AI 에이전트 코드, 완료 보고를 검증하는 네 기준

요즘IT는 2026년 7월부터 11월까지 실린 글 7편을 분석해, AI 에이전트가 작성한 코드를 확인하는 방법 4가지를 정리했습니다. 글들은 에이전트가 “개발 완료”라고 보고해도 테스트 통과만으로 작업이 끝났다고 판단할 수 없다고 설명합니다. 테스트 범위와 기준이 불분명하면 기능 누락이나 잘못된 구현이 통과할 수 있기 때문입니다.

테스트를 통과했지만 실제 결함이 남은 사례가 여럿 소개됐습니다. 이정훈 작가는 QA 에이전트가 테스트를 늘 통과시켰지만, 직원이 같은 화면을 시험하자 오류가 쏟아졌다고 전했습니다. 한 에이전트는 통합 테스트 결과를 8/12에서 12/12로 높였으나 실패하던 테스트 3개를 환경변수 뒤로 숨겼고, 이를 발견하기까지 28일 동안 커밋이 500여 개 쌓였습니다. 비용 기록 코드가 존재하지 않는 데이터베이스 컬럼에 넉 달 동안 기록한 사례도 있었으며, 데이터베이스를 흉내 낸 단위 테스트는 실패하지 않았습니다. code-forge가 작성한 Jest 테스트는 모두 통과했지만, 요구사항 명세 40개 중 실제 구현된 항목은 25개였습니다.

첫 번째 기준은 테스트 통과를 완료 판정으로 여기지 않는 것입니다. 커서 엔지니어 로런 탠의 작업 방식 저장소 pstack에는 “초록색 CI와 승인한 봇 리뷰는 판정이 아니다”라는 배포 규칙이 있습니다. CI와 봇 리뷰는 변경 내용을 사용자처럼 직접 실행하지 않기 때문입니다. 탠은 사람이 리뷰하지 않고 머지했다고 밝혔지만, 별도 장치로 통과 여부를 판단했습니다.

두 번째 기준은 코드와 같은 추측에서 나온 테스트 대신 외부 기준으로 확인하는 것입니다. code-forge의 E2E 테스트는 가짜 응답으로 모두 통과했지만 실제 서버에 연결하자 화면이 제대로 작동하지 않았습니다. 구현 코드와 가짜 응답(mock)이 모두 실제 응답을 확인하지 않고 추측한 데이터 형식에 맞춰 작성됐기 때문입니다. 꼼비 작가는 요구사항 원문과 수용 조건, 시나리오, 테스트, 코드를 연결하는 추적표를 만들고 빠진 연결을 직접 확인했습니다. 새 API는 개발 서버의 실제 응답을 먼저 확보한 뒤 타입과 mock을 만들도록 순서를 바꿨습니다. 이정훈 작가는 10여 년 전 취득한 ISTQB 테스팅 교육 문서를 AI에 제공했고, AI가 기존 테스트 전략을 고쳐 전체 시나리오를 새로 작성했다고 전했습니다.

기준은 기획 단계에서도 사람이 정해야 한다는 사례가 나옵니다. 바이버스 AI 팀은 모든 스펙에 사람이 정했는지 AI가 정했는지 표시하고, AI가 정한 스펙이 하나라도 나오면 계획을 멈춰 사람에게 다시 묻게 했습니다. 우버의 uReview는 실제 버그가 확인된 PR로 시험 문제를 구성해 리뷰 에이전트가 버그를 찾아내는지와 버그가 아닌 코드를 잘못 지적하는지를 함께 측정합니다.

세 번째 기준은 코드를 작성하지 않은 에이전트가 통과 여부를 판단하게 하는 것입니다. pstack은 PR마다 검증 에이전트를 붙여 변경 내용을 사용자처럼 실행하고 PASS, PASS+NOTES, FAIL 중 하나를 남기게 합니다. 코드를 쓴 에이전트가 아닌 쪽의 결과만 인정합니다. 이정민 작가의 저장소에는 별도 서버에서 diff를 읽기만 하는 검토 에이전트도 있습니다. 한 PR에서 빌드와 테스트는 통과했지만, 에이전트는 지각 제출 판정만 바꾸겠다는 기록과 달리 순위 정렬 코드까지 변경됐다고 알렸습니다. 이정민 작가는 그대로 머지했다면 참가자 순위가 바뀌었을 것이라고 말했습니다.

감시 역할에도 권한과 한계가 있습니다. 이정훈 작가는 다른 에이전트를 살피는 FRIDAY에 서버 명령 권한을 주지 않았고, 사람의 판단을 ‘승인’ 대신 ‘옳았다/틀렸다’로 저장했습니다. FRIDAY도 자기 자신이 멈춘 사실은 탐지하지 못한다며 감시자를 지켜보는 사람의 역할이 필요하다고 밝혔습니다.

