1. 형상관리에 대해

 오늘은 소프트웨어 개발에서 기본이 되는 형상관리에 대해서 알려 드리겠습니다. 형상관리(CM : configuration management)라고 들어보셨나요? 소프트웨어 공학을 배우신 분들에게는 익숙하겠지만, 그렇지 않으신 분들에게는 매우 생소한 단어라 생각 됩니다. 이미 배우신 분들은 형상관리가 범위도 다양하고 복잡하다는 걸 알고 있을 텐데, 오늘은 그 중에 개발자들에게 익숙한 소프트웨어 형상관리, 다른 말로 하면 소스 버전 관리에 대해 알아 보도록 하겠습니다.

 소프트웨어 형상관리는 Software Configuration Management, 줄여서 SCM라는 단어를 쓰기도 하는데, SW개발 및 유지보수 과정에서 발생하는 소스코드, 문서, 인터페이스 등 각종 결과물에 대해 형상을 만들고, 이들 형상에 대한 변경을 체계적으로 관리, 제어하기 위한 활동입니다. 단순히 말하자면 프로젝트를 진행하면서 생성하는 소스코드를 CVS나 SVN, 또는 GIT와 같은 버전 관리 시스템을 이용하는 것을 말합니다.

 다수의 개발자가 프로젝트에서 동일한 기능을 동시에 개발한다고 할 때, 작성된 소스 코드와 변경사항을 확인하고, 수정하는 협업을 도와주는 시스템이라고 할 수 있습니다.

 참고로 공급망 관리를 지칭하는 Supply Chain Management(SCM)과 동일한 약어를 사용하니, 누가 SCM에 대해 물어본다면, 어떤 SCM을 말하는 것인지 확인을 하고 대답해 주세요. ^^

 그럼 오늘은 소프트웨어 형상관리에서 버전 관리 시스템을 왜 사용해야 하는지, 어떤 개념들이 있는지, 그리고 어떠한 시스템들이 있는지 알아보도록 하겠습니다.

2. 왜 버전 관리 시스템이 필요한가?

 프로그램을 만들다 보면, 잘못 만들어서 다시 소스코드를 이전 상태로 되돌릴 필요도 있고, 변경된 이력을 확인할 필요가 있습니다. 그리고 여러 명의 개발자들이 동시에 같은 소스코드를 개발하면서 발생하는 충돌에 대한 처리도 필요합니다. 이러한 것을 하기 위해 무엇이 필요할까요? 바로 버전 관리 시스템입니다.

 과거와 달리 현재의 소프트웨어는 더 복잡해지고, 더 쉽게 변경됩니다. 만약 소프트웨어 버전관리 시스템을 사용하지 않는다면, 다른 개발자가 무엇을 했는지 알 길이 없으며, 실수를 쉽게 되돌릴 수도 없습니다.

 버전 관리 시스템이 없던 과거에는, 다음과 같이 누구 책임인지 싸우느라 시간을 허비 했을지도 모릅니다.

 버전 관리가 필요한 이유를 정리하면 다음과 같습니다.

• 개발 하는 동안 소스 코드의 변경 사항을 보존하기 위해

• 버그 및 문제점이 발생했을 때 추적에 유용
• 과거 특정 시점의 소스 파일 및 디렉토리의 내용을 손쉽게 확인 가능
• 과거 특정 시점의 소스 파일로 손쉽게 되돌릴 수 있음

• 협동 작업을 가능하게 하기 위해
• 대부분의 프로젝트는 팀 단위이기 때문에 전체 팀원이 하나의 소스를 가지고 효율적으로 작업할 수 있는 도구가 필요함
• 인터넷을 이용한 전세계 개발자들이 협업을 하여 개발하는 오픈 소스 프로젝트에 필수

3. 버전 관리 시스템의 기본 개념

문제 #1: 협업하기

 두 명 이상의 사람들이 똑같은 소스코드를 같은 시간에 편집해야 한다면 어떻게 해야 할까요?

해결책

 버전 관리 시스템은 개발자들이 동일한 소스 코드를 동시에 수정하거나 수정된 내용을 쉽게 공유할 수 있는 기능을 제공합니다.

