개요
최근 모 스타트업 인턴으로 지원하여 면접을 보고 왔습니다.
서류->과제->1차 면접->2차 면접으로 진행되었고, 저는 1차 면접을 보고 탈락했습니다.
1차 면접에서 과제와 포트폴리오 관련 질문을 주셨는데, 그중에서도 가장 기억에 남는 질문은 다음과 같습니다.
💡 외부 API 요청이 400 또는 429 등 에러코드를 제공했을 때 재시도 로직을 실행시킬 것인가?
이 질문에 대한 대답이 기억나진 않지만, 제대로 대답하지 못한 것 같습니다.
다음에는 제대로 대답할 수 있도록, 질문에 맞는 정답을 찾아보고 기록하려 합니다.
문제 상황
과제의 핵심은 AI 요청을 보내는 것이었습니다.
Spring Boot 웹애플리케이션에서 외부 API 호출 요청을 보내어 AI요청 결과를 저장해야 했습니다.
프로젝트 설계는 다음과 같습니다.
사용자의 요청이 들어오면 사용자 요청에 대한 처리를 진행하고 AI 요청 이벤트를 발행하게 됩니다.
사용자의 요청 처리에 대한 트랜잭션이 COMMIT이 되는 경우 이벤트 리스너가 동작합니다.
이벤트 리스너가 동작하면 새로운 트랜잭션에서 외부 API 요청이 진행되도록 설계하였습니다.
외부 API 요청은 일시적인 네트워크 오류나 서버 오류 등으로 실패할 수 있기 때문에 Spring에서 제공하는 @Retryable 어노테이션을 사용하여 관리하고자 했습니다.
재시도는 어떤 경우에 하는데요?
면접에서 받았던 질문은 다음과 같았습니다.
- AI 요청을 보냈는데 HTTP 400 상태 코드가 반환되면 재시도를 해야 할까요?
- AI 요청을 보냈는데 HTTP 429 상태 코드가 반환되면 재시도를 해야 할까요?
- AI 요청을 보냈는데 HTTP 500 상태 코드가 반환되면 재시도를 해야 할까요?
세 가지 질문들에 하나씩 대답해 보겠습니다.
HTTP 400 - ❌
HTTP 400 상태 코드가 반환된다는 의미는 요청 본문(body)에 잘못된 형식이나 값이 포함되어 있음을 의미합니다.
즉 클라이언트의 요청이 올바르지 않는다는 의미입니다.
결국, 이런 경우에는 재시도를 보내게 되더라도 동일한 오류가 발생하게 되므로 재시도가 동작하면 안 됩니다.
대신, 오류가 발생했음을 사용자에게 알리고 데이터 검증이나 필수 값 누락 등 수정을 해야 합니다.
HTTP 429 - ✅
HTTP 429 상태 코드는 Too Many Requests를 의미하며 일정 시간 동안 너무 많은 요청을 보냈을 때 이를 거부하기 위해 사용합니다.
일정 시간 동안 너무 많은 요청이 과도하게 오는 경우를 방지하여 서버의 리소스 과다 사용을 방지하기 위해 사용합니다.
이런 경우에는 재시도를 하더라도 429 상태 코드를 반환하게 됩니다.
제가 생각하는 해결 방법은 일정 시간이 지난 이후에 다시 API요청을 보내는 방식이 있을 것 같습니다.
아니면 재시도 로직을 더욱 정교하게 설정하여 요청 제한을 준수하거나 재시도 사이의 시간을 점진적으로 늘려가는 방식을 사용하여 해결해야 합니다.
HTTP 500 - ✅
HTTP 500 상태 코드는 Internal Server Error를 의미하며 서버에 오류가 발생해 작업을 수행할 수 없을 때 사용됩니다.
500번이나 503번 같은 경우에는 시스템 과부하, 메모리 부족, 일시적 네트워크 장애 등 일시적인 오류가 발생하는 경우 반환됩니다.
서버가 정상적으로 복구되면 오류가 사라질 가능성이 높기 때문에 재시도 로직이 유효하게 동작할 수 있습니다.
참고
https://namu.wiki/w/HTTP/%EC%9D%91%EB%8B%B5%20%EC%BD%94%EB%93%9C
'Teck Stack > Spring' 카테고리의 다른 글
| [Auth] OAuth2 로그인 시 Access Token을 헤더에 담는 방법 (0) | 2025.12.09 |
|---|---|
| [Auth] OAuth2 구글 로그인 + JWT 방식의 인증 플로우 (0) | 2025.12.08 |
| [Spring] @Scheduled 대신 Quartz를 사용한 스케줄링 구현 (0) | 2025.10.14 |
| [Spring] MultipartFile + DTO 요청 받기 (feat : 415 에러 해결) (0) | 2025.06.30 |