노비스의 진화: RAG를 버리고 멀티에이전트로 갈아탄 이야기

이전 글에서 노비스를 만들면서 겪었던 RAG의 현실적인 문제들을 공유했습니다.

그 후로 몇 개월. 노비스는 완전히 다른 모습으로 진화했습니다.

안녕하세요. 노머스에서 백엔드 개발자로 근무하고 있는 지승보입니다.

노비스(Knowbis) 는 질문의 허들을 낮추고, 사내 정보를 쉽게 찾아주는 것을 목표로 만든 Slack 기반 사내 AI 챗봇입니다.

TL;DR

• RAG 기반 검색의 한계를 체감하고, 멀티에이전트 아키텍처로 전환
• Google ADK(Agent Development Kit)를 도입해 전문 에이전트들이 협업하는 구조로 개편
• 각 에이전트는 맡은 도메인(문서, 코드, AWS, 모니터링)에 특화된 도구와 전략을 가짐
• Rovo MCP 연동 과정에서 OAuth sidecar를 거쳐 API Token으로 단순화한 여정
• “만능 검색 봇”이 아닌 “적재적소에 전문가를 불러오는 봇”으로 방향 전환

키워드: Multi-Agent, Google ADK, MCP, Slack Bot, 사내 AI 챗봇

---

목차

1. RAG만으로는 부족했다
2. 멀티에이전트로의 전환: 왜?
3. 기술 스택 선택: Google ADK와 Gemini
4. 전체 아키텍처와 에이전트들
5. Rovo MCP 연동: OAuth에서 API Token까지
6. 실제 사용 사례
7. 마무리하며

---

RAG만으로는 부족했다

이전 글에서 RAG의 문제들을 해결하기 위해 여러 시도를 했습니다. Query Rewrite, Re-ranking, Hierarchical 임베딩, Vertex AI 도입까지.

그런데 운영하다 보니 근본적인 한계가 보이기 시작했습니다.

만든 사람만 잘 쓸 수 있는 봇

노비스를 만든 저는 이 봇이 뭘 할 수 있고, 어떻게 질문해야 잘 대답하는지 알고 있습니다. Confluence에 어떤 문서가 있는지, 어떤 키워드로 검색해야 원하는 결과가 나오는지 감이 있죠.

하지만 동료들은 다릅니다. 제 의도대로 질문하지 않습니다. 당연히요.

“이 Lambda 함수 뭐하는 거야?” “선물하기 기능 히스토리 알려줘” “결제/환불 로직 관련 문서 다 찾아줘”

이런 질문들이 슬랙에 올라올 때마다, 노비스는 열심히 Confluence 문서를 뒤졌습니다. 그리고 대부분 엉뚱한 답변을 내놓거나, “관련 문서를 찾지 못했습니다”를 반환했습니다.

질문의 성격이 다른데, 같은 방식으로?

문제를 분석해보니 패턴이 보였습니다.

질문 유형	정보 위치	RAG로 해결 가능?
”이 Lambda 뭐야?”	AWS 콘솔	❌ 애초에 문서에 없음
”기능 히스토리 알려줘”	여러 Jira/Confluence 문서	△ 단일 검색으론 부족
”결제 로직 설명해줘”	Git 코드베이스	❌ 코드를 봐야 함
”지난주 회의록”	Confluence 특정 스페이스	○ 잘 찾으면 가능

RAG는 “문서를 잘 찾아서 답변하는 것”에 최적화되어 있습니다. 하지만 동료들이 실제로 하는 질문은:

• RAG에 학습되지 않은 정보를 묻거나 (AWS 리소스, 실시간 데이터)
• 여러 문서를 오가며 분석해야 하거나 (기능 변경 히스토리)
• 코드를 직접 봐야 답할 수 있는 것들이었습니다 (구현 로직)

결국 깨달았습니다.

노비스에게 필요한 건 “더 좋은 검색”이 아니라, “질문을 이해하고 적절한 방법을 선택하는 능력” 이다.

---

멀티에이전트로의 전환: 왜?

사람에게 질문할 때를 생각해봤습니다.

• 인프라 관련 질문 → DevOps 담당자에게
• 코드 관련 질문 → 해당 레포 담당 개발자에게
• 회의록 찾기 → 해당 팀 누군가에게

질문의 종류에 따라 물어볼 대상이 다릅니다.

이걸 AI로 구현하면 어떨까요?

