Thoughts2011.09.14 09:55
소프트웨어 개발 방법론 중 가장 널리 쓰이고 있는 것은, 아마 아직도 폭포수(waterfall) 방법론일 것 같습니다. 요구사항 분석 - 설계 - 개발 - 검증으로 이어지는 이 단순한 방법론은 그 단순성과 명료함 때문에 '그다지 심각한 고민 없이도' 현업에 도입되어 쓰이고 있습니다. 

그런데 폭포수 방법론에는 대관절 무슨 문제점이 있길래 그토록 많은 비난의 대상이 되고 있는 걸까요?

이미 많은 증거들이 있어서 사실 제가 또 언급할 필요까지는 없는건데, 집으로 돌아오는 비행기 안에서 이런 저런 생각하다보니 이런 결론에 이르게 되더군요. '단순성'

폭포수 방법론은 사실 프로젝트 진행중에 벌어지는 다양한 상황을 처리하기에는 좀 지나치게 단순합니다. 일단 요구사항 분석이 끝났다고 치죠. 그러면 설계 단계가 진행되는데, 이 와중에 새로운 요구사항이 등장한다면? 제품을 개발하는 사람들이 어떻게 대응할 것이냐와는 별개로, 방법론 자체는 그런 상황을 처리하기에 그다지 걸맞지 않습니다. 사람들이 유연하게 대처하면 괜찮습니다만, 사실 그런 지경에 이르면 '방법론'이라고 부르기 껄끄러워지죠. 지키지 않는 방법론을 과연 방법론이라고 부를 수 있을까요?

사실 폭포수 방법론은 그 단순성을 커버하기 위해 굉장히 많은 문서들을 요구합니다. (아마 해 보신분들은 아실 듯.) 가능한한 모든 시나리오를 문서에 적어두고, 그 틀을 벗어나는 상황이 벌어지지 않기를 기대하죠. 유스케이스 문서에 장황하게 적혀있는 개발 시나리오는 그 중 한 예입니다. 하지만 예외 상황(exceptional case)이 한 가지만 새로 생기더라도, 유스케이스 문서는 고쳐져야 합니다. 유스케이스 문서의 양이 너무 많아서, 대체 어디를 고쳤는지 추적하기가 좀 난감하다는 점도 문제죠.

폭포수 방법론의 대척점에 서 있는 개발 방법론들은, 그래서 가능하면 프로젝트 개발의 각 단계를 '제어 가능한' 작은 단계들로 쪼개려고 합니다. 스프린트(sprint) 같은 것은 그 좋은 예로, 한두주 단위로 쪼개진 기간 안에 설계-개발-검증을 완료하고 또 그 다음 구간에 설계-개발-검증을 반복합니다. 각각의 구간이 굉장히 짧기 때문에, 그 구간이 진행되는 만큼은 불확실성(uncertainty)을 적절히 통제할 수 있습니다. 그 구간이 끝나야만 새롭게 등장한 요구사항들을 검토할 수 있죠. (애자일 개발 방법론도 그 중 한가지입니다.) 

그런데 단순히 하나의 방법론에서 다른 방법론으로 이행한다고 해서 크게 나아지지 않는 것이 있습니다. 그건 프로젝트에 참여하는 사람 사이에 발생하는 역학관계죠. 그런 역학관계때문에 발생하는 문제를 해결하려면, 누군가는 프로젝트에 참여하는 사람에게 긍정적인 영향을 끼칠 수 있도록 수직적 관리방식에 영향력을 행사하거나, 아니면 팀원들간의 소통방식을 개선해야 합니다. 

이 문제는 사실 개발 방법론의 한 부분일수도 있고 아닐 수도 있습니다만, 적어도 프로젝트의 성공을 위해서는 반드시 고려해야 하는 부분입니다. 방법론이 달라진다고 해서 프로젝트에 대한 압박이 사라지지는 않겠습니다만, 그런 스트레스에 대응하는 내적 능력은 달라질 수 있습니다. 프로젝트를 수행하는 데 필요한 방법론을 개선하는 데 있어서 가장 크게 고려해야 하는 부분은 그런 내적 능력을 증진시켜 팀원 모두가 적절한 수준의 항상성을 유지할 수 있도록 만드는 것이 되어야 할 겁니다.

보통 스트레스가 적절한 수준 이상으로 늘어나면 그런 항상성을 유지하는 것이 불가능하기 때문에, 결국 프로젝트를 성공으로 이끄는 것은 (적절한 능력을 가진 팀원들이 모여있다는 가정 하에서) 결국 스트레스를 어떻게 관리할 것이냐 하는 부분으로 귀결되는 일이 많죠.


스트레스를 관리하는 방식은 여러가지가 있겠습니다만, 최근까지 등장한 방법들은 대략

