내일배움캠프 사전캠프 TIL: PM이 문서를 못 쓰면 개발자가 야근한다

 

기획 문서는 나를 위한 게 아니라, 나 없이도 팀이 돌아가게 만드는 장치다!

 

마케터로 일할 때, 기획서를 대강 방향만 잡으면 되는 것으로 생각했습니다.

 

사실 연차가 얼마 되지 않은 상태에서 구조에 너무 매몰되면 안되니까

사수분이 그렇게 지도해주셨을지도 모르겠다는 생각이 방금 문득 드네요.. 

근데 그 습관이 지금까지 이어지고 있었음 .. ㅋㅋㅋㅋ

 

아무튼 오늘 공부하면서 PM으로서 그렇게 일하면 얼마나 팀에 민폐일지 새삼 깨달았습니다.

PM은 자신이 없어도 팀이 움직일 수 있는 문서를 써야 하는 사람이고,

오늘은 그 문서들이 어떻게 생겼는지, 왜 그 구조가 필요한지를 배웠습니다.

---

이커머스 PM이 알아야 할 도메인 정책 설계

강의에 앞서 오늘 아티클 카타 시간에 이커머스 서비스 기획의 핵심 개념을 정리한 아티클을 읽었습니다.

읽으면서 마케터로 일했을때와 큰 구조 자체는 많이 다르지 않은 것 같더라구요

아무래도 매출을 다루는 직무라 그랬나봅니당...

이커머스는 5개 도메인이 맞물려 돌아간다!

도메인	핵심 역할	비즈니스 임팩트
회원·인증	고객 데이터 무결성 확보	체리피커 방지 → 마케팅 비용 누수 차단
상품 관리	원본, 전시, 옵션 3단계 계층	원가 누락 시 ROI 분석 불가, 데이터 사일로 발생
주문·결제	1원의 오차도 없는 정합성	결제 수단별 취소 정책 미설계 → CS 비용 폭증
배송 처리	물류 원가 최적화	추가배송비 자동화 미비 → 건당 수천 원 손실
클레임·환불	리텐션과 손실 방어의 균형	무분별한 취소 허용 → 물류 비용 폭증

마케터 눈으로 본 인사이트!

마케팅을 할 때는 매출 지표가 이상하게 나오면 단순히 광고 소재 문제라고 생각했습니다.

온통 머릿속엔 광고밖에 안들어있음 = 마케터...(아마...)

 

아티클을 읽고 나서 보니, 좀더 거시적인 구조에서 PM으로서 비즈니스 임팩트를 만들어내는 관점을 배울 수 있었습니다.

(e.g. 회원 인증 로직이 허술해서 한 사람이 여러 계정으로 쿠폰을 쓰면 ARPU 자체가 왜곡됨)

ㄴ 데이터 이상의 원인이 기획 설계에 있을 수 있다!

 

마케터는 식당 전단지를 뿌려서 사람들이 들어와서 일단 '사게' 만드는 역할로,

매출이 나오지 않을 때 전단지 내용을 수정하는 직무라면

 

PM은 식당에서 음식을 만들고 결제까지 하는 모든 과정을 책임지는 직무!

(재료 소싱하고, 만들고, 서빙하고, 결제하고, 고객 클레임 책임지고 등등등...)

 

나의 한 문장 요약: 이커머스 PM의 기획은 '기능을 만드는 일'이 아니라,
도메인 간 정책의 허점이 비즈니스 손실로 이어지지 않도록 방어선을 촘촘하게 설계하는 일이다.

---

서비스 기획 숙련 강의 수강 내용: 서비스 기획 산출물, 이렇게 쌓인다

오늘 강의에서는 아이디어가 실제 개발 가능한 기획 문서로 만들어지는 과정을 순서대로 배웠습니다. 

무엇을 만들지(PRD) → 어디에 배치할지(IA) → 어떤 기준으로 운영할지(정책서)
  → 예외 상황 처리(에러 케이스) → 기능별 상세 설계(스토리보드)

1. PRD: "빠르게"는 기획서가 아니다

PRD는 팀 전체가 같은 그림을 그릴 수 있게 해주는 지침서입니다. 작성할 때 가장 중요한 건 모호함을 없애는 것입니다.

