내 개발 생산성을 바꾼 도구들

개발자들은 도구에 대한 글을 좋아한다. 나도 좋아한다. "이 사람은 뭘 쓰지?" 궁금해서 다른 개발자들의 uses 페이지를 자주 본다. Stefan Judis라는 웹 개발자는 자신의 uses 페이지에 쓰는 도구를 상세하게 정리해두는데, Firefox를 메인 브라우저로 쓰면서 "브라우저 다양성이 중요하다"고 적어둔 걸 보고 인상적이었다. 도구 선택에 가치관이 묻어나는 사람.

근데 대부분의 도구 추천 글은 "내가 쓰는 것들 리스트"에서 끝난다. 왜 그걸 쓰게 됐는지, 이전에는 뭘 썼는지, 바꾼 후에 실제로 뭐가 달라졌는지는 잘 안 나온다. 도구 자체보다 도구를 바꾸는 과정에서 배우는 게 더 많은데.

이 글은 내가 2년 동안 도구를 바꿔온 이야기다. 채택한 것, 버린 것, 후회하는 것. 생산성 숫자를 넣을 수 있는 건 넣었다. 체감일 뿐인 건 체감이라고 적었다.

1년 차: 남들이 쓰는 걸 따라 쓰다#

입사하고 처음 6개월은 도구를 고를 여유가 없었다. 팀에서 쓰는 걸 그대로 썼다. VSCode, Chrome DevTools, Slack, Notion, GitHub. 거기에 개인적으로 iTerm2와 Oh My Zsh를 깔았다. 터미널을 예쁘게 만드는 데 반나절을 썼는데, 돌이켜보면 그 시간에 Git 명령어를 하나 더 외우는 게 나았을 것 같다.

이 시기에 가장 큰 생산성 향상을 준 건 도구가 아니라 단축키였다. 선임 개발자가 코드 리뷰를 하는 걸 옆에서 보는데, 마우스를 거의 안 쓰더라. Cmd+P로 파일 열고, Cmd+Shift+F로 전체 검색하고, Cmd+D로 다중 커서. 나는 사이드바에서 파일을 클릭해서 열고 있었다.

그 후 2주 동안 의식적으로 마우스를 덜 쓰려고 노력했다. 불편했다. 근데 2주가 지나니까 손이 기억하기 시작했다. 체감 속도가 확실히 달라졌다.

이 시기에 배운 것: 새 도구를 설치하기 전에, 지금 쓰는 도구의 단축키를 먼저 익혀라.

VSCode 확장: 정리하기까지 6개월 걸렸다#

입사 초기에 "추천 VSCode 확장" 글을 보고 20개 넘게 깔았다. Bracket Pair Colorizer, Auto Close Tag, Auto Rename Tag, Path Intellisense, indent-rainbow, GitLens, Prettier, ESLint, Import Cost, TODO Highlight...

6개월 후에 정리했다. 20개 중 실제로 쓰는 건 6개뿐이었다.

남긴 것들:

ESLint + Prettier (이건 필수)
GitLens (git blame이 인라인으로 보이는 게 코드 리뷰에 도움)
Error Lens (에러를 인라인으로 보여줘서 Problems 탭을 안 봐도 됨)
GitHub Copilot (아래에서 따로 다룸)
Thunder Client (간단한 API 테스트용, Postman 켜기 귀찮을 때)
Todo Tree (TODO, FIXME를 사이드바에서 한눈에)

버린 것들과 이유:

Bracket Pair Colorizer: VSCode에 내장됨. 확장이 필요 없어졌다.
Auto Close Tag, Auto Rename Tag: VSCode의 linked editing 설정으로 대체 가능.
indent-rainbow: 처음엔 예뻤는데, 화면이 산만해져서 끔.
Import Cost: 번들 사이즈를 매번 보여주는 건 좋은데, 에디터가 느려지는 느낌이 있었다. 번들 분석은 빌드 타임에 하는 게 맞다.

확장을 정리하고 나서 VSCode 시작 시간이 체감될 정도로 빨라졌다. 정확한 측정은 안 했지만, "잠깐 기다리는 느낌"이 사라졌다.

배운 것: 확장은 설치보다 삭제가 중요하다. 한 달에 한 번은 "이거 실제로 쓰고 있나?" 점검하는 게 좋다.

GitHub Copilot: 가장 논쟁적인 도구#

Copilot을 쓴 지 1년쯤 됐다. 솔직한 평가를 하자면, 하루에 20분 정도 절약해주는 것 같다. 주로 보일러플레이트 코드에서. 테스트 코드 작성, 반복적인 타입 정의, CRUD 패턴 같은 것들.

