Ch1. 정보처리기사 — 자격증 개요와 소프트웨어 설계 기초

정보처리기사란?

정보처리기사는 한국산업인력공단에서 시행하는 국가기술자격으로, IT 분야 최고 인기 자격증 중 하나입니다. 소프트웨어 개발·운영·관리 능력을 검증하며, 공공기관·IT 기업 취업 시 가산점이나 필수 조건으로 요구되는 경우가 많습니다.

응시 자격: 관련 학과 졸업(예정)자, 비관련 학과 3년 이상 실무 경력자, 관련 교육훈련기관 수료자 등 다양한 경로로 응시 가능합니다. 최근에는 전공 무관으로 응시 범위가 확대되어 비전공자도 도전할 수 있습니다.

시험 구조

필기시험 (5과목)

과목	내용
1과목	소프트웨어 설계
2과목	소프트웨어 개발
3과목	데이터베이스 구축
4과목	프로그래밍 언어 활용
5과목	정보시스템 구축 관리

문항 수: 과목당 20문항, 총 100문항 (4지선다 객관식)
시험 시간: 150분
합격 기준: 과목당 40점 이상, 전 과목 평균 60점 이상

실기시험

형식: 필답형 (서술·단답식)
시험 시간: 180분
합격 기준: 60점 이상
내용: 필기 5과목 전반 + 실무 응용 능력

합격률과 난이도

정보처리기사 필기 합격률은 보통 40~55% 수준이며, 실기는 20~35% 수준으로 더 까다롭습니다. 단순 암기보다 개념 이해와 응용 능력이 중요하므로, 체계적인 학습 계획이 필요합니다. 연간 3회(1·2·3회차) 시험이 시행됩니다.

1과목: 소프트웨어 설계

1과목은 소프트웨어 개발 프로젝트를 계획하고 설계하는 단계에 필요한 지식을 다룹니다. UML, 디자인 패턴, 개발 방법론, 아키텍처 패턴이 핵심입니다.

소프트웨어 개발 방법론

소프트웨어를 체계적으로 개발하기 위한 절차와 기법의 집합입니다.

구조적 방법론 (Structured Methodology)

프로세스 중심, 하향식(Top-Down) 분해
DFD(Data Flow Diagram): 데이터 흐름 표현
DD(Data Dictionary): 데이터 정의
대규모 시스템에 적합하지만 유지보수 어려움

객체지향 방법론 (Object-Oriented Methodology)

현실 세계를 객체(Object) 단위로 모델링
핵심 개념: 캡슐화, 상속, 다형성, 추상화
UML을 이용한 설계 표현
재사용성과 유지보수성이 높음

개념	설명
캡슐화(Encapsulation)	데이터와 메서드를 하나의 객체로 묶고 내부 구현 은닉
상속(Inheritance)	부모 클래스의 속성·메서드를 자식 클래스가 물려받음
다형성(Polymorphism)	같은 인터페이스로 다양한 객체 타입을 처리
추상화(Abstraction)	복잡한 내부 구현을 숨기고 핵심만 노출

애자일 방법론 (Agile Methodology)

가치: 개인과 상호작용 > 프로세스와 도구, 작동하는 소프트웨어 > 포괄적인 문서
특징: 짧은 반복(스프린트/이터레이션), 변화에 유연한 대응
대표 기법: 스크럼(Scrum), 칸반(Kanban), XP(Extreme Programming)

스크럼 주요 개념:

스프린트: 1~4주 단위 반복 개발 주기
백로그: 개발해야 할 기능 목록 (제품 백로그·스프린트 백로그)
일일 스크럼: 매일 15분 진행 상황 공유
번다운 차트: 남은 작업량을 시각화

UML 다이어그램

**UML(Unified Modeling Language)**은 소프트웨어 시스템을 시각적으로 모델링하는 표준 언어입니다.

구조 다이어그램 (정적 모델)

다이어그램	목적
클래스(Class)	클래스, 속성, 관계 표현 (가장 많이 사용)
객체(Object)	특정 시점의 객체 인스턴스 표현
컴포넌트(Component)	시스템의 물리적 컴포넌트 구조
배치(Deployment)	하드웨어·소프트웨어 배치 환경
복합체 구조(Composite Structure)	클래스 내부 구조
패키지(Package)	요소를 패키지로 그룹화

행위 다이어그램 (동적 모델)

다이어그램	목적
유스케이스(Use Case)	사용자와 시스템의 상호작용, 기능 요구사항
시퀀스(Sequence)	객체 간 시간 순서에 따른 메시지 교환
활동(Activity)	작업 흐름, 비즈니스 프로세스
상태(State Machine)	객체의 상태 변화와 전이
협력(Communication)	객체 간 협력과 메시지
타이밍(Timing)	시간 제약 조건과 상태 변화