1. 업무 시간이 일정 시간 이상이 되지 않도록 하여 팀원들이 휴식할 수 있도록 하는 방법
2. 팀원들에게 프로젝트 결과후 성과에 대한 유무형의 보상을 제시하여 감내하도록 하는 방법
3. 팀원들의 의사소통 방식을 개선하여 업무와 관련한 스트레스를 줄이는 방법
4. 프로젝트 수행에 관계된 수직적 관리 오버헤드와 태스크 스위칭을 줄이는 방법
5. 프로젝트 진도와 성과를 정량적으로 추정할 수 있도록 하여 보고 오버헤드를 줄이는 방법


등등이 있겠습니다. 이 중 5는 4와 관련이 있고, 3은 1과 관련이 있습니다. 1이 되도록 하면 가장 좋겠지만, 프로젝트 말미에는 불가능한 경우가 많기 때문에 2가 반드시 있어야 합니다. 2를 흔히 우리는 비전(vision)이라고 부르는데, 비전 없는 프로젝트가 팀원의 이직을 초래하는 경우가 많기 때문에 주의해야 합니다.

비전을 제시할 때 주의해야 할 것은, 비전에 대한 착시효과입니다. 팀원들은 비전이 없다고 생각하는데, 관리자는 비전이 있다고 생각하는 경우가 그 한 예입니다. 관리자가 보는 비전과, 팀원들이 생각하는 비전은 굉장히 많이 차이가 날 수 있습니다. 따라서 2는 3과도 관련이 있습니다. 비전이 하나로 수렴되려면, 관리자와 팀원 간의 의사소통 방식이 개선될 필요가 있습니다. 비전은 이야기하지 않으면 알 수 없는 부분 중 하나이기 때문에, 관리자와 팀원은 서로를 설득하거나 비전에 대한 간격을 줄이기 위해 애쓸 필요가 있습니다.

비전을 제시하는 가장 좋은 방법은, '무엇이 어떻게 나아질 것인지'에 대한 정량화된 지표를 제시하는 것입니다. 아쉽게도, 사람들은 '심증'이라도 없으면 아무것도 믿지 않습니다. 프로젝트가 종료된 후 팀원들이 떠나는 것은, 아무도 그 부분을 어떻게 제시할 것인지 고민하지 않기 때문이기도 합니다.

그래서 떄로 프로젝트를 관리하는 것은 단순히 야근을 하지 않는 회사를 만드는 것 그 이상입니다. 성공적인 프로젝트 개발 방법론을 만들고 싶으신가요? 어쩌면 정말로 중요한 것은 그 너머 어딘가에 있을지 모릅니다. 방법론이 잘못되어 프로젝트가 실패하는 것이 아닌지 의심하고 계시다면, 여러분의 프로젝트가 팀원들에게 어떤 비전을 제시하고 있는지 자문해 보세요. 

세상에는 비전 하나만으로 야근을 견뎌낼 사람들이, 아직은 많으니까요


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

Thoughts2011.04.28 16:07
언더커버 보스라는 텔레비전 프로그램이 있습니다. 회사의 CEO (그러니까 보스죠)로 하여금 회사의 밑바닥 생활을 경험하게 하는 것이 골자인 프로그램이죠.



이 프로그램의 구성은 단순합니다. CEO를 변장시켜서 회사의 말단 직원으로 투입합니다. 그런 다음 한 일주일 동안 뺑이(?)를 치게 합니다. 이 과정을 통해 CEO는 회사를 지탱하는 말단 직원들의 고충과 비효율을 경험하죠. 그런 다음 다시 자기 자리로 돌아갑니다. 그리고 나서는 그들의 근무 환경과 효율을 개선할 새로운 아이디어나 제도를 내놓고, 자신에게 풍성한(?) 교훈을 안겨준 직원들에게 포상을 합니다. 그리고는 끝.

물론 이런 식의 프로그램이 갖는 문제점을 나열하라면 한도 끝도 없습니다. 포상을 받는 직원을 제외한 다른 직원들은, 그런 기회를 누릴 자격이 없었던 걸까요? 아마 아닐 겁니다. 그러니, 오늘은 그냥 리더쉽 이야기만 하도록 하죠.

언더커버 보스라는 프로그램이 나름대로 고정 시청자를 확보하면서 지속적으로 방영되고 있는 이유를 곱씹어보면 별게 없습니다. 그저 옛 성현의 말을 그대로 실천했을 뿐이죠.

"니가 한번 해봐라. 말만큼 쉽나."

겪어 보지 않으면 모른다

일반적인 관리자들이 빠지기 쉬운 함정 중 하나는, '위에서 보면 모든 것이 단순해 보인다'라는 점입니다. 그도 그럴 것이, 관리자들이 갖게 되는 지식의 대부분은 '보고 체계'를 통해 전달된 것들입니다. 보고라는 것은 보통 텍스트와 이미지로 구성된 문서입니다. 보고하는 사람에 의해 한 번 추상화(abstraction)된 결과물이죠.

