데이터 엔지니어링의 AI 에이전트: 실제 운영 환경에서의 성과

한밤중입니다. 파이프라인이 고장 납니다. 누군가 호출을 받습니다. 그 누군가는 반쯤 잠든 채로 노트북을 열고 지난번에 이 일이 일어났을 때 했던 것과 똑같은 일을 하기 시작합니다. 로그를 확인하고, 한참을 스크롤 하여 오류를 찾아냅니다. 그리고 진짜 의문이 생깁니다. 상류(upstream)에서 무언가 바뀌었나? 스키마를 열어보니 6시간 전 선의를 가진 팀 동료가 이름을 바꾼 컬럼이 있습니다. 그래서 그 컬럼에 의존하는 대상을 추적하고, 수정 사항을 작성하고, 다시 실행한 뒤 침대로 기어 들어갑니다.

저는 이런 일을 셀 수 없이 많이 해왔고, 마침내 한 가지 사실을 깨달았습니다. 그 작업 중 공학(engineering)이라고 할 만한 것은 거의 없다는 것입니다. 그것은 패턴 매칭과 단순 반복 작업입니다. "무엇이 올바른 수정인가"를 고민하는 진짜 사고 과정은 소비하는 시간의 10분의 1에 불과합니다. 나머지는 똑같은 단계를 백 번째 되풀이하는 것뿐입니다.

이 간극을 에이전트들이 메우기 시작하고 있습니다. 우리를 대체하는 것이 아니라, 판단이 필요한 부분에 시간을 쓸 수 있도록 직무의 지루하고 반복적인 중간 과정을 대신해 주는 방식입니다. 사람들이 AI 에이전트를 "데이터 엔지니어링의 다음 진화"라고 부를 때 저도 동의합니다. 다만 LinkedIn 포스트에서 흔히 볼 수 있는 이유 때문은 아닐 것입니다. 제가 무엇을 의미하는지 설명하고, 더 유용하게는 저희가 무엇을 만들었으며 그 과정에서 무엇이 고장 났었는지 보여드리겠습니다.

에이전트란 실제로 무엇인가

이 단어가 워낙 모호하게 사용되니 빠르게 정의해 보겠습니다. 스크립트는 시킨 일을 수행합니다. LLM 호출은 단일 질문에 답하고 멈춥니다. 에이전트는 더 나아갑니다. 상태를 인지하고, 그것에 대해 추론하고, 도구를 선택하고, 행동을 취하고, 결과를 확인한 다음, 다음에 무엇을 할지 결정할 수 있습니다. 에이전트는 루프를 돌며 진행 과정에 따라 도구를 선택하고, 단일 지침이 아닌 목표를 향해 작업합니다. 격식을 차린 정의를 원하신다면, 설정한 한계 내에서 스스로 행동하며 목표를 쫓는 시스템이라고 할 수 있습니다.

데이터 엔지니어링 맥락에서 "도구"란 로그 읽기, 메타데이터 카탈로그 쿼리, dbt 명령 실행, 리니지 조회, 또는 Jira 티켓 생성과 같은 것들을 의미합니다. 에이전트는 무언가를 달성하기 위해 이러한 도구들을 스스로 엮습니다. 이것이 핵심입니다. 마법이 아니며, "에이전틱(agentic)"이라는 단어에 겁먹지 않는다면 그렇게 복잡하지도 않습니다.