데이터 엔지니어링 기술 스택, 도대체 무엇을 써야 할까? (실전 선택 가이드)

들어가며: 선택의 역설, 무엇을 골라야 할까? #

2026년인 지금, 데이터 엔지니어링 생태계는 그 어느 때보다 풍요롭습니다. 하지만 아이러니하게도 선택지는 너무 많아졌고, 엔지니어들의 고민은 오히려 깊어졌습니다. “요즘은 이게 대세라더라"라는 말만 믿고 덜컥 도입했다가, 운영 비용을 감당하지 못하거나 유지보수의 늪에 빠져 고생하는 경우를 종종 봅니다.

기술 선택에서 가장 중요한 건 ‘남들이 뭘 쓰느냐(Trend)‘가 아니라 ‘지금 우리에게 필요한 게 무엇인가(Context)’ 입니다. 이 글에서는 복잡한 기술 용어는 잠시 접어두고, 우리가 현업에서 마주하는 구체적인 고민 들을 중심으로 상황별 최적의 기술 스택을 제안해드리려 합니다.

1. 기술 선정의 3가지 핵심 질문 #

아무리 복잡해 보이는 요구사항도 결국 다음 세 가지 질문으로 좁혀집니다. 이 질문들에 대한 답이 곧 우리 팀의 아키텍처가 됩니다.

1. 지연 시간 (Latency) : 데이터가 얼마나 빨리 보여야 하나요?
   • 1초 미만으로 즉시 반응해야 하나요? (Real-time)
   • 1시간, 혹은 하루 정도 늦게 봐도 괜찮은가요? (Batch)
2. 데이터 가변성 (Mutability) : 데이터가 수정되기도 하나요?
   • 한 번 쌓이면 절대 변하지 않는 로그성 데이터인가요? (Immutable)
   • 주문 취소나 회원 정보 변경처럼, 과거 데이터가 수시로 바뀌나요? (Upsert)
3. 동시성 (Concurrency) : 누가 얼마나 많이 조회하나요?
   • 사내 분석가가 가끔 무거운 쿼리를 돌리는 수준인가요? (Low Concurrency)
   • 수만 명의 고객이 앱에서 실시간으로 대시보드를 보나요? (High Concurrency)

2. 상황별 추천 스택 (When to use What) #

시나리오 A: “고객에게 실시간 지표를 보여줘야 해요.” #

• 이런 고민 중이라면: “1초라도 늦으면 안 돼요”, “수만 명이 동시에 접속해요”
• 추천 조합: Kafka + Apache Flink + StarRocks

[상세 설명]

• Kafka (수집) : 실시간 처리의 시작점입니다. 쏟아지는 데이터를 안정적으로 받아내고, 뒤단(Downstream) 시스템들이 각자의 속도로 데이터를 가져갈 수 있도록 버퍼 역할을 해줍니다.
• Apache Flink (처리) : Spark Streaming도 훌륭하지만, 마이크로 배치(Micro-batch) 구조의 한계가 있습니다. 이벤트가 발생한 시간(Event Time)을 기준으로 상태(State)를 정밀하게 관리하거나, 밀리세컨드(ms) 단위의 완전한 이벤트 기반 처리 가 필요하다면 Flink가 독보적입니다.
• StarRocks (서빙) : 수천, 수만 명의 사용자가 동시에 보는 대시보드는 일반적인 DW로는 감당하기 어렵습니다. StarRocks는 압도적인 동시성 처리 능력은 물론, 강력한 조인(Join) 성능 을 제공합니다. 덕분에 데이터를 억지로 비정규화(Denormalization)하지 않고도 RDB처럼 유연하게 서빙할 수 있습니다.

시나리오 B: “데이터는 엄청 많은데, 비용은 아끼고 싶어요.” #

• 이런 고민 중이라면: “S3에 싸게 저장하고 싶어요”, “데이터 내용이 가끔 바뀌기도 해요”
• 추천 조합: Apache Iceberg + Trino

[상세 설명]

• Apache Iceberg (저장) : S3 같은 저렴한 객체 저장소를 쓰면서도 DB처럼 트랜잭션을 보장받고 싶으신가요? Iceberg는 파일 더미에 ‘테이블’이라는 질서를 부여하여, 데이터 레이크에서도 안전하게 UPDATE, DELETE를 수행할 수 있게 해줍니다. 이것이 바로 최근 주목받는 ‘데이터 레이크하우스(Data Lakehouse)’ 의 핵심입니다.
• Trino (조회) : Iceberg에 쌓인 페타바이트급 데이터를 DB로 옮기지 않고 바로 분석하고 싶다면 Trino가 제격입니다. 저장소(S3)와 연산(Trino)이 분리되어 있어, 평소엔 저장 비용만 내다가 쿼리를 날릴 때만 컴퓨팅 자원을 쓰면 되니 비용 효율이 극대화됩니다.

시나리오 C: “복잡한 정산 데이터, 매일 밤 정확하게 맞춰야 해요.” #

• 이런 고민 중이라면: “대규모 데이터를 한방에 처리해야 해요”, “절대 틀리면 안 돼요”
• 추천 조합: Apache Spark + Airflow

[상세 설명]

• Apache Spark (처리) : “어제 쌓인 데이터 전체"를 가지고 복잡한 연산을 해야 한다면 배치 처리의 왕, Spark를 쓰세요. 메모리 기반이라 빠르고, 방대한 라이브러리 덕분에 아무리 복잡한 비즈니스 로직도 우아하게 풀어낼 수 있습니다.
• Apache Airflow (관리) : 데이터 파이프라인의 관제탑입니다. “A 작업 끝나면 B 실행하고, 실패하면 3번 재시도해” 같은 의존성 관리에 있어 가장 널리 쓰이는 표준 도구입니다. 복잡한 워크플로우를 코드로 정의(IaC)하여 체계적으로 관리할 수 있습니다.

3. 한눈에 보는 결정 가이드 #

4. 마치며: 도구는 거들 뿐 #

결국 가장 좋은 아키텍처는 ‘현재의 문제’를 가장 단순하게 해결하는 구조 입니다.

• 데이터가 작다면? 굳이 분산 처리할 필요 없이 RDB(PostgreSQL 등) 하나면 충분합니다.
• 실시간이 꼭 필요한 게 아니라면? 맘 편한 배치(Batch)로 시작하세요. 운영 난이도가 확 낮아집니다.

유행을 좇기보다는 위에서 말씀드린 지연 시간, 데이터 가변성, 동시성 이라는 세 가지 기준을 가지고 우리 팀의 상황을 먼저 진단해 보시기 바랍니다. 여러분의 현명한 기술 선택을 응원합니다.

이 글은 AI의 도움을 받아 교정 및 정리되었습니다.