바람직한 소스 코드 관리 전략 #1

얼마 전에 제가 오늘의 소프트웨어이야기라는 제목으로 소스 코드 관리 전략의 핵심에 대해 잠깐 쓴 글을 기억하는 분이 있으신지요. 이와 더불어 아주 오래 전에 소스 코드 복사의 위험성이라는 글을 기억하는 분이 계신지 모르겠습니다.

소스 코드 복사의 위험성이라는 글을 정리해서 얘기한다면,

"소스 코드를 복사해서 재사용하면 복사하는 코드에 있는 버그도 함께 전체 소프트웨어 시스템내에 계속해서 증식하게 되는 문제가 있습니다"

라고 할 수 있습니다. 그리고, 오늘의 소프트웨어이야기에서는 소스 코드 관리 전략의 핵심은 관리하는 코드양을 얼마나 줄이냐이다라고 언급했었습니다.

그렇다면 이 두 가지 이야기가 어떤 연관이 있을까요 ? 이에 대한 대답은 이 글을 끝까지 읽으면 자연스럽게 이해하게 되시리라 생각합니다. 자~ 그러면 그 해답을 얻기 위해서라도 제 글을 끝까지 읽어주시길(2편까지 ^^;) 부탁드립니다. 굽신 굽신~

소스 코드 관리 비용

얘기를 본격적으로 풀어 나가기 전에 소스 코드 관리 비용이란 무엇인지부터 생각해 봐야할 것 같습니다. 제가 생각하는 소스 코드 관리 비용이란 주로 소스 코드에 포함된 결함을 수정하는데 드는 비용입니다. 이외에도 소스 코드 관리 툴을 잘 유지하는 비용, 소스 코드 저장 공간을 잘 관리하는 비용 등이 있겠지만 이러한 비용은 결함을 수정하는 비용에 비하면 아주 사소하므로 대세에는 영향을 미치지 못할 것입니다. 따라서 이 글에서는 결함 수정 비용을 주 논의 대상으로 삼겠습니다.

결함 수정 비용은 상식적으로 생각해 봐도 소프트웨어의 규모에 비례해서 증가할 것이라는 것을 예상할 수 있습니다. 그래서 소프트웨어의 품질에 대해서 얘기할 때, defects/KLOC 단위를 많이 사용합니다. 즉, 1000(K) 라인(Line Of Code) 당 알려진 결함의 개수를 기준으로 소프트웨어의 품질이 원하는 수준에 이르고 있는지를 측정하는 것이지요. 그리고, 그 개수가 원하는 수준 이하로 떨어질 때, 릴리즈를 결정하게 됩니다. 그런데 잘 생각해 보면 이것은 알려진 결함의 개수이지 알려지지 않은 결함의 개수를 나타내는 것은 아닙니다. 따라서 릴리즈 이후에도 결함 수정을 위한 비용은 계속 발생하기 마련입니다.

모든 관리 활동의 속성이 그렇듯 소스 코드 관리 활동도 결국은 관리 비용 대비 효용이 클 때, 그 가치가 있다고 하겠습니다. 관리하지 않을 때의 단순한 불안감을 없애기 위한 것도 아니고, 조직 평가에서 소스 코드 관리 활동 지표가 포함되어 있어서 그걸 단순히 만족하기 위한 것도 아닙니다. 그런 것들을 위해 소스 코드를 관리한다면 그런게 바로 관리를 위한 관리라고 할 것입니다. 즉, 아무런 효용도 없이 비용만 발생시키는 관리 활동인 것이지요.

소스 코드 관리의 효용성

소스 코드 관리의 비용이 무엇인지 알았다면 당연히 소스 코드 관리의 효용성이 무엇인지 알아야 할 것입니다. 소스 코드 관리의 효용성에 대해 학문적으로 접근할 수도 있겠지만 제가 지금까지 경험한 바에 의하면 소스 코드 관리의 효용성은 다음과 같습니다.

• 소스 코드 수정 후에 전에 없었던 새로운 문제가 발생했을 때, 문제를 발생시킨 코드를 빠르게 찾아낼 수 있다.
• 여러 사람이 동시에 개발하는 경우, 동일 소스를 수정하는 경우를 방지하거나 수정 내용간의 충돌을 쉽게 관리(또는 해결)할 수 있다.
• 개발 버전과 릴리즈 버전을 따로 관리함과 동시에 개발 버전과 릴리즈 버전간의 싱크를 유지할 수 있다.
• 소스 코드를 관리하지 않을 경우 어떤 것이 가장 최신의 수정 내용을 포함하고 있는 소스인지를 판단하기 어렵지만 소스 코드 관리 툴을 활용할 경우, 항상 최신의 소스가 저장소에 저장되어 있다. (소스 코드를 관리하지 않는 조직일 경우, 항상 이런 질문들을 하기 마련입니다. "야! 어떤 게 최신 소스야~?" "이거 저번에 그 문제 해결한 그 버전이야 ?" ㅋㅋㅋ)

