범위 밖

문서에 할 일만 적어 두면 안 하기로 한 것은 어디에도 남지 않습니다. 회의에서 누군가 "그건 이번엔 빼죠" 라고 말하고 모두 고개를 끄덕였어도 그 말은 회의가 끝나는 순간 사라집니다. 적힌 것은 하기로 한 목록뿐이니, 3주 뒤 같은 요청이 들어왔을 때 문서를 열어도 그 항목을 논의한 적이 있는지조차 알 수 없습니다.

페이지덱이 결제 화면에 쿠폰 입력칸을 붙일 때 실제로 그랬습니다. 첫 회의에서 코드를 자동으로 붙여 주는 기능은 이번에 만들지 않기로 정했는데, 문서에는 입력칸을 만든다는 줄만 적혔습니다. 2주 뒤 수아가 "고객이 자동 적용을 묻는데 언제 됩니까" 하고 물었고, 태오는 "그건 빼기로 한 것 같은데요" 라고 답했고, 아무도 확실히 기억하지 못해 회의를 다시 잡았습니다. 같은 결론에 다시 닿는 데 40분이 들었습니다.

한 문장이 이 자리를 막습니다. "코드 자동 적용은 이번에 하지 않습니다" 가 문서에 적혀 있으면 3주 뒤의 대화가 5분에 끝납니다. 범위 밖은 그 한 문장을 둘 자리입니다. 안 하는 것을 적는 칸이라 이상해 보이지만, 실무에서는 하기로 한 목록보다 이 칸이 더 자주 열립니다.

이번에 하지 않을 항목을 한 줄씩 적고, 줄마다 빼는 이유와 다시 볼 시점을 붙이는 방식으로 굴러갑니다. 이유와 시점이 없으면 그 줄은 거절 통보로 읽히고, 요청한 사람은 문서를 우회합니다.

한 줄에 세 가지가 들어갑니다.

1. 하지 않는 것 — 기능 이름만 적지 않고 어디까지 안 하는지를 함께 적습니다. "쿠폰 발급은 안 합니다" 는 관리자 화면이 없다는 뜻인지 발급 자체가 불가능하다는 뜻인지 갈리지 않습니다. 관리자용 발급 화면은 만들지 않고 발급은 운영팀이 직접 넣는다고 적으면 두 갈래가 닫힙니다.
2. 빼는 이유 — 일정이 모자라서인지, 수요가 확인되지 않아서인지, 기술 제약 때문인지를 적습니다. 이유마다 다시 볼 조건이 달라지기 때문입니다.
3. 다시 볼 시점 — 다음 분기라고 적어도 되고, 유료 팀 열 곳이 요청하면이라고 조건으로 적어도 됩니다. 이 칸이 비면 항목은 영구 거절로 굳습니다.

판정은 새 요청이 들어온 순간 이루어집니다. 그 요청이 범위 안인지, 범위 밖에 적혀 있는지, 어느 쪽에도 없는지를 먼저 확인합니다. 범위 밖에 있으면 문서를 고치는 결정을 거쳐야 하고, 그 한 단계가 일정 협의를 다시 열게 만듭니다. 어느 쪽에도 없으면 그때 판단하고 결과를 어느 칸이든 적어 둡니다.

이 한 단계가 막는 것이 스코프 크리프입니다. 합의 없이 범위가 슬금슬금 늘어나는 현상인데, 매번 "이건 작으니까" 라는 말과 함께 붙기 때문에 어느 시점에 무엇이 늘었는지 아무도 짚지 못합니다. 2주로 잡았던 일이 6주가 되는 과정에 한 번에 4주가 늘어난 날은 없습니다.

가장 자주 쓰이는 자리는 PRD 의 한 칸입니다. 제품이 해야 하는 동작을 적는 기능 요구사항 칸 바로 뒤에 놓여, 어디까지가 이번 것인지를 반대쪽에서 못 박습니다. 성능이나 보안 조건을 적는 비기능 요구사항에도 같은 칸이 필요합니다. 초당 100건까지만 견디게 만들고 그 위는 이번에 보지 않는다고 적는 식입니다.

