바꾸려는 동작
이미지 최적화 메모리에서 바꿀 결과와 유지할 기존 동작을 한 문장씩 적습니다. 큰 source image와 높은 동시 변환은 decoder·encoder memory를 늘리므로 허용 dimension, format, cache와 concurrency를 제한해야 합니다.
핵심 원리
메모리 문제는 한 시점의 사용률이 아니라 시간에 따른 할당률, 작업 종료 뒤 기준선과 참조 경로를 봐야 합니다. heap과 native·buffer·파일 캐시를 분리하면 제한을 늘려야 하는지, 참조를 끊어야 하는지가 달라집니다. 현재 version의 공식 문서와 실제 설정을 확인하고 대표·경계·실패 사례를 준비합니다. 빌드 route 분류, 서버 로그, 응답 Cache-Control, RSC 요청과 데이터 쿼리 수를 구분해 본다.
| 순서 | 할 일 |
|---|---|
| 1 | 수정 전 결과와 되돌릴 기준 저장 |
| 2 | 핵심 사실과 맞닿은 한 곳만 변경 |
| 3 | 같은 입력으로 수정 전후 비교 |
단계별 적용 예시
반복 횟수, 컬렉션, queue와 cache에 상한을 두고 상태를 만든 소유자가 listener·timer·handle까지 정리하게 합니다. 메모리 제한 상향은 원인 수정 뒤의 안전 여유로만 사용합니다. Server와 Client 경계를 좁히고 데이터 변경 계약에 맞춰 캐시 태그, 재검증과 동적 렌더링을 명시한다. 예상과 다르면 변경을 더 얹지 말고 처음 달라진 값으로 돌아갑니다. 프로덕션 빌드에서 정적·동적 route, 번들 크기, TTFB, 캐시 적중과 관리자 변경 직후 일관성을 확인한다. 동일 부하를 충분히 오래 유지한 뒤 GC 이후 live set과 RSS 기준선, allocation rate, 처리량과 pause가 함께 안정되는지 확인합니다.
공식 문서와 적용 범위
문서의 기본값과 동작은 version에 따라 달라질 수 있습니다. 현재 runtime·framework version, 실제 입력과 요청 흐름에서 다시 확인합니다.