도구를 먼저 고쳐라

• 오픈소스 라이브러리의 버그를 추적하던 과정에서 디버거가 작동하지 않는 문제가 발생함
• 코드가 실행되었음에도 중단점이 무시되는 현상이 나타나며, 다른 방법으로 문제를 찾으려 시도함
• 로그 출력을 추가하는 등 우회적 진단 시도를 했지만 원하는 통찰을 얻지 못함
• 결국 디버거 설정 오류를 수정하자 프로그램의 동작을 세밀히 관찰할 수 있었고, 이를 통해 버그를 해결함
• 문제 해결에 몰두한 나머지 도구 자체의 결함을 간과한 경험을 통해, 개발자는 먼저 도구를 고쳐야 효율적으로 문제를 해결할 수 있음을 강조함

---

버그 진단 중 발생한 문제

• 유지 중인 오픈소스 라이브러리의 버그를 찾는 과정에서 디버거가 중단점을 무시하는 현상 발생
  • 코드가 해당 줄을 실행했음이 확실했지만, 프로그램이 중단 없이 완료됨
  • 문제 해결에 집중한 나머지 디버거 문제를 무시하고 다른 접근을 시도함
• 코드 수정과 로그 추가를 통한 진단 시도를 했으나, 유용한 정보를 얻지 못함

디버거 수정과 문제 해결

• 디버거 문제를 해결하기로 결정하고, 한 줄짜리 설정 변경으로 수정 완료
  • 수정 후 프로그램의 동작을 자세히 관찰할 수 있었음
  • 이 정보를 바탕으로 버그를 성공적으로 해결함

깨달음과 교훈

• 버그를 고치려는 열정이 오히려 도구의 문제를 간과하게 만든 역설적 상황을 인식
• 도구가 제대로 작동하지 않으면 문제 해결 효율이 떨어짐을 체험
• 개발자에게 필요한 것은 문제보다 먼저 도구를 점검하고 고치는 습관임
• “Fix your tools”이라는 문구로, 모든 프로그래머에게 도구의 중요성을 상기시키는 메시지로 마무리됨

[GN⁺]

Hacker News 의견들

• 경력 30년 차인데 요즘 개발 도구들이 너무 망가져 있음
  Linux에서 Clio로 코드를 쓰는데, 몇 년째 버그가 점점 심해지고 있음
  이제는 그냥 “안 되면 안 되는 거지” 하고 넘어감. 인생이 짧은데 남의 코드까지 고칠 여유는 없음

• 문제를 고치려다 보면 결국 ‘yak shaving’ 에 빠지게 됨
  사소한 문제를 해결하려다 보면 세세한 작업이 꼬리에 꼬리를 물고 이어짐
  관련 영상은 여기에서 볼 수 있음

  • 이런 상황에는 정답이 없음
    가끔은 도구와 라이브러리를 정리해두면 생산성이 폭발적으로 오르고, 다른 때는 그냥 하드코딩으로 밀어붙이는 게 더 빠름
    AI가 도구를 다듬는 데 도움을 주지만, 동시에 범위가 커져서 결국 도구 관리에 똑같이 시간을 씀
    결국 감정적 미루기(procrastination) 문제임. 전체 구조를 생각하기 싫어서 작은 수정만 반복하거나, 반대로 전체 설계를 미루고 세부 도구만 다듬는 식임
  • ‘yak shaving’이 단순한 시간 낭비로 오해되는 게 아쉬움
    사실은 필요한 마찰과 불편함을 다루는 과정이기도 함
    하지만 그 불편이 진짜 필요한지 늘 점검해야 함
    반복 작업을 자동화하거나 단축시키는 데 10~15분 투자하는 건 결국 미래의 시간을 사는 일임
  • 영상은 예상대로였지만 여전히 웃김
  • 관련된 XKCD 349도 떠오름
  • 이런 일이 생기는 이유는 도구들이 너무 방치돼서 전부 망가졌기 때문임
    결국 기술 부채는 언젠가 갚아야 하므로, 조금씩 갚는 습관을 들여야 함

• 엔지니어링은 결국 도끼를 가는 과정의 연속임
  Kent Beck의 말처럼 “먼저 변화를 쉽게 만들고, 그다음에 쉬운 변화를 하라”는 접근을 좋아함

  • 처음 보는 코드 개선 작업을 맡았는데, 코드가 너무 엉망이라 결국 리팩터링부터 하기로 함
    단순히 기능을 추가하는 것보다 코드를 개선하는 게 훨씬 뿌듯했음
  • 이 접근이 AI 기반 코딩에는 아직 부족함
    AI는 같은 코드를 여러 번 반복해도 이상하다고 생각하지 않기 때문에 구조화나 재사용이 안 됨
  • 도끼를 처음부터 4시간 동안 가는 건 비효율적일 수도 있음
    실제로는 작업 중간에 무뎌질 때 다시 가는 게 더 현실적임
  • 프로그래밍에서는 ‘도끼’(vim 같은 최소한의 도구)를 선호하지만, 나무를 벨 때는 체인톱이 훨씬 낫다는 생각도 듦
  • 동료들은 대부분 파이프로 나무를 자르는 식으로 일함
    “지금은 바빠서 도끼를 갈 시간이 없어!”라며 계속 비효율적으로 일함

• “버그를 고치려는 욕심이 오히려 도구를 먼저 고쳐야 한다는 사실을 가리더라”는 말이 인상적이었음
  Kenneth Stanley의 『Why Greatness Cannot Be Planned』에서도 이 현상을 다룸

• 훌륭한 조언임. 나도 매일 실천하려 노력함
  하지만 “이제 도구 고치기 그만하고, 진짜 문제를 고쳐라”는 후속 조언은 잘 안 지켜짐

• 나도 이런 상황을 자주 겪음
  작은 마찰을 고치면 나중에 시간을 아끼지만, 끝없이 도구만 만지작거리게 되는 함정이 있음
  진짜 어려운 건 “이 정도면 충분하다”고 판단하고 넘어가는 시점임

• 도구는 노력의 배수 효과를 주는 존재임
  하지만 ‘yak shaving’과 불필요한 수작업 사이의 균형을 찾는 게 어렵음
  장기적으로 같은 도구를 쓸 계획이라면, 1%의 개선도 누적 효과가 크기 때문에 생각보다 yak shaving 쪽으로 기울어야 할지도 모름

• 가장 큰 교훈은 올인원 툴은 대부분 별로라는 것임
  콘텐츠 파이프라인을 위해 Make, Airtable, n8n 같은 no-code 툴을 다 써봤지만, 일정 규모 이상에서는 전부 깨짐
  결국 Python 스크립트로 직접 API 호출하는 게 훨씬 안정적이었음
  진짜 해결책은 복잡한 툴을 고치는 게 아니라, 단순하고 투명한 도구로 교체하는 것이었음

  • n8n 같은 툴을 안 써봤는데, Python보다 나은 경우가 있을지 궁금함
  • 그래서 나는 Airflow를 정말 좋아함

• 디버거로 코드의 흐름을 직접 보는 것은 매우 유용함
  정적 분석보다 훨씬 직관적으로 이해할 수 있음

  • 하지만 디버거가 항상 도움이 되는 건 아님
    변수나 브레이크포인트를 계속 바꾸다 보면 문제의 본질을 놓치기 쉬움
    디버거는 가설을 검증하는 도구로만 써야 함. 그렇지 않으면 ‘진전된 것 같은 착각’에 빠짐

• 이런 글을 좋아한다면 Emacs는 절대 설치하지 말라고 농담하고 싶음