[로컬라이제이션의 세계] #7 언어 자산 - 스타일 가이드(Style Guide)

같은 영어 문장을 두 명의 번역가에게 맡겨보자.

 

[Ready to get started?]

 

한 사람은 이렇게 번역할 수 있다.

 

[시작할 준비가 되셨나요?]

 

다른 사람은 이렇게 번역할 수도 있다.

 

[그럼 시작해 볼까요?]

 

둘 다 틀린 번역은 아니다.

 

하지만 같은 제품 안에서 첫 번째 문장과 두 번째 문장이 뒤섞여 나온다면 이야기가 달라진다. 어떤 화면에서는 딱딱한 존댓말을 쓰고, 다른 화면에서는 친근하게 말을 건다. 버튼에는 ‘저장’이라고 쓰다가 비슷한 기능의 다른 버튼에서는 ‘저장하기’를 쓴다. 숫자와 단위 사이에는 공백을 넣었다가 빼고, 영문 제품명은 그대로 쓰다가 어느 순간 한글로 표기한다. 문장 하나하나만 보면 문제가 없는데, 제품 전체를 보면 어딘가 어수선하다.

 

이런 문제를 줄이기 위해 사용하는 대표적인 언어 자산이 스타일 가이드(Style Guide)다.

 

*

 

스타일 가이드 =  맞춤법 규정집?

스타일 가이드라고 하면 가장 먼저 문법이나 맞춤법 규칙을 떠올리기 쉽다. 물론 그런 내용도 들어간다. 문장 부호는 어떻게 사용할지, 숫자와 단위는 어떻게 표기할지, 날짜는 어떤 형식으로 쓸지, 영어 고유명사를 한글로 표기할지 원문 그대로 유지할지 등을 정할 수 있다. 하지만 좋은 로컬라이제이션 스타일 가이드의 역할은 그보다 훨씬 크다.

 

“우리 제품은 사용자에게 어떻게 말해야 하는가?”

 

이 질문에 대한 답을 정리한 문서에 가깝다.

 

예를 들어 같은 오류 메시지도 이렇게 달라질 수 있다.

 

[비밀번호가 올바르지 않습니다. 다시 입력하십시오.]

[비밀번호가 맞지 않아요. 다시 입력해 주세요.]

[비밀번호를 확인해 주세요.]

 

세 문장 모두 의미 전달에는 문제가 없다. 하지만 은행 앱과 어린이용 게임, 운동 앱이 똑같은 방식으로 사용자에게 말을 걸 필요는 없다.

어떤 브랜드는 정확하고 전문적인 목소리를 원하고, 어떤 브랜드는 친근하고 가벼운 목소리를 원한다. 같은 브랜드 안에서도 법률 고지와 마케팅 문구의 말투가 같을 필요는 없다. 스타일 가이드는 이런 수많은 언어적 선택에 기준을 만들어준다.

 

또한 언어에는 하나의 정답만 존재하는 경우보다 여러 표현이 모두 가능한 경우가 훨씬 많기에, 기준이 없다면 여러 번역시과 리뷰어가 함께 작업을 할 때 리뷰는 품질 관리가 아니라 서로의 언어 취향을 교정하는 과정이 되기 쉽다. 스타일 가이드는 이때 공통의 기준점이 된다. “누가 더 자연스럽다고 생각하는가?”가 아니라 “우리가 정한 스타일은 무엇인가?”를 묻게 만드는 것이다.

 

스타일 가이드의 주요 내용

스타일 가이드의 내용은 제품과 회사에 따라 크게 달라진다. 하지만 몇 가지 대표적인 영역이 있다.

1. Voice & Tone

가장 중요한 부분 중 하나다. 사용자에게 어떤 목소리로 말할 것인가? 예를 들어,

• 친근하지만 지나치게 가볍지 않게
• 전문적이지만 권위적으로 들리지 않게
• 간결하고 직접적인 문장 사용
• 사용자를 탓하는 표현 피하기
• 불필요한 과장 표현 피하기

같은 원칙을 정할 수 있다. 하지만 지침에 ‘친근하게 번역하세요’라고만 써놓으면 사람마다 생각하는 친근함이 다르기에 논쟁의 여지가 되기 십상이다. 그래서 실제 예시가 중요하다.

 

Avoid
잘못된 값을 입력하셨습니다.

Prefer
입력한 값을 확인해 주세요.

 

추상적인 설명보다 이런 예시 하나가 훨씬 효과적일 때가 많다.

2. 높임말과 문체

한국어에서는 특히 중요하다. ‘합니다’체를 사용할지, ‘해요’체를 사용할지부터 결정해야 한다.

