데이터 엔지니어링 위클리 #8 | Hadoop, Netflix Maestro, Senior Data Engineer

2025. 4. 23. 06:23ㆍ데이터 엔지니어링 위클리

Articles

넷플릭스가 Maestro로 수백만 개의 작업 흐름을 어떻게 조정하는지

Netflix는 데이터를 활용한 작업과 머신러닝 워크플로우를 효과적으로 관리하기 위해 Maestro라는 새로운 워크플로우 오케스트레이터를 개발했습니다. Maestro는 이전의 Meson 시스템의 한계를 극복하고, 수십만 개의 작업을 효율적으로 관리할 수 있는 분산 아키텍처를 갖추고 있습니다. 이 글은 Maestro의 설계와 개발 과정에서의 도전 과제들을 다루고 있습니다.

Netflix는 Meson을 통해 70,000개의 워크플로우와 500,000개의 작업을 관리했지만, 시스템의 한계로 인해 새로운 오케스트레이터인 Maestro를 개발하게 되었습니다.
Maestro는 마이크로서비스 아키텍처를 기반으로 하여 높은 신뢰성과 낮은 운영 오버헤드를 유지하며, 다양한 사용자 요구를 충족시킵니다.
작업의 파라미터화, 신호 서비스, 스케일링 기술 등 다양한 기능을 통해 복잡한 데이터 및 ML 파이프라인을 쉽게 구성할 수 있도록 지원합니다.

개요

이번 글에서는 Netflix의 새로운 워크플로우 오케스트레이터인 Maestro에 대해 살펴보겠습니다. Maestro는 Netflix가 데이터와 머신러닝(ML) 워크플로우의 복잡한 관리 문제를 해결하기 위해 개발된 시스템으로, 그 배경과 설계 원리에 대해 알아보겠습니다.

Meson에서 Maestro로의 발전

Netflix는 첫 번째 워크플로우 오케스트레이터인 Meson을 사용하여 약 70,000개의 워크플로우와 500,000개의 일일 작업을 관리했습니다. 그러나 데이터 사용량이 급증하면서 Meson은 성능 문제를 겪기 시작했고, 특히 트래픽이 많은 시간대에 시스템이 느려지는 문제가 발생했습니다. Meson의 아키텍처가 단일 리더 모델로 구성되어 있어 수직 확장이 필요했기 때문에 한계에 도달했습니다.

Maestro의 설계 및 아키텍처

Maestro는 Meson의 단점을 극복하기 위해 여러 가지 혁신적 기능을 갖춘 다음 세대 오케스트레이터입니다. 마이크로서비스 기반으로 설계되어 필요한 만큼 유연하게 확장할 수 있습니다. 다음은 Maestro의 주요 컴포넌트입니다.

워크플로우 엔진: 워크플로우의 전체 라이프사이클을 관리하며, DAG(Directed Acyclic Graph) 형태로 작업을 정의합니다.
시간 기반 스케줄링: 주기적으로 워크플로우를 실행할 수 있도록 합니다. 이는 가벼운 서비스로 설계되어 효율적으로 확장할 수 있습니다.
신호 서비스: 실시간 이벤트에 따라 워크플로우를 트리거할 수 있어 동적 실행이 가능합니다.

확장성과 신뢰성

Maestro는 수평 확장이 가능하여 많은 워크로드를 처리할 수 있는 능력을 갖추고 있습니다. 모든 서비스는 상태 비저장 마이크로서비스로 설계되어 있으며, 외부 시스템에 상태 정보를 저장함으로써 쉽게 확장할 수 있습니다. 메시지 전달을 위해 분산 큐를 사용하여 서비스 간에 의존성을 줄이고 신뢰성을 향상시킵니다. 또한 CockroachDB를 사용하여 데이터의 높은 일관성을 유지합니다.

다양한 사용자 요구 사항 충족

