과잉 검증을 어떻게 막나 — HITL과 클로드(페이블) 몰아쓰기

점심 무렵 한 참여자가 코덱스를 쓸 때 쓸모없는 작업과 검증에 시간이 엄청나게 들어간다는 문제를 꺼내자, 각자가 쓰고 있던 통제법이 곧바로 쏟아졌다. 모델이 답을 못 내서가 아니라 답을 낸 뒤에 스스로를 계속 다시 확인하느라 시간을 쓴다는 진단이었다. 필요한 것은 더 좋은 모델이 아니라 멈추는 지점을 정해 주는 장치라는 데 이야기가 모였다.

다들 코덱스 쓰실때 쓸모 없는 작업과 검즈에 엄청나게 시간 들어가는 문제

가장 먼저 나온 처방은 시간을 잘라 넣는 방식이었다. 다른 참여자는 30분마다 스스로 점검하게 만드는 타이머 프롬프트를 공유했다. 지금 하고 있는 일이 쓸데없는 작업이나 검증인지 주기적으로 되묻게 하고, 정당한 작업이면 그대로 이어 가게 하는 구성이다. 모델의 판단을 믿되 되돌아보는 시점만 바깥에서 강제로 박아 넣는 셈이다.

타이머 걸어놓고 30분마다 쓸데없는 작업이나 검증을 하고 있는지 자기학대 해라. 정당한 작업은 이어서 해라.

두 번째 처방은 사람을 다시 루프 안에 넣는 쪽이었다. 또 다른 참여자는 주말에 자동으로 돌려 둔 작업 5개 가운데 쓸 만한 것이 20%도 안 됐다며, 처음 하는 일에는 HITL(Human-in-the-Loop), 곧 사람이 중간에 개입하는 절차를 무조건 넣어야 하는 것 같다고 정리했다. 완전 자동으로 던져 두는 방식이 익숙한 작업에서는 통해도 처음 밟는 경로에서는 회수율이 급격히 떨어진다는 실사용 후기다.

제가 주말에 솔트라 패스트 /goal로 작업 5개 정도 돌려놨는데 그중에 쓸만한게 20%도 안되는군요.. 처음 하는일은 HITL을 무조건 해야하나 봅니다.

세 번째 축은 도구를 바꿔 쓰는 쪽이었다. 한 참여자는 GPT 계열은 중간중간 단도리를 잘해 줘야 하는 느낌이고 클로드는 좀 멍청해도 중간 보고를 잘하는 느낌이라고 두 도구의 성격을 갈랐다. 이 대비는 성능 순위가 아니라 감독 비용의 차이를 가리킨다. 중간 보고가 잦으면 결과가 조금 아쉬워도 어디서 어긋났는지 일찍 알 수 있고, 반대면 끝까지 지켜본 뒤에야 손실이 드러난다.

흐름은 결국 간단한 작업조차 전부 클로드 페이블(Fable)로 몰아 쓴다는 쪽으로 기울었다. 성능이 압도적이라서가 아니라 시간 대비로 그편이 낫다는 판단이 배경에 있었다. 도구를 여러 개 띄워 놓고 각각의 상태를 살피는 비용까지 계산에 넣으면, 하나로 몰아 두는 선택이 오히려 총소요를 줄인다는 계산이다.

전 간단한 작업조차 전부 페이블만 써요…

세 처방이 겨냥하는 지점은 결국 같아 보인다. 타이머든 사람의 개입이든 도구 교체든, 에이전트가 스스로를 확인하는 데 쓰는 시간을 바깥에서 끊어 주려는 시도라는 점에서 그렇다. 자동화의 병목이 모델의 능력에서 감독의 비용으로 옮겨 갔다는 뜻으로 읽히며, 그렇다면 선택 기준도 무엇을 더 잘하느냐보다 얼마나 적게 지켜봐도 되느냐 쪽으로 이동할 가능성이 있다. 다만 이날 방 안에서 수치로 확인된 것은 주말 작업 5건 중 20% 미만이라는 한 사람의 후기뿐이라는 점은 함께 남겨 둘 필요가 있다.