Kat Busch가 작성한 원문을 토대로 쓴 글임을 밝혀둡니다.


컴퓨터 성능이 비약적으로 발전하면서, 알고리듬 성능 개선이란 단어의 인기는 사실 이전만 못합니다. 그래도 개발자라면 성능 개선은 피할 수 없는 것이죠. 특히 임베디드 시스템 개발자라면 더욱 그렇죠. 그런데 사실 우리는 성능 개선이 정말 필요하지 않은 상황임에도, 늘 강박강념처럼 성능 개선에 목을 메고 고민하고 있는건 아닐까요?

이러한 문제인식에서, 성능 개선에 대한 절대 원칙이라는 Kat Busch의 글을 보게되었고, 해당 글을 간추려 소개하고자 합니다.


성능 개선, 하지마라!

뭐라고? 그럼 왜 이 포스트를 쓰는거지? 자. 마음을 가라앉히시고… 필자가 이렇게 주장하는 이유를 아래에서 설명드리겠습니다. 그리고 정말 성능개선이 필요한 시점에 드릴 수 있는 저의 조언도 몇 가지 첨언하겠습니다.

Part 1. The Bottleneck

필자가 대학 시절, 여름 연구과제로 유전자 분석 프로그램을 개발하고 있었는데, 이 프로그램이 너무 느렸습니다. 필자의 지도 교수는 해당 프로그램에서 Graph Coloring 알고리즘이 시간을 많이 잡아먹는것 같다라고 말해주었죠. 그래서 필자는 그 말만 믿고 해당 부분에 대한 성능 개선을 시도했죠. 결론적으로 필자는 해당 부분에 대한 성능 개선에 성공했습니다! 기존 대비 70%의 개선이었죠! 몇 주간의 추가 개선후 전체 프로그램을 돌렸습니다.

그런데.. 이게 뭐죠? 전체 프로그램을 돌리니 실제 성능 개선은 15% 밖에 이루어지지 않았습니다.. 어떻게 된거죠? 분명 필자는 스스로 70% 성능 개선을 이뤘다고 자부했는데? 그는 무엇이 문제인지 살펴보았고 깨달았습니다. 아차!… 그가 작업중이던 프로그램은 수행 결과를 파일에 최종 기록하도록 프로그램 되어있었고, 수많은 파일들을 한꺼번에 기록하기 위해 수많은 프로세스를 생성하고 있었죠. 그래서, 하드 디스크는 각 파일을 기록하기 위해서 엄청난 수의 액세스 작업을 반복하고 있었습니다.

그는 근본적인 성능 저하의 문제점을 그제서야 깨닫고, Lock 구문을 사용해 한 프로세스에서만 파일 쓰기가 가능하도록 단 몇 줄의 코드로 기존 대비 전체 프로그램 성능이 60% 개선되는 효과를 얻었습니다. 단 몇 줄의 추가로…

이건 그가 Graph Coloring 알고리즘 개선에 들였던 몇 주의 성과로도 이루지 못했던 것이죠. 그의 지도 교수가 Graph Coloring을 C++로 작성해서 성능 개선해보라고 조언했던건, 교수 그 자신이 거기에 많은 시간을 투자했기 때문이라고 생각합니다. 정작 파일로 최종 결과를 산출하는 코드에 대해서는 교수는 크게 관심을 기울이거나 노력을 들이지 않았을 것으로 생각됩니다.

필자는 오랜 기간 동안 성능 개선과 연관된 업무를 하면서, 의외로 수많은 개발자들이 성능 개선에 엄청난 시간을 투자하면서도, 결론적으로 큰 소득을 얻지 못하는 광경들을 수없이 목격했다고 합니다. 그리고 성능 개선에 실패하는 경우의 공통점은 보통 정확히 어디가 Bottleneck인지 모르는 상태에서 작업을 시작하였기 때문이라는 것 입니다.

정확히 Bottleneck이 어딘지 모르는 상황에서, 성능개선 시도는 반드시 실패한다.

개발자들은 보통 자신이 건드리는 부분이 Bottleneck라고 생각합니다. 이는 숲은 못보고 나무를 보는 것과 같죠. 전체적인 그림이 아닌 아주 부분적인 단편을 보는 것일 수도 있습니다. 우습게도, 이러한 실수는 경험 많은 개발자들도 하는 실수입니다. 우리는 우리가 만든 세계에 갇혀, 바깥 세상에 대해서 잊어버리는 경우도 있습니다.

필자의 다른 경험담입니다. 한번은, 아주 숙련된 백엔드 전문가 개발 그룹에서, 복잡한 웹 엔드 포인트에 대한 성능 개선을 얻기 위해 기존 Python 언어로 작성된 것을 Go라는 언어로 재작성하기로 하였습니다. 그런데, 작업이 끝나고 보니, 정작 웹페이지 로딩이 느렸던 이유가 자신들이 담당하는 백엔드가 아닌, 앱의 브라우저 쪽 문제였던 것이죠. 한마디로, 그들은 헛다리를 짚은거죠.


위에서 소개해드렸던 필자의 경험담들.. 코딩에 입문한 초보자들이 하는 실수인것 같죠? 아닙니다. 자신의 시스템을 아주 잘 아는 사람도, 사실은 그 시스템을 벗어난 다른 연관 부분을 보지 못한 것이죠. 즉 나무만 보고 숲을 보지 못하는 실수는 전문가도 할 수 있다는 것이죠.

항상 스스로에게 질문하세요! 어떤 성능 요소가 최종 사용자에게 영향을 주는 부분인건지? 그리고 당신이 작성한 코드는 그 성능 요소에 어떤 영향을 미치는지?


Part 2. Complexity

정확히 Bottleneck이 어딘지 모르고 무조건 뛰어드는 성능개선은 해를 끼치는 행위입니다. 성능 개선 작업은 일반적으로 코드 복잡도를 증가시킵니다. 그래서 불 필요한 성능 개선 작업은 오히려 코드의 가독성을 낮추고 심지어 의도치 않은 버그들도 만들어내죠.