1장. 소프트웨어는 요구사항에서 시작한다

기능 이름만으로 시작한 프로젝트가 왜 서로 다른 기대와 재작업을 만드는지 살펴보고, 요구사항을 문서가 아닌 공유 지식으로 이해한다.

이번 장에서 해결할 질문

학습 목표

• “기능 이름만 있는 요청을 어떻게 공동의 판단 기준으로 바꿀 수 있는가?”에 답하는 데 필요한 개념과 근거를 설명한다.
• 수강신청 사례에 같은 판단 기준을 적용하고 확인할 빈칸과 다음 행동을 기록한다.

핵심 개념

소프트웨어 프로젝트는 흔히 기능 이름으로 시작한다. “모바일 수강신청을 만들어 주세요”, “신청 화면을 더 빠르게 바꿔 주세요” 같은 요청이 출발점이 된다. 그러나 기능 이름만으로는 누구의 어떤 문제가 해결되어야 하는지, 성공을 무엇으로 판단할지, 지켜야 할 정책과 제약이 무엇인지 알 수 없다. 개발팀이 빈칸을 알아서 채우면 일은 빨리 시작되는 듯 보이지만, 각자가 서로 다른 제품을 상상한 채 달리는 셈이 된다.

이 장에서는 요구사항 활동이 왜 필요한지부터 살펴본다. 핵심은 문서를 많이 만드는 데 있지 않다. 아직 드러나지 않은 필요와 제약을 찾고, 서로 다른 기대를 비교하며, 구현과 시험이 의지할 공통 기준을 만드는 데 있다. 대학 수강신청 시스템의 최초 요청이 설계·코드·시험으로 전달되는 과정을 따라가면서 요구사항 문제와 개발 문제를 구분하고, 요구사항 지식이 생명주기 동안 어떻게 변하는지도 살펴본다.

1. 요구사항은 왜 필요한가

요구사항은 불확실성을 다루기 위해 필요하다. 프로젝트를 시작할 때 모든 사실이 알려져 있는 경우는 드물다. 사용자마다 원하는 결과가 다르고, 조직의 정책은 문서와 실제 업무에서 다르게 작동하며, 기존 시스템의 제약은 뒤늦게 발견되기 쉽다. 요구사항 활동은 이 불확실성을 없애겠다고 약속하는 일이 아니다. 중요한 불확실성이 무엇인지 드러내고, 언제 누구와 어떤 증거로 판단할지를 정하는 일이다.

대학이 “학생들이 편하게 수강신청할 수 있는 시스템”을 원한다고 해 보자. 이 문장은 방향은 알려 주지만 개발 기준으로는 부족하다. ‘편하다’는 말이 모바일 접속을 뜻하는지, 원하는 강좌를 빨리 찾는 것을 뜻하는지, 신청 성공 여부를 즉시 아는 것을 뜻하는지 알 수 없다. 정원이 찬 강좌를 어떻게 처리할지, 선수과목과 시간표 충돌을 누가 판정할지, 졸업예정자에게 우선권이 있는지도 보이지 않는다. 이 상태에서 화면부터 그리면 화면의 빈칸을 설계자가 임의로 채우게 된다.

요구사항 활동은 이 요청을 판단 가능한 질문으로 바꾼다.

이 질문에 답하는 동안 프로젝트는 ‘무엇을 만들 것인가’보다 먼저 ‘왜 바꾸는가’와 ‘무엇을 지켜야 하는가’를 배운다. 아키텍트는 부하와 장애 대응의 기준을 얻고, 개발자는 예외 동작을 알며, 시험 담당자는 기대 결과를 만들 수 있다. 운영자는 변경 시 지켜야 할 정책을 확인하고, 발주자와 사용자는 결과가 약속과 같은지 판단할 수 있다.

2. 요구사항이 잘못되면 무엇이 잘못되는가

