PE Notes · SW
아키텍처 스타일 vs 디자인 패턴
시스템 전체의 구조 언어인 아키텍처 스타일과, 모듈 안의 반복 문제를 푸는 디자인 패턴을 범위·결정 시점·예시로 가릅니다.
큰 그림을 먼저 고르지 않으면, 클래스 안의 멋진 패턴이 서로 다른 방향을 봅니다. 반대로 스타일만 있고 지역 패턴이 없으면 경계는 그려져 있는데 코드가 한 덩어리입니다. 은 시스템 전체의 구조 언어이고, 은 그 안의 반복되는 설계 문제입니다.
범위가 가르는 두 층
스타일은 컴포넌트 종류, 연결 규칙, 데이터가 흐르는 방향을 정합니다. 레이어드, 파이프-필터, 이벤트 구동, 마이크로서비스, REST 자원이 이 층입니다. 한 번 고르면 배포 단위와 장애 전파가 따라옵니다.
패턴은 모듈·클래스 규모입니다. 생성·구조·행동으로 묶는 GoF 목록, 전략·옵저버·팩토리·어댑터가 대표입니다. 같은 마이크로서비스 스타일 안에서도 서비스마다 다른 패턴을 씁니다.
처럼 이름이 겹치는 경우가 있습니다. UI 관심사 분리로 쓰면 아키텍처 패턴에 가깝고, 컨트롤러 객체 하나의 역할로 쓰면 디자인 패턴에 가깝습니다. 답안에서는 적용 범위를 먼저 적습니다.
| 비교축 | 아키텍처 스타일 | 디자인 패턴 |
|---|---|---|
| 범위 | 시스템·서브시스템 | 모듈·클래스 |
| 결정 | 초기의 구조 제약 | 구현 중의 지역 해법 |
| 산출 | 컴포넌트와 커넥터 규칙 | 역할과 협력 구조 |
| 예 | 레이어드, MSA, 이벤트 구동 | 전략, 옵저버, 팩토리 |
| 바꾸기 | 비용이 크다 | 상대적으로 국소적 |
스타일이 패턴의 자리를 정한다
레이어드는 상위가 하위만 부르게 합니다. 그 안에서 의존을 뒤집으려면 DIP와 팩토리·어댑터가 필요합니다. 이벤트 구동은 발행-구독이 스타일의 커넥터이고, 옵저버는 그 커넥터를 코드로 적는 패턴입니다.
MSA는 서비스 경계를 스타일로 그립니다. 서비스 안의 트랜잭션 스크립트나 도메인 모델, 게이트웨이 패턴은 그 다음입니다. 스타일을 패턴 목록으로 대체하면 경계가 사라집니다.
바이브 코딩으로 생성한 조각도 같습니다. 패턴을 붙여 넣기 전에, 이 시스템이 레이어인지 이벤트인지부터 고정합니다.