AI 데이터 분석가 ‘물어보새’ 그 다음 – 3부. Agent로 더 넓고 깊은 지식 공유하기

AI 기술을 활용해 구성원의 의사결정을 지원하는 BADA(Baemin Advanced Data Analytics)팀은 우아한형제들 구성원의 데이터 리터러시와 업무 생산성 높이는 ‘물어보새’를 비롯해 다양한 AI 기반 데이터 프로덕트를 개발하고 있습니다.

2024년에 AI 데이터 분석가 ‘물어보새’를 공개한 이후 많은 분들이 BADA팀에 관심을 보내주셨습니다. 특히 “BADA팀은 지금 어디까지 왔나요?”라는 질문을 자주 받았습니다.

이 질문에 답하기 위해 이번 3부를 준비했습니다.

1부에서는 RAG와 Text-to-SQL 활용, 2부에서는 Data Discovery 기능을 중심으로 사내 구성원의 데이터 리터러시를 어떻게 높일 수 있었는지 구체적인 사례를 소개했습니다.

이번 3부도 ‘구성원의 질문’에서 출발합니다. 그 여정이 가리킨 도착지는 스스로 생각하고 행동하는 에이전트 기반의 ‘더 넓고 깊은 지식 공유하기’로 자연스럽게 이어집니다.

올해는 데이터 중심의 탐색 단계를 넘어, ‘지식의 탐색, 연결 그리고 확산’이라는 목표에 집중했습니다. 구성원이 데이터를 찾는 이유와 맥락을 이해하고, 조직 전체의 경험과 지식을 유기적으로 연결하는 것이 중요했습니다.

이렇게 축적되고 연결된 도메인 지식은 향후 지능형 데이터 분석 서비스의 토대가 됩니다. 그 과정 속에서 ‘물어보새’는 사내 구성원의 다양한 요구 사항을 끊임없이 반영하며 전사에서 널리 활용되는 서비스로 성장했습니다.

지난 1년간 ‘물어보새’가 어떤 고민과 실험을 거쳐왔는지 사용자 경험 관점에서 기술 도입의 여정을 깊이 있게 다뤄보도록 하겠습니다.

‘물어보새’는 거창한 기술 목표에서 출발하지 않았습니다.
시작은 구성원이 데이터를 더 쉽게 이해하고 활용할 수 있도록 돕는 것이었습니다.

그렇기에 우리가 가장 먼저 주목한 것은 ‘구성원의 질문’이었습니다. 질문은 구성원이 업무 중 무엇을 해결하고 싶어 하는지, 어디서 불편을 느끼는지 보여주는 가장 직접적인 신호였기 때문입니다.

1.1 구성원의 질문과 기대

초기 ‘물어보새’는 Text-to-SQL, Data Discovery 기능 중심으로 데이터 질문에 특화된 서비스였습니다.

하지만 서비스가 공개된 이후 ChatGPT, Claude, Gemini 등 다양한 LLM 서비스 성능이 급속히 발전하면서 사용자들의 답변 기대 수준도 빠르게 변화했습니다. 이제 구성원들은 단순히 데이터를 조회하는 도구를 넘어 업무와 지식을 아우르는 비즈니스 어시스턴트를 기대하기 시작했습니다.

‘물어보새’에 들어오는 질문은 데이터 중심의 문의를 넘어 점차 사내 전반의 지식 영역으로 확장되었습니다.

“OD가 뭐야?”
“회사 주소 알려줘”
“IT 보안 담당자는 누구고 어떤 일을 해?”
“배민 2.0이 뭐야?”
“한그릇 서비스 성과 분석해줄래?”

질문의 폭이 넓어지면서 단순한 데이터 조회와 탐색만으로는 구성원의 요구를 충족하기 어려웠습니다. 이러한 확장된 질문은 ‘물어보새’에 대한 기대 수준을 보여주는 지표였고, 우리는 그 기대를 만족시키는 것을 최우선 목표로 삼았습니다.

1.2 ‘물어보새’의 2025년 목표

이러한 질문에 답하기 위해서는 데이터 추출 환경(예: Zeppelin)을 넘어, 사내 포털·Confluence Wiki·Jira·Slack·Google Drive 등 사내 지식 전반을 연결하는 답변이 필요했습니다.

또한, 이전 대화를 기억하고 자연스럽게 이어가는 대화 맥락 유지(multi-turn) 기능과 불만족한 답변이 있을 경우 즉시 개선되는 운영 시스템도 갖춰야 했습니다. 그리고 단순 요약이나 전달을 넘어 질문의 의도를 해석하고 적절한 도구를 선택/실행해 실제 업무까지 처리하는 능력이 요구되었습니다.

하지만 이러한 요구는 단일 시스템으로는 감당하기 어려웠습니다. 복잡하고 다양한 질문 유형을 처리하기 위해서는 완전히 새로운 접근 방식이 필요했습니다. 다시 말해, 구성원의 기대 수준은 기존에 구축된 RAG 기반 서비스로 충족할 수 없었습니다.

이제는 다양한 지식 자원을 연결해 탐색하고, 질문의 맥락을 이해한 뒤 단계적 추론과 도구 선택으로 목적에 맞는 행동을 수행하는 ‘지능형 서비스’를 갖춰야 했습니다.

이러한 기능들이 구현되어야 구성원의 기대를 충족시키고, 사내 구성원의 ‘데이터 리터러시’와 ‘업무 생산성’을 동시에 높일 수 있습니다. 이 방향성은 2부에서는 Data Discovery 기능과 WOOWACON 2024 AI 데이터 분석가 ‘물어보새’ 등장 : 데이터 리터러시 향상을 위한 나만의 데이터 분석가에서 소개한 3단계 업무 협업 수준 ‘부분 업무 지능화’ 단계에 가까웠습니다.

다음 장에서는 이러한 목표를 달성하기 위해 사용자의 요구를 어떻게 해결해 나갔는지 구체적인 문제 해결 과정을 이야기 해보겠습니다.

앞서 말씀드린바와 같이 ‘물어보새’는 더 이상 단일 응답을 반환하는 구조로는 충분하지 않았습니다. 사용자의 의도를 분류하는 것을 넘어 해석하고, 필요한 정보를 스스로 찾아 조합하며, 때로는 여러 단계를 거쳐 실행 가능한 결과를 제안하는 시스템으로 진화해야 했습니다.

