Architecture Principles and Major Concepts

1 이 포스트의 목적

Reis Ch.3 §3.3은 좋은 데이터 아키텍처의 9대 원칙을 제시하고, §3.4는 아키텍처를 구성하는 주요 개념 — 도메인과 서비스, 분산 시스템, 결합도, 이벤트 기반 아키텍처, Brownfield vs Greenfield — 을 다룬다. 원칙이 “왜”에 해당한다면, 개념은 “어떻게”에 해당한다.

2 9대 아키텍처 원칙

Reis는 AWS Well-Architected Framework(6개 기둥)와 Google Cloud의 Five Principles for Cloud-Native Architecture에서 영감을 받아, 데이터 엔지니어링에 특화된 9대 원칙을 제시한다.

2.1 원칙 1: 공통 컴포넌트를 현명하게 선택하라

데이터 엔지니어의 핵심 업무 중 하나는 조직 전체에서 널리 사용할 수 있는 공통 컴포넌트와 프랙티스를 선택하는 것이다. 잘 선택하면 공통 컴포넌트는 팀 간 협업을 촉진하고 사일로를 허무는 결합 조직(fabric)이 된다.

공통 컴포넌트의 예: 오브젝트 스토리지, 버전 관리 시스템, 관측성(observability), 모니터링 및 오케스트레이션 시스템, 처리 엔진.

직관: 균형 잡기

공통 컴포넌트 선택은 균형 잡기(balancing act)이다. 한쪽 극단은 모든 팀에 동일한 도구를 강제하는 것(생산성 저하). 다른 극단은 각 팀이 독자적으로 도구를 선택하는 것(사일로 강화). 클라우드 플랫폼이 이 균형을 잡기 좋은 이유는 공유 스토리지 레이어(오브젝트 스토리지) 위에서 각 팀이 특화된 도구를 사용할 수 있기 때문이다.

2.2 원칙 2: 장애를 계획하라

Werner Vogels(AWS CTO)의 말처럼, “모든 것은 항상 고장난다(Everything fails, all the time).” 하드웨어는 충분한 시간이 주어지면 반드시 실패한다. 견고한 데이터 시스템을 구축하려면 설계 시점에 장애를 고려해야 한다.

용어	정의	실무 의미
가용성 (Availability)	IT 서비스가 작동 가능한 상태인 시간의 비율	99.9% = 연간 8.76시간 다운타임
신뢰성 (Reliability)	지정된 간격 동안 의도된 기능을 정의된 표준에 맞게 수행할 확률	장애 빈도와 심각도
RTO (Recovery Time Objective)	서비스 중단의 최대 허용 시간	내부 리포팅: 하루, 이커머스: 5분
RPO (Recovery Point Objective)	복구 후 허용 가능한 상태 (최대 허용 데이터 손실)	금융: 0(데이터 무손실), 로그: 1시간

이 네 지표는 아키텍처 결정의 입력(input)이다. RTO가 5분이면 자동 장애 조치(failover)가 필수이고, RPO가 0이면 동기 복제(synchronous replication)가 필요하다. 이 요구사항을 모르고 시스템을 설계하면, 장애 발생 시 비즈니스 영향을 통제할 수 없다.

2.3 원칙 3: 확장성을 위해 설계하라

확장성에는 세 가지 방향이 있다.

방향	의미	예시
스케일 업 (Scale up)	용량을 증가시켜 대규모 데이터를 처리	페타바이트 데이터로 모델 학습 시 대형 클러스터 가동
스케일 다운 (Scale down)	부하가 줄면 용량을 감소시켜 비용 절감	피크 시간 후 자동 축소
스케일 투 제로 (Scale to zero)	미사용 시 완전히 종료	서버리스 함수, 서버리스 OLAP

탄력적 시스템(elastic system)은 부하에 따라 자동으로 동적 확장한다. 하지만 부적절한 확장 전략은 과도하게 복잡한 시스템과 높은 비용을 초래한다. 하나의 장애 조치 노드를 가진 단순한 관계형 DB가 복잡한 클러스터보다 적절할 수 있다. 현재 부하를 측정하고, 부하 급증을 추정하고, 향후 수년간의 부하를 예측하여 아키텍처의 적절성을 판단해야 한다.

2.4 원칙 4: 아키텍처는 리더십이다

데이터 아키텍트는 기술 결정과 아키텍처 서술에 책임을 지며, 이를 효과적인 리더십과 교육을 통해 전파한다. 높은 기술 역량과 강한 리더십의 조합은 드물고 극히 가치 있다.

리더십은 명령과 통제(command-and-control)를 의미하지 않는다. 과거에는 하나의 독점 DB 기술을 선택하고 모든 팀에 강제하는 것이 흔했다. 클라우드 환경에서는 공통 컴포넌트 선택과 프로젝트 내 혁신의 유연성을 균형 있게 조화시킬 수 있다.