근데 비용도 있다.

Copilot이 도움이 되는 순간들:

테스트 코드 작성. describe/it 블록의 구조를 잡아주고, 비슷한 패턴의 테스트를 빠르게 찍어낸다. 여기서 제일 시간을 아낀다.
정규표현식. 주석으로 "이메일 형식 검증"이라고 쓰면 적절한 정규식을 제안한다.
타입 정의. 인터페이스의 필드를 몇 개 쓰면 나머지를 유추해서 제안한다.

Copilot이 해로운 순간들:

잘못된 패턴을 자신 있게 제안할 때. 특히 최신 API나 라이브러리 버전에서 deprecated된 패턴을 추천하는 경우가 있다. 한 번은 Next.js App Router 코드에서 Pages Router 패턴을 제안해서, 그걸 그대로 쓴 적이 있다. 30분짜리 디버깅으로 이어졌다.
코드를 "읽지 않게" 만들 때. Copilot이 여러 줄을 한번에 제안하면, 내용을 읽지 않고 Tab을 누르는 습관이 생긴다. 이게 쌓이면 내 코드인데 내가 모르는 코드가 된다.
복잡한 비즈니스 로직에서. Copilot이 문맥을 완전히 이해하지 못하는 경우, 겉보기에 그럴듯하지만 엣지 케이스를 놓치는 코드를 제안한다.

결론적으로 유지하고 있다. 근데 Tab을 누르기 전에 3초 읽는 습관을 의식적으로 들이고 있다. 그 3초가 30분짜리 디버깅을 막아줄 때가 있다.

터미널: iTerm2에서 Warp로, 다시 iTerm2로#

Warp가 나왔을 때 흥분해서 바로 갈아탔다. AI 기반 터미널. 명령어 자동완성, 블록 기반 출력, 팀 공유 기능. 미래의 터미널이라고 생각했다.

3개월 썼다. 다시 iTerm2로 돌아왔다.

이유가 몇 가지 있다. 첫째, Warp의 블록 기반 UI가 오히려 불편한 순간이 있었다. 긴 로그를 스크롤할 때 블록 단위로 움직여서, 원하는 줄을 찾기가 어려웠다. 둘째, 메모리 사용량이 눈에 띄게 높았다. 맥북 팬이 돌아가는 빈도가 늘었다. 셋째, 가끔 SSH 연결에서 렌더링이 깨지는 문제가 있었다.

돌아오면서 iTerm2를 제대로 설정했다. 이전에는 Oh My Zsh만 깔고 끝냈는데, 이번에는 시간을 들여서 설정했다.

Oh My Zsh에서 Starship으로 프롬프트 변경. 훨씬 가볍고 빠르다.
zsh-autosuggestions: 이전에 입력한 명령어를 회색으로 보여줌. 이거 하나로 타이핑이 체감 30% 줄었다.
zsh-syntax-highlighting: 명령어가 유효하면 녹색, 잘못되면 빨간색. 실행 전에 오타를 잡아준다.
fzf: 파일 찾기, 히스토리 검색. Ctrl+R로 히스토리를 퍼지 검색하는 게 특히 좋다.

배운 것: 새로운 도구가 항상 나은 건 아니다. 기존 도구를 제대로 설정하는 게 먼저다.

메모 도구: Notion에서 Obsidian으로#

팀에서는 Notion을 쓴다. 개인 메모도 Notion에 했었다. 근데 1년 쯤 쓰다 보니 불만이 쌓였다.

오프라인에서 못 쓴다. 카페에서 와이파이가 끊기면 메모를 못 한다.
느리다. 페이지 로딩에 체감 1~2초. 빠르게 메모하려는데 로딩을 기다리는 게 짜증났다.
구조를 강제한다. 데이터베이스, 페이지, 블록. 빠르게 생각을 적고 싶을 때 구조가 방해가 된다.

Obsidian으로 바꿨다. 로컬 마크다운 파일 기반이라 오프라인에서도 되고, 빠르고, 자유롭다.

가장 좋은 건 데일리 노트다. 매일 자동으로 빈 파일이 생기고, 거기에 생각나는 걸 막 적는다. 오늘 배운 것, 삽질한 것, 나중에 찾아볼 것. 구조 없이 그냥 적는다. 나중에 검색으로 찾으면 된다.

