테크 이야기2015.06.24 16:31

알고리즘 수업을 듣고 있었다. 렉처러는 알고리즘 분야에서 많은 저명한 논문을 발표한 옥스포드의 Ralf Hinze 교수였다. 그는 OOP와 FP(Functional Programming)을 아래의 수학식을 통해서 간단히 정의한 뒤 설명을 덧붙였다.


OOP와 FP를 설명하는데 있어 서 어떤 설명도 이 수학식보다 간단 명료할 수 있을까? 간혹, FP를 실제 코드에 적용하다 보면 가끔 OOP와 혼용되어 identity가 조금 흔들릴 때가 있지만 그럴때 다시금 이 철학을 되새겨야 한다.

저작자 표시
신고
Posted by 박경훈
애자일 이야기2015.06.08 09:44

쏘트웍스(ThoughtWorks)는 미국에 본사를 둔 세계적인 IT 회사이다. 직원이 3000명 가까이 되고 각 세계의 주요 도시마다 사무실이 있을 만큼 큰 IT 조직이다. 이 회사는 애자일의 거장으로 손꼽히고 또 리팩토링으로 유며한 마틴 파울러가 CSO(Chief Scientist Officer)로 몸 담았던 회사이기도 하다. 그래서 그들은 애자일에 있어서 누구보다 빠르고 적극적으로 도입했다. 그 결과 애자일에 대한 지식과 경험이 월등히 뛰어난 기업이다. 하지만 그들은 원거리(사무실이 지역적으로 떨어진 복수팀에 의해 진행되는) 프로젝트를 진행하면서 새로운 도전을 맞게 되었다. 원거리에서 개발 프로젝트를 진행하게 될 경우 구성원 사이의 커뮤니케이션, 협업, 지식의 공유 등 많은 어려움이 존재하기 때문이다.

쏘트웍스는 각기 다른 기술을 가진 30여명의 구성원이 인도, 호주, 영국에 나눠져 프로젝트를 진행하는 상황을 직접 겪게 되었다. 그들은 기존과 다른 방식으로 일일 스탠드업 미팅과 서로 지식을 교류하고 활동들을 도입해야 했다. 예를 들어 원거리 커뮤니케이션을 위해서 메신저와 같은 도구들을 적극적으로 활용했다. 그럼 원거리 프로젝트에서 애자일을 어떻게 활용하였는지 그리고 그 프로젝트를 어떻게 성공 시킬 수 있었는지 살펴보도록 하자.



프로젝트 배경

애자일 팀은 구성원들 사이의 소틍을 가장 중시하고 있다. 그리고 많은 애자일 프로젝트에서 소통의 실패가 프로젝트 실패로 이어졌다. 지역적으로 떨어져 있고 거기에 시간대까지 다르다는 것은 분명 커뮤니케이션에 있어서 높은 장벽일 수 밖에 없다. 이번 장에서는 이러한 경험을 직접 체험한 쏘트웍스의 사례를 설명할 것인데 이들은 삼 개국(영국, 인도, 호주)으로 프로젝트 팀원들과 고객이 떨어져 있었다. 그러므로 그들은 어떻게 이 커뮤니케이션 문제를 해결할지 그리고 기존에 지켜오던 애자일 프랙티스들을 어떻게 상황에 맞게 고쳐야 할지 고민해야 했다.

최종 고객은 영국에 있었는데 재무관련 서비스를 만들어 제공하는 것이 목표였다. 그들의 프로젝트는 초기 두 달 동안 프로젝트 참여인원을 구성해야 했다. 이렇게 모인 프로젝트 구성원은 약 30명 정도로 인도의 방갈로, 호주의 시드니, 영국 이렇게 삼 개국으로 나눠 구성이 되었다. 이중에 주 개발센터는 시드니였다. 시드니에는 프로젝트 매니저, 비즈니스 분석가, 기술 리더, 여덟 명의 개발자가 있었다. 이 프로젝트가 재무관련 프로젝트인 만큼 재무지식을 갖춘 비즈니스 분석가가 필수적이었다. 그리고 방갈로팀은 프로젝트 매니저와 비즈니스 분석가 그리고 두 명의 테스터와 16명의 개발자들로 구성되었다.

