Elm 아키텍처를 TypeScript로: Foldkit이 프론트엔드 상태 관리를 다시 정의하는 방식 (foldkit.dev)

한줄 요약

Effect-TS 기반 Foldkit은 Elm 아키텍처를 TypeScript 프론트엔드에 이식해 상태 관리의 예측 가능성을 구조적으로 보장한다.

무엇이 달라지나?

프론트엔드 개발에서 상태 관리는 오랫동안 "각자 알아서" 영역이었다. React는 렌더링 레이어를 제공하고, 그 위에 Zustand를 얹을지 Jotai를 쓸지, 사이드 이펙트는 React Query로 처리할지 직접 구현할지—이 결정들을 개발자가 매번 내려야 했다. 팀마다 패턴이 달라지고, 코드베이스가 커질수록 의도치 않은 결합이 생긴다.

Foldkit은 이 문제를 다른 방향에서 접근한다. "렌더링은 우리가, 아키텍처도 우리가" 가 이 프레임워크의 입장이다.

구체적으로 세 가지가 핵심이다.

단일 불변 모델. 애플리케이션 전체 상태는 하나의 Schema로 정의된 불변 객체다. 상태를 바꾸려면 반드시 update 함수를 거쳐야 하고, 이 함수는 현재 모델과 메시지를 받아 새 모델과 커맨드 배열을 반환한다. 숨겨진 뮤테이션이 끼어들 여지가 없다.

사이드 이펙트의 명시적 서술. Foldkit에서 사이드 이펙트는 핸들러 안에 묻힌 명령형 코드가 아니라, update가 반환하는 커맨드 값이다. "3초 후 카운터를 초기화하라"는 동작은 DelayReset 커맨드를 반환하는 것으로 표현되고, 실제 실행 시점과 방법은 런타임이 결정한다. 이 구조 덕분에 update 함수는 순수 함수로 유지되고, 테스트가 극적으로 단순해진다.

Effect-TS와의 완전한 통합. Foldkit 애플리케이션 자체가 Effect이고, 모든 상태는 Effect Schema로 정의된다. Effect 생태계를 이미 쓰고 있다면 전환 비용이 낮고, 처음 접한다면 Foldkit을 통해 Effect의 개념을 실무 맥락에서 학습할 수 있다.

이 설계는 Elm 언어에서 검증된 "The Elm Architecture"를 TypeScript로 이식한 것이다. Elm 커뮤니티에서 수년간 확인된 패턴—메시지 기반 상태 전이, 커맨드로 표현된 이펙트—을 자바스크립트 생태계가 가진 유연성과 결합한 시도로 볼 수 있다.

실무에서 어떤 의미인가?

외주 개발이나 팀 프로젝트에서 가장 자주 발생하는 문제 중 하나는 "코드를 새 사람이 이해하는 데 걸리는 시간"이다. Foldkit이 내세우는 "50개 파일짜리 앱도 5개 파일짜리 앱과 같은 패턴을 따른다"는 주장은 이 문제에 직접 대응한다. 패턴이 통일되면 온보딩 비용이 줄고, 특정 개발자에 대한 의존도도 낮아진다.

테스트 방식도 눈에 띈다. Foldkit은 두 가지 테스트 프리미티브를 제공한다. Story는 순수 함수인 update에 메시지를 순서대로 전달하며 모델과 커맨드를 검증한다. Scene은 실제 뷰를 렌더링하고 접근성 로케이터를 통해 버튼 클릭, 입력, 결과 확인을 시나리오처럼 기술한다. DOM 목킹이 필요 없고, 테스트 코드가 사용자 시나리오를 그대로 표현한다.

DevTools도 이 아키텍처의 직접적인 혜택이다. 모든 상태 변화가 메시지와 단일 모델을 통하기 때문에, 과거 특정 시점의 UI로 되돌리는 타임트래블이 구조적으로 가능하다. 나아가 AI 에이전트가 MCP를 통해 현재 모델 상태와 메시지 히스토리에 접근할 수 있다는 점은, 디버깅 자동화 측면에서 흥미로운 가능성을 열어둔다.

라우팅, UI 컴포넌트, 폼 유효성 검사, 서브모델, 구독, WebSocket 같은 장수 브라우저 리소스 관리까지 내장되어 있다. 별도 라이브러리를 조합하지 않아도 하나의 일관된 시스템으로 동작한다는 점은, 특히 소규모 팀이나 빠른 프로토타이핑을 원하는 프로젝트에서 도입 마찰을 줄인다.

도입 전 체크포인트

Foldkit은 현재 베타 상태다. 프로덕션 도입을 검토한다면 아래 항목을 먼저 확인하는 것이 좋다.

학습 곡선. Effect-TS와 Elm 아키텍처 모두 익숙하지 않은 개발자에게는 초기 진입 장벽이 있다. 함수형 프로그래밍의 핵심 개념—순수 함수, 불변성, 대수적 데이터 타입—을 팀이 어느 정도 이해하고 있는지 점검해야 한다.

기존 코드베이스와의 통합. Foldkit은 Runtime.embed를 통해 기존 호스트 애플리케이션 안에 위젯 형태로 삽입하는 방식을 지원한다. 전면 재작성 없이 점진적 도입이 가능하다는 뜻이지만, Schema 타입으로 정의된 포트를 통해 데이터를 교환해야 하므로 인터페이스 설계에 추가 공수가 필요하다.

생태계 성숙도. 베타 프레임워크는 API 변경 가능성이 있다. 장기 유지보수가 중요한 프로젝트라면 커뮤니티 규모와 릴리즈 속도를 모니터링하며 판단을 늦추는 것이 현실적이다.

Effect-TS 도입 여부. Foldkit의 이점은 Effect-TS를 함께 쓸 때 온전히 발휘된다. Effect를 처음 도입하는 팀이라면 Foldkit과 Effect 두 가지를 동시에 학습해야 한다는 점을 감안해야 한다.

React 중심의 기존 프로젝트를 당장 교체하기보다는, 신규 프로젝트나 독립적인 서브시스템에서 먼저 시도해보는 접근이 리스크를 줄이는 현실적인 방법이다.