daangn·2026년 1월 23일원문

서버를 위한 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에 익숙한 엔지니어라면 낮은 학습 곡선으로도 서버 사이드에 견고한 이벤트 중심 아키텍처를 구축하고, 복잡한 비즈니스 요구사항을 깔끔하게 정리할 수 있을 것입니다.

reduxTypeScriptnode.jsstate-management+2

figma·2021년 10월 13일·4분 읽기큐레이션 요약

LiveGraph: Figma의 실시간

Figma는 실시간 협업 제품에 필요한 데이터를 안정적으로 제공하기 위해 Postgres 위에 GraphQL 기반의 실시간 데이터 계층인 LiveGraph를 구축했다. LiveGraph는 프론트엔드가 선언적으로 데이터를 구독하면 데이터베이스 복제 스트림을 읽어 밀리초 단위로 변경 사항을 반영한다. 이를 통해 수동 이벤트 메시지와 클라이언트 상태 동기화의 복잡성을 줄이고, 대규모 실시간 데이터 구독을 지원한다. ## Figma에서 실시간 데이터가 필요한 이유 - 협업자가 파일을 추가하거나 권한을 변경하면 다른 사용자 화면에도 새로고침 없이 즉시 반영되어야 한다. - 따라서 서버에서 데이터를 한 번 가져오는 것만으로는 부족하며, 클라이언트가 현재 관심 있는 데이터의 변경 사항을 계속 받아야 한다. - 인프라 팀의 목표는 제품 개발자가 데이터 전파 방식이나 WebSocket 세부 구현을 직접 관리하지 않고도 실시간 뷰를 만들 수 있게 하는 것이었다. ## 기존 방식의 한계 - 초기에는 React 프론트엔드가 Ruby HTTP 엔드포인트에서 필요한 데이터를 한 번에 받아 Redux 전역 상태에 저장했다. - 데이터 변경 시 백엔드 코드에서 관련 클라이언트에 보낼 이벤트 메시지를 직접 작성하고, 프론트엔드는 WebSocket으로 이벤트를 받아 상태를 갱신했다. - 사용자와 데이터 규모가 커지면서 모든 데이터를 한 번에 로드하기 어려워졌고, 데이터를 점진적으로 불러오면서 다음 문제가 발생했다. - 특정 데이터가 메모리에 항상 존재한다는 보장이 없어짐 - 여러 제품 영역이 같은 데이터를 사용할 때 데이터 로딩 책임이 불분명해짐 - 이벤트를 어느 시점에 보내고 받아야 하는지 관리하기 어려워짐 - 단순한 “새 파일 생성” 이벤트와 달리 권한 변경은 다른 리소스의 가시성까지 연쇄적으로 바꿀 수 있어 이벤트 설계가 복잡했다. - 데이터베이스 쓰기 순서와 실시간 메시지의 송수신 순서가 항상 일치한다는 보장도 없었다. - 그 결과 클라이언트 상태가 서버 상태의 올바른 부분집합을 반영하지 못하는 일관성 버그가 발생했다. ## GraphQL 기반 Live Query 선택 - Figma는 개발자가 실시간 데이터 구독을 선언적으로 정의할 수 있는 일반적인 프레임워크가 필요하다고 판단했다. - GraphQL을 인터페이스로 사용하면 필요한 데이터와 관계를 쿼리로 표현하고, 시스템이 해당 데이터를 자동으로 가져오고 최신 상태로 유지할 수 있다. - 여기서 말하는 GraphQL 구독은 일반적인 이벤트 스트림 구독과 다르다. - GraphQL의 전통적인 `subscription`은 이벤트 메시지를 전달하는 방식에 가깝다. - LiveGraph가 목표로 한 것은 쿼리 결과 자체를 계속 갱신하는 “Live Query” 방식이다. - 프론트엔드는 GraphQL과 유사한 쿼리를 보내고, 서버는 결과를 JSON 트리로 반환한다. - 서버에는 엔터티와 관계를 정의하는 스키마 및 그래프의 일부를 조회할 수 있는 뷰가 존재한다. ## 기존 실시간 데이터베이스 대신 자체 구축한 이유 - Figma는 이미 Postgres를 대규모로 운영하고 있었기 때문에 Firebase나 RethinkDB 같은 별도의 실시간 데이터베이스로 이전할 수 없었다. - LiveGraph는 새로운 저장소가 아니라 기존 Postgres 위에 동작하는 쿼리 엔진이 되어야 했다. - Figma의 Multiplayer 시스템은 파일 단위의 쓰기와 충돌 해결을 담당하지만, LiveGraph는 여러 데이터의 조회와 실시간 동기화를 담당한다. - Hasura, Prisma, PostGraphile 등 GraphQL 기술도 검토했지만, 대규모 동시 구독을 핵심 요구사항으로 설계된 것은 아니었다. - Figma는 실시간 구독 수가 많아질수록 데이터베이스 부하가 커지는 폴링 방식도 피하고자 했다. - 폴링은 쿼리마다 주기를 정해야 한다. - 구독 수가 늘어나면 동일한 쿼리가 반복 실행되어 데이터베이스 부하가 증가한다. - 폴링보다 변경 발생 시점에 가까운 낮은 지연 시간을 확보하기 어렵다. ## 데이터베이스 복제 스트림 기반 설계 - LiveGraph는 주기적으로 데이터를 다시 조회하는 대신 Postgres의 데이터베이스 복제 로그를 추적한다. - 복제 스트림에서 변경 사항을 읽으면 실제 데이터베이스 변경을 감지한 뒤 구독 중인 쿼리 결과를 갱신할 수 있다. - 이 방식은 폴링보다 빠른 업데이트 지연 시간을 제공한다. - 다만 LiveGraph가 데이터베이스의 전체 변경량을 읽어야 하므로, 대규모 환경에서는 확장성이 중요하다. - Figma는 여러 데이터베이스 샤드의 변경 사항을 여러 머신에 분산 처리할 수 있는 구조를 고려했다. - 최종적으로 LiveGraph를 자체 구축한 이유는 Figma의 협업 기능에서 실시간 데이터가 핵심 기능이며, 이러한 요구사항이 경쟁력으로 이어질 수 있다고 판단했기 때문이다. ## 실용적인 결론 실시간 UI를 구축할 때 클라이언트별 수동 이벤트와 전역 상태 갱신에 의존하면 데이터 규모와 기능 복잡도가 커질수록 일관성 문제가 발생하기 쉽다. 기존 Postgres를 유지해야 하고 대규모 구독이 필요하다면, GraphQL 기반 선언적 쿼리와 데이터베이스 변경 스트림을 결합하는 방식이 폴링이나 수동 이벤트보다 확장성과 유지보수성 측면에서 유리하다.

