[내일배움캠프] PM - 기획 실무 문서 작성

썸넬 놀라는 냥이

 

하기 싫다.

 

귀차니즘이 하늘을 찌르는 요즘.

 

의무감에 떠밀려 TIL을 쓴다.

 

그웨엑

---

https://www.youtube.com/watch?v=Lqb8qpXqtxw

<JVKE - Golden hour>

인스타 / 쇼츠로 하이라이트 부분이 바이럴 되서 유명해지긴 한 노래인데

 

그와 별개로 그냥 정말 좋은 노래임.

 

처음 피아노 부분도 좋고 가사도 이쁨.

 

굿굿

---

💎 PRD ( Product Requirements Document , 요구사항 정의서)

PRD는 예전 블로그에서도 다뤘었던 내용인데 다시 한번 짚고 넘어가보자.

 

요구사항을 체계적으로 정리한 문서가 PRD로, 프로덕트 개발 과정에서의 지침서 역할을 한다.

 

해당 문서를 잘 작성하면 이해관계자 및 팀원들 간의 커뮤니케이션을 원활히 하고 프로젝트 진행이 명확해집니다.

 

PRD를 작성하는 방법은 대표적으로

• 기능 이름 : 기능의 이름
• 기능 설명 : 해당 기능이 어떤 역할을 수행하는지 설명
• 우선순위 : 해당 기능의 중요도 (예: 필수, 권장, 나중에 추가 가능)
• 구현 기준 : 기능이 어떻게 작동해야 하는지에 대한 세부적인 설명

와 같이 작성한다.

 

예전에 Confluence에 작성한 코레일톡 UX 개선 PRD를 같이 다시 보면서 이해해보도록 하자!

🚄 코레일톡 UX 개선 PRD

 🗓 날짜

2025년 4월 17일

 

👥 참여자

• @이형석

 

🚧 개요

• 프로젝트 명: 코레일톡 로그인 개선 프로젝트
• 해결할 문제: 현재 코레일 앱의 로그인 구조는 사용자 ID가 아닌 무작위 회원번호(10자리)를 사용하게 되어 있어, UX 측면에서 진입장벽이 높고 사용성이 떨어짐
• 개선 목표:
  • 사용자의 진입 허들을 낮추기 위해 소셜 로그인을 기본 로그인 방식으로 전환
  • 회원번호 입력은 최소화하며, 필요 시만 보조 방식으로 제공
  • 회원번호는 여전히 내부 시스템 식별자로 유지하되, 사용자에게는 노출되지 않거나, 조회/복사 방식으로만 제한

📄 배경

• 현재 시스템:
  • 무작위 회원번호를 로그인 수단으로 사용함 → 사용자가 번호를 기억하거나 저장하지 않는 이상 재로그인이 어려움
  • 로그인 실패율 및 이탈률 증가 요인으로 작용
• 유의 데이터:
  • Google Play / App Store 리뷰에서 "회원번호 기억 안 남", "소셜 로그인 눌러도 안 됨" 등 사용자 불만 지속적으로 제기됨
  • Amplitude 퍼널 기준: 로그인 실패율이 높고, 로그인 소요 시간도 평균보다 긴 편
• 경쟁사 비교:
  • SRT, KTX 등 대부분의 경쟁 서비스는 이메일 기반 ID 또는 간편 로그인(소셜/휴대폰 인증) 제공

🏁 개선 방향

• 유저 시나리오 : “ 회원번호를 통한 로그인 과정 불편해요! ”
• 중요 전략 : 사용자가 쉽게 로그인에 도달할 수 있도록 소셜 로그인 중심 UI 재편
• 개선 방안 :
  1. 소셜 로그인(Google, Kakao, Apple 등)을 기본 노출 UI로 배치
  2. 최근 로그인한 소셜 계정이 있을 경우 자동 로그인 또는 안내 문구 제공
  3. 회원번호 로그인은 하단 또는 '기타 로그인 방식'으로 이동
  4. 로그인 성공 시, 회원번호는 백엔드에서 자동 생성 및 매핑 처리 (유저에게는 노출 X 또는 설정 내 조회 가능)

 📍 요구사항 (Requirements)

- 기능 요구사항 (Feature Requirements)

• [FR-01] Google/Kakao/Apple 소셜 로그인 SDK 연동 및 UI 구현
• [FR-02] 신규 회원가입 시 소셜 로그인으로 가입하면 자동으로 회원번호 발급 및 매핑
• [FR-03] 회원번호는 설정 화면 등에서만 조회/복사 가능하도록 제한
• [FR-04] 비회원 또는 비정상 로그인 접근은 예외 처리되도록 설계

 