이런 변화를 실현하기 위해, 우리는 네 가지 핵심 요소를 정의했습니다.

• 확장(Knowledge Expansion)
  다양한 지식 자원을 연결해 더 넓은 시야로 답을 찾아줍니다.

• 기억(Long/Short-Term Memory)
  대화의 맥락과 사용자의 이전 경험을 이어줍니다.

• 관찰(Tracing)
  시스템이 스스로 판단하고 개선할 수 있도록 과정을 투명하게 기록합니다.

• 사고(Agentic Workflow)
  고유 역할을 가진 에이전트가 단계적 추론과 도구 선택으로 문제를 해결합니다.

시스템의 개선 방향이 명확해졌지만 여전히 가장 큰 도전이 남아 있었습니다.

바로 확장성과 자율성을 동시에 확보하는 일이었습니다. 서비스가 전사로 확산될수록 데이터 소스와 질문 유형이 빠르게 늘어났고, 그 속에서도 맥락을 잃지 않으면서 빠르고 일관된 품질을 유지해야 했습니다.

이에 대한 해답으로 우리는 앞서 정의한 네 가지 요소를 토대로 ‘멀티 에이전트 시스템’ 기반 아키텍처의 전환을 선택했고, 서로 다른 역할을 수행하는 전문화된 에이전트들이 유기적으로 협업하도록 시스템을 재설계했습니다.

이제 ‘확장’, ‘기억’, ‘관찰’, ‘사고’를 따라 ‘물어보새’가 어떻게 발전해 왔는지 차례로 살펴보겠습니다.

2.1 확장: 질문의 경계를 넓히다: Knowledge Expansion

(1) 분산된 지식과 비효율적인 검색

가장 먼저 ‘물어보새’가 다룰 수 있는 지식 자원의 스펙트럼을 확장했습니다.

기존에는 데이터베이스 중심으로 테이블 DDL, 메타데이터, SQL few-shot 예시 등 데이터 탐색 중심의 정보만 다뤘습니다. 하지만 실제 사용자들의 질문은 점점 더 업무 전반의 지식으로 확장되고 있었습니다.

문제는 이런 정보가 이미 사내 여러 곳에 흩어져 있었다는 점이었습니다. Wiki에는 개발 및 디자인 문서와 프로젝트 기록들이, Jira에는 이슈 관리 및 진행 상황이, 사내 포털에는 공지, 정책, 복리후생 정보가 Slack에는 업무 문의 관련 실시간 대화가 존재했습니다.

정보가 너무나 흩어졌기 때문에 사용자들은 각 시스템을 일일이 찾아다니는 대신 ‘물어보새’에게 도메인 지식에 대한 정보도 한 번에 질문하고 답을 받길 원했습니다.

또 다른 문제는 기존 검색의 비효율성이었습니다. 각 플랫폼의 기본 검색 기능은 키워드 매칭에만 의존해 문서 목록만 보여줄 뿐 사용자가 직접 문서를 열어봐야 원하는 답을 찾을 수 있었습니다.

(2) 지식 확장과 검색 시스템 고도화

이런 한계를 해결하기 위해, ‘물어보새’는 데이터를 넘어 사내 전반의 비정형 지식을 통합하는 파이프라인을 구축했습니다.

사내 포털·Confluence Wiki·Jira·Slack·Google Drive 등 업무 전반을 포괄하는 다양한 비정형 데이터를 통합적으로 수집했습니다. 그 결과 ‘물어보새’는 더 이상 특정 부서나 시스템에 한정되지 않고 조직 전체의 문맥을 이해하는 통합형 지식 시스템으로 발전했습니다.

또한 이렇게 수집된 방대한 데이터를 효율적으로 검색하고 LLM이 참고할 수 있도록 BM25s 기반 검색 알고리즘을 사용했습니다. BM25s는 인덱싱 단계에서 각 문서 토큰의 BM25 가중치를 미리 계산해 희소 행렬(sparse matrix) 형태로 저장하는 사전 계산(eager sparse scoring) 방식의 검색 모델입니다. 쿼리 시점의 계산을 최소화하여 기존 대비 최대 500배 빠른 검색 성능을 제공합니다. 이 방식은 질의와 문서 간의 유사도를 정교하게 계산하며 실제 Retriever 성능 테스트에서 기존 대비 약 15%의 검색 품질 향상을 확인했습니다.

위 과정을 거쳐 지식의 경계를 허물어졌지만 새로운 한계가 드러났습니다.

한 번의 질문(single-turn)에는 정확하게 답했지만, 이전 대화의 맥락을 기억하지 못해 후속 질문(multi-turn)에서는 일관성이 깨지는 ‘기억 상실’ 문제가 생긴 것입니다. 사용자는 연속된 대화 속에서 자연스러운 답변을 기대했지만 시스템은 매번 처음부터 다시 질문을 해석해야 했습니다. ‘지식의 확장’은 성공했지만, ‘맥락의 기억’은 비어 있었던 셈이었습니다.

다음 단계의 목표는 ‘기억’을 활용해 대화의 흐름과 맥락을 유지하는 방법을 찾는 것이었습니다.

2.2 기억: 대화의 맥락을 이어가다: Long/Short-Term Memory

(1) 기억 상실 문제

사용자는 대화를 이어갈 때 이전 맥락이 자연스럽게 유지되기를 기대합니다. 하지만 초창기 ‘물어보새’는 매번 새로운 대화로 인식했습니다. LLM API 호출 요청에는 오직 직전 질문만 포함되었기 때문입니다.

예를 들어,

첫 번째 질문: 지난 분기 푸드 서비스 매출은 얼마야?
두 번째 질문: 그럼 작년 동기 대비 매출 증감률은?

첫 번째 질문에 이어 두 번째 질문이 이어지면, 푸드 서비스 매출이라는 핵심 정보를 잊어버리고 새로운 질문으로 처리했습니다. 결국 문맥을 잃은 답변이 나오는 ‘기억 상실’ 문제가 발생했습니다.

(2) 대화 메모리 시스템 구축

