프론트엔드 비용 모델: 시간, 바이트와 관측량을 어떻게 비교할 것인가

30초 요약

프론트엔드 비용 모델은 청구서 총액만 나누는 표가 아니다. 한 번의 검증, 한 번의 콜드 세션과 한 번의 성공 흐름 같은 결과 단위를 정하고, 그 결과를 만드는 빌드 시간·저장 바이트·전송 바이트·관측 자료량을 같은 기간과 범위에서 연결하는 설명이다.

여기서 결과 단위는 비용을 나눌 기준, 비용 동인은 사용량을 바꾸는 원인, 측정 경계는 어디서 어떤 자원을 셀지 정한 선이다. 이 글의 콜드 세션은 합의한 캐시 기준에서 초기 자원을 다시 받아야 하는 사용자 세션을 뜻한다. “같은 부하”는 같은 사용자·요청 규모와 플랫폼 조건으로 비교한다는 뜻이다.

반복해서 기억할 문장은 이것이다.

결과 한 단위를 정하고, 시간·바이트·사건 수를 분리해, 품질과 함께 비교한다.

결정 질문 → 결과 단위·기간·범위 → 비용 동인과 측정 경계
→ 사용량 × 단가 + 고정 항목 → 단위 비용과 품질 기준
→ 같은 부하의 전후 비교 → 유지·확대·되돌림

금액은 통화·계약·할인·지역·날짜에 따라 바뀐다. 이 글은 고정 가격표를 외우지 않고 청구 자료의 현재 단가를 변수로 넣는 방법을 다룬다.

이 글의 대표 상황은 지속적 통합(Continuous Integration, CI) 작업을 병렬화해 결과는 빨라졌지만 실행기 사용량과 청구는 줄지 않은 변경을 평가하는 일이다. 기다린 시간, 사용한 자원, 검증한 변경 수와 품질을 서로 다른 단위로 나누면 “빨라졌으니 더 싸졌다”는 결론을 피할 수 있다. 같은 분리법을 전송·관측 비용에도 적용한다.

총량과 단위 비용을 함께 본다

기본 모형은 간단하다.

기간 총비용 = 고정 항목 + Σ(사용량_i × 현재 단가_i)
단위 비용   = 기간 총비용 ÷ 같은 기간의 유효 결과 수

고정 항목은 사용량이 조금 변해도 바로 달라지지 않는 구독·예약 용량 같은 비용이다. 변동 항목은 빌드 분, 저장 GB-시간, 전송 바이트나 관측 이벤트처럼 사용량에 따라 달라진다. 실제 계약에는 무료 허용량, 구간 단가와 할인도 있으므로 청구 내역의 계산 규칙을 그대로 기록한다.

월 전송량 100GB → 140GB  (+40%)
콜드 세션 50만 → 100만   (+100%)
 
세션당 전송량은 200KB → 140KB로 감소

이 예에서 총량은 늘었지만 단위 효율은 좋아졌다. 반대로 총액이 그대로여도 사용자 수가 절반이면 세션당 비용은 나빠졌을 수 있다.

분모도 조심한다. “전체 빌드 횟수” 대신 검증에 성공한 변경 수, “앱 실행 수” 대신 핵심 화면을 완료한 세션 수를 쓰면 실패·재시도가 만든 낭비를 숨기지 않는다. 단, 성공 정의를 바꾸면 전후 비교가 깨지므로 버전과 함께 기록한다.

파이프라인을 다섯 비용 경계로 나눈다

한 청구 항목을 여러 팀이 공유할 수 있고 한 변경이 여러 공급자 비용을 만들 수 있다. 먼저 코드에서 사용자와 관측 저장소까지의 흐름을 나눈다.

release(릴리스)는 배포할 산출물과 식별·출처 정보를 묶은 출시 후보이고, span은 분산된 한 작업 구간의 시작· 끝과 속성을 기록한 자료다. metric point는 특정 시점·구간의 측정값 하나다. 캐시 miss는 필요한 값을 캐시에서 찾지 못해 원본 계산이나 전송을 다시 해야 하는 경우다.

이 표는 비용을 조직 회계에 정확히 배분하는 완성본이 아니다. 어떤 최적화가 다른 경계로 비용을 옮겼는지 놓치지 않기 위한 지도다. 예를 들어 더 많은 청크는 첫 전달량을 줄여도 요청·캐시 관리와 오래된 탭 호환 비용을 늘릴 수 있다.

기다린 시간과 사용한 실행기 시간을 나눈다

