모던 리눅스 도구 모음 : 기존 명령어를 대체하는 새로운 CLI 들

• 리눅스 작업 효율을 높여주는 다양한 최신 커맨드라인 도구들 소개
• 기존 전통적 유닉스 명령어를 현대적으로 대체하거나 기능을 강화하고, Rust·Go 등으로 개발된 성능 중심의 도구들이 다수 포함

파일 보기 및 탐색 도구

• bat : cat 명령어의 신택스 하이라이팅 및 git 통합 기능 강화 버전
• exa : ls/tree를 대체하는 현대적 파일 리스트 뷰어이나 현재는 유지보수 중단 상태
• eza : exa의 포크로, 현대적인 ls/tree 제공함
• lsd : 차세대 ls로, 기존 호환성과 더욱 세련된 출력을 지원
• broot : 네비게이션이 강화된 트리 형태 파일 탐색기
• nnn : 경량·고속 터미널 파일 관리자

파일·디렉터리 용량 분석

• ncdu : 텍스트 기반의 직관적 du 인터페이스 제공
• dust : Rust로 구현된 더 쉬운 du 대체제
• duf : 기존 df보다 개선된 사용성의 디스크 사용량 분석 도구

파일 및 코드 검색

• fd : 간결하고 빠른 find 대체이며 사용성이 뛰어남
• ripgrep : gitignore를 지원하는 초고속 grep 대체제
• ag : ack과 비슷하지만 더욱 빠른 코드 검색 도구
• fzf : 범용 퍼지 검색기. 파이프라인, 등 다양한 곳에 활용 가능
• bfs : breadth-first 기반의 find 대체임

터미널 내 Git/diff 뷰어

• delta : git 및 diff 결과를 가독성 높게 시각화

명령어 기록 및 처리

• mcfly : 쉘 히스토리 검색·탐색을 혁신적으로 개선. 검색 품질 향상 및 직관적 UI 제공

데이터 처리

• choose : cut, 일부 awk보다 더 직관적이고 빠른 대체제
• jq : JSON 전용 sed처럼 쓰는 데이터 파서
• sd : 더 친숙한 find/replace로, sed 대체 도구

시스템/프로세스 모니터링

• bottom : 크로스 플랫폼 그래픽 기반 시스템·프로세스 모니터
• glances : top/htop의 개선 버전
• gtop : 터미널 대시보드형 시스템 모니터
• procs : Rust로 작성된 ps 대체 명령어

벤치마킹·네트워크

• hyperfine : CLI 벤치마킹 자동화 도구
• gping : 그래프 출력 기능을 포함한 ping 도구

HTTP 클라이언트

• httpie : 현대적이고 친화적인 CLI용 HTTP 클라이언트. 개발자 API 테스트에 적합
• curlie : curl의 파워에 httpie의 사용성을 결합한 도구
• xh : 성능 중심의 httpie 대체 도구

디렉터리 이동·에디터

• zoxide : z를 모티브로 한 스마트 cd 명령어
• micro : 현대적 기능의 터미널 텍스트 에디터

새롭게 등장한 CLI 유틸리티

• up : 실시간 미리보기 파이프라인 도구, 명령어 출력 즉시 확인 가능

도움말·문서 툴

• ManKier : 요약형 man 페이지, 깔끔한 명령어 설명
• tldr : 간결한 예제 중심의 man 페이지 요약
• tealdeer : Rust 기반 tldr 구현, 빠른 실행 속도
• explainshell : 명령어 인자를 자동 분석해 의미를 시각적으로 설명
• cheat.sh : tldr와 cheatsheet를 통합한 온라인 도움말 서비스

GUI 도구

• baobab : GUI 기반 디스크 사용량 분석기
• stacer : 시스템 최적화 및 모니터링 GUI 툴, 서비스 관리 포함

[GN⁺]

Hacker News 의견

