Extremely Agile/General2008.09.24 11:49

불확실성(Uncertainty) : 장래 일어날 수 있는 사상()에 관해서 인간이 가진 정보의 정확성에 대한 하나의 구분. (출처 : 네이버 백과사전)

네이버 백과사전에 나온 불확실성의 정의에 따르면, 의사결정자가 가지고 있는 정보의 정확성은 ㉠ 확실성, ㉡ 리스크(risk), ㉢ 불확실성, ㉣ 무지()의 4종류로 분류할 수 있다고 합니다. 관련 부분을 인용해보죠.

㉠의 확실성은 무엇이 일어날지 확정적으로 알고 있는 경우를 말한다. ㉡의 리스크는 무엇이 일어날지 확정적으로는 알 수 없으나, 일어날 수 있는 상태는 알고 있고, 또 그 확률분포()도 알고 있는 경우를 말한다. 이에 대하여 ㉢의 불확실성은 일어날 수 있는 상태는 알고 있으나, 그 확률분포를 알지 못하는 경우를 말한다. ㉣의 무지란 무엇이 일어날지, 어떠한 상태가 일어날지, 전혀 예견할 수 없는 경우를 말한다. 한편, 넓은 뜻의 불확실성이란 ㉡의 리스크와 ㉢의 불확실성의 양자를 가리킨다.

이런 개념을 최초로 정립한 사람들은 경제학자들입니다. 돈이 걸리면 어떻게든 위험성을 줄이는 것이 좋으니까, 당연하겠죠. 소프트웨어 프로젝트에도 돈이 걸려 있기 때문에, 무슨 방법을 쓰던 위험성을 줄이면 줄일수록 이득입니다.

하지만 '확실성'이 갖는 정의 - 무엇이 일어날 지 확정적으로 알고 있는 경우 - 에 비추어보면, 확실성이란 달성이 불가능한 꿈과 같습니다. 확실성을 성취하려면 타임머신을 발명하던가 해야 합니다. '아무 일도 하지 않으면 되지 않느냐?'고 물으실 분도 계실 것 같은데, 아무 일도 하지 않으면 그 순간부터 유보수익이 사라지고, 기회비용 문제가 발생하기 시작합니다.

하지만 '불확실성'에 대한 '확실한 사실'이 한가지 있긴 합니다. 우리가 알고자 하는 것이 미래의 특정 시점에 일어날 사건에 대한 불확실성의 정도라고  한다면, 이 불확실성은 그 시점에 가까이 가면 갈수록 감소하는 경향을 보인다는 것이죠. 가령 우리 아기가 몇개월때 첫 걸음마를 뗄 것인지를 알고 싶다고 해 봅시다. 그리고 18개월쯤에는 첫걸음마를 뗄 것으로 예상한다고 해 봅시다. 이 예상이 갖는 불확실성은 시간이 흘러 18개월 근처로 가면 갈수록 감소합니다. 17개월이 되었는데도 엎드려 고개를 드는 것이 고작이라고 한다면? 아마 18개월에 첫 걸음마를 떼기는 힘들어지겠죠. 예상이 맞건 틀리건, 불확실성은 이런 식으로 감소 추세를 보이기 시작합니다. (물론 아이가 예상하지 못한 병에 걸린다거나 하는 불행한 일이 생기면 불확실성이 급상승하는 일도 생길 수 있긴 하겠습니다.)

불확실성이 갖는 이러한 속성과, 확실성, 위험, 지식이 갖는 속성들을 종합해 보면, 우리는 분명해 보이는 몇 가지 결론에 이르게 됩니다.

1. 시간이 흐르면 불확실성은 차츰 감소한다.
2. 지식이 늘어나면 불확실성은 차츰 감소한다.

이 지식에는 '확률적 지식'도 포함됩니다. 시간이 흐르면 사람들은 '어떤 사실'의 '발생 가능성'에 대한 지식을 자연스럽게 취득하게 됩니다. 확률적 지식이 100% 정확하다고는 볼 수 없습니다만, 적어도 한 잣대는 되어줄 수 있기 때문에, 불확실성은 그에 따라 차츰 감소하게 됩니다.

이런 불확실성의 개념이 소프트웨어 개발 프로젝트 관리 방법론의 한 근간으로 등장한 것은 사실 오래된 일입니다. 1981년 베리 뵘은 이후 스티브 멕코넬이 '불확실성 원추(Cone of Uncertainty)'라고 부르게 되는 그래프를 하나 그렸는데, 이것이 시발이라고 봐도 무방할 것 같습니다. 이 그래프가 보여주는 것은 사실 위에 제시했던 두 가지 뻔한 결론에 다름 아닙니다. 하지만 전통적인 개발 방법론이 이 자명한 사실을 인정하게 되는 데는 약간의 시간이 필요했죠. 애자일 선언문이 발표된 것이 2001년도이니까, 그 사람들이 지금은 '애자일'이라고 불리는 방법론을 가다듬는 데 필요했을 10년 정도의 세월을 감안하면, 불확실성이 화두로 등장하는 데는 10년 정도의 시간이 필요했다고 봐도 될 것 같네요.

