Dev Stories

K RAG 개발자들의 Agentic AI 부트캠프 참여기

이미지

들어가며


KT AI검색기술 부서 연구원들로 구성된 저희 팀은 최근 캐나다 AI 연구기관 Vector Institute가 주최한 Agentic AI Bootcamp에 참여해 실제 서비스에 적용 가능한 멀티에이전트 기반 검색 시스템 PoC를 설계·구현했습니다. 짧은 기간이었지만, 차세대 AI 에이전트 시스템을 직접 설계하고 운영해 보며 “Agentic AI를 실제 서비스에 어떻게 녹일 것인가”에 대해 실전 위주의 고민과 실험을 진행했습니다.

이번 부트캠프에서 저희가 특히 집중한 주제는 다음과 같습니다.

  • 정형 데이터(DB)와 웹을 동시에 활용하는 멀티소스 RAG 에이전트 아키텍처
  • 개별 에이전트를 툴(Tool) 로 래핑해 메인 에이전트가 동적으로 조합·호출하는 패턴
  • 관측성(Observability) 과 평가(Evaluation) 를 함께 고려한 실전형 에이전트 시스템 구조

본 글에서는 다음 네 가지를 중심으로 이번 경험을 정리합니다.

  1. Vector Institute와 Agentic AI Bootcamp 개요
  2. 멀티에이전트 기반 검색 PoC(RAG Agent for DB & Web)
  3. Showcase Day에서 살펴본 글로벌 기업들의 Agentic AI 활용 사례
  4. 이번 경험을 앞으로의 K RAG 고도화에 어떻게 연결할지에 대한 계획


Vector Institute와 Agentic AI 부트캠프

Vector Institute란

이미지
Vector Institute는 2017년 캐나다 온타리오주와 민간 기업들의 투자로 설립된 비영리 AI 연구 기관입니다. 딥러닝의 개척자 중 한 명인 Geoffrey Hinton 토론토대 교수가 설립에 참여했으며, 현재 300명 이상의 머신러닝·딥러닝 연구자가 다양한 분야의 AI 기술을 연구하고 있습니다.

이 기관은 연구뿐 아니라 기업과 개발자를 위한 교육·부트캠프 프로그램도 활발히 운영하고 있으며, 이번에 참여한 Agentic AI Bootcamp 역시 그 일환입니다. 이 프로그램은 최신 에이전트 기반 AI 아키텍처를 실전 프로젝트 중심으로 다루는 것이 특징입니다.

Agentic AI 부트캠프 개요와 목표

Agentic AI Bootcamp는 에이전트 기반 AI 시스템을 설계·구현해 실제 비즈니스 문제를 해결하고자 하는 팀을 대상으로 합니다. 참가팀들은 공통적으로 다음과 같은 목표를 가지고 프로그램을 수행합니다.

  • Agentic AI 아키텍처에 대한 이론적 이해와 실제 개발·배포 경험 확보
  • 각자 도메인에 맞는 에이전트 시스템 설계 및 유즈케이스 발굴
  • 팀별로 정의한 문제를 해결하는 PoC(Proof of Concept) 를 제한된 기간 내에 완성

프로그램은 크게 세 단계로 구성됩니다.

  1. Learn Day (2일): Agentic AI 개념, 멀티에이전트 아키텍처, Observability/Evaluation, MCP, 합성 데이터 등 이론·실습
  2. Build Day (수 주): 각 팀이 자체 PoC를 설계·구현
  3. Showcase Day: 팀별 결과물 공유 및 피드백

부트캠프에 참여한 계기

저희는 조직/서비스 관점개인 학습 관점에서 각각 명확한 목표를 가지고 부트캠프에 참여했습니다.

조직과 서비스 관점에서는, 우선 정형 데이터(DB)를 대상으로 하는 RAG 에이전트 설계·구현 경험을 확보하고자 했습니다. 기존 K RAG가 강점을 가져온 비정형 문서/웹 정보 검색·Q&A뿐만 아니라, 정형 데이터베이스를 함께 다룰 수 있는 멀티에이전트 검색 구조를 탐색하는 것이 중요한 과제였습니다. 또한 Vector Institute 및 글로벌 기업들이 Agentic AI를 실제로 어떤 문제에 어떻게 적용하고 있는지를 직접 확인해 향후 서비스 방향성에 대한 인사이트를 얻고자 했습니다.

