서브에이전트 스포닝과 Team OS

에이전트를 여러 개 호출하는 것과 팀으로 일하게 만드는 것

2026.03.21

얼마 전 oh-my-claudecode를 만든 허예찬님이 LinkedIn에 하네스 무용론에 대한 글을 올렸습니다. 모델이 좋아져도 하네스가 필요한 이유, 특히 서브에이전트 스포닝과 팀 오케스트레이션이 근본적으로 다르다는 이야기였는데요, 읽으면서 저도 평소 느끼던 것들이 정리되는 기분이었습니다.

그 글을 보고, 제 나름대로 생각을 풀어본 글입니다.

Team OS

Team OS는 널리 쓰이는 표현은 아니고, 허예찬님이 oh-my-codex에서 사용하는 표현입니다. 저도 이 개념이 적합하다고 생각해서 이 글에서도 같은 의미로 씁니다.

서브에이전트 스포닝

서브에이전트 구조는 분명 장점이 있습니다. 큰 문제를 쪼개서 각 에이전트가 좁은 범위에서 판단하게 하면 추론 품질이 올라가고, 독립적인 작업은 병렬로 돌릴 수 있어서 전체 시간도 줄어듭니다. 그래서 대부분의 멀티에이전트 시스템은 비슷한 형태를 띱니다. 메인 에이전트가 문제를 보고, 작업을 나누고, 하위 에이전트에게 할당한 뒤, 결과를 합치는 구조죠.

실용적입니다. 다만 이 구조에서 하위 에이전트는 자기에게 전달된 좁은 범위 안에서만 움직이고, 전체 상태를 알지 못하고, 다른 하위 에이전트와 직접 이야기하지도 않습니다. 결과를 내면 빠지고요. 전체 그림을 들고 있는 건 메인 에이전트 하나뿐이라, 결국 일어나는 일은 협업보다는 일부를 떼서 맡기고 요약된 결과를 돌려받는 것에 가깝습니다.

전체 상태를 아는 건 상위 에이전트뿐이라 병목이 거기 몰리고, 하위 에이전트끼리 실행 중에 서로 조정하기보다 마지막에 한꺼번에 맞추는 경우가 많습니다. 어떤 가정으로 작업했는지, 어디서 막혔는지도 잘 안 남고, 프로세스가 끊기면 처음부터 다시 돌려야 하는 상황도 자주 생겼습니다.

이걸 팀이라고 부르기는 어렵다고 생각합니다.

스포닝에서 팀으로

스포닝에서 가장 아쉬운 건 일이 상위 에이전트의 머릿속에만 있다는 점입니다. 작업을 나누고 결과를 받아오는 건 잘 되는데, 전체적으로 어디까지 왔는지, 뭐가 결정됐는지는 그 에이전트만 알고 있거든요.

Team OS는 이걸 바깥으로 꺼냅니다. 공유 계획이나 작업 상태, 결정 기록 같은 것들이 특정 에이전트 안이 아니라 밖에 존재하는 거죠. 그래야 역할이 바뀌거나 중간에 끊겨도 이어서 할 수 있습니다. 검증도 마찬가지입니다. 스포닝에서는 결과를 만들면 거기서 끝이지만, Team OS에서는 검토와 수정이 작업 흐름 안에서 반복됩니다.

비유하자면, 서브에이전트 스포닝이 새 프로세스를 하나 띄우는 행위라면, Team OS는 여러 프로세스가 협력할 수 있도록 규약과 상태와 수명주기를 관리하는 계층에 가깝습니다.

실제로 작업이 한 번에 깔끔하게 끝나는 경우는 드뭅니다. 중간에 오류가 나거나, 방향이 바뀌거나, 일부만 끝난 채로 멈추는 게 보통인데요, 이때 처음부터 다시 돌려야 한다면 에이전트를 아무리 많이 붙여도 소용이 없습니다. 어디까지 했는지 알 수 있어야 시스템이 오래 돌아갑니다.

도구들에서 보이는 차이

이 차이를 가장 직접적으로 볼 수 있는 곳이 AI 코딩 에이전트 하네스들입니다.

oh-my-codex는 이 글에서 말하는 Team OS에 가장 가까운 도구입니다. 각 워커가 독립적인 CLI 프로세스로 tmux에 뜨고, 워커마다 별도의 git worktree를 가집니다. 파일 충돌 없이 병렬 작업이 되고, 중간에 끊겨도 tmux 세션이 살아 있어서 이어서 할 수 있습니다. Codex CLI가 headless 모드와 구조화된 출력을 지원하기 때문에, 워커를 진짜 독립 프로세스로 띄우고 파일 기반으로 소통하는 구조가 가능합니다. 계획, 실행, 검증, 수정 파이프라인도 이 위에서 돌아갑니다.

oh-my-claudecode도 Team 모드가 있지만, 기반 CLI의 차이 때문에 구현이 다릅니다. Claude Code는 TUI 기반이고 teams API가 아직 실험 단계라, 기본적으로는 부모 프로세스 안에서 서브에이전트를 위임하는 방식으로 동작합니다. tmux CLI 워커도 추가됐지만 보조 경로에 가깝습니다. 같은 Team이라는 이름을 쓰지만, oh-my-codex의 프로세스 수준 오케스트레이션과는 결이 다릅니다.

oh-my-opencode는 서브에이전트 스포닝에 집중합니다. Team 모드는 없고, Sisyphus라는 오케스트레이터가 작업의 성격을 분류해서 그에 맞는 모델에게 넘기는 구조입니다. 프론트엔드는 Gemini, 깊은 로직은 GPT, 일반 작업은 Claude처럼요. 여러 모델을 동시에 돌리지만 워커끼리 직접 대화하거나 공유 상태를 보진 않습니다. 대신 이전 작업에서 배운 것들을 다음 작업에 전달하는 방식으로 일관성을 유지합니다.

세 도구 모두 실용적이고, 풀려는 문제가 다릅니다. 하지만 이 글에서 말하는 스포닝과 팀의 차이가 실제로 어디서 갈리는지는 이 도구들을 보면 꽤 선명해집니다.

마치며

얼마 전까지만 해도 런타임은 부담이었습니다. 지시를 촘촘히 줘야 했고, handoff가 쉽게 깨졌기 때문입니다. 그런데 모델이 좋아지면서 상황이 달라지고 있습니다. 고수준 목표만 줘도 각자 알아서 움직이고, 검증 결과를 보고 스스로 수정하기도 합니다.

이 흐름이 계속된다면, 런타임은 제약이 아니라 증폭기가 될 것입니다. 모델이 강해질수록 "어떻게 나눌까"보다 "어떻게 오래 굴릴까"가 더 중요해질 테고, 앞으로 더 필요한 건 더 많은 서브에이전트 스포닝이 아니라 더 나은 Team Operating System이라고 생각합니다.

'에이전트를 여러 개 호출하고 있는가, 아니면 하나의 팀이 실제로 일하도록 만들고 있는가?'를 고민해야 합니다.