Views: 1288
0 0
Read Time:7 Minute, 17 Second

SVN을 이용한 업무 프로세스

SVN의 기본 구성

SVN은 기본적으로 서버-클라이언트 Sever-Client 구조를 기반으로 작동이 이루어진다. 당신이 SVN을 사용중인 개발팀에 배정되어 첫 출근을하게 되면 개발팀 전용 개발 서버가 있는 것을 볼 수 있을 것이다(아닐 수도 있다). 그리고 보통 개발 서버가 SVN 서버 역할을 하게 되며, 각 개인의 작업 컴퓨터가 SVN 클라이언트 역할을 한다. SVN 서버에는 저장소Repository라 불리우는 공간이 존재하며, 각 클라이언트는 이 저장소에 저장된 데이터를 검색하여 최신 작업물을 다운로드 받는다. 물론 각 클라이언트에서 작업된 작업물을 전송 받아 정리하고 보관하는 역할 역시 서버가 맡게 된다. 필요에 따라서는 서버-클라이언트 구조의 구분 없이 하나의 컴퓨터 안에 저장소를 배정하고 이를 다운로드하여 업무를 진행 할 수도 있다. 개별 컴퓨터에 SVN을 설치하고 별도의 폴더 내에 저장소를 생성하면 바로 사용이 가능하게 된다(이 문서에서는 SVN의 설치 및 관리 방법에 대해서는 설명하지 않으며, 추가 정보는 참고 문헌 항목을 참조 바란다).

SVN은 서버-클라이언트 구조로 동작한다

SVN의 물리적인 구성이 서버-클라이언트라고 한다면, 소프트웨어적인 구성은 저장소와 작업 복사본 Working Copies 으로 이루어진다. 저장소는 말 그대로 SVN과 작업물에 관련한 모든 기록을 저장하고 있는 공간이다. 저장소는 별도 형식으로 데이터가 저장되기 때문에 작업자가 직접 저장소가 저장된 폴더를 검색하여 내용물을 확인 할 수는 없다.

작업 복사본은 저장소에 있는 데이터를 작업자에게 복사한 별도의 작업 공간이다. SVN의 명령을 통하여 저장소의 데이터를 원하는 폴더에 내려받으면 작업 복사본이 생성된다. 작업 복사본은 하나의 컴퓨터에 다수로 생성이 가능하다. 작업 복사본은 일반적인 윈도우즈의 폴더 구성과 동일한 형태를 가지고 있다(폴더-파일이 존재한다). 때문에 파일이나 폴더의 기본적인 이용 방법은 일반적인 윈도우즈의 파일, 폴더 사용법과 동일하다. 작업 복사본의 모든 폴더에는 숨겨진 폴더 형태로 .svn이란 폴더가 존재하는데, 이 폴더는 SVN에서 관리하는 파일에 대한 명세 데이터 Index Data 가 존재한다(이 .svn 폴더를 전체 삭제해버리면 .svn 폴더가 존재했던 폴더 내의 모든 파일/폴더가 SVN의 관리에서 벗어난다 작업 복사물에서 그냥 일반적인 파일/폴더가 되어버린다).

SVN 작업 복사본의 폴더 구조

작업 복사본은 통째로 다른 장소로 복사하거나, 옮기는 것이 가능하다-그냥 폴더 통째로 다른 곳으로 복사/이동 하면 된다. 작업 복사본 내의 명세 데이터(.svn)만 손상되지 않는다면, 옮겨진 작업 복사본은 별 다른 이상 없이 정상적으로 작동한다.

기본 업무 프로세스

SVN을 이용하여 업무를 진행 하는 경우 보통 다음과 같은 프로세스를 거친다.

  • 작업물의 체크 아웃 Check-out
    처음 작업을 시작 할 때, 저장소에서 작업물을 다운로드 하는 과정이다. 자신이 작업하게 될 컴퓨터에 최신 작업물들을 가져오는 것이다-원한다면 이전 시점의 작업물을 선택하여 받아 올 수도 있다. 이렇게 생성된 작업 복사본은 저장소에 있는 내용과 100% 동일한 새로운 복사본이기 때문에 어떠한 수정을 가하더라도 작업 복사본을 커밋 Commit 하지 않으면 수정 사항은 저장소의 내용에 영향을 미치지 않는다. 체크 아웃은 보통 최초로 저장소의 내용을 다운로드 받기 위해 이용하며, 이후 작업 복사본의 내용을 갱신하기 위해서는 업데이트 Update 명령을 이용한다.
  • 작업 복사본에서의 작업 수행
    체크 아웃 한 작업물을 이용하여 자신이 원하는 작업을 실시한다. 작업 복사본은 완전히 별개의 복사본이기 때문에 어떠한 수정을 가하더라도 언제든 저장소에 저장되어 있는 어떠한 시점으로 되돌릴 수 있다. 평소에 하던대로 문서 파일이나 그래픽 파일을 마음껏 수정하고 해당 파일을 저장한다.
  • 작업 복사본 업데이트 Update
    자신이 작업 복사본을 가지고 열심히 일을 하고 있는 동안 당신의 팀원들 또한 자신들의 작업 복사본을 가지고 계속 새로운 내용을 SVN의 저장소에 갱신 할 것이다. 업데이트는 자신의 작업 복사본을 현재의 저장소의 최신 버전과 비교하여, 새로 갱신 된 파일이 있을 경우 해당 파일을 최신의 상태로 변경하여 준다. 최초의 체크 아웃 작업 저장소를 삭제하지 않았다면 업데이트로 자신의 작업 복사본을 항상 최신 상태로 갱신 할 수 있다.
  • 작업물을 저장소로 전송-커밋 Commit
    작업 복사본에서 업무를 완료 하였으면, 자신의 작업물을 저장소에 전송 함으로써, 다른 작업자들이 해당 내용을 업데이트 받을 수 있도록 해야 한다. 작업물을 커밋 함으로써 SVN을 이용한 작업 사이클이 종료된다.