Maestro는 기술적 배경이 다양한 사용자들을 위해 여러 가지 실행 추상화를 제공합니다. 사용자는 사전 정의된 스텝 유형이나 Jupyter 노트북 실행, Docker 컨테이너 실행 등을 통해 쉽게 워크플로우를 정의하고 실행할 수 있습니다. YAML, Python, Java와 같은 다양한 DSL(도메인 특화 언어)과 GUI를 통해 사용자 친화적인 환경을 제공합니다.

결론

Maestro는 Netflix의 데이터 및 머신러닝 워크플로우 관리의 미래를 여는 중요한 시스템입니다. 수평 확장 가능하고 클라우드 네이티브한 아키텍처를 갖춘 Maestro는 유연성과 확장성을 제공하며, 다양한 사용자 요구를 충족하는 데 초점을 맞추고 있습니다. Netflix의 기술 스택 안에서 Data/ML 워크플로우 오케스트레이션의 새로운 기준을 제시하는 이 시스템은 오픈 소스로 공개되어 다수의 사용자에게 기여할 기회를 마련하고 있습니다.

2025-04-16 00:38:11
ByteByteGo Newsletter
How Netflix Orchestrates Millions of Workflow Jobs with Maestro

우리가 Hadoop을 포기한 이유: 현대 데이터 아키텍처로의 여정

이 글은 Hadoop을 포기하고 현대의 데이터 아키텍처로 전환한 과정과 그로 인해 얻은 예상치 못한 이점과 도전 과제에 대해 이야기합니다. 데이터 엔지니어링 팀이 Hadoop을 사용하면서 직면한 복잡함과 비용 문제를 해결하고, 클라우드 비용 절감 및 데이터 처리 속도 향상과 같은 성과를 달성한 사례를 공유합니다.

Hadoop을 포기한 이유: 관리 비용과 복잡성 증가
6개월 간의 이전 후 클라우드 비용 42% 절감
데이터 처리 속도 3.5배 향상
데이터 아키텍처의 필요와 진화에 따른 적합한 기술의 중요성 강조

개요

최근 데이터 아키텍처의 변화에 대한 이야기로, 우리가 Hadoop을 포기하게 된 과정을 소개하겠습니다. 처음에 Hadoop은 큰 데이터 처리의 기준이었으나, 시간이 지나면서 복잡성과 비용 문제가 불거지게 되었습니다. 결국, Hadoop 클러스터의 운영을 중단하고 더 효율적인 데이터 관리 방식으로 전환했습니다.

Hadoop을 선택하게 된 이유

Hadoop은 우리가 직면한 큰 데이터 처리 문제를 해결하기에 적합한 도구였습니다. 그 당시의 데이터 처리 요구에 맞춰 설계되어, 어떻게든 대규모 데이터 세트를 지원할 수 있는 플랫폼으로 각광받았습니다. 하지만 시대가 바뀌면서 새로운 기술과 툴들이 등장하게 되었고, Hadoop은 점점 비효율적인 선택이 되어갔습니다.

Hadoop 포기의 결정적 순간

우리 팀의 회의 중에 "HDFS 관리자 한 명을 정규직으로 채용해야 한다"는 말이 나왔고, 이는 우리가 Hadoop을 보유하고 있는 것이 더 이상 합리적이지 않다는 신호였습니다. 3년 동안 운영한 Hadoop 클러스터는 점점 더 복잡해지고 비용이 증가하며, 혁신 속도도 늦추는 결과를 낳았습니다. 그렇게 우리는 6개월간의 준비 끝에 마지막 Hadoop 클러스터를 종료했습니다.

이점과 효과

Hadoop을 중단한 후, 우리는 여러 가지 긍정적인 변화들을 경험했습니다. 클라우드 비용이 42% 줄어들었고, 데이터 처리 작업의 속도는 3.5배 빨라졌습니다. 가장 놀라운 점은 데이터 엔지니어링 팀이 새로운 기능을 몇 주가 아닌 며칠 만에 제공할 수 있게 되었다는 것입니다.

결론

