모든 경쟁사 블로그들이 'AI가 데이터 엔지니어링을 바꾸고 있다'는 글을 게시하고 있습니다. 모두가 숨 가쁘게 몰아치듯 모호한 이야기만 늘어놓고 있죠. 여기 솔직한 목록을 정리했습니다. LLM (Large Language Model) 도구가 진정으로 도움이 되는 부분은 무엇인지, 여전히 손대지 못하는 부분은 무엇인지, 그리고 왜 '80% 자동화'라는 주장이 실제 운영 환경(production)에서는 통하지 않는지에 대해 말입니다.

내가 이 글을 쓰는 이유

현재 AI가 워낙 열풍이다 보니, 일부 CTO들은 스스로에게 이렇게 묻곤 합니다: "AI가 우리 데이터 엔지니어링 팀의 절반을 대체해야 할까?"

이것이 현재 데이터 엔지니어링 분야 내 AI의 현주소입니다. 모두가 숨 가쁘게 몰아치는 콘텐츠를 발행하고 있지만, 아무도 구체적이지 않습니다. 그래서 이 주제에 대한 제 견해를 밝힙니다:

AI가 진정으로 도움이 되는 부분

SQL 생성은 가장 명확한 승리입니다. Copilot 스타일의 도구들은 SQL 기초가 탄탄한 엔지니어들에게 첫 번째 초안 분석 쿼리(analytical query)를 작성하는 시간을 50-70% 단축해 줍니다. 여전히 검토는 필요합니다. 정답이 어떤 모습이어야 하는지도 여전히 알고 있어야 합니다. 하지만 '백지 상태의 문제(blank-page problem)'는 사라졌습니다.

스키마(Schema) 문서화는 극적으로 빨라졌습니다. "400개의 테이블이 있다"에서 "400개의 테이블에 대한 문서가 있다"로 넘어가는 과정은 과거에 분석가들의 시간을 몇 달씩 잡아먹곤 했습니다. 훌륭한 LLM 도구를 사용하면 팀은 이를 몇 주 만에 끝낼 수 있습니다. 문서가 완벽하지는 않지만, 이전에는 불가능했던 유용함을 제공할 만큼 충분히 좋습니다.

비엔지니어(non-engineers)를 위한 애드혹 분석(Ad-hoc analysis)은 의미 있게 변화했습니다. 과거에는 "~하는 쿼리를 작성해 줄 수 있나요?"라며 티켓을 발행해야 했던 비즈니스 분석가들이 이제는 간단한 질문에 대해 스스로 작동하는 답변을 얻을 수 있습니다. 이것은 실질적인 생산성 향상입니다. 또한 데이터 엔지니어링 팀의 업무 흐름을 방해하는 작업(interrupt-driven work)을 의미 있게 줄여줍니다.

코드 리뷰 초안 작성입니다. 리뷰를 대체하는 것이 아니라, 사람이 확인하기 전에 인덱스가 없는 조인(unindexed joins), 누락된 null 체크, 타입 불일치(type mismatches)와 같은 명백한 문제들을 잡아냄으로써 전체적인 시간을 절약해 줍니다.

이것들은 실제적이며 중요합니다. 저는 이것들을 무시하고 싶지 않습니다.

AI가 안정적으로 처리할 수 없는 부분

여기가 바로 벤더(vendor)들의 주장과 실제 운영 환경(production)의 현실 사이의 간극이 벌어지는 지점입니다.

대규모 스키마 진화 (Schema evolution at scale)

프로덕션 (production) 파이프라인을 유지 관리하는 가장 어려운 부분은 코드를 작성하는 것이 아닙니다. 상위 시스템 (upstream system)이 필드 유형을 변경하거나, 컬럼을 지원 중단 (deprecate)하거나, 다른 형식으로 데이터를 보내기 시작할 때 무엇을 해야 할지 아는 것입니다. 이를 위해서는 데이터 뒤에 숨겨진 비즈니스 로직, 하위 소비자 (downstream consumers), 그리고 해당 필드가 존재하는 역사적 맥락을 이해해야 합니다. 그러한 결정이 내려질 당시 그 자리에 없었던 LLM은 적절한 대응에 대해 신뢰할 수 있는 추론을 할 수 없습니다. LLM은 그럴싸해 보이는 결과물을 내놓겠지만, 그것이 실제로는 틀린 경우가 많습니다.

