데이터 엔지니어링 기술 스택, 무엇을 기준으로 고를까?

들어가며: 선택지가 많을수록 기준이 필요하다 #

2026년의 데이터 엔지니어링 생태계는 선택지가 많습니다. 문제는 선택지가 많아질수록 판단이 쉬워지는 게 아니라는 점입니다. “요즘은 이게 대세라더라"라는 말만 믿고 들여왔다가, 운영 비용이나 유지보수 부담 때문에 뒤늦게 고생하는 경우도 적지 않습니다.

기술 선택에서 먼저 봐야 할 것은 ‘남들이 뭘 쓰느냐(Trend)‘가 아니라 ‘지금 우리에게 필요한 게 무엇인가(Context)’ 입니다. 이 글에서는 복잡한 기술 용어보다 현업에서 자주 마주치는 고민을 기준으로, 상황별로 어떤 기술 조합을 검토할 만한지 정리합니다.

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

복잡해 보이는 요구사항도 대개 다음 세 가지 질문으로 좁혀집니다. 이 질문에 대한 답이 우리 팀의 아키텍처 방향을 정합니다.

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

2. 상황별 추천 스택 #

시나리오 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번 재시도한다” 같은 의존성 관리가 필요할 때 많이 씁니다. 워크플로우를 코드로 정의할 수 있어, 작업이 늘어날수록 수동 운영보다 안정적입니다.

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

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

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

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

유행을 먼저 따라가기보다 지연 시간, 데이터 가변성, 동시성 이라는 세 가지 기준으로 우리 팀의 상황을 먼저 확인하는 편이 낫습니다. 기준이 분명하면 도구 선택도 훨씬 덜 흔들립니다.

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