1 이 포스트의 목적
Reis Ch.4의 마지막 섹션인 §4.11은 앞서 다룬 10가지 기술 선택 고려사항(팀 규모~벤치마크)에 저류(undercurrents)라는 관통 렌즈를 추가한다. 어떤 기술을 선택하든, 그 기술이 수명주기의 저류 — 데이터 관리, DataOps, 데이터 아키텍처, 오케스트레이션, 소프트웨어 엔지니어링 — 를 어떻게 지원하는지를 이해하는 것이 필수이다.
2 데이터 관리 관점
데이터 관리는 넓은 영역이며, 기술이 데이터 관리를 주요 관심사로 채택하는지 항상 명확하지 않다. 예를 들어, 서드파티 벤더가 뒤에서 데이터 관리 모범 사례(규제 준수, 보안, 프라이버시, 데이터 품질, 거버넌스)를 적용하지만 제한된 UI 뒤에 이 세부사항을 숨길 수 있다.
기술 평가 시 물어야 할 질문:
| 질문 | 관련 영역 |
|---|---|
| 외부와 내부 양쪽에서의 데이터 침해를 어떻게 방지하는가? | 보안 |
| GDPR, CCPA 등 데이터 프라이버시 규정 준수 상태는? | 규제 준수 |
| 이 규정을 준수하기 위해 데이터를 특정 위치에 호스팅할 수 있는가? | 데이터 주권 |
| 데이터 품질을 어떻게 보장하며, 솔루션에서 올바른 데이터를 보고 있는지 어떻게 확인하는가? | 데이터 품질 |
이 질문들은 OSS 솔루션에도 동일하게 적용된다.
3 DataOps 관점
문제는 발생한다. 그냥 발생한다. 서버나 DB가 죽고, 클라우드 리전이 장애를 겪고, 버그가 있는 코드를 배포하고, 나쁜 데이터가 DW에 유입되고, 기타 예상치 못한 문제가 발생한다.
기술 평가 시 핵심 질문:
| 기술 유형 | 질문 | 고려사항 |
|---|---|---|
| OSS | 모니터링, 호스팅, 코드 배포를 어떻게 설정하는가? | 문제 처리, 인시던트 대응 — 자체 책임 |
| 관리형 서비스 | 벤더의 SLA, 문제 알림 방식, 해결 투명성, 수정 ETA는? | 운영의 대부분이 벤더 통제하에 있음 |
4 데이터 아키텍처 관점
Ch.3에서 다루었듯, 좋은 데이터 아키텍처는 트레이드오프를 평가하고 최선의 도구를 선택하되 결정을 가역적으로 유지하는 것이다. 데이터 환경이 초광속으로 변하므로, “최선의 도구”는 이동하는 목표(moving target)이다.
주요 목표: 불필요한 종속(lock-in)을 피하고, 데이터 스택 전반에 걸친 상호운용성을 보장하고, 높은 ROI를 생산하라.
5 오케스트레이션: Airflow 사례 연구
교재는 대부분의 챕터에서 특정 기술을 깊이 논의하는 것을 의도적으로 피하지만, 오케스트레이션만은 예외로 한다. 이 영역이 현재 하나의 오픈소스 기술 — Apache Airflow — 에 의해 지배되고 있기 때문이다.
5.1 Airflow의 역사와 장점
Maxime Beauchemin이 2014년 Airbnb에서 Airflow 프로젝트를 시작했다. 처음부터 비상업적 오픈소스 프로젝트로 개발되었다. 2016년 Apache Incubator 프로젝트, 2019년 정식 Apache 프로젝트가 되었다.
| 장점 | 설명 |
|---|---|
| 활발한 OSS | 높은 커밋 빈도, 빠른 버그/보안 대응, Airflow 2 대규모 리팩토링 |
| 대규모 마인드셰어 | Slack, Stack Overflow, GitHub에서 활발한 커뮤니티 |
| 상용 가용성 | GCP, AWS, Astronomer.io에서 관리형 서비스로 제공 |
5.2 Airflow의 단점
| 단점 | 설명 |
|---|---|
| 비확장 핵심 컴포넌트 | 스케줄러와 백엔드 DB가 병목이 될 수 있다 |
| 분산 모놀리스 패턴 | 확장 가능한 부분도 분산 모놀리스 패턴을 따른다 |
| 데이터 네이티브 구성 부재 | 스키마 관리, 리니지, 카탈로깅 같은 데이터 네이티브 기능 부족 |
| 개발/테스트 어려움 | Airflow 워크플로 개발과 테스트가 도전적이다 |
5.3 대안과 미래
Prefect와 Dagster가 Airflow 아키텍처의 일부 문제를 재설계하여 해결하려 한다. 교재는 이 논의 이외의 다른 오케스트레이션 프레임워크와 기술이 분명히 등장할 것이라고 예고한다.
오케스트레이션 기술을 선택하는 사람이라면 Airflow, Prefect, Dagster를 깊이 연구하라. 또한 이 영역의 활동을 꾸준히 모니터링하라 — 이 책을 읽을 시점에 새로운 발전이 확실히 있을 것이다.
6 소프트웨어 엔지니어링 관점
데이터 엔지니어는 데이터 스택 전반에 걸쳐 단순화와 추상화를 지향해야 한다. 가능하면 기성품을 구매하거나 오픈소스 솔루션을 사용하라. 차별화되지 않는 무거운 작업을 제거하는 것이 큰 목표이다. 커스텀 코딩과 도구 개발에 리소스를 집중하는 것은 확고한 경쟁 우위를 제공하는 영역에 한정하라.
예: 프로덕션 DB와 클라우드 DW 사이의 DB 커넥션을 직접 코딩하는 것이 경쟁 우위인가? 아마 아닐 것이다. 이것은 이미 해결된 문제이다. 기성 솔루션(OSS 또는 관리형 SaaS)을 선택하라.
반면, 고객이 왜 우리 제품을 사는지를 생각하라. 비즈니스에는 아마 특별한 무언가가 있을 것이다. 중복적인 워크플로와 프로세스를 추상화하면, 비즈니스에 바늘을 움직이는(move the needle) 것들을 다듬고 커스터마이징하는 데 집중할 수 있다.
7 Ch.4 전체 결론
올바른 기술을 선택하는 것은 쉽지 않다. 매일 새로운 기술과 패턴이 등장하는 현재가 아마 역사상 가장 혼란스러운 기술 평가·선택 시기일 것이다. 기술 선택은 유스케이스, 비용, 구축 vs 구매, 모듈화의 균형이다.
항상 기술에 아키텍처와 같은 방식으로 접근하라: 트레이드오프를 평가하고 가역적 결정을 지향하라. (Reis, 2022, Ch.4)
8 Ch.3~4를 관통하는 통합 메시지
Ch.3(아키텍처)과 Ch.4(기술 선택)는 하나의 연속체이다.
| Ch.3 (전략) | Ch.4 (전술) | 연결 |
|---|---|---|
| “좋은” 아키텍처의 9대 원칙 | 11가지 기술 선택 고려사항 | 원칙이 고려사항의 필터 역할 |
| 가역적 결정, 소결합 | 곰 덫 회피, 모듈화, 2년 재평가 | 같은 철학의 전략적/전술적 표현 |
| DW, 레이크, 레이크하우스, 데이터 메시 | Cloud, IaaS/PaaS/SaaS, 서버리스, 컨테이너 | 아키텍처 패턴 → 구현 기술 |
| 저류가 아키텍처의 기반 | 기술이 저류를 지원해야 함 | 저류 = 일관된 평가 렌즈 |
이 통합 메시지를 한 문장으로 압축하면: 아키텍처가 “왜”와 “무엇”을 정의하고, 기술이 “어떻게”를 구현하며, 저류가 양쪽을 관통하는 일관된 평가 기준이다.
9 참고 문헌
- Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.4 §4.11.