엣지 케이스

기획서에는 잘 풀리는 경우만 적혀 있었습니다. "초대 링크를 누르면 팀에 합류한다" 한 줄이면 화면 하나가 설명된다고 여겼고, 그 한 줄로 만든 화면은 열에 아홉은 잘 돌아갔습니다. 문제는 나머지 하나였습니다. 링크를 받은 사람이 이미 그 팀의 구성원이면 어떻게 되는지, 링크를 만든 사람이 그새 퇴사해 계정이 사라졌으면 어떻게 되는지, 같은 링크를 두 사람이 동시에 누르면 어떻게 되는지는 아무 데도 적혀 있지 않았습니다.

적히지 않은 것은 없어지지 않고 개발자의 책상으로 넘어갑니다. 코드를 짜다 보면 반드시 그 자리에 닿고, 물어볼 사람이 없으면 혼자 정합니다. 어떤 화면은 조용히 넘기고, 어떤 화면은 오류 메시지를 띄우고, 어떤 화면은 두 번 처리해 버립니다. 같은 상황이 화면마다 다르게 처리되는 이유가 대개 이것입니다.

그러면 답은 고객 문의로 돌아옵니다. "초대를 눌렀더니 팀이 두 개 생겼어요" 라는 문의가 들어오고, 코드를 열어 보고 나서야 그 경우가 정해진 적이 없다는 사실을 확인합니다. 급히 정한 처리가 또 아무 데도 적히지 않으면 반년 뒤 같은 자리에서 같은 일이 되풀이됩니다.

엣지 케이스는 이 빈칸에 붙인 이름입니다. 이름이 생기면 회의에서 "엣지 케이스 정리했어요?" 라고 물을 수 있고, 물을 수 있으면 만들기 전에 채울 수 있습니다.

엣지 케이스는 정상 흐름을 한 단계씩 되짚으면서 각 단계에 극단값을 넣어 보는 방식으로 드러납니다. 영감이 필요한 작업이 아니라 훑는 방법이 정해져 있는 작업이고, 넣어 보는 값은 대개 세 가지 축에서 나옵니다.

1. 수량의 양 끝 — 0개일 때와 최대치일 때를 넣어 봅니다. 팀원이 한 명도 없는 팀의 대시보드는 무엇을 보여 주는지, 좌석을 여덟 자리로 줄이려는데 이미 아홉 명이 들어와 있으면 누가 나가는지가 여기서 나옵니다.
2. 시간의 경계 — 기준 시각에 딱 걸리는 순간을 넣어 봅니다. 결제일 당일에 해지를 누른 사람, 무료 체험 마지막 날 밤 11시 59분에 결제한 사람이 여기서 나옵니다.
3. 같은 일의 중복 — 한 번만 일어난다고 가정한 일을 두 번 일으켜 봅니다. 결제 버튼을 연달아 두 번 누르는 경우, 두 사람이 같은 문서를 동시에 지우는 경우가 여기 들어갑니다.

찾아낸 것을 전부 다룰 수는 없어서 거르는 기준이 필요합니다. 그대로 두면 돈이나 데이터가 어긋나는가, 겪은 사람이 고객센터에 연락할 만큼 곤란해지는가 둘을 봅니다. 하나라도 걸리면 드물어도 지금 정합니다.

여기서 비즈니스 규칙과의 관계가 드러납니다. 비즈니스 규칙은 업무상 반드시 지켜야 하는 조건입니다. "유료 좌석 수는 실제로 들어와 있는 인원보다 적을 수 없다" 같은 문장이고, 어기면 돈이 맞지 않습니다. 엣지 케이스는 그 조건이 흔들리는 지점입니다. 규칙을 먼저 세워 두면 어디를 들여다봐야 하는지가 저절로 보이고, 규칙 없이 경계만 찾으면 무엇이 문제인지 판단할 잣대가 없습니다.

이 말이 실제로 오가는 자리는 세 군데입니다. 무엇을 만들지 적을 때, 그것이 제대로 만들어졌는지 확인할 때, 그리고 벗어난 경우에 무엇을 할지 정할 때입니다.

