인공지능이 데이터 엔지니어를 대체할까요?

간단히 말해서, AI가 데이터 엔지니어를 완전히 대체하지는 않을 것입니다. AI는 SQL 작성, 파이프라인 구축, 테스트 및 문서화와 같은 반복적인 작업을 자동화할 것입니다. 만약 당신의 역할이 주로 책임 범위가 좁고 티켓 기반의 업무라면 AI의 영향이 더 클 수 있습니다. 하지만 데이터의 안정성, 정의, 거버넌스 및 사고 대응을 담당하는 경우라면 AI는 주로 작업 속도를 향상시켜 줄 것입니다.

핵심 요약:

책임감: 단순히 코드를 빨리 작성하는 것이 아니라 결과에 대한 책임을 우선시하십시오.

품질: 파이프라인의 신뢰성을 유지하기 위해 테스트, 관찰 가능성 및 계약을 구축합니다.

관리: 개인정보 보호, 접근 제어, 데이터 보존 및 감사 추적은 담당자가 직접 관리해야 합니다.

오용 방지: AI 출력물을 초안으로 간주하고, 잘못된 확신에 찬 오류를 방지하기 위해 검토하십시오.

역할 전환: 정형화된 문구를 작성하는 데 시간을 덜 쓰고 내구성이 뛰어난 시스템을 설계하는 데 더 많은 시간을 투자하세요.

데이터 팀과 5분 이상 함께 시간을 보냈다면, 때로는 속삭이듯, 때로는 마치 반전처럼 회의 전체에 울려 퍼지는 이 말을 들어봤을 겁니다. " 인공지능이 데이터 엔지니어를 대체할까요?"

그리고… 이해합니다. AI는 SQL 쿼리를 생성하고, 파이프라인을 구축하고, 스택 트레이스를 설명하고, dbt 모델을 작성하고, 심지어는 놀라울 정도로 확신에 찬 어조로 웨어하우스 스키마까지 제안할 수 있습니다. GitHub Copilot for SQL About dbt models GitHub Copilot
마치 지게차가 저글링을 배우는 걸 보는 것 같습니다. 인상적이면서도 약간 불안하고, 이게 내 업무에 어떤 의미를 갖는지 완전히 확신할 수 없죠 😅

하지만 진실은 헤드라인처럼 깔끔하지 않습니다. AI는 데이터 엔지니어링을 완전히 바꿔놓고 있습니다. 지루하고 반복적인 작업을 자동화하고, "원하는 건 알지만 구문이 생각나지 않아" 애매한 부분을 빠르게 처리해 줍니다. 하지만 동시에 완전히 새로운 종류의 혼란도 야기하고 있습니다.

그러니 막연한 낙관론이나 비관적인 전망에 휩싸이지 않고, 제대로 상황을 설명해 봅시다.

이 글을 읽고 나서 읽어보시면 좋을 만한 글들:

🔗 인공지능이 영상의학과 전문의를 대체할까요?
이미지 처리 AI가 워크플로, 정확도 및 미래 직무에 미치는 영향.

🔗 인공지능이 회계사를 대체할까요?
AI가 자동화하는 회계 업무와 여전히 사람이 담당하는 업무를 비교해 보세요.

🔗 인공지능이 투자은행가를 대체할까요?
AI가 거래, 연구 및 고객 관계에 미치는 영향을 이해하십시오.

🔗 인공지능이 보험 설계사를 대체할까요?
인공지능이 보험 인수 심사, 영업 및 고객 지원을 어떻게 혁신하는지 알아보세요.

---

"AI가 데이터 엔지니어를 대체할 것인가?"라는 질문이 왜 자꾸 다시 나오는 걸까요? 😬

이러한 우려는 매우 구체적인 이유에서 비롯됩니다. 데이터 엔지니어링에는 반복적인 작업이 많기 때문입니다.

• SQL 작성 및 리팩토링

• 데이터 수집 스크립트 구축

• 한 스키마의 필드를 다른 스키마로 매핑하기

• 테스트 및 기본 문서 작성

• 디버깅 파이프라인 오류는… 어느 정도 예측 가능한 것들입니다

AI는 반복적인 패턴을 파악하는 데 매우 뛰어납니다. 그리고 데이터 엔지니어링의 상당 부분은 바로 그러한 패턴들이 겹겹이 쌓인 결과물입니다. (GitHub Copilot 코드 제안)

또한, 도구 생태계는 이미 복잡성을 "숨기고" 있습니다

• Fivetran 문서 에서 관리하는 ELT 커넥터

• 서버리스 컴퓨팅 AWS Lambda (서버리스 컴퓨팅)

• 원클릭 창고 프로비저닝

• 자동 스케일링 오케스트레이션 Apache Airflow 문서

• 선언적 변환 프레임워크 (dbt)란 무엇인가요?

그래서 AI가 등장하면 마치 마지막 조각처럼 느껴질 수 있습니다. 스택이 이미 추상화되어 있고 AI가 연결 코드까지 작성할 수 있다면… 남은 건 뭘까요? 🤷