이 문제를 해결하기 위해 ‘물어보새’는 대화의 모든 요소를 기록하고 재구성하는 대화 메모리 시스템을 새롭게 설계했습니다. 단순히 텍스트를 저장하는 것이 아니라 에이전트의 판단 근거, 도구 호출 내역, 실행 결과, 최종 답변까지 대화의 흐름 전체를 체계적으로 기록하고 다음 질문에 반영하는 구조입니다.

메모리 시스템의 주요 작동 방식은 다음과 같습니다.

• 대화 이력 저장
  사용자 질문, 실행된 도구, 첨부 파일, 최종 답변 등 모든 대화 관련 정보를 데이터베이스에 저장합니다.

• 선택적 맥락 불러오기
  모든 대화 이력을 전달하는 대신 최근 몇 개의 질문–답변 쌍만 불러와 효율적으로 맥락을 유지합니다.

• 질문 재구성 및 압축
  불러온 과거 대화는 새로운 질문과 결합되어 자연스러운 단일 질의로 재구성됩니다. 이때 이전 대화는 요약되거나 핵심만 압축되어 전달되어 입력 문맥의 한계(context window)를 효율적으로 관리할 수 있습니다.

• 연속 대화 생성
  재구성된 맥락을 기반으로 LLM이 답변을 생성하고, 이 결과 또한 메모리에 저장되어 다음 대화의 기반이 됩니다.

메모리 시스템의 도입으로 ‘물어보새’는 이전 대화를 자연스럽게 이어가며 맥락을 이해하는 대화형 서비스로 진화했습니다.

사용자가 “푸드 서비스 매출을 보여줘” 질문 이후에 “그리고 일자별로 알려줘” 라고 말했을 때 이전에는 두 문장을 별개의 요청으로 처리했지만 이제는 ‘그것’이 ‘푸드 서비스 매출’임을 인식하고 적절한 도구를 호출해 일자별 데이터를 조회할 수 있습니다.

대화의 연속성이 확보되면서 자연히 질문 수가 증가했고, 이에 따라 구성원이 원하는 답변을 정확하게 제공했는지를 측정할 수 있는 관리 체계가 다음 기술적 과제로 떠올랐습니다.

2.3 관찰: 답변의 과정을 투명하게 남기다: Tracing

(1) 결과 뒤에 숨어 있는 원인

대화의 연속성이 확보되면서 ‘물어보새’의 질문 수는 빠르게 증가했습니다.
그러나 그만큼 의도치 않은 오답이나 불만족스러운 답변도 함께 늘어났습니다.

사용자 만족도 피드백(👍/👎)만으로 문제의 존재는 확인할 수 있었지만, 정작 왜 그런 답변이 나왔는가?를 실시간으로 파악하기는 어려웠습니다. 기존 로그 분석 방식은 LLM이 생성하는 결과를 수동으로 정제해야 했기 때문에 분석에 많은 시간과 비용이 소요되었습니다.

또한 LLM의 비결정적 특성(non-determinism)으로 인해 같은 질문이라도 답변이 매번 조금씩 달라졌습니다. 설령 로그를 확보하더라도 동일한 조건에서 같은 답변 과정을 재현하기가 거의 불가능했습니다.

결국 우리는 결과를 보는 것만으로는 품질을 개선할 수 없다는 사실을 깨달았습니다. 필요했던 것은 답변의 결과가 아니라 답변이 만들어지는 ‘과정’을 실시간으로 관찰할 수 있는 도구였습니다.

(2) Tracing 시스템 구축

이 문제를 해결하고 LLM 서비스의 투명성을 높이기 위해 ‘물어보새’는 Tracing 시스템을 도입했습니다.

Tracing은 사용자의 질문이 들어온 순간부터 최종 답변이 생성될 때까지의 전 과정을 단계별로 추적합니다. 그 결과 LLM이 어떤 도구를 호출했는지, 어떤 검색 결과 단계를 참고했는지, 어떤 판단을 거쳐 답을 도출했는지를 한눈에 파악할 수 있습니다. Tracing의 주요 핵심 효과는 다음과 같습니다.

• 전 과정 추적 및 흐름 파악
  질문부터 답변까지의 실행 과정을 실시간으로 시각화하여 에이전트의 의사결정 순서, 도구 호출 이력, 중간 판단 흐름을 명확하게 이해할 수 있습니다.

• 운영 효율성 향상
  LLM 호출 비용과 처리 지연(latency) 같은 운영 지표를 실시간으로 모니터링하여 성능 병목 구간을 빠르게 식별하고 최적화할 수 있습니다.

• 품질 개선 체계 확보
  Tracing 데이터를 기반으로 답변 품질을 체계적으로 평가하고 개선할 수 있는 온·오프라인 평가 체계를 구축했습니다.

온·오프라인 평가에 대해 구체적으로 설명을 드리면, 온라인 평가는 실시간 사용자 질문과 답변 품질을 모니터링하는 데 중점을 둡니다. 이를 바탕으로 A/B 테스트를 수행하거나 특정 질의 유형의 문제를 신속하게 진단하고, 사용자 질문을 오프라인 평가 데이터로 재활용할 수 있습니다.

오프라인 평가는 모델 성능 개선과 전략 수립을 위한 분석 중심의 평가로 평가 데이터 생성 및 품질 측정, 모델별 성능 비교, 서비스 품질 지표 개발 등 장기적인 모델 개선 방향을 체계적으로 설계할 수 있도록 지원합니다.

Tracing 도입 이후 ‘물어보새’는 답변 생성 과정의 투명성을 확보했습니다. 이제 단순히 좋다/나쁘다 수준의 피드백을 넘어, ‘왜 이런 답변이 나왔는가?’를 명확히 이해하고 개선할 수 있습니다.

이는 곧, ‘물어보새’가 스스로 품질을 진단하고 발전할 수 있는 자가 개선(self-Improving) 시스템으로 성장할 수 있는 토대가 되었습니다.

2.4 사고: 자율적 판단으로 신뢰도를 높이다: Agentic Workflow

(1) 복잡한 요구, 더 높은 기대

지식 기반을 확장하고, 대화의 맥락을 기억하며, 답변 품질을 관리할 수 있는 구조까지 갖춘 뒤에도 ‘물어보새’를 향한 구성원들의 기대는 멈추지 않았습니다.

