시도 한 번이 비싼 경우가 있다

외부 API 연동을 시험하는데 계정이 잠겼다. 문서를 보니 인증 실패가 하루 다섯 번이면 잠긴다고 적혀 있었다.

Table of contents

아무 생각 없이 눌렀다

시험할 때 PHP 코드를 고치고 실행하고 실패하면 또 고치고 실행하기를 반복했다. 한 번 돌리는 데 몇 초라 부담이 없었고 다섯 번이 금방이었다.

한 번의 비용이 안 보이면 아껴 쓰지 않는다. 우리 시스템 안에서만 도는 것은 몇 번을 돌려도 비용이 없는데 밖으로 나가는 것은 시도 자체에 비용이 붙는다.

제한이 있는 것을 목록으로 만들었다

연동하는 것 중에 횟수 제한이 있는 것을 찾아봤다.

인증 실패     하루 5회 → 계정 잠김
API 요청      분당 60회 → 429 응답
문자 발송     하루 2,000건 → 초과분 미발송
결제 승인     실패 3회 → 카드 일시 정지

넷 다 시험 중에 걸릴 수 있는 것들이었고 API 문서에 있는데 안 읽고 있었다.

호출 수 제한은 응답 자체에 표시가 오기도 한다. 너무 많이 보냈다는 뜻의 429 가 규격에 정의돼 있고 얼마나 기다렸다 다시 오라는 Retry-After 헤더를 같이 실어도 된다고 적혀 있다.

제한을 알고 시작하는 것과 걸리고 나서 아는 것의 차이가 컸다.

실제 호출 없이 확인했다

대부분은 실제로 안 불러도 확인할 수 있었다. 먼저 httpPost 앞에서 요청 형태를 찍어 본다.

$body = $this->buildRequest($data);

if (DEBUG_NO_SEND) {
    log_message('debug', "요청: " . json_encode($body, JSON_UNESCAPED_UNICODE));
    return ['code' => 'DEBUG', 'sent' => false];
}

return $this->httpPost($url, $body);

DEBUG_NO_SEND 가 켜져 있으면 안 보내고 무엇을 보낼지만 남긴다. 형식이 맞는지는 이것으로 대부분 확인된다.

다음은 모의 응답이다. 상대 응답 예시를 파일로 두고 그것으로 처리 로직을 시험한다.

if (DEBUG_MOCK) {
    $raw = file_get_contents(APPPATH . 'tests/mock/auth_success.json');
    return json_decode($raw, true);
}

auth_success.json 은 실제로 한 번 성공했을 때 저장해 뒀다. 실제 호출은 앞의 둘로 확인한 뒤 마지막에 한 번만 부른다.

시험용 계정과 남은 횟수

그래도 실제 httpPost 는 필요했고 운영 계정으로 하면 위험하다. 상대에게 시험용 계정을 요청했는데 제한이 더 느슨하거나 실제 처리가 안 되는 계정이다.

없는 경우도 있었고 그때는 실제 호출 횟수를 세면서 했다.

$today = date('Ymd');
$cnt = (int)$this->cache->get("api_call:{$today}");

if ($cnt >= 3) {
    log_message('warning', "오늘 실제 호출 {$cnt}회. 더 하려면 확인 필요");
    return false;
}
$this->cache->save("api_call:{$today}", $cnt + 1, 86400);

api_call 카운트가 세 번을 넘으면 멈추고 더 하려면 코드를 고쳐야 하니 한 번 생각하게 된다.

상대 응답에 남은 횟수가 있으면 log_message 로 남겼고 없으면 우리가 센 횟수를 보여 줬다. 남은 횟수가 보이면 다음 시도를 신중하게 한다.

사전 준비 — 해제 절차와 확인 순서

잠기면 어떻게 푸는지도 확인했다.

계정 잠김 해제
1. 상대 관리자 화면에서 해제 (즉시)
2. 안 되면 담당자에게 연락 (평일 09~18시)
3. 24시간 뒤 자동 해제

세 번째 항목이 있어서 최악의 경우에도 하루면 풀린다는 것을 알았다. 절차를 모르면 잠긴 순간에 당황한다.

연동 작업의 순서도 정했다.

1. 문서에서 제한을 확인한다
2. 요청 형태를 찍어 형식을 맞춘다
3. 모의 응답으로 처리 로직을 맞춘다
4. 시험 계정으로 한 번 실제 호출
5. 응답을 저장해 모의 응답으로 쓴다
6. 운영 계정은 마지막에

5번이 다음 작업을 쉽게 만들었다. 한 번 성공한 응답이 있으면 그다음부터는 실제 호출이 거의 필요 없다.

정리

• 횟수 제한이 있으면 한 번의 시도가 비싸다
• 밖으로 나가는 것은 시도 자체에 비용이 붙는다
• 연동 대상의 제한을 목록으로 만들고 대개 문서에 적혀 있다
• 호출 수 제한은 429 와 Retry-After 로 오기도 한다
• 요청 형태를 찍고 모의 응답으로 처리하면 실제 호출 없이 확인된다
• 시험용 계정을 요청하고 없으면 호출 횟수를 세면서 한다
• 남은 횟수를 로그에 보이면 다음 시도가 신중해진다
• 잠긴 뒤의 해제 절차를 미리 확인한다
• 한 번 성공한 응답을 저장해 두면 그다음부터 실제 호출이 거의 필요 없다