OpenL logo

모바일 앱 현지화 방법

OpenL Team 3/14/2026

TABLE OF CONTENTS

모바일 앱 현지화 방법을 검색하고 있다면, 보통 “번역 팁”이 필요한 것이 아닙니다. 앱 문자열, 레이아웃, 복수형 규칙, 오른쪽에서 왼쪽(RTL) 지원, 스크린샷, 스토어 메타데이터를 제품을 망가뜨리지 않고 처리하는 출시 안전한 워크플로우가 필요한 것입니다.

핵심적인 차이점은 다음과 같습니다: 모바일 앱 현지화는 단순히 텍스트를 번역하는 것이 아닙니다. 각 타겟 시장에 맞게 앱, 제품 페이지, QA 프로세스를 적응시키는 것입니다. Apple에 따르면 App Store는 175개 지역과 40개 언어에서 이용 가능하며, Android 13은 시스템 수준의 앱별 언어 설정을 도입했습니다. 다시 말해, 양대 플랫폼 모두 언어 선택을 부수적인 기능이 아닌 핵심 제품 경험으로 간주합니다.

이 가이드는 iOS와 Android 팀을 위한 실용적인 단계를 안내합니다.

한눈에 보기:

  • 인앱 현지화와 App Store 및 Google Play 현지화를 분리하세요.
  • 번역하기 전에 먼저 문자열을 외부화하세요.
  • 복수형, 변수, 날짜, 통화, RTL을 초기에 처리하세요.
  • 실제 번역을 출시하기 전에 의사 언어(pseudolanguage)로 테스트하세요.
  • 설명뿐만 아니라 스크린샷과 스토어 자산도 현지화하세요.

모바일 앱 현지화에 실제로 포함되는 것

현지화 작업은 보통 두 가지 트랙으로 나뉩니다.

1. 인앱 현지화

이것은 제품 자체입니다:

  • UI 문자열
  • 에러 메시지와 온보딩 문구
  • 날짜, 시간, 숫자, 통화, 단위
  • 복수형 및 성별 관련 문자열
  • 레이아웃 확장과 오른쪽에서 왼쪽 동작
  • 텍스트나 방향성 의미를 포함하는 이미지나 아이콘

Apple은 글로벌 시장을 위한 앱 준비에 Xcode, Foundation API, Auto Layout, Unicode 지원, 현지화된 에셋 카탈로그, 방향 인식 심볼 사용을 명시적으로 권장합니다. Android도 마찬가지로 하드코딩된 텍스트와 위치 대신 로케일 인식 리소스, 앱 언어 지원, RTL 인식 레이아웃을 권장합니다.

2. 스토어 등록 정보 현지화

이것은 사용자가 앱을 발견하는 방식입니다:

  • 앱 이름
  • 부제목 또는 짧은 설명
  • 전체 설명
  • 키워드
  • 스크린샷
  • 앱 미리보기 또는 프로모션 동영상

이것을 별도의 산출물로 취급하세요. 잘 현지화된 앱도 제품 페이지가 일반적이거나, 번역되지 않았거나, 타겟 시장과 시각적으로 맞지 않으면 성과가 저조할 수 있습니다.

번역이 아닌 국제화부터 시작하세요

번역은 구조에서 시작되는 파이프라인의 마지막 단계입니다.

문자열을 외부화하고 완전한 폴백 로케일을 유지하세요

Android에서 Google은 기본 res/values/strings.xml이 앱에 필요한 모든 문자열을 정의해야 한다고 경고합니다. 기본 파일이 불완전하고 기기가 지원하지 않는 로케일에서 실행되면, 앱이 로드에 실패하고 강제 종료 버튼이 있는 에러를 표시할 수 있습니다. 그렇기 때문에 현지화는 언어 선택이 아닌 리소스 관리에서 시작됩니다.

iOS의 경우, Apple은 사용자에게 보이는 텍스트와 이미지를 실행 코드에서 분리하여 리소스 파일로 현지화할 수 있도록 권장합니다. 최신 Apple 워크플로우에서 문자열 카탈로그는 복수형이 포함된 문자열에 대해 Xcode 15 이상에서 권장되는 접근 방식입니다.

실용적인 규칙:

  • UI 텍스트를 뷰나 컨트롤러에 하드코딩하지 마세요
  • 하나의 정규 소스 언어를 유지하세요
  • 모든 사용자 대면 문자열에 안정적인 키, 컨텍스트, 폴백이 있는지 확인하세요
  • 모호한 문자열에는 번역자 코멘트를 포함하세요