이제 구성원들은 단순히 정보를 검색하고 요약하는 도구가 아닌 스스로 사고하고 판단해 문제를 해결하는 수준을 기대했습니다. 즉, ‘물어보새’가 여러 도구를 유기적으로 연계해 상황을 분석하고 그 결과를 바탕으로 다음 행동을 스스로 결정하길 원했던 것입니다.

예를 들어, “BADA팀 최근 프로젝트 진행 상황과 관련 문서들 정리 및 분석해줘”라는 요청은 단순히 검색뿐만 아니라 다음과 같은 복합적인 단계를 포함합니다.

• 정보 검색(RAG): 내부 데이터베이스와 문서에서 프로젝트 관련 정보를 탐색
• 도구 호출(Confluence): 프로젝트 상세 문서 조회
• 도구 호출(Jira): 이슈 및 진행 상태 확인
• 정보 추론 및 정리: 각 도구에서 얻은 정보를 종합하여 맥락화
• 결과 생성: 종합된 정보를 바탕으로 최종 답변 작성

초기에는 이러한 복합 요청을 단일 워크플로우로 처리했습니다(예: RAG → 요약 → RAG → 답변). 그러나 이 방식은 개발자가 설계한 순서에만 의존했기 때문에 새로운 질문이 등장할 때마다 코드를 수정해야 하는 비효율적이고 유지보수 불가능한 구조로 이어졌습니다.

이 한계를 마주하던 중, 꾸준히 기술 협업을 진행해 온 AWS의 도움으로 Anthropic AI 개발자와 이야기할 기회를 얻었고, 그 자리에서 단순하지만 강력한 메시지를 들었습니다.

“LLM이 가진 가능성은 여러분이 생각하는 것보다 훨씬 큽니다. LLM에게 믿고 위임하세요.”

이 한 문장이 ‘물어보새’의 아키텍처 방향을 완전히 바꿔놓았습니다. 개발자가 모든 흐름을 제어하는 대신 LLM이 스스로 문제를 분석하고 필요한 도구를 선택하며 결과를 평가할 수 있는 구조로 전환해야 한다는 깨달음이었습니다.

(2) LLM이 스스로 사고하는 ReAct 구조 도입

이 통찰을 바탕으로 ‘물어보새’는 Agentic Workflow 중 ReAct 구조를 도입했습니다. ReAct는 LLM이 스스로 사고(reasoning)와 행동(acting)을 반복하며 복합적인 문제를 단계적으로 해결하는 방식입니다.

ReAct의 기본 순환 구조는 다음과 같습니다.

• Reasoning (추론): 주어진 질문을 분석하고 다음 행동을 결정
• Acting (행동): 필요한 도구(검색, 데이터 쿼리 등)를 실행
• Observation (관찰): 실행 결과를 평가하고 다음 단계로 피드백
• Loop (반복): 목표를 달성할 때까지 추론–행동–관찰을 반복

이 순환 구조 덕분에 ‘물어보새’는 개발자가 사전에 정의하지 않은 문제 상황에도 유연하게 대응할 수 있는 자율적 사고 구조를 갖추게 되었습니다. ReAct Agentic Workflow의 의미는 단순히 기술 개선을 넘어 ‘물어보새’의 사고 체계 전환점이 되었습니다.

이제 ‘물어보새’는 질문을 단순히 이해하는 수준을 넘어 맥락을 추론하고, 행동을 계획하며, 목표를 달성하기 위한 판단을 스스로 수행합니다. 그 결과 답변의 정확성(accuracy)과 일관성(consistency)은 눈에 띄게 향상되었고, 구성원들이 신뢰할 수 있는 수준의 답변을 안정적으로 제공할 수 있게 되었습니다.

ReAct 기반의 에이전트 구조는 ‘물어보새’가 스스로 문제를 해결하고, 필요에 따라 에이전트들과 협력하며 역할을 분담하고 발전하는 자가 학습(self-improving)형 시스템으로 확장될 수 있는 기술적 토대가 되었습니다.

2.5 종합: 물어보새 멀티 에이전트 아키텍처

지금까지 ‘물어보새’가 구성원의 기대에 응답하며 발전시켜 온 네 가지 핵심 기술 축 확장·기억·관찰·사고를 살펴보았습니다. 이 기술들은 각각 독립적으로 도입된 기능이 아니라, 서로 맞물리며 하나의 유기적 구조로 진화했습니다. 새롭게 구성된 ‘물어보새’ 멀티 에이전트 아키텍처는 다음과 같습니다.

그림 1. 물어보새 멀티 에이전트 아키텍처

‘물어보새’의 아키텍처는 거창한 기술적 목표에서 출발한 것이 아닙니다. 구성원의 실제 업무 환경 속 문제를 해결하기 위한 시도들이 차곡차곡 쌓이면서 결과적으로 지금의 멀티 에이전트 시스템 구조가 자연스럽게 구축되었습니다. 이 과정에서 도입된 주요 기술들은 다음과 같이 각 영역의 핵심 요소로 자리잡았습니다.

• 확장(Knowledge Expansion)
  사내 전반의 비정형 데이터를 통합하여 지식의 기반을 넓혔습니다.

• 기억(Long/Short-Term Memory)
  대화의 맥락을 이어 사용자와의 상호작용을 자연스럽게 만들었습니다.

• 관찰(Tracing)
  답변이 생성되는 과정을 투명하게 기록하며 품질 관리와 운영 효율성을 개선했습니다.

• 사고(Agentic Workflow)
  LLM이 스스로 사고하고 판단하며, 여러 에이전트가 협업해 문제를 해결할 수 있는 자율적 구조를 가능하게 했습니다.

이 네 가지 축은 단절된 기능의 나열이 아니라 서로 순환적으로 연결된 체계입니다. 지식의 확장은 대화의 토대를 제공하고, 기억은 그 흐름을 이어갑니다. 관찰은 과정 전반을 기록하며 개선의 근거를 남기고 사고는 그 모든 정보를 활용해 최적의 판단을 내립니다.

그 결과, ‘물어보새’는 단순히 데이터를 검색하는 AI가 아니라 스스로 생각하고, 행동하며, 학습하는 에이전트 기반 비즈니스 어시스턴트로 진화했습니다. 이는 사용자의 질문과 기대를 중심으로 진화한 결과물입니다.

