D-9: 배포 & 최적화 ① — 늦게 도착하는 것들

안녕하세요, 홍순구입니다. 지난 시간 마지막에 제가 이런 말을 했었죠, 우리 피드에는 사진이 없다고요.

인스타그램인데요.

지금 브라우저에서 피드를 열어보세요. @jaehoon, "오늘 한강 노을이 미쳤다", 하트, 좋아요 1240인데, 글자만 있고 노을은 어디에도 없습니다.

데이터에는 처음부터 있었는데, Post 타입을 열어보면 imageUrl이 아홉 번째 줄쯤에 얌전히 앉아 있어요. C-6에서 그 타입을 만들 때부터 있었고, 우리가 화면에 안 붙였을 뿐입니다.

오늘 붙이는데, 그냥 붙이면 이상한 일이 생겨서 사진이 한 장씩 도착할 때마다 아래에 있던 글이 아래로 밀리면서 읽고 있던 문장이 손가락 밑에서 도망가요. 그 밀림을 재보고 없애는데, 사진만 늦게 오는 게 아니라 글꼴도 늦게 오고 제목은 아예 안 바뀌는 것까지 하나 더 있어요.

💡 오늘 수업의 핵심 — "늦게 올 것의 자리를 미리 잡아둡니다"

브라우저는 정직해서 사진이 몇 대 몇인지 모르면 자리를 못 비우는데, 안 비우고 있다가 사진이 도착하는 순간 그만큼을 밀어냅니다.

그렇게 밀어내는 걸 막으려면 사진을 빨리 받는 게 아니라 얼마나 클지 미리 알려주는 것이 해법인데, 오늘 배우는 도구들이 전부 이 한 문장 위에 서 있어요. next/image도, next/font도요.

그리고 오늘 한 번 이상한 걸 만나게 됩니다. 개발 서버에서는 요란하게 터지는데 진짜로 빌드해서 띄우면 아무 일도 없는 것처럼 보이는 자리요. 200이라고 다 정상이 아니라는 걸 D-4에서 한 번 봤었는데, 오늘 다른 얼굴로 다시 만납니다.

🎯 학습 목표

• 사진이 늦게 도착할 때 아래 글이 얼마나 밀리는지 직접 재고, next/image로 0으로 만듭니다.
• remotePatterns로 사진을 가져올 곳을 허락하고, 서버가 사진을 어떻게 다시 만들어 주는지 크기로 확인합니다.
• 어느 사진을 먼저 받을지 정하고, 그 자리에서 폐기된 옛 이름과 현행 이름을 가릅니다.
• next/font와 Metadata API로 글꼴과 제목을 각 화면에 맞게 붙입니다.

 오늘의 여정

 1. 인스타그램인데 사진이 없습니다   그냥 <img> 로 붙인다 -- 4,233px 밀린다
 2. 자리를 미리 잡아둡니다           next/image 와 width/height -- 0px
 3. 그런데 사진이 안 나옵니다         개발과 프로덕션이 반대로 움직인다
 4. 허락한 곳에서만 가져옵니다        remotePatterns -- 74KB 가 27KB 로
 5. 어느 사진을 먼저 받을까요         Next 가 직접 알려주는 경고
 6. 글꼴도 늦게 옵니다               next/font -- 조각 125개와 대역 배우
 7. 어느 화면에 가 있든 제목이 같습니다 generateMetadata
 8. 남이 우리 링크를 볼 때           og 태그

Step 1: "인스타그램인데 사진이 없습니다"

먼저 데이터부터 확인하고 가는데, 우리가 안 그린 건지 데이터에 없는 건지부터 봐요.

// apps/web-next/lib/posts.ts
export interface Post {
  id: number;
  username: string;
  profileImageUrl: string;
  imageUrl: string;
  mediaKind: 'image' | 'carousel' | 'video';
  content: string;
  hashtagNames: string[];
  likeCount: number;
  commentCount: number;
  liked: boolean;
  createdAt: string;
}

imageUrl도 profileImageUrl도 있어서 서버는 계속 사진 주소를 보내주고 있었는데, 우리가 안 쓴 겁니다.

붙여봅시다

FeedList를 열어서 사용자 이름과 본문 사이에 한 줄을 넣습니다.

// apps/web-next/app/components/FeedList.tsx
import { LikeButton } from './LikeButton';
import { fetchPosts } from '@/lib/api';

// 지시어가 없다. 그러니 서버 컴포넌트다.
// 서버에서 도니까 함수 안에서 그냥 기다렸다 받으면 된다 — 훅도, 상태도 없다.
export async function FeedList() {
  const posts = await fetchPosts();

  return (
    <ul className="space-y-4">
      {posts.map((post) => (
        <li key={post.id} className="rounded border border-black/10 p-4">
          <p className="font-semibold">@{post.username}</p>
          {/* 데이터에는 처음부터 있었다. 화면에 붙이는 건 지금이 처음이다. */}
          <img src={post.imageUrl} alt={post.content} />
          <p className="mt-1">{post.content}</p>
          <LikeButton postId={post.id} likeCount={post.likeCount} liked={post.liked} />
        </li>
      ))}
    </ul>
  );
}

새로고침하면 사진이 나오는데, 한강 노을도 제주도도요.

