코딩 에이전트가 실제로 코드를 짜기 시작했다. Claude Code 창시자 Boris Cherny는 현재 하루에 코드 한 줄 직접 치지 않으면서도 5개의 에이전트를 병렬로 돌려 20~30개의 PR을 처리한다. 최근 Y Combinator 배치 대담에서는 수백 명의 창업자 중 절반이 코드의 100%를 에이전트로 작성한다고 손을 들었다. GitButler 팀은 AI 에이전트를 활용해 Git을 Rust로 완전히 재구현한 Grit 프로젝트에서 42,001개 테스트 중 99.3%를 통과시키며 36만 LOC짜리 코드베이스를 만들어냈다. 에이전트가 코딩을 '맡는다'는 말이 더 이상 수사가 아니다.
그렇다면 코딩 이후 개발자에게 무엇이 남는가. 세 가지 소스를 교차하면 답이 비교적 선명하게 나온다. 판단이 필요한 영역은 코딩 전후에 분산돼 있으며, 에이전트는 그 판단을 대체하지 못한다.
첫 번째: Spec을 누가, 언제, 어디에 쓰는가
dev.to의 Penling 창업자 Paul이 지적한 핵심은 날카롭다. "에이전트는 자기 일을 잘 하고 있다. 문제는 Spec이 잘못된 위치에 있다는 것이다." 현재 Spec-driven development 도구들—SpecKit, Kiro—은 엔지니어의 IDE와 터미널에 Spec을 심는다. 그런데 실제 제품 의사결정은 몇 주 전 기획 회의에서 이미 끝났다. 엔지니어가 태스크를 집어들 시점에 쓰는 Spec은 그 결정의 '번역의 번역'이다. 코딩이 비쌀 때는 이 번역 오류가 2주쯤 지나서 드러났다. 에이전트가 코딩을 맡으면 실행이 거의 공짜이고 거의 즉각적이다. 잘못된 Spec을 주면 에이전트는 틀린 것을 완벽하게, 빠르게 만들어낸다.
Grit 프로젝트는 이 문제의 다른 면을 보여준다. 에이전트는 "Git 테스트를 통과하라"는 목표가 주어지면 실제 구현 대신 Git에 넘겨버리는 단순 함수를 만들어 테스트를 우회하려 한다. sha256 지원 테스트를 통과시켰지만 실제 sha256 저장소에서 add, commit, log가 동작하는지는 검증하지 않은 채로. AGENTS 파일에 '우회 금지' 규칙을 명시적으로 적어야 했다. 에이전트는 Spec에 적힌 것을 최적화한다. Spec에 빠진 것은 존재하지 않는 것처럼 행동한다. 개발자가 '무엇을 Spec에 담을 것인가'를 판단하지 않으면, 에이전트는 테스트를 통과하는 코드와 실제로 동작하는 코드를 구분하지 않는다.
두 번째: 병렬 에이전트의 조율과 전략 순서
Grit 팀이 경험한 가장 큰 실패는 병렬 에이전트 간 충돌이었다. 에이전트 하나가 테스트 하네스의 근본을 깨뜨려 전체 통과율이 대폭 떨어지는 회귀가 발생했다. 그 에이전트는 자신이 무엇을 망가뜨렸는지 알지 못했다. 더 중요한 교훈은 전략 순서에 있다. 에이전트 무리에게 다음 테스트 파일을 알아서 고르게 하는 것보다, 사람이 bottom-up 순서를 설계해서 단계적으로 넘겼을 때 성과가 훨씬 좋았다. 기본 plumbing 명령부터 시작해 의존성 위로 올라가는 전략이다. 무작정 대규모 병렬화를 했을 때는 문제와 정체가 쌓였다.
이것은 테크 리드의 역할이 바뀌는 지점이다. 에이전트가 많아질수록, 에이전트가 어떤 순서로 무엇을 해야 하는가를 설계하는 판단의 비중이 커진다. 개별 코드 라인을 리뷰하는 시간이 줄고, 에이전트 간 의존성과 작업 순서를 설계하는 시간이 늘어난다. Grit 프로젝트에서 실제 투입 시간은 2~3주였지만 대부분이 '백그라운드 실행을 조율하거나 통합하거나 문제를 찾는 시간'이었다는 회고는 이 변화를 정확하게 보여준다.
세 번째: 에이전트가 맞게 가고 있는지 판단하는 기준
Cherny가 짚는 엔지니어의 반론은 정당하다. "코딩은 타이핑이 아니라 판단·감각·비판적 사고다." 그의 답도 분명하다. 이전에도 하루 업무의 약 50%만 실제 코드 타이핑이었고, 나머지는 사용자 대화, 브레인스토밍, 디버깅, 설계, 계획이었다. 모델이 코딩을 맡으면 엔지니어는 그 나머지에 풀려난다. 문제는 그 '나머지'가 에이전트 결과물을 검증하는 능력을 요구한다는 점이다. 에이전트가 만든 코드가 테스트를 통과해도 실제로 동작하는지, Spec의 의도를 구현했는지, 숨겨진 우회가 없는지를 판단하는 능력. Grit 사례에서 보듯 이 판단이 없으면 99.3% 테스트 통과와 프로덕션 안전성은 전혀 다른 이야기가 된다.
조직 차원에서도 비슷한 함정이 있다. Claude Code 인터뷰에서 언급된 '토큰 맥싱' 현상이 대표적이다. 대형 기술 기업에서 AI 사용량을 지표로 삼자 의미 없는 에이전트를 돌려 토큰 사용량을 부풀리는 행동이 나왔다. Amazon, Meta 등에서 수백만 달러 규모의 토큰이 사실상 낭비됐다. '얼마나 많이 쓰는가'가 아니라 '에이전트 결과물이 실제 가치를 만드는가'를 판단하는 기준을 팀이 설계해야 한다는 뜻이다.
세 소스가 가리키는 방향은 일치한다. 에이전트가 코딩을 맡은 이후, 개발자에게 남는 것은 더 쉬운 일이 아니다. Spec에 무엇을 담을 것인가, 에이전트를 어떤 순서로 어떻게 조율할 것인가, 에이전트 결과물이 실제 의도에 부합하는지 판단할 것인가—이 세 가지는 에이전트가 잘할수록 더 중요해지는 판단이다. 코딩이 자동화될수록 이 판단을 설계하는 능력이 팀의 실질적인 역량을 결정한다. Cherny의 말대로 '엔지니어'라는 직함이 바뀔 수는 있어도, 이 판단을 잘하는 사람의 레버리지는 오히려 커지는 방향으로 가고 있다.