페어리의 검토는 정답보다 제안서에 가까웠다

대상과 시점, 지적과 피드백을 문서로 연결했다. 다른 AI의 검토도 다시 확인해야 했던 이유.

만든 결과를 다른 자리에서 다시 보게 하고 싶었다. 페어리 폴더는 6월 4일 안내에 다른 작업 세션이나 모델로 검토 결과를 넘기는 인계 위치라고 적혀 있다.

대화창에서만 문제를 말하면 다음 세션이 기준을 놓치기 쉽다. 대상 프로젝트와 시점, 결론과 확인 목록을 문서로 남기고 적용한 쪽에서 다시 답하도록 했다.

코드에 적힌 규칙이 실제로 쓰이는지

검토 대상은 웅삐만이 아니었다. 웨일서바이버의 카드풀과 경험치, 무기 적용 범위를 다룬 문서도 있었다.

6월 4일 외뿔고래 검토에서는 특정 구간만 바뀌어야 하는 규칙이 더 넓게 적용되는지, 초기 카드풀을 정했는데 실행 중 후보가 다시 늘어나는지, 새 무기를 우선하는 조건이 실제로 보장되는지를 나눠봤다.

상수나 문구가 코드에 있다고 실제 선택을 그 규칙이 결정하는 것은 아니었다. 이름을 찾는 것보다 한 단계 더 들어가야 했다. 다만 이 지적들은 당시 검토이며 지금도 그대로 남은 결함이라는 뜻은 아니다.

검토 문서는 제안함에서 끝나지 않았다. 적용 쪽에서 다르게 처리한 부분을 피드백으로 남기고, 사용한 문서는 따로 보관했다. 사진 실패 사례처럼 검토가 원인을 잘못 짚은 경우도 있었다.

다른 AI가 한 번 더 봤다는 사실만으로 정답이 되지는 않았다. 어느 버전을 봤는지, 증상과 코드가 맞는지, 적용 뒤 무엇이 달라졌는지가 이어져야 했다.

지금 이 구조를 다시 설명한다면 페어리는 심판보다 질문을 하나 더 던지는 역할에 가깝다. 무엇을 찾았는지뿐 아니라 무엇을 잘못 짚었는지도 남겨야 다음 검토에 도움이 됐다.