안녕하세요, 라포랩스 Data Engineer 이병우입니다.
오늘은 저희 팀이 점심시간을 활용해 만든 특별한 프로젝트, “라포위키”의 개발 여정을 공유하려 합니다. AI를 전혀 몰랐던 4명의 개발자가 어떻게 챗봇을 만들었는지, 그 좌충우돌 스토리를 함께 살펴보시죠.
아이디어는 사내 해커톤에서부터
지난 1월, 라포랩스 AI 해커톤에서 두 가지 아이디어가 나왔습니다. 하나는 노션 기반으로 무엇이든 답변해 주는 챗봇, 또 하나는 데이터 질의를 도와주는 SQL 챗봇이었습니다. 두 아이디어 모두 PoC까지는 만들었지만, 실제 사내 서비스로 사용하기엔 아쉬운 점이 많았습니다. 그래서 해커톤 이후, 아이디어를 실현하기 위해 다시 뭉쳤습니다.
그렇게 AI를 잘 모르는 서버 엔지니어 2명과 데이터 엔지니어 2명이 함께 모여, 라포랩스의 위키백과라는 뜻을 담아 "라포위키"라는 이름을 지었습니다. 우리는 매일 점심시간을 활용해 이 프로젝트를 시작하게 되었습니다.
흩어진 사내 지식을 하나로, 라포위키
가장 먼저 해결하고 싶었던 과제는 사내 노션(Notion)에 축적된 방대한 도메인 지식을 AI가 학습하게 하는 것이었습니다. 회사의 중요한 정보와 업무 노하우가 담긴 노션 문서를 기반으로 답변하는 챗봇이 있다면, 신규 입사자는 물론 기존 구성원들의 업무 효율도 크게 향상될 거라 생각했습니다. 여기에 슬랙 데이터 수집과 데이터 질의 기능을 더한, 똑똑한 AI를 만드는 것을 최종 목표로 삼았습니다.
최소 리소스로 최대 효율을 - 라포위키 아키텍처
직장인에게 점심시간은 너무도 짧고 소중합니다. 그래서 시간을 최대한 효율적으로 활용하기 위해, 복잡한 아키텍처보다는 “확실히 돌아가는” 구조에 집중했습니다. 그래서 선택한 방식이 RAG(Retrieval Augmented Generation) 패턴이었습니다. 쉽게 말하면, AI가 관련 문서를 먼저 검색한 뒤, 해당 내용을 바탕으로 답변하는 방식입니다.
왜 RAG 패턴을 선택했을까?
프로젝트 진행 당시 문서 검색 기반 챗봇의 가장 검증된 아키텍처가 RAG라고 판단했습니다. 특히 노션의 방대한 문서를 효율적으로 검색하고 활용하는 데 가장 적합했죠. AI에게 모든 문서를 전달하는 대신, 관련 문서만 선별해 주는 것이 비용과 성능 측면에서 모두 유리하다고 판단했습니다.
저희는 RAG를 구현하기 위해 다음과 같은 기술 스택을 활용했습니다:
Flask : 챗봇의 백엔드 API를 구축하는 데 사용했습니다. 백엔드와 데이터 엔지니어 모두가 빠르게 프로토타입을 만들고 운영해볼 수 있는 가벼운 프레임워크가 필요했습니다. Python 기반의 Flask는 학습 곡선이 낮고, 4명 모두 쉽게 이해하고 개발할 수 있다고 판단했습니다. 때문에 일단 빠르게 제작하고, 이후 더 나은 기술로 마이그레이션 하는 쪽의 실용적 접근을 선택했습니다.
PGVector (Vector Store) : 노션 문서들을 임베딩하여 저장하고, 사용자 질의와 유사한 문서를 빠르게 찾아내는 역할을 했습니다. 초기에는 벡터 검색을 위해 AWS Bedrock, ElasticSearch, Chroma, FAISS 등 여러 Vector Database를 검토했습니다. 그 중 빠르게 생성할 수 있는 PGVector를 선택했습니다. 새로운 기술의 성능을 모르는 상황에서 일단 확실한 것부터 시작하는, 보수적이면서도 실용적인 접근이었어요. 만약 프로젝트가 성공한다면, 그때 더 최적화된 벡터 DB로 마이그레이션하는 것을 고려하기로 했습니다.
LLM (Gemini (gemini-2.5-flash)) : LLM과의 연동을 통해 질문에 대한 답변을 생성했습니다.
노션 데이터는 Notion API를 활용하여 주기적으로 생성되거나 수정되는 페이지들을 받아와 PostgreSQL에 업데이트하는 방식으로 관리했습니다. 이렇게 단순하지만 효율적인 아키텍처 덕분에 빠른 개발이 가능했습니다.
다만, 개발 과정이 마냥 순탄치만은 않았습니다. 특히 다음 두 가지 단계에서 많은 시행착오를 겪었습니다.
노션 데이터 적재 & 임베딩 전략 세우기
노션에 있는 방대한 데이터를 챗봇이 잘 이해하고 답변할 수 있도록 적재하는 것이 큰 숙제였습니다. 단순히 내용을 긁어오는 것을 넘어, 어떻게 데이터를 쪼개고 임베딩*할지를 고민해야 했습니다.
* 임베딩 : 텍스트를 벡터로 변환
거미줄 같은 노션의 계층 구조 파헤치기
Notion의 모든 정보는 단순한 텍스트가 아닌, 서로 부모-자식 관계를 맺는 '블록(block)' 단위로 저장됩니다. 이 거미줄 같은 계층 구조 때문에 페이지의 완전한 문맥을 파악하는 것이 어려웠습니다. 예를 들어, '1분기 결산'이라는 페이지 제목만 보면 의미가 모호하지만, '프로젝트 A > 재무 > 1분기 결산'이라는 상위 경로 안에 있을 때 비로소 명확한 의미를 갖습니다. 기존 라이브러리들은 이런 경로 정보나 메타데이터를 가져오지 못하는 한계가 있었습니다. 결국 저희는 흩어진 정보의 문맥을 잇기 위해, 각 페이지의 부모를 거슬러 올라가며 전체 경로를 완성하는 파싱 로직과 메타데이터 수집을 ChatGPT의 도움을 받아 쉽고 빠르게 개발할 수 있었습니다.
최적의 문서 임베딩 모델 찾기
문서 청킹 전략 실험
초기에는 문서 전체를 임베딩했지만, 답변의 정확도가 떨어졌습니다.
문서의 특정 섹션이나 문단 단위로 쪼개 임베딩하는 방식으로 변경하며 정확도를 높였습니다.
청크 크기를 여러 토큰으로 쪼개며 실험해보며 최적의 크기를 찾았습니다.
실제 질문 예시와 임베딩 모델 실험 과정
최초에는 단순히 문서 전체를 임베딩해서 최적의 청크 크기를 찾았지만, 실제로 아래와 같은 질문에는 원하는 문서를 잘 찾지 못하는 경우가 많았습니다.
"셀러 API 연동 가이드 문서 찾아줘 (seller API 연동 가이드 문서 찾아줘)"
"스케일 스쿼드 멤버 알려줘 (scale squad 멤버 알려줘)" 특히 한글과 영어가 혼용된 질문(예: "셀러", "seller", "퀸잇", "queenit")에 대해 답변의 정확도가 떨어지는 문제가 있었습니다. 이 문제를 해결하기 위해 아래와 같은 다양한 임베딩 모델을 실험했습니다.
text-embedding-3-small
text-embedding-3-large
text-embedding-3-large
text-embedding-ada-002
gemini-exp-03-07
이 중 gemini-exp-03-07은 실험 당시 결과가 가장 좋았지만, 응답 속도가 너무 느려 실제 서비스에는 적용하지 못했습니다. 여러 모델을 비교한 결과, text-embedding-ada-002가 한글과 영어가 혼용된 질문에도 가장 범용적으로 답변을 잘 찾는다는 점을 검증했고, 최종적으로 이 모델을 임베딩에 채택해 사용하고 있습니다.
임베딩 모델을 직접 파인튜닝(fine-tuning)하는 방법도 고려할 수 있었지만, 당시 LLM 및 임베딩 모델의 발전 속도가 매우 빨랐기 때문에 특정 모델에 종속되는 것이 오히려 한계로 작용할 수 있다고 판단했습니다. 또한, 파인튜닝을 어떻게 하면 적절하게 수행할 수 있을지에 대한 경험과 확신이 부족했기 때문에, 파인튜닝보다는 최신의, 더 우수한 범용 임베딩 모델을 지속적으로 도입할 수 있도록 유연성을 유지하는 전략을 선택했습니다.
문서의 우선순위 올리기
사용자의 질문에 가장 적합한 답변을 주기 위해서는 단순히 유사한 문서를 찾는 것을 넘어, 문서의 중요도나 관련성을 높이는 작업이 필요했습니다. 이를 위해 다음과 같은 시도를 했습니다.
검색 정확도 향상을 위한 쿼리 확장: 내부 구성원이 사용하는 일상적인 언어와 회사 내부에서 사용하는 기술/약어 간의 차이는 검색 품질을 저하하는 주요 원인이었습니다. 예를 들어, LLM은 '상쿠'가 '상품쿠폰'의 줄임말인지, '레이크'가 내부 데이터 시스템인 'damoa-lake'를 의미하는지 알 수 없습니다. 이러한 문제를 해결하기 위해, 저희는 '쿼리 확장(Query Expansion)' 전략을 도입했습니다. 사용자의 원본 질문을 시스템이 이해할 수 있는 여러 동의어 및 내부 용어로 변환하여 검색 범위를 넓히는 방식입니다. 이를 위해 아래와 같이 서비스 및 사내 용어를 정리한 '도메인 용어집'을 구축했습니다.
사용자 언어/약어
내부 공식 용어 / 동의어
상쿠
상품 쿠폰
장쿠
장바구니 쿠폰
레이크, lake
data-lake
이렇게 구축한 용어집은 검색 파이프라인의 가장 첫 단계에서 작동합니다. 예를 들어, 사용자가 "상쿠 정책 관련 문서 찾아줘" 라고 질문하면, 시스템은 이 질문을 임베딩하기 전에 다음과 같이 자동으로 변환하고 확장합니다.
변환 전: "상쿠 정책관련 문서 찾아줘"
변환 후: "상쿠(상품쿠폰) 정책 관련 문서 찾아줘"
이렇게 확장된 쿼리로 Vector Search를 수행하면 '상품쿠폰'이라는 키워드가 포함된 기술 문서를 찾게됩니다.
문서 메타데이터 추가: 검색의 정확도를 높이기 위해 각 노션 문서의 메타데이터('작성자', '최종 수정일' 등)를 원문과 합해 임베딩하는 전략을 사용했습니다. 단순한 정보 나열을 넘어, 이 메타데이터를 문서의 서문(preamble)처럼 가공하여 텍스트의 일부로 취급하고 함께 임베딩하는 방식을 사용했습니다.이 과정을 통해 Vector Search는 내용의 의미적 유사성뿐만 아니라, 문서가 가진 문맥(Context)까지 종합적으로 이해하게 됩니다. 실제로 벡터DB에 저장하기 위해, 원본 문서 내용은 아래와 같이 가공됩니다.
[문서 주요 정보] 제목: 홈 혜택찾기 배너 실험 최종 수정일: 2025-04-25 실험 시작일 : 2025-04-01 실험 종료일 : 2025-05-01 실험 오너십: XX Squad 분석 담당: byeongwoo @rapportlabs.kr [문서 원본 내용] 이번 실험은 사용자가 홈에서 혜택탭 진입을 유도하기 위한 실험입니다... (이하 생략)이렇게 구성하면 "홈 혜택찾기 실험 종료일이 언제야?" 혹은 "최근에 완료된 실험 결과 알려줘"와 같은 질문에 대해, AI가 '최신', '최근'은
최종 수정일정보와, '완료된'은실험 시작, 종료 정보와 자연스럽게 연결해 가장 적절한 문서를 우선적으로 찾아낼 수 있습니다.문서의 최신 데이터를 제공하기: 기존에는 문서가 잘 관리되지 않아 Outdate된 정보가 혼재되어, 라포위키가 최신 맥락을 놓치는 일들이 간헐적으로 발생했습니다. 이를 해결하기 위해, Vector search 결과물을 LLM이 한번 더 질의하여 문서의 메타데이터(수정일, 작성자, 문서 맥락)를 기준으로 최신 정보를 우선 정렬하도록 개선했습니다.
위와 같은 여러 우여곡절 끝에 라포위키가 배포되었고 다음과 같은 기능을 제공하며 저희 라포랩스 팀원들의 업무 효율을 높이고 있습니다.
슬랙/노션 데이터 기반 답변: 슬랙에서 라포위키를 호출해서 질문하면 노션과 슬랙의 최신 데이터를 바탕으로 답변합니다.
BigQuery 데이터 조회: 슬랙 메시지에
bigquery키워드가 포함되면, 라포위키가 직접 BigQuery에 쿼리를 실행해 데이터를 제공합니다.슬랙 대화 아카이빙: 중요한 슬랙 대화를 한 번의 액션으로 노션에 아카이빙하여, 팀의 지식 자산으로 축적합니다.
키워드/채널 기반 맞춤 답변: 특정 채널이나 키워드에 따라, 관련 FAQ나 우선순위 문서를 우선적으로 답변합니다.
라포위키의 반응과 효과
라포위키는 단순한 지식 저장소를 넘어, 팀원들의 실질적인 업무 효율 개선 도구로 자리잡고 있습니다. 실제로 아래와 같은 긍정적인 피드백이 이어지고 있습니다:
특히 슬랙 검색이나 누가 알지 몰라서 묻기 애매했던 질문들도 “라포위키가 알려줬어요!”라는 말로 대체되는 모습을 종종 볼 수 있습니다.
라포위키를 통해 느낀점
라포위키는 실제 구성원들로부터 긍정적인 반응을 얻고 있습니다. 검색, 질의응답, 슬랙 소통 등 다양한 영역에서 실질적인 업무 효율을 높여주고 있습니다. 라포위키 배포 후, 사내 문화가 조금씩 긍정적으로 변화하고 있음을 체감하고 있습니다.
문서화 문화의 확산
구성원들이 "내가 남긴 기록이 라포위키를 통해 더 많은 동료에게 도움이 된다"는 경험을 하면서 자발적으로 문서화에 힘을 쓰는 문화가 확산되고 있습니다. 이로 인해 라포위키의 답변 품질도 자연스럽게 더 좋아지고 있습니다.
사내 질의응답의 자동화
𝘷 Before: "이거 누구한테 물어봐야 하지?"
𝘷 After: "먼저 라포위키한테 물어보자!"
예전에는 질문이 있으면 직접 사람이 답변해야 했지만, 이제는 문서화된 정보를 라포위키가 대신 답변하기에 리소스가 절약되고, 더 중요한 일에 집중할 수 있게 되었습니다.
기록의 선순환 구조
더 많은/더 좋은 기록이 쌓이면 → 라포위키의 답변 품질이 향상되고 답변 품질이 높아지면 사용량과 업무 효율이 증가하며 → 사용량이 늘수록 기록의 가치가 높아지고 다시 더 많은 기록이 쌓이는 선순환 구조를 만들 수 있었습니다.
정리하자면, 라포위키는 단순한 챗봇이 아니라 "기록 → 답변 품질 향상 → 사용량 증가 → 기록의 가치 상승 → 더 많은 기록"이라는 선순환 구조를 만들어내며, 회사 전체의 지식 관리와 협업 문화를 한 단계 끌어올리고 있습니다.
라포위키의 남은 과제들
앞으로는 라포위키를 MCP(Model Context Protocol) 기반으로 확장하여, 사내의 다양한 정보를 더 유연하게 연결하고 전파할 수 있는 구조로 발전시킬 계획입니다. 나아가, 라포위키를 단순한 위키 시스템이 아닌 Agent 형태로 전환하여, Slack이나 Notion, BigQuery 등 다양한 도구들과 연동해 정보를 제공하는 것을 목표로 하고 있습니다. 이를 통해 구성원들이 필요한 정보를 보다 능동적으로 탐색하고, 실시간으로 활용할 수 있는 환경을 구축하고자 합니다.
마치며
저희 4명은 "동료들이 원하는 정보를 더 쉽고 빠르게 찾게 하자"는 순수한 마음 하나로 프로젝트를 시작했습니다. 제한된 시간을 활용한 이 작은 프로젝트가 회사의 문서화 문화를 바꾸고, 소통의 효율을 높이는 데 기여하고 있다는 점에서 큰 보람을 느낍니다.
라포랩스는 이렇게 구성원들이 자발적으로 문제를 찾고, 기술로 해결하며 함께 성장하는 문화를 가진 곳입니다. 저희와 함께 뜨겁게 제품을 만들고 문화를 가꾸어 나갈 동료를 기다립니다.
함께 라포위키를 만든 사람들
이 모든 여정은 저 혼자서는 불가능했습니다. 수많은 아이디어와 부딪히며 점심시간을 기꺼이 함께해 준 저의 동료이자 라포위키의 공동 개발자인 지수환, 박서준, 김범환님께 이 글을 빌어 깊은 감사의 마음을 전합니다.
