동적 계획이 어려운 중간 지점인 이유
AI 에이전트 생태계는 두 진영으로 나뉘었고, 둘 다 쉬운 길을 선택했습니다. 전통적인 워크플로우 엔진 — Dify, n8n, Coze — 은 정적 오케스트레이션을 선택했습니다: 고정된 실행 경로를 가진 시각적 드래그 앤 드롭 플로우차트입니다. 이는 무지가 아니었습니다. 엔터프라이즈 고객은 결정론을 요구하고(동일한 입력, 안정적인 출력), 정적 그래프가 이를 제공합니다. 극단의 다른 쪽에는 완전히 자율적인 에이전트(AutoGPT와 그 후손들)가 있었는데, 이들은 엔드투엔드 자율성을 약속했지만 실용성이 없었습니다: 신뢰할 수 없는 작업 분해, 폭발적인 토큰 비용, 그리고 누구도 예측하거나 디버깅할 수 없는 동작입니다. 최적의 지점은 좁지만 실제로 존재합니다. 단순한 작업은 계획자가 필요하지 않습니다. 수십 개의 상호 의존적인 단계가 필요할 정도로 복잡한 작업은 현재의 LLM을 압도합니다. 하지만 그 사이에는 풍부한 문제 클래스가 있습니다 — 명확한 병렬 부작업을 가지고 있으면서 하드코딩하기에는 번거롭지만 LLM이 분해하기에는 충분히 다루기 쉬운 작업들입니다. 동적 DAG 계획은 정확히 이 영역을 목표로 합니다: 모델이 런타임에 실행 그래프를 제안하고, 프레임워크가 구조를 검증하고 최대 동시성으로 실행합니다. 드래그 앤 드롭도 없고, YOLO 자율성도 없습니다.모델 개선에 대한 베팅
몇 달마다 기초가 바뀐다 — GPT-4, 함수 호출, Claude 3, MCP 프로토콜. 움직이는 지반 위에 경직된 추상화를 구축하는 것은 위험하다. LangChain의 과도한 추상화는 이 분야의 모든 사람이 내재화한 경고 사례다. FIM One은 반대의 접근 방식을 취한다: 최소한의 추상화, 최대한의 확장성. 프레임워크는 오케스트레이션, 동시성, 관찰성을 담당한다. 지능은 모델에서 나오며, 모델은 계속 개선된다. 오늘날 LLM 작업 분해 정확도는 비자명한 목표에 대해 약 70-80% 수준이다. 이것이 90% 이상에 도달하면, 동적 계획의 “최적 지점”이 극적으로 확장된다 — 어제는 너무 복잡했던 문제들이 내일은 해결 가능해진다. FIM One의 DAG 프레임워크는 배관을 다시 작성하지 않고도 그 확장되는 가치를 포착하도록 설계되었다.ReAct와 DAG 계획이 구식이 될까요?
ReAct는 사라지지 않을 것입니다 — 모델 내부에 흡수될 것입니다. 비유를 들자면: TCP 핸드셰이크를 손으로 작성하지는 않지만, TCP가 사라진 것은 아닙니다. 운영 체제에 흡수되었을 뿐입니다. 모델이 충분히 강력해지면, think-act-observe 루프는 외부 프레임워크 코드가 아닌 모델 내부의 암묵적 동작이 됩니다. 이미 일어나고 있습니다: Claude Code는 본질적으로 루프가 외부 하네스가 아닌 모델 자체에 의해 구동되는 ReAct 에이전트입니다. DAG 계획의 지속적인 가치는 “약한 모델이 작업을 분해하도록 돕는 것”이 아닙니다 — 그것은 동시 스케줄링입니다. 무한히 능력 있는 모델이 있어도, 물리학은 지연을 부과합니다: 10개의 LLM 호출의 직렬 체인은 3개의 병렬 웨이브보다 10배 더 오래 걸립니다. DAG는 엔지니어링 문제(어떻게 빠르고 안정적으로 실행할 것인가)이지, 지능 문제(무엇을 실행할 것인가를 결정하는 방법)가 아닙니다. 재시도 로직, 비용 제어, 타임아웃 관리, 관찰성 — 이러한 것들은 모델이 더 똑똑해져도 사라지지 않습니다. 최종 결과: 모델은 “무엇을” 소유합니다(계획 지능이 모델 내부에 내재화됨), 프레임워크는 “어떻게”를 소유합니다(동시성, 재시도, 모니터링, 비용 거버넌스). 프레임워크의 지속적인 가치는 지능이 아닙니다 — 그것은 거버넌스입니다.Dify의 워크플로우 에디터를 미러링하지 않는 이유
자연스러운 질문: DAG가 유연한 경우를 다루면, 결정론적 경우를 위해 정적 워크플로우 에디터도 구축해야 하지 않을까? 아니다. 그 이유는:- 워크플로우는 이미 다른 곳에 존재한다. 정부 및 엔터프라이즈 클라이언트의 고정된 프로세스는 그들의 OA, ERP, 그리고 레거시 시스템에 있다. 그들은 이러한 흐름을 또 다른 플랫폼에서 다시 구축하고 싶지 않다 — 그들은 이러한 흐름이 이미 실행되는 시스템에 연결할 수 있는 AI를 원한다. 커넥터 플랫폼(v0.6)이 이를 직접 해결한다.
- 기존 기능이 고정된 파이프라인으로 구성된다. 스케줄된 작업(v1.0)은 고정된 프롬프트로 DAG 에이전트를 트리거하고, DAG는 동적으로 단계를 계획하며, 커넥터(v0.6)는 대상 시스템에 연결한다. 이 조합은 정적 파이프라인과 동등하다 — 하지만 더 유연하다. LLM이 마주친 데이터를 기반으로 계획을 조정할 수 있기 때문이다. 별도의 파이프라인 DSL이 필요하지 않다.
- 투자 불일치. 프로덕션 수준의 시각적 워크플로우 에디터(캔버스, 노드 타입, 변수 전달, 디버그/재생)는 수개월의 전담 노력이 필요하다. 그 결과는 Dify의 120K 스타 커뮤니티가 이미 유지하고 있는 것의 낮은 충실도 복사본일 것이다. 그 노력은 커넥터 아키텍처에 투자하는 것이 더 낫다 — 경쟁사가 제공하지 않는 기능이다.
FIM One의 위치
FIM One은 “AGI 작업 스케줄러”도 아니고 정적 워크플로우 엔진도 아닙니다. 중간 영역을 차지합니다: 제약이 있는 계획 수립 능력과 관찰 가능성이 있는 동시성.- Dify와 비교: 더 유연함 — 설계 시점의 플로우차트가 아닌 런타임 DAG 생성. 모든 실행 경로를 미리 예상할 필요가 없습니다. 시각적 워크플로우 편집에서는 경쟁하지 않으며, 레거시 시스템 통합에서 경쟁합니다.
- AutoGPT와 비교: 더 제어됨 — 제한된 반복, 재계획 제한, 로드맵에 있는 휴먼-인-더-루프. 보호장치 내의 자율성.
FIM One이 위치한 곳: 계획 x 실행 스펙트럼
AI 실행 환경은 두 개의 축으로 매핑할 수 있습니다 — 계획이 어떻게 생성되는지(정적 vs 동적)와 어떻게 실행되는지(경직된 vs 적응형): Dify/n8n이 정적 계획 + 정적 실행인 이유: DAG는 설계 시간에 인간이 시각적 캔버스에 그립니다. 각 노드는 고정된 작업(고정된 프롬프트를 사용한 LLM 호출, HTTP 요청, 코드 블록)을 실행합니다. 런타임 재계획이 없습니다 — 단계가 실패하면 워크플로우가 실패하거나 사전 연결된 오류 분기를 따릅니다. 이는 구조적으로 BPM과 동일하며, 단지 그래프에 AI 노드가 있을 뿐입니다. FIM One의 위치: 동적 계획 + 동적 실행- DAG 토폴로지는 런타임에 LLM에 의해 생성됩니다(동적 계획) — 인간이 그래프를 설계하지 않습니다
- 각 DAG 노드는 전체 ReAct 루프를 실행합니다(동적 실행) — 노드는 추론하고, 도구를 사용하며, 적응합니다
- 재계획 메커니즘(실행 → 분석 → 불만족하면 재계획)
- 하지만 제한됨: 최대 3회 재계획 라운드, 토큰 예산, 인간 확인 게이트
개념 용어집
이 문서에서 사용되는 용어에 익숙하지 않은 독자를 위해:| 용어 | 한 줄 설명 | FIM One과의 관계 |
|---|---|---|
| BPM (Business Process Management) | 설계 시점에 완전히 고정된 프로세스로 엄격하게 실행됨. Camunda, Activiti. | FIM One은 BPM이 아님. 고정된 프로세스 엔진 없음. |
| FSM (Finite State Machine) | 시스템이 항상 정확히 하나의 상태에 있으며, 이벤트가 전환을 트리거함. 루프 지원 (거절 → 재제출). | 대상 시스템 (ERP, 계약 시스템)은 내부적으로 FSM 사용. FIM One은 자체 FSM이 필요 없음 — 대상 시스템의 API를 호출함. |
| ACM (Adaptive Case Management) | 골격은 정적이고 분기는 동적. 주요 흐름은 사전 정의되고 각 노드는 런타임에 적응. | FIM One의 DAG + ReAct는 자연스럽게 이 영역에 해당. |
| HTN (Hierarchical Task Network) | 재귀적 작업 분해: 고수준 → 하위 작업 → 원자적 작업. | DAG 재계획이 대부분의 시나리오를 커버함. 아직 완전한 HTN은 필요 없음. |
| iPaaS (Integration Platform as a Service) | 여러 SaaS/온프레미스 시스템을 연결하는 클라우드 통합 플랫폼. MuleSoft, Zapier. | FIM One의 Hub Mode는 AI 네이티브 iPaaS 같음 — 자연어가 시스템 간 통합을 주도. |
아키텍처 경계: FIM One은 워크플로우 로직을 복제하지 않음
복잡한 비즈니스 프로세스(승인 체인, 이관, 거절, 에스컬레이션, 연서, 부서명)는 대상 시스템의 책임입니다. 이러한 시스템들은 이 로직을 구축하는 데 수년을 투자했습니다 — ERP, OA, 계약 관리 시스템 모두 성숙한 상태 머신을 갖추고 있습니다. 커넥터의 관점에서:| 작업 | 커넥터가 수행하는 작업 |
|---|---|
| 이관 | 하나의 API 호출, 대상 담당자 전달 |
| 거절 | 하나의 API 호출, 거절 사유 전달 |
| 에스컬레이션 | 하나의 API 호출, 에스컬레이션 담당자 목록 전달 |
| 연서 | 하나의 API 호출, 연서자 목록 전달 |
- 유지보수 부담 증가 (두 개의 상태 머신을 동기화 유지)
- 장애 모드 추가 (둘이 불일치하면 어떻게 할 것인가?)
- 추가 가치 제공 없음 (대상 시스템이 이미 올바르게 수행)