요구사항 감사란 무엇인가: 커버리지, 이탈, 예시

요구사항 감사는 팀이 합의하고 승인 시점에 기준선으로 동결한 요구사항을, 실제로 존재하는 작업과 비교하는 일입니다. 각 요구사항에 대해 커버리지를 보고합니다. 연결된 작업이 있는가, 그 작업은 완료되었는가. 또한 이탈도 보고합니다. 승인 후 문구가 바뀌었거나 삭제된 요구사항입니다. 소스 코드는 읽지 않습니다.

이것이 한 문단으로 정리한 전체 개념입니다. 나머지는 팀에 왜 이것이 필요한지, PRD가 실제 출시물과 어긋나는 실제 예시, 코드 스캔과의 차이, 그리고 수작업이든 도구든 어떻게 수행하는지를 설명합니다.

"우리가 무엇을 만들기로 합의했는가"가 어려운 질문인 이유

모든 팀이 열린 작업이 몇 개인지는 말할 수 있습니다. 그러나 요구사항 하나하나에 대해, 열린 작업들을 합치면 약속한 것이 되는지 말할 수 있는 팀은 드뭅니다. 두 사실이 서로 다른 곳에 있기 때문입니다. 요구사항은 몇 달 전에 쓴 PRD, 제안서, 계약서, Notion 페이지에 있습니다. 작업은 트래커에 있고, 집어 든 사람이 이름 붙인 이슈로 쪼개져 있습니다. 아무도 둘을 연결하지 않고, 그 사이의 공백은 고객, 출시, 신규 입사자가 발견할 때까지 보이지 않습니다.

공백은 세 가지 방식으로 커집니다.

누락. 요구사항은 합의됐지만 작업으로 바뀌지 않았습니다. 백로그에 없으니 어떤 보드도 지연으로 표시하지 않습니다.
조용한 재작성. 승인 후 요구사항이 편집됐습니다. 보통 만들기 쉬운 쪽에 맞추기 위해서입니다. 살아 있는 문서는 이제 구현이 "통과"한다고 말하고, 원래 문구는 사라졌습니다.
조용한 삭제. 요구사항이 지워졌습니다. 문서는 짧아졌고, 아무도 그래야 한다고 결정하지 않았습니다.

요구사항 감사는 이 세 가지를 모두 보이게 합니다. 용어집 항목에 공식 정의가 있으며, 요구사항 추적성 감사, 요구사항 커버리지라고도 부릅니다.

세 가지 요소: 기준선, 커버리지, 이탈

기준선. 요구사항 기준선은 승인된 순간의 요구사항을 동결하고 번호를 붙인 사본입니다. 각 항목의 식별자, 문구, 우선순위, 인수 기준을 담습니다. 살아 있는 문서는 계속 바뀌지만 기준선은 바뀌지 않습니다. 기준선 항목에서 이 관행을 더 자세히 다룹니다. 기준선이 없으면 감사할 대상이 없습니다. 남아 있는 유일한 요구사항 버전이 이미 이탈한 것이기 때문입니다.

커버리지. 기준선의 각 요구사항에 대해, 뒷받침하는 작업은 어떤 상태인가? 유용한 감사는 최소한 다음 상태를 구분합니다.

상태	의미	보통 뜻하는 것
작업 없음	트래커의 어떤 것도 이 요구사항을 가리키지 않음	합의되고 잊힘
진행 중	연결된 작업이 있고 끝나지 않음	순조롭거나 정체. 날짜 확인
작업 완료	연결된 모든 작업이 완료	인수 기준에 비춰 검증할 준비됨
이후 제외됨	기준선 이후 살아 있는 문서에서 요구사항이 제거됨	기록 여부와 무관한 범위 결정
레코드 사라짐	요구사항 레코드 자체가 삭제됨	누군가 정리함. 합의된 것인가?

유일한 작업들이 모두 취소된 요구사항은 세 번 시도했더라도 작업이 없는 것이며, 정직한 감사는 두 가지를 모두 말합니다.