개인 학습 측면에서는, 상용·오픈소스 라이브러리·프레임워크·도구를 활용해 실전 Agentic AI 시스템을 구축해 보는 경험과, 해외 연구자·개발자들과의 협업을 통해 설계·개발 과정에서의 베스트 프랙티스를 몸으로 익히는 것을 목표로 삼았습니다.


부트캠프에서 얻은 핵심 학습


Learn Day에서는 RAG, ReAct, 함수 호출 기반 Tool, 멀티에이전트 시스템, Gemini 모델 데모, Observability/Evaluation, MCP, 합성 데이터 생성 등 Agentic AI 전반에 걸친 이론과 실습이 제공되었습니다. 이 중 실무에 직접적으로 도움이 되었던 부분 두 가지를 중심으로 정리하면 다음과 같습니다.

1. 에이전트 도구(Tool) 설계 패턴

OpenAI Agents SDK를 활용해 멀티에이전트 시스템을 구성하는 실습을 진행하면서, 개별 에이전트를 그대로 사용하는 대신 서브 에이전트를 함수 형태로 래핑해 메인 에이전트의 Tool로 사용하는 패턴을 경험했습니다.
Python
​import agents

main_agent = agents.Agent(
    name="MainAgent",
    tools=[
        search_agent.as_tool(
            tool_name="search",
            tool_description="Perform a web search for a query and return a concise summary.",
        )
    ],
    ...,
)
123456789101112
이때 다음과 같은 점을 명확히 확인할 수 있었습니다.

  • 동일한 기능이라도 Tool로써의 범위와 책임을 어디까지로 설정하느냐에 따라 에이전트 행동이 달라진다는 점
  • 각 Tool의 설명(description)을 얼마나 구체적이고 명시적으로 작성하는지가 메인 에이전트의 플래닝과 Tool 선택에 직접적인 영향을 준다는 점

이 경험은 이후 PoC에서 DB 검색 에이전트와 웹 검색 에이전트의 역할을 정의하고, Tool description을 튜닝하는 작업에 그대로 이어졌습니다. 프롬프트 엔지니어링 못지않게 Tool 설계와 description 작성이 중요하다는 것을 실습을 통해 체감했습니다.

2. 관측성(Observability)과 평가(Evaluation)

이미지


Langfuse와 같은 도구를 활용해 에이전트 내부의 LLM 호출을 추적하는 Observability 실습도 큰 도움이 되었습니다. 서브 에이전트를 Tool로 감싼 구조에서도 tracing 도구를 이용하면 에이전트 간 호출 흐름과 각 단계의 LLM I/O를 상세히 확인할 수 있다는 점이 인상적이었습니다.

이를 통해 다음과 같은 실무적인 시사점을 얻었습니다.

  • 성능·안정성을 개선하거나 비용을 최적화할 때, 어디에서 문제가 발생하는지, 어떤 부분이 병목인지를 정량적으로 파악할 수 있어야 한다는 점
  • Agentic AI 시스템은 구조가 복잡해질수록 디버깅과 튜닝 난도가 급격히 높아지므로, Observability와 Evaluation을 PoC 단계부터 함께 설계해야 한다는 점


멀티 에이전트 기반 검색 서비스 MVP

문제 정의: K RAG의 다음 단계

저희가 정의한 프로젝트명은 “RAG Agent for DB & Web”입니다. 출발점은 KT의 검색 엔진, 즉 K RAG의 다음 단계를 탐색하는 것이었습니다.

현재 IntelliSearch는 KT 자체 모델과 기술을 활용하는 검색 엔진으로, 키워드 검색, 벡터 기반 유사도 검색, 웹 검색 등 다양한 방식을 지원합니다. K RAG는 이미지/PDF 등 다양한 문서 형식을 파싱하고, LLM 기반 고급 질의응답 기능을 제공하는 엔진으로, 비정형 텍스트 중심의 검색·Q&A에 강점을 가집니다.