새로고침을 한 번 더 해보면, 이번엔 스크롤을 조금 내린 채로 읽으려던 문장이 아래로 도망가요.

얼마나 밀리는지 재봅시다

느낌으로 말하면 안 되니까 숫자로 봅시다. 화면 폭 1853, 게시물 카드 안쪽 폭이 494픽셀인 창에서 잰 값입니다.

열 번째 게시물이 4,233픽셀 아래로 밀려납니다. 화면 네 개 반쯤 되는 거리예요.

24픽셀은 사진이 아직 없을 때 그 자리에 있던 것인데, alt 글자 한 줄의 높이라서 브라우저 입장에서는 그게 전부였어요.

왜 밀릴까요

브라우저가 HTML을 읽는 순서를 생각해봅시다.

 1) HTML 을 읽는다        <img src="https://picsum.photos/...">
                          → 주소만 있다. 크기는 안 적혀 있다

 2) 자리를 잡는다          "얼마나 클지 모르겠는데... 일단 0 으로 두자"
                          → 아래 글이 위로 바짝 붙는다

 3) 사진이 도착한다        640 x 640 이었구나
                          → 494px 을 확보해야 한다
                          → 아래 있던 것들을 전부 494px 만큼 밀어낸다

문제는 2번과 3번 사이인데, 그 사이에 학생이 글을 읽고 있고 링크를 누르려고 손가락을 대고 있어요.

이게 웹 성능 지표 중 CLS(Cumulative Layout Shift, 누적 레이아웃 이동)로 측정되는 항목인데, 얼마나 빨리 그렸느냐가 아니라 얼마나 안 흔들렸느냐를 재는 지표예요.

사실 도구가 미리 말해줬습니다

터미널에서 린트를 한 번 돌려보세요.

npx eslint

app/components/FeedList.tsx
  16:11  warning  Using `<img>` could result in slower LCP and higher bandwidth.
                  Consider using `<Image />` from `next/image` ...
                  @next/next/no-img-element

✖ 1 problem (0 errors, 1 warning)

error가 아니라 warning인데, 종료 코드는 0이라 빌드도 통과해요. 아무도 우리를 막지 않고, 그냥 알려만 줍니다.

💡 한 줄 정리

폭과 높이를 안 알려준 사진은 도착하는 순간 아래 있는 모든 것을 밀어낸다. 우리 피드에서는 열 번째 게시물이 4,233픽셀 내려갔다.

Step 2: "자리를 미리 잡아둡니다"

Next에는 <img> 대신 쓰는 컴포넌트가 있습니다. next/image의 Image예요.

이름만 보면 그냥 감싼 것 같은데, 하는 일이 꽤 많습니다. 오늘 그 일들을 하나씩 만나게 될 텐데, 첫 번째가 지금 우리 문제입니다.

// apps/web-next/app/components/FeedList.tsx
import Image from 'next/image';
import { LikeButton } from './LikeButton';
import { fetchPosts } from '@/lib/api';

// 지시어가 없다. 그러니 서버 컴포넌트다.
// 서버에서 도니까 함수 안에서 그냥 기다렸다 받으면 된다 — 훅도, 상태도 없다.
export async function FeedList() {
  const posts = await fetchPosts();

  return (
    <ul className="space-y-4">
      {posts.map((post) => (
        <li key={post.id} className="rounded border border-black/10 p-4">
          <p className="font-semibold">@{post.username}</p>
          {/* 원본이 몇 대 몇인지 알려준다. 그러면 사진이 오기 전에도 그 비율만큼 자리가 비워진다.
              화면 폭에 맞춰 줄어드는 건 className 이 맡는다. */}
          <Image
            src={post.imageUrl}
            alt={post.content}
            width={640}
            height={640}
            className="h-auto w-full"
          />
          <p className="mt-1">{post.content}</p>
          <LikeButton postId={post.id} likeCount={post.likeCount} liked={post.liked} />
        </li>
      ))}
    </ul>
  );
}

width와 height는 "화면에 이만큼 그려라"가 아닙니다. "원본이 이 비율이다"라고 알려주는 값이에요. 실제 표시 크기는 className의 w-full이 정합니다. 폭은 컨테이너를 꽉 채우고, 높이는 h-auto로 비율을 따라가요.

alt는 필수입니다. 안 적으면 타입이 통과 안 돼요. 화면을 못 보는 사람에게 이 사진이 무엇인지 읽어주는 글자니까, 컴포넌트가 아예 강제합니다.

다시 재봅시다

같은 창, 같은 방법으로 잰 값입니다.

사진이 도착하기 전에 이미 494픽셀입니다. 도착해도 자리가 안 바뀌니 밀 것이 없어요.

브라우저가 받은 결과물

Next가 우리 <Image>를 무엇으로 바꿔서 내보냈는지 소스 보기로 확인해봅시다.

<img alt="오늘 한강 노을이 미쳤다" loading="lazy" width="640" height="640"
     decoding="async" data-nimg="1" class="h-auto w-full"
     style="color:transparent"
     srcSet="/_next/image?url=...&amp;w=640&amp;q=75 1x,
             /_next/image?url=...&amp;w=1920&amp;q=75 2x"
     src="/_next/image?url=...&amp;w=1920&amp;q=75" />