앞서 이야기 했던대로 그들은 이렇게 팀원을 꾸린 다음 30명의 참여인원을 두 개 팀으로 나눴다. 그들은 재무적인 이익들을 고려하여 데드라인을 결정하게 되었다. 고객이 원격지의 팀을 선택하게 되었던 결정적인 이유는 짧은 기간 내에 많은 인원이 필요했는데 그만큼의 리소스를 투입하기 위해서였다. 그리고 고객이 제시한 데드라인을 지킬 수 있는 다른 조직을 찾지 못했기 때문이다.

그들은 주간 이터레이션를 이용하여 진행상황을 가능한 짧은 주기로 관찰하고 고객에게도 보고하기로 결정했다. 그들은 프로젝트 기간 중간 중간에 회고 일자를 정하고 매일 스탠드업 미팅을 진행하기로 하였다.


단절된 커뮤니케이션의 극복

그들은 프로젝트를 진행하면서 매일 진행되는 스탠드업 미팅을 포함하여 여러 가지 애자일 활동들을 도입했다. 그럼 그들이 원거리 환경을 극복하기 위해서 수행한 노력들을 살펴보도록 하자. 


스탠드업 미팅


지역적으로 떨어진 환경에서 처음으로 직면했던 문제가 바로 스탠드업 미팅을 비롯한 주기적인 소통을 부분이었다. 그들은 이전 프로젝트까지 줄곧 일일 스탠드업 미팅을 유지해 왔었는데 짧은 시간 동안 진행사항을 점검할 수 있고, 커뮤니케이션의 질을 높여 주기 때문이었다. 팀은 그 동안 사무실에 모여 하던 일일 스탠드업 미팅을 어쩔 수 없이 원격지 팀과 함께 할 수 있는 컨퍼런스 콜 형태로 진행했다.


두 나라의 시간대가 다르다 보니 일일 스탠드업 미팅 시간은 호주는 오전 10시였고, 인도는 오후 3시30분 이었다. 이 미팅은 대략 15-30분 정도가 소요됐다. 미팅에서 그들은 지난 24시간동안 진행한 일들과 다음 24시간동안 진행할 일에 대해서 이야기했다. 보통 3-6명의 시드니 팀원들과 8-10명의 방갈로 팀원들이 이러한 스탠드업 미팅에 참여했다.

그들은 사전에 이 원격 스탠드업 미팅이 어려울 것이라고 생각은 했지만 이 정도로 커뮤니케이션이 힘들게 진행될 줄은 예상치 못했다. 그들은 네트워크 문제로 굉장히 작은 목소리와 좋지 않은 전화 품질로 대화를 진행해야만 했다. 그러다 보니 듣고 이해하기가 굉장히 힘들었다. 즉, 여러 사람이 컨퍼런스 콜을 이용하는 것 자체가 쉬운 일이 아니었다. 그 뒤에 그들은 인터넷 기반의 컨퍼런스 소프트웨어를 이용했다. 일단, 음질에 있어서는 확실히 컨퍼런스 콜보다 뛰어났다. 그리고 처음에는 노트북에 장착되어있는 마이크와 스피커들을 이용했데 이 부분이 음질에 있어서 문제를 발생시킨다는 것을 알게 되었다. 

이렇게 그들은 초기 몇 달 동안 통화품질을 조정하고 또 서로의 영어 발음에 익숙해 지는데 소비하게 되었다. 그들은 이런 커뮤니케이션의 이슈로 인해 인내를 가지고 반복적으로 묻고 답하기를 해야만 했다. 당연히 기존의 스탠드업 미팅보다 더 많은 시간을 소비하게 됐다.

