이 글은 PyCon Korea 2025에서 진행된 <MCP로 데이터 엔지니어 업무 자동화하기> 세션을 정리한 내용입니다. 데이터 엔지니어로서 단순한 작업을 자동화하기 위해 MCP를 어떻게 활용했는지 발표자의 경험을 공유합니다. 발표 자료는 PyCon Korea 2025 공식 홈페이지에서 확인할 수 있으며, 추후 파이콘 한국 유튜브 채널을 통해 영상으로도 만나보실 수 있습니다.

MCP로 데이터 엔지니어 업무 자동화하기
이왕원 엔지니어

안녕하세요, 지상 최강 ML 엔지니어를 목표로 오늘도 분투 중인 이왕원입니다. 오늘은 MCP를 사용하여, 데이터 엔지니어의 DB 업무를 자동화했던 제 경험을 통해 현시점 AI의 현업 적용 가능성에 관해 이야기해 보려고 합니다.

2025년 가장 핫했던 키워드는 ‘AI’였다고 해도 과언이 아닙니다. 어느 순간부터 기업에서 AI를 도입하려는 시도는 ‘AI transformation’이라는 중요한 분야가 되었습니다. ‘나비의 작은 날갯짓이 대륙을 넘으면 폭풍이 될 수도 있다’라는 말이 있듯이, 높으신 분의 “우리도 AI로 뭐라도 해야 하는 거 아니냐?”는 한 마디가 기업에 폭풍을 몰고 오는 상황이죠. 말은 이렇게 해도, AI transformation은 작은 날갯짓부터 시작하는 것이 좋다고 생각합니다. 저 또한 조직에 AI를 도입하면서 작은 변화부터 시작했으니까요. 이제 좀 더 자세한 이야기를 시작해 볼까요?

시작하며

MCP로 데이터 엔지니어 업무 자동화하기 — <출처: 이왕원, ChatGPT 생성>

데이터 엔지니어나 백엔드 개발을 하다 보면 생각보다 단순 DB 조회/정리/집계 업무가 많다는 것을 느낍니다. 기획자, 마케터와 같은 사업팀과 이야기를 나눠보면, 업무상 꼭 필요한 정보지만 매번 요청할 때마다 죄송한 마음이 든다고 하고요. 저희 엔지니어의 입장에선 직접적인 DB 접근 권한을 주기에는 보안과 아키텍처상 쉽지 않은 경우도 많습니다.

몸이 열 개라도 모자란 상황에서 ‘이런 건 누가 나 대신 해주면 좋겠다’ 같은 생각이 드는데요. 어디 내 분신이라도 있으면 참 편할텐데, 바로 이거다 싶더라고요. 분신술이라니 소설 속에서나 나올 것 같은 말이지만, 우리 엔지니어들에겐 충분히 가능하죠.

저의 목표는 다음과 같았습니다.

1) 간단한 DB 조회 및 집계를 대신 해주는 AI 봇 만들기

2) 비개발 직군이 쓸 수 있을 정도로 쉬워야 함

3) 만드는데 시간 투자를 많이 하면 안 됨

만드는 과정 살펴보기

1) 데모용 web agent 제작

사실 원하는 수준은 딱 이 정도였습니다. “이름이 ㅇㅇㅇ인 유저의 user_id를 알려줘”라고 질의했을 때, 대답을 할 수 있는 정도로요. 이름과 user_id 정보는 내부 SQL DB에 있고, 간단한 쿼리를 통해 알 수 있는 정보니, 이게 뭐 그리 어려울까 싶었죠.

Gradio와 같은 프레임워크의 장점은 간단한 코드 몇 줄로 웹앱을 만들 수 있다는 점인데요. 외부 서비스로 제공하기엔 아쉽더라도, 프로토타이핑이나 데모 제작으로는 충분히 만족할 만한 수준의 결과물을 보여줍니다. 제 경우도 데모용으로 사용할 템플릿을 위 몇 줄의 코드 정도로 정말 빠르게 제작할 수 있었습니다.

2) MCP 공부하기

MCP는 Model Context Protocol의 약자입니다. 나무위키 설명에는 ‘2024년 11월 25일 Anthropic이 발표 및 제안한 생성형 인공지능 및 지능형 에이전트용 개방형 프로토콜’이라고 나와 있는데, 이것만 보고는 쉽게 이해하기 어려웠죠.

