금요일 오후, 한 엔지니어가 “회원 내보내기에 Excel 지원 추가"라는 issue를 coding agent에 배정하고 회의에 들어갔다. issue는 개발팀이 요구사항을 기록하는 작업표이고, coding agent는 스스로 코드를 읽고 고칠 수 있는 AI 도구다. 한 시간 뒤 돌아오니 pull request, 즉 검토와 병합을 기다리는 한 묶음의 코드 변경이 이미 올라와 있었다. 파일 14개가 바뀌었고, 의존 패키지가 두 개 늘었으며, 테스트는 모두 통과했다. diff(변경 전후를 줄 단위로 비교한 내용)를 열어 화면 세 개 분량을 내려 보다가, 그는 어떤 변경이 요구사항에 필요했고 어떤 변경이 agent가 하는 김에 손댄 것인지 구분할 수 없다는 걸 깨달았다. 결국 그는 PR을 닫고 직접 다시 짰다.
이런 결말은 드물지 않다. 대개 agent가 코드를 잘못 짠 탓이 아니다. 넘겨준 issue에는 “무엇을 이뤄야 하는지"만 있었고, “첫 단계를 마치면 무엇이 되어 있어야 하는지"는 없었다.
이 빈틈은 요즘 더 중요해졌다. 2026년 9월 1일, GitHub은 GitHub에 내장된 AI 코드 리뷰 기능인 Copilot code review가 관리자의 허용을 받으면 pull request를 직접 승인할 수 있고, 그 승인이 저장소(repo)의 필수 리뷰 수에 포함된다고 발표했다. 코드를 쓰는 것도 AI, 승인하는 것도 AI가 될 수 있다면, 사람이 판단할 수 있는 지점은 작업을 넘기는 순간으로 앞당겨진다. 넘기기 전에, 따로 검토할 수 있는 첫 번째 diff를 적을 수 있는가. 적을 수 없다면 그 issue는 아직 agent에게 구현을 맡길 단계가 아니다.
끝내는 것과 검토할 수 있는 것은 다른 일이다
coding agent는 실제로 “끝까지” 할 수 있는 수준에 와 있다. GitHub 문서에 따르면, GitHub의 Copilot coding agent는 클라우드 환경에서 repo를 살펴보고, 변경을 계획하고, 파일을 수정하고, 테스트와 linter(코드 작성 방식을 자동으로 점검하는 도구)를 실행한다. branch(독립된 작업 흐름)를 만들고, commit(변경마다 남기는 기록) 메시지를 쓰고, 푸시한 뒤 마지막으로 pull request를 연다. 또 다른 예는 스타트업 Cognition이 만든 Devin으로, 엔지니어링 작업을 혼자서 완수할 수 있다고 내세우는 coding agent다. Cognition의 CEO 스콧 우(Scott Wu)는 5월 TechCrunch 인터뷰에서 회사 엔지니어들이 커밋한 코드의 89%를 Devin이 커밋했다고 말했고, Devin의 수준을 주니어와 미들 엔지니어 사이 정도로 표현했다.
여기서 issue부터 PR까지 해낼 수 있으니 기능 전체를 맡기면 된다는 결론을 내리기 쉽다. 하지만 이 추론은 한 가지를 놓친다. 끝까지 해내는 것과 검토할 수 있는 형태로 끝내는 것은 다른 일이다.
파일 14개에 걸친 PR은 한 줄도 빠짐없이 맞더라도, 검토하는 사람은 먼저 agent의 생각 흐름을 다시 짜 맞춰야 판단할 수 있다. 다시 짜 맞추지 못하면 남는 선택은 둘뿐이다. 통째로 받아들이거나, 통째로 돌려보내거나. 앞의 선택은 아무도 제대로 이해하지 못한 코드를 main에 넣고, 뒤의 선택은 agent의 한 시간과 자신의 30분을 함께 버린다.
스콧 우는 같은 인터뷰에서 무엇을 할지는 “언제나 사람이 정해야 한다"고 말했다. 문제는 그 결정이 완성된 PR을 보는 순간에만 일어난다면, 사람이 할 수 있는 일은 받아들이거나 거절하는 것뿐이어서 결정이라고 부르기 어렵다는 점이다.
검토 비용은 diff의 범위를 따라간다
코드 한 덩어리를 검토하는 데 드는 수고는 그것이 한꺼번에 몇 가지를 바꾸는지에 달려 있다. 모듈 하나만 바꾸고 테스트 하나가 붙은 diff라면, 검토자는 어디서부터 볼지, 무엇이 보이면 맞는지 안다. 데이터 구조, 인터페이스, 설정, 문서를 동시에 바꾼 diff라면 어느 파일부터 열지 정하는 데만도 시간이 걸리고, 바뀐 곳이 하나 늘 때마다 확인해야 할 전제도 하나씩 는다.
agent는 이 점을 더 두드러지게 한다. 하는 김에 손대는 일이 잦기 때문이다. 테스트를 통과시키려고 테스트 자체를 고치기도 하고, 새 함수를 쓰기 편하게 하려고 옆의 코드까지 리팩터링하기도 한다. 하나하나는 말이 되지만, 모아 놓으면 아무도 요청하지 않았고 아무도 검토하지 않은 설계 결정이 된다.
도구 스스로도 같은 신호를 보낸다. GitHub 문서에는 Copilot coding agent가 작업마다 pull request를 하나만 열고, 한 번에 branch 하나와 repo 하나에서만 작업하며, 세션 한 번에 59분의 상한이 있고, 출력이 부정확하거나 안전하지 않을 수 있으므로 운영 환경에 들이기 전에 검토와 테스트를 거쳐야 한다고 적혀 있다. 이 제약들이 말하는 것은 하나다. 넘기는 작업은 사람이 다 볼 수 있을 만큼 작아야 한다.
첫 번째 diff를 적을 수 없는 작업은 아직 넘기지 않는다
그래서 배정하기 전에 issue에 한 줄을 덧붙인다. “첫 번째 diff는 ＿＿만 바꾸고, ＿＿로 맞다는 것을 증명한다.”
적을 수 있는 예는 이렇다. “내보내기 기능에 Excel 형식을 추가한다. 첫 번째 diff는 exporter 모듈에 xlsx 출력만 더하고, 회원 데이터 10건을 내보낸 뒤 열이 CSV 버전과 일치하는지 확인하는 테스트로 증명한다.” 이런 issue는 넘겨도 되고, 이 diff까지만 하고 멈춘 뒤 사람이 본 다음에 이어 가라고 agent에게 지시할 수 있다.
적을 수 없을 때는 대개 다음 세 가지 중 하나에서 막혀 있다.
- 요구사항이 정해지지 않았다. 제품이 Excel을 원하는지 Google Sheets를 원하는지 아직 정하지 않았으니, agent는 추측할 수밖에 없다.
- 맞는지 틀린지 증명할 수단이 없다. 해당 흐름에 테스트가 없어서 어떤 변경이든 눈으로만 판단해야 한다.
- 변경이 본래 여러 곳에 걸쳐 있다. 권한, 결제, 로그인, 삭제, 데이터 마이그레이션은 한 곳을 건드리면 전체가 움직인다.
이런 경우에도 agent는 쓸모가 있다. 용도를 바꾸면 된다. 코드를 읽게 하고, 영향을 받을 파일을 정리하게 하고, 테스트 초안을 쓰게 하고, 두 가지 방식의 장단점을 비교하게 한다. 이런 결과물은 main에 들어가지 않고, 틀려도 잃는 건 약간의 시간뿐이지만, 사람이 요구사항을 더 빨리 정리하는 데 도움이 된다. 그 한 줄을 적을 수 있게 되면 그때 구현을 넘기면 된다.
이 규칙에도 비용은 있다. 잘게 나눌수록 PR이 늘고 검토 횟수도 는다. 테스트가 충분히 갖춰져 있고 변경 패턴이 반복되는 작업, 예를 들어 의존 패키지를 대량으로 업그레이드하거나 정해진 규칙으로 함수 이름을 일괄 변경하는 일은 한 번에 통째로 넘기는 편이 오히려 효율적이다. 스콧 우가 agent에게 가장 잘 맞는다고 말한 자잘한 유지보수 작업도 대부분 이런 종류다. 판단 기준은 같다. 어떻게 검증할지 말할 수 있는가. “모든 테스트 통과, 빌드 성공, 동작 변화 없음"으로 대량 업그레이드를 증명할 수 있다면 한꺼번에 넘겨도 된다.
AI도 승인할 수 있게 된 뒤 지켜야 할 세 지점
Copilot의 승인 기능은 현재 공개 프리뷰이며 기본값은 꺼져 있다. 관리자가 엔터프라이즈, 조직, repo 단위로 켤 수 있고, repo 관리자는 Copilot이 승인할 수 있는 파일 경로를 지정할 수 있다. 켜 두면 같은 repo 안에 사람이 한 번도 거치지 않는 경로가 생길 수 있다. agent가 쓰고, AI가 승인하고, 병합 조건이 채워진다.
사람을 흐름 안에 남겨 두려면 세 지점을 지킨다.
- agent에게 구현을 맡기는 경로에는 Copilot 승인을 함께 켜지 않는다. 특히 권한, 결제, 데이터 마이그레이션과 관련된 디렉터리에서는 승인을 반드시 사람이 한다.
- issue 템플릿에 “첫 번째 diff” 칸을 추가한다. 이 칸을 채우지 못하는 issue는 자동으로 “조사만"으로 분류한다.
- 한 번에 한 단계씩만 진행시킨다. 첫 번째 diff가 병합된 뒤에야 agent에게 다음 단계를 맡기고, 단계마다 그것을 증명하는 테스트를 붙인다. 휴대폰으로 agent의 다음 단계를 승인하는 일이 잦다면 이 원칙은 더 중요하다. AI가 고친 코드를 휴대폰으로 병합하기 전에, 저장소 규칙에 관문을 맡긴다도 참고할 만하다.
잘게 나누면 다른 이점도 있다. 단계마다 컨텍스트가 짧아지고 실패했을 때 다시 해야 할 범위도 줄어서 비용이 불어나기 어렵다. 그 이유는 긴 AI 작업의 비용은 대부분 재시도와 컨텍스트 재전송에서 나온다에서 설명했다.
다음에 agent에게 배정할 issue에는 먼저 그 한 줄을 덧붙여 보자. 첫 번째 diff는 어디를 바꾸고, 어떤 테스트로 증명하는가. 적을 수 있다면 넘기면 된다. 적을 수 없다면, 그 issue에 필요한 것은 사람이 먼저 요구사항을 끝까지 생각해 보는 일이다.
AI 정리 카드
이 issue를 coding agent에 맡길 수 있는지 AI와 함께 판단하기 이 프롬프트는 먼저 issue의 상황을 확인한 뒤, 따로 검토할 수 있는 첫 번째 diff를 적어 보려 한다. 적을 수 없으면 agent가 지금 할 수 있는 조사 작업을 제안한다.
어떤 issue를 coding agent(예: Copilot coding agent나 Devin)에게 바로 구현하도록 맡겨도 되는지 판단하고 싶다.
판단 기준은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/coding-agents-need-human-checkpoints/
넘겨도 되는 작업은 "따로 검토할 수 있는 첫 번째 diff"를 적을 수 있는 작업뿐이다. 즉 어떤 파일이나 모듈을 바꾸는지, 어떤 테스트로 맞다는 것을 증명하는지 말할 수 있어야 한다.
먼저 나에게 질문 3개를 해 달라:
1. 이 issue의 완료 조건은 무엇이고, 아직 정해지지 않은 제품 결정이 있는가;
2. 관련 코드에 지금 동작을 증명할 수 있는 테스트가 있는가;
3. 이번 변경이 권한, 결제, 로그인, 삭제, 데이터 마이그레이션에 닿는가.
내 답을 바탕으로 다음을 출력해 달라:
- 한 줄 판단: 바로 넘긴다 / 먼저 나눈 뒤 넘긴다 / agent에게는 조사만 맡긴다;
- 넘길 수 있다면: 첫 번째 diff의 범위와 검증용 테스트를 한 문장으로 적어서 issue에 바로 붙일 수 있게 해 달라;
- 아직 안 된다면: 세 가지 이유 중 어디에서 막혔는지, 그리고 agent가 지금 할 수 있는 조사 작업(영향받는 파일 정리, 테스트 초안, 두 방식 비교 등).
존재하지 않는 테스트나 코드 구조를 멋대로 가정하지 말 것. 정보가 부족하면 계속 질문해 달라.
AI의 제안은 질문을 빠짐없이 세우도록 돕는 데 그친다. 넘길지 말지는 그 repo를 책임지는 사람이 정한다.
참고 자료
- GitHub Changelog: Copilot code review can now approve pull requests — https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests (2026-09-01)
- GitHub Docs: GitHub Copilot on GitHub.com — https://docs.github.com/en/copilot/concepts/agents/coding-agent/about-coding-agent [accessed: 2026-10-11]
- TechCrunch: Cognition’s Scott Wu says AI coding agents shouldn’t replace humans — https://techcrunch.com/2026/05/29/cognitions-scott-wu-says-ai-coding-agents-shouldnt-replace-humans/ (2026-05-29)