결국 평범한 <img>입니다. 다만 세 가지가 붙었어요.

• width="640" height="640" — 이게 자리를 잡습니다. 현대 브라우저는 이 두 값에서 비율을 계산해 미리 공간을 비워둬요.
• loading="lazy" — 화면에 가까워질 때까지 안 받습니다. 열 장을 한꺼번에 받지 않아요.
• srcSet과 src — 주소가 picsum.photos가 아니라 /_next/image?url=...로 바뀌었습니다. 우리 서버를 거쳐서 옵니다.

마지막 게 오늘의 다음 이야기예요. 사진을 원본 그대로 안 주고 우리 서버가 손을 대려면 허락이 필요하거든요.

💡 한 줄 정리

width/height는 표시 크기가 아니라 원본 비율이다. 그 비율만 알면 브라우저가 사진이 오기 전에 자리를 비워두고, 밀림은 0이 된다.

Step 3: "그런데 사진이 안 나옵니다"

여기서 좀 이상한 일이 생깁니다. 코드는 방금 그대로인데, 개발 서버에서 피드를 열면 이렇게 나옵니다.

피드를 불러오는 중…

그대로 멈춰 있어서, 사진은커녕 글자도 안 나옵니다. 그런데 응답 상태는 200이에요.

터미널을 보면 이유가 적혀 있습니다.

⨯ Error: Invalid src prop (https://picsum.photos/seed/post1/640/640) on `next/image`,
  hostname "picsum.photos" is not configured under images in your `next.config.js`

우리 서버가 아무 주소의 사진이나 받아다 다시 만들어주지 않는다는 뜻인데, 이유는 Step 4에서 볼게요. 지금 볼 것은 이 사실이 어디에서 드러나느냐입니다.

빌드는 통과합니다

같은 코드로 프로덕션 빌드를 돌려봅시다.

rm -rf .next
npx next build

✓ Compiled successfully in 1782ms
  Finished TypeScript in 955ms ...
✓ Generating static pages using 8 workers (7/7) in 371ms

Route (app)
┌ ◐ /
├ ◐ /_not-found
├   /[username]
│ └ ◐ /[username]
├ ƒ /api/profiles/revalidate
└ ◐ /explore

종료 코드 0이고, 라우트 표도 D-6 때와 똑같아서 아무 일도 없었던 것처럼 보입니다.

띄워보면 더 이상합니다

npx next start

피드가 정상으로 그려집니다. 개발 서버에서는 멈춰 있던 그 화면인데, 소스를 보면 <img> 태그도 멀쩡히 있고 srcSet도 src도 다 있어요.

그런데 화면에는 사진 자리만 비어 있는데, 자리는 494픽셀로 잡혀 있고 그 안이 하얗습니다.

그 src 주소를 직접 불러보면 답이 나옵니다.

curl -i 'http://localhost:3000/_next/image?url=https%3A%2F%2Fpicsum.photos%2Fseed%2Fpost1%2F640%2F640&w=640&q=75'

HTTP/1.1 400 Bad Request

"url" parameter is not allowed

정리하면 이렇습니다.

개발에서는 요란하게 터지고, 프로덕션에서는 조용히 사진만 안 나옵니다.

보통은 반대로 생각하죠, 개발은 관대하고 프로덕션이 엄격하다고요. 여기서는 뒤집혀 있는데, 개발 서버가 렌더 도중에 예외를 던져 화면을 세워버리는 반면 프로덕션은 HTML을 정상으로 다 내보내고 사진 바이트를 요청하는 순간에만 거절해요.

D-4에서 비슷한 걸 한 번 봤습니다. loading.tsx 하나 때문에 없는 사람의 프로필이 404 대신 200으로 나왔었죠. 그때 배운 문장이 오늘도 그대로입니다. 200은 "요청이 도착했다"는 뜻이지 "잘 됐다"는 뜻이 아닙니다.

💡 한 줄 정리

허락 안 된 주소의 사진은 빌드도, 페이지도, HTML도 전부 통과한다. 400이 나는 것은 사진 바이트 하나뿐이라 프로덕션에서는 조용히 빈 자리만 남는다.

Step 4: "허락한 곳에서만 가져옵니다"

이제 고칩니다. next.config.ts에 목록을 하나 만들어요.

// apps/web-next/next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  typedRoutes: true,
  // 굳힐 것과 흘려보낼 것을 우리가 직접 고르겠다고 선언하는 스위치.
  cacheComponents: true,
  images: {
    // 여기 적힌 주소에서 온 사진만 다시 만들어 준다. 나머지는 400 으로 거절한다.
    remotePatterns: [new URL('https://picsum.photos/seed/**')],
  },
};

export default nextConfig;

한 줄만 넣으면 새로고침 후 사진이 나옵니다.

왜 허락이 필요할까요

/_next/image?url=...은 주소를 받아서 그 사진을 가져다 다시 만들어주는 통로입니다. 목록이 없으면 누구든 우리 서버에 아무 주소나 넣어서 시킬 수 있는데, 남의 서버에 있는 100MB 짜리 사진을 우리 CPU로 백 번 변환시키는 것도 가능하고요.

