9월 20일, Jev 벤치마크를 다룬 짧은 글을 X에 올렸다. 사실관계는 맞았지만 읽어 보니 검증 메모에 가까웠다. 데이터를 어떻게 나눴는지, 검증에 쓴 사례를 어떻게 재사용했는지, 어떤 처리 경로가 실패했고 어디를 실패 기준으로 잡았는지까지 넣다 보니, 정작 내가 겪은 일을 설명하는 글이 그 세부사항에 묻혔다.
더 난감한 건 이미 두 차례 검토를 거친 글이었다는 점이다.
평소에는 첫 번째 AI 검토자에게 초안과 근거 자료를 주고, 지적받은 부분을 고친 뒤 다른 AI 검토자에게 수정본 전체를 보낸다. 두 번째 검토자도 글의 목적과 독자, 확인된 사실은 보지만 앞선 검토의 결론은 받지 않는다. 같은 판단을 따라가기보다 다른 문제를 찾아낼 여지를 남기려는 방식이다.
LangChain이 9월 8일 공개한 Deep Agents의 맥락 전달 방식에 관한 글에서도 비슷한 선택을 다룬다. 격리된 하위 에이전트는 맡은 과제만 받고 상위 에이전트의 대화는 받지 않는 반면, 대화를 분기해 만든 하위 에이전트는 앞선 대화를 이어받는다. LangChain은 상위 에이전트의 진단에 검토가 끌려갈 수 있는 경우에는 격리를, 앞선 조사 과정이 필요한 작업에는 대화 분기를 제안한다.
이번 검토에서도 실제 문제는 잡혔다. 첫 검토에서는 억지로 붙인 교훈을 걷어내고, 사람이 검토하도록 넘기는 경로에 대한 설명을 다듬었다. 두 번째 검토에서는 고친 사실관계를 확인했다. 그런데도 막상 게시하고 나서야 눈에 들어온 문제는 둘 다 놓쳤다. 글 전체가 자연스럽게 쓴 문장보다 조립한 문장처럼 읽혔다.
X에서 수정할 수 있는 시간이 지나기 전에 Jev 글을 다시 썼다. 처음에는 합성 사례로 시험했고 이후 과거 사업 사례 50건을 사용했다는 점, 마지막 15건을 검증에 재사용했다는 점, 거절하거나 사람의 검토로 넘기는 경로가 실패했다는 점과 다음에 해 볼 일을 남겼다. 나머지 세부사항은 실험 노트에 두는 편이 나았다.
다음 검토에서는 사실이 맞는지만 볼 게 아니라, 공개 글보다 실험 노트에 들어가는 편이 나은 대목도 표시해 달라고 하려 한다. 이 글에서는 검증 사례를 재사용했다는 사실은 남겨야 했지만, 처리 경로를 나누는 세부 임곗값까지 설명할 필요는 없었다.