Anti-Corruption Layer — 외부 변화로부터 내 도메인을 지키는 격리벽

Eric Evans Context Map 7가지 패턴 중 가장 강력한 boundary mechanism. 외부 시스템과 내 시스템 사이에 변환 layer를 두어, 외부의 변화·오염이 내 도메인 모델에 영향을 미치지 않게 한다. overview의 🌐 Domain 축 마무리. information-hiding의 시스템 단위 표현이고, bounded-context|BC의 downstream 자기 보호 패턴. AI 시대에 LLM Provider trait가 가장 명료한 implementation 사례.

한 줄

외부 시스템이 변할 때 내 코드가 몇 군데 영향받는가? 라는 질문에 대한 답이 ACL. 잘 되어 있으면 1군데만. 외부 vendor·protocol·format이 어떻게 바뀌어도 내 도메인 모델은 내가 결정. AI 시대에는 LLM provider trait가 가장 친숙한 사례 — OpenAI/Anthropic/local model이 다 다르지만 내 코드에서는 동일 contract.

⚛️ 철학

원칙의 왜. 더 깊은 root와의 연결.

Evans의 정의

"Translate between the two models, allowing one to remain pure while accommodating the other... Create an isolating layer to provide clients with functionality in terms of their own domain model."

— Eric Evans, Domain-Driven Design (2003)

핵심 명제:

내 도메인 모델은 내가 결정한다. 외부 시스템 형식·vocabulary에 종속되지 않는다. 외부의 변화는 ACL이 흡수해서 내부에 도달하지 못한다.

핵심 질문 — 변화 영향 측정

ACL의 가치를 한 질문으로 측정:

외부 시스템(vendor, API, schema, protocol)이 변하면 내 코드 몇 군데가 영향받는가?

ACL 상태	외부 변화 시 영향
❌ ACL 없음	외부 시스템을 사용하는 모든 곳
⚠️ 부분 ACL	일부 격리, 일부 leak
✅ 완전 ACL	ACL 한 군데만

→ 이 측정이 information-hiding|information hiding의 시스템 단위 운영. ACL이 외부 시스템의 변화 secret을 감춘다.

학내 segment의 명료한 사례

학사 시스템과 학내 도구의 관계:

→ 학내 segment에서 ACL의 가치가 가장 직접적. 학사 시스템은 학기마다 개편되는 게 정상인데, ACL 없으면 매 학기 모든 도구를 수정해야 함. ACL 1개만 수정하면 되는 게 학생의 시간을 아껴줌.

다른 root와의 연결

information-hiding — ACL은 외부 시스템의 변화라는 secret을 감춤. 시스템 단위 hiding
bounded-context — ACL은 BC 사이 또는 내 BC ↔ 외부 BC 사이의 격리
ubiquitous-language — ACL이 외부 vocabulary → 내 UL로 변환
information-leak-vs-abstraction — 외부 시스템의 leak을 한 자리에 모음
reversibility — ACL이 있으면 vendor 교체가 reversible
orthogonality — ACL이 layer 독립성을 외부와의 관계에서 보장
simple-not-easy — Hickey의 complect 제거가 ACL의 핵심 — 외부 complex를 한 자리에 모음, 내부는 simple

🧱 추상적 작동 구조

ACL의 책임 3가지:

ACL이 격리하는 외부 변화의 4가지 종류:

변화 종류	예시	ACL 없으면	ACL 있으면
Schema 변경	학사 시스템 응답 JSON 형태 변경	모든 도구 영향	ACL 1군데
API 변경	endpoint URL·인증 방식 변경	모든 도구 영향	ACL 1군데
Vendor 교체	OpenAI → Anthropic	모든 호출처 영향	Provider impl 1개
Protocol 교체	REST → GraphQL	모든 호출처 영향	ACL 1군데

명료한 implementation 사례 — LLM Provider trait

// 내 도메인 (UL): "AI에게 prompt 보내고 응답 받기"
trait Provider {
    async fn complete(&self, prompt: &str) -> Result<Response, MyError>;
    async fn stream(&self, prompt: &str) -> Result<Stream, MyError>;
    fn name(&self) -> &str;
    fn model_config(&self) -> ModelConfig;
}

// 각 vendor adapter = ACL
struct OpenAIProvider { ... }   // ACL: OpenAI API → Provider trait
struct AnthropicProvider { ... } // ACL: Anthropic API → Provider trait
struct LocalLlamaProvider { ... } // ACL: local llama.cpp → Provider trait

