Multi-Agent 01

Multi-Agent의 큰 그림: 필요성부터 종합 실습까지

Router, Supervisor, Network 같은 패턴명이 먼저 보이면 전체 학습 흐름이 조각나 보인다.

근거 · 교안 p3-p6

1장: Multi-Agent의 필요성과 패턴 조감도

솔라의 손끝이 모니터 화면 위를 맴돌았다. 화면에는 ‘Multi-Agent 과정’이라는 제목 아래, 학습 목표처럼 보이는 단어들이 나열되어 있었다.

1일차: Router 패턴
2일차: Supervisor 패턴과 오케스트레이터, Network 패턴 (Handoff)

단어들은 익숙했지만, 어쩐지 제각각 흩어져 있는 부품들처럼 느껴졌다. 서로 어떤 관계인지, 왜 이 순서로 배워야 하는지에 대한 설명은 없었다. 솔라는 미간을 살짝 찌푸렸다. 마치 레시피 없이 요리 재료만 잔뜩 늘어놓은 주방을 보는 기분이었다.

“언니, 이것 좀 봐. Router, Supervisor… 꼭 개별 부품 이름 같지 않아? 이걸 다 배우면 뭔가 완성된다는 건 알겠는데, 이것들이 어떻게 하나의 그림으로 합쳐지는지 전혀 감이 안 와.”

솔라의 말에, 소파에서 책을 읽던 루나가 고개를 들었다. 솔라의 모니터를 잠시 들여다본 루나는 말없이 일어나 책상 위에서 깨끗한 노트 한 장과 펜을 가져왔다.

“복잡한 여행 계획을 짜는 에이전트를 하나 만든다고 상상해 보자. 이름은 ‘만능 여행 플래너’라고 할까?”

루나가 노트 위에 큰 동그라미 하나를 그리고 그 안에 ‘만능 여행 플래너’라고 적었다.

“좋지. 그럼 이 에이전트한테 ‘일주일 동안 파리 여행 다녀올게, 최적의 계획을 짜줘!’라고 요청하는 거야.”

솔라는 신이 나서 거들었다. 상상만 해도 편리한 기능이었다.

“그럼 이 에이전트는 항공권을 검색하고, 숙소를 예약하고, 파리 시내 교통편을 알아보고, 맛집 리스트도 만들어야겠네. 또…”

“잠깐.”

루나가 솔라의 말을 끊고 펜으로 ‘만능 여행 플래너’ 동그라미를 꾹 눌렀다.

“항공권을 검색하는 중에 특가 호텔 상품이 떴어. 하지만 이 에이전트는 지금 항공권 최저가 비교에 온 신경을 쓰고 있어. 그 특가 상품은 놓치게 되겠지?”

“음… 그럴 수 있겠네. 그럼 작업을 동시에 여러 개 처리하게 하면 되지 않을까?”

“좋아. 그럼 다른 상황. 항공권과 숙소 예약을 다 마쳤는데, 사용자가 갑자기 ‘날씨를 보니 파리보다 로마가 좋겠어!’라고 마음을 바꾼다면? 우리 ‘만능 여행 플래너’는 이미 진행한 예약들을 취소하고, 로마에 대한 정보를 처음부터 다시 모아야 해. 항공권, 숙소, 교통, 맛집까지. 모든 걸 혼자서.”

루나의 말에 솔라는 잠시 생각에 잠겼다. 한 명의 에이전트가 모든 것을 처리하는 그림. 처음에는 완벽해 보였지만, 변수가 생기자 금세 엉망이 되어버렸다. 너무 많은 일을 하려다 보니 되려 비효율적이고, 하나의 작은 변화가 시스템 전체를 마비시킬 수도 있었다.

“…정말 만능이 아니라, 그냥 과로사 직전의 에이전트네. 하나만 잘못돼도 전체가 멈추거나 엉뚱하게 작동할 테니까.”

솔라가 중얼거렸다. 처음의 기대감은 사라지고, 단일 에이전트가 가진 명백한 한계가 보이기 시작했다.

루나는 고개를 끄덕이며 ‘만능 여행 플래너’라고 적힌 동그라미에 X표를 그었다. 그리고 그 아래에 작은 동그라미 여러 개를 새로 그리기 시작했다.

“그래서 우리는 ‘만능 플래너’ 대신, 각자의 역할을 가진 전문가 팀을 만드는 거야.”

루나는 각각의 동그라미 안에 ‘항공권 전문가’, ‘숙소 전문가’, ‘현지 정보 전문가’라고 적어 넣었다.

“아!”

솔라의 눈이 동그래졌다. 흩어져 있던 점들이 하나의 선으로 이어지는 순간이었다.

