Talk about Software with hani

전, 지금 HTC에서 나온 터치 다이아몬드 핸드폰을 쓰고 있습니다. 모바일 기기 관점에서 보자면, 참 괜찮은 핸드폰입니다. 하드웨어 스펙이 좋아서, SCUMM VM을 설치해서 어릴 적 즐겼던 원숭이 섬의 비밀과 같은 어드벤처 게임도 즐길 수 있고요, 번들로 제공되는 월드 카드는 명함 정리를 하던 수고를 한방에 날려버렸습니다.* 그리고 FM 라디오 음질도 괜찮고, 화면 해상도도 좋아서 오피스 모바일을 사용해 워드나 파워포인트를 읽으면서 음악을 듣기에도 괜찮습니다.

HTC의 터치 다이아몬드는 확실히 장점이 많은 핸드폰인데요, (제가 이 핸드폰을 사용하면서 경험한 UX 관점에서) 치명적인 약점이 한 가지 있습니다. 바로 완성도입니다. 물론 스마트폰이라는 사실을 100퍼센트 이해해도, 일반 핸드폰과 비교했을 때 음성이나 화상전화를 할 때 불편한 점이 무척 많습니다.

전화 기능을 사용하면서 조금 당황스러운 경험이 몇 번 있었는데요, 특히 전화 잠김 상태에서 화상 전화를 받았을 때 조금 황당했습니다. 잠김상태에서 화상 전화를 받으면, 키패드 화면이 보입니다. 잠김 상태이기 때문에 비밀번호를 입력하라는 키패드 화면을 보여주는 건 어떻게 보면 당연한데요.

이 상태에서는 음성전화인지 화상전화인지 사용자가 인식할 수 없습니다. 따라서 화상 전화를 받았는데도 음성 전화라고 오해해서 전화를 받으면, 상대방은 제 영상이 까맣게 보인다고 말합니다. 그제서야 화상 전화라는 것을 알고, 키패드에 비밀번호를 입력하고 잠금 상태를 풀면, 제 얼굴이 보이기를 기다리는 상대방 얼굴을 볼 수 있습니다.

개통되지 않은 전화라도 111, 112, 113, 119와 같은 긴급 전화를 사용할 수 있습니다. 이 전화기는 잠금 상태에서 비밀번호을 입력하는 키패드만 제공되기 때문에, 처음 이 전화를 사용할 때 긴급전화를 걸려면 비밀번호를 입력하고 나서, 긴급전화를 걸 수 있다고 생각했죠(사진1).

그런데 재미있는 것은, 긴급 전화번호인 111, 112, 113, 119를 입력하면 비밀번호를 나타내는 별표(*)가 사라지고 숫자가 나옵니다(사진2). 즉, 잠김 상태에도 긴급전화를 사용할 수 있는데요. 그렇다면 비밀번호로 앞자리로서 111, 112, 113, 119를 사용하면 비밀번호 노출의 위험이 있습니다.

사진1. 비밀번호 입력 화면

사진2. 비밀번호로서 긴급 전화번호와 일치하는 것을 입력할 때

기능적인 측면에서 HTC 다이아몬드 터치는 괜찮습니다. 하지만 완결성 측면에서 이 핸드폰의 UX를 바라 보자면, 점수가 매우 낮습니다. 전, 그 원인을 플랫폼과 OS에서 찾습니다.

아이폰의 경우 완성도 면에서 높은 평가를 봤는데, 애플이 하드웨어와 소프트웨어를 모두 통제하기 때문이죠. 하지만 모바일 윈도 기반의 스마트폰의 경우, 하드웨어 제조사가 윈도 기반에서 Application을 개발하기 때문에, 소프트웨어 측면에서 완결성을 애플보다 상대적으로 추구하기가 힘들기 때문일 듯합니다.

결국 이 포스트의 이렇게 요약될 듯합니다. 즉 스마트폰을 잘 쓰고 싶은 한 사람으로서, 별로 스마트하지 않은 핸드폰을 버리고, 스마트할 것이라고 믿는 아이폰으로 갈아탈 예정입니다. 과연 아이폰은 사람들이 말하듯이 스마트한지 냉철하게 사용하고 평가해 보겠습니다.

