Windows / MacOS 통합 터미널 환경 구축

들어가며

최근에 맥북 에어를 업그레이드한 것으로 인해 환경을 다시 세팅할 필요성이 느껴졌다.

m1 -> m5 성능적인 변화가 만족스럽긴 한데 기존에 사용하던 환경을 다시 맞춰주려고 하니까 손이 많이 가는 것을 확인했고, 이번 기회에 전체 과정을 문서화해서 편하게 다시 세팅할 수 있도록 규격화하고자 했다.

2026 Mac 터미널 완벽 세팅 (Ghostty + Starship + AI 코딩 환경)

그 과정에서 인상깊게 본 문서는 해당 링크의 자료였는데, 깔끔하고 멋지게 잘 세팅해 둔 환경을 스크립트 자료로 남겨두셔서 많은 도움을 받았다.

결론부터 이야기하자면 아래와 같은 형태로 터미널 환경을 구축할 수 있었다.

내부적으로는 Wezterm + Nushell + LazyVim를 큰 틀로 세팅하고 있다.

Github 링크 에서 세팅 전체 가이드를 확인할 수 있고, 해당 가이드를 통해 Windows, MacOS에 동일한 환경을 구축할 수 있도록 만들어 두었다.

목표 설정

해당 작업의 목표는 명확했는데

• Windows / MacOS에서 동일한 터미널 환경을 사용할 것

• LazyVim 기반의 편집기와 문제 없이 잘 작동할 것

• 기존 사용 환경과 크게 다르지 않을 것

• tmux와 같은 멀티플렉서 툴을 사용하기에 어려움이 없을 것

이와 같은 목표를 달성하기 위해 작업을 진행해 보았다.

진행 과정

일단 사용할 기술을 선택해야 했다. 일단 터미널 에뮬레이터는 GPU 가속 렌더링이 가능한 GUI를 가진 툴들이 요즘 트렌드고 실제로 이런 툴들이 각광받는 이유가 빠르고 데코레이션이 가능하다는 점 때문인데, 위에 안내한 링크처럼 터미널을 구축하기 위해서는 이런 요소가 필요했기 때문에 그들 중 Wezterm을 선택하게 되었다.

1. Terminal Emulator

   일단 크로스플랫폼에서 동일한 UX를 제공해야 했기 때문에 생태계가 구축된 크로스플랫폼 터미널 에뮬레이터로는 Alacritty, Wezterm 정도가 있다고 생각했고, 미니멀함을 추구하는 알라크리티는 확장성이 부족하다고 느껴져서 Wezterm을 선택하게 되었다. 멀티플렉서를 탑재하고 있다는 점도 메리트 중 하나.

2. Shell

   양쪽에서 동일한 사용감을 보장해야 했기 때문에 일단 unix 명령어를 사용할 수 있는 환경으로 통합하고자 했고, 그 결과 윈도우에서는 bash, 맥OS에서는 zsh를 사용하기로 초기에 결정을 했었다. 그러나 몇 가지 문제가 있었고 결국 최종안으로는 Nushell 기반으로 통합하게 되었다.

3. LazyVim

   사실 이쪽은 이미 사용하던 툴들이 있었고, 문제 없이 대부분 환경에서 통합되었기 때문에 어렵지 않았다. 원래 SpaceVim을 사용했었지만, 이쪽은 이미 유지보수가 중단된 상황이었기 때문에 LazyVim으로 넘어온지 어느 정도 시간이 지난 데에다가 기본적으로는 IDE를 사용하고 있고, 부수적인 툴로 사용하기 때문에 스무스하게 설치가 진행되었던 것 같다.

문제 봉착

이 과정에서 몇 가지 문제가 존재했는데, 두 문제가 모두 nushell로 넘어간 것과 연관이 되어 있다.

1. 윈도우에서는 bash가 체감이 될 정도로 너무 느림

   사실 이는 나중에 확인해보니 예정된 결말이었던 것 같다. 윈도우 환경 하에서는 POSIX 식 동작을 Windows에서 처리하기 위해 호환성 동작이 추가 레이어로 들어간다는 점을 확인할 수 있었다. 그래서 실제로 wsl2 환경으로 놓는 것도 고려했으나, 그건 결국 리눅스를 사용하는 것과 다르지 않기 때문에 배제했다.

   -> 이 문제를 해결하기 위한 tool로 nushell을 도입하게 되었다. unix 명령어와 호환되는 부분이 많다는 점, rust 기반으로 설계되어 어느 정도 성능도 보장되어 있다는 점, MacOS에도 동일한 환경 세팅이 가능하다는 점을 고려하였다.

2. Windows의 nushell에서 navi 플러그인이 작동하지 않음

   navi는 터미널 명령어 치트시트 참고용 플러그인이다. 그렇게 활용하는 빈도는 많지 않지만 해당 툴의 기능이 아예 동작하지 않으면 곤란했기 때문에 여러 방법을 고민해봤다. 결국 navi를 포크해서 해당 문제를 해결한 뒤, 새로 빌드한 플러그인을 사용하는 것으로 조치했다.

   • 원인: 사용자 shell이 변경되어도, 내부에서는 bash 기반의 문법을 적용하게 되어 nushell 사용 시에 깨지는 상황

   • 해결: 해당 부분을 shellscript를 통한 명령어로 처리하는 대신, 관련 의존성을 제거하기 위해 wget을 사용해야 하는 부분에서 rust http client를 사용하고, bash 사용해야 할 부분에서 pwsh를 사용하는 등 내부 helper가 bash에 의존하는 부분을 제거

   • 세부 수정 내역

결론

개발자는 터미널을 사용할 일이 꽤 있고, 환경이 하나로 통합되면 사용하기 편한 건 당연한 일이다. 그렇기에 크로스플랫폼과 동일한 사용성을 지원하는 Jetbrains의 IDE들이 메리트가 있는 것 아닐까? 마찬가지로 터미널에 있어서도 본인이 추구하는 바가 다양한 환경에서 통일된 사용감을 유지하는 거라면 이런 방식을 사용해보는 것도 괜찮은 것 같다.