Hadoop이 나쁜 기술이라는 이야기가 아닙니다. 시간과 상황에 따라 적합한 도구는 다를 수 있습니다. 데이터 환경이 예상보다 빠르게 변화하면서, 우리는 새로운 기술로의 전환이 필요했고, 그 결과로 더 나은 성과를 이뤘습니다. 이번 여정은 데이터 기술의 발전을 반영하며, 앞으로도 계속해서 변화에 적응해 나가야 할 중요성을 일깨워 줍니다.

2025-04-16 07:35:09
Data Engineer Things
Why We Abandoned Hadoop: Our Journey to a Modern Data Architecture

토스 쇼핑 추천 시스템: 수백만 사용자와 상품을 잇는 멀티 스테이지 접근법

이 글은 토스 쇼핑의 개인화 추천 시스템 개발에 대해 간략히 설명하고 있습니다. 특히, 목적형 사용자와 탐색형 사용자를 구분하여 이들의 특성에 맞춘 멀티 스테이지 접근 방식을 통해 최적의 상품 추천을 구현하는 과정에 대해 다룹니다.

토스 쇼핑은 사용자의 데이터 기반으로 개인화된 추천을 제공합니다.
주요 소비자 유형으로는 목적형 사용자와 탐색형 사용자가 있으며, 후자의 비율이 높습니다.
추천 시스템은 Retrieval, Ranking, Re-ranking의 세 가지 단계로 구성되어 있습니다.
각 단계에서는 성과 최적화를 위한 다양한 모델이 적용됩니다.
최종적으로 사용자 경험과 비즈니스 목표를 모두 충족시키는 것을 목표로 합니다.

개요

안녕하세요! 저는 토스 커머스 개인화팀의 ML Engineer 김정오입니다. 오늘은 토스 쇼핑에서 어떻게 사용자에게 최적의 상품을 추천하는 개인화 추천 시스템을 구축하고 있는지 간략히 설명드리겠습니다.

사용자 유형

토스 쇼핑에서는 두 가지 주요 사용자 유형이 있습니다.

목적형 사용자: 특정 상품이나 범주에 대한 명확한 구매 목표를 가지고 있는 사용자입니다. 이들은 빠르게 원하는 상품을 찾기를 원합니다.
탐색형 사용자: 구매 목적 없이 다양한 상품을 탐색하는 사용자입니다. 이들은 새로운 상품을 발견하는 것에 더 관심이 많습니다. 현재 우리 플랫폼에서 탐색형 사용자가 많기 때문에, 그들의 흥미를 유도할 수 있는 개인화 추천 시스템이 필요합니다.

멀티 스테이지 추천 시스템

토스 쇼핑에서는 대규모 추천 문제를 해결하기 위해 멀티 스테이지 구조를 채택하고 있습니다. 이 구조는 Retrieval, Ranking, Re-ranking 세 단계로 나뉩니다.

Retrieval: 이 단계에서는 수백만 개 상품 중에서 사용자가 관심을 가질 상품을 빠르게 추출합니다. 여기서는 다양한 방법론, 예를 들어 Two-Tower 모델, Graph 기반 모델, Sequence 모델 등을 활용합니다.
Ranking: Retrieval 단계에서 추출된 상품 후보군에 대해 개인화 모델을 통해 점수를 매기고 정렬합니다. 주요 목표는 pCTR(예상 클릭률)과 pCVR(예상 전환률)을 정확하게 예측하는 것입니다.
Re-ranking: 마지막 단계에서는 초기 모델 점수와 함께 다양한 비즈니스 요구 사항을 반영하여 추천 결과를 조정합니다. 사용자의 경험 향상과 비즈니스 목표를 모두 고려하여 결과를 조정합니다.

결론

토스 쇼핑의 추천 시스템은 탐색형 사용자의 특성을 반영한 멀티 스테이지 접근법을 사용하고 있습니다. 수백만 명의 사용자와 상품을 다루는 환경에서, 각 단계별 후보군 정제는 사용자에게 매력적인 상품을 자연스럽게 발견하도록 돕고 있습니다. 현재 토스 쇼핑에서는 이 추천 시스템을 지속적으로 개선할 ML Engineer를 모집하고 있습니다. 많은 관심과 지원 부탁드립니다!

