사내 AI 챗봇. 쉽게 보고 도전했다가 박살났습니다.

브라우저를 켜고 Confluence를 검색한다. 문서를 찾는데… 내가 원하는 그 문서가 없다.

“아! 이거 슬랙에서 이야기했었나?” 어딘가에 분명 존재하고, 누군가는 정리해두었을 텐데, 막상 필요할 때는 찾을 수가 없다.

그제야 깨닫게 되었습니다. 문서는 작성도 중요하지만, 검색도 똑같이 중요하다는 사실을요.

안녕하세요. 노머스에서 백엔드 개발자로 근무하고 있는 지승보 입니다.

TL;DR

• 초기 PoC는 성공적이었지만, 실제 운영에서 벡터 검색의 한계, 청킹 전략, 할루시네이션 등 다양한 문제에 직면
• Query Rewrite, Re-ranking, Hierarchical 임베딩 등으로 검색 품질을 개선하고, 최종적으로 Google Vertex AI로 전환하여 운영 부담 감소
• Confluence용 Atlassian Rovo의 발전으로 방향성을 재설정: Slack 대화 자산화와 신규 입사자 온보딩에 집중

키워드: RAG, 벡터 검색, 임베딩, 청킹 전략, Vertex AI, 사내 AI 챗봇

---

목차

1. “내가 원하는 문서를 대신 찾아주는 챗봇이 있다면 어떨까?”
2. 임베딩과 벡터 DB를 이용한 기본 RAG 만들기
3. 야심차게 시작한 프로젝트와 RAG의 현실적인 문제들
4. 그래서 찾게 된 해결책: Google Vertex AI
5. Confluence → GCS 동기화 코드 작성
6. 현재의 노비스 구조 (Playbook 기반)
7. 그리고 앞으로의 노비스 방향성
8. 마무리하며

---

“내가 원하는 문서를 대신 찾아주는 챗봇이 있다면 어떨까?”

2025 토스 메이커스 컨퍼런스에서 문서 시스템에 대한 세션을 듣다가, “회사 정보 특화 챗봇”을 실제로 운영하고 있는 사례를 처음 보게 되었습니다.

그전까지는 그냥 막연히 “있으면 좋겠다” 정도로만 생각하던 아이디어였는데, 그 세션을 통해 몇 가지를 동시에 깨달았습니다.

• 문서는 검색 가능해야 하고, 주기적으로 업데이트되어야 진짜 의미가 있다는 것
• RAG를 활용한 검색 봇이 실제 업무 환경에서 어떻게 쓰일 수 있는지에 대한 구체적인 그림
• 단순 편의성을 넘어서, 질문 허들을 낮추면 신규 입사자의 부담감까지 줄일 수 있다는 점

그때부터 머릿속에 이런 상상이 구체적으로 그려지기 시작했습니다.

만약 자연어로 질문만 던져도 사내 문서들을 빠르게 검색해주는 사내 전용 ChatGPT 같은 챗봇이 있다면 어떨까?

여기에 제가 특히 기대했던 것은 “질문하는 것 자체의 허들을 낮출 수 있지 않을까?” 하는 부분이었습니다.

• “이걸 물어봐도 되나?”
• “누구한테 물어봐야 하지?”
• “혹시 너무 기초적인 질문이면 어쩌지…”

같은 고민 없이, 일단 노비스에게 먼저 편하게 물어볼 수 있는 환경을 만들고 싶었습니다.

이때 처음으로 RAG(Retrieval-Augmented Generation)라는 개념도 알게 되었고,

• 왼손에는 ChatGPT
• 오른손에는 Cursor

가 있었으니, “한 번쯤은 직접 만들어봐도 되겠다”는 생각이 들었습니다.

이렇게 해서 노비스(Knowbis) 프로젝트가 시작되었습니다.

---

임베딩과 벡터 DB를 이용한 기본 RAG 만들기

처음 버전의 구조는 정말 단순했습니다. “일단 돌아가기만 하자”에 가까운, 그야말로 초기 PoC(Proof of Concept)였습니다.

• Slack 대화나 문서를 LLM으로 한 번 정리해서 텍스트로 만든 뒤
• 임베딩 모델로 벡터를 생성하고
• 벡터 DB(Qdrant)에 저장하고
• 나중에 질문이 들어오면, 질문을 임베딩해서 비슷한 벡터를 찾고
• 다시 LLM을 이용해 최종 답변을 만드는 구조였습니다.

