[견고한 데이터 엔지니어링] CH4. 데이터 엔지니어링 수명 주기 전체에 걸친 기술 선택

왜 기술 선택이 데이터 엔지니어링 수명 주기 전체에 걸쳐 중요한가

데이터 엔지니어링에서 기술 선택은 특정 단계(수집·저장·변환·서빙)에 국한되지 않는다.

한 번 선택한 기술은

• 운영 방식,
• 팀의 생산성,
• 비용 구조,
• 미래 확장 가능성

까지 수명 주기 전체에 장기적인 영향을 미친다. 따라서 기술 선택은 “최신인가?”가 아니라 “우리에게 맞는가?”의 문제다.

1 팀의 규모와 역량을 먼저 고려하라

카고-컬트 엔지니어링의 위험

소규모 데이터 팀이

대기업의 최첨단 스택이나 복잡한 아키텍처를 그대로 모방하는 것은 카고-컬트 엔지니어링의 전형적인 사례다.

문제점

• 운영·유지 불가
• 디버깅 불가능
• 팀 역량 대비 과도한 복잡성

현실적인 선택

• 소규모 팀, 기술 성숙도가 낮다면
• → 관리형 도구 + SaaS 적극 활용
• 팀이 이미 익숙한 기술과 워크플로를 우선 선택

→ 기술은 팀을 돕기 위한 것이지, 팀을 압도하면 안 된다.

2 시장 출시 속도(Time to Market)

빠르게 가치를 전달하지 못하는 기술은

아무리 정교해도 실패할 가능성이 크다.

중요한 기준:

• 이미 잘 아는 도구인가?
• 보안과 품질을 유지하면서 빠르게 배포 가능한가?
• 실험과 반복이 가능한가?

“완벽한 기술”보다 “빨리 전달할 수 있는 기술”이 이긴다.

3 상호 운용성(Interoperability)

기술은 혼자 존재하지 않는다. 항상 다른 기술과 연결되고 정보를 교환한다.

확인해야 할 질문:

• 다른 시스템과 쉽게 연결되는가?
• 표준 포맷/프로토콜을 지원하는가?
• 특정 벤더에 강하게 종속되는가?

⇒ 상호 운용성이 낮을수록 미래 변경 비용은 기하급수적으로 커진다.

4 비용 최적화와 비즈니스 가치

총소유비용(TCO, Total Cost of Ownership)

TCO는 직접 비용 + 간접 비용의 합이다.

• 직접 비용: 라이선스, 클라우드 사용료 등
• 간접 비용: 운영 인력, 장애 대응, 학습 비용

구매 방식의 차이

• 설비투자(CapEx)
• → 초기 대규모 투자, 유연성 낮음
• 운영비용(OpEx)
• → 종량제, 점진적 지출, 유연성 높음

클라우드는 본질적으로 운영비용 모델이다.

총소유 기회비용

기술·아키텍처·프로세스 선택으로 인해

하지 못하게 되는 것들의 비용도 고려해야 한다.

핀옵스(FinOps)

핀옵스는

• 클라우드 지출을 데이터 기반으로 관리하고
• 기술·재무·비즈니스 팀 간 협업을 가능하게 한다.

→ 비용은 사후 정산이 아니라 설계 단계의 요소다.

5 현재 vs 미래: 불변의 기술과 일시적 기술

불변의 기술

오랜 시간 살아남아 온 기술들:

• 클라우드 핵심 컴포넌트
• (객체 스토리지, 네트워킹, 서버, 보안)
• 언어 및 도구
• (SQL, Bash)

일시적 기술

• 특정 시기에 각광받았다가 사라질 수 있는 기술
• 예: 프런트엔드 프레임워크, 특정 쿼리 엔진

기술 선택 시 질문

“이 기술이 사라져도 대체할 수 있는가?”

6 장소(Location): 어디에서 실행할 것인가

온프레미스

• 하드웨어 직접 소유
• 컨테이너·쿠버네티스·CI/CD 도입 가능
• 하지만 운영 부담 큼

클라우드

• IaaS / PaaS / SaaS
• 서버리스: 0에서 자동 확장
• 운영 부담 감소, 민첩성 증가

하이브리드 클라우드

