가이드

작성자 Matt Connor 2026-09-17

Claude Code 터미널에서 한글이 깨지거나 밀릴 때 증상별 해결법

Q: VPS 로케일은 꼭 ko_KR.UTF-8이어야 하나, C.UTF-8로도 되나?

한글이 그려지느냐는 문자 집합이 결정하므로 C.UTF-8로도 된다. 차이는 시스템 메시지와 날짜 형식이 영어로 나온다는 것뿐이다. sudo update-locale LANG=C.UTF-8로 설정하고 다시 로그인한 뒤 locale에 경고가 없으면 끝이다. ko_KR.UTF-8을 쓰려면 sudo locale-gen ko_KR.UTF-8로 먼저 생성해야 하고, 생성 전에 클라이언트가 SendEnv로 그 이름을 보내면 cannot change locale 경고가 나온다.

Q: Shift+Enter가 줄바꿈이 아니라 전송으로 동작한다. 터미널을 바꿔야 하나?

아니다. Ctrl+J나 \ 뒤 Enter는 모든 터미널에서 설정 없이 줄바꿈이다. Shift+Enter를 꼭 쓰고 싶다면 VS Code, Cursor, Zed에서는 /terminal-setup을 한 번 실행하고, tmux 안이라면 ~/.tmux.conf에 set -s extended-keys on과 set -as terminal-features 'xterm*:extkeys'를 넣는다. gnome-terminal과 JetBrains IDE는 문서 기준으로 Shift+Enter가 아예 없다.

조합 중 커서 튐, 중간 수정 시 잔상, SSH VPS의 ?? 표시까지. Claude Code 한글 문제를 증상별로 나누고 공식 문서가 지목한 처방(/tui fullscreen, /terminal-setup, 서버 로케일)을 하나씩 정리했다.

먼저 결론: Claude Code 한글 깨짐은 증상마다 처방이 하나씩이다

Claude Code에서 한글이 깨지는 문제는 원인이 하나가 아니다. 조합 중인 글자가 엉뚱한 자리에 찍히거나 문장 중간을 고칠 때 글자가 밀리고 잔상이 남는다면 Claude Code의 렌더러 문제이고, 처방은 /tui fullscreen이다. Cursor나 VS Code의 통합 터미널에서 글자가 박스나 번짐으로 나온다면 편집기의 GPU 렌더러 문제이고, 처방은 /terminal-setup이다. Windows Terminal에서 이전 출력의 조각이 화면에 남는다면 CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT=1이다. SSH로 접속한 VPS에서 한글이 ?나 빈 박스로 나온다면 서버의 로케일과 tmux 문제이고, Claude Code 쪽 설정으로는 고칠 수 없다.

도구별이 아니라 증상별로 나눈 이유가 있다. 같은 Cursor에서도 조합이 튀는 것과 글자가 박스로 나오는 것은 원인이 다르고, 처방도 다르다. 아래의 Claude Code 관련 내용은 모두 2026-09-17에 읽은 공식 문서의 터미널 설정 페이지와 전체 화면 렌더링 페이지 기준이다. 이 부분은 거의 매달 바뀌므로 claude --version으로 자기 버전을 확인하고 문서를 다시 보는 습관이 필요하다. Claude Code가 처음이라면 Claude Code가 무엇이고 터미널에서 어떻게 동작하는지부터 읽는 편이 빠르다.

증상 1: 조합 중인 글자가 딴 데 찍히고, 문장 중간을 고치면 글자가 밀린다

가장 많이 보고되는 증상이다. "안녕하세요"를 치는데 조합 중인 자소가 입력창이 아니라 화면 구석에 나타났다가, 글자가 완성되어야 제자리에 박힌다. 이미 쓴 문장의 중간으로 커서를 옮겨 한 글자를 고치면 뒤의 글자들이 한 칸씩 밀리거나, 지운 글자가 잔상처럼 남는다. 같은 자리에서 영어로 고치면 멀쩡하다. 터미널 종류와 무관하게 iTerm2, Cursor, Windows Terminal, SSH 너머의 tmux에서 모두 나온다.

