몽둥발이님께서 지난 6월 자신의 블로그에 Agile과 프로젝트 현실이라는 제목의 글을 쓰셨습니다. 솔직하게 쓴 글입니다.

글은 한마디로 요약하자면 "애자일 적용에 현실적 어려움이 있으나 반대로 장점도 있으므로 애자일을 포기하자 말자"입니다. 글 구조는 우선 애자일 적용의 문제점과 애자일에 대한 흔한 오해를 언급합니다. 그다음에 아래과 같은 전환점을 두어서 애자일이 왜 우리 소프트웨어 개발 산업의 미래라고 생각하는지 설명을 합니다.

위에 언급한 문제점들과 오해로 인해 적용하기 쉬운 프로세스라는 현실들을 알고 있지만, 이런 현실에도 불구하고 난 Agile이 우리 Software 개발 산업의 미래라는 생각에는 변함이 없다.

장점 부분은 제가 굳이 커멘트를 할 필요가 없을 것 같고 어려움 부분에 대해 제가 몇 가지 하고 싶은 이야기가 있습니다. 여러가지 사안이 나열되어 있어서 한 번에 다 쓰기에는 글이 너무 길어질 것 같아 한 번에 한 가지 주제를 갖고 차례대로 이야기 해보겠습니다.

오늘은 소위 제품 소유자(Product Owner 이하 PO)의 역할에 대한 이야기입니다. 사진에 "학부모 서비스 프로젝트의 애자일 회고"라는 캡션이 달려 있는 것으로 보아, 이 프로젝트의 PO는 교과부나 한국교육학술정보원(KERIS)의 누군가가 될 것 같습니다. 관련자(stakeholder)는 교사, 교장, 교과부, 학부모, 학생 등등이 될테구요. 우선 글에서 해당 부분을 보죠.

첫번째로 Agile에서 말하는 Product Owner 는 보통 1)사용자가 원하는 화면을 그릴 수 없는 것은 물론이거니와 2)기능에 대해 설명해 줄 수도 없다. 게다가 이 Product Owner는 본인이 검수 담당자 이지만, 본인이 3)검수를 할때 자신이 속한 기관의 상위기관 또는 하위기관의 사용자의 의견을 무시하고 검수할 수가 없다. 항상 책임을 지기 어려운 상황에 놓여있다. 프로젝트에서 무엇인가 의사결정을 원할 때 그 결정을 내리기 위해 많은 시간이 소모되기 일쑤이다. 그러다보면, 자연스레 시간은 소모되고 Product Owner는 결정권자가 아닌 4)병목(bottle neck)이 되어버린다. 의사결정권자가 애물단지로 전락하는 순간이다.

숫자와 강조는 김창준

이 글을 읽으면서 제가 예전에 썼던 애자일의 미래가 생각이 났습니다.

필자가 그래디 부치(Grady Booch)를 인터뷰한 기사가 마소 2002년 11월호에 실렸다. 그래디 부치는 ‘UML의 아버지’ 중 한 사람이고 RUP와도 관련이 깊지만 애자일 연합(Agile Alliance) 위원회 소속이고 스스로 “애자일을 믿는다”고 표현하는 사람이다. 그에게 XP에서 가장 취약한 부분이 무엇인지 물었다.

XP에서 가장 약한 부분은 -- 이 의견은 랄프 존슨(Ralph Johnson)과 함께 하는 것인데 -- ‘고객’이라고 하는 개체에 믿을 수 없을 정도로 많은 책임을 덩어리 째 맡기면서, 어떻게 그 고객이 성공적일 수 있는지에 관해서는 대부분 아무런 가이드도 제공해주지 않는다는 점입니다. 개발자의 일이 간단해질 수 있게 상당한 양의 책임이 고객 역할에 전가됩니다. 하지만 실제는, 그 복잡성은 대체로 그대로 남습니다(하지만 XP는 이것을 은폐합니다). --그래디 부치

(중략)

