2026년 7월 23일 목요일
컨디션: 늦잠자서 지각했음..
오늘 한 일
✅ 오전 회의록 작성 2026.07.23 목 기능명세서 v2.1 반영건
✅ PRD 작성을 위한 지표 확인 PRD v3.0 - 데이터 기반 의사결정 문서 작성
✅ 지표 보다보니 posthog에서 연동한 supabase 데이터가 일치하지 않음, 삭제건이 반영되고 있지 않은 상태
✅ 2차 QA 확인 완료
✅ 부트캠프 마케팅 홍보 및, 인스타그램 홍보
✅ 다른팀 UT 참여
아침 스몰 토크에서 시작된 기능 아이디어
오늘 오전에는 기능명세서 v2.1 반영 건을 확인하고 회의록을 작성했다.
회의를 시작하면서 어제 확인한 데이터에 관해 가볍게 이야기를 꺼냈다. 데이터를 봐도 현재 상태 메시지 기능이 사용자에게 어떤 효용을 주고 있는지 명확하게 느껴지지 않았다.
상태 메시지가 실제로 쪽지 작성을 유도하는지, 사용자가 이 기능을 왜 써야 하는지 충분히 전달되고 있는지 애매하다는 생각이었다.
처음에는 가벼운 스몰 토크로 시작했지만, 이야기가 점점 발전하면서 팀원들과 추가 기능 아이디어도 함께 논의하게 됐다.
- 테스터 피드백에서 나왔던 욕설 필터링
- 쪽지를 받았을 때 이메일로 알려주는 알림 기능
- 상태 메시지의 목적을 더 명확하게 만드는 개선안
몇 가지 기능을 추가로 정리해 기능명세서를 작성해보려고 했다. 하지만 개발 튜터님께 확인한 결과, 현재 일정상 추가 기능 개발은 더 진행하기 어렵다는 답변을 받았다.
기능을 실제로 반영하지 못한다는 점은 아쉬웠다. 그래도 아침의 짧은 대화만으로도 기존 기능의 문제를 다시 바라보고, 기능명세서로 발전시킬 만한 아이디어를 함께 만들 수 있었다는 점은 좋았다.
항상 정식 회의나 긴 기획 시간이 있어야만 아이디어가 나오는 것은 아닌 것 같다. 팀원들이 각자 느꼈던 문제를 편하게 꺼낼 수 있는 분위기가 있으면, 짧은 대화도 제품 논의로 발전할 수 있다는 점을 느꼈다.
PRD 3.0 작성을 위한 지표 확인
오늘은 PRD 3.0 작성을 준비하기 위해 거의 하루 종일 지표를 확인했다.
버전별 데이터를 비교하고, 어떤 변화가 있었는지 확인하려고 했는데 PostHog에서 조회한 Supabase 데이터와 실제 DB 데이터가 일치하지 않았다.
처음에는 쿼리나 필터를 잘못 설정한 줄 알았다. 하지만 확인해보니 PostHog와 Supabase를 연동할 때 테이블 전체를 매번 가져오는 것이 아니라, 비용과 처리량을 줄이기 위해 업데이트된 데이터만 동기화하는 방식으로 설정되어 있었다.
이 때문에 새로 추가되거나 수정된 데이터는 반영됐지만, DB에서 삭제한 데이터는 PostHog에 그대로 남아 있었다.
결국 실제 DB에서는 삭제된 테스트 데이터가 PostHog 지표에는 계속 포함되고 있었고, 이를 모른 채 분석했다면 잘못된 결론을 내릴 수도 있는 상황이었다.
삭제된 데이터까지 다시 반영하기 위해 동기화 방식을 Full table replication으로 변경하고, letters 테이블 전체를 다시 동기화했다.
이번 문제를 겪으며 데이터를 분석하기 전에 다음 내용을 먼저 확인해야 한다는 것을 느꼈다.
- 원천 DB와 분석 도구의 데이터가 일치하는가
- 데이터가 어떤 방식과 주기로 동기화되는가
- 추가·수정뿐 아니라 삭제도 반영되는가
- 테스트 데이터가 지표에 포함되어 있지 않은가
- 지표를 구성하는 관련 테이블의 데이터도 함께 정리됐는가
PostHog에 숫자가 보인다는 이유만으로 그 데이터를 바로 신뢰해서는 안 됐다. 지표를 해석하기 전에 데이터가 어떤 구조로 수집되고 동기화되는지부터 확인해야 했다.
운영 DB와 테스트 데이터가 섞여 있을 때의 불편함
현재 부트캠프에서 사용하는 DB에는 실제 운영 데이터와 개발·QA·테스트 데이터가 모두 함께 들어가 있다.
테스트를 위해 만든 데이터는 나중에 삭제하면 된다고 생각했지만, 실제로 관리해보니 생각보다 불편한 점이 많았다.
팀원들이 기능을 확인하면서 다른 팀원에게 장난식으로 테스트 쪽지를 보내는 경우도 있었다. 테스트 목적으로 만들어진 데이터와 실제 사용 데이터의 경계가 명확하지 않다 보니, 어떤 데이터를 삭제해야 하는지 하나씩 확인해야 했다.
또한 쪽지 하나를 삭제할 때 letters 데이터만 지우는 것으로 끝나지 않았다. 해당 쪽지와 연결된 신고, 반응, 답장 데이터도 함께 확인하고 삭제해야 했다.
테스트하는 사람 입장에서는 가볍게 만든 데이터일 수 있지만, 이를 정리하고 지표를 관리하는 사람 입장에서는 작은 테스트 데이터도 분석 결과를 왜곡하는 노이즈가 될 수 있다는 점을 느꼈다.
운영 데이터와 테스트 데이터가 분리되어 있었다면 훨씬 간단했을 것이다. 당장 환경을 나누기는 어렵더라도, 최소한 테스트 계정과 테스트 데이터의 작성 규칙을 정하거나 삭제 범위를 사전에 맞춰두는 것이 필요하다고 생각했다.
2차 QA 반영 결과 확인
오늘은 2차 QA에서 발견한 수정 사항도 모두 개발에 반영되어 다시 확인했다.
확인 결과 요청했던 내용들이 깔끔하게 반영되어 있었다. 기능 동작과 화면을 다시 점검했고, 2차 QA 결과물 확인을 마칠 수 있었다.
추가 기능 개발은 어려워졌지만, 정해진 범위 안에서 기존 기능을 안정적으로 마무리했다는 점에서는 다행이었다.
다른 팀의 2차 UT에 참여하며 달라진 관점
오늘은 다른 팀의 서비스에 대한 2차 UT에도 참여했다.
해당 서비스는 함께 사는 두 사람이 집안일을 등록하고, 각자 완료한 일을 체크하며, 일주일 단위의 결과를 확인하는 앱이다. 집안일을 수행할수록 화면 속 성이 점점 발전하는 구조도 포함되어 있다.
1차 UT에서는 귀여운 디자인과 성이 성장하는 모습이 먼저 눈에 들어왔다. 당시에는 재미있고 다른 사람에게 추천할 만한 서비스라고 생각했다.
하지만 2차 UT에서 다시 사용해보니, 이번에는 겉으로 보이는 귀여움보다 서비스의 구조와 실제 사용성이 더 많이 보였다.
습관 관리 앱으로 보기에는 기록 기능이 부족했다
서비스는 집안일을 꾸준히 수행하도록 돕는 습관 관리 성격을 가지고 있지만, 실제 기능은 할 일을 체크하고 완료된 항목을 확인하는 수준에 가까웠다.
평소 여러 습관 앱을 사용해본 경험을 떠올리면, 습관을 지속적으로 관리하기 위해서는 다음과 같은 기능이 필요하다.
- 오전, 오후, 저녁과 같은 시간대별 구분
- 매일 또는 특정 요일에 반복되는 일정 설정
- 한 습관을 여러 번 수행했을 때 횟수를 기록하는 기능
- 일정 기간 동안 얼마나 지속했는지 보여주는 누적 기록
- 이전 기록과 현재 기록의 변화 확인
현재 서비스에서는 완료 여부만 체크할 수 있고, 완료한 일의 목록만 확인할 수 있었다. 이 때문에 사용자가 집안일을 얼마나 꾸준히 수행하고 있는지, 생활 습관이 실제로 달라지고 있는지를 확인하기 어려웠다.
집안일 체크 앱을 목표로 하는 것인지, 함께 생활 습관을 형성하는 앱을 목표로 하는 것인지 제품의 중심 가치가 조금 더 명확해질 필요가 있다고 느꼈다.
성을 완성하기 위해 편지를 작성해야 하는 흐름이 부자연스러웠다
집안일 완료율에 따라 성이 1단계부터 점점 아름다운 모습으로 발전한다. 하지만 마지막 9단계와 10단계까지 완성하려면 상대방에게 편지를 작성해야 했다.
1차 UT 당시에는 편지를 작성하지 않으면 다음 단계로 넘어갈 수 없는 강제 구조였다. 2차 UT에서는 강제성은 줄어들었지만, 여전히 마지막 단계를 완성하려면 편지를 써야 하는 구조는 남아 있었다.
나는 이 흐름이 여전히 부자연스럽게 느껴졌다.
9단계와 10단계에 도달하는 시점은 대체로 일주일이 끝나는 주말일 가능성이 높다. 함께 사는 사람들은 주말에 같은 공간에 있을 가능성이 높은데, 이 시점에 굳이 앱 안에서 편지를 작성해야 성을 완성할 수 있다는 연결이 잘 이해되지 않았다.
편지를 쓰는 행위가 두 사람의 관계를 좋게 만들 수는 있다. 하지만 사용자가 현재 하고 싶은 행동이 아니라 서비스가 정한 보상을 완성하기 위해 요구되는 행동이라면, 따뜻한 경험보다는 과제로 느껴질 수 있다.
특히 집안일 수행이라는 핵심 행동과 편지 작성이라는 행동 사이의 연결 근거가 충분하지 않았다. 성장을 완성하는 마지막 행동으로 편지를 두고 싶다면, 사용자가 왜 이 시점에 편지를 써야 하는지 자연스러운 맥락을 제공해야 한다고 생각했다.
예를 들어 단순히 편지를 작성하게 하기보다, 이번 주 상대방이 수행한 집안일을 보여주고 그중 고마웠던 일을 선택해 짧게 반응하도록 만들었다면 기존 행동과 더 자연스럽게 이어졌을 것 같다.
UT를 반복하면서 달라진 점
같은 서비스를 다시 테스트했지만 1차와 2차에서 보이는 문제가 달랐다.
처음에는 화면의 귀여움과 재미있는 장치에 집중했다. 두 번째로 사용했을 때는 서비스가 목표로 하는 행동과 실제 제공하는 기능이 일치하는지, 특정 기능이 사용자 흐름 안에서 자연스럽게 연결되는지를 더 많이 보게 됐다.
UT를 반복하는 것은 단순히 수정된 기능을 다시 확인하는 과정만은 아니었다. 서비스를 한 번 경험하고 구조를 이해한 뒤 다시 보면, 첫인상에 가려졌던 문제와 제품의 논리적 연결이 보이기 시작한다는 점을 느꼈다.
오늘의 배움
- 짧은 스몰 토크도 팀원들이 느낀 문제를 꺼낼 수 있다면 제품 아이디어로 발전할 수 있다.
- 좋은 아이디어가 나와도 일정과 개발 가능성을 고려해 이번 범위와 후속 과제를 구분해야 한다.
- 지표를 분석하기 전에 원천 DB와 분석 도구의 데이터가 일치하는지 확인해야 한다.
- 데이터 동기화에서는 추가와 수정뿐 아니라 삭제가 반영되는지도 중요하다.
- 운영 데이터와 테스트 데이터가 섞여 있으면 테스트 자체보다 이후 정리와 분석 관리에 더 많은 비용이 든다.
- 테스트 데이터도 지표를 왜곡할 수 있으므로 작성 규칙과 삭제 기준이 필요하다.
- 반복 UT에서는 첫인상에 가려졌던 제품 구조와 행동 간의 연결 문제를 발견할 수 있다.
- 사용자의 행동을 유도하려면 보상만 연결할 것이 아니라, 그 행동이 필요한 시점과 맥락을 설계해야 한다.
