[Vercel][비용] Fluid Compute에서 duration과 memory를 같이 봐야 하는 이유

IT 리서치 노트

[Vercel][비용] Fluid Compute에서 duration과 memory를 같이 봐야 하는 이유

Vercel Functions 비용을 옛 serverless 기준으로만 보면 계산이 어긋나기 쉽다. 현재 기본은 Fluid Compute이며, active CPU와 provisioned memory 시간을 함께 봐야 한다. 실무에서는 함수 duration만 줄이면 된다고 생각하지만, 실제로는 메모리 설정과 concurrency 패턴이 같이 비용을 바꾼다. 이 글은 AI 호출, DB 대기, 이미지 처리처럼 성격이 다른 함수에서 무엇을 먼저 봐야 하는지 정리한다.

목차

1. 개요
2. 어디서 막히는가
3. 실제로 해결하는 순서
4. 화면과 출력으로 확인하기
5. 주의할 점
6. 결론
7. 참고 링크

1. 개요

Vercel Functions 비용을 옛 serverless 기준으로만 보면 계산이 어긋나기 쉽다. 현재 기본은 Fluid Compute이며, active CPU와 provisioned memory 시간을 함께 봐야 한다.

실무에서는 함수 duration만 줄이면 된다고 생각하지만, 실제로는 메모리 설정과 concurrency 패턴이 같이 비용을 바꾼다. 이 글은 AI 호출, DB 대기, 이미지 처리처럼 성격이 다른 함수에서 무엇을 먼저 봐야 하는지 정리한다.

• 이 글은 현재 공식 문서와 공개 도움말을 다시 확인한 뒤 정리했다.
• 설정 경로, 실패 지점, 검증 결과를 분리해서 읽으면 바로 실행에 옮기기 쉽다.
• 실제 운영에서는 권한, 비용, 배포 로그를 함께 봐야 같은 실수를 반복하지 않는다.

2. 어디서 막히는가

문제가 길게 보이더라도 실제 막힘은 몇 가지 패턴으로 모인다. 아래 증상 중 하나라도 보이면 설정값, 요청값, 실행 결과를 분리해서 기록하는 쪽이 빠르다.

• 대기 시간이 긴 함수인데 CPU time도 같은 비율로 과금될 것이라 오해한다.
• 메모리를 높였는데 호출 시간은 줄어도 총비용은 내려가지 않는다.
• 동시 요청이 몰릴 때 함수 인스턴스가 어떻게 재사용되는지 감이 없다.
• 실행 시간 제한만 보고 비용표를 따로 보지 않아 배포 후 청구서를 보고 놀란다.

여기서 가장 흔한 실수는 증상만 보고 권한을 넓히거나 비용 플랜을 올리거나, 별도 로그 없이 다시 시도하는 것이다. 그러면 당장은 지나가도 다음 배포나 다음 운영 시간대에 같은 문제가 다시 나온다.

따라서 먼저 실제 값과 공식 기준이 어떻게 다른지 좁히고, 그 다음에 클릭, 입력, 실행, 저장 순서를 하나씩 재현해야 한다. 이 순서가 있어야 팀원끼리 같은 결과를 볼 수 있다.

문제정의 단계에서는 오류 문구 한 줄만 보는 대신, 어떤 메뉴에서 확인했고 어떤 필드가 비어 있었는지, 어떤 응답 상태가 먼저 나타났는지까지 적어두는 편이 좋다. 그래야 해결 단계에서 값을 바꾼 뒤에도 같은 기준으로 성공과 실패를 다시 비교할 수 있다.

특히 비용 문제나 권한 문제는 겉으로는 비슷하게 보여도 원인이 다르다. 청구 화면, 콘솔 설정, 배포 로그, 브라우저 요청, CLI 출력 가운데 무엇이 기준 화면인지 먼저 정하고 그 화면을 중심으로 확인해야 엉뚱한 메뉴를 오래 헤매지 않는다.

3. 실제로 해결하는 순서

아래 순서는 메뉴를 열고 값을 확인하고 결과를 다시 보는 실무용 순서다. 한 번에 모두 바꾸지 말고 한 단계씩 적용한 뒤 출력과 화면을 확인하는 편이 안전하다.

1. 먼저 함수 종류를 CPU 중심과 I/O 대기 중심으로 나눈다.
2. Vercel Usage 화면에서 active CPU와 memory 관련 지표를 같이 본다.
3. 메모리 조정 전후로 응답 시간과 사용량을 같이 기록한다.
4. 긴 AI 호출은 함수 한 번에 너무 많은 하위 작업을 몰지 않는 구조로 바꾼다.

안전한 예제 코드

export const maxDuration = 30;

export async function POST(req: Request) {
  const payload = await req.json();
  // 긴 외부 API 호출이 있으면 함수 내부 fan-out 개수를 먼저 줄인다.
  const result = await callExternalApi({
    jobId: payload.jobId,
    limit: 3,
  });
  return Response.json(result);
}

예제는 duration 설정 위치와 fan-out 제한 의도를 보여주기 위한 것이다. 실제 프로젝트명과 내부 API 주소는 넣지 않았다.

예제 코드는 흐름만 남겼다. 실제 토큰, 계정, 내부 서버 주소, 비공개 저장소 이름은 placeholder로 바꾸고 서버 환경변수나 보안 저장소로 분리한다.

