비즈니스 규칙

제품이 작을 때는 규칙이 사람 머릿속에 있습니다. 쿠폰을 두 개 쓸 수 있느냐고 물으면 만든 사람이 안 된다고 답하고 끝납니다. 사람이 늘고 기능이 늘면 이 방식이 깨집니다.

깨지는 모습은 같은 질문이 서로 다른 답을 받는 것으로 나타납니다. 고객이 쿠폰 두 장을 함께 쓸 수 있느냐고 묻자 고객 지원은 안 된다고 답했는데, 같은 주에 영업은 큰 계약을 따려고 된다고 말합니다. 개발자는 코드를 열어 보고 "지금은 되게 돼 있다" 고 합니다. 셋 다 거짓말이 아니라, 정해 둔 것이 없으니 각자 아는 것을 말한 겁니다.

정해진 것이 없으면 결국 코드가 규칙이 됩니다. 문제는 코드가 규칙을 적어 둔 문서가 아니라는 점입니다. 3년 전에 급하게 넣은 조건이 왜 거기 있는지 아무도 모르는 채로 계속 돌고, 한 주문에 쿠폰이 두 장 들어가 원가보다 싸게 팔려 나가도 그건 버그가 아니라 아무도 정하지 않은 결과입니다.

비즈니스 규칙은 이 조건들을 코드 밖으로 꺼내 문장으로 세워 둔 것입니다. 기술 문서가 아니라 업무 영역의 제약이라는 점이 성격의 전부입니다. 협상이나 취향의 대상이 아니고, 어기면 돈이 맞지 않거나 계약을 위반하게 되는 것들만 들어갑니다.

규칙 한 줄을 남이 읽고 그대로 실행할 수 있게 적으려면 다섯 칸이 필요합니다.

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

규칙을 세우고 나면 그것이 흔들리는 경계 상황을 찾는 일이 따라옵니다. 좌석을 여덟 자리로 줄이려는데 이미 아홉 명이 초대돼 있는 경우가 그런 자리이고, 이런 것을 엣지 케이스라고 부릅니다. 그 상황에서 무엇을 할지 단계와 시한까지 정한 것이 예외 처리 정책입니다.

쓰는 사람은 제품을 맡은 사람입니다. 페이지덱에서는 지현이 씁니다. 다만 혼자 정하지 않고 답을 가진 쪽에서 받아 옵니다. 환불 조건은 재무가, 계약 고객 예외는 세일즈가, 데이터 보관 기간은 법무가 답을 갖고 있고, 제품 담당은 그 답들을 서로 어긋나지 않는 한 벌의 문장으로 정리합니다.

읽는 사람은 넷이고 각자 다른 칸을 봅니다.

1. 개발자는 2번 칸을 그대로 코드로 옮깁니다. 조건이 한 줄에 하나씩 정리돼 있어야 옮기면서 해석이 끼어들지 않습니다.
2. 품질 담당은 2번과 3번 칸으로 시험 항목을 만듭니다. 규칙이 표로 있으면 행마다 시험 한 건이 나옵니다.
3. 고객 지원은 1번과 4번 칸을 봅니다. 왜 나는 안 되느냐는 물음에 답할 근거가 거기 있습니다.
4. 디자이너는 2번 칸에서 화면에 무엇을 막아야 하는지를 가져갑니다. 누를 수는 있는데 눌러 보면 안 된다고 하는 화면은 이 칸을 안 보고 만든 것입니다.

고객에게 약속의 형태로 내보내야 하는 규칙은 이용약관으로 옮겨 갑니다. 환불 조건이나 데이터 보관 기간이 그렇습니다. 같은 사실을 다른 독자에게 쓴 문서라, 한쪽만 고치면 제품 동작과 대외 약속이 어긋납니다.

"이건 비즈니스 규칙이라 예외를 못 둡니다. 계약 조건을 바꾸셔야 해요."

제품 설정으로 풀 수 있는 문제가 아니라는 뜻입니다.

"그 조건 어디에 적혀 있어요? 코드에만 있으면 규칙이 아니라 구현입니다."

문서로 합의된 것과 그냥 그렇게 짜인 것을 구분하자는 지적입니다.

"쿠폰과 계약 할인이 같이 들어오면 뭐가 이기는지 정해진 게 없네요."

3번 칸이 비어 있어 개발자가 그 자리에서 정하게 된다는 경고입니다.

이 문서가 페이지덱에서 처음 필요해진 것은 좌석 단위 요금제를 붙인 뒤였습니다. 좌석당 월 9,000원을 받는데 관리자가 좌석을 스무 자리에서 여덟 자리로 줄이려 했고, 이미 초대된 사람은 아홉이었습니다. 태오가 어떻게 처리하느냐고 물었는데 답이 나오지 않았습니다. 초대를 먼저 해제하라고 막을지, 초과 인원을 읽기 전용으로 돌릴지, 그냥 허용하고 다음 청구 때 맞출지가 전부 가능했기 때문입니다.

지현이 그날 적은 것은 한 줄이었습니다. 유료 좌석 수는 초대된 인원보다 적을 수 없고, 줄이려면 초대를 먼저 해제해야 한다. 그 뒤로 같은 질문이 세 번 더 왔지만 답하는 데는 매번 1분이 걸렸습니다.

개발 스펙의 일부로 보는 경우가 많습니다. 결국 코드로 구현되는 조건이니 요구사항 문서 안에 적으면 된다고 생각하기 쉽습니다. 하지만 이 조건들은 제품을 만들기 전부터 그 업무 영역에 있던 것입니다. 쿠폰을 하나만 쓰게 하는 것은 기능 설계가 아니라 그러지 않으면 돈이 맞지 않기 때문입니다. PRD 안에만 두면 그 기능을 만들 때 한 번 읽히고 끝나서, 6개월 뒤 다른 기능이 같은 조건을 건드릴 때 아무도 못 찾습니다.

한 번 정하면 바뀌지 않는다고 보는 것도 흔한 오해입니다. 반드시 지켜야 하는 조건이라는 말이 고정불변으로 들리기 때문입니다. 실제로는 요금제가 바뀌거나 새 나라에 진출하면 규칙도 바뀝니다. 그래서 5번 칸이 있고, 비어 있으면 반년 뒤에 아무도 지금 문장이 최신인지 확신하지 못합니다.