이탈. 이탈은 기준선의 문구와 오늘의 문구를 비교합니다. 동결 후 요구사항의 텍스트가 바뀌었다면 감사는 이를 표시하고 두 버전을 모두 보여줍니다. 기준선을 평가한다고 하면서 새 문구에 대해 커버리지를 보고하면 오해를 낳으므로, 좋은 감사는 항상 동결된 텍스트에 대해 측정하고 그 옆에 살아 있는 텍스트를 보여줍니다.

실제 예시: PRD는 이렇게 말했고, 구현은 다르게 됐다

작고 현실적인 사례입니다. 네 명의 팀이 고객 포털 PRD에 요구사항 14개로 합의하고 9월 2일에 기준선 1로 동결합니다. 출시는 10월 30일입니다. 출시 2주 전에 누군가 감사를 실행합니다.

11개는 진행 중이거나 완료됐습니다. 세 개는 아닙니다.

REQ-006, "고객은 청구서를 CSV와 PDF로 내보낼 수 있다." 커버리지: 작업 완료. 이탈: 표시됨. 살아 있는 문구는 이제 "고객은 청구서를 CSV로 내보낼 수 있다"입니다. 개발자가 PDF 라이브러리를 다루기 까다롭다고 느꼈을 때 PDF 절반이 빠졌고, 요구사항은 거기에 맞춰 편집됐습니다. PDF를 요청한 고객에게는 아무도 알리지 않았습니다.
REQ-009, "고객이 청구서에 이의를 제기하면 관리자가 이메일을 받는다." 커버리지: 작업 없음. 합의는 됐지만 아무도 이슈를 만들지 않았고, 백로그에 해당 행이 없습니다. 보드는 존재하는 이슈만 알기 때문에 모든 보드가 초록색이었습니다.
REQ-013, "포털은 출시 시점에 두 언어를 지원한다." 커버리지: 이후 제외됨. 3주 차에 채팅에서 이루어진 범위 논의 중 살아 있는 PRD에서 제거됐습니다. 결정은 옳았을지 모르지만, 그 기록은 아무도 찾지 못하는 메시지 하나입니다.

이 중 어느 것도 스프린트 리뷰에서는 드러나지 않습니다. REQ-006은 시연됐고 끝나 보였습니다. REQ-009는 작업으로 존재한 적이 없습니다. REQ-013은 조용히 요구사항이기를 멈췄습니다. 감사는 보이지 않던 세 공백을 세 가지 결정으로 바꿨습니다. REQ-009의 작업을 만들고, REQ-006을 복원하거나 공식적으로 재협상하고, REQ-013 결정을 기록해 기준선 2에 반영하는 것입니다.

감사가 모델의 프로젝트 해석이 아니라 기록에서 계산되어야 하는 이유도 여기 있습니다. 언어 모델에게 "REQ-009가 커버되었나"라고 물으면 이메일 알림과 비슷한 것을 찾다가 영수증 관련 이슈를 발견할 수도 있습니다. 요구사항과 이슈 사이의 명시적 연결에서 계산한 커버리지는 단순히 "작업 없음"이라고 답하며, 그것이 팀에 필요한 답이었습니다.

요구사항 감사 vs 코드 스캔 vs 코드 리뷰

사람들은 "감사"라는 말을 들으면 소스 코드를 읽는 스캐너를 떠올립니다. 그것은 다른 질문을 가진 다른 활동입니다.

	요구사항 감사	코드 스캔(정적 분석)	코드 리뷰
질문	합의한 것을 만들었는가?	코드가 건전한가?	이 변경이 좋은가?
입력	기준선 요구사항과 연결된 작업 항목	소스 코드	풀 리퀘스트 하나
코드를 읽는가	아니요	예	예
찾는 것	누락, 재작성, 조용한 범위 제거	버그, 취약점, 나쁜 패턴	국소 오류, 설계와 스타일 문제
놓치는 것	완료된 작업이 실제로 기준을 충족하는지	코드에 아예 없는 약속	여러 변경에 걸친 문제
결과물	요구사항별 커버리지와 이탈	파일이나 줄 단위 발견 사항	승인 또는 수정 요청

