1 이 포스트의 목적
Reis Ch.3의 §3.1~3.2는 “데이터 아키텍처란 무엇인가”라는 질문에 답한다. 데이터 아키텍처가 왜 엔터프라이즈 아키텍처의 맥락에서 정의되어야 하는지, 그리고 Reis의 정의가 기존 프레임워크와 어떻게 다른지를 이해하는 것이 이 포스트의 목표이다.
2 엔터프라이즈 아키텍처: 데이터 아키텍처의 상위 컨텍스트
데이터 아키텍처를 정의하기 전에 먼저 엔터프라이즈 아키텍처(EA)를 이해해야 한다. EA에는 비즈니스, 기술, 애플리케이션, 데이터 아키텍처가 포함된다. 데이터 아키텍처는 EA의 하위 집합이므로, EA의 속성 — 프로세스, 전략, 변화 관리, 트레이드오프 평가 — 을 상속한다.
“엔터프라이즈”라는 단어는 부정적 연상을 일으키기 쉽다. 관료적 기업 문화, 폭포수 방식 계획, 빈 구호를 떠올리게 한다. 하지만 Reis는 EA 프레임워크에서 배울 것은 배우되, 교조적으로 따르지는 말라는 입장을 취한다.
2.1 TOGAF의 정의
TOGAF(The Open Group Architecture Framework)는 가장 널리 사용되는 아키텍처 프레임워크이다.
“엔터프라이즈 아키텍처”에서 “엔터프라이즈”라는 용어는 기업 전체 — 모든 정보·기술 서비스, 프로세스, 인프라를 포괄하는 — 또는 기업 내 특정 도메인을 의미할 수 있다. 두 경우 모두 아키텍처는 여러 시스템과 여러 기능 그룹을 가로지른다.
TOGAF의 핵심 기여는 아키텍처가 단일 시스템이 아니라 시스템들의 시스템을 다룬다는 점을 명시한 것이다. 데이터 엔지니어가 자신이 구축하는 파이프라인이 조직 전체 아키텍처의 일부라는 인식을 갖는 것이 중요한 이유가 여기에 있다.
2.2 Gartner의 정의
엔터프라이즈 아키텍처(EA)는 파괴적 변화(disruptive forces)에 대한 기업의 대응을 선제적이고 전체적으로(proactively and holistically) 이끄는 분야이다. 변화를 식별·분석하고, 원하는 비즈니스 비전과 결과를 향해 실행한다.
Gartner 정의의 핵심 단어는 “선제적(proactively)”이다. 아키텍처는 문제가 발생한 후 대응하는 것이 아니라, 변화를 예측하고 준비하는 활동이다. 이것이 “항상 아키텍팅하라(Always Be Architecting)”는 원칙(Ch.3 Principle 5)의 이론적 근거이다.
2.3 EABOK의 정의
엔터프라이즈 아키텍처(EA)는 조직 모델(organizational model)이다. 전략, 운영, 기술을 정렬(align)하여 성공을 위한 로드맵을 만드는 기업의 추상적 표현이다.
EABOK는 MITRE Corporation이 2004년에 미완성 초안으로 공개한 이후 업데이트되지 않았지만, EA 분야에서 자주 인용된다. 핵심 기여는 아키텍처를 전략·운영·기술의 정렬로 정의한 것이다.
2.4 Reis의 통합 정의
엔터프라이즈 아키텍처는 기업의 변화를 지원하는 시스템 설계이며, 트레이드오프의 신중한 평가를 통해 도달한 유연하고 가역적인 결정으로 달성된다. (Reis, 2022, Ch.3)
Reis의 정의가 기존 프레임워크와 다른 점은 세 가지이다.
| 차별점 | 기존 프레임워크 | Reis |
|---|---|---|
| 초점 | 전략 정렬, 로드맵 | 변화 지원 |
| 의사결정 방식 | 체계적 거버넌스 | 유연하고 가역적인 결정 |
| 설계 철학 | 프레임워크 준수 | 트레이드오프 평가 |
2.5 유연하고 가역적인 결정이 중요한 이유
유연하고 가역적인 결정이 중요한 이유는 두 가지이다.
첫째, 미래는 예측 불가능하다. 세계는 끊임없이 변하므로, 가역적 결정을 통해 새로운 정보가 들어올 때 방향을 조정할 수 있어야 한다.
둘째, 조직은 성장하면서 경화(ossification)되는 경향이 있다. 가역적 결정의 문화를 채택하면, 결정에 따르는 위험을 줄여 이 경향을 극복할 수 있다.
Jeff Bezos의 단방향 문(one-way door)과 양방향 문(two-way door) 개념이 이를 직관적으로 설명한다.
| 유형 | 정의 | 예시 | 전략 |
|---|---|---|---|
| 단방향 문 (Type 1) | 되돌리기 거의 불가능한 결정 | AWS를 매각하거나 폐쇄하는 결정 | 신중하게, 충분한 분석 후 |
| 양방향 문 (Type 2) | 쉽게 되돌릴 수 있는 결정 | 새 마이크로서비스에 DynamoDB 사용 의무화 | 빠르게, 많이, 데이터 수집 |
양방향 문(가역적 결정)의 가치는 각 결정의 비용이 낮다는 점에 있다. 비용이 낮으면 더 많은 결정을 내릴 수 있고, 더 많이 실험하고, 더 빠르게 데이터를 수집할 수 있다. 스타트업이 대기업보다 빠르게 움직이는 이유 중 하나가 바로 대부분의 결정을 양방향 문으로 취급하기 때문이다.
2.6 변화 관리와 트레이드오프
변화 관리(change management)는 가역적 결정과 밀접하게 연결된다. 대규모 이니셔티브도 작은 변화들의 연쇄로 분해해야 한다. 각 작은 변화가 그 자체로 가역적 결정이 된다.
Amazon의 DynamoDB 사례가 이를 잘 보여준다. 2007년 DynamoDB 개념 논문 발표에서 2012년 Werner Vogels의 AWS 서비스 발표까지 5년의 간극이 있다. 그 뒤에는 수많은 작은 행동(small actions)이 있었고, 이 작은 행동들을 관리하는 것이 변화 관리의 핵심이다.
Reis는 Mark Richards와 Neal Ford의 Fundamentals of Software Architecture에서 중요한 영감을 받았다고 밝힌다. 그들이 강조하는 것은 트레이드오프가 엔지니어링 공간에서 불가피하고 편재(ubiquitous)한다는 점이다.
소프트웨어와 데이터의 유연한 특성 때문에 물리적 제약에서 자유롭다고 착각하기 쉽다. 하지만 디지털 시스템도 궁극적으로 물리적 한계(레이턴시, 신뢰성, 밀도, 에너지 소비)에 의해 제약된다. 여기에 프로그래밍 언어와 프레임워크의 특성, 복잡성 관리의 실용적 제약, 예산 등 비물리적 한계가 추가된다.
교재는 이를 한 문장으로 요약한다: “기술적 솔루션은 그 자체를 위해 존재하는 것이 아니라, 비즈니스 목표를 지원하기 위해 존재한다(Technical solutions exist not for their own sake but in support of business goals).”
3 데이터 아키텍처 정의
이제 엔터프라이즈 아키텍처를 이해했으므로, 데이터 아키텍처로 범위를 좁힌다. 데이터 아키텍처는 EA의 하위 집합이므로 EA의 속성 — 프로세스, 전략, 변화 관리, 트레이드오프 평가 — 을 상속한다.
3.1 TOGAF의 데이터 아키텍처 정의
기업의 주요 데이터 유형과 소스, 논리적 데이터 자산, 물리적 데이터 자산, 데이터 관리 리소스의 구조와 상호작용에 대한 서술이다.
TOGAF의 정의는 서술적(descriptive)이다. 현재 상태를 정확히 기술하는 데 초점을 맞춘다.
3.2 DAMA의 데이터 아키텍처 정의
기업의 데이터 요구(구조에 관계없이)를 식별하고, 이 요구를 충족하는 마스터 블루프린트를 설계·유지하는 것이다. 마스터 블루프린트를 사용하여 데이터 통합을 안내하고, 데이터 자산을 제어하고, 데이터 투자를 비즈니스 전략에 정렬한다.
DAMA의 정의는 규범적(prescriptive)이다. “설계하고 유지하라”는 행동 지침을 포함한다.
3.3 Reis의 데이터 아키텍처 정의
데이터 아키텍처는 기업의 진화하는 데이터 요구(evolving data needs)를 지원하는 시스템 설계이며, 트레이드오프의 신중한 평가를 통해 도달한 유연하고 가역적인 결정으로 달성된다. (Reis, 2022, Ch.3)
Reis의 정의에서 “진화하는(evolving)”이라는 단어가 핵심이다. TOGAF과 DAMA의 정의는 정적인 반면, Reis의 정의는 데이터 요구가 시간에 따라 변한다는 전제를 내장하고 있다.
데이터 아키텍처와 데이터 엔지니어링 아키텍처의 관계도 명확히 한다. 데이터 엔지니어링 수명주기가 데이터 수명주기의 하위 집합이듯, 데이터 엔지니어링 아키텍처는 일반적 데이터 아키텍처의 하위 집합이다. 교재는 편의상 두 용어를 혼용한다.
4 운영 아키텍처 vs 기술 아키텍처
데이터 아키텍처에는 두 가지 측면이 있다.
| 구분 | 질문 | 다루는 내용 | 예시 |
|---|---|---|---|
| 운영 아키텍처 | What — 무엇을 해야 하는가? | 사람, 프로세스, 기술의 기능적 요구사항 | 데이터 품질 기준, 레이턴시 요구, 비즈니스 프로세스 |
| 기술 아키텍처 | How — 어떻게 구현하는가? | 수명주기를 따라 데이터가 수집·저장·변환·서빙되는 방법 | 매시간 10TB를 소스 DB에서 데이터 레이크로 이동 |
건축에서 운영 아키텍처는 “이 건물에 몇 명이 살고, 어떤 용도로 쓰이며, 소방 규정은 무엇인가”이다. 기술 아키텍처는 “철근 콘크리트인가 목조인가, 배관은 어떻게 배치하고, 전기 용량은 얼마인가”이다. 둘 다 필요하지만, 운영 아키텍처(What)가 먼저이고 기술 아키텍처(How)가 그 다음이다.
이 구분이 실무에서 중요한 이유는, 기술 아키텍처부터 시작하는 오류가 매우 흔하기 때문이다. “Kafka를 쓸까 Kinesis를 쓸까?”는 기술 아키텍처 질문이다. 하지만 그 전에 “데이터가 생산되고 나서 소비자가 접근하기까지 허용되는 최대 지연 시간은 얼마인가?”라는 운영 아키텍처 질문에 먼저 답해야 한다. 이 답이 5분이면 배치로 충분할 수 있고, 5초이면 스트리밍이 필요하다.
5 “좋은” 데이터 아키텍처의 조건
Grady Booch에 따르면, “아키텍처는 시스템을 형성하는 중요한 설계 결정을 나타내며, ’중요한’은 변경 비용(cost of change)으로 측정된다.” 변경 비용이 높은 결정일수록 더 신중해야 한다.
5.1 좋은 아키텍처의 세 가지 특성
| 특성 | 설명 | 반대(나쁜 아키텍처) |
|---|---|---|
| 유연성 | 비즈니스 변화와 새 기술에 적응한다 | 경직 — 하나를 바꾸면 전체가 깨진다 |
| 재사용성 | 공통 빌딩 블록을 조직 전체에서 활용한다 | 일체형 — 모든 것이 하나의 시스템에 갇혀 있다 |
| 적절한 트레이드오프 | 모든 선택의 대가를 의식적으로 수용한다 | 마법적 사고 — 제약이 없다고 착각한다 |
교재의 핵심 인용: “좋은 데이터 아키텍처는 살아 있고 숨쉬는 것이다. 완성되는 법이 없다(Good data architecture is a living, breathing thing. It’s never finished).”
이것은 직관적으로, 좋은 아키텍처를 한 번 설계하고 끝내는 것이 아니라 지속적으로 진화시키는 프로세스라는 의미이다. 비즈니스가 바뀌면 아키텍처도 바뀌어야 하고, 새 기술이 등장하면 더 나은 트레이드오프가 가능해진다.
5.2 수명주기 저류와의 관계
6대 저류(보안, 데이터 관리, DataOps, 데이터 아키텍처, 오케스트레이션, 소프트웨어 엔지니어링)는 데이터 성숙도와 관계없이 모든 기업에서 좋은 데이터 아키텍처의 기반을 형성한다. 데이터 아키텍처 자체가 저류 중 하나이면서 동시에 다른 5개 저류가 작동하는 틀을 제공한다는 점에서, 아키텍처는 저류 중에서도 특별한 위치를 차지한다.
6 핵심 요약
§3.1~3.2의 핵심을 세 문장으로 요약하면 다음과 같다.
첫째, 데이터 아키텍처는 엔터프라이즈 아키텍처의 하위 집합이며, 변화 관리·트레이드오프 평가·유연한 결정이라는 EA의 핵심 속성을 상속한다.
둘째, Reis의 정의는 기존 프레임워크(TOGAF, DAMA)보다 동적(dynamic)이다. “진화하는 데이터 요구”라는 표현이 아키텍처의 목적을 현재 상태의 기술이 아니라 미래 변화에 대한 적응으로 규정한다.
셋째, 운영 아키텍처(What)가 기술 아키텍처(How)에 선행해야 한다. 기술 선택은 비즈니스 요구가 명확해진 후에 이루어져야 한다.
7 참고 문헌
- Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.3 §3.1-3.2.
- The Open Group (n.d.). TOGAF Version 9.1.
- DAMA International (2017). DMBOK: Data Management Body of Knowledge, 2nd ed.
- EABOK Consortium (2004). Enterprise Architecture Book of Knowledge (draft).
- Richards, M. & Ford, N. (2020). Fundamentals of Software Architecture. O’Reilly.