Skip to content
Published on

좋은 도구는 보이지 않는다: gingerBill의 주장과 "너무 보이지 않는" 도구의 함정

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
공유하기
Authors

들어가며 — 보이지 않는 도구라는 주장

Odin 언어를 만든 gingerBill, 즉 도구를 만드는 쪽의 사람이 쓴 글 "Good Tools Are Invisible"이 최근 Hacker News 1위에 올랐다. 주장은 제목 그대로다. 좋은 도구는 보이지 않아야 하고, 그런 도구를 만드는 것이 도구 제작자의 목표라는 것이다. 그가 반복해서 경계하는 습관은, 도구의 결함을 "풀면 재미있는 퍼즐"로 되파는 태도다. 그는 도구가 재미있길 원하지 않는다. 보이지 않길 원한다.

이 글의 가장 날카로운 부분은 심리적인 지적이다. 생산적이라고 느끼는 것과 실제로 생산적인 것은 다르다. 어려운 도구로 어려운 문제를 풀면 기분이 좋고, 사람들은 그 기분을 성과로 착각한다. 그가 제시하는 정직한 지표는 퍼즐을 푼 쾌감이 아니라 벽시계 시간과 그 과정에서 저지른 실수의 수다. 에디터에 익숙해지면 도구는 배경으로 녹아 사라진다. 하지만 무언가를 쉽게 처리하지 못하는 순간, 도구는 다시 보이기 시작한다.

나머지 논지도 같은 축 위에 있다. 대부분의 경우 멀티 커서가 vim 매크로보다 빠르다는 예시, 강한 기본값은 사용자의 시간에 대한 존중이라는 주장, 그리고 그의 표현대로 "학습 곡선은 비용이지 미덕이 아니다"라는 문장. 도구가 정체성이 되면 그 결함을 인정하는 일이 자신을 부정하는 것처럼 느껴져 정직한 평가가 막힌다는 지적도 좋다. 그는 프로그래머가 과한 설정 가능성을 즐기는 이유를 우연적 복잡성(accidental complexity) 으로 설명한다. 다만 그는 vim이나 emacs를 실제로 생산적으로 쓰는 사람을 비난하지는 않는다고 못박는다. 비판의 대상은 도구 선택이 아니라, 마찰을 미덕으로 포장하는 사고방식이다.

동의하는 지점 — 마찰을 기능으로 파는 수사법

이 글에서 가장 강한 대목은 "느끼는 생산성"과 "실제 생산성"의 구분이라고 본다. 매일 겪는 일이기 때문이다. 저장 시 포맷팅, LSP 자동완성, 손에 맞는 키맵 — 이것들이 제대로 동작할 때 나는 에디터를 의식하지 않는다. 반대로 언어 서버가 멈추거나 자동완성이 엉뚱한 후보를 올리는 순간, 도구는 다시 눈에 들어온다. "익숙해지면 사라지는가"는 실제로 쓸 만한 기준이다.

그는 GUI의 한계가 본질이 아니라 도구 제작자가 노력을 덜 들인 결과이며, 터미널 UI가 본질적으로 더 낫다는 생각은 틀렸다고도 말한다. 대체로 동의한다. 잘 만든 GUI — 좋은 프로파일러나 diff 화면 — 는 터미널만큼, 때로는 그 이상으로 보이지 않는다. 터미널이라면 머릿속에서 재구성해야 할 구조를 눈앞에 펼쳐 주기 때문이다. "TUI냐 GUI냐"는 잘못된 축이고, "나에게 퍼즐을 몇 개나 던지는가"가 옳은 축이다.

마찰을 기능으로 되파는 수사법에 대한 비판에도 동의한다. "이건 익숙해지면 빨라져"라는 말은 종종 매몰 비용을 정당화하는 문장이다. 배우는 데 쓴 시간이 아까워서, 그 어려움 자체를 가치로 승격시키는 것이다. 퍼즐을 푼 만족이 아니라 벽시계 시간과 실수 횟수로 재자는 제안은 감상이 아니라 엔지니어링이다.

가장 깊은 신호는 따로 있다. 도구가 정말로 보이지 않을 때, 나는 그 도구에 대한 의견 자체가 사라진다. 좋다 나쁘다를 말할 일이 없어진다 — gingerBill이 "쓰고 있다는 사실을 잊는다"고 표현한 상태다. 반대로, 지금 에디터 논쟁을 벌이고 있다면 적어도 그 순간 그 도구는 나에게 보이지 않는 상태가 아니다.

한 군데는 가볍게 반박하고 싶다. 매크로가 멀티 커서보다 "99.999%" 열등하다는 표현은 수사적 과장이다. 매크로는 기록하고, 재생하고, 파일로 저장해 버전 관리까지 할 수 있다 — 멀티 커서가 잘 못 하는 일이다. 그럼에도 그의 더 깊은 논점, 즉 "도구를 낭만화하지 말고 산출을 측정하라"는 여전히 옳다. 반박은 예시를 흠집 낼 뿐, 주장을 무너뜨리지 못한다.

"너무 보이지 않는" 도구의 함정

여기서 현업의 단서가 하나 붙는다. gingerBill의 "보이지 않음"은 인터페이스에 마찰이 없다는 뜻이다. 그런데 도구가 보이지 않는 방식에는 다른 축이 하나 더 있다. 내부 동작이 불투명해서 보이지 않는 경우다. 이 둘은 전혀 다르다. 앞의 것은 좋고, 뒤의 것은 위험하다.

