Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

오후 두 시에 디프 다섯 개가 동시에 도착했습니다
이런 환경이 실제로 파는 것은 모델이 아닙니다
격리 부분은 오늘 git만으로 해 볼 수 있습니다
병목은 사라지지 않고 자리를 옮깁니다
그래서 볼 것은 생성 기능이 아니라 선별 기능입니다
다섯 개가 비슷하면 다섯 배를 읽고 한 개를 얻습니다
이 프로젝트의 현재 상태를 있는 그대로 적으면
도구를 깔기 전에 이번 주에 해 볼 실험
정리와 출처

오후 두 시에 디프 다섯 개가 동시에 도착했습니다

같은 이슈를 놓고 에이전트 다섯 개를 동시에 돌렸습니다. 20분 뒤에 다섯 개의 브랜치가 생겼고, 각각 300줄에서 900줄 사이의 변경이 들어 있습니다. 접근 방식은 셋이 비슷하고 둘이 다릅니다. 테스트는 넷이 통과하고 하나는 실패합니다.

여기서 생기는 일은 대개 이렇습니다. 다섯 개를 다 읽는 데 두 시간이 걸립니다. 두 시간 뒤에 하나를 고르는데, 고르고 나면 나머지 넷에서 좋았던 부분이 아깝습니다. 그래서 조금씩 옮겨 붙이다가 결국 여섯 번째 버전을 손으로 만듭니다. 생성에 든 20분은 확실히 줄었고, 그 뒤에 붙은 두 시간 반은 원래 없던 시간입니다.

이 글은 그 두 시간 반이 어디서 오는지에 대한 이야기입니다.

이런 환경이 실제로 파는 것은 모델이 아닙니다

Orca는 이 흐름을 정면으로 겨냥한 도구입니다. 저장소 설명은 스스로를 병렬 에이전트 무리를 다루기 위한 ADE라고 소개하고, 어떤 CLI 에이전트든 사용자 본인의 구독으로 돌린다고 밝힙니다. 즉 모델을 파는 제품이 아닙니다.

README가 첫 번째로 내세우는 기능은 병렬 워크트리입니다. 프롬프트 하나를 여러 에이전트에 뿌리고, 각각을 격리된 git worktree에 넣고, 결과를 비교해 이긴 것을 병합한다고 적혀 있습니다. 나머지 기능도 같은 방향입니다. 디프의 각 줄에 코멘트를 달아 에이전트에게 되돌려 보내기, GitHub과 Linear의 이슈를 앱 안에서 열어 바로 워크트리를 만들기, 원격 서버 위의 워크트리를 SSH로 붙이기, 브라우저에서 UI 요소를 클릭해 그 HTML과 CSS와 잘라낸 스크린샷을 프롬프트에 넣기.

목록을 늘어놓고 보면 공통점이 보입니다. 이 제품이 파는 것은 코드를 만드는 능력이 아니라 만들어진 것을 사람이 감당하는 표면입니다. 격리, 비교, 코멘트, 병합. 정확히 리뷰와 통합의 도구들입니다.

격리 부분은 오늘 git만으로 해 볼 수 있습니다

병렬 에이전트에서 가장 먼저 아픈 곳은 한 디렉터리를 여럿이 건드리는 상황입니다. 이건 git의 기본 기능으로 해결됩니다. 아래는 실제로 실행해 확인한 명령입니다.

# 저장소 안에서, 브랜치를 새로 만들면서 별도 디렉터리를 붙인다
git worktree add -b try/a ../wt-a
git worktree add -b try/b ../wt-b

git worktree list
# /path/main-repo  2072b5c [main]
# /path/wt-a       2072b5c [try/a]
# /path/wt-b       2072b5c [try/b]

각 디렉터리는 파일 트리와 빌드 산출물이 완전히 분리되어 있고, .git 객체 저장소는 하나를 공유합니다. 저장소를 다섯 번 클론하는 것과 결과는 비슷하되 디스크와 페치 시간은 훨씬 적게 듭니다.

정리할 때 걸리는 지점이 하나 있습니다.

git worktree remove ../wt-a
git branch --list
# * main
#   try/a      <- 워크트리는 지웠지만 브랜치는 남아 있다
# + try/b      <- 플러스 표시는 다른 워크트리가 잡고 있다는 뜻

