메뉴 바로가기 검색 및 카테고리 바로가기 본문 바로가기

한빛출판네트워크

한빛랩스 - 지식에 가능성을 머지하다 / 강의 콘텐츠 무료로 수강하시고 피드백을 남겨주세요. ▶︎

IT/모바일

지역적 분산 소프트웨어 개발을 위한 툴들

한빛미디어

|

2007-07-09

|

by HANBIT

11,340

제공 : 한빛 네트워크
저자 : Ryan Bagueros
역자 : 추홍엽
원문 : Tools for Geographically Distributed Software Development

소프트웨어 개발은 보통 푸른 카펫으로 뒤덮여 있고 형광등 불빛으로 치장된 사무실에서 이루어져 왔다. 중요한 토의는 냉수기 주위나 도넛츠를 먹으며 모여있는 엔지니어들에 의해 즉흥적으로 이루어지곤 한다. 프로젝트 의사소통의 많은 부분이 직접적으로 이루어지기 때문에 근무시간동안 사무실 밖에서 시간을 보내는 것은 뒤쳐지게 됨을 의미한다. 현대 세계에서 개발팀은 점점 더 지역적으로 분산되고 있다. 어떤 프로젝트는 그 기간 전체동안 개발자들끼리 서로 만나보지 못하기도 한다. 지역적 분산 개발(Geographically Distributed Development, GDD)은 효율성이나 비용면에서 다수의 보상을 가져다 주지만, 성공적인 GDD 팀을 만들기 위한 몇가지 문제들도 있다. 이 글에서 필자는 GDD가 겪는 문제들에 대해 언급하면서, GDD로부터 많은 이득을 얻어내기 위해 사용했던 몇몇 기술과 툴을 되짚어보려 한다.

우리 소프트웨어 팀은 우선적으로 캘리포니아주의 샌프란시스코와 브라질의 상파울로에 거주하는 사람들로 이루어졌지만, 독일, 네덜란드, 아르헨티나, 베네수엘라의 개발자들을 포함한 프로젝트들을 많이 겪어왔다. 회사가 GDD를 하게 만드는 동기에는 아웃소싱을 통한 비용절감이나 XP와 같은 프로그래밍 방법론을 실험함으로써 개발주기를 단축시키는 능력 등이 있을 수 있다. 혹은 아마도 프로젝트가 무료 소프트웨어이고 그 자원자들이 세계 곳곳에 흩어져 있을 수도 있다. 우리 프로젝트의 경우에는 우리 모두가 오픈소스 소프트웨어 프로젝트를 작업하고 관리하는 동안에 만났고, 우리의 프로세스들은 서로 멀리 떨어져 살던 사람들이 제기한 요구를 충족시켜 왔다. 우리가 돈을 지불하는 클라이언트들을 위해 비용과 속도적인 이득을 도입하기로 결정 한 것은 그 후의 일이었다.

GDD 프로젝트가 마주치는 가장 큰 위험은 내부적으로 효율적인 의사소통을 할 수 있는가에 대한 것이다. 고용주가 그들의 개발자들이 매일같이 사무실에 있길 원하는 이유는 그것이 빈틈없고 의사소통이 잘 되는 팀을 만들기 위한 검증된 방법이며, 그러한 팀을 만드는 것이 모든 프로젝트를 성공시키기 위한 가장 핵심적인 부분이기 때문이다. GDD는 얼굴을 맞댈 수 있는 관계가 부족할 뿐만 아니라, 그것을 더욱 어렵게 만드는 언어 장벽을 가지고 있기도 하다. 그러나, 기술이라는 것은 지역적으로 분산된 팀이 매일 서로를 보며 개발하는 것만큼의 정교한 의사소통 수준을 달성하는데 도움을 준다.

