대부분의 시스템은 모듈간의 유기적인 관계속에서 돌아간다. 그리고 각 모듈들은 해당 담당자가 존재하며 이들이 문제가 발생하였을때 디버깅을 수행한다. 명확한 버그나 이미 알려진 버그는 해당 모듈자가 디버깅 하면 된다. 하지만 새롭게 발생한 버그나 에 대해서는 다르다. 특히나 모듈들간의 관계가 밀접할수록 어느쪽 문제인지 찾기가 어려워져 이것을 디버깅 하는건 어려운 작업이다.

디버깅 하기 어려운 작업을 예를 들면 이런 경우다. A, B, C, D 4개의 모듈이 존재한다. 실제로는 A모듈이 문제였지만 이것이 B모듈에 영향을 끼쳐 C모듈이 오동작 하도록 하였고 D모듈에서 경고나 에러 메시지를 뿜어내는 경우. 게다가 특정 시점에 발생한다는 시나리오도 없고 2~3일에 한번 정도로 문제가 발생한다면 만만치 않은 디버깅 작업이 될것이다. 아마도 이런 경우 에러 메시지를 뿜게 한 D모듈의 담당자가 디버깅을 수행해야 할 확률이 높다. 자신의 모듈이 문제가 없다는걸 증명하기 까지의 시간, 문제가 있어보이는 해당 담당자와의 회의 시간, 타 모듈에 대한 이해를 높이기 위해 문서 열람과 소스 참고에 걸리는 시간 상당히 피곤한 작업이다. 근본적인 원인은 A모듈에 있었다고 증명하는것은 전체 시스템에 대한 이해가 높은 사람이 아니라면 어려운 일이다.

모듈 검증 도구가 있다면 어떨까? 모듈 검증 도구란 모듈 담당자 자신의 모듈이 정상적으로 돌고 있다는 것을 증명할 수 있는 프로그램을 의미한다. 만약 locking을 담당하는 모듈이라면 critical section에 하나의 프로세스만 접근하고 있다는것을 검증한다. global locking을 수행하는 모듈이라면 전체 클러스터에서 exlusive lock을 한 노드만 가지고 있다는 것을 검증한다. thread 관리 모듈이라면 thread들의 동작상태를  통신 모듈이라면 하위계층 쪽에서 프로토콜 검증을 하여 통신에 문제가 없음을 검증한다(ethereal 같이 network버퍼 접근). 이것들의 목표는 최소한의 모듈 역할 검증을 하는것이다. 이 최소한의 검증으로 문제 발생시 고려해야 하는 부분을 최소한으로 줄일 수 있어 문제 접근이 수월할 수 있다.

물론, 에러처리를 잘 하거나 테스트툴을 이용하는 것이 좋은 방법이긴 하지만 현실적으로 적용이 어려운 상황이 많다. 일정 데드라인에 쫒겨 다양한 테스트가 이뤄지지 못하였거나 테스트툴이 너무 비싸다거나 에러처리 귀차니즘이 발동한다거나. 그리고 기능을 추가하거나 수정하면서 코드는 계속 업데이트 될 수 있고 O/S 패치나 타 O/S로의 포팅 등 환경은 언제나 달라질 수 있다. 코드 변경이나 환경 변경이 이루어 졌을때 모듈 검증 도구를 이용하여 최소한의 검증을 하고 문제 발생시엔 근본적인 원인에 보다 접근이 용이할 것이다.

구현 방법은 최대한 단순하고 독립적이야 한다. 왜냐하면 검증 도구도 역시 프로그램일뿐 이것이 또 다른 side effect를 가질 수 있고 메인 프로그램의 잘못된 영향을 받을 수 있기 때문이다. 그렇기 때문에 메인 프로그램 안에서 assert와 같은 검증은 좋지 않다. 검증만을 위한 thread나 아예 분리된 디버깅 모듈로 작성되야 한다. 왜 문제가 발생했는지를 찾기 위한 디버깅 프로그램이 아니라 해당 모듈 동작에 문제가 있냐 없냐를 검증하는 프로그램이라고 생각하고 작성하는것이 좋을 것 같단 생각이다.

겉으로 보이는 현상은 전부가 아니며 간단한 문제가 아니라고 판단되면 모든걸 의심해야 한다. 버그없는 100% 완벽한 프로그램은 없다고 한다. 그런 현실속의 프로그램 모듈이라면 그것들의 각각에 대한 검증 도구는 필수적이다. 이것은 모듈 담당자들에게 하나의 무기가 될 수 있으며 진정한(?) 모듈화라면 모듈 검증 도구도 가져야 한다는 생각이다.

요약해서 모듈 검증 도구의 장점
1. 디버깅 시간 감소
2. 문제 발생시 책임소재 명확
3. 장시간 삽질로 인한 개발자 정신적 타격 회피
4. 담당 모듈 집중 개발로 인한 해당 모듈 완성도 상승
5. 회사 매출 증대(?)