좋은 도구는 보이지 않는다

• 좋은 도구는 사용자가 작업에 몰입하는 동안 배경으로 사라지는 도구이며, 도구 제작자의 목표도 도구 자체를 의식하지 않게 만드는 데 있음
• 도구의 결함을 “재미있는 퍼즐”로 포장하면 영리해 보이는 느낌을 실제 생산성으로 착각하기 쉬움
• vim, emacs, Sublime 같은 편집기 선택은 개인 워크플로에 맞을 수 있지만, 결함까지 정체성 신호처럼 방어하면 장단점을 정직하게 보기 어려움
• TUI와 GUI 논쟁에서도 현재 구현의 부족함을 범주 자체의 본질적 한계로 보면 안 되며, 많은 문제는 좋은 구현이 없어서 생김
• 좋은 기본값은 사용자 시간을 아끼는 설계이며, 높은 설정 가능성이나 가파른 학습 곡선은 실제 생산성으로 보상될 때만 감수할 가치가 있음

좋은 도구의 기준

• 좋은 도구는 보이지 않아야 함
  • 사용자가 도구 자체를 의식하지 않고 일을 계속할 수 있을 때 도구가 배경으로 사라짐
  • 특정 작업에서 도구가 발목을 잡는 순간, 사용자는 다시 도구를 의식하게 됨
• 부족한 점을 “재미있는 퍼즐”로 다시 포장하는 태도는 도구 평가를 흐림
  • 우회 방법을 찾는 즐거움이 도구의 품질을 증명하지는 않음
  • 결함을 취미처럼 즐기는 것과 도구가 실제로 좋은 것은 별개의 문제임

텍스트 편집기 논쟁

• vim은 예시일 뿐이며, 같은 논리는 emacs나 Sublime 같은 다른 편집기에도 적용됨
• 일부 사용자는 vim의 장점보다 단점을 해결하는 과정을 재미있는 퍼즐처럼 칭찬함
  • 일회성 텍스트 리팩터링을 위해 매크로를 만드는 일이 재미있었다는 사례가 있음
  • 같은 작업을 Sublime의 다중 커서로 1분 안에 처리하거나 간단한 스크립트로 해결할 수 있었다면, 매크로 작업은 실제 생산성 기준에서 약해짐
• 편집기는 워크플로에 중요하지만, 특정 편집기를 “해커 분위기” 때문에 거의 종교적으로 따르는 태도는 위험함
  • vim이나 emacs를 새로 접하는 사람에게 이런 분위기가 매력으로 작용할 수 있음
  • 익숙함이 결함을 가리고, 그 결함을 게임처럼 자랑하게 만들 수 있음

Sublime을 쓰는 이유와 인정하는 한계

• Sublime은 15년 동안 사용한 편집기이며, 선택 이유는 몇 가지로 정리됨
  • 단축키가 그래픽 OS 환경의 상위 집합에 가까워 앱 사이를 오갈 때 인지적 전환 비용이 작음
  • 다중 커서는 매크로보다 99.999%의 경우 더 낫다고 봄
  • 다중 커서는 직접적인 시각 피드백을 제공함
  • 텍스트 편집 워크플로에서 풀어야 할 “퍼즐”이 가장 적음
• Sublime에도 결함은 남아 있음
  • 필요한 도구가 없어 플러그인을 쓰거나 별도 프로그램으로 텍스트 변환을 처리해야 할 때가 있음
  • 이런 결함을 “재미있는 퍼즐”로 포장하지 않고 그냥 불편함으로 받아들임
• vim은 기본 편집에는 더 나을 수 있지만, grep류 작업이 아닌 대량 작업에서는 더 약하다고 봄
  • vim motion이 Sublime 워크플로보다 훨씬 생산적이라고 느끼지 못함
  • 터미널에서 코드를 거의 작성하지 않기 때문에 터미널 지향 편집기가 사실상 필요하지 않음

도구가 정체성이 될 때

• 도구 선택은 자신이 어떤 사람인지 보여주는 깃발처럼 작동할 수 있음
• “해커 분위기”는 단순한 미학을 넘어 부족 신호가 되기도 함
• 정체성이 도구에 묶이면, 결함을 인정하는 일이 자기 자신을 부정하는 것처럼 느껴짐
  • 그래서 결함을 참는 데서 그치지 않고 방어하고 자랑하게 됨
  • 도구가 성격의 일부가 된 사람과는 도구에 대한 정직한 대화가 어려움

생산적인 느낌과 실제 생산성

• 편집기 매크로 사례는 생산적인 느낌과 실제 생산성의 차이를 보여줌
• 까다로운 문제를 해결할 때 생기는 영리함의 감각은 실제 산출과 혼동되기 쉬움
  • 어려운 일을 영웅적으로 느끼게 하고, 영리함을 성취처럼 느끼게 하는 도구는 강력해 보일 수 있음
  • 동시에 실제 작업 속도는 조용히 느릴 수 있음
