H-8: 국제화 ② — 글자만 바꾸면 되는 게 아닙니다

안녕하세요, 홍순구 튜터입니다.

지난 시간에 우리 앱을 한국어·영어·일본어 세 벌로 만들었는데, 주소 첫 칸이 언어가 됐고 언어별로 화면이 한 벌씩 미리 그려져서 잘 돌아갑니다.

영어로 들어가봤어요. /en/jaehoon을 열었더니 이렇게 나왔습니다.

 1 posts · 1240 followers
 (2026년 8월 22일 오후 2:32 기준)

영어 화면인데 이상한 게 세 가지 보입니다.

하나, 1 posts입니다. 하나인데 복수형이에요. 둘, 1240입니다. 영어권 사람이 기대하는 건 1,240 이죠. 셋, 시각이 한국어로 찍혀 있습니다. 주소는 /en인데요.

지난 시간에 우리가 옮긴 것은 구조였습니다. 언어를 어디서 알아낼지 정하고, 주소를 다시 짜고, 앱이 죽은 걸 되살렸죠. 글자는 머리말 세 칸과 탭 제목 네 칸, 딱 그만큼만 옮겼습니다.

오늘은 그 나머지를 하는데, 하다 보면 알게 되실 거예요. 번역은 글자를 바꾸는 일이 아닙니다. 숫자에도, 날짜에도, 줄이 바뀌는 방식에도, 심지어 글이 흘러가는 방향에도 언어가 들어 있습니다.

 오늘의 여정

 1. 번역이 어디까지 따라오나   브라우저까지 따라온다 — 필요 없는 것까지
 2. 숫자에 자릿점이 없다       {count} 와 {count, number} 는 다른 것
 3. 하나일 때와 여럿일 때      "1 posts" 를 언어가 고치게 한다
 4. 날짜는 진짜로 갈린다       하드코딩된 ko-KR 을 걷어낸다
 5. 글자 길이가 화면을 깨뜨린다  같은 머리말이 언어마다 다른 높이
 6. 줄은 아무 데서나 안 끊긴다   낱말 한가운데가 잘리는 이유
 7. 언어를 바꾸는 버튼         보던 화면은 그대로 두고
 8. 네 번째 언어, 뒤집힌 화면   아랍어와 좌우

💡 오늘 수업의 핵심 — "언어는 글자에만 들어 있는 게 아닙니다"

🎯 학습 목표

• 서버에서 읽은 번역문이 브라우저까지 얼마나 따라가는지 바이트로 재고, 그 양을 우리가 정합니다.
• 숫자·날짜·복수형처럼 글자가 아닌 것들을 언어에 맡깁니다.
• 글자 길이와 줄바꿈 규칙이 화면을 어떻게 깨뜨리는지 재보고 고칩니다.
• 글이 오른쪽에서 시작하는 언어를 들이고, 좌우가 뒤집혀도 안 깨지는 방식으로 여백을 씁니다.

Step 1: 번역이 어디까지 따라오나

먼저 물어볼 것

지난 시간에 우리가 쓴 도구는 서버에서 번역 파일을 읽어서, 브라우저가 번역 파일을 따로 내려받지 않습니다. 이게 이 도구를 쓰는 큰 이유 중 하나인데, 우리 머리말은 브라우저에서 도는 컴포넌트죠. 지금 어느 주소에 있는지 알아야 하니까요. 그 머리말이 홈, 탐색 같은 글자를 쓰는데, 이 글자는 어떻게 브라우저까지 갈까요? 서버에서만 읽는다면서요.

재봅시다.

서버가 브라우저로 보내는 것

서버가 화면을 그려서 보낼 때, HTML만 보내는 게 아닙니다. 브라우저에서 돌 컴포넌트들이 이어서 일할 수 있도록 자료 꾸러미를 같이 보내요. 그 꾸러미가 HTML 안에 <script>로 들어 있습니다.

그 안을 열어봤습니다.

 "messages": {
   "Nav":  { "brand": "인스타그램 클론", "home": "홈", "explore": "탐색" },
   "Meta": { "title": "인스타그램 클론",
             "description": "Next.js App Router 로 다시 짓는 인스타그램",
             "profileTitle": "@{username} · 인스타그램 클론",
             "followers": "팔로워 {count}명" }
 }

Nav가 있는 건 이해가 됩니다. 머리말이 브라우저에서 도니까 그 글자가 따라와야 하는데, Meta가 왜 여기 있을까요.

Meta.profileTitle과 Meta.followers는 프로필 화면의 탭 제목을 만들 때 씁니다. 그건 서버에서만 하는 일이에요. 브라우저에서 도는 컴포넌트는 이 칸을 한 글자도 안 읽습니다. 게다가 지금 이건 홈 화면입니다. 프로필 화면도 아니에요.

안 쓰는 칸도 값을 치르는지 확인합니다

의심이 들면 재보는 게 맞습니다. 번역 파일에 아무도 안 쓰는 칸을 스무 개 넣어봤어요. 회원가입 화면에서 쓸 문구라고 치고, 다시 빌드해서 홈 화면을 열어봤습니다.

회원가입 문구 스무 개가 홈 화면 HTML 안에 그대로 실려 나가는데, 홈 화면은 그 글자를 한 개도 안 보여주는데도 그렇습니다.

브라우저로 넘어가는 양이 쓰는 만큼이 아니라 파일 전체라서, 번역을 열심히 할수록 모든 화면이 무거워져요.

넘길 것을 우리가 고릅니다

고치는 방법은 한 줄이라서, 브라우저로 넘길 칸을 적어주면 됩니다.

// apps/web-next/app/[locale]/layout.tsx

// 이 언어의 번역문 전체를 서버에서 읽는다. 여기까지는 서버 안의 일이다.
const messages = await getMessages();

// ...

{/* 브라우저로 «넘겨보낼» 칸을 여기서 고른다.
    안 고르면 이 언어의 번역문이 통째로 넘어간다 — 서버만 쓰는 칸까지 같이. */}
<NextIntlClientProvider messages={{ Nav: messages.Nav }}>

