1 이 포스트의 목적
Reis & Housley (2022) Fundamentals of Data Engineering Ch.4는 “올바른 기술을 어떻게 선택하는가”라는 질문에 대해 아키텍처와 기술의 구분 → 11가지 고려사항 → 저류와의 관계 순서로 답한다. Ch.3이 “무엇을 설계할 것인가”(전략)였다면, Ch.4는 “어떤 도구로 구현할 것인가”(전술)이다.
2 아키텍처는 전략, 기술은 전술
아키텍처는 전략적(strategic)이다: What, Why, When. 도구(기술)는 전술적(tactical)이다: How.
“우리의 데이터 아키텍처는 도구 X, Y, Z이다”라는 말은 아키텍처에 대한 잘못된 사고방식이다. 아키텍처는 비즈니스의 전략적 목표를 충족하는 데이터 시스템의 고수준 설계, 로드맵, 청사진이다. 도구는 이 아키텍처를 현실로 만드는 수단이다.
교재가 반복적으로 경고하는 패턴: 아키텍처를 설계하기 전에 기술을 선택하는 것. 빛나는 물체 증후군(shiny object syndrome), 이력서 주도 개발(resume-driven development), 아키텍처 전문성 부족이 원인이다. 이 우선순위 역전은 “닥터 수스 판타지 머신” — 여러 기술을 아무 체계 없이 짜깁기한 시스템 — 을 만들어낸다.
원칙: 아키텍처 먼저, 기술은 그 다음(Architecture first, technology second).
3 11가지 기술 선택 고려사항
전략적 아키텍처 청사진이 있다는 전제 하에, 기술 선택의 전술적 계획은 다음 11가지 고려사항을 따른다.
| 번호 | 고려사항 | 핵심 질문 |
|---|---|---|
| 1 | 팀 규모와 역량 | 기술의 복잡도를 팀이 감당할 수 있는가? |
| 2 | 시장 속도 | 가치를 얼마나 빨리 전달할 수 있는가? |
| 3 | 상호운용성 | 기존 시스템과 얼마나 쉽게 통합되는가? |
| 4 | 비용 최적화와 비즈니스 가치 | TCO, 기회비용, FinOps 관점에서 적절한가? |
| 5 | 현재 vs 미래: 불변 vs 일시적 기술 | 이 기술이 2년 후에도 살아있을까? |
| 6 | 위치 | 온프레미스, 클라우드, 하이브리드, 멀티클라우드? |
| 7 | 구축 vs 구매 | 직접 만드는 것이 경쟁 우위를 주는가? |
| 8 | 모놀리스 vs 모듈 | 단일 시스템의 단순성 vs 모듈의 유연성? |
| 9 | 서버리스 vs 서버 | 운영 부담 최소화 vs 완전한 제어? |
| 10 | 최적화, 성능, 벤치마크 전쟁 | 벤치마크를 어떻게 해석할 것인가? |
| 11 | 저류의 영향 | 데이터 관리, DataOps, 보안은 어떻게 지원되는가? |
이 11가지는 독립적이지 않다. 팀 규모(1)가 작으면 관리형 서비스(6, 9)를 선호하게 되고, 그것이 비용 구조(4)에 영향을 미치며, 벤더 종속(5, 7)의 트레이드오프로 이어진다. 기술 선택은 이 고려사항들을 동시에 최적화하는 다차원 트레이드오프이다.
4 팀 규모에서 저류까지: 전체 흐름
각 고려사항은 후속 상세 포스트에서 깊이 다룬다. 여기서는 전체 흐름을 조감한다.
4.1 팀과 속도 (§4.1~4.2)
소규모 팀이 대형 기술 기업의 블로그를 읽고 동일한 복잡한 기술을 모방하는 것을 교재는 카고 컬트 엔지니어링(cargo-cult engineering)이라 부른다. 대부분의 팀에게 올바른 전략은 관리형 서비스와 SaaS를 최대한 활용하고, 비즈니스에 직접 가치를 더하는 복잡한 문제에 한정된 대역폭을 집중하는 것이다.
속도와 관련하여, 교재의 핵심 메시지: 완벽은 좋음의 적이다(Perfect is the enemy of good). 기술 선택에 수개월~수년을 고민하며 아무 결정도 내리지 않는 팀은 해산의 위기에 처한다. 일찍, 자주, 가치를 전달하라.
4.2 비용과 미래 (§4.3~4.6)
비용을 세 렌즈로 본다: TCO(총소유비용), TOCO(총기회비용), FinOps(클라우드 재무 운영). TOCO는 특히 간과되기 쉽다. 기술 스택 A를 선택하면 B, C, D는 배제된다. A가 구식이 되면 탈출할 수 있는가? “곰 덫(bear trap)” — 들어가기는 쉽지만 빠져나오기는 극히 고통스러운 기술 — 을 경계하라.
불변 기술(immutable)과 일시적 기술(transitory)의 구분은 린디 효과(Lindy effect)에 기반한다. SQL, bash, 오브젝트 스토리지 같은 기술은 수십 년 존재했으므로 앞으로도 수십 년 존속할 가능성이 높다. 반면 매년 등장하는 새 프레임워크는 대부분 2~3년 내에 사라진다.
4.3 위치와 구매 전략 (§4.5~4.8)
클라우드 경제학의 핵심: 클라우드 \(\neq\) 온프레미스. 온프레미스 서버를 그대로 VM으로 옮기는 단순 리프트 앤 시프트는 초기 마이그레이션으로는 합리적이지만, 클라우드 가격 모델을 최적화하지 않으면 비용이 폭발한다. 데이터 그래비티(data gravity)도 경계해야 한다: 데이터를 클라우드에 넣는 것은 저렴하거나 무료이지만, 꺼내는 것(data egress)은 매우 비쌀 수 있다.
구축 vs 구매의 핵심 기준: 경쟁 우위를 제공하는가? 경쟁 우위가 아닌 것은 기성품을 사용하라. 교재의 비유: “새 타이어가 필요할 때 원재료를 구해서 직접 만들고 장착하는가?”
4.4 구조와 운영 (§4.7~4.10)
모놀리스의 장점은 단순성이지만, 대가는 유연성 상실과 높은 기회비용이다. 모듈화는 도구를 교체할 수 있는 유연성을 주지만, 오케스트레이션의 복잡도가 크게 증가한다. 분산 모놀리스(distributed monolith) — 분산 시스템이지만 밀결합의 한계를 그대로 가진 패턴 — 은 두 세계의 단점을 결합한다.
서버리스는 운영 부담을 최소화하지만, 이벤트 빈도가 높아지면 비용이 급증할 수 있다. 컨테이너는 분산 모놀리스의 의존성 충돌 문제를 부분적으로 해결한다.
벤치마크에 대한 교재의 경고: 구매자는 주의하라(Caveat Emptor). 비대칭 최적화, 비현실적 데이터셋 크기, 무의미한 비용 비교가 벤치마크 전쟁의 일반적 트릭이다.
4.5 저류 (§4.11)
어떤 기술을 선택하든, 그 기술이 데이터 엔지니어링 수명주기의 저류 — 데이터 관리, DataOps, 데이터 아키텍처, 오케스트레이션, 소프트웨어 엔지니어링, 보안 — 를 어떻게 지원하는지를 이해해야 한다.
5 핵심 시사점
Ch.4가 전달하는 핵심 메시지는 세 가지이다.
첫째, 기술 선택은 아키텍처 이후에 온다. “좋은 데이터 기술의 기준은 간단하다: 데이터 제품과 더 넓은 비즈니스에 가치를 더하는가?”
둘째, 기술 선택은 다차원 트레이드오프이다. 11가지 고려사항 중 어느 하나만 최적화하면 다른 차원에서 손실이 발생한다. 최적의 기술은 이 차원들 사이의 균형점에 있다.
셋째, 기술 선택도 아키텍처 결정처럼 가역적이어야 한다. 2년마다 기술 선택을 재평가하고, 불변 기술을 기반으로 일시적 기술을 그 위에 배치하라.
이 overview 포스트의 각 고려사항을 심화하는 상세 포스트가 이어진다.
- Team Size + Speed — 카고 컬트 엔지니어링의 위험과 시장 속도의 중요성
- Interoperability + Cost — 상호운용성 평가와 TCO/TOCO/FinOps 분석
- Future + Location — 불변/일시적 기술 구분과 클라우드 배치 전략
- Build/Buy + Monolith/Modular — 구축 vs 구매 결정과 분산 모놀리스 함정
- Serverless + Optimization — 서버리스 평가 기준과 벤치마크 해석법
- Undercurrents — 기술 선택에 미치는 저류의 영향
6 용어 정리
| 용어 | 정의 |
|---|---|
| Cargo-cult Engineering | 대형 기업의 기술을 맥락 없이 모방하는 행위 |
| TCO (Total Cost of Ownership) | 직접 비용 + 간접 비용을 포함한 총소유비용 |
| TOCO (Total Opportunity Cost of Ownership) | 기술 선택으로 인해 포기한 기회의 총비용 |
| Immutable Technology | 수십 년 존속해온, 앞으로도 유지될 가능성이 높은 기술 |
| Transitory Technology | 빠르게 등장하고 사라지는 기술 |
| Data Gravity | 데이터가 한 곳에 쌓이면 이동 비용이 커져 벗어나기 어려운 현상 |
| Lift and Shift | 온프레미스 서버를 그대로 클라우드 VM으로 이전하는 방식 |
| Distributed Monolith | 분산 아키텍처지만 밀결합의 한계를 가진 안티패턴 |
7 참고 문헌
- Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.4.
- Storment, J. R. & Fuller, M. (2019). Cloud FinOps. O’Reilly.