자막이 깨져요? 한글 자막 인코딩 깨짐 해결 (UTF-8 vs EUC-KR/CP949, 모지바케)

자막 파일을 열었더니 타임스탬프는 완벽한데 실제 대사가 안녕 이나 café, 혹은 ??? 줄로 나옵니다. 파일이 손상된 것처럼 보이지만 거의 그렇지 않습니다 — 텍스트는 다 그대로 있고, 그저 잘못된 문자 맵으로 디코딩되고 있을 뿐입니다. 이 글은 왜 이런 일이 벌어지는지, 고칠 수 있는 문제인지 정말로 소실된 건지 구별하는 법, 그리고 깨끗한 텍스트를 되살리는 정확한 방법을 설명합니다.

'인코딩'이 정확히 무엇인가

자막 파일은 디스크 위의 바이트일 뿐입니다. 문자 인코딩은 그 바이트를 읽을 수 있는 글자로 바꾸는 변환표입니다. 같은 바이트라도 어떤 표를 쓰느냐에 따라 완전히 다른 글자가 됩니다 — 그래서 한 인코딩으로 쓴 파일을 다른 인코딩으로 읽으면 모든 비영어 문자가 엉뚱하게 나옵니다. 이 불일치가 문제의 전부이고, 파일 자체는 멀쩡합니다.

마주치는 인코딩은 크게 두 갈래입니다.

• UTF-8 — 현대의 보편 인코딩. 세상의 모든 언어를 표현할 수 있고, 지금의 모든 플레이어·편집기·플랫폼이 기대하는 형식입니다. 비영어 문자는 글자당 여러 바이트를 차지합니다.
• 레거시 코드페이지 — UTF-8 이전의 지역별 표로, 각각 하나의 언어군만 담습니다.
  • 한글: EUC-KR, CP949(UHC / Windows-949라고도 함, EUC-KR의 상위 집합)
  • 일본어: Shift-JIS (CP932)
  • 중국어 간체: GB2312 / GBK (CP936) / GB18030 (GBK의 하위 호환 슈퍼셋, CP936과 동일하지 않음)
  • 중국어 번체: Big5 (CP950)
  • 서유럽어: Windows-1252 / ISO-8859-1 (Latin-1)
  • 키릴: Windows-1251

모지바케(mojibake) — 이 현상을 가리키는 일본어에서 온, 이제는 표준이 된 용어 — 는 이 중 하나로 쓴 파일을 다른 것으로 읽을 때마다 발생합니다.

30초 진단: 깨진 글자가 알려주는 것

어떤 종류의 깨짐이냐가 텍스트를 되살릴 수 있는지를 알려줍니다.

보이는 모습	의미	복구 가능?
읽히지만 엉뚱한 글자: 안녕, café, при	모지바케 — 바이트는 맞고 디코더가 틀림	가능 — 올바른 인코딩으로 다시 디코딩
파일에 박힌 ? 또는 �(대체 문자)	이전 저장이 손실 변환 — 원래 바이트 소실	대개 불가 — 원본에서 다시 내보내기
빈 네모 / '두부': □ □ □	인코딩이 아니라 폰트 누락	해당 없음 — 글리프 있는 폰트 설치·임베드

첫 번째 줄이 압도적으로 흔하고, 완전히 고칠 수 있습니다. 핵심은 모지바케가 서로 반대인 두 방향으로 일어나며, 깨진 모습이 어느 쪽인지 — 따라서 해결책을 — 알려준다는 점입니다.

UTF-8을 서유럽 코드페이지로 읽음 → 악센트 라틴 잡탕. 파일은 이미 UTF-8인데 플레이어·편집기가 Windows-1252로 디코딩하는 경우입니다:

• UTF-8 한글 파일은 안녕 으로 보입니다(한글 한 글자의 여러 UTF-8 바이트가 각각 별개의 라틴 기호로 그려짐) — 올바르게 한 번 다시 읽으면 원래 한글이 돌아옵니다.
• UTF-8 café 는 café 로 보입니다 — é(UTF-8 두 바이트 C3 A9)가 é(C3→Ã, A9→©)로 갈라지는 전형적 패턴.