messages는 서버에서 전부 읽습니다. 탭 제목을 만들려면 Meta도 필요하기 때문인데, 브라우저로 건네줄 때는 필요한 칸만 골라 건넵니다.

재봤습니다.

/en은 83 B, /ja는 111 B가 됐어요. 머리말 세 칸과 탭 제목은 세 언어 모두 그대로 나옵니다. 잃은 기능이 없습니다.

한 가지 짚고 싶은 게 있어요. 고친 뒤(88 B)가 아무것도 안 넣었을 때(307 B)보다 작습니다. 우리 앱은 지난 시간부터 이미 Meta를 헛되이 보내고 있었던 거예요. 오늘 발견한 게 아니라 오늘 재본 겁니다.

💡 한 줄 정리

브라우저로 넘어가는 번역문은 «쓰는 만큼» 이 아니라 «파일 전체» 다. 넘길 칸을 직접 고르면 307 B가 88 B로 줄지만, 대신 새 칸이 필요해질 때마다 손으로 추가해야 한다.

Step 2: 숫자에 자릿점이 없다

1240과 1,240

오프닝에서 본 1240부터 봅시다. 번역 파일에는 이렇게 적혀 있었어요.

 "followers": "팔로워 {count}명"

{count} 자리에 숫자를 넣어달라는 뜻이고, 넣어주긴 하는데 넣기만 해요.

 {count}          →  팔로워 1240명
 {count, number}  →  팔로워 1,240명

{count}는 값을 그대로 끼워 넣습니다. {count, number}라고 적어야 "이건 숫자다, 숫자답게 찍어라"가 됩니다. 한 단어 차이인데 결과가 다르죠.

그런데 예상이 하나 빗나갑니다

여기서 저는 "언어마다 숫자 쓰는 법이 다르니까 언어에 맡겨야 한다"고 말하려 했는데, 세 언어로 찍어봤어요.

 1240  →   ko  1,240
           en  1,240
           ja  1,240

셋이 똑같습니다.

한국어·영어·일본어는 천 단위를 쉼표로 끊는 게 같아서, 우리 앱에서 숫자의 문제는 "언어마다 다르다"가 아니라 "자릿점이 아예 없다"였던 겁니다. 세 언어 모두에서 똑같이 틀리고 있었어요.

언어마다 다르다는 건 사실이지만, 그걸 보려면 다른 언어가 필요해요.

 1240  →   de  1.240      ← 독일어는 점으로 끊고
           en  1,240      ← 영어는 쉼표로 끊는다

독일어는 쉼표와 점의 역할이 영어와 정반대입니다. 독일어 사용자가 1,240을 보면 1.24로 읽어요. 우리가 지원하는 언어에 독일어가 없어서 안 보였을 뿐이지, 규칙 자체는 진짜입니다.

이건 기억해둘 만합니다. 우리가 지원하는 언어들이 우연히 비슷하면, 진짜 문제가 안 보입니다.

프로필 화면을 옮깁니다

프로필 화면의 숫자들을 번역 파일로 옮기면서 number를 붙였습니다.

// apps/web-next/messages/ko.json
"Profile": {
  "stats": "게시물 {posts, number} · 팔로워 {followers, number}",
  "likes": "좋아요 {count, number}"
}

// apps/web-next/messages/en.json
"Profile": {
  "stats": "{posts, number} posts · {followers, number} followers",
  "likes": "{count, number} likes"
}

화면 쪽은 이렇게 바뀌었어요.

// apps/web-next/app/[locale]/[username]/page.tsx

// 이 화면의 번역 칸을 연다. 서버에서 도는 조각이라 기다렸다 받는다.
const t = await getTranslations('Profile');

// ...

<p className="mb-4 text-sm text-black/60">
  {t('stats', { posts: posts.length, followers: profile.followerCount })}
</p>

세 언어 모두 자릿점이 찍힙니다.

 /ko   게시물 1 · 팔로워 1,240
 /en   1 posts · 1,240 followers
 /ja   投稿 1 · フォロワー 1,240

탭 제목도 같이 고쳐졌어요. 지난 시간에 1240으로 나오던 게 1,240이 됐습니다.

영어를 다시 보면 1 posts가 아직 그대로인데, 자릿점을 고치니까 이게 더 눈에 띄네요. 다음에서 다룹니다.

💡 한 줄 정리

{count}는 값을 그대로 끼워 넣을 뿐이고, {count, number} 라야 숫자답게 찍힌다. 지원하는 언어들이 우연히 비슷하면 이런 결함은 세 언어에서 똑같이 안 보인다.

Step 3: 하나일 때와 여럿일 때

한국어로 개발하면 안 보이는 문제

1 posts는 영어 문법이 틀린 겁니다. 하나면 1 post여야 해요.

이 문제가 왜 지금까지 안 보였을까요. 한국어에는 이런 구분이 없기 때문입니다. 게시물 1개 든 게시물 5개 든 개는 그대로예요.

언어마다 "갈래"가 몇 개인지 세어봤습니다.

 언어   0     1     2     5     11        갈래 수
 ────────────────────────────────────────────────
 ko    other other other other other        1
 ja    other other other other other        1
 en    other  one  other other other        2
 ar    zero   one   two   few   many        6

한국어와 일본어는 한 갈래라서, 이 문제가 존재한다는 것 자체를 모르고 지나갑니다. 영어에서 처음 둘로 갈라지고요. 아랍어는 여섯 갈래예요. 아랍어는 오늘 마지막에 만납니다.

갈래를 언어에게 맡깁니다

우리가 if (count === 1) 같은 걸 쓰면 안 됩니다. 그건 영어 규칙이거든요. 아랍어에 가면 안 맞아요.

대신 번역 파일에 갈래를 적어둡니다.

// apps/web-next/messages/en.json
"Profile": {
  "stats": "{posts, plural, one {# post} other {# posts}} · {followers, plural, one {# follower} other {# followers}}",
  "likes": "{count, plural, one {# like} other {# likes}}"
}

// apps/web-next/messages/ko.json
"Profile": {
  "stats": "게시물 {posts, plural, other {#개}} · 팔로워 {followers, plural, other {#명}}",
  "likes": "좋아요 {count, plural, other {#}}"
}