“항공권 전문가는 최고의 항공편만 찾고, 숙소 전문가는 사용자의 취향에 맞는 숙소만 찾으면 되는 거구나! 서로 방해하지 않고 동시에 일할 수 있으니까 훨씬 빠르고 효율적이겠네.”

“맞아. 그리고 사용자가 파리에서 로마로 마음을 바꿔도, 우리는 전체 시스템을 갈아엎을 필요가 없어. 각 전문가에게 ‘목적지가 로마로 바뀌었어’라고 알려주기만 하면 되니까.”

이제 솔라는 아까 보았던 그 단어들을 다른 시선으로 바라보게 되었다. ‘Router’, ‘Supervisor’. 이것들은 더 이상 낯선 부품 이름이 아니었다.

“그럼… 사용자가 ‘여행 계획 짜줘’라고 말했을 때, 이 요청을 받아서 ‘항공권 전문가’에게 먼저 보낼지, 아니면 ‘숙소 전문가’에게 보낼지 결정하는 누군가가 필요하겠네. 그리고 이 전문가들이 일하는 순서를 정해주고, 문제가 생겼을 때 해결해주는 감독관도 있어야 하고.”

솔라는 스스로 질문을 던지고 답을 찾아가며, 방금 루나가 그렸던 여러 개의 동그라미들 주위에 새로운 역할들을 상상하기 시작했다. 교통경찰처럼 일의 흐름을 정리해주는 역할, 오케스트라의 지휘자처럼 전체 작업을 조율하는 역할. 그제야 왜 그런 패턴들이 필요한지, 그 이름들이 왜 목록에 있었는지 피부로 와닿았다. 그것들은 Multi-Agent라는 ‘팀’이 유기적으로 협력하기 위한 필수적인 약속이자 전략이었던 것이다.

“이제 저 목록이 다르게 보여. 그냥 기술 이름의 나열이 아니라, 에이전트 팀을 꾸리고 운영하는 과정에서 자연스럽게 생겨나는 질문들에 대한 해답이었네.”

솔라가 모니터를 보며 말했다. 루나는 조용히 미소 지었다. 솔라가 스스로 문제의 본질을 꿰뚫어 본 순간이었다. 한 명의 영웅에게 모든 짐을 지우는 대신, 각자의 전문성을 가진 여러 에이전트가 협력하는 그림. Multi-Agent 시스템의 필요성이 바로 거기에 있었다.

문득, 솔라에게 새로운 궁금증이 생겼다.

“그런데 언니, ‘항공권 전문가’가 좋은 항공편을 찾았어. 그럼 그 정보를 ‘숙소 전문가’한테 어떻게 알려주지? 도착 날짜를 알아야 숙소를 예약할 수 있을 테니까. 이 전문가들이 서로 대화하려면 뭔가 공용 게시판 같은 게 필요한 거 아닐까?”

2장: Multi-Agent를 위한 State 설계

솔라는 루나가 잠시 자리를 비운 사이, 아까 쓰던 노트에 무언가를 열심히 그려 넣고 있었다. ‘항공권 전문가’, ‘숙소 전문가’, ‘현지 정보 전문가’라고 쓰인 동그라미들 한가운데에, 커다란 네모 상자가 자리 잡았다. 솔라는 그 위에 ‘공용 게시판’이라고 큼직하게 썼다. 그리고 ‘항공권 전문가’ 동그라미에서 네모 상자로 화살표를 긋고, 그 옆에 ‘항공편 예약 완료! (파리, 10월 5일 도착)’이라고 적었다. 이어서 네모 상자에서 ‘숙소 전문가’ 동그라미로 화살표를 그리고 ‘도착 날짜 확인!’이라고 메모했다.

스스로 보기에 제법 그럴듯한 그림이었다. 이 게시판만 있으면 모든 전문가가 알아서 필요한 정보를 보고 각자 일을 처리할 수 있을 것 같았다. 하지만 그림을 가만히 들여다볼수록 미심쩍은 구석이 보이기 시작했다. 만약 ‘현지 정보 전문가’가 ‘숙소 전문가’보다 먼저 게시판을 봐서, 확정되지도 않은 숙소 위치를 기준으로 맛집을 추천하면 어떡하지? 아니, 그전에 ‘항공권 전문가’는 수많은 검색 결과 중에서 어떤 정보를 게시판에 남겨야 할까? 최종 확정된 한 건? 아니면 후보 전부? 정보가 뒤죽박죽 섞여 버릴지도 모른다는 생각이 들었다.

돌아온 루나는 솔라가 그려놓은 복잡한 화살표들과 ‘공용 게시판’을 잠시 말없이 들여다보았다. 솔라의 고민을 읽었다는 듯, 루나는 펜을 들어 ‘공용 게시판’이라는 글자 옆에 물음표를 작게 그렸다.

