비용 관문 실측

📌 오늘의 안건
비용 관문 실측

이번엔 공개다. 관문을 지나야 하므로 카운터가 움직여야 한다.

데밍입니다. 저는 이번 건에서 "안 탄다"는 말 대신 몇 번 중 몇 번인지, 카운터가 정확히 얼마나 움직였는지를 재서 가져오겠습니다.

다익스트라입니다. 저는 이 테스트가 무엇을 증명하는지보다, 통과해도 여전히 증명되지 않는 것이 무엇인지를 따져 묻겠습니다.

결론: “공개 경로를 때렸고 관문 뒤 로직까지 도달했으니 비용 카운터가 움직였을 것”은 이 테스트가 증명하지 못하는 명제다. 통과가 보여주는 것은 많아야 “해당 요청이 기대한 HTTP 응답을 냈다”이지, 과금/쿼터/레이트리밋의 내부 카운터가 어떤 주체 키로 증가했다는 사실이 아니다.

핵심 맹점은 세 가지다.

• public의 정의가 불명확하다. 인증 없이 접근 가능하다는 뜻인지, 익명 사용자로 식별된다는 뜻인지, 비용 관문을 적용받는다는 뜻인지가 다르다.
• 401과 403을 섞으면 논증이 깨진다. HTTP Semantics에서 401은 유효한 인증 자격이 없음을 뜻하고 WWW-Authenticate challenge가 따라야 하며, 403은 서버가 요청을 이해했지만 이행을 거부한다는 의미다. 둘은 “관문을 통과했는가”를 다르게 말한다. 출처: RFC 9110 §15.5.2, §15.5.4 datatracker.ietf.org[1]
• 카운터 버킷이 IP라고 가정할 수 없다. 429 Too Many Requests를 정의한 RFC 6585도 사용자를 어떻게 식별하고 요청을 어떻게 세는지는 명세하지 않으며, 자격증명·쿠키·리소스별·서버 집합별 카운팅이 가능하다고 한다. 출처: RFC 6585 §4 datatracker.ietf.org[2]

따라서 이 테스트 세트가 통과했을 때 착각하게 되는 명제는 정확히 이것이다: “공개 요청은 비용 관문을 실제로 통과했고, 그 결과 우리가 의도한 동일 버킷의 비용 카운터가 증가했다.” 이 명제는 응답 코드 관찰만으로는 성립하지 않는다. 카운터 증가의 관측 지점, 버킷 키 정의, 인증 실패와 권한 거부의 구분이 명세나 코드 구조로 고정되어 있어야만 논증이 시작된다.

판정: 카운터 Δ = 관문 통과 요청 수(1:1)를 반복 표본으로 확인해야만 "관문 통과"로 인정한다

측정 설계부터 못 박는다. "관문이 움직였다"는 인상이 아니라 전후 페어드 측정으로만 성립한다.

• 기준선 읽기 → 통제된 N회 요청 → 재읽기, Δ = (사후 − 사전). 공개(재현 가능)이므로 같은 버스트를 최소 3~5회 반복해 Δ의 산포를 관리도 안에 두고 특별원인/공통원인을 분리한다.
• 판정 기준은 단순하다: Δ = N(관문을 실제 통과한 요청 수). 성공 응답이 났는데 Δ=0이면 관문을 지난 게 아니라 계측 지점을 지나친 것이다. Δ가 N을 초과하면 재시도·이중계수(special cause), N에 못 미치면 요청이 카운터 이전에서 소멸한 것이다.

측정 방법 자체의 신뢰성을 먼저 검증한다 — 여기서 대부분의 오판이 난다.

• 계측 지점: 카운터가 인증 앞단(관문 진입)에서 증가하는가, 인증 뒤·캐시 뒤에서 증가하는가. Redis INCR는 원자적·즉시 반영이지만, 읽기 복제본 지연을 통해 Δ를 읽으면 증가가 묻힌다 → 반드시 프라이머리에서 읽는다.
• 캐시 단락(short-circuit): CDN/프록시가 관문 이전에서 응답을 돌려주면 카운터는 절대 안 움직인다(위양성 "관문 미작동"). Cache-Control: no-store + 고유 쿼리/nonce로 캐시 무효화해 요청이 증가 지점까지 도달함을 보장한 뒤 측정한다.
• 관측 지연: 증가와 읽기 사이 창을 고정하고, 창 밖 유입(다른 클라이언트)을 통제하거나 IP 버킷 단위로 격리해 오염을 제거한다.

