소스코드는 어디 있나요?

나와 우리 회사에서는 소프트웨어 관련 경영 및 공학 컨설팅을 주로 하지만 드물게 개발을 해야 할 때도 있습니다. 이런 경우 고객 회사의 개발자와 협업을 하게 되는데 "소스코드는 어디 있나요?"라는 질문을 먼저 시작합니다.

"소스코드는 어디 있나요?"라는 질문은 Subversion등과 같은 소스코드관리시스템이 어디 있냐는 질문이고 모든 소스코드는 당연히 거기에 저장되어 있고 소스코드가 저장되어 있는 Repository와 Path만 말면 Build script를 찾아서 빌드까지 한번에 끝낼 수 있을 것으로 기대하고 하는 질문입니다. 사용자 ID만 등록하고 필요한 권한만 열어주면 더이상 질문할 것도 없이 협업 준비는 끝나는 겁니다.

그런데 이렇게 해피하게 준비된 경우는 아직 본적이 없습니다.

대부분 아래와 같은 답변들이 돌아옵니다.

• 내 PC에 소스코드가 저장되어 있습니다. 
• 아직 정리가 안되서 소스코드관리시스템에 등록하지 않았습니다.
• 빌드는 IDE(Eclipse 등)에서 해야 합니다.
• 빌드하기 위해서는 이런 저런 라이브러를 알아서 직접 설치해야 합니다.
• 아참, 설정을 이렇게 바꿔야 하는데 깜빡했습니다.
• 지금 내가 소스코드를 고치고 있어서 공유가 어렵습니다.

이런 얘기가 진행되는 동안에 일은 정상적으로 진행이 되지 못하고 여러 번 만나서 대화로 소스코드 공유 문제를 해결해나가야 합니다. 

혼자서 또는 개발자들끼리 익숙해져서 나름대로 방식으로 소스코드를 관리하면서 스스로 아무 문제가 없다고 생각하고 있는 개발자들은 냄비 안에서 물이 점점 뜨거워져서 죽는 개구리처럼 소스코드관리 문제가 점점 커져서 문제가 얼마나 심각한지 인식하고 있지 못하고 있는 겁니다. 이는 기본 중에 기본으로 자꾸 소스코드 관리 문제를 가지고 얘기를 하면 민망하고 한심하기도 합니다.

소스코드를 꽉 쥐고 요청하는 사람들에게 '모이'주듯이 하나씩 던져 주는 개발자들은 이로 인해서 얼마나 많은 자신의 시간을 낭비하고 있고 정작 자신이 제대로 개발할 시간은 모자라고 회사에도 손해를 끼치며 자신의 발전도 가로막는다는 것을 알아야 합니다.

정상적인 경우는 다음과 같습니다.

개발자가 1명이든 100명이든 1000명이든 상관없이 모든 소스코드는 당연히 소스코드관리시스템에 등록이 되어 있어야 합니다.  구차하게 이거 저거 물어보지 않아도 소스코드가 저장된 경로만 알면 누가나 소스코드를 Check out해서 클릭 몇 번이면 Build Script를 찾아내서 즉시 빌드를 할 수 있어야 합니다. 당연히 컴파일러 등의 빌드 환경은 설치가 되어 있어야죠. 여러명이 동시에 소스코드를 마구 고쳐도 전혀 걱정할 필요가 없어야 합니다.

이때 구차하게 이거 저거 물어 봐야 빌드가 되고 IDE를 실행 해야 하고, 빌드 중간에 명령어를 입력해야 하는 등의 바로 알기 어려운 행위들을 해야 하면 안됩니다.

이 정도는 되어 있어야 Daily Build가 가능해지고 프로젝트 내내 소스코드 관리 비용을 최소화 할 수 있습니다.

이 정도는 되어 있어야 엄청 복잡한 소스코드 상황을 깔끔하게 관리할 수 있습니다.

이 정도는 되어 있어야 내가 휴가를 가도 아무나 빌드를 할 수 있습니다.

이 정도는 되어 있어야 개발자들이 빌드를 하지 않고 빌드 담당자에게 빌드를 맡길 수 있습니다.

이 정도는 되어 있어야 누구와도 심지어는 외부인과도 협업을 할 때 말 한마디면 소스코드 공유 준비는 끝납니다.

이 정도는 되어 있어야 개발자는 진짜 개발에 집중할 수 있습니다.

이게 뭐 큰 일이냐라고 생각할지 모르지만 이렇게 생각하는 개발자는 위에서 얘기한 기초 중의 기초가 안되어 있다고 생각하면 됩니다.

소스코드 관리는 워낙 기초이기 때문에 누구나 제대로 방법만 익히면 제대로 수행하는데 오래 걸릴 일도 아닙니다. 똑똑한 개발자라면 일주일이면 방법을 다 터득합니다. 분석, 설계 작업이 방법을 제대로 익히고도 제대로 하는데 수년이 걸리는 것과는 안전히 딴판입니다. 그럼에도 아직도 많은 개발자들이 소스코드 관리를 제대로 하고 있지 못하거나 제대로 하려고 흉내는 내는데 엉뚱한 곳에서 헤매는 경우가 많습니다. 원리는 매우 간단한데 말입니다.

소프트웨어 개발이라는 것이 협업이라는 것을 깨달으면 됩니다. 혼자서 개발하더라도 협업과 똑같습니다. 그렇게 해야 더 혼자 개발하더라도 더 빨리 개발할 수 있고 여럿이 개발할 때는 더욱 더 중요합니다.