워크트리를 지워도 브랜치는 그대로 남습니다. 실험 브랜치가 쌓이는 원인이 대개 여기입니다. 그리고 플러스 표시가 붙은 브랜치는 다른 워크트리가 체크아웃 중이라 이쪽에서 다시 체크아웃할 수 없습니다. 병렬로 돌리다 보면 반드시 만나는 제약이라 미리 알아 두는 편이 낫습니다.

병목은 사라지지 않고 자리를 옮깁니다

격리를 해결하고 나면 다음 벽이 나옵니다. 생성이 다섯 배 빨라져도 읽는 사람은 한 명입니다.

이 관계는 대기 행렬 이론의 리틀의 법칙 한 줄로 정리됩니다. 시스템 안에 평균적으로 머무는 작업 수를 L, 도착률을 람다, 평균 체류 시간을 W라고 하면 L은 람다와 W의 곱입니다. 뒤집으면 W는 L을 람다로 나눈 값입니다.

에이전트를 다섯 개로 늘린다는 것은 람다를 다섯 배로 올리는 일입니다. 리뷰 처리 능력이 그대로면 시스템 안의 L, 즉 리뷰를 기다리는 디프의 재고가 쌓입니다. 재고가 쌓이면 각 디프의 체류 시간 W가 늘어납니다. 체류 시간이 늘어난 디프는 그 사이에 베이스 브랜치가 움직여서 충돌이 생기고, 다시 고쳐야 하고, 다시 줄을 섭니다.

숫자 없이도 결론은 분명합니다. 리뷰 능력을 함께 올리지 않으면 병렬화는 완료 속도가 아니라 재고를 늘립니다. 오후 두 시의 두 시간 반은 여기서 옵니다.

그래서 볼 것은 생성 기능이 아니라 선별 기능입니다

이 관점으로 다시 보면 병렬 에이전트 도구를 고를 때 물어야 할 질문이 달라집니다. 몇 개를 동시에 돌릴 수 있는지가 아니라, 다섯 개 중 넷을 얼마나 싸게 버릴 수 있는지입니다.

버리는 비용을 낮추는 방법은 셋입니다. 첫째, 읽기 전에 기계가 먼저 떨어뜨리게 합니다. 각 워크트리에서 테스트와 린트를 자동으로 돌려 실패한 것을 리뷰 대상에서 빼는 것으로, 도구 없이도 스크립트로 됩니다. 둘째, 비교를 나란히 놓습니다. 다섯 개를 순서대로 읽으면 앞의 것을 잊지만, 같은 파일의 다섯 버전을 나란히 보면 차이만 남습니다. 셋째, 고친 점을 다시 사람이 옮겨 붙이지 않게 합니다. 디프 위에 코멘트를 달아 그대로 에이전트에게 돌려보내는 기능이 필요한 이유가 이것입니다. 앞서 본 Orca의 기능 목록이 정확히 이 세 가지에 몰려 있습니다.

다시 말해 이런 도구의 가치는 에이전트를 여러 개 돌린다는 데 있지 않습니다. 그건 터미널 다섯 개로도 됩니다. 가치는 넷을 버리는 비용을 낮추는 데 있습니다.

다섯 개가 비슷하면 다섯 배를 읽고 한 개를 얻습니다

여기서 한 겹 더 들어가야 할 것이 있습니다. 팬아웃이 정보를 주려면 후보들이 서로 달라야 합니다. 같은 프롬프트를, 같은 컨텍스트로, 같은 모델에 다섯 번 던지면 대개 대동소이한 답이 다섯 개 나옵니다. 그러면 읽는 비용은 정직하게 다섯 배인데 얻는 정보는 한 개분입니다. 앞의 오후 두 시 장면에서 셋이 비슷했던 이유가 보통 이것입니다.

다양성을 만드는 축은 세 가지입니다. 첫째는 프롬프트입니다. 같은 요구를 던지는 대신 접근 방식을 못 박아 나눕니다. 하나는 기존 추상화를 재사용하게 하고, 하나는 새 모듈을 만들게 하고, 하나는 가장 작은 변경만 하게 하는 식입니다. 이렇게 하면 비교가 구현 취향이 아니라 설계 선택의 비교가 됩니다. 둘째는 컨텍스트 범위입니다. 어떤 후보에게는 관련 파일만 주고 어떤 후보에게는 테스트와 이슈까지 줍니다. 셋째는 실행 주체입니다.