간단한 예시를 통해 더 쉽게 이해할 수 있습니다.

Android는 보통 기본 strings.xml 파일로 시작합니다:

<!-- Primary CTA on the checkout screen. Keep it short. -->
<string name="checkout_cta">Pay now</string>
<string name="welcome_title">Welcome back, %1$s</string>

그런 다음 UI는 영어를 하드코딩하는 대신 리소스를 읽습니다:

Text(text = stringResource(R.string.checkout_cta))

Apple 플랫폼에서 Xcode 15 이상은 종종 문자열 카탈로그에서 같은 개념을 관리합니다. 간소화된 Localizable.xcstrings 발췌는 다음과 같을 수 있습니다:

{
  "sourceLanguage": "en",
  "strings": {
    "Pay now": {
      "localizations": {
        "en": { "stringUnit": { "value": "Pay now" } },
        "fr": { "stringUnit": { "value": "Payer maintenant" } }
      }
    }
  }
}

파일 형식을 외울 필요는 없습니다. 운영상의 교훈은 더 간단합니다: 모든 사용자 대면 문자열에는 하나의 진실 소스, 번역자를 위한 충분한 컨텍스트, 로케일이 불완전할 때의 안전한 폴백이 필요합니다.

앱이 구조화된 언어 파일도 함께 출시한다면, 2026년 최고의 JSON 번역기 가이드가 자동화와 형식 보존에 대한 방향을 잡는 데 도움이 될 수 있습니다.

앱 리소스 파일을 위한 직접적인 도구 옵션을 원한다면, OpenL JSON Translator를 살펴볼 만합니다. 키나 구조를 손상시키지 않고 .json 파일을 번역하도록 설계되었으며, 이는 앱 문자열이 기계 판독 가능한 현지화 파일에 저장될 때 정확히 필요한 기능입니다. 워크플로우는 간단합니다: 앱, CMS 또는 현지화 파이프라인에서 내보낸 JSON을 업로드하고, 대상 언어를 선택하고, 동일한 구조의 번역된 JSON 파일을 다운로드합니다. 제품 페이지에 따르면 100개 이상의 언어와 최대 50MB 파일을 지원하므로, 구조화된 콘텐츠를 처리하는 앱 현지화 팀에 실용적인 초벌 번역 도구입니다.

앱 수준 언어 선택 지원

사용자들은 점점 더 기기 언어와 별도로 앱 언어를 선택할 수 있기를 기대합니다.

Apple 플랫폼에서 사용자는 기기 언어와 독립적으로 앱의 선호 언어를 선택할 수 있습니다. Android에서는 Android 13이 중앙화된 앱 언어 설정을 추가했으며, Google은 자동 앱별 언어 지원을 활성화하거나 공식 API에 피커를 연결할 것을 권장합니다.

이것은 실제 제품에서 중요합니다. 이중 언어 및 다국어 사용자는 폰을 영어로 유지하면서도 쇼핑, 뱅킹 또는 배달 앱은 다른 언어로 사용하고 싶어할 수 있습니다. 앱이 하나의 언어 모델만 강제한다면, 번역 품질이 문제가 되기도 전에 마찰을 만들고 있는 것입니다.

플랫폼 현지화 스택 사용

정말로 필요하지 않다면 별도의 현지화 시스템을 만들고 싶은 유혹을 참으세요.

대부분의 팀에게 기본 플랫폼 스택이면 충분합니다:

  • iOS: 문자열 카탈로그, Localizable.strings, .stringsdict, Foundation 포매터, Auto Layout
  • Android: res/values/, 로케일별 리소스 폴더, LocaleConfig, setApplicationLocales(), supportsRtl

커스텀 현지화 인프라는 매우 큰 규모에서 의미가 있지만, 운영 오버헤드를 추가합니다. 네이티브 시스템으로 시작하고, 실제로 불편함을 느끼는 부분만 확장하세요.

대부분의 팀이 놓치는 부분을 현지화하세요

팀들은 종종 보이는 문장을 번역하고 그 주변의 제품 메커니즘을 놓칩니다.

복수형, 변수, 문법

