원문: https://blog.langchain.com/not-another-workflow-builder/
작성자: 해리슨 체이스(Harrison Chase)
LangChain 초기부터 저희가 가장 많이 받아온 요청 중 하나는 시각적 워크플로우 빌더에 대한 것이었습니다. 저희는 이 길을 가지 않았고, 대신 다른 이들(LangFlow, Flowise, n8n)이 저희를 기반으로 솔루션을 만들도록 했습니다. 어제 OpenAI가 개발자 데이에서 워크플로 빌더를 출시하는 것을 보고, 저희가 왜 지금까지 빌더를 만들지 않았는지, 그리고 저희가 더 흥미롭게 생각하는 다른 (관련된) 방향은 무엇인지에 대해 이야기해보면 좋겠다고 생각했습니다.
문제 정의
먼저, 노코드 워크플로 빌더가 해결하려는 문제가 무엇인지 명확히 짚고 넘어갈 필요가 있습니다. 가장 큰 동기는 비전문가도 에이전트를 만들 수 있게 하는 데 있습니다. 사람들이 이 기능에 관심을 갖는 데에는 크게 두 가지 이유가 있습니다.
- 많은 기업이 다른 기업에 비해 엔지니어링 인력이 부족합니다.
- 어떤 에이전트를 만들어야 하고, 그 에이전트가 무엇을 해야 하는지 아는 사람은 바로 비전문가인 경우가 많습니다.
물론 기술 사용자가 나중에 코드로 변환할 에이전트를 신속하게 프로토타이핑하는 것과 같은 다른 동기도 있습니다. 하지만 이 글에서는 조직의 모든 구성원이 엔지니어의 도움 없이 스스로 앱과 위젯을 만들 수 있도록 하는 것을 주된 동기로 가정하겠습니다.
워크플로우 대 에이전트
위에서 제가 의도적으로 사용한 두 단어는 “워크플로우”와 “에이전트”입니다. 저희는 이미 블로그 게시물 워크플로우를 지지하며에서 이 주제를 다룬 적이 있습니다(아이러니하게도, 워크플로우에 반대하는 OpenAI의 글에 대한 답변이었습니다).
개발자 커뮤니티는 대체로 에이전트에 대한 다음 정의에 의견을 모았습니다:
LLM 에이전트는 목표 달성을 위해 반복적으로 도구를 실행하는 시스템입니다.
워크플로는 자율성을 희생하는 대신 예측 가능성을 높이고, 에이전트는 예측 가능성을 희생하는 대신 자율성을 높입니다. 특히 에이전트 시스템을 구축할 때, 우리가 추구하는 것은 예측 가능성이나 자율성만으로는 보장할 수 없는 신뢰할 수 있는 좋은 결과입니다.
워크플로는 복잡합니다. 분기 로직, 병렬 실행, 다양한 경로를 포함하기 때문입니다. 이러한 복잡성은 워크플로의 “그래프”에 반영되고, 이 그래프는 특정 도메인 전용 언어(DSL)로 표현됩니다.
에이전트 역시 복잡한 로직을 포함할 수 있지만, 대조적으로 모든 로직은 자연어로 추상화되어 프롬프트에 반영됩니다. 따라서 에이전트의 전체 구조는 단순하지만(프롬프트 + 도구), 그 ‘프롬프트’는 종종 매우 복잡할 수 있습니다.
OpenAI의 에이전트 키트, 그리고 n8n, Flowise, LangFlow는 모두 에이전트 빌더가 아닌 시각적 워크플로우 빌더입니다.
시각적 워크플로 빌더의 문제점
그렇다면 이러한 맥락에서 워크플로 빌더의 문제점은 무엇일까요?
1. 시각적 워크플로 빌더는 진입 장벽이 ‘낮지 않습니다’.
대중을 위해 만들어졌음에도 불구하고, 비전문가가 사용하기에는 여전히 쉽지 않습니다.
2. 복잡한 작업은 시각적 빌더에서 관리하기에 너무 복잡해집니다.
일정 수준의 복잡성을 넘어서는 순간(그리고 이는 매우 빠르게 일어납니다), UI에서 관리해야 할 노드와 엣지가 뒤엉켜 엉망이 되어버립니다.
대안
목표는 (워크플로우든 에이전트든) ‘신뢰할 수 있는 좋은’ LLM 기반 시스템을 만드는 것입니다. 사람들이 LLM 기반 시스템으로 해결하려는 문제에는 복잡성이 낮은 것부터 높은 것까지 다양한 유형이 있습니다. 최적의 대안은 복잡성 수준에 따라 달라질 수 있습니다.
높은 복잡성: 코드로 구현하는 워크플로
복잡성이 높은 문제에서 일정 수준의 안정성을 확보하려면, 시스템은 단순한 에이전트를 넘어 워크플로의 요소를 포함해야 한다는 것을 알게 되었습니다. 이렇게 복잡성이 높은 문제에는 종종 복잡한 워크플로가 필요합니다. 이런 시나리오에서 수많은 분기 처리, 병렬 처리, 모듈화를 원한다면 코드가 최상의 선택입니다 (LangGraph가 바로 이를 위해 설계되었습니다).
전통적으로 이는 비전문가가 이런 유형의 문제에 접근하는 것이 사실상 불가능했음을 의미합니다. 하지만 코드 생성 비용이 0에 가까워지면서, 점점 더 많은 개발자들이 이러한 솔루션을 구축할 수 있게 될 것으로 기대합니다.
낮은 복잡성: 노코드 에이전트
복잡도가 낮은 사용 사례는 간단한 에이전트(프롬프트 + 도구)만으로도 안정적으로 해결할 수 있습니다. 이러한 에이전트를 노코드로 구축하는 것은 워크플로우를 노코드로 구축하는 것보다 훨씬 간단해야 합니다.
모델이 발전할수록, 이러한 에이전트가 해결할 수 있는 문제의 범위 또한 점점 더 넓어질 것으로 기대합니다.
양쪽에서의 압박
노코드 워크플로 빌더의 문제는 양쪽에서 압박을 받고 있다는 점입니다.
| 복잡성 수준 | 최적의 솔루션 |
|---|---|
| 낮음 | 노코드 에이전트 |
| 중간 | 노코드 워크플로 |
| 높음 | 코드로 구현하는 워크플로 |
저는 에이전트(프롬프트 + 도구)가 워크플로보다 노코드로 만들기가 훨씬 쉬워야 한다고 믿습니다. 저는 이러한 에이전트를 만들고, 수정하고, 훈련시키기 위한 모델, 에이전트 프레임워크, 인터페이스가 점점 더 발전할 것으로 기대합니다. 이는 곧 에이전트가 점점 더 많은 작업을 ‘신뢰할 수 있게 잘’ 수행할 수 있게 됨을 의미합니다.
반대로, 시각적 워크플로 빌더는 일정 수준의 복잡성을 넘어서면 관리가 불가능해집니다. 이에 대한 유일한 대안은 코드뿐입니다. 코드 작성은 역사적으로 소수의 인원에게만 국한되었고 진입 장벽도 상당히 높았습니다. 코드 생성 모델이 발전하고 생성 비용이 0에 가까워짐에 따라, 코드로 전환하는 결정은 점점 더 쉬워질 것으로 예상합니다.
흥미로운 과제들
분명히 말해, LLM 기반 워크플로 빌더를 대중화하는 데 큰 성과를 거둔 회사들이 있습니다(n8n, Flowise, LangFlow, Gumloop 등). 이들 중 다수는 제품-시장 적합성(PMF)을 찾아냈고, 오늘날 실재하는 문제들을 해결하며 비전문가도 멋진 결과물을 만들 수 있도록 힘을 실어주고 있습니다.
저는 단지 세상에 또 다른 워크플로 빌더가 필요하다고 생각하지 않을 뿐입니다. 오히려, 다음은 해결해야 할 흥미로운 과제라고 생각합니다:
- 어떻게 하면 코드 없이 신뢰할 수 있는 좋은 에이전트를 더 쉽게 만들 수 있을까요? 로우코드 워크플로가 아닌, 진짜 에이전트 말입니다!
- LLM 기반 워크플로/에이전트 작성 시, 코드 생성 모델의 성능을 어떻게 더 향상시킬 수 있을까요?