Field note · 2026-05-24

업무 흐름은 토폴로지다: Team Topology & Message Bus

업무 효율화 — Team Topology & Message Bus

업무 흐름은 토폴로지다: Team Topology & Message Bus

도구를 고르는가, 업무 흐름을 재설계 하는가

AI 도입 이야기가 나오면 가장 먼저 나오는 질문이 있다. "어떤 모델이 좋냐", "어떤 도구를 써야 하냐".

그런데 실제로 AI가 일에 녹아든 사례를 들여다보면, 결정적인 요소는 도구 선택이 아니다. 업무 흐름을 어떻게 재설계했느냐가 갈린다.

어떤 단계를 누가(또는 무엇이) 맡는가. 단계 사이를 무엇이 이어주는가. 어디서 사람이 판단하고, 어디서는 그냥 통과시키는가. 이것을 명시적으로 설계한 사람이 AI를 레버리지로 쓴다. 그렇지 않은 사람은 도구의 소비자에 머문다.

업무 흐름이 잘 설계되어 있으면 도구는 계속 갈아끼울 수 있다. 이미지 생성 도구가 업그레이드되어도, 영상 모델이 바뀌어도, 흐름을 들고 있는 오케스트레이터 구조는 그대로 남는다. 업무 흐름이 자산이다.

이것은 개발 지식이 필요한 일이 아니다. 전 세계 개발자는 많아야 전체 인력의 1% 수준이다(SlashData 2025: 4,720만 명). 나머지 99%가 지금 이 질문 앞에 서 있다. 콘텐츠 담당자, HR 매니저, 기획자, 마케터. 코드를 모르지만 업무 흐름을 설계할 수 있는 사람들이다.

코드가 필요한 부분은 따로 있다. Google이 최대 400억 달러를 약정한 Anthropic의 Claude Code가 그 역할을 한다. 워크스페이스 환경에서 Gemini가 하듯, 코드 작업 환경에서 Claude Code가 한다. 에코시스템이 이미 분담되어 있다.

질문을 하나 남기고 이론으로 들어간다. 업무 흐름을 잘 설계한다는 것이 무엇인가.

핸드오프, 업무 전달 비용

콘텐츠 한 편을 만들려면 기획자, 디자이너, 편집자가 따로 있어야 했다. 각자 자기 도구를 쓰고, 각 단계마다 파일이 오갔다.

콘텐츠 자체보다 그 사이의 핸드오프에서 시간과 품질이 샜다. 기획서가 디자이너에게 넘어가면서 의도가 희석됐다. 디자인 파일이 편집자에게 넘어가면서 맥락이 잘렸다. 각 단계 사이의 번역 비용이 쌓였다.

이것이 Point-to-Point 소통의 비용이다. A가 B에게, B가 C에게, A가 C에게 직접 연결된다. 사람이 늘어날수록 연결이 n*(n-1)/2로 폭발한다. 기획자 1명, 디자이너 2명, 편집자 1명이면 이미 6개의 연결이다. 각 연결마다 컨텍스트를 다시 맞추는 비용이 발생한다.

이것이 Collaboration Drag다. Gartner의 표현을 빌리면: "결정 권한 불명확, 과도한 조율, 정렬되지 않은 기대치."

AI 에이전트는 이 핸드오프 비용을 흡수한다. 각 단계 사이의 번역과 전달을 AI가 처리하면, 사람은 단계 내부의 판단에만 집중할 수 있다. 업무 흐름이 잘 설계되어 있다면, 1인이 전체 루프를 돌릴 수 있다. 비개발자도.

McKinsey(2025)는 이 효과가 비기술직 커뮤니케이션 집약 업무에서 가장 크다고 측정했다. Brynjolfsson 외(Quarterly Journal of Economics, 2025)는 숙련도가 낮은 노동자일수록 AI 도입 효과가 더 크다는 것을 실증했다. 기술 장벽이 낮을수록 레버리지가 크다.

개인이 달라지면 팀이 달라진다

개인의 업무 흐름이 재설계되면, 팀의 커뮤니케이션 구조도 달라진다.

예전에는 각 전문가 영역의 경계가 팀의 경계였다. 기획은 기획팀이, 디자인은 디자인팀이, 영상은 영상팀이. 팀 사이를 넘을 때마다 핸드오프 비용이 발생했다.

개인이 AI를 통해 여러 도메인을 흡수하면, 팀의 경계를 어디에 그어야 하는지가 달라진다. 기획+디자인+편집을 한 사람이 처리한다면, 그 팀은 무엇을 경계로 나눠야 하는가.

이것이 팀 설계의 질문이다. 그리고 이 질문에 가장 체계적으로 답한 것이 Conway's Law와 Team Topologies다.

