개발자의 저주: 고치는 능력을 가진 자의 무한한 책임감
(notashelf.dev)- 사소한 자동화를 반복하다 보면 어느 순간 모든 도구와 시스템이 고쳐야 할 대상으로 보이게 되는 인지의 임계점에 도달하게 됨
- 기술력이 쌓일수록 문제를 단순히 인식하는 것을 넘어 책임처럼 느끼게 되는 감정의 무게를 가지게 됨
- 고치고자 하는 욕구는 단순한 생산성 향상을 넘어서 감정 조절의 수단이 되기도 하며, 때론 자신이 만든 시스템에 스스로 갇히는 결과를 낳음
- 시스템은 시간이 지나며 반드시 망가지고, 완전한 해결이라는 환상은 존재하지 않음
- 결국 진짜 필요한 기술은 모든 것을 고치는 능력이 아니라, 무언가를 고치지 않고도 견딜 수 있는 마음의 여유임
시작은 사소한 자동화
- 파일 이름을 바꾸는 파이썬 스크립트나
git명령어 단축 등 작은 생산성 향상 작업에서 시작됨 - 시스템의 불편을 직접 고치고 나면, 세상의 모든 것들이 개선 대상처럼 보이기 시작함
- 어느 순간부터는 “할 수 있다”를 넘어 “해야 한다”는 도덕적 강박감으로 전환됨
기술력의 무게감
- 프로그래밍 이전에는 불편한 소프트웨어를 그냥 넘길 수 있었지만, 이제는 문제점이 선명히 보임
- 개발자가 만든 허술한 코드나 하드코딩된 설정들이 비난처럼 느껴짐
- 모든 시스템과 소프트웨어가 고쳐야 할 TODO 리스트로 보이는 인식 전환이 일어남
계속되는 리팩터의 삶
- 매번 “이건 내가 더 잘 만들 수 있어”라는 생각으로 자기만의 도구 개발에 빠져듦
- 정리되지 않은 코드 디렉토리, 무수한 시도와 포기, 끝없는 구조 재설계는 자기 구속적 노동이 되기도 함
- Kafka의 “새장을 짓고 새를 기다리는 것”이라는 비유처럼, 목적 없는 도구 제작에 빠져들 수 있음
소프트웨어는 썩는다
- 완벽해 보이던 스크립트도 언젠가 외부 변화로 인해 무용지물이 됨
- 웹사이트 레이아웃 변경, 패키지 버전 변경, 의존성 오류 등
- 문제 발생 시 단순 불편이 아닌 죄책감을 느끼게 됨
- 결국 지속적인 관리가 필요하다는 현실과 마주하게 됨
자동화라는 환상
- “한 번만 세팅하면 다시 안 건드려도 된다”는 거짓된 희망을 자주 품게 됨
- 프로그래밍을 문제 해결의 승리로 생각하지만, 끝나지 않는 전쟁일 뿐임
- 완성이라는 개념은 없고, 언제나 침수되는 참호를 파고 있을 뿐임
감정 조절의 수단이 된 코딩
- 도구를 만드는 행위는 때론 삶의 혼란을 통제하려는 심리적 반응임
- 시스템이 복잡할수록 오히려 자신이 정돈된 느낌을 받음
- 복잡한 삶을 피하기 위해 새로운 앱이나 리팩터링을 시도하며 자기 위안을 얻음
예고 없는 번아웃
- 번아웃은 단순한 과로보다 과도한 책임감에서 비롯됨
- “내가 고칠 수 있는 걸 왜 안 고치지?”라는 자기 비난이 스트레스를 가중시킴
- 끝없는 기술적 책임감은 자기파괴적인 부담으로 작용함
내려놓는 기술 배우기
- 모든 문제를 해결할 필요는 없음
- 때론 고치지 않아도 된다는 사실을 아는 것이 더 큰 통제력임
- 결함을 인정하고, 그냥 쓰는 것도 의식적인 선택이 될 수 있음
진짜 기술은 감정의 명료함
- 고칠 수 있는 기술보다 고치지 않아도 되는 마음의 기술이 더 중요함
- 언제 멈춰야 하는지, 어떤 프로젝트는 자기 위안용인지 구별하는 능력
- 모든 것을 고치려는 강박에서 벗어나, 불완전함 속에서도 편안함을 찾는 태도가 필요함
결국 프로그래밍에서 가장 어려운 기술은,
"망가진 것을 그냥 두는 법" 을 배우는 일임
세상에는 은행들과 결제사들 개판난 API 들을 묶어 정리해주는 일 만으로도 수천억대 가치를 지니는 기업도 있다는 걸 깨달으면 편합니다 ㅋㅋ
이짓을 오래하기 위해선 과도한 책임감으로 보상심리의 굴레로 빠지기 전에
때때로 책임과 감정의 무게를 덜어놓는 연습도 필요한 것 같습니다.
저도 잘 조절이 안되는 부분이기도한데 ㅋㅋ... 좋은 내용이네요
요거 좋은 포인트인 것 같습니다. 책임감은 말 그대로 책임을 느끼는 것이기 때문에 그 자체로는 댓가를 요구하지 않는 법이죠. 하지만 시간이 지나면, 몸과 마음은 지치는 반면 책임감은 쉽게 사라지지 않고, 그 간극을 메꾸기 위해 (그렇게 연결지으면 안되는 것인데도) 댓가를 바라기 시작하는 것 같습니다. 본인도 모르게요.
VB 6.0과 COM + OLE + 액티브X 으로 만들어진 시스템이 여전히 잘만 돌아가는걸 보고 기겁해서 다시 짜고 싶은 욕망이 든다면 당신은 고통받을 사람입니다
결국 프로그래밍에서 가장 어려운 기술은,
"망가진 것을 그냥 두는 법" 을 배우는 일임
공감합니다. 일을 벌이는 타입이라 항상 고생합니다...
개발자에게 과실여부를 따지며 "네가 코딩 잘못했네" 가 쌓이면
개발자는 책임감에 눌려서 새로운 시도를 기피하게 되고
결국은 발전없는 안전한 코드만 작성하게 되죠.
QA가 Assure 해야한다는게 그 뜻입니다.
발전적인 코딩을 하려면 어느정도 리스크는 지게 마련이고
그걸 검증하고 책임져주는게 QA가 되야하는거죠.
roxie 님 말씀대로 본문에 대한 얘기는 야크 쉐이빙에 대한 얘기가 맞는데,
제 개인적인 경험에 비추다보니 본문의 내용과 약간 딴판인 이야기가 되었네요.
NIH(not invented here) 현상으로도 설명할 수 있지 않을까요? 유지보수는 곧 고정비용이라는 것과 비용에 사람의 노력도 포함된다는 걸 잊지 말아야 한다고 생각합니다
Hacker News 의견
-
연극을 할 때 배운 인용구가 있음. 예술의 과정을 어려운 것을 습관으로 만들고, 습관적인 것을 쉽게 만들고, 쉬운 것을 아름답게 만드는 것이라고 설명함
- 배우로서 대사를 암기하고, 캐릭터의 동기를 이해하며, 관객이 감정과 의미를 공유하도록 공연을 조율함
- 소프트웨어에서는 컴퓨터가 원하는 대로 작동하도록 하는 마법의 주문을 배우고, 그 주문이 왜 작동하는지 이해하며, 문제를 더 아름답게 해결하는 방법을 찾음
-
UI 문제에 대한 개인적인 의견을 제시함
- 인터페이스는 (재)렌더링이 완료된 후 몇 밀리초 동안 상호작용할 수 없어야 함
- 알림을 실수로 잘못 누르면 알림을 잃어버리는 경우가 발생함
-
개인 프로젝트에 대한 어려움을 토로함
- 새로운 언어를 배우고 싶지만 문서를 매일 읽는 것이 어려움
- AI를 사용하여 코드를 생성하고 싶지 않음
-
소프트웨어 엔지니어에 대한 존경을 표함
- 데이터센터에서 자라며 소프트웨어가 해결되지 않는다는 것을 깨달음
- 시스템 관리자들은 모든 것이 처음부터 문제가 있다고 받아들임
-
완벽주의에 대한 비판을 제시함
- 팀원과의 협업에서 완벽주의가 비효율적임을 경험함
- "충분히 좋은" 해결책을 찾는 것이 중요함
-
개인적인 통찰을 공유함
- 모든 문제를 해결할 필요는 없으며, 완벽은 환상임
- 감정적 성숙과 자기 사랑의 중요성을 강조함
-
가족과 아이들이 완벽주의를 해결하는 데 도움이 됨을 언급함
-
소프트웨어를 직접 작성하는 것이 더 재미있고 간단한 해결책을 제공함
-
새로운 것에 집착하는 문화가 문제의 근원이라고 주장함
- 장기적으로 안정적이고 간단한 것을 구축하는 것이 중요함
-
심리학자들이 사람들을 최대화하는 사람과 충분히 좋은 것을 찾는 사람으로 분류함
- 최적화하는 사람들은 더 많은 것을 이루지만, 충분히 좋은 것을 찾는 사람들이 더 행복함