• 온프레미스 + 클라우드 혼합
• 예: 온프레미스 Spark → 클라우드 임시 클러스터
• 대규모 작업을 빠르게 확장 가능

멀티클라우드

• 여러 퍼블릭 클라우드에 워크로드 분산
• 장점: 벤더 종속 완화
• 단점: 데이터 이그레스 비용, 네트워크 병목

탈중앙화: 블록체인과 엣지

• 데이터가 중앙이 아닌 가까운 위치에서 처리
• IoT, 실시간 처리에서 중요

클라우드 송환(Cloud Repatriation)

드롭박스·넷플릭스처럼

규모가 충분하면 자체 인프라가 더 합리적일 수 있음.

⇒ 클라우드는 “항상 정답”은 아니다.

7 구축(Build) vs 구매(Buy)

구축이 필요한 경우

• 핵심 경쟁 우위를 제공
• 비즈니스에 직접적인 차별화 요소

구매가 나은 경우

• 이미 시장에 검증된 솔루션이 존재
• 운영 부담을 줄이는 것이 더 중요

8 오픈소스 소프트웨어(OSS) 선택 기준

OSS는 자유롭지만 책임도 함께 온다.

확인해야 할 요소:

• 인지도: GitHub 스타, 포크, 커밋
• 성숙도: 사용 기간, 실제 활용 사례
• 문제 해결: 커뮤니티 응답성
• 프로젝트 관리: 이슈 대응 방식
• 팀/후원: 기업 후원 여부
• 커뮤니티: 슬랙/포럼 존재 여부
• 기여 문화: PR 수용 여부
• 로드맵: 투명성
• 자체 호스팅 가능 여부
• 커뮤니티 환원 가능성

상용 OSS

• OSS 기반이지만 상용 서비스로 제공
• 운영·유지관리 부담 감소
• 예: 데이터브릭스, 컨플루언트, dbt Labs

고려 요소:

• 제공 가치
• 지원 모델
• 릴리스/버그 수정 주기
• 가격 정책
• 회사의 재정적 지속 가능성
• 커뮤니티 지원 진정성

9 전용 폐쇄형 네트워크 서비스

• 클라우드 플랫폼 전용 서비스(DB, 스토리지 등)
• 성능과 편의성은 뛰어남
• 상호 운용성과 벤더 종속성은 신중히 평가

10 모놀리식 vs 모듈식

모놀리스

• 단일 시스템
• 추론이 쉽고 단순
• 하지만 깨지기 쉽고 확장·변경 어려움

모듈식

• 시스템을 독립 컴포넌트로 분리
• API 기반 통신
• 리팩터링·교체 용이
• 다중 언어(polyglot) 가능

단점: 고려할 요소가 많고 운영 복잡성 증가

분산형 모놀리스 패턴

• 분산되어 있지만 강한 의존성
• 하나의 작업을 위해 전체 클러스터 라이브러리 필요
• 해결책: 임시 인프라 + 컨테이너

11 서버리스 vs 컨테이너 vs 서버

서버리스

• 작은 코드 단위 실행(FaaS)
• 자동 확장
• 이벤트가 많으면 비용 증가 가능

컨테이너

• 경량 가상 머신
• 쿠버네티스 기반
• 유연하지만 운영 복잡성 있음

서버 평가 기준

• 사용량
• 비용
• 장애 대응
• 오토스케일링
• IaC 활용 여부

12 성능 최적화와 벤치마크

• 실제 데이터와 쿼리 크기를 시뮬레이션
• 과도한 벤치마크 경쟁은 무의미
• 비대칭 최적화
• → 행 기반 vs 열 기반 시스템의 차이 인식

13 드러나지 않는 요소들 (Hidden Layers)

데이터 관리

• 보안
• 개인정보 보호
• 호스팅 정책

데이터 옵스

• 배포 통제
• 모니터링
• 장애 알림 및 대응

관리형 서비스:

• 벤더 SLA
• 문제 인지 방식
• 복구 ETA

오케스트레이션

• Airflow: 성숙하지만 병목 가능
• 스케줄러/DB 의존성
• 스키마·계보·카탈로그 미지원

대안:

• Prefect
• Dagster

소프트웨어 엔지니어링

• 데이터 스택 단순화
• 추상화 수준 향상
• 테스트·배포 자동화