소프트웨어 품질에 대한 책임은 누구에게 있는가

이영석 stone@sqe.co.kr SOAP, 웹 서비스 등 XML 기반 기술과 BPM을 통한 프로세스 시스템 신봉자로 소프트웨어 품질에 대한 정통부 GS인증 업무를 수행하는 등의 개발자 출신 QA라는 흔치 않은 경력을 가지고 있다. 현재 와이즈스톤 대표이며, 소프트웨어 품질관리 교육 및 컨설팅 등을 하고 있다. 2007년 5월 15일

무엇이 품질인가?

간단히 필자의 경력을 소개하는 것이 필자가 하려는 이야기에 대해 독자들의 공감을 얻는 데 도움이 될 듯 하다. 필자는 초기에 XML 프로세싱 시스템 개발 프로젝트로 개발자를 시작했으며, 이후 SOAP, 웹 서비스 개발과 업무 프로세스 관리 시스템인 BPM 개발 프로젝트에 참여했다. 이렇게 개발자의 길을 가던 필자의 관심 대상은 새로운 개발 기술, 설계 방법론, 개발 방법론 등이었다.
늘 개발자의 역할을 해오던 중 업무의 전환점을 맞게 되었다. 개발자가 아닌, 테스터 일을 시작하게 된 것이다. 정통부에서는 시장에 출시되는 제품을 일정 수준 이상의 품질을 갖도록 유도하기 위해 GS인증 제도를 수행하고 있다. 그 GS인증을 위한 품질 테스트 역할을 수행하게 된 것인데, 이 업무를 수행하면서 제품을 바라보는 관점이 크게 바뀌게 되었다.
필자의 바뀐 관점을 설명하기 위해 질문 하나를 해보겠다. 만약 여러분에게 "사용자의 신상명세를 받아 예약을 처리하는 기능을 어떻게 구현할 것입니까?"라고 영업이사가 묻는다면 어떤 대답을 할 것인가?

1. XML 기반으로 서버는 자바로 개발하고, 클라이언트는 AJAX로 개발할 것입니다.
2. 신상명세의 입력 항목은 다음과 같이 5개의 항목을 정하고, 보안이 필요한 부분은 별(*) 처리하고, 입력이 잘못된 경우 필드에 기존 입력 값을 보존하는 방식으로 개발할 것입니다.

물론 이 1번과 2번 중에 정답이 있는 것은 아니다. "어떻게"라는 모호한 질문을 나름 해석하고 대답을 하는 과정에서 자신의 관점이 투영될 것이다.
개발자 상당수가 1번과 같은 답을 할 것이다. 개발 과정 중 직면하는 이슈를 바라보는 시각이 도구와 방법에 집중될 수 밖에 없기 때문이다. 이런 개발자의 관점이 틀렸다는 것이 아니다. 대부분의 개발자는 무엇을 구현하는가 보다는 어떻게 구현하는가, 그리고 어떤 기능을 구현할 것인가 보다는 어떤 기술을 사용할 것인가에 생각의 비중을 더 크게 둔다는 것이다. 제품 전체를 혼자 개발하는 것이 아니라 제품 개발 일부분을 맡아 그 부분을 구현해야 하는 개발자 입장에서는 당연할 일이라 하겠다.
하지만 제품 사용자는 다르다. 사용자는 그 제품을 개발할 때 어떤 최신 기술이 사용되었는지 이해하지 못하며 어쩌면 관심조차 없을지 모른다. 사용자가 원하는 것은 정말 자신들의 요구사항에 맞게 만들어졌는지, 그 요구 사항을 만족시킬 수 있는 제품인지 하는 것이다.
사용자의 요구사항을 제품과 시스템 등이 얼마나 충족시키고 있는가에 대한 문제, 이것이 바로 "품질"이다. 사용자 입장에서의 평가, 이것이 바로 품질 평가이다.

소프트웨어 품질에 대한 표준적인 정의는 다음과 같다.
- “명시적이거나 묵시적인 요구사항을 만족하는 제품이나 서비스의 특성의 총체”(ISO 8492)
- “명시적인 요구사항과 사용자나 고객이 기대하는 것, 필요로 하는 것을 시스템이나 구성 요소, 공정이 충족시키는 정도”(IEEE Standard Glossary of Software Engineering Terminology)

따라서 품질은 사용자가 명시적으로나 암시적으로 원하는 것을 제품이 만족시키는 정도를 의미한다. 즉 소프트웨어의 품질이란 소프트웨어 제품이 사용자의 요구사항이나 만족도를 얼마나 충족시키는가를 나타내는 것이다. 필자는 품질평가 업무를 통해 처음으로 사용자 관점에서 제품을 보게 된 것이다.

위로

왜 품질인가?

