새 창을 만들려고 Ctrl-b c를 눌렀는데, 아무 일도 안 일어나고 c라는 글자만 화면에
찍혔다. tmux를 꽤 오래 써왔고 단축키가 이렇게 안 먹힌 적이 없어서 당황스러웠다.
클라이언트 쪽부터 의심했다
Windows 11 기본 터미널로 SSH 접속해서 tmux에 붙어 쓰는 환경이었다. 제일 먼저 의심한
건 클라이언트 쪽 — 뭔가가 Ctrl+B를 tmux까지 가기도 전에 가로채고 있는 게 아닐까
싶었다. Windows Terminal의 settings.json을 열어서 ctrl+b로 등록된 키바인딩이
있는지 하나하나 뒤져봤고, 그다음엔 cmd 자체가 문제일 수도 있겠다 싶어서 화면
단축키로 wsl.exe ~를 실행하는 걸 새로 만들어서 아예 다른 경로(WSL)로 접속해보기도
했다. 다 별 소득이 없었다.
결국 “정말 키가 서버까지 도착은 하는가”부터 직접 확인해보기로 했다. tmux를 잠깐
벗어나서 cat -v를 띄우고 직접 쳐보는 거다.
cat -v
# Ctrl+B를 누르면
^B^B가 정확히 찍혔다. 즉 키 입력 자체는 서버까지 멀쩡하게 도착하고 있었다 — 문제는
클라이언트가 아니라 서버(tmux) 쪽에 있다는 뜻이다.
설정 파일은 멀쩡한데
~/.tmux.conf를 열어보니 문제 될 게 없었다.
set -g mouse onprefix를 바꾸는 설정 자체가 파일에 없으니, 당연히 기본값인 Ctrl-b가 그대로 살아있을
거라고 생각했다. 그런데 실제로 지금 돌고 있는 tmux 서버한테 직접 물어보니 얘기가
달랐다.
tmux show-options -g prefix
# prefix C-aprefix가 Ctrl-a로 되어 있었다. 파일에는 없는 설정이 서버에는 살아있었던 거다.
파일과 서버가 따로 노는 이유
tmux는 set -g prefix C-a 같은 명령을 세션 안에서 직접 치면 그 순간 즉시 적용되는데,
이게 설정 파일에 자동으로 기록되지는 않는다. 그리고 tmux 서버는 한 번 뜨면 컴퓨터를
재부팅하지 않는 이상 계속 살아있다 — 이 서버도 확인해보니 7월 2일부터 한 번도 안
끊기고 계속 떠 있었다. 그러니 그 사이 어느 시점에 누군가(혹은 뭔가) 세션 안에서 직접
prefix를 바꿨다면, 파일은 그대로인 채 서버 상태만 바뀐 채로 계속 남아있을 수 있는
거다.
정작 나는 저 명령을 직접 친 기억이 없었다. 혹시나 해서 ~/.bash_history와 .bashrc,
.profile까지 다 뒤져봤는데 prefix나 tmux set 관련 흔적이 전혀 없었다. tmux
자체가 명령 실행 이력을 따로 로그로 남기지 않다 보니, 언제 어떻게 바뀐 건지는 결국
못 찾았다. 파일에도 없고 히스토리에도 없으면, 사후 추적이 안 되는 상황이 있다는 걸
이번에 알았다.
고친 방법
일단 지금 서버부터 원래대로 되돌리고,
tmux set -g prefix C-b다음에 서버가 재시작돼도 이번처럼 조용히 어긋나는 일이 없게 설정 파일에도 명시적으로 적어뒀다.
set -g mouse on
set -g prefix C-b주의할 점은, 이렇게 파일에 적어놔도 지금 떠 있는 서버가 앞으로 계속 이 값을
유지하도록 강제하는 건 아니라는 거다. 파일은 “서버가 재시작될 때의 기본값”만
보장한다. 지금처럼 살아있는 서버 상태를 고쳐놔도, 나중에 누가(또는 어떤 스크립트나
도구가) 세션 안에서 tmux set -g ...를 다시 치면 서버 상태는 그 순간 또 바뀐다.
같은 증상이 재발하면 이번에 한 것처럼 show-options로 다시 확인하는 수밖에 없다.
남는 교훈
“설정 파일을 확인했는데 문제가 없다”는 게 “지금 실제로 적용된 상태에 문제가 없다”는 뜻은 아니었다. tmux처럼 오래 떠 있는 서버 프로세스는, 파일에는 없지만 세션 중에 직접 준 명령으로 상태가 바뀌어 있을 수 있고, 그 둘이 서로 다른 걸 알아채는 유일한 방법은 파일이 아니라 지금 살아있는 상태를 직접 물어보는 것이었다.
전체 옵션을 다 켜놓고 파일이랑 하나하나 대조하는 건 비효율적이다. 지금처럼 “특정 단축키가 안 먹힌다”는 증상이면, 의심 가는 항목만 딱 집어서 물어보면 된다.
tmux show-options -g prefix # 지금 prefix가 진짜 뭘로 잡혀 있는지
tmux list-keys -T root | grep C-b # C-b 자체가 다른 동작에 재바인딩됐는지이 두 줄이면 이번 문제는 바로 잡혔을 거다. tmux 말고 오래 떠 있는 다른 서버/데몬을 디버깅할 때도, “전체를 덤프해서 비교”보다는 “의심되는 항목만 살아있는 상태에 직접 물어보는” 쪽이 훨씬 빠르다.
그리고 원인을 계속 못 찾겠으면, 서버를 완전히 죽였다가 다시 띄우는 것도 방법이다. 그러면 파일에 없던 상태는 전부 날아가고, 파일에 적힌 대로 깨끗하게 다시 시작한다 — 근본 원인은 못 찾은 채로 남지만, 적어도 지금부터는 파일과 실제 상태가 일치한다는 건 보장된다. 원인 추적을 더 파고드는 것보다 이게 ROI가 나을 때가 있다.