태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

삼성이 소프트웨어 분야에서도 최고가 되려면?

2010.03.02 14:26 by 전규현


잠시 후 Google blogger로 이동됩니다.





최근 삼성과 소프트웨어에 대한 글들을 몇 건 올리면서 정말로 다양한 의견을 접하게 되었습니다.
댓글뿐만 아니라 메일을 통해서도 의견을 들을 수 있었습니다. 

그 중에는 삼성 관계자 분들도 있었고, 삼성 내부 개발자, 삼성 협력사의 개발자들도 많이 있었습니다. 
현재 삼성으로 대표되는 대한민국 대기업들의 소프트웨어 개발 현황을 살펴보고 해결책을 찾아보려고 하는 블로그 글에 상당히 과민반응을 보이는 글들을 보면서 현 상황을 더욱 잘 짐작하게 해줍니다.
특히, 인상적인 글들은 삼성 내부 개발자와 삼성 협력사의 개발자의 글들이었습니다. 상당히 충격적인 증언들도 있었습니다. 댓글과 메일을 포함해서 삼성 내부 소프트웨어 조직의 심각성을 좀더 잘 알 수 있었습니다.
어쨌든 모든 댓글 및 메일을 보내주신 분들에게 감사 드립니다.

이제 결론을 내릴 때가 된 것 같습니다. 애초의 글들의 목적은 도무지 가망이 없어 보이는 대한민국의 소프트웨어 환경, 특히 삼성으로 대표되는 대기업들의 열악한 소프트웨어 개발 환경을 극복하고 소프트웨어 분야에서도 최고가 되는 방법을 찾아보려는 것이었습니다. 제 사견이긴 하지만, 그 동안의 소프트웨어 개발 및 컨설팅 경험을 근거로 나름대로 전문적이고 현실적인 방법을 찾아보려고 노력했습니다.

그럼 삼성이 소프트웨어 분야에서도 최고가 되는 방법의 시나리오를 보죠.

1. 좀더 실패가 필요합니다. 
어이 없는 결론이기는 하지만 몇번 더 실패를 통해서 소프트웨어의 중요성을 좀더 깨달아야 합니다.
현재 돌아가는 상황을 보면 소프트웨어 분야에 있어서 실패를 했고 실력은 부족하고 소프트웨어에 투자를 해야 한다는 간단한 현황을 진정으로 인식하고 있는 것으로 보이지 않습니다.
제가 삼성 및 대기업의 소프트웨어 개발 능력 부족을 지적하는 글을 작성한 이후에 놀랍게도 신문, 방송 모두 거의 똑같은 의견을 연일 쏟아 냈습니다. 이에 대응하여 삼성에서 발표한 극복 방안은 대부분 단기적이고 비전문가적인 접근들이었습니다. 소프트웨어 전문가라면 금방 문제가 있다는 것을 눈치챌 정도로 허술한 것들이었습니다. 
이는 현재상황을 진정으로 이해하고 있는 것이라고 볼 수 없습니다. 안타깝게도 몇번의 실패를 더 해야 진짜 문제가 심각하고 이대로는 안 된다는 것을 알 수 있을 것 같습니다. 삼성 내부에서도 아랫사람들이 아무리 얘기를 해봤자 시장에서 크게 실패하기 전에는 이를 깨닫기 어려울 것 같은 같습니다.
개인적인 바램은 최상위 경영층에서 가능하면 빨리 이를 인지해야 할 것 같습니다. 자칫하면 너무 늦을 수도 있습니다.

2. 소프트웨어 전문 경영자를 다시 중용해야 합니다.
기업의 경영자 인사는 다분히 정치적인 요소가 강합니다. 그러기 때문에 소프트웨어 전문 경영자가 중용되거나 오래 버티기가 힘들지만, 진짜 실패를 통해서 최고의 자리를 유지하기 위해서는 소프트웨어에 투자하는 수밖에 없다는 것을 깨닫고 나면 이를 이끌 소프트웨어 전문 경영자가 필요합니다. 
대기업의 소프트웨어 현황을 대변하는 말 중 하나가 "조삼모사"입니다.
"조三모四"아니 "조三모七"을 주장하는 소프트웨어 전문 경영자보다 "조四모一"을 얘기하는 경영자가 더 오래 살아남습니다. 여기서 저녁의 "일"은 얘기거리도 안됩니다. 소프트웨어 분야에서는 "조三모四현상이 더욱 극명하게 나타납니다.
애플은 아이폰의 플랫폼은 단 하나만을 사용하고 있고 구글도 안드로이드 하나를 사용하고 있습니다. 안드로이드는 핸드셋마다 변경될 수는 있지만 상당부분 호환성을 유지하고 있습니다.
그런데 국내의 한 굴지의 핸드폰 제조사는 지금까지 나온 6,000여개의 핸드셋에서 서로 다른 6,000개의 플랫폼을 사용하고 있습니다. 이를 공통으로 사용할 수 있는 플랫폼을 개발 할 수도 있었겠지만, 하나의 핸드셋만 놓고 보면 소스코드 복사해서 따로 만드는 것이 시간이 더 단축되기 때문에 "조三모七"이 아니고 "조四모一"을 선택한 것입니다. 
"一"이 아니고 마이너스 상황이 되고 소프트웨어가 지속적으로 발목을 잡기 전에 "소프트웨어 전문 경영자"가 이를 극복할 수 있도록 해야 할 것입니다. 또한 기존의 조직, 기존 사업부에서 결국 단기적인 실적 목표에 또 밀려 나지 않도록 새로운 조직이 필요할 것이며 정치논리에 밀리지 않도록 최상위 경영층의 지원이 필요합니다.

3. 외국의 전문 SW회사를 인수합니다.
삼성 내부의 개발조직을 가지고 어떻게 잘해보기에는 이미 늦은 듯 합니다. 물론 삼성 내부에도 뛰어난 개발자들이 많이 있지만, 조직으로 놓고 보면 얘기가 달라집니다. 이런 조직에서 오랫동안 길들여진 개발자들은 대부분 제대로 된 소프트웨어 개발 조직에서 제 역할을 하는 것을 기대하기는 힘듭니다. 
그렇다고 새로운 조직을 신입 개발자들을 뽑아서 만들어가기에는 시간이 이를 허용하지 않습니다. 
따라서 외국의 뛰어난 전문 SW회사를 인수해야 합니다. 이 또한 정치 논리가 아니고 진짜 소프트웨어 회사를 제대로 평가할 수 있는 전문가 그룹에서 삼성의 미래에 도움이 되는 소프트웨어 회사를 선택해서 제대로 평가하여 인수해야 합니다.
소프트웨어 전문 경영자는 인수한 SW회사와 삼성의 가교역할을 해야 합니다.

4. 인수한 SW회사는 삼성 내부의 개발조직과는 분리를 해야 합니다.
인수한 외국의 SW회사는 삼성 내부 개발자들과는 너무나 다른 개발문화를 가지고 있습니다. 이들을 자칫 그냥 섞어 놓다가는 둘 다 망칠 수 있습니다. 따라서 삼성 내부 개발자 중에서도 철저한 평가를 통해서만 인수한 SW회사로 이동이 가능할 것입니다. 아직 삼성의 개발문화에 많이 길들여지지 않았지만, 영어를 잘하고 똑똑한 개발자들은 인수한 SW회사와 섞어서 일하는 것이 가능할 것입니다. 
이 과정을 통해서 서서히 글로벌 소프트웨어 개발 문화를 익혀나가는 것이 필요합니다. 즉, 삼성에서 직접 활약할 선임 소프트웨어 개발자들을 양성해야 합니다.

5. 독자적인 성장을 할 수 있도록 보호를 해주고 지원해야 합니다.
인수한 소프트웨어 회사에도 "조삼모사"논리로 기존의 개발문화를 깨게 되면 평범한 소프트웨어 회사가 되어 버릴 수도 있습니다. 기존의 삼성 조직에 필요한 것들은 개발자 순환을 통해서 조금씩 익혀나가고 인수한 소프트웨어 회사에서는 독자적인 사업 영역을 계속 가져갈 수 있도록 보호를 해주고 지원해야 합니다. 이런 SW회사를 여러 개 인수하여 다양한 개발 문화를 접해야 합니다. 

6. 기존 조직의 반대와 방해로부터 보호를 받아야 합니다.
이러한 과정에서 내부 조직의 반대와 방해에 부딪힐 것은 뻔합니다. 이러한 방해는 아주 작은 소프트웨어 회사들에서도 존재하는데 삼성 같은 거대 기업은 말할 필요가 없습니다. 이를 보호해줄 수 있는 사람은 삼성내의 최상위 경영층 밖에 없을 겁니다. 이렇게 5년, 10년 투자가 이루어져야 소프트웨어 분야에서도 최고라는 소리를 조금씩 듣기 시작할 수 있을 겁니다.

고민 끝에 내린 시나리오는 이렇지만, 이 시나리오의 최대 키포인트는 바로 최고 경영층의 지원일 겁니다. 현재 상황을 얼마나 심각하게 깨닫고 기존의 경영자들은 이를 해결 할 수 없다는 것을 얼마나 빨리 깨닫느냐가 관건이라고 할 수 있습니다.

대한민국 소프트웨어 개발환경은 대기업, 중소기업 가리지 않고 열악하기 그지없습니다. 특히 삼성은 우리나라 경제의 가장 큰 버팀목이기도 하지만 수많은 중소 소프트웨어 회사의 밥줄이며 동시에 목줄을 죄고 있습니다. 삼성이 잘하면 모두 상생할 수도 있지만, 잘못하면 삼성은 약간의 타격이지만, 중소 소프트웨어 회사들은 와해되기 때문에 이것이 삼성이 소프트웨어 분야에서도 잘해야 하는 제가 생각하는 가장 큰 이유입니다. 