“좋은 시도야. 모든 에이전트가 정보를 공유할 공간이 필요하다는 걸 정확히 짚었어.”

루나는 솔라가 그린 그림을 지우는 대신, 노트의 새 페이지를 펼쳤다. 그리고 깔끔한 표를 하나 그리기 시작했다. 표의 왼쪽 열에는 ‘모두가 알아야 할 정보 (공유 정보)’, 오른쪽 열에는 ‘나만 알면 되는 정보 (개별 정보)’라고 썼다.

“솔라의 ‘공용 게시판’ 아이디어를 조금 더 다듬어 보자. 이 게시판에 무엇이든 다 쓸 수 있다면, 솔라가 방금 걱정한 것처럼 금방 혼란스러워질 거야. 마치 모두가 자기 할 말만 하는 시끄러운 회의실처럼.”

“맞아. ‘항공권 전문가’가 검색했던 수백 개의 항공권 후보 리스트까지 다 올라오면, ‘숙소 전문가’는 대체 뭘 봐야 할지 알 수 없을 테니까.”

“바로 그거야. 그래서 우리는 에이전트 팀의 ‘회의 규칙’을 정해야 해. 어떤 정보는 모두에게 실시간으로 공유해서 항상 최신 상태를 유지하고, 어떤 정보는 각자 알아서 관리하도록 하는 거지.”

루나가 표의 ‘공유 정보’ 열을 펜으로 톡톡 쳤다.

“자, 우리 여행 플래너 팀에게 ‘모두가 알아야 할 정보’는 뭐가 있을까? ‘항공권 전문가’가 일을 끝냈을 때, 다른 전문가들이 반드시 알아야 하는 핵심 정보 말이야.”

솔라는 잠시 고민했다. 수많은 항공권 후보가 아니라, 다른 에이전트의 다음 행동에 직접적인 영향을 주는 정보.

“음… 최종 목적지! 그리고 여행 시작일과 종료일. 마지막으로, 예약이 확정된 항공편명이랑 도착 시간! 그게 없으면 숙소 예약도, 교통편 예약도 시작할 수 없으니까.”

솔라가 답하자, 루나는 그 내용들을 ‘공유 정보’ 열에 하나씩 적어 내려갔다. 목적지: 파리, 여행 기간: 10/5 ~ 10/12, 확정 항공편: KE901 (10/5 18:00 도착).

“좋아. 그럼 반대로 ‘나만 알면 되는 정보’는? 예를 들어 항공권 전문가가 쓰는 정보 중에 다른 전문가들은 전혀 궁금해하지 않을 것들.”

“항공사 웹사이트에 접속하기 위한 비밀번호나 API 키 같은 거? 아니면 더 싼 항공편을 찾기 위해 비교했던 다른 사이트 목록들. 그런 건 ‘숙소 전문가’가 알 필요 없잖아.”

루나는 고개를 끄덕이며 ‘개별 정보’ 열에 항공사 API 키, 검색 기록 등을 적었다. 표가 채워지자, 솔라가 처음 그렸던 막연한 ‘공용 게시판’의 정체가 선명해졌다. 그것은 아무거나 쓰는 메모장이 아니라, 팀의 목표 달성을 위해 엄격하게 관리되는 핵심 데이터의 집합이었다.

“이제 보니 알겠다. 에이전트들이 협력한다는 건, 그냥 서로 대화만 하는 게 아니었어. ‘무엇을 공유하고 무엇을 각자 가질지’를 명확히 설계하는 게 훨씬 중요하구나. 만약 사용자가 여행지를 파리에서 로마로 바꾸면, 우리는 저 ‘공유 정보’ 칸의 목적지만 ‘로마’로 바꾸면 돼. 그럼 각 전문가들은 자기 정체성, 예를 들어 ‘항공권 전문가’라는 역할은 그대로 유지한 채, 바뀐 정보에 맞춰서 자기 일을 다시 처리하겠지. 마치 회의실 화이트보드의 핵심 안건이 바뀐 것처럼.”

솔라는 깨달았다는 듯 무릎을 쳤다. 에이전트의 역할(정체성)을 바꾸는 것과, 에이전트가 참고하는 정보(상태)를 바꾸는 것은 전혀 다른 차원의 문제였다.

“우리가 방금 한 작업이 바로 멀티 에이전트 시스템의 ‘상태(State)’를 모델링한 거야. 이 공유되는 정보 묶음, 즉 ‘State’가 에이전트 팀 전체의 현재 상황을 정의하고, 모든 작업의 기준점이 되어주지.”

