안녕하세요! 수많은 사용자 요청과 비즈니스 목표 사이에서 제품의 방향키를 잡고 계신 Product Owner(PO), PM 여러분, 그리고 소프트웨어 공학의 체계를 배우는 정보처리기사 수험생 여러분. 오늘은 ‘요구사항’이라는 거대한 퍼즐 조각들을 제자리에 맞추는 핵심 기술, 바로 ‘요구사항 분류’에 대해 이야기해 보겠습니다.
“로그인 기능은 만들었는데, 왜 이렇게 느리고 불안하죠?”, “결제는 되는데, 보안은 괜찮은 건가요?” 프로젝트를 진행하다 보면 이처럼 ‘기능’은 구현되었지만 정작 사용자의 기대를 충족시키지 못하는 경우가 많습니다. 이런 문제의 근원은 대부분 요구사항을 제대로 분류하지 않고, 눈에 보이는 기능적 요구에만 집중했기 때문입니다. 요구사항을 체계적으로 분류하는 것은 단순히 목록을 정리하는 행위가 아닙니다. 이는 제품의 품질을 결정하고, 개발의 우선순위를 정하며, 팀원 모두가 동일한 목표를 향해 나아가게 하는 전략적인 활동입니다. 이 글을 통해 요구사항 분류의 다양한 기준과 그 중요성을 이해하고, 균형 잡힌 제품을 만드는 통찰력을 얻어 가시길 바랍니다.
목차
- 요구사항 분류, 왜 반드시 해야 하는가?
- 가장 중요한 첫 번째 분류: 기능(Functional) vs 비기능(Non-functional) 요구사항
- 기능 요구사항: 시스템이 ‘무엇을’ 해야 하는가?
- 비기능 요구사항: 시스템이 ‘어떻게’ 동작해야 하는가? (품질 속성)
- 비기능 요구사항, 왜 놓치기 쉬울까?
- 관점의 차이: 사용자(User) vs 시스템(System) 요구사항
- 사용자 요구사항: 사용자의 목표와 언어
- 시스템 요구사항: 개발자를 위한 구체적인 지침
- 사용자 요구사항에서 시스템 요구사항으로
- 보이지 않는 제약: 프로젝트(Project) 및 외부(External) 요구사항
- 성공적인 제품 개발을 위한 제언: 균형 잡힌 분류의 중요성
요구사항 분류, 왜 반드시 해야 하는가?
요구사항 개발 프로세스를 통해 수많은 요구사항을 도출하고 나면, 우리는 뒤죽박죽 섞인 아이디어와 요청의 홍수 속에 놓이게 됩니다. 이 상태로는 무엇이 더 중요하고 시급한지, 어떤 것이 제품의 핵심이고 어떤 것이 부가적인 요소인지 판단하기 어렵습니다. 요구사항을 체계적으로 분류하는 것은 바로 이 혼돈에 질서를 부여하는 과정입니다.
요구사항을 분류하면 첫째, 제품의 전체적인 그림을 입체적으로 이해할 수 있습니다. 시스템의 기능뿐만 아니라 성능, 보안, 사용성 등 다양한 품질 속성을 균형 있게 고려하여 제품의 완성도를 높일 수 있습니다. 둘째, 합리적인 우선순위 설정이 가능해집니다. 모든 요구사항을 동시에 만족시킬 수는 없기에, 분류된 카테고리를 바탕으로 비즈니스 가치와 개발 비용을 고려하여 무엇을 먼저 개발할지 전략적인 결정을 내릴 수 있습니다. 마지막으로, 팀 내 의사소통이 명확해집니다. 각 요구사항의 성격을 명확히 정의함으로써 기획자, 개발자, 테스터 등 모든 이해관계자가 동일한 목표를 공유하고 오해를 줄일 수 있습니다.
가장 중요한 첫 번째 분류: 기능(Functional) vs 비기능(Non-functional) 요구사항
요구사항을 분류하는 가장 기본적이고 중요한 기준은 ‘기능 요구사항’과 ‘비기능 요구사항’으로 나누는 것입니다. 이 둘을 명확히 구분하고 이해하는 것만으로도 프로젝트의 많은 문제를 예방할 수 있습니다.
기능 요구사항: 시스템이 ‘무엇을’ 해야 하는가?
기능 요구사항(Functional Requirements)은 시스템이 사용자에게 제공해야 하는 구체적인 기능이나 서비스, 즉 ‘무엇(What)’을 하는지에 대한 정의입니다. 사용자가 시스템을 통해 특정 목표를 달성하기 위해 수행하는 행동이나 정보 처리 내용이 여기에 해당합니다. 기능 요구사항은 일반적으로 “시스템은 ~해야 한다” 또는 “~할 수 있어야 한다”의 형태로 기술됩니다.
예를 들어, 온라인 쇼핑몰 시스템의 기능 요구사항은 다음과 같을 수 있습니다.
- 사용자는 상품을 검색할 수 있어야 한다.
- 사용자는 상품을 장바구니에 담거나 뺄 수 있어야 한다.
- 시스템은 사용자의 결제를 처리하고 주문을 기록해야 한다.
- 관리자는 상품 정보를 등록하고 수정할 수 있어야 한다.
이처럼 기능 요구사항은 우리가 흔히 ‘기능 명세’라고 부르는 것들의 기반이 되며, 사용자가 시스템과 상호작용하는 핵심적인 부분입니다. 따라서 비교적 식별하기 쉽고, 이해관계자들도 명확하게 요구하는 경향이 있습니다.
비기능 요구사항: 시스템이 ‘어떻게’ 동작해야 하는가? (품질 속성)
비기능 요구사항(Non-functional Requirements)은 시스템이 특정 기능을 수행할 때 ‘얼마나 잘(How well)’ 수행해야 하는지에 대한 요구사항입니다. 즉, 기능 자체보다는 시스템의 전반적인 품질, 성능, 보안, 사용성, 신뢰성 등과 같은 특성을 정의합니다. 이는 기능 요구사항이 만족스럽게 동작하기 위한 제약 조건이나 기준으로 작용합니다.
비기능 요구사항은 다양한 카테고리로 나눌 수 있으며, 대표적인 예는 다음과 같습니다.
- 성능 (Performance): 시스템의 처리 속도나 응답 시간. (예: 상품 검색 결과는 2초 이내에 표시되어야 한다.)
- 보안 (Security): 비인가된 접근이나 데이터 유출로부터 시스템을 보호하는 능력. (예: 사용자의 비밀번호는 복호화 불가능한 방식으로 암호화하여 저장해야 한다.)
- 사용성 (Usability): 사용자가 시스템을 얼마나 쉽고 편리하게 사용할 수 있는지. (예: 사용자는 3번의 클릭만으로 상품 결제를 완료할 수 있어야 한다.)
- 신뢰성 (Reliability): 시스템이 장애 없이 얼마나 안정적으로 오랫동안 운영될 수 있는지. (예: 시스템은 99.9%의 가용성을 보장해야 한다.)
- 확장성 (Scalability): 사용자나 데이터가 증가했을 때 시스템이 원활하게 대응할 수 있는 능력. (예: 시스템은 동시에 10,000명의 사용자가 접속해도 성능 저하가 없어야 한다.)
| 구분 | 기능 요구사항 (Functional) | 비기능 요구사항 (Non-functional) |
| 정의 | 시스템이 제공해야 할 기능 (What) | 기능이 동작하는 방식, 시스템의 품질 (How well) |
| 초점 | 시스템의 행동, 서비스 | 시스템의 속성, 제약조건 |
| 예시 | 사용자는 로그인할 수 있다. | 로그인 시도는 3초 이내에 응답해야 한다. |
| 검증 | 기능이 동작하는가? (O/X) | 성능, 보안 기준을 만족하는가? (측정, 평가) |
비기능 요구사항, 왜 놓치기 쉬울까?
많은 프로젝트에서 비기능 요구사항은 간과되기 쉽습니다. 사용자는 “로그인하게 해주세요”라고 말하지만, “로그인이 3초 안에 되면서 안전하게 처리되어야 해요”라고 구체적으로 말하는 경우는 드뭅니다. 비기능 요구사항은 당연하게 여겨지거나, 기술적인 영역으로 치부되어 요구사항 도출 단계에서 누락되는 경우가 많습니다. 하지만 아무리 뛰어난 기능을 갖췄더라도, 시스템이 느리고 불안정하며 사용하기 어렵다면 아무도 사용하지 않을 것입니다. 따라서 Product Owner와 분석가는 사용자의 암묵적인 기대를 적극적으로 파악하고, 이를 측정 가능한 비기능 요구사항으로 정의하는 노력을 기울여야 합니다.
관점의 차이: 사용자(User) vs 시스템(System) 요구사항
요구사항을 바라보는 관점에 따라 사용자 요구사항과 시스템 요구사항으로 나눌 수도 있습니다. 이는 요구사항의 상세화 수준(Level of Detail)과 관련이 깊습니다.
사용자 요구사항: 사용자의 목표와 언어
사용자 요구사항(User Requirements)은 사용자의 관점에서 작성된 상위 수준의 요구사항입니다. 사용자가 시스템을 통해 달성하고자 하는 목표나 필요한 서비스가 자연어(일상 언어)로 기술됩니다. 주로 비즈니스 관리자, 최종 사용자 등 비기술적인 이해관계자들이 이해하기 쉽도록 작성됩니다. 사용자 요구사항은 시스템의 세부적인 동작 방식보다는 ‘무엇을 원하는지’에 초점을 맞춥니다.
예를 들어, 다음과 같은 것들이 사용자 요구사항에 해당합니다.
- “강의를 듣다가 궁금한 점을 바로 강사에게 질문하고 싶어요.”
- “내가 관심 있을 만한 다른 강의들을 추천받았으면 좋겠어요.”
- “모바일에서도 끊김 없이 편하게 강의를 보고 싶어요.”
시스템 요구사항: 개발자를 위한 구체적인 지침
시스템 요구사항(System Requirements)은 사용자 요구사항을 개발자가 이해하고 구현할 수 있도록 기술적인 용어와 형식으로 상세하게 풀어쓴 요구사항입니다. 시스템이 제공해야 할 서비스와 제약 조건에 대해 훨씬 더 구체적이고 정밀하게 기술됩니다. 이는 사용자 요구사항을 어떻게 구현할 것인지에 대한 구체적인 설계의 출발점이 됩니다.
사용자 요구사항에서 시스템 요구사항으로
하나의 사용자 요구사항은 여러 개의 구체적인 기능 및 비기능 시스템 요구사항으로 분해될 수 있습니다. 앞서 예로 든 사용자 요구사항 “내가 관심 있을 만한 다른 강의들을 추천받았으면 좋겠어요”는 다음과 같은 시스템 요구사항들로 구체화될 수 있습니다.
- [기능] 시스템은 사용자의 수강 이력 및 검색 기록을 분석해야 한다.
- [기능] 시스템은 분석된 데이터를 기반으로 사용자에게 개인화된 강의 추천 목록을 생성해야 한다.
- [기능] 시스템은 메인 페이지와 강의 상세 페이지에 추천 목록을 노출해야 한다.
- [비기능] 추천 알고리즘은 24시간 주기로 업데이트되어야 한다. (성능/신선도)
- [비기능] 추천 목록은 페이지 로딩 시 1초 이내에 함께 표시되어야 한다. (성능)
이처럼 사용자 요구사항은 ‘문제’를 정의하고, 시스템 요구사항은 그 문제를 해결하기 위한 ‘솔루션’을 구체화하는 역할을 합니다. Product Owner는 사용자 요구사항을 명확히 정의하여 제품의 방향성을 제시하고, 이를 개발팀과 함께 상세한 시스템 요구사항으로 전환하는 과정에서 중요한 다리 역할을 수행해야 합니다.
보이지 않는 제약: 프로젝트(Project) 및 외부(External) 요구사항
기능/비기능, 사용자/시스템 요구사항 외에도 프로젝트 자체의 제약 조건이나 외부 환경에서 비롯되는 요구사항들이 존재합니다. 이들은 제품의 개발 방식과 범위에 직접적인 영향을 미칩니다.
- 프로젝트 요구사항 (Project Requirements): 프로젝트의 예산, 일정, 투입 인력, 사용해야 하는 특정 기술 스택(예: 반드시 Java와 Oracle DB를 사용해야 함) 등 프로젝트 관리 및 수행과 관련된 제약 조건들입니다.
- 외부 요구사항 (External Requirements): 기업 외부에서 발생하는 법률, 규제, 표준 등을 준수해야 하는 요구사항입니다. 예를 들어, 개인정보보호법(PIPA), 정보통신망법, 전자상거래법 등은 IT 시스템 개발 시 반드시 지켜야 하는 강력한 외부 요구사항입니다. 또한, 특정 산업 표준이나 품질 인증(예: ISO 27001 정보보안 인증) 요구사항도 여기에 포함될 수 있습니다.
이러한 제약 조건들은 종종 타협이 불가능한 경우가 많으므로, 프로젝트 초기 단계에서 명확하게 식별하고 모든 이해관계자가 공유해야 합니다.
성공적인 제품 개발을 위한 제언: 균형 잡힌 분류의 중요성
지금까지 살펴본 것처럼, 요구사항은 다양한 기준으로 분류될 수 있으며 각 분류는 고유한 목적을 가집니다. 성공적인 제품을 만들기 위해서는 이 모든 분류를 종합적으로 고려하여 균형 잡힌 시각을 유지하는 것이 중요합니다.
기능 요구사항에만 매몰되지 말고, 제품의 품질과 사용자 경험을 결정하는 비기능 요구사항을 적극적으로 정의하고 관리해야 합니다. 사용자의 목소리인 사용자 요구사항에서 출발하되, 개발팀이 명확하게 일할 수 있도록 구체적인 시스템 요구사항으로 변환하는 노력을 게을리해서는 안 됩니다. 또한, 우리가 마음대로 바꿀 수 없는 프로젝트와 외부의 제약 조건을 명확히 인지하고 그 안에서 최적의 해결책을 찾아야 합니다.
요구사항 분류는 단순히 문서를 정리하는 행정적인 업무가 아닙니다. 이는 제품의 본질을 꿰뚫어 보고, 한정된 자원 속에서 최상의 가치를 만들어내기 위한 고도의 전략적 활동입니다. 체계적인 분류를 통해 요구사항의 우선순위를 정하고 로드맵을 그릴 때, 비로소 우리의 프로젝트는 실패의 위험을 줄이고 성공을 향해 나아갈 수 있을 것입니다.