하지만 사람들이 간과하는 부분이 있습니다. 데이터 엔지니어링은 단순히 타이핑하는 작업이 아닙니다. 타이핑은 쉬운 부분일 뿐입니다. 어려운 부분은 모호하고, 정치적이며, 끊임없이 변화하는 비즈니스 현실을 신뢰할 수 있는 시스템처럼 작동하도록 만드는 것입니다.

인공지능도 여전히 그런 모호함을 해결하는 데 어려움을 겪습니다. 사람들도 마찬가지지만, 임기응변으로 더 잘 대처할 뿐이죠.

---

데이터 엔지니어가 실제로 하루 종일 하는 일 (화려하지 않은 진실) 🧱

솔직히 말해서, "데이터 엔지니어"라는 직함은 마치 순수 수학으로 로켓 엔진을 만드는 것처럼 들립니다. 하지만 실제로는 신뢰를.

평소 일과는 "새로운 알고리즘을 개발하는 것"보다는 다음과 같습니다

• 상위 팀과 데이터 정의에 대해 협상하는 것(힘들지만 필수적임)

• 지표가 변한 이유(그리고 그 변화가 실제인지 여부)를 조사합니다

• 스키마 변경 및 "누군가 한밤중에 열을 추가했습니다"와 같은 예상치 못한 상황 처리

• 파이프라인의 멱등성, 복구 가능성, 관찰 가능성을 보장합니다

• 하위 분석가들이 실수로 엉터리 대시보드를 만들지 않도록 안전장치를 마련합니다

• 창고가 돈 낭비의 도가니가 되지 않도록 비용을 관리하는 방법 🔥

• 접근 보안, 감사, 규정 준수, 보존 정책, GDPR 원칙(유럽 위원회), 저장 용량 제한(ICO)

• 사람들이 DM으로 20가지 질문을 보내지 않고도 실제로 사용할 수 있는 데이터 제품을 만드는 것

업무의 상당 부분은 사회적 및 운영적인 측면과 관련이 있습니다

• “이 테이블은 누구 거예요?”

• “이 정의는 여전히 유효한가요?”

• "CRM에서 중복된 데이터가 내보내지는 이유는 무엇인가요?"

• "이 지표를 임원진에게 부끄럽지 않게 제출할 수 있을까요?" 😭

인공지능이 이러한 문제의 일부를 해결하는 데 도움을 줄 수 있는 것은 분명합니다. 하지만 인공지능을 완전히 대체하는 것은… 다소 무리한 시도입니다.

---

훌륭한 데이터 엔지니어 직무란 어떤 특징을 가지고 있을까요? ✅

이 부분이 중요한 이유는 대체 인력 논의에서 데이터 엔지니어를 주로 "파이프라인 구축자"로 보는 경향이 있기 때문입니다. 이는 마치 요리사를 주로 "야채 썰기"를 하는 사람으로 보는 것과 같습니다. 야채 썰기도 업무의 일부이지만, 주된 업무는 아닙니다.

뛰어난 데이터 엔지니어는 일반적으로 다음과 같은 대부분의 작업을 수행할 수 있습니다.

• 변화를 고려한 설계
  . 데이터는 변하고, 팀도 변하고, 도구도 변합니다. 훌륭한 엔지니어는 현실이 잠깐 휙 돌아도 무너지지 않는 시스템을 구축합니다. 🤧

• 계약 및 기대치를 정의하세요.
  "고객"이란 무엇을 의미하나요? "활성"이란 무엇을 의미하나요? 행이 늦게 도착하면 어떻게 되나요? 계약은 복잡한 코드보다 혼란을 방지하는 데 훨씬 효과적입니다. 오픈 데이터 계약 표준(ODCS) ODCS(GitHub)

• 모든 것에 관찰 가능성을 구축하세요.
  단순히 "실행되었는가"가 아니라 "정확하게 실행되었는가"를 확인해야 합니다. 최신성, 볼륨 이상, 널(null) 값 급증, 분포 변화 등을 파악해야 합니다. 데이터 관찰 가능성(Dynatrace) 이란 무엇일까요?

• 성숙한 자세로 절충안을 마련하세요
  . 속도와 정확성, 비용과 지연 시간, 유연성과 단순성 등 다양한 요소를 고려해야 합니다. 완벽한 파이프라인은 없으며, 오직 감당할 수 있는 파이프라인만 존재합니다.

• 비즈니스 요구사항을 지속 가능한 시스템으로 전환하세요.
  사람들은 지표를 요구하지만, 실제로 필요한 것은 데이터 제품입니다. AI는 코드를 작성할 수는 있지만, 비즈니스상의 위험 요소를 마법처럼 미리 파악할 수는 없습니다.

• 데이터를 조용하게 유지하세요.
  데이터 플랫폼에 대한 최고의 찬사는 아무도 그것에 대해 이야기하지 않는다는 것입니다. 특별한 사건이 없는 데이터는 좋은 데이터입니다. 마치 배관과 같습니다. 고장이 났을 때만 눈에 띄죠 🚽

이러한 일들을 하고 있다면, "AI가 데이터 엔지니어를 대체할까요?" 다소 어색하게 들릴 것입니다. AI는 업무 자체를, 소유권을.

---

AI는 이미 데이터 엔지니어들에게 많은 도움을 주고 있으며, 이는 정말 훌륭한 일입니다 🤖✨