복수형 규칙은 보편적이지 않습니다. Unicode CLDR 복수형 규칙은 zero, one, two, few, many, other와 같은 카테고리를 정의하며, 언어마다 다른 하위 집합을 사용합니다. Apple은 이전 .stringsdict 워크플로우에서 other만 필수 카테고리이지만, 언어별 카테고리를 건너뛰면 문법적으로 잘못된 결과가 나올 수 있다고 설명합니다. Android와 iOS 모두 로케일 인식 복수형 처리에 의존하는 데에는 이유가 있습니다.

이 부분에서 단순한 기계 번역은 실패합니다:

  • 1 file vs 2 files는 영어에서는 쉽습니다
  • 슬라브어족 언어는 종종 두 개 이상의 복수형이 필요합니다
  • 일부 언어는 명사, 동사 또는 주변 단어를 함께 변경합니다

"You have " + count + " messages"와 같이 조각을 연결하여 복수형 UI를 만들지 마세요. 대신 플랫폼 복수형 리소스를 사용하세요.

각 플랫폼에서의 최소 형태는 다음과 같습니다.

Android:

<plurals name="files_remaining">
  <item quantity="one">%1$d file remaining</item>
  <item quantity="other">%1$d files remaining</item>
</plurals>
Text(text = pluralStringResource(R.plurals.files_remaining, count, count))

iOS 레거시 .stringsdict 예시:

<plist version="1.0">
<dict>
  <key>%#@files@</key>
  <dict>
    <key>NSStringLocalizedFormatKey</key>
    <string>%#@files@</string>
    <key>files</key>
    <dict>
      <key>NSStringFormatSpecTypeKey</key>
      <string>NSStringPluralRuleType</string>
      <key>NSStringFormatValueTypeKey</key>
      <string>d</string>
      <key>one</key>
      <string>%d file remaining</string>
      <key>other</key>
      <string>%d files remaining</string>
    </dict>
  </dict>
</dict>
</plist>

Xcode 15 이상에서 Apple은 대신 문자열 카탈로그에서 복수형을 처리할 것을 권장하지만, 원칙은 동일합니다: 플랫폼에 하나의 메시지 패턴을 제공하고 올바른 언어 형태를 선택하게 하세요.

플레이스홀더와 구조화된 문자열에 대한 더 깊은 워크플로우 가이드라인은 코드를 깨뜨리지 않고 기술 문서를 번역하는 방법을 참조하세요.

날짜, 숫자, 통화, 단위

Apple은 로케일 간에 날짜, 길이, 무게, 가격, 통화 기호를 포맷하기 위해 Foundation API를 사용할 것을 명시적으로 권장합니다. Android에서도 같은 원칙이 적용됩니다: 구두점, 소수점, 단위 순서를 하드코딩하는 대신 로케일 인식 API로 데이터를 포맷하세요.

일반적인 실패 사례:

  • 03/04/2026이 지역마다 다른 의미를 갖는 것
  • USD가 아닌 시장에서 달러 기호를 하드코딩하는 것
  • 쉼표를 소수점 구분자로 사용하는 로케일에서 1,234.56이 잘못 표시되는 것
  • 잘못된 단위 시스템으로 표시되는 측정 단위

앱에 일정, 결제, 배송 기간 또는 분석 기능이 포함되어 있다면, 이것은 마무리 작업이 아니라 현지화의 일부입니다.

레이아웃 확장과 오른쪽에서 왼쪽 지원

영어는 보통 간결합니다. 독일어는 더 길어집니다. 아랍어와 히브리어는 읽기 방향이 반대입니다. 영어에서 잘 보이는 레이아웃이 다른 로케일에서는 심하게 깨질 수 있습니다.

Apple은 실제 번역을 가져오기 전에 오른쪽에서 왼쪽 의사 언어와 더블 길이 의사 언어를 포함한 의사 언어로 테스트할 것을 권장합니다. Android는 left와 right 대신 start와 end를 사용하고, android:supportsRtl="true"를 활성화하며, Force RTL로 기기에서 RTL 레이아웃을 테스트할 것을 권장합니다.

여기서의 체크리스트는 간단합니다:

  • 버튼과 레이블이 늘어날 수 있도록 허용하세요
  • 중요한 UI에 고정 너비 텍스트 컨테이너를 피하세요
  • 적절한 경우 방향성 UI를 미러링하세요
  • RTL에서 아이콘, 셰브론, 진행 흐름, 캐러셀을 확인하세요
  • 라틴 문자 제품 이름이나 쿠폰 코드가 포함된 아랍어 UI와 같은 혼합 방향 텍스트를 테스트하세요

