소프트웨어 개발은 생산 공정인가, 창조인가?
류한석(피플웨어 운영자) 2005/12/01
글쎄, 이런 질문은 마치 "사람과 동물의 차이는 무엇인가?"와 마찬가지로 추상적이고 철학적인 질문이라고 할 수 있다. 하지만 사람과 동물의 차이를 구분할 수 있듯이, 소프트웨어 개발이 (공장의) 생산 공정인지 또는 (새로운 타입의 독창적인) 창조인지를 구분하는 것 또한 충분히 가능하다.
사람은 영(靈)적인 존재이다. 그것이 바로, 동물과 사람을 구분 짓는 핵심 요소이다. 사람은 영적인 활동을 한다. 단순히 의식주의 충족을 초월하여, 음악을 만들고 그림을 그리고 문학 작품을 창작한다. 그렇게 만들어진 작품들이 수세기를 거쳐 후대의 사람들에게까지 전달되어 감동을 주고 누군가의 인생을 바꾸기도 한다.
그렇다면 소프트웨어 개발은 어떠한가?
소프트웨어 개발을 생산 공정을 통해 물품을 만들어 내는 것, 또는 공사장에서 블루프린트 대로 건물을 짓는 것으로 보는 관점을 먼저 살펴보자. 해당 관점 하에서는 개발자(또는 엔지니어)를 대체 가능한 부품 내지는 공사장의 인부로 볼 수 있는데, 그러한 현실을 김국현씨의 풍자 만화(http://www.goodhyun.com)-추운 새벽에 장작불을 쬐며 일감을 기다리는 개발자를 향한 외침, "자바 2명 타요"-는 잘 담아내고 있다.
공사장의 십장(인부를 직접 감독하고 지시하는 사람)과 같은 마인드로 개발자를 관리하려는 매니저들이 있는 것이 사실이다. 그들은 통제를 원한다. 통제하지 않으면 부하 직원들이 일을 제대로 수행하지 못하거나, 또는 일하지 않고 농땡이를 피울 것이라고 생각한다.
전문가라 불리는 일부 사람들은, 제조업 및 토목/건축업과 같은 관점을 소프트웨어에도 그대로 적용하려고 한다. 그렇게 함으로써 불확실한 소프트웨어 개발을 좀 더 명확하게 통제하려는 희망을 갖고 있는 것이다. 수십 년 동안 그러한 희망을 갖고서 수많은 방법론과 기법이 만들어졌지만, 그 어느 것도 명쾌하게 문제를 해결한 적은 없다.
예를 들어, CMMI을 만든 IBM 품질관리자 출신의 와츠 험프리를 생각해보자. 그는 소프트웨어 개발에도 마치 공장에서와 같은 품질 관리 개념을 적용할 수 있다고 보고, 거의 모든 것을 정량적으로 측정하고 통제하고자 하였다. 팀원들에 대한 교육 등 사람에 대한 내용이 전혀 없는 것은 아니지만, 그 사상의 바탕에는 합리적인 프로젝트 상황을 전제하고 개발자들을 대체 가능한 부품으로 생각하는 컨셉을 담고 있다.
왜냐하면 CMMI에는 유능한 개발자와 평범한 개발자의 수십 배의 생산성 차이, 개발자들의 열정과 동기부여, 조직 역학 및 프로젝트의 사회/정치적 요인, 그로 인한 개발자들의 이직률 등에 대해서는 전혀 다루어지지 않고 있기 때문이다. 단기적 생산성이 높다 하더라도, 이직률이 높다면 결국 엄청난 손실이 뒤따를 것이다. 그런 것은 아무도 측정하지 않는다.
솔직히 대부분의 프로젝트는 기술적인 문제 또는 프로세스적인 문제 때문에 실패하는 것이 아니다. 예를 들어, 평범한 데이터베이스 응용프로그램은 수십 년 동안 만들어졌음에도 여전히 종종 실패한다. 프로젝트 실패의 주요 요인은 이해관계의 상충, 거짓 데드라인, 고객의 무모한 욕심, 핵심 개발자의 퇴사, 커뮤니케이션 문제 등 사회/정치적인 요인임을 우리는 경험에 의해 잘 알고 있다.
그러므로 생산 공정과 같은 개념으로 소프트웨어를 다루려고 하는 접근 방법은 대개의 경우 그 가치가 과대평가되어 있다고 볼 수 있다. 그러한 접근이 매력적이기 때문에 흔히 선택될 뿐이다. 그들은 말한다. "포드시스템(조립 라인 방식에 의한 양산체제)과 같은 체계를 구축하면, 마치 소프트웨어 개발을 생산 공정과 같이 통제할 수 있어요."
아, 관리자의 입장에서는 얼마나 매력적인가?
개발자들을 부품 취급함으로써 "김대리는 불량품이었어. 일주일에 80시간 일했다고 해서 금새 고장이 나다니. 고장난 김대리는 버리고, 좀 더 성능 좋은 새로운 김대리로 대치하자고."라는 식의 접근을 할 수 있는 것이다.
오해가 없기를 바란다. 필자의 이러한 말이 품질 관리 전부를 부정하는 것은 아니다. 소프트웨어의 특수성을 인정하고, 좀 더 사람 중심으로 품질 관리의 방향을 잡을 필요가 있다는 뜻이다. 개발자들의 역량과 생산성에 대한 가치는 진지하게 재평가되어야 한다.
프로젝트에 있어 수많은 사회/정치적인 요인은 무시한 채로, 통제 가능한 것처럼 보이는 일부의 요인에만 집중함으로써 프로젝트가 성공할 수 있다는 식의 주장은 실제보다 훨씬 과장되어 있다고 볼 수 있다.
프로젝트 착수는 대개 합리적이지 않으며 데드라인은 말도 안되며 예산은 부족하며 적절한 인적자원은 주어지지 않는다. 그러한 현실을 무시하고, 선한 사람들과 함께, 합리적인 일정, 적절한 예산, 명확한 목표를 갖고서 일한다는 전제를 통해 만들어진 방법론들은 전혀 경험이 없는 사람들에 의해 만들어졌다는 의심이 들게 한다.
이제, 창조의 관점에서 소프트웨어 개발을 생각해 보자. 아, 알고 있다. 물론 SI 프로젝트는 예술이 아니며, 체계적이고 정량적으로 관리될 필요가 있는 것이 사실이다. 하지만 소프트웨어 개발에 있어 SI만 존재하는 것은 아니다. 애플 아이튠스 또는 구글 데스크톱 같은 것도 있다. 그것들은 생산 공정의 통제 기법을 통해 언제든지 만들어질 수 있는 것인가? 그렇지 않다.
그러한 유형의 소프트웨어를 개발하는데 있어, 가장 중요한 요소는 개발자의 영감(靈感, 머리에 번득이는 신묘한 생각)이다. 그리고 그것을 기반으로 한, 동기부여와 창조적 실행력의 극대화이다.
물론, 어떠한 유형의 소프트웨어를 개발하는가에 따라 접근 방법은 다를 것이다. 크게 구분하여, SI성 소프트웨어와 영감에 의한 소프트웨어가 있다. 한쪽은 제조에 가까운 반면, 한쪽은 창조에 가깝다. 두 가지 속성을 모두 가진 소프트웨어도 있을 것이다. 중요한 것은 소프트웨어에는 한가지 유형만 있는 것이 아니라는 점이다.
현실에서 소프트웨어의 유형에 따른 특성 차이, 개발자들의 본질적 속성, 작업 환경, 창조력, 프로젝트의 사회학 등에 대한 내용은 흔히 간과되고 있다. 그 이유는 아마도 그것이 일반적인 경영학이나 사회학, 심리학에서 다루어질 수 있는 분야가 아니고, 그렇다고 컴퓨터 공학이나 소프트웨어 공학에서 다루어 질 수 있는 분야도 아니기 때문일 것이다.
결론적으로 말해, 필자는 소프트웨어 개발의 본질이 창조 작업이라는 것을 주장한다. 생산 공정의 개념을 일부 적용할 수는 있겠지만, 그것이 창조적 실행력보다 우선할 수는 없다.
왜 그럴까? 그 모든 개발의 시작과 끝이 모두 사람으로부터 시작하여 사람으로 끝나기 때문이다. 사람의 지적 능력과 정서, 기쁨과 희생을 통해 만들어진 결과가 바로 소프트웨어다. 우리는 소프트웨어 개발을 단지 생산 공정으로 바라보려는 통제적 관점을 경계해야 한다.
필자의 대안은, 기업들이 생산 공정 식의 투자보다는 개발자의 작업 환경을 개선하고 창조적 실행력을 극대화하고 자기계발을 독려하고 동기부여를 하는데 더욱 투자해야 한다는 것이다. 구글, 어도비와 같은 몇몇 기업들은 그것의 성공 사례를 명백히 증명하고 있다.
필자는 이 문제에 대해서 강의를 하든, 집필을 하든, 그 무엇을 하든 지속적으로 다룰 것이다. 그것이 바로 필자가 몸담은 소프트웨어 업계에 대한 깊은 애정을 증명하는 방법이라고 믿기 때문이다. @
덧붙여
최준열[ 2005/12/07 ]
사 실 구글 데스크탑도 창조성이 많이 반영된 SW이긴 하지만 구글 직원들은 '기간이 언제 까지이고 스펙은 이렇다'는 식의 지시를 받아 움직였겠죠. 제가 가장 이상적으로 보고 있는 케이스는 리누스 토발즈의 리눅스입니다. 그는 리눅스 커널 제작이 아닌 다른 것이 생업이기 때문에 리눅스에 대해서는 돈에 연연할 필요가 없죠. 일단 그런식의 '경제적인 자유'가 확보되어야 SW제작에 예술활동 개념을 접목할 수 있다고 생각합니다. 저는...SW개발이 아닌 다른 것이 생업이면서 SW제작은 예술활동의 일환으로써 해나가는 자유 프로그래머들이 리누스 토발즈 말고도 더 나와야 한다고 봅니다.
아래에 이어서
최준열[ 2005/12/07 ]
자 신이 구글 데스크탑 같은 걸 만들고 있다고 생각한다면...자신의 작업은 SI와는 다른 창조작업이라고 생각한다면, '최준열씨, 납기일은 12월 24일입니다'와 같은 방식으로는 힘들지 않을까 생각합니다. 뭐랄까...저도 아직 명확한 결론을 내리지 못했지만, SW창조작업을 좀 더 예술적인 관점에서 바라볼 필요가 있는 것 같습니다 (SW의 성격에 따라).
오픈소스가 일시적인 대안이 될 수 있지 않을까요?
최준열[ 2005/12/06 ]
쩝, 저도...떠오르는 영감으로 어떤 SW를 창조했다가 그 이후과정을 어떻게 처리해야 할 지 난감해서 SW를 공개해 본 경험이 있습니다. 만약 제가 그 SW의 가치를 제대로 평가받기 위해 무리한 노력을 했다면 아마 상당한 출혈만 안고 자멸하지 않았을까 생각하는데요. 당시의 저는 따로 수입원이 있었기 때문에 SW자체는 공개하는 쪽을 택했고 반응은 매우 좋았습니다. 물론 SI 비즈니스에 오픈소스 개념을 적용시키는 것은 무리일 거라고 생각하고요, 패키지 제품이라면 제 생각에 이 방법이 매우 좋다는 생각이 듭니다.
기존의 비즈니스 모델은 제로자본에서 출발해서 차입을 통해 자본을 확보해서 마케팅 활동을 통해 SW의 좋은점을 무리하게 시장에 어필하고 소비자가 SW를 구매하도록 무리하게 드라이브 하는 방식인데요...다른 수입원이 있어서 돈에 구애받지 않는 상황이라면, 오픈소스 프로젝트가 제품의 가치를 시장에 알리는데 매우 효율적인 방법이라는 것입니다. 제 경우엔 공개된 웹 사이트가 제가 운영하는 것이 아니었기 때문에 공개비용(또는 홍보비용)이 제로였는데요...저 자신은 100원도 안 쓴 상태에서 1달만에 1000명의 유저가 제 SW를 사용하게 되었고 금새 시장이 제 SW의 가치에 반응하게 되었습니다.
인물의 포즈를 자동으로 생성해 주는 SW인 poser라고 아시는지 모르겠습니다. 일본의 만화가 중에 poser를 써서 만화를 그리는 사람도 있는데요, poser도 처음엔 오픈소스로 출발했다가 나중에 사업화 되었는데 시장에서 매우 성공적인 SW로 평가받고 있습니다.
소스를 콱 움켜진 상태에서 '반드시 돈을 얼마 내야 이것을 쓰게 해주겠다'는 과거의 패러다임보다 훨씬 효율적인 방식이라고 저는 믿고 있습니다. 왜냐하면...오픈이라는 것 자체가 유저들을 금새 모여들게 하는 강한 동기가 되기 때문이죠. 그렇게 해서 오픈된 상태에서 시장의 신뢰를 빠른 시간에 얻고 나면 그 때 가서 이익을 추구하기 위한 추가 상용판을 제작해도 늦지 않다고 생각합니다. 그 때는 어느 정도 시장의 흐름을 타고 있는 상태에서 제작하는 것이기 때문에 훨씬 일이 수월하게 풀리죠.
소프트웨어 업계의 비젼..
이준형[ 2005/12/06 ]
저도 나름대로 소프트웨어 업계에서 살아온 사람으로써 한마디 거들지 않을수 없어서.... 애써 로그인 까지 해가면서 이 글을 적습니다.
리플을 다신 많은 분들도 공감 혹은 반박을 하기 위해 글을 쓰셨겠지만, 결국 근본적인 원인은 측정되어 지지 않는것에 있다고 생각합니다. 프로그래밍도 디자인과 같이 상대적인 가치와 우위를 판단 할 순 있지만 그것이 최고이거나 몇점 이라거나 평가하기가 어렵기 때문에 CMM과 같은 건설업계에서 사람 다루듯이 해서는 안된다고 보여 집니다. 하지만 역시 안타까운 문제는 많은 인재들이 이렇듯 적절하게 평가되어지지 않는 현실에 몸서리를 치며 키보드를 놓곤 한다는것에 있다고 봅니다. 다들 입모아 상품에는 디자인이 중요한 요소라고 생각하면서 검증되지 않은 디자인은 천시하는 경향이 있습니다.
소프트웨어 업계에도 과기처 단가와 같이 형식적인것 말고 그 사람의 가치를 판단해 줄수 있는 평가 기준이 꼭 공정하게 만들어 지기를 바랍니다.
잘해준다고 창조성 up? 그 반대입니다.
몽몽이[ 2005/12/05 ]
잘해준다고 창조성 up? 절대 그렇지 않습니다.
사회에서 엔지니어는 부품이고, 부품이 능동적인 활동을 하는 것에 대해서는 프로세스 자체가 없으며 Nonsense하게 만들어버립니다.
창조적인 놈 뽑으라고 말하는 그들조차 기껏해야 싸구려 치기에 버릇없는 놈 뽑는거랑 구별도 못합니다.
문제는! 이런 당연한 사회현실이 문제가 아니고... 이미 엔지니어라는 생물들이 거기에 적응했다는 겁니다. 술한잔 얻어먹으면 해피하고 교육보내면 의례 자야하고... 호시절엔 그것도 지겹더라는 말을 태연하게 하지요...
잘해주지 않아서 창조가 안되는게 아니라... 이런 쓰레기들을 죽이지 않아서 창조가 안됩니다...
참고로 전 공공SI만 피터지게 하다... 돈 좀 벌어보겠다고 투자 좀 받는 신규 부서로 옮긴 사람인데, 이때다 하고 내일도 없이 사는 자칭 엔지니어들을 보고 저것들 먹여살리느라 내가 그 고생을 했던가 하고 치를 떠는 사람입니다.
물론 모두 줗은 의견들입니다.
sosteam[ 2005/12/05 ]
정말 좋은 그러나 조금은 어려운 내용의 의견들을 잘 읽었습니다. 같은 고민을 하시는 분이 많아 정말 기분이 좋았습니다.
하지만 제가 성격이 급해서 그런지 계속적인 좋은 의견이 구체적인 액션 플랜으로 어떻게 이어져야하는지 읽어봐도 모르겠습니다.
이런 질문 조차도 하늘에 별따기식 질문이 되어 버릴 수 있겠군요.
그럼 구체적으로 예를 들어보면 프로젝트 발생 시 SI가 아닌 업체에서 견적과 데드라인을 어떻게 정해야 할까요? 과기처 방식으로? 오래된 LOC 방식? 아니면 그 회사 내부의 방침으로? 어떤 구체적인 대안이 나오기 너무 힘듭니다.
컨설팅을 해주는 업체는 CMMI 같은 인증을 받을 수 있는 방법을 제시 해줍니다.
관을 먼저 산 후 사람을 끼워 맞추는 거죠.(산사람을 넣으면 많이 아프겠죠 )
이런 방법은 비 공식적 WBS 작성을 낳게 되고, 공식적인 WBS는 마치 제대로 진행되고 있는 양 속일 수 밖에 없습니다. 정말 답답한 회사라고 생각하실 수 있지만 그게 현실입니다.
견적 이외에 인스펙션 같은 예를 들어도 좋습니다. 인스펙션을 표준 방침대로 한다면 납기일을 맞출 수 있을까요? 게다가 효용성 있는 인스펙션에 대해서 나와있는 방법이 있을까요?
많은 것을 고려해서(인간적인 것 포함) 공정을 만들어가면된다는 것은, 다른 말로 공정이라는 자체가 필요없다는 얘기와 같습니다. 즉 모든 프로젝트는 시작할때 그 공정이 항상 새롭게 만들어지는 것입니다. PM의 역량과 건강상태, 업무내용과 프로그래머들의 친밀도, 각자의 성격과 가정환경까지도 그때 그때 따라 달라지는 것이죠. 심지어 몇월에 프로젝트가 시작되느냐에 따라 달라지죠 추석이 있는 달인지, 연말 연시인지, 인사철인지.
프로그램 공정은 인간의 생활을 문서화 하는 작업입니다. 인간의 생활을 문서화 하는 것은 마치 가능하게 보이기도 하겠지만 별로 하고 싶지 않은 작업임에는 틀림없습니다.
몸에 맞는 프로세스의 중요성
류한석[ 2005/12/05 ]
제가 지면 관계상 충분히 언급하지 못한 내용들이, 독자님들의 피드백을 통해 많이 다루어져서 기쁩니다. ZDNET에는 정말 수준 높은 독자님들이 많다는 사실을 다시 한번 실감하게 되었습니다.
가을하늘님의 말씀처럼.. 창의성과 동기부여를 훼손하지 않는 범위 내에서, 즐겁게 일할 수 있는 프로세스와 규범의 확립은 중요합니다. 의견에 동의하며, 그러한 균형 감각을 갖춘 조직이 많아지기를 기원합니다.
제대로 된 공정없이 제대로 된 제품이 가능한가?
가을하늘[ 2005/12/04 ]
사 실 국내에서 소프트웨어 제품 - SI가 아니라 - 을 개발하는 회사 중 제대로 된 소프트웨어 개발 프로세스를 갖고 있는 회사는 별로 없으리라 생각된다. 아무리 창의적인 생각도 그것이 제품으로 나타나고, 시장에서 매번 사람으로 때우는 SI가 아니라 외국 제품과 품질로 승부할 수 있는 제품이 되려면, 그리고 수년 간 제품이 버전업되고 유지보수되려면, 요구분석, 설계, 구현, QA 테스트, 버전 컨트롤, 버그 트래킹 등 기본적인 공정없이는 가능하지 않다. 나는 도리어 제대로 된 국내 소프트웨어 제품이 별로 없는 것이, 반짝이는 창의적인 아이디어가 부족해서가 아니라 제대로 된 제품을 만드는 소프트웨어 개발 프로세스를 제대로 익힌 소프트웨어 개발자가 별로 없기 때문이라고 생각한다. 공정은 말 그대로 기본적인 틀일 뿐이다. 개발 프로세스 안에서 얼마든지 개발자의 창의력과 경쟁력을 발휘할 수 있다. 탁월한 제품기획자, 탁월한 분석가, 탁월한 architect, 탁월한 trouble shooter, 탁월한 아이디어맨, 탁월한 QA engineer, 탁월한 PM, 이러한 사람들이 모여 개발프로세스를 움직여야, 재미있게 일할 수도 있고, 정말 좋은 제품도 나올 수 있다. 적절한 개발프로세스는 제대로 된 제품을 위한 필요 조건일 뿐이다. 소프트웨어 개발프로세스 하면 CMMI를 떠 올리시는 분들이 있을지도 모르겠다. 나는 CMMI가 소프트웨어 제품 개발에 필요하다고 생각하지 않는다. 몸에 맞는 개발프로세스를 만들고 적용하는 소프트웨어 회사가 계속 많아지기를 바란다.
수준높은 글과 리플들에 감동
김홍석[ 2005/12/04 ]
마침 제게 필요한 글이 올라와 감사합니다.
그리고 밑의 수준높은 리플들 또한 많이 도움이 되는군요..
류한석님뿐 아니라 홍형경님, 조동환님, sosteam님의 리플들이
저에게 많은 생각을 하게 해주네요..
저희 회사도 이번에 CMMI를 땄습니다..
형식에서는 배울 점이 많다고 생각되었지만
실제 업무에 도움이 되는 지는 정말 계속적으로 의문이 들더군요..
이 글을 읽고야 깨달았습니다...
문제는 인간.. 그리고 창의성이 배제가 되었던 겁니다..
제가 추구하는 것은 창의성이 먼저지 생산성 먼저가 아니었다는 걸
절실히 느꼈습니다..
그런데 또 이런 생각들도 들더군요..
그런 창의성을 제대로 키워주고 발휘할 수 있는 회사가 우리나라에 있을까..
그리고 CMMI를 제대로 도입해서 업무에 도움되는 곳이 있을까..
정확한 시간측정으로 인해 무모한 과로 업무를 줄여주고
정당한 보수를 지불한다면 그것만으로도 충분하리라 생각되는데..
하는 생각들이요..
수준높은 글과 리플들에 감동
김홍석[ 2005/12/04 ]
마침 제게 필요한 글이 올라와 감사합니다.
그리고 밑의 수준높은 리플들 또한 많이 도움이 되는군요..
류한석님뿐 아니라 홍형경님, 조동환님, sosteam님의 리플들이
저에게 많은 생각을 하게 해주네요..
저희 회사도 이번에 CMMI를 땄습니다..
형식에서는 배울 점이 많다고 생각되었지만
실제 업무에 도움이 되는 지는 정말 계속적으로 의문이 들더군요..
이 글을 읽고야 깨달았습니다...
문제는 인간.. 그리고 창의성이 배제가 되었던 겁니다..
제가 추구하는 것은 창의성이 먼저지 생산성 먼저가 아니었다는 걸
절실히 느꼈습니다..
그런데 또 이런 생각들도 들더군요..
그런 창의성을 제대로 키워주고 발휘할 수 있는 회사가 우리나라에 있을까..
그리고 CMMI를 제대로 도입해서 업무에 도움되는 곳이 있을까..
정확한 시간측정으로 인해 무모한 과로 업무를 줄여주고
정당한 보수를 지불한다면 그것만으로도 충분하리라 생각되는데..
하는 생각들이요..
생산공정도 변하고 있다..
홍형경[ 2005/12/01 ]
생 산공정적인 면에서 본다면, 과거의 대량생산 방식에서 쓰이던 방법은 분업형태였습니다. 생산라인에 각 작업자들이 쭉..나열해 있어 라인이 돌때마다 자기가 맡은 공정처리를 했었지요. 이러한 방법이 예전에는 꽤 생산력도 좋았고 불량품을 줄이는데도 기여를 했다고 합니다. 하지만 이 방법의 단점은 라인이 정해진 속도로 돌아가다 보니 초보자는 따라가기 힘들고, 숙련자들은 능력을 발휘할 기회를 없앴습니다.
얼마전 일본에서 Cell생산방식 이란것이 나왔습니다. 몇 명이 팀을 짜서 그 팀이 하나의 완제품을 생산하는 것이지요. 캐논이 처음 도입했다 합니다. 초기에는 한 팀에 30명이 투입되었는데, 몇달 지나니 20명, 최근에는 6명이 한 팀을 구성한다고 합니다. 그 6명이 복사기 한대를 다 조립하는 것이지요. 이러한 방식의 차이점은 뭘까요? 한 마디로 복사기만드는데 전문가를 키운다는 것입니다. 이 회사의 어떤 사람은 1만개가 넘는 부품으로 구성된 복사기를 불과 14시간에 조립하는 장인(마이스터)도 배출했다고 합니다. 속도뿐만 아니라 다른 여타 지식이나 노하우는 말도 꺼낼 필요가 없겠지요.
결국은 아무리 좋은 방법론이 나오거나 좋은 프레임웍이 나오더라도 결국 일은 사람이 하는 것입니다. 아직까지 우리나라 환경은 이러한 풍토를 만들지 못하고 있습니다. 제 개인적 생각으로는 시간이 지날수록 점점 더 나빠지고 있다는 생각이 드는군요.
넓으신 아량에 감탄...
조동환[ 2005/12/01 ]
미 디어에서의 여론은 항상 흑백논리거나 마녀사냥식이 많습니다. 무언가 다른 의견을 내놓는 사람들은 무시당하거나 심하게 취급받는 경우가 많습니다. 정치적인 이슈나 사회적인 이슈는 그럴 수 있다고 생각해도 이런 공학적인 이슈까지 그럴 필요는 없다고 생각합니다. 하지만 너무도 그런 식의 사고에 익숙해져버린 우리이기에 항상 의사결정이나 판단을 내릴때 일부만 보고 전체를 예단하는 실수를 하는 것 같습니다.
말씀하신대로 계량적으로 흐르는 통제주의는 인간본성에 대한 이해가 부족한 면에서 많은 부분 비롯되는 것으로 생각됩니다. 제가 존경하는 심리학자이신 미하이 칙센트미하이교수가 지은 "몰입(Flow)"이라는 책을 보면 과연 개발자나 지식노동자가 행복해지기 위한 것에 대해 implication을 얻을 수 있다고 생각합니다.
약간 거칠었던 댓글을 너그럽게 받아주신 아량에 감탄하며, 앞으로도 더 좋으신 글과 통찰력 깊은 의견개진 부탁드리겠습니다.
언제나 중요한 것은 "균형감각"
류한석[ 2005/12/01 ]
조동환님의 의견에 동의합니다. 언제나 중요한 것은 균형감각, 즉 밸런스입니다.
실제로 저도 프로세스 관련 글을 쓰고 그런 일을 하고 있습니다. 너무 계량적으로 흐르는 통제주의에 경종을 울리고자 쓴 글이니, 흑백논리는 아님을 이해해주시기 바랍니다.
좋은 의견 감사합니다. *
제 의견은 이렇습니다
조동환[ 2005/12/01 ]
우 선 의견을 올리신 sosteam님 및 속하신 회사께 위로의 말씀을 드립니다. 국내에서는 CMMI를 ISO9000처럼 "따야" 할 것으로 다루는 업체가 대다수인 것은 사실입니다(특히 SI, 방산등) 제가 7여년 넘게 소프트웨어프로세스개선을 포함한 기업내부컨설턴트로 일하는 동안 깨달은 사실은 “모델은 모델일뿐이다”라는 사실입니다. 즉, 개선의 방향성에 대해 힌트를 얻는 정도로 사용하는 데에는 최상의 도구(모델, CMMI)이나 세상의 모든 문제를 해결해주는 silver bullet으로 사용한다면 그 총알으로 스스로의 머리를 겨누는 것과 다름이 없습니다.
예를 들어, requirement management나 project planning도 제대로 해내기 위해서는 정말 많은 질문을 스스로(기업내부경영자, 개발자, 관리자)에게 진지하게 던져보아야 합니다. 도대체 우리가 달성하고자 하는 비즈니스목표는 무엇인가? 빠른 Time To Market인가, Reliability(Quality라는 용어는 너무 포괄적이므로 사용치 않겠습니다)인가, 아니면 Risk를 Minimizing하는 것이냐에 따라 아주 심플한 프로세스와 템플릿으로도 가능할 수 있고 아니면 아주 정교한 프로세스와 툴의 뒷받침이 필요할 수도 있습니다. 핵심은 경쟁자를 철저히 부셔버리고 따돌려버리기 위해서는 우리는 무엇을 해야하는가를 스스로에게 진지하게 물어보는 것입니다.
이것을 기업외부의 Lead Assessor가 1~2개월의 Assessing으로 수준을 판단하고 6개월~1년사이에 하나의 레벨을 올린다는 것은 거의 사기에 가깝습니다. 제가 모자른 탓도 많겠지만 제가 서비스하는 회사에서는 2~3개의 프랙티스(프로세스가 아닙니다. 훨씬 작은 범위입니다)만을 집중적으로 철저히 개선하고 변화시키는데 4년가까이 걸렸습니다. Software Product Engineering의 V&V중 Software Testing을 제대로 셋업하는데는 앞으로 5년이 더 걸릴지도 모릅니다.
다시 정리해서 말씀드리면, 흑백논리는 위험하다는 것입니다(이부분부터는 류한석씨께 드리는 말씀). 디마르코가 강조하는 포인트에서 반드시 배워야 하는 포인트가 있는 반면에 험프리나 기타 품질 GURU들에게 배워야 하는 포인트도 있다고 생각됩니다. 예를 들어, 창조성 부분은 Requirement Development부분에 훨씬 더 잘 적용되는 개념입니다. 즉, Research side에 더 많이 필요한 부분입니다. 하지만 개발이 진행되어 실제 개발(Development) side에 가까워지면 철저한 관리, 꼼꼼함이 더 중요한 부분이라고 생각됩니다.
유명한 학자의 말을 인용하는 것은 자신의 논리를 펼치는데 있어 비겁한 일일 수도 있지만 지식근로자에 대해 통찰력있는 글을 많이 쓴 피터 드러커의 말을 인용해보면, 지식노동자의 작업도 무조건 창조적이라고 싸잡아 이야기 할 수 있는 것이 아니라 3가지 부류가 있다고 합니다: 1) 작업품질이 작업량보다 훨씬 중요한 카테고리(즉, 신약개발이나 예로 드신 구글이나 애플?) 2) 작업품질과 작업량과 균형을 이루어야 하는 하이브리드 카테고리 3) 작업량이 중요한 육체노동에 가까운 카테고리(즉, 보험업무처리나 Call Center의 Caller등)
소프트웨어의 개발프로세스와 해당 기업이 시장에서 처한 상황, 기업내부의 기업문화를 고려하여 작업생산성(창조성을 포함한)을 최대한으로 높일 수 있는 방안을 고민하여 지속적으로 개선하는 것이 정말 경쟁력을 확보할 수 있는 방법이지 모든 참조가능한 선례와 지식을 부정하고 단지 현재 결과가 좋으니깐 당연히 우리의 방법이 좋다라고 하는 것은 논리의 비약이 좀 심한 것 같습니다.
참고적으로 “한국형 생산방식, 그 가능성을 찾아서”라는 제조쪽의 글의 논리를 보아도 한국사람들이 특히나 잘하는 것이 있다 그것을 무시하고 무조건적으로 외국의 방식을 따르는 것은 자신의 강점을 스스로 버리는 행위다라고 하고 있습니다. 저도 그부분에 있어 전적으로 동의합니다. 허나 그 한국적 방식이 시간을 거듭하면서 발전하거나 타인에게 전수가 가능하지 않는 것이라면 그 회사나 국가의 경쟁력을 계승발전시키는데 무슨 소용이 있겠습니까 (실제로 한국의 반도체 공장들은 생산성에 있어 세계최고이지만 다른 외국의 공장을 설립하는 경우 한국의 핵심기술자가 파견되지 않으면 셋업자체가 불가능하다고 합니다. 자동차공장도 마찬가지 상황이라고 합니다)
결론적으로, “창조적”+”체계적”은 항상 서로 피드백을 주고받고 Trade-off해야 하는 요소라고 생각됩니다. 그리고 그 최적점은 경쟁환경하에서 항상 바뀌므로 기업은 항상 변화하고 개선하고 노력해야 경쟁력을 지닐 수 있다고 생각됩니다.
거의 모든 분야에 대해 적용가능한 글...
최준열[ 2005/12/01 ]
사 실...지구의 모든 조직들이 인간이 영적존재라는 것을 간과하고 인간을 계량적으로 관리하려 들고 있지 않습니까? 학부시절에 '허구헌날 회로책만 보다가 졸업하면 안 되는데' 싶어서 경영학과 수업을 좀 수강했던 적이 있습니다. 정말...어처구니가 없더군요. 인적자원관리(HR Management) 책 보니까 저자는 영적인 존재들의 동기부여라는 테마에 대해 거의 아무런 관심도 없음을 알 수 있었습니다. 연봉제가 어떻다 성과급제가 어떻다 전부 수치적인 이야기(거의 급여에 관련된) 뿐이었죠.
마케팅 이론서적들도 그래요...인간은 영적인 존재이고 사람들(소비자들)이 그 시대 그 시대 어떤 상품을 원하는가는 그 시대의 영혼들이 마음으로부터 뭘 원하고 있었는가 오로지 그것밖에는 없는데, (가령 영혼들이 독점적인 매스컴의 횡포에서 벗어나고 싶어했고 자기가 원하는 정보를 마음대로 탐색하길 원하기 시작했기 때문에 PC혁명, 인터넷 혁명이 급물살을 탔던 것처럼) 책이 죄다 누구의 공식 누구의 공식 어쩌고 하면서 수치적인 이야기만 해대고 있었습니다. 세파에 시달리며 사람들과 함께 부대껴 본 적도 없으면서 저명한 교수님들이 방에 틀어박혀 상상만으로 책을 집필하고 있었던 거죠. 아 정말...뭔가 북받쳐 오르는 필이 오는군요 -,.-
저에게 방송활동을 할 수 있는 기회가 주어진다면 이런 걸 좀 공개적으로 다뤄보고 싶은데...삼성을 보세요. 자기 딸이 뭘 원하는지도 몰라서 혼자 죽게 한 사람이 직원들 한사람 한사람의 마음을 어떻게 알 수 있겠습니까? 우리 사회 정말 문제가 한두가지가 아닙니다.
절대 동감입니다.
sosteam[ 2005/12/01 ]
(좀더 수정 보완해서 삭제 후 다시 올립니다.)
우리회사도
CMMI 땄습니다.
어떻게되었을까요?
관리자분들만 좋아합니다.
고객은 자전거타고 빨리 가려하는데
우리는 뛰어서 갑니다.
예전에는 같은 속도를 낼때도 있고 때론 더 빠를 때도 있었습니다.
CMMI 후에 현저하게 차이가 납니다.
이젠 뛰다가 점점 지쳐갑니다.
부작용이 생깁니다.
개발자들은 이제 더이상 창의적인 생각을 안합니다.
문서 쓰고 결재 맡아야 하고. 책임 추궁 당하기 딱 좋습니다.
시키는일만 하고 문서 올리면 일 잘하는 사람되니까 창의적인 생각은 이제 별 필요 없습니다.
CMMI에서 가장 중요한것은 무엇인지 아십니까?
바로 시간안에 프로그램을 완성하는 것입니다.
누군가 기다리고 있는 사람이 없어도
얼마나 완성된 모습을 보이느냐..
얼마나 참신하냐는 중요하지 않습니다.
시간안에 만드느냐가 중요합니다.
소프트웨어를 짤때의 짜릿함은 이제 온데간데 없습니다.
소프트웨어 사대주의의 온상이 바로 CMMI입니다.
어떤회사는 레벨 5를 땃다고 하더군요.
그런 소식을 들을 때마다 정말 가슴이 메어집니다.
우리나라 업체 하나 소프트웨어 무덤 또 파고 있구나...하면서요.
부디 이글 읽으시는 관리자분들 계시면 꼬옥~ CMMI 하지 말아주십시오.
CMMI아닌 다른 어떤 것도 우리나라 실정에 맞지 않습니다.
우리나라 소프트웨어 업체가 모두 CMMI하면 우리나라 S/W업계 망하기 일쑤 입니다.
우리나라 휴대폰이 세계시장을 점령하는 것은
빨리 사람들의 요구를 받아서 빨리 만들기 때문입니다.
미국은 그 시간에 문서 작성해야 합니다. 중간에 변경하기 힘듭니다. 왜냐면 날짜 맞추어야 하니깐요.
구닥다리 만들고 있어도 그냥 쭈~욱 완성하고 문서쓰면 누구도 뭐라하지 않습니다.
절대 우리나라 못따라오죠.
http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39141899,00.htm
글쎄, 이런 질문은 마치 "사람과 동물의 차이는 무엇인가?"와 마찬가지로 추상적이고 철학적인 질문이라고 할 수 있다. 하지만 사람과 동물의 차이를 구분할 수 있듯이, 소프트웨어 개발이 (공장의) 생산 공정인지 또는 (새로운 타입의 독창적인) 창조인지를 구분하는 것 또한 충분히 가능하다.
사람은 영(靈)적인 존재이다. 그것이 바로, 동물과 사람을 구분 짓는 핵심 요소이다. 사람은 영적인 활동을 한다. 단순히 의식주의 충족을 초월하여, 음악을 만들고 그림을 그리고 문학 작품을 창작한다. 그렇게 만들어진 작품들이 수세기를 거쳐 후대의 사람들에게까지 전달되어 감동을 주고 누군가의 인생을 바꾸기도 한다.
그렇다면 소프트웨어 개발은 어떠한가?
소프트웨어 개발을 생산 공정을 통해 물품을 만들어 내는 것, 또는 공사장에서 블루프린트 대로 건물을 짓는 것으로 보는 관점을 먼저 살펴보자. 해당 관점 하에서는 개발자(또는 엔지니어)를 대체 가능한 부품 내지는 공사장의 인부로 볼 수 있는데, 그러한 현실을 김국현씨의 풍자 만화(http://www.goodhyun.com)-추운 새벽에 장작불을 쬐며 일감을 기다리는 개발자를 향한 외침, "자바 2명 타요"-는 잘 담아내고 있다.
공사장의 십장(인부를 직접 감독하고 지시하는 사람)과 같은 마인드로 개발자를 관리하려는 매니저들이 있는 것이 사실이다. 그들은 통제를 원한다. 통제하지 않으면 부하 직원들이 일을 제대로 수행하지 못하거나, 또는 일하지 않고 농땡이를 피울 것이라고 생각한다.
전문가라 불리는 일부 사람들은, 제조업 및 토목/건축업과 같은 관점을 소프트웨어에도 그대로 적용하려고 한다. 그렇게 함으로써 불확실한 소프트웨어 개발을 좀 더 명확하게 통제하려는 희망을 갖고 있는 것이다. 수십 년 동안 그러한 희망을 갖고서 수많은 방법론과 기법이 만들어졌지만, 그 어느 것도 명쾌하게 문제를 해결한 적은 없다.
예를 들어, CMMI을 만든 IBM 품질관리자 출신의 와츠 험프리를 생각해보자. 그는 소프트웨어 개발에도 마치 공장에서와 같은 품질 관리 개념을 적용할 수 있다고 보고, 거의 모든 것을 정량적으로 측정하고 통제하고자 하였다. 팀원들에 대한 교육 등 사람에 대한 내용이 전혀 없는 것은 아니지만, 그 사상의 바탕에는 합리적인 프로젝트 상황을 전제하고 개발자들을 대체 가능한 부품으로 생각하는 컨셉을 담고 있다.
왜냐하면 CMMI에는 유능한 개발자와 평범한 개발자의 수십 배의 생산성 차이, 개발자들의 열정과 동기부여, 조직 역학 및 프로젝트의 사회/정치적 요인, 그로 인한 개발자들의 이직률 등에 대해서는 전혀 다루어지지 않고 있기 때문이다. 단기적 생산성이 높다 하더라도, 이직률이 높다면 결국 엄청난 손실이 뒤따를 것이다. 그런 것은 아무도 측정하지 않는다.
솔직히 대부분의 프로젝트는 기술적인 문제 또는 프로세스적인 문제 때문에 실패하는 것이 아니다. 예를 들어, 평범한 데이터베이스 응용프로그램은 수십 년 동안 만들어졌음에도 여전히 종종 실패한다. 프로젝트 실패의 주요 요인은 이해관계의 상충, 거짓 데드라인, 고객의 무모한 욕심, 핵심 개발자의 퇴사, 커뮤니케이션 문제 등 사회/정치적인 요인임을 우리는 경험에 의해 잘 알고 있다.
그러므로 생산 공정과 같은 개념으로 소프트웨어를 다루려고 하는 접근 방법은 대개의 경우 그 가치가 과대평가되어 있다고 볼 수 있다. 그러한 접근이 매력적이기 때문에 흔히 선택될 뿐이다. 그들은 말한다. "포드시스템(조립 라인 방식에 의한 양산체제)과 같은 체계를 구축하면, 마치 소프트웨어 개발을 생산 공정과 같이 통제할 수 있어요."
아, 관리자의 입장에서는 얼마나 매력적인가?
개발자들을 부품 취급함으로써 "김대리는 불량품이었어. 일주일에 80시간 일했다고 해서 금새 고장이 나다니. 고장난 김대리는 버리고, 좀 더 성능 좋은 새로운 김대리로 대치하자고."라는 식의 접근을 할 수 있는 것이다.
오해가 없기를 바란다. 필자의 이러한 말이 품질 관리 전부를 부정하는 것은 아니다. 소프트웨어의 특수성을 인정하고, 좀 더 사람 중심으로 품질 관리의 방향을 잡을 필요가 있다는 뜻이다. 개발자들의 역량과 생산성에 대한 가치는 진지하게 재평가되어야 한다.
프로젝트에 있어 수많은 사회/정치적인 요인은 무시한 채로, 통제 가능한 것처럼 보이는 일부의 요인에만 집중함으로써 프로젝트가 성공할 수 있다는 식의 주장은 실제보다 훨씬 과장되어 있다고 볼 수 있다.
프로젝트 착수는 대개 합리적이지 않으며 데드라인은 말도 안되며 예산은 부족하며 적절한 인적자원은 주어지지 않는다. 그러한 현실을 무시하고, 선한 사람들과 함께, 합리적인 일정, 적절한 예산, 명확한 목표를 갖고서 일한다는 전제를 통해 만들어진 방법론들은 전혀 경험이 없는 사람들에 의해 만들어졌다는 의심이 들게 한다.
이제, 창조의 관점에서 소프트웨어 개발을 생각해 보자. 아, 알고 있다. 물론 SI 프로젝트는 예술이 아니며, 체계적이고 정량적으로 관리될 필요가 있는 것이 사실이다. 하지만 소프트웨어 개발에 있어 SI만 존재하는 것은 아니다. 애플 아이튠스 또는 구글 데스크톱 같은 것도 있다. 그것들은 생산 공정의 통제 기법을 통해 언제든지 만들어질 수 있는 것인가? 그렇지 않다.
그러한 유형의 소프트웨어를 개발하는데 있어, 가장 중요한 요소는 개발자의 영감(靈感, 머리에 번득이는 신묘한 생각)이다. 그리고 그것을 기반으로 한, 동기부여와 창조적 실행력의 극대화이다.
물론, 어떠한 유형의 소프트웨어를 개발하는가에 따라 접근 방법은 다를 것이다. 크게 구분하여, SI성 소프트웨어와 영감에 의한 소프트웨어가 있다. 한쪽은 제조에 가까운 반면, 한쪽은 창조에 가깝다. 두 가지 속성을 모두 가진 소프트웨어도 있을 것이다. 중요한 것은 소프트웨어에는 한가지 유형만 있는 것이 아니라는 점이다.
현실에서 소프트웨어의 유형에 따른 특성 차이, 개발자들의 본질적 속성, 작업 환경, 창조력, 프로젝트의 사회학 등에 대한 내용은 흔히 간과되고 있다. 그 이유는 아마도 그것이 일반적인 경영학이나 사회학, 심리학에서 다루어질 수 있는 분야가 아니고, 그렇다고 컴퓨터 공학이나 소프트웨어 공학에서 다루어 질 수 있는 분야도 아니기 때문일 것이다.
결론적으로 말해, 필자는 소프트웨어 개발의 본질이 창조 작업이라는 것을 주장한다. 생산 공정의 개념을 일부 적용할 수는 있겠지만, 그것이 창조적 실행력보다 우선할 수는 없다.
왜 그럴까? 그 모든 개발의 시작과 끝이 모두 사람으로부터 시작하여 사람으로 끝나기 때문이다. 사람의 지적 능력과 정서, 기쁨과 희생을 통해 만들어진 결과가 바로 소프트웨어다. 우리는 소프트웨어 개발을 단지 생산 공정으로 바라보려는 통제적 관점을 경계해야 한다.
필자의 대안은, 기업들이 생산 공정 식의 투자보다는 개발자의 작업 환경을 개선하고 창조적 실행력을 극대화하고 자기계발을 독려하고 동기부여를 하는데 더욱 투자해야 한다는 것이다. 구글, 어도비와 같은 몇몇 기업들은 그것의 성공 사례를 명백히 증명하고 있다.
필자는 이 문제에 대해서 강의를 하든, 집필을 하든, 그 무엇을 하든 지속적으로 다룰 것이다. 그것이 바로 필자가 몸담은 소프트웨어 업계에 대한 깊은 애정을 증명하는 방법이라고 믿기 때문이다. @
덧붙여
최준열[ 2005/12/07 ]
사 실 구글 데스크탑도 창조성이 많이 반영된 SW이긴 하지만 구글 직원들은 '기간이 언제 까지이고 스펙은 이렇다'는 식의 지시를 받아 움직였겠죠. 제가 가장 이상적으로 보고 있는 케이스는 리누스 토발즈의 리눅스입니다. 그는 리눅스 커널 제작이 아닌 다른 것이 생업이기 때문에 리눅스에 대해서는 돈에 연연할 필요가 없죠. 일단 그런식의 '경제적인 자유'가 확보되어야 SW제작에 예술활동 개념을 접목할 수 있다고 생각합니다. 저는...SW개발이 아닌 다른 것이 생업이면서 SW제작은 예술활동의 일환으로써 해나가는 자유 프로그래머들이 리누스 토발즈 말고도 더 나와야 한다고 봅니다.
아래에 이어서
최준열[ 2005/12/07 ]
자 신이 구글 데스크탑 같은 걸 만들고 있다고 생각한다면...자신의 작업은 SI와는 다른 창조작업이라고 생각한다면, '최준열씨, 납기일은 12월 24일입니다'와 같은 방식으로는 힘들지 않을까 생각합니다. 뭐랄까...저도 아직 명확한 결론을 내리지 못했지만, SW창조작업을 좀 더 예술적인 관점에서 바라볼 필요가 있는 것 같습니다 (SW의 성격에 따라).
오픈소스가 일시적인 대안이 될 수 있지 않을까요?
최준열[ 2005/12/06 ]
쩝, 저도...떠오르는 영감으로 어떤 SW를 창조했다가 그 이후과정을 어떻게 처리해야 할 지 난감해서 SW를 공개해 본 경험이 있습니다. 만약 제가 그 SW의 가치를 제대로 평가받기 위해 무리한 노력을 했다면 아마 상당한 출혈만 안고 자멸하지 않았을까 생각하는데요. 당시의 저는 따로 수입원이 있었기 때문에 SW자체는 공개하는 쪽을 택했고 반응은 매우 좋았습니다. 물론 SI 비즈니스에 오픈소스 개념을 적용시키는 것은 무리일 거라고 생각하고요, 패키지 제품이라면 제 생각에 이 방법이 매우 좋다는 생각이 듭니다.
기존의 비즈니스 모델은 제로자본에서 출발해서 차입을 통해 자본을 확보해서 마케팅 활동을 통해 SW의 좋은점을 무리하게 시장에 어필하고 소비자가 SW를 구매하도록 무리하게 드라이브 하는 방식인데요...다른 수입원이 있어서 돈에 구애받지 않는 상황이라면, 오픈소스 프로젝트가 제품의 가치를 시장에 알리는데 매우 효율적인 방법이라는 것입니다. 제 경우엔 공개된 웹 사이트가 제가 운영하는 것이 아니었기 때문에 공개비용(또는 홍보비용)이 제로였는데요...저 자신은 100원도 안 쓴 상태에서 1달만에 1000명의 유저가 제 SW를 사용하게 되었고 금새 시장이 제 SW의 가치에 반응하게 되었습니다.
인물의 포즈를 자동으로 생성해 주는 SW인 poser라고 아시는지 모르겠습니다. 일본의 만화가 중에 poser를 써서 만화를 그리는 사람도 있는데요, poser도 처음엔 오픈소스로 출발했다가 나중에 사업화 되었는데 시장에서 매우 성공적인 SW로 평가받고 있습니다.
소스를 콱 움켜진 상태에서 '반드시 돈을 얼마 내야 이것을 쓰게 해주겠다'는 과거의 패러다임보다 훨씬 효율적인 방식이라고 저는 믿고 있습니다. 왜냐하면...오픈이라는 것 자체가 유저들을 금새 모여들게 하는 강한 동기가 되기 때문이죠. 그렇게 해서 오픈된 상태에서 시장의 신뢰를 빠른 시간에 얻고 나면 그 때 가서 이익을 추구하기 위한 추가 상용판을 제작해도 늦지 않다고 생각합니다. 그 때는 어느 정도 시장의 흐름을 타고 있는 상태에서 제작하는 것이기 때문에 훨씬 일이 수월하게 풀리죠.
소프트웨어 업계의 비젼..
이준형[ 2005/12/06 ]
저도 나름대로 소프트웨어 업계에서 살아온 사람으로써 한마디 거들지 않을수 없어서.... 애써 로그인 까지 해가면서 이 글을 적습니다.
리플을 다신 많은 분들도 공감 혹은 반박을 하기 위해 글을 쓰셨겠지만, 결국 근본적인 원인은 측정되어 지지 않는것에 있다고 생각합니다. 프로그래밍도 디자인과 같이 상대적인 가치와 우위를 판단 할 순 있지만 그것이 최고이거나 몇점 이라거나 평가하기가 어렵기 때문에 CMM과 같은 건설업계에서 사람 다루듯이 해서는 안된다고 보여 집니다. 하지만 역시 안타까운 문제는 많은 인재들이 이렇듯 적절하게 평가되어지지 않는 현실에 몸서리를 치며 키보드를 놓곤 한다는것에 있다고 봅니다. 다들 입모아 상품에는 디자인이 중요한 요소라고 생각하면서 검증되지 않은 디자인은 천시하는 경향이 있습니다.
소프트웨어 업계에도 과기처 단가와 같이 형식적인것 말고 그 사람의 가치를 판단해 줄수 있는 평가 기준이 꼭 공정하게 만들어 지기를 바랍니다.
잘해준다고 창조성 up? 그 반대입니다.
몽몽이[ 2005/12/05 ]
잘해준다고 창조성 up? 절대 그렇지 않습니다.
사회에서 엔지니어는 부품이고, 부품이 능동적인 활동을 하는 것에 대해서는 프로세스 자체가 없으며 Nonsense하게 만들어버립니다.
창조적인 놈 뽑으라고 말하는 그들조차 기껏해야 싸구려 치기에 버릇없는 놈 뽑는거랑 구별도 못합니다.
문제는! 이런 당연한 사회현실이 문제가 아니고... 이미 엔지니어라는 생물들이 거기에 적응했다는 겁니다. 술한잔 얻어먹으면 해피하고 교육보내면 의례 자야하고... 호시절엔 그것도 지겹더라는 말을 태연하게 하지요...
잘해주지 않아서 창조가 안되는게 아니라... 이런 쓰레기들을 죽이지 않아서 창조가 안됩니다...
참고로 전 공공SI만 피터지게 하다... 돈 좀 벌어보겠다고 투자 좀 받는 신규 부서로 옮긴 사람인데, 이때다 하고 내일도 없이 사는 자칭 엔지니어들을 보고 저것들 먹여살리느라 내가 그 고생을 했던가 하고 치를 떠는 사람입니다.
물론 모두 줗은 의견들입니다.
sosteam[ 2005/12/05 ]
정말 좋은 그러나 조금은 어려운 내용의 의견들을 잘 읽었습니다. 같은 고민을 하시는 분이 많아 정말 기분이 좋았습니다.
하지만 제가 성격이 급해서 그런지 계속적인 좋은 의견이 구체적인 액션 플랜으로 어떻게 이어져야하는지 읽어봐도 모르겠습니다.
이런 질문 조차도 하늘에 별따기식 질문이 되어 버릴 수 있겠군요.
그럼 구체적으로 예를 들어보면 프로젝트 발생 시 SI가 아닌 업체에서 견적과 데드라인을 어떻게 정해야 할까요? 과기처 방식으로? 오래된 LOC 방식? 아니면 그 회사 내부의 방침으로? 어떤 구체적인 대안이 나오기 너무 힘듭니다.
컨설팅을 해주는 업체는 CMMI 같은 인증을 받을 수 있는 방법을 제시 해줍니다.
관을 먼저 산 후 사람을 끼워 맞추는 거죠.(산사람을 넣으면 많이 아프겠죠 )
이런 방법은 비 공식적 WBS 작성을 낳게 되고, 공식적인 WBS는 마치 제대로 진행되고 있는 양 속일 수 밖에 없습니다. 정말 답답한 회사라고 생각하실 수 있지만 그게 현실입니다.
견적 이외에 인스펙션 같은 예를 들어도 좋습니다. 인스펙션을 표준 방침대로 한다면 납기일을 맞출 수 있을까요? 게다가 효용성 있는 인스펙션에 대해서 나와있는 방법이 있을까요?
많은 것을 고려해서(인간적인 것 포함) 공정을 만들어가면된다는 것은, 다른 말로 공정이라는 자체가 필요없다는 얘기와 같습니다. 즉 모든 프로젝트는 시작할때 그 공정이 항상 새롭게 만들어지는 것입니다. PM의 역량과 건강상태, 업무내용과 프로그래머들의 친밀도, 각자의 성격과 가정환경까지도 그때 그때 따라 달라지는 것이죠. 심지어 몇월에 프로젝트가 시작되느냐에 따라 달라지죠 추석이 있는 달인지, 연말 연시인지, 인사철인지.
프로그램 공정은 인간의 생활을 문서화 하는 작업입니다. 인간의 생활을 문서화 하는 것은 마치 가능하게 보이기도 하겠지만 별로 하고 싶지 않은 작업임에는 틀림없습니다.
몸에 맞는 프로세스의 중요성
류한석[ 2005/12/05 ]
제가 지면 관계상 충분히 언급하지 못한 내용들이, 독자님들의 피드백을 통해 많이 다루어져서 기쁩니다. ZDNET에는 정말 수준 높은 독자님들이 많다는 사실을 다시 한번 실감하게 되었습니다.
가을하늘님의 말씀처럼.. 창의성과 동기부여를 훼손하지 않는 범위 내에서, 즐겁게 일할 수 있는 프로세스와 규범의 확립은 중요합니다. 의견에 동의하며, 그러한 균형 감각을 갖춘 조직이 많아지기를 기원합니다.
제대로 된 공정없이 제대로 된 제품이 가능한가?
가을하늘[ 2005/12/04 ]
사 실 국내에서 소프트웨어 제품 - SI가 아니라 - 을 개발하는 회사 중 제대로 된 소프트웨어 개발 프로세스를 갖고 있는 회사는 별로 없으리라 생각된다. 아무리 창의적인 생각도 그것이 제품으로 나타나고, 시장에서 매번 사람으로 때우는 SI가 아니라 외국 제품과 품질로 승부할 수 있는 제품이 되려면, 그리고 수년 간 제품이 버전업되고 유지보수되려면, 요구분석, 설계, 구현, QA 테스트, 버전 컨트롤, 버그 트래킹 등 기본적인 공정없이는 가능하지 않다. 나는 도리어 제대로 된 국내 소프트웨어 제품이 별로 없는 것이, 반짝이는 창의적인 아이디어가 부족해서가 아니라 제대로 된 제품을 만드는 소프트웨어 개발 프로세스를 제대로 익힌 소프트웨어 개발자가 별로 없기 때문이라고 생각한다. 공정은 말 그대로 기본적인 틀일 뿐이다. 개발 프로세스 안에서 얼마든지 개발자의 창의력과 경쟁력을 발휘할 수 있다. 탁월한 제품기획자, 탁월한 분석가, 탁월한 architect, 탁월한 trouble shooter, 탁월한 아이디어맨, 탁월한 QA engineer, 탁월한 PM, 이러한 사람들이 모여 개발프로세스를 움직여야, 재미있게 일할 수도 있고, 정말 좋은 제품도 나올 수 있다. 적절한 개발프로세스는 제대로 된 제품을 위한 필요 조건일 뿐이다. 소프트웨어 개발프로세스 하면 CMMI를 떠 올리시는 분들이 있을지도 모르겠다. 나는 CMMI가 소프트웨어 제품 개발에 필요하다고 생각하지 않는다. 몸에 맞는 개발프로세스를 만들고 적용하는 소프트웨어 회사가 계속 많아지기를 바란다.
수준높은 글과 리플들에 감동
김홍석[ 2005/12/04 ]
마침 제게 필요한 글이 올라와 감사합니다.
그리고 밑의 수준높은 리플들 또한 많이 도움이 되는군요..
류한석님뿐 아니라 홍형경님, 조동환님, sosteam님의 리플들이
저에게 많은 생각을 하게 해주네요..
저희 회사도 이번에 CMMI를 땄습니다..
형식에서는 배울 점이 많다고 생각되었지만
실제 업무에 도움이 되는 지는 정말 계속적으로 의문이 들더군요..
이 글을 읽고야 깨달았습니다...
문제는 인간.. 그리고 창의성이 배제가 되었던 겁니다..
제가 추구하는 것은 창의성이 먼저지 생산성 먼저가 아니었다는 걸
절실히 느꼈습니다..
그런데 또 이런 생각들도 들더군요..
그런 창의성을 제대로 키워주고 발휘할 수 있는 회사가 우리나라에 있을까..
그리고 CMMI를 제대로 도입해서 업무에 도움되는 곳이 있을까..
정확한 시간측정으로 인해 무모한 과로 업무를 줄여주고
정당한 보수를 지불한다면 그것만으로도 충분하리라 생각되는데..
하는 생각들이요..
수준높은 글과 리플들에 감동
김홍석[ 2005/12/04 ]
마침 제게 필요한 글이 올라와 감사합니다.
그리고 밑의 수준높은 리플들 또한 많이 도움이 되는군요..
류한석님뿐 아니라 홍형경님, 조동환님, sosteam님의 리플들이
저에게 많은 생각을 하게 해주네요..
저희 회사도 이번에 CMMI를 땄습니다..
형식에서는 배울 점이 많다고 생각되었지만
실제 업무에 도움이 되는 지는 정말 계속적으로 의문이 들더군요..
이 글을 읽고야 깨달았습니다...
문제는 인간.. 그리고 창의성이 배제가 되었던 겁니다..
제가 추구하는 것은 창의성이 먼저지 생산성 먼저가 아니었다는 걸
절실히 느꼈습니다..
그런데 또 이런 생각들도 들더군요..
그런 창의성을 제대로 키워주고 발휘할 수 있는 회사가 우리나라에 있을까..
그리고 CMMI를 제대로 도입해서 업무에 도움되는 곳이 있을까..
정확한 시간측정으로 인해 무모한 과로 업무를 줄여주고
정당한 보수를 지불한다면 그것만으로도 충분하리라 생각되는데..
하는 생각들이요..
생산공정도 변하고 있다..
홍형경[ 2005/12/01 ]
생 산공정적인 면에서 본다면, 과거의 대량생산 방식에서 쓰이던 방법은 분업형태였습니다. 생산라인에 각 작업자들이 쭉..나열해 있어 라인이 돌때마다 자기가 맡은 공정처리를 했었지요. 이러한 방법이 예전에는 꽤 생산력도 좋았고 불량품을 줄이는데도 기여를 했다고 합니다. 하지만 이 방법의 단점은 라인이 정해진 속도로 돌아가다 보니 초보자는 따라가기 힘들고, 숙련자들은 능력을 발휘할 기회를 없앴습니다.
얼마전 일본에서 Cell생산방식 이란것이 나왔습니다. 몇 명이 팀을 짜서 그 팀이 하나의 완제품을 생산하는 것이지요. 캐논이 처음 도입했다 합니다. 초기에는 한 팀에 30명이 투입되었는데, 몇달 지나니 20명, 최근에는 6명이 한 팀을 구성한다고 합니다. 그 6명이 복사기 한대를 다 조립하는 것이지요. 이러한 방식의 차이점은 뭘까요? 한 마디로 복사기만드는데 전문가를 키운다는 것입니다. 이 회사의 어떤 사람은 1만개가 넘는 부품으로 구성된 복사기를 불과 14시간에 조립하는 장인(마이스터)도 배출했다고 합니다. 속도뿐만 아니라 다른 여타 지식이나 노하우는 말도 꺼낼 필요가 없겠지요.
결국은 아무리 좋은 방법론이 나오거나 좋은 프레임웍이 나오더라도 결국 일은 사람이 하는 것입니다. 아직까지 우리나라 환경은 이러한 풍토를 만들지 못하고 있습니다. 제 개인적 생각으로는 시간이 지날수록 점점 더 나빠지고 있다는 생각이 드는군요.
넓으신 아량에 감탄...
조동환[ 2005/12/01 ]
미 디어에서의 여론은 항상 흑백논리거나 마녀사냥식이 많습니다. 무언가 다른 의견을 내놓는 사람들은 무시당하거나 심하게 취급받는 경우가 많습니다. 정치적인 이슈나 사회적인 이슈는 그럴 수 있다고 생각해도 이런 공학적인 이슈까지 그럴 필요는 없다고 생각합니다. 하지만 너무도 그런 식의 사고에 익숙해져버린 우리이기에 항상 의사결정이나 판단을 내릴때 일부만 보고 전체를 예단하는 실수를 하는 것 같습니다.
말씀하신대로 계량적으로 흐르는 통제주의는 인간본성에 대한 이해가 부족한 면에서 많은 부분 비롯되는 것으로 생각됩니다. 제가 존경하는 심리학자이신 미하이 칙센트미하이교수가 지은 "몰입(Flow)"이라는 책을 보면 과연 개발자나 지식노동자가 행복해지기 위한 것에 대해 implication을 얻을 수 있다고 생각합니다.
약간 거칠었던 댓글을 너그럽게 받아주신 아량에 감탄하며, 앞으로도 더 좋으신 글과 통찰력 깊은 의견개진 부탁드리겠습니다.
언제나 중요한 것은 "균형감각"
류한석[ 2005/12/01 ]
조동환님의 의견에 동의합니다. 언제나 중요한 것은 균형감각, 즉 밸런스입니다.
실제로 저도 프로세스 관련 글을 쓰고 그런 일을 하고 있습니다. 너무 계량적으로 흐르는 통제주의에 경종을 울리고자 쓴 글이니, 흑백논리는 아님을 이해해주시기 바랍니다.
좋은 의견 감사합니다. *
제 의견은 이렇습니다
조동환[ 2005/12/01 ]
우 선 의견을 올리신 sosteam님 및 속하신 회사께 위로의 말씀을 드립니다. 국내에서는 CMMI를 ISO9000처럼 "따야" 할 것으로 다루는 업체가 대다수인 것은 사실입니다(특히 SI, 방산등) 제가 7여년 넘게 소프트웨어프로세스개선을 포함한 기업내부컨설턴트로 일하는 동안 깨달은 사실은 “모델은 모델일뿐이다”라는 사실입니다. 즉, 개선의 방향성에 대해 힌트를 얻는 정도로 사용하는 데에는 최상의 도구(모델, CMMI)이나 세상의 모든 문제를 해결해주는 silver bullet으로 사용한다면 그 총알으로 스스로의 머리를 겨누는 것과 다름이 없습니다.
예를 들어, requirement management나 project planning도 제대로 해내기 위해서는 정말 많은 질문을 스스로(기업내부경영자, 개발자, 관리자)에게 진지하게 던져보아야 합니다. 도대체 우리가 달성하고자 하는 비즈니스목표는 무엇인가? 빠른 Time To Market인가, Reliability(Quality라는 용어는 너무 포괄적이므로 사용치 않겠습니다)인가, 아니면 Risk를 Minimizing하는 것이냐에 따라 아주 심플한 프로세스와 템플릿으로도 가능할 수 있고 아니면 아주 정교한 프로세스와 툴의 뒷받침이 필요할 수도 있습니다. 핵심은 경쟁자를 철저히 부셔버리고 따돌려버리기 위해서는 우리는 무엇을 해야하는가를 스스로에게 진지하게 물어보는 것입니다.
이것을 기업외부의 Lead Assessor가 1~2개월의 Assessing으로 수준을 판단하고 6개월~1년사이에 하나의 레벨을 올린다는 것은 거의 사기에 가깝습니다. 제가 모자른 탓도 많겠지만 제가 서비스하는 회사에서는 2~3개의 프랙티스(프로세스가 아닙니다. 훨씬 작은 범위입니다)만을 집중적으로 철저히 개선하고 변화시키는데 4년가까이 걸렸습니다. Software Product Engineering의 V&V중 Software Testing을 제대로 셋업하는데는 앞으로 5년이 더 걸릴지도 모릅니다.
다시 정리해서 말씀드리면, 흑백논리는 위험하다는 것입니다(이부분부터는 류한석씨께 드리는 말씀). 디마르코가 강조하는 포인트에서 반드시 배워야 하는 포인트가 있는 반면에 험프리나 기타 품질 GURU들에게 배워야 하는 포인트도 있다고 생각됩니다. 예를 들어, 창조성 부분은 Requirement Development부분에 훨씬 더 잘 적용되는 개념입니다. 즉, Research side에 더 많이 필요한 부분입니다. 하지만 개발이 진행되어 실제 개발(Development) side에 가까워지면 철저한 관리, 꼼꼼함이 더 중요한 부분이라고 생각됩니다.
유명한 학자의 말을 인용하는 것은 자신의 논리를 펼치는데 있어 비겁한 일일 수도 있지만 지식근로자에 대해 통찰력있는 글을 많이 쓴 피터 드러커의 말을 인용해보면, 지식노동자의 작업도 무조건 창조적이라고 싸잡아 이야기 할 수 있는 것이 아니라 3가지 부류가 있다고 합니다: 1) 작업품질이 작업량보다 훨씬 중요한 카테고리(즉, 신약개발이나 예로 드신 구글이나 애플?) 2) 작업품질과 작업량과 균형을 이루어야 하는 하이브리드 카테고리 3) 작업량이 중요한 육체노동에 가까운 카테고리(즉, 보험업무처리나 Call Center의 Caller등)
소프트웨어의 개발프로세스와 해당 기업이 시장에서 처한 상황, 기업내부의 기업문화를 고려하여 작업생산성(창조성을 포함한)을 최대한으로 높일 수 있는 방안을 고민하여 지속적으로 개선하는 것이 정말 경쟁력을 확보할 수 있는 방법이지 모든 참조가능한 선례와 지식을 부정하고 단지 현재 결과가 좋으니깐 당연히 우리의 방법이 좋다라고 하는 것은 논리의 비약이 좀 심한 것 같습니다.
참고적으로 “한국형 생산방식, 그 가능성을 찾아서”라는 제조쪽의 글의 논리를 보아도 한국사람들이 특히나 잘하는 것이 있다 그것을 무시하고 무조건적으로 외국의 방식을 따르는 것은 자신의 강점을 스스로 버리는 행위다라고 하고 있습니다. 저도 그부분에 있어 전적으로 동의합니다. 허나 그 한국적 방식이 시간을 거듭하면서 발전하거나 타인에게 전수가 가능하지 않는 것이라면 그 회사나 국가의 경쟁력을 계승발전시키는데 무슨 소용이 있겠습니까 (실제로 한국의 반도체 공장들은 생산성에 있어 세계최고이지만 다른 외국의 공장을 설립하는 경우 한국의 핵심기술자가 파견되지 않으면 셋업자체가 불가능하다고 합니다. 자동차공장도 마찬가지 상황이라고 합니다)
결론적으로, “창조적”+”체계적”은 항상 서로 피드백을 주고받고 Trade-off해야 하는 요소라고 생각됩니다. 그리고 그 최적점은 경쟁환경하에서 항상 바뀌므로 기업은 항상 변화하고 개선하고 노력해야 경쟁력을 지닐 수 있다고 생각됩니다.
거의 모든 분야에 대해 적용가능한 글...
최준열[ 2005/12/01 ]
사 실...지구의 모든 조직들이 인간이 영적존재라는 것을 간과하고 인간을 계량적으로 관리하려 들고 있지 않습니까? 학부시절에 '허구헌날 회로책만 보다가 졸업하면 안 되는데' 싶어서 경영학과 수업을 좀 수강했던 적이 있습니다. 정말...어처구니가 없더군요. 인적자원관리(HR Management) 책 보니까 저자는 영적인 존재들의 동기부여라는 테마에 대해 거의 아무런 관심도 없음을 알 수 있었습니다. 연봉제가 어떻다 성과급제가 어떻다 전부 수치적인 이야기(거의 급여에 관련된) 뿐이었죠.
마케팅 이론서적들도 그래요...인간은 영적인 존재이고 사람들(소비자들)이 그 시대 그 시대 어떤 상품을 원하는가는 그 시대의 영혼들이 마음으로부터 뭘 원하고 있었는가 오로지 그것밖에는 없는데, (가령 영혼들이 독점적인 매스컴의 횡포에서 벗어나고 싶어했고 자기가 원하는 정보를 마음대로 탐색하길 원하기 시작했기 때문에 PC혁명, 인터넷 혁명이 급물살을 탔던 것처럼) 책이 죄다 누구의 공식 누구의 공식 어쩌고 하면서 수치적인 이야기만 해대고 있었습니다. 세파에 시달리며 사람들과 함께 부대껴 본 적도 없으면서 저명한 교수님들이 방에 틀어박혀 상상만으로 책을 집필하고 있었던 거죠. 아 정말...뭔가 북받쳐 오르는 필이 오는군요 -,.-
저에게 방송활동을 할 수 있는 기회가 주어진다면 이런 걸 좀 공개적으로 다뤄보고 싶은데...삼성을 보세요. 자기 딸이 뭘 원하는지도 몰라서 혼자 죽게 한 사람이 직원들 한사람 한사람의 마음을 어떻게 알 수 있겠습니까? 우리 사회 정말 문제가 한두가지가 아닙니다.
절대 동감입니다.
sosteam[ 2005/12/01 ]
(좀더 수정 보완해서 삭제 후 다시 올립니다.)
우리회사도
CMMI 땄습니다.
어떻게되었을까요?
관리자분들만 좋아합니다.
고객은 자전거타고 빨리 가려하는데
우리는 뛰어서 갑니다.
예전에는 같은 속도를 낼때도 있고 때론 더 빠를 때도 있었습니다.
CMMI 후에 현저하게 차이가 납니다.
이젠 뛰다가 점점 지쳐갑니다.
부작용이 생깁니다.
개발자들은 이제 더이상 창의적인 생각을 안합니다.
문서 쓰고 결재 맡아야 하고. 책임 추궁 당하기 딱 좋습니다.
시키는일만 하고 문서 올리면 일 잘하는 사람되니까 창의적인 생각은 이제 별 필요 없습니다.
CMMI에서 가장 중요한것은 무엇인지 아십니까?
바로 시간안에 프로그램을 완성하는 것입니다.
누군가 기다리고 있는 사람이 없어도
얼마나 완성된 모습을 보이느냐..
얼마나 참신하냐는 중요하지 않습니다.
시간안에 만드느냐가 중요합니다.
소프트웨어를 짤때의 짜릿함은 이제 온데간데 없습니다.
소프트웨어 사대주의의 온상이 바로 CMMI입니다.
어떤회사는 레벨 5를 땃다고 하더군요.
그런 소식을 들을 때마다 정말 가슴이 메어집니다.
우리나라 업체 하나 소프트웨어 무덤 또 파고 있구나...하면서요.
부디 이글 읽으시는 관리자분들 계시면 꼬옥~ CMMI 하지 말아주십시오.
CMMI아닌 다른 어떤 것도 우리나라 실정에 맞지 않습니다.
우리나라 소프트웨어 업체가 모두 CMMI하면 우리나라 S/W업계 망하기 일쑤 입니다.
우리나라 휴대폰이 세계시장을 점령하는 것은
빨리 사람들의 요구를 받아서 빨리 만들기 때문입니다.
미국은 그 시간에 문서 작성해야 합니다. 중간에 변경하기 힘듭니다. 왜냐면 날짜 맞추어야 하니깐요.
구닥다리 만들고 있어도 그냥 쭈~욱 완성하고 문서쓰면 누구도 뭐라하지 않습니다.
절대 우리나라 못따라오죠.
http://www.zdnet.co.kr/itbiz/column/anchor/hsryu/0,39030308,39141899,00.htm
posted by whoami at 10:29 PM
0 Comments:
Post a Comment
<< Home