하나의 만능 에이전트가 모든 걸 처리하는 대신, 전문 분야가 다른 여러 에이전트가 협업하는 구조.

이 구조의 장점은 명확했습니다.

1. 각 에이전트는 자기 분야에만 집중하면 됩니다
2. 새로운 기능 추가 시 기존 에이전트에 영향 없이 새 에이전트만 추가
3. 문제가 생겼을 때 어느 에이전트에서 문제인지 파악하기 쉬움
4. 각 에이전트별로 다른 모델, 다른 전략을 적용 가능

단점도 있습니다.

1. 라우팅이 잘못되면 엉뚱한 에이전트가 답변
2. 에이전트 간 컨텍스트 공유가 어려움
3. 전체 시스템 복잡도 증가
4. 디버깅할 때 흐름 추적이 까다로움

하지만 “만능 검색 봇”의 한계를 계속 경험한 입장에서, 이 정도 복잡도는 감수할 가치가 있다고 판단했습니다.

---

기술 스택 선택: Google ADK와 Gemini

멀티에이전트 시스템을 구현하기 위해 여러 프레임워크를 검토했습니다.

• LangChain/LangGraph: 가장 유명하고 자료도 많음
• AutoGen: Microsoft의 멀티에이전트 프레임워크
• CrewAI: 역할 기반 에이전트 협업에 특화
• Google ADK: Google의 Agent Development Kit

결론부터 말하면, Google ADK를 선택했습니다.

왜 ADK인가?

Gemini와의 네이티브 통합

이미 Vertex AI를 쓰고 있어서 GCP 생태계 안에서 움직이는 게 자연스러웠습니다. Gemini 모델들을 바로 사용할 수 있었습니다.

심플한 에이전트 정의

에이전트 하나 만드는 데 필요한 코드가 정말 간결합니다.

from google.adk.agents import LlmAgent

docs_agent = LlmAgent(
    name="docs_agent",
    model="gemini-3-flash-preview",
    instruction="Confluence와 Jira에서 문서를 검색합니다...",
    tools=[rovo_search, rovo_search_cql, ...],
)

sub_agents를 통한 라우팅

라우터 에이전트가 sub_agents 목록 중 적절한 에이전트를 선택하는 구조가 직관적이었습니다.

모델 선택의 고민

에이전트의 역할 복잡도에 따라 다른 모델을 적용했습니다.

역할	모델	이유
라우터	gemini-3-flash-preview	빠른 판단, 비용 효율
docs/codebase/signoz	gemini-3-flash-preview	복잡한 검색과 종합이 필요
aws	gemini-3.1-flash-lite-preview	단순 CLI 명령 실행, 비용 최적화

이전 글에서도 언급했듯이, 저렴한 모델로 비용을 아끼려다가 품질이 떨어지는 경험을 했습니다. 다만 모델 세대가 올라가면서 Flash급으로도 충분한 품질이 나오는 영역이 많아졌습니다. “복잡한 지시사항을 따라야 하는 에이전트”에는 여전히 상위 모델이 필요하지만, AWS CLI 명령 실행 같은 단순한 작업은 Flash Lite로도 충분했습니다.

---

전체 아키텍처와 에이전트들

현재 노비스의 전체 구조입니다.

라우터: 질문을 적절한 전문가에게

라우터 에이전트의 instruction에는 각 에이전트가 어떤 질문을 처리해야 하는지, 어떤 키워드가 트리거가 되는지 우선순위와 함께 명시되어 있습니다.

우선순위	에이전트	트리거 키워드
1	docs_agent	회의록, 문서, Confluence, Jira, 정책
2	signoz_agent	SignOz, API 트레이스, 모니터링
3	codebase_agent	코드, 함수, 클래스, API 구현
4	aws_agent	S3, Lambda, CloudWatch, EC2

예를 들어 instruction에는 이런 규칙들이 들어있습니다.

## 핵심 규칙
1. 사내 정보 질문 = docs_agent: "지난 주 ~", "~가 공유한", "~회의에서"
2. 업무 질문 = 반드시 sub_agent 호출: 직접 답변 금지
3. 모호하면 되묻기: "어느 팀?", "어떤 프로젝트?"

라우터가 직접 답변하지 않고 반드시 적절한 에이전트에게 위임하도록 강제한 것이 핵심입니다.

4개의 전문 에이전트

docs_agent — Confluence/Jira 검색