PoC는 꽤 인상적이었습니다. Slack으로 TMI를 공유하는 채널을 통해 이런걸 해보았다고 공유하였고, 반응이 좋았습니다.

• “슬랙봇으로 연동되면 전사에서 다 쓸 수 있을 것 같다”는 피드백과 함께,
• 실제로 컨플루언스/슬랙/노션을 묶어서 질문의 허들을 낮추는 방향으로 가 보자는 이야기까지 나왔습니다.

비용 구조를 간단히 정리해 공유했을 때도, “이 정도면 충분히 시도해볼 만하다”는 반응이 많았습니다. 그래서 당시에는 저도 “조금만 더 다듬으면 곧바로 실서비스로 써볼 수 있겠는데?”라고 생각했습니다.

RAG와 청크(Chunk)란?

본격적인 시행착오를 이야기하기 전에, 이해를 돕기 위해 RAG와 청크(Chunk) 의 개념을 간단히 정리하겠습니다.

RAG(Retrieval-Augmented Generation)

RAG는 기존 LLM의 한계(최신 정보 미반영, 지식 한계 등)를 극복할 수 있는 대표적 방법론입니다.

장점

• 최신성 확보: 사전 학습 데이터에 없는 최신 문서/정보도 검색을 통해 반영할 수 있습니다.
• 정확성 향상: 문서를 근거로 답변을 생성하므로, LLM이 사실에 기반하지 않고 혼자 상상(hallucination)하는 일을 줄일 수 있습니다.
• 유연함과 확장성: 데이터 소스(위키, 슬랙, 노션 등)만 늘리면 비교적 손쉽게 새로운 지식을 반영할 수 있습니다.
• 용량 한계 극복: LLM 파라미터로 포함할 수 없는 대용량 지식도 외부 DB에 무제한 저장해 활용할 수 있습니다.

단점

• 검색 품질 의존: 벡터 검색이 원하는 내용을 못 찾거나, 핵심 맥락을 놓칠 경우 답변도 부정확해질 수 있습니다.
• 청크 전략 필요: 문서를 어떻게 쪼개느냐(청킹)에 따라 검색 결과와 답변 품질이 크게 달라집니다.
• Latency 증가: 검색 -> 생성의 추가 과정 때문에 순수 LLM 답변보다 응답 시간이 길어질 수 있습니다.
• 운영 복잡성: 외부 DB, 인덱싱, 파이프라인 운영 등 추가적인 인프라 관리가 필요합니다.

요약하면, RAG는 LLM의 활용도를 크게 높여주는 솔루션이지만, 검색 품질과 운영 복잡성에 유의하면서 설계/운영해야 최대 효과를 볼 수 있습니다.

RAG의 기본 구조

1. 사용자가 “A 에러 해결 방법 알려줘”처럼 자연어 질문을 입력한다.
2. 이 질문을 임베딩(벡터화)하여 벡터 DB에 질의한다.
3. 질문과 의미적으로 유사한 문서 조각(청크)들을 여러 개 가져온다.
4. 이 청크들을 LLM에게 함께 넘기고 “이 내용을 참고해서 답변을 만들어줘”라고 요청한다.

즉, LLM이 자체적으로만 답변을 생성하는 것이 아니라, 검색된 문서 청크들을 실제 근거로 활용하며 답변을 만들어내는 패턴입니다.

청크(Chunk)와 임베딩

문서 전체를 통째로 임베딩하지는 않습니다. 그 이유는, 보통 하나의 문서가 너무 길어서 임베딩 모델의 입력 한도를 초과하는 경우가 많고 설령 한 번에 임베딩할 수 있다고 해도 문서 전체의 의미가 질문과 딱 맞게 대응되기 어렵기 때문입니다.

예를 들어, 사용자가 특정 오류 코드, 기능, 예시와 관련된 질문을 던졌을 때 문서 전체 임베딩 벡터와의 유사도만으로는 원하는 정확한 내용을 제대로 찾지 못할 가능성이 큽니다.

또, 답변 생성시 LLM에 통째로 긴 문서를 넘길 수도 없어 효율적이지 않습니다. 따라서 문서를 작은 조각(청크)으로 쪼개서 임베딩해야 질문에 더 잘 맞는, 핵심적인 정보 덩어리만을 효과적으로 검색해 올 수 있습니다.

실제 구현은 다음과 같습니다:

