정보처리기사 실기 소프트웨어 공학 완전 정복

정보처리기사 실기에서 소프트웨어 공학은 전체 20문항 중 4~6문항을 차지하는 핵심 영역입니다. SQL·프로그래밍처럼 코드를 직접 작성하는 파트가 아니라 개념·용어를 정확히 쓰는 파트라 암기 비중이 높아요. 하지만 범위가 넓어서 어디서부터 공부해야 할지 막막한 분이 많습니다.

이 글에서는 실제 시험에 반복 출제되는 주제만 골라 정리했습니다. 방법론 → UML → 디자인 패턴 → 테스트 순서로 읽으면 됩니다.

1. 소프트웨어 개발 방법론과 SDLC 모델

SDLC 모델 — 4가지 핵심 모델

소프트웨어 개발 생명주기(SDLC) 모델은 어떤 순서와 방식으로 소프트웨어를 만드느냐에 대한 틀입니다. 시험에서는 모델의 이름과 특징·장단점을 서술하는 문제가 나옵니다.

모델	특징	장점	단점
폭포수 모델 (Waterfall)	요구분석 → 설계 → 구현 → 테스트 → 유지보수 순서대로 진행. 이전 단계로 돌아갈 수 없음	단계가 명확, 관리 쉬움	요구사항 변경 어려움, 완성 전까지 결과 확인 불가
프로토타입 모델	요구사항이 불명확할 때 시제품(프로토타입)을 먼저 만들어 사용자 피드백 반영	요구사항 명확화, 사용자 만족도 높음	관리 어려움, 프로토타입을 실제 제품으로 오해할 수 있음
나선형 모델 (Spiral)	계획 → 위험분석 → 개발 → 평가를 반복. 위험 분석이 핵심	위험 최소화, 대규모 프로젝트에 적합	관리 복잡, 위험 분석 전문가 필요, 비용 높음
반복적 모델 (Iterative)	시스템 일부를 반복적으로 개발·확장. 애자일의 기반이 됨	조기에 일부 기능 제공 가능, 변경 유연	전체 설계가 미리 명확하지 않으면 관리 어려움

소프트웨어 개발 방법론

SDLC 모델이 "순서"라면, 방법론은 "어떻게 만드느냐"에 대한 구체적인 접근법입니다.

방법론	핵심 개념	키워드
구조적 방법론	기능 중심. 자료 흐름도(DFD), 구조적 차트 사용. 프로세스를 분해하여 개발	DFD, 프로세스 분해, 절차 지향
정보공학 방법론	데이터 중심. 기업 전체 정보 시스템을 대상으로 계획→분석→설계→구축	데이터 중심, 기업 전략, ISP
객체지향 방법론	객체(데이터+행위) 중심. UML 사용. 재사용성·유지보수성 높음	객체, 클래스, 캡슐화, UML
CBD 방법론	컴포넌트(독립 기능 단위) 조합으로 개발. 재사용성 극대화	컴포넌트, 재사용, 인터페이스
애자일 방법론	짧은 반복(스프린트) 단위로 작동 소프트웨어 우선. 변화에 유연하게 대응	스프린트, 협업, 변화 수용

애자일 방법론 — 스크럼 vs XP

애자일 중 스크럼(Scrum)과 XP(Extreme Programming)는 각각 출제 빈도가 높습니다. 핵심 개념을 혼동하지 않도록 구분해서 외우세요.

항목	스크럼(Scrum)	XP(Extreme Programming)
핵심 초점	프로젝트 관리 프레임워크	개발 기술 실천법
반복 주기	스프린트 (보통 2~4주)	이터레이션 (1~2주)
핵심 역할	제품 책임자(PO), 스크럼 마스터, 개발팀	고객, 개발자, 코치
주요 산출물	제품 백로그, 스프린트 백로그, 번다운 차트	사용자 스토리, 릴리즈 계획
대표 실천법	데일리 스크럼(매일 15분 회의), 스프린트 리뷰	페어 프로그래밍, TDD, 리팩토링, 지속적 통합

2. UML 다이어그램 14종

UML(Unified Modeling Language)은 소프트웨어 설계를 시각화하는 표준 표기법입니다. 시험에서 "다음 설명에 해당하는 UML 다이어그램은?" 형식으로 자주 출제됩니다. 14종을 구조 다이어그램(7종)과 행위 다이어그램(7종)으로 나누어 외우세요.

구조 다이어그램 (7종) — 정적인 구조를 표현

다이어그램	표현 내용	시험 포인트
클래스	클래스의 속성·메서드·클래스 간 관계(연관, 의존, 상속, 실체화)	가장 자주 출제. 관계 표기 기호 암기 필수
객체	클래스의 인스턴스(실제 객체)와 관계를 특정 시점에 표현	클래스 다이어그램의 스냅샷
컴포넌트	소프트웨어 컴포넌트(독립 실행 단위)와 인터페이스 관계	CBD 방법론과 연계 출제
배치	하드웨어 노드에 소프트웨어 컴포넌트를 배치하는 물리적 구조	서버·네트워크 구성도와 유사한 개념
패키지	관련 요소를 그룹화한 패키지와 의존 관계	대규모 시스템 구조화에 사용