AI는 단순한 마케팅 도구가 아닙니다. 잘 활용하면 진정한 시너지 효과를 낼 수 있습니다.

1) 더 빠른 SQL 및 변환 작업

• 복잡한 접합부 도면 작성

• 생각하고 싶지 않은 윈도우 함수 작성하기

• 평이한 언어로 작성된 논리를 쿼리 골격으로 변환하기

• 보기 흉한 쿼리를 읽기 쉬운 CTE로 리팩토링하기: SQL용 GitHub Copilot

이는 "백지 상태" 효과를 줄여주기 때문에 매우 중요합니다. 여전히 검증은 필요하지만, 0%가 아닌 70%에서 시작할 수 있습니다.

2) 디버깅 및 근본 원인 추적

인공지능이 꽤 괜찮은 점은 다음과 같습니다

• 오류 메시지 설명

• 어디를 봐야 할지 제안합니다

• GitHub Copilot에서 "스키마 불일치 확인"과 같은 단계를 권장하는 건 마치 잠도 안 자고 가끔은 자신만만하게 거짓말까지 하는 쉴 새 없는 주니어 엔지니어를 둔 것 같아요 😅
  

3) 문서화 및 데이터 카탈로그 보강

자동 생성됨:

• 컬럼 설명

• 모델 요약

• 계보 설명

• "이 테이블은 무엇에 사용되나요?" dbt 문서

완벽하진 않지만, 문서화되지 않은 파이프라인의 고질적인 문제를 해결합니다.

4) 비계 테스트 및 점검

AI는 다음과 같은 제안을 할 수 있습니다

• 기본 널 테스트

• 고유성 검사

• 참조적 무결성 개념

• “이 지표는 절대 감소해서는 안 됩니다” 스타일의 주장, dbt 데이터 테스트, 위대한 기대: 기대치

다시 말씀드리지만, 무엇이 중요한지는 여전히 여러분이 결정하시지만, 이 시스템은 일상적인 절차를 더 빠르게 처리해 줍니다.

5) 파이프라인 "접착" 코드

설정 템플릿, YAML 스캐폴드, 오케스트레이션 DAG 초안. 이런 것들은 반복적인 작업인데, AI는 반복적인 작업을 아주 쉽게 처리하죠 🥣 아파치 에어플로우 DAG

---

인공지능이 여전히 어려움을 겪는 부분 (그리고 이것이 핵심입니다) 🧠🧩

이 부분이 가장 중요한데, 왜냐하면 이 부분이 교체에 대한 질문에 실질적인 질감을 담아 답해주기 때문입니다.

1) 모호성과 변화하는 정의

비즈니스 로직은 드물게 명확합니다. 사람들은 말을 하다가도 중간에 생각을 바꾸곤 하죠. "활성 사용자"가 "유료 활성 사용자"가 되고, 다시 "환불을 제외한 유료 활성 사용자(단, 예외적인 경우는 제외)"가 되는 식입니다. 다들 아시잖아요.

인공지능은 그러한 모호함을 소유할 수 없습니다. 단지 추측할 수 있을 뿐입니다.

2) 책임 및 위험

파이프라인에 문제가 발생하고 경영진 대시보드에 이상한 내용이 표시되면 누군가는 다음을 수행해야 합니다

• 응급 분류

• 영향력을 전달하세요

• 고쳐주세요

• 재발 방지

• 부검 보고서를 작성하세요

• 지난주 수치를 여전히 신뢰할 수 있는지 여부를 결정하세요

AI는 도움을 줄 수는 있지만, 의미 있는 방식으로 책임을 질 수는 없습니다. 조직은 분위기로 돌아가는 것이 아니라 책임감으로 돌아갑니다.

3) 시스템적 사고

데이터 플랫폼은 수집, 저장, 변환, 오케스트레이션, 거버넌스, 비용 관리, SLA 등 다양한 요소를 아우르는 생태계입니다. 한 계층의 변화가 전체 시스템에 파급 효과를 미칩니다. 아파치 에어플로우(Apache Airflow) 개념을 살펴보겠습니다

AI는 부분적인 최적화 방안을 제시하지만, 오히려 전체적인 문제를 야기할 수 있습니다. 마치 삐걱거리는 문을 고치려고 문 자체를 없애버리는 것과 같죠. 😬

4) 보안, 개인정보보호, 규정 준수

이곳은 대체에 대한 환상이 사라지는 곳입니다.

• 접근 제어

• 수준 보안 행 액세스 정책 BigQuery 행 수준 보안

• 개인정보 처리 관련 NIST 개인정보 보호 프레임워크

• 보존 규칙 저장 제한(ICO) EU 보존 지침

• 감사 추적 NIST SP 800-92(로그 관리) CIS 제어 8(감사 로그 관리)

• 데이터 상주 제약 조건

AI는 정책을 구상할 수는 있지만, 이를 안전하게 실행하는 것은 진정한 엔지니어링의 영역입니다.

5) "알 수 없는 미지의 것들"

데이터 사고는 예측하기 어려운 경우가 많습니다

• 벤더 API가 조용히 의미론을 변경합니다

• 시간대 가정이 뒤집힙니다

• 백필은 파티션을 복제합니다

• 재시도 메커니즘으로 인해 이중 쓰기가 발생합니다

