Multi-Agent · 21

면접 질문과 여행 일정 실습으로 Supervisor 판단 확장하기

Supervisor 예제가 보고서 파이프라인 하나에만 맞는 구조로 보일 수 있다.

근거 · 교안 p86-p90

1장: 면접 질문, Supervisor의 첫인상

솔라는 태블릿 화면에 떠 있는 워크플로우 다이어그램을 손가락으로 훑었다. ‘자소서 분석 및 예상 질문 생성 Agent 만들기’라는 실습 제목 아래, 여러 Agent들이 화살표로 연결되어 있었다. resume_analyzer, generate_questions, critic, 그리고 final_agent까지. 마치 잘 짜인 컨베이어 벨트처럼 보였다. 그리고 그 모든 흐름의 중심에는 ‘Supervisor’라는 이름의 노드가 자리하고 있었다.

“언니, 이 Supervisor라는 거, 아무리 봐도 역할이 너무 한정적인 것 같아.”

솔라의 말에 거실 테이블 맞은편에서 책을 읽던 루나가 고개를 들었다. 솔라는 루나에게 태블릿을 돌려 보여주었다.

“이 면접 질문 생성 실습에서 Supervisor는 그냥 정해진 순서대로 Agent들을 불러주는 역할이잖아. 자기소개서 분석가(resume_analyzer)를 부르고, 결과가 나오면 질문 생성가(generate_questions)를 부르고. 딱 이 워크플로우에 맞춰진 부품 같아. 이걸 다른 데다 쓸 수 있을까?”

솔라의 손가락은 Supervisor에서 다음 Agent로 나아가는 화살표 위를 맴돌았다. 그녀의 눈에는 Supervisor가 특정 보고서를 만들기 위한, 유연성 없는 중간 관리자처럼 비치고 있었다.

“그럼 이 공장 라인에서 불량품이 나오면 어떻게 될까?”

루나는 솔라의 비유를 그대로 받았다. 그녀는 책을 덮고 테이블 위로 몸을 기울였다. 그리곤 냅킨 한 장을 가져와 펜으로 솔라가 보고 있던 다이어그램을 간략하게 그리기 시작했다. 질문 생성이라고 쓴 동그라미와 평가라고 쓴 동그라미를 그렸다.

“generate_questions Agent가 지원자의 이력서를 바탕으로 질문을 다섯 개 만들었어. 그런데 그걸 넘겨받은 critic Agent가 보더니, 고개를 젓는 거야. ‘이 질문들은 너무 평범해서 지원자의 역량을 제대로 검증할 수 없어. 수정이 필요해(REVISE).’라는 의견을 냈다고 상상해 봐.”

루나는 평가 동그라미 옆에 작은 글씨로 ‘REVISE’라고 적었다.

“자, 그럼 이 ‘REVISE’라는 신호는 어디로 가야 할까? 그리고 그 다음엔 무슨 일이 일어나야 하지? 마지막 보고서를 만드는 final_agent가 이 부실한 질문들을 그냥 받아서 작업을 끝내버릴까?”

솔라는 잠시 생각에 잠겼다. 당연히 그러면 안 됐다. “음… critic이 generate_questions한테 ‘너 다시 해!’ 하고 직접 돌려보내야 하나?”

“그것도 방법일 수 있지.” 루나는 고개를 끄덕였지만, 바로 동의하지는 않았다. “하지만 만약 질문 생성 Agent가 하나가 아니라 여러 종류라면? 그리고 수정 요청의 종류도 다양하다면? ‘질문이 너무 적다’, ‘경력 관련 질문이 부족하다’ 같은 여러 가지 피드백이 있을 수 있잖아. critic이 그 모든 경우의 수를 알고, 어떤 Agent를 다시 호출해야 할지 전부 판단해야 한다면 critic의 역할이 너무 무거워지지 않을까?”

그 말에 솔라의 미간이 살짝 좁혀졌다. Agent 하나가 다른 모든 Agent의 상태와 역할을 속속들이 알아야 한다면, 그건 효율적인 시스템이 아니었다. 각자 자기 일만 잘하면 되도록 만드는 게 핵심일 텐데.

“아…!”

