태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

누가 소스코드를 몰래 바꿔놨다.

2009.07.13 19:57 by 전규현


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



누군가 몰래 여러분 회사의 소스코드를 바꿔놓는 일이 가능한가요? 진짜 이런 일이 일어 날 수 있는 환경이라면 당장 고쳐야 합니다.

실제로 이러한 걱정을 하는 회사도 많이 있습니다. 

영화 슈퍼맨3를 보면 한 프로그래머가 은행 이자의 우수리 돈을 자신의 계좌로 몰아서 스포츠카를 사는 장면이 나옵니다. 또, 퇴사하는 직원이 악의를 품고 소스코드를 몰래 바꿔놓지 않을까 걱정을 하기도 합니다.

정상적인 시스템과 프로세스를 갖춘 회사라면 이러한 걱정을 할 필요가 없으나 그렇지 못한 대부분의 소프트웨어 회
사들에서는 언제든지 일어날 수 있는 일입니다.

정상적인 경우라면 소스코드의 모든 변경은 기록에 남게 됩니다. 또 소스코드를 변경하기 위해서는 버그ID(또는 이슈ID)가 있어야 합니다. 이것이 소스코드 변경 승인의 역할을 대신하기 때문에 소스코드를 변경 시 버그 ID가 없다면 소스코드 변경이 차단되도록 되어 있는 경우도 있습니다.

또, 버그ID도 가짜로 만들어서 등록을 했다고 하더라도, Peer review에서 이상한 코드는 발견이 되게 됩니다. Peer review를 통과 했다고 하더라도, Build팀에서 빌드를 하면서 바뀐 소스코드와 버그ID를 체크하는 과정에서 가짜 버그 ID가 발각 될 수 있습니다. 여기까지 통과를 하였다고 하더라도, 테스트에서 걸리게 되어 있습니다. 이것도 통과를 하였다고 하더라도, 모든 변경의 이력은 기록이 남아 있고, Log가 존재하므로 추후 추적이 가능해집니다.

제대로 시스템과 프로세스가 갖추어져 있다면 누가 소스코드를 마음대로 바꾸지 않을까 걱정할 필요가 없습니다. 이를 걱정하고 온갖 프로텍트 장치를 해 놓는 것은 오히려 개발 효율성을 떨어뜨리게 됩니다.

모든 것이 다 Open되어 있고 허술한 것 같아 보이지만, 이렇게 하는 것이 오히려 더 안전하고 투명하게 개발이 진행되며 생산성을 훨씬 더 높이는 방법입니다.

* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 


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

전규현 기반시스템/소스코드관리 Peer Review, 빌드, 소스코드관리, 슈퍼맨3, 테스트

Peer review의 혜택

2009.05.13 13:44 by 전규현


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



"Peer review를 해야 하는데 바빠서 못하고 있다"라는 말을 종종 듣게 됩니다.
이 말을 들으면 Peer review를 해야 한다는 필요성을 사실은 알지 못하고 있다는 것을 알게 됩니다.
다들 Peer review를 해야 한다고 하니까 거기서 Peer review를 할 필요 없다고 하면 혼자 이상한 사람이 되니까 그냥 그렇게 얘기를 하는 것이지요.

정도는 다르지만 소프트웨어를 개발하고 있다면 기본적으로 Peer review는 꼭 필요합니다.
Peer review의 기본적인 2가지 목적은 다음과 같습니다.

1. 결함의 발견
2. 정보의 공유

Peer review를 말하면 Code review를 먼저 생각하는 사람들이 많은데, 사실 Code보다도 문서 Review가 더 필요합니다. 그 중에서도 스펙(SRS)의 리뷰가 가장 중요한 문서 중에서 하나지요. 문서가 코드보다 결함이 있을 경우 더 심각하고 나중에 고치려면 더 많은 비용이 들고, 개발 기간을 단축하고 효과적으로 일하려면 문서를 제대로 만들고 리뷰를 해야 합니다.
그럼, Peer review(스펙, 설계, 소스코드, 테스트 문서)를 하면 실제적으로 어떠한 혜택이 있는지 알아보도록 하겠습니다.

