10개 이상의 AI 코딩 에이전트를 병렬로 실행해 보았습니다. 병목 현상은 AI가 아니었습니다.
요약
10개 이상의 AI 코딩 에이전트를 병렬로 운영할 때 발생하는 인간의 인지적 병목 현상을 다룹니다. 에이전트의 성능 문제가 아닌, 다수의 세션을 관리하고 컨텍스트를 전환하는 과정에서 발생하는 가시성 부족과 정신적 오버헤드가 핵심 문제입니다.
핵심 포인트
- 에이전트 병렬 실행 시 발생하는 병목은 AI가 아닌 인간의 주의력 한계임
- 다수 세션 관리 시 각 에이전트의 상태를 파악하는 가시성 확보가 어려움
- 잦은 컨텍스트 스위칭으로 인한 정신적 오버헤드가 생산성을 저해함
- 리소스 문제로 인한 다중 기기 사용 시 세션 관리의 복잡성이 증가함
AI 코딩 에이전트(AI coding agents)는 제가 일하는 방식을 바꾸어 놓았습니다.
제가 에이전트를 사용하기 시작했을 때, 워크플로우는 단순했습니다:
에이전트에게 작업을 부여함 → 기다림 → 결과를 검토함 → 계속 진행함.
에이전트 하나를 실행하는 것은 충분히 쉬웠습니다.
그러다 저는 여러 에이전트를 병렬(parallel)로 실행하기 시작했습니다.
처음에는 엄청난 생산성 향상처럼 느껴졌습니다. 서로 다른 에이전트들이 동시에 각기 다른 작업들을 처리할 수 있었습니다:
-
- 한 에이전트는 기능을 구현하고
-
- 다른 에이전트는 버그를 수정하며
-
- 또 다른 에이전트는 기술적 접근 방식을 탐색하고
-
- 또 다른 에이전트는 코드를 리뷰하며
-
- 또 다른 에이전트는 반복적인 작업을 처리합니다.
더 이상 제한 요소는 제가 얼마나 빨리 코드를 작성할 수 있느냐가 아닌 것처럼 보였습니다.
그러다 예상치 못한 일이 발생했습니다.
병목 현상(bottleneck)은 바로 제가 되었습니다.
현재 저의 설정 (My current setup)
저의 워크플로우는 보통 10개 이상의 에이전트가 동시에 실행되는 것을 포함합니다.
그것들은 모두 같은 유형의 에이전트는 아닙니다:
-
- Claude Code
-
- Codex
-
- Kimi
-
- 기타 특정 작업용 에이전트들
그중 절반 이상이 코딩 어시스턴트(coding assistants)이며, 이는 상당한 양의 CPU와 메모리를 소비한다는 것을 의미합니다.
모든 것을 한 대의 기기에서 실행하는 것은 실용적이지 않기 때문에, 저는 여러 대의 기기에 에이전트들을 분산시키고 터미널 세션(terminal sessions)을 통해 원격으로 관리합니다.
이론적으로는 훌륭한 설정처럼 들립니다.
하지만 현실에서는 다른 문제를 야기합니다.
문제는 에이전트를 실행하는 것이 아닙니다. 무슨 일이 일어나고 있는지 아는 것입니다.
많은 에이전트가 실행되고 있을 때, 첫 번째 질문은 더 이상 다음과 같지 않습니다:
"이 에이전트가 작업을 마칠 수 있을까?"
질문은 다음과 같이 변합니다:
"지금 모든 에이전트가 무엇을 하고 있는가?"
저는 결정을 내리는 대신 세션을 확인하는 데 점점 더 많은 시간을 소비하고 있다는 사실을 깨닫기 시작했습니다.
다음과 같은 질문들 말입니다:
-
- 이 에이전트가 아직 작업 중인가?
-
- 이미 끝났는가?
-
- 내 입력을 기다리고 있는가?
-
- 막혀버렸는가?
-
- 이 세션이 여전히 유효한가?
에이전트들은 실행되고 있었지만, 저의 가시성(visibility)은 점점 나빠지고 있었습니다.
컨텍스트 스위칭(Context switching)이 실제 비용이 됩니다
가장 큰 정신적 오버헤드(mental overhead)는 세션 사이를 전환하는 것에서 발생합니다.
새로운 터미널 탭을 열 때마다, 저는 다음과 같은 컨텍스트 (context)를 다시 재구성해야 합니다:
-
- 이 에이전트가 무엇을 작업하고 있었나?
-
- 왜 이 작업을 시작했는가?
-
- 어떤 결정들이 이미 내려졌는가?
-
- 다음에 무엇이 일어나야 하는가?
에이전트가 한두 개라면 관리할 수 있는 수준입니다.
하지만 열 개 이상이 되면, 이는 매우 지치는 일이 됩니다.
문제는 에이전트의 능력이 부족한 것이 아닙니다.
문제는 인간이 여전히 주의력 (attention)의 한계에 갇혀 있다는 점입니다.
여러 대의 기기는 상황을 더 어렵게 만듭니다
코딩 에이전트 (coding agents)는 리소스를 많이 사용하기 때문에, 많은 사람들이 노트북 한 대에서 단순히 10개의 에이전트를 열 수는 없습니다.
저의 워크플로 (workflow)는 여러 대의 기기를 필요로 합니다.
원격 터미널 (remote terminal) 도구들은 이러한 기기들에 연결하는 데 유용하지만, 대부분 터미널 그 자체만을 보여줍니다.
그 도구들은 저에게 다음을 알려주지 않습니다:
-
- 어떤 세션이 활성화되어 있는가
-
- 어떤 세션이 대기 중인가
-
- 어떤 세션이 완료되었는가
-
- 어떤 세션에 주의를 기울여야 하는가
따라서 알 수 있는 유일한 방법은 각 탭을 수동으로 확인하는 것뿐입니다.
열 개의 에이전트는 열 번의 컨텍스트 스위칭 (context switches)을 의미합니다.
tmux는 다른 문제를 해결합니다
저는 tmux와 다른 터미널 멀티플렉서 (terminal multiplexers)를 사용해 보았습니다.
그것들은 매우 훌륭한 도구입니다.
그것들은 중요한 문제를 해결합니다:
어떻게 하면 내 세션들을 유지하고 정리할 수 있을까?
하지만 여러 AI 에이전트를 관리하는 것은 또 다른 문제를 야기합니다:
어떻게 하면 수많은 자율 프로세스 (autonomous processes) 사이에서 나의 주의력을 관리할 수 있을까?
모든 것을 가시적으로 유지하는 것이 항상 더 나은 것은 아닙니다.
활성 세션으로 가득 찬 화면은 또 다른 주의 산만 (distraction)의 원인이 될 수 있습니다.
더 많은 정보가 항상 더 명확함을 의미하지는 않습니다.
우리는 새로운 워크플로 문제에 진입하고 있다고 생각합니다
수년 동안 개발자들은 다음과 같은 요소들을 중심으로 워크플로를 최적화해 왔습니다:
-
- 에디터 (editors)
-
- 터미널 (terminals)
-
- 빌드 시스템 (build systems)
-
- CI 파이프라인 (CI pipelines)
-
- 버전 관리 (version control)
AI 에이전트는 또 다른 계층을 도입합니다:
동시에 실행되는 여러 자율 작업자 (autonomous workers).
이 도전 과제는 전통적인 프로그래밍보다는 작은 팀을 감독하는 것에 점점 더 가까워 보입니다.
이는 에이전트에게 지속적인 감독이 필요해서가 아니라, 인간에게 에이전트들의 현재 상태를 이해할 방법이 필요하기 때문입니다.
다른 사람들은 이 문제를 어떻게 다루고 있는지 궁금합니다
여러 개의 AI 코딩 에이전트 (AI coding agents)를 실행하는 분들께 질문드립니다:
-
- 보통 동시에 몇 개의 에이전트를 실행하시나요?
-
- 주로 CLI 도구, IDE 확장 프로그램 (IDE extensions), 또는 웹 인터페이스 (web interfaces) 중 무엇을 사용하시나요?
-
- 어떤 에이전트가 사용자의 주의를 필요로 하는지 어떻게 파악하시나요?
-
- 무엇이 가장 먼저 한계에 부딪히나요: 컨텍스트 스위칭 (context switching), 승인 (approvals), 아니면 단순히 정신적 과부하 (mental overhead)인가요?
다른 분들이 워크플로 (workflows)를 어떻게 적응시키고 있는지 듣고 싶습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기