TIL 2026.06.30 (화)
- 컨디션: 소소 약간의 두통이 있어서 두통약 먹었음. 다리가 매우 뻐근함..
오늘 한 일 요약
- 데일리 스크럼
- 티켓 분배
- 기능 명세서 템플릿 전달
- PRD 초안 리뷰
- 설문조사 작성해준 것 리뷰
- QA 템플릿 리뷰
- 설문조사 나오기 전에 할 수 있는 것은 무엇일까? 정리
- 설문조사 나오기 전에 할 수 있는 것들 정리하여 회의 (디자인 리서치)
- 회의를 했지만 팀원들이 시간이 필요하다고 하여 시간을 더 줌
- 디자인 튜터님과 상담
- 최종 방향성 회의
오늘은 최종 프로젝트에서 디자인 방향과 PRD 문제정의를 다시 맞춘 날이었다.
그런데 회의를 하면서 우리 팀이 아직 같은 그림을 보고 있지 않은 것 같다.
분명 KPI도 이야기했고, 발신자 중심의 UI 흐름도 정리했고, 문제정의도 어느 정도 맞췄다고 생각했다. 그런데도 계속 “유저 설문조사가 나와야 정할 수 있다”는 이야기가 나왔다.
처음에는 그 말이 잘 이해되지 않았다. 왜 이미 정리한 것들을 다시 멈춰야 하는지, 설문 결과가 나오기 전까지 정말 아무것도 정할 수 없는지 의문이 들었다.
하지만 나도 지쳐 있었고, 계속 설득하기보다는 일단 알겠다고 했다.
아직까지 왜 모른다고 했는지 나도 잘 모르겠다.. 🥲
다만 기다린다고 해서 모든 작업을 멈출 수는 없었다. 나는 마감 기한을 지키는 것도 프로덕트를 만드는 과정에서 중요한 책임이라고 생각한다. 그래서 지금 이 시간에 할 수 있는 일을 계속 찾았다.처음에는 설문 결과와 무관하게 진행할 수 있는 공통 요소를 정리하면 된다고 생각했다.
예를 들어 우리 서비스의 주요 흐름인 카드 작성, 카드 미리보기, 링크 공유, 수신자 열람 같은 부분이다. 온보딩이나 세부 문구는 바뀔 수 있어도, 마음을 작성하고 전달하고 읽는 기본 흐름은 크게 바뀌지 않는다고 봤다.
하지만 아직 IT 경험이 없는 팀원은 어떤 문제를 풀어야할지 무엇이 문제인지 이해를 못해서 진행이 되지 않았다...
예를 들면 나는 쪽지 발신, 수신 기능은 동일하니 그거에 대한 유저플로우를 짜면 되지 않을까? 생각했지만, IT에서 일해보지 않은 분들은 어떻게 짜야할지 잘 모르겠다고 했다.... ;;
오늘 한 일
1. 디자인 리서치 회의 진행이 잘 안된 이유
그럼 유저 인터뷰 없이도 진행할 수 있는 방향을 생각했다.
유저 인터뷰 없이도 가능한 온보딩/랜딩, 카드 작성, 공유, 수신자 열람 화면에 대한 레퍼런스를 공유하자고 했다.
처음에는 아래 내용을 정하려고 했다.
하지만 회의가 진행될수록 디자인 레퍼런스 자체보다 더 앞단의 문제가 드러났다.
- 사용자는 단순히 쓸 수단이 없어서 표현하지 못하는가?
- 아니면 관계 안에서 그 말을 꺼내기 어려워서 표현하지 못하는가?
팀원 중 한명이 “아직 그림이 잘 안 그려진다”고 이야기했다.
나에게는 어느 정도 유저 플로우가 머릿속에 있었기 때문에 답답함도 있었다.
우리가 모두 공통 기준을 문서로 정리했지만, 이 서비스에 대해 정말 이해가 가지 않는 팀원도 있기 때문에,
이 팀원을 설득시키고 가야하는가,, 아니면 그냥 두고 가야하는가,, 에 대한 고민이 있었다.
내 머릿속에서는 이미 처음에 정한 틀이 있었고, 유저 인터뷰도 굳이 진행하지 않아도 결과가 뻔했고,
결국 이 방향 혹은 저 방향대로 가겠군에 대해서 명확하게 있었고,
이미 나는 이 프로젝트를 한번 진행했었으니 그 서비스 방향성과 문제에 대한 맥락에 대해 다른 팀원들보다 이해가 컸다.
2. 디자인 튜터님께 조언 요청
디자인 튜터님께 현재 상황을 설명드렸다.
- 설문 결과에 따라 발신자 중심/수신자 중심 방향이 달라질 수 있음 (유저플로우가 달라질 수 있음)
- 타깃이 아직 명확하지 않음
- 팀원들이 각자 다른 서비스 그림을 그리고 있음
- 세부 UI를 정하기 어려운 상태
튜터님은 지금 단계에서 세부 UI를 정하기보다, 먼저 메인 플로우와 핵심 기능을 잡는 것이 좋다고 조언해주셨다.
- 타깃이 바뀌어도 유지될 가능성이 높은 기능부터 먼저 잡아라.
예를 들어 온보딩 문구나 카드 스타일은 타깃에 따라 달라질 수 있다.
하지만 “카드를 작성한다 → 공유한다 → 수신자가 열람한다”는 기본 흐름은 발신자 중심으로 가든, 일부 수신자 맥락을 고려하든 크게 변하지 않는다.
사실 이미 유저 플로우에 대해서도 팀원들한테 이야기 했지만 다시 이야기가 계속 원점으로 우리가 설문 조사를 해야 수신자 중심이 될지 / 발신자 중심이 될지 알 수 있다는 말만 돌아와서 어떻게 해결해야할지 막막했다.
(수신자 중심이 될지 / 발신자 중심이 될지도 벌써 앞단에 정했다.. 근데 왜 모르겠다고 하는지 이유를 잘 모르겠다!)
3. PRD 문제정의 리뷰
저녁 회의에서는 디자인 논의보다 PRD 문제정의에 가까운 이야기를 했다.
기존에는 우리가 문제를 이렇게 보고 있었다.
카톡으로 보내기엔 어색하고, 손편지로 쓰기엔 무거운 마음을 카드 형태로 가볍게 전할 수 있게 하자.
하지만 회의 중에 이 포지셔닝만으로는 부족하다는 의견이 나왔다.
문제는 단순히 “적절한 채널이 없다”가 아니라, 가까운 관계 안에서 긍정적인 마음을 표현할 때 생기는 심리적 부담에 더 가까웠다.
예를 들면 이런 것들이다.
- 괜히 어색해질까 봐 걱정된다
- 상대가 부담스러워할까 봐 망설인다
- 좋은 말을 했는데 상대가 무안하게 반응하면 내가 수치스러울 수 있다
- 가까운 사이일수록 오히려 고마움이나 응원을 말로 꺼내기 어렵다
- 표현하고 싶은 마음은 있지만, 그 말을 꺼낼 명분과 용기가 부족하다
이 논의를 통해 문제정의의 초점이 조금 바뀌었다.
Before:
발신자는 칭찬·감사·응원을 보내고 싶지만, 적절한 수단이 없어 표현하지 못한다.
After:
발신자는 가까운 관계 안에서 긍정적인 마음을 느끼지만, 관계 분위기와 상대 반응을 의식하기 때문에 표현할 용기를 내기 어렵다.
이 차이가 중요했다.
첫 번째 문장은 기능 중심이다.
두 번째 문장은 사용자 심리와 관계 맥락 중심이다.
오늘의 핵심 키워드: 관계와 용기
오늘 회의에서 서비스의 핵심 키워드는 관계와 용기로 정리됐다.
이 서비스가 단순히 “예쁜 카드를 보내는 서비스”라면 차별점이 약하다.
하지만 “관계 안에서 말하지 못했던 마음을 꺼낼 수 있는 명분과 용기를 주는 서비스”라면 조금 더 분명해진다.
특히 내가 이 서비스를 했던 경험이 있어 이렇게 말을 했다.
예전에 크리스마스 트리나 롤링페이퍼 같은 서비스를 보면, 평소에는 하지 않던 말도 “이 서비스가 있으니까 한번 해볼까?” 하게 되지 않나요? 그게 가장 큰 명분이 된다고 생각해요. 이걸 통해 용기를 얻는거예요.
즉, 서비스 자체가 표현의 명분이 된다.
이 점이 우리 서비스의 중요한 해결 방향이 될 수 있다고 느꼈다.
이 서비스는 사용자를 대신해 마음을 전해주는 것이 아니라, 사용자가 마음을 꺼낼 수 있는 분위기와 명분을 만들어주는 서비스다.
오늘 결정한 것
1. 유저 플로우는 발신자 중심으로 유지
예를 들면:
- 수신자 중심: “나에게 응원/칭찬을 써줘” 링크를 만든다
- 발신자 중심: “내가 누군가에게 마음을 전한다”
설문에서는 수신자 니즈도 보였지만, 이번 MVP에서는 기존 방향대로 발신자가 카드를 작성하고 공유하는 흐름을 중심으로 가기로 했다.
다만 수신자 경험을 무시한다는 뜻은 아니다.
수신자의 반응과 관계 맥락은 발신자의 허들을 낮추는 요소로 함께 고려하기로 했다.
2. 답장 기능은 MVP에서 제외
발신자가 두려워하는 것 중 하나는 상대 반응이다.
좋은 말을 보냈는데 상대가 어색하게 반응하거나, 아무 반응이 없으면 오히려 민망할 수 있다. 하지만 그렇다고 답장 기능까지 넣으면 MVP 범위가 커진다.
그래서 1차 MVP에서는 답장보다 가벼운 반응을 고민하기로 했다.
예를 들면:
- 읽음 표시
- 하트 이모지
-> 이건 사실 내가 이미 유저 플로우에서 정한 부분이다
중요한 것은 수신자에게 큰 부담을 주지 않으면서도, 발신자가 “내 마음이 도착했다”고 느끼게 하는 것이다.
오늘의 배움
1. 팀원이 “모르겠다”고 할 때는, 무엇을 모르는지 쪼개야 한다
모르겠는데 뭘 모르겠다고 말하는게 답답했다...
나는 개발 경험이 있어서 그런지, 방향이 완전히 확정되지 않아도 변하지 않는 기능부터 쪼개서 진행하면 된다고 생각했다.
하지만 팀원은 “설문 결과가 나오지 않으면 플로우를 못 정하겠다”고 느끼고 있었다.
여기서 내가 해야 했던 것은 “왜 못 정하지?”라고 생각하는 것이 아니라, 아래처럼 질문을 쪼개는 것이었다.
- 발신자/수신자 방향이 안 정해져서 막히는가?
- 타깃이 안 정해져서 막히는가?
- 화면에 들어갈 문구가 안 정해져서 막히는가?
- 디자인 톤을 모르겠어서 막히는가?
- 기능 우선순위가 안 보여서 막히는가?
“모르겠다”는 말은 하나의 상태처럼 보이지만, 실제로는 여러 종류의 불확실성이 섞여 있다.
2. 문제정의가 흔들리면 디자인도 흔들리게 된다.
디자인은 PRD와 별개가 아니었다.
처음에는 디자인 회의를 하려고 했지만, 결국 PRD 문제정의를 다시 보게 됐다.
왜냐하면 디자인 톤은 우리가 어떤 문제를 풀고 싶은지에 따라 달라지기 때문이다.
만약 문제가 “편지를 쉽게 쓰기 어렵다”라면, 디자인은 템플릿과 작성 편의성 중심이 된다.
하지만 문제가 “관계 안에서 표현할 용기를 내기 어렵다”라면, 디자인은 안전함, 따뜻함, 명분, 수신 반응까지 고려해야 한다.
3. 설문 조사는 20문항 이상 해보자
구구레터 서비스의 근거를 더 찾기 위해 설문 조사를 진행했는데, 생각보다 재밌는 조사가 나왔다.
그건 앞쪽에는 이런 서비스가 크게 필요없다 라는 식으로 답하다가 뒤로갈수록 이런 서비스가 필요하다 라는 식으로 답변을 했다
내일 할 일
우리 서비스는 예쁜 카드를 보내는 서비스가 아니라, 가까운 관계 안에서 말하지 못했던 마음을 용기 내어 전할 수 있게 돕는 서비스다.
이 문장이 정리되니, 다음에 해야 할 일도 조금 더 분명해졌다.
이제는 발신자 중심 유저플로우를 기준으로 기능명세서를 쪼개고, 카드 작성·공유·수신 흐름을 먼저 구체화해야 한다.