한국어는 other 하나만 적습니다. 갈래가 하나니까요. 영어는 one과 other 둘을 적고요.

#는 "여기에 그 숫자"라는 뜻입니다.

자릿점이 안 죽었는지 확인합니다

여기서 한 가지 걱정이 생깁니다. 방금 Step 2에서 {count, number}로 자릿점을 얻었는데, 지금 그걸 {count, plural, ...}로 바꿔 썼거든요. number라는 말이 사라졌어요.

자릿점이 같이 사라진 건 아닐까요?

넣기 전에 재봤습니다.

     1  →  1 post
     2  →  2 posts
  1240  →  1,240 posts

살아 있습니다. #는 복수형 안에서도 숫자답게 찍혀요. Step 2에서 얻은 것을 Step 3이 되팔지 않았습니다.

이런 확인은 습관으로 두시면 좋아요. 방금 얻은 것 위에 새 걸 쌓을 때, 밑에 있던 게 그대로인지 보는 겁니다. 안 보고 넘어가면 조용히 잃습니다.

실제 화면

 /en  jaehoon   1 post · 1,240 followers
 /en  minji     1 post · 8,500 followers

1 post는 하나짜리 갈래, 1,240 followers는 여럿 갈래입니다. 한 줄 안에 두 갈래가 같이 나왔네요.

💡 한 줄 정리

갈래가 몇 개인지는 언어가 정한다 — 한국어 1개, 영어 2개, 아랍어 6개. 우리가 if (count === 1)로 세면 영어 규칙을 다른 언어에 강요하게 된다.

Step 4: 날짜는 진짜로 갈린다

주소는 영어인데 시각은 한국어

오프닝의 세 번째 이상한 점입니다. 프로필 화면 코드를 열어보니 이렇게 되어 있었어요.

// 지난 시간까지의 코드
({new Date(profile.countedAt).toLocaleTimeString('ko-KR')} 기준)

'ko-KR'이 손으로 적혀 있습니다. 그러니 /en이든 /ja 든 항상 한국어로 찍힙니다.

지난 시간에 우리가 구조만 옮기고 지나간 빚이에요. 이런 건 눈에 잘 안 띕니다. 화면이 안 깨지거든요. 그냥 조금 이상할 뿐이죠.

날짜는 숫자와 다릅니다

Step 2에서 숫자는 세 언어가 똑같았죠. 날짜는 다릅니다.

 같은 시각을 세 언어로

 ko   2026년 8월 22일 오후 2:32
 en   August 22, 2026 at 2:32 PM
 ja   2026年8月22日 14:32

순서도, 구분 기호도, 오전·오후를 쓰는지도 다 다릅니다. 일본어는 24시간제로 찍네요. 이건 우리가 규칙을 외워서 만들 수 있는 게 아니에요.

언어를 안 적는 방식으로 바꿉니다

// apps/web-next/app/[locale]/[username]/page.tsx

// 날짜·시각·숫자를 이 요청의 언어로 찍어주는 도구. 언어 이름을 손으로 안 적는다.
const format = await getFormatter();

// ...

<span className="ml-2 text-black/40">
  {t('countedAt', {
    time: format.dateTime(new Date(profile.countedAt), {
      dateStyle: 'long',
      timeStyle: 'short',
    }),
  })}
</span>

dateStyle과 timeStyle로 어느 정도로 자세히를 말할 뿐, 어떤 모양인지는 안 정합니다. 그건 언어가 정해요.

괄호와 "기준" 같은 말도 언어마다 다르니 번역 파일로 옮겼습니다.

 ko   "countedAt": "({time} 기준)"
 en   "countedAt": "(as of {time})"
 ja   "countedAt": "({time} 時点)"

실제 화면입니다.

 /ko   (2026년 8월 22일 오후 2:32 기준)
 /en   (as of August 22, 2026 at 2:32 PM)
 /ja   (2026年8月22日 14:32 時点)

⚠️ 언어와 시간대는 다른 축입니다

위 세 줄을 자세히 보시면 시각이 전부 2:32입니다. 영어로 봐도 서울 시각이에요.

당연합니다. 우리 설정에 시간대가 서울로 적혀 있으니까요. 그게 맞을 때가 많은데, 이 숫자는 "우리 서버가 언제 집계했나" 니까요. 보는 사람이 어디 있든 집계 시각은 하나지만, 이건 결정입니다. "이 시각을 누구 기준으로 보여줄 것인가"를 정해야 하고, 그 답은 그 숫자가 무엇이냐에 따라 달라요.

• 서버가 집계한 시각 → 한 시간대로 고정하고 그걸 밝힌다
• 사용자가 댓글을 단 시각 → 보는 사람의 시간대로 바꿔주는 게 낫다

언어를 바꿨다고 시간대가 따라오지 않습니다. 영어를 쓰는 사람이 서울에 살 수도 있고, 한국어를 쓰는 사람이 뉴욕에 있을 수도 있으니까요.

💡 한 줄 정리

날짜는 숫자와 달라서 순서·구분 기호·시간제가 언어마다 진짜로 갈린다. 언어 이름을 손으로 적지 말고 맡기되, 시간대는 언어에 딸려 오는 게 아니라 따로 내리는 결정이다.

Step 5: 글자 길이가 화면을 깨뜨린다

같은 머리말, 다른 높이

글자 자체를 봅시다. 머리말을 세 언어로 열어놓고 높이를 재봤어요.

 머리말 높이 (폭 768px 기준)

 ko   ██████████            102px
 en   ████████████          122px
 ja   ██████████            102px

영어가 20px 더 높습니다. 왜일까요. 안을 들여다봤어요.

 언어  브랜드 이름        홈        탐색
 ────────────────────────────────────────
 ko    74px / 2줄        13px/1줄   20px / 2줄
 en    70px / 2줄        41px/1줄   49px / 1줄
 ja    85px / 2줄        23px/3줄   31px / 2줄

두 줄, 세 줄이 보이시죠. 머리말 한 줄에 들어가야 할 것들이 글자 단위로 줄바꿈되고 있습니다.