2025-04-17 12:50:06
토스테크
🛒 토스 쇼핑 추천 시스템: 수백만 사용자와 상품을 잇는 멀티 스테이지 접근법

AI야, 문서 좀 대신 써 줘 - 1. 일단 시작!

이 글에서는 카카오의 테크니컬 라이터 탈리사가 AI를 활용한 기술 문서 작성 지원 프로젝트인 "TW 에이전트"에 대해 소개하고 있습니다. AI의 도움으로 기술 문서 작성의 부담을 줄이고, 더 많은 지식을 쉽게 공유할 수 있는 방법을 모색하고 있습니다.

카카오에서 테크니컬 라이터로 활동하는 탈리사는 AI를 통한 문서 작성 지원의 필요성을 느끼고 프로젝트를 시작했습니다.
"TW 에이전트"는 사용자가 제공하는 원본 자료를 바탕으로 AI가 기술 문서를 작성 또는 편집할 수 있게 하는 도구입니다.
AI 전문가와의 협력을 통해 초기 목표와 진행 방향을 설정하고, 실무에 활용 가능한 형태로 발전시키는 것을 목표로 하고 있습니다.

개요

안녕하세요! 저는 카카오에서 테크니컬 라이터로 일하고 있는 탈리사입니다. 기술 문서를 작성하며 카카오의 개발자들이 멋진 결과물을 내도록 돕고 있습니다. 최근에는 AI 도구의 도움을 받아 문서 작성의 효율성을 높이는 방법에 대해 고민하게 되었습니다.

AI와의 협업

요즘은 ChatGPT와 같은 AI 도구들이 많이 활용되고 있습니다. 저는 이러한 AI 도구들을 업무에서 적극적으로 사용하고 있는데요, 이를 통해 문서 작성에 어려움을 느끼는 동료들을 도와줄 수 있을 것 같다는 생각을 하게 되었습니다. 카카오에는 다양한 사내 서비스와 개발 도구가 있어 이를 잘 활용하기 위해서는 기술 문서가 꼭 필요하지만, 많은 동료들이 문서 작성에 부담을 느끼고 있습니다.

따라서 AI의 힘을借리면 문서 작성이 좀 더 쉬워질 수 있을 것이라 생각했습니다. 그래서 Technical Writing(TW) 에이전트를 만들어보려고 합니다. 이 도구는 사용자가 제공한 자료를 바탕으로 AI가 기술 문서를 작성하거나 편집해주는 역할을 할 것입니다.

프로젝트 시작

하지만 막상 저와 제 동료 스텔라가 이 프로젝트에 착수하려고 하니, 여러 세부 기능을 혼자서 생각해야 해서 복잡하게 느껴졌습니다. 이에 AI 전문가인 로빈에게 조언을 요청했습니다. 로빈은 우리의 궁금증에 대해 진지하게 답변해주었고, 덕분에 현실적인 목표와 방향을 설정할 수 있었습니다.

우리는 우선 AI 모델을 기반으로 정보 분석과 문서 작성 능력을 테스트하기로 하였습니다. 태그가 없는 마크다운 문서부터 시작해 이후에는 API 연동 및 서버 개발로 발전시킬 계획입니다.

결론

이 글은 TW 에이전트 프로젝트에 대한 첫 번째 기록입니다. 이 프로젝트가 어떤 결과를 가져올지는 모르겠지만, 제가 겪는 경험들이 다른 이들에게 도움이 되길 바랍니다. 다음 편에서는 사용할 AI 모델과 첫 번째 결과물에 대해 공유하도록 하겠습니다. 많은 기대 부탁드립니다!

2025-04-17 14:44:22
tech.kakao.com
AI야, 문서 좀 대신 써 줘 - 1. 일단 시작!

로그 유형에 따른 Iceberg 테이블의 적재 및 운영 전략

