핵심 이슈: '더 많이'가 아니라 '더 적게'가 경쟁력이 된 시대
프론트엔드 개발자로서 솔직히 고백합니다. 저도 한때 GitHub 잔디밭을 초록으로 가득 채우는 게 실력이라고 믿었습니다. 컴포넌트 하나 더, 라이브러리 하나 더, 추상화 레이어 하나 더. 그런데 2026년 중반, 업계가 말하는 시니어의 덕목이 완전히 뒤집혔습니다. "뭘 추가했느냐"가 아니라 "뭘 빼냈느냐"입니다.
이번 주 눈에 띈 세 가지 글이 정확히 같은 방향을 가리키고 있어서 엮어봤습니다. RSC(React Server Components)-First SaaS 아키텍처를 다룬 dev.to의 "From Todo App to Real SaaS in 2026" 포스트, Rollup.js의 Tree-shaking 전략을 정리한 Velog 학습 노트, 그리고 "2026년 가장 가치 있는 스킬은 코드 삭제"라고 선언한 에세이. 셋 다 결론이 같습니다—번들도, 코드도, 아키텍처도 다이어트가 필요하다.
맥락 해석: 세 겹의 '뺄셈'
1. RSC-First — 서버에서 할 일은 서버에서 끝내라
Next.js App Router 기반 RSC-First 아키텍처의 핵심은 명쾌합니다. "클라이언트에 내려보낼 JavaScript를 원천적으로 줄이겠다." 서버 컴포넌트는 HTML만 내려보내니까 bundle.js에 포함되지 않습니다. Stripe 시크릿 키 같은 민감 정보가 브라우저에 노출될 일도 없고, SEO도 자동으로 개선됩니다. 마케팅 랜딩 페이지를 Server Component로, 대시보드 레이아웃은 layout.tsx로 퍼시스턴트하게 잡고, loading.tsx에 스켈레톤 UI를 넣는 구조—사실 이건 Figma에서 볼 때는 그냥 "페이지 세 개"지만, 실제로 구현하면 하이드레이션 에러와의 전쟁입니다.
사용자 입장에서는 어떤 일이 벌어지냐면요. 초기 JavaScript 번들이 줄어드니 LCP(Largest Contentful Paint)가 빨라지고, 스켈레톤 스트리밍 덕에 FID(First Input Delay)도 줄어듭니다. Core Web Vitals 세 지표 중 두 개가 아키텍처 선택만으로 개선되는 거죠. 물론 Server Actions에서 revalidatePath를 남발하면 캐시 무효화 폭탄이 터지니까, "서버에서 할 일"과 "클라이언트에서 할 일"의 경계를 1px 단위로 그어야 합니다.
2. 번들링 — Tree-shaking은 선택이 아니라 생존
Velog에 올라온 Rollup.js 학습 노트가 흥미로웠던 건, 라이브러리 빌드 관점에서 번들러를 바라본다는 점입니다. 디자인 시스템을 만들 때 ESM, CommonJS, UMD를 output 배열 하나로 동시에 뽑아주는 Rollup의 설정은 실무에서 정말 편합니다. 하지만 진짜 포인트는 Tree-shaking 효율이에요. Webpack이 아직도 CommonJS 모듈을 완벽히 흔들어 떨구지 못하는 반면, Rollup은 ESM 기반이라 dead code 제거가 훨씬 깔끔합니다.
여기서 프론트엔드 개발자로서 하나 짚고 싶은 건, external 설정의 중요성입니다. React 같은 peer dependency를 번들에 포함시키면 사용자 앱과 중복 로드돼서 번들 사이즈가 뻥튀기됩니다. rollup-plugin-peer-deps-external로 자동 제외하든, external 옵션으로 수동 지정하든—이 라이브러리 도입하면 bundle size가 얼마나 늘어나는지, 매번 bundlephobia에서 확인하는 습관이 필요합니다. 사실 이건 flexbox로 해결되는 레이아웃에 grid를 쓰는 것만큼이나 과잉 설계의 문제입니다.
3. 코드 삭제 — 2,000줄 지운 커밋이 가장 가치 있다
"The most valuable skill in 2026 isn't writing code. It is deleting it." 이 글의 저자가 주말 동안 한 일이 인상적입니다. 사용자 2%만 쓰지만 지원 티켓의 50%를 유발하는 기능을 삭제하고, 복잡한 상태 관리 라이브러리를 표준 React 훅으로 교체하고, "혹시 몰라" 동적으로 만들어둔 변수를 하드코딩으로 되돌렸습니다. 결과? 번들 사이즈 감소, 빌드 시간 절반, 그리고 가장 중요한 것—시스템에 대한 멘탈 모델이 다시 선명해졌다는 겁니다.
AI가 주니어 개발자 한 명의 한 달 치 코드를 오후 한 나절에 생성하는 시대에, 코드 작성의 가치는 0에 수렴합니다. 반면 유지보수 비용은 그대로입니다. 모든 코드 라인은 테스트해야 하고, 디버그해야 하고, 보안 패치해야 하고, 6개월 뒤의 내가 읽어야 합니다. "디지털 호딩"이라는 표현이 정확합니다—"나중에 쓸지 몰라" 쌓아둔 유틸 함수, "미래 대비" 추상화, "일단 넣어둔" 피처. 전부 정신적 부하(cognitive load)입니다.
시사점: 프레임워크 매직에 대한 반발도 같은 맥락
재밌는 건, "Inglorious Web"이라는 프레임워크를 만든 개발자의 글(dev.to)도 정확히 같은 철학을 공유한다는 점입니다. React의 useEffect 의존성 배열 지뢰밭, Vue 3의 reactive 디스트럭처링 함정, Svelte 5 Runes의 컴파일러 마법—이 모든 "보이지 않는 기계(invisible machinery)"에 지친 개발자가 "프록시 없이, 시그널 없이, 컴파일러 없이" 순수 JavaScript로 돌아간 겁니다. 프레임워크가 더해주는 추상화조차 "이게 정말 필요한 복잡성인가?" 따져봐야 한다는 신호입니다.
물론 현실적으로 React나 Next.js를 버리자는 이야기는 아닙니다. 다만 RSC-First로 클라이언트 번들을 줄이고, Rollup의 Tree-shaking으로 라이브러리 사이즈를 깎고, 주기적으로 코드를 삭제하는 "세 겹의 뺄셈"이 2026년 프론트엔드 엔지니어의 기본 소양이 되어야 한다는 겁니다. Lighthouse 점수 100점보다 중요한 건, 그 점수를 유지하면서도 새 기능을 투입할 여력이 남아 있는 코드베이스입니다.
전망: "What can I remove?"가 코드 리뷰의 첫 질문이 되는 날
2026년 하반기, 프론트엔드 팀의 PR 리뷰에서 가장 먼저 묻는 질문이 바뀔 겁니다. "이 기능 어떻게 구현했어?"에서 "이거 추가하면 번들에 몇 KB 붙어?", "이 코드 없이도 동작하지 않아?"로요. Refactor: Deleted 2,000 lines라는 커밋 메시지가 팀에서 박수받는 문화—사실 그게 진짜 시니어 프론트엔드 엔지니어의 풍경 아닐까요.
지금 당장 할 수 있는 건 간단합니다. 프로젝트의 node_modules를 열어보세요. import 한 번 하고 잊어버린 라이브러리가 몇 개인지. 그리고 loading.tsx에 스켈레톤 넣으면 어떨까요? 서버에서 처리할 수 있는 로직을 클라이언트에서 돌리고 있진 않은지. 더하기 전에, 빼세요.