Microsoft의 Windows Performance Toolkit 문서는 연속·병렬 작업을 모두 포함한 가장 긴 경로를 임계 경로라고 설명한다. GitHub Actions의 현재 workflow 문법처럼 독립 job은 병렬로 실행되고 needs로 의존 순서를 만들 수 있다. 개발자가 결과를 기다린 시간은 이 임계 경로에 가깝고, 자원 사용량은 실행한 모든 job의 시간을 합친 값에 가깝다.

직렬: lint 4분 → test 4분 → build 4분
  피드백 지연 약 12분, 작업 시간 합 12 job-min
 
병렬: lint 4분 ┐
      test 4분 ├ 동시에 실행
      build 4분┘
  피드백 지연 약 4분, 작업 시간 합 12 job-min

job-minute는 작업 하나가 실행기를 점유한 분 단위다. 실제 공급자는 운영체제·실행기 크기, 분 올림과 무료 허용량에 따라 다르게 청구할 수 있으므로 이 숫자는 자원 비교 모델이지 고정 가격 계산이 아니다.

최적화 질문을 분리한다.

• 개발자 피드백을 줄이려면: 임계 경로, 대기열과 실패를 가장 늦게 발견하는 작업
• 실행기 자원을 줄이려면: 전체 job 시간, 실행 빈도, 중복 작업과 취소되지 않은 옛 변경
• 저장 비용을 줄이려면: 산출물·캐시 크기와 보존 시간
• 실패 비용을 줄이려면: 재시도율과 실패를 발견하기 전까지 실행한 뒤 작업

빠른 실패 검사는 뒤의 비싼 작업을 시작하지 않게 할 수 있지만, 독립 작업을 무조건 직렬화하면 피드백이 느려진다. 실패 확률·작업 비용·의존성을 측정해 순서와 병렬성을 정한다.

공급자 청구와 실제 자원 소비를 분리한다

지속적 통합(CI) 사용량 ≈ Σ(job 실행 분 × 실행기별 계산 규칙)
일반 저장량 근사 ≈ Σ(보관 GB × 보관 시간)
 
GitHub artifact 사용량 = Σ(시간별 보관 이진 GB × 1시간)
GitHub cache 청구량     = Σ(max(시간별 최고 이진 GB - 포함 10GB, 0) × 1시간)
                         단, cache 한도를 10GB보다 높게 설정한 저장소

구매 청구와 내부 자원 소비를 두 열로 둔다. 자체 실행기는 유휴 용량이 있어 추가 작업의 현금 지출이 즉시 늘지 않을 수 있지만, 대기열이 길어지거나 더 큰 서버가 필요해지는 임계점에서는 비용이 계단처럼 증가할 수 있다.

개발자 시간을 무조건 시간당 급여로 곱해 “비용 절감”이라고 단정하지도 않는다. 기다리는 10분이 집중을 끊는지, 다른 일을 병행하는지와 배포 지연·실패 위험을 관찰해 기회비용을 별도 가정으로 둔다.

캐시 비용은 hit와 miss의 평균으로 본다

캐시 hit는 현재 입력의 결과를 안전하게 재사용한 경우다. 캐시 miss 시간만 줄이면 hit가 많은 실제 경로의 효과를 과장하거나 놓칠 수 있다.

기대 작업 시간
  = hit 비율 × hit 시간
  + miss 비율 × miss 시간
 
기간 캐시 비용
  = 조회·전송 사용량 + 저장 크기 × 보존 시간 + 원본 재계산 비용

예를 들어 hit 80%, hit 1분, miss 5분이면 기대 시간은 0.8 × 1 + 0.2 × 5 = 1.8분이다. miss를 1분 줄이면 평균은 0.2분만 줄고, hit를 잘못 재사용해 틀린 산출물을 내면 품질 비용은 훨씬 커질 수 있다.

캐시 키를 느슨하게 만들어 hit율만 높이지 않는다. 입력 동일성, 잘못된 재사용 탐지, 저장·전송량과 실제 임계 경로 개선을 함께 본다.

저장·전송의 네 바이트 경계와 실행 자원을 나눈다

같은 JavaScript도 서로 다른 네 바이트 값으로 측정된다.

1. 원본·source map 포함 산출물 저장 크기
2. 압축된 네트워크 본문 크기(encodedBodySize)
3. 응답 헤더 등을 반영한 브라우저 전송 값(transferSize)
4. 압축을 푼 본문 크기(decodedBodySize)

파싱·컴파일 뒤의 메모리와 CPU 시간은 바이트 크기가 아니다. 네 값과 구분해 사용자 실행 경계의 별도 비용으로 측정한다.