상태 저장 스트림 처리 (Stateful stream processing)

한 팀이 실시간 이상 거래 탐지 (fraud detection) 파이프라인을 위해 지연 도착 처리 (late-arrival handling)가 포함된 윈도우 집계 (windowed aggregation)를 LLM이 올바르게 구현하도록 만드는 데 3개월을 소비할 수도 있습니다. LLM은 코드를 작성할 수 있고, 그 코드도 실행됩니다. 하지만 특정 정렬 조건이나 이례적인 이벤트 볼륨이 발생하는 날처럼, 오직 프로덕션 환경에서만 나타나는 엣지 케이스 (edge cases)에서 잘못된 답을 내놓습니다. 이러한 버그는 매우 까다로운 종류입니다. 에러를 발생시키지 않고, 그저 조용히 지표 (metrics)를 오염시키기 때문입니다. 모델은 자신이 직면하게 될 실제 엣지 케이스에 대해 자신의 출력을 스스로 테스트할 방법이 없습니다.

프로덕션 장애 복구 (Production failure recovery)

Kafka 컨슈머 (consumer)가 48시간 뒤처져서 데이터를 다시 재생 (replay)할지, 버릴지, 아니면 중복 제거 (deduplicate)할지를 결정해야 할 때, 그것은 코드 생성의 문제가 아닙니다. 그것은 비즈니스, SLA (Service Level Agreement), 그리고 각 옵션의 비용을 알아야 하는 판단의 문제입니다. 저는 상당한 수준의 인간의 지원 (human scaffolding) 없이는 LLM이 그러한 결정을 올바르게 내리는 것을 아직 본 적이 없습니다.

한 사이버 보안 회사의 리드 엔지니어는 저에게 이렇게 말했습니다. "우리는 표준 ETL 패턴에 대해 약 70%의 자동화를 달성했습니다. 나머지 30%는 실제로 프로덕션에서 문제를 일으키는 것들입니다." 그는 불평하는 것이 아니었습니다. 왜 그런지 이해하고 있었기 때문입니다. 하지만 바로 그 30%가 데이터 엔지니어를 계속 고용되게 만드는 요소입니다.

"80% 자동화" 문제

Gartner는 작년에 2027년까지 데이터 엔지니어링 업무의 80%가 영향을 받을 것이라는 예측을 발표했습니다. 저는 그들이 왜 그런 글을 썼는지 이해합니다.

여기서 80%에 관한 핵심은 이렇습니다. 그들이 말하는 80%는 스캐폴딩 (scaffolding, 구조물 구축), 상용구 코드 (Boilerplate), 초안 작성 등을 의미합니다. 예를 들어, 진정으로 80% 자동화가 가능한 부분은 이미 상대적으로 속도가 빨랐던 부분들입니다.

남는 것은 시간의 80%를 차지하는 나머지 20%입니다. 데이터가 왜 잘못되어 보이는지 디버깅 (debugging)하고, 상위 팀 (upstream teams)과 스키마 (schema) 변경을 협상하며, 아무도 예상하지 못한 상황에서 파이프라인 (pipeline) 신뢰성에 대해 추론하는 일들 말입니다. 이 20%는 또한 잘못된 답변이 나왔을 때 그 비용이 매우 큰 20%이기도 합니다.

비관적으로 말하려는 것이 아닙니다. 80%는 중요합니다. 엔지니어링 팀을 스캐폴딩 작업에서 해방시키는 것은 진정으로 가치 있는 일입니다. 하지만 이러한 자동화가 곧 엔지니어의 수가 줄어듦을 의미하는 세상에 대비하는 팀들은, 비용이 많이 드는 문제들 또한 쉬워질 것이라는 특정 가설에 베팅을 하고 있는 것입니다. 그럴 수도 있겠지만, 저는 아직 그에 대한 증거를 보지 못했습니다.

인력 감축을 고려하는 팀들에게 제가 하는 말

아직은 하지 마십시오. 기술이 실재하지 않아서가 아니라, 여러분이 잘못된 변수에 베팅하고 있기 때문입니다.