* 월드 카드의 명함 인식률은 정말로 대단합니다.

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

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

from 애자일 프랙티스

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

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

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

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

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

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

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

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

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

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

얼마 전에 제가 참여했던 프로젝트가 끝났습니다. 무사히 끝나서 천만다행이죠. 지금에서야 드는 생각이지만 약간은 무모한 프로젝트가 아니었나 싶습니다. 데드라인도 달력 위에 특정한 날짜로 고정되어 있었고, 개발범위도 협상가능하지 않았으며, 프로젝트 예산조차도 딱 정해져 있었습니다.

이 프로젝트가 제안되고 프로젝트로 만들어질 때, 동료들이 “누가 PM이나 팀원이 될지 모르겠지만, 고생이 심하겠다”고 말할 때, 저도 고개를 끄덕였죠. 물론 프로젝트의 성공만을 놓고 볼 때에, 이런 프로젝트는 피해야 하는 게 상책이지만, 조직 입장에서 매우 중요한 프로젝트였기 때문에, 어쨌든 성공해야 했습니다.

하지만

프로젝트의 PL로서(그리고 실질적인 PM), 제가 낙점되었다는 희소식(?)에 ‘관조끝 고생시작’의 길로 들어섰습니다. 대개 제한인자가 많은 프로젝트에 참여하는 팀원들은, 약간의 피해의식에 빠져드는 경향이 있지만. 그나마 다행스럽게도 팀원들로서 긍정적인 동료들이 참여했죠.

겸손한 개발자가 만든 거만한 소프트웨어에서 다루었지만, 소프트웨어 개발 프로젝트에서 작업량을 예측하는 것은 매우 중요합니다. 즉 거만한 소프트웨어의 한 종류인, 품질이 나쁜 소프트웨어를 만들지 않으려면 프로젝트 기간에 품질을 확보할 있는 작업 시간이 필요 하고. 그럴려면 팀원들이 탈진하지 않고 개발 리듬을 활기차게 유지할 수 있도록, 하루 평균 8시간 정도만 작업해야 합니다.

8시간 근무를 하려면 작업량을 예측하는 작업을 먼저 진행해야죠. 즉 주어진 프로젝트 기간에 주어진 팀원들로 고객이 원하는 기능을 모두 개발할 수 있는지 우선 예측을 해야 합니다. 프로젝트 초기에 내린 작업량 예측치는 대개 틀리기 마련입니다. 예측을 하는 데 필요한 데이터가 부족하고 정확하지 않기 때문이죠.

예측치의 정확도를 높이려면, 애자일에서 하듯이 반복주기가 끝날 무렵 예측치가 얼마나 정확했는지 평가하고, 예측치의 정확도를 높이는 작업을 해야 합니다. 그리고 남은 기간 동안, 고객이 원하는 기능을 모두 인도할 수 있는지 판단해야죠. (가능할지 모르지만) 주어진 기간에 모든 기능을 인도할 수 없다면, 고객(내부고객이든 외부고객이든)과 요구사항 or 예산 or 기간을 두고 협상을 해야 합니다.

앞의 이야기는 프로젝트를 수행해 보신 분들은 거의 아시는 이야기일 듯합니다. 제가 참여했던 프로젝트처럼 지나치게 제약사항이 많은 상황에서도, 작업량을 예측할 필요가 있을까요? 작업량을 예측한다는 것은, 프로젝트를 구성하는 여러 조건들을 조정할 수 있다는 것을 가정하죠. 하지만 제약사항이 모두 고정되어 있을 때 사실 협상의 여지가 없기 때문에, 작업량을 예측하는 것은 그다지 도움이 되지 않습니다.

그렇다면 이런 상황에서, PL로서 저는 어떤 선택을 했을까요? 제약사항이 많았지만, 다행스럽게도 설계서와 비슷한 산출물을 고객이 제공했고, 전문 테스터가 프로젝트에 투입됐습니다(개발자 2명당 테스터 1명이 붙었습니다. 일반적인 프로젝트와 비교했을 때, 테스터 비율이 무척 높았죠*).