• 새로운 제품 기능은 새로운 이벤트 패턴을 도입합니다

인공지능은 상황이 알려진 패턴이 아닐 때 성능이 떨어집니다.

---

비교표: 실제로 무엇이 무엇을 줄여주는지 🧾🤔

아래는 실용적인 관점입니다. "사람을 대체하는 도구"가 아니라, 특정 작업을 간소화하는 도구와 접근 방식입니다.

도구/접근 방식	청중	가격 분위기	작동 원리
AI 코드 코파일럿(SQL + Python 도우미) GitHub 코파일럿	코드를 많이 작성하는 엔지니어	거의 무료에서 유료까지	스캐폴딩, 리팩토링, 구문 분석에 뛰어나지만, 가끔은 아주 특정한 방식으로 거만해 보이기도 합니다
Fivetran 관리형 ELT 커넥터	데이터 수집 구축에 지친 팀들	구독-y	맞춤형 섭취의 고통은 없애지만, 새롭고 재미있는 방식으로 분해합니다
데이터 관찰 가능성 플랫폼 데이터 관찰 가능성(Dynatrace)	SLA를 소유한 모든 사람	중소기업	이상 징후를 조기에 감지합니다 - 예를 들어 송유관용 연기 감지기 🔔
변환 프레임워크(선언적 모델링) dbt	분석 + DE 하이브리드	일반적으로 도구 + 컴퓨팅	로직을 모듈화하고 테스트 가능하게 만들어 코드가 복잡해지는 것을 방지합니다
데이터 카탈로그 + 시맨틱 레이어 dbt 시맨틱 레이어	측정 기준에 혼란을 겪는 조직	실제로는 상황에 따라 다릅니다	'진실'을 한 번만 정의함으로써 끝없는 측정 논쟁을 줄입니다
템플릿을 사용한 오케스트레이션: Apache Airflow	플랫폼 지향적인 팀	오픈 + 운영 비용	워크플로우를 표준화하여 개별적인 DAG(방향 비순환 그래프) 수를 줄입니다
AI 기반 문서화 dbt 문서 생성	문서 작성을 싫어하는 팀	저렴한 편부터 중간 정도까지	지식이 사라지지 않도록 "충분히 좋은" 문서를 만듭니다
자동화된 거버넌스 정책 NIST 개인정보보호 프레임워크	규제된 환경	엔터프라이즈-y	규칙 시행에 도움이 되지만, 규칙을 설계하는 데는 여전히 인간의 손길이 필요합니다

빠진 부분을 눈치채셨나요? "데이터 엔지니어를 제거하려면 버튼을 누르세요"라는 항목이 빠져있습니다. 네… 그 항목은 존재하지 않아요 🙃

---

그렇다면… AI가 데이터 엔지니어를 대체할까요, 아니면 역할만 바뀔까요? 🛠️

간단히 말해서, 인공지능은 업무 흐름의 일부를 대체할 뿐, 직업 자체를 대체하지는 않을 것입니다.

하지만 이는 역할을 재편 할 것입니다 . 그리고 만약 당신이 이를 무시한다면, 압박감을 느끼게 될 것입니다

변경되는 사항:

• 정형화된 문구 작성 시간 단축

• 문서 검색 시간 단축

• 검토, 검증, 설계에 더 많은 시간을 투자하세요

• 계약 및 품질 기대치를 정의하는 데 더 많은 시간을 할애해야 함 (공개 데이터 계약 표준(ODCS))

• 제품, 보안, 재무 부서와 협력하는 데 더 많은 시간을 할애합니다

이것이 바로 미묘한 변화입니다. 데이터 엔지니어링은 더 이상 "파이프라인 구축"에 관한 것이 아니라 "안정적인 데이터 제품 시스템 구축"에 관한 것이 되었습니다

그리고 아이러니하게도, 그것은 오히려 더 가치 있는 일입니다.

또한, 다소 과장되게 들릴지 모르지만, AI는 데이터 산출물을 만들어낼 수 있는 사람의 수를 늘리고, 이는 결국 전체 시스템을 제대로 관리할 사람의 필요성을 증가시킵니다. 산출물이 많아질수록 혼란의 가능성도 커지기 때문입니다. GitHub Copilot

마치 모든 사람에게 전동 드릴을 나눠주는 것과 같죠. 훌륭하네요! 이제 누군가 "수도관에 구멍을 뚫지 마세요"라는 규칙을 지키도록 해야 할 거예요 🪠

---

인공지능이 도처에 존재하는 시대에도 여전히 가치 있는 새로운 스킬 스택 🧠⚙️

실용적이고 "미래에도 유효한" 체크리스트를 원하신다면 다음과 같습니다

시스템 설계 사고방식

• 변화에도 살아남는 데이터 모델링

• 일괄 처리와 스트리밍 처리의 장단점

• 지연 시간, 비용, 신뢰성에 대한 고찰

데이터 품질 엔지니어링

• 계약, 유효성 검사, 이상 탐지, 오픈 데이터 계약 표준(ODCS), 데이터 관찰 가능성(Dynatrace)

• SLA, SLO, 사고 대응 습관

• 체계적인 (느낌이 아닌) 원칙에 입각한 근본 원인 분석

