나는 코더 또는 프로그래머보다는 소프트웨어 엔지니어라는 용어를 더 선호한다. 앞의 두 용어는 어쩐지 격이 낮아보이기 때문이다. 소프트웨어 엔지니어를 얕잡아보는 일부 사람들이 엔지니어를 가리켜 코더나 프로그래머라고 하는 경우가 종종 있다.
처음부터 이야기가 빗나갔는데 이쯤에서 바로 잡자. 어떤 소프트웨어를 설계하고 코딩하는 일련의 과정에서 소프트웨어 엔지니어는 여러가지 고민을 지속적으로 하게 된다. 가끔은 두통을 유발하기도 하는 이런 고민거리 중에는 성능과 간단한 설계 사이의 균형 문제도 있다. 많은 경우에 최적의 성능과 간단한 설계라는 목표가 어긋나기 마련이다. 나는 이런 상황을 대처하기 위한 한가지 원칙을 갖고 있다.
나는 성능 문제에 집착하지 않으려고 노력한다. 그보다는 빠른 출시와 쉬운 유지보수를 최우선 과제로 생각한다. 많은 경우에 이런 접근방법이 유용한데, 그 이유로 크게 두가지를 생각해 볼 수 있다. 우선 설계단계에서 모든 성능문제를 고려하기는 힘들다는 점이다. 폭포수 모델이든, 나선형 모델이든 요구사항분석, 설계, 개발식으로 작업단계를 나누어 놓는다. 최근의 개발모델에서는 개발 단계로 넘어가더라도, 그 이전 단계의 작업도 계속된다. 사실상 모든 문제를 초기에 예상할 수 있다는 믿음은 깨진지 오래다. 우리는 생명주기의 뒷단계로 나아감에 따라 문제를 보다 잘 이해하게 된다. 그러므로 초기에 성능문제를 100% 해결하려고 달려드는 것은 별 도움이 되지 않는다.
실제로 있었던 이야기를 해보자. 서버/클라이언트 환경인 사내 시스템 일부가 있었다. 시스템을 간단히 설명하자면, 클라이언트가 서버에게 메시지를 보내면 서버가 메시지를 데이터베이스에 저장하는 시스템이었다. 기존 서버는 클라이언트가 접속할 때마다 쓰레드를 생성하는 간단한 동기소켓/멀티쓰레드 구조였다. 어느날 한 엔지니어가 이 서버를 비동기소켓 구조로 만든다면, 성능이 훨씬 나아질 것이라고 주장했다. 그러나 꽤 많은 자원을 투자해서 새로운 서버를 제작했음에도 기대했던만큼 성능이 나아지지 않았다. 왜냐하면 실제로 병목현상이 발생하는 곳은 클라이언트와 서버 간의 네트워크가 아니었기 때문이다. 오히려 데이터베이스에 메시지를 넣는 작업이 더딘 것이 문제였다.
문제를 단순화시켰기 때문에 앞의 이야기에 등장하는 엔지니어가 바보처럼 느껴질 것이다. 하지만 실제 상황은 이보다 복잡하고, 머리 속에서 돌아가는 갖가지 시뮬레이션은 틀리기 쉽다. 더욱이 요구사항조차 완벽하지는 않을 것이다.
전체 어플리케이션 중 극히 일부에서 병목현상이 발생한다는 점도 단순한 설계에 힘을 실어준다. 프로필러를 사용하거나 간단한 성능측정객체(후에 내가 자주 사용하는 성능로그객체를 소개할 생각이다.)를 만들어서 어플리케이션의 구간별 실행 시간을 측정해보자. 대부분의 경우, 20%의 구간에서 80%의 실행시간을 차지한다. 20%, 80%는 편의상 제시한 수치일 뿐, 실제 상황에서는 이보다 더한 경우가 많다. 그러므로 처음부터 모든 성능문제를 고려하느라 진을 뺄 필요가 없다. 우선 간단한 설계를 채택한 후에 성능 테스트에서 발견된 상위 20%의 문제를 집중적으로 해결하는 편이 낫다.
불과 2주일 전에도 이를 뒷받침해 주는 사건이 일어났다. 성능 테스트가 가능한 지점까지 개발이 진척되었다. 가상 데이터로 몇차례 테스트를 해보니, 단 하나의 함수가 전체 실행시간의 90%를 차지하고 있었다. 이제 해당 함수를 Inspection 해 보았다. 문제는 실로 간단했는데, 상당한 크기의 문자열을 조합하는데 StringBuilder를 사용하지 않고, + 연산자를 반복적으로 호출했기 때문이었다. 3, 4줄 정도의 코드만 슬쩍 수정하고 나니, 전체 성능이 수십배 향상되었고, 그것으로 충분했다.
이런 접근 방법이 모든 경우에 통용된다고 말할 수는 없다. 예를 들어 하루에 2억건 정도의 트랜잭션이 발생하는 결제요청처리 서버를 개발해야 한다면, 설계단계부터 상당한 수준의 검토가 필요할 것이다.
[2005년 12월 8일] 글 중간에서 약속한 간단한 성능측정 객체를 소개했다.
