예외 처리 정책

기획서에 적히는 것은 대개 잘 풀리는 경우입니다. 카드가 승인되고 초대가 수락되고 파일이 올라가는 흐름은 화면 단위로 꼼꼼히 그려지지만, 그 흐름이 끊겼을 때 무엇을 할지는 비어 있는 채로 개발에 넘어갔습니다.

그래서 같은 장면이 되풀이됐습니다. 태오가 결제 기능을 짜다가 카드 승인이 거절되는 갈래를 만나 지현에게 묻습니다. 회의 중이라 답이 늦고 마감은 그날이라 태오가 그 자리에서 정합니다. 한 번 더 시도하고 안 되면 계정을 잠급니다. 같은 주에 쿠폰 쪽을 맡은 사람도 비슷한 상황을 만나 다르게 정합니다. 다섯 번 시도하고 그대로 통과시킵니다. 둘 다 그럴듯하지만 한 제품 안에서 같은 성격의 사고가 다르게 처리됩니다.

값은 그다음에 치릅니다. 고객이 수아에게 전화해 결제가 안 됐다는데 그동안 쌓아 둔 문서는 어떻게 되느냐고 묻습니다. 답이 문서에 없으니 수아는 태오에게 묻고, 태오는 코드를 열어 확인한 뒤에야 답합니다. 제품이 실제로 무엇을 하는지 아는 사람이 그 코드를 쓴 한 명뿐인 상태입니다.

예외 처리 정책은 이 답을 코드보다 먼저 정해 두려고 생긴 문서입니다. 비즈니스 규칙, 곧 업무상 어겨서는 안 되는 조건이 먼저 서고, 엣지 케이스가 그 조건이 흔들리는 경계 상황을 찾아내면, 상황마다 무엇을 할지 답하는 자리가 여기입니다.

예외 하나를 다루는 데 필요한 칸은 여섯입니다. 카드 결제 실패를 예로 들면 이렇게 채워집니다.

1. 발생 조건 — 무엇을 예외로 볼지 기계가 판정할 수 있게 적습니다. "결제가 안 되면" 이 아니라 "정기 결제 요청에 카드사가 승인 거절을 반환하면" 처럼 씁니다. 사람이 읽고 해석해야 하는 조건은 개발자마다 다르게 옮겨집니다.
2. 즉시 동작 — 그 순간 제품이 하는 일입니다. 첫 실패에는 구독을 끊지 않고 상태만 결제 지연으로 바꾸며 기능은 그대로 열어 둡니다.
3. 재시도와 시한 — 몇 번, 며칠 간격으로 다시 시도할지 적습니다. 사흘 간격 세 번이면 아홉째 날에 마지막 시도가 끝납니다.
4. 고지 — 누구에게 언제 무엇으로 알릴지입니다. 첫 실패에 결제 담당자 메일, 두 번째에 관리자까지, 세 번째에 제품 안 배너. 받는 사람에게 결제 수단을 바꿀 권한이 없으면 알림은 가도 처리되지 않습니다.
5. 최종 상태 — 끝내 해결되지 않았을 때 계정이 놓이는 자리입니다. 읽기 전용으로 30일, 그 뒤 데이터 보관 종료. 이 칸은 이용약관에 적힌 약속과 맞물리므로 문구를 임의로 정하지 않습니다.
6. 수동 개입 경로 — 정책 밖으로 나가야 할 때 누가 무엇을 할 수 있는지입니다. 기업 고객이 세금계산서 절차 때문에 늦는 경우처럼 예외의 예외가 생깁니다. 지원 담당이 30일을 60일로 늘릴 수 있는지, 그러려면 누구 승인이 필요한지를 적어 둡니다.

여섯 칸 가운데 가장 자주 비는 것은 3번입니다. "실패하면 다시 시도한다" 까지만 적힌 문서가 흔한데, 그러면 횟수와 간격은 코드를 짜는 사람이 정하게 되고 고객에게 언제 알릴지도 함께 사라집니다. 왜 사흘 간격 세 번으로 정했는지까지 남겨야 하면 의사결정 기록을 따로 두고 여기에는 결정만 적습니다.

