어제(3일차)는 "설문조사 팀(3명)"과 "아이디에이션 팀(2명)"이 나뉘어 활동을 했다. 나는 이전에 설문조사를 배포한 경험이 있기에 설문조사 팀으로 배정되었다.

따로 활동을 하다가 오후 7시 30분에 두 팀이 함께 모여서 이야기를 나누게 되었는데, 저녁 튜터님께서 오시는 시간대와 겹치게 되었고, 그러다보니 함께 서로의 첫 공유물을 튜터님 앞에서 보는 상황이 펼쳐졌다.

우리 조에서 그동안 생각해온 모습은 "사용자의 맥락을 고려한 인앱 푸시 설계를 통해 사용자가 감정 기록 어플에 꾸준하게 접속할 수 있도록 한다"였는데, 아이디에이션 팀이 구상해온 모델은 인앱 푸시 알림이 아닌 "이메일 알림"이어서 꽤 당황스러웠다.

그러나 같이 이야기를 나눌 시간이 부족해서 '왜 앱 푸시 알림에서 이메일로 변경이 되었는지'에 대한 자세한 이야기를 하지 못했고, "내일 12시까지 조원들 각자 아이디에이션을 해온 것을 발표하고, 어떻게 프로덕트를 설계하는 것이 좋을지"에 대해 이야기를 나누기로 했다.

🏃‍♀️ 오늘 한 일

12시에 조원들을 만나기 전에 부트캠프 내의 PM튜터님과 개발 튜터님께 찾아가 궁금한 점에 대해 여쭈어보았다.

"저희 조가 가려는 방향은 ‘알림을 적절하고 불쾌하지 않게, 그리고 사용 지속성을 위해서 도움이 되도록 주는 것’인데 메일로 알림을 하게 되면 적절하지 않을까봐, 그리고 실제로 배포를 했을 때 저희 조에서 보고자 했던 '지표'라던가 '개선'이 무의미해질까봐 걱정이 됩니다.'

👩‍🏫 PM 튜터님의 피드백 요약

✅ A. 이메일 알림으로 전환은 가능 • 문제 정의 자체가 “개인화되지 않은 알림 구조 문제”였기 때문에, 이메일 방식도 논리적으로 이어질 수 있음. • 단, 이메일로 전환하는 경우에도 개인 맞춤 맥락(위치, 일정 등)을 고려한 설계를 잘 해야 함. • 이메일 안에 버튼(CTA)을 넣어 서비스로 직접 연결되도록 구현하면 전환율 개선 가능.

⚠️ B. 이메일 알림의 단점 및 허들 • 사용자가 이메일 앱 알림을 꺼두었거나, 열어보지 않으면 실효성이 없음. • 이메일 알림은 접근까지의 허들이 많음: 1. 이메일 알림 허용 설정 2. 메일함 진입 → 클릭 → 앱 진입 • → 따라서 온보딩 단계에서 알림 설정 유도 필요 (예: “이메일 알림을 허용해 주세요”)

** 🎯 3. 지표 설정 및 유저 수 관련 조언**

📊 A. 1차 MVP 지표에 너무 집착하지 말기 • MVP 1차 지표는 정확도보다는 방향성 확인용. • 실무에서도 1차 목표치는 대부분 실패하거나 조정됨. • → “달성하겠다”보다 “가능성 테스트”의 관점에서 설정해야 함.

👥 B. 유의미한 테스트를 위한 사용자 수 • 1차 배포 시 유저 50~100명 확보 권장 (지표 확인 및 개선용). • 내부 팀원, 가족, 지인 등 지인 네트워크 적극 활용. • 이후 개선된 버전은 타겟 커뮤니티를 활용한 바이럴 및 마케팅 추진.

** 🧩 4. 참고 사례** • ‘첨벙’ 팀 : 자유 수영 관련 서비스 → 커뮤니티 활용 → 약 300~400명 확보 • ‘무지개 다리’ 팀 : 반려동물 사별 위로 편지 → AI 활용 → 커뮤니티 바이럴 통해 한 달간 회원 가입자 1,000명 이상 확보

👨‍🏫 개발 튜터님의 피드백

📌 1. 푸시 알림 기능 관련 기술적 제약

❌ 인앱 푸시 알림 : 앱 설치 기반 기능이며, 프레이머는 웹앱이라 기술적으로 구현 불가능. ❌ 웹 푸시 알림 : 구현 가능은 하나, 6주 내 MVP 수준에서 구현하기에는 난이도 높음. ✅ 이메일 알림 : 가장 현실적인 구현 방법. 기술적 진입장벽 낮고, 단순한 텍스트/링크 포함 가능. ❗ 앱 설치 유도 기획 : 비용이 많이 들고 최신 트렌드에 부적합, 웹앱으로 유지하는 게 바람직함.

📨 2. 이메일 vs 카카오톡 메시지/챗봇

이메일

• 장점 : 구현 쉬움, 웹과 궁합 좋음
• 단점 : 메일 앱 알림 설정 필요, 노이즈/스팸으로 인식 가능

카카오 챗봇

• 장점 : 모바일 앱 설치 없이 알림 전송 가능, 사용자 경험 친숙
• 단점 : 카카오 디벨로퍼 등록, 채널 생성 및 정책 준수 필요전화번호 수집 등 민감정보 처리에 정책 허들이 존재

💬 3. 대체 구현 아이디어 및 조언

• 온보딩 시 카카오 챗봇 추가 유도 + 메시지 전송 : 현실성 있음, 기술 난이도는 낮고 정책 리서치가 관건
• 구글 캘린더 연동 → 일정 기반 알림 : 불가능에 가까움, 구글과의 제휴/API 인증 필요
• 프레이머 내 자체 캘린더 UI 구성 : 가능, 일정 직접 입력 + 저장은 구현 가능하나, 매력도와 우선순위 검토 필요
• 감정일기 기록 기능 외 기존 프로덕트의 기능 껍데기 구현 여부 : 자유롭게 결정 가능, 필수 아님, 단 껍데기 제공 시 개선 포인트 전달에 유리함

⚠️ 4. 프레이머는 웹앱이다: 팀 내 혼동 정리 필요

•** 웹앱 : 브라우저 기반 접속, 설치 불필요 → 현재 프레이머가 만드는 것 • **앱(앱 어플리케이션): 앱스토어 설치 기반, 알림 구현 가능하지만 비용/난이도/정책 부담 큼 • → 웹앱 기준으로 접근해야 함 (모바일 브라우저 기준 UX)

"🗣PM이라면 앱 vs 웹 차이를 반드시 알고 있어야 한다. 팀원과 인식 정렬 필요”

🔧 5. MVP 개발 범위와 목표에 대한 리마인드

• *기능 범위 *: 완성도보다 문제 정의와 설계 논리 중심. 껍데기만 구현해도 무방함.
• 구현 우선순위 : ‘지금 필요한 핵심 기능 중심’으로 구성. 기능 모두 구현할 필요 없음.
• *지표 기준 *: 1차 MVP는 테스트용 → 정확한 지표보다 변화 방향과 개선 기반 확보가 중요
• 추천 접근 : 기능 구현 < 논리 설계 및 기획 근거. 발표 시 이를 강조하는 게 중요

🌌 저녁 스크럼 시간 재편성

우리 조는 오전 9:30에 아침 스크럼을, 오후 7:30에 저녁 스크럼을 했는데 그러다보니 저녁 튜터님께서 우리 조에 방문하시는 시간과 겹치게 되어, 조에서 얼라인되지 않은 내용을 튜터님 앞에서 발표를 해야하는 상황이 연속적으로 발생해서 조원들과 저녁 튜터님(우리의 이야기를 듣는 튜터님의 거친 생각과... 불안한 눈빛과...)의 동공지진을 볼 수 있었다.

그래서 오전 스크럼 시간은 그대로 두되, 저녁 스크럼 시간을 오후 7:30 -> 오후 5:00로 당겨서(특강이 있거나 조사가 미루어지는 등의 상황은 예외) 조에서 얼라인된 내용을 튜터님에게 이야기하고 피드백을 받을 수 있도록 하기로 했다.

💬 오늘의 회고

오늘 두 분의 튜터님과의 피드백을 통해, 아이디어가 아무리 매력적이어도 “현실적인 구현”과 “기술적 제약”을 고려하지 않으면 소용없다는 것을 체감했다.