파일 디스크 크기          ≠ encodedBodySize
encodedBodySize           ≠ decodedBodySize
브라우저의 transferSize   ≠ 콘텐츠 전송망(CDN) 청구 바이트

전송량의 단순 모델은 다음과 같다.

기간 전송 바이트
  ≈ 콜드 요청 수 × 압축 본문·헤더 바이트
  + 재검증 수 × 재검증 바이트
  + cache miss의 원본·CDN 구간 바이트

200KB × 10,000 콜드 세션 ≈ 2GB 같은 계산은 영향 크기를 가늠하는 첫 추정이다. KB를 1000바이트로 볼지 1024바이트로 볼지, 세션당 요청 수·캐시율·실패 재시도와 업로드를 포함했는지 명시한다.

관측 비용은 사건 수, 크기, 보존과 카디널리티로 나눈다

관측 자료는 로그, 오류 사건(event), trace의 작업 구간(span), 측정값(metric point)과 실행 기록 (profile)마다 비용 동인이 다르다. 카디널리티는 메트릭에 붙은 고유 속성 조합의 수다.

로그·오류·trace 수집량 ≈ 사건 수 × 평균 바이트/사건 × 보존·인덱싱 규칙
trace span 수           ≈ trace 수 × 평균 span 수 × 샘플 비율
한도 전 metric 집계 상태
  ≈ metric stream 수(같은 집계 규칙을 공유하는 측정 흐름 수) × 고유 속성 조합 수

샘플 비율을 100%에서 10%로 바꿔도 모든 관측 비용이 정확히 10%가 되지 않는다. 샘플러와 관측 자료 수집기(collector)의 고정 계산, 무조건 남기는 오류, 별도 로그·메트릭, 저장 최소 요금과 검색(query) 비용이 남을 수 있다.

fan-out은 한 시작점에서 여러 하위 작업·span으로 갈라지는 정도다. 사용자 1명 = metric 조합 1개인 설계는 한도 전까지 SDK 집계 상태를 늘리고, 한도 뒤에는 속성별 질의를 과소 집계하게 만들 수 있다. 전체 합은 초과분 묶음(overflow)에 남지만 해당 속성이 제거되기 때문이다. 관측 저장소로 내보낸 뒤의 시계열·청구 비용은 공급자의 집계와 한도 규칙을 별도로 확인한다. 고유 식별자는 제한된 metric 속성보다 필요할 때 찾는 로그·trace 문맥에 두고, 13편의 카디널리티 예산을 적용한다.

관측 최적화에는 품질 분모가 필요하다.

• 탐지해야 할 치명 오류의 누락률
• 한 문제를 원인까지 좁히는 데 걸린 시간
• 배포 후보와 기준 집단을 나눌 수 있는 비율
• 개인정보 제거와 보존 정책 준수

비용만 줄여 장애를 보지 못하면 절감이 아니라 위험을 다른 시점으로 옮긴 것이다.

예산에는 범위, 단위와 행동을 붙인다

나쁜 예산: "번들은 500KB 이하"
 
판단 가능한 예산:
  범위: 첫 방문에 필요한 배포용 JavaScript
  크기: 콘텐츠 인코딩 후 합계, source map 제외
  부하: 합의한 주소 경로·언어·기능 설정
  기간: main 브랜치의 매 빌드와 주간 실제 사용자 분포
  품질: 첫 화면·상호작용 시간과 오류율 악화 금지
  초과: 원인이 보이는 변경 차이 첨부, 승인 전 병합 차단 또는 명시적 예외 만료일

hard budget은 넘으면 실행·병합·사용을 막는 한도이고 soft budget은 알리되 작업은 계속하는 목표다. 중요한 보안 수정 때문에 일시적으로 산출물이 커지는 상황처럼 품질·위험과 교환할 수 있으므로 예외의 이유, 승인자와 만료 조건을 남긴다.

한 예산이 여러 경계에 겹쳐 예상치 못하게 전체 CI를 막지 않도록 범위를 분명히 한다. 예산 경고 자체가 성공 목표가 되어 테스트를 삭제하거나 telemetry를 무작정 버리는 역효과도 살핀다.

Web, React와 React Native의 연결점

Web에서는 주소 경로(route)별 배포용 산출물, 압축 본문과 실제 Resource Timing 분포를 함께 본다. 코드 분할로 초기 바이트를 줄였으면 요청 수·cache miss·오래된 HTML의 청크 실패와 상호작용 시간까지 확인한다.

