Agent Roundtable: 로컬 다중 에이전트 전문가 라운드테이블 시스템 구축

최근 나는 다중 Agent 채팅 프로젝트인 agent_roundtable을 만들었다.

아이디어는 단순하다. 하나의 주제를 던지면, 시스템이 서로 다른 관점을 가진 몇 명의 “전문가 Agent”를 번갈아 발언하게 하고, 진행자가 추궁·연결·요약을 맡아 마지막에는 전체 토론을 Markdown 보고서로 저장한다.

이는 단순 채팅봇이 아니다. 역할을 설정하고, 모델을 구성하며, 로컬 지식베이스를 붙이고, 토론 과정을 문서화하는 로컬 Agent 워크플로우다.

나는 이를 “전문가 원탁 도구”로 이해한다. 하나의 모델이 모든 답을 한 번에 내놓는 방식이 아니라, 하나의 주제를 여러 관점의 Agent에게 나눠주고 같은 주제를 중심으로 토론하게 하는 방식이다.

1. 왜 이 프로젝트를 만들었는가

나는 오래전부터 하나의 질문을 계속 고민해왔다. 실제로 유용한 AI Agent 시스템은 무엇이어야 할까?

단일 Agent는 시작하기가 쉽다. 프롬프트를 넣으면 질문에 답하고, 도구를 호출하고, 요약까지 해준다. 이 방식만으로도 많은 일을 할 수 있다. 그러나 문제의 복잡성이 커지면 단일 Agent의 한계가 분명해진다.

• 서로 다른 관점을 섞어버리기 쉽다.
• 여러 전문 역할을 안정적으로 수행하기 어렵다.
• 답변이 실제 토론이 아니라 통합 에세이처럼 느껴진다.
• “거시경제 관점”, “투자 관점”, “AI 기술 관점”, “철학적 관점”, “역사적 전략 관점”을 분명히 구분하기 힘들다.

그래서 다중 Agent 라운드테이블을 만들고 싶었다.

하나의 주제를 여러 전문가가 각각 다른 방식으로 다루면 된다. 거시전문가는 제도와 사이클을 본다, 투자 전문가는 현금흐름과 리스크를 본다, AI 전문가는 기술 진화를 본다, 철학 전문가는 개념과 가치 판단을 본다, 역사 전략 전문가는 장기 구조를 본다.

이렇게 하면 출력이 더 이상 “한 모델의 답”이 아니라 구조화된 토론으로 바뀐다.

2. 지금 이 프로젝트가 할 수 있는 일

agent_roundtable은 현재 Python 기반 로컬 프로젝트로, CLI와 로컬 웹 UI 두 가지 방식으로 실행할 수 있다.

현재 주요 기능은 다음과 같다.

• CLI 또는 로컬 Streamlit UI로 다중 Agent 라운드테이블 실행
• 각 Agent를 개별적으로 provider, 모델, API key 환경변수 이름 기준으로 설정
• API key는 .env에만 저장되며 JSON, YAML, 로그, 보고서에는 기록되지 않음
• 메인 전문가들이 각각의 로컬 장문 자료를 읽고 RAG로 관련 내용을 검색
• 실행 결과가 자동으로 logs/에 저장되어 Markdown 보고서로 생성됨
• 각 발언마다 사용한 provider와 model이 보고서에 표시됨
• API key가 없어도 --mock로 전체 파이프라인을 먼저 점검할 수 있음

현재 프로젝트에는 라운드테이블이 두 개 내장되어 있다.

여기서 특히 말하자면, persona_inspired는 “인물 흉내”가 아니라 “사고 스타일 영감”이다. 어떤 인물을 가장화하거나 대변하지 않는다. 특정한 사고 방식으로 답변을 구조화하도록 돕는 장치다.

3. 내가 보는 Agent의 정의

요즘 Agent라는 단어는 매우 인기다. 그런데 너무 추상적으로 쓰면 오히려 이해하기가 어렵다.

내가 보는 Agent는 “대화하는 모델”이 아니다. 목표를 중심으로 과제를 수행하는 시스템 단위다. 보통 다음 요소를 포함한다.

• 역할 또는 목적
• 프롬프트와 행동 제약
• 호출 가능한 도구
• 갱신 가능한 상태
• 필요에 따라 기억, 지식베이스, 워크플로우 제어

일반 대화는 “질문 하나, 답 하나”다. Agent는 “목표를 달성하기 위해 다음에 무엇을 할지 스스로 판단”한다.

