# 서두 2026년 1차 정처기 필기/실기 한방에 통과한 사람 나야 나 ☆~(ゝ。∂)
뭔가 공부하고 싶은데 자격증도 겸사겸사 따면 좋을 거 같아서 정처기 도전했다. 근데 하다보니 공부는 뒷전이고 효율의 한국인답게 기출풀개로 전락해버렸다. (출제 범위에 있는 개념 다 공부하면 올해 안에 시험 못 봄 ㅠ)
우선은 응시해보는 거에 의의를 두고 기출 문제를 무작정 외우고 시험장 들어갔다. 솔직히 시험 치고나서 필기는 붙을 줄 예상했는데 실기는 진짜 천운으로 붙었다. 전혀 모르는 개념의 약어인데 그냥 한국어 설명을 영어로 번역해서 앞글자만 따서 맞춘 문제도 있었다 껄껄.
시험 보고 나니 오히려 마음의 여유가 생겨서 이제는 정처기에 나오는 개념들에 대해 공부다운 공부를 해보려고 한다. 첫번째로 공부할 개념은 기출 최다 빈출 개념인 **GoF 디자인 패턴**이다. 시험볼 때는 어떤 패턴인지 정의를 외우는 데에 급급했다면, 이번에는 이게 왜 필요한지, 언제 쓰는지, 이미 쓰고 있었는지에 집중해서 보고자 한다. # 공부한 내용 ## Strategy 패턴 ### 1. 정의 - 알고리즘을 교체 가능한 단위로 캡슐화하는 패턴 - 즉, 하나의 목적을 위해서 여러 **전략(Strategy)** 을 바꿔 끼울 수 있게 만드는 패턴 ### 2. 언제/어떻게 쓸까? `if/else`나 `switch`를 써서 타입에 따라 다른 알고리즘을 처리하고 있고, 그 종류가 앞으로 계속 늘어날 가능성이 있을 때 써야 한다. ```js class PriceCalculator { calculate(price, discountType, value) { if (discountType === 'none') return price; if (discountType === 'fixedAmount') return Math.max(0, price - value); if (discountType === 'percentage') return price * (1 - value / 100); throw new Error('unknown discount type'); } } ``` 위 내용을 보면 새 할인 정책이 생길 때마다 `calculate()` 메서드 내부를 계속 고쳐야 한다. 기존 코드를 안 건드리고 새 알고리즘을 추가할 수 있어야 한다는 **OCP(Open-Closed Principle)** 원칙에 위배되기 때문에 Strategy 패턴을 써서 해결해보겠다. 아래는 Strategy 패턴 적용 후의 모습이다. ```js // 1. Strategies const discountStrategies = { none: (price) => price, fixedAmount: (price, amount) => Math.max(0, price - amount), percentage: (price, percent) => price * (1 - percent / 100), }; // 2. Context // 전략을 "실행"만 할 뿐, 전략이 뭘 하는지는 관심 없음 class PriceCalculator { constructor(strategy) { this.strategy = strategy; } setStrategy(strategy) { this.strategy = strategy; } calculate(price, ...args) { return this.strategy(price, ...args); } } // 3. 사용 const calculator = new PriceCalculator(discountStrategies.none); console.log(calculator.calculate(10000)); // 10000 calculator.setStrategy(discountStrategies.percentage); console.log(calculator.calculate(10000, 20)); // 8000 (20% 할인) calculator.setStrategy(discountStrategies.fixedAmount); console.log(calculator.calculate(10000, 3000)); // 7000 (3000원 할인) // 4. 새 할인 정책 추가 // PriceCalculator는 단 한 줄도 안 건드림 discountStrategies.buyOneGetOneFree = (price) => price / 2; calculator.setStrategy(discountStrategies.buyOneGetOneFree); console.log(calculator.calculate(10000)); // 5000 ``` Strategy 패턴이 적용된 코드에서는 `PriceCalculator(Context)`가 한 번도 수정된 적이 없다. 새 할인 정책은 `discountStrategies` 객체에 함수 하나 추가하는 것으로 끝난다. ### 3. 이미 어디서 써봤을까? - `array.sort(compareFn)` : 정렬 전략을 함수로 갈아끼우기 - `array.filter(predicate)` / `array.map(fn)` : "어떻게 걸러낼지", "어떻게 변환할지"를 함수로 주입 즉, JavaScript에서 **콜백 함수를 인자로 넘기는 습관 자체가 이미 Strategy 패턴**이라고 볼 수 있다.
## Observer 패턴 ### 1. 정의 - 어떤 주체(Subject)의 상태가 바뀌었을 때, 그 변화에 관심 있는 여러 관찰자(Observer)들에게 자동으로 알려주는 패턴 - 하나의 변화가 여러 곳에 퍼지는 1:N 관계 ### 2. 언제/어떻게 쓸까? 한 곳의 상태 변화에 반응해야 할 대상이 여러 개이고, 그 개수·종류가 앞으로도 계속 늘어날 수 있을 때 사용하는 패턴이다. Subject 코드 안에 반응해야 할 대상들이 하드코딩되어 있고, 새 대상이 추가될 때마다 그 코드를 계속 고쳐야 한다면 Observer 패턴을 고려해야 한다.
주문이 완료되면 이메일 발송, SMS 발송, 로그 기록을 해야 한다고 가정해보자. ```js class OrderService { completeOrder(order) { EmailService.send(order); SmsService.send(order); LogService.log(order); } } ``` OrderService가 EmailService, SmsService, LogService를 전부 직접 알고 있어야 하고, 강하게 결합되어 있다. '슬랙 채널 알림' 같이 새 알림 방식이 생기면 이 클래스를 또 열어서 고쳐야 한다. Strategy 때와 똑같이 OCP 위반 문제가 있다. ```js // 1. Subject // 구독자 목록을 관리하고, 상태 변화 시 통지만 함 class OrderService { constructor() { this.observers = []; } subscribe(observer) { this.observers.push(observer); } unsubscribe(observer) { this.observers = this.observers.filter((o) => o !== observer); } notify(order) { this.observers.forEach((observer) => observer(order)); } completeOrder(order) { // 주문 처리 로직... this.notify(order); // "주문이 완료됐다"고만 알릴 뿐, 누가 반응할지는 관심 없음 } } // 2. Observer들 // 각자 알아서 구독 const orderService = new OrderService(); orderService.subscribe((order) => console.log(`이메일 발송: 주문 ${order.id}`)); orderService.subscribe((order) => console.log(`SMS 발송: 주문 ${order.id}`)); orderService.subscribe((order) => console.log(`로그 기록: 주문 ${order.id}`)); orderService.completeOrder({ id: 1 }); // 이메일 발송: 주문 1 // SMS 발송: 주문 1 // 로그 기록: 주문 1 // 3. 새 알림 채널 추가 // OrderService는 한 글자도 안 건드림 orderService.subscribe((order) => console.log(`슬랙 발송: 주문 ${order.id}`)); ``` 위에서 OrderService는 EmailService, SmsService가 뭔지 전혀 모르고, 목록에 있는 함수들을 순서대로 호출한다는 것만 안다. 새 알림 채널을 추가하고 싶으면 subscribe만 호출하면 끝이다. Strategy 때와 마찬가지로 기존 코드를 재수정할 필요가 없다.
### 3. 이미 어디서 써봤을까? - `element.addEventListener('click', handler)` : element(Subject)는 몇 개의 핸들러가 붙어있는지, 그 핸들러가 뭘 하는지 전혀 모른다. 그냥 클릭이 발생하면 등록된 모든 핸들러를 순서대로 호출한다. - `Node.js EventEmitter`: Node.js에서 이미 만들어놓은 observer - .on('event', listener) = subscribe - .emit('event', ...args) = notify - .off(eventName, listener) = unsubscribe - `Redux store.subscribe(listener)`: state가 바뀔 때마다 등록된 모든 리스너(주로 React 컴포넌트 리렌더 트리거)를 호출
## Iterator 패턴 ### 1. 정의 - 컬렉션의 내부 구조가 어떻게 생겼는지 몰라도, 그 안의 요소들을 순서대로 하나씩 꺼내볼 수 있는 통일된 방법을 제공하는 패턴 - 핵심은 **순회하는 방법**과 **컬렉션이 내부적으로 어떻게 저장돼 있는지**를 분리하는 것 ### 2. 언제 쓸까? - 컬렉션의 내부 구현을 몰라도 되게 만들고 싶을 때 - 서로 다른 자료구조 여러 개를 동일한 방식으로 순회하고 싶을 때 — 배열이든 Set이든 Map이든 for...of로 똑같이 돌 수 있는 것처럼 - 컬렉션 내부 구조가 나중에 바뀔 수 있는데 그때마다 그걸 순회하던 바깥 코드까지 다 같이 고치고 싶지 않을 때 ### 3. 어떻게 쓸까? ```js class Bookshelf { constructor() { this.books = []; // 내부적으로 배열을 씀 } addBook(book) { this.books.push(book); } } const shelf = new Bookshelf(); shelf.addBook('클린 코드'); shelf.addBook('리팩토링'); // 순회하려면 "Bookshelf가 내부에 books라는 배열을 갖고 있다"는 걸 알아야 함 for (let i = 0; i < shelf.books.length; i++) { console.log(shelf.books[i]); } ``` 위 구조에서는 shelf.books라는 이름과 그게 배열이라는 사실까지 알아야 한다. 나중에 Bookshelf를 배열에서 Map이나 연결 리스트로 바꾸면 이걸 순회하던 외부 코드가 깨진다. ```js class Bookshelf { constructor() { this.books = []; } addBook(book) { this.books.push(book); } [Symbol.iterator]() { let index = 0; const books = this.books; return { next() { if (index < books.length) { return { value: books[index++], done: false }; } return { value: undefined, done: true }; }, }; } } const shelf = new Bookshelf(); shelf.addBook('클린 코드'); shelf.addBook('리팩터링'); for (const book of shelf) { console.log(book); } // 클린 코드 // 리팩터링 ``` 이제 외부 코드는 shelf.books라는 필드가 존재하는지조차 모르지만 for...of는 그냥 [Symbol.iterator]()를 호출해서 { next() {...} } 형태의 객체(이터레이터)를 받고, next()를 반복 호출해서 { value, done }을 받는 약속(프로토콜) 만 지키면 된다. 이제 Bookshelf 내부를 배열 대신 Map이나 연결 리스트로 바꿔도, [Symbol.iterator] 메서드 내부만 고치면 되고 바깥의 for...of 코드는 바뀌지 않는다.
참고로 제너레이터 문법을 쓰면 훨씬 짧게 쓸 수 있다: ```js class Bookshelf { constructor() { this.books = []; } addBook(book) { this.books.push(book); } *[Symbol.iterator]() { yield* this.books; } } ``` ### 4. 이미 어디서 써봤을까? - `for...of` : 루프 자체가 Iterator 패턴 위에 세워진 문법 - `array.entries(), array.keys(), array.values()` : 전부 이터레이터를 반환 - `제너레이터 함수(function*)` : 이터레이터를 쉽게 만들게 해주는 JS 문법 - `const arr = [...shelf];` : 스프레드 연산자 - `const [first] = shelf;` : 구조 분해 할당 - `Array.from(shelf);` : 배열이 아닌 것을 진짜 배열로 변환해주는 함수 ## Command 패턴 ### 1. 정의 - **요청을 객체로 캡슐화**해서 실행부와 분리하는 패턴 - 패턴의 이름이 command인 이유는 군대에서의 상명하복처럼 실행하는 측은 요청이 뭔지 몰라도 무조건 실행하기 때문이다. (그렇다고 요청과 실행 사이에 위계질서가 있다는 뜻은 아님)
**Cf. Strategy와 헷갈리는 지점** Strategy와 Command 패턴 둘 다 **동작을 함수/객체로 캡슐화해서 들고 다닌다**라는 개념이 공통돼서 헷갈릴 수 있다. 하지만 두 패턴이 방점을 찍은 지점이 다르다는 것을 알면 헷갈리지 않을 수 있다.
- **Strategy**: "이 알고리즘들 중 어떤 걸로 할지 고르는 것"이 목적으로, Context는 전략 하나를 골라 즉시 실행한다. - **Command**: "이 요청 자체를 나중에 실행하거나, 여러 번 실행하거나, 되돌릴 수 있게" 포장하는 게 목적으로, 반환값보다 실행 시점을 미루는 것 / 실행 이력 / 되돌리기 능력이 핵심이다. ### 2. 언제 쓸까? - **누가 무슨 요청했는지**와 **그 요청을 어떻게 실행/취소하는지**를 분리하고 싶을 때 - "실행"과 "실행 취소"를 함께 관리해야 할 때 - 요청을 즉시 실행하지 않고 큐에 쌓았다가 나중에 순서대로 실행해야 할 때 - 실행된 작업들의 이력을 남기고 재실행해야 할 때 - 여러 명령을 하나로 묶어서 한 번에 실행해야 할 때 ### 3. 어떻게 쓸까? ```js class TextEditor { constructor() { this.text = ''; } addText(str) { this.text += str; } } const editor = new TextEditor(); editor.addText('Hello'); editor.addText(' World'); ``` 위 코드에서 방금 한 작업만 취소하고 싶다면 editor 안에 히스토리 스택을 직접 넣고, undo 로직을 editor 내부에 추가해야 한다. ```js // 캡슐화된 요청 class AddTextCommand { constructor(editor, text) { this.editor = editor; this.text = text; } execute() { this.editor.text += this.text; } undo() { this.editor.text = this.editor.text.slice(0, -this.text.length); } } class TextEditor { constructor() { this.text = ''; } } // 이력 관리 class CommandManager { constructor() { this.history = []; } execute(command) { command.execute(); this.history.push(command); } undo() { const command = this.history.pop(); if (command) command.undo(); } } const editor = new TextEditor(); const manager = new CommandManager(); // 실행 manager.execute(new AddTextCommand(editor, 'Hello')); manager.execute(new AddTextCommand(editor, ' World')); // 실행 취소 manager.undo(); ``` 수정된 코드에서 TextEditor는 "undo"라는 개념을 몰라도 된다. undo 기능은 각 AddTextCommand 객체가 들고 있고, CommandManager는 그걸 순서대로 쌓았다 꺼내는 일만 한다. ### 4. 이미 어디서 써봤을까? - `command line` : - 셸 소스코드 안에는 요청 로직이 없고(cli 프로그램 따로 설치해야 됨) - 실행 후에도 이력이 남아있고 - 다시 실행 가능하며 - 여러개를 묶어서 하나로 실행할 수 있는 전형적인 command 패턴 - `Redux의 action` : - action(요청 객체) → dispatch → reducer(실행) - 요청과 실행이 분리됨 - `텍스트 에디터` : 사용자가 과거에 한 요청의 이력을 쌓고 연속적으로 실행취소할 수 있음 # 후기 존경하는 AI 선생님께 GoF 디자인 패턴을 사사했는데 내용이 너무 많다보니 handoff.md를 작성해놓고 계속 세션을 새로 생성하면서 대화를 이어 나갔다. 어차피 내가 한 대화 기록일 테니 따로 handoff.md 파일을 읽어보지 않았는데 어쩌다 열어보니 이런 내용이 있더라. **사용자 학습 스타일 메모** - 정의 암기보다 "왜 필요한가"에 집중하길 원함 - Before/After 코드 비교로 이해하는 걸 선호 - 이미 알고 있는 JS 관용구와 연결지어 설명하면 이해가 빠름 - 개념이 조금이라도 애매하면 바로 "이게 무슨 말이야?" 하고 파고드는 스타일 — 세밀하고 구체적인 재설명을 원함, 두루뭉술한 답변은 피할 것 - 직전 답변에서 쓴 특정 문장/단어를 그대로 인용하며 되묻는 경우가 많음 — 답변 시 그 원문 표현을 다시 가져와서 정확히 대응시켜 설명할 것 - 새 패턴을 배울 때 "이거 사실 전에 배운 패턴이랑 같은 거 아니야?"처럼 스스로 유사점을 찾아 비교하려는 경향이 있음 — 틀렸을 때 무조건 아니라고 하지 말고, 어느 지점까지는 맞는 관찰인지 인정한 뒤 정확한 차이(의도/목적)를 짚어줄 것 선생님 제가 귀찮으셨던 건 아니죠. 멍청해서 죄송해요 ㅠㅠ 덕분에 아무 죄책감과 쪽팔림 없이 바보 질문을 남발했습니다. 탄생해주셔서 감사합니다.
정처기 볼 때는 정의랑 패턴 이름이 도대체 무슨 연관이 있는지 모르겠어서 외우기 힘들었는데 역시 개념을 조금이라도 이해해야 외우기도 좀 더 수월하다. 다음에는 구조 패턴 공부해야징~