1. 명세 문서 — 화면과 동작을 구현할 수 있을 만큼 적은 문서입니다. 정상 흐름을 적은 다음 "예외 상황" 이라는 칸을 따로 두고 찾아낸 경계를 한 줄씩 적습니다. 이 칸이 비어 있는 명세는 아직 절반만 쓴 것입니다.
2. 인수 조건 — 이 작업이 끝났다고 인정받기 위한 조건입니다. 엣지 케이스는 여기서 확인 항목으로 바뀝니다. "좌석을 인원보다 적게 줄이려 하면 저장이 막히고 안내 문구가 뜬다" 처럼 적어 두면 품질 보증 담당자가 그대로 눌러 보며 확인할 수 있습니다.
3. 예외 처리 정책 — 벗어난 상황에서 제품이 무엇을 할지 정한 방침입니다. 앞의 목록이 없으면 이 문서는 쓸 수 없습니다.

"이건 엣지 케이스라 이번 스프린트에서는 빼고 다음에 보겠습니다."

드문 상황이니 지금은 다루지 않겠다는 선언입니다. 없다는 뜻은 아니라서 어디에 적어 둘지를 함께 정해야 말이 됩니다.

"엣지 케이스 정리해서 주시면 그대로 테스트 케이스로 만들겠습니다."

찾아낸 경계 목록을 확인 항목으로 옮기겠다는 뜻입니다. 정리가 안 되어 있으면 테스트도 정상 흐름만 확인하게 됩니다.

"이거 엣지 케이스 아니에요. 전체 고객의 12퍼센트가 여기 들어갑니다."

드문 일로 분류한 판단 자체를 숫자로 뒤집는 말입니다.

페이지덱에서 좌석 수를 줄이는 기능을 만들 때 이 단어가 회의 내내 오갔습니다. 지현이 명세 초안을 열어 놓고 태오와 함께 흐름을 한 단계씩 짚었습니다. 숫자를 0으로 넣으면 어떻게 되는지, 이미 들어와 있는 인원보다 적게 넣으면 누구를 내보내는지, 줄이는 순간 다른 관리자가 새 구성원을 초대하고 있으면 어느 쪽이 이기는지를 적었습니다. 열두 개가 나왔고 그중 다섯 개는 돈 계산이 어긋나는 것이라 그 자리에서 처리 방침까지 정했습니다.

남은 일곱 개는 수아가 걸렀습니다. 고객 문의 기록을 뒤지니 두 건은 이미 요청이 들어온 적이 있었고, 나머지 다섯 개는 명세의 예외 상황 칸에 적어만 두고 이번에는 만들지 않기로 했습니다.

드무니까 나중에 해도 된다는 판단이 가장 흔합니다. 천 명 중 세 명이 겪는 일이라면 급하지 않아 보이고, 실제로 일정이 빠듯할 때 가장 먼저 잘리는 항목이기도 합니다. 그런데 겪은 세 명은 그냥 지나가지 않고 문의를 넣거나 결제를 멈춥니다. 한 달에 세 건이면 대응하는 시간과 그때마다 코드를 열어 보는 시간이 계속 쌓입니다. 만들 때 30분이면 끝났을 처리가 1년 동안 며칠치 일이 됩니다.

버그와 같은 말로 쓰는 경우도 자주 봅니다. 둘 다 예상 못 한 상황에서 튀어나오니 비슷해 보입니다. 하지만 버그는 정해 둔 대로 동작하지 않는 결함이고, 엣지 케이스는 애초에 정해 둔 적이 없는 상황입니다. 구분이 중요한 이유는 고치는 방법이 다르기 때문입니다. 버그는 코드를 고치면 끝나지만, 정해진 적 없는 상황은 코드를 고치기 전에 무엇이 맞는 동작인지부터 정해야 합니다. 섞어 두면 "고쳤습니다" 하고 닫은 항목이 아무도 합의하지 않은 동작인 채로 남습니다.