영어에서 특히 심했어요. Home과 Explore가 홈·탐색보다 넓다 보니, 옆에 있던 "글자 크기" 버튼이 밀려서 네 글자가 세로로 한 줄씩 쌓였습니다.

 영어 화면의 "글자 크기" 버튼

   글
   자
   크
   기

이건 오늘 만든 문제가 아닙니다

먼저 분명히 해둘 게 있어요. 이 깨짐은 오늘 우리가 만든 게 아닙니다. 한국어에서도 이미 깨져 있었어요. 브랜드 이름이 두 줄이었고 로그인 칸은 세 줄이었죠.

머리말에 넣은 것이 많아서 폭이 모자랐던 것인데, 언어를 바꾸니까 어느 것이 눌리는지가 달라져서 눈에 띄었어요.

국제화 작업을 하면 이런 일이 자주 생깁니다. 원래 아슬아슬하던 것이 언어가 바뀌면서 무너지는 거죠. 국제화가 문제를 만든 게 아니라 드러낸 겁니다.

칸이 눌리지 않게 합니다

왜 글자가 쪼개졌을까요. 머리말이 가로로 늘어선 배치인데, 폭이 모자라니까 각 칸을 제 너비보다 좁게 눌러버린 겁니다. 눌린 칸 안에서 글자가 줄바꿈된 거고요.

고침은 한 단어입니다. 폭이 모자라면 칸을 누르지 말고 다음 줄로 내려보내라 고 하면 돼요.

// apps/web-next/app/components/HeaderNav.tsx

// flex-wrap 이 없으면 칸들이 제 너비보다 좁게 눌려서 «글자» 가 줄바꿈된다.
// 줄이 모자라면 글자를 쪼개지 말고 칸 단위로 다음 줄에 내려보낸다.
<nav className="mx-auto flex max-w-3xl flex-wrap items-center gap-4 p-4 text-sm">

다시 재봤습니다.

모든 칸이 한 줄이 됐습니다. 로그인 폼은 통째로 다음 줄로 내려갔어요. 글자가 쪼개지는 대신 덩어리가 이동한 겁니다.

일본어는 오히려 5px 높아졌는데, 이건 나빠진 게 아닙니다. 글자를 세로로 쌓아서 억지로 낮췄던 걸 정상적인 두 줄로 편 결과예요.

💡 한 줄 정리

국제화는 깨짐을 만든 게 아니라 드러냈다. 폭이 모자랄 때 칸을 누르는 대신 다음 줄로 내려보내면, 어느 언어가 들어와도 글자가 쪼개지지 않는다.

Step 6: 줄은 아무 데서나 안 끊긴다

Step 5가 증상을 지웠습니다

솔직하게 말씀드릴 게 있어요. 원래 이번 단계는 "일본어는 띄어쓰기가 없어서 줄바꿈이 이상하다"를 머리말로 보여드리려고 했습니다. 실제로 고치기 전 일본어 머리말이 이랬거든요.

 インスタグラ      ← "인스타그램" 이 여기서 잘렸다
 ムクローン

Step 5에서 칸이 안 눌리게 하자 이 증상이 같이 사라졌습니다. 글자에 자리가 생기니까 쪼갤 이유가 없어진 거라서, 여기서는 확인할 수 있는 게 없어졌습니다. 우리 앱의 게시물 본문은 사용자가 쓴 한국어 글이라 번역하지 않으니까요.

증상이 사라졌다고 원인이 사라진 건 아닙니다. 자리가 넉넉할 때만 안 보이는 것이라서, 폭을 고정한 칸을 따로 만들어서 재봤습니다.

어디서 끊기는지 봅니다

폭 120px 짜리 칸에 같은 뜻의 문장을 세 언어로 넣고, 줄이 어디서 바뀌는지 그대로 뽑았습니다.

 영어
   Welcome to the
   Instagram Clone          ← 띄어쓰기에서만 끊긴다. 낱말은 온전하다.

 한국어
   인스타그램 클론에
   오신 것을 환영합니
   다                       ← "환영합니 / 다" 낱말 한가운데가 잘렸다

 일본어
   インスタグラムク
   ローンへようこそ          ← "クローン" 한가운데가 잘렸다

여기서 짚고 싶은 게 있어요. 한국어도 잘립니다.

저는 이걸 "일본어 문제"로 알고 있었는데 재보니 아니었습니다. 한국어에도 띄어쓰기가 있지만 브라우저는 한국어·일본어·중국어에서 기본적으로 글자 단위로 끊어요. 띄어쓰기를 안 기다립니다.

영어만 낱말을 지킵니다.

언어마다 다른 규칙을 줍니다

한국어는 띄어쓰기가 있으니 "거기서만 끊어라" 고 하면 됩니다.

 한국어에 keep-all 을 준 뒤
   인스타그램 클론에
   오신 것을
   환영합니다              ← 낱말이 온전해졌다

일본어에도 같은 걸 주면 될까요. 해봤습니다.

 일본어에 keep-all 을 주면

   今日の東京の天気はとても良いので散歩に行きます
   └─ 칸 폭 140px · 실제 너비 322px ─┘

   → 182px 넘쳐서 밖으로 삐져나간다

같은 속성이 한 언어를 고치고 다른 언어를 깨뜨립니다.

당연합니다. 일본어에는 띄어쓰기가 없어요. "띄어쓰기에서만 끊어라"라고 하면 끊을 곳이 없으니 한 줄로 쭉 뻗어버리는 겁니다.

일본어에는 다른 걸 줍니다. 문장을 의미 덩어리로 나눠서 그 경계에서 끊게 하는 거예요.

 일본어에 auto-phrase 를 준 뒤
   今日の東京の天気は
   とても良いので散歩に
   行きます                ← 덩어리 경계에서 끊긴다

언어를 보고 붙게 합니다

두 규칙을 화면마다 손으로 적으면 금방 어긋납니다. 지난 시간에 우리가 <html>에 언어를 적어뒀으니, 그걸 보고 붙게 하면 돼요.

/* apps/web-next/app/globals.css */

/* 한국어: 띄어쓰기가 있으니 «거기서만» 끊게 한다. */
:lang(ko) {
  word-break: keep-all;
}

