예삐 PM

내배캠 PM 최종 프로젝트 (10) 구구레터 2차 QA & UT 시뮬레이션

yeppi' s — Mon, 13 Jul 2026 21:01:42 +0900

오늘 오전 스크럼을 마치고 개발 튜터님께 전달드릴

수정 사항들을 정리하여 전달드렸다.

전체적으로 이미지 깨지는 부분들과 사용에 있어서

큰 영향을 미치는 것들 위주로 수정사항을 전달드렸고

빠르게 반영해주셔서 오후에 구구레터 2차 QA를 진행할 수 있었다.

01. 2차 QA

로고 이미지 깨지는 부분들은 변경이 되어 훨씬 깔끔해졌고

QA도 마찬가지로 티켓을 분배하여 담당했다.

테스트를 하려는데 홈 불러오기, 쪽지 전송하기가 모두 실패하였다.

최대한 캐시 삭제, 브라우저 등등 다양한 시도를 해보았으나 실패하였고

다른 분들은 잘 되신다고 하셔서 계정 문제인가 싶어 탈퇴하고 가입하니

다시 원상복구되어 일단 QA 마저 진행....

이후에 다른 팀원분도 동일한 현상이 발생했는데 왔다갔다 하는 것인지ㅜㅜ

QA에서 맡은 부분
1. OG 이미지 적용 여부
OG 공통 이미지를 전달 드렸는데 카카오톡 공유를 해보니 뜨지 않았다.
확인해보니 슬랙에서는 짤림 없이 보이는데 카카오톡 공유에서는 이미지가 짤려서 보인다..
특히, 상황( 내홈 링크 공유/받은 쪽지 링크)에 따라 적용할 문구도 반영되지않아서 실패 처리

2. 이모지 반응 줄 잘림 반응 여부
받은 쪽지함에서 내용이 길어지면 이모지 반응하기 버튼의 문구도
줄 잘림되어 버튼 크기가 변경되고 이상하게 보였는데 해결되었다.

3. 작성한 내용이 길어질 시 버튼이 짤리지않도록 고정 여부
내가 쪽지를 작성할 때 내용이 길어지면 화면도 변경되어
버튼이 점점 아래로 내려가 짤리는 것처럼 보였는데 이부분도 고정되어 변경되었다.

02. UT 시뮬레이션

처음으로 UT 진행자가 되었다.

사실 이런저런 내용들을 잘 체크하면서 진행할 수 있을지 걱정이지만

이것 또한 모두 경험이 되는 나의 자산...이라고 생각하고...

동시에 관찰자도 맡았는데 생각보다 흐름을 따라가면서

내용들을 상세히 적는게 쉽지 않았다.

내용과 함께 소요된 시간도 체크해서 더더욱 정신 없었는데

최대한 정리를 해보고 녹화본을 보면서 정리하는 것으로 말씀 나누었다.

UT 시뮬레이션만 오늘 하루종일 했는데

시뮬레이션 진행하면서 필요 없는 질문, 애매한 질문은 없었는지 확인하고

전체적인 진행 흐름이 어떤지, 관찰자 입장에서 기재하기 어려운 부분들을 공유했다.

내일은 질문지에서 필수와 선택 체크해주신 부분을 확인하며

내가 진행할 대본을 개인적으로 정리 및 수정 해 볼 예정이다.

아자자 할 수 있서,,,

내배캠 PM 최종 프로젝트 (9) 구글 계정 복구하기 & 면접 특강 2부

yeppi' s — Wed, 8 Jul 2026 19:18:51 +0900

오늘 목요일인 줄 알았는데 아직 수요일!

하루 더 벌었다고 생각하고 오늘 뭐 할지 오전 스크럼에 정리했다.

구글 계정 복구하고, 특강 듣고, 마케팅 활용안 고민하고

다른 분들 작업 사항 리뷰 있으면 같이 듣고 정리하면서 마무리 할 예정

01. 구글 계정 복구하기

구구레터 구글 계정을 만들고 나서 다음 날 정지되었다 ^^...

아무래도 다른 IP에서 운영자 6명이 로그인 하다보니 그런 것 같은데

구글은 원래도 계정을 잘 정지 시키니 이전에도 같은 경험이 있어서

맡아서 이의 신청과 문의를 넣어두었다.

그 결과 하루만에 계정 복구 승인은 완료

원래 최소 3일~7일 걸린다는 과정이 짧아져서 기뻤던 것도 잠시

인증 단계에서 제한이 걸려서 막혔다.

새로운 계정을 만들 수도 있지만 최대한 계정을 살리고 싶어서

오전에 구글 코리아 대리인에게 추가 문의 사항을 접수했다.

아직 답변은 못 받았지만 최대한 전화 연결이라도 해결해 볼 예정...

(빠른 시일 내에 로그인 하지않으면 삭제된다면서요ㅜㅜ)

최대한 담당자랑 소통해 보고 안되면 빠르게 계정 만들 예정...

제발 구구레터 이메일 쓸 수 있게 해주세요...

02. 면접 특강 2부

오늘 특강으로 배울 것은 하나의 제품과 기능을

세상에 내놓기 까지 거치는 과정과 각 단계에서 PM이 반드시 해야 하는 일

*실무에서는 조직 규모나 개발 방식에 따라 순서가 겹치거나 반복될 수 있다.

*내 일인가 아닌가 싶을 때 고민이 들 땐 그냥 일단 해라

단계	목적	주요 업무	핵심 포인트
1. 문제 정의 & 기획 준비	무엇을, 왜 만들어야 하는지 정의	• 시장/경쟁사 조사 • 사용자 리서치(인터뷰, 설문, 행동 데이터) • 내부 이해관계자 요청 수집 •문제와 목표 정의 • 목표 지표(KPI) 문서화 (예: 전환율, 리텐션) • 우선순위 판단(임팩트 대비 노력) • 추진 근거 확보	• PM의 핵심 업무는 문제와 목표를 명확히 정의하는 것 • "왜 지금 이 기능을 해야 하는가?"에 대한 근거를 확보해야 함
2. 요구사항 정의 & 기획	문제 해결 방안을 구체화	• 기능 범위 정의 • 요구사항 목록 작성 • MVP 범위 정의 • 기능별 예외 처리 및 정책 정의 • 제약 조건 정리 • 개발/디자인 리드와 기술적 실현 가능성 검토• 대략적인 일정 검토	• 구현에 필요한 요구사항이 빠짐없이 정의되어야 함
3. 화면 설계 & 기획서 작성	기획 내용을 시각화	• 와이어프레임 작성 • 플로우차트 작성 • 기획서(스토리보드) 작성 • 화면 정의 • 상태값(로딩, 에러, 빈 화면 등) 명세	• 좋은 기획서는 개발자와 디자이너가 문서만 보고도 같은 그림을 그릴 수 있어야 함
4. 디자인 협업	기획 의도를 UI에 반영	• 디자인 검토 • 기획 의도 전달 및 확인 • UX 관점에서 우선순위 판단 • 디자이너와 개발자 간 실현 가능성 논의 중재	• 기획 의도가 디자인에 정확하게 반영되는지 지속적으로 확인해야 함
5. 개발자 협업	기능 구현	• 개발 진행 협업 • 스프린트 단위 일정 관리(애자일) • 변경사항 검토 및 공유	• 변경사항은 신중하게 결정하고 빠르게 공유해야 함
6. QA	기능 품질 검증	• 기획서 기준 기능 검증 • 버그 및 이슈 확인 • 이슈 관리 • 심각도 판단(배포 전 수정 / 이후 개선) • (필요 시) 디자인 QA 수행	• QA 조직이 없으면 PM이 직접 챙겨야 함 • 디자인 QA는 픽셀 단위까지 확인
7. 배포	실제 사용자에게 기능 오픈	• 배포 계획 수립 • 대내외 커뮤니케이션 • CS·마케팅·영업 등 유관부서 공지 • 롤백 기준 및 대응 프로세스 준비	• 배포 후 장애 상황까지 미리 대비해야 함
8. 배포 후 운영 및 분석	성과 측정 및 개선점 도출	• 사용자 데이터 분석 • 문제점 및 개선점 발굴 • 성과 측정 • 개선 방향 수립	• 데이터 기반으로 다음 개선 과제를 도출
9. 플로우 반복	지속적인 서비스 개선	• 개선점 반영 • 새로운 문제 정의 • 1단계부터 프로세스 반복	• PM 업무는 배포로 끝나는 것이 아니라 지속적인 개선 사이클을 반복하는 것이 핵심