이는 비단 삼성만의 문제는 아닙니다. 제 바램은 이런 목소리를 통해서 소프트웨어 환경이 조금씩 나아지는 길로 가는 것입니다. 

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
Image by whisperwolf
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 M&A, 개발문화, 소프트웨어, 인수

  1. 정말 100% 공감하는 글 입니다.
    극단적인 표현일지 몰라도 . 많은 프로젝트들이 실패를 해야 한다고 생각이
    듭니다.
    부정적인 시각이라기 보다 현실적인 시각이죠...
    프로젝트가 시작하면 이미 절반이상 실패를 했다고
    생각합니다.
    근거를 알 수 없는 개발공수, 복불복 개발 방법론(나만 아니면돼),
    커뮤니케이션 없는 일방적 진행,무늬만 개발 총괄,
    기술보단 정치가 중요한 환경등...
    재난이 난 후 피해액보다 예방에 투자한 금액이 훨씬 저렴하고
    안정적이란걸 깨달았으면 합니다.
    쓰나미가 밀려오는 걸 알면서 피하지 않고 기다린다는게 너무 슬프군요

  2. 안녕하세요. Beyond J2EE
    또다른 문제는 소프트웨어 분야에서 문제가 많음에도 불구하고 삼성이 잘해왔다는 겁니다. 최근 스마트폰이 대두되면서 문제가 되고 있기는 하지만 지금까지 겉으로 보기에는 잘 해왔습니다.
    그래서 더욱 경영층들이 설득이 알될 가능성이 높습니다.

  3. 바늘로 찔러 고름을 짜낼것을 미루고 미루다가
    10%도 안되는 성공율의 수술을 받아야 하는 상황이 된게 아닐까 싶습니다.

  4. 안녕하세요. 구차니님
    지금까지 왜 이렇게 되어 왔는지 이해는 되지만 안타깝죠.

  5. 시나리오는 영화로 제작하지 않는한 실감하기가 쉽지 않죠.
    또한 영화로 제작한다고 시나리오가 현실이 되는것도 아니고요.
    삼성의 SW 성공 시나리오는 말그대로 시나리오일 뿐..

    현실에서의 실질적인 대책은
    역시 어느 누구도 세울 수 없는 상황인 것 같습니다.

  6. 안녕하세요. 크레브님
    그나마 최선의 방법을 제시한 것이지만 이렇게 되지 않을 확률이 훨씬 높아 보입니다.

  7. Blog Icon
    도모네

    그 동네는 해외 유학파 출신 인재들도 많은 걸로 알고 있습니다만, 선진국으로부터 배운 것들은 조직문화에 별 영향을 주지 못하는 것 같습니다. '인천공항의 기적'이라는 말도 있던데.. 주로 대학 쪽에서 쓰이던 말이지만, 업계에서도 그것은 통용되고 있지 않나 싶네요.

고객이 요구사항을 너무 자주 바꿔요.

2009.07.30 23:48 by 전규현


잠시 후 Google blogger로 이동됩니다.



우리나라 소프트웨어 시장을 너무 비관적으로 과대평가하는 경우를 종종 봅니다.

예를 들면 전세계 유래가 없는 까다로운 고객 요구 수준, 시도 때도 없이 바뀌는 요구사항, 엄청나게 낮은 금액, 제품의 Output과는 상관없이 작업 시간을 통제하는 관행

일부는 공감을 하기도 하지만, 어느 나라를 가던지 각 나라만의 특징이 있다는 측면으로 바라보고 싶습니다. 우리나라 고객은 요구사항을 정말로 외국에 비해서 더 자주 바꾸는 것인지는 생각해 볼 필요가 있습니다. 어딜 가던지 고객은 요구사항을 항상 바꾸기 마련이고, 그것이 고객의 습성이라고 볼 수 있습니다. 그런데, 외국에서는 관행적으로 문화적으로 스펙을 근거로 계약을 하고, 분석 능력이 뛰어난 엔지니어들도 많이 있습니다. 하지만 그런 저변이 상대적으로 부족한 우리는 개발을 하는 쪽이나 고객이나, 일단 대충으로 요구사항으로 개발을 하고 나중에 서로 맞춰나가는 것이 상당 부분 관행화된 측면이 있습니다.

개발회사와 개발자가 요구사항을 분석하고 통제하는데 능력을 갖추고 있다면 100%는 아니지만, 고객의 요구사항 변경을 상당부분 통제 가능한 범위 안으로 가져올 수도 있습니다. 

스스로가 주먹구구 식으로 개발을 하면서 고객에게만 덤터기를 씌우는 것은 스스로에게 이득이 될 것이 없습니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/요구사항분석 개발자, 변경, 분석, 소프트웨어, 요구사항

  1. 포스팅 잘 읽었습니다. CMMI에서도 요구사항에 대해서 요구사항을 먼저 "개발" 하고 그 다음 레벨이 요구사항 "관리"입니다. 지속적으로 요구사항이 바뀌기 때문이지요. 본문의 내용과 비슷한 맥락이라 허접 답변 남기고 갑니다. ^^

  2. hoya님 안녕하세요.
    CMMI도 결국 소프트웨어를 잘 개발하기 위한 것이 목적이므로 근본 원리는 같습니다.

  3. 어쩌면 가장 중요한 차이점은,
    요구사항이 변경되고 나서 재계산되는 시간, 비용의 차이가 아닐까 생각이 됩니다.
    한국에서는 변경되도 마감일이나 비용이 변하지 않으니 말이죠..

  4. 구차니님 안녕하세요.
    요구사항이 변경되면 그에 따른 영향평가가 따라야 하고, 계약이 변경되어야 하는데, 우리나라에서는 스펙따로 계약 따로이기 때문에 요구사항이 2배로 늘어도 계약은 변하지 않는 문제가 있죠.

살아남은 개발자들

2009.07.03 23:23 by 전규현


잠시 후 Google blogger로 이동됩니다.



소프트웨어 업계에서 주변을 둘러보면, 실력은 없으면서 탁월한 생존력으로 살아남은 개발자들을 볼 수 있습니다.

소프트웨어 개발 실력은 떨어지지만, 업무지식을 속속들이 알고 있는 개발자
회사의 개발정보를 꼭꼭 숨겨서 자신만 알고 있는 개발자
과거에 개발해 놓은 소스코드의 문서도 만들지 않고 뒤죽박죽으로 섞어놔서 자신이 아니면 유지보수를 못하게 만들어 놓은 개발자
탁월한 인화력으로 후배 개발자들과 똘똘 뭉쳐있는 개발자
미래에 경쟁이 될만한 새싹은 미리 밟아 버리는 개발자(관리자)
화려한 언변으로 경영자들에게 거짓된 신임을 얻고 있는 개발자

위와 같은 방법의 생존이 소프트웨어 업계에서 살아가는 한 방법이기도 하지만, 또 일부 기술은 부러운 기술이기도 하지만, 이는 결국 회사와 개발자 모두의 경쟁력을 갉아 먹고, 그 부메랑은 개발자에게 돌아옵니다. 이런 방식으로는 10년, 20년 꾸준히 소프트웨어 엔지니어로서 일을 하면서 성장하기는 어렵습니다. 개발자로서 오래 살아남고 싶다면, "생존력"보다는 "경쟁력"이 필요합니다.

"경쟁력"이 구체적으로 무엇인지는 제 블로그 전반에서 계속 주장하고 있으니 살펴보세요. ^^

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 경쟁력, 생존력, 소프트웨어

  1. 괜히 이글에 찔리네요 ㅋ_ㅋ;;

  2. 안녕하세요. 스스로를 아는 것이 큰 힘입니다.

  3. Blog Icon
    개발자

    생존력있는 사람이 오래갑니다..
    님이 어려서 아직 멀..모르고 있네여...

  4. 안녕하세요. 익명님 :)

    제가 동안이라... 실제는 그렇게 어리지 않습니다. ^^
    오래 살아 남는 것도 중요하기 하죠. 본인의 가치관에 따라 다를 것 같습니다.

    현실적으로 진짜 일리 있는 말입니다. 현실적인 지적입니다.

    개인적인 관점으로만 보면 서로 자신만 살아 남는 것이 좋겠죠. 여러 회사를 컨설팅하다보면 특히 금융권 등에서 이런 개발자가 많은 것을 알 수 있습니다.
    그러다 보니 모두 서로 발목을 잡아서 회사나 각 개발자는 성장이 어려워지고, 본인들도 살아는 남지만 또한 운신의 폭이 작아지는 것을 종종 봐 옵니다.

    하지만 현실적으로 이렇게 생존모드 외에 별 방법이 없는 것을 이해는 합니다. 할줄 아는게 생존이라서 자신의 지식을 감추고 자신이 없으면 잘 안돌아가게 하는 수 밖에 없더군요. 이 때 자신만 내놓으면 자신만 손해보는 현상이 발생하죠. 이게 악순환... 우리나라 대부분의 소프트웨어 회사에 존재하는 거죠.

    선순환이 그렇게 쉬면 누구나 다 하겠죠. 회사, 개발자 모두 바뀌어야 모두에게 이익인데, 선순환의 시작은 대단히 어렵습니다. 제가 하는 일이 선순환이 시작될 수 있도록 회사를 바꿔주고 개발자를 교육하는 일입니다.

도대체 얼마나 자세히 적어 달라고?!

2009.06.29 23:58 by 전규현


잠시 후 Google blogger로 이동됩니다.




소프트웨어 개발자들에게 문서 작성은 고역이 아닐 수 없습니다. 그래서 문서는 소프트웨어를 개발한 후에 후배들에게 소프트웨어에의 스펙과 구조를 설명하기 위해서 작성하곤 합니다. 이런 경우에는 문서의 효용성도 별로 없을 뿐더러 문서가 제대로 작성되었는지 알기도 어렵습니다. 또 개발자들은 기억을 더듬어서 문서를 작성하기도 어려울 뿐더러 이러한 작업은 하기 싫은 고역이 될 수 밖에 없습니다.

소프트웨어를 개발하는데 있어서 필수적인 문서의 대부분은 개발한 내용을 정리하기 위해서 만드는 것이 아니고, 소프트웨어를 개발하는데 필요한 내용을 앞 단계에서 작성하는 것입니다.

즉, 설계를 하기 전에 스펙을 작성하고
구현을 하기 전에 설계서를 작성하고
테스트를 하기 전에 테스트 계획 및 TCL(Test Case List)를 작성합니다.

하지만 현실에서는 이렇게 작성된 문서를 가지고 다음단계 작업이 잘 안 된다는 문제가 있습니다.
즉, 다른 개발자가 작성한 스펙을 가지고 설계 및 구현(코딩)을 할 수가 없는 경우가 대부분입니다.

스펙을 제대로 작성하려면 남이 설계할 수 있을 정도로 상세하게 적어야 하는데, 잘못하면 백과사전이 되고 또는 흔히 빈약한 스펙서를 작성합니다. 이렇게 되면 스펙을 작성한 사람이 또 설계자에게 계속 스펙을 설명해줘야 합니다. 

이 글을 읽고 있으면서 이것이 뭐가 문제라고 생각하신다면 이미 가내수공업식 개발에 익숙해지신 겁니다. 한 개발자가 스펙도 작성하고 설계, 구현, 테스트를 모두 다하는 이런 가내수공업식 개발은 회사는 성장의 한계에 부딪히고, 개발자는 성장하지 못하는 악순환에 빠지기 쉽습니다.

개발문서는 그 문서를 보고 다음단계의 개발자들이 충분히 일을 진행할 수 있을 정도로 상세해야 합니다.
따라서 상세화 정도는 상황에 따라서 다르다는 것을 알 수 있습니다. 설계자가 해당 제품에 대해서 빠삭하게 알고 있으면 기능스펙을 적당히 적어도 문제가 없을 것이고, 신입사원에게 일을 시키려면 좀더 자세히 적어야 할 것입니다. 

