마이크로소프트웨어 3월호에 오픈마루 기사는 아니고, 애자일 방법론에 대한 글이 특집으로 실렸습니다. 그 중 2부가 강규영님이 쓴 글입니다.

글 중간에 나오지만 애자일이라는 말에는 모호함이 있습니다. '기민한'이라는 말로 번역되는데, 이 말도 또한 모호함이 있습니다. 빠르다라는 말은 어떤 것을 빨리 수행한다는 뜻도 있지만 빠르게 변화에 대응한다는 뜻도 있을 겁니다.

그런데 이 두 가지는 어떤 부분에서는 충돌을 일으킵니다. 웹서비스 개발팀의 이광호 팀장님은 스키를 너무 좋아하시는데, 스키를 이용해서 이런 비유를 하시더군요.

"스키 숏턴의 비법은 중심을 항상 일정하게 유지하는 것이다."

빠르게 내려가면서도 계속된 턴을 수행하는 상황은 빠르게 실행하면서도 여러 가지 변화에 기민하게 반응하는 것과 비슷합니다. 이 때 가장 중요한 것이, 지형이라는 변화에 반응하는 것은 꼭 필요한 일이지만 내 몸의 중심은 항상 내가 가고자 하는 방향을 향해서 일정하게 이동해야 한다는 것입니다. 결국 가고자 하는 방향이 무엇인지 정확히 아는 것과, 그 방향에 대한 중심만큼은 변하지 않는 것이 중요하다는 거죠.

애자일을 한 문장으로 요약하라면 '빠르게 가치를 전달하는 것'이라고 얘기할 수 있다고 생각합니다. 변화를 포용하라는 말이 뜻하는 바는 결국 빠르게 가치를 전달하기 위한 방법으로서 의미를 가진다고 생각합니다.

그러면 빠르게 가치를 전달하기 위해 필요한 것은?

결국은 자신이 만드는 것에 대한 믿음과 애정을 통해 나오는 열정만이 답이 아닐까 싶습니다. 애플의 직원들이 그랬던 것처럼. 원래 세상의 모든 방법론은 사람을 도와주는 것일 뿐, 모든 문제의 해답은 결국 사람에 있는 거니까요.



강규영님의 글입니다.
-------------

XP(eXtreme Programming)를 비롯한 여러 애자일 방법론의 도입 사례는 이미 많다. 그 와중에 별 변변치 못한 사례를 하나 더 추가하는 것이 과연 무슨 의미일까 싶은 생각도 든다. 그럼에도 불구하고 필자가 이 글을 쓰는 이유는 단 한 가지이다. 그리 완벽하지도 않고 실수도 많지만 어찌됐건‘현재진행형’인 국내 조직의 사례를 소개하여 이를 통해 애자일 방법론을 도입하고자 하는 개인, 조직에게 용기를 주기 위한 것이다.

‘사발면 프로젝트 팀’

이 글에서는 오픈마루 스튜디오 내‘사발면 프로젝트 팀’ 의 애자일 방법론 도입 사례를 소개하고자 한다. 사발면 프로젝트는 올해 초 출시된 오픈 아이디 서비스인 ‘마이아이디넷’에 이어 오픈마루에서 두 번째로 출시하게 될 웹 서비스이다. 사발면 프로젝트 팀은 기획자, 디자이너, 개발자 등 총 9명으로 구성되어 있으며, 필자는 개발자로서 이 팀에 참여하고 있다.

짝 프로그래밍

마소는 개발 전문지이니까 먼저 개발 얘기부터 시작해보자. 짝 프로그래밍은 가장 널리 알려진 XP 실천법 중 하나이다. 개발자들이 한 대의 PC 앞에 둘씩 짝지어서 앉아 있으니 겉으로 보기에 확연하게 드러나기도 하거니와, 그 효과 또한 즉각적이고 확실하기 때문이 아닐까 싶다.

오른쪽 사진은 대학생 인턴 고명석 씨(왼쪽,‘ 해리 포터’의 주인공과 ‘반지의 제왕’의 프로도를 모두 닮았다고 해서 ‘해리 프로도’라는 별명을 가졌다)와 10년 가까이 자바 개발자로 활동해 온 이창신 씨(오른쪽)가 즐겁게 만담을 나누며 짝 프로그래밍을 하고 있는 모습이다.