Martin Fowler가 묘사하는 이상적인 아키텍트 — “개발 팀을 멘토링하여 더 복잡한 문제를 맡을 수 있도록 수준을 높이는 것” — 이 데이터 아키텍트에게도 적용된다.

2.5 원칙 5: 항상 아키텍팅하라

Google Cloud의 Five Principles에서 직접 차용한 원칙이다. 아키텍트는 기존 상태를 유지하는 역할이 아니라, 비즈니스와 기술 변화에 대응하여 끊임없이 새로운 것을 설계하는 역할이다.

EABOK의 프레임워크: 베이스라인 아키텍처(현재 상태) → 타겟 아키텍처(목표 상태) → 시퀀싱 플랜(우선순위와 변경 순서). 타겟 아키텍처는 고정된 목표가 아니라 비즈니스와 기술 변화에 따라 조정되는 이동하는 목표(moving target)이다.

2.6 원칙 6: 소결합 시스템을 구축하라

2002년 Bezos가 Amazon 직원에게 보낸 이메일 — Bezos API Mandate — 이 이 원칙의 기원이다.

Bezos의 5가지 명령:

1. 모든 팀은 서비스 인터페이스를 통해 데이터와 기능을 노출한다
2. 팀 간 통신은 이 인터페이스를 통해서만 이루어진다
3. 다른 형태의 프로세스 간 통신은 허용되지 않는다 (직접 링킹, 직접 DB 읽기, 공유 메모리 모두 금지)
4. 어떤 기술을 사용하든 상관없다 (HTTP, Corba, Pubsub, 커스텀 프로토콜)
5. 모든 서비스 인터페이스는 예외 없이 외부화(externalizable)할 수 있도록 설계해야 한다

이 명령은 Amazon의 분수령이 되었고, 결과적으로 AWS가 탄생했다. 소결합의 4가지 기술적 속성을 조직적 특성으로 번역하면 다음과 같다.

기술적 속성	조직적 특성
시스템이 많은 작은 컴포넌트로 분리된다	많은 작은 팀이 대규모 시스템을 엔지니어링한다
추상화 레이어(API, 메시지 버스)를 통해 인터페이스한다	팀은 API 정의, 메시지 스키마 등을 통해 소통한다
내부 변경이 다른 부분의 변경을 요구하지 않는다	각 팀이 독립적으로 진화·개선할 수 있다
전체 릴리스 사이클이 없고 개별 컴포넌트가 별도 업데이트된다	팀은 정규 근무 시간에 지속적으로 릴리스한다

2.7 원칙 7: 가역적 결정을 내려라

데이터 환경은 빠르게 변한다. 오늘의 인기 기술이 내일의 구식이 된다. 가역적 결정을 지향하면 아키텍처가 단순해지고 민첩성이 유지된다.

Martin Fowler: “아키텍트의 가장 중요한 작업 중 하나는 소프트웨어 설계에서 비가역성을 제거하는 방법을 찾아 아키텍처를 없애는 것이다.” 데이터 아키텍처의 탈결합/모듈화 추세를 고려하면, 현재 최선의 솔루션(best-of-breed)을 선택하되 환경이 진화하면 업그레이드하거나 더 나은 프랙티스를 채택할 준비를 항상 하라.

2.8 원칙 8: 보안을 우선하라

두 가지 핵심 개념: 제로 트러스트 보안과 공동 책임 모델.

경화된 경계(hardened perimeter) 모델은 전통적 보안 접근법이다. 네트워크 경계 안은 “신뢰”, 밖은 “비신뢰”. 하지만 스피어 피싱이나 내부 위협에 취약하다. 1996년 영화 Mission Impossible에서 Ethan Hunt가 CIA 본부에 침투하는 장면이 경화된 경계 모델의 한계를 완벽히 보여준다. 물리적 보안 경계를 뚫고 나면, 내부 데이터를 비교적 쉽게 탈취할 수 있다.

제로 트러스트 모델은 네트워크 위치와 관계없이 모든 접근을 검증한다. 클라우드 환경에서는 모든 자산이 어느 정도 외부와 연결되어 있으므로, 경화된 경계 개념 자체가 침식된다.

공동 책임 모델: AWS는 클라우드의 보안(security of the cloud)에 책임을 지고, 사용자는 클라우드 내의 보안(security in the cloud)에 책임을 진다. S3 버킷을 퍼블릭 액세스로 설정하는 단순한 실수에서 수많은 데이터 침해가 발생했다.

교재의 핵심 메시지: 모든 데이터 엔지니어는 자신을 보안 엔지니어로 간주해야 한다.

2.9 원칙 9: FinOps를 수용하라

정의: FinOps