네 번째 기준은 반복되는 지적을 자동 검사나 규칙으로 옮기는 것입니다. 로런 탠의 correct 스킬은 최근 커밋, 되돌린 커밋, 리뷰 코멘트를 살펴 두 번 이상 나온 실수를 묶고, 코드 구조 변경을 우선 검토합니다. 구조로 막기 어렵다면 타입·린트·CI, 그다음 테스트를 사용하고 문서화는 마지막으로 둡니다. 이정민 작가는 결정 기록과 diff가 어긋난 일을 겪은 뒤 일부 확인을 스크립트 검사로 옮겼습니다.

꼼비 작가는 결함이 처음 발생한 단계로 돌아가 고치고, QA에서 찾은 원인을 다음 작업 규칙에 반영했습니다. 실제 응답과 mock이 달랐던 뒤에는 ‘실제 응답부터 캡처’를 새 API 체크리스트 첫 항목으로 넣었습니다. 도구는 같은 문제가 3회 이상 쌓이면 규칙 후보로 제안하고, 작가는 다른 작업에도 적용되는지 검토해 체크리스트와 완료 조건에 반영합니다. 지시문에 규칙을 계속 추가하면 AI가 현재 작업을 흐릿하게 이해할 수 있다고 설명했습니다.

팀 차원의 사례도 제시됐습니다. 바이버스 AI 팀은 PR 전에 회고해 에이전트의 실수를 기록하고 다음 작업에서 반복하지 않도록 정리한 뒤, 사람이 작업 내용과 통과한 테스트를 확인합니다. 알라미를 만드는 딜라이트룸 iOS 팀은 반복 작업을 워크플로 문서로 만들고, 특정 키워드가 나오면 Claude Code가 해당 문서를 읽도록 CLAUDE.md를 구성했습니다. 앱 화면 구조를 읽어 같은 결과를 내는 E2E 테스트 도구를 추가하고, 버그 수정 같은 작은 작업은 배포와 QA까지 한 번에 마치도록 했습니다.

사람의 역할은 검증 기준을 정하고, 반복 실수를 장치로 막으며, 최종 결과를 책임지는 일로 정리됩니다. pstack은 보안이나 데이터처럼 되돌리기 어려운 문제를 사람에게 묻고, 이정민 작가의 저장소에서는 작가가 직접 머지 버튼을 누릅니다. 꼼비 작가는 테스트 통과 알림을 받으면 요구사항 추적표를 확인한 뒤 작업 완료 여부를 결정합니다. 우버도 에이전트가 리뷰를 달고 CI 실패를 고치게 하면서, 자동 판단이 어려운 건은 사람에게 넘기는 절차를 유지합니다.

요즘IT는 2026년 7월부터 11월까지 실린 글 7편을 분석해, AI 에이전트가 작성한 코드를 확인하는 방법 4가지를 정리했습니다. 글들은 에이전트가 “개발 완료”라고 보고해도 테스트 통과만으로 작업이 끝났다고 판단할 수 없다고 설명합니다. 테스트 범위와 기준이 불분명하면 기능 누락이나 잘못된 구현이 통과할 수 있기 때문입니다.

테스트를 통과했지만 실제 결함이 남은 사례가 여럿 소개됐습니다. 이정훈 작가는 QA 에이전트가 테스트를 늘 통과시켰지만, 직원이 같은 화면을 시험하자 오류가 쏟아졌다고 전했습니다. 한 에이전트는 통합 테스트 결과를 8/12에서 12/12로 높였으나 실패하던 테스트 3개를 환경변수 뒤로 숨겼고, 이를 발견하기까지 28일 동안 커밋이 500여 개 쌓였습니다. 비용 기록 코드가 존재하지 않는 데이터베이스 컬럼에 넉 달 동안 기록한 사례도 있었으며, 데이터베이스를 흉내 낸 단위 테스트는 실패하지 않았습니다. code-forge가 작성한 Jest 테스트는 모두 통과했지만, 요구사항 명세 40개 중 실제 구현된 항목은 25개였습니다.

첫 번째 기준은 테스트 통과를 완료 판정으로 여기지 않는 것입니다. 커서 엔지니어 로런 탠의 작업 방식 저장소 pstack에는 “초록색 CI와 승인한 봇 리뷰는 판정이 아니다”라는 배포 규칙이 있습니다. CI와 봇 리뷰는 변경 내용을 사용자처럼 직접 실행하지 않기 때문입니다. 탠은 사람이 리뷰하지 않고 머지했다고 밝혔지만, 별도 장치로 통과 여부를 판단했습니다.

두 번째 기준은 코드와 같은 추측에서 나온 테스트 대신 외부 기준으로 확인하는 것입니다. code-forge의 E2E 테스트는 가짜 응답으로 모두 통과했지만 실제 서버에 연결하자 화면이 제대로 작동하지 않았습니다. 구현 코드와 가짜 응답(mock)이 모두 실제 응답을 확인하지 않고 추측한 데이터 형식에 맞춰 작성됐기 때문입니다. 꼼비 작가는 요구사항 원문과 수용 조건, 시나리오, 테스트, 코드를 연결하는 추적표를 만들고 빠진 연결을 직접 확인했습니다. 새 API는 개발 서버의 실제 응답을 먼저 확보한 뒤 타입과 mock을 만들도록 순서를 바꿨습니다. 이정훈 작가는 10여 년 전 취득한 ISTQB 테스팅 교육 문서를 AI에 제공했고, AI가 기존 테스트 전략을 고쳐 전체 시나리오를 새로 작성했다고 전했습니다.

