Skip to main content

​
그래프 엔지니어링(2026)과 FIM One

업계 논의에서는 종종 루프 엔지니어링(단일 에이전트가 반복적으로 생각하고 행동하는 방식)에서 그래프 엔지니어링(다중 노드 토폴로지를 명시적인 엔지니어링 객체로 만드는 방식)으로의 전환을 언급합니다. 이 용어는 새롭지만, 실제 관행은 그렇지 않습니다. LangGraph 스타일의 시스템과 멀티 에이전트 조직들은 수년간 그래프를 사용해왔습니다. FIM One에 중요한 것은 사람들이 의미하는 그래프의 종류와 그것이 우리의 세 가지 실행 계층에 어떻게 매핑되는지입니다.

​
그래프 엔지니어링이 보통 의미하는 것

그 프레임 전반의 합의: 그래프는 루프를 대체하지 않습니다. 그래프 설계는 프로세스 간의 관계를 설계합니다. 각 에이전트 노드는 여전히 전체 루프를 실행할 수 있습니다. “Graph”는 실제로 과도하게 사용됩니다. 세 가지 사용법이 혼합됩니다: 이 페이지는 처음 두 가지(오케스트레이션)에 관한 것입니다.

​
”Dify Workflow with a new name”이 아님

Dify 스타일의 시각적 워크플로우와 그래프 엔지니어링은 공통의 혈통(명시적 토폴로지)을 공유하지만 동일한 제품이 아닙니다. 간단히 말해: 클래식 워크플로우는 결정론적 (또는 반결정론적) 파이프이며 가끔 LLM 단계가 있습니다. 그래프 엔지니어링은 다중 노드 시스템 토폴로지이며, 중요한 지점은 여전히 자율 에이전트일 수 있습니다.

​
FIM One에서 산업 맵이 어떻게 위치하는가

FIM One은 이미 제어 스펙트럼 전체를 아우르고 있으며, 채팅 “Planner mode”는 일부일 뿐입니다.

​
그래프 엔지니어링 vs FIM One DAG (채팅 Planner)

같은 계열(명시적 다단계 토폴로지). 다른 종류. 함의: 그래프 엔지니어링 주변의 산업 관심은 그래프/스케줄링 엔진 유지를 검증합니다. 이는 모든 턴에 “Planner”를 선택하도록 강제하는 채팅 기본값을 요구하지 않습니다. 대부분의 작업은 여전히 강력한 루프를 원합니다; 그래프는 병렬 분기, 고정 규정 준수 경로, 다중 역할 오케스트레이션에서 가치를 입증합니다.

​
FIM One이 배울 수 있는 것 (ReAct, DAG, Workflow 강화)

구체적인 수확, 슬로건 아님. 영향력 순서. “그래프를 하고 있을” 때 피해야 할 안티패턴:
  • 의존성 그래프를 인간 상태 머신 시뮬레이션에 사용 (대기 원시 없는 다단계 “답변 대기”).
  • ReAct update_plan (체크리스트 메모리)을 그래프 엔지니어링 (스케줄링 토폴로지)과 동일시.
  • 그래프 열을 두 번째 채팅 성격으로 배송하는 대신 엔진 구성 (외부 루프, 필요할 때 내부 스케줄).
  • FIM One DAG 단계를 “얕은 LLM 호출”로 설명: 엔진을 과소평가하고 제품 결정을 오도.

​
AI 도구 환경에서 “계획”의 다섯 가지 종류

