API 요금 사고 막기 — 세 겹의 방어선

API는 쓴 만큼 청구됩니다. 편리한 구조지만 실수로 많이 쓰면 그만큼 청구된다는 뜻이기도 합니다. 코드가 반복 호출에 빠지면 하루 만에 예상 밖의 금액이 나올 수 있습니다.

이 글은 그런 사고를 막는 세 겹의 방어선을 정리합니다.

왜 사고가 나는가

구독은 아무리 많이 써도 정액입니다. API는 다릅니다. 다음 상황에서 금액이 급격히 늘어납니다.

• 반복 호출. 재시도 코드가 실패를 반복하며 계속 호출하는 경우
• 긴 입력의 반복. 대화를 이어 가는 코드가 매번 전체 기록을 보내는 경우
• 키 노출. API 키가 공개된 곳에 올라가 남이 쓰는 경우
• 모델 착각. 테스트에서 가장 비싼 모델을 그대로 쓰는 경우 — 요율이 20배까지 차이 납니다

공통점은 돌아가고 있는 동안에는 알기 어렵다는 것입니다. 그래서 사후 확인이 아니라 사전 차단이 필요합니다.

1차 방어선 — 지출 한도

가장 확실한 방어선입니다. 계정에 월 한도를 걸어 두면 그 금액을 넘겨 청구되지 않습니다.

한도는 감당할 수 있는 금액으로 잡으시길 권합니다. “이 정도면 넉넉하겠지”가 아니라 “최악의 경우 이 금액까지는 물어도 된다”가 기준입니다. 한도는 예산이 아니라 안전장치입니다.

설정 위치와 절차는 오픈AI 지출 한도 글과 앤트로픽 과금 관리 글에 적어 두었습니다.

2차 방어선 — 자동 충전 끄기

잔액이 떨어지면 자동으로 충전하는 기능이 있습니다. 편리하지만 사고가 났을 때 계속 충전됩니다.

자동 충전을 꺼 두면 잔액이 소진되는 시점에 호출이 멈춥니다. 서비스가 잠시 중단되는 대신 금액이 무한정 늘어나지는 않습니다.

운영 중인 서비스라면 중단이 곤란할 수 있으니, 한도는 걸되 자동 충전은 켜 두고 알림을 촘촘히 하는 조합도 방법입니다. 어느 쪽이든 두 설정을 모두 확인해 두는 것이 중요합니다.

3차 방어선 — 알림

한도가 최후의 방어선이라면 알림은 조기 경보입니다. 사용량이 일정 금액을 넘으면 메일이 오도록 설정할 수 있습니다.

실용적인 방법은 여러 단계로 거는 것입니다. 평소 사용량의 2배 지점에 하나, 한도의 절반 지점에 하나. 첫 알림이 평소보다 일찍 오면 그때 확인하면 됩니다.

코드 쪽에서 할 수 있는 것

1. 재시도 횟수를 제한합니다. 무한 재시도는 사고의 가장 흔한 원인입니다.
2. 최대 출력 길이를 지정합니다. 출력 요율이 입력의 5~6배이므로 상한을 두면 최악의 경우가 줄어듭니다.
3. 테스트는 싼 모델로 합니다. 코드가 도는지 확인하는 단계에서 비싼 모델을 쓸 이유가 없습니다.
4. 키를 코드에 적지 않습니다. 환경 변수로 분리하면 실수로 공개될 위험이 크게 줄어듭니다.
5. 사용량 로그를 남깁니다. 응답에 오는 토큰 수를 기록해 두면 이상한 증가를 빨리 알아챌 수 있습니다.

사고가 이미 났다면

먼저 호출을 멈추는 것이 순서입니다. 키를 폐기하면 그 키를 쓰는 모든 호출이 즉시 멈춥니다. 원인을 찾는 것은 그다음입니다.

이미 발생한 청구에 대한 조정 가능 여부는 서비스 정책에 달려 있습니다. 저희가 각 서비스의 예외 처리 정책을 원문으로 확인하지 못했으므로 “환불된다”고 단정하지 않습니다. 사용량 내역과 함께 고객센터에 문의하시는 것이 확인 방법입니다.