관리자는 보통 이 추상화된 결과물들이 만들어 내는 다이어그램들의 연결관계로 문제를 파악합니다. 추상화의 핵심은 단순화(simplification)입니다. 단순하게 정리되지 않은 결과물을 보고하는 사람은 없습니다. 관리자는 보통 한번에 여러 직원들과 문제들을 상대하게 마련이고, 스스로 결과물을 분석할 시간적 여력이 없습니다. 그러니 관리자에게 보고되는 내용들은 가능한 한 단순화되어야 하고, 그 과정에서 문제의 세부사항은 생략되게 마련입니다.

어떻게 보고 해야 하나

세부사항이 생략될 경우에 발생하는 가장 큰 위험은 '관리자가 보는 일정 추정치'와 '직원들이 보는 일정 추정치'가 달라진다는 점입니다. 관리자들은 태스크 스위칭 오버헤드 같은 세부사항에 신경을 쓰지 않기 때문에 직원들에게 가능한 한 많은 일거리를 주려는 경향이 있고, 이런 일거리들이 어떻게 프로젝트를 지연시키는 지에 대해서는 신경을 쓰지 않습니다.

그런 상황에서 '참 또는 거짓' 그러니까 '무엇이 됐고 무엇이 실패했다'는 식으로 보고를 하게 되면, 일정 추정치를 정확하게 만들수가 없게 됩니다. 해결책은 문제를 둘러싼 상황적 맥락(context)을 기술하는 것이죠.

문제는 '상황적 맥락'이라는 것이 굉장히 모호하다는 겁니다. 여러분은 여러분이 처한 환경을 몇 줄 만으로, 가능한한 정확하게 묘사하려는 시도를 해 보신적이 있으십니까? 상황적 맥락은 텍스트로 추상화하기 가장 어려운 부분 중 하나입니다.

문제점 리스트가 왜 중요한가

상황적 맥락을 기술하기가 어렵다면, 프로젝트 진행 중간에 발생하는 이벤트들을 기록해 두는 것이 도움이 됩니다. 이런 이벤트들은 이슈 추적 시스템(issue tracking system)을 통해서 나열해 둘 수 있습니다. 이슈들의 발생 빈도, 이슈들의 양 등을 정확하게 기록해두면, 프로젝트 중간중간에 어떤 일들이 발생했고 그 일이 어떤 환경에서 발생했으며 어떤 맥락에서 처리되었는지 확인할 수 있습니다.

문제점 리스트가 갖는 가장 큰 장점은 '관리자들이 좋아하는 추상화된 형태'로 보여주기 좋다는 점이죠. 개수, 양, 그래프 등등 고도로 추상화된 수단을 동원해 시각화하기 편하다는 거에요.말로 설명하면 납득하지 못하는 사람도, 제대로 정리된 그래프를 보여주면서 이야기하면 프로젝트 중간에 발생한 불확실성의 수준을 이해하는 경향이 있으니까요.


위의 사진에서처럼 '실제로 겪어본다는 것'에는 영감을 불러 일으키는 마력이 있습니다. 지금 관리자인 사람들도 과거에는 말단 직원이었을 거에요. '경험'이라는 것에는 마력같은 부분이 있죠. 보통 관리자들이 갖고 있는 '과거의 기억'은 윤색되기 마련입니다. '과거에 나는 이랬어!' 뭐 이런 자부심 같은 것들이죠.

문제는 그런 자부심이 나쁘다는 것이 아니라, 그런 자부심이 때로 프로젝트 진행 당사자가 겪는 문제들을 올바르게 파악하지 못하도록 방해한다는 점입니다.

언더커버 보스의 CEO들도 회사의 발전을 위해 고군분투하고 있다는 점에서는 다른 직원들과 다를 바가 없는 사람들입니다. 다만 그들에게 주어지는 정보의 양이 제한적이다 보니, 프로젝트 진도와 방향에 대해, 더 나아가서는 회사의 발전 방향에 대해 '오해'를 할 수 있다는 것이 문제일 뿐이죠.

관리자들이 여러분 주변의 문제를 더 자주 파악할 수 있도록, 눈에 잘 띄는 곳에 문제점 리스트를 두세요. 그리고 그 문제점 리스트가 왁자지껄해지도록 만드세요. 할 수 있다면, 익명 게시판 같은 형태도 나쁘진 않을 겁니다. (많은 사람들이 선호하는 방법은 아니지만요.) 그럼 아마 관리자들은 여러분들이 무슨 생각을 하고 있는지, 현장에서 무슨 일들이 벌어지고 있는지 더 잘 파악할 수 있을겁니다.

물론 어떤 관리자들은 그런 정보를 봐도 '그건 네가 잘 몰라서 그래'라고 말할지 모릅니다. 하지만 그런 상황에 처하더라도, 어떤 의미에서건 '문제를 노출한다는 것'은 좋은 거에요.

한두번이면 모르겠지만, 잽도 여러번 때리다 보면 결정적 한방이 될 수 있거든요.





신고
Posted by 이병준

소중한 의견, 감사합니다. ^^

  1. 잘보고 갑니다

    2011.04.28 16:17 신고 [ ADDR : EDIT/ DEL : REPLY ]