▲

Statecharts: 계층적 상태 기계

 (statecharts.dev)
1P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 복잡한 시스템의 행동을 시각적으로 구조화하는 형식으로, 기본 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?, What is a statechart?에서 이어짐

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에서 이어짐

실행 가능한 Statecharts

  • 문서로만 statechart를 쓰는 대신, 실행 가능한 machine format을 설계와 런타임에 함께 쓸 수 있음
  • 하나의 정의를 single source of truth로 삼아 실제 런타임 동작과 시각적 다이어그램을 함께 구동할 수 있음
  • 다이어그램을 코드로 옮기는 작업이 필요 없어짐
  • 손으로 번역하면서 생기는 버그를 줄일 수 있음
  • 다이어그램과 구현이 항상 동기화된 상태를 유지함
  • 다이어그램이 더 정밀해짐
  • 반대로 다이어그램은 꽤 복잡해질 수 있음
  • 실행 가능한 statechart를 위한 포맷과 도구 선택지는 제한적임
  • statechart와 컴포넌트 사이의 타입 안전성을 강하게 보장하기는 어려움
  • 코드 안에 statechart 정의가 있다면 그 표현을 이용해 시각적 statechart를 자동 생성할 수 있음
    • 정의가 JSON이나 XML 같은 별도 파일에 있을 때 더 단순해짐

커뮤니티와 추가 자료

함께 보면 좋은 글 β

▲
GN⁺ 5시간전  [-]
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

    • 당신 덕분에 처음으로 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

답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.