AI·문서
연구용 챗봇 대화 수집 데모
참가자 대화를 저장 방식 두 가지로 동시에 흘려, 어느 쪽에서 기록이 사라지는지 비교하는 데모입니다.
research-chatbot-157002-production.up.railway.app
열어 보시면 이런 걸 확인하실 수 있습니다
- [탭 닫힘]을 재현하면 왼쪽 기록만 12행으로 줄어 차이 +2가 뜹니다.
- [서버 재시작] 뒤 [재접속]을 누르면 커밋 쪽만 14행을 다시 읽어옵니다.
- [CSV 내보내기]에서 집단별로 걸러 13컬럼 파일을 실제로 내려받아 봅니다.
- 상단 [사용법]을 열면 왼쪽 기록이 문서 서술을 옮긴 모형임을 밝힙니다.
만들면서 풀어야 했던 것
- '참가자 입력과 AI 답변이 누락 없이 저장돼야 한다'는 요구가 흔히 쓰이는 구성에서는 구조적으로 깨질 수 있다는 점을 다뤘습니다. 저희는 턴마다 즉시 커밋하는 원장을 따로 두고, 두 저장 방식의 행 수가 갈라지는 장면과 [재접속] 복구를 화면에서 바로 비교하도록 만들었습니다. 비교 대상인 왼쪽 기록은 실측 벤치마크가 아니라 공식 문서 서술을 재현한 모형이며 앱 화면이 이 사실을 상시 고지합니다. 특정 개발 스택을 시연하는 것이 아니라 저장 설계를 시연하는 데모입니다.
- 공개 배포본에서 API 키가 브라우저로 노출되고 공개 주소가 남용돼 비용이 새는 문제를 서버 프록시 구조로 정리했습니다. 키는 서버 환경변수에만 두고, 응답 토큰 상한·입력 길이 상한·IP당 호출 상한·요청 간격을 서버에서 강제합니다. 프록시가 없는 환경에서는 준비된 응답으로 대체하고, 대체 중임을 화면에 상시 고지합니다.
- 적대 감사에서 '재접속하면 두 기록의 차이가 0으로 돌아온다'는 설명이 실제 동작(재접속 뒤에도 차이 +6 유지)과 어긋나는 것을 발견했습니다. 안내 모달·소개 글·계획서 세 곳의 문구를 동시에 정정하고 검증기를 다시 돌려 통과시킨 뒤 배포본을 갱신했습니다.
비슷한 걸 만들어 보고 싶으시다면
구간 견적으로 규모를 먼저 가늠해 보시거나, 조건을 적어 보내 주시면 범위를 정리해 회신드립니다.