셋은 서로를 대체하지 않습니다. 모든 스캔을 통과한 코드베이스에도 고객이 돈을 낸 기능이 빠져 있을 수 있습니다. 모든 요구사항이 커버된 요구사항 감사도 보안 구멍을 내보낼 수 있습니다. 둘 다 중요하게 여기는 팀은 둘 다 합니다.

두 가지 주의가 요구사항 감사를 정직하게 유지합니다. 첫째, "작업 완료"는 "요구사항 충족"이 아닙니다. 완료된 이슈는 누군가 작업을 끝냈음을 증명할 뿐, 결과가 인수 기준을 충족한다는 뜻은 아닙니다. 여전히 사람이 확인해야 합니다. 둘째, 감사는 연결의 품질만큼만 좋습니다. 이슈가 요구사항에 묶여 있지 않으면 모든 요구사항이 "작업 없음"으로 표시되어 쓸모가 없습니다. 연결하는 것이 선행 비용이고, 그것이 감사를 가능하게 하는 바로 그 비용입니다.

요구사항 감사를 수작업으로 수행하는 법

도구는 필요 없습니다. 규율과 스프레드시트가 필요합니다.

기준선을 동결하세요. 승인된 요구사항을 행마다 안정적인 ID(REQ-001, REQ-002), 정확한 문구, 우선순위, 인수 기준과 함께 시트에 옮기세요. 날짜를 적고 누가 승인했는지 기록하세요. 이 시트는 다시 편집하지 않습니다.
작업을 요구사항에 연결하세요. 트래커에서 모든 이슈에 그것이 기여하는 요구사항을 가리키는 필드나 라벨을 부여하세요. 요구사항 ID가 없는 새 작업은 버그이거나 잡무이거나 범위 확장입니다. 어느 것인지 결정하세요.
커버리지를 계산하세요. 각 REQ 행에 대해 이슈와 상태를 나열하세요. 위 표의 상태를 부여하세요. 작업 없음 행을 먼저 세세요. 그 목록이 감사의 주요 발견입니다.
이탈을 확인하세요. 살아 있는 요구사항 문서를 동결된 시트 옆에 두세요. 문구가 다른 행과 살아 있는 버전에 없는 행을 모두 표시하세요.
결정을 기록하세요. 각 공백에 대해 작업을 만들거나, 재협상하거나, 공식적으로 제외하세요. 제외한 것은 이유와 함께 기록하고, 기준선 2를 동결하세요.
마일스톤마다 반복하세요. 고객 리뷰, 출시, 청구, 인수인계 전에. 대부분의 작은 팀에는 월 1회면 충분합니다.

수작업 버전도 작동합니다. 약점은 2단계입니다. 사람들이 바빠지는 순간 연결은 퇴화하고, 아무도 갱신하지 않는 시트는 아무도 신뢰하지 않는 감사를 만듭니다.

도구는 어떻게 하며, Atrix는 무엇을 하는가

규제 산업을 겨냥한 여러 요구사항 관리 도구가 수십 년 동안 추적성을 제공해 왔습니다. 보통 요구사항 대 테스트와 작업의 매트릭스 형태입니다. 항공우주, 의료, 자동차 팀을 위해 만들어졌고 가격도 그에 맞춰져 있습니다.