원문 읽기(새 탭에서 열림)

reduxReactPostgreSQLTypeScript+4

figma·2020년 8월 18일·3분 읽기큐레이션 요약

60fps의 React: Figma

Figma는 캔버스에서 댓글 핀이 이동할 때 발생하던 불필요한 React 렌더링을 줄여 스크롤 성능을 약 3배 개선했다. 댓글 수와 무관하게 편집기를 60fps에 가깝게 동작시키는 것이 목표였으며, Chrome Performance 도구와 React Profiler로 병목이 JavaScript 실행과 컴포넌트 재렌더링에 있음을 확인했다. 핵심 해결책은 뷰포트 변화에 실제로 영향을 받는 댓글 컴포넌트만 업데이트하고, 댓글 위치 계산과 변환 처리를 최적화하는 것이었다. ## 60fps를 목표로 한 댓글 스크롤 - Figma의 댓글은 캔버스 위 특정 위치에 고정된 “댓글 핀”으로 표시된다. - 사용자가 캔버스를 이동하거나 확대·축소하면 댓글 핀도 뷰포트에 맞춰 계속 위치를 다시 계산해야 한다. - 15fps나 30fps보다 60fps가 훨씬 부드러운 사용자 경험을 제공하므로, 댓글과 스레드가 많아져도 일정한 성능을 유지하는 것이 목표였다. - 댓글 사용량이 증가하면서 대규모 팀과 파일에서 캔버스 반응성이 저하되기 시작했다. ## WebGL 캔버스와 React 댓글 UI의 구조 - Figma 편집기는 WebGL과 WebAssembly를 사용하는 “브라우저 안의 브라우저”에 가까운 구조다. - 일부 사용자 인터페이스는 TypeScript와 React로 구현되어 있지만, 일반적인 정적 React 화면과 달리 댓글은 캔버스의 이동과 확대·축소에 따라 동적으로 움직인다. - 편집기의 뷰포트 정보는 Redux에 저장된다. - 댓글 핀 컴포넌트는 Redux에서 뷰포트 정보를 가져와 캔버스 좌표를 화면에 표시할 위치로 변환한다. - 뷰포트가 변경될 때마다 React 컴포넌트 트리 일부가 업데이트되므로, 업데이트 범위가 성능에 직접적인 영향을 준다. ## 성능 분석에서 발견한 병목 - Chrome Performance 도구에서 대부분의 프레임 시간이 렌더링이나 페인팅이 아니라 JavaScript 실행에 사용되는 것으로 나타났다. - 댓글 30개인 화면에서 프레임당 약 68ms가 JavaScript에 소비되었고, 실제 화면은 약 19fps로 렌더링됐다. - React Profiler에서는 댓글 화면 자체의 렌더링에는 약 1.8ms만 사용되고 있었다. - 대신 뷰포트 변화와 직접 관련 없는 다음 컴포넌트들이 함께 재렌더링됐다. - 왼쪽 패널 - 툴바 - 속성 패널 - 기타 고정 위치 UI - 즉, 댓글 내용 렌더링보다 “변화가 없는 컴포넌트까지 다시 렌더링하는 것”이 더 큰 비효율이었다. ## 불필요한 재렌더링 줄이기 - 뷰포트 업데이트는 댓글 핀의 위치에는 필요하지만, 화면에 고정된 패널이나 툴바에는 필요하지 않다. - 따라서 뷰포트 상태를 사용하는 컴포넌트의 범위를 댓글 영역으로 제한해야 한다. - React 애플리케이션이 커질수록 상위 컴포넌트의 상태 변화가 하위 전체로 전파되면서 불필요한 렌더링이 발생하기 쉽다. - React Profiler로 실제로 다시 렌더링되는 컴포넌트를 확인하면, 직관만으로 찾기 어려운 병목을 구체적으로 식별할 수 있다. - 성능 개선은 댓글 컴포넌트 자체를 빠르게 만드는 것뿐 아니라, 댓글과 무관한 컴포넌트가 업데이트되지 않도록 컴포넌트 구조와 상태 구독 방식을 조정하는 데서 시작됐다. ## 댓글 핀 위치 변환 최적화 - 댓글 핀은 뷰포트가 바뀔 때마다 캔버스 좌표를 화면 좌표로 변환해야 한다. - 이 변환 과정이 매 업데이트마다 React 렌더링과 결합되면 JavaScript 실행 비용이 커질 수 있다. - Figma는 불필요한 컴포넌트 업데이트를 제거한 뒤 댓글 핀의 변환 처리도 최적화해, 캔버스 이동 중 위치 계산과 화면 반영 비용을 줄였다. - 결과적으로 댓글 스크롤 FPS가 기존보다 약 3배 향상됐다. ## 실용적인 결론 - React 성능 문제에서는 먼저 “컴포넌트 하나의 렌더링 속도”보다 “불필요하게 다시 렌더링되는 컴포넌트가 무엇인지”를 확인하는 것이 효과적이다. - Chrome Performance 도구로 프레임별 JavaScript 비용을 확인하고, React Profiler로 재렌더링 범위를 분석하는 조합이 유용하다. - 자주 변하는 상태는 실제로 그 상태가 필요한 컴포넌트 가까이에 두고, 고정 UI가 동적 상태 변화에 구독되지 않도록 설계하는 것이 좋다.

원문 읽기(새 탭에서 열림)

reduxReactTypeScriptwebassembly+2

datadog·2017년 1월 17일원문

엔지니어링 스포트라이트: 마리로르 바르도네 (새 탭에서 열림)

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

redux데이터베이스 설계datadogReact+3

datadog·2016년 11월 14일원문

Redux-Doghouse: 스코프 지정을 통한 재사용 가능한 React-Redux 컴포넌트 만들기 (새 탭에서 열림)

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는 구조적인 일관성을 지키며 확장성을 확보할 수 있는 훌륭한 대안이 될 것입니다.

redux데이터베이스 설계Reactui-components+4