신승환

로망은, 실현되리라!

Archive for the 'software' Category


프로젝트 팀원들을 구덩이에 몰아 넣어라.

Friday, June 1st, 2012

프로젝트를 관리하는 방법은 다양하다. pmbok과 같은 지식을 사용해서 체계적으로 관리하는 방법이 있다. 이 방법은 상당히 형식성을 겸비한 방법이다. 이에 반해서 비형식성을 추구하는 방법으로 아예 프로젝트를 관리하지 않는 방법도 있다. 물론 자유 방임형을 가장한 프로젝트 관리의 포기라고 할 수도 있지만. 나름 철학이 있는 경우 자유 방임형도 효과적이다. 이런 자유 방임형이 효과적일려면 몇 가지 전제 조건을 만족해야 한다.

‘고약한 문제 합당한 해결’에서 스크럼의 시초를 설명하는 예제가 나온다. 팀원들을 모아놓고 여기 모인 사람들은 실패 위험이 큰 프로젝트에 참여할 것이라고 이야기한다. 목표를 달성하기 위한 방법은 알아서 결정하라고 말하고 목표가 말이 안 되어 프로젝트에 참여하지 못할 것 같다고 느낀 사람들은 이 방을 떠나도 좋다고 이야기한다. 프로젝트가 끝난 후 보자는 말을 남기고 방을 나온다. 그 이후 어떻게 될까?

방에 남겨진 사람 가운데 일부는 말도 안 되는 프로젝트라며 방을 나간다. 일부는 방에 남아서 이런 프로젝트를 기획한 회사 경영층을 욕하고 그 가운데 일부는 프로젝트를 성공시키기 위해서 어떻게 해야 할지 고민한다. 이런 사람들을 중심으로 프로젝트의 계획이 세워지고 진행이 된다. 방에 남아서 의심을 품었던 사람들도 프로젝트가 진행되는 게 보이자 프로젝트에 적극적으로 참여한다. 프로젝트 기간이 끝나고 나서 프로젝트 룸을 다시 방문하면 놀라운 광경을 목격한다. 불가능해 보이던 프로젝트가 끝났다.

상위 관리자 입장에서 목표와 기간만을 던져 놓고 관리한 게 없기에 자유방임형 관리라 했지만. 사실 이런 프로젝트 관리 방법은 애자일의 핵심요소인 자기조직형 조직으로 운영할 수 있을 때 효과적이다. 사실 관리자 입장에서 자유방임형이지만 이런 자유방임형 프로젝트 관리 기법은 막 적용한다고 성공하지 못한다. 이런 방법을 혹자는 구덩이에 팀원을 몰아놓고 알아서 올라오게 하는 방법이라 부르기도 하는데, 이런 별명에서 알 수 있듯이 구멍에서 팀원들이 기어올라 오려면 능력이 출중해야 한다.

자기조직형 조직이 되려면 팀원들이 위계로 관리 받는 게 아니라, 기술적 리더십과 권위나 수평적 관계로 관리되고 의사소통해야 한다. 아울러 프로젝트에 대한 후원이 적극적이어야 한다. 목표가 도전적인데 이래저래 제약조건이 많다면 프로젝트 망하라는 소리일 뿐이다. 관리자 입장에서 이런 프로젝트 운영방식은 마법처럼 보이나, 이게 성공하려면 똑똑하면서 긍정적이고 협업에 능한 직원들을 뽑아 놓아야 한다. 그런데 이런 사람 구하기가 쉽지 않으니 이 방법이 성공하는 경우가 극히 드물단 사실을 유념하시길.

페이스북 최고의 먹튀가 될 것인가?

Friday, May 25th, 2012

페이스북이 상장했지만, 그 체면이 말이 아니다. 아직 섵부른 판단일 수도 있지만, 페이스북의 상장 전과 상장 이후의 논란을 보면서, 몇 년 전에 웹2.0 열풍이 불었을 때가 생각났다. 웹2.0 열풍이 불었을 때, 웹2.0을 기반으로 새로운 경제가 활성화될 것이라는 말이 많았다. 심지어는 웹2.0 때문에 공짜 경제가 주류 경제로 자리 잡을 것이라는 이야기도 있었다. 그런데 공짜 경제라는 게, 난 말이 안된다고 생각한다. 도대체 공짜 경제란, 무엇을 기반으로 한 것이란 말인가?

