
안녕하세요! 여러분의 랜선 사수, codenlife의 CoLife입니다. 모니터 앞에 따뜻한 커피 한 잔 준비하셨나요?
며칠 전, 한바탕 폭풍 같았던 프로젝트 오픈을 무사히 마쳤습니다. 배포 버튼을 누를 때의 그 짜릿함과 해방감은 20년째 겪어도 늘 새롭고 좋네요. 하지만 진짜 개발의 묘미(라고 쓰고 고통이라 읽는)는 오픈 이후부터 시작된다는 거, 다들 아시죠?
오늘은 제가 수많은 기획자, 클라이언트, 현업 담당자들과 부대끼며 겪었던 **'우리를 울고 웃게 만드는 프로그램의 생애'**에 대해 이야기해 보려 합니다. 개발자라면 듣자마자 등골이 서늘해질, 마법의 주문 두 가지를 소개합니다.
1. 첫 번째 주문: "매일 볼 거니까 무조건 완벽하게!"
요구사항 정의 회의나 기획 리뷰 때 가장 많이 듣는 말입니다. 특히 통계나 대시보드 화면을 기획할 때 이런 요청이 폭주하죠.
"매출 추이를 일별, 주별, 월별로 다 볼 수 있어야 하고요." "조건 검색 다 들어가야 하고, 엑셀 다운로드는 시트 10개로 쪼개서 매크로까지 적용해 주세요. 우리 대표님이 매일 아침 보실 거거든요!"
이 말을 믿고 개발자는 며칠 밤을 새웁니다. 온갖 차트 라이브러리를 동원하고 복잡한 SQL 쿼리를 튜닝하여 완벽한 통계 프로그램을 만들어 내죠. 게다가 서버에 걸릴 부하를 생각해, 새벽마다 데이터를 미리 집계해 두는 배치(Batch) 프로그램까지 정성스럽게 돌려놓습니다.
현실의 배신
결과는 어떨까요? 오픈 첫날 테스트 삼아 딱 한 번 조회해 보고, 영원히 데이터베이스 한구석에서 잠드는 경우가 태반입니다. 나중에 서버 자원이 부족해서 시스템 로그를 뒤져보면 1년 내내 파리만 날리고 있죠. 정성껏 만든 새벽 집계 배치는 아무도 보지 않는 데이터를 위해 매일 밤 홀로 헛바퀴를 돌고 있었던 셈입니다.
2. 두 번째 주문: "아무도 안 쓰니까 그냥 지워주세요."
반대로 수년간 구석에 방치된 낡은 프로그램이 있습니다. 디자인도 촌스럽고 로직도 낡았죠. 현업 담당자도 당당하게 말합니다.
"아, 그거 저희 부서에서 이제 안 써요. 헷갈리니까 메뉴에서 아예 빼서 지워주세요."
홀가분한 마음으로 소스 코드를 깔끔하게 삭제하고 DB 테이블까지 날려버립니다. 앓던 이를 뺀 것처럼 배포를 마친 퇴근길 발걸음이 그렇게 가벼울 수가 없죠.
체스터튼의 울타리 (Chesterton's Fence)
놀랍게도 그걸 지운 바로 다음 날 아침, 전화기에 불이 납니다.
"어? CoLife님! 어제까지 잘 쓰던 월말 마감 버튼이 어디 갔죠?!"
알고 보니 1년 내내 접속률이 0%였던 이유는, 특정 부서에서 매년 12월 31일에 딱 한 번 결산을 위해 접속하는 필수 프로그램이었기 때문입니다. 혹은 전임자가 몰래 만들어둔, 사장님만 아는 비밀 단축키 같은 기능이었을 수도 있고요. 어제까지 어떻게 썼다는 건지 미스터리지만, 당장 복구해 내라고 아우성입니다. 등줄기에 식은땀이 줄줄 흐르죠.
💡 20년 차 CoLife의 실전 생존 노하우: '진짜' 방어적 프로그래밍
개발에서 '방어적 프로그래밍'이란 단순히 코드의 널 포인터 예외(Null Pointer Exception) 처리를 잘하는 것만을 의미하지 않습니다. 사람의 변심과 예측 불가능한 업무 환경에 대비하는 것이 찐 베테랑의 방어적 프로그래밍이죠.
- 의심스러운 코드는 절대 '하드 딜리트(Hard Delete)' 하지 마세요. 아무도 안 쓴다고 호언장담한 기능이라도 소스 코드를 바로 삭제하지 마세요. 일단 메뉴에서 **숨김 처리(Hide)**만 하거나, 특정 관리자 권한으로만 볼 수 있게 열어두는 것이 안전합니다.
- 사용자 몰래 로그(Log)를 심어두세요. 정말 사용률이 '0'인지 현업의 말만 100% 믿어서는 안 됩니다. 삭제하기 전 한 달 정도 해당 기능에 접근 로그를 남기는 코드를 심어두세요. 실제로 아무도 호출하지 않는다는 것을 데이터로 증명한 뒤에 도려내도 늦지 않습니다.
- '삭제'가 아닌 '보관'의 개념으로 접근하세요. 불가피하게 코드를 들어낼 때는 Git 같은 버전 관리 시스템을 믿는 것도 좋지만, 별도의 Legacy 폴더나 브랜치를 만들어 모아두는 것이 정신 건강에 좋습니다. 언제 다시 "그때 그거 다시 살려주세요"라고 할지 아무도 모르니까요.
마무리하며
수많은 요구사항에 치이고, 밤새 만든 기능이 버림받기도 하며, 시원하게 지운 코드 때문에 가슴 철렁이는 일들이 참 많습니다. 하지만 돌아보면 이런 좌충우돌 에피소드들이 겹겹이 쌓여 우리를 더 단단하고 노련한 개발자로 만들어주는 것 같습니다.
독자 여러분은 어떠신가요? 아무도 안 쓴다고 해서 시원하게 지웠다가 식은땀을 흘렸던 경험이나, 정말 영혼을 갈아 넣었는데 아무도 안 써서 슬펐던 기능이 있으신가요? 여러분의 눈물 없인 들을 수 없는 에피소드를 댓글로 남겨주세요! 같이 위로의 커피 한 잔 나누자고요. 😊
'Tech > Essay' 카테고리의 다른 글
| 게으른 개발자가 세상을 바꾼다 — 빌 게이츠 명언으로 보는 자동화 철학 (1) | 2026.04.13 |
|---|---|
| 기획이 2달 밀렸는데 오픈일은 그대로? 20년 차가 알려주는 벼랑 끝 프로젝트 생존법 (0) | 2026.04.07 |
| [개발자 에세이 Part 4] "분명히 바꿨는데 왜 그대로죠?" 20년 차를 울리는 캐시(Cache)의 배신 (0) | 2026.04.02 |
| [개발자 에세이 Part 3] "손도 안 댔는데 왜 고쳐졌지?" 20년 차를 소름 돋게 하는 유령 버그 (0) | 2026.04.01 |
| [개발자 에세이 Part 2] "내가 쓴 오타는 왜 내 눈에만 안 보일까?" 캠브리지가 증명한 20년 차의 착각 (0) | 2026.03.31 |