정보처리기사 1과목 소프트웨어 설계 핵심 정리 — 출제 포인트 완전 분석

📚 1과목 출제 경향 분석

소프트웨어 설계는 정보처리기사 필기 5과목 중 이론 이해 비중이 높은 과목입니다. 단순 암기보다 개념 간 관계(예: 요구사항 → UML 모델링 → 아키텍처 설계 → 인터페이스 설계로 이어지는 흐름)를 이해해야 응용문제까지 대응할 수 있습니다. UML 다이어그램 종류, GoF 디자인 패턴, 요구사항 분석 기법, 결합도·응집도는 회차마다 거의 빠짐없이 출제되는 핵심 영역입니다.

📊 출제 빈도 TOP 10 개념

순위	개념	출제 빈도
1	UML 다이어그램 종류 및 특징	매회 출제
2	GoF 디자인 패턴 23종	매회 2~3문항
3	소프트웨어 생명주기 모델	매회 출제
4	요구사항 분석 기법(유스케이스 등)	매회 출제
5	객체지향 개념(SOLID 원칙)	90% 출제
6	소프트웨어 아키텍처 패턴	80% 출제
7	모듈화·결합도·응집도	75% 출제
8	인터페이스 설계	70% 출제
9	코드 설계	60% 출제
10	UI·UX 설계	50% 출제

📝 요구사항 분석 — 설계의 출발점

요구사항 분석은 사용자가 원하는 시스템의 기능과 제약사항을 파악해 명세로 정리하는 과정입니다. 시험에서는 요구사항의 두 분류와 프로세스 순서를 정확히 구분하는 문제가 자주 나옵니다.

• 기능적 요구사항(Functional Requirement): 시스템이 반드시 수행해야 하는 기능. 입력·처리·출력·데이터 흐름 등 "무엇을 하는가"에 해당.
• 비기능적 요구사항(Non-Functional Requirement): 성능, 보안, 신뢰성, 사용성, 이식성, 유지보수성 등 시스템의 품질 속성. "얼마나 잘 하는가"에 해당.
• 요구사항 개발 프로세스: 도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 확인 및 검증(Validation) 순으로 진행되며, 이후 변경 관리를 통해 형상관리와 연계됩니다.
• 요구사항 도출 기법: 인터뷰, 설문조사, 브레인스토밍, 워크숍(JAD), 프로토타이핑, 관찰, 유스케이스 작성 등이 있으며 이해관계자 의견을 최대한 반영하는 것이 목적입니다.
• 요구사항 분석 도구: 자료흐름도(DFD), 자료사전(Data Dictionary), 소단위명세서(Mini-Spec), 개체관계도(ERD) 등 구조적 분석 기법과, 클래스 다이어그램·유스케이스 다이어그램 등 객체지향 분석 기법으로 나뉩니다.

🗂️ UML 다이어그램 — 구조 vs 행위

UML(Unified Modeling Language)은 시스템을 시각적으로 모델링하는 표준 표기법으로, 총 14종의 다이어그램이 구조(Structure) 다이어그램과 행위(Behavior) 다이어그램 두 갈래로 나뉩니다. 시험에서는 "이 다이어그램은 구조인가 행위인가", "무엇을 표현하는가"를 묻는 문제가 반복 출제됩니다.

분류	다이어그램	용도
구조 다이어그램	클래스(Class)	클래스의 속성·오퍼레이션과 클래스 간 관계(연관·집합·상속 등)를 표현
	컴포넌트(Component)	시스템을 구성하는 컴포넌트 단위와 인터페이스 관계를 표현
	배치(Deployment)	하드웨어 노드에 소프트웨어 컴포넌트가 어떻게 배치되는지 표현
	객체(Object)	특정 시점의 객체 인스턴스와 객체 간 관계(스냅샷)를 표현
행위 다이어그램	유스케이스(Use Case)	사용자(액터)와 시스템 기능 간의 상호작용을 기능 단위로 표현
	시퀀스(Sequence)	객체 간 메시지를 시간 순서에 따라 표현, 동적 상호작용 분석에 사용
	액티비티(Activity)	업무 처리 흐름을 순서도 형태로 표현, 분기·병합·병행 처리 포함
	상태(State)	객체가 이벤트에 따라 상태가 어떻게 전이되는지 표현

이 외에도 협력(Communication), 타이밍(Timing), 상호작용 개요(Interaction Overview), 패키지(Package), 복합체 구조(Composite Structure), 프로파일(Profile) 다이어그램이 있어 총 14종을 이룹니다. 시험 대비로는 위 8종을 정확히 익히고 나머지는 이름과 소속 분류만 매칭할 수 있으면 충분합니다.