// 사용 — vendor 무관
fn use_ai(p: &dyn Provider, prompt: &str) {
    p.complete(prompt).await  // 내 UL로 호출
}

→ Provider trait가 contract, 각 adapter가 ACL. Vendor 교체 = adapter 교체. 사용 코드는 그대로. AI 시대 ACL의 가장 친숙한 사례.

⚠️ 약점/한계

원칙의 적용 한계. 잘못 적용 시 함정.

1. ACL 자체의 유지비용

외부 시스템이 변하면 ACL은 반드시 변경. 외부 시스템이 자주 바뀌면 ACL 유지비용 큼. 하나의 코드를 항상 외부에 따라 수정.

해결: ACL을 작게 유지. 자주 변하는 부분만 ACL에. 안정적 부분은 직접 호출. 그러나 경계 판단이 어려움.

2. Performance overhead

변환 자체에 비용 (CPU, memory, allocation). 매 외부 호출마다 변환. 대용량·고성능 시스템에서 부담.

해결: Hot path는 변환을 batch로 또는 zero-copy. 안 그러면 ACL이 bottleneck.

3. 추상화 leak 잔존 (Spolsky 함정)

ACL이 외부 vendor를 격리한다고 약속해도, latency·rate limit·timeout 같은 leak은 남음. information-leak-vs-abstraction의 4종류 leak이 ACL을 통해서도 새옴.

예: Provider trait가 OpenAI/Anthropic을 격리하지만:

OpenAI rate limit 다름
Anthropic latency 다름
Local llama 메모리 사용 다름

해결: Leak을 ACL의 contract에 명시적으로 노출. model_config() 같은 metadata 메서드로. 감추지 말고 예측 가능한 leak으로.

4. 언제 ACL 만들지 판단 어려움

너무 일찍 만들면 over-engineering (외부 시스템이 안 변할 수도). 너무 늦으면 모든 곳에 vendor 코드 박혀버림 → 마이그레이션 비용 폭발.

해결: Rule of two — 외부 시스템 변경이 두 번 발생하면 그때 ACL. 한 번은 우연일 수 있음. 두 번이면 변하는 패턴.

5. ACL의 ownership 모호

ACL은 외부 시스템 + 내 도메인 둘 다 알아야 함. 누가 maintain하는가? 외부 팀? 내 팀? 보통 내 팀의 책임이지만 외부 변경을 추적해야.

해결: Named ownership 박기 (named-ownership). ACL의 owner를 명시. 외부 시스템 release note 모니터링 책임도.

6. 작은 시스템에서 over-engineering

1회용 script, prototype, MVP에 ACL 만드는 건 비용 낭비. 외부 시스템이 변할 가능성이 사실상 0인 경우 ACL 불필요.

해결: 도메인의 변화 압력으로 측정. 외부 시스템이 영구히 안정하면 ACL 불필요. 변화가 예상되면 ACL.

🔄 대안 흐름

이 원칙이 적용 안 되는 시나리오와 다른 답.

대안 1 — Conformist (DDD Context Map의 다른 패턴)

외부 시스템에 그대로 따름. ACL 비용 회피. 외부 vocabulary·schema·error를 내 도메인에 그대로 사용.

→ 정당한 사용처:

외부 시스템이 명확한 표준 (ISO, IETF, W3C)
내 시스템이 임시·일회용
외부 변경이 드물거나 통제됨

→ 함정: 외부가 변하면 내 시스템 전체 영향. ACL 회피 비용을 변경 시 한 번에 지불.

대안 2 — Direct integration (작은 시스템)

외부 API를 도메인 코드에서 직접 호출. ACL 없음. 작은 시스템 / single use case.

→ 작은 시스템에는 정당. premature ACL보다 낫다. 단, 증거가 쌓이면 ACL로 마이그레이션.

대안 3 — Event-driven integration

외부 시스템과 event로만 통신. ACL이 아니라 event schema가 contract. 두 시스템이 시간적으로도 분리.

→ ACL의 event-driven 변형. 같은 정신, 다른 mechanism. Eventual consistency 허용 가능 시 우수.

대안 4 — Open Host Service — 반대 방향 ACL

내가 외부에게 contract 제공. 외부가 내 contract에 맞춰 사용. 내가 변하지 않고 외부가 적응.

→ ACL의 반대. 내가 upstream인 경우. 외부 사용자가 적응 책임.

대안 5 — Microservices boundary가 ACL