요구사항 오류는 한 문장에 머물지 않는다. 하나의 요구는 여러 설계 결정으로 나뉘고, 설계 결정은 코드와 데이터 구조, 인터페이스, 시험 사례로 퍼진다. SWEBOK Guide V4.0a의 Software Requirements 지식 영역도 누락되거나 잘못 해석된 요구가 뒤 단계의 여러 결정에 연쇄적인 재작업을 일으킬 수 있다고 설명한다. 여기서 중요한 것은 특정 배수의 비용 통계를 외우는 일이 아니라 오류가 전파되는 구조를 이해하는 것이다.

수강신청 팀이 “정원이 남아 있으면 신청을 승인한다”는 규칙만 구현했다고 하자. 실제 규정에는 선수과목 이수, 시간표 중복, 학기 최대 학점, 특정 학과 우선 배정이라는 조건이 더 있다. 이 누락은 다음과 같이 퍼질 수 있다.

1. 신청 화면은 모든 학생에게 같은 신청 버튼을 보여 준다.
2. API는 정원만 확인하고 신청 레코드를 만든다.
3. 데이터베이스에는 거절 사유나 예외 승인 근거를 남길 필드가 없다.
4. 시험은 정원 초과만 확인하므로 선수과목과 시간표 오류를 발견하지 못한다.
5. 개강 직전 교무처가 잘못 승인된 신청을 수작업으로 취소한다.
6. 학생의 졸업 계획과 강의실 배정, 등록금 정산까지 영향을 받는다.

처음에는 업무 규칙 한 줄의 누락이었지만, 발견 시점에는 화면·API·데이터·시험·운영 절차를 함께 고쳐야 한다. 이미 사용자에게 결과가 통지되었다면 기술 수정만으로 끝나지 않는다. 정책 책임자의 판단, 학생 안내, 예외 처리와 감사 기록이 필요하다.

요구사항 오류에는 누락만 있는 것이 아니다. 같은 문장을 서로 다르게 이해하는 모호성, 실제 필요와 맞지 않는 부적절성, 다른 요구와 함께 만족할 수 없는 충돌, 현실적인 비용과 기술로 달성할 수 없는 비현실성도 있다. “신청 결과를 즉시 알려야 한다”는 문장은 ‘즉시’의 시간 기준이 없어서 모호하다. “모든 신청을 절대 실패 없이 처리한다”는 문장은 장애와 네트워크 단절을 고려하면 검증할 수 없거나 비현실적일 수 있다. “모든 학생에게 선착순을 적용한다”와 “졸업예정자에게 우선권을 준다”는 두 문장은 정책 해석에 따라 충돌한다.

3. 요구사항 문제와 개발 문제의 차이

요구사항 문제는 무엇을 만족해야 하는지에 관한 문제다. 개발 문제는 합의된 요구를 어떤 구조와 기술로 실현할지에 관한 문제다. 둘은 긴밀하게 연결되지만 같은 질문은 아니다. 이를 구분하지 못하면 기술적으로 훌륭한 해결책으로 잘못된 문제를 풀거나, 구현 결함을 요구사항 탓으로 돌리게 된다.

다음 예를 비교해 보자.

경계가 항상 고정된 것은 아니다. 상위 팀이 “개인정보는 국내 리전에만 저장한다”고 결정하면 전체 프로젝트에는 제약 요구사항이다. 저장소를 담당하는 하위 팀에는 선택 범위를 제한하는 입력이 된다. 반대로 아키텍트가 내부 검토를 통해 특정 데이터베이스를 선택했다면 전체 프로젝트 관점에서는 설계 결정이다. 같은 문장도 누가 누구에게 어떤 책임을 부여하는지에 따라 요구사항이 되거나 설계 결정이 될 수 있다.

분류할 때는 세 가지 질문이 유용하다.

• 이 문장은 해결해야 할 필요나 반드시 만족할 결과를 말하는가, 아니면 실현 방법을 선택하는가?
• 이 결정을 승인할 권한은 업무·정책 책임자에게 있는가, 기술 책임자에게 있는가?
• 대안을 바꾸어도 상위 목적과 수용 기준을 만족할 수 있는가?

