FlowScript: Markdown 스킬에 실행 흐름을 결합한 소규모 프로토타입

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 Markdown 기반의 사람이 읽는 스킬을 유지하면서 기계가 검증·실행할 수 있는 흐름을 분리하는 방법으로 FlowScript라는 소규모 프로토타입을 제시했다. 설계는 SKILL.md를 그대로 두고 FLOWSCRIPT.md의 fenced flow 블록을 런타임이 파싱해 LLM·검증기·Python 노드를 순차 실행하며 선언된 분기만 허용하고 아티팩트를 영속화하는 구조를 따른다. 이러한 접근은 채팅 히든 상태에 의존하지 않는 재현 가능한 로그와 부분 산출물 기록을 확보해 디버깅과 감사성을 높이며, 완전한 워크플로우 DSL로의 확대가 복잡성을 증가시킬 위험이 있다는 점이 한계로 지적된다. 작성자는 구현 세부 경계와 기존 프로젝트와의 중복 여부, 스키마와 관습의 분리 등에 대한 구체적 피드백을 요청하고 있다.

커뮤니티 반응

글 작성자는 피드백을 명시적으로 요청하고 있으며 설계 의도와 한계를 분명히 하고 있다. 게시물은 FlowScript의 구현 책임 영역과 기존 워크플로우/런타임과의 차이를 묻는 형태로 구성되어 있어 토론을 촉발할 수 있다. 실무자는 아티팩트 영속화, 선언적 분기 제한, 재현 가능한 컨텍스트 기록 같은 실질적 설계 포인트에 관심을 보일 가능성이 크다.

주요 논점

01찬성다수

Markdown을 저자 친화적 표면으로 유지하면서 별도 실행 흐름 파일로 검증 가능한 구조를 두면 작성 편의성과 실행 일관성을 모두 달성할 수 있다는 주장이 다수 있었다.

02중립분열

일부는 소규모 제어 프로파일이 유용하나 장기적으로는 워크플로우 DSL로 확장되기 쉬워 복잡성 관리가 필요하다는 신중한 입장을 보였다.

03반대소수

다른 의견으로는 이미 존재하는 런타임이나 LangGraph 유사 프로젝트와 중복될 가능성이 있고 유지 관리 비용 때문에 별도 층을 도입하는 것이 부담일 수 있다는 우려가 제기되었다.

합의점 vs 논쟁점

합의점

Markdown 형태의 사람이 읽는 스킬 문서는 작성·검토 면에서 장점을 제공한다는 점에는 대체로 동의가 형성되었다.
아티팩트 영속화와 실행 로그 기록은 재현성과 디버깅을 위해 필수적인 요소로 받아들여졌다.
런타임이 선언된 분기만 허용하고 비지원 말단 상태에서 중단하며 부분 산출물을 남기는 동작은 실용적이라는 점에서 합의가 있었다.

논쟁점

FlowScript 수준의 제어 프로파일이 충분한지 아니면 결국 워크플로우 DSL로 확장되어야 하는지에 관해 의견이 갈렸다.
FLOWSCRIPT의 문법과 어떤 부분을 Markdown 관습으로 남길지, 어떤 부분을 스키마로 강제해야 할지에 대한 경계 설정이 논쟁거리였다.
기존 도구와의 중복 가능성과 생태계 통합 비용을 누가 부담할지에 대해 이견이 존재했다.

실용적 조언

런타임이 신뢰할 수 있도록 FLOWSCRIPT.md의 스키마를 우선 작게 정의해 필수 노드 타입과 명시적 분기만 허용하도록 설계하면 초기 복잡도를 낮출 수 있다.
아티팩트는 파일 시스템 또는 객체 스토리지에 명시적 경로로 저장하고 skill_agent_context.json을 기록해 재실행과 감사를 지원하면 디버깅 작업 부하가 줄어든다.
외부 런타임과의 통합을 고려해 변환기나 어댑터 레이어를 두면 LangGraph나 워크플로우 엔진으로의 이식성이 확보되며, 문서와 실행 정의를 분리해 호환성 문제를 완화할 수 있다.

섹션별 상세

