Data Eng Wiki

AI in Data Engineering

19 min read

AI in Data Engineering

AI/LLM이 데이터 엔지니어링 실무를 어떻게 변화시키고 있는가

개요

2025~2026년, AI는 데이터 엔지니어링의 거의 모든 영역에 영향을 미치고 있다. 코딩 생산성 향상부터, 셀프서브 분석, 자동화된 품질 보증, 에이전트 기반 워크플로우까지 광범위하다.

주요 트렌드

1. AI Agent의 프로덕션 배포

자율 에이전트가 분석 쿼리, 랭킹 모델 최적화, 데이터 탐색 등을 수행한다.

2. LLM을 활용한 품질 보증

사람 평가자를 대체하여 대규모 자동 평가가 가능해졌다.

  • LLM-as-Judge — Zalando 검색 품질, Dropbox 관련성 판정
  • LLM Evaluation — LangChain Deep Agent eval, DSPy 프롬프트 최적화

3. 셀프서브 데이터 접근과 그 한계

비기술 사용자가 자연어로 데이터를 조회한다. 그러나 a16z에 따르면 2024~25년 에이전트 광풍 이후 대부분의 배포가 컨텍스트 부재로 실패하며 “벽에 부딪힘” — 해결책은 시맨틱 레이어를 넘어선 Context Layer 구축.

4. 컨텍스트 관리의 부상

LLM의 한정된 컨텍스트 윈도우를 효율적으로 관리하는 것이 새로운 핵심 역량이다.

5. 데이터 과학자 역할의 재정의

AI가 코딩을 가속화할수록, 평가·실험 설계·데이터 모델링 등 기초 역량의 가치가 재조명된다.

6. AI 에이전트 표준화와 거버넌스

에이전트 생태계의 파편화 문제를 해결하기 위한 표준이 등장하고 있다.

  • AI Agent — Agent Format (Snap): 선언적 에이전트 정의 표준, MCP/A2A와 보완
  • Data Governance — LogSentinel: LLM 기반 PII 자동 탐지

7. AI + 데이터 엔지니어 협업 패러다임

AI가 DE를 대체하는 것이 아니라 배율기로 작용한다 (“DE + AI > DE”).

  • Claude Code로 dbt 프로젝트를 빌드한 실험에서 자율 디버깅은 성공했으나 데이터 품질 이슈는 사람이 잡아야 함
  • Spotify Wrapped: 14억 LLM 리포트 생성 — “LLM 호출은 쉬운 부분, 진짜 일은 용량 계획과 안전 시스템”

8. ETL → ECL: Context Architect의 부상

AI 에이전트가 데이터 웨어하우스의 소비자가 되면서, 인간 운영자용으로 설계된 구조(스타 스키마, 카탈로그, 메달리온)의 한계가 드러난다. 데이터 엔지니어의 역할이 파이프라인 신뢰성에서 시맨틱 신뢰성으로 이동한다.

  • Semantic Layer — ECL 프레임워크, Context Store, Context Architect

9. 멀티에이전트 암묵지 문서화

Meta가 50+ 특화 AI 에이전트를 다단계 오케스트레이션하여 데이터 파이프라인의 암묵지를 자동 문서화.

  • AI Agent — “Compass, Not Encyclopedia” 원칙, 도구 호출 40% 감소, 2일→30분 단축
  • Context Engineering — 프리컴퓨트 컨텍스트의 사람 작성 Context Anchoring과 보완적 관계

10. RAG의 진화: 그래프 기반 에이전틱 검색 + 실전 구축

Vanilla RAG의 구조 파괴·Top-K 맹점·교차 페이지 기억상실 문제를 그래프 기반 에이전틱 검색이 해결한다.

  • RAG — LAD-RAG++, Graph RAG 비용 최적화 (10~90% 절감), 로컬 RAG 1TB 실전 구축기

11. Semantic Layer vs. Text-to-SQL 벤치마크

dbt Labs의 2026 벤치마크에서 시맨틱 레이어가 Text-to-SQL 대비 거의 완벽한 정확도 달성.

  • Semantic Layer — Claude Sonnet 4.6: 90% vs. 98.2%, GPT-5.3: 84.1% vs. 100%
  • Rill Metrics SQL: SQL 기반 시맨틱 레이어로 MCP 서버를 통해 에이전트 접근

12. LLM Fine-Tuning의 실전 도입

프롬프트 엔지니어링 → SFT → RL로의 점진적 진화가 실무에서 검증되고 있다.

  • LLM Fine-Tuning — Booking.com SFT (p99 67% 감소), Netflix Post-Training (4.7x 처리량)
  • Shopify: Qwen3-32B 파인튜닝 → Python DSL 전환(+22p 구문, +13p 의미), 주간 재학습 플라이휠, 2.2x 빠름, 68% 저렴

13. AI 과의존과 이해력 퇴화