우리가 하고자 했던 건 ‘사용자에게 맥락 기반의 맞춤 앱 기반 푸시 알림을 제공하여 사용 지속성을 높이는 것’이었지만, 인앱 푸시가 기술적으로 불가능하다는 사실 앞에서 방향을 틀 수밖에 없었다.

'사용자에게 이메일 알림이 나을 것인가, 카카오톡 알림이 나을 것인가'에 대한 니즈는 설문지를 돌리면서 확인해보기로 했다.

만약 이메일 알림이 압도적으로 니즈가 많다면 이메일 알림으로, 카카오톡 알림이 압도적으로 니즈가 많다면 카카오톡 알림으로 (물론 정책상의 이유로 불가능한 경우에는 이메일 알림으로 가야한다는 점에서 조원들 모두 동의했다), 그리고 만약 니즈가 반반으로 비슷하다면 한 그룹은 이메일 알림을, 다른 그룹에는 카카오톡 알림을 제공하여 A/B 테스트를 하는 방향도 있음을 확인했다.

MVP는 결국 완성도가 아니라, “기획 → 제약 → 재해석 → 실행”의 사이클을 어떻게 설득력 있게 끌고 가느냐의 싸움이라는 걸 오늘 배웠다.

앞으로 이 프로젝트가 어떻게 흘러갈지 굉장히 궁금해진다.

감정 기록 앱의 방향성에 대한 튜터님의 피드백 정리

📌 루트 1 : 맥락에 맞는 감정 기록 푸시 알람하기

🔍 주요 피드백 요약 • 상황 맥락 정보 수집은 핵심이자 난관 • 감정 기록이 맥락과 함께 저장된다면 데이터 가치가 높아짐. • 위치, 시간, 일정 등 다양한 정보를 수집해야 하며, 이 과정이 진입장벽이 될 수 있음. • 알림(푸시) 설계는 정보 수집보다 중요할 수 있음 → 푸시가 과하면 노이즈 발생 가능성 있음. • 개인화 추천 시스템을 설계할 때 필요한 것들 • 다양한 상황/페르소나에 맞는 정답 시나리오 설계 필요. • 예: “헬스를 좋아하는 1인 가구” → 1인분+건강식 메뉴 추천. • UX 라이팅도 핵심! “오늘 기분이 어땠나요?” 그 이상을 고민해야 함. • 로직을 구성할 때 필수적으로 정의해야 할 3가지

1.    어떤 데이터를 수집할 것인가?
2.    그 데이터를 어떻게 받을 것인가?
3.    그 데이터를 통해 무엇을 줄 것인가?

📌 루트 2 : 감정 기록 → 심리상담 연결

🔍 주요 피드백 요약 • 사용자 니즈 관점에서 다소 어긋날 수 있음 • 유저는 “내 감정을 아는 상담사”보다는 “괜찮은 상담사”를 원함. • 기록 기반 추천은 공급자 중심적 사고일 수 있음. • 이미 사용자는 감정 기록을 따로 하고 상담사에게 보여주는 방식에 익숙함 • 오히려 심리상담 도구로서의 감정기록은 상담사 쪽에서 먼저 제안하는 경우도 많음. • 기록 앱 → 상담 연결이 자연스러운 플로우가 아닐 수 있음 • 감정 기록은 상담보다 일상에서 자기 관리 루틴으로 받아들여짐. • 유저는 내가 쓰는 기록을 다운로드해서 상담에 활용할 수 있는 기능 정도만으로도 충분할 수 있음. • 비즈니스 모델 고민은 지속적으로 병행 필요 • 감정 기록 앱의 수익 모델은 대부분 유료 플랜 (ex. 프리미엄 기능). • ‘감정 기반 추천’이 킬러 기능이 될 수 있다면 유료화 가능성도 있음.

🧠 그 외 인사이트 및 질문 정리

🧭 감정 기록 도메인에 대한 PM 관점 피드백 • 도메인 자체가 취업/실무 연계 측면에서 특이할 수 있음. • 하지만 ‘문제를 어떻게 풀었는가’가 더 중요하므로, 논리적 구조와 사용자 중심 설계에 집중하면 충분히 포트폴리오로 활용 가능.

✍️ 느낀 점

• 감정 기반 서비스를 설계할 때, 데이터 수집의 정교함과 사용자 피로도의 균형이 정말 중요하다는 것을 실감했다. • 어떤 ‘좋은 아이디어’든, 유저의 기대와 사용 흐름을 벗어나면 실제 활용도나 매력도가 낮아질 수 있음을 깨달았다. • MVP를 설계할 때는 “데이터를 어떻게 받을 것인가”에 가장 많은 리소스를 들여야 한다는 조언이 특히 기억에 남는다. • 비즈니스 모델 없이도 출발할 수는 있지만, 지속 가능성과 확장성을 고려한 BM 설계가 필수라는 점도 다시 한 번 인지하게 되었다.

그렇게 우리는 생산성 어플 리서치를 해보기로 했고, 5명 각자 [투두/루틴], [노트], [시간관리], [감정기록], [커리어로그] 총 5개의 카테고리에 속한 어플 3가지씩을 조사하고, 해당 어플의 pain point와, 해당 카테고리의 어플의 pain point를 우리가 해결해봄직한지에 대해 이야기를 나누어보기로 했다.

나는 [노트] *카테고리를 맡아 노트 어플 3대장이라고 불리는 *노션, 에버노트, 원노트에 대해 조사를 했다.

세 어플 모두 특징과 강점이 달랐는데, pain point는 비슷했다.

• 앱 성능 저하 (로딩, 렉 문제)
• 동기화 오류
• 요금제 불만

과 같은 우리 단에서 해결하기 힘든 문제들이었다.

결국 노트앱은 실서비스 프로젝트의 프로덕트로 가져가기 어렵다고 판단을 했고, 다른 조원들의 발표를 듣고 서로 의견을 나누었다.

📌 주요 의견 정리

❌ 제외 혹은 난이도 높음 판단된 영역

• 노트앱 : 기능이 다양하고 개발 공수가 높아 어려워보임
• 커리어 로그 : 북마크 기반 역채용 기능은 채용 플랫폼 자체가 아니면 구현이 어려워보임
• 시간관리 앱 : 완성도 높은 앱이 많고, UI/UX 개선만으로는 구현 난이도 높음
• 투두 앱 : 이미 경쟁 앱 많고 모방 방지 어려움, 단 설문 기반 개선안 접근은 안전한 대안으로 고려됨

✅ 가능성 높은 주제 : 감정 기록 기반 서비스

• 기존 감정 기록 앱들(무디, 마인디 등)의 한계는 기록에만 그치고 실질적인 기분 개선까지 연결되지 않음
• 감정 기록 + 피드백/개선 전략 제공 구조로 확장 가능성 있음
• 사용 지속성이 낮은 현상 : 기록 자체로 정서적 치유 연결되기 어렵기 때문
• 하단탭 등 UI 공간 재설계를 통해 전문가 연결 기능(ex. 심리상담사 연결) 추가도 고려

💡 제안된 구체적 실행 아이디어

1. 감정 기록 앱 중 완성도 낮은 앱을 선정하여 기능 개선 (ex. CBT 기반 개입 추가)
2. 기존 우수 사례 앱(무디, 마인디 등)의 벤치마킹을 통한 기능 차용
3. 명상 콘텐츠 or 전문가 연결 기능 등 감정→행동 유도 흐름으로 UX 설계

🧭 실행 전략

• Plan A : 감정 기록 앱 리디자인 및 신규 기능 기획 (기분 개선 전략 등 포함)
• Plan B : 감정 기록 주제가 구현상 무리일 경우, 투두 앱 중 설문조사를 통한 개선 방향으로 우회

💬 설문 방식 예시 (Plan B 대비)

• 사용자 수 많은 투두 앱 하나 선정 → UX 설문 배포 ex. "어떤 기능이 불편했는지, 어떤 기능이 추가되었으면 좋겠는지" 등 직접 수요 조사
• 약 50~100명 규모의 서베이

🔚 최종 결정

• 우선적으로 감정 기록 기반 서비스 주제로 실서비스 기획을 시작
• 실행 가능성 평가 후 유지/우회 결정
• Plan B(투두 개선)는 비상 시 우회안으로 설정된 보조 플랜으로 유지

💤 회의 마무리 멘트

