# Statecharts: 계층적 상태 기계 > Clean Markdown view of GeekNews topic #28938. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28938](https://news.hada.io/topic?id=28938) - GeekNews Markdown: [https://news.hada.io/topic/28938.md](https://news.hada.io/topic/28938.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-27T12:35:20+09:00 - Updated: 2026-04-27T12:35:20+09:00 - Original source: [statecharts.dev](https://statecharts.dev/) - Points: 1 - Comments: 1 ## Topic Body - **복잡한 시스템의 행동**을 시각적으로 구조화하는 형식으로, 기본 **state machine**을 확장해 state explosion 문제를 다루도록 보강됨 - **행동과 컴포넌트의 분리**가 가능해져 동작 변경과 코드 추론이 쉬워지고, 컴포넌트와 독립적인 테스트와 **예외 상황 탐색**에도 잘 맞음 - statechart를 만드는 과정에서 가능한 상태를 전부 탐색하게 되며, statechart 기반 코드는 전통적인 코드보다 **버그 수가 더 낮았던 연구 결과**도 있음 - **SCXML 표준**과 여러 언어의 도구·라이브러리를 통해 모델을 읽고 작성하고 실행할 수 있으며, **entry/exit action** 같은 동작 순서를 올바르게 처리하는 데 도움을 줌 - **실행 가능한 machine format**을 쓰면 하나의 정의를 single source of truth로 삼아 런타임 동작과 다이어그램을 함께 유지할 수 있어, 구현과 설계의 **동기화 유지**가 중요해짐 --- ### Statecharts 개요 - **Statechart**는 복잡한 시스템을 다루기 위한 시각적 형식으로, 기본적인 **state machine**을 확장한 형태임 - state machine이 커질수록 생기는 **state explosion** 문제를 다루도록 보강됨 - 동작을 그림으로 표현할 수 있지만, 소프트웨어 엔지니어링에서는 시각화 자체보다 **행동 모델링**과 구조화에 더 가까움 - 관련 기초 설명은 [What is a state machine?](https://statecharts.dev/what-is-a-state-machine.html), [What is a statechart?](https://statecharts.dev/what-is-a-statechart.html)에서 이어짐 ### Statecharts를 쓰는 이유 - **이해하기 쉬운 구조**를 가져서 다른 많은 코드 형태보다 파악하기 쉬움 - **행동과 컴포넌트의 분리**가 가능함 - 동작 변경이 더 쉬워짐 - 코드 추론이 더 쉬워짐 - 컴포넌트와 독립적으로 행동을 테스트할 수 있음 - statechart를 만드는 과정에서 **가능한 상태를 전부 탐색**하게 됨 - statechart 기반 코드는 전통적인 코드보다 **버그 수가 더 낮았던 연구 결과**가 있음 - 놓치기 쉬운 **예외 상황**을 다루는 데 잘 맞음 - 복잡성이 커질수록 **확장성**이 좋아짐 - 개발자가 아닌 사람도 이해하기 쉽고, QA는 **탐색 도구**로 활용할 수 있음 - 이미 많은 코드가 암묵적으로 state machine을 담고 있으며, statechart는 이를 **명시적으로 드러내는 방식**으로 작동함 ### Statecharts의 부담과 반대 요인 - **새로운 학습 비용**이 필요함 - 기반 개념인 state machine 자체는 많은 프로그래머에게 익숙할 수 있음 - 기존 코딩 방식과 꽤 달라서 **낯선 패러다임**으로 느껴질 수 있음 - 팀 차원에서 거부감이 생길 수 있음 - 작은 statechart에서는 동작을 분리하는 과정 때문에 **코드 줄 수가 늘어날 수 있음** - 널리 쓰이지 않는 이유로는 **인지 부족**과 YAGNI가 함께 작용함 - 흔한 반대 논리로는 굳이 필요하지 않다는 점, 특정 기술 흐름에 맞지 않는다는 점, 라이브러리 수가 늘어난다는 점이 꼽힘 - 웹 애플리케이션에서는 로드 시간이 늘 수 있음 - 이런 장단점을 함께 보더라도 도입 효과는 전반적으로 **순이익**에 가까움 ### 사용 방식과 SCXML - **SCXML**은 2005년부터 2015년까지 W3C에서 표준화한 형식으로, statechart의 다양한 의미 규칙과 **엣지 케이스 처리**를 정의함 - 여러 언어에서 SCXML을 읽고 작성하고 실행하는 도구가 있음 - 같은 **모델**을 유지하면서 문법만 다른 파생 형식도 있음 - 다양한 플랫폼용 statechart 라이브러리가 있으며, SCXML 의미 규칙을 각기 다른 수준으로 지원함 - 이런 라이브러리를 쓰면 **entry/exit action** 같은 동작 순서를 올바르게 처리하는 데 도움이 됨 - 추가 사용 가이드는 [how to use statecharts](https://statecharts.dev/how-to-use-statecharts.html)에서 이어짐 ### 실행 가능한 Statecharts - 문서로만 statechart를 쓰는 대신, **실행 가능한 machine format**을 설계와 런타임에 함께 쓸 수 있음 - 하나의 정의를 **single source of truth**로 삼아 실제 런타임 동작과 시각적 다이어그램을 함께 구동할 수 있음 - **다이어그램을 코드로 옮기는 작업**이 필요 없어짐 - 손으로 번역하면서 생기는 버그를 줄일 수 있음 - 다이어그램과 구현이 항상 **동기화된 상태**를 유지함 - 다이어그램이 더 정밀해짐 - 반대로 다이어그램은 꽤 복잡해질 수 있음 - 실행 가능한 statechart를 위한 **포맷과 도구 선택지**는 제한적임 - statechart와 컴포넌트 사이의 **타입 안전성**을 강하게 보장하기는 어려움 - 코드 안에 statechart 정의가 있다면 그 표현을 이용해 시각적 statechart를 자동 생성할 수 있음 - 정의가 JSON이나 XML 같은 별도 파일에 있을 때 더 단순해짐 ### 커뮤니티와 추가 자료 - 커뮤니티 대화는 [gitter.im](https://gitter.im/statecharts/statecharts)에서 이어지며, 로그인 없이 채팅을 볼 수 있음 - 질의응답 성격의 토론은 [statecharts GitHub discussions](https://github.com/statecharts/statecharts/discussions)에서 이어짐 - 책과 발표 자료는 [resources](https://statecharts.dev/resources.html) 페이지에 모여 있음 - 직접 작성한 자료는 [GitHub Discussions](https://github.com/statecharts/statecharts/discussions)에 공유할 수 있음 - ## 추가 읽을거리 - [Use case: Statecharts in User Interfaces](https://statecharts.dev/use-case-statecharts-in-user-interfaces.html) - [Concepts](https://statecharts.dev/concepts.html) — statechart의 핵심 개념과 다이어그램에서의 모습 - [Glossary](https://statecharts.dev/glossary/) — 자주 쓰이는 용어와 정의 - [FizzBuzz](https://statecharts.dev/fizzbuzz.html) — FizzBuzz를 바탕으로 statechart 개념을 다룸 - [Acknowledgements](https://statecharts.dev/acknowledgements.html) ## Comments ### Comment 56375 - Author: neo - Created: 2026-04-27T12:35:22+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47908833) - **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]() - 당신 덕분에 처음으로 **state machines**를 알게 됐다 Laracon에서 state machines와 statecharts에 대한 생각을 정리해 발표한 영상도 있다 [https://www.youtube.com/watch?v=1A1xFtlDyzU]() - Clojure 쪽에서는 [https://github.com/fulcrologic/statecharts]()를 추천할 만하다 **SCXML**에 꽤 가깝게 가면서도, 특히 실행 가능한 콘텐츠에서 XML 요구를 없앤 상당히 성숙한 구현이다 prior art 섹션에 XState도 참고 사례로 들어가 있다 - **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의 잠재력을 완전히 끌어내려면 시간이 더 필요하겠지만, 출발은 좋다 - 나도 이 **Godot plugin**을 보다가 statecharts를 알게 됐다 [https://github.com/derkork/godot-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에 내장된 기능인지, 아니면 팀에서 직접 만든 것인지 알고 싶다 - **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가 아직 정점을 못 찍은 건지 궁금하다 - 다음 **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]()