0. 들어가면서몇 주 전 Iceberg 테이블에 MERGE를 하다 동시 쓰기 충돌을 만났습니다. "Found conflicting files that can contain records matching true". 검색하면 자료가 나오는 에러였고, 파티션 스펙에 구분 컬럼을 추가하고 MERGE 조건에 상수 술어를 넣어 충돌 감지 범위를 좁혔습니다. 조치는 유효했고, 3주 동안 같은 에러가 한 번도 나오지 않았습니다. 그러다가 아래의 에러 메세지를 마주하게 됩니다.Runtime file filtering is not possible: the table has been concurrently modified.Row-level operation scan snapshot ID: 431882613635636801..

0. 들어가며DE to MLOps 시리즈 4일차입니다. 어제 3일차 실습에서는 CLI 에이전트에게 "무엇을 만들지"만 지시하고 "어떻게 만들지"는 비운 채 파이프라인을 맡겨보았습니다. 그리고 그게 놀랍도록 잘 굴러갔습니다.오늘은 그 경험의 정체를 짚어보려 합니다. 바로 AI-Native Development(AI 네이티브 개발), 더 정확히는 그 핵심 메커니즘인 의도 기반 개발(Intent-Driven Development)입니다. 2026년 소프트웨어 엔지니어링의 판을 바꾸고 있는 이 패러다임이 무엇인지, 그리고 왜 데이터 엔지니어에게도 중요한지 정리해보겠습니다. 1. AI-Native란 "AI를 붙인 것"이 아니다가장 먼저 오해부터 걷어내야 합니다. 많은 분들이 "AI-Native = 제품에 AI 기..

0. 들어가며DE to MLOps 시리즈 3일차입니다. 오늘은 지난 2일차에서 에이전틱 코딩의 이론(제안에서 위임으로, plan-build-test-ship 루프)을 다뤘던 것을 예제로 만들어보았고, 이를 실습해보는 내용으로 채울 예정입니다. 실습에 앞서 먼저 환경 구성을 해봐야 할 텐데, 예제의 실행환경 및 사용 프로그램들은 다음과 같습니다.[실습환경]- Apple Silicon Mac(M2 Max)- Claude Code- Docker Desktop이번 예제는 도커를 이용해 Spark 클러스터를 구성하고, 로그 집계 데이터 파이프라인을 생성하는 것이 목표입니다. 단, 모든 환경 세팅부터 코드·테스트까지 전부 CLI 에이전트에게 위임하는 것이 포인트입니다. 미리 공부해서 준비하지 않고, 막히면 어떤 부..

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..