고명석 씨는 이번 인턴 과정을 통해 웹 관련 분야의 실무를 처음 경험했는데, 처음 이틀 정도는 주로 옆에 앉아서 구경하는 일을 했다(아마 상당히 지루하지 않았을까). 사흘 째 되는 날부터 자바스크립트 단위 테스트 작성을 돕거나 셀레늄(Selenium)으로 인수 테스트를 자동화 하는 일을 돕기 시작했고, 나흘째에는 실제로 쓰이게 될 프로덕션 코드를 작성하기 시작했다.

이 과정에서 그는 우리 팀이 몇 달간 잡지 못해 고생하고 있던 버그를 잡아내는 등(필자의 요즘 메신저 대화명은‘사이보그지만 괜찮아’를 패러디한‘쌓인버그지만 괜찮아’이다. 물론 실제로
괜찮은 것은 아니지만) 그야말로 눈부신 활약을 하고 있다(최근 며칠 동안은 홀로 외롭게 문서작업을 하고 있는데 아마 또 지루해하고 있지 않을까 싶다).

그 이름을 통해 짐작(?)할 수 있듯이 고명석 씨 개인의 명석함도 한 몫 했겠지만 짝 프로그래밍의 효과 또한 제법 크다고 생각한다. 구체적인 연구나 분석을 한 것은 아니지만 약 5년에 걸쳐 짝 프로그래밍을 하며 비슷한 경험을 몇 번 해 보았다. 예전에 다니던 다른 직장에서의 경험인데, ASP의 VBScript 밖에 모르던 개발자가 짝 프로그래밍을 통해 약 2주 만에 자바를 그럭저럭 익혀서 또 다른 개발자에게 자바 지식을 전파하던 모습도 인상적이었다.

필자의 옆 자리에 앉은 동료(박영록 씨)를 통해 알게 된 사실인데, 짝 프로그래밍을 하면서 필자가 누리게 되는 부차적인(하지만 중요한) 이득은, 혼자서 할 때보다 더 ‘제대로’하게 된다는
것이다. 평소에 게을러서 테스트 주도 개발도 안하고(필자 중 한 명으로써 참 부끄러운 노릇이다), 리팩토링도 대충 하면서 설렁설렁 지내다가도 누군가와 함께 짝 프로그래밍을 하게 되면 태도가 바뀌게 되는 것이다.

파티션 없는 공간에 함께 앉기

짝 프로그래밍 이야기는 이 정도로 접고, 잠시 눈을 돌려 팀 전체를 둘러보면 몇 가지 눈에 띄는 점들이 보인다. 그 중 한 가지는 모든 팀원들이 물리적으로 인접한 공간에 함께 앉아서 일한다는 점이다. 그리고 각 개인의 작업 공간 사이에 의례적으로 설치되는 벽( ‘파티션’이라고 하던데 정확한 용어인지는 모르겠다)조차 없애버렸다.


뿐만 아니라 한 공간 안에서도 의도적으로 기획자와 프로그래머가 섞이도록 자리를 배치하였다. 덕분에 기획자는 기획안에 대해 고민하다가 개발자와 의논할 일이 생기면 그 자리에 앉은 채로 모니터만 살짝 돌려놓고“이거 어때요?”라며 바로 앞자리에 앉은 개발자에게 물어볼 수 있다. 위 사진에서 보는 것과 같이 누구든 모니터를 살짝 돌리면 건너편 혹은 대각선에 앉은 사람에게 자신의 화면을 보여줄 수 있다.

전화나 메신저, 메일 등으로 이야기하면서“제가 보내드린 기획서의 다섯 번째 페이지 우측 하단에 있는 버튼 배치 어때요?” 라고 물어보는 것과 앉은 자리에서 화면을 손가락으로 가리키며 "이거 어때요?"라고 묻는 것 사이에는 커다란 차이가 있다.