• "문제 정의가 가장 어렵고 중요하다. 초반에 시간을 들이는 게 결국 전체 완성도를 좌우한다."
• "모든 도메인에는 길이 있다. 고민하면 반드시 인사이트는 나올 것."

🗓 내일 계획

• 9시 30분에 오전 스크럼
• 감정기록 앱 관련 시장 트렌드, 문제현상 리서치 시작
• 기존 문제정의 구조 참고하여 정리 진행 예정

개인적으로, 제로샷이라던가, 피샷이라던가, COT라던가 알지 못하는 단어들이 초반에 나와서 알아듣기 어려운 특강이었다.

하지만 [주목할 만한 모델 및 특징] 부분에서는 제미나이, 클로드, 챗지피티, 퍼플렉시티, 젠스파크, 릴리스 등 툴에 대한 설명을 해주셔서 _'어떠한 요청을 하기에 적합한 모델과 적합하지 않은 모델이 있는데, 그동안 나는 그런 것들을 고려하지 않고 AI 툴을 써왔구나'_를 느끼게 되었다.

앞으로도 더욱 AI 툴은 정교화될 것이고, 우리 생활에 더욱 밀접해질텐데, AI툴에 대한 공부가 부족했다는 것을 느낄 수 있는 특강이었다.

당장 깊게 AI 툴을 공부하지는 못하더라도, 오늘 특강에서 배운 것처럼 적절한 모델을 적절한 사용처에 사용해야겠다는 생각을 하게 되었다.

✅ 1. Gemini (Google) • 특징: 유튜브 및 구글 검색 API와 직접 연동 가능 • 강점 • 유튜브 영상 요약 • 웹 검색 기반 조사 자동화 • 입력/출력 길이 모두 넉넉함 • 추천 사용처: 시장 조사, 콘텐츠 요약, 멀티모달 분석

⸻

✅ 2. Claude (Anthropic) • 특징: 아티팩트(Artifact) 기능 탑재, 고난도 추론 우수 • 강점 • 코드, 문서, 프레젠테이션의 시각화 • 논리적 추론과 분석 능력 탁월 • 단점: 출력 길이가 짧고 요금이 상대적으로 높음 • 추천 사용처: 기술 검토, 전략 문서 작성, 코드 리뷰

⸻

✅ 3. GPT-4 (OpenAI) • 특징: 감정 인식 및 공감형 커뮤니케이션에 강함 • 강점 • 범용성 (지식 작업, 콘텐츠 생성 모두 가능) • 일정한 품질의 안정된 응답 • 공감형 피드백 및 스토리텔링에 탁월 • 추천 사용처: 회의록 작성, 팀 커뮤니케이션, 스토리텔링 기획

⸻

✅ 4. Perplexity • 특징: 검색 기반 응답에 최적화된 모델 • 강점 • 정확한 출처 기반 정보 제공 • 다중 검색 결과를 통합하여 보고서 형태로 제공 • 추천 사용처: 논문 요약, 리서치 보고서 작성, 출처가 중요한 과제

⸻

✅ 5. 젠스파크 (Genspark) • 특징: 텍스트 → 비주얼 변환 특화 모델 • 강점 • 도식, PPT, 추상 개념 시각화에 강함 • 디자인 스타일 반영 가능 • 단점: 사용 비용이 높고, 수정 시 리소스 소모 많음 • 추천 사용처: 발표자료 제작, 개념 시각화, 와이어프레임 디자인

⸻

✅** 6. 네이버 클로바노트 / 릴리스** • 클로바노트 • 특징: 음성 → 텍스트 자동 변환 • 강점: 회의록 자동 생성, 대화자 구분, 구조화 • 릴리스 • 특징: 요약 및 보고서 자동 생성 특화 • 강점: 의미 기반 요약, 보고서 구조화 능력 • 추천 사용처: 회의 기록, 회의 후 보고서 작성, 음성 기반 업무 기록

내가 하는 고민들이 과연 합당한 고민일지, 아니면 그렇지 않은 고민일지 궁금했다.

Q1. 제가 PM에 잘 맞지 않는 사람일까요?

MVP 프로젝트를 하면서 초반에 프로덕트를 정하고 논리를 디벨롭 하는 부분에서 내가 기여한 바가 적은 것 같아, 자주 찾아뵈었던 부트캠프 내의 PM튜터님께 찾아가 고민을 털어놓았다.

내가 생각하기에 PM은 논리력이 좋아야하는데, 그 부분에서 크게 두각을 드러내지 않는 것 같아 '내가 PM으로서의 역량이 많이 부족한 사람인가?'라는 의문이 들었다.

A1-1. 충분히 잘 하고 계십니다.

다행히도 튜터님은 "역기획을 할 때 거의 매일 이야기를 나누었는데, 그때 OO님이 논리력이 떨어진다고 느끼지 못했다", "논리적으로 자신이 생각하고 있는 문제 정의부터 해결책을 도출하는 과정에서 충분히 잘 해오셨다", "많은 분들이 문제를 정의하고 가설을 도출하는 논리를 보았는데 거기서 OO님은 절대 못하는 축에 속하지 않습니다. 잘하는 축에 속합니다"라고 말씀해주시며, '아마 지금 OO님이 속한 조에 잘 하시는 분들이 많아서 그렇게 느낀 것 같다'고 말씀해주셨다.

내가 속한 조의 조원들이 아이데이션하는 속도나 생각하는 게 빨라서 상대적으로 내가 '잘 못 하나? 나 느린가?'하면서 위축이 되었는데, 자주 찾아뵌 튜터님이 이렇게 말씀해주시니 위안이 되어었다.

A1-2. "나는 어떠어떠한 PM이 될 것이다"라는 커리어를 세워보세요.

"모든 PM이 다 말을 많이 하고, 의견을 많이 제시하는 건 아닙니다. 그러지 않아도 괜찮아요. 여기 계신 튜터님들 모두 PM이고 최소 3년에서 5년 이상 경력을 가지신 분들임에도 불구하고 회의를 할 때 말 많이 하는 사람과 말 안 하는 사람이 정해져 있어요. 그렇기 때문에 이거는 그냥 모든 PM이 다 '이러한 성향이어야 되고, 말을 많이 해야 되고, 의견 아이디어가 많고' 그런 건 아닙니다. 그거는 OO님이 나름대로 '나는 무슨 PM이다'라고 길을 세우고 그 길을 꿋꿋이 가시면 돼요."

Q2. 퀄리티를 중요시 여겨서 시간이 다른 사람보다 들어가는 편인데, 괜찮을까요?

조원분들과 와이어 프레임을 그릴 때에 느낀 건데, 나는 퀄리티를 중요시 여기다보니 자연스럽게 다른 분들보다 시간을 더 많이 쏟는 경향이 있었다. 이전에 다른 튜터님께 "PM이 앞단에서 시간을 쓰면 뒷단에서 쓸 시간이 줄어든다"라고 말씀해주셔서 그 부분이 걱정이어서 이에 대해 여쭈어보았다.

A2. 디자이너에서 PM으로 직무 변환하는 사람에게 많은 사례입니다.

"디자이너에서 PM으로 업무하실 때 가장 어려움을 겪는 게 이거더라고요. 디자이너들은 디자인을 통해서 완성도를 높이시는 분들이라 초기 와이어 프레임을 그를 때 다른 분들에 비해서 완성도 높게 그리십니다. 유저 플로우 만들 때도, 아주 사소한 기획 문서도 되게 완성도 있게 그리시는 문제가 있었어요. 이게 문제라고 하기는 조금 그런 거긴 한데, PM이 앞단에서 시간을 많이 빼먹으면 안 되긴 해요. 그래서 그 부분은 동의를 하고, 이거는 OO님이 이번에 MVP 프로젝트 같은 걸로 연습을 해보시면 좋을 것 같습니다. Lo-fi로 그리는 연습을 해보시면 좋을 것 같습니다."

Q3. 에듀테크에 관심이 있는데, 에듀테크는 정보를 찾는 게 좀 어려운 것 같더라구요. 어떻게 찾아나가야 할지 조언을 얻고 싶습니다.

A3. 장벽이 높은 것 중에 가장 큰 이유가 저는 "회사가 많지 않아서"인 것 같습니다.

