▲

좋아하는 개발자 도구는 무엇인가요?

 (lobste.rs)
33P by GN⁺ | ★ favorite | 댓글 7개
  • 에디터 영역에서는 Helix, Emacs, Neovim, Sublime Text, Zed, JetBrains IDE가 반복적으로 언급되며, 각자의 trade-off가 명확히 드러남
  • 버전 관리 분야에서 jujutsu(jj)가 git CLI를 대체하는 흐름이 두드러지고, Magit·lazygit·Sublime Merge 같은 GUI 보조 도구도 다수 거론
  • 셸·터미널·환경 관리에서는 Fish, WezTerm, Ghostty, kitty, tmux, Nix, mise, atuin, fzf 등이 핵심 스택으로 등장
  • 반복되는 키 메시지는 "기본값이 좋은 도구를 골라 끝없는 설정을 피하자" 와 "나이 들수록 도구를 내게 맞추기보다 좋은 기본값에 적응" 이라는 합의 (반대 의견도 함께 존재)

토론 배경

  • Lobsters에 올라온 "개발자가 가장 좋아하는 도구는?" 질문 스레드 "개발자들은 의견이 강해서 단 하나의 도구를 꼽기 어렵다"
  • 19시간 만에 130개 이상의 댓글이 달림
  • 반복적으로 등장한 철학: "나이 들수록 도구를 내게 맞추기보다 좋은 기본값을 가진 도구에 내 선호를 맞춤", "가장 잘 테스트된 경로에 있게 되어 버그도 적게 만남"
    • 반대 의견: "나이 들수록 나쁜 기본값에 대한 인내심이 줄어듦. 몇 분 안에 사용 가능한 상태로 못 만들면 다른 도구로 교체"