파티션도 없고 모두 공간적으로 가까운 곳에 모여 있기 때문에 두 사람간의 대화는 다른 사람들에게도 대략이나마 전달된다. 개발자들도 대부분의 시간 동안 짝 프로그래밍을 하기 때문에 구체적인 개발 사안에 대해 업무 내내 이런저런 이야기를 주고받는다. (우리 팀에서는 이를 ‘만담’이라고 부른다).

이 대화는 자연스럽게 앞자리에 앉은 기획자에게도 들리게 되는데, 개발자들이 별로 중요하지 않은 기능을 구현하느라 고민하고 있을 때 “어? 그 기능이 그렇게 구현하기 힘들다면 안 해도 됩니다”라는 식으로 바로 조언을 해주기도 한다(기획자들은 상상외로 개발자들만의 공장 얘기를 잘 알아듣고 이해한다). 크리스탈(Crystal) 방법론에서‘최고의 팀이 가지는 일곱 가지 공통적 속성’중 하나로 언급하고 있는 삼투적 커뮤니케이션(Osmotic Communication)이 이루어지고 있는 것이다.

점진적인, 어설픈 기획서

시선을 다시 좁혀서 기획자 윤정환 씨가 일하는 모습을 보자. 사발면 프로젝트 팀의 기획자는 파워포인트 문서를 만드느라 몇 달 동안 고생하지 않는다. 개발자는 기획자가 몇 달 동안 만든 수십 페이지(혹은 백 여 페이지) 분량의 파워포인트 파일을 대충 훑어 읽으며 “말도 안 되잖아, 무슨 생각으로 만든 거야?”라고 투덜거리지 않는다. 프로젝트 중간에 기획의 큰 방향을 바꾸는 경우에도(몇 번 있었다) 비용이 상대적으로 적게 든다. 이것이 가능한 이유는 여러 가지이다.

우선, 한 번에 기획서를 다 만들지 않는다. 프로젝트 초기에 개발자, 기획자, 디자이너가 다 같이 모여서 대략적인 컨셉을 정한 후 앞으로 1~2주 정도 작업할 부분에 대해서만 점진적으로 기획서를 다듬어가고, 개발자들도 해당 부분에 대해서만 자세히 읽어보면 된다.

물론 초기에 큰 방향에 대해 모두 모여 고민을 했기 때문에 나무만 보고 숲을 보지 못하게 될 위험도 적다. 간혹 기획의 큰 방향을 바꾸어야 할 경우가 있으면 역시 다 같이 모여서 의논한다. 공들여서 미리 다 만들어둔 기획서가 없기 때문에 이때도 어느 정도 유연하게 방향을 조정할 수 있다.

또한 앞에서 설명한 바와 같이 파티션으로 나뉘어 있지 않은 공간에 팀 멤버가 모두 모여 앉아 있기 때문에 팀원들 간에 자연스럽게 정보가 흐른다. 따라서 한 일주일 정도 작업한 상세 기획
안을 공유할 때도 사전에 어느 정도 이슈에 대해 공유가 된 상태에서 회의에 참여할 수 있게 된다.

마지막으로 떠오르는 이유는 바로 기획서의 어설픔이다. 어설프다는 것은 내용과 형식 모두에 해당된다.

내용적인 측면을 보자면, 기획자의 의도는 위에서 설명한 여러 가지 경로를 통해 공유되고 있고 행여나 개발자가 중간에 모르는 것이 있으면 바로 앞에(혹은 옆에) 앉아 있는 기획자에게 그때 그때 물어보면 되기 때문에 기획서가 요구사항 명세서나 기능 정의서 역할을 할 필요가 없다. 따라서 모든 것을 명시할 필요 없이 대충만 정리해두면 되는 것이다. 내용이 어설프다는 것은 이런 의미이다.

아울러 형식적인 측면을 보면, 필자가 보아온 보통의 기획서는 첫 장부터 마지막 장까지의 모든 페이지가 동등한 완성도를 갖는다. 각 페이지의 폰트 크기와 위치가 딱딱 맞아떨어져야 하는 것은 기본이고, 만일 수십 장에 걸쳐 화면 예시와 함께 시나리오를 표현하려고 하면, 각 페이지의 모든 화면이 동일한 정밀도로 표현된다.