루나의 말에 솔라는 아까 그렸던 표를 다시 보았다. ‘공유 정보’와 ‘개별 정보’로 나뉜 표는 더 이상 단순한 목록이 아니었다. 복잡한 문제를 해결하기 위해 협력하는 에이전트 팀의 뇌와 근육을 설계하는 청사진처럼 보였다. 정보의 흐름이 막히거나 꼬였을 때 어디를 봐야 할지 명확해졌다.

그때, 솔라의 머릿속에 또 다른 질문이 떠올랐다.

“알겠어. 이제 에이전트들이 뭘 보고 일해야 하는지는 명확해졌어. 그런데… 사용자가 그냥 ‘유럽 여행 계획 짜줘’라고만 말하면 어떡해? 목적지도, 날짜도 아무것도 정해지지 않은 상태잖아. 이때는 ‘항공권 전문가’랑 ‘숙소 전문가’ 중에 누가 먼저 일을 시작해야 하는 거지? 게시판에 아무것도 안 쓰여 있는데.”

3장: Router 패턴: 에이전트의 의사결정 방식

솔라는 지난번 루나와 함께 정리했던 노트를 펼쳐보았다. 한 페이지에는 ‘만능 여행 플래너’의 실패 원인과 ‘전문가 팀’의 그림이, 다른 페이지에는 에이전트들이 공유할 정보(State)를 정의한 표가 깔끔하게 정리되어 있었다. 이제 이 에이전트 팀은 ‘공유 정보’라는 화이트보드를 중심으로 각자 맡은 일을 효율적으로 처리할 준비가 된 것처럼 보였다.

그때, 루나가 옆에 있던 메모지 한 장을 떼어냈다. 밝은 노란색의 네모난 점착 메모지였다. 루나는 펜으로 그 위에 몇 글자를 적더니, 솔라가 보고 있던 노트 페이지 한가운데, ‘항공권 전문가’와 ‘숙소 전문가’ 동그라미 사이의 애매한 공간에 꾹 눌러 붙였다. 메모지에는 이렇게 쓰여 있었다.

“유럽 여행 계획 짜줘”

솔라의 시선이 노란 메모지에 꽂혔다. 목적지도, 날짜도 없는 막연한 요청. 이것은 지난번 대화의 마지막에 자신이 던졌던 바로 그 질문이었다. 하지만 문장으로 떠다닐 때와 달리, 에이전트들의 그림 위에 실제로 붙어 있는 메모지는 훨씬 더 곤란해 보였다. 저건 대체 누구에게 온 요청이란 말인가?

“항공권 전문가가 이걸 가져가야 하나? 아니면 숙소 전문가가? 둘 다 자기가 뭘 해야 할지 모를 것 같은데.”

솔라가 혼잣말처럼 중얼거렸다.

“맞아. 지금 상태로는 저 메모를 본 두 전문가 모두 어깨를 으쓱할 뿐이겠지. 항공권 전문가는 ‘어느 도시로 가는 항공편을 찾으라는 거지?’ 할 테고, 숙소 전문가는 ‘도착 날짜도 없는데 어떻게 숙소를 알아보지?’ 하고 되물을 거야.”

루나는 솔라가 그린 전문가 동그라미들을 가리켰다. 각자의 전문성은 명확했지만, 지금처럼 모호한 요청 앞에서는 무용지물이었다.

“그럼… 어떡하지? 그냥 둘 다에게 보내고, 알아서 하라고 할까?”

솔라가 일단 떠오른 생각을 말했다. 하지만 곧 스스로 고개를 저었다.

“아니, 그건 낭비야. 두 에이전트 모두 ‘정보 부족’이라는 똑같은 결론을 내릴 때까지 불필요한 연산을 할 테니까. 우리가 ‘만능 플래너’를 포기했던 이유랑 비슷해지잖아.”

바로 그 지점이었다. 루나는 노란 메모지 왼편, 즉 전문가들에게 요청이 닿기 전 단계에 새로운 네모 상자를 하나 그렸다. 그리고 그 안에 ‘안내 데스크’라고 썼다.

“공항에 처음 도착하면 어디로 가지? 항공사 카운터? 아니면 면세점?”

“일단은 전광판이나 안내 데스크부터 확인해야지. 내가 타야 할 비행기 카운터가 어디인지 알아내야 하니까.”

“바로 그거야. 우리 에이전트 팀에도 이런 ‘안내 데스크’가 필요해. 모든 요청을 받아서, 내용을 살펴본 뒤 가장 적절한 전문가에게 연결해주는 역할.”

루나는 ‘안내 데스크’ 상자에서 ‘항공권 전문가’와 ‘숙소 전문가’ 쪽으로 각각 화살표를 그었다.

“자, 그럼 이 안내 데스크의 직원이 되어서 규칙을 만들어 보자. 어떤 요청이 들어왔을 때, 어떤 전문가에게 보내야 할까?”