튜터님께서는 실제 현업에서 면접을 볼 때
나올 수 있는 아래 내용에 대해 공유해 주셨다.
생각하지 못했던 부분이라서 참고해서 준비하면 좋을 듯

면접에서 나올 수 있는 질문
1. 1차 배포하고나서 다음 목표는 무엇이였는지?
2. 그 목표를 위해서 어떤 개선점을 가지고 2차 배포를 진행했는지?
3. 그로인해서 개선점, 문제점이 해결되었는지?

03. 개인 회고

오랜만에 1시간동안 특강을 들으니 즐거웠다

최종까지 다가갈 수록 점점 다른 분들을 알아가고 대화할 시간도 부족한ㅠㅠ

특강에서 튜터님께서 실제 현업 이야기도 많이 풀어주시고

입사해서 놓치지 말아야 할 부분들이 무엇인지 알 수 있었다.

가장 중요한 건 "내 일인가? 싶을 땐 그냥 해라" 였는데

마케팅도 이렇게 보면 PM이랑 정말 비슷한 점이 많은 것 같다..

규모가 작을 수록 내 일, 남의 일 없이 해야 하는 경우가 많기 때문에

어떻게 보면 이런 점들은 나에게 잘 맞다고(?) 생각했다.

사실 캠프를 하면 할 수록 실무에 대한 궁금증이 많아졌는데

단순히 물음표가 아니라 얼른 실무를 직접 경험해 보고싶다는 것에 가깝다

직접 깨지고 하면서 성장하겠지!

[아티클 아카이브] LINE PM이 말하는 '딸깍'의 시대에도 PM이 필요한 이유

yeppi' s — Tue, 7 Jul 2026 16:49:05 +0900

제목: LINE PM이 말하는 '딸깍'의 시대에도 PM이 필요한 이유

https://www.jobkorea.co.kr/goodjob/Tip/View?News_No=22533&schCtgr=0&Page=1&Tip_Top=1

LINE PM이 말하는 ‘딸깍’의 시대에도 PM이 필요한 이유

대기업 PM 취업을 준비하는 분들을 위한 라인 PM 인터뷰

www.jobkorea.co.kr

아티클 핵심 내용

1. LINE Planet에 대해

LINE Planet은 글로벌 메신저 LINE의 음성 & 영상 통화 기술을

SDK와 API로 패키징 해서 개발자들이 자신의 서비스에 통화 기능을 붙일 수 있게 해주는

CPaaS(Communications Platform as a Service) 플랫폼이다.

API란?
다른 서비스의 기능을 가져다 사용할 수 있게 해주는 연결 통로
예를 들어, 우리의 서비스에서 카카오 로그인을 사용하고 싶다고 가정하면
직접 로그인 시스템을 만드는 대신 서비스 → 카카오 로그인 API 호출 → 사용자 로그인 성공
위 예시와 같이 카카오의 기능을 빌려 쓰는 것이다.

SDK란?
API를 더 쉽게 사용할 수 있도록 만든 개발 도구 모음
API만 주면 개발자가 직접 많은 코드를 작성해야한다.
이를 SDK를 사용하면 필요한 코드, 예제, 라이브러리, 문서 등 함께 제공되어
훨씬 쉽게 개발할 수 있다.

위에 언급한 API가 자동차 엔진이라면 SDK는
핸들, 브레이크, 계기판, 설명서 등 모두 포함된 자동차 키트 같은 것이다.

CPaaS란?
전화, 문자, 이메일, 알림톡 같은 통신 기능을 API 형태로 제공하는 서비스
예를 들어, 우리 서비스에서 문자보내기, 전화연결, 본인 인증, 알림톡 등
기능이 필요하다면 직접 통신 시스템을 만들지 않고 CPaaS를 활용한다.

2. 기업의 대상의 플랫폼과 일반 소비자 대상의 차이점

LINE Planet을 사용하는 사람은 개발자이지만 돈을 지불하는 쪽이

의사결정권을 가지고 있어 영업 & 사업 측면에서는 기술적인 이야기보다

비용 이야기가 먼저 나오는 경우가 많아 내부 의사결정자를 설득하는 것이 핵심이다.

또한, 고객 요구사항을 스펙화 할 때 ROI(투자 수익률)을 따져야 한다.

개발 공수가 많이 들어가는 과제라면 "왜 못하는지"에 대한 근거도 필요하다.

3. 의사결정자의 '진짜 니즈'를 찾아내는 법

진짜 니즈를 찾아내는 방법은 결국 대화를 깊게하는 것이다.

또한 이분의 요청이 윗선에서 받은 미션인지도 확인 필요하다.

의사결정자가 원하는 것이 무엇인지 맥락을 파악해야 진짜 솔루션으로 이어진다.

흥미로웠던 점

1. PM 업무에서 AI 활용 범위

PRD 작성부터 Wiki 업데이트, 다이어그램 설계까지

대부분의 업무를 Claude Code 안에서 처리하고 있다.

단순히 텍스트를 생성하는 용도가 아니라 claude/skills/ 폴더에

반복 업무를 스킬로 정의해 두고 재사용하는 방식으로 운영한다.

보조적으로는 경쟁사 IR 분석이나 새로운 도메인 지식을 빠르게 흡수할 때

NotebookLM을 쓰는데 여러 문서를 한꺼번에 넣고 질문하는 방식이 리서치 속도를 향상 시킨다.

2. AI의 활용법

AI는 제품의 맥락을 모르면 엉뚱한 PRD를 만들어낸다.

따라서 AI가 PRD를 쓰기 시작할 때부터 우리 제품의 히스토리와

기획 맥락을 다 파악한 상태에서 출발할 수 있도록

기존에 작성했던 요구사항 문서들을 위키에 모아두고

벡터 DB로 만들어 Claude Code가 참조하도록 했다.

3. AI에게 질문 요청 하기

Claude에게 "먼저 10개 이상의 질문을 통해 내용을 완성한 뒤

확인하고 보강해서 완성하라"는 지침을 심어두고 AI가 먼저 질문을 던지면서

PM이 미처 생각하지 못한 부분을 채워주는 구조를 생성한다.

