우리는 종종 소프트웨어 공학을 고층빌딩,댐  또는 도로를 만드는 것에 비유하는  것을 들을 수 있습니다. 몇몇 중요한 측면에서는 사실입니다.

도시 공학에서 가장 어려운 부분은 한번에 완성되는 빌딩을 설계하는 것이 아니라, 건축 과정을 이해하는 것입니다. 건축 과정은 황량한 땅에서 완공된 빌딩까지 진행됩니다.  그 사이에, 모든 작업자는 각자의 업무를 책임감을 가지고 수행할 수 있어야 하며, 모든 공사기간 동안 완공되지 않는 구조체는 지탱해야 합니다. 우리는 거대한 통합 시스템(완공된 빌딩)을 배포하는 시점에서 교훈을 얻을  수 있습니다. (여기서 “통합”이란 단어는 거의 모든 엔터프라이즈 및 웹 어플리케이션을 포함합니다.!)

전통적인 “빅 뱅(big bang)” ¹방식의 배포는 대들보(집과 지붕을 받치는 큰 보)와 들보(하중을 지탱하는 구조물 ) 더미를 쌓아 올려, 높이 올린 다음(공중으로 집어 던진 다음), 건물 형태대로 잘 이어 붙기를 기대하는 것과 같습니다.

대신에, 하나의 컴포넌트를 하나씩 배포하는 계획을 짜야만 합니다.  교체 (신규) 프로젝트 이든, 그린필드 프로젝트²(1.새로운 공장의 건설 혹은 생산을 위한 새로운 수단의 마련 2.미개발 사업)건 간에 컴포넌트를 하나씩 배포하면 얻을 수 있는 두 가지 큰 장점이 있습니다.

첫 번째로, 소프트웨어를 배포할 때, 코드 안에  포함되어 있는, 축적되어 있는 기술적  위험성을 스스로 파악할 수 있습니다. 한번에 하나의 컴포넌트를 배포함으로써, 장 기간에 걸쳐 기술적 위험을 분산 시킬 수 있습니다. 모든 컴포넌트가 생산과정 중 개별적으로  실패할 수 있기 때문에, 각각의 컴포넌트가  독립적으로 구성되도록, 만들 수 있는 좋은  기회를 제공합니다.

두 번째의 커다란 이점은 컴포넌트간  잘 정의된 인터페이스를 생성할 수 있도록  우리가 집중할 수 있습니다. 새로운 시스템의 개별  컴포넌트 배포는 종종 오래된(레거시) 시스템과의  역 통합을 의미합니다. 그러므로, 배포가 끝나는  시점이 되면, 각각의 컴포넌트는 서로  다른 두 개의 시스템 : 레거시(원래) 시스템과  교체(신규) 시스템 – 과 함께 동작합니다. 컴포넌트가 재사용 되기 전에 어떤 것도 재사용 가능 하지 않기 때문에, 구분적인 배포는 자동적으로 더 큰 재 사용 성을 의미합니다. 실제적으로, 이러한 행위는 또한 더 나은 응집도와 낮은 결합도를 가지도록  이끕니다.

바꿔 말하면, 몇몇 중요한 방법이 토목공학과의  비유 속에 있다는 것이 우리를 잘못된 방향으로  이끌고 있습니다. 특히, 실 세계의 구체성은 우리를 항상 폭포수 모델³로 향하도록 만듭니다. 결국, 그 누구도 어디로 가고 있는지, 얼마나 커야 하는지 알지 못한 체 마천루(소프트웨어)를  만들기를 시작합니다. 기존 건물에 층을 추가(새로운 기능을 추가)하는 것은 비용이 들고, 파괴적이며, 위험해서, 우리는 새로운 층(새로운 기능)을 추가하는 것을 꺼립니다. 한번 설계되면, 마천루(소프트웨어)는 위치나 높이를 바꾸는 것은 불가능합니다. 마천루(소프트웨어)를 확장할 수 없습니다.

우리는 도로에 쉽게 차로를 더 낼 수는 없지만, 소프트웨어에 쉽게 기능(Feature)을 더하는 방법을 배웠습니다. 이것은 우리의 소프트웨어 개발 과정의 결함이 아니라, 소프트웨어 개발의 미덕입니다.   몇 가지 기능이 동작하는 어플리케이션에 사용자의 가치(피드백)을  받을 수 있다면,  단지 몇 가지 기능을 수행하는 어플리케이션을 릴리즈 하는 것도 괜찮습니다. 사실, 당신이  어플리케이션을 일찍 릴리즈 하면 할 수록, 모든 기능의 현가(현재의 가치)는 증가합니다

“초기 릴리즈”는 “점진적인 릴리즈”와 경쟁하는 것처럼 보일 수  있지만, 매우 잘 들어 맞을 수도  있습니다. 개별 컴포넌트의 초기 릴리즈는 각각의 컴포넌트가 독립적으로  이터레이션하여  개발할 수 있다라는 것을 의미합니다. 사실, 이런 개발방식은 당신이  배포와 프로토콜 버전들을 관리하는  동안, (시스템이 중지되지 않고 동작해야 하는) 가용성(availability)과 같은 고통스러운 문제를  만들 수도 있습니다.

높은 상업적 가치와 더 나은 아키텍쳐의 질을 동시에 제공하는 기술을 찾기 힘듭니다. 하지만 개별 컴포넌트의 조기 배포는 두 마리의 토기를 다 잡을 수 있게 해줍니다.

Written By Michael Nygard

이 자료는 Creative Commons Attribution 3 라이센스를 준수합니다.

(실제 서적을 번역한 것이므로, 위 Wiki 원본과는 번역 내용이 상이할 수도 있습니다.)

1차 번역 : 임 병수

2차 번역 : 손 영수

---

¹ 빅 뱅(Big Bang)은 빅 뱅 테스팅(Big Bang Testing) 의 방법론에서 나온 단어로, 통합 테스팅을 할 때 모든 각각의 모듈들을 개별적으로 코딩하고 테스팅 한 후 이를 통합 테스팅을 위해 전체로 조합하는 방법론을 의미한다. 여기서는 각 부분 부분을 먼저 만들고 이를 설계대로 한 꺼번에 붙여서 완성하는 배포 방법론을 의미한다.

² 그린필드 프로젝트(Greenfield Project) 는 기존의 프로젝트에 의해 영향이나 제약사항을 받지 않는 새로운 형태의 프로젝트를 의미한다. 원래는 무선 통신 분야의 용어로 기존 네트워크에 제약을 받지 않는 네트워크를 의미하나,  근래에 들어서는  소프트웨어 공학을 넘어서 전 방위적으로 사용되고 있다. 세일즈 분야에서는 완전 미개발된 자유 시장을 의미하기도 한다.  http://en.wikipedia.org/wiki/Greenfield_project 에서 자세한 내용을 참고하길 바란다.

³ 폭포수 모델(Waterfall Model) 은 소프트웨어 공학에서의 가장 오래된 개발 방법론 중 하나로, 1979 Boehm에 의해 개발된 하향식 생명주기 모델이다.  특징 점으로는 앞 단계가 끝나야 다음 단계로 넘어갈 수 있으며, 단계별 정의가 분명하고 단계별 산출물이 명확하다. 최근에 있어서 그 트렌드가 많이 바뀌고 있기는 하나, 소프트웨어 개발에서 가장 폭넓게 적용된다