Tool Use가 붙으면 Agent는 검색, 파일, 데이터베이스, 코드 실행 같은 도구를 호출할 수 있다. RAG가 붙으면 먼저 자료를 조회하고 답한다. 워크플로우가 붙으면 여러 Agent가 순차적으로 협업한다.

이것이 내가 agent_roundtable을 만든 이유다. 나는 프롬프트 수준에서 멈추지 않고 역할, 지식, 모델 호출, 실행 흐름을 프로그래밍적으로 엮고 싶었다. 스마트 에이전트의 기초부터 ReAct 패턴, 기억과 RAG 입문을 더 체계적으로 보고 싶다면 《Hello-Agents: AI Agent를 처음부터 구축하는 오픈 소스 튜토리얼》을 참고하면 된다.

4. 왜 다중 Agent인가, 거대 Agent가 아닌가

거대 Agent도 복잡한 질문에 답할 수 있다. 하지만 나는 다중 Agent 형식을 더 선호한다.

이유는 단순하다. 현실의 복잡한 판단은 한 목소리로 끝내기 어렵다.

예를 들어 “AI가 투자와 고용에 미치는 장기적 영향”을 논의한다면, 최소한 다음 관점으로 쪼개볼 수 있다.

하나의 모델이 한 번에 다루면 이 항목들을 다루더라도 실제로는 관점 간 충돌이나 차이를 충분히 만들기 어렵다.

다중 Agent의 장점은 각자 고유한 역할카드, 지식 범위, 말투, 블라인드 스폿을 갖는다는 점이다. 토론할 때 서로 다른 방향에서 접근하고 진행자가 이를 엮는다.

이 방식은 길게 늘어놓은 프롬프트 하나를 고도화하는 것보다 안정적이고 확장성도 좋다.

5. 프로젝트에서의 RAG 역할

RAG는 쉽게 말해 “열린책고사”에 가깝다.

일반 LLM은 모델 파라미터에 이미 내장된 지식에 의존해 답한다. 반면 RAG는 답을 생성하기 전에 외부 지식베이스에서 관련 자료를 검색해 모델이 참고하게 한다.

agent_roundtable에서는 로컬 장문 자료를 knowledge/ 아래에 둔다. 각 전문가가 각자의 지식 디렉터리를 가질 수 있다. 예를 들면:

knowledge/macro_economist/
knowledge/investing_master/
knowledge/ai_researcher/
knowledge/philosophy_expert/
knowledge/history_strategist/

그다음 아래 명령으로 인덱스를 만든다.

python -m rag.ingest --expert-name macro_economist --embedding-provider keyword

현재는 keyword 검색을 우선 지원한다. 추가 API key가 필요 없어 로컬 테스트와 입문 단계에 적합하다. 추후 더 강력한 시맨틱 검색이 필요하면 embedding 모델을 붙이면 된다.

이 설계가 나에게는 핵심이었다.

전문가 Agent가 모델이 가진 “기억”에만 기대어 답하는 걸 원하지 않는다. 미리 준비한 책, 논문, 장문 자료를 읽고 그 자료를 배경지식으로 삼게 하고 싶었다.

그래서 Agent는 단순 캐릭터 프롬프트가 아니라, 로컬 지식원을 가진 전문가 시스템의 초기 형태가 될 수 있다.

6. 프로젝트 구조

프로젝트 구조는 대략 다음과 같다.

agent_roundtable/
├── main.py
├── ui/
│   └── app.py
├── src/
│   ├── graph.py
│   ├── agents.py
│   ├── llm.py
│   ├── model_catalog.py
│   ├── agent_llm_config.py
│   ├── loader.py
│   ├── logger.py
│   ├── prompts.py
│   └── state.py
├── agents/
│   ├── domain_experts/
│   └── persona_inspired/
├── councils/
├── configs/
│   └── agent_llms.json
├── knowledge/
├── rag/
├── vector_db/chroma/
├── logs/
├── tests/
├── requirements.txt
└── .env.example

주요 디렉터리의 역할은 다음과 같다.

나는 이런 계층화가 마음에 든다. 역할은 역할, 모델 설정은 모델 설정, 지식베이스는 지식베이스, 실행 로그는 실행 로그로 분리되어 있다. 서로 뒤엉키지 않는다.

7. Agent 역할카드는 어떻게 설계하나

