테크블로그를 구경하다가 네이버플레이스의 Backoffice AI Agent 구축기 게시글을 읽어보앗다.

Backoffice 전용 RAG+MCP 기반의 의미검색 에이전트를 설계하고 구축했다고 한다....

• RAG(Retrieval-Augmented Generation): LLM이 답변 생성 전 외부 DB에서 관련 정보를 검색하여 활용하는 기술
• MCP(Model Context Protocol): AI 모델과 외부 데이터/도구를 연결하는 개방형 표준 프로토콜

아주아주아주 구체적으로 정리되어있어서 좀 하나하나 이해하면서 읽어봄
근데 너무 길어서 끝까지 못읽겠다
일단 그냥 올리고 나중에 수정하기

---

Backoffice AI Agent 구축기

배경

• 업무 중 문서 찾는 시간이 너무 오래 걸림.
• 기존 문서 검색 기능은 단어 일치(Lexical Search) 위주라 성능이 별로임. 특히 약어/사내용어/긴 회의록 문맥에서 성능 구림.
• 기술 문서, 히스토리가 각 서비스 단위로 따로따로 축적됨 -> 각 서비스마다 지식/맥락 공유가 어려움

목표

1. 팀 내 기술, 서비스 간 지식 격차 해소 및 정보 접근성 향상
2. OJT(On-the-Job Training) 및 협업 과정에서의 업무 효율 극대화
   * ojt = 인수인계 or 신입 교육 정도로 이해하면 될 듯

이걸 구현하려면

1. 의미 검색(Semantic Search) 기반의 RAG 구조로 문서의 의미를 이해해 관련 정보를 찾는다.
2. MCP를 통해 질문 의도를 해석해서 최적의 답변을 생성한다.

이렇게 하면 된다고 한다....

---

설계 과정

1. 데이터 -> 지속적으로 확장 가능한 구조로 만들겠다

• 수집 대상 데이터
  • github oss: 그냥 깃허브 저장소
  • Attlasian Wikis: 아틀라시안은 Jira(개발자용 이슈 트래커)를 갖고 있는 회사인 것 같고....Attlasian Confluence라는 웹 기반 협업 및 문서화 위키 툴을 제공하는 것 같다......그냥 문서 저장소 ㅇㅇ
  • Milvus: 벡터데이터베이스. 비정형 데이터에서 변환된 임베딩 벡터를 저장하고 인덱싱한 DB이다....
    * 유사품: PostgreSQL의 pgvector 익스텐션
  • Kserve: 만들어진 ML/DL 모델을 실제로 서비스하기 위해 API를 쉽게 만들 수 있도록 도와주는 툴.
• 각 데이터들은 서로 다른 형식/주기로 갱신됨
  $\rightarrow$ 수집-정제-임베딩-적재 과정을 자동화하고 증분 처리(변경된 부분만 처리)하여 최신성 유지
• 향후 새로운 문서 플랫폼이 추가되어도 모듈 단위로 확정할 수 있도록 설계
• 팀 내 기존 인프라 스택(Opensearch, Milvus)을 활용하여 운영 효율 확보

2. 검색 -> 의미 기반 검색 RAG를 최적화하겠다

• "고품질 검색"을 정의: 측정 가능한 평가 체계 구축, 실험을 통해 최적화가 가능하도록 설계
  • BEIR-SCIFACT 벤치마크: 과학적 팩트체크를 위한 벤치마크셋
  • LLM-as-a-Judge 평가 체계: 생성된 데이터셋과 실제 데이터셋을 비교/평가, 모델의 응답 품질 지속적으로 개선하는 평가 방식
• 하이브리드 검색 전략 활용
  다양한 검색 방식(lexical이든 sementic이든...)을 섞어서 쓰겠다는 뜻
• Pre-Retrieval / Retrieval / Post-Retrieval 단계 별 최적화 기법 적용
  $\rightarrow$ 답변 생성에 필요한 충분한 문맥 확보
