0. 들어가며DE to MLOps 시리즈 2일차입니다. 어제는 2026년 IT 트렌드 10선을 훑으며 큰 지도를 그렸습니다. 오늘은 그중 개발자 실무에 가장 직접적으로 꽂히는 키워드, Agentic Coding(에이전틱 코딩)을 깊게 파봅니다.지난 1~2년 사이 개발 도구에 대한 대화의 주제가 완전히 바뀌었습니다. 예전엔 "Copilot이냐 Cursor냐"를 두고 다퉜다면, 2026년 초에 오면서 각 도구가 자율성·모델 유연성·가격·아키텍처에서 서로 다른 트레이드오프를 갖는 다변화된 생태계로 성숙했습니다. 이제 질문은 "어떤 자동완성이 낫냐"가 아니라 "작업을 얼마나 맡길 수 있냐"로 옮겨갔습니다. 1. 자동완성과 에이전트는 무엇이 다른가가장 먼저 짚어야 할 개념 차이입니다. 많은 분들이 "AI 코딩 =..

0. 들어가면서최근 Glue 파이프라인을 이용하다가 애를 먹은 경험이 있어서, 같은 실수를 반복하지 않겠다는 의지와 저와 같은 경험(?)을 오래하지 않기를 바라는 마음으로 글을 써봅니다. 혹시 여러분은 AWS Glue 잡을 돌리다가 이런 에러를 만난 적 있으신가요?AccessDeniedException: Insufficient Lake Formation permission(s) on 물론 위의 에러만 보고서 "내가 권한을 안줬나?" 싶어, IAM 정책에서 확인해보면 glue:GetTable도 s3:GetObject도 다 붙어 있습니다. 콘솔에서 그 테이블이 보이기까지 합니다. 그런데도 잡은 계속 죽습니다. 저는 온프렘 HDFS/Hive 환경을 AWS로 옮기는 마이그레이션 프로젝트를 이끌면서 이 에러와 꽤..

0. 들어가며: 왜 지금 트렌드를 정리하는가안녕하세요. DE to MLOps 시리즈의 첫 글입니다. 이 시리즈는 현재까지 데이터 엔지니어로서 쌓아온 경험을 바탕으로, MLOps/ML 엔지니어로 나아가는 여정을 매일 한 편씩 기록하는 프로젝트입니다.그에 맞게 어떤 내용으로 시작을 하는게 좋을까 고민을 하다가 "2026년 IT 트렌드"라는 주제로 이야기 하고자 합니다. 이 주제를 고른 이유는 단순합니다. 어떤 방향으로 공부하고 커리어를 설계할지 정하려면, 시장이 어디로 흐르는지부터 봐야 하기 때문입니다. 기술은 빠르게 움직이고, 안내판 없이 달리다 보면 단기 처방이나 과장된 하이프에 휩쓸리기 쉽습니다.이 글에서는 Gartner, Capgemini 등 주요 리서치 기관과 데이터 엔지니어링 전문 매체의 2026..

데이터 엔지니어링 생태계에서 '실시간(Real-time)'이라는 단어는 종종 오해를 부릅니다. 배치(Batch) 처리보다 빠른 것을 실시간이라고 부르기도 하고, 단 몇 밀리초(ms)의 지연도 허용하지 않는 진짜 실시간 처리를 뜻하기도 합니다.특히 밀리초 단위의 틱(Tick) 데이터를 다뤄야 하는 정량적(Quant) 트레이딩 시스템이나 부정 결제 탐지(FDS)와 같은 환경에서는 아키텍처의 미세한 차이가 비즈니스 결과에 엄청난 영향을 미칩니다. 오늘은 대용량 데이터 스트리밍 처리의 두 축인 Apache Flink와 Spark Structured Streaming의 아키텍처 차이와 장단점을 명확히 비교해 보겠습니다.1. 근본적인 아키텍처 철학 도식화두 프레임워크의 가장 결정적인 차이는 '데이터를 어떻게 바라보..

