당근이 Redux를 서버로 가져간 이유

프론트엔드 상태 관리의 대명사인 Redux 패턴이 서버 아키텍처의 중심에 놓인다면 어떤 모습일까. 당근 테크 블로그에 올라온 Ventyd 개발기를 읽고 한참을 생각에 잠겼다.

#프론트엔드 코어팀이 만든 서버 아키텍처 도구

당근이 공개한 Ventyd는 TypeScript 기반 이벤트 소싱 라이브러리다. 흥미로운 건 이걸 만든 팀이 백엔드가 아니라 프론트엔드 코어팀이라는 점이다. 보통 이벤트 소싱이라 하면 Java나 Kotlin 생태계의 Axon Framework, EventStoreDB를 떠올린다. 당근은 이걸 Node.js와 TypeScript 생태계로 가져왔고, 그 과정에서 Redux의 멘탈 모델을 통째로 차용했다.

Node.js 쪽에서 이벤트 소싱을 시도한 프로젝트가 아예 없던 건 아니다. EventStoreDB gRPC 클라이언트나 Oskar Dudycz의 EventSourcing.NodeJS 같은 레퍼런스가 있지만, TypeScript 네이티브로 처음부터 설계된 라이브러리는 찾기 어려웠다. 대부분 JavaScript 시절 코드를 끌고 가거나 특정 데이터베이스에 강하게 결합돼 있다.

블로그 글을 쓴 Tony에 따르면, 처음엔 단순 CRUD로 충분했던 서비스들이 감사 처리, 롤백, 알림 같은 복잡한 요구사항 앞에서 한계를 드러냈고, 이벤트 소싱 도입을 결정했다고 한다. 팀이 이미 Redux로 체화한 "액션 → 리듀서 → 상태" 흐름을 서버에 그대로 옮겼다. 프론트엔드 경험이 백엔드 설계에 직접 영향을 준 드문 사례다.

#Redux와 Ventyd — 진짜 동형인가

처음엔 마케팅 비유인가 싶었는데, 코드를 까보면 정말 그렇다.

Redux에서 dispatch(action)으로 상태를 변경하고, reducer(state, action)으로 새 상태를 반환하며, store.getState()로 현재 상태를 조회한다. Ventyd에서는 append(event)로 이벤트를 기록하고, reduce(state, event)로 프로젝션을 만들고, getState()로 현재 상태를 읽는다. 이름만 다를 뿐 패턴이 1:1로 대응된다.

이 동형성의 실질적 가치는 팀 커뮤니케이션에 있다. 백엔드 엔지니어가 "이벤트 소싱으로 설계했습니다"라고 말하면 프론트엔드 엔지니어가 "Redux 서버 버전이군요"라고 바로 받아칠 수 있다. 당근처럼 풀스택 지향이 강한 조직에서 이 공통 언어는 온보딩 비용 절감으로 직결된다. 새로 합류한 프론트엔드 개발자가 서버 코드를 열어봤을 때 "이거 낯설지 않은데?"라는 반응이 나올 수 있다.

한 가지 더 — 리듀서가 순수 함수이기 때문에 테스트 작성이 프론트엔드만큼 쉽다. 입력과 출력이 결정적이니 mock이 필요 없다. 서버 코드 테스트에서 이 정도 간결함을 확보하는 건 실무에서 꽤 큰 장점이다.

#Standard Schema — 짧지만 날카로운 선택

기술적으로 눈에 띄는 결정은 Standard Schema 스펙 채택이다. Zod든 Valibot이든 ArkType이든, Standard Schema를 구현한 라이브러리면 뭐든 끼울 수 있다. TypeScript 진영의 밸리데이션 라이브러리 전쟁에 끼지 않고 추상 레이어 위에 선 것. 특정 도구에 묶였다가 커뮤니티 이동으로 마이그레이션 지옥에 빠지는 사례를 충분히 봐 왔을 테니, 현명한 판단이다.

#왜 한국에서 이벤트 소싱 오픈소스가 드문가

국내 기술 블로그에서 이벤트 소싱을 진지하게 다룬 사례가 흔치 않다. 우아한형제들이 CQRS 관련 세션을 몇 차례 진행했고 토스에서도 간간이 언급하지만, 직접 라이브러리를 만들어 오픈소스로 공개한 건 당근이 사실상 처음이다.

이유는 단순하다. 도입 비용이 높다. 상태를 직접 업데이트하는 대신 이벤트를 누적해서 상태를 재구성하는 구조는 단순 CRUD에 과한 설계다. 이벤트 스토어 운영, 프로젝션 동기화, 스냅샷 전략 같은 운영 이슈가 줄줄이 따라온다. 대부분의 스타트업은 "일단 RDB에 현재 상태를 넣자"를 택하고, 그 "나중에 고도화하자"는 대체로 실현되지 않는다.

당근이 이 시점에 Ventyd를 꺼낸 건 하이퍼로컬 플랫폼으로 서비스가 확장되면서 감사 로그, 거래 이력 추적, 상태 복원 같은 요구를 더 이상 미룰 수 없게 됐기 때문이다. 중고거래 도메인 자체가 "누가 언제 가격을 변경했고, 예약이 어떤 경로로 전환됐는지" 기록해야 하는 구조다. 동네 생활 서비스로 카테고리가 넓어질수록 추적할 상태 변화의 종류는 기하급수적으로 늘어난다. 이벤트 소싱이 과잉 설계가 아니라 자연스러운 해법이 되는 지점에 다다른 것이다.

여기서 한 가지 흥미로운 대비가 있다. 같은 한국 테크 기업이지만 우아한형제들은 장애 대응 라이프사이클 쪽으로, 토스는 LLM 기반 생산성 도구 쪽으로 투자하고 있다. 각 회사의 기술 블로그가 보여주는 관심사가 곧 그 조직의 현재 과제를 반영한다. 당근에게 지금 가장 뜨거운 문제가 "복잡한 상태 변화 추적"이라는 것 자체가 플랫폼 성숙도를 보여주는 지표다.

#프로덕션 도입은 시기상조?

솔직히 말하면 아직은 지켜볼 단계다. GitHub 레포의 스타 수는 적고, 프로덕션 규모 검증 사례도 명확하지 않다.

아쉬운 건 스토리지 백엔드 지원 범위다. PostgreSQL이나 DynamoDB 같은 프로덕션급 어댑터가 붙어야 실 서비스 도입이 현실적이다. 이벤트가 수백만 건을 넘어가면 프로젝션 리빌드 속도가 서비스 안정성에 직접 영향을 미치는데, 스냅샷 전략과 캐싱 설계가 문서에서 아직 충분히 드러나지 않는다. 한국 테크 기업의 오픈소스 중 지속 가능한 프로젝트가 드물다는 현실도 변수다. 당근이 자체 서비스에서 이걸 얼마나 밀고, 외부 기여를 얼마나 열어둘지가 궤도를 가를 것이다. 관심은 가질 만하되, 프로덕션 베팅은 다음 릴리스까지 참아도 늦지 않다.