그럼  불확실성이 프로젝트 관리에 있어서 가장 중요한 문제중 하나로 등장한 이유는 뭘까요? 아마 다 아시겠지만, 그것은 초기 계획대로 굴러가는 프로젝트가 별로 없기 때문이며, 초기 설계대로 우아하게 마무리되는 프로그램이 별로 없기 때문이고, 그런 일이 빈번하게 생기면 프로젝트 팀원들의 '꼭지가 돌아버리기' 때문입니다. 그리고 그런 프로젝트는 고객에게 '최선의 가치를 전달'하기가 점점 더 어려워지죠. 전통적인 방법론들은 프로젝트 도중에도 불쑥 뿔쑥 등장하곤 하는 이런 '꼭지도는 일들'을 어떻게 처리해야 하는지에 대해서는 별 이야기가 없습니다.

이쯤에서 이미 식상해졌을 지도 모를 애자일 이야기를 조금만 더 하자면... 애자일 방법론은 사실 불확실성에 관한 방법론입니다. 흔한 오해중에 한가지는 '애자일 방법론은 고객 중심 방법론이다'라는 것인데, 사실 이 이야기는 반 정도는 맞고 반 정도는 틀립니다. 사용자를 무조건 만족시키는 것이 애자일 방법론의 목표는 아니기 때문이죠. 고객이 중요한 것은, 사용자가 프로젝트의 성패에 관련된 가장 중요한 이해 당사자 중 하나이기 때문입니다. 고객을 중요하게 생각하는 것은, 그들과 어떻게 의사소통하느냐에 따라 프로젝트의 불확실성 정도가 굉장히 많이 달라질 수 있기 때문입니다.

흔히 보는 장면
A : 이번 프로젝트의 요구사항 명세표를 분석해야 하는데요.
B : 누가 작성한 명세표죠?
C : 영업팀에서 작성한 겁니다.
D : 그거 영업 팀에서 분석해야 하는거 아닌가?
A : 이전 프로젝트 결과를 토대로 우리가 추가해줬음 하는 것도 있어서요.
B : 그런걸 요구사항이라고 부를 수 있나요?
A : 엇비슷한 프로젝트니까 일단은 그렇게 하고 프로젝트를 진행해달라는 게 '영업팀의' 요구사항이죠.
B : 왜?
C : 받아온 프로젝트 기간이 좀 빡빡해서요.
(2달 후)
A : 우리가 구현한 기능들 중 한 열개 항목 정도가 잘못되었다는 군요.
B : 누가 그래?
A : 고객이요.

보통 개발자들이 고객을 미워하는 이유는 개발자들이 보기에 고객이란 사람들이 '뭘 잘 모르는 사람들'처럼 보이기 때문도 있습니다만, 가장 큰 이유는 프로젝트 진행 중에 요구사항을 변경하는 사람들이 대부분 고객이기 때문입니다. 그런 일이 자주 생기면, 개발자들의 인생은 급속도로 피폐해집니다.

그런데 사실 그건 고객 잘못은 아니에요. 위의 '흔히 보는 장면' (진짜로 이런 일이 흔하면 큰일나겠습니다만 ㅋㅋ)에서도 느끼실 수 있겠지만, 애초에 프로젝트를 진행하는 팀이 고객과 의사소통을 할 기회가 없었다는 것이 가장 큰 문제죠. 자뻑용 프로젝트를 한다면야 모르곘지만, 개발팀을 고객과 떼놓고 프로젝트를 하면 득보다는 실이 더 많아질 수도 있습니다. 고객/사용자는 종종 시장 그 자체이며, 시장의 변화를 외면하면서 시장에 '최선의 가치를 전달할' 방법 같은 것은 없습니다. 시장의 변화라는 것은 곧 '불확실성'이기 때문에, 우리는 어떻게든 불확실성을 끌어안을 방법을 찾아내야 합니다.

애자일 방법론이 의사소통의 문제를 가끔 비 이성적으로 보일 때 까지 깊이 탐구하는 것은 아마 그래서 일 겁니다. 애자일 방법론은 구두로 나눈 대화와, 그 자리에서 합의된 사항을 '개발 계획서'보다 더 중시하는 경향이 있습니다. (이 점이 전통적인 방법론을 옹호하는 사람들의 심기를 굉장히 불편하게 만들곤 합니다만...) 이건 제 개인적인 경험입니다만, 지식을 늘리는 가장 간단한 방법른 사실 구글 검색도 아니고 독서도 아닙니다. '대화'죠. 대화가 확대할 수 있는 지식의 영역은 특별히 어딘가로 제한되지 않습니다. 하지만 프로젝트 진행에 있어 가장 도움되는 부분은 다음의 몇 가지 일 것 같군요. (무순)

1. 프로젝트 자체에 대한 지식
2. 팀원에 대한 지식
3. 고객/사용자에 대한 지식