솔라는 금세 루나의 의도를 파악하고 게임에 참여하듯 눈을 반짝였다. 그녀는 펜을 들고 새로운 요청을 상상하며 입으로 외쳤다.

“만약 ‘파리 왕복 항공권 제일 싼 걸로 찾아줘’라는 요청이 들어오면… 음, 이건 쉽네. ‘항공권’이라는 단어가 있으니 무조건 ‘항공권 전문가’에게!”

“좋아. 다음 문제. ‘에펠탑 근처에 있는 호텔 예약해줘’라는 요청은?”

“그건 ‘호텔’, ‘근처’ 같은 단어가 있으니 ‘숙소 전문가’ 담당이지.”

솔라는 신이 나서 규칙들을 만들어 나갔다. 요청에 포함된 특정 키워드를 기준으로 담당자를 지정하는 것은 명확하고 간단했다. 마치 도서관 사서가 책 제목만 보고도 정확한 서가로 안내하는 것 같았다. 기술적인 네트워크 장비 이름으로만 생각했던 ‘라우터’가, 실제로는 이런 지적인 ‘판단’을 내리는 역할임을 깨닫기 시작했다.

“알겠다! 이 ‘안내 데스크’가 바로 ‘라우터(Router)’ 패턴이구나! 단순히 트래픽을 분산시키는 게 아니라, 들어온 요청의 맥락을 이해하고 가장 적합한 담당자를 지정해주는 ‘책임 분배’의 첫 관문이었어.”

솔라는 자신이 처음 모니터에서 봤던 ‘Router 패턴’이라는 단어를 떠올렸다. 이제 그 단어는 더 이상 낯선 부품이 아니었다. 에이전트 팀의 효율성을 극대화하는 핵심적인 의사결정 과정 그 자체였다.

루나는 고개를 끄덕이며, 솔라가 만든 규칙 목록 아래에 처음의 그 노란 메모지를 다시 가리켰다. “유럽 여행 계획 짜줘.”

“그럼 이 요청은 어떻게 해야 할까? 우리 규칙대로라면 ‘항공권’도 ‘호텔’도 없으니, 이 라우터는 어디로도 보내줄 수가 없는데.”

솔라는 잠시 생각에 잠겼다. 그리고는 무릎을 탁 쳤다.

“아! 어디로 보낼지 결정할 수 ‘없다’는 것 자체가 이 라우터가 내린 중요한 판단인 거네! 라우터는 이 요청을 처리할 전문가가 현재 우리 팀에 없거나, 혹은 정보가 너무 부족해서 작업을 시작할 수 없다고 결론 내리는 거야. 그리고 사용자에게 ‘목적지를 먼저 정해주세요’라고 되묻는 역할을 맡을 수도 있겠네!”

책임을 명확히 나누자, 혼란스러웠던 문제의 진짜 모습이 드러났다. 이제 솔라에게 ‘라우터’는 어떤 요청이 들어왔을 때, 누구의 문을 두드려야 할지 알려주는 현명한 지표가 되었다.

생각을 정리하던 솔라의 머릿속에 새로운 장면이 그려졌다. 라우터가 ‘항공권 전문가’에게 ‘파리행 10월 5일 항공권 검색’이라는 명확한 임무를 전달했다. 이제 ‘항공권 전문가’는 일을 시작할 수 있다. 그런데… 그 일이 한 번에 끝날까?

“언니, 그런데 ‘항공권 전문가’가 일을 시작했다고 치자. 먼저 여러 항공사 사이트를 검색하고, 가격을 비교하고, 좌석이 있는지 확인해야 하잖아. 만약 가장 싼 표를 찾았는데 결제 단계에서 오류가 나면? 그럼 거기서 멈추는 거야? 아니면 차선책을 다시 찾아야 하나? 이 모든 작업 순서랑 돌발 상황 대처는 누가 지시하고 감독하는 거지?”

4장: Supervisor 패턴과 Orchestrator: 에이전트 워크플로 관리

솔라의 펜 끝이 ‘항공권 전문가’라고 쓰인 동그라미 옆에서 망설였다. 라우터가 임무를 정확히 전달해준 다음의 상황. 이제 이 전문가가 해야 할 일들을 구체적으로 그려보고 싶었다. 솔라는 동그라미 옆에 작은 글씨로 번호를 매겨가며 적기 시작했다.

여러 항공사 사이트 검색
가장 저렴한 항공권 가격 비교
최종 항공권 예약 및 결제

단순하고 명쾌한 순서였다. 하지만 펜은 ‘3. 결제’ 단계에서 멈췄다. 만약 결제 시스템에 일시적인 오류가 생긴다면? 솔라는 ‘결제’ 옆에 작은 물음표와 함께 ‘실패하면?’이라고 적었다. 이 간단한 질문 하나가 방금 만든 깔끔한 절차를 순식간에 무용지물로 만들었다. 그냥 멈추는 걸까? 아니면 1번부터 다시 시작해야 할까? 누가 그 결정을 내리는 거지? ‘항공권 전문가’ 혼자서?

