멀티 에이전트를 만들지 마세요

맥락 설계의 원칙

다음 원칙에 차근차근 도달해 보겠습니다.

맥락을 공유하라
행동에는 암묵적인 결정이 담긴다

왜 원칙을 생각해야 할까요?

HTML은 1993년에 등장했습니다. 2013년에는 Facebook이 React를 세상에 공개했습니다. 2025년인 지금, React와 그 후손은 개발자가 사이트와 앱을 만드는 방식을 지배합니다. 왜일까요? React는 단순히 코드를 작성하는 뼈대가 아니기 때문입니다. React는 하나의 철학입니다. React를 쓰면 반응성과 모듈성을 바탕으로 애플리케이션을 만드는 방식을 받아들이게 됩니다. 지금은 사람들이 이를 당연한 표준 요구사항으로 여기지만, 초기 웹 개발자에게는 늘 명백한 일이 아니었습니다.

LLM과 AI 에이전트의 시대인 지금, 우리는 초기 웹에서 HTML과 CSS를 이리저리 조합해 좋은 경험을 만드는 법을 찾던 단계와 비슷한 곳에 있는 듯합니다. 몇 가지 가장 기본적인 사항을 빼면 에이전트를 만드는 단 하나의 표준 방식은 아직 나오지 않았습니다.

OpenAI의 https://github.com/openai/swarm과 Microsoft의 https://github.com/microsoft/autogen 같은 라이브러리는 때때로 제가 잘못된 에이전트 구축 방식이라고 생각하는 개념을 적극적으로 권합니다. 바로 멀티 에이전트 아키텍처입니다. 이제 그 이유를 설명하겠습니다.

그렇지만 에이전트 구축을 처음 시작한다면 기본 뼈대를 설정하는 방법을 알려주는 자료가 많습니다 [1] [2]. 하지만 제대로 된 상용 애플리케이션을 만드는 일은 이야기가 다릅니다.

장기 실행 에이전트를 만드는 이론

신뢰성부터 살펴보겠습니다. 에이전트가 오랫동안 실제로 안정적으로 작동하고 일관된 대화를 유지해야 한다면, 오류가 쌓여 커질 가능성을 억제하기 위해 반드시 해야 할 일이 있습니다. 주의하지 않으면 모든 것이 빠르게 무너집니다. 신뢰성의 중심에는 맥락 설계가 있습니다.

맥락 설계

2025년의 모델은 대단히 지능적입니다. 하지만 아무리 똑똑한 사람도 자신이 맡은 일이 무엇인지 알려주는 맥락이 없으면 일을 제대로 할 수 없습니다. “프롬프트 엔지니어링”은 LLM 챗봇에 작업을 가장 알맞은 형식으로 전달하려는 노력을 가리키는 말입니다. “맥락 설계”는 여기서 한 단계 더 나아갑니다. 변화하는 시스템 안에서 이 작업을 자동으로 처리하는 일입니다. 훨씬 더 세심한 판단이 필요하며, 사실상 AI 에이전트를 만드는 엔지니어의 가장 중요한 일입니다.

흔히 볼 수 있는 에이전트를 예로 들어 보겠습니다. 이 에이전트는 다음과 같이 일합니다.

작업을 여러 부분으로 나눈다
각 부분을 맡을 서브에이전트를 시작한다
마지막에 결과를 합친다

다음 원칙에 차근차근 도달해 보겠습니다.

이 아키텍처는 매력적으로 보입니다. 특히 여러 부분을 동시에 처리할 수 있는 작업 분야라면 더욱 그렇습니다. 하지만 매우 깨지기 쉽습니다. 핵심 실패 지점은 다음과 같습니다.

작업이 “Flappy Bird 복제 게임 만들기”라고 해 보겠습니다. 이 작업은 하위 작업 1인 “초록색 파이프와 충돌 영역이 있는 움직이는 게임 배경 만들기”와 하위 작업 2인 “위아래로 움직일 수 있는 새 만들기”로 나뉩니다.

그런데 서브에이전트 1은 하위 작업을 잘못 이해해 Super Mario Bros.처럼 보이는 배경을 만들기 시작했습니다. 서브에이전트 2는 새를 만들었지만 게임 자원처럼 보이지 않고 Flappy Bird의 새와 전혀 다르게 움직입니다. 이제 마지막 에이전트는 이 두 가지 오해의 결과를 합쳐야 하는 곤란한 일을 떠안습니다.

억지스러운 예처럼 보일 수 있지만, 현실의 작업 대부분에는 잘못 전달될 수 있는 미묘한 차이가 여러 겹으로 쌓여 있습니다. 원래 작업도 맥락으로 서브에이전트에게 그대로 복사해 주면 간단히 해결된다고 생각할 수 있습니다. 그러면 서브에이전트가 자기 하위 작업을 오해하지 않을 테니까요. 하지만 실제 상용 시스템에서는 대화가 여러 차례 이어질 가능성이 큽니다. 에이전트는 작업을 어떻게 나눌지 정하려고 도구를 몇 번 사용했을 수도 있습니다. 수많은 세부사항 중 어느 것이든 작업을 해석하는 방식에 영향을 줄 수 있습니다.