전통적인(?) 기획서의 경우 작업 방식 또한 전통적으로 이루어지는 경우가 많다. 즉, 모든 세부 기획안을 몇 달에 걸쳐 한 번에 다 작성하는 것이다. 이 두 가지가 결합되면 엄청난 낭비를 만들어낸다. 프로젝트 중간에 화면 구성을 약간 바꿀 일이 생긴다면? 모든 페이지를 찾아다니며 변경 사항을 반영하느라 귀중한 시간을 소비하게 된다.

사발면 프로젝트 팀의 기획서는 얼핏 보면 성의 없이 대충 만들어진 것으로 보인다. 예전에 만들어놓은 페이지에 나오는 화면 예시와 최근에 만들어진 페이지에 나오는 화면 예시가 다르기도하고, 각 페이지 간의 폰트 크기와 모양이 살짝살짝 다른 것도 예사다. 어떤 페이지는 상당한 정밀도로 표현되어 있고 또 다른 페이지는 낙서 수준인 경우도 있다. 형식이 어설퍼서 잃게 되는 것은? 아무리 생각해봐도 없다. 얻는 것은?

개발자는 수정된 기획 문서를 빨리 받아볼 수 있게 되고, 기획자는 좀 더 창의적이고 생산적인 일에 집중할 수 있게 된다(사발면 프로젝트의 기획자인 윤정환 씨는 불행하게도 기획자이면서 동시에 PM이기도 해서 파워포인트 작업을 안 하더라도 이미 시간이 절대적으로 부족한 상태이다. 절대적인 시간 부족의 문제는 잦은 야근과 주말 근무로 대충 해결하고 있는데 이런 방식이 얼마나 지속 가능한 것인가(sustainable pace)를 두고 팀원들 사이에 의견이 분분한 상태이다).

요구사항 명세, 변경 이력 관리, 추적 가능성

사발면 프로젝트 팀에 있어서 파워포인트로 작성된 기획서는 일종의 요구사항 명세서라고 볼 수 있는 유일한 문서인데, 이 문서가 일관성도 없고, 변경 이력 관리도 안 되며, 추적 가능성(traceability)도 전혀 없다면 문제가 되지 않을까?

최근에 시스템의 모든 범위를 포괄하는 단일한 문서가 없어서 문제가 발생한 경우가 한 번 있었다. 사발면 프로젝트의 핵심 기능 중 하나이자 여러 테스터들이 좋다고 얘기한 기능 한 가지가 보름이 넘도록 작동되지 않는 채로 방치되어 있었는데 프로젝트 팀의 어느 누구도 모르고 있었던 것이다. 강문식 씨의 노력으로 테스트 커버지리가 거의 100% 가까이 유지되고 있는 서버 측 단위 테스트 모음(RSpec을 쓰고 있다)만 믿고 수동 테스트나 기능 테스트(혹은 인수 테스트)를 부실하게 한 결과, 단위 테스트로는 적절히 처리하기 힘든 모듈에서 문제가 발생했던 것이다.

이 문제를 보완하기 위해, 지난주부터 시스템의 전체 기능 명세서와 비슷한 것을 엑셀 파일에 작성하기 시작했다(박영록 씨가 이를 건의했고 작업은 고명석 씨가 진행하고 있다). 여기서 잠깐! XP는 문서를 만들지 않는 방법론 아니었나? 여기에는 두 가지 오해가 있다.

첫째, 우리 팀은 XP를 하고 있지 않다. 물론 XP의 가치와 원칙을 존중하고 이를 따르기 위해 노력하고 있긴 하지만 딱히 XP 팀이라고 말하기는 힘들다. 둘째, XP에서는 문서를 만들지 말라고 하지 않는다. 굳이 말하자면 불필요한 문서를 만들지 않는 것(더 일반적으로는 불필요한 행위를 하지 않는 것 - 토요타 생산 방식에서 말하는‘낭비 제거’의 개념)이 중요하다.

