티스토리 뷰
컨디션: 조금 푹 잔 것 같기도..
📌 오늘 한 일
✅ 2차 UT 결과 및 반복 사용성 문제 정리
✅ 버튼 문구와 실제 동작이 일치하지 않는 UX 문제 분석
✅ 구구레터 서비스 장애 대응 과정 문서화
✅ /health 기반 서버 모니터링과 Slack 알림 구조 정리
✅ 최종 브로셔에 사용할 서비스 성과 지표 선별
✅ 홈 공유부터 친구 홈 쪽지 작성까지의 흐름 분석
✅ 구구레터 서비스 한 줄 설명과 사용 방식 문구 수정
1. 2차 UT를 정리하며, 서비스는 더 친절해야 한다고 느꼈다
오늘 2차 UT 결과를 정리했다.
기능을 전혀 사용하지 못하는 수준의 문제보다는,
사용자가 다음에 무엇이 일어날지 정확히 알기 어려운 문제가 반복해서 보였다.
가장 대표적인 것은 쪽지 작성 화면의 버튼이었다.
현재 흐름은 다음과 같았다.
쪽지 작성
→ ‘쪽지 보내기’ 클릭
→ 미리보기 화면
→ 최종 발송
하지만 사용자는 쪽지 보내기라는 문구를 보면 쪽지가 바로 발송될 것으로 예상한다.
실제로는 미리보기 화면이 나타나기 때문에,
쪽지가 이미 발송된 것인지 다시 보내야 하는 것인지 혼란이 생길 수 있었다.
개선된 흐름은 문구와 실제 동작을 일치시키는 것이다.
쪽지 작성
→ ‘쪽지 미리보기’
→ 미리보기 화면
→ ‘쪽지 보내기’
→ 발송 완료
처음에는 서비스가 친절하려면 안내 문구나 설명을 더 많이 제공해야 한다고 생각했다.
그러나 UT를 정리하면서, 친절함은 설명의 양보다
사용자가 예상한 결과와 실제 동작을 일치시키는 것에서 시작된다고 느꼈다.
쪽지 보내기를 누르면 쪽지가 전송되어야 하고,
쪽지 미리보기를 누르면 미리보기가 나와야 하는게 기본적인 UX가 아닐까 생각했다.
2. 서비스 장애를 겪고 모니터링 구조를 만들었다
구구레터 백엔드 서버가 중단됐을 때 프론트 화면에는 CORS 오류가 나타났다.
처음에는 프론트 설정 문제처럼 보였지만,
실제 원인은 백엔드 서버가 정상적으로 응답하지 않는 것이었다.
왜냐면, 이미 API 셋팅을 다 끝냈기 때문에 CORS 문제가 날 수가 없었다.
서비스를 계속 운영하려면 사용자가 제보하기 전에 서버 이상을 알아차릴 수 있어야 했다.
이를 위해 기존 백엔드의 /health API를 기준으로 모니터링 구조를 만들었다.
Supabase Cron 실행
→ Edge Function에서 /health 호출
→ 실패 시 최대 3회 재시도
→ 3회 모두 실패하면 Slack 알림
→ 장애가 지속되면 중복 알림 생략
→ 정상 복구 시 알림 상태 초기화
Supabase에는 점검 로그와 알림 상태를 저장하는 테이블을 만들고 RLS를 적용했다. Edge Function에서는 한 번의 실패만으로 장애를 판단하지 않고,
일정 간격을 두고 총 3회 확인하도록 했다.
한 번만 확인하지 않은 이유는 Render 서버의 콜드스타트 때문이다.
첫 호출은 응답이 늦을 수 있지만 이후에는 정상적으로 응답할 수 있어,
일시적인 지연과 실제 장애를 구분할 필요가 있었다.
정상·실패·중복 알림·복구 상황을 각각 테스트했고,
Cron은 5분 주기로 자동 실행을 검증한 뒤 운영용으로 30분 간격으로 변경했다.
3. 최종 브로셔에 넣을 지표를 고르며 제품 흐름을 다시 봤다
최종 브로셔를 작성하기 위해 구구레터의 핵심 사용 흐름을 다시 분석했다.
구구레터의 친구 홈 작성형은 홈 소유자가 자신의 링크를 먼저 공유해야 시작된다.
자기 홈 진입
→ 홈 링크 공유
→ 친구 홈 진입
→ 쪽지 작성
→ 발송 및 열람
따라서 친구 홈에서 쪽지가 작성됐는지만 보는 것이 아니라,
그 이전 단계인 홈 공유가 실제로 발생했는지도 확인해야 했다.
홈 공유 행동

v2에서 자기 홈 진입자는 크게 늘었지만,
실제 링크를 공유한 사용자는 거의 늘지 않았다.
다만 자기 홈 진입자에는 마케팅을 통해 가입한 사용자,
받은 쪽지를 확인한 사용자, 자신의 홈을 둘러본 사용자 등이 함께 포함될 수 있다.
따라서 공유율 감소만으로 기능이 나빠졌다고 단정할 수는 없었다.
확실히 말할 수 있는 것은
자기 홈을 방문한 사용자는 늘었지만,
친구 유입을 시작시키는 공유 사용자 수는 비슷한 수준에 머물렀다.
공유 이후의 쪽지 작성
v2에서 친구 홈에 진입한 사용자 중 41.1%가 쪽지 발송을 완료했다.
전체 발송 방식도 비교했다.

실제로 발송된 쪽지의 약 3분의 2가 친구 홈에서 바로 작성한 방식이었다.
친구 홈 방식의 열람률도 내 홈 작성형 방식보다 높게 나타났다.
이를 통해 브로셔에서는 다음 가설에 집중하기로 했다.
친구가 자신의 쪽지 홈을 공유하면,
링크를 받은 지인이 해당 홈에 들어와 쪽지를 작성할 것이다.
- 지표 잘못 셋팅된거 발견해서 또 다수정함.. 힘들어.. 하.. ㅜ
'TIL > 2026 부트캠프' 카테고리의 다른 글
| [2026년 08월 04일] 커리어데이 (1) (0) | 2026.10.03 |
|---|---|
| [2026년 07월 30일 ~ 2026년 8월 3일] 최종 프로젝트 (19) (0) | 2026.10.03 |
| [2026년 07월 28일] 최종 프로젝트 (17) (0) | 2026.10.03 |
| [2026년 07월 27일 월요일] 최종프로젝트 (16) (0) | 2026.10.03 |
| [2026년 07월 26일] 이력서 & 면접 영상 찍기 (0) | 2026.10.03 |
- Total
- Today
- Yesterday
- 개발자퇴사
- C++
- npm init
- jdk1.7 다운
- ORACLE MERGE INTO 같은테이블
- java1.7 다운
- merge into 단일테이블
- 신입사원
- 알고리즘
- 백준알고리즘
- jdk 이전버전 다운
- package.json
- 백준
- 신입개발자퇴사
- ORACLE 단일테이블
- 파이썬
- 개발자
- 단일쿼리문
- 인스턴스
- 신입사원개발자
- Java
- 자바
- 초보개발자
- merge into 같은 테이블
- merge into using dual
- merge into
- merge into using
- ORACLE MERGE INTO USING DUAL
- ORACLE MERGE INTO 동일테이블
- npm이란
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |