소프트웨어 요구공학(Requirement Engineering)
1. 개요
가. 정의
이해관계자의 요구를 도출·분석·명세·검증·관리하는 체계적 절차를 통해, 개발 대상 시스템이 갖춰야 할 요구사항을 정확·완전·일관되게 정의하고 변경까지 통제하는 소프트웨어공학 활동.
요구공학은 "무엇을 만들 것인가(What)"를 규명하는 활동으로, "어떻게 만들 것인가(How)"를 다루는 설계·구현과 구분된다. 즉 문제 공간(problem space)을 정의하는 것이 요구공학의 본질이며, 해 공간(solution space)으로 넘어가기 전에 문제 자체를 정확히 합의하는 단계다. 이 경계가 무너져 요구 단계에서 설계 세부를 미리 확정해 버리면, 더 나은 대안을 검토할 여지가 사라지고 요구가 특정 구현에 종속되어 유연성을 잃는다.
요구공학은 단순한 문서 작성 활동이 아니라 커뮤니케이션과 합의의 공학이다. 이해관계자마다 배경 지식·용어·이해관계가 다르므로, 같은 단어라도 서로 다르게 해석하는 의미의 간극(semantic gap)이 상존한다. 요구공학은 이 간극을 모델·명세·검증이라는 공학적 수단으로 좁혀, 개발팀과 발주자가 "같은 시스템"을 머릿속에 그리도록 만드는 데 그 목적이 있다.
특히 소프트웨어는 눈에 보이지 않는 무형의 산출물이라는 특성 때문에 요구 합의가 더욱 어렵다. 건축이라면 도면과 조감도로 완성될 모습을 미리 공유할 수 있지만, 소프트웨어는 완성되기 전까지 실체를 보기 어려워 이해관계자가 자신의 요구를 구체적으로 표현하지 못한다. 요구공학이 모델·프로토타입 같은 가시화 수단을 강조하는 이유가 여기에 있다.
나. 등장 배경 및 필요성
소프트웨어 프로젝트 실패의 가장 큰 원인은 코딩 실수가 아니라 "잘못된 것을 제대로 만드는 것", 즉 요구의 오류다. 스탠디시 그룹의 CHAOS 보고서 등 여러 산업 조사에서 프로젝트 실패·지연의 주요 원인으로 불완전한 요구, 요구의 잦은 변경, 이해관계자 참여 부족이 반복적으로 상위에 오른다. 이는 코드 품질보다 요구 품질이 프로젝트의 운명을 먼저 결정한다는 사실을 보여 준다.
요구 결함은 발견이 늦어질수록 수정 비용이 기하급수적으로 커진다. 요구 단계에서 1의 비용으로 고칠 결함이 설계에서 10, 운영에서 100의 비용이 든다는 1:10:100 법칙이 이를 말한다. 그 이유는 결함이 하류(downstream)로 흘러가는 동안 그 결함 위에 설계·코드·테스트·문서가 층층이 쌓이기 때문이다. 운영 중 요구 오류가 드러나면 이미 만들어진 산출물 전체를 되짚어 수정해야 하므로 재작업의 범위가 폭발한다.
또 요구가 모호하면 개발 도중 범위가 계속 바뀌어(스코프 크리프) 재작업이 폭증한다. "관리자용 화면도 필요하죠"처럼 합의되지 않은 요구가 개발 중에 계속 추가되면, 일정과 예산은 그대로인 채 작업량만 늘어 품질이 무너진다. 요구공학은 이런 손실을 막기 위해, 요구를 즉흥적 대화가 아닌 공학적 절차로 다루어 이해관계자 간 합의·추적성을 확보한다. 특히 요구를 베이스라인으로 고정하고 변경을 통제함으로써, "무엇이 계약된 범위인가"를 명확히 해 분쟁과 재작업을 줄인다.
2. 요구공학 절차
요구공학은 다섯 단계가 순차적이면서도, 변경이 생기면 다시 분석으로 돌아가는 반복적 활동이다. 아래 개념도는 전체 절차의 흐름과 변경 피드백 루프를 보여 준다.
flowchart LR
E["도출(Elicitation)"] --> A["분석(Analysis)"]
A --> S["명세(Specification)"]
S --> V["검증(Validation)"]
V --> M["관리(Management)"]
M -.변경 발생.-> A
각 단계는 앞 단계의 산출물을 정제해 최종적으로 신뢰할 수 있는 요구 명세로 수렴시킨다. 아래 상세도는 각 단계가 소비하는 입력과 생산하는 산출물, 그리고 이해관계자·형상관리 도구와의 상호작용을 나타낸다.
flowchart TB
ST["이해관계자"] -->|요구·기대| E2["도출"]
E2 -->|원시 요구 목록| A2["분석/모델링"]
A2 -->|정제·우선순위화된 요구| S2["명세(SRS)"]
S2 -->|SRS 초안| V2["검증(리뷰/프로토타입)"]
V2 -->|승인된 요구| BL["요구 베이스라인"]
BL --> M2["변경관리(CCB/RTM)"]
M2 -.영향분석 후 재분석.-> A2
M2 -->|추적성 링크| RTM["요구추적매트릭스"]
가. 도출(Elicitation) — 이해관계자를 식별하고 그들의 요구·기대를 끌어내는 단계다. 여기서 핵심 난제는 사용자가 자신이 무엇을 원하는지 스스로도 명확히 모른다는 점이다. 이를 암묵지(tacit knowledge) 문제라 하며, 현업 담당자에게는 너무 당연해 굳이 말하지 않는 업무 규칙이 정작 시스템에 반영되지 않아 나중에 결함이 되는 경우가 많다.
따라서 도출은 인터뷰·워크숍 같은 직접 질문 기법만이 아니라, 실제 업무를 곁에서 지켜보는 관찰(observation), 동작하는 모형으로 반응을 끌어내는 프로토타이핑, 기존 문서·로그를 분석하는 기법을 병행해 잠재 요구까지 발굴해야 한다. 예컨대 물류 창고 시스템을 만들 때 담당자 인터뷰만으로는 "바쁠 때 바코드 대신 수기로 적는다"는 예외 흐름이 드러나지 않지만, 현장 관찰로는 즉시 포착된다.
또한 도출 단계에서는 이해관계자 간 요구의 충돌이 처음 드러난다. 영업 부서는 기능의 다양성을, 운영 부서는 안정성을, 재무 부서는 비용 절감을 우선하므로, 도출은 단순 수집이 아니라 서로 다른 관점을 균형 있게 확보하는 과정이 되어야 한다. 특정 목소리 큰 이해관계자에게 편중되면 요구가 왜곡되므로, 이해관계자 지도(stakeholder map)로 관련자를 빠짐없이 식별하는 것이 선행되어야 한다.
나. 분석(Analysis) — 수집한 요구의 상충·중복·모호함을 해소하고, 실현 가능성과 우선순위를 따지는 단계다. 원시 요구는 서로 모순되거나("빠르면서도 싸게"), 같은 요구가 다른 표현으로 중복되거나, "사용하기 편해야 한다"처럼 검증 불가능한 형태로 존재한다. 분석은 이를 정제해 개발 가능한 형태로 다듬는다.
이때 유스케이스·DFD·UML 같은 모델링이 핵심 수단이다. 자연어는 모호하지만 모델은 요구를 구조화해 누락과 모순을 시각적으로 드러낸다. 예컨대 유스케이스 다이어그램을 그리다 보면 "인증되지 않은 사용자가 결제를 시도하면?" 같은 미정의 흐름이 자연스럽게 발견된다. 모델은 이해관계자와의 대화 도구이기도 해서, 그림을 놓고 토론하면 텍스트보다 오해가 줄어든다.
우선순위 결정에는 MoSCoW(Must/Should/Could/Won't) 나 Kano 모델을 쓴다. 모든 요구를 동등하게 다루면 정작 중요한 요구에 자원이 부족해지므로, 반드시 필요한 것(Must)과 있으면 좋은 것(Could)을 구분해야 한다. Kano 모델은 요구를 당연 품질·일원 품질·매력 품질로 나누어, 없으면 불만이지만 있어도 감동은 없는 "당연 요구"와 있으면 만족도가 급상승하는 "매력 요구"를 구별하게 해 준다. 예컨대 은행 앱에서 "이체가 정확히 처리된다"는 당연 요구여서 잘 되어도 칭찬받지 못하지만, "생체인증 3초 로그인"은 매력 요구여서 경쟁 우위가 된다. 한정된 예산에서는 당연 요구를 먼저 완비한 뒤 매력 요구에 투자하는 것이 합리적이다.
실현 가능성 검토도 분석의 핵심이다. 기술적으로 구현 가능한지, 일정·예산 안에서 달성 가능한지, 법·조직 제약과 충돌하지 않는지를 따져 실현 불가능한 요구를 조기에 걸러내야 한다. 이 검토가 부실하면 개발 후반에 "이 요구는 애초에 불가능했다"는 사실이 드러나 대규모 재작업이 발생한다.
다. 명세(Specification) — 합의된 요구를 SRS(요구사항 명세서) 로 문서화하는 단계다. SRS는 개발·테스트·인수의 공통 기준이 되는 계약적 문서이므로, 해석의 여지를 최소화해야 한다. 자연어의 모호성을 줄이기 위해 유스케이스 명세, 사용자 스토리, 필요 시 정형 명세(Z, 상태기계 등) 를 병행한다. 예컨대 금융·항공처럼 안전이 중요한 도메인에서는 정형 명세로 요구를 수학적으로 기술해 모호성을 원천 차단하기도 한다.
명세를 쓸 때는 표현의 일관성도 중요하다. 같은 개념을 문서 곳곳에서 서로 다른 용어로 부르면(예: "회원", "사용자", "가입자") 오해가 생기므로, 용어집(glossary)을 두어 도메인 용어를 통일한다. 또 각 요구에 고유 식별자(REQ-001 등)를 부여해야 이후 추적성 링크를 걸 수 있고, 변경 시 어느 요구가 바뀌었는지 명확히 지목할 수 있다. 식별자 없는 서술형 요구는 관리 단계에서 추적이 불가능해 사실상 통제 밖에 놓인다.
라. 검증(Validation)과 관리(Management) — 검증은 명세가 이해관계자의 실제 요구를 정확·완전·일관되게 담았는지 리뷰·인스펙션·프로토타입으로 확인하는 단계다. 여기서 검증(validation, 올바른 것을 만들고 있는가)과 확인(verification, 명세대로 만들고 있는가)의 구분이 중요하다. 검증에서 놓친 요구 결함은 그대로 하류로 흘러가므로, 검증은 요구공학의 마지막 방어선이다. 프로토타입은 특히 강력한 검증 수단인데, 동작하는 화면을 본 이해관계자가 "이건 내가 생각한 게 아니다"라고 조기에 지적하면 문서로는 잡지 못한 오해를 저비용으로 걸러낼 수 있다.
관리는 확정된 요구를 베이스라인으로 고정하고, 이후 변경을 형상관리·RTM·변경통제위(CCB) 로 통제하는 활동이다. 변경 자체를 막는 것이 아니라, 변경의 영향을 분석하고 합의된 절차로만 반영해 무질서한 변경을 막는 것이 목적이다. CCB는 변경 요청이 들어오면 그 변경이 일정·비용·품질·다른 요구에 미치는 파급을 분석해 승인·보류·기각을 결정하며, 이 절차가 있어야 "누군가의 요청 한마디로 범위가 슬그머니 늘어나는" 스코프 크리프를 제도적으로 차단할 수 있다.
| 단계 | 활동 | 대표 기법 | 주요 산출물 |
|---|---|---|---|
| 도출 | 이해관계자 식별·요구 수집 | 인터뷰, 워크숍, 관찰, 프로토타이핑 | 원시 요구 목록 |
| 분석 | 상충·중복 해소, 우선순위 | 유스케이스, DFD/UML, MoSCoW, Kano | 요구 모델, 우선순위 |
| 명세 | SRS 문서화 | 자연어·정형 명세, 유스케이스 명세 | SRS |
| 검증 | 정확·완전·일관성 확인 | 리뷰·인스펙션, 프로토타입 | 승인된 요구 |
| 관리 | 변경·이력·추적 관리 | 형상관리, RTM, CCB | 베이스라인, RTM |
3. 요구사항 유형
요구를 유형으로 나누는 이유는, 유형마다 검증 방법과 설계 영향이 다르기 때문이다. 기능 요구는 시스템의 행위를 정의하므로 상대적으로 표현·검증이 쉽지만, 비기능 요구는 시스템 전반에 걸쳐 은근히 영향을 미쳐 놓치기 쉬우면서도 아키텍처를 근본적으로 좌우한다.
특히 비기능 요구(NFR)는 아키텍처 결정의 핵심 동인이다. 예컨대 "동시 사용자 1만 명, 응답 2초 이내"라는 성능 요구는 단일 서버로는 달성 불가능해 초기부터 로드밸런싱·캐시·분산 아키텍처를 강제한다. 반대로 이 요구가 명세되지 않은 채 개발이 진행되면, 나중에 성능 문제가 터졌을 때 아키텍처를 통째로 갈아엎어야 하는 최악의 재작업이 발생한다. 그래서 비기능 요구는 "나중에 튜닝하면 되는 것"이 아니라 설계 이전에 확정해야 하는 것이다.
비기능 요구를 체계적으로 도출하려면 품질 특성의 표준 분류를 참조하는 것이 효과적이다. ISO/IEC 25010 제품 품질 모델은 기능 적합성·성능 효율성·호환성·사용성·신뢰성·보안성·유지보수성·이식성의 여덟 특성을 제시하는데, 이 목록을 체크리스트처럼 활용하면 "가용성은 정했는데 유지보수성 목표는 빠졌다"는 식의 누락을 예방할 수 있다. 즉 비기능 요구는 감으로 나열하는 것이 아니라 표준 분류에 비추어 빠짐없이 도출하는 것이 바람직하다.
제약사항은 시스템이 반드시 따라야 하는 외부 조건으로, 개발팀의 선택지를 제한한다. 개인정보보호법·전자금융감독규정 같은 법·규제, 특정 플랫폼·언어, 예산·기한이 여기 속한다. 제약을 요구와 구분해 명시해 두어야, 설계 대안을 검토할 때 애초에 위반되는 안을 걸러낼 수 있다. 제약을 뒤늦게 발견하면 이미 확정한 설계를 폐기해야 하므로, 제약사항 식별은 분석 초기에 완료하는 것이 원칙이다.
| 구분 | 내용 | 예 |
|---|---|---|
| 기능 요구 | 시스템이 수행할 기능·서비스 | 로그인, 주문 처리 |
| 비기능 요구 | 성능·보안·가용성 등 품질속성 | 응답 2초, 99.9% 가용성 |
| 제약사항 | 법·표준·플랫폼·예산 제약 | 개인정보보호법 준수 |
4. 요구사항 명세서(SRS)와 품질 특성
SRS는 목적·범위, 기능/비기능 요구, 인터페이스, 제약조건으로 구성되며, "좋은 요구란 무엇인가"에 대한 품질 특성을 만족해야 한다. 국제 표준 ISO/IEC/IEEE 29148은 좋은 요구가 갖춰야 할 특성으로 필요성·명확성·완전성·일관성·검증가능성·추적가능성 등을 제시한다(과거 널리 쓰이던 IEEE 830-1998을 대체·통합한 표준).
이 특성들이 중요한 이유는, 하나라도 어기면 개발 단계에서 해석 차이·재작업으로 이어지기 때문이다. 예를 들어 "화면이 빨라야 한다"는 요구는 검증 불가능하므로, "메인 화면은 3G 환경에서 2초 이내 로딩"처럼 조건과 정량 기준을 담아 검증 가능하게 써야 한다. 검증가능성이 없으면 인수 시점에 "빠르다/느리다"를 두고 발주자와 개발사가 다투게 된다.
완전성과 일관성은 특히 놓치기 쉽다. 완전성은 정상 흐름뿐 아니라 예외·경계 조건까지 빠짐없이 다루었는가를 뜻한다. "결제 실패 시 어떻게 되는가", "재고가 음수가 되면?" 같은 예외가 명세에서 빠지면 개발자가 임의로 처리해 버그의 씨앗이 된다. 일관성은 요구 간 모순이 없어야 함을 뜻하며, 규모가 커질수록 서로 다른 요구가 충돌할 위험이 커지므로 추적성 관리가 함께 필요하다.
| 특성 | 의미 |
|---|---|
| 완전성 | 필요한 요구를 빠짐없이 포함(예외·경계 포함) |
| 일관성 | 요구 간 상충 없음 |
| 명확성 | 모호하지 않고 단일 해석 가능 |
| 검증가능성 | 테스트로 확인 가능(정량 기준) |
| 추적성 | 상위 요구 |
5. 비교와 적용 사례
요구공학의 실제 모습은 프로젝트 성격에 따라 크게 갈린다. 아래 표는 계획 주도(plan-driven) 방식과 애자일 방식의 요구관리를 비교한 것이다. 두 방식의 차이는 단순한 문서량의 문제가 아니라, "요구를 언제 확정하는가"라는 근본 철학의 차이에서 비롯된다.
| 관점 | 계획 주도(폭포수) | 애자일 |
|---|---|---|
| 요구 확정 시점 | 초기 일괄 확정 | 스프린트마다 점진 확정 |
| 표현 형태 | SRS 문서 | User Story·Backlog |
| 변경 태도 | 통제·최소화 | 수용·환영 |
| 적합 도메인 | 규제·안전 중시(금융·항공·의료) | 시장 불확실성 큰 서비스 |
| 검증 | 리뷰·인스펙션·인수시험 | DoD·인수조건·데모 |
이 차이가 생기는 근본 이유는 변화의 비용 곡선이 도메인마다 다르기 때문이다. 항공 관제처럼 한 번 배포하면 수정이 극히 어렵고 안전 사고로 직결되는 시스템은, 초기에 요구를 완벽히 확정하고 정형 검증까지 거치는 비용이 정당화된다. 반대로 스타트업의 커머스 서비스는 시장 반응을 봐 가며 요구를 계속 바꾸는 편이 유리하므로, 초기 완전 확정은 오히려 낭비가 된다. 따라서 "어느 방식이 옳은가"가 아니라 "이 프로젝트에는 어느 방식이 맞는가"가 요구공학자의 판단 지점이다.
구체적 사례로, 대규모 공공 정보화 사업에서는 발주 단계에서 제안요청서(RFP)와 상세 요구정의서를 확정하고 이를 계약 범위로 삼는다. 이때 요구가 부실하면 사업 수행 중 과업 범위를 둘러싼 분쟁이 빈번하므로, 요구 상세화와 추적성 확보가 사업 성패를 좌우한다. 반면 사내 모바일 서비스 개발에서는 2주 스프린트마다 사용자 피드백을 백로그에 반영하며, 6개월간 요구의 상당수가 초기 정의와 달라지는 것이 정상으로 간주된다. 같은 "요구공학"이지만 운용 방식이 정반대인 셈이다.
6. 심화: 애자일 시대의 요구공학과 최신 동향
전통적 요구공학은 개발 초기에 요구를 한 번에 확정하는 빅뱅(Big Design Up Front) 을 전제했지만, 시장·기술 변화가 빨라지면서 이 전제가 흔들렸다. 요구는 시간이 지나면 반드시 변하는데, 초기에 모든 것을 확정하려는 시도는 오히려 변화를 결함처럼 취급해 마찰을 일으켰다. 이에 애자일은 요구의 변동을 자연스러운 것으로 수용하는 방향으로 패러다임을 전환했다.
애자일에서는 SRS를 한 번에 확정하지 않고 User Story·Product Backlog로 표현해 반복 스프린트마다 점진적으로 정제한다. 각 스토리는 "역할-기능-가치(As a … I want … so that …)" 형태로 쓰이고, 완료의 정의(DoD)와 인수 조건(Acceptance Criteria)으로 검증가능성을 확보한다. 다만 애자일이 요구공학을 없애는 것은 아니다. 도출·분석·검증은 여전히 필요하며, 다만 그 시점이 프로젝트 초기에 몰려 있던 것에서 전 스프린트에 걸쳐 분산된 것뿐이다. 백로그 우선순위 관리, 스토리 정제(refinement) 회의가 곧 상시적 요구공학이다.
최근에는 요구공학의 전문성을 인증하는 IREB CPRE(Certified Professional for Requirements Engineering) 체계가 국제적으로 확산되고, 요구 관리를 지원하는 도구(Jira, DOORS, Polarion 등)가 추적성·영향분석을 자동화하고 있다. 나아가 생성형 AI를 활용해 이해관계자 인터뷰 기록에서 요구 후보를 초안으로 추출하거나, 요구 명세의 모호성·중복을 자동 점검하는 시도가 늘고 있다. 다만 AI가 만든 요구 초안도 결국 사람이 검증·합의해야 하므로, AI는 요구공학자를 대체하기보다 초안 생성과 품질 점검을 돕는 보조 도구로 자리잡는 추세다.
또 하나 주목할 흐름은 모델 기반(model-based) 요구공학이다. 텍스트 SRS 대신 SysML 같은 모델로 요구·구조·행위를 연결해 관리하면, 요구 변경이 설계·시험 모델에 미치는 영향을 자동으로 추적할 수 있다. 특히 자동차·항공처럼 시스템이 복잡하고 안전 인증이 필요한 분야에서 모델 기반 접근이 확산되고 있다. 이는 요구가 더 이상 개발의 앞단에만 있는 정적 문서가 아니라, 전체 개발 생애주기에 걸쳐 살아 움직이는 자산으로 다뤄진다는 관점의 변화를 보여 준다.
7. 고려사항 및 시사점
- 추적성(Traceability) 확보: RTM(요구추적매트릭스)으로 요구-설계-코드-테스트를 양방향으로 연결해 두면, 요구 변경 시 영향 분석이 즉시 되고 누락 없는 테스트가 보장된다. 이것이 품질보증의 핵심 도구이며, 규제 산업(의료기기·항공)에서는 인증을 위해 추적성 증적이 필수로 요구된다.
- 변경관리와 베이스라인: 변경을 무조건 막는 것이 아니라 CCB를 통해 영향(일정·비용·품질)을 분석하고 합의된 것만 반영하는 통제된 변경이 핵심이다. 베이스라인이 없으면 "무엇이 계약 범위인가"가 모호해져 분쟁과 스코프 크리프가 발생한다.
- 방법론에 맞는 요구관리 전략 선택: 요구가 안정적이고 규제가 엄격한 도메인은 문서 기반 SRS와 정형 검증이, 시장 불확실성이 큰 도메인은 백로그 기반 점진적 정제가 유리하다. 획일적 적용이 아니라 프로젝트 특성에 맞춘 트레이드오프 판단이 요구공학자의 역량이다.
- 이해관계자 참여와 합의(사인오프): 결국 요구공학 성공의 토대는 도구가 아니라 사람이다. 이해관계자의 적극 참여와 명시적 합의(사인오프)가 없으면 아무리 잘 쓴 SRS도 "우리가 원한 게 아니다"라는 인수 거부로 무력화된다.
- 비기능 요구의 조기 확정: 성능·보안·가용성 같은 NFR은 아키텍처를 좌우하므로 설계 이전에 정량 기준으로 확정해야 한다. 뒤늦게 드러난 NFR은 아키텍처 전면 재작업이라는 최악의 비용을 부른다.
- AI·자동화의 도입과 검증 책임: 생성형 AI로 요구 초안·모호성 점검을 가속하되, 최종 요구의 정확성·합의 책임은 사람에게 있음을 명확히 해야 한다. 자동 생성 요구를 무비판적으로 수용하면 그럴듯하지만 실제와 다른 요구가 명세에 스며들 수 있으므로, AI는 생산성 도구로 활용하되 검증 게이트는 유지해야 한다.
참고자료
- ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering: https://www.iso.org/standard/72089.html
- IREB (International Requirements Engineering Board): https://www.ireb.org/en/
- SWEBOK Guide V3.0, Software Requirements(Chapter 1), IEEE Computer Society: https://www.computer.org/education/bodies-of-knowledge/software-engineering
한 줄 요약: 요구공학은 도출→분석→명세→검증→관리 절차로 이해관계자 요구를 공학적으로 체계화하고, 완전·일관·명확·검증가능·추적가능한 SRS와 베이스라인·RTM·CCB로 요구 결함과 프로젝트 실패(1:10:100)를 예방하는 활동이며, 애자일에서는 백로그 기반의 점진적 요구 정제로 진화하고 있다.