이 프로젝트에서 각 Agent는 자체 YAML 역할카드를 가진다.

일반적으로 하나의 Agent 역할카드는 다음을 포함한다.

• 이름
• 역할
• 세계관
• 말투
• 강점
• 약점
• 대응하는 RAG 지식 디렉터리
• Agent 유형

예를 들어 에너지 전문가를 이렇게 설계할 수 있다.

name: "Energy Expert"
role: "에너지 및 산업 정책 전문가"
worldview: "에너지 수요·공급, 인프라, 지정학, 기술 대체 관점에서 문제를 분석한다"
speaking_style: "명확하고 신중하게, 제약을 먼저 제시한 뒤 판단을 전개한다"
strengths:
  - "에너지 수급 분석"
  - "산업체인 분해"
weaknesses:
  - "금융시장 단기 변동을 과소평가할 수 있다"
catchphrases:
  - "먼저 에너지 제약을 봐야 한다"
rag_expert_name: "energy_expert"
agent_type: "domain_expert"
profile:
  focus:
    - "에너지 안보"
    - "전력 시스템"
    - "석유·천연가스 및 신재생"

여기서 핵심은 “사람 캐릭터 소설처럼 쓰는 것”이 아니다. Agent의 분석 경계를 고정하는 것이다.

좋은 전문가 Agent는 자신이 무엇을 잘하는지 알고, 무엇을 놓치기 쉬운지도 알아야 한다. 그렇지 않으면 결국 모든 Agent가 같은 목소리로 들린다.

8. 모델 설정을 분리해 둔 이유

어떤 Agent가 어떤 모델을 쓰는지는 configs/agent_llms.json에 따로 둔다.

이 구조의 장점은 역할과 모델의 디커플링이다.

역할카드는 “이 Agent가 누구인지”만 설명한다. JSON은 “이 Agent가 어떤 provider, 어떤 모델, 어떤 API key 환경변수’를 쓰는지”를 설명한다.

예를 들면:

{
  "agents": {
    "macro_economist": {
      "provider": "openrouter",
      "model": "nvidia/nemotron-3-super-120b-a12b:free",
      "api_key_env": "OPENROUTER_API_KEY_1"
    },
    "ai_researcher": {
      "provider": "openrouter",
      "model": "nvidia/nemotron-3-ultra-550b-a55b:free",
      "api_key_env": "OPENROUTER_API_KEY_1"
    }
  }
}

여기서 api_key_env는 실제 API key가 아니다. 프로그램이 .env에서 어떤 변수를 읽어야 하는지 가리키는 이름일 뿐이다.

실제 API key는 JSON, YAML, README, 로그, 스크린샷 어디에도 넣으면 안 된다. 이 부분은 매우 중요하다.

9. 로컬 UI의 의미

프로젝트에는 로컬 Streamlit UI가 들어 있다.

이 UI는 예쁘게 상업용 제품을 만들기 위한 것이 아니다. 설정 과정을 직관적으로 만들기 위함이다.

UI에서는 다음을 할 수 있다.

• 라운드테이블 선택
• 각 Agent에 사용할 provider 설정
• 각 Agent에 사용할 모델 설정
• 각 Agent에 사용할 .env API key 변수 선택
• configs/agent_llms.json에 설정 저장
• 주제를 입력하고 실제 LLM 실행
• 진행 상황, 현재 단계, 최근 이벤트 확인
• 최종 요약과 대화 로그 미리보기

이 UI는 실제로 매우 유용하다.

다중 Agent 시스템이 커질수록 수동으로 설정 파일을 수정하는 방식은 점점 번거롭다. UI가 필요 복잡할 필요는 없지만, 최소한 모델과 라운드테이블을 빠르게 바꾸고 다양한 조합을 실험할 수 있어야 한다.

10. MCP와 Tool Use: 앞으로 어떻게 붙일 것인가

현재 agent_roundtable의 핵심은 로컬 다중 Agent 라운드테이블, RAG, 보고서 생성이다. MCP는 아직 프로젝트의 핵심 구현은 아니지만, 매우 자연스러운 다음 단계다.

MCP는 Model Context Protocol의 약자로, AI 애플리케이션이 외부 도구와 데이터 소스를 연결하는 개방형 프로토콜이다. 모델과 도구, 데이터베이스, 파일 시스템, 비즈니스 시스템 간 연결 방식을 표준화하려는 시도다.