소스코드관리시스템을 쓰기는 하는데 어중간하게 흉내만 내고 있다고 생각한다면 한번 확실하게 제대로 배워 놓을 필요가 있습니다. 그렇지 않으면 평생 기초 중에 기초에 문제거리를 안고 가는 겁니다.  

Copy & Paste의 종말

직업상 다른 개발자들이 작성해 놓은 코드를 볼 기회가 정말 많습니다.

그러다보면 자주 접하는 것이 복사된 코드들입니다. 

소소코드 Copy & Paste는 개발자의 대단히 큰 잘못입니다. 즉, 소스코드를 복사해 놓는 것은 쉽지만 그로 인해서 지속적으로 회사와 후배들이 부담을 져야 하기 때문입니다. 즉, 회사의 생산성을 갉아 먹는 행동입니다. 그런 개발자는 해고가 되어야 마땅하지요.

한쪽 제품이나 컴포넌트에서 사용한 함수나 소스코드들을 복사해 와서 다른 제품이나 컴포넌트에서 사용하는 것입니다. 동일하게 그대로 사용하는 경우도 있고, 약간 수정해서 사용하는 경우도 있습니다.

이런 일이 반복되다보면 비슷한 코드들이 회사의 전체 소스코드 중에서 여기 저기 산재하게 됩니다. 그러다가 버그가 발생하는 그중 일부는 고쳐지고, 일부는 여전히 버그를 가지고 있습니다. 또 해당 기능이 변경이 될 때도 이를 모두 찾아서 변경하기란 쉬운 일이 아닙니다. 이쯤 되면 개발은 창의적인 작업이 아닌 점점 노동이 되어 갑니다.

이런 공통적인 소스코드들은 공통모듈을 잘 계획해서 공통적으로 사용할 수 있어야 합니다. 공통모듈은 전사적으로 관리가 되어서 효율적으로 사용할 수 있도록 해야 하며, Copy & Paste의 욕구가 생겨도 시간을 약간 더 들여서 공통모듈화 하는 노력을 들이는 것이 필요합니다.

공통모듈을 관리하려면 당연히 소스코드관리시스템을 잘 사용해야 하고, 각 제품이나 컴포넌트들이 공통모듈들과 더불어 효과적으로 빌드가 가능하도록 빌드 스크립트도 준비가 되어야 합니다.

Peer review, code review가 정착되어서 다른 팀에서 서로 모르고 중복된 작업을 하는 것을 줄여야 합니다.

또, 특정 고객을 위한 커스트마이즈된 제품을 만들 때 대규모 소스코드 복사가 일어나는데, 이를 통제없이 만들고 방치하면 함수 몇개 복사한 것과는 비교도 안되는 큰 비용을 치뤄야 합니다. 물론 상황에 따라서 다르기는 하지만, 이런 경우에는 가능하면 소스코드 브랜치를 줄이고 브랜치를 만들더라도 소스코드관리시스템을 이용하여 잘 관리를 해야 합니다. 그리고 추후 Merge를 통해서 브랜치의 수명 주기를 짧게 가져갈 필요가 있습니다.

여기저기 복사된 쌍둥이 소스코드들... 참 문제가 아닐 수 없습니다.

소스코드가 그렇게 중요한가요?

소스코드를 신주단지 모시듯 하는 회사나 개발자들을 자주 볼 수 있습니다.

소스코드가 자신들의 모든 기술이 함축된 집합체라고 생각들을 합니다.

 

저는 이런 회사나 개발자들 딱 접하는 순간 그 수준을 한번에 알 수 있습니다. 다른 것들은 별로 물어볼 필요도 없이 그로 인해서 회사가 어떤 식으로 개발을 하고 있다는 것을 쉽게 짐작할 수 있습니다.

 

그러한 회사들은 소스코드를 개발자를 제외한 다른 직원들은 접근하지 못하도록 하기 위해서 보안장치를 두고 개발자는 자신이 작성한 소스코드를 공유하기 꺼려하기도 합니다. 개발의 내용은 SRS나 설계서에 포함되어 있기보다는 그냥 코드에 숨어 있어서 이를 작성한 사람이 아니면 전체를 파악하기 정말 어렵습니다. 해당 개발자가 아니면 유지보수가 어렵고 신입사원이 들어와도 공유가 잘 안됩니다.

 

이런 말이 있습니다.

"경쟁회사를 어렵게 만들고 싶으면 자사의 소스코드를 실수인척하고 공개해서 경쟁회사로 흘러 들어가게 하라"

그 경쟁사는 소스코드를 얻고 횡재한 줄 알겠지만, 이를 분석하다 보면 몇 달 후 별로 얻은 것은 없이 시간만 낭비했다는 것을 알게 될 것입니다.

 

가슴에 손을 얹고 생각해보면 우리가 작성하는 소스코드 중에서 정말 획기적인 것이 있나요? 남들은 절대로 만들지 못할 엄청나게 어려운 것이 있나요? 대부분은 이미 다 공개된 알고리즘과 모듈들입니다. 물론 그런 것들이 있다면 잘 지켜야 겠지요. 하지만 그런 경우는 거의 찾아보기 힘듭니다.

정작 중요한 것은 그 아키텍처이고, 스펙입니다. 그리고 개발자들의 역량과 팀웍이죠. 그것들이 다른 회사와 우리 회사를 다르게 만들어주는 요소입니다. 소스코드는 아니죠.

 

물론 소스코드가 소프트웨어를 이루는 중요한 요소이기는 하지만 소스코드의 보안에만 신경 쓰는 순간 자신의 수준을 확 낮춘다는 것을 알아야 하겠습니다.