개발자
재작업 시간을 감소시켜 줍니다.
개발 생산성을 높여줍니다.
선배들로부터 많은 기술을 습득할 수 있습니다. 또 개발자간의 정보를 공유합니다.
디버깅 및 단위 테스트 시간이 줄어듭니다.

유지보수개발자
기술 지원 이슈가 감소하고, 기술지원이 손쉬워 집니다.
소프트웨어의 구조를 쉽게 파악할 수 있습니다.
유지보수가 용이해 집니다.

테스터
테스트 기간이 단축됩니다.
심각한 버그가 감소합니다.
테스트 케이스를 만들기 용이해 집니다.

분석가
잘못된 요구사항을 조기에 발견할 수 있습니다.
요구사항이 개발가능 해지고, 테스트가 가능해 집니다.

프로젝트 관리자
프로젝트 일정일 지키기가 더 용이해 집니다.
프로젝트의 리스크를 조기에 발견할 수 있습니다.
범위의 변경이 줄어듭니다.
협업이 개선됩니다.

위의 혜택 중에 더 많은 부분이 문서리뷰에서부터 비롯되며, 만약에 Peer review를 전혀 하지 않는다면, 위의 혜택들이 NOT이 되는데, 그런 프로젝트는 상상하기가 어렵네요. 
리뷰 문화가 아직 정착이 되지 않았다면, 일단 스펙을 작성할 때는 꼭 모든 관련자가 리뷰를 해야 한다는 규칙을 정해서 조금씩 리뷰에 적응하는 것이 어떨까요?

Peer review는 규칙에 의한 강제에 의해서도 자율만에 의존해서도 정착시킬 수 없습니다. Peer reivew에 필요한 기초 역량등 제반 여건이 되어 있어야 하고(이 정도도 안되면서 Peer Review를 한다고요?), 처음에는 어느정도 강제화를 하면서 점점 업무속에 파고들게 해야 합니다.


이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다. 

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

전규현 개발문화 Peer Review, 리뷰

  1. Blog Icon
    아름드리

    멀고도 먼 나라의 얘기처럼 보이네요.
    대부분은 '개발자 = 유지보수개발자 = 테스트' 공식이니깐요.

  2. 안녕하세요. 아름드리님
    '개발자 = 유지보수개발자 = 테스트' 이런 상황에서도 one man company가 아닌 이상 Peer review는 필요하죠. Peer review를 하지 않는다면 그 혜택을 모르는 것이고요. 아름드리님의 말씀처럼 많은 사람들이 먼나라 얘기처럼 느낄 겁니다. 그래서 우리나라 소프트웨어 문화가 갈길이 먼것입니다. 대부분 가내 수공업을 못벗어나고 있습니다.

과거의 개발자 vs. 미래의 개발자

2009.04.28 11:16 by 전규현


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



개발자는 2가지의 상반된 가치를 가지고 있습니다.

하나는 과거의 가치
또 하나는 미래의 가치입니다.

"이 사람들 나가면 과거에 개발해 놓은 것 어떡하지?"라는 생각이 들면 과거의 가치를 가진 개발자이고
"이 사람들 나가면 미래에 개발은 누가 하지?"라는 생각이 들면 미래의 가치를 가진 개발자입니다.

과거의 가치를 가진 개발자들은 본인이 아니면 유지보수가 어렵게 소프트웨어를 개발해 놓았고, 대부분의 지식은 머리 속에 있기 때문에 자신이 과거에 만들어 놓은 소프트웨어를 인질 삼아서 회사와 인질극을 벌이고 있는 것과 같습니다. 이렇게 된 원인이 상당부분 회사에 있다고 하더라도, 개발자의 가치는 인질범과 별반 다를 바가 없습니다. 기존 소프트웨어를 망칠까봐 대우해줄 수 밖에 없습니다.

미래의 가치를 가진 개발자들은 자신이 과거에 만들어 놓은 소프트웨어들은 후배들이 유지보수 할 수 있도록 충분히 문서화를 해 놓았고, Peer review를 통해서 이미 많은 지식이 전달된 상태입니다. 이러한 개발과정을 거쳐서 본인은 분석, 설계 능력을 더욱 향상시켰고, 신기술들에 대한 연구에 집중하여 미래에는 과거의 제품들 보다 한 단계 높은 수준의 제품들을 만들어 낼 것입니다. 이러한 개발자들이 진정한 영웅이라고 할 수 있습니다.