/* 일본어: 띄어쓰기가 없어서 keep-all 을 주면 한 줄이 통째로 넘쳐버린다.
   대신 문절(文節) 경계를 브라우저가 찾아 끊게 한다. */
:lang(ja) {
  word-break: auto-phrase;
}

브라우저가 실제로 뭘 적용했는지 확인해봤습니다. 선언만 보고 넘어가면 안 되니까요.

 /ko  →  keep-all
 /ja  →  auto-phrase
 /en  →  normal        ← 규칙을 안 줬으니 기본값. 영어는 이미 낱말을 지킨다.

⚠️ 이 중 하나는 크롬에서만 됩니다

auto-phrase는 크롬 계열 브라우저에서만 동작하고, 다른 브라우저는 이 줄을 모릅니다.

문제가 될까요? 안 됩니다. CSS는 모르는 값을 만나면 그 줄을 그냥 무시해요. 화면이 깨지지 않습니다. 그 브라우저에서는 지금처럼 글자 단위로 끊길 뿐이에요.

이런 걸 "있으면 더 좋고 없어도 되는" 개선이라고 봅니다. 반대로 keep-all은 오래전부터 모든 브라우저가 지원하니 마음 놓고 써도 됩니다.

이 둘을 구분하는 게 중요해요. 없으면 깨지는 것과 없으면 조금 덜 예쁜 것은 다르게 다뤄야 하니까요.

💡 한 줄 정리

같은 속성이 한 언어를 고치고 다른 언어를 깨뜨린다. 한국어엔 keep-all, 일본어엔 auto-phrase를 :lang()으로 갈라 주되, 앞은 없으면 깨지는 것이고 뒤는 없어도 되는 개선이다.

Step 7: 언어를 바꾸는 버튼

보던 화면은 그대로 두고

지금은 언어를 바꾸려면 주소창에 직접 쳐야 합니다. 버튼을 만들어봅시다.

중요한 건 보던 화면을 잃지 않는 것입니다. /ko/jaehoon을 보다가 일본어로 바꿨는데 홈으로 튕기면 곤란하죠.

지난 시간에 만든 도구가 여기서 일합니다. 우리가 쓰는 usePathname은 언어 칸을 뗀 주소를 돌려줘요. /ko/jaehoon에 있어도 /jaehoon을 줍니다. 그러니 거기에 새 언어만 붙이면 됩니다.

// apps/web-next/app/components/LocaleSwitcher.tsx
'use client';

export function LocaleSwitcher() {
  const locale = useLocale();
  // 언어 칸이 «빠진» 주소가 온다. /ja/jaehoon 에 있어도 /jaehoon 을 준다.
  // 그래서 보던 화면을 그대로 두고 언어만 갈아 끼울 수 있다.
  const pathname = usePathname();
  const router = useRouter();
  const t = useTranslations('LocaleSwitcher');

  return (
    <select
      aria-label={t('label')}
      value={locale}
      onChange={(event) => {
        router.replace(pathname, { locale: event.target.value });
      }}
      className="rounded border border-black/15 px-2 py-1"
    >
      {routing.locales.map((code) => (
        <option key={code} value={code}>{nativeName(code)}</option>
      ))}
    </select>
  );
}

목록의 이름을 무슨 말로 적을까요

작지만 중요한 결정이 하나 있습니다. 목록에 "일본어"라고 적을까요, "日本語"라고 적을까요?

한국어 화면이니까 "일본어"가 맞아 보이지만, 생각해보세요. 그 목록을 여는 사람은 지금 한국어를 못 읽어서 여는 겁니다. "일본어"라고 적혀 있으면 자기가 찾는 게 어느 것인지 알 수가 없어서, 각 언어를 그 언어 자신의 말로 적습니다.

// 목록에 뜨는 이름은 «그 언어 자신의 말» 로 적는다.
// 한국어 화면이라고 "일본어" 라고 쓰면, 일본어 쓰는 사람은 그 글자를 못 읽는다.
function nativeName(code: string) {
  return new Intl.DisplayNames([code], { type: 'language' }).of(code) ?? code;
}

이름을 우리가 적어두지 않아도 됩니다. 브라우저가 알고 있어요.

 ko  →  한국어
 en  →  English
 ja  →  日本語

⚠️ Step 1의 청구서가 여기서 옵니다

버튼을 붙이고 빌드했더니 이런 게 쏟아졌습니다.

 MISSING_MESSAGE: LocaleSwitcher (ko)
 MISSING_MESSAGE: LocaleSwitcher (en)
 MISSING_MESSAGE: LocaleSwitcher (ja)
 ...  모두 36건

"번역 칸이 없다"는 뜻인데, 저는 세 언어 파일에 LocaleSwitcher.label을 분명히 넣었어요. 파일을 열어보면 있습니다.

없는 게 아니라 안 넘어간 겁니다.

Step 1에서 우리가 이렇게 적었죠.

<NextIntlClientProvider messages={{ Nav: messages.Nav }}>

브라우저로 Nav만 넘긴다고 했는데, 이 버튼은 브라우저에서 돌면서 LocaleSwitcher 칸을 읽으려고 합니다. 서버에는 있지만 브라우저에는 안 갔어요.

이게 Step 1에서 우리가 한 선택의 대가입니다. 넘길 것을 고른다는 건, 새로 필요해지면 추가해야 한다는 뜻이에요.

// apps/web-next/app/[locale]/layout.tsx
<NextIntlClientProvider
  messages={{ Nav: messages.Nav, LocaleSwitcher: messages.LocaleSwitcher }}
>

이러니 36건이 0건이 됐습니다.

💡 그런데 빌드는 통과했습니다

여기서 꼭 짚어야 할 게 있어요. 위의 36건이 쏟아지는 동안에도 빌드는 성공했습니다. 종료 코드 0 이었어요.

 MISSING_MESSAGE  36건
 빌드 결과        성공 (exit 0)

빌드가 초록불인데 화면의 라벨이 세 언어 모두 깨져 있는 상태였던 겁니다.