원칙 1
맥락을 공유하라. 개별 메시지만이 아니라 에이전트의 전체 실행 기록을 공유하라

에이전트를 다시 고쳐 보겠습니다. 이번에는 각 에이전트가 앞선 에이전트의 맥락을 갖도록 합니다.

다음 원칙에 차근차근 도달해 보겠습니다.

아쉽게도 아직 문제가 다 풀리지는 않았습니다. 에이전트에 똑같은 Flappy Bird 복제 작업을 주면 이번에는 새와 배경의 시각 스타일이 완전히 다를 수 있습니다. 서브에이전트 1과 서브에이전트 2는 상대가 무엇을 하는지 볼 수 없습니다. 그래서 둘의 작업 결과는 서로 어울리지 않습니다.

서브에이전트 1과 2는 미리 정하지 않은 서로 충돌하는 가정을 바탕으로 행동했습니다.

원칙 2
행동에는 암묵적인 결정이 담긴다. 결정이 충돌하면 나쁜 결과가 나온다

원칙 1과 원칙 2는 너무 중요하고 이를 어길 만한 경우는 매우 드뭅니다. 따라서 이 원칙을 지키지 않는 에이전트 아키텍처는 기본적으로 배제해야 한다고 생각합니다. 제약이 크다고 생각할 수 있지만, 실제로는 여전히 다양한 에이전트 아키텍처를 살펴볼 수 있습니다.

이 원칙을 따르는 가장 간단한 방법은 하나의 흐름을 따라 순차적으로 작동하는 에이전트를 쓰는 것입니다.

다음 원칙에 차근차근 도달해 보겠습니다.

여기서는 맥락이 끊이지 않습니다. 하지만 하위 부분이 아주 많은 대규모 작업에서는 맥락 창이 넘치기 시작할 수 있습니다.

다음 원칙에 차근차근 도달해 보겠습니다.

솔직히 간단한 아키텍처만으로도 상당히 멀리 갈 수 있습니다. 하지만 정말 오랫동안 이어지는 작업을 다루고 기꺼이 노력을 들이려 한다면 더 나은 방법도 있습니다. 이 문제를 푸는 방법은 여러 가지지만 오늘은 한 가지만 소개하겠습니다.

다음 원칙에 차근차근 도달해 보겠습니다.

이 구조에는 별도의 LLM을 추가합니다. 이 LLM은 행동과 대화 기록을 핵심 세부 사항, 사건, 결정으로 압축하는 일을 주로 맡습니다. 이 일을 제대로 해내기는 어렵습니다. 무엇이 핵심 정보인지 알아내고 이를 잘 처리하는 시스템을 만드는 데 투자해야 합니다. 분야에 따라서는 더 작은 모델을 미세 조정하는 방법도 생각해 볼 수 있습니다. 실제로 Cognition에서도 이 방법을 사용했습니다.

이렇게 하면 더 긴 맥락을 효과적으로 다루는 에이전트를 얻을 수 있습니다. 그래도 언젠가는 한계에 부딪힙니다. 관심 있는 독자라면 길이에 제한이 없는 맥락을 더 잘 관리하는 방법을 생각해 보길 권합니다. 파고들수록 상당히 깊은 주제입니다.

원칙 적용하기

에이전트를 만드는 사람이라면, 시스템의 다른 부분에서 내린 관련 결정의 맥락을 에이전트의 모든 행동에 반영해야 합니다. 이상적으로는 모든 행동이 다른 모든 것을 볼 수 있어야 합니다. 안타깝게도 맥락 창의 크기와 현실적인 절충 때문에 늘 가능한 일은 아닙니다. 목표로 삼은 신뢰성 수준에 맞춰 어느 정도의 복잡성을 감수할지 정해야 할 수도 있습니다.

결정의 충돌을 피하는 에이전트 아키텍처를 고민할 때 생각해 볼 만한 현실의 사례는 다음과 같습니다.

Claude Code 서브에이전트
2025년 6월 기준으로 Claude Code는 하위 작업을 시작하는 에이전트의 사례입니다. 하지만 서브에이전트와 동시에 작업하지는 않습니다. 서브에이전트도 보통 코드를 작성하지 않고 질문에 답하는 일만 맡습니다. 왜일까요? 서브에이전트에는 메인 에이전트의 맥락이 없기 때문입니다. 그 맥락이 없으면 명확하게 정해진 질문에 답하는 범위를 넘어서기 어렵습니다. 여러 서브에이전트를 동시에 실행하면 서로 충돌하는 답을 내놓을 수도 있습니다. 그러면 앞선 에이전트 사례에서 살펴본 신뢰성 문제가 생깁니다. 이 경우 서브에이전트를 쓰면 서브에이전트가 조사한 모든 과정을 메인 에이전트의 기록에 남기지 않아도 됩니다. 따라서 맥락이 다 차기 전까지 더 긴 실행 기록을 유지할 수 있습니다. Claude Code 설계자는 의도적으로 단순한 방식을 택했습니다.