본 글에서는 아파치 아이스버그(Apache Iceberg) 테이블에 DB 로그와 서버 로그를 적재하고 운영하는 최적의 전략을 공유하며, 로그 유형에 따른 파티션 및 최적화 방안에 대해 설명합니다. 특히, 각 로그의 특성을 고려하여 효과적인 데이터 처리 방안을 제안하고, 운영 중 발생할 수 있는 다양한 문제와 그 해결 방법도 다루고 있습니다.

DB 로그와 서버 로그의 차이점 및 관리 전략 정리
아이스버그 테이블의 파티션 및 최적화 전략 상세 설명
로그 수집 및 모니터링 방안 제안
데이터를 효과적으로 관리하기 위한 구현 사례 공유

개요

안녕하세요, 데이터 분석 플랫폼 조직의 루이스입니다. 이번 글에서는 아파치 아이스버그(Apache Iceberg)를 활용하여 로그 데이터를 관리하는 방법에 대해 알아보겠습니다. 특히 두 가지 로그 유형(DB 로그와 서버 로그)에 따라 파티션과 최적화 방식을 어떻게 설정하면 좋을지, 그리고 모니터링 전략에 대해서도 이야기하려 합니다.

로그 유형과 수집 방식

저희 팀은 지표를 산출하기 위해 세 가지 로그 유형을 수집합니다: 클라이언트 로그, 서버 로그, 그리고 데이터베이스 변경 로그(DB 로그)입니다. 이 중 DB 로그는 MySQL 테이블에서 아파치 플링크를 통해 아이스버그 테이블로 직접 연동되고 있으며, 서버 로그는 다양한 서버에서 발생하는 로그를 수집하고 있습니다.

DB 로그

DB 로그는 실시간 데이터 변경 사항을 반영하기 위해 UPSERT 모드로 아이스버그 테이블에 적재합니다. 파티션 전략으로는 Primary Key 기준으로 버킷 파티셔닝을 적용하여 데이터 조회 시 성능을 개선하고 있습니다. 커밋 주기는 10분으로 설정되어 있어 데이터 신선도를 유지하고 있습니다.

서버 로그

서버 로그는 서버에서 발생하는 로그로, 다양한 형식과 구조를 가집니다. 현재는 카프카를 통해 로그를 수집하고 플링크를 사용하여 아이스버그 테이블에 APPEND 모드로 적재하는 방향을 실험하고 있습니다. 이때 압축 코덱은 zstd를 사용하고 있으며, 압축 레벨을 조정하여 최적의 성능을 유지하고 있습니다.

압축, 파티션 및 최적화 전략

아이스버그를 운영할 때는 세 가지 요소—파일 포맷과 압축, 파티션, 최적화 전략—을 고려해야 합니다.

압축

DB 로그의 경우 일반적으로 zstd 압축 코덱과 기본 압축 레벨을 사용하고 있습니다. 서버 로그는 수십 배 더 많은 로그가 생성되기 때문에 압축을 통해 파일 크기를 줄이는 것이 중요합니다. 압축 레벨을 변경하면서 CPU 사용률과 지연 발생 여부를 조사했습니다. 높은 압축 레벨은 CPU 사용률을 증가시킬 수 있으므로, 적절한 압축 수준을 찾는 것이 핵심입니다.

파티션

DB 로그는 Primary Key 기준으로 버킷 파티셔닝을 적용하며, 서버 로그는 처리 시간 기반의 Identity Transform 방식을 실험하고 있습니다. 서버 로그는 시간대 문제가 발생할 수 있으므로 이를 고려한 파티션 전략이 필요합니다.

최적화 전략

아이스버그의 최적화 기능은 컴팩션, 스냅샷 만료, 고아 파일 제거 작업으로 이루어집니다. DB 로그는 주로 하루 두 번 컴팩션을 수행하며, 서버 로그는 매 시간마다 최적화 작업이 수행됩니다. 성능을 유지하고 불필요한 파일을 제거하는 것이 중요합니다.

모니터링

아이스버그 테이블의 상태와 성능을 모니터링하기 위해 주요 지표를 수집하고 시각화합니다. 참조 상태의 파일 수나 평균 크기, 파티션별 데이터 분포를 주의 깊게 확인하여 효과적인 운영 전략을 수립합니다. 이를 위해 Trino와 Spark SQL의 메타데이터 테이블을 활용하여 모니터링을 진행하고 있습니다.

