정책의 종류

이 글에서는 정책의 중요성에 대해 언급하고, 그 세부 내용을 단계적으로 살펴보고자 합니다. 많은 경우 정책은 화면 설계나 기능 정의가 어느 정도 마무리된 뒤 “정리해야 할 문서” 정도로 취급됩니다. 그러나 실제로 정책은 정리의 대상이 아니라, 서비스의 뼈대를 구성하는 기준입니다. 무엇을 만들 것인가보다 중요한 질문은 “이 서비스는 어떤 원칙으로 작동하는가”이며, 정책은 바로 그 작동 원칙을 문서로 고정하는 작업입니다. 따라서 정책은 단순한 설명(디스크립션)이 아니라, 서비스의 경계와 권한, 책임과 예외 처리 기준까지 포함하는 운영 철학에 가깝습니다. 이 글에서는 정책이 왜 서비스의 안정성과 직결되는지, 그리고 서비스 정책·개발 정책·운영 정책이 어떤 구조로 정리되어야 하는지를 구체적으로 살펴보겠습니다.

 

정책은 ‘디스크립션’이 아니라, 서비스의 작동 원칙이다

서비스 기획에서 정책은 흔히 “나중에 정리해야 하는 골치 아픈 문서”로 밀리곤 합니다. 특히 화면 설계나 기능 정의가 먼저 진행될수록 정책은 뒤로 밀립니다. 그런데 정책은 단순히 상세한 문장 몇 줄을 정리하는 작업이 아닙니다. 정책은 서비스가 실제로 굴러가는 기준, 즉 “이 서비스는 어떤 룰로 움직이는가”를 정해두는 일입니다. 그래서 디스크립션(화면에서 무엇을 어떻게 보여주는지 설명하는 것)과는 성격이 다릅니다. 디스크립션이 ‘보이는 것’을 설명한다면, 정책은 ‘보이지 않는 기준’을 만드는 것입니다. 사용자가 어떤 조건에서 어떤 권한을 갖는지, 어떤 데이터를 어떤 방식으로 수집·보관하는지, 운영자가 무엇을 어디까지 할 수 있는지, 예외 상황에서는 어떤 판단을 우선하는지처럼 서비스의 실제 작동을 지배하는 기준이 정책으로 고정됩니다. 결국 정책은 화면보다 깊은 층위에서 서비스의 안정성을 잡아주는 장치이고, 기획자가 서비스의 운영과 개발을 ‘예측 가능한 형태’로 만드는 가장 중요한 수단이 됩니다.

그렇기 때문에 정책이 어렵고 머리 아픈 건 자연스러운 일입니다. 오히려 정책이 쉬우면 이상하다고 봐야 합니다. 서비스는 항상 예외가 생기고, 예외는 결국 운영 비용과 개발 비용으로 돌아옵니다. 정책은 그 예외를 ‘가능한 한 미리’ 정리해서 시행착오를 줄이려는 장치이기도 하지만, 동시에 현실적으로는 모든 것을 한 번에 완벽히 고정할 수 없기 때문에 “빠르게 정리할 수 있는 부분부터 먼저 치고 나가고, 불확실한 부분은 여지를 남겨두며, 시행착오를 반복해 고도화한다”라는 접근이 필요해집니다. 다만 여기서 중요한 전제가 하나 있습니다. 여지를 남긴다는 것이 ‘대충’이라는 뜻이 되면 안 됩니다. 여지는 ‘결정의 보류’가 아니라 ‘결정 보류의 범위와 이유가 문서로 남아 있는 상태’여야 하고, 그래야 팀이 같은 기준으로 다음 결정을 이어갈 수 있습니다.

 

정책의 3대 핵심: Identity, IA, Policy는 분리될 수 없다

