Page 11 -

아주 작은 기능은 추가해도 나중에 리팩토링하기가 어렵지 않다. 아키텍
처가 감당할 수 없는 거대한 기능을 넣었다가 나중에 없애는 건 끔찍하게

어려운 일이다. 크기가 중요하다.

올바른 방법 도입하기

최악의 상황은 팀원들이 몇 달 혹은 몇 년 동안 아무 설계도 없이 기능을
추가하도록 내버려두다가 어느 날 문득 뭔가 잘못되었다는 걸 깨닫는 경우

다. 이런 상황이 닥치면 코드베이스 전체 뜯어고치기라는 끔찍하게 어려운
작업을 감당해야 한다. 새로운 기능을 추가할 때와 마찬가지로, 아예 새로

작성하지 않는 이상 뚝딱 할 수 있는 일이 아니다.
이제라도 올바르게 일하고 싶은가? 그러려면 올바른 방법을 도입하는 수

밖에 없다. 그 말인즉 간단한 절차를 차례로 밟아가며 설계를 조금씩 고쳐

야 한다는 뜻이다. 그렇게 하려면 보통 몇 개월에서 몇 년을 수고해야 한
다. 아주 허튼 수고다. 프로젝트 초반에 설계했으면 될 일이니 말이다. 애

초에 미래를 생각했어야 한다.

엄격한 설계 없이 시작한 프로젝트가 계속 성장하면 결국 개발자의 능력을
벗어날 정도로 복잡해진다.

처음부터 모든 걸 포괄하는 거대한 설계를 완성해야 한다는 뜻은 아니다.
장래에 필요한 모든 것을 예측하고 적용해야 한다는 의미도 아니다. 프로젝

트를 시작할 초기 단계부터 이 책과 『Code Simplicity』에서 논의한 소프트
웨어 설계 원칙을 적용해야 한다는 뜻이다. 그래서 이해할 수 있고 유지 보

수도 가능한, 단순한 시스템을 만들어야 한다는 뜻이다.

9장 설계는 프로젝트 초반에 하라 041

심플소프트웨어_06.indd 41 2019-10-18 오전 10:33:59