FinOps는 엔지니어링, 재무, 기술, 비즈니스 팀이 데이터 기반의 지출 결정에 협업함으로써 조직이 최대 비즈니스 가치를 얻도록 하는, 진화하는 클라우드 재무 관리 규율이자 문화적 프랙티스이다. (FinOps Foundation)

온프레미스 시대에는 수년에 한 번 자본 지출(CapEx)로 시스템을 구매했다. 클라우드 시대에는 사용량 기반(pay-as-you-go) 비용이 지배적이다. 이 전환은 효율성을 높이지만, 지출이 훨씬 더 동적(dynamic)이 된다.

온프레미스	클라우드
고정 자본 지출	동적 운영 비용
과잉/과소 구매 딜레마	필요에 따라 확장/축소
성능 엔지니어링 중심	비용 구조 이해 중심
예산 주기 연단위	실시간 지출 모니터링

FinOps는 운영 모니터링 모델을 확장하여 지출을 지속적으로 모니터링한다. 요청 수나 CPU 사용률만 모니터링하는 것이 아니라, 서버리스 함수의 비용, 지출 급증에 대한 알림 등을 모니터링한다.

비용 공격(cost attack)도 고려해야 한다. DDoS 공격이 웹 서버 접근을 차단하듯, S3 버킷에서의 과도한 다운로드가 지출을 급증시켜 소규모 스타트업을 파산 위기에 빠뜨릴 수 있다.

3 주요 아키텍처 개념

3.1 도메인과 서비스

Eric Evans의 정의를 따르면, 도메인(domain)은 “지식, 영향, 또는 활동의 영역”이며 사용자가 프로그램을 적용하는 주제 영역이다. 서비스(service)는 특정 작업을 수행하는 기능 집합이다.

예: 영업(sales) 도메인에 주문 처리, 송장 발행, 제품 관리 서비스가 있다. 회계(accounting) 도메인은 송장 발행, 급여, 매출채권 서비스를 가진다. 두 도메인이 송장 서비스를 공유한다.

도메인을 설계할 때의 핵심 조언: 실세계에서 도메인이 나타내는 것에 집중하고 역방향으로 작업하라. 다른 회사의 구조를 그대로 복사하지 말라. 도메인에 무엇을 포함할지 결정할 때 가장 좋은 방법은 사용자와 이해관계자에게 가서 이야기를 듣고, 그들의 업무를 돕는 서비스를 구축하는 것이다.

3.2 분산 시스템: 확장성과 장애 설계

네 가지 핵심 속성:

• 확장성(Scalability): 시스템 용량을 증가시켜 수요를 처리하는 능력
• 탄력성(Elasticity): 워크로드에 따라 동적으로 확장하는 능력 (스케일 투 제로 포함)
• 가용성(Availability): IT 서비스가 작동 가능한 시간의 비율
• 신뢰성(Reliability): 지정 간격 동안 의도된 기능을 수행할 확률

이 속성들의 관계: 낮은 신뢰성 → 시스템 무응답 → 낮은 가용성. 동적 확장(탄력성)은 수동 개입 없이 적절한 성능을 보장하여 신뢰성을 향상시킨다.

수평 확장(horizontal scaling)은 부하와 리소스 요구를 충족시키기 위해 더 많은 머신을 추가한다. 일반적인 분산 아키텍처는 리더 노드가 워커 노드에 작업을 분배하는 리더-팔로워 구조이다. 데이터는 복제되어 한 머신이 죽어도 다른 머신이 이어받을 수 있다.

3.3 결합도: 모놀리스 vs 마이크로서비스

아키텍처 티어

유형	특성	장점	단점
단일 티어	DB + 앱이 한 서버에 밀결합	프로토타이핑에 단순	서버·DB·앱 중 하나 실패 → 전체 실패
다중 티어 (N-tier)	데이터·앱·표현 등 레이어 분리	관심사 분리, 유연한 기술 선택	더 복잡한 운영
3-티어	데이터 + 애플리케이션 로직 + 표현	가장 널리 사용, 리소스 경합 회피	분산 시스템의 노드 간 리소스 공유 전략 필요

모놀리스

모놀리스는 가능한 한 많은 것을 하나의 지붕 아래 두는 것이다. 극단적 형태에서는 단일 코드베이스가 단일 머신에서 애플리케이션 로직과 UI를 모두 제공한다. 밀결합의 문제는 컴포넌트 교체가 고통스럽고, 컴포넌트 재사용이 어렵거나 불가능하며, 하나를 개선하면 다른 곳에서 알 수 없는 부작용이 발생하는 두더지 잡기(whack-a-mole) 게임이 된다.

마이크로서비스

마이크로서비스는 모놀리스의 정반대이다. 분리된, 탈중앙화된, 소결합된 서비스로 구성된다. 각 서비스가 특정 기능을 담당하며, 한 서비스가 일시적으로 다운되어도 다른 서비스는 영향받지 않는다.