이미지, 아이콘, 스크린샷, 비디오

Apple의 현지화 가이드에는 많은 팀이 간과하는 중요한 점이 있습니다: 이미지도 현지화할 수 있다는 것입니다. 여기에는 이미지 세트, 심볼 세트, 커스텀 심볼의 방향성이 포함됩니다. 스크린샷에 영어 UI, 배너의 영어 텍스트, 또는 왼쪽에서 오른쪽 화살표가 포함되어 있다면, 스크린샷 자체가 현지화되지 않은 것입니다.

이것은 온보딩 화면, 튜토리얼 카드, App Store 자산에서 특히 중요합니다. 사용자는 “마케팅 비주얼”과 “제품 언어”를 정신적으로 분리하지 않습니다. 전체 경험을 한꺼번에 판단합니다.

App Store와 Google Play 페이지를 별도로 현지화하세요

여기서 많은 팀이 인앱 작업을 잘 수행한 후에도 설치를 놓칩니다.

계획해야 할 App Store 요구 사항

Apple은 앱 설명, 키워드, 앱 미리보기, 스크린샷을 포함하여 App Store Connect에서 메타데이터를 현지화할 것을 권장합니다. Apple은 또한 제품 페이지에 최대 10개의 스크린샷을 표시할 수 있으며, 지원되는 기기 크기와 언어당 최대 3개의 앱 미리보기를 사용할 수 있다고 말합니다. 앱 미리보기는 최대 30초 길이이며, 미리보기가 없을 때 스크린샷이 더 중요해지는데, 처음 1~3개의 스크린샷이 검색 결과에 표시될 수 있기 때문입니다.

이것은 두 가지 시사점을 갖습니다:

  1. 첫 번째 스크린샷은 단순한 문서가 아닌 발견 가능성 자산입니다.
  2. 모든 곳에 영어 자산을 재사용하는 대신 최우선 시장을 위해 스크린샷과 미리보기를 현지화해야 합니다.

계획해야 할 Google Play 요구 사항

Google Play도 등록 정보 현지화를 자체 워크플로우로 취급합니다. Play Console에서는 현지화된 텍스트, 해당 언어 스크린샷, 현지화된 그래픽 자산을 추가할 수 있습니다. 현지화된 그래픽 자산 없이 텍스트 번역만 추가하면, Google은 기본 언어 비주얼이 여전히 표시될 것이라고 말합니다.

Google은 또한 자체 스토어 등록 번역을 추가하지 않으면, 사용자에게 자동으로 생성되었다는 알림과 함께 자동 번역이 표시될 수 있다고 언급합니다. 이것은 폴백으로는 유용하지만, 강력한 시장 진입 전략은 아닙니다.

특히 관련성 있는 현재 기능: Play Console은 Gemini 모델을 사용하여 무료로 앱 문자열을 지속적으로 번역할 수 있다고 합니다. 더 구체적으로, Google은 이것이 초안 릴리스에 업로드된 앱 번들의 strings.xml 앱 문자열에 적용되며, 게시 전에 내장 에뮬레이터에서 생성된 번역을 미리 볼 수 있다고 말합니다. 초벌 번역 커버리지를 높이는 강력한 방법이지만, 중요한 흐름에 대해서는 여전히 사람의 검토가 필요합니다.

릴리스 및 QA 워크플로우 구축

좋은 현지화 프로세스는 더 빠르게 번역하는 것보다 더 적은 예상치 못한 문제를 출시하는 것에 관한 것입니다.

1단계. 타겟 로케일을 신중하게 선택하세요

“모든 것을 20개 언어로 번역”하는 것부터 시작하지 마세요.

다음부터 시작하세요:

  • 현재 다운로드 구성
  • 적극적으로 지원하는 국가
  • 결제, 법률, 고객 지원 범위
  • 앱과 스토어 등록 정보를 함께 현지화할 수 있는지 여부

하나의 시장을 엔드투엔드로 출시하는 것이 보통 5개 시장을 절반만 출시하는 것보다 낫습니다.

2단계. 현지화 준비된 자산 만들기

