요약: Scrum, Extreme Programming (XP), Crystal, Dynamic Systems Development Method (DSDM)와 LEAN Software Development (LSD) 같은 개발 방식 속에 함축되어 있는 애자일(agile) 기본 원리를 살펴보고자 합니다. 비즈니스는 끊임없이 변하는 고객의 요구, 시장 기회, 외부 위협들에 신속하게 대처해야 합니다. 비즈니스가 성공을 거두려면, SOA의 개발 방식부터 변화하는 요구 사항에 대처할 수 있어야 합니다.


머리말

저명한 사상가 Mark Colan이 정의한 ("Service-Oriented Architecture expands the vision of Web services, Part 1" 참조) 서비스 지향 아키텍처(SOA)는 적응성이 뛰어난 엔터프라이즈 IT 시스템을 구축하는 방식으로서 상당한 입지를 굳혀오고 있다. 목표는 확실하지만 그 목표에 다다르는 길은 확실하지 않다. 왜냐하면 SOA에 대한 이렇다 할 방법론이 없기 때문이다. 하지만 어느 정도는 기여한 바도 있다. (Methodology for SOA).

SOA를 구축하는 사람들은 두 가지 큰 도전에 직면해 있다. 1) 비즈니스 프로세스, 비즈니스 목표, IT 아키텍처에 두루 잘 맞는 시스템을 어떻게 디자인 할 수 있는가? 2) 미래의 변화에 대응할 수 있는 아키텍처를 어떻게 구현하는가? 두 번째 도전은 기민성 문제이고 일반적으로 애자일 소프트웨어 개발 방식이라는 테두리에서 논의되었다. 이 글에서, 우리는 SOA 디자인 방법론을 살펴 볼 것이다. 가장 기본적인 애자일 개발 방식을 검토하고, 그 다음에 "LEAN Software Development" (LSD)의 원리에 대해 살펴보고자 한다. 마지막으로 SOA를 구현하는 과정에서 LSD의 조기 분석에 대해서도 논하겠다.


SOA: 입문

SOA란 무엇인가?

IT 아키텍처, 특히 엔터프라이즈 레벨의 아키텍처는 비즈니스 프로세스를 지원하고 변화에 대응하는데 초점을 맞춰 구현되었다. 지난 몇 년 동안 시스템 아키텍처에 대한 새로운 방식들이 생겨났고 이 방식들은 서비스라고 하는 기능 단위에 복잡한 시스템을 구축하려는 시도를 했다.

최근에 서비스와 관련하여 네 개의 기본적인 측면들이 부각되고 있다:

  • 프로비저닝(Provision)
  • 소비(Consumption)
  • 디스크립션(Description)
  • 브로커리지(Brokerage)

이러한 측면들을 체계적이고 표준에 기반하여 지원하는 것은 웹 서비스가 함께 한다. 웹 서비스는 기민성이라는 독보적인 장점이 있다. 예를 들어, 웹 서비스 인프라에서 런타임 시 소비자에게 어떤 영향을 미치지 않고 서비스 공급자를 바꿀 수 있다.

스스로를 SOA 기반이라고 자칭하는 시스템은 다음과 같은 특징이 있다:

  • 비즈니스 프로세스는 소프트웨어 서비스로 매핑된다. 따라서 비즈니스는 소프트웨어로도 트래킹 할 수 있다.
  • 네 개의 다른 서비스 요소들을 지원하는 인프라가 있다. 이로서 서비스 차원에서 기민성이 높아진다.
  • 서비스는 모니터링과 관리 단위이다. 따라서 누구나 비즈니스 프로세스에 대한 작동상의 특징과 문제들을 트래킹 할 수 있다.

SOA 애플리케이션