콜롬비아 대학의 두 교수들이 GDD의 이러한 면에 대한 연구를 해왔고, 그들의 해답은 소프트웨어 프로젝트를 표현하는 3D 가상 세계인 CHIME (Columbia Hypermedia Immersion Environment)이다. 개발자들은 "걸어다니면서" 다른 개발자들의 아바타와 프로젝트 산출물(예를 들면, 마일스톤 목록과 같은)과 상호작용을 한다. 여기서의 목표는 엔지니어들에게 직접적인 의사소통을 효과적으로 만드는 것과 똑같은 대인관계를 증진시킬 가상 오피스를 제공하는 것이다. 그러나 우리의 경험상 그와 똑같은 효과가 대부분의 기본적인 인터넷 툴들로 달성될 수 있다. 우리에게 있어 GDD의 기본초석은 Internet Relay Chat 프로토콜이다. 우리는 IRC가 원거리 개발에 있어 인스턴트 메시징보다 우월하다는 것을 알았는데, 왜냐하면 이것은 CHIME이 주는 효과와 같은 효과를 내기 때문이다. IRC는 개발자들에게 온라인상에서 특정 주제에 관심을 갖는 사람들과 실시간 대화를 할 수 있는 공간을 제공한다. 다른 개발자들은 그 후에 오더라도 저장된 글로부터 그것을 다시 읽어 볼 수 있기 때문에 굳이 대화에 끼어 뭔가를 얻어내려고 그 자리에 있을 필요가 없다. IRC는 채널에 있으려는 노력을 많이 들이지 않고서도 그 채널상에 항상 존재를 유지하기가 쉬워서 그것을 작업 스타일에 합치기 쉽다. 그러므로 개발자들은 그들이 알고 있는 질문에 바로 뛰어들어 대답을 할 수 있고, 바로 자신의 업무로 돌아올 수 있다. 만약 개발팀이 IRC를 작업흐름에 성공적으로 통합시킨다면 IRC이기 때문에 전통적인 사무실보다 이로운 점들, 즉 더 많은 사람들과 즉흥적인 대화를 할 수 있고 그 후의 사람들을 위해 기록을 남기는 것들을 제공할 수 있다.

IRC의 의사소통 형식은 언어장벽에도 맞설 수 있는 기반 또한 제공한다. IRC에서 오가는 대화 속에서 가능한 사회적으로 받아들여질 수 있는 잠깐의 틈은 개발자들에게 한 묶음의 툴들에 의지하여 새로운 언어를 배울 수 있는 기회를 준다. 새로운 언어를 배우는 데에는 그 나라 말을 쓰는 사람과의 직접적인 대화에 뛰어 들어보는 것보다 더 좋은 방법은 없다. 개발자는 인터넷 상의 무료 서비스들을 이용하여 효율적인 툴들의 묶음을 만들 수 있다. 보통 이 묶음에는 동사를 변형할 수 있는 등의 문법 지향적인 번역 기능을 가진 툴 뿐만 아니라, 단어를 번역하기 위한 온라인 사전이 포함된다. 예를 들어 AltaVista의 Babelfish나 Google의 번역 툴은 각각의 단어를 번역함에 있어 정말로 끔찍하며, 문단을 번역할 때도 마찬가지다. 한 예로, "bear"라는 단어를 입력하면 이것이 숲에 사는 동물을 얘기하는 것인지 동사를 얘기하는 것인지 AltaVista나 Google에게 알려줄 방법이 없다. 그러나 이러한 툴들은 동사변형이나 전치사구를 만드는데 유용하다. 그러므로 양질의 온라인 사전과 번역툴의 효과적인 혼합이 필요하다. 이 툴들에 익숙해 지는 것과 IRC의 대화에서 재빠르게 이것들을 참조하여 비정상적인 시간이 걸리지 않고 응답할 수 있게 되는 것은 정말 쉽다. 우리 팀의 몇몇은 단순히 IRC를 사용하고 무료 인터넷 언어 툴들을 사용함으로써 2개국어 내지는 다국어를 사용할 수 있게 되었다. 분명, 언어를 가르치는 교사들은 이러한 접근법이 지나치게 읽기/쓰기에만 집중하고 말하기/듣기에는 거의 시간을 들이지 않는다고 지적할테지만, 유창하게 쓸 수 있는 것은 훨씬 더 유창하게 말할 수 있게 해줄 것이다. 그리고 우리에게 더 중요한 것은 개발자들이 공동으로 작업하는 데에는 글로 쓰는 의사소통으로도 충분하다는 것이다.

IRC (혹은 이와 유사한 다른것)에서 가상의 사무실을 만드는 것은 GDD팀의 기초가 될 뿐만 아니라 가장 중요한 것 중의 하나이기도 하다. 지난 수년간 필자가 종종 IRC에서 매일 들르던 사무실은 샌프란시스코만 지역의 닷컴 기업들에 들렀던 실제 사무실들보다 더 "사실적"이었다고 말해두는게 안전할 것이다. 6~7년간 이렇게 일한 후에야 필자는 작년 우리가 브라질 상파울로에 조직한 Developers Summit에서 동료들을 처음 만나볼 수 있었다.