편집 적용 모델
2024년에는 코드를 편집하는 능력이 매우 떨어지는 모델이 많았습니다. Devin을 비롯한 코딩 에이전트, IDE, 앱 제작 도구 등에서는 흔히 “편집 적용 모델”을 사용했습니다. 큰 모델이 올바른 형식의 diff를 출력하게 하는 것보다, 원하는 변경 사항을 마크다운으로 설명한 뒤 작은 모델이 파일 전체를 다시 쓰게 하는 편이 더 안정적이라는 생각이 핵심이었습니다. 그래서 제작자는 큰 모델이 코드 변경 사항을 마크다운으로 설명하게 한 다음, 이 설명을 작은 모델에 넣어 파일을 실제로 다시 작성하게 했습니다. 하지만 이런 시스템도 여전히 오류가 잦았습니다. 예를 들어 작은 모델은 큰 모델의 지시를 잘못 이해하고 사소한 모호성 때문에 코드를 잘못 고치곤 했습니다. 오늘날에는 한 모델이 한 번의 행동으로 편집 결정과 적용을 함께 처리하는 경우가 더 많습니다.

멀티 에이전트

정말로 시스템을 병렬로 작동하게 하려면 결정을 내리는 에이전트들이 서로 “대화”하며 문제를 풀게 하는 방법을 떠올릴 수 있습니다.

이상적인 세상에서 사람이 의견이 다를 때 하는 일입니다. 엔지니어 A의 코드가 엔지니어 B의 코드와 병합 충돌을 일으킨다면, 올바른 절차는 차이를 이야기하고 합의에 이르는 것입니다. 하지만 오늘날의 에이전트가 이런 식으로 긴 맥락을 바탕으로 적극적으로 대화한다고 해도, 단일 에이전트보다 훨씬 더 높은 신뢰성을 얻기는 어렵습니다. 사람은 서로에게 가장 중요한 지식을 매우 효율적으로 전달합니다. 하지만 이 효율에는 상당한 지능이 필요합니다.

ChatGPT가 출시된 지 얼마 지나지 않은 때부터 사람들은 여러 에이전트가 서로 상호작용하며 목표를 이루는 방식을 살펴봤습니다 [3][4]. 저는 에이전트끼리 협력하는 방식의 장기적인 가능성을 낙관합니다. 하지만 2025년에는 여러 에이전트를 협력시킬수록 시스템이 불안정해진다는 점이 분명합니다. 결정은 지나치게 흩어지고 에이전트 사이에 맥락을 충분히 공유할 수 없습니다. 지금은 이 어려운 에이전트 간 맥락 전달 문제를 해결하는 데 전념하는 사람이 보이지 않습니다. 개인적으로는 단일 흐름 에이전트가 사람과 더 잘 소통하도록 개선되면 이 능력도 자연스럽게 따라올 것이라고 생각합니다. 그날이 오면 훨씬 더 많은 병렬 처리와 효율을 얻을 수 있습니다.

더 일반적인 이론을 향하여

맥락 설계에 관한 이런 관찰은 언젠가 에이전트 구축의 표준 원칙이라고 부를 이론의 출발점일 뿐입니다. 여기서 다루지 않은 과제와 기법도 많습니다. Cognition은 에이전트 구축을 중요한 개척 분야로 봅니다. 우리는 되풀이해서 깨닫는 이 원칙을 지키기 위해 내부 도구와 프레임워크를 이 원칙에 맞춰 만듭니다. 하지만 우리의 이론도 완벽하지 않을 가능성이 큽니다. 이 분야가 발전함에 따라 이론도 바뀔 것으로 예상하므로 유연성과 겸손도 필요합니다.

app.devin.ai에서 저희가 만든 결과물을 사용해 보시기 바랍니다. 이런 에이전트 구축 원칙을 함께 찾아 나가는 일이 즐겁겠다면 walden@cognition.ai로 연락해 주세요.

후속 글: 멀티 에이전트, 실제로 작동하는 방식

원문: Multi-Agents: What's Actually Working

10개월 전, 나는 멀티 에이전트를 만들지 마세요라는 글에서 대부분의 사람은 멀티 에이전트 시스템을 만들려고 해서는 안 된다고 주장했습니다 [1]. 병렬 에이전트는 스타일, 예외 상황, 코드 패턴에 관해 암묵적으로 선택합니다. 당시에는 이런 결정이 서로 충돌하는 일이 많았고, 그 결과 제품이 취약해졌습니다. 그 뒤로 많은 것이 달라졌습니다.