React의 렌더링(render), 즉 화면 결과를 계산한 횟수 자체는 공급자 청구 단위가 아니다. 프로파일 (profile), 즉 시간과 자원 사용 기록에서 비싼 렌더링이 사용자 응답성, CPU·배터리나 telemetry 양에 실제 영향을 주는지 확인한다. 이전 계산 결과를 재사용하는 메모이제이션(memoization)은 근거 없이 늘리면 코드·메모리와 검증 비용을 키울 수 있다.

React Native는 Android·iOS 빌드 실행기 시간, 스토어 바이너리와 충돌 주소를 함수 이름으로 되돌리는 심벌(symbol)·source map 보관, 앱 설치 크기, 무선 업데이트(OTA)의 다운로드·채택과 모바일 데이터· 배터리를 나눠 본다. OTA 한 번의 게시 크기보다 호환 기기 수, 실제 다운로드율, 재시도와 보존한 이전 업데이트까지 기간 총량을 계산한다.

같은 기능을 Web과 RN에서 제공해도 비용 경계는 다르다. Web은 요청마다 CDN·브라우저 캐시가 관여하고, RN 네이티브 빌드는 플랫폼별 빌드·심사·설치 산출물이 있으며 OTA는 설치된 런타임별 채택이 필요하다.

자주 실패하는 비용 모델

총액만 비교한다

사용자·빌드·배포 수요가 달라진 효과가 섞인다. 총량과 단위 비용을 함께 본다.

단위 이름만 같으면 비교한다

콜드 세션, 성공 세션, 요청의 포함 범위가 다르면 KB/세션끼리도 비교할 수 없다. 분모 정의와 자료 출처를 버전 관리한다.

더 빠른 CI를 더 싼 CI라고 부른다

병렬화는 임계 경로를 줄여도 job-minute를 줄이지 않을 수 있다. 피드백 지연과 자원 시간을 나눈다.

빌드 폴더 크기를 사용자 전송량으로 쓴다

압축·캐시·실제 요청 경로가 빠져 있다. 저장, 인코딩, 전송과 실행 크기를 분리한다.

가격표만 코드에 고정한다

계약과 단가가 바뀌면 모델이 조용히 틀린다. 사용량을 안정적으로 측정하고 현재 청구 자료의 단가를 결합하며 적용일을 남긴다.

비용만 줄이고 품질 기준을 지운다

테스트 삭제, 짧은 보존과 과도한 sampling은 당장 수치를 낮춰도 실패 발견·복구 비용을 키운다. 각 단위 비용 옆에 지켜야 할 품질·위험 지표를 둔다.

비용 모델을 만드는 순서

1. 어떤 결정을 바꿀 모델인지 한 문장으로 쓴다.
2. 같은 기간·범위의 결과 단위와 성공·실패 포함 규칙을 정한다.
3. 검증·보관·전달·실행·관측 경계에서 비용 동인과 자료 출처를 찾는다.
4. 사용량, 현재 단가, 고정 항목과 공유 비용 배분 가정을 분리한다.
5. 총량·단위 비용과 품질 보호 기준의 기준선을 함께 기록한다.
6. 같은 부하·분모에서 변경 전후를 비교하고 다른 경계로 옮긴 비용을 확인한다.
7. 범위·단위·기간·초과 행동이 있는 soft 또는 hard budget으로 자동 관찰한다.
8. 수요·가격·아키텍처가 바뀌면 계산식과 예산을 재검증한다.

21편에서는 이 계산과 검증을 반복 가능한 CLI·공통 도구로 옮길 때 입력, 출력, 종료 코드, 부수 효과와 버전 호환성을 어떤 계약으로 고정해야 하는지 다룬다.

한 문장으로 다시 설명하기

프론트엔드 비용 모델은 총액을 줄이는 구호가 아니라 검증한 변경·콜드 세션·성공 흐름 같은 결과 한 단위에 빌드 시간, 저장·전송 바이트와 관측 사건을 같은 경계로 연결하고, 현재 단가와 품질 기준을 분리해 전후 결정을 가능하게 하는 설명이다.

스스로 확인하기

1. 결과 단위를 먼저 정해야 총량과 단위 비용을 함께 해석할 수 있는 이유는 무엇인가?
2. 임계 경로 시간·모든 job 시간의 합·캐시의 기대 시간은 각각 무엇을 설명하는가?
3. 산출물 저장, 압축 본문, 브라우저 전송, 해제 본문의 네 바이트 값은 어떻게 다른가?
4. sampling과 카디널리티는 관측 비용을 어떤 서로 다른 방식으로 바꾸는가?
5. 비용 예산에 숫자 외에 어떤 품질 기준과 초과 행동을 붙여야 하는가?