실제 사용자 질의는 점점 복잡해지고 있습니다.

  • 여러 시스템에 흩어진 정보를 한 번에 묻는 복합 질의
  • 정형/비정형/외부 정보를 동시에 활용해야 답이 나오는 질문
  • “찾고, 조합하고, 요약해 달라”는 형태의 고급 질의

기존의 단일 파이프라인만으로는 이러한 요구를 유연하게 처리하기 어려워졌습니다. 따라서 사용자가 한 번의 질의로 비정형 문서·정형 DB·웹 정보를 함께 조회하는 경험을 PoC로 수행하기로 했습니다.

  • 영화(미디어) 데이터로 구성된 DB를 검색하는 에이전트 개발
  • DB 검색 에이전트와 웹 검색 에이전트를 멀티에이전트 구조로 통합
  • 부트캠프 기간을 고려해 MVP 수준의 PoC를 완성하고, 구조적 타당성과 기본 성능을 검증

아키텍처: 멀티에이전트 코디네이터 패턴

01.jpg


저희는 멀티에이전트 코디네이터(Coordinator) 패턴을 중심으로 시스템을 설계했습니다.

  • 메인 코디네이터 에이전트는 사용자의 자연어 질의를 입력받아 질의 의도를 파악하고, 어떤 서브 에이전트(DB / Web)가 필요한지 플랜을 수립합니다. 이후 정해진 플랜에 따라 적절한 순서로 작업을 위임하고, 결과를 통합해 최종 답변을 생성합니다.
  • DB 검색 에이전트는 영화/인물 DB에 대해 질의를 수행하고, 필요한 정보를 영화 제목, 감독, 개봉연도 등 구조화된 형태로 반환합니다.
  • 웹 검색 에이전트는 SerpAPI를 활용해 웹 검색을 수행하고, 필요한 정보를 자연어 요약 형태로 반환합니다.

사용자 관점에서는 하나의 대화형 인터페이스로 보이지만, 내부적으로는 메인 코디네이터가 여러 서브 에이전트를 호출·조합하면서 질의를 해결하는 구조입니다. 단일 LLM 호출로는 처리하기 어려운 복합 질의를, 여러 에이전트의 협력 플로우를 통해 유연하게 다루는 것이 핵심 설계 방향입니다.

기술 스택 및 데이터

에이전트 및 서비스 개발

  • 에이전트 개발: LangChain, LangGraph
  • UI: Streamlit
  • 관측성(Observability): Langsmith, Langfuse
  • LLM: Gemini 2.5 Flash, Gemini 2.5 Pro (API 기반)

데이터

  • 사내 미디어 데이터 기반 DB
  1. 영화 데이터: 40,000편 이상
  2. 인물 데이터(배우, 감독 등): 90,000명 이상
  • 평가용 테스트 데이터셋
  1. 부트캠프 범위 내에서 소규모로 설계
  2. 15건 (일반 상식 질의 5건, DB 조회(NL2SQL) 질의 10건)

에이전트 도구(Tools)

  • DB 도구: SQLAlchemy ORM 기반 Python 함수
  • 웹 검색 도구: SerpAPI 기반 검색 함수

구현 과정에서의 핵심 설계 포인트

부트캠프 일정 내에 PoC를 완성하기 위해, 저희는 다음 세 가지를 우선순위로 두고 설계를 진행했습니다.

1. Tool 세분화와 description 튜닝

DB 검색 기능을 여러 Tool로 세분화하고, 각 Tool의 입력 파라미터, 반환 형식, 책임 범위를 명확히 정의했습니다. 또한 Tool description에는 다음 내용을 구체적으로 기술했습니다.
  • 어떤 상황에서 이 Tool을 사용해야 하는지
  • 어떤 컬럼/테이블을 중심으로 동작하는지
  • 반환값이 어떤 구조로 주어지는지

