정보처리기사 CBT
종목 메뉴

개념 한 쪽

정보처리기사 UML 기초 — 액터·유스케이스·확장 관계

UML 세트는 모델링 언어의 쓰임과 유스케이스 다이어그램의 구성 요소를 묻고, 이어서 요구사항 분석이 어려운 까닭과 검증의 한계, 애자일·스크럼과의 구분으로 넘어간다. 액터가 사람만이 아니라는 점, 유스케이스 다이어그램에 객체가 들어가지 않는다는 점이 중심이다.

2026-10-15 기준 · 정보처리기사 대시보드

이 개념을 문제로 확인하고 싶으면 이 개념 문제 10개 풀기 회원용

가입 없이 오늘의 10문제 바로 풀기 →

시험에 이렇게 나온다

출제기준 단원 「UML」의 공개 문제 3개를 묻는 꼴별로 나누면 이렇습니다.

묻는 꼴문제 수무엇을 묻나
UML·유스케이스 구성요소와 모델링 특성 판단1유스케이스 다이어그램 요소와 UML 적용 가능성 판단
사용자 요구사항 관련 판단1요구사항 검증·분석 기법과 분석 어려움의 타당성 판단
애자일·스크럼 원리·용어 타당성 판단1애자일 특성 및 스크럼 용어의 옳고 그름 판단

뜻

UML은 시스템의 구조와 행위를 표현하는 표준 모델링 언어다. 실시간·분산 시스템의 분석과 설계에도 널리 쓰이므로 특정 분야에서 쓸 수 없다는 설명은 틀린다. 모델링은 한 번에 끝나는 작업이 아니라 반복적이고 상호 의존적인 과정이어서, 한 모델링 결과물이 다른 작업에 영향을 준다.

유스케이스 다이어그램은 사용자 요구사항을 표현하며 액터(Actor), 유스케이스(Use Case), 관계(Relationship)로 구성된다. 객체(Object)는 이 다이어그램의 구성 요소가 아니다. 액터는 시스템과 상호작용하는 외부 주체로, 사람일 필요가 없고 다른 컴퓨터 시스템이나 하드웨어 장치, 연동 시스템도 액터가 될 수 있다. 기본 유스케이스의 흐름을 특별한 조건에서 확장하는 경우에는 확장 관계로 표현한다.

요구사항 분석은 사용자의 요구가 모호하고 복잡하며 예외가 많아 어렵다. 예외가 거의 없어 열거와 구조화가 쉽다는 설명은 분석을 어렵게 만드는 이유와 반대다. 요구사항 분석에는 현장 조사와 의견 수렴이 쓰이며, 통제와 보안 분석은 설계 단계의 기술적 검토에 해당한다. 검증은 요구사항의 문제를 모두 발견하는 것을 보장하지 않으므로 모든 문제를 발견한다는 설명도 틀리다.

애자일은 개발 방법론이지 모델링 도구가 아니다. 애자일은 엄격한 계획과 문서화보다 변화 수용과 소통을 중시하므로, 문서화를 더 가치 있게 둔다는 설명은 원칙에 어긋난다. 스크럼의 스프린트는 2주에서 4주 이내의 짧은 반복 주기로 운영되며 3개월 이상의 장기간은 스크럼 원칙에 맞지 않는다.

예제

출제 패턴은 네 가지다. ① 구성 요소 — 유스케이스 다이어그램에 속하지 않는 것으로 객체를 고른다. 구성은 액터·유스케이스·관계다. ② 액터의 범위 — 액터를 사람으로만 한정한 선지가 오답이고, 외부 시스템과 연동 시스템도 액터가 된다. ③ 요구사항 분석·검증 — 예외가 거의 없어 분석이 쉽다거나 검증이 모든 문제를 발견한다고 적은 선지가 틀린다. ④ 애자일·스크럼 — 애자일을 모델링 도구로 적거나, 문서화를 더 중시한다거나, 스프린트를 3개월 이상으로 적은 선지가 오답이다.

대표 기출 3문항

