터미널 하나 때문에 윈도우 PC를 버렸습니다

올여름에 개발 환경을 윈도우에서 맥으로 옮겼습니다. 이유가 좀 민망합니다. 터미널 하나 때문이었습니다.

cmux라는 터미널을 쓰고 싶었는데 맥에서만 돌아갑니다. 그래서 노트북을 바꿨습니다.

터미널이 그렇게 중요한 도구였나

원래는 아니었습니다. 에디터가 중심이고 터미널은 빌드 돌리고 로그 보는 창이었습니다. 창이 예쁜지 아닌지는 취향 문제였지 생산성 문제가 아니었습니다.

그게 바뀐 건 작업 방식이 바뀌었기 때문입니다. 지금은 코드의 상당 부분을 에이전트가 씁니다. 제가 하는 일은 문제를 정의하고, 계획을 승인하고, 결과를 검증하는 쪽으로 옮겨갔습니다. 그러면 하루의 중심도 같이 옮겨갑니다. 에디터가 아니라 에이전트가 사는 터미널이 작업대가 됩니다.

작업대가 바뀌면 작업대에 요구하는 것도 달라집니다.

iTerm2를 켜보다 접었습니다

맥으로 넘어오기 전에 먼저 알아본 건 iTerm2였습니다. 오래됐고 안정적이고 정보도 많습니다. 무난한 선택입니다.

그런데 후보를 비교하다가 제가 찾는 게 터미널 에뮬레이터가 아니라는 걸 알았습니다. 탭, 분할, 색 테마, 단축키 — 이런 건 어느 터미널이나 합니다. 제가 원한 건 에이전트가 터미널 자체를 조작하는 것이었고, 그건 에뮬레이터의 기능 목록에 없는 항목이었습니다.

세 개를 늘어놓으면 이렇습니다. 기능 비교표가 아니라, 제가 각각을 얼마나 써봤고 어떤 용도로 대했는지의 기록입니다.

	얼마나 써봤나	나한테 어떤 도구였나
윈도우 터미널	윈도우 시절 몇 년	빌드 돌리고 로그 보는 창
iTerm2	후보로 검토만, 정착 안 함	무난한 선택지. 안 써봤으니 단점은 말할 수 없음
cmux	옮긴 뒤로 매일	에이전트가 직접 조작하는 작업대

iTerm2 줄이 비어 있는 게 정직한 상태입니다. 제대로 안 써본 도구를 표에서 깎아내리는 건 비교가 아니라 변명이라서요. 아래 이야기는 전부 cmux를 쓰면서 겪은 것입니다.

뭐가 다른가

cmux에는 에이전트가 호출할 수 있는 CLI가 딸려 있습니다. 덕분에 에이전트가 창을 열고, 패널을 만들고, 다른 화면을 읽습니다. 실제로 쓰는 건 두 가지입니다.

브라우저를 직접 엽니다. 이게 제일 큽니다. 이전에는 화면을 고친 뒤 에이전트가 “브라우저에서 확인해 보세요”로 끝냈습니다. 검증이 항상 저한테 넘어왔습니다. 지금은 에이전트가 페이지를 열고, 클릭하고, 텍스트를 읽고, 스크린샷을 떠서 자기가 확인합니다. 이 블로그도 배포한 뒤에 에이전트가 실제 주소를 열어 렌더 결과를 보고 옵니다.

말장난 같지만 차이가 큽니다. “빌드가 통과했습니다”와 “열어보니 이렇게 나옵니다”는 다른 문장입니다.

옆 패널에 다른 CLI를 띄웁니다. 같은 문제에 다른 도구를 동시에 붙여서 판단을 되짚습니다. 한 모델이 확신에 차서 틀리는 경우가 있는데, 이걸 잡는 방법은 지금으로선 다른 모델에게 같은 걸 물어보는 것밖에 없더군요.

# 옆에 패널을 만들고, 다른 CLI를 붙이고, 결과만 회수한다
cmux new-pane --type terminal --direction right
cmux send --surface surface:2 "..."
cmux read-screen --surface surface:2 --lines 40

정리하면 작업 중 화면이 이렇게 됩니다.

옮기면서 한꺼번에 청구된 비용

여기가 예상 못 한 부분입니다. 저는 터미널만 바꾸는 일이라고 생각했는데, 실제로는 개발 환경 전체를 이사하는 일이었습니다.

플랫폼 가정이 코드 곳곳에서 튀어나왔습니다. 줄바꿈이 CRLF에서 LF로 정규화되면서 diff가 통째로 어긋났고, 한글 폴더명이 자소 분리 문제(NFD/NFC)로 충돌했고, 윈도우 전용 폰트 경로를 박아둔 스크립트들이 죽었습니다.

아직 다 못 옮겼습니다. 관리하던 프로젝트 열두 개 중 일곱 개는 코드가 아직 맥에 없습니다. 두 개는 백업 폴더에서 겨우 찾았습니다.

교훈은 이겁니다. 플랫폼에 기댄 가정은 컴퓨터 한 대에서만 쓸 때는 보이지 않습니다. 경로 구분자, 줄바꿈, 폰트 경로, 파일명 정규화 — 전부 “그냥 되던 것”이었고, 옮기는 순간 한꺼번에 청구됐습니다. 몇 년치가 한 주에 몰려온 셈입니다.

아쉬운 점

브라우저에 한계가 있습니다. 내장 브라우저가 WKWebView 기반이라 크롬 개발자 도구 계열에서 되는 것 중 안 되는 게 있습니다. 오프라인 모드 흉내, 트레이스·스크린캐스트, 네트워크 요청 가로채기, 로우 레벨 입력 이벤트 같은 것들은 지원하지 않는다고 나옵니다. 이런 게 필요한 작업이면 처음부터 다른 도구를 골라야 합니다.

맥 전용입니다. 저한테는 이게 선택지가 아니라 조건이었습니다. 노트북을 바꿔야 쓸 수 있는 도구를 권하는 건 무리한 이야기라고 생각합니다.

명령과 플래그가 자주 바뀝니다. 외워두면 다음 버전에서 틀립니다. 저는 아예 외우지 않고 매번 도움말을 확인하는 쪽으로 습관을 바꿨습니다.

지금 생각

노트북을 바꿀 만한 일이었냐고 물으면, 저한테는 그렇습니다. 다만 이유가 “맥이 개발에 좋아서”는 아닙니다. 그런 이야기는 예전부터 있었고 저는 그 이유로는 안 옮겼습니다.

옮긴 이유는 하나였습니다. 검증을 저한테 넘기지 않는 도구가 거기에만 있었습니다. 혼자 만들고 혼자 유지하는 입장에서 병목은 코드 작성 속도가 아니라 확인하는 시간입니다. 그걸 줄여주는 쪽에 노트북 값과 옮기는 데 든 시간을 쓴 겁니다.

반대로 코드를 직접 치는 시간이 대부분인 분이라면 이 계산은 성립하지 않습니다. 터미널을 바꿔서 얻을 게 별로 없습니다. 도구가 좋아서 옮긴 게 아니라, 제 작업의 병목이 그쪽으로 옮겨가 있었기 때문에 옮긴 것에 가깝습니다.