코드 삭제가 쉬워야 생존한다!

추상화는 중복을 피하기 위해 사용되지만, 가장 중요한 목적은 코드를 격리하거나 이름을 부여하여 다른 부분을 건드리지 않고 변경하거나 제거할 수 있도록 하는 것이다. 예를 들어, 로깅(Logging)을 생각해보자. console.log 호출을 여기저기 흩뿌리는 것은 작성하기는 쉽지만 변경하기는 어렵다. 반면, 모든 로깅을 단일 로거 모듈을 통해 라우팅하면, 로깅 라이브러리를 교체하거나, 컨텍스트를 추가하거나, 완전히 비활성화하는 경우 단일 파일만 수정하면 된다. 이처럼 추상화(Abstraction)는 복잡성 때문이 아니라, 변경 또는 삭제 가능성을 위해 사용되어야 한다.

소프트웨어는 끊임없이 변화하며, 기능은 추가되고 제거된다. 제품은 피벗하고, 요구 사항은 변경된다. 오늘 작성한 코드는 부분적으로 또는 완전히 대체될 것이다. 이는 실패가 아니라, 살아있는 소프트웨어가 작동하는 방식이다. 이러한 무상함(Impermanence)을 받아들이고, 그에 맞춰 설계해야 한다. 목표는 절대 제거할 수 없는 코드가 아니라, 제거 비용이 저렴한 코드를 작성하는 것이다. 30년 이상 운영되는 시스템을 구축한 엔지니어들은 코드를 건드릴 수 없게 만들어서가 아니라, 이해하기 쉽고, 격리하기 쉬우며, 필요할 때 조각별로 쉽게 교체할 수 있도록 설계했기 때문이다.

코드를 커밋하기 전에, 몇 가지 질문을 자문해 볼 필요가 있다. 첫째, 이 기능을 단일 PR로 삭제할 수 있는가? 그렇지 않다면, 그 이유는 무엇인가? 둘째, 이 코드는 몇 개의 파일을 수정하는가? 셋째, 이 모듈은 불필요한 것들을 알고 있는가? 넷째, 이 의존성이 사라진다면 얼마나 큰 문제가 발생할까? 다섯째, 이 추상화는 변경을 더 쉽게 만드는가, 아니면 중복을 피하는 것뿐인가? 이러한 질문들은 코드베이스를 더 건강하게 유지하는 데 기여하며, 삭제 비용에 대한 본능을 개발하는 데 도움이 된다. 결국, 가장 삭제하기 쉬운 코드는 작성하지 않은 코드이다.