결론

이번 글에서는 아이스버그 테이블을 활용한 로그 데이터 관리를 위한 다양한 전략을 살펴보았습니다. DB 로그와 서버 로그의 특성을 고려한 최적화 및 파티션 전략, 그리고 모니터링 방안을 통해 데이터 관리를 효율적으로 할 수 있습니다. 이러한 경험이 여러분께 도움이 되길 바랍니다. 감사합니다.

2025-04-18 15:16:20
tech.kakao.com
로그 유형별 Iceberg 테이블 적재 및 운영 전략

디스크 없는 카프카: 80% 더 저렴하고, 100% 개방형

이 글에서는 디스크 없는 Kafka(Diskless Kafka)가 제공하는 비용 절감과 기술적 진보에 대해 설명하고 있습니다. 새로운 KIP-1150 제안은 Kafka가 객체 저장소를 사용하여 데이터 복제를 처리함으로써 비용을 최대 80%까지 줄이고, 클라우드 환경에서의 운영 효율성을 높이는 방식에 대해 다룹니다.

Kafka의 클라우드 운영 비용이 높아지는 이유와 이에 대한 해결책 제안
KIP-1150을 통해 객체 저장소를 활용하여 복제 비용 절감 및 성능 향상
디스크 없는 Kafka의 장점: 신속한 자원 확장, 이음새 없는 다중 지역 재해 복구, IOPS 병목 현상 해소 등
오픈 소스 커뮤니티와의 협력 및 경제적 이점 강조

개요

Kafka를 클라우드에서 운영하는 것은 상당히 비쌉니다. 특히 다양한 가용 영역(AZ) 간에 데이터를 복제할 때 발생하는 비용이 큰 원인입니다. 이에 대한 해결책으로 제안된 것이 KIP-1150입니다. 이 방법은 Apache Kafka에서 복제를 객체 스토리지로 위임하는 방식으로, 데이터가 하드디스크 없이도 안전하게 저장될 수 있도록 합니다. 결국, 이는 클라우드 사용 비용을 80%까지 줄일 수 있게 하는 장점이 있습니다.

KIP-1150의 장점

KIP-1150을 통해 얻을 수 있는 주요 이점은 다음과 같습니다:

비용 절감: 하드디스크 비용과 네트워크 요금을 없애음으로써, Kafka 운영 비용을 크게 줄일 수 있습니다.
운영 용이성: Kafka 브로커의 상태를 제거해 운영 복잡성을 줄이고, 자원을 필요에 따라 신속하게 조정할 수 있습니다.
다지역 재해 복구: 객체 스토리지를 활용하여 다지역 복구 시스템을 쉽게 구축할 수 있습니다.
IOPS 병목 현상 제거: 데이터 저장을 객체 스토리지에 위임함으로써, 전통적인 하드디스크 관련 문제를 해결할 수 있습니다.

이 외에도 사용자는 여러 종류의 스토리지 클래스를 활용해 성능과 비용을 조정할 수 있는 유연성을 가지게 됩니다.

구현 방법

디스크리스 모드를 사용하여 Kafka 토픽을 생성하는 것은 매우 간단합니다. 다음의 명령어를 사용하면 됩니다:

kafka-topics.sh --create --topic my-topic --config topic.type=diskless

이 명령어 하나로 디스크리스 Kafka 사용을 시작할 수 있으며, 클라이언트 API를 변경할 필요 없이 기존의 Kafka 환경에서 손쉽게 전환할 수 있습니다.

결론

KIP-1150은 Kafka의 전통적인 장점을 유지하면서도 클라우드 환경에서의 경제성과 유연성을 제공합니다. 이는 데이터 엔지니어링 분야에서 새로운 어플리케이션의 가능성을 여는 중요한 변화입니다. 여러분은 이 변화에 대해 어떻게 생각하시나요? 더 자세한 내용은 기술 KIP 문서와 블로그 포스트를 참고하시면 좋겠습니다.