소통 구조가 시스템을 만든다

1968년 Melvin Conway가 발견했다.

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of those organizations."

→ Melvin Conway, "How Do Committees Invent?" (1968)

조직의 소통 구조가 시스템 아키텍처를 결정한다. 따로 소통하는 두 팀은 따로 작동하는 두 모듈을 만든다. 긴밀하게 소통하는 팀은 강하게 결합된 하나의 모듈을 만든다.

업무 흐름 설계의 언어로 번역하면: 흐름을 어떻게 자르는가가 결과물의 형태를 결정한다. 단계를 어디서 나누고, 단계 사이를 어떻게 연결하느냐가 최종 산출물의 구조에 그대로 반영된다.

거꾸로도 작동한다. Skelton과 Pais의 Inverse Conway Maneuver(2019):

"Deliberately design team structures to shape the desired software architecture."

→ Inverse Conway Maneuver — Martin Fowler

원하는 결과물을 먼저 설계하고, 그에 맞게 흐름을 나눈다. 원하는 에이전트 아키텍처를 먼저 그리고, 그 경계에 맞게 에이전트 컨텍스트를 나눈다.

그렇다면 경계를 어디에 긋는가. 소통 방식이 답이다.

지속적으로 소통해야 하는가, 핸드오프로 충분한가

팀 구성의 핵심 진단 질문은 하나다.

이 두 단위는 지속적으로 소통해야 하는가, 아니면 핸드오프로 충분한가.

지속적 소통이 필요하다면 같은 팀으로 묶어라. 수시로 컨텍스트를 공유하고, 실시간으로 조율하고, 같은 맥락 안에서 움직여야 한다면 분리 비용이 너무 크다. 경계를 만들 것이 아니라 채널을 만들어야 한다. 이것이 Message Bus가 작동하는 방식이다. 공통 채널 안에서 단위들이 서로를 직접 알 필요 없이 메시지를 주고받는다. 2003년 Hohpe와 Woolf가 Enterprise Integration Patterns에서 정리한 이 패턴은 조직 설계에도 그대로 적용된다.

핸드오프로 충분하다면 팀을 나눠라. 명확한 입력을 받아 명확한 출력을 돌려주는 관계라면, 굳이 같은 컨텍스트를 공유할 필요가 없다. 경계를 명확히 하고, 그 경계에서 주고받는 형식(인터페이스)만 잘 정의하면 된다. 각 단위는 독립적으로 발전할 수 있다.

이것이 에이전트 아키텍처의 두 패턴과 정확히 대응된다.

Agent Team — 여러 에이전트가 컨텍스트를 공유하며 지속적으로 소통하는 방식. 실시간 조율이 필요한 복잡한 태스크에 적합하다. 단, 에이전트 수가 늘어나면 컨텍스트가 뒤섞이는 위험이 커진다.

Sub-agent (Isolated) — 격리된 컨텍스트 윈도우에서 독립적으로 작동하는 방식. 명확한 입력을 받아 압축된 결과를 Orchestrator에게 돌려준다. 5,000 토큰짜리 탐색 결과를 200 토큰 요약으로 압축한다. 핸드오프 구조다.

소통 방식팀 구조에이전트 패턴
지속적 소통 필요팀으로 묶어라Agent Team
핸드오프로 충분팀을 나눠라Sub-agent (Isolated)

그러므로 팀 재구성의 질문은 이것이다: 현재 우리 팀의 소통 방식이 지속적 소통인가, 사실은 핸드오프인가? 지속적 소통처럼 보이지만 실제로는 핸드오프인 경우가 많다. 매일 만나는 회의가 사실은 파일을 주고받는 핸드오프의 변형이라면, 팀을 나누고 인터페이스를 명확히 하는 것이 낫다.

에이전트 시스템은 조직의 거울이다

2026년 멀티 에이전트 시스템의 컨센서스는 명확하다. Orchestrator + Isolated Sub-agents. Anthropic, OpenAI, AutoGen, LangChain이 모두 수렴한 패턴이다.

이유가 정확히 위의 진단과 같다. 대부분의 복잡한 태스크는 지속적 소통이 필요한 부분과 핸드오프로 충분한 부분이 섞여 있다. Orchestrator가 전체 흐름을 들고 판단하고, Sub-agent는 격리된 컨텍스트에서 자신의 도메인만 처리한 뒤 결과를 돌려준다.

모든 에이전트가 모든 메시지를 보는 peer-to-peer 구조는 production에서 실패한다. 컨텍스트가 오염된다. 채널 수가 n*(n-1)/2로 폭발한다. 결정 권한이 불명확해진다. 지속적 소통이 필요하지 않은 단위까지 같은 컨텍스트에 묶어두면, Message Bus가 아니라 노이즈가 된다.