• 검색 품질, 응답 속도, 운영 비용 간의 균형을 고려하여 최적화
  • 임베딩 모델을 Dense하게 구성할지 Sparse하게 구성할지
  • 어떻게 청킹을 할 지
  • 인덱스를 어떻게 구성할 지
  • 실험을 20가지나 돌렸대

3. 인터페이스 -> MCP 기반 Agentic RAG를 설계하겟다

• 모든 검색 및 문서 조회를 MCP 툴로 통일
  $\rightarrow$ Cursor-Dify 등 어디서든 표준화된 인터페이스로 호출
  • cursor: AI기반 IDE (VScode를 포크해서 만듬)
  • dify: 노코드 기반 생성형 AI 개발 플랫폼...? 코드 한 줄도 안 쓰고 서비스 구현/배포 가능.
• 전 구간 로깅
  • 질의 / 도구 호출 / 응답시간 / 근거 등을 추적
  • 품질을 지속적으로 개선할 수 있는 구조 마련
• 프롬프트 기반 행동 규칙(Resource Prompt) 정의
  • LLM이 질의를 해석하고, 부족하거나 불명확한 정보를 스스로 정제한 뒤 필요한 정보가 확보될 때까지 검색 모듈을 반복 호출하도록 규칙을 정의함
    => 검색 과정 전체를 Agentic 구조로 설계

4. 평가 -> 사용자 신뢰 확보를 위한 시스템

• 응답의 신뢰성을 보장하기 위해 응답에서 근거 문서 링크를 함께 제공함.
• 신규입사자 온보딩(OJT) 시나리오 기반 질의를 만들어서, 단어 일치(Lexical Search) 기반 MCP(기존)와 Backoffice AI MCP(새로 만든거) 간 블라인드 A/B 테스트 수행
  -> 응답의 정확도/만족도 정성적으로 평가
• 응답 속도 / 토큰 사용량 / 툴 호출 수 등 효율성, 자원 활용 지표를 정량적으로 측정

시스템 아키텍처

OpenSearch, Milvus, Data Loader, MCP Server를 중심으로 하는 3계층 컴포넌트로 구축

DB

• OpenSearch(Raw Data Store)
  • 깃허브나 위키 등에서 수집된 원본데이터의 1차 저장소.
  • 주로 원시 텍스트, 메타데이터 저장을 담당
  • 키-값 스토어로 활용된다
• Milvus(Vector Store)
  • 청킹, 임베딩이 완료된 문서를 저장하는 벡터 데이터베이스
  • Dense 벡터, BM25 기반 Sparse 벡터까지 모두 저장하여 하이브리드 검색의 단일 통합 소스 역할 수행
    • 원핫인코딩같이 0이 많은 임베딩은 sparse...단어 집합 크기와 관계없이 사용자가 설정한 차원으로 임베딩을 수행하는 경우는 주로 dense...
• Opensearch DB(MCP log Store)
  • 운영 데이터(MCP 서버 호출, 검색 결과, LLM 응답 등)를 저장.
  • 시스템 성능 평가 / 모니터링을 위한 로그 인프라로 활용됨

Core Components

• Data Loader
  • 다양한 소스의 데이터를 수집-정규화-청킹-임베딩-적재하는 과정을 자동화
  • FastAPI 기반 증분 수집, 재임베딩 기능
• Milvus Loader
  • opensearch의 원지 데이터를 청킹하고 임베딩을 생성하는 전처리 허브.
  • 임베딩 실험 유연성을 위해 data loader와 분리된 독립 모듈로 개발했다고 한다...
• MCP Server
  • search_smart와 같은 툴을 통해 milvus hybrid 검색 기능을 호출하고, 검색 결과를 MCP Clients의 LLM Agent에 제공한다

---

데이터 파이프라인

확장 가능한 구조로 만드는걸 중점적으로 구성했다고 한다

결론부터 말하면

• 데이터 소스 5개
• 문서 11,173건

Data Sources

내부 협업 문서와 외부 기술 문서를 함께 다루었다~~~