D-8에서 문지기를 세우면서 배운 것과 같은 결입니다. 그때는 "이 사람이 들어와도 되나" 였고, 지금은 "이 주소에서 가져와도 되나"인데, 열려 있는 통로는 반드시 목록으로 좁힙니다.

/seed/**에서 **는 그 아래 몇 겹이든 허용한다는 뜻입니다. picsum.photos의 다른 경로는 안 되고, http://도 안 됩니다. 프로토콜·호스트·경로를 다 봐요.

⚠️ 예전 자료에서 images.domains를 보실 수 있는데, 그건 폐기된 설정입니다. 호스트 이름만 적는 방식이라 경로도 프로토콜도 포트도 못 가렸어요. 지금은 remotePatterns만 씁니다.

우리 서버가 사진에 무슨 짓을 하는지

같은 사진 한 장을 여러 조건으로 불러서 크기를 재봤습니다.

두 가지가 일어납니다.

형식을 바꿔줍니다. 브라우저가 요청할 때 "나는 이런 형식들을 읽을 수 있다"를 같이 보내는데(Accept 헤더), 서버가 그걸 보고 webp로 줄지 jpeg로 줄지 정해요. 우리가 코드를 나눠 쓸 필요가 없습니다.

필요한 크기로 다시 만들어 줍니다. 폰 화면에 384픽셀로 그려질 사진이라면 640픽셀짜리를 받을 이유가 없죠. 27,102바이트는 원본의 36%입니다.

화질은 잠겨 있습니다

주소의 q=75가 화질입니다. 숫자를 바꿔서 불러보면 이렇게 됩니다.

q=75   → 200
q=50   → 400   "q" parameter (quality) of 50 is not allowed
q=100  → 400   "q" parameter (quality) of 100 is not allowed

75 말고는 전부 거절당하는데, Next 16부터 화질 목록도 허용제로 바뀌었습니다. 안 적으면 75 하나만 열려 있고, 다른 값을 쓰려면 qualities에 적어야 합니다.

이유는 remotePatterns와 같습니다. 아무나 q=1부터 q=100까지 백 번 요청하면 우리 서버가 같은 사진을 백 가지 화질로 백 번 만들거든요.

💡 한 줄 정리

/_next/image는 열려 있는 통로다. remotePatterns로 어디서 가져올지, qualities로 어떤 화질까지 만들지 목록으로 좁힌다. 대신 서버가 형식과 크기를 알아서 맞춰준다.

Step 5: "어느 사진을 먼저 받을까요"

이제 사진이 나옵니다. 그런데 피드를 처음 열었을 때 첫 장이 조금 늦게 뜬다는 느낌을 받으셨을 거예요.

터미널을 보면 Next가 직접 말해줍니다.

[browser] Image with src "https://picsum.photos/seed/post1/640/640" was detected as
          the Largest Contentful Paint (LCP). Please add the `loading="eager"`
          property if this image is above the fold.

LCP(Largest Contentful Paint, 최대 콘텐츠 렌더링 시간)는 "화면에서 가장 큰 것이 언제 그려졌나"를 재는 지표입니다. 학생이 "아 떴다"라고 느끼는 순간과 가장 가까운 숫자예요.

우리 피드에서 가장 큰 것은 첫 사진인데, Step 2에서 본 것처럼 모든 사진에 loading="lazy"가 붙어 있어요. 화면에 이미 보이는 사진까지 "가까워지면 받자" 하고 미루고 있는 겁니다.

첫 장만 곧바로 받게

// apps/web-next/app/components/FeedList.tsx
      {posts.map((post, index) => (
        <li key={post.id} className="rounded border border-black/10 p-4">
          <p className="font-semibold">@{post.username}</p>
          {/* 원본이 몇 대 몇인지 알려준다. 그러면 사진이 오기 전에도 그 비율만큼 자리가 비워진다.
              화면 폭에 맞춰 줄어드는 건 className 이 맡는다. */}
          <Image
            src={post.imageUrl}
            alt={post.content}
            width={640}
            height={640}
            className="h-auto w-full"
            // 첫 장은 화면을 열자마자 보이는 자리다. 미루지 않고 곧바로 받는다.
            loading={index === 0 ? 'eager' : 'lazy'}
          />
          <p className="mt-1">{post.content}</p>
          <LikeButton postId={post.id} likeCount={post.likeCount} liked={post.liked} />
        </li>
      ))}

map의 두 번째 인자로 순번을 받아서 첫 장에만 eager를 줍니다. 나머지는 그대로 lazy예요.

경고가 사라지고, <head>에 이런 줄이 하나 생깁니다.

<link rel="preload" as="image" imageSrcSet="/_next/image?url=...&amp;w=640&amp;q=75 1x, ..." />

브라우저가 HTML을 위에서부터 읽다가 이 줄을 만나면, 아직 <img>까지 못 갔어도 사진을 미리 받기 시작합니다.

⚠️ 여기가 옛 자료와 갈리는 자리입니다

검색해서 나오는 대부분의 글은 이 자리에 priority를 쓰라고 합니다. Next 16에서 폐기된 이름입니다. 공식 문서가 이렇게 적어놨어요.

"Starting with Next.js 16, the priority property has been deprecated in favor of the preload property in order to make the behavior clear."