• 이런 툴들이 객관적으로는 더 뛰어날 수 있겠지만, OS를 새로 설치하거나 VM을 띄우거나 SSH 접속을 할 때마다 매번 이런 툴들을 세팅하는 게 끝없는 고생임을 깨달았음. 매 환경마다 세팅하는 건 지치는 일, 한 곳에선 새 툴, 다른 곳에선 전통적인 툴을 혼용해서 쓰고 싶지도 않음. 고전적인 툴들을 제대로 익히는 것이 가장 삶을 편하게 해주는 방법임

  • 어떤 사람들은 대부분의 시간을 자신의 컴퓨터에서 보내기 때문에 이런 편의성 강화의 가치가 큼. 그래도 고전적인 툴도 웬만큼은 사용할 줄 알기 때문에, 가끔 다른 서버 작업할 때도 충분함. 모두가 하루 종일 여러 다양한 서버에 로그인해야 하는 시스템 관리자는 아님

  • 어떤 툴들은 지나치게 더 좋아서, 약간 번거롭게 설치하더라도 가치가 충분함. 나는 고전적인 툴을 잘 다루지만, 항상 fd나 ripgrep이 더 좋음

  • 내가 Nix를 정말 좋아하는 이유는 거의 모든 환경에서 동일한 셋업이 가능하다는 점임 (내가 사용하는 환경이 linux나 macOS인 한, 이 두 가지만 신경 씀). 루트 권한도 필요 없는 여러 방식의 Nix 설치법이 있어서 어디서든 내 환경을 그대로 만듦. 물론 Nix가 없으면 고전적인 툴도 충분히 쓸 수 있음. 둘 중 하나만 골라야 하는 게 아니고, 둘 다 가질 수 있음

  • OS를 새로 설치할 땐 어차피 필요한 패키지들을 apt-get, pacman, dnf, brew 같은 걸로 깔아야 하고, 나만의 브라우저나 에디터 등도 별도로 설치해야 함. SSH로 들어가면 GUI도 못 쓰는데, 그게 GUI 툴을 피할 이유는 아님. 개인 환경과 공용 환경에서 툴 조합이 다르더라도 크게 문제라고 생각하지 않음. 예를 들어 bat는 cat을 완전 대체하는 게 아니라 구문 하이라이트만 추가해줘서 삶이 편해짐. 안 깔려 있으면 그냥 안 쓰면 됨

  • 내 생각에 “하나의 일을 잘하라”는 UNIX 철학에 비춰 보면, 더욱 뛰어난 대안이 등장하면 그걸로 쉽게 교체 가능한 것 자체가 이런 심플 유틸리티의 요지임. 경력을 위해 고전 도구를 먼저 배우는 건 맞지만, 새로운 대안도 반드시 배워야 한다고 생각함. 나는 bat이나 eza보다는 fd(find 대체), sd(sed 대체)처럼 시간을 아끼는 대안이 정말 도움이 된다고 느낌

• 여러 네트워크와 고객사 등, 수백 대의 서버에 접속하는 입장에선 커스텀 툴을 쓸 가치가 거의 없음. 90% 환경엔 이런 툴들이 설치돼 있지 않기 때문임. 나는 ansible-config에 딱 몇 가지만 추가해서 자동화로 배포하지만 리스트를 아주 간결하게 유지함. 내가 관리하는 95% 시스템은 debian이나 ubuntu라서 베이스라인이 거의 비슷하고, 거기에 ack, etckeeper, vim, pv, dstat 같은 것들만 추가함

  • 여기서 "서버"란 점이 핵심임. 대부분 살짝 개선된 sysadmin용 프로그램들은 그리 가치 있지 않을 수 있지만, 일부는 개발 환경에서 쓰는 진짜 dev툴이라 프로그래밍하는 적은 수의 머신에만 설치해도 됨. ripgrep(뛰어난 recursive grep), jq(JSON 프로세서로 unix 기본툴킷엔 대안 없음), hyperfine(벤치마킹) 같은 것들이 대표적임

  • Windows와 Linux를 오가며 일하다 보니 ripgrep처럼 뛰어난 크로스플랫폼 툴이 정말 편리함

  • 이런 앱을 원격 SSH 세션에 자동으로 가져오는 툴이나 SSH 확장이 실제로 있을까 궁금함. 크기가 작은 바이너리라면 temp 폴더에 복사해서 쓸 수도 있고, 그 과정을 자동화하는 것도 상상 가능함. 다만 보안상 문제는 없는지, 추가 권한이 필요하지 않은지가 관건임. 결국 이 앱들의 이식성이 관건이라 할 수 있음. 나 역시 이 고민을 자주 함

  • emacs는 거의 하나의 운영체제처럼 동작해서, 어떤 시스템이든 익숙한 환경을 얻을 수 있음. "GNU is my operating system, linux is just the current kernel"라는 말이 그래서 나옴. 베테랑 admin 입장에서, 처음 리눅스를 배우는 사람에게 "info" 명령어부터 보고 그 매뉴얼을 다 읽으라고 추천하는 이유임. 그러면 대다수 관리자를 크게 앞설 수 있음. 내장 툴이 무엇인지 알면 매뉴얼도 좋아서 스크립트 작성이 쉽고, 그게 바로 리눅스 철학의 핵심임. 한때는 nano도 없이 vi만 있던 시절이었으나, 요즘엔 CI/CD 자동화로 tui 에디터를 추가하는 것도 간단함

  • 이런 "내가 어떤 사람이다"라는 식의 덧글들은 별로 공감되지 않음. 커스텀 툴을 원격에 설치하지 않는다는 사실에 관심 없는 사람도 많음. 로컬 컴퓨터에라도 이런 툴 설치해서 이점 얻으라는 의견임

