FlowBot — '텍스트 그래디언트'로 LLM 워크플로우 자체를 학습하는 이중 최적화

NAS for LLMs

딥러닝 역사에서 가장 "인간의 직관을 줄여준" 순간이 뭐였냐고 물으면, 많은 연구자가 NAS(Neural Architecture Search)를 꼽는다. 사람이 일일이 레이어 수, 커널 크기, 스킵 커넥션을 설계하던 시절이 있었는데, NAS는 그 설계 자체를 검색 문제로 바꿔 버렸다. 결과적으로 EfficientNet 같은 구조가 나왔고, 사람이 생각하지 못한 조합이 더 잘 작동한다는 걸 증명했다.

지금 LLM 생태계도 비슷한 병목에 걸려 있다. 프롬프트를 어떻게 쓸지, LLM 호출을 몇 단계로 나눌지, 중간에 어떤 도구를 끼울지 -- 이 모든 걸 사람이 직접 짜고 있다. 체인오브소트 한 줄 바꿨더니 성능이 5% 떨어지고, RAG 파이프라인에 요약 노드 하나 추가했더니 갑자기 좋아지고. 이 과정이 본질적으로 "사람이 신경망 구조를 수작업으로 짜던 시절"과 똑같다.

FlowBot은 이 문제에 대한 직접적인 답이다. LLM 워크플로우의 구조(어떤 노드가 어떤 순서로 연결되는지)와 각 노드의 내용(프롬프트, 도구 선택)을 동시에 학습하겠다는 논문이다. 비유하자면 NAS가 CNN 아키텍처를 자동으로 찾아냈듯, FlowBot은 LLM 파이프라인 아키텍처를 자동으로 찾아낸다.

쉽게 말하면 -- 사람이 짠 파이프라인을 왜 학습으로 찾나

요즘 LLM 기반 시스템 개발은 대부분 이런 식이다. "먼저 사용자 쿼리를 분류하고, 분류 결과에 따라 RAG를 호출하거나 요약기를 호출하고, 마지막에 응답을 생성한다." 이 흐름을 개발자가 직접 설계한다. 문제는 이게 최적인지 아무도 모른다는 거다. 노드를 하나 더 추가하면 좋을 수도 있고, 순서를 바꾸면 더 나을 수도 있다. 하지만 경우의 수가 폭발적이라 사람이 다 시도해 볼 수 없다.

기존에도 이 문제를 풀려는 시도가 있었다. DSPy는 프롬프트 최적화를 자동화했고, AFlow는 워크플로우 구조 자체를 코드 생성으로 탐색했다. 하지만 둘 다 한계가 뚜렷했다. DSPy는 워크플로우 구조는 사람이 고정해야 했고, AFlow는 구조를 바꿀 수 있지만 내부 프롬프트 최적화가 약했다. 구조와 내용을 동시에 최적화하는 프레임워크가 없었다.

FlowBot이 제안하는 해법은 이중 최적화(bilevel optimization)다. 바깥 루프가 워크플로우 구조를 탐색하고, 안쪽 루프가 각 노드의 프롬프트와 도구를 최적화한다. 이 두 루프가 번갈아 돌면서, 구조가 바뀌면 내용도 거기에 맞춰 재조정되고, 내용이 최적화되면 그 결과가 구조 탐색의 신호로 반영된다.

연구진 / 출처

이 논문은 네이버 서치 US(Naver Search US)의 Hongyeon Yu, Young-Bum Kim과 MIT의 Yoon Kim이 공동으로 작성했다. 2026년 4월 29일 arXiv에 공개됐다. Yoon Kim은 MIT에서 자연어 처리 연구를 이끌고 있는 인물로, 이전에도 텍스트 생성과 구조 학습 분야에서 영향력 있는 논문을 여러 편 발표한 바 있다. 네이버 서치 US는 네이버의 미국 검색 AI 연구 조직으로, 검색 파이프라인 자동화에 직접적인 실무 수요를 가지고 있다. 산업체의 실전 수요와 학계의 최적화 이론이 결합된 연구라고 볼 수 있다.

이중 최적화 구조 -- 외부 루프와 내부 루프

FlowBot의 핵심은 두 개의 중첩된 최적화 루프다. 이걸 이해하면 논문의 90%를 이해한 거다.

