Talk with Hani

인사이트에서 신간 이해관계자중심 소프트웨어 개발을 보내 주셨습니다. 택배를 뜯었을 때, 책표지를 보고 신선하다고 생각했습니다. 최근 인사이트에서 나오는 책답지 않게(?) 표지가 모던했기 때문이죠.

이  책에서 말하는 이해관계자중심 소프트웨어 개발이란 무엇일까요? SW개발 프로젝트에서 흔히 접하는 이해당사자(stakeholder)와 비슷한 개념입니다. 물론 책의 원제는 Outside-in Software Development이기 때문에, 이해당사자로 번역하는 stakeholder와는 다르지만요.

책에서는 이해관계자를 4가지 분야로 분류합니다. 우선 주관계자(principals)가 있습니다. 주관계자는 SW개발 프로젝트나 SW구매에 자금을 대는 사람으로서, 흔히 스폰서라고 말하는 사람들이죠. 주관계자와 눈높이를 맞추는 작업을 프로젝트 기간에 충실히 하지 않으면, 프로젝트 완료보고 때 프로젝트가 180도 선회하는 경우가 있죠. 즉 ‘집에도 못가거나’, ‘집에 가야’하는 상황이 벌어질 때도 있습니다.

다음으로 최종 사용자(end users)가 있습니다. 이름에서 알 수 있듯이, 시스템이나 SW을 사용하는 사람들입니다. 이 분류에 속하는 사람들의 눈높이를 맞추지 못하면, “시스템 어려워서 못 써먹겠어요!”라는 불평의 스나미에 휩쓸릴 수 있습니다. 겸손한 개발자 만든 거만한 소프트웨어서도 최종 사용자의 눈높이를 맞추지 못해서 고생했던 ERP프로젝트를 소개했는데요. 대개 이런 프로젝트들에서는 주관계자들의 눈높이에 맞추서 프로젝트가 진행될 때가 잦기 때문에, 최종 사용자들에게 과도하게 데이터를 많이 입력할 것을 요구하거나, 최종 사용자를 고려하지 않은 채 UI가 만들어집니다.

세번째 분류는 협력관계자(partners)입니다. SW를 대신 판매하는 1차 벤더나, SW나 시스템을 설치, 지원하는 업체를 말하죠. 프로젝트나 SW가 성공하려면, 이분들이 제품을 잘 팔도록 도와주거나, 설치와 유지보수가 쉽게 제품을 만들어야 합니다. 이분들이 “아, 이 소프트웨어는 발로 만들었냐. 이렇게 설치가 어려워서 뭘 하라는 거야!” 식의 불평이 터진다면, 시스템이나 SW는 생명유지가 쉽지 않을 겁니다.

마지막으로 내부관계자(insiders)가 있습니다. 말 그대로 우리네 조직을 말하죠. 개발자, QA, 영업, 테스터, PM이 여기에 속합니다. 당연한 이야기이지만, 내부관계자끼리 제대로 협력을 하지 못해서, 영업은 개발자들이 거만해서 자신들의 이야기에 귀를 귀울이지 않는다고 불평하거나, 개발자들은 영업이 무식해서 제대로 제품도 못 판다고 비아냥거린다면, 프로젝트는 산으로 갈 겁니다.

백인백색의 이해관계자가 원하는 것을 파악하고, 이들 사이에 접점을 잘 찾아나가는 것이, 바로 이해관계자중심 소프트웨어 개발이라고 말하죠. 자세한 이야기는 책을 읽으실 분들을 위해, 남겨 두겠습니다.

PM으로서 프로젝트를 하나씩 끝날 때마다, 프로젝트를 바라보는 시각이 조금씩 바뀌는 듯합니다. 제일 처음 프로젝트를 맡았을 때, 프로젝트를 끝내는 데 초점을 맞췄죠. 그렇기 때문에, 프로젝트 내에서 개발할 기능들을 제일 신경썼죠. 그리고 회사에서 PMBOK 형태의 프로젝트 체계를 강조했을 때, 프로젝트 계획을 준수하는 것을 중요하게 생각했습니다. 그런데, 프로젝트라는 게 변화무쌍한 유기체 비슷하고, 장기 계획의 정확성이 낮다는 것을 깨닫았을 때, 변화를 관리하는 게 중요하고 그래서 애자일 실천방법을 프로젝트에 적용하는 것에 중점을 두었죠.

