올해 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를 이상적인 실현이라고 말하기보다 현실적으로 개발자에게 그리고 프로젝트에 도움이 되는 실용적인 접근 방식으로 바라보는 지혜가 필요할 듯 싶다.
저작자 표시 비영리 동일 조건 변경 허락
신고

'Homo Faber > Concepts' 카테고리의 다른 글

TDD, CI, CD  (0) 2011.08.27
유스케이스의 상속  (0) 2010.02.10
"Less is More"  (0) 2009.02.24
유스케이스 드리븐 방식의 한계  (0) 2008.03.10
Abstract와 Interface  (1) 2008.03.04
자바에서 상속  (1) 2008.03.04
UML에서 상속은 classifier간에 사용할 수 있다. classifier에는 클래스, 액터, 유스케이스 등이 포함된다. 따라서, 유스케이스 간 상속(generalization) 역시 가능한 관계이다. 유스케이스 상속은 동일한 유형의 흐름이 존재하지만, 서로 다른 기능을 수행하는 경우에 상속을 통해 표현이 가능하다. 예를 들어, 은행의 계좌이체 기능은 ATM 앞에서 수행하는 기능과 텔레뱅킹, 인터넷 뱅킹 등에서 수행하는 계좌이체 기능으로 다양한 서비스로 수행되며, 이는 모두 계좌이체라는 동일한 작업을 수행한다.

이와 같이 계좌이체와 같은 기능을 상위 유스케이스로 식별하고, ATM 계좌이체, 텔레뱅킹 계좌이체, 인터넷 뱅킹 계좌이체 등으로 하위 유스케이스를 분류하여 모델링을 할 수 있다. 이때, 상위 유스케이스는 공통적이고 일반적인 유형의 흐름을 기술하고, 그 하위 유스케이스에서는 상위 유스케이스에서 기술한 내용을 확장하여 변이(variation)가 나타나는 부분을 세부적으로 기술하게 된다. 또한, 상위 유스케이스는 경우에 따라서 액터에 의해서 시작될 수 없는 추상 유스케이스로 선언이 가능하다. 즉, 아래와 같은 모델링이 가능하다.



위의 그림에서 고객 역시 상속 관계를 통해 좀 더 세분화시켜서 ATM 고객, 텔레뱅킹 고객, 인터넷뱅킹 고객 등으로 분류할 수 있다. 하지만, 각각의 액터들이 다른 특수한 행위를 수행할 때에는 세분화시키는 것이 의미가 있지만, 그렇지 않은 경우에는 세분화시켰다고 하더라도 그리 의미가 없을 수 있다.

유스케이스 기술은 상위 유스케이스인 '계좌이체' 유스케이스에서 '고객은 해당 서비스에 특화된 형태로 계좌번호를 입력한다.' 와 같이 일반적인 형태의 문장으로 표현되며, 하위 유스케이스에서는 '고객은 계좌번호를 입력기를 통해서 입력한다.', '고객은 계좌번호를 전화기 버튼을 통해서 입력한다.', '고객은 계좌번호를 키보드를 통해서 입력한다'와 같이 구체적인 행위가 기술된다.

일반적인 상속 개념과 같이 상위 유스케이스에서 기술된 내용을 그대로 사용한다면, '상위 유스케이스에서 기술한 대로 특정 기능이 수행된다.'와 같이 표현이 가능하다.

이러한 유스케이스 상속은 특정 서비스를 다양한 매체나 채널을 통해서 제공할 때 모델링하는데 사용할 수 있다. 하지만, 유스케이스 모델링에 대해서 익숙하지 않거나, 모델링 자체가 너무 복잡해질 경우에는 상위 유스케이스 표시를 생략하고, 유사한 유스케이스들에 대해서는 별도로 관리하는 형태로 그룹핑을 할 수도 있다.

이러한 유스케이스 모델링은 기능에 대한 분화/특수화에 대한 의미로만 한정해야지, 이를 시스템 내부의 설계와 연관지어서 유스케이스 모델링을 해석해서는 안된다.
저작자 표시 비영리 동일 조건 변경 허락
신고

'Homo Faber > Concepts' 카테고리의 다른 글

TDD, CI, CD  (0) 2011.08.27
유스케이스의 상속  (0) 2010.02.10
"Less is More"  (0) 2009.02.24
유스케이스 드리븐 방식의 한계  (0) 2008.03.10
Abstract와 Interface  (1) 2008.03.04
자바에서 상속  (1) 2008.03.04

독일의 Bauhaus 운동의 아키텍트이자 리더인 Ludwig Mies van der Rohe(1886-1969)가 한 말로, 최소주의 설계(minimalist design)의 모토로 채택된 개념이다. 그 의미는 단순성(simplicity)과 명료성(clarity)이 좋은 설계를 만들게 된다라는 것으로 현대 설계의 아키텍처의 단순한 형태(style)와 관련된 용어이다.

SW 아키텍처에서는 견실한(consistent) 아키텍처는 동일한 것에 대해 수행하는 두가지 이상의 방법을 제공하지 않는다는 것을 의미하며, 이는 사용자로 하여금 어떤 것을 사용할지를 선택하도록 강요하는 시간 낭비를 유발시킬 수 있기 때문이다.
따라서, 견실한 SW 아키텍처는 배우기가 더 쉽고 빨라야 하며, 일단 처음에 배운 내용을 거의 알지 못한다고 하더라도 그 나머지에 대해서는 쉽게 예상할 수 있게 구성되어야 한다.
특별한 경우에 대해서 염두하고 처리할 필요가 없이 코드는 더 깔끔해지고 테스트 코드는 더 적어야 한다.
저작자 표시 비영리 동일 조건 변경 허락
신고

'Homo Faber > Concepts' 카테고리의 다른 글

TDD, CI, CD  (0) 2011.08.27
유스케이스의 상속  (0) 2010.02.10
"Less is More"  (0) 2009.02.24
유스케이스 드리븐 방식의 한계  (0) 2008.03.10
Abstract와 Interface  (1) 2008.03.04
자바에서 상속  (1) 2008.03.04

+ Recent posts