하네스 엔지니어링, AI에게 검증과 멈출 때를 맡긴다

지난 편에서 반복되는 일을 코드로 옮겨 도구를 만들고, 그 도구에 회사만 아는 기준을 채워 넣었습니다. 해외 법인 40곳의 실적을 모아 쓰는 월간 리뷰 한 건은 그렇게 내용과 형식 모두 믿을 만한 수준이 됐습니다.

그런데 이 수준에 닿았는지는 매번 사람이 직접 열어보고 확인했습니다. 확률로 움직이는 AI이니, 이번 달 보고서가 기준에 맞았다고 해서 다음 달 것도 맞으리라는 보장은 없습니다. 같은 확인을 매달 반복해야 한다면 에이전트에게 일을 맡겼다고 말하기는 어렵습니다.

결과를 통과시킬 기준과 그 기준으로 판정할 장치를 에이전트 바깥에 세우는 일이 남았습니다. 그리고 그 장치가 넘지 말아야 할 선까지 정해야, 보고서 한 건을 비로소 매번 보지 않고 맡길 수 있습니다.

판정 기준을 세워야, 내가 아니라 에이전트가 검증할 수 있다

기준 없이 결과물을 맡기면 무슨 일이 생기는지는 이미 한 번 봤습니다. 회사 기준을 모른 채 쓴 보고서가 그럴듯한 문장으로 잘못된 결론에 닿았던 것처럼, 기준 없이 검증까지 맡기면 잘못된 판정에도 그럴듯한 근거가 따라붙습니다.

검증을 넘기려면 먼저 통과의 기준부터 사람이 글로 적어야 합니다. 이 결과물은 통과라고 판단할 근거가 없으면, 에이전트에게 검증을 맡기는 게 아니라 아무 기준 없이 흘려보내는 것과 다르지 않습니다.

월간 리뷰의 검증기준표에는 1편에서 넣은 회사 기준이 그대로 들어갑니다. 분기합계 열이 집계에서 빠졌는가, 러시아 법인이 집계에서 제외됐는가, 법인코드가 전부 권역으로 매핑됐는가, 제품군별 미달선(주력인 스마트폰·태블릿 95%, 신규인 웨어러블·버즈 85%)이 올바로 적용됐는가. 그리고 원인 서술이 실제 데이터 근거와 연결되는가, 결론이 바로 쓸 수 있는 수준인가. 항목마다 기계로 판정할 수 있는지, 사람이나 에이전트의 판단이 필요한지를 표시해 둡니다.

이 표시 하나로 역할이 갈립니다. 기준이 없을 때는 결과가 나올 때마다 사람이 전부 열어봐야 했지만, 기준이 서고 나면 그 기준과 결과를 맞대어 보는 일은 사람이 아니어도 할 수 있는 일이 됩니다. 검증기준표도 결국 파일입니다. 매번 대화마다 전부 읽히면 무거워지니, 상시 지킬 기준은 매번 읽는 규칙 파일에 두고, 법인 40곳 매핑표처럼 양이 많고 판단이 필요 없는 표는 에이전트가 직접 읽지 않고 코드가 조회하게 둡니다.

기준은 섰습니다. 이제 이 기준으로 누가, 또는 무엇이 실제로 판정할지가 남았습니다.

검증은 코드, 에이전트, 사람 셋 중 누가 맡을지로 나뉜다

기준이 있어도 완벽하게 지켜지는 건 아닙니다. 확률로 움직이는 AI이니 같은 지시를 백 번 수행해도 백 번 다른 결과가 나올 수 있고, 한 번의 통과율이 95%라 해도 수집, 전처리, 분석, 보고서 작성으로 이어지는 단계를 세 번만 거쳐도 통과율은 95%의 세제곱인 85.7%로 떨어집니다. 어느 단계에서 틀렸는지 모른 채 최종 결과만 보고 믿을 수는 없습니다.

그래서 검증은 세 주체 중 누가 맡을지를 정하는 일입니다.

정답이 하나뿐인 기준은 코드가 맡습니다. 분기합계 열을 월별 값과 같이 더하면 이중 집계가 되는 것처럼, 기계적으로 맞고 틀림이 갈리는 기준입니다. 코드로 판정하는 이유는 비용이 싸서가 아니라 환각이 없기 때문입니다. 사람 눈도 에이전트도 백 번 보면 몇 번은 놓치지만, 코드는 놓치지 않습니다.

