Offcanvas

애플리케이션

애플리케이션 품질을 평가하는 다섯 가지 기준

2011.06.21 Jitendra Subramanyam  |  Network World

이 글은 특정 제품 홍보를 피하기 위해 네트워크 월드에서 수정됐으나 작성자의 방식을 선호함을 밝혀둔다.

소프트웨어의 품질이란, 처칠의 말을 빌자면, “미스터리 속의 수수께끼에 담긴 암호”다. 숙련된 IT기술자조차 소프트웨어 품질을 어떻게 정의하고 평가할 것인지에 대해서는 잘 모르는 경우가 많다. 기술을 기준으로 평가해야 할까? 어떤 수단을 사용했느냐에 따라 평가해야 하나? 그리고 쉽고, 저렴하고, 정확하게 품질을 평가하기 위해서는 어떻게 해야 할까?

당연한 일인지도 모르지만, 이러한 어려움 때문에 소프트웨어 그 자체보다는 생산 과정에 지나치게 초점을 맞춘 채 품질을 평가하는 경우가 많아졌다. 우리는 이러한 품질 평가 과정을 정확하게 정의하고 평가해 사람들이 소프트웨어를 제작하고 관리하는 활동에 초점을 맞출 수 있도록 해야겠다고 생각했다. 대부분 사람들이 보지 못해 신경 쓰지 못하는 것은 그 과정을 통해 제작된 소프트웨어 제품들이다. 눈에서 보이지 않으면 마음에서 벌어진다는 말이 딱 맞다.

하지만 과정 자체에 아무런 결점이 없다 해도 최종 결과물이 잘못된 것이라면 아무 소용 없다. 소프트웨어 품질을 제대로 평가할 수 없다면 그러한 위험 부담을 안고 가야 한다.

소프트웨어 품질에 대한 가시성 부재는 많은 소프트웨어 관리 문제의 원인이 되기도 한다. 사업주들은 왜 소프트웨어에 돈이 그렇게 많이 들어가는지, 만드는 데 왜 그렇게 오래 걸리고 바꾸는 데에는 더 많은 돈이 들어가는지 이해하지 못한다. CIO들의 경우 왜 언제나 추정 값이 맞지 않는지 답답해 하고, CFO와 CEO들은 IT 투자 비용이 왜 그렇게 많아야 하는지 궁금해한다.

게다가, CFO와 CEO가 소프트웨어의 진정한 가치에 대해서도 확신하지 못한다는 점도 문제다. 이 사람들은 소프트웨어에 투자한 돈 만큼의 가치를 돌려 받을 수 있을지를 의심하기도 한다.

이건 마치 수영선수 마이클 펠프스(Michael Phelps)가 밥 먹는 시간이며, X박스에서 보내는 시간, 강아지 산책 시키는 시간은 열심히 재면서 정작 100미터 수영하는 데 걸리는 시간은 얼마인지 측정하지 않는 것과 다를 바 없다!

소프트웨어 품질은 외부 측면을 통해서면 드러난다. 소프트웨어가 실제로 어떻게 작동하는지 말이다. 하지만 이러한 외부적인 측면은 너무 조금씩, 너무 늦게 드러나는 경우가 많다. 미리 이에 대해 알려주는 시스템이 있다면 편할 텐데 말이다.

이 시점에서 독자들은 아마, “소프트웨어 테스트를 통해서 품질을 관리하는 것 아닌가?” 생각하겠지만, 테스팅은 아무리 잘해 봐야 부분적인 해결책밖에 못 된다. 소프트웨어의 구조적 품질을 평가하지 못하게 때문이다. 그저 애플리케이션 디자인의 품질과 소프트웨어 실행이 그 디자인에 얼마나 잘 맞는가를 볼 뿐이다.