거버넌스 및 신뢰 아키텍처

• 접근 패턴

• 감사 가능성 NIST SP 800-92(로그 관리)

• 개인정보 보호 설계 NIST 개인정보 보호 프레임워크

• 데이터 수명주기 관리 EU 보존 지침

플랫폼 사고방식

• 재사용 가능한 템플릿, 황금 경로

• Fivetran dbt 데이터 테스트를 위한 수집, 변환 및 테스트의 표준화된 패턴

• 녹지 않는 셀프 서비스 공구

소통 (정말이에요)

• 명확한 문서 작성

• 정의 일치시키기

• 정중하지만 단호하게 "아니오"라고 말하기

• 로봇처럼 딱딱하게 들리지 않게 장단점을 설명하는 방법 🤖

이러한 것들을 할 수 있다면, "AI가 데이터 엔지니어를 대체할 것인가?"라는 질문은 더 이상 위협적으로 느껴지지 않을 것입니다. AI는 당신을 대체하는 것이 아니라, 당신의 외골격이 되어줄 것입니다.

---

데이터 엔지니어링 직무 중 일부가 축소되는 현실적인 시나리오 📉

자, 잠깐 현실 점검 좀 해볼까요? 세상이 마냥 행복하고 이모티콘으로 가득한 곳만은 아니니까요 🎉

일부 역할은 더 많이 노출됩니다

• 모든 것이 표준 커넥터인 Fivetran 커넥터를 사용하는 순수 데이터 수집 전용 역할

• 팀들은 대부분 도메인별 세부적인 사항을 고려하지 않고 반복적인 보고 파이프라인 작업을 수행합니다

• 데이터 엔지니어를 "SQL 초보자"로 취급하는 조직 (가혹한 표현이지만 사실입니다)

• 업무 내용이 단순히 티켓 처리와 복사 붙여넣기인, 소유권이 낮은 직무

AI와 관리형 도구를 결합하면 이러한 요구 사항을 줄일 수 있습니다.

하지만 그런 경우에도 교체는 대개 다음과 같은 형태로 이루어집니다

• 반복적인 작업을 하는 사람이 줄어들고 있습니다

• 플랫폼 소유권 및 신뢰성에 더욱 중점을 두다

• “한 사람이 더 많은 파이프라인을 지원할 수 있다”는 방향으로의 전환

네, 맞습니다. 인력 변동 패턴은 변할 수 있습니다. 직무도 진화하고, 직책도 바뀔 수 있습니다. 그건 사실입니다.

하지만, 높은 책임감과 신뢰를 바탕으로 한 역할의 형태는 여전히 남아 있습니다.

---

마무리 요약 🧾✅

인공지능이 데이터 엔지니어를 대체할까요? 사람들이 상상하는 것처럼 깔끔하고 완벽하게 대체하지는 않을 겁니다.

AI는 다음과 같은 일을 할 것입니다:

• 반복적인 작업을 자동화하다

• SQL dbt 문서화를 위한 GitHub Copilot을 사용하여 코딩, 디버깅 및 문서화 속도를 높이세요.

• 파이프라인 생산 비용을 줄입니다

하지만 데이터 엔지니어링은 근본적으로 다음과 같은 것입니다:

• 책임

• 시스템 설계

• 신뢰, 품질 및 거버넌스 개방형 데이터 계약 표준(ODCS) NIST 개인정보 보호 프레임워크

• 불투명한 비즈니스 현실을 신뢰할 수 있는 데이터 제품으로 변환

인공지능은 그 일에 도움을 줄 수는 있지만, 그 일을 "소유"하는 것은 아닙니다.

데이터 엔지니어라면 전환은 간단합니다(쉽지는 않지만요).
책임감, 품질, 플랫폼 중심적 사고, 그리고 소통에 집중하세요. AI가 반복적인 작업을 처리하도록 맡기고, 당신은 중요한 부분에 집중하세요.

네, 맞아요. 때로는 그 상황에서 어른스러운 역할을 해야 할 때도 있죠. 화려하진 않지만, 조용하면서도 강력한 힘이 되는 역할이에요 😄

AI가 데이터 엔지니어를 대체할까요?
일부 업무를 대체하고, 업계 판도를 바꾸고, 최고의 데이터 엔지니어의 가치를 더욱 높일 것입니다. 이것이 바로 AI가 말하고자 하는 핵심입니다.

실제 사례: AI 기반 데이터 파이프라인 검토 워크플로 구축 🛠️

대본

데이터 엔지니어 한 명과 분석가 두 명을 둔 소규모 전자상거래 회사를 상상해 보세요. 이 회사는 결제 서비스 제공업체가 필드 이름을 변경할 때마다 재무 대시보드가 ​​제대로 작동하지 않는 아주 흔한 문제에 직면해 있습니다.

팀은 AI가 파이프라인을 "소유"하는 것을 원하지 않습니다. 그것은 위험할 수 있기 때문입니다. 대신, 그들은 AI를 일상적이지만 중요한 작업, 예를 들어 dbt 모델 골격 작성, 테스트 제안, 문서 초안 작성, 코드 검토 체크리스트 생성 등을 위한 초안 작성 보조 도구로 활용합니다.

