제품 정책

만들 기능이 정해지고 나면 곧바로 다른 종류의 질문이 따라붙습니다. 만들기로 한 동작이 정상적으로 흘러가지 않는 경우에는 무엇을 보여 줄지, 두 규칙이 동시에 걸리면 어느 쪽이 이기는지, 이미 그 기능을 쓰고 있던 사람에게는 어떻게 적용할지 같은 것들입니다. 기능 하나를 붙일 때마다 이런 질문이 스무 개씩 생기는데, 이 질문들은 만들 것을 정하는 회의의 의제로 잘 올라오지 않습니다. 화면에 보이지 않고, 대부분 드물게 일어나는 일이기 때문입니다.

페이지덱이 유료 플랜의 좌석 수를 줄일 수 있게 만들 때 그 일이 실제로 벌어졌습니다. 열두 자리를 쓰던 팀이 여덟 자리로 줄이면 이미 낸 돈은 어떻게 되는지 아무 데도 적혀 있지 않았습니다. 태오는 남은 기간만큼 다음 결제에서 빼 주는 쪽이 자연스럽다고 보고 그렇게 만들었고, 수아는 고객에게 다음 갱신일부터 새 요금이 적용된다고 설명했고, 문의를 받은 지원 담당자는 차액을 환불해 주겠다고 답했습니다. 같은 질문에 세 개의 답이 나갔고, 셋 다 회사의 공식 입장으로 고객에게 전달됐습니다.

세 답이 부딪히는 데는 오래 걸리지 않았습니다. 한 고객이 지원팀 안내를 믿고 환불을 기다렸는데 통장에는 아무것도 들어오지 않았고, 대신 다음 달 청구서가 조금 줄어 있었습니다. 그 고객이 다시 문의를 넣으면서 앞선 안내 메일을 그대로 붙여 왔고, 그때부터는 무엇이 맞는지를 정하는 일이 아니라 이미 나간 말을 어떻게 수습할지를 정하는 일이 됐습니다.

문제는 누가 틀렸는지가 아니라 답이 어디에도 없었다는 데 있습니다. PRD는 이번에 무엇을 왜 어디까지 만들지를 적는 문서라 이런 규칙을 다 담기에는 자리가 좁고, 화면과 동작을 구현할 수 있을 만큼 적는 명세 문서는 이번에 만드는 화면 바깥의 일을 다루지 않습니다. 게다가 이 규칙들은 기능보다 훨씬 오래 삽니다. 좌석 축소 화면은 한 번 만들면 끝이지만 좌석을 줄였을 때 돈을 어떻게 처리하는가는 그 뒤로 몇 년 동안 매주 누군가가 묻습니다.

제품 정책은 그 규칙만 따로 떼어 한곳에 적어 두자는 제안입니다. 기능 단위가 아니라 규칙 단위로 묶고, 정상 경로보다 정상이 아닌 경로에 더 많은 줄을 씁니다.

제품 정책 아래 묶인 용어는 한 갈래, 문서를 이루는 구성 요소뿐입니다. 셋은 규칙이 만들어지는 순서대로 이어집니다. 먼저 어겨서는 안 되는 조건을 세우고, 그 조건이 흔들리는 경계 상황을 찾아내고, 그 상황에서 무엇을 할지 정합니다. 순서를 건너뛰면 대개 세 번째부터 시작하게 되는데, 그러면 눈앞에 닥친 상황 하나씩만 막다가 서로 어긋나는 처리 방침이 쌓입니다.

