[번역] AI 시대에 데이터 엔지니어가 살아남는 법 (3 / 3)

AI 시대, 데이터 엔지니어의 역할은 어떻게 달라질까요?
얼마 전 읽은 글에서 인상 깊었던 부분들을 정리해 공유합니다. 파트 1과 2는 이전 포스트에서 보실 수 있습니다.
글 전체가 아닌, 개인적으로 중요하다고 생각되는 부분만 옮겼습니다.
원문이 궁금하신 분들은 링크를 참고해주세요.

 

AI로 인해 데이터 엔지니어의 역할도 빠르게 바뀌고 있다. 몇 줄의 프롬프트만으로도 파이프라인을 만들고, SQL을 작성하고, Airflow DAG을 생성할 수 있다. 하지만 AI가 바꿀 수 없는 진실도 있다.

• 잘못된 설계는 결국 프로덕션 환경에서 문제를 일으킨다.
• 좋은 엔지니어링 Practice는 여전히 유효하다.

제대로 구조를 잡지 않고 빠르게 개발하기만 하는 건, 발전이 아니다. 데이터 파이프라인이 점점 복잡해지고 자동화가 고도화될수록, 명확하고 일관된 Best Practice를 지키는 엔지니어가 더 돋보일 수밖에 없다.

 

적절한 파티셔닝, 압축, PII 관리

1. 파티셔닝(Partitioning)

파티셔닝은 얼마나 빠르게(혹은 느리게) 데이터를 읽을지를 결정한다. Iceberg, Delta Lake, Hive 테이블은 모두 파티션 프루닝에 크게 의존한다. user_id 같이 카디널리티가 높은 컬럼으로 잘못 파티셔닝하면, 작은 파일 수백만 개가 생겨서 성능이 떨어진다. 쿼리가 느릴 때는 Spark 설정을 건드리기보다 파티션 전략을 먼저 살펴보자.

 

2. 압축(Compression)

일반적으로 Parquet + Snappy가 기본이지만, 압축률을 더 높이고 싶을 때는 ZSTD를, 장기 보관용(archive)일 때는 GZIP을 검토해보자. 또, 이미 압축된 데이터(예: base64 인코딩된 이미지, 압축 로그)는 다시 압축하지 말자.

 

3. 개인정보(PII) 관리

개인정보는 변환 계층에서 마스킹, 해싱, 분리를 기본으로 해야한다. Apache Ranger, Immuta 같은 데이터 거버넌스 툴을 활용해볼 수 있다. 예를 들어, 개인정보가 포함된 부분과 그렇지 않은 부분을 분리해서 꼭 필요할 때만 조인(join)해서 사용하는 것도 방법이 된다.

 

데이터 보존 전략: 비용 vs 규제 vs 분석

1. Cold vs Hot Data

계층을 나눠서 데이터를 저장하는 전략이 도움이 된다. 예를 들어, 최근 6개월 데이터는 빠른 분석을 위해 Delta / Iceberg에 저장하고, 그 이후 데이터는 S3 Glacier / BigLake 등 저비용 스토리지로 아카이빙하는 방식이다.

2. 규제 준수

GDPR이나 HIPAA과 같은 규제를 고려해 데이터 삭제/보관 주기 관리를 자동화해야 한다.

3. 분석 친화적인 정책

원본 데이터는 일정 기간 후 삭제하는 대신, 월간/주간 집계 테이블은 장기 보관하면 비용은 줄이는 대신, 의사결정을 지원하는 데는 도움을 줄 수 있다.

 

DAG Best Practices: 신뢰성과 멱등성

DAG을 작성할 때는 이런 원칙을 꼭 지켜야 한다.

• Idempotency: 재실행 시 중복이 없게 하기 (MERGE, UPSERT, partition overwrite 사용)
• Retry-Safe: 재시도 시 불필요하게 외부 API를 다시 호출하지 않도록 설계하기
• Auditable: Row count, hash check, lineage 로그를 남겨 이상 탐지가 가능하게 만들기

 

