데이터 분석을 위한 AI: 실제로 작동하는 것 (그리고 단순한 데모용 마법일 뿐인 것)

지난달 저는 한 창업자가 투자자들 앞에서 자신의 "AI 기반 분석 플랫폼"을 시연하는 것을 보았습니다. AI는 막대그래프를 한 문장으로 요약했습니다. 그 과정에는 세 번의 API 호출이 필요했습니다. 반면, 그 자리에 있던 실제 분석가들은 공개된 채용 공고, SEC 공시 자료, Glassdoor 데이터를 활용해 Claude를 사용하여 경쟁사의 가격 모델을 역설계(reverse-engineer)하고 있었으며, 이 작업은 단 한 오후 만에 끝났습니다. 데모에서 보여주는 것과 빌더(builders)들이 실제 현장에서 수행하고 있는 것 사이의 이러한 격차가 바로 이 포스트가 다루고자 하는 핵심입니다.

실제로 배포되어 사용 중인 유스케이스 (Use Cases)

감성 분석(sentiment analysis) 튜토리얼이나 "CSV에 질문하기" 같은 데모는 잊으십시오. 다음은 현재 개발자와 데이터 팀이 프로덕션(production) 환경에서 실제로 실행하고 있는 사례들입니다.

대규모 이상 징후 분류 (Anomaly triage at scale). 제가 아는 한 인프라 팀은 모든 모니터링 알림이 온콜(on-call) 엔지니어에게 전달되기 전에 LLM을 거치도록 경로를 설정합니다. 이 모델은 단순히 "CPU 스파이크 감지"라고 말하는 데 그치지 않습니다. 지난 72시간 동안의 관련 로그를 추출하고, 최근 배포(deploys) 내용과 상관관계를 분석하며, 3주 전에도 동일한 패턴이 나타났는지 확인한 뒤 두 문장으로 된 가설을 작성합니다. 그들의 평균 장애 복구 시간(mean time to resolution)은 40% 감소했습니다. AI가 분석 전체를 수행하는 것이 아닙니다. 분석의 _첫 20분_을 자동으로 수행하는 것입니다.

비정형-to-정형 파이프라인 (Unstructured-to-structured pipelines). 수천 개의 고객 지원 티켓, 영업 통화 녹취록, 또는 사용자 인터뷰 노트가 데이터베이스에 아무런 역할도 하지 못한 채 쌓여 있습니다. 이제 팀들은 기능 요청, 이탈 지표(churn indicators), 가격에 대한 이의 제기, 버그 보고와 같은 정형화된 신호(structured signals)를 추출하는 배치 작업(batch jobs)을 실행하고 있습니다. 완벽하지는 않습니다. 하지만 과거에 5명의 팀원이 수동 코딩을 통해 처리해야 했던 데이터셋을 이제는 단 한 명의 분석가가 관리할 수 있을 정도로 충분히 훌륭합니다.

코드 보조 EDA (Code-assisted EDA). 탐색적 데이터 분석 (Exploratory data analysis, EDA)은 과거에 수많은 Jupyter 셀, pandas 구문을 찾기 위한 끊임없는 구글링, 그리고 히스토그램을 뚫어지게 쳐다보는 과정을 의미했습니다. 이제 개발자들은 프롬프트를 통해 탐색을 수행하고, 상관관계 행렬 (correlation matrices)을 자동으로 생성하며, 분포가 무엇을 의미하는지에 대한 평이한 영어(plain-English) 해석을 얻습니다. 병목 현상은 "이 쿼리를 어떻게 작성할 것인가"에서 "실제로 어떤 질문을 던져야 하는가"로 이동했습니다.

한계점 (솔직한 평가)

실패 양상은 일관적이며, 이를 직접적으로 명시할 가치가 있습니다.

