Extensibility 패턴
Sidecar·Ambassador·ACL·BFF로 경계와 계약을 분리해 기능 확장을 안전하게 흡수하는 구조
한 문단 요약 — 기능 확장에서 시스템이 망가지는 이유 5가지
결론: 시스템은 기능이 늘어서가 아니라 경계와 계약이 흐려질 때 무너진다.
첫째, 책임 경계가 불분명해져 변경이 연쇄 전파된다.
둘째, API·이벤트 계약이 명시되지 않아 버전 충돌이 누적된다.
셋째, 트래픽·보안·관측 책임이 뒤섞여 운영 복잡도가 폭증한다.
넷째, 프론트 요구가 서버 내부 모델을 직접 오염시킨다.
다섯째, 조직 분리가 구조에 반영되지 않아 팀 간 충돌이 구조적 문제가 된다.
Extensibility의 핵심은 “BOUNDARY와 CONTRACT”다
결론: 확장 가능한 시스템은 기능을 추가하기 쉬운 구조가 아니라 변경의 영향 범위를 가두는 구조다.
정의
Extensibility 패턴은 새로운 요구를 기존 시스템에 직접 주입하지 않고, 경계 밖에서 흡수하기 위한 구조적 선택이다.
직관
기존 집을 허물지 않고 증축 공간을 미리 확보하는 것에 가깝다.
작동 원리
- 경계(BOUNDARY): 변경이 넘지 못하는 선
- 계약(CONTRACT): 경계를 통과하는 유일한 통로 패턴은 이 둘을 어디에 둘지 결정한다.
트레이드오프
- 장점: 변경 비용 예측 가능
- 비용: 초기 구조 복잡도 증가
체크리스트
- 변경 요청은 어느 경계를 넘는가?
- 계약은 문서/스키마로 고정되어 있는가?
- 이 경계는 조직 분리와 일치하는가?
Sidecar vs Ambassador
결론: 두 패턴의 차이는 기능이 아니라 책임 배치다.
Sidecar
애플리케이션 옆에 붙어 공통 인프라 책임을 분리한다.
Ambassador
애플리케이션 앞단에서 외부 통신 계약을 대리한다.
| 구분 | Sidecar | Ambassador |
|---|---|---|
| 위치 | 서비스 옆 | 서비스 앞 |
| 주요 책임 | 관측·보안·통신 보조 | 외부 API 계약 |
| 결합도 | 낮음 | 중 |
| 대표 용도 | 로깅, mTLS, 프록시 | 외부 서비스 통합 |
트래픽·보안·관측성 관점
결론: 이 패턴들의 가치는 기능 추가가 아니라 책임 분리에 있다.
- 트래픽 제어: 애플리케이션 코드에서 제거
- 보안: 인증/암호화 정책 일관화
- 관측성: 로그·메트릭 수집 표준화
적용 체크리스트
- 인프라 성격 책임인가?
- 모든 서비스에 동일하게 필요한가?
- 애플리케이션 코드 변경 없이 교체 가능한가?
- 장애 시 영향 반경이 제한되는가?
- 운영 팀이 관리 가능한가?
Anti-Corruption Layer (ACL)
결론: ACL은 번역 계층이 아니라 도메인 방화벽이다.
도메인 오염의 의미
외부 시스템의 개념·데이터 모델이 내부 도메인에 스며드는 현상이다.
예: 외부 결제 상태 코드가 내부 주문 상태로 그대로 사용됨.
왜 필요한가
ACL이 없으면:
- 외부 변경이 내부 코드에 연쇄 반영
- 내부 모델이 점점 이해 불가능해짐
- 교체 비용이 기하급수적으로 증가
작동 원리
외부 입력 → ACL에서 의미 변환 → 내부 도메인
내부 이벤트 → ACL에서 계약 변환 → 외부 전파
트레이드오프
- 장점: 내부 도메인 보호
- 비용: 코드·계층 증가
적용 체크리스트
- 외부 시스템 교체 가능성을 고려했는가?
- 내부 모델이 외부 용어를 사용하고 있지 않은가?
- 변환 규칙이 테스트로 고정되어 있는가?
- ACL이 단순 매핑을 넘어 의미 변환을 하는가?
- 장기 비용을 감당할 수 있는가?
BFF (Backend for Frontend)
결론: BFF는 프론트 편의 계층이 아니라 계약 격리 계층이다.
문제 상황
웹/모바일 요구가 직접 서버 API를 흔든다.
- 필드 추가 요구
- 화면별 응답 구조 요구
- 실험적 요구의 잦은 변경
BFF의 역할
프론트별 요구를 서버 내부 모델로부터 격리한다.
- 웹 BFF
- 모바일 BFF
왜 API Gateway와 다른가
결론: Gateway는 트래픽 진입점, BFF는 계약 설계 계층이다.
트레이드오프
- 장점: 프론트 변화 흡수
- 비용: BFF 자체 유지 비용
적용 체크리스트
- 프론트 채널이 여러 개인가?
- 화면별 요구가 자주 바뀌는가?
- 서버 팀과 프론트 팀이 분리되어 있는가?
- 실험/AB 테스트 요구가 있는가?
- 계약 변경이 서버 도메인을 오염시키는가?
패턴 적용 요약
결론: Extensibility 패턴은 미래 변경을 현재 구조로 흡수하는 기술이다.
- Sidecar/Ambassador: 인프라·통신 책임 분리
- ACL: 도메인 보호
- BFF: 계약 격리
흔한 오해와 교정
결론: 이 패턴들은 도구가 아니라 경계 설계 원칙이다.
- “BFF = API Gateway”
→ Gateway는 진입점, BFF는 계약 분리 - “ACL = DTO 몇 개 추가”
→ ACL은 의미 변환 계층 - “Sidecar는 쿠버네티스 전용”
→ 본질은 책임 분리, 플랫폼은 구현일 뿐
조직이 커질수록 왜 중요해지는가
결론: 조직 규모 증가는 구조적 충돌 빈도를 높인다.
- 팀 분리는 구조 분리를 요구한다.
- 변경 속도 차이는 경계 없이는 충돌을 낳는다.
- 계약 없는 협업은 운영 리스크로 전이된다.
- Extensibility 패턴은 기술이 아니라 조직 완충 장치다.
재학습 체크리스트
- 변경 요청의 출발점은 어디인가?
- 변경 영향 범위를 예측할 수 있는가?
- 경계가 코드·조직과 일치하는가?
- 계약이 문서/스키마로 고정됐는가?
- 외부 의존성이 내부를 오염시키는가?
- 프론트 요구가 서버 모델을 흔드는가?
- 인프라 책임이 코드에 섞여 있는가?
- 교체 가능한 구조인가?
- 운영 팀이 이해 가능한가?
- 1년 뒤 변경 비용을 설명할 수 있는가?