[2026년 07월 30일 ~ 2026년 8월 3일] 최종 프로젝트 (19)

2026년 07월 30일 목요일 ~ 31일 금요일

• 7월 30일은 발표 자료를 마감하고 마지막으로 문서를 한번 더 점검했다.
• 7월 31일 이제 정말 완료하여서 오전에 문서 제출을 마지막으로 확인하고 제출했다. 나는 생일이라 오후에는 생일파티를 하고 쉬었다.

2026년 08월 03일 월요일

📌 오늘 한 일

• 최종 프로젝트 발표회 참여
• 다른 팀의 최종 프로젝트 발표 청취
• 구구레터 발표 및 전체 피드백 확인
• 제출 문서 기반 PM 심사위원 피드백 세션 참여
• 팀원 평가 작성
• 박람회 참여 및 프로젝트 마무리

---

다른 팀의 최종 프로젝트 발표

오늘은 다른 팀들의 최종 프로젝트 발표를 들었다.

모든 팀이 오랜 기간 준비한 만큼 결과물에서 많은 고민과 노력이 느껴졌다. 특히 몇몇 프로젝트는 문제 정의부터 해결 방향까지의 논리가 분명해, 큰 추가 리서치 없이도 “왜 이 문제를 풀었고 왜 이 솔루션을 선택했는지”가 자연스럽게 납득됐다.

발표를 들으며 우리 팀은 실행과 데이터 수집에는 강했지만, 프로젝트 앞단의 문제 정의와 솔루션 사이의 논리적 연결은 상대적으로 약했다는 점을 다시 느꼈다. 실제로 구구레터도 여러 차례 “서비스를 만든 이유와 구구레터만의 차별점이 더 명확해야 한다”는 피드백을 받았다.

---

구구레터 발표 피드백

첫 번째 발표 피드백에서는 구구레터가 기존 메신저나 손편지와 비교해 어떤 고유한 경험을 제공하는지가 더 선명해야 한다는 의견을 받았다.

구구레터는 가까운 관계에서 마음을 표현하고 싶지만 어색함이나 부담 때문에 행동하지 못하는 문제를 다루고 있다. 이 문제 자체와 관련 심리 리서치는 긍정적으로 평가받았다.

다만 다음 질문에는 충분히 답하지 못했다.

카카오톡이나 손편지로도 마음을 전달할 수 있는데, 사용자가 왜 구구레터를 거쳐야 하는가?

심사위원은 아버지와 자녀의 관계 개선을 위해 매일 질문을 제공하는 서비스를 사례로 들었다. 해당 서비스는 단순히 “대화하세요”라고 제안하는 것이 아니라, 서로를 알아갈 수 있는 질문을 매일 제공함으로써 서비스만의 행동 장치를 만들고 있었다.

구구레터 역시 단순히 쪽지를 작성하는 공간을 제공하는 것을 넘어, 사용자가 마음을 표현할 수 있도록 돕는 질문·상황·콘텐츠 등 구구레터에서만 가능한 장치가 필요하다는 피드백이었다.

또 다른 심사위원은 우리 팀을 실행력이 강한 팀으로 평가했다. 퍼널별 지표를 확인하고 개선한 과정, 운영 업무를 자동화한 과정은 장점으로 언급됐다.

반면 초기 가설이었던 “기존 메시지 수단에서 느끼는 어색함과 명분 부족을 구구레터가 해결한다”는 부분이 실제 제품 경험과 충분히 연결되지 않았다는 점은 아쉬움으로 남았다.

---

설문조사와 문제 정의에 대한 피드백

이후 제출한 브로셔, PRD, 기능명세서, 장애보고서 등을 바탕으로 세 명의 PM에게 추가 피드백을 받았다.

첫 번째 심사위원은 문제 정의 단계에서 진행한 설문조사의 대상과 기준을 구체적으로 질문했다.

우리 팀은 내일배움캠프, 지인, 에브리타임, 설문 이벤트 채널 등 다양한 곳에 설문을 배포했고 약 60명의 응답을 확보했다. 초기에는 응답 수를 확보하는 데 집중했고, 이후에는 마음 표현의 어려움을 강하게 느끼는 사용자를 구분할 수 있는 문항을 추가했다.

그러나 다음 기준은 충분히 설계하거나 설명하지 못했다.
- 누구를 핵심 타깃으로 보았는가
- 왜 그 집단을 조사했는가_
- 마음을 표현하고 싶은 사람 중 실제로 어려움을 느끼는 사람은 얼마나 되는가
- 설문 결과가 구구레터의 필요성을 얼마나 뒷받침하는가

