기능 요구사항

요구를 뭉뚱그려 적던 시절이 있었습니다. "결제 화면에 쿠폰 기능 넣어 주세요" 한 줄이 문서의 전부였고, 나머지는 만드는 사람이 알아서 채웠습니다. 짧게 적는 쪽이 빨라 보이지만, 적지 않은 것은 사라지지 않고 누군가 나중에 혼자 정하게 됩니다.

그래서 착수 회의가 늘 같은 모양으로 흘러갔습니다. 태오가 "쿠폰 코드가 틀리면 어떻게 하나요" 라고 물으면 지현이 그 자리에서 생각해 답하고, "이미 쓴 코드면요" 라고 다시 물으면 또 그 자리에서 답합니다. 열 개쯤 되는 질문이 열 번의 즉석 결정이 되고, 그중 절반은 회의록에 남지 않습니다. 두 주 뒤 검수에서 "만료된 쿠폰을 넣었는데 아무 일도 안 일어나는데요" 라는 말이 나오면 아무도 그때 무엇을 정했는지 대지 못합니다.

한 줄짜리 요구는 읽는 사람마다 다른 그림을 그리게 합니다. 한쪽은 붉은 글씨가 뜨는 화면을 떠올리고, 다른 쪽은 입력칸 아래 안내 문구를 떠올리고, 적은 사람은 틀린 코드가 들어올 일을 생각하지 않았습니다.

기능 요구사항은 그 어긋남을 만들기 전에 드러내려고 쓰는 항목입니다. 무엇을 할지 한 줄로 적는 대신, 어떤 조건에서 무엇이 일어나는지를 경우마다 한 문장씩 적습니다. 문장 수가 늘어나는 만큼 회의에서 나올 질문이 줄어듭니다.

한 항목은 주어와 조건과 동작과 결과가 들어간 문장 하나입니다. "사용자가 결제 화면에서 쿠폰 코드를 입력하면 할인 금액이 즉시 표시된다" 가 기본형이고, 여기서 하나라도 빠지면 읽는 사람이 채워 넣습니다.

문장 하나에 붙는 자리는 다섯입니다.

1. 주어 — 누가 하는 동작인지 적습니다. 사용자인지, 관리자인지, 시스템이 스스로 하는 일인지에 따라 만들어야 할 화면이 달라집니다. "쿠폰이 만료된다" 는 주어가 없어서 만료를 사람이 누르는지 시간이 지나면 저절로 되는지 알 수 없습니다.
2. 조건 — 언제 그 동작이 일어나는지입니다. 결제 화면에서인지 장바구니에서인지가 여기 들어갑니다.
3. 동작과 결과 — 무엇을 하면 무엇이 보이는지를 짝으로 적습니다. 결과가 화면에 보이는 것이 아니라 데이터만 바뀌는 경우에도 그 사실을 적습니다.
4. 예외 경로 — 정상이 아닌 경우를 경우마다 한 줄씩 붙입니다. 코드가 틀렸을 때, 이미 쓴 코드일 때, 유효 기간이 지났을 때, 최소 결제 금액에 못 미칠 때 각각 무엇을 보여 줄지를 적습니다. 여기서 다루는 드문 상황을 엣지 케이스라고 부르고, 실무에서 되묻는 질문의 대부분이 이 자리에서 나옵니다.
5. 인수 조건 — 이 항목이 끝났다고 인정받기 위한 조건입니다. 체크할 수 있는 문장으로 적어야 검수하는 사람이 목록을 그대로 따라가며 확인할 수 있습니다.

항목이 열 개를 넘어가면 번호와 우선순위를 함께 답니다. 반드시 있어야 하는 것과 있으면 좋은 것을 나눠 두면 일정이 밀릴 때 무엇을 미룰지 다시 회의하지 않아도 되고, 번호가 있으면 검수에서 세 번째 항목이라고 부르는 것만으로 서로 같은 문장을 보게 됩니다.

