CIO

글로벌 칼럼 | "그대로 믿어서는 안된다" 벤치마크, 분석 보고서를 제대로 보는 법

Andrew C. Oliver | InfoWorld 2017.06.27
벤치마크와 분석 보고서는 개발업체 제품과 기술에 대한 독립적인 평가를 제공하며 많은 IT 관련 종사자에게 절대적인 기준이 된다. 그러나 그 자료를 곧이곧대로 믿는 사람이 너무 많다. 사실 이런 자료를 대할 때는 좀더 회의적인 시각이 필요하다. 중요한 것은 그 자료를 작성하는 데 사용된 방법이다.

이는 필자가 개인적인 경험을 통해 알게 된 사실이다. 필자는 여러 소프트웨어 개발업체에서 일했고 지금도 일하고 있는데, 이 개발업체들은 분석 업체로부터 긍정적인 평가를 받기도, 부정적인 평가를 받기도 한다. 필자는 자사의 좋은 면을 부각하기 위해 사양 등 벤치마크를 위한 튜닝 작업도 직접 해봤다.

개발업체가 자사의 좋은 면을 전면에 내세우고 자사의 관점에 공감하도록 분석가를 설득하는 것은 나쁜 일이 아니지만 가끔 선을 넘는 경우가 있다. 어느 분석 보고서의 결론이 해당 분석가의 고객사인 개발업체의 입김에 따라 작성되었다는 뒷이야기는 흔하다.

또한 언론에서도 보도된 바와 같이 하드웨어 업계의 여러 분야에서 습관적인 벤치마크 조작이 이뤄진다. 폭스바겐 디젤 엔진 사례가 전부가 아니다. 벤치마크가 실행되는지 여부를 탐지한 다음 실제 환경에서보다 더 좋게 보이도록 벤치마크에 맞게 동작을 변경하는 방식으로 결과를 조작한다.

따라서 분석 보고서나 벤치마크 결과를 접하고 해당 자료를 얼마나 신뢰해야 하는지 가늠할 때는 다음과 같은 사실을 염두에 둬야 한다.

1. 분석가는 소프트웨어를 실행하지 않는다
분석가는 개발업체에 질문을 하고 문서를 읽고 데모를 보는 것만으로 보고서를 작성하는 경우가 많다. 분석가가 실제 그 소프트웨어를 사용하는 경우는 거의 없다. 소프트웨어 설명에 혹해서 사용해 본 적이 있는 사람이라면 개발업체의 주장과 실제 사용 경험은 다르다는 사실을 잘 알 것이다.

분석가들이 보편적으로 사용하는 방법인 "개발업체에게 묻기"는 결국 개발업체의 주장을 대변하는 결과로 이어지는데, 그 주장의 진실성은 천차만별이다. 사실 실제 제품 기능보다는 개발업체의 영업 프로세스 테스트에 더 가깝다.

2. 분석가는 유행어를 쫓는다.
SOA(서비스 지향 아키텍처)를 기억하는가? 필자는 JBoss에서 유능한 일단의 소프트웨어 개발자들과 함께 일한 적이 있는데 누구도 단순한 모듈형 설계 및 웹서비스와 SOA의 차이점을 알지 못했다. 오직 마케팅 부사장만 그 의미를 설명할 수 있었다.

어쨌든 일부 제품에 SOA라는 딱지를 붙이고 마케팅 정보에 이 용어를 사용하기 시작했다. 결국 사람들은 엔터프라이즈 서비스 버스와 관련된 무언가로 SOA를 정리했고 이 용어는 자사의 ESB에 공식적으로 들어갔다.

1년 동안 XYZ의 리더였는데, 그 다음 해에 분석가들이 XYZ는 무의미하고 이제 중요한 것은 ABC라고 말한다. ABC가 고객에게 거의 의미가 없는 소소한 기술적 인터페이스가 적용되었을 뿐 사실상 이름만 바뀐 XYZ라는 점은 중요치 않다.

SOA가 그렇게 중요했다면 가트너 매직 쿼드런트나 포레스터 웨이브에서 더 이상 SOA를 찾아볼 수 없는 이유가 무엇인가? 분석가들은 유행어를 쫓지만 실제 고객에게 필요한 부분이나 프로젝트와는 동떨어질 수도 있다.

3. 개발업체의 "셀프 인증"
스펙(Spec)의 벤치마크와 같은 벤치마크는 셀프 인증 개발업체 테스트다. 예전에 JBoss는 SpecjAppServer에 대해 비판을 받았는데, 이는 다른 게 아니라 데이터베이스와 컨테이너 관리 지속성(CMP)에 대한 테스트였기 때문이다. CMP는 애초에 존재해서는 안 되는, Java2EE 사양에 의해 만들어진 고약한 괴물이었다(아무런 실질적 이유도 없이 객체 관계형 매핑과 대치한다).

