TDD, CI, CD

올해 Jolt Awards의 The Best Books에서는 6권의 최고의 책을 선정했고, 그 중에서 Jez Humble과 David Farley가 쓴 Continuous Delivery를 가장 최고의 책(Excellent Book)으로 선정했다. [관련 기사] 기사에서도 말했듯이 이책은 기존 Continuous Integration에서 코드로부터 할 수 있는 모든 것을 자동화시키는 개념을 더 확장하여(응용하여) 가상화(virtualization) 개념을 도입해 배포로 인한 무중단 서비스를 가능하게 하는 방식을 이야기하고 있다. CD에서의 테스트는 오로지 단위테스트(unit test)를 말하고 있으며, 그 테스트 수행 속도 역시 빨라야 한다. 즉, 단위테스트를 하는 범위(coverage)를 최대한 독립적인 비즈니스 영역으로 제한하고, 다양한 Test Double을 통해서 최대한 빠른 시간안에 테스트를 수행하는 것이다. 또한, 통합이나 UI 테스트는 이 단위테스트 범주에 놓기에는 다양한 문제들이 발생하기 때문에 CD에서는 acceptance test 단계에서 수행하는 것으로 이야기하고 있다.

TDD와 비즈니스 컴포넌트
TDD(Test Driven Development)에서는 단위테스트에 대한 다양한 방식과 방법에 대해서 거론이 되었고 또한 여러 기법들이 다양한 패턴 형식으로 나와있기 때문에 구체적인 내용들은 생략한다. 여기서 한가지 생각해볼 문제는 단위테스트를 어떠한 기준과 어떠한 범위를 다룰 것인지(cover)는 결국 비즈니스 로직에 대한 크기의 분류 기준과도 관련이 있다. 테스트에 대한 접근 방식은 비즈니스 로직을 담는 아키텍처에 따라서 다양해진다. 비즈니스 로직은 분석/설계 시점까지도 영향을 받으면서 구현 단계에서는 구체적인 덩어리 형태를 띠는데 이러한 비즈니스 로직 덩어리들을 컴포넌트라는 이름으로 부를 수 있다. 즉, 컴포넌트를 어떠한 기준으로 설계를 할 것인가에 따라서 단위테스트의 크기가 달라질 수 밖에 없으며, CD의 입장에서 TDD는 이러한 독립된 비즈니스 덩어리를 TDD를 통해 어떻게 효과적으로 검증을 수행할 것인가에 대한 영역으로 볼 수 있을 것이다.

Acceptance Test 단계에서 TDD는 BDD(behavior driven development)로 확장되어서 비즈니스 관점의 검증을 수행하도록 자동화되며, 여기에서도 역시 TDD에서 사용했던 다양한 패턴과 기법들이 사용되어야 한다. UI 테스트의 경우에는 Stub이나 Driver들을 적절하게 사용해서 효과적으로 테스트할 수 있어야 한다.

CI와 서비스
CI(Continuous Integration)는 독립적인 단위인 각 컴포넌트들을 어떠한 방식으로 묶어서 서비스를 제공할 것인가에 초점을 맞추고 있으며, 이러한 프로세스를 자동화시키는 관점에서 접근하고 있다. 서비스를 제공하기 위한 각각의 컴포넌트는 해당 서비스의 품질(Quality of Service)에 따라서 통합하는 방식이나 배포 방식을 달라질 수 있으며, 이는 운영 환경과도 밀접하게 관련이 있다. TDD는 인프라나 운영 환경과는 독립적으로 수행할 수 있는 방식을 초점을 맞추기 때문에 컴포넌트들의 의존관계를 그리 크게 영향을 받지 않지만, CI에서는 의존관계에 따라서 통합 프로세스에 영향을 미친다. 예를 들어, 외부 시스템과의 연동을 위한 EAI 솔루션 등에 대한 설정의 영역이 CI 프로세스에서는 중요한 단계 중에 하나가 된다. CI는 궁극적으로 서비스를 만들어내는 자동화된 프로세스를 고려하기 때문에 전체 CI 프로세스를 몇개의 하위 CI 프로세스로 나눌 수도 있다.

TDD는 개발자가 직접 다루는 영역이지만, CI는 개발자가 다루는 환경과는 독립적으로 구성해서 프로세스를 실행한다. 즉, CI에서도 단위테스트의 수행 속도가 영향을 미친고. 인프라의 구성과 개발 환경 등이 CI 프로세스에 영향을 미친다. CI 도구의 동작 방식을 비교적 단순하지만, 확장성을 보장해야 한다. CI 도구 차원에서 해당 프로세스를 충족시키지 못하면 다른 확장된 형태로 특정 프로세스를 충족시키도록 커스터마이징이 가능해야 한다.

