AP22 — 요구사항, UML, 객체 지향 설계
응용정보기술자시험 과목 A에 필요한 기능·비기능 요구사항, 양방향 추적성, 유스케이스·클래스·시퀀스·상태 머신 다이어그램, 다중성 읽기, 캡슐화·다형성, 응집도·결합도를 도서 대출 예제와 오리지널 연습 문제 5문항으로 익힙니다.
AP 과목 A 제22편 · 2026년도·실라버스 Ver.7.2 기준의 독립 학습 자료입니다. IPA와 제휴하지 않으며 합격을 보장하지 않습니다. 시리즈 허브 보기
개정 및 출처 확인일: 2026-10-21
학습 인덱스와 출제 범위 매핑
이 회차는 각 산출물이 필요한 이유를 잃지 않으면서 요구사항을 설계로 연결한다. 아래 페이지는 공식 IPA 실러버스의 PDF 페이지와 하단 인쇄 페이지를 구분한다.
| 학습 인덱스 | IPA Ver.7.2 위치 | 이 글의 범위 |
|---|---|---|
| 1. 요구사항 | PDF 62 / 인쇄 58 | 시스템 경계, 기능·성능·기타 기능/비기능 요구사항, 평가와 리뷰 |
| 2. 추적성 | PDF 63 / 인쇄 59 | 양방향 추적성, 요구사항 속성에서 소프트웨어 요소·테스트 케이스·정보 항목까지의 추적, 추적성 매트릭스, 유스케이스, UML |
| 3. UML 관점 | PDF 64 / 인쇄 60 | 요구사항 리뷰, 유스케이스·클래스·상태 머신·시퀀스 다이어그램 |
| 4. 요구사항과 설계의 경계 | PDF 65 / 인쇄 61 | 상태 전이도/표, 기능/비기능 설계 |
| 5. 객체 지향 설계 | PDF 68 / 인쇄 64 | 클래스, 캡슐화, 서브클래스, 상속, 다형성, 연관, 일반화/특수화, 분해, 집약 |
| 6. 모듈 설계 | PDF 69 / 인쇄 65 | 응집도, 결합도, 모듈 독립성, 데이터 결합, 제어 결합 |
AP22의 범위는 요구사항, UML, 객체 지향 설계다. AP23은 테스트, 품질, 개발 방법을 다루며, 여기서는 언급만 한 테스트 설계를 그때 자세히 학습한다. AP24는 프로젝트 관리, AP25는 서비스 관리, AP26은 감사·내부 통제·보안 관리다.
공통 용어표
아래 표는 세 언어 글에서 의도적으로 바이트 단위까지 동일하다.
| English | Korean | Japanese |
|---|---|---|
| functional requirement | 기능 요구사항 | 機能要件 |
| non-functional requirement | 비기능 요구사항 | 非機能要件 |
| bidirectional traceability | 양방향 추적성 | 双方向トレーサビリティ |
| traceability matrix | 추적성 매트릭스 | トレーサビリティマトリクス |
| use-case diagram | 유스케이스 다이어그램 | ユースケース図 |
| class diagram | 클래스 다이어그램 | クラス図 |
| sequence diagram | 시퀀스 다이어그램 | シーケンス図 |
| state-machine diagram | 상태 머신 다이어그램 | ステートマシン図 |
| association | 연관 | 関連 |
| multiplicity | 다중성 | 多重度 |
| generalization | 일반화 | 汎化 |
| aggregation | 집약 | 集約 |
| composition | 합성 | コンポジション |
| encapsulation | 캡슐화 | カプセル化 |
| inheritance | 상속 | 継承 |
| polymorphism | 다형성 | 多相性 |
| cohesion | 응집도 | 結束性 |
| coupling | 결합도 | 結合度 |
하나의 예제로 목표부터 설계까지
이 글 전체에서 가상의 도서 대출 시스템을 사용한다.
- R-F01(기능): 자격이 있는 회원은 대출 가능한 도서 복사본을 빌릴 수 있고 시스템은 대출을 기록한다.
- R-N01(비기능): 명시된 가상 시험 조건인 동시 세션 200개에서 도서 검색 응답의 95%가 2.0초 이내에 완료된다. 이는 측정 가능한 기준의 예시이지 IPA 규칙이 아니다.
- 추적성 사슬: 이해관계자 목표 → R-F01 → UC-01 Borrow Copy →
LoanService.borrow와Copy.checkout→ SD-01 → V-F01.
기능 요구사항은 시스템이 제공할 동작을 말한다. 비기능 요구사항은 품질이나 운용을 제약하며 지표와 조건을 명시하면 검증 가능해진다. 양방향 추적성은 산출물에 번호만 붙이는 것이 아니다. 정방향은 영향 분석과 커버리지를, 역방향은 근거와 기원을 확인한다. 추적성 매트릭스는 양쪽 방향을 기록할 수 있다. V-F01은 후속 검증 항목이며 테스트 설계는 AP23에서 본격적으로 다룬다.
상호 보완적인 UML 네 관점
| 다이어그램 | 목적 | 한계 |
|---|---|---|
| 유스케이스 | 외부 액터의 목표와 시스템 경계를 표시 | 내부 메시지 순서나 데이터 구조는 표시하지 않음 |
| 클래스 | 정적인 클래스·속성·연산·관계·다중성을 표시 | 실행 중 시간 순서는 표시하지 않음 |
| 시퀀스 | 한 시나리오의 메시지를 시간순으로 표시 | 가능한 모든 생명주기 상태는 표시하지 않음 |
| 상태 머신(상태) | 한 엔티티의 상태와 이벤트/가드에 따른 전이를 표시 | 객체 구조는 표시하지 않음 |
유스케이스:
[Member] --> (UC-01 Borrow Copy)
[Librarian] --> (UC-02 Register Copy)클래스 관계:
Member "1" -- "0..*" Loan
BookTitle "1" -- "0..*" Copy
Copy "1" -- "0..1" activeLoan: Loan다중성은 연관의 반대쪽 끝을 기준으로 읽는다. 한 끝 옆의 수는 반대쪽 인스턴스 하나에 그 끝의 인스턴스가 몇 개 연결될 수 있는지를 뜻한다. 따라서 Loan마다 Member는 정확히 한 명이고 Member 한 명에는 Loan이 0개 이상 연결될 수 있다. Copy마다 BookTitle은 정확히 하나이고 BookTitle 하나에는 Copy가 0개 이상 연결될 수 있다. 활성 Loan마다 Copy는 정확히 하나이고 Copy 하나에는 활성 Loan이 최대 하나다. 과거 대출은 별도이며 여러 개일 수 있다.
관계 표기에서 연관은 실선, 일반화는 상위 클래스를 가리키는 속이 빈 삼각형, 집약은 전체 쪽의 속이 빈 마름모, 합성은 전체 쪽의 채운 마름모다. 단지 “has-a”라고 해서 집약이나 합성으로 추론할 수 없다. 생명주기와 소유권 의미로 판단해야 하며 보통의 연관이 적절한 경우도 많다.
시퀀스 SD-01:
Member -> UI: requestBorrow
UI -> LoanService: borrow
LoanService -> Copy: checkout
Copy -> Copy: validate Available; status := OnLoan
LoanService -> LoanRepository: save
LoanRepository --> LoanService --> UI --> Member: successCopy 상태 머신:
Available --checkout--> OnLoan
OnLoan --return [undamaged]--> Available
OnLoan --return [damaged]--> Maintenance
Maintenance --repairComplete--> AvailableSD-01은 Copy.checkout 시작 시 상태가 Available일 때만 유효하다. OnLoan에서 두 번째 checkout은 거부해야 한다.
객체 지향과 모듈 구조
- 캡슐화:
Copy.status는 유효한 전이를 강제하는checkout,return,repairComplete같은 연산으로만 바뀐다. - 상속: 하위 유형은 상위 유형의 특성을 이어받아 확장한다. 예를 들어
BookTitle이CatalogItem의 하위 유형이라면 공통 식별자와 제목을 이어받되,BookTitle이CatalogItem자리에 대체 가능할 때만 이 일반화가 타당하다. 상속이 언제나 합성보다 좋은 것은 아니며 대체 가능성, 소유권, 변경 필요에 따라 선택한다. - 다형성:
LoanService는NotificationChannel.send를 호출하고EmailChannel과PushChannel은 하나의 계약 아래 서로 다른 구현을 제공한다. 이는 오버라이딩/런타임 대체이며 같은 이름에 여러 시그니처를 두는 오버로딩과 다르다.
높은 응집도와 낮은 결합도는 일반적으로 유지보수성에 유리하지만 절대적인 보편 법칙도, 그것만으로 충분한 지표도 아니다. LoanService는 관련 없는 보고서/UI 작업 대신 대출 판단과 생명주기에 집중해 응집도를 높인다. NotificationChannel 인터페이스에 의존하면 구체 채널과의 결합을 줄인다. 데이터 결합은 필요한 값을 전달하고, 제어 결합은 다른 모듈의 내부 분기를 지시하는 플래그를 전달한다. 일반적으로 데이터 결합이 제어 결합보다 제약이 적다.
풀이 예 A — 분류, 추적, 변경
- “자격 있는 회원이 대출 가능한 Copy를 빌리고 Loan을 기록한다”는 기능 동작 R-F01이다. “동시 세션 200개에서 검색 응답 95%가 2.0초 이내”는 측정 가능한 비기능 품질 조건 R-N01이며 IPA 기준이 아니다.
- 매트릭스에 양방향으로 목표 ↔ R-F01 ↔ UC-01 ↔
LoanService.borrow/Copy.checkout↔ SD-01 ↔ V-F01을 기록한다. - 규칙이 “연체 대출이 없는 회원만 자격이 있다”로 바뀌면 정방향 영향 분석으로 R-F01, UC-01,
LoanService.borrow의 자격 판단, SD-01(모델링한다면 거부 대안 포함), V-F01을 찾는다. 역방향 추적으로 각 변경 산출물의 존재 이유를 확인한다. 가용성 동작이 그대로라면Copy.checkout과 상태 전이는 검토 대상이나 반드시 변경되지는 않는다. R-N01은 자동으로 영향받지 않는다.
풀이 예 B — 다중성과 동작
Member "1" -- "0..*" Loan에서 Loan 옆 끝을 읽으면 Member 한 명에 Loan이 0개 이상 연결된다. Member 옆 끝을 읽으면 Loan 하나에 Member가 정확히 한 명 연결된다. 이를 뒤집으면 Loan 하나에 회원 여러 명이 가능하다는 오답이 된다. Copy "1" -- "0..1" activeLoan: Loan도 Copy 하나에 활성 Loan이 최대 하나라는 뜻이다. Loan에 Copy가 0개 또는 1개라는 뜻이 아니며 반대 끝의 1은 활성 Loan당 Copy가 정확히 하나임을 말한다.
SD-01을 재생하면 요청이 Copy.checkout에 도착하고 Available --checkout--> OnLoan으로 전이한 뒤 저장하고 성공을 반환한다. 이미 OnLoan일 때 checkout을 다시 실행하면 유효한 전이가 없으므로 거부한다. 상태 화살표나 다중성 끝의 해석을 뒤집으면 안 된다.
연습 문제
Q1
옳은 설명은?
- ア. R-F01은 회원을 언급하므로 비기능 요구사항이다.
- イ. R-N01은 검색을 언급하므로 기능 요구사항이다.
- ウ. R-F01은 동작이고 R-N01은 동시 세션 200개 조건의 측정 가능한 품질 조건이며, 그 기준은 예시이지 IPA 규칙이 아니다.
- エ. 비기능 요구사항은 측정할 수 없다.
정답: ウ (3). ア는 액터와 요구사항 유형을 혼동한다. イ는 응답 시간이 품질 제약임을 무시한다. ウ는 둘과 가상 기준을 정확히 분류한다. エ는 측정 조건이 검증을 가능하게 하므로 틀리다.
Q2
한 대출 시나리오의 메시지를 시간순으로 나타내기에 가장 좋은 것은?
- ア. 클래스 다이어그램
- イ. 시퀀스 다이어그램
- ウ. 유스케이스 다이어그램
- エ. 상태 머신 다이어그램
정답: イ (2). ア는 정적 구조, イ는 시나리오의 시간순 메시지, ウ는 액터 목표와 경계, エ는 한 엔티티의 상태와 전이를 나타낸다.
Q3
Copy "1" -- "0..1" activeLoan: Loan의 유일하게 올바른 해석은?
- ア. 활성 Loan 하나에는 Copy가 0개 또는 1개다.
- イ. 모든 Copy에는 항상 활성 Loan이 하나 있어야 한다.
- ウ. Copy 하나에는 활성 Loan이 몇 개든 연결될 수 있다.
- エ. 활성 Loan마다 Copy가 정확히 하나이고 Copy마다 활성 Loan은 최대 하나다.
정답: エ (4). ア는 끝의 의미를 뒤집는다. イ는 0..1을 필수 1로 바꾼다. ウ는 상한을 무시한다. エ는 양쪽 끝을 정확히 읽으며 과거 Loan은 여러 개일 수 있다.
Q4
캡슐화와 다형성을 올바르게 구분한 것은?
- ア. 캡슐화는
Copy.status가 유효한 연산으로만 바뀌게 하며, 다형성은LoanService가 하나의NotificationChannel.send계약으로 서로 다른 채널 구현을 호출하게 한다. - イ. 캡슐화는 모든 필드를 공개하는 것이고 다형성은 오버로딩뿐이다.
- ウ. 캡슐화는 상속이고 다형성은 집약이다.
- エ. 둘 다
LoanService가 모든 구체 채널 유형을 검사해야 한다.
정답: ア (1). ア는 두 개념을 정확히 설명한다. イ는 정보 은닉을 부정하고 런타임 오버라이딩과 오버로딩을 혼동한다. ウ는 무관한 관계로 대체한다. エ는 대체 가능성을 깨고 구체 결합을 높인다.
Q5
가장 적절한 설계 판단은?
- ア. 응집도를 최대화하려면 보고와 UI 렌더링을
LoanService에 넣는다. - イ. 분기 제어 플래그 전달은 필요한 데이터 전달보다 항상 제약이 적다.
- ウ.
LoanService를 집중시키고NotificationChannel에 의존한다. 데이터 결합은 일반적으로 제어 결합보다 제약이 적지만 응집도/결합도는 절대 법칙이 아니다. - エ. 낮은 결합도를 위해 모듈끼리 전혀 통신하지 않아야 한다.
정답: ウ (3). ア는 무관한 책임을 섞어 응집도를 낮춘다. イ는 일반적인 비교를 뒤집는다. ウ는 균형 잡힌 판단이다. エ는 낮은 결합을 상호작용 없음으로 오해한다.
정답표: 3, 2, 4, 1, 3 (ウ, イ, エ, ア, ウ)
퀵 시트
- 동작 → 기능, 측정 가능한 품질/제약 → 비기능.
- 정방향(영향/커버리지)과 역방향(기원/근거)을 모두 추적한다.
- 유스케이스=액터 목표, 클래스=정적 구조, 시퀀스=시나리오 순서, 상태 머신=엔티티 생명주기.
- 다중성은 반대쪽 끝을 기준으로 읽는다.
- 빈 삼각형→상위 클래스, 빈/채운 마름모→집약/합성의 전체.
- 상태 변경을 캡슐화한다. 다형성은 런타임 대체이지 단순 오버로딩이 아니다.
- 책임을 집중하고 인터페이스에 의존하며 데이터/제어 결합을 구분한다.
셀프 체크와 1/3/7일 복습
R-F01/R-N01 분류, 사슬의 양방향 재현, 각 다이어그램의 한계, 세 다중성 해석, Copy 상태에 따른 SD-01 재생, 캡슐화·런타임 다형성·응집도·결합도 설명을 할 수 있는가?
- 1일째: 네 그림을 다시 그리고 Q1–Q5를 노트 없이 푼다.
- 3일째: 추적성 사슬을 재구성하고 두 풀이 예를 소리 내어 설명한다.
- 7일째: 전 문항을 다시 풀고 배제 이유를 설명할 수 없는 선택지를 복습한다.
공식 출처와 고지
- IPA, 응용정보기술자시험(레벨 3) 실러버스 Ver.7.2, PDF 62, 63, 64, 65, 68, 69쪽(인쇄 58, 59, 60, 61, 64, 65쪽): https://www.ipa.go.jp/shiken/syllabus/omgdg50000005kq5-att/syllabus_ap_ver7_2.pdf
- Object Management Group, Unified Modeling Language 2.5.1, 소개/명세 페이지, 규범 PDF.
출처 확인일은 2026-10-21이다. 이 독립 학습 자료는 IPA 또는 OMG와 제휴하거나 그 승인을 받은 자료가 아니며 시험 합격을 보장하지 않는다.