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

AI 시대, 데이터 엔지니어의 역할은 어떻게 달라질까요?
얼마 전 읽은 The Only AI Data Engineering Roadmap You Need In 2025라는 글에서 인상 깊었던 부분들을 정리해 공유합니다.
글 전체가 아닌, 개인적으로 중요하다고 생각되는 부분만 옮겼습니다.
원문이 궁금하신 분들은 링크를 참고해주세요.

 

데이터 엔지니어를 위한 필수 디자인 패턴

2025년 데이터 엔지니어의 역할은 단순히 데이터를 A에서 B로 옮기는 일에서 그치지 않는다. 진짜 가치는 데이터를 어떻게 구조화하고, 이를 바탕으로 분석과 ML에서 활용 가능한 형태로 가공하는지에 달려 있다.

 

dbt, Spark, Airflow, Apache Flink 같은 도구를 다루는 것도 중요하지만, 적절한 데이터 설계 패턴을 이해하고, 적용하는 능력이 큰 차이를 만든다. 이번 글에서는 모든 데이터 엔지니어가 반드시 알아야 할 6가지 핵심 디자인 패턴을 소개한다.

 

1. Kimball의 차원 모델링(Dimensional Modeling)

데이터 엔지니어라면 "비정규화는 피해라."라는 말을 듣지만, 분석 환경에서는 전략적인 비정규화가 오히려 도움이 된다. Kimball의 차원 모델링은 Fact Table과 Dimension Table로 데이터를 구성하여, BI 분석에 최적화된 구조를 만든다.

 

왜 써야하는가?

• 스타 스키마(star schema)로 쿼리 성능 향상
• 데이터 사용자들이 직관적으로 이해할 수 있는 데이터 구조 제공
• 지표 정의의 일관성 확보

언제 써야할까?

• BI 리포팅 시스템
• 대시보드 구축
• Ad-hoc 분석

Best Practice

• Fact Table의 단위(grain level)를 반드시 기록해두자. 
  (예: "이 Fact Table은 주문별/일별 하나의 행을 구성된다.")
• 원시 이벤트 로그를 무작정 Fact Table에 쌓지 말 것. 조회 성능이 떨어지거나, 사용자들이 데이터 정의를 헷갈릴 수 있다.

2. Slowly Changing Dimensions (SCD 타입 2)

고객의 주소나 상품 카테고리처럼 변경될 수 있는 속성은 어떻게 레코드로 관리해야 할까? 단순히 기존 레코드를 덮어쓰면 과거 이력이 사라진다. 이를 해결하기 위해 SCD 타입 2 패턴을 사용한다. SCD 타입 2 패턴의 핵심은 변경이 발생할 때마다 새로운 dimension 레코드를 추가하는 것이다. 

• 새로운 surrogate key 추가
• 유효 시작/종료 타임스탬프
• 현재 여부를 나타내는 is_current_flag 관리

이렇게 하면 과거 데이터가 보존된다. 예를 들어, 어떤 사용자가 구매를 했을 때, 뉴욕에 살았다면, 나중에 캘리포니아로 이사해도 분석에서는 여전히 그 시점의 구매가 뉴욕 기준으로 기록된다.

 

실제 사례

은행은 KYC(Know Your Customer) 규제 준수를 위해 SCD2를 사용한다. 각 거래 시점에 시스템이 고객 정보를 어떻게 알고 있었는지를 남겨야, 감사(audit)에서 증명할 수 있기 때문이다.

 

Best Practice

모든 로직을 직접 구현하기보다 dbt의 surrogate_key() 매크로나 Spark의 merge, Iceberg의 Time Travel 기능 같이 검증된 도구를 사용하는 것이 안정적이다.

3. OLTP 정규화

분석(Analytics) 환경에서는 비정규화가 유리한 경우가 많지만, OLTP(Online Transaction Processing) 시스템에서는 여전히 3차 정규화(3NF)가 표준이다. 데이터는 중복을 최소화하고, 외래 키로 연결된 여러 테이블에 나눠 저장된다.

 

왜 정규화가 중요할까?

• 데이터 수정 시 불일치 최소화
• 트랜잭션의 ACID 보장
• 불필요한 쓰기와 불일치 방지

대부분 서비스의 운영 DB(예: 결제, 재고 관리 등)는 3NF 기반이다.

 

실무 인사이트

Debezium이나 Airbyte 같은 CDC(Change Data Capture) 도구를 사용할 때, 정규화된 로그 기반으로 비정규화된 이벤트를 재구성할 수 있어야 한다. 이를 위해 관계형 데이터베이스 이론에 대한 기본기가 필요하다.

 

4. Apache Flink와 Kappa 아키텍쳐

예전에는 Lambda 아키텍쳐처럼 Batch Layer와 Speed Layer를 따로 운영했지만, 최근에는 Kappa 아키텍쳐가 대세다.

 

핵심 아이디어

• 모든 데이터는 실시간 스트림으로 처리
• 과거 데이터를 재처리할 때도 동일한 Flink Job에 replay
• 하나의 코드베이스로 실시간/백필(backfill) 모두 처리 -> 아키텍쳐 단순화

 

언제 쓰면 좋을까?

• 실시간 이상 거래 탐지
• 클릭스트림 분석
• 금융 시세 데이터 처리

실무 팁

처리 시간이 아닌, 이벤트 타임 윈도우를 사용해야 지연 환경에서도 정확도가 보장된다. 데이터가 늦게 도착하는 경우에 대비해, watermarking 로직을 적용해야 한다.

 

