2009년 4월 8일 수요일

프로세스가 창의성을 저해한다고?

개발 프로세스가 창의성을 저해한다고 싫어하는 개발자, 관리자, 경영자를 종종 만나게 됩니다. 이들이 프로세스를 싫어하는 이유는 과거에 개발 프로세스 도입에 대한 실패의 경험이 있거나 그런 얘기를 종종 전해 듣기 때문입니다.

이렇게 개발 프로세스 도입에 실패하는 이유는 현실성이 없는 이론적인 프로세스를 도입하거나 회사의 역량 수준에 맞지 않는 프로세스를 시도한 경우가 많습니다. 또 인터넷이나 책을 통해서 배우게 된 프로세스를 따라 하다 보면 그 Context를 다 알지 못하고 형태만 비슷하게 흉내 내다가 실패하기도 합니다.

그럼, 그렇다고 프로세스가 없다면 창의성이 샘솟을까요?
개발프로세스가 제대로 갖춰지지 않은 회사는 대부분 각 개발자들의 개인 역량에 따라서 적절히 개발이 이루어지며 개발자들은 역할의 구분 없이 만물박사 식으로 온갖 업무를 처리합니다. 이러다 보면 항상 바쁘고 새로운 기술을 조사한다거나 참신한 생각을 할 틈이 별로 없습니다. 또, 멋진 아이디어가 떠올라도 마땅하게 Follow up할 방법이 없어서 아이디어를 떠올린 개발자가 북치고 장구치고, 경영층도 설득하고, 프로토타입도 만들어보고 시장 조사도 해보고 해야 합니다. 안 그래도 바쁜 마당에서 짬을 내서 또 새로운 아이디어를 Follow up하기는 정말 어렵습니다. 누가 무슨 일을 얼마나 하고 있는지 잘 파악이 안되므로 또 이런 일을 벌여서 괜히 성과도 없이 평가만 안 좋아 질까봐 포기하기 십상입니다. 또 아이디어 낸 사람이 총대를 매야 하기 때문에 그렇다고 기존의 업무가 줄어들지 않기 때문에 공식적으로 이런 활동을 안하려고 합니다.

하지만, 개발 프로세스를 잘 갖추고 있는 회사는 아이디어를 내기만 하면 일단 회사의 System이 이를 Follow up합니다. 일단 아이디어는 수면 위로 떠올라서 여러 사람과의 Review를 통해서 더욱 Refine되고 정식 절차를 통해서 Prototype을 만들고 마케터는 시장 조사를 하고 영업은 고객들의 의견을 수집해 옵니다. 관리자는 해당 개발자가 아이디어를 발전시킬 수 있도록 정식으로 업무를 할당해서 시간을 빼줍니다. 한마디로 개발자는 기술적인 것만 Follow up해도 됩니다. 물론 모든 아이디어가 제품화 되는 것은 아니지만, 이런 아이디어들이 10개 100개 모여서 성공하는 제품이 나옵니다.

결국 프로세스가 창의성을 저해한다는 생각은 무지의 산물이거나 잘못된 경험의 결과입니다.

문제는 회사의 몸에 딱 맞는 개발프로세스를 갖추는 것이 어렵다는 것입니다. 현재 개발을 어떻게 하고 있는지 조사를 해보면 제각각 일겁니다. 이것부터 통일해 나가면서 조금씩 바꿔가는 것이 스스로 해볼 수 있는 최선의 방법입니다.

2009년 4월 6일 월요일

이 정도도 안되면서 Peer Review를 한다고요?

소프트웨어 개발의 기초도 되어 있지 않으면서 무리하게 Peer Review를 시도하다가 실패하기 십상입니다.

개발의 체계도 전혀 없이 코딩위주로 개발을 하고 있다면 Peer Review할 것도 별로 없거니와 Peer Review를 통해서 공유의 문제와 품질을 향상할 수 있을 것으로 착각하는데, 이는 Peer Review를 너무 만만하게 보는 것입니다. 피아노 기초도 안되어 있으면서 쇼팽을 치려는 것과 같고, 기초 체력도 부족하면서 축구의 고급 기술은 배워서 무엇 하겠습니까? 그래서 히딩크가 강조한 것이 기초체력이지요.

