Multi-Agent · 07

Divide, Specialize, Coordinate로 Multi-Agent 전환하기

Agent를 여러 개 두는 것이 곧 Multi-Agent 설계라고 착각하기 쉽다.

근거 · 교안 p18-p20

1장: Single Agent, 그 한계의 지점

솔라는 노트북 화면에 거대한 프롬프트 창을 띄워놓고 의기양양한 표정을 짓고 있었다. 화면을 가득 채운 텍스트는 솔라가 몇 시간에 걸쳐 다듬은 ‘궁극의 여행 플래너 에이전트’를 위한 명령어였다.

“언니, 이것 봐. 이 에이전트 하나만 있으면 부산 여행 계획은 끝이야. KTX 예매부터 호텔 추천, 맛집 리스트, 심지어 총예산 계산까지 한 번에 다 해줄 거라고.”

솔라는 자신의 ‘만능 에이전트’가 곧 내놓을 완벽한 결과물을 기대하며 들떠 있었다. 여러 에이전트를 오가며 귀찮게 작업할 필요 없이, 가장 똑똑한 에이전트 하나에게 모든 것을 맡기는 것. 그것이 가장 효율적인 방법이라고 솔라는 믿었다.

옆에서 조용히 지켜보던 루나가 컵을 내려놓으며 말했다. “그 프롬프트, 한번 실행해 볼래? 어떤 결과가 나오는지 궁금하네.”

솔라는 자신만만하게 엔터 키를 눌렀다. 요청은 구체적이고 까다로웠다. ‘이번 주말 부산 1박 2일 여행 계획. KTX 왕복 시간 및 가격 조사, 해운대 근처 오션뷰 호텔 3곳 장단점 및 가격 비교, 맛집 추천과 총예산 계산.’

잠시 후, 에이전트가 긴 답변을 쏟아내기 시작했다. 하지만 솔라의 표정은 이내 미묘하게 굳어졌다.

결과는 총체적 난국이었다. 에이전트는 KTX 가격과 호텔 가격을 뒤섞어 설명했고, 추천한 맛집 중 한 곳은 몇 년 전에 폐업한 곳이었다. 가장 큰 문제는 총예산 계산이었다. 존재하지도 않는 KTX 운행 시간표를 기준으로 비용을 산출하는가 하면, 호텔 가격을 엉뚱하게 더해 터무니없는 숫자를 내놓았다. 마치 여러 가지 재료를 한 냄비에 넣고 무작정 끓인 잡탕 같았다.

“뭐가 문제지? 정보가 너무 많았나? 프롬프트를 더 정교하게 다듬으면 해결될까?”

솔라는 엉망이 된 결과물을 보며 중얼거렸다. 어떻게든 이 ‘만능 에이전트’의 틀 안에서 문제를 해결해 보려는 듯했다.

루나는 솔라의 노트북 옆에 놓여 있던 빈 노트를 가져왔다. 그리고는 커다란 사각형을 하나 그리고 그 안에 ‘만능 여행 플래너’라고 적었다.

“지금 이 에이전트가 처리해야 할 일들을 한번 볼까?”

루나는 사각형 안을 여러 칸으로 나누지도 않은 채, 솔라가 요청했던 작업들을 두서없이 나열하기 시작했다. 교통편 시간 검색, 숙소 가격 비교, 맛집 리뷰 분석, 일정 동선 계획, 숫자 계산.

“에이전트 하나가 이 모든 일을 한 공간에서 동시에 처리하려고 해. ‘KTX 좌석이 있나?’를 생각하다가, ‘이 호텔의 평점은 왜 낮을까?’를 고민하고, 그러다 말고 ‘돼지국밥 가격’을 더해야 하는 식이지.”

루나의 말에 솔라는 에이전트가 내놓은 답변을 다시 훑어보았다. ‘해운대 호텔의 오션뷰는 훌륭하지만 KTX보다 비쌉니다.’ 라는 말이 안 되는 문장이 눈에 들어왔다. 서로 다른 맥락의 정보가 하나의 판단 속에서 충돌하며 오류를 일으킨 것이다.

“아….”