5. ML Feature Store 아키텍쳐

예전처럼 Feature를 추출해서 CSV로 전달하는 방식은 더이상 통하지 않는다. 프로덕션 ML 시스템에서는 아래와 같은 조건이 필수다.

• Offline Store: 배치로 계산된 Feature 저장소 (Parquet, Spark, Hive, Iceberg 등)
• Online Store: 실시간 조회 최적화 (Redis, Cassandra, DynamoDB 등)
• Registry: 메타 데이터 저장소 (Feature 소유자, 타입, 라인리지 포함)

Feast, Tecton, Databricks Feature Store 같은 툴들이 이 패턴을 추상화해주지만, 구조를 이해해야 디버깅과 확장이 가능하다.

 

주의할 점

일회성으로 사용되는 모델 input을 Feature Store에 넣지 말고, 여러 모델들이 재사용할 수 있는 범용 Feature 위주로 관리해야 ROI가 높아진다.

 

6. One Big Table(OBT) 모델링

데이터 엔지니어라면 "데이터를 하나의 테이블에 몰아넣지 마라."는 조언을 들어봤을 것이다. 하지만, 분석 중심 환경에서는 반대로 하나의 큰 테이블(OBT: One Big Table)로 만드는 것이 더 효율적일 때도 있다.

 

왜 써야하는가?

• 여러 테이블 간 join 최소화
• 대시보드 응답 속도 향상
• Columnar Storage(예: BigQuery, DuckDB)와 궁합이 좋음

언제 써야할까?

• dimension이 많은 하나의 business entity
• 읽기 비중이 크고, 쓰기는 드문 상황
• 사전 집계가 필요한 분석

프롬프트의 힘: AI + Context = 데이터 엔지니어링 슈퍼파워

AI 시대의 가장 큰 변화는, 더이상 모든 SQL, YAML, Python 코드를 일일이 작성하지 않아도 된다는 점이다. 대신 프롬프트를 통해 의도를 정확히 전달하고, AI를 지휘하는 능력이 중요해졌다.

 

프롬프트 프레임워크

효과적이고, 재사용 가능하고, 쓸 만한 프롬프트를 작성하기 위해서 아래와 같이 해보자.

 

1. Inputs

비즈니스 컨텍스트나 스키마를 명확히 전달하는 것으로 시작한다.

"customer_id, order_id, order_date, status 필드를 가진 customer_orders 테이블이 있어."

 

2. Tech

사용하려는 스택 이름을 적는다. Trino인지 BigQuery인지 Airflow인지 Dagster인지에 따라서 모델이 패턴을 바꿔준다.

"Airflow랑 Trino on Iceberg를 사용하고, 유효성 검증은 Great Expectations으로 할 거야."

 

3. 디자인 패턴

구체적으로 어떤 패턴을 적용해서 구현해야 할지 적는다. 깊이 없는 프롬프트와 실제 엔지니어링 수준을 가르는 기준이 된다. 디자인 패턴은 프롬프트 구조를 부여해준다. 코드를 만들라고 하는 게 아니라, methodical solution을 제공한다.

"SCD 타입 2 로직을 써서 변경 사항을 모델링해라."
"Write-Audit-Publish 패턴을 적용해라."

 

4. Best Practices

마지막으로, 가드레일을 추가해라. LLM은 이런 걸 요청하기 전까지는 해주지는 않는다.

"idempotency 체크를 추가해라"
"지수적으로 DAG retry를 구현해라."
"Great Expectations로 테스트를 추가해라."

프롬프트 활용 예시

1. Trino

Join을 여러 번 하는 쿼리를 직접 작성하는 대신에 이렇게 프롬프트를 작성하자. Trino는 스키마를 인지하고 있기 때문에 적절하게 프롬프트만 작성하면, 의도(intent)를 이해하는 SQL 컴파일러가 될 수 있다.

"일자별 주문 데이터와 고객 dimension을 합치고, Iceberg의 머지 기능을 이용해서 SCD2를 적용하는 Trino 쿼리를 작성해줘."

2. Airflow

AI는 이제 DAG을 스캐폴드할 수 있지만, 디테일이 중요하다. 프롬프트는 production 데이터 엔지니어처럼 생각해야 한다.

"task 수준에서 retries, timeouts, SCD 로직을 구현한 Airflow DAG을 만들어줘. row count consistency를 검증하는 task를 포함시켜줘."

3. Great Expectations

YAML을 만드는 데, 30분을 보내는 대신에 이렇게 요청하자. 구조와 의도를 분명하게 전달하면, 프롬프트가 잘 먹힌다.

"null 체크, order_id의 중복 점검, status의 regex match를 수행하는 Great Expectations 테스트를 만들어줘."

4. Write-Audit-Publish(WAP) 패턴

"주문 테이블을 WAP 패턴으로 구현해줘. staging layer를 사용하고, 체크포인트를 audit하고, Iceberg snapshot 커밋으로 publish해줘."

 

SQL나 Python처럼 프롬프트 엔지니어링도 데이터 엔지니어들에게 필수 역량이 되고 있다. 프롬프트를 잘 짠다고 해서, 핵심 개념을 몰라도 된다는 의미는 아니다. AI가 무엇을 만들어주는지를 이해하고 시스템을 가이드해야 하기 때문에 사실상 더 많은 것을 알고 있어야 한다.