유튜브에도 많은 설명이 있었지만, 쉽게 이해되지는 않았습니다. C type을 기준으로 많이들 설명해 주셨고, 실제 anthropic 또한 C type 포트를 비유로 설명한 것은 맞습니다. 그러나 일반인 기준으로는 C type 규격이 얼마나 혁신적으로 포트를 통합했는지 공감하긴 힘들 것 같습니다. 그래서 제가 여러분의 이해를 도울 수 있는 재밌는 비유를 가져왔습니다. Model Context까지도 어려우니, 정말 쉽게 프로토콜(Protocol)을 이해하는 것부터 시작해 볼까요?

혹시 가라사대 게임 아시나요? 예를 들어, 진행자가 ‘가라사대’를 붙여서 말하면 게임 참여자들이 그대로 행동하면 되고, ‘가라사대’를 붙이지 않고 말하면, 행동하면 안 되는 간단한 룰입니다.

위 그림처럼 말이죠. 제 또래는 한 번쯤 해봤던데, 이제 이 게임을 모르는 세대가 있다는 것을 듣고 슬펐습니다. 그나저나 갑자기 이 게임이 무슨 상관이냐면, 이게 바로 프로토콜의 본질이기 때문입니다. 칵테일파티 효과라는 유명한 이론이 있습니다. ‘시끄러운 환경에서 여러 음성이나 소리가 섞여 있을 때, 특정 소리에만 선택적으로 집중하여 듣는 인간의 인지 능력’인데요.

사람에겐 이런 대단한 능력이 있지만, 기계는 이런 능력이 없습니다. 따라서 여러 신호와 잡음이 섞인 통신 신호 속에서, 나에게 중요한 신호만 정확하게 캐치하는 기술이 필요했습니다. 그래서 규칙을 정했던 거죠. “통신을 잘 보고 있다가 ‘가라사대’라는 단어가 보이면 그때부터 집중해. 그건 내가 보내는 신호니까.” 이런 식으로 말이죠.

이런 식의 유명한 프로토콜에는 TCP, IP, HTTP와 같은 것들이 있습니다. 한 번쯤 들어봤던 단어들의 마지막을 장식하는 P는 사실 Protocol이었죠. 이처럼 프로토콜은 인식하지는 못했어도 우리 삶에서 정말 중요한 역할을 하고 있었습니다.

그러면 프로토콜은 이해했는데 Model Context는 어떤 의미일까요? MCP에서 Model Context는 ‘AI 모델이 작업을 수행하는 데 필요한 정보와 환경’을 의미합니다. 이러한 Context 정보 없이는 LLM은 잘못된 답변을 할 수밖에 없습니다. LLM이 정확하지 않거나, 사실이 아닌 정보를 생성하는 현상을 할루시네이션(Hallucination)이라고 합니다. 언뜻 봤을 때 정말 그럴듯하게 말하기 때문에 쓰는 입장에서는 더욱 구분하기 어렵죠. 이러한 할루시네이션 현상을 막기 위해선 모델이 꼭 맥락 정보를 고려할 수 있게 해야 합니다.

제가 처음에 만든 데모를 보면, “이름이 이왕원인 유저의 user_id를 알려줘”라는 질문을 했죠? 이것은 저희 회사 내부 DB를 보지 않고서는 절대 알 수 없는 정보입니다. 하지만 LLM이 회사 내부 DB에 접근할 수 있게 하면 대답할 수 있겠죠. 이를 연동하는 작업은 원래같으면 매우 번거로운 작업입니다. 하지만 MCP라는 표준 규격을 통해 아주 쉽게 연동할 수 있게 되었죠. 그러면 이제 다시 MCP와 LLM을 처음에 만든 데모에 붙이는 과정으로 돌아가 볼게요.

저도 결국 뭐가 뭔지 몰라서 되는대로 example도 돌려보고 했는데, 몇 번 해보니 감이 잡혔습니다. 이런 프로토콜 같은 경우는 그냥 규칙이라서 눈에 보이는 뚜렷한 것이 있는 건 아니라, 직접 해보면서 배우는게 가장 좋습니다.

3) 프로토타입 제작

가장 스타 많이 받은 오픈소스 MCP 서버를 uvx로 가져와서 사용했습니다. MCP 서버를 직접 구현하는 방법도 있지만 바퀴를 2번 발명할 필요는 없는 법이죠. 이런 식으로 아주 빠르게 프로토타입을 완성했습니다.

오픈소스와 프로토콜이 만나면 최대 장점이 이거인 것 같습니다. 지금까지는 다들 각자 자기만의 구현 방식대로 구현하고, 그거 붙이고 결합하는 것이 AI 엔지니어의 큰 업무였거든요. 이렇게 프로토콜이 잘 정립되면, 모두가 그 규칙에 맞춰서 만들기 때문에 생산성 증대에 매우 큰 도움이 되는 것 같습니다.