인질범이 되겠습니까? 영웅이 되겠습니까? 이는 본인의 의지에 달려있습니다.

안타까운 것은 고참 소프트웨어 개발자 중에는 영웅보다 인질범이 더 많다는 겁니다. 물론 이 개발자가 인질범과 다를바가 없다는 것을 본인도 모르고 회사도 모르는 경우가 태반이지만 말입니다.



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

전규현 사람과 기술 Peer Review, 가치, 개발자, 과거, 문서화, 미래, 분석, 설계, 영웅, 인질범, 지식, 후배

  1. 그러고 보니.. 전 이제 2년 경력이긴 하지만, 인질범이었다는 생각이 드는군요 ㅠ.ㅠ
    조금 더 알아보기 쉽게 작성하고 문서도 남기는 버릇을 들이도록 해야겠습니다.

  2. 구차니님 안녕하세요.
    필요성을 느끼는 것이 첫걸음이고, 다음은 배워야죠. 대부분 선배들에게 배우지를 못하니 배우는데, 어려움이 있습니다.

  3. Blog Icon

    동감합니다. 남을 위해 코드를 개발하다 보면 실력향상에도 도움이 된다고 생각합니다. ^^

  4. A2님 안녕하세요.
    협업은 기본인데, 그렇지 않게 생각하는 경우가 너무나 많습니다.

  5. 그러게요. 개인의 문제이기 이전에 조직의 문제라고 생각해요.
    개인이 고민하기 이전에 회사가 조직적으로 만들어가야 하는 부분 아닐까 합니다.
    물런 영세하고 사람도 부족해서 어쩔수 없긴 하지만 말입니다.

  6. hangum님 안녕하세요.
    사실 이런 경우 회사의 책임이 더 크다고 할 수 있죠. 그래도 결국 개발자와 회사 둘다 피해를 입죠.

  7. 아주 멋진 표현이었습니다.
    저놈이 나가면 제가 만든 코드 어쩌지? 라는 생각만 들면
    이미 과거의 개발자이네요.. ^^

  8. zeous님 안녕하세요.
    반갑습니다.

  9. Blog Icon
    momo

    그런데 말이죠.. 제 주변에도 영웅들을 몇몇 봐왔지만 회사에서 못알아 보는건지 인질범과 별반 다를바 없이 대하더군요. 오히려 인질범에게 더 잘해준다는 느낌이 듭니다.

  10. 안녕하세요. Momo님
    회사는 어쩔 수 없이 그렇게 되는 것이지요. 하지만 그렇게 반복되면 회사고 개인이고 둘다 미래가 없다는 거....

  11. 인질범이 되지 않으려고 발버둥 쳤지만, 결국 떠나는 이시점에..
    전 인질범이 었다는 결론이 내려지네요..

  12. 안녕하세요.
    본의 아니게 그렇게 된 경우도 많습니다.

  13. Blog Icon
    장성호

    공감가는 글이네요
    그동안 몇번 직장옮기면서... 매번 강력이 계속남아주기를 요청받았는데..
    미래를 위한 부분도 있었지만, 과거를 위한 부분도 상당한듯 하네요.

    미래가치가 큰 개발자가 되도록 더욱 노력해야 겠습니다.

  14. 안녕하세요. 장성호님
    과거의 가치가 더 높은 개발자들은 자칫하면 그것이 자신의 뒷다리를 잡고 있다는 것을 망각하기 쉽습니다.

  15. Blog Icon
    농부

    유전무죄 무전유죄 입니다.

    누가 프로그래머를 인질범으로 내몰았습니까?

    어처구니없는 일정과 꽉막힌 현업 그리고 끊임없는 요구사항변경...

    어느누가 인질범이 되고 싶었겠습니까?

    프로그래머는 지금도 충분히 어렵고 힘듭니다.

    너무 ~해야한다 자꾸 그러지 좀 마세요.

    몸도 마음도 점점 지쳐가네요..ㅠㅠ

  16. 안녕하세요. 농부님...
    닭이 먼저냐 달걀이 먼저냐? 이슈네요. 개발자들이 일하기 열악한 환경인것은 사실입니다. 조금 더 나은 환경을 만들기 위해서 노력하려고 합니다. 힘내세요.

  17. Blog Icon
    대한민국 개발자

    외국에서는
    DBA, 네트웍 담당자, 서버 담당자, 서버개발자, 클라이언트 개발자, 컨설턴트
    데이터 베이스 설계자 , 업무 담당자, 운영유지 보수 담당자
    이렇게 협업해서 개발하는데

    우리나라는 개발자혼자 다 처리해야 하죠 이런 상황에서 어떻게 문서화가 가능
    하겠습니까 개발 일정도 외국의 절반인데

  18. 안녕하세요. 대한민국 개발자님...
    물론 외국도 One man company는 혼자서 이런 걸 다하죠. 하지만 우리나라에서는 개발자가 수천명이어도 똑같이 이것들을 해야 한다는 것이 문제죠.
    어떻게 협업을 해야 하는지 모르고 훈련도 안되어 있는 겁니다.
    협업을 하기 위해서는 문서화, 프로세스, 시스템, 문화가 뒷받침이 되어야 하는데, 여기저기 구멍이 숭숭 뚤려서 제대로 하기 어려운 것이 현실입니다.
    대기업들은 이것을 돈을 들여 프로세스와 시스템으로 해결하려고 하기도 하는데 문화가 뒷받침이 안되어서 어렵습니다.
    이를 해결하려면 시간도 오래 걸리고 고난의 작업이 될 겁니다.

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