엑셀 파일에는 사용자 스토리(User story)와 비슷한 단위의 기능 조각들과 각 기능에 대한 명세가 인수 테스트 형식의 문장으로 적혀 있다. 엑셀 문서 작성이 완료되면 셀레늄을 이용하여 최대한 많은 부분의 기능테스트를 자동화할 생각이다. 자동화 비용이 많이 드는 부분은 일부 남겨 놓고 수동으로 테스트를 할 것이다( 『Lessons Learned in Software Testing』에서도 100% 완벽한 자동화를 하기 위해 너무 많은 노력을 들이지 않는 것이 좋다고 말하고 있다).

실시간으로 사용자 목소리를 듣다

사발면 프로젝트는 얼마 전부터 소수의 사용자를 대상으로 닫힌 베타 테스트를 시작했다. 베타 테스터 그룹과의 원활한 커뮤니케이션을 위해 비공개 포럼을 설치했는데, 이것만 가지고는 오픈마루답지 못하다는 생각이 들어서 이런저런 고민을 하다가 ‘새 글 듣기’프로그램을 만들었다.

포럼에 누군가가 새 글을 올리면 TTS(Text-to-speech, 문자를 음성으로 변환하는 기술)를 통해 스피커로 즉시 그 글의 제목을 읽어주는 것이다. 우리 팀의 독창적인 발명품은 아니고, 워드커닝햄(Ward Cunningham)의 아이디어인 ‘Spoken Log’를 응용한 것이다.

처음에는 단순히 사용자의 피드백에 더 재빠르게 대응하자는 생각에서 만들었는데 며칠 쓰다 보니 그 이상의 의미가 있다는 사실을 알게 됐다. 사무실 어딘가에서(사실은 필자의 발 밑에 있는 스피커에서) 들려오는 목소리를 듣고 있으니까 ‘진짜 사용자’가 지금 이 순간 우리 서비스를 ‘진짜로 사용하면서’ 우리에게 '진짜 목소리’로 말을 걸고 있다는 느낌이 드는 것이다. 그야말로 엄청난 동기부여가 되는 셈이다.

물론 단점도 있다. 목소리가 들릴 때마다 포럼을 살펴보느라 개발(혹은 기획, 혹은 디자인)이 잠깐씩 중단된다는 점. 그래도 단점에 비해 장점이 훨씬 크다고 생각해서 계속 켜놓고 있다. 시간이 나면 조금씩 개선을 할 생각이다. 예를 들어 우리 팀 사람들이 쓴 글은 다른 목소리로 들려준다거나 하는 방법도 가능할 것이다.

계속되는 실험들, 끝없는 실패들

기왕이면 애자일 방법론의 많은 실천법들을 성공적으로 도입했다는 이야기를 하고 싶지만 불행하게도 사실은 그렇지 못하다. 그 동안 수많은 시도들을 해왔으나 일부만이 성공적으로 정착되었다.

여기서 필자가 실패를 거론하는 이유는 두 가지이다.

첫째, 기왕이면 긍정적인 얘기만 하려고 했는데 옆 자리의 동료 박영록씨가 솔직하게 쓰라고 부추기는 터라 이에 대해서도 충분히 언급하게 되었다.

둘째, 실패에 대한 언급 없이는 서두에 밝혔던 이 글의 목적(애자일 방법론을 도입하고자 하는 독자들에게 용기를 주는 것)을 달성할 수 없을 것으로 판단했기 때문이다. 사람들이 모여서 일하는 곳은 다 비슷비슷하고, 오픈마루도 예외는 아니라는 점을 보여주고 싶다. 모든 것이 한 번에 잘 돌아가는 기적 따위는 일어나지 않는다. 빠르게, 자주, 많이 실패할수록 성공 횟수도 늘어나는 것이다(fail early and often).

스토리 기반 계획법의 실패

많은 노력을 했으나 결국 중단된 것 중 하나는 사용자 스토리 기반 계획법이다. 요약해서 설명 하자면, 고객(우리 팀의 경우엔 모든 멤버가 참여하는 편이다)이 사용자 스토리를 적고 개발자들이 각 스토리에 대해 추정하면 다시 고객이 추정치와 중요도를 고려하여 작업 우선순위를 세운다는 간단하고 합리적인 방식이다.