순간 솔라의 눈이 커졌다. 그녀는 냅킨 위에 그려진 다이어그램과 태블릿 화면의 Supervisor를 번갈아 보았다.

“그 ‘REVISE’ 신호를 Supervisor가 받는 거구나! 전체 흐름을 감독하는 건 Supervisor니까. Critic은 그냥 ‘이거 문제 있음’이라고 깃발만 들면 되는 거고, 그 깃발을 본 Supervisor가 판단을 내리는 거야. ‘아, Critic이 수정을 요청했네. 그럼 질문 생성 Agent를 한 번 더 실행시켜서 새로운 질문을 받아와야겠다.’ 이렇게.”

솔라는 자신이 뱉은 말을 곱씹으며 고개를 끄덕였다. Supervisor는 단순히 다음 차례의 Agent를 호출하는 기계적인 역할이 아니었다. 워크플로우의 중간 결과를 계속 지켜보면서, 상황에 맞는 ‘판단’을 내리는 존재였다.

“맞아. 단순히 순서대로 부르는 게 아니었어. Supervisor는 Agent들의 작업 결과를 보고, 특정 조건이 발생하면—방금의 경우처럼 Critic이 ‘REVISE’를 외치면—흐름을 그대로 진행할지, 아니면 특정 단계로 되돌아가서 다시 실행할지, 혹은 아예 전체 작업을 중단할지를 결정하는 거였네.”

솔라는 이제야 Supervisor의 진짜 역할을 깨달은 듯했다. 그녀는 태블릿 화면의 다이어그램을 새로운 눈으로 바라보았다. 화살표들은 더 이상 일방통행 도로로 보이지 않았다. Supervisor를 중심으로 복잡하게 얽혔다가 풀리기를 반복할 수 있는, 유연한 경로처럼 느껴졌다. Supervisor의 역할은 ‘다음 실행할 Agent 선택’뿐만 아니라, ‘재생성 여부와 종료 여부를 판단’하는 것이었다. 바로 이 조건부 재생성 결정 능력이 핵심이었다.

“알겠어. 면접 질문을 만드는 것처럼 최종 결과물의 품질을 계속 확인하고 수정해야 하는 작업에서는 Supervisor가 필수적이겠구나.”

솔라는 만족스럽게 중얼거렸다. 하지만 그녀의 마음 한구석에는 새로운 질문이 고개를 들었다.

“그런데… 결국 이것도 ‘보고서’나 ‘계획안’ 같은 결과물을 만들어내는 과정이잖아. 이런 생성형 작업 말고, 완전히 다른 종류의 일에는 이 패턴을 어떻게 적용할 수 있을지 아직은 잘 모르겠어. 예를 들어, 실시간으로 변하는 데이터를 처리하거나… 아니면 다음 실습 주제인 여행 일정을 짜는 건 좀 다른 문제일까?”

2장: 여행 계획, 또 다른 Supervisor의 얼굴

솔라의 손가락이 태블릿 화면을 스와이프하자, ‘면접 질문 생성 Agent’ 실습 화면이 사라지고 ‘여행 일정 추천 Agent’라는 새로운 제목이 나타났다. 화면 아래에는 예시로 생성된 ‘부산 2박 3일 힐링 여행’ 계획표가 떠 있었다. 빽빽한 글씨로 채워진 일정은 첫눈에 보기에도 잘 짜인 결과물처럼 보였다.

하지만 솔라의 표정은 시큰둥했다. 그녀는 거실 테이블에 놓인 빈 냅킨—조금 전 루나와 면접 질문 워크플로우를 그렸던—을 툭 치며 말했다.

“언니, 이것 봐. 결국 똑같아. 면접 질문이 여행 계획으로 바뀌었을 뿐이잖아.”

루나는 솔라가 내민 태블릿을 들여다보았다. 1일차에는 ‘감천문화마을 → 자갈치시장 점심 → 해동용궁사’, 2일차에는 ‘이기대 해안산책로 → 광안리 드론쇼 → 서면 젊음의 거리’ 등이 나열되어 있었다.