"다른 곳도 똑같기는 하겠지만, 에듀테크도 B2C, B2B, B2G 이렇게 나눠서 볼 수 있습니다. 여기에서 저는 주니어가 가기에 적합한 데가 B2C라고 생각을 하거든요. B2C에서 어느 정도 도메인 지식을 쌓아야 B2B나 B2G 쪽으로 갈 수 있다고 생각이 들어요. B2B나 B2C 쪽은 아무래도 우리가 프론트하고 백을 나눠서 보면, 백단의 개발이 많거든요. '이 시장이 어떻게 돌아가는지 알아야' 백오피스 개발을 할 수가 있을 것 같아서, 일단은 스파르타나 인프런 같은 회사들을 우선적으로 공부해 보시면 좋을 것 같습니다.

Q4. 에듀 테크에 지원할 때, 포폴에 에듀 관련 프로젝트가 없어도 괜찮을까요?

A4. 있으면 더 좋지만, 없어도 됩니다.

"이런 질문을 하시는 분들한테 다 드리는 내용인데요, 스스로 에듀테크 관련된 케이스 스터디를 해보신다거나, 그래서 그 스터디한 내용들을 우리가 TIL 올리는 것처럼 나름대로 정리를 하시고 그걸 넣어주세요. 그렇게 포트폴리오에 넣으시면 아무래도 프로젝트보다는 좀 덜하기는 하겠지만, 그래도 '나름 도메인 지식이 있다'를 보여주는 거를 하셨으면 좋겠어서 그거는 스스로 나중에 해보시면 좋을 것 같습니다."

오랫동안 지녀왔던 고민을 튜터님께 털어놓고, 또 조언을 받음으로써 자신감도 얻을 수 있었고, 앞으로 어떻게 하면 좋을지에 대한 방향성도 받을 수 있어서 뜻깊은 시간이었다.

다음에는, 조언 받는 내용들을 실천해보고 다시 튜터님께 찾아뵈어야겠다.

논리적이라는 건, 단지 말이 그럴듯하다는 뜻이 아니다. 문제를 해결하기 위한 이유와 근거를 명확히 설명하고, 합리적인 방식으로 의사결정을 내리는 것을 뜻한다.

즉,

• 데이터를 바탕으로 판단하고,
• 그 과정과 결과에 대해 이해관계자가 납득할 수 있도록 설명할 수 있어야 한다.

2. 왜 PM에게 논리적 사고가 중요한가?

✅ 문제 해결의 기본이 된다 문제가 생겼을 때 감이나 추측보다 데이터 기반 분석을 통해 접근하면, 설득력 있는 결정을 내릴 수 있다.

ex) ❌ "이 기능 아무도 안 쓰니까 그냥 없애죠." ✅ "기능 클릭률이 낮고, 유저 피드백에 ‘찾기 어렵다’는 내용이 많았습니다. UI를 개선하면 사용률이 늘어날 수 있습니다."

✅ 우선순위와 리소스 배분 여러 업무가 겹칠 때, 논리적 사고는 ‘무엇을 먼저 해야 하는지’를 정리해준다. ex) ❌ "일단 급하니까 전부 구현부터 해요." ✅ "현재는 인증 시스템과 데이터 동기화가 가장 중요합니다. 사용자 경험에 직접적인 영향을 주기 때문입니다."

✅ 이해관계자 설득 PM은 다양한 부서와 소통해야 한다. 감정이나 느낌만으로는 설득이 어렵다. 논리적인 설명 + 객관적 근거가 있어야 신뢰를 얻는다.

3. 동료를 논리적으로 설득하는 3가지 방법

1. 주장과 근거를 구분하기 "UX를 개선해야 한다" → 주장 "3개월간 피드백 중 45%가 ‘어렵다’고 응답했다" → 근거 → 주장이 설득력을 가지려면 항상 그에 맞는 근거가 따라야 한다.

2. 문제를 단계적으로 나누기 문제를 작게 쪼개서 분석하고 해결해야 전체 흐름을 파악할 수 있다. ex) 문제: 사용자 이탈률 증가 → 로그인 문제인가? → 앱 속도는 어떤가? → 경쟁 서비스와 비교해보면?

3. 논리적인 흐름 만들기 ‘주제 → 주장 → 근거 → 결론’ 순서로 설명하면, 상대방이 이해하기 쉽고 받아들이기 쉬워진다. ex) 주제 : 새로운 기능 추가 제안 주장 : 사용자 문제 해결 + 제품 가치 향상 근거 : 사용자 요청 60% 이상 결론 : 따라서 이 기능은 우선 개발해야 한다.

💬 커뮤니케이션이란?

커뮤니케이션이란 정보를 전달하고, 교환하며, 이해하는 과정이다. 이 과정에서 핵심은 ‘오해 없이’, ‘의도를 명확히’ 전달하는 것이다. 프로젝트에서 커뮤니케이션이 제대로 이뤄지지 않으면,

• 팀원들이 무엇을 해야 할지 모르게 되고
• 우선순위가 불명확해지며
• 목표 자체가 흔들려, 프로젝트 전체가 실패할 위험이 생긴다.

✅ 좋은 커뮤니케이션 vs 나쁜 커뮤니케이션

좋은 커뮤니케이션은 단순한 말하기가 아니라, → 상호 이해, 효율적인 협업, 갈등 최소화, 관계 형성, 신뢰 구축의 기반이 된다.

특히, 명확성과 간결성은 핵심이다. 말이 많다고 해서 좋은 게 아니라, 핵심 메시지를 빠짐없이, 그러나 간결하게 전달해야 한다.

회의 내용 요약 → 구조화된 정보 전달을 통해 팀원들이 필요한 정보를 빠르게 파악할 수 있다.

🎯 커뮤니케이션의 핵심 포인트

1. 목표와 의도 명확히 하기 무엇을 말하는가보다 왜 말하는가가 더 중요할 수 있다. 불분명한 목표는 혼란을 낳고, 불분명한 의도는 갈등을 만든다.

2. 공감과 감정 관리 감정에 대한 이해는 갈등을 줄이고, 신뢰를 형성한다. 공감은 ‘이해받고 있다’는 느낌을 주고, 감정 관리는 나와 상대방을 위한 성숙한 태도다.

3. 상대방의 관점에서 이해하기 상대가 어떤 배경과 관점을 가졌는지 생각해보는 태도는, 오해를 줄이고 더 나은 소통을 이끈다.

📈 커뮤니케이션 역량 키우기

✔️ 적극적인 경청 그냥 듣는 것이 아니라 왜 그런 말을 했는지 생각하고 질문하는 것

• "왜 그렇게 생각하셨나요?"
• "말씀하신 부분이 어떤 맥락에서 나온 건가요?" → 몸짓, 표정, 반응으로도 경청의 태도를 보이자.

✔️ 명확하고 간결한 표현

• 핵심 메시지를 한 문장으로 정리
• 이후에 세부사항 덧붙이기
• ‘세 가지 핵심 포인트’로 구조화하면 더욱 효과적

📝 오늘의 인사이트

인간관계처럼, 프로젝트가 잘 흘러가느냐, 아니면 중간에 삐걱거리느냐는 결국 커뮤니케이션에 달려 있다. 결국 소통은 단순한 정보 전달이 아니라, ‘서로를 이해하고 협업하기 위한 기술’인데, 이걸 잘 하기가 참 어려운 것 같다.

내가 말하고자 하는 바가 명확한가?, 상대방은 이해하고 있는가?를 계속 점검하고, 더 나은 소통을 할 수 있도록 노력해야겠다.

정보 구조도(IA)는 사용자가 웹사이트나 앱 내에서 정보를 어떻게 찾을 것인가를 정의하고, 그 정보를 어디에 배치할 것인지 설계하는 작업이다. IA는 단순히 기능을 나열하는 것이 아니라, 정보의 흐름을 논리적으로 배치해 사용자가 원하는 정보를 빠르고 쉽게 찾을 수 있도록 돕는 역할을 한다.

🛠️ 정보 구조도를 작성하는 이유

1. 사용자 경험(UX) 개선 사용자는 웹사이트나 앱에서 원하는 정보를 빠르고 쉽게 찾을 수 있어야 한다. IA 설계는 사용자가 직관적으로 탐색할 수 있도록 돕고, 사용자가 불편함 없이 사이트를 이용할 수 있게 한다.

2. 효율적인 협업을 위한 명확한 소통 정보 구조도는 팀 간에 명확한 커뮤니케이션 도구로 활용된다. 기획자, 개발자, 디자이너 등 모든 팀원이 정보의 흐름을 시각적으로 이해할 수 있기 때문에 협업이 원활해진다.