스탠드업 미팅 외의 커뮤니케이션은 주로 메신저를 이용하였다. 아무래도 익숙하지 않은 영어발음보다 텍스트 기반의 대화가 훨씬 이해하는데 유용했다. 그들은 또한 컨퍼런스 콜은 다수의 사람들이 참여하기에는 적합하지 않음을 깨달았다. 그래서 그들은 컨퍼런스 콜의 인원을 8명 이하로 제한하는 규칙을 만들었다. 그들이 생각할 때 이 스탠드업 미팅을 통해서는 팀 간의 신뢰관계를 쌓기 힘들다고 생각했다. 그래서 그들에게는 개인적인 관계를 만들 수 있는 다른 무언가가 필요했다.


관계에 다리놓기

그들이 가졌던 빡빡한 데드라인과 적지 않은 인원으로 구성된 개발 팀이라는 환경 때문에 1:1 관계를 만들어 가는데 무리가 있었다. 그렇다고 이 관계를 무시할 수 없었기 때문에 시드니와 방갈로 매니저들 사이에서만 1:1 관계를 가져 나가기로 했다.

각 매니저는 자신의 팀을 대표해서 이슈를 비롯해서 질문이나 필요한 도움을 수집하였다. 그리고는 둘이서 해당 내용을 이야기했다. 이렇게 중간 다리를 만들자 팀 사이에서 커뮤니케이션이 개선되는 것을 볼 수 있었다. 이런 활동을 통해서 매니저 사이에 두터운 신뢰가 쌓여가는 것을 볼 수 있었고 어떤 문제점이 발생하거나 특정 행동이 필요 할 때 적절히 진행할 수 있었다.

그들은 이러한 두 매니저 사이의 미팅을 매일 진행했다. 둘만의 대화를 통해서 스탠드업 미팅으로는 해결할 수 없는 복잡한 문제를 토론하는 것이 가능했다.



파견인사의 교환


처음에는 대면하지 않고 프로젝트를 진행한다는 것이 굉장히 어려운 일이었다. 무엇보다도 고객은 영국에서 시드니로 요구사항을 전달하기 때문에, 시드니팀에서 다시 방갈로팀에게 비즈니스 요청사항을 전달하는 것이 쉽지 않았다. 실제 얼굴을 보면서 이야기하는 것을 대체할 만한 도구나 마땅한 대안이 없었다. 

그래서 그들은 파견인사의 교환이라는 방법을 찾게 되었다. 이 방법은 실제 커뮤니케이션을 증진하는데 효과적이었다. 이 파견인사의 교환을 통해서 개인 간의 관계를 두텁게 만들어 갈 수 있었고 어떤 지식이나 신뢰를 쌓아가는데 있어도 도움이 되었다. 파견인사들은 원격지 팀을 방문함으로써 새로운 교훈들을 얻어갈 수 있었고 미래의 방향을 설정하는데 큰 도움을 받을 수 있었다.

먼저 시드니팀에서는 개발자와 매니저를 방갈로에 보내고, 그 다음에는 방갈로 개발자들이 시드니를 방문했다. 그들은 팀원들을 차례대로 돌아가면서 파견 갈 수 있도록 기획해서 진행했다. 가능한 많은 팀원들을 보내고 싶었지만 개인사정상 가지 못하는 사람들도 있었고 회사의 입장에서도 비자와 경비 측면에서 어려운 부분이 있었다. 