서비스 경계가 자연스럽게 ACL. 각 service가 자기 도메인. 다른 service는 외부.

→ Architecture 단위로 ACL을 자동 강제. Microservices의 가장 큰 가치 중 하나.

💡 인사이트

AI 시대 왜 지금 부활하는가 + 학내 segment 의미.

1. LLM Provider trait가 가장 친숙한 ACL 사례

AI 시대 모든 개발자가 직접 경험하는 ACL:

OpenAI API ↔ Provider trait ↔ 내 코드
Anthropic API ↔ Provider trait ↔ 내 코드
Local llama ↔ Provider trait ↔ 내 코드

LLM provider 시장이 매우 빠르게 변함:

Vendor가 매월 새 model 출시
API spec 정기 변경
Pricing 변경 (rate limit, context window, token cost)
새 vendor 등장 (DeepSeek, Mistral, ...)

→ ACL 없으면 매번 모든 LLM 호출처 수정. ACL 있으면 Provider impl 하나만 수정. 이게 research/stateless-llm-sdk/design-principles|7 원칙의 원칙 4 (Orthogonal Layers, Reversible Decisions)의 가장 직접적 사례.

2. Hexagonal Architecture / Ports and Adapters 정합

Alistair Cockburn (2005)의 Hexagonal Architecture는 ACL의 architectural 운영:

Hexagonal	DDD ACL	의미
Port	Contract / Interface	내가 정의한 도메인 contract
Adapter	ACL implementation	외부 시스템을 contract에 맞춤
Domain core	내 도메인 model	외부 무관, 내 결정
Driving adapter	Inbound ACL	UI·CLI·API → 도메인
Driven adapter	Outbound ACL	도메인 → DB·외부 API·LLM

→ Hexagonal Architecture는 ACL을 시스템 전체에 일반화한 것. 모든 외부 의존을 port + adapter로 강제. v1.0 architecture가 자연스럽게 hexagonal 닮음.

3. v1.0 design 직접 적용

Layer	ACL 역할	격리 대상
`Provider` trait + adapters	LLM vendor 격리	OpenAI, Anthropic, local model
학내 통합 모듈	학사 시스템 격리	학사·인증·학칙 변경
MCP bridge	MCP protocol 격리	MCP spec 변경
Hooks layer	lifecycle event 격리	외부 trigger 변경
Skills loader	skill format 격리	SKILL.md 형식 변경

→ 모든 외부 의존이 ACL로 격리. v1.0의 정체성이 외부 변화에 강한 시스템.

4. 학내 segment의 most direct value

학내 시스템의 변화 빈도:

학사 시스템: 학기마다 개편 (UI·API·정책)
인증 시스템: 연 1-2회 변경 (SSO 도입, 다중 인증)
학칙: 매년 일부 변경 (수강 제한, 졸업 요건)
정책: 매학기 일부 (등록금, 장학)

ACL 없는 학내 도구:

매 학기 모든 도구 점검 + 수정
학생이 자기 도구 유지에 시간 다 씀
결국 도구 사용 포기

ACL 있는 학내 도구:

학기 개편 → ACL 1개만 수정
다른 도구는 그대로 작동
학생이 도구 사용 + strategic 사고에 시간 투자

→ 학내 segment에서 ACL은 가장 직접적인 경제적 가치. v1.0이 학내에 가져다 주는 유지비용 절감의 mechanism.

5. Hickey 명제의 ACL 표현

simple-not-easy 명제: complect 제거 = simple. ACL의 응용:

ACL은 외부 complex를 한 자리에 모음. 다른 곳은 simple 유지.

ACL 없음:
  외부 complex가 시스템 *모든 곳에* 흩뿌려짐
  매 호출처가 외부 vendor 지식 보유 (얽힘)

ACL 있음:
  외부 complex가 *ACL 안에 격리*
  다른 곳은 *내 UL만 알면 됨* (simple)

→ Hickey의 simple 추구가 외부 시스템 단위에서 정확히 작동. complect를 ACL이 흡수.

6. AI agent에게 ACL의 의미

sources/key-articles-summary#5. Ian Bull — *Sinks, Not Pipes*|Ian Bull 명제: AI는 architecture를 face value로 받음. ACL이 잘 되어 있으면:

AI agent는 외부 vendor specific 지식을 몰라도 됨. 내 UL과 contract만 알면 작동.

학내 학생이 AI에게 "수강신청 검증 함수 만들어줘":