어쨌든 벤치마크에서 CMP를 측정했기 때문에 CMP에서 좋은 점수를 받아야 했다. 방법은 데이터베이스의 발목을 잡지 않도록 CMP 엔진을 튜닝해서 데이터베이스 성능을 올리는 것이었다. 이 방법은 통했지만 필자가 알기로 그 벤치마크를 게시하지는 않았다. 그 때쯤에는 이미 아무도 해당 벤치마크에 관심을 두지 않았기 때문이다.

물론 이런 테스트는 아무 의미도 없다. CMP가 특정 조인을 어떻게 처리하는 지에 관한 그 이상한 순열은 고객이 사용하는 앱 서버의 성능과는 하등 관계가 없었다. 고객은 실제 환경에서 그런 작업을 하지 않기 때문이다. 게다가 실행 규칙상 성능 개선을 위해 일반적으로 사용되는 요령이 제한됐기 때문에 고객이 실제 환경에서 사용하는 기법(최적화)도 반영하지 못했다.

결과적으로 개발업체들은 고객의 실제 경험을 반영하지 못하는 벤치마크에서 "승리"하기 위해 큰 돈을 투자한다. 아이러니하게도 고객이 벤치마크를 진지하게 받아들이는 한, 개발업체들은 계속해서 벤치마크에 전념할 것이다.

분석가와 벤치마크에서 유효한 정보를 얻는 방법
물론 누구나 모든 것을 다 알 수는 없고 그래서 외부에서 전문 지식과 검증을 찾는다. 앞서 언급한 문제점들에도 불구하고 독립 분석가와 벤치마크에서 유효한 지식을 얻는 방법도 있다. 살펴봐야 할 부분은 다음과 같다.

- 방법론: 분석가가 개발업체에게 질문을 하고 데모를 보고 문서를 읽는 방법만으로 작성한 분석 보고서는 별 가치가 없다. 분석가가 소프트웨어를 사용해 그 결과를 검증하지 않았다면 그 보고서는 그저 개발업체의 주장을 그대로 전달하는 것에 불과하다.

- 타당성: 예를 들어 서비스 지향 아키텍처가 회사에 중요하다고 스스로 생각해 본 적이 없다면 분석가가 그렇게 말했다는 이유만으로 중요하다고 생각해서는 안 된다. 또한 분석가가 어떤 유행어에 대한 지지를 바탕으로 제품을 평가하는 경우 회의적인 시각으로 봐야 한다. 자사에게 명확히 유용한 것을 찾아라. 그게 데이터를 받아서 유의미한 알고리즘을 적용해 납득할 만한 결과를 돌려주는가?
예를 들어 메시징 서버에 관심이 있다면 개발업체나 분석가가 "무엇보다 중대한 것"이라 말한다 해도 서비스 지향 아키텍처 또는 머신러닝을 기준으로 제품을 선택해서는 안 된다. 이들은 2년 정도 지나면 분명 새로운 유행어로 갈아타겠지만 이를 도입한 이들은 계속해서 그 메시징 서버를 운용해야 한다.
물론 시간이 지나면서 새로운 개념과 기술이 등장해 정당한 평가의 기준이 되기도 한다. 이런 경우는 이러한 새로운 영역에서 자사에게 무엇이 유용한지 명확하게 보이므로 알 수 있다. 그 특이성과 명확함이 보이지 않는다면 단순한 유행어일 뿐이다.

- 서드파티 인증: 벤치마크나 테스트의 정확함과 타당성을 제 3자가 검증할 때까지는 개발업체의 주장을 믿어서는 안 된다. 개발업체들은 실행 규칙을 준수하면서 정직함의 경계에서 줄타기하는 방법을 잘 안다. 또한 그 서드파티는 개발업체에게서 후원을 받지 않았어야 한다.

- 평가: 벤치마크의 러너블(runnable) 또는 분석가 평가 기준이 본인이 관심있는 분야와 밀접하게 관련되지 않는다면 재고해야 한다. 벤치마크의 경우 벤치마크 도구를 재사용하되 자사의 러너블을 넣어볼 수 있다. 이해하지 못할 독자 대상의 자료보다 공개적으로 볼 수 있는 명확한 코드를 찾는 편이 낫다.
분석 보고서의 경우 기준을 조정하거나(예를 들어 포레스터 웨이브에서는 사용자가 스프레드시트를 직접 조작할 수 있음) 조정을 허용하는 다른 보고서를 찾아라.

이번 칼럼의 핵심은 검증을 통한 신뢰다. 직접 테스트하고, 유행어에는 아무런 의미가 없음을 기억하고, 해당 분야에 대한 지식을 갖춰야 한다. 요약 페이지만 볼 것이 아니라 자세히 살펴보면서 방법론을 세밀히 확인하고, 헤드라인은 보고서를 구매하거나 벤치마크를 보도록 유도하는 광고에 불과함을 알아야 한다. editor@itworld.co.kr  

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.