문제 유형별로 패턴을 고르는 법: 추천 매트릭스와 결정 트리

패턴을 몇 개나 외우고 있는지는 설계 리뷰에서 별로 중요하지 않다. 정작 필요한 건 조건 분기가 200줄 넘게 쌓인 코드를 보고 "이건 Strategy 자리다"라고 몇 초 안에 판단하는 능력이고, 그 판단을 팀 전체가 일관되게 내릴 수 있게 만드는 게 패턴 선택 가이드의 역할이다.

패턴을 고르는 문제는 패턴을 아는 문제와 다르다

패턴 선택 가이드는 문제 유형을 입력으로 받아 설계·아키텍처 패턴을 추천하는 체계화된 매핑과 결정 트리를 제공하는 것으로 정의한다. 문제 유형은 생성, 구조, 행위, 동시성/복원력, 데이터 일관성, 통합/인터페이스 범주로 나누고, 추천 매트릭스는 각 문제 유형에 대해 핵심 증상, 1차 패턴, 보조 기법, 기대 지표를 연결하는 표준 레퍼런스 역할을 한다.

문제를 축으로 나눠 진단한다

생성·구성, 구조·복잡도, 행위·협력, 동시성·복원력, 데이터 일관성, 통합·경계라는 여섯 축으로 문제 유형을 분류한다. 각 축은 "런타임 알고리즘 교체가 필요한가", "외부 장애 전파를 차단해야 하는가" 같은 증상 기반 진단 질문을 제공한다. 문제 유형에서 패턴으로는 다대일 매핑이 이뤄지고 1차 패턴과 보조 패턴을 나눠 제시하며, 각 매핑은 성능·확장성·일관성·안정성·운영 편의 중 주효과가 무엇인지와 연계된다.

증상과 패턴, 지표를 잇는 추천 매트릭스

문제 유형	핵심 증상	추천 패턴(핵심)	보조 패턴/기법	주효과(지표)
객체 생성 복잡성	생성자 파라미터 폭증, 생성 로직 중복	Factory Method, Abstract Factory, Builder, Prototype	DI Container, Configuration-as-Code	일관성, 테스트 용이성
조건 분기 난립/전략 교체	if-else/switch 폭증, 런타임 교체 필요	Strategy	Factory, Policy Registry	유지보수성, 확장성
단계적 검증/파이프라인	전처리-검증-후처리 체인	Chain of Responsibility, Pipeline	Interceptor, Middleware	모듈성, 응답시간
상태 기반 행위 변화	상태표 전개, 전이 규칙 증가	State	FSM, Transition Table	일관성, 복잡도 감소
이벤트 통지/비동기 협력	관찰자 난립, 콜백 혼재	Observer, Pub/Sub	Mediator, Event Bus	확장성, 결합도 감소
인터페이스 불일치 통합	레거시 API/서드파티 불일치	Adapter	Anti-Corruption Layer	통합 리스크 감소
복잡 서브시스템 단순화	외부 API 사용 난이도 높음	Facade	Adapter, Gateway	운영 편의, 학습곡선 감소
부분-전체 계층 구조	트리형 도메인 모델	Composite	Iterator, Visitor	일관된 순회, 확장성
메모리/객체 수 과다	동일 속성 객체 대량	Flyweight	Pooling, Caching	메모리 사용량 절감
읽기 스케일 분리	읽기 과부하/보고서 쿼리	CQRS, Read Model	Materialized View, Cache	성능, 확장성
분산 일관성/사가	분산 트랜잭션 회피 필요	Saga(Choreography/Orchestration)	Outbox/Inbox, Idempotency, Retry	일관성, 안정성
장애 고립/복원력	외부 의존 장애 전파	Circuit Breaker, Bulkhead, Retry+Backoff	Timeout, Rate Limit	안정성, MTTR 감소

추천은 맥락에 의존한다. 보안·규제·도메인 특성·팀 역량에 따라 조정이 필요하다.

결정 트리로 후보를 좁힌다

⤢✕

트리를 타고 내려가려면 먼저 요구 품질속성(QA)의 우선순위를 정해야 한다. 예를 들어 일관성이 지연시간보다, 지연시간이 비용보다 우선한다고 정해두면 경로가 갈리는 지점에서 판단이 빨라진다. 트리 경로에는 금지 패턴 가이드라인도 포함되는데, 전역 상태에 의존하는 상황이면 Singleton을 지양하라는 식이다.