RAG가 “답변 전에 자료부터 조회”하는 문제를 다룬다면, MCP는 “Agent가 외부 도구에 표준적으로 연결해 동작을 수행”하는 쪽에 더 가까운 문제를 다룬다.

따라서 이 글에서는 agent_roundtable을 이미 MCP가 완전히 통합된 프로젝트로 포장하지 않는다. 더 정확히 말하면, 로컬 다중 Agent 워크플로를 우선 안정화하고, 이후 MCP와 Tool Use를 붙일 수 있는 인터페이스 공간을 열어둔 상태라고 보는 게 맞다.

이 프로젝트에 대해서는 앞으로 다음과 같은 MCP 기능을 고려할 수 있다.

• 파일 시스템 MCP를 붙여 Agent가 로컬 자료를 더 표준적으로 읽기
• 검색 MCP를 붙여 일부 Agent가 웹으로 검증 수행
• 데이터베이스 MCP를 붙여 금융·거시 Agent가 구조화된 데이터를 조회
• GitHub MCP를 붙여 기술 Agent가 저장소, 이슈, 코드 분석
• 캘린더·메일·태스크 시스템 연동으로 라운드토론 결과를 후속 액션으로 연결

하지만 지금은 MCP를 한 번에 과도하게 넣지 않는다.

우선은 로컬 RAG, 역할 설정, 모델 호출, 보고서 생성이라는 주선을 먼저 안정화한다. 이 축이 안정된 뒤에 MCP를 도구 계층으로 붙이는 방식이 맞다.

11. ReAct, LangGraph와의 관계

ReAct는 고전적인 Agent 사고방식이다. 추론과 행동을 번갈아 수행하게 한다. 쉽게 말해 모델이 바로 정답을 내놓는 대신 생각하고, 도구를 호출하고, 도구 결과에 따라 다음 단계를 조정한다.

LangGraph는 워크플로우 오케스트레이션에 더 가깝다. Agent의 절차를 그래프로 모델링한다. 노드는 Agent, 도구, 판단 로직, 요약기로 구성될 수 있고, 간선은 흐름 이동을 나타낸다.

다중 Agent 라운드테이블은 그래프 관점과 매우 잘 맞는다.

flowchart TD
    A["진행자가 질문을 제시한다"] --> B["전문가가 순차적으로 발언한다"]
    B --> C["진행자 소결 요약"]
    C --> D["다음 라운드 추궁"]
    D --> B
    C --> E["최종 요약"]

이 구조는 단순 체인 호출이 아니다. 상태가 있고, 순서가 있고, 역할 분담이 있는 워크플로다.

현재 프로젝트는 이 방향으로 설계했다. 먼저 라운드 흐름을 만들고, 그다음 Agent 발언, 다시 요약과 로그 적재를 거친다. 향후 강화할 때는 더 복잡한 조건 분기도 붙일 수 있다. 예를 들면:

• 특정 Agent가 증거가 부족하다고 판단하면 검색을 트리거
• 두 Agent의 견해 충돌 시 진행자가 추궁
• 한 라운드 토론 품질이 낮으면 반박 라운드 자동 추가
• 최종 보고서 생성 전에 팩트체크 Agent 추가

이것이 바로 Agent 워크플로우가 정말 재미있는 이유다.

12. 오픈 소스 공개 시 주의점

이 프로젝트는 로컬 지식베이스, API key, 실행 로그를 다루므로 오픈소스 공개 시 매우 주의가 필요하다.

.gitignore에는 기본적으로 다음 항목을 제외한다.

