본문 바로가기
경제

[임베디드기사 실기 20부작 19편] UML, Use Case, Aggregation, White/Black Box Test — 소프트웨어 설계와 검증 핵심 정리

by 프레스러쉬 2026. 9. 18.

[임베디드기사 실기 20부작 19편] UML, Use Case, Aggregation, White/Black Box Test — 소프트웨어 설계와 검증 핵심 정리

임베디드기사 실기에서는 하드웨어와 커널뿐 아니라 소프트웨어 설계·모델링·테스트 영역도 반복적으로 출제됩니다. 특히 UML 관계 기호, Use Case Diagram의 목적, Aggregation과 Composition의 구분, 그리고 White-Box·Black-Box Test의 차이는 짧은 문제로 출제하기 좋고 실무에서도 중요한 개념입니다.

이번 편에서는 “시스템을 어떻게 표현하고, 어떻게 검증하는가”라는 하나의 흐름으로 UML과 테스트를 연결해 정리합니다. 단순히 기호를 외우는 것이 아니라 요구사항 → 설계 → 구현 → 검증으로 이어지는 과정 속에서 이해하는 것이 목표입니다.

1. UML이란 무엇인가

UML(Unified Modeling Language)은 객체지향 시스템의 구조와 동작을 시각적으로 표현하기 위한 모델링 언어입니다.

코드를 작성하기 전에 시스템의 구조와 관계를 명확히 하고, 개발자·설계자·고객 간 의사소통을 돕는 역할을 합니다.

시험에서는 UML 자체의 정의보다 어떤 다이어그램이 어떤 목적을 가지는가, 그리고 관계 기호가 무엇을 의미하는가가 더 중요합니다.

2. UML을 크게 나누면 — 구조와 행위

UML 다이어그램은 크게 StructuralBehavioral 관점으로 볼 수 있습니다.

Structural Diagram은 시스템의 정적인 구조를 표현합니다. 대표적으로 Class Diagram이 있습니다.

Behavioral Diagram은 시스템의 동작과 상호작용을 표현합니다. 대표적으로 Use Case, State, Sequence Diagram 등이 있습니다.

UML
├─ Structural
│   └─ Class Diagram
└─ Behavioral
    ├─ Use Case Diagram
    ├─ State Diagram
    └─ Sequence Diagram
3. Class Diagram — 정적인 구조를 본다

Class Diagram은 클래스의 이름, 속성, 메서드와 클래스 사이의 관계를 표현하는 대표적인 구조 다이어그램입니다.

실기에서는 다음 관계를 구분할 수 있어야 합니다.

Association, Aggregation, Composition, Generalization, Dependency, Realization

특히 Aggregation과 Composition은 마름모 기호 때문에 자주 출제됩니다.

4. Use Case Diagram — 사용자의 관점에서 기능 요구사항을 본다

Use Case Diagram은 외부 Actor 관점에서 시스템이 제공해야 하는 기능적 요구사항과 시스템 범위를 표현하는 다이어그램입니다.

대표 구성 요소는 다음과 같습니다.

Actor — 시스템과 상호작용하는 사람, 외부 시스템, 장치
Use Case — 시스템이 제공하는 기능
Association — Actor와 Use Case의 상호작용
<<include>> — 공통 기능을 항상 포함
<<extend>> — 특정 조건에서 기능 확장
Generalization — 일반화 관계

5. Use Case Diagram이 실기에서 중요한 이유

시험에서 “사용자의 관점에서 시스템이 제공해야 할 기능적 요구사항을 나타내는 UML 다이어그램”을 묻는다면 정답은 Use Case Diagram입니다.

즉 다음 한 문장으로 기억하면 됩니다.

기능적 요구사항 + 사용자 관점 = Use Case Diagram

6. Sequence Diagram — 시간 순서로 메시지를 본다

Sequence Diagram은 객체들이 시간의 흐름에 따라 주고받는 메시지 순서를 표현합니다.

대표 요소는 Lifeline, Activation, Message입니다.

API 호출 순서, 장비 제어 절차, Host와 Device 간 메시지 흐름, 초기화 Sequence를 표현할 때 유용합니다.

시험에서는 Use Case와 Sequence를 혼동하지 않는 것이 중요합니다.

Use Case = 어떤 기능이 필요한가
Sequence = 그 기능이 시간 순서상 어떻게 동작하는가

7. State Diagram — 상태 변화와 전이를 표현한다

State Diagram은 객체나 시스템이 어떤 상태를 가지고 있고, 이벤트에 따라 어떻게 다른 상태로 전이되는지를 표현합니다.

예를 들어 장비의 상태를 다음처럼 나타낼 수 있습니다.

Idle
  ↓ Start
Running
  ↓ Error
Alarm
  ↓ Reset
Idle

장비 제어 Firmware나 Robot Sequence 설계와 직접 연결되는 매우 실용적인 UML입니다.