데이터 엔지니어는 여전히 최종 설계, 데이터 정의, 접근 규칙 및 프로덕션 배포를 담당합니다. AI는 단지 복잡한 중간 단계를 가속화할 뿐입니다.

워크플로에 필요한 것

AI를 사용하기 전에 팀은 AI가 유용하게 활용될 수 있도록 충분한 맥락 정보를 제공합니다

• 기존 결제 테이블 스키마

• 목표 재무 지표 정의에는 "순수익", "환불 금액", "정산 금액" 등이 포함됩니다

• dbt 모델의 명명 규칙

• 승인된 테스트의 예시

• 결제 피드용 간략한 데이터 계약

• 개인 식별 정보, 미지급금, 중복 기록 및 지연 도착 기록 처리 규칙

• 과거 발생했던 사건들의 사례와 함께, 무엇이 잘못되었고 어떻게 해결되었는지를 보여줍니다

핵심은 "AI에게 파이프라인 구축을 요청하라"가 아닙니다. 너무 모호한 표현입니다.

더 나은 접근 방식은 다음과 같습니다. "규칙은 이렇고, 스키마는 이렇고, 예상되는 동작은 이렇습니다. 검토할 수 있는 초안을 작성해 주세요."

예시 지침

귀하는 당사의 결제 데이터에 대한 dbt 모델 초안 작성을 지원하고 있습니다. 아래 스키마와 규칙을 사용하여 초기 모델, 제안된 dbt 테스트 및 문서화 참고 ​​사항을 작성하십시오.

이 모델은 주문 ID와 결제 제공업체별로 일일 정산 수익을 계산해야 합니다. 결제 실패 건과 테스트 거래는 제외하고, 환불 상태가 "확인됨"인 경우에만 환불액을 차감해야 합니다.

불필요한 열을 만들지 마십시오. 필수 열이 누락된 경우 추측하지 말고 "사람이 검토해야 할 질문" 항목에 해당 열을 명시하십시오.

또한 고유성, 결측값, 허용 값 및 수익 합리성에 대한 테스트를 제안하십시오. 재무 보고에 영향을 미칠 수 있는 모든 논리를 표시하십시오.

테스트 방법

합리적인 테스트는 규모가 작고 의도적으로 평범해야 합니다

• AI에게 검증된 결제 체계 하나를 제공하고, AI가 새로운 항목을 만들어내지 않는지 확인합니다.

• refund_status 열이 누락된 스키마 하나를 제공하고, 추측하는 대신 질문을 하는지 확인해 보세요.

• 생성된 SQL 쿼리를 프로덕션 데이터셋이 아닌 스테이징 데이터셋에 대해 실행하세요.

• 출력 결과를 수동으로 확인한 20건의 결제 기록과 비교하십시오.

• 병합하기 전에 분석가와 데이터 엔지니어에게 정의를 검토해 달라고 요청하세요.

• 승인된 테스트를 CI에 추가하여 배포 후에도 파이프라인이 자체적으로 지속적으로 검사하도록 하세요.

중요한 것은 가장 우려되는 오류 유형, 즉 임의로 생성된 열, 잘못된 수익 논리, 누락된 환불 처리, 그리고 숨겨진 중복 행에 대해 AI를 테스트하는 것입니다.

결과

예시 결과: 이 워크플로를 사용하기 전후에 세 가지 샘플 파이프라인 변경 작업에 소요된 시간을 비교한 결과입니다.

AI를 사용하기 전에는 엔지니어가 변경 사항 하나당 약 5시간 30분을 소요했습니다. 대략 2시간은 SQL 작성, 1시간은 테스트 생성, 45분은 문서 작성, 나머지는 재무팀과 함께 예외 상황을 검토하는 데 사용되었습니다.

AI를 초안 작성에만 사용했을 경우, 동일한 유형의 변경 작업에 약 2시간 10분이 소요되었습니다. 가장 큰 시간 절약은 테스트 프레임워크 및 문서 초안 작성에서 나타났는데, 이 작업 시간이 1시간 45분에서 약 25분으로 단축되었습니다.

사람의 검토 단계는 여전히 약 45분이 소요되므로 삭제해서는 안 됩니다.

세 가지 작업으로 구성된 테스트에서 AI는 18개의 검토 사항을 제안했습니다. 엔지니어는 11개를 수용하고 5개를 수정했으며, 2개는 실제 비즈니스 규칙과 맞지 않는 가정을 바탕으로 했기 때문에 거부했습니다. 이 거부 횟수는 중요한 의미를 지닙니다. 워크플로에 맹목적인 신뢰가 아닌 검토가 필요하다는 것을 보여주기 때문입니다.

무슨 문제가 생길 수 있을까?

AI는 파이프라인이 실제보다 더 완벽해 보이도록 만들 수 있습니다.

일반적인 실패 원인은 다음과 같습니다

• 그럴듯하게 들리는 칼럼을 만들어내기

• 환불, 차지백, 결제 실패를 동일하게 취급

• 일일 매출에서 시간대 정보가 누락되는 문제

• 재무 오류를 잡아내지 못하는 일반적인 테스트를 제안합니다

• 자신감 있어 보이지만 불확실성을 숨기는 문서 작성

• 샘플 데이터에 고객 정보가 포함되어 있을 때 개인정보 보호 규칙을 잊어버리는 경우