물론 이외에도 많이 있겠지만 이 정도이면 실제 개발 현장에서 피부로 느낄 수 있는 효용성을 잘 표현하고 있다고 생각합니다. 소스 코드를 관리하지 않는 조직의 경우 대규모의 소프트웨어를 개발하기는 거의 불가능하다고 봐야 할 것입니다. 혹시 개발하고 있다고 하더라도 엄청난 개발 비용 부담에 허덕이게 될 것입니다.
 

소스 코드 관리 관련 질문

여러분이 속한 조직은 어떤 방식으로 소스 코드를 관리하시나요 ? 다음과 같은 질문에 답변하다보면 소스 코드 관리 활동을 명확하게 이해할 수 있을 것 같습니다.

1. 소스 관리 툴은 사용하시나요 ?
2. 소스 관리 툴은 어떤 걸 사용하시나요 ?
3. 수정된 소스를 어떤 시점에 소스 코드 저장소에 Commit를 하시나요 ?
4. 현재의 개발 싸이클이 완료되어 소프트웨어를 릴리즈하고 나서 다음 개발 싸이클을 시작하기 전에 어떤 조치를 취하시나요 ?
5. 개발 버전의 소프트웨어와 릴리즈 버전의 소프트웨어를 어떤 식으로 관리하시나요 ?
6. 이전 프로젝트에서 개발했던 컴포넌트를 현재 개발 중인 프로젝트에서 재활용할 때 어떤 식으로 하시나요 ?
7. Open Source 를 자사의 요구사항에 맞게 수정해서 개발하고 난 후 어떤 조치를 취하시나요 ?
8. 사내 조직간에 소프트웨어 컴포넌트를 어떤 식으로 공유하시나요 ?

제대로된 소프트웨어 개발 조직이라면 위와 같은 질문에 대한 나름대로의 답변을 가지고 있어야 할 것입니다.

그럼 이러한 질문들에 대해서 여러분이 속한 조직은 어떤 답변을 가지고 계시나요 ?

소스 관리 툴의 활용 및 전파

우선 첫번째, 두번째 질문을 함께 생각해 보겠습니다. CVS, SVN, ClearCase와 같은 소스 관리 툴의 도움 없이 소스 코드를 관리하는 조직이라면 아마 소스 코드 관리가 거의 되지 않는다고 하는 편이 맞을 것 같습니다. 툴을 활용하지 않고 소스 코드 관리 효용성을 이끌어 내기란 무척 어렵기 때문입니다. 툴의 도움 없이 소스 코드를 관리하려면 관리 비용이 지나치게 커지게 되기 때문입니다. 현재 자신이 속한 조직에서 소스 코드 관리 툴을 사용하지 않는다면 지금이라도 당장 문제의 심각성을 책임 있는 사람에게 알려줘야 할 것입니다.

제가 소프트웨어 개발자로서 경력을 쌓기 시작할 때쯤(1996년경)에는 주변에 소스 코드 관리 툴을 사용하는 조직이 거의 없었습니다. 그리고, 제가 다녔던 회사에서 소프트웨어 개발을 시작한 것도 제가 입사를 한 시점과 같았기 때문에 소스 코드를 관리해야 한다는 개념조차 없었지요. 1,2년 정도 개발 경험을 갖게 되니 소스 코드 관리가 필요하다는 것을 자연스럽게 느끼게 됐고, 오픈 소스에서 많이 활용하던 CVS 를 도입하게 됐었습니다. 그리고, 그 툴을 제가 다니던 회사에서 전반적으로 쓰게 되기까지는 5년이란 시간이 필요했습니다. 제가 다니던 회사는 고작 50명 정도 규모였습니다. 그런 조직에서도 간단한 소스 코드 관리 툴이 퍼질 때까지 그렇게 오랜 시간이 걸렸으니 조직을 변화시키기 위해 얼마나 인내심이 있어야 하는지 감을 잡으셨으리라 생각합니다.

물론 제가 회사의 정책을 정할 수 있는 위치는 아니였기 때문에 그 툴이 자리를 잡는데 시간이 걸렸다고 예상할 수도 있겠지만, 소스 코드를 관리한다는 것은 관리자가 밀어붙인다고 되는 일이 아니라 개발자들의 매일 매일의 개발 습관에 스며들어야 하는 것이므로 어느 조직에서나 상당한 시간을 필요로 할 것입니다. 아래로부터의 개혁이던 위로부터의 개혁이던 상당한 인내심을 가지고 변화를 추진해가야 할 것입니다.

소스 코드 Commit 정책