클래스 다이어그램 관계 기호 — 반드시 암기

관계	설명	기호(화살표 방향)
연관(Association)	클래스 간 서로 관련 있음. 가장 일반적인 관계	─────→
의존(Dependency)	한 클래스가 다른 클래스를 일시적으로 사용	- - - →
집합(Aggregation)	전체-부분 관계. 부분은 독립적으로 존재 가능 (약한 결합)	◇─────
합성(Composition)	전체-부분 관계. 부분은 전체 없이 존재 불가 (강한 결합)	◆─────
일반화(Generalization)	상속 관계 (IS-A 관계). 자식 → 부모 방향	────▷
실체화(Realization)	인터페이스를 구현하는 관계	- - -▷

행위 다이어그램 (7종) — 동적인 흐름을 표현

다이어그램	표현 내용	시험 포인트
유스케이스	사용자(Actor)와 시스템 간 상호작용. 기능 요구사항 시각화	include, extend 관계 자주 출제
시퀀스	객체 간 메시지 교환 순서를 시간 흐름으로 표현 (수직 = 시간축)	가장 자주 출제. 생명선, 활성 박스 개념
커뮤니케이션	시퀀스와 같은 정보지만 공간 배치에 집중. 메시지에 번호 표기	시퀀스 다이어그램과의 차이점
상태	객체가 가질 수 있는 상태 변화와 전이 조건	이벤트·전이·상태 개념 암기
활동	업무 처리 흐름. 순서도(Flowchart)와 유사. 병렬 처리 표현 가능	swimlane(수영 레인)으로 역할 구분

3. GoF 디자인 패턴 23개

GoF(Gang of Four) 디자인 패턴은 소프트웨어 설계에서 반복되는 문제의 검증된 해결책입니다. 23개를 생성(5) · 구조(7) · 행위(11) 패턴으로 나눕니다. 시험에서 설명을 읽고 패턴 이름을 맞히는 문제가 주로 나옵니다.

생성 패턴 (5개) — 객체 생성 방식에 관한 패턴

구조 패턴 (7개) — 클래스·객체를 조합하는 패턴

행위 패턴 (11개) — 객체 간 책임 분배와 통신에 관한 패턴

패턴명	핵심 개념
옵서버 (Observer)	상태 변경 시 의존 객체들에게 자동 알림. 이벤트 처리, 알림 시스템. 발행-구독 모델
전략 (Strategy)	알고리즘을 캡슐화하여 교체 가능하게 함. 정렬 알고리즘을 런타임에 바꾸는 것이 대표 예
템플릿 메서드	알고리즘 골격을 상위 클래스에, 세부 구현을 하위 클래스에. "훅 메서드" 개념
커맨드 (Command)	요청을 객체로 캡슐화. 실행 취소(Undo), 로깅, 큐잉 가능
이터레이터 (Iterator)	컬렉션 내부 구조 노출 없이 순차 접근. Java의 Iterator 인터페이스가 대표 사례
책임 연쇄 (Chain of Responsibility)	요청을 처리할 수 있는 객체가 나타날 때까지 연쇄적으로 전달
인터프리터 (Interpreter)	언어의 문법 규칙을 클래스로 표현하여 해석. SQL 파서, 정규 표현식 등
미디에이터 (Mediator)	객체 간 복잡한 통신을 중재자가 담당. 채팅방 서버가 대표 예
메멘토 (Memento)	객체의 내부 상태를 저장·복원. 문서 편집기의 실행 취소(Ctrl+Z)
상태 (State)	객체의 내부 상태에 따라 행동을 변경. 신호등(빨강/노랑/초록 상태)
비지터 (Visitor)	알고리즘을 객체 구조와 분리. 구조 변경 없이 새 연산을 추가 가능

4. 소프트웨어 테스트

테스트 파트는 화이트박스 vs 블랙박스의 구분과 커버리지 종류, 그리고 테스트 단계가 핵심입니다. 매 회차에 한두 문제씩 꾸준히 나옵니다.

화이트박스 테스트 vs 블랙박스 테스트

구분	화이트박스 테스트	블랙박스 테스트
관점	내부 소스 코드를 보고 테스트	내부 구조를 모르고 입출력만으로 테스트
다른 이름	구조 테스트, 유리 박스 테스트	기능 테스트, 명세 기반 테스트
테스트 기법	구문 커버리지, 결정 커버리지, 조건 커버리지, 경로 커버리지	동치 분할, 경계값 분석, 원인-결과 그래프, 오류 예측
주요 목적	코드의 모든 경로가 실행되는지 확인	요구사항 명세대로 동작하는지 확인