즉 PRD를 문서로 정리하는 건 AI가 하지만 완성된 PRD를 검토하고

다듬는 것은 PM의 몫이 되는 셈이다.

4. AI 도구를 통해 어려웠던 점

트레이드 오프가 있긴하다.

(한 가지를 얻으면 다른 한 가지를 포기하거나 희생하는 관계)

AI로 형식적인 문서는 빠르게 만들 수 있지만 빠르게 나온만큼

맞는지 컴토하고 판단하는 몫은 PM에게 있기 때문이다.

AI로 인해 업무의 형태가 바뀐 것이지 총량이 줄어든 것이라고 생각하지 않는다.
AI 덕분에 할 수 있는 것이 많아지니 기대치도 올라가고 업무 경계도 같이 넓어졌다.

새롭게 배운 점

1. 의사결정권자의 진짜 니즈를 파악하자

B2C 플랫폼에서는 작은 기능 하나도 수백만 사용자에게 즉시 검증된다.

하지만 B2B 플랫폼은 특정 고객사 요구사항에 개발 공수를 쏟아내어

기회 비용 판단이 훨씬 명시적으로 요구된다.

2. AI 시대에도 대체될 수 없는 PM의 역량

'융합'이다.

개벌적인 작업은 AI가 잘하고 있지만

서로 다른 것들을 섞고 그 조합을 상상하는 것은 PM이 잘한다.

AI가 준 초안을 구체화하고 내 것으로 만들려면

나의 지식과 경험을 융합할 수 있어야 한다.

융합 역량을 키우기 위해 소설을 많이 읽으면 좋다.

소설 속에는 융합을 통해 만들어진 기발한 표현들이 넘쳐난다.

또한 관찰도 중요한데 지하철 옆 사람이 서비스를 어떻게 쓰는지

다른 사람들이 어떻게 소비를 하는지 관찰하는 것이야 말로

PM에게 가장 중요한 기초 훈련이다.

나의 생각

처음엔 "AI를 사용할 줄 아시나요?" or "AI를 얼마나 사용할 줄 아시나요?"가 많았는데

이제는 "AI를 어떻게 업무, 일상에 사용(활용)하고 있나요?"로 질문이 바뀌었다.

위 아티클을 읽으면서 가장 공감이 갔던 부분은 내 지식과 AI가 융합되어야 한다는 것이다.

AI를 활용하면 SQL 쿼리는 얼마든지 짤 수 있다.

하지만 내가 원하는 내용으로, 정확한 쿼리를 짰는지는 내가 판단한다.

늘 내가 어느정도의 혹은 그 이상의 기본 지식을 가지고 있어야

AI를 잘 활용하는 사람이 될 수 있다..

의사결정권자의 진짜 니즈를 파악하는 부분도 너무 공감이 갔다.

본 아티클에서는 B2B 플랫폼이지만 이 내용은 실무에서도 적용된다고 생각한다.

실제로 사업, 기획의 방향성은 의사결정권자의 판단도 들어가기 때문에...

진짜 니즈가 무엇인지 파악하고 그것을 명확히 설득할 수 있는 연습을 해야겠다!

내배캠 PM 최종 프로젝트 (8) 마케팅 계정 만들기 & 화면정의서 수정 & PM 튜터님 피드백

yeppi' s — Mon, 6 Jul 2026 21:56:44 +0900

드디어 기능명세서와 PRD 제출 완료

제출 할 땐 금요일이였는데 오후 조퇴를 해서 함께 하지 못 했지만

전날 새벽까지 팀원들이랑 내용 정리하면서 너무 뿌듯했다...

기간은 촉박했지만 실무에서도 기간은 넉넉하지 않을테니 연습!

01. 마케팅

오늘 오전에는 작업을 나누어 진행했는데

나는 총무이기도 해서 마케팅에 활용 할 계정을 만들었다.

일단 구글 계정은 문의하기 계정으로 연동해야 하기도 하고

나중에 타 채널들과 연동할 것을 생각해서 만들었다.

각 채널 별로 계정 만들고 티켓에 내용까지 기재
계정을 만들면서 광고 부분까지 고려하였는데 메타 광고는

초기 학습 비용이 많이 들기도 하고 뚜렷한 경쟁 서비스가 없다는 점

그리고 웹 기반이라는 점에서 단가도 비싸고 어려울 것 같아 제외하였고

우리의 타겟은 2030이기때문에 인스타, 스레드 채널을 주로 활용할 예정이다.

구글
인스타
스레드

빠르게 계정을 만들고 인스타 콘텐츠 기획까지 생각해봤다.

세팅하고 나니 구구레터 너무 귀엽다...

인스타 콘텐츠를 어떻게 기획할지 한번 그려보고

추후 어떤 광고를 할 수 있을지 정리하다가 화면 정의서 작업으로 이동!

02. 화면정의서

기존의 화면정의서는 완료되었으나 디자인 튜터님께서 피드백을 주셔서

피드백 내용을 기반으로 팀원분께서 화면을 다시 그려주셨다.

새롭게 그린 화면대로 화면 정의서 업데이트 하고 기능명세서와

내용이 다른 부분은 없는지, 제외된 부분은 없는 지 등등....

확인하면서 최종 화면정의서까지 수정 완료했다.

03. PM 튜터님 피드백

튜터님께서 주신 말씀 중 "너무 잘하고 있어서 중간에 피드백을 주지않았다."고 하셨다.

이와 더불어 다른 말이 없다면 잘하고 있구나 생각하면 된다고 하셨다ㅋㅋㅋ

또한 아래의 내용도 함께 말씀해 주셨다.

1. 수정할 내용이 거의 없고 KPI도 선정이 잘된 것 같다.

2. 리스크 부분을 생각해보면 좋다, 우리 서비스에서 홈 화면이
유저들이 쪽지를 남겨줄 명분과 갭을 진짜 만들어주는 검증이 필요할 것 같다(추후에)

3. 만약 실패했다면? 기획한 컨셉의 실패보다는 홈 화면의 파워(영향력)이 적었을 것 같다.
이 부분을 UT에서 검증해보면 좋을 듯 하다.

4. 마이너한 부분이지만 외향적,내향적 사람들이 느끼는 요소가 다른데
지금 서비스가 예상치 못한 유저에게 긍정적인 것보다 부정적인 요소로 느껴질 수 있다.
이 부분은 어떤 커뮤니티든 가지고 있는 문제고 컨트롤 할 수 있는 부분은 아니지만
내용은 알고 있고 최대한 허들을 어떻게 낮출 수 있을지 고민해보면 좋다.

추가로 팀장님께서 튜터님께 질문을 해주셨는데 너무 좋은 내용...

다음 사이드 프로젝트에서도 실무에서도 기억하면 좋을 것 같다.

Usability Test VS User Test 차이점

Usability는 사용성 테스트로 (물론 유저 테스트도 사용성이지만 목적이 다르다)

이 서비스를 사용하는데 무엇을 원하는지 볼 수 있다.

예를 들어, 회원가입에서 카카오 로그인을 넣었는데 로그인이 안되거나

혹은 쪽지를 보내고 나서 버튼을 못 찾아서 우왕좌왕한다거나

사용자가 서비스를 원활히 사용할 수 있는지 확인하는 테스트이다.

반면 User Test는 앱의 사용성 보다는 사용의향과

사용자의 페인포인트를 해결해 줄 수 있는지 이런 포인트에 집중한다.