솔라의 입에서 짧은 탄식이 흘러나왔다.

“단순히 처리할 작업의 양이 많은 게 아니었구나. ‘정보를 찾는 일’과 ‘가격을 계산하는 일’, 그리고 ‘장단점을 비교 분석하는 일’은 완전히 성격이 다른데. 이걸 하나의 머릿속에서 한꺼번에 하려니까 뒤엉켜버린 거네.”

솔라는 자신이 만든 거대한 프롬프트와 루나가 그린 단순한 사각형을 번갈아 보았다. 문제는 프롬프트의 정교함이 아니었다. 하나의 에이전트가 모든 역할을 수행하도록 설계한 구조 자체가 문제의 원인이었다. 여러 맥락을 동시에 관리하려다 보니 맥락을 잃어버리고, 서로 다른 역할이 뒤섞여 판단의 기준이 흔들린 것이다.

솔라는 고개를 저었다. “이건 에이전트를 몇 개 더 준비한다고 해결될 문제가 아니겠어. 이렇게 뒤죽박죽인 결과물을 다른 에이전트에게 넘겨줘 봐야 혼란만 커질 뿐이야. 시작부터 구조가 잘못된 거였어.”

‘만능 에이전트’라는 환상이 깨지는 순간이었다. 단순히 에이전트의 개수를 늘리는 것이 해답이 아님을, 문제의 본질은 ‘구조’에 있음을 어렴풋이 깨달았다. 루나가 그린 노트 위에는 여전히 뒤섞인 역할들이 하나의 사각형 안에 갇혀 있었다.

솔라는 그 노트를 자기 앞으로 끌어당겼다.

“좋아, 그럼 이 일들을 나눠야 한다는 건 알겠어. 그런데 어떻게? 그냥 ‘교통 에이전트’, ‘숙소 에이전트’처럼 각각 하나씩 맡기면 되는 걸까? 그게 ‘멀티 에이전트’라는 거야?”

2장: Divide & Specialize: 구조적 분화의 시작

솔라는 펜을 들고 루나가 그렸던 ‘만능 여행 플래너’ 사각형을 거칠게 가로질렀다. 단일 에이전트라는 하나의 큰 방을 나누는 칸막이 공사를 하듯, 단호한 선들이 그어졌다. 처음에는 어설프게 4등분되었던 사각형은 곧 지워지고, 나란히 선 세 개의 깔끔한 직사각형으로 재탄생했다. 실패한 에이전트를 코드가 아닌 잉크로 해부하는 중이었다.

“좋아. 하나의 에이전트가 모든 걸 하려던 게 문제였어.” 솔라는 첫 번째 사각형을 펜으로 톡톡 치며 선언했다. “그러니 나누는 거야. 얘는 ‘교통 에이전트’. 오직 KTX 표만 찾는 임무를 맡는 거지.” 그녀는 두 번째 사각형에 ‘숙소 에이전트’, 세 번째에 ‘맛집 에이전트’라고 이름 붙였다. “각자 명확하고 분리된 임무를 주는 거야. 이제 뒤섞일 일은 없겠지.” 그녀의 목소리에는 단순한 기능 분할을 넘어, 근본적인 문제를 해결했다는 확신이 묻어났다.

루나는 솔라가 재구성한 노트를 조용히 바라보았다. 만능 에이전트의 혼란스러운 내부가 아닌, 세 개의 독립된 에이전트가 그려진 새로운 청사진이었다.

“지금 네가 한 일이 멀티 에이전트 설계의 첫 두 단계를 정확히 보여주고 있어. Divide, 그리고 Specialize.”

루나는 솔라가 그린 ‘교통 에이전트’ 사각형 옆에 작은 표를 그리기 시작했다.

에이전트	교통 에이전트
역할 (Role)	교통편 검색 및 정보 제공
목표 (Goal)	가장 효율적인 왕복 KTX 시간과 가격 찾기