앞서도 언급했었습니다만, 지식이 증가하면 불확실성은 감소합니다. 지식을 늘리는 방법으로 스파이크(spike) 같은 것도 있습니다만, 아무래도 고수와의 커피타임만큼 짧고 효율적이진 않습니다. 요구사항 변화에서 오는 야근을 줄이는 방법으로 '무조건적인 퇴근시간 준수'같은 것도 있겠습니다만, 아무래도 요구사항을 낸 이해 당사자와의 전화통화만큼 효과적이지는 못합니다.

의사소통을 자주 그리고 효율적으로 하게 되면 프로젝트 중반에 발생하는 이런 저런 일들에 보다 능동적으로 대처할 수 있게 됩니다. 그리고 팀이 지금 어디쯤 와 있는지 좀 더 분명히 알 수 있게 되고, 앞으로 발생할 지 모를 '꼭지도는' 일들이 팀의 항로를 어떻게 바꾸어 놓게 될지 좀 더 명료하게 알 수 있게 됩니다.

의사소통을 강조하는 것이 자기 파티션 안에 처박혀 있기를 좋아하는 개발자들의 습성과 배치되긴 합니다만, 그런 개발자의 모습은 개발이라는 것을 종종 예술(art)과 비슷한 것으로 묘사하는 너드(nerd) 문화의 클리셰일 가능성이 높습니다. 개발자들은 프로그래밍이 오타쿠들이 좋아하는 저패니메이션같은 것과는 질적으로 다르다는 사실을 깨달을 필요가 있어요. 개발은 현실이고, 현실은 가혹합니다. 개발자들이 의사소통을 무시하고 파티션 안에 처박혀 있으려는 습성은 어찌보면 개발자들이 처한 현실이 주는 문제를 계속해서 재생산하는 측면이 있습니다. 그냥 그 안에 처박혀서 '사용자들은 아무것도 몰라'라고 해서는 인간다운 생활을 영위할 수 없다는 것이 문제라는 거죠. 불확실성을 감소시키지 않으면, 야근 일수는 줄어들지 않는다, 뭐 그런 이야기죠.

하지만 굳이 불확실성 이야기의 외연을 개발자 각각의 삶으로 넓혀놓지 않더라도, 불확실성을 감소시키는 것은 중요합니다. 소프트웨어 프로젝트의 목표가 '고객에게 최선의 가치를 전달'하는 것이라고 보면, '최선의 가치'라는 것의 정의는 시간이 지나면 어떻게든 변화하게 될 처지이니 (시장 상황은 자고 일어나면 바뀌죠) 불확실성이라는 것이 존재한다는 사실을 인정하고 그것과 '화해할 수 있는' 전략을 수립하도록 애쓰는 것이 프로젝트를 관리하는 사람이 해야 하는 일이 아닐까요?


신고
Posted by 이병준

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

Extremely Agile/General2008.01.22 05:55

SW 프로젝트는 일입니다. 모든 일이 다 그렇듯, 시간이 지나면 남은 일의 양은 차츰 감소하게 마련입니다. 하지만 대부분의 SW 프로젝트의 경우, 그렇지 않을 떄도 많습니다. 가장 흔한 것은, 마감 시간에 맞추어 밤을 새우는 일입니다. 일의 총량은 정해져 있을 터인데, 왜 프로젝트가 끝나갈 무렵까지 일의 양은 전혀 줄어들지 않고, 결국에는 철야를 하게 되는 것일까요?

애자일 방법론을 만든 사람들은 이 문제를 깊이 있게 연구했습니다. 그리고 그 결과, 이런 결론을 얻습니다.

일은 빵과 같다. 빵을 먹으면, 빵은 줄어든다. 일도 마찬가지이다. 일을 하면, 남은 일의 크기는 점점 작아진다. 하지만 '내가 먹으려는 이 빵이 정말로 내가 먹고 싶었던 빵인지' 한 입 베어물어 보기 전에는 정확하게 알 수 없는 것과 마찬가지로, 고객에게 소프트웨어를 인도하기 전까지는 누구도 그것이 정말로 고객이 원했던 그것인지 확신할 수가 없다.

고객이 원하지 않는 기능을 구현하게 되면, 그 기능을 구현하는 데 투자했던 시간들이 고스란히 오버헤드가 되고, 결국 고객이 정말로 원하는 기능을 구현하기 위해 프로젝트 후반부에 날밤을 새우게 됩니다. 이런 문제에 대해서는 마이크 콘(Mike Cohn)을 비롯한 여러 사람들이 많은 연구를 했고, 좋은 책도 많이 있습니다. Agile Estimating and Planning은 그 중 하나입니다.

하지만 오늘은 그 보다는 좀 더 개인적인 이야기를 해 볼까 합니다. 개인적인 견지에서 보면, 프로젝트 막바지에 더 바쁜 가장 결정적인 이유는, 프로젝트 중간 중간에 박혀있는 마일스톤 점검 시점에 반드시 해야 할 몇 가지 일들을 하지 않고 넘어갔기 때문입니다.