파견인사가 현지에 도착하게 되면 현지 팀은 기본적인 주거 공간을 제공하고 자신들이 하고 있는 일과 현지 팀의 프로세스를 설명했다. 그리고 그 파견인사와 함께 일할 공간을 보여주고 그들이 해줘야 하는 역할과 업무를 소개했다. 이렇게 파견된 팀원은 약 한달 정도 시간을 보내면서 네 번의 이터레이션에 참여했다. 그들은 해당 기간 동안 스탠드업 미팅에 참여 하였고 또한 회고 미팅에도 참여하였다. 파견인사의 출장 기간을 3주로 할 경우 경험을 축적하게는 너무 짧아 효과가 없을 것이고 그렇다고 너무 오래 머물게 하면 원래 팀에서 인수인계를 필요로 하기 때문에 이 역시 쉽지 않았다. 그래서 4주라는 기간을 정하게 된 것이다.

그 파견인사를 위해 일과 시간이 끝난 뒤에 친목을 다지는 이벤트를 진행했다. 시드니에서는 매주 금요일 오후에 BBQ파티가 있었고 방갈로에서는 팀원들이 함께 저녁을 먹는 이벤트가 있었다. 이런 친목 이벤트는 팀원들끼리의 단합과 신뢰를 다지는데 큰 역할을 하게 되었고 그 파견인사가 자신의 나라로 돌아갔을 때 그 효과를 톡톡히 볼 수 있었다.

파견인사들의 활발한 참여를 통해서 다른 팀의 환경을 이해하게 되었고, 더불어 원격으로만 진행하던 커뮤니케이션을 파견인사를 통해서 간단히 질의하는 것도 가능했다. 더 인상 깊었던 것은 파견을 온 직원일수록 더 열심히 일하면서 무언가 좋은 영향을 주려고 애쓰는 모습이었다. 파견인사들은 자신의 원래 근무지로 돌아가게 되었을 때 파견지에서 같이 일하던 동료들과 자주 연락을 주고 받으며 친하게 지내는 것을 볼 수 있었다. 이런 부분이 커뮤니케이션에 있어서 중요한 역할을 하게 되었다. 왜냐하면 그들의 관계와 각 팀이 갖고 있는 문화에 대한 지식이 어려운 결정을 할 때 아니면 복잡한 이해 관계가 얽혀 있을 때 해결해주는 열쇠가 되어주곤 했다.

파견인사는 출장이 끝나면 그들이 파견기간 동안 쌓은 지식을 원래 팀으로 가져가게 되면서 그들이 갖고 있던 사소한 오해 같은 것들을 해결해 주었다. 그들은 원격지에 머물면서 알게 모르게 중요한 지식들을 흡수하게 되고 또 자신이 배우고 느낀 것을 다른 팀원들에게 퍼뜨리면서 두 팀은 같이 성장할 수 있었다.

그 파견인사에게는 다녀 온 소감이나 배운 것들을 공식적으로 보고하는 절차가 없었다. 하지만 자연스럽게 비공식적으로 그들의 경험과 지식이 팀에 전해져 나갔다. 아마 이런 보고를 부담을 주지 않는 선에서 공식화 시켰어도 충분히 좋은 내용이 되었을 것이다.


걸러지지 않은 커뮤니케이션 

인도에서 온 파견인사는 흥미로운 사실을 발견했다. 시드니팀이 방갈로팀에게 복잡한 내용을 최대한 간단히 설명하려고 노력하는 것을 본 것인데 실제 이런 작업이 갈등의 원인이 되었다. 왜냐하면 방갈로팀은 프로젝트에서 특정 결정이 이루어지면 근본이 되는 내용을 잘 몰랐기에 이해하기 힘든 부분이 있었다. 운이 좋게도 그때 파견 온 팀원이 이 부분을 정확하게 잡아낼 수 있었고 생략된 내용을 인도 팀에게 전달할 수 있었다. 

시드니팀은 불필요한 정보를 걸러내고 커뮤니케이션을 하려고 했던 것인데 중요한 부분까지 놓쳤다는 것을 알게 되었다. 그들은 뒤늦게 이 점을 깨닫고 프로젝트를 처음 시작할 때부터 지금까지 있었던 배경과 목표에 대해서 다시 인도 팀과 대화를 하면서 오해를 풀기 위해 노력하였다. 이런 커뮤니케이션을 통해서 프로젝트에 대해 모든 정보를 전달하면서 팀 사이에서 신뢰를 회복할 수 있었다.


