1 상호운용성
기술 선택에서 단일 기술이나 시스템만 사용하는 경우는 거의 없다. 기술을 선택할 때 다른 기술과 어떻게 연결, 정보 교환, 상호작용하는지를 확인해야 한다.
상호운용성(Interoperability)은 다양한 기술이나 시스템이 서로 연결하고, 정보를 교환하고, 상호작용하는 방식을 설명한다. (Reis, 2022, Ch.4)
1.1 통합 난이도 스펙트럼
기술 A와 기술 B의 통합을 평가할 때, 난이도는 원활함(seamless)에서 시간 집약적(time-intensive)까지의 스펙트럼에 놓인다.
| 통합 수준 | 특성 | 예시 |
|---|---|---|
| 원활 | 제품에 통합이 내장되어 설정이 간편 | 대부분의 수집·시각화 도구가 인기 DW와 내장 통합 |
| 표준 기반 | 공통 표준으로 연결 | JDBC/ODBC — 거의 모든 DB가 지원 |
| 비표준 통합 | 벤더/프로젝트가 개별적으로 보장 | REST API — 실제 표준이 아니라 각 API마다 고유 특성 |
| 수동 구성 | 많은 수동 설정 필요 | 커스텀 커넥터 개발 |
1.2 표준의 역할
JDBC(Java Database Connectivity)와 ODBC(Open Database Connectivity)는 거의 모든 DB가 지원하는 연결 표준이다. 이 표준이 존재하기 때문에 어떤 DB든 쉽게 연결할 수 있다.
반면 REST(Representational State Transfer)는 진정한 API 표준이 아니다. 모든 REST API가 고유한 특성(quirks)을 가진다. 이 경우 통합의 원활함은 벤더나 OSS 프로젝트가 다른 기술·시스템과의 부드러운 통합을 보장하는지에 달려 있다.
1.3 실무 지침
항상 수명주기 전체에서 다양한 기술을 연결하는 것이 얼마나 간단한지를 인식하라. 모듈화를 위해 설계하고, 새로운 프랙티스와 대안이 등장할 때 기술을 쉽게 교체할 수 있는 능력을 확보하라.
2 비용 최적화와 비즈니스 가치
비용은 아키텍처와 기술 선택의 주요 제약(major constraint)이다. 조직은 데이터 프로젝트에서 긍정적인 ROI를 기대한다. 기술은 주요 비용 동인이므로, 기술 선택과 관리 전략이 예산에 큰 영향을 미친다. 비용을 세 가지 렌즈로 본다: TCO, TOCO, FinOps.
2.1 총소유비용 (TCO)
총소유비용(TCO)은 이니셔티브의 총 추정 비용이며, 사용된 제품과 서비스의 직접 비용과 간접 비용을 포함한다. (Reis, 2022, Ch.4)
| 비용 유형 | 정의 | 예시 |
|---|---|---|
| 직접 비용 | 이니셔티브에 직접 귀속 가능 | 팀 급여, AWS 청구서 |
| 간접 비용 (오버헤드) | 이니셔티브와 무관하게 지불 | 사무실 임대, 일반 관리비 |
2.2 CapEx vs OpEx
구매 방식이 비용 회계에 영향을 미친다.
| 구분 | CapEx (자본 지출) | OpEx (운영 비용) |
|---|---|---|
| 지불 시점 | 오늘 (선불) | 점진적 (사용 기반) |
| 초점 | 장기 | 단기 |
| 유연성 | 낮음 | 높음 |
| 예시 | 하드웨어 구매, 대규모 계약 | 클라우드 사용량 기반 요금 |
| 회계 처리 | 자산으로 감가상각 | 직접 비용으로 귀속 |
클라우드 이전까지 대규모 데이터 프로젝트에 OpEx는 선택지가 아니었다. 데이터 시스템은 종종 수백만 달러 계약을 요구했다. 클라우드의 소비 기반 모델이 이를 바꾸었다. OpEx는 엔지니어링 팀에게 소프트웨어와 하드웨어를 선택하는 훨씬 더 큰 유연성을 제공한다.
교재의 권장: OpEx 우선 접근법(opex-first approach) — 클라우드 중심, 유연한 사용량 기반 기술을 선택하라. 데이터 환경이 너무 빠르게 변하므로, 구식이 되고 쉽게 확장할 수 없는 장기 하드웨어에 투자하는 것은 유연성을 해친다.
2.3 총기회비용 (TOCO)
총기회비용(TOCO)은 기술, 아키텍처, 프로세스를 선택함으로써 발생하는 잃어버린 기회의 비용이다. (Reis, 2022, Ch.4)
모든 선택은 본질적으로 다른 가능성을 배제한다. 데이터 스택 A를 선택하면, B, C, D는 배제된다. A와 그에 수반되는 모든 것 — 지원 팀, 교육, 설정, 유지보수 — 에 투입(committed)된다.
핵심 질문: - 스택 A가 잘못된 선택이면 어떻게 되는가? - 스택 A가 구식이 되면 어떻게 되는가? - 다른 스택으로 이동할 수 있는가? - 얼마나 빨리, 얼마나 저렴하게 더 새롭고 나은 것으로 이동할 수 있는가?
교재는 유연하지 않은 데이터 기술을 곰 덫(bear trap)에 비유한다. 들어가기는 쉽지만 빠져나오기는 극히 고통스럽다. 기회비용을 최소화하는 첫 번째 단계는 눈을 크게 뜨고(with eyes wide open) 평가하는 것이다.
교재의 경험: 수많은 데이터 팀이 당시에는 좋아 보였지만 미래 성장에 유연하지 않거나 단순히 구식이 된 기술에 갇히는 것을 목격했다.
2.4 FinOps: 비용 절감이 아니라 수익 창출
“FinOps가 비용 절감에 관한 것처럼 보인다면, 다시 생각하라. FinOps는 돈을 버는 것이다(FinOps is about making money). 클라우드 지출은 더 많은 수익을 창출하고, 고객 기반 성장을 신호하고, 제품과 기능의 출시 속도를 높이고, 심지어 데이터 센터를 폐쇄하는 데 기여할 수 있다.” — Cloud FinOps, J.R. Storment & Mike Fuller
데이터 엔지니어링 맥락에서, 빠르게 반복하고 동적으로 확장하는 능력은 비즈니스 가치 창출에 매우 귀중하다. 이것이 데이터 워크로드를 클라우드로 전환하는 주요 동기 중 하나이다.
3 비용 의사결정 프레임워크
TCO, TOCO, FinOps를 통합한 비용 의사결정 프레임워크를 정리하면 다음과 같다.
| 렌즈 | 질문 | 관점 |
|---|---|---|
| TCO | 이 기술의 직접+간접 총비용은? | 현재의 지출 |
| TOCO | 이 선택으로 포기하는 기회의 가치는? | 배제된 대안 |
| FinOps | 클라우드 지출이 비즈니스 가치를 극대화하는가? | 가치 창출 |
세 렌즈 중 TOCO가 가장 간과되기 쉽다. TCO는 청구서에서 보이고, FinOps는 대시보드에서 모니터링할 수 있지만, TOCO는 보이지 않는 비용이다. 선택하지 않은 길의 가치는 사후에야 드러나는 경우가 많다.
4 핵심 요약
첫째, 상호운용성은 모듈화 전략의 전제 조건이다. 기술을 교체할 수 있으려면 먼저 기술 간 통합이 원활해야 한다.
둘째, 비용 분석은 TCO만으로 충분하지 않다. TOCO(기회비용)와 FinOps(가치 창출)를 함께 고려해야 최적의 기술 선택이 가능하다.
셋째, OpEx 우선 접근법이 데이터 환경의 빠른 변화에 가장 적합하다. 장기 하드웨어 투자보다 클라우드 기반의 유연한 사용량 모델이 더 나은 트레이드오프를 제공한다.
5 참고 문헌
- Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.4 §4.3-4.4.
- Storment, J. R. & Fuller, M. (2019). Cloud FinOps. O’Reilly.
- Reis, J. “Total Opportunity Cost of Ownership.” In 97 Things Every Data Engineer Should Know. O’Reilly.