오픈소스 개발방법론
오픈소스 세계에서의 개발은 기존 사유 소프트웨어 개발과는 전혀다른 방식을 사용합니다.
이 페이지에서는 소프트웨어공학에서 뻗어나온 오픈소스 개발방법론을 살펴봅시다.
오픈소스 개발방법론
개발방법론의 등장배경
소프트웨어를 개발한다는 것은 정신적인 노가다의 연속이라고 볼 수 있다. 표면적으로는 아주 간단해보인다. 클라이언트(고객)의 요구에 맞는 구동되는 소프트웨어 코드를 짜서 팔면 된다. 요점은 잘 작동되는 코드라는 점이다. 알다시피 소프트웨어는 형체가 없다. 형체가 없는 존재를 정의하고 만든다는 것이 어렵다는 것은 불보듯 뻔한 일이다. 게다가 일의 진행상황도 알기 어렵다. 코드가 완성되기 전까지는 어디까지나 완전히 작동되지 않는 상태이기 때문이다.
예를 들어 케이크를 만드는 과정을 보면 밀가루 반죽 - 케이크 빵 틀에 반죽과 과일 넣기 - 오븐에 굽기 - 식히기 - 표면에 생크림과 장식하기의 순으로 이루어 진다. 여기서 반죽을 만드는 과정까지 했다면 진행의 초기단계, 오븐에 굽는 단계라면 중간단계임을 손쉽게 알 수 있다. 다만든 다음에 문제가 발견되서 처음부터 다시 해야하는 경우는 드물다. 왜냐하면 각단계에서 문제가 생긴다면 결과물이 있으니 알 수 있기 때문에 그 단계에서 고칠 수 있기 때문이다. 가령 밀가루가 상했다면 반죽단계에서 알 수 있기에 시정하면 되고 빵이 탔다면 굽는 온도가 높았으니 온도를 조절한 뒤 처음부터 다시 하면 된다. 다 완성해서야 문제를 알게되는 경우는 없다고 봐도 무방하다.
그러나 프로그램 개발은 그렇지 않다. 간단한 문법오류라면 개발과정에서 디버깅을 통해 고칠 수 있다. 일부의 논리 오류는 모듈화를 통해 프로그램을 나누어 실행해서 오류를 찾을 수 있다. 하지만 당연히 이걸로는 부족하다. 결국 중요한 문제들은 프로그램 전체를 가동해봐야 나타나기 마련이고 만약 중대한 문제가 발생 혹은 발견될 경우 처음부터 다시 해야할 수도 있다. 심지어 고객에게 프로그램이 전달된 후에 문제가 발견되기도 한다.(비일비재하다. 그래서 유지보수를 한다.) 아래의 리포트에서 볼 수 있듯이 소프트웨어 개발에서 32%만이 정해진 개발기간을 지켰다.
카오스레포트문제는 여기서 그치지 않는다. 오류를 고치고 하는데 시간만 드는 것이 아니기 때문이다. 프로그램 개발의 노동력은 당연히 공짜가 아니기에 시간이 늘어난다면 개발비용도 당연히 증가한다. 자본주의 사회에서 투자비용이 늘어난다는 것은 그만큼 이윤이 감소하는 리스크가 늘어난다는 뜻이고 이만큼 매리트 경우는 없을 것이다. 당연히 문제가 된다. 게다가 시스템이 커지기 시각하면서 이 문제는 더욱 도드라 졌다. 하드웨어는 '무어의 법칙'(마이크로 칩의 밀도가 2년에 2배씩 늘어난다는 법칙)을 착실하게 이행에 이행해 가며 성능은 높이고 가격은 낮춰가고 있던 반면에 이런 하드웨어를 돌려야할 소프트웨어는 아이러니하게 점차 할 일이 많아지면서 개발비용과 시간도 덩달아 상승한 것이다.(이를 흔히 'software crisis', 소프트웨어 위기라고 하는데 시스템의 대규모화에 따라 개발비 증가, 계획 지현, 신뢰성 저하로 개발 수행이 매우 곤란해짐을 뜻한다. 1968년 NATO 소프트웨어 컨퍼런스에서 처음 쓰였다.)
여기서 개발방법론이 등장한다. 소프트웨어 개발방법론은 이런 막막함을 조금이라도 해결해보려는 의도에서 자연스럽게 만들어졌다. 만드는 과정의 틀이 어느정도 주어지면 개발과정에서의 문제들을 쉽게 발견하고 해결해 나갈 수 있지 않을까하는 것이다. 개발방법론이 대두되기 시작한 시기는 1980년으로 점차 시스템이 비대해져가면서 전체 컴퓨터 가격에서 소프트웨어의 가격이 20%이던 1955년과 달리 80%에 달하던 때이다.
여기에 더해 소프트웨어 개발문제를 해결하는데 있어 이를 하나의 학문으로 연구하려는 움직임도 있었다. 이 분야는 '소프트웨어 공학'이라는 새로운 분야로 자리잡아갔는데 다른 공학분야의 문제해결 방식을 프로그래밍에 대입해보는 방식이었다.
소프트웨어 공학
소프트웨어 공학이 연구되기 시작하면서 가장먼저 이식된 공학개념은 '라이프 사이클'이다. 라이프 사이클은 말 그대로 수명주기를 뜻하는데 예를 들어 건축공학에서의 라이프 사이클은 건물이 건설되고 파괴되기까지의 기간을 1 cycle로 두고 있었고 기계공학에서는 공장에서 생산된 제품이 신제품으로서 각광을 받는 기간, 매출이 신장하는 기간, 매출이 정지되는 기간, 매출이 떨어지는 기간, 시장에서 자취를 감추는 기간으로 나누어 전체과정을 1 cycle로 보고 있었다.
소프트웨어에서의 수명주기는 요구사항 분석 → 설계 → 개발 → 테스트 → 운영의 단계를 거친다. 좀 더 세분화 하면 예비분석 → 시스템분석→ 시스템설계 → 개발 → 통합 → 테스트 → 운영,유지,보수 → 폐기의 단계가 되겠다.
- - 예비분석 : 고객(클라이언트)와의 대화를 통해 고객의 요구하는 바를 이해하고 일종의 청사진을 그리는 단계이다. 최대한 자세한 질문을 통해 솔루션(프로그램)의 성격과 범위, 목적을 추상화해내야 한다. 또한 몇가지 요구에 대해 개발이 지나치게 어려울 것으로 예상되면 대체할 솔루션도 제안한다. 타당성 조사도 실시해서 아예 불가능한 부분이 있는지도 알아본다. 개발에 들어갈 비용과 시간을 어느정도 분석하는 것도 이시기이다. 어찌보면 모든 것의 틀을 만드는 가장 중요한 시기라 볼 수 있다.
- - 시스템분석 : 추상적으로 정의된 예비분석 자료들을 프로그램을 짤수 있을 정도로 구체적이고 보다 이산적인 개념으로 바꾼다. 불완전한 부분은 다시 클라이언트와 대화를 통해 메꾼다. 어느정도의 프로그램이 그려지면 그것의 장단점을 생각해보고 장점을 살리는 방안과 단점을 최대한 제거할 해결책을 찾는다
- - 시스템 설계 : 개발 과정은 어떻게 할지, 개발시의 규칙은 어떤 것으로 할지와 같은 전체 코딩의 큰 그림을 그린다. 실제로 다이어그램을 그려보고 프로그램을 어떻게 나누고 개발자들을 어떤식으로 팀을 나눌지 결정한다.
- - 개발 : 실제 코드를 각팀별로 짜서 결과물을 낸다.
- - 통합 : 짜여진 코드들을 merge해서 작동시켜본다.
- - 테스트 : 임의의 입력값이 들어가는 테스트 환경에서 소프트웨어를 돌려서 오류와 버그 상호운용성을 검증한다.
- - 운영,유지,보수 : 고객에게 제품이 전달되고 실제상황에서 쓰인다. 나타나는 문제들은 피드백받아 패치를 제공하고 서버유지 같은 업무를 병행한다.
- - 폐기 : 완전히 새로운 시스템으로 전환하기 위해 사용하던 시스템을 파기하는 단계이다. 여기서 수명주기가 끝난다.
위의 과정이 대부분의 소프트웨어 개발에서의 수명주기(SDLC)이다. 그렇다면 개발방법론이란 것은 무엇인가? 위의 과정에 이것을 더하고 저것을 빼고 해서 만든 새로운 방식의 개발과정이 바로 개발방법론이다. 다양한 예시가 있겠지만 위의 과정을 그대로 따르는 것을 '폭포수 모형'이라고 한다. 폭포수처럼 다시 위로 가는 과정없이 분석 → 설계 → 개발 → 테스트 → 운영의 과정에서 분석이 끝나면 설계, 설계가 끝나면 개발하는 식으로 하나가 끝나면 다음 단계를 진행하는 방식이다.
개발방법론의 종류
위의 과정을 조합하는데 있어 다양한 개발방법들이 무수히 나오겠지만 여기서는 주된 개발방법모델들만 소개하고자 한다. 위의 폭포수 모형은 굉장히 고전적인 방식으로써 너무나 고도화된 현재에는 잘 쓰이지 않는다.
폭포수모델
폭포수 모델로 더 많이 알려져 있다. 폭포에서 물이 떨어지듯이 다음 단계로 넘어가 폭포수 모델이라고 하는데, 고전적 생명주기라고도 한다. 폭포수 모델은 소프트웨어 공학의 고전으로 말해진다. 소프트웨어 발전 초기에 만들어진 전통적인 모델이다. 공장 생산 라인이 돌아가는 것처럼, 소프트웨어 개발의 표준적인 프로세스를 정하여 소프트웨어를 순차적으로 개발한다. 개발 단계는 아래와 같다.
① 계획 단계 • 클라이언트의 요구사항을 분석하여 정의한다. • 개발자들이 어떤일을 할지 나누어본다. • 개발의 순서와 방향을 결정한다. • 개발마감일을 예측하고 그에 맞춘 일정표를 작성한다. • 개발에 클라이언트가 지출할 비용을 산정한다. • 계획 단계의 최종 산출물인 '개발 계획서'를 작성한다. ② 요구 분석단계 • 기존에 쓰던 시스템이 있다면 분석하고 요구사항과 맞춰본다. • 기능적 요구사항과 입력,정보 같은 비기능적 사항을 정리한다. • 각 방법론에 따른 표기법을 이용해 정리된 요구 사항을 표현한다. • 마지막으로 보기 쉽게 요구분석표를 만든다. ③ 설계 단계 설계 단계는 크게 전체적인 시스템 구성을 나타내는 상위설계\(아키텍처 설계\)와 각 모듈\(컴포넌트, 자료구조, 알고리즘\)의 세부 내용을 설계하는하위설계로 나뉜다.| 상위 설계 | •개발하려는 소프트웨어의 전체 구조를 볼 수 있는 아키텍처를 설계한다. • 아키텍처의 품질 속성을 결정한다. • 아키텍처의 스타일을 결정한다. • 설계 패턴을 결정한다. |
| 하위 설계 | •모듈 간의 결합도와 모듈 내의 응집력을 고려해 각 모듈의 세부 내용을 설계한다. • 객체지향 방법론에 따라 설계를 한다면 설계 원리, 클래스 간의 관계, 클래스 설계 원칙을 고려한다. |
구현은 코딩을 하는 단계이다. 코딩을 할 때는 가능한 표준 코딩 스타일을 지키는 것이 좋다. 또한 최근에는 보안이 매우 중요하므로 항상 예외처리를 하여 보안에 취약하지 않도록 코딩한다.
⑤ 테스팅 단계테스트 방법은 다음과 같이 다양한 방법으로 분류할 수 있으므로 프로젝트의 성격에 맞는 방법을 선택한다.
• 개발자 또는 사용자 시각에 따른 분류 • 사용되는 목적에 따른 분류 • 프로그램의 실행 요구 여부에 따른 분류 •품질특성에 따른 분류 • 소프트웨어 개발 단계에 따른 분류 ⑥ 유지보수단계개발에서 유지보수비용은 전체 비용의 50~60%를 차지할 만큼 큰부분이다. 소프트웨어 유지보수는 집에 불편한 부분이 발견되거나 낡으면 계속 고치면서 살아가는 것과 유사하다. 소프트웨어도 사용하다보면 추가 요구 사항, 수정 사항 등이 많이 발생한다. 유지보수 단계는 사용 중인 소프트웨어를 문제없이 잘 유지하고, 문제가 있는 곳은 보수하면서 사용하는 단계이다. 유지보수는 다음과 같이 분류할 수 있다.
• 수정 유지보수 • 적응 유지보수 • 기능 보강 유지보수 • 예방유지보수장단점
폭포수개발의 장점은 아무래도 절차가 딱딱 정해져 있으므로 간결하고 이해하기 쉬우며 관리가 용이하다는 점이다. 단점은 앞 단계가 완벽해야 오류가 발생하지 않는다는 점과 중간결과를 볼 수 없다는 점이 되겠다. 당연히 현재처럼 복잡한 개발환경에서는 거의 쓰이지 않는다.
| 장점 | 단점 |
| 관리가 용의하다 | 전 단계가 완벽해야 오류가 없다. |
| 체계적이다 | 중간결과라는 것 자체가 없다 |
| 요구사항이 적은 프로젝트에 적합하다 | 폭포를 거슬러 오를 수 없다. |
나선형 모델
① 계획 및 요구 분석단계계획 및 요구 분석 단계에서는 사용자의 개발 의도를 파악하여, 해당 프로젝트의 목표를 명확히 하고, 여러 제약 조건의 대안을 고려한 계획을 수립한다. 또 사용자의 요구를 통해 파악한 기능 요구 사항과 성능,정보,입력 같은 비기능 요구 사항을 정의하고 분석한다.
② 위험 분석단계위험 분석 단계에서는 프로젝트 수행에 방해되는 위험 요소를 찾아 목록을 작성하고 위험에 대한 예방 대책을 논의한다. 또한 위험 요소를 평가하여 개발에 얼마나 영향을 주는지, 대안은 없는지 등을 분석하여 심각한 위험이 존재하는 경우에는 해당 프로젝트를 계속 진행해도 되는지를 결정한다.
소프트웨어를 개발하는 데 일반적으로 나타날 수 있는 위험 요소는 아래와 같다.
#### 소프트웨어 개발 시 위험 요소| 소프트웨어 개발 시 위험 요소 |
| 목차 | |
| _위험 요소_ | _위험 내용_ |
| 개발자의 이직 | 프로젝트 수행 중 개발자의 이직 |
| 요구 사항 변경 | 요구 사항 확정 이후에 계속되는 변경 요구 |
| 발주사의 재정적 어려움 | 프로젝트 수행 중 발주사의 경제적 어려움 |
| 예상을 빗나간 투입 인력 | 처음에 예측한 인력보다 더 많은 인력을 필요로 하는 경우 |
| 개발 기간의 부족 | 처음에 예측한 개발 기간을 초과한 경우 |
| 개발비의 초과 | 처음에 예측한 개발비로 완료할 수 없는 경우 |
개발 단계에서는 초기버전인 프로토타입을 만드는데, 다른 소프트웨어 개발 프로세스의 설계와 구현에 해당된다.
④ 사용자 평가단계사용자 평가 단계는 진화적 프로토타입 모델에서 매우 핵심적이고 중요하다. 즉 개발이 반복적으로 이루어지는 이유는 사용자 평가 단계가 존재하기 때문이다. 알파 버전은 첫 평가를 시작하는 단계로 충돌이나 데이터 손상을 입을 수 있는 버전을 뜻한다. 베타버전은 알파버전을 이은 단계로 속도/성능이 어느정도 완성된 형태이나 아직 많은 버그가 존재한다.
⑤반복단계이 단계는 처음 개발된 프로토타입을 사용자가 확인하고 추가 및 수정될 요구 사항이 있으면 이를 반영한 2차 프로토타입을 만들도록 한다. 또 개발된 2차 프로토타입을 평가하여 추가 및 수정될 요구 사항이 있으면 이를 반영한 3차 프로토타입을 만들도록 한다. 이와 같이 사용자가 만족할 때까지 n번 반복하여 더 이상의 추가 및 수정 요구가 없으면 최종 제품을 만든다.
장단점
나선형모델은 위험을 미리 분석하는 단계가 있기에 이를 고려하면서 개발이 진행되어 갑작스런 오류로 심각한 사태가 벌어질 가능성이 적다. 그러나 반복적인 단계들의 시행으로 기한을 지킬 수 없는 경우가 많고 관리도 어렵다. | 장점 | 단점 | |-----------|-----------| | 심각한 오류 발생의 가능성이 적다 | 개발 시간이 길어진다 | | 클라이언트의 요구에 유연하게 대처할 수 있다 | 프로세스 관리가 어렵다. |
### 애자일 방법론애자일 방법론은 애자일\(agile\)이라는 뜻 그대로 빠르고 민첩하게 작동하는 방법론을 말한다. 이 모델은 고객의 요구에 민첩하게 대응하고 그때그때 주어지는 문제를 풀어나가는데 중점을 둔다. 한마디로 폭포수와 나선형의 장점만을 합한 모델인데 폭포수의 관리용의성과 나선형의 유연함을 가지고 왔다. 애자일은 일종의 정의로써 애자일의 특성을 가진 방법론을 모두 애자일이라고 부른다. 예로 익스트림 프로그래밍, 스크럼, 크리스털이 있다. 2001년에 각 방법론의 전문가들이 모인 '애자일 연합\(agilealliance\)' 그룹에서 '애자일 선언문'이라는 공동 선언서를 통해 애자일을 정의 내렸다. 정의는 다음과 같다.
• 최우선적인 목표는 고객을 만족시키기 위해 가치 있는 소프트웨어를 빨리, 지속적으로 제공하는 것이다. • 개발 후반에 새로 추가되는 요구 사항도 기꺼이 받아들인다. 애자일 프로세스는 고객의 경쟁력을 위해 요구 사항의 변경을 받아들인다. • 동작 가능한 소프트웨어를 짧으면 2주, 길면 2개월 간격으로 자주 고객에게 전달한다. 이때 간격은 짧을수록 좋다. • 프로젝트가 진행되는 동안에 업무 담당자와 개발자는 매일 서로 의견을 주고받으며 함께 참여한다. • 정보 전달을 위한 전화, 팩스, 인터넷 등 많은 매체 수단이 있으나 가장 효과적인 의사소통 방법은 역시 직접 만나 얼굴을 보면서 대화하는 것이다. • 진척 사항의 척도를 나타내는 방법은 여러 도구로 표현할 수 있으나, 가장 좋은 방법은 실행 가능한 소프트웨어를 보여주는 것이다. • 자율적 사고와 자유로운 분위기의 프로젝트 팀에서 최고의 아키텍처, 요구 사항, 설계가 나온다. • 프로젝트의 효율성을 향상시키기 위해 개발 팀 스스로 정기적인 미팅을 진행하여 자신들의 행동을 되돌아보고 조율 및 수정한다. _구분_ | -------------| | | _애자일 방법론_ | _폭포수 모델_ | 나선형 모델 | |---------------|---------------------|------------------------|-----------------------------| | 추가 요구 사항의 수용 | 처음 수집한 요구 사항을 전체 요구 사항 중 일부로 인정하고 시작하므로 언제든지 추가 요구 사항이 있을 것으로 간주한다. 따라서 추가 요구 사항을 수용할 수 있는 방법으로 설계되어 있다. | 요구 사항 분석이 완전히 완료된 후에 설계 단계로 넘어가므로 새로운 요구 사항을 추가하기 쉽지 않다. 추가 요구 사항을 반영하기 어려운 구조이다. | 요구사항을 수정하려면 다시 그 단계에 도달할 때 까지 사이클을 돌아야 한다.| | 릴리스 시점 | 가능하면 자주, 빨리 제품에 대한 프로토타입을 만들어 사용자에게 보여준다. 이러한 방식을 반복적으로 수행하여 최종 제품을 만들기 때문에 자주 릴리스된다. | 요구 사항에 대한 분석, 설계, 구현 과정이 끝나고 최종 완성된 제품을 릴리스한다. | 폭포수보다는 빨리 결과가 나오지만 정해진 단계를 거처야하므로 애자일 보다는 느리다.| | 시작 상태 | 계속적인 추가 요구 사항을 전제로 하는 방식이라 시작 단계에서는 부족한 점이 많지만 점차 완성도가 높아진다. | 한 번 결정된 단계는 그 이후에 변동이 적어야 한다. 따라서 단계별 완성도를 최대한 높여 다음 단계로 넘어가기 위해 시작 단계에서의 완성도가 매우 높다. | 점차 완성도는 높아진다. 다만 속도는 느리다.| | 고객과의 의사소통 | 사용자와 함께 일한다는 개념을 담고 있다. 처음부터 사용자의 참여를 유도하고 많은 대화를 하면서 개발을 진행한다. | 사용자의 요구 사항을 정의한 후 사용자에게서 더이상 추가 요구가 없다는 확답을 받고 개발에 들어간다. 따라서 사용자와 산출물을 근거로 하여 빈번하게 대화하지 않는다. | 역시 애자일보다는 적은 소통을 한다. | | 진행 상황 점검 | 개발자와 사용자는 개발 초기부터 지속적으로 진행 상황을 공유하며 함께 관심을 갖고 진행해나간다. | 단계별 산출물을 중요시하기 때문에 단계별 산출물에 대한 결과로 개발의 진척 상황을 점검한다. | 진행상황은 개발자들이 관리하고 차례가 왔을 때만 클라이언트와 대화한다.| | 분석, 설계, 구현 진행 과정 | 분석, 설계, 구현이 하나의 단계와 그 단계 안의 반복마다 한꺼번에 진행된다. 다만 어떤 단계에서는 분석이 많고 구현이 적은데 어떤 단계에서는 분석이 적고 구현이 많다는 차이만 있을 뿐이다. 하나의 단계 또는 반복 안에 분석, 설계, 구현 과정이 모두 포함되어 동시에 진행된다고 볼 수 있다. | 분석, 설계, 구현 과정이 명확하다. 각 과정에서 생산되는 산출물 중심의 개발 방식이기 때문에 단계가 명확히 구별되어 있다. 따라서 분석이 끝난 후 설계를, 설계가 끝난 후 구현 작업을 진행한다. | 과정은 절차대로 밟는다. 당연히 느리다.| | 모듈\(컴포넌트\) 통합 | 개발 초기부터 빈번한 통합을 통하여 문제점을 빨리 발견하고 수정하는 방식을 택한다. 이 방식은 문제점을 빨리 발견하여 비용을 많이 절감할 수 있다는 장점이 있다. | 코드구성이 전부다 완료된 후에야 통합 작업을 한다. | 코드가 완성된 후에 통합한다. 다만 n번 반복해야할 뿐이다.|마치 주먹구구식으로 만드는 것과 비슷해보이는 이 방법은 현대에서 가장많이 쓰이는 방법론이다. 요컨데 오픈소스 개발방법론의 주요한 부분을 차지한다. 폭포수는 1950-1970년에 나선형은 1970-1980년에 애자일은 1990년이후 주욱 주요한 위치를 차지하고 있다. 애자일을 사용한 것이 오픈소스 개발방법론이라면 애자일과 다른 점이 무엇인가? 다음 장에서 알아보자.
##오픈소스 개발방법론의 정의오픈소스 개발방법론은 말 그대로 개발에 오픈소스를 활용하는 것이다. 좀 더 쉽게 말하자면 오픈소스를 이용해서 애자일방식으로 개발하는 모델을 일컫는다. 크레이그 먼디는 성당과 시장\(cathedral and bazarr\)에서 오픈소스 개발방법론에 대한 철학적인 바탕을 제시한다. 기존의 폭포수, 나선형같은 독점 소프트웨어 개발방법론은 성당을 짓는 것처럼 위계적이고 폐쇠적이기에 개발의 시간과 비용이 증가할 수 밖에 없다. 그러나 애자일과 오픈소스를 플럼빙\(plumbing\)하여 작성하는 코드개발은 시장처럼 시끌벅적하다. 논의가 오가고 많은 사람들이 협력하기에 비용과 시간은 줄어들 수 밖에 없다.
그렇다면 오픈소스는 개발과정 중 언제 들여와야 하는가? 당연히 개발 초기에 오픈소스를 들여다 보아야한다. 개발 초기에는 요구사항이 불명확해서 매우 많은 시간을 소비하는 경우가 많다. 이 때에 오픈소스 커뮤니티들에서 오픈소스를 들여다보면 이미 필요한 기능이 개발된 경우가 많고 라이센스를 확인해서 들여오기만 하면된다. 게다가 오픈소스는 이미 많은 개발자들에 의해 사용된 검증된 소스이기에 버그도 적다. 당연히 추후 테스팅과정에서의 비용과 시간도 줄어든다.
여기서 드는 의문은 그렇다면 오픈소스만 가져오고 개발과정은 폐쇠적으로 할 수 있지 않느냐는 점이다. 물론 그렇수 있다. 그러나 그것은 오픈소스 개발방법으로 보지는 않는다. 왜냐하면 원시소스만 가져와서 개발팀에서 수정, 업그레이드 하는 경우 커뮤니티가 아닌 본인들이 관리 해야하게되고 비용과 시간을 아끼려고 선택한 방법의 장점은 사라지게 되기 때문이다. 즉 소스코드는 재사용할 수 있는 것으로 보아야하고 본래의 코드에 기여하는 방식으로 성장 변화시켜 사용하는 것이 극히 효율적이다라고 볼 수 있다.
또한 '성장'에 초점을 맞춘 애자일과 오픈소스의 '성장'은 일맥상통하기에 잘 맞기도 하기 때문이다. 가령 클라이언트가 빨리 목적지에 도착하는 수단을 요구했을 때 애자일 방식의 개발은 처음에는 킥보드를 개발해서 주고 다음에는 자전거를 그리고 더 개발을 진행시킨다음에는 오토바이를, 마지막에는 자동차를 준다. 오픈소스도 마찬가지로 처음에는 불완전하지만 작동하는 형태에 많은 이들의 협업을 통해 점차 어른으로 성장해가는 과정을 거친다. 개발방식에서도 오픈소스 자체를 만드는 커뮤니티처럼 수평적 조직을 운영해야하는 이유가 여기에 있다.
### VCS이를 위해 오픈소스개발에서는 특정한 VCS\(버전 컨트롤 시스템\)을 운용한다. 오픈소스 개발방법론에서는 아주 잦은 코드의 변경, 수정이 이루어지기 때문에 이를 보조할 VCS는 필수적이다.\(인간이 다 관리하는 것은 불가능에 가깝다\) VCS는 코드의 모든 변화들을 추적한다. 언제 새로운 코드가 추가됬는지, 삭제됬는지, 누가 했는지, 어떤것이 변화했는지, 코드가 증가했는지 줄었는지 등등의 것을 전부다 말이다.
초기의 VCS는 중앙에 서버를 둔 집중식이었다. Subversion이라는 프로그램이 많이쓰였는데 느리고 비효율적이었다. 이것이 bit keeper같은 협업식으로 바뀌었다가 git이 개발되면서 대부분 git을 오픈소스 개발의 VCS로 삼았다. 주로 쓰인 VCS들을 시대순으로 나열 | ----------------| |CVS | Current vesions systems, 동시버전 관리시스템으로도 알려져 있다. 모든 작업과 모든 변화를 추적하고 개발자들이 협력할 수 있게 한다. 다만 파일단위 입출력, 디렉토리의 이동이나 이름의 변경 불가, 거의 동시에 코드 변경시 오류를 발생시키는 등의 문제를 갖고 있었다. | |---------------------|-----------------------------| |SubVersion | 오픈소스에서도 쓰이지만 기업에서도 많이 쓰이는 방식이다. 중앙집중식이며 CVS와 달리 다른 사용자와 엉키지 않고 파일의 이름을 바꿀 수 있었다. 그리고 전체적으로 CVS에 비해 빨라졌다.| |Bitkeeper | Fork와 merge같은 작업이 subversion에 비해 비약적으로 속도가 상승하였으나 기업에서 개발한 제품으로 사용에 많은 제약이 걸려 최종적으로는 거의 사용되지 않았다.| |Arch,Darcs,Monotones | Bitkeeper가 사용중단되고 한동안 오픈소스개발자들이 임의로 개발하여 쓰였다. git이 개발되기 전까지의 기간에 잠깐 쓰인 VCS들이다.| |Git | Bitkeeper의 모든 장점에 모든 단점을 없엔 거의 궁극적인 VCS가 되었다. 현재 전세계에서 가장 많이 쓰이는 VCS이다.| 일반적인 VCS들의 기능은 다음과 같다.
1. 저장소\(repository\) : 코드가 공유되고 저장되는 장소이다. 누구나 코드를 다운로드할 수 있고 허가된 개발자들은 코드를 수정할 수 있는 권한을 가진다. 2. 체크아웃 : 개별 개발자들이 코드의 카피를 자기고 IDE와 연결하는 행위 3. 푸쉬\(push\) : 수정한 코드를 저장소로 보내는 행위 4. 커밋\(commit\):개별 저장소에 코드를 저장하는 행위로 허가된 개발자들은 직접 소스코드에 commit하기도 한다. 5. 머지\(merge\) : 두 코드 조각을 합치는 행위 6. 패치\(patch\) : 원시코드에 코드가 추가되는 것, 누가 기여했는지도 알린다. 7. 브랜치\(branch\) : 분리되고 독립적으로 개발가능한 카피, 코딩후에는 master branch에 merge시킨다. ### 개발과정 오픈소스 개발방법론에 따른 개발과정은 다음과 같다. 1. 클라이언트의 요구사항 접수 2. 오픈소스 활용 검토 3. 설계,개발 4. 테스팅 5. 프로그램 출고설계, 개발과정에서 바로 위의 VCS를 적절히 사용하는 것이다. 오픈소스를 활용한다는 전제하에 설계 개발에는 다양한 오픈소스들이 쓰인다. 오픈소스가 쓰이지 않는 부분은 도메인 클래스를 만들 때인데 도메인 클래스는 개인정보같은 민감한 정보가 들어가기 때문이다. 클라이언트가 원하는 정보와 입력은 모두 여기에 들어간다. 그리고 데이터베이스 개발에는 오픈소스인 MySQL같은 소스들을 활용할 수 있다. 개발된 코드는 공개되어 다시 다른 개발자의 코딩에 쓰이게 되는 선순환 구조를 갖는다. 오픈소스를 코딩에 적용하는 방식은 아래의 경우가 있다.
1. 블랙박스 재사용 : 이 경우에는 원래의 소프트웨어를 거의 원본 그대로 사용한다. 이 방식의 장점은 구매비용과 구입시 발생하는 로열티를 아낄 수 있으며 공급업체에 종속되어 그 업체 제품만을 사야하는 지경에 이르는 것을 막을 수 있다. 2. 그레이 박스 재사용 : 코드를 고치는 것은 유저인터페이스 같은 부가적인 부분에서만 하고 대부분을 고치지 않는다. 그렇다 할지라도 기존 오픈소스에 대해 심도있는 이해가 있어야 할 수 있기에 초기에는 상당한 시간, 금액이 들어간다. 3. 화이트 박스 재사용 : 오픈소스의 내부동작과정을 연구한뒤 쓰임에 맞게 개조, 수정하여 사용한다. 거의 대부분을 고처서 쓰는 재사용과정이다. 유명한 예시로 구글이 리눅스 커널을 가져다 고처쓰는 것을 들 수 있다. 또한 재사용될 코드를 선택하는데 있어 아래의 기준을 두고 엄격히 점검해야한다. * 신뢰성,성숙도 * 유지보수성 * 기존 기술과의 호환여부 * 확장성과 이식성 * 클라이언트의 요구사항에 충족하는가 * 보안성 * 인터페이스의 유연성 * 다른 운영체제 및 하드웨어에서의 동작여부 * 라이선스의 적법성 ### 의의오픈소스 개발방법론은 소프트웨어 산업에서 중요한 의미를 갖는다. 소프트웨어 개발은 시간도 오래걸리고 어렵고 힘들어서 많은 개발자들이 떠날 정도 였다.\(사실 지금도 그렇다\) 그러나 오픈소스를 사용하므로써 코드는 재사용, 재가공되고 많은 비용과 시간을 줄일 수 있게되었다. we are better than me가 오픈소스 개발의 기치이다. 백지장도 맞들면 낫다는 속담을 증명하는 것만 같은 분야이다.