사발면 팀에서는 이 방식이 제대로 되지 않았다. 개발자들이 익숙하지 않은 분야의 작업에 대해 추정하다 보니 추정의 정확도가 낮았던 점이 주요 원인이었다.

추정의 정확도가 낮았다는 점을 인식하게 된 후 몇 차례에 걸쳐 재추정을 했지만 그래도 만족스럽지 못했고, 급기야 추정 방식 자체를 바꾸기도 했다. 단일한 추정치를 내세우는 것이 아니
라 범위 기반(예를 들면‘하루에서 삼일’이라는 식으로) 추정을 하고 간단한 수식을 통해 최적 완료 시점과 버퍼(여유분)를 계산하는 방식이었다.

또, 스토리 포인트의 단위도 여러 가지로 바꾸어 보았다. 아무 의미 없이 스토리 간 상대비교만 가능한 SP라는 단위를 써 보기도 하고, 이상적인 시간(ideal hour) 단위를 써보기도 하고, 작업 일 단위를 도입해보기도 했지만 별 소용이 없었다.

효과적인 계획법을 정착시키지 못한 채로 시간은 계속 흘러갔고, 초기에 예상했던 것보다 작업 속도(team velocity)가 너무 떨어지는 바람에 일정을 연기하고 개발 범위(기획안)를 소위‘피골이 상접한’수준으로 줄였다. 그 이후에도 뼈를 깎는 노력으로(피골은 이미 상접했으니 이제 뼈를 깎아야 한다) 기획을 더 줄여야만 했다.

결국 어떻게 됐나? 추정의 정확도는 낮고, 스토리 포인트의 단위는 자꾸 바뀌고, 범위 기반 추정 방식이 익숙하지 않아서 매번 고생을 하게 되니, 유용성은 낮으면서 노력은 많이 들어가는 꼴이 되어 흐지부지 포기해버렸다.

지금은 약간 어설픈 방식으로 일정 관리를 하고 있다. 일단 잦은 릴리즈를 위해 보름 정도 간격으로 이정표를 찍어놓고, 그 사이에 해야 할 일을 ‘대충’ 나열한다. 만일 시간이 부족하면? 열심히, 미친 듯이 달리는 거다. 우린 이 방식을 애자일(agile) 방법론이란 이름에 살짝 변형을 가해 ‘애드혹(ad-hoc) 방법론’이라고 부르고 있다.

이상적인 환경에서 과욕을 부리다

필자가 생각하는 사발면 팀 최초의 문제는 팀이 만들어지기 전부터 존재했다. 이 문제는 애자일 방법론을 도입하고자 하는 다른 조직이나 개인들도 겪게 될 가능성이 크다고 생각해서 조금 자세히 이야기하고자 한다.

입사 초기, 필자가 보기에 오픈마루는 완벽한 XP를 할 수 있는 이상적인 조직 같았다. 스튜디오의 책임자인 실장을 비롯하여 몇 몇 팀장들, 그리고 대부분의 구성원이 XP 도입을 매우 긍정적으로 생각하고 있었을 뿐 아니라 몇몇 초기 멤버는 입사 동기가 ‘XP를 하기 위해서’일 정도였다. 그래서였을까? 필자를 포함한 몇몇 사람들은‘이상적인 XP 조직’을 꿈꾸기 시작했다(여러 책들에 나오는 말이지만 사실은 ‘이상적인 혹은 완벽한 XP’라는 말 자체가 XP적인 발상과 거리가 멀다).

우리는 조직 구조를 ‘XP에 어울리게’바꾸고 싶어 했다. 오픈마루는 웹 개발자들로 이루어진 웹 서비스팀, 기획자와 디자이너등으로 구성된 기획팀, 검색엔진 개발자들로 구성된 검색팀, 그리고 인프라스트럭처를 개발하는 인프라팀으로 이루어져 있는데, 우리가 생각하기에 이러한 팀 구성이 소위‘애자일스럽지 못하게’ 여겨졌던 것이다.

