요구사항 분석과 UML

🎯 학습 목표

이 강을 마치면 다음을 할 수 있습니다.

• 기능 요구사항, 비기능 요구사항, 제약사항을 정확히 구분하고 예시를 들 수 있습니다.
• UML의 5대 다이어그램(유즈케이스·클래스·시퀀스·상태·활동)의 구성 요소와 표기법을 설명할 수 있습니다.
• 클래스 다이어그램에서 의존·연관·집합·합성·일반화 관계를 구분할 수 있습니다.
• 유즈케이스 다이어그램의 include·extend·generalization 관계를 정확히 설명할 수 있습니다.

📋 요구사항 분류 — 기능·비기능·제약

이 섹션에서는 소프트웨어 개발의 시작점인 요구사항을 올바르게 분류하는 방법을 살펴보겠습니다.

요구사항(Requirement)은 이해관계자가 시스템으로부터 원하는 것을 명세한 것입니다. 요구사항을 정확히 분석하지 않으면 아무리 훌륭한 기술로 개발해도 "잘못된 것을 올바르게 만든" 결과가 됩니다. 요구사항은 크게 세 가지로 분류됩니다.

기능 요구사항(Functional Requirement)은 시스템이 무엇을 해야 하는가를 정의합니다. 사용자가 시스템과 상호작용하며 경험하는 기능들입니다. 예: "회원은 이메일과 비밀번호로 로그인할 수 있어야 한다", "관리자는 사용자 목록을 엑셀로 내보낼 수 있어야 한다", "시스템은 결제 완료 시 이메일을 발송해야 한다". 기능 요구사항은 유즈케이스로 표현되며, 테스트로 충족 여부를 확인할 수 있습니다.

비기능 요구사항(Non-functional Requirement)은 시스템이 어떻게 동작해야 하는가를 정의합니다. 품질 속성이라고도 합니다. 예: "시스템은 1,000명의 동시 접속자를 처리할 수 있어야 한다(성능)", "시스템의 가용성은 99.9% 이상이어야 한다(신뢰성)", "사용자의 개인정보는 AES-256으로 암호화되어야 한다(보안)", "시스템의 응답 시간은 2초 이내여야 한다(성능)". 비기능 요구사항은 종종 기능 요구사항보다 구현이 더 어려우며, 아키텍처 결정에 큰 영향을 미칩니다.

제약사항(Constraint)은 설계나 구현 선택을 제한하는 조건입니다. 예: "시스템은 오픈소스 데이터베이스만 사용해야 한다", "모든 API는 RESTful 방식으로 구현해야 한다", "서비스는 클라우드 환경에서만 운영해야 한다". 기출에서는 세 가지를 혼동하도록 보기를 구성하는 경우가 많습니다. 기능 요구사항 = 무엇을 / 비기능 요구사항 = 얼마나 잘 / 제약사항 = 어떤 조건 아래서로 기억하면 구분이 쉽습니다.

요구사항 분석의 핵심 도구인 요구사항 명세서(SRS, Software Requirements Specification)는 모든 요구사항을 정형화된 형식으로 문서화한 것입니다. 좋은 요구사항의 특성을 SMART로 기억할 수 있습니다: 명확성(Specific), 측정가능성(Measurable), 달성가능성(Achievable), 관련성(Relevant), 추적가능성(Traceable).

🔷 UML이란 무엇인가

이 섹션에서는 소프트웨어 시스템을 시각적으로 모델링하는 표준 언어인 UML의 개념과 다이어그램 분류를 살펠보겠습니다.

UML(Unified Modeling Language)은 객체지향 소프트웨어 시스템을 시각적으로 표현하기 위한 표준 모델링 언어입니다. 1997년 OMG(Object Management Group)가 표준으로 채택했으며, 그래디 부치·제임스 럼보·이바 야콥슨의 방법론을 통합해 만들어졌습니다. UML은 "프로그래밍 언어"가 아닌 "모델링 언어"입니다. 코드를 작성하는 것이 아니라 시스템의 구조와 동작을 다이어그램으로 표현합니다.