그림 1은 애플리케이션의 관점에서 본 엔터프라이즈 SOA의 엘리먼트이다. 비즈니스 프로세스는 사용자 인터페이스 애플리케이션서비스 애플리케이션에 의해 부분 또는 전체적으로 지원을 받는다. 비즈니스 프로세스의 단계는 수동적이거나 사용자 인터페이스 애플리케이션에 의해 지원을 받는다. 사용자 인터페이스 애플리케이션은 많은 세세한 워크플로우들을 구현하고 비즈니스 기능을 갖춘 서비스들을 소비한다.

서비스 구성(service choreography) 레이어에서 합성 서비스(composite services)들은 BPEL(Business Process Execution Language) 같은 구성 언어로 정의된다. 합성 서비스의 구성법은 엘리먼트 서비스(elemental services)에서 흐름과 합성을 정의한다. 구성 레이어는 IBM WebSphere® Business Integration Modeler와 IBM Rational® Application Developer 같은 그래픽 구성 툴을 사용하여 만들어진다.

서비스 구성 레이어와 사용자 인터페이스 애플리케이션에서 사용되는 엘리먼트 서비스는 서비스 애플리케이션에 의해 구현된다. 서비스 구현은 다른 서비스들, 주로 다른 서비스 애플리케이션을 호출한다.


그림 1. CBDI Service Oriented Architecture Practice Portal에서 채택된 SOA의 엘리먼트


그림 1은 CBDI Service Oriented Architecture Practice Portal의 David Sprott과 Lawrence Wilkes의

 "Understanding SOA"에서 발췌한 것이다.

SOA를 위한 방법론

성공적인 SOA를 만드는 개발 방식은 어떤 모습일까? 이전 섹션에서 보았지만 비즈니스 프로세스, 애플리케이션, 서비스가 있다. 서비스 모델링은 확실히 그러한 방식의 기본적인 태스크가 될 것이다. 또 다른 중요한 측면으로는 비즈니스 프로세스와 서비스 간 연결을 보장하는 것이다. (What is SOA 참조)

"Elements of Service-Oriented Analysis and Design"에서는 Object-Oriented Analysis and Design (OOAD), 엔터프라이즈 아키텍처 프레임웍, 비즈니스 프로세스 모델링 기술 같은 기존 모델도 SOA 디자인에 기여한다고 설명하고 있다. 또한 서비스 구분과 집합, 비즈니스 추적 가능성, 기존 자산의 통합, 재사용 같은 방법과 기술 같은 추가 메소드 엘리먼트가 필요하다.

developerWorks 기술자료인 "Service-oriented modeling and architecture"에서도 위 질문들에 대한 해답을 제시하고 있다. 이 글은 서비스 모델링에 초점을 맞춰 설명하고 있는데, 영역 분할, 기존 시스템 분석, 목표 서비스 모델링 같은 기술을 사용한다.

위에 제시한 참조 문서에서는 이를 테면, SOA 거버넌스에 대한 궁금증을 유발하고 있다. 서비스 모델이 미래의 변화에 대처할 수 있으려면 SOA 개발에 어떤 규칙과 방법들이 필요할까? 라는 또 다른 질문이 생긴다. 그렇다면 다양한 애자일 소프트웨어 개발 방식을 생각해 볼 수 있겠다.

애자일 소프트웨어 개발

애자일 소프트웨어 개발은 90년대 후반에 시작되었다. 이 당시에는 Kent Beck이 소프트웨어 플래닝, 코딩, 디자인, 테스팅의 가치와 원리와 방법론을 통해 Extreme Programming (XP)을 선보였던 때이다. (Extreme Programming: A gentle introduction 참조)

모든 애자일 소프트웨어 개발 방식에는 여러 가치들이 있다:

  • 잦은 검사와 적용
  • 주기적인 배포
  • 협업과 긴밀한 커뮤니케이션
  • 반응적 향상
  • (점증적인) 요구 사항, 기술, 팀 기능의 탄생
  • 권한 부여와 자가 구성
  • 인도물이 아닌 현재의 것 다루기
  • 용기와 존경