Cognition에서는 실제로 작동하는 멀티 에이전트 시스템을 배포하기 시작했습니다. 병렬 작성자 무리에 관한 우리의 원래 관찰은 지금도 유효합니다. 이 영역에서 매력적으로 보이는 아이디어 대부분은 여전히 의미 있게 채택되지 않고 있습니다. 하지만 그보다 좁은 범위에서 통하는 패턴을 찾았습니다. 여러 에이전트가 한 작업에 지능을 보태되, 쓰기는 단일 흐름으로 유지하는 구성입니다. 이 글에서는 이런 시스템을 만들며 배운 점을 정리합니다.

맥락 설계 되짚어보기

지난 글에서는 에이전트를 만드는 일을 ‘프롬프트 엔지니어링’이 아니라 ‘맥락 설계’로 다시 바라보자고 제안했습니다. 프롬프트 엔지니어링은 “당신은 시니어 소프트웨어 엔지니어입니다”나 “더 오래 생각하세요” 같은 기교를 부추깁니다. 맥락 설계는 모델의 능력이 시간이 지날수록 좋아진다고 전제하면서 적절한 맥락을 제공하는 데 집중하므로 더 오래갑니다. 여러 이유로 멀티 에이전트 구성에서는 맥락 설계가 매우 어려워질 수 있습니다. 과거에 우리는 다음 원칙을 권했습니다.

에이전트끼리 가능한 한 많은 맥락을 공유하세요. 같은 정보 출처를 보고, 같은 진행 상황을 따르며(할 일 목록, 계획 파일), 완수해야 할 전체 작업에 관해 같은 사전 가정을 공유하게 하세요. 필요하다면 서로 소통하도록 도우세요.
행동에는 암묵적인 결정이 따릅니다. 한 에이전트가 특정 변경이나 수정을 하면 스타일, 코드 패턴, 특정 예외 상황을 처리하는 방법 등을 암묵적으로 선택할 수 있습니다. 이 선택은 다른 병렬 에이전트의 암묵적인 선택과 충돌할 수 있습니다. 따라서 여러 에이전트가 쓰기 작업을 하는 멀티 에이전트 환경에서는 의사 결정이 상당히 파편화될 수 있습니다.

지난 몇 달 동안 많은 것이 달라졌지만, 세심한 맥락 설계의 필요성은 그대로입니다. 두 번째 원칙 때문에 세상의 멀티 에이전트 구성 대부분은 웹 검색이나 코드 검색처럼 ‘읽기 전용’ 하위 에이전트에 한정됩니다. 예를 들어 Devin은 DeepWiki 하위 에이전트를 호출해 코드베이스 맥락을 얻을 수 있습니다. 하지만 이런 하위 에이전트는 진정한 멀티 에이전트 협업보다는 도구 호출에 가깝습니다. 우리는 에이전트가 더 상호작용적인 방식으로 협업할 때 어떤 능력을 열 수 있는지 알아보고 싶었습니다.

지난 10개월 동안 달라진 점

먼저, 모델은 훨씬 더 자연스럽게 ‘에이전트처럼’ 행동하게 됐습니다. 도구 사용, 자신의 맥락 한계, 협업 상대가 사람이든 아니든 그 상대를 위해 맥락을 압축하는 방법을 직관적으로 이해합니다. 그 결과 에이전트 사용량이 말 그대로 엄청나게 늘었습니다. 새로운 기술 도입에 전통적으로 신중했던 대형 엔터프라이즈 고객군에서 Devin 사용량만 보더라도 지난 6개월 동안 약 8배 폭증했습니다.

10개월 전, 나는 ‘멀티 에이전트를 만들지 마세요’라는 글에서 대부분의 사람은 멀티 에이전트 시스템을 만들려고 해서는 안 된다고 주장했습니다 [1]. 병렬 에이전트는 스타일, 예외 상황, 코드 패턴에 관해 암묵적으로 선택합니다. 당시에는 이런 결정이 서로 충돌하는 일이 많았고, 그 결과 제품이 취약해졌습니다. 그 뒤로 많은 것이 달라졌습니다.

이런 사용량 폭증은 멀티 에이전트 시스템을 밀어내는 힘과 끌어당기는 힘을 모두 만들었습니다.

밀어내는 쪽에서는 향상된 능력 덕분에 사용자가 자연스럽게 훨씬 다양한 멀티 에이전트 구성을 실험하게 됐습니다. 많은 에이전트를 사용하다 보면 그 주변의 모든 일, 즉 관리, 계획, 검토가 자연스럽게 병목이 됩니다. 예를 들어 어떤 사람들은 Devin이 다른 Devin을 관리하게 하는 스크립트를 만들었습니다. 코딩 에이전트와 검토 에이전트가 서로 결과를 주고받으며 반복하게 하는 사람도 많아졌습니다.