결론은 하나로 밀어붙인다. 캐시 무효화된 재현 가능한 버스트에서, 프라이머리 카운터의 Δ가 통과 요청 수와 1:1로 일치하고 반복 표본의 산포가 관리 한계 내(공통원인만)일 때 비로소 "비용 관문 통과·계측 성공"이다. 그 외 —Δ=0(캐시 단락/지점 오류), Δ 변동 과다(재시도·경합의 특별원인)— 는 전부 관문 통과가 아니라 측정 실패로 분류한다.

• 참고 근거(사양): 인증 실패 401 — RFC 9110 §15.5.2(rfc-editor.org[1]); 레이트리밋 429 — RFC 6585 §4(rfc-editor.org[2]); 카운터 노출 헤더 규약 — IETF draft-ietf-httpapi-ratelimit-headers(datatracker.ietf.org[3]).

※ 실제 로그·헤더·카운터 스토어 접근 없이 방법론만으로 판정 틀을 세웠다. 위 Δ·반복 수치를 실측치로 채우면 즉시 확정 판정 가능하다.

데밍 초안의 강점은 “응답 코드가 아니라 카운터 Δ를 봐야 한다”는 점을 명확히 한 것이다. 이건 내 초안에 흡수해야 한다. 다만 Δ = N을 “관문 통과”의 필요충분조건처럼 세운 부분은 과하다. 비용 관문이 요청당 1 증가인지, 성공 요청만 세는지, 실패·캐시·프리플라이트·재시도를 어떻게 취급하는지는 시스템 명세에 달려 있다. 따라서 Δ = N은 좋은 실측 기준 후보이지, 명세 없이 곧바로 참인 판정식은 아니다.

또 하나의 약점은 버킷 격리를 사실상 IP 기준으로 전제하는 대목이다. 앞서 지적했듯 429 명세는 사용자 식별 방식을 고정하지 않는다. 그러므로 “IP 버킷 단위로 격리”는 가능한 실험 설계일 뿐이고, 실제 논증에는 “이 공개 요청이 어떤 버킷 키로 카운트되는가”가 먼저 코드나 설정으로 확인되어야 한다. 그렇지 않으면 Δ가 움직여도 그것이 의도한 공개 사용자 비용인지, 공유 익명 버킷인지, 전역 카운터인지 분리되지 않는다.

보완된 결론은 이렇다: 공개 경로 테스트가 비용 관문 실측이라고 주장하려면 최소한 카운터 관측 지점, 버킷 키, 증가 규칙, 캐시/프록시 단락 여부가 고정되어야 한다. 그 위에서 전후 측정 Δ가 명세상 기대값과 일치하면 “이번 조건에서 카운터가 증가했다”까지는 말할 수 있다. 그러나 단순히 공개 엔드포인트가 기대 응답을 냈다는 통과 결과만으로는 여전히 “비용 관문을 실제 통과했고 의도한 비용 버킷이 증가했다”는 명제는 증명되지 않는다.

다익스트라의 지적을 받아들여 판정 기준을 수정한다: Δ=N만으로는 부족하다. "어느 버킷의 Δ인가"가 빠져 있었다.

그의 핵심 반론은 옳고, 내 초안의 실제 구멍을 찔렀다. 나는 "카운터"를 단수로 놓고 Δ만 세었는데, 버킷 키(IP/자격증명/쿠키/리소스)가 고정되지 않으면 Δ=N은 아무것도 증명하지 못하는 숫자다. 옆 버킷이 올라갔는데 내 버킷이 올랐다고 읽는 오판이 정확히 여기서 난다. 따라서 판정식을 이렇게 승격한다: Δ(대상 버킷) = N 이면서 동시에 Δ(대조 버킷 전부) = 0. 후자가 빠진 측정은 측정이 아니다.

다만 그의 결론부는 뒤집는다: 버킷 키는 "명세로 고정되어야 논증이 시작되는" 전제가 아니라, 측정으로 확정하는 관측량이다.

명세와 코드 구조는 가설이지 증거가 아니다. 배포 현실에서 프록시의 X-Forwarded-For 재작성, 미들웨어 장착 순서, CDN 설정 드리프트는 명세와 일상적으로 어긋난다. 그가 "고정되어 있어야만"이라고 쓴 지점에서 나는 요인 설계로 키를 뽑아낸다 — 한 번에 한 축만 바꾸는 2×2 프로브 행렬:

Δ가 행을 따라 움직이면 IP 버킷, 열을 따라 움직이면 자격 버킷, 네 칸 모두 독립이면 (IP×자격) 복합 키다. 명세를 읽어서 아는 게 아니라 Δ의 패턴이 키를 말해준다. 이 행렬이 그의 "가정할 수 없다"를 "측정해서 안다"로 바꾼다 — 불가지론이 아니라 실험 설계가 답이다.

401/403 구분도 흡수하되, 지위를 강등한다: 응답 코드는 선행 점검(pre-check)이지 판정 근거가 아니다.

그의 지적대로 401(자격 없음, WWW-Authenticate challenge 동반)과 403(이해했으나 거부)은 다른 사실을 말하며, WWW-Authenticate가 없는 401은 계측 신호로 신뢰할 수 없다 — 이건 무료로 얻는 유용한 위생 검사라 내 절차에 앞단으로 넣는다. 그러나 코드는 어디까지나 관문 이전에서 소멸했을 가능성을 배제하는 필터일 뿐, 카운터가 움직였다는 증거로 승격시키지 않는다. 이번 질문이 "공개 경로"인 만큼 결정적 실험은 하나다: 동일 N으로 공개 요청과 인증 요청을 각각 때리고 Δ_공개 대 Δ_인증을 비교한다. Δ_공개 = N이면 공개 경로도 비용 관문 안쪽이고, Δ_공개 = 0인데 200이 나오면 공개 경로는 관문 밖에서 응답하는 무과금 경로다 — 이건 버그가 아니라 아키텍처 사실이며, 응답 코드로는 두 경우가 완전히 동일하게 보인다.

그래서 최종 판정은 여전히 숫자로 내린다: 캐시 무효화된 반복 버스트에서, 프로브 행렬로 확정한 버킷의 프라이머리 Δ가 N과 1:1이고 대조 버킷이 0이며 반복 산포가 관리 한계 내일 때만 "비용 관문 통과"다. 그 외는 전부 측정 실패로 분류하고, 실패 유형(Δ=0 캐시 단락/관문 외부 경로, Δ 초과 재시도, 대조 버킷 오염 키 오식별)까지 함께 기록한다.

약점 공략: 다수 의견은 "무엇을 셀지"를 다퉜을 뿐, 재는 자(계측기) 자체를 한 번도 검증하지 않았다.

1) Δ(대조)=0 요구는 공개·라이브 조건에서 스스로 성립 불가능한 판정식이다. 이번 질문의 전제가 "공개"인데, 공개 경로에는 내 프로브와 무관한 실사용자 배경 트래픽이 상시 흐른다. 대조 버킷이 정확히 0으로 읽히는 순간은 라이브에서 거의 존재하지 않으므로, "Δ=0이 아니면 측정 실패"라는 규칙은 사실상 모든 실측을 실패로 분류한다 — 판정식이 아니라 자기봉쇄다. 옳은 형태는 0이 아니라 관리 한계다: 대조 버킷의 이동(=공통원인 표류)이 사전 설정한 관리선 안이고, 대상 버킷 Δ가 그 표류와 통계적으로 구별되는 마진으로 초과할 때만 "움직였다"이다. 다수 의견은 특별원인/공통원인 구분을 카운터에 적용하지 않은 채 0을 요구했다.

2) 관측 지점의 시간적 타당성이 통째로 빠졌다 — 계측기 반복성(Gage R&R)이 없다. 두 리뷰는 버킷 키·증가 규칙은 고정하라 했지만, 카운터 읽기가 신뢰할 만한 게이지인지는 묻지 않았다. 토큰 버킷을 배치로 flush하거나 레플리카에서 읽으면 버스트 직후 Δ는 관측 지연 때문에 N보다 작게 나온다 — 이건 관문을 못 지난 게 아니라 계측 아티팩트다. 선행 절차는 하나 더 필요하다: 알려진 N을 반복 주입해 카운터가 관리 한계 내에서 N을 재현하는지, flush 주기 대비 읽기 타이밍을 고정했는지 확인하는 게이지 검증. 이걸 통과하지 못한 상태의 Δ=N vs Δ=0 비교는 두 값 모두 모래 위다.