3. 서비스 확장 시 유연한 대응 서비스가 확장되거나 새로운 기능이 추가될 때, 잘 설계된 IA는 쉽게 수정하고 확장할 수 있다. 이를 통해 미래의 변화를 대비할 수 있다.

📋 정보 구조도 작성 방법

1. 기능 목록 작성 시스템 내에서 제공할 모든 기능을 목록화한다. 각 기능이 무엇을 제공할 것인지 구체적으로 정의한다.

2. 카테고리 및 메뉴 구조 설계 기능 목록을 작성한 후, 관련 기능들을 논리적으로 분류하고 계층화하는 작업이 필요하다.

• 카테고리화: 유사한 기능들을 그룹으로 묶는다.
• 계층 구조: 각 카테고리 내에서 세부 항목들을 어떻게 배치할 것인지를 결정한다.

가장 중요한 정보는 상위 카테고리에 배치하고, 덜 중요한 정보는 하위 카테고리로 배치한다.

3. 시각화 작성한 정보를 시각적으로 표현한다. 시각화된 정보 구조도는 팀원들이 쉽게 이해하고 효율적으로 작업을 진행할 수 있게 한다.

📝 오늘의 인사이트

정보 구조도(IA)가 사용자가 웹사이트나 앱을 이용하는 흐름을 설계하는 중요한 작업이라는 것은 알고있었지만, 작성할 떄 미래의 확장성을 고려하여 설계해야한다는 것은 처음 알았다.

체계적인 정보 배치가 사용자 경험에 얼마나 큰 영향을 미치는지 다시 한 번 깨닫게 되었고, 후에 새로운 프로젝트를 진행할 때 IA를 잘 설계해, 보다 효율적이고 직관적인 사용자 경험을 제공할 수 있도록 해야겠다는 생각을 했다.

🔍 요구사항 분석이란?

요구사항 분석은 "우리가 정확히 무엇을 만들 것인가?"를 명확히 정의하는 작업이다. ✔️ 고객이 원하는 것, ✔️ 문제를 해결하는 기능, ✔️ 사용자가 기대하는 경험을 문서화함으로써, 모든 팀원이 동일한 목표를 향해 개발을 진행할 수 있게 한다.

📄 PRD란?

PRD는 요구사항 분석의 결과물을 정리한 문서로, 프로젝트 전반에 걸친 지침서이자 커뮤니케이션 도구 역할을 한다.

🛠️ PRD 작성 항목 정리

✅ 1. 요구사항 항목

• 기능 이름 : 예) 회원가입
• 기능 설명 : 사용자가 이메일과 비밀번호로 계정을 생성할 수 있다
• 우선순위 : 필수 / 권장 / 나중에 추가
• 구현 기준 : 비밀번호는 최소 8자 이상, 특수문자 포함 등

✅ 2. 프로젝트 개요

• 프로젝트의 목적과 핵심 기능, 타겟 유저 정의 예) 20대 직장인 여성을 위한 빠른 패션 쇼핑 앱

✅ 3. 서비스 배경 및 가치

• 해결하고자 하는 문제와 사용자의 Pain Point
• 서비스가 가져올 변화와 가치 정의

✅ 4. 우선순위 및 릴리즈 계획

• 기능별 우선순위 정리 예시) 1순위 : 로그인/회원가입, 상품 검색, 결제 2순위 : 리뷰/별점 시스템 3순위 : 추천 알고리즘, 이벤트 배너

✅ 5. 기대 성과

• 서비스 출시 후 기대되는 변화, 수치적 목표 등 예시) 일일 방문자 1만 명, 전환율 3% 이상

⚠️ PRD 작성 시 주의할 점

1. 모호한 문장 X

• ❌ “빠르게 로딩되도록 한다”
• ✅ “홈 화면은 3초 이내에 로딩되어야 한다”

2. 기능 범위와 우선순위는 현실적으로 설정하기

• MVP 기준으로 꼭 필요한 기능부터 시작하고, 그 외 기능은 단계별로 릴리즈 계획 세우기

pm캠프 내에서 조원들과 일주일 간의 직무 스터디를 끝마치고 나서 회고를 한 적이 있었는데, 사람은 망각의 동물인지라 그 상황 당시에 느꼈던 감정이나 생각, 느낀점을 유지할 수가 없다. 그 때의 문제점을 확인하려면 회고록을 통해 '아, 그때 이러한 일이 있어서 다음에는 이렇게 시도해보자고 했구나'를 알 수 있기에 '회고는 꼭 해야하는 작업'이라고 내 머릿속에 남아있다.

🔍 회고란?

회고는 프로젝트나 일정한 작업 단위가 끝난 후, 어떤 점이 잘 되었는지, 어떤 부분이 부족했는지, 그리고 그 이유는 무엇이었는지를 함께 나누는 과정이다. 단순히 '무엇을 했는가'를 나열하는 것이 아니라, '왜 그렇게 되었는가', '어떻게 개선할 수 있는가'를 논의하는 것이 핵심이다.

💡 회고가 중요한 이유

1. 학습과 개선 회고는 실패를 교훈으로 바꾸고, 성공을 반복할 수 있는 전략으로 만드는 기회다. 예를 들어, 기능 개발 프로젝트가 지연되었을 때 단순히 일정을 탓하는 것이 아니라,

• 요구사항 변경이 많았던 이유,
• 테스트가 부족했던 배경을 파악하고
• 이를 해결할 수 있는 방법(요구사항 명확화, 자동화 테스트 도입 등)을 도출하는 것이 회고의 목적이다.

2. 협업의 질 향상 회고는 팀원 간의 솔직한 소통을 통해 신뢰를 쌓고, 각자의 노력을 인정받을 수 있는 시간이기도 하다. 서로 다른 시선에서 바라본 경험을 공유하면서, 개인적으로는 미처 인식하지 못했던 문제나 장점을 깨달을 수 있다.

3. 업무 효율성 향상 회고를 통해 불필요한 반복 업무, 커뮤니케이션 병목, 비효율적인 프로세스 등을 식별할 수 있고, 팀의 전반적인 생산성과 업무 집중도를 높일 수 있다.

✅ 회고는 어떻게 진행할까?

• 무엇이 잘 되었고, 무엇이 문제였는가? → 팀원 각자의 관점에서 좋았던 점과 아쉬웠던 점을 공유한다.

• 왜 그렇게 되었을까? → 문제의 원인을 분석하고, 반복되지 않도록 근본적인 이유를 탐색한다.

• 무엇을 개선할 수 있을까? → 실행 가능한 액션 아이템을 도출하고, 실제 적용할 계획을 세운다.

• 내용을 정리하고 공유하기 → 회고의 결과가 문서화되어 공유되면, 팀 전체가 같은 방향으로 개선에 동참할 수 있다.

✍️ 오늘의 인사이트

회고 경험을 통해 알게 된 것은, 다음엔 더 잘하기 위해 모두가 머리를 맞대는 시간’이라는 것이다. 그 이전에는 회고를 형식적인 절차라고 생각했는데, 오히려 팀이 성장할 수 있는 실질적인 지점이라는 걸 느낄 수 있었다.

✅ 킥오프란?

킥오프는 프로젝트가 공식적으로 시작되는 시점을 말하며, PM이 프로젝트 목표, 범위, 일정, 예산 등 핵심 정보를 팀과 이해관계자에게 명확하게 공유하는 자리다. 프로젝트에 참여하는 모두가 같은 목표와 방향을 공유하고 협업 기반을 다지는 중요한 의사소통의 순간이다.

📌 킥오프 미팅에서 다루는 핵심 요소

1. 프로젝트 목표 : 프로젝트가 끝났을 때 ‘무엇을 이루어야 하는가’에 대한 정의 ex. 신규 제품 출시 후 시장 점유율 5% 증가

2. 프로젝트 범위 : 프로젝트에서 포함/제외되는 작업을 명확히 함 ex. 웹사이트 개발은 포함되지만, 모바일 앱은 제외

3. 일정 : 주요 마일스톤과 일정 ex. 개발 및 테스트 기간 1/16 ~ 2/28

4. 팀 구성 : 팀원들의 역할과 책임 명확화 ex. PM, 디자이너, 웹/서버 개발자, QA 등

5. 커뮤니케이션 방법 : 사용 도구와 회의 주기 명시 ex. 슬랙/이메일/주간회의 등

