코드를 지우지 못하는 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-08-06

멘토링을 진행하며 2년 차 백엔드 개발자의 이력서와 프로젝트 레포지토리를 함께 둘러본 적이 있습니다. 컨트롤러 파일 하나에 주석 처리된 옛 코드가 100줄 넘게 남아있었고, 사용되지 않는 DTO 클래스가 5개나 방치되어 있었습니다. 이유를 물으니 돌아온 대답은 비슷했습니다. "혹시 나중에 다시 쓸지도 몰라서 남겨뒀습니다."

자신이 직접 작성한 코드를 지우지 못하는 주니어 개발자를 수없이 만납니다. 요구사항이 바뀌어 더 이상 호출되지 않는 메서드, 테스트용으로 만들어둔 임시 로직을 삭제하지 못하고 주석으로 덮어둡니다. 작성하느라 들인 시간과 노력이 아깝다는 생각이 지우개질을 방해하기 때문입니다.

지우지 않은 코드는 부채가 아니라 폭탄입니다

주석으로 덮어둔 코드 50줄은 당장 빌드에 영향을 주지 않습니다. 하지만 3개월 뒤 그 코드를 읽는 동료나 미래의 자신에게는 거대한 혼란을 줍니다. 이 로직이 정말 안 쓰는 로직인지, 특정 상황에서 살아나는 조건문인지 판단하기 위해 결국 다시 읽고 분석해야 합니다.

실제로 멘토링했던 3년 차 개발자는 주석 처리된 옛 로직 때문에 하루 반나절을 허비했습니다. 신규 이벤트 할인 적용 로직을 수정하던 중, 이전 담당자가 남겨놓은 주석 블록을 보고 "이 조건도 고려해야 하나?" 고민하다가 결국 사용하지 않는 로직임을 확인하고 허탈해했습니다. 지우지 않은 코드 한 줄이 팀 전체의 가독성과 개발 속도를 떨어뜨린 대표적 사례입니다.

Git이 있는데 왜 코드베이스에 남아있습니까

개발자가 커밋 버튼을 누르는 순간, 그 시점의 모든 상태는 버전 관리 시스템에 영구히 기록됩니다. 필요한 순간이 오면 git log 명령어로 언제든 지난주의 코드, 지난달의 로직을 되살려낼 수 있습니다.

그럼에도 코드베이스에 과거의 흔적을 찌꺼기처럼 놔두는 이유는 도구를 믿지 못하고 자신의 기억에만 의존하려 하기 때문입니다. 훌륭한 개발자는 코드베이스를 깔끔하게 유지합니다. Git 레포지토리를 백업 창고가 아니라 깨끗한 전시관처럼 다룹니다. 지워야 할 코드가 보일 때 망설임 없이 Delete 키를 누릅니다.

진짜 실력은 추가가 아니라 삭제에서 나옵니다

기능을 하나 더 붙여 2000줄짜리 서비스를 만드는 건 누구나 할 수 있습니다. 2000줄짜리 더러운 코드를 읽어내고, 구조를 정리하여 800줄로 줄여내는 것은 아무나 하지 못합니다.

지난달 멘토링에 참여한 한 팀은 레거시 API 12개를 리팩토링하면서 불필요한 엔티티 4개와 쓰이지 않는 메서드 23개를 완전히 삭제했습니다. 결과는 놀라웠습니다. 전체 코드 줄 수는 30% 줄어들었고, 신규 팀원이 온보딩되어 첫 PR을 올리기까지 걸린 기간은 기존 2주에서 4일로 단축되었습니다. 코드를 줄일수록 버그가 설 자리가 줄어듭니다.

오늘 당장 쓰지 않는 주석을 삭제하십시오

지금 본인이 작성 중인 코드베이스를 열어보십시오. "언젠가 쓰겠지"라며 주석으로 막아둔 로직이 있다면 주저 없이 지우십시오. 만약 정말 필요해진다면 Git이 당신을 구하러 올 것입니다.

새로운 기술 스택을 추가하는 것에 열을 올리기 전에, 본인이 남긴 찌꺼기를 스스로 정리하는 습관부터 기르십시오. 코드베이스가 가벼워질수록 개발자의 사고도 명확해집니다.