• 정직한 기준은 몰입감이나 영리함이 아니라 걸린 시간과 실수의 수임
  • 많은 사람이 전도하듯 추천하는 도구는 이 기준에서 밀릴 수 있음
• 생산성이 목표라면 자신의 믿음을 실제로 의심하고, 무엇이 더 생산적인지 확인해야 함

TUI와 GUI 논쟁

• 터미널에 하루 종일 머무는 사용자에게는 터미널 앱의 장점이 명확함
• 하지만 대부분의 프로그래머가 하루 종일 터미널에 갇혀 있는 것은 아님
• GUI 앱을 키보드만으로 탐색할 수 없다는 비판은 GUI가 본질적으로 나쁘다는 뜻이 아님
  • 많은 GUI가 키보드 탐색을 충분히 지원하지 않을 뿐임
  • GUI를 키보드로 탐색 가능하게 만드는 데 본질적으로 불가능한 점은 없음
  • 많은 도구 제작자가 이를 구현하지 않거나, 마우스를 자주 쓰는 것보다 키보드 탐색이 더 생산적인 경우가 많다는 점을 깨닫지 못함
• 특정 TUI 앱이 특정 GUI 대안보다 낫다는 비교는 타당할 수 있음
• 그러나 TUI가 GUI보다 본질적으로 낫다는 판단은 현재 구현의 한계를 본질적 한계로 착각하는 오류에 가까움

Linux 데스크톱과 설정의 즐거움

• 2026년에도 “Linux 데스크톱의 해”는 오지 않았음
• 이유 중 하나는 Linux 사용자 중 많은 사람이 설정 파일을 만지며 시스템을 바꾸는 일을 재미있는 퍼즐로 좋아한다는 점임
• 직접 그런 단계를 거쳤더라도, 시간이 지나면 그냥 잘 작동하는 도구를 원하게 됨
  • 몇 시간 또는 며칠씩 설정하는 일은 더 이상 원하는 일이 아님
  • 기본값은 좋아야 하고 바로 작동해야 함
  • 작은 조정이 필요할 때는 몇 초 안에 끝나야 함
• 최대 설정 가능성은 도구의 목표가 아니라 실제로 필요할 때 쓰는 선택지여야 함
• 인체공학적인 도구 설계는 좋은 기본값과 필요한 경우의 탈출구를 함께 제공하는 일임

좋은 기본값과 도구 제작자의 책임

• 좋은 기본값은 도구 제작자의 책임임
• 도구 제작자는 설정, 조정, 학습의 부담을 사용자에게 넘기기 쉬움
• 많은 부담은 설계자가 결정을 회피한 결과임
  • “높은 설정 가능성”은 아무 의견도 담지 않은 채 문제를 사용자에게 넘기는 핑계가 될 수 있음
• 좋은 기본값은 사용자 시간에 대한 존중임
  • 도구 제작자가 한 번 고민하면 수많은 사용자가 같은 고민을 반복하지 않아도 됨
• 탈출구는 특이한 요구가 있는 진짜 소수를 위한 장치임
  • 일반적인 경우를 제대로 만드는 일을 대체해서는 안 됨

가파른 학습 곡선은 기능이 아님

• 어떤 도구의 어려움이 핵심이라는 방어도 있음
  • 헌신하지 않은 사람을 걸러내고, 고비를 넘으면 평생 보상받는다는 논리임
• 학습 곡선은 비용이지 미덕이 아님
  • 그 비용이 가치 있을 수는 있지만, 보상은 실제 생산성이어야 함
  • 비용을 지불했다는 만족감 자체가 보상이 되어서는 안 됨
• “몇 달 배웠으니 가치가 있어야 하고, 다른 사람도 따라야 한다”는 논리는 매몰비용을 능력처럼 포장함
• 이때 퍼즐은 도구를 이용한 작업이 아니라 도구 자체가 됨

도구 선택보다 중요한 태도

• 특정 도구를 반대하는 논지가 아니라, 도구를 대하는 사고방식에 대한 비판임
• vim, emacs, Sublime 중 무엇이든 써도 됨
  • 기준은 그 도구가 배경으로 사라지고 사용자가 일을 계속하게 해주는지임
  • 이 기준은 개인적인 기준임
• 문제는 도구 선택 주변에 붙는 이야기임
  • 한계를 기능으로 다시 포장함
  • 결함을 우회하는 노력을 보상처럼 판매함
  • 도구가 “사용하는 것”에서 “자신의 일부”로 승격됨
• 도구가 제대로 봉사하고 있다는 가장 분명한 신호는 사용자가 그 도구를 알아차리지 않게 되는 상태임
• 최고의 도구는 가장 좋은 이야기를 가진 도구가 아니라, 사용자가 자신이 쓰고 있다는 사실을 잊게 하는 도구임