본문 바로가기
Homo Architect

테스트, 이젠 옵션이 아닌 필수이다.

by javauser 2011. 7. 11.
프로젝트 진행 중에 수많은 산출물들과 수많은 작업들이 있지만, 가장 주요한 그리고 필수적으로 있어야 되는 작업과 산출물은 주로 설계과 소스 코드로 초점을 맞출 수 있습니다. 그 이외에 개발에 지연을 주는 요소들은 모두 선택적인 작업이나 산출물들이 됩니다. 설계 산출물 중에서도 대부분이 클래스 다이어그램을 중심으로 하는 정적 모델을 필수 산출물로 선정하고, 시퀀스 다이어그램과 같은 동적 모델에 대해서도 선택 산출물이라고 얼버무리는 경우도 많습니다. 기본적으로 다이어그램은 선택과 필수라는 식의 접근 방식보다는 해당 산출물이 어떤 이유에서 필요하며 어떤 결과물들을 내기 위해서 사용되어야 하는지에 대한 타당성이 먼저 있어야 하며, 그와 같은 결과물들은 내려면 시퀀스 다이어그램과 같은 동적 모델을 그릴 수 밖에 없는 설계 접근 방식을 채택해야 됩니다.

예를 들어, 클래스간 상호관계나 컴포넌트의 호출 관계 등을 파악하기 위해서는 정적모델로는 어느 정도 한계가 있으며, 시퀀스 다이어그램과 같은 동적 모델을 사용할 때 더 효과적으로 파악이나 설계가 가능합니다. 어느 한쪽으로만 치우친 설계는 실제 동작하는 SW의 본 모습을 보여주는 설계가 결과물로 나타나기 어렵습니다.

마찬가지로 개발 작업 중에서 소스 코드를 만드는 작업 이외에 (단위) 테스트 코드를 만드는 작업 역시 필수가 아닌 선택의 영역에 두어서 마치 테스트 코드는 없지만, 프로세스 상에서 단위테스트가 존재하는 듯이 위장하여 개발 프로세스가 이상이 없다는 식의 포장은 나중에 더 큰 화를 불러일으킬 우려가 있으며 현실적으로 많은 문제들을 포함하고 있습니다.

개발 작업에서 테스트 코드를 만드는 노력은 필요하며, 이는 분명 개발 작업에 부담이 될 수도 있습니다. 또한, 테스트를 위한 환경이나 다양한 장치들을 고려해야 하기 때문에 오히려 이에 대한 부담이 더 할 수도 있을 것입니다. 대부분의 개발자들은 이러한 방식을 좋아하지 않거나 소스 코드를 만드는 작업 이외에 테스트 코드를 만드는 작업에 대한 부담을 이유로 상당한 반발을 하는 경우도 흔합니다. 이때에 테스트 코드는 필수가 아닌 선택이라는 이야기로 얼버무리는 경우가 많이 있습니다.

하지만, 이와 같이 테스트를 선택적인 작업으로만 보기에는 이제 그 악영향이 너무나도 너무 많이 미치고 있습니다. SW는 이제 간단한 비즈니스 구현체가 아니라, 서로 복잡하게 얽혀있는 커다란 덩어리 형태로 존재하며 이를 예전과 같이 어느 한사람이 상세하게 머리 속에 그려놓고 그에게 의존하던 시대는 지났습니다. 그 누구도 전체 시스템을 혼자서 책임지지 못하며, 어느 한쪽의 문제는 전반적으로 영향을 미치는 형태로 시스템은 얽혀있습니다. 이러한 상황에서 테스트를 필수가 아닌 선택으로 두기에는 너무나도 많은 위험을 고객이나 사용자에게 그대로 노출시키는 결과를 초래합니다. 테스트에 대한 비용을 어느 특정 단계에서만 혹은 자동화 도구에 집중하기에는 위험 영역이 너무 넓게 퍼져있습니다. 차라리 특정 단계의 테스트 비용을 오히려 개발자들에게 투자하여 이들이 만들어내는 단위 테스트 코드의 품질을 더 높이게 만드는게 더 효과적일 수 있으며, 단위 테스트 코드를 형상관리할 수 있게 만드는게 비용이 덜 드는 전략일 수도 있습니다.

앞으로 클라우드 시대에서는 물리적인 HW에 대한 영역 확장 뿐만 아니라, SW 영역의 확장도 고려해 볼 수 있는데, 이는 통합/배포되는 SW가 충분한 품질을 보장할 때에만 가능합니다. 문제가 있는 SW를 배포했을 때 얼마나 이전 문제가 없는 상태로 다시 복원할 수 있는가가 클라우드 시대의 SW가 풀어야 할 숙제이며, 그 해결책은 테스트로부터 찾을 수 있을 것입니다.


* 제 4 회 SW 아키텍트 대회에서 위와 같은 내용으로 발표를 했습니다. 여기에 발표 자료를 공유합니다.
제4회_아키텍트대회_발표자료_Session19.pdf
반응형