에이전트 업무일지Agent work log · 2026-09-09

AI 동료 제작기: 페어리의 검토는 정답보다 제안서에 가까웠다

기록일 2026. 6. 4.수정 2026. 9. 9.

표시 날짜는 이 글이 다루는 작업의 대표 기록일이며, 당시 발행된 글을 뜻하지 않습니다. 이후 회고와 적용 방법은 2026년 9월에 정리했습니다.

이 글의 목적

페어리 폴더에 검토 문서를 넘기고 인계받는 방식을 쓰는 사람에게, 왜 검토 결과를 명령이 아니라 다시 대조할 가설로 다뤄야 하는지 보여준다.

핵심 내용

6월 4일 외뿔고래 구현 검토는 계획과 코드가 어긋난 지점—적용 범위, 초기 카드풀과 런타임 후보, 무기 우선 조건—을 따로 짚었다. 코드에 이름이 있다는 것과 그 규칙이 실제 선택을 지배한다는 것은 다른 문제였다.

읽고 나서

검토를 요청할 때 함수 이름을 찾아달라고 하지 말고, ‘이 조건이 실제로 선택 경로를 지배하는가’ 같은 재현 가능한 질문으로 바꿔서 보낸다.

연재 목차

먼저 답하면

페어리 폴더는 6월 4일 작성된 안내에서 자신을 검토 결과를 다른 작업 세션이나 모델로 넘기는 인계 위치라고 설명한다. 검토 대상은 웅삐만이 아니라 웨일서바이버의 카드풀·경험치·무기 적용 범위도 있었다.

만든 결과를 다른 자리에서 다시 보게 하고 싶었다.

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

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

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

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

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

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

검토를 요청할 때는 대상 버전, 기대 규칙, 실제로 의심되는 행동을 묶어서 준다. 예를 들어 ‘첫 구간 카드 후보가 이 목록만으로 제한되는가’는 함수 이름을 찾아달라는 요청보다 명확하다. 후보가 만들어지고 다시 걸러지는 경로까지 볼 이유가 생긴다.

결과에는 정상 조건 하나와 경계 조건 하나를 요구해볼 수 있다. 특정 캐릭터에서만 적용되는 규칙이라면 다른 캐릭터에서 바뀌지 않는 것도 확인한다. 잘못된 범위 적용을 찾는 데 도움이 된다. 단, 코드만 읽은 검토와 실제 입력으로 실행한 시험은 표시를 달리한다.

제안함과 적용 피드백을 연결하면 검토의 정확도도 돌아볼 수 있다. 무엇을 맞혔는지뿐 아니라 오래된 버전 때문에 틀린 지적, 실행 조건이 빠진 지적을 남긴다. 보고서가 길어지는 것보다 다음 사람이 같은 증상을 재현할 수 있는 것이 더 중요하다.