코드의 라이프 사이클을 고려한 설계 경험에 대해 이야기해 주실 수 있나요?

처음 개인 프로젝트를 만들 때는 기능 구현에만 집중했습니다. 그 결과 6개월 후 버그 수정을 위해 코드를 열었을 때 어디서부터 손을 대야 할지 알 수 없는 상태가 됐습니다. 이 경험이 코드의 라이프사이클을 진지하게 고민하게 된 계기였습니다.

이후 팀 프로젝트에서는 설계 단계부터 가독성과 테스트 가능성을 먼저 고려하기 시작했습니다. 함수는 단일 책임만 갖도록 분리하고, 외부 의존성은 인터페이스로 감싸서 테스트 시 교체할 수 있게 했습니다. 덕분에 PR 리뷰에서 로직 흐름을 이해하는 시간이 눈에 띄게 줄었습니다.

또 신경 쓴 부분은 변경에 강한 구조였습니다. 기능이 추가될 때마다 기존 코드를 대폭 수정해야 하는 상황이 반복됐는데, 핵심 로직과 I/O를 분리하는 방식을 적용한 이후에는 새 기능 추가 시 기존 파일을 거의 건드리지 않게 됐습니다.

유지보수 관점에서는 코드보다 이유를 남기는 주석 원칙을 팀 내에 제안했습니다. 무엇을 하는지는 코드가 보여주지만, 왜 이렇게 했는지는 코드만으로 알 수 없는 경우가 많았습니다. 이 원칙을 적용한 뒤 온보딩한 팀원의 질문 수가 크게 줄었습니다.