Why Requirements Become a Document

한 줄 요약

요구사항 정의는 문서를 만드는 일이 아니라 말을 검증 가능한 문장으로 바꾸는 일이고, 번호를 붙이는 이유는 그 번호가 설계·개발·테스트·검수를 꿰는 실이 되기 때문이다.

현장 첫 장면

프로젝트 착수 2주차. PM 이 당신에게 회의록 뭉치를 던지며 말한다. "이거 정리해서 요구사항정의서 초안 만들어 주세요. 금요일 검토회의 때 씁니다."

회의록에는 이런 문장이 있다.

"주문 화면에서 조회가 좀 느리니까 개선했으면 좋겠고, 관리자는 엑셀로도 받아볼 수 있으면 좋겠네요. 아, 그리고 요즘 보안 감사 나와서 로그인 이력도 남겨야 합니다."

이 한 문단은 요구사항 세 개다. 그리고 셋 다 지금 상태로는 개발할 수 없다. "좀 느리니까"는 몇 초를 말하는가? "엑셀로도"는 화면 그대로인가 다른 항목인가? "로그인 이력"은 성공만인가 실패도인가, 보관 기간은?

요구사항 정의란 말을 검증 가능한 문장으로 바꾸는 일이다.

왜 번호를 붙이는가

SI 프로젝트에서 요구사항에 REQ-014 같은 ID 를 붙이는 이유는 관료주의가 아니다. 이 ID 하나가 이후 모든 문서를 꿰는 실이 되기 때문이다.

REQ-014 (요구사항정의서)
  → SCR-032 주문조회 화면 (화면정의서)
  → PGM-118 OrderSearchService (프로그램목록)
  → TC-207 대량조회 성능 테스트 (단위테스트 시나리오)
  → ITC-041 주문-정산 연계 테스트 (통합테스트)
  → 검수확인서 항목 14번

이 연결이 끊기면 세 가지 사고가 난다.

1. 개발했는데 아무도 테스트 안 한 기능 — 오픈 후 첫 장애로 발견된다.
2. 테스트는 했는데 요구사항에 없던 기능 — 누가 지시했는지 아무도 모른다. 검수 때 "이건 과업 범위 밖인데 왜 했죠"라는 말을 듣는다.
3. 요구사항에는 있는데 개발이 없는 기능 — 검수 직전에 발견된다. 가장 아프다.

셋 다 막는 도구가 요구사항 추적표(RTM, Requirements Traceability Matrix) 다. 행은 요구사항, 열은 산출물. 빈칸이 곧 리스크다.

좋은 요구사항 문장의 조건

현장에서 통용되는 기준은 대략 이렇다.

• 검증 가능(testable) — "빠르게"가 아니라 "동시 100 사용자에서 3초 이내". 숫자가 없으면 검수 때 고객과 싸운다. 무조건 진다.
• 원자적(atomic) — 한 문장에 하나. "조회하고 엑셀 다운로드한다"는 둘로 쪼갠다. 쪼개야 진척률이 정확해진다. 안 쪼개면 영원히 "90% 완료"다.
• 출처가 있다(source) — 누가 언제 말했는지. 나중에 "그런 말 한 적 없다"가 나온다. 실제로 나온다. 반드시 나온다.
• 우선순위가 있다 — 상/중/하. 일정이 밀리면 '하'부터 다음 차수로 넘긴다. 우선순위 없이 시작한 프로젝트는 막판에 전부 '상'이 된다.

요구사항은 반드시 바뀐다 — 그래서 변경관리를 한다

신입이 가장 많이 하는 오해: "요구사항을 잘 정의하면 안 바뀐다." 안 바뀐다는 프로젝트는 없다. 관리되지 않는 변경이 있을 뿐이다.

변경관리의 최소 형태는 변경 요청 대장 한 장이다.

항목	왜 필요한가
변경 전 / 변경 후	무엇이 달라졌는지 나중에 재구성 가능
요청자	책임 소재. 고객사 현업인지 우리 PL 인지
영향도	연관 화면·프로그램·공수(MD). 이게 협상 카드다
승인 여부	승인 전 개발 착수 = 무상 개발

승인 전에 개발하지 마라. 이건 SI 판에서 가장 비싸게 배우는 교훈이다. "급하니까 일단 해 놓고 문서는 나중에"로 시작한 일은 정산 때 근거가 없다.

과업대비표 — 검수의 최종 무기

공공 프로젝트에서는 과업대비표를 쓴다. 제안요청서(RFP)의 과업 항목과 실제 산출물을 1:1 로 대조한 표다. 검수 회의는 사실상 이 표를 한 줄씩 읽는 자리다.

RTM 을 프로젝트 내내 성실히 갱신했다면 과업대비표는 그걸 다시 정렬한 것에 불과하다. 안 했다면, 검수 2주 전에 전 팀원이 밤을 새며 역추적을 한다. 어느 쪽을 택할지는 프로젝트 첫 달에 결정된다.

추적표가 실제로 굴러가게 만드는 법

요구사항 추적표는 만들기는 쉬운데 유지되지 않는다. 프로젝트 중반이면 문서와 현실이 갈라지고, 그때부터 아무도 안 본다. 유지되는 표에는 공통점이 있다.

한 곳에서만 관리한다. 엑셀과 이슈 트래커에 같은 항목이 있으면 둘 다 틀린다. 어느 하나를 원본으로 정하고, 다른 곳에서는 그것을 참조만 한다. 보고용 문서가 필요하면 원본에서 뽑아 만든다.

번호는 절대 재사용하지 않는다. REQ-042 가 삭제되었다고 다음 요구사항에 그 번호를 주면, 옛 회의록과 시험 문서가 다른 것을 가리키게 된다. 삭제된 항목은 삭제 상태로 남긴다.

추적은 양방향이어야 쓸모가 있다. 요구사항에서 시험으로 내려가는 방향만 있으면 "이 시험은 왜 있는가" 에 답할 수 없다. 반대 방향이 있어야 없어진 요구사항에 딸린 시험과 근거 없는 기능이 드러난다.

방향	답하는 질문
요구 → 설계 → 코드 → 시험	이 요구사항은 구현되고 검증되었는가
시험 → 요구	이 시험은 무엇을 보장하는가
코드 → 요구	이 기능은 누가 왜 요청했는가

변경은 번호가 아니라 버전으로 남긴다. REQ-042 의 내용이 바뀌었다면 새 번호를 주지 말고 그 항목의 버전을 올린다. 언제, 누가, 왜 바꿨는지와 함께. 검수 때 "이건 원래 이런 뜻이 아니었다" 는 다툼이 여기서 갈린다.

빈칸이 곧 위험 신호다. 설계는 있는데 시험이 없는 행, 시험은 있는데 요구사항이 없는 행을 주기적으로 뽑아 본다. 표를 다 채우는 것이 목적이 아니라, 비어 있는 칸을 보이게 만드는 것이 추적표의 존재 이유다.

이번 모듈에서 할 것

인터뷰 정리본에서 요구사항을 뽑아 번호를 붙이고, 추적표를 만들고, 협력사가 준 추적표에서 빠진 요구사항을 기계적으로 찾아내는 스크립트를 작성한다. 사람 눈으로 대조하지 않는다 — 500 건짜리 추적표는 눈으로 못 본다.