프론트엔드 개발자에게 '더 좋은 코드'를 물으면 대부분 무언가를 추가하는 방향으로 답한다. 컴포넌트를 쪼개고, 라이브러리를 가져오고, 서버 레이어를 얹는다. 그런데 최근 실전 사례들을 들여다보면 정반대의 흐름이 보인다. 덜어냄으로써 오히려 더 단단한 구조가 만들어지는 것이다. 컴포넌트 분할 전략, 의존성 3개짜리 화이트보드 앱, WASM 기반 클라이언트 사이드 비디오 편집기—이 세 가지는 표면적으로는 달라 보이지만, 같은 질문을 공유하고 있다. 지금 이게 정말 필요한가?
컴포넌트 분할: '쪼개기'가 만병통치약이 아닌 이유
React 생태계에는 오랫동안 '작은 컴포넌트가 좋은 컴포넌트'라는 암묵적 통념이 자리잡고 있었다. 하지만 dev.to에 게재된 컴포넌트 분할 전략 분석 글은 이 통념을 정면으로 재검토한다. 핵심은 간단하다. 분할은 목적이 아니라 수단이다.
분할이 실제로 가치를 만드는 경우는 네 가지로 정리된다. 진짜 재사용이 발생할 때, 컴포넌트의 책임이 명확히 줄어들 때, 독립적인 테스트가 가능해질 때, 그리고 코드의 가독성이 의미 있는 수준으로 올라갈 때다. 이 중 하나도 해당하지 않는다면 분할은 복잡도를 줄이는 게 아니라 분산시키는 것에 불과하다.
특히 주목할 지점은 '책임 테스트'라는 개념이다. 컴포넌트가 하는 일을 한 문장으로 설명할 수 없다면, 그건 크기의 문제가 아니라 역할의 문제다. 400줄짜리 컴포넌트를 200줄 두 개로 나눠도 각각이 여전히 API 호출·상태 관리·렌더링을 한꺼번에 담당한다면 구조적 문제는 그대로다. 이 글이 제안하는 더 나은 대안은 종종 컴포넌트 분리가 아닌 커스텀 훅 분리다. 비 UI 로직을 훅으로 빼내면 컴포넌트는 자연스럽게 얇아지고, 별도의 하위 컴포넌트를 만들지 않아도 된다.
'Rule of Three'도 실용적인 기준으로 소개된다. 세 가지 구체적인 사례가 동일한 패턴을 보일 때 비로소 추상화를 고려하라는 것이다. 두 개의 유사한 컴포넌트를 너무 일찍 합치면, 6개월 뒤 두 케이스가 서로 다른 방향으로 자라날 때 오히려 더 큰 비용을 치른다.
의존성 3개: 단순함이 곧 아키텍처 결정이다
화이트보드 앱을 만들 때 보통은 어떤 드로잉 라이브러리를 쓸지, 상태 관리는 Redux로 할지 Recoil로 할지를 먼저 고민한다. dev.to에 소개된 MindNotes Pro 구현 사례는 그 질문 자체를 뒤집는다. 프로덕션 의존성은 react, react-dom, zustand 단 세 개. 드로잉 라이브러리 없이 Canvas API를 직접 다뤘고, 아이콘 폰트도 외부 CDN 없이 번들에 포함시켰다.
결과는 수치로 말해준다. 번들 사이즈 gzip 기준 160KB, 빌드 타임 약 2초, 외부 CDN 호출 0건. 6가지 브러시 타입과 9가지 드로잉 도구, PNG·PDF·SVG·Word를 포함한 6가지 내보내기 포맷, 50단계 undo/redo까지 갖춘 앱치고는 놀라운 숫자다.
이 사례에서 인상적인 건 단순히 '가볍게 만들었다'는 사실이 아니다. 각 기술 결정이 명확한 이유와 함께 내려졌다는 점이다. SVG 대신 Canvas를 선택한 건 수천 개의 스트로크를 DOM 오버헤드 없이 처리하기 위해서였고, Zustand를 선택한 건 1KB 미만의 크기와 보일러플레이트 제거 때문이었다. 외부 CDN을 배제한 건 중국 등 특정 지역에서의 접근성 문제를 해결하기 위해서였다. 기술 선택 하나하나가 사용자 경험으로 직결되는 트레이드오프 판단이었다.
WASM: 서버를 생략하는 것이 설계가 되는 순간
dev.to에 소개된 프라이버시 중심 온라인 비디오 커터 사례는 조금 다른 각도에서 '덜어냄'을 실천한다. 개발자가 선택한 건 백엔드 서버를 아예 없애는 것이었다. FFmpeg.wasm을 통해 비디오 처리 전체를 브라우저 안에서 완결한다.
이 결정은 단순한 기술적 선호가 아니라 제품의 핵심 가치에서 출발한다. '파일이 서버에 닿지 않는다'는 사실 자체가 사용자에게 설명 없이도 전달되는 프라이버시 보증이다. 500MB 파일을 업로드하고 처리를 기다리는 대신, 파일은 브라우저 메모리에만 올라가고 즉시 처리된다. 서버 클러스터 비용이 없으니 완전 무료를 지속할 수 있고, 이는 다시 가입 강제·워터마크 없는 서비스로 이어진다.
물론 이 경로가 쉽지만은 않다. 4K 파일을 브라우저 탭 안에서 다루는 메모리 관리는 개발 기간 상당 부분을 차지했다. WASM이 모든 상황의 답은 아니지만, 간단한 트리밍·회전·변환 같은 유틸리티성 작업에서는 '브라우저가 충분히 강하다'는 것을 이 사례가 증명한다.
시사점: 설계 판단의 기준을 바꿔라
세 사례를 관통하는 공통점은 하나다. 무언가를 추가하기 전에 그것이 실제로 필요한지를 먼저 물었다는 것이다. 컴포넌트 분할 전에 '이 분할이 재사용·테스트·책임 중 하나라도 개선하는가'를 묻고, 의존성 추가 전에 '이 라이브러리 없이 Canvas API로 직접 처리할 수 있는가'를 물으며, 서버 도입 전에 '이 처리가 정말 서버에서 일어나야 하는가'를 물었다.
AI 코드 생성 도구가 일상화된 지금, 이 판단력의 중요성은 오히려 더 높아졌다. Cursor나 Claude가 컴포넌트를 순식간에 만들어주는 환경에서, 개발자가 해야 할 일은 코드를 빠르게 생산하는 것이 아니라 무엇을 만들지 않을지 결정하는 것이다. 잘못된 추상화, 과잉 의존성, 불필요한 서버 레이어—이것들은 AI가 더 빠르게 만들어줄수록 빠르게 쌓이는 부채이기도 하다.
전망: '덜어냄'이 경쟁력이 되는 시대
번들 사이즈, 빌드 시간, 컴포넌트 트리 깊이—이것들은 단순한 성능 지표가 아니라 설계 결정의 누적된 결과다. Core Web Vitals가 검색 순위에 영향을 미치고, 로딩 속도가 전환율에 직결되는 환경에서 '가볍게 시작해 필요할 때 더하는' 전략은 점점 더 강력한 경쟁 우위가 된다.
좋은 프론트엔드 설계의 질문은 '무엇을 더 쓸 수 있는가'가 아니라 '무엇을 안 써도 되는가'로 바뀌고 있다. 컴포넌트 하나, 의존성 하나, 서버 하나를 덜어낼 때마다 코드베이스는 더 이해하기 쉬워지고, 유지보수는 더 예측 가능해지며, 사용자 경험은 더 빨라진다. 덜어낼수록 단단해진다—이것이 2025년 프론트엔드 설계가 다시 발견하고 있는 원칙이다.