공식 문서는 두 렌더러의 차이를 이렇게 설명한다. 기본(classic) 렌더러는 대화를 터미널의 일반 스크롤백에 그리고, 출력이 들어올 때마다 입력창의 위치가 함께 움직인다. 전체 화면(fullscreen) 렌더러는 vim이나 htop처럼 터미널의 대체 화면 버퍼(alternate screen buffer)에 그리고, 입력창은 화면 아래에 고정되며, 문서의 표현대로 "flicker-free"다. 이 차이가 한글 조합에 왜 영향을 주는지는 문서가 직접 말하지 않는다. 한글 IME(input method editor, 입력기)는 조합 중인 글자를 터미널이 알려 주는 커서 위치에 그리는데, 그 커서가 다시 그리기 도중에 계속 움직이면 조합 글자도 따라 움직인다는 것이 사용자들의 분석이다. 이 분석은 우리가 측정한 것이 아니다.

처방은 Claude Code 안에서 이 명령 한 줄이다.

/tui fullscreen

실행하면 tui 설정이 저장되고, 대화가 유지된 채 전체 화면 렌더러로 다시 시작된다. 이후 세션은 전체 화면으로 시작한다. 되돌리려면 /tui default, 지금 어느 렌더러인지 보려면 인자 없이 /tui를 친다. 문서 기준으로 2026년 5월 6일 이후에 처음 쓴 사용자는 이미 전체 화면으로 시작할 수 있으니, /tui가 fullscreen이라고 답하면 이 처방은 이미 적용된 상태다. 시작 전에 환경 변수로 켤 수도 있다.

CLAUDE_CODE_NO_FLICKER=1 claude

PowerShell에서는 문법이 다르다.

$env:CLAUDE_CODE_NO_FLICKER = "1"; claude

매번 치기 싫으면 ~/.claude/settings.json에 넣는다.

{
  "env": {
    "CLAUDE_CODE_NO_FLICKER": "1"
  }
}

전체 화면이 한글 조합을 고쳤다는 것은 사용자 보고다. 고영혁(@Gonnector) 님은 X에 올린 글에서 "터미널상 한글 입력시 자소 단위로 제대로 입력/편집이 안되고 구석탱이에서 한 글자로 완성되어야만 제자리에 박히던 문제가 완전히 해결됐습니다"라고 쓰면서 그 이유를 "새로 추가된 NO_FLICKER 모드"로 지목했다. 이것은 한 사용자의 경험이지 우리가 재현한 결과가 아니고, 공식 문서 자체는 한글이나 IME를 한 번도 언급하지 않는다. 그래도 문서가 이름 붙인 처방과 사용자 보고가 같은 스위치를 가리키므로, 첫 시도로는 이것이 맞다.

같은 증상을 다룬 GitHub 이슈 #5126 "Korean Text Input Rendering Breaks When Editing Mid-Sentence"는 Linux의 Cursor, v1.0.68 환경에서 올라왔고 지금은 닫혀 있다. 스레드 어디에도 어느 버전에서 고쳐졌다는 말은 없다. 그러니 "X 버전부터 해결됐다"는 말은 믿지 말고, 전체 화면에서도 재현되면 Claude Code 안에서 /feedback으로 터미널 이름과 버전을 적어 보내는 것이 문서가 안내하는 경로다.

