스트리밍 채팅과 온보딩 마찰을 한 번에 개선한 배포 경험
목차
한 번에 스트리밍 채팅, 호감도 연출, 자동 셀카, 큰 얼굴 온보딩까지 네 가지 기능을 함께 배포했다. 규모가 있는 변경인 만큼 팀 전체의 조율과 우선순위 결정이 필요했던 작업이다. 왜 이 모든 걸 한 번에 했는지, 그 과정에서 뭘 배웠는지 정리해보자.
왜 한 배포에 담았나
처음엔 당연히 분리하는 게 맞나 고민했다. 스트리밍 채팅만 해도 일이고, 온보딩 개선만 해도 별개 업무다. 그런데 현실은 다뤘다.
팀과의 대화 속에서 드러난 게, 사용자 첫 경험을 개선하려면 채팅 반응성과 온보딩 마찰이 동시에 해결되어야 한다는 점이었다. 누군가는 스트리밍 채팅으로 "아, 이 앱은 빠르네"라는 신뢰를 만들고, 누군가는 자동 셀카와 큰 얼굴 UI로 "진입 장벽이 낮네"라는 느낌을 받아야 했다. 분리하면 각 기능이 따로 놀 위험이 있었다. 그래서 한 번의 배포로 사용자 경험의 여러 터치포인트를 동시에 개선하는 게 낫다고 판단했다.
물론 이건 상충도 만든다. 변경 파일이 6개, 레이어는 API부터 스타일까지 흩어진다. 테스트 범위도 넓어진다. 리뷰하는 팀원 입장에선 부담이다. 그래서 커밋 메시지를 명확하게, 변경 의도를 전부 담는 것에 신경 썼다.
스트리밍 채팅: 반응성을 사용자에게 보여주기
src/app/api/chat/route.ts에서 스트리밍을 구현했다. 이게 왜 필요했느냐면, 기존 요청-응답 모델에선 응답이 완성될 때까지 사용자가 기다려야 했기 때문이다. 특히 긴 답변일수록 화면이 멈춰 있는 것처럼 보인다.
스트리밍으로 바꾸면 첫 토큰이 0.5초 안에 나타난다. 사용자는 "아, 앱이 작동하고 있네"라는 느낌을 즉시 받는다. 이건 기술적 개선이자 심리적 개선이다.
// 개선 전 (완성 후 전달)
response = await chat.complete()
return response
// 개선 후 (토큰별로 실시간 전달)
stream = await chat.stream()
for token in stream:
yield token
프론트엔드 chat-client.tsx에서 이 스트림을 받아 처리하는 로직도 필요했다. 사용자가 메시지 중간에 멈추는 불안감을 느끼지 않도록, 토큰이 들어올 때마다 즉시 화면에 반영해야 했다.
온보딩 개선: 마찰을 없애는 세 가지 치료
호감도 연출은 초기 화면에서 "이 앱이 날 환영한다"는 느낌을 주는 것. 반응 시간이 빠르다, 이모지가 생생하다, 대화가 따뜻하다 같은 미시적 경험들이 쌓인다. chat-client.tsx에서 메시지 애니메이션, 타이핑 표시, 이모지 타이밍을 다듬었다.
자동 셀카는 온보딩 단계에서 사진을 직접 찍게 하던 기존 방식의 마찰을 줄이기 위함이다. 사용자가 "카메라 허용" 버튼을 누르면 자동으로 한두 장 캡처해서 선택하게 한다. src/lib/chat.ts, src/lib/claude-cli.ts에 캡처 로직을 담았다.
큰 얼굴 온보딩은 시각적 임팩트. 온보딩 첫 화면에서 큼지막한 사용자 얼굴(또는 샘플 이미지)을 보여주면 "이건 나를 위한 앱이다"라는 귀속감이 생긴다. src/app/globals.css와 src/app/page.tsx에서 레이아웃과 타이포그래피를 수정했다.
| 개선 항목 | 목적 | 담당 파일 | 사용자 느낌 |
|---|---|---|---|
| 스트리밍 채팅 | 반응성 | route.ts, chat-client.tsx | "빠르네" |
| 호감도 연출 | 감정 연결 | chat-client.tsx | "날 좋아하는군" |
| 자동 셀카 | 마찰 제거 | chat.ts, claude-cli.ts | "쉽네" |
| 큰 얼굴 UI | 귀속감 | page.tsx, globals.css | "나를 위한 앱이다" |
여러 파일을 건드릴 때의 주의점
한 번의 배포에 6개 파일이 영향받으면, 회귀 테스트도 그만큼 복잡해진다. 우리 팀은 이 점 때문에 다음을 챙겼다:
- 경계가 명확한 변경: API는 API만, 스타일은 스타일만. 섞지 않기
- 각 기능별 수용 테스트: 스트리밍이 제대로 오는지, 셀카 캡처가 실제로 작동하는지 별도 확인
- 롤백 전략: 뭔가 터지면 어느 파일부터 복구할 건지 미리 순서 정하기
- 커밋 메시지의 명확성: 저 네 가지 기능이 독립적으로 설명되도록
배운 점
처음엔 이런 큰 배포를 피하고 싶었다. 작고 자주가 정석이니까. 근데 현실은 사용자 경험은 시스템으로 움직인다. 한 가지만 빨라져도, 한 가지만 편해져도 전체는 별로다. 여러 기능이 한 방향을 가리킬 때는 함께 배포하는 게 사용자에겐 더 의미 있다.
대신 팀과의 조율, 테스트 자동화, 리뷰 문화가 견고해야 한다. 파일이 많으면 누군가는 놓친다. 그래서 우린 "각자 담당 레이어의 변경은 본인이 끝까지 책임"이라는 원칙을 세웠다.
다음 번엔 더 크게 생각할 것 같다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.