끌어당기는 쪽에서는 에이전트 사용량 폭증이 비용 폭증으로 이어졌습니다. 더 크고 유능한 새로운 Mythos급 모델이 등장할 예정인 만큼, 최전선 수준의 능력을 더 낮은 비용으로 얻으려면 어떻게 해야 하느냐는 질문이 자연스럽게 생깁니다. 멀티 에이전트 시스템이 그 답이 될 수 있습니다.

수많은 에이전트를 대규모 엔지니어링 프로젝트에 투입한 자극적인 시연도 잇따랐습니다. 대표적인 사례로 웹 브라우저 만들기(코드 20만 줄), C 컴파일러 만들기(코드 10만 줄), LLM 학습 스크립트 최적화(1만 회 넘는 반복)가 있습니다. 흥미로운 사례지만, 실제 소프트웨어 대부분에는 없는 공통점이 있습니다. 단순하고 검증 가능한 성공 기준입니다. 실제 소프트웨어에는 사람의 안목과 의사 결정을 확장하는 시스템이 필요합니다. 우리는 바로 이런 맥락에서 멀티 에이전트 시스템을 탐구하기 시작했습니다.

몇 가지 실제 멀티 에이전트 실험

1) 말도 안 될 만큼 단순한데 통하는 코드 검토 반복

모델이 자기 코드를 검토해 봐야 쓸 만한 문제를 찾지 못할 것이라고 생각하기 쉽습니다. 하지만 Devin이 작성한 PR에서도 Devin Review는 PR 하나당 평균 2개의 버그를 잡으며, 그중 약 58%는 심각한 문제입니다(논리 오류, 누락된 예외 상황, 보안 취약점). 시스템은 여러 차례 코드 검토를 반복하며 매번 새로운 버그를 찾기도 합니다. 시간이 오래 걸릴 수 있으므로 항상 좋은 일만은 아닙니다. 현재 Devin과 Devin Review는 기본적으로 서로 결과를 주고받으며 반복합니다. 사람이 PR을 열 때쯤이면 대부분의 버그가 이미 해결돼 있습니다.

직관에 어긋나는 부분. 흥미롭게도 코딩 에이전트와 검토 에이전트가 사전에 아무 맥락도 공유하지 않을 때 이 기법이 가장 잘 작동했습니다. 왜 그럴까요?

여기에는 철학적 이유와 기술적 이유가 섞여 있습니다. 먼저 에이전트 실행 구조까지 완전히 같더라도 같은 모델을 두 에이전트에 넣는 것이 한 사람이 두 작업을 모두 할 때 상상할 법한 자기 편향이나 상관관계를 그대로 만들지는 않는다는 점을 기억해야 합니다. 결국 에이전트는 주어진 맥락에 따라 작동하는 시스템입니다. 자아가 없으며, 공통된 편향이 있다면 결국 학습 과정에서 나온 것입니다. 요즘에는 그 학습 품질이 상당히 높다고 전제할 수 있습니다.

Deep Dive: 여기서 같은 모델은 같은 학습 가중치를 쓴다는 뜻일 뿐, 같은 작업 상태를 공유한다는 뜻은 아닙니다. 코딩 에이전트는 구현 과정에서 쌓인 맥락에 묶여 있지만, 깨끗한 맥락의 검토 에이전트는 완성된 변경점부터 다시 추론합니다. 따라서 작업 맥락에서 생긴 편향은 줄일 수 있습니다. 다만 두 에이전트는 같은 학습에서 얻은 지식과 맹점을 공유하므로 모델 자체의 편향까지 사라지지는 않습니다.

검토 에이전트가 완전히 깨끗한 맥락에서 시작하면 원래 코딩 에이전트가 파고들지 못한 영역을 더 깊게 살필 수도 있습니다. 우선 명세 없이 구현부터 거꾸로 추론해야 하기 때문에 가능한 일입니다. 원래 에이전트가 사용자 지시의 오류 때문에 놓쳤을 법한 사항도 거리낌 없이 문제 삼을 수 있습니다. 예를 들어 사용자가 안전하지 않은 패턴을 구현하라고 지시한 경우입니다. 더 중요한 이유는 어텐션의 수학적 특성 때문에 깨끗한 맥락에서 에이전트가 더 똑똑해진다는 점입니다. 맥락 부패는 맥락이 길어질수록 모델의 판단력이 떨어지는 잘 알려진 현상입니다. 모델은 보통 어텐션 헤드 수가 제한돼 있습니다. 지시, 프롬프트, 코드 등이 쌓이는 맥락을 다뤄야 하면 중요한 세부 사항이 의사 결정에 충분히 반영되지 않을 수 있습니다. 코딩 에이전트가 몇 시간 동안 작업하며 저장소를 읽고, 명령을 실행하고, 여러 접근법을 고민하고, 오류를 고치면 맥락은 빠르게 커집니다. 전담 검토 에이전트는 이런 불필요한 맥락을 건너뛰고 변경점만 본 뒤, 코드를 처음부터 읽으면서 필요한 맥락을 다시 찾습니다. 맥락이 짧아지면 지능이 좋아지고, 그 결과 미묘한 문제를 더 잘 발견하게 됩니다.