1. 문서 저장소에 있는 원문을 여러 조각(청크) 으로 나눈다.
2. 각 청크를 임베딩 모델에 넣어, 벡터(숫자 배열) 로 변환한다.
3. 이 벡터들을 벡터 DB(Qdrant 등)에 저장해 둔다.

이후 질문이 들어오면,

1. 질문 역시 임베딩 벡터로 변환하고
2. “질문 벡터와 가장 비슷한 청크 벡터”들을 찾아온 뒤
3. 그 청크들을 LLM에 함께 넘겨 답변을 생성하게 합니다.

이 과정에서 특히 중요한 포인트는 문서를 어떻게 쪼개느냐(청킹 전략) 에 따라 검색 품질, 답변의 구체성, 그리고 할루시네이션 발생 여부까지 크게 달라진다는 것입니다. 이 글에서 다루는 “벡터 검색 문제”, “문단 단위 청킹의 한계”, “Hierarchical 임베딩” 등의 주제는 모두 이 청킹 + 검색 구조에 얽힌 이슈들입니다.

---

야심차게 시작한 프로젝트와 RAG의 현실적인 문제들

Slack 봇으로 연결해 실제로 사람들이 질문을 던지도록 해보니, 그때부터 이상적인 RAG와 현실의 RAG 사이의 갭이 하나씩 드러나기 시작했습니다.

아래 문제들은 대부분 “RAG 검색에서 자주 겪는 고전적인 문제들”이었고, 저도 똑같이 밟으면서 하나씩 체감하게 되었습니다.

---

1) “에러” 같은 일반 단어에 묻혀버리는 벡터 검색 문제

예를 들어 Slack에서 이렇게 묻는 경우가 있습니다.

“A 에러 해결 방법 알려줘”

이 질문을 임베딩해서 벡터 검색을 하면, “A 에러”보다는 “에러”라는 일반적인 단어가 더 강하게 작동하는 경우가 종종 있었습니다.

그 결과:

• 정작 필요한 A 에러 관련 문서 대신
• B 에러 해결 방법이 상단에 올라오는 일이 자주 발생했습니다.

문제는 여기서 끝이 아니었습니다. 상위로 검색된 B 에러 문서 청크에는,

“B는 어떤 에러다”

같은 정의 문장조차 없는 경우도 많았습니다. 그러다 보니 LLM 입장에서는,

• “에러 해결 방법을 묻고 있다”는 것만 보고
• “현재 컨텍스트 안의 B 에러 해결책”을
• 마치 A 에러 해결책인 것처럼 자연스럽게 말해버리는, 전형적인 할루시네이션이 자주 발생했습니다.

이 문제를 줄이기 위해 다음과 같은 시도를 했습니다.

• 질문을 그대로 임베딩하는 대신, 에러 코드, 서비스명, 기능명 등을 더 강조한 Query로 재작성(Query Rewrite)
• 벡터 검색 결과에 대해 한 번 더 re-ranking을 수행하여, 단순히 “에러”라는 단어가 많이 들어간 청크보다 문맥이 더 잘 맞는 청크를 상단에 노출

이렇게 하면서 “전혀 엉뚱한 문서로 가는 경우”를 어느 정도 줄일 수 있었습니다.

---

2) 단순 문단 단위 청킹의 한계

GitHub Action을 통해 마크다운 문서를 벡터화해서 저장하는 파이프라인을 만들었는데, 처음에는 문서를 단순히 문단 단위로 청킹했습니다.

이 방식의 문제는 앞뒤 문맥이 잘려 나간 상태로 임베딩되다 보니 검색은 그럭저럭 되지만, 정답으로 쓰기에는 문맥이 너무 부족하다는 점이었습니다.

예를 들어 “A 에러 해결 방법” 문서가 다음과 같이 구성되어 있다고 해보겠습니다.

• 위쪽 문단: A 에러의 정의, 발생 조건, 증상
• 아래쪽 문단: A 에러 해결 절차, 주의 사항, 예외 사항

그런데 아래쪽 문단만 따로 청킹되어 검색되면, LLM은 “이게 어떤 에러의 해결책인지”를 모른 채 답변을 생성하게 됩니다. 이는 앞서의 A/B 에러 혼동 문제와 결합하면서, 에러는 맞는데 뭔가 미세하게 틀린 답변이 자주 만들어지는 원인이 되었습니다.