자본주의의 대척점에 있는 사회주의를 기반으로 한 개념이라면, 어감이 이상해도 받아들일 수 있다. 하지만 당시에 공짜 경제란 자본주의 새로운 접근방식을 말한 것이다. 정리하자면 하드웨어의 비용이 싸지고 있으니까 사람들이 웹에 올리는 지식이나 경험이 더 중요해지고, 이것을 기반으로 모든 비용은 0으로 수렴하니, 자 이제 모든 재화는 웹에 있는 재화는 공짜로 뿌릴 수 있다. 따라서 우리는 말 그대로 돈을 내지 않고 공짜로 즐기는 경제의 시대에 살게 되었다는 논리였을 것이다. 이런 논리를 받아들여, 우리가 웹에서 모든 것을 공짜로 사용한다고 하더라도, 현실에서는 하루 세 끼 꼬박꼬박 밥을 먹고 살아야 하고, 서울9호선 요금이 500원 인상된다는 소식에 열 받는 건 어떻게 할 수 없다.

말하자면 웹으로 대표되는 가상 세계의 재화에 대해서, 우리는 최대한 공짜로 소비할 수 있지만, 현실을 기반으로 먹고 살아야 하는 인간은, 오래되어서 이상한 냄새조차 나는 자본주의를 기반으로 살아갈 수밖에 없다.

이렇게 이야기를 하면 이런 반문하는 사람도 있을 것이다. 구글도 공짜로 검색엔진과 다양한 서비스를 제공해서 돈을 벌고, 네이버도 공짜로 각종 컨텐츠를 제공해서 잘 먹고 산다고 말이다. 물론 구글이나 네이버 같은 서비스를 공짜로 쓸 수 있다는 건, 소비자로서 다행이다. 하지만 우리가 공짜로 이런 서비스를 쓸 수 있는 이면에는, 탄탄한 자본주의의 메카니즘이 작동하기 때문이다. 즉 최신 서비스업이나 구닥다리 같은 제조업에서 지출하는 광고비가 있기 때문이다. 이들 기업을 근거로 끝까지 웹2.0의 공짜 경제학이 유효하다고 주장한다면, 이제는 점점 사라지고 있는 지하철 무가지도 웹2.0은 아니지만 아주 훌륭한 공짜 경제학의 하나였다고, 반문하고 싶다.

흔히 기대는 컸지만 결국에 실적이 미미했다는 것이 궁극적으로 밝혀지는 것을, 좋게 이야기해서 거품이 꺼졌다고 한다. 거품의 속성상 거품이 한창일 때는 모른다. 거품이 한창일 때는 어떤 논리를 가져다 놓아도 거품이 커지는 이유를 댈 수 있다. 앞에서 예를 든 웹2.0이 한참 그 거품을 키울 때, 우리는 공짜 경제학이라는 이상한 용어로 웹2.0이 제공해줄 수 있는 가치를, 고전적인 자본주의의 잣대로 말하는 것을, 넌센스라고 말했다. 하지만 거품이 꺼지고 나서, 결국 자본주의에서 탄생하고 성장하고 소멸하는 사업은, 이익을 내지 않으면 안된다는 명제를 새삼 확인했을 뿐이다.

자, 오늘의 글을 시작한 질문으로 돌아가보자. 과연 페이스북은 최고의 먹튀가 될 것인가? 지금 당장 확답은 내리기 쉽지 않다. 하지만 적어도 지금처럼 성장 가능성만으로는 더 이상 페이스북의 미래를 아름답게 그릴 수 없다는 점은 확실하다. 예를 들자면, 와! 페이스북의 사용자가 점점 늘어나, 페이북의 사용자의 이용시간은 타의추종을 불허해, 아직 중국 사람들은 페이스북을 쓰지 않잖아… 그러니까 PER가 100 가깝게 되더라도, 구식의 잣대로 페이스북의 성장 가능성을 점치지는 말아,라고 생각의 방점이 찍히는 순간, 우리는 거품의 논리에 한참 빠져 있는 것이다.

