요새는 소프트웨어를 개발할 때 문서 작업을 덜 해도 된다고 생각하는 듯합니다. no paper라는 가치가 생겨나고, 문서를 만들고 관리할 시간에 개발에 집중하면 더 나은 결과가 나올 것이라는 거, 오늘도 그런 비슷한 사례에 대한 경험자의 이야기를 들었네요. 듣다보니 아직도 그런 부분에 대해서는 실질적인 논의 자체가 거부되는 듯 해서, 오늘도 한 번 '욱' 해 봅니다. 하하.
결론부터 이야기해서 문서 작업, 필자도 솔직히 CMMi 레벨 획득할 정도로 안해도 된다고 생각합니다. 그럴 필요가 있나요? 쓸데 없잖아요. 개발 결과만 잘 나오면 되는거 아닌가요?
하지만 아이러니 하게도 우리는 현업에서 문서 작업을 계속 해야 하지요. 특히 SI가 그렇고, R&D라고 해도 그 중에 일본이나 독일에 납품하는 업체들은 그들이 가진 인수 기준의 까다로움에 욕을 하고 계실지도 모르겠네요. 그래도 기왕 밥 먹을 거 맛있는거 먹기를 바라는 인간의 심리처럼, 기왕 문서화 할거 기왕이면 잘하던가, 아니면 해야 하는 아유라도 명확히 해 보는게 어떨까 합니다.
"오랫동안 소프트웨어 도구를 만드는 기업이나 연구자에게 소프트웨어 위기를 해결하는 것은 매우 중요한 과제였습니다. 그러나 어떠한 도구, 원칙, 정형 기법, 프로세스, 전문성 그 어떤 것도 그것만으로는 해결책이 되지 못했습니다."
방법론: 폭포수 모델, 나선형 모델, V-모델 등...
도구 : Structured Programming, OOP, CASE 도구 등...
정형기법 : 정형적 공학 기법을 소프트웨어 개발에 활용. 모든 프로그램은 옳다는 것을 증명해야 함.
프로세스 : 프로세스와 CMM과 같은 방법론을 주장.
전문성 : 윤리, 자격증 등의 전문성.
출처 : Fredrick Phillips Brooks, Jr. Software Engineering, 1986
번역 출처 : 고려대학교 정형기법 연구실
애자일 세미나 혹은 QA 세미나 같은 SW공학 방법론과 관련된 세미나에 가면 많이 나오던 단골 질문 중 하나는 "SI 프로젝트에는 맞지 않은 것 아닌가요?" 입니다. 예전에는 저도 그렇게 생각했는데, 이제는 생각이 좀 다릅니다. 제 경험상 SW 개발 방법론들이 SI에 맞지 않는게 아니라, SI 프로젝트를 진행할 때 수주/계약 단계에서 문서 작업과 그에 드는 시간 및 비용을 프로젝트 계획으로 산정하지 않는다는게 정확한 근본적인 문제가 아닐까 합니다. 그러다보니 문서화를 할 공식적인 일정이 투입되지 않습니다.
그 근본적인 이유를 보면, 자꾸만 비용은 내리려고 하면서 프로젝트 품질은 올리라고 하니, 프로그래밍 산출물에 집중하겠다는 논리인데, 솔직히 그냥 핑계로 보입니다.
예를 들어볼까요?
만약 어떤 프로그래머에게 "연봉 9000, 4대보험 안됨, 너의 권한은 없으며, 일만 해야함. 난 너를 아무때나 짜를 수 있음" 이라고 쓰여 있는 계약서를 들이민다면, 과연 몇 명이나 그 조건에 싸인할까요? 왜죠? 정말 좋은 회사일 수 있는데요. 사장이 최선을 다 할거에요.
만약 어떤 집을 사는데, "내가 알아서 잘 지었으니 넌 그냥 살아라" 라고 되어 있고, 어떤 품질보증 문서나 A/S에 관한 조항이 없다면, 누가 거기에 입주할까요? 왜죠? 정말 좋은 집일 수 있는데요. 짓는 사람은 최선을 다 했을 겁니다.
어떤 보험을 드는데, "넌 돈 내면 내가 알아서 잘 관리했다가 필요할 때 줄께" 라고 쓰여 있다면 가입하시겠습니까? 왜죠? 정말 좋은 보험일 수 있는데요. 보험 관리자는 최선을 다 했을 겁니다.
다시 한 번 자신이 계약했던 계약 문서들을 잘 보시면, 여러분들이 계약하는 문서에는 회사가 기업으로서 지켜야하는 도리와 법적으로 물을 수 있는 책임의 한계, 법 관련 규제들에 대한 사항들이 잔뜩 적혀 있습니다. 회사와의 계약에서는 상호간 지켜야할 규약에 대해 적혀 있구요. 어느 한 쪽의 이익만 적혀 있는 경우는 계약이 중도 해지 되어도 법적인 책임을 물을 수 없습니다.
이런게 문서의 기본 목적입니다. 인간이 살아가는데 필요한 커뮤니케이션 중 증명이 필요한 부분들에서 효력을 발휘힙니다. 그러므로 문서화라는 것은 어떤 제품이나 서비스를 거래하는데 있어서 가장 기본적인 법률적 해석이 가능한 책임 소재의 증명이라고 볼 수도 있습니다.
프로그래머들은 자신들이 직접 코딩하고 하루에도 열 번씩, 백 번씩 테스트 해 보니 프로그램 산출물만을 가지고 충분하다고 생각하겠지만, 그 산출물을 돈 주고 사야하는 입장이 되어 보면 인수 기준은 단순히 잘 짜여진 프로그래밍 산출물만으로는 충분치 않다는 것을 스스로도 아실 수 있다고 생각합니다.
다시 바꾸어 이야기해 봅니다. 영수증 끊어주는 정형화된 마켓이나 식당보다는, 현금 밖에 받지 않고 영수증도 손글씨로 전표 떼주는 곳들이 더 편하고 좋으신가요? 그 분들에겐 그게 낭비를 줄이는 선택이고 집중이며, 비용을 아끼고 산출물에 집중하는 방식인데요. 문서화를 안하고도 충분한 결과만으로 통한다고 생각하신다면, 일단 자신이 스스로 먼저 그런 고객이 되셔야 하는게 아닐까요?
그래서 결론과 대안은 이렇습니다.
소프트웨어 개발 도중에 일일이 하나 하나 기록하고 관리하는 거, 정말 쉽지 않습니다. 어렵습니다. 그렇지만 뭐가 됐든 문서화가 되어 있지 않으면 관리하는 사람, 그 제품을 사는 사람 입장에서는 현금으로 전표 떼면서 물건을 사는 기분이 들겁니다. 그러므로 우리는 앞으로 산출물의 종류를 줄이고 집중해야 할 부분을 찾아야 합니다. 어떤 문서가 필요한지 연구하고 파악하고, 적용하여 개선해야 합니다. 또 어떤 문서가 필요 없는지, 타당한 이유를 대고 그런 문서가 정말 개발 중에는 필요하다면 대안을 만들어야합니다. 그런 종류의 노력은 오케이지만, 문서 자체를 산출하지 않고 결과만 잘 나오면 된다고 말하는 것은 자신이 하기 싫은 일, 못하는 일에 대한 책임을 남에게 전가하는 행위입니다. 언젠가 그 일이 자기 자신에게 돌아오게 되실겁니다.
요약
대부분의 사람들이 거래할 때 자신이 필요한 정보들은 모두 문서에 정확히 기재되어 있기를 원한다. 그런데 자신이 일할 때는 자신의 머릿 속에서 그것들은 꺼내지 않고도, 그 정보들이 잘 관리되고 있다고 생각한다. 그러므로 개선해야한다. 어떤 것이 필요한 문서이고, 어떤 내용을 기재해야 하는 지에 대한 고찰과 연구가 필요하다.
사실 대부분의 소프트웨어 개발에서 나타나는 문제는 PM이나 관리자에게 있습니다. 단적으로, PMBOK은 Body of Knowledge지, Body of Activity가 아니에요. 어떤 사항에 대해 알고 있으면 됐으니, 제발 자기가 다 할려고 들지 말았으면 좋겠네요. 애자일이든 뭐든 말이죠.
소프트웨어 문서, 역지사지 해 보면 쉽습니다.