이 시스템을 아주 잘 작동하게 만드는 마지막 핵심은 코딩 에이전트와 검토 에이전트 사이의 소통 다리입니다. 핵심 질문은 Devin이 사용자 지시, 결정 등 더 넓은 맥락을 제대로 활용해 Devin Review가 돌려준 버그를 걸러 내느냐입니다. 반복을 멈추지 못하거나, 사용자의 뜻을 어기거나, 범위를 벗어난 일을 하는 상황 등을 막으려면 반드시 필요합니다. 전용 프롬프트를 조금 제공하면 오늘날의 모델은 여기서 합리적으로 판단할 수 있었고, 두 에이전트와 사람 사이에서 매우 흥미로운 상호작용이 나타났습니다.

요점: 생성자-검증자 반복에서는 깨끗한 맥락이 능력을 눈에 띄게 향상합니다. 하지만 일관된 경험을 만들려면 전체 맥락과 명확하게 소통하고 결과를 종합하는 일이 중요합니다.

2) 크고 비싼 모델의 귀환: ‘Smart Friend’ 소개

지난 몇 달 동안 가장 인기 있었던 모델을 보면 성능을 위해 Anthropic의 Sonnet급 중형 모델에서 Opus급 대형 모델로 뚜렷하게 이동하고 있습니다. Mythos까지 등장하면 사실상 “스케일링이 돌아왔다”고 말할 수 있습니다.

이 흐름에는 곧 최전선 수준의 지능이 일상적인 작업 대부분에 쓰기에는 지나치게 비싸고 어쩌면 느려질 것이라는 조용한 함의가 있습니다. 동시에 작은 모델을 쓰면 처음 예상했던 것보다 작업이 어려운 것으로 드러날 수 있다는 딜레마에 빠집니다.

두 장점을 모두 얻으려면 어떻게 해야 할까요? Windsurf에서는 10월에 초당 950토큰을 처리하는 준최전선 모델 SWE-1.5를 출시하면서 이 목표를 위한 실험을 했습니다. Sonnet 4.5를 ‘계획’에 함께 사용하면 낮은 비용과 빠른 속도를 유지하면서 성능 격차를 조금 줄일 수 있었습니다.

이를 구현한 실제 구조에서는 더 똑똑하고 비싼 모델을 ‘Smart Friend’ 도구로 제공해 주 모델인 작은 모델이 필요할 때 호출하게 했습니다. 즉 상황이 충분히 까다로워서 더 똑똑하고 비싼 모델과 상의할 가치가 있는지를 주 모델인 작은 모델이 판단하게 했습니다. 하지만 곧 맥락 전달과 소통을 설계하는 일이 까다롭다는 것을 알게 됐습니다.

1. 주 모델은 Smart Friend에게 말하는 법을 알아야 합니다.

이 구성에서 핵심적으로 까다로운 문제는 “덜 똑똑한 모델이 자신이 한계에 이르렀다는 것을 어떻게 아는가?”입니다. 똑똑한 주 모델이 작은 하위 에이전트에게 작업을 위임하는 더 일반적인 반대 구성과 달리, 언제 위임할지 결정하는 모델이 더 똑똑한 쪽이 아닙니다. 몇 가지 해결책이 있습니다. 먼저 주 에이전트가 놓친 까다로운 점이 있는지 평가하도록 Smart Friend를 언제나 적어도 한 번 호출하게 할 수 있습니다. 이 판단을 더 정확히 보정하도록 주 모델의 프롬프트를 조정하거나 모델을 학습할 수도 있습니다. 주 모델의 지능에 따라서는 병합 충돌이 생기면 반드시 Smart Friend를 호출하라는 식의 분야별 구체적인 지침이 필요할 수 있습니다.

이 소통 방식에서 또 하나 까다로운 질문은 주 모델이 Smart Friend와 어떤 맥락을 공유해야 하느냐입니다. 더 나아가 주 모델은 Smart Friend에게 무엇을 물어야 할까요? 주 모델이 전체 맥락 중 일부만 공유하면 Smart Friend는 충분한 정보를 바탕으로 판단하지 못할 수 있습니다. 오늘날의 모델에는 주 모델의 전체 맥락을 복제해 Smart Friend와 공유하는 것이 합리적인 80/20 해법이었습니다. 마찬가지로 주 모델이 “무엇을 해야 할까?” 같은 폭넓은 질문을 하고 Smart Friend가 무엇을 논의할 가치가 있는지 판단하게 하는 편이 더 좋았습니다.