그런데 문서는 한 줄 더 붙이는데, 대부분의 경우 preload보다 loading="eager"를 쓰라는 것이에요. 방금 본 Next의 경고문도 정확히 그 이름을 불렀고요.

셋을 실제로 넣어보고 렌더 결과를 비교했습니다.

여기가 고약한데, priority를 써도 결과가 같아요. 타입 검사도 통과하고 린트도 조용하고 개발 서버 로그에도 아무 말이 없어서, 아무도 안 알려주는 채로 코드만 낡아갑니다.

C-1에서 라우터 패키지 이름이 바뀌었다는 이야기를 했었죠. 검색 결과가 낡았을 수 있다는 것을요. 프론트엔드는 반년마다 이런 자리가 생깁니다. 공식 문서의 그 API 페이지를 한 번 열어보는 습관이 유일한 방어선이에요.

💡 한 줄 정리

화면 맨 위 사진 한 장만 loading="eager"로 곧바로 받는다. 옛 자료의 priority는 Next 16에서 폐기됐는데 아직 동작해서 아무도 안 알려준다.

Step 6: "글꼴도 늦게 옵니다"

사진 이야기는 여기까지인데, 늦게 오는 게 사진만이 아니에요.

지금 우리 앱은 글꼴을 지정한 적이 없어서 학생 컴퓨터에 깔려 있는 기본 글꼴로 그려지는데, 맥에서 보는 화면과 윈도우에서 보는 화면이 다르고 자간도 줄 높이도 다르고요.

글꼴을 하나 정해서 우리가 주기로 합시다.

// apps/web-next/app/layout.tsx
import { Suspense } from 'react';
import type { Metadata } from 'next';
import { Noto_Sans_KR } from 'next/font/google';
import { HeaderNav } from './components/HeaderNav';
import { Providers } from './components/Providers';
import { SignInForm } from './components/SignInForm';
import { TextScaleStyle } from './components/TextScaleStyle';
import './globals.css';

// 빌드할 때 폰트 파일을 받아와 우리 서버에서 준다 — 학생 브라우저가 구글을 부르지 않는다.
// subsets 는 "미리 받아둘 조각" 이다. 한글은 여기 못 적는다(뒤에서 이유를 본다).
const notoSansKr = Noto_Sans_KR({ subsets: ['latin'], display: 'swap' });

이 값을 <html>에도 붙입니다.

    <html lang="ko" className={notoSansKr.className}>

새로고침하면 글꼴이 바뀝니다.

⚠️ 한글 폰트인데 subsets에 한글이 없습니다

subsets: ['korean']이 자연스러워 보이죠. 적어보면 이렇게 나옵니다.

app/layout.tsx(11,45): error TS2322: Type '"korean"' is not assignable to
type '"cyrillic" | "latin" | "latin-ext" | "vietnamese"'.

한글이 목록에 없는데, 빠뜨린 게 아니라 한글은 그 방식으로 못 나르기 때문입니다.

이유는 글자 수인데, 라틴 알파벳은 대소문자·숫자·기호 다 합쳐 200자쯤이라 한 파일에 담을 수 있습니다. 한글은 완성형만 11,172자라서, 통째로 받으면 몇 메가바이트가 됩니다.

그래서 한글 폰트는 잘게 쪼개서 나릅니다. 만들어진 CSS를 열어보면 이렇게 되어 있어요.

@font-face {
  font-family: Noto Sans KR;
  font-style: normal;
  font-weight: 100 900;
  font-display: swap;
  src: url("../media/5989c81e7a9c7e38-s.2isa_l1o5587j.woff2") format("woff2");
  unicode-range: U+D723-D728, U+D72A-D733, U+D735-D748, U+D74A-D74F, ...;
}

@font-face가 125개 있습니다. 각각이 unicode-range로 "이 글자들은 내가 담당한다"를 선언해요. 브라우저는 화면에 실제로 나온 글자를 보고 그 글자가 든 조각만 받습니다. "안녕하세요" 다섯 글자를 그리려고 11,172자를 받지 않아요.

구글을 안 부릅니다

방금 CSS의 src를 다시 보세요. fonts.gstatic.com이 아니라 ../media/...입니다. 우리 서버 주소예요.

next/font/google은 이름만 구글인데, 실제로는 빌드할 때 폰트 파일을 받아와 우리 프로젝트 안에 넣어두고 런타임에는 우리 서버가 줍니다. 학생 브라우저가 구글에 요청을 보내는 일이 한 번도 없어서, 방문자 IP가 구글로 안 갑니다.

글자가 안 밀리는 장치

여기부터가 오늘 주제와 이어지는데, 웹폰트도 늦게 와요. 도착하기 전까지는 기본 글꼴로 그려지다가, 도착하는 순간 갈아 끼워집니다. 두 글꼴의 글자 폭이 다르면 그 순간 줄이 흔들리는데, 사진이 밀어내던 것과 같은 일입니다.

만들어진 CSS에 이런 규칙이 하나 더 있습니다.

@font-face {
  font-family: Noto Sans KR Fallback;
  src: local(Arial);
  ascent-override: 110.73%;
  descent-override: 27.49%;
  line-gap-override: 0.0%;
  size-adjust: 104.76%;
}