3.1. 흩어진 지식을 하나로 연결하는 사내 지식 탐색: Knowledge Discovery

‘물어보새’는 이미 다양한 사내 데이터를 연결하며 지식의 범위를 넓혀왔습니다.

그러나 곧 새로운 한계에 부딪혔습니다. 정보는 연결되어 있었지만 여전히 서로의 의미가 자연스럽게 이어지지 않았습니다. 사내 포털, Wiki, Jira, Slack 등 채널마다 비슷한 주제가 중복되고, 담당자 정보와 문서 버전이 제각각이어서 구성원들은 단순한 질문 하나에도 여러 플랫폼을 오가야 했습니다.

확장은 끝났지만 이제는 ‘흩어진 지식을 하나의 지식으로 엮는 일’이 남았습니다. 그 과제를 해결하기 위해 시작된 것이 바로 사내 지식 탐색 Knowledge Discovery입니다.

(1) 이미지 속 정보, 검색의 사각지대를 없애다

복지 제도나 사내 정책 문서가 이미지 형태로 게시된 경우가 많아 텍스트 기반의 기존 검색 엔진으로는 내용을 활용할 수 없었습니다. 이 문제를 해결하기 위해 우리는 멀티모달 LLM(텍스트와 이미지를 함께 이해하고 처리할 수 있는 모델)을 도입했습니다.

멀티모달 LLM을 활용해 사내 포털에서 수집된 이미지 데이터를 텍스트로 변환하고, 표 구조나 제목 등 문서 내 계층 정보를 함께 추출해 벡터화했습니다. 이 과정으로 이미지 속 정보까지 검색에 포함되었고 사내 포털의 시각 자료도 이제 하나의 지식 자원이 되었습니다.

(2) 몇만 개의 Wiki, 핵심 문서 중심으로 정리하다

다음으로 마주한 문제는 너무 많은 Wiki 문서였습니다. 팀·프로젝트별로 생성된 수백 개의 Wiki 공간 중 자주 활용되는 문서만 선별해 관리하는 것이 효율적이었습니다.

우리는 Wiki 공간별 문서 생성 수와 최근 2주 조회수를 기준으로 핵심 문서만 자동으로 선별해 수집했습니다. 또한 문서 구조에 따라 정책 문서는 섹션 단위, 프로젝트 문서는 단락 단위, 공지사항은 전체 단위로 저장해 검색 효율성과 문맥 일관성을 모두 확보했습니다. 문서 제목, 팀명, 생성일, 라벨 등 메타데이터도 함께 저장하여 검색의 정밀도를 한층 끌어올렸습니다.

(3) 실시간 정보, MCP 서버로 연결하다

지식을 선별해 저장하는 전략은 효율적이었지만 한계가 있었습니다. 저장 대상이 아니거나 저장 주기 외의 최신 데이터는 반영되지 않아 오늘 새로 등록된 Jira 티켓이나 방금 올라온 Wiki 문서와 같은 실시간 정보는 찾을 수 없었습니다.

이를 해결하기 위해 MCP(Model Context Protocol) 서버를 활용했습니다. MCP는 LLM과 외부 시스템을 표준화된 방식으로 연결하는 프로토콜로, 서로 다른 도구와 서비스를 일관된 인터페이스로 통합할 수 있도록 설계되었습니다. Atlassian MCP 서버로 Confluence Wiki·Jira의 최신 정보와 저장하지 않았던 데이터까지 실시간으로 가져올 수 있게 되었습니다.

뿐만 아니라 이제 사용자는 “이 내용으로 Wiki 문서 만들어줘”라고 말하면 ‘물어보새’가 직접 Wiki 문서를 생성하고, “이 버그를 티켓으로 만들어줘”라고 하면 Jira 티켓을 자동 등록할 수 있습니다. ‘물어보새’는 단순히 정보를 ‘찾는’ 역할에서 정보를 ‘활용하고 실행하는’역할로 확장되었습니다.

다만 외부 서버에 대한 의존은 불안정성을 동반했습니다. 이를 보완하기 위해 Connection Manager를 구축해 주기적으로 서버 연결 상태를 점검하고, 연결 실패 시에는 자동으로 벡터 스토어 기반 검색으로 전환하는 Fallback 전략을 적용했습니다. 덕분에 안정성과 응답 속도를 모두 확보할 수 있었습니다.

(4) ReAct 구조로 스스로 판단하다

정보의 범위와 실시간성은 확보했지만 여전히 어떤 질문에 어떤 도구를 써야 할까?라는 과제가 남았습니다. 변화가 적고 정적인 정책 문서는 벡터 스토어 검색이 적합하고, Jira 티켓이나 신규 프로젝트 상황은 시시각각 바뀌는 데이터이므로 MCP 서버 접근이 필요했습니다.

이 판단을 매번 사람이 설계할 수는 없었기에 우리는 ReAct(reasoning + acting) 구조를 도입했습니다. LLM이 사용자의 질문을 분석해 필요한 도구를 선택하고 결과를 검토해 답변을 완성하는 방식입니다.

예를 들어 "복지 정책 담당자가 누구야"라는 질문이 들어오면, 다음과 같은 과정을 거칩니다.

1. Reasoning(추론)
   담당자 정보가 필요하다고 판단합니다.

2. Acting(행동)
   벡터 스토어에서 조직도를 검색하고, MCP 서버로 최신 담당자 정보를 확인합니다.

3. Observation(관찰)
   담당자 이름, 연락처, 소속팀 정보를 종합해서 답변합니다.

4. 루프(Loop)
   추론–행동–관찰 단계를 결과가 충분해질 때까지 반복 과정을 순환합니다.

이 구조로 ‘물어보새’는 신규 데이터 소스가 추가되더라도 최소한의 설정 변경만으로도 유연하고 빠르게 확장할 수 있는 모듈형 아키텍처를 갖추게 되었습니다.

그림 2. Knowledge Discovery의 ReAct 구조도

(5) 지식을 연결하고 공유하다

Knowledge Discovery 도입 이후 구성원들의 일상 대화부터 달라졌습니다.
“Wiki에서 찾아봐야 하나?” 대신 "‘물어보새’한테 물어봐도 잘 답변해주던데요?”라는 말이 생겨나기 시작했습니다.

그림 3. 물어보새 Knowledge Discovery 기능 예시