🧩 디자인 패턴 — GoF 23종 분류

GoF(Gang of Four) 디자인 패턴은 반복되는 설계 문제에 대한 검증된 해결책을 유형화한 것으로, 생성(Creational), 구조(Structural), 행위(Behavioral) 3가지로 분류됩니다.

• 생성 패턴 — 객체 생성 방식을 캡슐화: 싱글톤(Singleton, 인스턴스를 하나만 생성해 전역에서 공유), 팩토리 메서드(Factory Method, 객체 생성을 서브클래스에 위임), 추상 팩토리(Abstract Factory, 관련 객체 군을 생성하는 인터페이스 제공), 빌더(Builder, 복잡한 객체를 단계적으로 생성), 프로토타입(Prototype, 기존 객체를 복제해 새 객체 생성).
• 구조 패턴 — 클래스·객체를 조합해 더 큰 구조를 구성: 어댑터(Adapter, 호환되지 않는 인터페이스를 연결), 데코레이터(Decorator, 객체에 동적으로 기능을 추가), 프록시(Proxy, 실제 객체에 대한 접근을 제어), 퍼사드(Facade, 복잡한 서브시스템을 단순한 인터페이스로 제공), 컴포지트(Composite, 트리 구조로 부분-전체 계층을 표현), 브리지(Bridge, 추상화와 구현을 분리), 플라이웨이트(Flyweight, 객체를 공유해 메모리 절약).
• 행위 패턴 — 객체 간 상호작용과 책임 분배: 옵저버(Observer, 상태 변화를 구독자에게 자동 통지), 전략(Strategy, 알고리즘을 캡슐화해 런타임에 교체), 커맨드(Command, 요청을 객체로 캡슐화해 실행·취소 가능), 템플릿 메서드(Template Method, 알고리즘 골격을 상위 클래스에서 정의), 상태(State, 객체 상태에 따라 행동을 변경), 반복자(Iterator, 컬렉션 요소를 순차 접근), 중재자(Mediator, 객체 간 통신을 중재 객체로 집중).

시험에서 자주 나오는 상위 10개(싱글톤·팩토리메서드·옵저버·전략·어댑터·데코레이터·프록시·커맨드·템플릿메서드·이터레이터)는 이름-분류-핵심 목적을 반드시 매칭할 수 있어야 하며, 나머지 패턴은 이름과 소속 분류만 구분해도 대부분 대응 가능합니다.

🏛️ 소프트웨어 아키텍처 패턴

아키텍처 패턴은 시스템 전체 구조를 설계할 때 재사용하는 큰 틀의 해결책입니다. 디자인 패턴이 클래스·객체 수준이라면 아키텍처 패턴은 시스템 수준이라는 점이 구분 포인트입니다.

• 계층화 패턴(Layered Pattern): 시스템을 여러 계층(프레젠테이션-비즈니스-데이터 등)으로 나누고 인접 계층끼리만 통신. OSI 7계층이 대표 사례.
• 클라이언트-서버 패턴(Client-Server): 서비스를 요청하는 클라이언트와 제공하는 서버로 역할을 분리.
• MVC 패턴(Model-View-Controller): Model(데이터·비즈니스 로직), View(화면 표시), Controller(사용자 입력 처리)로 역할을 분리해 유지보수성과 재사용성을 높임.
• 파이프-필터 패턴(Pipe-Filter): 데이터를 필터(처리 단위)들이 순차적으로 가공하고, 파이프로 필터 간 데이터를 전달.
• 브로커 패턴(Broker): 분산 시스템에서 클라이언트와 서버 컴포넌트 간 통신을 브로커가 중개.
• 이벤트 기반 패턴(Event-Driven): 이벤트 발생과 이벤트 처리기를 분리해 비동기적으로 시스템을 구성.

🔌 인터페이스 설계

인터페이스 설계는 시스템 내부 모듈 간, 혹은 외부 시스템 간 데이터 교환 방식과 통신 규약을 정의하는 작업입니다.

• 내부 인터페이스: 시스템 내부 모듈·컴포넌트 간 데이터 교환 방식을 정의.
• 외부 인터페이스: 외부 시스템과 데이터를 주고받기 위한 연계 방식을 정의(API, 파일 연계, DB 연계 등).
• EAI(Enterprise Application Integration) 구축 유형: Point-to-Point(1:1 직접 연결), Hub&Spoke(허브 중심 집중 연계), Message Bus(공통 버스를 통한 메시지 전달), Hybrid(허브와 버스를 혼합) 방식으로 구분.
• 미들웨어(Middleware): 이기종 시스템 간 통신을 중개하는 소프트웨어. DB 미들웨어, RPC(원격 프로시저 호출), MOM(메시지 지향 미들웨어), TP-Monitor, WAS 등이 대표적.
• 인터페이스 명세서: 송수신 시스템, 데이터 항목, 통신 방식(동기/비동기), 프로토콜, 예외 처리 방안 등을 문서화한 산출물.