좋은 규칙은 다음과 같습니다. AI는 모델 초안을 작성할 수 있지만, 정의, 자금 논리, 접근 제어 및 제품 출시에 대해서는 사람이 최종 승인을 해야 합니다.

실질적인 교훈

데이터 엔지니어링에서 인공지능의 진정한 가치는 "데이터 엔지니어를 대체하는 것"이 ​​아니라 "백지 상태를 없애고, 철저하게 검토하는 것"입니다.

즉, SQL 실행 속도 향상, 테스트 속도 향상, 그리고 더 나은 초기 문서 작성이 가능해지는 동시에, 엔지니어는 데이터의 정확성, 신뢰성, 보안성, 그리고 설명 가능성 등 가장 중요한 부분에 대한 책임을 계속해서 맡게 됩니다.

---

자주 묻는 질문

인공지능이 데이터 엔지니어를 완전히 대체할까요?

대부분의 조직에서 AI는 특정 작업을 완전히 없애기보다는 그 작업을 대신하는 경우가 더 많습니다. SQL 쿼리 작성, 파이프라인 구축, 문서 초안 작성, 기본적인 테스트 생성 등을 가속화할 수 있습니다. 하지만 데이터 엔지니어링에는 소유권과 책임감이 따르며, 복잡한 비즈니스 현실을 안정적인 시스템처럼 작동하도록 만드는 고되고도 어려운 작업도 포함됩니다. 이러한 부분에서는 여전히 인간이 무엇이 "올바른" 것인지 판단하고 문제가 발생했을 때 책임을 져야 합니다.

AI가 이미 자동화하고 있는 데이터 엔지니어링 부분은 무엇인가요?

AI는 반복적인 작업, 예를 들어 SQL 초안 작성 및 리팩토링, dbt 모델 골격 생성, 일반적인 오류 설명, 문서 개요 작성 등에 가장 효과적입니다. 또한 null 값이나 고유성 검사와 같은 테스트 프레임워크를 구축하고 오케스트레이션 도구를 위한 템플릿 "접착" 코드를 생성할 수도 있습니다. AI를 활용하면 솔루션 개발에 한 걸음 더 가까워질 수 있다는 장점이 있지만, 정확성을 검증하고 환경에 적합한지 확인하는 작업은 여전히 ​​필요합니다.

인공지능이 SQL 쿼리와 파이프라인을 작성할 수 있다면, 데이터 엔지니어에게 남은 역할은 무엇일까요?

데이터 엔지니어는 데이터 계약 정의, 스키마 변경 처리, 파이프라인의 멱등성, 관찰 가능성 및 복구 가능성 보장 등 많은 일을 합니다. 또한 지표 변화를 조사하고, 하위 사용자들을 위한 안전장치를 구축하며, 비용과 안정성 사이의 균형을 관리하는 데 시간을 할애합니다. 결국 데이터 엔지니어의 업무는 신뢰를 구축하고 데이터 플랫폼을 "안정적"으로 유지하는 것, 즉 아무도 일상적으로 신경 쓰지 않아도 될 만큼 안정적으로 유지하는 데 있습니다.

인공지능은 데이터 엔지니어의 일상 업무를 어떻게 변화시킬까요?

일반적으로 반복적인 코드 작성과 검색 시간을 줄여주기 때문에 타이핑 시간을 줄이고 검토, 검증 및 설계에 더 많은 시간을 할애할 수 있습니다. 이러한 변화는 모든 것을 직접 코딩하는 대신 기대치, 품질 표준 및 재사용 가능한 패턴을 정의하는 역할로 이어집니다. 실제로 제품, 보안 및 재무 부서와 협력하는 경우가 더 많아질 것입니다. 기술적인 결과물을 만드는 것은 더 쉬워지지만, 관리하기는 더 어려워지기 때문입니다.

인공지능이 "활성 사용자"와 같은 모호한 비즈니스 정의를 이해하는 데 어려움을 겪는 이유는 무엇일까요?

비즈니스 로직은 고정적이거나 정확하지 않기 때문에 프로젝트 도중에 변경되거나 이해관계자에 따라 달라질 수 있습니다. AI는 해석을 제시할 수는 있지만, 정의가 진화하거나 갈등이 발생할 때 최종 결정을 내릴 수는 없습니다. 데이터 엔지니어링은 종종 협상, 가정 문서화, 모호한 요구사항을 명확한 계약으로 전환하는 작업을 필요로 합니다. 이러한 "인간의 조율" 작업은 도구가 발전하더라도 데이터 엔지니어링 역할이 사라지지 않는 핵심적인 이유입니다.

인공지능이 데이터 거버넌스, 개인정보 보호 및 규정 준수 업무를 안전하게 처리할 수 있을까요?

AI는 정책 초안 작성이나 접근 방식 제안에 도움을 줄 수 있지만, 안전한 구현을 위해서는 여전히 전문적인 엔지니어링과 세심한 감독이 필요합니다. 거버넌스에는 접근 제어, 개인정보 처리, 보존 규칙, 감사 추적, 그리고 경우에 따라서는 상주 제한 등이 포함됩니다. 이러한 영역은 위험도가 매우 높기 때문에 "거의 완벽"한 수준으로는 충분하지 않습니다. 따라서 규칙 설계, 시행 검증, 그리고 규정 준수 결과에 대한 책임은 반드시 사람이 담당해야 합니다.

