개발 일정을 확인하는 자리에서 "AI 코딩 도구로 처리해서 하루 만에 끝났습니다"라는 보고를 받는 일이 늘었습니다. 담당자 입장에서 이 말은 판단하기 어렵습니다. 코드를 직접 읽을 수 없으면 빨라진 것인지 대충 한 것인지 구분할 근거가 없습니다.
이 글은 그 판단에 쓸 기준을 정리합니다. 저희가 AI 코딩 도구에 작업을 맡긴 뒤 결과를 받아 무엇을 확인하는지, 담당자가 개발을 맡길 때 무엇을 물어보면 되는지입니다.
90% 끝난 것처럼 보이는 상태가 제일 위험합니다
여덟 개를 새 방식으로 옮기라고 하면 여섯 개는 깔끔하게 끝내고 두 개는 예전 방식으로 남겨두는 일이 있습니다. 겉으로는 거의 끝난 것처럼 보입니다.
이 상태가 현장에서 어떻게 나타나는지 생각해 보면 문제가 분명해집니다. 화면은 정상이고 시연도 잘 됩니다. 남은 두 개는 평소에 잘 쓰지 않는 조건에 걸려 있어서 몇 달 뒤 특정 거래처의 데이터에서만 잘못된 값이 나옵니다. 그때는 이미 원인을 추적할 사람이 자리에 없습니다.
저희는 이 현상을 이전 글에서 다뤘고, 도구를 어떻게 나눠 쓰는지는 Claude Code vs Codex, 실무에서 둘 다 써보니 이랬습니다에 정리했습니다. 이 글은 그다음 질문을 봅니다. 결과를 받아서 무엇을 확인하는가입니다.
작업을 맡기기 전에 기준선을 남깁니다
작업이 끝난 뒤 "무엇이 바뀌었나"를 판단하려면 시작 시점을 알아야 합니다. 커밋 위치만으로는 부족합니다. 작업 폴더에 이전 작업의 미완성 변경이 남아 있으면, 나중에 변경분을 봐도 어디까지가 원래 있던 것인지 가릴 수 없습니다.
그래서 세 가지를 함께 기록합니다. 현재 커밋 위치, 이미 수정 중이던 파일의 변경 내용, 아직 버전 관리에 들어가지 않은 파일의 상태입니다. 파일 이름만으로는 부족합니다. 같은 파일을 다시 수정하면 이름만 봐서는 누구의 변경인지 모릅니다.
작업 지시에는 다음을 적습니다.
- 수정해도 되는 파일의 범위
- 다른 작업자가 함께 보고 있는 파일이 있는지
- 무엇이 충족되면 완료인지
범위를 정하지 않으면 관련돼 보이는 곳을 넓게 고칩니다. 의도는 나쁘지 않은데 검토할 양이 늘고, 다른 사람의 작업을 덮을 위험이 생깁니다. 실제로 저희 작업 폴더에 다른 곳에서 실행 중이던 에이전트가 조회 결과와 미완성 파일을 쓰고 있던 것을 발견해 중지시킨 적이 있습니다.
시스템 설정이나 전역 환경 설정 변경은 코드 작업의 기본 범위에서 빼둡니다. 필요하면 별도 범위로 따로 합의합니다.
범위를 벗어났을 때 되돌리지 않습니다
범위를 벗어난 변경을 발견했을 때 통째로 되돌리고 싶어집니다. 그러면 그 안에 섞인 기존 작업까지 사라집니다.
먼저 추가 수정을 멈추고, 기준선에 기록해 둔 내용과 대조해 소유권을 가릅니다. 그다음 범위 밖 변경만 분리해 처리합니다. 저희가 여러 작업 폴더를 정리할 때도 같은 순서를 썼습니다. 검증된 것만 통합하고 나머지는 보존 브랜치로 남겼습니다. 지우는 것보다 남기는 쪽이 나중에 덜 곤란합니다.
테스트가 통과했다는 말은 두 가지 뜻일 수 있습니다
변경분에서 보는 것은 세 가지입니다.
| 확인 항목 | 보는 이유 |
|---|---|
| 지정한 범위를 벗어난 파일 | 다른 작업자의 변경을 덮었을 수 있음 |
| 테스트가 삭제·건너뛰기·기대값 완화됐는지 | 구현이 아니라 테스트를 고쳐 통과했을 수 있음 |
| 키·토큰 같은 값이 코드에 들어갔는지 | 저장소에 남으면 회수가 어려움 |
두 번째가 놓치기 쉽습니다. 테스트를 다시 돌려서 통과해도, 그 테스트의 기대값이 잘못된 구현에 맞춰 바뀌었다면 의미가 없습니다. 실행 결과가 아니라 테스트 파일의 변경분을 봐야 합니다.
담당자가 확인할 수 있는 형태로 바꾸면 이렇습니다. "테스트 통과"라는 보고를 받았다면 통과 화면 대신 테스트 파일이 이번에 함께 바뀌었는지를 물어보면 됩니다. 함께 바뀌었다면 왜 바뀌었는지 설명을 들어야 합니다.
세 번째는 사람이 매번 기억하기 어려워서 빌드 절차에 넣어 두었습니다. 문서에 관리자 자격값을 특정 형태로 적는 실수를 빌드 전에 걸러냅니다. 다만 이것은 정해진 변수명과 표기 형태만 보는 좁은 검사입니다. 코드 전체의 비밀값 검토를 대신하지 못하므로 변경분 확인은 따로 합니다.
만든 사람과 검토하는 사람을 나눕니다
작업한 쪽이 자기 결과를 검토하면 세운 전제를 그대로 통과시키기 쉽습니다. 그래서 별도 검토를 붙이고, 검토자는 지적만 하고 고치지 않습니다. 고치는 권한까지 주면 검토와 작업이 섞여 추적이 어려워집니다.
실제로 추가 발견이 나온 사례가 있습니다. 카피를 점검했을 때 한쪽 검토에서만 나온 표기 문제가 있었고, 성능을 점검했을 때는 화면에 쓰지 않는 본문 데이터가 브라우저까지 전달되던 것을 검토 쪽이 짚었습니다. 작업하던 쪽은 보지 못한 것이었습니다.
다만 매번 새로운 것이 나오지는 않습니다. 겹치는 지적이 더 많고, 검토 비용과 절감 시간을 비교한 자료는 저희에게 없습니다. 추가 발견이 실제로 나온 적이 있다는 정도까지가 확인된 사실입니다.
개발을 맡길 때 물어볼 것
절차를 만들어도 특정 상황에서 생략하고 싶어집니다. 변경이 작아 보일 때, 설명이 설득력 있을 때, 이전에 같은 작업을 문제없이 해냈을 때입니다.
기준을 사람의 판단이 아니라 작업의 성격에 두면 매번 다시 고민하지 않아도 됩니다. 되돌리기 어려운가, 여러 곳에 영향을 주는가, 외부로 나가는가로 나눕니다. 자동화 시스템이 외부로 행동할 때의 승인 기준은 AI 자동화에서 사람 승인을 남겨야 하는 7가지 순간에서 다뤘습니다.
담당자가 개발을 맡길 때 물어볼 질문도 같은 틀에서 나옵니다.
- 작업 전 상태를 어떤 형태로 남기는가
- 수정 범위를 사전에 합의하는가
- 테스트 파일이 함께 바뀌었을 때 설명을 받을 수 있는가
- 만든 사람과 검토하는 사람이 분리돼 있는가
AI에게 코드를 맡기는 일의 어려움은 도구의 성능보다 검증 비용에 있습니다. 검증까지 포함한 시간이 직접 하는 시간보다 짧아야 맡길 이유가 생깁니다. 이 계산을 하지 않고 속도만 보면, 일정 안에 끝난 것처럼 보였던 개발이 몇 달 뒤 더 큰 비용으로 돌아옵니다.