• 중앙 저장소(Repository)에 메인 소스 코드를 저장해 놓습니다.
• 여러 명의 개발자들은 각자 로컬 PC에 중앙 저장소에 저장되어 있는 소스 코드를 작업 디렉토리(Working Copy)에 사본을 복사해 소스 코드를 수정합니다.
• 개발자들이 소스 코드 수정을 끝낸 후, 소스 코드를 공유하기 위해서 중앙 저장소로 소스코드를 커밋(Commit) 합니다.
• 다른 개발자는 변경된 내용을 확인 하기 위해서 중앙 저장소의 소스를 작업 디렉토리로 갱신(Update) 되도록 명령을 수행합니다.

문제 #2: 수정 사항 되돌리기

 간혹 수정하던 소스 코드를 다음과 같은 이유로 이전 상태로 돌아갈 필요가 생깁니다.

• 개발을 시작한 후 시간이 지나, 잘못된 구현을 하고 있다는 것을 알게 되었을 때
• 이전 상태로 되돌리면서 모든 파일에 대한 변경 이력(History)를 유지하고 싶을 때
• 소스 코드가 언제, 무엇을, 그리고 누가 수정했는지 알고 싶을 때
  ->누군가 작성한 소스 코드를 이해하는 가장 좋은 방법은 작성한 사람에게 물어보는 것입니다.

해결책

 버전 관리 시스템은 개발자들이 수정한 소스 코드에 대한 리비전(Revision)을 관리합니다. 리비전은 수정 시간, 수정한 사람, 수정한 내용들을 포함하고 있어, 개발자들에게 편리한 정보를 제공하고 있습니다.

 또한 되돌리기(Roll back) 기능이 있어 특정 리비전 또는 특정 시간으로 소스코드를 되돌릴 수 있습니다.

위 두 가지 문제를 보면서 버전 관리 시스템의 기본적인 개념을 설명 드렸습니다. 그리고 위에서 나온 용어들을 정리하면 다음과 같습니다.

 위 용어들은 다양한 버전 관리 시스템에서 다양한 용어로 대체되어 사용됩니다. 예를 들면 작업 디렉토리(working Copy)는 작업 공간(Workspace)라는 단어로, 커밋(Commit)은 체크인(Check-In)이라는 단어가 사용되기도 하니 버전 관리 시스템을 사용하기 전에 어떤 단어가 위의 기능들과 매핑 되는지 확인해야 합니다.

4. 버전 관리 시스템의 종류

 버전 관리 시스템은 상용과 비상용(오픈소스)로 구분 할 수 있습니다.

• 상용
  • IBM Rational ClearCase
  • Perforce
  • PTC Integrity