인공지능이 발전함에 따라 데이터 엔지니어에게 여전히 가치 있는 기술은 무엇일까요?

시스템의 복원력을 높이는 핵심 역량으로는 시스템 설계 사고, 데이터 품질 엔지니어링, 플랫폼 중심의 표준화 등이 있습니다. 계약, 관찰 가능성, 사고 대응 습관, 체계적인 근본 원인 분석은 더 많은 사람들이 신속하게 데이터 산출물을 생성할 수 있을 때 더욱 중요해집니다. 또한, 의사소통은 중요한 차별화 요소가 됩니다. 정의를 명확히 하고, 명확한 문서를 작성하며, 갈등 없이 장단점을 설명하는 것은 데이터의 신뢰성을 유지하는 데 필수적입니다.

인공지능과 관리형 툴로 인해 가장 큰 위험에 처한 데이터 엔지니어링 직무는 무엇일까요?

반복적인 데이터 수집이나 표준 보고 파이프라인에만 집중하는 역할은 특히 관리형 ELT 커넥터가 대부분의 소스를 지원하는 경우 더욱 취약해집니다. AI와 추상화로 파이프라인당 작업량이 줄어들면서 책임 소재가 불분명하고 티켓 기반으로 처리되는 업무는 감소할 수 있습니다. 하지만 이는 대개 반복적인 작업을 하는 인력이 줄어드는 것을 의미할 뿐, "데이터 엔지니어가 아예 없어진다"는 것을 의미하지는 않습니다. 신뢰성, 품질, 그리고 믿음에 중점을 둔 책임 소재가 큰 역할은 여전히 ​​중요합니다.

GitHub Copilot이나 dbt 같은 도구를 AI와 함께 사용할 때 혼란을 일으키지 않으려면 어떻게 해야 할까요?

AI 출력물을 최종 결정이 아닌 초안으로 간주하세요. 이를 활용하여 쿼리 뼈대를 생성하고, 가독성을 개선하거나, dbt 테스트 및 문서의 구조를 구축한 다음, 실제 데이터와 예외 상황을 통해 검증하세요. 또한, 강력한 규칙(계약, 명명 표준, 관찰 가능성 검사, 코드 검토 관행)을 준수해야 합니다. 목표는 신뢰성, 비용 관리 및 거버넌스를 희생하지 않고 더 빠른 결과물을 제공하는 것입니다.

참고 자료

1. 유럽 ​​위원회 - 데이터 보호 설명: GDPR 원칙 - commission.europa.eu

2. 정보 감독관 사무실(ICO) - 저장 용량 제한 - ico.org.uk

3. 유럽 ​​위원회 - 데이터는 얼마나 오래 보관할 수 있으며, 업데이트가 필요한가요? - commission.europa.eu

4. 미국 국립표준기술연구소(NIST) - 개인정보보호 프레임워크 - nist.gov

5. 미국 국립표준기술연구소(NIST) 컴퓨터 보안 리소스 센터(CSRC) - SP 800-92: 컴퓨터 보안 로그 관리 가이드 - csrc.nist.gov

6. 인터넷 보안 센터(CIS) - 감사 로그 관리(CIS 제어) - cisecurity.org

7. Snowflake 문서 - 행 접근 정책 - docs.snowflake.com

8. Google Cloud 문서 - BigQuery 행 수준 보안 - docs.cloud.google.com

9. BITOL - 오픈 데이터 계약 표준(ODCS) v3.1.0 - bitol-io.github.io

10. BITOL(GitHub) - 오픈 데이터 계약 표준 - github.com

11. Apache Airflow - 문서 (안정 버전) - airflow.apache.org

12. Apache Airflow - DAG(핵심 개념) - airflow.apache.org

13. dbt Labs 문서 - dbt란 무엇인가요? - docs.getdbt.com

14. dbt Labs 문서 - dbt 모델 정보 - docs.getdbt.com

15. dbt Labs 문서 - 문서 - docs.getdbt.com

16. dbt Labs 문서 - 데이터 테스트 - docs.getdbt.com

17. dbt Labs 문서 - dbt 시맨틱 레이어 - docs.getdbt.com

18. Fivetran 문서 - 시작하기 - fivetran.com

19. 파이브트란 - 커넥터 - fivetran.com

20. AWS 문서 - AWS Lambda 개발자 가이드 - docs.aws.amazon.com

21. GitHub - GitHub Copilot - github.com

22. GitHub 문서 - GitHub Copilot을 사용하여 IDE에서 코드 제안 받기 - docs.github.com

23. Microsoft Learn - SQL용 GitHub Copilot(VS Code 확장 프로그램) - learn.microsoft.com

24. Dynatrace 문서 - 데이터 관찰 가능성 - docs.dynatrace.com

25. DataGalaxy - 데이터 관찰 가능성이란 무엇인가요? - datagalaxy.com

26. Great Expectations 문서 - 기대치 개요 - docs.greatexectations.io

최신 AI 기술을 공식 AI 어시스턴트 스토어에서 만나보세요

회사 소개