이를 통해 메인 에이전트가 적절한 Tool을 선택하도록 유도했습니다. 실제 구현 과정에서 프롬프트 엔지니어링 못지않게 Tool description 작성과 수정에 많은 시간을 투자했으며, 에이전트의 행동과 안정성에 미치는 영향을 직접 확인할 수 있었습니다.

2. 포맷 에러 방지 및 안정성 확보

메인 에이전트가 플랜을 수립한 뒤 첫 Tool 호출을 수행할 때, LLM이 생성한 요청 포맷이 정의와 어긋나면서 에러가 발생하는 경우가 있었습니다. 이를 줄이기 위해, 본격적인 Tool 실행 전에 플랜 수립 여부와 포맷을 검증하는 별도 Tool을 두어 형식 오류를 사전에 점검하도록 설계했습니다.

이 구조를 통해 런타임 에러를 초기에 차단하면서, 제한된 리소스와 시간 안에서도 비교적 안정적인 동작을 확보할 수 있었습니다.

3. 제한된 리소스 안에서의 선택과 집중

부트캠프 기간이 길지 않았기 때문에, 저희는 DB 에이전트의 정확도와 안정성 확보에 리소스를 집중하고, 웹 검색 에이전트는 PoC에 필요한 최소 기능 위주로 구현하는 전략을 선택했습니다. 성능 평가는 LLM judge를 활용한 자동화된 평가 파이프라인으로 구성해, 반복 실험에 드는 수고를 줄이고 개선 사이클을 빠르게 돌릴 수 있도록 했습니다.

평가 및 Showcase Day 시연

평가 설정과 결과

부트캠프의 목적과 시간 제약을 고려해, 소규모 평가 데이터셋(총 15건) 으로 PoC의 방향성과 구조를 검증했습니다.
  • 일반 상식 질의 5건: 주로 웹 검색 중심 질의
  • DB 조회(NL2SQL) 질의 10건: 영화/인물 정보 조회, 조건 검색 등

각 질의에 대해
  • 최종 답변이 의도한 정답과 일치하는지
  • 필요한 경우 DB와 웹을 모두 활용했는지

를 기준으로 평가한 결과, 15건 중 14건에서 기대한 정답 또는 이에 준하는 응답을 생성해, 소규모 데이터셋 기준으로는 90% 이상 정확도를 확인할 수 있었습니다.

다만 데이터셋 규모가 작기 때문에, 절대적인 성능 수치보다는 아키텍처 방향성과 멀티에이전트 구조의 타당성을 검증하는 데 초점을 두었습니다.

Showcase Day 데모 시나리오

이미지
Showcase Day에서는 DB와 웹을 모두 활용해야만 답을 낼 수 있는 복합 질의를 중심으로 데모를 구성했습니다. 대표 예시는 다음과 같습니다.

다크 나이트 영화 재밌던데, 감독이 누구야? 그리고 그 감독 최근 작품도 알려줘.

이 질의에 대해 시스템은 다음과 같은 흐름으로 동작합니다.

1. 메인 코디네이터 에이전트: 질의를 분석해, 영화·감독 정보는 DB 조회, 감독의 최신작 정보는 웹 검색이 필요하다고 판단합니다. 이에 따라 “DB 에이전트 호출 → 웹 에이전트 호출 → 결과 통합” 형태의 플랜을 수립합니다. 예를 들어 아래와 같은 계획이 출력됩니다. 
    a. call_db_agent로 ‘다크 나이트’의 감독 정보를 조회
    b. call_web_agent로 해당 감독의 최신작을 검색
    c. 두 결과를 합쳐 최종 답변을 생성
2. DB 검색 에이전트: 영화/인물 DB에 대해 다음과 같은 multi-hop 쿼리를 수행합니다.
    a. 영화 테이블에서 ‘다크 나이트’의 movieCode를 조회
    b. 해당 movieCode를 필모그래피로 가진 인물 목록 중 ‘감독’ 역할에 해당하는 personId를 식별
    c. People 테이블에서 해당 personId를 조회해 크리스토퍼 놀란이라는 감독명을 반환
