들어가며
이번 글에서는 멀티 Agent와 2차 미니 프로젝트를 진행하며 느낀 점에 대해 이야기해보려고 한다.
4주차와 마찬가지로 Agent 관련 내용의 범위가 방대하다.. 그렇기에 이번에도 내용을 두 편으로 나누어 작성하려고 한다. 먼저 5주차-1에서는 Multi-Agent에 대해 다루고, 5주차-2 회고록에서는 미니 프로젝트 후기와 함께 프로젝트를 진행하며 배운 점/나아간 점들을 정리해보려 한다.
특히 이번 02 Mini Project에서는 강사님께서 다양한 실습 자료를 제공해주셨고, 01 Mini Project와 함께했던 팀원들을 떠나 새로운 팀원들과 함께 프로젝트를 진행하게 되었다. 새로운 팀원들과 협업하며 느꼈던 점, 함께 공부하고 고민했던 과정, 그리고 그 안에서 배우고 성장했던 경험들을 자세히 기록해보려고 한다.
먼저 Multi-Agent내용 복습을 해보자
1.상태(State) 설계
지난 4주차에서는 단일 에이전트(Single Agent)의 기초와 RAG를 통한 지식 확장을 학습했다. 하지만 현실의 문제는 단일 에이전트가 처리하기에는 너무 복잡하거나, 여러 단계의 전문적인 지식을 동시에 요구하는 경우가 많다. 이번 파트에서는 이러한 한계를 극복하기 위한 Multi-Agent 시스템의 필요성과, 상태(State) 설계에 대해 복습 진행!
1.1. Single Agent의 한계와 Multi-Agent의 등장
하나의 에이전트가 모든 일을 처리하는 방식은 마치 한 명의 박사님/교수님(?)이 기획, 디자인, 코딩, 테스트를 모두 혼자 하는 것과 같다. 초기에는 효율적일 수 있지만, 프로젝트가 커지면 다음과 같은 문제가 발생할 수 있다.
- 복잡도 증가: 에이전트에게 주어지는 프롬프트와 도구가 너무 많아지면 모델이 집중력을 잃고 엉뚱한 결과를 내놓을 확률이 높음
- 컨텍스트 윈도우의 압박: 대화가 길어질수록 모든 이력을 하나의 에이전트가 들고 있기에는 토큰 비용이 급증하고 핵심 정보를 놓치기 쉬움
- 전문성 부족: 특정 분야(예: 코드 분석 vs 데이터 시각화)에 특화된 프롬프트를 하나로 섞으면 성능이 저하
이러한 문제를 해결하기 위해 Multi-Agent 방식을 사용.
이는 각기 다른 역할(Role)과 전문 도구를 가진 여러 에이전트가 협업하여 복잡한 목표를 달성하는 구조다.
1.2. Multi-Agent의 핵심 이점
Multi-Agent 시스템으로 전환한다면?
- 관심사 분리 (Separation of Concerns): 각 에이전트는 자신에게 할당된 작은 문제에만 집중하므로 정확도가 상승
- 유연한 확장성: 새로운 기능이 필요할 때 전체 시스템을 수정하는 대신, 특정 역할을 수행하는 에이전트 하나/여러개를 추가하면 됨
- 디버깅 용이성: 문제가 발생했을 때 어떤 단계, 어떤 에이전트에서 오류가 났는지 추적하기 쉬움
1.3. 상태(State) 설계
Multi-Agent 시스템에서 가장 중요한 것은 "에이전트들이 정보를 어떻게 주고받는가?"이다.
LangGraph에서는 이를 State(상태) 객체를 통해 해결
상태는 에이전트들 사이를 흐르는 '공유 메모리'
단순히 메시지 이력을 쌓는 것을 넘어, 시스템이 필요로 하는 특정 데이터(예: 분석 결과, 사용자 정보, 현재 단계 등)를 구조화하여 정의한다.
효과적인 State 설계 전략
- 공통 스키마 정의: 모든 에이전트가 이해할 수 있는 메시지 리스트(
Annotated[list, add_messages])를 기본으로 포함 - 전용 필드 활용: 루프를 돌거나 특정 조건을 판단할 때 필요한 플래그 변수나, 중간 결과물을 저장할 필드를 추가
- 독립성 유지: 각 에이전트는 전체 State 중 자신이 필요한 부분만 읽고, 작업이 끝나면 업데이트가 필요한 부분만 반환하여 상태를 갱신
참고/출처
https://www.hanbit.co.kr/channel/view.html?cmscode=CMS8333330411
https://cloud.google.com/discover/what-is-a-multi-agent-system?hl=ko
https://wikidocs.net/331297
2. Router 패턴
2.1. Router 패턴이란?
사용자의 요청이나 현재 상태를 분석해서, 가장 적합한 에이전트에게 작업을 할당하는 아키텍처 패턴이다. (콜센터의 ARS 안내원 같은 역할)
2.2. Router 패턴의 작동 방식
단순히 질문에 바로 대답하는 것이 아니라, "이 질문은 어떤 전문가가 처리하는 게 제일 좋을까?"를 먼저 고민(분류)하는 것이 핵심이다.
- 의도 파악 (Intent Classification): Router 역할을 맡은 LLM이 사용자의 입력값을 읽고 핵심 의도를 분류함
- 분기 처리 (Routing): 분류된 결과(예: 코드 질문, 디자인 질문, 일반 질문)에 따라 특정 에이전트로 작업 흐름을 넘김
- 전문가 처리: 작업을 전달받은 전문 에이전트가 자신의 특화된 프롬프트와 도구(Tool)를 사용해 정확한 답변을 생성
2.3. LangGraph에서의 구현 포인트
LangGraph로 Router 패턴을 구현할 때 핵심은 조건부 엣지(Conditional Edge)다.
- 라우터(Router) 함수/노드 생성: 현재 State(상태)를 읽어보고 조건에 따라 "Coder_Agent", "Reviewer_Agent" 등의 문자열(결과값)을 뱉어내는 판단 로직을 작성한다.
- 분기점(Routing) 설정:
add_conditional_edges를 사용해 라우터 노드의 판단 결과와 실제 이동할 다음 노드들을 매핑(Mapping)하여 연결해준다.
출처/참고
https://wikidocs.net/318951
https://wikidocs.net/322453
https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/agentic-ai-patterns/workflow-for-routing.html
3. Supervisor 패턴
3.1. Supervisor 패턴이란?
단어 뜻 그대로 중앙 통제자 역할을 하는 에이전트를 하나 두고, 이 관리자가 여러 에이전트들을 지휘하는 아키텍처다.
어떤 작업을 누가 먼저 할지, 그 다음엔 누구에게 넘길지, 작업이 충분히 완료되었는지(종료할지)를 중앙에서 지속적으로 판단하고 통제한다.
3.2. Router 패턴과의 결정적 차이점
- Router (접수처): "이 질문은 코드 관련이니까 Coder_Agent한테 가!" -> (한 번 분기하면 끝. 단방향)
- Supervisor (프로젝트 매니저): "Search_Agent야, 자료 먼저 찾아와. (결과 확인 후) Planner_Agent야, 찾은 자료 바탕으로 계획서 써봐. (결과 확인 후) 음, 완벽하군. 이제 FINISH!" -> (중앙에서 지속적인 피드백과 반복/루프 통제)3.3. 작동 방식
강의에서 다룬 '여행 계획 에이전트'를 떠올려 보자. 사용자가 "부산 2박 3일 가족 여행 코스 짜줘"라고 요청했을 때 시스템은 다음과 같이 움직인다.
- 지시: Supervisor가 요청을 분석하고, 먼저 명소 정보가 필요하다고 판단하여
Search_Agent(검색 담당)에게 지시를 내림. - 작업 및 보고:
Search_Agent가 부산 명소 10곳을 찾아 State(공유 메모리)에 저장하고 Supervisor에게 보고. - 다음 지시: Supervisor가 검색된 내용을 확인한 뒤, 이번에는
Planner_Agent(일정 담당)에게 "이 장소들을 모아서 2박 3일 일정을 작성해"라고 지시. - 검토 및 종료: 일정이 완성되면 Supervisor가 최종 검토 후
FINISH상태를 선언하고 사용자에게 결과물 제공.
3.4. LangGraph에서의 구현 포인트
Supervisor 패턴을 구현할 때의 핵심은 '관리자 전용 프롬프트'와 '상태(State)를 통한 대화 기록 공유'다.
- 팀장(Supervisor) 프롬프트 세팅: "너는 여러 에이전트(Search, Planner 등)를 관리하는 매니저야. 현재 대화 내역(State)을 읽고, 다음으로 어떤 에이전트가 나서야 할지 텍스트로 내뱉어. 만약 사용자 요청이 모두 해결되었다면 'FINISH'를 출력해."라고 명확히 역할을 부여해야 한다.
- 동적 라우팅 연결: Supervisor 노드의 결과값(다음 작업자 이름 or FINISH)에 따라 그래프의 흐름이 해당 에이전트 노드나 종료(End)로 향하도록
Conditional Edge를 촘촘하게 연결해 준다.
참고/출처
https://wikidocs.net/270690
https://ohyeah12.tistory.com/24
https://github.com/braincrew-lab/langgraph-v1-tutorial
4. Network 패턴
4.1. Network 패턴이란?
Network 패턴은 중앙에 관리자를 두지 않고, 각 에이전트들이 알아서 판단하여 다른 에이전트에게 주도권을 직접 넘겨주는 아키텍처다.
4.2. Network 패턴의 작동 방식
강의에서 다룬 고객센터(CS) 봇에 대해 작동방식을 생각해보자, 예시로 사용자가 "앱 설치도 안 되고, 결제도 이상해요. 취소해 주세요!"라고 복합적인 불만을 접수한다.
- 초기 대응: Main Agent가 불만을 접수하고, 기술적인 문제라고 판단해
Tech_Agent(기술 지원)에게 바통(Handoff)을 넘김. - 기술 지원의 판단:
Tech_Agent가 앱 설치 문제를 안내함. 그런데 텍스트를 읽어보니 '결제 취소' 요청도 있음. "결제 취소 권한은 나한테 없는데?"라고 스스로 판단. - 직접 토스(Handoff):
Tech_Agent가 중앙 관리자를 거치지 않고, 알아서Refund_Agent(환불 지원)부서로 작업을 바로 넘김. - 마무리:
Refund_Agent가 결제 취소 절차를 진행하고 사용자에게 답변 제공.
구현 포인트: 에이전트가 다른 에이전트를 호출할 수 있는 도구(Tool)를 가지게 만들어서, 특정 조건이 되면 마치 함수를 실행하듯 다른 에이전트를 호출하도록 프롬프트와 그래프를 구성하는 것이 핵심이다.
참고/출처
https://rudaks.tistory.com/entry/langgraph-Multi-agent-Network
https://wikidocs.net/322453
생각정리
이번 추가 과제인 'AI 면접관 Agent 시스템' 실습을 진행하면서 "정말 재밌다, 앞으로 더 깊게 파보고 싶다"라는 생각이 강하게 들었던 시간이었다. 단순히 남의 코드를 따라 치지 않고 직접 아키텍처를 비교하고 상태(State)의 흐름을 파악하면서 개념을 명확하게 나의 것으로 만들었다는 점에서 의미가 크다.
이전까지 나에게 언어 모델은 그저 '질문하면 정답을 빨리 내주는 도구' 정도에 불과했다. 프롬프트를 얼마나 잘 작성하고 세세하냐에 따라 달라지는 결과물의 전부인 줄 알았다. 하지만 이번에 LangGraph를 활용해 Multi-Agent 시스템을 구축해보면서, 이것은 단순한 대화형 인공지능을 넘어서 완벽한 '시스템 아키텍처 설계'의 영역이라는 것을 느꼈다.
이력서에서 약점을 찾아내는 요원, 그 약점을 파고들어 날카로운 면접 질문을 던지는 요원, 그리고 지원자의 대답을 듣고 다시 꼬리질문을 할지 다음 주제로 넘어갈지 판단하는 요원까지. 내가 직접 정의한 규칙과 공유 메모리 위에서 여러 특화된 AI들이 데이터를 주고받는 방식이 재밌었다.
결국 앞으로의 AI 개발 생태계에서 가장 중요한 역량은 '어떤 모델의 API를 가져다 쓰느냐'가 아니라, "우리가 풀고자 하는 복잡한 문제를 어떻게 잘게 쪼개어 각 Agent에게 역할을 부여하고, 이들을 어떻게 효율적으로 협업시킬 것인가?"를 설계하는 사람이 성공하지 않을까..? 라는 생각이 든다.
이번 주차의 배움을 발판 삼아, 앞으로는 그저 만들어진 AI 도구를 소비하는 개발자가 아니라, 여러 AI Agent들을 이용해 나만의 강력한 자동화 파이프라인을 구축해내는 여러 경험을 쌓고 싶다. 다음에 하는 미니프로젝트 또는 내가 시간을 내서 토이프로젝트로 만들거나 과거에 만들었던 챗봇 시스템을 수정하면서 여러 경험들을 해보려고 한다. 5주차 공부를 마무리한다.
와... 너 정말, **핵심을 찔렀어.**