제대로 설계되고 실행된 소프트웨어야 말로 품질이 뛰어나다 할 수 있다. 작업하기 편리할 뿐 아니라, 급박한 업무 요구에도 적절히 대응할 수 있기 때문이다. 이런 측면에서 품질에 대한 테스트를 실행하는 일은 전혀 불가능한 것이 아니다.

소프트웨어 제품 자체의 품질을 평가하는 것이 중요하다는 것을 이제 알았을 것이다. 품질 평가는 소프트웨어 블랙박스를 투명하게 공개하는 유일한 방법이다. 하지만 어떻게 하면 이를 제대로 정의하고 적당한 비용을 사용해 평가할 수 있을까?

소프트웨어 품질을 평가하는 제품을 사용하면 가능하다. 그리고 이 제품들은 품질 평가를 위해 반드시 필요하므로 소프트웨어 품질에 대한 정의 역시 내릴 수 있을 것이다.

내용 면에서는 좀더 정교한 소프트웨어 품질 관리 툴이 필요하다. 애플리케이션 구성 요소들의 품질은 다른 어떤 요소들과 어떻게 연결돼 있는지에 좌우된다. 따라서 한 애플리케이션의 품질은 단순히 각 요소들의 품질을 합쳐놓은 것이라고만 할 수는 없다. 소프트웨어 엔지니어링에서는 이 사실을 기억하는 것이 매우 중요하다.

이처럼, 애플리케이션 품질이 단순히 한두 개의 구성 요소의 품질만 알아서는 안 된다는 것을 알게 되면, 대부분은 평가를 포기하고 만다. 하지만 꼭 그럴 필요는 없다. 애플리케이션 품질이 상호 의존적이기 때문에 이를 평가하는 시스템은 다음의 다섯 가지를 평가할 수 있어야 한다.

1. 범위 : GUI부터 데이터베이스까지 폭넓은 기술을 다룰 수 있어야 한다. 대부분의 현대 애플리케이션들은 복잡하게 얽힌 여러 언어와 시스템으로 구성돼 있다.

2. 깊이 : GUI부터 데이터베이스까지 전체 소프트웨어 애플리케이션의 완전하고 자세한 설계도를 그릴 수 있어야 한다. 그러한 설계도 없이는 애플리케이션 구성 요소들의 상호 의존성을 고려하기 어렵다.

3. 소프트웨어 엔지니어링 지식 : 제품은 또한 수백 개의 실행 패턴에 대비해 전체 애플리케이션을 확인할 수 있어야 한다.

4. 구체적인 행동 지침을 소개하는 메트릭스 : 단순히 소프트웨어 관련된 정보를 알려줄 뿐 아니라 무엇을 먼저 하고 어떻게 해야 할지, 그 다음에는 무엇을 해야 하는지 등을 알려줘 소프트웨어 품질을 개선시켜야 한다(즉, 행동의 우선 순위와 방법을 알려줘야 한다).

5. 자동화 : 마지막으로, 이 모든 것들을 전부 자동으로 할 수 있어야 한다. 이 일들은 인력으로 할 수 있는 일이 아니고, 시간도 매우 많이 들기 때문이다.

소프트웨어 품질을 평가하는 것은 매우 중요하다. 제품 그 자체의 품질 말이다. 또, 소프트웨어 품질의 상호의존적 성격을 고려해 평가를 내리는 것 역시 간과돼서는 안 된다. 소프트웨어 개발에 있어 평가는 매우 중요하지만, 잘못된 평가를 내리는 것보단 아예 평가 내리지 않는 편이 나은 경우가 대부분이다.

*CAST는 전 세계 650여 개 기업의 IT 및 경영진들에게 정확한 분석과 함께 자동화 소프트웨어 평가 제품을 제공해 애플리케이션 개발을 사실에 기초한 과정으로 만들고 IT에 들어가는 비용을 줄이면서 사업 방해물을 예방하고자 노력하고 있다. ciokr@idg.co.kr

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

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

Copyright © 2024 International Data Group. All rights reserved.