Data Agent를 “LLM이 SQL을 잘 짜는 도구”로 보면 제품은 금방 막힌다. 실제 업무 요청은 “지난달 매출 왜 떨어졌어?”, “아까 결과에서 조건 하나만 바꿔줘”, “파일로 줄 수 있어?”, “대시보드에 넣어도 돼?”처럼 분석, 대화 상태, 권한 경계, 산출물 형태가 섞여 있다. 이 문제를 모델 성능이나 긴 프롬프트로 해결하려 하면 정책은 흐려지고 재현성은 떨어진다.
핵심은 LLM을 중심에 두는 것이 아니라 workflow를 중심에 두는 것이다. 지표가 모호하면 멈춰서 묻고, 후속 요청이면 이전 scope를 복원하며, 산출물이 시스템 반영을 요구하면 permission boundary를 확인해야 한다. 좋은 Data Agent는 답변을 생성하는 봇이 아니라 분석 과정을 안전하게 진행하는 workflow runner에 가깝다.
근거
원문은 Data Agent가 LLM에서 출발하면 안 되며, workflow가 먼저 있고 LLM은 일부 판단과 생성을 맡는 구성요소여야 한다고 말한다.
Data Agent는 LLM에서 출발하면 안 됩니다. Workflow가 먼저 있고, LLM은 그 workflow 안에서 일부 판단과 생성을 맡는 구성요소여야 합니다.
연결된 생각
- 20260630-data-agent-workflow-architecture — 이 통찰의 구조화된 개념 노트.
- 20260526-workflow-orchestration-is-the-real-ai-era-skill — 프롬프팅보다 workflow orchestration이 높은 레버리지라는 기존 생각과 연결된다.
- 20260605-process-beats-prompting — 정책을 프롬프트에 쌓기보다 프로세스와 테스트로 관리해야 한다는 관점과 이어진다.