“계획”이라는 단어는 과부하 상태입니다. 현재 최소 다섯 가지의 서로 다른 접근 방식이 존재하며, 각각 다른 문제를 해결합니다: 처음 두 가지는 설계 시간 계획입니다 — 작업이 시작되기 전에 계획을 생성하며, 인간(또는 모델 자체)이 단계별로 따릅니다. 마지막 세 가지는 런타임 계획을 도입합니다 — 실행 그래프가 프로그래밍 방식으로 생성되고 스케줄되며, 독립적인 분기가 병렬로 실행됩니다. 차이점은 누가 실행하는가입니다: Claude Code Teams는 자율 에이전트를 생성하고, FIM One DAG는 단일 오케스트레이터 내에서 단계를 디스패치합니다. 이러한 접근 방식들은 경쟁 관계가 아닙니다. 이들은 상호 보완적인 계층입니다. Kiro 스타일의 스펙은 무엇을 구축할지 정의할 수 있고, FIM One DAG는 부작업을 동시에 어떻게 실행할지 스케줄할 수 있습니다. Claude Code의 계획 모드는 인간이 접근 방식에 동의하도록 보장하고, FIM One의 PlanAnalyzer는 결과를 자동으로 검증합니다.

​
Three-Layer Nesting: The Full-Power Architecture

Claude Code Teams와 FIM One DAG는 최대 용량에서 3계층 중첩 아키텍처를 나타냅니다:
  • Layer 1 — Human gate: 사용자가 계획을 검토하고 실행이 시작되기 전에 승인합니다.
  • Layer 2 — DAG orchestration: 승인된 계획이 의존성 엣지를 가진 작업으로 분해됩니다. 독립적인 작업은 병렬로 실행되고, 다운스트림 작업은 차단 요소가 해결될 때까지 대기합니다.
  • Layer 3 — ReAct inner loop: 각 작업은 완전한 ReAct 사이클(Perceive → Reason → Act → Observe)을 실행하는 에이전트에 의해 실행되며, 다단계 추론, 도구 사용 및 자동 재시도가 가능합니다.
핵심 통찰: Claude Code Teams와 FIM One DAG는 동일한 3계층을 구현하며, Layer 2 메커니즘만 다릅니다 — 메시지 전달 vs 의존성 엣지 해결.

​
Full-Power Runtime: FIM One vs Claude Code Teams

둘 다 진정한 에이전트입니다 — 핵심 루프는 동일합니다: 인식 → 추론 → 행동 → 피드백. 차이점은 최대 용량에서 병렬 작업을 어떻게 조율하는지에 있습니다.

​
Real-World Benchmark: v0.5 RAG System

Claude Code Teams built FIM One’s entire v0.5 RAG subsystem in a single session:
  • 8 phases: Embedding → Reranker → Loaders → Chunking → VectorStore → Retrieval → KB Backend → Frontend + Docs
  • 46 tests passing, frontend build clean
  • Wall time: ~5 minutes
  • Token cost: ~100k tokens per agent task × 8+ tasks ≈ 800k+ total tokens
  • Dependency edges: Phase 5 depends on Phase 4 + 1b; Phase 6 depends on Phase 5 + 2 + 3 — a genuine DAG
This demonstrates the core trade-off: 시간 병렬화로 인한 토큰 증가의 대가. Claude Code Teams는 개발자 시간을 절약하기 위해 컴퓨팅 비용을 증가시킵니다.

​
수렴, 경쟁이 아님

“팀 협업”과 “파이프라인 스케줄링” 간의 경계가 흐릿해지고 있습니다:
  • Claude Code Teams의 blockedBy/blocks는 DAG입니다 — 작업은 명시적 의존성 엣지를 가지며, 리더는 선행 작업이 완료되면 새로 차단 해제된 작업을 디스패치합니다. 이는 추가 단계(메시지)가 있는 위상 정렬 스케줄링입니다.
  • FIM One DAG 스텝은 이미 완전한 ReAct 에이전트입니다 — Layer 3은 염원이 아닙니다. 각 스텝은 도구와 다중 반복 루프를 사용하여 agent.run()을 실행합니다. 최상위 ReAct 채팅 턴과의 차이는 의도적입니다(스텝별 계획 보드 없음, 채팅 레벨 ask_user_question 대기 없음, model_hint / 일반 기본값으로 선택된 모델).
