요구사항정의서 쓰는 법 2026 — 항목 12가지·요구사항 ID 체계와 추적표(RTM)

요구사항정의서는 발주처가 "무엇을 만들어 달라"고 적는 문서이고, 프로젝트에서 범위·견적·검수 기준이 모두 이 한 문서에서 파생됩니다. 기능정의서도 화면설계서도 WBS도 검수확인서도 전부 이 문서를 근거로 만들어집니다. 그래서 요구사항정의서가 부실하면 이후 산출물이 아무리 두꺼워도 "합의한 적 없는 기능"을 두고 분쟁이 납니다.

문제는 이 문서를 쓰는 사람이 대개 개발자가 아니라는 점입니다. 기획자나 현업 담당자가 처음 써 보는 경우가 많고, 그래서 "회원가입 기능 필요"처럼 검수할 수 없는 문장이 그대로 계약에 실립니다. 이 글은 요구사항정의서에 실제로 무엇이 들어가야 하는지, 요구사항 ID와 추적표를 어떻게 설계하는지, 비기능 요구사항을 어떻게 숫자로 바꾸는지를 발주처 관점에서 정리했습니다.

요구사항정의서란 무엇인가

요구사항정의서(Requirements Definition Document)는 시스템이 갖춰야 할 기능과 품질 조건을 발주처와 개발사가 합의 가능한 형태로 기술한 문서입니다. 요건정의서·요구정의서라고도 부르며, 영문 문맥에서는 SRS(Software Requirements Specification, 소프트웨어 요구사항 명세서)와 거의 같은 역할을 맡습니다.

핵심 성질은 세 가지입니다.

1. 합의의 단위다. 이 문서에 없는 것은 과업이 아닙니다. 구두로 오간 요청이 여기에 적히지 않으면 추가 개발로 처리되는 것이 원칙입니다.
2. 검증 가능해야 한다. 각 요구사항은 완료 여부를 누군가 판정할 수 있어야 합니다. "빨라야 한다"는 요구사항이 아니고 "목록 조회 응답이 95퍼센타일 기준 1.5초 이내"는 요구사항입니다.
3. 추적 가능해야 한다. 요구사항 하나가 어떤 기능·화면·테스트케이스로 이어졌는지 되짚을 수 있어야 합니다. 이를 위해 ID 체계가 필요합니다.

공공 정보화사업에서는 이 문서가 단순 참고자료가 아니라 과업 범위의 법적 근거로 쓰입니다. 소프트웨어 진흥법에 따라 과업 내용을 확정하거나 변경할 때 과업심의위원회의 심의를 거치는데, 그 심의의 기준 문서가 요구사항정의서입니다. 민간 프로젝트에서도 계약서에 "별첨 요구사항정의서에 따른다"는 문구로 첨부되는 경우가 대부분입니다.

요구사항정의서·요구사항명세서·기능정의서·화면정의서는 어떻게 다른가

네 문서를 섞어 쓰는 것이 현장에서 가장 흔한 혼란입니다. 이름이 비슷해서가 아니라 작성 주체와 시점이 다르기 때문에 구분이 필요합니다.

관계는 위에서 아래로 한 방향입니다. 요구사항 하나가 기능 여러 개로 갈라지고, 기능 하나가 화면 여러 개로 갈라집니다. 반대 방향으로는 갈 수 없습니다. 화면을 먼저 그리고 요구사항을 역으로 맞추면, 화면에 안 나타나는 요구사항(배치 작업, 외부 연계, 권한 규칙)이 통째로 누락됩니다.

요구사항정의서와 요구사항명세서를 굳이 나누지 않고 한 문서로 운영하는 프로젝트도 많습니다. 중소 규모에서는 그게 오히려 효율적입니다. 다만 발주처가 쓴 원문은 반드시 남겨 두세요. 개발사가 상세화하면서 해석을 덧붙이는데, 원문이 사라지면 나중에 "우리가 요청한 건 그게 아니다"를 증명할 근거가 없어집니다. 실무에서는 같은 표에 「발주 원문」 열과 「상세화 내용」 열을 나란히 두는 방식을 씁니다.

기능정의서와 화면정의서의 실제 작성법은 각각 기능 정의서 작성법과 화면설계서 작성법에 따로 정리해 두었습니다.

요구사항정의서에 반드시 들어가는 12가지 항목

요구사항 한 건이 차지하는 행에 무엇을 적을지가 문서 품질의 전부입니다. 아래 12개 항목이 실무 표준에 가깝습니다.

이 중 현장에서 가장 자주 빠지는 것이 수용 기준(acceptance criteria) 입니다. 수용 기준이 없는 요구사항은 검수 단계에서 반드시 문제가 됩니다. "회원가입 기능"이라고만 적힌 요구사항은, 소셜 로그인이 포함되는지·이메일 인증이 필요한지·중복 가입을 어떻게 막는지가 전부 열려 있습니다. 개발사는 가장 단순한 해석으로 만들고, 발주처는 가장 완전한 해석을 기대합니다.

수용 기준은 다음 형식으로 쓰면 거의 실패하지 않습니다.

> ~한 상태에서 ~를 하면 ~가 된다.

> 예: 이메일 인증을 마치지 않은 계정으로 로그인을 시도하면, 로그인이 거부되고 인증 메일 재발송 안내가 표시된다.

요구사항 ID 체계 — 추적성은 여기서 시작한다

요구사항 ID를 그냥 1, 2, 3으로 매기는 문서를 자주 봅니다. 요구사항이 40개를 넘어가는 순간부터 관리가 안 됩니다. 중간에 하나가 추가되면 번호가 밀리고, 이미 발행한 회의록·테스트케이스의 참조가 전부 어긋납니다.

ID는 의미를 담되, 한 번 부여하면 절대 재사용하지 않는 것이 원칙입니다. 삭제된 요구사항의 번호도 비워 둡니다. 다음 형식이 실무에서 가장 무난합니다.

REQ-<구분>-<업무영역>-<일련번호>

REQ-FUN-USR-001    기능 / 회원 / 1번
REQ-FUN-ORD-014    기능 / 주문 / 14번
REQ-NFR-PRF-003    비기능 / 성능 / 3번
REQ-IFC-PAY-002    인터페이스 / 결제 / 2번
REQ-SEC-AUT-005    보안 / 인증 / 5번

구분 코드는 FUN(기능), NFR(비기능), IFC(인터페이스), DAT(데이터), SEC(보안) 다섯 개면 충분합니다. 업무영역 코드는 프로젝트 시작 시 발주처와 함께 고정하고, 이후 추가만 하고 변경하지 않습니다.

ID 체계가 자리 잡으면 그다음 문서들이 자동으로 연결됩니다. 기능정의서의 기능 ID(`FN-USR-001`)와 화면정의서의 화면 ID(`SCRN-USR-010`)가 각각 어떤 REQ에서 나왔는지 열 하나로 표현되고, 테스트케이스 ID(`TC-USR-0012`)도 같은 방식으로 붙습니다. 이 연결이 곧 추적표입니다.

기능 요구사항과 비기능 요구사항을 가르는 기준

구분이 헷갈릴 때 쓰는 판별 문장이 있습니다.

> "시스템이 무엇을 하는가"이면 기능, "어떻게 해내는가"이면 비기능입니다.

"주문서를 PDF로 내려받을 수 있다"는 기능입니다. "PDF 생성이 3초 안에 끝난다"는 비기능입니다. 같은 대상을 다루지만 검증 방법이 완전히 다릅니다. 기능은 동작 여부로 판정하고, 비기능은 측정으로 판정합니다.

비기능 요구사항이 누락되면 개발이 끝난 뒤에야 문제가 드러납니다. 기능은 개발 중에 보이지만, 성능·동시접속·보안은 운영에 올려야 드러나기 때문입니다. 그리고 그 시점의 수정은 구조 변경이라 비용이 가장 비쌉니다. 요구사항정의서 단계에서 비기능을 적어 두는 것이 곧 리스크 관리입니다.

비기능 요구사항을 숫자로 쓰는 법

비기능 요구사항은 "안정적이어야 한다" 같은 형용사로 쓰면 아무 효력이 없습니다. 아래 표의 좌측을 우측으로 바꾸는 작업이 요구사항정의서 작성의 절반입니다.

숫자를 모르겠다면 현재 운영 중인 시스템의 실측치를 기준으로 삼으세요. 신규 구축이라 실측치가 없다면 "오픈 6개월 후 예상 사용자 수"를 근거로 적고, 그 근거를 출처 열에 남깁니다. 근거 없는 숫자보다 나쁜 것은 숫자가 아예 없는 것입니다. RPO(Recovery Point Objective, 복구 시점 목표)는 "장애 시 몇 시간 전 데이터까지 되살릴 것인가", RTO(Recovery Time Objective, 복구 시간 목표)는 "몇 시간 안에 서비스를 재개할 것인가"를 뜻합니다. 이 두 숫자는 백업 설계와 인프라 비용을 직접 결정하므로 반드시 발주처가 정해야 합니다.

요구사항 추적표(RTM) — 무엇을 어디에 연결하는가

요구사항 추적표(Requirements Traceability Matrix)는 요구사항 하나가 어떤 산출물로 이어졌고 어떤 테스트로 확인됐는지를 한 장으로 보여 주는 표입니다. 감리 대상 사업에서는 제출 산출물이고, 민간 프로젝트에서도 검수 단계에서 가장 강력한 도구입니다.

추적표가 실제로 하는 일은 빈칸을 드러내는 것입니다.

• 기능 ID 열이 빈 요구사항 → 설계에서 누락됐습니다. 개발이 시작되지도 않았다는 뜻입니다.
• 테스트케이스 ID 열이 빈 요구사항 → 검증 계획이 없습니다. 검수 때 "됩니다"라는 말 외에 확인할 방법이 없습니다.
• 어느 요구사항에도 연결되지 않은 기능 → 요청한 적 없는 기능이 만들어졌습니다. 비용은 발생했는데 범위 밖입니다.

세 번째 경우가 의외로 자주 나옵니다. 개발 중 "이왕이면 이것도"로 추가된 기능들인데, 계약 범위 밖이라 나중에 유지보수 책임 소재가 애매해집니다. 추적표는 주간 보고 때 함께 갱신하는 것이 원칙입니다. 프로젝트 끝나고 한꺼번에 채우면 그건 기록이지 관리가 아닙니다.

요구사항 우선순위 — 무엇을 기준으로 자를 것인가

요구사항을 전부 「필수」로 적은 문서는 우선순위가 없는 문서와 같습니다. 일정이 밀렸을 때 무엇을 뒤로 보낼지 결정할 근거가 사라지고, 그 결정은 결국 개발사가 임의로 하게 됩니다.

현장에서 쓸 만한 방식은 두 가지입니다.

MoSCoW — Must(없으면 오픈 불가) / Should(중요하지만 대체 수단 있음) / Could(있으면 좋음) / Won't(이번 범위 제외). 단순해서 합의가 빠릅니다. 주의할 점은 Must가 전체의 60%를 넘으면 분류가 실패한 것이라는 점입니다. 그럴 때는 "이 기능 없이 오픈일에 서비스를 열 수 있는가"를 한 건씩 되물어 걸러냅니다.

Kano 모델 — 기본 품질(없으면 불만, 있어도 당연) / 성능 품질(많을수록 만족) / 매력 품질(없어도 불만 없지만 있으면 감동). 사용자 만족도 관점이라 신규 서비스의 차별화 요소를 고를 때 유용합니다. 반면 발주 문서의 범위 협상에는 MoSCoW가 더 직접적입니다.

단계별 오픈이 예정된 프로젝트라면 우선순위 대신 차수(1차/2차/3차) 를 열로 두는 편이 훨씬 명확합니다. "권장"은 해석이 갈리지만 "2차"는 갈리지 않습니다.

IEEE 830과 ISO/IEC/IEEE 29148 — 표준은 어디까지 따라야 하나

요구사항 문서를 검색하면 IEEE 830이 자주 등장합니다. 중요한 사실이 하나 있습니다. IEEE 830-1998은 이미 폐지된 표준이고, 현행 표준은 ISO/IEC/IEEE 29148입니다(2011년 제정, 2018년 개정). 오래된 블로그 글을 그대로 따라 쓰면 폐지된 표준의 목차를 쓰게 됩니다.

다만 IEEE 830이 제시한 「좋은 요구사항의 조건」은 29148에도 그대로 이어졌고, 실무에서 쓰기에 충분히 유용합니다.

단일성 위반이 가장 흔하고 가장 비쌉니다. "회원은 가입하고 이메일 인증을 거쳐 마케팅 수신 동의를 설정할 수 있다"는 요구사항 세 개입니다. 하나로 묶여 있으면 부분 완료를 표현할 방법이 없어서, 셋 중 하나만 미완성이어도 전체가 미완으로 보이거나 반대로 전체가 완료로 처리됩니다.

표준 문서를 통째로 따를 필요는 없습니다. 위 7개 조건으로 작성한 요구사항을 한 건씩 점검하는 것만으로 대부분의 품질 문제가 걸러집니다.

메뉴구조도·인터페이스정의서는 요구사항정의서에 포함되는가

포함 여부로 다투기보다 어느 단계 산출물인지로 판단하는 편이 정확합니다.

메뉴구조도(정보구조도, IA) — 요구사항정의서 단계에서는 대분류 수준까지만 넣습니다. 3depth 이상의 메뉴 트리는 화면 목록이 확정돼야 나오므로 설계 단계 산출물입니다. 요구사항정의서에 상세 메뉴 트리를 넣으면, 설계에서 바뀔 때마다 요구사항정의서를 개정해야 해서 문서가 금방 낡습니다.

인터페이스정의서 — 요구사항정의서에는 연계 대상과 연계 목적, 데이터 종류, 주기까지 적습니다. 전문 규격·필드 레이아웃·오류코드는 설계 단계 인터페이스정의서로 넘깁니다. 요구사항 단계에서 중요한 것은 규격이 아니라 「그 외부 시스템이 우리 요구대로 협조해 줄 수 있는가」 입니다. 이게 확인 안 된 연계가 프로젝트 지연의 단골 원인입니다.

외부 연계가 있는 프로젝트라면 요구사항정의서 작성 단계에서 연계 대상 시스템의 담당 부서명과 협의 이력을 출처 열에 반드시 남기세요. "연계 가능하다고 들었다"와 "OO팀 OOO과 O월 O일 협의 완료"는 프로젝트 후반에 전혀 다른 무게를 갖습니다. 데이터 이관이 함께 걸린 프로젝트라면 데이터 마이그레이션 발주 가이드를, 개인정보를 다루는 공공사업이라면 개인정보 영향평가 발주 가이드를 함께 참고하세요.

발주처가 검토할 때 봐야 할 것

개발사가 상세화해서 돌려준 요구사항정의서를 받았을 때, 전부 읽을 시간이 없다면 아래 다섯 가지만 확인해도 대부분의 사고를 막습니다.

1. 원문이 살아 있는가. 우리가 쓴 문장이 「발주 원문」 열에 그대로 있는지 봅니다. 개발사 해석만 남아 있으면 그 해석에 동의한 것이 됩니다.
2. 수용 기준 열의 빈칸을 센다. 빈칸이 있는 요구사항은 검수 때 반드시 쟁점이 됩니다. 이 단계에서 채우는 비용이 가장 쌉니다.
3. 「제외」 상태 요구사항을 따로 본다. 협의 중 빠진 항목들인데, 빠진 이유가 적혀 있는지 확인합니다. 이유 없는 제외는 되살릴 수 없습니다.
4. 비기능 요구사항에 숫자가 있는가. 형용사만 있다면 그 항목은 계약상 의미가 없습니다.
5. 우선순위 분포를 본다. 필수가 80%라면 분류를 다시 요청하세요. 일정이 밀렸을 때 협상할 여지가 사라집니다.

검토 결과는 구두가 아니라 문서에 직접 코멘트로 남기고 회신본을 보관하세요. 검수 단계에서 근거가 되는 것은 회의에서 한 말이 아니라 남아 있는 문서입니다.

흔한 실수 6가지

1. 해결책을 요구사항으로 적는다. "Redis를 도입한다"는 요구사항이 아니라 설계 결정입니다. 요구사항은 "조회 응답 2초 이내"이고, 그걸 무엇으로 달성할지는 개발사의 몫입니다. 수단을 먼저 못 박으면 더 나은 방법이 있어도 쓸 수 없고, 그 수단으로 목표를 못 냈을 때 책임 소재도 흐려집니다.

2. 현행 시스템을 "동일하게"로 갈음한다. 재구축 프로젝트에서 "현행과 동일"이라고 적는 순간, 현행 시스템의 모든 동작이 요구사항이 됩니다. 아무도 전체를 알지 못하는 시스템이 기준이 되는 셈입니다. 최소한 주요 업무 단위로는 현행 기능 목록을 뽑아 승계·개선·폐기를 표시해야 합니다.

3. 화면을 먼저 그리고 요구사항을 역산한다. 화면에 나타나지 않는 요구사항(야간 배치, 외부 연계, 권한 규칙, 데이터 보관 정책)이 전부 빠집니다. 이 누락은 개발 후반에 드러나고 대개 구조 변경을 동반합니다.

4. 법·제도 요건을 적지 않는다. 개인정보 처리, 전자금융, 접근성, 보존 연한 같은 항목은 개발사가 알아서 챙겨 주지 않습니다. 해당 업무를 아는 쪽은 발주처입니다. 준수해야 할 근거(법령·내규·지침)를 출처 열에 명시하세요.

5. 변경을 구두로 처리한다. 프로젝트 중 요구사항은 반드시 바뀝니다. 문제는 변경 자체가 아니라 변경이 문서에 반영되지 않는 것입니다. 상태 열을 「변경」으로 바꾸고 변경 이력에 일자·사유를 남기는 절차를 주간 회의에 고정하세요.

6. 문서를 만들고 나서 안 본다. 요구사항정의서가 착수 보고 이후 열리지 않는 프로젝트가 많습니다. 추적표와 함께 주간으로 갱신되지 않으면 그 문서는 계약 부속서류일 뿐 관리 도구가 아닙니다.

요구사항정의서 완성 9단계 체크리스트

1~7단계는 발주처가, 8단계는 개발사가, 9단계는 양측이 함께 합니다. 3단계와 5단계에 전체 기간의 대부분이 들어갑니다. 요구사항 수집은 부서 간 이해관계가 충돌하는 단계라 기술적으로 어려운 게 아니라 합의가 어렵습니다. 여기에 시간을 배정하지 않으면 나머지 단계가 모두 밀립니다.

발주 문서 전체의 순서와 각 문서의 역할은 외주 개발 산출물 문서 가이드에, 과업 범위를 계약서에 묶는 방법은 과업지시서 작성 가이드에 정리해 두었습니다.

트리숲의 AI-Native 요구사항 정의 방식

트리숲(TreeSoop)은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. 요구사항 정의 단계에서 이 환경이 실제로 바꾸는 것은 문서를 빨리 쓰는 일이 아니라 빈칸을 빨리 찾아내는 일입니다.

발주처가 보내 준 요청 목록을 받으면, 먼저 요구사항 단위로 쪼개 수용 기준이 비어 있는 항목과 검증 방법이 없는 항목을 전수로 표시합니다. 사람이 40개를 읽으면 놓치지만 전수 점검은 놓치지 않습니다. 그다음 그 빈칸만 들고 발주처와 회의합니다. 회의 시간이 "문서를 같이 읽는 시간"에서 "결정이 필요한 항목만 결정하는 시간"으로 바뀝니다.