심사위원은 문제 정의 단계에서 조사 대상이 명확하지 않으면, 이후 가설과 기능, 지표까지 연쇄적으로 흔들릴 수 있다고 설명했다.

전체 응답자의 90%가 마음을 표현하고 싶다고 답했더라도, 이들이 실제로 표현에 어려움을 느끼는지는 별개의 문제다. 마음 표현을 원하지만 어려움을 겪는 집단이 어느 정도 규모인지 확인했어야 구구레터가 해결하려는 문제의 크기를 판단할 수 있었다.

설문조사는 단순히 수치를 얻는 과정이 아니라, 어떤 사람에게 어떤 문제를 검증했는지 설명할 수 있어야 근거로 기능한다는 점을 배웠다.

---

시장 수요와 서비스 차별점

오픈채팅방, 블라인드, 인스티즈 등에서 사람들이 칭찬과 격려를 요청하는 행동을 문제의 근거로 사용했지만, 실제로 이런 활동이 전체 게시글에서 어느 정도 비중을 차지하는지는 확인하지 못했다.

심사위원은 이러한 행동이 일부 존재한다는 사실만으로는 시장 수요가 검증됐다고 보기 어렵다고 설명했다.

수요가 작더라도 반복적으로 사용하는 강한 사용자층이 있는지, 혹은 여러 채널에서 넓게 발생하는 문제인지 구분해야 했다. 이를 위해서는 게시글 수, 반복 활동, 사용자 특성 등 더 구체적인 로우 데이터가 필요했다.

또한 카카오톡이나 선물하기 같은 기존 서비스가 있음에도 유사한 서비스가 크게 성장하지 못한 이유를 먼저 검토했어야 한다는 피드백도 받았다.

우리 팀은 초기에는 다음과 같이 생각했다.

- 커뮤니티형 쪽지 서비스는 직접적인 비즈니스 모델이 약하다.
- 일회성 사용에 그칠 가능성이 크다.
- 명확한 수익 구조가 없으면 대기업에서도 우선순위가 낮을 수 있다.

하지만 이것만으로는 충분하지 않았다. 실제로 구구레터가 경쟁력을 가지려면 사용자가 작성하고, 링크를 공유하고, 수신자가 다시 들어오는 복잡한 행동을 감수하면서도 이 서비스를 선택해야 할 이유가 필요했다.

단순히 “카카오톡 메시지는 일상 대화 속에서 묻히지만 구구레터는 별도로 저장할 수 있다”는 설명만으로는 부족하다. 아카이빙 외에도 구구레터에서만 가능한 명확한 차별점을 만들어야 한다.

---

앞으로 제품을 어떻게 발전시킬 것인가

심사위원은 구구레터를 실제 프로덕트로 계속 운영한다면 어떤 방향으로 발전시키고 싶은지 질문했다.

팀원들은 공통적으로 리텐션을 높이고, 사용자 간 상호작용을 강화해야 한다고 답했다.

논의된 방향은 다음과 같다.

• 쪽지 도착 알림
• 답장 기능 강화
• 생일·시험·입사·퇴사·연말 등 표현 계기 제공
• 질문이나 주제 콘텐츠 제공
• 1:1 관계 외 그룹 쪽지 확장
• 친구 관계를 연결해 서비스 내부에서 바로 발송하는 구조
• 모바일 선물 및 기프티콘 연계
• 감정과 상황에 따른 선물 큐레이션
• 기업 내 칭찬 문화와 연계한 B2B 서비스
• 기업 마케팅 비용을 활용한 저가 상품 및 샘플링

내가 생각한 비즈니스 방향은 쪽지와 가벼운 선물을 결합하는 것이다. 카카오 선물하기는 상품의 가격대가 부담스럽거나 마음보다 상품이 중심이 되기 쉽다고 느꼈다.

구구레터에서는 사용자가 표현하려는 감정과 상황을 먼저 선택하고, 그에 맞는 저렴한 모바일 선물이나 브랜드 상품을 추천하는 구조를 생각했다. 브랜드는 마케팅 비용을 부담하고, 사용자는 낮은 가격으로 상품과 쪽지를 함께 보낼 수 있다.

다만 심사위원은 비즈니스 모델보다 먼저 사용자에게 구구레터를 반드시 사용해야 하는 이유를 만들어야 한다고 강조했다.

---

리텐션과 열람률에 대한 질문

구구레터의 전체 발송 대비 열람률은 약 70%, 미열람률은 약 30%였다.

처음에는 이 수치를 리텐션 문제와 연결해 설명하려 했지만, 열람률과 리텐션은 다른 지표다.