2. Smart Friend는 주 모델에게 답하는 법을 알아야 합니다.

첫 번째 방식을 아무리 잘 조정해도 맥락 손실로 인한 품질 공백은 남을 가능성이 큽니다. 반대 방향의 소통을 조정하면 이 공백을 메울 수 있습니다. 예를 들어 주 모델이 important_file.py를 전혀 보지 않은 채 이 파일의 내용을 알아야 답할 수 있는 질문을 Smart Friend에게 했다고 가정해 봅시다. 이때 Smart Friend가 해야 할 올바른 답은 흔히 기본 행동으로 나타나는 추측성 이론을 만들어 내는 것이 아닙니다. 주 모델에게 이 파일을 살펴보고 나중에 다시 물어보라고 구체적으로 지시해야 합니다. 이와 마찬가지로 주 모델이 묻지 않았더라도 지금까지의 에이전트 작업 흐름을 바탕으로 중요한 지침을 제안하도록 Smart Friend에게 요청하는 것이 유익할 때가 많습니다. 요청 범위를 넘어 살피는 이런 Smart Friend가 대체로 더 흥미로운 상호작용을 만든다는 것을 확인했습니다.

Smart Friend에서 실제로 일어난 일

솔직히 말해야 합니다. SWE 1.5는 이 구성이 제대로 작동할 만큼 좋은 주 모델이 아니었습니다. Sonnet 4.5와의 격차가 언제 상위 모델로 넘길지, 무엇을 물을지 아는 능력처럼 이 구성에 꼭 필요한 지점에서 너무 컸습니다. 비용과 속도 이점은 분명했지만 품질 상한은 주 모델이 정했고, 주 모델의 능력이 충분하지 않았습니다. SWE 1.6은 최근 후속 모델로, SWE-bench에서 Opus 4.5 수준의 성능을 냅니다. 훨씬 좋아졌고 이 패턴이 효과를 내기 시작할 만큼 격차를 줄였지만, 아직 우리가 원하는 수준은 아닙니다. 우리는 이것이 학습 문제라고 꽤 확신하며, 향후 SWE 모델은 이런 상호작용을 염두에 두고 학습할 것입니다 [2].

이 패턴이 실제로 잘 작동한 곳은 최전선 모델끼리의 조합이었습니다. 우리는 상당 기간 프로덕션에서 Claude와 GPT를 함께 이 구성으로 운영했고, 가장 까다로운 상황에서 실질적인 개선을 얻었습니다. 흥미로운 발견은 프롬프트 조정 문제가 소형 모델에서 대형 모델로 넘기는 경우와 다르다는 점입니다. 최전선 모델 사이의 소통은 약한 모델이 강한 모델에게 언제 물어야 하는지를 아는 문제라기보다 특정 하위 작업을 가장 잘하는 모델로 보내는 문제에 가깝습니다. 어떤 모델은 디버깅을 더 잘하고, 어떤 모델은 시각적 추론을 더 잘하며, 어떤 모델은 테스트를 더 잘 작성합니다. 위임 로직은 난이도에 따라 상향하는 장치가 아니라 능력에 맞춰 보내는 라우터가 됩니다.

요점: 두 모델이 모두 강할 때 Smart Friend는 오늘날에도 작동합니다. 가장 큰 가능성을 여는 형태는 능력이 비대칭적으로 낮은 주 모델과 함께 작동하게 하는 것이지만, 여전히 풀리지 않은 문제입니다. 우리는 이를 학습 문제라고 봅니다. 의견을 나누고 싶다면 연락해 주세요.

더 높은 수준의 위임을 향하여

앞의 두 패턴은 같은 구조를 가집니다. 작성자는 하나이고, 다른 에이전트가 그 주변에서 지능을 보탭니다. 자연스럽게 이어지는 질문은 이 구조를 더 큰 범위를 맡는 에이전트로 확장할 수 있느냐입니다. 예를 들면 PR 열 개에 걸친 제품 기능, 열두 개 서비스에 영향을 주는 마이그레이션, 오후 한나절이 아니라 일주일짜리 작업입니다.

이 기능은 현재 Devin에서 실제로 작동합니다. 관리자 Devin은 큰 작업을 여러 조각으로 나누고, 하위 Devin을 생성해 작업하게 하며, 내부 MCP를 통해 진행 상황을 조율할 수 있습니다. 일관된 시스템처럼 느껴지게 만드는 데에는 예상보다 훨씬 많은 맥락 설계가 필요했습니다. 작은 범위의 위임으로 학습한 관리자는 지나치게 구체적으로 지시하는 경향이 있습니다. 관리자가 코드베이스를 깊이 이해하지 못하면 이런 방식은 역효과를 냅니다. 에이전트는 실제로는 공유하지 않는 상태를 하위 에이전트와 공유한다고 가정합니다. 에이전트 간 소통도 기본적으로 일어나지 않습니다. 예를 들어 하위 에이전트가 관리자에게 메시지를 보내고, 관리자가 이를 팀의 다른 에이전트에게 전달하는 행동입니다. 모델은 이런 행동이 필요한 환경에서 학습하지 않았기 때문입니다. 각각의 문제를 고치는 데 전담 작업이 필요했고, 지금도 모두 계속 개선하고 있습니다.