업무 프로세스의 변형

위에서 언급한 프로세스가 불변의 방식은 아니다-SVN을 이용한 업무 프로세스는 개인 혹은 집단에 따라서 다양하게 정립되어 있다. 때문에 팀원 간 SVN을 이용하는데 필요한 업무 약속 Work Protocol 을 공유하고 작업을 진행하여야 한다-팀의 작업 프로세스에 대해서는 팀 관리자나 SVN 관리자의 지침을 받으면 된다.

참고: 두 가지 관리 모델

리소스를 관리하고 업무 프로세스를 진행하는 데 있어 두 가지의 대표적인 모델이 존재한다. 이는 각각 잠금 중심 버전 관리, 통합 중심 버전 관리 불리우며, 각각의 관리 모델은 장단점을 가지고 있다. SVN에서는 기능상 두 모델의 적용이 모두 가능하나 기본적으로는 통합 중심 버전 관리 모델을 지원한다.

Lock-Modify-Unlock 모델 – 잠금 중심 버전 관리

잠금 중심 버전 관리 기법은, 한 명의 사용자가 어떠한 파일을 열어 작업을 하고 있다면, 다른 사용자들은 해당 파일을 수정/저장 할 수 없게 함으로써, 하나의 작업물을 동시에 둘 이상의 사용자가 수정-커밋하여 작업물을 엉망으로 만드는 것을 미연에 방지하기 위해 고안된 관리 기법이다. SVN에서는 Lock 및 Unlock 명령을 이용하여 파일 혹은 폴더를 잠금/해제 상태로 만들 수 있는데, 잠금 상태로 지정 된 파일은 그것을 잠가 놓은 사용자 본인만 커밋이 가능하게 된다.

Lock-Modify-Unlock Model

작업물의 중복 및 이로 인한 손상을 미연에 방지할 수 있지만, 관리가 상당히 번거롭다는 것이 단점이다-어떤 사용자가 잠금 상태를 풀지 않으면 다른 사용자는 해당 파일을 이용한 작업이 불가능하게 되므로 작업 혼선이 올 수도 있다. SVN을 이용하여 잠금 중심 버전 관리를 하기 위해서는 잘 짜여지고 체계화된 업무 프로세스 확립이 필요하다.

Copy-Modify-Merge 모델 – 통합 중심 버전 관리

통합 중심 버전 관리 기법은 잠금 중심 버전 관리와 다르게 모든 사용자가 하나의 작업물을 동시에 편집이 가능하다. 해당 작업물을 저장소에 커밋하게 될 경우 SVN에서는 각 사용자의 커밋 내용을 분석하여 자동으로 통합하게 된다. 다만, 자동 통합 과정은 텍스트Text 파일에 한해서만 가능하며, 동일한 지점에 대한 변경이 일어나게 될 경우 통합되지 않고 충돌Conflict을 일으킴으로써 누군가가 이를 수정을 해줘야 하는 문제가 발생한다.

Copy-Modify-Merge Model

바이너리 파일 등의 경우에는 작업물이 덮어씌워 질 수 있기 때문에, 만약 팀이 충분한 커뮤니케이션이 이루어지지 않은 경우 예기치 않게 작업물을 엉망이 되어버리는 위험도 존재한다. 통합 중심 버전 관리는 업무 프로세스 관리라는 측면에서는 잠금 중심 버전 관리 보다는 좀 더 현실적이지만, 작업물의 충돌에 많은 주의를 기울여야 한다.

SVN 기본 개념

사용자, 그룹 그리고 권한

SVN은 기본적으로 여러 사용자가 이용하기 때문에 각 이용자는 접근 권한을 가진다. SVN은 각 사용자에 대한 접근 권한을 지정 할 수 있으며, 비슷한 그룹의 사용자들을 그룹(예: 프로그램 그룹, 그래픽 그룹, 기획 그룹)으로 묶어 각 폴더에 접근 권한을 별도로 지정 할 수 있다. 개별 사용자들은 팀 내의 SVN 관리자로 부터 자신의 사용자 이름과 접근 패스워드를 부여 받게 되고, 해당 SVN 저장소에 접근을 할 때 부여받은 사용자 이름을 이용하게 된다.