“결국 이것도 최종 ‘계획안’이라는 보고서를 만들어내는 작업이야. 에이전트가 초안을 만들면, Supervisor가 보고 ‘이거 괜찮네, 통과!’ 하거나 ‘이거 별로네, 다시 만들어!’ 라고 하는 거겠지. 면접 질문 만들 때랑 본질적으로 다른 게 뭔지 모르겠어.”

솔라는 Supervisor의 역할이 여전히 특정 ‘생성-검토’ 패턴에 갇혀 있다고 생각했다. 그녀에게 Supervisor는 그저 다른 종류의 보고서를 검수하는, 예측 가능한 관리자일 뿐이었다.

“음, 그럴까?”

루나는 태블릿을 테이블 중앙에 내려놓았다. 그러고는 일정표의 한 부분을 손가락으로 가리켰다.

“이 여행을 요청한 사용자가 ‘사람 많고 복잡한 곳은 싫고, 조용히 쉴 수 있는 힐링 여행’을 원했다고 상상해보자. 이 계획표, 어때 보여?”

솔라는 루나가 가리킨 곳을 다시 살펴보았다. 1일차의 자갈치시장, 2일차의 서면 젊음의 거리. 주말이라면 발 디딜 틈도 없이 붐비는 장소들이었다. 게다가 1일차의 동선을 보니, 부산 서쪽 끝의 감천문화마을에서 동쪽 끝의 해동용궁사로 이동하게 되어 있었다. 지도 앱으로 대충 계산해봐도 차로 1시간이 훌쩍 넘는 거리였다.

“아… 이건 좀. ‘힐링 여행’이라는 주제랑 안 맞는 장소들이 섞여 있네. 그리고 동선도 너무 비효율적이야. 이동하다가 시간 다 보내겠어.”

“그렇지? 그럼 이 상황에서 Supervisor는 어떤 판단을 내려야 할까? 그냥 ‘계획이 마음에 안 드니 다시!’라고만 할까? 면접 질문 예시처럼 단순하게 ‘REVISE’ 신호만 보내면, 여행 계획 Agent가 뭘 고쳐야 할지 어떻게 알 수 있을까?”

루나의 질문에 솔라는 잠시 말문이 막혔다. 면접 질문 생성에서는 critic의 평가 기준이 ‘질문의 질’이라는 비교적 단일한 잣대였다. 하지만 지금 이 여행 계획은 문제가 한두 가지가 아니었다.

“그러네… 그냥 ‘다시 해!’라고 하면 안 돼. ‘추천 장소가 여행 타입과 맞지 않는다’는 지적도 해야 하고, ‘일정이 너무 빡빡하고 동선이 비효율적이다’라는 지적도 따로 해야 해.”

솔라는 깨달았다는 듯 눈을 반짝였다. Supervisor가 내려야 할 판단이 훨씬 더 복잡하고 다층적이라는 것을 알아차린 것이다.

“단순히 결과물이 좋다/나쁘다를 넘어, 여러 기준을 동시에 놓고 검토해야 하는구나. 첫째, 추천된 관광지가 사용자의 여행 ‘타입’과 맞는지. 둘째, 정해진 ‘기간’ 안에 소화하기에 일정이 너무 과밀하지 않은지. 셋째, 장소 간 이동 ‘동선’이 효율적인지… Supervisor는 이 모든 걸 종합적으로 검토하고 판단해야 하는 거였어.”

그녀는 태블릿의 여행 계획표를 새로운 시선으로 바라보았다. 이것은 단순히 하나의 문서를 생성하는 작업이 아니었다. ‘여행 타입’, ‘기간’, ‘장소’, ‘동선’이라는 서로 다른 종류의 정보들을 엮어 최적의 조합을 찾아내는 문제였다. Supervisor는 이 복잡한 관계 속에서 균형을 맞추는 조율자 역할을 하고 있었다.

“알겠다. 면접 질문 생성에서의 Supervisor는 품질 검수관에 가까웠다면, 여행 계획에서의 Supervisor는 여러 요소를 동시에 고려해서 최적의 안을 찾아내는 프로젝트 매니저 같아. 단순히 ‘재생성’을 요청하는 게 아니라, 무엇이 왜 잘못되었는지를 구체적으로 지적하며 복합적인 검토와 재조정을 이끌어내는 거구나.”