중요한 점은 설정 변경 직후 바로 다음 단계로 넘어가지 않는 것이다. 각 단계마다 어떤 메뉴를 클릭했고, 어떤 값을 입력했고, 어떤 출력이 돌아왔는지 짧게라도 기록해야 한다. 그래야 실패했을 때 마지막으로 바뀐 값이 무엇인지 빠르게 되짚을 수 있다.

또한 해결 절차는 한 번 성공했다고 끝나지 않는다. 같은 절차를 다른 환경이나 다른 브랜치, 다른 계정에서도 다시 실행해 보고 결과가 같은지 확인해야 한다. 운영 환경과 로컬 환경의 URL, 권한, 캐시, 플랜, 리전 차이가 숨어 있으면 여기서 드러나는 경우가 많다.

4. 비용과 제한 화면에서 같이 볼 항목

Fluid Compute 비용은 호출 횟수만으로 판단하기 어렵다. 아래 화면에서는 기능 설명, 동시성, duration, memory, 제한 값을 함께 보면서 실제 비용이 어디서 늘어나는지 확인한다.

먼저 Fluid Compute 문서의 기본 설명을 확인한다. 서버리스 함수가 더 오래 실행될 수 있다는 점만 보지 말고, 어떤 런타임과 사용 방식에서 의미가 있는지 봐야 한다.

Fluid Compute 문서에서는 기능의 기본 목적과 적용 범위를 먼저 확인한다.

동시성 설명은 비용 계산과 직접 연결된다. 같은 요청 수라도 한 인스턴스가 동시에 처리하는 요청 수가 달라지면 duration과 대기 시간이 함께 달라진다.

Optimized concurrency 화면에서는 한 인스턴스가 여러 요청을 처리할 때 성능과 비용이 어떻게 연결되는지 확인한다.

가격 문서에서는 duration과 memory를 따로 보지 않는다. 실행 시간이 길고 메모리 설정이 크면 같은 호출 수에서도 사용량이 빠르게 늘어난다.

pricing 화면에서는 duration, memory, 실행 모델을 같이 읽어야 실제 청구 기준을 놓치지 않는다.

제한 문서는 비용 상한을 잡을 때 필요하다. 함수가 오래 실행되도록 바꿨다면 max duration 제한과 plan별 차이를 함께 확인해야 한다.

Vercel Functions 제한 화면에서는 max duration과 런타임별 제한을 확인한다.

마지막으로 memory 제한을 본다. CPU 병목인지 메모리 병목인지 모르는 상태에서 설정만 키우면 비용은 늘고 문제 원인은 남을 수 있다.

Memory size limits 화면은 함수 설정을 키우기 전에 비용과 성능 영향을 함께 비교할 때 확인한다.

이 순서로 확인하면 문서의 기능 설명, 설정 범위, 제한 조건, 실제 운영 판단 기준을 한 번에 대조할 수 있다. 화면에서 먼저 볼 항목을 정한 뒤 코드나 콘솔 설정을 수정해야 같은 문제가 반복되지 않는다.

5. 주의할 점

설정을 맞췄더라도 운영에서는 다시 틀어지는 지점이 있다. 아래 항목은 배포 직전과 배포 직후에 꼭 다시 점검할 부분이다.

• 함수 대기 시간을 전부 CPU 비용처럼 오해하면 잘못된 최적화를 하게 된다.
• 메모리만 키우면 병목이 외부 API일 때 비용만 늘 수 있다.
• 제한 시간을 충분히 주지 않으면 실패 재시도로 호출 수가 오히려 늘 수 있다.

특히 권한, 비용, 캐시, 재시도 정책은 한 번 맞춘 뒤에도 환경이 바뀌면 다시 확인해야 한다. 문서가 바뀌었는지, 콘솔 기본값이 달라졌는지, 팀의 배포 방식이 바뀌었는지도 같이 본다.

6. 결론

대기 시간이 긴 함수는 duration만 보지 말고 실제 active CPU를 본다.

• 대기 시간이 긴 함수는 duration만 보지 말고 실제 active CPU를 본다.
• 메모리 상향은 성능 실험 뒤에만 적용한다.
• 외부 API fan-out이 크면 구조를 먼저 바꾸고 플랜을 나중에 본다.

핵심은 추상적인 '좋은 설정'을 찾는 것이 아니라, 지금 내 서비스에서 어떤 값과 어떤 출력이 정답인지 빠르게 확인하는 것이다. 이 글의 순서대로 문서, 설정, 실행 결과를 묶어 보면 같은 문제를 다시 만났을 때 훨씬 빨리 끝낼 수 있다.

실제 청구액을 다시 계산할 때는 Active CPU·Provisioned Memory·Invocations 합산 절차로 세 항목을 분리한다. 그 다음 서울 icn1과 미국 iad1의 리전 선택 기준으로 데이터 위치와 단가를 대조하고, CPU·메모리 병목이 확인된 함수만 2GB Standard와 4GB Performance 비교 실험을 진행하면 된다.

7. 참고 링크

1. https://vercel.com/docs/fluid-compute
2. https://vercel.com/docs/functions/usage-and-pricing
3. https://vercel.com/docs/functions/limitations