ACL 없음: AI가 학사 시스템 API 명세도 알아야 함. 외부 docs 학습 필요
ACL 있음: AI가 학내 통합 모듈의 contract만 알면 됨. 외부 무관

→ ACL이 AI 친화적 architecture. AI session이 내 도메인에만 집중.

7. ACL이 reversibility의 mechanism

reversibility 원칙: 결정을 되돌릴 수 있게. ACL이 그 mechanism:

Vendor 결정 → ACL 안에 박힘. 다른 vendor로 바꾸기 = ACL 1개 다시 짜기
Protocol 결정 → ACL 안에 박힘. 다른 protocol = ACL 변경
Schema 결정 → ACL 안에 박힘. schema 진화 = ACL 마이그레이션

→ ACL이 모든 외부 결정의 reversibility 보장. vendor lock-in 회피의 가장 직접적 도구.

8. AI 시대 새 ACL 종류 — Prompt-level ACL

AI 시대에 새로 등장한 ACL 종류:

Prompt structure의 vendor 차이를 격리.

OpenAI, Anthropic, local model이 system prompt 형식·tool calling 방식·streaming 형식이 다름. 매 vendor의 prompt convention이 외부 detail. 이를 prompt template ACL로 격리:

내 코드: "도메인 task를 prompt로 표현"
   ↓
Prompt-level ACL (vendor별 template)
   ↓
OpenAI prompt format / Anthropic format / local format

→ AI 시대의 새 ACL 종류. v1.0의 자연스러운 추가 layer.

다음에 가야 할 자리

이 노트가 호출한 다른 원칙들 — 자연스러운 다음 노트:

orthogonality — ACL이 layer 독립성의 외부 관계 표현. Process 축 시작
reversibility — ACL이 모든 외부 결정의 reversibility 보장
tdd-as-small-deliberate-steps — ACL contract를 test로 정의

→ 🌐 Domain 축 마무리. 다음은 🔄 Process 축으로 이동. orthogonality가 자연스러움.

Sources

직접 source

Domain-Driven Design — Eric Evans (2003). Chapter 14 Maintaining Model Integrity에 ACL 정의
Implementing Domain-Driven Design — Vaughn Vernon (2013). Chapter 13 Integrating Bounded Contexts. ACL 실무 적용

Hexagonal Architecture (인사이트 2)

Cockburn, A. (2005). Hexagonal Architecture / Ports and Adapters. https://alistair.cockburn.us/hexagonal-architecture/
Get Your Hands Dirty on Clean Architecture — Tom Hombergs. Hexagonal 실무

AI 시대 ACL

[LangChain / LiteLLM / OpenAI SDK] 등이 Provider trait의 다양한 implementation
research/stateless-llm-sdk/design-principles — v1.0의 ACL 원칙 7번

Microservices와 ACL (대안 5)

Building Microservices — Sam Newman. 서비스 경계 = ACL

Anti-Corruption Layer — 외부 변화로부터 내 도메인을 지키는 격리벽

Anti-Corruption Layer — 외부 변화로부터 내 도메인을 지키는 격리벽

한 줄

⚛️ 철학

Evans의 정의

핵심 질문 — 변화 영향 측정

학내 segment의 명료한 사례

다른 root와의 연결

🧱 추상적 작동 구조

명료한 implementation 사례 — LLM Provider trait

⚠️ 약점/한계

1. ACL 자체의 유지비용

2. Performance overhead

3. 추상화 leak 잔존 (Spolsky 함정)

4. 언제 ACL 만들지 판단 어려움

5. ACL의 ownership 모호

6. 작은 시스템에서 over-engineering

🔄 대안 흐름

대안 1 — Conformist (DDD Context Map의 다른 패턴)

대안 2 — Direct integration (작은 시스템)

대안 3 — Event-driven integration

대안 4 — Open Host Service — 반대 방향 ACL

대안 5 — Microservices boundary가 ACL

💡 인사이트

1. LLM Provider trait가 가장 친숙한 ACL 사례

2. Hexagonal Architecture / Ports and Adapters 정합

3. v1.0 design 직접 적용

4. 학내 segment의 most direct value

5. Hickey 명제의 ACL 표현

6. AI agent에게 ACL의 의미

7. ACL이 reversibility의 mechanism

8. AI 시대 새 ACL 종류 — Prompt-level ACL

다음에 가야 할 자리

관련

Sources

직접 source

Hexagonal Architecture (인사이트 2)

AI 시대 ACL

Microservices와 ACL (대안 5)