그리고 최근에 드는 생각은, 특히 SI 프로젝트라면, 다양한 이해당사자들의 힘 벡터가 평형을 이루는 지점에 시스템이 완성된다는 것입니다. 즉 주관계자 벡터가 크다면, 시스템은 최종 사용자 쓰기 어려운 거만한 소프트웨어가 되거나. 내부관계자가 벡터가 지나치게 큰 경우, 그들만의 잔치로 끝나는 경우가 있죠. 물론 벡터의 합으로서 시스템이 만들어진다는 결정론을 받아들인다면, 프로젝트를 이끌어가는 PM은 상당히 무력한 존재이지만. 벡터는 정적인 것이 아니라 동적인 것으로 받아들인다면, 미약한 힘이지만 PM은 벡터의 평형점을 옮겨서 모든 사람들이 만족해 하는 시스템을 만들 수 있지 않을까 합니다.

아마존 킨들DX의 포장박스에 이렇게 쓰여 있죠.

Don’t judge a book by its cover

참 맞는 말이라고 생각하는데요. 그런데 실상 서점에서 손에 먼저 들게 되는 책은, 눈에 잘 띄는 책입니다. 내용을 잘 살피지 않고 제목과 책 커버 때문에 책을 사서 애궂은 출판사를 욕한 경우도 가끔이지만, 표지가 마음에 들지 않는다고 책을 멀리해서 괜찮은 책을 놓치는 경우도 있죠. 바로 ‘만화로 쉽게 배우는 푸리에 해석’도 표지 때문에, 책의 가치를 평가절하할 뻔했습니다.

제목도 그렇지만, 표지 그림에 있는 여고생 3명이 조금 부담스러웠습니다. 그런데, 이 책 읽을수록 대학교 공업시간 때 교수님이 참 어렵게 설명하시던 푸리에 해석을 무척이나 쉽게 설명했다는 데 감탄했습니다. 여고생 3명으로 이야기를 푸리에 해석을 풀어간다는 게 조금 아방가드르하고, 만화의 스토리가 거의 없다는 점이 아쉽지만. 삼각함수, 적분, 함수의 직교성 등으로 차근차근 이야기를 풀어가면서, 고등학교 수학을 조금이라도 아는 사람이라면, 푸리에 해석을 쉽게 이해하도록 정리해 두었습니다.

공업수학시간에 교수님의 지루한 설명 때문에, 재미있는 푸리에 해석을 배우는 기회를 놓친 분이라면, 꼭 읽어보시길 바랍니다.

대한민국 소프트웨어는 위기다?!

이 위기를 도약의 발판으로 삼고 싶으신가요? 그렇다면 ‘대한민국 소프트웨어, 리스타트’, 이 책을 한 번 읽어 보세요.

Yes24 교보문고 알라딘 리브로 인터파크

스크럼(Scrum)에서는 팀원과 비 팀원의 역할을 돼지와 닭 이라고 이름 붙였다. 팀원은 돼지(자존심 접었다!)고 비 팀원(관리자, 지원, QA 등)은 닭이다. 이 용어는 농장의 동물이 모여서 식당을 연다는 우화에서 나왔다. 아침 메뉴로 베이컨과 계란 프라이를 내놓으려고 할 때, 닭은 단순히 계란을 하나 내며 참여하는 수준이지만, 돼지는 자기 살을 내어주는 헌신인 것이다.

오직‘돼지’만이 스크럼 스탠드 업 미팅에 참석하는 것이 허용된다.

from 애자일 프랙티스

스크럼에서는 프로젝트에 참여해서 적극적으로 일하는 팀원을 돼지라고 말합니다. 닭이 계란만을 넘길 때, 돼지는 자기 살을 떼어서 베이컨을 만드는 데 쓰기 때문이죠. 만약 여러분이 스크럼을 사용하는 프로젝트에 참여하고, 날마다 조금씩 살을 떼어내는 심정으로 일을 한다면, 여러분은 분명히 자랑스러운 ‘돼지’일 겁니다. 그런데 이런 생각이 듭니다. 과연 날마다 내가 만들어내는 산출물이나, 내 노력이 다른 돼지들의 노력과 비슷한 수준으로 프로젝트 성장에 기여하는 것일까요?

testers insight에서, “모든 돼지는 평등하지 않을 수 있다”는 논지의 칼럼을 읽었습니다. 칼럼을 쓴 테스트 전문가는 소위 말하는 애자일 프로젝트에 참여하는 테스터들이 다른 돼지(주로 개발자)처럼 프로젝트에 많은 기여를 하지 않는다고 합니다. 물론 TDD, 동료 검토, 인수 테스트 같은 테스트 영역의 실천방법들이 있지만, 이것들은 어디까지나 개발자 입장에서 코드 품질을 높이는 데 사용하는 것이라고 말하죠.

테스터로서 애자일 프로젝트에 참여해서, 단순히 돼지 개발자들이 개발을 잘하도록 지원해주는 돼지 테스터는, 확실히 개발자 돼지보다 프로젝트에 기여하는 게 떨어진다고 합니다. 테스터 전문가는 이런 상황을 조지 오웰의 동물농장에 나온 말을 인용해서 재미있게 표현했습니다.