대시보드 최적화: 미리 집계해둔 데이터 서빙하기

대시보드에 Snowflake나 Druid에 있는 원천 테이블을 직접 연결하면 비효율적인 경우가 많다. 대신, 이런 방법을 검토해보자.

• Materialized View, Roll-up Table, OLAP Cube를 활용해 사전 집계된 데이터 서빙
  (예: 일간 고객 이탈률, 주간 매출, 월간 활성 사용자수)
• 이렇게 하면, 대시보드 로딩 속도가 빨라지고, 쿼리 비용이 절감되고, 리포트 간 일관성이 높아질 수 있다.

 

파이프라인이 아닌, 시스템을 만드는 엔지니어

AI가 단순 코드 작성과 반복 작업을 대신해주는 시대다. 단순히 DAG을 만들줄 아는지보다, 1년 뒤에도 문제 없이 돌아갈 수 있는 시스템을 만들 수 있는지가 중요하다. 좋은 시스템을 설계하려면 다음을 고려해야 한다.

• 스키마 변경에도 안정적으로 동작하는 구조
• 데이터 품질 관리: 결측, 이상값 처리, 데이터 검증 내재화
• 일관성 있는 데이터 서빙: 분석, ML, 모니터링을 하나의 신뢰 가능한 데이터 소스로 제공
• 팀 차원의 협업: 코드 리뷰, 컨벤션 공유, 페어 디버깅

좋은 엔지니어는 파이프라인을 만들지만, 훌륭한 엔지니어는 신뢰할 수 있는 시스템을 만든다.

 

더 중요해지는 협업

AI가 발전하면 협업이 줄어들 거라 생각하기 쉽지만, 오히려 협업이 더 중요해진다. AI가 생성한 코드는 팀의 컨벤션을 모르는 경우가 많다. 또, 같은 프롬프트를 사용해도 결과물이 완전히 달라질 수 있다. 사일로(silo) 상태에서 각자 AI를 써서 개발하면, 오히려 리스크가 커지기 때문에 맥락을 공유하는 것이 더 중요해진다.

 

예를 들어, LLM이 만들어낸 Airflow DAG은 겉보기에 멀쩡할 수 있지만, 실제 운영에서는 재시도를 건너뛰거나 null을 잘못 처리하는 경우가 생길 수 있다. 이런 문제는 팀원의 코드 릴뷰나 페어 디버깅을 통해 더 빨리 발견할 수 있다. 협업은 AI 시대의 안전장치라고 생각하면 된다. 코드 리뷰, 아키텍쳐 논의, 지식 공유가 필수적이다.

 

더 중요해지는 관측가능성, 테스팅, 라인리지

AI가 boilerplate 코드를 대신 작성해주는 만큼, 이제 엔지니어의 가치는 코드를 쓰는 속도가 아니라, 문제를 어떻게 빨리 감지하고 해결하는지에 달려 있다. 

• Observability: Monte Carlo와 OpenLineage, Databand를 사용해서 freshness와 schema drift, failure rates를 기록
• Testing: CI/CD 파이프라인에서 Great Expectations나 Deequ를 실행 -> row count를 검증하고, join, null, category 일관성검증
• Lineage Tracking: 소스부터 대시보드까지 lineage graph 시각화 -> 문제 발생 시 원인 분석에 활용

 

커리어 인사이트: 데이터 엔지니어 역할은 사라지지 않는다. 다만, 바뀔 뿐.

AI가 반복 작업을 대신하면서, 엔지니어에게 요구되는 기준은 오히려 더 높아지고 있다. 앞으로는 이런 역량이 차별화 포인트가 된다.

• 견고한 시스템 설계: 명확한 계약(contract)과 SLA로 보장되는 시스템
• 데이터 품질: 신뢰할 수 있는 데이터 제공
• 지식 공유와 팀워크: 컨벤션 수립, 코드 리뷰, 멘토링을 통한 협업 강화
• 비즈니스 컨텍스트 이해: 단순 테이블 생성이 아닌, 비즈니스 가치를 담은 데이터 모델링