또한, 좀더 작은 양으로 이해 가능한 문서를 작성하려면 소프트웨어를 다양한 뷰에서 바라보고 적어 주는 것이 좋습니다. 따라서 스펙을 작성할 때는 소프트웨어를 인터페이스에서 바라본 모습, UI에서 바라본 모습 그리고 기능, 비기능적인 내용을 적어주면 기능에 대하여 많은 양을 설명한 것보다 더 이해하기 쉽습니다.  설계에 있어서도 소프트웨어의 아키텍처를 데이터 관점, Flow 관점, 시간의 흐름, 시스템의 상태 등 다양한 관점에서 바라본 모습을 적당히 표현해 주는 것이 하나를 자세히 적어 주는 것보다 좋습니다.

매우 추상적인 글을 적어 놓은 것 같지만, 실제 개발문서를 제대로 적기 시작하면 잘 적었는지? 못 적었는지는 명확하게 구분 됩니다. 작성된 문서를 가지고 다음 단계 개발자들이 별 무리 없기 개발을 할 수 있고, 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

그래서 이를 위해서 기법을 쫓기 보다는 실제로 필요한 것이 무엇인가 생각하고 실질적인 접근이 필요합니다. 잘못 익힌 기법은 독이 될 수 있습니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 TCL, 문서, 설계, 소프트웨어, 스펙

  1. 문서가 실용적이어야 한다는 의미는 공감합니다만,

    > 문서가 거의 바뀌지 않는다면 잘 작성된 것이고, 그렇지 않으면 잘 작성되지 않은 것입니다.

    이 부분은 일반적인 이야기가 아니지 않나 생각됩니다. 코드는 문서보다 훨씬 빠르게 바뀌기 때문에 문서는 뒤쳐지게 되어있는데, 아마도 말씀하신 의미상으로는 문서를 이런 변화까지 수용하게 적어야 된다는 것이 아닐까 추측되는데, 그건 잘 작성된 기준으로 생각하기에는 적합한 기준이 아니지 않나 생각됩니다. 문서가 바뀌기 때문에 잘 작성하지 않았다는 것은...

    또한, 다음 단계(?)의 개발자가 이를 활용할 수 있는 프로젝트가 있는 반면, 그렇지 않은 프로젝트도 많이 있기도 한 것 같습니다.

  2. charlz님 안녕하세요.
    좋은 의견 감사합니다. charlz님의 댓글을 보면 "문서"라는 말을 가지고도 서로 다른 이미지를 그리고 있다는 생각이 듭니다.

    예를 들어서 스펙서를 기준으로 보면 설계단계나 구현단계에서 스펙서가 바뀌는 것은 스펙이 바뀐 것이고, 그 변경에 대한 비용을 몇곱절로 치뤄야 합니다. 하지만 개발 기간내에 스펙이 전혀 바뀌지 않는 프로젝트는 찾아보기 힘들죠. 하지만 변경을 최소화는 해야 합니다. 설계가 진행되고 코드가 진행됨에 따라서 스펙서를 바꾸지는 않죠.

    그리고 설계서의 경우에도 코드가 진행됨에 따라서 아키텍쳐나 인터페이스의 변경이 있기 전에는 설계서가 변경되지 않습니다. 문서와 코드가 같이 발전해 나가는 경우는 분석, 설계, 구현단계가 적당히 밍글된 형태일 수도 있습니다. 사실 크고 작은 많은 프로젝트가 이렇게 진행되고 성공적으로 잘 끝나기도 합니다. 하지만 이런 방법으로 계속 성장하기는 어려움이 있습니다.

    사실 문서가 잘 작성되었는지 판단하기는 대단히 어렵습니다. 그래서 그 한방법을 언급해 봤습니다.

    제가 항상 주장하는 것은 개발자들이나 개발사들의 현재 상황에 따른 전투적인 대응방법이 아니고 개발자들이 꾸준히 성장하고 실력도 향상되며 현재 프로젝트를 잘 수행해내기 위한 원론적인 방법들이 주류를 이룹니다. 그런 관점으로 읽어주세요.

    charlz님의 의견과 같은 여러 관점은 제가 많은 도움이 되네요. 감사합니다.

  3. Blog Icon
    ^^

    문서라 지긋지긋하지요.

    정말 돈받고 만드는 프로덕트로서의 문서들은 가끔 종이값과 타이핑값을 받기 위해 만드는거 아닐까 하는 생각이 들곤 합니다. 그래서 도큐멘트도 아니고 산출물이라고 하는게 아닐까 생각하죠. ^^

    SI성 프로젝트를 많이 하다보니 몇십종의 산출물들이 과연 필요나 할까 싶을떄가 많기도 하고, 왜 보지도 않고 쓸데도 없는 문서를 주구줄창 만들어야 할까 싶습니다.

    경험적으로 생각해보면 산출물은 의사전달을 위한 문서, 생각을 정리하기 위한 문서, 점검을 위한 문서 세종류가 있는 것 갑습니다. (그냥 제 기준입니다.)

    무엇을 위해서 작성을 하는지가 중요한 것 같은데.. 문서 프레임에 압도당할때가 만은데요. 잘하지는 못하지만 고객이나 내부 팀원이 쓸 수 있을 만한 표현력이 들어가면 문서의 프레임이야 얼마든지 고칠 수 있지 않나 싶네요. ㅎㅎ

    뭐 항상 만들고 나면 이것 저것 한방에 보고 싶다는 욕심에 덕지덕지 붙여넣다가
    질려서 흐지부지 되는 경향이 있어서.

    될 수 있으면 간략한게 좋지 않나 생각이 드네요.

    특히나 고객의 요구사항이 수시로 변할떄는 말이죠.

  4. 산더미같이 많은 문서를 만드는 프로젝트들은 아주 잘못된 관행입니다. 소프트웨어 개발에 대해서 잘 모르는 고객이 거대한 방법론에 있는 문서를 무작정 다 요구하곤 합니다. 그 방법론에서도 문서를 다 만들라고 하지 않는데도 잘못 적용하는 것이지요.
    하지만 개발사 입장에서 고객이 요구하는데 안만들 수는 없는 노릇이지요. 수많은 문서 중에서 실제 개발에 필요한 문서는 소수에 불과합니다. 그런 문서만 제대로 만들고 나머지 프로세스나 관리를 위한 문서들은 최소한의 노력만 들이는 것이 좋습니다.

커뮤니케이션 오류

2009.04.19 23:16 by 전규현


잠시 후 Google blogger로 이동됩니다.



소프트웨어 프로젝트를 진행하다 보면 수많은 커뮤니케이션의 오류를 발견하게 됩니다.
문서화 되지 않은 수많은 의견과 결정들에 대한 오해와 대화를 하면서 발생하는 표현의 오류는 한 두개가 아닙니다. 이는 비단 프로젝트에서 뿐만 아니라 일상생활에서도 벌어지는 현상이지만, 일상생활에서의 커뮤니케이션 오류는 그렇게 심각하지 않을 수 있지만, 프로젝트에서의 커뮤니케이션 오류는 심각한 손실을 초래하기 때문에 조심할 필요가 있습니다.

따라서 프로젝트를 진행하면서 오가는 대화나 기록은 명확해야 합니다. 미사여구보다는 직설적인 화법으로 핵심을 정확하게 말해야 합니다. 또 하나의 문장은 사실, 의견, 추축, 가정, 결정 또는 정보일 수 있습니다. 그런데, 현재 하고 있는 말이 사실인지 의견이지 명확하게 하지 않으면 수많은 오해가 발생합니다.
 
특히, 의견이나 추측을 사실처럼 얘기하면 다른 사람들은 이를 바탕으로 계획을 세울 수도 있습니다. 또 경영진은 잘못된 결정을 내려서 큰 손해를 보게 될 수도 있습니다. 그리고 가정으로 이미 확인된 사실처럼 얘기하면 프로젝트는 큰 리스크를 안게 됩니다. 

따라서 프로젝트에서는 구체적으로 가정과 종속관계를 파악하는 활동을 하게 됩니다. 프로젝트를 진행하면서 확인되지 않은 사실이나 결정해야 할 것들 및 종속되어 있는 항목을 찾아서 리스크관리를 해야 하기 때문입니다. 이러한 하나하나가 프로젝트의 리스크라는 것을 생각하지 못하면 지뢰밭을 걷는 것과 같습니다.

이러한 커뮤니케이션 오류를 제거하려면 이 문장이 사실인지 의견인지를 정확하게 구분하여 적는 것이 좋습니다. 특히 누구의 의견이라고 적을 수도 있고, 누구의 결정이라고 표현할 수도 있습니다. 그리고 가정은 언제 확인하고 해결이 될지 계획까지 적는다면 누구나 해당 내용이 확인이 필요한 가정사항이고 상황에 따라서 프로젝트의 위험 요소라는 것을 쉽게 파악할 수 있습니다. 이렇게 직설적이고 확실한 표현이 삭막하게 들릴 수는 있지만, 프로젝트를 진행하는데 있어서는 더 좋은 표현법입니다.

연인에게 이러한 표현법은 안되겠지요? 
당신을 사랑하는데 이 표현이 사실, 의견, 추측, 가정 또는 결정일까요? 이를 구분해서 말한다면 따귀맞기 십상이겠네요.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  
저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/커뮤니케이션 가정, 결정, 리스크, 문서, 사실, 소프트웨어, 의견, 추측, 커뮤니케이션, 표현, 프로젝트

버그관리시스템 사용 현황 조사 결과

2009.04.12 20:23 by 전규현


잠시 후 Google blogger로 이동됩니다.



그동안 제 블로그에서 50일동안 버그관리시스템 사용 현황을 조사하였습니다.
소프트웨어를 개발하는데 필수적인 요소 중의 하나인 버그관리를 어떻게 하고 있는지 조사하기 위함이었습니다.
물론 여기서 말하는 광의의 버그를 말하며, 이슈관리시스템, 이슈추적시스템이라고도 불리며 모두 같은 시스템이라고 생각하시면 됩니다.

질문은 다음과 같습니다.

 버그관리는 어떻게 하십니까? 버그관리를 위해서 사용하는 툴이나 방법을 모두 선택해주세요.

복수 응답을 허용하면서 투표한 결과 총 73표가 모였습니다.
그럼 그 투표결과를 분석해보도록 하겠습니다.

 버그관리시스템 사용 vs. 미사용 비율

보시다시피 버그관리시스템은 68%만이 사용하고 있었고 32%의 사용자는 버그관리시스템을 사용하고 있지 않습니다.  버그관리시스템을 사용하지 않은 그룹은 버그관리를 하지 않거나, 엑셀파일 또는 워드파일로 관리를 하거나 전문 버그관리시스템이 아닌 게시판 등을 사용하고 있었습니다.

소스코드관리시스템 미사용율은 25%였는데, 이보다 더 높은 수치를 기록하고 있습니다.

