해 보고 나서야
알게 된 것들을 기록합니다

AI가 여러 대 일하면, 병목은 사람의 결정입니다

문제

일하는 AI가 늘어나자 사람이 결정해야 할 안건이 여러 대화창에 흩어졌습니다. 말로만 보고된 안건은 다음 날이면 어디에도 보이지 않았습니다.

해 본 것

• 결정을 기다리는 안건을 중앙 장부 하나에 모았습니다. 장부를 각 PC에 두면 PC가 꺼질 때 안건도 화면에서 사라지기 때문입니다.
• 같은 안건을 다시 올려도 처음 등록한 날짜는 바꾸지 않습니다. 날짜가 바뀌면 20일 묵은 안건이 새 안건처럼 보입니다.
• 6시간 동안 소식이 없는 항목은 흐리게, 24시간이 지나면 감춥니다. 멈춘 일을 "진행 중"으로 보여 주지 않기 위해서입니다.

배운 점안전망은 실패를 감춥니다. 전송에 실패한 안건을 보관해 두는 장치가 제 역할을 한 탓에, 등록 경로가 통째로 막혀 있었는데도 아무도 몰랐습니다. 성공률은 주기적으로 직접 재야 합니다.

에이전트 협업은 단순할수록 오래 갑니다

문제

PC마다 AI 에이전트를 한 대씩 두고, 중앙에서 명령을 내려보내 원격으로 실행하는 구조를 만들었습니다. 그러자 로그인 만료, 실행 경로, 관리자 권한, 코드 배포 문제가 줄줄이 생겨 PC 한 대를 연결하는 데 하루가 걸렸습니다.

해 본 것

• 지시는 각 PC에 띄워 둔 '업무 수신' 대화 세션으로 바로 보내고, 기록은 게시판 하나에만 남깁니다.
• 기록은 보낸 쪽이 자기 열쇠로 남깁니다. 대신 적어 주면 업무 흐름의 방향이 거꾸로 찍히는 것을 실제로 겪었습니다.
• 지시 후 5분 동안 응답이 없으면 알림을 한 번 보내고, 늦게라도 응답이 오면 복구 알림을 보냅니다.
• 모든 에이전트의 프로젝트 상태를 한 화면에서 봅니다. 상태를 자동으로 분류할 때는 제목과 '다음 할 일'에서만 막힘을 판단합니다.

배운 점자동화를 위한 자동화가 가장 비쌉니다. 이미 잘 돌아가는 도구(대화 세션)를 그대로 쓰는 쪽이 같은 날 끝났습니다.

AI에게 "확인했는지"를 표시하게 했습니다

문제

되짚어 보니 사고 6건이 모두 확인 명령 하나를 실행하지 않아서 생겼습니다. 버튼 일부만 눌러 보고 완료라고 보고했고, 배포한 것을 화면에 반영된 것으로 착각했습니다. 이미 있는 도구를 "없다"고 단언한 적도 있고, 오류 한 번만 보고 서버가 죽었다고 판단한 적도 있습니다.

해 본 것

• AI가 말하는 모든 사실에 [확인] [미확인] [추정] 중 하나를 붙이게 했습니다. [확인]에는 근거(실행한 명령, 경로, 출력)를 함께 적습니다.
• 원인을 진단할 때는 표본을 2개 이상 봅니다. 외부 정보는 검색 요약이 아니라 원본을 직접 엽니다.
• "간단한 질문이니 확인은 생략"은 허용하지 않습니다. 사고는 바로 그런 간단한 상태 확인에서 났습니다.

배운 점추측이 맞았더라도 신뢰는 깎입니다. 듣는 사람이 그 답을 검증할 방법이 없기 때문입니다.

LLM은 코드로 된 틀 안에 넣어야 합니다

문제

같은 입력을 넣어도 실행할 때마다 답이 달랐습니다. 프롬프트를 고쳐서 한 곳이 좋아지면 다른 곳이 나빠졌는데, 그걸 알아챌 방법이 없었습니다.

해 본 것

• 시스템의 모든 부품을 결정론(코드)과 확률론(LLM 판단)으로 나눠 표시했습니다.
• LLM 앞뒤를 코드 검사로 감쌉니다. 입력을 정리하고, LLM을 호출하고, 출력을 검증합니다. 검증에 실패하면 아무것도 하지 않는 안전한 값을 돌려줍니다.
• 프롬프트, 온도, 임계값 같은 설정은 파일 하나에만 두고 버전으로 관리합니다.
• 기준 문제 10건 이상을 만들어 두고, 설정을 바꾸기 전과 후의 통과율을 비교합니다. 통과율이 떨어지면 반영하지 않습니다.

배운 점수치 없는 튜닝 보고는 미완성입니다. "좋아진 것 같다"는 말은 판단 근거가 되지 않습니다.

"동작한다"와 "내보내도 된다"는 다른 질문입니다

문제

그동안 배포 여부는 "잘 동작하는가"만 보고 판단했습니다. 무인으로 도는 기능을 멈추는 방법, 로그에 남는 개인정보, 나중에 추적할 수 없는 자동 처리처럼 내보낸 뒤의 책임은 아무도 묻지 않았습니다.

해 본 것