데이터 아키텍처에 대한 고려사항

소프트웨어 아키텍처의 소결합 개념을 데이터에 적용할 때 몇 가지 특수성이 있다. 데이터 파이프라인이 여러 소스에서 데이터를 수집하여 중앙 데이터 웨어하우스에 적재하는 구조는 본질적으로 모놀리식이다. 마이크로서비스 등가물은 도메인별 데이터 파이프라인이 도메인별 데이터 웨어하우스에 연결되는 구조이다.

실무 조언

독단적으로 마이크로서비스를 설교하기보다, 소결합을 이상(ideal)으로 삼되 사용 중인 데이터 기술의 상태와 한계를 인식하라. 가능할 때마다 모듈화와 소결합을 허용하는 가역적 기술 선택을 도입하라. 모놀리스가 반드시 나쁜 것은 아니다. 빠르게 움직여야 할 때 모놀리스로 시작하는 것이 훨씬 단순하다. 다만 언젠가 작은 조각으로 분해할 준비를 하라.

3.4 멀티테넌트 결정

데이터 엔지니어는 여러 팀·조직·고객 간 시스템 공유에 대한 결정을 내려야 한다. 고려 요소는 두 가지이다.

요소	질문	위험
성능	한 테넌트의 높은 사용량이 다른 테넌트의 성능을 저하시키는가?	노이지 네이버(noisy neighbor) 문제
보안	서로 다른 테넌트의 데이터가 적절히 격리되는가?	데이터 누출

3.5 이벤트 기반 아키텍처

이벤트(event)는 “발생한 무언가”이며, 일반적으로 상태의 변화이다. 이벤트 기반 워크플로는 세 영역으로 구성된다.

이벤트 생산 (Production) → 이벤트 라우팅 (Routing) → 이벤트 소비 (Consumption)

이벤트 기반 아키텍처의 장점은 이벤트의 상태를 여러 서비스에 분산한다는 것이다. 서비스가 오프라인이 되거나, 분산 시스템의 노드가 실패하거나, 여러 소비자가 같은 이벤트에 접근해야 할 때 유리하다.

3.6 Brownfield vs Greenfield

프로젝트 유형	정의	핵심 과제	권장 전략
Brownfield	기존 아키텍처 리팩토링	레거시 기술·결정의 제약	Strangler 패턴 — 새 시스템이 레거시 컴포넌트를 점진적으로 교체
Greenfield	백지 상태에서 시작	신기술 유혹, 이력서 주도 개발	요구사항 우선 — 쿨한 것보다 가치 있는 것을 먼저

Brownfield에서의 핵심 조언: 이전 팀의 결정을 비판하기보다 왜 그런 결정을 내렸는지 깊이 파고들고, 질문하고, 이해하라. 공감과 맥락이 문제 진단, 기회 식별, 함정 인식에 큰 도움이 된다.

Greenfield에서의 핵심 경계: 빛나는 물체 증후군(shiny object syndrome)과 이력서 주도 개발(resume-driven development). 프로젝트의 궁극적 목표보다 기술 스택의 인상적 구성에 매달리는 유혹이다.

4 원칙과 개념의 연결

9대 원칙과 주요 개념은 독립적으로 존재하지 않는다. 다음과 같이 연결된다.

원칙	관련 개념	연결
공통 컴포넌트 (1)	도메인/서비스	공통 컴포넌트가 도메인 간 서비스 공유를 가능케 한다
장애 계획 (2) + 확장성 (3)	분산 시스템	분산 시스템이 장애 허용과 확장성을 실현한다
소결합 (6) + 가역적 결정 (7)	모놀리스 vs 마이크로서비스	소결합이 가역적 결정을 가능케 한다
항상 아키텍팅 (5)	Brownfield/Greenfield	기존/신규 프로젝트 모두에서 지속적 설계가 필요하다
보안 (8) + FinOps (9)	이벤트 기반 아키텍처	이벤트 흐름의 보안과 비용을 관리해야 한다

5 핵심 요약

원칙은 “왜”에 해당하고, 개념은 “어떻게”에 해당한다. 원칙 없이 개념만 적용하면 기술 선택의 근거가 없고, 개념 없이 원칙만 있으면 구체적인 구현이 불가능하다. 좋은 데이터 아키텍처는 원칙에 의해 동기 부여되고, 개념에 의해 실현되며, 트레이드오프 평가에 의해 조정된다.

6 참고 문헌

• Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.3 §3.3-3.4.
• AWS (n.d.). “Well-Architected Framework.”
• Google Cloud (n.d.). “Five Principles for Cloud-Native Architecture.”
• FinOps Foundation (n.d.). “What Is FinOps.”
• Evans, E. (2015). Domain-Driven Design Reference.
• Fowler, M. (2003). “Who Needs an Architect?” IEEE Software.