ChatGPT 한글 깨짐의 절반은 자음 모음이 분리된 것이에요

파일을 올렸는데 이름이 ㅎㅏㄴㄱㅡㄹ 처럼 흩어져 보인 적 있으신가요? 아니면 분명히 있는 파일인데 이름으로 검색하면 안 나오거나, 목록 정렬이 뒤죽박죽이었던 적이요.

이건 글씨가 깨진 게 아니에요. 같은 한글을 저장하는 방식이 두 가지여서 생기는 일이고, 원인을 알면 한 번에 고칠 수 있어요.

한글을 담는 두 가지 방식

한글 낱자 하나를 컴퓨터에 넣는 방법이 둘 있어요.

• 완성형으로 담기: 한 이라는 완성된 글자를 한 칸에 넣어요.
• 낱자로 담기: 첫 자음 ᄒ, 모음 ᅡ, 끝 자음 ᆫ 을 세 칸에 따로 넣어요.

둘 다 유니코드 표준에 정식으로 들어 있는 방식이고, 화면이 제대로 조립해 주면 둘 다 똑같이 한 으로 보여요. 문제는 조립을 안 해 주는 자리에서 생기죠. 그때 낱자가 하나씩 떨어져 보이는 게 우리가 "깨졌다"고 부르는 그 화면이에요.

실제로 한글 두 글자를 두 방식으로 저장해서 칸을 세어 봤어요.

낱자 쪽 여섯 칸의 정체를 하나씩 확인하니 이렇게 나왔어요. 첫자음 히읗, 모음 아, 끝자음 니은, 첫자음 기역, 모음 으, 끝자음 리을. 유니코드가 첫 자음과 끝 자음을 다른 글자로 취급하는 것도 보이시죠. 같은 니은이라도 첫머리에 오는 것과 받침으로 오는 것이 서로 다른 칸을 씁니다.

용량이 정확히 세 배가 돼요

같은 문장이 방식에 따라 얼마나 달라지는지 직접 세어 봤어요. 2026년 9월 18일 실측값이에요.

받침이 전부 있는 한글 은 6바이트에서 18바이트로 정확히 세 배가 됐어요. 받침이 없는 글자가 섞이면 배수가 조금 내려가요. 안녕하세요 는 받침이 하나뿐이라 15바이트에서 36바이트로 2.4배였어요.

여기서 실무에 영향을 주는 게 글자 수예요. 서울특별시 가 5자로도 세어지고 13자로도 세어져요. 입력 길이 제한이나 글자 수 카운터가 있는 자리에서 같은 문장이 다르게 걸릴 수 있다는 뜻이에요.

검색이 안 되는 진짜 이유

가장 사람을 헷갈리게 하는 증상이 이거예요. 눈으로는 완전히 같은데 컴퓨터는 다르다고 판정해요.

한글 을 두 방식으로 각각 저장해 같은지 비교해 봤더니 결과가 거짓이었어요. 화면에 나란히 놓으면 구분이 안 되는데도요.

목록으로 실험해 보면 더 분명해요. 완성형 나무, 낱자 가지, 완성형 다리 가 섞인 목록을 만들고 가지 를 찾아 봤어요.

• 완성형으로 검색 → 못 찾아요
• 낱자로 검색 → 찾아요

정렬도 같은 이유로 어긋나요. 낱자로 담긴 글자는 낱자 코드 번호 순서로 줄을 서니까, 완성형 글자들 사이에 끼면 예상과 다른 자리에 놓여요.

그래서 파일 이름으로 검색했는데 분명히 있는 파일이 안 나올 때는, 맞춤법이나 띄어쓰기를 다시 보기 전에 이쪽을 먼저 의심하는 게 빠릅니다.

어디에서 주로 생기나

낱자로 흩어진 글자를 만나는 경로가 대체로 정해져 있어요.

맥에서 만든 파일 이름이 가장 흔해요. 맥의 파일 시스템은 한글 파일 이름을 낱자로 나누어 저장하는 쪽을 씁니다. 그 파일을 압축해서 보내거나 웹에 올리면 받는 쪽에서 흩어져 보여요. 반대로 윈도우와 대부분의 웹 서비스는 완성형을 기대해요.

그다음이 압축 파일이에요. 압축할 때의 방식이 그대로 담기므로, 맥에서 압축한 파일을 윈도우에서 풀면 이름이 흩어진 채로 나옵니다.

그리고 웹에서 복사해 붙인 텍스트예요. 복사는 원래 방식을 그대로 가져와요. 그래서 흩어진 글자를 복사해 다른 곳에 붙이면 흩어진 채로 따라갑니다. 이게 문제가 계속 옮겨 다니는 이유예요.

눈으로 구분하는 방법

고치기 전에 지금 내가 보는 게 어느 쪽인지 알아야 하죠. 코드 없이 확인하는 방법이 두 가지 있어요.

첫째, 커서를 옮겨 보세요. 글자 하나를 지나갈 때 화살표를 여러 번 눌러야 넘어가면 낱자로 담긴 거예요. 완성형이면 한 번에 넘어갑니다. 지우기도 같아요. 백스페이스 한 번에 받침만 사라지고 다시 눌러야 글자가 없어지면 그쪽이에요.

둘째, 글자 수 세는 곳에 넣어 보세요. 서울특별시 를 넣었는데 5가 아니라 13이 나오면 낱자로 담긴 상태예요. 위 표의 값과 맞춰 보시면 됩니다.

