리팩터링과 성능

- 리팩터링 2판 중

 

 

리팩터링하면 프로그램 성능이 느려질까봐 걱정하는 사람이 많다.

나는 실제로 소프트웨어를 이해하기 쉽게 만들기 위해서 속도가 느려지는 방향으로 수정하는 경우가 많다.

 

직관적인 설계 vs 성능 은 중요한 주제이다.

내가 성능을 무시하는 이유는 설계의 순수성을 우선시하거나 조만간 더 빠른 하드웨어가 나오리라 믿기 때문이 아니다.

예전에도 너무 느린 소프트웨어는 고객이 수용해주지 않았고 빠른 하드웨어가 등장하더라도 성능 기준이 낮아지는 경우는 드물었다.

 

리팩터링하면 소프트웨어가 느려질 수도 있는 건 사실이다.

하지만 그와 동시에 성능을 튜닝하기는 더 쉬워진다.

하드 리얼타임 시스템을 제외한 소프트웨어를 빠르게 만드는 비결은, 먼저 튜닝하기 쉽게 만들고 나서 원하는 속도가 나게끔 튜닝하는 것이다.

 

나는 빠른 소프트웨어를 작성하는 방법 3가지를 경험했다.

그중 가장 엄격한 방법은 시간 예산 분배 방식으로, 하드 리얼타임 시스템에서 많이 사용한다.

 이 방식에 따르면 설계를 여러 컴포넌트로 나눠서 컴포넌트마다 지원 예산을 할당한다.

 

컴포넌트는 할당된 자원 예산을 초과할 수 없다.

단, 주어진 자원을 서로 주고받는 매커니즘을 제공할 수는 있다.

 

시간 예산 분배 방식은 특히 엄격한 시간 엄수를 강조한다.

심장 박동 조율기 처럼 데이터가 늦게 도착하면 안되는 시스템에서는 이러한 점이 굉장히 중요하다.

반면, 사내 정보 시스템과 같은 부류에는 맞지 않는 기법이다.

 

두번째 방법은 끊임없이 관심을 기울이는 것이다.

프로그래머라면 누구나 높은 성능을 유지하기 위해서 무슨 일이든 한다.

직관적이어서 흔히 사용하는 방식이지만 실제 효과는 변변치 않다.

 

성능을 개선하기 위해 코드를 수정하다보면 프로그램은 다루기 어려운 형태로 변하기 쉽고, 결국 개발이 더뎌진다.

결과적으로 소프트웨어가 더 빨라지면 충분한 보상을 얻겠지만 실제로 그런 경우는 별로 없다.

 

이 방식에서는 성능을 개선하기 위한 최적화가 프로그램 전반에 퍼지게 되는데, 각각의 개선은 프로그램 특정 동작에서만 관련될 뿐,

정작 컴파일러와 런타임과 하드웨어의 동작을 제대로 이해하지 못한 채 작성할 때도 많다.

 

성능에 대한 흥미로운 사실은, 대부분 프로그램은 전체 코드 중 극히 일부에서 대부분의 시간을 소비한다는 것이다.

그래서 코드 전체를 고르게 최적화 한다면 그중 90%는 효과가 거의 없기 때문에 시간 낭비인 셈이다. 

즉, 속도를 높이기 위해 투자한 시간을 모두 날리는 행위다.

 

성능 개선을 위한 3번째 방법은 이 90%의 시간은 낭비라는 통계에서 착안한 것이다. 즉 의도적으로 성능 최적화에 돌입하기 전가지는 성능에 신경쓰지 않고 코드를 다루기 쉽게 만드는데 집중한다.

 

그러다 성능 최적화 단계가 되면 다음의 구체적인 절차를 따라 프로그램을 튜닝한다.

 

먼저 프로파일러로 프로그램을 분석하여 시간과 공간을 많이 잡아먹는 지점을 알아낸다.

그러면 성능에 큰 영향을 주는 작은 부분을을 찾을 수 있다.

그런 다음 전체를 고르게 최적화할 때와 마찬가지 방법으로 그 부분들을 개선한다.

 

이렇게 하면 성능에 큰 영향을 주는 부분만 집중해서 최적화하기 때문에 적은 노력으로 훨씬 큰 효과를 볼 수 있다.

이때도 물론 신중하게 작업해야 한다.

 

리팩터링할 때처럼 최적화를 위한 수정도 작은 단계로 나눠서 진행한다. 각 단계마다 컴파일과 테스트를 거치고 프로파일러를 다시 실행해본다.

성능이 개선되지 않았다면, 수정내용을 되돌린다. 

이런 식으로 사용자가 만족하는 성능에 도달할 때까지 최적화 대상을 찾아서 제거하는 일을 계속한다.

 

프로그램을 잘 리팩터링해두면 이런 식의 최적화에 2가지 면에서 도움이 된다.

1. 성능 튜닝에 투입할 시간을 벌 수 있다. 
리팩터링이 잘되어있다면 기능 추가가 빨리 끝나서 성능에 집중할 시간을 더 벌 수 있다.

 (또한 프로파일링을 하면 이렇게 확보한 시간을 낭비없이 쓸 수 있다.)

 

2. 리팩터링이 잘 되어 있는 프로그램은 성능을 더 세밀하게 분석할 수 있다.

프로파일러가 지적해주는 코드의 범위가 더 좁아질 것이고, 그래서 튜닝하기 쉬워진다.

코드가 깔끔하면 개선안들이 더 잘 떠오를 것이고, 그 중 어떤 튜닝이 더 효과가 좋을지 파악하기 쉽다.

 

즉, 리팩터링은 성능 좋은 소프트웨어를 만드는 데 기여한다. 단기적으로 보면 리팩터링 단계에서는 성능이 느려질 수도 있다.

그렇지만, 최적화 단계에서 코드를 튜닝하기 훨씬 쉬워지기 때문에 결국 더 빠른 소프트웨어를 얻게된다.