• 열람률: 발송한 쪽지가 실제로 확인됐는가
• 리텐션: 사용자가 다시 돌아와 반복 행동했는가
• 상호성: 수신자가 다시 발신자가 되었는가

열람률은 리텐션의 선행 조건일 수 있지만, 열람률 자체가 리텐션은 아니다.

심사위원은 마케팅 기간의 데이터가 전체 지표에 섞여 있으면 원인을 잘못 해석할 수 있다고 설명했다. 실제로 쪽지 발송 이벤트에서는 보상을 받기 위해 쪽지만 보내고, 수신자가 확인하지 않는 행동이 발생했을 가능성이 있었다.

따라서 다음과 같이 데이터를 구분해야 한다.

• 마케팅 유입과 자연 유입
• 이벤트 참여성 발송과 일반 발송
• 발송 방식별 열람률
• 발송 후 24시간·72시간 이내 열람률
• 알림 부재로 인한 미열람
• 링크를 복사했지만 실제로 전달하지 않은 경우
• 서비스 필요성을 느끼지 못해 확인하지 않은 경우

전체 열람률 하나만 보는 것이 아니라, 어떤 유입과 행동에서 미열람이 발생했는지 세분화해야 실제 문제를 찾을 수 있다.

---

로그인 플로우 개선에 대한 피드백

브로셔에는 v1에서 v1.1로 넘어가면서 친구 홈 진입 대비 발송 완료율이 10.91%에서 23.08%로 높아졌지만, 이를 로그인 CTA 변경의 단독 효과로 단정하지 않는다고 작성했다.

심사위원은 인과관계를 성급하게 단정하지 않은 태도가 좋았다고 평가했다.
이후 v2에서는 쪽지 작성 전에 로그인이 필요하다는 사실을 미리 안내했다.

그 결과 작성 시작률은 이전보다 낮아졌지만, 쪽지를 모두 작성한 후 로그인 화면을 보고 이탈하는 사용자는 거의 없어졌다.

이를 통해 다음과 같이 해석했다.

• 사전 안내를 하면 작성 시작 사용자는 줄어들 수 있다.
• 그러나 사용자가 뒤늦게 로그인을 발견해 작성한 내용을 포기하는 문제는 줄어든다.
• 서비스 제약을 숨겨 전환율을 높이는 것보다, 사전에 정확하게 알리고 의도가 있는 사용자를 발송까지 연결하는 편이 낫다.

단순히 상위 퍼널의 숫자가 높아졌는지만 보는 것이 아니라, 어떤 사용자 경험이 더 신뢰할 수 있는지 판단한 사례였다.

---

보조 플로우에 대한 새로운 해석

구구레터에는 두 가지 쪽지 발송 방식이 있다.

1. 친구가 공유한 홈에 들어가 바로 쪽지를 작성하는 메인 플로우
2. 자신의 홈에서 쪽지를 작성한 뒤 링크를 외부 채널로 전달하는 보조 플로우

초기에는 최근 쪽지 서비스들이 자신의 홈을 열고 다른 사람에게 작성을 요청하는 구조를 주로 사용하고 있어 첫 번째 방식을 메인으로 보았다.

그러나 실제 데이터에서는 보조 플로우도 약 40%에 가까운 사용량을 보였다. 이는 초기 리서치에서 충분히 예상하지 못했던 행동이었다.

보조 플로우는 사용자가 자신의 홈을 공개하지 않아도 특정 사람에게 먼저 마음을 표현할 수 있다는 장점이 있었다. UT에서도 홈을 공개해 쪽지를 요청하는 것은 부담스럽지만, 내가 먼저 한 사람에게 쪽지를 보내는 것은 괜찮다는 의견이 있었다.

이를 통해 구구레터 사용자도 다음과 같이 구분할 수 있다는 생각이 들었다.

• 자신의 홈을 열고 적극적으로 쪽지를 요청하는 사용자
• 친구의 홈에서 쪽지를 작성하는 사용자
• 공개 요청은 부담스럽지만 특정 사람에게 먼저 표현하는 사용자

다만 현재 보조 플로우의 마지막 단계가 외부 메신저로 빠져나간다는 점은 한계다.

서비스를 계속 운영한다면 친구 관계나 초대 연결을 만들고, 구구레터 내부에서 바로 수신자를 선택해 발송할 수 있도록 개선하는 방향을 고려할 수 있다.

---

장애보고서와 운영 리스크 피드백

장애보고서를 바탕으로 서비스 운영 권한과 인프라 리스크에 대한 질문도 받았다.