8. Association — 가장 기본적인 관계

Association은 두 클래스가 서로 연관되어 있음을 나타냅니다.

예를 들어 User와 Account, Sensor와 Controller처럼 서로 관련된 객체 사이의 관계를 나타낼 수 있습니다.

Aggregation과 Composition은 Association의 특수한 형태로 이해하면 쉽습니다.

9. Aggregation — 빈 마름모(◇)

Aggregation(집합 관계)은 Whole과 Part 사이의 약한 포함 관계를 표현합니다.

표기할 때 Whole 쪽에 빈 마름모(◇)를 그립니다.

[Directory] ◇──── [File]

핵심은 전체와 부분의 생명주기가 독립적이라는 점입니다.

즉 Whole이 없어져도 Part는 독립적으로 존재할 수 있습니다.

10. Composition — 채워진 마름모(◆)

Composition(합성 관계)은 Aggregation보다 강한 포함 관계입니다.

Whole 쪽에 채워진 마름모(◆)를 표시하며, Part의 생명주기가 Whole에 강하게 종속됩니다.

예를 들어 Whole이 소멸하면 Part도 함께 소멸하는 관계로 이해할 수 있습니다.

11. Aggregation과 Composition 비교
항목 Aggregation Composition
기호 ◇ 빈 마름모 ◆ 채워진 마름모
결합도 약함 강함
생명주기 독립적 Whole에 의존
핵심 암기 약한 포함 강한 포함
12. 2025년 기출과 연결 — Directory ◇ File

2025년 실기 자료에서는 다음 관계가 직접 출제되었습니다.

[Directory] ◇──── [File]

빈 마름모이므로 정답은 Aggregation(집합 관계)입니다.

시험에서는 이처럼 기호 하나만 보고 관계를 맞히는 문제가 출제될 수 있으므로 빈 마름모와 채운 마름모의 차이를 확실히 구분해야 합니다.

13. 설계 다음에는 검증 — Testing으로 넘어간다

요구사항을 Use Case로 정의하고, Class·Sequence·State Diagram으로 구조와 동작을 설계했다면 다음 단계는 실제 구현 결과를 검증하는 것입니다.

이때 가장 기본적으로 구분해야 하는 것이 White-Box TestBlack-Box Test입니다.

14. White-Box Test — 내부 구조를 보며 테스트한다

White-Box Test는 소스코드 내부 구조, 제어 흐름, 조건, 경로 등을 알고 있는 상태에서 테스트하는 기법입니다.

대표 기법은 다음과 같습니다.

Statement Coverage
Decision / Branch Coverage
Condition Coverage
Condition/Decision Coverage
MC/DC
Path Coverage
Loop Testing
Data Flow Testing

핵심: 코드 내부 로직을 직접 본다.

15. Statement Coverage

Statement Coverage는 프로그램의 모든 실행문이 최소 한 번 이상 실행되도록 Test Case를 구성하는 방법입니다.

가장 기본적인 Code Coverage 기준입니다.

16. Branch / Decision Coverage

Branch Coverage는 if, switch 등 분기문의 모든 결과가 최소 한 번씩 실행되도록 하는 방법입니다.

예를 들어 if문의 True와 False가 모두 한 번 이상 실행되어야 합니다.

17. Condition Coverage와 MC/DC

Condition Coverage는 복합 조건식 내부의 각 개별 조건이 True와 False를 모두 경험하도록 하는 방식입니다.

MC/DC는 각 조건이 다른 조건과 독립적으로 전체 Decision 결과에 영향을 미치는지를 검증합니다.

시험에서는 세부 계산보다 Statement, Branch, Condition의 차이를 구분할 수 있는 것이 우선입니다.

18. Black-Box Test — 내부 코드는 보지 않고 입력과 출력으로 검증

Black-Box Test는 내부 코드 구조를 모르거나 보지 않고, 요구사항과 입력·출력 결과를 기준으로 기능을 검증합니다.

대표 기법은 다음과 같습니다.

Equivalence Partitioning
Boundary Value Analysis
Cause-Effect Graph
State Transition Test

핵심: 내부 구현이 아니라 외부 기능 명세를 본다.

19. Equivalence Partitioning — 입력 영역을 대표 그룹으로 나눈다

동등분할은 입력값 전체를 같은 동작이 예상되는 여러 Class로 나누고 각 Class의 대표값만 테스트하는 방식입니다.

예를 들어 유효 입력이 1~100이라면 Valid Class와 Invalid Class를 나누어 대표값을 선택할 수 있습니다.

모든 값을 전부 테스트하지 않고도 효율적으로 검증 범위를 줄일 수 있다는 장점이 있습니다.

20. Boundary Value Analysis — 오류는 경계에서 자주 발생한다

