[Vercel][운영] Runtime Logs에서 memory 경고가 보일 때 function memory size를 같이 보는 순서

IT 리서치 노트

[Vercel][운영] Runtime Logs에서 memory 경고가 보일 때 function memory size를 같이 보는 순서

Vercel Runtime Logs에서 memory 경고가 보이면 많은 팀이 바로 memory size를 올리거나, 반대로 무조건 timeout 문제로 취급한다. 하지만 2026년 6월 28일 기준 Vercel 공식 문서를 다시 보면, Runtime Logs는 함수가 duration이나 memory allocation 상한에 가까워졌는지 보여 주고, memory 문서는 Deployments와 Observability에서 현재 function memory size를 확인하는 경로를 제공한다. 이 글은 경고를 봤을 때 어떤 순서로 해석해야 쓸데없는 비용 상향을 줄일 수 있는지 정리한 것이다.

목차

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

1. 개요

결론부터 말하면 Runtime Logs의 memory 경고는 로그 문장 하나만 보고 끝내지 말고, 현재 function memory size와 요청 성격을 같이 본다. memory 경고가 있더라도 원인은 큰 응답 버퍼나 이미지 처리일 수 있고, 경고가 없는데도 duration이 긴 외부 API 대기일 수 있다. 그래서 Logs의 request 정보와 Observability의 function memory size를 함께 읽어야 다음 액션이 빨라진다.

이미 Runtime Logs에서 외부 API 대기와 메모리 압박을 나누는 글이 증상 분기를 다뤘다면, 이번 글은 실제 memory 경고가 보였을 때 dashboard에서 무엇을 확인할지에 더 가깝다. 또 Fluid Compute duration과 memory 글을 같이 보면 비용 판단도 훨씬 구체적으로 붙는다.

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

실무에서 자주 생기는 혼선은 세 가지다. 첫째, Runtime Logs에 memory 경고가 보여도 현재 function이 어떤 memory profile인지 모른다. 둘째, memory 경고를 보고 곧바로 상향했는데 실제로는 외부 API 대기가 길었던 경우가 있다. 셋째, timeout과 memory 경고가 같이 보여도 어느 route, 어느 deployment, 어느 함수 타입에서 반복되는지 로그를 묶지 않아 판단 기준이 섞인다.

Vercel changelog는 로그가 최대 duration과 memory allocation 근접 여부를 보여 준다고 설명한다. Runtime Logs 문서는 request별 기본 필드와 grouping, filtering 경로를 제공한다. memory 문서는 Deployments와 Resources, Observability에서 현재 function memory size를 확인하는 방법을 적고 있다. 즉 경고 해석은 Logs와 Resources를 함께 보는 작업이다.

또 memory 문서는 memory size가 CPU와도 묶여 있고, Fluid Compute에서는 Active CPU와 Provisioned Memory가 함께 과금 축이 된다고 설명한다. 그래서 memory 상향은 성능 개선이 될 수 있지만, 요청 패턴이 그대로면 비용만 늘 수도 있다. 경고를 봤을 때는 먼저 실제 병목이 메모리인지, duration인지, 외부 I/O인지 나눠야 한다.

• 증상: Runtime Logs에 memory 경고가 반복된다.
• 실패: 현재 function memory size를 확인하지 않고 바로 상향한다.
• 막힘: warning이 난 request의 path, deployment, status를 같이 기록하지 않는다.
• 누락: memory 경고와 duration 경고를 같은 원인으로 취급한다.

증상	먼저 볼 곳	판단 기준
memory 경고가 보인다	function memory size	현재 profile이 무엇인지부터 본다
504도 같이 난다	duration 경고와 upstream 로그	memory와 timeout 중 어느 쪽이 먼저인지 본다
특정 route에서만 반복된다	RequestId, path, deployment	route 특성에 맞는 코드 병목을 본다

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

점검은 다섯 단계가 실용적이다. 먼저 Logs에서 경고가 난 request의 path, RequestId, status, deployment를 적는다. 다음으로 Deployments와 Resources에서 해당 function을 찾고 Observability에서 현재 memory size를 확인한다. 세 번째로 request가 큰 JSON 집계, 이미지 처리, 파일 변환, 대형 SSR 렌더인지 확인한다. 네 번째로 duration 경고가 함께 있는지 본다. 마지막으로 그다음에만 코드 수정, 스트리밍, 캐시, memory 상향 중 무엇이 맞는지 결정한다.

1. Logs에서 request 정보와 warning 종류를 기록한다.
2. Observability에서 현재 function memory size를 확인한다.
3. route가 큰 객체나 버퍼를 다루는지 본다.
4. duration warning과 함께 보이는지 확인한다.
5. 그다음에만 코드 수정 또는 memory 상향을 결정한다.

이 순서를 따르면 memory 상향이 실제로 도움이 되는 경우와, 단지 더 비싼 profile에서 같은 코드를 돌리는 경우를 더 빨리 나눌 수 있다. 예를 들어 이미지 리사이즈나 PDF 생성처럼 순간 메모리 사용이 큰 작업은 상향이 맞을 수 있지만, 외부 API 대기나 느린 DB 조회는 memory를 올려도 핵심 병목이 남는다.

점검 메모 예시

request_id=req_741
path=/api/render-report
warning=near maximum memory allocation
function_memory_size=2 GB / 1 vCPU
payload_kind=image_render
duration_warning=false
next_action=stream_output_and_review_memory_upgrade

또 memory size 변경은 새 배포 이후에 반영된다는 점도 기억해야 한다. 경고를 보고 설정을 바꿨다면, 다음 배포에서 동일 route의 경고 패턴이 어떻게 달라졌는지 다시 비교해야 한다.

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

