[기술블로그] EP5. AI 어시스턴트: 품질 개선 도전기

안녕하세요. 키냅스 에서 AI 어시스턴트를 만들고 있는 개발자 신재은이라고 합니다!

이번 글에서는 RAG 기반 AI를 실제 서비스에 적용하면서 겪었던 문제들, 

그리고 특히 응답 속도, 출처 표시 방식, 가독성, 검색 품질같은 것들을 어떻게 개선해나갔는지 공유해보려고 합니다.

“RAG 붙였으니까 이제 답변 잘 나오겠지?”

처음엔 그렇게 생각했습니다.
하지만 현실은 전혀 달랐습니다.

답변은 느렸고,
출처는 불친절했고,
내용은 읽기 힘들었고,
검색은 정확하지 않을 때도 있었습니다.

그래서 오늘은,
이 문제들을 하나씩 해결해나가면서 

AI 응답 품질을 어떻게 개선했는지 정리해보려고 합니다.
(아직도 개선 중이긴 합니다 😅)

[EP5. 핵심 요약]

• 사용자 경험(UX)의 전환
  단순 로딩바 대신 AI 에이전트의 사고 과정(검색, 요약, 생성 등)을 실시간 스테이터스로 노출하여, 대기 시간의 지루함을 신뢰와 기대감으로 전환

• 신뢰 기반의 출처 표시
  답변 하단에 몰아넣던 기존 방식에서 탈피하여 문장·문단 단위로 ‘옆에’ 즉시 출처를 표시, 사용자가 답변의 근거를 즉각 검증할 수 있는 직관적인 UI 구현

• 가독성 및 구조화 전략
  Plain Text의 한계를 극복하기 위해 Markdown 형식을 전면 도입하고 제목, 강조, 리스트 등을 활용함으로써 ‘답변’을 넘어 ‘정리된 문서’ 수준의 가독성 확보

• RAG 검색 품질 고도화
  고정 길이 분할(Fixed Size) 대신 문맥을 유지하는 ‘Semantic Chunking’과 계층적 분할 방식인 ‘Recursive Splitting’을 결합하여, 정보 손실 없는 정교한 데이터 검색 구조 구축

|“로딩 중…” 말고, AI가 뭘 하는지 보여주자

초기 UX는 단순했습니다.

요청 → 로딩 → 결과 출력

하지만 응답이 길어질수록 문제가 드러났습니다.
사용자는 아무 정보 없이 기다려야 했고, 그 시간은 생각보다 길게 느껴졌습니다.

특히 RAG 기반 응답은 검색 → 정제 → 생성 단계를 거치기 때문에 구조적으로 시간이 걸릴 수밖에 없습니다.
그래서 접근을 바꿨습니다.

“어차피 기다려야 한다면, 기다리는 시간을 납득시키자”

우리는 로딩바 대신 에이전트가 지금 무엇을 하고 있는지 보여주기 시작했습니다.

• “회의록 관련 문서를 검색 중입니다…”
  

• “지난주에 작성하신 문서를 찾았습니다. 요약을 진행합니다.”
  

• “요청하신 내용을 기반으로 답변을 생성하고 있습니다.”

이렇게 중간 과정을 스트리밍으로 노출하자, 재미있게도 실제 속도는 같지만 체감은 완전히 달라졌습니다.
사용자는 더 이상 기다린다는 느낌보다 “아, 지금 뭔가 열심히 일하고 있구나”라고 받아들이기 시작했고,
서비스에 대한 신뢰도도 자연스럽게 올라갔습니다.

| 출처는 “아래”가 아니라 “옆에”

초기에는 RAG의 기본적인 방식대로 답변 하단에 참고 문서를 모아서 제공했습니다.
하지만 답변이 길어질수록 문제가 생겼습니다.

“그래서 이 내용은 어디서 나온 거지?”

출처는 있었지만, 내용과의 연결이 명확하지 않았습니다.
그래서 구조를 변경했습니다.
문장 또는 문단 단위로 출처를 바로 옆에 표시하도록 개선했습니다.

• A에 대한 설명입니다. (출처: 문서1)
  

• B에 대한 내용입니다. (출처: 문서2)

이 변화 이후 가장 크게 달라진 것은 사용자의 신뢰였습니다.
답변을 검증하는 속도가 빨라졌고, “근거 있는 답변이다”라는 느낌이 강해졌습니다.
같은 데이터라도 어떻게 보여주느냐에 따라 설득력은 크게 달라진다는 것을 느꼈습니다.

|Plain Text의 한계: 읽히지 않는 답변

초기에는 비용을 아끼기 위해 응답을 전부 plain text로만 처리했습니다.
짧은 답변에서는 문제가 없었지만, 문서를 요약하거나 긴 설명을 생성하기 시작하면서 한계가 드러났습니다.

문단 구분도 없고 강조도 없고 구조도 없는 텍스트는 조금만 길어져도 읽기 어려웠습니다.
그래서 방향을 바꿨습니다.

“이제는 답변이 아니라, 문서를 만들어야 한다.”