우리가 사는 이 세계는 자본주의다. 수정자본주의, 주주자본주의, OO자본주의라고 다양하게 고쳐 부를 수 있지만, 자본주의 세계는 수요와 공급이 교차하는 지점에서 생존의 가능성을 점칠 수 있다. 이걸 무시하고 성장 가능성만을 놓고 이야기하는 건, 거품을 만들고 있다는 소리다.

위대한 개발문화를 위하여

Friday, May 11th, 2012

요즘 들어서 좋은 소프트웨어를 만드는 주요 요인으로 좋은 개발 문화를 이야기하는 경우가 많다. 이런 이야기를 들을 때마다 개발 문화가 무엇이길래, 소프트웨어의 품질을 좌지우지하는 것일까?라는 궁금증이 생긴다. 개발 문화가 중요하다면, 좋은 소프트웨어를 만들기 위해서 개발 문화를 좋게만 만든다면 모든 문제가 해결되는 것일까? 이 글은 단순하지만 답은 쉽지 않은 이 질문에 대한, 지금까지 나의 결론이다. 사실 결론이라고 말은 했지만, 어쩌면 이 글을 다 읽고 난 사람들은 새로운 의문이 생길지도 모른다. 그렇다 하더라도, 그런 의문과 의문에 대한 답을 찾아내는 과정이 여러분의 회사에 좋은 개발 문화를 조성하고 위대한 소프트웨어를 만드는 데 작은 보탬이 되었으면 좋겠다.

좋은 개발 문화를 이야기하기 전에 첫 직장에서의 경험담을 하나 소개하겠다. 오래 전에 내 블로그에서 소개한 적이 있는 일화다. 첫 직장 앞에는 넓은 화단이 조성되어 있었다. OJT 때 선배 사원이 그 화단을 횡단해서 다니지 말라는 주의를 주었다. 첫 직장에서는 통근 버스를 운행했는데 퇴근 시간에 맞춰서 나오면 버스 출발 시간에 맞추기가 빠듯했다. 그런데 그 화단을 가로 질러서 가면 시간을 상당히 많이 줄일 수 있었다. 그런데 그런 사람이 많았는지 화단을 무단횡단하다가 사장님의 눈에 띄면 좋지 않은 소리를 들을 수 있으니 조심하라는 게 선배의 조언이었다.

그 이야기를 듣고 며칠이 지났을 때 일이다. 여유 있게 나온다고 준비했는데 막상 회사 문을 나오고 보니까 버스 시간이 빠듯했다. 내 눈 앞에는 넓은 화단이 펼쳐져 있었다. 신입사원으로서 그 화단을 횡단하느냐 마느냐는 유혹에 시달리고 있었다. 그때 평소 안면을 트고 지낸 선배 사원이 내 옆을 지나서 화단을 유유자적 무단횡단했다. 선배 사원의 뒤를 쫓아서 나도 냉큼 화단을 무단횡단했다. 선배 옆에서 서서 넌즈시 물었다. 무단횡단하다 걸리면 안 좋은 소리 듣는다는 이야기가 있지 않냐고 말이다. 선배 사원이 내 질문을 받더니 원숭이 다섯 마리 이야기를 아냐고 물었다. 원숭이 다섯마리 이야기? 난 모른다고 답했다.

원숭이 다섯 마리를 이용해서 간단한 실험을 했다고 한다. 우선 우리 가운데 기둥을 두고 그 기둥 위엔 바나나를 묶어두었다고 한다. 그리고 원숭이 다섯 마리를 그 우리에 가두었다고 한다. 원숭이들 중에서 기둥 위에 매달린 바나나를 발견한 놈이 재빠르게 기둥을 타고 올라서 바나나를 먹으려고 할 때, 실험자가 그 원숭이를 향해서 센 물살이 나오는 물대포를 발사했다고 한다. 물대포를 맞은 원숭이는 기둥에서 떨어졌지만, 다른 원숭이가 다시 시도한다고 한다. 마찬가지로 다른 원숭이가 바나나를 낚아채려고 할 때, 다시 한 번 물대포를 쏴서 원숭이를 떨어트렸다고 한다.

