오늘은 서비스 기획의 뼈대이자 프로젝트의 나침반이 되는 서비스 정책 문서(Policy Document) 작성법에 대해 이야기해볼게. 기획 초년생 시절에는 화면 설계서(SB) 그리기에 바빠서 정책 정의를 소홀히 하기 쉬운데, 사실 정책이 흔들리면 프로젝트 전체가 산으로 가게 되거든. 7년 차 기획자인 내가 실무에서 구르며 터득한 노하우를 아낌없이 나눠줄게.
1. '정책(Policy)'과 '가이드라인(Guideline)'을 구분하자
실무에서 가장 흔히 하는 실수가 규칙과 방법을 혼동하는 거야. 정책은 타협할 수 없는 '의무 규정'이고, 가이드라인은 권장하는 '행동 지침'이야.
예를 들어, "사용자는 반드시 본인 명의의 계정으로만 가입해야 한다"는 정책이고, "비밀번호는 8자리 이상, 특수문자를 포함해 설정하는 것을 권장한다"는 가이드라인에 가깝지. 기획자는 이 두 가지를 명확히 구분해서 문서에 녹여내야 해. 필수 조건과 선택 조건을 흐리멍덩하게 섞어 쓰면 개발 단계에서 반드시 혼선이 오게 되어 있어.
2. 두괄식으로 쓰고, 시각 자료를 적극 활용해봐
텍스트가 빽빽한 정책 문서는 읽는 사람을 지치게 만들어. 개발자나 디자이너는 바쁘기 때문에 문서를 훑어보듯(Skim) 읽는 경우가 많거든. 그래서 정책을 쓸 때는 무조건 결론(규칙)을 가장 먼저 제시하고, 그 아래에 상세 설명이나 예시를 덧붙여야 해. 텍스트로만 장황하게 나열하기보다는 표(Table)나 흐름도(Flowchart)를 활용하는 것이 훨씬 효과적이야.
- AS-IS (나쁜 예시): 사용자가 탈퇴를 신청하면 즉시 탈퇴 처리가 되지만, 만약 진행 중인 주문이 있다면 탈퇴가 불가능하고 모든 주문이 완료된 후에 탈퇴가 가능합니다. 단, 보유한 포인트는 즉시 소멸합니다.
- TO-BE (좋은 예시):
회원 탈퇴 규칙: 진행 중인 주문건이 0건일 때만 즉시 탈퇴 가능.포인트 처리: 탈퇴 완료 즉시 보유 포인트 전액 소멸 (복구 불가).
3. '예외 케이스(Edge Case)'를 집요하게 파고들어야 해
내가 기획자로서 7년 동안 일하면서 뼈저리게 느낀 건, 서비스의 완성도는 '예외 케이스를 얼마나 꼼꼼하게 정의했는가'에서 갈린다는 점이야. 일반적인 프로세스(Happy Path)는 누구나 쉽게 기획해. 하지만 결제 도중 네트워크가 끊겼을 때, 쿠폰 유효기간이 결제 취소 시점에 만료되었을 때 같은 예외 상황에 대한 정책이 없으면 개발 단계에서 구멍이 숭숭 뚫리게 되지. "이런 상황에서는 어떻게 처리하지?"라는 질문을 스스로 끊임없이 던져보며 예외 정책을 촘촘하게 세워봐.
4. 법무(Legal), CS, 개발팀과 끊임없이 싱크를 맞추자
정책은 기획자 혼자서 상상해서 쓰는 소설이 아니야. 개인정보 보호법이나 전자상거래법 등 법적인 이슈가 얽혀 있는 경우가 많기 때문에, 초안을 작성한 후에는 반드시 법무팀이나 개인정보 담당자의 검토를 받아야 해. 또한, 정책을 기술적으로 구현할 개발팀과 고객의 문의를 직접 응대할 CS팀의 의견도 적극적으로 반영해야 실무에서 삐걱거리지 않는 단단한 정책이 완성되더라.
💡 핵심 정리
- 명확한 구분: 타협 없는 '정책'과 유연한 '가이드라인'을 구분해서 작성해봐.
- 두괄식 구조: 핵심 규칙을 가장 먼저 배치하고, 표와 예시를 활용해 가독성을 높여야 해.
- 예외 케이스 정의: 발생 가능한 변수(Edge Case)를 집요하게 찾아내 정책에 반영하자. 처음에는 정책 문서 작성이 막막하고 어렵게 느껴질 수 있어. 하지만 이 정책이 단단하게 잡혀 있어야 동료들도 흔들리지 않고 작업할 수 있거든. 기획자로서 서비스의 법을 만드는 일인 만큼, 자부심을 가지고 차근차근 작성해봐!