로컬 개발 환경의 다이어트

얼마 전까지만 해도 필자는 다음과 같은 스펙의 로컬 개발 환경을 사용했었습니다. (이후로는 개발 환경이라고 줄여 적겠습니다.)

약 5년 간 개발하며, 사용하는 도구가 늘어나고 이미 사용하던 도구는 업데이트로 인해 무거워졌으며, 풀스택 애플리케이션을 개발하기 위해 여러가지 서버를 동시에 띄워야 했습니다. 따라서, 5년 전의 저에게 딱 맞는 개발 환경은 어느새 리소스가 가난한 상태가 되어버렸습니다. 이런 상황을 극복하기 위해 필자는 개발 환경의 리소스 다이어트를 시작했고, 장치가 침수되어 사망하기 전까지는 꽤 쓸만한 상태로 유지할 수 있었습니다. (btw R.I.P.)

이 글은 필자가 직접 경험했던 개발 환경의 다이어트 과정을 간략히 설명합니다.

Docker 도입: macOS는 Docker를 native하게 실행하지 못한다.

학부 시절 Docker를 처음 만나게 되었고 이후로 떨어져 산 적이 없습니다. Docker를 만나기 전에는 개발에 필요한 DB, 검색/모니터링 엔진, 런타임 등을 OS에 직접 설치하거나 VM을 만드는 등 지금보면 기괴하고 과학자처럼 개발 환경을 세팅했었습니다.

하지만 Docker를 개발 환경에 도입 후, 프로젝트 간 이동 시, 요구사항 세팅 과정을 획기적으로 단축할 수 있었으며, 이대로 행복이 이어지는 줄 알았습니다.

macOS는 Docker를 native하게 실행하지 못한다.

현실은 차가웠습니다. Docker는 리눅스 환경에서만 native하게 실행시킬 수 있었으며, Docker의 관리를 위해 사용하던 Docker Desktop은 내부적으로 VM을 사용하며, 이는 곧 상시적인 리소스 점유와 개발 환경의 성능 저하로 이어졌습니다. 이 문제를 해결하기 위해 차마 Docker를 포기할 수 없던 필자는 홈 서버를 구축하게 되었습니다.

apple/container가 있지만, 아직 Docker가 익숙합니다 :|

홈 서버 구축: 로컬에서 멀어지다.

Docker가 리눅스에서만 native하게 동작한다면, 직접 리눅스 환경을 구축하고 싶다.

라고 생각한 필자는 개발 환경을 리눅스 데스크탑으로 변경하려 했지만, 랩탑을 사용해야 할 상황이 많았고, 데스크탑에 Arch Linux를 설치해 윈도우와의 듀얼부트로 몇 달 간 사용해봤지만, Secure Boot 모드를 사용할 때 몇번 이슈가 발생했으며, 3종류(영어/한글/일어) IME의 전환도 매끄럽지 않아 불편했었습니다.

때문에 홈 서버를 구축하고자, 집에서 놀고있는 컴퓨터 부품들을 모아 Ubuntu Minimal을 설치하고, 해당 서버에 Docker를 설치했습니다. 그 결과, 로컬 개발 환경에서의 Docker는 완전히 제거하고 필요한 컨테이너를 사용할 때 사용할 리소스는 전부 서버에게 위임할 수 있었습니다.

홈 서버는 GUI-less 환경이기에 Docker를 관리할 때 lazydocker 를 자주 사용합니다.

번외) 홈 서버 침입 흔적: 외부망으로부터 홈 서버를 숨겨야 한다.

이때의 필자는 외부에서도 홈 서버에 접속해야 한다는 목적을 위해 ssh 포트를 외부에 오픈하고 password 기반 인증을 허용해두었었습니다. "ssh의 리스닝 포트만 22번이 아닌 임의의 포트로 변경해두면 되지" 라는 괴물같은 생각을 하고 있었으며, 이후 서버의 로그를 보고 두 눈을 의심했습니다. 포트 스캐닝 로그와 불특정 다수의 무수히 많은 ssh 접속 시도는 필자가 네트워크 공부를 하게 만들기 위해 충분했으며, 이후 모든 포트를 닫고 내부망에서만 리소스에 접근할 수 있도록 정책을 변경했으며, 서버에 WireGuard VPN을 설치하고 VPN 접속을 위한 포트만 외부에 열어두었습니다.

WireGuard는 기본적으로 "침묵" 상태이기에 포트 스캐너에 잘 걸리지 않습니다. WireGuard 백서 쉽게 읽기

AeroSpace 도입: 무거운 도구가 내 장치에 설치되다.

AeroSpace 란 macOS에서 사용 가능한 TWM(타일링 윈도우 매니저) 입니다.

Hyprland, i3를 맛보고 난 후 TWM에 중독되어, macOS에서도 AeroSpace를 도입한 것은 제 개발 환경에 있어서 큰 변화이자 충격이었습니다. 필자가 처음 AeroSpace를 설치할 때는 싱글 스레드로 동작했기에 성능 문제가 있었으며(현재는 해결), JetBrains IDE와의 호환도 좋지 않았습니다.

하지만 단순 브라우징, 터미널 환경에서는 꽤 쓸만한 성능을 보여줬으며, 결과적으로 개발 환경을 터미널로 천천히 이사하기 시작했습니다.

터미널 환경으로 이사하다.

터미널 환경으로 이사하기 시작하면서 우선적으로 적응했던 도구는 코드 작성을 위한 Neovim이었습니다. 필자는 기존에 IDE 환경에서도 Vim 플러그인/키매핑을 사용했었기에 적응에 큰 장애는 없을 거라 예상했지만, 탭이 아닌 버퍼의 개념을 사용하거나 IDE에는 당연했던 기능들이 빠져 있었기에 그대로 사용하는 것은 용납할 수 없었습니다. 이 문제를 해결하기 위해 LazyVim을 설치하였으며, 이를 통해 약간의 커스터마이징만으로 쾌적한 코드 작성 환경을 구축할 수 있었습니다.

이외에도 아까 설명한 lazydocker라던가 gitui, lsd, television, zoxide 등 다양한 CLI/TUI 도구들을 사용하게 되었습니다.

그럼에도 터미널 환경의 도구로 이전하기 힘든 작업들이 존재했습니다. Java/Kotlin + Spring 프로젝트를 관리할 때는 IntelliJ가 기능면에서 압도적으로 편리하였으며, DB 클라이언트도 CLI/TUI 기반은 적응이 어려웠습니다. 때문에 VSCode 또는 Zed와 같이 가벼운 도구를 시도해봤으며, 결과적으로는 도구들을 상황에 따라 번갈아 사용하게 되었습니다.

현재 AeroSpace의 성능 문제는 많이 개선되었으며, JetBrains IDE도 쾌적하게 사용 가능합니다. 출처

결과

당시 개발하던 Spring 프로젝트의 빌드 속도를 43% 향상시킬 수 있었으며, 터미널 개발 환경으로 이전하면서 기존에 간간이 발생하던 프리징 문제를 해결할 수 있었습니다.

또한, Docker를 외부 서버에 분리하면서 다른 개발 환경에서도 연속적으로 작업을 진행할 수 있는 의외의 이점도 있었습니다.

개인적으로 가장 마음에 드는 결과는 귀여운 홈 서버가 생겼다는 것과 Vimmer 타이틀입니다. :)