바이트는 이미 맞으니, 해결책은 그저 도구가 파일을 UTF-8 로 읽게 하는 것입니다.

레거시 코드페이지를 UTF-8로 읽음 → 그 반대이며, 한글·일본어·중국어 자막이 깨지는 흔한 원인입니다: 오래된 EUC-KR/CP949, Shift-JIS, Big5 파일을 UTF-8 도구로 열면 � 마크나 깨진 글자가 나옵니다. 이때는 그 레거시 코드페이지를 지정해 다시 연 뒤 UTF-8로 저장합니다.

결정적으로, 어느 경우든 타임스탬프는 깨끗하게 남습니다. SRT의 구조를 이루는 바이트 — 숫자, 타임스탬프의 : 와 ,, --> 화살표, 줄바꿈 — 가 UTF-8과 이 레거시 코드페이지들에서 같은 문자로 매핑되기 때문입니다. 타이밍은 깨끗한데 글자만 깨졌다 = 인코딩 문제, 끝.

복구 가능한 모지바케 고치기

해결 방식은 늘 같은 모양입니다: 파일의 실제 인코딩(위 두 경우에 따라 UTF-8 또는 레거시 코드페이지)을 지정해 다시 열고, 텍스트가 제대로 읽히는지 확인한 뒤, UTF-8로 저장합니다. 가진 도구로, 미리보기가 맞을 때까지 인코딩을 바꿔 가며 하세요.

자막 인코딩 변환기 (무료, 브라우저에서 바로)

설치가 전혀 필요 없는 가장 빠른 방법입니다: 자막 인코딩 변환기 를 열고 깨진 파일을 업로드한 뒤, 미리보기가 제대로 읽힐 때까지 원본 인코딩 — EUC-KR/CP949, Shift-JIS, GB18030/GBK, Big5, Windows-1252/1251 — 을 바꿔 보고, 깨끗한 UTF-8(BOM 없음)로 내려받으면 됩니다. 모든 처리가 브라우저 안에서만 일어나 파일이 기기를 떠나지 않습니다. 데스크톱 편집기가 더 편하면 아래 도구들도 같은 일을 합니다:

Subtitle Edit (무료, Windows)

자동 감지로 파일을 엽니다. 잘못 추측했다면 상단의 인코딩 드롭다운으로 올바른 코드페이지로 바꿔 미리보기가 제대로 읽힐 때까지 맞춘 뒤, File → Save As 에서 UTF-8 을 고릅니다. 가장 확실한 클릭 방식.

Notepad++ (무료, Windows)

1. 파일을 엽니다. Encoding → Character sets → 텍스트가 읽히게 만드는 코드페이지의 지역을 고릅니다(예: 오래된 CP949 파일이면 Korean → EUC-KR) — 기존 바이트를 다시 해석합니다. 파일이 실제로는 UTF-8인데 라틴 잡탕으로 보인다면 Encoding → UTF-8 로 다시 해석하세요.
2. 텍스트가 이제 제대로 읽히는지 확인합니다.
3. Encoding → Convert to UTF-8 ('UTF-8-BOM'이 아니라).
4. 저장합니다.

VLC (모든 플랫폼)

설정 → 자막 / OSD → 기본 인코딩 → 파일의 실제 코드페이지로 설정합니다(예: 한국어 (EUC-KR/CP949)). 단, 이건 재생 중 표시만 고치고 파일을 다시 쓰지는 않으므로 다른 앱은 여전히 원래 바이트를 봅니다.

iconv (명령줄, macOS/Linux)

iconv -f EUC-KR -t UTF-8 broken.srt > fixed.srt

필요에 따라 EUC-KR 을 SHIFT-JIS, GBK, BIG5, WINDOWS-1252 등으로 바꾸세요.

무엇을 쓰든 BOM 없는 UTF-8 으로 저장하세요(아래 참고). 파일이 깨끗한 UTF-8이 되면 나머지 도구가 정상 동작합니다 — VTT로 변환하거나, 플레인 텍스트 대본 추출, 혹은 타이밍도 어긋났다면 싱크 맞추기까지.

