한빛출판네트워크

저자: 한빛 웹로거 김대곤

필자는 지난주, Middleware Company가 발표한 보고서를 보게 되었다. 그리고 필자의 눈을 의심하였다. 그들이 왜 그런 보고서를 작성했는지 이해할 수 없었기 때문이다. 더욱이 Middleware Company는 필자가 근무하는 회사이다. 나도 당신처럼 감이 잡히지 않는다.

그 보고서에 대한 무수한 반응이 있었으며, 수많은 사람들이 TMC(The Middleware Company)와 TSS(TheServerSide.Com)에 대해 반격의 기회를 노리면서, 그 보고서를 비난하고 있다. 필자는 보고서, 보고서에 대한 사람들의 반응, 다른 주장들을 살펴보면서, 이 보고서가 주는 혼란의 주요한 원인을 찾았다.

- 투명하지 않은 발표
- 불공정성

투명하지 않은 발표

보고서에는 누가 보고서를 작성했는지, 테스트에 참석한 사람은 누구인지, 왜 특정한 "규칙"들이 적용되었는지, 테스트를 위한 재정 지원은 누가 했는지에 대한 정보가 누락되어 있다. 투명한 정보를 가지지 않고서는 정확한 그림을 그릴 수 없다. 우리는 이러한 정보들을 TMC로부터 얻어내려고 노력하고 있다. 그러나 그것은 처음부터 제공되어야 할 자료였으며, 그들은 마땅히 발표했어야 했다.

불공정성

벤치마크 테스트는 제 논에 물 대기와 같다. 가장 잘 디자인 된 벤치마크 테스트도 특정 제약 조건 내에서 성능 비교의 역할을 수행한다. 너무 많은 변수들이 없는 달리기 경주에서 이러한 작업은 상당히 좋은 편이다. 그러나 엔터프라이즈 컴퓨팅 환경에서 벤치마크 테스트는 거의 아무런 의미가 없다. 자기 제품의 성능이 가장 좋게 나오도록, 특정 규칙을 설정하는 것은 매우 쉬운 일이며, 이러한 방식은 항상 사용되어져 왔기 때문이다. 필자는 이번에도 마찬가지라고 생각한다.

필자가 보기에는 그 보고서/테스트의 목적이 무엇인지 분명하지 않다. 성능에 대한 것인지 개발생산성(Line of Code)인지. 하여튼 알 수가 없다.

성능

만약 테스트가 성능에 관한 것이었다면, 각 애플리케이션 서버 벤더들이 참여하여 코드, Deployment descriptor, 하드웨어, 및 필요한 모든 사항을 점검하고, 이번 테스트에서 최고의 성능을 발휘할 수 있도록 수정할 수 있도록 했어야 했다. 마이크로소프트는 이러한 작업이 허락된 유일한 회사였다. 이것은 공정하지 못한 경기이다. 또한 J2EE PetStore의 구 버전이 사용되었으며, 성능 개선을 위해 필요한 특정한 작업은 수행되지 않았다.

• EJB 2.0 Local Interfaces
• EJB 2.0 CMP
• EJB를 사용하지 않는 것
• JDO(Java Data Object)
• 다른 자바 가상 머신(JVM) , 예: 1.4 JRockIt

이러한 작업들이 수행되었다면, 보다 만족스러운 결과 뿐 아니라 이러한 기술 및 작업들이 중요하다는 사실도 알 수 있게 되었을 것이다. 필자는 보고서에 나타난 수치들에 흔들리지 않는다. CMP 2.0, Local Interface, 서블릿만으로 구성된 시스템, 다른 영속화 기술의 효과를 보고 싶다. 이러한 것들은 필자가 실제 프로젝트에서 사용할 수 있는 지식이기 때문이다. 게다가 필자는 벤더들처럼 시스템을 최적화할 수 없다. 그러므로 필자에게 중요한 정보를 주기 바란다. TMC 기술자들은 두 가지 시스템을 최적화하기 위해 많은 시간을 소모하였을 것이고, 그들의 머리 속에는 분명 유용한 정보를 많이 가지고 있을 것이다. 성능을 위해 무엇을 수정했는지, 왜 수정했는지? 그러한 작업들이 성능에 실제로 도움이 되었는지.

또한 벤치마크 테스트에서 XA 트랙잰션과 그와 같은 다른 "규칙"이 사용되었다. 이러한 "규칙"들이 결과에 과연 어떻게 영향을 미치는지 알고 싶다. 반드시 필요한 경우가 아니면 분상 트랙잰션을 사용하지 않으려고 필사적으로 노력한다. TMC 기술자들은 성능 향상을 위해 위에 언급된 기술들을 적용해 보았으며, 여전히 닷넷이 승리할 것이라고 말했다. 그러나 지금은 이 승패에 관한 논쟁에서 벗어나야 할 때가 아닌가 싶다.

개발의 용이함

프로그램 라인 수가 개발이 쉽다는 사실을 보여주는가? 결코 그렇지 않다. LOC 자체로는 아무런 의미가 없다. 나는 단지 아키텍처의 구조와 원리를 알고 싶고, 벤치마크 테스트가 내가 알기 원하는 자료를 주는지 궁금할 뿐이다.

결국 보고서가 말하는 바는 무엇인가?

이제까지의 문제들을 다 접어두고, 이 보고서가 의미하는 바는 무엇인가? 닷넷이 J2EE보다 좋다? 결코 아니다. 이 보고서는 J2EE에 대한 닷넷의 우수성을 의미주지 않는다. 이 보고서는 단지 특정 조건 하에서 마이크로소프트의 기술자들이 최신 모델이 아닌 서버에서 특정 J2EE 애플리케이션 서버을 사용하여 구버전의 프로그램을 튜닝한 결과보다 나은 성능을 얻었다는 사실만 보여준다. 반면에 마이크로소프트사는 닷넷 핵심 모듈도 수정할 수 있다. 벤치마크 테스트에서 더 좋은 결과를 얻기 위해 CLR팀이 실제로 그들의 가상머신을 변경했다고 말하는 것이 아니다. 나는 단지 그들이 그렇게 할 수 있으며, 그들이 할 수 있는 위치에 있었다는 것을 말하고 싶다.

이 보고서가 나에게 가르쳐 주는 것은 내가 다른 종류의 아키텍처를 사용하는 사람들로부터 더 많은 정보와 성능과 개발 용이성이 실제로 어떻게 작용하는지 정말 알고 싶어 한다는 사실이다. 나는 키스(Keep it simple and short)와 "기준 이상이면 된다"(Fast Enough)의 신봉자이다. 그러나 이 보고서는 단지 읽기에만 재미있을 뿐이다.

보고서가 다루고 있는 주제에 대한 실제적인 정보를 얻도록 노력하자. 닷넷보다 J2EE를 선택하는 이유는 수없이 많다. 필자는 이 보고서에 대한 커뮤티니와 벤더들의 반론을 기대하고 있다.

어쩌면, 벤치마크 테스트를 다시 할 수도 있을 것이다. 다시 강조하겠지만, 나는 새로운 벤치마크가 단지 수치상의 우열을 비교하는 것을 목적으로 하지 않기를 바란다. 테스트의 목적이 기술을 배우는 것이 되기를 바란다.

밝혀두고 싶은 것

위에서 쓴 내용은 단지 필자의 생각이며 TMC와는 아무 관련이 없다. 나는 TSS에 참여하고 있으며, 이 보고서는 필자에게 하나의 충격으로 다가온다. 나에게 충격인 만큼 여러분들에게도 충격이라고 생각한다.