훌륭한 개발자가 되는 방법은 XP에 있다. 하지만 훌륭한 고객이 되는 방법은 XP에 없다. 그런데 XP는 훌륭한 고객에 의존한다. 무엇을 만들어야 할 지의 의사 결정과 그걸 어떻게 만들어야 할 지의 의사 결정을 분리하고, 또 크게 보면 결정자와 건설자의 책임을 분리하고 있다. "고객이 사용자 스토리를 잘 만들어주면, 우리는 그 때부터 시작이다. 프로젝트가 실패하면 고객이 사용자 스토리를 잘못 만들어서 그런 것이다."

1)번에서 PO가 사용자가 바라는 화면을 그려줄 수 없다고 했는데, 그런 일을 잘 하려면 어떤 지식과 기술이 필요할까요? 제 생각에는 제품 관리자(product manager), 도메인 전문가, 인터랙션 설계자, 업무 분석가(business analyst) 등의 지식과 기술이 필요합니다. 그런데 어떤 애자일 프로젝트에서는 PO가 이런 지식과 기술, 능력을 갖췄는지 확인하지 않은 상태에서 이 모든 책임을 PO에게 넘기는 경우가 있습니다. 그러면 소프트웨어를 직접 만드는 사람들은 제품의 사업적 실패에 대해 책임을 피할 수 있기 때문입니다.

사용자가 원하는 화면을 그려주는 일은 일반적으로 PO의 역할이 아닙니다. 통상 PO 역할을 맞는 사람을 보면 스스로 그런 일을 잘 할 능력이 없습니다. "화면을 그리는 일"은 현장 고객팀이라고 부르는 사람들과 개발자들이 해야 하며, 그 중 PO는 비전을 유지하고 퍼뜨리며 어려운 트레이드오프 결정을 내리는 역할을 합니다.

2)번 기능에 대해 설명해 주는 것도 꼭 PO만의 역할은 아닙니다. 물론 이 경우 1번보다는 PO가 잘 할 수 있는 일에 속하긴 하지만 도메인 전문가와 업무 분석가들이 이 일을 더 잘 할 수도 있습니다.

3)번은 PO가 독자적인 최종 결정을 내려줄 수 없다는 이야기입니다. 그런데 거의 대부분의 프로젝트가 그렇습니다. 한 사람만을 위한 소프트웨어를 개발하는 일은 정말 드물기 때문입니다. 따라서 PO는 독단적인 판단을 하는 사람이 아니라 의견을 통합(consolidate)하여 결정하는 사람입니다. 그래서 이 경우는 예컨대 관련자(stakeholder) 위원회를 만들 수 있는데, 그 위원회에서 한가지 결정이 이뤄지도록 노력하는 사람이 PO입니다.

이렇게 여러 전문분야를 관통하고 이런 저런 능력에 넘치는 일을 요구하기 때문에 4)번에서 말하듯이 PO가 병목이 되는 겁니다.

일반적으로 XP나 스크럼 모두 고객(Customer) 혹은 제품 소유자(Product Owner)가 너무 많은 역할을 하기 때문에 혼동과 문제가 생기는 것 같습니다. 그래서 저는 다른 이름을 선호합니다. 제품 관리자(product manager)나 "애자일의 미래"에서 말한 제품 감독(product director)이라는 이름을 좋아합니다. (제품 관리자나 현장 고객팀에 대해서는 제임스 쇼어(James Shore)가 공저한 The Art of Agile Development에서 잘 설명하고 있습니다.)

그럼 만약 고객사 쪽에서 제품 관리자나 감독을 맡으려고 하지 않는다면? 이 때는 이 프로젝트의 성공 여부를 심히 의심해 보아야 합니다. 그 쪽에서 그럴만한 능력과 지식이 있는 사람을 찾아야 합니다. 그래도 안되면 가장 근접한 사람을 정하고 그 사람이 정보가 충분한 상황에서 결정할 수 있게(informed decision) 적극적으로 지원해줘야 합니다(그냥 책임지라고 떠 넘기는 것이 아니라). 마지막 수단으로 소프트웨어를 만드는 쪽에서 그 역할을 맡을 수도 있긴 합니다. 이 때 그 사람은 정치적 능력과 수완이 뛰어난 사람이어야 합니다. 쉽지는 않을 겁니다만 이름 뿐인 PO를 세워두는 것보다는 낫습니다.