빌드 시스템이 대표적이다. 캐시가 맞고 증분 빌드가 빠를 때 빌드 도구는 완벽하게 보이지 않는다. 문제는 캐시가 왜 미스 났는지, CI가 왜 갑자기 40분이 걸리는지 설명해 주지 않을 때다. 잘 동작할 때 보이지 않던 도구가 고장 났을 때도 여전히 보이지 않는다면, 그건 우아함이 아니라 관측 불가능성이다.

쿠버네티스 오퍼레이터에서 이 문제가 가장 선명하다. 원하는 상태를 선언하면 오퍼레이터가 알아서 조정(reconcile)한다. 손이 안 가니 보이지 않는다. 바로 그 보이지 않음 때문에, 재조정이 조용히 멈춰도 — 파이널라이저가 걸리거나, 어드미션 웹훅이 죽거나, CRD의 어떤 필드를 소리 없이 무시하거나 — 아무도 눈치채지 못한다. 선언형 도구의 편안함은 종종 "무슨 일이 일어나는지 모른다"는 비용과 짝을 이룬다. 나도 노드가 몇 주 동안 스케줄 불가 상태로 방치된 걸 한참 뒤에야 발견한 적이 있다(포스트모템). 도구가 너무 조용했기 때문이다.

여기엔 더 깊은 대가가 있다. 보이지 않는 추상은 나의 역량을 대신 짊어져 준다 — 그러다 새는 순간, 그 밑을 한 번도 들여다본 적 없는 사람만 남는다. 조엘 스폴스키가 "사소하지 않은 모든 추상은 어느 정도 샌다"고 한 바로 그 지점이다. kubectl apply가 늘 "그냥 되면", 안 되는 날 당직 엔지니어는 그 아래에 무엇이 있는지 배운 적이 없다. 도구는 보이지 않을수록 좋지만, 보이지 않는다고 그 아래가 사라지는 것은 아니다.

보이지 않되, 고장 나면 크게 울리는

그래서 나는 gingerBill의 기준에 축을 하나 더한다. 좋은 도구는 쓸 때는 보이지 않아야 하고, 동시에 고장 났을 때는 크고 명확하게 다시 보여야 한다. 마찰의 보이지 않음(좋음)과 실패의 침묵(나쁨)은 서로 다른 축이다. 두 축을 겹치면 도구는 네 칸으로 나뉜다.

                 실패 시 시끄럽다        실패 시 조용하다
──────────────  ────────────────────  ────────────────────
평소 안 보인다   신뢰하는 도구(목표)      가장 위험한 도구
평소 거슬린다    정직하지만 미완성        최악 — 느리고 깜깜함

내가 가장 신뢰하는 도구는 왼쪽 위 칸이다 — 평소엔 보이지 않고, 고장 나면 시끄럽다. 가장 위험한 도구는 오른쪽 위다 — 잘 될 때도 안 될 때도 똑같이 조용하다. 이건 gingerBill을 반박하는 게 아니라 보완하는 것이다. 그가 옳게 강조한 강한 기본값에, 나는 관측 가능성을 짝지운다.

좋은 오퍼레이터는 조건(condition)과 이벤트, 메트릭을 내보낸다. 평소엔 손이 안 가서 보이지 않지만, 들여다보면 자기가 무엇을 하는지 말해 준다. 내가 Rust로 작은 오퍼레이터를 써서 이미 죽어 있던 내 플릿을 찾아낸 일도(그 이야기) 결국 도구를 시끄럽게 만든 사례였다. "마법처럼 알아서 되는" 프레임워크가 위험한 이유도 같다. 추측이 맞을 땐 보이지 않다가, 추측이 틀리는 순간 디버깅할 표면 자체가 사라진다.

가시성은 실패할 때까지 기다릴 필요도 없다. 좋은 도구는 원할 때 자신을 보이게 해 준다 — --dry-run, kubectl describe, 쿼리의 EXPLAIN, 빌드의 --verbose 그래프. 평소엔 보이지 않다가, 물어보는 순간 들여다볼 수 있다. 매일 주시하지 않고도 멘탈 모델을 유지하게 해 주는 건 바로 그 "요청 시 가시성"이다.

마무리

gingerBill의 글은 읽을 가치가 있다. "마찰을 재미로 되파는 것은 합리화"라는 진단은 정확하고, "익숙해지면 사라지는가"는 도구를 고르는 좋은 리트머스다. 그의 결론에 나는 크게 이견이 없다.

현업에서 단서를 하나 붙이자면 — "고장 나면 다시, 크게 보이는가"도 함께 물어야 한다. 사용 중엔 보이지 않고 실패 시엔 읽을 수 있는 도구. 그 둘을 다 갖춘 도구가, 내가 오래 신뢰하게 된 도구였다.

그의 논점과 내 논점 밑에는 같은 가치가 있다. 사용자에 대한 존중이다. 그는 도구가 당신의 시간을 존중하길 요구하고, 나는 거기에 당신의 이해까지 존중하길 더한다. 오늘 내 시간을 아껴 주지만 고장 났을 때 나를 길에 버려두는 도구는, 그 시간을 아낀 게 아니라 잠시 빌린 것뿐이다.

참고 자료

Discuss on Twitter • View on GitHub