"페이지가 느리다"와 "배포가 두렵다"는 같은 문제다
프론트엔드 개발자가 가장 자주 마주치는 두 가지 불안이 있다. 하나는 "실제 사용자 환경에서 왜 이렇게 느린지 모르겠다"는 막막함이고, 다른 하나는 "배포 눌렀다가 뭔가 터지면 어떡하지"라는 두려움이다. 이 둘은 언뜻 다른 문제처럼 보이지만, 뿌리는 같다. 측정하지 않고 전체에 한 번에 열었기 때문이다.
최근 velog에 나란히 올라온 두 글이 이 문제를 정면으로 다룬다. 하나는 Resource Timing API로 실제 사용자 브라우저에서 리소스 병목을 추적하는 RUM 설계 이야기고, 다른 하나는 Feature Flag로 배포와 출시를 분리해 점진적으로 기능을 여는 전략이다. 이 두 주제를 하나의 프레임으로 묶으면, '측정 → 배포 → 검증 → 재측정'이라는 프론트엔드 운영 루프가 선명하게 드러난다.
RUM: 감이 아니라 브라우저의 숫자를 읽어라
Lighthouse 점수가 좋은데도 사용자 불만이 줄지 않는 경험, 한 번쯤 있을 것이다. 이유는 단순하다. Lighthouse는 개발자 머신 한 대의 스냅샷이고, 실제 사용자는 모바일 LTE, 오래된 안드로이드, 특정 지역 CDN 장애를 만난다. 이 간극을 메우는 것이 Real User Monitoring(RUM)이다.
브라우저는 이미 모든 것을 기록하고 있다. performance.getEntriesByType("resource")를 호출하면 각 리소스의 startTime, responseStart, responseEnd, transferSize가 담긴 PerformanceResourceTiming 객체 배열이 나온다. 서버 로그에 200 OK만 찍혀 있어도, 실제 사용자 화면에서는 차트 번들이 1.8초, 이미지 스프라이트가 1.2초를 잡아먹고 있을 수 있다. 문제는 API가 아니라 리소스였던 것이다.
여기서 주의할 점이 있다. duration 하나만 보면 오해하기 쉽다. DNS, TCP, TLS, 대기, 다운로드가 모두 합산된 값이기 때문이다. 진짜 원인을 찾으려면 responseStart - requestStart(대기 시간)와 responseEnd - responseStart(다운로드 시간)를 함께 봐야 한다. 또한 cross-origin 리소스는 Timing-Allow-Origin 헤더가 없으면 transferSize가 0으로 보일 수 있어, CDN 응답 헤더 정책까지 설계의 범위에 넣어야 한다.
Feature Flag: 배포와 출시는 다른 이벤트다
Resource Timing으로 현재 상태를 측정했다면, 다음은 새 기능을 어떻게 안전하게 켜는가의 문제다. 여기서 Feature Flag의 역할이 시작된다.
핵심 개념은 하나다. deploy(배포)와 release(출시)를 분리하라. 코드가 프로덕션 서버에 올라가는 것과 사용자가 실제로 그 기능을 쓰는 것은 같은 순간일 필요가 없다. 금요일 오후에 코드를 배포하고, 기능은 월요일 오전에 내부 계정 → 1% → 10% → 전체 순서로 천천히 열 수 있다. 문제가 생기면 코드 롤백 없이 플래그를 끄는 것으로 즉시 원복된다.
OpenFeature 기반의 React 구현은 직관적이다. useFlag("new-feature", false) 한 줄로 화면 분기를 만들고, 플래그 서버의 값이 바뀌면 UI가 조용히 전환된다. 하지만 여기서 놓치기 쉬운 설계 포인트가 있다. 브라우저에 내려간 플래그 값은 사용자가 볼 수 있다. 화면을 숨기는 용도로는 쓸 수 있지만, 실제 권한 검사는 반드시 서버 API에서 이루어져야 한다. BFF 레이어에서도 같은 플래그 컨텍스트로 평가하고, 서버가 최종 방어선이 되어야 한다.
두 도구가 맞물릴 때: 안전 릴리즈 루프
RUM과 Feature Flag는 각각 강력하지만, 함께 설계될 때 진짜 힘이 나온다. 실제 시나리오를 상상해 보자.
새 플레이어 UI를 20% 사용자에게 열었더니 영상 시작 실패율이 0.8%에서 3.4%로 뛰었다. 이때 RUM 대시보드는 flag_new_player_ui="true" 레이블이 붙은 모바일 사용자에게서 리소스 로딩 지연과 API 오류가 집중된다는 것을 보여준다. Feature Flag 덕분에 전체 사용자가 아닌 20%에서 문제를 잡았고, 플래그를 0%로 낮춰 즉시 영향을 차단한다. 그다음 Resource Timing 데이터로 어떤 리소스가 어느 구간에서 막혔는지 좁혀서 수정한다.
이 루프의 핵심은 지표를 플래그 variant 기준으로 쪼개는 것이다. Grafana 패널에 flag_new_player_ui="true"와 "false"를 함께 띄우면, 새 기능이 성능에 미치는 영향이 실시간으로 보인다. 배포 후 30분 동안 특정 route의 이미지 p95 duration이 임계값을 넘으면 알림을 보내는 것도 이 구조 위에서 자연스럽게 만들 수 있다.
놓치기 쉬운 실무 디테일 세 가지
이 구조를 실제로 굴릴 때 자주 걸리는 함정이 있다.
첫째, 플래그 초기값 깜빡임이다. 앱이 처음 렌더링될 때 플래그 기본값이 false였다가 네트워크 응답 후 true로 바뀌면, 결제 버튼이나 가격 카드가 갑자기 나타나는 불안한 경험을 준다. SSR 환경에서는 서버에서 플래그를 미리 평가해 초기 HTML에 반영하는 것이 가장 깔끔한 해결책이다.
둘째, 외부 SDK의 Resource Timing 사각지대이다. 결제 SDK, 채팅 위젯, A/B 테스트 스크립트는 우리 코드가 아니지만 초기 렌더링을 밀 수 있다. initiatorType=script이고 host가 외부 도메인인 항목을 분리해서 보지 않으면, 우리 번들만 최적화하다가 진짜 병목을 놓친다.
셋째, 플래그 기술 부채다. newCheckout, newCheckoutV2, checkoutExperiment2026 같은 이름이 코드베이스에 쌓이면 다음 개발자가 어떤 분기가 현재 경로인지 알 수 없다. 플래그를 만들 때부터 만료일, 제거 조건, 담당 티켓을 함께 기록하는 것이 코드 품질 감각의 일부다.
시사점: "느린 이유를 모른다"와 "배포가 두렵다"를 동시에 없애는 방법
두 도구가 가리키는 방향은 결국 같다. 프론트엔드 운영을 감이 아닌 데이터로 하라는 것. "홈 화면이 느리다"는 제보를 받았을 때 서버 로그와 Lighthouse만 보던 시절과, Resource Timing으로 실제 사용자 브라우저의 리소스 로딩 패턴을 route별로 집계해서 보는 것은 문제 해결 속도와 정확도가 완전히 다르다.
Feature Flag도 마찬가지다. "배포했는데 뭔가 이상한 것 같다"는 불안과, "플래그 variant별 오류율과 p95 latency가 대시보드에 나란히 찍히고 있다"는 확신은 팀의 릴리즈 문화 자체를 바꾼다. 코드 롤백은 느리고 불안하지만, 플래그 off는 빠르고 안전하다.
전망: 관측 가능성이 프론트엔드의 기본값이 되는 시대
React Server Components와 Next.js의 Partial Prerendering이 확산되면서, 성능 측정의 경계가 서버와 클라이언트를 넘나들게 됐다. Resource Timing API 기반 RUM은 클라이언트 사이드 리소스 로딩을 커버하고, 서버 사이드 렌더링 지연은 별도의 트레이싱으로 봐야 한다. 이 두 관측 데이터를 route 단위로 묶는 것이 앞으로의 프론트엔드 관측 가능성 설계의 핵심 과제가 될 것이다.
Feature Flag도 단순한 if/else를 넘어, A/B 테스트 데이터와 결합해 전환율·이탈률·재생 시작률 같은 제품 지표와 직접 연결되는 방향으로 진화하고 있다. OpenFeature 같은 표준화 움직임도 이 흐름을 가속하고 있다.
결국 앞으로의 프론트엔드 개발자는 코드를 잘 짜는 것만큼, 무엇을 측정하고 어떻게 안전하게 열지를 설계하는 사람이어야 한다. 측정하고, 조심스럽게 배포하고, 데이터로 검증하는 루프—이것이 프로덕트 사고를 가진 프론트엔드 개발자가 팀에 가져올 수 있는 가장 실질적인 기여다.