오픈마루 내의 ‘애자일 진영(이런 표현은 지나치게 단순화된 우스운 표현이지만, 글을 간결히 하기 위해 이용토록 하겠다)’ 사람들은 '유쾌한 이노베이션'과 같은 책에서 나오는 조직 스타일을 원했다. 즉 각각의 전문 분야별로 팀을 만들고 해당 분야의 전문가를 각 팀 별로 모아두는 것 보다는, 실제로 수행하게 될 프로젝트 단위로 팀을 나누고 각 분야의 전문가들이 서로 섞여서 한 팀을 이루어야 한다는 것이다.

이를 통해 다른 분야의 사람들과 지식 및 경험을 나누고 좀 더 유기적으로 일할 수 있게 될 것이라는 생각이다. XP 실천법으로 따지자면 ‘전체 팀(Whole Team)’을 이루자는 주장이다.

조직 내의 모든 팀장들과 모든 멤버들이 이 방식에 동의하는 것은 아니었다. 각자가 나름의 근거와 논리를 내세우며 치열하게 논쟁했고 간혹 서로 감정이 상하게 되는 일도 있었다.

결국 어떻게 되었나? 우리가 제안한 팀 구조는 결국 채택되지 않았다.

하지만 조직도상의 팀 구성과는 별개로 여러 팀의 사람들이 프로젝트를 중심으로 모여서 하나의 워크파트(workpart)를 이루었고, 이 워크파트를 우리는 사발면 프로젝트 팀이라고 부르고
있다. 처음에는 각 조직도상의 팀 별로 서로 떨어져 앉아 있었지만 두 차례에 걸친 자리 이동(사무실 이전 등)의 결과로 지금과 같이 워크파트의 모든 사람들이 모여 앉을 수 있게 되었다.

돌이켜보면, 우리는 구체적으로 어떤 일을 할 것인지에 대한 목표도 정해지기 전부터 어떻게 할지에 대한 이야기를 하느라 에너지를 소비했던 것이다. 다시 말해 구체적인 혹은 당면한 사례를 중심으로 하는 것이 아니라 추상적인 혹은 가정에 근거한 논점을 놓고 불필요한 논쟁을 한 것이 아닌가 싶다.

물론 사발면 프로젝트와 관련된 일을 하는 모든 사람이 이 워크파트에 소속된 것은 아니다. 검색팀과 인프라팀은 별도의 프로젝트를 통해 사발면 프로젝트 팀과 협업을 하고 있는 형태로 일을 진행하고 있으므로 진정한 의미의 ‘전체 팀’ 혹은 ‘함께 앉기’라고 할 수는 없다.

전체 팀이 아니라서 큰 문제가 생겼을까? 그럭저럭 잘 굴러가고 있다. 물론 문제가 없다고는 할 수 없다. 예를 들어 팀 간의 커뮤니케이션에 종종 문제가 발생해 왔는데 생각해보면 검색팀이나 인프라팀의 문제라기보다는 사발면 팀의 문제가 컸다.

사발면 프로젝트 팀은 명확하게 정리된 요구사항 명세서도 없고, 기획안을 미리 모두 구체화해 놓지도 않았고, 일정도 확정되지 않은 상황이며, 소프트웨어 설계도 같은 것은 더더욱 기대하기 힘든 상황인데 타 팀에서는 우리와 협업하기 위해서 이런 정보들이 꼭 필요했던 것이다. 초기에는“아직 정해지지 않았어요. XP는 원래 이래요”라는 식으로 대답했다. 정직한 답변이기는 하지만 좋은 답변은 아니고, 어떻게 보면 큰 잘못이다.

대부분의 독자들이 개발자일 것이므로 소프트웨어에 비유를 하자면, 기존 시스템에 새로운 모듈이 추가되었을 때 양자 간의 인터페이스가 맞지 않으면 새로운 모듈을 제작한 쪽에서 기존 모듈에 대한 어댑터(Adapter)를 제공하는 것이 옳다. 조직의 문제에 있어서도 마찬가지라고 생각한다. XP 조직이 다른 조직과 협업을 하고자 한다면 다른 조직이 원하는 형태로 협업을 할 수 있도록 최대한 맞추는 것이 옳다고 본다.