마일스톤 점검시에, 제가 속한 팀은 주로 그 때 까지 개발한 소프트웨어의 큰 틀이 정상동작하는지를 점검합니다. 속칭 '연동시험'을 하는 것이죠. 이 연동시험은 개발에 참여하는 여러 업체와 개발자들로 하여금 '다른 사람의 관점에서' 시스템을 바라볼 수 있도록 해 주기 때문에 굉장히 중요합니다. 그 과정에서 '개발에는 별로 적합하지 않은' 업체나 개발자가 가려지기도 하죠. ('다른 사람의 입장을 전혀 고려하지 않는 개발자'는 그 한 예가 되겠습니다. 이런 개발자일수록 '개발자의 자질'에 대해 더 많이 이야기하곤 한다는 것은 아이러니 한 일이죠. 좋은 코더가 되는 것도 중요하지만, 사실 더 중요한 것은 존중의 자세입니다.)

그런데 이 마일스톤 점검시에는 보통 자질구레한 사항이나 버그들에 신경을 쓰기 보다는, 서로 다른 사람들이 만든 시스템이 별 탈 없이 연동되어 돌아가는지를 살펴보는데 집중하는 일이 많습니다. 자잘한 문제들은 TO-DO 리스트에 적어놓는 것으로 점검을 마무리 짓곤 하죠.

문제는 그렇게 만들어진 TO-DO 리스트를 나중에는 아무도 거들떠보지 않는다는 사실입니다. 그러다보니, 데드라인이 다가오면 최종 연동시험과 병행해서 '자질구레한' 버그들도 함께 잡아 나가야 하는 일이 벌어지게 되고, 결국은 잠을 줄이게 되는 것이죠.

'엉뚱한 기능'을 구현하는 것도 위험천만한 일이지만, 진짜 '일'을 남겨두는 것도 위험천만하기는 마찬가지라는 거에요. 그런데 이런 실수를 되풀이하게 되는 이유는 대체 뭘까요?

가장 큰 이유는, 그런 '뒷마무리 작업'이 대체로 재미가 없기 때문입니다. 뭔가 그럴듯한 새 기능을 시스템에 추가하는 건 재미있습니다만, 그 부산물들을 치우는 것은 사실 지루한 일이죠. 물론, 그런 뒷마무리 작업을 충실히 할 만큼 넉넉한 시간이 주어지지 않는 경우도 있습니다. 자고 일어나면 세상은 달라져 있고 또 뭔가 새로운 요구사항은 생겨나게 마련이니까요.


PS.

이 글은 새벽 네시쯤 쓴 것 같군요.
저도 날밤을 새고 있었다는 이야기죠. ㅋㄷ



 

신고
Posted by 이병준

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

  1. SW개발은 아니지만 나름 개발일을 하고 있는 완전공감이에요 ;ㅁ;
    내일까지 프로젝트마감을 맞추기위해 1주일전부터 완전철야중. 하루에 2~3시간밖에 못자는것 같아요 ;ㅁ;
    지금도 밤샘중 흑흑흑;;;
    왜 마지막날이 되면 온갖 수정사항들이 나오는건지 TO DO LIST가 줄질않네요.
    한개 지우면 2~3개 추가되고. orz

    2008.01.22 06:27 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그러게요. 이런 문제를 극복해 나가는 현명한 방법을 찾는 것이 개발자들이 해야 할 일이겠죠. 개인적으로는 TO-DO LIST를 관리하는 것 보다는, TO-DO BOARD(해야할 일 게시판)을 만들어 모두가 볼 수 있는 자리에 배치하는 것도 한 방법이 되지 않을까 생각하고 있습니다. 그러면 시간이 지날수록 그 게시판에 나열된 개선 항목들이 줄어드는 모습을 볼 수 있어서 좋을 거라고 생각해요. 어쩐지 '사용자 스토리'의 동어반복같다는 생각도 드는군요. 덧글 감사합니다.

      2008.01.22 06:44 신고 [ ADDR : EDIT/ DEL ]
  2. 개발자만 공감하는 얘기는 아니랍니다 ;ㅁ;
    기획자도 똑같은 짓(?)을 하고 있다죠

    제 시간관리 능력을 탓해야 겠지요 쩝

    2008.01.22 07:47 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 기획자도 개발팀의 일원이니 개발자라고 보는 것이 좋겠죠. 시간관리라는 문제를 개인 차원의 문제로 접근하면 전반적인 상황은 크게 개선되지 않을 수도 있다고 생각합니다. 가급적 팀 단위의 해결책을 찾는 것이 좋겠죠.

      2008.01.22 09:25 신고 [ ADDR : EDIT/ DEL ]
  3. 아직 프로젝트에 대한 경험이 없어서 선배분들의 얘기가 마냥 멀리 느껴집니다.OTL.....
    하지만 토이박스를 몇 번 만들어본터라 막바지에 자질구레한 일 때문에 지겹고 바빠진다는 것을 매번 느꼈습니다.;;ㅜㅜ

    2008.01.22 08:54 신고 [ ADDR : EDIT/ DEL : REPLY ]
    • 그런 일들이 쌓이고 쌓이면 결국 개발이라는 것이 막판에는 재미없는 일이 되어버리겠죠.

      2008.01.22 09:26 신고 [ ADDR : EDIT/ DEL ]
  4. 저는 프로그램 개발과는 완전 거리가 먼....출판 편집을 하고 있지만 와닿네요. ㅡㅡ;;

    2008.01.22 22:19 신고 [ ADDR : EDIT/ DEL : REPLY ]
  5. ㅡㅡ;

    [펌] 해가겠습니다. ^^; 당연히 펌한 url 과 명시는 꼭 하겠습니다. ^^;
    감사합니다. 펌한 사이트 : http://cafe.daum.net/aspdotnet

    2008.02.13 00:36 신고 [ ADDR : EDIT/ DEL : REPLY ]