UI에서는 "설정을 완료하십시오." 라고 하면서 마케팅에서는 "새로운 기능을 만나봐요!" 라고 할 수도 있다. 버튼이나 메뉴처럼 공간이 제한된 UI에서는 완전한 문장을 사용하지 않을 수도 있다. 영어에서는 크게 고민하지 않았던 문제가 한국어로 넘어오는 순간 중요한 스타일 결정이 되는 경우가 많다.

3. UI 요소 표기

버튼, 메뉴, 체크박스, 오류 메시지처럼 반복적으로 등장하는 UI 요소에도 기준이 필요하다. 예를 들어 영어의 Save를 '저장'과 '저장하기'

중 무엇으로 번역할까? Cancel은 ‘취소’와 ‘취소하기’ 중 어느 쪽을 쓰는 게 좋을까?

버튼에는 명사형을 사용한다는 식으로 규칙을 정할 수도 있다. 한두 문장에서는 사소해 보이지만 수천 개의 문자열이 쌓이면 이런 작은 차이가 제품 전체의 인상을 좌우한다.

4. 숫자, 날짜, 시간, 단위

10km / 10 km

오전 9:00 / 오전 9시

2026년 10월 24일 / 2026. 10. 24.

어떤 표기를 사용할까? 특히 여러 플랫폼에서 같은 데이터를 표시하거나 수치가 중요한 제품이라면 이런 규칙은 생각보다 중요하다.

5. 영어와 외래어 처리

Bluetooth를 ‘블루투스’라고 할 것인가, ‘Bluetooth’라고 할까? Wi-Fi는? GPS는? 제품명과 기능명은?

이미 한국 사용자에게 영어 표현이 더 익숙한데 굳이 번역하면 오히려 어색할 수도 있다. 반대로 영어를 지나치게 남겨두면 번역된 제품인데도 한국 사용자가 이해하기 어려워진다. 중요한 것은 무조건 번역하거나 무조건 원문을 유지하는 것이 아니라 일관된 기준을 만드는 것이다.

 

실제 스타일 가이드 예시

온라인에서 쉽게 무료로 접근할 수 있는 가장 대표적인 예가 Microsoft Localization Style Guides다.

Microsoft는 한국어를 포함한 다양한 언어의 로컬라이제이션 스타일 가이드를 공개하고 있다. 실제 기업이 각 언어의 로컬라이제이션에서 어떤 기준을 정의하는지 볼 수 있기 때문에 로컬라이제이션을 공부하는 사람이라면 한 번쯤 살펴볼 만하다. 특히 Korean Style Guide를 열어보면 한국어의 문체와 언어 사용, UI 관련 규칙 등을 어떻게 문서화하는지 참고할 수 있다.

 

Microsoft Localization Style Guides:

https://learn.microsoft.com/en-us/globalization/reference/microsoft-style-guides

 

함께 살펴볼 만한 자료로 Google Developer Documentation Style Guide도 있다.

Microsoft의 자료처럼 언어별 번역가를 위한 Localization Style Guide라기보다는 기술 문서를 위한 Writing Style Guide에 가깝지만, 명확한 문장과 용어, Voice & Tone, UI 표기 등을 어떻게 규칙으로 만드는지 참고하기 좋다. 특히 Google은 별도로 Write for a global audience라는 항목을 두고 번역과 로컬라이제이션을 고려해 원문을 작성하는 방법도 설명한다. 좋은 스타일 가이드는 번역가에게 ‘어떻게 번역할 것인가’를 알려주는 데서 끝나지 않는다. 애초에 번역하기 좋은 콘텐츠를 어떻게 만들 것인가에도 영향을 줄 수 있다.

 

Google Developer Documentation Style Guide:

https://developers.google.com/style

https://developers.google.com/style/translation

 

그런데 아무도 읽지 않는다면?

여기까지 읽으면 스타일 가이드는 자세할수록 좋을 것처럼 보일 수도 있다. 하지만 실제 로컬라이제이션 업계에서 일하면서 나는 그 반대의 경우도 많이 봤다. 상당히 잘 만들어진 스타일 가이드가 있는데도 실제 번역에서는 거의 사용되지 않는 경우다. 프로젝트 시작 때 번역가에게 수십 페이지짜리 PDF를 전달한다. 여러 참고 문서와 함께 링크도 보내준다. 그리고 작업은 시작된다. 시간이 지나면서 새로운 번역가가 투입되고, 벤더가 바뀌고, 리뷰어도 바뀐다. 제품에는 새로운 기능이 추가된다. 그런데 스타일 가이드는 몇 년 전 그대로다. 번역가들은 바쁜 일정 속에서 수십 페이지의 문서를 매번 찾아보지 않는다. 실제 번역에서 자주 발생하는 문제는 정작 가이드에 없고, 거의 발생하지 않는 예외적인 규칙이 몇 페이지에 걸쳐 설명되어 있기도 한다. 결국 스타일 가이드는 존재하지만 실제 의사 결정에는 사용되지 않는 유명무실한 문서가 된다. 그래서 스타일 가이드에서 중요한 것은 얼마나 많은 규칙을 담고 있는가가 아니라 얼마나 자주 실제 판단에 사용되는가라고 생각한다.

 