나머지 세 자리는 이렇습니다.

1. 일정을 추정하는 자리 — 같은 일을 두고 2주와 6주가 나오는 이유는 대개 두 사람이 서로 다른 범위를 그리고 있기 때문입니다. 범위 밖 세 줄을 함께 읽으면 두 숫자가 붙습니다.
2. 고객에게 말하는 자리 — 세일즈와 고객 성공은 이 칸을 먼저 엽니다. 아직 없는 기능을 약속하면 계약 뒤에 그 약속을 지우는 일이 남고, 그 일은 약속한 사람에게 돌아옵니다.
3. 다음 회차를 준비하는 자리 — 여기 적힌 줄은 사라지지 않고 제품 백로그로 넘어갑니다. 백로그는 앞으로 만들 후보를 우선순위대로 모아 둔 목록입니다.

예외 규칙이 많아 한 줄로 안 되는 항목은 제품 정책으로 보냅니다. 제품 정책은 어떤 상황에서 제품이 어떻게 굴어야 하는지를 예외까지 못 박아 둔 문서입니다. 쿠폰 하나에도 중복 사용과 부분 취소 같은 규칙이 스무 줄쯤 붙고, 그중 이번에 다루지 않을 조합만 범위 밖에 한 줄로 적습니다.

"그건 이번 범위 밖입니다. 하려면 문서를 고치고 일정을 다시 잡아야 합니다."

요청을 거절한 것이 아니라 일정 협의를 다시 열자는 제안입니다.

"범위 밖에 한 줄만 넣어 주세요. 안 한다고 적혀 있어야 고객한테 말할 수 있어요."

문서에 없는 항목은 대외적으로 없다고 말하기 어렵다는 요청입니다.

"이거 범위 안인가요 밖인가요. 둘 다에 안 적혀 있는데요."

판단이 아직 안 된 항목이니 지금 정해 어느 칸이든 적어 두자는 지적입니다.

페이지덱의 쿠폰 작업에서 이 칸을 채운 사람은 지현입니다. 초안에는 관리자용 발급 화면과 코드 자동 적용 두 줄이 있었습니다. 사흘 뒤 수아가 기업 고객 계약에 이미 다른 할인이 걸려 있다고 댓글을 남겼고, 지현은 그 계약과 쿠폰을 함께 쓰는 경우를 세 번째 줄로 추가했습니다.

한 달 뒤 세 줄이 각각 다른 일을 했습니다. 첫 줄은 운영팀의 발급 요청을 백로그로 보냈고, 둘째 줄은 수아가 고객에게 답할 말이 됐고, 셋째 줄은 태오가 예외 처리를 건너뛰게 해 줬습니다.

가장 흔한 오해는 이 칸을 영구 거절 목록으로 읽는 것입니다. 안 한다고 적혀 있으니 자연스러운 오해입니다. 실제로는 이번 회차에 한정된 결정이라서, 다음 분기에 같은 항목이 범위 안으로 옮겨 가는 일이 흔합니다. 영구 거절로 굳으면 사람들이 자기 요청이 이 칸에 적히는 것을 피하고, 결정은 다시 문서 밖 개별 대화로 돌아갑니다.

범위만 잘 적으면 이 칸은 없어도 된다고 보는 것도 흔합니다. 안 할 것은 무한히 많으니 적는 의미가 없어 보이기 때문입니다. 그런데 읽는 사람은 적히지 않은 자리를 각자 상상으로 채웁니다. 쿠폰 입력칸을 만든다는 줄만 있으면 세일즈는 발급 화면도 포함됐다고 읽고 개발은 아니라고 읽습니다. 무한한 목록을 다 적을 필요는 없습니다. 이번 논의에 올랐던 항목 세 줄이면 대개 충분합니다.