외부 루프(outer loop)는 워크플로우의 "스케치"를 관리한다. 스케치란 노드의 종류(LLM 호출, 도구 호출, 분기, 병합 등)와 노드 간의 연결 구조를 의미한다. 외부 루프는 현재 스케치로 태스크를 수행한 결과를 보고, 구조를 수정한다. 예를 들어 "요약 노드가 불필요하게 정보를 잃고 있으니 삭제하자" 또는 "검색 노드 뒤에 검증 노드를 추가하자" 같은 구조적 변경을 수행한다. 이 과정은 NAS에서 아키텍처를 탐색하는 것과 정확히 대응된다.

내부 루프(inner loop)는 외부 루프가 정한 스케치를 받아서, 각 노드의 세부 사항을 최적화한다. 구체적으로는 각 LLM 호출의 프롬프트, 사용할 도구, 파라미터 등을 조정한다. 이 최적화에 사용되는 핵심 메커니즘이 바로 "텍스트 그래디언트"인데, 이건 다음 섹션에서 자세히 다룬다.

두 루프의 관계를 정리하면 이렇다. 외부 루프가 "어떤 구조로 일할지"를 정하고, 내부 루프가 "그 구조 안에서 각 부품을 어떻게 세팅할지"를 정한다. 내부 루프 최적화가 끝나면, 그 결과(성능)가 외부 루프에 피드백된다. 외부 루프는 이 피드백을 보고 구조를 유지하거나 변경한다. 이 과정이 반복되면서 구조와 내용이 함께 수렴한다.

전통적인 기계학습에서 비유하면, 외부 루프는 하이퍼파라미터 튜닝(또는 NAS)에 해당하고, 내부 루프는 모델 파라미터 학습에 해당한다. FlowBot이 이 구조를 LLM 시스템 수준으로 끌어올린 것이다.

텍스트 그래디언트 -- 역전파를 자연어로

내부 루프의 핵심 메커니즘인 텍스트 그래디언트(textual gradients)는 이 논문에서 가장 인상적인 아이디어다. 전통적 신경망에서 역전파(backpropagation)는 손실 함수에서 각 파라미터까지 기울기를 수학적으로 계산하는 과정이다. 문제는 LLM 워크플로우에서는 이 계산이 불가능하다는 거다. 각 노드가 자연어를 입출력하고, 도구 호출까지 섞여 있으니 미분 가능한 함수가 아니다.

FlowBot은 이 문제를 자연어 피드백으로 우회한다. 텍스트 그래디언트의 작동 방식은 다음과 같다. 먼저 워크플로우를 실행해서 각 노드의 입력과 출력을 기록한다. 그 다음 최종 출력과 정답(또는 평가 기준)을 비교해 자연어로 된 "손실"을 생성한다. 예를 들어 "최종 응답이 질문의 두 번째 조건을 무시했다"는 식이다. 이 자연어 손실을 마지막 노드부터 첫 번째 노드까지 역방향으로 전파한다. 각 노드에서 LLM이 "이 노드의 입력, 출력, 그리고 다음 노드에서 전달된 피드백을 고려할 때, 이 노드의 프롬프트를 어떻게 수정해야 하는가?"를 판단한다.

중요한 건 이 과정이 레이어 바이 레이어(layer-by-layer)로 진행된다는 점이다. 마치 신경망에서 기울기가 출력층에서 입력층까지 체인 룰을 따라 역전파되듯, FlowBot에서는 자연어 피드백이 마지막 노드에서 첫 번째 노드까지 순차적으로 전파된다. 각 노드는 자기 다음 노드로부터 받은 피드백만 보고 자기 프롬프트를 수정하므로, 전체 워크플로우의 복잡한 상호작용이 로컬 수정의 연쇄로 분해된다.

이게 왜 중요하냐면, 기존 접근법들은 대부분 "전체 출력이 틀렸으니 전체 프롬프트를 수정해라"는 식의 글로벌 피드백만 사용했다. 노드가 5개인 파이프라인에서 3번째 노드에 문제가 있으면, 글로벌 피드백으로는 어떤 노드를 고쳐야 하는지 특정하기 어렵다. 텍스트 그래디언트는 이 문제를 해결한다. 역전파처럼 각 노드에 국소적인 수정 신호를 전달하기 때문이다.

결과 표

논문에서 보고된 벤치마크 결과를 정리하면 다음과 같다.

벤치마크	FlowBot	AFlow	ReAct (단일 호출)	CoT (단일 호출)
HotpotQA	최고 성능	2위	3위	4위
DROP	최고 성능	2위	4위	3위
MATH	최고 성능	2위	3위	4위
GSM8K	2위	최고 성능	3위	4위
FEVER	최고 성능	2위	3위	4위
TriviaQA	2위	최고 성능	4위	3위