🔑 자주 출제되는 핵심 용어

• 결합도 7단계(낮을수록 좋음): 내용 결합도 → 공통 결합도 → 외부 결합도 → 제어 결합도 → 스탬프 결합도 → 자료 결합도 → 비결합.
• 응집도 7단계(높을수록 좋음): 기능적 응집도 → 순차적 응집도 → 교환적(통신적) 응집도 → 절차적 응집도 → 시간적 응집도 → 논리적 응집도 → 우연적 응집도.
• 형상관리(Configuration Management): 소프트웨어 변경을 체계적으로 통제하는 활동. 형상식별 → 형상통제(변경관리) → 형상감사 → 형상기록의 4단계로 구성.
• CASE(Computer Aided Software Engineering) 도구: 소프트웨어 개발 전 과정을 자동화·지원하는 도구. 상위(Upper) CASE는 요구분석·설계, 하위(Lower) CASE는 구현·테스트를 지원.
• 소프트웨어 생명주기 모델: 폭포수 모델(순차적 단계 진행), 프로토타입 모델(시제품으로 요구사항 확인), 나선형 모델(위험 분석을 반복하며 점진적 개발), 애자일 모델(짧은 반복 주기로 점증적 개발).
• 애자일 방법론: 스크럼(Scrum, 짧은 스프린트 단위 반복 개발), XP(eXtreme Programming, 짝 프로그래밍·테스트 주도 개발 강조).
• SOLID 원칙: 단일 책임(SRP), 개방-폐쇄(OCP), 리스코프 치환(LSP), 인터페이스 분리(ISP), 의존 역전(DIP) — 객체지향 설계 5대 원칙.

🎯 효율적 학습 전략 — 암기 vs 이해

1과목을 효율적으로 정복하려면 암기 영역과 이해 영역을 구분해 학습 시간을 배분해야 합니다.

• 암기가 필요한 영역: UML 다이어그램 14종의 이름과 분류(구조/행위), 디자인 패턴 23종의 이름과 3대 분류, 결합도·응집도 단계별 순서, 미들웨어 종류. 이 항목들은 원리보다 정확한 명칭·순서 매칭이 관건이므로 표로 정리해 반복 암기하는 것이 효과적입니다.
• 이해가 필요한 영역: 요구사항 분석 프로세스의 흐름, 아키텍처 패턴 간 차이(계층형 vs 클라이언트-서버 vs MVC), 디자인 패턴이 실제로 어떤 문제를 해결하는지. 이 항목들은 단순 암기로는 응용문제(사례 제시 후 패턴 고르기 등)에 대응하기 어려우므로, 각 개념이 "왜" 필요한지 스스로 설명할 수 있을 때까지 반복 학습해야 합니다.
• 기출 회독 전략: 최근 5개년 기출문제를 3회독 이상 반복하면서 오답 개념만 별도로 정리하는 방식이 효율적입니다. 특히 디자인 패턴과 UML은 문제 유형이 크게 벗어나지 않으므로 기출 반복이 곧 실전 대비입니다.

❓ 자주 묻는 질문

Q. 디자인 패턴 23개를 전부 외워야 하나요?

자주 나오는 상위 10개(싱글톤·팩토리·옵저버·전략·어댑터·데코레이터·프록시·커맨드·템플릿메서드·이터레이터)를 확실히 이해하고, 나머지는 이름과 3대 분류(생성/구조/행위)만 정확히 매칭할 수 있으면 충분합니다.

Q. 1과목만 따로 먼저 공부하는 게 좋나요?

과목 간 연계가 있으므로 5개 과목을 병렬로 진행하는 게 효율적입니다. 다만 1과목은 이해 기반 개념이 많아 가장 먼저 시작해 감을 잡아두면 이후 과목 학습에도 도움이 됩니다.

Q. UML과 아키텍처 패턴을 헷갈리는데 어떻게 구분하나요?

UML은 "시스템을 어떻게 그림으로 표현할 것인가"에 대한 표기법이고, 아키텍처 패턴은 "시스템을 어떤 큰 구조로 설계할 것인가"에 대한 해결책입니다. UML은 도구, 아키텍처 패턴은 설계 결과물이라고 구분하면 헷갈리지 않습니다.

🚀 IT 자격증 학습 시작

정보처리기사 준비 강의로 체계적으로 정복하세요.