핵심: 동일한 에이전트 본질, 수렴하는 병렬 철학. Claude Code는 팀 협업 모델을 따릅니다 — 리더가 메시지를 통해 통신하는 워커에게 위임합니다. FIM One은 파이프라인 스케줄링 모델을 따릅니다 — DAG 실행기가 의존성 해결을 기반으로 ReAct 스텝을 디스패치합니다. 실제로 두 모델 모두 의존성 기반 병렬 실행을 구현합니다. 차이는 조정 오버헤드(메시지 vs 엣지), 격리(피어 에이전트 vs 작업 + 의존성 결과), 토큰 경제학입니다. 제품 격차는 “노드를 에이전트로 만들기”보다는 그래프를 스케줄할 시기 vs 하나의 채팅 루프에 머물 시기, 그리고 그래프가 일시 중지할 수 없는 인간 대기 엣지입니다.

​
구조화된 출력 성능 저하

DAG 파이프라인의 모든 구조화된 LLM 호출 사이트(Planner, Analyzer, Tool Selection)는 3단계 성능 저하 체인을 구현하는 통합 structured_llm_call() 유틸리티를 사용합니다: 각 텍스트 기반 레벨은 다음 레벨로 넘어가기 전에 재포맷 프롬프트로 한 번 재시도합니다. 결과는 파싱된 값, 추출 성공 레벨, 누적된 토큰 사용량을 포함하는 StructuredCallResult입니다. 이 설계는 동일한 프롬프트가 GPT-4(native FC), Claude(JSON mode), 로컬 모델(plain text)에서 안정적으로 작동하도록 하며, 네 개의 호출 사이트에 분산되지 않고 한 곳에서 일관된 오류 처리 및 재시도 로직을 제공합니다.

​
세 가지 실행 계층: 제어 스펙트럼

위의 다섯 가지 계획 접근 방식은 전체 그림을 설명합니다. FIM One 내에서 세 가지 실행 계층은 완전한 인간 제어에서 완전한 AI 자율성까지의 제어 스펙트럼을 제공합니다. 그래프 엔지니어링과의 관계: Workflow는 설계 시간 그래프 제품입니다. DAGPlanner는 런타임 작업 그래프입니다. ReAct는 루프 엔지니어링입니다(선택적 계획 보드 메모리 포함, 스케줄 그래프 아님). 설계 원칙: 사용자에게 원하는 만큼의 제어를 정확히 제공합니다.
  • 모든 대출 승인이 다섯 가지 특정 단계를 통과하는지 증명해야 하나요? → Workflow.
  • 세 가지 주제를 병렬로 조사한 후 종합해야 하나요? → DAG.
  • 실행 중간에 초안 작성, 개선 또는 구조화된 질문을 해야 하나요? → ReAct.
  • 확실하지 않나요? → execution_mode: "auto"는 쿼리를 분류하고 런타임에 DAG 또는 ReAct로 라우팅합니다(목표가 주로 명확화 또는 짧은 탐색일 때 ReAct 선호).
이 계층화는 FIM One을 단일 패러다임 도구와 구분하는 것입니다:
  • Dify는 Workflow 계층을 강조합니다(정적 또는 반정적 시각적 그래프).
  • LangGraph는 코드 수준의 제어 흐름 그래프 DSL을 강조합니다(개발자 정의 토폴로지, 동적 라우팅, 체크포인팅). 구조적으로 시각적 워크플로우와 관련이 있으며 소프트웨어로 표현됩니다.
  • Manus 클래스 에이전트는 Agent/루프 계층을 강조합니다(자율 실행, 사용자 정의 구조 최소화).
FIM One은 세 가지 계층 모두를 포함하며, 채팅 엔진 간의 자동 라우팅도 포함합니다. 사용자 정의 그래프 → LLM 생성 작업 그래프 → 스케줄 그래프 없음의 진행은 더 광범위한 산업의 정직함과 일치합니다: 모델이 개선됨에 따라 명시적 토폴로지는 필수 UI가 아닌 대부분의 턴에서 선택 사항이 됩니다. 그래프 엔지니어링 열은 모든 채팅을 플래너를 통해 강제하는 것이 아니라 엔진과 구성에 투자하는 이유입니다.

​
관련 문서