“모바일 앱을 만든다”는 말은 대체로 해결책을 먼저 고른 문장이다. 장소와 관계없이 신청 상태를 확인해야 한다는 필요는 반응형 웹, 모바일 앱, 알림 서비스 등 여러 대안으로 충족할 수 있다. 반면 법이나 계약이 특정 접근 채널을 요구하거나 이미 승인된 제품 범위가 모바일 앱이라면 그 문장은 프로젝트에 주어진 제약이 될 수 있다. 핵심은 문장 모양이 아니라 출처, 책임, 대안의 존재와 결정 근거다.

4. 요구사항 없는 개발이 가능한가

명시적인 요구사항 문서 없이 개발하는 일은 가능하다. 한 사람이 자기 문제를 해결하는 짧은 스크립트를 만들거나, 폐기할 탐색용 프로토타입을 작성하거나, 같은 공간에서 일하는 작은 팀이 매우 짧은 피드백 주기로 제품을 개선할 때는 무거운 문서가 오히려 흐름을 방해할 수 있다. 그러나 문서가 없다는 말과 요구사항이 없다는 말은 다르다. 개발자가 머릿속으로 기대하는 결과, 사용자가 데모에서 승인하거나 거절하는 기준, 코드에 박힌 정책이 모두 요구의 표현이다.

문제는 요구사항 지식이 사람의 기억과 대화에만 있을 때 생긴다. 시간이 지나 담당자가 바뀌면 왜 그런 동작을 만들었는지 알기 어렵다. 서로 다른 시간대와 조직에서 일하면 합의가 전달되지 않는다. 규제나 계약이 있는 프로젝트에서는 승인 근거를 입증하기 어렵다. 운영 중 변경이 발생하면 무엇이 영향을 받는지 찾기 힘들다.

따라서 문서화 수준은 위험에 맞춰 조정해야 한다. 다음 조건이 많을수록 더 명시적인 요구사항 기록이 필요하다.

• 이해관계자와 개발자가 여러 조직에 흩어져 있다.
• 안전, 보안, 개인정보, 회계 또는 법적 책임이 크다.
• 시스템을 오래 운영하고 담당자가 바뀔 가능성이 높다.
• 계약 범위와 검수 기준을 증명해야 한다.
• 여러 팀과 외부 시스템이 같은 요구에 의존한다.
• 변경 비용이 크거나 되돌리기 어렵다.

가벼운 방식에서도 제품 목표, 핵심 업무 규칙, 수용 조건과 중요한 결정의 이유는 남길 수 있다. 형식보다 검색 가능성, 최신성, 책임자와 근거가 중요하다.

애자일 개발도 요구사항을 없애지 않는다. 긴 선행 명세를 줄이고 작은 단위로 발견·구체화·확인하는 시점을 바꿀 뿐이다. SWEBOK은 요구사항 작업을 프로젝트 초기에 한 번 끝내는 활동이 아니라 제품의 수명 동안 다듬어지는 활동으로 설명하며, 생명주기에 맞게 방식을 조정해야 한다고 본다. 빠른 피드백은 기록을 없애는 이유가 아니라 기록할 결정을 더 신중히 고르는 이유다.

5. 요구사항 공학이란 무엇인가

요구사항 공학요구사항 공학요구를 발견·분석·명세·검증·관리하는 체계적인 활동이다.(requirements engineering)은 이해관계자의 필요를 이해하고, 요구사항을 체계적으로 명세하고 관리하여 필요에 맞지 않는 시스템을 만들 위험을 줄이는 활동이다. IREB CPRE 온라인 용어집은 이를 요구사항의 명세와 관리에 대한 체계적이고 규율 있는 접근으로 설명한다. 여기서 ‘공학’은 문서를 복잡하게 만들거나 모든 프로젝트에 같은 절차를 강요한다는 뜻이 아니다. 불확실한 정보를 근거와 검토 가능한 결과로 바꾸는 데 반복 가능한 원칙을 적용한다는 뜻이다.