텍스트 에디터 / IDE

  • Helix

    • "커스터마이즈 가능성과 우수한 기본 경험의 적절한 균형점"
    • jujutsu와 함께 사용 시 커밋 전환 후 열린 파일 수동 reload 필요 — 임시 대응으로 :reload-all 키바인드 사용
    • 파일 감시 기능 PR(#14544)이 maintainer에 의해 진행 중
    • selection-first 모델에 적응 못해 vim으로 회귀하는 사례도 다수
    • vim 키바인딩 일부 지원 포크: evil-helix

  • Emacs

    • 단순히 "Emacs"라고만 답한 사용자가 다수
    • Magit은 별도 언급될 만큼 호평
    • 영역별 이전 흐름: Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org-mode, Finder → dired

  • Neovim

    • "10년 이상 사용한 .vimrc를 은퇴시키고 Neovim으로 완전 이전함"
    • 플러그인 디스트리뷰션 흐름:
      • LazyVim: 가장 완성도 높음, flash.nvim 키바인드는 비활성화 권장
      • AstroNvim: 더 슬림한 대안
      • Kickstart.nvim: 커스터마이즈 기반 단순 시작점
      • MiniMax: mini.nvim 팀이 만든 시작 config

  • JetBrains IDE

    • PyCharm의 디버거 강력 추천 — Django REPL 내부에서도 동작, 템플릿 HTML/CSS/JS 지원, cherry-pick hunk 가능
    • 2개 이상 JetBrains 제품 사용 시 All Products 라이선스가 더 저렴

  • Sublime Text / Zed

    • "Sublime Text는 과소평가받음", 20년 이상 매일 사용한다는 응답
    • 코딩은 다른 곳에서 하더라도 빠른 성능, 영속 unsaved buffer가 매일 쓰는 이유
    • VSCode가 비대해져 Zed로 이전 시도 흐름도 등장

  • Kate / Notepad++

    • Linux 진영의 Kate, Windows 진영의 Notepad++도 단답으로 언급

버전 관리

  • jujutsu (jj) — 올해 가장 많이 호명된 도구

    • "git CLI를 버릴 줄은 몰랐는데 결국 그렇게 됨"
    • "더 쉬우면서 동시에 더 강력한 도구는 드문데, jujutsu는 둘 다 해냄"
    • rebase와 commit amend가 즐거워진다는 평
    • 단점: 기본값이 다듬어지지 않아 color/template 조정 필요 — "고대비 무지개 유니콘 토사물 텍스트"가 기본

  • Git 보조 도구

    • tig: "git log 개선판", 인터랙티브 staging에 활용
    • Magit: Emacs 사용자의 핵심
    • Sublime Merge: "git의 GUI 레이어지만 매우 잘 만들어짐", jj와도 merge-editor = "smerge"로 통합 가능
    • lazygit: rebase, revert, stash, 다중 remote 같은 복잡한 작업을 적극 시도하게 만듦
    • delta: git pager로 설정 시 syntax-highlighted diff, lazygit과 결합하면 side-by-side / inline 토글 가능
    • difftastic: 줄 단위가 아닌 syntax 기반 diff
    • git revise: "git에 기본 포함되어야 함"
    • Beyond Compare: 20년간 사용된 diff/merge/folder 동기화 도구

셸 / 터미널

  • Fish

    • "bash·zsh가 하는 일을 모두 처리하면서 별다른 설정 없이 훌륭한 경험"
    • 필요 시 bash 스크립트도 그대로 실행 가능
    • 새 단축키를 지속적으로 발견하게 되는 도구로 평가 (예: alt+<left|right> 디렉토리 히스토리)

  • 터미널 에뮬레이터

    • WezTerm: 키보드만으로 복사/붙여넣기(ctrl+shift+space), ctrl+shift+t로 동일 시스템에 탭 복제, 내장 SSH 클라이언트와 멀티플렉서
    • Ghostty: macOS 네이티브 통합 — Cmd+Ctrl+D 사전 팝오버, 드래그앤드롭, 네이티브 탭, 폰트 렌더링 품질
    • kitty: "기본값이 그냥 작동하면서 동시에 설정 여지가 많은 좋은 도구의 표본"

  • tmux

    • 터미널 세션을 열면 가장 먼저 실행하는 명령
    • SSH 종료/실수로 닫힌 터미널 대비 — Mac과 NixOS 환경을 오가도 동일 패턴 유지 가능

  • Starship

    • 어떤 셸에도 플러그인 가능, 단점은 대형 repo에서 git status·branch 명령이 느림

환경 / 의존성 관리

  • Nix / NixOS

    • "Stockholm syndrome일 수도 있지만 다른 Linux 배포판과 빌드 시스템을 못 쓰게 만듦"
    • 프로젝트별 nix shell로 시스템 패키지를 최소화, 글로벌 PATH 오염 없이 정확한 버전 고정 가능
    • "1년 후, 5년 후에도 동일하게 동작할 거라는 높은 확신"
    • "학습곡선만 넘으면 마법 같음. OS 구성이 원래 이래야 했음"

  • mise

    • direnv를 대체하는 도구 버전 매니저, 가벼운 CI에도 통합
    • "asdf의 strictly better한 대체재"
    • mise activate 기능 발견 시 direnv를 완전 제거 가능
    • mise watch와 task 시스템으로 프로젝트별 액션, 파일 변경 시 작업 실행

  • Dev Containers

    • docker/container 배포 환경과 dev 환경 공유 가능이 장점
    • 단점: tooling이 미성숙 (reference CLI에 stop 명령조차 미구현)

  • chezmoi

    • 작업·개인 머신 전반에서 일관된 개발 환경 유지, git alias·Neovim config·access token·기타 도구 설치를 함께 관리

디버깅 / 프로파일링

  • rr — record/replay 디버거

    • "C/C++ 디버깅의 주력 도구, 한 번 기록하면 결정론적으로 무한히 재생"
    • 메모리 주소 watch 후 마지막 쓰기 시점까지 되감기 가능
    • "temporal debugging bisection" — watchpoint와 함께 메모리 손상 발생 지점을 앞뒤로 탐색

  • Pernosco

    • time-travel + 데이터 흐름 분석 디버거
    • Firefox의 멀티 콘텐츠 프로세스 focus handling, about:blank Chrome 호환성 작업에 결정적 도움

  • RenderDoc / Tracy / RemedyBG

    • RenderDoc: 그래픽 디버깅의 만능 도구, XCode Metal 디버거보다 기본 기능 우수
    • Tracy: "무제한 리소스로 프로파일러를 만든다면 결국 Tracy가 됨"
    • RemedyBG: 작업 편의성이 좋은 디버거

  • XCode Instruments

    • 3D/GPU 셰이더 프로파일링에서 per-line runtime cost 주석 제공
    • stall 원인 분석 — 메모리 페치 대기, 동기화 대기, 제어 흐름 발산 구분
    • "하드웨어·드라이버·Metal 셰이딩 언어·툴링까지 모두 통제하는 생태계의 이점"

  • 기타

    • strace, extrace, perf — 디버깅 필수 조합
    • gdb — 여전히 단답으로 다수 언급

검색 / 텍스트 처리

  • fzf: shell 역방향 검색 통합, "fuzzy 정도가 적절"
    • rg '' | fzf 패턴으로 전체 repo 텍스트 검색, 매칭 선택 시 즉시 vim foo.rs +123 형태로 셸 프롬프트에 반환
  • ripgrep: "out of the box로 올바른 동작, 설정 시도조차 한 적 없음"
  • septum: 상호작용 코드 검색 — "7줄 이내에 triangle·vertex·mesh를 모두 포함하되 physics는 제외" 같은 조건부 검색
  • fastmod / spacemod: 대량 치환
  • autojump: j whatevs로 과거 작업 디렉토리 히스토리에 fuzzy 매칭하여 이동
  • zoxide: autojump 유사, 더 부드러운 네비게이션
  • awk: "약간만 추출해서 약간만 손보는 작업"에 여전히 강력
  • entr: "이 파일들을 감시해서 이걸 실행해" — 코드베이스 테스트 자동 실행에 적합

JSON / 데이터 / 변환 도구

  • jq: JSON 처리 사실상 표준, manual을 끝까지 읽기를 추천, Exercism의 jq track도 권장
    • gojq: native jq보다 에러 메시지가 압도적으로 우수, yaml 입력 지원으로 muscle memory 그대로 활용 가능
  • fx: 큰 JSON 출력 드릴다운
  • hexdump: 특히 hexdump -C가 임베디드 디버깅에 유용 — picocom --baud 115200 /dev/ttyUSB | hexdump -C 패턴
  • hexyl: 컬러 hex 뷰어
  • bat: cat의 syntax-highlighted 대체
  • choose, fd: 각각 cut, find의 대체

셸 히스토리 / 클립보드 / 노트

  • Atuin: shell history 동기화, 디렉토리·git repo 컨텍스트 기반 히스토리 검색
  • CopyQ: 약 2000개 항목의 클립보드 매니저, 메모를 놓쳤을 때 과거 작업 복원 가능
  • histprune: fzf의 Ctrl+R 커스텀 — alt+D로 히스토리 항목 즉시 삭제
  • Obsidian: Logseq에서 이전, 순수 Markdown 보관이 LLM/agent 협업에 유리
  • Joplin: AGPLv3, 데스크탑·모바일·웹 앱 모두 지원, WebDAV/OneDrive/S3 backend, .md 파일 그대로 저장

빌드 / 작업 자동화

  • just: make 대체 — 빌드가 아닌 task에 초점, 언어 무관 just lint 같은 일관된 인터페이스
    • "make의 줄 단위 모드와 shell/python/node 풀스크립트 모드를 target별로 토글 가능"
    • 단점: 임베디드 스크립트를 $TMPDIR에 쓴 뒤 실행, 자체 템플릿 언어 사용 (uncanny valley)
  • Task (go-task): yaml 기반 대안, batteries-included 성향
  • universal-test-runner: repo의 테스트 방식 자동 감지 후 실행, 추가 args pass-through
  • chezmoi: 머신 간 dotfile·도구 설치까지 일관 관리

HTTP / 네트워크 / 시크릿

  • Hurl: "정보를 수집하려 드는 GUI HTTP 앱을 잊자" — 단순 텍스트 포맷으로 curl 요청, 통합 테스트에 적합
  • curl: 단답으로 다수 언급
  • SOPS: age/SSH key로 시크릿 암호화, sops exec-env secrets.yaml -- some command 패턴
  • Mutagen: SSH 위에서 양방향 실시간 파일 동기화 — 원격 머신 작업에 유용
  • forge: GitHub CLI 대체, Codeberg 지원, 더 빠르고 정돈됨

기타 / 워크플로

  • Quarto: markdown으로 빠른 프레젠테이션
  • Nushell: PowerShell 영향을 받은 셸, GeoPackage → PostGIS, PostGIS view → PMTiles 같은 대규모 변환 스크립트를 신뢰성 있게 작성. 단점: 1.0 이전이라 업데이트마다 깨짐
  • Typst: LaTeX 대체로 언급, call-by-value 기반 문법 선호
  • Topiary: 다국어 포매터
  • Hunk: agentic coder를 위한 review-first terminal diff 뷰어, --watch 모드를 코딩 에이전트 옆에 띄워두는 패턴
  • Raycast / Alfred: macOS 런처, snippet·클립보드·파라미터화된 웹 검색
  • Ergodox EZ: 10년 사용한 키보드, 커스터마이즈·전력 모두 만족
  • Joplin / Fossil: 노트와 위키 자가호스팅
  • AeroSpace / Sway: 타일링 윈도우 매니저

반복되는 메타 메시지

  • "기본값이 좋은 도구를 골라 끝없는 설정을 피하자" — Helix, Fish, ripgrep, mise가 이 철학의 대표 사례로 호명
  • 반대 관점: 끝없이 tweak한 결과 자기만의 도구 체계를 완성한 사례도 있음 — "지금은 1년에 몇 번만 손봄"
  • AI 에이전트 시대의 부산물: jq·Markdown·structured text 도구가 LLM과의 협업에 유리하다는 인식 확산 — Obsidian의 순수 Markdown, hunk의 watch 모드, jq의 manual 학습 권장 등이 같은 흐름
  • macOS의 그래픽 디버깅 우위: XCode Instruments의 GPU 프로파일링이 Linux/Windows 대비 압도적이라는 평가
  • CLI 르네상스 vs 타이포그래피: 터미널 도구가 풍요로워지는 동시에, 긴 LLM/agent 출력은 결국 브라우저나 전용 앱의 타이포그래피가 더 읽기 좋다는 양가 관찰

함께 보면 좋은 글 β

▲
edunga1   [-]

맥 기준, 터미널에서 한글 입력하려면 엔터 두 번 눌러야 하지 않나요?(한글 조합 완성 후 입력까지 2번)
유일하게 wezterm만 이런 문제가 없어서 갈아탔거든요.

답변달기
▲
xguru   [-]

cmux, tmux, mux 세개를 요즘 묶어서 잘 쓰고 있어요.
tailscale 로 묶은 서버에 cmux로 ssh 로그인 하면 fzf로 기존 tmux 로그인들 묶어서 보여주고, 거기서 선택해서 들어갑니다.
들어간 상태에서는 mux 로 전환하고요

cmux - AI 코딩 에이전트를 위한 Ghostty 기반 macOS용 터미널
Show GN: mux – AI 코딩 세션을 라이브 프리뷰로 전환하는 tmux 세션 매니저

답변달기
▲
snisty   [-]

나는 이제 Claude Code 없이 살수없는 몸이 되어버렸어. + tmux..
추가하자면 vscode로 텍스트 편집기..
그게 아니면 빌드용 Visual Studio 같은 필수 IDE 정도..

답변달기
▲
hwhang0917   [-]

fzf, jq, rg, awk ❤️

답변달기
▲
jjpark78   [-]

neovim, alacritty, tmux, fzf, rg, obsidian, bat, jq, hurl, lazygit, hammerspoon, chrome, codex, claude,

답변달기
▲
GN⁺   [-]
Lobste.rs 의견들

  • Helix를 텍스트 편집기로 쓰고 있음. 내게는 사용자화 가능성과 훌륭한 기본 경험의 균형이 딱 맞음
    같은 이유로 터미널 셸은 Fish를 씀. 기본 상태가 훌륭하고, 원하는 대로 쓰기 위해 조정할 것이 거의 없음
    나이가 들수록 끝없이 설정을 만지기보다, 의도적으로 좋은 기본값을 가진 도구에 내 취향을 맞추는 쪽이 더 좋아짐
    Atuin은 원격 머신 간 셸 기록 동기화와 현재 디렉터리나 git 저장소 기반의 맥락적 기록 검색에 좋음. 다른 기능도 있지만 나는 이 기능들만 씀
    Mise도 여러모로 마음에 들지만, 주로 도구 버전 관리자로 가장 좋아함. 예전에 쓰던 direnv를 대체했고, 개인 프로젝트에서는 가벼운 CI 흐름에도 조금씩 통합하기 시작함

    • 좋은 기본값을 따르는 경로가 가장 많이 테스트된 경로라서 버그를 덜 만남. 대체로 현명한 선택임
    • “기본값에 취향을 맞추기”와 “끝없이 설정 만지기”만 있는 건 아님. 내 n=1 경험으로는 계속, 계속, 계속 설정을 만지다가 결국 원하는 지점에 도달했고, 이제는 거의 안 만짐
      1년에 몇 번 정도뿐임. 내 Emacs는 나만의 Studley 공구함 같은 상태임
    • Helix를 좋아하고 싶음. 정말 매끈한 프로젝트고 기본값도 매력적인데, Vim 근육 기억이 너무 많이 쌓여 있음
      대신 몇 달 전에 Neovim을 완전히 받아들였고, 10년 넘게 유기적으로 자라난 .vimrc를 은퇴시켰음. 조금 아쉬웠지만 Helix가 덜 부러워짐
      Mise도 좋고, 사실상 설정이 거의 필요 없음. Fish도 몇 달 전부터 쓰기 시작했는데, 몇 가지 사용자 함수 말고는 거의 기본값 그대로 씀
      Ripgrep도 기본 상태에서 “그냥 맞는 일”을 해줘서 설정을 시도해본 적조차 있는지 모르겠음
    • Helix를 제대로 쓰려면 어떻게 배워야 할까? Neovim이 플러그인 때문에 50개 넘는 저장소를 끌어오는 구조라 공급망 공격이 너무 걱정되어 벗어나려는 중임
    • 이 말이 정말 공감됨. 나이가 들면서 도구와 소프트웨어를 그렇게 많이 만지는 사람들이 잘 이해되지 않음. 재미도 없고 그럴 가치도 없음

  • Emacs

  • 스톡홀름 증후군일지도 모르지만 Nix임. 완벽하진 않지만, Nix로 더 표현력 있고 효율적으로 작업할 수 있게 되면서 다른 Linux 배포판과 메타 빌드 시스템을 사실상 망쳐버렸음
    덧붙이면 pwntools도 CTF 밖에서도 쓰기 즐거운 도구임. 예를 들어 Python REPL에서 소켓을 비트 단위로 만지는 식으로도 좋음

    • Nix와 pwntools 둘 다 좋아함. 같은 CTF 플레이어로서 궁금한데, Nix 기반 CTF pwn 환경을 갖고 있다면 어떻게 구성했는지 궁금함
      나는 항상 libvirt Ubuntu VM을 새로 띄우고 도구들을 넣어 거기서 작업했는데, Nix 기반으로 추천할 만한 방식이 있을까?

  • Emacs는 당연하고, 특히 Magit임

  • Nix. 학습 곡선은 있음. Nix 사용자나 전도자 주변에 몇 년 있다가 진지하게 시도했지만, 결국엔 꽤 좋음
    여러 프로젝트를 하다 보니 시스템 수준 의존성을 관리하는 도구가 제각각인 데 질렸음. Node 버전용 하나, Python 버전용 하나, 이런 식임
    프로젝트 간 비호환성 때문에 디버깅하기 어려운 빌드 실패가 나는 것도 지쳤음. Project A에서 $foo가 깨져서 Homebrew로 업데이트했더니, 이제 Project B에서 $foo가 깨지는 식임
    빌드 과정이 시스템에 설치된 여러, 종종 숨겨진 의존성에 기대고 있어서 “왜인지 모르게” 빌드가 실패하는 상황도 피곤함
    가능한 모든 것을 프로젝트별 nix shell로 옮겼음. 시스템 수준 패키지는 최대한 얇게 유지하고, 프로젝트에는 필요한 도구들, 즉 의존성·런타임·컴파일러 등을 정확한 버전으로 고정함
    전역 PATH나 다른 프로젝트를 오염시키지 않음. 지금 내게서 동작한다면 1년 뒤나 5년 뒤에도 동작할 거라는 확신이 꽤 높음
    도구를 업그레이드하고 싶을 때도 다른 프로젝트에 영향을 줄 걱정 없이 할 수 있고, 회귀가 생기면 쉽게 되돌리거나 특정 의존성 하나만 예전 버전으로 고정할 수 있음
    동료들도 Nix를 쓰는 프로젝트에서는 더 좋음. nix shell을 설정하고 유지하는 추가 시간이 공유되고, 개발 환경이 동일하다는 확신도 꽤 높아짐

    • 비슷한 이유로 최근 Dev Containers에 많이 빠졌음. 아이디어는 꽤 좋다고 보지만, 아쉽게도 도구 품질이 받쳐주지 못함
      예를 들어 기준 CLI조차 stop 명령 구현을 아직 안 했음. 그래도 배포에 Docker/컨테이너를 쓴다면 개발 환경과 배포 환경 사이에서 설정을 많이 공유할 수 있다는 장점이 있음
      https://containers.dev/
      https://github.com/devcontainers/cli

  • rr(https://rr-project.org/)은 없으면 못 살 정도로 마법처럼 좋은 소프트웨어임

    • 예전이었다면 매일 필요했을 도구임. 좋은 발견임. 나중에 다시 필요해질 때 찾을 수 있도록 내 세컨드 브레인에 넣어둘 생각임
    • 궁금한데, rr에서 가장 큰 가치를 얻는 지점이 어디임? 프로젝트 첫 페이지의 소개는 큰 틀에서 이해함
      실패를 한 번 기록한 뒤, 그 기록을 결정적으로 몇 번이고 디버그한다는 개념은 분명 유용해 보임
      다만 실제 경험을 묻는 이유는 “와, 이 특정 버그/작업 흐름은 rr 없이는 해결이 불가능했겠다”라는 식의 체감이 아직 부족해서임

  • 시스템 관리자 배경이라 “좋은 기본값을 최소 설정으로 쓰기” 쪽에 훨씬 가까움. 그런데 최근 습관을 깨게 만든 것이 두 가지 있음
    jujutsu(jj)는 이 사이트에서도 말이 많았지만, 솔직히 쓰는 맛이 정말 좋음. git CLI를 버릴 줄은 몰랐는데 이렇게 됐음
    여러 해 동안 nvim 사용과 설정을 배우는 걸 피해왔는데, nvchad 덕분에 시작할 수 있었음. 이름은 끔찍하지만, 나에게는 미니멀함에서 딱 적당히 주관적인 훌륭한 시작 설정임
    물론 이제는 처음부터 내 최소 설정을 직접 쓰고 있음
    그 외에는 Python을 꽤 쓰는 편이라 astral 도구들도 꾸준히 쓰기 즐겁다고 말해야겠음. Anthropic이 잘 돌봐주길 바람

    • jujutsu는 두 배로 그렇음. 처음엔 전환 자체가 좋고, 그다음엔 jj 기본값이 아주 다듬어져 있지는 않아서 한 번 더 손보게 됨
      어두운 배경에 전형적인 고대비 무지개 유니콘 토사물 같은 텍스트를 쓰는 게 아니라면, 색과 템플릿 조정이 많이 필요함

  • 사실 Emacs임. 내 컴퓨팅 작업을 조금씩 Emacs로 옮기고 기본값을 받아들이기 시작했음
    Emacs는 사용자화가 정말 쉽고, 많은 키 바인딩이 모든 모드에서 적절한 일을 해줌
    느리게 전환 중인 목록은 Git → Magit, Email → mu4e, RSS → elfeed, Notes/TODO/Calendar → org mode, Finder → dired임
    Quarto도 Markdown으로 빠르게 발표 자료를 만들 때 꽤 좋음. Nix와 nix-darwin은 모든 dotfiles에 씀

    • dired 용도로는 Dirvish를 살펴볼 만함

  • Emacs. 자주 쓰지는 않지만, ragel로 파서를 작성하는 건 즐거움

  • Sublime Text는 확실히 너무 많은 사람에게 저평가되어 있음

    • Sublime Text를 좋아하고 싶었지만, vi 모드가 Vim에서 쌓은 근육 기억과 충분히 맞지 않아서 정착하지 못했음
      아마 “vintage” 같은 이름이었던 것 같음. 요즘은 Sublime Text를 좋아하고 싶었던 상황에서 Zed를 씀
답변달기