버그관리시스템을 사용하는 것만으로도 소프트웨어 개발 생산성 및 효율성은 상당히 향상됩니다. 그리고 소프트웨어의 규모나 복잡성이 증가할 수록 시스템 없이 파일 등으로 관리하는 것은 점점 불가능해집니다. 물론 소프트웨어가 아무리 작아도 엑셀파일로 관리하는 것보다는 버그관리시스템이 훨씬 낫죠.
버그관리시스템도 소스코드관리시스템과 마찬가지로 단순히 설치해서 사용하기만 하는 것은 아주 기초적인 혜택만 누리는 것입니다. 버그관리시스템의 혜택을 제대로 누리기 위해서는 개발 프로세스도 필요하며 오랜 훈련과 경험이 필요합니다.

 전체 투표 결과


전체 투표결과는 위와 같습니다. 엑셀로 버그관리를 하는 비율(18%)와 자체 제작한 버그관리시스템 사용 비율이 매우 높다는 것에 놀리자 않을 수 없었습니다. 특히 자체 제작한 버그관리시스템은 실패하는 것이 일반적입니다. 버그관리를 간단하고 쉽게 생각하고 자신의 회사에 딱 맞는 버그관리시스템을 만들 수 있다고 착각하지만, 실제 만들어서 사용하다보면 문제점이 많습니다.

우선 자신의 회사에 딱 맞는 시스템이라는 것이 기존의 회사에서 개발하는 방식에 문제가 있는 경우가 대부분이기 때문에 이에 딱 맞추면 회사의 개발 프로세스는 나아지는 것이 없습니다. 오히려 제대로 된 툴에 회사의 프로세스를 변화시켜서 맞춰나가는 것이 성공할 가능성이 더 높습니다. 또 버그관리시스템에 대한 전문적인 지식 없이 표면적인 기능만 구현을 하게 되면 계속되는 기능 추가 및 유지보수 이슈로 본업인 제품개발에 지장을 초래할 수도 있습니다. 이러다가 결국 포기하고 제대로된 툴을 사용하다보면 그동안 나쁜 버릇들이 몸에 베어서 정상적인 경우면 1,2개월이면 적응할 것을 적응 기간이 몇배 더 들고 또 실패할 수도 있습니다. 운동도 처음에 나쁜 자세가 몸에 익어버리면 제대로 배우는데 처음부터 배우는 것보다 몇배 더 오래 걸리는 것과 같은 원리입니다.

따라서 버그관리시스템은 처음부터 기존에 나와았는 상용이나 무료 툴들을 사용하는 것이 올바른 방법입니다. 서투른 다른 시도는 안하니만 훨씬 못합니다.

버그를 관리하지 않는 비율이 7%나 되는데, 음.. 버그가 하나도 없다는 얘기일까요? 신기하군요. 회사가 작다면 작은 PC에다가 Matis등의 무료 버그관리시스템을 설치해서 써보는 것도 좋은 방법입니다. 제대로 쓰기만 하면 개발 패러다임이 바뀔 것 입니니다.

 버그관리시스템의 사용 비율


버그관리시스템을 사용하고 있는 집단에서의 시스템 사용비율을 따로 뽑아봤습니다.
그 결과 Mantis가 32%를 기록했습니다. 즉 버그관리시스템을 사용하고 있다면 3명중 1명은 Matis를 사용하고 있다는 것입니다.
그리고 Trac, JIRA, Bugzilla등의 순서인데, IBM CQ나 Teamwork를 쓰고 있는 회사도 소수 있었습니다.
Matis는 설치가 쉽고 사용이 쉽고 직관적이라서 많은 개발자들이 선호하는 것으로 보입니다. 또 무료라는 것도 무시할 수 없는 매력이겠지요.

 결론

버그관리시스템의 사용비율은 예상외로 낮았습니다. - 68%
또, 자체적으로 만들어서 사용한다는 비율도 꽤 높았습니다. - 10%

이를 미루어 볼 때 버그관리에 대한 의식이 매우 낮고, 버그관리를 만만하게 보는 경향을 엿볼 수 있었습니다.
소스코드관리시스템을 만들어서 사용한다는 개발자들은 별로 보기가 힘듭니다. 일단 어려워보이거든요.
하지만 버그관리시스템을 팔기위해서가 아니고 자신들이 사용하기 위해서 만든다고 하는 개발자들을 쉽게 볼 수 있는 이유는 버그관리시스템이 만들기 쉽다고 생각하는 것 같습니다. 

DB 좀 핸들링 할 줄 알고 Web 프로그래밍을 할 수 있으면  버그관리시스템을 만들 수 있다고 생각합니다. 버그관리시스템은 그렇게 간단한 것이 아닙니다. 크고 작은 소프트웨어 회사의 전체 개발프로세스를 완전히 이해하지 않으면 이를 개발할 수는 없습니다. 현재 유명한 Mantis 등의 버그관리시스템들도 모두 수십년에 걸쳐서 축적된 버그관리 철학이 녹아 있는 것입니다.

따라서, 이러한 버그관리시스템에 잘 적응해여 사용하는 것만으로도 수십년간 축적된 개발 프로세스와 문화를 흡수할 수 있는 좋은 기회입니다.

버그관리가 별거 아니라고 생각하는 서투른 착각으로 이런 좋은 기회를 차버리는 과오를 범하면 안되겠습니다.

버그관리시스템을 도입하거나 사용하시면서 의논할 사항이 있으면 언제든지 연락을 주세요. 도움을 드리도록 하겠습니다. 감사합니다.



* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  
저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/버그관리 Bugzilla, ClearQuest, Jira, Mantis, Teamwork, trac, 버그관리, 소프트웨어, 엑셀, 이슈관리, 이슈처적, 투표

  1. 맨위에 도표를 보고 생각보다 많이 쓴다고 생각했었는데...;;
    저희회사도 이제막 도입을 검토중이거든요..
    프로젝트에 적용할려면 또 얼마나 걸릴지 모르겠지만;;
    늦게나마 도입하려는 시도가 보인다는것만으로도 감사하다고 해야할까요 ㅎㅎ;
    그나저나 RSS보다 블코 위젯 메인에뜬걸 보고 들어오다니;; 축하드립니다 ^^

  2. 어떤 시스템을 도입하려하시나요? Mantis? JIRA? 도입과정에서 어려움이 있거나 사용상의 이슈등 궁금하신 것이 있으면 언제든지 문의하세요. 감사합니다.

소프트웨어 공학이 왜 필요하지? 복잡하기만 한데...

2008.12.11 14:16 by 전규현


잠시 후 Google blogger로 이동됩니다.



소프트웨어 공학 블로그를 운영하고 있으면서도 전면에는 소프트웨어 공학이라는 말을 사용하고 있지 않습니다. 그 이유는 소프트웨어 공학은 막연하고 왠지 모르게 문서도 많이 만들어야 할 거 같고, 절차도 엄격히 따라야 할 것 같아서 부담스러운 느낌을 줄 수 있기 때문입니다.

이것이 다 소프트웨어 공학에 대한 오해에서 비롯된 것 같습니다. 이미 유행이 한번 쓸고 지나간 CMMI나 외국의 유명한 방법론들을 도입했다가 실패한 경험과 소문들 때문일 겁니다. 
 
Naver 백과사전에서 소프트웨어 공학을 찾아봤습니다.
다음과 같이 설명되어 있더군요.

요약
컴퓨터 소프트웨어의 계획·개발·검사·보수·관리 등을 위한 기술과 그것을 연구하는 분야이다. 소프트웨어의 규모가 커지고 복잡해짐에 따라 공학적인 접근으로 구조화 프로그래밍을 도입한 것이다

본문
컴퓨터 시스템의 가격에서 소프트웨어가 차지하는 비율은, 컴퓨터가 생겨난 직후인 1955년경에는 20% 미만이었지만, 그 후에 급격히 높아져 80년대 후반에는 80~90%에 이르렀다. 이것은 요구되는 소프트웨어의 규모가 커짐에 따라 복잡해진 데 기인한다. 또, 요구되는 소프트웨어가 점차 복잡해진 반면, 그것에 대처할 수 있는 소프트웨어 기술(개발기술 및 관리기술)이 뒤따르지 못하기 때문이다. 그 결과, 소프트웨어는 항상 납기()에 늦어져 비용이 많이 들고 당초의 규정을 충족시키지 못하고 있으며, 신뢰성이 없고 영구히 보수해야 하고, 투명성()이 결여되고, 보수할 수가 없으며, 수정 ·개량할 수도 없다는 ‘소프트웨어 위기()’라고 불리는 징후가 나타나기 시작했다. 그 원인으로서, 모든 공학 분야에서 공통된 기본적인 설계절차를 밟지 않고 있다는 지적이 일기 시작하고, 소프트웨어의 개발에 스트럭처드 프로그래밍(structured programming:구조화 프로그래밍)과 같은 공학적 어프로치(approach)가 도입되기에 이르렀다.

소프트웨어에 소요되는 비용을, 계획에서 보수에 이르는 각 단계가 차지하는 비율로 보면, 요구하는 정의() 및 방법의 기술() 단계에 약 10%, 설계단계에 약 10%, 프로그래밍단계에 약 10%, 테스트 및 디버그 단계에 약 20%, 그리고 보수에 소요되는 비용이 약 50%를 차지한다. 검출되는 에러로는, 설계단계 및 그 이전의 것이 약 60%나 된다. 종래까지는 프로그래밍 단계가 강조되었으나, 소프트웨어의 ‘라이프사이클’을 인식하고 사태를 개선할 필요가 있다. 그러기 위해서는 과학적인 지식을 축적하고, 이를 실제적으로 응용해야 하는데, 이것들을 다루는 분야가 곧 소프트웨어 공학이다.


상당히 복잡하죠. 매우 잘 쓰여진 글이지만 한번에 딱 뭐다라고 이해하기 어려운 글입니다.
소프트웨어 공학이 무엇인지 한마디로 정의하면 다음과 같습니다.
 
"소프트웨어를 최소 비용으로 최소 시간에 개발하는 방법"
 
소프트웨어 공학의 목적 자체가 이거니까 이를 증명할 필요는 없습니다. 

방법론이나 소프트웨어 공학의 일부를 적용했더니, 시간도 더 많이 걸리고 개발자들이 더 힘들고 효율적이지 못하면 뭔가 잘못된 겁니다. 단순한 Learning curve가 아니라면 다시 생각해봐야 합니다. 어딘가 잘못된 부분이 있을 겁니다. 주변에 전문가가 있으면 의논하는것이 좋습니다.

위 정의에 대해서는 지금으로서는 믿어주기를 바랄 수 밖에 없습니다. 위의 말은 간단해도 소프트웨어 개발현장에서는 수많은 충돌이 일어납니다. 문서를 만드는 것이 더 오래걸린다고 하기도 하고, 프로세스는 거추장스럽다고 하고, 개발자와 직접 얘기를 하는 것이 더 빠르다고 합니다. 이 정도는 간단한 이슈입니다. 훨씬 복잡한 상황이 많기 때문에 일단은 믿고 시작하는 수밖에 없습니다.