ISO/IEC/IEEE 29148은 요구사항을 특정 문서 하나가 아니라 시스템과 소프트웨어 제품·서비스의 생명주기 전반에서 수행되는 프로세스와 정보 항목으로 다룬다. 이 표준은 2024년에 재확인되어 2026년 8월 현재 발행된 제2판으로 유효하다. 다만 ISO에서는 이를 대체할 제3판 국제표준안(DIS)이 개발 중이다. 이 책은 확정된 2018판을 기준으로 설명하고, 초안의 내용은 확정 규정처럼 사용하지 않는다.

요구사항 공학의 활동은 다음 질문으로 요약할 수 있다.

이 표는 고정된 폭포식 단계가 아니다. 인터뷰 중 충돌을 발견해 분석할 수 있고, 프로토타입을 확인하다 새로운 필요를 발견할 수 있으며, 설계 과정에서 기술 제약이 드러나 요구를 다시 협상할 수 있다. 활동을 구분하는 이유는 순서를 강제하기 위해서가 아니라 지금 어떤 질문에 답하고 어떤 근거를 남겨야 하는지 분명히 하기 위해서다.

요구사항 공학은 담당자 한 명의 일이 아니다. 업무 책임자, 사용자, 개발자, 시험·운영 담당자가 각자의 지식을 제공해야 한다. 요구사항 전문가는 이들을 연결하고 불일치를 드러내도록 돕는다.

6. 요구사항은 문서가 아니라 지식이다

요구사항을 문서와 동일시하면 두 가지 문제가 생긴다. 첫째, 문서에 적혀 있지 않은 지식을 존재하지 않는 것으로 취급한다. 실제 업무 규칙은 담당자의 판단, 기존 시스템의 예외 처리, 고객 문의와 운영 기록에 흩어져 있다. 둘째, 문서가 완성되면 요구사항 활동도 끝났다고 착각한다. 정책과 사용자, 기술 환경이 바뀌면 어제의 정확한 문서가 오늘의 잘못된 문서가 될 수 있다.

요구사항은 필요와 제약, 결정 근거, 관계에 관한 공유 지식이다. 문장, 표, 모델, 프로토타입, 백로그, 시험 사례는 그 지식을 목적에 맞게 표현한 작업 산출물이다. 어느 한 형식도 전체 지식을 혼자 담지 못한다. 업무 규칙은 결정표가 자연스럽고, 사용자와 시스템의 상호작용은 시나리오가 이해하기 쉬우며, 상태 변화는 상태 모델이 더 정확할 수 있다.

수강신청의 최초 요청을 다음처럼 기록할 수 있다.

최초 요청 기록 0.1
출처: 교무처 학사운영팀과 학생 대표 회의
원문: “학생들이 편하게 수강신청할 수 있어야 한다.”
상태: 요구사항이 아니라 확인이 필요한 요청
알려진 맥락: 신청 시작 직후 문의와 재접속이 집중된다.
미확정 사항: 편의의 의미, 대상 학생, 정원·우선순위 정책, 성공 기준
다음 확인자: 교무처 정책 책임자, 학생지원팀, IT 운영팀

이 기록은 잘 쓴 요구사항이 아니다. 대신 무엇을 알고 무엇을 아직 모르는지 보여 준다. 원문을 보존했기 때문에 나중에 해석이 어떻게 달라졌는지 추적할 수 있고, 다음 질문의 책임자도 알 수 있다. 이후 인터뷰와 분석을 거치면 같은 항목에서 문제, 목표, 사용자 요구사항과 시스템 요구사항이 분리된다.

요구사항 지식의 품질을 판단할 때는 문장만 보지 말고 다음을 함께 확인해야 한다.