Extremely Agile/General2007.11.12 01:44
'프로그래밍의 도' (Tao of Programming)라는 유명한 농담이 있습니다. 꽤 재미있는 농담입니다만, 저는 이 농담이 두 가지 측면에서 좋지 않다고 생각합니다. 프로그래머라는 사람들은 조직의 가치에 융화되기 어려운 사람들이라는 잘못된 생각을 전파시킬 수 있다는 점에서 그렇고, 이 농담에서 묘사하는 '도를 깨친 프로그래머'가 실제 프로그래머의 모습과 상당히 거리가 있기 때문에 더 그렇습니다.

제자(第子)가 스승에게 묻기를: "저 프로그래머는 설계(設計)도 않고, 문서(文書) 작성(作成)도 않으며 자기(自己) 프로그램을 테스트해 보지도 않습니다. 하지만 모두 그를 세계(世界)에서 가장 뛰어난 프로그래머라고 칭송(稱頌)합니다. 그 이유(理由)가 무엇입니까?"

가령, 위와 같은 문장이 그 예입니다. '테스트를 하지 않는 프로그래머'가 세계에서 가장 뛰어난 프로그래머라니요? 모든 좋은 프로그램들은 오히려 '뛰어난 테스트'로부터 만들어집니다. 테스트를 하지 않고서도 돌아갈 수 있는 프로그램을 만드는 프로그래머가 되고 싶은 마음은 이해하지만, 현실적으로는 불가능합니다.

도사(道士) 프로그래머 가라사대:
"프로그램을 테스트하고 있을 때는
설계(設計)를 변경(變更)하기엔 이미 늦은 다음이니라."

위의 문장은 부분적으로는 맞고, 부분적으로는 맞지 않습니다. 위의 명제가 맞으려면, 프로젝트가 거의 폭포수 형태로 진행되어야 하고, 설계는 프로젝트 초기에 모두 이루어져야 합니다. 하지만 프로젝트를 애자일 적으로 진행하는 경우에는 테스트를 통해 설계의 얼개가 드러나기도 합니다. 설계는 프로젝트 전반에 걸쳐 조금씩 진행되며, 결과적으로 테스트 시점에 떠안게 되는 오버헤드도 굉장히 낮아집니다. 그럼 저 명제를 제시한 '도사 프로그래머'는 정말로 도사일까요? (저는 아니라고 생각합니다.)

많은 해가 지나 관리자는 은퇴(隱退)하게 되었다. 은퇴식장에 가던 도중 그는 프로그래머가 터미날 앞에서 잠들어 있는 것을 보게 되었다. 그는 어제 밤을 새가며 프로그래밍을 했던 것이다.

위와 같은 문장은 프로그래머가 굉장히 무책임한 부류의 사람들이라는 인상을 줍니다만 (물론 원래 의도는 그렇지 않을 거라고 생각합니다만) 그것도 역시 사실이 아닙니다. 이렇게 사실이 아닌 문장이 농담을 빌어 나열된 것은, 아마도 다음과 같은 이유 때문일 겁니다. 역시 '프로그래밍의 도'에서 인용했습니다.

프로그래머는 왜 생산성(生産性)이 낮은가?
그들의 시간이 회의로 낭비(浪費)되기 때문이다.
프로그래머가 왜 툴툴거리는가?
관리자가 지나치게 참견하기 때문이다.
프로그래머가 왜 하나씩 회사를 떠나는가?
지쳤기 때문이다.
무능력(無能力)한 관리자 밑에서 일하는 프로그래머는 자신의 직업(職業)을 소중히 여기지 않는다.

위에 나열된 문제들은 계획(planning)을 프로젝트 전반기에 어떻게든 마무리하고 그렇게 해서 만들어진 프로젝트를 고수하려고만 하는 프로젝트 팀에서 빈번히 발견됩니다. 전반기의 회의 시간에 상당수의 프로그래머들은 졸거나 다른 일을 하고, 막상 개발에 들어가고 나면 관리자들이 요구사항을 지나치게 변경해 댄다고 툴툴거리게 됩니다. 그러다보면 정작 테스트는 프로젝트 막바지에 몰아서 하게 되고, 그 단계에 오류를 발견하게 된다고 하더라도 설계를 쉽게 변경할 수 없게 됩니다. 그러다보면 프로그래머들은 결국 지쳐서 하나둘씩 회사를 떠나게 되지요. 결국 관리자들은 '프로그래머들이란 책임감이라고는 눈꼽만치도 없는 인간들이야...'라는 식으로 생각하게 될 겁니다.

