최근에 바쁜 일도 끝나고 해서 (아직 논문 실험 데이터 뽑는 일이 남긴 했습니다만 ㅋㅋ) 이 책을 다시 잡았습니다. 제 블로그에 자주 오시는 분은 (계실지 모르겠습니다만) 아시겠습니다만, 잠시 놓고 있었던 "생각하는 프로그래밍"도 다시 읽고 있습니다.
애자일 회고를 읽으며 한 가지 감탄했던 것은, 회고라는 행위 자체도 Agility의 영역에서 자유롭지 않다는 점이었습니다. 나부군님의 이야기를 한번 읽어보죠.
[전략] 다만 회고를 진행하는 목적을 잊지 말아야 한다. 팀이 프로세스를 개선하고 같은 문제점을 반복하지 않기 위해서 회고를 진행하는 것임을 잊지 말아야 한다. 회고 자체가 목적이 되어서는 안된다.막연한 기대를 품고 사람들이 모두 지겨워하고 괴로워하는 회고를 억지로 이끌어나가는 팀에게 개선은 매우 힘든 일이 될 것이다. 회고 자체도 개선해야 한다. 뭔가 문제가 있다면, 진행 과정을 더욱 간단하고 쉽게 만들자. 사람들이 최대한 부담을 느끼지 않는 선에서 시작해서 발전해 나가는 방식도 좋다. 처음 회고를 진행하다보면 많은 난관에 부딪힐 수 있다. 이때 회고 자체를 개선할 수 있다는 마음가짐으로 회고에 대한 회고를 반복하다보면 결국 팀이 개선하는 데도 큰 도움이 될 것이다. [후략] (191페이지)
회고를 회고하고 개선한다... 결국 모든 것은 개선의 대상이라는 뜻 되겠습니다. 애자일 지침들에서 가장 마음에 드는 것 중 하나는, "어떤 것도 처음 그 상태로 내버려두지 않는다"는 것입니다. 결국 프로젝트의 목적이란 불확실성을 프로젝트에서 조금씩 덜어나가는 것일 터. 불확실성을 제거하는 것은 좋은 제품을 만드는 데도 도움이 되고, 더 나은 팀을 만드는 데도 도움이 되며, 더 나은 일상생활을 영위하는 데도 도움이 됩니다. (웃음) 어쩌면 프로그래머가 추구해야 할 궁극적인 지점은 바로 그 부분이 아닐까요? 더 나은 삶을 만드는 것.
더 나은 삶을 만들기 위해서는, 단순히 프로그래밍 기술을 뛰어 넘는 어떤 것이 필요합니다.
아마도 여러분은 현재 각자 일하고 있는 분야에서 전문가일 것이다. 하지만 회고를 매끄럽게 진행하는 업무를 하기 위해서는 소프트웨어 분야와는 다른 기술과 시각이 요구된다. 새로운 기술을 연마하는 데는 많은 시간과 연습이 필요하다. 마음의 여유를 가지고, 원하는 바가 무엇인지 잘 정리하고, 스승을 찾아라. 여러분은 자신을 발전시키는 일에도 '조사하고 적용하게 하기'를 사용할 수 있을 것이다. (82페이지)
분명 애자일 프로세스도 기술입니다. 하지만 여태껏 알아왔던 어떤 프로세스도, 프로세스에 참여하는 사람의 삶의 질을 어떻게 향상시킬 것인지에 대해서는 언급하지 않았던 것 같아요. 주로 예측 가능성의 문제에만 집중해 왔죠. 반면 애자일 프로세스는 프로젝트에 참여하는 사람들이 어떻게 협동하면 보다 나은 무엇이 만들어질 수 있는지 자주 이야기합니다. 회고도 그 중 하나예요.
애자일 프로세스 전반에 큰 관심이 없더라도, 이 책은 한 번 읽어볼 만 하리라고 생각합니다. 회고라는 것은 결국 '과거에 했던 어떤 것'을 돌아보는 행위일텐데, 세상에 과거 따위는 없다고 말하는 프로세스는 없거든요.
애자일 개발자들이 어떤 형태의 자리에 앉아서 일을 하도록 해야 하느냐, 하는 데 있어서는 별로 이견이 없는 편입니다. Extreme Programming의 사례를 보아도 그렇습니다만, '적극적인 협업이 가능한 형태면 좋다'의 정도인 것 같습니다. 애자일 원칙들이 대개 그렇습니다만, 정형화된 '규칙(regulation)'이 있는 건 아닙니다.
보통 프로그래머들은 협업의 문제를 컴포넌트 인터페이스 레벨에서 사고하는 경향이 있습니다. 너는 네 일을 하고, 나는 내 일을 하는데, 그 두 일이 인터페이스 레벨에서 잘 연동이 되면 만사 OK다 라는 것이죠. 물론 그렇게만 되면 프로젝트 관점에서야 만사 OK일 수도 있겠습니다만(아닐 수도 있습니다) 문제는 그런 식의 관점이 생산성 측면에서 어떠한 이득도 가져다 주지 못한다는 데 있습니다. 생산성을 극대화시키는 것이 목적이라면, 내 일/네 일 관계를 넘어서는 좀 더 기민한 형태의 의사소통이 필요합니다.
개인적인 경험에 따르면, 이러한 의사소통이 극도로 잘 이루어지는 경우에는 (설사 그 의사소통 형태가 그다지 애자일 적이 아니라고 하더라도) 프로그래머들을 개발 완료 시한 한달을 남겨놓고 소집해서 개발을 시작하더라도 완결된 프로그램을 내 놓을 수가 있었습니다. 물론, 그 중 한 사람은 '프로젝트의 성격과 범위, 그리고 관련 기술에 극도로 능통한 사람이어야 합니다. 모든 의사 소통은 그 '달인'을 통해서 이루어져야 하고, 모든 프로그래머들은 그 한 사람과 자신의 일에 대해서 의논을 해야 합니다.
신적인 의사 소통 모델
이런 식의 의사소통 모델에서는 자리 배치는 그다지 중요하지 않습니다. 모든 사람이 (극단적으로 보자면) 딱 한 사람과 자신의 업무에 대해서 이야기를 하면 되니까요. 다른 사람들과 의사소통을 해야 하는 문제는 '달인' 혼자서 다 처리했습니다. 인터페이스 중재부터 시작해서, 개발 범위의 조정 등등... 각각의 개발자들은 중간의 '달인'이 내린 지침에 따라 개발하되, 자신이 담당한 모듈에 대한 클라이언트 인터페이스는 자신이 개발해서 다른 사람들에게 배포하기만 하면 되었습니다.
하지만 이런 '신적인 의사소통 모델'(중간에 마치 신과도 같은 개발자 한 사람이 떡 버티고 있는 모델)은 쉽게 찾아볼 수 있는 형태는 아닙니다. 이런 신적인 의사소통 모델이 널리 통용될 수 없는 이유는 몇 가지 있습니다.
(1) 달인이 드물다 (2) 아무도 달인의 자리에 오려고 하지 않는다.
물론 가장 큰 문제는, 저런 역할을 담당해 줄 달인이 실질적으로는 거의 없다는 점입니다. 그 정도의 권위와 카리스마를 갖춘 사람과 같이 일을 할 수 있다면 정말로 영광이겠습니다만, 그런 드문 기회는 그야말로 드물기 때문에 문제가 됩니다. 설사 그런 사람을 찾을 수 있다고 하더라도, 나중에 프로젝트가 실패하게 되면 그 사람 혼자서 '독박'을 써야 하는데, 아무리 달인이라고 하더라도 그렇게 하려고 할까요?
그렇다면 실제상황에서 써먹을 만한 기민한 형태의 의사소통은 어떻게 해야 가능해지는 걸까요? 어떻게 근무환경을 조성해야 그런 형태의 의사소통이 가능해지는 것일까요?
위의 동영상은 Daum의 제주 GMC 센터의 동영상입니다. 스마트플레이스에 올라왔길래, 참고삼아 링크를 걸어보았습니다. 다른 부분은 논외로 하고, 자리 배치만 한번 눈여겨 보시죠. 팀 내에 있는 모든 사람들이 원형으로 배치되어 등을 지고 일을 하고 있습니다. 뭔가 의논해야 할 일이 생긴다면, 바로 의자를 돌려 관련된 사람들끼리 이야기를 할 수 있는, 그런 구조입니다. 중단기적인 프로젝트를 밀어부치기에는 좋은 구조입니다.
하지만 이런 구조는 "모든 프로그래머는 자신만의 공간을 원하게 마련이다"라는 통상적인 믿음과는 좀 거리가 있습니다. 옆 사람 타이핑 소리까지 다 들릴 정도로 가까운데다, 머리를 조금만 돌리면 옆 사람 모니터까지 다 보이거든요. 물론 Pair Programming을 진행하기에는 아주 이상적인 조건이긴 합니다. 하지만 이런 구조에서 일하는 사람들은 '자신만의 무언가'를 원하게 되는 순간 근무 환경을 떠나야 해요. 근무 환경을 나서면 그 밖에는 근무와는 별 상관이 없는 이질적인 공간이 기다리고 있는데, 사람에 따라서는 그런 이질적인 환경이 사색에 오히려 방해가 될 수도 있습니다.
그러니 저는 자신만의 공간과 협업을 위한 공간 사이에 어느정도의 논리적/물리적인 구분이 존재하는 것이 바람직하지 않겠는가, 하는 생각이 들어요. 자신의 자리에서 일하다가, 협업이 필요할 때 협업을 위한 공간으로 들어가는. 뭐 그런 구조 말이죠. 다만 그 두 공간을 왔다갔다 하는게 그다지 어렵지는 않아야 합니다.
