1 구축 vs 구매
구축(build) vs 구매(buy)는 기술 분야의 오래된 논쟁이다.
| 입장 | 주장 | 트레이드오프 |
|---|---|---|
| 구축 | 솔루션에 대한 완전한 통제, 벤더나 커뮤니티에 종속되지 않음 | 높은 개발·유지 비용, 전문 인력 필요 |
| 구매 | 리소스 제약과 전문성 부족 해결 | 벤더 종속 위험, 커스터마이징 한계 |
어느 결정이든 TCO, TOCO, 그리고 그 솔루션이 조직에 경쟁 우위를 제공하는지로 귀결된다.
경쟁 우위를 제공할 때 구축하고 커스터마이징하라. 그 외에는 거인의 어깨 위에 서서 시장에 이미 존재하는 것을 사용하라. (Reis, 2022, Ch.4)
교재의 비유: “새 타이어가 필요할 때 원재료를 구해서 직접 만들고 장착하는가?” 대부분의 사람처럼 타이어를 사고 누군가에게 장착하게 한다. 같은 논리가 구축 vs 구매에 적용된다. 자체 DB를 처음부터 구축한 팀을 교재는 목격했는데, 단순한 오픈소스 RDBMS가 훨씬 더 적합했을 것이다.
1.1 Type A vs Type B 엔지니어와의 연결
Ch.1에서 소개한 Type A(추상화)와 Type B(구축) 구분이 여기서 실용적으로 적용된다. 특히 소규모 조직에서 두 역할은 같은 엔지니어에게 공존한다. 가능하면 Type A 행동을 지향하라: 차별화되지 않는 무거운 작업을 피하고 추상화를 수용하라.
1.2 오픈소스 소프트웨어 (OSS)
OSS에는 두 가지 풍미가 있다.
커뮤니티 관리 OSS: 강한 커뮤니티와 활발한 사용자 기반으로 성공한다. 평가 기준:
| 기준 | 확인 사항 |
|---|---|
| 마인드셰어 | GitHub 스타, 포크, 커밋 빈도·최신성, 커뮤니티 활동 |
| 성숙도 | 프로젝트 존속 기간, 프로덕션 사용 정도 |
| 문제 해결 | 문제 발생 시 자체 해결 vs 커뮤니티 지원 |
| 프로젝트 관리 | Git 이슈 대응 속도와 프로세스 |
| 팀 | 기업 스폰서 여부, 핵심 기여자 |
| 로드맵 | 투명하고 명확한 로드맵 존재 여부 |
| 자체 호스팅 | 호스팅·유지보수 리소스 보유 여부, TCO vs 관리형 서비스 |
상용 OSS (COSS): 커뮤니티 OSS의 호스팅·관리 부담을 벤더가 해결한다. Databricks(Spark), Confluent(Kafka), dbt Labs(dbt)가 대표적이다. 전형적 경로: OSS 인기 → 유지관리자가 상용 버전을 위한 별도 회사 설립 → VC 자금 → 클라우드 SaaS 플랫폼.
COSS 평가 추가 기준:
| 기준 | 확인 사항 |
|---|---|
| 가치 | 자체 관리 대비 더 나은 가치를 제공하는가? |
| 지원 | 지원 모델과 추가 비용, 지원 범위 |
| 회사 재정 | 자금 조달 상황, 생존 가능성 |
| 로고 vs 매출 | 고객 수 확대 vs 매출 성장 중 무엇에 집중하는가? |
| 커뮤니티 지원 | 회사가 커뮤니티 OSS에 실제로 기여하는가? |
1.3 프로프라이어터리 솔루션
독립 제품: 벤더가 OSS로 공개하지 않고 프로프라이어터리로 제공하는 솔루션. 상호운용성, 마인드셰어/시장 점유율, 문서화/지원, 가격 투명성, 생존 가능성(longevity)을 평가하라.
클라우드 플랫폼 프로프라이어터리: 각 클라우드 벤더의 자체 서비스. Amazon이 내부 도구로 DynamoDB를 만들고 나중에 AWS에서 서비스로 제공한 것이 대표적이다. 클라우드 벤더는 제품을 번들링하여 생태계의 접착성(stickiness)을 만든다.
1.4 소프트웨어 채택의 변화
과거에는 IT가 하향식(top-down)으로 소프트웨어를 채택했지만, 현재는 개발자·데이터 엔지니어·데이터 사이언티스트 등 기술 역할이 주도하는 상향식(bottom-up) 채택이 트렌드이다.
2 모놀리스 vs 모듈
2.1 모놀리스
모놀리스는 수십 년간 기술의 주력이었다. 폭포수 방식의 대규모 릴리스, 밀결합, 느린 케이던스. Informatica, Spark 같은 모놀리식 데이터 시스템이 오늘날에도 존재한다.
| 장점 | 단점 |
|---|---|
| 추론이 쉽다 | 취약하다 — 한 곳의 버그가 전체에 영향 |
| 인지적 부담과 컨텍스트 전환이 적다 | 업데이트/릴리스가 느리다 |
| 하나의 기술, 하나의 주 프로그래밍 언어 | 벤더/프로젝트 사망 시 전환이 고통스럽다 |
| 멀티테넌시 문제 — 한 사용자의 작업이 다른 사용자에 영향 |
교재의 사례: 48시간이 걸리는 모놀리식 ETL 파이프라인. 파이프라인 어디에서든 무언가가 깨지면 전체 프로세스가 재시작되어야 했다. 불안한 비즈니스 사용자들은 기본적으로 이틀 늦은 리포트를 기다렸고, 보통 그보다 훨씬 늦게 도착했다. 결국 이 모놀리식 시스템은 폐기되었다.
2.2 모듈화
모듈화는 소프트웨어 엔지니어링의 오래된 개념이지만, 마이크로서비스의 부상과 함께 본격화되었다. 각 서비스가 자체 관심 영역에 집중하고, API를 통해 통신한다.
Bezos의 투 피자 룰(two-pizza rule): 팀이 두 판의 피자로 먹일 수 없을 만큼 커서는 안 된다 (최대 5명). 이 상한이 팀 책임의 복잡도를 제한하고, 대규모 모놀리식 애플리케이션을 작고 관리 가능한 소결합 조각으로 분해하도록 강제한다.
모듈화된 마이크로서비스 환경에서는 폴리글랏(polyglot) 애플리케이션이 가능하다. Java 서비스가 Python 서비스를 교체할 수 있다. 서비스 소비자는 API의 기술 사양만 신경 쓰면 되고, 구현의 뒤편 세부사항은 알 필요 없다.
데이터 처리 기술도 모듈화 모델로 전환했다. 데이터 레이크와 레이크하우스에서 Parquet 같은 표준 포맷으로 오브젝트 스토리지에 데이터를 저장하면, 해당 포맷을 지원하는 어떤 처리 도구든 데이터를 읽고 쓸 수 있다.
2.3 분산 모놀리스 패턴
분산 모놀리스는 분산 아키텍처이지만 모놀리식 아키텍처의 많은 한계를 그대로 가지는 패턴이다. 서로 다른 서비스가 서로 다른 작업을 수행하지만, 공통 의존성 세트나 공통 코드베이스를 공유한다. (Reis, 2022, Ch.4)
전통적 Hadoop 클러스터가 대표적 예이다. Hive, Pig, Spark 같은 여러 프레임워크를 동시에 호스팅하면서, Hadoop 공통 라이브러리, HDFS, YARN, Java를 공유한다. 하나의 프레임워크 업그레이드가 다른 작업을 깨뜨릴 수 있고, 두 버전을 유지하면 복잡도가 추가된다.
Apache Airflow도 이 문제를 겪는다. 고도로 탈결합된 비동기 아키텍처이지만, 모든 서비스가 같은 코드베이스와 같은 의존성을 실행한다. 하나의 DAG에서 사용하는 클라이언트 라이브러리가 전체 클러스터에 설치되어야 한다.
해결책: 1. 임시 인프라(ephemeral infrastructure): 각 작업이 자체 임시 서버/클러스터에서 의존성과 함께 실행. Amazon EMR, Google Cloud Dataproc이 이 패턴을 사용한다. 2. 컨테이너: 분산 모놀리스를 여러 소프트웨어 환경으로 적절히 분해한다.
3 교재의 조언
모놀리스의 단순성은 매력적이지만, 그 대가는 유연성 상실, 기회비용 증가, 높은 마찰의 개발 주기이다.
평가 시 고려사항:
| 항목 | 권장 |
|---|---|
| 상호운용성 | 공유와 상호운용성을 위해 설계하라 |
| 곰 덫 회피 | 들어가기 쉽지만 빠져나오기 고통스러운 기술을 경계하라 |
| 유연성 | 데이터 분야의 빠른 변화를 고려하면, 모놀리스 투입은 유연성과 가역적 결정을 줄인다 |
4 핵심 요약
첫째, 구축 vs 구매의 핵심 기준은 경쟁 우위이다. 경쟁 우위가 아닌 것은 기성품(OSS, COSS, 관리형 서비스)을 사용하라.
둘째, 모듈화는 도구 교체의 유연성을 주지만 오케스트레이션 복잡도가 증가한다. 분산 모놀리스 안티패턴에 빠지지 않도록 컨테이너와 임시 인프라를 활용하라.
셋째, 소프트웨어 채택은 하향식에서 상향식으로 이동하고 있다. 기술 역할의 현장 판단이 기술 선택에 더 큰 영향을 미친다.
5 참고 문헌
- Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Ch.4 §4.7-4.8.