새 API를 계획하면서 라우트와 서비스의 위치를 확인해도, 구현 세션은 그 근거를 받지 못하면 같은 코드를 다시 찾게 됩니다. 반대로 검색 결과를 전부 넘기면 구현자가 다시 선별해야 합니다. 어느 범위에 메모가 도움이 되는지 알아보기 위해 새 기능과 기존 동작 변경, 고정 패치 검토를 나눠 비교했습니다. 1.5.2는 적용 범위를 좁혔고, 1.5.5는 넘겨받은 위치를 현재 코드와 대조했고, 1.5.6은 이전 검사가 이번 리뷰의 근거로 섞이지 않도록 했습니다.
1.5.2 새 기능에만 탐색 메모
과거 개발 작업 세 가지를 골랐습니다. 새 백엔드 API, 새 프론트엔드 기능, 기존 화면 동작 변경입니다. 작업마다 같은 요구와 시작 소스에서 Codex 구현을 조건별 다섯 번 실행했습니다. 한쪽은 작업별로 미리 고정한 계획 메모를 받았고, 양쪽 모두 rg를 썼습니다. 검토 효과는 같은 패치를 검토하는 별도 실험으로 확인했습니다. 계획 메모 비교 실험
| 작업 | 디렉터리 탐색 합계 | 토큰 합계 | 실행 시간 중앙값 |
|---|---|---|---|
| 새 백엔드 API 구현 | 34 → 16 | 1,887,966 → 1,335,521 | 191.6초 → 175.9초 |
| 새 프론트엔드 기능 구현 | 40 → 33 | 3,634,961 → 3,018,478 | 292.4초 → 279.1초 |
| 기존 화면 동작 변경 | 23 → 7 | 1,372,917 → 1,179,555 | 89.2초 → 105.7초 |
| 새 프론트엔드 패치 검토 | 16 → 26 | 574,338 → 728,400 | 39.1초 → 45.4초 |
두 새 기능에서 구현 탐색과 총 토큰이 함께 줄었습니다. 새 백엔드 기능의 검사 전체를 통과한 실행은 메모 없이 5건 중 1건, 메모를 받아 5건 중 5건이었습니다. 기존 화면 동작 변경에서는 양쪽이 동작 검사에 통과했지만, 메모를 받은 쪽의 실행 시간 중앙값은 늘었습니다. 별도 패치 검토에서는 두 조건 모두 각 과제의 사전 삽입 결함을 5번 중 5번 찾았고, 새 화면 기능의 패치에서는 메모를 받은 쪽의 탐색과 토큰이 늘었습니다. 비교한 것은 각 과제에 미리 고정한 메모 하나의 효과이며, 세 항목이라는 상한은 별도로 비교하지 않았습니다. 검사 통과와 패치 검토 결과
1.5.2에서는 구현 파일이나 모듈을 여러 개 거치는 새 기능에 한해, 계획에서 이미 확인한 저장소 상대 경로와 정확한 심볼, 실행했다면 검사 결과를 최대 세 항목으로 남기게 했습니다. 구현은 그 위치에서 탐색을 시작합니다. 작업 범위와 완료 조건, 계획한 검사는 모든 작업의 기본 계획에 들어갑니다. 정식 검토에는 실제 변경과 검증 근거가 필요하므로 구현용 탐색 메모는 기본적으로 넘기지 않습니다. COCO 1.5.2 변경 기록
별도로 예제 저장소에서 지침을 읽고 인수인계 문서를 작성하게 했습니다. 첫 확인에서는 탐색 메모를 생략한 두 과제의 기본 인수인계에 이전 검사 결과가 다시 들어갔습니다. 추가로 넘길 탐색 근거는 적용 대상의 메모에만 적도록 문구를 고쳤고, 다시 확인했을 때 두 문서 모두에서 그 결과가 빠졌습니다. 이 검사는 지침을 따른 문서의 결과를 살펴본 것으로, 예제 기능을 구현하거나 그 테스트를 실행한 비교와는 범위가 다릅니다. 인수인계 절차 점검
1.5.5 현재 소스와 메모 대조
계획에 적힌 심볼은 그 시점에 확인한 이름입니다. 구현을 시작할 때 기준 브랜치가 바뀌었다면 파일이 옮겨졌거나 검사 결과가 다른 코드의 것일 수 있습니다. 1.5.5에서는 경로나 검사 결과가 특정 소스 리비전에 의존할 때 그 리비전도 메모에 적도록 했습니다. 구현 세션은 현재 체크아웃에서 경로·심볼·관련 리비전을 대조한 뒤 사용합니다. 일부 정보만 오래됐거나 서로 맞지 않으면, 그 부분만 범위를 좁혀 다시 찾고 구현에 필요한 검사를 실행합니다. COCO 1.5.5 변경 기록
대상을 세는 기준도 구체화했습니다. 구현 파일 하나에 새 함수를 만들고 테스트 파일 하나를 더하는 작업은 구현 파일 하나로 셉니다. 기존 기능을 바꾸는 작업은 파일 여러 개를 수정해도 일반 계획을 사용합니다. 예를 들어 새 라우트와 서비스를 잇는 계획이라면 메모로 시작 위치를 전달할 수 있습니다. 나중에 라우트 등록 함수의 이름이 바뀌면 해당 호출 관계만 다시 확인하면 됩니다. 계획의 결과를 재사용하면서도, 실제 구현 판단은 현재 코드와 이번 검증에 근거하게 했습니다.
1.5.6 리뷰에는 지금 변경에서 확인한 검사만
1.5.5에서 구현 메모를 정식 리뷰에 넘기지 않게 해도 이전 검사 결과가 계획의 일반 문장에 남아 있을 수 있었습니다. 예제 계획으로 재현해 보니, 그 문장만 읽은 리뷰어는 이전 코드에서 통과한 검사를 이번 변경의 결과로 해석할 수 있었습니다. 1.5.6에서는 계획에 이미 확인한 근거를 적는 위치와 리뷰에 넘기는 근거를 각각 정했습니다. 1.5.6 변경 및 검증 기록
계획에는 실행할 검사
모든 계획에 범위, 완료 조건, 구현 뒤 실행할 검사를 적습니다. 여러 파일이나 모듈을 거치는 새 기능에는 경로·심볼·이미 확인한 검사 결과를 최대 세 항목의 구현 메모에 따로 둘 수 있습니다. 구현을 시작할 때 이 메모를 현재 코드와 대조합니다. 기존 동작 수정이나 구현 파일 하나에 테스트를 추가하는 작업에는 이전 탐색과 검사 결과를 계획 본문에도 옮기지 않습니다. 1.5.6 릴리스 노트
리뷰에는 현재 검증 상태
리뷰 인계에는 요구사항, 실제 변경 범위, 현재 코드, 그 코드에서 확인한 검사를 적습니다. 계획에서만 읽은 파일 위치나 이전 검사 결과가 다른 곳에 적혀 있어도 리뷰로 가져오지 않습니다. 같은 검사가 현재 변경에도 필요하면 이번 실행 결과를 적고, 아직 실행하지 않았다면 그 상태를 남깁니다. 1.5.6 구현·리뷰 인계 지침
두 도구에서 같은 사례로 확인
새 Codex와 Claude Code 세션에 같은 합성 예제를 줬습니다. 여러 파일의 새 기능, 기존 동작 수정, 구현 파일 하나와 테스트, 오래된 코드 위치, 계획 본문에 이전 검사가 들어 있는 경우까지 다섯 가지에서 계획과 리뷰 인계에 어떤 근거가 들어가는지 확인했습니다. 실제 프로젝트의 작업 시간이나 리뷰 품질은 이 검증에서 측정하지 않았습니다. 합성 예제 검증 기록

댓글
댓글과 반응은 GitHub 계정으로 로그인해 남길 수 있어요.