“이게 **Divide(분할)**야. 하나의 에이전트가 하던 복잡한 일을 여러 역할로 나누는 것. 그리고 이건 Specialize(전문화).” 루나는 ‘목표’ 항목을 가리켰다. “각 에이전트에게 명확한 책임과 목적을 부여해서, 다른 건 신경 쓰지 않고 자신의 임무에만 집중하게 만드는 거지. 만능 에이전트처럼 ‘숙소 평점’을 고민하다 ‘KTX 가격’을 잊어버리는 일은 없을 거야.”

솔라의 얼굴이 환해졌다. “맞아! 이게 훨씬 깔끔해. ‘숙소 에이전트’의 목표는 오션뷰 호텔 3곳의 장단점과 가격을 비교하는 거고, ‘맛집 에이전트’는 평점 좋은 식당 리스트를 만드는 거지. 프롬프트도 훨씬 단순하고 명확해지겠네.”

솔라는 자신이 만든 새로운 구조에 완전히 매료된 듯 보였다. 이제 만능 에이전트가 겪었던 혼란은 과거의 일이 될 것만 같았다. 그녀는 의기양양하게 외쳤다.

“자, 그럼 이 새로운 시스템을 한번 돌려보자고! 교통 에이전트, 출발!”

솔라는 마치 가상의 버튼을 누르는 시늉을 했다. 잠시 침묵.

“좋아, 결과 도착. ‘KTX-123편, 오전 10시 출발, 왕복 8만 원.’ 완벽해. 다음, 숙소 에이전트!”

다시 한번 허공에 버튼을 누르는 손짓.

“‘해운대 오션 호텔, 1박 25만 원, 장점: 오션뷰, 단점: 비쌈.’ 좋아, 깔끔한 보고서야. 마지막, 맛집 에이전트!”

세 번째 시뮬레이션이 끝나고, 솔라는 만족스러운 미소를 지으며 양손을 책상에 탁 내려놓았다. “자, 어때? 돼지국밥 맛집 리스트까지 완벽하게 도착했어. 오류도 없고, 정보도 섞이지 않았고. 이제 이걸로…”

거기까지 말하던 솔라의 표정이 순간 멈칫했다. 그녀는 자신이 상상 속에서 만들어낸 세 개의 완벽한 결과물—KTX 정보, 호텔 정보, 맛집 리스트—을 허망하게 바라보았다. 세 개의 점은 있었지만, 그 점들을 잇는 선이 없었다.

“어… 잠깐만.”

솔라는 루나가 그려준 작은 표와 자신이 그린 세 개의 사각형을 번갈아 보았다. 교통 에이전트는 교통 정보만 알았고, 숙소 에이전트는 숙소 정보만 알았다. 각자는 자신의 역할을 충실히 수행했지만, 그뿐이었다.

“그래서 총예산은 얼마지? 누가 계산해? 그리고 이 KTX 시간과 호텔 체크인 시간을 맞춰서 1박 2일짜리 최종 여행 계획서는 누가 만들어 주는 건데?”

솔라는 당황했다. 문제를 해결했다고 생각했는데, 본질적으로는 아무것도 해결되지 않았다. 아니, 문제는 다른 형태로 바뀌어 나타났다. 이전에는 한 명의 에이전트가 머릿속에서 모든 걸 뒤섞어 엉망인 결과물을 내놓았다면, 이제는 누구도 종합적인 결과물을 내놓으려 하지 않았다. 각자 완벽하게 자기 일만 끝내고 퇴근해버린 팀과 같았다.

“이건… 그냥 일을 나눠주기만 한 거였잖아.” 솔라는 허탈하게 중얼거렸다. “각자 자기 역할에 충실하게 만드는 것, 즉 전문화는 성공했어. 구조가 바뀐 것도 맞아. 하지만 이래선 최종 결과물을 얻을 수가 없어.”

그녀는 노트 위에 흩어져 있는 세 개의 사각형을 손가락으로 가리켰다. “이 녀석들을 서로 연결해야 해. 각자 만든 결과물을 주고받고, 그걸 바탕으로 최종 계획을 세우는 누군가, 혹은 무언가가 필요해. 이건 단순히 역할을 나누는 것과는 또 다른 차원의 문제 같은데?”