UML 다이어그램은 크게 두 가지로 분류됩니다. 구조 다이어그램(Structure Diagram)은 시스템의 정적 구조를 표현합니다(클래스·객체·컴포넌트·배포 다이어그램 등). 행위 다이어그램(Behavior Diagram)은 시스템의 동적 동작을 표현합니다(유즈케이스·시퀀스·상태·활동 다이어그램 등). 정보처리기사 시험에서는 유즈케이스·클래스·시퀀스·상태·활동 다이어그램이 집중적으로 출제됩니다.

👤 유즈케이스 다이어그램

이 섹션에서는 시스템과 외부 행위자 간의 상호작용을 표현하는 유즈케이스 다이어그램을 살펴보겠습니다.

유즈케이스 다이어그램(Use Case Diagram)은 시스템이 제공하는 기능(유즈케이스)과 그 기능을 사용하는 외부 행위자(Actor) 간의 관계를 표현합니다. 요구사항 분석 단계에서 주로 작성되며, 기술적 세부사항 없이 "누가 무엇을 한다"를 표현하는 것이 목적입니다.

구성 요소를 살펴보겠습니다. 행위자(Actor)는 시스템 외부에서 시스템과 상호작용하는 존재입니다. 사람(회원, 관리자)이나 외부 시스템(결제 서버, SMS 서버) 모두 행위자가 될 수 있습니다. 막대 인형 아이콘으로 표현합니다. 유즈케이스(Use Case)는 시스템이 행위자에게 제공하는 기능 단위입니다. 타원으로 표현하며, 능동형 동사로 명명합니다(예: "로그인", "상품 검색", "결제하기"). 시스템 경계(System Boundary)는 직사각형으로 시스템 내부와 외부를 구분합니다.

유즈케이스 간 관계가 기출의 핵심입니다.

관계	표기	의미	예시
포함(include)	점선 화살표 + <<include>>	기본 유즈케이스가 반드시 포함 유즈케이스를 실행	로그인 →<<include>>→ 비밀번호 확인
확장(extend)	점선 화살표 + <<extend>>	특정 조건에서 선택적으로 확장 유즈케이스 실행	주문하기 ←<<extend>>← 쿠폰 적용
일반화(generalization)	실선 화살표(빈 삼각형)	상위 유즈케이스를 하위 유즈케이스가 상속	결제하기 ← 카드결제, 계좌이체

include와 extend의 혼동이 가장 많은 기출 함정입니다. include는 항상 실행(필수), extend는 조건부 실행(선택)으로 기억하세요. 화살표 방향도 중요합니다. include는 기본 유즈케이스에서 포함 유즈케이스로 향하고, extend는 확장 유즈케이스에서 기본 유즈케이스로 향합니다.

🏗️ 클래스 다이어그램 — 관계 5종

이 섹션에서는 객체지향 시스템의 정적 구조를 표현하는 클래스 다이어그램의 관계 표기법을 살펴보겠습니다.

클래스 다이어그램(Class Diagram)은 시스템을 구성하는 클래스와 클래스 간의 관계를 표현하는 구조 다이어그램입니다. 클래스는 세 구획(이름/속성/오퍼레이션)으로 구성된 직사각형으로 표현합니다. 접근 제어자는 +(public), -(private), #(protected), ~(package)로 표기합니다.

클래스 간 관계 5종이 기출에서 반복적으로 출제됩니다.

관계	표기	설명	생명주기
의존(Dependency)	점선 화살표	한 클래스가 다른 클래스를 일시적으로 사용	독립적
연관(Association)	실선 (화살표 선택)	두 클래스가 구조적으로 연결(참조 보유)	독립적
집합(Aggregation)	실선 + 빈 마름모	전체-부분 관계, 부분이 독립 존재 가능	부분이 독립
합성(Composition)	실선 + 채운 마름모	강한 전체-부분 관계, 부분이 독립 불가	전체와 함께 소멸
일반화(Generalization)	실선 + 빈 삼각형	상속 관계(IS-A 관계)	해당 없음

