터미널이 비었을 뿐, 작업은 살아 있었습니다
9월 6일 저녁, cs로 들어간 Cursor 화면이 비어 있었습니다. 글자가 하나도 보이지 않았습니다. 확인해 보니 작업 프로세스는 살아 있었고, 화면이 글자 없는 곳을 보고 있었습니다.
저는 여러 컴퓨터의 작업창을 tmux에 열어 둡니다. tmux는 터미널 연결을 끊었다가 다시 들어와도 작업창을 유지해 주는 도구입니다. 컴퓨터 앞에 있든 다른 터미널에서 접속하든 같은 작업을 이어 볼 수 있습니다.
그날은 이 구성이 오히려 상태를 잘못 읽게 만들었습니다. 프로그램이 그리는 창의 크기와 제가 접속한 터미널의 크기가 달랐습니다. 큰 작업창의 어느 부분을 보여줄지도 설정에 들어 있었습니다.
창의 맨 아래가 입력창은 아니었습니다
작업창은 높게 잡혀 있었고, 화면 위치를 맨 아래로 강하게 내리는 설정이 있었습니다. 작은 터미널로 들어오면 글자가 없는 아래쪽 영역이 보였습니다.
큰 종이에 몇 줄 적어 놓고 종이 끝부분만 들여다보는 것과 비슷했습니다. 글을 쓰는 과정이 멈춘 것은 아닌데, 보고 있는 부분에는 글자가 없었습니다.
이 상태에서 프로그램을 다시 켜는 것부터 시작했다면 원인을 놓칠 수 있었습니다. 재시작 직후 잠깐 정상처럼 보여도 같은 크기의 터미널로 다시 접속하면 문제가 돌아올 수 있었으니까요.
먼저 확인한 것은 프로세스가 살아 있는지, 입력 위치가 어디인지, 접속한 터미널이 창의 어느 부분을 보여주는지였습니다. 그 세 가지를 나눠 보니 화면 위치 설정이 원인으로 드러났습니다.
작업을 보존한 채 화면을 돌렸습니다
맨 아래로 강제 이동하던 동작을 입력 위치를 따라가는 방식으로 바꿨습니다. 공통 설정을 만들고 세 컴퓨터에 적용했습니다.
이번 수리에서는 기존 작업 프로세스를 보존했습니다. 화면을 복구하는 일 때문에 진행 중인 작업까지 처음부터 다시 시작하지 않도록 했습니다.
설정 파일을 바꿨다는 사실만으로 끝내지도 않았습니다. 이미 연결된 터미널에서 글자가 보이는지, 다른 크기로 재접속해도 입력 위치를 따라오는지 확인했습니다. 사용자에게 필요한 것은 설정의 이름보다 다시 읽을 수 있는 화면이었으니까요.
작은 창에서 다시 검사했습니다
개발할 때 쓰는 넓은 창에서만 확인하면 이 문제를 놓치기 쉬웠습니다. 실제 문제가 드러난 것은 작은 터미널이었습니다.
24행과 25행 환경에서 재접속하고 크기를 바꾸는 검사를 넣었습니다. 세 컴퓨터에서 각각 네 개씩, 실제 tmux를 사용하는 검사 12개를 통과했습니다. 설정 파일이 같다는 확인과 실제 화면이 보인다는 확인을 함께 남겼습니다.
이전의 잘못된 화면 이동 설정도 검사에 다시 넣었습니다. 그러자 검사가 실패했습니다. 고친 설정으로 돌리면 다시 통과했습니다. 적어도 이번에 찾은 원인을 검사로 잡을 수 있다는 뜻이었습니다.
그 결과가 모든 터미널 문제를 해결했다는 보증은 아닙니다. 이번 검사가 확인한 것은 작은 창에서 입력 위치를 놓치는 문제와 재접속 동작입니다. 다음에 다른 증상이 나오면 그 증상을 다시 구분해야 합니다.
배운 것
화면이 비어 있다는 것은 관찰입니다. 작업이 멈췄다는 것은 그 관찰에서 내린 판단입니다. 둘 사이를 확인하지 않으면 살아 있는 작업을 불필요하게 종료할 수 있습니다.
이번에는 글자가 사라진 곳부터 따라갔습니다. 프로세스와 작업창은 남아 있었고, 제가 보는 위치만 어긋나 있었습니다. 그래서 작업을 보존하면서 고칠 수 있었습니다.
비슷한 증상을 다시 만나면 같은 순서로 보려고 합니다. 작업이 살아 있는지, 입력 위치가 어디인지, 내 화면이 그 위치를 보여주는지요. 재시작은 그다음에 판단할 수 있습니다.
— 강대종 / @ssamssae