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

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

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

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

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

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

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

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

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

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

Written By Michael Nygard

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

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

1차 번역 : 임 병수

2차 번역 : 손 영수


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

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

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

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중

카테고리

Articles, Books & Articles, My Activity, My Thinking, Software Engineering

태그

, , , , ,