"대역 배우"를 하나 만들어둔 겁니다. 이미 컴퓨터에 있는 글꼴(여기서는 Arial)을 데려다가, 줄 높이가 Noto Sans KR과 같아지도록 비율을 조정해서 씁니다. 위로 올라가는 높이(ascent), 아래로 내려가는 높이(descent), 전체 크기(size-adjust)를 전부 맞춰요. 이 숫자들은 Next가 두 글꼴의 실제 치수를 비교해서 계산한 값이라서, 진짜 글꼴이 도착해서 갈아 끼워질 때 줄 높이가 안 바뀌는데, 우리가 width/height로 사진 자리를 미리 잡은 것과 정확히 같은 발상이에요. 늦게 올 것의 크기를 미리 알아내서 그만큼 자리를 잡아둡니다.

display: 'swap'은 그동안 무엇을 보여줄지 정하는 값입니다. swap은 "대역 배우로 먼저 보여주고 진짜가 오면 바꿔라"예요. 글자가 안 보이는 시간이 없습니다.

💡 한 줄 정리

next/font는 폰트를 빌드 때 받아와 우리 서버가 준다. 한글은 유니코드 범위로 125조각이 나고, 대역 배우 글꼴의 비율을 진짜와 맞춰둬서 갈아 끼워질 때 글자가 안 밀린다.

Step 7: "어느 화면에 가 있든 제목이 같습니다"

브라우저 탭을 보세요.

피드에 있어도 "인스타그램 클론", @minji 프로필에 있어도 "인스타그램 클론", 탐색 화면에서도 "인스타그램 클론"인데, 탭을 다섯 개 띄워놓으면 어느 게 어느 화면인지 알 수 없어요.

원인은 D-1에서 만든 이 부분입니다.

// apps/web-next/app/layout.tsx
export const metadata: Metadata = {
  title: '인스타그램 클론',
  description: 'Next.js App Router 로 다시 짓는 인스타그램',
};

가장 바깥 껍데기에 하나 있고, 아래 화면들이 자기 것을 안 줘서 이게 그대로 쓰이고 있습니다.

화면마다 다르게

metadata는 고정된 값이라 사람 이름을 넣을 수 없는데, 이름은 주소에서 와야 하니까 값 대신 함수를 내보냅니다.

// apps/web-next/app/[username]/page.tsx
import { Suspense } from 'react';
import type { Metadata } from 'next';
import { FollowButton } from '@/app/components/FollowButton';
import { TagFilter } from '@/app/components/TagFilter';
import { fetchPostsByUsername, fetchProfile, fetchTopTags } from '@/lib/api';

// 화면을 그리기 전에 Next 가 이 함수를 먼저 부른다. 돌려준 값이 <head> 로 들어간다.
// 굳혀둔 집계값을 그대로 다시 쓴다 — 제목 하나 때문에 서버를 또 부르지 않는다.
export async function generateMetadata({ params }: PageProps<'/[username]'>): Promise<Metadata> {
  const { username } = await params;
  const profile = await fetchProfile(username);

  return {
    title: `@${username} · 인스타그램 클론`,
    description: `팔로워 ${profile.followerCount}명`,
  };
}

params를 받는 모양이 ProfilePage와 똑같은데, await를 붙이는 것도요. 화면을 그리는 함수와 제목을 만드는 함수가 같은 입력을 받는 거예요.

결과입니다.

description에는 팔로워 수까지 들어갔습니다.

<meta name="description" content="팔로워 8500명"/>

굳혀둔 값을 다시 씁니다

여기서 fetchProfile을 부르는 게 마음에 걸리실 수 있습니다. 화면도 같은 함수를 부르는데, 제목 때문에 서버를 한 번 더 부르는 건 아닐까요.

아닙니다. D-6에서 그 함수에 'use cache'와 cacheLife('hours')를 달아뒀거든요. 이미 굳어 있는 값이라 그대로 꺼내 씁니다. 그때 붙여둔 이름표가 여기서 값을 하네요.

그리고 하나 더. cacheComponents를 켜두면 굳지 않는 것을 <Suspense>로 감싸라는 규칙이 있었죠. 제목은 그 규칙 밖입니다. <head>는 흘려보낼 수 있는 자리가 아니라서 Next가 따로 다룹니다. 빌드 라우트 표도 안 바뀌어요 — /[username]은 여전히 ◐입니다.

💡 한 줄 정리

고정된 제목은 metadata, 주소에 따라 달라지는 제목은 generateMetadata. 화면과 같은 입력을 받고, 화면이 쓰는 굳은 값을 그대로 다시 쓴다.

Step 8: "남이 우리 링크를 볼 때"

마지막으로 하나 더 있는데, 지난 시간 마지막에 이렇게 말했었죠, 링크를 메신저에 붙여넣어도 마찬가지라고요.

/minji 주소를 복사해서 카카오톡이나 슬랙에 붙여넣으면 미리보기 카드가 뜹니다. 그 카드에 무엇이 들어갈지는 우리가 정할 수 있어요. og:로 시작하는 태그들입니다.

이것도 generateMetadata 안에서 만듭니다.