이런 호의적인 조건에 덧붙여서 프로젝트를 성공시키기 위해서, 저는 ‘과연 프로젝트를 합리적으로 끝낼 수 있는지 고민’하기보다, ‘프로젝트를 성공에 가깝게 하는 방법’들을 적용하는 데 주력했습니다. 즉 제가 프로젝트의 PM으로 참여할 때 항상 적용하는 애자일 실천방법을 조금 더 밀도 있게 적용했습니다. 이런 실천 방법으로는 스탠드업 미팅, 짝 프로그래밍, 동료 검토(Peer review), statement coverage 100퍼센트를 목표로 한 단위 테스트, 프로젝트 초반부터 테스터와 협업 등이 있었습니다.

애자일 프랙티스를 처음 경험하는 팀원들이 대다수여서, 짝 프로그램이나 동료 검토에 대해서 프로젝트 초반에는 회의적인 분위기가 다소 있었지만. 프로젝트를 시작하고 나서 2주 정도 지나자, 짝 프로그래밍과 동료 검토의 효과를 경험하고 나서, 프로젝트에는 경쾌한 개발 리듬이 형성되었죠. 그리고 다행스럽게도 프로젝트는 잘 마무리되었습니다.

세상에 협상 불가능한 것은 존재하지 않습니다. 제약사항이 많은 프로젝트라든지, 협상이 불가능하다고 선언한 고객이라도, 불가피한 상황에서 이해당사자들이 협상 테이블에 앉기 마련입니다. 그렇기 때문에, 작업량을 계속해서 예측하는 것도 도움이 될지 모르죠. 하지만 협상 테이블이 차려질 정도면, 이미 이해당사자들이 감정이 상한 상태이거나 팀원들이 탈진 상태인 경우가 흔합니다.

작업량을 예측하는 것도 어느 한편으로 도움이 되지만. 그것보다 제가 경험한 프로젝트처럼, 기민하게 프로젝트를 성공시킬 수 있는 실천방법을 적용하든가. 고객 입장에서 우선순위가 가장 높은 기능 순서대로 개발을 해서, 협상 테이블이 차려졌을 때, 협상 가능성을 높이는 편이 낫다는 생각입니다.

* 이번 프로젝트에서 어떤 식으로 테스터와 협업했는지는 다른 포스트에서 한번 다뤄 보겠습니다.

얼마 전에 구글을 지탱하는 기술을 읽었습니다. 재미있는 이야기가 많았는데, 관심을 끄는 이야기는, 구글의 개발환경이었습니다(물론 분량이 매우 적었기 때문에, 구글의 개발환경에 대해서 자세히 알 수 없는 아쉬움이 있었죠). 특히 개발이 끝난 소스는, 개발자가 아닌 다른 사람이 반드시 검토를 한다는 이야기가 흥미로웠습니다. 물론 검토함으로써, 소프트웨어의 품질이 높아진다는 구글러의 이야기도 있었죠.

구글에서도 효과적으로 사용한다는 검토는, 소프트웨어 분야의 전유물이 아닙니다. 전자제품 설계가 끝나고 나서, 설계 검토(Design Review, DR)를 실시하도록 대부분의 전자제품 회사에서는 설계 프로세스에 명시해 두죠. 예전에 전자제품의 기구 설계 설계 관련한 컨설팅 프로젝트에 참여했을 때, 설계실장님이나 프로젝트 리더들이 설계 검토가 중요하다고 생각하고, 설계자들에게 DR을 꼭 실시하도록 지시하는 것을 많이 봤습니다.

설계 프로세스에 DR이 명시되어 있거나 윗분들의 엄한 지시가 있어도, 설계자들은 DR을 잘 수행하지 못했습니다. DR을 수행하면, 설계자들이 생각하지도 못한 문제를 발견하거나, 제품이 양산 되기 전에 문제점을 미리 발견해서 해결할 수 있기 때문에, 제품 개발 후단의 업무가 줄어든다는 장점이 있습니다. 이런 장점들은, 경험하지 않은 설계자들도 선험적으로 알고 있었죠.