경계값 분석은 입력 범위의 최소값, 최대값과 그 주변을 집중적으로 테스트하는 방식입니다.

예를 들어 유효 범위가 1~100이라면 0, 1, 2, 99, 100, 101과 같은 값이 대표적인 Test Point가 됩니다.

Off-by-one Error를 잡는 데 특히 효과적입니다.

21. White-Box와 Black-Box 비교
항목 White-Box Black-Box
관점 내부 구조 외부 기능
코드 지식 필요 불필요
대표 기법 Statement, Branch, Condition, Path 동등분할, 경계값
중점 로직·제어 흐름 요구사항·입출력
22. 2025년 기출과 연결 — 내부구조를 검사하는 테스트는?

2025년 실기 자료에서는 소프트웨어 내부 구조와 동작을 자세하게 검사하는 테스트와, 내부 구조를 모르는 상태에서 기능을 검사하는 테스트를 구분하는 문제가 출제되었습니다.

정답은 다음과 같습니다.

내부 구조 기반 → White-Box Test
외부 동작 기반 → Black-Box Test

23. 실무 관점 — 장비 소프트웨어에는 두 테스트가 모두 필요하다

산업용 장비 SW에서는 White-Box와 Black-Box를 선택적으로 하나만 쓰는 것이 아니라 함께 사용하는 것이 일반적입니다.

예를 들어 Vision Algorithm의 내부 Branch와 Error Path는 White-Box 관점으로 확인하고, Recipe 입력에 따른 최종 판정값은 Black-Box 관점에서 검증할 수 있습니다.

또한 Motion Sequence는 State Diagram과 Sequence Diagram으로 흐름을 정의하고, 실제 동작은 Acceptance Test로 검증할 수 있습니다.

24. 요구사항부터 테스트까지 하나로 연결하기
Requirement
   ↓
Use Case Diagram
   ↓
Class / Sequence / State Diagram
   ↓
Implementation
   ↓
White-Box Test
   ↓
Black-Box Test
   ↓
System Validation

이 흐름으로 이해하면 UML과 테스트가 서로 분리된 암기 과목이 아니라 하나의 개발 프로세스로 연결됩니다.

25. 실기 예상문제와 모범답안

문제 1. 사용자 관점에서 시스템의 기능적 요구사항을 표현하는 UML 다이어그램은?
답: Use Case Diagram

문제 2. UML에서 빈 마름모(◇)가 의미하는 관계는?
답: Aggregation(집합 관계)

문제 3. Aggregation과 Composition의 차이를 설명하시오.
모범답안: Aggregation은 Whole과 Part가 독립적인 생명주기를 가지는 약한 포함 관계이며 빈 마름모로 표현한다. Composition은 Part의 생명주기가 Whole에 강하게 종속되는 강한 포함 관계이며 채워진 마름모로 표현한다.

문제 4. 내부 소스코드의 제어 흐름과 조건을 검증하는 테스트는?
답: White-Box Test

문제 5. 동등분할과 경계값 분석은 어느 테스트 기법에 속하는가?
답: Black-Box Test

문제 6. 모든 분기의 True/False 결과를 최소 한 번씩 실행하도록 하는 Coverage는?
답: Branch/Decision Coverage

26. 시험 직전 30초 암기

Use Case = 기능적 요구사항 / Actor 관점
Class = 정적 구조
Sequence = 시간 순서 메시지
State = 상태와 전이
= Aggregation / 약한 포함 / 독립 생명주기
= Composition / 강한 포함 / 종속 생명주기
White-Box = 내부 코드 구조
Black-Box = 외부 기능 명세
Statement = 모든 실행문
Branch = True/False 분기
Condition = 개별 조건식
Equivalence Partitioning = 동등분할
Boundary Value = 경계값 분석

27. 마무리 — 설계와 테스트는 하나의 흐름이다

UML과 테스트를 따로 외우기보다 다음 흐름으로 이해하면 오래 기억됩니다.

요구사항을 Use Case로 표현하고 → 구조를 Class Diagram으로 설계하고 → 동작을 Sequence/State Diagram으로 설명하고 → 구현 결과를 White-Box와 Black-Box 방식으로 검증한다.

실기에서 기호 하나, 용어 하나만 묻더라도 머릿속에는 전체 개발 흐름이 연결되어 있어야 안정적으로 답할 수 있습니다.

다음 편 예고

20편 — 장애 대응과 실기 최종 총정리: 접수부터 원인분석·복구·재발방지까지

태그
#임베디드기사 #임베디드기사실기 #UML #UseCaseDiagram #ClassDiagram #SequenceDiagram #StateDiagram #Aggregation #Composition #WhiteBoxTest #BlackBoxTest #StatementCoverage #BranchCoverage #ConditionCoverage #MCDC #동등분할 #경계값분석 #소프트웨어테스트 #소프트웨어설계 #자격증공부