diff --git a/pages/docs/pages/building-your-application/rendering/automatic-static-optimization.mdx b/pages/docs/pages/building-your-application/rendering/automatic-static-optimization.mdx
index c569f30..113606b 100644
--- a/pages/docs/pages/building-your-application/rendering/automatic-static-optimization.mdx
+++ b/pages/docs/pages/building-your-application/rendering/automatic-static-optimization.mdx
@@ -3,43 +3,41 @@ title: Automatic Static Optimization
 description: Next.js automatically optimizes your app to be static HTML whenever possible. Learn how it works here.
 ---
 
-{/* TODO: 번역이 필요합니다. */}
-
 # Automatic Static Optimization
 
-Next.js automatically determines that a page is static (can be prerendered) if it has no blocking data requirements. This determination is made by the absence of `getServerSideProps` and `getInitialProps` in the page.
+Next.js는 페이지가 렌더링될 때 반드시 필요한 데이터가 없다면 해당 페이지가 정적(미리 렌더링 가능한 상태)임을 자동으로 결정합니다. 이 결정은 페이지에 `getServerSideProps`와 `getInitialProps`가 없는 경우에 이루어집니다.
 
-This feature allows Next.js to emit hybrid applications that contain **both server-rendered and statically generated pages**.
+이 기능을 통해 Next.js는 **서버 렌더링 페이지와 정적 생성 페이지를 모두 포함하는 하이브리드 애플리케이션**을 생성할 수 있습니다.
 
-> Statically generated pages are still reactive: Next.js will hydrate your application client-side to give it full interactivity.
+> 정적으로 생성된 페이지도 여전히 반응형입니다: Next.js는 클라이언트 측에서 애플리케이션을 hydrate하여 완전한 상호작용성을 제공합니다.
 
-One of the main benefits of this feature is that optimized pages require no server-side computation, and can be instantly streamed to the end-user from multiple CDN locations. The result is an _ultra fast_ loading experience for your users.
+이 기능의 주요 이점 중 하나는 최적화된 페이지가 서버 측 계산을 필요로 하지 않으며, 여러 CDN 위치에서 최종 사용자에게 즉시 스트리밍될 수 있다는 점입니다. 그 결과 사용자에게 _초고속_ 로딩 경험을 제공할 수 있습니다.
 
 ## How it works
 
-If `getServerSideProps` or `getInitialProps` is present in a page, Next.js will switch to render the page on-demand, per-request (meaning [Server-Side Rendering](/docs/pages/building-your-application/rendering/server-side-rendering)).
+만약 페이지에 `getServerSideProps` 또는 `getInitialProps`가 포함되어 있으면, Next.js는 해당 페이지를 요청이 있을 때마다 즉시 렌더링하도록 전환합니다.([Server-Side Rendering](/docs/pages/building-your-application/rendering/server-side-rendering)을 의미합니다.)
 
-If the above is not the case, Next.js will **statically optimize** your page automatically by prerendering the page to static HTML.
+위의 경우가 아니라면, Next.js는 페이지를 정적 HTML로 사전 렌더링하여 자동으로 **정적 최적화**를 수행합니다.
 
-During prerendering, the router's `query` object will be empty since we do not have `query` information to provide during this phase. After hydration, Next.js will trigger an update to your application to provide the route parameters in the `query` object.
+사전 렌더링 중에는 이 단계에서 제공할 `query` 정보가 없기 때문에 라우터의 `query` 객체가 비어있게 됩니다. hydration 이후, Next.js는 애플리케이션 업데이트를 트리거하여 `query` 객체에 라우트 매개변수를 제공합니다.
 
-The cases where the query will be updated after hydration triggering another render are:
+hydration 이후 query가 업데이트되어 다른 렌더링을 트리거하는 경우는 다음과 같습니다:
 
-- The page is a [dynamic-route](/docs/pages/building-your-application/routing/dynamic-routes).
-- The page has query values in the URL.
-- [Rewrites](/docs/pages/api-reference/next-config-js/rewrites) are configured in your `next.config.js` since these can have parameters that may need to be parsed and provided in the `query`.
+- 페이지가 [dynamic-route](/docs/pages/building-your-application/routing/dynamic-routes)인 경우.
+- URL에 query 값이 있는 경우.
+- `next.config.js`에 [Rewrites](/docs/pages/api-reference/next-config-js/rewrites)가 구성된 경우, `query`에서 파싱되어 제공되어야 할 매개변수를 가질 수 있기 때문입니다.
 