6. 리스크 및 이슈 : 잠재적 리스크 공유 및 대응 방안 논의 ex. 인력 부족 시 일정 조정

7. 기대 사항 : 이해관계자들의 요구 사항과 기대 정리 ex. 웹사이트 리뉴얼 후 사용자 참여도 20% 증가

❕ 킥오프가 중요한 이유

킥오프 미팅은 단순한 '소개' 이상의 의미를 가진다. 명확한 목표 설정, 리스크 인지 및 대응 전략 마련, 팀 간 협업 구조 형성, 이해관계자와의 기대 정렬까지 프로젝트의 성공을 위한 기반을 마련해 준다.

내가 특히 인상 깊게 느낀 부분은 '리스크와 일정 관리의 사전 공유가 향후 혼란을 줄이는 데 얼마나 중요한 역할을 하는지'였다. 프로젝트 도중 갑작스러운 변수에 당황하지 않기 위해서라도 킥오프는 철저하게 준비되어야 한다는 걸 실감했다.

👥 킥오프 미팅 진행

1. 프로젝트 개요 및 목표 공유
2. 범위 및 일정 소개
3. 팀 구성 및 역할 설명
4. 리스크 및 문제 해결 방안 논의
5. 커뮤니케이션 계획 소개
6. Q&A 및 의견 수렴

💡 미팅 후 정리도 중요!

• 회의록 공유
• 액션 아이템 목록화 및 전달

오늘은 가격에 민감하고 빠르게 구매를 결정하는 저가 유저(5만 원 이하 상품 대상자)를 중심으로, '상세페이지 진입 → 장바구니 담기' 전환율을 어떻게 높일 수 있을까?를 주제로 데이터 분석을 진행했다.

📌 데이터 분석 포인트

1. 저가 유저 정의 → price_band = under_50k → 빠르게 판단, 빠르게 이탈하는 특징

2. 관찰 지표

• 장바구니 담기 전환율
• 상세페이지 체류 시간
• 유입 채널
• 리뷰 클릭 여부
• 할인 노출 여부

📊 분석 결과 요약

💡 인사이트 해석

저가 유저는 고민보다 직관과 가격 인식이 행동에 영향을 미친다. 리뷰나 너무 많은 정보는 오히려 구매 결정 방해 요소. 할인, 간결한 정보, 빠른 CTA(Call-to-Action)가 핵심.

📝 오늘의 회고

• '빠른 유저'에겐 빠른 설득이 답이다.
• 리뷰나 정보는 반드시 '전환에 도움이 되는 방식으로' 노출되어야 함.
• 데이터 분석을 통해 막연한 전략이 아닌, 근거 있는 설계가 가능하다는 점을 다시 체감했다.

1. 5 Whys : “왜?”를 반복하는 연습을 하자. 상상해도 괜찮다!

나를 포함한 조원들이 공통적으로 어려움을 겪었던 부분이 바로 5 Whys였다. 우이로서는 실제로 네이버 플러스 스토어 팀이 다크모드를 넣지 않은 이유를 알 수 없기에(내부 결정이기 때문에 외부인이 알 수 없다) 예상하고 상상하는 수밖에 없었다.

피드백을 주신 튜터님은, 중요한 건 정답이 아니라 논리적으로 정리된 ‘추정’이라는 것이라 하셨다.

실제로 PM은 개발자에게 “왜 이 기능을 개발해야 하는지”, 디자이너에게 “왜 이 디자인이 필요한지”를 논리적으로 설명하고 설득해야 하는 직무이기 때문에, 이런 사고 훈련이 곧 실무 능력과 연결된다고.

🍯** Tip from 튜터님** “왜?”라는 질문에 대한 예상 답을 많이 써보자. 예상, 상상도 괜찮다. 논리적으로 정리만 되어있으면 된다!

2. 우선순위 기준 : 내가 정한 기준을 보여야 한다

Impact Effort Matrix를 작성했었는데, Impact를 상·중·하로 나누는데에 그치지 않고, 이 Impact 강도를 나눌 때 어떠한 기준을 사용했는지에 대한 설명이 빠져있어서 아쉬웠다는 평을 들었다.

“채점은 했지만, 채점 기준표가 없는 느낌”이라고.

🍯** Tip from 튜터님** 1순위 문제는 2·3순위보다 더 자세하게, 더 디테일하게 설명되어야 한다. 근데 난 2·3순위가 더 자세히 쓰여있었다... 순위가 높을수록 설명도 그만큼 깊이 있게!

3. 가설 설계 : 사용자 여정을 그려야 한다

가설을 세울 때도 단순히 "다크모드를 개선하면 이탈률이 몇 % 감소할 것이다" 식으로 작성하는 것보다, 사용자 관점을 녹여서 작성하는 게 훨씬 설득력이 있다고 한다.

ex. “다크모드를 개선하면 사용자들의 야간 사용 환경이 편안해져서 체류시간이 몇 % 오를 것이다.”

사용자 여정이 가설에 빠져있어서 아쉽다는 이야기를 들었다.

피드백 후기

첫 개인과제였고, 생각보다 난이도가 높아서 정말 많은 시간을 쏟았었다. 과제를 하면서도 '내가 하고 있는 게 맞나?'라는 의문이 계속 들었는데, 피드백을 받고 나니 좀 방향성이 보이는 것 같다. 다음에는 '더 잘 할 수 있지 않을까' 싶다.

📌 로그란?

로그는 시스템 또는 소프트웨어에서 발생하는 이벤트, 동작, 오류 등의 정보를 기록한 데이터다. 쉽게 말해, 앱이나 서비스가 '무슨 일이 있었는지'를 기억하는 일기장 같은 존재.

로그를 사용하는 곳

1. 🔧 문제 해결 및 디버깅

시스템에 오류가 발생했을 때, 로그를 통해 문제의 원인과 위치를 정확히 파악할 수 있다. ex. 배달 앱에서 결제 오류 발생 시, 카드 결제 요청 단계에서 실패했는지 로그를 통해 확인 → 문제 수정 가능

2. 🧠 사용자 행동 분석

사용자의 행동을 추적하여 UX 개선에 활용된다. 어디서 이탈했는지, 어떤 버튼을 눌렀는지 등을 파악할 수 있다. ex. 장바구니에서 결제 페이지로 넘어가기 전 이탈한 유저가 많다면, 결제 과정 개선 필요

3. 📈 비즈니스 전략 수립

매출, 지역별 주문량, 프로모션 효과 등 데이터 기반 의사결정에 로그가 큰 역할을 한다. ex. 특정 지역의 주문량 급증 → 프로모션 효과 확인 → 향후 마케팅 전략 수립

🧾 PM에게 중요한 로그 종류

📌 클라이언트 로그 : 사용자의 기기(모바일, 웹 등)에서 발생한 이벤트를 기록한 로그. PM이 주로 다루게 되는 로그 유형이다.

🔧 로그 설계 방법 (PM 입장)

단순히 무엇을 기록하느냐가 아니라, 왜 기록하고, 어떻게 활용할지까지 고려해야 한다.

1. 로그 설계 목표 정의

• 로그를 통해 무엇을 알고 싶은가?
• 문제 해결인가, 사용자 분석인가, 비즈니스 지표 추적인가?

2. 로그 항목 정의 및 설계

• 어떤 데이터를, 어떤 상황에서, 어떤 방식으로 기록할 것인가?
• 개발팀과 협업하여 필요한 데이터 포인트를 논의해야 한다.

3. 로그 전송 및 테스트

• 실제 배포 전에 테스트 환경에서 로그가 잘 작동하는지 확인
• 데이터 누락 없이 전송되는지 체크

서비스 "정책"이라는 말에 아무래도 이전 실시간 강의 주제보다는 어렵게 다가왔던 것 같다.

🤔 서비스 정책이란?

서비스가 특정 상황에서 어떻게 작동할지, 사용자에게 무엇을 허용하고 제한할지 등에 대해 정의한 규칙과 기준. ex. 신고 기준, 노출 우선순위, 보상 정책, 환불 기준 등.

📌 서비스 정책이 중요한 이유!