🎫 사용자 흐름 (User Flow)

1. 앱 실행
2. 로그인 화면 진입
3. "Google" 또는 "Kakao" 로그인 버튼 클릭
4. OAuth2.0 인증 성공
5. (최초 로그인 시) 회원번호 자동 생성 → DB에 매핑
6. 홈 화면 진입

 

✅ 데이터 및 로깅 요구사항

• 이벤트 정의 (Amplitude 기준):
  • login_screen_view
  • login_social_click (method=google/kakao/...)
  • login_success
  • login_failed
  • member_number_auto_generated

 

📊 사용자 흐름 (User Flow)

1. 앱 실행
2. 로그인 화면 진입
3. "Google" 또는 "Kakao" 로그인 버튼 클릭
4. OAuth2.0 인증 성공
5. (최초 로그인 시) 회원번호 자동 생성 → DB에 매핑
6. 홈 화면 진입

 

🗓 릴리스 계획 (Release Plan)

스프린트	일정	주요 내용
Sprint 1	~5월 1주	개선 구조 논의, UI 스케치 및 사용자 흐름 확정
Sprint 2	~5월 3주	로그인 화면 개발, SDK 연동 및 테스트
Sprint 3	~6월 2주	Amplitude 이벤트 연동, QA 및 베타 배포

 

⛔ 제약 조건 (Constraints)

• OAuth2.0 인증 구조에 대한 보안 검토 및 정보보호 심사 필요
• 다수의 기존 시스템이 회원번호 중심 구조로 되어 있어 매핑 시 중복 방지 및 정합성 검증 로직 필요
• 일부 예외 상황(예: 만 14세 미만, 외부 단말기 등)에 대한 예외 처리 정책 마련 필요

 

이렇게 작성해보았는데,

 

PRD 작성시 주의할 점은 '명확하고 구체적으로' 요구사항을 작성해야 하고,

 

'우선순위 설정과 범위'를 관리해야 한다는 점이다. 이를 잊지 말자.

---

📜 서비스 정책서란?

서비스 정책서는 서비스 개발이나 개선 과정에서 기능에 대한 명확한 정의와 구현 기준을 설정하여, 관련 팀들이 일관되게 작업할 수 있도록 하는 문서이다.

 

예를 들어 비밀번호 정책서의 경우는 

 

 

와 같이 작성할 수 있다.

 

서비스 정책서의 경우 제일 중요한 건 '법적 및 규제 준수' 부분이다.

 

대표적으로 개인정보 보호 정책이 있다.

 

서비스 정책서를 작성하는 방법은

· 서비스 정책서의 목적 정의 · 정책의 범위 설정 · 정책의 주요 항목 및 세부 사항 작성 · 정책 문서화 및 공유 · 정기적 검토 및 업데이트

 

와 같이 진행한다.

---

💢 에러 케이스

서비스나 시스템에서 발생할 수 있는 예외 상항을 정의하고 이를 어떻게 처리할 지를 명확하게 기술하는 문서를 말한다.

 

서비스의 안정성과 UX를 향상시킬 수 있으며, 문제 발생 시 어떻게 처리할 지 명확히 하기 위해 작성한다.

 

에러 케이스 / 에러 발생 조건 / 에러 메시지 / 에러 코드 4가지를 표로 나누어 작성한다.

 

예시는 아래와 같다.

에러 케이스	에러 발생 조건	에러 메시지	에러 코드
결제 시 카드 정보 오류	사용자가 입력한 카드 정보가 유효하지 않거나, 만료된 카드로 결제를 시도할 때	"입력하신 카드 정보에 오류가 있습니다. 카드 번호와 만료일을 다시 확인해 주세요."	PAY102
결제 시 결제 서버 오류	결제 서버와의 연결 실패 또는 응답 지연으로 결제가 처리되지 않을 때	"결제 서버에 문제가 발생했습니다. 잠시 후 다시 시도해 주세요."	PAY500
파일 업로드 실패	파일 크기가 업로드 제한을 초과하거나 파일 형식이 지원되지 않을 때	"업로드 가능한 최대 파일 크기를 초과하거나 지원되지 않는 파일 형식입니다. 파일을 확인 후 다시 시도해 주세요."	UPLOAD400

 

그런데 이걸 PM이 실무에서 진짜 쓰는 지는 모르겠다..?

---

 

스토리보드(상세 기획)의 경우는 따로 제대로 열심히 한 번 제작해보기 위해 따로 뺐다.

 

그럼 오늘은 여기까지.