# 개발자의 저주: 고치는 능력을 가진 자의 무한한 책임감 > Clean Markdown view of GeekNews topic #20735. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=20735](https://news.hada.io/topic?id=20735) - GeekNews Markdown: [https://news.hada.io/topic/20735.md](https://news.hada.io/topic/20735.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-05-07T09:46:03+09:00 - Updated: 2025-05-07T09:46:03+09:00 - Original source: [notashelf.dev](https://notashelf.dev/posts/curse-of-knowing) - Points: 55 - Comments: 21 ## Summary 개발자는 사소한 자동화를 반복하면서 모든 시스템이 **고쳐야 할 대상**으로 보이는 **인지의 임계점**에 도달하게 됩니다. 기술력이 쌓일수록 문제를 인식하는 것을 넘어 **책임처럼 느끼게 되는 감정의 무게**를 가지게 되며, 이는 때로는 **자기 구속적 노동**으로 이어집니다. **완전한 해결이라는 환상은 존재하지 않으며**, 지속적인 관리가 필요하다는 현실과 마주하게 됩니다. 결국, 진정으로 필요한 기술은 모든 것을 고치는 능력이 아니라, **무언가를 고치지 않고도 견딜 수 있는 마음의 여유**입니다. ## Topic Body - 사소한 자동화를 반복하다 보면 어느 순간 모든 도구와 시스템이 **고쳐야 할 대상**으로 보이게 되는 **인지의 임계점**에 도달하게 됨 - 기술력이 쌓일수록 문제를 단순히 인식하는 것을 넘어 **책임처럼 느끼게 되는 감정의 무게**를 가지게 됨 - **고치고자 하는 욕구**는 단순한 생산성 향상을 넘어서 **감정 조절의 수단**이 되기도 하며, 때론 자신이 만든 시스템에 **스스로 갇히는 결과**를 낳음 - 시스템은 시간이 지나며 반드시 망가지고, **완전한 해결이라는 환상은 존재하지 않음** - 결국 진짜 필요한 기술은 모든 것을 고치는 능력이 아니라, **무언가를 고치지 않고도 견딜 수 있는 마음의 여유**임 --- ### 시작은 사소한 자동화 - 파일 이름을 바꾸는 파이썬 스크립트나 `git` 명령어 단축 등 **작은 생산성 향상 작업**에서 시작됨 - 시스템의 불편을 직접 고치고 나면, **세상의 모든 것들이 개선 대상처럼 보이기 시작함** - 어느 순간부터는 “할 수 있다”를 넘어 “**해야 한다**”는 **도덕적 강박감**으로 전환됨 ### 기술력의 무게감 - 프로그래밍 이전에는 불편한 소프트웨어를 그냥 넘길 수 있었지만, 이제는 **문제점이 선명히 보임** - 개발자가 만든 허술한 코드나 하드코딩된 설정들이 **비난처럼 느껴짐** - 모든 시스템과 소프트웨어가 **고쳐야 할 TODO 리스트**로 보이는 인식 전환이 일어남 ### 계속되는 리팩터의 삶 - 매번 “이건 내가 더 잘 만들 수 있어”라는 생각으로 **자기만의 도구 개발에 빠져듦** - 정리되지 않은 코드 디렉토리, 무수한 시도와 포기, 끝없는 구조 재설계는 **자기 구속적 노동**이 되기도 함 - Kafka의 “**새장을 짓고 새를 기다리는 것**”이라는 비유처럼, 목적 없는 도구 제작에 빠져들 수 있음 ### 소프트웨어는 썩는다 - 완벽해 보이던 스크립트도 **언젠가 외부 변화로 인해 무용지물**이 됨 - 웹사이트 레이아웃 변경, 패키지 버전 변경, 의존성 오류 등 - 문제 발생 시 단순 불편이 아닌 **죄책감**을 느끼게 됨 - 결국 **지속적인 관리가 필요하다는 현실**과 마주하게 됨 ### 자동화라는 환상 - “한 번만 세팅하면 다시 안 건드려도 된다”는 **거짓된 희망**을 자주 품게 됨 - 프로그래밍을 문제 해결의 승리로 생각하지만, **끝나지 않는 전쟁**일 뿐임 - 완성이라는 개념은 없고, **언제나 침수되는 참호를 파고 있을 뿐**임 ### 감정 조절의 수단이 된 코딩 - 도구를 만드는 행위는 때론 **삶의 혼란을 통제하려는 심리적 반응**임 - 시스템이 복잡할수록 오히려 자신이 정돈된 느낌을 받음 - 복잡한 삶을 피하기 위해 **새로운 앱이나 리팩터링을 시도**하며 **자기 위안을 얻음** ### 예고 없는 번아웃 - 번아웃은 단순한 과로보다 **과도한 책임감에서 비롯됨** - “내가 고칠 수 있는 걸 왜 안 고치지?”라는 **자기 비난**이 스트레스를 가중시킴 - 끝없는 기술적 책임감은 **자기파괴적인 부담**으로 작용함 ### 내려놓는 기술 배우기 - 모든 문제를 해결할 필요는 없음 - 때론 **고치지 않아도 된다는 사실을 아는 것이 더 큰 통제력**임 - 결함을 인정하고, 그냥 쓰는 것도 **의식적인 선택**이 될 수 있음 ### 진짜 기술은 감정의 명료함 - 고칠 수 있는 기술보다 **고치지 않아도 되는 마음의 기술**이 더 중요함 - 언제 멈춰야 하는지, 어떤 프로젝트는 **자기 위안용인지** 구별하는 능력 - 모든 것을 고치려는 강박에서 벗어나, **불완전함 속에서도 편안함을 찾는 태도**가 필요함 > 결국 프로그래밍에서 가장 어려운 기술은, > **"망가진 것을 그냥 두는 법"** 을 배우는 일임 ## Comments ### Comment 38409 - Author: ndrgrd - Created: 2025-05-10T08:34:12+09:00 - Points: 1 모든 것에는 목적이 있습니다. 목적을 달성했다면 그만 고쳐도 됩니다. 하지만 목적을 달성하지 못했다면 고쳐야 합니다. 프로젝트의 목적을 명확히 파악하는 것이 시작이겠네요. ### Comment 38324 - Author: techiemann - Created: 2025-05-08T09:55:49+09:00 - Points: 2 세상에는 은행들과 결제사들 개판난 API 들을 묶어 정리해주는 일 만으로도 수천억대 가치를 지니는 기업도 있다는 걸 깨달으면 편합니다 ㅋㅋ ### Comment 38344 - Author: dkang - Created: 2025-05-08T13:06:59+09:00 - Points: 1 - Parent comment: 38324 - Depth: 1 쿠x.. ### Comment 38322 - Author: techiemann - Created: 2025-05-08T09:52:47+09:00 - Points: 3 VB 6.0과 COM + OLE + 액티브X 으로 만들어진 시스템이 여전히 잘만 돌아가는걸 보고 기겁해서 다시 짜고 싶은 욕망이 든다면 당신은 고통받을 사람입니다 ### Comment 38321 - Author: wedding - Created: 2025-05-08T09:51:16+09:00 - Points: 1 결국 프로그래밍에서 가장 어려운 기술은, "망가진 것을 그냥 두는 법" 을 배우는 일임 공감합니다. 일을 벌이는 타입이라 항상 고생합니다... ### Comment 38318 - Author: techiemann - Created: 2025-05-08T09:41:51+09:00 - Points: 1 일개 프로그래머가 얼기설기 엮어주는 자동화는 당연히 깨질수 밖에 없죠 ### Comment 38311 - Author: bluekai17 - Created: 2025-05-08T09:12:25+09:00 - Points: 1 좋은내용 ### Comment 38294 - Author: kgh1379 - Created: 2025-05-07T20:12:34+09:00 - Points: 1 번아웃 도트뎀 : 힘들게 업무 자동화했더니 그 혜택은 옆에 동료가 보고, 정작 본인은 다른 업무의 자동화 작업에 투입될 때; ### Comment 38406 - Author: bungker - Created: 2025-05-10T08:15:26+09:00 - Points: 2 - Parent comment: 38294 - Depth: 1 15분이면 하는 업무를 2일걸려 자동화했더니 월급루팡 들은 1인입니다 ### Comment 38285 - Author: loblue - Created: 2025-05-07T15:37:20+09:00 - Points: 2 과도한 책임감은 프로그래머의 직업병같은거라 시스템으로 해결해줘야해요. Quality Assurance 팀에서 Assure 해줘야죠. ### Comment 38303 - Author: roxie - Created: 2025-05-08T02:17:17+09:00 - Points: 1 - Parent comment: 38285 - Depth: 1 QA 가 개발자의 과도한 책임감을 억제해 줄 수 있는건가요? 잘 이해가 안되어서요. ### Comment 38335 - Author: loblue - Created: 2025-05-08T11:10:53+09:00 - Points: 3 - Parent comment: 38303 - Depth: 2 개발자에게 과실여부를 따지며 "네가 코딩 잘못했네" 가 쌓이면 개발자는 책임감에 눌려서 새로운 시도를 기피하게 되고 결국은 발전없는 안전한 코드만 작성하게 되죠. QA가 Assure 해야한다는게 그 뜻입니다. 발전적인 코딩을 하려면 어느정도 리스크는 지게 마련이고 그걸 검증하고 책임져주는게 QA가 되야하는거죠. ### Comment 38336 - Author: roxie - Created: 2025-05-08T11:14:04+09:00 - Points: 1 - Parent comment: 38335 - Depth: 3 이 글을 그렇게도 읽을 수 있군요? 저는 이 글이 굳이 따지자면 야크 쉐이빙을 비판하는 글이라고 생각했네요 ### Comment 38350 - Author: loblue - Created: 2025-05-08T14:40:03+09:00 - Points: 1 - Parent comment: 38336 - Depth: 4 roxie 님 말씀대로 본문에 대한 얘기는 야크 쉐이빙에 대한 얘기가 맞는데, 제 개인적인 경험에 비추다보니 본문의 내용과 약간 딴판인 이야기가 되었네요. ### Comment 38262 - Author: savvykang - Created: 2025-05-07T11:31:42+09:00 - Points: 2 NIH(not invented here) 현상으로도 설명할 수 있지 않을까요? 유지보수는 곧 고정비용이라는 것과 비용에 사람의 노력도 포함된다는 걸 잊지 말아야 한다고 생각합니다 ### Comment 38261 - Author: ztaka - Created: 2025-05-07T11:24:33+09:00 - Points: 4 이짓을 오래하기 위해선 과도한 책임감으로 보상심리의 굴레로 빠지기 전에 때때로 책임과 감정의 무게를 덜어놓는 연습도 필요한 것 같습니다. 저도 잘 조절이 안되는 부분이기도한데 ㅋㅋ... 좋은 내용이네요 ### Comment 38304 - Author: roxie - Created: 2025-05-08T02:18:35+09:00 - Points: 1 - Parent comment: 38261 - Depth: 1 요거 좋은 포인트인 것 같습니다. 책임감은 말 그대로 책임을 느끼는 것이기 때문에 그 자체로는 댓가를 요구하지 않는 법이죠. 하지만 시간이 지나면, 몸과 마음은 지치는 반면 책임감은 쉽게 사라지지 않고, 그 간극을 메꾸기 위해 (그렇게 연결지으면 안되는 것인데도) 댓가를 바라기 시작하는 것 같습니다. 본인도 모르게요. ### Comment 38256 - Author: madsyntst - Created: 2025-05-07T10:52:34+09:00 - Points: 2 뭐, "망가진 것을 그냥 두는법"보다 그나마 나은 타협점은 "망가지기 전까지는 손대지 마라"겠죠 :) ### Comment 38242 - Author: neo - Created: 2025-05-07T09:46:03+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=43902212) * 연극을 할 때 배운 인용구가 있음. 예술의 과정을 어려운 것을 습관으로 만들고, 습관적인 것을 쉽게 만들고, 쉬운 것을 아름답게 만드는 것이라고 설명함 - 배우로서 대사를 암기하고, 캐릭터의 동기를 이해하며, 관객이 감정과 의미를 공유하도록 공연을 조율함 - 소프트웨어에서는 컴퓨터가 원하는 대로 작동하도록 하는 마법의 주문을 배우고, 그 주문이 왜 작동하는지 이해하며, 문제를 더 아름답게 해결하는 방법을 찾음 * UI 문제에 대한 개인적인 의견을 제시함 - 인터페이스는 (재)렌더링이 완료된 후 몇 밀리초 동안 상호작용할 수 없어야 함 - 알림을 실수로 잘못 누르면 알림을 잃어버리는 경우가 발생함 * 개인 프로젝트에 대한 어려움을 토로함 - 새로운 언어를 배우고 싶지만 문서를 매일 읽는 것이 어려움 - AI를 사용하여 코드를 생성하고 싶지 않음 * 소프트웨어 엔지니어에 대한 존경을 표함 - 데이터센터에서 자라며 소프트웨어가 해결되지 않는다는 것을 깨달음 - 시스템 관리자들은 모든 것이 처음부터 문제가 있다고 받아들임 * 완벽주의에 대한 비판을 제시함 - 팀원과의 협업에서 완벽주의가 비효율적임을 경험함 - "충분히 좋은" 해결책을 찾는 것이 중요함 * 개인적인 통찰을 공유함 - 모든 문제를 해결할 필요는 없으며, 완벽은 환상임 - 감정적 성숙과 자기 사랑의 중요성을 강조함 * 가족과 아이들이 완벽주의를 해결하는 데 도움이 됨을 언급함 * 소프트웨어를 직접 작성하는 것이 더 재미있고 간단한 해결책을 제공함 * 새로운 것에 집착하는 문화가 문제의 근원이라고 주장함 - 장기적으로 안정적이고 간단한 것을 구축하는 것이 중요함 * 심리학자들이 사람들을 최대화하는 사람과 충분히 좋은 것을 찾는 사람으로 분류함 - 최적화하는 사람들은 더 많은 것을 이루지만, 충분히 좋은 것을 찾는 사람들이 더 행복함 ### Comment 38286 - Author: beoks - Created: 2025-05-07T15:58:45+09:00 - Points: 5 "망가진 것을 그냥 두는 법"보단 "중요하지 않은 것을 내려놓는 법"이 더 적절한 문장인 것 같네요 반드시 고쳐야하는건 고쳐야죠 ### Comment 38340 - Author: ethanhur - Created: 2025-05-08T12:38:59+09:00 - Points: 1 - Parent comment: 38286 - Depth: 1 공감합니다. 자신이 정원을 더 예쁘게 가꾸는 건지, 아니면 중요한 작업을 하는 건지 잘 알고 내려놔야 한가고 생각합니다.