이게 몇 번 반복이 되면 원숭이들이 더 이상 바나나를 따 먹으려고 하지 않는다고 한다. 더 이상 바나나에 도전하는 원숭이가 나오지 않으면 원숭이 한 마리를 꺼내고 물대포를 한 번도 맞아보지 않은 원숭이로 바꾼다고 한다. 이때부터 재미있는 현상이 일어 났다고 한다. 새로 들어온 원숭이는 바나나를 발견하고 따먹으려고 하는데, 물대포를 맞은 원숭이들이 이 원숭이를 한사코 말린다고 한다. 새로운 원숭이는 몇 번 시도하다가 무리의 제지를 받고 기둥 위를 오르려고 하지 않는다고 한다.

이런 식으로 물대포를 맞은 원숭이를 하나씩 바꾸면, 우리엔 물대포를 한 번도 맞아보지 않은 원숭이들로 가득 찬다고 한다. 그런데 흥미로운 건 이런 원숭이들이 물대포를 한 번도 맞아 보지 않았지만, 모두 기둥 위에 매달린 바나나를 따먹으려고 하지 않는다. 선배에게서 그날 들은 이야기는 상당히 충격적이었다. 그리고 그 이후로 직장문화나 조직문화, 개발문화 같은 것에 대해서 이야기하거나 생각할 때면 선배와 함께 금단의 화단을 횡단하며 들었던 원숭이 다섯 마리 이야기가 생각난다.

이 이야기가 신선하기는 하지만, 사실 누구나 한 번쯤 겪어보는 경험담을 원숭이를 통해서 재확인했다는 생각이 들 것이다. 즉 새로운 조직에 들어갔을 때 흔히 듣는 이야기나 충고가 여기에 해당한다. 새로운 조직에 들어가서 새로운 아이디어나 일하는 방법을 바꿔 보자고 제안을 하면 듣게 되는 이야기와 비슷하다. 말하자면, “짝 프로그래밍 해봤는데, 잘 안되더라고.” “코드 검토 해봤는데, 시간 낭비야.” “요구사항을 정리해도 결과는 똑같아” “그런 식으로 UI를 구성하면 사용자들이 싫어하더라고.”

물론 이런 이야기를 하는 사람 가운데 자신이 직접 경험해 보고 나서 하는 경우도 있지만, 물대포를 한 번도 맞아 보지 않은 원숭이가 동료 원숭이들의 만류에 기둥을 오르기를 포기한 것처럼, 조직 구성원의 이야기만으로 새로운 아이디어나 방법론을 구현하거나 적용해 보기를 포기한 경우도 많다. 우리는 흔히 이런 분위기가 팽배한 조직을 조직문화가 나쁘거나 개발문화가 부실하다는 평가를 한다. 사람이 자산의 전부라고 할 수 있는 개발회사에, 이런 학습된 무력감이 만연하다며 그 끝이 뻔하다.

이런 부정적인 개발문화를 타파해서 혁신적인 소프트웨어를 만들기 위해서 어떤 방법을 취할까? 흔히 개발문화를 바꾸기 위해서, 소프트웨어 프로세스 개선을 많이 한다. 비싼 돈을 들여 외부의 프로세스 전문가를 불러 프로세스를 개선하는 경우도 있고, 프로세스 개선 팀을 회사 내부에 만들어서 개발 팀의 프로세스를 고치는 경우도 있다. 이런 식의 해법을 찾는 이유는, 소프트웨어를 만드는 방법을 개선한다면 소프트웨어의 품질도 좋아질 것이라는 아이디어에 기초한 것이다. 이런 방법이 성공할 때도 있지만, 대개 원하는 결과에 미치지 못하는 경우도 많다. 왜 그럴까?

낙후된 문화 때문에 개발이 더딘 원주민들에게 선교사와 같은 사람들이 찾아와서, 당신들이 못 사는 것은 사는 방식이 잘못됐기 때문이라고 진단을 내린다. 그리고 삶의 방식을 바꾸는 매뉴얼을 만들어 주고, 그 매뉴얼대로 산다면 부자나라 대열에 낄 수 있다는 말을 남기고 자신들의 나라로 돌아간다. 매뉴얼을 받은 원주민 가운데 일부는 매뉴얼대로 살려고 노력하고 일부는 배부른 소리하고 있네,란 생각으로 원래 살던 대로 산다. 시간이 흐르면서 잘해보려고 하는 원주민들도 원래 삶을 고수하는 원주민들 때문에, 뭔가 바뀌는 것 같지 않아 포기하고 만다. 결국 선교사들이 남긴 매뉴얼은 저녁 식사를 위한 땔감으로 사용된다.

