[Vercel][운영] Runtime Logs에서 memory 경고가 보일 때 memory size를 올리기 전에 payload 크기와 외부 API 대기를 먼저 나누는 법

IT 리서치 노트

[Vercel][운영] Runtime Logs에서 memory 경고가 보일 때 memory size를 올리기 전에 payload 크기와 외부 API 대기를 먼저 나누는 법

Vercel Runtime Logs에서 memory warning이 보이면 많은 팀이 바로 Function memory size를 올린다. 하지만 2026년 7월 6일 기준 Vercel 공식 문서를 다시 보면 메모리 상향은 CPU와 비용도 함께 바꾸고, Observability는 External APIs 지연과 Peak Memory, Function Wall Time을 서로 다른 지표로 분리해 제공한다. 이 글은 Runtime Logs에서 memory 경고가 보일 때 memory size를 올리기 전에 payload 크기와 외부 API 대기를 어떤 순서로 나눠 볼지 정리한 것이다.

목차

1. 개요
2. 어디서 실제로 막히는가
3. 실무에서 적용하는 순서
4. 공식 문서와 예시 화면으로 확인하기
5. 주의사항과 리스크
6. 결론
7. 참고 링크

1. 개요

결론부터 말하면 memory warning을 본 직후의 첫 질문은 '얼마나 올릴까'가 아니라 '이 경고가 payload 때문인가, upstream wait 때문인가'여야 한다. Vercel 문서는 memory 상향이 CPU와 비용을 같이 바꾼다고 설명하고, Observability는 External APIs latency, Peak Memory, Function CPU Time, Function Wall Time을 서로 다른 축으로 제공한다. 따라서 Runtime Logs 한 줄만 보고 설정을 키우기보다 이 네 신호를 먼저 나눠 보는 편이 비용과 재발을 함께 줄인다.

이미 FUNCTION_INVOCATION_TIMEOUT이 날 때 maxDuration과 Runtime Logs를 같이 보는 글이 timeout 출발점을 설명했다면, 이번 글은 timeout 전 단계의 memory warning 해석이다. 또 memory 경고와 function memory size를 같이 보는 글은 메모리 설정 판단을 다뤘고, 오늘은 상향 전에 더 좁혀 보는 분기다.

2. 어디서 실제로 막히는가

실무에서 흔한 실수는 세 가지다. 첫째, memory warning이 뜬 요청을 모두 메모리 부족으로만 본다. 둘째, payload가 커서 Peak Memory가 올라간 요청과, 외부 API가 느려서 Wall Time만 늘어난 요청을 한 범주로 묶는다. 셋째, memory size 상향이 CPU와 비용도 함께 바꾼다는 점을 잊고 무조건 상향부터 한다.

Vercel Runtime Logs 문서는 로그 탭에서 request row, 상태 코드, 함수 유형, RequestId를 같이 보라고 설명한다. Memory 설정 문서는 메모리 상향이 CPU와 비용에 동시에 영향을 준다고 적는다. Observability Insights 문서는 External APIs 탭에서 요청 수, p75 latency, error rate를 따로 보라고 하고, Query Reference는 Peak Memory, Function CPU Time, Function Wall Time, Fast Origin Transfer를 별도로 제공한다. 이 네 출처를 같이 읽으면 memory warning은 단일 원인이 아니라 적어도 payload, CPU, upstream wait 세 갈래로 갈라 봐야 하는 신호라는 점이 보인다.

특히 Runtime Logs에서 경고가 보이는 순간만 보면 모든 요청이 비슷해 보이지만, Query에서 Peak Memory는 높지 않은데 Wall Time만 길고 External APIs p75가 치솟는 경우가 있다. 반대로 External APIs는 안정적인데 CPU Time과 Peak Memory가 같이 올라가면 JSON 직렬화, 큰 응답 본문, 이미지 처리, 압축 비용을 먼저 의심하는 편이 맞다.

• 증상: memory warning이 반복되지만 상향 뒤에도 체감 지연이 그대로다.
• 실패: payload 문제와 upstream wait를 분리하지 않는다.
• 막힘: Peak Memory와 Wall Time을 같은 의미로 읽는다.
• 누락: memory 상향이 CPU와 비용을 함께 바꾼다는 점을 기록하지 않는다.

