좋은 도구는 보이지 않는다

 (gingerbill.org)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 좋은 도구는 사용자가 작업에 몰입하는 동안 배경으로 사라지는 도구이며, 도구 제작자의 목표도 도구 자체를 의식하지 않게 만드는 데 있음
  • 도구의 결함을 “재미있는 퍼즐”로 포장하면 영리해 보이는 느낌을 실제 생산성으로 착각하기 쉬움
  • 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 중 무엇이든 써도 됨
    • 기준은 그 도구가 배경으로 사라지고 사용자가 일을 계속하게 해주는지임
    • 이 기준은 개인적인 기준임
  • 문제는 도구 선택 주변에 붙는 이야기임
    • 한계를 기능으로 다시 포장함
    • 결함을 우회하는 노력을 보상처럼 판매함
    • 도구가 “사용하는 것”에서 “자신의 일부”로 승격됨
  • 도구가 제대로 봉사하고 있다는 가장 분명한 신호는 사용자가 그 도구를 알아차리지 않게 되는 상태임
  • 최고의 도구는 가장 좋은 이야기를 가진 도구가 아니라, 사용자가 자신이 쓰고 있다는 사실을 잊게 하는 도구임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 개발자 팀을 위한 내부 도구를 꽤 많이 설계해 보니 정말 동의함
    예전에는 사용자가 개발자니까 “내부 구조”를 열어두는 편이 좋다고 생각했지만, 실제로는 팀원들이 본업을 하는 데 장애물만 만들었음
    팀원들은 회사가 필요로 하는 일을 하려고 내가 만든 도구를 쓰는 것이지, 다른 곳에서는 볼 일도 없는 작은 도구를 만지작거리고 싶어 하지도 않고 그래야 할 이유도 없음
    지금도 탈출구는 많이 남겨두지만, 사용자가 자연스럽게 성공의 구덩이로 떨어지도록 내부 도구를 설계하려고 함
    그리고 오류 메시지, 오류 메시지, 오류 메시지와 흔한 오류에 대한 자동 제안이 중요함
    글의 예시만 붙잡고 글의 취지를 보지 않는 사람이 많아서 실망스럽기도 함

    • 설정 가능성은 그 도구가 수행 중인 핵심 업무에 얼마나 중요한지에 따라 달라진다고 봄
      사용자가 중요하게 여기는 일을 직접 수행하게 돕는다면 설정 가능성이 매우 가치 있지만, 덜 중요하게 여기는 문제를 치워주는 도구라면 오히려 방해가 될 수 있음
      예를 들어 Gusto가 급여, 세금, 양식 제출을 대신 처리해 주는 방식은 정말 좋음. 거의 생각하거나 만질 필요가 없기 때문임
      하지만 급여·회계·세무가 본업이거나 대기업 HR·법무·재무 부서에서 일하는 사람에게는 그런 단순화가 해로울 수 있음. 도구와 싸워야 하거나, 좀 덜 좋게 말하면 자기 일을 너무 단순하게 만들어버리기 때문임
      또 실제로 돈을 내는 사람이 누구인지, 그 도구가 감사 가능성·보안·원치 않는 행동 제한 같은 방어적 목적인지, 창의적 목적인지도 큰 문제임. 창의적인 기능은 더 매력적이지만 정량화하기 어렵고, 최종 사용자는 자기 역할에 얼마나 도움이 되든 그만큼 큰돈을 내려고 하지는 않음
    • 같은 관점임. 이것은 점진적 공개의 한 형태로 보임
      합리적인 기본값을 두고 필요하면 커스터마이즈할 수 있게 하는 방식임. 80% 사례에서 시작하고, 원하면 바꾸게 해야 하며 선택 사항이어야 함
      특히 개발자 도구에서는 의견을 강하게 담는 것을 주저하는 경향이 있음. 어떤 선택지가 “항상 맞다”고 확신하지 못하면 사용자에게 묻는 편이 안전해 보이고, 개발자는 꽤 까다롭게 따지기 때문임
      “95%는 아마 이 방식을 원하겠지만, 5%도 타당한 지점이 있으니 모두에게 고르게 해야겠다”라고 하면 대다수 사용자에게 더 나쁜 도구가 됨
      커스터마이즈를 지원하는 일은 생각보다 훨씬 복잡함. 버그만의 문제가 아니라, 선택지 하나하나가 사용자 경험 다듬기를 어렵게 만듦. 테스트 범위도 커지고, 더 유연한 추상화는 설계하기도 더 어려움
    • 방해하지 않는 것이 중요한 이유는 사람들이 매일 수십 개의 도구를 오가며 쓰기 때문임
      다만 여전히 균형을 맞춰야 할 부분이 있는데, 사람들에게 올바른 방식을 강제하는 일임
      제대로 하느라 막힌다고 투덜대는 사람은 항상 있고, 그들은 그것을 시간 낭비라고 느끼는 경우가 많음
    • 이건 프레이밍에 따라 다름. 특히 재미있고 기술을 키워주는 일은 사람들이 생각하는 것보다 더 가치 있을 수 있음
      조직 관점의 목표는 직원이 재직하는 동안 가장 높은 성과 곡선을 만드는 것이고, 직원 관점에서는 커리어 전체의 성과 곡선을 만드는 것임
      많은 부분은 관련된 사람들의 관계에 달려 있음. 이삿짐 작업자가 전날 운동해서 근육통이 있으면 내 입장에서는 더 느리고 나쁜 결과지만, 이사업체 입장에서는 장기적으로 더 강해져 더 많은 일을 할 수 있으니 좋을 수 있음. 다만 그날 그만두거나 해고된다면 다시 나쁜 결과가 됨
      진짜 평가는 매크로와 Sublime 편집 중 무엇이 나은지가 아니라, 매크로를 만드는 사고 과정이 다른 일에도 도움이 되는지, 그리고 그 전에 무엇을 하고 있었는지임
      내 경험상 매크로를 쓰거나 Vim을 배우는 데 쓰던 시간을 진짜 의미 있는 업무에 쓸 사람은 거의 없음. 그들은 지루하거나 번아웃되어서, 그 순간 재미있게 느껴지는 다른 것을 생각하고 싶어 그러는 경우가 많음
      문제는 직원들이 랜덤 스크립트를 쓰는 게 아니라, 현재 작업에 대한 긴급감이나 관심이 없다는 데 있음

  • 인터페이스가 “보이지 않게” 되는 효과는 실제로 그 인터페이스 안에서 보낸 시간의 함수임
    글쓴이가 반응하는 대상은 디자이너나 제품 담당자가 기능이나 복잡성을 더하는 재량적 마찰에 가까워 보임
    하지만 특정 작업을 달성하려면 그런 마찰이 필요할 수 있음. 병합 충돌을 해결하는 상황을 생각해 보면 됨. 그리고 충분히 오래 쓰면 그런 “방해되는” 단계조차 배경으로 사라짐
    구체적으로 737 조종석은 조작 장치가 엄청나게 빽빽함. 비행기 자체도 여러 모드가 있고, 의도된 마찰도 많음
    하지만 737을 10년 넘게 다룬 조종사에게 물어보면 그 인터페이스가 보이지 않게 되었다고 말할 것임
    흔히 “나쁘다”고 여겨지는 Bloomberg Terminal도 마찬가지임. 의료 분야에서도 하루 8시간 이상 MR 스캔 소프트웨어를 쓰며 모든 제어에 즉시 접근하고 싶은 사람에게는 버튼으로 가득한 인터페이스가 정확히 맞는 해법일 수 있음
    프로그래머는 자기 경험과 선호를 너무 빨리 일반화해서 다른 사람에게 적용하려는 경향이 있음
    출처: IDEO에서 소비자용·전문가용 소프트웨어를 10년 설계했음

    • “재량적 마찰, 즉 디자이너나 제품 담당자가 기능이나 복잡성을 추가하는 것”이라는 표현이 훨씬 정확함
      글은 사용자 쪽에서 이를 다루며, 핵심 기능보다 궁극적 가치는 낮은 “추가” 기능을 배우는 것을 즐기는 사용자 부류가 있다고 봄
      “사람들이 vim, emacs 등이 진짜 좋고 생산적이라고 느껴 쓴다면 비판하지 않겠다. 사람은 익숙한 것에 가장 편안함을 느낀다. 하지만 내가 말하는 사람들은 그 익숙함 때문에 도구의 결점을 보지 못하고, 그 결점을 게임처럼 과시하며 찬양하게 된다”는 부분이 핵심임

  • 오래 터미널을 써 온 입장에서 사람들이 이해하지 못하는 게 별로 놀랍지 않음. 대화는 보통 이렇게 흘러감
    “터미널에서는 간단한 명령으로 이런저런 일을 할 수 있다”
    “내 FrobnicatorStudio에는 그걸 위한 Ctrl+Alt+So 단축키가 있다”
    이런 식으로 끝없이 이어지며 “Vim에서는 네 번 누르면 24줄을 지울 수 있다”와 “Sublime에는 다중 커서가 있다” 같은 거의 무의미한 비교로 감
    아마 제대로 된 논점은 터미널이 작은 명령줄 도구들을 파이프라인으로 조합하는 방식 덕분에 무한히 많은 사용 사례를 커버하지만, 편해지기까지 1년쯤 걸리는 학습 곡선이 있다는 것임
    그 지점에 도달하면 평균적인 GUI 사용자보다 훨씬 생산적일 수 있지만, 거기까지 가려면 헌신과 고통이 필요하고 많은 사람은 자의가 아니라 어쩔 수 없이 그렇게 됨
    내 경우 첫 직장이 ssh로 고객 서버를 관리해야 했고, 그 서버들은 최소한만 설치되어 있었음. 종종 vim도 아니고 vi만 있었고, 그 환경에서 효과적으로 일하는 법을 찾는 것 말고는 선택지가 없었음
    그 경험이 없었다면 터미널에서 일하기 시작하는 고통을 감수했을지 확신이 없음

    • Wireshark와 비슷한 관계가 있음. 실시간 캡처와 표시, 클릭 가능한 GUI의 매력은 이해함
      하지만 어느 순간 거기서 시간을 너무 많이 낭비하고 있다고 느꼈음. tshark와 jq, 오래된 bash/awk/grep과 gnuplot으로 다시 명령줄로 돌아갔고, 이후에는 Python을 썼지만 여전히 tshark 출력을 사용했음
      결국 pcap과 pcapng 파서, ethernet-ip-udp/tcp 처리, 완전한 Java IDE까지 만들게 됐고 다시 돌아가지 않았음
      반복해서 써야 하는 모든 데이터 캡처·탐색 도구에서도 같은 구불구불한 길을 걸었음
      이런 도구 개선의 반복 단계를 겪는 사람이 나만은 아닐 것 같고, 이를 설명하는 잘 붙은 이름의 척도가 있으면 좋겠음
    • 논리가 틀렸다고 보지는 않지만, FrobnosticatorStudio 쪽 사람들도 일리가 있음
      터미널은 무한히 더 많은 능력을 주지만, 실제로 정기적으로 하는 일은 20개 정도일 가능성이 큼. 그 20개가 전부라면 학습 곡선 때문에 설득하기 어려움
      예를 들어 터미널에 있고 빌드 스크립트를 찾고 싶으면 cat packages.json | jq .scripts 같은 걸 할 수 있음
      터미널 안에서는 유용하지만 VSCode에 있으면 ctrl-p -> packages.json -> ctrl-f -> scr로 끝나고, 실제로 키 입력도 더 적음
      사람들의 작업 흐름은 정말 개인적이라 누군가에게 바꾸라고 말하지는 않겠지만, 내 경우 프로젝트를 그냥 텍스트로만 다루는 도구보다 프로젝트 구조를 이해하는 도구를 선호해서 IDE가 더 맞음
    • 명령줄 앱과 텍스트 사용자 인터페이스 앱을 구분한다면, 글은 특히 후자를 말하는 것으로 보임
      명령줄 앱은 grep, sort, cp, git, ls, tar처럼 셸에 명령을 써서 상호작용하는 도구를 뜻함. 일반적인 사용법을 알면 스크립트에서도 쓸 수 있고, 따라서 파이프라인으로 조합할 수 있음
      텍스트 사용자 인터페이스 앱은 Vim, Emacs, Tmux, Lynx, Tig, Midnight Commander, Claude Code처럼 쓰는 동안 터미널을 장악하는 대화형 앱을 뜻함
      이런 것들은 파이프라인으로 조합하지 않음. 더 정확히는 평소 쓰는 방식 그대로는 파이프라인에 넣어 쓰지 않음. 가능하다면 그 앱이 TUI와 별도로 명령줄 인터페이스를 제공했기 때문일 가능성이 큼
    • 정확히 이 점임. GUI 도구의 비조합성과 비표준화가 가장 큰 문제임
      모든 문제를 풀 때 같은 도구상자를 쓸 수 있게 되려면 시간이 걸리지만, 결국 더 효율적임
      다만 설득하기는 어렵다. 명령줄 도구로 아니면 풀기 힘든 문제를 해결해 보기 전까지는 그 단순함을 이해하기 쉽지 않음
    • 거의 20년 동안 명령줄로 일해 왔고, 그중 몇 년은 Vim을 주 편집기로 썼지만 결국 Sublime으로 옮긴 뒤 돌아보지 않았음
      그래도 모든 일에서 명령줄은 많이 씀. 보통 konsole 창을 띄워두고 빌드나 테스트가 필요하면 Sublime의 “build system” 지원 대신 alt+tab으로 넘어감
      Vim은 ssh가 필요하거나 휴대폰에서 Termux를 쓸 때만 사용함
      확장 가능한 GUI 도구인 Sublime, VSCode 등도 무한히 많은 사용 사례를 커버하며, 오히려 더 안정적이고 재현 가능한 실행 환경을 제공함
      이런 논쟁이 끝나지 않는 이유는 사람들이 대체로 닫힌 사고를 하기 때문이라고 봄. 남의 입장에 서기 어렵고, 자신이 틀렸을 가능성을 진지하게 받아들이기는 더 어려움
      결국 이 문제는 초보자에게만 중요함. 충분히 익숙해지고 나면 무엇을 쓰든 생산성 병목은 도구가 아니게 됨. 물론 ed라면 예외일 수 있음

  • “키보드 탐색이 마우스를 자주 잡는 것보다 훨씬 생산적이라는 걸 모른다”는 주장에 대해, 자신이 더 생산적이라고 말하는 사람 중 상당수는 실제로 측정해 본 적이 없음
    수년간 키보드 대 마우스 탐색 경쟁이 많이 있었고, 테스트 설계 세부 사항에 따라 한쪽이 이기기도 다른 쪽이 이기기도 했으며 차이가 꽤 큰 경우도 많았음
    실제 결과를 보기 전에는 사용자가 더 생산적이라고 말했던 방식이 패배하는 경우도 적지 않았음

    • 이런 걸 측정해야 한다고 생각하는 순간 애초에 핵심을 놓친 것 같음
      절대적인 생산성 지표를 쫓고 싶은 게 아니라, 흐름을 깨지 않는 환경을 원함
      많은 사람에게 마우스를 잡는 행위는 흐름을 깨고 어색하게 느껴지며, 1초 느린 것보다 더 나쁠 때가 많음. 머릿속에 있던 맥락에서 벗어나게 만들기 때문임
      내 경우 일할 때 마우스를 쓰는 게 자연스럽기 때문에, 모든 탐색을 키보드로 하도록 작업 흐름을 바꾸는 것은 어떤 상황에서 아주 조금 시간을 아낄지도 모른다는 이유만으로 엄청난 추가 노력을 들이는 일임
    • 꽤 환원적인 태도라고 봄. 도구의 주된 사용이 텍스트 기반이라면 키보드 탐색이 더 생산적일 수 있음
      워드프로세서, IDE, 파일 관리자처럼 읽고, 입력하고, 읽고 입력한 것을 처리하는 일이 중심인 도구에서는 사용자가 단축키를 배웠을 때 키보드 탐색이 더 빠르고 자연스럽다는 것을 보일 수 있음
      반대로 텍스트가 아닌 시각 정보가 중심인 도구에서는 키보드 대 마우스 논쟁이 훨씬 마우스 쪽으로 기움
      그래도 효과적인 단축키가 메뉴와 아이콘보다 훨씬 유용한 순간은 있음. CAD나 3D 모델링 소프트웨어를 보면, 사용자의 90% 작업은 시각적으로 표시된 공간 데이터를 다루는 일이지만, 도구 변경이나 도구 설정 수정 단축키를 알면 훨씬 빨라지고 중첩 메뉴를 계속 뒤질 필요가 줄어듦

  • 글쓴이가 자기 도구에 익숙하다는 사실을 더 낫다는 증거와 혼동하는 것 같아 걱정됨
    현실적으로 모든 도구에는 트레이드오프가 있고, 사용자가 도구 X를 도구 Y보다 선호한다면 멍청해서가 아니라 숙련자만 이해하는 그 도구의 affordance를 더 잘 활용하기 때문일 가능성이 큼
    개발자에게 vim, emacs, Sublime Text를 각각 10년씩 쓰게 한다면 무엇이 더 낫다고 확신하지 못할 것임. 개인적인 선호는 있겠지만, 다른 사람들이 왜 다른 도구를 선호하는지도 설명할 수 있을 것임
    익숙하지 않은 소프트웨어에 제대로 기회를 줘 본 적 없는 데서 나온 논쟁처럼 보임
    오래 굴러온 고참의 표식은 모든 소프트웨어와 그 소프트웨어를 개선하겠다는 약속에 대한 희미한 불신이라고 봄. 장기적으로 모든 소프트웨어는 평범함으로 수렴함

    • 글은 특정 도구가 아니라 사고방식을 비판한 것임. Sublime이 Vim보다 낫다고 말한 적은 없음
      도구의 마찰을 기능으로 보는 생각에 동의하지 않는다고 말했을 뿐임
      그의 논지를 그대로 가져와 Vim이 내게 완벽한 편집기임을 보일 수도 있음. 내가 Vim을 쓸 때는 보이지 않기 때문이고, 어느 정도는 Vim을 내가 원하는 도구로 바꿨기 때문임
      그는 Sublime을 원하는 도구로 바꿨음. 그래도 기본 요지는 유지됨. 다른 사람이 쓸 무언가를 만든다면 그 도구가 사용자에게 보이지 않게 만드는 것은 강력한 속성임
    • “장기적으로 모든 소프트웨어는 평범함으로 수렴한다”에 대한 다른 관점도 가능함. 어쩌면 그게 괜찮고, 고참들은 그걸 아는 것일 수도 있음
      평범하다는 것은 “보통 또는 일반적인 품질”이라는 뜻임
      다음 CRUD 앱을 만들 때 최신이자 최고인 비범한 기술이 꼭 필요하지는 않을 수 있음
    • “글쓴이가 익숙함을 자기 도구가 더 낫다는 증거와 혼동한다”는 말은 정말 내가 암시했거나 말한 내용이 아님. 그런 식으로 말한 부분을 인용해 보길 바람
      내가 쓴 문장을 인용하면 이렇다. “나를 당황하게 하는 것은 많은 사람이 그 마찰, 즉 도구의 한계를 우회하려는 노력을 ‘재미있는’ 부분으로 취급하고, 그것을 도구가 훌륭하다는 증거처럼 홍보한다는 점이다.”
      이것은 나나 다른 사람이 어떤 도구를 왜 선택하는지와는 상관없고, 결함을 퍼즐 게임처럼 우회할 대상으로 취급하는 태도에 관한 것임

  • 좋은 도구의 유지보수자는 사용자가 실제로 도구를 보는 방식보다 훨씬 부정적으로 받아들이는 경우가 많음
    “오늘 10명이 버그나 빠진 기능을 불평했고 9990명은 문제없이 썼다”와 “오늘 10명이 불평했고 90명만 문제없이 썼다”를 구분하기는 어려움. 하지만 사용자 만족도 90%에서 99.9%로 가는 데 필요한 노력은 엄청나게 다름
    이것이 많은 오픈소스 유지보수자 번아웃의 큰 요인이라고 강하게 의심함
    만족하지 못한 사용자는 만족한 사용자보다 훨씬 더 눈에 띄고, 새 사용자가 늘어나는 속도에 비해 같은 양의 버그 보고·기능 요청을 만들어내는 불만족 사용자 비율은 낮아짐
    결국 유지보수자에게는 아무리 개선해도 전체 품질 체감이 달라지지 않는다는 착시가 생기고, 계속할 동기가 깎임
    이 문제에 대한 좋은 해법은 잘 모르겠음. 명백한 답은 잘 작동할 때 더 자주 칭찬하는 것이지만, 현실에서는 잘 일어나지 않는 집단행동 문제에 가까움
    개인적으로는 무언가가 잘 작동하면 일부러 자주, 열정적으로 긍정적 피드백을 주려 하지만, 모두가 그렇게 하지 않는 한 큰 차이를 만들기는 어려움

  • 이 인용구가 떠오름
    “우리는 늘 허리를 굽히고 부산스럽게 비굴한 사람을 알아차리고, 아마 ‘얼마나 겸손한가!’라고 말할 것이다. 하지만 진정으로 겸손한 사람은 눈에 띄지 않는다. 세상은 그를 알지 못한다.”
    ~ Tito Colliander

  • “도구가 당신을 잘 섬긴다는 가장 분명한 신호는 그것을 의식하지 않게 되는 것, 즉 보이지 않게 되는 것이다. 결함을 취미로 바꾸지 않으므로 결함을 찬양하지 않고, 약간 짜증을 내며 우회할 뿐이다”라는 부분은 도구보다 사용자 의존성이 더 커 보임
    물론 서로 다른 도구는 서로 다른 사용자를 끌어들일 것이고, 강한 상관관계를 측정할 수도 있을 것임
    또한 이 입장은 균형이 부족함. 도구는 결코 완벽하지 않고, 때로는 개선할 수 있음을 깨닫게 되며, 그 변경을 구현하는 것과 그것이 습관에 미칠 영향을 저울질해야 함
    오래 쓸수록 그런 변화는 작아지겠지만, 사용 방식은 평생에 걸쳐 진화하고 도구도 그렇게 변하는 것이 자연스러움

  • 꽤 특이한 해석임
    글쓴이가 Vim은 “보인다”고 집착하면서 Sublime의 다중 커서와 기능은 그렇지 않다고 암시하는 게 이상함. 머리가 더 이상 생각하지 않도록 훈련됐다고 해서 덜 보이는 것은 아님
    다중 커서는 많은 도구에서 기본 기능이 아니며, 효과적으로 쓰는 것까지 포함하면 배워야 하는 대상임. Vim 키 바인딩과 마찬가지임
    게다가 Vim은 터미널 전용 사용자를 위한 TUI 선택지 이상임. 키보드를 자기 몸의 자연스러운 연장으로 배운 사람들이 마우스로 계속 왔다 갔다 하지 않기 위해 쓰는 키 바인딩이기도 함. Sublime을 15년 쓴 사용자에게 다중 커서가 그런 존재가 될 수 있는 것처럼

    • 내가 말한 건 그게 아님. Vim 전체가 아니라 Vim 매크로를 예로 들었음
      “일회성 텍스트 리팩터링 문제를 처리하려고 매크로를 만드는 게 얼마나 ‘재미있는지’ 말하는 사람들을 봤다. 하지만 그들이 무엇을 하고 얼마나 걸리는지 봤을 때 솔직한 반응은 이랬다. Sublime의 다중 커서로 1분이면 하거나, 그냥 짧은 스크립트를 썼을 것이다.”
      그리고 “나를 당황하게 하는 것은 많은 사람이 그 마찰, 즉 도구의 한계를 우회하려는 노력을 ‘재미있는’ 부분으로 취급하고, 그것을 도구가 훌륭하다는 증거처럼 홍보한다는 점이다.”
      Vim 매크로를 효과적으로 쓸 수 있다면 좋음. 하지만 수십 년 Vim을 써도 못 쓴다면, 그것을 “재미있는” 부분이라고 홍보하지는 말아야 함
    • 특히 이상한 점은 누군가 Vim을 풀기 재미있는 퍼즐이라고 묘사하는 것을 들어본 기억이 거의 없다는 것임
      가장 흔한 정서는 학습 곡선은 있지만 결국 그만한 가치가 있다는 쪽임
    • 글에는 “다중 커서는 99.999%의 경우 매크로보다 정말 낫다. 직접적인 시각 피드백을 주기 때문이다”라고 되어 있음
      무슨 뜻인지 모르겠음. Vim 매크로도 작성하는 동안 직접적인 시각 피드백을 줌. 녹화하면서 평소처럼 편집하고, 나중에 그 편집을 재생하는 방식임
      작성 중 텍스트에 미치는 실시간 효과를 보지 않고 매크로를 쓰는 것이 기술적으로 가능할지는 모르지만, 나는 그렇게 해본 적이 없음
      궁금해서 다중 커서를 찾아봤고, 장점은 설명하기 쉬운 하나의 인터페이스라는 점 같음. 실제로는 이를 대체하려고 여러 Vim 명령을 쓸 것임
      다중 커서를 쓸 만한 대부분의 일에는 다중 커서가 매크로보다 나을 수 있다는 데는 동의함. 하지만 보통 그런 일에는 매크로를 쓰지 않음
      내가 매크로로 하는 대부분의 일은 다중 커서로 할 수 없어 보임
      “이 상황에서는 다중 커서가 훌륭하고 Vim에는 좋은 대안이 없다”는 예시가 있다면 틀렸다는 걸 증명받고 싶음
    • 동의함. 예전에는 Vim 매크로를 즐겨 썼지만 Helix로 옮긴 뒤로는 다중 커서를 늘 쓰고 매크로는 거의 쓰지 않음
      그렇다고 다중 커서에 학습 곡선이 없다는 뜻은 아님. 여전히 커서를 올바른 위치에 놓는 방법을 생각해야 함
    • 읽다 보니 중간쯤에서 대부분이 AI 헛소리 같다는 느낌이 들었음

  • “보이지 않음”이라는 표현은 예전에 emacs magit을 설명할 때 썼음
    git 출력 위의 얇은 레이어로, 나타났다가 UI 상태에서 매개변수를 추론하고 평소의 git 명령을 호출한 뒤 사라짐
    가볍고 빠름. 큰 프로젝트에서는 아닌 것 같지만 그렇다함

답변달기