2009.04.06 23:52 by 전규현


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



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

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

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

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

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

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

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

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  

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

전규현 개발문화 Peer Review, 리뷰, 설계, 스펙

  1. 언제나 글 잘 읽고 있습니다. 빠른 시일 내에 효과적인 스펙 및 설계문서 제대로 만들기에 대한 내용을 볼 수 있길 바래봅니다. :)

  2. 우울한 딱따구리님 안녕하세요. 모터쇼 다녀오셨군요. 저도 항상 블로그 잘 읽고 있습니다. 처음에 블로그를 시작할 때 스펙을 첫번째 주제로 생각을 하고 있는데, 계속 주변만 서성거리고 있습니다. 블로그를 통해서 스펙을 잘 만드는 법을 습득한다는 것은 과욕이지만 해보는데까지 시도는 해봐야죠. 똑같은을 글을 가지고 1을 얻는 사람도 100을 얻는 사람도 있으니 1명의 독자라도 도움이 된다면 좋겠습니다.

  3. 용역 의뢰를 받다보면,
    특정 플랫폼을 위한 엔진을 개발하는데 고객이 너무 '배려심'이 많아서 산출물 필요없다고 하시는 경우가 있습니다. 고객 측에서도 개발진이 있으니 완료 보고서를 알아서 쓰겠다고 하는 거죠.

    문제는 설계 문서를 쓰지 않으면, '완료 보고'가 아니라 프로젝트 중간 관리 자체를 못하는 건데, 나서서 문서를 쓰겠다고 하니, 아군(?), 적군(?) 할 것 없이 쓸데 없는 짓이라고 말리더군요. 그래도 고집 피워서 겨우 기본 틀 잡아서 문서 제출하고 회의 때마다, 진도/이슈 체크 했더니 더 이상 아무 말도 없습니다.

    말씀하신게 옳은 현장의 작은 기업들이나 실무 개발자들은 SRS라던가, 진행 사항 관리를 위해 어떤 서식이 있는지도 모르는 경우가 많습니다. 가장 간단한 서식 몇개를 공개할까 생각 중입니다. 제가 최근들어 고민하는 내용을 그래도 밝혀 주셔서 감사한 마음 담아 주절 거리고 갑니다.

  4. 써니님 안녕하세요.
    고객도 산출물이 필요없다는 직원도 문서는 개발에 필요없다고 생각하고 있는 것이 문제죠. 대부분 문서에 대한 아픈 기억이 있고, 문서는 개발 시간만 늘인다고 생각하는 경우가 많습니다. 제대로 문서를 써본 경험도 전혀 없으면서 엉터리 경험을 가지고 착각을 하는 겁니다. 문서가 제대로 적히지 않으면 요구사항이 제대로 분석이 되지도 않고 서로 다른 생각을 하면 수많은 재작업을 해야 하며 프로젝트의 진척을 확인할 수도 없습니다.
    각 프로젝트 상황에 맞게 최소한의 문서를 만들어야 하는데, 쓸데없는 문서만 잔뜩 만들다가 아예 포기해버리는 경우가 대부분입니다.

    그리고 몇가지 Template을 공개하는 것은 거의 도움이 안되거나 오히려 방해만 됩니다. Template을 채우는 것을 문서를 작성하는 것으로 착각하기 때문에 그렇게 해 놓고 문서를 작성하고 있다고 할 수 있습니다.

    Template은 인터넷에 널려 있는데, 그게 없어서 문서를 작성 못하는 것은 아니고, 우선 문서 작성의 필요성을 못 느끼는 겁니다. 그리고 문서를 작성해본 경험도 거의 없으니 실력도 없는 것인데, 나름대로 문서를 작성하고 있다고 착각하기도 하고요.

    문서는 작성을 해보고 리뷰하고 또 배우고, 공부하고 작성하고 리뷰하고 프로젝트 해보면서 계속 실력을 향상시켜나가야지요. 그러면서 자연스럽게 자신의 회사에 알맞는 Template를 만들어가면 좋습니다. 표준 Template을 가지고 시작할 수도 있는데, 대부분의 표준 Template가 매우 Heavy하다데 문제가 있습니다. 또 자신의 회사와 맞지 않을 수도 있고요. 항상 의견 남겨주셔서 감사합니다.

  5. 먼저 답글 감사드립니다. 템플릿이 오히려 해가 된다는 말씀에는 깊이 공감합니다.
    ISO 9001 standard 문서 작업한다고 고생하던 기억이 떠오르네요 ^^;

    많은 SI 프로젝트 매니저들이 현실성 없는 양식들을 가지고,
    산출물 작성만을 강요하는 상황도 큰 폐해라고 생각 합니다.

    이렇게 이야기 하는 것보다 실제로 어떻게 쓰고 있는지 밝히는게 역시 낫겠네요.
    역시, 템플릿 자체 보다 중요한 건, What, Why, How 3가지 행동 지침이겠죠.
    서식을 만들면서 어떤 고민을 했고, 어떻게 적용했으며, 개선할 점들을 이야기하려고 합니다.

  6. 내제된 역량이 부족한 상황에서 문서만 만드는 것은 고역이죠. 그렇다고 실력이 느는 것도 절대로 아닙니다. 오히려 아픈 기억만 쌓입니다.

    다양한 경험을 블로그에서 소개하는 것은 매우 긍정적인 일인 것 같습니다. 자신의 경험들에 비춰봐서 도움이 될 수도 있고, 이견이 있으면 토론도 할 수 있겠죠. 어떤 글이 올라올지 기대하겠습니다. ^^

  7. Peer Review를 하기 전에 기본 역량이 되어 있어야 하겠군요
    우리 회사는 소스 코드 관리시스템은 예전부터 사용해왔고
    버그 관리시스템은 몇 번 시도하다가 최근에 다시 강력하게 시행을 하여
    현재는 안정적으로 버그 관리 시스템에 정착한 정도의 레벨입니다.
    스펙 문서와 설계 문서가 가장 취약하군요.
    현재 작성하는 문서가 전혀 없는 상태입니다.

    하지만 새로 개발하는 프로젝트가 아니라 유지보수 단계의 프로젝트라면
    어차피 처음부터 만들어 놓은 스펙과 설계 문서는 없기 때문에
    코드 리뷰만을 진행하는것도 어느 정도 의미가 있을것이라 생각합니다.

  8. 안녕하세요. 이성열님
    이제 체계적인 개발을 위한 첫발을 내디신 겁니다. 소스코드관리시스템과 버그관리시스템도 제대로 쓰려면 시간이 한참 더 걸립니다. 제 책을 보시면 조금 도움이 될 겁니다.
    현재 겪고 계시는 문제의 50% 이상은 스펙 문서의 부재에서 온다고 보면 됩니다. 유지보수 단계라고 해도 스펙 문서가 없다면 계속 악순환 밖에 될 수 없습니다.
    또 다음 제품부터 스펙을 작성하려고 마음을 먹었다고 해서 그렇게 될 가능성은 거의 Zero입니다.
    코드 리뷰로 유지해 나가는 것은 차차차선책쯤 됩니다.

  9. 답변 감사합니다.

    우선 우리회사의 사업분야 대해 간단히 설명을 드리면
    반도체 장비, LED, SolarCell 장비등의 제어 SW 개발과 머신 비전 알고리즘 ,HW 개발 등입니다.
    개발자는 저를 포함 7명이고요 . (제가 사장 )
    고객업체에서 개발하는 장비에 들어가는 프로그램믈 만들어야하는데..
    기본적으로 1인 1프로젝트 식으로 진행합니다.
    2인 1프로젝트를 하더라도 개발 단계에서 GUI, 스퀀스 제어등으로 나누어서 진행하고
    개발이 끝나면 거의 1명이 맡아서 합니다.
    다행히 어떤 장비를 하던지 기본 SW 라이브러리를 사용하고 GUI등을 비슷한 구조로 만들기 때문에
    다른 사람이 분석하는데 큰 문제는 없습니다.

    유지보수는 한사람이 다수 프로젝트를 하고 있으나 문제가 생겼을때 서로 도와 줄 수 있을 정도로
    각 프로젝트 소스에 대한 이해는 하고 공유하고 있습니다.
    장비가 납품되면 유지보수가 자주 일어나는것은 아니지만.. 거의 장비 폐기 전까지 가끔씩이라도 SW 유지보수가 진행되기 때문에 .. 오래된 개발자들은 거의 모든 프로젝트 소스를 디버깅 할 정도까지는 이해하고 있습니다.

    일단..개발시 한 프로젝트에 다수가 참여하는 일반적인 다른 업체와는 조금 성격이 다르기는 합니다.

    그리고 장비 개발하는 고객사에서 초기에 스펙을 거의 작성하지 않고 , 소프트웨어는 물론 기구 하드웨어 스펙도 정확히 없는 경도 많습니다. 당연히 소프트웨어는 어떤 기능들이 들어가야 하는지 정확한 스펙정의 과정이 전혀 없습니다.
    그렇다고 우리가 다 스펙을 작성해서 고객사에 제시하기에는 개발일정이 바로 코딩 들어가도 빡빡 일정이라도 힘들고요. 고객사도 자신들이 원하는 소프트웨어가 어떤 기능이 필요한지 대충 밖에 파악을 못합니다.

    결론적으로 고민은 고객쪽에서 요구사항, 스펙 작성 등이 전혀 안되고 있는 상황에서
    개발 문서를 어떤식으로 작성해야 하는지 고민입니다.

  10. 안녕하세요. 이성열님
    온라인소프트웨어개발역량 분석도 답장을 보냈으니 확인해보세요. ^^

    말씀하신 스펙에 관련된 내용은 전혀 특이한 상황이 아닙니다. 많은 회사들은 자신들만 이러한 상황이라고 생각하는데 그렇지 않습니다. 더 열악한 경우도 많습니다.

    이렇기 때문에 스펙을 작성하는 역량이 있어야 합니다. 지금도 스펙을 그냥 문서에 적는 행위로 생각을 하시는 것 같은데 문서에 적는 것은 결과를 기록하는 것 뿐입니다. 분석역량이 있어야 한다는 뜻입니다. 대부분은 회사는 분석역량없이 자신의 상황만을 핑계로 대는 경우가 많습니다.

    스펙은 계속 변하고 초기에는 잘 모르기 때문에 분석을 잘하고 상황에 맞게 잘 대처를 해야 합니다. 이는 스펙을 한번 제대로 적어보면 그때 이해를 할 수 있지 그전에는 100번 얘기를 해도 이해하기는 불가능합니다.

    또 한가지 위험한 것은 개발자 각각에 전적으로 의존을 하는 것입니다. 개발이 너무 쉬워서 개발자가 교체가 되어도 누구나 다 할 수 있는 것이라면 문제가 없겠죠. (이러면 경쟁력도 없겠죠? ^^) 하지만 그렇지 않다면 개별 개발자에 의존하는 것 자체가 큰 리스크입니다. 회사에서 개발자가 가장 중요한 자산이지만 특정 개발자에 의존하는 시스템은 매우 위험합니다. 개발자가 아플 수도 있고 퇴사를 할 수도 있습니다. 개발자는 팀으로서 힘을 낼 수 있어야 합니다.

    회사의 시스템과 프로세스가 80%정도를 차지하고 개발자의 Risk는 20%정도만 유지해야 합니다. 대부분의 회사는 80% 개발자에 의존하기 때문에 개발자가 1,000명이 넘는 회사나 10명이 안되는 회사나 똑같이 인적 Risk가 엄청나게 큽니다.

    이렇게 하지 않으면 개발자가 성장하기도 어려워집니다. 회사와 개발자에게 모두 손해입니다.

    스펙 작성의 힌트는 제 책을 참조하시기 바랍니다. 제일 좋은 방법은 미국 실리콘밸리의 SW회사에서 몇년 일해보는 것인데 그렇지 않다면 분석전문가와 같이 프로젝트를 하면서 실제로 스펙을 적어보는 겁니다.

    열정을 가지고 회사를 운영해나가는 모습이 매우 보기 좋습니다. 궁금한 것이 있으면 언제든지 연락주시기 바랍니다.