그 다음 질문으로 넘어가 보겠습니다. 수정된 소스를 소스 코드 저장소에 집어 넣는 것을 Commit 이라고 한다는 걸 대부분은 알고 계시리라 생각합니다.

이 Commit 정책은 프로젝트마다 달라질 수도 있겠지만, 저 같은 경우 상당히 공격적인 정책을 주로 사용했었습니다. 현재 수정 또는 작성 중인 소스에 대해 일단 에러 없이 컴파일이 완료되면 바로 소스 코드 저장소에 그 소스에 대해 단위테스트를 거치지 않고 Commit 하도록 했습니다. 다음과 같은 가정에서 이러한 정책을 따랐습니다.

1. 어차피 통합 이전에는 개발자들이 각자 독립적인 모듈을 작성하므로 단위테스트를 거치지 않은 코드가 소스 코드 저장소에 들어가더라도 서로의 작업에 영향을 미치지 않을 것이다.
2. 단위테스트를 완료한 후에 Commit 하게 되면 컴파일과 단위테스트 완료까지 발생한 수정 내용을 잃어버리게 된다. 실질적으로 이 시기에 발생한 수정로그를 분석하면 개발자들이 쉽게 실수하는 것들을 알아낼 수 있다. (이를 위해 저는 개발자들이 Commit 할 때, 비교적 상세한 Commit 로그를 꼭 작성하도록 했습니다)

1, 2번의 가정이 참으로 성립하는 경우가 상당히 자주 있다고 생각합니다. 그렇지 않은 경우에는 제가 따랐던 정책과는 다른 정책을 따라야겠지요. 1번의 가정은 어차피 통합 이전에만 성립할 수 있으므로 통합 단계에 들어가게 되면 아무래도 저처럼 공격적인 정책을 취하기는 힘들거라 생각합니다. 또한 요즘 Agile Method 에서 권장하는 지속적 통합(Continuous Integration)기법을 활용한다면 1번의 가정이 성립하기 힘들겠지요.

2번의 가정은 만약 개발 프로세스 상에서 개발자들이 단위테스트를 정형화된 형태에 따라 수행하게 한다면 성립하기 어려운 가정일 것입니다. 이런 경우 보통은 별도의 문서로 단위테스트 결과와 수정 내용을 남기게 되니까요. 그렇지만 이렇게 별도의 문서로 로그를 남기게 할 경우 개발자들은 보통 그러한 문서를 최소화해서 작성하기 마련입니다. 거의 흉내만 내게 됩니다. 개발 프로세스는 최대한 가벼워야 하고, 개발자들의 개발 환경과 개발 습관 속에 자연스럽게 녹아들어갈 수 있는 형태가 되어야 합니다. 그런 측면에서 본다면  되도록 2번의 가정은 참이 될 수 있도록 유지하는 것이 좋다고 생각합니다. 물론 실제 개발 현실이 그렇지 않은 경우, 제가 따랐던 정책은 오히려 좋지 않을 수도 있긴 하겠지요.

제가 따랐던 방식 외의 다른 정책을 생각해 본다면,

1. 매일 매일 주기적으로
2. 별도의 Task 관리 시스템(TRAC, ClearQuest 등)에 정의된 단위 Task 가 완료됐을 때
3. 모듈별 단위 테스트가 완료된 후
4. 프로젝트 완료 후에 한꺼번에

등이 있을 것입니다. 1번, 4번 같은 방식은 특별히 그렇게 할만한 이유를 발견하기 어려워서 저 같은 경우 권장하고 싶지 않은 방식입니다. 2번, 3번 방식은 나름의 장점이 있는 경우가 있으므로 자신의 프로젝트 상황 및 조직의 개발 프로세스 등을 고려하여 따르시면 될 것으로 생각합니다.

다음글을 기약하며

다른 글을 쓸 때도 그랬지만 이 글을 쓰면서도 역시나 애초에 쓰려고 마음 먹었던 것보다 훨씬 더 많은 부분들을 건드리는 바람에 글이 길어지고 말았습니다. 나머지 질문들에 대해서도 다음 글을 통해 답변해 보면서 바람직한 소스 코드 관리 전략에 대한 담론을 이어가도록 하겠습니다.

중구 난방인 글 읽어 주셔서 감사합니다. ^______^

제 글이 유익하셨다면 오른쪽 버튼을 눌러 제 블로그를 구독하세요. ->
블로그를 구독하는 방법을 잘 모르시는 분은 2. RSS 활용을 클릭하세요.
RSS에 대해 잘 모르시는 분은 1. RSS란 무엇인가를 클릭하세요.

다음글 예고편: C++ 이야기 열일곱번째: 임시 객체는 임시 객체일뿐
다음글도 기대해 주세요~~~ :)