초안은 그 기능을 맡은 제품 담당자가 잡습니다. 개발이 쓰면 지금 구현하기 쉬운 쪽으로 기울고, 지원이 쓰면 이미 들어온 문의만 덮습니다. 전체 흐름을 알고 결정 권한도 있는 쪽이 먼저 쓰고 나머지가 검토하는 편이 어긋남이 적습니다.

검토는 세 방향에서 받습니다. 개발은 발생 조건이 기계가 판정할 수 있는 형태인지, 지원은 고객에게 그대로 읽어 줄 수 있는 문장인지, 법무는 최종 상태가 약관과 어긋나지 않는지 봅니다.

읽는 사람은 셋이고 읽는 시점이 다릅니다.

1. 개발자 — 코드를 짜기 전에 읽습니다. 조건과 시한이 숫자로 적혀 있으면 그대로 옮기면 되고, 비어 있으면 그 자리에서 지어내게 됩니다.
2. 지원 담당 — 문의가 들어온 순간 읽습니다. 수아가 "지금 읽기 전용 상태이고 27일 남았습니다" 라고 바로 답할 수 있으려면 문서에 그 숫자가 있어야 합니다.
3. 디자이너 — 화면 문구와 그 자리에서 누를 수 있는 버튼을 정할 때 읽습니다. 민서가 결제 지연 배너를 그리려면 며칠 뒤 무슨 일이 생기는지를 알아야 문장이 나옵니다.

셋이 같은 문서를 읽으니 한 벌만 두고 찾기 쉬운 자리에 둡니다.

"이 케이스는 예외 처리 정책에 없는데요. 세 번 다 실패하면 좌석은 어떻게 되죠?"

문서에 답이 없으니 개발을 더 진행하지 않겠다는 뜻입니다.

"정책 먼저 정하고 개발 들어갈게요. 지금 넘기면 배너 문구를 제가 지어내야 해요."

빈 칸이 결국 화면 문구를 정하는 사람에게 떠넘겨진다는 말입니다.

"정책상 읽기 전용으로 30일이고 그 뒤 삭제입니다. 고객에게 그대로 안내드렸어요."

담당자가 확인 절차 없이 바로 답할 수 있었다는 뜻입니다.

페이지덱에서 이 문서가 생긴 계기는 좌석 축소였습니다. 좌석을 여덟으로 줄이려는데 이미 아홉 명이 초대된 계정이 나왔고, 제품은 아무 말 없이 마지막에 초대된 사람을 잘라 냈습니다. 그 사람이 쓰던 문서를 며칠 뒤 못 열게 되자 문의가 들어왔습니다. 지현이 비슷한 상황을 모아 보니 열한 가지였고, 그중 아홉 가지는 정한 기록 없이 제품이 알아서 처리하고 있었습니다.

예외 처리 정책을 에러 메시지 문구 모음으로 여기는 경우가 가장 많습니다. 눈에 보이는 결과물이 화면에 뜨는 문장이라 그렇게 읽힙니다. 하지만 문구는 여섯 칸 가운데 고지 한 칸의 일부일 뿐이고, 정작 합의가 필요한 것은 며칠 뒤 계정이 어떤 상태가 되느냐입니다. 문구만 정리해 두면 "결제에 실패했습니다" 라는 친절한 문장 뒤에서 계정이 언제 잠기는지는 여전히 아무도 모릅니다.

나중에 정해도 되는 문서로 미루는 것도 흔합니다. 예외는 드물게 일어나니 급하지 않아 보입니다. 그런데 드문 것은 각 상황의 빈도이지 예외 전체의 빈도가 아닙니다. 천 건에 세 건씩 일어나는 상황이 열 가지면 한 달에 수십 건이 되고, 그 수십 건은 전부 사람이 손으로 처리하게 됩니다. 정책 없이 반년을 보낸 제품은 코드를 읽어야만 동작을 알 수 있게 되고, 그때는 문서를 쓰기 전에 이미 나간 동작을 조사하는 일부터 해야 합니다.