원주민과 선교사의 비교가 조금 지나친 감은 있지만, 우리가 흔히 프로세스 개선으로 얻게 되는 결과와 유사한 점이 많다. 물론 프로세스 개선을 지속적으로 하다 보면 깨우침을 얻는 원주민들이 늘어나 문화가 조금씩 바뀌기는 하지만, 그 변화의 속도가 매우 느리다. 왜 그럴까?

모든 변화의 근본적인 동기는 조직이나 개인의 안에서 나와야 한다. 흔한 자기 계발서에 나오는 이야기와 유사하지만, 현실이 그렇다. 아무리 좋은 프로세스, 방법론을 가져다 개발자들에게 설명한다고 해도 개발자가 실천하지 않으면 그만이다. 특히 오랜 시간 동안 학습된 무력감이 조직문화로 굳어진 개발회사에서, 외부에서 주어지는 계기로 무언가를 바꿔보려면, 조직의 관성을 이겨내야 한다. 그래서 외부의 전문가가 참여하는 프로세스 개선은 그다지 도움이 되지 않는다. 그렇다면 이런 조직에서 개발문화를 바꿔 보려면 어떻게 해야 할까?

개발자, PL, PM, 프로세스 컨설턴트로서 지난 직장생활 경험을 봤을 때, 개발 문화의 변화는 중간관리자가 가장 잘 주도할 수 있는 걸 체험했다. 팀원이나 일반 개발자일 때 변화의 바람은 개인의 울타리를 넘어서기가 힘들다. 말하자면 도전적인 원숭이 하나가 기둥 위에 달린 바나나를 먹을 수 있을 것 같은데, 대장 원숭이와 동료 원숭이가 쌍수를 들고 말리는 형국이다. 이런 조직적인 저항을 이겨내기란, 개인으로서 쉽지 않다.

하지만 울타리 안의 원숭이들을 움직일 수 있는 대장 원숭이라면 이야기가 달라진다. 원숭이들에게 미시적인 비전을 제시하고 구체적인 행동 지침을 내려 장기간 문화의 형태로 축적된 학습된 무력감을 이겨낼 수 있다. 대장 원숭이로서, 팀원 원숭이들에게 바나나를 혼자 힘으로 따 먹을 수 없지만 같이 힘을 합치면 가능하다는 미시적인 비전을 제시한다. 그리고 조직적으로 바나나를 따먹을 수 있는 전략을 도출한다. 예를 들자면 여럿 원숭이가 동시에 기둥을 올라서 물대포의 사선(fire line)을 분사시킨 후, 그중 가장 재빠른 원숭이가 바나나를 탈취해 내려오는 작전을 구상하고 실천에 옮기는 것이다. 만약 이런 성공경험을 우리 안에 원숭이들을 하게 된다면, 그들은 장기간에 걸친 패배주의적인 문화를 극복하고 더 나은 도전을 할 수 있을 것이다.

하지만 이런 변화는 우리 안에 원숭이들에게만 국한된 것이다. 다른 우리에 갇힌 원숭이들에게 이런 성공 체험을 전파하고 전체 원숭이 사회의 문화로 자리 잡기 위해서는 반드시, 우리를 넘어서는 지식 전파가 필요하다. 말하자면 우리 안의 성공은 개발회사로 치자면 하나의 부서나 하나의 프로젝트 팀에 해당한다. 이런 팀과 부서 내에서의 미시적인 성공이 조직 전체로 퍼져 나가기 위해서, 원숭이들을 조직화하고 움직일 수 있는 능동적인 다수의 대장 원숭이와, 그런 대장 원숭이를 등용할 수 있는 왕 원숭이가 필요하다.

