엑셀 파일 하나 던져주고 "이거 분석해서 그래프 그려줘"라고 물어본 적 있으세요?
ChatGPT나 Claude의 코드 인터프리터가 그럴듯한 표와 차트를 뽑아주긴 하는데, 막상 숫자를 검증해보면 미묘하게 틀린 경우가 꽤 많아요. 데이터 분석 자동화 커뮤니티에서도 "결과는 빠른데 믿고 그대로 쓰기엔 불안하다"는 얘기가 자주 나옵니다. 그래서 어느 시점부터는 직접 Python 스크립트를 짜서 데이터를 처리하고 대시보드까지 만드는 쪽으로 넘어가는 사람들이 늘고 있어요. 왜 그런 흐름이 생기는지, 그리고 실제로 어떻게 엔드투엔드 파이프라인을 구성하는지 짚어볼게요.
코드 인터프리터의 기술적 한계, 어디까지 믿을 수 있을까
ChatGPT의 Advanced Data Analysis(구 코드 인터프리터)는 편하긴 한데 제약이 꽤 명확해요. 업로드 가능한 단일 파일은 최대 512MB지만, CSV는 데이터 복잡도에 따라 실질적으로 50MB 정도부터 처리가 버거워집니다. 대화 한 번에 파일도 최대 10개(파일 분석 GPT는 20개)까지만 올릴 수 있고요. (출처: Obot AI)
작업이 60초를 넘기면 타임아웃이 나고, 요청은 순차 처리라 여러 작업을 동시에 돌릴 수 없어요. 지원 언어도 Python 하나뿐입니다.
근데 진짜 문제는 용량이나 시간 제한이 아니에요. 정확도 쪽이 더 뼈아픕니다. 데이터 과학 코드 생성 능력을 측정하는 DA-Code 벤치마크에서 GPT-4는 코드를 끝까지 실행하는 완료율은 99.4%였지만, 실제 정답 기준 총점은 30.5%에 그쳤어요. GPT-4o는 완료율 97.4%에 총점 29.1%, Claude-3-Opus는 완료율 97.7%에 총점 27.6%였습니다. (출처: arXiv, DA-Code 벤치마크)
코드는 거의 다 돌아가는데, 정작 맞는 답을 내는 비율은 30% 안팎이라는 거예요. 이게 말이 되냐고요? 실제로 그렇습니다. Holistic Agent Leaderboard의 SciCode 벤치마크에서도 2025년 8월 기준 Claude Opus 4.1이 7.7%, GPT-4.1이 6.2% 정확도에 그쳤어요. 작업이 복잡해질수록 코드 실행 성공률과 실제 분석 정확도 사이 간극이 크게 벌어지는 거죠.
Python으로 직접 짜는 엔드투엔드 파이프라인, ETL부터 대시보드까지
그래서 결국 직접 Python 스크립트로 파이프라인을 짜는 쪽으로 넘어가는 거예요. 구조는 ETL(추출-변환-적재)을 따릅니다.
추출(Extract) 단계에서는 pandas의 read_csv 같은 함수로 데이터를 읽어 데이터프레임을 만들어요. 변환(Transform) 단계에서는 컬럼명을 통일하고 데이터 타입을 정리하고, 클리닝·집계·필터링을 수행합니다. 적재(Load) 단계에서는 처리된 데이터를 저장하거나 BI 도구로 내보내 대시보드를 만들어요. (출처: hevodata.com)
시각화는 Matplotlib, Seaborn, Plotly, Bokeh, Dash 같은 라이브러리로 처리하고, 데이터베이스·API·CSV·Excel·JSON과 연동해 실시간 데이터까지 붙일 수 있어요. 스크립트는 Windows 작업 스케줄러나 Unix cron job으로 정기 실행을 걸어두고, 더 복잡한 파이프라인은 Apache Airflow로 오케스트레이션합니다. Airflow는 Python DAG를 직접 짜야 해서 손이 더 가지만, 그만큼 커스터마이징이 자유롭다는 평가예요.
대시보드 프레임워크 선택을 두고는 늘 Streamlit과 Dash가 비교 대상이에요.
| 항목 | Streamlit | Plotly Dash |
|---|---|---|
| 학습 난이도 | 낮음, 선형 스크립트 모델 | 높음, 콜백 구조 이해 필요 |
| 구조 | 단순 Python 스크립트 | Flask + React.js + Plotly.js |
| 제어 수준 | 빠른 프로토타입에 적합 | 세밀한 상호작용 제어 가능 |
| 적합 상황 | 일반 대시보드 약 80% | 다중 컴포넌트 독립 업데이트 필요 시 |
일반적인 대시보드의 80%는 Dash가 제공하는 고급 기능까지는 필요 없다는 분석이 많아요. (출처: usedatabrain.com) 그래서 처음 시작할 땐 Streamlit으로 빠르게 붙여보고, 콜백 단위로 정밀하게 제어해야 할 일이 생기면 그때 Dash로 옮기는 흐름이 자연스러워요.
자연어 질의가 필요하면 LangChain의 create_pandas_dataframe_agent()를 얹는 방법도 있어요. 사용자가 자연어로 물으면 에이전트가 pandas 코드로 변환해서 실행하고, 그 결과를 다시 자연어로 돌려주는 구조거든요. 실행된 코드가 그대로 노출되니까 검증하기도 수월합니다.
보안 이슈와 시장 규모, 그냥 넘길 문제는 아니에요
데이터 분석 자동화 관련 포럼에서 요즘 많이 나오는 우려가 하나 있어요. 코드 인터프리터에 업로드한 데이터가 안전한가 하는 부분이에요.
보안 연구원 요한 레버거는 Claude의 코드 인터프리터가 간접 프롬프트 인젝션을 통해 조작될 수 있고, 이를 이용해 채팅 기록이나 업로드된 문서, MCP 서버·구글 드라이브 연동 데이터 같은 민감 정보를 외부로 유출시킬 수 있다는 점을 밝혔어요. 데이터 유출 방지를 위한 기본 차단 규칙도 우회 가능했다고 합니다. (출처: CIO)
별도로 Check Point Research는 Claude Code에서 원격 코드 실행과 API 키 탈취가 가능한 취약점 3건을 찾아냈어요. 신뢰할 수 없는 저장소를 클론하거나 열기만 해도 공격이 성립하는 구조였는데, 현재는 패치가 완료된 상태입니다.
그럼에도 시장은 빠르게 커지고 있어요. AI 에이전트 시장 규모는 2025년 기준 약 76억 3,000만 달러로 추산되고, 2030년까지 연평균 45.8% 성장해 503억 1,000만 달러 규모에 이를 거라는 전망이 나옵니다(추정치는 기관별로 차이가 있어요). 기업 도입률도 무시할 수 없는데, 직원의 79%가 이미 소속 회사에서 AI 에이전트를 쓰고 있다는 조사도 있고요. 다만 5곳 중 4곳이 어떤 형태로든 도입은 했지만 실제 프로덕션에서 운영하는 곳은 9곳 중 1곳뿐이라는 점이 흥미로워요. (출처: DemandSage)
도입은 했는데 실전 투입은 안 됐다는 거죠. 이게 딱 코드 인터프리터의 현재 위치 같아요.
결국 코드 인터프리터는 보조 도구일 뿐이에요
정리하면, 코드 인터프리터는 빠른 탐색이나 간단한 시각화에는 충분히 괜찮은 도구예요.
근데 숫자 하나가 보고서에 그대로 들어가는 작업이라면 얘기가 달라져요. 정확도가 검증된 영역이 아니거든요.
직접 Python으로 ETL부터 짜고 Streamlit이나 Dash로 대시보드를 띄우는 방식이 손은 더 가지만, 적어도 어디서 숫자가 나왔는지는 끝까지 추적할 수 있어요. 보안 측면에서도 외부 서버에 데이터를 올리지 않고 로컬이나 사내 환경에서 돌릴 수 있다는 점이 꽤 큽니다.
편한 도구와 믿을 수 있는 도구는 다른 얘기예요. 그 사이 어딘가에서 균형을 잡는 게 결국 지금 데이터 분석 자동화가 놓인 자리인 것 같습니다.
참고: DA-Code 벤치마크(arXiv), CIO "클로드 AI 취약점" 보도