2025-04-18 23:54:41
Top posts on r/dataengineering
Diskless Kafka: 80% Cheaper, 100% Open

시니어 데이터 엔지니어들이 실제로 하루 종일 하는 일 (생각하는 것과는 다릅니다)

본 글에서는 선임 데이터 엔지니어가 실제로 어떤 일을 하는지에 대한 현실과 예상의 차이를 다루고 있습니다. 저자는 자신의 경험과 여러 선임 데이터 엔지니어들과의 인터뷰를 통해, 이 직무에 대한 일반적인 오해가 종종 새로운 엔지니어들에게 불만과 혼란을 초래한다고 지적합니다.

선임 데이터 엔지니어들의 하루 업무는 복잡한 데이터 파이프라인 설계, 고급 변환 코드 작성, 쿼리 성능 최적화 등과 같은 예상과는 다를 수 있습니다.
실제로는 다른 업무가 더 많아 많은 새 선임들이 준비되지 않은 상태로 역할에 임하게 됩니다.
이 글은 엔지니어링 분야의 현실적인 업무 이해를 돕기 위해 작성되었습니다.

개요

제가 Senior Data Engineer로 처음 승진했을 때, 더욱 복잡한 데이터 파이프라인과 어려운 기술적 문제를 다루게 될 것이라고 생각했습니다. 또한 주니어 엔지니어 몇 명을 멘토링하는 기회가 있을 것이라는 기대도 있었습니다. 하지만 6개월이 지나면서 느낀 것은 제 생각과는 совсем 달랐다는 것입니다. 실제로 제가 했던 일들은 예상을 넘어 무척 달라서, 많은 Senior Data Engineers도 저와 비슷한 경험을 하고 있다는 것을 알게 되었습니다.

기대와 현실의 차이

많은 사람들이 Senior Data Engineers가 하루 종일 다음과 같은 일을 한다고 생각합니다: - 복잡한 데이터 파이프라인 설계 - 고급 변환 코드 작성 - 쿼리 성능 최적화

하지만 실제로는 이와 같은 기대가 현실과 맞지 않는 경우가 많습니다. 이러한 인식 차이는 새로운 Senior들이 자신의 역할에 대한 요구에 대비하지 못하게 만들고, 조직 또한 기대와 인센티브의 괴리를 초래합니다.

결론

Senior Data Engineer로서의 실제 업무는 종종 예상과 다릅니다. 여러 동료들과의 대화를 통해, 이 역할이 단순히 기술적 문제를 해결하는 것 이상이라는 사실을 깨달았습니다. 앞으로 이러한 경험들을 통해 더욱 많은 사람들이 이 직무에 대한 진정한 이해를 가질 수 있기를 바랍니다.

2025-04-20 17:40:29
Data Engineer Things
What Senior Data Engineers Actually Do All Day (It’s Not What You Think)

Jobs

원티드 채용공고(최근 7일)

주요 업무(최근 7일)

필요한 기술(최근 7일)

필요한 경험(최근 7일)

필요한 소프트 스킬(최근 7일)

'데이터 엔지니어링 위클리' 카테고리의 다른 글

데이터 엔지니어링 위클리 #9 \| Vibe Coding, AI, Airbyte (1)	2025.04.29
데이터 엔지니어링 위클리 #6 \| Knowledge Graph, Data Observability, OpenTelemetry, OpenLineage (0)	2025.04.08
데이터 엔지니어링 위클리 #5 \| Shift Left, Karpenter, Data 3.0, Lakehouse (1)	2025.04.01
데이터 엔지니어링 위클리 #4 \| LLM, AI, Netflix, Airbnb (0)	2025.03.26
데이터 엔지니어링 위클리 #3 \| 스파크 최적화, 데이터 제품, Late-Arriving Data (0)	2025.03.19

데이터 엔지니어 기술 블로그

▪ dahuin000@gmail.com ▪ linkedin ▪ medium

태그

최근글

댓글

공지사항

아카이브