diff --git a/public/images/nextjs-image-optimization/process.avif b/public/images/nextjs-image-optimization/process.avif
new file mode 100644
index 0000000..1a4c73d
Binary files /dev/null and b/public/images/nextjs-image-optimization/process.avif differ
diff --git a/src/content/post/blog/nextjs-image-optimization.mdx b/src/content/post/blog/nextjs-image-optimization.mdx
index 420d7a1..89f7ad1 100644
--- a/src/content/post/blog/nextjs-image-optimization.mdx
+++ b/src/content/post/blog/nextjs-image-optimization.mdx
@@ -172,13 +172,6 @@ export default function Page() {
 네트워크 탭을 살펴보면 기본 `img` 태그의 요청은 원본 PNG 이미지(794 KB)를 그대로 전송하고 `next/image` 컴포넌트의 요청은 WebP 형식(45.7 KB)으로 **최적화되어 전송**되는 것을 확인할 수 있다.
 `next/image`의 두 번째 요청부터는 **캐시에서 즉시 응답**한다.
 
-최적화 과정을 다시 한번 요약해 보자면 다음과 같다.
-
-1. 클라이언트가 `/_next/image?url=...` 경로로 요청을 보냄
-1. 서버가 Sharp(또는 Squoosh)를 사용해 리사이징 및 포맷 변환 수행
-1. 변환된 이미지를 `/.next/cache/images/`에 저장 (같은 요청이 오면 캐싱된 파일 반환)
-1. 최적화된 이미지가 브라우저로 전달됨
-
 이처럼 **요청 시점(런타임)에 최적화**하기 때문에 디바이스나 브라우저 등 **클라이언트의 상황에 맞춰 최적화**가 가능하다.
 최적화된 이미지는 **캐시에 저장**되어 같은 요청이 왔을 때 최적화 과정 없이 바로 응답한다.
 
@@ -208,6 +201,10 @@ const nextConfig = {
 - `STALE`: 캐시는 있지만 유효 기간이 만료된 경우
 - `HIT`: 유효한 캐시가 있는 경우
 
+최적화 과정을 다시 한번 요약해 보자면 다음과 같다.
+
+![캐시 상태에 따른 최적화 과정](/images/nextjs-image-optimization/process.avif)
+
 ## 빌드 타임 최적화
 
 런타임에 이미지 최적화가 진행되지만, 빌드 시점(또는 개발 환경의 컴파일 시점)에 미리 준비할 수도 있다.