최영선의 블로그

GoF 책이 나온 1994년, 저자들이 주로 쓰던 언어는 C++과 Smalltalk였습니다. 이후 Java가 패턴 교육의 사실상 표준 언어가 되면서, 많은 개발자가 패턴을 "클래스 계층으로 표현하는 것"이라고 무의식적으로 받아들이게 되었습니다. 저는 Python으로 처음 Strategy를 구현할 때 ABC를 만들고 구현 클래스를 세 개 작성한 뒤, 동료에게 "그냥 함수 넘기면 되지 않나요?"라는 리뷰를 받고서야 언어가 달라지면 패턴의 표현도 달라져야 한다는 사실을 체감했습니다.이 글은 Design Patterns 101 시리즈의 마지막 글입니다. 시리즈 전체를 관통하는 질문 하나로 마무리합니다. GoF 패턴의 의도를 유지하면서, Python이 이미 제공하는 도구로 얼마나 가볍게 표현할 수 있는가? 그리고..

저는 한때 모든 함수에 Strategy를 씌우고, 객체 하나 만들 때마다 Factory를 거치게 하고, 설정값 하나에도 Singleton 클래스를 만들던 시절이 있었습니다. 패턴을 배운 직후의 열병이었습니다. 코드 리뷰에서 "이거 왜 이렇게 복잡해요?"라는 질문을 받을 때마다 "확장성을 위해서요"라고 답했지만, 그 확장은 2년이 지나도 오지 않았습니다. 결국 저 혼자 만든 추상화를 저 혼자 유지보수하는 상황이 되었습니다.이 글은 Design Patterns 101 시리즈의 아홉 번째 글입니다. 패턴을 아는 것과 패턴을 참는 것이 왜 다른 능력인지, 그리고 과하게 적용된 패턴을 어떻게 다시 단순한 코드로 되돌리는지 이야기합니다.패턴 과잉 적용의 신호를 인식하고 단순 코드로 되돌리는 판단 흐름먼저 던지는 질..

저는 코드 리뷰에서 가장 자주 남기는 코멘트가 "이 객체를 여기서 직접 만들어야 하나요?"입니다. 서비스 클래스가 자기 협력자를 직접 생성하는 코드를 보면, 테스트를 어떻게 짤지부터 걱정이 됩니다. DB 커넥션을 열고, SMTP 서버에 연결하고, 외부 SDK를 초기화하는 코드가 비즈니스 로직 한가운데 박혀 있으면, 그 서비스를 테스트하려면 실제 인프라를 전부 띄워야 합니다. 이 문제의 해법은 놀랍도록 단순합니다. 만드는 일과 쓰는 일을 분리하면 됩니다.이 글은 Design Patterns 101 시리즈의 여덟 번째 글입니다. 2장에서 Factory Method를 "생성 결정을 서브클래스에 위임하는 패턴"으로 소개했다면, 이번 글에서는 Factory가 Dependency Injection과 만나 Compo..

주문이 제출되면 메일을 보내고, 슬랙에 알리고, 창고를 예약합니다. 처음에는 Order.submit() 안에 세 줄을 추가하면 끝입니다. 그런데 한 달 뒤 SMS 알림이 추가되고, 분석 이벤트 전송이 추가되고, 포인트 적립이 추가됩니다. 이제 Order는 주문 처리보다 후속 작업을 더 많이 알고 있습니다. 후속 작업 하나가 느려지면 주문 전체가 느려지고, 후속 작업 하나가 예외를 던지면 주문이 실패합니다. 저는 이 상황을 여러 프로젝트에서 반복해서 봤습니다.이 글은 Design Patterns 101 시리즈의 일곱 번째 글입니다. 4장에서 Observer를 개요 수준으로 소개했으니, 여기서는 동기/비동기 차이, 메모리 누수, 에러 격리, 메시지 큐와의 경계까지 깊이 들어갑니다.발행자가 구독자를 모르는 상..

결제 SDK를 교체해야 하는 날이 옵니다. 저는 이 상황을 세 번 겪었습니다. 첫 번째는 Stripe에서 Toss Payments로 바꿀 때였고, 두 번째는 SES에서 SendGrid로 메일 발송을 옮길 때였고, 세 번째는 사내 인증 서버가 OAuth2 표준으로 전환될 때였습니다. 세 번 모두 같은 교훈을 남겼습니다. 외부 SDK의 시그니처가 도메인 코드 곳곳에 박혀 있으면, 교체 작업은 "SDK 하나 바꾸기"가 아니라 "서비스 전체 리팩터링"이 됩니다.이 글은 Design Patterns 101 시리즈의 여섯 번째 글입니다. 3장에서 Adapter를 개요 수준으로 소개했으니, 여기서는 실무에서 Adapter가 어떤 경계를 만들고, 그 경계가 어떤 비용을 부르는지 깊이 파고듭니다.외부 SDK 호출이 Ad..