// apps/web-next/app/[username]/page.tsx
  return {
    title: `@${username} · 인스타그램 클론`,
    description: `팔로워 ${profile.followerCount}명`,
    // 우리 화면이 아니라 남의 화면에 뜨는 카드다. 크기까지 같이 줘야 자리를 잡는다.
    openGraph: {
      title: `@${username}`,
      description: `팔로워 ${profile.followerCount}명`,
      images: [{ url: profile.profileImageUrl, width: 64, height: 64 }],
    },
  };

openGraph라는 키 하나를 더 얹었습니다. 나온 결과는 이렇습니다.

<meta property="og:title" content="@minji"/>
<meta property="og:description" content="팔로워 8500명"/>
<meta property="og:image" content="https://picsum.photos/seed/minji/64/64"/>
<meta property="og:image:width" content="64"/>
<meta property="og:image:height" content="64"/>

title을 따로 준 이유가 있습니다. 탭에 뜨는 제목은 "@minji · 인스타그램 클론"이 좋아요. 어느 사이트인지 알아야 하니까요. 그런데 카드에는 이미 사이트 이름이 따로 표시되니까 @minji 만으로 충분합니다. 읽는 자리가 다르면 쓰는 글도 달라집니다.

width와 height를 같이 준 것도 오늘 주제 그대로예요. 메신저도 사진 크기를 모르면 카드 자리를 못 잡습니다. 우리 화면에서 한 일을 남의 화면에서도 하는 겁니다.

자기 것이 없는 화면은

지금 상태에서 / 나 /explore를 소스 보기로 열면 og: 태그가 하나도 없어서, 링크가 맨몸으로 나가요. 가장 바깥 껍데기에도 하나 깔아둡시다.

// apps/web-next/app/layout.tsx
export const metadata: Metadata = {
  title: '인스타그램 클론',
  description: 'Next.js App Router 로 다시 짓는 인스타그램',
  // 아래 화면이 자기 것을 안 주면 이게 쓰인다 — 링크가 맨몸으로 나가는 일은 없다.
  openGraph: {
    title: '인스타그램 클론',
    description: 'Next.js App Router 로 다시 짓는 인스타그램',
    type: 'website',
  },
};

결과는 이렇게 갈립니다.

/explore는 자기 generateMetadata가 없어서 껍데기 것을 물려받았고, /minji는 자기 것으로 덮었습니다. D-1에서 layout이 겹겹이 쌓이는 걸 봤는데, <head>도 안쪽이 이기는 구조입니다.

다만 한 가지가 다른데, 물려받기는 키 하나 단위예요. openGraph를 안 주면 껍데기 것이 통째로 내려오지만, 주는 순간 그 키 전체가 교체됩니다. 안쪽 항목끼리 섞이지 않는다는 것을 과제에서 직접 확인하게 됩니다.

💡 한 줄 정리

openGraph는 우리 화면이 아니라 남의 화면에 뜨는 카드다. 사진에는 크기를 같이 주고, 껍데기에 기본값을 깔아두면 어떤 주소를 복사해도 맨몸으로 안 나간다.

마무리

오늘 배운 핵심 세 가지

💡 하나 — 늦게 오는 것은 자리를 미리 잡아둡니다. 사진도 글꼴도 나중에 도착하는데, 도착할 때 자리가 없으면 그만큼 아래를 밀어내요. 우리 피드에서는 열 번째 게시물이 4,233픽셀 내려갔는데, 해법은 빨리 받는 게 아니라 얼마나 클지 미리 알려주는 것이었어요. width/height가 하는 일도, 폰트의 size-adjust가 하는 일도 같습니다.

💡 둘 — 열려 있는 통로는 목록으로 좁힙니다. /_next/image는 주소를 받아 사진을 만들어주는 통로인데, 좁혀두지 않으면 누구든 우리 서버에 아무 일이나 시킬 수 있어요. remotePatterns로 어디서 가져올지, qualities로 어떤 화질까지 만들지 정합니다. 지난 시간에 문지기를 세운 것과 같은 결이에요.

💡 셋 — 200이라고 다 정상은 아닙니다. 허락 안 된 주소의 사진은 빌드도, 페이지도, HTML도 전부 통과했는데, 400이 나는 것은 사진 바이트 하나뿐이라 프로덕션에서는 빈 자리만 남아요. 개발 서버가 더 요란하게 알려주는 자리도 있다는 걸 오늘 봤습니다.

다음 시간 예고

오늘까지 화면은 다 만들었는데, 사진도 있고 글꼴도 있고 주소마다 제목도 다르지만, 이 앱은 아직 제 노트북에서만 돕니다.

다음 시간에는 이걸 밖으로 내보냅니다. 필요한 것만 골라내서 한 덩어리로 만들고, 컨테이너 하나에 담아서 어디서든 실행되게 만들어요.

그 과정에서 오늘 배운 문장이 한 번 더 나오는데, 담아서 띄웠는데 화면은 200으로 뜨지만 스타일이 하나도 없고 버튼도 안 눌려서 무엇이 안 담겼는지 찾아야 하고, 컨테이너 안에서만 드러나는 문제도 하나 더 기다리고 있어요. 지금까지 우리가 코드에 그냥 적어둔 값 중에 밖으로 나가는 순간 뜻이 달라지는 것이 있거든요.

과제

[구현] 프로필 격자에도 사진을 붙이세요

