23개 이름을 낱개로 외우면 시험장에서 섞인다. 세 무리로 나눈 뒤 설명의 표지 낱말 하나로 이름을 확정한다
왜 이걸 하나 — SW공학 37문항 중 9문항이 패턴이고 11회 중 9회에 나왔다. 2023년 3회와 2025년 3회만 빠졌다.
11회분 220문항 중 이 장의 기출은 9문항이다. 답이 나온 이름은 Proxy(2회) · Abstract Factory(2회) · Singleton · Visitor · Iterator · Adapter · Bridge · Observer 와 분류 이름 「행위 패턴」이다. 2026년 2회 17번은 보기 넷(Builder · Factory Method · Abstract Factory · Prototype)이 전부 생성 패턴이라 무리를 안 뒤 표지로 갈라야 했다.
| 꼴 | 몇 문항 | 무엇을 적나 | 보기 |
|---|---|---|---|
| 설명 → 패턴 이름 | 6 | Proxy · Abstract Factory · Iterator · Adapter | 2023-1회 11번 · 2024-1회 20번 · 2024-2회 7번 · 2025-1회 14번 · 2025-2회 7번 · 2026-2회 17번 |
| 2칸 매칭 | 2 | Singleton · Visitor, Bridge · Observer | 2023-2회 18번 · 2026-1회 3번 |
| 분류 이름 | 1 | 행위(Behavioral) 패턴 | 2024-3회 8번 |
→ 기출 9문항에 나온 이름은 8개뿐이다. 23개 중 나머지 15개가 다음 회차의 후보이고, 훈련 5문항이 그중 12개(Factory Method · Builder · Prototype · Composite · Decorator · Flyweight · Template Method · Chain of Responsibility · Mediator · State · Facade · Memento 등)를 다룬다.
E01 진단의 17번(Abstract Factory)이 이 장이었다. 「외울 것이 많다」는 묶음인데, 패턴은 이름의 원어가 곧 동작이라(Proxy 대리, Adapter 변환기, Observer 관찰자) 원어 뜻으로 외우면 절반은 끝난다.
문항 수는 이 노트의 문제 데이터에서 ch=E17 인 것을 센 값이다(2026-09-14). 패턴 정의는 GoF(Gamma · Helm · Johnson · Vlissides, 1994) 분류를 따랐다.
왜 이걸 하나 — 시험 전날 23개를 무리별로, 표지 낱말과 함께 백지에 적어 본다.
왜 이걸 하나 — 이름을 외우는 것이 아니라 어느 무리인지 먼저 정하는 절차가 있어야 23개가 섞이지 않는다.
설명을 읽고 먼저 정하는 것은 무리다. 「생성 · 인스턴스 · 만든다 · 복제」가 보이면 생성, 「인터페이스 · 감싼다 · 구조 · 트리 · 공유」가 보이면 구조, 「요청 · 상태 · 알고리즘 · 통지 · 순회 · 연산 추가」가 보이면 행위다. 2024년 3회 8번은 이 무리 이름 자체(Observer · Strategy · Command 가 속한 것)를 물었고 답은 행위 패턴이다.
무리가 정해지면 후보가 5 · 7 · 11 로 준다. 그 안에서 설명의 고유한 낱말 하나로 확정한다. 생성이면 「하나만」 Singleton · 「하위 클래스가 결정」 Factory Method · 「객체군 · Kit」 Abstract Factory · 「단계별 조립」 Builder · 「복제」 Prototype.
2026년 2회 17번이 그 절차 그대로다. 보기 넷이 전부 생성 패턴이라 무리로는 못 가르고, 「서로 관련된 객체들의 집합 · Kit」가 Abstract Factory 의 고유 낱말이다. 2024년 1회 20번의 「객체들의 군(family)」도 같은 표지다.
Adapter · Facade · Proxy · Decorator 는 넷 다 어떤 객체를 다른 객체가 감싼다. 갈리는 것은 왜 감싸느냐다. 인터페이스가 안 맞아 바꾸려고 감싸면 Adapter(2025년 1회 14번), 복잡한 여러 객체를 창구 하나로 단순하게 보이려고 감싸면 Facade, 접근을 제어하거나 대신 처리하려고 감싸면 Proxy(2023년 1회 11번 · 2025년 2회 7번), 기능을 덧붙이려고 감싸면 Decorator.
나머지 셋은 모양이 다르다. Bridge 는 추상(무엇을 하나)과 구현(어떻게 하나)을 두 계층으로 떼어 각자 확장한다(2026년 1회 3번). Composite 는 부분과 전체를 같은 인터페이스로 다뤄 트리를 만든다. Flyweight 는 같은 작은 객체를 여러 곳이 공유해 메모리를 아낀다.
행위 11 은 무엇을 캡슐화해 바꿔 끼우느냐로 읽는다. 알고리즘을 바꿔 끼우면 Strategy, 상태에 따라 행동이 바뀌면 State, 뼈대는 두고 단계만 바꾸면 Template Method, 요청 자체를 객체로 만들어 저장 · 취소 · 큐잉하면 Command, 객체의 상태를 저장했다 되돌리면 Memento.
객체 사이의 통신을 다루는 것이 넷이다. 한 객체의 변화를 여럿에게 알리면 Observer(2026년 1회 3번), 여럿의 상호작용을 중재자 하나에 모으면 Mediator, 처리자를 사슬로 엮어 차례로 넘기면 Chain of Responsibility, 컬렉션 안을 노출하지 않고 차례로 꺼내면 Iterator(2024년 2회 7번, 「Cursor」).
Visitor 는 클래스를 고치지 않고 새 연산을 추가하는 것이다(2023년 2회 18번). 「원소 클래스를 수정하지 않고 연산 추가」가 표지고, 「새 연산」이 Decorator 의 「새 기능」과 다른 점은 Visitor 가 여러 클래스에 걸친 연산을 밖에서 정의한다는 것이다. Interpreter 는 문법 규칙을 클래스로 만든다.
표지 낱말이 겹치는 자리가 셋이다. 「취소(Undo)」는 Command(요청을 저장해 두었다 되돌림)와 Memento(상태를 저장해 두었다 되돌림) 둘 다에 있어, 요청을 저장하나 상태를 저장하나로 가른다. 「감싼다」는 3-2 의 넷, 「하나만」은 Singleton 뿐이다.
아키텍처 패턴은 GoF 보다 한 단계 큰 그림이다. MVC 는 데이터(Model) · 화면(View) · 제어(Controller)로 나누고, 파이프-필터는 데이터가 필터를 차례로 지나며, 브로커는 분산 객체 사이를 중개한다. 「전체 구조」를 말하면 아키텍처, 「객체 몇 개의 관계」를 말하면 GoF 다.
왜 이걸 하나 — 설명에서 무리 → 고유 낱말 → 이름 순서로 적는 연습이다.
답 칸에 무리(생성 · 구조 · 행위)를 먼저 적고 이름을 적는다. 이름은 영문(Proxy)과 한글(프록시) 중 문제가 보기로 준 표기를 따르고, 없으면 영문으로 적고 한글을 괄호에 덧붙인다.
특정 객체에 대한 접근을 제어하기 위해 그 객체의 대리자(surrogate)를 두어 원래 객체의 작업을 대신 처리하게 하는 GoF 디자인 패턴은?
답 — 프록시(Proxy). 진짜 객체 앞에 대리인을 세워 접근을 거르거나 미루거나 기록하는 구조 패턴이다.
원리 — 클라이언트는 진짜 객체와 같은 인터페이스를 가진 대리 객체를 부른다. 대리 객체는 요청을 받아 "권한이 있나 확인(보호 프록시)", "진짜 객체를 아직 안 만들었으면 지금 만들기(가상 프록시 · 지연 로딩)", "원격 서버에 대신 전달(원격 프록시)", "결과를 캐시" 같은 일을 한 뒤 필요할 때만 진짜에게 넘긴다. 클라이언트는 대리인인지 진짜인지 모른다 — 그래서 접근 제어를 진짜 객체 코드를 건드리지 않고 끼워 넣을 수 있다. JPA 의 지연 로딩 엔티티, 스프링 AOP 프록시가 이 패턴이다.
따라가기
헷갈리는 자리 — 데코레이터(Decorator)와 섞는 것. 둘 다 같은 인터페이스로 감싸지만, 데코레이터는 "기능을 덧붙이는" 것이 목적이고 프록시는 "접근을 제어하는" 것이 목적이다. 어댑터는 인터페이스를 "바꾸는" 것이라 또 다르다. 같은 문제가 2025-2-07 에 다시 나왔다.
GoF 책 Design Patterns 의 패턴 정의(생성 5 · 구조 7 · 행위 11)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.
① 클래스의 인스턴스를 하나만 생성해 어디서든 참조하게 하는 패턴 ② 원소 클래스를 수정하지 않고 새로운 연산을 추가할 수 있게 하는 행위 패턴
답 — ① 싱글톤(Singleton) ② 비지터(Visitor). "인스턴스 하나만"과 "클래스를 안 고치고 연산 추가"가 각각의 표지다.
원리 — 싱글톤은 생성 패턴이다. 생성자를 private 으로 막고 static 메서드(getInstance)로만 객체를 내주어, 프로그램 전체에서 인스턴스가 하나만 있게 한다 — 설정 · 로그 · 연결 풀처럼 여러 개면 곤란한 것에 쓴다. 비지터는 행위 패턴이다. 자료 구조(원소 클래스들)는 그대로 두고, 그 위에서 할 "연산"을 별도의 방문자 객체로 뺀다. 원소는 accept(visitor) 만 갖고, 새 연산이 필요하면 원소를 고치지 않고 새 방문자 클래스를 하나 더 만든다 — 자료 구조는 안정적이고 연산은 자주 바뀔 때 맞는 패턴이다.
따라가기
헷갈리는 자리 — ②를 데코레이터로 적는 것. 데코레이터는 "객체에 기능을 덧입히는" 구조 패턴이고, 비지터는 "구조를 돌며 연산을 수행하는" 행위 패턴이다. "새로운 연산(operation)"이라는 말과 "행위 패턴"이라는 힌트가 비지터를 가리킨다.
GoF 책 Design Patterns 의 패턴 정의(생성 5 · 구조 7 · 행위 11)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.
구체적인 클래스를 지정하지 않고, 서로 관련된 객체들의 군(family)을 생성하기 위한 인터페이스를 제공하는 생성 패턴은?
답 — 추상 팩토리(Abstract Factory). 서로 어울리는 객체 "묶음"을 구체 클래스 이름 없이 만들어 주는 생성 패턴이다.
원리 — 버튼 · 체크박스 · 창을 만드는데 윈도우용과 맥용이 따로 있다고 하자. 클라이언트가 new WinButton() 처럼 구체 클래스를 직접 쓰면 OS 를 바꿀 때 코드를 전부 고쳐야 한다. 추상 팩토리는 createButton() · createCheckbox() 를 가진 팩토리 인터페이스를 두고, WinFactory · MacFactory 가 각각 자기 계열 부품을 만든다. 클라이언트는 팩토리 하나만 받아 부품을 만들므로 팩토리를 바꾸면 계열 전체가 함께 바뀐다 — "관련된 객체들의 군(family)"을 일관되게 만든다는 것이 핵심이다. 그래서 별명이 Kit 다.
따라가기
헷갈리는 자리 — 팩토리 메서드(Factory Method)를 적는 것. 팩토리 메서드는 "객체 하나"를 만드는 메서드를 하위 클래스가 재정의하는 것이고, 추상 팩토리는 "관련 객체 여러 개(군)"를 만드는 팩토리 객체를 갈아끼우는 것이다. "군 · family · 집합 · Kit" 이 보이면 추상 팩토리다.
GoF 책 Design Patterns 의 패턴 정의(생성 5 · 구조 7 · 행위 11)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.
컬렉션의 내부 구조를 노출하지 않고 요소들에 순차적으로 접근하게 하는 행위 패턴으로, Cursor라고도 불리는 것은?
답 — 이터레이터(Iterator). 컬렉션이 배열인지 리스트인지 트리인지 모르고도 "다음 것 주세요"만으로 순회하게 하는 행위 패턴이다.
원리 — 컬렉션마다 저장 구조가 다르면 순회 코드도 달라진다(배열은 인덱스, 연결 리스트는 next 포인터). 이터레이터는 hasNext() · next() 두 메서드를 가진 순회 객체를 컬렉션이 내주게 해서, 클라이언트는 내부 구조를 전혀 모르고 같은 코드로 돈다. 자바의 Iterator, for-each 문이 그대로 이 패턴이다. 커서(Cursor)라고도 부르는 이유는 "지금 어디까지 읽었나"를 가리키는 위치 표시를 순회 객체가 들고 있기 때문이다 — DB 커서와 같은 발상이다.
따라가기
헷갈리는 자리 — 컴포지트(Composite)와 섞는 것. 컴포지트는 트리 구조를 "만드는" 구조 패턴이고, 이터레이터는 구조를 "도는" 행위 패턴이다. 시험은 별명(Cursor)으로 힌트를 준다 — 옵저버는 Dependents · Publish-Subscribe, 어댑터는 Wrapper, 추상 팩토리는 Kit 다.
GoF 책 Design Patterns 의 패턴 정의(생성 5 · 구조 7 · 행위 11)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.
GoF 디자인 패턴 중 객체 간의 상호작용과 책임 분배를 다루는 패턴 분류는? (Observer, Strategy, Command 등이 속함)
답 — 행위(Behavioral) 패턴. GoF 23개는 생성 5 · 구조 7 · 행위 11 로 나뉘고, 객체 사이의 상호작용과 책임 분배를 다루는 것이 행위 패턴이다.
원리 — 생성 패턴은 "객체를 어떻게 만드나"(싱글톤 · 팩토리 메서드 · 추상 팩토리 · 빌더 · 프로토타입). 구조 패턴은 "클래스 · 객체를 어떻게 조립하나"(어댑터 · 브리지 · 컴포지트 · 데코레이터 · 퍼사드 · 플라이웨이트 · 프록시). 행위 패턴은 "객체들이 어떻게 협력하고 누가 무엇을 책임지나"(옵저버 · 스트래티지 · 커맨드 · 이터레이터 · 템플릿 메서드 · 스테이트 · 비지터 · 미디에이터 · 메멘토 · 책임 연쇄 · 인터프리터). 행위 패턴이 11개로 가장 많고, 이름에 동작(관찰 · 명령 · 전략 · 방문)이 들어간다.
따라가기
헷갈리는 자리 — 세 분류의 개수 5 · 7 · 11 과 소속을 외운다. 자주 틀리는 소속 — 프록시 · 데코레이터 · 퍼사드는 구조, 템플릿 메서드 · 스테이트 · 이터레이터는 행위, 빌더 · 프로토타입은 생성이다. 영문 Behavioral 철자도 같이 적어 둔다.
GoF 책 Design Patterns 의 패턴 정의(생성 5 · 구조 7 · 행위 11)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.
서로 호환되지 않는 인터페이스를 변환해 클래스들을 함께 동작하게 하는 구조 패턴은?
답 — 어댑터(Adapter). 모양이 안 맞는 두 인터페이스 사이에 변환기를 끼워 함께 돌게 하는 구조 패턴이다.
원리 — 클라이언트는 Target 인터페이스를 기대하는데, 쓰고 싶은 기존 클래스(Adaptee)는 다른 메서드 이름 · 형식을 가진다. 어댑터는 Target 을 구현하면서 안에서 Adaptee 의 메서드를 호출해 형식을 맞춘다 — 220V 콘센트에 110V 기기를 꽂는 변환 플러그와 같다. 기존 클래스를 고치지 않고(고칠 수 없는 외부 라이브러리일 때 특히) 재사용할 수 있다. 상속으로 만들면 클래스 어댑터, 합성으로 Adaptee 를 갖고 있으면 객체 어댑터다. 별명은 Wrapper 다.
따라가기
헷갈리는 자리 — 브리지(Bridge)와 섞는 것. 브리지는 "처음부터 추상과 구현을 나눠 설계"하는 것이고, 어댑터는 "이미 있는 안 맞는 것을 나중에 맞추는" 것이다. 퍼사드는 복잡한 것을 "단순하게" 보여 주는 것이라 변환과는 다르다.
GoF 책 Design Patterns 의 패턴 정의(생성 5 · 구조 7 · 행위 11)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.
실제 객체에 대한 접근을 제어하기 위해 대리 객체를 두는 구조 패턴은?
답 — 프록시(Proxy). 2023-1-11 과 같은 문제다 — 실제 객체 앞에 대리 객체를 두어 접근을 제어한다.
원리 — 프록시는 실제 객체(RealSubject)와 같은 인터페이스(Subject)를 구현한다. 클라이언트는 프록시를 실제 객체인 줄 알고 부르고, 프록시가 중간에서 "접근 허용 여부 · 생성 시점 · 원격 전달 · 캐시 · 로그"를 처리한 뒤 실제 객체를 호출한다. 종류로 가상 프록시(무거운 객체를 필요할 때 생성), 보호 프록시(권한 검사), 원격 프록시(네트워크 너머 객체를 지역 객체처럼), 스마트 참조(참조 횟수 세기)가 있다. 접근 제어 코드를 실제 객체 밖으로 빼는 것이 이 패턴의 값어치다.
따라가기
헷갈리는 자리 — 데코레이터로 적는 것. 구조가 거의 같아서(같은 인터페이스로 감싼다) 목적으로 구분한다 — 데코레이터는 "기능 추가", 프록시는 "접근 제어". 문제 문장에 "접근 제어 · 대리"가 있으면 프록시다.
GoF 책 Design Patterns 의 패턴 정의(생성 5 · 구조 7 · 행위 11)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.
① 추상부와 구현부를 분리해 독립적으로 확장할 수 있게 하는 구조 패턴 ② 객체 상태 변화 시 등록된 객체들에게 자동으로 통지하는 행위 패턴
답 — ① Bridge(브리지) ② Observer(옵저버). "추상부와 구현부 분리"와 "상태 변화 자동 통지"가 각각의 표지다.
원리 — 브리지는 구조 패턴이다. "도형(원 · 사각형)"과 "그리는 방식(벡터 · 래스터)"처럼 두 축이 있을 때 상속으로 조합하면 클래스가 곱셈으로 늘어난다(원벡터 · 원래스터 · 사각벡터…). 브리지는 추상부(도형)가 구현부(그리기)를 필드로 가리키게 해서 두 축을 따로 확장한다 — 다리로 잇는다. 옵저버는 행위 패턴이다. 주제(Subject)가 관찰자(Observer) 목록을 갖고, 상태가 바뀌면 notify() 로 등록된 모두에게 알린다 — 주제는 관찰자가 누구인지 몰라도 된다. 이벤트 리스너 · 발행/구독이 이것이다.
따라가기
헷갈리는 자리 — 브리지를 어댑터로 적는 것. 어댑터는 "안 맞는 것을 나중에 맞춤", 브리지는 "처음부터 두 축을 갈라 설계"다. 옵저버를 미디에이터로 적는 것 — 미디에이터는 여러 객체의 대화를 중재자 하나에 모으고, 옵저버는 한 주제의 변화를 여럿에게 뿌린다.
GoF 책 Design Patterns 의 패턴 정의(생성 5 · 구조 7 · 행위 11)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.
다음 설명에 해당하는 디자인 패턴을 보기에서 골라 쓰시오.
구체적인 클래스를 명시하지 않고 서로 관련되거나 의존적인 객체들의 집합을 생성하기 위한 인터페이스를 제공한다. ‘Kit’라고도 한다.
ㄱ. Builder
ㄴ. Factory Method
ㄷ. Abstract Factory
ㄹ. Prototype
답 — ㄷ Abstract Factory. "관련 · 의존적인 객체들의 집합"과 별명 "Kit" 이 결정적이다.
원리 — 생성 패턴 네 개를 구분한다. Builder 는 복잡한 객체 하나를 단계별로 조립한다(빌더.setA().setB().build()). Factory Method 는 객체 생성 메서드를 하위 클래스가 재정의해 "어떤 클래스의 인스턴스를 만들지"를 하위가 정한다 — 객체 하나. Abstract Factory 는 서로 어울려야 하는 객체 여러 개(버튼 · 창 · 메뉴 = 한 테마)를 한 팩토리가 세트로 만들고, 팩토리를 바꾸면 세트 전체가 바뀐다 — 그래서 Kit(공구 세트)이라 부른다. Prototype 은 원본을 복제(clone)해 새 객체를 만든다.
따라가기
헷갈리는 자리 — ㄴ Factory Method 를 고르는 것. 팩토리 메서드는 "하나"를 만들고 하위 클래스가 종류를 정하며 별명은 Virtual Constructor 다. 추상 팩토리는 "집합"을 만들고 별명이 Kit 다. 2024-1-20 과 같은 정의라 두 문제를 같이 묶는다.
GoF 책 Design Patterns 의 패턴 정의(생성 5 · 구조 7 · 행위 11)와 대조했다. 복원 출처 grandlife.co.kr(2026-09-14) — 공식 원문이 아니라 문장이 실제와 다를 수 있다.
① 복잡한 서브시스템들을 하나의 단순한 통합 인터페이스로 제공하여 사용을 쉽게 하는 구조 패턴 ② 객체의 상태를 저장해 두었다가 필요할 때 이전 상태로 복원(Undo)할 수 있게 하는 행위 패턴
답 — ① 퍼사드(Facade) ② 메멘토(Memento). "통합 창구"와 "상태 저장 · 복원"이 각각의 표지다.
원리 — 퍼사드는 구조 패턴이다. 서브시스템 안에 클래스 열 개가 얽혀 있어도, 앞에 "간단한 메서드 몇 개"만 가진 퍼사드 클래스를 세우면 클라이언트는 그것만 부른다 — 건물 정면(facade)만 보고 안의 배관을 모르듯. 결합도가 내려가고 쓰기 쉬워진다. 메멘토는 행위 패턴이다. 객체의 내부 상태를 캡슐화를 깨지 않고 메멘토 객체에 저장해 두었다가, 나중에 그 메멘토로 되돌린다 — 편집기의 실행 취소(Undo), 게임 저장이 이것이다. 원본(Originator)이 메멘토를 만들고, 관리자(Caretaker)가 보관한다.
따라가기
헷갈리는 자리 — 퍼사드를 어댑터로 적는 것. 어댑터는 인터페이스를 "변환"하고, 퍼사드는 여러 개를 "단순화"한다. 메멘토를 커맨드로 적는 것 — 커맨드도 Undo 를 하지만 "요청을 객체로" 만드는 것이 본질이고, 메멘토는 "상태 스냅샷"이 본질이다.
이전 자료의 예상 문제다. GoF 패턴 정의와 대조했다.
① 알고리즘군을 각각 캡슐화하여 실행 중에 동적으로 교체할 수 있게 하는 행위 패턴 ② 요청 자체를 객체로 캡슐화하여 요청의 저장·취소(Undo)·큐잉이 가능하게 하는 행위 패턴
답 — ① 스트래티지(Strategy) ② 커맨드(Command). "알고리즘 교체"와 "요청을 객체로"가 각각의 표지다.
원리 — 둘 다 행위 패턴이다. 스트래티지는 같은 일을 하는 여러 알고리즘(정렬 방식 · 할인 정책 · 경로 계산)을 각각 클래스로 캡슐화하고 같은 인터페이스를 갖게 해서, 실행 중에 갈아끼운다 — if-else 로 알고리즘을 고르던 코드가 없어진다. 커맨드는 "무엇을 해 달라"는 요청 자체를 객체로 만든다. execute() 를 가진 명령 객체를 만들어 두면 큐에 넣어 나중에 실행하거나, 로그로 남기거나, undo() 를 구현해 취소할 수 있다 — 메뉴 항목 · 버튼 클릭 · 트랜잭션이 이것이다.
따라가기
헷갈리는 자리 — 스트래티지를 스테이트(State)로 적는 것. 구조가 같지만 스테이트는 "객체 상태에 따라" 자동으로 행동이 바뀌고, 스트래티지는 "클라이언트가 골라서" 알고리즘을 바꾼다. 커맨드를 메멘토로 적는 것 — 메멘토는 상태 저장, 커맨드는 요청 저장이다.
이전 자료의 예상 문제다. GoF 패턴 정의와 대조했다.
왜 이걸 하나 — 패턴은 같은 무리 안의 이웃과 바꿔 적어서 깎인다.
| 자리 | 새는 꼴 | 적는 법 | 기출 |
|---|---|---|---|
| Factory 둘 | Abstract Factory 자리에 Factory Method | 「군 · 집합 · Kit」면 Abstract Factory, 「하위 클래스가 결정」이면 Factory Method | 2024-1회 20번 · 2026-2회 17번 |
| 감싸는 넷 | Proxy 를 Adapter 나 Decorator 로 | 접근 제어 = Proxy, 변환 = Adapter, 단순화 = Facade, 기능 추가 = Decorator | 2023-1회 11번 · 2025-1회 14번 · 2025-2회 7번 |
| Undo 둘 | Memento 자리에 Command | 상태 저장 · 복원 = Memento, 요청 객체화 · 큐잉 = Command | 예상 1회 18번 · 예상 2회 18번 |
| Bridge · Adapter | 둘을 바꾼다 | 「추상과 구현 분리 · 독립 확장」 = Bridge, 「호환 안 되는 인터페이스」 = Adapter | 2026-1회 3번 |
| 표기 | 「이터레이터」를 「이터레이션」으로, 「옵저버」를 「옵서버」로 | 영문으로 적으면 안전 — Iterator · Observer | 2024-2회 7번 · 2026-1회 3번 |
| 분류 이름 | 「행동 패턴」「동작 패턴」 | 행위(Behavioral) 패턴. 생성(Creational) · 구조(Structural) | 2024-3회 8번 |
| 보기 기호 | 보기가 있는데 이름을 적는다 | 「기호로」면 ㄷ, 「골라 쓰시오」면 보기의 표기 그대로 | 2026-2회 17번 |
영문 표기는 대소문자를 문제의 보기대로 따른다. 보기가 없으면 첫 글자 대문자(Abstract Factory · Chain of Responsibility)가 가장 흔한 정답표 표기다.
왜 이걸 하나 — 기출에 아직 안 나온 15개 중 12개가 여기 있다.
5문항은 분류, 구조 셋(Composite · Decorator · Flyweight), 행위 넷(Template Method · Chain of Responsibility · Mediator · State), 생성 셋(Builder · Prototype · Factory Method), MVC 다. 정답은 GoF 정의로 대조했다.
다음 GoF 패턴을 생성 · 구조 · 행위로 분류하시오.
Factory Method, Decorator, Template Method, State, Builder, Composite
답 — 생성: Factory Method · Builder / 구조: Decorator · Composite / 행위: Template Method · State.
원리 — 판정 질문은 "이 패턴이 답하는 물음이 무엇인가"다. 생성 패턴은 "객체를 어떻게 만드나" — Factory Method(생성 메서드를 하위가 정함), Builder(단계별 조립). 구조 패턴은 "객체를 어떻게 조립 · 감싸나" — Decorator(기능을 덧입힘), Composite(트리로 묶음). 행위 패턴은 "객체들이 어떻게 협력하나" — Template Method(뼈대는 상위, 세부는 하위), State(상태에 따라 행동 변경). 이름에 만들기(Factory · Builder · Prototype)가 있으면 생성, 짜임새(Composite · Decorator · Bridge · Adapter)면 구조, 동작(Method · State · Command · Observer)이면 행위다.
따라가기
이 노트에서 만든 변형 문제다. GoF 패턴 정의 · MVC 표준 설명과 대조했다.
다음 설명에 해당하는 구조 패턴을 각각 쓰시오.
① 객체들을 트리 구조로 구성해 부분과 전체를 같은 방식으로 다룬다
② 객체에 동적으로 새로운 기능(책임)을 덧붙인다
③ 많은 수의 작은 객체를 공유해 메모리를 아낀다
답 — ① Composite ② Decorator ③ Flyweight.
원리 — 컴포지트는 폴더와 파일처럼 "부분(잎)"과 "전체(가지)"가 같은 인터페이스를 갖게 해서, 클라이언트가 하나든 묶음이든 같은 방법으로 다루게 한다 — 트리 구조가 표지다. 데코레이터는 원래 객체를 같은 인터페이스의 포장 객체로 감싸 기능을 하나씩 덧입힌다 — 자바 IO 의 BufferedReader(new FileReader()) 가 이것이며, 상속 없이 실행 중에 기능을 조합한다. 플라이웨이트는 글자 · 나무 · 총알처럼 수만 개인 작은 객체의 "공유 가능한 부분(내재 상태)"을 하나만 만들어 공유하고, 달라지는 부분(외재 상태)만 밖에서 넘겨 메모리를 아낀다.
따라가기
이 노트에서 만든 변형 문제다. GoF 패턴 정의 · MVC 표준 설명과 대조했다.
다음 설명에 해당하는 행위 패턴을 각각 쓰시오.
① 알고리즘의 뼈대를 상위 클래스에 두고 세부 단계만 하위 클래스가 재정의한다
② 요청을 처리할 수 있는 객체들을 사슬로 엮어 차례로 넘긴다
③ 객체 간의 복잡한 상호작용을 중재자 객체 하나에 모은다
④ 객체의 내부 상태에 따라 행동이 바뀌게 한다
답 — ① Template Method ② Chain of Responsibility ③ Mediator ④ State.
원리 — 템플릿 메서드는 상위 클래스가 알고리즘의 순서(뼈대)를 final 메서드로 고정하고, 그 안의 몇 단계만 추상 메서드로 열어 하위 클래스가 채우게 한다 — 순서는 못 바꾸고 내용만 바꾼다. 책임 연쇄는 처리자 객체들을 사슬로 엮어 요청을 앞에서부터 넘기고, 처리할 수 있는 객체가 처리한다 — 서블릿 필터 체인이 이것이다. 미디에이터는 객체들이 서로 직접 부르지 않고 중재자 하나를 통해 대화하게 해서 다대다 결합을 일대다로 줄인다 — 채팅방 서버, 관제탑. 스테이트는 상태마다 클래스를 두어 객체의 상태가 바뀌면 행동 클래스가 바뀐다 — 자판기(동전 없음 · 동전 있음 · 판매 중).
따라가기
이 노트에서 만든 변형 문제다. GoF 패턴 정의 · MVC 표준 설명과 대조했다.
생성 패턴 중 다음 설명에 해당하는 것을 각각 쓰시오.
① 복잡한 객체를 단계별로 조립해 만들고, 같은 절차로 다른 표현을 만들 수 있다
② 원본 객체를 복제해 새 객체를 만든다
③ 객체 생성을 하위 클래스에 맡겨 어떤 클래스의 인스턴스를 만들지 하위 클래스가 정한다
답 — ① Builder ② Prototype ③ Factory Method.
원리 — 빌더는 생성자 인자가 열 개쯤 되는 복잡한 객체를 setName() · setAge() 처럼 단계별로 채운 뒤 build() 로 완성한다. 같은 조립 절차(Director)에 다른 빌더를 꽂으면 다른 표현(HTML 문서 · PDF 문서)이 나온다. 프로토타입은 이미 있는 객체를 clone() 으로 복제해 새 객체를 만든다 — 생성 비용이 크거나(DB 조회 결과) 종류가 실행 중에 정해질 때 쓴다. 팩토리 메서드는 createProduct() 를 추상 메서드로 두고, 하위 클래스가 그것을 재정의해 어떤 구체 클래스를 new 할지 정한다 — 상위 코드는 구체 클래스 이름을 모른다.
따라가기
이 노트에서 만든 변형 문제다. GoF 패턴 정의 · MVC 표준 설명과 대조했다.
MVC 아키텍처 패턴의 세 요소가 각각 맡는 일을 쓰시오.
① Model ② View ③ Controller
답 — ① Model: 데이터와 업무 로직 ② View: 화면 표시 ③ Controller: 입력을 받아 Model 과 View 를 잇는 흐름 제어.
원리 — MVC 는 GoF 패턴이 아니라 아키텍처 패턴이다. 한 화면 코드에 데이터 처리 · 화면 그리기 · 입력 처리가 섞이면 하나를 고칠 때 셋이 같이 깨진다. 그래서 셋을 갈라 놓는다. Model 은 데이터와 그것을 다루는 규칙(재고 차감 · 잔액 검증)을 갖고 화면을 모른다. View 는 Model 의 데이터를 사용자에게 보여 주기만 한다(HTML · 템플릿). Controller 는 사용자의 요청을 받아 Model 에 일을 시키고 결과를 어느 View 로 보여 줄지 정한다 — 스프링의 @Controller 가 이것이다. 이렇게 하면 화면을 바꿔도 Model 은 그대로고, 같은 Model 을 웹 · 앱 View 가 공유한다.
따라가기
이 노트에서 만든 변형 문제다. GoF 패턴 정의 · MVC 표준 설명과 대조했다.
왜 이걸 하나 — 아래를 안 보고 적을 수 있어야 이 장이 끝난다.