오늘날 다양한 애자일 방식들은 각기 다른 방법들을 강조하고 있다.

2001년 2월, Agile Manifesto가 만들어지면서, 개인과 프로세스와 툴을 통한 인터랙션, 포괄적인 문서를 통한 소프트웨어 작동, 계약 협상을 통한 고객 협업, 플랜을 따르는 것 이상으로 변화에 대응하는 것 등에 가치가 매겨졌다. 이는 오늘날 사용되는 모든 애자일 방식의 토대가 된다.

먼저, 가장 일반적으로 사용되는 애자일 방식을 설명하고자 한다. 이들 중 많은 것들이 SOA 개발에도 유용하다. SOA는 소프트웨어 개발 그 이상이라는 것은 우리도 알고 있다. SOA는 비즈니스와 IT 아키텍처에 관한 것이기도 하다. 따라서 소프트웨어 개발 방식을 생각할 때면 언제나 이것이 SOA에 적합한지를 평가해야 한다. 적합성 평가에 대해서는 다음 시리즈에서 다루도록 하겠다.

Scrum

Scrum은 단순해 보이지만 작업에 영향을 주고 핵심적인 애자일 특징을 지닌 방식을 갖추고 있다. Scrum의 특징은 스스로 방향을 설정한 팀, 매일 매일의 팀 평가, 규정된 프로세스 지양이라는 특징이 있다. 다음은 Scrum의 기본적인 특징이다.

  • 스스로 방향을 설정하고 구성한 팀
  • 특별한 문제(무엇을 했는가, 무엇을 할 것인가, 문제가 무엇인가) 들을 주제로 한 매일 매일의 미팅
  • 30일 주기 반복
  • 매번 반복을 시작할 때 고객 위주의 적응성 플래닝
  • (각 반복의 끝에) 스테이크홀더에 기능을 선보임

엔터프라이즈의 경우, 프로젝트 간 의존성을 이해하고 관리하는 것이 중요하다. 이것은 Scrum에서 "글로벌 백로그(global backlog)"를 통해 잘 관리되고 있다. 이는 사용자가 가치를 두고 있는 기능적 요구 사항과 비 기능적 요구 사항을 엔터프라이즈 관점에서 본 것이다. 글로벌 백로그에서는 전체적인 우선순위가 정해진다. 각 프로젝트는 글로벌 백로그에서 자신들에게 가장 중요한 부분들을 취한다. 프로젝트 간 동기화 역시 Scrum of Scrums"에서 다루고 있다. 팀들간 동기화를 위해서 각 팀의 대표들과 이틀에 한번 또는 매주 미팅을 갖는다.

XP