옆에서 솔라의 노트를 조용히 지켜보던 루나는, 솔라가 멈춘 것을 보고 펜을 건네받았다. 그리고 솔라가 적은 목록을 지우는 대신, 그 아래 깨끗한 공간에 네모 상자를 하나 그렸다. 상자 안에는 ‘항공권 검색’이라고만 간결하게 썼다.

“솔라가 방금 고민한 건, 한 명의 전문가가 수행해야 할 ‘작업의 흐름’에 대한 문제야.”

루나는 ‘항공권 검색’ 상자에서 오른쪽으로 두 개의 화살표를 그었다. 위쪽 화살표 끝에는 ‘성공’, 아래쪽 화살표 끝에는 ‘실패’라고 적었다. 마치 갈림길처럼.

“자, ‘항공권 검색’에 성공했어. 그럼 다음 단계는 뭘까?”

솔라는 금방 의도를 알아차리고 대답했다.

“성공했으면, 찾아낸 항공권들 중에서 가격을 비교해야지.”

루나는 ‘성공’ 화살표가 가리키는 곳에 ‘가격 비교’라는 새 상자를 그렸다. 다시 그 상자에서 ‘성공’과 ‘실패’ 화살표가 뻗어 나왔다.

“가격 비교에 성공하면? 그 다음엔?”

“예약하고 결제해야지!”

솔라의 대답에 따라 ‘예약/결제’ 상자가 그려졌다. 하지만 솔라의 시선은 아래쪽에 그려진 ‘실패’ 화살표들에 머물러 있었다. ‘항공권 검색’ 실패. ‘가격 비교’ 실패. ‘예약/결제’ 실패. 각각의 실패는 무엇을 의미할까?

“언니, 만약 ‘예약/결제’에 실패하면… 그냥 오류 메시지만 띄우고 끝나는 거야?”

“그렇게 되면, 우리 여행 계획 전체가 저 작은 결제 오류 하나 때문에 멈춰버리는 거 아닐까?”

루나의 반문에 솔라는 정신이 번쩍 드는 것 같았다. “아니, 그러면 안 되지! 가장 싼 표를 놓친 거니까… 그럼 두 번째로 쌌던 표, 즉 차선책으로 예약을 다시 시도해야지!”

솔라는 펜을 다시 가져와 ‘예약/결제’ 상자의 ‘실패’ 화살표 끝에 ‘차선책으로 재시도’라고 적었다. 그러자 새로운 질문이 꼬리를 물었다. 만약 차선책도 실패하면? 세 번째 시도를 해야 하나? 아니면 검색부터 다시? 실패의 종류에 따라 대응도 달라져야 했다. 검색 결과가 아예 없어서 실패한 것과, 결제 직전에 오류가 난 것은 완전히 다른 상황이었다.

“이건… 그냥 작업 목록이 아니네. 거의 하나의 작은 시나리오, 정교한 연극 대본 같아.”

솔라가 자신이 그려 넣은 복잡한 화살표와 상자들을 보며 중얼거렸다. 성공했을 때의 경로, 실패했을 때의 경로, 그리고 특정 조건에 따라 다른 경로로 이동하는 규칙들. 이것은 한 명의 에이전트가 따라야 할 매우 구체적인 행동 지침이었다.

“맞아. 우리는 지금 ‘항공권 전문가’라는 배우가 어떤 무대(상황)에서 어떤 연기(작업)를 해야 할지, 그리고 돌발상황에는 어떻게 대처해야 할지 정해주는 ‘워크플로’를 설계한 거야. 이 전체 흐름을 지휘하고 감독하는 역할이 필요하겠지.”

바로 그 순간, 솔라의 머릿속에서 희미했던 단어 하나가 선명하게 떠올랐다.

“아! 그래서 Supervisor(감독관), Orchestrator(지휘자)라는 말이 있었구나! 단순히 에러가 나는지 감시만 하는 게 아니라, 이 복잡한 작업 흐름 전체를 처음부터 끝까지 책임지고 관리하는 역할이었어.”

처음에 솔라는 Supervisor를 그저 에러 모니터링 도구 정도로 생각했다. 하지만 이제는 달랐다. Supervisor는 에이전트라는 개별 연주자들이 조화롭게 연주하도록 전체 악보를 이해하고 지휘하는 오케스트라의 지휘자와 같았다. 각 단계의 성공과 실패를 판단하고, 그 결과에 따라 다음 작업을 지시하거나, 다른 에이전트에게 순서를 넘기거나, 때로는 전체 작업을 중단시키는 결정을 내리는 총감독. ‘워크플로 제어’라는 개념이 손에 잡힐 듯했다.