솔라의 목소리에는 이전보다 깊은 이해가 담겨 있었다. Supervisor의 역할이 단순한 반복이 아니라, 문제의 종류에 따라 훨씬 더 정교하고 복합적인 판단을 내릴 수 있다는 사실을 받아들인 것이다.

하지만 그녀는 여전히 테이블 위에 놓인 두 개의 실습—면접 질문과 여행 계획—을 번갈아 보았다. 두 가지 모두에서 Supervisor의 더 넓은 가능성을 발견했지만, 마음 한구석의 찜찜함은 완전히 가시지 않았다.

“그래도… 여전히 이건 ‘면접 질문 목록’이나 ‘여행 계획표’처럼, 처음부터 끝까지 정해진 흐름에 따라 최종 결과물을 만들어내는 작업이라는 점은 똑같네. 아직도 Supervisor가 이런 ‘계획 수립’이나 ‘보고서 작성’ 같은 일에만 특화된 것처럼 느껴져. 이걸 넘어서는, 더 근본적인 역할은 없을까?”

3장: Supervisor, 핵심 패턴을 찾아서

솔라는 태블릿 화면의 빈 페이지를 멍하니 바라보고 있었다. 페이지 상단에는 ‘Supervisor 적용 아이디어’라고 쓰여 있었지만, 커서는 그 아래에서 깜빡이기만 할 뿐이었다. 그녀는 조금 전 ‘신제품 출시 계획서 초안 작성’이라고 썼다가 지웠고, ‘분기별 실적 보고서 자동 생성’이라고 썼다가 또 지웠다. 머릿속을 맴도는 아이디어들이 모두 ‘면접 질문 목록’이나 ‘여행 계획표’의 변주처럼 느껴졌다. 전부 정해진 형식의 최종 결과물을 만들어내는 일들이었다.

“안 되겠어. 아무리 생각해도 결국 ‘보고서’나 ‘계획서’ 같은 걸 만드는 일 말고는 딱히 떠오르지가 않아.”

솔라는 투덜거리며 태블릿을 테이블 위에 내려놓았다. 그녀의 답답함은 명확했다. Supervisor의 역할이 ‘조건부 재생성’이나 ‘복합 검토’처럼 정교하다는 것은 이해했지만, 그 적용 범위가 특정 유형의 작업에만 국한되는 것 같다는 찜찜함이 가시지 않은 것이다.

그때, 맞은편에 앉아 있던 루나가 펜을 들어 깨끗한 냅킨 두 장을 나란히 놓았다. 첫 번째 냅킨에는 입구 하나에서 화살표가 두 갈래로 나뉘어 각각 ‘A팀’, ‘B팀’으로 향하는 간단한 그림을 그렸다.

“이건 교통경찰이야. 사거리에서 ‘A 방향 차는 이쪽으로, B 방향 차는 저쪽으로 가세요’ 하고 한번 길을 안내하고 나면 역할이 끝나지. 이걸 우리는 보통 ‘Router’라고 불러.”

루나는 두 번째 냅킨으로 펜을 옮겼다. 이번에는 중앙에 ‘Supervisor’라고 쓴 큰 원을 그리고, 그 주위로 ‘작업자1’, ‘작업자2’라고 쓴 작은 원들을 그렸다. 화살표는 Supervisor에서 작업자들로 나아갈 뿐만 아니라, 작업자들에게서 다시 Supervisor로 돌아오도록 그려졌다. 순환하는 고리 모양이었다.

“하지만 Supervisor는 달라. 단순히 어느 길로 가라고 지시만 하는 게 아니야. 작업자가 일을 마치고 돌아오면, 그 결과물을 보고 판단을 내리지. ‘음, 이 정도면 됐으니 다음 단계로 넘어가자’ 또는 ‘결과물이 기대에 못 미치네. 이러이러한 점을 보완해서 다시 해 와.’ 하고 되돌려 보내기도 하고, ‘더 이상 진행은 무의미하니 여기서 작업을 끝내자’고 결정하기도 해.”