고치는 방법

방향은 하나예요. 흩어진 것을 완성형으로 합치는 쪽입니다. 이 변환을 유니코드 정규화라고 부르고, 합치는 방식의 이름이 NFC 예요.

파이썬을 쓸 수 있다면 표준 라이브러리 unicodedata 의 normalize 함수에 NFC 를 지정해 문자열을 넣으면 끝이에요. 별도 설치가 필요 없는 기본 모듈이라 바로 됩니다. 파일 이름을 여러 개 고쳐야 하면 같은 변환을 폴더 목록에 돌리면 돼요.

코드를 쓰기 어렵다면 파일 이름을 손으로 다시 타이핑하세요. 새로 입력한 글자는 지금 쓰는 환경의 기본 방식으로 들어가니까 그것만으로 해결돼요. 🔴 다만 복사해서 붙이면 안 돼요. 원래 방식이 그대로 따라옵니다.

애초에 안 만드는 방법도 있어요. 맥에서 파일을 넘길 때 압축하지 않고 하나씩 올리거나, 파일 이름을 영문과 숫자로 두는 거예요. 특히 자동화 흐름에 파일 이름을 키로 쓰는 경우라면 한글 파일 이름 자체를 피하는 게 나중에 원인을 찾는 시간보다 쌉니다.

고칠 수 있는 깨짐과 고칠 수 없는 깨짐

여기가 이 글에서 가장 실용적인 부분일 거예요. 한글이 이상해 보이는 경우가 세 가지인데, 세 가지의 복구 가능성이 완전히 달라요. 한글 파일 을 각각의 상태로 만들어 되돌려 봤어요.

첫째는 이 글이 다룬 경우예요. 합치는 변환을 한 번 거치면 원본과 완전히 같아졌어요.

둘째는 흔히 말하는 글자 깨짐이에요. 낯선 기호가 줄줄이 나오지만 바이트는 그대로 살아 있어요. 읽는 방식만 되돌리면 원본과 정확히 일치했어요.

셋째가 진짜 손실이에요. 잘못 읽은 상태에서 한 번 저장하면 되돌릴 수 없는 글자가 물음표 모양의 대체 문자로 바뀌어 박힙니다. 한글 파일 을 이 경로로 보내니 대체 문자가 4개 생겼고, 되돌려도 원본과 같아지지 않았어요. 그 자리의 한글은 사라진 거예요.

그래서 순서가 중요해요. 이상해 보이는 파일은 저장하거나 덮어쓰지 말고 먼저 원인을 판정하세요. 낱자로 흩어진 첫째 경우와 기호가 나오는 둘째 경우는 원본이 무사하지만, 그 상태에서 저장 버튼을 누르는 순간 셋째로 넘어갈 수 있어요.

낱자를 직접 타이핑해서 고칠 수 없는 이유

한 가지 함정을 더 적어 둘게요. 흩어진 글자를 보고 키보드로 ㅎ ㅏ ㄴ 을 쳐서 맞추려는 시도는 안 통해요.

유니코드에 한글 낱자가 두 벌 있기 때문이에요. 조립용 낱자와, 낱자 자체를 표시하기 위한 낱자가 따로 있어요.

키보드로 치는 ㄱ 은 U+3131 이고, 흩어진 파일 이름에 들어 있는 것은 U+1100 이에요. 눈에는 같아 보이지만 다른 글자라 바꿔 써도 합쳐지지 않아요. 구간으로 정리하면 조립용 첫 자음이 U+1100부터, 모음이 U+1161부터, 받침이 U+11A8부터 시작하고, 완성형 음절은 U+AC00부터 U+D7A3까지 11,172자예요.

이게 "겉보기로 고치는 방법"이 전부 실패하는 이유예요. 정규화 변환을 거치거나, 아예 새로 타이핑하는 것 둘 중 하나여야 해요.

이 글이 재지 않은 것

정직하게 적어 둘게요.

• 바이트와 글자 수만 쟀어요. 낱자로 담긴 문장이 모델에서 토큰을 몇 개 먹는지는 재지 않았어요. 바이트가 세 배라고 해서 토큰도 세 배라고 단정할 수 없어요.
• 특정 서비스의 동작을 시험하지 않았어요. 어떤 서비스가 업로드 시점에 알아서 합쳐 주는지는 서비스마다 다르고 수시로 바뀌어요. 위 실측은 유니코드 자체의 성질이고, 그 성질이 어디에서 드러나느냐는 받는 쪽 구현에 달려 있어요.
• 표의 배수는 받침 비율에 따라 달라져요. 받침이 없는 글자만 있으면 두 배에 가깝고, 전부 받침이 있으면 세 배에 가까워요.

파일을 올려 작업할 때 미리 정리해 두면 좋은 것들은 ChatGPT 데이터 전처리 전략 쪽에, 자동화 흐름에서 같은 데이터가 두 번 처리되는 문제는 자동화 중복 실행 막는 5가지 쪽에 정리해 두었어요.

정리하면 이래요. 자음 모음이 흩어져 보이는 것은 손상이 아니라 조립되지 않은 상태예요. 글자 정보는 그대로 있고, 정규화 한 번으로 합쳐집니다. 그리고 그 상태에서 생기는 진짜 피해는 보기 흉한 게 아니라 검색과 정렬과 글자 수가 조용히 어긋나는 것이에요.