에이전트(Agent) 기반의 AI 개발 환경으로 전환되면서 개발 과정의 복잡성이 소수의 담당자에게 집중되는 '인지 부하' 문제가 심각해졌습니다. 이 글은 '팀 토폴로지(Team Topologies)' 모델을 바탕으로, AI 플랫폼이 기술적 복잡성을 흡수하여 비즈니스 팀이 각자의 도메인에만 집중할 수 있도록 조직 구조를 어떻게 재설정해야 하는지 다룹니다.
번역된 본문
에이전트 플랫폼(Agentic Platform)은 무엇을 제공해야 하는지를 정의합니다. 팀 토폴로지(Team Topologies)는 누가 그것을 제공하며, 이를 실현하기 위해 팀들이 어떻게 상호작용하는지를 정의합니다. 이 시리즈의 첫 번째 글에서 우리는 '무엇'을 묻고자 했습니다. 대규모로 신뢰할 수 있는 애플리케이션을 구축하기 위해 어떤 시스템적 역량(컨텍스트, 가드레일, 도구)이 필요한가? 그 대답이 바로 에이전트 플랫폼이었고, 그 핵심에는 에이전트가 계획, 코딩, 테스트 및 배포를 수행하는 메커니즘인 '에이전트 팩토리(Agentic Factory)'가 있습니다. 하지만 플랫폼은 스스로를 구축하지 않으며, 더 중요한 것은 구축되는 방식과 소비되는 방식이 동일하지 않다는 점입니다. 근본적인 질문이 남아 있습니다: 누가 무엇을 하는가?
진짜 문제: 에이전트 생산의 인지 부하
'누가 무엇을 하는가'를 묻기 전에, 왜 이번에는 그 질문이 다른지 이해해야 합니다. 과거에 애플리케이션을 구축한다는 것은 시간의 흐름에 따라 역할을 조율하는 것을 의미했습니다. 한 사람은 디자인을 하고, 다른 한 사람은 아키텍처를 검토했으며, 세 번째 사람은 테스트를, 네 번째 사람은 배포를 담당했습니다. 복잡성은 존재했지만 여러 사람에게 분산되었고 시간에 걸쳐 분배되었습니다. 각 역할은 순차적으로 자신의 질문을 던졌습니다.
에이전트는 이 공식을 바꿔버립니다. 그들은 질문을 던지지 않고 즉각적으로 결과물을 생산해 냅니다. 그들은 지치지도, 쉬지도, 기다리지도 않습니다. 그들의 속도는 강점이자 동시에 덫입니다. 과거에 역할들이 순차적으로 제기했던 모든 질문들을, 이제 에이전트를 조종하는 인간은 프롬프트라는 짧은 창 안에서 미리 병렬적으로 예측해야 합니다. 프롬프트가 제대로 설계되지 않더라도 에이전트는 속도를 늦추지 않습니다. 그저 빠르게, 그리고 엉뚱한 방향으로 결과물을 쏟아냅니다.
인지 부하(Cognitive load)는 AI와 함께 사라지는 것이 아니라 변형될 뿐입니다. 이는 먼저 '예측의 부담(anticipation burden)'이 됩니다. 에이전트를 실행하기 전에 인간이 미리 예측하고 준비해야 할 모든 것을 의미하며, 그렇지 않으면 결과물의 품질이 떨어집니다. 그리고 에이전트가 인간의 리듬 없이 끊임없이 결과물을 생산해 내기 때문에, 이는 시간이 지남에 따라 지속적인 의사결정의 흐름을 요구하는 '인지 처리량(cognitive throughput)'의 문제가 되기도 합니다. 대규모 에이전트 생산의 진짜 도전 과제는 복잡성이 커진다는 것이 아닙니다. 그것은 복잡성이 한 개인에게 압축되며, 그들이 감당할 수 없는 시간 프레임 안으로 짓눌린다는 것입니다.
바로 이것이 플랫폼이 해결하고자 하는 부분입니다. 플랫폼은 스스로를 에이전트가 쿼리(질의)할 수 있도록 만듦으로써 예측의 부담 일부를 흡수합니다. "보안은 신경 쓰지 마라"라는 말은 에이전트가 진행 방법을 플랫폼에 묻고, 결정론적 제어(deterministic controls)가 하위 시스템에서 결과를 강제로 실행한다는 것을 의미합니다. 플랫폼은 생각의 과정을 없애는 것이 아니라 인간이 직접 다뤄야 할 질문의 범위를 좁혀줍니다. 인간은 진정으로 중요한 부분, 즉 인간의 판단이 여전히 대체 불가능한 구조적이고 이견이 존재하는 의사결정에 집중할 수 있게 됩니다.
따라서 스켈튼(Skelton)과 파이스(Pais)가 설명한 것처럼 인지 부하는 더 이상 단순히 팀 간에 분배해야 하는 양만이 아닙니다. 에이전트의 세계에서는 이를 시간이 지남에 따라 규제해야 하는 '처리량'이기도 합니다. 팀 토폴로지는 분배 방법을 알려줍니다. 하지만 플랫폼이 이를 어떻게 흡수해야 하는지는 우리가 별도로 정의해야 합니다. 그것이 바로 이 글의 주제입니다.
부하에 대한 해답, 팀 토폴로지(Team Topologies)
이러한 부하 문제를 해결하기 위해 우리는 4가지 팀 유형과 3가지 상호작용 모드를 정의한 조직 모델인 '팀 토폴로지(Team Topologies)'를 도입합니다. 이는 결코 우연이 아닙니다. 이 모델의 근본적인 논리는 바로 인지 부하, 즉 팀이 감당할 수 있는 수준 이상의 복잡성을 떠안지 않을 때만 팀이 효과적일 수 있다는 것입니다. 스켈튼과 파이스는 팀에 분배할 구조적 부하에 대해 논의했습니다. 우리는 이를 앞서 설명한 에이전트 생산 행위의 동적 부하로 확장합니다. 이 모델은 분배할 수 있는 것을 분배하고, 플랫폼이 흡수해야 할 것을 식별할 수 있는 기준을 제공합니다.
우리의 입장을 분명히 하겠습니다. 아래 내용은 우리가 생각하는 미래지향적인 확신이자, 에이전트를 통한 애플리케이션 생산이 나아가야 할 조직적 목표입니다. 더 이상의 질문은 '팩토리에 무엇이 필요한가'가 아니라, '누가 이를 운영하는가'입니다. 바로 이것이 에이전트 플랫폼의 역할입니다. 이 플랫폼은 기술적 복잡성을 흡수하여 비즈니스 팀이 오직 자신들의 도메인에 해당하는 인지 부하만을 감당하게 만듭니다. 개발자의 역할은 변화합니다. 그들은 이제 다른 사람들이 생산할 수 있도록 돕는 플랫폼을 구축합니다. 이와 동시에 애플리케이션 생산은 에이전트를 통해 비즈니스 팀에게 열려 있습니다.
The agentic platform defines what needs to be provided. Team Topologies defines who provides it, and how teams interact to make it happen. In the first article of this series , we asked the what : which systemic capabilities (context, guardrails, tooling) are needed to produce reliable applications at scale. The answer was the agentic platform, and at its core, the agentic factory : the mechanism where agents plan, code, test, and ship. But a platform does not build itself, and more importantly, it is not consumed the same way it is built. A fundamental question remains: who does what? The real problem: the cognitive load of agentic production Before asking who does what, we need to understand why the question is different this time. Building an application used to mean orchestrating roles over time: one person designed, another challenged the architecture, a third tested, a fourth deployed. The complexity was real, but distributed — across several people, and spread over time. Each role asked its questions in turn. Agents change the equation. They do not ask questions: they produce answers, immediately. They never tire, never rest, never wait. Their speed is their strength, and their trap. All the questions that roles used to raise sequentially , the human steering the agent must now anticipate upfront, in parallel, in the short window of a prompt . Poorly framed, an agent does not slow down: it produces fast, and off target. Cognitive load does not disappear with AI — it transforms. It first becomes an anticipation burden : everything the human must foresee before launching the agent, or the output will fall short. And because the agent produces continuously, without human rhythm, it also becomes a cognitive throughput problem: a sustained flow of decisions over time. The real challenge of agentic production at scale is not that complexity grows — it is that complexity compresses , onto a single person and into a timeframe they cannot absorb alone. This is exactly what the platform addresses. It absorbs part of the anticipation burden by making itself queryable by the agent : “don’t worry about security” means the agent will ask the platform how to proceed, and deterministic controls will enforce the outcome downstream. The platform does not eliminate thinking — it narrows the set of questions the human must carry , letting them focus on what truly matters: the contested, structural decisions where human judgment remains irreplaceable. Cognitive load is therefore no longer just, as Skelton and Pais describe, a quantity to distribute across teams . In the agentic world, it is also a throughput to regulate over time . Team Topologies tells us how to distribute; we still need to say how to absorb. That is the subject of this article. Team Topologies, an answer to the load To tackle this load problem, we draw on Team Topologies 1 , an organizational model that defines four team types and three interaction modes. This is no coincidence: its founding argument is precisely cognitive load — a team can only be effective if it carries no more complexity than it can absorb. Skelton and Pais reason about structural load, to be distributed across teams; we extend it to the dynamic load of the agentic production act, described above. The model gives us the grid for distributing what can be distributed, and identifying what the platform must absorb. Let us state our position upfront: what follows is a forward-looking conviction , the organizational target toward which, in our view, application production by agents is heading. The question is no longer what the factory needs , but who operates it . This is exactly what the agentic platform does: it absorbs technical complexity so that business teams carry only the cognitive load of their domain. The developer shifts: they build the platform that enables others to produce. Symmetrically, application production opens up to business teams through agents. What we keep and what we adapt Applying Team Topologies to the agentic context requires clarity about our departures. To avoid hollowing out the model while claiming its name, here is the line. What we keep intact: the guiding principle of cognitive load ; the four team types ; the three interaction modes ; the shift from collaboration to X-as-a-Service at maturity. What we adapt, and why: stream-aligned teams can be non-technical (business), because the platform absorbs the technical load; they do not carry end-to-end operational responsibility (run, incidents), which the platform absorbs; enabling is not merely transient: it is structurally compensated by the platform, since the producer is no longer a developer; cognitive load is no longer just a quantity to distribute across teams, but a throughput to regulate over time : the platform absorbs the anticipation burden upstream of agentic production. These adaptations do not betray Skelton and Pais’s intent: they apply it to a context they had not anticipated — one where agents produce, and humans orchestrate. Four team types, one objective The objective is shared: produce reliable applications, consistent with organizational standards, at scale. But the roles are distinct. The four Team Topologies team types applied to the agentic platform. Each team plays a specific role in the production chain. Stream-aligned teams: producing applications Stream-aligned teams are product teams. They drive the AI orchestrator (the engine of the agentic factory described in the first article), define business intent, and supply the dynamic context : specifications, product-specific guardrails, domain knowledge. The transformation runs deep: these teams no longer need to be composed of developers. Increasingly, they are business teams (domain experts, product managers, analysts) who directly drive production through agents. This shift brings production closer to the need, but it carries a risk: these teams may not always appreciate the implications of putting an application into production. This is precisely why the other team types exist. A point of rigor is in order. In classic Team Topologies, a stream-aligned team is responsible end to end for a value stream, including operations and incidents. Here, the platform absorbs operational responsibility (deployment, monitoring, rollback). The stream-aligned team remains responsible for the what (intent, business quality); the platform guarantees the how (reliable production deployment). This split requires a sufficiently mature platform . On-call duty is distributed accordingly: the platform team handles systemic incidents (infrastructure, guardrails, pipelines); business decisions (content removal, product rollback) stay with the stream-aligned team. This what/how boundary is more porous than it appears . Brand consistency, for example, is a business concern (the what ), but its verification is automated by the platform (the how ). The platform guarantees minimums ; it does not guarantee business excellence. The platform team: industrializing capabilities The platform team provides the three systemic pillars as X-as-a-Service: Systemic context : instructions, roles, shared business knowledge, memory, examples and patterns Systemic guardrails : security, reliability, brand consistency, conventions Tooling and skills : MCP servers, CI/CD pipelines, evaluations, shared skills The model is self-service: documented, versioned, consumable without friction. Design effort is invested once, then applied to every project. A platform is “mature” when… To keep the word from remaining an empty promise, here are the observable criteria: Guardrail coverage : critical dimensions (security, reliability, brand consistency) are covered automatically, not by verbal agreement Pipeline reliability : deployment success rate is measurable and tracked (internal SLA) Self-service share : the majority of deployments happen without platform team intervention Documentation c