왜 테스트와 검수 통과한 앱과 웹이 서비스에는 실패할까?

얼마 전 약 3000천 억 가량 개발비를 들여  개발된 4세대 교육행정시스템(나이스/NEIS)의 먹통으로 전국 학교 업무가 마비되었다는 뉴스가 나왔습니다. 이제 이런 뉴스는 새롭지 않습니다. 그럼 민간 개발은 다를까요? 몇 년 전 롯데온이 론칭되자마자 시작된 문제는 또한 많은 뉴스를 양상하였습니다.   

 

 

문제의 시작은 어디일까

 

분명 앱이나 웹 사이트가 공개되어 이용이 시작된 것은 개발이 끝난 것은 물론 테스트와 검수도 완료되었기 때문입니다. 그리고 이렇게 수 천 억 원의 개발비가 투입된 프로젝트인 만큼 테스트와 검수 또한 꼼꼼하게 진행되었을 것입니다.

 

그런데 일반 이용자가 쉽게 발견할 수 있는 너무나 당연한 오류를 테스트/검수 전문가들이 발견하지 못했다는 것은 언뜻 납득이 되지 않습니다.

 

그럼 이런 문제가 일어난 것에 대해 몇 가지 가설을 세울 수 있을 것입니다.

• 테스트와 검수가 형식적이었다
• 테스트와 검수가 이루어지지 않았다
• 테스트와 검수가 개발 시스템이 아닌 문서로만 진행되었다

 

내부적으로 어떤 일이 있었는지는 알 수 없지만, 결국 이런 가설을 세우게 만든 상황이 일어난 이유는 개발이 잘못되었다는 사실일 것입니다. 너무나 큰 개발 비용이 투입된 프로젝트인 만큼 잘못된 개발에서 파급되는 당장의 큰 문제를 피하려 하다 결국 서비스 때까지 문제를 숨겼던 것은 아닌가 추정됩니다.

 

 

문제의 시작은 설계에서

 

몇 천억 프로젝트는 해본 적이 없지만, 전체로는 천억에 가까운 민간 개발 프로젝트의 일부분 정도는 해본 적이 있기는 합니다.

 

그러나 규모의 크기와 상관없이 대부분의 개발 프로젝트의 문제를 파헤쳐 보면, 시작은 부족하거나 잘못된 분석/설계에서부터라는 공통점이 있습니다. 

 

규모가 클수록 시스템의 복잡도는 올라가고 일부 부족한 설계는 개발이 진행될수록 큰 문제 요인으로 변하게 됩니다. 여기에 잘못된 설계까지 있다면 개발이 될수록 문제는 걷잡을 수 없을 정도로 성장합니다.

 

DB 구성이나 함수와 변수 관계 등 실제 프로그램 될 부분의 설계 또한 초기 앱/웹 설계를 기반으로 진행되기 때문에 분석/설계의 문제가 개발에 문제로 나타나는 것입니다. 

 

그런데 분석/설계는 프로그램이 개발되어 테스트해 보기까지 알 수 없는 경우가 종종 있습니다. 이 또한 개발을 위한 설계가 부족해서 나타나는 현상입니다.

 

시스템 분석/설계가 부족하거나 잘못되었다면 이를 받아서 세부 개발 계획을 세우는 설계에서 걸러지게 됩니다. 그런데 이 설계 또한 부족하다면 대충 실 개발로 넘어가데 됩니다.   

 

결국 설계의 문제가 앱/웹이 론칭되고 사용자의 이용에서 나타나게 되는 것입니다.

 

이 경우도 설계의 문제를 인식하기는 어렵습니다. 사용자는 앱/웹 이용하면서 발생한 에러나 다운, 불편함 등을 개발 문제로 인식할 뿐입니다. 

 

 

그럼 테스트, 검수 시 왜 발견하지 못할까

 

천억이 넘는 시스템 개발 프로젝트라면 테스트나 검수에도 상당히 많은 인력과 전문성이 높은 사람들을 투입했을 것입니다. 그런데도 일반인인 사용자도 잡아내는 너무나 쉬운 문제를 잡아내지 못했다는 사실이 이해되지 않을 수 있습니다.

 

그럼 일단 테스트나 검수를 위한 계획서가 어떻게 만들어지는 것인지 이해할 필요가 있습니다.

 

테스트나 검수는 특정 시스템(앱/웹)을 대상으로 합니다. 롯데온 테스트/검수에 같은 쇼핑 앱이라 쿠팡에 대해 테스트/검수하지는 않습니다. 

 

그리고 당시까지 진행된 사항을 바탕으로 테스트/검수가 이루어집니다. 수만 줄, 수십만 둘이 넘는 코드에 대한 직접적인 테스트와 검수를 하기는 어렵습니다. 그러므로 설계 문서 및 개발 산출물로 제공된 문서들을 바탕으로 보통의 테스트와 검수를 진행합니다.

 

물론 코드나 함수, 라이브러리 또는 개발 모듈 등에 대한 테스트/검수를 직접 할 수 없는 것은 아닙니다. 그러나 이를 위해서는 사전에 기획이 준비가 되어 있어야 합니다. 그렇지 않다면 테스트/검수 자체가 개발 지연 요인이 될 수도 있게 됩니다. 이 또한 막대한 비용이 들어가는 프로젝트에서는 상당한 부담입니다. 시간은 인건비와 연결되어 비용이 되기 때문입니다.

 

 그렇다고 화면이나 기능에 대한 테스트와 검수가 불가능한 것은 아닙니다. 어차피 앱/웹으로 이용될 시스템이 론칭되어 사용자가 이용하는 것은 화면과 기능이기 때문입니다.

 

• 화면, 기능 테스트 조건

그러므로 화면과 기능 테스트만 잘 이루어졌어도 시스템 론칭 시 문제가 최소화될 수 있을 것입니다. 여기에 트래픽 상황에서의 연동 등에 관한 문제는 조금 다른 대응이 필요할 것이기는 합니다.

 

그럼에도 화면, 기능 테스트만으로 너무나 당연한 사용자들도 알 수 있는 일반적 문제는 잡아낼 수 있습니다.

 

그럼 화면, 기능 테스트를 위한 기본 조건은 무엇일까요? 아마 스토리보드라 생각하실 수 있습니다. 그러나 이는 맞을 수도 있고 아닐 수도 있습니다.  

 

천억 정도 되는 개발 프로젝트의 스토리보드의 양은 어마어마할 것입니다. 이를 보면서 테스트한다는 것은 불가능합니다. 아니 피상적으로 이루어질 수밖에 없습니다. 더하여 스토리보드 자체에 문제가 있는 경우라면 테스트 정확한 자체가 불가능할 것입니다.

 

그럼 스토리보드를 잘 작성하기 위해 무엇이 필요한지 생각하면 답이 나옵니다. 바로 기능/화면 정의서입니다.

 

기능 정의서에는 해당 시스템이 구현해야 할 기능 목록가 내용이 상세히 표시되어 있습니다. 더하여 기능이 작동될 때의 프로세스까지 설명되어 있습니다. 이 부분만 체크하여도 기능이 모두 시스템에 적용되었는지, 기능이 적절히 작동되는지 확인할 수 있습니다.

 

화면 정의서에는 사용자가 시스템을 이용할 때 앱/웹 화면이 모두 담겨 있습니다. 개별 화면의 구성은 물론 시스템 메뉴와 화면과 화면의 관계도 표시되어 있습니다. 이를 바탕으로 화면을 찾아 확인하고, 화면 UI 상태와 컴포넌트 반응을 체크할 수 있습니다.

 

결국 개발 규모가 크던 작던 적적한 테스트/검수팀이 투입되었음에도 문제가 있다는 것은 개발에 문제가 있거나, 개발도 잘 진행되었음에도 문제가 있는 것이라면 기획에서 잘못된 것입니다.

 

그런데 대부분 개발 프로젝트가 기획/설계 부분은 중요하게 생각하지 않고 넘어가는 경우가 많습니다. 실질적 개발은 코딩이라 생각하기 때문입니다. 그리고 기획자보다는 개발자(프로그래머) 확보에 더 신경 씁니다.

 

그러다 보니 크건 작던 앱/웹 시스템은 설계에서부터 크고 작은 문제를 않고 있는 경우가 대부분이니다. 규모가 작은 경우 복잡도가 낮으므로 경험 많은 개발자가 어떻게든 문제없이 프로젝트를 끌고 가기도 합니다. 그러나 일정 규모 이상 되면 개발자의 하드캐리로는 문제를 해결할 수 없게 됩니다.

 

종종 프로젝트를 하다 보면 형식적 테스트/검수를 하는 것을 경험합니다. 일단 문제 소지만 없으면 대부분 그냥 진행합니다. 그래서 테스트/검수가 실제 개발이 아닌 산출물 중심으로 이루어지기도 합니다. 그리고 이 산출물도 개발용이 아닌 보고용인 경우도 있기는 합니다.

 

• 설계의 중요성

아이폰 개발의 핵심 기업은 애플일까요 폭스콘일까요?

너무 당연하게 모두 애플이라 할 것이라 생각합니다. 그런데 애플은 아이폰의 설계 회사이지 생산 회사는 아닙니다. 아이폰의 핵심 AP 또한 애플이 아닌 TSMC가 생산합니다.

아이폰을 직접 만들지는 않지만 애플의 기획/설계가 없다면 아이폰은 나오지 않을 것이라는 것은 누구나 알고 있습니다.

 

그런데 앱/웹은 왜 기획/설계 없이 개발(생산)만으로 나올 것이라 기대할까요? 

거대 개발 프로젝트 중간에 테스트나 검수하러 온 인력이 짧은 시간 시스템을 모두 파악하고 완벽히 테스트/검수할 수 있다면 처음부터 이 인력이 들어와 개발했다면 문제없는 시스템이 개발되지 않았을까요?

 

결국 프로그램 코딩도 그러하듯 테스트와 검수도 애초 기획/설계에 영향을 받을 수밖에 없습니다. 

 

종종 시스템을 분석할 때가 있습니다. 저의 경우 기획자이므로 코드를 보지는 않습니다. 기획/설계 문서만 살핍니다. 그런데 기획 문서만 보더라도 왜 문제가 발생했는지는 금세 알 수 있습니다.