맥락 판단이 필요한 기준은 별도의 에이전트가 맡습니다. 원인 서술이 실제 데이터에 근거하는지, 결론이 바로 쓸 수 있는 수준인지는 숫자 하나로 가려지지 않습니다. 이 검증을 맡는 에이전트는 보고서를 어떻게 만들었는지는 모른 채, 결과물과 기준만 보고 판정합니다. 만든 쪽과 같은 맥락을 공유하면 자기가 만든 오류를 스스로 못 잡기 때문입니다.

코드로도, 에이전트로도 판정할 수 없는 영역이 남습니다. 대외에 발표할 자료인지, 예산이나 계약이 걸린 판단인지처럼 리스크가 큰 결정은 사람의 몫입니다. 이 영역은 검증을 넘기다 보니 남은 게 아니라, 애초에 넘기면 안 되는 영역입니다. 사람이 검증해야 하는 자리라면, 에이전트가 거기까지 혼자 가버리게 둬서는 안 됩니다.

사람이 검증할 영역만큼, 에이전트가 자유롭게 움직일 범위를 정한다

사람이 검증해야 하는 영역이 있다는 것은, 그 앞까지는 에이전트가 자유롭게 움직여도 되고 그 너머는 안 된다는 뜻이기도 합니다. 그 경계를 그어두는 일이 권한입니다.

실습 첫날 이미 선 하나를 그었습니다. 교육 전용 폴더만 열어, 그 폴더 밖의 사내 자료나 개인 파일은 애초에 에이전트가 열어볼 수 없게 막았습니다. 폴더를 여는 순간 그 안은 전부 노출되기 때문입니다. 월간 리뷰 업무에도 같은 경계가 필요합니다. 법인들이 올려준 원본 실적 파일과 월간리뷰 작성기준, 디자인 가이드 문서는 읽기 전용으로 두어 에이전트가 참고는 하되 고치지는 못하게 합니다. 작업 중 결과물은 자유롭게 쓸 수 있는 폴더에 쌓이지만, 사업부장에게 나가는 발행 폴더에는 검증을 통과한 뒤에만 쓸 수 있습니다.

이 마지막 경계가 멈춤입니다. 검증을 통과하지 못하면 발행 폴더에 쓸 권한 자체가 없으니, 사람이 매번 지켜보지 않아도 못 나가야 할 결과물은 나가지 않습니다. 되돌릴 수 없는 행동 앞에서는 이렇게 아예 권한으로 막아두고, 매핑표에 없는 법인코드처럼 기준으로 판정할 수 없는 입력이 나오면 추측하지 말고 사람에게 묻게 합니다.

잘못된 컨텍스트는 다시 시키면 그만이지만, 잘못된 하네스는 되돌릴 수 없는 일을 저지릅니다. 그래서 반드시 멈춰야 하는 지점은 규칙 파일에 적어두는 지침만으로 남겨두지 않습니다. 지침은 에이전트가 참고할 뿐 반드시 따르리라는 보장이 없는 반면, 권한은 그 자체로 못 하게 만드는 장치이기 때문입니다.

하네스는 AI 에이전트가 원하는 방향으로만 움직이게 만드는 일의 환경 전체입니다. 일을 처리할 도구를 만들고, 그 도구에게 회사 사정을 알려주고, 결과가 통과인지 판정할 기준과 장치를 세우고, 되돌릴 수 없는 순간에는 멈춰서 사람에게 묻게 만드는 일까지, 이 전부가 하네스입니다.

1편에서는 앞 두 가지를 채웠습니다. 반복되는 일을 코드로 옮겨 도구를 만들고, 그 도구에 회사만 아는 기준을 알려줬습니다. 2편에서는 나머지 두 가지를 세웠습니다. 결과를 통과시킬 기준을 사람이 먼저 쓰고 코드와 에이전트, 사람이 나눠 판정하게 했고, 에이전트가 넘지 말아야 할 경계를 그어 되돌릴 수 없는 순간에는 멈추게 했습니다.

이제 월간 리뷰 한 건은 매번 열어보지 않아도 되는 상태가 됐습니다. 기준에 맞는 부분은 코드와 에이전트가 걸러내고, 사람은 정말 봐야 할 자리에서만 나섭니다.

그런데 이 판정과 멈춤은 한 번의 시도를 통과시키는 데까지만 다룹니다. 에이전트가 단 한 번 만에 통과 기준을 채우는 경우는 드뭅니다. 반려되면 사유를 보고 다시 시켜야 하는데, 그 다시 시키는 일마저 사람이 매번 해야 한다면 쌓아온 기준과 장치의 절반은 여전히 사람 손에 남아 있는 셈입니다. 이 기준과 장치를 갖춘 하네스 안에서, 에이전트가 목표를 완수할 때까지 스스로 반복해서 돌아가게 하려면 무엇이 더 필요할까요.