AI 코딩 도구에 과도하게 의존하면 코드베이스의 멘탈 맵이 사라지고 디버깅 능력이 퇴화한다. “AI로 사고를 가속하는 것”과 “AI로 사고를 대체하는 것”의 구분이 핵심.

  • Data Scientist Role in AI Era — 분석적 직관, 수동 검증 습관의 중요성
  • 징후: 더 많은 SEV, 더 긴 디버깅 사이클, 시니어가 주니어/AI 산출물 검증에 투입

14. 2026년 데이터 산업 예측

AI 하이프 사이클이 “패턴 결정화” 단계에 진입하면서, 99%의 기업은 아직 ERP→Excel 수준이고 도구 스프롤이 가속되는 현실.

  • 모던 데이터 스택의 전면 재구축 수요 증가
  • Databricks는 올인원 정체성 확립, Snowflake는 방향 모색 중

관련 위키

15. 에이전트 하니스의 컨텍스트 관리 수렴

Pi, OpenClaw, Claude Code, Letta 4개 에이전트 하니스가 파일 읽기 캡, 세션 프루닝, 서브에이전트 격리에서 동일한 패턴으로 수렴. 50년 컴퓨팅 메모리 관리(레지스터→캐시→페이지→스왑)와 동일한 방향.

16. Data Agent — 능동적 분석으로의 진화

대시보드 → 자연어 Q&A → 능동적 Data Agent로 진화. 연속 실행, 의사결정 인접, 명시적 가드레일의 3가지 차별점.

17. AI 에이전트의 보험 리스크

보험업계가 AI 출력물의 비결정적 특성으로 사이버보안·E&O 보험 커버리지를 축소. 거버넌스된 AI만 보험 가능.

18. 멀티도메인 지식 그래프와 에이전트

에이전트는 개별 도메인이 아닌 도메인 간 교차 지식이 필요. Karpathy LLM Wiki가 지식 그래프의 경량 변형으로 수렴.

19. Agentic Search — 검색 스택의 에이전트 대체

BM25/임베딩 도구를 에이전트가 구동하여 42% NDCG 향상(0.289→0.453). 키워드 검색의 인과관계를 이용한 쿼리 반복 개선이 핵심.

  • AI Agent — “물건 찾기”에서 에이전트 우세, “정보 찾기”에서는 전통 스택 유지

20. AI Second Brain — 지식 작업자 생산성 플랫폼

Meta 60,000명이 사용하는 Claude Code 기반 시스템. PARA 파일시스템 + Progressive Disclosure + MCP 인프라 + Markdown Skills.

  • AI Agent — 인프라 우선, 저마찰 온보딩, 컴포저빌리티 > 기능

21. 엔터프라이즈 멀티에이전트 데이터 관리

Informatica CLAIRE: 50-60 모델 콜을 조율하는 오케스트레이션 에이전트 + 전문화된 에이전트. 태스크 성공률 90%, 그라운딩 정확도 98%.

  • AI Agent — 단일 에이전트 한계를 전문화·검증 체크포인트로 극복

22. Pinterest Analytics Agent — 상세 아키텍처 공개

Unified Context-Intent Embeddings: 과거 SQL을 3단계 파이프라인(Domain Context Injection → SQL-to-Text → Embedding)으로 의미 기반 검색 가능하게 만듦. 거버넌스 메타데이터(티어, 신선도)를 랭킹에 직접 반영하여 관련성뿐 아니라 신뢰성까지 보장. 2개월 만에 분석가 40% 채택, 사내 에이전트 1위.

23. Query Proxy의 AI Agent 통합

서비스 쿼리를 중재하는 Query Proxy가 AI Agent 로그 분석으로 파생 테이블 자동 생성을 제안, 분석 워크로드 최적화.

  • Query Proxy — 에이전트의 분석 쿼리를 Proxy로 집중하여 캐싱·최적화 효과 극대화

dew_277~286 트렌드

24. 데이터 아키텍처가 곧 AI 아키텍처

Thoughtworks가 다섯 속성(Trusted / Contextual / Traceable / Governed / Operational)으로 정리한 프레임이 이번 묶음의 중심축이다. 각 속성이 인간이 무의식적으로 하던 일 중 무엇이 데이터로 밀려나는가에 대응한다.

⚠️ 스택은 의존 순서로만 쌓인다 — contract → context → access, observability는 셋을 관통. 행을 평균 내지 마라. 준비도는 가장 약한 기반 레이어가 상한을 정한다.

25. AI는 스토리지·처리·통합의 가치를 높이지 않는다

AI는 의미·계약·거버넌스의 가치를 극적으로 높인다. 여섯 패턴(Lambda/Kappa/Medallion/Mesh/Lakehouse/Semantic)은 여전히 올바른 building block이고, 바뀐 것은 그중 어느 것이 이제 무게를 지느냐다.