이러한 변화는 지식이 시스템 내에서 자동으로 탐색·연결·요약·추천되는 구조 덕분이었습니다.
그 결과 구성원들의 일상 대화와 업무 수행 방식이 자연스럽게 달라졌습니다.

특히 신규 입사자 온보딩에서 효과가 두드러졌습니다. “업데이트된 문서들을 찾고 정리하는 게 어려웠는데 ‘물어보새’가 대신 정리해줘서 큰 도움이 됐다”는 피드백이 대표적입니다.

또한 주간 보고나 연말 평가 작성, 담당자 탐색 등에서도 “시간을 절약하고 실수를 줄였다”는 의견이 이어졌습니다. 긴급한 상황에서도 “법인카드 분실 시 즉시 절차를 안내 받았다”는 사례도 있었습니다.

이처럼 ‘물어보새’는 단순한 검색 도구를 넘어 조직의 지식이 자연스럽게 흐르고 순환하는 중심 허브로 자리 잡았습니다. 사용자 피드백을 기반으로 답변 품질을 개선하고 새로운 데이터 소스를 확장하며 시스템을 고도화해 나가고 있습니다.
‘Knowledge Discovery’는 정보를 찾는 방식을 바꾼 것을 넘어 조직이 지식을 공유하고 학습하는 문화 자체를 변화시키는 출발점이 되었습니다.

3.2 반복되는 업무 문의를 자동으로 해결: Support Channel Automation

(1) 반복되는 질문, 반복되는 답변의 딜레마

사내 업무 지원을 위한 응대 채널을 운영하다 보면 이런 질문을 자주 받게 됩니다.

“데이터베이스 접근 권한은 어디서 신청하나요?”
“VPN 연결이 안 되는데 어떻게 해야 하나요?”
“노트북 장비는 어디서 수령하나요?”

이런 질문들은 매주, 매달 반복되며, 담당자는 같은 답변을 여러 번 작성해야 했습니다. 특히 회의 중이거나 업무 시간 외라면 응답은 더욱 지연될 수밖에 없었습니다.

우아한형제들에서는 이러한 응대 채널을 ‘서포트 채널(support channel)’이라고 부르며, ‘25년 10월 기준 수백 개의 활성화된 서포트 채널이 있습니다. 사업의 규모가 커지고 서비스가 다양해질수록 서포트 채널의 문의량도 급격히 늘어납니다. 그 결과 담당자들은 점점 반복 업무에 묶이게 되고, 정작 본질적인 업무에 집중하기 어려운 상황이 발생합니다.

(2) FAQ 시스템의 한계

이런 문제를 해결할 수 있는 가장 손쉬운 접근 방법은 FAQ 자동응답 시스템이었습니다. 미리 정의된 질문–답변 쌍을 등록해두고, 키워드 매칭으로 자동으로 답을 제시하는 방식입니다.

하지만 실제로 구축해보면 예상치 못한 문제들이 발생합니다.
대표적인 문제는 같은 내용이지만 사람마다 질문 방법이 달랐습니다. “재택근무 신청”, “원격근무 방법”, “집에서 일하려면?” 표현은 다르지만 의미는 같았습니다. FAQ 시스템은 키워드 매칭 기반이기 때문에 질문 변형에 대해 제대로 인식하지 못했습니다.

또한 “로그인이 안 돼요”처럼 맥락이 필요한 질문은 처리하기 어려웠습니다. 어떤 시스템인지, 어떤 환경에서 시도했는지, 어떤 오류 메시지인지 알 수 없기 때문입니다. 무엇보다 FAQ 문서를 지속적으로 업데이트하는 일도 쉽지 않았습니다. 사용자들은 FAQ 문서를 찾기보다 채널에 직접 묻는 방식이 더 편하고 빠르기 때문에 질문 방식을 선호했습니다.

FAQ 문서는 존재했지만 여전히 사람이 응대해야 하는 근본적인 한계가 남았습니다. 이를 해결하기 위해 우리는 문서 기반의 접근을 넘어, 실제 대화 데이터를 활용하는 새로운 방식을 고민했습니다.

(3) 자동 응대 구축 전략

이러한 한계를 극복하기 위해 우리는 문서형 FAQ에서 벗어나 실제 대화 데이터를 기반으로 한 자동 응대 시스템을 구축했습니다. Slack 서포트 채널에 축적된 질문–답변 데이터를 학습 소스로 삼아 다음 네 가지 단계를 중심으로 설계했습니다.

첫째, 복잡한 대화 데이터를 구조화한다

Slack 대화는 FAQ처럼 단일 구조로 정리되어 있지 않습니다. 질문자와 답변자 그리고 제3자의 코멘트가 뒤섞이며 하나의 대화가 여러 단계로 이어집니다.

예를 들어 “VPN 연결이 안 돼요”라는 단순한 문장 안에는 운영체제 확인, 오류 로그 공유, 해결 시도, 최종 피드백까지의 전체 문제 해결 여정이 담겨 있습니다.

이 복잡한 대화를 체계적으로 정리하기 위해 PCSO(Problem–Cause–Solution–Outcome) 구조를 도입했습니다. 대화 스레드를 분석해 다음 네 가지 요소로 요약하고 저장하는 방식입니다.

• 문제(Problem): 무엇이 발생했는가
• 원인(Cause): 왜 발생했는가
• 해결책(Solution): 어떤 조치가 취해졌는가
• 결과(Outcome): 결과는 어땠는가

예를 들어 ‘VPN 연결 실패’ 스레드는 다음과 같이 처리됩니다.

• 문제: 연결 불가
• 원인: 리디렉션 오류
• 해결책: PanGPS 설정 변경
• 결과: 연결 성공

이처럼 대화를 구조화하면, 유사한 사례가 발생했을 때 빠르고 정확하게 참조할 수 있는 지식 데이터로 활용할 수 있습니다. 또한 각 채널의 주제, 담당 팀, 답변 톤 등 메타데이터를 함께 저장하여 검색의 정밀도와 응답 품질을 더욱 높였습니다.

그림 4. PCSO(Problem-Cause-Solution-Outcome) 구조 예시

둘째, 단계적으로 사례를 검색해 답변을 생성한다

신뢰할 수 있는 답변을 제공하기 위해 단계적 사례 검색(progressive retrieval) 전략을 채택했습니다.