일단 일일 협업에 대한 프레임웍이 형성되고 나면 다음 극복해야 할 것은 시간적인 것이다. GDD 팀원간의 시차는 팀을 위기로 내몰고, 작업흐름을 혼란시키는 장애물이 될 수 있다. 지속적으로 사용하게 될 훌륭한 툴이 바로 timeanddate.com이다. 이 웹사이트는 시차 정보에 대해 빨리 알아볼 수 있으며 회의 스케쥴을 잡을 때 시차를 시각화하기 쉽게 만들어주는 Meeting Planner라는 애플리케이션도 가지고 있다. 날짜와 시간에 관련된 다른 사이트들도 다수 존재하며, 이들 사이트들은 GDD 팀이 동료간 주야간을 조정하는데 도움이 될 것이다.

언어와 시간, 거리에 관계된 문제들을 해결하고 나서의 다음 문제는 개발 흐름을 촉진시킬 툴들을 찾는 것이다. 다시 말하지만, 이러한 많은 툴들은 기본적인 주요 인터넷 협업 기술들이다. 이는 다음을 포함한다:
  1. 메일링 리스트: 실시간 상호작용에 대한 검증된 보완방법이다. 메일링 리스트는 서로 다른 형태의 토론에 대해 실시간 대화보다 좀 더 논리적이고 여러모로 깊이 생각할 수 있게 한다. 우리가 사용하는 것은 Mailman이다.
  2. 버전 관리: 대부분의 개발자들이 CVS와 서브버전에 친숙하다. 전통적인 이 두 클라이언트-서버 버전 시스템은 소스코드의 이력을 관리하고 많은 사람들이 동시에 작업할 수 있게 한다. 그러나 새로나온 버전 시스템들은 굉장하다. 이것들은 클라이언트-서버 형태를 능가한 분산 저장소 모델을 제공한다. 요컨대 분산 CVS는 코드를 합치는 메커니즘을 더 향상시켜 개발자들을 좀 더 자유롭게 해준다 (예를 들어, 분산된 버전 시스템으로 인터넷에 연결하지 않은 채 저장소에 코드를 체크인 할 수 있다.) 분산 버전 시스템의 예로는 Bazaar와 Mercurial이 있다.
  3. 버그 추적: 특정 버그 추적 시스템은 시스템 내에 버그 상태들을 사용할 수 있다는 점에서, 소프트웨어 개발 주기에서의 속도조절을 종종 결정해 왔다. 이러한 컴포넌트는 수년간 별로 많이 바뀌지 않았다: 버그가 들어오면, 개발자는 버그를 승인하거나 거부하고, 버그 상태는 개발자가 그것을 고치는 대로 변하고 그것을 CVS 저장소에 체크인하고, 해당 코드들을 제품에 적용한다. 우리는 여전히 Bugzilla를 사용한다.
  4. 문서 관리: 공동 문서 관리는 원거리 작업 관계의 핵심적인 부분이다. 위키의 장점이 현재까지 유명하다; 이것은 문서의 버전관리나 롤백을 허용하고, 변경을 누가 했는지 쉽게 알 수 있으며, 누구라도 위키에 매우 쉽게 참여할 수 있다. 위키에 그룹 편집 기능을 개선하자는 일부 "웹 2.0" 요구가 일고 있다. 우리가 사용해온 예는 writewith.com인데 각각의 문서에 대해 워크플로우를 만들 수 있고, 사용하기 쉬운 히스토리와 노트 섹션이 있으며, 현재의 문서 개정 시 데스크탑과 같은 인터페이스가 존재한다. 그러나 writewith.com는 위키가 아니기 때문에 우리가 이러한 형태의 툴들을 통합해왔던 방법은 우선 writewith와 같은 좀더 진보된 툴 상에서 문서의 초기버전을 만들고, 일단 전체 과정을 작업해서 마지막 드래프트를 내고나면 우리는 그것을 모든 우리의 문서들을 조직화하기 좋은 위키로 옮길 것이다.
서로 다른 이들 툴 모두를 사용하면서 생기는 문제는 이것들이 인터넷 상의 곳곳에 흩어져 있고, 각각 로그인을 따로 해야 하며, 어느 툴을 사용해야 할 것인지에 대해 헷갈릴 위험을 피해야 한다는 것이다. 우리는 이러한 문제가 없었다. 왜냐하면 우리는 개발 프로세스 상에 하나의 안정점을 향해 조금씩 발전시켜 왔고, 우리가 사용하는 각각의 툴들은 그것이 우리의 작업 흐름상에서 최상의 결과를 내는 이유로 사용했기 때문이다. 새로 온 개발자들이 우리의 툴들을 따라잡는 것은 그리 어렵지 않다.

