병렬 서브 에이전트를 '믿는' 것에서 '보는' 것으로 — AI 에이전트의 분기(Fork)를 하나의 타임라인으로 관찰하기

서브 에이전트에게 작업을 나누어 주면 빨라집니다. 논리적으로는 그렇게 됩니다. 하지만 실제로 백그라운드에서 3개, 4개의 에이전트가 돌아가기 시작하면 저는 대개 불안해집니다. 지금 뭘 하고 있는 걸까? 끝난 건지, 막힌 건지. 끝날 때까지 화면을 노려볼지, 아니면 포기하고 커피를 마시러 갈지를 고민하게 됩니다.

병렬화는 보이지 않으면 그저 도박일 뿐입니다.

저는 Andromity라는 오픈소스(MIT) AI 코딩 에이전트를 만들고 있습니다. Andromity에는 병렬 세션과 백그라운드 서브 에이전트 메커니즘이 있어, 태스크를 분기(fork)하여 동시에 실행할 수 있습니다. 그리고 그 모든 움직임을 하나의 타임라인에서 관찰할 수 있는 것이 바로 /waterfall (실시간 실행 워터폴 프로파일러)입니다. 이 글은 '병렬로 실행했을 때 무엇을 볼 수 있고, 그것이 무엇을 변화시키는지'에 대한 이야기입니다.

도입

VS Code 확장:

code --install-extension agenticmarket.andromity-agent

CLI:

curl -fsSL https://raw.githubusercontent.com/agenticmarket/andromity/main/install.sh | bash
# 또는
pipx install andromity

Andromity는 BYOK(자신의 API 키를 사용하는 방식) 방식으로, Claude / GPT / Gemini / DeepSeek / Groq / OpenRouter 등 396개 이상의 모델을 지원합니다. 로컬에서 무료로 사용하고 싶다면 Ollama에서도 작동합니다. 코드는 자신이 선택한 프로바이더에게만 전송되며, API 키는 로컬에 암호화되어 저장됩니다.

분기(Fork)하면 타임라인이 가지를 친다

/waterfall은 실행 중인 에이전트의 움직임을 실시간 타임라인으로 표시합니다. 각 추론 턴 구간, 각 도구 호출에 걸린 시간, 그리고 서브 에이전트로 분기된 위치까지 보여줍니다. 마치 브라우저 개발자 도구의 퍼포먼스 탭을 AI 에이전트에 맞게 재설계한 것과 같습니다.

분기가 일어나면 타임라인 위에 가지가 생깁니다. 부모의 실행이 어디서 나뉘었는지, 분기된 각각의 지점이 무엇을 하고 있는지, 그리고 얼마나 빨리 돌아왔는지를 말입니다. 병렬 실행의 '겹침'이 그대로 형태로 나타납니다.

예시: 리팩토링 작업을 3개로 나눈 날

중간 정도의 리팩토링을 요청했을 때였습니다. 구현 코드 변경, 테스트 추적(follow-up), 문서 업데이트. 성격이 다른 세 가지 작업이 섞여 있었기 때문에 서브 에이전트로 분리하여 병렬로 실행했습니다.

워터폴에서 관찰하니 진행 방식의 차이가 명확하게 드러납니다. 글로 옮기자면 다음과 같은 형태입니다.

# /waterfall — 병렬 리팩토링 (총 약 36초)
0.0s 부모: 추론 → 태스크를 3개로 분할하여 분기(fork)
├─ 구현 분기 0.0s ──────────────── 36.5s
...

• 테스트 담당의 분기는 세밀한 도구 호출을 간헐적으로 진행하며 차근차근 나아갑니다.
• 문서 담당은 빠르게 끝나서 부모 타임라인에 합류합니다.
• 구현 담당 바(bar)의 일부가 묘하게 길게 늘어져 있습니다. 명령어 실행 한 건에서 멈춘 것처럼 보입니다.

총 시간만 보고 있으면 '3개나 병렬인데 생각보다 느하네'로 끝날 수 있는 상황입니다. 하지만 가지별로 보면 이야기는 간단해서, 느린 것은 단 하나뿐입니다. 게다가 그 하나의 더 작은 도구 호출 건이었습니다. 병렬화가 효과를 내지 못한 것이 아니라, 한 곳의 정체가 전체 발목을 잡고 있었던 것입니다.

이것을 보니 기다리는 방식이 달라집니다. 전부를 의심할 필요가 없습니다. 막힌 가지만 보면 되고, 끝난 가지의 성과는 미리 확인해 볼 수 있습니다. '병렬 에이전트가 무엇을 하고 있는지 알 수 없다'는 불안감은 사실 정보의 부재였고, 병렬화 자체의 결함이 아니었다는 것을 그때 깨달았습니다.

계획과 실행은 다른 화면에서 추적할 수 있다

