Documentation Index
Fetch the complete documentation index at: https://docs.fim.ai/llms.txt
Use this file to discover all available pages before exploring further.
동적 계획이 어려운 중간 지점인 이유
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 스타 커뮤니티가 이미 유지하고 있는 것의 낮은 충실도 복사본일 것이다. 그 노력은 커넥터 아키텍처에 투자하는 것이 더 낫다 — 경쟁사가 제공하지 않는 기능이다.
전략적 베팅: 워크플로우 시각화로 경쟁하지 말고, 시스템과 AI가 만나는 허브가 되는 것으로 경쟁하라. Dify가 “AI 워크플로우를 시각적으로 구축”을 소유하게 하라. FIM One은 “시스템과 AI가 만나는 허브”를 소유한다.
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회 재계획 라운드, token 예산, 인간 확인 게이트
이는 FIM One을 AutoGPT와 동일한 사분면에 배치하지만, 폭주 동작을 방지하는 엔지니어링 제약이 있습니다. BPM/Dify보다 더 유연하고, AutoGPT보다 더 제어됩니다.
개념 용어집
이 문서에서 사용되는 용어에 익숙하지 않은 독자를 위해:
| 용어 | 한 줄 설명 | 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와 같음 — 자연어가 시스템 간 통합을 주도함. |
| MDM (Master Data Management) | 시스템 전체에서 엔티티 레코드를 중복 제거하고 통합하여 “황금 레코드”로 만듦. Reltio, Informatica, Tamr. | FIM One은 MDM 시스템에 연결됨; 엔티티 해석을 복제하지 않음. |
| Context Layer / System of Context | AI 에이전트에 신뢰할 수 있는 비즈니스 컨텍스트를 제공하는 통합 엔티티 + 관계 그래프. Reltio에서 대중화된 용어(2026). | FIM One은 이를 업스트림 MDM/데이터 플랫폼에 위임함. 스킬은 일반적인 경우에 대한 경량 집계를 제공함. |
아키텍처 경계: FIM One은 워크플로우 로직을 복제하지 않음
복잡한 비즈니스 프로세스(승인 체인, 이관, 거절, 에스컬레이션, 공동 서명, 부서명)는 대상 시스템의 책임입니다. 이러한 시스템들은 이 로직을 구축하는 데 수년을 투자했습니다 — ERP, OA, 계약 관리 시스템 모두 성숙한 상태 머신을 보유하고 있습니다.
커넥터의 관점에서:
| 작업 | 커넥터가 수행하는 작업 |
|---|
| 이관 | 하나의 API 호출, 대상 담당자 전달 |
| 거절 | 하나의 API 호출, 거절 사유 전달 |
| 에스컬레이션 | 하나의 API 호출, 에스컬레이션 담당자 목록 전달 |
| 공동 서명 | 하나의 API 호출, 공동 서명자 목록 전달 |
- 유지보수 부담 증가 (두 개의 상태 머신을 동기화 유지)
- 장애 모드 추가 (둘이 불일치하면 어떻게 할 것인가?)
- 추가 가치 제공 없음 (대상 시스템이 이미 올바르게 수행)
커넥터 패턴은 설계상 단순합니다: 하나의 작업 = 하나의 API 호출.
Architecture Boundary: Connector Layer, Not Context Layer
Enterprise AI is converging on a layered architecture for agent context:
| Layer | What it does | Representative players |
|---|
| Decision Traces | Records why something happened — audit trails, lineage | Palantir Decision Lineage, Arize |
| Entity Context | Unified golden records + relationship graphs — the “System of Context” | Reltio/SAP, Informatica/Salesforce, Tamr |
| Data Connectivity | Connects agents to source systems via APIs and protocols | FIM One, CData, MCP ecosystem |
| Source Systems | CRM, ERP, contract management, databases, SaaS apps | SAP, Salesforce, custom systems |
산업 맥락: 2025-2026년 통합
두 개의 획기적인 인수합병이 엔터프라이즈 AI 데이터 환경을 재편성했으며 컨텍스트 계층을 전략적 경쟁 무대로 만들었습니다:
- Salesforce가 Informatica 인수 (2025년 11월) — 엔터프라이즈 MDM 및 데이터 거버넌스를 Data Cloud + Agentforce 스택에 추가했습니다. 목표: Informatica의 골든 레코드를 기반으로 Agentforce 에이전트를 신뢰할 수 있게 만들기.
- SAP가 Reltio 인수 발표 (2026년 3월) — AI 네이티브 엔티티 해석 및 관계 그래프를 Business Data Cloud(BDC)에 추가했습니다. 목표: SAP 및 비SAP 환경에 걸쳐 있는 “System of Context”를 생성하여 Joule 에이전트의 신뢰할 수 있는 기반으로 제공.
이러한 움직임은 세계 최대 규모의 엔터프라이즈 플랫폼들이 이제 통합된 엔티티 컨텍스트를 신뢰할 수 있는 AI 에이전트의 필수 요소로 간주하고 있음을 시사합니다 — 선택 사항이 아닙니다.
데이터 소유권 × 컨텍스트 깊이 스펙트럼
차트 읽기:
- 좌하단 (경량 커넥터): 최소한의 데이터 소유권, 원시 API 연결성. Dify, n8n, 기본 MCP 서버가 여기에 위치합니다 — 시스템에 연결되지만 엔티티를 이해하지 못합니다. FIM One은 이 사분면에 있지만 점진적 공개 메타 도구, 스킬 기반 컨텍스트 집계, 도메인 인식 에스컬레이션으로 인해 y축에서 더 높은 위치에 있습니다.
- 좌상단 (컨텍스트 인식 허브): 엔티티 수준 이해를 갖춘 연합 액세스. Salesforce Data Cloud가 이를 예시합니다 — 제로 카피 연합과 온디맨드 엔티티 해석. DataHub는 비즈니스 데이터를 소유하지 않으면서 메타데이터 수준 컨텍스트(스키마, 계보, 소유권)를 제공합니다.
- 우상단 (심층 온톨로지 플랫폼): 심층 엔티티 인텔리전스를 갖춘 완전한 데이터 수집. SAP BDC + Reltio는 관계 그래프를 포함한 영구적인 다중 도메인 골든 레코드를 구축합니다. Palantir는 가장 멀리 나아갑니다 — 의사결정 계보를 포함한 3계층 온톨로지.
- 우하단 (데이터 웨어하우스 / 레이크): 엔티티 의미론 없는 중앙화된 데이터 저장소. 모든 것을 수집하지만 엔티티 해석이나 관계 모델링이 부족한 전통적인 데이터 플랫폼.
FIM One의 위치는 의도적인 선택을 반영합니다: 연합 및 경량 상태를 유지하되, 업스트림 엔티티 컨텍스트(모든 MDM에서)를 에이전트가 쉽게 액세스할 수 있도록 투자합니다.
세 가지 엔티티 컨텍스트 모델
SAP: 다중 도메인 골든 레코드 (복사 입력 + 거버넌스)
SAP는 3계층 엔터프라이즈 아키텍처를 구축하고 있습니다:
| 계층 | 시스템 | 역할 |
|---|
| 트랜잭션 | S/4HANA | 비즈니스 실행 — 주문, 송장, 배송 |
| 인텔리전스 | Business Data Cloud (BDC) + Reltio | 의미론적 통합, 엔티티 해석, 관계 그래프 |
| 에이전트 | Joule + Joule Agents | 의도 이해, 도구 오케스트레이션, 자율 실행 |
FIM One의 위치
| 차원 | SAP + Reltio | Salesforce + Informatica | FIM One |
|---|
| 데이터 철학 | Copy-in: BDC에 수집, 골든 레코드 구축 | Federate: 제로 카피 액세스, 온디맨드 해결 | Pass-through: 소스에 연결, 저장하지 않음 |
| 엔티티 해결 | 심화 — AI 기반 MDM과 관계 그래프 | 중간 — Data Cloud 엔티티 해결 | 없음 — 업스트림 MDM에 위임 |
| 에이전트 통합 | Joule Agents + MCP | Agentforce + Data Cloud grounding | 모든 에이전트 + 모든 커넥터 |
| 배포 비용 | 엔터프라이즈 플랫폼 가격 | 엔터프라이즈 SaaS 가격 | 경량, 몇 시간에서 며칠 |
| 종속성 | 높음 (BDC + S/4HANA 에코시스템) | 중간 (Salesforce 에코시스템) | 낮음 — 커넥터는 상호 교환 가능 |
| 최적 사용 사례 | 제조, 공급망, 생명과학 (복잡한 다중 도메인) | CRM 중심 기업 (프론트 오피스 포커스) | 중견기업, 다중 시스템, 공급자 무관 |
FIM One이 커넥터 레이어에 머물러 있는 이유
엔티티 컨텍스트 레이어를 구축하려면 지속적인 데이터 저장소, ML 기반 엔티티 해석, 생존 규칙, 관계 그래프 엔진, 거버넌스 프레임워크가 필요합니다. 이는 별개의 제품 카테고리(MDM)이며 10년 이상의 경쟁 역사가 있습니다(Reltio, Informatica, Tamr). 이를 시도하면:
- FIM One을 커넥터에서 데이터 플랫폼으로 변환 — 근본적으로 다른 제품, 팀, 시장 진출 전략
- 업스트림 시스템이 이미 제공하는 기능 중복 — 워크플로우 로직에서 피하는 것과 동일한 안티패턴
- 잠금 증가 — 사용자가 FIM One에 골든 레코드를 저장하면 전환 비용이 급격히 증가
올바른 전략: 모든 MDM 시스템의 최고의 진입점이 되기, MDM의 대체품이 아니기. FIM One은 Reltio, Informatica, Tamr 또는 커스텀 MDM이 MCP 리소스, 커넥터 API 또는 지식 베이스 주입을 통해 에이전트에 엔티티 컨텍스트를 제공하는 것을 간단하게 만들어야 합니다.
현재 접근 방식: 경량 컨텍스트 집계로서의 스킬
여러 커넥터에 걸친 컨텍스트가 필요한 시나리오(예: 공급업체 데이터 + 결제 이력 + 위험 플래그가 필요한 계약 검토)의 경우, 스킬은 이미 실용적인 솔루션을 제공합니다. 스킬의 SOP는 여러 커넥터 작업을 순차적으로 조율하고, 결과를 집계하며, 구조화된 컨텍스트를 에이전트에 제시할 수 있습니다. 이는 영구적인 엔티티 계층을 구축할 필요 없이 가능합니다.
이는 80%의 사용 사례를 다룹니다. 커넥터 수준에서 실시간 엔티티 해석에 대한 수요가 발생하면, 아키텍처는 외부 MDM 시스템과 통합되는 향후 ContextSource 커넥터 타입을 위한 여지를 남깁니다. 하지만 이는 향후 고려 사항이지, 현재의 약속은 아닙니다.
FIM One과 컨텍스트 레이어의 관계는 SQLAlchemy와 데이터베이스의 관계와 같습니다. 데이터를 저장하거나 관리하지 않지만, 애플리케이션 레이어에서 모든 데이터 소스에 접근할 수 있게 합니다. MDM 플랫폼이 엔티티 해석을 소유하도록 하고, FIM One이 연결을 소유하도록 하세요.
FIM One이 AI 스택에서의 위치
계층화된 모델
유용한 정신 모델(출처: Phil Schmid)은 AI 시스템을 컴퓨팅 하드웨어와 유사한 4계층 스택으로 매핑합니다:
| 계층 | 유추 | FIM One 구성 요소 |
|---|
| 모델 | CPU | ModelRegistry — OpenAI 호환 LLM |
| 컨텍스트 | RAM | ContextGuard + 메모리 (Window / Summary / DB) |
| 하네스 | 운영 체제 | ReAct 에이전트 + DAG 플래너 + Hooks + ToolRegistry |
| 애플리케이션 | 앱 | Portal, Copilot, Hub API |
AI 엔지니어링의 세 가지 시대
이 분야는 뚜렷한 단계들을 거쳐 진화해왔습니다: 제시어 엔지니어링은 고정된 모델에서 올바른 동작을 유도하기 위해 더 나은 지시사항을 작성하는 데 초점을 맞췄습니다. 컨텍스트 엔지니어링은 주의를 올바른 정보 조립으로 전환했습니다 — 문서 검색, 도구 결과 주입, 메모리 관리 — 모델이 잘 추론할 수 있도록 필요한 것을 갖추도록 합니다. 하네스 엔지니어링은 더 나아갑니다: 결정론적 가드레일, 도구 오케스트레이션, 피드백 루프, 비용 제어를 포함하여 모델 주위의 전체 실행 환경을 설계합니다.
FIM One의 아키텍처는 하네스 엔지니어링 원칙을 구현합니다. Hook System은 잘 정의된 라이프사이클 포인트에서 LLM 루프 외부의 플랫폼 코드를 실행합니다 — 현재 FeishuGateHook은 민감한 도구 호출을 가로채고 IM 채널을 통해 승인을 라우팅하며, 동일한 추상화는 v0.9에서 감사 로깅, 읽기 전용 모드 적용, 속도 제한, 결과 잘라내기의 계획된 홈입니다. ContextGuard는 컨텍스트 윈도우에 무엇이 들어가고 언제 들어가는지를 관리합니다. 동적 도구 선택(점진적 공개 메타 도구)은 커넥터 수가 증가함에 따라 도구 표면을 관리 가능하게 유지합니다. ReAct 루프의 자기 반성 메커니즘과 DAG 플래너의 재계획 사이클은 더 강력한 모델을 요구하지 않고도 실행 품질을 향상시키는 구조화된 피드백을 제공합니다.