4) 1차 문제점 발생

이렇게 실행하면 모든 게 해결될 줄 알았지만, 처음부터 예상치 못한 일이 생겼습니다.

“이름이 이왕원인 유저의 user_id를 알려줘”라고 질의했더니, 존재하지 않는 테이블(users)과 속성(user_id)을 대상으로 쿼리를 날리는 문제가 발생했던 거죠. 아래는 실제 유저 정보 테이블의 스키마입니다.

‘users’ 테이블이 아니라 ‘User’ 테이블이고, ‘user_id‘가 아니라, ‘userId’로 검색해야 했습니다. 테이블 이름과 속성을 LLM 자기 마음대로 생각해서 SQL 쿼리를 날린 경우인데요.

5) 1차 해결 방안

“User table에 이왕원이라는 name을 가진 유저의 userId를 알려줘”처럼, 위와 같이 테이블 이름과 속성값을 정확하게 지정해서 물어봅니다.

이제 이렇게 잘 동작하는 것을 확인할 수 있는데요. 기능이 동작하게는 했지만, 이를 실제로 쓰기에는 큰 문제가 있었습니다.

6) 1차 해결 방안의 한계점

이대로면 직접 쿼리를 짜서 날리는 것과 다를 것이 없음
비개발 직군이 쓸 수 있을 정도로 쉽지 않음

비개발 직군이 쓸 수 있을 정도로 쉬워야 하는데, 위 방식은 사실상 직접 쿼리를 짜서 날리는 것과 다를 것이 없어 보입니다. 그렇다면 어떻게 해결할 수 있을까요?

7) 2차 해결 방안

DB에 대한 이해 없이 AI가 단순히 연결만 되어 있는 상황이니, AI가 DB 컨텍스트를 이해하기 위해 조금 도와주면 될 것 같습니다. 쉽게 말해 이 또한 컨텍스트에 관련된 문제이기 때문에, AI가 그 맥락을 파악할 수 있으면 된다는 의미입니다. AI가 알맞은 SQL 쿼리를 생성하기 전에, 전체적인 DB 스키마 구조를 파악하고 검색하도록 사전 프롬프트를 추가했습니다.

드디어 원하는 형태로 동작했습니다. 그럼 어떻게 해낼 수 있었는지 같이 로그를 확인해 볼까요?

데모 로그를 보니, AI가 테이블 리스트와 스키마 구조를 파악하고, 올바른 쿼리를 작성하는 것을 확인할 수 있었습니다. ‘SHOW TABLES’ 쿼리를 통해 테이블 리스트를 확인하고, ‘User’ 테이블이 해당 질의와 관련된 테이블이라는 것을 알아서 판단했습니다. 그리고 ‘DESCRIBE User’ 쿼리를 통해 User 테이블의 속성들까지 확인한 후 정확한 최종 쿼리를 날린 모습이죠.

‘어떤 방식으로 DB 스키마를 파악할지’, ‘어떤 테이블이 질의와 관련 있을 것 같은지’는 모두 LLM의 자의적인 판단하에 진행된 과정이었습니다. 이런 것들을 알아서 진행해 준다는 점에서 놀라움을 느꼈고요.

8) 추가 테스트

다음은 추가 테스트인데요. 동시에 여러 정보를 물어봐도 잘 정리해서 답변해 주는 것을 확인할 수 있었습니다. 여러 번 물어보면서 테스트해 봐도, 오류 없이 잘 동작하는 것을 봤을 때는 기분이 정말 좋았습니다.

하지만 “이름이 이왕원인 유저의 현재 크레딧 보유량이 얼마야?”라는 질의에서 오류가 발생했습니다.

9) 2차 문제점 분석 및 해결 방안

한 테이블 내에서 모든 정보를 다 찾을 수 있던 아까 질의와는 다르게, 이 질의는 User 테이블에서 userId를 먼저 찾고, UserCredit 테이블에서 추가 조회가 필요한 질문이었는데요.

이러한 여러 동작을 하는 데 기본 timeout인 5초로는 부족했던 것이 원인이라, timeout을 30초 정도로 넉넉하게 증량하는 형태로 코드를 개선했습니다.

