2025년 8월 14일·4분
웹 성능에 대한 컴파일러 접근법: Rich Harris의 관점
컴파일러 중심의 웹 성능 접근법을 실용적으로 살펴보고 런타임 중심 프레임워크와 컴파일 타임 출력의 차이를 비교한 뒤, 간단한 의사결정 프레임워크를 제시합니다.
컴파일러 중심의 웹 성능 접근법을 실용적으로 살펴보고 런타임 중심 프레임워크와 컴파일 타임 출력의 차이를 비교한 뒤, 간단한 의사결정 프레임워크를 제시합니다.
사용자는 성능을 기술적으로 말하지 않습니다. 앱이 무겁게 느껴진다고 말하죠. 페이지가 뭔가를 보여주기까지 한 박자 늦고, 버튼 반응이 지연되며, 메뉴 열기나 검색 입력, 탭 전환 같은 단순한 동작이 끊깁니다.
증상은 익숙합니다: 느린 첫 로드(빈 화면이나 반쯤 구성된 UI), 지연되는 상호작용(클릭이 잠시 뒤에 반영되거나 흔들리는 스크롤), 저장이나 필터링처럼 즉각적이어야 할 동작 뒤의 긴 스피너.
많은 문제는 런타임 비용에서 옵니다. 간단히 말해 페이지가 로드된 후 브라우저가 앱을 사용 가능하게 만들기 위해 해야 하는 작업들입니다: 자바스크립트를 더 다운로드하고, 파싱하고, 실행하고, UI를 구성하고, 핸들러를 붙이고, 업데이트마다 추가 작업을 계속합니다. 빠른 기기에서도 브라우저에 지나치게 많은 자바스크립트를 밀어넣으면 경험은 금방 느려집니다.
성능 문제는 나중에 나타나기도 합니다. 초기에는 앱이 작습니다: 몇 개 화면, 가벼운 데이터, 단순 UI. 그런데 제품이 커집니다. 마케팅은 트래커를 추가하고, 디자인은 더 풍부한 컴포넌트를 더하며, 팀은 상태와 기능, 의존성, 개인화를 더합니다. 각 변화는 개별적으로 무해해 보이지만 총합은 누적됩니다.
그래서 팀들은 컴파일러 우선 성능 아이디어에 관심을 가지기 시작합니다. 목표는 보통 완벽한 점수가 아니라 제품이 매달 느려지지 않도록 계속 배포하는 것입니다.
대부분의 프론트엔드 프레임워크는 두 가지를 돕습니다: 앱을 만들기, 그리고 데이터와 UI를 동기화 상태로 유지하기. 핵심 차이는 두 번째 작업이 언제 일어나는가입니다.
런타임 중심 프레임워크는 더 많은 작업이 페이지 로드 후 브라우저에서 일어납니다. 다양한 경우를 처리할 범용 런타임을 배포합니다: 변경 추적, 무엇을 업데이트할지 결정, 업데이트 적용 등. 이런 유연성은 개발에 유리하지만, UI가 준비되기 전에 다운로드·파싱·실행해야 할 자바스크립트가 늘어나기 쉽습니다.
컴파일 타임 최적화는 그 작업의 많은 부분을 빌드 단계로 옮깁니다. 브라우저에 범용 규칙 집합을 보내는 대신 빌드 도구가 컴포넌트를 분석해 더 직접적이고 앱 특화된 코드를 생성합니다.
유용한 비유:
대부분의 실제 제품은 중간 어딘가에 위치합니다. 컴파일러 우선 접근도 여전히 라우팅, 데이터 페칭, 애니메이션, 에러 처리 같은 런타임 코드를 일부 보냅니다. 런타임 중심 프레임워크도 클라이언트 작업을 줄이기 위해 빌드 타임 기법(미니파이, 코드 스플리팅, 서버 렌더링)을 활용합니다. 실용적 질문은 어느 진영이 ‘옳은가’가 아니라 여러분의 제품에 맞는 혼합이 무엇인가입니다.
Rich Harris는 컴파일러 우선 프론트엔드 사고의 대표적 목소리 중 하나입니다. 그의 주장은 간단합니다: 더 많은 작업을 미리 해서 사용자가 다운로드할 코드와 브라우저가 해야 할 작업을 줄이라는 것입니다.
동기는 실용적입니다. 많은 런타임 중심 프레임워크는 범용 엔진을 배포합니다: 컴포넌트 로직, 반응성, diffing, 스케줄링, 다양한 헬퍼들. 그런 유연성은 바이트와 CPU 비용을 요구합니다. UI가 작아도 큰 런타임 비용을 계속 지불할 수 있습니다.
컴파일러 접근은 모델을 뒤집습니다. 빌드 시점에 컴파일러는 실제 컴포넌트를 보고 필요한 특정 DOM 업데이트 코드를 생성합니다. 라벨이 절대 변하지 않으면 평범한 HTML이 됩니다. 한 값만 바뀌면 그 값의 업데이트 경로만 출력됩니다. 범용 UI 기계를 배포하는 대신 제품에 맞춘 출력을 배포하는 겁니다.
결과는 보통 단순합니다: 사용자에게 전송되는 프레임워크 코드가 줄고, 상호작용마다 해야 할 작업이 줄어듭니다. 또한 저사양 기기에서 그 차이가 빠르게 드러나는 경향이 있습니다.
여전히 트레이드오프는 존재합니다:
실용적 경험법칙: UI의 대부분이 빌드 시점에 알 수 있으면 컴파일러가 더 타이트한 출력을 생성합니다. UI가 매우 동적이거나 플러그인 중심이라면 더 무거운 런타임이 더 쉬울 수 있습니다.
컴파일 타임 최적화는 작업의 위치를 바꿉니다. 더 많은 결정이 빌드 중에 이뤄지고 브라우저에 남는 작업이 줄어듭니다.
가시적인 결과 중 하나는 전송되는 자바스크립트가 줄어드는 것입니다. 작은 번들은 네트워크 시간, 파싱 시간, 탭이나 클릭에 응답하기 전의 지연을 줄입니다. 중급형 폰에서 그 차이는 많은 팀이 예상하는 것보다 큽니다.
컴파일러는 더 직접적인 DOM 업데이트 코드를 생성할 수도 있습니다. 빌드 단계가 컴포넌트 구조를 볼 수 있을 때, 실제로 변경되는 DOM 노드만 건드리도록 업데이트 코드를 생성해 상호작용마다 추상화 계층을 덜 타게 합니다. 리스트, 테이블, 폼 같은 빈번한 업데이트에서 반응성이 더 좋아질 수 있습니다.
빌드 시 분석은 트리 쉐이킹과 데드 코드 제거를 강화할 수 있습니다. 보상은 단순히 더 작은 파일만이 아닙니다. 브라우저가 로드하고 실행해야 할 코드 경로가 줄어듭니다.
하이드레이션도 빌드 시 선택으로 도움을 받을 수 있는 영역입니다. 하이드레이션은 서버 렌더된 페이지가 이벤트 핸들러를 붙이고 브라우저에서 충분한 상태를 재구성해 인터랙티브해지는 단계입니다. 빌드가 어떤 부분이 인터랙티브해야 하는지 표시할 수 있다면 첫 로드 작업을 줄일 수 있습니다.
부수 효과로 컴파일은 CSS 스코핑을 개선하는 경향이 있습니다. 빌드는 클래스 이름을 재작성하고, 사용하지 않는 스타일을 제거하고, 컴포넌트 간 스타일 누수를 줄일 수 있습니다. UI가 커질 때의 예기치 않은 비용을 낮춥니다.
예를 들어 필터와 큰 데이터 테이블이 있는 대시보드를 생각해 보세요. 컴파일러 우선 접근은 초기 로드를 가볍게 유지하고, 필터 클릭 후 변경된 셀만 업데이트하며, 절대 인터랙티브하지 않을 부분을 하이드레이트하지 않아도 됩니다.
더 큰 런타임이 무조건 나쁜 것은 아닙니다. 런타임은 유연성을 제공합니다: 런타임에서 결정되는 패턴, 많은 서드파티 컴포넌트, 수년간 검증된 워크플로우.
런타임 중심 프레임워크는 UI 규칙이 자주 변할 때 빛납니다. 복잡한 라우팅, 중첩 레이아웃, 풍부한 폼, 깊은 상태 모델이 필요하면 성숙한 런타임이 안전망처럼 느껴질 수 있습니다.
런타임은 앱이 구동되는 동안 많은 일을 프레임워크에 맡기길 원할 때 유용합니다. 이는 팀의 일상 속 속도를 높일 수 있으며, 비용이 늘어나더라도 생산성으로 보상받을 수 있습니다.
일반적인 장점은 방대한 생태계, 상태 및 데이터 페칭에 대한 익숙한 패턴, 강력한 개발 도구, 플러그인식 확장의 용이성, 채용 시 온보딩의 부드러움 등입니다.
팀 친숙성은 실제 비용이자 실제 이점입니다. 팀이 자신 있게 배포할 수 있는 약간 느린 프레임워크가, 빠르지만 재교육이나 엄격한 규율, 커스텀 도구가 필요한 접근법보다 더 나을 수 있습니다.
많은 “느린 앱” 불만은 프레임워크 런타임이 원인이 아닙니다. 페이지가 느린 API, 무거운 이미지, 너무 많은 폰트, 서드파티 스크립트를 기다리고 있다면 프레임워크를 바꿔도 핵심 문제는 해결되지 않습니다.
로그인 뒤 내부 관리자 대시보드는 강력한 기기에서 사용자가 많고 작업이 테이블, 권한, 백엔드 쿼리 중심이라면 더 큰 런타임으로도 괜찮게 느껴질 수 있습니다.
초기에는 “충분히 빠름”이 옳은 목표일 수 있습니다. 제품 가치를 증명하는 단계에서는 반복 속도를 유지하고 기본 예산을 설정한 뒤, 컴파일러 우선 복잡성을 증거가 있을 때만 도입하세요.
반복 속도는 피드백까지 걸리는 시간입니다: 누군가 화면을 바꾸고, 실행하고, 무엇이 깨졌는지 보고, 수정하는 속도. 이 루프가 짧을수록 팀은 더 자주 배포하고 더 빨리 학습합니다. 그래서 런타임 중심 프레임워크는 초기엔 생산적으로 느껴지는 경우가 많습니다: 익숙한 패턴, 빠른 결과, 많은 내장 행동.
성능 작업은 너무 빨리 또는 너무 광범위하게 하면 그 루프를 늦춥니다. 모든 PR이 마이크로 최적화 논쟁으로 바뀌면 팀은 위험을 감수하기를 멈춥니다. 제품이 무엇인지 모르기 전에 복잡한 파이프라인을 구축하면 사람들은 도구 싸움에 시간을 쓰고 사용자와 대화하는 대신 툴링과 싸우게 됩니다.
요점은 ‘충분히 좋음’이 무엇인지 합의하고 그 안에서 반복하는 것입니다. 성능 예산은 그 박스를 제공합니다. 완벽 점수를 좇는 것이 아니라 경험을 보호하면서 개발을 계속할 수 있게 하는 제한입니다.
실용적 예산 예시는 다음과 같습니다:
성능을 무시하면 보통 나중에 비용을 지불합니다. 제품이 성장하면 느려짐은 단순한 트윅 문제가 아니라 아키텍처 결정과 연결됩니다. 늦은 리라이트는 기능 동결, 팀 재교육, 이전에 작동하던 워크플로 깨짐을 의미할 수 있습니다.
컴파일러 우선 도구는 이 트레이드오프를 옮길 수 있습니다. 빌드 시간이 약간 길어지는 것을 감수하면 매 방문, 매 기기에서 수행되는 작업량을 줄일 수 있습니다.
제품이 증명됨에 따라 예산을 재검토하세요. 초기에는 기본을 보호하고, 트래픽과 수익이 늘어나면 예산을 더 엄격히 하고 실제 지표에 영향을 주는 곳에 투자하세요.
성능 논쟁은 ‘빠름’의 정의에 모두가 동의하지 않으면 혼란스러워집니다. 소수의 지표를 정하고 문서로 남기며 공유된 스코어보드로 다루세요.
간단한 시작 세트:
대표 기기에서 측정하세요. 개발용 랩탑은 빠른 CPU, 웜 캐시, 로컬 서버로 인해 중급형 폰의 지연을 숨길 수 있습니다.
현실에 맞게 두세 대의 장치를 골라 동일한 흐름(홈, 로그인, 흔한 작업)을 매번 실행하세요. 변경 전에 현 빌드의 기준선을 캡처해 두세요. 그 기준선이 ‘전후 사진’입니다.
단일 실험실 점수만으로 성능을 판단하지 마세요. 랩 도구는 잘못된 것을 보상할 수 있습니다(첫 로드는 좋지만 사용자가 불평하는 문제—메뉴 끊김, 느린 타이핑, 첫 화면 이후의 지연—를 놓칠 수 있음).
숫자가 나빠지면 추측하지 말고 무엇이 배포되었는지, 무엇이 렌더링을 차단했는지, 시간이 네트워크·자바스크립트·백엔드 중 어디서 소모되었는지 확인하세요.
프레임워크와 렌더링 결정을 차분하게 반복 가능한 제품 결정으로 다뤄보세요. 목표는 최고 기술을 고르는 것이 아니라 성능과 팀 속도의 적절한 균형을 찾는 것입니다.
얇은 슬라이스는 다음의 지저분한 부분을 포함해야 합니다: 실제 데이터, 인증, 가장 느린 화면.
빠르게 프로토타입할 방법으로 Koder.ai (koder.ai)를 사용하면 챗으로 웹, 백엔드, 모바일 플로우를 만들고 소스 코드를 내보낼 수 있습니다. 이를 통해 실제 라우트를 조기에 테스트하고 실험을 스냅샷과 롤백으로 되돌릴 수 있습니다.
결정 내용을 이해하기 쉬운 언어로 문서화하고, 어떤 상황에서 재검토할지(트래픽 증가, 모바일 점유율 변화, SEO 목표 등)를 적어 두세요. 이렇게 하면 팀이 바뀌어도 선택이 지속됩니다.
팀들이 성능 결정을 잘못하는 이유는 보통 오늘 보이는 것을 최적화하고, 세 달 뒤 사용자가 느끼게 될 것을 보지 못하기 때문입니다.
한 가지 실수는 첫 주에 과도하게 최적화하는 것입니다. 매일 바뀌는 페이지에서 몇 밀리초를 깎는 데 며칠을 쓰는 동안, 실제 문제는 사용자가 아직 필요한 기능을 갖추지 못한 경우가 많습니다. 초기에는 학습 속도를 빠르게 하세요. 라우트와 컴포넌트가 안정되면 더 깊은 성능 작업을 고정하세요.
또 다른 실수는 번들 성장률을 무시하는 것입니다. 200KB에서는 괜찮아 보이다가 몇 번의 작은 추가 후에는 메가바이트 단위로 커집니다. 습관 하나가 도움이 됩니다: 번들 크기를 시간에 따라 추적하고 갑작스러운 증가를 버그로 취급하세요.
팀들은 또한 모든 것을 클라이언트 전용 렌더링으로 처리하는 경향이 있습니다. 일부 라우트(가격 페이지, 문서 스타일 콘텐츠, 온보딩 단계)는 정적에 가깝게 제공하면 기기 작업을 훨씬 줄일 수 있습니다.
조용한 치명타는 편의를 위해 큰 UI 라이브러리를 추가해 실제 프로덕션 빌드에서 비용을 측정하지 않는 것입니다. 편의는 타당하지만, 추가 자바스크립트와 CSS, 중급형 폰에서의 느린 상호작용에 대해 무엇을 지불하는지 명확히 하세요.
마지막으로 접근법을 명확한 경계 없이 섞으면 디버깅하기 어려운 앱이 됩니다. 앱의 절반은 컴파일러가 생성한 업데이트를 전제로 하고 다른 절반은 런타임 매직을 전제로 하면 규칙이 불분명하고 실패 원인이 혼란스럽습니다.
실무에서 통하는 몇 가지 가드레일:
대부분의 경우 네트워크 문제만이 원인은 아닙니다—주된 원인은 런타임 비용입니다. 브라우저가 자바스크립트를 다운로드하고 파싱하고 실행하며 UI를 구성하고, 업데이트마다 추가 작업을 하는 과정이 포함됩니다.
그래서 자바스크립트 작업량이 커지면, 좋은 노트북에서도 앱이 “무겁다”는 느낌을 줄 수 있습니다.
목표는 동일합니다(클라이언트에서 하는 일을 줄이기). 다만 메커니즘이 다릅니다.
프레임워크가 빌드 시점에 구성요소를 분석해서 앱에 맞춘 코드를 출력한다는 의미입니다. 범용 UI 엔진을 배포하는 대신 앱에 특화된 출력물을 내보내는 방식입니다.
실무적 이점은 보통 번들 크기 감소와 상호작용 중 CPU 작업 감소입니다 (클릭, 타이핑, 스크롤 등).
다음 항목부터 시작하세요:
항상 동일한 사용자 흐름을 측정해 빌드 간 비교가 가능하게 하세요.
가능합니다. 그러나 핵심 병목이 느린 API, 큰 이미지, 과도한 폰트, 서드파티 스크립트 등이라면 프레임워크 교체만으로는 해결되지 않습니다.
프레임워크 선택은 여러 레버 중 하나입니다. 먼저 시간 소모가 어디서 발생하는지(네트워크, 자바스크립트 CPU, 렌더링, 또는 백엔드)를 확인하세요.
유연성과 반복 속도가 필요할 때는 런타임 중심이 맞을 때가 많습니다:
런타임이 병목이 아니라면, 그 편의성 때문에 추가 바이트를 감수할 만합니다.
간단한 규칙은 다음과 같습니다:
혼합(Hybrid)이 가장 실용적일 때가 많습니다. 단, 앱이 혼란스러워지지 않도록 경계를 문서화하세요.
사용자 느낌을 막지 않으면서 개발을 멈추지 않게 하는 예산을 쓰세요. 예:
예산은 보호 장치이지 완벽 점수 경쟁이 아닙니다.
하이드레이션은 서버에서 렌더된 페이지에 이벤트 핸들러를 붙이고 브라우저에서 상태를 재구성해 인터랙티브하게 만드는 작업입니다.
과도하게 하이드레이트하면 HTML은 빨리 보이지만 첫 상호작용까지 시간이 걸려 느껴질 수 있습니다. 빌드 단계에서 어떤 부분만 인터랙티브해야 하는지 표시하면 초기 작업을 줄일 수 있습니다.
좋은 ‘얇은 슬라이스’는 다음을 포함합니다:
프로토타입 단계에서 Koder.ai (koder.ai)를 사용하면 웹·백엔드 플로우를 챗으로 만들고 소스 코드를 내보내어 전체 흐름을 조기에 측정하고 비교할 수 있습니다.