Peer Review를 정상적으로 진행하려면 최소한 소스코드관리시스템과 버그관리시스템은 제대로 사용하고 있어야 하며, 스펙과 설계문서를 제대로 만들어야 하며, 코딩 컨벤션을 따라서 개발을 하고 있어야 합니다. 간단하게 2줄로 설명을 했지만, 이 정도의 역량을 가지고 있는 소프트웨어 회사는 흔하지 않습니다. 즉, 대부분의 회사들이 Peer Review를 시행할 준비가 되어 있지 않고, 억지로 시행한다고 해도 그 효과를 제대로 누리기는 어렵습니다.

스펙과 설계문서를 제대로 만든다는 의미는 이미 Peer Review를 모두 포함하고 있는 것입니다. 여기서 또 많은 개발자들이 스펙과 설계문서를 제대로 만들고 있다고 착각할 수도 있겠지만, 현실은 그렇지 않습니다. 필자의 경험에 의하면 많은 회사와 개발자들이 스펙과 설계문서를 만들고 있다고 착각을 하고 있습니다. 이에 관한 얘기들은 추후에 올릴 계획입니다.

이렇게 얘기를 하면 매우 비관적인 것처럼 보이는데 비관적인 것이 사실입니다. 굳이 거짓된 희망의 메시지를 전하고 싶은 생각은 없습니다. 현실이니까요. 이렇게 된 것은 개발자들만의 탓도 아니고 회사에서 제대로 된 개발 환경 및 교육의 기회를 제공했어야 하는데, 그렇지 못했고 많은 회사들이 그냥 개별 개발자들에 의존해서 주먹구구식으로 개발해왔고 뭔가를 시도하려고 한 회사들도 그렇게 좋은 성과를 낸 회사는 별로 없습니다. 

결론을 말씀드리면 그럼에도 불구하고 Peer Review를 시행하려고 노력하는 것은 의미가 있다고 할 수 있습니다. 하지만 그와 더불어서 개발의 기초를 닦기 위한 노력도 병행해야 합니다. 이미 개발을 잘하고 있는데 기초가 부족하다고 하면 기분이 나쁠 수도 있는데, 사실이기 때문에 말을 돌려서 하고 싶지는 않습니다. 코딩도 잘하고 꽤 근사한 제품도 만들어 내지만, 효과적인 개발의 체계를 갖추고 있지 못한 것을 사실입니다. 그래서 좀더 좋은 제품을 좀더 짧은 시간에 개발할 수 있는데 그렇지 못하고 개발자들은 제대로 성장할 수 있는 기회를 갖추고 있지 못한 것입니다. 

앞으로 개발자로서 10년, 20년 후의 모습이 그려지지 않는다면 소프트웨어 회사로서 제대로 체계를 갖추고 있지 못한 것이 확실합니다. 제대로 소프트웨어를 개발하기 위해서 우선적으로 해야 할 것이 무엇인지 생각해야 합니다.

2009년 4월 2일 목요일

Peer Review의 방해꾼들

Peer Review가 정말 중요하다고들 다들 생각할 것 같지만, 실상은 그렇지 않습니다.
Peer Review의 중요성을 알고 있는 사람은 정말 많은 경험과 깨달음을 얻은 사람이고 대부분은 Peer Review의 중요성을 모르거나 심지어는 노골적으로 또는 은연 중에 방해를 합니다.

Peer Review는 (이미 언급했지만), 소프트웨어의 결함을 줄이고 개발 비용과 시간을 절약하며, 개발자들 간의 정보와 지식을 공유하고, 개발자들을 성장시키며, 개발자들의 사기를 높여줍니다.