그러니, 위에서 언급한 '테스트를 하지 않는 프로그래머', 즉 도를 깨친 프로그래머는, 프로그래머가 당면한 여러가지 현실적 문제들을 논리적으로 거꾸로 뒤집어 만들어낸 캐릭터인 셈입니다. 현실과는 완전히 반대이며, 그렇기 때문에 또 정말로 바람직한 프로그래머의 상 과는 '현실적으로' 거리가 있는, 그런 캐릭터가 만들어진 것이죠.

그렇다면 저는 '프로그래밍의 도를 깨친 프로그래머는 애자일적인 프로그래머이다'라는 주장을 하고 싶은 걸까요? 사실 그건 아닙니다. '프로그래밍의 도'라는 이 농담이 폭포수적인 개발 관행의 부조리함에 대한 반감에서 나오긴 했습니다만, 그렇다고 애자일적인 프로그래밍을 하는 사람이 자동적으로 도를 깨친 프로그래머가 되는 건 아닙니다. 사실 '프로그래밍의 도'라는 이 농담에는 꽤 들어둘만한 구절도 몇 군데 있는데, 이런 구절들이 사실상 프로그래밍의 도란 무엇인가를 어느정도는 암시한다고 생각합니다. 결국 프로그래밍의 도라는 것은 특정한 방법론에 귀속되는 것은 아닌 셈이죠.

관리자는 보너스를 주려고 하였지만, 프로그래머는 거절(拒絶)하였다. 프로그래머 가로되. "나는 이 프로그램이 재미있다고 생각했기 때문에 작했을 뿐입니다. 따라서 나는 아무런 보상도 바라지 않습니다."
이 말을 들은 관리자가 말하기를, "이 프로그래머는, 비록 비천(卑賤)한 자리에 있으나, 종업원의 맡은 바 책무(責務)가 무엇인지 잘 알고 있다. 그를 보조 관리자로 승진시키도록 하자!"
그러나 이 말을 들은 프로그래머는 다시 한 번 거절하였다."나는 프로그램을 짤 수 있기 때문에 존재합니다. 만일 승진한다면 다른 사람의 시간을 갉아먹게 될 뿐입니다. 이제 가도 됩니까? 지금 짜고 있는 프로그램이 하나 있거든요."


이 글을 읽는 여러분은 프로그래밍의 도에 대해 어떤 생각을 가지고 계실지 궁금하군요.
 

신고
Posted by 이병준

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

Extremely Agile/General2007.11.05 10:55
애자일 개발자들이 어떤 형태의 자리에 앉아서 일을 하도록 해야 하느냐, 하는 데 있어서는 별로 이견이 없는 편입니다. Extreme Programming의 사례를 보아도 그렇습니다만, '적극적인 협업이 가능한 형태면 좋다'의 정도인 것 같습니다. 애자일 원칙들이 대개 그렇습니다만, 정형화된 '규칙(regulation)'이 있는 건 아닙니다.

보통 프로그래머들은 협업의 문제를 컴포넌트 인터페이스 레벨에서 사고하는 경향이 있습니다. 너는 네 일을 하고, 나는 내 일을 하는데, 그 두 일이 인터페이스 레벨에서 잘 연동이 되면 만사 OK다 라는 것이죠. 물론 그렇게만 되면 프로젝트 관점에서야 만사 OK일 수도 있겠습니다만(아닐 수도 있습니다) 문제는 그런 식의 관점이 생산성 측면에서 어떠한 이득도 가져다 주지 못한다는 데 있습니다. 생산성을 극대화시키는 것이 목적이라면, 내 일/네 일 관계를 넘어서는 좀 더 기민한 형태의 의사소통이 필요합니다.

개인적인 경험에 따르면, 이러한 의사소통이 극도로 잘 이루어지는 경우에는 (설사 그 의사소통 형태가 그다지 애자일 적이 아니라고 하더라도) 프로그래머들을 개발 완료 시한 한달을 남겨놓고 소집해서 개발을 시작하더라도 완결된 프로그램을 내 놓을 수가 있었습니다. 물론, 그 중 한 사람은 '프로젝트의 성격과 범위, 그리고 관련 기술에 극도로 능통한 사람이어야 합니다. 모든 의사 소통은 그 '달인'을 통해서 이루어져야 하고, 모든 프로그래머들은 그 한 사람과 자신의 일에 대해서 의논을 해야 합니다.

신적인 의사 소통 모델

신적인 의사 소통 모델


이런 식의 의사소통 모델에서는 자리 배치는 그다지 중요하지 않습니다. 모든 사람이 (극단적으로 보자면) 딱 한 사람과 자신의 업무에 대해서 이야기를 하면 되니까요. 다른 사람들과 의사소통을 해야 하는 문제는 '달인' 혼자서 다 처리했습니다. 인터페이스 중재부터 시작해서, 개발 범위의 조정 등등... 각각의 개발자들은 중간의 '달인'이 내린 지침에 따라 개발하되, 자신이 담당한 모듈에 대한 클라이언트 인터페이스는 자신이 개발해서 다른 사람들에게 배포하기만 하면 되었습니다.

