1 불변 기술 vs 일시적 기술
데이터 엔지니어링처럼 흥미로운 분야에서, 빠르게 진화하는 미래에 집중하면서 현재의 구체적 필요를 무시하기 쉽다. 미래를 위해 선택한 도구가 그 미래가 도래할 때 이미 구식이 되어 있는 경우가 흔하다.
현재에 집중하라. 현재와 가까운 미래에 최선인 기술을 선택하되, 미래의 알 수 없는 것과 진화를 지원하는 방식으로 선택하라. (Reis, 2022, Ch.4)
1.1 불변 기술 (Immutable Technologies)
불변 기술은 클라우드의 기반 컴포넌트이거나, 시간의 시험을 견딘 언어와 패러다임이다.
| 분류 | 예시 | 존속 기간 |
|---|---|---|
| 클라우드 기반 | 오브젝트 스토리지 (S3, Azure Blob), 네트워킹, 서버, 보안 | 10년+ |
| 언어 | SQL, bash | 수십 년 |
| 아키텍처 | 관계형 DB, x86 프로세서 아키텍처, 전력 그리드 | 수십 년 |
불변 기술의 판별 기준은 린디 효과(Lindy effect)이다.
린디 효과는 기술이 확립된 기간이 길수록 앞으로도 더 오래 사용될 것이라는 관찰이다. (Reis, 2022, Ch.4)
SQL은 1970년대에 탄생하여 50년 넘게 존속하고 있다. MapReduce 시대에 잠시 구식 취급을 받았지만, 선언적이고 집합론적인 특성 덕분에 다시 데이터의 공용어가 되었다. 린디 효과에 따르면, SQL은 앞으로 수십 년 더 존속할 가능성이 높다.
1.2 일시적 기술 (Transitory Technologies)
일시적 기술은 왔다가 사라진다. 전형적 궤적: 많은 과대광고(hype) → 인기 급상승 → 서서히 무명으로. JavaScript 프론트엔드 프레임워크가 전형적 예이다. 2010년대 초 Backbone.js, Ember.js, Knockout → 현재 React, Vue.js → 3년 후에는?
데이터 분야도 마찬가지이다. 매일 새로운 벤더와 오픈소스 프로젝트가 등장한다. 최고의 VC도 대부분의 데이터 도구 투자가 실패할 것을 알면서 베팅한다. VC가 수백만(또는 수십억) 달러를 투자하고도 맞추지 못하는데, 개별 데이터 엔지니어가 어떻게 올바른 기술을 알 수 있겠는가?
Hive의 사례가 교훈적이다. 2010년대 초 MapReduce 작업을 직접 코딩하지 않고도 대규모 데이터셋을 쿼리할 수 있게 해 빠르게 채택되었다. 하지만 Hive의 한계를 개선하려는 엔지니어들이 Presto 등을 개발했고, Hive는 이제 주로 레거시 배포에서만 보인다.
1.3 교재의 조언: 2년 재평가 주기
불변 기술을 기반으로 삼고, 그 위에 일시적 기술을 배치하라. 기술 선택을 2년마다 재평가하라. 많은 데이터 기술의 실패 가능성을 고려하면, 선택한 기술에서 전환하기가 얼마나 쉬운지를 항상 고려해야 한다.
2 기술 배치 위치: 어디서 운영할 것인가
2.1 온프레미스
새 스타트업은 점점 더 클라우드에서 태어나지만, 기존 기업에게 온프레미스 시스템은 여전히 기본이다. 자체 하드웨어를 소유하고, 하드웨어가 실패하면 수리·교체하고, 수년마다 업그레이드 주기를 관리해야 한다. 피크 부하를 처리할 수 있는 충분한 하드웨어를 보유해야 한다.
기존 기업의 딜레마: 검증된 운영 프랙티스가 있지만, 더 민첩한 경쟁자가 클라우드 관리형 서비스를 활용하여 빠르게 확장하는 것을 본다. 기존 시스템을 효율적으로 운영하면서 동시에 다음 행보를 결정해야 한다.
2.2 클라우드
클라우드는 온프레미스 모델을 뒤집는다. 하드웨어를 구매하는 대신 클라우드 제공자로부터 대여한다. VM은 1분 이내에 가동되고, 초 단위로 과금된다.
클라우드 서비스의 진화:
| 수준 | 정의 | 예시 |
|---|---|---|
| IaaS (Infrastructure as a Service) | VM, 가상 디스크 등 하드웨어 대여 | EC2, Azure VMs |
| PaaS (Platform as a Service) | IaaS + 관리형 서비스 | RDS, Cloud SQL, GKE, AKS |
| SaaS (Software as a Service) | 완전한 기업 소프트웨어 플랫폼 | Salesforce, Snowflake, Fivetran |
| 서버리스 | 자동 확장 (제로부터 고부하까지), 사용량 기반 과금 | Lambda, BigQuery |
2.3 클라우드 경제학: 클라우드 \(\neq\) 온프레미스
이 제목은 자명해 보이지만, 클라우드 서비스가 익숙한 온프레미스 서버와 같다는 믿음은 클라우드 마이그레이션을 괴롭히고 충격적인 청구서를 초래하는 널리 퍼진 인지적 오류이다. 교재는 이를 “친숙함의 저주(curse of familiarity)”라 부른다.
온프레미스 서버를 그대로 클라우드 VM으로 옮기는 단순 리프트 앤 시프트는 초기 마이그레이션으로는 합리적이지만, 이 상태로 방치하면 문제가 심각하다. 직접 비교 기준으로, 클라우드에서 장기 실행 서버는 온프레미스보다 상당히 비싸다.
클라우드 가치를 찾는 핵심: 클라우드 가격 모델을 이해하고 최적화하라. 전체 피크 부하를 처리할 수 있는 장기 실행 서버 대신, 오토스케일링으로 가벼운 부하에는 최소 인프라, 피크 시에는 대규모 클러스터로 확장하라. 예약 인스턴스, 스팟 인스턴스, 서버리스 함수를 활용하여 할인을 실현하라.
2.4 데이터 그래비티
벤더는 자사 제품에 종속시키고 싶어 한다. 대부분의 클라우드 플랫폼에서 데이터를 넣는 것은 저렴하거나 무료이지만, 꺼내는 것(data egress)은 극히 비쌀 수 있다. 데이터 이그레스 수수료와 장기적 비즈니스 영향을 사전에 인식하라. 데이터 그래비티는 실재한다: 데이터가 한 클라우드에 착지하면, 추출하고 프로세스를 마이그레이션하는 비용이 매우 높을 수 있다.
2.5 하이브리드 클라우드
기존 기업이 모든 워크로드를 하룻밤에 마이그레이션하는 것은 불가능하다. 하이브리드 클라우드 모델은 일부 워크로드를 영구적으로 클라우드 외부에 유지한다.
분석 워크로드를 클라우드에 배치하는 패턴은 데이터 이그레스 비용을 최소화하기 때문에 효과적이다. 온프레미스 애플리케이션이 이벤트 데이터를 생성하여 클라우드로 (사실상 무료로) 푸시하고, 대부분의 데이터는 클라우드에서 분석된다. 더 적은 양의 데이터만 온프레미스로 다시 푸시된다.
2.6 멀티클라우드
여러 퍼블릭 클라우드에 워크로드를 배포하는 것이다. 동기: SaaS 플랫폼이 고객 워크로드에 가깝게 서비스를 제공하려는 경우, 여러 클라우드의 최고 서비스를 활용하려는 경우.
단점: 데이터 이그레스 비용, 네트워킹 병목, 서비스 관리 복잡도, 크로스 클라우드 통합·보안 과제.
2.7 교재의 조언
현재를 위한 기술을 선택하되 미래에 대한 시야를 유지하라. 불필요하게 복잡한 멀티클라우드나 하이브리드 전략을 선택하지 말라. 여러 클라우드에서 고객 가까이 데이터를 서빙해야 하는 이유, 산업 규제로 특정 데이터를 자체 데이터 센터에 보관해야 하는 이유, 두 다른 클라우드의 특정 서비스가 필요한 기술적 이유가 없다면 단일 클라우드 전략을 선택하라.
단, 탈출 계획(escape plan)을 가져라. 이상적으로 이 계획은 유리 뒤에 잠겨 있겠지만, 이 계획을 준비하는 것이 현재의 더 나은 결정을 돕고 미래에 문제가 생겼을 때 탈출구가 된다.
3 핵심 요약
첫째, 불변 기술을 기반으로 삼고 일시적 기술을 그 위에 배치하라. 2년마다 재평가하라.
둘째, 클라우드는 온프레미스가 아니다. 클라우드 가격 모델을 이해하고 최적화하라. 단순 리프트 앤 시프트는 비용 재앙의 시작이다.
셋째, 단순성을 우선하라. 불필요한 멀티클라우드 복잡성을 피하되, 탈출 계획은 항상 가져라.
4 참고 문헌
- Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.4 §4.5-4.6.
- Wang, S. & Casado, M. (2021). “The Cost of Cloud, a Trillion Dollar Paradox.” a16z.