터미널 한글 깨짐, 3층위로 구분하기 — 명령이 실행되느냐로 원인을 가른다

“한글이 깨진다”, “영문이 넓게 벌어진다”는 하나의 증상처럼 보이지만 원인이 다른 세 층위가 섞여 있다. 층위를 먼저 구분하지 않으면 폰트를 바꾸거나 인코딩을 만졌다가 엉뚱한 곳만 건드리게 된다. 어느 층에서 깨지는지 가르는 법부터 정리한다.

결론 먼저

층위	증상	원인	구분점	해결
1. 코드페이지	출력이 ???나 엉뚱한 글자	쓴 인코딩 ≠ 읽는 인코딩	출력이 깨짐 (입력은 정상)	chcp 65001 등으로 양쪽 맞춤
2. IME·PSReadLine	자모가 풀리거나(ㅎㅏㄴㄱㅡㄹ) 글자가 겹침	조합 중 글자와 예측 입력 충돌	타이핑 중 조합 단계에서 깨짐	Set-PSReadLineOption -PredictionSource None
3. 전각 문자	영문이 2칸씩 넓어지고 명령이 안 먹힘	입력 문자 자체가 전각(U+FF45 계열)	명령이 실행되지 않음	IME 전각 모드 해제 (Shift+Space)

가장 헷갈리는 건 “영문이 넓다”는 표면 증상이다. 모호한 폭(ambiguous width) 설정이나 비고정폭 글꼴로 넓어 보일 수도 있고, 전각 문자가 입력돼도 넓어 보인다. 결정적 구분점은 명령이 실행되느냐다. 글꼴·폭 문제면 글자만 넓을 뿐 exit는 동작하고, 전각 문자면 명령 자체가 다른 코드포인트라 실행이 실패한다.

층위 1: 코드페이지

터미널은 바이트를 문자로 되돌릴 때 “코드페이지”라는 인코딩 규칙을 쓴다. 프로그램이 UTF-8(코드페이지 65001)로 바이트를 뱉었는데 터미널이 CP949(EUC-KR, 949)로 해석하면, 같은 바이트가 엉뚱한 글자나 ???로 나온다. 반대 방향도 마찬가지다. 즉 깨짐은 “쓴 인코딩 ≠ 읽는 인코딩”의 불일치에서 생기지, 데이터 자체가 손상된 게 아니다.

현재 코드페이지는 chcp로 확인한다.

chcp

• 949 — CP949 / EUC-KR (한국어 Windows 기본)
• 65001 — UTF-8

출력한 쪽과 읽는 쪽의 번호가 어긋나 있으면 깨진다. 한쪽을 상대에 맞추면 정상으로 돌아온다.

특정 프로그램(예: lazygit) 맥락에서 코드페이지를 UTF-8로 맞추는 구체적인 사례는 별도 글에서 다뤘다: Neovim에서 lazygit 한글 깨짐.

층위 2: IME·PSReadLine

타이핑 중 “한글”이 “ㅎㅏㄴㄱㅡㄹ”처럼 자모로 분리되거나 글자가 두 번씩 찍히는 건 인코딩이 아니라 입력 조합 단계의 충돌이다. 출력이 깨지는 층위 1과 달리, 여기서는 내가 치는 도중에 화면이 어긋난다.

PowerShell의 PSReadLine 예측 입력(Predictive IntelliSense)이 켜져 있으면, 조합 중인 미완성 한글 글자와 예측 표시가 부딪쳐 이렇게 된다. 한글은 자모를 모아 한 글자를 완성하는 조합형인데, 아직 완성되지 않은 상태에서 예측 텍스트가 같은 자리에 겹쳐 그려지면서 조합이 풀려 보이는 것이다.

예측 입력을 끄면 해결된다.

Set-PSReadLineOption -PredictionSource None

영구 적용은 $PROFILE에 이 줄을 추가한다.

층위 3: 전각 문자

영문이 한 글자당 2칸씩 벌어지고 exit가 not recognized로 튕기면, 입력된 문자 자체가 전각(全角, U+FF45 계열)으로 바뀐 것이다. Shift+Space로 IME 전각 모드를 해제한다. 전각 문자가 왜 명령으로 인식되지 않는지, 진단·해제 방법은 별도 글에서 자세히 다뤘다: Windows Terminal에서 영문이 넓게 나오고 명령어가 안 먹히면 IME 전각 모드.

정리

한글 깨짐은 단일 문제가 아니라 세 층위가 겹쳐 보이는 것이다. 고치기 전에 어디서 깨지는지부터 가른다.

• 출력이 깨지는가 → 층위 1(코드페이지). chcp로 양쪽 인코딩을 맞춘다.
• 타이핑 중 조합이 풀리는가 → 층위 2(IME·PSReadLine). 예측 입력을 끈다.
• 영문이 넓고 명령이 안 먹히는가 → 층위 3(전각 문자). IME 전각 모드를 해제한다.

특히 “영문이 넓다”는 증상은 폰트·전각이 함께 걸려 헷갈리는데, 명령이 실행되느냐를 보면 바로 갈린다.