그래서 청킹 전략을 바꾸었습니다.

• 청킹 시 앞·뒤 문맥을 일정 길이만큼 오버랩(overlap) 시키고
• 제목/섹션 정보는 가능하면 같은 청크 안에 포함되도록 조정했습니다.

이렇게 하니, 적어도:

• “이 청크가 어떤 에러의 이야기인지”
• “어떤 섹션(원인/해결방법/주의사항)에 해당하는지”

정도는 LLM이 더 잘 이해할 수 있게 되었습니다.

---

3) Hierarchical 임베딩 – 부모/자식 청크 구조 도입

단순 오버랩만으로는 부족하다고 느껴져서, Hierarchical 임베딩 구조도 함께 도입했습니다.

• 상위 레벨(부모 청크): 문서 전체를 거칠게 요약한 상위 개념 청크
• 하위 레벨(자식 청크): 실제 답변에 사용될 세부 내용 청크

검색 시에는:

1. 먼저 부모 청크들을 대상으로 거친 필터링을 하고
2. 그 안에서 자식 청크에 대해 세밀한 검색을 하는 구조로 바꾸었습니다.

이 구조로 바꾸고 나서 얻은 장점은:

• 질문과 완전히 상관없는 문서가 검색되는 비율이 줄어들고
• 같은 문서 안에서도 질문과 더 잘 맞는 부분을 찾기 쉬워진다는 점이었습니다.

결과적으로:

• “뜬금없는 문서에서 답변이 나오는 문제”
• “정확히는 아니지만 얼추 비슷해 보이는 답이 나오는 문제”

가 눈에 띄게 줄어들었습니다.

---

4) Slack → 문서 자동 생성 단계에서의 할루시네이션

검색뿐만 아니라, 문서 생성 단계에서도 할루시네이션은 계속해서 문제가 되었습니다.

Slack 대화를 기반으로 LLM이 문서 초안을 자동 생성할 때,

• 사용자가 여러 날에 걸쳐 조금씩 설명했거나
• 중간에 대화 주제가 바뀌는 경우

LLM이 빈 부분을 그럴듯한 내용으로 채워 넣는 일이 자주 발생했습니다. (흔히 할루시네이션이라 부르는 현상입니다.)

초기에는 이 문제를 해결하기 위해 Slack Block UI를 활용했습니다.

• “이 내용이 맞나요?”
• “수정할 부분이 있나요?”

와 같은 형태로 유저에게 직접 확인을 받았지만, 블록 UI 특성상 긴 문서를 검토하고 수정하기에는 UX가 너무 좋지 않았습니다.

그래서 흐름을 다음과 같이 바꾸었습니다.

1. Slack 대화를 기반으로 마크다운 문서 초안을 생성
2. 이 초안을 GitHub 저장소에 PR 형태로 올리기
3. 실제 작성자 또는 관련자가 GitHub 리뷰 플로우 안에서 수정/코멘트

이렇게 바꾸고 나니:

• LLM이 작성한 초안을 반드시 사람이 한 번 검토하게 되고
• 잘못된 부분을 PR 리뷰 과정에서 자연스럽게 수정할 수 있어 운영 환경에 들어가는 문서의 품질과 신뢰도를 한 단계 끌어올릴 수 있었습니다.

---

여기까지 오고 나니, 또 다른 고민이 생겼습니다.

“이 모든 파이프라인과 인프라를 앞으로도 계속 직접 관리하는 게 맞을까?”

• 임베딩/검색/LLM 모델의 선택과 버전 업그레이드
• 청킹/검색 전략이 바뀔 때마다 전체 파이프라인을 재배포해야 하는 부담
• 문서가 쌓일수록 커지는 인프라 비용과 모니터링/운영 복잡도
• 기존 업무도 바쁜데 이것까지 운영한다면..

를 생각하다 보니,

“검색 + LLM”이라는 공통 문제를 어느 정도는 관리형 서비스에 맡기고, 우리는 도메인 지식과 경험 설계에 더 집중하는 게 좋지 않을까?

라는 생각이 자연스럽게 들었습니다.

그때 대안 중 하나로 검토하게 된 것이 바로 Google Cloud Vertex AI였습니다.

---

그래서 찾게 된 해결책: Google Vertex AI

여러 시행착오를 거치며, “우리가 직접 붙잡고 있을 부분”과 “플랫폼에 맡길 부분”을 나누는 것이 필요하다고 느꼈습니다.