두 가지 모두 목적이 다르기때문에 둘 다 진행해야한다.

하지만 캠프에서는 시간적 여유가 없다보니 동시에 진행해도 괜찮다.

예를 들어 사용자 5명과 진행한다고 가정하면 사용성 테스트를 진행하고

이어서 추가 질문을 통해 UT를 진행할 수 있다.

(EX. "기존의 ㅇㅇ서비스에 비해 어떤 점이 좋았는지" 등)

UT에서 가장 많이 하는 실수는 사용자들의 답변을

의도하는 질문이 있는 경우인데 이러한 부분들을 고려하여 작성하고

UT 직전에 튜터님께 한번 피드백 받기로 하였다.

내배캠 PM 최종 프로젝트 (7) 기능명세서 티켓 분배 & 기능명세서 작성

yeppi' s — Thu, 2 Jul 2026 21:13:12 +0900

오늘은 팀원분들과 함께 MVP scope와 유저 플로우를 그렸다.

MVP에서는 P0/P1로 나누었고 P1까지 MVP 개발 목표 범위이다.

P1에서 논의 필요한 부분이 있어 전체 회의를 통해 결정하고 회의록까지 작성하고

이후엔 기능명세서 티켓 분배하는 작업을 진행하였다.

01. 기능명세서 티켓 분배

EPIC	주요 기능
회원	• 회원가입 (P0) • 로그인 (P0) • 로그아웃 (P0) • 탈퇴 (P0)
홈	• 나의 홈 조회 (P0) • 내 쪽지함 링크 복사 (P0) • 상대 홈 조회 (P0)
상태 메시지	• 상태 메시지 조회 (P1) • 상태 메시지 생성 (P1) • 상태 메시지 수정 (P1)
프로필	• 내 닉네임 수정(P0)
쪽지	• 쪽지 작성 (비회원/회원) (P0) • 쪽지 작성 가이드 (P0) • 쪽지 미리보기 (P0) • 쪽지 발송 (P0) • 받은 쪽지 목록 조회 (P0) • 받은 쪽지 상세 조회 (P0) • 보낸 쪽지 목록, 상세 조회 (P0) • 신고하기 (P0) • 이모지 반응 (P1)
공유	• 받은 쪽지 외부 공유 (P1)
운영	• 문의하기 (P0) & 아이디어 건의 (P0)

크게 EPIC 단위로 분리하고 그 안에 티켓들을 나눴다.

사실 기능명세서를 화면 단위로 할지? 기능 단위로 할지? 고민하다가

기능 명세서는 서비스에서 제공하는 기능이 어떻게 동작해야 하는지 구체적으로 정의한 문서로

기능 단위로 보는 것이 맞을 것 같아 아래와 같이 기준을 정리하고 분배하였다.

화면 단위는 "어느 페이지를 만들 것인가?" 기준
기능 단위는 "사용자가 무엇을 할 수 있는가?" 기준

02. 기능명세서 작성

EPIC 단위로 기능명세서 분담해서 담당했다.

내가 맡은 곳은 <회원> 쪽 회원가입, 로그인, 로그아웃, 탈퇴가 해당된다.

비교적 <회원>은 빨리 끝날 것 같아서 얼른 마무리하고 <쪽지>로 넘어갔다.

<쪽지> 중에서는 이모지 반응과 신고하기 내용이 있다.

채영님께서 기능명세서 양식을 미리 작성해주셔서 원활하게 작성이 가능했다!

(덕분에 많이 배웠습니다...)

*기능명세서 작성한 내용은 캠프 종료 후에 업데이트 하는 것으로!

기능 명세서 목차
1. 기능 개요 - 한 문장 정의
2. 기능 정책
3. 사용자 시나리오
4. 화면 설계 (와이어프레임 첨부)
5. 이벤트 로깅 정의 (필요 시)
6. 수집 데이터 제약 조건 (필요 시)
7. 예외 처리 및 에러케이스
8. KPI/지표 연결
9. 검증할 가정 (필요 시)

팀원분들께서 기능명세서에 작성 필요한 부분 중에

PM이 알아두면 좋을 데이터 조건까지 설명해주셨는데

이번 기회에 다시 한번 정리할 수 있었다.

(PM은 정말 다재다능 해야 하는 구나...다시 한번 깨달음)

타입	예시	조건(아무 값이나 가능한지)
string	"홍길동", "자세히 보기", "여성"	✅ 가능
number	1, 27, 15000	숫자만 가능
boolean	true, false	두 값만 가능
enum	WOMEN, MEN, KIDS	❌ 미리 정한 값만 가능

snake_case = 뱀 꼬리

Camel Case = 낙타 혹

03. 개인 회고

기능명세서 작성하면서 데이터 조건을 어떻게 해야하는지

그리고 어떤 식으로 기능 단위를 쪼개고 작성해야하는지 학습할 수 있었고

PM은 정말 다재다능 해야하는 사람이구나를 다시 한번 느꼈다..

그리고 기능명세서 정리하고 화면정의서로 넘어갔는데

작성, 기능명세서랑 맞추기, 검토 등등을 거치다보니 생각보다 시간이 촉박했다.

하지만 주어진 시간 안에 문제를 해결하는 것 또한 PM의 역량...

그래도 얼추 마무리가 되어가고있으니 힘을 내보자 화이팅!

내배캠 PM 최종 프로젝트 (6) 설문조사 작성/마무리 & QA 템플릿 제작 & 업무 분담

yeppi' s — Tue, 30 Jun 2026 21:22:01 +0900

오늘은 설문조사 마무리하고 후딱 배포하고 다른 작업으로 넘어가야 한다.

일단 설문조사 마무리는 내가 맡아서 진행하는 것으로 하고

중간중간 내용들을 공유하면서 진행했다.

01. 설문조사 작성 마무리

어제 풀리지 않았던 섹션 이동은 마지막 질문이 아니거나

중복 체크(체크박스)의 경우 지정할 수 없어서의 이유였다.

미리보기로 보았을 때 크게 거슬리지 않는 선에서

섹션을 최대한 나누고 수정하여 이동 문제는 해결!

설문조사가 길고 구체적이다 보니 확인사항을 먼저 작성하고

미리보기 화면에서 하나씩 테스트 해 보았다.

✅ 설문조사 확인사항
1. 각 중복 체크 2개 이상 알림 뜨는지 확인 (”최대 2개까지 선택해 주세요”)
2. 수신자 경험 ‘전혀 없었다’ 선택 시 → 발신자 경험 섹션으로 이동하는 지 확인
3. 수신자 경험 ‘자주 있었다, 가끔 있었다, 거의 없었다’ 선택 시 → 다음 섹션으로 이동하는 지 확인
4. 발신자 경험 ‘전혀 없었다’ 선택 시 → 설문지 제출로 이동하는 지 확인
5. 발신 경험 ‘자주 있었다, 가끔 있었다, 거의 없었다’ 선택 시 → 다음 섹션으로 이동하는 지 확인
6. 전하고 싶었던 말을 실제로 전했나? '바로 전했다, 일부만 전했다, 나중에 전했다' 선택 시 → 전한 경우 질문으로 이동 → 제출
7. 전하고 싶었던 말을 실제로 전했나? '전하지 못했다' 선택시 → 전하지 못한 경우 질문으로 이동 → 제출 필수 선택 질문지 최종 확인 필수 질문 선택 기준 (선택하는 사항(체크, 객관식)은 필수 O / 주관식 필수 선택 X)

