9-11) 최적화는 신중히 하라

빠른 프로그램보다 좋은 프로그램을 작성하라

 

최적화를 할 때는 다음 두 규칙을 따르라.
첫 번째, 하지마라.
두 번째, (전문가 한정) 아직 하지 마라. 다시 말해, 완전히 명백하고 최적화되지 않은 해법을 찾을 때까지는 하지 마라.
- M.A 잭슨 (Jackson75)

위의 격언은 최적화의 어두운 진실을 이야기해준다. 최적화는 섣불리 진행하면 오히려 안좋은 결과를 불러올 수 있다. 성능보다 중요한 것은 견고한 구조를 가진 좋은 프로그램을 작성하는 것이다. 프로그램의 구성요소들이 각각 독립된 책임을 가지고 동작해야 한다. 그러면 나머지 시스템에 영향을 주지 않고 각 요소를 다시 수정할 수 있을 것이다. 그렇다고 성능을 무시하라는 것은 아니다. 다만 지엽적인 구현상의 최적화에 신경쓰기 보다는 설계상의 성능에 더욱 신경써야 한다. 설계상에 성능 문제가 있다면 그것은 추후 바로잡기가 어렵기 때문이다. 예를 들어 외부 시스템과의 인터페이스가 필요 이상으로 많이 이루어진다면 이는 추후 성능개선을 어렵게 만든다. 그리고 공용 클래스를 만들때에도 불필요하게 가변 인스턴스를 반환하면 이를 사용하는 곳에서 매번 방어적 복사를 해야할 수 있다.

 

 

---

최적화 시도 전후로 성능을 측정하라

 

최적화를 하기로 결정했다면 최적화 결과 성능이 향상되었는지 확인해야 할 것이다. 이를 위해서는 해당 기능의 성능측정이 먼저 이루어져야 한다. 또 성능 측정이 자세하게 이루어진다면 어느부분을 최적화 해야할 지 명확히 알 수 있다. 예를들어 어떠한 API가 응답시간이 오래걸려서 최적화가 필요하다고 했을 때 무작정 Java 코드 최적화를 한다면 이는 의미가 없는 노력일수도 있다. 해당 API가 지연되는 이유가 DB 조회시간때문이라면 Java 코드 최적화가 아니라 DB를 최적화 해야한다.

 

최근 MSA 구조를 채택한 서비스들이 많아지면서 성능측정이 더욱 어려워지고 있다. 하나의 요청이 여러 서비스를 거쳐 동작하다보니 어느 서비스에서 성능개선이 필요한지 알기 위해선 흐름을 추적할수 있도록 로그를 쌓아야 하고 이를 바탕으로 성능을 측정해야 한다.