초기 LLM 서빙은 HuggingFace의 기본 pipeline을 이용했지만, 이는 프로덕션 환경에서 트래픽이 몰릴 때 치명적인 메모리 병목 현상을 일으켰습니다. 이를 극복하고 GPU 메모리 관리와 배치(Batch) 처리를 극대화하기 위해 등장한 것이 바로 vLLM과 HuggingFace의 TGI입니다.오늘은 이 두 프레임워크가 어떤 혁신적인 기술로 메모리를 관리하는지, 그리고 어떤 상황에서 무엇을 선택해야 하는지 딥다이브 해보겠습니다.1. 메모리 병목의 원인과 핵심 기술 도식화LLM이 텍스트를 생성할 때, 이전에 생성된 Key와 Value 텐서를 메모리에 캐싱(KV Cache)하여 연산 속도를 높입니다. 하지만 기존 방식은 이 KV Cache 메모리를 비효율적으로 할당하여 낭비(Fragmentation..

수많은 데이터 파이프라인을 조율하고 스케줄링하는 오케스트레이션 툴은 데이터 엔지니어링의 심장과 같습니다. 오랜 기간 이 분야의 독보적인 표준(De-facto standard)은 Apache Airflow였습니다. 하지만 최근 데이터의 복잡도가 기하급수적으로 증가하면서, 데이터를 단순한 작업의 결과물이 아닌 '자산(Asset)'으로 취급하는 새로운 패러다임의 Dagster가 급부상하고 있습니다.오늘은 Task 지향적 접근(Task-based)과 데이터 자산 지향적 접근(Asset-based)이 아키텍처 설계와 운영에 어떤 차이를 가져오는지 심층 비교해 보겠습니다.1. 아키텍처 및 철학 비교 도식화두 도구의 근본적인 차이는 파이프라인을 바라보는 '관점'에 있습니다.[ Apache Airflow : Task-..

데이터 웨어하우스의 성능과 데이터 레이크의 유연성을 결합한 데이터 레이크하우스(Data Lakehouse) 아키텍처가 데이터 엔지니어링의 표준으로 자리 잡고 있습니다. 그리고 이 아키텍처를 완성하는 핵심 기술이 바로 '테이블 포맷(Table Format)'입니다. 오늘은 이 분야의 양대 산맥인 Apache Iceberg와 Delta Lake의 특징과 장단점을 심층적으로 비교해보겠습니다. 1. 데이터 레이크하우스 아키텍처 도식화두 테이블 포맷이 전체 데이터 파이프라인에서 어느 위치에 존재하는지 아래 도식화를 통해 확인할 수 있습니다.[ Data Sources ] │ (Ingestion: Kafka / Spark / Flink) ▼[ Cloud Storage (AWS S3, Google ..

지난 1일차 리뷰에 이어, 21일에 진행됬던 2일차 리뷰도 간략하게 정리해보았습니다. 1일차에서는 주로 에이전틱 AI의 시대가 도래했고, 이를 위한 각 회사별 SMUS(SageMaker Unified Studio)를 어떤 식으로 활용했는가에 중점을 두었다면, 2일차에서는 어떻게하면 AI 에이전트를 완성할 수 있는지, 그리고 그 과정에서 데이터 거버넌스가 왜 중요한지 등을 설명해주는 세션에 관심이 갔습니다. 과연 어떤 내용들이었는지 한 번 살펴보도록 하겠습니다. 1. 에이전틱 AI를 위한 데이터 실무 가이드첫 번째 주제는 바로 "에이전틱 AI를 위한 데이터 실무 가이드" 라는 주제였습니다. 단순히 듣기에는 에이전틱 AI를 다루려면 데이터를 어떻게 설계하고 처리해야하는 가라는 주제를 다룰 것처럼 생각했지만..