무료 SRT → 텍스트 추출기 열기파일이 깨끗한 UTF-8이 되면 타임코드를 떼어 복사용 대본으로 — 브라우저에서 바로→

BOM 함정

UTF-8로 저장할 때 일부 편집기는 BOM(Byte Order Mark) — 파일 맨 앞의 보이지 않는 3바이트(EF BB BF) — 를 붙입니다. UTF-8에는 필요 없고, SRT에서는 오히려 문제를 일으킵니다. BOM이 첫 큐 번호 바로 앞에 놓이는 탓에 일부 파서가 1번 큐를 인식하지 못하거나 첫 자막 앞에 (그 3바이트가 서유럽 문자로 그려진 것) 같은 이상한 문자가 보입니다.

편집기가 둘 다 제공하면 항상 "UTF-8" 을 고르고 "UTF-8 with BOM" / "UTF-8-BOM" 은 피하세요. Notepad++에서는 Encoding → Convert to UTF-8 이 BOM 없는 쪽입니다.

텍스트가 정말로 사라진 경우

파일에 이미 글자 그대로의 ? 나 � 가 — 화면 표시 아티팩트가 아니라 바이트로 — 들어 있다면, 어딘가 상류에서 어떤 도구가 그 문자를 표현할 수 없는 인코딩으로 파일을 다시 저장하면서 각 문자를 자리표시자로 바꾼 것입니다. 이 변환은 손실이고 일방향입니다. 원래 문자는 이 파일에 더는 존재하지 않으며, 아무리 다시 디코딩해도 돌아오지 않습니다.

그 시점의 선택지:

• 원본에서 자막을 다시 받거나 다시 내보내기 — 이번엔 UTF-8로 저장.
• 영상을 새로 전사 — 깨진 파일을 통째로 건너뜀.

한글(그리고 CJK) 자막을 위한 메모

이 문제는 한글·일본어·중국어 자막 파일에서 가장 흔합니다. 이 언어들은 UTF-8 이전부터 널리 쓰인 레거시 코드페이지(EUC-KR/CP949, Shift-JIS, GBK, Big5)를 갖고 있기 때문입니다. 오래된 사이트에서 받았거나 DVD에서 추출한 한글 SRT는 십중팔구 CP949이고, 이를 UTF-8 기본 편집기나 플레이어에서 열면 � 마크나 깨진 글자가 나옵니다. CP949(또는 EUC-KR)로 다시 해석해 UTF-8로 저장하면 영구히 고쳐지고, 이제 모든 현대 플레이어로 이식 가능해집니다.

인코딩 문제를 아예 피하기: 새로 생성

모든 모지바케 골칫거리는 같은 뿌리로 거슬러 올라갑니다 — 어떤 레거시 코드페이지로 저장된 자막 파일을 재사용하는 것이죠. 깔끔한 탈출구는 레거시 인코딩 파일에서 시작하지 않는 것입니다.

음성에서 자막을 생성하면 결과물이 첫 바이트부터 UTF-8 입니다 — 사슬 어디에도 어긋날 지역 코드페이지가 없으니 깨진 글자가 애초에 나타나지 않습니다. Picute는 영상(또는 붙여넣은 유튜브 URL)을 전사해 깨끗한 UTF-8 SRT 와 플레인 텍스트 대본, 선택적 번인 영상을 70개 이상 언어로 제공합니다.

이미 가진 파일을 구제할 땐 위의 다시-디코딩 단계를, 처음부터 ? 를 다시 보고 싶지 않을 땐 새로 생성하세요.

관련 글

• SRT vs VTT vs SBV vs ASS: 자막 포맷 완벽 정리 — 각 포맷이 저장하는 것과 깔끔한 변환법
• 자막 싱크가 안 맞을 때 — 밀림·드리프트 잡기 — "자막 파일이 깨졌다"의 타이밍 쪽 절반
• 장편 영상 자막 완벽 가이드 — 긴 영상용 자막 생성

Picute에서 깨끗한 자막 생성하기업로드 한 번으로 UTF-8 SRT · 전체 대본 · 스타일 번인 · 70개 이상 언어→