위 백과사전의 설명을 보면 80년대 말에 미국에서는 다음과 같은 일들이 일어났다고 합니다.
소프트웨어는 항상 납기()에 늦어져 비용이 많이 들고 당초의 규정을 충족시키지 못하고 있으며, 신뢰성이 없고 영구히 보수해야 하고, 투명성()이 결여되고, 보수할 수가 없으며, 수정 ·개량할 수도 없다는 ‘소프트웨어 위기()’라고 불리는 징후가 나타나기 시작했다.
 
내 기억으로는 우리나라 80년대 후반은 소프트웨어 태동기였기 때문에 우리와는 거리가 먼 얘기죠.
오히려 위 문장이 지금의 소프트웨어 환경 및 현상과 많이 비슷합니다.
미국 및 소프트웨어 선진국들은 이를 해결하기 위해서 10~20년을 노력했습니다. 그래서 나온 것이 소프트웨어 공학인데, 우리도 똑같이 10~20년을 낭비할 필요는 없다고 봅니다. 모두들 노력만하면 그러한 시행착오 없이 몇 년 안에 우리도 소프트웨어 공학을 개발 현장에 자리잡도록 할 수 있습니다.
 
소프트웨어 엔지니어들… 고집 셉니다.
많은 개발자들이 자신들이 하고 있는 방법이 최선인줄 알고 있습니다. 하지만 이미 전세계의 선배들이 수십년 전부터 이미 고민했던 문제를 또 되풀이하고 있는 경우가 대부분입니다.
특별히 배운 것 없이 선배들에게 좀 배워서 하던 방식대로 개발을 하고 있다면 거의 나름대로의 개발방식으로 개발을 하고 있을 겁니다. (제가 컨설팅을 하면서 실제로 느낀 겁니다.)
"우리는 다르다"라고 하시는 분들도 매우 많습니다. "우리는 다르기 때문에 일반적인 방법을 적용할 수 없다"라고 말씀을 하십니다. 
99%의 경우 다르지 않습니다. 다르지 않으니 다행이지요. 배우고 따라할 것이 있으니까요. 
우리는 세계 소프트웨어 역사에 비해서 1/3밖에 안되는 역사를 가지고 있다는 것을 명심해야 합니다. 한마디로 배울 것이 많다는 거죠. 자신의 방식을 고집하고 있다면 마음을 열고 넓게 봐야 합니다.

소프트웨어 공학은 학교에서 배울 수 없다고 되어 있습니다. 물론 대학에 과목이 있기는 하죠. 하지만 용어들을 익히는 것이지 실제로 그것이 무엇을 뜻하는지는 대부분의 학생들은 이해를 못한다는 겁니다. 즉, 현장에서 배우는 것이 소프트웨어 공학입니다. 대학에서 배운 학생들은 더 빨리 배우기는 하겠죠. 따라서 언제라도 시작해도 늦지는 않습니다. 그동안 쌓은 경험이 도움이 될 수 있습니다. (방해가 되는 경우도 많이 봤습니다.) 그리고 쉽게 배울 수 있는 것도 아니고 그 범위도 매우 큽니다. 시간도 많이 걸리죠. 또, 그 과정에서 별 쓸데 없는 것에 매달리면서 시간 낭비하는 경우도 정말 많습니다.

이럴때 유경험자나 전문가가 주위에 있는 것이 정말 좋습니다. 머리에 지식을 넣어주기는 어려워도 서로 의견을 주고 받고 있다면 쓸모없은 것 공부하느라고 시간을 허비하는 것은 줄일 수 있습니다. 
 
앞으로 계속 연재해 나갈 소프트웨어 공학의 구체적인 내용들이 소프트웨어 공학을 이해하고 실제로 개발에 접목하는데 도움이 되기를 기대합니다. 
 
소프트웨어 개발 시의 애로점, 개발자 진로의 고민, 소프트웨어 공학에서 알고 싶은 내용은 언제든지 메일이나 방명록으로 의견을 주시면 정성껏 답을 드리고 같이 의논할 수 있도록 하겠습니다.
 
 (아래는 소프트웨어 Requirements에 관련된 재미있는 그림입니다. Document 부분의 맨땅이 인상적이네요.)
저작자 표시 비영리 변경 금지
신고

전규현 소프트웨어이야기 소프트웨어, 소프트웨어 개발, 소프트웨어 공학

  1. 팀에서 개발경험없는 소프트웨어 공학을 전공한 석/박사님들과 충돌을 많이했습니다. 학교에서 배우지 못하는 학문이라서 그랬을까요? ^^;
    앞으로 올라올 포스팅이 기대되네요... 저도 많은 의견 올리겠습니다. ^,.^;

  2. 정의의소님 안녕하세요.
    실전을 모르고 대학에서 소프트웨어 공학을 연구하시는 분들이 계십니다. 그런 분들을 헐뜻는 것은 아니지만 그런 분들은 계속 연구쪽으로 하시는 것이 좋겠죠.
    실전은 다르니까요. 물론 그런 분중에는 실전 경험도 두루 갖추고 계신 분들이 계시죠.
    연구파와 실전파 정도로 나눌 수 있겠죠.
    미국에서도 소프트웨어 공학을 가르칠 때 "가르칠 수 없다", "배울 수 없다"라고 하고 가르친다고 합니다.
    현실 소프트웨어 개발 현장에서는 탄탄한 이론에 기초를 둔 실전파들이 필요하다고 생각합니다.

    그런 경우 그분들이 실전을 잘 몰라서 그런다고 생각하십시오. 소프트웨어 공학이 기계적으로 적용하면 된다고 생각하면 그분들이 잘못 배운 것이거나 경험없이는 안되는 것이 소프트웨어 공학인 것이지요.

    제 생각에는 소프트웨어 공학은 실전 경험이 있는 분들에게 가르치는 것이 좋을 것 같습니다. 현재 KAIST에는 경험자를 위한 소프트웨어 공학 코스가 있는 것으로 알고 있습니다. 대부분 10년 이상 경험이 있는 분들이 수강을 하는데, 그정도는 되야 가르치는 것을 이해한다고 하더군요.

  3. 제 trackback에 있어서 타고 왔더니 정말 좋은 글이 있군요;ㅁ;
    금일 다음 클릭애드클릭스 블로그 선정이 안되어서 우울했는데..
    정리의 진수를 보여주시는군요..잘보고 갑니다^0^/

  4. 열정태하님 안녕하세요.
    소프트웨어공학에 관심이 있으신 것 같아서 트랙백을 남겼습니다. 블로그 가보니 좋기만 하던데 왜 선정이 안되었을까요? 너무 뻑뻑하네요. 힘내세요.
    감사합니다.

  5. 트랙백 있길래 와봣습니다.
    참 좋은 내용은 많네용..
    흠..소프트웨어 공학..학교때 배워도.어찌보면...그때는 아하 그랫어도 실상 개발자로 살아가다보면 간과 하게되죵..역으로 다시 서적을 통해 보고 있습니다.
    잘 보고 갑니다.

  6. 쇼팬하워님 안녕하세요.
    그래서, 소프트웨어 공학에는 경험이 정말 중요한 것 같습니다. 우리가 아는 유명한 소프트웨어 공학자들도 대부분 실전파 잖아요.

  7. Blog Icon
    지나가다가

    그렇다면 '공학'이란 말을 빼야겠네요. ^^

  8. Blog Icon
    나르사스

    음...저는 학교에서 배울때 소공의 목적이 요즘은 빨리 만드는것보다는 유지보수가 용이하게 잘 만드는 추세로 간다고 들었던 것 같은데, 뭐가 맞는 걸까요? 연구실파는 아니셨는데요...ㅡ.ㅡ;;

  9. 나르사스님 안녕하세요.
    의견 감사합니다.
    저는 실전파 맞습니다. 그리고 소프트웨어 개발에 소프트웨어 공학을 적용하는 것은 프로젝트 비용 및 기간 단축과 유지보수를 용이하게 만드는 것 모두 해당합니다.

    추세를 말씀하셨네요. 갈수록 소프트웨어의 유지보수가 중요해지고 있습니다. 실제로 소프트웨어는 개발보다도 유지보수에 더 많은 비용이 듭니다. 그래서 유지보수의 비용을 줄이는 것도 매우 중요합니다.

    주먹구구식으로 개발하는 소프트웨어 프로젝트는 초기에는 빠른 것 같지만, 프로젝트가 막바지로 갈수록 뒤죽박죽이 되어갑니다. 그리고 이렇게 개발한 프로젝트가 더 빨리 끝나는 경우도 가끔 있으나 유지보수에 더 많은 비용이 드는 것이 일반적이지요.

  10. 녹차프린스님의 글부터 시작해서 트랙백을 따라서 여기까지 왔습니다.
    알찬 글들이 많이 있네요.
    잘 읽고 갑니다. 구독링크하고 자주 방문하겠습니다. ^^*

  11. 필넷님 안녕하세요.
    새해 복 많이 받으세요. 좋은 블로그를 운영중이시더군요. RSS 등록해서 볼려고 합니다. 감사합니다.

효과적인 버그 처리 방법

2008.12.09 13:31 by 전규현


잠시 후 Google blogger로 이동됩니다.



HannaKim님의 이 버그를 누구에게 넘겨 줄 것인가? 라는 글에 대한 의견을 적어보려고 합니다.
의견이라기 보다는 주욱 해오던 방법입니다. 너무 당연한 얘기일수도 있습니다.

개발자에게 버그를 할당하여 처리하는 방법은 여러가지 형태가 있습니다.
주먹구구식으로 개발자에게 직접 버그가 보고되고 처리되는 형태부터 철저한 Workflow를 따라서 관리자가 담당개발자를 할당해서 처리하는 방법까지 다양합니다.

여기서는 자질구레한 기타 방법은 제외하고 정상적으로 Bug Tracking System를 사용하면서 체계적으로 버그를 관리하고 해결하는 방법 내로 국한을 해서 설명하도록 하겠습니다. 다른 방법을 사용하고 있다면 심각성을 깨달으시고 빨리 방법을 고치셔야죠.

개발팀의 규모나 프로젝트의 종류는 천차만별입니다. 기술을 잘 아는 관리자가 있기도 하고 기술을 잘 모르는 관리자가 있기도 합니다. 하루에 버그가 하나도 보고되지 않을 수도 있고, 하루에 수백개의 버그가 보고되는 경우도 있습니다.

이러한 모든 경우에도 버그는 가장 적절한 개발자에게 신속히 할당이 되어서 신속히 해결을 해야 합니다. 해결이라함은 꼭 버그를 Fix하는 것을 의미하는 것이 아니고 연기할 수도 있고, 수정하지 않기로 할 수도 있고, 버그가 아닌 경우도 있죠. 어쨌든 이런 요구를 항상 만족시키기란 쉽지 않죠.

그래서 사람들이 찾아낸 방법이 "자율"입니다. 완전한 자율은 아니고 "Process"와 적당히 혼합된 "자율"입니다. 소프트웨어 개발에 있어서 "자율"은 매우 자주 등장하니 그리 놀랄 일도 아닙니다.