우리는 이런 모양을 전에도 만났습니다. 보안 설정을 다룰 때 빌드는 멀쩡한데 화면의 스크립트가 하나도 안 실행된 적이 있었고, 지난 시간에는 빌드가 통과했는데 앱의 모든 화면이 안 열린 적이 있었죠.

빌드 성공은 "문법이 맞다"는 뜻이지 "동작한다"는 뜻이 아닙니다. 세 번째 만나는 것이니 이제 기억해두시면 좋겠어요.

확인

 /ko/explore   →  /ja/explore     보던 목록 그대로
 /ko/jaehoon   →  /ja/jaehoon     보던 사람 그대로

 바뀐 내용
   게시물 1개 · 팔로워 1,240명(2026년 8월 22일 오후 2:43 기준)
   投稿 1件 · フォロワー 1,240人(2026年8月22日 14:43 時点)

두 번째 줄 안에 오늘 한 게 거의 다 들어 있습니다. 복수형, 자릿점, 날짜 형식, 그리고 화면을 유지한 언어 전환까지요.

💡 한 줄 정리

언어 칸이 빠진 주소에 새 언어만 붙이면 보던 화면을 잃지 않는다. 그리고 Step 1에서 넘길 칸을 고른 대가가 여기서 청구된다 — 새로 필요해진 칸은 우리가 직접 추가해야 한다.

Step 8: 네 번째 언어, 그리고 뒤집힌 화면

언어를 하나 더 들입니다

마지막으로 아랍어를 들여봅시다. 지금까지와 다른 성질이 하나 있는 언어예요.

추가는 간단합니다. 목록에 한 줄, 번역 파일 하나.

// apps/web-next/i18n/routing.ts
export const routing = defineRouting({
  locales: ['ko', 'en', 'ja', 'ar'],
  defaultLocale: 'ko',
});

미리 그려지는 화면이 20개에서 24개로 늘었습니다. 언어 하나에 네 화면씩이니까요.

⚠️ 칸을 덜 채우면 어떻게 되는지 먼저 봅니다

일부러 머리말 세 칸만 채우고 빌드해봤습니다. 나머지는 비워뒀어요.

빌드는 성공했습니다. 그런데 /ar을 열어보니 이랬어요.

 브라우저 탭 제목:  Meta.title

탭에 우리가 쓴 칸 이름이 그대로 떠 있습니다. 번역문 대신에요. 페이지 설명도 Meta.description이라고 나갔고요.

빌드 기록을 보니 이런 게 76건 있었습니다.

 MISSING_MESSAGE: Meta (ar)
 MISSING_MESSAGE: LocaleSwitcher (ar)
 빌드 결과: 성공 (exit 0)

Step 7에서 본 것과 같은 모양이죠. 언어를 하나 추가하고 칸을 덜 채워도 아무도 안 막아줍니다. 검색 결과에 Meta.title이라고 뜬 뒤에야 알게 되는 거예요.

그래서 칸을 채웠습니다.

아랍어의 복수형 여섯 갈래

Step 3에서 예고한 걸 이제 실물로 봅니다.

// apps/web-next/messages/ar.json
"likes": "{count, plural, zero {لا إعجابات} one {إعجاب واحد} two {إعجابان} few {# إعجابات} many {# إعجابًا} other {# إعجاب}}"

여섯 갈래를 다 적어야 합니다. 실제로 다 쓰이는지 숫자를 바꿔가며 찍어봤어요.

     0  →  لا إعجابات        (zero — 없을 때 전용 표현)
     1  →  إعجاب واحد        (one)
     2  →  إعجابان           (two — 둘일 때 전용)
     3  →  3 إعجابات         (few)
    11  →  11 إعجابًا         (many)
  1240  →  1,240 إعجابًا      (many — 자릿점도 유지)

여섯 갈래가 전부 다르게 나옵니다. 한국어가 한 갈래로 끝내는 것을 아랍어는 여섯으로 나눠요.

만약 우리가 Step 3에서 if (count === 1) 같은 걸로 처리했다면, 여기서 전부 다시 짜야 했을 겁니다.

글이 오른쪽에서 시작합니다

아랍어는 오른쪽에서 왼쪽으로 씁니다. 브라우저에게 알려주려면 <html>에 한 칸을 더해야 해요.

그런데 여기서 제가 넘어졌습니다.

⚠️ 넘어진 이야기

방향을 우리가 목록으로 들고 있지 말고 브라우저에게 물어보면 좋겠다고 생각했어요. 실제로 그런 기능이 있습니다. 확인해보니 잘 되길래 코드에 넣었죠.

그리고 빌드가 멈췄습니다.

 TypeError: (intermediate value).getTextInfo is not a function
 Export encountered an error on /[locale]/[username]/page, exiting the build.

"그런 기능이 없다"는 뜻입니다. 분명히 확인했었는데요.

원인은 제 확인 방법에 있었습니다. 저는 이렇게 확인했어요. "새 이름이 있으면 그걸 쓰고, 없으면 옛 이름을 쓴다" 고요. 결과가 잘 나오길래 통과시켰죠.

그런데 그 확인은 어느 쪽이 동작했는지를 안 남겼습니다. 실제로는 새 이름이 없어서 옛 이름으로 돌아간 거였는데, 저는 결과만 보고 새 이름이 있다고 믿었어요. 그리고 코드에는 새 이름을 적었습니다.

다시 확인해보니 이랬습니다.

 새 이름(getTextInfo) 이 함수인가  →  undefined     없다
 옛 이름(textInfo) 이 있나          →  {"direction":"rtl"}   있다

이 기능은 표준으로 확정됐지만 이름이 바뀌는 중입니다. 그래서 실행 환경마다 있는 게 달라요. 우리 환경에는 옛 이름만 있었습니다.

여기서 배울 게 두 가지 있어요.

하나는 확인에 관한 겁니다. 여러 갈래를 두고 확인하면, 결과는 알 수 있어도 어느 길로 갔는지는 모릅니다. 갈래가 있는 확인을 할 때는 어느 쪽이 동작했는지도 같이 남겨야 해요.

