콘텐츠로 건너뛰기
Codex

오래 살아 있는 tmux 세션에서 자주 겪는 문제들

오래 살아 있는 tmux 세션에서 자주 겪는 문제들

TECH NOTE · AUTOMATION OPS

tmux 세션을 오래 띄워두면 겪게 되는 이름 충돌, 환경 드리프트, 로그 누적을 어떻게 다루는지 정리했습니다.

오래 살아 있는 tmux 세션에서 먼저 망가지는 건 상태다

오래 켜둔 tmux 세션에서 자주 터지는 문제는 대체로 세션 이름 충돌, 환경 드리프트, 로그 누적 이 세 가지다. tmux 자체가 불안정하다기보다는, 세션이 오래 살아 있으면서 “처음 열었을 때의 상태”와 “지금 내가 기대하는 상태”가 조금씩 어긋난다. 처음엔 그냥 편해서 계속 붙잡고 있었는데, 어느 순간부터는 내가 어느 세션에 붙어 있는지부터 의심해야 했다.

세션 이름이 겹치면 내가 어디에 붙었는지 헷갈린다

세션 이름 충돌은 생각보다 단순하게 시작한다. 예전에 blog라는 이름으로 열어 둔 세션이 있는데, 며칠 뒤에 또 비슷한 작업을 하면서 같은 이름을 쓰려고 한다. 그러면 새 세션이 안 만들어지거나, 내가 예상한 세션이 아니라 예전 세션으로 붙는다.

먼저 지금 살아 있는 세션을 본다. 이건 “tmux가 이상한가?”를 보기보다, 내가 이미 만들어 둔 세션을 잊고 있는지 확인하는 쪽에 가깝다.

tmux ls

여기서 같은 주제의 세션이 여러 개 보이면, 이름을 대충 지은 대가를 치르는 중이다. 내 경우에는 blog, blog2, test, work 같은 이름이 쌓이기 시작하면 거의 반드시 헷갈렸다.

이럴 때는 세션 이름을 작업 단위로 조금 길게 붙이는 편이 낫다.

tmux new -s blog-content-pipeline

이미 만들어진 세션 이름을 바꿀 수도 있다. 오래 살아 있는 세션일수록 나중에 봐도 의미가 남아야 한다.

tmux rename-session -t blog blog-content-pipeline

세션 이름은 별것 아닌데, 이게 흐려지면 이후 문제가 전부 애매해진다. 명령은 맞게 쳤는데 다른 폴더였는지, 다른 브랜치였는지, 다른 프로세스였는지 구분이 잘 안 된다.

환경 드리프트는 조용히 쌓인다

환경 드리프트는 세션이 오래 살아 있을 때 제일 귀찮았다. tmux 안에서 쉘을 열어 둔 뒤에 바깥에서 .zshrc를 고치거나, Node 버전을 바꾸거나, PATH를 손봤는데 tmux 안쪽은 예전 상태를 계속 들고 있는 식이다.

헷갈리면 먼저 바깥 터미널과 tmux 안쪽에서 같은 명령을 쳐 본다.

pwd
git branch --show-current
which node
node -v

결과가 다르면 tmux가 틀린 게 아니라, 오래 켜 둔 쉘이 예전 환경을 계속 들고 있는 것이다. 내 경우에는 node -v가 바깥과 tmux 안에서 다르게 나와서 한참을 빌드 문제로 착각한 적이 있다.

자주 보는 항목은 대충 이 정도다.

확인할 것 왜 보는가
pwd 내가 생각한 프로젝트 폴더가 맞는지 본다
git branch --show-current 예전 브랜치에 붙어 있는지 확인한다
which node 다른 Node 실행 파일을 잡고 있는지 본다
node -v 버전 차이로 빌드가 갈리는지 본다
echo $PATH PATH가 예전 설정인지 본다

환경을 다시 읽히고 싶으면 쉘 설정을 다시 불러온다.

source ~/.zshrc

그래도 꼬였으면 세션 안의 해당 pane을 새로 여는 게 빠를 때가 많다. 오래 켜 둔 프로세스를 억지로 살려 두는 것보다, 지금 기준의 환경에서 다시 시작하는 쪽이 덜 헷갈린다.

로그는 쌓이기 시작하면 문제를 숨긴다

오래 살아 있는 세션에서는 로그도 누적된다. 특히 개발 서버나 watch 명령을 며칠씩 켜 두면, 지금 막 난 에러인지 어제 이미 지나간 에러인지 구분이 안 된다.

그래서 문제가 생기면 먼저 화면을 한번 비우고 다시 재현한다.

clear

이건 해결책이라기보다 눈을 새로 뜨는 것에 가깝다. 화면 위쪽에 오래된 에러가 남아 있으면, 지금 상태를 보고 있다고 착각하기 쉽다.

파일 로그를 보고 있다면 마지막 부분만 보는 편이 낫다.

tail -n 80 logs/listen.log

계속 흐르는 로그를 봐야 할 때는 이렇게 붙는다.

tail -f logs/listen.log

다만 tail -f를 여러 pane에서 켜 두면 그것도 금방 소음이 된다. 내 경우에는 “로그를 많이 보고 있으니 더 안전하다”고 생각했는데, 실제로는 어느 pane이 현재 문제를 보여주는지 더 헷갈렸다.

오래 둔 세션을 계속 쓸지 버릴지 기준을 둔다

세션은 오래 살릴 수 있지만, 오래 살아 있다고 늘 좋은 건 아니다. 특히 환경을 많이 바꾼 날에는 새 세션이 더 싸게 먹힌다.

상황 보통 선택
같은 폴더, 같은 브랜치, 같은 서버를 계속 보는 중 기존 세션 유지
Node, Python, PATH 같은 실행 환경을 바꿨다 새 세션 권장
브랜치를 여러 번 오갔다 세션 이름부터 확인
로그가 너무 많이 쌓여 현재 상태가 안 보인다 화면 정리 후 재현
세션 이름만 봐서는 용도를 모르겠다 이름 변경 또는 종료

종료할 세션이 확실하면 지운다.

tmux kill-session -t blog-content-pipeline

이 명령은 되돌리는 명령이 아니다. 그래서 tmux ls로 이름을 다시 보고 치는 편이 낫다.

같이 나오는 질문

tmux 세션은 그냥 오래 켜 둬도 되나?

켜 둬도 된다. 다만 환경을 바꿨거나, 브랜치를 많이 오갔거나, 로그가 너무 쌓였으면 새로 여는 편이 덜 헷갈린다.

세션 이름은 어떻게 짓는 게 낫나?

blog, test처럼 넓은 이름보다 blog-content-pipeline처럼 작업 단위가 드러나는 이름이 낫다. 오래 살아 있는 세션일수록 나중에 봐도 뜻이 남아야 한다.

문제가 생기면 tmux부터 재시작해야 하나?

처음부터 그럴 필요는 없다. 먼저 pwd, 브랜치, 런타임 버전, 로그의 최신 구간을 본다. 거기서 상태가 꼬였다는 게 보이면 그때 새 세션으로 옮기는 게 낫다.

다음에 확인할 건 내가 자주 쓰는 세션 이름 규칙이다. 이름만 정리해도 “어느 세션에 붙어 있는지 모르겠다”는 문제는 꽤 줄어든다.

이 블로그 더 보기

이 블로그는 실제 프로젝트를 AI와 함께 굴리면서 남긴 기록입니다.

  • 새 글은 RSS로 받아볼 수 있습니다.
  • 시리즈 전체는 여기에 정리해 두었습니다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다