1. 서비스 일관성 유지: 운영자와 사용자 모두에게 명확한 기준을 제공해 혼선을 줄인다.
2. 위기 대응 체계 마련: 이슈 발생 시 ‘정책에 따라 대응했다’는 근거가 되며, 불필요한 논쟁이나 피해를 방지할 수 있다.
3. 브랜드 신뢰 구축: 예측 가능한 정책은 사용자에게 신뢰를 준다.
4. 기획·디자인·개발 방향 설정의 기준점 역할을 한다.

📌 그렇다면 정책은 누가 만들까?

• 보통은 PM 주도 하에 운영팀, 법무팀, UX팀 등과 협의해 만들어짐.
• 특히 초기 서비스일수록 PM이 기준을 잡아야 하는 경우가 많다.

실제 사례를 통한 이해

커뮤니티 앱에서 "무엇을 신고 대상으로 삼을 것인가?" 라는 질문에 대해:

• 허위 정보, 광고성 콘텐츠, 혐오 표현 등 구체적인 기준을 설정
• 사용자 오신고 방지를 위한 UI/UX 설계 고려
• 운영자가 개입할 시점과 자동 필터링의 범위 설정

이렇게 정책은 단순한 글 몇 줄이 아니라 서비스 흐름과 구조, UI, 운영까지 전반에 영향을 미친다는 걸 체감했다.

❕ 느낀점

캠프를 통해서 PM에 대해서 많이 알게 되었다고 생각했는데, 서비스 정책까지 다뤄야하는 줄을 모르고 있었다.

PM = 기획만 하는 역할이 아니라, 서비스가 어떻게 운영되고 유지될지의 기준을 설계하는 사람이라는 점이 명확해졌다.

앞으로 기능 기획을 할 때, "이게 실제 운영되면 어떤 상황이 생길까? 어떤 예외가 발생할 수 있을까?"를 더 자주 생각해보아야겠다는 생각이 들었다.

아, 올 것이 왔다(?). PM의 꽃(?) 커뮤니케이션.

어쩌면, PM에게 가장 필요한 소프트 스킬일 수 있는 커뮤니케이션에 대한 내용이라 평소보다 유심히 듣게 되었다.

🤷‍♀️ 커뮤니케이션이 왜 중요할까?

튜터님께서는 회사에서 일 잘하는 것보다, 일을 잘한다고 보이게 하는 것이 더 중요할 때가 많다고 하셨다. ( 일 못해도 되는데 잘 보이게만 하면 된다는 뜻이 아니다! )

_"커뮤니케이션을 잘하면 80을 일하고도 100처럼 보이고 못하면 110을 일해도 100만큼밖에 안 보인다"_고... 그런데 어쩌면, 커뮤니케이션을 못 하면 110 -> 100이 아니라 한 7, 80으로 떨어져 보일 수도 있다는 생각이 들었다.

🤔 PM 커뮤니케이션은 뭐가 다를까?

특히 PM은 커뮤니케이션이 더 어렵다고 한다. 이유는

• 명령할 권한이 없는데 팀을 이끌어야 하고
• 개발자, 디자이너, 기획자 등 각자 다른 입장인 사람들이랑 조율해야 하고
• 최종 결과에 대한 책임은 또 PM이 져야 하고 😅

"왕도 아닌데 왕 노릇을 해야 하는 느낌"이라고 하셨다. ( 아이고... )

🤝 부트캠프 팀 프로젝트 vs 🏢 실제 회사

부트캠프에서는 다 비슷한 출발선에서 시작하지만, 회사에서는 다르다.

• 내가 제일 신입일 가능성이 높고,
• 회사는 이미 쌓인 프로젝트 히스토리가 많고,
• 승인 절차가 복잡하고,
• 실패하면 바로 매출이나 성과에 영향이 간다.

그래서 지금 부트캠프에서는 실패해도 괜찮으니까 최대한 주도적으로 움직여보는 게 좋다고 하셨다.

나도 속으로는 '좀 더 튜터님 찾아뵙고 무언가를 찾아서 하고 그래야하는데'라고는 생각하는데, 무엇을 여쭙고 무엇을 해야할지 모르겠어서 + 과제에 치여서(;;;) 아직 이 상황인 것 같다.

더 노력을 해야지...ㅠㅠ

😬 커뮤니케이션이 어려운 이유

커뮤니케이션이 어려운 이유는

• 서로 알고 있는 정보가 다르고 🧠
• 각자 기준이 다르기 때문이라고 했다. 🔄

나는 당연히 알 거라고 생각했는데, 상대는 모를 수 있고 나는 쉽게 말했는데, 상대는 어렵게 느낄 수 있다.

그래서 최대한 "같은 정보, 같은 기준"을 맞추려고 노력해야 한다. 이 부분이 진~짜 어려운 건데, 나도 디자인 프리랜서 일을 하면서 내가 전달하고자 하는 말을 깨끗하게 그대로 전달하는 것이 정말 어렵다는 것을 느꼈기 때문이다.

지금 부트 캠프에서도 그렇다.

오늘은 사전캠프 조원분들을 만났는데, 나는 '저희 오랫동안 못 봤으니까 한 번 얼굴 되어요!🥰'라는 의도로 자리를 만들었는데, 어떤 분은 '무슨 문제가 있어서 부르신 건가요?', '스터디 같은 거 같이 하려고 모으신 거 아닌가요?'라고 말씀하셔서 깜짝 놀랐다. ( 사람이 하는 생각이 이렇게 다르다... 오늘 또 배웠다. 다음에는 소통을 더 깔끔하게 하기 위해 "목적"을 밝혀야지 )

❕ 오늘 느낀 점

커뮤니케이션은 거의** 생존기술**(?)이다.

특히 PM은 여러 부서 사람들과 소통해야하는 직업이기도 하고, 또 NO 권한 Yes 리딩이니까 더 그렇고, 사람과 사람, 프로젝트를 이어주는 다리 역할인 만큼 상대방과 기술을 이해하려고 노력하는 것도 중요하고, 동시에 ‘상황을 주도하는 연습’을 해야한다는 생각이 들었다.

좀 더 의식적으로 커뮤니케이션을 잘하기 위한 노력을 해보아야겠다.

어제 개인과제를 하기 위해 Impact Effort Matrix를 작성하다가, _'어, 내가 생각한 문제 우선 순위와 Impact Effort Matrix를 작성해서 나온 문제 우선 순위가 다른데?'_라고 느껴서 굉장히 당황스러웠는데,

오늘 아침에 문득 '_내가 Impact Effort Matrix에서 Impact 점수를 줄 때에 명확한 기준이 없이 작성했기 때문에 이런 일이 벌어진 것이 아닐까?'_라는 생각이 들어 튜터님께 피드백을 받아보았다.

👩‍🏫 Impact Effort Matrix 피드백

Q. 제가 생각한 문제 우선 순위와, 매트릭스로 작성했을 때 나온 우선순위가 다릅니다. 평가 기준을 정하지 않고 impact 점수를 주어서 일까요?

A. 원래 이런 개선 작업을 하는 거에 목적이 명확해야 돼요. 그 목적이 없어서 헷갈리셨던 것 같아요.

예를 들어 "리텐션"을 목표로 삼는다면 그것이 우선순위를 판단하는 기준이 되겠죠. 그거를 놓치셨기 때문에 헷갈리셨던 것 같고 실제로 실무를 할 때도요, 우리가 지금 현재 단계에서 중요하게 봐야 되는 것들 그런 것들을 기준으로 삼고 이제 우선순위를 봐요.

지금 우리의 목표는 무엇이고, 그래서 임팩트를 측정하실 때 그 지표나 목표에 맞춰서 _'이거는 리텐션을 높일 수 있는 거니까 조금 더 임팩트를 높게 측정해 준다'_거나 그렇게 보시면 좋을 것 같아요!

🤔 조금 더 명확하게 이야기하자면, 문제 정의를 하기 전에 OKR 설정을 하지 않고 바로 데이터를 분류하고 문제 정의에 들어갔던 것이 패착이었던듯 하다.

📌 OKR란?

OKR = '목표(Objectives)'와 그 목표를 측정할 수 있는 '핵심 결과(Key Results)'로 구성된 성과 관리 도구

• Objective (목표) = 무엇을 이루고 싶은지를 명확하게 표현한 문장
• Key Results (핵심 결과) = 해당 목표가 달성되었는지 측정할 수 있는 정량적인 지표 (보통 25개 정도 작성, 7080% 정도 달성 목표로 설정)

📌 OKR vs KPI 차이점

😵 혼란 포인트 1 : “Effort”과 “Impact”의 기준이 모호하다

