✅ Introduction
2024년 오늘의집 AI 인턴 ‘오집사’가 런칭된 이후, 오늘의집에서는 사내 피드백을 반영해 다양한 업무 자동화에 활용할 수 있는 전사 지식 탐색 시스템 ‘ORI(오리)’를 개발했습니다. 이번 글에서는 오집사 개발 이후 받았던 피드백과, 그를 바탕으로 어떤 실험과 개선을 거쳐 지금의 ORI에 이르렀는지 그 여정을 소개하고자 합니다.
참고 글 : 오늘의집 AI 인턴 ‘오집사’ 개발 여정
오늘의집 내부에서는 매일 다양한 채널을 통해 수많은 질문과 확인 요청이 발생합니다. ▲어떤 절차로 진행해야 하는지 ▲누가 승인 권한을 가지고 있는지 ▲비슷한 사례가 예전에 어떻게 처리되었는지 등을 묻는 메시지가 반복적으로 올라오고, 각 담당자가 매번 다시 설명하는 구조가 고착화되어 있었습니다. 여기서 문제는 ‘답이 없다’가 아니라, ‘답이 흩어져 있다’는 점이었습니다. 실무적인 대화와 실제 처리 이력은 Slack에, 공식 가이드와 정책은 Notion에, 그리고 팀별 합의나 일시적 예외는 회의 메모에만 존재하는 경우가 많았습니다. 이 글에서 소개할 ORI(Omni Resource Integrator)는 바로 이 지점에서 출발했습니다. ORI의 목표는 ‘사람에게 물어보지 않아도 회사 내부에 이미 존재하는 맥락과 근거를 스스로 찾아 연결해 주는 전사 지식 탐색 시스템’을 만드는 것이었습니다.
이 프로젝트는 단순히 챗봇 답변을 조금 더 똑똑하게 만드는 수준을 목표로 하지 않았습니다. 더 중요한 목적은 ‘사내 의사결정의 맥락을 검색 가능하게 만드는 것’이었습니다. 예를 들어 장비 구매 요청, 권한 접근 요청, 특정 비용 처리 방식 같은 질문들은 보안팀, 운영 지원 조직, 회계·정산 조직 등 서로 다른 팀에서 반복적으로 받는 유형입니다. 이런 질문에는 단순히 매뉴얼만 필요한 것이 아니라 “이 사례는 지난달에 어떻게 처리되었는지”, “누가 최종 승인자였는지”, “예외가 허용된 적이 있는지” 같은 실제 맥락이 함께 따라붙습니다. ORI는 이 맥락을 Slack과 Notion 등 사내 지식 소스에서 자동으로 수집·연결해 각 조직이 이미 갖고 있는 경험과 기준을 다른 사람도 재사용할 수 있도록 하는 전사 지식 인프라를 지향합니다. 다시 말해, 특정 팀만 알고 있던 운영 지식을 회사 전체가 필요할 때 찾아볼 수 있도록 하는 구조를 만드는 것이 목표였습니다.
이번 글에서는 ORI를 어떤 방식으로 설계하고 운영하게 되었는지 전체 흐름에 따라 정리합니다. 먼저, 반복 질문이 줄어들지 않았던 이유와 “검색하면 안 나온다”는 불만이 왜 계속 누적되었는지를 문제 정의 관점에서 살펴봅니다. 이어서 Slack과 Notion을 중심으로 사내 지식을 어떻게 수집하고, 어떤 형태로 정규화하고, 어떻게 검색 가능한 형태로 만들었는지 RAG 기반 아키텍처와 기술적 선택을 설명합니다. 그다음 ORI를 기존 사내 챗봇(오집사)과 각 조직 Q&A 채널에서 어떻게 연결했는지 공유합니다. 마지막으로 운영 관제와 평가 체계, 그리고 결과적으로 어느 정도의 응답 속도와 리소스 절감 효과를 확인했는지를 다루고 앞으로의 확장 방향까지 소개하려 합니다.
문제 정의 : 사내 Q&A의 반복과 정보 접근의 비효율
오늘의집 내부에는 운영 지원, 정보보안, 인프라, 정산 등 주제가 다른 전사 Q&A 채널들이 존재합니다. 이 채널들에는 장비 구매 요청, 접근 권한 요청, 비용 지출 처리 방식 확인, 계정 정책 문의 등 비슷한 유형의 질문이 반복적으로 올라옵니다. 형태만 조금씩 다를 뿐 “이건 어떻게 처리되나요?”, “누구에게 요청해야 하나요?”, “지난번에는 이렇게 했던 것 같은데 이번에도 가능한가요?” 같은 질문이 여러 사람에 의해, 여러 날에 걸쳐 다시 등장하는 상황이 일상적으로 벌어지고 있었습니다. 답변하는 쪽에서는 이미 한 번 설명했던 내용을 다시 정리해 붙여 넣거나, 예전에 있었던 유사 이슈의 링크를 찾아와 공유하는 방식으로 대응하고 있었으며, 이 과정은 하루 수 시간 단위로 누적되는 경우도 적지 않았습니다. 한마디로, ‘아는 사람이 계속 직접 답해줘야만 굴러가는 구조’가 기본 상태였습니다.
이 문제의 원인은 정보의 위치가 제각각이라는 점이었습니다. 어떤 요청이 승인 가능한지에 대한 공식 기준은 Notion에 문서화되어 있지만, 실제로 비슷한 요청이 과거에 어떤 조건으로 허용되었는지는 Slack 스레드에만 남아 있는 경우가 많았습니다. 반대로, Notion에는 절차가 적혀 있지 않은데 Slack 대화에는 “이 경우에는 예외로 처리해도 된다”는 사실상의 합의가 남아 있는 경우도 있었습니다. 심지어 중요한 결정이 공개 채널이 아닌 개인 DM이나 소규모 스레드에서 내려진 뒤, 그 맥락이 이후에 공유되지 않는 일도 있었습니다. 회사 입장에서는 분명히 ‘답’이 존재하지만, 그 답이 여러 소스에 나뉘어 저장되고 서로 연결되지 않아 한 번에 검색해서 맥락까지 따라가기 어렵다는 것이 반복 문의의 구조적 원인이었습니다.
물론 이전에도 이 문제를 줄이려는 시도들은 있었습니다. 대표적으로 FAQ 문서를 만들어두고 공통 질문에 대한 정답을 정리하거나, 사내 챗봇(오집사)을 통해 자주 등장하는 질문을 요약해서 답하는 방식이 시도되었습니다.
하지만 이런 방식은 세 가지 한계를 가졌습니다. 첫째, FAQ는 시간이 지나면 바로 낡아졌고, 실제 운영 맥락(“이 경우는 예외로 처리 가능하다”)까지 반영하지 못했습니다. 둘째, 수동 검색은 결국 특정 사람의 기억력과 판단력에 의존하는 방식이기 때문에, 담당자가 자리를 비우면 지식 자체가 멈췄습니다. 셋째, 당시의 오집사는 회사 내부 컨텍스트를 충분히 인식하지 못한 상태에서 공개된 일부 자료만을 근거로 답을 생성했기 때문에, ‘그럴듯하지만 실제로는 맞지 않는 답’을 주는 경우가 반복적으로 발생했습니다.
요약하면, 기존 방식은 문서를 보여줄 수는 있었지만 실제로 회사 내부에서 어떤 식으로 결정하고 처리하는지가 담긴 맥락까지는 전달하지 못했습니다. 결국 우리가 정의한 목표는 단순했습니다. ‘한 번 질문하면, 회사 안에서 이미 존재하는 모든 맥락을 한 번에 가져오자.’ 사용자가 Slack에서 질문을 하면 관련된 결정 사례, 최근 처리 이력, 공식 정책, 담당 범위, 후속 액션까지 연결해서 즉시 보여주는 것을 목표로 삼았습니다.
여기에서 중요한 기준은 세 가지였습니다. 첫째, 속도입니다. 대부분의 담당자는 ‘1분 이내 응답’을 기대하고 있었고, 느린 답변은 사실상 무의미하다는 의견이 명확했습니다. 둘째, 정확도입니다. 특히 보안이나 비용 처리처럼 민감한 영역에서는 잘못된 안내가 그대로 사고로 이어질 수 있기 때문에, 과거 실제 대응 기록과 공식 정책을 동시에 근거로 사용하도록 설계해야 했습니다. 셋째, 확장성입니다. 특정 팀만을 위한 전용 챗봇이 아니라, 여러 도메인에 걸쳐 재사용 가능한 공통 인프라여야 했습니다.
이후의 내용에서는 이 목표를 달성하기 위해 어떤 구조를 설계했는지, 그리고 이를 실제 서비스 환경에 어떻게 적용했는지를 설명합니다.
✅ 구현 단계로의 전환
이런 반복되는 Q&A와 정보 단절 문제를 해결하기 위해, AI에 관심 있는 개발자들이 자발적으로 모였습니다. 그리고 AI Working Group을 결성해 ‘모든 사내 지식을 한 번에 탐색할 수 있는 시스템’을 만드는 프로젝트를 시작했습니다. 목표는 단순히 문서를 더 잘 검색하는 것이 아니라 실제로 회사 내 의사결정이 이루어지는 맥락 전체를 복원하는 것이었습니다. 누가 어떤 근거로 판단했는지, 그 결정이 어떤 문서나 대화에서 비롯되었는지를 하나의 질의로 연결할 수 있다면 사람의 경험이 아닌 시스템이 지식을 전달할 수 있게 됩니다. 다시 말해, 이번 프로젝트의 출발점은 ‘검색을 위한 검색’이 아니라, ‘맥락을 재구성하는 검색’을 만드는 것이었습니다.
이 비전을 실제 시스템으로 옮기기 위해서는 먼저 ‘무엇을 검색해야 하는가’를 정의해야 했습니다. 회사 내에는 수많은 데이터 소스가 존재하지만, 모든 텍스트가 같은 ‘지식’은 아닙니다. Slack의 대화, Notion의 문서, Jira의 티켓, 메일과 회의록까지 모두 다른 구조와 의미를 갖고 있습니다. 그래서 AI Working Group은 우선 Slack과 Notion을 대표 소스로 선정하고, 이 두 환경에서 실제 의사결정의 흔적이 어떻게 쌓이는지를 분석했습니다. 이를 통해 시스템이 다뤄야 할 최소 단위를 ‘비즈니스 컨텍스트(Business Context)’로 정의했습니다. 이 단위는 문서 하나가 아니라, ‘의사결정의 흐름을 설명하는 하나의 맥락 단위 텍스트’였습니다. 다음 섹션에서는 이 비즈니스 컨텍스트가 무엇이며, 왜 이를 중심으로 시스템을 설계했는지를 자세히 살펴봅니다.
비즈니스 컨텍스트 : 우리가 검색하려는 것의 정의
ORI가 다루려는 대상은 단순한 텍스트 데이터가 아닙니다. 우리가 정의한 ‘비즈니스 컨텍스트’는 회사 안에서 실제로 어떤 의사결정이 이루어졌는지를 설명하는 복합적인 단위입니다. 하나의 정책 문서, 그 문서가 작성된 배경이 담긴 Slack 대화, 그리고 담당자의 코멘트나 후속 조치 기록이 모두 연결되어 하나의 맥락을 형성합니다. 다시 말해, 비즈니스 컨텍스트란 ‘이 결정이 왜 이렇게 내려졌는가’를 이해할 수 있게 해주는 데이터의 집합입니다. ORI는 이 복합적 맥락을 분석 가능한 형태로 구조화하고, 사용자가 질문했을 때 이 중 가장 관련도 높은 맥락을 찾아주는 것을 목표로 합니다.
Slack은 오늘의집에서 가장 역동적인 지식이 쌓이는 공간입니다. 실무자 간의 대화, 담당자 멘션, 파일 첨부, 회신 스레드 등은 실제 업무 의사결정의 과정과 결과를 가장 잘 보여주는 데이터입니다. 예를 들어 “이 항목은 예외로 승인되었습니다”라는 한 줄의 멘션은 정책 문서보다 현실적인 근거가 될 때가 많습니다. 하지만 Slack 데이터의 가장 큰 강점이자 약점은 비정형성입니다. 시효성은 높지만 구조화되어 있지 않아 과거의 유사 사례를 재활용하기 어렵습니다. 특정 주제에 대한 과거 논의를 찾기 위해서는 여전히 사람이 직접 메시지를 검색하거나 기억에 의존해야 했습니다. ORI에서는 우선 Slack 데이터를 메시지 단위로 마크다운 형태로 저장하고, 채널·작성자·타임스탬프 등 최소한의 메타정보를 함께 보존하는 방식으로 시작했습니다. 이렇게 저장된 마크다운 데이터만으로도 이후 RAG 파이프라인에서 충분히 검색 가능한 지식 단위로 활용할 수 있었습니다.
반면 Notion은 회사의 공식 정책과 프로세스가 정리된 신뢰도 높은 문서 저장소입니다. 예산 처리 규정, 승인 절차, 보안 정책 등은 모두 Notion을 중심으로 관리됩니다. 하지만 이 문서들은 작성 주기가 길고 실무에서의 실제 변화 속도를 따라가지 못하는 경우가 많습니다. Slack에서 ‘이미 예외 처리된 케이스’가 존재하더라도, Notion 문서가 업데이트되지 않아 여전히 과거 기준이 남아 있는 경우도 드물지 않습니다. 따라서 Slack과 Notion은 각각의 강점이 뚜렷한 대신, 서로 보완되어야만 완전한 그림을 이룹니다. Slack은 현장의 ‘현재’와 ‘맥락’을, Notion은 회사의 ‘원칙’을 담고 있습니다. ORI는 이 두 흐름을 통합적으로 검색할 수 있도록 설계되었습니다.
Slack과 Notion은 서로 다른 성격의 지식이 축적되는 두 축입니다. Slack은 실무 중심의 대화가 빠르게 쌓이며 최신성과 현장성을 보장하지만, 체계가 느슨합니다. 반대로 Notion은 공식 정책과 절차가 정리되어 있지만 갱신 속도가 느리고 현장 맥락을 충분히 반영하지 못합니다. ORI는 이 두 소스의 데이터를 서로 보완적으로 활용하도록 설계되었습니다. 질문이 들어오면 Slack에서는 실제 처리 사례를, Notion에서는 관련 정책 또는 가이드를 함께 조회해 참고 자료로 제시합니다. 이러한 구조는 각 소스의 한계를 보완하고 내부 지식 검색의 정확도를 높이는 기반이 되었습니다.
정리하자면, 우리가 말하는 ‘비즈니스 컨텍스트’는 회사 내 의사결정의 총체입니다. 하나의 질문이 주어졌을 때 시스템은 단일 문서가 아니라 여러 데이터 소스에 흩어진 단서—정책, 사례, 담당자, 그리고 결정의 이유—를 조합해야 합니다. ORI의 설계는 이 개념을 중심으로 이루어졌습니다. 즉, 질문을 입력하면 Slack에서 유사 사례를, Notion에서 관련 정책을, 그리고 메타데이터에서 담당자 정보를 함께 가져와 ‘맥락을 가진 답변’을 생성하는 구조입니다. 다음 섹션에서는 이러한 비즈니스 컨텍스트를 실제로 구현하기 위해 어떤 RAG 기반 접근 방식을 사용했는지, 그리고 시스템의 설계가 어떤 기술적 선택을 거쳤는지를 구체적으로 다룹니다.
접근 방식 : RAG 기반 시스템으로의 전환
앞에서 언급했던 것처럼 정책은 Notion 문서 안에, 실제 사례와 예외는 Slack 스레드 안에 존재하기 때문에 서로 다른 형태의 데이터가 혼재된 환경에서는 단순한 키워드 검색만으로는 충분하지 않았습니다. AI Working Group은 이러한 구조적 차이를 연결하기 위한 가장 현실적인 방법으로 RAG(Retrieval-Augmented Generation) 방식을 선택했습니다. 단순히 ‘검색된 결과를 보여주는 것’이 아니라 관련 맥락을 불러와 의미 단위로 응답을 구성할 수 있기 때문입니다. RAG는 두 데이터 소스 간의 비정형성과 시차 문제를 흡수하며, Slack과 Notion의 맥락을 하나의 응답 내에서 자연스럽게 엮을 수 있는 구조였습니다.
전체 파이프라인은 일곱 단계로 구성됩니다.
(1) 데이터 수집 : Slack과 Notion의 데이터를 정기 또는 실시간으로 수집하고,
(2) 전처리 및 마크다운 변환 : 수집된 데이터를 텍스트 기반으로 통일하며,
(3) 메타데이터 부착 : 작성자, 출처, 시점 등의 정보를 함께 저장합니다.
이후 (4) AWS Bedrock KnowledgeBase 인덱싱으로 데이터를 등록하고,
(5) Hybrid Search와 Reranking 과정을 통해 검색 품질을 향상시킵니다.
(6) LangGraph가 검색 결과를 조합해 답변을 생성하고,
(7) Langfuse가 이를 로깅·평가하며 피드백 루프를 구성합니다.
이 과정에서 비정형 문서는 모두 마크다운으로 변환되어 일관된 형태로 처리되며, 전체 데이터 흐름이 단순하고 추적 가능한 형태로 유지됩니다.
문서 포맷은 프로젝트 초기에 명확히 표준화했습니다. 모든 문서는 마크다운(.md) 형태로 변환해 저장하며, 텍스트 기반 표현으로 통일했습니다. 노션에서 생성된 표는 구조를 유지한 채 마크다운 테이블 형태로 변환해 저장하도록 했습니다. 현재는 이미지나 첨부 파일을 직접 텍스트로 변환하지는 않지만, 추후에는 이미지 설명문을 자동으로 생성해 포함시키는 등 멀티모달 요소를 텍스트화할 수 있는 확장 여지를 열어두었습니다. 이러한 설계는 “모든 문서는 문자열로 표현될 수 있다”는 전제에 기반하며, 다양한 출처의 데이터를 하나의 검색 파이프라인으로 통합하기 위한 기초가 되었습니다.
각 문서에는 별도의 메타데이터 파일(.metadata.json)이 자동으로 생성되어 S3 내 동일 경로에 저장됩니다. Bedrock KnowledgeBase는 이 파일을 자동으로 인식하고, 추가적인 필드 정보를 인덱싱 시 함께 수집합니다. 별도의 커스텀 인덱싱 로직을 구현하지 않아도 되기 때문에, 구현 복잡도를 크게 줄일 수 있었습니다. 실제 속성은 아래와 같은 추상 형태를 따릅니다 :
{
"metadataAttributes": {
"author": {"value": {"type": "STRING"}, "includeForEmbedding": true},
"source_url": {"value": {"type": "STRING"}, "includeForEmbedding": true},
"created_date": {"value": {"type": "NUMBER"}, "includeForEmbedding": true},
"updated_date": {"value": {"type": "NUMBER"}, "includeForEmbedding": true},
"title": {"value": {"type": "STRING"}, "includeForEmbedding": true},
"fanout_urls": {"value": {"type": "STRING"}, "includeForEmbedding": true},
"domain_id": {"value": {"type": "STRING"}, "includeForEmbedding": true}
}
}
이 메타데이터는 단순 검색 보조 이상의 의미를 가집니다. fanout_urls 필드는 문서 간 참조 관계를 나타내고, domain_id는 Slack·Notion 등 데이터 출처를 명시합니다. 이러한 구조는 향후 연관 문서 탐색이나 프로젝트 단위의 관계 기반 검색으로 확장할 수 있는 기반이 됩니다. 예를 들어 특정 주제의 Notion 문서에서 fanout_urls를 통해 Slack 대화 기록으로 연결되면, 단일 문서 중심의 검색을 넘어 ‘맥락적 탐색’이 가능해집니다. 주요 필드는 아래와 같습니다.
AWS Bedrock KnowledgeBase에서는 Hybrid Search를 활용했습니다. 이 방식은 RAG의 retrieval 단계에서 문서 탐색 정확도를 높이기 위해 자주 사용되는 접근법으로, 짧은 검색어는 키워드 검색이, 장황한 질의는 벡터 검색이 강점을 갖는 경향이 있습니다. 키워드 기반 검색과 벡터 기반 검색을 결합하면 짧고 명확한 요청과 길고 복합적인 질문 모두에 안정적인 결과를 얻을 수 있습니다. 또한 대부분의 데이터베이스에서는 RRF(Reciprocal Rank Fusion)를 직접 구현해야 하는 반면, Bedrock은 이를 기본적으로 지원했습니다. 향후에는 키워드 검색과 벡터 검색 결과를 가중합 형태로 커스터마이징하여, 각 쿼리 유형별로 최적 가중치를 실험해 볼 여지도 있습니다.
초기에는 단순한 벡터 유사도 검색만으로 충분하다고 판단했지만, 실제 실험 과정을 거치면서 VPN 관련 문의 등에서 오탐 사례가 다수 발견되었습니다. 특정 질문에 대해 정답 후보가 검색되었음에도, 순위가 낮아 결과에서 제외되는 경우가 있었던 것입니다. 이 문제를 해결하기 위해 LLM 기반 Reranker를 도입을 검토했으며, 여러 벤치마크 결과와 커뮤니티 사례를 검토한 끝에 Cohere rerank-3.5 모델을 채택했습니다. 그 결과 응답 시간이 약간 증가(1초 내외)했지만, 최대 3.6배(Notion, +264.2%)의 정확도 개선 효과를 확인할 수 있었습니다. 체감 성능 개선이 분명했고, 지연 시간은 허용 범위(1분 내 응답 목표) 안에 있었습니다. 시스템 전반의 기술 선택은 세 가지 축의 균형을 기준으로 이루어졌습니다.
첫째, 정확도와 속도(Accuracy ↔ Latency)의 균형입니다. 내부 Q&A 자동화 특성상 1분 이내 응답(SLA)을 지키되, 지나치게 오래 걸리지 않는 선에서 높은 정확도를 달성하는 것을 원칙으로 삼았습니다. 복잡도를 무한히 높이기보다 정확도를 우선하되 지연이 SLA를 넘지 않도록 최적화했습니다.
둘째, Vendor Lock-in과 Open Source의 선택입니다. 제한된 리소스와 일정 속에서 안정적 성과를 내기 위해 AWS Bedrock을 선택했지만, 향후 확장을 고려해 내부 벡터 DB와의 호환성도 확보해 두었습니다.
셋째, 비용과 유연성(Cost ↔ Flexibility)입니다. LangGraph를 채택해 다양한 워크플로우를 시각적으로 설계하면서도, 인프라 비용을 통제할 수 있는 구조를 유지했습니다.
이 세 축은 프로젝트의 기술적 의사결정을 일관되게 이끌어간 기준이 되었습니다. 결과적으로 RAG 기반 접근은 “한 번의 질문으로 회사의 맥락을 탐색할 수 있는 구조”를 현실화하는 핵심 기술이 되었습니다. Slack과 Notion의 데이터를 동일 파이프라인에서 검색할 수 있게 되면서, 사내 정보 접근의 단일 진입점(single entry point)이 만들어졌습니다. 다음 섹션에서는 이러한 RAG 구조가 실제로 어떤 방식으로 Slack과 Notion 데이터를 수집·확장하는지, 그리고 각 데이터 소스가 시스템 안에서 어떻게 운영되는지를 살펴보겠습니다.
Slack 데이터 수집 : Batch에서 Event 기반으로
Slack은 ORI의 데이터 소스 중 가장 실무적인 정보를 담고 있는 채널이었습니다. 실제 사례, 담당자 멘션, 예외 승인 내역 등이 모두 이곳에서 논의되었기 때문입니다. 프로젝트 초기에는 Slack Web API를 활용해 일정 주기로 메시지를 수집(batch)하고, 이를 S3 버킷에 저장하는 방식으로 시작했습니다. 이는 구현이 단순하고 관리가 용이하다는 장점이 있었지만, API rate limit에 걸릴 가능성이 있었고 최신 대화가 즉시 반영되지 않는다는 한계가 있었습니다. 또한 Slack 채널이 점점 늘어나면서 배치 작업이 길어질 경우, 주기 내에 모든 데이터를 수집하지 못할 가능성도 있었습니다. Slack 앱을 추가해 분산 수집을 수행하는 방안을 고려하기도 했지만 실시간성이 중요한 Q&A 자동응답 목적에는 배치 중심 구조가 근본적으로 적합하지 않았습니다.
이후 AI Working Group은 배치 기반 구조를 Event Subscription + Socket Mode 기반 실시간 수집 구조 로 전환했습니다. 이 구조는 Slack 앱이 이벤트를 수신하면, 메시지를 S3에 바로 저장하고 S3 Event Trigger를 통해 AWS Lambda가 Bedrock KnowledgeBase 인덱싱을 호출하는 방식입니다. 이 설계로 rate limit 문제를 우회하면서, 수동 배치 관리 없이 모든 퍼블릭 채널의 메시지를 실시간으로 반영할 수 있게 되었습니다. Socket Mode는 별도 외부 서버를 두지 않고 내부 네트워크에서 안전하게 이벤트를 수신할 수 있는 점도 장점이었습니다.
이벤트 기반 구조로 전환하면서 데이터 신선도와 운영 효율 모두 개선되었습니다. 새로운 메시지가 발생하면 즉시 S3 객체가 생성되어 Slack 상의 변화가 거의 실시간으로 반영되기 때문에 배치 스케줄 관리나 누락 점검이 필요하지 않게 되었죠. Slack 앱당 하루 30K 이벤트 제한이 있어 rate limit에 걸릴 가능성이 우려되었지만, 전환 전에 Slack 전체 데이터 볼륨을 분석한 결과 이 한도를 초과하지 않는 수준이었습니다. 따라서 채널 수를 제한하지 않고 전사 퍼블릭 채널 전체를 수집 대상으로 둘 수 있었습니다. 이 과정을 통해 “Slack 메시지를 S3에 단일 진실원본(Single Source of Truth)으로 축적한다”는 구조가 정착되었고, 실시간 수집이 대부분의 조직에서도 무리 없이 적용 가능하다는 인사이트를 얻었습니다.
Slack 메시지는 단순 텍스트가 아니라 멘션, 스레드, 리액션 등 다양한 형태의 비정형 요소를 포함하고 있습니다. 이를 일관되게 처리하기 위해 ‘본문 + 메타데이터 요약’ 형태의 마크다운 변환 규칙을 정의했습니다. 멘션(@username)은 텍스트 그대로 유지하고, 스레드 내 답글은 > reply 블록 인용 형태로 변환했습니다. 메시지마다 channel, timestamp, author 정보가 함께 기록됩니다. 이렇게 변환된 데이터는 검색 시 문맥 단위로 정렬되거나, 스레드 흐름 복원이 가능합니다.
@alex 문의주신 부분은 이미 처리되었습니다.
> reply: @jordan 네, 지난주 배포에서 반영되었습니다.
(meta: channel=#security, author=@taylor, ts=1728861234)
각 Slack 메시지는 .metadata.json 파일을 함께 생성해 저장합니다. Bedrock KnowledgeBase는 이를 자동으로 인식해 인덱싱 과정에서 함께 처리합니다. 이 메타데이터는 이후 검색 단계에서 필터링이나 도메인별 리콜 제한 등에 활용되며, RAG 파이프라인에서 Slack 문맥을 독립적으로 분석할 수 있는 근거가 됩니다.
현재 ORI의 Slack 파이프라인은 전사 퍼블릭 채널을 대상으로 실시간 이벤트 수집을 수행하고 있습니다. 이 구조를 통해 Slack 상의 대화가 거의 지연 없이 Bedrock KnowledgeBase에 반영되며, 배치 방식 대비 운영 안정성과 데이터 최신성이 크게 향상되었습니다. Slack 수집은 ORI의 전사 지식 탐색 파이프라인에서 실무 데이터를 담당하는 축으로 자리 잡았습니다. 다음 섹션에서는 이와 짝을 이루는 또 다른 축인 정책 문서 데이터 소스인 Notion 연동 구조를 다룹니다.
Notion 데이터 수집 : 복잡한 문서 구조를 안정적으로 다루는 파이프라인
Slack 수집이 실시간 이벤트 스트림을 통해 변경 사항을 즉각 반영하는 ‘실시간성’ 중심 구조였다면, Notion은 방대한 텍스트 기반 문서와 복합 객체를 누락 없이 처리할 수 있는 대규모 수집 파이프라인 구축이 핵심이었습니다. 오늘의집 내부에는 약 200만 건의 노션 문서가 존재하며, 매일 1천 건 이상 생성되고 1만 건 이상 수정됩니다. 이처럼 방대한 문서 데이터를 완전하게 수집하고 최신 상태를 유지하기 위해, AI Working Group은 단순 API 호출을 넘어 문서 구조, API 제약, 순환 참조 등 다양한 문제를 해결하는 체계를 설계했습니다. 아래는 그 주요 이슈와 해결 방법입니다.
✔️ 문제 1 : 전체 문서 탐색 - Teamspaces 기반 계층적 크롤링
Notion API에는 모든 문서를 조회할 수 있는 엔드포인트가 없었습니다. Search API로 테스트를 수행한 결과, 성능과 제약 때문에 안정적으로 여러 문서 정보를 한번에 추출할 수 없다고 판단했습니다. 따라서, Teamspaces의 최상위 페이지에서 시작해 하위 참조(child pages)를 재귀적으로 탐색하는 너비 우선 탐색(BFS) 방식을 채택했습니다. 이 방식은 추출 대상으로 포함할 필요가 없는 문서들도 걸러줄 수 있다는 장점도 있었으며, 최종적으로 Teamspaces에서 생성된 약 40만 개 문서를 대상으로 데이터 수집 작업을 수행할 수 있었습니다.
✔️ 문제 2 : 순환 참조(Circular Reference)로 인한 무한 루프 - Redis 기반 중복 제거
Notion 문서들은 서로를 자유롭게 참조할 수 있기 때문에, “문서 A → 문서 B → 문서 A”와 같은 순환 참조가 빈번했습니다. 초기에는 BFS 큐에 문서 reference를 단순 추가하는 구조였기에, 이 문제가 생기면 크롤러가 종료되지 않았습니다. 이를 해결하기 위해 Redis의 Set 자료구조를 활용했습니다. 각 문서의 처리 상태(성공, 실패, 진행 중)를 Redis에 기록하고, 이미 처리된 문서는 즉시 스킵하도록 구현했습니다. 이 방식으로 중복 작업을 제거하고 작업 효율을 높였으며, 진행 현황도 실시간으로 모니터링할 수 있었습니다.
✔️ 문제 3 : Notion API의 불안정성과 데이터 구조 다양성 - Notion Parser와 Fallback
Notion API로 데이터를 추출해 본 분이라면, 다음과 같은 에러 메시지를 한 번쯤은 마주했을 것입니다.
Could not retrieve page…
Could not fetch database contents for …
Database with ID does not contain any data sources accessible by this API bot.
문제의 핵심은 문서 타입과 내부 구조가 페이지마다 다르다는 점이었습니다. API가 반환하는 데이터는 page, database, object, block 등으로 나뉘며 각 타입의 구조가 제각각이라 모든 경우를 일관되게 처리하기 어려웠습니다. 이를 해결하기 위해 Notion Parser를 구축했습니다. 문서의 id를 기반으로 metadata를 조회하고, 1) 문서/데이터베이스 구분 2) 하위 페이지·객체 포함 여부 3) 블록 타입에 따른 파싱 로직을 분기 처리하도록 설계했습니다.
하지만 API 불안정성으로 특정 하위 콘텐츠를 가져오지 못하는 경우가 여전히 존재했습니다. 이때는 Fallback 로직을 추가해, 노션의 파일 다운로드 기능을 직접 호출하여 원문을 복원했습니다. export cookie와 file cookie를 이용해 문서를 다운로드한 후, 테이블·참조 링크 등의 내용을 재구성함으로써 누락된 데이터까지 완전하게 복원할 수 있었습니다.
✔️ 문제 4: 최신 변경 사항 반영 지연 - Search API 기반 일일 증분 업데이트
단일 API Key 기준, 문서 1건을 처리하는 데에 평균 3.6초가 소요되었습니다. 단순 계산으로 40만 건을 처리하려면 약 400시간(약 16일 16시간)이 필요한 셈입니다. 이 병목을 해소하기 위해 다중 API Key를 병렬로 처리하는 구조를 설계했고, 처리 속도를 10배 향상시켰습니다. 덕분에 주말 배치만으로도 전체 문서 동기화를 완료할 수 있게 되었습니다.
그러나 여전히 한계는 남아 있었습니다. 오늘의집에서는 매일 수천 건의 문서가 새로 생성되거나 수정되기 때문에, 주간 배치를 기다리는 것은 최신성 측면에서 아쉬움이 있었습니다. 이를 해결하기 위해 Notion Search API의 최신순 정렬 기능을 활용하여, 매일 생성·수정된 문서만을 수집하는 일 배치 작업을 구축했습니다. 이 증분 업데이트 구조를 통해 완전한 실시간 반영은 아니지만, 문서 최신성이 하루 단위로 개선되었고 ORI의 검색 결과 또한 더 시의성 있는 데이터를 다룰 수 있게 되었습니다.
평가 체계 설계 : 실험과 메트릭의 진화
프로젝트 초기에 ORI의 품질 평가는 대부분 정성적 판단에 의존했습니다. 몇 가지 대표 질의를 던져보고, 그 결과가 ‘적절해 보이는지’를 논의하는 수준이었습니다. 하지만 이 방식은 개선 여부를 수치로 판단할 수 없고, 실험마다 결과 해석이 달라지기 때문에 지속적인 개선 방향을 잡기 어려웠습니다. 개발을 이어가면서 ‘검색 결과가 정말로 의미 있는 문서를 찾고 있는가’를 객관적으로 검증할 필요성이 자연스럽게 제기되었습니다. 단순히 생성된 답변의 품질이 아니라, 검색된 문서가 질문 의도에 부합했는가를 정량적으로 측정할 체계가 필요했습니다.
처음 시도한 평가지표는 nDCG(Normalized Discounted Cumulative Gain)이었습니다. 이는 검색된 문서의 순위를 기준으로, 정답 문서가 상위에 있을수록 높은 점수를 부여하는 대표적인 랭킹 지표입니다. 그러나 내부에는 평가용 gold label 데이터셋이 존재하지 않았습니다. 이를 보완하기 위해 LLM을 활용해 pseudo-gold 데이터를 자동으로 생성했지만, LLM 출력의 일관성이 낮아 결과의 신뢰도가 떨어지는 문제가 있었습니다. 동일한 쿼리와 문서 조합이라도 모델 버전이나 프롬프트 변경에 따라 결과가 달라졌고, 지표 변동이 실제 품질 저하를 의미하는지 판단하기 어려웠습니다. 결국 nDCG는 체계적 평가의 출발점이었지만, gold 데이터 없이 유지하기 어려운 구조라는 한계가 드러났습니다.
이를 보완하기 위해 평가 방식은 LLM-as-a-judge 구조로 전환되었습니다. 이 방식은 사람이 평가하듯, LLM이 직접 응답을 읽고 ‘질문 의도에 맞는가’, ‘검색된 문맥이 적절히 활용되었는가’를 판정하는 접근입니다. 이로써 별도의 gold 데이터셋 없이도 실험 간 상대적 품질 비교가 가능해졌습니다. LLM이 매번 동일 기준으로 판단하도록 프롬프트를 고정함으로써, 결과를 수치화해 지속적인 품질 모니터링을 수행할 수 있었습니다.
RAGAS 평가 지표 기반 평가 체계 도입
LLM-as-a-judge 기반 평가에서는 RAG 파이프라인을 Retrieval 단계와 Generation 단계로 나누어 서로 다른 기준으로 점검했습니다. Retrieval 단계의 품질은 RAGAS의 ‘Context Precision Without Reference’ 지표로 확인했습니다. 이 지표는 정답 레퍼런스가 없는 상황에서, “검색된 문맥 중 실제 답변 생성에 의미 있게 기여한 문맥이 얼마나 되는지”를 기반으로 Retrieval의 정확도를 판단하는 방식입니다. 예를 들어 5개의 문서를 검색했지만 그중 1~2개만 답변에 실질적으로 활용되었다면, 불필요한 문서를 과도하게 가져온 것으로 평가되어 context precision이 낮게 나옵니다.
반면 Generation 단계에서는 faithfulness라는 지표를 사용했습니다. faithfulness는 ‘최종 응답이 주어진 근거(검색된 문맥)에 얼마나 충실한가’, ‘없는 내용을 임의로 지어내지 않았는가’를 LLM이 판정하도록 하는 방식입니다. 즉, 모델이 근거에 기반해 답했는지를 검증하는 지표입니다. 이렇게 Retrieval은 context precision으로, Generation은 faithfulness로 별도 점검함으로써 ‘우리가 올바른 문서를 찾아왔는가’와 ‘찾은 문서를 근거로 답했는가’를 분리해 평가할 수 있었습니다. 이는 단순히 응답이 맞았는지 여부를 보는 정확도 지표보다, 실제 맥락 활용 중심의 품질 관리 체계를 세우는 데 더 적합했습니다.
RAGAS 평가 지표 기반 검색 성능 개선
이 두 지표를 활용해 검색 기반 QA 시스템의 성능을 정량적으로 측정하고 개선했습니다. Slack과 Notion 두 데이터 소스 중, 특히 비정형 구조를 가진 Notion 문서의 검색 정확도 향상이 주요 과제였습니다. Slack 데이터의 경우 메시지가 문제–원인–해결–결과 구조로 구성되어 있에 초기부터 벡터 검색 성능이 양호했습니다. 반면, Notion 문서는 Q&A 구조가 아닌 서술형 지식 문서이기 때문에 질의 문장을 그대로 검색에 사용하면 관련 문서를 찾기 어려웠습니다. 이 문제를 해결하기 위해 다음 세 가지 접근을 순차적으로 도입했습니다.
- Reranker 적용 — 검색된 문서 중 실제 질의와 의미적으로 가장 관련성 높은 문서를 재정렬
- Chunking 전략 개선 — 문서를 분리할 적합한 chunk 크기와 구조(Fixed / Hierarchical)를 최적화
- Model Optimization — 벡터 임베딩 모델과 검색 파이프라인을 개선하여 의미 매칭 성능 강화
[Context Precision]
[Faithfulness]
이 일련의 개선으로 Notion 문서 기반의 Context Precision이 약 5배(402%), Faithfulness가 56% 향상되었으며, 검색 단계의 “관련 문서 정확도”와 생성 단계의 “근거 충실도”가 함께 개선되었습니다. 즉, 모델의 응답이 실제 근거에 기반해 생성되도록 유도하는 구조로 발전했습니다. 이처럼 RAGAS 기반 평가는 LLM-as-a-judge 평가를 정량적 지표로 확장한 형태로, 실험의 품질 변화를 수치로 추적하고 개선 효과를 명확히 설명할 수 있는 근거가 되었습니다.
Langfuse 기반 평가 및 관제
평가 결과를 단발성으로 확인하는 수준에서 끝내지 않고 지속적으로 관리하기 위해, 기존에 프롬프트 관리 도구로 사용하던 Langfuse를 관제와 평가에도 적극적으로 활용하기 시작했습니다. Langfuse는 우선 프롬프트 버전을 관리하고 수정 이력을 기록할 수 있기 때문에, ‘어느 프롬프트가 어느 시점에 어떤 형태였는가’를 추적할 수 있습니다. 여기에 더해, 프롬프트와 실행 기록(트레이스)을 자동으로 연결해 ‘이 프롬프트가 실제로 어떤 응답을 생성했는가’를 시각적으로 살펴볼 수 있습니다. 또한 Langfuse 상에서 각 트레이스마다 점수를 부여할 수 있어, context precision / faithfulness 기반 평가 결과를 요청 단위로 저장하고 변화를 수치화할 수 있습니다. 또한 Langfuse는 LangGraph 워크플로우를 노드 단위로 시각화해, 파이프라인 각 단계의 출력을 순서대로 보여줍니다. 덕분에 문제가 발생했을 때, retrieval, rerank, generation 중 어느 단계에서 품질이 손상되었는지 즉시 역추적할 수 있습니다. 이 구조 덕분에 실험은 ‘한 번 돌려보고 느낌 공유’ 수준에서 벗어나, 프롬프트 변경 → 결과 변화 → 점수 변동을 지속적으로 축적·비교할 수 있는 평가 루프로 정착했습니다.
결과적으로 ORI의 평가 체계는 단순히 “정답을 맞히는가”를 검증하는 수준을 넘어, “어떤 문맥이 선택되었고, 그 선택이 얼마나 일관되게 개선되는가”를 관찰할 수 있는 구조로 발전했습니다. 지표는 매 실험마다 Langfuse에 기록되고, 개선 흐름이 데이터로 축적되며, LLM-as-a-judge가 이를 정성적 기준으로 보완합니다. 다음 섹션에서는 이러한 평가 체계를 기반으로 실제 프론트엔드인 오집사에 통합된 사례와, 그 결과로 관찰된 사용자 변화 양상을 다룹니다.
✅ 적용 단계로의 전환
이렇게 구축된 전사 지식 탐색 시스템은 이제 실제 현장에서 활용될 차례였습니다. AI Working Group은 이 시스템을 사내 구성원이 일상적으로 사용하는 인터페이스에 녹여내는 것을 목표로, 기존 챗봇 오집사와의 통합을 추진했습니다. 이를 통해 사내 Slack과 Notion에 흩어져 있던 정보를 대화형으로 탐색할 수 있는 프론트엔드를 확보했습니다. 이후에는 같은 구조를 기반으로 자동 Q&A 기능을 확장하여, 부서별 반복 문의를 AI가 실시간으로 대응하도록 시범 적용했습니다. 이 단계부터는 단순한 기술 구현을 넘어, 실제 사용자 경험과 피드백을 중심으로 검증이 이루어졌으며, 프로젝트는 자연스럽게 “적용 단계(Phase 2)”로 진입했습니다.
오집사 통합 : 전사 지식 탐색의 프론트엔드
전사 지식 탐색 시스템이 구축되더라도, 이를 실제로 사용하는 창구가 없다면 효과는 제한적입니다. 당시 회사 내부에는 이미 오집사라는 Slack 기반 챗봇이 존재했습니다. 오집사는 IT 지원, 인사, 보안 등 여러 채널에서 반복되는 문의를 모아 요약하거나 담당자에게 전달하는 역할을 하고 있었지만, 본질적으로는 ‘대화 정리 도구’에 가까웠습니다. 이 시점에서 ORI(Omni Resource Integrator) 프로젝트는 별도의 프론트엔드가 필요했고, 오집사 또한 사내 챗봇으로서 명확한 한계를 가지고 있었습니다. 두 문제의 해법을 함께 찾기 위해 ‘ORI의 주요 인터페이스 중 하나를 오집사로 하자’는 결정을 내렸습니다. ORI는 백엔드에서 전사 지식을 연결하고, 오집사는 이를 가장 손쉽게 접근할 수 있는 창구로 작동하도록 한 것입니다. 이를 통해 사내 Slack과 Notion 데이터를 하나의 대화형 경험으로 통합하는 실험이 시작되었습니다.
ORI 통합 이후 오집사는 단순한 요약 챗봇이 아닌 전사 지식 탐색 인터페이스로 진화했습니다. 사용자가 Slack에서 오집사를 호출하면, 백엔드에서 ORI가 Slack과 Notion의 통합 인덱스를 기반으로 RAG 검색을 수행합니다. 검색된 문서는 LLM 응답에 포함된 근거(reference) 형태로 함께 반환되어, 사용자는 ‘이 답이 어떤 문서와 대화에서 비롯된 것인지’를 즉시 확인할 수 있습니다. 이 과정은 모두 Slack 메시지 내에서 일어나며, 추가적인 UI나 별도 애플리케이션 설치 없이도 사내 문맥을 기반으로 한 답변을 받을 수 있도록 설계되었습니다.
ORI가 연결된 이후 오집사의 활용도는 뚜렷하게 증가했습니다. 적용 이전에는 오집사가 회사의 맥락을 이해하지 못해 실질적으로는 단순 질의 요약 도구로 사용되었고, 퍼블릭 채널 기준 호출 횟수도 일정 기간 약 수백 건 수준에 머물렀습니다. ORI가 통합된 이후 같은 기간 동안 호출 횟수는 약 2~3배 이상 증가했고, 개인 대화까지 포함하면 수천 건에 이르렀습니다. 이는 단순히 트래픽 증가를 넘어 ‘질문하면 실제 사내 의사결정과 과거 처리 경험에 근거한 답을 받을 수 있다’는 신뢰가 형성되었다는 점에서 의미가 있었습니다.
통합 과정의 핵심은 ORI를 별도의 서비스로 분리하고 REST API 형태로 노출한 설계였습니다. 이 구조 덕분에 오집사와 ORI 간 통신을 단일 API 호출로 구성할 수 있었고, 향후 다른 인터페이스(예: 사내 포털 또는 데이터 콘솔)에서도 동일한 ORI 엔드포인트를 재사용할 수 있게 되었습니다. 오집사 쪽에서는 기존 프롬프트 포맷을 그대로 유지하되, RAG 검색 결과를 system message 영역에 삽입하는 방식으로 응답 품질을 높였습니다. 이 접근은 오집사의 기존 사용자 경험을 그대로 보존하면서도 ORI 결과를 즉시 반영할 수 있는 가장 단순하고 확장성 있는 구조였습니다. 프롬프트는 Langfuse를 통해 버전 관리되어 품질 지표에 따라 실험과 튜닝을 반복할 수 있게 했습니다.
UX 측면에서도 큰 변화가 있었습니다. 오집사는 이제 단일 질문에 대해 단 하나의 문장을 반환하는 대신, 여러 문서의 근거를 함께 제시하도록 설계되었습니다. 예를 들어, “보안 점검 보고 절차는 어떻게 되나요?”라는 질문에 대해 오집사는 관련 Slack 대화 요약과 Notion 정책 문서를 함께 링크로 제공합니다. 이는 ‘AI가 대신 말해주는 답변’이 아니라, ‘참조 가능한 내부 문서 기반의 응답’으로 인식되며, 사용자에게 신뢰를 높여주었습니다. 이런 구조는 챗봇의 신뢰도 문제를 완화하고 내부적으로 AI 보조 Q&A 문화가 자리 잡는 계기가 되었습니다.
ORI 통합은 ‘모든 사내 지식을 하나의 대화로 연결한다’는 목표의 첫 실현이었습니다. 이를 계기로 여러 팀이 오집사를 중심으로 자동 Q&A를 실험하기 시작했습니다. 각 부서는 자신들이 다루는 문서와 Slack 대화 데이터를 기반으로 자동응답을 학습시키거나, 프롬프트를 세분화해 도메인 특화형 답변을 만드는 형태로 발전했습니다. 다음 섹션에서는 이러한 도메인별 자동 Q&A 확장 과정과 실제 사용자 인터뷰를 통해 도출된 요구사항 및 기술적 제약을 함께 다룹니다.
자동 Q&A 프로젝트 : 사용자 피드백과 기술적 제약의 교차점
전사 지식 탐색 시스템이 오집사를 통해 안정적으로 활용되기 시작한 후, 다음 과제는 Q&A 응답의 자동화였습니다. 여러 부서, 특히 운영·보안·인사 등 비개발 직군의 Q&A 채널에서는 반복적인 문의 대응이 상당한 리소스를 차지하고 있었고, ‘얼마나 빠르게 답하느냐’가 품질의 핵심 지표로 여겨졌습니다.
이에 따라 자동 Q&A 시스템은 최대한 빠르게 응답하되 오답률은 최소화해야 했습니다. 모델의 완벽한 정답을 기대하기는 어려웠기에, 대신 “최대 1분 이내 응답”이라는 실질적인 SLA(Service Level Agreement)를 설정하고, 이 범위 내에서 가장 신뢰도 높은 응답을 제공하도록 시스템을 설계했습니다. 자동 Q&A 도입 전, 여러 부서 구성원과의 사용자 인터뷰를 통해 세 가지 공통적인 pain point가 드러났습니다.
첫째는 응답 속도입니다. 대부분의 팀에서 “가능하면 1분 이내에 답이 오면 좋겠다”는 의견이 일관되게 제시되었습니다.
둘째는 면책 문구(disclaimer)입니다. AI가 생성한 답변이 항상 정확하지 않을 수 있다는 점을 우려한 일부 팀에서는, “이 답변은 AI가 생성했으며 실제 정책과 다를 수 있습니다”라는 문구를 포함해달라고 요청했습니다. 이에 따라 프로덕션 환경에서는 기본 템플릿에 면책 문구가 자동으로 삽입되도록 했습니다.
셋째는 담당자 라우팅입니다. 단순히 답변으로 끝나는 것이 아니라, ‘해당 질문이 어느 담당자에게 이어져야 하는가’를 자동으로 연결하는 기능이 필요하다는 의견이 다수였습니다.
그러나 팀별 요구사항은 상당히 다양했습니다. 일부 팀은 “현재 수준의 자동응답이면 충분하다”고 평가한 반면, 다른 팀은 “Notion에 명시된 공식 정책만을 근거로 답변해야 한다”는 엄격한 조건을 제시했습니다. 또 어떤 팀은 단순 응답을 넘어 “답변 이후 티켓 생성, 담당자 멘션, 알림 전송 등 후속 액션이 자동으로 수행되길 원한다”고 요청했습니다. 이처럼 이질적인 요구를 모두 코드로 직접 반영하는 것은 비효율적이었습니다. AI Working Group은 이 문제를 해결하기 위해, 기존에 PoC 용도로 사용하던 워크플로 자동화 도구인 n8n을 본격적으로 활용하기로 했습니다. n8n은 시각적 노드 기반으로 동작하며, REST API 호출이 가능한 HTTP 노드를 기본적으로 지원하기 때문에 ORI를 별도 개발 없이 즉시 연동할 수 있었습니다. 이를 통해 각 팀은 “질문 입력 → ORI 검색 → 후속 액션(티켓 생성, Slack 알림 등)”의 프로세스를 직접 구성할 수 있었고, 중앙 코드 수정 없이도 자동화 범위를 유연하게 확장할 수 있었습니다. 현재는 ORI용 전용 노드를 별도로 만들지 않고 HTTP 노드로 연결하고 있지만, 장기적으로는 ORI의 주요 기능을 8n 노드 형태로 제공해 팀 단위의 업무 자동화 시나리오를 더욱 손쉽게 구성할 수 있도록 확장할 계획입니다.
자동 Q&A의 핵심 제어 지점은 SSOT(Single Source of Truth) 시트였습니다. 이 시트를 도입한 이유는 단순히 데이터를 통합하기 위함이 아니라, 각 팀이 스스로 응답 유도를 구성할 수 있게 하기 위함이었습니다. 즉, AI가 모든 답을 생성하도록 맡기기보다, 도메인 담당자가 직접 “이런 질문에는 이런 맥락으로 답하라”는 기준을 정의할 수 있는 구조를 만들고자 한 것입니다.
각 팀 담당자는 SSOT 시트에 주기적으로 ‘질문–답변 예시’, ‘담당자 매핑’, ‘도메인별 정책 링크’ 등을 업데이트했습니다. Airflow는 이를 주기적으로 수집하여 ORI를 통해 Langfuse 프롬프트에 자동 반영했습니다. 이 덕분에 시스템은 단순히 정답을 생성하는 모델이 아니라, 각 팀의 규칙과 담당 구조를 인지한 상태에서 응답하는 보조자로 진화할 수 있었습니다. 이 구조는 결과적으로 사용자 중심의 운영 모델을 가능하게 했습니다. 기존에는 AI 팀이 일일이 모델 응답을 수정·튜닝해야 했다면 이제는 각 부서가 자신의 지식 영역을 직접 정의하고 주입할 수 있는 루프를 형성하게 된 것입니다.
실제로 자동 Q&A를 도입한 팀들은 반복 문의 대응에 필요한 운영 리소스를 약 20% 절감할 수 있었다고 피드백을 주었습니다. 이는 단순히 AI가 몇 가지 답변을 대신했기 때문이 아니라, 반복적인 문의에 자동으로 대응하고 담당자 연결 과정을 단축함으로써 업무 흐름의 병목(bottleneck)이 줄어든 결과였습니다. 예를 들어, 보안팀의 경우 ‘계정 접근 권한 신청 절차’ 관련 문의의 60% 이상이 자동응답으로 처리되었고, 나머지 복잡한 문의만 담당자에게 자동 라우팅되었습니다. 결과적으로 담당자의 응답 부담을 줄이고 좀 더 중요한 업무에 집중할 수 있는 시간을 확보하게 만들었습니다.
여전히 실제 운영 환경에서는 봇이 응답하더라도 사람이 검수해야 하는 케이스가 많습니다. 특히 정책 변경이나 예외 처리가 빈번한 채널에서는 AI 응답의 신뢰도를 확보하기 위해 담당자가 응답 내용을 확인·보완하는 단계를 거칩니다. 그럼에도 불구하고, 일부 채널에서는 봇의 자동응답만으로도 질문이 완전히 해소되는 사례가 꾸준히 발생하고 있으며 향후 더 높은 수준의 운영 리소스 절감이 기대됩니다. 즉, 오늘의집에서 자동 Q&A는 단순 자동화가 아니라 사람과 AI가 함께 응답 체인을 구성하는 형태의 협업 구조로 자리 잡고 있습니다.
✅ 운영 및 발전 단계로의 전환
시스템을 만드는 일보다 더 어려운 것은 지속적으로 유지하고 발전시키는 일입니다. 전사 지식 탐색과 자동 Q&A가 각각 안정화된 이후, AI Working Group의 관심은 ‘이 구조를 얼마나 오래, 그리고 얼마나 정교하게 다듬을 수 있을까’로 옮겨갔습니다. 이제부터는 구축된 시스템을 안정적으로 운영하고 품질을 정량적으로 개선하기 위한 체계 수립과 그 결과를 다루고자 합니다. 다음 단계의 주제는 운영, 관제, 그리고 실험 관리 체계의 정착입니다.
시스템 운영 및 관제 : Langfuse 기반 실험 관리 체계
자동 Q&A가 실제 업무 환경에 적용된 뒤 가장 먼저 직면한 과제는 ‘시스템을 안정적으로 개선하고 유지할 수 있는 구조를 만들자’는 것이었습니다. LLM 기반 응답은 모델 버전, 프롬프트 문구, 데이터셋 업데이트에 따라 작은 차이만으로도 결과가 달라질 수 있기 때문입니다. 이에 따라 단순 모니터링을 넘어, 실험·평가·관제가 하나의 루프로 작동하는 운영 구조가 필요했습니다. 이 단계에서 AI Working Group은 기존에 프롬프트 관리 중심으로만 활용하던 Langfuse를 시스템 전체의 실험·평가·관제 허브로 확장했습니다. Langfuse는 응답 로그, 평가 점수, 프롬프트 버전, 검색 결과를 한 곳에 기록할 수 있기에, 운영자가 ‘무엇이 바뀌었고 왜 바뀌었는가’를 추적하기에 적합한 구조였습니다.
Langfuse는 단순한 로그 저장소가 아니라, 모델의 입력–출력–평가 데이터를 통합 관리하는 관제 허브로 활용되었습니다. 모든 응답은 Langfuse의 Trace 단위로 자동 기록되며, 각 Trace에는 다음과 같은 메타데이터가 포함됩니다.
이 구조 덕분에 ‘어떤 프롬프트가 어떤 응답 품질을 만들었는가’를 명확히 추적할 수 있었고, 응답 품질 변화를 단일 대시보드에서 시각적으로 파악할 수 있었습니다.
Langfuse의 Prompt–Trace 연동 기능은 운영 효율을 크게 높였습니다. 프롬프트가 수정될 때마다 자동으로 새 버전이 생성되고, 이후 들어오는 모든 응답 트레이스는 해당 버전과 자동으로 연결됩니다. 이 구조 덕분에 응답 품질이 달라졌을 때 그 원인이 프롬프트 수정 때문인지, 데이터셋 업데이트 때문인지, 혹은 모델 버전 변경 때문인지를 명확히 구분할 수 있었습니다. 이전에는 ‘왜 갑자기 답변이 달라졌는지’를 로그를 일일이 대조하며 추적해야 했지만 지금은 Langfuse 내에서 프롬프트 버전별 품질 곡선을 직접 비교할 수 있어, 변화의 원인을 빠르게 진단하고 즉시 조치할 수 있게 되었습니다.
Langfuse의 또 다른 강점은 LangGraph 워크플로우를 노드 단위로 시각화할 수 있다는 점입니다. 각 단계(검색 → 생성 → 응답)의 출력과 로그가 개별 노드에 기록되어, ‘검색 단계에서 잘못된 문서를 가져온 건지’, ‘생성 단계에서 문맥을 오해한 건지’를 즉시 구분할 수 있습니다. 이 기능은 단순한 로그 열람을 넘어, RAG 전체 파이프라인을 실시간으로 관제하는 운영 도구로 발전했습니다. 특히 오류가 발생했을 때 원인을 빠르게 식별하고, 수정 후 재실험 결과를 Langfuse에서 바로 비교할 수 있어 운영 중단 없이 품질 개선 루프를 유지할 수 있었습니다.
또한, 운영팀은 Langfuse에 쌓인 데이터를 기반으로 품질 리포트 대시보드를 구성했습니다. 대시보드에는 채널별 응답 성공률, 재시도율, LLM-as-a-judge 평균 점수, 그리고 context precision 추세 변화가 함께 표시됩니다. 이 리포트는 단순한 통계가 아니라, 운영 우선순위를 결정하는 핵심 지표로 활용되었습니다. 예를 들어 특정 도메인에서 context precision 점수가 하락하면, 해당 인덱스 구조나 프롬프트를 우선 점검하고, 검색 단계에서 불필요한 문서가 함께 노출되는 경우에는 메타데이터 필터링 로직을 수정하는 식으로 지속적인 개선이 이루어졌습니다.
요약하자면, 본 프로젝트의 운영 단계는 ‘모델을 만드는 일보다, 개선할 수 있는 구조를 만드는 일’에 초점을 맞췄습니다. Langfuse를 중심으로 구축된 이 체계는 단순한 유지보수가 아닌, 지속적인 학습·실험·관제의 엔드투엔드 사이클을 가능하게 했습니다. 이제 모델의 품질은 일회성 개선이 아니라, 데이터 업데이트와 프롬프트 수정, 그리고 평가 결과를 기반으로 지속적으로 성장하는 구조적 자산으로 전환되었습니다. 다음 섹션에서는 이러한 운영 체계를 통해 관찰된 전사적 변화와 실제 임팩트를 다루겠습니다.
결과와 관찰된 변화 : 정량적 성과 중심 분석
ORI 통합 이후, 전사적 활용률이 뚜렷하게 증가했습니다. 통합 이전 오집사는 회사의 맥락을 인식하지 못해 호출 빈도가 낮았으나, ORI가 Slack과 Notion 데이터를 연결하면서 퍼블릭 채널 기준 약 3배 이상 호출량이 증가했습니다. 퍼블릭 채널·개인 메시지·자동화 호출을 모두 포함하면, 3개월간 누적 수천 건 규모의 질의가 처리된 것으로 추산됩니다. 이는 AI 응답이 단순한 참고 단계를 넘어 실제 업무 프로세스 일부로 정착되었음을 보여줍니다.
특히 반복 문의 자동화와 과거 이슈 검색 기능을 통해, 정보보안·정산·플랫폼 등 여러 팀에서 응답 속도 단축과 리소스 절감이 공통적으로 관찰되었습니다. 또한 이 구조는 향후 온보딩 지원이나 운영 기록 요약 등으로 확장할 수 있는 기반이 되었습니다. 예를 들어 신규 담당자가 특정 채널의 과거 대응 이력을 손쉽게 검색하거나, 정책 문서와 사례를 자동 요약해 브리핑받는 기능으로 발전할 여지가 있습니다.
✅ 마치며 : ORI 이후의 과제들
ORI 프로젝트는 ‘모든 사내 지식을 한 번에 탐색할 수 있는 시스템’을 만드는 일을 넘어, 오늘의집이 AI와 데이터를 통해 일하는 방식을 바꾸는 과정이었습니다. Slack과 Notion에 흩어져 있던 의사결정의 흔적을 하나의 파이프라인으로 모으고, RAG를 통해 ‘문서’가 아닌 ‘맥락’을 검색 단위로 전환했으며, Langfuse를 중심으로 실험–평가–관제가 이어지는 운영 루프를 자리 잡게 했습니다. 그리고 이를 오집사와 자동 Q&A로 연결해 실제 업무 흐름 속에서 검증했습니다. 이 과정에서 얻은 가장 큰 인사이트는 ‘좋은 모델을 한 번 만드는 것보다, 조직이 계속해서 개선할 수 있는 구조를 만드는 일이 더 중요하다.’는 것입니다. 앞으로 ORI와 오집사, 그리고 자동 Q&A 프로젝트는 세 가지 축을 중심으로 진화할 예정입니다.
첫째, Slack·Notion을 넘어 Google Workspace, Jira, GitHub 등 더 많은 업무 도구를 연결해 전사 지식의 범위를 넓혀갈 것입니다.
둘째, 팀별 도메인에 특화된 에이전트와 워크플로우를 확장해 각 조직이 자신의 언어와 규칙을 반영한 AI 보조자를 가질 수 있도록 할 계획입니다.
셋째, 신규 합류자 온보딩, 운영 이력 요약, 리스크 징후 탐지처럼 ‘질문을 하기 전에 먼저 필요한 맥락을 제안하는 기능’을 제공하여, 보다 능동적인 지식 시스템으로 나아가고자 합니다.
이 글에서 소개한 ORI는 완성된 결과물이 아니라, 오늘의집이 ‘전사 지식을 어떻게 바라보고, 어떻게 확장해 나갈 것인가’에 대한 하나의 답변이자 출발점입니다. 이 여정에 함께해 준 AI Working Group 구성원들, 그리고 각자의 자리에서 ORI 프로젝트에 기꺼이 참여해 준 모든 동료들께 이 글을 빌려 감사 인사를 전합니다. 앞으로도 오늘의집은 ‘사람이 물어보지 않아도, 회사 안의 지식이 먼저 다가오는 환경’을 만들기 위해 계속 실험하고 개선해 나가겠습니다.