하지만 이런 '신적인 의사소통 모델'(중간에 마치 신과도 같은 개발자 한 사람이 떡 버티고 있는 모델)은 쉽게 찾아볼 수 있는 형태는 아닙니다. 이런 신적인 의사소통 모델이 널리 통용될 수 없는 이유는 몇 가지 있습니다.

(1) 달인이 드물다
(2) 아무도 달인의 자리에 오려고 하지 않는다.

물론 가장 큰 문제는, 저런 역할을 담당해 줄 달인이 실질적으로는 거의 없다는 점입니다. 그 정도의 권위와 카리스마를 갖춘 사람과 같이 일을 할 수 있다면 정말로 영광이겠습니다만, 그런 드문 기회는 그야말로 드물기 때문에 문제가 됩니다. 설사 그런 사람을 찾을 수 있다고 하더라도, 나중에 프로젝트가 실패하게 되면 그 사람 혼자서 '독박'을 써야 하는데, 아무리 달인이라고 하더라도 그렇게 하려고 할까요?

그렇다면 실제상황에서 써먹을 만한 기민한 형태의 의사소통은 어떻게 해야 가능해지는 걸까요? 어떻게 근무환경을 조성해야 그런 형태의 의사소통이 가능해지는 것일까요?


위의 동영상은 Daum의 제주 GMC 센터의 동영상입니다. 스마트플레이스에 올라왔길래, 참고삼아 링크를 걸어보았습니다. 다른 부분은 논외로 하고, 자리 배치만 한번 눈여겨 보시죠. 팀 내에 있는 모든 사람들이 원형으로 배치되어 등을 지고 일을 하고 있습니다. 뭔가 의논해야 할 일이 생긴다면, 바로 의자를 돌려 관련된 사람들끼리 이야기를 할 수 있는, 그런 구조입니다. 중단기적인 프로젝트를 밀어부치기에는 좋은 구조입니다.

하지만 이런 구조는 "모든 프로그래머는 자신만의 공간을 원하게 마련이다"라는 통상적인 믿음과는 좀 거리가 있습니다. 옆 사람 타이핑 소리까지 다 들릴 정도로 가까운데다, 머리를 조금만 돌리면 옆 사람 모니터까지 다 보이거든요. 물론 Pair Programming을 진행하기에는 아주 이상적인 조건이긴 합니다. 하지만 이런 구조에서 일하는 사람들은 '자신만의 무언가'를 원하게 되는 순간 근무 환경을 떠나야 해요. 근무 환경을 나서면 그 밖에는 근무와는 별 상관이 없는 이질적인 공간이 기다리고 있는데, 사람에 따라서는 그런 이질적인 환경이 사색에 오히려 방해가 될 수도 있습니다.

그러니 저는 자신만의 공간과 협업을 위한 공간 사이에 어느정도의 논리적/물리적인 구분이 존재하는 것이 바람직하지 않겠는가, 하는 생각이 들어요. 자신의 자리에서 일하다가, 협업이 필요할 때 협업을 위한 공간으로 들어가는. 뭐 그런 구조 말이죠. 다만 그 두 공간을 왔다갔다 하는게 그다지 어렵지는 않아야 합니다.

그런 구조에 대해서는 http://www.talk-with-hani.com/archives/660를 참고해 보시는 것이 좋겠습니다. 다만 관리자 입장에서 보면 모든 개발자들에게 이런 공간을 마련해 줄 만큼 돈이 없다는 게 문제가 될 수도 있겠죠. 또 다른 구체적인 사례도 있는데, http://blog.naver.com/yuzico/130007299724 를 참고하세요. 스토리 카드 보드 등등을 망라하는 재미있는 사례들을 많이 보실 수 있습니다. 자리 배치에 대해서는 그다지 상세히 언급하고 있지는 않습니다.




신고
Posted by 이병준

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

  1. 비밀댓글입니다

    2007.11.05 20:30 [ ADDR : EDIT/ DEL : REPLY ]
  2. elipsis

    잘 읽었습니다. :-)

    2007.11.06 15:14 신고 [ ADDR : EDIT/ DEL : REPLY ]

제 주변엔 게으른 사람들이 좀 있습니다. 유유상종이라고, 저부터도 굉장히 게으른 편입니다. 스스로 프로그래머를 자처하고 있으니, 저는 '게으른 프로그래머'입니다.

흔히 프로그래밍에 있어서 게으름은 '창조의 어머니'에 비유되고는 합니다. 프로그래밍은 복잡한 문제를 단순하게, 그것도 컴퓨터의 힘을 빌어 풀어보자는 것이므로, 사실은 귀차니즘 신봉자의 게임이라고도 할 수 있습니다. 그러니 '게으르면 게으를수록 프로그래밍에 능하다'는 Myth가 유포되는 것도 어쩌면 당연한 일일지 모르죠.

하지만 정말로 그럴까요? (오늘의 질문입니다.) 주변의 사례를 한번 살펴보겠습니다.