Orca가 특정 모델에 묶이지 않고 터미널에서 도는 CLI 에이전트라면 무엇이든 붙인다고 명시한 점은 세 번째 축에서 의미가 있습니다. 서로 다른 에이전트는 기본 프롬프트와 도구 사용 습관이 달라서, 같은 요구에도 다른 모양의 답을 냅니다. 다만 이건 제품이 가능하게 해 주는 축일 뿐이고, 실제로 다양성을 설계하는 것은 여전히 사람의 일입니다.

이 프로젝트의 현재 상태를 있는 그대로 적으면

과장하지 않기 위해 확인한 사실만 적습니다. 저장소는 2026년 3월 17일에 만들어졌고, 라이선스는 MIT이며, 주 언어는 TypeScript입니다. 데스크톱은 macOS, Windows, Linux를 지원한다고 표시되어 있고 Homebrew 캐스크와 AUR 패키지가 안내되어 있습니다. 모바일 동반 앱은 iOS는 App Store와 TestFlight, 안드로이드는 저장소 릴리스에 올라온 APK로 배포됩니다.

README는 스스로 매일 배포한다고 적고 있고, 그래서 기능 목록이 항상 뒤처져 있으니 릴리스 노트가 진짜 목록이라고 안내합니다. 저는 이 문장을 장점이자 경고로 읽습니다. 만들어진 지 반년이 안 된 데스크톱 앱이 매일 배포된다는 것은, 어제 되던 것이 오늘 다르게 동작할 수 있다는 뜻이기도 합니다. 확인한 시점에 열린 이슈는 3천 건이 넘습니다. 인기 있는 저장소에서 이 숫자 자체가 결함을 뜻하지는 않지만, 성숙도를 대신 말해 주지도 않습니다.

정리하면 이 도구는 쓸 만한지 여부를 남이 대신 판단해 줄 단계에 있지 않습니다. 팀의 코드가 들어가는 환경이므로, 도입한다면 그 판단을 직접 해야 합니다.

도구를 깔기 전에 이번 주에 해 볼 실험

설치 없이 워크플로만 먼저 시험해 보는 방법이 있습니다. 실제로 돈이 드는 부분은 도구가 아니라 리뷰이므로, 리뷰 쪽부터 재면 됩니다.

# 1) 같은 이슈로 브랜치 세 개를 판다 (에이전트를 세 개 돌리든, 사람이 세 번 시도하든)
for n in a b c; do git worktree add -b try/$n ../wt-$n; done

# 2) 사람이 읽기 전에 기계가 먼저 떨어뜨린다
for n in a b c; do
  ( cd ../wt-$n && npm test >/dev/null 2>&1 && echo "PASS $n" || echo "DROP $n" )
done

# 3) 살아남은 것만, 파일 단위로 나란히 본다
git diff try/a try/b -- src/

그리고 두 가지를 기록합니다. 살아남은 후보를 하나 고르는 데 실제로 몇 분이 걸렸는지, 그리고 고른 뒤에 다른 후보에서 손으로 옮겨 붙인 코드가 있었는지. 후자가 있었다면 그 팀에서는 팬아웃이 아직 이득이 아닙니다. 옮겨 붙이는 순간 다섯 개를 만든 이유가 사라지기 때문입니다.

이 측정을 한 주만 해 보면 도구를 살지 말지가 아니라 몇 개까지 뿌리는 것이 우리 팀에 맞는지를 숫자로 말할 수 있게 됩니다. 대개 그 숫자는 다섯보다 작습니다.

정리와 출처

병렬 에이전트 환경은 생성 처리량을 파는 것처럼 보이지만 실제로 파는 것은 선별과 통합의 도구입니다. 그리고 그 도구가 필요한 이유는 생성이 싸질수록 병목이 리뷰로 옮겨 가기 때문입니다. 도구를 고르기 전에 우리 팀의 리뷰 처리 능력을 먼저 재는 편이 순서가 맞습니다.

stablyai/orca 저장소 — 기능 목록, 지원 에이전트, 설치 경로, 라이선스. 이 글의 Orca 관련 서술은 모두 저장소 README와 저장소 메타데이터에서 직접 확인한 것입니다.
git worktree 공식 문서 — 워크트리 추가, 목록, 제거의 정확한 동작
본문의 git 명령은 git 2.50.1에서 실제로 실행해 출력을 확인했습니다. npm test가 들어간 마지막 예시는 프로젝트마다 다르므로 그대로 실행해 보지는 않았습니다.