||
AI Agent “Megatron” 이야기 — LangChain/LangGraph 기반 Agentic Loop와 MCP로 연결한 실행 백엔드가, 반복되던 CDC 온보딩 절차를 대화 하나로 줄인 과정을 실제 구현 기준으로 이야기해 봤습니다.
“Data & AI Platform Peace through Brutal Automation.”
평화는 무자비한 자동화를 통해 달성된다.
- Megatron
안녕하세요. KREAM Data&AI Platform 팀 Lead Leon(유결)입니다.
새로운 테이블 하나를 실시간 데이터 파이프라인에 태우는 일. 별거 아닌 것 같지만 실제로는 4개의 서로 다른 시스템을 오가며 사람이 판단하고, PR을 올리고, 서버에 직접 접속해야 끝나는 작업이었습니다. 저는 이 과정을 통째로 Slack 대화 한 번으로 줄였습니다. 그 뒤에 있는 AI Agent의 이름은 Megatron입니다.
(참고로 이름을 옵티머스가 아니라 메가트론으로 지은 건, 개인적으로 선한 주인공보다 악당 캐릭터를 좋아해왔기 때문입니다.
)
이 글에서는 Megatron이 무엇을, 어떻게 자동화했는지 — LangChain/LangGraph 기반 Agentic Loop, MCP(Model Context Protocol)로 연결된 도구 서버, 승인 게이트와 Auto Failover 같은 안전장치까지 — 실제 구현을 기준으로 정리합니다.
0. 배경 — CDC 파이프라인과 Lakehouse
Megatron 이야기로 들어가기 전에, KREAM Data&AI Platform 팀에서 자동화한 파이프라인 자체가 무엇인지 먼저 간단히 짚고 가겠습니다.
CDC(Change Data Capture)는 원본 데이터베이스에서 일어나는 변경(insert/update/delete)을 실시간으로 캡처해 다른 시스템으로 흘려보내는 방식입니다. 저희는 이 방식으로 서비스가 쓰는 MySQL의 데이터를 분석·집계용 Lakehouse로 실시간에 가깝게 복제합니다. 전체 흐름은 다음과 같습니다.
원본 MySQL — 서비스가 실제로 트래픽을 받는 프로덕션 데이터베이스입니다.
Debezium(Kafka Connect) — MySQL의 binlog를 읽어 변경 이벤트를 감지하고, 이를 Kafka 토픽으로 발행하는 CDC 커넥터입니다.
Kafka — 변경 이벤트가 잠시 쌓였다 흘러가는 메시지 큐입니다. 소스와 소비자를 시간·속도 면에서 분리해 주는 완충 지대 역할을 합니다.
Spark Streaming — Kafka에 쌓인 변경 이벤트를 실시간으로 읽어, 원본 테이블의 최신 상태를 Lakehouse에 반영하는 스트리밍 처리 애플리케이션입니다.
Lakehouse(HDFS + Iceberg + Trino + StarRocks) — 최종적으로 데이터가 쌓이는 곳입니다. HDFS 위에 Iceberg 테이블 포맷으로 저장되고, Trino나 StarRocks로 바로 SQL 조회를 할 수 있습니다.
이 글의 “Before”는 새 테이블 하나를 태울 때마다 2~5번 구간을 사람이 손으로 설정하고 배포하던 이야기이고, “After”는 그전 과정을 Megatron과의 대화로 줄인 이야기입니다.
원래 2~5번 구간은 관리하는 곳도, 확인하는 곳도 전부 따로였습니다. Kafka Connect 커넥터 설정은 kafka-connector 레포에 파일로 저장돼 배포됐고, Spark Streaming 애플리케이션 명세는 lakehouse-etl 레포의 매니페스트 JSON에 저장돼 배포됐습니다. 지금 어떤 상태인지 확인하려면 Kafka Connect API, Kafka UI, YARN UI를 하나씩 따로 열어 각 Application을 찾아봐야 했습니다.
그래서 저희는 이번에 stream-orchestrator라는 백엔드를 새로 만들어, 이 정보를 전부 DB로 끌어왔습니다. 커넥터·토픽·앱·테이블을 서로 매핑해서 저장해두었기 때문에, 여러 화면을 오갈 필요 없이 stream-orchestrator 하나에서 파이프라인 전체를 한눈에 볼 수 있습니다. 두 가지 화면으로 보여주는데
)
이 글에서는 Megatron이 무엇을, 어떻게 자동화했는지 — LangChain/LangGraph 기반 Agentic Loop, MCP(Model Context Protocol)로 연결된 도구 서버, 승인 게이트와 Auto Failover 같은 안전장치까지 — 실제 구현을 기준으로 정리합니다.
0. 배경 — CDC 파이프라인과 Lakehouse
Megatron 이야기로 들어가기 전에, KREAM Data&AI Platform 팀에서 자동화한 파이프라인 자체가 무엇인지 먼저 간단히 짚고 가겠습니다.
CDC(Change Data Capture)는 원본 데이터베이스에서 일어나는 변경(insert/update/delete)을 실시간으로 캡처해 다른 시스템으로 흘려보내는 방식입니다. 저희는 이 방식으로 서비스가 쓰는 MySQL의 데이터를 분석·집계용 Lakehouse로 실시간에 가깝게 복제합니다. 전체 흐름은 다음과 같습니다.
원본 MySQL — 서비스가 실제로 트래픽을 받는 프로덕션 데이터베이스입니다.
Debezium(Kafka Connect) — MySQL의 binlog를 읽어 변경 이벤트를 감지하고, 이를 Kafka 토픽으로 발행하는 CDC 커넥터입니다.
Kafka — 변경 이벤트가 잠시 쌓였다 흘러가는 메시지 큐입니다. 소스와 소비자를 시간·속도 면에서 분리해 주는 완충 지대 역할을 합니다.
Spark Streaming — Kafka에 쌓인 변경 이벤트를 실시간으로 읽어, 원본 테이블의 최신 상태를 Lakehouse에 반영하는 스트리밍 처리 애플리케이션입니다.
Lakehouse(HDFS + Iceberg + Trino + StarRocks) — 최종적으로 데이터가 쌓이는 곳입니다. HDFS 위에 Iceberg 테이블 포맷으로 저장되고, Trino나 StarRocks로 바로 SQL 조회를 할 수 있습니다.
이 글의 “Before”는 새 테이블 하나를 태울 때마다 2~5번 구간을 사람이 손으로 설정하고 배포하던 이야기이고, “After”는 그전 과정을 Megatron과의 대화로 줄인 이야기입니다.
원래 2~5번 구간은 관리하는 곳도, 확인하는 곳도 전부 따로였습니다. Kafka Connect 커넥터 설정은 kafka-connector 레포에 파일로 저장돼 배포됐고, Spark Streaming 애플리케이션 명세는 lakehouse-etl 레포의 매니페스트 JSON에 저장돼 배포됐습니다. 지금 어떤 상태인지 확인하려면 Kafka Connect API, Kafka UI, YARN UI를 하나씩 따로 열어 각 Application을 찾아봐야 했습니다.
그래서 저희는 이번에 stream-orchestrator라는 백엔드를 새로 만들어, 이 정보를 전부 DB로 끌어왔습니다. 커넥터·토픽·앱·테이블을 서로 매핑해서 저장해두었기 때문에, 여러 화면을 오갈 필요 없이 stream-orchestrator 하나에서 파이프라인 전체를 한눈에 볼 수 있습니다. 두 가지 화면으로 보여주는데