집합과 합성의 차이가 가장 자주 출제되는 포인트입니다. 예를 들어 학교와 학생의 관계는 집합입니다(학교가 없어져도 학생은 존재). 반면 집과 방의 관계는 합성입니다(집이 없어지면 방도 존재할 수 없음). 마름모는 항상 전체 쪽에 붙습니다.

⏱️ 시퀀스·상태·활동 다이어그램

이 섹션에서는 시스템의 동적 행위를 표현하는 세 가지 행위 다이어그램을 살펴보겠습니다.

시퀀스 다이어그램(Sequence Diagram)은 객체들 사이의 메시지 교환을 시간 순서에 따라 표현하는 다이어그램입니다. 가로축은 참여 객체(생명선, Lifeline), 세로축은 시간 흐름을 나타냅니다. 객체 간 화살표는 메시지(메서드 호출)를 표현합니다. 실선 화살표는 동기 메시지(응답 대기), 점선 화살표는 반환 메시지, 점선 화살표 끝이 열린 것은 비동기 메시지입니다. 객체가 활성화된 기간을 활성화 막대(Activation Bar)로 표현합니다. 로그인 프로세스나 결제 처리 흐름을 표현할 때 주로 사용됩니다.

상태 다이어그램(State Diagram)은 하나의 객체가 생명주기 동안 거치는 상태와 상태 전환을 표현합니다. 특정 이벤트나 조건에 따라 상태가 어떻게 변하는지 보여줍니다. 구성 요소는 상태(둥근 직사각형), 전환(화살표+이벤트[조건]/액션), 시작 상태(채운 원), 종료 상태(채운 원+원)입니다. 주문 상태(주문접수→결제완료→배송중→배송완료→취소)나 TCP 연결 상태처럼 객체의 상태 변화가 중요한 경우에 사용합니다.

활동 다이어그램(Activity Diagram)은 작업의 흐름(워크플로우)을 표현하는 다이어그램입니다. 순서도(Flowchart)와 유사하지만 객체지향 관점에서 병렬 처리, 분기, 합류를 더 명확히 표현합니다. 구성 요소는 활동(둥근 직사각형), 시작(채운 원), 종료(채운 원+원), 분기(마름모, 조건 분기), 분할/합류(두꺼운 가로선, 병렬 처리), 수영 레인(Swim Lane, 역할별 구분)입니다. 비즈니스 프로세스나 알고리즘 흐름을 표현할 때 사용합니다.

다이어그램	분류	표현 대상	기출 포인트
유즈케이스	행위	시스템 기능과 행위자 관계	include vs extend 방향과 의미
클래스	구조	클래스 구조와 관계	집합 vs 합성 마름모 차이
시퀀스	행위	객체 간 메시지 교환 순서	동기/비동기 메시지 표기
상태	행위	객체의 상태 전환	상태·전환·이벤트 구분
활동	행위	작업 흐름과 병렬 처리	수영 레인, 분할/합류 표기

📝 핵심 요약

2강에서 배운 내용을 정리해 보겠습니다.

• 요구사항 3분류: 기능(무엇을) / 비기능(얼마나 잘) / 제약(어떤 조건 아래)
• UML include: 항상 실행(필수), 기본 → 포함 방향 / extend: 조건부 실행(선택), 확장 → 기본 방향
• 집합(빈 마름모): 부분 독립 존재 가능 / 합성(채운 마름모): 전체와 함께 소멸
• 시퀀스: 시간순 메시지 / 상태: 단일 객체 상태 전환 / 활동: 업무 흐름·병렬

다음 강인 3강 — 구조적 설계와 모듈화에서는 소프트웨어 설계 품질의 핵심 지표인 응집도(7종)와 결합도(6종)를 완전히 정복합니다. 기출에서 가장 많이 출제되는 단원 중 하나이므로 꼼꼼히 준비하겠습니다!