스타일 가이드의 규칙 역시 실제 프로젝트에서 발견되는 문제를 따라가야 한다. 리뷰에서 같은 문제가 계속 발견된다면 매번 번역가에게 똑같은 피드백을 보내는 대신 생각해 볼 수 있다. “이건 스타일 가이드에 넣어야 하지 않을까?” 반대로 몇 년 동안 아무도 참고하지 않는 규칙이라면 정말 필요한 내용인지 다시 검토할 수도 있다. 그렇게 스타일 가이드는 완성해서 보관하는 문서가 아니라 프로젝트와 함께 계속 다듬어지는 언어 자산이 된다.

 

AI 시대에 더 중요해지는 스타일 가이드

AI 이야기도 빼놓을 수 없다. 단순히 ‘AI에게 스타일 가이드를 프롬프트로 주면 번역을 잘한다’는 이야기를 하려는 것은 아니다.

더 흥미로운 변화는 스타일 가이드가 사람이 읽는 문서에서 시스템이 활용할 수 있는 언어 데이터로 변하고 있다는 점이다. 기존의 로컬라이제이션 자산을 생각해 보면, 번역 메모리(Translation Memory)는 과거에 어떻게 번역했는지를 보여준다. 용어집(Glossary)은 무엇을 무엇이라고 불러야 하는지를 알려준다. 그리고 스타일 가이드(Style Guide)는 어떻게 말해야 하는지를 알려준다.

LLM 기반 번역이나 리뷰에서는 이 세 가지를 함께 Context로 제공할 수 있다.

 

예를 들어 스타일 가이드에 다음과 같은 핵심 규칙이 있다고 해보자.

 

Tone: Friendly, encouraging, concise
Formality: 해요체
UI buttons: 명사형 사용
Product names: 번역하지 않음
Error messages: 사용자의 잘못을 직접적으로 지적하지 않음

 

이런 정보는 번역 생성뿐 아니라 AI 기반 QA에서도 사용할 수 있다. ‘합니다’체를 사용하지 않는 제품에서 "설정이 완료되었습니다."

라는 번역이 발견되면 스타일 위반 가능성을 표시할 수 있고, 버튼에는 명사형을 사용하기로 했는데 "저장하기"가 들어왔다면 검토 대상으로 올릴 수 있다. 기존의 자동 QA가 숫자 불일치, 태그 누락, 용어 오류처럼 비교적 명확한 오류를 찾는 데 강했다면, LLM을 활용하면 문체나 Voice & Tone처럼 기존에는 자동으로 검사하기 어려웠던 영역까지 범위를 넓힐 수 있다.

 

그런데 여기서도 결국 같은 문제가 돌아온다. 스타일 가이드 자체가 명확해야 한다는 것. 사람이 읽어도 무슨 뜻인지 애매한 규칙은 AI에게 전달한다고 갑자기 명확해지지 않는다. “자연스럽게 번역한다.” “브랜드에 맞는 친근한 어조를 사용한다.” 같은 추상적인 문장보다,

무엇을 하고 무엇을 하지 않는지, 실제 예시는 무엇인지 명확하게 정의된 규칙이 훨씬 활용도가 높다. AI를 제대로 활용하려면 인간이 먼저 원하는 언어를 더 정확하게 정의해야 하는 셈이다.

 

그래서 앞으로의 스타일 가이드는 단순히 번역가에게 보내는 PDF나 Word 문서만을 의미하지 않을 가능성이 크다. 사람이 읽기 쉬우면서 동시에 필요한 규칙을 시스템이 검색하고 AI의 Context로 전달할 수 있는 형태가 점점 중요해질 것이다. 이 관점에서 보면 앞서 이야기한 ‘짧고 명확하며 실제로 도움이 되는 스타일 가이드’의 중요성은 AI 시대에 오히려 더 커진다. 수십 페이지의 규칙을 만드는 것 자체가 목표가 아니다. 번역가가 고민하는 순간 필요한 답을 찾을 수 있고, 리뷰어가 판단의 근거로 사용할 수 있고, 필요하다면 AI도 같은 기준을 활용할 수 있어야 한다.

 

*

 

다음 이야기

→ [로컬라이제이션의 세계] #8 언어 자산 - 번역 메모리(Translation Memory)와 용어집(Glossary)