첫 화면은 Vercel changelog다. 여기서는 Runtime Logs가 함수가 duration이나 memory 상한에 도달했거나 근접했는지 보여 준다고 적고 있다.

Vercel은 Runtime Logs에서 함수가 duration 또는 memory allocation 상한에 도달했는지 표시한다고 공지했다.

즉 timeout이 났을 때와 memory 경고가 떴을 때는 같은 로그 화면을 봐도 해석 순서가 달라진다. 경고가 보인다면 maxDuration만 올리기 전에 memory size와 실제 요청 특성을 같이 봐야 한다.

두 번째 자료는 Runtime Logs 문서다. Vercel은 각 로그 행에 request 기본 정보가 있고, 필터와 grouping으로 같은 요청을 묶어 볼 수 있다고 설명한다.

Runtime Logs 문서는 request, status, function type, RequestId 같은 필드를 기준으로 요청을 묶어 보라고 안내한다.

memory 경고를 읽을 때도 이 기본 필드가 중요하다. 어느 route에서, 어느 deployment에서, 어떤 요청 패턴에서 경고가 반복되는지부터 봐야 메모리 상향과 코드 수정 중 어느 쪽이 맞는지 가른다.

세 번째 화면은 memory 문서의 확인 경로다. Vercel은 Deployments에서 Resources를 열고 Observability 쪽에서 함수 memory size를 확인하는 순서를 제공한다.

Vercel 문서는 Deployments와 Resources, Observability에서 함수 memory size를 확인하는 경로를 설명한다.

이 경로를 모르면 Runtime Logs에 memory 경고가 떠도 현재 함수가 2GB 기본값인지, 더 높은 memory profile인지 확인이 늦어진다. warning 해석은 현재 할당값을 알아야 시작된다.

실제 운영에서는 warning 패턴을 한 줄 메모처럼 남겨 두는 편이 좋다. duration 병목과 memory 병목은 로그 문장과 다음 액션이 다르기 때문이다.

duration 경고와 memory 경고를 나눠 기록한 로그 예시다.

이미 외부 API 대기와 메모리 압박을 나누는 글을 읽었다면, 이번 글은 그 분기에서 memory 경고가 실제로 떴을 때 확인 경로를 더 좁힌 단계다.

memory 경고가 떴다고 무조건 memory를 올리면 비용만 늘 수 있다. 반대로 실제로 메모리 여유가 부족한데도 외부 API 대기로만 보면 튜닝이 늦어진다.

memory 경고를 본 뒤 무엇을 먼저 고칠지 정리한 표다.

이 표를 기준으로 보면 로그에 memory 경고가 있어도 실제 원인은 큰 객체 생성, 이미지 처리, JSON 집계, 스트리밍 버퍼일 수 있고, 경고가 없어도 duration만 긴 외부 API 대기일 수 있다. FUNCTION_INVOCATION_TIMEOUT 기본 글과 같이 보면 어디서 분기가 생기는지 더 잘 보인다.

마지막 자료는 대시보드 확인 순서다. 팀에 이 순서를 남겨 두면 '로그에서 경고를 봤는데 어디서 memory size를 확인하지'라는 시간을 줄일 수 있다.

Runtime Logs 경고 뒤에 function memory size를 확인하는 순서다.

또 Fluid Compute에서 duration과 memory를 같이 보는 글을 같이 보면 memory 상향이 cost와 CPU 모두에 어떤 영향을 주는지도 연결해서 판단할 수 있다.

5. 주의사항과 리스크

첫 번째 리스크는 memory 경고 하나만 보고 profile을 올려 비용을 키우는 것이다. 두 번째 리스크는 실제로는 duration 병목인데 memory 상향으로 해결하려는 것이다. 세 번째 리스크는 warning이 어느 deployment에서 발생했는지 기록하지 않아 설정 변경 전후를 비교하지 못하는 것이다.

운영 전에는 warning 종류, function memory size, route 성격, next action을 같은 메모에 남기는 편이 좋다. 그래야 이후 재발 때도 같은 기준으로 볼 수 있다.

• memory 경고는 현재 function memory size와 함께 봐야 한다.
• duration warning과 함께 있는지 항상 확인한다.
• 설정 변경 뒤에는 새 배포 기준으로 재비교한다.

6. 결론

Vercel Runtime Logs의 memory 경고는 단순한 경고 문구가 아니라 다음 확인 경로를 정해 주는 신호다. Logs의 request 정보와 Observability의 function memory size를 같이 읽으면, memory 상향이 필요한지 아니면 코드 구조를 먼저 줄여야 하는지 훨씬 빠르게 판단할 수 있다.

다만 memory size를 확인한 뒤에도 원인이 애매하면, 다음 단계로는 payload 크기와 외부 API 대기를 먼저 나누는 후속 글을 붙여 보는 편이 안전하다. 이번 글이 경고 해석의 입구라면, 후속 글은 로그에서 payload 계열과 upstream wait 계열을 갈라 memory 상향 전 액션을 정리한다.

• warning 종류와 request 정보를 먼저 기록한다.
• Observability에서 current memory size를 확인한다.
• 그다음에만 memory 상향 여부를 결정한다.

7. 참고 링크

1. https://vercel.com/changelog/improved-log-visibility-for-function-durations-and-memory
2. https://vercel.com/docs/logs/runtime
3. https://vercel.com/docs/functions/logs
4. https://vercel.com/docs/functions/configuring-functions/memory
5. https://vercel.com/docs/functions/configuring-functions/duration