팀원분들과 확인 후 나눠주신 티켓의 세부 내용에서

설문조사 작업에 대한 과정/내용을 작성하였다.

1) 설문조사 확인사항

2) 배포 후에도 수정/변경된 사항

3) 설문조사 템플릿이 변경된 사유 (나중에 확인하기위함)

4) 질문 의견에 대한 반영 여부 (왜 반영이 불가했는지 사유도 포함)

02. QA 템플릿

설문조사 배포 후 QA 템플릿 작업으로 넘어가기

팀원분께서 참고용으로 남겨주셨던 내용과

내가 작성했던 QA 템플릿을 생각하면서 템플릿을 잡아갔다.

일단 기본적인 틀을 잡아놓고 추후 QA 진행하면서

필요한 부분은 추가하며 진행하는 것으로 현재 버전에서 마무리!

✅ QA 리스트
*아래 순서를 표 형식으로 정리

1. 우선순위

2. 유형

3. 대분류

4. 중분류

5. 소분류

6. 테스트 케이스

7. 실제 결과

8. 상태 (PASS/FAIL)

9. 담당자

10. 테스트 날짜

11. 노션 링크 (에러 발생 시 구체적으로 기재)

03. 업무 분담

현재까지 완료된 설문조사 통계도 확인하고 레퍼런스도 체크하면서

서비스의 방향을 어떻게 생각하는 지 (대표 키워드)등을 논의했고

다음 스텝에 대해서 팀원들과 논의하면서 업무를 분담했다.

내일은 발신자 입장에서 유저 플로우를 설계하고 정리!

오늘 하루도 알차게 보냈다....진짜 눈 뜨면 하루가 지나가...

내배캠 PM 최종 프로젝트 (5) 욕구에 대한 단계 정리 & 설문조사 작성

yeppi' s — Tue, 30 Jun 2026 21:05:13 +0900

(6월 29일 TIL이지만 밀려서 지금 작성합니다..)

저번 주 키우던 강아지가 무지개 다리를 건너고

아직 집중은 잘 안되지만 그래도 최대한 집중하려고 노력했다

오늘 진행할 부분은 욕구에 대한 단계 정리와 설문조사 작성

팀원들과 논의한 결과 발신자 입장에 기준을 맞추기로 해서

욕구에 대한 단계 정리도 발신자 입장으로 쪼개보기로 하였다.

01. 욕구에 대한 단계 정리

발신자의 욕구에 대해 데스크 리서치를 진행했지만

근거, 이론 등이 수신자 보다 부족하다는 점을 알 수 있었다.

왜냐하면 발신자는 대부분 상황(트리거)가 있어야 움직이고

그 행동에 의미를 부여하거나 기록하지 않기 때문이라고 생각했다.

따라서 자체적으로 진행하는 설문 조사에서 발신자에 대한 생각을 알아볼 수 있을 것 같았다.

오히려 수신자의 경우 이론들을 찾아볼 수 있었다.

매슬로우의 욕구 이론
Maslow’s hierarchy of needs이란, '인간의 욕구는 타고난 것'으로
사람은 누구나 다섯 가지 욕구를 가지고 태어난다는 것이다.
욕구는 '욕구의 강도와 중요성'에 따라 다섯 단계로 분류하였다. (= 욕구5단계설)

※ 인간의 동기가 일반적으로 움직이는 양상을 묘사하기 위해 각 동기 단계를 작용하는 욕구로
생리적 욕구, 안전의 욕구, 애정과 소속의 욕구, 존중의 욕구, 자아의 실현 욕구로 구분했다.
[참고 출처] https://m.blog.naver.com/euna4520/221915250841

매슬로우의 욕구 이론, Maslow’s Hierarchy of Needs

※ 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음 쓰담쓰담의 심리학으로 알아보는 심리상담편...

blog.naver.com

칭찬은 이 피라미드 구조에서 '존경(존중)의 욕구'에 해당한다.

매슬로우의 욕구 이론에서는 모든 사람은 존중받고자 하는 욕구가 있다고 한다.
그러므로 사람은 어떤 일을 해내거나 무엇을 잘한다며 타인에게 인정을 얻고자 한다.

만약 사람은 존중의 욕구가 충족되지 않았거나 불균형이 생긴다면 자아 존중감이 낮아지거나 열등감을 갖게된다.
사람은 자아 존중감이 낮아지면 다른 사람들에게 더 인정을 받고자 명예·명성·권위 등과 같은 것들을 찾는다.

그 중에서도 '낮은 수준의 존중감'과 '높은 수준의 존중감'이 있다.
(1) 낮은 수준의 존중감 = 타인으로부터 존중받고자 하는 욕구
외적으로 형성된 존중감으로 지위나 인정, 명성, 위신, 주목 등의 욕구를 의미

(2) 높은 수준의 존중감 = 자기 존중에 대한 욕구
내적인 자기 경쟁력으로 사람이 경험을 통해 형성된 강인함, 경쟁력, 숙달, 자신감, 독립성
혹은 자유와 같은 가치를 갖고자 하는 것을 의미

낮은 수준 존중과 높은 수준의 존중 욕구가 결합하여야 자신 스스로가 중요하다고 느끼고
다른 사람으로부터 인정을 받아야 비로소 궁긍적인 의미에서 존중의 욕구가 충족되었다고 볼 수 있다.

수신자(칭찬을 받고 싶은 사람) 입장에서 흐름을 그려봤다.

현재 문제점들을 파악했고 우리 서비스는 어디서 개입되어야 할지

시각화하여 정리하는 시간을 가졌고 그로인해 얻은 결과는 아래와 같다.

칭찬받고 싶은 상황은 분명히 존재한다.  

하지만 현재 해소 경로(SNS, 지인)는 두 가지 이유로 작동하지 않는다.

상대가 있어도 — 말하는 행위 자체의 심리적 비용이 너무 커서 행동으로 이어지지 않음
상대가 없어도 — 욕구를 받아줄 사람 자체가 없음

결국 둘 다 "칭찬을 안전하게 전달받을 수 있는 적절한 채널이 없다" 는 것으로 수렴하고
이 때문에 익명 커뮤니티라는 차선책으로 흘러간다.

하지만 우리가 논의했던 발신자 입장에서는 고려하기 어려워

이에 대해서 담당자분들과 논의를 하였고 결국 내가 고민했던 문제는

모두가 고민했던 문제임을 알 수 있었다.

따라서 다른 팀원분들과도 논의한 결과 ' 수요는 있지만 공급이 없다'로 가정하고

이미 충분히 검증된 칭찬을 받고 싶어하는 욕구를 배경 근거로 두어

MVP 단계에서는 발신자의 표현 허들을 낮추는 방향으로 검증하는 것으로 정리하였다.

또한, 발신자 입장 데스크 리서치는 외부 자료로 획득하기 어려워

현재 진행된 부분까지 멈추고 설문조사 작성을 먼저 진행하였다.

02. 설문조사 작성

팀원분께서 욕구(수요)에 대한 검증은 이미 충분하지만

자체 데이터로 교차 검증하면 좋을 것 같다는 의견을 주시어

수신자와 발신자로 나누어 설문 내용을 작성하였다.

각 생각하는 설문조사 내용에 대해 작성하였고