구구레터의 서버 결제, 복구 권한, 소유권 일부가 개발 튜터에게 있어 장애가 발생했을 때 팀이 직접 조치하기 어려운 구조였다.

심사위원은 이러한 구조적 리스크를 프로젝트 초기에 식별했어야 한다고 지적했다.

우리 팀은 다음 내용을 충분히 확인하지 못했다.

• 무료 플랜의 제한
• 유료 전환 기준
• 서버와 계정의 실제 소유자
• 결제 카드와 유효기간
• 장애 발생 시 복구 권한
• 모니터링 담당자
• 배포 직후 대응 체계
• 백업과 재해복구 방식
• 운영에 필요한 추가 개발 공수와 비용

서비스를 출시하는 것은 기능 개발로 끝나지 않는다. 특히 오픈 직후에는 사용자 유입이 발생하는 시간대에 모니터링하고, 장애가 발생했을 때 누가 어떤 권한으로 대응할지 정해야 한다.

서버 이중화나 재해복구 체계는 안정성을 높이지만 비용과 개발 기간이 증가한다. PM은 안정성만 요구하는 것이 아니라, 개발 공수·비용·리스크 사이에서 적절한 수준을 결정해야 한다.

개발자 출신인 나는 장애 해결책을 직접 떠올리는 데 집중했지만, 심사위원은 PM으로서 먼저 개발자에게 예상 리스크와 운영 조건을 질문하고 조율했어야 한다고 피드백했다.

---

PM의 커뮤니케이션 능력

심사위원은 PM의 커뮤니케이션 능력을 단순히 경청하거나 말을 부드럽게 하는 것으로 설명해서는 안 된다고 말했다.

업무에서의 커뮤니케이션은 개발자·디자이너·사업 담당자가 사용하는 언어와 제약을 이해하고, 그들의 관점으로 대화할 수 있는 능력이다.

PM은 다음 내용을 얕고 넓게 이해해야 한다.

• 서비스의 기본 아키텍처
• 데이터가 오가는 구조
• 각 직군이 담당할 수 있는 범위
• 개발 방식과 일정
• 운영 모니터링
• 장애 대응과 복구
• 비용과 개발 공수
• DB와 데이터 수집 구조

개발자 출신이라는 강점도 기술을 직접 구현할 수 있다는 점보다, 기술적 제약과 구현 가능성을 이해해 현실적인 제품 판단을 할 수 있다는 방향으로 설명해야 한다.

---

목적 기반 사고와 OKR

한 심사위원은 문제 정의보다 더 근본적으로 중요한 것은 목적이라고 설명했다.

문제를 잘 정의하는 것도 목적을 달성하기 위한 하나의 방식이다. 항상 다음 질문을 반복해야 한다.

우리가 이루려는 상태는 무엇인가?

지금 하는 일이 그 목적을 실제로 달성하는가?

이를 구체화하는 방법으로 OKR을 소개해 주었다.

• Objective: 도달하고 싶은 상태를 명확하게 표현한 문장
• Key Results: 해당 상태에 도달했는지 판단할 수 있는 측정 가능한 결과

구구레터에 적용하면 단순히 “답장 기능을 만든다”가 목표가 되어서는 안 된다.

예를 들어 다음과 같이 설정할 수 있다.

Objective

마음 표현이 실제 관계 행동으로 이어지는 반복 구조를 만든다.

Key Results

• 발송 후 72시간 이내 열람률 개선
• 수신자에서 발신자로 전환되는 비율 측정 및 개선
• 첫 발송자의 14일 이내 재발송률 개선
• 열람 후 답장 또는 홈 공유 전환율 개선

기능은 Key Result를 달성하기 위한 실행 수단이다.

---

PM 채용에서 중요하게 보는 것

심사위원들은 신입 PM을 평가할 때 결과와 그 결과를 만든 사고 과정을 중요하게 본다고 말했다.

주로 다음과 같은 질문을 받는다고 했다.

• 왜 이 문제를 선택했는가
• 어떤 결과를 만들려고 했는가
• 어떤 판단으로 이 방법을 선택했는가
• 다른 대안은 무엇이었는가
• 결과가 의도한 판단 때문인지 어떻게 확인했는가
• 실패했다면 무엇을 배웠는가

좋은 결과가 있다면 그 결과를 만든 과정이 탄탄할 가능성이 높다. 반대로 실패한 프로젝트라도 명확한 가설과 러닝이 있다면 의미 있는 경험이 될 수 있다.

면접 준비는 마지막에 말을 외우는 것이 아니라, 프로젝트를 수행할 때부터 판단 과정이 촘촘하게 정리되어 있어야 한다는 말이 인상 깊었다.