프로세스의 개선

첫 번째 계획한 분기가 끝나고 그들은 회고를 진행하기로 했다. 이 회고 미팅에서는 양쪽 팀과 파견인사들이 참여하여 서로 상대 팀의 결과물에 대한 대화를 나눴다. 이 회고 미팅에서 팀을 더 작게 만들어 스스로 진행할 수 있게 하면 좋겠다는 의견이 나왔다. 그럼 이 의견을 어떻게 적용해 나갔고 어떤 이익을 얻을 수 있었는지 살펴보도록 하자.


소규모 팀

그들은 기존에 대규모 팀으로 움직일 때, 몇 가지 어려움들이 있었다. 대규모 팀의 팀원들은 회의를 진행할 때 자기 때문에 회의가 길어지면 안 된다는 압박을 느낀다. 이런 압박은 커뮤니케이션이 효율적으로 진행되는 것을 방했다. 그로 인해 각 팀원들도 서로의 업무를 깊게 이해할 수 없었다. 

그들은 이러한 문제들을 인정하였고 30명으로 구성된 하나의 팀을 10개 팀으로 나누었다. 이렇게 소규모 팀들로 나눠지면서 팀원들끼리 더 많은 소통을 할 수 있었다. 그리고 그 결과 산출물도 향상되었다. 소규모 팀들은 소통의 문제를 해결함과 동시에 팀원들이 서로 더 가깝고 친밀하게 만들었다. 

뿐만 아니라 팀들이 조금 더 정돈 될 수 있었고 팀원끼리 동지애가 형성되면서 서로에 대한 신뢰를 더욱 두텁게 증진시킬 수 있었다. 특히 이런 원거리 프로젝트에서는 더 많은 커뮤니케이션을 필요로 하기 때문에 작은 팀의 효과를 다른 프로젝트보다 더 크게 얻을 수 있었다.


잘 분배된 팀들

첫 분기가 지났을 때, 대부분의 사용자 인터페이스는 방골라 팀에 의해서 개발되었고 백 엔드(Back-End) 개발은 시드니팀에 의해서 진행되었다. 고객이 관련된 업무를 직접 할당하면서 각 현지에서의 불필요한 커뮤니케이션을 줄일 수 있었다. 둘째 분기에서는 이 작업을 순차적으로 진행할 수 있는 구조로 바꾸었다. 즉, 기존에 각 팀 별로 원하는 기능을 모두 수평적인 상태에서 처리하는 형태였는데 이제는 순서대로 사용자 기능을 처리할 수 있게 바꾼 것이다. 즉, 그들은 우선순위를 부여한 순서대로 일을 할당하는 것이 커뮤니케이션에 있어서 큰 효과가 있었다.

이런 일을 통해서 고객과 불필요한 소통을 최소화하면서 높은 생산성과 작업효율을 얻을 수 있었다. 뿐만 아니라 각 팀은 프로젝트 매니저, 팀 리더, 비즈니스 분석가 그리고 개발자 등 다양한 역할을 지닌 사람들로 구성되어 있었기 때문에 스스로 일할 수 있는 환경이었다. 만약 역할 별로 팀을 구성했다면 지역에 따른 시간대 차이 때문에 원활한 소통이 어려웠을 것이다.


미러링

팀의 구성을 새롭게 바꾸면서 팀은 더 작은 단위가 되었고 각 분야 별로 3명의 개발자들만 있게 되었다. 이런 변화는 팀원 간의 관계를 친밀하게 만드는 효과를 가져왔다. 팀의 구조를 바꾸면서 그들은 “미러링”이라고 부르는 방법을 도입했다. 이것은 업무 별로 개발자, 테스트, 비즈니스 분석가 등으로 팀을 구성하는데 동일한 팀을 시드니와 방갈로에 두는 것이다. 그들은 각자 자신의 지역 시간대에 맞춰 개발을 진행하고 개발이 끝나면 다른 지역의 팀이 출근해서 그 일을 진행한 부분까지 인수인계 받아 진행하는 형태이다.