작은 프로덕트 팀에게 실용적인 버전은 요구사항과 이슈를 같은 곳에 두고 연결을 대신 유지해 주는 트래커입니다. 이것이 우리가 우리 자신의 프로젝트를 위해 Atrix에 넣은 것이며, 무엇을 하는지 정확히 말할 가치가 있습니다. 에이전트의 Develop 실행이 브리프에서 요구사항을 작성하고, 여러분이 편집하고 승인하면 Audit 모드가 기준선을 동결합니다. 그때부터 감사는 기준선의 모든 요구사항에 대해 위의 다섯 가지 상태를 보고하고, 문구가 바뀌었다면 이탈 표시와 살아 있는 문구를 함께 보여줍니다. 모든 상태는 모델의 판단이 아니라 행에서 계산되므로, 감사는 AI 실행을 소모하지 않고 두 번 실행해도 같은 답을 줍니다. 연결된 GitHub와 Vercel 프로젝트는 저장소와 배포 신호를 그 옆에 더합니다.

하지 않는 것도 똑같이 중요합니다. Atrix는 코드를 스캔하지 않고, 정적 분석을 실행하지 않으며, 취약점을 찾지 않습니다. 기능 페이지에 그렇게 적혀 있습니다. 코드 감사가 필요하다면 그것은 다른 서비스이고, 우리 쪽에서는 제품이 아니라 에이전시의 사람 감사자가 합니다. 구현이 합의와 일치하는지 알아야 한다면, 그것이 제품의 일입니다.

FAQ

요구사항 감사와 코드 감사의 차이는 무엇인가요?

요구사항 감사는 합의한 요구사항을 존재하는 작업과 비교해 커버리지와 이탈을 보고합니다. 코드 감사는 소스 코드를 기준에 비추어 버그, 보안, 품질을 점검합니다. 전자는 "합의한 것을 만들었는가"에, 후자는 "코드가 건전한가"에 답합니다. 어느 쪽도 다른 쪽을 대체하지 않습니다.

요구사항 추적성이란 무엇인가요?

추적성은 각 요구사항에서 그것을 구현하는 작업, 테스트, 코드로 이어지는 연결과 그 역방향 연결의 집합입니다. 요구사항 감사는 이것에 의존합니다. 이슈에서 요구사항으로의 연결이 없으면 커버리지를 계산할 수 없습니다.

범위 이탈이란 무엇인가요?

범위 이탈, 또는 요구사항 이탈은 명시적 결정 없이 프로젝트가 제공해야 할 것이 점진적으로 바뀌는 현상입니다. 구현에 맞춰 요구사항이 다시 쓰이거나, 조용히 빠지거나, 승인 없이 추가되는 것입니다. 감사는 동결된 기준선과 살아 있는 요구사항을 비교해 이를 감지합니다.

요구사항은 얼마나 자주 감사해야 하나요?

고정된 달력보다는 마일스톤에 맞춰서입니다. 고객 리뷰, 출시, 인수인계, 큰 청구 전입니다. 연결을 최신으로 유지하는 팀은 몇 분 만에 필요할 때 감사할 수 있고, 수작업으로 하는 팀은 보통 월 1회가 한계입니다.

작업이 완료되면 요구사항이 충족된 것인가요?

아니요. 완료된 작업은 누군가 일을 끝냈음을 보여줄 뿐, 결과가 인수 기준을 충족한다는 뜻은 아닙니다. 좋은 감사는 이 상태를 "작업 완료"로 표시하고, 기준에 비춘 검증은 사람에게 맡깁니다.

AI가 요구사항 감사를 수행할 수 있나요?

AI는 요구사항을 쓰고 다듬을 수 있고, 작업을 요구사항에 연결하는 것을 도울 수 있습니다. 감사 자체는 기록에서 계산되어야 합니다. 무언가가 "커버되었는지"에 대한 모델의 의견은 실행마다 달라지고 고객 앞에서 방어할 수 없기 때문입니다. Atrix는 요구사항 작성에는 에이전트를, 감사 계산에는 순수 데이터를 사용합니다.

다음 단계

요구사항 감사 용어집 항목에서 정의와 상태를 확인하고, 첫 기준선을 동결하세요. 연결과 감사를 대신 유지해 주길 원한다면, Atrix의 요구사항 감사가 여러분의 이슈로부터 수행합니다.

요구사항 감사란 무엇인가? 커버리지와 이탈, 그리고 실제 예시