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

흔히 프로그래밍에 있어서 게으름은 '창조의 어머니'에 비유되고는 합니다. 프로그래밍은 복잡한 문제를 단순하게, 그것도 컴퓨터의 힘을 빌어 풀어보자는 것이므로, 사실은 귀차니즘 신봉자의 게임이라고도 할 수 있습니다. 그러니 '게으르면 게으를수록 프로그래밍에 능하다'는 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 이병준

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