AI 에이전트를 많이 돌리면 정말 생산성이 올라갈까
이 글은 Addy Osmani의 글을 읽고, 개인적인 해석과 생각을 덧붙여 정리했습니다.
AI 코딩 도구를 쓰다 보면 생산성이 크게 올라간 것처럼 느껴진다.
Codex, Claude Code, Cursor, 각종 에이전트를 동시에 띄워놓고 여러 작업을 병렬로 맡기면 화면은 계속 바쁘게 움직인다. 한쪽에서는 테스트를 고치고, 다른 쪽에서는 문서를 정리하고, 또 다른 쪽에서는 리팩터링을 시도한다.
그런데 어느 순간 이상한 피로감이 생긴다.
분명 도구는 더 좋아졌고, 이전보다 더 많은 일이 동시에 진행되는 것 같은데, 실제로 내가 이해하고 책임질 수 있는 결과물은 생각보다 많지 않다. 오히려 확인해야 할 변경사항이 쌓이고, 각 에이전트가 어떤 맥락에서 무엇을 바꿨는지 다시 읽어야 하며, 여러 작업을 머릿속에서 병합해야 한다.
여기서 중요한 착각이 하나 있다.
에이전트는 병렬로 실행할 수 있지만, 내 판단력은 병렬로 늘어나지 않는다.
에이전트 수가 아니라 검토 속도가 병목이다
AI 에이전트를 하나 더 실행하는 비용은 매우 낮다. 프롬프트 하나를 입력하거나 명령 하나를 실행하면 된다. 하지만 그 결과물을 검토하는 비용은 낮지 않다. 코드가 맞는지, 기존 구조와 충돌하지 않는지, 제품 흐름을 해치지 않는지, 나중에 유지보수 가능한지 판단해야 한다.
그 판단은 결국 나를 통과해야 한다.
Addy Osmani는 이를 오케스트레이션 세금(orchestration tax)이라고 부른다. 에이전트를 더 많이 띄울수록 생산되는 diff와 PR은 늘지만, 그것을 읽고 합치고 책임지는 일은 여전히 한 사람의 머리를 거쳐야 한다. 인지 대역폭은 병렬화되지 않는다.
성능 공학에서 익숙한 말이 있다. 병목이 아닌 부분을 최적화해도 처리량은 늘지 않는다. 에이전트를 더 많이 돌리는 것은 코드 생성이라는, 이미 충분히 빨라진 구간을 또 최적화하는 것과 비슷할 수 있다. 시스템 전체의 처리량은 결국 검토와 병합이 허용하는 속도에 맞춰진다.
그래서 AI 에이전트 워크플로우의 병목은 더 이상 “코드를 작성하는 속도”가 아닐 수 있다. 오히려 병목은 “내가 검토하고 이해하고 책임질 수 있는 속도”에 있다.
바쁨과 생산성은 다르다
AI 도구를 많이 띄워놓으면 바쁘다는 느낌을 받기 쉽다. 터미널은 돌아가고, 파일은 수정되고, diff는 쌓이고, PR 초안도 만들어진다. 겉으로 보면 엄청난 생산성이 발생하는 것처럼 보인다.
하지만 진짜 생산성은 다르다.
생산성은 많은 변경사항이 생기는 것이 아니라, 이해 가능한 변경사항이 안전하게 통합되는 것에 가깝다. 내가 제대로 읽지 못한 코드, 왜 바뀌었는지 설명할 수 없는 구조, 테스트는 통과하지만 제품 맥락을 해치는 변경은 생산성이 아니라 부채에 가깝다.
AI가 만든 코드를 충분히 이해하지 못한 채 병합하면 당장은 속도가 빨라 보일 수 있다. 하지만 시간이 지나면 코드베이스에 대한 내 mental model이 무너진다. 나중에 문제가 생겼을 때 “이게 왜 이렇게 되어 있지?”라는 질문에 답하지 못하게 된다.
이것이 AI 시대의 새로운 인지 부채다.
에이전트를 줄이라는 뜻은 아니다
그렇다고 AI 에이전트를 적게 써야 한다는 말은 아니다. 핵심은 에이전트 수를 무조건 늘리는 것이 아니라, 작업의 성격에 따라 병렬화 가능한 일과 그렇지 않은 일을 구분하는 것이다.
예를 들어 테스트 추가, 문서 정리, 타입 보강, 반복적인 리팩터링, 기존 패턴을 따르는 UI 수정은 에이전트에게 맡기기 좋다. 이런 작업은 결과를 검증하기 쉽고, 실패하더라도 영향 범위를 좁히기 쉽다.
반대로 아키텍처 설계, 복잡한 버그 원인 분석, 도메인 정책 판단, 사용자 흐름을 바꾸는 결정은 다르다. 이런 작업은 코드 생산보다 판단 자체가 핵심이다. 이 영역을 여러 에이전트에게 동시에 던지면 생산성이 올라가기보다 내 판단력이 더 빨리 소모될 가능성이 크다.
즉, 중요한 것은 “얼마나 많은 에이전트를 돌릴 수 있는가”가 아니라 “얼마나 많은 결과물을 제대로 검토할 수 있는가”다.
내 주의력을 시스템의 병목으로 인정하기
개발자는 시스템의 병목을 찾는 데 익숙하다. 서버 처리량, DB 쿼리, 네트워크 지연, 렌더링 비용은 분석하면서 정작 자신의 주의력은 무한한 자원처럼 다루는 경우가 많다.
하지만 AI 에이전트 워크플로우에서는 내 주의력이 가장 희소한 자원이다.
에이전트가 만든 결과물을 검토하려면 컨텍스트를 다시 로드해야 한다. 어떤 작업을 맡겼는지, 어떤 파일을 바꿨는지, 왜 그렇게 바꿨는지, 다른 작업과 충돌하지 않는지 확인해야 한다. 에이전트가 다섯 개라면 단순히 일이 다섯 배가 되는 것이 아니라, 다섯 개의 맥락을 계속 전환해야 한다.
이 비용을 무시하면 결국 둘 중 하나가 된다.
첫째, 리뷰가 얕아진다.
둘째, 이해하지 못한 코드를 받아들이게 된다.
둘 다 위험하다.
Osmani가 말하듯, 때로는 가장 레버리지가 큰 선택이 오케스트레이션을 멈추고 한 문제에 깊게 붙는 것일 수도 있다. 에이전트를 많이 띄우는 것이 일이 아니라, 일 주변의 오버헤드가 될 수 있다.
내가 가져가고 싶은 원칙
AI 에이전트를 사용할 때는 다음 원칙이 필요하다고 생각한다.
첫째, 에이전트 수는 실행 가능한 수가 아니라 리뷰 가능한 수에 맞춘다.
도구가 20개의 에이전트를 허용하더라도 내가 제대로 검토할 수 있는 수가 2개라면, 실제 병렬 처리량은 2개에 가깝다. 에이전트 생산 속도에 맞춰 리뷰 대기열이 쌓이지 않도록 backpressure를 두는 것이, 분산 시스템을 설계할 때와 같은 종류의 일이다.
둘째, 에이전트에게 작업만 맡기지 말고 증거를 요구한다.
테스트 결과, 변경 전후 스크린샷, 수정 파일 목록, 영향 범위, 리스크, 미확인 사항을 함께 남기게 해야 한다. 그래야 내 주의력을 단순 확인이 아니라 최종 판단에 사용할 수 있다.
셋째, 복잡한 판단이 필요한 작업은 병렬화하지 않는다.
어려운 버그나 설계 문제는 여러 개를 동시에 돌리는 것보다 하나의 문제를 깊게 붙잡는 편이 낫다. AI가 도와줄 수는 있지만, 판단의 중심까지 넘기면 안 된다.
넷째, 바쁜 상태를 생산성으로 착각하지 않는다.
진짜 기준은 대시보드가 얼마나 활발한지가 아니라, 내가 이해하고 책임질 수 있는 변경이 얼마나 안전하게 통합되었는지다.
결론
AI 에이전트 시대에 개발자의 역할은 단순히 코드를 직접 많이 작성하는 사람에서, 여러 생산 흐름을 설계하고 검토하는 사람으로 이동하고 있다.
하지만 그 변화 속에서도 변하지 않는 것이 있다.
최종 판단은 여전히 사람에게 남아 있다는 점이다.
에이전트는 병렬로 일할 수 있다.
테스트는 반복 검증을 도와줄 수 있다.
문서는 맥락을 정리해줄 수 있다.
하지만 무엇을 받아들이고, 무엇을 거절하며, 어떤 방향으로 시스템을 유지할지는 결국 개발자의 판단에 달려 있다.
그래서 AI를 잘 쓰는 개발자가 된다는 것은 단순히 더 많은 에이전트를 돌리는 것이 아니다.
내 주의력을 병목 자원으로 인정하고, 그 병목을 중심으로 작업 시스템을 설계하는 것.
에이전트를 띄우는 것은 누구나 할 수 있다. 그 위에 주의력이라는 직렬 자원을 어떻게 배치할지 설계하는 것이, 앞으로 AI와 함께 개발하는 데 필요한 중요한 역량이라고 생각한다.