• ❌ "앱이 빠르게 로딩되어야 한다"
• ✅ "홈 화면은 사용자가 진입한 후 3초 이내에 로딩이 완료되어야 한다"

숫자와 조건이 없으면 기획서가 아닙니다.

마케팅 보고서에 "광고 성과를 개선하겠습니다"라고 쓰면 아무도 OK 안 해주는 것처럼요..^^

 

PRD에 꼭 들어가야 하는 것들

• 프로젝트 개요 (목적·타겟·핵심 가치)
• 기능 목록 + 우선순위 (필수/권장/나중에)
• MVP 기준 릴리즈 계획
• 기대 성과 (정량 목표)

2. IA: 사용자가 헤매지 않게 길을 놓는 일

IA(Information Architecture)는 서비스 안에서 정보의 위치와 연결 관계를 설계하는 작업입니다.

쉽게 말하면 "이 앱에서 내가 원하는 걸 어떤 경로로 찾을 수 있는가"를 설계하는 일입니다.

 

잘 만들어진 IA는 팀 간 협업의 기준점이 되고, 서비스가 커져도 유연하게 기능을 추가할 수 있는 뼈대가 됩니다.

반대로 IA가 엉망이면 기능을 추가할 때마다 전체 구조를 손봐야 하는 상황이 발생합니다..ㅠ

3. 서비스 정책서: 말이 아닌 문서로 합의한다

정책서는 "우리 서비스가 이런 상황에서 이렇게 동작한다"를 명문화한 문서입니다. 없으면 매번 회의에서 같은 질문이 반복됩니다.

"비밀번호 몇 자리였죠?" "5번 틀리면 잠그는 거 맞죠?"

 

등등..

 

이걸 매번 말로 확인하는 대신 정책서 하나로 해결합니다.

마케터 시절 캠페인 세팅 가이드라인을 만들어두면 신입 팀원이 혼자서도 세팅할 수 있던 것과 같은 원리인 것 같아요

 

4. 에러 케이스: 잘 될 때보다 안 될 때를 더 많이 생각해라

에러 케이스 정의는 예외 상황이 발생했을 때 어떻게 처리할지를 미리 적어두는 작업입니다. 크게 두 종류로 나뉩니다.

서비스 오류	사용자 요청이 정상 처리 안 된 경우	비밀번호 불일치, 카드 정보 오류
시스템 오류	서버·DB·API 등 내부 문제	API 서버 응답 없음, DB 연결 실패

 

에러 메시지는 단순히 "오류가 발생했습니다"가 아니라, 사

용자가 다음에 무엇을 해야 하는지 알 수 있게 써야 합니다. 이 부분이 UX와 직결됩니다.

5. 스토리보드: 기획의 마지막 퍼즐

스토리보드(상세 기획)는 기능 하나하나가 어떻게 동작해야 하는지를 입력값, 출력값, 흐름까지 구체적으로 정의하는 문서입니다. 협업자가 이 문서만 보고도 개발하거나 디자인할 수 있어야 합니다.

 

핵심 구성 요소는 세 가지입니다.

• 기능 개요: 무엇을, 왜 만드는지
• User Flow: 사용자가 목표를 달성하기까지의 경로 시각화 (분기점 포함)
• 기능 명세: 입력값 조건 + 성공/실패 시 출력값

---

오늘의 회고

기획 문서는 PM이 '설명하기 위해' 쓰는 게 아니라, PM이 없어도 팀이 움직일 수 있도록 '작동하게' 쓰는 것

 

7~9년차 마케터 선배들을 보면서

약간.. 좋게 말해 ✌️머리가 좋은✌️선배들은 문서 구조화보다는 말로 때우는(삶의 지혜,,,ㅎㅎ)

경우가 많았던 것 같은데..

 

말로 하는것도 좋지만 문서화하고 정리하는 업무를 더 좋아하고, 잘했던지라

직무 전환을 결심한게 잘한 선택이라는 생각도 드네요.

 

일단.. 면접이 끝나고 조금 여유가 생기면 빨리 과제를 끝내고

개인적으로 쫌쫌따리 구현해봤던 밤티 바이브코딩 산출물을 가지고 각종 PM 문서들을 만들어볼까 합니다,,