그 과정에서 Vertex AI를 알게 되었고, 다음 요소들을 고려하여 도입을 결정했습니다.

Vertex AI의 장점

• GCS에 저장된 비정형 문서를 자동으로 수집·파싱·임베딩
• Conversational Agent에서 벡터 검색 + LLM 호출 파이프라인을 설정 위주로 구성 가능
• 모니터링, 로깅, 권한 관리 등이 GCP 콘솔 안에서 어느 정도 일원화되어, 운영 복잡도가 줄어듦
• 장기적으로는, 임베딩/검색/LLM 모델이 개선될 때 플랫폼 레벨에서 업그레이드 혜택을 받기 쉬움

물론 단점도 분명히 있습니다.

Vertex AI의 단점

• 세부 동작을 직접 제어하기에는 커스터마이징에 제약이 있습니다.
• 임베딩 모델, 검색 전략, 청킹 로직을 100% 마음대로 변경하기보다는 제공되는 옵션 안에서 적절히 타협해야 합니다.
• 쿼리 흐름이 내부에서 어떻게 흘러가는지 완전히 투명하지 않아, 디버깅 시 로우레벨 로그를 파고들기 어렵다는 점도 있습니다.
• 특정 클라우드(GCP)에 대한 락인(Lock-in) 역시 감안해야 합니다.

그럼에도 불구하고, “우리가 지금 당장 해결하고 싶은 문제”와 “앞으로 줄이고 싶은 운영 부담”을 고려했을 때, Vertex AI는 충분히 검토할 가치가 있는 선택지였습니다.

---

Confluence → GCS 동기화 코드 작성

Vertex AI의 Datastore는 GCS에 저장된 비정형 데이터를 기반으로 임베딩과 검색 인덱싱을 수행합니다. 즉, 우리 문서의 ‘진실의 근원’을 GCS에 두는 구조가 되는 셈입니다.

그래서 자연스럽게 “Confluence → GCS” 파이프라인을 어떻게 만들지 고민하게 되었고, 처음에는 Airbyte 같은 오픈소스 ETL 툴도 시도해보았습니다.

하지만 몇 가지 한계가 있었습니다.

• Confluence의 계층 구조(스페이스, 페이지, 버전)를 노비스가 필요한 수준으로 세밀하게 반영하기 어려웠습니다.
• 문서 포맷도 노비스에 적절한 html 포맷, 상위 하위문서 관계도 등을 동기화순간에 넣어주기 어려웠습니다.
• 장기적으로 봤을 때, 우리 쪽에서 원하는 대로 커스텀하기에는 직접 만드는 편이 더 낫겠다는 판단이 들었습니다.

그래서 최종적으로는 Confluence Sync Job을 직접 구현하게 되었습니다.

노비스의 Confluence → GCS 동기화 흐름은 대략 다음과 같습니다.

1. Confluence REST API를 이용한 증분 동기화
   • 마지막 동기화 시점 이후로 변경된 페이지만 수집합니다.
   • last_modified 기준으로 새로 생성/수정/삭제/이동된 페이지를 가져오고, 삭제/이동된 페이지도 감지해서 GCS 쪽에서도 상태를 최대한 맞춥니다.
2. 텍스트/마크다운 변환
   • Confluence의 리치 텍스트/매크로 구조를 가능한 한 단순한 텍스트/마크다운으로 변환합니다.
   • 페이지 제목, 링크, 스페이스 정보 등은 메타데이터로 따로 저장합니다.
3. GCS 업로드
   • gs://.../space-key/page-id/version 형태의 경로로 저장해, 나중에 문제가 생겼을 때 “어느 문서의, 어느 버전에서 온 것인지” 추적하기 쉽게 만들었습니다.
4. Cloud Run 기반 자동 동기화 Job 운영
   • 일정 주기마다 동기화 Job이 실행되어 변경분을 수집합니다.
   • 실패 시 재시도, 알림 등을 Cloud Run + Cloud Scheduler 조합으로 처리합니다.

이렇게 쌓인 문서들은 GCS에 저장되고, Vertex AI가 해당 버킷을 바라보며 임베딩 + 검색 인덱싱을 수행하게 됩니다.

---

현재의 노비스 구조 (Playbook 기반)

현재의 노비스는 단순한 “질문 → 검색 → 답변” 구조에서 조금 더 진화해, Vertex AI Agent Builder의 Playbook 기능을 사용하여 대화의 흐름을 정교하게 제어하고 있습니다.