4장에서 Behavioral 패턴을 훑을 때 Strategy를 "알고리즘을 교체 가능하게 분리하는 패턴"으로 소개했습니다. 한 줄 요약으로는 충분하지만, 실무에서 Strategy를 적용하려고 하면 금방 질문이 쏟아집니다. 이 분기가 정말 Strategy 후보인지, 클래스로 만들어야 하는지 함수면 되는지, 기본 전략은 어떻게 두는지, 런타임에 바꿔도 안전한지. 저는 이 질문들에 하나씩 답하면서 Strategy를 깊게 파 보겠습니다.이 글은 Design Patterns 101 시리즈의 다섯 번째 글입니다.Context가 Strategy 인터페이스에만 의존하고, 구체 알고리즘은 독립적으로 교체되는 구조먼저 던지는 질문모든 if/elif 분기가 Strategy 후보일까요, 아니면 특정 조건을 만족해야 할까요?P..

코드를 잘 나눠 놓았는데도 변경이 어려운 순간이 있습니다. 클래스 하나를 고치면 알림 로직이 깨지고, 상태 전이를 추가하면 기존 분기가 흔들리고, 정렬 방식을 바꾸려면 호출부 전체를 뒤져야 합니다. 이런 문제는 구조가 아니라 객체 사이의 책임 흐름이 꼬여 있을 때 나타납니다. Behavioral 패턴은 바로 이 흐름에 이름을 붙이고, 변경이 번지지 않도록 경계를 만드는 도구입니다.이 글은 Design Patterns 101 시리즈의 네 번째 글입니다. Strategy와 Observer는 뒤에 각각 독립 장(5장, 7장)이 있으므로 여기서는 개요 수준으로 다루고, Command, Iterator, State, Template Method, Chain of Responsibility에 더 많은 지면을 할애합..

객체를 만드는 문제를 정리하고 나면, 그다음에 부딪히는 벽은 "이미 있는 객체들을 어떻게 엮을 것인가"입니다. 저는 실무에서 이 벽을 가장 자주 만나는 순간이 외부 SDK를 도메인에 연결할 때, 기존 객체에 로깅이나 캐시를 덧붙여야 할 때, 그리고 복잡한 하위 시스템을 호출자에게 단순하게 보여줘야 할 때라고 봤습니다. 이 세 가지 상황은 전부 "구조를 어떻게 조립하느냐"의 문제이고, GoF는 이 문제를 Structural 패턴이라는 이름으로 묶었습니다.이 글은 Design Patterns 101 시리즈의 세 번째 글입니다. Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy 일곱 가지를 다루되, Adapter는 6장에서 깊게 파고들 예정이므로..

프로젝트 초기에는 객체를 만드는 코드가 눈에 띄지 않습니다. SomeService(config)를 호출하면 끝이니까요. 그런데 서비스가 환경별로 다른 DB 커넥션을 받아야 하고, 테스트에서는 가짜 저장소를 끼워야 하고, 생성 인자가 열 개를 넘기 시작하면, 객체를 만드는 코드 자체가 시스템에서 가장 변경이 잦은 지점이 됩니다. 저는 이 시점을 "생성 책임이 비명을 지르는 순간"이라고 부릅니다.이 글은 Design Patterns 101 시리즈의 두 번째 글입니다. GoF가 분류한 다섯 가지 Creational 패턴 — Factory Method, Abstract Factory, Builder, Prototype, Singleton — 이 각각 어떤 문제를 풀고, 무엇을 잃게 하는지를 Python 코드와 ..

처음 디자인 패턴을 배우면 대부분 이름부터 외우게 됩니다. Singleton, Strategy, Adapter, Observer, Factory. GoF 책을 펼치면 23개가 줄지어 등장하니까, 자연스럽게 "이걸 다 알아야 코드를 잘 짜는구나" 하는 인상을 받습니다. 그런데 실무에서 패턴이 실제로 힘을 발휘하는 순간은 따로 있습니다. 시험 문제를 푸는 순간이 아니라, 코드 리뷰에서 "여기 분기가 자꾸 늘어나니까 Strategy로 빼는 게 어떨까요"라고 한 줄 던졌을 때, 팀원 전체가 같은 구조를 머리에 떠올리는 순간입니다.이 글은 Design Patterns 101 시리즈의 첫 번째 글입니다. 디자인 패턴을 "외워야 할 23개 정답"이 아니라, 반복되는 설계 문제를 짧게 설명하고 빠르게 합의하기 위한 공..