정책은 혼자 존재하지 않습니다. 정책은 서비스의 Identity(정체성)와 IA(정보 구조) 위에서만 제대로 작동합니다. Identity는 “우리는 어떤 서비스인가, 무엇을 지향하는가”를 규정합니다. IA는 “그 지향점이 사용자 경험으로 구현될 때 어떤 정보 구조를 갖는가”를 정의합니다. 정책은 그 위에서 “그 구조가 운영과 개발 과정에서 흔들리지 않도록, 어떤 기준과 규칙으로 통제되는가”를 결정합니다. 이 세 가지가 맞물리지 않으면, 서비스는 겉보기엔 만들어져 있어도 내부에서부터 균열이 시작됩니다.

예를 들어 Identity가 ‘신뢰’와 ‘안전’을 핵심으로 한다고 해놓고, 정책이 그와 어긋나면 사용자는 얼마 못 가서 서비스에 대한 감각적 불일치를 느낍니다. 또 IA에서 회원 체계를 ‘일반/사업자/관리자’로 나눠놓고, 정책에서 권한 범위가 겹치거나 모호하면 운영자는 매번 케이스별로 즉흥 판단을 하게 되고, 그 즉흥 판단은 시간이 지날수록 내부 기준을 깨뜨립니다. 결국 정책이 부실하면 “IA와 별개로 서비스에 부분적인 균열이 생기고, 그 균열이 누적되면 서비스 전체가 흔들린다”라는 말이 현실이 됩니다.

여기서 자주 쓰는 비유가 ‘미세한 누수’입니다. 집에서 아주 작은 누수는 당장 큰 문제처럼 보이지 않을 수 있습니다. 하지만 그 누수는 시간이 지나면 천장 얼룩이 되고, 아래층 피해가 되고, 결국 큰 비용과 갈등으로 커집니다. 정책도 똑같습니다. 작은 빈틈은 초기에는 “일단 넘어가자”로 처리되지만, 그게 몇 번만 반복되면 운영의 기준이 사람마다 달라지고, 개발은 예외 처리에 시달리며, 고객 경험은 들쑥날쑥해집니다. 그래서 정책은 ‘완성도 높은 기능’보다도 오히려 ‘예외가 생겼을 때 흔들리지 않는 기준’을 만들어주는 역할을 합니다. 정책의 철저함은 단순 꼼꼼함이 아니라, 서비스의 장기 비용을 줄이는 전략입니다.

 

정책은 구조로 이해해야 한다: 서비스정책 / 개발정책 / 운영정책

정책을 정리할 때 가장 먼저 해야 하는 일은 정책을 한 덩어리로 보지 않는 것입니다. 정책은 크게 서비스정책, 개발정책, 운영정책으로 나뉘며, 각각의 질문이 다릅니다. 서비스정책은 “무엇을 제공할 것인가”를 답합니다. 개발정책은 “그것을 어떻게 구현할 것인가”를 답합니다. 운영정책은 “그 서비스를 어떤 방식으로 관리하고 제공할 것인가”를 답합니다. 이 구조를 구분하지 못하면 기획 문서에서 흔히 보는 문제가 발생합니다. 예를 들어 서비스정책 문서에 개발 조건(아이디 최소 글자 수, 비밀번호 정규식 등)이 섞이거나, 운영정책에서 다뤄야 할 권한 체계가 서비스정책 단계에서 애매하게 남아버리는 식입니다. 그러면 문서가 길어질수록 내용은 많아지는데 기준은 더 흐려지고, 결국 “정책이 있는데도 정책대로 안 굴러가는” 상태가 됩니다.

따라서 정책은 ‘정의’의 층위를 분리해서 적어야 합니다. 서비스정책은 서비스의 경계선을 긋는 작업이고, 개발정책은 그 경계선 안에서 시스템이 동일하게 작동하도록 로직을 못 박는 작업이며, 운영정책은 실제 운영 과정에서 사람이 바뀌어도 동일한 판단이 반복되도록 절차와 권한을 만드는 작업입니다. 이 세 층위가 정합적으로 이어질 때 정책은 비로소 “문서”가 아니라 “기준”으로 작동합니다.

 