Markdown 기반 스킬은 작성과 검토가 쉬워 재사용 가능한 스킬 패키지로 편리하지만 실행 제어가 느슨해 모델이 단계 건너뛰기나 순서 위반을 일으키는 문제가 있었다. FlowScript는 이 문제를 해결하기 위해 사람이 읽는 SKILL.md와 기계가 파싱하는 FLOWSCRIPT.md를 분리해 두 파일이 각자의 역할을 하게 한다. 글에는 FLOWSCRIPT.md가 fenced flow 블록을 포함하고 런타임이 이를 로드해 검증·실행한다고 구체적으로 기술되어 있으며, 이 접근은 스킬의 가독성과 실행 일관성을 동시에 확보하려는 시도로 의미가 있다.

FLOWSCRIPT의 핵심 설계는 선언된 흐름만 실행하도록 런타임이 강제하고 LLM 노드·검증기·Python 스크립트 노드를 순서대로 실행하는 구조에 있다. 작성자는 런타임이 선언된 분기만 라우팅하고 아티팩트를 파일에 영속화하며 OpenAI 스타일의 skill_agent_context.json을 기록한다고 상세히 적었다. 이러한 처리 과정은 채팅 히든 상태에 의존하지 않고 재현 가능한 실행 로그와 부분 산출물을 남기므로 디버깅과 감사가 용이해진다는 근거로 제시되었다.

저자는 FlowScript를 워크플로우 엔진이나 LangGraph 같은 도구들을 대체하려는 의도가 아니라 호환성 계층으로 위치시켰다. 이 관점에서는 Markdown 네이티브 스킬을 유지하면서도 적절한 수준의 기계 검증(schema validation)과 실행 통제를 부여하는 작은 프로파일이 목표다. 게시글에서 이를 명확히 구분한 이유는 완전한 워크플로우 DSL로 범위가 확장될 경우 복잡성과 표준화 비용이 급증할 수 있다는 점을 지적했기 때문이다.

작성자는 구체적 피드백 항목으로 Markdown/실행 분리 타당성, 기존 프로젝트의 중복성 여부, Markdown 관습과 기계 검증의 경계, 그리고 소규모 제어 프로파일의 실용성 여부를 제시했다. 이 질문들은 설계 결정이 어디까지 문서 컨벤션으로 두고 어디까지 런타임 검사로 강제할지를 가르는 실무적 선택과 연결된다. 제안된 항목들은 프로젝트 채택 시 유지보수성·호환성·도구 생태계 영향을 평가해야 한다는 실무적 결론을 암시한다.

용어 해설

Workflow DSL: — 작업 단계를 선언적으로 기술하여 실행 순서·분기·에러 처리를 자동화하는 도메인 특화 언어로서, 입력과 노드 실행 규칙을 명시해 런타임에서 직렬화·검증·재현을 가능하게 하는 역할을 한다. 이 글에서는 단순한 실행 제어나 검사만을 다루는 '제어형 프로필'과 완전한 워크플로우 DSL의 확장성 문제를 비교하는 맥락에서 중요하게 작용한다. Workflow DSL의 설계 결정이 스킬의 가독성, 검증 가능성, 호환성에 미치는 영향이 핵심 고려사항이다.
Artifact persistence: — 대화형 상태 대신 파일·스토리지에 중간 결과와 산출물을 저장하여 재현과 검사, 실패 복구를 가능하게 하는 방법을 의미한다. 글에서는 채팅 히든 상태에 의존하지 않고 선언된 경로로만 아티팩트를 보존하는 설계를 목표로 삼는 기술적 선택으로 등장한다. 아티팩트 영속화는 디버깅과 재실행을 일관되게 만들며 감사용 로그와 연계하기 쉽다는 장점이 있다.
Trace/Replay: — 실행 중 생성된 컨텍스트와 입력·출력 이벤트를 기록해 동일한 시나리오를 다시 재생하거나 분석할 수 있게 하는 접근법으로, 재현성과 디버깅을 강화한다. 글에서는 OpenAI 스타일의 skill_agent_context.json을 기록해 이후 재생·검토가 가능하도록 하는 설계가 핵심으로 제시되었다. 추적·재생은 스킬 변경 시 회귀 검증이나 사용자 행동 분석에 유용하다.

언급된 도구

LangGraph중립

워크플로우 스타일 런타임과의 비교 대상

Workflow engines중립

강력한 실행 제어와 오케스트레이션을 제공하는 기존 솔루션 범주

OpenAI-style skill_agent_context.json추천

실행 컨텍스트를 기록해 재현과 재생을 가능하게 하는 로그 형식 예시

언급된 리소스

GitHubFlowScript repository