XState를 쓸 때는 statecharts라는 용어를 몰라도 충분히 유용했다
lit.js와 함께 페이지 너비에 반응하고 props와 내부 상태가 많은 drawer형 네비게이션 컴포넌트에 적용했는데, XState 없이는 얼마나 끔찍했을지 상상도 안 된다
예전에 복잡하게 꼬인 상황들을 XState로 많이 정리했다
다음 버전도 기대되고, 정말 고맙다
복잡한 중첩 상태 머신이 필요 없다면 robot3.js도 볼 만하다
자동 TS 타입 추론이 꽤 좋아서, 가벼운 상태 머신 로직이 필요한 자리에서 쓰기 편하다
예전엔 frontend/UI ecosystem에서 statecharts가 조금씩 탄력을 받는 듯했는데, 왜인지 그 흐름이 사라진 게 아쉽다
UI 상호작용에 상태 머신, 특히 statecharts 같은 상태 머신 조합을 쓰면 복잡한 흐름을 훨씬 추론하기 쉬워진다
처음 접하는 거라면 Ian Horrucks의 "Constructing the user interface with statecharts"를 강력히 추천한다
1999년 책이지만 실제로 어떻게 적용하고 써야 하는지 설명하는 입문서로는 여전히 최고 수준이다 https://archive.org/details/isbn_9780201342789/mode/2up
XState는 아직도 충분히 확산 중이다
주간 npm 다운로드가 400만을 넘고, Rive와 LottieFiles 같은 애니메이션 도구도 상태 머신 기능을 강하게 내세운다
LangGraph 같은 AI 도구도 상태 머신 기반 위에 올라가 있다
이런 앱과 도구들이 statecharts의 잠재력을 완전히 끌어내려면 시간이 더 필요하겠지만, 출발은 좋다
입문서에서 자주 빠지는 부분이 history pseudo-states다
H, H를 쓰면 바깥에서 볼 때 statechart는 형식적으로 비결정적이 된다
흔히 "현재 상태는 입력의 순수 함수"라고 설명하지만, history가 그 전제를 깨뜨린다
부모 상태로 H를 통해 다시 들어가면 마지막으로 활성화돼 있던 자식으로 복귀하므로, 같은 이벤트와 같은 바깥 상태에서도 서로 다른 내부 상태로 들어갈 수 있다
그 숨어 있는 "마지막 활성 자식" 자체가 상태인데, 다이어그램에는 보통 그려지지 않는다
Harel 원 논문도 이걸 인정하고, SCXML과 XState도 구현하지만, 정작 이 부분은 거의 이야기되지 않는다
그래서 deep history로 서브트리 상태를 재진입 시 보존한다면 bookkeeping을 차트 엔진 쪽으로 옮긴 셈이다
괜찮은 선택이긴 하지만 그림만으로는 전체 동작을 다 설명하지 못하고, history 전이도 다른 상태 로직처럼 별도 테스트가 필요하다
여기서 inputs를 현재와 미래 입력만 뜻한다고 볼 수도 있고, 지금 위치에 오기까지의 과거 입력까지 포함한 전체 입력으로 볼 수도 있다
후자 해석이라면 기계는 완전히 결정적이며, deep history 포인터도 그냥 상태 머신 상태의 일부다
설명한 시나리오만 놓고 보면 history 노드는 다시 결정적으로 모델링할 수 있어 보인다
예를 들어 H, H 노드를 여러 노드로 풀고, H'를 각 노드 앞에 붙는 write-ahead log 같은 것으로 두면 된다
Temporal, DBOS, Restate 같은 durable execution 엔진과 statecharts를 결합할 수 있을지 궁금하다
회사에서는 onboarding과 payment workflow를 관리할 때 Cloudflare Workflows를 쓰는데, 자동으로 나오는 flowchart 다이어그램 덕분에 워크플로우 동작을 빠르게 이해할 수 있다
이게 결국 statecharts가 노리는 가치와 꽤 닮아 보인다
Zindex를 바로 그 "실행 가능한 워크플로우의 시각 표현" 계층을 목표로 만들고 있다 https://zindex.ai/
AI가 만드는 다이어그램은 대개 한 번 생성하고 끝나는 Mermaid/SVG/PNG라서, 갱신·검증·diff·재사용이 가능한 지속적 다이어그램 상태가 없다
Zindex는 다이어그램 자체를 구조화된 상태로 다룬다
에이전트가 Diagram Scene Protocol(DSP)로 노드, 엣지, 그룹, 관계, 제약, 리비전을 patch하면 Zindex가 validation, layout, rendering, versioning, storage를 맡는다
그래서 Temporal/DBOS/Restate/Cloudflare Workflows 옆에 붙여, 실행의 진실 원천은 엔진이 유지하고 Zindex는 코드나 실행 이력에서 파생된 영속적이고 검사 가능한 시각 모델을 관리하게 할 수 있다고 본다
워크플로우만 스포트라이트를 받고 state machines는 과소평가되는 느낌이 늘 아쉬웠다
사실 durable execution만 붙으면 statecharts도 충분히 해낼 수 있다
Cloudflare가 한동안 durable object actor 모델 쪽으로 가는 듯했는데, 그 프로젝트를 접었는지는 잘 모르겠다
"flowchart 다이어그램을 생성한다"는 게 정확히 무엇이 만드는 건지 궁금하다
Cloudflare Workers에 내장된 기능인지, 아니면 팀에서 직접 만든 것인지 알고 싶다
상태 머신의 채택이 더 커지길 늘 바랐다
AI가 생성한 코드를 인간이 쓴 코드만큼 깊이 이해하지 못하는 시대에는 state의 시각적 이해가 점점 더 중요해진다
그래도 프런트엔드 프레임워크에서는 여전히 store 기반 reactive state를 더 선호하는 듯하다
나 역시 그걸 기본값으로 쓰는 편이라 굳이 바꾸지 않았고, xstate 같은 라이브러리는 문법을 배우기 더 어렵고 장황하다는 인식도 있다
그런데 AI가 있으면 그 장벽은 거의 줄어들기 때문에, 내가 못 본 다른 이유가 있는지, 아니면 statechart가 아직 정점을 못 찍은 건지 궁금하다
다음 XState 버전은 훨씬 더 ergonomic해질 예정이다
API 표면적도 줄고, 학습 곡선도 낮아지고, 개발자와 에이전트 모두가 작성하기 쉬워진다
동시에 최신 frontier 모델들은 이미 XState 코드를 꽤 잘 작성한다
https://github.com/xlnfinance/xln 프로젝트를 하다가, 실제 네트워크를 결정적으로 에뮬레이션할 방법이 필요하다는 걸 깨달았다
그러다 모든 블록체인은 결국 replicated state machine인데, 그렇다면 각 사용자 노드를 Runtime -> Entity -> Account의 3단계 상태 머신 계층으로 감싸면 되지 않을까 싶어졌다
바깥 머신이 안쪽 머신을 완전히 제어하는 구조라서, 서로 다른 합의 모드를 가진 "blockchain inside blockchain" 같은 그림이다
이후 "hierarchical state machines"를 검색하다가 statecharts를 찾았고, 두 아이디어는 꽤 닮아 있다고 느꼈다
내 생각엔 더 많은 소프트웨어가 상태 머신 계층을 써서 비결정성이 만드는 최악의 버그를 줄여야 한다
자동차 분야에서는 이런 방식을 오랫동안 써왔다
matlab/simulink를 보면 알고리즘을 상태 머신으로 그린 뒤 코드 생성까지 할 수 있다
최근에는 꽤 복잡한 React 컴포넌트를 관리하려고 상태 머신을 구현했는데, CSS transition을 거치며 여러 시각 상태를 오가는 구조였다
상태 머신 자체가 아주 어렵진 않았지만, 사람들이 여기에 충분히 익숙하지는 않은 듯하다
게임 엔진들도 아마 이런 것, 혹은 더 발전된 버전을 이미 구현해뒀을 것 같다
회사에서는 내가 Postgres 내부 인터프리터를 만든 뒤로 모든 비즈니스 프로세스를 statecharts로 돌리고 있다
경험이 아주 좋았고, 프로세스가 변화에 매우 강해졌으며 몇 년 뒤 다시 돌아와도 이해하기 쉽다
라이브러리도 오픈소스로 공개해뒀다 https://github.com/kronor-io/statecharts
Hacker News 의견들
statecharts가 계속 주목받는 걸 보니 반갑다
JS/TS용 상태 머신·statecharts 작성/실행/시각화 라이브러리 XState를 만들었고, https://github.com/statelyai/xstate에서 볼 수 있다
10년 넘게 작업하면서 배운 핵심은 statecharts를 단순 문서가 아니라 실행 가능한 동작으로 다룰 때 가장 가치가 크다는 점이다
모든 곳에 쓸 필요는 없고, "다음에 무슨 일이 일어나는가?"가 현재 상태와 이벤트 둘 다에 의존하는 경우 특히 강력하다
이런 차트는 "지금 이 상태에서 이 이벤트가 오면 다음 상태는 무엇이고 어떤 효과가 실행되는가?"를 답해주는 오라클처럼 쓸 수 있다
다음 메이저 버전 XState 알파도 거의 준비됐고, ergonomics, 타입 안정성, composability, 새 visualizer/editor에 초점을 두고 있다
기본적인 오픈소스 시각화 도구는 https://sketch.stately.ai에 있다
형식적 명세 쪽은 SCXML이 읽어볼 만하다: https://www.w3.org/TR/scxml
David Harel의 원 논문도 가치가 크다: https://www.weizmann.ac.il/math/harel/sites/math.harel/files/users/user50/Statecharts.pdf
Laracon에서 state machines와 statecharts에 대한 생각을 정리해 발표한 영상도 있다
https://www.youtube.com/watch?v=1A1xFtlDyzU
SCXML에 꽤 가깝게 가면서도, 특히 실행 가능한 콘텐츠에서 XML 요구를 없앤 상당히 성숙한 구현이다
prior art 섹션에 XState도 참고 사례로 들어가 있다
lit.js와 함께 페이지 너비에 반응하고 props와 내부 상태가 많은 drawer형 네비게이션 컴포넌트에 적용했는데, XState 없이는 얼마나 끔찍했을지 상상도 안 된다
다음 버전도 기대되고, 정말 고맙다
자동 TS 타입 추론이 꽤 좋아서, 가벼운 상태 머신 로직이 필요한 자리에서 쓰기 편하다
예전엔 frontend/UI ecosystem에서 statecharts가 조금씩 탄력을 받는 듯했는데, 왜인지 그 흐름이 사라진 게 아쉽다
UI 상호작용에 상태 머신, 특히 statecharts 같은 상태 머신 조합을 쓰면 복잡한 흐름을 훨씬 추론하기 쉬워진다
처음 접하는 거라면 Ian Horrucks의 "Constructing the user interface with statecharts"를 강력히 추천한다
1999년 책이지만 실제로 어떻게 적용하고 써야 하는지 설명하는 입문서로는 여전히 최고 수준이다
https://archive.org/details/isbn_9780201342789/mode/2up
주간 npm 다운로드가 400만을 넘고, Rive와 LottieFiles 같은 애니메이션 도구도 상태 머신 기능을 강하게 내세운다
LangGraph 같은 AI 도구도 상태 머신 기반 위에 올라가 있다
이런 앱과 도구들이 statecharts의 잠재력을 완전히 끌어내려면 시간이 더 필요하겠지만, 출발은 좋다
https://github.com/derkork/godot-statecharts
입문서에서 자주 빠지는 부분이 history pseudo-states다
H, H를 쓰면 바깥에서 볼 때 statechart는 형식적으로 비결정적이 된다
흔히 "현재 상태는 입력의 순수 함수"라고 설명하지만, history가 그 전제를 깨뜨린다
부모 상태로 H를 통해 다시 들어가면 마지막으로 활성화돼 있던 자식으로 복귀하므로, 같은 이벤트와 같은 바깥 상태에서도 서로 다른 내부 상태로 들어갈 수 있다
그 숨어 있는 "마지막 활성 자식" 자체가 상태인데, 다이어그램에는 보통 그려지지 않는다
Harel 원 논문도 이걸 인정하고, SCXML과 XState도 구현하지만, 정작 이 부분은 거의 이야기되지 않는다
그래서 deep history로 서브트리 상태를 재진입 시 보존한다면 bookkeeping을 차트 엔진 쪽으로 옮긴 셈이다
괜찮은 선택이긴 하지만 그림만으로는 전체 동작을 다 설명하지 못하고, history 전이도 다른 상태 로직처럼 별도 테스트가 필요하다
후자 해석이라면 기계는 완전히 결정적이며, deep history 포인터도 그냥 상태 머신 상태의 일부다
예를 들어 H, H 노드를 여러 노드로 풀고, H'를 각 노드 앞에 붙는 write-ahead log 같은 것으로 두면 된다
Temporal, DBOS, Restate 같은 durable execution 엔진과 statecharts를 결합할 수 있을지 궁금하다
회사에서는 onboarding과 payment workflow를 관리할 때 Cloudflare Workflows를 쓰는데, 자동으로 나오는 flowchart 다이어그램 덕분에 워크플로우 동작을 빠르게 이해할 수 있다
이게 결국 statecharts가 노리는 가치와 꽤 닮아 보인다
https://zindex.ai/
AI가 만드는 다이어그램은 대개 한 번 생성하고 끝나는 Mermaid/SVG/PNG라서, 갱신·검증·diff·재사용이 가능한 지속적 다이어그램 상태가 없다
Zindex는 다이어그램 자체를 구조화된 상태로 다룬다
에이전트가 Diagram Scene Protocol(DSP)로 노드, 엣지, 그룹, 관계, 제약, 리비전을 patch하면 Zindex가 validation, layout, rendering, versioning, storage를 맡는다
그래서 Temporal/DBOS/Restate/Cloudflare Workflows 옆에 붙여, 실행의 진실 원천은 엔진이 유지하고 Zindex는 코드나 실행 이력에서 파생된 영속적이고 검사 가능한 시각 모델을 관리하게 할 수 있다고 본다
사실 durable execution만 붙으면 statecharts도 충분히 해낼 수 있다
Cloudflare가 한동안 durable object actor 모델 쪽으로 가는 듯했는데, 그 프로젝트를 접었는지는 잘 모르겠다
Cloudflare Workers에 내장된 기능인지, 아니면 팀에서 직접 만든 것인지 알고 싶다
XState를 정말 좋아한다
여러 코드베이스에서 수많은 문제를 풀어줬고, 최근에는 은행권용으로 만드는 음성 앱의 핵심 골격이 됐다
시간과 노력을 이렇게 들여 훌륭하게 만들어줘서 고맙다
finite state machines 경험과, XState + Mastra로 잡았던 아키텍처를 블로그에도 조금 정리했다
출간 뒤에는 Mastra에서 Pipecat으로 갈아탔다
https://blog.davemo.com/posts/2026-02-14-deterministic-core-agentic-shell.html
이것도 같이 던져본다
ETL State Chart와 Hierarchial FSM:
https://www.etlcpp.com/state_chart.html / https://www.etlcpp.com/hfsm.html
Quantum Leaps:
https://www.state-machine.com
주로 safety-critical 시스템에서 써봤는데, 여기서는 복잡성, 타이밍, 동작 검증 가능성이 특히 중요하다
의사결정과 행동을 분리할 수 있다는 점이 큰 도움이 된다
"지금 이 상태에서 이 이벤트가 오면 다음에 무엇을 할까"로 의사결정을 깎아내리는 방식이 보통 프로그램 구조와는 조금 다르지만, 분리를 잘 만들어주고 다양한 조건에서 동작을 추론하기 쉬워진다
상태 머신의 채택이 더 커지길 늘 바랐다
AI가 생성한 코드를 인간이 쓴 코드만큼 깊이 이해하지 못하는 시대에는 state의 시각적 이해가 점점 더 중요해진다
그래도 프런트엔드 프레임워크에서는 여전히 store 기반 reactive state를 더 선호하는 듯하다
나 역시 그걸 기본값으로 쓰는 편이라 굳이 바꾸지 않았고, xstate 같은 라이브러리는 문법을 배우기 더 어렵고 장황하다는 인식도 있다
그런데 AI가 있으면 그 장벽은 거의 줄어들기 때문에, 내가 못 본 다른 이유가 있는지, 아니면 statechart가 아직 정점을 못 찍은 건지 궁금하다
API 표면적도 줄고, 학습 곡선도 낮아지고, 개발자와 에이전트 모두가 작성하기 쉬워진다
동시에 최신 frontier 모델들은 이미 XState 코드를 꽤 잘 작성한다
https://github.com/xlnfinance/xln 프로젝트를 하다가, 실제 네트워크를 결정적으로 에뮬레이션할 방법이 필요하다는 걸 깨달았다
그러다 모든 블록체인은 결국 replicated state machine인데, 그렇다면 각 사용자 노드를 Runtime -> Entity -> Account의 3단계 상태 머신 계층으로 감싸면 되지 않을까 싶어졌다
바깥 머신이 안쪽 머신을 완전히 제어하는 구조라서, 서로 다른 합의 모드를 가진 "blockchain inside blockchain" 같은 그림이다
이후 "hierarchical state machines"를 검색하다가 statecharts를 찾았고, 두 아이디어는 꽤 닮아 있다고 느꼈다
내 생각엔 더 많은 소프트웨어가 상태 머신 계층을 써서 비결정성이 만드는 최악의 버그를 줄여야 한다
자동차 분야에서는 이런 방식을 오랫동안 써왔다
matlab/simulink를 보면 알고리즘을 상태 머신으로 그린 뒤 코드 생성까지 할 수 있다
최근에는 꽤 복잡한 React 컴포넌트를 관리하려고 상태 머신을 구현했는데, CSS transition을 거치며 여러 시각 상태를 오가는 구조였다
상태 머신 자체가 아주 어렵진 않았지만, 사람들이 여기에 충분히 익숙하지는 않은 듯하다
회사에서는 내가 Postgres 내부 인터프리터를 만든 뒤로 모든 비즈니스 프로세스를 statecharts로 돌리고 있다
경험이 아주 좋았고, 프로세스가 변화에 매우 강해졌으며 몇 년 뒤 다시 돌아와도 이해하기 쉽다
라이브러리도 오픈소스로 공개해뒀다
https://github.com/kronor-io/statecharts