좋은 에이전트 설계는 좋은 팀 설계와 같은 질문에서 시작한다. "이 두 에이전트는 지속적으로 소통해야 하는가, 핸드오프로 충분한가."

업무 흐름에이전트
지속적 소통 단위 (팀 내)Agent Team
핸드오프 단위Sub-agent (Isolated)
흐름 총괄Orchestrator
단계 간 표준 형식공통 명령 구조
핸드오프 비용Context pollution

쪼개기 기준

"지속적으로 소통해야 하는가, 핸드오프로 충분한가"라는 질문에 답하기 위한 다섯 가지 기준이다.

1. 같은 어휘를 쓰는가

Eric Evans는 Domain-Driven Design(2003)에서 "Ubiquitous Language"를 경계의 핵심 기준으로 제시했다. 같은 단어로 같은 개념을 가리키는 집단은 하나의 단위다. 단어가 달라지는 경계가 나눌 경계다.

Edward Hall의 High-context / Low-context 커뮤니케이션 이론이 이것을 보완한다. 공유된 경험이 쌓인 집단에서는 "어제처럼"이라는 한 마디가 수백 단어를 대체한다. 그 공유 경험이 없는 집단 간에는 같은 채널을 써도 의미가 달리 착지한다.

어휘가 같다면 지속적 소통이 효율적이다. 어휘가 다르다면 핸드오프 인터페이스를 명확히 하고 나누는 것이 낫다. 억지로 같은 채널에 두면 번역 비용만 쌓인다.

→ Eric Evans, Domain-Driven Design (2003) — O'Reilly
→ Bounded Context — Martin Fowler
→ Edward T. Hall, Beyond Culture (1976) — High/Low-context communication 원전

2. 인지 부하 한계를 넘는가

John Sweller의 인지 부하 이론(1988): 인간의 작업 기억에 물리적 상한이 있다. George Miller의 "Magic Number 7"(1956) — 동시에 처리할 수 있는 독립 항목은 7±2개.

Skelton과 Pais는 이것을 팀 설계 원칙으로 번역했다.

"Architecture must be shaped around the minimum effective cognitive load per team."
— Team Topologies (2019)

한 단위가 담당하는 도메인이 인지 한계를 초과하면 품질이 떨어진다. 지속적 소통으로 묶어두어야 할 단위인지, 아니면 인지 부하를 격리하기 위해 나눠야 할 단위인지가 여기서 갈린다.

에이전트의 컨텍스트 윈도우 제한은 이 인지 한계의 기술적 구현이다. 너무 많은 도메인을 하나의 컨텍스트에 넣으면 품질이 저하된다("Lost in the Middle" 현상). Sub-agent 격리가 이 한계를 우회한다.

→ Matthew Skelton & Manuel Pais, Team Topologies (2019) — teamtopologies.com
→ Team Cognitive Load — Team Topologies Key Concepts

3. 피드백 루프가 독립적이어야 하는가

Accelerate(Forsgren, Humble, Kim, 2018): 고성과 조직은 빠른 피드백 루프를 가지고 있고, 그 루프는 외부 노이즈로부터 보호되어 있다.

피드백의 속도가 다른 단위를 같은 채널에 넣으면 가장 느린 루프가 전체를 결정하거나, 가장 빠른 루프가 나머지를 압도한다. 즉각 실행 단계와 검토 단계를 같은 흐름에 두면 검토 대기가 전체를 블로킹한다.

피드백 리듬이 같다면 지속적 소통으로 묶어라. 리듬이 다르다면 핸드오프로 나눠라.

→ Nicole Forsgren, Jez Humble, Gene Kim, Accelerate (2018) — DORA Research

4. 시간 지평이 같은가

Stafford Beer의 Viable System Model(VSM, 1972): 실행(현재), 최적화(단기), 전략(장기)이 같은 채널에서 같은 속도로 소통하려 하면 마비된다.

전략적 판단이 필요한 단계와 자동화 가능한 단계를 같은 루프에 두면 안 된다. 시간 지평이 같은 단위는 지속적 소통으로 묶고, 다른 단위는 핸드오프로 나눠라.

→ Stafford Beer, Brain of the Firm (1972)

5. 원하는 아키텍처에서 역산할 수 있는가

Inverse Conway Maneuver: 원하는 결과를 먼저 설계하고, 그에 맞게 단위를 나눈다. 최종 결과물의 모듈 경계를 먼저 정의하고, 그 경계에서 주고받는 것(인터페이스)을 명확히 한다. 인터페이스가 명확하면 핸드오프로 나눌 수 있다. 인터페이스를 정의하기 어렵다면 지속적 소통이 필요한 단위다.