1. 비즈니스 규칙 — 제품이 다루는 업무 영역에서 반드시 지켜야 하는 조건입니다. "한 주문에 쿠폰은 하나만 적용된다", "유료 좌석 수는 실제로 초대된 인원보다 적을 수 없다" 처럼 씁니다. 협상이나 취향의 대상이 아니라는 점에서 다른 둘과 성격이 다릅니다. 어기면 돈이 맞지 않거나 계약을 위반하게 되므로, 기술적으로 가능하더라도 막아야 하는 것들입니다.
2. 엣지 케이스 — 드물게 일어나지만 정의해 두지 않으면 곤란해지는 경계 상황입니다. 좌석을 여덟 자리로 줄이려는데 이미 아홉 명이 초대돼 있는 경우, 결제일 당일에 해지를 누르는 경우, 쿠폰을 쓴 주문을 부분 환불하는 경우가 여기 들어갑니다. 천 건에 세 건쯤 나오는 일이라 테스트에서도 잘 걸리지 않고, 실제 고객에게서 먼저 발견되는 경우가 많습니다. 찾는 방법은 정상 흐름을 한 단계씩 짚으면서 각 단계마다 수량이 0이거나 최대치인 경우, 시간이 경계에 걸리는 경우, 같은 일이 동시에 두 번 일어나는 경우를 넣어 보는 것입니다.
3. 예외 처리 정책 — 정상 흐름을 벗어났을 때 제품이 무엇을 할지 정한 방침입니다. 카드 결제가 실패하면 사흘 간격으로 세 번 다시 시도하고, 그래도 안 되면 계정을 읽기 전용으로 바꾸고, 그 상태로 30일이 지나면 데이터 보관을 끝낸다는 식으로 단계와 시한을 함께 적습니다. 엣지 케이스가 질문이라면 이쪽은 답입니다. 시한이 빠진 방침은 방침 구실을 하지 못합니다. "결제가 실패하면 다시 시도한다" 까지만 적혀 있으면 몇 번을 언제까지 시도할지는 결국 코드를 짜는 사람이 정하게 되고, 고객에게 언제 알릴지도 함께 사라집니다.

이 셋을 찾아냈다면 그다음은 남이 읽고 그대로 실행할 수 있는 형태로 적는 일입니다. 정책 문서 한 건을 열면 아래 다섯 칸이 채워져 있어야 합니다.

1. 적용 범위 — 이 규칙이 어디까지 적용되는지 적습니다. 무료 플랜에도 걸리는지, 기업 계약 고객은 예외인지, 특정 국가에서만 다른지를 먼저 좁혀 두지 않으면 아래 내용이 전부 애매해집니다. 한 문장이면 충분합니다. "유료 팀 플랜을 월 단위로 결제하는 고객에게 적용한다" 정도로 적고, 여기 들지 않는 경우는 아예 다른 문서로 뺍니다.
2. 조건과 결과 — 규칙 본문입니다. "좌석 수를 줄이면" 처럼 조건을 왼쪽에, "남은 기간의 차액을 다음 청구서에서 뺀다" 처럼 결과를 오른쪽에 두고 표로 늘어놓습니다. 조건은 한 줄에 하나씩만 담아야 나중에 한 줄만 고칠 수 있습니다. "좌석을 줄이고 남은 기간이 15일 미만이면" 처럼 조건 두 개를 한 줄에 묶어 두면, 기간 기준을 7일로 바꾸는 순간 좌석 규칙까지 함께 흔들립니다.
3. 우선순위 — 규칙 둘이 동시에 걸릴 때 어느 쪽이 이기는지 적습니다. 기업 계약서에 별도 할인이 적혀 있고 쿠폰도 들어왔다면 무엇이 먼저인지를 정해 두지 않으면 개발자가 그 자리에서 정하게 됩니다. 계약이 이긴다고 한 줄 적어 두면 그 뒤로는 같은 조합이 몇 개 더 생겨도 판단이 갈리지 않습니다.
4. 발효 시점과 소급 여부 — 언제부터 적용하는지, 이미 그 상태에 있던 사용자에게도 적용하는지를 적습니다. 정책을 바꿀 때 가장 많이 빠지는 칸이고, 빠지면 어제 결제한 사람과 오늘 결제한 사람이 다른 대접을 받습니다. 기준은 대개 둘 중 하나입니다. 새 규칙을 모두에게 적용하고 손해 보는 쪽만 개별로 보상하거나, 기존 사용자는 다음 갱신일까지 옛 규칙을 그대로 두는 것입니다.
5. 변경 이력 — 언제 무엇을 왜 바꿨는지 한 줄씩 쌓습니다. 왜 그렇게 정했는지까지 길게 남겨야 한다면 의사결정 기록을 따로 두고 여기서는 날짜와 링크만 겁니다.

이렇게 적어 둔 규칙 가운데 고객에게 약속의 형태로 내보내야 하는 것은 이용약관으로 옮겨 갑니다. 환불 조건이나 데이터 보관 기간처럼 지키지 않으면 분쟁이 되는 항목이 그렇습니다. 둘은 같은 사실을 다른 독자에게 쓰는 문서이고, 한쪽만 고치면 제품 동작과 약속이 어긋납니다.

"이건 정책이 없어서 일단 제 판단으로 막아 뒀는데, 정해 주시면 바꾸겠습니다."

만들다가 규칙이 필요해졌는데 문서에 없어 임시로 정했다는 고백이자, 그 결정을 원래 정해야 할 사람에게 돌려주겠다는 말입니다.

