redux

서버를 위한 Redux: Node.js 이벤트 소싱 라이브러리 개발기 (새 탭에서 열림)

당근 프론트엔드코어 팀은 복잡해지는 내부 도구의 요구사항을 해결하기 위해 기존 CRUD 방식의 한계를 넘어 '이벤트 소싱' 패턴을 도입했습니다. 이를 위해 프론트엔드 개발자들에게 친숙한 Redux의 구조를 서버 환경으로 옮겨온 TypeScript 기반 라이브러리 'Ventyd'를 직접 개발하여 오픈소스로 공개했습니다. 이 방식은 데이터의 현재 상태뿐만 아니라 모든 변경 이력을 보존함으로써 감사 로그, 롤백, 비즈니스 인사이트 추출을 획기적으로 용이하게 만듭니다. **전통적 CRUD 방식의 한계와 이벤트 소싱의 필요성** * 기존 CRUD(Create, Read, Update, Delete) 방식은 데이터의 '최종 상태'만 저장하기 때문에, 어떤 과정을 거쳐 현재 상태에 이르렀는지에 대한 맥락을 파악하기 어렵습니다. * 승인 절차, 수정 기록 관리, 복잡한 롤백 로직 등을 구현하려면 별도의 히스토리 테이블이나 복잡한 상태 컬럼을 추가해야 하며, 이는 코드의 복잡도를 높이고 유지보수를 어렵게 만듭니다. * 이벤트 소싱은 상태를 직접 수정하는 대신 "상태를 변경시킨 모든 이벤트"를 순차적으로 기록하여, 필요할 때마다 이벤트를 재생(Replay)해 어느 시점의 상태든 완벽하게 재구성할 수 있게 합니다. **Redux 패턴을 통한 이벤트 소싱의 이해** * 이벤트 소싱 아키텍처는 프론트엔드 상태 관리 라이브러리인 Redux와 매우 유사한 구조를 가집니다. * Redux의 'Action'은 이벤트 소싱의 'Event'와 대응되며, 'Reducer'는 이전 상태와 이벤트를 결합하여 새로운 상태를 계산하는 핵심 로직 역할을 수행합니다. * 가장 큰 차이점은 Redux가 브라우저 메모리에서 상태를 관리하는 반면, 서버의 이벤트 소싱은 이 모든 이벤트를 데이터베이스에 영구적으로 저장하여 데이터의 영속성과 신뢰성을 보장한다는 점입니다. **TypeScript 퍼스트 라이브러리: Ventyd** * Ventyd는 TypeScript 환경에서 이벤트 소싱을 더 쉽고 안전하게 구현하기 위해 개발되었으며, 강력한 타입 추론을 제공합니다. * **스키마 정의**: `defineSchema`를 통해 발생 가능한 이벤트의 종류와 최종 상태(State)의 형태를 정의합니다. 이때 Valibot, Zod, TypeBox 등 다양한 검증 라이브러리를 선택하여 사용할 수 있습니다. * **리듀서 구현**: `defineReducer`를 사용해 각 이벤트가 발생했을 때 상태가 어떻게 변화하는지 선언적으로 기술합니다. * **유연한 확장성**: 특정 데이터베이스에 종속되지 않도록 설계되어 있으며, 프론트엔드와 백엔드 엔지니어가 공통의 비즈니스 로직 언어(이벤트)로 소통할 수 있는 환경을 제공합니다. 단순히 현재의 데이터 값만 저장하는 것을 넘어, 서비스의 성장 과정과 모든 변경 맥락을 자산으로 남기고 싶은 팀에게 Ventyd 도입을 추천합니다. 특히 Redux에 익숙한 엔지니어라면 낮은 학습 곡선으로도 서버 사이드에 견고한 이벤트 중심 아키텍처를 구축하고, 복잡한 비즈니스 요구사항을 깔끔하게 정리할 수 있을 것입니다.

Engineering spotlight: Marie-Laure Bardonnet (새 탭에서 열림)