유스케이스(Usecase)에 대한 설명 중 옳은 것은?

  1. 유스케이스 다이어그램은 개발자의 요구를 추출하고 분석하기 위해 주로 사용한다.
  2. 액터는 대상 시스템과 상호 작용하는 사람이나 다른 시스템에 의한 역할이다.
  3. 사용자 액터는 본 시스템과 데이터를 주고받는 연동 시스템을 의미한다.
  4. 연동의 개념은 일방적으로 데이터를 파일이나 정해진 형식으로 넘겨주는 것을 의미한다.
정답과 해설 보기

정답 ② · 유스케이스와 액터의 개념에 대한 옳은 설명을 고르는 문제이다. 액터(Actor)는 대상 시스템과 상호작용하는 사람이나 외부 시스템이 수행하는 역할을 의미하며, 시스템 경계 바깥에 위치한다.

액터는 시스템과 상호작용하는 주체로 사람이나 외부 시스템 모두 포함하며 유스케이스의 핵심 요소다.

요구사항 검증(Requirements Validation)과 관련한 설명으로 틀린 것은?

  1. 요구사항이 고객이 정말 원하는 시스템을 제대로 정의하고 있는지 점검하는 과정이다.
  2. 개발완료 이후에 문제점이 발견될 경우 막대한 재작업 비용이 들 수 있기 때문에 요구사항 검증은 매우 중요하다.
  3. 요구사항이 실제 요구를 반영하는지, 문서상의 요구사항은 서로 상충되지 않는지 등을 점검한다.
  4. 요구사항 검증 과정을 통해 모든 요구사항 문제를 발견할 수 있다.
정답과 해설 보기

정답 ④ · 요구사항 검증에 대한 설명 중 틀린 것을 찾는 문제이다. 요구사항 검증은 요구사항이 고객이 원하는 시스템을 제대로 정의하는지, 실제 요구를 반영하는지, 문서 간 상충은 없는지 등을 점검하는 과정이다.

검증은 완벽을 보장하지 않으므로 '모든' 문제를 발견한다는 주장은 명백한 과장이다.

애자일 개발 방법론과 관련한 설명으로 틀린 것은?

  1. 빠른 릴리즈를 통해 문제점을 빠르게 파악할 수 있다.
  2. 정확한 결과 도출을 위해 계획 수립과 문서화에 중점을 둔다.
  3. 고객과의 의사소통을 중요하게 생각한다.
  4. 진화하는 요구사항을 수용하는데 적합하다.
정답과 해설 보기

정답 ② · 애자일 개발 방법론에 대한 틀린 설명을 고르는 문제이다. 애자일 선언은 포괄적인 문서보다 작동하는 소프트웨어를, 계획보다 변화에 대한 대응을 가치 있게 여기므로 계획 수립과 문서화에 중점을 둔다는 2번은 애자일 원칙에 위배된다.

애자일은 엄격한 계획과 문서화보다 변화 수용과 소통을 중시하므로, ②번이 애자일 원칙에 위배된다.

자주 묻는 물음

유스케이스 다이어그램은 무엇으로 구성되나요?
액터, 유스케이스, 관계로 구성됩니다. 객체는 이 다이어그램의 구성 요소가 아닙니다. 액터는 시스템과 상호작용하는 외부 주체로 사람뿐 아니라 다른 컴퓨터 시스템이나 하드웨어 장치, 연동 시스템도 포함됩니다.
요구사항 분석과 검증에서 자주 나오는 함정은 무엇인가요?
요구사항은 모호하고 복잡하며 예외가 많아 분석이 어렵다는 점이 핵심입니다. 예외가 거의 없어 열거와 구조화가 쉽다는 설명은 반대이고, 검증이 모든 문제를 발견한다는 설명도 틀립니다. 분석에는 현장 조사와 의견 수렴이 쓰이며, 통제·보안 분석은 설계 단계의 검토입니다.
애자일과 스크럼은 UML과 어떻게 구분하나요?
UML은 모델링 언어이고 애자일은 개발 방법론입니다. 애자일은 엄격한 계획과 문서화보다 변화 수용과 소통을 중시합니다. 스크럼의 스프린트는 2주에서 4주 이내의 짧은 반복 주기이며, 3개월 이상의 장기간은 스크럼 원칙에 어긋납니다.
이 개념 문제 10개 풀기 회원용

정보처리기사 풀이 세트에서 이 개념의 문제 10개를 바로 풀어 보세요.