버그할당의 의무와 역할을 관리자에게만 두는 것이 아니고, 개발자도 그 역할을 조금씩 나눠 갖는 겁니다.
버그가 보고되면 관리자나 관련 개발자나 누구나 먼저 인지를 한 사람이 버그를 할당하는 겁니다. 여기서 버그를 할당했다고 해서 당장 버그를 고친다는 의미는 아닙니다.(이는 버그 관리 정책에 따라서 다릅니다.)

모든 개발자가 모든 버그를 다 감시할 수는 없겠죠. 버그의 카테고리는 기능별, 모듈별로 모두 등록을 해 놓아서 카테고리와 담당개발자의 연관성을 높이고 개발자들은 자신과 주로 관련된 카테고리들만 감시를 해도 충분합니다. RSS Feed를 지원하는 Bug Tracking System이 있으면 이렇게 감시를 하기 편리합니다. 그리고 나면 버그 해결 스케쥴은 시스템을 이용하여 정할 수도 있고, 회의를 하기도 합니다.
버그할당의 최종 책임은 관리자에게 있으므로 이렇게도 할당이 안된 버그는 관리자가 처리를 해야죠.

이러한 방법은 대부분의 경우에 상당히 효율적입니다만, 자율에 의한다는 것은 각 구성원의 성숙도에 많은 영향을 받으므로 이를 감안해서 시행해야 할 것입니다. 

버그의 처리에는 시간이 걸릴 수 있어도 버그의 인지는 신속해야 하고, 버그의 할당도 빠르게 이루어져야 합니다. 버그인지 자체가 일주일 이상 걸리는 상황이라면 그 기간 동안 버그는 완전히 방치가 되고 있는 상황이라고 할 수 있습니다. 그래서 회사에 따라서는 버그 인치와 처리 시간을 줄이기 위해서 KPI에 이 수치를 포함해서 평가의 지표로 삼곤 하는데, 별로 바람직한 시도는 아닙니다. 어차피 자율에 의한 방법이기 때문에 좀더 성숙한 개발 문화와 이를 북돋울 약간의 당근만이 필요할 뿐입니다.

이미지출처 : Microsoft Office Online

저작자 표시 비영리 변경 금지
신고

전규현 기반시스템/버그관리 버그관리, 버그추적, 소프트웨어, 소프트웨어 개발

  1. 자율에 의해 버그가 잘 처리 되고 개발자가 자기 모듈에서 버그가 발생된다면 해당 개발자가 맡아 주는 것이 좋겠죠? 그러나 버그 리포트만 보고 어느 모듈에서 버그가 있는지 알기 어려울때가 있고 또 이전 모듈을 담당한 개발자가 더이상 일하지 않을수도 있고, 우리의 관리자가 개발자의 이름을 다 기억 못할수도 있고 등등등. 이럴때 이전 버그 할당한 히스코리나 버그의 증상을 바탕으로 버그 트래킹 시스템이 자동으로 이 버그를 픽스할만한 후보를 3명 정도 찝어 준다면 어떨까요? 물론 이 3명을 정확하게 찝어줘야 겠지만.

  2. HannaKim님 안녕하세요.
    자동으로 후보를 찍어주는 시스템이 효과를 발휘하면 대형 프로젝트에서는 정말 멋진 시스템이 될 것 같은데요. 혹시 그런 시스템을 만드신다면 기대하고 싶네요. :)

  3. 테스트팀이 개발 설계때 부터 투입되고 개발과 테스트관련 작업?이 같이 진행되면 Bug를 발견한 테스터가 직접 개발자를 Assign해도 좋다고 생각합니다. 물론 그 만큼 개발과 테스트가 유기적으로 진행되고 있어야하겠지요. 개발자와 1:1로 개발, 테스트를 진행했었는데 이게 가장 효율적이었습니다.
    즉, 현재 조직 상황과 프로세스에 따라 다르게 적용되어야 한다고 생각합니다. 프로세스 성숙도와 규모에 따라 적용하는 것이 달라지겠지요.
    Clear Quest를 사용하면서 큰 틀은 함께하면서 팀마다 다른 스키마를 적용했었습니다.

  4. 정의의소님 안녕하세요.
    각 개발자가 컴포넌트를 완전히 구분해서 개발을 하신 경우겠네요.
    테스트팀은 말씀하신 대로 개발 초기부터 투입이 되어야 합니다. V-Model만 보더라도 테스트팀이 요구사항단계부터 투입이 됩니다.
    소프트웨어 개발은 원리를 이해하는 것이 정말 중요하다고 생각합니다.

  5. 관리자 및 개발자의 성숙한 소프트웨어 개발 프로세스 문화 뿐 아니라 QA팀에서의 Report도 많은 비중을 차지할 것 같습니다.
    일단 버그의 담당자를 지정하기 위한 자료는 Issue Report 가 전부이기 때문이죠.
    그리고 Stracking System을 Product별로 커스터마이징 해서 킥 오프 단계에서 각 개발 컴포넌트와 그 담당자를 매칭해 주고 자동 Assign 하면서 이 관계를 지속적으로 업데이트하는 방법도 효율적일 것 같습니다.
    (가능한 Tracking System 및 양질의 Issue Report, 모든 부서의 원활한 커뮤니케이션이 선행되어야 하는... 어려운(...?!?!?!) 점이 있겠지만요.)

  6. Noel님 안녕하세요.
    상당히 Detail하게 적어주셨네요. 말씀하신 모든 부분이 이슈 할당 및 처리에 도움을 주는 방법들이죠.
    버그 리포트 주체를 QA팀이 아닌 "누구나"로 확장하면 또 고려해야 할 것들이 있겠죠.
    워낙 다양한 경우가 있어서 원리만 잘 이해하고 있으면 응용력이 생기죠.
    이런 좋은 경험들이 다양한 경우에 응용력을 키워 줍니다.

오늘도 밤을 세워야 하는 개발자 (야근 탈출)

2008.12.08 16:57 by 전규현


잠시 후 Google blogger로 이동됩니다.



옛날부터 내려오는 경영자들이 믿고 있는 미신이 있습니다.

"개발자의 Output은 근무시간의 양에 비례한다."

말은 아니라고 하면서도 밤에 사무실이 텅 비어 있으면 개발자들이 군기가 빠졌다고 생각하고 주말에 누가 나와서 일하나 확인하러 가끔 사무실에 들르는 사람들이 경영자입니다.

실제로 근무시간에 성과가 비례하는 개발자들이 있다면 공장에서 벽돌 찍어내는 것과 다를 바가 없겠지요.
이 미신은 믿기 싫지만 자꾸 저절로 손이 가는 새우깡처럼 믿게 되고, 회사 조직에서 위로 올라갈수록 더 맹신하게 되나 봅니다.

이러한 이유로 어쩔 수 없이 또는 습관적으로 야근을 하는 개발자가 있다면 십중팔구 미혼이거나 결혼을 했어도 아이가 없겠죠.
이런 정상적이지 않은 생활을 하며 10, 20, 30년간 소프트웨어 엔지니어 일을 할 수는 없겠죠.

나는 "개발은 창의적인 작업으로 그 성과는 충분한 재충전에 나온다"고 믿고 있습니다.

그렇게 합리적인 시간에 개발을 하려면 소프트웨어 개발은 좀더 체계적이고 효과적으로 진행해야 합니다.
지금의 일반적인 경우처럼 일단 프로젝트를 시작해서 개발자들이 능력껏 그럭저럭 진행하는 방법으로는 또 개발자의 야근은 피할 수 없고, 별로 빠르게 끝나지도 제품의 품질이 좋지도 않게 됩니다.

그래서 소프트웨어 개발에 소프트웨어 공학을 적용하는 것이지요.
말은 거창한 것 같지만, 소프트웨어 공학이라는 것이 소프트웨어를 최소비용으로 최단기간에 개발하기 위한 온갖 방법들을 말하는 겁니다. 결코 교과서의 내용이 아니고 현실에서 수많은 회사들이 경험을 통해서 내려오는 방법이고 여러분들도 상당부분은 익히 알고 있는 방법들입니다. 이 블로그의 주제이기도 하고요.

다시 개발자들이 밤을 세지 않기 위한 방법으로 되돌아 와서 그 방법을 알아봅시다.

일단, 경영자의 인식이 바뀌어야 하는 것은 당연한 일인데, 어떻게 손을 델 수가 없는 일입니다.
그리고 나면 아래와 같이 개발자들과 프로젝트팀이 행할 수 있는 3가지 방법이 남습니다.

  • 정확한 일정 예측
  • 체계적인 개발 방법 
  • 합리적인 일정 복구 

첫째, 정확한 일정 예측입니다. 이는 모순된 문장입니다. 어떻게 예측을 정확하게 하나요? 하지만 예측이란 그때 상황에서 최선을 다해 정확하게 예측을 해야지요. 
당연히 프로젝트가 시작하자마자 정확한 예측은 불가능합니다. 아직 스펙이 정해지지 않았거든요.
그래서 프로젝트가 시작할 때는 대충을 일정을 가지고 시작을 하다가 스펙 작성이 완료되면 스펙을 근거로 1,2일 단위의 정확한 WBS를 작성하여 소요일정과 투입인력을 따져서 프로젝트 일정을 작성해야 합니다.
회사의 모든 관련자들은 프로젝트가 시작할 때 정해진 일정을 진짜 일정으로 봐서는 안됩니다. 스펙 완료 후 작성된 일정을 진짜 일정으로 봐야지요. 이것을 당연히 이해 할 수 있어야 얘기가 되지요.
그리고도 일정은 개발중간에 지속적으로 점검하며 일정이 틀어지면 대응을 해야 합니다. 1,2일 단위로 작성된 일정은 조금만 늦어져도 금방 문제를 파악할 수 있습니다.

둘째, 체계적인 개발 방법입니다. 
이 부분은 책 한 권을 써도 될 만큼 많은 양이고 앞으로 블로그에서 지속적으로 다룰 내용이니 간단히 소개만 하겠습니다. Stage를 따라서 개발을 하거나, Daily Build를 하고, 소스코드관리/버그관리시스템을 사용하고, 피어리뷰/코드리뷰를 하고, 모든 이슈를 투명하게 Open하고, Build를 자동화하는 등 수많은 방법들을 당연히 사용해야 할 것 입니다.

셋째, 합리적인 일정 복구입니다.
프로젝트는 어쨌든 늦어지게 마련입니다.  
다음 그림을 보면 현재 프로젝트 진척이 계획보다 늦어지고 있습니다. 이럴 때 다음 4가지의 방법이 있습니다.


A. 더 낮은 우선순위의 요구사항은 다음 버전으로 연기한다. 
B. 개발자를 추가로 투입한다. 
C. 시간외 근무를 단기간 동안 강제로 시킨다. 
D. 일정을 연기하여 추가된 기능을 수용한다. 