"고객사에서 좌석 줄이면 환불되냐고 묻는데, 정책 문서 어디를 보면 되나요?"

고객 앞에서 답하기 전에 근거를 문서에서 확인하겠다는 뜻이고, 답이 거기 없으면 그 자리에서 규칙이 하나 더 만들어집니다.

"그건 이번 범위 밖으로 잡죠. 대신 그 상황에서 무슨 화면이 뜨는지는 정해 둡시다."

지금 만들지는 않지만 그 상황은 실제로 일어나므로 동작만이라도 정의해 두자는 제안입니다.

페이지덱에서 좌석 축소 기능을 다시 손보기로 한 주에 이 문서가 처음 만들어졌습니다. 지현이 지금까지 나간 답변 세 가지를 나란히 적어 놓고, 어느 쪽으로 정할지를 두 시간짜리 회의 하나로 끝냈습니다. 태오는 남은 기간을 계산하는 방식이 셋 중 어느 쪽이 구현 가능한지를 말하고, 수아는 이미 다른 설명을 들은 고객이 열 곳쯤 있다는 사실을 올리고, 규원은 차액을 현금으로 돌려주면 매출을 잡는 방식이 달라진다는 점을 짚습니다.

결론은 다음 청구서에서 빼 주는 쪽이었습니다. 지현은 그 한 줄과 함께 이미 다른 안내를 받은 고객 열 곳은 그대로 처리한다는 소급 예외를 적고, 발효일을 2주 뒤로 잡았습니다. 그 뒤로 같은 질문이 들어오면 세 사람 모두 같은 문서를 열어 같은 줄을 읽습니다. 규칙이 옳아서가 아니라 하나뿐이어서 생기는 효과입니다.

문서가 생긴 뒤에 달라진 것이 하나 더 있습니다. 비슷한 질문이 새로 나올 때 회의를 여는 대신 문서에 줄을 하나 추가하는 것으로 끝난다는 점입니다. 석 달 뒤 연간 결제 고객이 중간에 좌석을 줄이면 어떻게 되느냐는 문의가 들어왔을 때, 지현은 기존 규칙 아래에 연간 결제는 다음 갱신일에 좌석 수를 맞춘다는 한 줄을 붙이고 태오에게 알렸습니다. 처음 두 시간이 걸린 자리가 두 번째부터는 10분짜리가 됩니다.

가장 흔한 오해는 정책을 만드는 쪽의 세부 사항으로 보는 것입니다. 화면에 드러나지 않고 대부분 드문 상황을 다루니 개발자가 적당히 정하면 되는 영역처럼 보입니다. 하지만 좌석을 줄였을 때 차액을 돌려주느냐 다음 청구서에서 빼느냐는 구현 방식의 문제가 아니라 회사가 매출을 잡는 방식과 고객에게 한 약속이 달라지는 문제입니다. 결정을 넘겨 두면 그 규칙들은 코드 곳곳에 흩어진 조건문으로만 남고, 반년 뒤 고객이 항의했을 때 왜 그렇게 동작하는지 설명할 수 있는 사람이 회사에 없습니다. 규칙을 되찾으려면 코드를 읽어 거꾸로 복원해야 하는데, 그 작업은 대개 새로 정하는 것보다 오래 걸립니다. 코드에는 무엇을 하는지만 적혀 있고 왜 그렇게 정했는지는 남아 있지 않기 때문에, 복원한 규칙이 의도였는지 실수였는지조차 가려내지 못합니다.

두 번째는 출시 전까지만 쓰는 문서로 보는 것입니다. 개발 착수 자료와 함께 묶여 전달되니 개발이 끝나면 역할도 끝난 것처럼 읽힙니다. 실제로는 출시 뒤에 훨씬 자주 열립니다. 지원 담당자가 답변을 쓸 때, 세일즈가 계약서에 조건을 넣을 때, 법무가 약관 문구를 고칠 때 모두 이 문서를 근거로 삼습니다. 관리하지 않고 두면 문서는 출시 시점에 멈춰 있고 제품 동작만 계속 바뀝니다. 둘이 어긋난 채로 고객센터가 옛 규칙대로 답하면 그 답이 새로운 약속이 되고, 회사는 문서에도 코드에도 없는 규칙을 지키게 됩니다. 이런 규칙은 한번 생기면 지우기가 어렵습니다. 이미 그 답을 받은 고객이 있으니 되돌리는 순간 말을 바꾼 쪽이 되기 때문입니다.