분기의 근거가 되는 계획(plan)은 플래너(planner)에서 추적할 수 있습니다. 태스크가 어떻게 분해되었는지 확인한 후, 실행의 타임라인을 보는 것입니다. 계획과 실제 결과에 대한 대응이 붙기 때문에 '애초에 분할 방식이 잘못된 것인지, 실행 과정이 막힌 것인지'를 구분할 수 있습니다.

모델은 세션별로 전환할 수 있으므로, '빠른 모델로 넓게 시도해 보고', '강력한 모델로 핵심 작업을 수행한다'와 같은 배분도 가능합니다.

병렬로 실행하기 전에, 사소하지만 효과적인 것들

병렬화는 담당 범위를 확장하는 행위이므로, 발밑의 안전장치도 적어두겠습니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

신뢰 모드 (SAFE → TRUST → FULL → YOLO): 폴더를 신뢰하기 전까지는 실행되지 않습니다. 단계적이기 때문에, 병렬로 구동하는 세션마다 맡기는 방식을 변경할 수 있습니다. -
: 턴 단위로 되돌리기(undo)가 가능합니다. git의 히스토리에는 영향을 주지 않습니다. 포크된 지점이 이상한 방향으로 가더라도, 돌아갈 수 있다는 전제가 있으면 맡기기가 쉽습니다. /undo

: 스케줄러 내장 기능입니다. 밤에 백그라운드 세션을 구동해 두는 등의 사용이 가능합니다. /cron

솔직한 한계점 이야기

포크(fork) 수가 늘어나면, 타임라인은 솔직히 말해서 복잡해집니다. 5개나 6개의 가지가 뻗어 나가면, 따라가는 쪽의 인지적 부하가 먼저 한계에 다다릅니다. 게다가 워터폴(waterfall)은 '현재 구동 중인 실행'을 보기 위한 것이지, 과거의 실행을 축적하여 분석하는 본격적인 트레이싱 기반이 아닙니다. 시각화는 하지만, 운영 기반의 대체재가 될 수는 없습니다. 이 경계는 솔직하게 말씀드립니다.

개인적인 의견

저는 병렬화의 병목 현상이 모델의 지능보다는 '사람이 상황을 관찰할 수 없는 것' 쪽에 있다고 생각합니다. 눈에 보이는 병렬화는 쓸 수 있는 병렬화이지만, 보이지 않는 병렬화는 그저 불안감일 뿐입니다. 적어도 제가 개발하면서 포크를 살펴볼 수 있게 된 이후로, 서브 에이전트에게 맡기는 태스크의 크기가 확연히 커졌습니다.

자주 묻는 질문 (FAQ)

Q. /waterfall은 무엇을 표시하나요?

실행 중인 에이전트의 라이브 타임라인입니다. 추론(inference) 턴 구간, 도구 호출별 소요 시간, 그리고 서브 에이전트로 포크된 위치가 하나의 타임라인에 나열됩니다. 병렬로 구동되는 가지들 역시 그대로 가지 형태로 보입니다.

Q. 에이전트 실행이 느릴 때, 원인을 어떻게 찾나요?

/waterfall을 열고 가장 긴 바(bar)를 찾는 것이 빠릅니다. 대부분의 경우 모델 자체가 느린 것이 아니라, 범위가 너무 넓은 검색이나 단 하나의 긴 도구 호출이 전체를 끌어내리고 있는 경우가 많습니다. 병렬 실행이라면, 가지별로 보기 때문에 '느린 것이 어느 포크인지'까지 분리할 수 있습니다.

Q. Andromity는 무료로 사용할 수 있나요?

본체는 MIT 라이선스의 오픈소스라 무료입니다. 모델은 BYOK(Bring Your Own Key, 자신의 API 키를 가져오는 방식)이기 때문에, API 요금은 선택한 프로바이더에 지불하는 비용이 됩니다. 무료로 끝내고 싶다면, Ollama의 로컬 모델로도 구동할 수 있습니다. 그 경우 API 요금은 발생하지 않습니다.

Q. 코드가 외부에 전송되는 것이 걱정됩니다. 개인정보 보호는 어떻게 되나요?

코드가 전송되는 곳은 사용자가 직접 선택한 프로바이더뿐입니다. Ollama로 로컬 실행하면, 코드는 기기 외부로 나가지 않습니다. API 키는 로컬에 암호화되어 저장됩니다. 아울러, 폴더를 신뢰하기 전까지 아무것도 실행되지 않는 신뢰 모드(SAFE → TRUST → FULL → YOLO)도 있습니다.

맺음말

느릴 때 의심해야 할 것은 병렬 전체가 아니라 막혀 있는 한 가지 가지입니다. 그리고 계획(planner)과 실행(waterfall)을 분리하여 추적할 수 있게 되면, 에이전트에게 맡기는 방식 자체가 바뀝니다.

병렬 에이전트를 '왠지 모르게 불안해서' 피하고 있는 사람이 있다면, 한번 살펴보면서 구동해 보세요. GitHub 스타도 환영합니다.

Discussion