솔라는 완성된 워크플로 그림을 만족스럽게 바라보았다. ‘항공권 전문가’는 이제 이 설계도만 있으면 어떤 상황에서도 막힘없이 자신의 임무를 완수할 수 있을 것이다. 그리고 마침내, 모든 성공 경로의 끝에 있는 마지막 상자, ‘결과 저장 (항공편 정보)’에 도달했다.

그림을 보던 솔라의 눈썹이 다시 미세하게 움직였다. 새로운 질문이 고개를 들었다.

“좋아. ‘항공권 전문가’가 이 완벽한 시나리오에 따라 자기 일을 끝냈어. 그럼 이제 이 저장된 ‘항공편 정보’는 어떻게 ‘숙소 전문가’에게 전달되지? 그냥 우리가 만들었던 공유 상태(State) 게시판에 적어두면 ‘숙소 전문가’가 알아서 보고 가져가는 걸까? 아니면 누군가 직접 건네줘야 하는 걸까?”

5장: Network Handoff와 종합 실습: 연결고리 완성

솔라의 노트 위에는 이제 제법 복잡한 그림이 펼쳐져 있었다. 왼쪽에는 ‘항공권 전문가’의 상세한 작업 흐름도(워크플로)가, 오른쪽에는 ‘숙소 전문가’의 비어있는 작업 공간이 그려져 있었다. ‘항공권 전문가’의 워크플로 마지막 단계, ‘결과 저장 (항공편 정보)’ 상자는 진하게 표시되어 있었다. 모든 관문을 통과하고 마침내 임무를 완수한 결과물이었다.

이제 이 정보를 ‘숙소 전문가’에게 넘겨줄 차례였다. 솔라는 펜을 들어 ‘결과 저장’ 상자에서 ‘숙소 전문가’ 쪽으로 쭉 화살표를 그리려 했다. 하지만 펜 끝은 허공에서 잠시 멈칫했다. 그냥 선 하나를 긋는다고 해결될 문제가 아닌 것 같았다. ‘숙소 전문가’는 언제, 어떻게 ‘항공편 정보’가 준비되었다는 사실을 알게 될까? 공유 상태 게시판만 뚫어져라 쳐다보고 있어야 하나? 그건 너무 비효율적이었다. 그렇다고 ‘항공권 전문가’가 직접 ‘숙소 전문가’를 불러서 정보를 건네주는 걸까? 그럼 그 둘의 상호작용은 또 누가 통제하고 관리해야 하지?

솔라가 고민에 빠져 있는 동안, 루나는 조용히 다른 노트 페이지에 간단한 그림 두 개를 그렸다. 첫 번째 그림은 출발선에 선 주자 한 명. 두 번째 그림은 그 주자가 다음 주자에게 바통을 넘겨주는 장면이었다. 루나는 아무 말 없이 노트를 솔라 쪽으로 밀었다.

“계주 경기네.”

솔라가 그림을 보고 말했다.

“첫 번째 주자가 자기 구간을 완주했어. 그 다음엔 무슨 일이 일어나지?”

“당연히 다음 주자에게 바통을 넘겨줘야지.”

“어떻게?”

루나의 짧은 질문에 솔라는 잠시 생각했다. 너무나 당연한 질문이었다.

“음… 정해진 구역 안에서, 다음 주자가 달리기 시작할 타이밍에 맞춰서 손에 확실하게 쥐여줘야지. 만약 그냥 바닥에 던져놓고 가버리면… 실격이거나, 주자가 그걸 줍느라 시간을 다 허비할 테니까.”

그 말을 하는 순간, 솔라는 자신이 망설이던 문제의 답을 스스로 찾았다는 것을 깨달았다. 그녀의 시선이 다시 자신의 노트, ‘결과 저장’ 상자와 ‘숙소 전문가’ 사이의 허공으로 향했다.

“아…! 공유 상태(State)에 정보를 저장하는 건, 마치 바통을 그냥 트랙 위에 던져두는 거랑 똑같구나. ‘숙소 전문가’가 그걸 언제 발견할지도 모르고, 다른 에이전트가 먼저 집어갈 수도 있고. 혼란만 생길 뿐이야.”

단순히 정보를 공유하는 것만으로는 부족했다. 협업은 ‘적절한 시점’에 ‘정확한 대상’에게 ‘필요한 정보’를 능동적으로 전달하는 행위까지 포함하는 것이었다.

“맞아. 그래서 우리 에이전트 팀의 총감독, 즉 오케스트레이터는 한 전문가의 작업이 성공적으로 끝나면, 그 결과를 다음 전문가에게 ‘직접’ 전달하라고 지시해야 해. 이 과정을 ‘핸드오프(Handoff)’라고 부를 수 있겠지.”