-To be able to distinguish if the query is fully updated and ready for use, you can leverage the `isReady` field on [`next/router`](/docs/pages/api-reference/functions/use-router#router-object).
+query가 완전히 업데이트되고 사용할 준비가 되었는지 확인하려면 [`next/router`](/docs/pages/api-reference/functions/use-router#router-object)의 `isReady` 필드를 활용할 수 있습니다.
 
-> **Good to know**: Parameters added with [dynamic routes](/docs/pages/building-your-application/routing/dynamic-routes) to a page that's using [`getStaticProps`](/docs/pages/building-your-application/data-fetching/get-static-props) will always be available inside the `query` object.
+> **알아두면 좋은 점**: [`getStaticProps`](/docs/pages/building-your-application/data-fetching/get-static-props)를 사용하는 페이지에 [dynamic routes](/docs/pages/building-your-application/routing/dynamic-routes)로 추가된 매개변수는 항상 query 객체 내에서 사용할 수 있습니다.
 
-`next build` will emit `.html` files for statically optimized pages. For example, the result for the page `pages/about.js` would be:
+`next build`는 정적으로 최적화된 페이지에 대해 `.html` 파일을 생성합니다. 예를 들어, `pages/about.js` 페이지의 결과는 다음과 같습니다:
 
 ```bash filename="Terminal"
 .next/server/pages/about.html
 ```
 
-And if you add `getServerSideProps` to the page, it will then be JavaScript, like so:
+그리고 페이지에 `getServerSideProps`를 추가하게 되면, 다음과 같이 JavaScript로 생성됩니다:
 
 ```bash filename="Terminal"
 .next/server/pages/about.js
@@ -47,6 +45,6 @@ And if you add `getServerSideProps` to the page, it will then be JavaScript, lik
 
 ## Caveats
 
-- If you have a [custom `App`](/docs/pages/building-your-application/routing/custom-app) with `getInitialProps` then this optimization will be turned off in pages without [Static Generation](/docs/pages/building-your-application/data-fetching/get-static-props).
-- If you have a [custom `Document`](/docs/pages/building-your-application/routing/custom-document) with `getInitialProps` be sure you check if `ctx.req` is defined before assuming the page is server-side rendered. `ctx.req` will be `undefined` for pages that are prerendered.
-- Avoid using the `asPath` value on [`next/router`](/docs/pages/api-reference/functions/use-router#router-object) in the rendering tree until the router's `isReady` field is `true`. Statically optimized pages only know `asPath` on the client and not the server, so using it as a prop may lead to mismatch errors. The [`active-class-name` example](https://github.com/vercel/next.js/tree/canary/examples/active-class-name) demonstrates one way to use `asPath` as a prop.
+- 만약 `getInitialProps`가 있는 [custom `App`](/docs/pages/building-your-application/routing/custom-app)이 있는 경우, [Static Generation](/docs/pages/building-your-application/data-fetching/get-static-props)이 없는 페이지에서는 이 최적화가 비활성화됩니다.
+- 만약 `getInitialProps`가 있는 [custom `Document`](/docs/pages/building-your-application/routing/custom-document)를 사용하고 있다면, 페이지가 서버 사이드 렌더링인지 확인하기 위해 `ctx.req`가 정의되어 있는지 확인 해야 합니다. 사전 렌더링된 페이지의 경우 `ctx.req`는 `undefined`로 나타납니다.
+- 라우터의 `isReady` 필드가 `true`가 될 때까지 렌더링 트리에서 [`next/router`](/docs/pages/api-reference/functions/use-router#router-object)의 `asPath` 값 사용을 피해야 합니다. 정적으로 최적화된 페이지는 서버가 아닌 클라이언트에서만 `asPath`를 알기 때문에, 이를 prop으로 사용하면 불일치 오류가 발생할 수 있습니다. [`active-class-name` example](https://github.com/vercel/next.js/tree/canary/examples/active-class-name) 예제는 `asPath`를 prop으로 사용하는 한 가지 방법을 보여줍니다.