터미널 테마는 취향이고, 설정이 사는 위치는 비용이다
티오리가 자사 해커들에게 터미널을 어떻게 꾸미는지 물어 정리한 글에서, 제가 따로 저장해 둔 건 테마 이름이 아니라 표 하나예요. 어떤 설정이 `.zshrc`에 살고 어떤 설정이 터미널 앱 안에 사는지를 나눈 표입니다. 꾸미기 글의 뒤쪽에 조용히 붙어 있는데, 가장 오래 쓸 정보는 거기 있었습니다.
글은 설문에 답한 해커 22명 가운데 몇 사람의 화면을 직접 보여주며 Catppuccin, Powerlevel10k, Oh My Zsh 내장 테마인 bira와 afowler를 차례로 소개합니다. 보는 재미는 있어요. 그런데 테마는 취향이라 남의 선택을 가져와도 제 문제가 풀리지는 않잖아요. 저는 이 글에서 네 가지만 골랐고, 그중 하나에는 동의하지 않습니다.
설정은 두 군데에 나뉘어 산다
프롬프트 테마, 플러그인, alias와 환경 변수는 셸 설정 파일인 `.zshrc`에 들어갑니다. 터미널 앱을 iTerm2에서 Ghostty로 바꿔도, 노트북을 바꿔도 이 파일만 따라오면 그대로죠. 반면 배색과 폰트, 화면 분할 단축키는 앱이 따로 들고 있어서 새 환경에서는 앱마다 다시 지정해야 합니다. 같은 Powerlevel10k 테마인데 iTerm2에서는 아이콘이 멀쩡하고 VS Code 내장 터미널에서는 □로 깨지는 일이 생기는 것도 폰트가 앱 쪽에 저장되기 때문이고요.
제가 한 걸음 더 나가고 싶은 건 앱 쪽 설정의 형태입니다. 글에 따르면 Ghostty는 `~/.config/ghostty/config` 같은 텍스트 파일에, iTerm2는 앱 환경설정 안 프로필에 배색과 폰트를 저장해요. 텍스트 파일은 `.zshrc`와 같은 저장소에 넣어 함께 옮길 수 있고, 무엇을 바꿨는지 diff로 남습니다. 앱 안 프로필은 내보내기를 따로 챙겨야 하고요. 터미널을 고를 때 기능 비교표보다 "설정이 텍스트로 남는가"를 먼저 보는 편이 몇 년 뒤에 덜 억울합니다.
"파일 하나 옮기면 그대로"라는 설명에는 표 안에 작은 단서가 달려 있었습니다. 추가 플러그인과 테마는 별도로 설치해야 한다는 것. `.zshrc`는 플러그인을 불러오라는 지시문이지 플러그인 자체가 아니니까요. 꾸밈이 많을수록 새 노트북에서 다시 깔아야 할 목록도 길어집니다.
창을 열 때마다 내는 시간
마지막 팁 자리에 숫자가 하나 있습니다. 한 개발자가 자기 환경을 재 보니 터미널을 열고 프롬프트가 뜨기까지 약 5초가 걸렸고, 그 절반 이상이 Oh My Zsh 자체를 읽는 시간이었다는 사례예요. 플러그인은 창을 새로 열 때마다 하나씩 읽히기 때문에 개수만큼 기다림이 늘어납니다.
이 숫자가 팁으로 밀려나 있는 게 저는 아쉬웠어요. 글의 앞 절반은 Oh My Zsh 위에서 테마를 고르는 법을 보여주는데, 바로 그 Oh My Zsh가 지연의 절반이라는 사실은 끝에 가서야 나오거든요. 터미널은 하루에 한 번 여는 창이 아니라 탭과 분할로 종일 새로 여는 창입니다. 테마를 올리기 전에 셸 시작 시간을 한 번 재 두고, 플러그인을 넣을 때마다 다시 재 보는 습관이 테마 선택보다 값지다고 생각해요.
해커들이 프롬프트에 올려 둔 정보를 보면 왜 무거워지는지 짐작이 갑니다.
지금 있는 폴더, Git 브랜치와 변경 여부, 직전 명령의 성공 여부. Powerlevel10k를 쓰는 해커가 3명이었는데, 이런 정보는 프롬프트가 그려질 때마다 새로 계산됩니다. 쓸모 있는 정보인 건 맞습니다. 공짜가 아니라는 걸 알고 올리면 돼요.
효율은 테마에서 나오지 않았다
동의하지 않는 대목은 글의 출발점입니다. 화면이 깔끔하고 멋있어지면 그것만으로 효율이 좋아지지 않겠느냐는 질문으로 시작하는데, 정작 마지막 문단에 가면 "터미널 테마가 실제 작업에 엄청 큰 영향을 주진 않지만"이라며 물러서요. 저는 뒤쪽 문장이 맞다고 봅니다.
효율 설정으로 꼽힌 셋에는 공통점이 있습니다. zsh-autosuggestions는 히스토리에서 맞는 명령을 회색 글씨로 미리 보여주고, zsh-syntax-highlighting은 유효한 명령인지를 입력 중에 색으로 알려주고, `Ctrl + R`은 예전 명령을 몇 글자로 찾아줍니다. 전부 엔터를 누르기 전의 시간을 줄이는 장치죠. 실행하고 에러 메시지를 읽는 것보다 입력하다 알아채는 쪽이 싸다는 건, 코드 리뷰보다 린터가 싸다는 것과 같은 이치고요. 그리고 셋 중 제가 가장 크게 치는 `Ctrl + R`은 설치할 것도 없는 기본 단축키입니다. 위쪽 화살표를 연타하던 사람에게는 테마 열 개보다 이 단축키 하나가 커요.
설문 숫자도 같은 눈으로 읽어볼 만합니다.
본문은 절반이 iTerm2를 쓴다고 했지만 그래프는 44%입니다. VS Code라고 답한 사람은 3명인데 그래프에서는 12%고요. 3명이 12%가 되려면 분모가 25여야 하고, 실제로 44%·16%·12%·8%·20%를 25로 풀면 11·4·3·2·5로 딱 떨어집니다. 응답자는 22명이니 몇 명이 둘 이상을 골랐다고 읽는 게 자연스럽죠. 사소한 차이지만 설문을 인용할 때 "절반"과 "복수 응답 기준 44%"는 다른 문장입니다.
숫자 자체에서 가져간 건 두 가지예요. 2010년에 나온 iTerm2가 여전히 1위인 이유를 글은 막혔을 때 참고할 자료가 많아서라고 설명하는데, 도구 선택 기준으로 이만큼 정직한 것도 드뭅니다. 그리고 2024년 12월에 공개된 Ghostty가 2년이 안 돼 16%로 2위에 올랐어요. 자료의 양으로 고르는 사람들 사이에서 신생 도구가 이만큼 올라왔다면, 자료가 적다는 약점을 감수할 이유가 있었다는 뜻입니다. 설문은 그 이유까지는 묻지 않았고, 저는 그게 테마 목록보다 궁금했습니다. 에디터 내장 터미널만 쓴다는 답도 VS Code 3명, Emacs 1명이 있었는데, 창을 오가지 않는 쪽을 택한 사람들이죠.
tmux를 분할 도구로만 알고 있다면
네 번째로 고른 건 멀티플렉서 대목입니다. 화면을 나누는 기능만 보면 iTerm2의 `Cmd + D`와 tmux는 다를 게 없어요. 차이는 세션이 남느냐입니다. tmux에서 detach한 세션은 터미널 창을 닫아도 계속 돌고, 원격 서버에 붙어 긴 작업을 돌리다 연결이 끊겨도 서버 쪽에서 살아 있다가 다시 attach하면 화면 배치와 작업이 그대로 나옵니다. 앱의 분할은 창을 닫는 순간 같이 사라지고요.
이 대목의 조건부 결론에는 저도 동의합니다. 화면을 나누는 게 목적이면 앱 단축키로 충분하고, 원격에서 긴 작업을 자주 돌리는 사람에게만 tmux가 값을 해요. 재부팅하면 세션이 사라진다는 한계까지 적어 둔 건 이 글의 미덕입니다. macOS 기본 터미널의 `Cmd + D`가 셸을 하나 더 띄우는 게 아니라 같은 세션의 출력을 둘로 나눠 보여줄 뿐이라는 설명도, 모르면 한참 헤매는 부분이라 반가웠습니다.
86%가 다크 모드를 쓰지만 형광 초록을 쓰는 해커는 한 명도 없었다는 결과처럼, 터미널의 겉모습은 남이 상상하는 것과 실제가 다르고 사람마다도 다릅니다. 그래서 테마는 따라 할 게 못 돼요. 따라 할 건 그 밑에 깔린 선택입니다. 설정이 텍스트 파일로 남는 도구를 고르고, 플러그인을 넣을 때마다 시작 시간을 재고, 엔터 전에 실수를 잡아주는 장치부터 켜는 것. 새 노트북을 받은 날 이 세 가지가 돼 있는 사람은 금방 원래 환경으로 돌아오고, 테마에만 공들인 사람은 처음부터 다시 꾸밉니다.