그랬더니 다시 만족스럽게 동작하는 것을 확인할 수 있었습니다. 이런 부분에서 우리는 현시점 LLM의 성능이 어느 정도인지를 가늠할 수 있는 것 같습니다. 놀라울 정도로 잘될 때도 있지만, 컨텍스트가 조금만 복잡해도 아직 성능 면에서 아쉬운 모습을 자주 보입니다.

주의할 점은?

1) SQL 권한 관련

기술자로서 가장 마음에 걸리던 점은 LLM에 자율적으로 CRUD 권한을 맡긴다는 점이었습니다. 사실 수행 능력만 보면 단순 쿼리 정도만 작성할 수 있는 초보 엔지니어 수준이기 때문입니다. 이런 엔지니어에게 CURD 권한을 모두 맡긴다는 것은 상당히 위험할 수 있는데요. 따라서 단순 Read 권한만 있는 유저를 생성해서 사용했습니다.

얼마 전, replit AI agent가 DB를 통째로 날렸다는 이야기가 화제였습니다. 이처럼 아직까지는 LLM의 수행 능력이 주요 관리를 맡기기엔 미숙하다는 것을 의마하며, LLM이 실수할 때 누가 책임을 질 것이느냐에 대한 문제도 논의되어야 할 필요가 있습니다. 마블 영화 ‘스파이더맨’에서도 “힘에는 책임이 따른다”라는 유명한 말이 나옵니다. 우리 업계에서도 “Free lunch is over”이라는 유명한 말이 있는데요. 일을 효율적으로 하고자 도입하는 AI이지만, 무분별하게 남용하다간 큰 사고가 날 수도 있다는 것을 명심해야 합니다.

2) 다른 컨텍스트가 필요한 경우

2025년 5월, 당시 회사에서 본격적으로 서비스를 알리기 위한 마케팅을 실시했습니다. 마케팅의 효과를 확인하기 위해, 해당 시기를 기준으로 신규 유저를 체크했는데요. 따라서 질문의 의도는 25년 5월 8일 이후의 가입자 수를 알고자 한 것인데, LLM이 멋대로 23년 5월 이후의 유저 수를 체크해서 대답했습니다.

질문에서는 2025년 5월이라고 한 적은 없고 5월이라고만 물어봤으니 틀린 답은 아니지만, 맥락상 맞는 답변이라고는 할 수 없습니다. DB 이외의 컨텍스트가 필요한 질문은 역시나 잘못된 방향으로 대답하는 것을 확인할 수 있었습니다. 만약 마케팅 시기가 기록된 노션이나 구글 캘린더를 MCP로 연동했다면 대답이 달라질 수도 있엇겠지만, 이러한 할루시네이션 현상의 가능성은 계속 염두에 둬야 합니다.

3) 테이블 이름이 헷갈리는 경우

위 이미지는 결제와 관련된 SQL 테이블들입니다. 만약 LLM이 결제와 관련된 정보를 조회해야 한다면, legacy 테이블들이 섞여 있는 이 부분에서 병목이 생길 수 있습니다. 실제로 제가 결제 관련 질의를 했을 때도 정확히 이 문제로 인해 병목이 생겨, 질의가 timeout으로 실패한 적이 있는데요.

코드나 테이블 정리가 잘 안되어있으면 인수인계하거나, 협업할 때 애로사항이 생기듯, LLM과 협업할 때도 코드나 스키마를 깔끔하게 정리하는 것은 아주 중요한 일이라는 것을 알 수 있는 부분입니다.

마치며

오늘은 MCP를 활용한 간단한 SQL 쿼리 작업 보조 챗봇을 만드는 내용에 대해 소개해 봤습니다. 정리하면 다음과 같습니다.

1) AI의 발전 속도가 정말 빠르고, MCP는 오픈소스도 잘 되어있음

2) 컨텍스트가 필요한 부분을 LLM이 마치 사람처럼 알아낸다는 부분이 놀라움

3) 도입 공수가 크게 들지 않는 방향으로 고려해 보는 것을 추천함

4) 현 LLM+MCP로도 간단한 DB 조회 및 정리 업무는 충분히 가능함

저 역시 해당 데모는 큰 공수를 들이지 않고 제작했음에도 불구하고, 업무 효율을 올리는 데 유용했습니다. 지금도 단순한 업무들은 충분히 AI가 대체할 수 있고, 이 수준은 AI의 성능이 점점 발전함에 따라 고수준의 업무까지 대체할 수 있을 듯합니다. 그러니 범람하는 AI 홍수에 맞춰, 엔지니어들은 어떤 변화가 있을지 깊이 생각해 보는 자세가 필요합니다. 읽어주셔서 감사합니다.