보통 프로그래머들은 협업의 문제를 컴포넌트 인터페이스 레벨에서 사고하는 경향이 있습니다. 너는 네 일을 하고, 나는 내 일을 하는데, 그 두 일이 인터페이스 레벨에서 잘 연동이 되면 만사 OK다 라는 것이죠. 물론 그렇게만 되면 프로젝트 관점에서야 만사 OK일 수도 있겠습니다만(아닐 수도 있습니다) 문제는 그런 식의 관점이 생산성 측면에서 어떠한 이득도 가져다 주지 못한다는 데 있습니다. 생산성을 극대화시키는 것이 목적이라면, 내 일/네 일 관계를 넘어서는 좀 더 기민한 형태의 의사소통이 필요합니다.
개인적인 경험에 따르면, 이러한 의사소통이 극도로 잘 이루어지는 경우에는 (설사 그 의사소통 형태가 그다지 애자일 적이 아니라고 하더라도) 프로그래머들을 개발 완료 시한 한달을 남겨놓고 소집해서 개발을 시작하더라도 완결된 프로그램을 내 놓을 수가 있었습니다. 물론, 그 중 한 사람은 '프로젝트의 성격과 범위, 그리고 관련 기술에 극도로 능통한 사람이어야 합니다. 모든 의사 소통은 그 '달인'을 통해서 이루어져야 하고, 모든 프로그래머들은 그 한 사람과 자신의 일에 대해서 의논을 해야 합니다.
신적인 의사 소통 모델
이런 식의 의사소통 모델에서는 자리 배치는 그다지 중요하지 않습니다. 모든 사람이 (극단적으로 보자면) 딱 한 사람과 자신의 업무에 대해서 이야기를 하면 되니까요. 다른 사람들과 의사소통을 해야 하는 문제는 '달인' 혼자서 다 처리했습니다. 인터페이스 중재부터 시작해서, 개발 범위의 조정 등등... 각각의 개발자들은 중간의 '달인'이 내린 지침에 따라 개발하되, 자신이 담당한 모듈에 대한 클라이언트 인터페이스는 자신이 개발해서 다른 사람들에게 배포하기만 하면 되었습니다.
하지만 이런 '신적인 의사소통 모델'(중간에 마치 신과도 같은 개발자 한 사람이 떡 버티고 있는 모델)은 쉽게 찾아볼 수 있는 형태는 아닙니다. 이런 신적인 의사소통 모델이 널리 통용될 수 없는 이유는 몇 가지 있습니다.
(1) 달인이 드물다
(2) 아무도 달인의 자리에 오려고 하지 않는다.
물론 가장 큰 문제는, 저런 역할을 담당해 줄 달인이 실질적으로는 거의 없다는 점입니다. 그 정도의 권위와 카리스마를 갖춘 사람과 같이 일을 할 수 있다면 정말로 영광이겠습니다만, 그런 드문 기회는 그야말로 드물기 때문에 문제가 됩니다. 설사 그런 사람을 찾을 수 있다고 하더라도, 나중에 프로젝트가 실패하게 되면 그 사람 혼자서 '독박'을 써야 하는데, 아무리 달인이라고 하더라도 그렇게 하려고 할까요?
그렇다면 실제상황에서 써먹을 만한 기민한 형태의 의사소통은 어떻게 해야 가능해지는 걸까요? 어떻게 근무환경을 조성해야 그런 형태의 의사소통이 가능해지는 것일까요?
위의 동영상은 Daum의 제주 GMC 센터의 동영상입니다. 스마트플레이스에 올라왔길래, 참고삼아 링크를 걸어보았습니다. 다른 부분은 논외로 하고, 자리 배치만 한번 눈여겨 보시죠. 팀 내에 있는 모든 사람들이 원형으로 배치되어 등을 지고 일을 하고 있습니다. 뭔가 의논해야 할 일이 생긴다면, 바로 의자를 돌려 관련된 사람들끼리 이야기를 할 수 있는, 그런 구조입니다. 중단기적인 프로젝트를 밀어부치기에는 좋은 구조입니다.
하지만 이런 구조는 "모든 프로그래머는 자신만의 공간을 원하게 마련이다"라는 통상적인 믿음과는 좀 거리가 있습니다. 옆 사람 타이핑 소리까지 다 들릴 정도로 가까운데다, 머리를 조금만 돌리면 옆 사람 모니터까지 다 보이거든요. 물론 Pair Programming을 진행하기에는 아주 이상적인 조건이긴 합니다. 하지만 이런 구조에서 일하는 사람들은 '자신만의 무언가'를 원하게 되는 순간 근무 환경을 떠나야 해요. 근무 환경을 나서면 그 밖에는 근무와는 별 상관이 없는 이질적인 공간이 기다리고 있는데, 사람에 따라서는 그런 이질적인 환경이 사색에 오히려 방해가 될 수도 있습니다.
그러니 저는 자신만의 공간과 협업을 위한 공간 사이에 어느정도의 논리적/물리적인 구분이 존재하는 것이 바람직하지 않겠는가, 하는 생각이 들어요. 자신의 자리에서 일하다가, 협업이 필요할 때 협업을 위한 공간으로 들어가는. 뭐 그런 구조 말이죠. 다만 그 두 공간을 왔다갔다 하는게 그다지 어렵지는 않아야 합니다.
그런 구조에 대해서는 http://www.talk-with-hani.com/archives/660를 참고해 보시는 것이 좋겠습니다. 다만 관리자 입장에서 보면 모든 개발자들에게 이런 공간을 마련해 줄 만큼 돈이 없다는 게 문제가 될 수도 있겠죠. 또 다른 구체적인 사례도 있는데, http://blog.naver.com/yuzico/130007299724 를 참고하세요. 스토리 카드 보드 등등을 망라하는 재미있는 사례들을 많이 보실 수 있습니다. 자리 배치에 대해서는 그다지 상세히 언급하고 있지는 않습니다.
댓글 없음:
댓글 쓰기