이 전략은 요약된 PCSO 데이터에서 전체 Slack 대화로 점차 확장되는 검색 구조를 기반으로 합니다. 먼저 구조화된 PCSO 요약 데이터에서 빠르게 후보를 탐색하고, 필요할 경우 전체 대화 이력을 참조해 추가 맥락을 확보합니다. 검색은 단계적으로 진행됩니다.

사용자 질문을 받으면 먼저 질문의 핵심 문제와 해결 목적을 파악한 뒤, 구체적인 환경, 버전, 오류 메시지 등을 포함한 키워드를 바탕으로 1차 검색을 수행합니다. 예를 들어 “Mac에서 VPN 연결이 안 돼요”라는 질문에는 ‘Mac’, ‘VPN’, ‘연결’, ‘오류’ 등의 키워드가 사용됩니다.

1차 검색으로 충분한 결과를 얻지 못하면, 검색 조건을 단계적으로 완화하며 보다 일반화된 사례를 탐색합니다. 예를 들어 ‘Mac VPN 연결 안 됨’ → ‘VPN 연결 실패’ → ‘네트워크 문제’순으로 범위를 넓혀가며 일반화된 유사 사례를 탐색합니다.

마지막으로 Cross-Encoder 리랭킹을 활용해 질문과 검색 결과의 의미적 유사도를 정밀하게 평가하고 가장 관련성 높은 사례를 기반으로 현재 상황에 맞는 새로운 답변을 생성합니다.

셋째, 자동 응답과 담당자 사이의 검증 균형을 맞춘다

모든 질문을 자동으로 처리하면 품질이 떨어지고, 반대로 모든 요청에 사람이 개입하면 반복 업무 문제는 해결되지 않습니다. 이 두 극단 사이에서 균형을 찾기 위해 질문의 성격에 따라 자동 응답이 적합한 경우와 담당자 개입이 필요한 경우를 구분하는 체계를 구축했습니다.

질문 분류 시스템은 사용자의 질문을 분석해 ‘자동 해결 가능’과 ‘담당자 확인 필요’ 두 가지로 분류합니다. 예를 들어 ‘데이터베이스 접근 권한 신청 방법’ 은 자동 응답이 가능하지만, ’특정 테이블의 데이터 불일치 발생’처럼 세부 검토가 필요한 문의는 담당자에게 즉시 전달됩니다.

답변 품질을 보장하기 위해 LLM 기반 자동 평가(G-Eval)를 도입했습니다. G-Eval은 LLM이 평가자의 역할(LLM as a judge)을 수행하여 사전에 정의된 기준에 따라 텍스트의 품질을 정량적으로 평가합니다. 답변이 실제로 문제를 해결할 수 있는지 그리고 필요한 정보를 충분히 포함하는지를 자동으로 검증한 뒤, 기준을 충족하지 못하면 자동 응답을 중단하고 담당자에게 전달합니다.

담당자 연결도 유연하게 설계했습니다. Slack 사용자 그룹, 개별 담당자, Opsgenie 스케줄 등 다양한 방식으로 호출할 수 있으며 사용자는 “문제 해결이 어려워요” 버튼을 눌러 언제든 즉시 연결할 수 있습니다.

이 구조로 자동 응답의 효율성과 담당자 검증의 정확성이 균형을 이루며 반복 업무를 줄이면서도 일관된 품질을 유지할 수 있게 되었습니다.

아래는 한 서포트 채널의 인입된 질문과 이에 대한 ‘물어보새’의 답변입니다. 담당자의 개입 없이도 문의가 자동으로 처리되는 것을 볼 수 있습니다.

그림 5. Support Channel Automation 기능 예시

넷째, 셀프 서비스로 손쉽게 확산한다

아무리 뛰어난 시스템이라도 설정이 복잡하고 접근성이 낮다면 널리 사용되기 어렵습니다.
이에 서포트 채널 담당자가 별도의 기술적 도움 없이도 쉽게 도입할 수 있도록 Slack 워크플로우 기반의 셀프 신청 시스템을 구축했습니다. 담당자가 간단한 신청서를 작성하여 제출 버튼을 누르면 자동으로 10분 이내에 기능이 활성화됩니다.

신청 정보도 단순화했습니다. 채널명, 워크플로우 이름, 담당자 정보, FAQ 문서 등 필수 항목 몇 가지만 입력하면 설정이 완료됩니다. 추가적으로 FAQ 문서가 없는 경우에도 기존 Slack 대화 데이터를 기반으로 즉시 연결할 수 있도록 설계했습니다.

사용자 경험 역시 세심하게 개선했습니다. 모든 답변에는 출처 정보와 관련 문서 링크를 함께 제공해 신뢰성을 높였으며 평균 1분 이내 응답으로 언제 어디서나 빠른 지원을 받을 수 있게 했습니다. 이 간결하고 직관적인 구조 덕분에 빠른 시간 안에 자동 응답 시스템은 자연스럽게 전사로 확산될 수 있었습니다.

그림 6. Support Channel Automation 동작 흐름

(4) 자동화를 넘어, 실제 행동으로

이전에는 같은 질문에 매번 비슷한 답변을 작성해야 했지만, 이제는 자주 묻는 질문이나 유사 사례가 있는 문의에 대해 ‘물어보새’가 자동으로 응답합니다. 담당자는 복잡하고 중요한 문제 해결에 집중할 수 있게 되었고 사용자는 언제든 즉각적인 도움을 받을 수 있게 되었습니다.

하지만 이제 구성원들의 기대는 단순한 응답을 넘어섰습니다. “24시간 답변받을 수 있어서 좋다”는 만족에서 “반복적인 응대를 넘어 상황에 따라 다른 해결책들을 제시해줬으면 좋겠다”는 요구로 발전했습니다. 이에 따라 ‘물어보새’는 Grafana나 사내 시스템 등 다양한 MCP 서버와 연결해 문제의 원인을 분석하고 실제 조치를 수행하는 테스트를 진행하고 있습니다.

이 테스트는 시스템 오류나 데이터 파이프라인 실패 등 일부 상황에서 문제를 진단하고 필요한 도구를 호출해 해결을 시도하는 문제 해결형 에이전트로의 확장을 의미합니다. 또한 이 과정에서 축적되는 ‘질문–조치–결과’ 데이터를 활용하면 비슷한 문제가 생겼을 때 더 빠르고 정확하게 대응할 수 있습니다.

