루프 엔지니어링의 가장 어려운 완료 기준 설정

6개월차는 보고서를 열자마자 통과와 반려를 압니다. 숫자마다 출처가 붙어 있는지, 합계가 재무팀 확정 실적과 맞는지를 보면 됩니다. 그런데 이 기준을 처음 글로 적어보라고 하면 대부분 "보고서가 논리적으로 작성되어야 한다"는 문장에서 멈춥니다. 머릿속에서는 분명했던 기준이 적어 놓고 보면 사람마다 다르게 읽히는 말이 되어 있습니다.

루프는 됐으면 멈추고, 안 됐으면 다시 하는 동작이 전부입니다. "됐다"를 가를 기준이 없으면 멈출 곳을 찾지 못해 돌고 또 돕니다. 하네스와 루프 엔지니어링이 자리잡은 개발 영역은 코드와 테스트가 맞고 틀림으로 갈리는, 기준이 0과 1로 정해진 곳입니다. 그런데 하네스 엔지니어링 2편의 기준은 한 번의 보고서만 가렸을 뿐, 다음 달도 같은 판정이 나올지는 다루지 않았습니다. 루프는 다릅니다. "보고서가 논리적이다"처럼 사람마다 다른 답이 나오는 문장으로는 에이전트도 사람도 같은 결론에 닿을 수 없습니다.

판정이 사람마다 흔들리면 그 기준으로 도는 루프도 흔들린다는 것이 지난 편이 남긴 질문이었습니다. 두 사람이 따로 읽어도 같은 판정이 나오는 기준은 어떻게 적어야 할까요.

완료 기준, 형용사를 버리고 참과 거짓으로 답하게 만든다

통과와 반려를 가르는 기준을 완료 기준이라고 부르겠습니다. "보고서가 논리적으로 작성되어야 한다"도 완료 기준입니다. 다만 이대로는 쓸 수 없습니다. 참 또는 거짓으로 답할 수 없기 때문입니다. 형용사 "논리적"의 뜻을 사람마다 다르게 채우니, 검토 에이전트도 수치를 많이 넣은 보고서는 논리적이라 보고, 근거가 부족하다며 반려하는 식으로 서로 다른 판정을 내립니다.

참 또는 거짓으로 답할 수 있게 다듬어야 완료 기준을 실제로 쓸 수 있습니다. 1편이 예로 든 "필수 항목 5개가 모두 채워지고 숫자 출처가 전부 표시될 때까지"가 이렇게 다듬은 완료 기준입니다. "필수 항목 5개가 모두 채워졌는가"는 그대로 참 또는 거짓을 답할 수 있고, "숫자 출처가 전부 표시"는 "금액마다 원본 파일명과 행 번호가 붙어 있는가"로 바꿔야 참 또는 거짓을 답할 수 있습니다. 주간 채널 실적 보고의 완료 기준은 이 둘을 포함해 모두 여섯 개입니다. 대리점 합계가 재무팀 확정 실적과 일치하는가, 증감률과 순위를 원본 데이터로 다시 계산해도 같은 값이 나오는가, 본문은 40줄 이하이고 금액은 원 단위로, 비율은 소수 첫째 자리까지로 썼는가, 보고서 파일은 한 개에 이 다섯 항목만 담았는가.

여섯 기준은 멈추는 지점이면서 일의 범위이기도 합니다. 1편에서 끝을 정해 주지 않은 "이번 주 주간 보고서 만들어줘" 한 줄이 98줄에서 191줄까지 늘어나고 수식 1,016개짜리 엑셀을 만들어낸 것은 검증과 분석을 얼마나 덧붙여도 되는지 막아 둔 기준이 없었기 때문입니다. 파일 한 개와 다섯 항목이라는 여섯 번째 기준은 이 확장을 그 자리에서 막습니다.

판정, 코드와 검토 에이전트와 사람이 서로 다른 자리를 맡는다

