LLM API를 사용해 제품을 개발할 때 겪는 공통적 문제점이 하나 있습니다. 바로 maxDuration 문제입니다. 저도 어제까지 그 문제를 겪었습니다. 이 문제는 개발 환경에서는 발생하기 어렵지만 배포 환경에서 호스팅 서비스에 게이트 웨이 타임아웃 시간 또는 프론트 클라이언트의 우동화된 서버리스 함수로 인해 발생합니다.
이게 무슨 말이냐구요? 아주 구체적 예시를 들어보겠습니다.
GPT를 통해 이미지 생성이나 전문화된 응답 요청시 경우에 따라 90초 이상의 대기가 발생합니다. 웹 클라이언트를 Vercel과 같은 서비스를 통해 배포한 경우에 Vercel은 기본적으로 Fluid compute를 지원하여 API 호출에 대한 응답을 유동화된 컴퓨팅 자원으로 지원합니다.
즉 요청이 발생하면 서버리스 콜백 함수 형태로 이를 확장하고, 일정 시간(maxDuration)을 초과하면 release하여 증가시킨 API 리스너를 축소시킵니다. 이 과정에서 LLM API 응답이 유실되어 결과적으로 504 게이트웨이 시간 초과 에러를 야기시킵니다.
근데 참 이상한 점은 Vercel의 공식 문서에는 최대 대기 시간 설정만 하면 작동엔 문제가 없다고 한다는 점입니다. 제가 이를 해결한 방법은 아이러니하게도 공식 문서에서 제대로 지원한다는 유동 컴퓨팅 옵션을 꺼버리는 것이었습니다.
그러면 정적 컴퓨팅 자원으로 최대 유지 시간은 Pro 플랜 기준 900초에서 300초로 감소하지만 대부분의 LLM 응답은 180초 이내로 응답되니 문제가 없었습니다.
이처럼 배포 환경에서만 발생할 수 있는 서드파티 API 응답의 대기 시간을 우회하려면 백그라운드 요청 형태로 구조를 처음부터 다르게 설계하거나 백엔드 서버측 이벤트나 메시지 큐 등의 대안적 설계를 채택하는 것도 좋습니다. 만약 대안적 설계로 바꾸기에 너무 오래걸린다면 유동화된 컴퓨팅 옵션을 끄면 됩니다. 때로는 공식 문서와 달리 작업을 진행해야 한다는 점에서 개발은 경험의 영역이라 할 수 있을 것 같습니다.