시드니 개발자들이 자신의 업무를 방갈로 개발자에게 인수인계 해주는 데는 2시간 정도가 소요 되었다. 이 때는 자신과 동일한 업무를 하는 사람에게 개별적으로 인수인계를 해주었다. 인수인계는 음성 메신저를 이용했으며 원격 데스크탑 서비스를 이용해서 코드를 보여주고 진행과정과 이슈들을 설명했다. 

이렇게 진행한 결과 팀이 자율적으로 업무를 관리해 나가는 것이 가능했고, 미러링은 풍부한 커뮤니케이션을 제공하기 때문에 기존 커뮤니케이션으로는 해결하지 못한 문제점들을 줄일 수 있었다. 


안정적인 인프라

프로젝트의 초기 2주 동안은 네트워크를 비롯한 내부 인프라에 문제가 많이 있었다. 이러한 인프라 문제들은 50여명의 팀원들의 생산성을 저하시켰다. 그들은 초기 2주 동안 진행한 스토리 포인트를 측정해 봤는데 인프라 문제가 심각하다라는 것을 알 수 있었다. 인프라 문제가 잦았던 첫 이터레이션에서는 스토리 포인트를 약 18포인트 밖에 올리지 못했다. 하지만 이 문제를 해결한 두 번째 이터레이션 이후부터는 평균 70포인트를 올릴 수 있었다.


[그림] 이터레이션별 진행률


인프라 문제는 일정 연기 뿐만 아니라 팀이 개발을 진행할 때 의욕 또한 저하시키기 때문에 생산성이 크게 감소하게 되었다. 그들이 프로젝트를 진행하는데 있어서 가장 중요한 인프라는 공동의 코드 저장 공간과 CI(Continuous Integration) 였다. 

그들은 두 번째 이터레이션에서 자신들의 개발 인프라를 보다 안정적으로 제공하려고 노력하였다. 무엇보다도 다음과 같은 네 가지 요소의 안정성이 개발 생산성을 개선에 있어 중요한 열쇠였다.


• 빠르고 안정적인 인터넷 환경

• VPNS 환경

• 코드 공유 컨트롤 서버

• 최신 DB 및 설정 서버


인프라 팀은 항상 네트워크를 비롯한 인프라 환경을 모니터링 하고 방갈로팀에 문제가 발생할 경우 늦은 밤까지 문제를 해결해 주려고 노력하였다. 


원격 개발 도구들의 소개


이 원격 프로젝트를 진행하는 동안 그들은 많은 커뮤니케이션 도구들을 사용했다. 그 중에 유용했던 도구들을 살펴보도록 하자. 


메신저

대부분의 원격 팀들은 모두 그룹 메신저를 통해서 수시로 소통을 했다. 커뮤니케이션의 제1순위가 바로 이 메신저를 이용하는 것이었던 것만큼 가장 중요한 도구였다. 그들은 야후! 메신저를 사용하였고 다음과 같은 룰을 통해서 더 많은 도움을 받을 수 있었다. 


• 고객, 테스터, 비즈니스 분석가, 개발자 모두 프로그램을 설치했고, 자신의 이름에 역활을 표시하게 하였다.

• 주소록을 만들어서 전체 팀을 추가하였고 자유롭게 연락할 수 있게 하였다.

• 연락처 부분에 현재 일하고 있는 위치를 표시하였다.


이러한 간단한 룰을 통해서 각 지역에서 쉽게 커뮤니케이션을 진행할 수 있었고 어떤 질문이 생길 경우 쉽게 물어볼 수 있었다. 각 팀은 그룹메시지를 지정하여 그룹 별로 쉽게 토론을 개설하고 참여할 수 있었다. 

