도쿄 팝업 스토어 안내 챗봇

문제

17일 동안 열린 도쿄 팝업 스토어에는 5개 층에 78개 브랜드가 들어섰습니다.

매장 운영 정보는 한국어 스프레드시트 28개 탭에 흩어져 있어 일본 고객이 직접 찾아볼 수 없었고, 같은 질문이 현장 스태프에게 몰렸습니다.

그래서 문제를 “고객이 스태프에게 묻지 않고 원하는 정보에 3번 이내 탭으로 닿게 하는 것”으로 정했고, 처음 요구는 일본어 안내뿐이었지만 한국어와 영어까지 넓혔습니다.

설계부터 배포까지는 2주 안에 혼자 끝내야 했습니다.

접근

• 챗봇을 만들기 전에 안내판·키오스크 강화, 다국어 스태프 증원, 기존 상품 페이지 기능 확장과 비교했고, 다국어를 모두 지원하는지, 사용 데이터를 모을 수 있는지, 늘리기 쉬운지, 바로 배포할 수 있는지에서 챗봇이 앞섰습니다.
• 답을 만드는 방식은 LLM과 키워드 규칙을 비교했습니다. 키워드 규칙은 자연어를 이해하지 못하고 새 키워드를 코드로 넣어야 하지만, 응답 속도를 예측할 수 있고 비용이 0원이며 없는 사실을 지어내지 않아 17일짜리 현장 운영에 맞았습니다.
• 서버 쪽 로그가 없어서, 이벤트 계측을 출시 전에 반드시 갖출 조건으로 정했습니다.

결정

• 서버 없이 앱 안의 웹 화면으로 동작하는 React·TypeScript·Vite 앱을 만들고, 답은 한국어·일본어·영어 키워드 200개 이상의 규칙으로 고르게 했습니다. 실행 중 API 호출은 0건이고, 사용 이벤트 전송만 둡니다.
• 정적 콘텐츠는 파일 하나에 모으고 접근 계층을 따로 둬, 나중에 API나 CMS로 바꿔도 화면 코드는 그대로 두게 했습니다.
• 5번 대화할 때마다 앱 홍보 카드를, 브랜드를 보고 1.5초 뒤에는 함께 볼 상품 카드를 띄우고, 알아듣지 못한 입력에는 할인 폭이 가장 큰 상품을 대신 보여 주게 했습니다.
• 웹 화면 주소는 정적 호스팅과 앱 원격 설정으로 관리해, 코드 배포와 노출 여부를 따로 제어했습니다.

결과

• 17일 동안 고유 사용자 약 5천 명이 썼고, 방문 대비 클릭 전환율은 약 62%였습니다.
• 한국어 스프레드시트 28개 탭에 있던 정보를, 고객이 앱 안 챗봇에서 3번 이내 탭으로 찾게 됐습니다.
• 번들은 JS 약 79KB, CSS 약 17KB(gzip)로 유지했습니다.
• 검증: 출시 전 런치 리뷰에서 이벤트가 내부 코드값만 보내는 문제를 찾아, 모든 클릭 이벤트에 버튼·메뉴 이름을 붙이고 빠진 이벤트 2종을 새로 만들었습니다(파일 1개, +102/−4줄, 기존 필드 유지). 배포 전에는 서버 오류율 0.5%, 화면 오류율 1%, LCP p75 4초를 5분 넘게 넘기거나 고객 문의가 2건 들어오면 되돌린다는 조건을 적었습니다.
• 이 챗봇은 이후 하라주쿠 팝업에 그대로 재활용됐습니다.

기록과 자동화

• 문서: 2쪽 기획서(2-Pager)를 직접 쓰고, PRD와 ADR, 메뉴 라우팅·시퀀스·배포·구매 흐름 HLD 다이어그램, 키워드 규칙을 고른 이유와 한계를 적은 아키텍처 문서, 되돌릴 조건을 적은 런치 리뷰를 남겼습니다.
• 프로세스 자동화: 배포를 자동화했고, 요구사항부터 ADR, HLD, LLD, 구현, 지식베이스, 런치 리뷰, 위키 발행까지 단계를 나눈 AI 에이전트 흐름을 처음 실전에 쓰며 분류, 브랜치, 커밋 전 리뷰, 팀 구성 판단을 서브에이전트로 나눴습니다.
• 누가 쓰나: 개발 과정은 사례 문서로 정리해 팀에 공유했고, 챗봇은 하라주쿠 팝업에서 다시 쓰였습니다.

배운 점

1. 짧게 운영하는 현장 서비스는 답이 늘 같고 빠른 방식을 고르고, 그 대가도 문서에 적어 둡니다.
   • 상황: 17일 동안 운영할 챗봇을 2주 안에 혼자 만들어야 했습니다.
   • 한 일: LLM 대신 키워드 200개 이상의 규칙으로 답하게 하고, 자연어를 이해하지 못한다는 한계를 설계 문서에 적었습니다.
   • 결과: 비용 0원에 응답 속도를 예측할 수 있었고, 17일간 약 5천 명이 쓴 뒤 하라주쿠 팝업에서 그대로 다시 쓰였습니다.
2. 분석용 이벤트는 사람이 읽을 수 있는 이름으로 설계하고, 출시 전 점검 문서에서 한 번 더 확인합니다.
   • 상황: 이벤트가 내부 코드값만 보내 어떤 메뉴와 질문이 눌렸는지 알 수 없었고, 스타일과 브랜드 클릭은 아예 기록되지 않았습니다.
   • 한 일: 런치 리뷰를 쓰다 이를 찾아 이름 필드를 붙이고 빠진 이벤트 2종을 만들되, 기존 필드는 그대로 두었습니다.
   • 결과: 계측을 분석할 수 있는 형태로 바꿨고, 되돌릴 조건을 미리 적고 스스로 승인해 배포했습니다.
3. 혼자 짧게 만들 때는 요구사항, 결정, 설계, 출시 점검을 단계별 문서로 나누고 단계별 판단을 AI 에이전트에 나눠 맡겨 재작업 범위를 좁힙니다.
   • 상황: 혼자서 2주 안에 설계부터 배포까지 해야 했습니다.
   • 한 일: 요구사항부터 위키 발행까지 단계를 나눈 AI 에이전트 흐름을 처음 실전에 쓰고, 분류, 브랜치, 커밋 전 리뷰 판단을 서브에이전트로 나눴습니다.
   • 결과: 재작업이 생겨도 해당 단계 안에서 끝났고, 이 과정을 사례로 정리해 팀에 공유했습니다.