상황	먼저 볼 곳	판단 기준
경고와 함께 CPU도 높다	Peak Memory, Function CPU Time	payload와 처리 로직을 먼저 줄인다
Wall Time만 길다	External APIs latency, error rate	upstream wait와 retry를 먼저 본다
비용이 갑자기 올라간다	Provisioned Memory, Active CPU	무분별한 memory 상향 여부를 본다

3. 실무에서 적용하는 순서

가장 짧은 triage 순서는 다섯 단계다. 먼저 Runtime Logs에서 문제가 난 RequestId와 route를 고정한다. 두 번째로 Query에서 Peak Memory, Function CPU Time, Function Wall Time을 같은 시간 창으로 본다. 세 번째로 Insights의 External APIs 탭에서 같은 시간의 upstream latency와 error rate를 확인한다. 네 번째로 payload 크기와 응답 본문 크기를 로그로 남긴다. 마지막으로 payload 쪽 병목인지 upstream wait인지 분리한 뒤에만 memory size 상향 여부를 다시 판단한다.

1. Runtime Logs에서 RequestId와 route를 먼저 고정한다.
2. Peak Memory, CPU Time, Wall Time을 같은 시간 창으로 비교한다.
3. External APIs latency와 error rate를 확인한다.
4. payload 크기와 응답 크기를 로그에 남긴다.
5. 원인이 좁혀진 뒤에만 memory size 상향을 검토한다.

핵심은 memory warning을 '설정 문제'와 '요청 특성 문제'로 분리하는 것이다. 설정 문제라면 memory와 CPU를 같이 조정할 가치가 있지만, 요청 특성 문제라면 payload 축소, 캐시, upstream timeout, 병렬화 재조정이 더 먼저다. 이 순서를 지키면 같은 경고라도 더 싼 방법으로 줄일 수 있는 경우를 놓치지 않는다.

triage 메모 예시

request_id=req_7f1
peak_memory_mb=792
cpu_time_ms=1480
wall_time_ms=6120
payload_bytes=184002
external_api_p75_ms=140
decision=payload-first

이 정도 메모만 있어도 다음 배포에서 무엇을 먼저 바꿀지 훨씬 빨리 정해진다.

4. 공식 문서와 예시 화면으로 확인하기

첫 자료는 Runtime Logs의 기본 역할이다. Vercel은 로그 탭에서 실행 정보, 상태 코드, 함수 유형, RequestId까지 함께 보라고 설명한다.

Vercel Runtime Logs 문서는 로그 탭에서 실행 정보를 검색하고 분류할 수 있다고 안내한다.

즉 memory 경고를 봤다고 바로 메모리 옵션부터 올리는 것이 아니라, 어떤 요청에서 어떤 실행 정보와 함께 나타났는지부터 확인하는 편이 맞다. 같은 경고라도 payload가 큰 요청인지, 외부 API 대기가 긴 요청인지 해석이 달라질 수 있다.

두 번째 자료는 Vercel memory 설정 문서다. 문서는 memory를 올리면 CPU도 같이 늘 수 있고, Provisioned Memory 비용도 함께 달라진다고 적는다.

Vercel memory 문서는 메모리 상향이 CPU와 비용에 함께 영향을 준다고 설명한다.

그래서 memory size 상향은 만능 해결책이 아니라 비용과 실행 특성을 함께 바꾸는 선택이다. memory warning이 payload 때문인지, 실제로는 upstream wait 때문에 wall time만 긴 것인지 먼저 분리해야 쓸데없는 상향을 줄일 수 있다.

세 번째 자료는 Observability Insights의 External APIs 탭이다. Vercel은 외부 API 요청 수, p75 latency, error rate로 upstream 병목을 따로 보라고 안내한다.

Vercel Insights 문서는 External APIs 탭에서 외부 API latency와 error rate를 따로 확인할 수 있다고 설명한다.

이 화면을 같이 보지 않으면 메모리 경고가 떠 있는 요청을 전부 메모리 부족으로만 오해할 수 있다. 실제로는 upstream 응답이 늦어 wall time이 길어진 요청일 수 있고, 이 경우 memory를 올려도 병목이 그대로 남는다.