여기서 대부분의 회사가 C를 주로 선택하고 가끔 B를 선택합니다.
C는 단기적으로는 효과가 있지만, 이 기간이 길어지면 별로 효과도 없을 뿐더러 개발자 사기만 떨어지고 회사의 경쟁력도 잃고 개발자도 잃게 되는 방법입니다. 
B는 효과가 거의 없는 것으로 익히 잘 알려져 있습니다. 프로젝트 후반에 개발자를 투입하는 것은 기존에 열심히 개발하고 있는 다른 개발자들에게 방해만 되는 경우가 허다합니다. 기존 개발자들은 이들을 가르치느라고 시간을 허비해야 하고, 새로 투입된 개발자는 별로 성능을 발휘하지 못하며 버그도 많이 만들어내는 경우가 허다합니다.
프로젝트가 늦어지고 있는지 전혀 신경을 쓰지 않다가 프로젝트 막바지에 가서야 한참 늦어지고 있다는 보고를 받고 부랴부랴 대책을 세울 때 선택하는 방법이죠.
가장 좋은 방법은 A입니다.
여기서 중요한 점은 모든 프로젝트를 시작할 때 프로젝트가 늦어질 수 있다는 것을 미리 생각해야 한다는 것입니다.
그래서 스펙의 각 기능은 Priority(우선순위)를 정해줘야 합니다. 그래서 일정이 늦어지면 우순선위가 낮은 기능을 연기하고 프로젝트를 종료하는 것입니다. 그러기 위해서는 개발 순서도 우선순위가 높은 기능부터 개발이 진행되어야 합니다.
이러한 모든 것들이 체계적으로 합리적으로 진행이 되어야 중요한 프로젝트를 하더라도 퇴근 후에 가족과 식사를 하고 아이들과 놀 수 있는 시간이 생깁니다.

위와 같이 합리적이고 체계적인 절차에 의한 데이터를 근거로 경영층에 보가 되고 투명한 개발진행이 경영층에 신뢰를 준다면 하루 8시간 근무하는 날이 점점 늘어 날 수 있을 것입니다.

개발자 혼자서 할 수 있는 일은 결코 아니고, 회사가 조직, 프로세스, 시스템등 모든 것이 바뀌어 나가야 가능한 일입니다.

이미지출처 : Microsoft Office Online

저작자 표시 비영리 변경 금지
신고

전규현 프로젝트/일정 8시간근무, 소프트웨어, 소프트웨어 개발, 소프트웨어 공학, 일정

  1. Blog Icon
    붉은칼

    이상적인 환경이네요. 아웃소싱, SI 업계에서는 조건부터 잘못되서 적용이 안될거 같고, 금융 또는 IT 대기업 사내 소프트웨어 연구실 정도면 어느정도 현실화 될지도. 아마 괜찮은 회사에서는 벌써 적용될지도 몰르고. 그러나, 99% 개발자에겐 그림의 떡일듯. 불쌍한 우리회사 개발자들..--;
    실력있는 개발자 같으신데 기회가 되면 창업한번 해보세요. 다양한 경험을 통해 좀더 현실적인 답을 찾아내시길~

  2. 저희 팀이 보편적인 프로젝트라고 보기는 힘들지만, 분명 SI 업계의 아웃소싱 프로젝트에서 위 내용을 토대로 진행을 해서 야근을 없앴습니다.
    팀원 중 2명은 야간 대학원에 다니기 까지 하고 있습니다.
    중요한 일이 무엇인지 판단을 하고, 고객이 원하는 것이 무엇인지 정확하게 판단하는 것과 구현을 분리하지 않고 일하는 것, 작업을 잘게 쪼개서 예측가능하게 하려는 노력은 현실적인 답을 만들어냅니다.

  3. 영회님 안녕하세요.
    역시, 이 댓글 하나만 봐도 영회님과 그 개발팀이 어느정도의 실력과 경험이 있는지 알 수 있겠네요.
    말은 쉽지만 실제로 그렇게 실행하고 있다는 것은 이해의 단계를 넘어서 내제화를 이루고 있다고 할 수 있습니다. 감사합니다.

  4. 붉은칼님 안녕하세요.
    우선 밝혀둘 것이 있습니다. 저는 소프트웨어 개발컨설턴트로서 대한민국의 어떠한 개발자와 비교해도 부족하지 않은 개발 및 컨설팅의 지식과 경험이 있습니다. 수백만명이 쓰는 제품, 전세계인이 쓰는 제품, SI등 다양한 분야의 경험을 풍부하게 다 가지고 있습니다. 제가 쓰는 글들은 모두 경험에서 나온 글들입니다. 또한 저희 펌에서는 한국과 미국에서의 20년이상의 소프트웨어 개발에 대한 다양한 노하우를 가지고 있습니다. 그냥 단순히 보고 들은 내용을 옮기는 것으로 오해하지 마시길 바랍니다.

    제가 컨설팅을 하면서 만난 거의 모든 회사는 "우리회사는 다르다"라고 합니다. SI다, 금융이다. 이유는 많지만 사실을 다 똑같습니다. 원리는 같다는 얘기입니다. 99%의 개발자에게 그림의 떡이 아니고 99%의 개발자에게 가능하고 그래야 더 품질이 좋은 제품이 개발되고 회사의 경쟁력이 더 높아집니다.
    8시간 근무를 하는 이유도 더 개발을 잘하고 빨리 하기 위해서임을 명심해주시면 좋을 것 같습니다. 잘 이해가 안되면 붉은칼님에게는 정말 좋은 기회인 것 같습니다. 소프트웨어 엔지니어링이 가져올 좋은 개발환경에 대해서 앞으로 제 블로그를 지속적으로 관심을 가지고 봐주세요. 점점 더 구체적인 글들을 작성해 나갈 겁니다.
    감사합니다.

  5. Blog Icon
    Jake

    저도 동감합니다. 저도 지금까지 거친 회사에서 항상 개발 프로세스를 체계화 해 보려고 노력했지만 (지금도 하고 있습니다) 항상 나오는 말은 "우리는 그런거 적용 못해" 라는 겁니다. 하지만 한가지 짚고 넘어가고 싶은 부분은 Ray 님의 말씀처럼 원리는 다 같다고 할 수 있겠지만 원리와 현실의 차이는 무시할 수 없다고 생각합니다.
    따라서 원리나 원칙을 적용하고 그에 따르도록 하는 것 보다는 그 회사의 특수성을 이해하고 받아들여 그에 맞게 차용(adopt)하는 것이 가장 현실적이고 바람직하지 않을까 하는 생각입니다.
    아시다시피 미국회사라고 야근 없는 것 아니고 주말에도 일할 때도 많습니다 - 전 미국에 있습니다. 개발자란 직업의 특수성이라고 생각합니다. 제 처제는 게임회사 그래픽 디자이너인데 프로젝트 마감일 다가오면 집에도 못가고 주말에도 밤새서 일합니다. 하지만 릴리즈 후에는 2주 - 3주 정도의 휴가를 받습니다. 고생 후 그만큼의 보상이 따른다는 것이 한국과의 다른점이라고 생각이 됩니다. 이는 IT 업계뿐 아닌 사회 전반적인 문화의 차이가 아닐까 하는 생각이 되네요.

  6. Jake님 안녕하세요.
    정확한 말씀입니다. 평소에 제가 하는 말이죠.^^
    Jake님은 한번 만나뵈고 싶은 분이네요.
    앞으로 좋은 교류 지속되기 기대합니다.

  7. 미국의 개발자들은 야근을 안하는가? 하는 오해가 있을 수 있습니다. 미국의 개발자들도 야근을 많이 하기로 유명합니다. 하지만 우리와는 경우가 좀 다릅니다. 대부분 체계적으로 개발을 하는데도 야근을 많이 하는 거죠. 특히 MS는 야근을 많이하고 그만큼 많이 보상해주죠. 많이주고 많이 뽑아먹기로 유명합니다.

  8. 정말 공감이 가는 글입니다. 이 글은 경영자 필독입니다.

  9. HannaKim님 안녕하세요.
    소프트웨어 엔지니어링에 관심이 많으신 분을 만나서 반갑습니다. 앞으로 좋은 얘기 많이 주고 받으면 좋겠습니다.
    감사합니다.

  10. 좋은 말씀 잘 보고 갑니다. 선택할 위치에 있는 분들의 뿌리깊은 잘못된 사고방식이 합리적으로 바뀌었으면 좋겠는데, 개발자 출신의 관리자들도 똑같은 생각은 가지신 분들이 많으니 요원한 일로 보이기도 합니다. 하지만 점점 좋아지겠죠? ^^

  11. cozydev님 안녕하세요.
    개발자가 좀더 전문적이어야하지 않을까요? 주먹구구식으로는 경영자를 납득시키기는 어려울 것 같습니다.

  12. Blog Icon
    다른개발자

    뭐 워낙 대단한분들이 모이신거 같은데 읽다가 저도 생각을 한줄 표현할까 해서 올립니다만...
    환경이 열악한건 사실이죠..근데 환경이 언젠가는 좋아지겠지라는 생각과 그런날이 올까? 라는 생각이 주를 이루는데요...?너무 환경탓을 하기 보다는 자신에게 주어진 환경을 자기가 만들어 갈수 있다는 생각을 가지는것이 중요하다고 생각합니다. 저도 적지않은SI 경험을 가지고 있지만...SI하면서도 일빨리 끝내고 일찍가는 개발자 많고요... 일잘하면 요새는 관리자도 특별히 근태 터치 안합니다.물론 기본적 근태는 지켜줘야죠 9시 출근 6~7시 퇴근 그러다가 일주일에 한두번정도는 8~9시 퇴근 이정도면 처자식과 가정생활 하면서도 충분히 SI에서도 개발자로 생활 가능하다고 보는데요..

  13. 안녕하세요.
    잘하고 계시는 것 같습니다. ^^ 사실 SI나 팩키지나 소프트웨어 개발의 기본은 거의 같죠.

고객중심의 서비스 마인드가 소프트웨어 산업을 망친다.

2008.12.05 11:36 by 전규현


잠시 후 Google blogger로 이동됩니다.





부제 : Global mind를 가져라.

우리나라의 Customer Service(A/S) 정신은 정말로 환타스틱합니다.

TV가 고장나서 전화하면 수리기사가 바로 달려와서 고쳐주고 갑니다.
핸드폰이 고장나서 서비스센터에 가면 바로 고쳐줍니다.
뭐든지 바로바로 해결이 되죠. 