전체 화면에는 대가가 있다. 대화가 터미널 스크롤백이 아니라 대체 화면 버퍼에 있으므로 터미널의 Cmd+F와 tmux 검색이 대화를 보지 못한다. 대신 Ctrl+O로 transcript 모드에 들어가 /로 검색하고, [를 누르면 대화 전체를 터미널 스크롤백에 써 준다. 마우스도 Claude Code가 잡기 때문에 터미널의 드래그 복사가 바뀐다. 한 번만 터미널 쪽 선택을 쓰려면 Shift를 누른 채 드래그한다(iTerm2는 Option, Terminal.app은 Fn). 마우스 캡처가 계속 거슬리면 CLAUDE_CODE_DISABLE_MOUSE=1을 같이 주면 렌더러는 그대로 두고 마우스만 터미널에 돌려준다.

증상 2: Cursor나 VS Code 통합 터미널에서 글자가 박스, 번짐, 엉뚱한 글자로 나온다

조합이 튀는 것이 아니라 글자 자체가 깨져 보이는 경우다. 공식 문서의 문제 해결 페이지는 이 증상을 이렇게 적는다. "If characters render as boxes, smears, or the wrong glyphs when running Claude Code in the VS Code, Cursor, or Devin Desktop integrated terminal, the terminal's GPU renderer is likely the cause." 통합 터미널의 GPU 렌더러가 원인일 가능성이 높다는 뜻이다.

처방은 Claude Code 안에서 /terminal-setup이다. 단, tmux나 screen 안이 아니라 Cursor의 터미널 탭에서 직접 실행해야 한다. 이 명령은 호스트 터미널의 설정 파일에 써야 하기 때문이다.

/terminal-setup

문서는 이 명령이 VS Code, Cursor, Devin Desktop에서 편집기 설정 두 개를 바꾼다고 명시한다. 하나는 terminal.integrated.gpuAcceleration을 "off"로 바꾸는 것인데, 원문의 이유는 "to prevent garbled text in the integrated terminal"이다. 다른 하나는 전체 화면 모드에서 스크롤을 부드럽게 하는 terminal.integrated.mouseWheelScrollSensitivity다. 처음 실행하면 Installed VSCode terminal Shift+Enter key binding 같은 확인 문구가 뜨고, 이미 되어 있으면 VSCode terminal Shift+Enter key binding already configured가 뜬다. 두 번째 문구가 떴는데 여전히 깨진다면 아래 수동 설정으로 GPU 값이 실제로 "off"인지 확인한다.

수동으로 하려면 편집기의 settings.json에 한 줄을 넣고 창을 다시 연다.

{
  "terminal.integrated.gpuAcceleration": "off"
}

명령 팔레트에서 Developer: Reload Window를 실행해야 적용된다. 되돌리려면 값을 "auto"로 바꾸고 다시 창을 연다.

증상 1과 증상 2가 통합 터미널에서 같이 나타난다면 둘 다 적용한다. /terminal-setup은 편집기의 GPU 렌더러를 끄고, /tui fullscreen은 Claude Code의 렌더러를 바꾼다. 서로 다른 층이라 하나가 다른 하나를 대신하지 못한다. 덤으로 문서는 VS Code 통합 터미널이 아주 큰 붙여넣기에서 글자를 떨어뜨릴 수 있다고 경고하므로, 긴 한글 문서를 붙여 넣다가 뒷부분이 사라지면 파일로 저장해서 읽히는 편이 낫다.

증상 3: Windows Terminal에서 이전 출력의 조각이 화면에 남는다

전체 화면 모드를 켠 뒤, 지나간 출력의 일부가 화면 여기저기 남아 있다가 창 크기를 바꾸면 사라진다. 공식 문서는 이 증상을 이렇게 설명한다. 전체 화면 렌더링은 프레임 사이에 바뀐 셀만 보내는데, "most commonly Windows Terminal and other ConPTY-backed hosts"가 이 위치 지정 쓰기를 잘못 합쳐서 조각을 남긴다. ConPTY(Windows pseudo console)는 Windows Terminal과 PowerShell 창이 콘솔 앱과 이야기하는 계층이다.

처방은 환경 변수 하나다. 매 프레임 모든 셀을 다시 그리게 한다.

$env:CLAUDE_CODE_ALT_SCREEN_FULL_REPAINT = "1"
claude

이 변수는 전체 화면 렌더러에만 의미가 있다. 기본 렌더러에서 조각이 남는다면 증상이 다른 것이니 증상 1로 돌아가 /tui fullscreen부터 켠다.

Windows Terminal에서 한글 조합 자체가 튄다면 그것은 증상 1이고, 첫 처방은 역시 /tui fullscreen이다. 그래도 안 된다는 보고가 GitHub 이슈 #51768에 있다. 그 사용자는 Git Bash를 열어 claude 대신 winpty claude로 실행하는 우회법과 D2Coding 글꼴을 제안했다. 이슈는 "not planned"로 닫혔고, 우회법은 그 사용자의 경험이지 우리가 확인한 것이 아니다.

PowerShell에서 한글이 조합도 안 되고 처음부터 ??로 나온다면 코드 페이지를 확인한다. chcp를 쳐서 활성 코드 페이지 번호를 본다. 65001이면 UTF-8이고, 다른 번호라면 chcp 65001로 바꾼 뒤 claude를 다시 연다. 이 번호가 무엇으로 나오는지는 Windows 버전과 지역 설정에 따라 다르므로 직접 확인해야 한다.

증상 4: SSH로 접속한 VPS에서 한글이 `?`나 빈 박스로 나온다

로컬에서는 멀쩡한데 Ubuntu VPS에 SSH로 들어가 tmux 안에서 Claude Code를 열면 한글이 ?나 빈 박스로 찍힌다. 이것은 Claude Code의 문제가 아니다. 서버에 UTF-8 로케일이 생성되어 있지 않거나, SSH가 LANG을 넘기지 않거나, tmux 서버가 잘못된 환경으로 먼저 떠 있는 것이다. 세 층을 순서대로 확인한다. VPS의 tmux 안에서 Claude Code를 계속 돌리는 구성을 따라 만든 서버라면 그 글의 tmux 세션 만드는 줄에 아래의 -u 한 글자만 보태면 된다.

1단계, 서버 로케일. SSH로 들어간 셸에서 두 명령을 친다.

locale
locale -a

locale의 출력이 무엇으로 나오는지는 이미지와 접속 방식에 따라 다르다. 값을 이렇게 읽는다. LANG=이 비어 있고 LC_CTYPE="POSIX"라면 서버 셸이 글자를 바이트 단위로 다루고 있어서 한글을 그릴 수 없다. LANG=ko_KR.UTF-8인데 locale: Cannot set LC_CTYPE to default locale: No such file or directory 경고가 붙거나, 로그인 직후 -bash: warning: setlocale: LC_ALL: cannot change locale (ko_KR.UTF-8)이 떴다면 클라이언트가 보낸 로케일 이름이 서버에 없는 것이다. 두 경우 모두 로케일을 생성해야 한다. LANG이 .UTF-8로 끝나고 경고가 없고 locale -a 목록에 ko_KR.utf8이나 C.utf8이 있다면 이 단계는 통과이니 3단계로 간다.

생성은 Ubuntu에서 두 줄이다.

sudo locale-gen ko_KR.UTF-8
sudo update-locale LANG=ko_KR.UTF-8

locale-gen: command not found가 나오면 sudo apt install -y locales를 먼저 한다. update-locale은 /etc/default/locale에 값을 쓰고, 다음 로그인부터 적용된다. 로그아웃 후 다시 들어와서 locale을 다시 쳐 보고 경고가 사라졌는지 본다. 한글 표시만 필요하고 시스템 메시지는 영어로 두고 싶다면 sudo update-locale LANG=C.UTF-8도 된다. 한글이 그려지느냐는 언어 부분(ko_KR)이 아니라 문자 집합 부분(UTF-8)이 결정하기 때문이다. C.UTF-8을 따로 생성 없이 쓸 수 있는지는 locale -a에 C.utf8이 보이는지로 판단한다.

2단계, SSH가 로케일을 넘기는가. 로컬 터미널의 echo $LANG과 서버에 들어간 뒤의 echo $LANG을 비교한다. 로컬은 UTF-8인데 서버가 비어 있다면 두 파일 중 하나가 빠진 것이다. 서버 쪽은 /etc/ssh/sshd_config의 AcceptEnv 줄이다.

grep -n AcceptEnv /etc/ssh/sshd_config

AcceptEnv LANG LC_* 줄이 없거나 주석 처리되어 있으면 추가하고 sudo systemctl reload ssh로 반영한다. 클라이언트 쪽은 ~/.ssh/config의 SendEnv다.

Host myvps
  HostName 203.0.113.10
  SendEnv LANG LC_*

순서가 중요하다. 서버에 ko_KR.UTF-8을 생성하기 전에 SendEnv부터 켜면 1단계의 setlocale 경고가 바로 그 결과로 나타난다. 휴대폰의 SSH 앱은 SendEnv 설정이 없는 경우가 많으므로, 휴대폰에서 SSH로 Claude Code를 쓰는 구성이라면 1단계의 update-locale로 서버 기본값을 UTF-8로 못 박는 편이 안전하다. 한글만 깨지는 것이 아니라 화면 전체가 어긋나고 접속 직후 unknown terminal type 같은 문구가 보인다면 로케일이 아니라 terminfo 문제이니 SSH 접속 직후 뜨는 unknown terminal type 오류 쪽을 본다.

3단계, tmux. SSH 셸에서는 echo 한글이 잘 보이는데 tmux 안의 Claude Code에서만 깨진다면 여기다. tmux 서버는 처음 시작될 때의 환경을 붙들고 있고, 새 창은 그 환경을 물려받는다. 그래서 로케일을 고친 뒤에도 옛 tmux 서버가 살아 있으면 그 안의 LANG은 옛날 값이다. tmux 안과 밖에서 echo $LANG을 쳐서 다르면 확정이다. 처방은 서버를 죽이고 -u로 다시 만드는 것이다. 실행 중인 Claude Code 세션이 있으면 먼저 /exit로 나오고, 다시 만든 뒤 claude --resume으로 이어 간다.

tmux kill-server
tmux -u new -s claude

tmux 매뉴얼의 -u 설명은 이렇다. LANG, LC_ALL, LC_CTYPE 중 처음 설정된 변수에 UTF-8이 없더라도 터미널에 UTF-8로 출력한다. 로케일이 정상이면 -u는 없어도 되지만, 붙여서 손해 볼 일은 없다. 같은 김에 공식 문서가 tmux용으로 권하는 세 줄을 ~/.tmux.conf에 넣는다. 알림과 Shift+Enter를 위한 것이고, 한글 표시와는 무관하다.

set -g allow-passthrough on
set -s extended-keys on
set -as terminal-features 'xterm*:extkeys'

tmux source-file ~/.tmux.conf로 실행 중인 서버에 적용한다. 전체 화면 모드를 tmux 안에서 쓰려면 set -g mouse on도 필요하고, 문서는 tmux 3.6 계열까지 synchronized output을 구현하지 않아 다시 그릴 때 깜빡임이 더 보일 수 있다고 적어 두었다.

줄바꿈: Shift+Enter를 눌렀는데 전송돼 버린다

한글 문제와 같이 오는 불만이다. 문서 기준으로 Enter는 전송이고, 전송하지 않고 줄을 바꾸려면 Ctrl+J를 누르거나 \를 입력한 뒤 Enter를 누른다. 이 두 방법은 모든 터미널에서 설정 없이 동작한다. Shift+Enter는 터미널마다 다르고, 문서의 표를 그대로 옮기면 이렇다.

Ghostty, Kitty, iTerm2, WezTerm, Warp, Apple Terminal, Windows Terminal: 설정 없이 동작한다.
kitty 키보드 프로토콜을 지원하는 그 밖의 터미널(foot, Alacritty 0.16 이상): 설정 없이 동작하지만 Claude Code v2.1.269 이상이 필요하다.
VS Code, Cursor, Devin Desktop, Alacritty 0.16 이전, Zed: /terminal-setup을 한 번 실행한다.
gnome-terminal, PyCharm과 Android Studio 같은 JetBrains IDE: Shift+Enter가 아예 없다. Ctrl+J나 \ 뒤 Enter를 쓴다.

tmux 안에서는 바깥 터미널이 Shift+Enter를 지원해도 위의 extended-keys 두 줄이 있어야 tmux가 Shift+Enter와 일반 Enter를 구별한다. macOS에서 Option+Enter를 쓰고 싶다면 터미널이 Option을 Meta로 보내야 한다. iTerm2는 Settings → Profiles → Keys → General에서 Option 키를 "Esc+"로, Apple Terminal은 Settings → Profiles → Keyboard의 "Use Option as Meta Key"다. 아예 Enter를 줄바꿈으로, Shift+Enter를 전송으로 바꾸고 싶다면 키 바인딩 파일에서 chat:newline과 chat:submit을 다시 매핑한다.

글꼴과 폭 설정은 직접 고르는 것이다

여기부터는 측정한 것이 아니라 선택지다. 터미널 글꼴이 한글을 포함하지 않으면 시스템이 다른 글꼴에서 한글을 빌려 오는데, 그 글자의 폭이 영문 두 칸과 정확히 맞지 않으면 칸 계산은 맞아도 눈에 보이는 줄이 밀려 보인다. D2Coding이나 나눔고딕코딩(Nanum Gothic Coding)처럼 한글 한 글자를 영문 두 칸 폭으로 만든 고정폭 글꼴을 터미널 글꼴로 지정하면 이 종류의 어긋남은 사라진다. 어느 글꼴이 좋은지는 취향이다.

터미널의 "East Asian Ambiguous Width" 설정은 건드리지 않는 편이 낫다. 한글 음절은 유니코드 East Asian Width 속성에서 W(wide)로 고정되어 있어 이 설정과 무관하다. 이 설정이 바꾸는 것은 ─, │, ※, → 같은 모호 폭 문자이고, Claude Code의 입력창 테두리가 바로 그런 문자로 그려진다. iTerm2의 "Treat ambiguous-width characters as double width"나 WezTerm의 treat_east_asian_ambiguous_width_as_wide를 켠 뒤 테두리가 어긋난다면 그것 때문이다.

그래도 안 되면

/tui로 지금 어느 렌더러인지, claude --version으로 버전을, 그리고 터미널 이름과 버전을 적어 /feedback으로 보내거나 GitHub 이슈를 연다. 전체 화면이 시작 도중 죽으면 다음 세션은 기본 렌더러로 뜨면서 Claude Code's fullscreen renderer didn't finish starting last time on this machine이라는 줄을 보여 준다. 그 줄이 보인 뒤 한글 문제가 다시 나타나는 이유는 렌더러가 되돌아갔기 때문이니, /tui fullscreen을 다시 실행하고 그것도 실패하면 그 사실을 포함해 보고한다.

FAQ

`/tui fullscreen`을 켰더니 마우스 드래그로 복사가 안 된다. 어떻게 하나?

전체 화면 모드는 마우스를 Claude Code가 잡기 때문에 터미널의 선택이 바뀐다. Claude Code 안에서 드래그하면 놓는 순간 자동으로 클립보드에 복사된다. 터미널 쪽 선택을 쓰고 싶으면 Shift를 누른 채 드래그한다. iTerm2는 Option, Terminal.app은 Fn이다. 항상 터미널 선택을 쓰려면 CLAUDE_CODE_DISABLE_MOUSE=1을 주면 렌더러는 전체 화면 그대로, 마우스만 터미널에 돌아간다. 완전히 되돌리려면 /tui default다.

한글 편집 이슈 #5126은 해결된 것인가?

닫혀 있지만, 스레드 안에 어느 버전에서 고쳐졌다는 말이 없다. 그러니 특정 버전에서 해결됐다고 단정할 근거가 없다. 문서가 이름 붙인 처방은 /tui fullscreen이고, 그 상태에서도 문장 중간 수정 시 글자가 밀린다면 Claude Code 안에서 /feedback으로 터미널 이름과 버전을 함께 보내는 것이 지금의 경로다.

VPS 로케일은 꼭 `ko_KR.UTF-8`이어야 하나, `C.UTF-8`로도 되나?

한글이 그려지느냐는 문자 집합이 결정하므로 C.UTF-8로도 된다. 차이는 시스템 메시지와 날짜 형식이 영어로 나온다는 것뿐이다. sudo update-locale LANG=C.UTF-8로 설정하고 다시 로그인한 뒤 locale에 경고가 없으면 끝이다. ko_KR.UTF-8을 쓰려면 sudo locale-gen ko_KR.UTF-8로 먼저 생성해야 하고, 생성 전에 클라이언트가 SendEnv로 그 이름을 보내면 cannot change locale 경고가 나온다.

SSH 셸에서는 한글이 보이는데 tmux 안에서만 `?`로 나온다. 왜인가?

tmux 서버가 로케일을 고치기 전의 환경으로 떠 있기 때문이다. 새 창은 서버의 환경을 물려받으므로 셸을 새로 열어도 LANG이 옛날 값이다. tmux 안과 밖에서 echo $LANG을 비교해 다르면 확정이다. 실행 중인 Claude Code에서 /exit로 나온 뒤 tmux kill-server로 서버를 죽이고 tmux -u new -s claude로 다시 만들면 된다. 대화는 claude --resume으로 이어진다.

Shift+Enter가 줄바꿈이 아니라 전송으로 동작한다. 터미널을 바꿔야 하나?

아니다. Ctrl+J나 \ 뒤 Enter는 모든 터미널에서 설정 없이 줄바꿈이다. Shift+Enter를 꼭 쓰고 싶다면 VS Code, Cursor, Zed에서는 /terminal-setup을 한 번 실행하고, tmux 안이라면 ~/.tmux.conf에 set -s extended-keys on과 set -as terminal-features 'xterm*:extkeys'를 넣는다. gnome-terminal과 JetBrains IDE는 문서 기준으로 Shift+Enter가 아예 없다.

#claude-code #terminal#korean#tmux #ssh #troubleshooting

먼저 결론: Claude Code 한글 깨짐은 증상마다 처방이 하나씩이다

증상 1: 조합 중인 글자가 딴 데 찍히고, 문장 중간을 고치면 글자가 밀린다

증상 2: Cursor나 VS Code 통합 터미널에서 글자가 박스, 번짐, 엉뚱한 글자로 나온다

증상 3: Windows Terminal에서 이전 출력의 조각이 화면에 남는다

증상 4: SSH로 접속한 VPS에서 한글이 ?나 빈 박스로 나온다

줄바꿈: Shift+Enter를 눌렀는데 전송돼 버린다

글꼴과 폭 설정은 직접 고르는 것이다

그래도 안 되면

FAQ

/tui fullscreen을 켰더니 마우스 드래그로 복사가 안 된다. 어떻게 하나?

한글 편집 이슈 #5126은 해결된 것인가?

VPS 로케일은 꼭 ko_KR.UTF-8이어야 하나, C.UTF-8로도 되나?

SSH 셸에서는 한글이 보이는데 tmux 안에서만 ?로 나온다. 왜인가?

Shift+Enter가 줄바꿈이 아니라 전송으로 동작한다. 터미널을 바꿔야 하나?

증상 4: SSH로 접속한 VPS에서 한글이 `?`나 빈 박스로 나온다

`/tui fullscreen`을 켰더니 마우스 드래그로 복사가 안 된다. 어떻게 하나?

VPS 로케일은 꼭 `ko_KR.UTF-8`이어야 하나, `C.UTF-8`로도 되나?

SSH 셸에서는 한글이 보이는데 tmux 안에서만 `?`로 나온다. 왜인가?