FlowBot은 6개 벤치마크 중 4개에서 AFlow를 이겼다. AFlow가 이긴 2개 벤치마크(GSM8K, TriviaQA)에서도 차이가 크지 않았다. 특히 HotpotQA와 DROP처럼 다단계 추론이 필요한 태스크에서 우위가 뚜렷했는데, 이는 워크플로우 구조 최적화의 이점이 복잡한 태스크에서 더 크게 나타난다는 걸 의미한다.

단일 LLM 호출 기반인 ReAct이나 CoT에 비해서는 격차가 더 컸다. 워크플로우 자체를 학습하는 방식이 "좋은 프롬프트를 쓰는 것"만으로는 도달할 수 없는 성능 영역을 열어준다는 걸 보여준다.

왜 흥미로운지 -- DSPy, AFlow 이후의 다음 단계

이 논문이 기존 연구와 다른 지점은 "최적화 대상의 범위"에 있다. DSPy는 프롬프트 최적화에 집중했다. 워크플로우 구조는 사람이 정의해야 했고, 그 구조 안에서 프롬프트만 자동으로 튜닝했다. AFlow는 한 단계 더 나아가 워크플로우 구조 자체를 탐색했지만, 코드 생성 기반이라 탐색 공간이 상대적으로 제한적이었고 내부 프롬프트 최적화와의 결합이 느슨했다.

FlowBot은 구조 탐색(외부 루프)과 프롬프트 최적화(내부 루프)를 하나의 수학적 프레임워크로 묶었다. 이중 최적화라는 프레임워크 덕분에 두 최적화가 서로를 강화하는 방식으로 작동한다. 내부 루프가 각 구조를 공정하게 평가할 수 있으니 외부 루프의 구조 선택이 더 정확해지고, 외부 루프가 좋은 구조를 제시하니 내부 루프의 최적화가 더 효과적으로 작동한다.

더 넓은 맥락에서 보면, 이건 LLM 시스템 개발 방법론 자체가 변하고 있다는 신호다. "사람이 좋은 파이프라인을 설계한다"에서 "기계가 파이프라인을 학습한다"로의 전환이다. NAS가 CNN 아키텍처 설계를 바꿨듯, FlowBot 류의 접근법이 LLM 시스템 설계를 바꿀 가능성이 있다.

물론 NAS가 나왔다고 사람이 설계한 아키텍처가 완전히 사라지지는 않았다. 마찬가지로 FlowBot이 모든 수동 파이프라인 설계를 대체하지는 않을 거다. 하지만 "기본 구조를 자동으로 찾고, 사람이 거기서 미세 조정한다"는 워크플로우는 충분히 현실적이다. 그리고 그 방향으로의 첫 번째 설득력 있는 프레임워크가 바로 FlowBot이다.

한계와 전망

아직 해결되지 않은 문제도 있다. 첫째, 최적화 비용이 상당하다. 외부 루프와 내부 루프를 반복하면서 많은 LLM 호출이 발생한다. 워크플로우 하나를 최적화하는 데 드는 토큰 비용이 실무에서 감당할 수 있는 수준인지는 추가 검증이 필요하다. 둘째, 벤치마크가 학술 태스크에 집중돼 있다. 실제 프로덕션 워크플로우(예: 고객 지원 봇, 코드 리뷰 파이프라인)에서의 효과는 아직 미지수다. 셋째, 텍스트 그래디언트의 품질이 피드백을 생성하는 LLM의 능력에 의존한다. 피드백 LLM이 잘못된 진단을 하면 최적화 방향 자체가 틀어질 수 있다.

그럼에도 연구 방향 자체는 명확하게 가치가 있다. LLM 시스템이 점점 복잡해지면서, 수동 파이프라인 설계의 한계가 더 뚜렷해지고 있기 때문이다. FlowBot이 제안한 이중 최적화 프레임워크는 이 문제를 풀기 위한 설득력 있는 출발점이다. 후속 연구에서 비용 효율성과 실전 적용 가능성이 개선된다면, LLM 워크플로우 개발의 패러다임이 바뀔 수 있다.

참고 자료

• 원문 논문: FlowBot: Bilevel Optimization for LLM Workflow Induction
• arXiv HTML 전문: https://arxiv.org/html/2604.26258
• DSPy 프레임워크: https://github.com/stanfordnlp/dspy
• AFlow 논문: AFlow: Automating Agentic Workflow Generation (2024)