쓰는 쪽은 대개 그 기능을 맡은 프로덕트 매니저 한 사람입니다. 무엇을 왜 만들지 정하고 출시까지 책임지는 역할이라, 경우를 나누는 결정도 이 사람이 합니다. 다만 혼자 앉아서 쓰지는 않습니다. 예외 경로는 만들어 본 사람이 더 잘 알기 때문에 초안을 돌리고 개발자가 놓친 경우를 짚는 순서가 흔합니다.

읽는 쪽은 넷이고 각자 다른 자리를 봅니다.

1. 개발자 — 동작과 결과, 예외 경로를 보고 얼마나 걸릴지 답합니다. 만들 것이 한 경우인지 다섯 경우인지에 따라 답이 달라져서, 예외가 비어 있으면 추정이 두 배씩 벌어집니다.
2. 디자이너 — 경우의 수를 세어 그려야 할 화면이 몇 개인지 정합니다. 예외 네 줄이 화면 네 개가 되는 일이 흔합니다.
3. 품질 보증 — 출시 전 품질을 점검하는 쪽입니다. 인수 조건과 예외 경로를 그대로 검수 목록으로 옮기므로, 적히지 않은 경우는 검수에서도 빠집니다.
4. 세일즈와 고객 성공 — 고객에게 무엇을 약속해도 되는지를 여기서 확인합니다.

그래서 한 자리가 비면 그 자리를 읽는 사람만 멈춥니다. 예외 경로가 없으면 개발은 시작되는데 검수에서 판정할 기준이 없고, 주어가 흐리면 디자이너가 화면을 몇 개 그려야 할지 되묻습니다.

"기능 요구사항에 예외가 하나도 없는데, 코드가 틀렸을 때는 어떻게 되나요?"

정상 경로만 적혀 있어 만들 수 없다는 지적입니다.

"그건 기능 요구사항이 아니라 속도 이야기예요. 아래 칸에 적을게요."

동작이 아니라 품질 조건이라 다른 자리에 적어야 한다는 말입니다.

"이번 스프린트 범위는 기능 요구사항 1번부터 4번까지입니다."

번호로 경계를 그어 무엇을 만들고 무엇을 미루는지 합의하는 방식입니다.

페이지덱에서 쿠폰 기능을 준비하던 주에 지현이 항목을 일곱 개 적어 태오에게 보냈습니다. 태오가 돌려준 것은 일정이 아니라 질문 세 개였습니다. 결제를 부분 취소하면 쿠폰이 돌아오는지, 쿠폰과 기존 할인이 겹치면 어느 쪽이 먼저인지, 결제 도중에 쿠폰이 만료되면 어떻게 되는지였습니다.

지현은 세 질문의 답을 항목으로 만들어 문서를 열 개로 늘렸고, 늘어난 세 줄이 일정에 나흘을 더했습니다. 그 나흘은 원래도 필요한 시간이었고 문서에 적히기 전에는 아무의 일정에도 없었을 뿐입니다.

기능 요구사항을 화면 설명으로 읽는 경우가 가장 많습니다. 결과가 대개 화면으로 보이니 자연스러운 오해입니다. 하지만 여기 적는 것은 제품이 무엇을 해야 하는가이고, 그것을 어느 화면 어디에 어떻게 놓을지는 다음 단계의 일입니다. 둘을 섞어 쓰면 "쿠폰 입력칸을 결제 버튼 위에 둔다" 같은 문장이 요구사항 자리에 들어오고, 배치를 바꿀 때마다 요구사항 문서까지 고쳐야 합니다.

자세히 적으면 만드는 사람의 판단을 뺏는다고 읽는 것도 흔합니다. 지시가 촘촘할수록 재량이 준다는 짐작인데, 실제로 촘촘해지는 것은 무엇을 만들지이고 어떻게 만들지는 그대로 남습니다. 만료된 쿠폰에 어떤 안내를 보여 줄지는 제품을 맡은 쪽이 정하고, 그 화면을 어떤 구조로 구현할지는 개발자가 정합니다. 이 경계가 흐리면 만드는 사람이 제품 결정까지 대신하게 되고, 그 결정은 검수에서야 드러납니다.