실무 경험이 많지 않은 개발자들이 자주 저지르는 실수 중 한 가지는, 개발 초기 단계에서 퍼포먼스 튜닝을 시도한다는 것이다.
퍼포먼스 튜닝은, 해당 모듈에 대한 로직이 명확해지고, 더는 로직의 변경이 없을 것임을 확신할 수 있을 때, 또한 실제로 문제가 발생하였을 때 진행하는 것이 좋다.
그 이유는, 한 번 퍼포먼스 튜닝을 거치게 되면, 그 코드에 대한 관리 비용이 급격히 상승하기 때문이며, 로직과 코드의 변경이 빈번한 개발 단계에서 이를 시행하게 되면, 이후 해당 부분에 변경 사항이 있을 때마다, 더 많은 시간 비용을 투자해야 하기 때문이다.
또한, 시스템이 완성되기 전까지는, 어디에서 가장 높은 오버헤드가 발생할지 아무도 알 수 없다. 물론, 어느 정도 예측은 할 수 있지만, 그렇다고 해서 무조건 퍼포먼스 튜닝을 미리 감행할 필요는 없다. 미리 퍼포먼스 튜닝을 한다고 해서 특별히 나아질 것이 없기 때문이다.
특히 초보 개발자들은, 어디에서 튜닝이 필요한지 알지 못한 채, 무조건 자신이 튜닝할 수 있는 부분을 먼저 튜닝하려는 경향이 있다. 이렇게 만들어진 코드는, 개발 비용과 관리 비용만 비약적으로 증가시킨 채, 결과적으로 시스템 성능에는 이렇다 할 향상을 가져오지 못하게 된다.
가볍게 읽고 넘길 수도 있는 글이지만, 이 문제가 전체적인 소프트웨어 개발 및 유지 비용에 미치는 영향은 상당하다.
11/30/2009에 덧붙임
이 글은, 실제 문제가 발생하기 전까지는 퍼포먼스 튜닝을 미루는 것이 바람직하다는 취지의 글입니다. (며칠 전 IRC에서, 김학영님이 이와 같이 정리를 요청하셨는데, 한동안 잊고 있다가 맹기완님의 답글을 보고 생각이 나서 추가합니다.)
또한, 이 글에서 퍼포먼스 튜닝이란, 높은 수준의 퍼포먼스 튜닝도 물론 포함하지만, 사소한 정도의 코드 변형도 포함합니다.
'Software Engineering' 카테고리의 다른 글
| 출제자의 의도 파악 문제 (2) | 2008/05/30 |
|---|---|
| 깨끗한 코드 (2) | 2008/03/10 |
| 소프트웨어의 수명 정하기 (0) | 2008/02/22 |
| 성급한 퍼포먼스 튜닝 (6) | 2007/05/06 |
| 코드의 레이어링 (0) | 2007/03/11 |
| 테스트 케이스 (0) | 2007/03/07 |
댓글을 달아 주세요
"리팩토링은 개발후에 하라고!" 라고 야단맞으며 뒤통수를 맞아봐야~
아~~~~~~~~~~~
무식하면 손발이 고생이구나~ 할꺼야?~
ㅋㅋㅋ 허경환
재영 2009/11/26 10:22 댓글주소 수정/삭제 댓글쓰기
간단히 코딩 습관만으로도 많은 효과를 기대할 수 있지...
음.. 형은 일단 코딩 컨벤션부터 좀.. -_-;
Flash Builder 4에서 override 할때마다 생각남..
튜닝이 필요한 서비스를 수주하는 행운을 가진 사람이 많지 않죠 ^^
실제 필요한만큼 과부하를 걸어야하는 무언가를 공사로 받지 못하는 자들에겐 공허 실험과 예상들뿐이라 많은 이들과 공감하시기 어려운 주제입니다.
개인적으로 너무나 당연하게도 퍼포먼스 튜닝이 좋은 결과로 이루어질 가능성은 매우 희박합니다. 완전히 확정된 알고리즘에 대해서만 튜닝을 적용하는 의미가 있는데 프로그램의 세계에서 확정이란게 거의 없어서 ^^
게다가 OOP에선 OOP답게, DB는 정규화가 C는 잘정의된 헤더가 성능을 높이고 분산할 수 있는 환경으로 머신을 늘려가는게 정답인게 대부분이니 더욱더 그 의미는 줄어들고 있는 추세라 생각됩니다.
단지 습관이 좋은건 좋은거죠 ^^
루프대신 링크드리스로 돌린다던가 GC에 기대는 대신 풀링을 쓴다던가 하는 습관아닌 습관같은것들은 여러가지를 보완해줄듯.
음.. 문제가 일어나기도 전에 성능에 집착할 필요가 없다는 취지의 글입니다.. :')
안 그래도 며칠 전에 검쉰이, 이 글 내용의 요점을 추가하는 것이 좋겠다고 언급한 적이 있었는데, 그러마 하고는 잊고 있었네요 ㅎㅎ