기업내 오픈소스 개발 방식 도입記

http://www.zdnet.co.kr/itbiz/column/anchor/scyoon/0,39030409,39175288,00.htm 기업내 오픈소스 개발 방식 도입記 윤석찬(다음 R&D 센터 팀장)   2008/11/16 04:50:07 PM

[지디넷코리아]최근에 오픈 소스 소프트웨어(Open Source Software)가 인기를 끌고 상용 S/W의 대안으로 자리 매김 하면서 많은 IT 기업들이 오픈 소스 소프트웨어를 개발 현장에서 사용하기 시작했다.  과거에는 제품 개발 시 비용 절감을 위해 단순히 차용하는데 머물고 있었으나, 최근에는 자사의 제품을 직접 오픈 소스로 공개하고 개발자 커뮤니티를 제품 개발에 끌어들이는 것은 이제 일반화 되고 있는 실정이다.  노벨, 썬마이크로스시스템즈, IBM, 오라클, 레드햇 같은 해외 유수 기업은 물론 국내에서도 삼성 SDS의 애니프레임, NHN의 큐브리드 등이 대열에 동참하고 있다.  하지만, 흔히 ‘프로젝트’라고 부르는 기업의 제품 개발 방식과 개발자 커뮤니티에서 오픈 소스 소프트웨어가 만들어지는 방식이 다르기 때문에 문화적 혹은 기술적 차이가 생기게 된다. 만약 자사의 제품을 오픈 소스 방식으로 개발하고 싶다면 많은 부분을 고려해야 한다.  오픈 소스 개발 방식은 다수 사용자의 버그 리포팅과 개발자 사이의 엄격한 상호 코드 리뷰를 기반으로 진행되는 특징을 가지고 있다. 오픈 소스 커뮤니티는 태생적으로 원격지에서 전혀 모르는 개발자들 사이에 만들어지기 때문에 개발 과정에서 온라인 프로세스의 엄격성은 매우 중요하고 잘 지켜진다.  하지만, 회사의 경우 개발팀 내에서 주로 직접 대면을 통한 의 의사 소통에 의해 개발이 이루어지기 때문에 문화적 차이가 존재한다.  특히, 시스템 통합(SI) 같은 기업형 프로젝트에서 CMMI 준수나 인수 인계 혹은 회계적 요구 사항에 의해 도입되는 전통적인 프로젝트 관리 시스템은 개발자들로 하여금 더 많은 비용을 야기 시키는 경향이 있다. 우리 회사에서도 과거 일정 관리 PMS가 있었는데 분기나 반기가 끝나면 형식적인 입력을 했었다.  따라서, 오픈 소스 개발 방식과 전통적 프로젝트 관리 방식 사이에서 적합한 솔루션을 찾는다면 효율성 측면에서 좋은 결과를 얻을 수 있을 것 같다. 아래는 몇 년 전부터 다음(Daum)에서 오픈 소스 개발 방식을 기업에서 차용하기 위해 시도했었던 몇 가지 노력에 대한 경험을 공유해보고자 한다. (1) 소스 코드를 한곳에  2004년 처음 입사 했을 때 우리 회사 개발 프로세스에는 몇 가지 문제점이 있었다. 우선 각 서비스 소스 코드가 각 팀들이 별도의 레포지터리(Repository)에 보관하고 있었는데 그러다 보니 서비스 중단 혹은 조직 개편으로 중간에 뜨는 것들이 생기고 있었다. 게다가 팀마다 CVS, 서브버전(Subversion), 소스세이프(SourceSafe) 등 다양한 소스 콘트롤을 사용했다.  가장 먼저 시도한 것이 바로 '소스 콘트롤 및 저장소 일원화’였다. 기존에 많은 팀에서 사용하던 CVS에서 서브버전으로 옮기는 작업을 했다.  서브버전은 CVS이 비해 체인지셋(Change Set) 단위 커밋(Commit)이 가능하고 파일 및 디렉토리 관리가 편하기 때문에 코드 변경 횟수나 파일이나 디렉토리명 변경이 자주 이루어지는 웹 개발 현장에서 훨씬 좋은 것으로 판단되었다.  특히, 서브버전은 웹으로 관리하도록 개발하기 용이한 구조로 되어 있어서 아직도 당시 만든 사용자 인증, 레포지터리 생성 및 관리 도구는 별 불편 없이 사용하고 있다. 당시 서브버전이 이클립스 플러그인 안정성 등 많은 이슈가 있어서 어려움이 많았지만 다행히 수백 개나 되는 전사 소스 코드가 한 자리로 모일 수 있었다. (2) 사소한 것부터 문서화  오픈 소스 프로젝트에서는 누구나 알만한 것들이나 알쏭달쏭한 것들을 모아서 문서로 잘 만들어 둔다. 누구나 다 알고 있을 것이라 여기는 사소한 것들부터 논쟁이 될만한 사안까지 다양한 문제를 하나의 문서로 제공해 주는 일은 꽤 유익한 일이다. 우리 회사에서는 오래 전부터 자바(Java)를 주 언어로 사용해오면서 언어를 어느 정도 일원화해 왔기 때문에 개발자가 갖추어야 할 기술 지식에 대해 각 팀 별로 크게 다르지 않았다.  하지만, 각 팀 내 개발자에 따라 꽤 다른 코딩 습관 때문에 코드 리뷰나 이동이 일어나면 다양한 개발 이슈들이 자주 생기고 있었다.  우선 자바 코딩 컨벤션 번역문과 회사 내 코딩 컨벤션을 합쳐 문서화 하고 여기에 주석 가이드, SQL 작성 가이드, 사내 SW 라이센스 규정, 파일 및 디렉토리 명명 표준화, 코드 리뷰 프로세스 등 개발 중에 질문할 수 있는 것들을 묶어 문서로 제공하였다.  오픈 소스 커뮤니티에서도 이렇듯 자주 질문하는 내용에 대한 문서 정리가 매우 잘 되어 있다. 따라서, 회사 내 자질구레한 개발 프로세스에 대한 지식들을 모아서 문서로 제공하는 것은 가장 기본적인 일에 속한다. 이런 것들을 한번 문서화 해 두면 신입 이나 경력 개발자들이 들어와서 빠르게 업무를 파악 가능하기 때문이다. (3) 생산성 높은 프로젝트 관리 도구 제공  오픈 소스 개발 방식에서 사용하고 있는 대표적인 도구는 포지(Forge)류라고 불리는 프로젝트 관리 도구이다. 이들 소프트웨어는 프로젝트 생성 및 관리, 개발자 관리, 문서화, 게시판, 메일링리스트, 소스 콘트롤, 버그 트래커 등 다양한 기능을 제공해 준다. 온라인에서 널리 이용되는 것 중에 소스포지(SourceForge.net), 지포지(GForge.org) 등을 들 수 있다.  초기에 회사 공통 라이브러리 및 공용 소프트웨어를 위해 GNU Forge를 도입하고 사내 개발자 참여를 유도 했었는데, 실패로 끝났을 정도로 활용도는 극히 미비했다. 대표적인 이유가 포지 소프트웨어의 사용 편의성이 낮고 불필요한 기능이 많다는 점이었다.  따라서 최근 나온 Google Code나 LaunchPad.net 같은 신규 오픈 소스 프로젝트 호스팅 서비스를 보면 문서화, 버그트래킹, 소스콘트롤 등 심플하고 필요한 기능만 딱 제공 되고 있다. 많은 점에서 기존 포지 소프트웨어를 기업에서 바로 가져다 쓰기는 곤란하다고 본다.  2006년부터 각 개발팀에서 서브버전과 궁합이 잘 맞는 Trac이라는 프로젝트 관리 도구 이용에 대한 요구 사항이 들어오기 시작했는데 지금은 신규 레포지터리 중 대략 40% 정도가 트랙(Trac)을 이용하고 있다. 따라서, 각 회사에 맞는 적당한 프로젝트 관리 도구를 필요에 따라 제공하면 생산성을 높일 수 있을 것 같다. (4) 쉬운 문서화: 위키 통합 공간  개발자들에게 문서화를 촉구해 보면 대부분 템플릿을 요구한다. 도대체 어떻게 문서화 해야 할지 모르는 경우가 많기 때문이다. 전통 기업 프로젝트에서는 이를 위해 정형화된 워드, 엑셀, 파워포인트 양식이 있다.  아마 이런 것들은 어느 개발자나 한번쯤은 본적이 있을 것이다. 이 템플릿들의 문제점은 그 양식만 보고도 학을 뗄 정도로 쓰기 싫어진다는 데 있다. 대부분 필요한 요구 사항을 계속 덧붙이다 보니 배보다 배꼽이 더 큰 양식이 되어 버리기 일쑤다.  이런 탓에 우리 회사에서도 개발 업무 보고, 소스 코드 및 S/W 사용법 문서화 등에 쉬운 문법과 템플릿 그리고 이력(Revision) 관리가 가능한 위키(Wiki)가 주로 쓰이고 있었다. 하지만, 각 팀 취향에 따라 여러 가지 위키를 사용하는 데다 개발자와 기획자의 커뮤니케이션에서 위키가 쉽지는 않았다.  그래서 전사에서 사용할 수 있는 공용 위키 서버를 두어 개인 메모, 업무 보고나 자료 정리 등에 쉽게 위키를 쓰도록 하였다. 원하는 팀은 언제든 위키를 바로 세팅할 수 있다.  각 팀별로 위키 S/W가 일원화에 따라 유지 보수 비용 및 학습 비용이 감소 되고 기획자들도 자연스럽게 위키에 접근할 수 있는 기회가 열렸다. (요즘엔 기획자들도 위키를 쓰는데 익숙할 정도...) 아직 미해결 과제  그 후 2년 전부터 외부 개발자 지원으로 업무를 옮겼지만 위의 사내 개발 지원 서버들은 계속 우리 팀이 관리하고 있다가 얼마 전 기술 자원 담당팀으로 이전을 했다. 그 동안 사내 개발 프로세스에서 오픈 소스 도구와 방식을 잘 이식시켜 왔다고 생각하지만 아직 남아 있는 몇 가지 숙제들이 있다.  첫 번째는 버그 트래킹에 대한 이슈다. 기존 오픈 소스에서는 버그는 원격의 다수 개발자들과 사용자 사이에 TODO 목록이고 작업에 대한 토론과 공유 그리고 리뷰가 함께 이루어지는 제일 중요한 요소다.  하지만, 회사 내 버그(?)는 대개 고객센터로 들어온 문제와 기획자의 의사 결정과 요구 사항이 함께 만들어져 개발자에게 제공되는 방식이다.  즉, 개발자와 기획자 1:1 혹은 팀장과 3자 정도로 공유되고 있다. 따라서 버그 트래커가 거의 불필요하거나 도입했더라도 버그 처리 과정 자체가 번거러운 일로 인식되게 된다. 게다가 소스 이력 관리를 위해 소스 콘트롤과 버그트래커의 유기적인 관계와 데이터 연결이 매우 중요한데도 이런 부분은 문화적으로 쉽게 정착되지 못하고 있다.  두 번째는 여전히 잦은 소스 콘트롤 사용 방법의 오류 문제다. 앞서 말한 대로 웹 개발 코드는 요구 사항이 자주 변경되고 사용자 인터페이스(UI) 부분의 변경도 수시로 일어난다. 그 도중에서 개발자들이 잦은 커밋을 하기 때문에 소스 콘트롤 로그가 아무런 정보를 제공하지 못하는 커밋 로그에 불과한 경우가 많다.  웹과 같은 서비스형 소프트웨어 개발 프로젝트가 늘면서 빠른 개발 방식을 선호함에 따라 잦은 소스 커밋을 브랜치(Branch)에 자유롭게 하고 최종 변경 사항만 트렁크(Trunk)에 할 수 있도록 쉽게 합쳐(Merging) 주는 자동화 도구가 절실한 것도 이런 이유다.  지금까지 나열한 개발 프로세스와 도구는 전통적인 소프트웨어 개발에서도 존재하거나 차용되어 왔던 것들이다. 하지만 오픈 소스 커뮤니티에서는 이를 위한 개발 도구 및 문화를 적극적으로 개방해서 공유함으로서 이러한 혜택을 얻지 못하는 기업에게도 도움이 되고 있다.  소프트웨어 공학자들의 최근 연구 결과에 따르면 오픈 소스 커뮤니티의 오류에 의해 버그가 생길 확률이 기업의 것 보다 더 낮다고 한다. 특히, 오픈 소스 커뮤니티에서 많은 개발자들이 이들 방식을 학습하여 실제 기업에서 적용할 수 있는 기회가 커지고 있다. 이러한 기회를 잘 활용하는 IT 기업에게 미래가 있을 것이다.