비기능 요구사항

요구사항을 적을 때 오래도록 한 가지만 적었습니다. 제품이 무엇을 해야 하는지, 그러니까 기능 요구사항입니다. 사용자가 어떤 버튼을 누르면 무엇이 보인다는 문장을 잔뜩 적어 개발에 넘기는 식이었습니다.

문제는 그다음에 나왔습니다. 페이지덱이 문서 검색 기능을 열었을 때가 그랬습니다. 검색창에 단어를 넣으면 결과가 나오기는 했는데, 문서가 3천 개를 넘는 팀에서는 결과가 뜨기까지 4초가 걸렸습니다. 검수 자리에서 지현이 너무 느리다고 말했고, 태오는 몇 초 안에 나와야 한다는 말이 문서 어디에도 없었다고 답했습니다. 둘 다 틀린 말을 하지 않았습니다. 요구사항에는 결과가 나온다고만 적혀 있었습니다.

그 시점에 고치려니 검색을 짠 방식을 통째로 바꿔야 했습니다. 1초를 목표로 두고 시작했다면 애초에 다른 구조로 만들었을 텐데, 다 만든 뒤에 알게 되어 2주를 더 썼습니다. 무엇을 하는지 말고 어느 수준으로 하는지를 착수 전에 적어 두는 칸이 그래서 생겼습니다.

동작을 적는 대신 그 동작이 만족해야 할 조건을 숫자로 적습니다. 한 문장에 대상과 기준값과 재는 방법이 함께 들어갑니다. "검색이 빨라야 한다" 는 조건이 아니고 "문서 3천 개를 가진 팀에서 검색 결과가 1초 안에 나온다" 가 조건입니다. 앞의 문장으로는 맞았는지 틀렸는지 아무도 판정하지 못하고, 뒤의 문장은 검수 자리에서 한 번 눌러 보면 판정이 끝납니다.

실무에서 채우는 칸은 대개 다섯 갈래입니다.

1. 성능 — 얼마나 빠른지입니다. 화면이 그려지기까지, 요청에 답하기까지 걸리는 시간에 상한을 둡니다. 가장 큰 콘텐츠가 화면에 그려진 시점을 재는 LCP처럼 이미 정의된 지표를 기준으로 삼으면 사람마다 다르게 세는 일이 없습니다.
2. 부하 — 몇 명까지 견디는지입니다. 동시에 500명이 들어와도 응답 시간이 두 배를 넘지 않는다는 식으로 적고, 요청을 많이 보내 견디는지 확인하는 부하 테스트로 맞았는지 봅니다.
3. 보안 — 무엇을 남기지 않고 무엇을 막는지입니다. 비밀번호와 결제 정보를 기록에 그대로 쓰지 않는다, 남의 문서 주소를 알아도 열리지 않는다 같은 항목이 들어갑니다.
4. 접근성 — 누가 쓸 수 있는지입니다. 접근성은 눈이 잘 보이지 않거나 손을 쓰기 어려운 사람까지 포함해 화면을 설계하는 일이고, 기준은 국제 지침인 WCAG의 등급을 적어 둡니다.
5. 가용성 — 얼마나 안 멈추는지입니다. 정상 동작한 시간의 비율인 가동률을 99.9퍼센트로 잡으면 한 달에 멈춰도 되는 시간이 43분으로 정해집니다.

칸마다 숫자를 고를 때 잣대는 이상적인 값이 아니라 그 값을 못 지켰을 때 생기는 손해입니다. 검색이 4초 걸리면 사람들이 검색 자체를 안 쓰게 되니 1초로 잡고, 문서가 5분 동안 안 열리면 그 팀의 일이 전부 멈추니 가동률은 두 자리 뒤까지 올려 잡습니다. 반대로 관리자 화면처럼 하루에 몇 번 쓰는 곳은 3초가 걸려도 손해가 없으니 숫자를 느슨하게 둡니다.

처음 쓰이는 자리는 요구사항 문서 안의 한 칸입니다. 해야 하는 동작을 적은 칸 바로 아래에 놓이고, 이번에 만들기로 한 범위와 같은 시점에 채웁니다. 다 만든 뒤에 적으면 이미 정해진 구조 안에서 지킬 수 있는 숫자만 적게 되어, 문서가 결정을 이끄는 대신 결과를 받아쓰게 됩니다.

여기서 적힌 숫자는 세 곳으로 흘러갑니다.

1. 설계 결정 — 태오가 무엇으로 만들지 정할 때 씁니다. 1초 안에 검색 결과를 내야 한다는 한 줄이 있으면 검색어를 미리 정리해 두는 구조를 고르고, 3초까지 괜찮다면 훨씬 단순한 방식으로 끝냅니다. 같은 기능이 이 한 줄에 따라 다른 물건이 됩니다.
2. 검수 항목 — 출시 전 품질을 점검하는 품질 보증 단계에서 하나씩 확인합니다. 동작만 보는 검수와 달리 여기서는 시간을 재고 사람 수를 늘려 보고 키보드만으로 화면을 다녀 봅니다.
3. 고객과의 약속 — 기업 고객은 계약서에 서비스 수준을 적어 달라고 요구합니다. 계약으로 못 박은 SLA의 숫자가 문서의 숫자보다 높으면 지킬 수 없는 약속이 되므로, 수아가 계약을 쓸 때 두 숫자를 맞춰 봅니다.

"이 기능 비기능 요구사항이 비어 있는데요. 응답 시간 기준 누가 정해 주세요."

만들기 전에 지킬 숫자를 정해 달라는 요청입니다.

"접근성 항목은 이번 범위에 못 넣습니다. 안 하는 것으로 적어 두겠습니다."

빼는 결정을 문서에 남겨 나중에 잊히지 않게 하겠다는 뜻입니다.

"기능은 다 됐는데 비기능이 안 잡혀서 아직 못 엽니다."

동작은 요구대로 도는데 속도나 보안 기준을 못 맞춰 출시를 미룬다는 말입니다.

페이지덱에서는 지현이 요구사항 문서를 열어 회의를 시작하면 태오가 가장 먼저 이 칸을 봅니다. 여기 적힌 숫자에 따라 답해야 할 일정이 2주에서 6주까지 벌어지기 때문입니다. 민서는 접근성 줄을 보고 화면 대비와 키보드 이동을 시안 단계에서 반영합니다. 나중에 알게 되면 색과 구조를 다시 그려야 하기 때문입니다.

있으면 좋은 항목으로 읽는 경우가 가장 많습니다. 화면에 보이지 않고 사용자가 달라고 말한 적도 없으니 순위를 뒤로 미루기 쉽습니다. 하지만 사용자 쪽에서 보면 버튼이 없는 화면과 눌러도 4초 뒤에 반응하는 화면은 같습니다. 둘 다 그 일을 못 한 것입니다. 미뤄 두면 나중에 고치는 값이 처음의 몇 배가 되고, 구조를 다시 짜는 동안 새 기능은 하나도 나가지 않습니다.

숫자 없이 적어도 적은 셈이라고 여기는 것도 흔합니다. "빠르게 동작한다", "안전하게 처리한다" 라고 쓰면 칸이 채워진 것처럼 보이니 그렇습니다. 그런데 이런 문장은 검수에서 판정이 되지 않아서, 3초를 빠르다고 보는 사람과 1초여야 한다고 보는 사람이 출시 전날 같은 화면을 두고 다투게 됩니다. 판정할 수 없는 줄은 없는 줄과 같습니다.