3. 웹 검색 에이전트: DB에서 반환된 “크리스토퍼 놀란”을 키워드로 웹 검색을 수행하고, 최근 개봉작과 공개된 차기작 정보를 요약해 반환합니다.
  • 최근 개봉작으로 2023년 영화 오펜하이머를 식별
4. 메인 코디네이터 에이전트: DB와 웹 검색 결과를 통합해 사용자 관점에서 이해하기 쉬운 자연어 응답을 생성합니다. 

안녕하세요! 문의하신 영화 '다크 나이트'의 감독과 그의 최신 작품에 대한 정보를 찾아왔습니다.
  • 감독: 크리스토퍼 놀란
  • 최근 작품: 2023년에 개봉한 오펜하이머입니다.
        또한, 차기작으로는 호메로스의 서사시 '오디세이아'를 원작으로 하는 영화가 2026년 개봉 예정이라고 합니다.
        더 궁금한 점이 있으시면 언제든지 다시 물어보세요

이 데모를 통해, 단일 LLM 호출이 아니라 여러 에이전트를 오가며 정보를 검색·조합하는 에이전트 기반 플로우를 직관적으로 보여줄 수 있었습니다.


Showcase Day: 다른 팀들로부터의 인사이트

Showcase Day에는 통신, 금융, 제약, 회계 등 다양한 산업의 팀들이 참여해 각자의 Agentic AI 프로젝트를 소개했습니다. 이를 통해 Agentic AI가 실제 어떤 업무에 어떻게 적용되고 있는지를 한눈에 살펴볼 수 있었습니다.

인상적이었던 프로젝트들

  • Bell Canada – Pricing Virtual Assistant
    캐나다 통신사 Bell의 요금제 상담 에이전트로, 사용자의 사용 패턴과 예산 등을 입력받아 최적 요금제 조합을 제안하는 시스템이었습니다. 통신 도메인 특화 Agentic AI 사례로, 실제 매출과 바로 연결될 수 있는 실용적인 활용이라는 점이 인상적이었습니다.
  • CIBC – SmartServe  
    캐나다 주요 은행 CIBC의 금융 상품 상담 에이전트로, 고객 질의에 응답하는 수준을 넘어 개인화된 금융 상품 추천까지 수행하도록 설계되어 있었습니다. 규제 환경이 강한 금융 도메인에서 Agentic AI를 적용하는 방식을 엿볼 수 있었습니다.
  • Roche – 임상시험보고서(CSR) 작성 보조 에이전트  
    스위스 바이오테크 제약사 Roche의 프로젝트로, Clinical Study Report(CSR)와 같이 구조가 복잡한 문서 작성 과정을 보조하는 에이전트였습니다. 완전 자동화가 아니라 사람이 해야 할 복잡한 작업의 일부를 부분적으로 자동화·지원하는 방식이 특징적이었습니다.
  • EY – 내부 감사 지원 에이전트  
    글로벌 회계법인 EY의 내부 감사 업무 지원 에이전트로, 규정, 보고서, 로그 등 여러 자료를 동시에 참조해야 하는 복잡한 절차형 업무에 Agentic AI를 적용한 사례였습니다. 감사 프로세스의 일부를 자동화하면서도, 주요 판단은 사람이 내리도록 설계된 Human-in-the-Loop 구조가 인상적이었습니다.

여기서 얻은 주요 인사이트

여러 프로젝트를 비교해 보면서, 다음과 같은 공통된 흐름을 읽을 수 있었습니다.

  1. 자동화 대상 업무의 복잡도 증가 
    단순 FAQ나 단일 API 호출이 아니라, 여러 자료를 참조하고 여러 단계를 거치는 복잡한 업무에 Agentic AI가 적극적으로 적용되고 있었습니다.
  2. Human-in-the-Loop 설계의 중요성 
    완전 자동화보다는 “어디까지를 에이전트가 처리하고, 어디부터는 사람이 개입해야 하는지”를 업무 단위로 명확히 설계하는 팀들이 많았습니다. 특히 금융·제약·회계처럼 규제가 강하고 리스크가 큰 도메인일수록 Human-in-the-Loop 구간이 분명하게 정의되어 있었습니다.
  3. 도메인 특화 설계의 필수성 
    통신, 금융, 제약, 회계 등 도메인에 따라 에이전트 구조와 요구 기능이 크게 달랐습니다. 비슷한 도메인 내 기업들은 유사한 문제를 유사한 방식으로 해결하고 있었고, 이는 향후 KT 내부에서도 도메인별 Agentic AI 설계를 고민할 때 좋은 참고가 될 수 있는 부분이었습니다.