• NIST AI RMF의 신뢰성 특성을 따라 7대 기준을 정했습니다. 유효성, 안전성, 보안성, 책임성, 설명 가능성, 개인정보, 공정성입니다.
• 안전성, 보안성, 개인정보 중 하나라도 미달이면 무조건 배포하지 않습니다.
• 검토서는 배포하기 전에 파일로 남깁니다. 배포한 뒤에 쓰는 검토서는 알리바이일 뿐입니다.
• 게이트와 최종 검토에서 실제로 잡은 사례: 인증 실패가 기록되지 않던 문제, 내부 요약 기능이 서버로 보내면 안 되는 개인 메모까지 함께 보내던 문제.

배운 점"테스트 서버", "일단 올려 두기"도 밖에서 접근할 수 있으면 배포입니다.

요구사항은 '전달'이 아니라 '품질'에서 갈립니다

문제

고객 요구사항이 모호하게 전달되면 일이 헛돕니다. 처음 설계에서는 긴급한 건만 따로 처리하도록 갈래를 나눴는데, 이것이 틀린 방향이었습니다. 긴급하든 아니든 전달은 항상 100%여야 하고, 차이는 전달된 내용의 품질에서 납니다.

해 본 것

• AI가 모호한 부분을 찾아 고객에게 확인 질문을 합니다(최대 3회). 조치, 일정, 비용에 대해서는 AI가 말하지 않습니다.
• 끝나면 결과는 확정본 아니면 미확정본 둘 중 하나입니다. 24시간 동안 응답이 없으면 미확정본으로 그대로 넘깁니다. 붙잡아 두면 게시판에서 썩습니다.
• "과장하지 마라"라는 프롬프트 지시는 지켰는지 검증할 수 없습니다. 그래서 AI가 뽑은 사실마다 원문 인용을 붙이게 하고, 서버가 그 인용이 원문에 실제로 있는지 기계적으로 검사합니다.
• 긴급 키워드로 등급을 나누는 방식은 실제 글 2건에 돌려 보니 2건 모두 오탐이었습니다. 요구사항 글은 원래 전부 "무엇이 안 된다"는 내용이기 때문입니다. 그래서 AI는 사실만 뽑고, 등급은 코드 표가 정합니다.

배운 점환각은 프롬프트로 막는 게 아니라, 코드로 검사할 수 있는 형태로 만들어서 막습니다.

가장 위험한 실패는 조용한 실패입니다

사례 1

입금 확인 자동화가 한 달 동안 멈춰 있었는데 아무도 몰랐습니다. 수집에 실패하면 빈 목록을 돌려주도록 되어 있어서 "새 입금 0건"과 "수집 장치 고장"을 구분하지 못했습니다. 게다가 금액은 대조하지 않고 이름만 맞춰 가장 오래된 미수금에 반영하고 있었습니다.

고친 것

• 실패와 0건을 구분합니다. 5번 연속 실패하면 알림을 보내고, 복구되면 복구 알림도 보냅니다.
• 자동 확정은 금액이 정확히 일치하고 후보가 1건일 때만 합니다. 나머지는 사람이 확인하는 보류함으로 보냅니다.

사례 2

기록의 식별자에 저장 시각을 넣었더니, 같은 내용도 저장할 때마다 새 항목으로 쌓였습니다. 한 저장소는 정상보다 645배로 불어났습니다. 식별자를 내용에서 만들도록 바꾼 뒤로는 같은 작업을 반복해도 한 건도 늘지 않습니다.

배운 점자동화는 "멈췄다"를 크게 말하도록 만들어야 합니다. 사람이 확인하는 보류함은 실패가 아니라 설계의 일부입니다.

멀리서 누른 터치가 안 잡히던 원인을 찾아 다시 설계했습니다

문제

벽이나 바닥에 투사한 화면을 멀리서 누르면 인식이 잘 안 된다는 현장 의견이 있었습니다. 원인을 찾아보니, 센서가 한 바퀴에 300점(1.2° 간격)을 찍는데 손으로 인정하려면 2점 이상 맞아야 했습니다. 약 1.9m를 넘어가면 손에 1점만 맞아서 통째로 버려지고 있었습니다.

해 본 것

• 회전 속도를 낮춰 점 간격을 0.8°로 촘촘하게 했습니다.
• 빔마다 배경을 통계로 학습해서, 배경과 다른 점만 손 후보로 봅니다.
• 한 프레임에서 판정하지 않고 여러 프레임의 증거를 모아 확정하는 추적기를 만들었습니다.
• 시제품과 실제 제품에 옮긴 코드가 녹화 데이터에서 프레임 단위로 같은 결과를 내는지 검증했습니다.

덤

조사하는 중에 "터치 위치가 0.8배 작게 잡힌다"는 문제도 찾았습니다. 처음에는 새 알고리즘 탓이라고 의심했지만, 데이터를 보니 화면 해상도 값이 예전 값으로 남아 있던 것이 원인이었습니다. 새 알고리즘을 쓰기 전 버전에서도 같은 증상이 나왔습니다.

남은 숙제

실제 4m 거리에서의 실측과 현장 재보정이 남아 있습니다. 위 수치는 모의 실험 결과입니다.

배운 점상수 하나만 바꾸는 빠른 수정에는 오인식을 막을 장치가 없습니다. 그리고 녹화 데이터 없이는 튜닝 결과를 숫자로 검증할 수 없습니다.