[ 아이템 67 ] 최적화는 신중히 하라

 섣불리 진행하는 최적화는 좋은 결과보다는 해로운 결과를 낸다. 빠르지도 않고 제대로 동작하지도 않으면서 수정하기는 어려운 소프트웨어를 탄생시키는 것이다.

 

 성능 때문에 견고한 구조를 희생하지 말자. 빠른 프로그램보다는 좋은 프로그램을 작성하라 좋은 프로그램이지만 원하는 성능이 나오지 않는다면 그 아키텍처 자체가 최적화할 수 있는 길을 안내한다. 좋은 프로그램은 정보 은닉 원칙을 따르므로 개별 구성요소의 내부를 독립적으로 설계할 수 있다. 따라서 시스템의 나머지에 영향을 주지 안혹도 각 요소를 다시 설계할 수 있다.

 

 ( 이는 성능 문제를 프로그램 완성까지 무시하라는 것이 아니다. 구현상의 문제는 나중에 최적화 할 수 있지만, 아키텍처의 결함이 성능을 제한하는 상황이라면 시스템 전체를 다시 작성하지 않고는 해결하기 불가능할 수 있다. 따라서 설계 단계에서 성능을 반드시 염두에 두어야 한다. )

 

 성능을 제한하는 설계를 피하라. 완성 후 변경하기가 가장 어려운 설계 요소는 바로 컴포넌트끼리, 혹은 외부 시스템과의 소통 방식이다. API, 네트워크 프로토콜, 영구 저장용 데이터 포맷 등이 대표적이다. 이런 설계 요소들은 완성 후에는 변경하기 어렵거나 불가능할 수 있으며, 시스템 성능을 심각하게 제한할 수 있다.

 

 API를 설계할 때 성능에 주는 영향을 고려하라. public 타입으로 인해 내부 데이터가 변경되면 불필요한 방어적 복사를 유발하고(아이템 50), 상속 방식으로 설계한 public 클래스는 상위 클래스에 종속되며 성능 제약까지 받는다.(아이템 18) 또한 인터페이스를 사용하지 않고 구현 타입을 사용하면, 특정 구현체에 종속되어 더 빠른 구현체를 사용하지 못한다.(아이템 64)

 

 성능을 위해서 API를 왜곡하는 건 매우 안좋은 생각이다. API를 왜곡하도록 만든 성능은 다음 버전에서 사라질 수도 있지만, 왜곡된 API를 지원하는데 따른 고통은 영원히 계속 될 것이다.

 

 잭슨이 소개한 "하지마라" , "(전문가 한정) 아직 하지 마라"라는 최적화 규칙에 더하여 "각각의 최적화 시도 전후로 성능을 측정하라"에 주목해야 한다. 프로파일링 도구(profiling tool)을 사용하면 최적화 노력을 어디에 해야 하는지 집중할 수 있다. 개별 메서드의 소비 시간과 호출 횟수 같은 런타임 정보를 제공하여, 집중할 곳과 알고리즘을 변경해야 한다는 사실을 알려주기도 한다. 자바는 기본 연산에 드는 상대적인 비용을 덜 명확하게 정의하고 있다. 자바의 성능 모델은 정교하지 않을뿐더러 구현 시스템, 릴리스, 프로세서마다 차이가 있다. 각자의 환경에 맞게 최적화의 효과를 각각 측정해주어야 한다.

 

*느낀점

최적화는 신중히 진행되어야 하며 성능보다는 좋은 설계의 필요성을 강조한다. 성능을 개선하는 것은 쉽지만 설계를 바꾸는 것은 쉽지 않다. 그렇다고 성능이 항상 후순위라는 것도 아니다. 즉, 기본적으로 어느정도의 성능을 보장하면서 설계를 하고, 이후 프로파일링을 통해 구체적으로 성능을 개선하라는 의미이다. 최적화를 명목으로 무작정 코드를 변경하는 것이 얼마나 잘못된 것인지, 침착해야 하는 것인지 깨달았다.