기고 | ‘클라우드 설계 협업’ 문서화 방법은?

클라우드 시스템을 개발하고 통합하는 데 있어 공용 인터페이스(public interfaces)와 해당 서비스를 이용하는 '외부 개발자들(external "contracts")'과의 협업은, 설계와 아키텍처를 빠르게 그리고 동시에 진척시킬 수 있음을 시사한다.

하지만 이 경우 특히 개발자들이 서로 다른 공간에서 파일을 동시에 관리함에 따라, 갑작스런 변화로 인한 업무적 혼란을 초래할 수도 있다.

예를 들어 (서비스 제공자와 서비스 소비자라는) 두 팀이 인터페이스를 마주보고 작업한다면, 변수와 방법을 일치시키기가 힘들어진다. 물론 서비스를 제공하는 당사자가 문서를 업데이트 한 후, 상대 팀에게 새 필드 값이나 서비스 행동의 새로운 의미에 대해 통보할 수는 있다.

그러나 현실적으로 바로 바로 실천에 옮겨지는 경우는 드물다. 이 경우 변경된 문서 버전을 팀별로 분산해 관리하면서, 최종본이 무엇인지를 두고 비롯되는 통상적인 문제들이 대두된다.

클라우드 설계와 아키텍처 협업과 관련해 몇 가지 현실부터 살펴보자.

1. 해당 팀들은 규칙과 프로세스에 우선해 속도와 현명함에 가치를 부여한다.

2. 반복 개발을 강조하는 애자일(Agile) 프로세스를 사용하고, 지속적으로 통합하고 테스트한다.

3. 방법론에 무게를 두지 않고, 높은 수준의 실용성을 추구한다. 특히 ULM, 기타 특정 모델링이나 인터페이스 정의 툴을 고집하지 않는다.

4. 중앙에서 관리되지 않는 여러 조직에 팀들이 산개해 있기 쉽다.

5. 팀원들이 서로 떨어져 위치해 있다.

그렇다면 이것들이 시사하는 바는 뭘까? 일반적으로, 설계 협력에 있어 공통 분모로 사용되는 툴이 없을 확률이 높다는 것이다. (그렇다. 애자일 툴들이 있다. 그러나 기껏해야 고르지 않게 사용되고 있을 뿐이다.) 따라서 마이크로소프트 워드, 액셀, 비지오, 파워포인트가 출발점이 되기 쉽다. 불행히도, 이들 툴 대부분은 변경 관리 기능이 미흡하다. 만약 많은 사람들이 문서 내용을 변경했다면, 심지어는 워드의 변경기능 추적 기능조차 제대로 활용하기가 힘들다.

드롭박스(Dropbox)나 베이스캠프(BaseCamp), 기타 이와 유사한 파일 공유 및 프로젝트 스토리지에 이들 파일을 저장하는 방법을 쓸 수 있다. 팀의 관점에서 파일이나 변경 내역을 살필 수 있기 때문에 분명히 도움이 된다.

운이 좋다면, 파일공유 시스템의 파일 잠금 기능이 쓸만할 수 있다. 또 탄탄한 버전화(Versioning) 기능이 있을 수 있다. 그러나 대부분의 경우, 변경 내용 일체를 버전이 다른 하나의 파일로 저장해야 한다. 또 파일 이름을 정하는 방법에 대해 약속하고, 이를 엄격히 준수해야 한다. 10Jan11@DTaber#8NewFieldsV2_32와 같은 파일명이 등장하는 것이다.

게다가 두 팀이 동시에 특정 기술 하나를 놓고 작업을 하게 되면 소용이 없어진다. 따라서 '업데이트 충돌'을 방지하기 위한 일종의 점검 절차가 필요하다. 사용하고 있는 파일 공유 시스템이 파일 잠금을 완벽하게 지원하지 않는다면, 점검을 마친 가장 최근 버전의 파일이 관련 파일을 지우도록 하는 것이 대안이다. 단 해당 파일을 작업을 한 사람과 팀이 누구인지는 남겨둬야 한다.

한층 새로운 대안들
이 모든 것들이 진부한 생각이거나 어리석은 수작업 기반의 절차처럼 느껴지는가? 맞다. 실제로도 그렇기 때문이다.

더 현대적인 대안 중 하나가 구글 독스(Google Docs)다. 구글 독스는 협업을 지원하고 문서를 실시간으로 분산해 개발하는 기능을 지원하는 스프레드시트와 그림, 문자 문서화 시스템을 제공한다. 특히 컨퍼런스 콜(Conference Call) 도중에 사용하기 쉬울뿐더러 플랫폼에 얽매이지 않은 채 자유롭게 협업을 할 수 있는 방법을 제공한다. 개정 이력 기능은 최소 1년 동안의 버전들을 조사할 수 있도록 해준다. 즉 문서가 어떻게 발전해갔는지 쉽게 확인할 수 있다. 또 변경을 철회할 필요가 있다면, 언제 어느 때나 앞서 상태로 문서를 되돌릴 수 있다.

그러나 즉각적인 변경을 빠르게 문서화할 수 있는 방법이 없다. 버전 전반에 걸쳐 가시적인 차이가 없다. 필자는 변경 이력을 분석 툴이 사용할 수 있도록 추출하는 방법을 찾지도 못했다 (이론적으로는 구글의 V3 API 피드를 사용하면 가능하다.)

더 나아가, 구글 독스는 구글 계정 내부에서 확인할 때만 품질이 뛰어나다. 방화벽을 통한 관리를 기반으로 작업을 하거나 다른 보안 우려를 갖고 있는 회사들에게 구글 독스는 출입금지 구역이나 마찬가지다.

이 경우라면 위키(Wiki)를 사용할 것을 권장한다. 위키는 시간대가 다른 지역에 분산된 팀이라도 협업을 할 수 있도록 지원하는 (토크 페이지와 같은) 협업 툴과 문서 공유, 제한이 없는 변경 이력을 제공한다. 그러나 이런 협업 기능에도 제약이 있다. 취약한 테이블링(Tabling) 기능이다(HTML 해킹 같이 느껴진다). 또 도면(drawing)과 관련된 협업 기능이 없다.

상대적으로 새로 등장한 또 다른 툴이 채터(Chatter)다. 세일즈포스닷컴(Salesforce.com)에서 효과적으로 쓸 수 있는 협업 툴이다. (그룹과 해시 태그를 세심하게 구축해야 하는 등) 효과적인 엔지니어링 결정을 위해서는 많은 원칙이 필요하긴 하지만, 무료인데다 첨부 문서의 버전화를 지원한다는 장점이 있다.

쓸모 없는 것들
설계 협업에서 버려야 할 3가지가 있다. 이메일, 설계 회의 기록, 종이 문서다. 지금 당장 실천에 옮겨보자. ciokr@idg.co.kr