현재 노비스 Playbook의 핵심은 “LLM에게 명확한 역할(Role)과 제약(Constraint)을 주는 것”입니다.

1) Rewriter: “검색하기 좋은 질문”으로 번역하기

사용자는 보통 이렇게 질문합니다.

“그… SQS DLQ 설정 어떻게 하더라?”

하지만 이 문장을 그대로 벡터 검색에 넣으면 ‘어떻게’, ‘하더라’ 같은 불필요한 단어들이 유사도에 영향을 줍니다. 그래서 Rewriter라는 별도 Playbook을 두어 검색 전용 쿼리로 변환하도록 했습니다.

# Rewriter Instruction 발췌
- Output **one Korean line**, noun-heavy
- Drop particles & relative time ("최근/이번")
- Prepend system/product if clear.

• Noun-heavy (명사 중심): 조사를 제거하고 핵심 키워드만 남깁니다.
• 단일 라인 출력: 검색 엔진에 들어갈 깔끔한 한 줄만 뱉어내게 합니다.
• 문맥 유지: 이전 대화 턴(Turn)을 참고하여 대명사를 구체적인 명사로 치환합니다.

그 결과 "SQS DLQ 설정 어떻게 해?"는 → SQS DLQ 설정 가이드라는 깔끔한 쿼리로 변환되어 검색 엔진으로 전달됩니다.

2) Datasource: Filter 전략

처음에는 효율성을 위해 “백엔드 질문은 백엔드 스페이스에서만 검색”하도록 필터를 걸려고 했습니다. 하지만 문서는 생각보다 파편화되어 있었습니다.

• 백엔드팀 스페이스가 아니라 기획팀 스페이스에 API 명세가 있기도 하고
• 최신 아키텍처 결정사항(ADR)이 프로젝트 스페이스에 숨어 있기도 했습니다.

그래서 Datasource Tool에는 CRITICAL: DO NOT use filters 라는 지침을 박아넣었습니다. Project, FE, Mobile, BE 등 모든 팀의 스페이스를 한 번에 훑는 것이, 놓치는 문서를 줄이는 가장 확실한 방법이었기 때문입니다.

3) Answer Generation: “최신성과 사실성”

검색된 문서를 바탕으로 답변을 생성할 때 가장 큰 문제는 “옛날 문서”와 “할루시네이션”이었습니다. 이를 해결하기 위해 Summarizer와 Answer Playbook에 엄격한 규칙을 적용했습니다.

# Answer Instruction 발췌
- Newest wins on conflicts (`lastModified`).
- Keep **verbatim**: numbers, dates, paths, code, URLs.
- De-dup by `pageId`.

• Newest wins: 내용이 충돌하면 무조건 lastModified가 최신인 문서를 따릅니다.
• Verbatim (있는 그대로): 숫자, 날짜, 코드 경로, URL은 절대 요약하거나 바꾸지 말고 원문 그대로 가져오게 강제합니다.
• Slack-style Citation: 답변의 근거가 된 문서는 반드시 <...|Title> 포맷으로 출처를 남겨, 사용자가 직접 원문을 확인할 수 있게 했습니다.

이러한 제약 조건들 덕분에 노비스는 “그럴듯한 거짓말” 대신, “근거 있는 답변”을 할 수 있게 되었습니다.

4) 모델 선정의 시행착오: Gemini 2.5 Flash vs Flash Lite

비용 효율화를 위해 처음에는 Gemini 2.5 Flash Lite 모델을 도입했습니다. “단순히 문서를 보고 답변하는 거니까 Lite 모델로도 충분하겠지”라고 생각했기 때문입니다.

하지만 결과는 기대에 미치지 못했습니다. Playbook에 적어둔 꽤 복잡한 지시사항(Instruction)을 모델이 완벽하게 소화하지 못하는 느낌을 강하게 받았습니다.

• “원문을 그대로 인용하라”는 제약을 무시하고 말을 바꾸거나
• 문서 간의 우선순위 규칙(lastModified)을 놓치는 경우가 빈번했습니다.

결국 다시 Gemini 2.5 Flash로 모델을 교체했고, 거짓말처럼 답변의 품질과 지시 이행률(Instruction Following)이 정상 궤도로 돌아왔습니다. 복잡한 제약 조건이 많은 RAG 시스템에서는, 일정 수준 이상의 추론 능력을 가진 모델이 필수적이라는 것을 다시 한번 확인한 계기였습니다.