AI 도구로부터 가장 많은 이득을 얻고 있는 팀들은 인력을 감축하는 팀이 아닙니다. 동일한 인력을 유지하면서 그들을 더 어려운 문제에 투입하는 팀들입니다. 과거에 일과를 일상적인 ETL 작업에 소비하던 엔지니어들은 이제 데이터 품질 프레임워크 (data quality frameworks), 스키마 거버넌스 (schema governance), 실시간 파이프라인 신뢰성 (real-time pipeline reliability) 작업에 매진하고 있습니다. 엔지니어 1인당 산출량은 더 높아졌습니다. 산출물의 품질도 더 높아졌습니다. 팀은 대체하기 쉬워진 것이 아니라, 오히려 더 대체하기 어려워졌습니다.

이것이 실상입니다. AI는 데이터 엔지니어를 대체하는 존재가 아니라, 데이터 엔지니어를 위한 생산성 승수 (productivity multiplier)입니다.

간단한 개요

비교 표 형식을 피하겠다고 말씀드렸던 것은 알고 있습니다. 하지만 이번 표는 이를 보여주는 데 있어 진정으로 가장 명확한 방법입니다:

작업 (Task)	AI가 도움을 주는 부분	AI가 어려워하는 부분
SQL 생성 (SQL generation)	초안 작성, 50-70% 더 빠르게	미묘한 비즈니스 규칙이 포함된 복잡한 로직
...

왼쪽 열은 현실입니다. 오른쪽 열은 데이터 엔지니어링 팀이 여전히 존재하는 이유입니다.

layline.io가 위치한 곳

솔직하게 말씀드리겠습니다. 위에서 설명한 AI 생산성 이득은 파이프라인이 LLM (Large Language Model)이 이해하고 확장할 수 있는 명시적인 구조를 가지고 있을 때 더 쉽게 확보할 수 있습니다.

layline.io에서는 선언적 설정 (declarative configuration)을 통해 파이프라인을 구축합니다. 즉, 로직이 커스텀 코드에 내장되는 것이 아니라 구조화된 연산자 (operators) 안에 들어 있습니다 (정말 필요한 경우에만 간혹 사용되는 Javascript나 Python은 제외하고 말이죠). 이것은 AI 보조 개발 (AI-assisted development)과 잘 어우러지는 것으로 나타났습니다. 엔지니어가 LLM에게 처리 단계 추가를 요청하면, LLM은 이를 명확하게 추론할 수 있습니다. 무언가 고장 났을 때, 실패 지점은 맞춤형 코드 속에 파묻혀 있는 대신 이미 알려진 위치에 있게 됩니다.

우리가 처음부터 그렇게 만든 이유는 이것 때문이 아닙니다. 선언적 파이프라인이 인간이 디버깅하고 유지보수하기 더 쉽기 때문에 그렇게 만들었습니다. AI와의 친화성은 부수적인 효과로 나타난 것입니다.

하지만 이는 구조화된 기반 위에서 구축하는 팀이 커스텀 코드로 작업하는 팀보다 AI 도구로부터 더 많은 이득을 얻는다는 것을 의미합니다. 이는 2년 뒤에도 중요하게 작용할 아키텍처 선택을 할 때 고려해 볼 만한 가치가 있는 부분입니다.

팀에 던져볼 만한 질문

이렇게 해보세요. 최근 발생한 다섯 가지 데이터 장애 (data incidents)를 골라보세요. 각 사례에 대해, AI가 이를 방지하거나 더 빠르게 진단할 수 있었을지 질문해 보십시오.

대부분의 팀에게 그 답변은 "5개 중 1개 정도일 것입니다." 나머지 4개는 LLM (Large Language Model)이 신뢰성 있게 추론할 수 없는 문제들입니다. 즉, 기술적으로는 올바른 코드이지만 비즈니스 로직 (business logic)이 틀린 경우, 아무도 공지하지 않은 상위 팀 (upstream team)의 스키마 변경 (schema change), 또는 특정 이벤트 볼륨 (event volumes)에서만 나타나는 스트림 처리 (stream processing)의 엣지 케이스 (edge case) 등이 이에 해당합니다.

만약 AI 도구 (AI tooling)를 평가하고 있다면, 그것이 당신의 기준점 (baseline)이 되어야 합니다. "AI가 데이터 엔지니어링을 변화시킬 것인가"가 아니라 — 물론 변화시킬 것입니다. 하지만 "AI가 실제로 우리를 괴롭히는 문제들을 제거할 것인가?"라는 질문에 대한 답은 '아니오'입니다. 아직은 아니며, 아마도 아직 변하지 않은 무언가가 변하지 않는 한 계속 그럴 것입니다.