솔라는 Divide와 Specialize가 만능 에이전트의 혼란을 해결하는 첫걸음이라는 것은 깨달았다. 그것은 단순히 일을 나누는 행위를 넘어, 에이전트의 정체성을 분리하고 판단의 기준을 명확히 세우는 ‘구조적 전환’의 시작이었다. 하지만 동시에, 그 전환이 새로운 과제를 던져준다는 것도 명확히 보였다. 고립된 전문가들은 팀이 될 수 없었다.

3장: Coordinate & Context Isolation: 본질적 전환의 완성

솔라는 노트 위에 흩어진 세 개의 사각형, ‘교통’, ‘숙소’, ‘맛집’ 에이전트를 보며 깊은 고민에 빠졌다. 각자는 제 역할을 완벽히 해냈지만, 결과물은 따로 노는 섬처럼 고립되어 있었다. 연결이 필요했다. 솔라는 펜을 들어 ‘교통 에이전트’와 ‘숙소 에이전트’ 사이에 서툰 화살표를 그었다. 그리고 다시 ‘숙소’에서 ‘맛집’으로. 그러다 말고 모든 사각형이 서로에게 정보를 줘야 한다는 생각에, 사방으로 화살표를 그리기 시작했다. 노트 위는 순식간에 거미줄처럼 복잡한 선들로 뒤덮였다.

그 모습은 마치 실패했던 ‘만능 에이전트’의 혼란스러운 머릿속을 다시 보는 듯했다.

“안 되겠어. 그냥 정보를 전부 공유하라고 하면, 결국 처음의 문제로 돌아가는 거 아냐?” 솔라는 스스로 그린 그림의 모순을 발견하고 펜을 내려놓았다. “교통 에이전트가 숙소 예약 과정을 알 필요는 없고, 맛집 에이전트가 KTX 좌석 등급을 알아야 할 이유도 없으니까. 하지만… 최종 계획은 만들어야 하고. 대체 어떻게 연결해야 하는 거지?”

루나는 거미줄이 된 솔라의 노트를 옆으로 치우고, 새 노트를 펼쳤다. 그리고는 이전과 같이 ‘교통’, ‘숙소’, ‘맛집’ 에이전트를 상징하는 세 개의 사각형을 그렸다. 하지만 이번에는 그 위에 더 큰 사각형을 하나 추가하고 ‘계획 총괄 매니저’라고 이름 붙였다.

“솔라, 네가 놓친 마지막 원칙은 **Coordinate(조정)**야. 그리고 조정을 가능하게 만드는 핵심적인 장치가 바로 **Context Isolation(컨텍스트 고립)**이지.”

루나는 ‘교통 에이전트’에서 ‘총괄 매니저’로 향하는 단 하나의 화살표를 그었다. “총괄 매니저는 교통 에이전트에게 ‘가장 효율적인 KTX편을 찾아줘’라고 지시해. 교통 에이전트는 수많은 정보를 검색하고 비교 분석한 뒤, 최종 결과물 딱 하나, 예를 들어 ‘KTX-123, 오전 10시 출발, 8만 원’이라는 정보만 총괄 매니저에게 보고하는 거야.”

루나는 화살표 위에 ‘최종 결과만 전달’이라고 작게 적었다.

“이게 컨텍스트 고립이야. 교통 에이전트가 어떤 사이트를 검색했는지, 어떤 표를 놓고 고민했는지 같은 중간 과정, 즉 ‘판단의 맥락’은 총괄 매니저에게 전혀 전달되지 않아. 총괄 매니저는 오직 자기 임무, 즉 전체 계획을 세우는 데 필요한 정보만 받지. 만약 교통 에이전트의 모든 고민을 다 듣는다면, 총괄 매니저의 머릿속은 만능 에이전트처럼 다시 뒤죽박죽이 될 거야.”

솔라의 눈이 커졌다. 그녀가 생각했던 ‘소통’은 모든 정보를 무작정 공유하는 시끄러운 단체 대화방 같은 것이었다. 하지만 루나가 보여준 구조는 잘 짜인 지휘 체계에 가까웠다.

