[Data Agent 만드는 법 - 3탄] LLM model이 아니라, Workflow 설계가 핵심
Claude를 써야 할까? GPT를 써야 할까?
하지만 이제 모델 성능은 상향평준화 되어있습니다. Data Agent를 실제 조직에서 운영하려면, 더 중요한 질문은 따로 있습니다.
사용자의 요청이 들어왔을 때 어떤 workflow를 탈 것인가?
Data Agent는 LLM에서 출발하면 안 됩니다. Workflow가 먼저 있고, LLM은 그 workflow 안에서 일부 판단과 생성을 맡는 구성요소여야 합니다.
가장 단순한 Data Agent는 SQL Bot입니다. 사용자가 질문하면 LLM이 SQL을 만들고, 쿼리를 실행한 뒤, 결과를 요약합니다.
하지만 실제 업무 요청은 그렇게 깔끔하지 않습니다.
“지난달 매출 왜 떨어졌어?” “아까 뽑은 것에서 조건 하나만 바꿔줘.” “파일로 줄 수 있어?” “이건 대시보드에 바로 넣어도 돼?”
이 요청들은 단순 SQL 생성 문제가 아닙니다. 분석 workflow의 문제입니다.
Data Agent는 매번 판단해야 합니다.
어떤 data source를 우선할 것인가. 지표 정의가 모호하면 바로 쿼리할 것인가, 먼저 물어볼 것인가. 이전 대화의 기간, 필터, 지표를 이어받아야 하는가. 결과만 전달하면 되는가, 원인 분석까지 해야 하는가. 파일 생성이나 대시보드 반영 요청이 permission boundary를 넘지는 않는가.
이런 판단을 전부 프롬프트에 넣는 방식으로 해결하려고 하면 한계가 빨리 옵니다. 프롬프트는 길어지고, 정책은 흐려지고, 재현성은 떨어집니다.
무엇보다 테스트하기 어렵습니다. 그래서 Data Agent는 chatbot처럼 만들기보다, 데이터 파이프라인처럼 설계해야 합니다.
저는 이 지점에서 LangGraph가 유용하다고 봅니다. LangGraph는 agent의 판단을 node로 나누고, state transition을 명시하고, 각 node를 테스트할 수 있게 해줍니다.
dbt가 SQL 파이프라인을 하나의 거대한 쿼리로 두지 않고 model로 나누고, dependency를 명시하고, test를 붙이는 것과 비슷합니다.
Data Agent workflow도 같은 질문을 가져야 합니다.
이 node는 어떤 state를 입력으로 받는가? 어떤 판단을 수행하는가? 다음 node는 무엇인가? 이 판단은 regression test를 통과하는가?
예를 들어 사용자가 “지난달 전환율 좀 봐줘”라고 했다고 해보겠습니다.
좋은 Data Agent는 바로 SQL을 실행하지 않습니다.
MessageReceived → MetricCheck → NeedClarification
전환율 기준이 모호하다면 먼저 물어야 합니다.
“어떤 전환율 기준으로 볼까요?”
반대로 사용자가 “아까 결과에서 국가만 추가해줘”라고 하면 최신 메시지만 보면 안 됩니다.
FollowUpDetected → RestorePreviousScope → ApplyChangedDimension → ReAnalyze
이전 분석의 기간, 지표, 필터는 유지하고, 변경된 조건만 반영해야 합니다.
결국 Data Agent의 품질은 어떤 LLM model을 쓰느냐만으로 결정되지 않습니다. 더 중요한 것은 요청을 어떤 workflow로 해석하고, 어디서 멈추고, 무엇을 검증하고, 어떤 node에서 LLM을 사용할지 설계하는 것입니다.
LLM은 핵심 부품입니다. 하지만 시스템의 중심은 workflow여야 합니다.
원문: LinkedIn