D-ask를 왜 다시 만드는가: v1에서 v2로

About this offer

D-ask는 내가 처음으로 진행했던 프로젝트다. 1학년 때 처음 만들었던 프로젝트를 지금 다시 꺼내 v2라는 이름으로 처음부터 다시 만들고 있다. 왜 이미 한 번 만들었던 프로젝트를 다시 만들게 되었는지, 그리고 이번에는 무엇을 다르게 해보고 싶은지 정리해보려고 한다. 1. D-ask v1은 왜 시작했는가 학교생활을 하다 보면 학교 홈페이지에 올라온 문서를 찾아볼 일이 종종 있다. 하지만 필요한 정보가 여러 공지와 문서에 흩어져 있다 보니 학생들이 매번 직접 문서를 찾아 내용을 확인해야 했다. 그래서 이런 생각에서 D-ask를 시작했다. 학교 문서가 한곳에 모여 있고, 학생이 직접 문서를 찾는 대신 질문만 하면 필요한 정보를 알려줄 수 없을까? 이 문제를 해결하기 위해 학교 문서를 수집하고, 문서를 기반으로 학생의 질문에 답변하는 서비스를 만들어보기로 했다. 그게 D-ask v1의 시작이었다. 2. v1에서는 무엇을 만들었는가 D-ask v1에서는 RAG를 이용해 학교 문서를 기반으로 답변하는 Q&A 챗봇 을 만들었다. 사용자가 질문하면 관련된 학교 문서를 검색하고, 검색한 내용을 LLM에 전달해 답변을 생성하는 방식이었다. 당시에는 RAG를 직접 구현하고 실제 학교 문서를 이용해 답변이 생성되는 것만으로도 신기했다. 하지만 프로젝트를 진행하면서 여러 문제를 만나기 시작했다. 문서 안에 분명 답이 있는데 관련 내용을 제대로 검색하지 못하는 경우가 있었고, 검색 결과가 있어도 답변 생성 과정에서 문제가 발생하기도 했다. 그때의 나는 이런 문제가 발생하면 주로 한 가지를 생각했다. “어떻게 하면 일단 이 문제를 해결할 수 있을까?” D-ask v1 프로젝트 회고 3. 만들고 나서 어떤 한계와 의문을 느꼈는가 대표적인 사례가 임베딩 모델이었다. 검색이 제대로 되지 않는 문제가 발생했을 때, 당시 사용하던 임베딩 모델이 한국어 문서를 충분히 잘 처리하지 못한다고 판단했다. 그래서 한국어 성능이 더 좋다고 알려진 다른 임베딩 모델로 교체했다. 모델을 변경한 뒤 당시 문제가 발생했던 일부 질문에서는 이전보다 정상적으로 검색되는 것을 확인할 수 있었다. 그런데 지금 다시 생각해보면 여기에는 문제가 있었다. 왜 그 모델이어야 하는지 설명할 수 없었다. 모델 A보다 모델 B가 정말 전체적으로 검색을 더 잘하는지 측정하지 않았다. 어떤 종류의 질문에서 얼마나 좋아졌는지도 알 수 없었다. 결국 당시의 선택 과정은 이랬다. 문제 발생 ↓ 다른 모델로 교체 ↓ 잘 되는 것 같음 ↓ 채택 지금 생각하면 모델을 바꾸기 전에 먼저 이런 질문을 했어야 했다. 현재 검색 성능이 실제로 얼마나 나쁜가? 모델을 바꿨을 때 얼마나 좋아졌는가? 그 차이를 무엇으로 판단할 것인가? 하지만 v1에는 이 질문에 답할 수 있는 평가 기준이 없었다. 돌아가는 것과 운영할 수 있는 것은 달랐다 평가만의 문제도 아니었다. D-ask v1은 챗봇 자체는 동작했지만, 프로젝트를 완성하고 나니 한 번 동작하는 RAG를 만드는 것과 지속적으로 운영할 수 있는 서비스를 만드는 것은 다른 문제 라는 생각이 들었다. 새로운 학교 문서가 추가되거나 기존 문서가 수정되면 이를 어떻게 반영할 것인지에 대한 구조가 부족했다. 검색 방식을 변경했을 때 이전보다 정말 좋아졌는지 검증하기도 어려웠다. 오류가 발생했을 때도 원인이 문서 파싱인지, 검색인지, 임베딩인지, 답변 생성인지 명확하게 분리해서 판단하기 어려웠다. 무엇보다 프로젝트에서 했던 여러 기술 선택에 대해 “왜 이렇게 했나요?” 라는 질문을 받았을 때 충분한 근거를 제시하기 어려웠다. 처음 만드는 프로젝트였던 만큼 일단 기능을 완성하는 데 집중했고, 평가와 운영은 그다음 문제라고 생각했기 때문이다. 4. 왜 v1을 고치는 대신 v2를 시작했는가 처음에는 v1을 계속 수정하는 것도 생각했다. 하지만 다시 생각해보니 바꾸고 싶은 것은 임베딩 모델 하나나 특정 기능 하나가 아니었다. 문서를 어떻게 준비할 것인지부터 검색 결과를 어떻게 평가할 것인지, 모델을 어떤 기준으로 선택할 것인지, 문제가 발생하면 어떻게 찾아낼 것인지까지 프로젝트를 만드는 방식 자체를 바꿔보고 싶었다. 기존 프로젝트에 기능을 하나씩 덧붙이기보다 v1을 만들면서 생긴 의문들을 가지고 처음부터 다시 설계해보기로 했다. 그래서 D-ask v2를 개인 프로젝트로 다시 시작했다. 5. v2에서는 무엇을 다르게 해보고 싶은가 v2의 목표는 단순히 v1보다 기능이 많은 챗봇을 만드는 것이 아니다. 이번에는 내가 내린 기술적인 결정을 측정하고 설명할 수 있는 서비스를 만드는 것 을 목표로 잡았다. 예를 들어 임베딩 모델을 선택한다면 단순히 유명하거나 성능이 좋다고 알려진 모델 하나를 가져오는 방식으로 결정하지 않으려고 한다. 여러 후보를 선정하고 동일한 데이터와 평가 기준으로 비교한 뒤, 실제 측정 결과를 근거로 선택하려고 한다. Chunking, Retrieval, Reranking, LLM 같은 다른 요소도 같은 방식으로 접근하고 싶다. 후보 선정 ↓ 동일한 조건에서 실험 ↓ 성능 측정 ↓ Trade-off 비교 ↓ 기술 선택 ↓ 선택한 이유 기록 그래서 D-ask v2에서는 RAG 파이프라인부터 빠르게 구현하지 않았다. 먼저 Golden Dataset을 만들고, 평가 기준을 정의하고, 동일한 조건에서 여러 방법을 비교할 수 있는 Benchmark 환경을 만드는 작업 부터 시작했다. 이 과정은 다음 글에서 자세히 다뤄보려고 한다. 그리고 이번에는 개발에서 끝내지 않고 실제 서비스까지 만들어보는 것 도 목표로 하고 있다. v1처럼 “챗봇이 동작한다”에서 프로젝트를 끝내는 것이 아니라, 실제로 배포해 사용자가 사용할 수 있는 형태로 만들고 싶다. 6. D-ask v2를 통해 무엇을 배우고 검증하고 싶은가 D-ask v2를 통해 처음부터 완벽한 RAG 시스템을 만드는 것이 목표는 아니다. 오히려 실제로 서비스를 운영하면서 다음 과정을 경험해보고 싶다. 배포 ↓ 사용 ↓ 문제 발견 ↓ 원인 분석 ↓ 개선 ↓ 다시 측정 내가 선택한 임베딩 모델이 정말 적절했는지, Retrieval 방식을 변경했을 때 실제로 검색 성능이 좋아지는지, 검색 성능의 개선이 최종 답변 품질의 개선으로 이어지는지 직접 측정하고 검증해보고 싶다. 그리고 배포 이후에는 개발하면서 예상하지 못했던 문제도 실제 사용자와 데이터를 통해 발견해보고 싶다. 결국 이번 프로젝트에서 경험하고 싶은 것은 단순히 RAG를 구현하는 방법 만은 아니다. 문제를 발견하고, 원인을 찾고, 여러 해결 방법을 비교하고, 하나를 선택한 뒤, 그 선택이 실제로 효과가 있었는지 다시 측정하는 과정까지 경험해보는 것이 목표다. D-ask v1이 나에게 RAG 서비스를 처음 만들어본 프로젝트 였다면, D-ask v2는 RAG 서비스를 어떻게 평가하고, 기술을 선택하고, 실제로 운영할 것인지 고민하는 프로젝트 로 만들어보려고 한다. 다음 글에서는 그 첫 번째 과정으로, D-ask v2에서 RAG 파이프라인을 구현하기 전에 왜 평가 환경부터 만들기 시작했는지 정리해보려고 한다.