다섯 개가 쌓이자 도장을 찍고 있었다: '묵인 승인' 패턴 없애기

처음에는 괜찮았습니다.

소스 하나, 혹은 두 개가 인박스에 들어오면 꼼꼼히 검토하고 승인하거나 거절했습니다. 어떤 것은 “이 출처는 신뢰하기 어렵다”고 거절하고, 어떤 것은 “이 주장은 T3 수준이지만 흥미롭다”고 조건부로 통과시켰습니다.

그런데 어느 날 인박스에 소스가 일곱 개 쌓여 있었습니다.

처음 두 개는 신중하게 검토했습니다. 세 번째부터 속도가 빨라졌습니다. 다섯 번째쯤 됐을 때 저는 사실상 제목만 훑어보고 승인하고 있었습니다. 일곱 번째는 무슨 내용인지도 잘 기억나지 않습니다.

한 번의 “인제스트 세션”에 모든 것을 몰아넣은 결과였습니다.

’묵인 승인’의 함정

묶음으로 처리하면 효율적이라고 생각했습니다. 일곱 개를 한꺼번에 검토하면 한 번만 집중하면 되니까요.

그런데 인간의 주의력은 그렇게 작동하지 않습니다. 첫 번째 소스를 검토할 때의 집중도와 일곱 번째 소스를 검토할 때의 집중도는 같지 않습니다. 특히 이전 여섯 개가 모두 “승인”으로 끝났다면, 일곱 번째도 승인하고 싶은 관성이 생깁니다.

이것을 ‘묵인 승인(Browse and Accept)’ 패턴이라고 부르기 시작했습니다. 실제로 검토하지 않고 검토한 척 도장을 찍는 것입니다.

문제는 이 패턴이 나쁜 의도에서 오지 않는다는 점입니다. 저는 제가 검토하고 있다고 생각했습니다. 하지만 인식과 실제 행동 사이에 차이가 있었습니다.

분리: 분석, 검토, 쓰기

해결책은 하나의 “인제스트 세션”을 세 단계로 나누는 것이었습니다.

Stage 1 — 분석: AI 에이전트가 혼자서 모든 소스를 분석합니다. 중복 체크, S/V-tier 판단, 위키 업데이트 초안. 저는 이 단계에 참여하지 않습니다. 에이전트가 알아서 진행합니다.

Stage 2 — 검토: 저 혼자서, 한 번에 하나씩, 에이전트가 분석한 결과를 검토합니다. 서두를 필요가 없습니다. 오늘 세 개를 검토하고 나머지는 내일 해도 됩니다. 이 단계는 에이전트가 개입하지 않습니다.

Stage 3 — 쓰기: 제가 승인한 것들을 에이전트가 일괄적으로 위키에 반영합니다. 다시 순수하게 기계적인 작업입니다.

세 단계를 분리하자 두 가지가 달라졌습니다.

첫째, 검토가 실제 검토가 됐습니다. 한 번에 하나씩, 시간 압박 없이.

둘째, 분석 품질에 대한 피드백이 명확해졌습니다. 이전에는 분석→검토→쓰기가 한 흐름에서 일어나서, 분석이 틀렸을 때 어디서 틀렸는지 보기 어려웠습니다. 단계가 분리되니 “Stage 1 분석은 맞는데 Stage 2 판단에서 제가 틀렸다”처럼 구분이 됐습니다.

시스템 설계에서 배운 것

이 변경을 하고 나서야 깨달은 점이 있습니다.

처음 설계에서 “인제스트”를 하나의 작업으로 묶은 것 자체가 문제의 씨앗이었습니다. 분석은 AI에게 맡길 수 있는 일이고, 검토는 사람이 해야 하는 일이며, 쓰기는 다시 AI에게 맡길 수 있는 일입니다. 이 세 가지는 성격이 다릅니다. 성격이 다른 일을 같은 상자에 넣으면, 결국 가장 약한 고리가 전체를 망가뜨립니다.

사람의 주의력이 필요한 부분을 정확히 식별하고, 그 부분만 사람에게 맡기는 것. 나머지는 자동화할 수 있습니다. 하지만 그 경계를 흐릿하게 두면, 사람의 주의력이 필요한 순간에 주의력이 없는 상태로 임하게 됩니다.

이 글을 쓰면서 인박스를 확인했더니 소스가 열 개 쌓여 있었습니다. 세 단계로 나눠서 처리했습니다.