왜 만들었나
GIST에 관한 정보는 학사 공지, 학사 편람, 신입생 안내 자료, 학과 페이지에 흩어져 있습니다. 매 학기 같은 질문이 반복되지만 답을 찾기는 어렵습니다. 이 챗봇은 그 공식 자료 더미를 "그냥 물어보면 되는 것"으로 바꿉니다.
내가 맡은 부분
GSA InfoTeam 안에서 답변 생성 시스템 전체와 프론트엔드·백엔드 개발, UI 디자인을 맡았습니다. 문서 수집과 인프라는 팀의 다른 구성원과 함께 했습니다.
무엇을 만들었나
- 답변 생성. 업로드된 문서를 chunking하고 관련 구절을 랭킹해 모델 답변의 근거로 삼는 검색 파이프라인. 추측이 아니라 실제 학교 규정을 인용합니다.
- MCP 구조. 문서 검색은 별도 MCP 서버에, NestJS 백엔드는 MCP 클라이언트로. 새 데이터 소스를 답변 로직을 건드리지 않고 붙일 수 있습니다.
- 임베드 가능한 위젯. 프론트엔드를 iframe으로 제공해 어떤 학생 서비스든 태그 하나로 챗봇을 넣을 수 있습니다.
- 서비스별 대시보드. 연동한 서비스마다 자기 문서와 사용량을 따로 관리합니다.
기술적 결정
검색을 왜 분리했나. 첫 버전은 백엔드 하나에 검색과 답변 생성이 모두 들어 있었습니다. chunking 크기 하나를 바꾸는 실험도 답변 서버 전체를 다시 배포해야 했고, 실험 한 번에 반나절이 걸렸습니다. 검색을 MCP 서버로 떼어내자 데이터 소스 추가는 "도구 하나 추가"가 됐고, 실험 비용이 떨어지면서 실험 횟수가 늘었습니다.
도구는 하나로. 처음에는 search, search_by_category, search_recent처럼 도구를 여럿 두었는데 모델이 비슷한 도구 사이에서 헤맸습니다. 도구를 search_documents 하나로 줄이고 인자를 넓히자 프롬프트도 로그도 단순해졌습니다.
문서 종류별 chunking. 공지는 문서 하나를 chunk 하나로 두고 제목과 게시일을 앞에 붙였고, 편람은 조·항 경계로 잘라 상위 장 제목을 접두어로 넣었으며, 표가 많은 안내 자료는 행 단위로 풀어 "항목: 값" 문장으로 저장했습니다. 한 규칙으로 통일하려던 초기 시도는 편람 답변의 정확도를 눈에 띄게 떨어뜨렸습니다.
결과
chatbot.gistory.me에 배포되어 GIST 학생들이 사용 중이고, iframe 위젯 덕분에 학내 다른 서비스에도 붙기 시작했습니다. 질문 40개와 기대 답변으로 평가 세트를 만든 뒤로는 구조 변경의 효과를 숫자로 보고 있고, 응답 지연은 검색 인덱스를 바꿔 절반으로 줄였습니다. 지금은 답변 정확도를 더 올리는 데 집중하고 있습니다.