폰 돌리면 AI 터미널이 깨지는 이유

맥에서 돌아가는 클로드 코드(Claude Code) 세션을 폰으로 이어 보다가 화면을 돌리면, 글자가 두 줄로 뒤엉켜 알아볼 수 없게 된다. 솔로 개발자 멘디 아위제라(Mendy Aouizerat)는 이 증상을 2주 동안 쫓은 끝에 렌더링 버그가 아니라는 결론에 이르렀다. 그가 8월 21일 정리한 원인은 한 문장으로 압축된다. 바이트 스트림은 세션이 아니다.

무슨 일인가 / 배경

그는 아이폰용 개발 도구 엑스텐드(Xtend)를 혼자 만들면서, 맥에서 실행 중인 터미널 세션을 폰에 실시간으로 비추는 기능을 붙였다. 그런데 폰을 회전하면 화면이 뒤섞인 두 열로 무너졌고, 화면 속 버튼을 눌러도 아무 반응이 없었다. 2주와 전면 되돌림 한 번을 쓰고 나서야, 같은 원인이 디스크에 저장되던 세션 파일까지 조용히 망가뜨리고 있었다는 사실도 드러났다.

그가 짚은 핵심은 이렇다. 터미널이 뱉는 것은 완성된 그림이 아니라 '어디에 무엇을 그려라'는 지시가 담긴 바이트의 흐름이다. 그런데 그 지시에 의미를 주는 정보 — 화면이 몇 칸이었는지, 어떤 입력 모드였는지 — 는 바이트 안에 없고 함께 이동하지도 않는다. 그리고 그 사실은 어디에도 제대로 적혀 있지 않다는 게 그가 글을 쓴 이유다.

핵심 짚어보기

문제의 실체는 화면 폭이다. 위로 지나간 기록은 그냥 바이트이고, 바이트에는 폭이 없다. 클로드 코드의 로딩 표시는 맨 아랫줄에서 커서를 두 줄 위로 올려 제자리에 다시 그리는 식으로 회전한다. 40칸 화면에서 만들어진 이 지시를 18칸짜리 좁은 화면에서 그대로 재생하면, 그 사이에 있던 명령어가 두 줄로 접히면서 '두 줄 위'가 엉뚱한 자리를 가리킨다. 그 결과 명령어 한가운데에 두 번째 로딩 표시가 찍히고, 한 줄에 두 개의 글이 겹친다. 줄이 어디서 접혔는지는 애초에 바이트에 없었다. 그 정보는 이미 사라진 화면 격자에만 존재했다.

이건 특수한 상황도 아니다. 코덱스(Codex)는 올해 창 크기 변경 시 지난 화면을 다시 흘려주는 수정을 반영했고, 클로드 코드도 2.1.116 버전 변경 기록에 지난 화면 중복 문제를 고쳤다고 적었다. 그런데 같은 증상이 네 번의 릴리스 연속으로 되살아나 관련 이슈가 계속 열려 있고, 몇 주 뒤에도 중복 신고가 들어왔다. 그의 진단은 간명하다. 수정이 자꾸 붙지 않으면 원인은 대개 한 층 아래에 있다.

기술 배경도 짧게 정리해 둘 만하다. 프로그램을 단순 파이프로 연결해 띄우면 출력은 받지만 그건 터미널이 아니다. 창 크기라는 개념 자체가 없어서 화면을 직접 그리는 프로그램이 동작하지 않는다. 진짜 유사 터미널을 만들어야 커널이 창 크기를 소유하고, 크기가 바뀔 때 프로그램에 '창이 바뀌었다'는 신호를 보낸다. 화면이 다시 그려지는 이유는 그 신호 하나뿐이다. 디버깅 요령도 하나 남겼다. 해당 터미널에서 행·열 값을 직접 조회해 제대로 나온다면 껍데기는 정상이고 버그는 그 위층에 있다는 뜻이다.

그의 해법은 스트림 안에 메모를 끼워 넣는 것이었다. 터미널 규격에는 이해하지 못하는 터미널이라면 조용히 버려야 하는 이스케이프 시퀀스 계열이 있다. 여기에 '이 지점부터 폭이 바뀌었다'는 표시를 넣으면 자기 앱만 그걸 읽고 다른 터미널은 아무 영향 없이 무시한다. 위치도 스트림 안에 있으니 자연히 정확하다.

1인기업 실전 적용 포인트

• 원격으로 AI 코딩 세션을 이어 쓸 계획이라면 대부분은 직접 만들지 말고 SSH와 터미널 멀티플렉서 조합을 쓰는 게 맞다. 이 글의 저자도 그 점을 가장 먼저 인정한다.
• 폰에서 확인하는 용도라면 '붙어서 조작'보다 '결과를 밖으로 밀어내기'가 훨씬 싸다. 작업 완료·실패 알림을 메신저로 푸시하는 구조가 화면 미러링보다 안정적이다.
• 자동화 로그를 파일로 남길 때 터미널 출력을 그대로 저장하면 나중에 재생과 검색이 깨진다. 색상 코드가 섞인 화면 출력이 아니라 구조화된 텍스트로 따로 남기는 편이 안전하다.
• 되풀이되는 버그를 만나면 같은 층에서 고치려 들지 말자. 네 릴리스 연속 재발이라는 신호는 원인이 더 아래에 있다는 뜻이다.

전망과 주의점

에이전트를 길게 돌리는 사용 패턴이 늘면서 '세션을 다른 기기에서 이어받기'는 공통 과제가 되고 있다. 편집기와 에이전트를 잇는 표준 프로토콜도 등장했지만, 그것은 에이전트만 줄 뿐 빌드·로그·디버거가 있는 내 기계를 주지는 않는다. 그래서 당분간은 모든 명령행 프로그램이 공통으로 말하는 유사 터미널이 유일한 접점으로 남을 가능성이 크다.

다만 이 글이 남긴 진짜 교훈은 터미널 지식이 아니라, 상태를 잃어버린 채 데이터만 옮기면 반드시 어딘가에서 깨진다는 원칙이다. 세션·컨텍스트·설정을 다른 기기나 다른 도구로 옮기는 모든 자동화에 똑같이 적용된다.

출처: 엑스텐드 저널 (https://getxtend.com/blog/terminal-state-you-cant-replay.html)