Atlassian의 Rovo MCP를 통해 Confluence와 Jira를 검색합니다. 자연어 검색, CQL/JQL 쿼리, 페이지/이슈 상세 조회가 가능합니다. “지난 주 회의록 찾아줘” 같은 시간 표현은 요청에 KST 시각 정보를 함께 전달해서 정확하게 해석합니다.

codebase_agent — 코드베이스 검색

Gemini CLI를 subprocess로 호출해서 로컬 코드베이스에 자연어 질문을 합니다. 핵심은 쿼리 확장입니다. “결제 버튼 누르면 뭐 돼?”라는 단편적인 질문을 “결제 버튼 클릭 시 전체 플로우: UI → API → 백엔드 → DB”로 확장해서 검색합니다. 여러 레포지토리는 10분 주기 크론잡으로 동기화합니다.

aws_agent — AWS 리소스 조회

별도 Docker 컨테이너에 AWS CLI를 넣고, docker exec로 명령을 실행합니다. AWS 자격 증명이 컨테이너 안에만 존재하도록 격리한 구조입니다. “fromm channel dev contents 버킷”처럼 부정확한 리소스명도 전체 목록에서 유사 매칭으로 찾아줍니다.

signoz_agent — 모니터링 로그/트레이스 조회

Go로 작성된 signoz-mcp-server를 stdio 기반 MCP로 호출합니다. 서비스 목록, 에러 로그, 트레이스, 알림 등 9가지 도구를 제공합니다. 시간 범위가 핵심이라, 알림 시각 기준 -3분 ~ +1분 같은 규칙을 instruction에 명시해뒀습니다.

---

Rovo MCP 연동: OAuth에서 API Token까지

멀티에이전트 이야기와는 결이 좀 다르지만, 운영 과정에서 가장 많은 시간을 잡아먹은 부분이라 공유합니다.

문제: OAuth 2.1만 지원

초기 Rovo MCP는 OAuth 2.1 플로우만 지원했습니다. API Token 방식은 사용할 수 없었죠.

다만 Atlassian 문서에는 API Token 인증이 추후 도입될 예정이라고 명시되어 있었습니다. 그래서 전략을 세웠습니다.

“복잡하지만 확실하게 동작하는 방향으로 먼저 구현하자. API Token이 나오면 그때 바꾸면 된다.”

겪은 일들

토큰 자동 갱신: OAuth 토큰은 약 1시간(우리 환경 기준)마다 만료됩니다. 서버가 24시간 돌아가야 하니 TokenRefresher를 만들어 5분마다 체크, 만료 25분 전 갱신, 실패 시 3회 재시도, 원자적 파일 쓰기와 백업까지 구현했습니다.

mcp-remote 토큰 충돌: Rovo MCP 통신에 사용하는 mcp-remote CLI가 자체적으로 토큰 파일을 관리하면서, 제가 갱신한 토큰을 덮어쓰는 문제가 발생했습니다. 버전마다 토큰 경로도 바뀌어서 symlink로 대응해야 했습니다.

메모리 누수와 Sidecar 분리: mcp-remote를 매 호출마다 subprocess로 실행하니 메모리가 누적되었습니다. 결국 rovo-sidecar라는 별도 FastAPI 컨테이너를 만들어 분리했는데, Docker 네트워크, 볼륨 공유, 복잡도 증가라는 대가가 따랐습니다.

“OAuth 토큰 갱신”이라는 단순해 보이는 문제가, 별도 컨테이너 + 백그라운드 스케줄러 + 백업 복구 + symlink 관리까지 낳은 겁니다.

해결: API Token 도입

예상대로, Atlassian이 Rovo MCP에 Basic Auth (API Token) 인증을 지원하기 시작했습니다.

credentials = base64.b64encode(f"{email}:{api_token}".encode()).decode()
headers = {"Authorization": f"Basic {credentials}"}

async with streamablehttp_client(ATLASSIAN_MCP_URL, headers=headers) as (read, write, _):
    async with ClientSession(read, write) as session:
        await session.initialize()
        result = await session.call_tool(tool_name, arguments)

이 코드로 rovo-sidecar, TokenRefresher, mcp-remote, 백업 메커니즘, symlink 관리가 전부 삭제되었습니다. MCP SDK의 streamablehttp_client를 직접 사용하니 subprocess 없이 HTTP 연결을 재사용할 수 있게 되었고, 메모리 누수도 사라졌습니다.

