코딩 에이전트를 붙인 팀에서 같은 장면이 반복된다. 한 사람이 에이전트 여러 개를 동시에 돌리는데, 그렇게 쏟아진 변경분(diff)은 한 사람이 다 읽지 못한다. 생성은 빨라졌지만 그 코드를 읽고 옳고 그름을 판정하는 사람의 속도는 그대로다. 제약은 모델 성능에서 사람의 검토 용량으로 옮겨갔다.
이번 달 도구들은 이 전제를 그대로 제품에 새겼다. GitHub는 6월 2일 Build에서 Copilot 앱을 기술 프리뷰로 공개했다. 에디터 확장이 아니라 별도 데스크톱 앱으로, 에이전트 작업을 "감독하고 검증하는" 자리다. 세션마다 격리된 git worktree(브랜치의 실제 사본)에서 돌고, 'My Work' 화면에 여러 저장소의 진행 중 작업이 모인다. 'Agent Merge'는 CI를 지켜보고 리뷰어를 추적해 조건이 맞으면 병합까지 끌고 간다. 사람은 코드를 치는 자리가 아니라 여러 에이전트를 지켜보는 자리에 앉는다.
생성 쪽은 계속 싸지고 빨라진다. Google은 I/O 2026에서 Gemini 3.5 Flash를 내놨고, 작년 Pro급 성능을 flash 속도로 낸다고 밝혔다. 한쪽에서 코드가 더 빠르고 싸게 나올수록, 그것을 읽는 사람의 한계는 더 도드라진다.
코드는 사람이 다 읽지 못하는 속도로 쌓인다
The New Stack의 진단은 건조하다. AI는 사람이 읽을 수 있는 속도보다 빠르게 코드를 만들고, 그 읽기를 또 다른 AI에게 맡기는 것은 근본 문제를 풀지 못한다. 검토를 다른 모델에 위임하면 "그 검토는 누가 검토하나"라는 같은 질문이 한 단계 뒤로 밀릴 뿐이다. GitHub가 예고한 에이전트 코드량 30배 시나리오에서, 코드 뒤에 선 검토자는 그 양에 깔린다.
검토를 코드 뒤에 두면 늦는다
해법은 검토 인원을 늘리거나 AI에 AI를 검토시키는 것이 아니다. 사람의 검문 지점을 코드가 쓰이기 전으로 당기는 것이다. 무엇을, 왜, 어떤 제약과 합격 기준으로 만들지를 명세 단계에서 합의하면, 에이전트가 만든 결과는 그 기준에 맞는지만 빠르게 판정하면 된다. Copilot 앱이 계획과 PR을 사람이 "편집·재정렬·승인·방향 수정"하도록 펼쳐 두는 것도 같은 방향이다. 판단의 자리가 "이 diff가 통과했나"에서 "이 작업이 검토 가능한 명세로 쪼개졌나"로 옮겨간다.
코드 앞에서 사람이 합의해 둘 것은 네 가지다.
- 의도: 이 변경이 풀려는 문제와 풀지 않을 문제
- 명세: 입출력과 경계 조건
- 제약: 건드리면 안 되는 것, 지켜야 할 규칙
- 합격 기준: 무엇을 보면 "됐다"고 말할지
옮겨간 일은 새 역량을 요구한다
코드 앞 검토에도 비용이 있다. 명세를 잘게 쪼개고 합격 기준을 미리 적는 일은, 막연한 지시를 던지고 결과를 기다리는 것보다 품이 든다. 명세가 부실하면 격리된 worktree에서 자율로 돈 에이전트는 빠르게, 그러나 엉뚱하게 완성한다. 그래서 새 제약은 모델 접근권이 아니라 작업을 검토 가능한 단위로 쪼개고 결과를 빠르게 판정하는 사람의 역량이다. 이 역량은 모델과 달리 약관 변경이나 수출통제로 꺼지지 않고, 훈련으로 길러진다.
조녁컴퍼니가 AX·개발 교육에서 먼저 다루는 것도 더 빨리 코드를 만드는 법이 아니라, 일을 명세로 나누고 에이전트의 결과를 판정하는 법이다. 도구가 사람을 타이피스트가 아니라 검토자로 가정하기 시작했다면, 교육도 그 자리에 맞춰야 한다. 사업영역 →