‘개발 난이도가 높다’는 게 과연 어느 정도를 말하는 걸까? “사용자 영향도”는 빈도 기준으로 봐야 하나, 아니면 유저 이탈 가능성 같은 리스크를 포함해야 하나? 같은 요청이라도 배경과 맥락에 따라 effort와 impact의 평가가 달라질 수 있어서 선뜻 사분면에 넣기가 어려웠다.

그리고 저녁 스크럼을 하면서 들은 이야기인데, "초반에 어떻게 설계했느냐"에 따라서 개발 공수가 상당히 다르다고 한다. 그래서 만약에 컬러 코드?가 하드 코딩되어 있다면 다크 모드 개발이 쉽지 않을 수 있다고... 그런데 이런 것들은 알 수 없는 부분이다보니, Effort가 높다, 낮다를 판단하기가 어렵다.

🤯 혼란 포인트 2 : 숫자(빈도)와 영향력이 항상 비례하지 않는다

예를 들어, 어플 내 오류를 지적하는 후기 숫자는 상대적으로 적었지만, 사용자 경험에 미치는 영향은 매우 크다. 반면 다크모드 요청 빈도는 가장 높지만,어플 내 오류만큼 치명적인 것은 아니다. 그러다 보니 단순히 빈도순으로 우선순위를 매길 수 없다는 점에서 고민이 깊어졌다.

😖 혼란 포인트 3: 영향력이 매우 높고 노력도 높은 기능 vs 영향력은 높고 노력이 중간 정도인 기능

예를 들어, A 기능은 사용자에게 엄청난 영향을 주지만, 개발 난이도가 높고 (ex. 결제 시스템 오류 수정)

B 기능은 사용자 영향도도 꽤 있고, 개발 난이도는 중간 정도라면 (ex. 다크모드)

이럴 땐 과연 어떤 걸 더 우선 순위로 두어야 할지... _'단순히 Effort-Impact Matrix를 작성한다고 해결되는 문제가 아니구나'_를 느꼈고... 이에 대해서 튜터님의 조언이 필요할 것 같다고 느꼈다.

오늘 한 내용들을 보기 좋게 정리하고, 내일 튜터님께 피드백을 받아야겠다.

✋ 네플즈(네이버 플러스 스토어 제작팀)

"AI 시대 사용자들은 스스로 몰랐던 자신의 니즈를 발견하고, 탐색하길 원하는 단계에 도달했다” “우리의 목표는 5000만 국민의 모두 다른 쇼핑 경험을 구현하는 것이다” https://fficial.naver.com/contentDetail/110

1. 커머스 영역 강화 (배송 & 제휴)

• 도착 보장 → 네이버배송(N배송)으로 리브랜딩

• 배송 서비스 세분화

  • 오늘배송 / 내일배송 / 일요배송 / 희망일배송
  • ‘지금배송(주문 즉시~1시간 이내 상품 배송 시작)’도 올해 출시 예정

• 컬리와의 전략적 제휴
  • 컬리 : 프리미엄 신선식품 강점 (네이버는 이 부분이 약점)
  • 신선 식품은 반복 구매율이 높아 충성도 높이는데 효과적인 카테고리
  • 컬리의 30~40대 충성층 → 네이버 유입
  • 컬리는 차별화된 풀 콜드체인 시스템, 주7일 새벽배송 등의 물류경쟁력 갖춤
  • 반대로, 컬리는** 자사몰 외 신규 유통채널 확보할 수 있음** (자사몰 중심 유통구조로, 고객과의 접점이 적다는 것이 약점으로 지목되어 왔었음) ➡️ ** 반(anti)쿠팡 연대**로 해석되기도 함.

🤔 왜 네이버와 컬리는 손을 잡았을까?

• 쿠팡: 로켓배송 + 와우 멤버십으로 속도 및 혜택 강점 **+ 1등 앱 (MAU 3292만명. 압도적 1위)** (네이버 플러스 스토어는 268만명)

• 네이버 : 쿠팡이 가진 이용자 수에 한참 못 미침.
• 컬리 : 신선식품 및 프리미엄 포지션이 쿠팡에게 따라잡혀 애매한 상황 + 흑자 전환을 못하고 있다가 최근 흑자 전환 했음.

❕ 두 기업 모두 신선식품과 이커머스 *부문에서 쿠팡에 이은 *2위 사업자임 + 서로 보완 요소를 갖추고 있음

2. 검색광고 → 커머스 & AI 중심 전환

• 네이버, AI 기반 커머스에 집중
• 멤버십 적립형 모델 = 네이버만의 경쟁력 (혜택 체감 큼)
• AI 서울 정상회의에서 ‘소버린 AI’ 발표
  • AI를 신성장 동력으로 소개

[검색 엔진 시장의 변화]

• 검색엔진이 구글에 꾸준히 밀려왔음. 10년 전 점유율 80% → 2024 상반기 점유율 56%
• 챗gpt등 생성형 AI 서비스도 검색 엔진 시장을 위협하고 있음 (기존 검색광고 모델 한계 도달)

[AI + 커머스 : 아마존과 네이버]

출처 : https://www.joongang.co.kr/article/25329841

• 아마존은 “루퍼스” 외에도 지난 3일 “바이 포 미”를 베타 테스트 중 (쇼핑 AI 에이전트)
• “웹 기반의 1세대 → 앱 기반의 2세대 → AI가 주도하는 3세대 커머스 시대가 열리고 있다”는 분석. “A2A (AI to AI) 거래 시대가 머지않았다”는 전망
  • 네이버 대표 “축적된 데이터를 바탕으로 혁신적인 AI 커머스 에이전트 개발하겠다” 발표
  • 사용자 블로그/카페 후기, 단골 정보 등 → 개인화된 추천하겠다
  • ‘고관여 제품에서 쿠팡보다 우위 가능성 있다’는 전망

기존 수익 모델의 한계 / 광고→커머스 중심으로 방향 전환 / 차별화 및 미래 비전을 위해 AI를 택한 것으로 보인다.

기존에 존재하는 공개된 자료를 바탕으로 하는 간접 조사 방식.

실무에서는 단순한 '자료 수집'이 아니라, 사업 방향성, 사용자 맥락, 제품 철학을 이해하기 위한 탐색 과정이다.

🏃‍♀️ 데스크 리서치 프로세스

✅ 1. 조사 목표 설정

• 프로젝트/서비스 맥락에서 중요한 포인트 설정
  • 예) 회사의 철학이 제품에 어떻게 반영되었는가?

✅ 2. 출처 선정

• 공식 홈페이지, 보도자료, 유튜브 인터뷰, 뉴스, 블로그, 앱 리뷰 등

✅ 3. 구조화 및 흐름 정리

• 단편적 나열 X → 인과 관계 기반의 스토리로 정리
• 추천 흐름:

1. 대표자 철학
   → 이 사람이 어떤 생각으로 회사를 운영하는지
2. 조직 문화와 인재상
   → 구성원에게 어떤 기준을 요구하는지
3. 서비스 및 UX 전략
   → 그 철학이 어떻게 실제 제품에 녹아드는지
4. 성과 및 방향성
   → 그 전략이 시장에서 어떤 반응을 이끌어냈는지
5. 경쟁사 비교
   → 유사 업계의 다른 기업과 어떤 차별점이 있는지

> 대표자의 철학 → 조직문화 → 브랜드/UX 전략 → 사용자 경험/성과
>

🖋️ 사례 : 배달의 민족 vs 쿠팡

튜터님께서 세션에서 다루어주신 예시 중 인상 깊었던 건 [배달의민족]과 [쿠팡]의 철학과 UX 전략의 차이였다.

🤔 느낀 점

둘 다 ‘배달’이라는 카테고리 안에 있고, 메이저 기업이라는 공통점이 있지만, 각자의 철학과 문화가 제품 경험 전반에 완전히 다르게 녹아 있고, 그로 인해 보이는 UI양상이 다르다는 점이 신기했다.

그동안 데스크 리서치를 해오면서 표면적인 정보를 찾아왔을 뿐, 대표자의 철학이라던가 UX전략이라던가 그런 부분은 볼 생각도 하지 못했었다는 것을 튜터님의 세션을 들으면서 깨달을 수 있었다.

앞으로 역기획 같은 프로젝트를 하거나 데스크 리서치 할 때, 배운 부분을 적용해보아야겠다.