참고로 API Token 방식은 조직 관리자가 활성화해야 사용할 수 있습니다.

교훈: “별거 아닌 것 같은” 인증 문제가 시스템에서 가장 큰 복잡도를 만들 수 있습니다. 그리고 그 복잡도는 종종 플랫폼의 지원 범위가 넓어지면서 한 순간에 사라지기도 합니다.

권한 제어: 전용 계정 방식

Confluence와 Jira의 MCP 검색은 인증에 사용한 계정의 권한을 그대로 따릅니다.

처음에는 “문서별로 접근 제어를 구현해야 하나?” 고민했지만, 노비스 전용 서비스 계정을 만들고, 이 계정에 필요한 스페이스와 프로젝트만 권한을 부여하는 방식을 선택했습니다.

• 공개 문서 → 접근 허용
• 민감한 문서 (HR, 재무 등) → 접근 차단

Atlassian의 기존 권한 체계를 그대로 활용하니, 별도의 접근 제어 코드 없이 문서 범위를 관리할 수 있습니다. 대규모 조직이라면 더 세밀한 RBAC이 필요하겠지만, 10~20명 규모의 팀에서는 이 방식이 가장 합리적이었습니다.

---

실제 사용 사례

여기까지 기술적인 이야기를 많이 했는데, 결국 중요한 건 “실제로 팀에서 얼마나 쓰이고 있는가” 입니다.

실제 Slack에서 노비스를 사용하는 모습을 몇 가지 공유합니다.

에러 분석을 시켜두고, 다른 일을 한다

AWS 에러 알림이 올라왔을 때, 출퇴근 중이거나 다른 업무를 하고 있다면? 노비스에게 에러 분석을 시켜두면 됩니다. 돌아와서 확인하면 원인 분석이 끝나 있고, 바로 작업에 들어갈 수 있습니다.

분석에서 작업 시작까지 한 번에

분석 결과를 바탕으로 Jira 티켓 초안과 AI 코딩 도구에서 사용할 프롬프트까지 자동으로 생성할 수 있습니다. 에러 발견부터 수정 작업 시작까지의 간극을 줄여주는 워크플로우입니다. (나중에는 노비스가 직접 티켓을 올리고 PR까지 생성하는 단계로 발전시킬 생각도 하고 있습니다.)

문서와 코드 기반의 답변

사용자의 질문에 따라 Confluence 문서나 코드베이스를 검색해서 근거 있는 답변을 제공합니다. 문서에 정책이 정리되어 있으면 문서를 기반으로, 문서에 없으면 코드를 기반으로 답변합니다.

에이전트 간 연계

aws_agent를 통해 Lambda의 타임아웃, 메모리 같은 설정값을 바로 확인할 수 있습니다. 여기서 더 나아가, 이전 대화 컨텍스트를 이어서 codebase_agent에게 코드 분석을 요청하는 것도 가능합니다. 하나의 질문에서 시작해 여러 에이전트가 자연스럽게 협업하는 흐름입니다.

에러 시나리오 분석

“이 오류가 왜 발생할 수 있는지” 시나리오 분석을 요청하면, 코드베이스를 기반으로 가능한 원인들을 상세하게 분석합니다.

---

마무리하며

노비스는 “RAG 기반 문서 검색 봇”에서 “멀티에이전트 기반 사내 AI 어시스턴트”로 진화했습니다.

핵심 변화를 정리하면:

이전	현재
단일 RAG 파이프라인	전문 에이전트들 + 라우터
Vertex AI Datastore	Rovo MCP, Gemini CLI, AWS CLI, SignOz MCP
”검색해서 답변"	"질문에 맞는 방법으로 정보 조회”
문서 검색 특화	문서, 코드, 인프라, 모니터링 통합
OAuth sidecar 복잡도	API Token 기반 단순화

물론 아직 완벽하지 않습니다.

• 라우팅이 가끔 틀림 (코드 질문을 docs_agent로 보내는 등)
• 에이전트 간 컨텍스트 공유가 아직 미흡
• Vertex AI 모델 쿼터 제한으로 가끔 오류가 발생

하지만 방향성은 맞다고 생각합니다. “만능 검색 봇”이 아니라 “적재적소에 전문가를 불러오는 봇”.

노비스는 팀 누구나 참여해서 업무 효율화를 위한 본인의 아이디어를 구현할 수 있는 플랫폼이 되면 좋겠습니다.

읽어주셔서 감사합니다!