또다시 프로그래머 탓하는 정부와 삼성SDS

최근 전국 학교의 내신성적 석차를 처리하는 나이스(NEIS) 시스템의 오류로 인한 기사를 보셨을 겁니다. 수많은 학생들의 석차가 잘못 산출되어 혼란을 가져왔고 학부모/학생들의 불만도 대단하다고 하죠.

기사를 보고선 또 개발자들 탓하는 게 아닌가 하는 생각이 들었는데, 역시나 하단과 같은 기사가 등장했군요.

관련 기사: 나이스, 프로그램에 문제… 쓰레기값 처리 누락

잠시 옛날 일로 돌아가서, 2007년 9월에 제가 블로그에 올렸던 '정부의 디지털 회계예산시스템의 오류'에 대한 글을 한번 보시죠.

관련 글: 국가 회계예산시스템의 오류에 대한 단상

어떻게 된 게 4년전이나 지금이나 똑같네요. ㅠㅠ

1차적으로 개발자들이 프로그램에 버그를 발생시킨 건 사실이겠죠. 그런데 프로그래밍이란 게 사람이 하는 일이고, 또한 대개의 개발자들이 자신이 짠 프로그램에 대해서는 정상적인 입출력만 테스트하고 예외적인 값에 대한 처리나 테스트에 취약한 경향이 있습니다.

극히 소수의 최상급 개발자라면 모르겠지만, 대부분의 개발자들은 자신의 짠 코드의 양에 비례해서 일정 수준의 버그를 발생시키는 경향이 있습니다. 거기에다 복잡한 수식이 많을수록 버그가 발생할 가능성은 기하급수적으로 높아지게 됩니다.

그것이 바로 소프트웨어 프로젝트의 본질적 특성입니다.

그렇기 때문에 테스터들과 품질 매니저가 프로젝트의 초기에 합류해서 테스트 계획을 작성하고 개발 진도에 따라 지속적으로 테스트를 하고 프로세스에 의한 철저한 품질관리를 해야 합니다.

더군다나 나이스 시스템처럼 수식 계산이 중요한 경우에는 아주 집중적으로 관리를 해야겠죠. 주요 케이스들에 대한 테스트만 제대로 했다면 충분히 잡을 수 있는 게 이런 유형의 버그입니다. 수식 계산이 복잡할 수록 개발할 때 버그가 생기기 쉽지만, 수식 계산이라는 게 입출력이 정직하기에 테스트 하기도 쉽고 그만큼 버그도 잘 잡힙니다.

미국, 일본 등과 같은 소프트웨어 선진국들에서는 코드 작성 그 자체보다 품질 관리를 더욱 중요하게 생각합니다.

실례로 제가 미국의 한 회사와 잠시 일했을 때, 개발자 1명당 테스터 4명을 할당하여 빌드와 테스트를 매일 같이 함께 하는 걸 경험한 적이 있습니다. 단순 테스터뿐만 아니라 테스트를 위한 코드를 작성하는 테스트 개발자(Test Developer)도 있었습니다. 그렇게 한다고 하더라도 자잘한 버그까지 100% 잡을 수는 없지만, 적어도 심각한 버그는 다 잡을 수 있습니다.

주요 기능에 대한 테스트 케이스, 입출력 결과값 등을 모두 프로세스화해서 관리하고 충분한 리소스를 투입하기 때문에 가능한 일입니다.

그러므로 ‘프로그래머가 프로그램을 잘못 짜서 이런 일이 생겼다’는 건 사실상 다음의 두 가지 중 하나를 뜻합니다.

A. 프로젝트에 적절한 테스트 인원과 품질 매니저가 제대로 배정되지 않았다.

B. 프로젝트에 적절한 테스트 인원과 품질 매니저가 배정되었지만, 어떤 이유로 인해 제대로 업무를 수행하지 못했다.

개인적인 의견으로는 A일 가능성이 높다고 봅니다. 촉박한 일정에, 부족한 예산에, 제대로 된 인력 배정 없이 개발자들만 쪼았을 가능성이 큽니다. 그러다 일정에 쫓겨 충분한 테스트도 못한 채로 출시했을 겁니다.

지금 이 순간에도 정말 당연히 필요한 테스터와 품질 매니저의 지원을 받지 못하며(소프트웨어 선진국들에서는 있을 수도 없는 일입니다) 열악한 환경에서 개발하고 있는 개발자들이 많습니다. 버그를 만들었다고 손가락질 받으면서요.

4년전이나 지금이나 나아진 게 없는데요. 이런 식이면 40년이 흘러도 마찬가지일 겁니다.

이번 일을 계기로, 소프트웨어 프로젝트에 제대로 된 인력 배정이 있기를 바랍니다.

개발자는 만능선수가 아닙니다. 소프트웨어 프로젝트에는 아키텍트도 있어야 하고 테스터, 품질매니저도 반드시 필요하며, 그들이 함께 협업하며 일할 수 있는 일정과 환경을 제공해 주어야 합니다.

이번 나이스 스캔들과 같은 기사를 다시는 보지 않았으면 좋겠습니다.

관련 글: SI업계의 갑을병정, 그 죽음의 순환고리