지금까지 좋은 개발문화를 만들어내는 방법에 대해서 간단하게 살펴봤다. 그렇다면 이 글을 시작한 근본적인 질문, 좋은 개발문화를 갖고 있다면 좋은 소프트웨어를 만들어 낼 수 있을까?에 답을 찾아보자. 물론 좋은 개발문화를 갖고 있다고 해서 반드시 좋은 소프트웨어를 만들어내리라는 보장을 할 수 없다. 효율성과 효과성의 관점에서 봤을 때, 좋은 개발문화라는 효율성을 고도로 높이는 수단이다. 효율성이란 잘하는 것을 더 잘하는 것이다. 10을 들여서 10을 얻었다면, 효율성이 좋다는 건 1을 들여서 10을 얻는 것이다. 하지만 아무리 효율이 좋아 1원에 10개의 빵을 만들어내더라도 고객이 원하는 것이 맛있는 만두라면, 이 회사는 효과적이지 않은 것이다. 고객이 만두를 먹고 싶다는 걸 알아차리고 10원이 들더라도 1개의 만두를 만들어야 효과적인 전략을 구사한 셈이다.

좋은 개발문화를 갖고 있는 회사는 적은 노력으로 품질이 우수한 소프트웨어를 만들 가능성이 높다. 하지만 아무리 효율성 좋게 개발해서 제품을 만들었더라도, 시장이 반응하지 않는다면 그 회사는 좋은 개발문화를 갖추었지만 그다지 효과적으로 운영되지 않는 것이다. 이런 효과성의 문제는, 사실 이 글에서 다루는 주제가 아니다. 하지만 효율적으로 일하고 고객이 원하는 것에 많은 관심을 기울이려는 조직은, 더욱 효과적인 제품을 만들어낼 가능성이 높을 것이다. 이런 측면에서 보자면 좋은 개발문화를 갖고 있는 회사는 시장에서 장기적으로 위대한 소프트웨어를 만들어낼 것이다.

최근 들어 좋은 소프트웨어를 만들어내려면 좋은 인재를 양성해야 한다는 이야기를 많이들 한다. 실제로 이런 인력을 양성하기 위한 교육기관이나 프로그램도 많이 만들어지고 운영되고 있다. 그동안 인력난에 시달린 개발회사들에 반가운 소식이 아닐 수 없다. 하지만 이런 생각도 든다. 우리나라에 세계에 자랑할만한 소프트웨어가 많이 나오지 않은 이유가 단순히 인력이 부족했기 때문일까? 그동안 배출된 개발 인력을 잘 활용한다면, 정부나 기업에서 원하는 좋은 소프트웨어를 만들어낼 수 있지 않았을까?

결국 이런 질문을 하다 보면, 개발 문화의 중요성에서 그 해답을 찾게 된다. 학습된 무력감에 시달리는 조직 안에 있다 보면 대다수가 어느새 패배감에 젖어 든다. 하지만 그런 문화를 만든 것은 결국 개인의 합이다. 하지만 반대로 그런 문화를 타파하고 혁신을 이룰 수 있는 것도 개인에서 출발한다. 물론 패배주의에 빠진 조직 문화를 바꾸는 게 가능하다고 하지만, 적지 않은 노력과 시간이 필요하다. 낙후된 조직문화에 아무리 능력이 출중한 인재를 투입한다고 해도, 그렇게 모두가 원하는 좋은 소프트웨어를 얻을 수 없다. 그래서 개발 문화가 중요하다고 말했다.

결국 이 글을 끝까지 읽은 여러분이 개발문화의 중요성에 동의를 한다면, 어쩌면 이 생각에도 동의할지 모른다. 정말 위대한 개발 문화를 갖춘 회사라면 아주 평범하거나 역량이 부족한 개발자들로도 위대한 소프트웨어를 만들 수 있어야 한다. 어쩌면 뛰어난 인재로 뛰어난 소프트웨어를 만들어내는 것은, 위대한 회사가 아니라 평범한 회사도 할 수 있는 게 아닐까 한다. 결국 평범한 회사에서 위대한 회사로 변하는 그 중심에는, 위대한 개발문화가 꼭 필요하다는 뜻이다.

개와 소가 소스를 커밋하는 회사

Monday, March 5th, 2012