구조 없는 무리는 어떨까요? 우리는 임의의 에이전트 네트워크가 서로 협상하는 구조 없는 무리 방식이 대체로 주의를 흐린다고 봅니다. 실제로 쓸 만한 형태는 map-reduce-and-manage입니다. 관리자가 작업을 나누고, 하위 에이전트가 실행하며, 관리자가 결과를 종합해 보고합니다. 이런 시스템이 에이전트 하나가 작업 하나를 수행할 때만큼 일관되게 느껴지도록 만드는 일은 2026년에 진행할 핵심 과제 중 하나입니다.

오늘날 우리가 아는 것

이 모든 실험을 관통하는 공통점이 있습니다. 오늘날 멀티 에이전트 시스템은 쓰기를 단일 흐름으로 유지하고, 추가 에이전트가 행동보다 지능을 보탤 때 가장 잘 작동합니다. 깨끗한 맥락의 검토자는 코딩 에이전트가 보지 못하는 버그를 잡습니다. 최전선급 Smart Friend는 더 약한 주 모델이 놓치는 미묘한 점을 포착합니다. 관리자는 결정을 파편화하지 않으면서 하위 에이전트의 작업 범위를 조율합니다.

아직 풀리지 않은 문제는 모두 소통 문제입니다. 약한 모델은 상위 모델로 넘겨야 할 때를 어떻게 배울까요? 한 하위 에이전트는 형제 에이전트의 작업을 바꿔야 할 발견을 어떻게 알릴까요? 받는 쪽을 맥락에 빠뜨리지 않으면서 에이전트 사이에 맥락을 어떻게 전달할까요? 프롬프트만으로도 제법 멀리 갈 수 있지만, 우리가 직접 학습하는 모델을 포함한 차세대 모델이 이 공백을 메우기 시작할 것으로 기대합니다.

우리는 소프트웨어 개발 생명주기의 모든 단계, 즉 계획, 코딩, 검토, 테스트, 모니터링에 지능을 주입하는 세상을 만들고 있습니다. 자율적인 행위자의 무리가 아니라 사람의 안목을 확장하는 조율된 시스템입니다.

devin.ai나 windsurf.com에서 우리의 작업을 사용해 보세요. 이런 에이전트 구축 원칙을 함께 발견하는 일이 즐거울 것 같다면 walden@cognition.ai로 연락해 주세요.

[1] 공교롭게도 Anthropic은 바로 다음 날 멀티 에이전트 연구 시스템 구축에 관한 관련 글을 공개했습니다. 두 글은 맥락 설계의 비슷한 어려움을 다뤘고, 첫 적용 영역은 읽기 전용 에이전트라는 비슷한 결론에 도달했습니다.

[2] 최근 Anthropic은 작은 모델이 같은 방식으로 큰 모델을 호출하게 하는 비슷한 베타 실험을 시작했습니다. 적어도 이는 ‘Smart Friend’ 쪽 모델도 주 모델에 더 잘 답하도록 발전할 것임을 시사합니다.

Deep Dive

2026-07-16

맥락의 다양성과 모델의 다양성은 다른 문제다

깨끗한 맥락과 서로 다른 모델의 조합은 서로 다른 종류의 편향을 줄입니다. 같은 모델로 검토 에이전트를 따로 실행하면 구현 과정에서 생긴 고정관념을 끊을 수 있습니다. 하지만 같은 학습에서 나온 공통된 지식의 한계는 남습니다. Claude와 GPT처럼 학습 과정이 다른 모델을 함께 쓰면 이런 공통 맹점을 줄이고, 디버깅이나 시각적 추론처럼 각 모델이 잘하는 능력도 골라 쓸 수 있습니다.

그렇다고 여러 모델이 동시에 코드를 쓰게 하는 방식으로 돌아가서는 안 됩니다. 모델마다 내린 암묵적인 결정이 다시 충돌하기 때문입니다. 현재 실용적인 구성은 한 에이전트가 쓰기와 최종 판단을 맡고, 다른 모델은 검토와 조언으로 지능을 보태는 방식입니다. 후속 글에서 Claude와 GPT의 조합이 효과를 냈다는 사례도 이 구조를 따릅니다.

Key Insight

멀티 에이전트의 실용적 가치는 에이전트 수가 아니라 작업 맥락과 모델의 맹점을 얼마나 분리하느냐에 있다. 여러 모델이 지능을 보태더라도 쓰기와 최종 결정은 하나의 흐름으로 유지해야 한다.