이런 환경 설정은 하루 만에 끝낼 수 있었고, 실제 자리에 있는지 여부를 메신저 상태를 통해서 쉽게 알 수 있었다. 그리고 그들이 바쁘거나 방해 받고 싶지 않을 경우에 ‘바쁨’으로 메신저 상태를 표시하도록 하였다. 



스카이프


야후 메신저와 별도로 스카이프(Skype)를 이용하여 음성 대화를 진행했다. 초기에는 스카이프의 기본 음성 통화 기능을 이용해서 스탠드업 미팅을 진행했다. 그러나 시간이 흐를수록 다른 회의나 연락에도 전화보다는 스카이프를 즐겨 사용했다. 그리고 스카이프는 인터넷을 이용하여 현지의 일반 전화로 연결할 수 있는 기능이 있는데 한 쪽에서 인터넷이 사용이 불가능한 경우에는 상대방의 휴대폰 전화로 연결을 시도했다.

무엇보다도 스카이프에서 제공하는 연락처를 이용해서 급한 경우에 쉽게 연락할 수 있었다. 그리고 스카이프에서 제공하는 인터넷 기반의 전화 또한 좋은 통화품질을 갖고 있어 추가비용 없이 쉽게 이용할 수 있었다. 하나의 단점은 네트워크 속도에 따라서 통화품질에 제한이 있었다는 것이다. 


동영상 문서


원격 개발팀에서 한가지 더 중요한 것이 있는데 바로 동영상을 작성하는 것이다. 그들은 짧은 동영상을 활용하여 특정 기술을 전달하거나 교육이 필요할 경우 사용하였다. 그들은 개발에 있어 필요한 설정가이드나 고객에게 시스템 데모를 보여주기 위해서 동영상을 활용했다.

프로젝트 매니저 또한 시스템 아키텍처 또는 복잡한 도구의 사용법을 알기 쉽게 전달하기 위해서 동영상을 사용하기도 했다. 작성된 동영상은 네트워크 드라이브를 통해서 공유하였다.  그리고 파일 사이즈가 클 경우, 원격 드라이브를 사용하는데 문제가 있었기 때문에 카메라의 해상도와 화질을 적절히 조절해서 파일 사이즈가 너무 크지 않도록 하였다. 간혹 화이트 보드에 적은 내용을 문서화 할 시간이 없을 경우, 사진으로 찍고 그 사진들을 모아서 동영상으로 제공하기도 하였다. 


그들은 좋은 동영상 만드는 팁들을 다음과 같이 소개하고 있다. 


• 동영상은 최대한 짧게 만드는 것이 좋은 하나의 주제당 3-5분 정도가 적합하다. 녹화할 때 적절히 끊어서 작업을 진행하면 나중에 동영상을 편집하는 리소스를 줄일 수 있다.


• 카메라를 PC에 연결했을 때 자동으로 동영상을 변환하는 도구를 이용하는 것이 좋다. 그들은 캐논 드라이버를 이용하였고 윈도우에 있는 카메라 내에 동영상을 자동으로 감지하여 변환하는 도구를 이용하였다. 이런 자동화를 통해서 일의 번거로움을 줄이는 것이 좋다. 


• 파일명은 최대한 쉽고 이해가 가능하게 정하는 것이 좋다.


그들은 화면을 녹화할 때 해상도를 800x600으로 맞추어 작성하였다. PC화면을 촬영할 경우 음성 메시지도 적절히 같이 녹음하여 보다 쉽게 이해할 수 있게 진행하였다. 가끔은 말하는 사람의 얼굴과 PC화면을 적절히 번갈아 가면서 녹화를 진행하였다. 


원격 제어