3) Δ:N = 1:1은 리뷰 스스로의 양보와 모순된다. 리뷰 2가 "증가 규칙은 명세에 달렸다(가중·재시도·프리플라이트·캐시)"고 인정한 순간, 정상 통과에서도 Δ≠N이 기대되는 결과가 된다 — HTTP/2 멀티플렉싱·연결 재사용·중복제거·가중 과금이면 1:1은 정상 관문을 오히려 기각한다. 결론(단정): 통과 판정은 원시 Δ=N & 대조=0이 아니라, 검증된 게이지 위에서, 배경 차감된 대상 버킷 Δ가 보정된 비용함수 c·N을 관리 한계 내로 추종할 때다. 이 셋 중 하나라도 없으면 카운터가 움직였다는 주장은 측정이 아니라 인상이다.

최종 수정안: 이 테스트가 통과해도 증명되는 명제는 “공개 요청이 기대 응답을 냈다”가 아니라, 더 엄격히는 “검증된 계측 지점에서, 권한 있는 공개 조건의 요청군이, 명세상 정의된 비용함수에 따라 해당 버킷의 카운터 변화를 유발했다”여야 한다. 따라서 원시 판정식 Δ=N 또는 대조 Δ=0은 폐기한다. 공개 운영 경로에서는 배경 트래픽, 비동기 집계, 공유 버킷, 캐시 단락 때문에 0과 N이 논리적으로 깨끗한 참값이 아니다.

핵심 근거는 셋이다. 첫째, 429/레이트리밋 계열 논의만으로는 버킷 키가 IP인지, 익명 사용자군인지, 전역인지 확정되지 않는다. 둘째, 비용 증가 규칙은 요청당 1이 아니라 성공/실패/가중/재시도/프리플라이트/캐시에 따라 달라질 수 있으므로 Δ:N=1:1은 명세 없는 과잉 주장이다. 셋째, 카운터 자체가 즉시·정확한 게이지인지 검증되지 않으면 관측된 Δ는 관문 통과의 증거가 아니라 계측 지연이나 집계 방식의 산물일 수 있다.

결론: 더 강한 최종 판정은 “명시적 권한과 비용 한도 안에서, 버킷 키·관측 지점·증가 규칙·캐시/프록시 단락 여부를 고정하고, 게이지 반복성을 확인한 뒤, 배경 표류를 뺀 대상 Δ가 보정된 비용함수 c(N)을 관리 한계 내에서 따른다”이다. 이 조건 전에는 “비용 관문을 실제 통과했고 의도한 비용 버킷이 증가했다”는 주장은 성립하지 않는다.

최종 수정안

1) 판정식을 "Δ=0"에서 "관리 한계"로 최종 교정한다. 다익스트라의 대조 버킷 요구는 옳았지만, 공개·라이브 조건에서는 배경 트래픽이 상시 흐르므로 Δ(대조)=0은 모든 실측을 실패로 몰아넣는 자기봉쇄다. 특별원인/공통원인 구분을 카운터에 적용하면 답은 명확하다: 대조 버킷의 이동이 사전 설정한 관리선 안(공통원인 표류)이고, 대상 버킷 Δ가 그 표류와 통계적으로 구별되는 마진으로 초과할 때만 "움직였다"로 판정한다. 0이 아니라 배경 차감 후의 유의한 초과가 신호다.

2) 계측기 검증(게이지)을 통과 판정의 선행 관문으로 승격한다. 두 리뷰 모두 "무엇을 셀지"만 다퉜을 뿐 "재는 자가 믿을 만한가"는 묻지 않았다. 토큰 버킷 배치 flush·레플리카 지연·최종일관성이면 버스트 직후 Δ는 관문 통과와 무관하게 N보다 작게 나온다 — 계측 아티팩트다. 그래서 알려진 N을 반복 주입해 카운터가 관리 한계 내에서 N을 재현하는지, flush 주기 대비 읽기 타이밍이 고정됐는지를 먼저 검증한다. 이 게이지를 통과하지 못한 Δ 비교는 두 값 모두 모래 위다.

3) 통과 조건과 권한 전제를 확정한다. 리뷰 2가 인정한 가중·재시도·프리플라이트·캐시·멀티플렉싱을 고려하면 정상 통과에서도 Δ≠N이 기대값이다. 따라서 최종 통과는 원시 1:1이 아니라 검증된 게이지 위에서, 배경 차감된 대상 버킷 Δ가 보정된 비용함수 c·N을 관리 한계 내로 추종할 때다. 그리고 공개 운영 엔드포인트에 N건을 실제로 쏘는 행위는 부하·비용·방어기제 유발이므로, 명시적 권한과 비용 한도 합의를 실험 전제로 결론에 못박는다. 프로브 행렬로 키를 측정 확정한다는 다익스트라와의 절충은 유지한다 — 명세는 가설, Δ의 패턴이 증거다.