Peer Review의 방해꾼들

2009.04.02 23:10 by 전규현


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




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

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

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

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

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

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

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

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

전규현 개발문화 Peer Review, 개발자, 공유, 리뷰, 문화, 방해, 성장

  1. Blog Icon
    ~_~

    아무런 문서화도 로직설명도 끝나지 않은채 버그리포트를 시키고 수정하라고 시키는 사람도 있다는거...

  2. 별의별 사람이 다 있죠.

  3. Blog Icon
    아름드리

    제가 있던 회사에도 자신이 만든 프로그램의 소스 코드를 암호화 수준까지 작성해서 아무도 안 보여주는 사람이 있더군요. 이런 사람 얘기는 웹을 통해서 간혹 봤지만 실제로 보니 대책이 안 서더군요.

  4. 아름드리님 반갑습니다.
    이런 개발자들을 어떻게 해야 하는지는 제 블로그의 여러 글들에서 언급을 해 놨습니다. ^^

Peer Review의 치명적인 유혹

2009.04.01 10:51 by 전규현


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



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는 동료들간에 서로 같이 검토를 해 주는 것에 의의가 있습니다.

이미지출처 : Microsoft Office Online
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.  

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

전규현 개발문화 KPI, Peer Review, 검토, 관리자, 동료, 리뷰, 상벌, 평가, 포상

  1. 문제는 대부분의 회사나 관리자가 '평가에 반영하기 부적절한 Peer Review 결과' 를 가지고 죽어라 평가항목을 만들어 대는 게 아닐까 싶습니다.
    등록한 버그 갯수 가지고 테스터 평가하려는 것처럼요...

  2. Shawn님 안녕하세요.
    KPI를 제대로 만드는 것이 얼마나 어려운 일인지 모른는 경영자나 관리자도 꽤 많습니다. 등록한 버그 수를 가지고 테스터를 평가하면 개발자와 짜고 버그를 많이 만들어내면 되겠네요. ^^ 이런 삽화도 본 적이 있습니다. 찾아낸 버그수대로 보너스를 지급하겠다고 하니 나는 오후에 스포츠카를 살 수 있다고 하더군요. ㅎㅎ

  3. 어휴, 그러게요. 생각만 해도 끔찍합니다. ㅠㅠ

  4. 반갑습니다. 최종욱님
    이런 경험이 있으신가보죠?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바