그런데, 결함을 줄이고, 비용과 시간을 절약하며, 지식을 공유하는 것을 싫어하는 개발자들이 의외로 꽤 많습니다. 공유를 통해서 자신만 알고 있는 지식이 빠져나가면 자신의 가치가 줄어들 것으로 생각하며 심각한 버그를 만들어서 자신만이 멋지게 해결하는 모습을 보고 싶어하고, 프로젝트의 일정을 항상 궁지로 몰아 넣고 자신이 이를 해결할 수 있는 유일한 사람인척 행동하는 많은 개발자들이 있습니다. 이러한 행동이 자신의 가치를 높여주고 자리를 보존해 준다고 생각합니다. 하지만 그 말로는 뻔하죠. 본인도 성장하지 못할 뿐더러 동료와 후배의 성장도 방해하고, 결국 실력은 부족한데 영향력만 유지하려고 하는 "정치꾼 개발자"로 전락하고 맙니다. 

회사들은 알고도 또는 모르고 이러한 개발자들에게 인질로 잡혀서 끌려다니곤 합니다.

Peer Review를 시행하면 이러한 개발자들의 방해에 부딪혀서 좌절하기 일쑤이며 이런 개발자들에게 동조한 관리자들도 방해자 노릇을 톡톡히 해냅니다. 프로젝트의 지연을 Peer Review의 탓으로 돌리기 일쑤이며 Peer Review의 성과를 평가절하 합니다. 또 영업부서가 고객이 Peer Review를 반대하기도 합니다.

이러한 방해꾼들을 극복할 의지가 회사에 없다면 Peer Review는 그림의 떡입니다. 즉 회사가 정말로 Peer Review의 필요성을 모르는 상태이거나 아직 이를 시행할 외적인 준비나 성숙도가 떨어진다고 볼 수 있습니다. 준비를 조금 더 해야겠죠? 

그럼 다음에는 Peer Review를 시행하기에 앞서서 준비가 되어야 할 것들에 대해서 알아보겠습니다. 

2009년 4월 1일 수요일

Peer Review의 치명적인 유혹

Peer Review는 익히 언급했다시피 가장 중요한 소프트웨어 개발 문화 중에 하나입니다.

그런데, Peer Review를 시행하다보면 경영층에서는 Peer Review를 평가에 이용하고 싶은 생각이 들게 마련입니다. Peer Review 시행자체를 권장하기 위해서 Peer Review 시행 여부를 관리자들의 평가 기준에 포함하는 것은 일리가 있지만, Peer Review의 내용을 평가에 반영하는 것은 자칫 부작용이 더 클 수도 있습니다.

평가에 반영 가능한 Peer Review 결과
  • Peer Review 실시가 잘 진행되고 있는지 관리자를 평가
  • 얼마나 많은 Peer Review에 참석해서 Peer Review에 기여를 했는지 개발자를 평가

평가에 반영하기 부적절한 Peer Review 결과
  • Peer Review에서 누가 결함을 많이 찾았나 평가에 긍정적으로 반영
  • Peer Review에서 발견된 결함의 수를 해당 산출물 작성자에게 부정적으로 반영
  • Peer Review 통계 데이터를 이용하여 포상 또는 제재

이처럼 Peer Review를 정착시키기 위한 활동은 좋으나, Peer Review 내용 및 그 통계를 관리의 목적이 아니고 평가와 상벌에 이용하면 통계는 왜곡되기 시작할 것이며 그 때부터는 통계도 의미가 없어지고, 직원들은 Peer Review를 피하게 될 것입니다.

Peer Review는 동료들간에 서로 같이 검토를 해 주는 것에 의의가 있습니다.

2009년 3월 30일 월요일

외주를 주면 된다고요?

"우리가 못하면 외주를 주면 된다."

이렇게 생각하십니까? 아니면 인력이 모자라거나 시간이 부족하여 외주를 주십니까?
대부분의 개발자라면 외주에 대한 쓰라린 기억이 있을 겁니다.

한 포탈업체가 인도에 포탈 시스템 외주를 줬다가 통째로 버리고 국내 업체에 다시 외주를 줘서 개발한 적이 있습니다. 그리고도 국내 업체에 질질 끌려 다녔었지요.

인도에 외주를 줄 때는 스펙을 제대로 전달 하지 못했고, 개발 기간에도 전혀 관리와 리뷰를 하지 않고 최종 결과물만 받아 본 사례입니다. 이런 케이스 많죠?