솔라는 두 개의 냅킨을 번갈아 보았다. Router와 Supervisor. 두 그림의 차이는 명확했다. Router는 ‘분기’를 결정하는 단발적인 역할이었지만, Supervisor는 전체 워크플로우의 상태를 계속 지켜보며 ‘반복’, ‘진행’, ‘종료’를 총괄하는 지속적인 역할이었다.

“아…! 나는 지금까지 Supervisor가 만들어내는 최종 결과물이 ‘보고서’냐 ‘계획서’냐 하는 것만 보고 있었어. 그게 아니구나. 중요한 건 결과물의 종류가 아니라, ‘품질을 검토하고 필요하면 다시 시키는 과정’ 그 자체였네.”

솔라의 눈이 번뜩였다. 그녀는 이전의 두 실습을 새로운 관점에서 떠올렸다.

“면접 질문 생성이든 여행 계획이든, 그건 그냥 이 패턴을 적용해 본 예시일 뿐이었던 거야. 면접 실습에서는 critic의 평가를 바탕으로 질문의 품질을 검토해서 재생성을 ‘조율’했고, 여행 일정 실습에서는 추천 장소, 동선, 기간 같은 여러 조건을 종합적으로 ‘검토’해서 계획의 적합성을 판단했어. 두 작업 모두 본질은 ‘결과물의 품질을 특정 기준에 따라 검토하고, 목표에 도달할 때까지 과정을 반복적으로 제어한다’는 거였구나.”

Supervisor는 특정 보고서 파이프라인에 묶인 부품이 아니었다. 그것은 Agent 기반 시스템에서 결과물의 품질을 보장하기 위해 워크플로우 전체를 통제하고 조정하는 일반적인 설계 원칙, 즉 워크플로우 중앙 조정 패턴이었다. 이 깨달음은 솔라를 옭아매던 ‘보고서/계획서’라는 좁은 틀을 단숨에 부숴버렸다.

“그럼… 보고서를 만드는 일이 아니더라도, 과정 중간에 사람의 검토나 판단이 들어가는 일이라면 뭐든지 이 패턴을 적용할 수 있겠네?”

솔라는 흥분한 목소리로 말하며 아까 내려놓았던 태블릿을 다시 집어 들었다. 그녀는 ‘Supervisor 적용 아이디어’ 페이지에 있던 흔적들을 모두 지우고, 새로운 제목을 입력하기 시작했다.

‘Supervisor 패턴 적용 시나리오 제안서 초안: 고객 문의 응대 자동화 시스템’

“예를 들어, 고객 문의가 들어왔을 때 Router가 ‘환불’, ‘배송’, ‘기술 지원’으로 분류해서 넘기는 데서 그치는 게 아니라… 응답을 생성하는 Agent를 두고, Supervisor가 그 초안을 검토하는 거야.”

솔라는 빠르게 키보드를 두드리며 자신의 생각을 구체화했다.

• 1단계: 응답 Agent가 문의 내용에 대한 답변 초안 작성.
• 2단계: Supervisor가 답변 초안 검토.
  • 검토 기준 1: 고객의 감정을 고려한 적절한 어조인가? (예: 불만 문의에 기계적인 답변을 하지는 않았는가?)
  • 검토 기준 2: 문제 해결에 필요한 정보(정책 링크, 절차 안내 등)가 모두 포함되었는가?
• 3단계: Supervisor의 판단.
  • 통과(Proceed): 기준 충족 시, 최종 응답으로 발송.
  • 수정(Revise): 기준 미달 시, ‘어조를 더 공감적으로 수정할 것’, ‘관련 규정 링크를 추가할 것’과 같은 구체적인 피드백과 함께 응답 Agent에게 재생성 요청.

이 시나리오는 더 이상 ‘보고서’를 만들지 않았다. 대신, 상호작용의 ‘품질’을 관리하고 있었다. Supervisor의 역할이 특정 결과물에 국한되지 않는 범용적인 통제 패턴이라는 것을 완벽하게 증명하는 사례였다. 솔라는 만족스러운 미소를 지으며, 방금 완성한 제안서 초안을 루나에게 보여주었다. 더 이상 Supervisor의 역할에 대한 의심은 남아있지 않았다.