소프트웨어 설계는 "용어 매칭"이 시험의 전부
이 과목은 코드 문제가 아니라 개념과 용어의 정확한 매칭으로 구성됩니다. 디자인 패턴 설명을 주고 이름을 쓰라, 응집도 유형 중 가장 강한 것을 고르라, UML에서 이 선이 무엇을 의미하느냐 — 이런 식이에요.
외울 게 많아 보여도, 시험에 나오는 키워드는 정해져 있기 때문에 우선순위를 정해 암기하면 효율이 좋습니다.
UML 다이어그램 — 구조 vs 행위
UML은 크게 두 갈래로 나뉩니다.
| 구분 | 종류 |
|---|
| 구조 다이어그램 | 클래스, 객체, 컴포넌트, 배치, 패키지, 복합 구조 |
| 행위 다이어그램 | 유스케이스, 시퀀스, 활동, 상태, 커뮤니케이션, 타이밍 |
단답으로 "시퀀스 다이어그램은 구조/행위 중 무엇인가?" 같은 문제가 나옵니다. 답은 행위 쪽입니다(시간의 흐름을 나타내니까요).
클래스 다이어그램 관계
| 관계 | 표기 | 의미 |
|---|
| 연관(Association) | 실선 | 두 클래스가 연결됨 |
| 의존(Dependency) | 점선 화살표 | 잠시 사용 |
| 일반화(Generalization) | 속이 빈 삼각형 | 상속 관계 |
| 실체화(Realization) | 속이 빈 삼각형 + 점선 | 인터페이스 구현 |
| 집합(Aggregation) | 속이 빈 마름모 | 부분이 전체 없이 존재 가능 |
| 합성(Composition) | 속이 찬 마름모 | 부분이 전체와 생명주기 같음 |
집합(aggregation)과 합성(composition)의 차이가 자주 출제됩니다. "전체가 사라지면 부분도 같이 사라지는가?"가 기준이에요. 같이 사라지면 합성, 아니면 집합.
유스케이스 관계
| 관계 | 의미 |
|---|
| include | 반드시 포함되는 기능 (예: 결제 → 로그인 확인) |
| extend | 조건에 따라 선택적으로 확장 |
| 일반화 | 공통 기능을 상위 유스케이스로 |
응집도와 결합도
응집도(Cohesion) : 하나의 모듈 안 기능들이 얼마나 밀접한가. 높을수록 좋음.
| 강도 | 응집도 유형 | 설명 |
|---|
| 강함 | 기능적 응집도 | 단일 기능만 수행 |
| ↑ | 순차적 응집도 | 이전 출력을 다음 입력으로 |
| ↑ | 교환적 응집도 | 같은 데이터 활용 |
| ↑ | 절차적 응집도 | 특정 순서로 실행 |
| ↑ | 시간적 응집도 | 같은 시간대에 실행 (예: 초기화) |
| ↑ | 논리적 응집도 | 비슷한 종류 기능 묶음 |
| 약함 | 우연적 응집도 | 관련 없는 기능을 우연히 묶음 |
결합도(Coupling) : 모듈 간 의존 정도. 낮을수록 좋음.
| 강도 | 결합도 유형 | 설명 |
|---|
| 약함 | 자료(Data) 결합도 | 매개변수로 값만 주고받음 |
| ↑ | 스탬프(Stamp) 결합도 | 자료 구조 전체를 매개변수로 |
| ↑ | 제어(Control) 결합도 | 제어 정보를 매개변수로 (플래그) |
| ↑ | 외부(External) 결합도 | 외부 환경(파일 등)을 공유 |
| ↑ | 공통(Common) 결합도 | 전역 변수 공유 |
| 강함 | 내용(Content) 결합도 | 다른 모듈의 내부 직접 참조 |
"응집도는 높을수록, 결합도는 낮을수록 좋다" — 한 줄 요약으로 단답에 자주 등장합니다.
SOLID — 객체지향 5원칙
| 원칙 | 이름 | 핵심 |
|---|
| S | 단일 책임 원칙(SRP) | 클래스는 하나의 책임만 |
| O | 개방-폐쇄 원칙(OCP) | 확장엔 열려 있고, 수정엔 닫혀 있게 |
| L | 리스코프 치환 원칙(LSP) | 자식이 부모 자리를 대체해도 문제 없어야 함 |
| I | 인터페이스 분리 원칙(ISP) | 크고 두꺼운 인터페이스 → 작게 쪼개기 |
| D | 의존 역전 원칙(DIP) | 구체 클래스가 아닌 추상화에 의존 |
단답으로는 "설명 → 원칙 이름"이 전부입니다. 특히 OCP와 DIP가 디자인 패턴과 연계돼 자주 나와요.
디자인 패턴 — 생성 / 구조 / 행위
| 분류 | 패턴 (대표) |
|---|
| 생성 | Singleton, Factory Method, Abstract Factory, Builder, Prototype |
| 구조 | Adapter, Bridge, Composite, Decorator, Facade, Proxy |
| 행위 | Observer, Strategy, Command, Template Method, Iterator, State |
자주 나오는 5개는 꼭
| 패턴 | 설명 |
|---|
| Singleton | 인스턴스를 하나만 생성해 전역에서 공유 |
| Factory Method | 객체 생성을 서브클래스에 위임 |
| Observer | 상태 변경 시 관련 객체에 자동 통지 |
| Strategy | 알고리즘을 캡슐화해 런타임에 교체 |
| Adapter | 호환되지 않는 인터페이스를 서로 연결 |
실기에서는 "다음 설명에 해당하는 디자인 패턴은?" 형태로 나옵니다. 위 5개만 정확히 써낼 수 있으면 디자인 패턴 문제는 거의 다 맞힙니다.
요구사항 분석
기능 요구사항 : 시스템이 무엇을 해야 하는가 (로그인, 결제 등)
비기능 요구사항 : 어떻게 해야 하는가 (성능, 보안, 가용성, 사용성, 유지보수성 등)
요구사항 도출 기법
| 기법 | 설명 |
|---|
| 인터뷰 | 이해관계자와 직접 대화 |
| 설문 | 다수의 응답 수집 |
| 브레인스토밍 | 아이디어 자유롭게 제시 |
| 프로토타이핑 | 시제품을 통한 검증 |
| 워크숍 / JAD | 이해관계자 공동 회의 |
애자일과 전통적 방법론
| 방법론 | 특징 |
|---|
| 폭포수(Waterfall) | 순차적 진행, 변경 수용 어려움 |
| 프로토타입 | 요구사항 불확실 시 시제품 먼저 |
| 나선형(Spiral) | 위험 분석 기반, 대형 프로젝트 |
| V모델 | 개발 단계마다 대응 테스트 |
| 애자일(Agile) | 반복·점진, 변화 수용 |
애자일 하위 방법론
| 이름 | 핵심 |
|---|
| Scrum | 스프린트(2–4주) 단위 반복, 일일 스탠드업 |
| XP | 짝 프로그래밍, TDD, 지속적 통합 |
| Kanban | 작업 흐름 시각화, WIP 제한 |
| Lean | 낭비 제거, 가치 흐름 최적화 |
자주 틀리는 포인트
| 함정 | 정답 |
|---|
| 시퀀스 다이어그램 | 구조 아니라 행위 |
| 집합 vs 합성 | 생명주기 공유 여부 |
| 응집도 강함 | 기능적 응집도 (단일 기능) |
| 결합도 약함 | 자료 결합도 (값만 전달) |
| OCP | 수정에 닫혀, 확장에 열려 |
| Singleton | 생성 패턴이지 행위 패턴 아님 |
이 과목은 문제를 많이 풀면서 키워드 감을 익히는 게 가장 효과적이에요. 처음 보면 비슷해 보여도, 반복하면 "이 설명은 Observer" 하는 순간 기억이 딱 붙습니다.
정리
소프트웨어 설계는 시험에 나오는 키워드 셋 자체가 고정돼 있는 과목입니다. UML의 구조/행위 분류, 응집도/결합도 순서, 디자인 패턴 5종, SOLID 5개 — 이것만 손으로 써서 외워두면 단답형은 거의 전부 커버됩니다.
직접 문제를 풀어보세요
매번 새로운 모의고사와 무한 풀이 모드로 실전 감각을 키울 수 있습니다.