스키마 호환성이 시맨틱 호환성을 보장하지 않는다 — 두 도메인이 customerId가 string이라는 데 완벽히 동의하면서 customer가 무엇인지에 대해서는 완전히 불일치할 수 있다. → AI 아키텍처는 기술적 위장을 입은 거버넌스 문제

26. 희소 자원이 consensus로 이동

분석 생산 비용이 0에 가까워지면서 병목이 “만들기”에서 “합의”로 옮겨갔다. Pre-AI에는 consensus가 희소성에서 자연 발생했지만(비싸게 손수 만든 대시보드가 조직도 폴더에 중첩), 이제는 엔지니어링해야 한다.

consensus divergence rate — 같은 질문을 모든 인터페이스 × 모델 조합에 던져 서로 다른 답이 몇 개 나오는지 센다. 이사회 자료는 0이어야 한다.

모델이 틀린 적은 없다고 가정하라 — 당신의 컨텍스트가 덜 명세되었을 뿐이다.

27. 대시보드가 목적지에서 저장소로

인간은 더 이상 데이터 팀 산출물의 주 소비자가 아니다. 대시보드는 에이전트가 분해하고 재조립할 수 있는 사실·계약·설명의 저장소가 된다. 실천: 데이터 제품별 llms.txt, provenance 지침, 사람용 UI와 에이전트용 표현을 함께 설계.

SEO와의 차이: Google 알고리즘은 통제 불가 블랙박스지만, 사내 팀은 판독 가능한 산출물과 그것을 소비하는 에이전트를 동시에 소유한다.

28. 시맨틱 레이어가 C-suite 대화에 올라온 두 가지 이유

① 데이터 팀 없는 회사들이 에이전트를 벤더에 직접 꽂아 ETL·모델링을 건너뛰고 재현성 위기를 만든다 ② “intelligence exhaust” — 모든 “이거 이상한데”, 모든 지표 명료화. 컨텍스트는 당신의 네 벽 안에서 복리로 쌓이거나, 남의 벽 안에서 쌓인다.

시맨틱 레이어 없이 agentic 벤더를 raw 데이터에 직접 연결하는 것에 대한 최고의 반론: 답이 틀릴 수 있다는 것만이 아니라, 모든 수정이 당신의 스택을 고치는 대신 벤더에게 당신의 비즈니스를 가르치는 데 간다는 것.

29. 모델링과 컨텍스트의 딜레마 — “Model the core, curate the context, evaluate continuously”

모델링을 너무 적게 하면 AI가 틀린 지표·grain·조인으로 설득력 있는 답을 내고, 사전에 너무 많이 하면 새 질문마다 데이터 엔지니어링 프로젝트가 된다. 해법은 일관성이 필수인 것만 정식 모델링하고 나머지는 큐레이션된 컨텍스트로 다루는 것. 데이터 사이언스 팀은 사라지지 않고 시스템을 평가하는 human feedback loop가 된다.

30. 에이전트가 데이터를 큐레이션하기 시작

Adaptive Gold — 에이전트가 소비만 하지 않고 자기 쿼리 패턴을 관찰해 계속 손을 뻗는 조합을 materialize한다. Apple이 카탈로그의 “digital steward” 로 에이전트를 쓰는 것의 데이터셋 버전.

31. 비정형 데이터의 “의미를 위한 pre-modeling”

SQL은 숫자에 훌륭하지만 “왜 건설 버티컬에서 딜을 잃고 있지?” 에는 맞지 않는다. 1억 행 집계는 싸고 빠르지만 10만 개 콜 전사 LLM 파싱은 비싸고 느리다.

→ 전체 비정형 데이터셋에 AI tagger를 한 번, 오프라인으로 돌리고, 사람들이 묻는 질문에서 관찰한 구조로 출력을 다시 쓴다. ⚠️ 이것을 벤더에 위임하지 마라 — 벤더의 태깅 분포가 경고 없이 바뀌어 win/loss 리포팅을 재현할 수 없게 된 사례가 있다.

32. 에이전트가 모델링·마이그레이션·실험을 수행

  • Agentic ML Modeling — 성숙한 프로덕션 모델에서도 3~5% 개선, 그러나 leakage·cheating·다중 검정이라는 새 실패 모드
  • supervised agentic migration — 플레이북이 정확히 기술 가능해지면 그것은 에이전트의 일이다. 어려운 부분은 플레이북 밖의 순간을 인식하고 멈춰서 묻도록 가르치는 것
  • AI를 코드가 아니라 운영에 쓰기 — Netflix의 Spark 실험에서 “가치는 깊은 Spark 전문성이 아니라 operational memory였다.” 그리고 AI가 지루해하지 않기 때문에 writer × row-group × 정렬 순서를 수백 번 sweep하는 것이 가능해졌다

관련 위키 (추가)

관련 이슈: DEW #256, #257, #258, #261, #262, #263, #264, #265, #266, #267, #268, #269, #270, #277~#286 | SeattleDataGuy 시리즈

그래프 뷰

백링크