서비스 정책: “이 서비스는 무엇인가”를 먼저 정의한다

서비스정책은 한마디로 ‘정의의 문서’입니다. 이 단계에서 기획자가 해야 하는 일은 “무엇을 제공할지”를 확정하고, 서비스가 포함하는 개념의 범위를 명확히 하는 것입니다. 예를 들어 ‘회원가입’을 만든다고 했을 때, 서비스정책은 “회원이란 무엇인가”부터 시작해야 합니다. 회원을 단순히 가입한 사용자로 볼 것인지, 특정 약관 동의 여부가 포함되는지, 연령 제한이나 법적 조건이 필요한지, 사업자 회원과 개인 회원이 동일한 가입 흐름을 갖는지 같은 ‘회원 개념의 경계’를 확정해야 합니다.

그 다음으로 서비스정책에서 중요한 것은 회원 유형(회원종류)의 분류와 이용 권한(이용범위) 정의입니다. 일반 회원과 사업자 회원, 혹은 개인/기업/관리자처럼 유형이 나뉜다면 각 유형이 어디까지 접근 가능한지, 어떤 기능이 잠겨 있고 어떤 기능이 열려 있는지부터 정책으로 고정되어야 합니다. 여기서 ‘권한’은 화면에 버튼이 보이냐 마냐의 문제가 아니라, 서비스가 해당 사용자에게 무엇을 허락하는지의 문제입니다. 그리고 이 권한 정의가 개발정책과 운영정책의 기준점이 됩니다.

또 하나, 서비스정책은 가입 시 수집정보를 정의합니다. 이때 “어떤 정보를 받는다(수집한다)”를 규정하는 것이 핵심입니다. 필수/선택 항목을 나누고, 어떤 항목이 서비스 제공에 필수인지, 어떤 항목이 부가 목적(예: 마케팅, 개인화)인지 범주를 정합니다. 그리고 탈퇴 시 보관정보를 다룹니다. 탈퇴 후 어떤 정보는 즉시 삭제하는지, 어떤 정보는 일정 기간 보관해야 하는지, 보관이 필요한 이유가 무엇인지 같은 기준이 이 단계에서 잡혀야 합니다. 왜냐하면 이 기준이 없으면 운영 단계에서 “이 데이터 지워도 되나요?” 같은 질문이 매번 나오고, 그때마다 즉흥 판단이 쌓여서 리스크가 됩니다.

여기까지가 서비스정책의 핵심입니다. 중요한 건 서비스정책이 개발자의 입력 조건을 세세하게 적는 문서가 아니라는 점입니다. 서비스정책은 “무엇을 한다”를 정의하는 문서이고, “어떻게 한다”는 개발정책으로 넘어가야 합니다. 이 구분이 깨지면 정책 문서는 길어지기만 하고, 실제로는 아무 기준도 못 세우는 상태가 되기 쉽습니다.

 

개발 정책: “어떻게 구현되어야 하는가”

서비스정책이 개념의 경계를 그었다면, 개발정책은 그 경계를 시스템이 실제로 동일하게 실행하도록 규칙을 고정합니다. 예를 들어 서비스정책에서 ‘아이디를 수집한다’고 정했다면 개발정책에서는 아이디의 입력 조건이 들어가야 합니다. 최소/최대 글자 수, 허용 문자, 금지 문자, 중복 체크 방식, 에러 메시지의 기준, 저장 전 검증 타이밍 같은 것들이 이 단계에서 정의됩니다. 비밀번호도 마찬가지입니다. 최소 길이, 필수 포함 요소(대/소문자, 숫자, 특수문자), 동일 문자 반복 제한 같은 룰을 명확히 해야 개발자가 구현할 수 있고, QA가 검증할 수 있습니다.