하지만 미국에서는 좀 다릅니다. 노트북이 고장나면 바로 해결이 안됩니다. 서비스센터에 맡겨도 서비스센터는 단순히 포장만해서 수리공장으로 보내는 경우가 대부분이고 오래 걸리면 한달이 걸리기도 하고 재수 좋으면 그보다는 빨리 받아 볼 수 있죠.
미국은 땅덩어리가 워낙 커서 가 도시마다 전문서비스기사를 둘 수도 없습니다.
부른다고 쪼르륵 달려갈 수도 없습니다. 비행기타고 몇시간 날아가서 차 랜트해서 또 한참 가야지만 고객을 만날 수 있거든요. 또 고객이 비행기타고 핸드폰 수리하러 갈 수는 없죠.
소프트웨어도 마찬가지입니다. 고객이 소프트웨어를 구매하고 나서 수시로 개발사의 엔지니어를 불러서 이거 봐줘라, 저거 봐줘라, 이렇게 바꿔달라, 이런 요청을 할 수 없습니다.
물론 Enterprise Solution들은 유지보수 계약을 맺고 서비스를 받지요. 그 종류도 다양하고 서비스도 시스템화 되어 있지요. 물론 그 대가를 지불해야 하구요.
엔지니어를 부르는 것은 매우 비싸지요. 그리고 유지보수 건으로 개발자를 부른다는 것은 상상하기 힘들죠.
하지만 우리나라에서는 장애 시 사과 차원에서 개발자가 가서 인사를 해야 하는 어처구니 없는 경우도 있더군요. 문제를 만든 사람이 와서 사과를 하라는 거죠.
미국에서는 이러한 환경이 제품을 만드는 마인드부터 달라지는 것 같습니다.
일단 미국 어디에 파나, 전세계 어디에 파나 컨셉은 거의 같구요. 제품은 문제 생기면 쪼르륵 달려가서 해결해야 하는 형태로 만들지는 안죠. 제품의 품질을 떠나서 마인드가 다르니 접근을 다르게 합니다. 제품의 기능이나 UI에 그러한 마인드가 묻어나고, 개발 문서도 제대로 만들고, White paper도 만들죠. 문제가 생겼는데, 거의 모든 정보가 개발자의 머리 속에 있으면 안되거든요.
물론 고객도 이거 저거 바꿔달라는 요구는 잘 못하죠. 요구가 있다고 해서 다음 버전에 꼭 넣어 달라고 강요도 못하고 그건 개발사가 알아서 할 일이죠.

우리나라의 경우는 사정이 좀 다릅니다. 전국 어디서나 부르면 개발자나 Technical Support Engineer가 달려갈 수 있죠. 오랫동안 그런 서비스에 익숙해져서 고객은 아무 때가 개발사의 Engineer를 부르고, 제품의 기능이나 업그레이드 일정도 좌지우지 합니다. 개발자를 제 종 부리듯 하는 고객도 있습니다. 또 유지보수 댓가는 제대로 받기가 어렵죠. 개발사는 단기적인 이익에 쫓겨서 어쩔 수 없이 고객의 요구를 들어주다 보면 장기적으로 제품의 경쟁력이 떨어지게 됩니다. 그러다보니 이런 환경에 적응된 제품을 생각하고 만드는 경우가 많아지는 것 같습니다. 당연히 Global mind가 떨어지지요.

또 아이러니 한 것은 이러한 고객이라도 외국 제품을 쓰면서는 국내 소프트웨어 회사 대하듯 못한다는 겁니다.

컨설팅을 하면서 만나본 많은 회사들은 국내에서는 꽤 많은 매출을 일으켰는데, 외국에는 팔기가 어려운 제품을 많이 봤습니다. 설치는 꼭 엔지니어가 가서 해줘야 하고, 주기적으로 점검도 해줘야 하고, 고객마다 커스트마이징을 해야 하기 때문에 외국에 팔 경우 그 나라에 서비스조직을 상당히 갖춰야 하는 경우가 많습니다. 국내에서는 커스트마이징을 경쟁력으로 내세워서 외국제품과 경쟁했는데, 그로 인해서 더 큰시장으로는 못나가는 거죠. 

결국 마인드를 바꿔야만 됩니다.
고작 이 작은 땅덩어리에서 경쟁해서는 구멍가게 밖에 되지 못합니다. 좀 큰 구멍가게는 매출액이 몇백억씩 되기도 하지만, 유지보수에 발목을 잡혀서 수익이 악화되고 회사가 고꾸라지기도 합니다. 구멍가게를 알차게 꾸려가든가,그렇지 않다면 Global하게 경쟁할 수 있는 마인드를 가지고 소프트웨어를 개발해야 합니다.

우리나라에서
처음부터 글로벌 마인드를 가지고 시작하는 제품이 좀더 많아지면 좋겠습니다.
이러한 글로벌 마인드를 가진 개발자와 회사가 많아지면 좋겠습니다.
작더라도 전세계 사람들이 사용하는 제품이 많아지면 좋겠습니다.
고객이 부른다고 쪼르륵 달려가지 않아도 되는 제품이 많아지면 좋겠습니다.
고객서비스가 비싼 상품이라고 인식하는 고객이 많아지면 좋겠습니다.
개발자 불러다가 이거 저거 고쳐달라고 해도 된다는 인식이 적어지면 좋겠습니다.
우리나라 개발자들이 많은 수많은 제품이 세계를 호령하는 날이 오면 좋겠습니다.


저작자 표시 비영리 변경 금지
신고

전규현 개발문화 문화, 소프트웨어, 소프트웨어 개발

  1. 실제로 이런 마인드로 힘들어져 가는 회사를 겪어봐서 그런지 더욱 와닿는 글이네요.

  2. JasonPA님 반갑습니다.
    이런 현상을 조삼모사라고 합니다.
    당장의 이익을 위해서 미래에 큰 손해를 보는 것이지요. 회사의 비전과 제품의 로드맵에 따라서 이익이 안되는 요구나 고객들은 과감히 포기할 수 있어야 하는데, 우리나라의 많은 소프트웨어 회사들은 비전과 로드맵이 부족하기 때문에 사실 포기할 수 있는 기준도 애매한 경우가 많더군요.

  3. Blog Icon
    한인철

    전적으로 동감합니다.
    아직까지도, 소프트웨어에 제 값 안주고, 하드웨어의 서비스처럼 생각하는 동네도 있습니다.
    슬픈 현실입니다.

    어제 밤에 우연히 이곳을 발견했습니다.
    도움되는 글이 많아서, 오늘 하루를 몽땅 투자해서 처음부터 읽고 있습니다.
    좋은 글 감사합니다.

  4. 한인철님 반갑습니다.
    소프트웨어엔지니어이신가요? 좋은 의견 많이 주세요.
    감사합니다.

  5. 이건 우리나라의 특수성에서도 기인하는 것 같습니다.

    미수다였나? 어디선가 외국인이 우리나라 오면 신기해하는 것중 하나가 "어디를 가도 사람 없는 곳이 없다."라는 것이었습니다.

    인구밀도가 워낙 높아서, 아파트를 선호하고, 인구밀도가 높으니 네트워크를 설치할 때도 비용이 상대적으로 저렴하죠. 그러니 초고속 인터넷 보급률도 높았죠. 소프트웨어 산업도 비슷한 맥락이 아닐까 합니다. 인력은 넘쳐나니(업무능력은 논외), 손쉬운 대안이 되는 것이고, 개발자는 개발자 나름대로 자기 노하우를 다 쏟아놓으면 토사구팽될까 두려워하고. 뭐, 이런 것 아닐까요?

  6. nulonge님 안녕하세요.
    동감입니다. 그래서 개발자들이 죽어나죠. 고객들은 좋지만 결국 고객도 손해보고 다 같이 손해보는 것인데 말입니다.

블로그 호스팅을 Google Blogger로 이전합니다.

최근에 블로그에 보안 문제가 발생하여 좀더 안정적으로 블로그를 운영하기 위해서 Google Blogger로 이전합니다. 기존에 http://allofsoftware.net 과 http://www.allofsoftware.net..

한국어(한글) 코드 이야기 (8)

유니코드에 대해서 좀더 알아보기 전에 한국어 코드(문자세트)와 인코딩에 대해서 좀더 알아보자. 1991년에 유니코드가 탄생한 후에 유니코드는 점점 많은 개발자들이 사용하기 시작해서 영역을 넓혀가고 있다. 물론 언젠가는 유니코..

유니코드 영토 전쟁의 승리자는? (7)

이번에는 유니코드의 코드 체계에 대해서 간단하게 알아보고자 한다. 소프트웨어 국제화를 필요로 하는 개발자라면 자주는 아니지만 유니코드 내부 코드 체계를 알아야 할 때가 있다. 다양한 플랫폼에서 개발을 할 때 폰트 등과 관련하..

유니코드는 어떻게 탄생했을까? (6)

소프트웨어 국제화를 이해하기 위해서는 유니코드에 대해서 필수적으로 잘 알아야 한다. 유니코드란 말을 들어보지 않은 개발자는 없지만 관련 용어가 매우 많아서 종종 헷갈린다. 게다가 유니코드가 탄생한지 20년도 더 넘었지만 아직..

직원을 잠재적인 도둑 취급하는 회사

필자는 몇 년 전 A그룹에 강연을 하러 갔다가 곤란한 일을 겪은 적이 있다. 한국 대부분의 대기업이 그렇듯이 보안이 매우 엄격한 회사였다. 나는 직원들의 안내대로 메모리, 외장하드를 모두 빼놓고 회사로 들어갔다. 하지만 강연..

외국에서 팔리는 소프트웨어의 아키텍처 디자인 원칙 (5)

김과장은 그 동안 한국어만 지원하는 소프트웨어 A를 개발해 왔는데 최근에 사장님이 A의 일본어 버전을 만들라고 했다. 그리고 개발 기간도 한달 밖에 주어지지 않았다. 그래서 기존 소스코드를 복사해서 한국어가 들어 있는 모든 ..

소프트웨어 개발자 성장에 꼭 필요한 리뷰

우리나라 개발자들은 프로그래밍은 잘 하는데 대접을 못 받는다는 얘기가 있다. 또, 머리는 좋은데 환경이 나쁘다는 얘기도 있다. 젊은 개발자들은 외국의 개발자들에 전혀 뒤지지 않는데 나이를 먹을수록 실력이 떨어진다는 얘기도 있..

외국에 출시한 소프트웨어가 날짜 때문에 낭패 본 사연 (4)

10년차 개발자인 김과장(가상의 인물)은 최근에 소프트웨어를 영어를 지원하도록 만들었다. 어플리케이션에서 표시되는 모든 메시지(메뉴, 버튼, 다이얼로그 등)를 영어로 번역했다. 그렇게 해서 영어버전을 출시했는데 얼마 안 가서..

독일어 버전 소프트웨어란 말이 잘못된 이유 (3)

본 시리즈는 차례대로 읽으면 소프트웨어 국제화가 전체적으로 이해가 되어서 소프트웨어 개발자에게 도움이 되는 방향으로 진행하려고 하고 있다. 개발자마다 지식과 경험이 천차만별이라서 초급 개발자를 기준으로 작성하고 있다. 경영자..

소프트웨어를 외국에 출시 하면서 흔히 빠지는 함정 (2)

우리나라 소프트웨어 중에서 외국에서 크게 성공했다고 하는 소프트웨어가 있는가? 온라인 게임을 제외하고는 거의 없다. 사실 게임은 국제화, 지역화를 잘 못하더라도 큰 흉이 안 된다. 하지만 그 외의 많은 소프트웨어들은 제품이든..