트레이드오프를 무엇으로 재는가

패턴 선택은 성능과 일관성, 결합도와 재사용성, 복잡도와 확장성 사이에서 균형을 잡는 일이다. 이 균형을 감으로 판단하지 않으려면 P95 지연시간, 에러율, 변경 건수 대비 결함률, MTTR 같은 지표로 측정해야 한다.

POC와 ADR로 결정을 검증하고 남긴다

절차는 입력·처리·출력 세 단계로 이뤄진다. 입력 단계에서는 증상·제약·도메인 규칙·비기능 요구(QA) 우선순위를 명세로 모으고, P95 지연·처리량·일관성 수준(강/최종)·오류율 같은 기준 지표를 정의한다. 처리 단계에서는 매트릭스와 결정 트리를 바탕으로 23개 후보를 도출하고, 성능·일관성·안정성·운영 편의를 놓고 트레이드오프를 분석하며 전역 mutable 상태 같은 금지 조건을 점검한다. 이어서 생산과 유사한 워크로드로 12일 안에 POC·벤치마크를 돌려 임계지표를 검증하고, 제약이 충돌하면 요구를 재협상하거나 패턴 조합을 재설계하며 POC가 실패하면 대안 패턴으로 회귀한다. 출력 단계에서는 선정한 패턴과 적용 범위, 마이그레이션 계획, 롤백 시나리오를 담은 ADR(Architecture Decision Record)을 작성하고, 표준 템플릿과 샘플 코드 저장소에 반영해 코드 가이드로 배포한다.

실무에서 이렇게 갈랐다: 결제·리포팅·장애격리·주문상태

결제 규칙 엔진에서 if-else가 200줄을 넘어가고 신규 결제수단을 추가할 때마다 리스크가 커지던 상황에는 Strategy+Factory를 적용해 규칙을 리포지토리화하고 런타임에 주입했다. 그 결과 신규 전략 추가 시간이 평균 0.5일 단축되고 회귀 결함률이 40% 줄었다.

OLTP DB에 복잡한 조인 리포트를 걸어 P95 지연이 2.5초까지 나오던 대량 읽기 트래픽 리포팅 서비스에는 CQRS+Materialized View를 적용해 읽기 전용 리드 모델을 분리했다. P95 지연은 300ms로 줄었고 운영 DB 부하는 60% 감소했다.

외부 결제 게이트웨이 지연이 전체 주문 흐름을 지연시키던 마이크로서비스 간 장애 전파 문제에는 Circuit Breaker+Timeout+Retry with Backoff를 적용하고 Bulkhead로 스레드 풀을 격리했다. 타 서비스 에러율이 70% 줄고 MTTR이 35% 단축됐다.

상태별 로직이 여기저기 흩어져 불일치 상태가 빈발하던 주문 상태 관리에는 State 패턴과 명시적 전이 테이블을 적용하고 불변 이벤트 로그로 상태 전이를 추적했다. 상태 불일치 사고가 80% 줄고 디버깅 시간이 50% 단축됐다.

매트릭스를 쓸 때 잊지 말아야 할 것

이 프레임워크가 조직에 자리 잡으면 설계 리뷰 준비 시간이 3050% 단축되고 POC 재작업률이 2040% 줄어드는 식으로 의사결정 속도가 빨라진다. 회귀 결함률이 2040%, 장애 전파율이 3060% 줄어드는 품질·안정성 개선과 P95 지연이 2070% 개선되고 처리량이 20200% 늘어나는(워크로드·캐싱 전략에 따라 다름) 성능·확장성 개선도 함께 보고된다. 온보딩 시간이 30% 줄고 표준 템플릿 재사용률이 60% 이상으로 오르는 운영 편의성 증대도 뒤따른다.

다만 이 수치는 다수 프로젝트 경험을 바탕으로 한 범위 추정치이며, 실제 효과는 도메인·팀 성숙도·인프라에 따라 달라진다는 점은 유의해야 한다. 매트릭스와 결정 트리가 후보를 좁혀주더라도, 최종 검증은 경량 POC와 지표로 하고 그 근거를 ADR에 남기는 절차가 없으면 같은 판단을 팀 전체가 반복하기 어렵다.