정답이 하나로 객관적인 판단이 가능한 기준은 코드가 검증을 맡고, 맥락이 필요한 판단은 검토 에이전트가, 기준 밖의 입력이나 되돌릴 수 없는 판단은 사람이 맡습니다. 앞선 여섯 가지 기준에 이 구분을 대 보면, 기준 하나하나가 참인지 거짓인지는 코드가 가릴 수 있습니다. 항목이 채워졌는지 세고, 출처 표시가 붙어 있는지 확인하고, 합계와 증감률을 원본 데이터로 다시 계산해 맞댑니다. 전부 참 또는 거짓이 하나로 가려지는 기준입니다.

여섯 기준을 검토한 결과를 모아 통과인지 반려인지를 정하고, 반려라면 왜 반려인지를 사람이 읽고 고칠 수 있는 문장으로 쓰는 일은 검토 에이전트가 맡습니다. "기준 3개 미달"이라고 뭉뚱그리면 다음 차례에 무엇부터 고쳐야 할지 알 수 없습니다. 반려 사유 한 줄에는 어긴 기준 하나와 고칠 곳 하나만 담아야, 다시 만들 때 그 한 곳만 고쳐집니다.

권한, 검토 에이전트는 원본을 읽되 고치지 못한다

검토 에이전트는 애초에 보고서를 만든 에이전트와 완전히 분리되어야 합니다. 그런데 분리된 에이전트로 만들고는 동일한 권한을 넘겨주면 이 독립은 지켜지지 않습니다. 합계와 증감률을 원본 데이터로 다시 계산하여 검토하려면 검토 에이전트에게 대리점 파일과 재무팀 확정 실적을 읽을 권한부터 있어야 합니다. 이 권한을 막아두면 맞게 쓴 보고서도 근거를 확인할 길이 없어 반려됩니다. 다만 읽는 권한과 고치는 권한은 분리되어야 합니다. 검토 에이전트에게 고치는 권한까지 주면, 반려해야 할 보고서를 스스로 고쳐 통과시켜 버릴 수 있습니다. 판정과 수정이 같은 손에 있으면 판정 자체가 무의미해집니다. 그래서 검토 에이전트는 원본과 보고서는 읽되 쓸 수는 없어야 합니다. 검토 에이전트가 쓸 수 있는 건 판정 기록만으로 한정해야 합니다.

이 권한 설계가 실제로 믿을 만한지는 교정 세트로 테스트하여 확인합니다. 결함을 하나씩 심어 둔 보고서 3건과 정상 보고서 1건, 모두 4건을 검토 에이전트에게 주고 전부 맞혀야 루프에서 사용될 수 있습니다. 결함이 어디 있는지 적어 둔 정답 파일은 검토 에이전트가 읽지 못하는 폴더 밖에 둡니다.

4건을 다 맞혔다고 끝이 아닙니다. 판정 사유를 읽고 보고서 문구를 그대로 믿었는지, 원본 숫자를 직접 대조했는지를 함께 확인합니다. "확인 완료"라는 문구만 보고 통과시켰는데 마침 그 보고서가 결함 없는 1건이었을 수도 있기 때문입니다. 답이 맞아도 과정까지 맞아야 루프에 검토 에이전트를 배치할 수 있습니다.

이제 검토 에이전트는 추측 대신 원본을 읽고 계산하여 판정합니다. 필수 항목이 빠졌는지, 합계가 재무팀 확정 실적과 맞는지를 매번 같은 기준으로 짚어 반려 사유 한 줄을 남기고, 교정 세트를 통과한 뒤에야 루프에 들어왔습니다. 그런데 같은 지적을 받은 채널 담당이 고치고 또 고쳐 올리는데도 통과하지 못한다면 어떨까요. 완료 기준은 흔들리지 않는데 보고서는 계속 반려됩니다. 판정이 믿을 만해졌다고 반복까지 끝나는 것은 아닙니다. 반려가 반복될 때 언제 사람을 불러야 하는지는 아직 정해지지 않았습니다. 다음 편에서는 이 순간을 어떻게 알아채고 사람을 부르는지를 다룹니다.

이 사례는 포텐스닷이 진행한 루프 엔지니어링 교육에서 나온 것입니다. 같은 과정을 직접 설계해보고 싶다면 포텐스닷 기업교육에서 확인할 수 있습니다.