AI는 항상 혼자였다 — 단일 에이전트 구조의 전제
지금까지 우리가 사용해온 대부분의 AI는 본질적으로 하나의 사고 주체였다. 사용자가 프롬프트를 입력하면, 하나의 모델이 그 전체 맥락을 해석하고 하나의 응답을 생성하는 구조다. 이 과정은 겉으로 보기에는 단순하고 직관적이며, 초기에는 매우 강력하게 느껴진다. 특히 짧은 질문과 명확한 요구사항에서는 이 구조가 거의 완벽하게 동작하는 것처럼 보인다. 그래서 우리는 자연스럽게 “AI는 하나의 똑똑한 존재”라는 전제를 받아들이게 된다. 이 전제는 너무 오랫동안 유지되어 왔기 때문에, 그것이 구조적 선택이라는 사실조차 인식하지 못하는 경우가 많다. 하지만 이 구조는 어디까지나 설계의 결과일 뿐이며, 반드시 그래야 할 이유는 없다.
문제는 이 단일 에이전트 구조가 복잡한 작업으로 확장될 때 드러난다. 단순 질의응답이 아니라 코드베이스 전체를 분석하거나, 여러 단계의 판단이 필요한 문제를 다룰 때, 하나의 모델이 모든 것을 동시에 처리해야 한다. 이때 모델은 모든 정보를 하나의 컨텍스트에 담아야 하고, 그 안에서 추론을 이어가야 한다. 처음에는 잘 작동하는 것처럼 보이지만, 점점 더 많은 정보가 쌓이면서 결과의 일관성이 흔들리기 시작한다. 이전의 판단이 이후의 판단을 왜곡하거나, 불필요한 정보가 계속 남아 추론을 방해하는 일이 발생한다. 그럼에도 우리는 이 문제를 구조의 문제로 보기보다는 “프롬프트를 더 잘 써야 한다”는 방향으로 해결하려 했다. 하지만 이 접근은 근본적인 해결이 아니라, 이미 한계를 가진 구조 위에서의 최적화에 가깝다.
이 지점에서 중요한 질문이 하나 생긴다. 정말로 AI는 하나여야 하는가, 아니면 우리가 그렇게 사용해왔을 뿐인가. 지금까지의 방식은 단순했기 때문에 널리 쓰였지만, 그 단순함이 복잡한 문제를 다루는 데에는 오히려 제약으로 작용하고 있다. 특히 작업의 성격이 다양해지고, 요구되는 판단의 종류가 늘어날수록 하나의 모델이 모든 것을 책임지는 구조는 점점 더 비효율적으로 변한다. 결국 우리는 하나의 모델을 더 잘 쓰는 방법이 아니라, 이 구조 자체를 다시 생각해야 하는 시점에 도달하게 된다.
복잡한 문제에서 무너지는 이유 — 컨텍스트의 구조적 한계
단일 에이전트 구조가 복잡한 문제에서 무너지는 이유는 단순히 모델의 성능 부족이 아니다. 핵심은 컨텍스트를 처리하는 방식에 있다. LLM은 입력된 모든 정보를 하나의 컨텍스트로 받아들이고, 그 안에서 다음 토큰을 예측하는 방식으로 동작한다. 이 구조에서는 모든 정보가 동일한 공간에 쌓이게 되며, 모델은 그 전체를 기반으로 추론을 이어간다. 문제는 이 컨텍스트가 길어질수록, 정보의 중요도와 관계없이 동일하게 취급된다는 점이다. 초기에는 핵심 정보였던 내용도 뒤로 밀리면서 영향력이 약해지고, 이후에 추가된 부차적인 정보가 오히려 더 큰 영향을 미치는 상황이 발생한다. 이런 현상은 점진적으로 쌓이기 때문에 사용자는 쉽게 인지하지 못하지만, 결과의 품질에는 분명한 영향을 준다.
이러한 문제는 흔히 context pollution과 context rot이라는 개념으로 설명된다. context pollution은 불필요하거나 중복된 정보가 계속 쌓이면서 추론을 방해하는 현상을 의미한다. 반면 context rot은 초기의 중요한 정보가 점점 왜곡되거나 희석되면서, 모델의 판단이 점차 흐려지는 현상을 말한다. 이 두 가지는 서로 독립적인 문제가 아니라, 동시에 발생하며 서로를 강화한다. 결국 모델은 점점 더 많은 정보를 참고하지만, 그 정보의 질은 오히려 떨어지는 역설적인 상황에 놓이게 된다. 이 구조에서는 아무리 프롬프트를 정교하게 작성해도, 일정 수준 이상에서는 품질 저하를 피하기 어렵다.
여기서 중요한 점은 이 문제가 사용자의 실수나 모델의 한계 때문이 아니라는 것이다. 이는 구조적으로 피할 수 없는 현상이다. 하나의 컨텍스트에 모든 정보를 밀어 넣는 방식 자체가 문제이기 때문이다. 그래서 우리는 프롬프트를 더 잘 쓰는 방법, 불필요한 정보를 줄이는 방법, 단계적으로 나누어 요청하는 방법 등을 시도해왔다. 하지만 이 모든 시도는 결국 동일한 구조 안에서의 최적화일 뿐이다. 근본적인 해결은 “컨텍스트를 어떻게 더 잘 쓸 것인가”가 아니라, “컨텍스트를 하나로 유지해야 하는가”라는 질문에서 시작해야 한다. 이 질문에 대한 답이 바로 다음 섹션에서 다루게 될 Subagents라는 접근이다.
해결이 아닌 전환 — Subagents라는 새로운 접근
이 모든 것을 처리해야 한다는 전제를 기반으로 시스템을 설계해왔다. 그래서 문제를 더 잘 쪼개거나, 프롬프트를 더 정교하게 작성하거나, 모델의 성능을 끌어올리는 방향으로 개선을 시도했다. 하지만 Subagents는 이 전제를 뒤집는다. 하나의 모델이 모든 것을 처리해야 할 이유가 없다면, 작업을 여러 개의 에이전트로 나누고 각자 처리하게 하면 된다. 이 접근은 단순히 효율을 높이기 위한 것이 아니라, 구조 자체를 재설계하는 시도다.
Subagents의 기본 흐름은 생각보다 단순하다. 먼저 하나의 큰 작업을 여러 개의 작은 작업으로 나눈다. 그 다음 각 작업에 대해 별도의 에이전트를 생성한다. 각 에이전트는 자신에게 주어진 작업만을 독립적으로 처리하며, 다른 에이전트의 컨텍스트와는 완전히 분리되어 있다. 모든 에이전트가 작업을 마치면, 그 결과를 하나로 모아 최종 응답을 구성한다. 이 과정에서 중요한 점은 각 에이전트가 동일한 모델일 필요도 없고, 동일한 설정을 가질 필요도 없다는 것이다. 즉, 작업의 성격에 따라 서로 다른 “전문가”를 구성할 수 있다.
이 접근이 의미 있는 이유는 단순히 병렬 처리 때문이 아니다. 진짜 변화는 컨텍스트가 분리된다는 점에 있다. 각 에이전트는 자신의 작업에 필요한 정보만을 컨텍스트로 사용하며, 불필요한 정보의 영향을 받지 않는다. 이는 앞서 설명한 context pollution과 context rot 문제를 구조적으로 차단하는 효과를 만든다. 동시에 각 에이전트는 자신의 역할에 맞는 방식으로 최적화될 수 있기 때문에, 전체 시스템의 품질도 자연스럽게 향상된다. 결국 Subagents는 더 똑똑한 하나의 모델을 만드는 것이 아니라, 여러 개의 적절한 모델을 조합하는 방식으로 문제를 해결한다.
이 지점에서 우리는 중요한 변화를 마주하게 된다. 더 이상 AI를 하나의 도구로 사용하는 것이 아니라, 여러 개의 역할을 가진 시스템으로 설계해야 한다는 것이다. 사용자의 역할도 변한다. 단순히 질문을 잘 만드는 사람이 아니라, 작업을 어떻게 나눌지 결정하는 설계자가 된다. 이 변화는 아직 초기 단계에 있지만, 앞으로의 AI 활용 방식에 큰 영향을 줄 가능성이 높다. 다음 섹션에서는 이 구조를 조금 더 깊이 들여다보고, 실제로 어떤 원리로 동작하는지 구체적으로 분석해본다.
구조의 핵심 요소 — Spawn, Isolation, Orchestration
Subagents 구조를 이해하려면 표면적인 “여러 개의 에이전트가 동시에 돈다”는 설명을 넘어, 그 내부를 구성하는 세 가지 핵심 원리를 분해해서 봐야 한다. 이 구조는 단순한 병렬 처리 시스템이 아니라, 명확한 설계 원리를 가진 아키텍처다. 특히 Spawn, Isolation, Orchestration이라는 세 축은 각각 독립적인 기능이 아니라 서로를 보완하며 전체 시스템의 동작 방식을 규정한다. 이 세 요소를 제대로 이해하지 못하면 Subagents를 단순히 “여러 개 돌리는 것”으로 오해하게 되고, 그 결과 설계 자체가 무너지기 쉽다. 따라서 이 구조를 기능이 아니라 “설계 단위”로 보는 것이 중요하다.
먼저 Spawn은 에이전트가 언제, 어떻게 생성되는지를 정의하는 개념이다. Subagents에서는 에이전트가 항상 존재하는 것이 아니라, 필요할 때 명시적으로 생성된다. 이 점은 기존의 단일 에이전트 구조와 큰 차이를 만든다. 기존에는 모든 작업이 하나의 지속적인 컨텍스트 안에서 처리되었다면, 여기서는 작업 단위마다 새로운 실행 단위가 만들어진다. 이는 단순한 리소스 분배 이상의 의미를 가진다. 각 작업이 독립적인 시작점을 갖게 되면서, 이전 작업의 잔여 영향에서 자유로워지기 때문이다. 즉, Spawn은 단순한 생성이 아니라 “새로운 사고의 시작점”을 만드는 역할을 한다.
다음으로 Isolation은 이 구조에서 가장 중요한 요소다. 각 에이전트는 완전히 분리된 컨텍스트를 가지며, 서로의 내부 상태를 공유하지 않는다. 이는 단순히 메모리를 나누는 수준이 아니라, 추론 과정 자체를 독립시키는 것을 의미한다. 하나의 에이전트에서 발생한 오류나 왜곡이 다른 에이전트로 전파되지 않으며, 각 에이전트는 자신의 문제에만 집중할 수 있다. 이 구조는 앞서 언급한 context pollution과 context rot을 근본적으로 차단한다. 동시에 각 에이전트는 서로 다른 모델이나 설정을 사용할 수 있기 때문에, 작업의 성격에 맞는 최적의 환경을 구성할 수 있다. 이 점에서 Isolation은 Subagents 구조의 핵심 가치라고 볼 수 있다.
마지막으로 Orchestration은 이 모든 과정을 하나로 묶는 역할을 한다. 여러 에이전트가 독립적으로 실행된다고 해서 자동으로 의미 있는 결과가 나오지는 않는다. 각 에이전트의 결과를 적절히 수집하고, 필요한 경우 후속 작업을 지시하며, 최종적으로 하나의 응답으로 통합하는 과정이 필요하다. 이 역할을 Codex가 수행한다. Orchestration은 단순한 스케줄링이 아니라, 전체 흐름을 관리하는 상위 레이어다. 이 레이어 덕분에 사용자는 복잡한 실행 흐름을 직접 제어하지 않고도, 고수준의 지시만으로 시스템을 운영할 수 있다. 결국 이 세 가지 요소가 결합되면서, Subagents는 단순한 기능이 아니라 하나의 완성된 실행 모델로 작동하게 된다.
단일 LLM과의 본질적 차이 — 비교를 통한 이해
이제 Subagents 구조를 기존 단일 LLM 구조와 비교해보면, 두 접근 방식이 단순히 “확장된 버전”이 아니라 완전히 다른 철학을 기반으로 한다는 것을 알 수 있다. 기존 방식은 하나의 모델이 모든 정보를 받아들이고, 그 안에서 모든 판단을 수행하는 구조였다. 이 구조는 단순하고 직관적이며, 작은 문제에서는 매우 효과적이다. 하지만 문제의 규모가 커지고, 요구되는 판단의 종류가 다양해질수록 하나의 모델이 모든 것을 처리하는 방식은 점점 비효율적으로 변한다. 특히 서로 다른 성격의 작업이 하나의 컨텍스트 안에서 뒤섞이게 되면서, 모델은 어떤 정보에 집중해야 할지 점점 더 어려워진다.
반면 Subagents 구조에서는 이러한 문제가 설계 단계에서부터 제거된다. 작업은 처음부터 분리되며, 각 에이전트는 자신의 역할에 맞는 정보만을 다룬다. 이 차이는 단순히 실행 방식의 차이를 넘어서, 시스템의 확장성과 안정성에 직접적인 영향을 준다. 기존 구조에서는 작업이 복잡해질수록 하나의 컨텍스트가 비대해지고, 그에 따라 품질이 저하되는 경향이 있었다. 하지만 Subagents에서는 작업이 늘어날수록 에이전트의 수가 증가할 뿐, 각 에이전트의 복잡도는 일정하게 유지된다. 이는 시스템이 복잡한 문제로 확장될 때 훨씬 안정적으로 동작할 수 있게 만든다.
또한 두 구조의 차이는 “어디에 지능을 두느냐”에서도 드러난다. 기존 방식에서는 지능이 하나의 모델에 집중되어 있었고, 사용자는 그 모델을 최대한 잘 활용하는 데 집중해야 했다. 반면 Subagents에서는 지능이 여러 에이전트에 분산되며, 사용자는 이들을 어떻게 조합할지를 설계해야 한다. 즉, 기존에는 프롬프트 작성이 핵심이었다면, 이제는 구조 설계가 핵심이 된다. 이 변화는 단순한 기술적 차이를 넘어, AI를 사용하는 방식 자체를 바꾸는 요소다. 결국 Subagents는 단일 LLM을 대체하는 것이 아니라, 전혀 다른 문제 해결 패러다임을 제시한다고 볼 수 있다.
가장 중요한 변화 — 컨텍스트 문제의 구조적 해결
Subagents가 가져오는 변화 중 가장 중요한 것은 컨텍스트를 다루는 방식의 전환이다. 기존 LLM 사용 방식에서는 컨텍스트를 어떻게 구성하고 관리할 것인가가 핵심 과제였다. 사용자는 불필요한 정보를 제거하고, 필요한 정보를 적절한 순서로 배치하며, 모델이 올바르게 이해할 수 있도록 프롬프트를 조정해야 했다. 이 과정은 일종의 기술이 되었고, 프롬프트 엔지니어링이라는 영역으로 발전하기도 했다. 하지만 이 모든 노력은 결국 하나의 컨텍스트를 더 잘 활용하기 위한 것이었을 뿐, 그 구조 자체를 바꾸지는 못했다.
Subagents는 이 접근을 근본적으로 뒤집는다. 더 이상 하나의 컨텍스트를 최적화하려고 하지 않고, 아예 여러 개의 컨텍스트로 분리한다. 각 에이전트는 자신에게 필요한 정보만을 가지고 작업을 수행하며, 다른 에이전트의 정보에 영향을 받지 않는다. 이는 단순히 효율을 높이는 수준을 넘어, 문제의 성격을 바꾸는 효과를 만든다. 컨텍스트가 분리되면서, 각 작업은 더 명확한 경계를 가지게 되고, 모델은 불필요한 정보에 의해 방해받지 않는다. 결과적으로 추론의 안정성과 정확도가 동시에 향상된다.
이 변화는 단순한 기술적 개선이 아니라 사고 방식의 전환을 요구한다. 기존에는 “어떻게 하면 이 모든 정보를 하나의 컨텍스트에 잘 담을 수 있을까”를 고민했다면, 이제는 “이 작업을 어떻게 나눌 것인가”를 고민해야 한다. 즉, 문제를 해결하는 방식이 프롬프트 중심에서 구조 중심으로 이동한다. 이 과정에서 사용자는 더 이상 단순한 요청자가 아니라, 시스템을 설계하는 역할을 맡게 된다. Subagents는 이 변화를 가능하게 하는 도구이며, 동시에 그 변화를 요구하는 구조다.
이 지점에서 우리는 하나의 결론에 가까워진다. LLM의 한계를 극복하는 방법은 더 강력한 모델을 만드는 것이 아니라, 모델을 사용하는 구조를 바꾸는 것이다. Subagents는 그 방향을 가장 명확하게 보여주는 사례다. 물론 이 접근이 모든 문제를 해결해주는 것은 아니며, 새로운 복잡성을 만들어내기도 한다. 하지만 적어도 컨텍스트라는 근본적인 제약을 다루는 방식에 있어서는, 이전과는 다른 차원의 해법을 제시하고 있다. 다음 섹션에서는 이러한 구조가 실제 문제 해결에서 어떻게 활용되는지, 그리고 어떤 상황에서 진짜 차이를 만들어내는지를 구체적으로 살펴본다.
AI를 설계하는 단계로 — 역할 기반 에이전트 구조
Subagents 구조가 가져오는 가장 큰 변화 중 하나는, 우리가 AI를 사용하는 방식 자체가 달라진다는 점이다. 기존에는 하나의 모델에게 최대한 명확하게 지시를 내리는 것이 핵심이었다. 사용자는 질문을 정제하고, 필요한 정보를 잘 구성하여 전달하는 데 집중했다. 하지만 Subagents 환경에서는 이러한 접근이 충분하지 않다. 하나의 에이전트가 모든 것을 처리하지 않기 때문에, 무엇을 어떻게 물어볼지보다 먼저 “이 작업을 어떻게 나눌 것인가”를 결정해야 한다. 이 지점에서 사용자의 역할은 단순한 요청자가 아니라, 시스템을 설계하는 사람으로 바뀐다.
이 변화는 자연스럽게 역할 기반 구조를 만들어낸다. 하나의 문제를 해결하기 위해 서로 다른 성격의 에이전트를 구성하게 되며, 각 에이전트는 특정 역할에 집중하게 된다. 예를 들어 어떤 에이전트는 코드베이스를 탐색하는 데 집중하고, 또 다른 에이전트는 오류를 찾는 데 집중하며, 또 다른 에이전트는 수정 작업을 수행한다. 이 구조는 우연히 만들어진 것이 아니라, 인간이 협업하는 방식과 유사한 형태로 수렴한다. 각 역할은 서로를 보완하며, 전체 시스템의 품질을 끌어올린다. 중요한 점은 이러한 역할이 단순히 작업 분배가 아니라, 서로 다른 사고 방식을 분리하는 데 있다는 것이다.
이 과정에서 설계의 중요성이 크게 증가한다. 어떤 역할을 정의할 것인지, 각 역할에 어떤 모델과 설정을 부여할 것인지, 그리고 이들을 어떤 순서로 연결할 것인지에 따라 결과가 달라진다. 잘 설계된 구조에서는 각 에이전트가 자신의 역할에 집중하면서 전체적인 품질이 향상되지만, 잘못 설계된 구조에서는 오히려 혼란이 증가할 수 있다. 특히 역할 간의 경계가 모호하거나, 하나의 역할에 너무 많은 책임을 부여할 경우, 다시 단일 에이전트 구조의 문제로 되돌아가게 된다. 따라서 Subagents를 제대로 활용하기 위해서는, 문제를 어떻게 분해하고 역할을 정의할 것인지에 대한 설계 역량이 필요하다.
이러한 변화는 단순히 기술적인 차원을 넘어, AI를 바라보는 관점 자체를 바꾼다. 더 이상 AI는 하나의 똑똑한 도구가 아니라, 여러 개의 구성 요소로 이루어진 시스템이 된다. 사용자는 이 시스템을 어떻게 구성할지 결정하는 설계자가 되며, 그 결과에 대한 책임도 함께 갖게 된다. 이 관점에서 보면 Subagents는 새로운 기능이라기보다는, AI 활용 방식의 진화를 나타내는 신호에 가깝다. 다음 섹션에서는 이러한 구조가 실제 문제 상황에서 어떻게 적용되는지, 그리고 어떤 경우에 진짜 차이를 만들어내는지를 살펴본다.
실제 활용 시나리오 — 어디에서 진짜 차이가 나는가
Subagents의 가치는 이론적인 구조 설명만으로는 충분히 드러나지 않는다. 실제로 어떤 문제에서 이 구조가 유의미한 차이를 만들어내는지를 살펴봐야 한다. 가장 대표적인 예는 코드 리뷰나 코드베이스 분석과 같은 작업이다. 이러한 작업은 단순히 하나의 정답을 찾는 것이 아니라, 여러 관점에서 동시에 판단이 이루어져야 한다. 기존의 단일 에이전트 방식에서는 하나의 모델이 모든 관점을 동시에 고려해야 했고, 그 과정에서 일부 중요한 요소가 누락되거나 왜곡되는 경우가 많았다. 하지만 Subagents 구조에서는 각 관점을 별도의 에이전트로 분리할 수 있다.
예를 들어 하나의 에이전트는 코드의 실행 흐름을 추적하는 데 집중하고, 다른 에이전트는 보안 취약점을 찾는 데 집중하며, 또 다른 에이전트는 테스트 커버리지를 검토할 수 있다. 이처럼 각 에이전트가 자신의 역할에 맞는 정보만을 처리하게 되면, 전체적인 분석의 깊이가 자연스럽게 증가한다. 또한 각 에이전트의 결과는 서로 간섭하지 않기 때문에, 특정 관점이 다른 관점에 의해 묻히는 일이 줄어든다. 결과적으로 최종 응답은 여러 관점이 결합된 형태로 제공되며, 이는 단일 에이전트가 생성한 결과보다 훨씬 균형 잡힌 분석을 가능하게 한다.
이 구조는 코드 리뷰뿐만 아니라, 복잡한 기능 구현이나 대규모 리팩토링과 같은 작업에서도 유사한 효과를 낸다. 작업을 단계별로 나누고, 각 단계에 맞는 에이전트를 배치함으로써 전체 흐름을 안정적으로 관리할 수 있다. 특히 서로 다른 종류의 판단이 필요한 경우, 이를 하나의 모델에 맡기는 대신 역할을 분리함으로써 오류 가능성을 줄일 수 있다. 중요한 것은 Subagents가 단순히 속도를 높이기 위한 도구가 아니라는 점이다. 오히려 이 구조는 “어떤 문제를 더 잘 풀 수 있는가”에 직접적인 영향을 미친다. 즉, Subagents는 특정한 종류의 복잡한 문제에서 그 진가를 발휘하는 구조다.
하지만 모든 문제에서 이 구조가 필요한 것은 아니다. 단순한 질의응답이나 짧은 작업에서는 오히려 불필요한 복잡성을 추가할 수 있다. 따라서 Subagents를 언제 사용하는 것이 적절한지를 판단하는 것도 중요한 요소다. 이 판단은 단순히 작업의 크기뿐만 아니라, 요구되는 판단의 다양성과 복잡도를 기준으로 이루어져야 한다. 다음 섹션에서는 이러한 판단을 포함하여, Subagents 구조가 가지는 현실적인 한계와 주의할 점을 살펴본다.
현실적인 한계 — 비용, 복잡도, 그리고 오용
Subagents는 분명 강력한 구조이지만, 모든 문제를 해결해주는 만능 도구는 아니다. 가장 먼저 고려해야 할 것은 비용이다. 각 에이전트가 독립적으로 실행되기 때문에, 단일 에이전트 방식에 비해 토큰 사용량이 증가한다. 이는 단순히 실행 시간이 늘어나는 문제가 아니라, 실제 운영 환경에서는 비용 증가로 직결된다. 특히 에이전트의 수가 많아질수록 이 비용은 선형적으로 증가하기 때문에, 무분별한 분해는 오히려 비효율을 초래할 수 있다. 따라서 Subagents를 사용할 때는, 구조적 이점과 비용 사이의 균형을 고려해야 한다.
또 다른 문제는 설계의 복잡도다. 기존에는 하나의 프롬프트를 잘 작성하는 것이 중요했다면, 이제는 전체 시스템을 어떻게 구성할 것인지가 더 중요한 문제가 된다. 어떤 작업을 나눌 것인지, 각 에이전트의 역할을 어떻게 정의할 것인지, 그리고 이들을 어떻게 연결할 것인지에 대한 판단이 필요하다. 이 과정은 단순한 설정 이상의 사고를 요구하며, 잘못된 설계는 오히려 결과의 품질을 떨어뜨릴 수 있다. 특히 역할 간의 중복이나 경계의 불명확성은, 에이전트 간 충돌이나 불필요한 반복 작업을 유발할 수 있다.
마지막으로 가장 흔한 문제는 과도한 분해다. Subagents의 개념을 접하면, 모든 작업을 가능한 한 많이 나누는 것이 좋다고 생각하기 쉽다. 하지만 실제로는 그렇지 않다. 지나치게 많은 에이전트를 생성하면, 각 에이전트의 작업 단위가 지나치게 작아지고, 전체적인 흐름이 오히려 비효율적으로 변한다. 또한 결과를 통합하는 과정에서 불필요한 복잡성이 증가할 수 있다. 중요한 것은 적절한 수준에서의 분해이며, 이는 경험과 설계를 통해 결정된다.
이러한 한계는 Subagents의 약점이라기보다는, 새로운 구조가 가지는 자연스러운 비용이라고 볼 수 있다. 어떤 기술도 모든 상황에서 최적일 수는 없으며, Subagents 역시 특정한 문제 영역에서 강점을 가지는 도구다. 따라서 이 구조를 효과적으로 활용하기 위해서는, 언제 사용해야 하고 언제 사용하지 않아야 하는지를 명확히 이해하는 것이 중요하다. 이러한 판단 기준을 바탕으로, 우리는 다음 섹션에서 이 구조가 의미하는 더 큰 변화와 방향성을 정리해본다.
결론 — AI는 도구에서 시스템으로 바뀐다
지금까지 살펴본 내용을 다시 정리해보면, Subagents는 단순히 하나의 기능이 아니라 우리가 AI를 다루는 방식 전체를 재정의하는 변화에 가깝다. 기존에는 하나의 모델을 중심으로 모든 작업을 해결하려 했고, 그 모델을 얼마나 잘 활용하느냐가 핵심이었다. 그래서 우리는 프롬프트를 정교하게 다듬고, 컨텍스트를 최적화하는 데 많은 시간을 투자해왔다. 하지만 이러한 접근은 결국 하나의 컨텍스트 안에서 모든 것을 해결해야 한다는 전제를 벗어나지 못했다. Subagents는 이 전제를 무너뜨리고, 작업을 분리하고 역할을 나누는 방식으로 문제를 풀도록 유도한다. 이 변화는 단순한 효율 개선이 아니라, 문제를 바라보는 관점 자체를 바꾸는 전환이다.
특히 중요한 점은 이 변화가 사용자의 역할을 바꾼다는 것이다. 더 이상 우리는 하나의 모델에게 “잘 물어보는 사람”에 머물지 않는다. 대신 여러 에이전트를 어떻게 구성하고, 어떤 역할을 부여하며, 이들을 어떤 흐름으로 연결할지를 결정하는 설계자가 된다. 이 과정에서 필요한 것은 더 이상 문장을 다듬는 기술이 아니라, 문제를 구조적으로 분해하는 능력이다. 어떤 작업을 나누고, 어디까지 분리해야 하며, 어떤 부분을 다시 통합해야 하는지를 판단하는 것이 핵심이 된다. 즉, AI를 사용하는 기술이 점점 더 시스템 설계의 영역으로 이동하고 있다.
이러한 변화는 앞으로의 AI 활용 방식에도 큰 영향을 미칠 가능성이 높다. 단일 모델 중심의 접근은 여전히 유효한 영역이 있겠지만, 복잡한 문제를 다루는 환경에서는 점점 더 한계를 드러낼 것이다. 반면 역할 기반으로 분리된 에이전트 구조는, 문제의 규모가 커질수록 오히려 더 안정적으로 동작할 수 있다. 이는 단순히 성능의 문제가 아니라, 확장성과 유지 가능성의 문제다. 하나의 거대한 모델에 모든 것을 맡기는 대신, 여러 개의 작은 단위로 나누어 관리하는 방식은 소프트웨어 설계에서도 이미 검증된 접근이다. Subagents는 이러한 개념을 AI 영역에 적용한 사례라고 볼 수 있다.
물론 이 구조가 모든 상황에서 정답이 되는 것은 아니다. 앞서 살펴본 것처럼 비용과 복잡도, 그리고 설계 난이도라는 현실적인 제약이 존재한다. 하지만 중요한 것은 방향이다. 우리는 더 이상 하나의 모델을 어떻게 더 잘 사용할 것인가를 고민하는 단계에 머물지 않는다. 대신 여러 개의 모델과 에이전트를 어떻게 조합할 것인가를 고민하는 단계로 이동하고 있다. 이 변화는 점진적으로 진행되겠지만, 결국 AI는 하나의 도구가 아니라 여러 구성 요소로 이루어진 시스템으로 자리 잡게 될 것이다.
결국 Subagents가 의미하는 바는 명확하다. LLM은 더 이상 단일한 지능이 아니라, 역할을 가진 여러 단위의 집합으로 이해해야 한다는 것이다. 이 구조를 어떻게 설계하고 활용하느냐에 따라 결과의 품질이 결정되며, 이는 단순한 사용 기술을 넘어 하나의 설계 문제로 이어진다. 지금은 아직 초기 단계이지만, 이 방향은 분명하다. AI는 점점 더 “잘 쓰는 것”에서 “잘 설계하는 것”으로 이동하고 있으며, Subagents는 그 변화의 시작점 중 하나다.