‘물어보새’는 단순히 답변을 자동화하는 수준을 넘어 조직의 지식이 학습되고 순환되는 문제 해결 플랫폼으로 발전을 기대하고 있습니다.

‘Knowledge Discovery’와 ‘Support Channel Automation’을 거치며 우리는 하나의 분명한 사실을 배웠습니다. 중요한 것은 기술이 아니라 사용자의 문제를 해결하는 일이며, 기술은 문제 해결 과정에서 자연스럽게 발전한다는 점입니다.

이제 ‘물어보새’는 전사 구성원 4명 중 1명이 업무에 사용하는 지식 허브 서비스로 자리 잡았습니다. 그러나 구성원들은 이제 단순한 검색을 넘어, 자신의 상황에 맞는 정확한 해결 방안과 전략적 실행을 기대하고 있습니다.

이러한 변화에 대응하기 위해 ‘물어보새’는 새로운 로드맵을 중심으로 진화하고 있습니다.

4.1 모두가 함께 만들어가는 문제 해결 방법: Agent Ecosystem

지금까지의 ‘물어보새’는 BADA팀이 직접 데이터를 수집하고 연결하는 중앙화된 방식으로 운영되었습니다.

이제는 각 팀과 개인이 스스로의 문제를 해결할 수 있도록 분산형 지식 생태계로의 전환을 추진하고 있습니다.
구성원은 문제를 정의하고 셀프 서비스 기반의 ‘물어보새 에이전트 키트’를 활용해 맞춤형으로 문제를 해결할 수 있습니다.

조직 차원에서는 셀프 서비스를 활용해 간단한 설정만으로 각 팀의 도메인 지식을 ‘물어보새’와 연결할 수 있습니다. 예를 들어, 개발 팀은 배포 로그, 장애 이력, 내부 코드와 문서를, 디자인 팀은 디자인 가이드와 디자인 리소스를 연동해 활용할 수 있습니다.

개인 차원에서는 필요한 프롬프트와 도구를 조합해 자신만의 에이전트를 만들 수 있습니다. 예를 들어, 데이터 분석가는 데이터 추출 및 탐색 중심의 에이전트를, 데이터 엔지니어는 데이터 파이프라인 및 리소스 최적화 에이전트를, PM은 프로젝트 관리 중심의 에이전트를 만들 수 있습니다.

이 과정으로 ‘물어보새’는 중앙화된 시스템에서 분산형 생태계로 전환되며, 조직 전체가 함께 지식을 구축하고 확장하는 MCP 기반의 협업 네트워크로 진화하고 있습니다.

이처럼 팀과 개인이 ‘물어보새’ 위에서 각자의 전문성을 구현할수록 조직의 문제 해결 능력은 유기적으로 확장되고, 개인의 성장과 조직의 진화가 맞물린 선순환 구조가 만들어집니다.

4.2 데이터로 판단하고 함께 성장하는 방법: Analytics Assistant

데이터를 단순히 조회하는 것을 넘어, 데이터를 기반으로 판단하고 실행하는 단계로 발전할 계획입니다. 기존의 ‘물어보새’는 사용자가 데이터를 탐색·추출한 뒤 별도로 분석을 수행해야 했지만, 앞으로는 데이터 탐색 → 인사이트 도출 → 시각화 → 모델링까지 하나의 흐름으로 자동화된 분석 경험을 제공할 계획입니다.

특히 부서 간 데이터 해석과 보고 프로세스가 일원화되면서, 팀마다 다른 방식으로 진행되던 분석과 의사결정이 하나의 공통 언어와 워크플로우로 통합됩니다.

예를 들어, “새로운 마케팅 캠페인이 효과가 있을까?”라는 질문이 들어오면, 각 조직은 전문 영역에 따라 역할을 분담합니다.

사업 조직은 분석 대상과 주요 지표를
마케팅 조직은 핵심 가설과 주요 인사이트를
데이터 조직은 실험 설계와 모델 기반 패턴 분석을
플랫폼 조직은 자동화 파이프라인과 대시보드를 제공합니다.

‘물어보새’는 이 모든 정보를 하나의 분석 흐름으로 연결해, 가설 검증부터 분석 리포트 생성까지 자동으로 수행합니다. 사용자는 코드 작성이나 대시보드 구성 없이, 질문 한 번으로 부서 간 협업이 자동화된 데이터 의사결정 과정을 경험할 수 있습니다.

이 과정으로 ‘물어보새’는 단순한 분석 도구를 넘어, 데이터를 중심으로 조직의 사고방식과 협업 문화를 연결하는 ‘Analytics Assistant’로 발전하고자 합니다.

4.3 글로벌 협업을 향한 확장

‘물어보새’는 이제 우아한형제들을 넘어, Delivery Hero 글로벌 생태계로의 확장을 준비하고 있습니다.
현재 여러 글로벌 엔티티와 협력하며, 지식과 데이터를 연결하기 위한 논의를 지속하고 있으며 이를 바탕으로 조직 간 지식 순환과 에이전트 활용의 표준화를 모색하고 있습니다. 또한 오는 12월 미국 라스베가스에서 열리는 AWS re:Invent 2025(AWS가 주최하는 세계 최대 클라우드 기술 콘퍼런스)에서 ‘물어보새’의 개발 사례를 글로벌 무대에서 공유할 예정입니다.

‘물어보새’는 단일 서비스를 넘어, 각 조직이 자체 에이전트를 구축하고 운영할 수 있는 AaaS(Agent as a Service) 형태의 ‘글로벌 협업 플랫폼’으로 발전을 준비하고 있습니다.

‘물어보새’의 여정은 언제나 사용자의 문제에서 출발해 그 문제를 함께 해결하며 성장해 온 이야기입니다. BADA팀이 추구하는 지향점은 단순합니다.

사용자 중심의 AI 서비스를 활용해 함께 배우고 성장하며, 더 큰 문제를 해결하는 조직 문화를 만들어가는 것입니다.

‘물어보새’의 다음 여정도 계속 이어집니다.

앞으로도 많은 관심과 응원 부탁드립니다.