검증용 코드의 필요성

by mycatdid0 2022. 8. 16. 19:36

(포스팅 2022.08.16)

- 목차
테스트 불가능한 개발 환경
어떻게 개발을 시작하는가
가상의 테스트환경
까다롭게 테스트
최대한 많은 디버깅 정보를 추가
또 하나의 문제
마치며

저는 대형 장비를 개발하는 연구소에서 일하고 있습니다. 일반적으로 사용하는 제품을 만드는 것이 아니기에, 여러분이 알고 있는 개발과 조금 다른 부분이 있습니다. 예를 들어 PC 또는 모바일에서 사용하는 프로그램을 개발하는 경우, 사용할 테스트용 환경을 이미 가지고 있는 경우가 많습니다. 실제로 동작시켜보면서 오류를 확인할 수 있습니다. 최신이 IDE는 디버깅하기 편리한 도구를 많이 제공합니다.

제품의 일부를 나누어 개발하는 경우, 각 부품의 개발이 완료되어야 제품으로서 테스트를 할 수 있게 됩니다. 실제로 동작해보며 개발하는 것이 불가능합니다.

이번 포스팅에서는, 그러한 환경에서의 개발에 필요한 것을 설명하고자 합니다.

테스트 불가능한 개발 환경

PC용 프로그램이나 모바일 앱을 제작하는 경우, 프로그램이 동작할 환경을 미리 확보하고 시작합니다. Visual Studio나 gdb에서 프로젝트를 관리하고 디버깅이 가능합니다. 개발 초기부터 프로그램을 실제로 동작시키면서 테스트를 할 수 있습니다.

어떤 프로젝트는 테스트할 수 있는 준비가 전혀 되어있지 않을 수도 있습니다. 대형 장비를 여러 회사가 나누어 개발하는 경우, 각 부품을 여러 회사에서 개발하고 최종적으로 이를 모아서 하나의 완성품을 만들게 됩니다.

부품 개발을 시작하기 전에 얻을 수 있는 정보는 스펙 문서나 전체 설계도 정도입니다. 이러한 정보만 가지고 개발을 완료하고 납품을 할 수는 있겠으나, 이것이 실제 조립할 때 정확하게 맞아 들어갈지는 장담하기 어렵습니다.

어떻게 개발을 시작하는가

테스트할 환경이 없는 상태에서 개발을 진행해야 한다면, 개발자가 취할 수 있는 행동은 아래와 같습니다.

가상의 테스트 환경을 만든다.
요구사항에 주어진 모든 조건을 하나도 빠짐없이 확인한다.
최대한 꼼꼼히 디버깅 정보를 넣는다.

정리해서 말한다면 '철저한 준비와 테스트'로 요약할 수 있습니다. 제품을 생산한 후에 수정하는 것은 많은 비용을 수반하기 때문에, 개발하는 동안 철저하게 준비하고 철저하게 검증해야 합니다.

가상의 테스트환경

테스트할 환경이 준비되어 있지 않다면, 테스트 환경을 자체적으로 만드는 수밖에 없습니다. 예를 들어 어떤 입력을 받아 결과를 출력하는 프로그램을 만드는 프로젝트라면, 아래의 프로그램을 모두 제작해야 합니다.

요구사항이 지정하는 입력을 하는 프로그램
요구사항대로 출력되는지 확인하는 프로그램

이러한 가상의 테스트환경의 목적이 제품을 검증하는 것이기 때문에, 경우에 따라 검증 부서에서 외부에 요청하여 준비하기도 합니다. 그렇더라도 어차피 개발에서 자체 테스트할 때에도 이런 환경이 필요하기 때문에, 보통은 개발기간을 산정할 때 테스트 환경을 개발하는 기간도 포함시켜 준비하게 됩니다.

까다롭게 테스트

테스트 환경을 아무리 잘 갖추어도, 납품처의 상황을 완전히 재연할 수 없습니다. 가능한 모든 상황을 가정하고 준비하는 것은 검증부서의 업무입니다. 그러나 조직이 작거나 검증자의 역량이 충분하지 않은 경우, 검증자가 준비하는 테스트 조건은 스펙 문서의 요구사항에서 크게 벗어나지 않습니다.

아래 동영상은 바람직한 ~~안타까운~~ 테스트의 예입니다.

바람직한 테스트의 예

검증에서 문제점을 미리 찾아내지 못하면, 납품 후에 문제가 발생합니다. 개발자가 측정장비와 노트북을 싸들고 클라이언트 회사에 찾아가서 디버깅을 해야 합니다. 검증자는 품질관리의 책임이 있으므로 클라이언트에게 사과해야 합니다.

최대한 많은 디버깅 정보를 추가

제품 내부에서 뿐 아니라 외부와 연동하는 과정에서 발생하는 문제도 많습니다. 외부와 연동하는 과정에서 문제가 발생하는 경우, 여러 회사가 서로서로 책임을 떠넘기려 합니다. 모든 회사들은 각각 자신의 제품이 문제 없다는 것을 증명해야 합니다. 개발과정에서 제품이 스펙대로 동작하는 것은 이미 확인했음에도, 클라이언트에게 문제없다는 것을 증명하려면 다음의 두 가지를 보여줄 수 있어야 합니다.

스펙에 주어진 대로 출력을 했는가
스펙에 주어진 대로 입력을 받았는가

대부분의 제품은 이를 위한 debug-port를 가지고 있습니다. 개발자는 가능한 많은 정보가 debug-port로 출력되도록 준비해야 합니다. 테스트에 필요할 시엔 debug-port를 통해서 커맨드를 입력할 수도 있어야 합니다. 되도록이면 외부로 출력되는 신호를 피드백하여 로그로 남길 수 있어야 합니다. 개발자의 융통성이 요구됩니다.

로그 수집까지 순조롭게 진행할 수 있다면, 나머지는 업체 간에 책임 넘기기 경쟁이 됩니다. 논리적인 설명이 가능하다면 개발자가 더 이상 고민할 필요는 없을 것입니다.

또 하나의 문제

현업에서 발생할 수 있는 또한 가지 문제는, 클라이언트가 자신의 요구사항을 잘못 이해하여 오류가 포함된 스펙 문서를 전달할 수 있다는 점입니다. 예를 들면 입력과 출력은 맞게 정의했는데, 과정을 잘못 정의하는 경우입니다.

많은 클라이언트가 자신이 실수했다는 생각을 하지 않습니다. 오류가 발생하는 과정을 눈으로 확인하고나서야 마지못해 인정합니다. 그래서 개발자는 제품이 동작하면서 진행하는 모든 과정을 로그로 남겨야 합니다. 클라이언트는 과정에 이상이 없다는 것을 확인하고 나서야 요구사항을 의심할 것입니다.

개발자로서는 억울한 점이 있지만, 클라이언트가 납품 서류에 사인을 해야 돈을 받을 수 있다는 걸 기억하세요.