SVN 저장소에 대한 권한은 읽기(저장소에서 작업 복사본 내려받기 권한), 쓰기(저장소에 작업 복사본을 커밋 하는 권한), 혹은 모두(읽기 및 쓰기)로 구분되어진다.

용어 설명

SVN 을 할 때 자주 접하게 될 주요 용어에 대해서 설명 한다.

  • 저장소 Repository
    저장소는 작업물을 보관하고 있는 장소를 가리킨다. 이러한 장소는 별도의 네트워크 서버 Server 의 하드 디스크가 될 수도 있고, 개인 컴퓨터의 하드 디스크 내의 어떠한 폴더가 될 수도 있다.저장소는 각 사용자들이 보내온 작업 복사본과 비교를 하여 가장 최신의 버전을 유지한다. 또한 각 작업물에 대한 변경 이력을 기록하여 해당 파일이 어떤한 수정 과정을 거쳤는지에 대한 정보를 제공하는 역할을 한다. 이러한 저장소에 접근하기 위해서는 저장소에 대한 접근 권한을 가진 사용자 이름을 등록해야 하며, 사용자 이름 등록은 팀 내 SVN 관리자를 통하여 받을 수 있다.
  • 작업 복사본 Working Copies
    작업 복사본은 저장소에서 내려받은 ‘복사본’을 의미한다. 해당 자료는 저장소에 보관되어 있는 최신 버전과 내용이 동일하며, 내용을 어떤식으로 변경을 하더라도, 저장소의 내용과는 무관하기 때문에 안전하게 작업을 진행 할 수 있다. 작업 복사본을 커밋하게 되면 작업 복사본에서 변경 된 내용이 저장소로 전송되며, 저장소는 해당 변경 사항을 반영하여 저장한다.자신 이외의 다수의 사용자가 SVN을 이용하고 있을 경우, 경우에 따라서는 나의 작업 복사본은 저장소에 저장된 내용과 비교하여 최신의 내용이 아닐 수 있다-이 때는 업데이트 Update 명령을 이용하여 자신의 작업 복사본을 갱신해야 한다. 물론, 자신의 작업물을 다른 사용자들도 공유 할 수 있도록 자신의 작업 결과물을 저장소에 커밋을 하는 것도 잊지 말아야 한다.
  • 리비전 Revision
    리비전은 작업물에 대한 일종의 버전 Version 으로 작업물에 대한 고유 번호이다. SVN은 작업물을 저장소에 등록 할 때 마다 등록 시점에 대한 고유 번호를 지정한다. 사용자가 작업물을 등록하면 해당 등록물 전체에 대하여 동일한 리비전이 붙게 된다.리비전이 붙는 방식은 단순하다. 누군가가 작업물을 커밋 하면 현재 리비전 번호에 +1 이 더해진다. SVN에서는 이러한 리비전을 검색하여 변경 이력 등을 확인 할 수 있다.
  • 기록 Log
    SVN 은 각각의 리비전에 대해 기록을 남겨둔다. 여기에 작업 결과물을 등록 할 때 사용자는 적당한 메시지를 입력 하여 해당 기록에 첨부 할 수 있는 기능이 존재한다. 이러한 기록 메시지는 다른 팀원들이 해당 작업물의 변경 사항을 확인하는데 많은 도움을 준다. 기록 메시지은 사용자의 편의에 의해서 사용 할 수 있기 때문에 몇몇 작업자들은 해당 기능을 귀찮아하고 메시지을 남기는 것을 등한시 하는 경우가 있는데, 원할한 프로젝트 커뮤니케이션을 위해서는 기록 메시지 기능을 적절하게 사용하여 주는 것이 좋다.
  • 충돌 Conflict
    동시에 같은 파일을 두 명 이상의 사용자가 수정 하고 이를 각각 커밋 할 경우, 해당 파일은 충돌을 일으키게 된다. 충돌이 일어날 경우 해당 파일의 수정 내용을 병합 Merge 하거나, 혹은 두 파일 중 하나를 최신으로 지정하여 충돌 상태를 해결해야 한다. 충돌이 일어난 파일을 제때 처리하지 않게 되면, 최신 작업물을 제대로 확인하지 못하는 문제가 발생 할 수 있으므로, 충돌이 일어난 작업물은 즉시 충돌 상태를 정리해야 한다.
  • 병합 Merge
    작업 복사본과 저장소에 있는 파일의 내용이 다를 경우, 병합 작업을 통하여 두 파일의 내용을 합치게 된다. 병합 과정은 주로 Text 파일 형식의 작업물에서 동작을 하게 되며 어플리케이션 데이터Application Data-그래픽 저장 파일(JPG, GIF 등)이나 문서 파일(DOC, PPT 등) 같이 전용 프로그램을 이용하여 만들어지고 저장된 데이터-나 바이러니 파일 Binary Files 의 경우 이러한 병합 기능이 별도로 지원되지는 않는다.
Previous post 게임 개발자를 위한 SVN (1)
Next post 게임 개발자를 위한 SVN (3)