왜 개발자가 사용자의 관점을 가져야 하는가. 그것은 개발자든 테스터이든 제품 개발에 참여하는 모든 사람들의 목적은 하나, 다시 말하면 사용자가 만족하며 사용할 수 있는 제품 개발이라는 공통된 사명을 가지고 개발과정에 참여하기 때문이다. 즉 좋은 품질의 제품 개발이 개발에 참여한 모든 이의 궁극적 사명인 것이다.
개발자가 아무리 최신 기술을 이용해 멋지고 화려한 코드로 소프트웨어를 개발하더라도, 최신 개발방법론을 이용해 최단시간 개발을 해낸다 하더라도, 소비자 입장에서 그 제품 품질이 만족스럽지 못하다면 궁극의 사명 달성은 실패한 것이 된다.
그렇기에 제품 개발에 참여하는 모든 사람이 사용자 입장에서의 관점, 즉 품질이라는 관점을 가져야 하는 것이다. 앞서 언급한 것처럼 제품 개발에 참여하는 모든 이에게 제품 품질에 대한 책임이 있지만 개발자는 그 어떤 다른 역할의 이들보다 더 큰 책임이 있다.

일반적으로 품질관리라 하면 테스트를 떠올린다. 테스트는 품질에 대한 1차적인 역할을 하지 못한다. 품질에 능동적으로 영향을 주기도 쉽지 않다. 테스트라는 것은 누군가 만들어 놓은 제품을 검사하고 확인하는 작업이기 때문이다. 형편없는 졸작을 아무리 뛰어난 평론가가 평가한다고 해서 그 평가 행위 자체만으로 졸작이 명작이 될 수는 없다.
제품의 품질을 책임지는 사람은 테스터가 아니다. 가장 근본적으로 제품의 품질에 책임이 있는 사람은 개발자인 것이다. 이런 이유에서 개발자의 품질에 대한 이해와 역할은 중요한 문제다. 품질관리 또는 품질보장(QA: Quality Assurance)의 역할은 제품을 테스트하는 테스터뿐 아니라 개발에 참여하는 모든 이에게 있다.
품질을 보장하기 위한 첫 번째 행위는 사용자의 요구를 파악하는 것이다. 사용자가 원하는 것이 무엇인지를 정확히 파악해야 그 요구대로 제품을 만들 수 있다. 요구가 파악된 후에 품질에 대한 책임은 제품을 만드는 사람에게로 넘어간다. 개발자는 그 제품을 사용자의 요구에 맞도록 만들어야 한다. 설령 자신의 생각과 요구 사항이 일치하지 않더라도 그 제품을 사용할 사람이 자신이 아니라면 그 사용자의 요구사항에 더 귀 기울여야 하는 것이다.
테스터는 그 제품을 확인한다. 요구사항이 정확히 반영되었는지, 요구사항대로 제품이 만들어 졌는지, 제품을 사용할 사용자의 입장을 대변해 그 제품을 확인하고 평가하는 것이다. 그리고 부족한 면이 있다면 다시 개발자에게 그 부분을 설명하고 개선을 요구한다.
이 모든 프로세스가 품질보장을 위한 행위이며, 품질보장이란 일부 조직의 일부 테스트 행위로 한정할 수 없다. 개발을 위한 모든 과정과 모든 행위가 품질을 위한 과정이며 행위이고, 품질에 대한 책임 그 한가운데 개발자가 있다.

위로

테스터의 상황

사실 대부분의 테스터는 개발자로부터 좋은 대우를 받지 못한다. 테스터의 일이 테스트 모델 설계, 테스트 케이스 작성 등의 창조적인 활동임에도 불구하고 대외적으로 개발자의 창조적 개발 활동에 비해 과소 평가되는 것이 현실이다. 또 개발자는 자신의 코드를 100% 이해하지 못한 테스터를 우습게 생각하는 경향이 있다. 사실 테스터가 코드를 100% 이해할 필요는 없다.
미국의 SQE(www.sqe.com) 교육 내용 중에는 테스터의 바람직한 기술에 대한 습득 정도와 참여 역할 수준을 화이트박스(White Box)도 아니고 블랙박스(black Box)도 아닌 그레이박스(Grey Box)라고 말하고 있다. 즉 코드와 개발기술을 100% 이해하고 간섭하는 것도, 기술을 전혀 이해하지 못하고 현상만 확인하는 것도 바람직하지 않으며, 개발자와 기술적인 공감대를 형성할 수 있는 수준의 기술 이해와 참여 수준이 바람직하다는 것이다(이것은 디버거와 테스터를 구분하는 역할 분담론과도 관련이 있다고 하겠다).
테스터와 개발자는 역할이 다르며 필요한 전문 지식의 영역이 다른 것이다. 테스터는 한 분야의 전문가인 개발자와는 다르게 더 많은 종류의 기술로 만들어진 제품을 테스트한다. 개발자의 깊은 종적인(vertical) 지식에 비해 더 넓은 횡적인(horizon) 지식을 가지고 있다(물론 코드 인스펙션과 같이 예외적인 테스트도 있다). 이러한 경향으로 인해 개발자와 테스터의 대화가 쉽게 풀리지 않는 경우가 발생한다.

위로

개발자의 상황

가끔 테스트한 결과를 놓고 개발자와 심한 논쟁을 벌이는 경우가 생긴다. 특히 설계부터 구현까지 모든 일을 혼자 처리한 개발자의 경우에 이런 논쟁이 일어나는 빈도가 높다. 더군다나 사용성 측면의 논쟁이라면 결론을 내지 못하는 경우가 대부분이다.
테스트라는 행위는 사실 설계도라는 기본 정보가 필요하다. 당연히 설계도에는 사용자의 요구사항이 정확하게 담겨 있어야 한다. 그렇기 때문에 설계도 작성에도 테스트가 필요하다. 사용자의 요구에 따라 만들어진 제품 설계도가 정말 사용자의 요구를 담고 있는지 확인하는 작업이 테스트이다. 또한 제품이 개발된 이후(또는 중간에라도) 제품이 정말 설계도대로 만들어졌는지 확인하는 작업이 테스트이다.
사용자의 요구사항 파악부터 제품 개발까지 아무런 객관적(여기서 객관적이란 같은 개발자가 아닌 제3의 관점을 말한다. 가령 테스터) 검토 없이 진행되어 온 경우, 만약에 그 과정까지도 다른 개발자들과 상의 없이 혼자 설계하고 개발한 경우라면 논점의 해결은 어렵다.
이미 그 개발자는 제품을 완성하는 단계까지 오면서 자신의 철학을 확고하게 만들었기 때문이다. 예를 들어 보자. 완성된 집을 감리하는 과정에서 왜 여기에 화장실이 있느냐는 질문을 한다면 설계부터 진행해온 개발자는 아주 쉽게 그 이유를 설명할 수 있을 것이다. 그는 집을 만든 사람일 뿐 아니라 집을 설계한 사람이기 때문이다. 화장실이 지금 이 위치에 있는 것은 나름 설계자의 의도와 철학이 있었기 때문일 것이다. 다 만들어진 집을 가지고 이 집을 사용할 사람이 불편하니 화장실을 안방 옆으로 옮기라고 한다면? 어떤 건설업자라도 쉽게 수긍하기 힘들어 할 것이다(콘크리트를 부수고, 하수 배관을 옮겨야 하며, 마감질이 끝난 바닥도 들어내야 한다).
소프트웨어 개발도 마찬가지다. 만약 설계시에 문제를 지적한다면 개발자가 그 의견을 수용하기 쉽겠지만, 개발이 끝났을 때는 제품 변경이란 정말 쉽지 않은 일이 되어 버린다. 더군다나 기능 결함으로 인해 눈에 보이는 하자라면 테스터의 지적을 받아들이기 쉽지만, 눈에 보이지 않는 사용자 측면의 사용성을 가지고 논의를 한다면 수용 가능성은 거의 없다. 개발자(그리고 설계자 역시)는 개발과정 중에 품질에 관해 테스터와 긴밀하게 협력해야 한다. 또한 그들이 쉽게 의사소통을 하기 위해 서로 동일한 언어를 사용해야 한다. 즉 테스터뿐 아니라 개발자 역시 품질에 관한 기본 개념이 필요한 것이다. 그러나 필자 역시 그러했지만 대부분의 개발자들은 품질론에 대한 기본 지식이 부족한 것이 현실이다. 항상 더 좋은 코드를 위해 노력하고 있지만 그 기준이 기능성인지, 사용성인지, 효율성인지, 신뢰성인지에 대한 정확한 인식이 부족하다.

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

소프트웨어 품질론에 대한 국제표준인 ISO9126이나 TTA(한국정보통신기술협회) 표준인 TTAS.KO-11.0049 등의 자료를 보는 것으로도 기본적인 품질에 대한 틀을 이해하는 데 도움이 될 것이다(TTAS 패키지 소프트웨어 품질 평가 항목 http://www.tta.or.kr/Home2003/library/ttasView.jsp).
개발자는 자신들의 사명이 좋은 품질의 제품을 만드는 데 있다는 사실을 명심해야 한다. 또한 자신들이 품질에 관한 1차적인 책임을 가지고 있다는 것을 알아야 한다. 그것이 개발자가 품질론을 알아야 하는 이유이다. 좋은 코드 개발에 목말라 하는 개발자에게 어쩌면 진정 필요로 한 것은 품질에 대한 정보일지 모른다. 다음 칼럼에서는 품질이 가지고 있는 다양한 면을 살펴보는 기회를 갖도록 하겠다.

위로

[지난 developerWorks Column 보기]