XP (http://www.extremeprogramming.org와 http://www.xprogramming.com)는 협업, 빠른 소프트웨어 구현, 매우 기술적인 개발 방식을 강조한다. 이것은 주요 관행들(함께 앉기, 전체 팀, 정보가 풍부한 작업 공간, 짝(pair) 프로그래밍, 주간 반복, 여유, 10분 구현, 연속 반복, 테스트 우선 프로그래밍, 점증적인 디자인)과 부차적인 관행들(실제 고객 개입, 점증적인 전개, 뿌리 원인 분석, 공유 코드, 싱글 코드 기반, 협상된 범위 계약, 사용에 따른 비용 지불)로 구성된다.

Crystal

Crystal은 주기적인 인도(delivery), 긴밀한 통신, 반응적인 향상을 강조하는 방법론이다. Crystal의 특징은 다음과 같다:

Crystal에서 우선순위는 프로젝트 결과의 안정성, 개발 효율성, 규율 지키기 등이다. 프로젝트 팀은 7 개의 특징을 지니고 있다. (첫 번째 세 개는 Crystal의 핵심이고, 다른 것들은 안정성을 위해 필요한 것들이다.):

  • 잦은 검사와 적용
  • 주기적인 배포
  • 긴밀한 커뮤니케이션; 개인적인 안정성
  • 포커스
  • 전문 사용자들로의 쉬운 액세스
  • 자동화된 테스팅을 갖춘 기술 환경
  • 설정 관리
  • 잦은 통합

Dynamic Systems Development Method

The Dynamic Systems Development Method (DSDM)는 시스템을 구현하고 관리하는 제어 프레임웍을 제공한다. 촉박한 시간 제약을 맞추고 반복적인 Rapid Application Development (RAD) 성공을 위한 방법을 제시한다. 이 방식은 개발자 관점의 RAD 뿐만 아니라 효과적인 시스템 개발에 관심이 있는 모든 사람들의 요구들을 포용한다. 아래 리스트는 DSDM의 관리 원리이다:

  • 적극적인 사용자 개입이 필요하다.
  • DSDM 팀은 결정을 내릴 수 있어야 한다.
  • 목표는 제품의 주기적인 인도이다.
  • 비즈니스 목적에 맞추는 것은 인도물의 필수 기준이다.
  • 반복적이고 점증적인 개발은 정확한 비즈니스 솔루션으로 수렴되어야 한다.
  • 개발 시 모든 변경 사항들은 원상으로 되돌릴 수 있어야 한다.
  • 요구 사항들은 고급 레벨을 기반으로 우선순위가 정해져야 한다.
  • 테스팅이 라이프 사이클에 통합된다.
  • 모든 스테이크홀더들 간 협업이 필요하다.

Lean manufacturing

제조업은 두 가지 유형의 제조 문제가 있다는 것을 깨달았다. "Predictable manufacturing"과 "신제품 개발"이 바로 그것이다. 전자는 요구 사항들을 앞서서 알 수 있는 기능이다. 안정적인 스케줄링이 가능하다. 후자는 요구 사항들을 정확하게 정의할 수 없다. 프로젝트 과정으로서 지속적으로 순응 및 재평가 해야 한다.

Craig Larman은 이러한 문제들을 그의 책 Agile and Iterative Development 에서 비교했다:


표 1. Predictable manufacturing과 신제품 개발의 비교 
Predictable manufacturing 신제품 개발
먼저 스팩을 완성하고 구현하는 것이 가능하다. 앞으로의 불변하는 상세한 스팩을 만들기가 거의 불가능하다.
시작 단계에서 노력과 비용을 평가할 수 있다. 시작 단계에서는 불가능하다. 실질적인 데이터가 생기면 플래닝과 평가가 가능하다.
모든 상세한 액티비티들을 구분, 정의, 스케줄링, 순서를 정할 수 있다. 시작할 때까지는 불가능하다. 구현-피드백 사이클을 중심으로 채택 단계가 필요하다.
예기치 못한 변경에 적응해야 할 경우가 드물고 변경 비율도 비교적 낮다. 예기치 못한 변경에 적극적으로 적응해야 하는 것이 다반사이다. 변경 비율도 높다.

한 예로, Toyota는 1980년에 "LEAN Manufacturing" 방식으로 자동차 산업을 혁신시키기 시작했다. 낭비를 줄이고, 밸류 체인을 체계화 하며, 요청에 기반한 생산을 하고, 사람들의 요구에 초점을 맞추기 위해서였다.

LSD

Mary와 Tom Poppendieck은 제조 환경의 이러한 원리와 방식을 소프트웨어 개발 환경에 적용시켰다. (Web site 참조) 연속적인 향상을 통해 낭비를 규명하고 이를 줄여나가고, 비즈니스 가치를 점차 증대시키면서 결함과 순환 시간을 줄인다는 목표가 있었다. LSD의 토대는 Toyota, Dell, Wal-Mart가 채택한 표준 LEAN Manufacturing이다.

한 가지 중요한 포인트는 LSD는 XP, DSDM, SCRUM 같은 개발 방식이 아니다. 오히려, 개발 방식이나 프로젝트 방식과 관계 없이, 소프트웨어 개발을 향상시키기 위해 반드시 적용해야 할 근본 원리를 제공하고 있다. 이제부터는 LSD의 7 가지 원리와 툴을 검토해 보고자 한다.

Principle 1: 낭비 줄이기

낭비를 줄이는 것은 가장 근본적인 LEAN 원리이다. 다른 모든 원리들도 이 원리를 따르고 있다. LEAN 개발의 첫 번째 단계는 See Waste (코드의 품질을 향상시키지 않으며, 코드를 만드는데 드는 시간과 노력을 줄이지도 않고, 비즈니스 가치를 고객에게 주지도 못하는 것) 이다. 두 번째 단계는 낭비의 가장 큰 원인을 밝혀내고 이를 줄이는 것이다. 초기 스팩에서 정의된 45%의 기능들이 솔루션이 완성 및 인도된 후에 절대로 사용되지 않는다라는 충격적인 보고도 있다.

Principle 2. 교육 확대

기업이 소프트웨어 개발상의 문제에 봉착할 때면, 더욱 강력한 순차적 프로세싱으로 엄격한 규율을 적용하는 경향이 있다. 제어 이론이 말해주듯, 이는 나쁜 상황을 더 악화시킨다. 문제가 생기면, 가장 먼저 해야 할 일은 피드백 루프가 모두 제 위치에 있는지를 확인하는 것이다. 그런 다음에는 문제 영역에서 피드백 루프의 빈도수를 늘린다. 짧은 피드백 루프로 제어력이 강화되기 때문이다.

여러 명이 같은 작업을 할 때마다 "동기화"에 대한 필요성이 대두된다. 동기화는 복잡한 개발 프로세스에서는 기본적인 것이다. "반복(Iterations)"은 동기화의 핵심이자 결정의 실행 포인트이다.

Principle 3. 가능한 늦게 결정하기

개발을 시작하기 전에 요구 사항을 확립하는 것은 심각한 오류로 부터의 방어 수단으로 간주된다. 순차적 개발(폭포형)의 문제는 디자이너가 넓이 위주의 방식 보다는 깊이 위주의 방식을 취하게끔 한다. 하지만 실수의 지름길은 너무나 빠르게 상세를 파고드는 것이다.

동시 개발(모든 작업이 반복-분석, 디자인, 프로그래밍, 테스팅-내에서 수행됨)의 경우 고급 개념상의 디자인이 결정되자마자 가장 높은 가치부터 프로그래밍을 시작한다. 세부적인 요구 사항들이 만들어지지 않았더라도 말이다. 이러한 실험적 접근 방식은 한 방향으로 고정하기 전에 다양한 옵션들을 시도하면서 배울 수 있다. 하지만 동시 개발의 경우 개발자가 자신의 분야에 대해 충분한 전문성을 갖춰야 한다.

Principle 4. 가능한 빨리 인도하기

고객은 빠른 인도를 좋아한다. 이는 비즈니스 유연성으로 해석될 수 있다. 빠른 인도는 소프트웨어 개발에 있어 옵션 친화적인 방식이라고 할 수 있다. 불확실성을 줄이고 보다 사실에 기반한 결정을 내리기 전 까지 옵션은 열려있다.

비즈니스에 효과적으로 기여하려면 각 사람들이 무엇을 해야 하는지가 명확해야 한다. 누구든 비즈니스에 가장 효과적인 기여를 내려야 한다. 무엇을 할지를 명령하고("명령과 제어"), 스스로 설정("자가 구성")할 수 있도록 한다. 빠르게 움직이는 환경에서는 두 번째 옵션만이 유효하다. 효과적인 자가 구성을 위해서는 로컬 시그널링과 커밋먼트(information radiators사용하기 참조)가 개발되어 종합 시스템(Pull System) 형태로 작업을 조정해야 한다. 적절한 변화로는 복잡한 환경에서 효과를 거둘 수 없다. 초기에 상세한 플랜을 수립하는 것은 결정을 못박는 것을 의미한다. 플랜과 예견은 나쁜 것은 아니지만 추론에 근거하여 회복 불능의 결정을 내리는 것은 피해야 한다.

빠른 개발의 이점은 여러분이 생각하고 있는 것 이상이다. 다음 몇 년 안에 신제품 모델을 만들고 손익계산서(P&L)를 만들고 개발 결정을 내린다. 판매량(초기의 고가 가격 정책의 손실)과 마켓 쉐어(마켓 쉐어의 장기적 손실)에 지연이 어떤 영향을 초래할 것인지도 평가할 수 있다. 이 모델은 매출과 마켓 쉐어의 어떤 차이점이 이익을 창출하는지를 보여주고 있다.

Principle 5. 팀에 권한 부여하기

향상 프로그램은 작업이 수행되는 방식을 변화시키지 못한다. 작업 만족(성취, 인지, 책임감)에 기여하는 요소를 늘리는 대신 작업 불만족(정책, 감독, 관리)로 이끄는 요소를 강화하고 있다. LEAN 개념은 최전선 작업자들의 지능을 극대화 하고 그들 스스로가 작업하는 방식을 지속적으로 결정하고 향상시킬 수 있을 것이라고 믿어준다. 훈련되고 동기부여가 된 사람들 없이는 소프트웨어 개발은 성공할 수 없고 실험과 피드백이 처음부터 모든 것을 결정짓는 것 보다 효과적이다.

Principle 6. 무결성

제품의 컴포넌트가 맞고 작동이 잘 된다면 그 제품은 개념상 무결성을 갖추었다고 볼 수 있다; 아키텍처는 다음 항목들 간 균형을 맞춰야 한다:

  • 유연성
  • 관리 용이성
  • 효율성
  • 반응성

개념상의 무결성을 이룩하려면 제어 메커니즘을 멀리해야 한다. 다음과 같은 항목들이 권장된다:

  • 직접 논의
  • 소규모 일괄 처리
  • 속도
  • 흐름

시작부터 미래 경향을 예견하려고 하는 대신 넒이 위주의 접근 방식을 취하고 기본부터 바로잡아야 한다. 그런 다음, 세부적인 부분들이 생겨나고 아키텍처를 건전하게 유지하면서 주기적인 리팩토링에 기반하여 플래닝을 해야 한다. 리팩토링이란 어떤 "조짐"이 보일 때 라인을 중지하고(예를 들어, 신 기능을 추가하는 것을 중지하고) 시간을 갖고 문제의 뿌리 원인부터 찾아 해결하는 것이다.

리팩토링은 테스트 망이 안전하게 구축되었을 경우에만 가능하다. 테스트는 가능한 한 자동화 되어야 하고 평상시 구현의 일부가 되어야 한다. 그런 후에야, 시스템은 안전하게 복구되고 리팩토링 될 수 있다. 테스팅을 할 충분한 시간이 없다면 고객 테스트를 작성하는 요구 사항 문서에 들어간 노력들을 재할당 해야 한다.

Principle 7. 전체를 보기

시스템이 복잡해질수록 이것을 부분들로 나누고 로컬에서 관리하고 싶은 유혹도 강해진다. 로컬 관리는 퍼포먼스도 로컬로 평가하게끔 한다. 이러한 로컬 평가는 전체 퍼포먼스를 떨어트리는 효과를 만들어 낸다. 매일 매일의 태스크를 최적화 하는 것은 매우 나쁜 전략이라 할 수 있다.

지식만 가지고는 중요한 모든 것을 평가하는 것은 매우 어렵다. 특히 각 노력이 독창적인 것이고 불확실성이 내재해 있을 때 더욱 그렇다. 중요한 모든 것을 평가할 수 없다면 부분적인 평가가 로컬 관리로 변하기 쉽다. 전체적인 비즈니스 목표를 최적화하는데 필요한 모든 것을 평가할 수 없다면 부분적인 평가로 일부만 최적화 하는 것이 더 낫다.

프로젝트 관리자의 관점에서, 프로젝트를 관리할 때 조정할 수 있는 네 가지 변수가 있다. 시간, 비용, 품질, 범위가 바로 그것이다. 이러한 네 가지 변수에서 시간, 비용, 품질은 고정할 수 있지만 범위는 그렇지 않다. 기능의 우선순위를 정해야겠지만, 계약서에는 고정된 기능을 지정하지 않는다. 고정된 범위에서 협상 가능한 범위로 옮겨가야 한다. 높은 우선순위를 가진 기능을 먼저 인도하면, 여러분은 고객이 위시 리스트가 채 완성되기도 전에 최상의 비즈니스 가치를 실현한 것이 된다.

애자일 아키텍처

No big design up front

소프트웨어 개발 방식마다 프로젝트의 아키텍처를 개발하는 다양한 방식이 있다. Rational Unified Process (RUP)는 아키텍처 레벨의 리스크를 조기에 다룬다. ("리스크에 적극적으로 대처하지 않으면, 리스크가 여러분을 공격할 것이다.") 반면 XP는 "no big design up front"를 고수한다. Scrum은 미리 아키텍처를 충분히 정의하지만 기능의 우선순위 대로 아키텍처를 점증적으로 전달한다.

애자일 관점에서 보면 프로젝트의 초기에 모든 요구 사항들을 이해하고, 이들을 분석하며, 폭포식 모델처럼 전체 시스템의 아키텍처를 개발하는 방식은 권장되지 않는다. 초기 아키텍처 안정성과 변화 가능성 간 균형을 맞춰야 한다. 물론, 중요한 아키텍처 결정을 반복하여 수정하면 비용이 많이 든다. 하지만, 결정이 잘못되었고 변경된 요구 사항에 맞지 않는다면 결정을 초기에 수정하는 것이 낫다.

확인(verification) 보다는 유효성 검사(Validation)를..

어떤 방식을 사용하여 아키텍처를 개발하든지 간에 사용자의 기대에 맞게 아키텍처의 유효성을 검사해야 한다. (요구 사항을 기준으로 검사하는 것이 아니다.) 이러한 종류의 유효성 검사는 솔루션의 일부를 개발하여 이 아키텍처가 잘 돌아가는지를 보여주는 것이다. 아키텍처 골격에는 점증적으로 세부적인 살들이 붙는다.

아키텍처를 작동시킬 때

전통적으로, 초기 프로젝트 단계에 얼마나 많은 아키텍처를 작동시켜야 하는지는 개발팀이 결정한다. XP와 Scrum 같은 몇몇 애자일 개발 방식은 기능적/비기능적 요구 사항들을 보유해 두고 고객이 요구 사항의 우선순위를 정하게 한다. 고객이 비즈니스 가치와 중요성에 따라 요구 사항의 우선순위를 정하면 개발팀은 노력과 비용을 계산하고 아키텍처 리스크를 분석한다. 따라서 아키텍처는 이러한 요구 사항들과 함께 점증적으로 개발된다.

최근에, 아키텍처 작업을 수행하는 시기에 대한 결정은 기술적인 요소 보다는 비즈니스와 재정적인 요소에 기인하고 있다.Incremental Funding Method는 요구 사항들을 Minimum Marketable Features (MMF)로 나누고 아키텍처를 Architecture Elements (AE)로 나눈다. MMF와 AE는 다양한 재정적 목표들을 최적화 하기 위해 연속적으로 발생한다. (ROI 최대화, 현금 투입 최소화, 초기 플레이백) 클라이언트는 다양한 아키텍처 옵션과 재정 상황을 이해하고 평가한다. 개발팀은 모든 아키텍처를 초기에 개발할 경우와 점증적으로 개발할 경우의 재정적 측면을 이해하고 있다.

전통적인 방식과 초기 애자일 방식은 "greedy approach"을 취했다. 전통적인 방식은 가장 위험한 부분들을 먼저 처리하고 초기 애자일 방식은 가장 중요한 부분들을 먼저 처리했다. IFM은 고객과 개발 팀이 가장 가치가 있는 방식을 선택할 수 있도록 한다.

지속적인 서비스 리팩토링

SOA라는 정황에서 하나의 애플리케이션은 결코 독립된 애플리케이션으로 볼 수 없다. 서비스 애플리케이션에는 대한 다양한 사용자들이 있기 때문에 애플리케이션간 다양한 의존성이 존재한다. 어떤 서비스라도 다른 애플리케이션들에 의해 잠재적으로 재사용 될 수 있다. 따라서 서비스 애플리케이션은 재사용 가능한 제품으로 간주되어야 한다. 따라서 기민성은 점점 더 중요해진다. 해당 애플리케이션의 사용자 수가 늘어나기 때문이다. 엔드 유저 뿐만 아니라 애플리케이션이 다른 애플리케이션의 사용자가 될 수 있다. 사용자의 수가 늘어나면서 변화 가능성도 늘어나게 된다.

애자일 개발의 동력이 되는 SOA에는 한 가지 중요한 측면이 있다. 바로 서비스 모델-서비스의 모델, 이들의 의존성, 구성, 흐름-이다. 서비스 모델은 시간이 흐르면서 진화하고 서비스 인터페이스 정의도 진화한다. 기업은 서비스의 책임 소재가 올바르게 정의되지 않았기 때문에 현재 자신들의 서비스 모델이 약점을 갖고 있다는 것을 인식할 것이다. 이들은 하나의 서비스(또는 한 버전의 서비스)에서 또 다른 서비스로 이동하고 서비스 인터페이스를 수정해야 한다. 서비스 모델의 리팩토링은 필수적이며 애자일 소프트웨어 개발에서는 이와 같은 지속적인 리팩토링을 권장한다.

서비스 리팩토링은 하나의 서비스에서 또 다른 서비스로 책임을 돌려서 인터페이스를 수정하는 것을 의미한다. 이것은 서비스 모델을 사용하여 제어된 방식으로 수행될 수 있다. 서비스 모델은 SOA 환경에서 애자일 개발의 중요한 톨이 되고 있다. 이것 없이는, 서비스 리팩토링을 제어할 수 없기 때문이다. 우리가 서비스 모델을 갖고 있다면 애자일 소프트웨어 개발을 SOA 레벨로 확장할 준비가 된 것이다.

애자일 SOA에 대한 좋은 소식이 한 가지 더 있다. 기민성 관리가 더 쉬워지고 있다. 합성 서비스의 서비스 구성을 변경하여 비즈니스 프로세스에서 변경 사항들을 포착할 수 있다. 구성의 변화는 서비스 구현을 변경하는 것 보다 더 쉽게 활용된다.

맺음말

지금까지, SOA, 애자일 소프트웨어 개발, LSD의 개념을 설명했다. 애자일 또는 LEAN 원리와 방식이 서비스 아키텍처를 포함하여 아키텍처에 어떤 영향을 미치는지에 대해서도 알아봤다.

두 번째 시리즈에서는 LEAN 소프트웨어 원리와 SOA 개발을 혼합해 볼 것이다. 이렇게 혼합된 것들과 1편에서 다룬 애자일 아키텍처는 애자일 SOA 개발의 토대가 될 것이다.

감사의 말

이 글에 값진 조언을 주신 Olaf Zimmermann, Rick Robinson, Keith Jones, Norbert Bieberstein에게 감사의 말을 전하고 싶다.


[출처 : IBM http://www.ibm.com/developerworks/kr/library/ws-agile1/]

Posted by 필굳