한 달에 한 번 정도 데일리 노트들을 훑어보면서 반복되는 패턴을 발견한다. "이 라이브러리 삽질했다"가 3번 나오면 별도 문서로 정리한다. 아래에서 위로 쌓이는 구조. 미리 카테고리를 만들어두는 것보다 이게 훨씬 자연스럽다.

단점: 팀과 공유가 안 된다. 그래서 팀 문서는 여전히 Notion이다. 개인 메모만 Obsidian. 두 도구를 병행하는 건 좀 번거롭지만, 각자의 역할이 명확해서 괜찮다.

후회하는 도구 채택들#

Vim 키바인딩. VSCode에서 Vim 확장을 깔고 2주 동안 고생했다. 생산성이 바닥을 찍었다. 2주면 적응된다고 했는데, 나는 3주째에도 dd와 yy가 헷갈렸다. 결국 포기했다. Vim이 나쁜 도구라는 게 아니라, 이미 VSCode에 익숙한 상태에서 전환하는 비용이 내 상황에서는 이점보다 컸다.

Docker Desktop. 프론트엔드 개발하면서 Docker를 쓸 일이 거의 없는데, "개발자라면 Docker 정도는 알아야지"라는 생각에 깔았다. 맥북의 RAM 16GB 중에 Docker가 평소에 2GB를 먹고 앉아 있었다. 한 달에 한두 번 쓰는 도구가 매일 메모리를 차지하는 건 말이 안 됐다. 삭제하고 필요할 때만 OrbStack을 켜는 걸로 바꿨다. OrbStack이 Docker Desktop보다 가볍다.

화려한 대시보드 도구들. WakaTime으로 코딩 시간을 트래킹하고, GitHub contribution 그래프를 신경 쓰고. 한동안 숫자에 집착했다. "오늘 8시간 코딩했다"는 기록이 뿌듯했으니까. 근데 6개월쯤 뒤에 깨달았다. 코딩 시간이 길다고 생산적인 게 아니다. 4시간 집중해서 끝낸 날이 8시간 늘어지며 한 날보다 결과물이 나았다. WakaTime은 삭제했다.

2년 차의 도구 스택#

지금 쓰고 있는 도구와 그 이유를 정리하면 이렇다.

에디터: VSCode. 확장 6개. 이 이상 늘리지 않으려고 의식적으로 노력한다.

터미널: iTerm2 + Starship + zsh-autosuggestions + fzf. 이 조합이면 충분하다.

브라우저: Chrome (개발). 가끔 Firefox로 크로스 브라우저 테스트. Safari는 iOS 테스트 때만.

메모: Obsidian (개인), Notion (팀).

API 테스트: Thunder Client (간단한 것), Bruno (팀 공유 필요할 때). Postman은 무겁다.

Git GUI: 안 쓴다. CLI로 충분하다. git log --oneline --graph면 히스토리도 잘 보인다.

디자인 확인: Figma. 선택의 여지가 없다.

AI: GitHub Copilot. Tab 전에 3초 읽기.

도구에 대한 관점 변화#

2년 전에는 도구를 많이 아는 게 실력이라고 생각했다. 새 도구가 나오면 바로 써봐야 뒤처지지 않는다고. 지금은 생각이 다르다.

좋은 도구는 투명해야 한다. 도구를 의식하지 않고 작업에 집중할 수 있어야 한다. 도구 자체가 주의를 끌면 그건 안 맞는 거다. Warp의 화려한 UI가 나한테 안 맞았던 이유도 이거다. 터미널은 명령어를 치고 결과를 보는 곳이지, 예쁜 인터페이스를 감상하는 곳이 아니다.

도구를 바꾸는 데는 비용이 있다. 새 도구에 적응하는 시간, 이전 도구의 설정을 마이그레이션하는 시간, 근육 기억을 다시 만드는 시간. 이 비용을 상쇄할 만큼 새 도구가 나은지 최소 2주는 써본 후에 판단하는 게 맞다. 첫날의 흥분으로 결정하면 후회한다.

그리고 가장 중요한 건, 도구는 생산성의 10%쯤이라는 거다. 나머지 90%는 문제를 이해하는 능력, 코드를 설계하는 능력, 디버깅하는 능력. 도구를 아무리 최적화해도, 뭘 만들어야 하는지 모르면 빠르게 삽질할 뿐이다.

지금도 가끔 새 도구가 나오면 설레긴 한다. 근데 이제는 "이거 정말 내 워크플로우의 병목을 해결하는가?"를 먼저 묻는다. 답이 "아니"면 설치하지 않는다. 2년 전의 나한테 이 말을 해줬으면 반나절짜리 터미널 커스터마이징은 안 했을 텐데.