우리가 얻은 것과 앞으로의 계획

이 경험을 통해 얻은 학습

첫째, 에이전트 설계에서 Tool 튜닝의 비중을 다시 인식하게 되었습니다. 프롬프트 엔지니어링뿐 아니라, 어떤 기능을 어떤 단위로 Tool로 분해하고 각 Tool의 설명을 어떻게 작성하는지가 에이전트의 성능·안정성에 큰 영향을 미친다는 점을 실전 구현을 통해 확인했습니다.

둘째, 실전 Agentic AI 서비스 설계 원칙을 정립하는 데 중요한 경험을 쌓을 수 있었습니다. 관측성(Observability) 확보, 비용/성능 트레이드오프 관리, 실패 케이스 수집·분석 및 개선 루프 설계 등은 이론만으로는 잘 보이지 않는 부분이었으나, 실제 PoC를 운영하면서 그 필요성을 체감했습니다. 특히 멀티에이전트 구조에서는 어디에서 어떤 이유로 에러가 발생했는지 추적하는 능력이 서비스 품질에 직결된다는 점을 확인했습니다.

셋째, 업계가 Agentic AI에 기대하는 현실적인 역할을 이해하게 되었습니다. 여러 기업과 교류하면서, 현재 업계가 기대하는 Agentic AI는 “완전 자율 AI”라기보다는 복잡한 실제 업무를 책임 있게 보조·부분 자동화하는 도구에 가깝다는 인상을 받았습니다. 자동화의 범위와 Human-in-the-Loop의 경계 설정이 앞으로의 Agentic AI 설계에서 핵심적인 논의 지점이 될 것이라 판단하고 있습니다.

앞으로의 계획

조직/서비스 관점에서, 이번 부트캠프에서 얻은 아키텍처와 구현 경험을 바탕으로 K RAG에 Agentic RAG 기능을 단계적으로 도입·고도화할 계획입니다. 정형/비정형/내부/외부 데이터를 모두 아우를 수 있는 통합 검색·질의응답 솔루션으로 진화시키는 과정에서, 이번 PoC에서 검증한 멀티에이전트 코디네이터 패턴을 핵심 레퍼런스로 삼을 예정입니다.

개인/팀 역량 관점에서는, Agentic AI 시스템 역시 다른 IT 서비스와 마찬가지로 아키텍처 설계가 성공의 핵심이라는 점을 다시 확인했습니다. 모델 선택뿐 아니라 각 구성 요소의 역할과 한계를 명확히 정의하고, 이를 적절한 워크플로우로 구조화하는 능력에 더 많은 고민과 실험을 투자할 계획입니다.


마치며

Vector Institute의 Agentic AI Bootcamp는 단순한 기술 교육을 넘어, 전 세계 기업들이 Agentic AI를 실제 업무에 어떻게 활용하고 있는지를 한자리에서 확인할 수 있었던 자리였습니다. AI검색기술팀이 완성한 PoC 자체도 의미가 있었지만, 더 큰 가치는 “Agentic AI 시스템을 실제 서비스 수준으로 설계하려면 무엇을 고민해야 하는가”에 대한 실질적인 감각과 설계 원칙을 얻었다는 데 있다고 생각합니다.

이번 경험을 바탕으로, 더 많은 데이터 소스와 더 복잡한 업무를 다루는 실용적이고 영향력 있는 AI 에이전트 기반 검색 솔루션을 만들어 나가고자 합니다.


참고 자료 & 링크


박국현, 김대현, 김윤종

KT의 Agentic AI Lab에서 K RAG 시스템과 API를 설계하고 서비스 개발을 담당하고 있습니다.

이전 글