제 주변에는 '어찌나 모든것을 귀찮아 하는지 회의시간에도 꾸벅꾸벅 졸기만 하는' 프로그래머가 한명 있습니다. (편의상 그를 A라고 하겠습니다.) 요구사항 검토회의이건, 개발 회의이건 굉장히 일관되게 좁니다. 하지만 그 사람의 업무 생산성은 그다지 나쁘지 않습니다. 왜 그럴까요?

일단 A에게는 주어진 작업량을 시간 안에 해 낼 정도의 최소한도의 책임감과 능력이 있습니다. 그것마저 없었다면 아마 그는 벌써 회사를 나갔을 겁니다. 그리고 무엇보다, A는 '회의시간에 조는' 바로 그 불성실한 행위를 통해 (1) 요구사항 변동 (2) 문서 갱신 (3) 일정 변동 등등의 정보를 스스로 차단합니다.

통상 Waterfall 형태의 개발 방법론을 따르는 조직에서 실제 코딩에 돌입하기 전 70% 정도의 시간을 소요하게 마련인 (1), (2), (3) 등등의 절차를 기꺼이 외면한 그는, 모든 사람이 코딩에 돌입하는 '개발 phase' 초기가 되어서야 비로소 자신에게 할당된 작업의 이름을 확인하고는 주변 사람들을 귀찮게 해 가면서 '그 작업이 대체 무엇인지'를 파악하기 시작합니다. 그리고는 코딩을 시작하는 것이죠.

A가 정말로 '좋은 프로그래머'인지는 잘 모르겠습니다만 한 가지는 분명합니다. 그의 행동에는 '애자일 적' 혹은 '사용자 스토리'적인 구석이 있다는 것이죠.

사용자 스토리는 보통 '구현될 기능이 어떤 것인지'를 한두줄 정도로 명세하고 그칩니다. 실제로 구현되어야 할 시스템의 디테일은 테스트 케이스들을 통해, 혹은 고객과의 대화를 통해 알아내거나 해야 하죠. 하지만 Waterfall 형태의 개발 모델에서는 사용자 스토리 대신 '유스케이스'라는 도구를 사용하는 경향이 있습니다. 유스케이스는 잘 알려진 대로 특정한 액터의 시스템 사용 시나리오를 굉장히 상세하게 기술합니다. (심지어는 Exceptional Case까지 전부 하나의 유스케이스 안에 때려넣는 경우도 있습니다.)

A는 본인도 모르는 사이에 '사용자 스토리에 기반한 개발'과 유사한 형태로 개발을 하고 있습니다. 그가 커피타임에 이런 이야기를 하는 것을 들은 적이 있습니다.

'확정될 수 없는 것을 확정짓고 개발을 하려 하면 개발에 소요되는 시간은 더 늘어나게 되어 있습니다. 그렇게 열심히 만들어 놓은 유스케이스를 실제로 펼쳐놓고 코딩해야 될 때가 되면, 고객의 요구사항이 상당부분 바뀌어 있는 경우가 많잖아요?'

그러니, 어쩌면 A가 회의 시간에 조는 것은 요구사항이 널뛰는 과정을 연대기적으로 파악하고 있어야 하는 오버헤드가 귀찮아서 일 겁니다.

하지만 그의 행동에는 상당히 비-애자일 적인 면도 많습니다. '회의 시간에 조는' 바로 그 행위는 애자일 적이면서도 한편으로는 비-애자일적이기도 합니다. 다른 사람이 열심히 떠들때 '굉장히 일관되게' 존다는 것은 다른 사람들에 대한 배려가 부족하다는 증거입니다. 그런 경우에는 그가 몸담고 있는 조직이 그를 피곤하게 하는 것은 아닌지도 확인을 해 봐야겠지만, 그 자신의 태도에도 문제가 있음을 한편으로는 지적해 줄 필요가 있습니다. 애자일적인 조직이건, 비-애자일 적인 조직이건 가장 중요한 것은 상호 존중이기 때문입니다.

TIP: 회의를 외면하는 프로그래머가 늘어난다면 '사용자 스토리'를 도입하는 것을 고려해 보세요.

각설하고, 원래의 질문으로 돌아가보죠. 게으른 A는 훌륭한 프로그래머입니까? '게으른 사람 중에 훌륭한 프로그래머가 많다'는 것은, 게으름이 '상황을 개선하고자 하는 의지'로 환골탈태하게 되는 케이스가 많다는 것을 의미합니다. 하지만 A는 자기 주변의 상황을 전혀 개선하려고 하질 않아요. 상황을 개선하고 나면, 남는 시간에 보다 더 게을러질 수도 있는데 말이죠. 그러니, 제 기준에서 보면 A는 그다지 훌륭하지 않습니다. 충분히 게으르지 않은 프로그래머라고도 말할 수 있겠습니다. 프로젝트 기간의 70%를 유스케이스 작성에 투자하는게 그렇게 귀찮았다면, 스스로 애자일 프로세스 도입을 주장해서 상황을 더 낫게 만들 수도 있었을텐데 말이에요. :=P





신고
Posted by 이병준

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