---

그리고 앞으로의 노비스 방향성

노비스를 개발하며 Vertex AI 기반의 검색 시스템을 구축하는 동안, 한편으로는 우리가 사내 문서 시스템으로 사용하는 Confluence 자체의 AI 기능도 빠르게 진화하고 있었습니다.

처음 Atlassian Rovo를 봤을 때는 “현재 보고 있는 페이지 안에서만 조금 도와주는 보조 도구” 정도의 느낌이었습니다.

당시에는:

• 단일 페이지 내에서의 요약 기능
• 간단한 질문에 대한 답변 정도

하지만 조금씩, 꾸준히 업데이트가 이루어지면서 이전에는 안 되던 것들이 하나씩 가능해지기 시작했습니다.

• 여러 Space를 동시에 검색하는 기능이 추가되고
• 문서 간의 관계를 이해하며 답변을 생성하게 되고
• 이제는 문서를 넘나들며 종합적인 요약까지 제공하는 수준으로 발전했습니다

점점 노비스가 해결하려던 Confluence 문서 검색과 답변 생성 문제와 역할이 겹치기 시작한 것입니다.

어느 순간 이런 생각이 들었습니다.

“이 속도라면, Confluence 문서 검색은 굳이 노비스가 아니라 Rovo로도 충분한 거 아닐까?”

AI 기술의 발전 속도와 경쟁이 얼마나 치열한지 직접 체감하게 되었습니다.

Rovo가 Confluence 문서 검색을 잘 해주게 된 덕분에, 노비스는 Rovo가 커버하지 못하는 영역에 더 집중해야 합니다.

Confluence 외에도 우리 회사에는 Slack, GitHub, Notion 등 다양한 정보 저장소가 있고, 특히 Slack 대화는 체계적으로 정리되지 않은 채 사라지는 경우가 많습니다.

그래서 노비스는 다음과 같은 방향으로 발전시키려 합니다.

1) Slack 대화 자산화 파이프라인

Slack에서는 다양한 대화가 오가지만, 하나하나를 문서로 정리하기란 쉽지 않습니다. 그런데 이렇게 쌓이는 대화 안에는 무시할 수 없는 꿀팁들이 많죠. 문제는, 이런 정보들이 Slack 안에만 묻혀 있다 보면 쉽게 사라지고 동료에게 잘 전달되지 않는다는 점입니다.

이런 소중한 대화들이 자연스럽게 회사의 자산으로 남을 수 있도록 파이프라인을 만들고자 합니다.

• 문서화가 필요한 대화: 의미 있는 대화는 요약해서 Confluence 문서 초안으로 자동 생성해, 작성자가 처음부터 전부 쓸 필요 없이 손쉽게 정리할 수 있게 합니다.
• 문서화가 애매한 경우: 간단한 Q&A처럼 즉석에서 오간 정보들은 별도의 지식 베이스로 정리해둡니다.

이렇게 모인 데이터 덕분에, 비슷한 질문이 나왔을 때 예전 기록을 참고하여 빠르게 답을 찾거나, 검증된 해결 방법을 쉽게 전파할 수 있습니다.

2) 신규 입사자를 위한 온보딩 챗봇

신규 입사자일수록 이런 고민을 자주 하게 됩니다.

• “이걸 물어봐도 되는 걸까?”
• “누구에게 물어봐야 하지?”
• “어디 문서에 정리되어 있는지 모르겠다…”

노비스는 그런 순간에 가장 먼저 부담 없이 질문할 수 있는 상대가 되는 것을 목표로 하고 있습니다.

노비스가 모든 답을 다 알지 못하더라도,

• 질문과 그에 대한 시도된 답변이 남고
• 이를 본 다른 동료가 더 좋은 답을 이어 쓸 수 있고
• 그 과정이 다시 지식으로 축적되는 흐름

자체가 의미가 있다고 느끼고 있습니다.

---

마무리하며

노비스를 만들면서 많은 시행착오와 고민이 있었습니다. 벡터 검색, LLM의 답변, 점점 복잡해지는 인프라 등 쉽지 않은 도전이었지만, 그 과정에서 얻은 경험과 교훈은 앞으로 새로운 서비스와 비즈니스 개발에 밑거름이 될 것이라 생각합니다.

읽어주셔서 감사합니다!