그렇다면, 설계자들은 이렇게 좋은 DR을 왜 실시하지 않았을까요?

언제나 그렇듯이, 설계 시간이 부족하다는 이유로 형식적으로 DR을 진행하거나, 어쩔 때 생략하고 넘어갔습니다. 물론 프로젝트 리더들도 DR의 중요함을 강조했지만, 실상 양산 일정이 촉박하게 다가오면 일단 설계자들의 능력을 믿고 설계도를 타부서로 넘기는 경우가 많았습니다.

전자제품을 만드는 곳에서 DR을 효과적으로 수행하지 못하는 이유는, 어디에서 많이 들어본 변명이 아니신지요? 맞습니다. 소프트웨어를 만드는 우리 일터에서도 늘상 부딪히는 불만과 비슷합니다.

“그거 하면 좋은 줄 알겠는데, 개발할 시간도 부족해서요. 우리 회사에서 불가능해요.”

소프트웨어의 검토 방식은 다양하죠. 즉 짝 프로그래밍, 버디 리뷰(buddy review), 동료 검토, 워크스루, 정식 검사(formal code inspection) 등이 있습니다.* 어떤 검토 방식을 선택해서 업무에 적용해도, 나름의 효과를 얻을 수 있습니다. 제 경험을 보면, 짝 프로그램의 비용이 가장 낮고 효과가 가장 좋죠. 짝 프로그래밍에 비해서, 정식 검사가 비용이 가장 높지만, 발견하는 결함이 가장 적었습니다.**

***

물론 검토가 소프트웨어 분야의 전유물은 아니지만, 검토는 제품을 개발하는 조직보다 소프트웨어를 개발하는 조직에 훨씬 효과적이고 꼭 필요합니다. 제품을 만드는 조직에서는, 스펙을 잡고 설계도를 그리고 나서, 양산을 하기 위해서 생산 부서, 품질 부서 등에서 검증작업을 별도로 수행하기 때문에, 설계상의 오류를 제품 개발 뒷단계에서 어느 정도 잡아낼 수 있습니다.

하지만 소프트웨어 개발 조직에서는, 특히 SI 프로젝트인 경우 전문 테스터가 프로젝트에 투입될 때가 가뭄에 콩 나듯하고, QA가 하는 일은 체크리스트에 있는 항목을 검토하는 수준에 머물거나, 단위 테스트는 교과서에 나오는 이야기로 생각할 때가 흔하기 때문에, 소프트웨어를 설계하거나 만들면서 발생하는 버그는, 고객이 찾아주는 일상다반사의 것이 됩니다. 이럴 때,  바로 소프트웨어의 품질을 높이는 방법으로서 검토가 매우 효과적이라고 생각합니다.

* from Manage It!

** (제 경험상) 짝 프로그램이 비용 대비 효과가 가장 뛰어나고 정식 검사가 가장 효과적이지 않은 이유는, 한번 검토할 때 살펴 봐야 하는 코드의 양과 검토에 필요한 설계 지식의 양에 있습니다.

짝 프로그래밍을 하면 검토의 범위가 함수나 매우 작은 모듈 단위에 국한되죠. 검토 범위가 매우 좁기 때문에, 다양한 관점에서 코드를 검토할 수 있습니다. 하지만 정식 검사를 한다면, 매우 큰 모듈이나 프로그램 전체가 될 때가 있기 때문에, 정식 검사가 자칫 로직이나 버그를 검토하는 자리가 아닌 코딩 룰 정도나 주석을 Copy & Paste를 하지 않았는지 살피는 자리가 되죠.

짝 프로그래밍을 수행하면 검토자와 작성자의 코드를 비슷하게 파악하기 때문에, 검토 수준이 매우 깊습니다. 이에 반해 정식 검사를 수행할 때, 코드를 미리 배포해도 정식 검사 참석자들이 단 시간 안에 작성자만큼 코드를 파악하지 못할 때가 흔합니다. 그렇기 때문에, 정식 검사는 들인 시간에 비해서 효과적이지 못할 때가 잦습니다.