상태 관리의 본질을 향해, 아토믹 스테이트의 가능성

시간이 흘러, Zustand는 이제 React 생태계에서 어엿한 이름으로 자리 잡았다. 커뮤니티의 도움으로 유지보수 부담은 조금씩 분산되었고, 다이시 카토는 다시 코드와 아키텍처에 대해 깊이 사색할 여유를 조금이나마 되찾을 수 있었다. 그는 자신이 만든 Zustand가 수많은 개발자들의 고통을 덜어주고 있다는 사실에 뿌듯함을 느꼈지만, 그의 탐구적인 정신은 거기서 멈추지 않았다.

‘Zustand… 분명 많은 문제를 해결했어. 하지만 이게 상태 관리의 궁극적인 형태일까?’

늦은 밤, 카토는 자신의 모니터에 떠 있는 Zustand 코드를 바라보며 상념에 잠겼다. 외부 스토어, 선택적 구독, 간결한 훅 API. 이 조합은 분명 효율적이고 우아했다. 하지만 그의 마음속 깊은 곳에서는 여전히 풀리지 않는 질문 하나가 맴돌고 있었다.

상태(State)란 무엇인가? 애플리케이션을 구성하는 데이터 조각들의 집합. 그렇다면 그 ‘조각’을 어디까지 잘게 쪼갤 수 있을까?

Zustand는 거대한 상태 객체를 하나 두고, 셀렉터(selector)를 통해 필요한 부분만 꺼내 쓰는 방식이었다. 마치 잘 정리된 거대한 창고에서 필요한 물건만 콕 집어 찾아오는 것과 같았다. 효율적이었지만, 여전히 ‘하나의 큰 창고’라는 전제에서 벗어나지는 못했다.

‘만약… 창고 자체가 없다면? 그냥 필요한 물건들만 낱개로 존재한다면?’

그의 머릿속에 새로운 발상이 떠올랐다. 상태를 거대한 객체로 관리하는 것이 아니라, 더 이상 쪼갤 수 없는 가장 작은 단위, 마치 물질을 이루는 원자(Atom)처럼 다루는 것이다.

예를 들어, 사용자의 이름 상태, 다크 모드 활성화 상태, 장바구니 개수 상태… 이 각각이 독립적인 ‘상태 원자(State Atom)’가 되는 것이다. 이 원자들은 서로를 전혀 알지 못하고, 오직 자신의 값만을 가지고 존재한다.

그렇다면 여러 상태가 조합되어야 하는 파생 상태(Derived State)는 어떻게 처리할까? 예를 들어, ‘장바구니 총 가격’ 같은 상태는 개별 상품의 가격과 수량이라는 여러 원자에 의존한다.

‘파생 상태는… 그저 함수일 뿐이야!’

카토는 무릎을 쳤다. 파생 상태를 위한 별도의 저장 공간이나 로직이 필요한 것이 아니었다. 그저 필요한 원자들을 읽어서 계산하는 순수 함수(Pure Function). 그것으로 충분했다!

// 아토믹 스테이트 개념 스케치
const firstNameAtom = atom('Daishi');
const lastNameAtom = atom('Kato');

// 파생 상태는 그저 함수! (어떤 atom에 의존하는지만 명시)
const fullNameAtom = atom((get) => `${get(firstNameAtom)} ${get(lastNameAtom)}`);

// 컴포넌트에서는 필요한 atom만 사용
function Profile() {
  const fullName = useAtomValue(fullNameAtom); // fullNameAtom 값 사용
  return <div>{fullName}</div>;
}

이 아이디어는 섬광처럼 그의 뇌리를 관통했다. 이 방식의 잠재력은 엄청났다.

첫째, 극강의 모듈성. 각 상태 원자는 완전히 독립적이므로, 코드베이스 어디서든 쉽게 정의하고 사용할 수 있다. 상태 로직이 특정 스토어 구조에 묶이지 않는다.
둘째, 자동화된 의존성 추적. 파생 상태 함수는 자신이 어떤 원자에 의존하는지만 명시하면 된다. 프레임워크(혹은 라이브러리)가 알아서 해당 원자들이 변경될 때만 파생 상태를 다시 계산하고, 그 파생 상태를 사용하는 컴포넌트만 리렌더링한다. 개발자는 더 이상 수동으로 의존성을 관리하거나 최적화에 신경 쓸 필요가 없다.
셋째, 궁극의 간결함. 상태 정의는 atom(...) 한 줄, 사용은 useAtom(...) 한 줄. 보일러플레이트가 거의 존재하지 않는다.

‘이건… Zustand와는 완전히 다른 접근 방식이야.’

Zustand가 잘 닦인 고속도로처럼 명확한 길을 제시한다면, 이 아토믹 모델은 마치 레고 블록처럼 무한한 조합의 가능성을 열어주는 방식이었다. 더 유연하고, 더 분산적이며, 어쩌면 상태 관리의 본질에 더 가까울지도 모르는.

물론 이 아이디어 역시 해결해야 할 기술적 과제들이 산적해 있었다. 어떻게 수많은 아톰들의 의존성 그래프를 효율적으로 관리할 것인가? 가비지 컬렉션(Garbage Collection)은 어떻게 처리할 것인가? 비동기 아톰은 어떻게 다룰 것인가?

하지만 카토는 직감했다. 이 ‘아토믹 스테이트’라는 개념 속에 상태 관리의 또 다른 미래가 숨 쉬고 있다는 것을. Zustand를 통해 Context의 벽을 넘었던 것처럼, 이제 그는 상태 관리의 더 근본적인 차원을 향해 나아가고 있었다.

그의 머릿속에서는 이미 새로운 라이브러리의 청사진이 그려지기 시작했다. Zustand와는 다른 철학, 다른 구조를 가진, 원자적 상태 관리자. 이것이 바로 훗날 ‘Jotai(조타이)’ 라는 이름으로 세상에 나오게 될 아이디어의 씨앗이었다.

Zustand의 성공은 끝이 아니었다. 그것은 카토에게 더 깊은 질문을 던졌고, 그 질문은 또 다른 혁신을 향한 문을 열어주었다. 개발자의 여정은 결코 멈추지 않는다는 것을, 그는 다시 한번 깨닫고 있었다. 그의 심장은 새로운 가능성을 향해 다시 뛰기 시작했다.