• 비상용(오픈소스)
  • Subversion(SVN)
  • CVS
  • Git

 위에 나열한 시스템 외에도 수많은 버전 관리 시스템이 있습니다. 버전 관리라는 동일한 목표를 가지고 있지만, 각각의 시스템들은 특색을 가지고 있어, 그 특색에 따라 툴을 사용하는 방법들이 상이합니다. 그리고 상용 프로그램들은 가격이 정말 비쌉니다. 프로그램 라이선스가 1년에 1명 사용하는데 수백만원을 넘기니 말이죠. 그리고 최근 오픈 소스 프로젝트의 대부분은 Git를 사용하고 있습니다. 참고로 예전에는 SVN을 주로 사용했습니다. 여러분이 오픈 소스에 관심 있으시면 Git-Hub(http://git-hub.com/) 사이트를 둘러 보시면 도움이 될 것 입니다.

5. 글을 마치며

 버전 관리 시스템은 아마추어 개발자와 전문 개발자를 구분하는 것 중에 하나라고 합니다. 프로젝트를 혼자서 하는 경우도 있고, 몇 명이 나누어서 진행하는 경우도 있습니다. 늘 일정에 쫓기다 보니 '바빠 죽겠는데 버전 관리까지 어떻게 해?'라고 생각하시는 분들도 있을 것입니다. 하지만 일주일 동안 온 힘을 다한 소스 코드를 실수로 날려 버린 경험을 가지신 분들은 버전 관리 및 소스 코드 백업의 필요성을 느끼실 것 입니다.

 소스 코드 버전 관리는 정말 유용합니다. 처음 익숙해 질 때 어려움은 있지만, 시간이 조금 더 지나면 버전 관리에 대한 보상을 금방 얻으실 수 있습니다. 요즘 사람들이 많이 쓰는 Git로 버전 관리를 시작해 보시겠어요?

Git란

분산형 버전 관리 시스템이다. 기존 중앙 관리형 버전 관리 시스템에서는 서버에서 Snapshot을 Checkout 해 로컬에서 사용하는 방식과 달리, 저장소(repository)를 전부 복제해서 전체 시스템을 하나의 Client처럼 사용한다. 그래서 서버에 문제가 생겼을때, 소스 변경 작업이나 복구가 용이하다는 장점을 가지고 있다.

여담으로 Git가 생긴 이유는 Linux 커널 소스 버전 툴인 BitKeeper가 무료로 사용할 수 없다고 함에 따라 리누스 토발즈가 만든 툴이다.

Git의 지향점

• 빠른 속도
• 단순한 구조
• 비선형적 개발(수 천개의 동시 다발적 브랜치)
• 완벽한 분산
• 리눅스 커널과 같은 대형 프로젝트에서도 유용한 구조(속도, 데이터 안전성)

Git의 기초 이론

1. Commit 단위

기존 중앙 관리형 버전 관리 도구에서는 시간의 흐름에 따른 각각 파일들의 변화를 버전으로 만들어 관리했다. 

이에 반해 Git에서는 저장(Commit)시점에 변경된 파일의 집합을 하나의 버전으로 관리한다.

-> 파일의 집합을 하나의 버전으로 관리하는 모습은 Perforce의 Changelist나 또는 ClearCase의 UCM에서 Activity를 사용하는 모습과 흡사하다.

2. 속도

Git는 저장소 전체를 복사해 사용하기 때문에 서버 성능이나 장애 상황에 따라 영향을 받는 중앙 관리형 버전 관리 도구에 비해 속도가 현저히 빠르다. 로컬에 모든 정보를 가지고 직접 실행하다 보니 네트워크를 통해 정보를 교환하는 방식에 비해 빠를 수 밖에 없다. 

물론 Offline시에서도 소스와 관련된 작업 수행이 가능하다.

3. 무결성

모든 데이터를 다루기 전에 해당 파일에 대한 체크섬^[각주:1]을 구하고, 그 값을 이용해 데이터를 관리한다. Git에서는 SHA-1 Hash를 이용히 체크섬을 만든다.

4. Repository에 대해 삭제 수정이 없는 데이터 추가

데이터가 Commit 된 이후에는 기존 Repository에 대한 데이터를 삭제/수정이 불가능하다.

-> 아직 이 특징을 어떻게 활용해야 할지 의구심이 든다. 정말 정말 없나? 그건 뒤에 공부하면서 알아가야 겠다.

5. 파일의 세가지 상태

Git 상에서 파일은 Committed, Modified, Staged 상태로 관리된다.

- Committed : 로컬 GIT 데이터 베이스에 안전하게 저장된 상태

- Modified : 현재 수정되어 지고 있는 파일

- Staged : 수정 된 파일을 곧 Commit할 것이라는 표시

- Working Directory : 프로젝트의 특정 버전을 Checkout 한 곳 -> 실제 개발 작업이 이루어지는 공간

- Staging Area : Git Directory에 존재 하며 곧  Commit 할 파일으 대한 정보를 저장하는 곳

- Git Directory(Repository) : Git 프로젝트의 메타데이터와 객체 데이터베이스를 저장하는 곳

1) Working Directory에서 파일을 수정한다. (Modified  상태)

2) Staging Area에서 파일을 Stage해서 Commit할 Snapshot을 만든다. (Staged 상태)

3) Staging Area에 있는 파일을 Commit해서 Git Directory에 영구적인 Snapshot으로 저장한다. (Committed 상태)