프론트엔드 아키텍처 결정의 함정은 언제나 같은 장면에서 시작된다. 데모는 완벽하다. 20개 행, 정렬 아이콘, 깔끔한 스타일. 그런데 6개월 뒤 PM이 일곱 번째 티켓을 열 때쯤이면, 그 '간단한 테이블'은 포커스 규칙·유효성 검사·권한 관리·영속성·서버 성능 문제를 동시에 품은 작은 운영 시스템이 되어 있다. dev.to에 게재된 React 데이터 그리드 비교 글의 제목—'The Best React Data Grid Is the One You Will Not Hate After Feature Request Number Seven'—이 이 현실을 정확히 꿰뚫는다.
같은 원칙이 인프라 선택에도 그대로 적용된다. Cloudflare Durable Objects로 Redis도 전용 WebSocket 서버도 없이 실시간 낯선 이 채팅 앱을 구축한 사례(dev.to)는, '지금 동작하는 최소 구성'이 아니라 '스케일 시나리오가 바뀌어도 후회하지 않을 구조'를 처음부터 선택한 이야기다. 두 사례는 표면상 전혀 다른 레이어—컴포넌트와 인프라—를 다루지만, 핵심 질문은 하나로 수렴한다. 로드맵이 도착한 이후에도 이 선택을 좋아할 것인가?
데이터 그리드: 데모가 아니라 '불쾌한 오후'로 검증하라
시장에 나온 React 데이터 그리드는 각자의 포지션이 명확하다. AG Grid는 검증된 기능 폭이 필요할 때의 안전한 선택, TanStack Table은 모든 픽셀과 인터랙션을 직접 소유하고 싶을 때의 헤드리스 프리미티브, MUI X Data Grid는 이미 Material UI를 쓰는 팀의 생태계 선택, Handsontable은 스프레드시트 경험 자체가 제품일 때의 답이다. 선택지 자체는 어렵지 않다.
어려운 건 선택 기준이다. 비교 글이 제안하는 방법은 단순하면서 냉정하다. 홈페이지 데모가 아니라 '불쾌한 프로토타입'을 만들어라. 커스텀 에디터, 잘못된 Excel 붙여넣기, 오류 상태에서의 키보드 내비게이션, 핀 고정 행과 열, 느린 서버 응답, 저장 실패, 필터와 컬럼 상태 복원—이 시나리오를 후보 라이브러리 모두에게 같은 조건으로 통과시켜 보라는 것이다. 그 과정에서 팀이 직접 소유해야 했던 코드의 양, 실제로 사용한 라이선스 티어, 키보드 경로의 완성도가 답을 준다.
이 맥락에서 Ace Grid가 흥미로운 이유는 기능 목록이 가장 길어서가 아니다. 오히려 반대다. MIT 라이선스 Core로 시작해 스프레드시트 동작이 필요할 때 Pro를, 서버 데이터 모델과 피벗이 필요할 때 Enterprise를 선택할 수 있는 단계적 진입 구조 때문이다. 지금 필요하지 않은 복잡성을 아키텍처에 미리 끌어들이지 않아도 된다는 것, 그리고 AI가 생성한 테이블 출력을 렌더링 전에 스키마로 검증하는 기능처럼 '데모를 화려하게 만드는 것'이 아니라 '그리드가 인프라가 되었을 때 실제로 필요한 것'을 설계한 흔적이 보인다. 역사와 커뮤니티는 AG Grid가 압도적으로 앞서지만, 팀이 복잡성이 진입하는 시점을 통제하고 싶다면 Ace Grid는 진지하게 검증할 가치가 있는 도전자다.
인프라: 엣지가 Redis를 지운 방식
Cloudflare Durable Objects 기반 실시간 채팅 구축 사례는 엣지 컴퓨팅이 '기술적 유행'을 넘어 실제 아키텍처 결정을 단순화하는 지점을 보여준다. 전통적인 실시간 앱 스택은 WebSocket 서버 + Redis(프레즌스·매치메이킹용)의 조합이 당연했다. 이 아키텍처는 Session DO(사용자당 하나, WebSocket 보유), Conversation DO(채팅방당 하나, SQLite로 메시지 저장), Matchmaker DO(단일 큐)로 그 조합 전체를 대체했다. 상태 권위의 위치가 명확하고, 외부 데이터베이스가 핫 패스에 없다.
게임 로직을 순수 리듀서로 설계한 선택도 눈에 띈다. Conversation DO가 서버 측 레퍼리 역할을 하고, 클라이언트는 동일한 리듀서로 낙관적 UI를 구현한 뒤 권위 있는 스냅샷이 도착하면 조정한다. 새 게임 추가는 리듀서를 작성하고 등록하는 것으로 끝난다. 이 패턴은 로직의 단일 진실 소스를 클라이언트와 서버가 공유하는 방식으로, 기능이 추가될수록 복잡도가 선형적으로 증가하지 않게 잡아주는 구조다.
번들 크기 문제도 주목할 만하다. Next.js 16(App Router)을 Workers에 OpenNext로 배포했을 때 SSR Worker가 5MiB로 부풀었고, Cloudflare 무료 플랜 한도인 3MiB를 넘겼다. 해결책은 Turbopack 대신 webpack 빌드, experimental.inlineCss 비활성화로 1.94MiB까지 압축하는 것이었다. 엣지 환경에서 번들 크기는 성능 지표가 아니라 배포 가능 여부를 결정하는 하드 제약이라는 사실이 여기서 드러난다. 도구 선택이 아키텍처 가능성 자체를 닫을 수 있다.
시사점: '7번째 요구사항'을 먼저 상상하라
두 사례가 공통으로 가리키는 설계 원칙은 하나다. 지금 필요한 것만으로 선택하면, 일곱 번째 요구사항이 도착할 때 아키텍처 전체를 교체하는 비용을 치른다. 데이터 그리드는 '지금 표시할 행'이 아니라 '언젠가 요청될 Excel 붙여넣기, 서버 페이지네이션, AI 생성 결과 검증'을 미리 상상한 뒤 선택해야 한다. 인프라는 'Redis 없이 지금 채팅이 되는가'가 아니라 '사용자가 늘고 기능이 추가될 때 이 구조가 버티는가'로 판단해야 한다.
이 판단을 잘하는 개발자는 데모 퀄리티가 아니라 변화의 비용 곡선을 먼저 읽는다. 라이브러리가 제공하는 마이그레이션 진단 도구, 단계적 라이선스 구조, 엣지 환경의 번들 하드 제약—이런 것들은 홈페이지에서 강조하지 않지만, 로드맵이 실제로 도착했을 때 팀의 속도를 결정한다. 선택의 기준을 첫 번째 요구사항이 아니라 일곱 번째 요구사항으로 옮기는 것, 그게 후회 없는 프론트엔드 아키텍처의 출발점이다.