지금 것보다 훨씬 이전, 이 서비스가 아직 지금의 모노레포 구조(packages/api)로 옮겨오기 전 — Next.js 앱 하나로 다 하던 시절 이야기다. Riot API 연동을 처음 붙인 지 딱 이틀 만에 벽에 부딪혔다.

시작 — dev key로는 답이 없다

Riot Games API를 처음 붙였을 때 쓸 수 있는 건 개발자용(dev) 키뿐이었다. dev key의 요청 한도는 코드 주석에 이렇게 적혀 있었다.

// Riot dev key 한도(100req/2min). puuid 캐시로 유저당 1호출(light) 또는 14호출(풀).
// light: 100req/120s = 1.2s/req — 여유있게 700ms.
// 풀 모드: 유저당 14호출 × 36명 = 504호출. 120s 한도 안에서 절대 못 돌리니 3s 유지.
await new Promise((r) => setTimeout(r, skipChampions ? 700 : 3000));

전체 랭크 갱신 같은 관리자 작업은 유저 한 명당 여러 번 API를 호출해야 하는데, dev key 한도(120초에 100회) 안에 다 못 넣으니 유저 사이사이에 강제로 딜레이를 넣어서 버텼다. 36명 전체를 raw 모드로 갱신하려면 유저당 3초씩, 총 100초 넘게 걸렸다.

부작용도 있었다. “솔랭왕” 위젯 같은 통계 기능은 아예 요청 수를 줄이는 쪽으로 타협했다 — 최근 매치 여러 개를 다 보는 대신 딱 1경기만 보고 평균 플레이타임을 추정하거나, 실패하면 30분으로 뭉뚱그려 표시했다.


이틀 뒤 — production key로 전환

Riot API 연동을 붙인 지 이틀 만에 production key로 바꿨다. production key의 한도는 10초에 500회, 10분에 30,000회 — dev key와는 자릿수가 다르다.

- // Riot dev key 한도(100req/2min). ...
- await new Promise((r) => setTimeout(r, skipChampions ? 700 : 3000));
+ // Riot prod key 한도(500req/10s, 30000req/10min). 여유 충분하므로 최소 딜레이만.
+ await new Promise((r) => setTimeout(r, skipChampions ? 50 : 200));

계산해보면 실제로 체감되는 효과다. 36명 기준 raw 모드 갱신이 유저당 700ms(light 모드 기준) × 36 ≈ 25초에서, 50ms × 36 ≈ 2초로 줄었다.

요청 수를 아끼려고 타협했던 부분들도 원래대로 되돌렸다. 솔랭왕 위젯은 매치 1개만 보던 걸 최근 20개 매치를 병렬로(Promise.allSettled) 조회해서 실제 플레이타임 합산으로 바꿨고, 개별 실패가 있어도 나머지로 계산하도록 fallback도 “전부 실패했을 때만 추정치 사용”으로 좁혔다. 주간 솔랭 통계도 표본을 10경기에서 20경기로 늘렸다.


정리

  • 처음부터 production key를 받을 수 있었다면 이 워크어라운드 자체가 필요 없었다. 하지만 서비스 시작 시점엔 실사용 트래픽 근거가 없어 dev key로 시작할 수밖에 없었고, 그 제약을 코드 곳곳(딜레이 상수, 통계 표본 축소)에 녹여야 했다.
  • 제약을 위한 코드는 제약이 풀리면 반드시 걷어내야 한다. 딜레이 상수와 표본 축소 로직은 겉으로는 “정상 동작”처럼 보이지만, 사실은 dev key라는 특정 조건에 맞춰진 타협이었다. production key로 넘어가면서 그 흔적을 전부 되돌렸다.
  • 딱 이틀. 이 정도로 짧게 버틴 워크어라운드도 코드에 흔적을 꽤 많이 남긴다는 걸 보면, 제약이 오래갈수록 나중에 걷어내기 더 번거로워질 거라는 짐작이 든다.