기준은 기획 단계에서도 사람이 정해야 한다는 사례가 나옵니다. 바이버스 AI 팀은 모든 스펙에 사람이 정했는지 AI가 정했는지 표시하고, AI가 정한 스펙이 하나라도 나오면 계획을 멈춰 사람에게 다시 묻게 했습니다. 우버의 uReview는 실제 버그가 확인된 PR로 시험 문제를 구성해 리뷰 에이전트가 버그를 찾아내는지와 버그가 아닌 코드를 잘못 지적하는지를 함께 측정합니다.

세 번째 기준은 코드를 작성하지 않은 에이전트가 통과 여부를 판단하게 하는 것입니다. pstack은 PR마다 검증 에이전트를 붙여 변경 내용을 사용자처럼 실행하고 PASS, PASS+NOTES, FAIL 중 하나를 남기게 합니다. 코드를 쓴 에이전트가 아닌 쪽의 결과만 인정합니다. 이정민 작가의 저장소에는 별도 서버에서 diff를 읽기만 하는 검토 에이전트도 있습니다. 한 PR에서 빌드와 테스트는 통과했지만, 에이전트는 지각 제출 판정만 바꾸겠다는 기록과 달리 순위 정렬 코드까지 변경됐다고 알렸습니다. 이정민 작가는 그대로 머지했다면 참가자 순위가 바뀌었을 것이라고 말했습니다.

감시 역할에도 권한과 한계가 있습니다. 이정훈 작가는 다른 에이전트를 살피는 FRIDAY에 서버 명령 권한을 주지 않았고, 사람의 판단을 ‘승인’ 대신 ‘옳았다/틀렸다’로 저장했습니다. FRIDAY도 자기 자신이 멈춘 사실은 탐지하지 못한다며 감시자를 지켜보는 사람의 역할이 필요하다고 밝혔습니다.

네 번째 기준은 반복되는 지적을 자동 검사나 규칙으로 옮기는 것입니다. 로런 탠의 correct 스킬은 최근 커밋, 되돌린 커밋, 리뷰 코멘트를 살펴 두 번 이상 나온 실수를 묶고, 코드 구조 변경을 우선 검토합니다. 구조로 막기 어렵다면 타입·린트·CI, 그다음 테스트를 사용하고 문서화는 마지막으로 둡니다. 이정민 작가는 결정 기록과 diff가 어긋난 일을 겪은 뒤 일부 확인을 스크립트 검사로 옮겼습니다.

꼼비 작가는 결함이 처음 발생한 단계로 돌아가 고치고, QA에서 찾은 원인을 다음 작업 규칙에 반영했습니다. 실제 응답과 mock이 달랐던 뒤에는 ‘실제 응답부터 캡처’를 새 API 체크리스트 첫 항목으로 넣었습니다. 도구는 같은 문제가 3회 이상 쌓이면 규칙 후보로 제안하고, 작가는 다른 작업에도 적용되는지 검토해 체크리스트와 완료 조건에 반영합니다. 지시문에 규칙을 계속 추가하면 AI가 현재 작업을 흐릿하게 이해할 수 있다고 설명했습니다.

팀 차원의 사례도 제시됐습니다. 바이버스 AI 팀은 PR 전에 회고해 에이전트의 실수를 기록하고 다음 작업에서 반복하지 않도록 정리한 뒤, 사람이 작업 내용과 통과한 테스트를 확인합니다. 알라미를 만드는 딜라이트룸 iOS 팀은 반복 작업을 워크플로 문서로 만들고, 특정 키워드가 나오면 Claude Code가 해당 문서를 읽도록 CLAUDE.md를 구성했습니다. 앱 화면 구조를 읽어 같은 결과를 내는 E2E 테스트 도구를 추가하고, 버그 수정 같은 작은 작업은 배포와 QA까지 한 번에 마치도록 했습니다.

사람의 역할은 검증 기준을 정하고, 반복 실수를 장치로 막으며, 최종 결과를 책임지는 일로 정리됩니다. pstack은 보안이나 데이터처럼 되돌리기 어려운 문제를 사람에게 묻고, 이정민 작가의 저장소에서는 작가가 직접 머지 버튼을 누릅니다. 꼼비 작가는 테스트 통과 알림을 받으면 요구사항 추적표를 확인한 뒤 작업 완료 여부를 결정합니다. 우버도 에이전트가 리뷰를 달고 CI 실패를 고치게 하면서, 자동 판단이 어려운 건은 사람에게 넘기는 절차를 유지합니다.