1. Github issues

• 그냥 깃허브 커밋한거..
  이지만 프로젝트 진행 상황 / 실험 로그 / 문제 해결 과정이 모두 포함된 실질적인 이슈 데이터겟죠 아무래도
• GitHub API를 통해 본문과 댓글을 함께 수집 -> 문맥 손실 최소화

2. Confluence Wiki

• 위에서 말했던 Attlasian Confluence라는 웹 기반 협업 및 문서화 위키 툴.....어쩌구저쩌구이다.
• 부서별 플젝, 기술 리서치, 회의록 등 장기적 문맥이 담겨있는 문서들이 저장되어 있음.
• CQL(Confluence Query Language)를 이용해 작성자, 수정일 등 메타데이터까지 확보했다 !!

3. 기술 공식 문서

• 팀이 사용하는 기술 스택의 공식 문서
• 사이트맵 기반 크롤링 방식을 도입했다 $\rightarrow$ 불필요한 페이지 배제
  • 일반 크롤링은 그냥 메인페이지에서부터 클릭할 수 있는 링크를 타고 계속 안으로 들어가는데........사이트맵 기반 크롤링은 sitemap.xml파일을 먼저 읽고 어떤 페이지를 방문해야 할지 즉시 파악한다고 제미나이가 말하는데 맞는지는 잘 몰루겠다.

Data Loader

1. 데이터 수집

API, 크롤러로 다양한 문서 플랫폼의 원문 문서 수집

2. 데이터 구조화

수집된 HTML 문서를 markdownify와 같은 도구 등으로 markdown 포맷의 문서로 변환

• markdownify: beautifulsoup 모듈 안에 있는 HTML을 마크다운으로 변환해주는 라이브러리

3. 임베딩, 청킹

텍스트 단위 분할(청킹) 및 벡터화
이건 왜 구체적으로 안알려주시지...뭘로 임베딩햇을까

4. 저장 및 마이그레이션

원시 데이터는 Opensearch, 벡터화된 데이터는 Milvus로 이중 적재
$\rightarrow$ 부하 분산, 검색 최적화

Crawl4AI - 텍스트 밀도 기반 크롤링 기술

그냥 beautifulsoup으로 크롤링하기에는 각 웹사이트의 구조가 달라 아주 귀찮다고 함
그래서 Crawl4AI로 텍스트 밀도 기반 컨텐츠 추출을 적용했다고 한다....
* 텍스트 밀도 기반 컨텐츠 추출이란? : HTML 태그와 텍스트의 비율을 계산해서 광고나 사이드바가 배제된 의미 있는 본문만 자동으로 추출해줌.

API Design - 지속 가능한 증분 업데이트 구조

일회용이 아닌, 지속적으로 데이터를 뽑아낼 수 있도록 Data Loader를 설계했다고 한다.

• 엔드포인트 분리 : 소스별로 전체 문서 갱신 또는 특정 기간 이후 문서만 갱신하는 엔드포인트 제공
• 변경 감지: 소스별 마지막 업데이트 시간을 확인해서 그 이후에 변경된 데이터만 가져와 최신 상태 유지

이런 식으루다가...
이건 2025년 9월 24일 이후 변경된 문서만 감지해서 증분 업데이트를 수행하는 API 동작 예시임

---

검색 파이프라인

"좋은 검색이란 무엇인가?"

여기서는 이 질문에 대해, RAG 구조에서는 '정확한 검색'보다 LLM이 답변을 만들 수 있을 만큼 충분한 문맥을 주는 것이 좋은 검색이라고 정의함.
$\rightarrow$ 검색 품질 평가 체계를 먼저 구축

BEIR 기반 정량 평가

LLM-as-a-Judge 기반 의미 평가

최적의 검색 구조 만들기

하이브리드 검색 설계

검색 후 최적화

인터페이스

성능 평가

---

참고해서 나중에 뚝딱뚝딱 해보기:
허깅페이스 MCP 코스
MCP실습 플젝