aMember와 같은 새로운 소프트웨어 패키지들을 이용하여 여러분의 툴들이 단일 로그인을 하게 업그레이드 시키는 것이 가능하다. aMember는 실제적으로 웹사이트의 유료 멤버십 구역을 만드는데 사용되지만, 그 기능은 많은 웹 애플리케이션에 단일 로그인 지점을 만드는 데에도 유용하다. 우리는 현재 GDD에 사용할 다양한 그룹웨어 툴을 위한 aMember같은 메타-로그인을 제작중에 있다.

GDD를 막 시작한 팀들을 위해 이러한 모든 툴들을 통합해서 제공하는 상용서비스가 있다. 그 중 하나가 CollabNet사의 SourceCast인데 지역 분산 개발을 위해 필요한 모든 것들이 있다. 기본적으로 이것은 위에서 언급한 모든 툴들을 각 프로젝트에 대해 한 곳에서 모두 제공한다. 이것이 무료 소프트웨어 툴을 사용한 GDD 환경을 구축할 수 있게는 하지만, 하나의 중앙 장소에서 전체를 조직화하는 데에 약간의 가치가 있다. SourceCast가 실시간 커뮤니케이션과 "가상 작업장"에 대한 요구에 어떻게 접근할지는 불명확하다.

무료 소프트웨어 옹호자들의 마음에 더욱 가까운 유사 제공물로 GNU 프로젝트의 Savannah와 VA 소프트웨어의 SourceForge가 있다. SourceCast, SourceForge, 그리고 Savannah는 소프트웨어 프로젝트를 위해 하나의 중앙 장소에서 메일링리스트, CVS 저장소, 이슈 추적기, 파일저장, 문서공유를 제공한다.

해외 애플리케이션 개발에서 현재 배치되고 있는 한가지 흥미로운 기능이 VNC의 "watch windows."이다. 이것은 미국측에 있는 엔지니어링 관리자가 해외 엔지니어들이 생산적으로 일하고 있는가 불안해 하는 것을 보완하기 위한 것인데, 이 애플리케이션은 개발자들이 자신의 개발 컴퓨터에 "시간을 기록하게 하고" 데스크 탑에서 일어나는 모든 것들이 VNC 창에 보여지게 한다. 이 기술은 유용하긴 하지만 관리자가 엔지니어와의 관계가 아직 형성중인 상태에서는 더 해로울 수 있다.

GDD에 관해 언급할 마지막 애플리케이션은 진보적인 회의를 위한 기술이다. IRC와 이메일이 대부분의 일일 작업에 충분하지만, 가끔은 팀원들끼리 서로를 보고 들을 수 있는 대면 회의를 갖는 것도 유용하다. 새로운 세대의 인터넷 회의는 이 모든 것이 가능하다. 우리는 Skype을 사용하여 음성회의를 하고, 좀더 세부적인 논의가 필요할 때는 음성과 화상을 교차하여 회의를 한다.

결론적으로, 비록 아웃소싱이나 원거리 개발 프로젝트에 이용할 만한 상용 서비스들이 있긴 하지만, 그것들 대부분은 수년간 사용되어 온 오픈소스와 무료 소프트웨어 기술들을 묶어 놓은 버전이다. 약간만 주의깊게 설정해 놓으면 어떤 그룹의 개발자들이라도 다국적 소프트웨어 개발사들이 애플리케이션 기술을 배포하는 데 사용한 예산과 경쟁력을 갖출 수 있고 효율성과 속도에서 큰 이득이 있음을 빠르게 실감할 수 있다. 우리에게 있어서는, 우리의 국제적인 개발자 팀을 부드럽게 운영할 수 있게 하고, 그것으로부터 얻을 수 있는 것은 서로 다른 세 대륙에서 세가지 언어로 일에 참여할 수 있는 능력이며, 비용 절감이 적당할 땐 아웃소싱할 수 있고, 우리의 일상 작업의 일부로서 문화적 장벽을 돌파하면서 많은 개인적 성취감을 얻을 수 있다.


저자 Ryan Bagueros는 캘리포니아주 샌프란시스코와 브라질 상파울로에서 그의 회사인 northxsouth.com를 운영하며 인터넷 기술을 만들고 있다.
TAG :
댓글 입력
자료실

최근 본 상품0