번역 시작 전에 다음을 확정하고 준비하세요:

  • 컨텍스트가 포함된 소스 문자열
  • 로케일별 스크린샷 목록
  • 용어집과 제품명 규칙
  • 플레이스홀더 규칙
  • 스토어 문구의 글자 수 제한 가이드
  • 로케일별 검토 담당자

앱이 별도의 저장소나 여러 파일 형식을 사용하는 경우, 이름 지정과 추출을 초기에 표준화하세요.

3단계. 먼저 의사 현지화로 테스트하세요

Apple 플랫폼에서는 더블 길이 및 오른쪽에서 왼쪽 의사 언어를 사용하세요. Android에서는 지원되지 않는 로케일, Force RTL, 앱 언어 설정을 테스트하세요. 이를 통해 다음을 발견할 수 있습니다:

  • 잘린 버튼
  • 잘린 헤더
  • 숨겨진 텍스트
  • 잘못된 정렬
  • 현지화되지 않은 문자열
  • 하드코딩된 왼쪽/오른쪽 가정

이것은 실행할 수 있는 가장 비용 효율적인 QA 패스 중 하나입니다.

4단계. 실제 기기에서 언어 QA 실행

번역이 완료된 후:

  • 각 타겟 언어에서 중요 흐름을 테스트하세요
  • 시스템 언어와 앱 언어 동작을 비교하세요
  • 복수형 동작과 플레이스홀더를 확인하세요
  • 결제, 날짜, 주소를 확인하세요
  • 시장 내 스크린샷과 스토어 등록 정보를 검토하세요

온보딩, 결제, 본인 인증 또는 알림에 영향을 미치는 버그는 릴리스 차단 요소로 취급하세요.

첫 현지화 스프린트 체크리스트

첫 번째 본격적인 출시라면, 깔끔하게 완료할 수 있을 만큼 스프린트를 작게 유지하세요:

  • 10개가 아닌 1개의 타겟 로케일을 선택하세요.
  • 하나의 릴리스 브랜치에 대한 소스 문자열을 확정하세요.
  • 모든 온보딩, 결제, 계정, 알림 문자열을 컨텍스트 코멘트와 함께 내보내세요.
  • App Store와 Google Play를 위해 현지화할 스크린샷을 캡처하세요.
  • 실제 텍스트를 번역자에게 보내기 전에 한 번의 의사 현지화 패스를 실행하세요.
  • 같은 스프린트에서 앱 문자열과 스토어 등록 문구를 번역하세요.
  • 번역을 다시 가져와서 iOS와 Android 모두에서 앱 언어 전환을 테스트하세요.
  • 실제 기기에서 상위 5개 사용자 여정을 QA하세요.
  • 같은 로케일에 대해 스크린샷, 앱 미리보기, 스토어 메타데이터를 업데이트하세요.
  • 먼저 TestFlight 또는 내부 트랙에 출시한 다음, 지원 티켓과 크래시 리포트를 모니터링하세요.

이 체크리스트는 의도적으로 좁습니다. 깔끔한 앱 경험과 동기화된 스토어 자산을 갖춘 하나의 로케일은 여러 시장에 걸친 급하게 진행된 출시보다 훨씬 더 많은 것을 가르쳐줍니다.

실제 사례

위의 핵심 아이디어는 이론적인 것이 아닙니다.

DoorDash는 번역을 플랫폼 문제로 구축했습니다

2022년 DoorDash는 이미 4개 언어에 걸쳐 100만 개 이상의 문자열을 번역했으며, 새 언어 온보딩을 개발자의 수시간 작업에서 1분 만에 단일 명령으로 줄였다고 밝혔습니다. 흥미로운 교훈은 단순히 규모가 아닙니다. 구조입니다: DoorDash는 정적 문자열과 동적 문자열을 분리하고, 용어집과 스타일 가이드 지원을 추가했으며, 번역되지 않은 문자열이 빠져나가지 않도록 가이드라인을 구축했습니다.

2026년 2월 2일 DoorDash 블로그 포스트에서 회사는 재구축된 온보딩 플랫폼이 이제 모든 DoorDash 시장의 가입을 지원하며 원활한 현지화를 통한 빠른 국제 출시를 지원한다고 밝혔습니다. 이것이 바로 성숙한 현지화의 모습입니다: 재사용 가능한 워크플로우, 지역 유연성, 더 적은 일회성 해결책.

Meta는 현지화를 언어 문제이자 앱 크기 문제로 취급했습니다

