Category Archives: 개발

예전에는 중앙 저장소가 있고 모든 개발자가 중앙 저장소에 자신의 작업을 커밋했다. 반면 Git은 분산 저장소를 제공한다. 따라서 중앙 저장소가 있더라도 해당 저장소를 로컬에 복사(clone)하는 순간 로컬에 나만의 저장소가 생긴다. 따라서 예전처럼 원격 저장소에 영향을 미치지 않고 로컬 내에서 브랜치를 만들고, 커밋하고, 롤백하는 일 모두 가능하다.

만약 중앙 저장소에 내 작업을 넣고 싶으면 어떻게 할까? 예를 들어 어떤 저장소를 로컬에 복사한다. 그리고 파일 하나를 수정한다. 원격 저장소에 변경사항을 반영(push)하려하면 변경사항이 없다고 나온다. 이는 예전과는 달리 사용자와 중앙 저장소의 입장이 아닌 로컬 저장소와 원격 저장소의 입장이 되기 때문에 발생하는 일이다. 즉, 로컬 저장소에 커밋을 하지 않았기 때문에 변경이 없다고 보는 것이다. 로컬 저장소에 커밋을 한다. 그리고 다시 변경 사항을 반영해본다. 이제서야  변경사항이 원격 저장소에 적용된다. 방금 얘기한 것이 Git의 가장 기본적 흐름이다.

오픈소스는 소수의 커밋터(Committer)와 다수의 공헌자(Contributor)로 구성된다. 커밋터를 제외한 공헌자는 익명으로 소스를 체크아웃하고 로컬에서 작업한다. 작업이 어느정도 완료되면 패치를 만들어 커밋터에게 적용을 요청한다. 이 모델은 대부분 오픈소스에서 사용하는 개발모델이다. 그런데 문제점이 있다. 바로 공헌자는 패치를 완료하기 전까지 SCM의 이점을 전혀 못 누린다는 점이다. 저장소가 없으므로 중간에 커밋을 할 수도 없고 롤백도 할 수 없다. 당연히 브랜치도 만들 수 없다. 따라서 어떤 공헌자가 한 프로젝트에 대해 여러 패치를 동시에 작업해야 한다면 이는 기존 SVN 환경에서 쉽지 않은 일이다.

Git을 이용하면 방금 얘기한 문제가 해결된다. 중앙 저장소에 권한이 없더라도, 로컬에서 얼마든지 SCM의 장점을 누릴 수가 있다. 작업하다 잘못되면 롤백을 할 수도 있고, 몇 개 브랜치를 만들어 여러 패치를 동시에 작업할 수도 있다. 난 이런 이유로 오픈소스진영에서는 Git을 반길 수밖에 없다고 생각한다.

Git에 대해 긍정적 의견을 내비치는 사람의 근거 중 하나는 오픈소스진영이 점차 Git으로 전환하고 있다는 점이다. 오픈소스 진영은 기술적 트렌드에 민감한 편이고, 오픈소스에 먼저 적용한 기술이 시간이 흘러 대중화되는 것은 매우 자연스러운 흐름이다. 그렇다면 회사에 Git을 도입하는 것은 어떨까? 난 아래 두 가지 이유로 신중한 접근이 필요하다고 본다.

첫째 회사는 오픈소스진영과 개발상황이 다르기 때문이다. 가장 큰 차이점은 오픈소스에는 흔한 공헌자가 없다는 것이다. 팀원 모두 커밋터고, 팀은 저장소 하나를 공유하며 함께 작업한다. 따라서 수정한 것이 있으면 바로 커밋을 하면 된다. 팀원 모두 커밋터로써 SCM의 장점을 충분히 누릴 수 있다.

둘째 지속적 통합에 대한 부정적 영향을 미칠 가능성이 있기 때문이다. 여럿이서 저장소 하나를 대상으로 함께 작업하다 보면 지속적 통합이 무척 중요하다. 다시 말해 동작하는 버전을 자주 커밋하는 게 강력히 권장된다. 이를 잘 지키면 다른 동료에게 빠른 피드백을 줄 수 있고, 통합 시점(보통 QA 혹은 배포 전)에 소스가 충돌이 나 소스를 급하게 수정하는 일도 줄어든다. 그렇다면 Git은 어떨까? 난 Git은 지속적 통합이 추구하는 바에는 잘 안 맞는 것 같다고 생각한다. Git은 로컬 저장소를 제공하기 때문에 로컬에서 커밋하고 롤백하며 작업할 수 있는 좋은 토양을 제공한다. 이로 인해 자주 통합하기보다는 소스를 로컬에 오래 가지고 있는 상황이 생기지 않을까라는 우려가 든다.

