if문 지옥에서 벗어나는 길 - Statecharts로 복잡한 상태를 다스리기

코드가 if문 덩어리가 되는 이유

버튼 하나 만들었을 뿐인데 코드가 점점 누더기가 되는 경험, 다들 한 번쯤 있으시죠. "로딩 중이면서 비활성화", "에러 났는데 재시도 가능한 상태", "로그인은 됐는데 약관 동의는 안 한 상태"... 이런 조건이 늘어날수록 if문이 가지처럼 뻗어나가고, 어느 순간 손을 못 댈 정도가 됩니다.

statecharts.dev라는 사이트가 화제(아, 이런 표현은 빼고)... 다시 말해 statecharts.dev라는 학습 사이트가 다시 주목받고 있어요. 이게 뭐냐면, 계층적 상태 머신(Hierarchical State Machine) 이라는 개념을 처음 접하는 사람도 따라갈 수 있게 정리해 놓은 곳이거든요. 1987년에 David Harel이라는 컴퓨터 과학자가 만든 개념인데, 최근 프론트엔드 쪽에서 XState 같은 라이브러리가 인기를 끌면서 다시 조명받고 있습니다.

상태 머신이라는 게 뭔데

쉽게 말하면 "내 앱은 지금 어떤 상태인가?" 를 명확하게 정의하고, "어떤 이벤트가 오면 어떤 상태로 바뀌는가?" 를 표로 정리해 두는 방식이에요.

예를 들어 신호등을 생각해보세요. 빨강, 노랑, 초록 세 가지 상태가 있고, "타이머"라는 이벤트가 오면 정해진 순서로 바뀌잖아요. 빨강에서 갑자기 초록으로 점프하는 일은 없죠. 이런 식으로 "가능한 상태와 가능한 전이"를 미리 정의해두면, 잘못된 상태 조합 자체가 만들어질 수 없어요. 흔히 말하는 "불가능한 상태를 불가능하게 만든다(make impossible states impossible)"는 철학이 여기서 나옵니다.

그런데 일반적인 상태 머신만 쓰면 또 다른 문제가 생겨요. 상태가 30개, 50개로 늘어나면 전이 화살표가 거미줄처럼 얽히거든요. "로딩 중"인데 그 안에서도 "첫 로딩", "재시도 로딩", "백그라운드 새로고침"이 또 나뉘는 식이죠. 이걸 평평하게 펼치면 머리가 터집니다.

Statecharts가 푸는 방식: 계층화와 병렬성

Statecharts는 여기에 두 가지 무기를 더해줘요.

첫 번째가 계층(hierarchy) 입니다. 상태 안에 상태를 둘 수 있어요. 예를 들어 "재생 중"이라는 큰 상태 안에 "일반 재생", "느리게 재생", "빠르게 재생" 같은 하위 상태를 두는 거죠. 그리고 "정지" 이벤트가 오면, 어느 하위 상태에 있든 상관없이 "재생 중" 전체에서 빠져나갑니다. 공통 처리를 부모 상태에 한 번만 써두면 되니까 코드 중복이 확 줄어요. 객체지향에서 상속이 코드를 재사용하는 방식이랑 비슷한 느낌이라고 보시면 돼요.

두 번째가 병렬 상태(parallel states) 예요. 한 시점에 여러 축의 상태가 동시에 존재할 수 있게 해줘요. 예를 들어 음악 앱이 "재생 중이면서 + 셔플 켜져 있고 + 가사 표시 중" 이런 식으로 세 가지 축이 독립적으로 굴러가야 하잖아요. 옛날 방식대로 곱셈으로 다 펼치면 상태가 8개(2×2×2)가 되지만, 병렬로 표현하면 3개 영역만 관리하면 됩니다. 상태가 폭발하는 걸 막아주는 거예요.

그리고 가드(guard), 액션(action), history state 같은 부가 기능들도 있어요. 가드는 "이 조건이 참일 때만 전이를 허용"하는 장치고, history state는 "이전에 어디 있었는지 기억해뒀다가 돌아가기"를 가능하게 해줘요.

업계 흐름: XState와 그 너머

실무에서 statecharts를 쓰는 가장 유명한 도구가 XState입니다. 자바스크립트/타입스크립트 라이브러리인데, React, Vue, Svelte 어디서든 쓸 수 있어요. 시각화 도구도 잘 돼 있어서 상태 다이어그램을 그래프로 보면서 디버깅할 수 있다는 게 큰 장점이고요.

비슷한 결의 도구들도 있어요. Redux의 reducer 패턴도 일종의 상태 머신이라고 볼 수 있고, MobX는 좀 더 반응형 쪽이고, Zustand나 Jotai는 가벼운 상태 관리에 가깝죠. 그런데 "상태가 정말 많고 복잡한 워크플로"(예: 결제 플로우, 폼 마법사, 비디오 플레이어, 실시간 게임 로직)에는 statecharts 기반 접근이 압도적으로 명료해요.

백엔드 쪽에서도 워크플로 엔진(Temporal, Camunda 같은)들이 비슷한 발상을 공유합니다.

한국 개발자에게

주니어 분들은 "내가 짠 컴포넌트의 if문이 5개를 넘어간다" 싶으면 한 번 statecharts 관점으로 다시 그려보시는 걸 추천해요. 노트에 동그라미와 화살표만 그려봐도, 빠뜨린 케이스가 보입니다. 결제, 로그인, 영상 플레이어, 모달 같은 데에 특히 잘 맞아요. 시니어라면 팀원들과 상태 다이어그램을 공유 자산으로 두는 문화를 만들어보세요. 새 기능 명세를 statechart로 그려서 PM, 디자이너와 함께 보면 "엣지 케이스를 미리 합의"할 수 있어서 버그가 정말 줄어듭니다.