그리고 국내 업체에 외주를 줄 때도 자체적으로 기술을 보유하지 못하고 외주에 의존하다 보니 지속적으로 문제가 됩니다.

결국 스스로 만들 능력이 없는데, 외주를 주는 것은 성공할 확률도 낮고, 경험있는 외주 업체를 만나면 개발은 제대로 되더라도 질질 끌려다니기 일쑤입니다. 또한 외주를 주기 위해서는 분석능력과 관리 능력이 필수 입니다. 특히 해외 업체에 외주를 줄 때는 대단히 정교한 스펙문서(SRS 등)가 필요합니다. 따라서 대다수의 업체는 외주를 줄 능력이 없다고 볼 수 있습니다. 그래서 외주가 아니고 사람만 빌려오는 거죠. 옆에 앉혀놓고 같이 의논해가면서 개발하는 방법이 유일한 방법입니다. 소프트웨어 개발 생산성이 아직도 매우 낮은 수준에 머물러 있는 원인이기도 합니다. 

"스스로 잘 할 수 없다면 외주는 더 어렵다."

2009년 3월 28일 토요일

RSS Feed 업데이트 문제 해결

저는 RSS Feed를 위해서 Feedburner를 사용하고 있었습니다. 
오랫만에 Feedburner 사이트에 들어가서 이거 저거 보고 있는데, 3월초부터 제 블로그의 RSS Feed가 전혀 업데이트가 되고 있지 않았었습니다. 
그래서 TroubleShootize 메뉴에서 원인을 찾아봤습니다.


이걸 보니 3/11에 에러가 난 것이 발견이 되더군요. 
"Feed의 크기가 너무 크다."
"Maximum size는 512K다."

다들 알고 계신 내용인지 모르지만 저는 모르고 있었습니다.
기억을 더듬어보니 제가 그당시 Feed의 크기를 키우는 행동을 몇가지 한 것 같더군요.

첫째, RSS Feed를 부분 공개에서 전체 공개로 바꿨습니다. 여러분들이 글을 읽어 주는 것이 목적이므로 굳이 블로그에 들어오지 않아도 된다고 생각해서 전체 공개로 바꿨었습니다.

둘째, RSS Feed 갱신 개수를 10개에서 30개로 늘렸습니다.

셋째, 저는 OneNote를 이용해서 글을 작성을 하고 나중에 Copy&Paste해서 글을 올렸었습니다. 그렇게 하니 원래 글보다도 크기가 5배 이상 커지더군요. OneNote의 CSS가 너무 복잡해서 괜히 크기가 커지고 있었습니다.

이러한 3가지가 겹쳐서 3/11에 드디어 512K를 넘기는 일이 발생했습니다.

지금은 2,3번째를 수정해서 10개로 줄이고 복잡한 스타일의 글도 간단하게 수정해서 크기를 대폭 줄였습니다. 그러고 나니 RSS가 다시 업데이트가 되는 군요.

그동안 2주 넘게 RSS를 기다리신 분들께 죄송합니다. 

RSS Feed가 잘되는지 수시로 점검도 해봐야 겠어요. 앞으로는 Text Editor로 일단 글을 옮긴 후에 Plain Text를 블로그에 붙여 넣는 식으로 글을 작성해야 할 것 같습니다.

혹시 저와 같은 장애를 겪으신 분은 안계시나요?