• 이 표에 “이 툴이 무슨 문제를 해결하는가”라는 추가 열이 있으면 좋겠다고 생각함. 그리고 ‘rust로 구현됨’ 같은 건 차별점이 아니라고 여김

  • “Go로 짰다”가 차별점이라는 설명을 듣고 회사 회의에서 황당했던 경험을 가진 적 있음. #facepalm

  • 표에 있는 많은 항목은 “syntax highlight”, “ncurses interface”, “more intuitive”처럼 실제 문제를 언급하긴 함. 다만 “rust로 씀”, “modern”, “better” 같은 표현은 도움되지 않는다고 생각함

  • 대부분의 툴의 1차 목적은 UX 개선임

  • 비 GPL 라이선스를 쓰는 것도 차별점이 아님

  • 이 툴들 중 상당수는 Windows에서도 사용 가능해서 좋음

• 이런 툴 리스트는 언제나 즐거움. 대부분의 사람들은 아마 여기 있는 툴 중 하나나 두 개는 잘 쓸 수 있을 것 같음. 개인적으로 ripgrep과 jq가 필수임. ripgrep은 grep 대체제 중에 최고의 드랍인이고, jq는 내가 꼭 필요로 했던 문제를 해결해줌. lsd와 dust도 써볼까 함. 새로운 툴이 내게 직접 필요하지 않아도, 다들 이런 툴에 시간을 쏟아주는 걸 고맙게 생각함. 공동체 전체의 툴박스를 조금씩 더 낫게 해주는 행동이 대단함

  • fzf를 가장 먼저 선택할 것 같음. rg나 jq보다 훨씬 선호함

  • ripgrep이 grep과 동작이 달라서 실제로는 drop-in 대체가 아님. 훌륭한 프로그램이긴 하지만, 완전히 호환되지는 않음

  • 나처럼 리눅스 admin들은 각자 이런 꽁꽁 짜인 리스트가 있음. 나는 GPL 기반 스택을 위주로 진영을 꾸렸고, 이 ikrima.dev 포맷이 특히 마음에 듦

• 나는 터미널에서 생활하지만, 이런 툴들은 내가 당장 필요한 문제를 해결해주지 않거나, 내 시스템에 깔려 있지 않거나, 하지만 왠지 수만 개의 github 별을 가지고 있음. 도대체 무슨 이유에서 이런 인기가 있는지 모르겠음

  • 음악 라이브러리 속에서 사는 사람도, 자기 취향이 아니거나 라이브러리에 없는 아티스트가 수백만 장을 팔아도 아리송할 수 있음. 농담은 그렇고, 직접 한번 이런 툴을 써본 적이 있는지 묻고 싶음. 나도 예전에 vim이 왜 쓰는지 몰랐는데, 제대로 써보니까 이유를 알겠었음

  • fzf를 안 쓴다고? 터미널 생활이 정말 힘들 것 같음. 직접 실행하는 것보다 각 셸 플러그인으로 Ctrl+R로 bash_history, Ctrl+T로 현재 디렉토리 파일을 퍼지 검색할 수 있어서 정말 유용함

  • 코어 unix 툴셋이 워낙 견고해서, 기본 툴만으로도 충분히 작업 가능함. 많은 대체 툴들이 더 낫긴 하지만 꼭 필수는 아니고, 게다가 대부분 기본 설치되어 있지 않음

  • 궁금해서 묻자면, 내장 unix 툴만으로 숨김 파일(.git 등)은 무시하고 특정 확장자만 recursive grep하는 우아한 방법이 있을까? 예를 들어 rg -g '*.foo' bar 명령은 정말 자주 쓰는 패턴임. fd로 정규식이나 glob에 맞는 파일을 찾는 것도 마찬가지임. 기본툴만으론 깔끔한 방법을 못 찾았음

  • 터미널에서 하루 종일 어떤 작업을 하기에 툴셋 개선 욕구가 없는지 궁금함. 혹시 직접 모든 툴을 작성하는 건지 물어보고 싶음

• 다크 모드에선 링크 텍스트가 너무 안 보여서 읽기 힘듦

• jq만이 딱히 기존 툴로는 해결이 안 되는 실제 문제를 해결한다고 생각함. 나머지는 대부분 기호나 성능, 하이라이트, rust 구현 같은 차이일 뿐임

• 한 팀이 매개변수, 색상, 테이블 등 디자인을 일관되게 맞춘 툴 “스위트”를 내놨으면 하는 바람이 있음

• 오랫동안 htop을 top보다 접근성 있다고 써왔으나, htop이 기본적으로 커널 스레드를 안 보여서 장애 원인 찾는데 걸림돌이 됐음. 그 후로는 top이 모든 정보를 보여주고 신뢰도 높아서 다시 top으로 돌아감. htop/btop 같은 UI는 그냥 쇼맨십에 가깝다고 생각함

• 이 글은 2023년 기사임. “모던 툴” 대부분은 이미 업데이트되고 새로운게 트렌디하게 나왔을 수도 있음

  • 툴이 많기 때문에 절반만 살아남아도 충분히 가치가 큼

  • 내 경험은 오히려 반대임. 이 툴들 대부분은 시간을 들여서 제대로 배우기만 하면 엄청나게 강력한 GNU 기본툴을 또 한 번 “재발명”한 것에 불과함