[칼럼]SW 품질관리와 테스트에 대한 단상

박민우

최근 IT 업계의 가장 큰 이슈는 농협 전산장애 사태로 인한 사회적 혼란이다. 많은 전문가들이 이번 사태의 주요 원인을 제3자의 해킹으로 보고 있지만 보안에 대한 총체적인 의식 문제를 지적하고 있다. 더불어 허술한 감사시스템도 그 원인 중에 하나로 보고 있다.

아직 정확한 원인과 범인을 찾아내지는 못하고 있는 상태지만, 어찌됐건 해킹은 일종의 테러이고 우리가 살고 있는 현 시대에 이러한 사이버 테러는 사전에 방어하기란 현실적으로 쉽지 않다. 그리고 그 방법이 내부인과 연결된 경우는 더욱 어려워진다.

하지만 진짜 문제는 해킹 이후에 대처 능력이다. 모든 시스템은 복잡도가 늘어날 수록 장애의 확률도 높아진다. 장애가 발생하지 않도록 하는 것이 최선이겠지만 그 다음 노력은 발생한 장애를 얼마나 빨리 복구할 수 있는가가 또 다른 능력이다.

클라우드 시스템 구성 조건 중에 매우 중요한 요소 중에 하나가 장애 발생시 회복(Recovery) 능력이다. 자동확장, 자동복구 능력은 시스템 자원과 밀접한 연관이 있고 대부분 대규모 인터넷 서비스 업체에서 활용도가 높긴 하지만, 이제는 금융시스템에서도 적용해 볼 필요가 있을 것 같다.

많은 사람들이 테스트를 많이 할 수록 장애가 일어날 확률이 줄어든다고 생각한다. 하지만 테스트를 어떻게 하느냐에 따라서 장애의 확률은 줄어들 수도, 그대로 일 수도 있다는 사실을 간과하고 있다. 심지어 장애에 대한 복구까지도 포괄적인 테스트 전략 중에 하나라는 사실도 잘 모르는 경우가 많다.

서두가 길었지만 이번 칼럼에서는 테스트에 대한 잘못된 인식과 전략적인 테스트의 필요성에 대해서 언급을 하고자 한다.

■소프트웨어 테스트와 요구공학

다음은 소프트웨어 테스트에 대한 일반적인 생각들이다.

- 테스트는 기능구현이 완료된 이후에 진행한다.

- 테스트는 일반인들이 서비스 메뉴얼을 보고 무작위로 기능을 수행하여 결함을 발견해 내는 것이다.

- 테스트는 테스터의 수와 테스트 시간이 많이 주어질수록 결함을 발견할 가능성이 높다.

- 테스트 보고서에 적혀있는 결함의 50% 이상은 테스터들이 기능을 잘 이해하지 못해서 작성한 내용이다.

- 테스트는 UI가 존재하지 않는 경우 제대로 테스트를 수행하기 어렵다.

- 서버 성능테스트는 서버에 과도한 부하를 주어서 서버가 견딜 수 있는지 확인하는 테스트다.

대부분 많은 기업들과 개발조직에서 이렇게 테스트를 수행해왔고 이런 과정이 당연하다고 생각하고 있다. 하지만 최근 복잡도가 높아진 소프트웨어 환경과 모바일 서비스까지 결합된 상황에서는 기존의 주먹구구식 테스트는 한계에 다다랐다.

실제로 요구공학이나 선진화된 IT 조직에서는 위와 같은 방식으로 테스트를 진행하지는 않는다.

물론 100% 새로운 방식으로 진행하는 것은 아니지만 다른 시각의 접근 방식을 이해할 필요가 있다.

우선 가장 잘못된 상식은 "테스트는 기능구현이 완료된 이후에 진행한다"로 알고 있다는 것이다. 기능이 구현되지 않았는데 어떻게 테스트를 한다는 것일까?

이러한 의문의 가장 큰 문제는 테스트의 범위가 개발된 결과물을 대상으로 한다라는 고정관념 때문이다.

소프트웨어공학(특히 요구공학)에서 많이 얘기되어지는 V-모델(http://ko.wikipedia.org/wiki/V_%EB%AA%A8%EB%8D%B8)을 꼭 예를 들지 않더라도, 기획/설계 단계에서 제 3자가 테스트 검증을 위한 참여가 이루어진다는 것은 효과적인 테스트 케이스를 만들기 위해서 매우 중요한 일이다. 생소하겠지만 테스트 컨설턴트들은 아키텍처 설계, UML, 요구사항 명세들을 같이 숙지하게 된다.

소위 말하는 단위테스트의 경우 대부분 해당 시스템을 개발한 개발자들이 테스트도 병행한다.

일단 제 3자의 경우 요구사항이나 설계에 대한 이해가 없기 때문에 단위테스트에 참가할 수가 없기 때문이다. 이런 경우 제대로 된 테스트 계획이나 테스트 설계 없이 진행되는 경우가 많기 때문에 형식적인 테스트만 하게 되는 문제가 있다.

하지만 위에 얘기한 것처럼 기획/설계 단계에서부터 테스트 컨설턴트가 함께 참여했다면 제 3자에 의한 단위테스트가 가능하며, 이렇게 개발과 테스트의 분리는 기존 개발자들이 테스트에 뺏기는 시간과 비용을 줄여서 원래의 목적인 개발에 집중할 수 있도록 도와준다.

숙련된 테스트 컨설턴트의 경우 기획과 설계에 대한 리뷰만으로 충분한 테스트 케이스 추출이 가능하며 단위테스트를 개발과 병행하는데 문제가 없다. 문제는 국내에 이런 숙련된 테스트 컨설턴트가 거의 전무하다는 것이다. 대부분 대형 포탈이나 대형 SI 조직 내에 SQE 같은 팀에 속해있는 경우가 많으며, 자사의 시스템에 대한 검증과 테스트만 하기에도 시간과 자원이 빠듯하다.

비록 잘못된 상식 하나만 가지고 얘기를 시작하게 되었지만, 결론은 위에서 언급된 테스트에 대한 일반적인 생각들이 모두 잘못된 생각이라는 것이다. 일반인 관점에서의 테스트도 중요하지만, 이런 류의 테스트는 서비스 런칭에 앞서서 알파 버전이나 클로즈드베타 버전에서도 충분히 가능한 테스트라는 것이다.

더군다나 테스트 계획 없이 하는 무작위 테스트는 주어진 시간과 투입인력이 많다고 해서 효율이 높아지는 구조도 아니다. 당연히 시스템의 기획과 설계에 대한 이해가 부족하기 때문에 기능에 대한 이해부족으로 오는 테스트 오류들도 많아지게 된다.

■테스트 시뮬레이션과 자동화 툴

소프트웨어 공학에서 언급하는 테스트 방법론은 테스트에 대한 잘못된 이해를 바로 잡는데 많은 도움이 된다. 하지만 이러한 방법론과 관련된 툴을 사용한다고 해서 모든 테스트 과정이 완벽해 지는 것은 아니다. 우선 완벽한 테스팅이란 것 자체가 존재하지 않는다. 테스팅은 결함이 존재함을 밝히는 행위일 뿐이다.

결국 어떤 방법론과 어떤 툴을 사용하는가의 여부가 테스팅의 결과를 크게 좌우하지는 않는 경우가 많다. 그렇다면 어떻게 해야 테스팅이 완전함에 가까워질 수 있을까? 이 역할의 키는 결국 테스트 엔지니어의 창의력에 달려있다고 볼 수 있다.

좋은 테스트는 실제 상황과 유사한 환경하에서 수행하는 것이다. 어떻게 실제 상황을 재현할 것인가에 대한 고민이 필요하다.

예를 들어 스마트폰 모바일앱과 서버 간 통신에 대한 테스트를 하고 싶다면, 기존의 테스트 방식은 에뮬레이터 같은 가상의 모바일앱을 통해서 서버에 지속적으로 통신을 수행하고 오류를 검출해 내는 형태였다. 반면 실제 상황에 좀 더 가깝게 시뮬레이션을 해보면 사용자가 3G 환경에서 엘리베이터를 타는 동안 통신의 문제가 발생하고 다시 사무실에서 와이파이 환경으로 전환되는 상황을 시뮬레이션 해 볼 수 있을 것이다. 이런 상황에 대한 테스트 슈트가 만들어지고 시뮬레이션을 수행한다면 좀 더 완전에 가까운 테스팅이 가능해 질 것이다. 개별 상황에 대한 시뮬레이션이 추출되면 이것들을 모아서 해당 서비스 전용 자동화 툴의 형태로 발전시킬 수도 있다.

주어진 상황과 방법에 의존하기에는 현재의 IT 환경은 변수가 너무 많아졌다. 따라서 테스팅 방법도 기존 방식에 국한하지 말고 새로운 방식에 대한 연구와 고민이 필요한 시점이다.

개발하기도 바쁜데 이런 고민과 시뮬레이션, 그리고 자동화툴까지 만드는 것은 현실을 맞지 않다고 생각할 수도 있다. 그래서 개발조직과 테스팅 조직이 분리되어 하나의 프로젝트를 같이 진행해야만 개발자들의 시간을 뺏지 않을 수 있다. 테스트 조직의 비용 문제가 걱정되겠지만 충분한 테스트가 이루어지지 않아서 유지보수에 투입되는 시간과 비용을 생각하면 오히려 미리 테스트 조직에 지출하는 것이 비용을 아끼는 방법이 될 것이다.

애자일 방법론에서 추구하는 가장 이상적인 테스팅은 개발과 테스팅이 동시에 완료되는 구조다. 소위 말하는 테스트 주도 개발(TDD: Test Driven Development)이 이런 방식이다. 많은 SI 조직에서 애자일 방법론에 대해서 비현실적이라고 말한다. 하지만 TDD만큼은 애자일 방법론에서 가장 SI에 적합한 방법론이라고 생각한다. 많은 프로젝트에서 개발조직과 테스트조직은 좋은 관계를 유지할 수 없다. 하지만 TDD의 경우 개발자가 테스터고 테스터가 곧 개발자이기 때문에 감정이 상할 일이 많지 않다. 물론 개발기간이 좀 늘어날 수는 있겠지만 이제는 일단 만들어놓고 보자 식의 개발은 지양되어야 할 것이다.

■테스트 엔지니어의 필요성

많은 대규모 프로젝트에는 PM이라 불리는 프로젝트 매니저가 존재하고 기능 단위의 PL이라 불리는 프로젝트 리더들이 있다. 이 사람들이 실제 코딩을 하지는 않지만 그들이 능력과 수준이 부족할 경우 해당 시스템의 제대로 된 오픈을 기대하기 어렵다. 마찬가지로 TM(테스트 매니저)와 TL(테스트 리더)의 부재는 시스템의 안정성과 완전성을 담보할 수 없다.

대부분의 프로젝트는 일단 ‘오픈하고 보자’라는 식으로 일을 진행하게 되고 일단 돌아만 가면 사용자의 반응과 증가추이를 봐서 리뉴얼하면 된다고 생각한다. 기획의 확장에 의한 리뉴얼은 바람직하지만 설계의 오류와 개발의 미비함으로 발생하는 리뉴얼은 개발비용이라기 보다 운영비용에 포함된다. 체계적인 테스트 프로세스가 이루어지지 않은 경우 개발비용 몇 배의 운영비용이 발생하는 것은 자명한 일이다.

최근 발생한 L사의 스마트폰 결함문제의 경우도 현상은 배터리의 교환과정에서 발생하는 것처럼 보이지만 실제로는 소프트웨어의 문제로 인한 것이라고 한다. 이미 내부적인 알파 테스트를 통해서도 확인된 문제지만 밀어붙이기식의 출시는 결국 소비자의 불만만 가중시키고 브랜드에 대한 이미지만 실추시키게 되었다. 국내 굴지의 제조사들조차도 설계단계에서부터의 테스트 프로시져가 구축되지 않았다는 것이다.

이러한 사례에서 보듯이 이제 소프트웨어 테스트는 포탈이나 애플리케이션 개발업체에 국한 된 것이 아니다. 통신사, 제조사, 자동차 회사 조차도 이제는 단순한 하드웨어만 가지고는 사업을 지속할 수 없게 되었다. 소프트웨어의 중요성이 높아진 것은 모두 인지하고 있지만 정작 테스트의 경우는 잘못된 인식과 방법으로 인하여 충분한 효과를 얻지 못하고 있는 경우가 대부분이다.

"자동차 혁신의 90%는 소프트웨어에서 출발한다"라고 선언한 독일 BMW의 경우만 보더라도 이제 우리나라도 선진적인 검증 시스템의 도입이 절실하다.

더 큰 문제는 이러한 문제 인식의 공감대가 형성된다 하더라도 제대로 된 테스트 컨설턴트와 테스트 엔지니어를 구할 수가 없다는 것이다. 기존 테스트 아웃소싱 업체들은 대부분 알파테스트를 대행하는 수준이고, 엔지니어 레벨에서 설계단계부터 참여할 수 있는 테스트 컨설턴트는 만나기조차 쉽지 않다.

많은 개발자들이 원하는 목표가 있을 것이다. 대부분은 코딩의 수준을 높이고 싶을 것이고 시스템에 대한 이해와 설계 능력을 갖추고 싶어한다. 하지만 R&B가 유행한다고 모든 가수가 R&B를 부르지는 않는다. 개발자의 진로에 있어서 테스트 엔지니어의 길도 하나의 새로운 선택이 될 수 있다고 생각한다. 기존의 잘못된 선입관으로 인하여 하찮은 업무로 분류되기도 했지만 IT 기업들의 인식이 바뀌어가면서 해당 분야에 대한 전문성이 더욱 중요해 지고 있다. 누군가는 아이폰의 멋진 모바일앱을 만들겠지만 누군가는 이 모바일앱이 완전해질 수 있도록 함께 기술을 공유하고 발전시킬 수 있는 것이다.

우리나라 같이 유행에 민감한 구조에서는 누구나 눈에 띄는 일을 하고 싶겠지만, IT의 균형적인 발전을 위해서는 해당 역할의 트렌드도 중요하겠지만 역할의 가치에 대해서도 고민해봐야 할 것이다. 언제나 유행은 다시 돌고 돈다.

웹이 대세일 때 모든 개발자가 자바만 할 줄 알면 된다고 생각했다가 스크립트가 그 역할을 대체하게 됐고 이제는 HTML5가 그 역할을 위협하고 있다. C/C++ 개발자들은 생계의 위협을 느끼게 됐지만 아이폰이 성공하면서 다시 그들의 역할이 중요해 졌다. 안드로이드 개발을 위해 스크립트 개발자들을 다시 자바 개발자로 전환시키고 있지만 웹페이지만 만들어봤지 애플리케이션을 만들어 본적이 없으니 개발하기가 쉽지 않다.