Meta에 따르면 Facebook for Android 사용자의 약 57%와 Facebook for iOS 사용자의 49%가 영어 이외의 언어로 앱을 사용합니다. 같은 글에서 Meta는 번들된 번역 파일을 제거하여 iOS 앱에서 최대 16.6MB를 절약했으며, Android에서는 앱 크기를 늘리지 않고 거의 12개의 추가 언어를 지원할 수 있었다고 밝혔습니다.

교훈은 소규모 팀에도 유용합니다: 현지화에는 엔지니어링적 결과가 있습니다. 바이너리 크기, 런타임 로딩, 번역 전달, 릴리스 메커니즘에 영향을 미치며, 단순히 카피라이팅에만 국한되지 않습니다.

출시 전 최종 체크리스트

마지막 점검으로 사용하세요:

  • 모든 사용자 대면 문자열이 외부화되어 있습니다.
  • 기본 폴백 리소스가 완전합니다.
  • 복수형과 플레이스홀더가 플랫폼 네이티브 현지화 지원을 사용합니다.
  • 날짜, 시간, 숫자, 통화, 단위가 로케일 인식됩니다.
  • RTL 레이아웃과 혼합 방향 텍스트가 테스트되었습니다.
  • 스토어 등록 텍스트가 타겟 시장에 맞게 현지화되었습니다.
  • 스크린샷과 미리보기가 우선 언어에 맞게 현지화되었습니다.
  • iOS와 Android에서 인앱 언어 선택이 예상대로 작동합니다.
  • 언어 QA가 가장 중요한 사용자 여정을 다루었습니다.

마무리

모바일 앱 현지화를 생각하는 가장 간단한 방법은 다음과 같습니다: 제품을 번역하고, 경험을 현지화하고, 릴리스를 테스트하세요.

처음 하는 것이라면, 첫날부터 완벽한 글로벌 커버리지를 목표로 하지 마세요. 하나 또는 두 개의 전략적 로케일을 선택하고, 앱과 스토어 페이지를 함께 현지화하고, 철저한 QA 패스를 실행하고, 실제 사용에서 배우세요. 이미 리소스 파일과 개발자 대면 콘텐츠를 관리하고 있다면, 이 워크플로우를 코드를 깨뜨리지 않고 기술 문서를 번역하는 방법과 2026년 최고의 JSON 번역기와 결합하세요.

이번 주에 딱 하나의 행동만 취한다면, 이렇게 하세요: 1개 로케일을 선택하고, 1번의 의사 현지화 패스를 실행하고, 1개의 일치하는 App Store 또는 Google Play 등록 정보를 현지화하세요. 이 세 부분의 테스트는 20개 로케일을 병렬로 번역하는 것보다 준비 상태에 대해 더 많은 것을 알려줄 것입니다.

앱 문구, 스크린샷 또는 구조화된 언어 파일의 빠른 초벌 번역이 필요하다면, 자동화를 사용하여 초안 작업을 가속화한 다음, 릴리스 전에 사람의 QA 단계를 유지하세요. 그것이 사용자 신뢰를 보호하고 “번역은 되었지만 진정으로 현지화되지 않은” 출시를 방지하는 부분입니다.

참고 자료

Tags

i18n how to
Share this post on:
Share this post on X Share this post on Facebook Share this post via WhatsApp

Related Posts

글로벌 마켓플레이스를 위한 아마존 상품 페이지 번역 방법

글로벌 마켓플레이스를 위한 아마존 상품 페이지 번역 방법

아마존의 규정을 준수하며 아마존 상품 페이지를 번역하는 방법을 알아보세요. 제목 정책, 브랜드 분석, A+ 콘텐츠, 출시 전 QA 등을 포함합니다.

2026/3/24
출생증명서 번역 방법

출생증명서 번역 방법

이민, 비자 신청, 법적 제출을 위한 출생증명서 번역 단계별 가이드. 국가별 공인 번역 요건과 자주 발생하는 반려 실수까지 설명합니다.

2026/3/6
졸업증명서 번역 방법

졸업증명서 번역 방법

이민, 대학 입학 또는 해외 취업을 위해 공인된 졸업장 번역이 필요하신가요? 여기에서 인증, 공증, 아포스티유의 절차와 국가별 규정, 그리고 거절을 피하기 위한 팁을 안내해드립니다.

2026/1/25