데이터 분석 워크플로우를 AI에 통째로 맡긴다는 흐름, 진짜 병목은 다른 데 있음
AI가 Google Drive에서 raw 데이터 찾아 BigQuery에 적재하고 분석 리포트까지 30분 안에 뽑아낸다는 시연이 도는데, 직접 MCP 깔아본 입장에서 보면 30분에서 빠진 시간이 더 길다. Plan Mode가 진짜 핵심인 이유, 첫 패스가 얕은 이유, 그리고 142GB짜리 로그 파일 일화까지.
영어권에서 요즘 자주 보이는 시연 패턴이 있음. AI가 데이터 분석을 끝에서 끝까지 다 한다는 거. Google Drive에서 raw 데이터 찾기 → 옛날 GitHub repo 참고해서 파싱 스크립트 작성 → BigQuery에 적재 → SQL 돌려서 리포트 생성. 사람은 질문 던지고 검토만. 30분 컷.
들으면 좀 멋지죠. 근데 비슷한 셋업 직접 만져본 입장에서는 "30분"이라는 숫자에서 빠져 있는 게 너무 많음. 그 빠진 부분이 사실은 도입 가능 여부를 결정함.
MCP 셋업이 진짜 시간을 먹음
이런 워크플로우의 핵심은 MCP(Model Context Protocol). Codex나 Claude Code 같은 에이전트가 외부 도구 — Google Drive, GitHub, BigQuery — 에 붙으려면 각 MCP 서버를 설정해야 함. 시연 글들은 이 부분을 보통 가볍게 넘어감. "AI한테 셋업 부탁하면 알아서 해줌" 식으로.
실제로 만져보면 케이스가 갈림. Google Drive 같은 건 OAuth 클라이언트 한 번 만들고 끝나니까 비교적 무난한 편. 문제는 권한 체계 복잡한 쪽이거든요. BigQuery, Snowflake, 회사 내부 ERP 등등. 이쪽은 환경변수, 인증, 스코프 설정에서 한 번에 안 붙는 게 디폴트임. 어떤 후기는 BigQuery MCP가 10번 이상 실패한 뒤에 겨우 붙었다고 솔직히 적혀 있던데, 30분 데모 보고 따라하는 사람들은 이 부분을 잘 안 봄.
내 환경은 Ubuntu 위에 nginx + FastAPI 베이스라 구글 클라우드 OAuth 콜백 한 번 트는 데도 리다이렉트 URI 화이트리스트 잡느라 시간 좀 씀. 결국 30분이 되려면 셋업이 끝나 있어야 함. 셋업까지 포함하면 반나절짜리 작업.
정작 진짜 핵심은 Plan Mode
이런 시연에서 가장 저평가된 부분이 Plan Mode 활용임. 작업 시키기 전에 /plan 으로 모델한테 "어떻게 풀 건지 단계별로 적어봐" 시키고, 사람이 검토하고, 그다음에 "이대로 실행" 하는 흐름.
왜 중요하냐면, 에이전트가 폭주하는 거의 모든 케이스가 동일한 패턴이거든. 한 줄짜리 모호한 지시 → 13분간 엉뚱한 방향으로 일함 → 결과물 갈아엎기. 미리 계획을 명문화하고 사람이 한 번 봐주면 이 사이클이 확 줄어듦. Codex랑 Claude Code 양쪽 다 있는 기능인데 활용도는 의외로 낮은 듯.
이거 진짜 안 쓰면 손해임.
첫 패스 분석은 항상 얕음
AI가 30분 만에 뽑은 첫 번째 리포트의 퀄리티에 대해서 솔직히 말하면, 굉장히 표면적임. 시계열 평균, 단순 비교, "X년부터 활동량이 줄었음" 수준의 관찰. 그 이상은 안 나옴.
깊이가 생기는 건 follow-up 질문 단계임. "여행 기간만 따로 분리해서 분석해봐", "원인 가설 세 개 세우고 데이터로 각각 검증해봐" 같은 추가 지시. 이게 들어가야 비로소 stakeholder한테 보여줄 만한 분석이 나옴.
그리고 도메인 지식 문제. 어떤 분석에서 모델이 "2020년부터 활동량이 줄었는데 원인은 모르겠고 추정뿐"이라고 정직하게 적었다는 일화가 있는데, 사람 입장에선 그게 팬데믹이라는 게 자명함. 데이터에서 "줄었다"는 사실을 뽑는 건 AI가 잘 하지만, 그게 왜인지 해석하는 건 외부 정보가 필요한 영역. 이 부분은 AI가 점점 잘하긴 해도 회사 내부 맥락(조직 개편, 정책 변경, 시즌성)까지는 여전히 사람이 채워야 함.
이게 데이터 직군 역할이 변하는 지점. 코드 짜는 시간은 줄어드는데 질문 만드는 시간은 안 줄어듦. 오히려 좋은 질문을 만드는 능력의 가중치가 더 커지는 방향.
그리고 회사 데이터에는 못 씀
개인 프로젝트면 Google Drive 통째로 권한 풀든 말든 본인 책임이지만, 회사 환경에서는 이 워크플로우 그대로 못 옮김. 데이터 거버넌스, 컴플라이언스, 외부 LLM에 데이터 흘리는 정책 — 대기업은 거의 막혀 있고 중견기업도 점점 잠그는 중.
회피 옵션이 있긴 함. MCP 서버를 회사 내부망에 self-hosted로 돌리고, 모델은 Bedrock이나 Vertex AI 같이 회사가 계약한 엔드포인트 거치게 하고. 근데 이게 별도 인프라 작업임. 시연에서 "회사 환경에선 정책 따라 쓰세요" 한 줄로 처리되는 그 부분이 사실상 도입 가능성의 70~80%를 결정한다고 봄.
잡담: 142GB짜리 로그 파일
이 주제 쓰면서 떠올린 일화 하나. 한 사람이 비슷한 셋업으로 작업한 다음 날 아침에 맥북 디스크가 가득 차 있더라는 거. 알고 보니 BigQuery MCP 트러블슈팅 중에 만들어진 wrapper 로그 파일이 142GB까지 부풀어 있었음.
이게 이번 글 결말로 잘 어울려서 적어둠. AI 에이전트가 일을 잘 한다는 게 곧 깨끗하게 한다는 뜻은 아니거든요. 디버그 모드 켜진 채로 며칠 돌리면 디스크가 죽고, 토큰 사용량 모니터링 안 하면 청구서가 죽고, MCP 권한 잘못 풀어두면 데이터가 죽음. 자동화의 비용은 보통 이런 데서 청구됨.
Claude Code 공식 docs에도 권한 관리랑 로그 핸들링 가이드가 의외로 상세한데, 매뉴얼이라 안 읽고 넘기는 사람이 많은 듯. 사고 한 번 나봐야 챙겨 보게 되는 부분.
한계 — 이 글에서 안 다룬 것들
- 비용: Codex/Claude Code를 이런 식으로 풀로 돌리면 하루 단위 토큰 비용이 어떻게 되는지는 안 다뤘음. 사용 패턴 편차가 너무 커서 일반화하기 어려움.
- 결과 검증: SQL 결과 검증 자동화는 별도 큰 주제. AI가 join 잘못해서 fan-out 나는 건 일상이고, 필터 빼먹어서 row count가 두 배 되는 것도 자주 봄. 이건 다음 글에서 따로 정리할 예정.
- 에이전트 비교: Codex vs Claude Code vs Cursor agent vs 자체 LangGraph 파이프라인이 어디서 어떻게 갈리는지는 한 명이 다 만져보고 쓸 주제가 아님. 비교 글들이 도는데 대부분 검증이 부족해 보임.
마무리
"AI가 데이터 분석을 통째로 해준다"는 프레임은 지금 시점에서 절반은 맞고 절반은 마케팅임. 정확히 풀면 — 잘 셋업된 MCP 환경 + Plan Mode로 정의된 작업 + 도메인을 아는 사람의 follow-up 세 개가 다 갖춰져야 가능. 하나라도 빠지면 그냥 더 비싼 ChatGPT 됨.
그리고 셋업 30분, 분석 30분, 디버깅 1시간이 현실적 시간 분포라고 본인은 추정함. 시연 영상의 30분 컷에 너무 의미 부여 안 하는 게 좋음.

댓글
NEXT_PUBLIC_GISCUS_*환경변수 구성 필요)