개발정책에서 빠지기 쉬운데 가장 중요한 것이 ‘인증 방식’과 ‘약관 동의 방식’입니다. 본인 인증을 할지, 점유 인증(이메일/SMS)을 할지, 인증코드 유효시간과 재전송 제한은 어떻게 할지, 실패 횟수 제한이나 잠금 처리 기준은 무엇인지 같은 것들이 로직으로 정의되어야 합니다. 약관 동의도 단순히 “필수/선택” 구분을 넘어서 전체 동의 버튼 제공 여부, 필수 약관 미동의 시 처리, 약관 내용을 끝까지 스크롤해야 동의 버튼이 활성화되는지 같은 UX와 로직의 결합 지점이 정책으로 정리되어야 합니다.

그리고 개발정책의 핵심 중 핵심은 “논리 프로세스(Logic process)”입니다. 회원가입 흐름을 예로 들면, 사용자는 어떤 순서로 입력하고, 어떤 시점에 어떤 검증이 이루어지고, 어느 단계에서 서버에 저장되고, 실패하면 어디로 되돌아가며, 완료 조건은 무엇인지가 일관된 플로우로 정의되어야 합니다. 이 프로세스가 명확하지 않으면 개발자는 ‘자기 방식’으로 구현하게 되고, 운영 중에 발생하는 예외 케이스를 나중에 덧대기 시작합니다. 그 덧대기가 쌓이면 결국 기능이 복잡해지고, 고객 경험은 예측 불가능해집니다. 그래서 개발정책은 조건의 나열이 아니라, 시스템이 움직이는 방식의 합의 문서입니다.

추가로, 데이터 검증과 저장 방식도 개발정책의 일부로 다뤄져야 합니다. 어떤 항목을 어떤 정규식으로 검증하는지, 중복 데이터는 어디에서 체크하는지, 비밀번호는 어떤 방식으로 암호화하는지 같은 기본 원칙이 없으면 서비스 운영 단계에서 보안과 개인정보 이슈로 바로 이어집니다. 개발정책이 꼼꼼할수록 개발 이후 운영 비용은 눈에 띄게 줄어듭니다. 즉 개발정책은 “개발을 위한 문서”이기도 하지만 동시에 “운영 비용을 낮추는 문서”이기도 합니다.

 

운영 정책: 고객 접점과 관리자 통제를 ‘현실적으로’ 굴리는 기준

운영정책은 서비스가 실제로 돌아가기 시작한 뒤, 사람과 프로세스가 흔들리지 않게 만드는 기준입니다. 운영정책은 크게 두 축으로 나뉩니다. 하나는 고객에게 직접 닿는 프론트 운영정책이고, 다른 하나는 관리자(백오피스) 중심의 운영정책입니다. 프론트 운영정책에는 고객 커뮤니케이션과 마케팅 메시지 정책이 포함됩니다. 예를 들어 푸시 알림을 발송할 때, 하루 몇 회까지 허용하는지, 어떤 이벤트에서 발송하는지, 야간 시간대는 제한할 것인지, 사용자에게 수신 거부 옵션을 어떤 방식으로 제공할 것인지 같은 기준이 필요합니다. 이런 기준이 없으면 운영자는 “이번엔 보내도 되겠지”라는 판단을 하게 되고, 결국 알림 과다로 사용자가 피로를 느끼고 앱을 삭제하거나 알림을 꺼버리는 결과가 생깁니다. 즉 운영정책은 ‘무엇을 한다’가 아니라 ‘어떤 수준과 기준으로 한다’를 정의하는 문서입니다.

반면 백오피스 운영정책은 내부 통제의 기준입니다. 관리자 권한을 어떻게 나눌지, 어떤 역할이 어떤 기능을 수행할 수 있는지, 게시판은 어떤 기준으로 관리하고 제재할지, 쿠폰 발행 조건과 유효기간은 어떻게 할지, 메인 노출 콘텐츠를 어떤 절차로 승인할지 같은 항목들이 여기에 포함됩니다. 이 기준이 없으면 운영자의 숙련도나 성향에 따라 운영 결과가 달라지고, 그 차이는 결국 서비스 신뢰도 하락으로 이어집니다. 운영정책은 “사람이 바뀌어도 운영이 유지되는 상태”를 만드는 문서라는 점에서, 서비스의 지속 가능성과 직결됩니다.

 