환각된 통계 (Hallucinated statistics). LLM (Large Language Model)에게 실제로 볼 수 없는 데이터를 분석하라고 요청하면, 모델은 자신 있게 숫자를 지어낼 것입니다. 이는 당연해 보이지만, 문체가 매우 권위적으로 들리기 때문에 사람들을 끊임없이 속이곤 합니다. 만약 당신의 파이프라인이 분석을 요청하기 전에 실제 검색된 데이터에 모델을 접지 (grounding)시키지 않는다면, 당신은 분석가가 아닌 '자신감 넘치는 헛소리꾼 (confident bullshitter)'을 만들고 있는 것입니다.

컨텍스트 윈도우 스래싱 (Context window thrashing). 실제 데이터셋은 컨텍스트 윈도우 (context window)에 다 들어가지 않습니다. 팀들이 단순히 CSV 파일을 붙여넣고 질문을 던지려 할 때 이 벽에 빠르게 부딪힙니다. 해결책(청킹 (chunking), 검색 (retrieval), 요약 계층 구조 (summarization hierarchies))은 존재하지만, 대부분의 튜토리얼이 완전히 생략해버리는 엔지니어링 복잡성을 추가합니다. 진지한 데이터 분석 워크플로우를 구축한다는 것은 검색 레이어 (retrieval layer) 또한 구축한다는 것을 의미합니다.

단일 모델 병목 현상 (Single-model bottlenecks). 모델마다 강점이 다릅니다. GPT-4o는 분류 (classification) 작업에 빠르고 저렴합니다. Claude는 긴 컨텍스트 추론 (long-context reasoning)과 미묘한 해석에 강합니다. Gemini는 거대한 컨텍스트 윈도우를 가지고 있습니다. 분석 파이프라인에 하나의 제공업체(provider)를 하드코딩하는 팀은 결국 단순한 작업에 과도한 비용을 지불하거나, 복잡한 작업에는 성능이 부족한 상황에 직면하게 됩니다.

아무도 말하지 않는 오케스트레이션 문제

진짜 어려운 부분은 바로 이것입니다: 데이터 분석은 단일 프롬프트로 이루어지는 경우가 거의 없습니다. 그것은 하나의 워크플로우 (workflow)입니다. 데이터를 검색하고, 정제하고, 통계적 변환 (statistical transforms)을 실행하고, 출력을 해석하고, 가설을 생성하고, 더 많은 데이터를 위해 다시 돌아가고, 요약을 작성하는 과정입니다.

각 단계는 서로 다른 모델, 서로 다른 도구, 또는 서로 다른 데이터 소스를 사용할 수 있습니다. 그리고 만약 세 번째 단계가 실패한다면, 재시도(retry)를 해야 할지, 경로를 재설정(reroute)해야 할지, 아니면 오류를 사람에게 알릴(surface) 것인지를 결정할 수 있어야 합니다.

대부분의 팀은 맞춤형 Python 스크립트, 흩어져 있는 API 호출, 그리고 요행을 바라는 마음을 덕테이프로 붙이듯 임시방편으로 이 과정들을 이어 붙이고 있습니다. 이는 작동할 때는 괜찮지만, 작동하지 않게 되는 순간이 오면 디버깅(debugging)은 악몽이 됩니다. 전체 워크플로(workflow) 전반에 걸쳐 어떤 일이 일어났는지 확인할 수 있는 단일 지점이 없기 때문입니다.

이 문제보다 앞서 나가는 빌더(builders)들은 AI 분석 파이프라인(AI analysis pipelines)을 데이터 파이프라인(data pipelines)과 동일하게 취급합니다. 즉, 명시적인 단계(explicit steps), 관찰 가능한 상태(observable state), 재시도(retries), 그리고 라우팅 로직(routing logic)을 적용합니다. 사고 모델(mental model)의 전환은 "AI를 호출한다"에서 "AI 노드(AI nodes)를 포함하는 워크플로를 실행한다"로 바뀌어야 합니다.

AI 분석 작업을 평가하기 위한 프레임워크 (A Framework for Evaluating AI Analysis Tasks)

LLM을 어떤 데이터 작업에 연결하기 전에, 다음 체크리스트를 통해 검토하십시오:

모델이 실제로 데이터를 볼 수 있는가?

• 데이터가 프롬프트(prompt)에 근거(grounded)되어 있는가, 아니면 도구 호출(tool call)을 통해 검색되는가?
• 데이터셋이 컨텍스트(context)에 담기에 충분히 작은가, 아니면 청킹(chunking)이나 RAG가 필요한가?
• 실제 소스 데이터와 대조하여 출력을 검증하고 있는가?

이 작업에 적합한 모델인가?

• 분류/추출(classification/extraction) 작업인가? (빠르고 저렴한 모델)
• 긴 컨텍스트 추론(long-context reasoning) 작업인가? (컨텍스트 최적화 모델)
• 코드 생성(code generation) 작업인가? (코딩 최적화 모델)

단발성(one-shot)인가, 아니면 워크플로(workflow)인가?

• 여러 개의 순차적인 단계가 필요한가?
• 분기(branches)나 조건부 로직(conditional logic)이 존재하는가?
• 어느 단계에서든 실패 시 재시도(retry)나 사람의 개입(human escalation)이 필요한가?

품질을 측정할 수 있는가?

• 평가를 위한 정답(ground truth)이 있는가?
• 입력, 출력, 그리고 지연 시간(latency)을 기록(logging)하고 있는가?
• 중요한 결과물에 대해 사람이 검토하는 단계가 있는가?

이 모든 질문에 "예"라고 답할 수 없다면, 당신은 AI 데이터 분석 도구를 만들고 있는 것이 아니라, 데모(demo)를 만들고 있는 것입니다.

AI Handler는 이를 어떻게 접근하는가

저는 지난 몇 달 동안 이 분야에서 제품을 만들어 왔으며, AI Handler를 이끄는 핵심 통찰은 간단합니다. 바로 워크플로 계층 (workflow layer)이 곧 제품이라는 점입니다.

제가 목격한 모든 진지한 AI 데이터 분석 유스케이스 (use case)는 모델 수준이 아니라 오케스트레이션 (orchestration) 수준에서 무너집니다. 팀들은 인프라가 아닌 애플리케이션 코드에 포함되어서는 안 될 라우팅 로직 (routing logic), 재시도 처리 (retry handling), 멀티 모델 디스패치 (multi-model dispatch), 그리고 관측성 (observability) 도구를 재발명하는 데 수 주를 허비합니다.

AI Handler는 이 문제를 해결하기 위해 특별히 설계된 통합 AI 워크플로 (workflow) 도구입니다. 여러분은 분석 파이프라인 (analysis pipeline) — 어떤 단계가 어떤 모델을 호출하는지, 어떤 데이터가 언제 검색되는지, 실패는 어떻게 처리되는지, 출력값은 어떻게 로그로 남기는지 — 을 정의하며, Handler는 실행, 관측성, 그리고 라우팅을 관리합니다. 특정 제공업체(provider)에 종속되지 않습니다. 함수를 조합하는 것과 동일한 방식으로 모델을 조합할 수 있습니다.

특히 데이터 분석의 경우, 이는 초기 분류에는 저렴한 모델을 사용하고, 복잡한 추론 단계는 컨텍스트 창이 긴 (longer-context) 모델로 라우팅하며, 다양한 분석 관점을 위해 병렬 브랜치 (parallel branches)를 실행하고, 최종 종합 결과물을 인간 검토자에게 전달하는 워크플로를 구축할 수 있음을 의미합니다. 이 모든 과정은 사후에 덧붙여진 것이 아니라, 전체 로깅과 재시도 기능이 내장되어 있습니다.

목표는 진지한 유스케이스 (데모용이 아닌 실제로 배포되는 것들)를 더 빠르게 구축하고 더 쉽게 유지 관리할 수 있도록 만드는 것입니다.

AI Handler는 제가 만들고 있는 통합 AI 워크플로 도구입니다. 2026년 6월 출시 예정입니다. 베타 액세스 권한을 원하시면 ceo@eternalsix.com으로 이메일을 보내주세요.