# 도구를 먼저 고쳐라 > Clean Markdown view of GeekNews topic #26926. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26926](https://news.hada.io/topic?id=26926) - GeekNews Markdown: [https://news.hada.io/topic/26926.md](https://news.hada.io/topic/26926.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-23T20:33:03+09:00 - Updated: 2026-02-23T20:33:03+09:00 - Original source: [ochagavia.nl](https://ochagavia.nl/blog/fix-your-tools/) - Points: 1 - Comments: 1 ## Topic Body - 오픈소스 라이브러리의 **버그를 추적하던 과정에서 디버거가 작동하지 않는 문제**가 발생함 - 코드가 실행되었음에도 **중단점이 무시되는 현상**이 나타나며, 다른 방법으로 문제를 찾으려 시도함 - 로그 출력을 추가하는 등 **우회적 진단 시도**를 했지만 원하는 통찰을 얻지 못함 - 결국 **디버거 설정 오류를 수정**하자 프로그램의 동작을 세밀히 관찰할 수 있었고, 이를 통해 버그를 해결함 - 문제 해결에 몰두한 나머지 **도구 자체의 결함을 간과한 경험**을 통해, 개발자는 먼저 도구를 고쳐야 효율적으로 문제를 해결할 수 있음을 강조함 --- ### 버그 진단 중 발생한 문제 - 유지 중인 **오픈소스 라이브러리의 버그**를 찾는 과정에서 디버거가 중단점을 무시하는 현상 발생 - 코드가 해당 줄을 실행했음이 확실했지만, **프로그램이 중단 없이 완료**됨 - 문제 해결에 집중한 나머지 디버거 문제를 무시하고 다른 접근을 시도함 - 코드 수정과 **로그 추가를 통한 진단 시도**를 했으나, 유용한 정보를 얻지 못함 ### 디버거 수정과 문제 해결 - 디버거 문제를 해결하기로 결정하고, **한 줄짜리 설정 변경**으로 수정 완료 - 수정 후 프로그램의 동작을 자세히 관찰할 수 있었음 - 이 정보를 바탕으로 **버그를 성공적으로 해결**함 ### 깨달음과 교훈 - 버그를 고치려는 열정이 오히려 **도구의 문제를 간과하게 만든 역설적 상황**을 인식 - 도구가 제대로 작동하지 않으면 문제 해결 효율이 떨어짐을 체험 - 개발자에게 필요한 것은 **문제보다 먼저 도구를 점검하고 고치는 습관**임 - “**Fix your tools**”이라는 문구로, 모든 프로그래머에게 도구의 중요성을 상기시키는 메시지로 마무리됨 ## Comments ### Comment 51706 - Author: neo - Created: 2026-02-23T20:33:03+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47112174) - 경력 30년 차인데 요즘 **개발 도구들이 너무 망가져 있음** Linux에서 Clio로 코드를 쓰는데, 몇 년째 버그가 점점 심해지고 있음 이제는 그냥 “안 되면 안 되는 거지” 하고 넘어감. 인생이 짧은데 남의 코드까지 고칠 여유는 없음 - 문제를 고치려다 보면 결국 **‘yak shaving’** 에 빠지게 됨 사소한 문제를 해결하려다 보면 세세한 작업이 꼬리에 꼬리를 물고 이어짐 관련 영상은 [여기](https://m.youtube.com/watch?v=_UZFI-8D5uA)에서 볼 수 있음 - 이런 상황에는 정답이 없음 가끔은 도구와 라이브러리를 정리해두면 생산성이 폭발적으로 오르고, 다른 때는 그냥 **하드코딩**으로 밀어붙이는 게 더 빠름 AI가 도구를 다듬는 데 도움을 주지만, 동시에 범위가 커져서 결국 도구 관리에 똑같이 시간을 씀 결국 **감정적 미루기(procrastination)** 문제임. 전체 구조를 생각하기 싫어서 작은 수정만 반복하거나, 반대로 전체 설계를 미루고 세부 도구만 다듬는 식임 - ‘yak shaving’이 단순한 시간 낭비로 오해되는 게 아쉬움 사실은 **필요한 마찰과 불편함**을 다루는 과정이기도 함 하지만 그 불편이 진짜 필요한지 늘 점검해야 함 반복 작업을 자동화하거나 단축시키는 데 10~15분 투자하는 건 결국 미래의 시간을 사는 일임 - 영상은 예상대로였지만 여전히 웃김 - 관련된 [XKCD 349](https://xkcd.com/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는 절대 설치하지 말라**고 농담하고 싶음