• 출처: 이 필요나 제약은 어디서 왔는가?
• 의미: 핵심 용어를 관련자가 같은 뜻으로 이해하는가?
• 상태: 후보, 합의, 구현, 폐기 가운데 어디에 있는가?
• 근거: 왜 필요하며 어떤 목표와 정책을 지원하는가?
• 관계: 상위 필요, 설계, 시험, 변경과 어떻게 연결되는가?
• 책임: 누가 내용을 확인하고 변경을 승인하는가?

문서는 지식을 보존하고 전달하는 강력한 수단이다. 그러나 검토되지 않고 갱신되지 않는 문서는 지식 저장소가 아니라 과거의 가정이 된다. 좋은 요구사항 관리는 ‘문서가 있는가’보다 ‘필요한 사람이 현재의 근거에 접근하고 같은 판단을 할 수 있는가’를 묻는다.

7. 요구사항의 생명주기

요구사항은 한 번 작성되어 고정되는 문장이 아니다. 필요가 발견되기 전에는 존재 이유가 불분명하고, 분석되기 전에는 충돌과 누락을 품고 있으며, 합의된 뒤에는 구현과 시험의 기준이 된다. 운영 중 정책이나 환경이 바뀌면 다시 검토되고, 더 이상 필요하지 않으면 폐기된다. 상태가 바뀔 때마다 내용뿐 아니라 근거와 관계도 함께 바뀐다.

다음 흐름은 요구사항 생명주기를 단순화한 것이다.

기준선(baseline)은 이제 절대 바꿀 수 없다는 표시가 아니다. 특정 시점에 관련자가 동의한 내용을 식별해 이후 변경을 비교할 기준으로 삼는 것이다. 기준선 뒤에도 변경은 가능하지만, 무엇이 왜 바뀌었고 어떤 설계와 시험이 영향을 받는지 관리해야 한다.

예를 들어 분석을 거쳐 다음 사용자 요구사항 후보가 만들어졌다고 하자.

UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자. 학생은 정해진 수강신청 기간에 자신이 신청할 수 있는 강좌를 확인하고, 신청 또는 거절 결과와 이유를 알 수 있어야 한다.

처음에는 ‘신청할 수 있는 강좌’의 조건이 불명확하다. 교무처와 확인하면서 선수과목, 시간표, 최대 학점과 전공 제한이 연결된다. 시스템 요구사항과 기능 요구사항이 파생되고, 화면에는 신청 가능 여부와 거절 이유가 표시된다. 시험 사례는 각 조건의 허용·거절 결과를 확인한다. 이후 졸업예정자 우선 정책이 도입되면 UR-001UR-001 · 사용자 요구신청 가능 강좌와 결과·사유 확인 / 사용자. 자체가 바뀌지 않더라도 하위 규칙과 정렬 방식, 화면, API, 시험이 영향을 받을 수 있다.

따라서 생명주기 관리는 문장 상태를 ‘완료’로 바꾸는 행정 절차가 아니다. 요구가 실제 가치로 이어지는 동안 의도와 구현 사이의 연결을 유지하는 일이다. 요구사항을 발견하는 팀과 구현하는 팀이 다르더라도, 왜 이 기능이 존재하고 어떤 조건에서 올바른지 거슬러 올라갈 수 있어야 한다.

이 장의 판단 기준은 세 가지다. 첫째, 개발을 시작하기 전에 모든 답을 얻었는지가 아니라 중요한 불확실성과 책임자가 드러났는가. 둘째, 요구사항 문제와 개발 문제를 근거에 따라 구분할 수 있는가. 셋째, 문서 형식과 무관하게 의도·출처·상태·관계가 생명주기 동안 보존되는가. 다음 장에서는 이 기준을 바탕으로 요구, 목표, 요구사항, 기능, 정책, 제약, 설계와 시험 조건을 더 정확히 구분한다.

수강신청 사례에 적용

판단 기준과 흔한 오류

직접 해보는 실습

핵심 요약

관련 도구와 다음 경로