어떤 분이 소프트웨어의 품질을 높이려면 어떻게 해야 하는지 물으셨다. 이 분이 계신 조직에서는 오래 전부터 CMMI도 하고 애자일 방법도 도입하고 백방으로 소프트웨어 품질을 개선하려고 노력했다. 하지만 그 성과는 그다지 눈에 띄지 않는다고 하셨다. 지금도 이 회사에서는, 이 업계에서 알려진 좋은 방법을 적용하려고 시도하고 있고, 조직적으로도 어떻게 확산할지를 치열하게 고민하고 있다. 따라서 단순한 배경 지식만으로 이런 저런 방법을 쓰면 소프트웨어 품질이 좋아진다고 말하기란 쉽지 않다. 그럼에도 굳이 소프트웨어 품질을 개선할 출발점으로 괜찮은 게 무엇이냐고 질문을 한정 짓는다면,

개발자가 아무렇게나 커밋을 하지 못하게 하는 것

이라고 답할 것이다. 그리고 실제로 이렇게도 말씀 드렸다. 커밋에 대한 기준은 프로젝트마다 회사마다 다르다. 그리고 형상관리나 이슈관리를 쓰게 하는 것조차도 쉽지 않은데, 커밋을 개발자 마음대로 못하게 한다면 개발 못하겠다고 반기를 들 개발자도 무척 많을 것이다. 하지만 다양한 방법으로 소프트웨어 품질을 개선하려고 했는데, 그 노력이 유효하지 않다면, 최후의 수단으로 커밋을 개발 품질을 지키기 위한 마지막 방어선으로 삼는 게 좋다.

커밋이란, 소스를 개발자라는 개인영역에서 회사라는 공공영역으로 공개하는 것이다. 이때부터 생기는 문제는 개인의 문제가 아니라 팀의 문제고 회사의 문제가 된다. 따라서 커밋에 대한 정책이 명확하지 않은 회사는, 개발자에게 개인의 영역과 공공의 영역을 구분하지 않고, 개인에게 소스 코드의 품질을 전적으로 맡기겠다는 뜻이다.

커밋을 관리하지 않으면, 개발자는 대개 자신이 맡은 영역에서 문제가 생기지 않으면 커밋을 한다. 이렇게 아무런 관리도 받지 않고 커밋된 소스는, 다른 개발자가 소스를 업데이트 받아서 컴파일할 때 문제가 생긴다. 컴파일 시 문제가 당장 생기지 않아도, 통합하면서 기능이 잘못 구현되어 새로운 버그가 생길 수도 있다.

커밋할 때 조건을 까다롭게 걸 수도 있다. 조건 커버리지나 MCDC 커버리지 몇 퍼센트 이상 만족이라는 높은 단위테스트 기준과, 각종 품질 메트릭 수준을 만족했는지, 동료 검토를 받았는지 등의 모든 품질 기준을 커밋 때마다 확인받을 것을 회사 정책으로 삼을 수도 있다. 하지만 이건 어느 정도 수준이 되는 회사다. 국내엔 이런 회사가 거의 드물 것이다.

이런 복잡다단한 커밋 조건이 부담스럽다면, 동료 검토 정도를 커밋의 기준으로 삼아도 코드 품질은 확연히 달라진다. 내가 짠 소스를 동료들이 볼 것이라는 생각만으로 발 코딩을 하기란 쉽지 않기 때문이다. 이런 자기 절제의 메커니즘 말고도 검토는 코드 품질을 개선하는 효과를 준다.

소프트웨어는 하드웨어 개발과는 다르다는 말이 있다. 그래서 제조업체의 품질관리처럼 소프트웨어의 품질 관리를 할 수 없다고 한다. 나도 이 말에는 어느정도 동감한다. 하지만 이 말은 어디까지나 품질관리의 방법에 관한 이야기다. 품질관리를 왜 하는지를 생각해 보면, 소프트웨어나 하드웨어의 분야에 관계 없이 품질을 관리해야 한다는 결론을 얻는다.

하지만 회사에서 개발자가 품질을 고민하지 않고 아무렇게나 소스를 커밋할 수 있다면, 회사에서 품질이 제대로 관리되지 않는다는 뜻이다. 그래서 어쩌면 누군가의 회사에서 견공과 우공이 소스를 커밋하고 있을지도 모른다는, 생각이 든다.