상세화 회신본에는 항상 발주 원문 열을 남기고, 착수 시점에 추적표를 먼저 만든 뒤 기능정의서·화면설계서를 그 위에 얹습니다. 순서를 이렇게 잡으면 프로젝트 중반에 "이 기능은 어느 요구사항에서 나왔나"를 되묻는 일이 생기지 않습니다. 이런 방식은 트리숲의 AI-Native 개발 방식에서 일관되게 적용하는 원칙입니다.

요구사항정의서를 처음 쓰거나, 받은 문서를 어떻게 검토해야 할지 막막하시다면 AI-Native 개발사 트리숲에 문의해 보세요. 문서 검토만 단독으로도 도와 드립니다. (문의: 카카오톡 채널)

자주 묻는 질문

Q: 요구사항정의서와 요구사항명세서는 꼭 나눠야 하나요?

중소 규모라면 한 문서로 운영해도 됩니다. 다만 발주처가 쓴 원문 열과 개발사가 상세화한 열을 반드시 분리해 두세요. 원문이 사라지면 "요청한 것과 다르다"를 증명할 근거가 없어집니다.

Q: 요구사항이 몇 건쯤 되어야 적정한가요?

건수에 정답은 없지만, 한 요구사항이 개발 기준 2~5일 분량으로 쪼개져 있으면 관리하기 좋습니다. 한 건이 한 달짜리면 진척을 볼 수 없고, 반나절짜리면 문서가 기능 목록이 되어 버립니다. 중소 규모 웹 시스템이면 대체로 60~150건 선에서 정리됩니다.

Q: 요구사항정의서 양식은 어디서 구하나요?

양식 자체는 중요하지 않습니다. 이 글의 12개 항목이 열로 들어간 스프레드시트 한 장이면 충분합니다. 양식을 받아다 쓸 때 가장 흔한 문제는 수용 기준 열이 아예 없는 양식을 쓰는 것입니다. 받은 양식에 그 열이 없으면 직접 추가하세요.

Q: 개발 중에 요구사항이 바뀌면 어떻게 하나요?

바뀌는 것은 정상입니다. 절차만 고정하면 됩니다. ① 상태를 「변경」으로 바꾸고 ② 변경 이력에 일자·요청자·사유를 남기고 ③ 일정·비용 영향이 있으면 그 자리에서 산정해 합의합니다. 공공사업에서 과업 내용이 변경되면 과업심의위원회 심의 대상이 될 수 있으므로, 변경 시점과 근거를 문서로 남기는 것이 특히 중요합니다.

Q: 비기능 요구사항의 숫자를 발주처가 정할 수 없으면요?

개발사에 "권장값과 그 근거를 제시해 달라"고 요청하고, 그 값을 검토해 승인하는 방식으로 진행하세요. 개발사가 제시하고 발주처가 승인한 숫자는 합의된 숫자입니다. 아무도 정하지 않은 상태로 두는 것만 피하면 됩니다.

Q: 요구사항 추적표는 누가 관리하나요?

작성과 갱신은 개발사가 하고, 검토는 발주처가 합니다. 주간 보고에 추적표 갱신본을 포함하는 것을 계약 단계에서 합의해 두면 별도 요청 없이 굴러갑니다. 프로젝트 종료 시점에 한꺼번에 채우면 기록일 뿐 관리 도구가 아닙니다.

정리

요구사항정의서의 품질은 분량이 아니라 검증 가능성과 추적 가능성 두 가지로 결정됩니다.

• 요구사항마다 수용 기준을 적는다 — 「~한 상태에서 ~하면 ~가 된다」
• 비기능 요구사항은 숫자로 적는다 — 형용사는 계약상 효력이 없다
• ID 체계를 먼저 고정하고 재사용하지 않는다 — 추적표의 전제다
• 원문 열을 남긴다 — 상세화 과정에서 해석이 덮어쓰지 않도록
• 추적표를 주간으로 갱신한다 — 빈칸이 곧 리스크다

이 다섯 가지만 지켜도 검수 단계 분쟁의 대부분은 발생하지 않습니다. 요구사항정의서는 프로젝트가 끝난 뒤 서랍에 넣는 문서가 아니라, 진행 중 매주 펼쳐 보는 문서여야 합니다.