Bezos의 "API Mandate"(2002)가 이 원칙의 산업 사례다. 내부 팀들이 서비스 간 직접 접근을 금지하고 API를 통해서만 통신하도록 강제했다. 인터페이스를 강제함으로써 핸드오프 구조를 만들었다. 그 결과물이 AWS다.

→ Matthew Skelton & Manuel Pais, Team Topologies (2019)
→ Amazon API Mandate — Steve Yegge's Platform Rant (2011)

Team Topologies의 네 유형

Skelton과 Pais(2019)가 정리한 팀 유형이 소통 방식과 에이전트 아키텍처에 정확히 대응된다.

Stream-aligned — 특정 가치 흐름에 집중하는 단위. 자율적 end-to-end 책임. 도메인 안에서 지속적으로 소통하며 움직인다. → 도메인 전문 Sub-agent. 비서형 에이전트가 주로 처리하는 영역이다.

Platform — 다른 단위에게 명확한 인터페이스(API)로 서비스를 제공한다. 핸드오프 관계다. → 공유 Tool / MCP server. 개발이 필요한 영역이다.

Enabling — 능력을 이전하고 빠져나오는 임시 코치. 일시적 지속 소통 후 핸드오프로 전환한다. → Orchestrator의 일시적 컨텍스트 이전.

Complicated Subsystem — 전문 지식이 필요한 복잡 영역을 격리하는 단위. 인지 부하를 다른 단위에게 넘기지 않기 위해 핸드오프로 분리한다. → 전문 도메인 Isolated Sub-agent.

Dunbar의 수와 n(n-1)/2

Robin Dunbar의 발견. 인간이 안정적 관계를 유지할 수 있는 상한이 약 150명, 신뢰 협업자는 15명이다.

지속적 소통으로 묶을 수 있는 단위의 상한이 여기서 나온다. 20명이 모두 지속적으로 소통하면 경로가 190개다. 팀이 15명을 초과하면 신뢰 관계 유지가 어려워지고 인지 부하가 직접 증가한다. 이 한계를 넘는 순간 지속적 소통이 노이즈가 되고, 핸드오프 구조로 전환해야 할 신호가 된다.

수학이 같다. n*(n-1)/2 채널 폭발이 조직에서는 Collaboration Drag로, 에이전트에서는 Context pollution으로 나타난다. 지속적 소통 단위를 너무 크게 잡으면 같은 붕괴가 일어난다.

업무 흐름은 남는다

도구는 계속 바뀐다. 더 좋은 모델이 나오면 교체하면 된다. 도구는 플러그인이다.

업무 흐름은 남는다. 어떤 단위를 지속적 소통으로 묶고 어떤 단위를 핸드오프로 나눴는지의 설계. 그 경계에서 주고받는 인터페이스의 계약. 이것은 도구가 바뀌어도 유지된다. Orchestrator가 들고 있는 흐름이 그렇고, Sub-agent의 입출력 스펙이 그렇고, Agent Team의 공통 명령 구조가 그렇다.

1편에서 신뢰는 예측 가능성이라고 했다. 예측 가능성은 업무 흐름의 일관성에서 온다. 도구가 바뀌어도 흐름이 일관하면 결과물이 예측 가능하다.

빠르게 바꿀 것: 각 단위의 도구. Sub-agent가 사용하는 모델과 API.

일관되게 유지할 것: 지속적 소통 단위와 핸드오프 단위의 경계. 그 경계에서 주고받는 인터페이스. Orchestrator가 들고 있는 계약.

에이전트를 잘 설계한다는 것은 결국 좋은 업무 흐름을 설계하는 것과 같다. 그리고 좋은 업무 흐름 설계는 개발 지식보다 소통 구조에 대한 이해에 가깝다. Conway가 1968년 발견한 것을 에이전트 시대가 다시 증명하고 있다.

3편에서는 이 흐름 위에서 에이전트가 실제로 읽는 맥락의 품질 문제를 다룬다. 채널 설계가 어떻게 흐를지를 결정한다면, 컨텍스트 설계는 무엇이 흐를지를 결정한다. Enterprise System의 데이터를 에이전트가 어떻게 읽고, 어떻게 행동하고, 어떻게 해석하는가 — Dynamic, Kinetic, Semantic.

Quantum Jump for Topology 1편. 고객 확보: Agent Web & Trust 2편. 업무 효율화: Team Topology & Message Bus 3편. 빠른 개선: Dynamic, Kinetic and Semantic 4편. 거버넌스: Rail, Checkpoint, Guardrail 5편. 측정: Hidden graph, Sensor, Observatory

참고