Data Architecture Patterns: Decisions for the AI Era
Source: guldmann.blog | Published: 2026-08-19
한 줄 요약
Lambda·Kappa·Medallion·Data Mesh·Data Lakehouse·Semantic Architecture는 서로 대안이 아니라 각자 다른 차원에서 1차 결정을 내리는 조합 가능한 결정들이고, AI가 스토리지·처리·통합의 가치가 아니라 의미·계약·거버넌스의 가치를 극적으로 올린다.
핵심 주장/내용
- AI 소비가 이제 데이터 아키텍처를 재편하는 지배적 압력: 2026년의 지배적 압력은 단순한 분석·통합이 아니라 AI 애플리케이션·에이전트·RAG·시맨틱 검색·자율 의사결정이고, 이들 모두가 BI 대시보드나 야간 배치 잡과 매우 다르게 데이터를 소비한다
- 전통 패턴은 분석과 통합에 최적화되었다. 현대 아키텍처는 추가로 AI 소비를 지원해야 한다
- 고객 레코드를 검색하는 AI 에이전트는 사람 분석가와 같은 시맨틱 명료함을, 아마 더 많이 필요로 한다 — 오해를 잡아줄 분석가가 루프에 없기 때문이다. 계약을 제대로 하는 것은 더 이상 통합 관심사가 아니라 AI 시스템이 당신의 데이터에 대해 애초에 올바르게 추론하는지를 결정한다
- 패턴이 아니라 아키텍처 스타일이 컴포넌트 상호작용을 결정한다: 아키텍처 스타일은 컴포넌트가 상호작용하도록 허용되는 기저 방식이다. 여섯 패턴 중 어느 것도 그 자체로 스타일이 아니고 각각이 event-driven, pipeline-oriented, service-oriented, data-product-oriented, layered, distributed/decentralised, shared platform 중 하나 이상을 결합한다
- Medallion 예: 기저 스타일은 layered + pipeline-oriented이고, 그 스타일이 bronze·silver·gold 스테이징을 형성하며 스키마와 data contract로 거버넌스되고 보통 Delta 테이블로 구현된다
- 스타일이 interaction 축과 ownership 축으로 갈라져 계약에서 만난다: 아키텍처 스타일이 위에 앉아 두 갈래로 나뉜다. interaction 모델이 아키텍처 패턴(Lambda, Kappa, Medallion, Data Lakehouse)을 주고, ownership 모델이 Data Mesh 의미의 데이터 아키텍처(도메인이 자기 데이터를 소유)를 준다. 둘 다 같은 것으로 수렴한다 — 다른 도메인과 시스템이 소비하는 데이터 제품이나 API. 그것이 시맨틱·기술적·행동적 계약으로 거버넌스되고, 궁극적으로 구현되는 것은 그 계약이다
- 아키텍처 패턴은 데이터 시스템이 어떻게 조직되는지, 아키텍처 스타일은 컴포넌트가 어떻게 상호작용하는지, 계약은 그 상호작용을 명시적으로 만든다
- 여섯 패턴이 갈라지는 이유는 각자 다른 차원에서 1차 결정을 내리기 때문:
| 패턴 | 1차 아키텍처 결정 |
|---|---|
| Lambda | 처리 |
| Kappa | 처리 |
| Medallion | 변환 |
| Data Mesh | 소유권 |
| Data Lakehouse | 스토리지/플랫폼 |
| Semantic Architecture | 의미 |
- 이렇게 보면 이 패턴들은 반드시 대안이 아니다. 다른 아키텍처 차원에서 작동하고 결합될 수 있다 — 실제 기업 아키텍처는 여섯 중 하나만 고르는 대신 Data Mesh + Data Lakehouse + Medallion + event-driven/Kappa 스타일 파이프라인을 결합할 수 있다
- 엄밀히 peer도 아니다: Lambda·Kappa는 처리 아키텍처, Medallion은 데이터 조직 패턴, Data Mesh는 조직적 패러다임, Data Lakehouse는 플랫폼·스토리지 아키텍처, Semantic Architecture는 의미 자체에 관한 것이다. 같은 슬롯을 두고 경쟁해서가 아니라 데이터 플랫폼을 설계할 때 손을 뻗는 패턴들이라서 함께 묶는다
- 각 패턴의 AI readiness와 핵심 구현 결정:
- Lambda — 역사적 정확성과 낮은 레이턴시를 둘 다 필요로 할 때. 대가는 서로 일치해야 하는 두 파이프라인. AI 관점: 실시간 피처와 조정된 히스토리 뷰가 둘 다 필요한 곳에 유용하지만 dual-pipeline 복잡도가 학습·추론 데이터 동기화에 레이턴시를 더한다. 핵심 설정 결정: 스트리밍 레이어가 이미 서빙한 결과에 대해 늦게 도착하는 배치 수정을 어떻게 조정하느냐 (보통 watermarking이나 배치가 따라잡은 뒤 overwrite 잡)
- Kappa — 재처리 로직이 스트림 자체 안에 살 수 있을 때. 대가는 수정·백필 로직이 그 스트림에 만들어져야 하는 것. AI 관점: 갱신된 모델로 히스토리를 재처리해야 하는 AI 시스템에 좋은 fit — 이벤트 로그 replay가 정확히 과거 이벤트를 재임베딩·재스코어링하는 방법이다. 핵심 설정 결정: 로그 보존 윈도우(또는 log compaction 사용 여부)와 스트림 처리 잡 자체의 버저닝 — replay가 버그를 유발한 로직이 아니라 수정된 로직을 돌게
- Medallion — 단계적 데이터 품질과 팀 간 재사용을 원할 때. 대가는 한 레이어 대신 세 레이어 유지의 거버넌스 오버헤드. AI 관점: Bronze가 raw 컨텍스트를 보존하고 Gold가 큐레이션된 비즈니스 엔티티를 제공하므로 RAG의 강한 기반. 핵심 설정 결정: 스키마를 어디서 강제하느냐 — Silver write 시점에 제약으로, 아니면 Gold 소비자가 drift를 직접 처리하게
- Data Mesh — 단일 중앙 팀이 현실적으로 모든 것을 소유할 수 없을 때. 대가는 도메인이 공유 표준에 동의해야만 작동하는 것. AI 관점: 계약과 시맨틱이 성숙하면 강하고, 도메인이 호환되지 않는 정의를 발행하면 약하다. 핵심 설정 결정: 상호운용성 표준 자체 — 데이터 제품이 발행되기 전에 무엇을 포함해야 하는가(canonical 정의, 속성, JSON Schema 기술 표현, 오너·producer·consumer 기대·품질 규칙·SLA·버저닝·변경 정책을 명시한 data contract)
- Data Lakehouse — SQL과 ML을 한 기반 위에 원할 때. 대가는 도구 선택보다 플랫폼 규율이 중요해지는 것. 핵심 설정 결정: 테이블 포맷 거버넌스 — 누가 테이블에 쓸 수 있고, 스키마 진화를 어떻게 다루고, ACID 트랜잭션이 모든 writer에 걸쳐 일관되게 강제되는지
- Semantic Architecture — 의미 자체를 스토리지나 파이프라인이 아니라 엔지니어링할 대상으로 취급한다. canonical 모델·지식 그래프·온톨로지·비즈니스 어휘가 존재하는 이유는 시스템, 그리고 점점 AI 에이전트가 다른 무엇에 동의하기 전에 데이터가 무엇을 의미하는지에 동의하도록 하기 위해서다. 대가는 자기 정의를 그냥 내보내고 싶어하는 팀들 사이에서 공유 어휘를 유지하는 지속적 노력
- 문제-결정-결과: 기업 데이터 실패의 큰 몫이 스토리지·소유권·처리 실패가 아니라 시맨틱 실패로 드러나므로, canonical 모델과 온톨로지로 의미 자체를 명시적이고 거버넌스된 아티팩트로 만들기로 결정하고, 결과는 어떤 단일 프로젝트보다 오래 사는 지속적 거버넌스 비용
- AI readiness: 논쟁의 여지는 있지만 AI 소비가 가장 많이 의존하는 패턴 — 에이전트나 RAG 파이프라인은 “customer”가 보는 모든 곳에서 같은 것을 의미할 때만 시스템 간에 올바르게 추론할 수 있다
- 핵심 설정 결정: canonical 정의를 얼마나 엄격히 강제하느냐 — 발행 시점의 hard validation gate로, 아니면 사후에 로컬 정의를 canonical 모델에 매핑하는 조정 레이어로
- 계약이 인프라가 아니라 1차 아키텍처 경계가 되어간다: 계약은 단순한 기술 스키마가 아니라 세 레벨로 정의된다 — 비즈니스 계약(“Customer는 활성 상업 관계를 가진 조직을 의미한다”), 시맨틱 계약(“Customer, 속성 customerId·legalName·country·status”), 기술 계약(
{"customerId": {"type": "string"}})- 스키마 호환성이 시맨틱 호환성을 보장하지 않는다. 두 도메인이 customerId가 string이라는 데 완벽히 동의하면서 customer가 무엇인지에 대해서는 완전히 불일치할 수 있다. 정확히 거기에 canonical 모델·비즈니스 정의·온톨로지·택소노미가 들어간다. 요약하면 스키마는 의미와 같지 않다. 계약은 의미·구조·행동·기대를 함께 담은 것이다
- 더 밀고 나가면 경계 자체가 이동한다: API가 계약이고, 이벤트가 계약이고, 데이터 제품이 계약이고, 에이전트 인터페이스가 계약이다. 아키텍처가 점점 물리적 통합이 아니라 계약으로 정의된다
- AI 아키텍처는 기술 문제로 위장한 거버넌스 문제: 분석 아키텍처는 인간 소비에 최적화되었고 AI 아키텍처는 기계 추론에 최적화되어야 하는데, 기계 추론은 시맨틱이 명시적일 때만 작동한다. 명시적 시맨틱은 계약을 요구하고, 계약은 누군가 거버넌스할 때만 버틴다 — 누가 정의를 소유하고, 누가 바꿀 수 있고, 바꾸면 무슨 일이 일어나는가. 이 사슬을 따라가면 AI 아키텍처는 기술적 위장을 입은 거버넌스 문제로 드러난다
- 이 글이 향해 온 진짜 전환: AI는 스토리지·처리·통합의 가치를 높이지 않는다. 의미·계약·거버넌스의 가치를 극적으로 높인다. 위의 여섯 패턴은 여전히 올바른 building block이고, 바뀐 것은 그중 어느 것이 이제 무게를 지느냐다
관련 위키
- Semantic Control Plane
- Knowledge Spine
- Data Contracts
- Data Mesh and Federation
- Medallion Architecture
- Catalog-Managed Tables
- Data Governance
- Real-Time Stream Processing
- Declarative Data Engineering
Source: 원문 보기