클래스 다이어그램 관계 표기:

연관(Association): 실선
집합(Aggregation): 빈 마름모 + 실선 (부분-전체, 독립적 생존)
합성(Composition): 채운 마름모 + 실선 (부분-전체, 의존적 생존)
일반화(Generalization/상속): 빈 삼각형 화살표 + 실선
실현(Realization/구현): 빈 삼각형 화살표 + 점선
의존(Dependency): 점선 화살표

디자인 패턴

**디자인 패턴(Design Pattern)**은 소프트웨어 설계에서 반복적으로 발생하는 문제에 대한 검증된 해결책입니다. GoF(Gang of Four)가 제시한 23가지 패턴이 표준입니다.

생성 패턴 (Creational Patterns) — 객체 생성 관련

패턴	설명
싱글톤(Singleton)	클래스의 인스턴스를 하나만 생성하여 전역 접근 제공
팩토리 메서드(Factory Method)	객체 생성을 서브클래스에 위임
추상 팩토리(Abstract Factory)	연관된 객체들의 패밀리를 생성하는 인터페이스 제공
빌더(Builder)	복잡한 객체를 단계적으로 생성
프로토타입(Prototype)	기존 객체를 복사(clone)하여 새 객체 생성

구조 패턴 (Structural Patterns) — 클래스·객체 구성 관련

패턴	설명
어댑터(Adapter)	호환되지 않는 인터페이스를 연결 (변환기 역할)
브리지(Bridge)	추상화와 구현을 분리하여 독립적으로 변경
컴포지트(Composite)	단일 객체와 복합 객체를 동일하게 처리
데코레이터(Decorator)	객체에 동적으로 기능 추가
파사드(Facade)	복잡한 서브시스템에 단순한 인터페이스 제공
플라이웨이트(Flyweight)	많은 수의 유사 객체를 공유하여 메모리 절약
프록시(Proxy)	다른 객체의 대리자 역할 (접근 제어, 캐싱 등)

행위 패턴 (Behavioral Patterns) — 알고리즘·책임 분배 관련

패턴	설명
옵저버(Observer)	객체 상태 변화를 구독자에게 자동 통보
전략(Strategy)	알고리즘을 캡슐화하여 런타임에 교체 가능
커맨드(Command)	요청을 객체로 캡슐화, 실행 취소 지원
템플릿 메서드(Template Method)	알고리즘 골격 정의, 세부 단계는 서브클래스에서 구현
이터레이터(Iterator)	컬렉션 요소를 순차 접근하는 표준 방법 제공
상태(State)	객체 내부 상태에 따라 행동 변경
책임 연쇄(Chain of Responsibility)	요청을 처리할 수 있는 객체를 체인 형태로 연결

소프트웨어 아키텍처 패턴

아키텍처 패턴은 시스템 전체 구조를 구성하는 방법입니다.

MVC (Model-View-Controller)

사용자 → Controller → Model → View → 사용자

Model: 데이터와 비즈니스 로직
View: 사용자 인터페이스 (화면 표시)
Controller: 사용자 입력 처리, Model과 View 연결
장점: 역할 분리, 유지보수 용이
단점: View와 Controller 간 의존성 (Massive View Controller 문제)

MVP (Model-View-Presenter)

View ↔ Presenter ↔ Model

Presenter가 View와 Model 모두를 중재
View는 완전히 수동적 (Passive View)
Android 개발에 주로 사용
단위 테스트가 용이

MVVM (Model-View-ViewModel)

View ↔ (Data Binding) ↔ ViewModel ↔ Model

ViewModel: View의 상태와 로직을 담당, 데이터 바인딩으로 View와 연결
View와 ViewModel이 1:N 관계 가능
WPF, SwiftUI, Vue.js 등에 주로 사용
데이터 바인딩이 없는 환경에서는 구현이 복잡

응집도와 결합도

소프트웨어 모듈의 품질을 평가하는 핵심 지표입니다.

응집도 (Cohesion) — 높을수록 좋음

모듈 내부 요소들이 얼마나 밀접하게 관련되어 있는지를 나타냅니다.

응집도 유형	강도	설명
기능적(Functional)	최강 ★★★★★	모듈의 모든 기능이 단일 목적 수행
순차적(Sequential)	★★★★	한 기능의 출력이 다음 기능의 입력
통신적(Communicational)	★★★	같은 데이터를 사용하는 기능들
절차적(Procedural)	★★★	순서에 따라 실행되는 기능들
시간적(Temporal)	★★	같은 시점에 실행되는 기능들
논리적(Logical)	★★	유사한 종류의 기능들
우연적(Coincidental)	최약 ★	아무 관련 없이 묶인 기능들

