devway
홈전체 글태그

카테고리

  • 전체40
  • 인프라3
    • 하드웨어2
    • ubuntu1
  • AI34
    • 로컬 LLM8
    • AI 코딩 도구9
    • 컴퓨터 비전4
    • 디자인1
    • 이미지생성2
    • 데이터 아키텍쳐0
    • agent2
    • 모델3
  • Backend1
  • Architecture2
    • 분산 시스템1
    • 데이터0

태그

  • #로컬LLM9
  • #ClaudeCode9
  • #AI개발7
  • #LocalLLM6
  • #AI에이전트5
  • #에이전트4
  • #컴퓨터비전4
  • #MCP4
  • #LLM4
  • #RTX30904
  • #AI코딩4
  • #Anthropic4
  • #모델비교3
  • #객체탐지3
  • #로컬AI3
  • #딥러닝3
  • #개발도구3
  • #Gemma43
  • #이미지생성3
  • #백엔드3

구독

  • RSS
  • Sitemap
AI · 2026-05-04 · 11분

데이터 분석 워크플로우를 AI에 통째로 맡긴다는 흐름, 진짜 병목은 다른 데 있음

AI가 Google Drive에서 raw 데이터 찾아 BigQuery에 적재하고 분석 리포트까지 30분 안에 뽑아낸다는 시연이 도는데, 직접 MCP 깔아본 입장에서 보면 30분에서 빠진 시간이 더 길다. Plan Mode가 진짜 핵심인 이유, 첫 패스가 얕은 이유, 그리고 142GB짜리 로그 파일 일화까지.

목차
  • MCP 셋업이 진짜 시간을 먹음
  • 정작 진짜 핵심은 Plan Mode
  • 첫 패스 분석은 항상 얕음
  • 그리고 회사 데이터에는 못 씀
  • 잡담: 142GB짜리 로그 파일
  • 한계 — 이 글에서 안 다룬 것들
  • 마무리
셋업·계획·반복 세 기둥 사이에 선 개발자를 표현한 컨셉 일러스트

영어권에서 요즘 자주 보이는 시연 패턴이 있음. AI가 데이터 분석을 끝에서 끝까지 다 한다는 거. Google Drive에서 raw 데이터 찾기 → 옛날 GitHub repo 참고해서 파싱 스크립트 작성 → BigQuery에 적재 → SQL 돌려서 리포트 생성. 사람은 질문 던지고 검토만. 30분 컷.

들으면 좀 멋지죠. 근데 비슷한 셋업 직접 만져본 입장에서는 "30분"이라는 숫자에서 빠져 있는 게 너무 많음. 그 빠진 부분이 사실은 도입 가능 여부를 결정함.

AI 에이전트가 터미널에서 실행되는 야간 개발 작업 환경

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 양쪽 다 있는 기능인데 활용도는 의외로 낮은 듯.

이거 진짜 안 쓰면 손해임.

Plan Mode에서 단계별 실행 트리로 분기되는 워크플로우 시각화

첫 패스 분석은 항상 얕음#

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에도 권한 관리랑 로그 핸들링 가이드가 의외로 상세한데, 매뉴얼이라 안 읽고 넘기는 사람이 많은 듯. 사고 한 번 나봐야 챙겨 보게 되는 부분.

거대한 종이 더미와 작은 노트북으로 시각화한 142GB 로그 파일

한계 — 이 글에서 안 다룬 것들#

  • 비용: 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분 컷에 너무 의미 부여 안 하는 게 좋음.

터미널과 BigQuery 출력을 보며 작업하는 손과 키보드 클로즈업
  • #ClaudeCode
  • #Codex
  • #MCP
  • #BigQuery
  • #AI에이전트
  • #데이터분석
  • #DataScience
  • #AIWorkflow
  • #PlanMode
D

devway

AI 도구로 실제 서비스 운영하면서 손에 쥔 결과만 적는 1인 개발 노트. RTX 3090 + 로컬 LLM 환경에서 직접 굴려보고 글로 옮긴다.

소개전체 글RSS

관련 글

AI/agent2026-05-09

RAG는 죽었다는 글이 많은데 한국어 환경에서는 좀 다른 얘기

영어권에서 자주 도는 "RAG 파이프라인은 죽었다, 에이전트가 검색이다" 흐름을 한국어 환경 관점에서 다시 따져봤음. hybrid retrieval의 BM25는 한국어 형태소 분석을 별도로 붙여야 하고, 한국어 임베딩 모델 선택지는 영어만큼 풍부하지 않으며, MCP 채택은 한국에서 아직 초기 단계라 영어권 thesis를 그대로 옮기기 어려운 변수들이 붙는다는 정리.

  • #RAG
  • #AI에이전트
  • #하이브리드검색
  • +6
AI2026-05-03

Google AI 자격증 자랑글에서 진짜 건진 건 따로 있음

"AI 자격증 주말에 따버렸음" 류의 자랑글이 콘텐츠 포맷으로 굳었어요. 그 중 하나를 끝까지 읽고 정리해봤는데, 자격증 자체보다 글 안에 묻혀 있던 한 줄(Anthropic Academy)이 훨씬 쓸모 있었습니다. 한국 개발자 입장에서 두 옵션을 어떻게 비교하면 될지, 그리고 "AI 리터러시 = 새 Excel" 비유의 게으른 부분에 대한 솔직한 정리.

  • #GoogleAI
  • #AnthropicAcademy
  • #AI자격증
  • +7
AI/AI 코딩 도구2026-04-09

Claude Code 4.7 올리고 청구서 2배 된 진짜 이유

Sonnet 4.7로 업그레이드한 뒤 Claude Code 토큰 사용량이 갑자기 폭증했다면, 모델 탓이 아닙니다. 진짜 원인은 백엔드 MCP 서버가 컨텍스트 윈도우에 쓰레기를 자꾸 부어넣는 구조. 실측 벤치마크와 InsForge 같은 컨텍스트 엔지니어링 도구로 토큰비 2~3배 줄이는 구조를 정리했어요.

  • #ClaudeCode
  • #AI개발
  • #ContextEngineering
  • +3

댓글

(댓글 미설정 — NEXT_PUBLIC_GISCUS_* 환경변수 구성 필요)
소개개인정보처리방침RSSSitemapaickywayconvertprompt
© devway