정책 수립의 ‘시점’은 화면보다 앞당길수록 유리해질 때가 많다

정책을 언제 정리해야 하느냐는 실무에서 늘 논쟁이 생깁니다. 일반적인 순서만 놓고 보면 IA → 서비스정책 → 개발정책 → 화면설계 → 운영정책 같은 흐름이 자연스럽습니다. 그런데 실무에서는 화면 설계가 논쟁의 중심이 되기 쉽고, 그 논쟁은 종종 방향성을 흐립니다. 그래서 오히려 “백오피스 설계와 기능 중심 정책을 먼저 정리하고, 화면은 병렬로 가자”라는 접근이 효율적일 때가 많습니다.

서비스정책과 개발정책이 먼저 정리되면, 개발자는 화면이 없어도 기능을 기준으로 개발을 시작할 수 있습니다. 동시에 디자이너는 “각 페이지에서 반드시 포함되어야 할 오브젝트와 기능 리스트”를 기반으로 컨셉 디자인을 빠르게 뽑아낼 수 있습니다. 화면을 먼저 그릴 때처럼 픽셀과 배치로 싸우지 않고, 기능의 중요도와 목적을 기반으로 디자인의 방향을 잡을 수 있게 됩니다. 결과적으로 개발과 디자인을 병렬로 돌릴 수 있고, 일정이 빨라집니다. 정책이 먼저 잡혀 있으면 화면은 그 정책의 결과로 자연스럽게 정렬됩니다. 반대로 정책이 비어 있는 상태에서 화면만 빨리 만들면, 화면은 나오는데 운영과 개발 기준은 뒤늦게 따라붙으며 반복 수정이 시작됩니다.

 

정책은 한 번에 완성되지 않지만, ‘빈틈의 누적’은 반드시 막아야 한다

정책을 다 완벽하게 쓰고 시작하는 것은 현실적으로 어렵습니다. 특히 초반에는 결정되지 않은 부분이 생기고, 시장과 고객 반응에 따라 바뀌어야 하는 부분도 있습니다. 그래서 정책을 수립할 때는 “빠르게 확정 가능한 영역부터 우선 정리하고, 확정이 어려운 영역은 여지를 남기되, 그 여지의 범위와 후속 결정 기준을 함께 남겨둔다”라는 방식이 실무적으로 유효합니다. 중요한 것은 ‘미뤄두는 것’ 자체가 아니라, 미뤄둔 항목이 팀의 기억 속에서 사라지지 않게 문서에 남아 있어야 한다는 점입니다. 그래야 시행착오가 반복되더라도 서비스가 흔들리지 않고, 정책이 점점 더 단단해지는 방향으로 고도화됩니다.

결국 정책은 “철저함”이 핵심입니다. 여기서 말하는 철저함은 모든 것을 처음부터 완벽하게 쓰라는 뜻이 아니라, 서비스가 운영되는 동안 기준이 흔들리지 않게 만드는 수준의 구조화입니다. 작은 빈틈은 당장은 문제가 없을 수 있지만, 누적되면 큰 문제로 돌아옵니다. 정책의 누수는 눈에 잘 안 보이지만, 일단 터지면 복구 비용이 커집니다. 그래서 정책은 귀찮고 머리 아프더라도, 서비스의 장기 안정성을 위해 반드시 ‘기획자가 책임지고’ 세워야 하는 뼈대입니다. 화면은 결국 결과물이고, 정책은 그 결과물이 흔들리지 않게 만드는 기준이라는 점을 놓치지 않는 것이 중요합니다.