Datadog의 새로운 기능인 'Notebooks'는 숙련된 시니어 엔지니어가 아닌, 7개월간의 인턴십을 거친 인턴의 주도로 개발되었습니다. 인턴 Marie-Laure Bardonnet는 사소한 버그 수정부터 시작해 점진적으로 업무 범위를 넓히며, 결국 최신 프론트엔드 기술을 활용해 제품의 핵심 기능을 성공적으로 구축했습니다. 이는 주니어 개발자에게 도전적인 과제와 적절한 멘토링이 주어졌을 때 얼마나 큰 성과를 낼 수 있는지를 보여주는 사례입니다. ### Notebooks 기능의 역할과 가치 * 특정 시점의 데이터 그래프를 텍스트 및 기타 정보와 함께 저장하고 공유할 수 있는 도구입니다. * 조직 내에서 장애 대응이나 분석 시 깊은 맥락(Context)을 제공하여 팀원들이 더 빠르게 상황을 파악하고 협업할 수 있도록 돕습니다. ### 단계적인 업무 확장을 통한 코드베이스 적응 * 초기에는 대시보드의 즐겨찾기 별표 표시 수정과 같은 사소한 UI 버그부터 시작하여 애플리케이션 구조에 익숙해졌습니다. * 점차 난이도가 높은 과제를 수행하며 코드베이스에 연착륙(Smooth entry)했고, 이는 단순한 '잡무(Grunt work)'를 넘어 실제 제품에 영향을 미치는 프로젝트로 이어졌습니다. ### 최신 프론트엔드 기술 스택의 실무 적용 * 단순한 기능 구현을 넘어 React, Redux(상태 관리), Redux Saga(사이드 이펙트 관리)와 같은 최신 기술을 깊이 있게 학습하고 적용했습니다. * 인턴 과정임에도 불구하고 기능 구현에 필요한 아키텍처 리팩토링 아이디어를 제안하고 이를 실무에 반영하는 등 심도 있는 엔지니어링 과정을 거쳤습니다. ### 자율성과 가이드의 균형을 맞춘 멘토링 * 팀 리드는 인턴이 스스로 해결책을 찾도록 지켜보는 것과 기술적으로 까다로운 부분에서 함께 논의하는 것 사이에서 적절한 균형을 유지했습니다. * 이러한 멘토링 덕분에 인턴은 이론적인 지식과 실무 역량의 차이를 이해하고, 개발자로서 독립적인 의사결정을 내리는 법을 체득했습니다. 기업이 우수한 엔지니어를 확보하기 위해서는 인턴을 단순 보조 인력으로 활용하기보다, 실질적인 제품 개발에 참여시키고 최신 기술을 탐구할 환경을 제공해야 합니다. 적절한 자율성과 책임감이 부여될 때 주니어 개발자는 기업의 핵심 인재로 성장하며 장기적인 기여를 할 수 있게 됩니다.

Redux-Doghouse: Creating reusable React-Redux components through scoping (새 탭에서 열림)

Redux-Doghouse는 단일 Redux 애플리케이션 내에서 동일한 컴포넌트를 여러 번 재사용할 때 발생하는 상태 충돌 문제를 해결하기 위해 개발된 라이브러리입니다. 각 컴포넌트 인스턴스에 고유한 '스코프(Scope)'를 부여함으로써 액션과 리듀서가 특정 인스턴스에만 독립적으로 작용하도록 격리합니다. 이를 통해 개발자는 기존의 Redux 로직을 대대적으로 수정하지 않고도 복잡한 UI 구성 요소를 모듈화하고 재사용할 수 있습니다. **재사용 가능한 컴포넌트와 Redux의 충돌** * Redux는 전역 상태 관리에는 탁월하지만, 동일한 로직을 가진 컴포넌트를 한 페이지에 여러 개 배치할 경우 문제가 발생합니다. * 특정 액션 타입(예: `MY_ACTION`)이 발행되면, 해당 타입을 구독하는 모든 리듀서가 동시에 반응하기 때문에 한 인스턴스의 버튼 클릭이 모든 인스턴스에 영향을 주게 됩니다. * 이를 해결하기 위해 기존 코드를 리팩토링하는 대신, 각 인스턴스를 독립된 영역(Doghouse)에 격리하는 방식이 필요해졌습니다. **스코프 기반의 액션과 리듀서 작동 방식** * Redux-Doghouse는 `actionCreators`와 `reducers`에 고유한 스코프(식별자)를 결합합니다. * 액션이 발행될 때 메타데이터로 스코프 정보를 포함하며, 래핑된 리듀서는 자신에게 할당된 스코프와 일치하는 액션만을 처리합니다. * 이 방식의 장점은 하위 컴포넌트가 자신이 거대한 애플리케이션의 일부라는 사실을 모른 채 독립적으로 작동할 수 있다는 점입니다. * 상위 레벨에서는 여전히 모든 인스턴스의 내부 상태에 접근하거나 특정 액션에 반응할 수 있어, 상호 연결된 Redux의 장점을 그대로 유지합니다. **데이터독(Datadog)의 실제 적용 사례: 쿼리 에디터** * 데이터독의 '익스프레션 에디터(Expression Editor)'는 여러 개의 '쿼리 에디터'를 포함하며, 각 쿼리는 A, B, C 등의 식별자를 가집니다. * 각 쿼리 에디터에서 발생하는 `SET_GROUP` 액션은 해당 쿼리 인스턴스에만 영향을 주어야 하지만, 동시에 상위 에디터는 모든 쿼리의 그룹 규칙이 일치하는지 검사해야 합니다. * Redux-Doghouse를 통해 각 쿼리 에디터는 부모의 존재를 모른 채 독립적으로 동작하고, 상위 에디터는 스코프가 부여된 액션을 통해 전체적인 비즈니스 로직을 조율합니다. **모듈화와 개발 생산성 측면의 이점** * UI 구성 요소(React)와 상태 로직(Redux)을 동일한 단위로 묶어 모듈화할 수 있어 코드 관리가 용이해집니다. * 뷰(View) 코드와 모델(Model) 코드가 서로 다른 방식으로 분리되는 혼란을 방지하고, 컴포넌트 중심으로 사고할 수 있게 돕습니다. * 기존에 독립적으로 작성된 Redux 컴포넌트를 더 큰 시스템에 통합할 때 코드 수정 기능을 최소화할 수 있습니다. 복잡한 대시보드나 도구 모음처럼 동일한 UI 패턴이 한 화면에 반복적으로 나타나면서도 각각 독립적인 상태를 유지해야 하는 프로젝트라면, Redux-Doghouse는 구조적인 일관성을 지키며 확장성을 확보할 수 있는 훌륭한 대안이 될 것입니다.