누군가는 이렇게 얘기할 수 있다. ‘로컬 저장소가 제공되는 Git을 쓰자. 그리고 예전처럼 자주 커밋하자. 예전과 다를 바가 없지 않나?’ 그런데 여기 약간의 걸림돌이 있다. Git은 SVN, CVS와 달리 중앙 저장소에 바로 커밋할 수 없기 때문이다. Git은 로컬 그 자체가 저장소이기 때문에 우선 로컬 저장소에 커밋을 수행한 후에 로컬 저장소를 원격 저장소에 머지(push)하는 방식으로 통합한다. SVN, CVS를 사용할 때는 단순한 파일 하나를 수정할 때 커밋을 하면 끝이었다. 하지만 Git은 로컬 저장소에 커밋하고 원격 저장소로 머지해야 한다. 즉, 두 단계가 필요한 것이다. 별것 아닌 것 같지만, 개발자가 가장 많이 수행하는 흐름이 좀 더 길어진 것이다. 물론 두 단계를 한꺼번에 수행해주는 도구를 개발하면 쉽게 해결되는 문제이다. 하지만, 도구를 쓰는 단계까지 간다면 Git을 써야 하는 이유가 많이 퇴색되는 게 아닐까?

앞서 소개했지만, Git의 가장 큰 장점은 로컬에 나만의 저장소를 둘 수 있다는 점으로 보인다. 그런데 과연 이 특성이 현장에서 얼마나 필요할까? 예전에 가끔 로컬에서 중간 중간 커밋하고 싶다는 생각을 한 적이 있다. 하지만, 당시 내가 그런 생각을 했던 이유는 지속적 통합을 하지 않고 있었기 때문이었다. 나는 소스를 광범위하게 고치고 있었고, 다음 수정에서 무엇인가 잘못되어 예전에 작업한 부분도 없어질까 봐 두려웠다. 하지만, 지속적 통합을 실천하며 다시 이런 생각을 한적은 없었다. 항상 동작하는 버전을 자주 커밋했다. 때로 1시간에 수십회를 커밋하기도 했다. 테스트가 통과하면 바로바로 커밋하기 때문이다.

가끔 Git과 같은 분산저장소를 사용하면 머지가 편해진다는 얘기를 듣는다. SVN에서 소스충돌은 다른 개발자가 같은 라인을 수정해서 발생하기도 했고, 어떤 때는 SVN의 오판으로 발생하기도 했다. 소스충돌이 일어났을 때 소스를 정리하는 작업은 정말 어렵고 힘들다. 따라서 Git이 머지를 편하게 해준다면 이는 큰 매력이다. 하지만 Git홈페이지(http://git-scm.com/about)를 보면 여러 장점을 소개하지만 머지에 대한 언급은 없다. 어디서 이런 얘기가 나왔는지는 모르겠지만, 확인이 필요한 부분 같다.

Git이 제공하는 가장 주요한 특징은 분산 저장소이다. 많은 오픈소스에서 Git을 잘 쓰고 있는 것처럼, 분명히 분산 저장소라는 특징이 빛나는 상황이 있을 것이라 생각한다. 하지만, 이 점이 Git으로 전환할 만한 충분한 이유가 될까? 난 아직 잘 모르겠다. 지금까지 내가 이해한 수준에서는 전환비용을 감당하면서도 넘어가야 할 이유를 찾기 어렵기 때문이다. 오히려 가뜩이나 잘 되지 않는 지속적 통합을 더 악화시키지 않을까라는 우려가 있다. 하지만 Git이 SVN 보다 머지기능이 탁월하다는 것이 밝혀진다면, 이는 Git으로 전환해야 하는 좋은 근거가 되리라 생각한다.

8. 참고

1) C와 같은 개발 환경에서는 Git이 지속적 통합에 해가 된다기 보다는 오히려 여러 장점이 있다는 의견을 담은 글
http://hyukhur.tumblr.com/post/4126008077/git-for-more-continuous-building

The Code Project Open License (CPOL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Common Development and Distribution License (CDDL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Microsoft Public License (Ms-PL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Mozilla Public License 1.1 (MPL 1.1)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Common Public License Version 1.0 (CPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Eclipse Public License 1.0

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The MIT License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The BSD License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Apache License, Version 2.0

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 예
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The Creative Commons Attribution-ShareAlike 2.5 License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 아니오**
* 라이센스 전파 여부: 예**

The zlib/libpng License

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

공개 커뮤니티에 대한 공헌 (라이센스 아님)

* 저작권 보호: 아니오**
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 아니오
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 아니오

The GNU Lesser General Public License (LGPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 예
* 라이센스 전파 여부: 예**

The GNU General Public License (GPL)

* 저작권 보호: 예
* 상용 소프트웨어에서 사용 가능: 예
* 버그 패치 및 기능 확장 제공의 의무: 예**
* 명시적 특허권 행사 가능 여부: 아니오**
* 사유 프로그램 (소스 비공개 프로그램)에서 사용 가능 여부: 아니오**
* 라이센스 전파 여부: 예**