팀원분들 내용까지 합쳐서 1차 정리 내용에 대해서 작성했다.

수신자/발신자를 나눠서 진행해야하고 꼭 필요한 질문들이 많다보니

어쩔 수 없이 길어졌지만 그래도 필요한 내용이면 넣어야 하니...

최대한 필요하지않거나, 지양하면 좋을 내용들은 제외했고

설문 조사 작성 폼을 왈라로 하려고 했으나 무료 플랜은 최대 1명까지

초대 가능으로 추후 데이터 분석 시 공유가 불편할 것 같아 구글폼으로 진행했다.

대략 작성하고 섹션 이동 구역 나누는데 도대체 왜 안 넘어가는지!!!

일단 설문조사 내용도 작성했으니 디테일한 건 내일 맞추고 배포하기로

내배캠 PM 최종 프로젝트 (4) 서비스 방향 정하기 & 4차 데스크 리서치(문제 정의)

yeppi' s — Fri, 26 Jun 2026 22:06:47 +0900

오늘은 정말 서비스 방향을 정해야한다..!

오전 스크럼 진행하고 바로 두 가지 서비스 중에서 선택해야 하는데

아무래도 욕심이 있다보니 우려점이 먼저 생각이 들었던 것 같다.

팀원분께서 두 가지 서비스 모두 우리의 기준에 맞으니

이제는 정말 하고 싶은 서비스, 납득이 가는 서비스를 선택하면 될 것 같다라고

의견을 주셨는데 굉장히 많은 도움이 되었다.

(신중할 수록 고민만 커지고 생각만 많아지고ㅠㅠ)

01. 서비스 방향성

사실 나는 내 결정을 내리지않고 멈춘 상태에서 잠들면

묵힌 생각들이 꿈에서라도 나오는 편이라 미리 정리했다.

그래서 나의 선택은 확고했던 것 같고...

(물론 고민하는 과정은 길었지만...!!)

다른 분들의 의견을 들으면서 선택을 했는데...했는ㄷ ㅔ...

설마했던 3:3이 나와서 당황했지만 서로 어떤 부분에서 선택했는지

다시 한번 한 줄로 정리하고 설득하면서 칭찬 기반 서비스로 확정되었다.

서비스가 확정되면서 우리가 해야 할 다음 스텝을 분담했다.

나는 그 중에서 커뮤니티, 앱 관련한 정성 리서치를 맡았다.

02. 커뮤니티(정성 리서치) & 앱(VOC)

2-1 앱 찾아보기 & VOC 취합

딱 들어맞는 앱을 찾고 싶었지만 생각보다 쉽지않았다.

그래도 비슷한 방향의 앱들을 몇 개 찾았지만 아무리 찾아도

우리에게 필요한 VOC를 찾기 힘들었고 시간이 오래걸릴 것 같아

오후에 틈틈히 찾아보는 것으로 일정을 바꿔서 진행했다.

하지만 조사하면서 들었던 생각은 사용자가 리뷰를 적어준다는 것

정말 서비스를 위해서라는 생각이 들었다.

2-2 커뮤니티 정성 리서치

처음엔 우리 서비스를 설득할 수 있는 정성 데이터를 찾고싶었다.

하지만 '사람들이 칭찬에 대해서 말을 할까?' 였는데 커뮤니티를 찾아보니

생각보다 칭찬을 해달라, 칭찬을 받고싶다에 대해서 게시글과 댓글이 많았다.

전체적으로 얻을 수 있었던 내용은 아래와 같다.

칭찬을 받고 싶은 사람의 상황(입장)

(1) 내가 칭찬 받고 싶은 상황&내용에 대해 공유하고 칭찬 구하기

(2) 내 자신에 대해 인정받고 칭찬받기

→ 상황을 극복하고 있다에 인정받거나, 감정적으로 칭찬 받길 원하거나

→ 응원보다 칭찬을 원하는 사용자들의 행동을 파악

1. 칭찬/인정 욕구
가장 데이터가 밀집된 카테고리 (전체의 약 65%)

(1) 결핍 기반 욕구

"비난만 받아서 칭찬이 고프다"  직장에서 욕·핀잔·비난을 반복적으로 받은 후 칭찬을 갈구하는 패턴이 가장 많음.
단순한 기분 좋음을 원하는 게 아니라 자존감 회복을 위한 수단으로 칭찬을 필요로 함
"칭찬받으면 잘하는데 항상 비난이랑 혼만 나네", "자존감이 바닥이야" 등

(2) 공유 대상 부재

"자랑할 곳이 없어서 여기 올림" 취업 성공, 연봉 인상, 자산 달성, 다이어트 감량, 성적 향상 등 명확한 성취가 있지만
주변에 공유할 사람이 없어서 블라인드·네이버 카페 등 익명 커뮤니티에 올리는 패턴이 뚜렷함
"친구 없어서 여기 쓰는 거 맞아", "주변 친구들은 박봉이라 어디 자랑할 곳이 없어서" 등
사회적 맥락 불일치(나의 성취를 이해해줄 주변인이 없음)가 공통 원인

(3) 존재 자체의 인정 욕구

"이유 없이 그냥 칭찬받고 싶다"  성취 없이도 "그냥 세상살이 팍팍하다, 이유 없이 칭찬받고 싶다",
"하루도 열심히 살았는데 토닥토닥해줬으면" 같은 욕구가 등장. 퍼포먼스와 무관한 무조건적 인정 욕구

(4) 칭찬 보관/회고 니즈

"힘들 때 꺼내보는 칭찬"  "칭찬을 캡처해서 핸드폰 메모장에 붙여넣는다",

"밤의 이정표 같은 별처럼 떠있다", "5살 때 들은 말 아직도 기억함" 등
칭찬은 순간적 경험이 아니라 자기 회복의 기준점으로 기능/ 사용자가

이미 수동으로 보관 행동을 하고 있다는 점이 특이함

(5) 발신자 니즈

"타인을 칭찬해주는 사람이 되고 싶다"  "나이 들고 타인의 존재에 대한 동의를 해주는 사람이 되려 노력 중"처럼
칭찬을 받는 니즈뿐 아니라 보내는 니즈도 존재함. 수신자 중심으로만 설계하면 놓치는 세그먼트

2. 표현 허들
데이터 건수는 적지만 (4~5건) 내용의 밀도가 높음

(1) 수신자의 방어 반응  "왜 이러지, 나한테 뭘 원하나 이런 생각이 먼저 든다", "부끄러워서 장난치며 넘기려고 한다" 등
칭찬을 받아도 진지하게 수용하지 못하는 패턴 한국 사회 특유의 칭찬 낯섦이 배경으로 보임

(2) 발신자의 표현 어려움  레딧에서 "소중한 사람에게 칭찬하는 것이 어렵거나 불가능하다고 느끼는 분이 계신가요?"라는 질문이
커뮤니티에 올라올 정도로 표현 자체가 허들. 특히 뭘 어떻게 말해야 할지 모르는 어휘/형식의 문제

(3) 장문 카톡의 부담  "장문 카톡 받으면 더 답답하려나", "핵심이 뭔지 파악하기 귀찮고 읽기 싫음"
칭찬을 길게 쓰는 게 오히려 상대방에게 부담이 될 수 있다는 발신자의 자기검열

