핵심 인사이트 (3줄 요약)
- 본질: 부패 방지 레이어 (ACL, Anti-Corruption Layer)는 DDD의 전략적 통합 패턴으로, 외부 시스템·레거시 시스템·다른 바운디드 컨텍스트의 도메인 모델이 자신의 도메인 모델을 '오염(corrupt)'시키지 못하도록 경계에 변환·번역 레이어를 두어 내부 도메인 모델의 순수성을 보호한다.
- 가치: ACL을 통해 외부 시스템 변경(API 스펙 변경, 필드명 변경)이 내부 도메인 모델에 직접 전파되지 않으며, 외부 모델에 대한 의존성이 ACL 경계 내에 격리되어 내부 팀이 외부 변화에 독립적으로 개발할 수 있다.
- 판단 포인트: ACL은 단순히 외부 API를 호출하는 클라이언트 코드가 아니다. 외부 개념을 내부 도메인 언어로 번역하는 Facade + Adapter + Translator의 조합이며, 외부 모델을 내부 모델로 변환하는 명시적 번역 로직이 핵심이다.
Ⅰ. 개요 및 필요성
소프트웨어 시스템은 반드시 외부 시스템과 통합해야 하는데, 외부 시스템의 도메인 모델이 내부 시스템과 다를 때 문제가 발생한다. 외부 결제사(PG)가 'paymentCode'를 사용하지만 내부 도메인은 'paymentId'를 사용한다면, ACL이 없는 경우 내부 코드 전체에 외부 개념이 스며들어 도메인 모델이 오염된다.
ACL은 이 오염을 방지한다. 외부 API와 접촉하는 지점에 변환 레이어를 두어 외부 개념을 내부 도메인 모델로 번역하고, 그 이후의 내부 코드는 오직 내부 도메인 개념만 사용한다.
┌─────────────────────────────────────────────────────────────┐
│ ACL 동작 구조 │
├─────────────────────────────────────────────────────────────┤
│ [외부 결제 시스템] │
│ paymentCode, orderId, merchantKey (외부 개념) │
│ │ │
│ ┌────▼────────────────────────────────────────────────┐ │
│ │ ACL (Anti-Corruption Layer) │ │
│ │ PaymentGatewayAdapter (Facade + Translator) │ │
│ │ - paymentCode → paymentId (번역) │ │
│ │ - 외부 예외 → 내부 DomainException (변환) │ │
│ └────┬────────────────────────────────────────────────┘ │
│ │ (내부 도메인 언어만 사용) │
│ [주문 바운디드 컨텍스트] │
│ paymentId, orderId (내부 개념) │
└─────────────────────────────────────────────────────────────┘
- 📢 섹션 요약 비유: ACL은 외교관처럼, 두 나라(시스템) 간에 서로 다른 언어(도메인 모델)를 번역하여 한 나라의 문화(외부 모델)가 다른 나라 내부를 오염시키지 않게 막는다.
Ⅱ. 아키텍처 및 핵심 원리
ACL 구현 패턴은 Facade + Adapter + Translator의 조합이다. Facade는 외부 시스템의 복잡한 API를 단순한 인터페이스로 감추고, Adapter는 인터페이스를 맞춰주며, Translator는 외부 모델을 내부 도메인 모델로 변환한다.
| 항목 | 설명 | 포인트 |
|---|---|---|
| Facade | 외부 복잡성 은닉 | PaymentGatewayFacade |
| Adapter | 인터페이스 변환 | ExternalOrderAdapter |
| Translator | 모델 번역 | ExternalPaymentTranslator |
| Repository (방향) | 외부 저장소를 내부 모델로 | LegacyProductRepository |
┌─────────────────────────────────────────────────────────────┐
│ 레거시 통합 시 ACL 위치 │
├─────────────────────────────────────────────────────────────┤
│ [신규 도메인 서비스] │
│ │ (내부 도메인 객체 사용) │
│ [ACL: LegacySystemAdapter] │
│ │ (레거시 모델 ↔ 내부 모델 변환) │
│ [레거시 시스템 API] │
│ (오래된 필드명, 구조, 예외 타입) │
└─────────────────────────────────────────────────────────────┘
- 📢 섹션 요약 비유: ACL은 수입통관(변환)과 같다. 외국 제품(외부 모델)이 국내 기준(내부 모델)에 맞게 검사·변환되어야 국내 시장(내부 도메인)에서 유통될 수 있다.
Ⅲ. 비교 및 연결
ACL의 가장 어려운 실무 과제는 외부 시스템이 자주 변경될 때 ACL 유지보수 비용이다. 외부 API 버전업 시 ACL 내의 번역 로직만 수정하면 내부 도메인 코드는 수정하지 않아도 된다는 것이 ACL의 핵심 가치다.
| 비교 축 | A | B |
|---|---|---|
| 외부 변경 영향 | ACL 내부만 수정 | 내부 도메인 전체 수정 |
| 내부 모델 순수성 | 보장됨 | 오염 위험 |
| 테스트 용이성 | ACL Mock 가능 | 외부 시스템 의존 |
- 📢 섹션 요약 비유: ACL이 없는 외부 시스템 통합은 하수구(외부 모델)가 수돗물(내부 모델)과 직접 연결된 것이다. 반드시 정수 필터(ACL)를 거쳐야 내부 시스템이 깨끗하게 유지된다.
Ⅳ. 실무 적용 및 기술사 판단
ACL 적용으로 외부 시스템 변경이 내부 도메인에 전파되지 않아 안정적인 내부 모델이 유지되고, 외부 시스템을 Mock으로 대체하여 독립적인 도메인 테스트가 가능해진다.
판단 체크리스트
- 외부 시스템·레거시 API 연동 시 ACL 레이어가 명시적으로 존재하는가?
- ACL이 외부 도메인 개념을 내부 유비쿼터스 언어로 번역하는 로직을 포함하는가?
- 외부 시스템의 예외·오류가 내부 도메인 예외로 변환되는가?
- ACL이 인터페이스로 추상화되어 외부 시스템 Mock 테스트가 가능한가?
- 외부 API 버전 변경 시 ACL 내부만 수정하면 내부 도메인 코드를 수정하지 않아도 되는가?
- 📢 섹션 요약 비유: ACL은 공항 세관처럼, 입국(외부 데이터 유입) 시 검사·변환하여 내국인(내부 도메인)이 외국 규격(외부 모델)에 맞춰 바뀔 필요가 없게 한다.
Ⅴ. 기대효과 및 결론
ACL 적용으로 외부 시스템 변경이 내부 도메인에 전파되지 않아 안정적인 내부 모델이 유지되고, 외부 시스템을 Mock으로 대체하여 독립적인 도메인 테스트가 가능해진다. 레거시 시스템 통합 시 내부 팀의 개발 속도가 외부 변화에 영향받지 않는다.
한계는 ACL 구현 자체가 추가 개발 비용이며, 단순한 외부 통합에 적용하면 오버엔지니어링이 될 수 있다. API 게이트웨이와 ACL의 결합(BFF 패턴)이 미래 방향이다.
- 📢 섹션 요약 비유: ACL은 번역가처럼, 외국어(외부 모델)를 한국어(내부 모델)로 번역하여 내부 팀이 외국어를 배우지 않아도 소통할 수 있게 한다.
📌 관련 개념 맵
[외부 시스템 의존성 오염] → [ACL 패턴(Evans DDD)] → [Facade+Adapter+Translator] → [BFF 패턴 결합] → [서비스 메시 ACL 자동화]
| 개념 | 연결 포인트 |
|---|---|
| 바운디드 컨텍스트 | ACL이 BC 경계에서 외부 모델을 차단 |
| 파사드 패턴 | ACL 구현의 외부 복잡성 은닉 |
| 어댑터 패턴 | ACL 구현의 인터페이스 변환 |
| 스트랭글러 피그 | 레거시 통합 시 ACL을 함께 사용 |
📈 관련 키워드 및 발전 흐름도
[외부 의존성 오염 문제] → [DDD ACL 패턴] → [Facade+Adapter+Translator 구현] → [BFF(Backend for Frontend)] → [서비스 메시 통합 ACL]
👶 어린이를 위한 3줄 비유 설명
- ACL은 외국 음식(외부 데이터)을 우리 입맛(내부 모델)에 맞게 조리해주는 요리사예요.
- 외국 레시피(외부 API)가 바뀌어도 우리 메뉴(내부 도메인)는 그대로 유지돼요.
- 이렇게 하면 외부 변화로부터 내부 시스템을 보호할 수 있어요!