둘은 선택에 관한 겁니다. 이름이 바뀌는 중인 기능 위에 앱의 동작을 얹으면 이런 일이 납니다. 우리 언어 목록은 네 줄이에요. 직접 적는 게 쌉니다.

직접 적되, 빠뜨리면 알려주게 합니다

// apps/web-next/i18n/routing.ts

// 글이 어느 쪽에서 시작하는지를 언어 목록 바로 옆에 함께 적는다.
//
// satisfies 를 붙여두면 언어를 하나 추가하고 방향을 안 적었을 때
// 화면이 아니라 «타입» 이 먼저 알려준다.
export const localeDirections = {
  ko: 'ltr',
  en: 'ltr',
  ja: 'ltr',
  ar: 'rtl',
} as const satisfies Record<(typeof routing.locales)[number], 'ltr' | 'rtl'>;

satisfies 한 단어가 하는 일이 있습니다. 언어를 추가하고 방향을 안 적으면 타입 검사가 막아요. 일부러 아랍어 방향을 지워봤습니다.

 TS1360  Property 'ar' is missing in type ... but required in
         type 'Record<"ko" | "en" | "ja" | "ar", "ltr" | "rtl">'

빠뜨린 곳과 쓰는 곳 두 군데에서 잡힙니다. 오늘 우리가 두 번이나 만난 "빌드는 초록인데 화면이 깨진" 상황을, 여기서는 미리 막아둔 거예요.

// apps/web-next/app/[locale]/layout.tsx

// 아랍어는 rtl, 나머지 셋은 ltr. 이 한 칸이 화면 전체의 좌우를 뒤집는다.
<html lang={locale} dir={localeDirections[locale]} className={notoSansKr.className}>

여백이 반대쪽에 붙어야 합니다

dir 한 칸으로 화면이 뒤집힙니다. 머리말이 오른쪽에서 시작하고, 목록이 오른쪽으로 정렬되죠.

그런데 우리가 손으로 적은 여백은 안 따라옵니다. 예를 들어 로그인 칸에 ml-2라고 적어뒀다면, 그건 "왼쪽에 여백"이라는 뜻이에요. 화면이 뒤집혀도 여전히 왼쪽에 붙습니다. 원래 의도는 "앞의 것과 떨어뜨려라" 였는데, 뒤집힌 화면에서 앞은 오른쪽이거든요.

우리 앱에 그런 곳이 몇 군데인지 세어봤습니다.

 app/[locale]/[username]/page.tsx      ml-2
 app/components/SignInFields.tsx       ml-2
 app/components/SignInForm.tsx         ml-2
 app/components/CommentSection.tsx     mr-1
                                       ─────
                                       4곳

네 곳입니다. 생각보다 적죠. 우리가 여백을 대부분 gap으로 줬기 때문이에요.

고침은 이름을 바꾸는 겁니다. "왼쪽" 대신 "시작하는 쪽"이라고 적어요.

 ml-2  →  ms-2      왼쪽 여백    →  시작하는 쪽 여백
 mr-1  →  me-1      오른쪽 여백  →  끝나는 쪽 여백

"시작하는 쪽"이 어디인지는 그 언어가 정합니다. 한국어면 왼쪽, 아랍어면 오른쪽이에요. 조건문을 하나도 안 씁니다.

브라우저가 실제로 뭘 적용했는지 확인했습니다.

같은 한 단어가 언어에 따라 반대쪽에 붙습니다.

 한국어 화면 (ltr) — 글이 왼쪽에서 오른쪽으로 흐른다

   ┌───────────┐
   │  로그인   │
   └───────────┘
   ↑
   ms-2 가 준 여백 8px 이 «왼쪽» 에 붙는다


 아랍어 화면 (rtl) — 글이 오른쪽에서 왼쪽으로 흐른다

   ┌───────────┐
   │   로그인  │
   └───────────┘
               ↑
               같은 ms-2 인데 여백 8px 이 «오른쪽» 에 붙는다

버튼에 실제로 뜨는 글자는 아랍어(تسجيل)지만, 여기서 보실 것은 글자가 아니라 여백이 어느 쪽에 붙었는지입니다. 우리가 바꾼 건 한 단어뿐이고 붙는 쪽은 언어가 정했어요.

💡 한 줄 정리

dir 한 칸이 화면 전체의 좌우를 뒤집지만, 손으로 적은 왼쪽·오른쪽 여백은 따라오지 않는다. 시작·끝 기준으로 적으면 방향은 언어가 정하고, 빠뜨린 언어는 satisfies가 타입 단계에서 잡는다.

마무리

오늘 한 일을 정리하면 이렇습니다.

 1. 브라우저로 넘길 번역 칸을 골랐다        307 B → 88 B
 2. 숫자에 자릿점을 붙였다                  1240 → 1,240
 3. 하나와 여럿을 언어가 정하게 했다        "1 posts" → "1 post"
 4. 시각에서 하드코딩된 언어를 걷어냈다     /en 인데 한국어였던 것
 5. 칸이 눌려 글자가 쪼개지는 걸 막았다     한 칸 4줄 → 1줄
 6. 언어마다 줄 끊는 규칙을 다르게 줬다     낱말 한가운데가 잘리던 것
 7. 화면을 유지한 채 언어를 바꾸게 했다     /ko/jaehoon → /ja/jaehoon
 8. 네 번째 언어와 뒤집힌 화면을 들였다     물리 여백 4곳 → 논리 여백

지난 시간 처음에 "글자만 바꾸면 될 것 같지만 그렇지 않다" 고 말씀드렸죠. 오늘 그 뒤쪽 절반을 보셨습니다.

오늘 배운 핵심 세 가지

💡 하나 — 오늘 만진 것 중 글자 자체는 오히려 적었습니다. 숫자를 찍는 법, 날짜를 찍는 법, 갈래를 나누는 법, 줄을 끊는 법, 여백이 붙는 쪽. 이것들이 전부 언어에 딸려 있었습니다.