단, 이 카테고리는 데이터가 부족해 패턴 일반화에 한계가 있음
집된 사례가 4~5건에 불과하고 수신 허들 vs. 발신 허들이 혼재되어 있어
어느 쪽이 더 큰 장벽인지 현 데이터로는 판단 불가하여 설문 조사 필요

3. 기존 방식의 한계
카톡, 편지, 스크린샷/메모장 3가지 방식이 한계로 등장
 ✅ 카톡

갑작스럽게 받으면 "어케 답장해야 되나, 당황스럽다"처럼 수신자의 답장 부담이 생김
발신자 입장에서도 "길게 보내려니 오글거려서 못 보냈다" 작성 자체가 걸림돌
1:1 채널이라 관계 온도차에 따라 부담이 큼

 ✅ 편지/손편지

"부담스럽다", "오글거려서 두드러기 난다", "나한테도 세심함을 바랄까봐 부담" 등  
상호성 부담이 핵심 저항. 편지를 받으면 나도 써줘야 한다는 심리적 의무감
생일·특별한 날이 아닌 일상적 상황에서는 특히 부담

✅ 스크린샷/메모장

이미 칭찬을 캡처해서 보관하는 사용자 행동이 자발적으로 존재하나 저장 위치가 흩어지고
맥락(누가, 언제, 어떤 상황에서)이 정리되지 않으며, 필요할 때 찾기 어려운 구조적 한계

03. 개인 회고

오늘 생각보다 정성 리서치에 시간이 많이 걸렸다.

아무래도 기존에 없는 서비스를 바라보니 어려웠던 것 같기도...

추가로 2차 정성 리서치도 필요할 것 같다는 생각

확실히 자체 설문 조사랑 검증은 필요할 것 같다.

그래도 이번 정성 리서치를 통해 설문 조사에서 어떤 점을

포함해야 할지 대략적인 구성이 나왔다.

확실히 최종은 눈 뜨고 나니까 금요일...

드디어 내일 주말! 푹 쉬고 컨디션 관리해서 월요일도 화이팅하자...

내배캠 PM 최종 프로젝트 (3) 3차 데스크 리서치 & 서비스 방향성 논의

yeppi' s — Fri, 26 Jun 2026 21:24:44 +0900

6월 25일 TIL 이지만 하루 밀렸다...

정말 이번 주는 계속 팀원분들과 논의하다보니

9 to 9을 넘었는데 25일에는 12시 넘게 논의하느라 밀렸다.

(12시에 끝나자마자 다시 사이드 프로젝트로 넘어가서ㅠㅠ)

01. 3차 데스크 리서치

이전에 정해진 쪽지 관련 서비스에 관해서

추가 데스크 리서치를 진행했는데 조사한 내용은 아래와 같다.

이 서비스에서는 어떤 문제를 풀 수 있을지, 핵심 문제는 무엇일지,

서비스의 가치, 우려사항 or 검증 사항까지 각자 정리하여 논의하였다.

1-1 이 서비스가 풀려는 문제가 뭐로 보이나?
(1) ✅ 칭찬/감사 표현의 어려움  

페인포인트: 마음은 있는데 표현 행동으로 못 넘어가는 것 

타깃 유저: 표현하고 싶은 사람 (발신자)  핵심 가치: 표현 허들 낮추기
→ 하지만 자체 설문 조사를 통해서 추가 검증 필요

(2) 서운함/감정 표현의 어려움 

페인포인트: 부정적 감정을 직접 말하지 못하고 쌓아두는 것 

타깃 유저: 말 못한 서운함이 있는 사람 혹은 서운함과 감정 표현에 어려움이 있는 사람

[우려사항]

→ 감정표현 불능증에 대한 연구가 있지만 임상적인 개념이고 “말하기 어색해서 서운함을 못 전한다”와 결이 다르다.
→ 감정 억제가 수동 공격적 행동으로 이어진다는 연구를 보면 익명 서운함 발송이 관계에 ‘도움이 될지 역효과가 날지 불분명’ 하다.
→ 서운함이라는 것 기준 자체가 사람마다 다르고 해결방식도 다르기 때문에 MVP에선 민감한 영역이라고 보여진다.

(3) 관계 회복/건강한 소통 

페인포인트: 멀어진 관계, 소통 단절 

타깃 유저: 관계가 어색해진 사람 

핵심 가치: 관계 복원

이 서비스가 풀려는 문제가 무엇인지 생각해보면

나는 위와 같이 서비스 방향성 로드맵을 잡을 수 있었다.

건강한 소통과 회복은 우리 서비스의 비전이고

서비스의 포지셔닝과 MVP는 칭찬, 감사 표현의 어려움이였다.

서운함은 우리 서비스가 실제로 '서운함'을 해소하는 과정에서

도움이 될지 혹은 역효과가 날지 검증할 수 있는 외부 자료가 부족했고

또한 자체적으로 테스트 하기에는 우선 순위가 아닐 것 같았다.

또한, 서운함이라는 것 기준 자체가 사람마다 다르고 해결방식도 다르기때문에

내가 서운함이라고 생각해서 갑자기 상대방에게 전송한다는 것 자체가

하나의 서비스 리스크라고 보여져 팀원들에게도 공유하였다.

1-2 핵심 문제

고마움이나 칭찬, 응원의 마음이 생겨도 표현으로 이어지지 못하는 경우가 많다.
그 이유는 마음이 없어서가 아니라 적절한 표현 방법을 찾지 못하기 때문이다.

카카오톡은 일상적인 대화가 오가는 공간이라 특별한 마음을 전하기에 어색하고
반면 손편지는 의미는 크지만 준비와 심리적 부담이 있어 선뜻 쓰기 어렵다.
결국 사용자는 두 가지 선택지 사이에서 어느 쪽도 선택하지 못한 채 어려워 하거나 그 마음을 그냥 흘려보낸다.

1-3 서비스 가치

(1) 표현 허들을 낮춘다
상황에 맞는 문구 가이드와 카드 형식을 제공해
무엇을 어떻게 써야 할지 몰라 망설이던 순간을 행동으로 전환한다.

(2) 전달된 마음을 따로 간직할 수 있다
감사나 응원 메시지는 일반 대화에 섞이면 시간이 지나 다시 찾기 어렵다.
카카오톡은 가족, 친구, 직장, 일회성 대화가 하나의 공간에 뒤섞여 있어
의미 있는 마음을 따로 보관하기에 적합하지 않다.

전달된 마음을 카드 형태로 분리 보관해

언제든 다시 꺼내볼 수 있는 디지털 편지함을 제공한다.

1-5 우려되거나 검증해야 할 가정