결합도 (Coupling) — 낮을수록 좋음

모듈 간의 상호 의존 정도를 나타냅니다.

결합도 유형	강도	설명
내용(Content)	최강 ★★★★★	다른 모듈 내부를 직접 참조·수정
공통(Common)	★★★★	전역 변수를 공유
외부(External)	★★★	외부 데이터 형식·통신 프로토콜 공유
제어(Control)	★★★	제어 신호를 매개변수로 전달
스탬프(Stamp)	★★	복잡한 자료 구조를 매개변수로 전달
자료(Data)	최약 ★	단순 데이터만 매개변수로 전달 (최선)

설계 원칙: 응집도는 높게(High Cohesion), 결합도는 낮게(Low Coupling) — 유지보수성과 재사용성 향상의 핵심입니다.

SOLID 원칙

객체지향 설계의 5대 원칙으로, 유지보수 가능한 소프트웨어 설계의 기반입니다.

원칙	설명
S — 단일 책임 원칙(SRP)	클래스는 변경 이유가 하나여야 함
O — 개방-폐쇄 원칙(OCP)	확장에는 열려있고, 수정에는 닫혀 있어야 함
L — 리스코프 치환 원칙(LSP)	부모 클래스는 자식 클래스로 대체 가능해야 함
I — 인터페이스 분리 원칙(ISP)	클라이언트가 사용하지 않는 인터페이스에 의존하지 않아야 함
D — 의존 역전 원칙(DIP)	고수준 모듈이 저수준 모듈에 의존하면 안 됨, 추상화에 의존

요구사항 분석

요구사항 분류

기능적 요구사항: 시스템이 수행해야 하는 기능 (ex. 로그인, 결제 처리)
비기능적 요구사항: 성능, 보안, 신뢰성, 유지보수성 등 품질 속성

요구사항 개발 프로세스

도출(Elicitation) → 분석(Analysis) → 명세(Specification) → 검증(Validation)

도출: 인터뷰, 설문, 프로토타이핑, 브레인스토밍
분석: 요구사항 충돌 해결, 우선순위 설정
명세: SRS(Software Requirements Specification) 문서 작성
검증: 리뷰, 프로토타이핑, 인수 테스트 계획

핵심 개념 카드

소프트웨어 개발 방법론 ★★★★★ : 구조적(DFD/하향식), 객체지향(UML/캡슐화·상속·다형성), 애자일(스프린트·스크럼). 암기 포인트: 구→객→애 순서로 발전. 애자일은 변화 대응이 핵심.

UML 다이어그램 분류 ★★★★★ : 구조(클래스·객체·컴포넌트·배치·패키지) vs 행위(유스케이스·시퀀스·활동·상태). 암기 포인트: 구조=정적/현재 모습, 행위=동적/흐름과 변화

디자인 패턴 3분류 ★★★★★ : 생성(싱글톤·팩토리·빌더) / 구조(어댑터·데코레이터·파사드) / 행위(옵저버·전략·커맨드). 암기 포인트: 생→만드는 것, 구→조립하는 것, 행→하는 것

응집도·결합도 ★★★★★ : 응집도 최강=기능적, 최약=우연적 / 결합도 최강=내용, 최약=자료. 암기 포인트: 응집도↑ 결합도↓ = 좋은 모듈 설계

SOLID 원칙 ★★★★☆ : SRP·OCP·LSP·ISP·DIP. 각 앞글자로 암기. 암기 포인트: 단개리인의(단·개·리·인·의존역전)

실전 퀴즈

Q1. 디자인 패턴 중 생성 패턴에 해당하지 않는 것은? ① 싱글톤 ② 옵저버 ③ 팩토리 메서드 ④ 빌더

정답: ② 옵저버(Observer)는 행위 패턴입니다. 생성 패턴에는 싱글톤, 팩토리 메서드, 추상 팩토리, 빌더, 프로토타입이 있습니다.

Q2. 모듈 설계에서 응집도는 높고 결합도는 낮아야 한다. 응집도 중 가장 높은 수준은?

정답: 기능적 응집도(Functional Cohesion). 모듈 내 모든 요소가 단일한 기능을 위해 협력하는 이상적인 형태입니다. 반대로 가장 낮은 응집도는 우연적 응집도입니다.

Q3. MVC 패턴에서 사용자 입력을 처리하고 Model과 View를 연결하는 컴포넌트는?

정답: Controller. Controller는 사용자 요청을 받아 Model에 비즈니스 로직 실행을 요청하고, 결과를 View에 전달합니다. Model은 데이터, View는 화면 표시 담당입니다.

OIYO 편집부