AI 에이전트를 많이 돌리면 정말 생산성이 올라갈까
이 글은 Addy Osmani의 글을 읽고, 개인적인 해석과 생각을 덧붙여 정리했습니다.
AI 코딩 도구를 쓰다 보면 생산성이 크게 올라간 것처럼 느껴진다.
Codex, Claude Code, Cursor, 각종 에이전트를 동시에 띄워놓고 여러 작업을 병렬로 맡기면 화면은 계속 바쁘게 움직인다. 한쪽에서는 테스트를 고치고 다른 쪽에서는 문서를 정리하고 또 다른 쪽에서는 리팩터링을 시도한다.
그런데 어느 순간 이상한 피로감이 생긴다.
분명 도구는 더 좋아졌고, 이전보다 더 많은 일이 동시에 진행되는 것 같은데, 실제로 내가 이해하고 책임질 수 있는 결과물은 생각보다 많지 않다. 오히려 확인해야 할 변경사항이 쌓이고, 각 에이전트가 어떤 맥락에서 무엇을 바꿨는지 다시 읽어야 하며, 여러 작업을 머릿속에서 병합해야 한다.
여기서 중요한 착각이 하나 있다.
에이전트는 병렬로 실행할 수 있지만, 내 판단력은 병렬로 늘어나지 않는다.
에이전트 수가 아니라 검토 속도가 병목이다
AI 에이전트를 하나 더 시작하는 조작은 간단하다. 프롬프트 하나를 입력하거나 명령 하나를 실행하면 된다. 물론 실제 실행에는 토큰 비용과 자원 제한이 따른다. 여기에 결과물을 검토하는 비용도 더해진다. 코드가 맞는지, 기존 구조와 충돌하지 않는지, 제품 흐름을 해치지 않는지, 나중에 유지보수 가능한지 판단해야 한다.
그 판단은 결국 나를 통과해야 한다.
Addy Osmani는 이를 오케스트레이션 세금(orchestration tax)이라고 설명한다. 한 사람이 여러 에이전트를 감독하는 상황에서는 diff와 PR이 늘어도 최종 검토와 통합 판단은 그 사람에게 모인다. 에이전트 수만큼 검토자의 주의력이 늘어나지는 않는다. 팀에서 검토 책임을 나누는 경우에는 병목의 위치와 크기도 달라질 수 있다.
성능 공학에서 익숙한 말이 있다. 병목이 아닌 부분을 최적화해도 처리량은 늘지 않는다. 에이전트를 더 많이 돌리는 것은 이미 충분히 빨라진 코드 생성 구간을 또 최적화하는 것과 비슷할 수 있다. 시스템 전체의 처리량은 검토와 병합이 허용하는 속도에 맞춰진다.
그래서 AI 에이전트 워크플로우의 병목은 더 이상 “코드를 작성하는 속도”가 아닐 수 있다. 오히려 병목은 내가 검토하고 이해하고 책임질 수 있는 속도에 있다.
바쁨과 생산성은 다르다
AI 도구를 많이 띄워놓으면 바쁘다는 느낌을 받기 쉽다. 터미널은 돌아가고 파일은 수정되고 diff는 쌓이고 PR 초안도 만들어진다. 겉으로 보면 엄청난 생산성이 발생하는 것처럼 보인다.
하지만 진짜 생산성은 다르다.
생산성은 많은 변경사항이 생기는 것이 아니라, 이해 가능한 변경사항이 안전하게 통합되는 것에 가깝다. 내가 제대로 읽지 못한 코드, 왜 바뀌었는지 설명할 수 없는 구조, 테스트는 통과하지만 제품 맥락을 해치는 변경은 생산성이 아니라 부채에 가깝다.
AI가 만든 코드를 충분히 이해하지 못한 채 병합하면 당장은 속도가 빨라 보일 수 있다. 하지만 시간이 지나면 코드베이스가 어떻게 동작하는지에 대한 내 이해가 실제 코드와 어긋날 수 있다. 나중에 문제가 생겼을 때 “이게 왜 이렇게 되어 있지?”라는 질문에 답하기 어려워진다.
이것이 AI 시대의 새로운 인지 부채다.
에이전트를 줄이라는 뜻은 아니다
그렇다고 AI 에이전트를 적게 써야 한다는 말은 아니다. 핵심은 에이전트 수를 무조건 늘리는 것이 아니라, 작업의 성격에 따라 병렬화 가능한 일과 그렇지 않은 일을 구분하는 것이다.
작업 이름만으로 병렬화 여부를 정하기는 어렵다. 테스트 추가도 같은 공통 fixture를 바꾸면 충돌할 수 있고, 복잡한 버그 분석도 서로 다른 가설을 읽기 전용으로 조사하게 하면 병렬화의 이점이 있다.
나는 다음처럼 공유 상태와 결과를 합치는 비용을 먼저 보겠다.
| 작업 관계 | 가능한 진행 방식 | 합치기 전에 확인할 것 |
|---|---|---|
| 서로 다른 파일, 독립된 수용 기준 | 병렬 구현 | 공통 API·설정 의존성이 없는가 |
| 같은 파일이나 공통 타입 수정 | 담당 범위를 나누거나 순차 진행 | 텍스트 충돌 외에 의미상 충돌은 없는가 |
| 한 변경이 다른 변경의 계약을 결정 | 계약부터 합의한 뒤 병렬화 | 반환값·오류·호환성 기준이 같은가 |
| 하나의 장애, 여러 원인 가설 | 가설별 읽기 전용 조사 | 각 결론을 지지·반박하는 증거가 있는가 |
| 같은 설계의 독립 리뷰 | 범위가 명확할 때 병렬 검토 | 여러 에이전트가 같은 전제를 반복했는가 |
별도 브랜치나 worktree는 파일 충돌을 격리할 수 있지만 제품 정책의 충돌까지 해결해주지는 않는다. “서로 다른 파일을 고쳤다”는 필요 조건에 가까울 뿐, 독립성의 충분한 증거는 아니다.
즉, 중요한 것은 “얼마나 많은 에이전트를 돌릴 수 있는가”가 아니라 “얼마나 많은 결과물을 제대로 검토할 수 있는가”다.
대기열을 보면 늘릴 때와 줄일 때가 보인다
나는 실행 중인 에이전트 수보다 리뷰를 기다리는 결과물의 수와 가장 오래 기다린 시간을 먼저 보고 싶다. 시작은 계속되는데 완료가 쌓이지 않는다면 작업 중 재고만 늘고 있는 셈이다.
예를 들어 에이전트들이 하루 8개의 검토 가능한 변경을 만들고 사람이 3개를 통합한다고 가정해보자. 재작업과 취소가 없으면 대기열은 하루 5개씩 늘어난다. 이 숫자는 실측이나 권장 기준이 아니라 유입과 처리 속도를 구분하기 위한 예다.
그렇다고 검토 대기가 생겼다는 이유만으로 무조건 에이전트를 줄이지는 않겠다. 느린 테스트를 독립적으로 실행하거나, 미확인 가설을 조사하는 에이전트는 결과물 적체를 줄이는 데 도움이 될 수도 있다. 병목 뒤에 일을 더 쌓는지, 병목 자체를 해소하는지가 다르다.
동시 작업 수를 조정할 때는 비슷한 작업 묶음에서 다음을 비교하면 된다.
- 요청부터 통합까지 걸린 시간
- 사람이 설명을 읽고 검토·수정하는 데 쓴 시간
- 리뷰 대기 수와 대기 시간
- 병합 후 재수정과 충돌 해결 비용
에이전트를 늘렸을 때 통합량은 그대로인데 대기와 재작업만 늘면 줄일 이유가 생긴다. 반대로 통합량이 늘고 품질이 유지되며 사람의 부담도 감당 가능하면 병렬화가 효과적인 것이다. 작업 난이도와 담당자가 바뀌면 이 비교도 다시 해석해야 한다.
내가 가져가고 싶은 원칙
AI 에이전트를 사용할 때는 다음 원칙이 필요하다고 생각한다.
첫째, 에이전트 수는 실행 가능한 수가 아니라 리뷰 가능한 수에 맞춘다.
도구가 20개의 에이전트를 허용하더라도 내가 두 작업의 결과를 검토하는 동안 나머지 결과가 계속 쌓인다면 병렬 실행 수를 줄여야 한다. 처리량은 에이전트 개수가 아니라 일정 시간 동안 검토하고 통합한 결과로 봐야 한다. 검토 속도에 맞춰 새 작업 투입을 조절하는 것은 분산 시스템의 역압력(backpressure)과 비슷한 접근이다.
둘째, 에이전트에게 작업만 맡기지 말고 증거를 요구한다.
변경에 맞는 테스트 결과나 화면 비교, 핵심 수정 위치, 영향 범위, 미확인 사항을 남기게 해야 한다. 작은 문구 수정마다 모든 산출물을 요구하면 조율 비용이 더 커질 수 있다. 그래야 내 주의력을 단순 확인이 아니라 최종 판단에 사용할 수 있다.
셋째, 복잡한 판단을 여러 작업으로 무작정 분산하지 않는다.
어려운 버그나 설계 문제를 여러 개 동시에 다루면 맥락 전환 비용이 커진다. 다만 한 문제에 대한 독립적인 가설 조사나 대안 비교는 병렬로 맡길 수 있다. 결과를 모아 최종 방향을 판단하는 책임은 분명히 남겨둬야 한다.
넷째, 바쁜 상태를 생산성으로 착각하지 않는다.
진짜 기준은 대시보드가 얼마나 활발한지가 아니라, 내가 이해하고 책임질 수 있는 변경이 얼마나 안전하게 통합되었는지다.
결론
AI 에이전트 시대에 개발자의 역할은 코드를 직접 많이 작성하는 사람에서 여러 생산 흐름을 설계하고 검토하는 사람으로 이동하고 있다.
하지만 그 변화 속에서도 변하지 않는 것이 있다. 무엇을 완료로 인정하고 누가 통합을 책임지는지 정해야 한다는 점이다.
에이전트는 병렬로 일할 수 있다. 테스트는 반복 검증을 도와줄 수 있다. 문서는 맥락을 정리해줄 수 있다.
하지만 무엇을 받아들이고 무엇을 거절하며 어떤 방향으로 시스템을 유지할지는 개발자의 판단에 달려 있다.
그래서 AI를 잘 쓰는 개발자가 된다는 것은 단순히 더 많은 에이전트를 돌리는 것이 아니다.
내 주의력을 병목 자원으로 인정하고 그 병목을 중심으로 작업 시스템을 설계하는 것.
에이전트를 띄우는 것은 누구나 할 수 있다. 그 위에 주의력이라는 직렬 자원을 어떻게 배치할지 설계하는 것이 앞으로 AI와 함께 개발하는 데 필요한 중요한 역량이라고 생각한다.