아이템 등록 한도를 실제 소비량 기반 사후 정산으로 정밀화

[m-a-king]

왜

#339 로 들어간 아이템 등록 한도는 등록 1건을 균일하게 1 차감하는 선불 예측 방식이다. 등록 시점엔 그 링크가 어느 경로로 풀릴지 알 수 없어 균일이 유일한 선택이었지만, 실제 소비량은 경로마다 크게 다르다.

• 파서로 풀리는 경우 (무신사·29cm·지그재그 등): fetch 대역만
• HEADLESS_FIRST 사이트 (kream·올리브영·에이블리): 헤드리스 렌더러 + residential proxy. 프록시는 사용량 과금이라 LLM 과 별개로 돈이 나간다
• 파서 실패로 LLM fallback: Gemini 호출

균일 차감은 싼 경로를 과하게 깎고 비싼 경로를 덜 깎는다. 정상 사용자가 싼 사이트만 쓰는데도 한도에 닿거나, 비싼 사이트만 골라 쓰는 요청이 상대적으로 싸게 통과한다.

무엇을

파싱이 끝난 뒤 실제로 소비한 자원을 세어 정밀화한다. 등록 시점의 선불 차감(1)은 예약으로 두고, 확정 비용과의 차액을 파싱 완료 시점에 반영하는 구조다.

세는 대상:

• LLM 을 실제로 탔는지 (파서로 풀렸으면 0)
• residential proxy IP 로테이션 횟수
• 헤드리스 렌더러 사용 여부

단계를 나눈다 — 관측 먼저, 차감은 나중

바로 차감으로 넣으면 사용자가 예측할 수 없는 차단이 생긴다. 한도 10 기준으로:

1. 사용자가 링크 5개를 담는다 → 등록 시점에 5 차감 → 잔액 5
2. 응답은 전부 201 성공. 사용자는 "5개 더 담을 수 있겠네" 로 인식한다
3. 그런데 그 5개가 전부 HEADLESS_FIRST 사이트였다 → 실제 비용은 건당 3
4. 사후 정산이 차액 2씩, 총 10 을 추가로 깎는다 → 누적 15
5. 6번째를 담으려 하면 429

사용자 입장에서는 "방금 5개 담았는데 왜 벌써 막히지" 가 된다. 자기 행동과 막힌 시점 사이에 보이지 않는 정산이 끼어서 예측이 안 된다. 실제 비용 분포를 모르는 상태에서는 이 상황이 얼마나 자주 터질지도 알 수 없다.

그래서 두 단계로 나눈다.

단계	내용	판단 근거
1. 관측	실제 소비를 메트릭으로 기록만 하고 차단에는 쓰지 않는다	비싼 경로가 전체의 몇 퍼센트인지, 사용자당 실제 소비 분포가 어떤지를 먼저 본다
2. 차감	관측 결과를 근거로 정산을 한도에 반영한다	그때는 한도 값도 실측 기반으로 다시 잡을 수 있다

구현 메모

• 판정은 이미 잔액 방식이라(userId별 애플리케이션 레벨 레이트리밋 (인증 사용자별 정밀 quota) #339 에서 도입) 사후 정산분을 그대로 얹을 수 있다. 남은 몫이 있으면 통과시키고 넘긴 만큼은 다음 요청이 갚는 구조라, 정산으로 누적이 한도를 넘어도 판정 로직을 바꿀 필요가 없다
• ItemQuotaGuard 는 차감량을 인자로 받으므로, 거부 판정 없이 더하는 메서드 하나를 추가하면 키 구조와 창 개념은 그대로 재사용한다
• core 의 ItemParsingMetrics 가 이미 result·reason 라벨을 세고 있어 관측 단계의 확장 지점이 된다

선행 조건

• extractor 가 소비 정보(LLM 사용 여부, 프록시 로테이션 횟수, 헤드리스 사용 여부)를 응답 계약에 실어야 한다

참고

• userId별 애플리케이션 레벨 레이트리밋 (인증 사용자별 정밀 quota) #339 (선불 균일 차감 + 잔액 판정 도입)
• 아이템 파싱 시간당 가용량 상한 (전역 load shedding) #927 (전역 일일 가용량 상한). 이 이슈와 독립적이다 — 그쪽은 "우리가 하루에 몇 건까지 처리하겠다" 는 가용량 선언이라 등록 건수로 세고, 그 건이 비쌌는지는 관심사가 아니다. 이 이슈는 비용에 비례하는 정밀화라 세는 대상이 다르다