CD와 클라우딩
CD를 도입하려는 궁극적인 목적은 기존 서비스의 무중단이며, 해당 서비스의 변경(업그레이드)이 서비스의 중단을 초래해서는안된다는 개념이다. CD를 실현하려는 방식은 현재로써는 해당 시스템의 인프라의 구성에 따라 전혀 다른 접근 방식을 취하게 된다. 하지만, 가장 이상적인 CD의 접근 방식은 클라우드 서비스를 제공하는 시스템에서 클라우드 접근 방식으로 시스템을 배포하는 것이다. 가상화의 개념이 운영 시스템에 도입됨으로써 자원을 효율적으로 사용하는 장점이 있는 반면에 배포에 있어서 상당한 부담을 가지고 온 것이 사실이다. 즉, 클라우딩의 실현에는 바로 CD가 뒷받침되어야 이상적인 클라우딩 서비스를 제공할 수 있게 된다. Jez가 말한 CD는 책에서 클라우드 환경에서 구현된 내용은 아니지만, 지금의 클라우드 환경에서 이를 구현하는 노력은 충분히 가능할 수도 있다.

개발 환경을 구성하는 개발자는 클라우드에서 서비스되는 각 개발 도구들(스마트폰의 앱과 같은 형태)을 로컬 PC나 노트북에서 다운받아서 해당 비즈니스를 구현하고, 이를 다시 또 다른 도구를 통해서 테스트를 수행하고, 형상관리 서버로 커밋을 처리한다. 개발자의 손을 떠난 배포 가능한 비즈니스 구현체를 관리자는 그 실행 가능성을 점검해보고자 해당 기능에 대한 간단한 테스트를 수행해볼 수도 있다. 이 과정에서 내부적으로 프로세스는 실행되지만, 사용자의 복잡한 데이터 조작이나 개발 내부를 들여다보기 위한 노력을 없앨 수도 있다. 또 다른 도구는 개발자가 구현한 내용에 대해 품질 검사를 수행함으로써 일정 수준을 유지하는지를 점검해볼 수도 있다. 여러개의 측정치들을 종합하고, 실행가능 여부를 판단하여 관리자는 최종 승인을 하여 배포를 위한 프로세스를 계속 진행해볼 수 있다. CD가 개발에서 배포까지를 이어주는 프로세스를 자동화시킨다고 하더라도 실제 조직에서는 배포를 위한 결재 프로세스도 여기에 추가되어서 운영하는게 더 현실적이기 때문이다.

가상화 인프라는 서비스를 무중단 상태로 업그레이드 하기 위한 장치로 활용될 것이다. 만일 변경된 서비스가 잘못이 있다고 하더라도 전체 시스템을 셧다운하는 사태는 발생하지 않을 것이며, 다시 이전 서비스로 복원하려는 절차 역시 자동으로 수행되어 사용하는 사람으로 하여금 그러한 변화를 못느끼게 할 수 있을 것이다.

 
Jez는 CD에서 TDD에 대한 단계를 Commit Stage에 포함시켰다. Commit 단계에서는 형상관리도구로부터 소스를 얻어서 Compile, Unit Test, Assemble, Code Analysis를 하는 과정을 담고 있으며, 그 결과를 Artifact Repository에 보고서, 바이너리 파일, 메타데이터 등을 등록(commit)하는 것으로 보고 있다. TDD에 Acceptance Test를 포함시킨다면, CD의 이후 과정인 Automated Acceptance Test를 별도로 나누어서 프로세스를 잡을 필요는 없지만, 이와 같이 두가지 단계를 분리함으로써 얻는 잇점이 많다. 우선은 빠른 빌드를 통해서 배포 가능한 시스템을 언제든지 다시 만들어낼 수 있으며, 복잡한 비즈니스 흐름이나 처리에 대해서 최소화시켜 단계를 진행해볼 수 있다. 어찌되었든 간에 CD에는 TDD에 대한 개념이 같이 포함되어 있다는 것이고 이는 CD를 강력하게 요구할수록 TDD의 입지는 확고해질 수 밖에 없다는 의미이다.

TDD를 바라보는 입장에서 복잡한 비즈니스 로직에 대한 단위테스트로써의 효용가치를 말하는 경우가 있는데, 이는 단위테스트를 통해 얻는 이점을 먼저 개발자가 발견한다면 단위테스트의 필요는 충분하리라 본다. 궁극적으로는 시스템의 검증을 어떻게 효과적으로 할 수 있을 것인가의 측면에서 TDD를 강조하지 않을 수 없으며, 이에 필적할 만한 다른 대안을 찾아보기 힘든 것도 사실이다. 이에 더해, CI나 CD를 이상적인 실현이라고 말하기보다 현실적으로 개발자에게 그리고 프로젝트에 도움이 되는 실용적인 접근 방식으로 바라보는 지혜가 필요할 듯 싶다.