• .env: 실제 API key
• knowledge/**/*.md: 로컬 책·논문·장문 자료
• logs/**: 실행 보고서
• vector_db/chroma/**: 로컬 벡터 인덱스
• __pycache__/, .pytest_cache/ 같은 임시 파일

보통 GitHub에 올리는 것은 다음이다.

• 코드
• README
• agents/*.yaml
• councils/*.yaml
• configs/agent_llms.json
• knowledge/README.md
• .gitkeep 플레이스홀더 파일

특히 knowledge/ 디렉터리는 조심해야 한다.

저작권 책, 논문 원문, 개인 자료, 유료 콘텐츠가 포함되어 있다면 공개 저장소에 올려서는 안 된다. 오픈소스 프로젝트는 구조와 사용 방식을 보여줄 수는 있어도 공개에 부적절한 자료는 같이 배포하면 안 된다.

13. 이 프로젝트가 나에게 의미 있는 이유

내게 agent_roundtable은 단순한 장난감 프로젝트가 아니다.

이는 내가 오랫동안 연습해오던 여러 영역을 하나로 엮은 결과다.

• AI Agent
• 다중 에이전트 협업
• RAG 지식베이스
• Tool Use
• 로컬 워크플로
• 모델 구성 관리
• Markdown 보고서 생성
• 실사용을 염두에 둔 UI

또한 확장성이 좋다.

앞으로 거시경제, 투자, AI, 역사, 철학, 점성술, 프로그래밍 등 주제별로 각각 전문가 시스템을 추가로 구성할 수 있다. 각 전문가마다 자기만의 자료실, 역할카드, 모델 설정이 존재한다. 사용자는 질문만 입력하면 같은 주제를 여러 전문가가 토론하게 할 수 있다.

이건 단순히 프롬프트 몇 개를 더 짜는 것보다 시스템에 가깝다.

이 프로젝트는 현재 완전히 Python으로 구현돼 있으며 연구·실험 단계에 더 가깝다. 만약 앞으로 사용자 대상 제품으로 바꾸려면 언어 선택 자체가 또 다른 문제가 된다. 나는 《AI Agent는 어떤 언어를 써야 하나: Python, TypeScript와 차세대 제품 엔지니어링》에서 이 주제를 다뤘다.

이제 점점 실감한다. 앞으로 많은 AI 응용은 “하나의 채팅창이 모든 걸 해결한다”가 아니라, 여러 역할·도구·지식베이스·워크플로가 결합된 구조가 될 것이라는 점을.

agent_roundtable은 내가 이 방향으로 한 번 실전으로 들어간 기록이다.

자주 묻는 질문

agent_roundtable이 무엇인가?

로컬에서 실행되는 다중 Agent 전문가 라운드테이블 프로젝트다. 주제를 입력하면, 시스템이 서로 다른 방향의 전문가 Agent를 번갈아 발언하게 하고 진행자가 추궁·연결·요약을 담당해 전체 토론을 Markdown 보고서로 저장한다. CLI와 로컬 Streamlit UI 두 방식 모두 지원하며, 각 Agent는 개별적으로 provider, 모델, API key 환경변수를 설정할 수 있다.

왜 다중 Agent를 쓰고, 거대 Agent를 쓰지 않는가?

현실의 복잡한 판단은 한 목소리로 끝낼 수 없다. 다중 Agent의 장점은 각 Agent가 자기 역할카드, 지식 범위, 말투, 블라인드 스폿을 가져서 서로 다른 방향에서 문제에 들어간다는 점이다. 진행자가 그것을 묶는다. 긴 프롬프트 하나를 더 고도화하는 것보다 안정적이고 확장도 쉽다.

API key가 없어도 실행 가능한가?

가능하다. 프로젝트는 --mock 모드를 지원해서 API key가 없어도 전체 파이프라인을 먼저 점검할 수 있다. RAG 검색도 기본적으로 keyword 방식을 우선 지원하므로 추가 embedding API key가 필요 없어 로컬 테스트와 입문 단계에 적합하다.

이 프로젝트는 MCP를 이미 붙였는가?

아직 아니다. agent_roundtable의 현재 초점은 로컬 다중 Agent 라운드테이블, RAG, 보고서 생성이다. MCP와 Tool Use는 자연스러운 다음 단계로 남아 있고, 후속 연동을 위한 인터페이스는 열어두었으나 핵심 구현에는 아직 들어가 있지 않다.

오픈 소스 공개 시 API key와 사적 자료를 어떻게 유출 없이 관리하나?

실제 API key는 .env에만 둔다. 설정 파일에는 api_key_env 변수명만 쓰고 키 값 자체를 쓰지 않는다. .gitignore에서는 기본적으로 .env, knowledge/ 하위 로컬 자료, logs/ 실행 보고서, vector_db/chroma/ 벡터 인덱스를 제외한다. 공개 저장소에는 코드, README, 역할카드, configs/agent_llms.json, 플레이스홀더 파일만 올라간다.

참고 출처

• Random-Walk2026/agent_roundtable GitHub 저장소
• Model Context Protocol 공식 문서
• Anthropic: Introducing the Model Context Protocol
• LangGraph 공식 페이지
• LangGraph: Multi-Agent Workflows
• ReAct: Synergizing Reasoning and Acting in Language Models
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks