한빛미디어

근래 테스트에 대해 잘 알아야겠다는 생각을 하고 있습니다. 잘 갖춰진 테스트 체계는 개발 조직에 학습 기회를 제공하는 피드백을 제공하게 되는데요. 적절한 피드백을 받는 조직에서 일하는 것만큼, 개발자의 자기 계발에 중요한 요소가 없다고 이해하게 되었기 때문입니다.

그 배경에는 작년 말에 읽었던 <디지털 트랜스포메이션 엔진>이 한몫을 했습니다. 기업가 정신이나 인수 합병과 같은 기업 행위 보다, 기업의 수익률을 높이는 요소는 "적절한 기술"의 사용이라고 했기 때문인데요. 이는 "고성과" 기술 조직의 뒷받침이 있어야 가능한 일입니다.

​

다시 말해, 고성과 기술 조직이 회사의 사활을 가를 수 있는 거죠. 고성과 조직은 고객의 요구사항이 빠르게 서비스로 반영되고, 그 과정이 대단히 안정적이며, 과정을 거친 다음 나오는 피드백이 조직의 학습에 도움이 되는 조직입니다. 여기에 지속적인 통합, 지속적인 배포 등의 기술과 함께 적절한 테스트 기법이 상당히 중요한 위치를 차지하고 있습니다. 그러니 테스트에 대해 관심을 가질만하죠.

​

우리가 가지고 있는 선입견에서 '테스트'는 제품을 만들어서 최종 출시 전 승인을 받는 정도의 역할을 하는 것입니다. 하지만 그건 애자일 방식의 테스트가 아닙니다. 테스트 주도 개발(TDD: Test driven development) 개념에서 볼 때 테스트는 선행으로 시작해야 하거든요. 여기서 문제가 발생합니다. 애자일이 왜 필요한지 이해하기 전, 무작정 테스트를 앞으로 보내는 게 맞는다는 강요를 받게 되면, 정말 테스트만 앞으로 보내려고 노력하다가 포기하게 됩니다. 테스트를 앞으로 보내는 건, 개발자 입장에서는 다른 방식의 사고로 개발을 하는 것을 의미하지만 개발 프로세스의 입장에서는 그만큼 자동화 기회를 얻겠다는 의미가 됩니다. 되도록 많은 테스트를 확보해야 코드를 유지 보수하는 과정에서 시스템이 안정적으로 변화하게 될 것이기 때문입니다.

​

반드시 필요하지만, 우리의 지식과 경험이 거부하는 상황이라 표현하면 될 것 같습니다. 그럼, 서로의 이해를 돕기 위해서, 전통적인 테스트 방법과 애자일 테스트 방법에 대한 적절한 비교를 통해서 고성과 조직이 어떤 방식으로 지속적인 학습을 도모하는지 이해하는 과정이 필요할 것 같습니다. 그게 이해된다면, 그다음 필요한 건, 우리가 서비스를 운용하기 위해 필요한 테스트들을 분야별로 나누고, 우리가 이해한 대로 기존의 테스트 프로세스를 바꾸는 작업이 필요하게 될 것 같은데요. <풀 스택 테스트>는 그 부분에서 필요한 책인 것 같습니다. 저자는 테스트를 분야로 나누고 각 분야 테스트가 어떤 의미를 지니는지 독자를 이해시킨 다음 관련 코드로 그 이해의 깊이를 깊게 해줄 설명을 보태는 방식으로 책의 내용을 꾸리고 있습니다.

​

그래서, "풀스택"이라는 용어보다는 모든 분야 서비스를 잘 설명한다는 다른 용어를 찾아서 책의 제목을 삼았으면 어떨까 하는 생각도 해보게 되더군요. "풀스택"이라고 하면 왠지 프런트엔드, 백엔드를 아우르는 테스트 정도로 이해되기 때문이죠.

​

회사에서 특정 기술을 도입하거나, 또는 우리 회사만의 독특한 기술을 문서화할 때 필요한 건, 특정 기술을 사용하는 샘플 코드 보다, 그 기술이 왜 세상 밖으로 나오게 되었는지, 그리고 그 기술은 어떤 이론적인 배경을 가지고 만들어졌는지 설명하는 내용입니다. 기술 블로그나 회사 내 문서를 볼 때마다 저는 이 부분의 결핍을 느꼈는데요. 이 책을 읽으면서, 이 책의 설명 방식이 하나의 샘플이 되면 좋겠다는 생각을 했습니다. 앞에서 말씀드린 것처럼 이 책은 왜 그게 필요한지를 먼저 설명하고 코드를 보여주는 방식으로 구성되어 있기 때문입니다.

​

우리가 복잡한 일을 해야 할 때 가장 중요한 준비가 일의 목록을 정하는 것입니다. 뭘 해야할지 먼저 정리해 둬야 막상 일을 하게 될 때 놓치고 하지 않는 불상사가 일어나지 않기 때문이죠. 문제는 목록을 작성하는게 그리 만만치 않다는 것입니다. 저는 이런 경우에 필요한 책이 <풀스택 테스트>와 같은 책이 아닐까 싶습니다. 읽어보시면 아시겠지만, 필요한 테스트를 설명하는 과정에서 그 테스트에 어떤 개념과 일이 필요한지 목록 정리를 잘해주는 부분들이 많이 보이거든요.

​

아참, "시각 테스트"에 대해서 설명하는 부분은 흥미로웠습니다. 로버트 C 마틴은 <소프트웨어 장인 정신 이야기>에서 GUI는 테스트하지 말라"고 직접 이야기 하고 있는데요. 이 책에서는 "시각 테스트"라는 장을 따로 나눠서 설명하고 있기 때문입니다. 하지만 어떤 면에서 기조가 비슷하다고 생각하게 되었습니다.

"따라서 시각적 테스트의 경우에는 명확하게 관련된 사용자 스토리가 있을 때만 적용해야 한다"라고 199페이지에 못박고 있기 때문입니다. 로버트 C 마틴도 GUI를 위한 유닛테스트는 필요없다고 설명하지만 화면을 그리는 프리젠테이션 컴포넌트를 테스트하지 말라는 것이지 여기에 '그릴' 데이터를 주입해주는 프리젠터에 경우에는 유닛테스트를 추가해서 TDD방식으로 구현하라고 설명하고 있습니다. 그렇다면 테스트를 마무리하는 시점에서 "사용자 스토리"가 있는 경우에는 "인수"를 위해 테스트를 추가할 필요가 생길 것 같습니다.

​

이 책은 한번 보고 끝나는 것보다 관련 업무를 할 때 다시 들춰보며 "목록" 확인을 하는 용도로 사용하면 꽤 유용하겠다는 생각을 했습니다.

​

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."