💡 둘 — 오늘 두 번 넘어졌고, 둘 다 재보고 나서야 알았습니다. 한 번은 Step 5의 고침이 Step 6에서 보여드리려던 증상을 지워버린 것이었고, 한 번은 확인을 잘못해서 없는 기능을 코드에 적은 것이었죠. 앞의 것은 고친 다음 원래 되던 걸 다시 안 쟀으면 몰랐을 거고, 뒤의 것은 확인이 어느 길로 갔는지를 안 남겨서 생긴 일이었습니다.

💡 셋 — 지난 시간이 옮긴 것은 구조였고, 오늘은 그 위에 얹히는 세부였습니다. 자릿점 · 복수형 · 줄바꿈 · 방향까지 갖춰야 비로소 "번역했다" 고 말할 수 있습니다.

다음 시간 예고

우리 앱에는 아직 한국어 그대로인 글자가 마흔 개 넘게 남아 있습니다. 다음 시간에는 화면을 여러 팀이 나눠 만드는 이야기로 넘어가는데, 남은 글자들은 오늘 배운 방식 그대로 옮기시면 됩니다.

과제

[구현] 남은 글자를 옮깁니다

우리 앱에는 아직 한국어 그대로인 UI 글자가 있습니다. 세어보니 20개 파일에 47개였어요. (주석을 뺀 문자열과 화면에 그대로 나가는 글자만 셌습니다. 세는 방법에 따라 숫자가 달라질 수 있으니 직접 세보셔도 좋아요.)

그중 게시물 본문과 해시태그 30개는 사용자가 쓴 글이라 번역하지 않습니다. 지난 시간에 가른 그 기준 그대로예요.

• 가장 많이 남은 파일부터 옮겨보세요. SignInFields.tsx에 5개가 있습니다.
• 옮긴 뒤 빌드하고 MISSING_MESSAGE가 나오는지 보세요. 나온다면 왜일까요? Step 7에서 만난 것과 같은 이유일 수 있습니다.
• app/actions/ 안의 파일들은 브라우저가 아니라 서버에서만 도는 코드입니다. 여기서는 훅을 쓸 수 없어요. 어떻게 번역 칸을 여실 건가요?

[구현] 언어를 하나 더 넣어보세요

독일어를 넣어보세요. Step 2에서 자릿점 이야기를 하며 잠깐 봤던 그 언어입니다.

• 언어 목록에 de를 넣고 방향을 일부러 안 적어보세요. 무엇이 먼저 알려주나요? 화면인가요, 타입 검사인가요?
• 번역 파일을 만들고 팔로워 수를 보세요. 1,240으로 나오나요, 1.240으로 나오나요?
• 미리 그려지는 화면이 몇 개가 되나요? 24개에서 얼마나 늘었나요?

[탐구] 좁은 화면에서 다시 재보세요

Step 5에서 잰 머리말 높이는 폭이 768px 일 때입니다.

• 브라우저 창을 휴대폰 폭(400px 안팎)으로 줄이고 네 언어를 각각 열어보세요.
• 머리말이 몇 줄이 되나요? 언어마다 다른가요?
• flex-wrap을 잠시 지워보고 같은 폭에서 다시 보세요. 무엇이 달라지나요? 확인 뒤 되돌리세요.

[탐구] 고친 것이 다른 것을 되팔지 않았는지 확인하세요

Step 3에서 저는 복수형을 넣기 전에 "자릿점이 안 죽었나"를 먼저 쟀습니다.

• 만약 안 쟀다면 어떻게 됐을지 재현해보세요. # 대신 그냥 숫자를 넣는 방식으로 복수형을 써보고, 1240을 넣으면 무엇이 나오는지 보세요.
• 그 상태에서 빌드와 타입 검사는 통과하나요?
• 통과한다면, Step 2에서 얻은 것이 사라진 걸 무엇으로 알아챌 수 있을까요?

생각해볼 주제

1. 우리가 지원하는 언어가 우연히 비슷할 때

Step 2에서 숫자 표기가 세 언어 모두 같았습니다. 그래서 "언어마다 다르다"를 보여드릴 수가 없었어요. 독일어를 빌려와야 했죠.

이건 운이 좋았던 걸까요, 나빴던 걸까요. 세 언어만 지원한다면 자릿점 처리를 대충 해도 아무 문제가 없습니다. 그러다 네 번째 언어가 들어오는 날 한꺼번에 드러나겠죠.

지금 당장 문제가 안 되는 것을 미리 제대로 해둘지, 문제가 될 때 고칠지는 늘 판단입니다. 여러분이라면 이 결정을 무엇으로 내리시겠어요? 그리고 "나중에 고치자"를 골랐다면, 그 나중이 왔다는 걸 어떻게 알아차릴 수 있을까요?

2. 고쳤더니 증거가 사라졌습니다

Step 5에서 칸이 눌리는 걸 고쳤더니, Step 6에서 보여드리려던 일본어 줄바꿈 문제가 같이 사라졌습니다. 증상이 없어졌지만 원인은 그대로 있었어요. 자리가 넉넉할 때만 안 보일 뿐이었죠.

이런 일은 버그를 고칠 때도 자주 생깁니다. 증상이 사라져서 고쳐진 줄 알았는데, 사실은 조건이 바뀌어서 안 보이게 된 것뿐인 경우요.

둘을 어떻게 구별할 수 있을까요? "정말 고쳐졌다"와 "지금은 안 보인다"를 가르는 데 무엇이 필요할지 이야기해봅시다.

3. 빌드가 초록불인데 화면이 깨져 있을 때

오늘 두 번 만났습니다. 번역 칸을 안 넘겨서 라벨이 깨졌을 때 36건, 아랍어 칸을 덜 채워서 탭 제목이 Meta.title로 떴을 때 76건. 둘 다 빌드는 성공이었어요.

그런데 마지막에 우리는 이걸 막는 방법을 하나 썼습니다. satisfies로 방향을 빠뜨리면 타입이 잡게 한 거죠. 같은 방식으로 번역 칸이 비었을 때도 막을 수 있을까요?

막을 수 있다면 어디까지 막는 게 좋을까요. 모든 언어의 모든 칸이 채워져야만 빌드가 되게 하면 안전하겠지만, 번역이 도착하기 전에는 아무것도 배포할 수 없게 됩니다. 이 사이 어디에 선을 그으시겠어요?