루나는 솔라가 그리다 만 워크플로 그림 위에 더 큰 틀을 그리기 시작했다. ‘항공권 전문가’와 ‘숙소 전문가’의 워크플로 전체를 감싸는 거대한 상자였다. ‘여행 계획 오케스트레이터’라는 이름이 붙었다.

“오케스트레이터의 시나리오는 이렇게 되는 거야. 1번, 라우터로부터 작업을 받아 ‘항공권 전문가’를 실행한다. 2번, ‘항공권 전문가’가 성공하면, 그 결과(항공편 정보)를 가지고 ‘숙소 전문가’를 실행한다.”

솔라는 루나의 설명을 들으며 자신의 그림을 수정했다. ‘항공권 전문가’의 ‘결과 저장’ 상자 다음에, ‘숙소 전문가에게 정보 전달(Handoff)’이라는 새로운 상자를 그렸다. 그리고 그 상자에서 ‘숙소 전문가’의 워크플로 시작점으로 화살표를 이었다. 이제야 비로소 두 전문가의 작업이 유기적으로 연결되었다.

“알겠다! Network 패턴이라는 게 이런 거였구나. 단순히 기술적인 통신 방법이 아니라, 에이전트라는 독립된 네트워크 노드들이 어떻게 협력의 바통을 주고받을지 설계하는 거였어.”

솔라는 처음 마주했던 그 낯선 단어들의 목록을 떠올렸다.

Router: 어떤 전문가가 시작해야 할지 결정하고. (책임 분배)
Supervisor: 각 전문가는 자신만의 상세한 시나리오에 따라 임무를 수행하고. (워크플로 제어)
Network (Handoff): 한 전문가가 일을 마치면, 오케스트레이터의 지시에 따라 다음 전문가에게 결과를 안전하게 넘겨준다. (협업 통합)

흩어져 있던 부품들이 제자리를 찾아 하나의 거대한 기계가 완성되는 기분이었다. 처음의 막막함은 사라지고, 복잡한 문제를 해결하는 하나의 명확한 사고 흐름이 눈앞에 그려졌다.

모든 퍼즐 조각이 맞춰진 것을 확인한 솔라는, 문득 새로운 아이디어가 떠오른 듯 눈을 반짝였다. 그녀는 깨끗한 새 노트를 펼쳤다.

“언니, 그럼 만약에… ‘여행 요약 보고서 자동 생성 시스템’을 만든다고 상상해 봐.”

솔라는 주저 없이 노트 위에 그림을 그리기 시작했다. 더 이상 루나의 도움이 필요 없었다.

맨 위에는 [필요성] 이라고 쓰고 ‘한 명의 에이전트가 항공, 숙소, 활동 내역을 전부 요약하는 건 비효율적’이라고 적었다.

그 아래에는 여러 개의 동그라미를 그리고 각각 ‘항공 내역 요약 에이전트’, ‘숙소 내역 요약 에이전트’, ‘활동 내역 요약 에이전트’, 그리고 마지막으로 ‘최종 보고서 작성 에이전트’라고 썼다.

옆에는 [State] 라는 제목 아래 최종 목적지, 여행 기간, 그리고 각 에이전트가 채워 넣을 요약된 항공 정보, 요약된 숙소 정보 등의 항목들을 정리했다.

그리고 노트의 중앙에 전체 시스템의 작동 방식을 그리기 시작했다. [패턴 구현] 이라는 제목과 함께.

Router가 ‘보고서 생성’ 요청을 받아서 각 요약 에이전트에게 동시에 작업을 분배한다.
각 요약 Agent는 각자의 Supervisor가 정의한 워크플로에 따라 정보를 요약한다.
모든 요약 에이전트의 작업이 끝나면, Orchestrator는 이 결과들을 모아 Handoff를 통해 ‘최종 보고서 작성 에이전트’에게 전달한다.
‘최종 보고서 작성 에이전트’가 모든 정보를 취합해 하나의 완성된 보고서를 만든다.

솔라의 펜이 거침없이 움직였다. 그녀는 더 이상 개별 패턴의 이름에 혼란스러워하지 않았다. 대신, ‘필요성 파악 → State 설계 → 책임 분배(Router) → 워크플로 제어(Supervisor) → 협업 통합(Handoff)’으로 이어지는 단계적 사고의 흐름을 이용해 스스로 새로운 멀티 에이전트 시스템을 설계하고 있었다.

루나는 솔라가 그려나가는 명료한 청사진을 조용히 바라보았다. 솔라는 이제 낯선 기술의 숲에서 길을 찾는 여행자가 아니라, 직접 지도를 그리는 설계자가 되어 있었다.