https://www.youtube.com/watch?v=Hv_PhrfwerQ
최근에 웹접근성 미션 때문에 캐러셀 컴포넌트를 구현해야 했었다. 그런데 생각보다 동작이 복잡했고, 엮여있는 상태들의 경우의 수가 많았다.
이렇게 복잡한 UI 컴포넌트 개발을 끊임없이 하게 될 텐데, 이 때마다 이렇게 고통 받아야할까? 막연한 기분으로 필요할 때 마다 상태를 정의하고, 상태에 따라서 어떠한 사이드이펙트가 날 지 정의하고 해야하는걸까? 하는 고민이 들어서 보게 된 영상이다. 영상에서는 Finite State Machine, 즉 상태머신을 소개하고 Statecharts 를 소개한다. 엄청나게 어려운 개념은 아니고, 어떠한 UI 에 엮여있는 상태들을 미리 설계하고 정리해놓는 것이다. 자세한 내용은 아래와 같다.
- 액션에는 많은 사전조건이 붙는다.
- 대부분의 상태변경은 사이드 이펙트를 수반한다.
- DB, 캐시, 쿠키 등 다양한 맥락에 의존한다.
- 하나의 상태로부터 또다른 상태들이 파생된다.
- 상태들의 의존성을 추적하고 동기화하는데 많은 비용이 든다.
- UI 는 우리 생각보다 더 복잡하다.
- 작은부분부터 만들다보면, 코드가 이해하기 어려워진다.
- 데이터 모델링의 중요성은 이해해도, 동작의 모델링은 과소평가되는 경향이 있다.
- 항상 단일 초기 상태를 가진다.
- 유한한 개수의 상태를 가진다.
- 유한한 개수의 이벤트를 가진다.
- 이벤트에 의해 다음 상태로 전환한다.
- 위와 같은 특징을 갖는, promise 는 결국 하나의 상태 머신이다.
- YAGNI
- 예상하지 못한 동작을 고치기 위해 새로운 상태 추가하지 않기
- 미리 제한한 상태로부터 동작을 예상 가능하게 바꾸기.
- 리액트에서는 리듀서를 사용해보기.
- 미리 동작을 예상하고 설계를 해도, 엣지케이스들이 많다.
- 설계할 때 빼먹은 상태
- 기능 추가
- 엣지 케이스 대응 기존의 상태머신에 새로운 상태를 추가 할 때, 모델링 해야하는 상태와 상태간의 연결 개수가 폭발적으로 증가하는 현상
- 상태머신을 통한 모델링의 한계를 해결하기 위해 몇가지 개념 도입
- State-Diagram (상태 다이어그램)
- Depth (깊이)
- 중첩 상태머신
- Orthogonality (직교성)
- Broadcast-communication (브로드캐스트)
- 상태차트가 컴포넌트 동작을 주도하면 코드를 두 개의 모듈로 분리 할 수 있다.
- 어떤 일을 실행할 것인가와 어떻게 실행할 것인가로 분리할 수 있다.
- 이건 관심사의 분리를 따르므로, 그 자체로도 의미가 있다.
- 어떤 컴포넌트가 비즈니스 로직이 실행되는 방식을 구현하고 상태차트는 언제 어떤 일이 발생하는지, 즉 어떤 이벤트 시퀀스가 해당 비즈니스 로직을 실행시키는지에 대한 규칙을 인코딩 한다.
- 아래와 같은 이점이 있다. - 동작 변경이 더 쉽다. - 코드를 쉽게 추론 할 수 있다. - 동작 모델이 컴포넌트와 관계 없이 독립적으로 테스트 가능하다. - 팀 커뮤니케이션
물론 발표에도 나온 것 처럼 YAGNI 를 생각하면 위와 같이 상태차트를 미리 설계해놓는 것이 어쩌면 비효율적일 수 있겠다.
하지만, 내가 생각하기에 상태들이 복잡하게 얽혀있는 UI 개발의 가장 큰 문제점은 협업에서 나온다고 생각하기 때문에 상태차트의 활용이, 그러한 UI 개발에서는 빛을 볼 수 있다고 생각한다.
UI 상태가 복잡해질 수록 코드를 추론하기 어려워지고 유지보수에 비용이 크게 든다. 또한 개발자가 아닌 동료들이 볼 때 해당 UI 는 간단해보일 수 있어서 다른 요구사항을 쉽게 추가하자고 제안 할 수도 있다. (나 역시도 캐러셀을 직접 구현하기 전까지는 간단할 줄 알았다.)
이 때 상태차트를 사용한다면 보다 더 원활한 협업을 할 수 있지 않을까 생각해본다.