시드니팀과 방갈로팀은 코드를 같이 보면서 이야기 해야 될 경우가 많았다. 그럴 때 리얼 VNC(Real VNC)라는 무료 소프트웨어를 이용했다. 이 도구와 함께 음성 채팅을 이용하여 대화를 진행했다. 원격제어 소프트웨어는 코드 기반 리뷰의 질을 높이는데 큰 역할을 했다. 

첫 이터레이션에서는 이 도구를 자주 사용하지 않았었다. 하지만, 두 번째 이터레이션부터 개발자들이 미러링이나 기술적인 인수인계가 필요할 경우 자주 사용하게 되면서 이 도구의 유용성을 깨닫게 되었다. 해당 도구를 이용하면 훨씬 쉽게 화면을 공유할 수 있다는 것을 인지하고 작은 코드리뷰에도 무조건 이 도구를 이용하기 시작했다. 


정리

지금까지 그들이 원격 프로젝트를 진행한 과정과 과정 도중에 발생한 어려움을 해결하기 위해서 수행했던 여러 방법들을 살펴보았다. 해결방법 중 일부는 굉장히 효과적이었고 다른 일부는 부분적 효과만 있었다. 예를 들어 그들이 초기에 컨퍼런스 콜을 이용한 스탠드업 미팅은 비효율적이었다. 원격 환경에서는 스탠드업 미팅과 더불어 화상 전화와 원격 제어 그리고 메신저와 같은 여러 커뮤니케이션 도구들이 추가로 제공되어야 한다. 

그들은 또한 원격팀과 이야기 할 때 최대한 간단히 이야기 하려고 많은 내용을 걸러서 진행했지만, 시간이 조금 더 소모되더라도 자세히 이야기 하는 것이 좋다고 했다. 왜냐하면 모두가 진행되고 있는 정책과 관계 그리고 각 기능이 도출되기까지의 상황을 설명해주어야 오해가 생기지 않기 때문이다. 

그리고 그들은 중간 소통자를 둬서 복잡한 이슈를 대신 의논하게 하고 지역 별로 각 분야 전문가를 둠으로써 많은 문제를 해결 할 수 있었다고 한다. 

그리고 두 번째 이터레이션에서 보다 팀을 작게 만들어 많은 효과를 얻었다. 비록 큰 팀들이 어떤 정보가 격리 된다거나 어떤 책임 의식이 나누어 진다라는 리스크를 가지고 있다고 하더라도 원격 팀에게 있어서 그런 책임감이 짐으로서 다가오게 된다. 소규모 팀을 통해서 이런 부담감을 적절하게 조절할 수 있고 팀 별로 원하는 만큼의 정보만 제공함으로써 과도한 커뮤니케이션 문제 또한 해결할 수 있었다.

그들이 활용했던 방법 중에 가장 효과적이었던 것은 파견인사 제도였다. 이 제도를 통해 자연스럽게 신뢰를 두텁게 하고 서로 오해한 부분과 잘못된 지식을 자연스럽게 고쳐갔다. 원격 프로젝트를 진행한다고 할 때 실제로 얼굴을 보면서 하는 커뮤니케이션을 과소평가하는 경우가 많이 있다. 하지만 결국에 그 간과했던 커뮤니케이션이 오해로 돌아오면서 더 큰 비용이 소모되는 경우가 많이 있다는 점을 볼 때 반드시 이뤄져야 하는 투자가 분명하다. 

원격 팀들은 안정적 시스템 인프라가 최우선 되어야 하고, 그 인프라를 바탕으로 최대한 많은 커뮤니케이션을 해야 한다. 그리고 중요한 것은 원격 프로젝트인 만큼 더 자주 진행과정을 점검해야 한다. 이번 장에서 소개한 쏘트웍스의 환경과 방법들을 잘 조합한다면 원격 프로젝트도 분명히 성공적으로 이끌 수 있는 자신감을 가질 수 있을 것이다.


저작자 표시
신고
Posted by 박경훈