네 번째 자료는 Query Reference의 핵심 메트릭 표다. Peak Memory, Function CPU Time, Function Wall Time, Fast Origin Transfer를 같이 놓고 보면 메모리, CPU, 업스트림 대기를 다른 축에서 볼 수 있다.

Vercel Query Reference는 Peak Memory, Function CPU Time, Function Wall Time 같은 지표를 별도 메트릭으로 제공한다.

운영에서는 이 메트릭 분리가 가장 중요하다. Peak Memory가 높고 CPU Time도 같이 올라가면 payload나 직렬화 비용을 의심할 수 있고, Wall Time만 길고 External API p75가 높으면 upstream wait 쪽으로 더 빨리 좁혀진다.

실제 triage 메모는 간단해야 한다. payload 크기, 응답 시간, 외부 API 대기 시간을 같은 요청 ID 기준으로 남기면 memory warning 해석이 빨라진다.

payload 크기와 외부 API 대기를 같은 요청 ID 기준으로 남기는 로그 예시다.

이 메모를 남겨 두면 메모리 경고가 떴을 때 배포 설정을 바꿀지, 요청 본문을 줄일지, 외부 API를 캐시할지 우선순위가 더 빨리 정해진다. 이미 memory 경고와 function memory size를 같이 보는 글을 읽었다면, 이번 코드는 그다음 분기인 payload 대 upstream wait 분리다.

마지막 자료는 memory warning 분기표다. payload가 큰 경우와 외부 API 대기가 긴 경우를 다른 조치로 묶어 두면 설정 변경을 덜 성급하게 하게 된다.

memory warning을 payload 문제와 external API wait 문제로 나눠 보는 비교표다.

이 표가 있으면 Runtime Logs 경고 한 줄만 보고 메모리를 올리는 습관을 줄일 수 있다. post 59가 timeout 뒤 외부 API와 메모리 압박을 나눴다면, 이번 표는 memory warning 시점에 더 앞단에서 나누는 기준이다.

5. 주의사항과 리스크

첫 번째 리스크는 memory size 상향으로 CPU까지 늘어난 뒤, 실제 병목이 가려져 원인이 더 늦게 드러나는 것이다. 두 번째 리스크는 External APIs 지연을 보지 않고 메모리만 올려서 비용만 증가하는 것이다. 세 번째 리스크는 payload 크기를 기록하지 않아 재현 세션이 끝난 뒤에는 다시 같은 요청을 찾지 못하는 것이다.

운영 전에 적어도 한 개 route에는 request body 크기, upstream 대기 시간, total execution을 RequestId 기준으로 같이 남겨 두는 편이 좋다. 그래야 Runtime Logs 경고를 Query와 Insights로 자연스럽게 이어 붙일 수 있다.

• memory 경고는 Peak Memory와 Wall Time을 같이 본다.
• External APIs 지연 여부를 별도로 확인한다.
• payload와 응답 크기를 RequestId 기준으로 남긴다.

6. 결론

Vercel Runtime Logs에서 memory warning이 보일 때는 memory size를 바로 올리기보다 payload 문제와 external API wait 문제를 먼저 갈라야 한다. Peak Memory, CPU Time, Wall Time, External APIs를 같은 요청 창으로 묶어 보면 어떤 요청이 실제로 메모리 상향 대상인지 더 빨리 보인다.

실제 triage 순서를 한 단계 더 좁히고 싶다면 request body 축소와 streaming 전환 후속 글을 같이 보면 좋다. 이 글이 memory warning을 payload와 wait로 나누는 1차 분기라면, 후속 글은 그다음에 body 축소를 먼저 볼지 streaming 전환을 먼저 볼지까지 운영 순서를 정리한다.

• 먼저 RequestId를 고정한다.
• Peak Memory와 Wall Time을 분리해서 본다.
• 원인이 좁혀진 뒤에만 memory size 상향을 검토한다.

7. 참고 링크

1. https://vercel.com/docs/logs/runtime
2. https://vercel.com/docs/functions/configuring-functions/memory
3. https://vercel.com/docs/observability/insights
4. https://vercel.com/docs/query/reference