마지막으로 옛날 Feed(http://feeds2.feedburner.com/softwaredev)를 사용하고 계신 분들은 
새로운 Feed인 http://feeds2.feedburner.com/allofsoftware 로 바꿔주시면 좋겠습니다. 블로그 이름을 바꾸면서 Feed이름도 바꿨는데, 지금은 괜히 바꿨다는 생각을 하고 있습니다. 옛날 Feed 구독자가 줄어들지 않아서 완전히 두개가 되어 버렸습니다. 

감사합니다.

2009년 3월 27일 금요일

Peer Review를 성공하기 위한 요소들

얼마 전에 "코드리뷰 정착이 어려운 이유"라는 글을 올린 적이 있습니다.

그에 대해서 codeart 님께서 코드리뷰에 대한 일반적인 방법론에 대해서 궁금해 하시더군요. 하지만 이런 방법론은 알면 도움이 되지만, 이것을 안다고 코드리뷰를 성공하는데는 별로 도움이 안됩니다. 하지만 몇가지 성공 요소는 생각해 볼 수 있습니다. 

이제부터는 코드리뷰보다는 Peer Review라고 하겠습니다. 사실 코드만 리뷰를 하는 것이 아니고 스펙문서부터 소스코드등 개발 관련된 산출물들을 다 리뷰를 합니다. 그리고 동료들간에 검토를 해 준다는 것이 중요한 요소입니다.

그럼 Peer Review를 성공하기 위해서는 어떻게 해야 하는지 한번 보죠.

첫째, 개발자들끼리 으쌰으쌰 해서는 성공하기 힘듭니다. 회사에서 정책적으로 Peer Review를 추진해야 합니다. 개발잘들끼리 한번 해보려고 하는 것은 Peer Review를 너무 우습게 본 겁니다. 그냥 시간 좀 내서 서로 리뷰해주면 되지 뭐 그렇게 어려울게 있어? 라고 생각하면 오산이죠. 일단 많은 시간을 빼앗기는 것이 가장 큰 장애물입니다. 처음에는 의욕적으로 시작했다가, 금방 시들해지게 됩니다. 아직 Peer Review가 정착되지 않은 회사에서 개발자들끼리 한번 시도해보는 것은 거의 대부분 실패합니다. 따라서 회사에서는 Peer Review 담당자도 지정을 해주고, 제도와 자원을 지원해야 합니다.

둘째, 개발일정에 Peer Review를 포함해야 합니다. 그러면 더 시간이 오래 걸린다구요? Peer Review가 조금만 정착이되어도 결국은 이것이 훨씬 시간을 더 절약해준다는 것을 알아야 합니다. 테스트 시간이 절약되고, 유지보수 비용이 절약되고, 후배들이 빨리 성장하고 여기저기서 중복된 코드를 만드느라고 헛되이 보낸 시간이 절약됩니다. 이는 너무 뻔한 것이기 때문에 Peer Review가 개발 시간과 비용을 얼마나 절약하는지 증명하라고 하면 허탈하죠.

셋째, Peer Review는 동료와 하는 겁니다. 강사가 학생들을 가르치는 것도 아니고, 고객에게 설명을 하기 위한 것도 아니고, 서로 리뷰를 하면서 결함을 찾는 겁니다. 여기에 집중해야 합니다.

넷째, 자주해야 합니다. 프로세스에 따라서 빡빡하게 진행하기보다는 수시로 동료들과 리뷰를 하는 것이 좋습니다. 언제든지 "이것 좀 봐줘"하면서 부탁을 할 수 있고, 짧은 시간을 내서 흔쾌히 봐주면서 차츰 적응해 가야 합니다. 많은 양을 몰아서 리뷰를 하게 되면, 쉽게 질려서 포기하게 되고, 모든 코드와 문서를 모든 개발자가 다 리뷰를 해야 하는 것은 아니니 수시로 적당한 동료와 리뷰를 하면 좋습니다.

적어도 이 네가지만 지켜도 Peer Review를 지속하는데 약간의 도움은 될 겁니다.

그런데, 왜 Tool에 대한 설명은 없냐구요? Tool이 리뷰를 대신해주지는 않기 때문에 Tool을 그렇게 심각한 요소는 아닙니다. Tool이 도움이 될 수는 있지만, Tool이 없다고 리뷰를 못하지는 않습니다.

위 조건을 보면 일단 첫번째에서 막힐 수 있습니다. 설령 회사차원에서 Peer Review를 시행하더라도, 촉박한 일정에 쫓겨서 쉽게 포기해버리기 일쑤입니다. 이런 상황이라면 Peer Review가 정착하기는 어렵습니다. 회사도 단단한 의지가 없다면 Peer Review를 정착시키는 대단히 어렵습니다.

이렇게 만만한 일이 아니기 때문에 회사의 개발 성숙도에 따라서 적절한 계획이 필요합니다. 처음부터 욕심부리면 금방 포기하게 됩니다.