사발면 프로젝트 팀의 경우 PM이 어댑터의 역할을 적극적으로 수행했어야 하는데 이 부분이 미흡했다. 사실 우리 프로젝트에는 PM이 두 명이다. 앞에서 얘기했던 윤정환 씨, 그리고 바로
필자이다. 짝 프로그래밍이 아니라 짝 관리라고 해야 하나? 두 명이기는 하지만 대부분의 PM 노릇은 윤정환 씨가 하고 있고 필자는 개발PL 노릇도 제대로 못하고 있으니 이른바‘바지PM’이라고 보는 것이 맞다. 어쨌건 간에 검색팀이나 인프라팀과의 협업은 모두 기술적인 내용이기 때문에 필자가 어댑터 노릇을 잘 했어야 하는데 그러지 못했으므로 결국은 필자의 잘못인 게다.

“그건 애자일스럽지 않아”

한 때 오픈마루 사무실에서는 “그건 애자일스럽지 않아!” 혹은 “오, 그것 참 애자일스럽군”이라는 말을 종종 들을 수 있었다. 이런 말을 쓰지 않게 된 것은 몇 달쯤 된 것 같은데 아마도 우리가 ‘애자일’이라는 단어를 모호하게 사용하고 있다는 것을 깨달은 후부터인 것 같다. 그러니까 우리는 ‘좋다’의 의미로 “애자일스럽다”,‘ 나쁘다’의 의미로 “애자일스럽지 않다”를 사용하고 있었던 것이다. 한 마디로 오용이었다.

이러한 오용의 배경에는 아마도 ‘내가 알고 있는 방법론이(적어도 이 조직에 있어서는) 가장 좋다’는 유아적 자신감이 존재하지 않았을까. 다른 사람보다도 필자 스스로를 되돌아보며 내리게 된 결론이다. 그리고 이런 태도는 결코 애자일 방법론 도입에 득이 되지 않았을 것이다.

얼마 전, 필자가 지금까지 ‘애자일스럽지 않다고’여기던 작업 방식을 주장하던 사람들이 실제로 작업하는 모습과 결과를 보았을 때 크게 감명 받은 일이 있다. 바로 검색팀인데, 작년 말에 한 해를 마감하며 프로젝트 종료 보고를 하는 자리였다. 이 팀은 단위 테스트, 짝 프로그래밍, 정기적인 회고(retrospectives)를 통한 점진적 개선, 월 단위의 잦은 릴리즈 등 그야말로 너무나 ‘애자일 하게’해왔던 것이다.

사람을 바꾼다는 것

애자일 방법론을 도입한다는 것은 다른 대부분의 일과 마찬가지로 결국 사람을 바꾸는 문제로 귀결된다. 하지만 자신이 더 좋은 방법, 혹은 유일하게 올바른 단 하나의 방법을 알고 있으니 저 사람들을 설득하여 그 방법을 따르도록 바꾸어야 한다는 태도로는 아무 것도 할 수 없다.

자기 주변에 모여 있는 사람들을 보자. 그들은 모두 나름의 분야에서 나름의 철학과 방법으로 크고 작은 성공을 쌓아왔다. 스스로의 경험을 통해 얻어진 생각과 행동을 타인이, 그것도 말로 설득하여 바꾸려고 하는 시도는 무모한 일일 뿐 아니라 옳은 일도 아니라고 생각한다.

오픈마루에서의 경험을 통해 필자가 얻게 된 믿음은 단순하다. 남이 그대로 따라주었으면 하는 좋은 습관을 자신이 알고 있다면 말과 논리로 설득하기보다는 묵묵히 행동으로 보여주는 것이 좋겠다는 믿음, 그리고 나름의 성공을 쌓아온 서로 다른 개인이나 조직의 습관 뒤에는 어떤 공통적인 속성이 있을 것이라는 믿음이다.

이러한 믿음을 가지고 볼 때, 자신이 속한 조직에 어떠한 방법론을 도입한다는 것은 결국 행동을 통해 남에게 긍정적인 영향을 주고 나 또한 그들로부터 좋은 영향을 받으며 서로의 경험 뒤숨어있는 공통점을 찾아가는 과정일 것이라고 생각한다. 따라서 방법론 ‘도입(adoption)’이라는 용어는 이런 측면에서 그리 적절치 않다.