우리는 응답을 Markdown 기반으로 전환하고, 제목과 문단, 강조를 명확하게 나누기 시작했습니다.
같은 내용인데도 훨씬 잘 읽혔고, 사용자 입장에서는 “정리가 잘 된 답변”처럼 느껴졌습니다.
흥미로운 점은 모델이 더 똑똑해진 건 아닌데 결과는 더 좋아 보이기 시작했다는 점이었습니다.

| RAG의 핵심: 검색 품질을 결정하는 Chunking

가장 큰 문제는 검색 품질이었습니다.
초기에는 단순하게 접근했습니다.

“일정 글자 수(n) 기준으로 나누자”

구현은 쉬웠지만, 결과는 좋지 않았습니다.
문장이 중간에서 끊기고 문맥이 단절되면서 의미가 왜곡되는 문제가 발생했습니다.
그 결과, 실제로는 관련 없는 문서가 검색되는 경우도 빈번하게 발생했습니다.
아래 이미지는 이러한 차이를 직관적으로 보여줍니다.

Fixed Size Chunking은 일정 길이로 잘리기 때문에 문맥이 고려되지 않고, 문장이 잘리는 문제가 발생합니다.
반면 오른쪽의 Semantic Chunking은 문맥과 의미 단위를 기준으로 데이터를 분할하기 때문에 정보의 흐름이 자연스럽게 유지됩니다.
이 문제를 해결하기 위해 단순한 문자 기반 분할에서 벗어나 Semantic Chunking 기반 구조로 전환했습니다.
Semantic Chunker는 앞뒤 문맥의 유사도를 기준으로 데이터를 나누며, 각 청크가 하나의 의미 단위를 가지도록 구성합니다.
그 결과, 검색 시 문맥이 유지된 상태로 데이터가 활용되면서 관련도 높은 결과를 훨씬 안정적으로 가져올 수 있었습니다.
다만, 의미 단위로 나누다 보면 청크 크기가 과도하게 커지는 문제가 발생할 수 있습니다.

이를 방지하기 위해 추가적인 안전장치를 적용했습니다.
Semantic 기반으로 1차 청킹을 수행한 뒤, 청크 크기가 일정 기준을 초과할 경우 다시 한 번 분할을 수행합니다.
이때는 단순 분할이 아니라, 개행 → 문장 → 단어 순으로 자연스러운 경계를 기준으로 나누는 방식을 사용했습니다.
이 과정에서 RecursiveCharacterTextSplitter를 활용하여 문맥 손실을 최소화하면서도 적절한 크기를 유지하도록 설계했습니다.
결과적으로, 문맥은 유지하면서도 검색 효율까지 고려한 보다 균형 잡힌 청킹 구조를 만들 수 있었습니다

|청크사이즈는 어떻게 설정해야할까?

청킹을 하다 보면 결국 한 번은 이 질문에 부딪히게 됩니다.
이건 단순한 튜닝 포인트가 아니라 RAG 성능을 좌우하는 핵심 요소입니다.
청크 크기가 바뀌는 순간 검색 정확도, 응답 품질, 심지어 응답 속도까지 함께 영향을 받기 때문인데요.

• 너무 작은 경우 (128 토큰 이하)
  청크가 너무 작은 경우를 먼저 보면, 시스템은 마치 문장 하나씩만 기억하는 사람처럼 동작합니다.
  정확한 키워드나 사실은 잘 찾아내지만, 그 정보가 어떤 맥락에서 나온 것인지는 놓치기 쉽습니다.
  실제로 연구에서도 128~256 토큰 수준의 작은 청크는 정확한 fact retrieval에는 강하지만 문맥 이해에는 약하다는 결과가 반복적으로 나타납니다.
  
  

• 너무 큰 경우 (1024 토큰 이상)
  이번에는 하나의 청크 안에 너무 많은 정보가 들어가면서 정작 중요한 내용이 묻히게 됩니다.
  이 경우 LLM은 충분한 컨텍스트를 받긴 하지만, 불필요한 정보까지 함께 처리해야 하기 때문에
  응답 품질이 오히려 떨어지거나, 응답 속도가 느려지는 문제가 발생합니다.
  NVIDIA 실험에서도 너무 작은 청크(128)와 너무 큰 청크(2000+) 모두 성능이 떨어지고,
  중간 크기에서 가장 안정적인 결과가 나왔습니다.

실무에서는 이를 조금 더 단순화해서 문서 성격에 따라 다른 전략을 가져가기도 합니다.

이 값들은 어디까지나 가이드일 뿐이고, 실제로는 서비스에 맞게 직접 실험하면서 조정해야 합니다.

|마무리

이번 개선을 통해 느낀 건 단순했습니다. 좋은 AI는 단순히 “정답을 잘 맞히는 AI”가 아니었습니다.

사용자가 기다리는 시간을 어떻게 설계했는지,
근거를 얼마나 설득력 있게 보여주는지,
얼마나 읽기 쉽게 전달하는지,
그리고 데이터를 얼마나 잘 나누는지까지

이 모든 요소가 함께 맞물릴 때 비로소 “좋은 응답”이 만들어진다는 걸 느낄 수 있었습니다.

아직 갈 길은 멀지만, 꾸준히 개선해나가고 있으니 지켜봐주세요 😄

👉 [kynapse.ai 더 알아보기]