(우려) 익명 사이버 폭력 피해에 대한 정책 검토•강화 (참고 https://www.yna.co.kr/view/AKR20251015078900001)
(우려) 기프티콘/선물 기능의 부담감 (기프티콘을 도입한다면 가능할지 모르겠지만 최대 금액대를 지정하는 것도 좋을 듯)
(검증) 익명에 대한 거부감 - 받는 사람이 ‘익명’ 메시지를 긍정적으로 받아들이는지 검증 필요
(검증) 실제로 표현하지 못한 사람에 대한 행동 분석 & 검증 필요
(검증) 어떤 특정 상황에서 많이 사용할지에 대해 판단 필요 (직장, 학교, 동아리, 친구, 지인(친구보단 먼 사이), 가족)

나의 실패한 경험에서 얻을 수 있었던 인사이트는

바로 정책을 잘 검토하고, 정책을 대비해야한다는 것이다.

(이전에 정책으로 인해 휘청한 경험이 있기때문에....)

따라서 '익명' 기반을 유지한다면 정책상 문제가 없을지

향후 범위를 넓혔을 때 우려되는 상황을 없을 지 찾아보았는데

확실히 위험 요소는 있을 것으로 판단되어 가이드 라인을
꼼꼼히 검토하고 피해갈 수 있는 방안을 마련하는 것이 좋겠다고 생각했다.

02. 서비스 방향성 논의

이후 서로의 내용을 공유하면서 나눈 얘기 중에

칭찬이라는 부분이 추상적이고 뾰족한 문제정의가 어렵지않을까라는

고민에서 시작해서 프로젝트 시작 전에 한번 더 돌아보기로 하였다.

이전에 나눈 아이디에이션과 새롭게 나온 내용들을 통해

다양한 얘기를 나누면서 이런저런 방향을 생각해보았고

6월 25일 어느정도 정리는 되었지만 명확히 잡히진않았다!

12시까지 계속해서 논의한 과정이 긴 과정이긴 했지만

어떤 부분에서 우려가 되는지, 어떤 점이 이해가 가지않는 지

솔직하게 얘기를 나눌 수 있어 좋았고 프로젝트 시작 전에

'방향성'을 모두가 통일하는 것 같아 의미있는 과정이였다.

03. 개인 회고

개인적으로 중간에 다시 아이디에이션을 돌아보면서 떠올랐던 생각이

확장 범위, 문제 정의, 데이터 분석 모두 중요한 부분이지만

가장 중요한 건 '개발 기간이 어느정도이지?' 였다.

우리는 정해진 기간 안에 우리가 원하는 구현을 해야하고

그 안에서 QA, UT를 통해 검증하고 보완점을 찾아

V1에서 V2까지 만들어야 하기 때문에 기간 또한 중요했다.

(우리가 빨리 문서를 내어도 상황은 변할 수 있기 때문에..)

그래도 이렇게 열정으로 얘기 나누고 명확하게

짚어줄 수 있는 팀원분들과 함께해서 굉장히 의미있었다!

아자자!

내배캠 PM 최종 프로젝트 (2) 2차 데스크 리서치 & 아이디에이션

yeppi' s — Wed, 24 Jun 2026 21:31:23 +0900

어제 데스크 리서치와 아이디에이션을 진행하고 나서

추가로 2차 데스크 리서치와 아이디에이션을 진행했다.

1차에서는 이커머스와 소셜에 대해 알아보고 결합한 형태를 떠올렸는데

2차에서는 최대한 다양한 범위를 생각할 수 있도록 기준을 넓혔다.

2차 데스크 리처시 & 아이디에이션 기준
1. 사용자가 가볍게 접근할 수 있는 것
2. 사용자를 쉽게 모을 수 있는 구조
3. 팀원 모두가 알 수 있고 관심있게 볼 수 있는 것

01. 2차 추가 리서치 & 아이디에이션

1-1 동네 소분 모임에 대해

기존에 존재하는 앱에서는 소분소분이라는 앱이 있었지만

활성화되진 않는 것 같았고 쪼개요 등등 다양한 서비스는 있었다.

또한, 식품과 관련해서 리스크가 있을 것 같아 살펴보니 '상업적 판매' 정책도 존재했는데

당근에서는 판매 연결해주는 것이 아니라 모임이라는 방안으로

'사용자들이 알아서 모임을 만들고 그 안에서 이뤄지는 하나의 활동'의 개념으로 보았다.

실제 당근에서도 소분 모임이 존재하지만 왜 기능을 만들지 않았을까 이해할 수 있었다.

1-2 가장 기준에 맞는 지점은 어디일까?

가장 기준에 맞는 지점을 찾기 위해서 고민한 결과

내가 혹은 주변 지인이 느꼈던 상황, 불편함을 고민하여 좁혀보았다.

그리고 내가 이전에 참고했던 마케팅 아티클을 읽어보며 최근 2030에서는

어떤 트렌드와 라이프 스타일을 지향하고 있는지 알 수 있었다.

1. 취준생 & 이직러

취준생과 이직러 모두 면접을 본다는 행위 자체는 똑같다.

다양한 채용 커뮤니티를 참고하였을 때 (잡플래닛, 사람인, 리멤버 등등)

면접 후기, 예상 질문들을 탐색하지만 정보가 흩어져 있어

사용자가 직접 수집하고 정리해야한다는 불편함이 존재하고 있다.

그래서 사용자가 실제 면접에서 받았던 질문을 직무별로 등록하고

서로 공유할 수 있는 플랫폼을 고려해보았다.

하지만 확실히 취준 관련한 아이디에이션이 많을 것 같아 보류...

2. 2030 트렌드 기반

2030에서 자리잡고 있는 트렌드와 불편함이 무엇일지 고민했다.

2030에서 가장 화제인 것은 제철 코어 부분이였는데 음식을 넘어서

패션, 뷰티, 독서, 음악 등등 다양한 카테고리에 연결할 수 있었다.

(실제로 사용자들도 음식보단 생활 자체에 중심을 두었다.)

제철코어 참고 (1) 2026 MZ세대 소비 트렌드: 제철코어, 필코노미, 나노 커뮤니티
MZ세대는 가격과 기능보다 지금 이 순간의 감정과 경험에 반응하며
계절의 희소성을 즐기는 '제철코어' 소비를 보이고 있다.
[참고 출처] https://kbthink.com/life/card/mz-consumption-trends.html

제철코어 참고 (2) 개인 기록의 분산
일상 기록은 남기고 싶은데 일기는 부담스럽고 인스타는 아쉬움 때
셋로그를 제외하고 대체할 수 있는 서비스에 대해서 이야기하고 있다.
→ 독서 기록앱, 오늘의 영수증, 커피 기록앱, 영감 기록앱, 음식 기록앱, 이미지 아카이빙 앱(핀터레스트x)

하지만 여전히 각 장르별로 나눠져있고 장르를 통합할 수 있는 서비스는 일기장과 비슷한 형태 (자유롭게 작성)
[참고 출처] https://newneek.co/@gosum_beat/article/40658

그래서 생각한 것은 지금 이 순간 가장 제철인 나의 취향이였다.

각 카테고리 별로 지금 계절에 맞춰 항목을 노출 시키고

리스트 확인(발견) + 항목을 선택해서 기록할 수 있는 부분을 생각했다.

전체적으로 내용을 취합하고 1차 논의 시간을 거쳤다.

다양한 논의 끝에 세 가지 후보로 요약 해서 추가 리서치 시간을 가졌고

추가 리서치 시간에는 정말 니즈가 있는 부분인지

그리고 우려되는 사항은 무엇인지도 함께 정리하여 추가 논의

결론적으로 한 가지 방향성이 정해졌고 내일은 논의와...

디벨롭 시간을 거치면서 하나씩 정리해 나갈 예정...

02. 개인 회고

강조하고 싶은 도메인, 시장 규모, 차별점, 수익 구조, 프로젝트 기간 등

다양하게 고려를 하다보니 확실히 생각이 많아질 수 밖에 없었다.

그래도 이 과정이 제일 중요하니...! 의미있는 시간!...

내일은 더 분석해보고 이것저것 봐야겠다!...