모든 동물들은 평등하다. 그러나 어떤 동물들은 다른 동물보다 더욱 평등하다.

동물농장에서 인간과 결탁한 돼지들이 다른 동물들을 착취하려는 목적으로, 더욱 평등한 동물이 있다는 말을 했기 때문에, 인용문을 지탱하는 논리는 애자일 프로젝트에서 불평등한 돼지가 나오는 논리와 다릅니다. 그리고 스크럼 마스터나 프로젝트 관리자가, 프로젝트 팀원들이 평등하게 팀에 기여하고 보상받도록 노력해야죠.

하지만 애자일 프로젝트에 참여하는 팀원들이라면, 그리고 내가 다른 돼지들보다 프로젝트에 기여하는 게 적거나 영향력이 적다라는 생각이 든다면, 스스로 프로젝트에 어떻게 기여를 할려고 노력했는지 생각해 봐야 합니다. 애자일 프로젝트는, 역할과 책임이 분명히 정의된 명식적인 프로세스보다 정형성이 떨어지기 때문에, 누가 무엇을 해야 하는지가 명확하지 않습니다.

이런 점 때문에, 애자일 프로젝트는 제멋대로 하는 프로세스를 사용한다는 오해를 받지만, 이런 비정형성에서 애자일 프로젝트의 강점이 나옵니다. UI전문가는 개발자가 최대한 쉽게 구현하도록 UI를 설계하고, 개발자는 테스터 커버리지를 최대한 높이도록 코드를 쉽게 작성하며, 테스터는 프로젝트 초반부터 팀원들이 테스트의 중요성을 인식하고 산출물을 작성하도록 도와줄 때, 애자일 프로젝트는 강력한 힘을 발휘합니다.

애자일 선언문의 바탕을 이루는 아이디어는 ‘인간다움’이라고 생각합니다. 그렇기 때문에 프로젝트 팀원이 불평등한 대우를 받는 것을 암묵적으로나 명시적으로 인정하지 않을 겁니다. 하지만 “직원들의 개인화야말로 조직의 핵심프로세스 중 하나다”라는 말을 생각해볼 때, 내가 다른 돼지보다 기여하는 게 적거나 영향력이 적을 때, 나는 진정으로 다른 돼지들만큼 대접받기 위해서 얼마나 노력했는지 반추해봐야 합니다.

인생을 지나치게 전투적으로 살 필요는 없지만, 작은 충돌과 투쟁 속에서 발전하는 게 삶이 아닐까합니다. 이런 논지로, 동물농장의 인용문을 이렇게 바꿔보면 어떨까요?

모든 돼지들은 평등하다. 그러나 치열하게 노력하는 돼지는 다른 돼지보다 더욱 평등하다.

요구공학 전문가가 내구성 소비재를 만드는 회사에서 요구공학 세미나를 진행했습니다. 이해당사자(stakeholder) 개념을 설명하고 나서, 세미나 참석자들에게 제일 중요한 이해당사자로 누가 있는지 물었습니다.

어떤 대답이 나왔을까요? 흥미롭게도, 참석자들이 대부분 자신의 ‘상관’을 가장 중요한 이해당사자라고 대답했다고 합니다. 내구성 소비재를 만드는 회사였는데, ‘고객’을 가장 중요한 이해당사자라고 말하지 않은 이유가 궁금했습니다. 저는 요구공학 전문가와 그 원인을 놓고 이야기를 했는데요.

가장 그럴싸한 답은, 회사의 조직에서 찾을 수 있었습니다. 그 회사는 전형적인 피라미드 형식의 기능조직이었기 때문에, 고객을 가장 중요한 이해당사자로 생각하기보다, 자신을 평가하는 조직장을 가장 중요한 이해당사자로 생각하는 듯했습니다.

아무래도 기능조직 중심인 회사에 속한 개인이, 자신이 만드는 제품을 사용하는 고객을 이해당사자로 생각하기는 쉽지 않을 듯합니다. 즉 팔이 안으로 굽는다고 했듯이, 눈에 보이지 않는 고객을 중요하게 생각하기보다, 아무래도 조직장의 요구사항이 더 중요할테니까요.

그런데 이런 생각도 듭니다. 중간관리자인 상관들이 제대로 된 의사결정을 내릴 수 있다면, 이런 회사에서 만드는 제품도 고객이 만족하고 사용할 듯합니다. 업무는 실무진이 하고 중요한 의사결정은 경영층에서 내리지만, 중산층이 사회의 방향을 선도하듯이. 중간관리자들이 어떤 마인드로 어떻게 협력하느냐에 따라서, 그 조직의 성공 여부는 판가름나기 때문입니다. 물론 상관이 가장 중요한 이해당사자라는 답변이 아직도 어리둥절하지만요.