/minji 같은 프로필 화면의 게시물 격자는 아직 글자만 보여줍니다. 여기에도 사진을 붙이세요.

• 칸이 정사각형(aspect-square)으로 고정되어 있어서, 피드처럼 width/height로 비율을 알려주는 방식은 여기에 안 맞아요. 공식 문서에서 fill을 찾아 읽고 쓰세요.
• fill을 쓰면 한 가지 조건이 생기는데, 그 조건을 안 맞추면 사진이 엉뚱한 곳에 붙어요. 무엇인지 확인하고 맞추세요.
• 사진이 칸을 꽉 채우되 찌그러지지 않게 하세요.
• 다 되면 소스 보기로 srcSet을 확인하세요. 피드의 것과 모양이 다릅니다. 무엇이 다르고 왜 다른지 한 문장으로 적으세요.

[구현] 프로필 사진을 진짜로 바꾸세요

프로필 화면 맨 위의 회색 동그라미를 실제 프로필 사진으로 바꾸세요. Profile 타입에 profileImageUrl이 있습니다.

• 동그라미는 64×64입니다.
• 바꾼 뒤 화면을 새로고침하면서 잘 보세요. 오늘 없앤 문제가 다시 나타납니다. 무엇이 밀리나요.
• 왜 다시 나타났는지 설명하고, 고치세요. 힌트는 <Image>밖에 있습니다.

[탐구] 화질을 열어보세요

Step 4에서 q=50이 400으로 거절당하는 걸 봤습니다. 열어봅시다.

• next.config.ts의 images에 qualities를 추가해서 40과 75를 허용하세요.
• /_next/image를 q=40·q=75·q=100 세 가지로 직접 불러서 상태 코드와 응답 크기를 표로 적으세요.
• 40으로 받은 사진과 75로 받은 사진을 나란히 열어보세요. 눈으로 구별이 되나요?
• 그럼 왜 모두 40을 안 쓸까요. 어떤 사진에서는 차이가 크게 보일지 한 문장으로 적으세요.

[탐구] 링크를 붙여넣어 보세요

만든 미리보기 카드를 실제로 확인합니다.

• 개발 서버 주소는 남의 서버에서 못 보니까, 소스 보기로 og: 태그를 직접 읽어 확인하세요. /·/explore·/minji 세 곳을 비교해 표로 적으세요.
• /explore에 generateMetadata를 추가해서 그 화면만의 제목과 카드를 주세요. 이 화면은 params가 없습니다. 함수 모양이 어떻게 달라지나요.
• 마지막으로 openGraph.images의 주소를 실제로 404가 나는 주소로 바꿔보세요. Step 4에서 허락한 목록에 없는 호스트로요. 빌드·타입 검사·화면 중 어디에서 걸리나요? 아무 데서도 안 걸린다면, 그 사실이 왜 문제인지 한 문장으로 적으세요.

생각해볼 주제

1. 우리 서버가 사진을 만들어야 할까요

/_next/image는 요청이 올 때마다 사진을 다시 만듭니다. 첫 요청은 만들고, 그 뒤로는 캐시에서 꺼내요.

편한데, 설정 한 줄이면 되고 코드도 안 바뀌어요. 사진 변환은 CPU를 꽤 쓰는 일이라서, 사용자가 늘면 화면을 그리는 일과 사진을 만드는 일이 같은 서버에서 자리를 다투게 돼요.

대안은 사진 전용 서비스에 맡기는 것인데, 대신 돈이 들고 업체에 묶이고, 그 서비스가 죽으면 우리 사진이 다 안 나옵니다.

우리 인스타그램 클론이 하루 10만 장을 서비스한다면 어느 쪽을 고르시겠어요? 판단의 기준이 되는 숫자는 무엇인가요?

2. 폐기됐는데 동작하는 API를 어떻게 발견할까요

오늘 priority를 봤습니다. Next 16에서 폐기됐는데 타입 검사도, 린트도, 개발 서버 로그도 아무 말을 안 했어요. 렌더 결과까지 같았고요.

이런 게 무서운 이유는 코드가 잘못됐다는 신호가 어디에도 없다는 것입니다. 다음 메이저 버전에서 갑자기 사라져야 그때 알게 되는데, 그때는 이미 그 코드가 프로젝트 곳곳에 복사되어 있고요.

팀에서 이런 것을 조기에 발견하려면 무엇을 해야 할까요? 사람의 성실함에 기대지 않는 방법이 있을까요?

3. 밀림을 없애는 것과 빨리 그리는 것 중 무엇이 먼저일까요

오늘 우리는 밀림을 4,233픽셀에서 0으로 만들었지만, 페이지가 빨라진 건 아니에요. 사진은 여전히 같은 시간에 도착하는데, 오히려 자리를 미리 비워두니 처음엔 빈 사각형이 크게 보이죠.

반대로 사진을 아주 작게 만들어서 빨리 받게 할 수도 있는데, 그러면 빨리 그려지는 대신 화질이 나빠져요.

"빠르다"는 하나가 아니라 여러 지표의 묶음이고, 어떤 것은 서로 밀어냅니다. 우리 인스타그램 클론에서 학생이 "이 앱 좋다" 고 느끼게 하려면 어느 지표를 먼저 잡아야 할까요? 그렇게 판단한 근거는 무엇인가요?