화이트박스 커버리지 — 강도 순서 암기 필수

커버리지는 "테스트가 얼마나 꼼꼼하게 코드를 검증했는지"를 나타냅니다. 강도가 높을수록 더 많은 경우를 검사합니다.

커버리지	설명	강도
구문(Statement) 커버리지	모든 구문(명령문)을 최소 1번 실행	★☆☆☆☆ (가장 약함)
결정(Decision/Branch) 커버리지	모든 분기(if문의 true/false)를 최소 1번씩 실행	★★☆☆☆
조건(Condition) 커버리지	각 조건식의 true/false를 모두 실행	★★★☆☆
조건/결정 커버리지	조건 커버리지 + 결정 커버리지를 동시에 만족	★★★★☆
변경 조건/결정 커버리지 (MC/DC)	각 조건이 독립적으로 전체 결과에 영향을 줌을 확인. 항공기 소프트웨어 기준	★★★★★
다중 조건 커버리지	모든 조건의 모든 조합을 실행. 가장 완벽하지만 경우의 수 폭발	★★★★★+

블랙박스 테스트 기법

기법	설명	예시
동치 분할 (Equivalence Partitioning)	입력 데이터를 동등한 그룹(동치 클래스)으로 나누어 각 그룹에서 대표값 선택	나이 입력(1~120): 유효 클래스(1~120), 무효 클래스(<1, >120)로 분할
경계값 분석 (Boundary Value Analysis)	경계 부분(최소, 최소+1, 최대-1, 최대)에서 오류가 많이 발생하므로 경계값 중심 테스트	나이 1~120이면: 0, 1, 2, 119, 120, 121 테스트
원인-결과 그래프 (Cause-Effect Graphing)	입력 조건(원인)과 출력 결과(결과)의 관계를 그래프로 표현 후 테스트 케이스 도출	여러 입력 조건 조합이 복잡할 때 사용
오류 예측 (Error Guessing)	경험과 직관을 바탕으로 오류가 발생할 것 같은 케이스를 테스터가 직접 예측	입력값 0, NULL, 공백, 최대값 등을 경험적으로 테스트

테스트 단계 — 단위·통합·시스템·인수

단계	대상	주요 특징
단위(Unit) 테스트	개별 모듈·함수·메서드	개발자가 직접 수행. 화이트박스 기법 주로 사용
통합(Integration) 테스트	모듈을 결합한 인터페이스	상향식·하향식·빅뱅·샌드위치 방식으로 수행
시스템(System) 테스트	완성된 전체 시스템	요구사항 명세서와 비교. 기능·비기능 모두 검증
인수(Acceptance) 테스트	사용자 관점에서 전체 시스템	알파(내부 사용자), 베타(외부 사용자) 테스트 포함

5. 소프트웨어 품질과 형상 관리

ISO/IEC 25010 소프트웨어 품질 특성

소프트웨어 품질을 측정하는 국제 표준입니다. 8가지 특성을 영어 이름과 함께 외워두세요.

품질 특성	설명	하위 특성(예시)
기능 적합성 (Functional Suitability)	명시된 요구사항을 올바르게 수행하는 정도	기능 완전성, 기능 정확성, 기능 적절성
성능 효율성 (Performance Efficiency)	주어진 조건에서 자원 사용 대비 성능	시간 반응성, 자원 활용성, 용량
호환성 (Compatibility)	다른 제품·환경과 정보를 교환하는 능력	공존성, 상호운용성
사용성 (Usability)	사용자가 목표를 달성하기 위해 사용하는 용이성	학습성, 운용성, 사용자 오류 방지
신뢰성 (Reliability)	명시된 기간 동안 정상 작동을 유지하는 정도	성숙성, 가용성, 결함 허용성, 복구성
보안성 (Security)	정보 및 데이터를 보호하는 정도	기밀성, 무결성, 부인방지, 책임성
유지보수성 (Maintainability)	수정·개선이 용이한 정도	모듈성, 재사용성, 분석성, 변경성, 시험성
이식성 (Portability)	다른 환경으로 이전할 수 있는 정도	적응성, 설치성, 대체성

형상 관리(Configuration Management)

형상 관리는 소프트웨어 산출물(소스 코드, 문서 등)의 변경을 체계적으로 관리하는 활동입니다.

도구	유형	특징
Git	분산형	로컬 저장소 보유. 오프라인 커밋 가능. 브랜치 전략 유연. 현재 표준
SVN (Subversion)	중앙집중형	중앙 서버에 모든 이력 저장. 접근 제어가 명확. Git 이전의 표준
CVS	중앙집중형	SVN의 이전 버전. 디렉터리 이동·이름 변경이 어려움

6. 실전 문제 풀어보기