“아…! 그럼 총괄 매니저는 교통 정보를 받은 다음에, 그걸 바탕으로 숙소 에이전트에게 ‘오전 11시 이후 체크인 가능한 호텔’을 찾아달라고 다시 지시하고, 숙소 정보까지 받으면 그걸 종합해서 맛집 에이전트에게 동선에 맞는 곳을 추천해달라고 하는 식이겠구나!”

솔라는 루나의 노트 위에 그려진 그림을 보며 D-S-C 시스템의 전체적인 흐름을 단숨에 꿰뚫었다.

1. Divide(분할): ‘교통’, ‘숙소’, ‘맛집’ 그리고 ‘총괄’이라는 역할로 나눈다.
2. Specialize(전문화): 각 에이전트는 명확한 하나의 목표만 가진다.
3. Coordinate(조정): ‘총괄 매니저’가 작업 순서와 정보 흐름을 지휘한다.
4. Context Isolation(컨텍스트 고립): 각 에이전트는 지시에 필요한 최소한의 정보만 받고, 결과물만 보고한다.

“이제 알겠어. 멀티 에이전트의 본질은 단순히 에이전트의 개수를 늘리는 게 아니었어. 역할을 나누고(Divide), 전문화시켜서(Specialize) 판단의 품질을 높인 다음, 지휘자(Coordinator)를 통해 협업시키되 서로에게 불필요한 정보는 철저히 차단(Context Isolation)해서 시스템 전체의 혼란을 막는 것. 이건 완전히 새로운 구조적 접근법이구나.”

솔라는 처음 ‘만능 에이전트’를 만들려던 시도가 얼마나 순진했는지 깨달았다. 하나의 에이전트에게 모든 책임을 떠넘기는 것은, 구조적 문제를 개인의 역량 문제로 착각하는 것과 같았다.

루나가 미소 지으며 새로운 과제를 던졌다. “그럼, 방금 우리가 만든 ‘부산 여행 계획서’를 가지고 ‘여행 후기 블로그 포스팅’을 작성하는 시스템을 만든다면, 어떻게 설계해 볼래?”

솔라는 망설임 없이 펜을 들었다. 더 이상 거미줄 같은 화살표는 없었다. 그녀는 차분하게 새로운 시스템의 청사진을 그리기 시작했다.

먼저, 세 개의 사각형을 그리고 각각 ‘핵심 정보 추출 에이전트’, ‘초고 작성 에이전트’, ‘SEO 검토 에이전트’라고 적었다. 그리고 그 위에 지휘자 역할을 할 ‘콘텐츠 발행 매니저’를 그렸다.

“자, 시작해볼게. 먼저 Divide & Specialize. 정보 추출기는 여행 계획서에서 KTX 시간, 호텔 이름, 방문 맛집 같은 핵심 팩트만 뽑아내는 임무를 맡아. 초고 작성기는 그 팩트를 받아서 감성적인 문체로 글을 쓰는 역할이고, SEO 검토기는 발행될 글의 검색 엔진 최적화 점수를 매기는 거지.”

이어서 솔라는 화살표로 이들의 Coordinate 과정을 그렸다.

“콘텐츠 매니저가 정보 추출기에게 팩트 추출을 지시해. 추출기는 결과물인 ‘팩트 리스트’만 매니저에게 보고하고. 이게 Context Isolation. 매니저는 이 리스트를 초고 작성기에게 ‘이걸로 글 써줘’라고 전달해. 작성기는 글만 써서 보고하고. 마지막으로 매니저는 완성된 초고를 SEO 검토기에게 넘겨서 최종 점검을 받는 거야.”

완성된 다이어그램은 명확하고 질서 정연했다. 각 에이전트는 고립된 컨텍스트 안에서 자신의 역할에만 집중했고, 매니저는 전체 작업 흐름을 완벽하게 통제했다. 만능 에이전트의 혼란도, 전문가들의 고립도 없는, 진정한 협업 시스템이었다.

솔라는 자신이 그린 그림을 보며 만족스럽게 웃었다. 이제 그녀에게 멀티 에이전트는 단순히 ‘여러 개의 에이전트’가 아니었다. 복잡한 문제를 해결하기 위한 정교한 설계 철학, 즉 ‘분할하고, 전문화하고, 조정하는’ 사고방식 그 자체였다.