태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

레퍼런스 있어요?

2009.07.15 23:18 by 전규현


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



컨설팅을 하다보면 종종 듣는 질문이 레퍼런스 있냐는 말입니다.

또 이걸 시행하면 시행전보다 몇%의 생산성의 향상을 가져오는지 수치로 알려달라고 하는 사람들도 있습니다.

히딩크가 한국에서 와서 기초 체력훈련에 집중할 때 반대 했던 많은 사람들처럼 소프트웨어를 개발하기에는 너무나 기초가 취약한 수많은 기업에서 아주 기초적인 것들을 도입할 때도 종종 이런 말을 듣게 됩니다. 

레퍼런스는 Global 소프트웨어 회사 전부이고, 생산성 향상을 논할 수 없을 만큼 기초적인 것이다라고 말을 해야 하지만, 그렇게 얘기를 하면 기분이 나쁠 수 있으므로 애둘러서 말해야 합니다.

아직도 국내 소프트웨어 개발 환경 및 역량 수준이 Global 수준과 너무나 큰 차이가 나는 것이 현실입니다. 레퍼런스를 따질 때가 아니고 기초부터 다시 다져야 합니다.

정부에서는 Global 수준의 소프트웨어 개발 방법을 배우기 위해서 외국인들을 활용하려고 하는 정책들이 나오고 있는데, 또, 헛돈을 쓰는 시행착오로 끝날 것이 불 보듯 뻔합니다. 국내 현실을 전혀 모르는 외국인들이 과연 국내 소프트웨어 회사들을 어떻게 바꿀 수 있을지 그림이 안 나옵니다. 영어도 잘 안 통하는 한국에서 또 뜬구름 잡는 소리만 하고 비싼 세금으로 만든 비용을 받아 가겠죠. 

결과를 지켜봐야겠습니다.

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

전규현 소프트웨어이야기 레퍼런스, 소프트웨어 개발, 컨설팅

  1. 솔찍히 기초만 다지라고 해서 될일은 아니라고 생각이 됩니다.
    교육기반 자체가 암기식이고 왜? 라는물음을 배제한 채 다 커버린 교육의 결정체인 개발자에게 초심으로 돌아가라는건 개인에게만 너무 책임을 전가하는 행위라고 보여집니다.
    물론, 살아남기 위해서라도 스스로가 기반을 다져야 하는 것은 옳지만 말이죠.

  2. 안녕하세요. 구차니님
    기초라는 것이 개발자가 혼자서 어떻게 해 볼 수 있는 것이 아니고, 회사의 조직, 프로세스, 관리방식, 시스템등을 말하는 것입니다. 그런 것 없이 개발자들보고 알아서 잘 해보라는 것은 무리죠. 제대로된 환경에서 개발을 해야 개발자들이 또 역량이 올라고요. 지금은 너무 당양한 것들을 안하면서 뭔가 근사한 것만 찾는 회사가 많아서 문제입니다.

  3. 저도 컨설팅일을 하고 있지만 레퍼런스라는 것은 중요한게 맞는것 같습니다.
    특히 같은 업종이나 같은 나라의 레퍼런스라는 것은
    이미 경험을 해봤고, 문제가 무엇임을 알고 있기 때문에, 좀더 프로젝을 제대로 돌아가기 때문에 레퍼런스가 중요한 것 같습니다. 그리고 C레벨 경영자가 ROI를 따지는 것은 당연한 일이구요. 돈받고 무언가를 팔려면 그만한 가치를 하고 증명을 하는게 당연한 일이겠지요.
    국내 소프트웨어 수준에 대해서는 외국 컨설턴트와 많이 일을 해봤지만 구현 기술에 있어서는 어느 나라 못지 않습니다. 프로세스 부분에 특히 관리 부분에서는 문제가 많지만 국내 고객 요건이 해외에 비해서 훨씬 까다롭고 더 높은 수준의 요구사항이 많기 때문에 국내 환경이 꼭 나쁘다 수준이 낮다고는 할 수 는 없을것 같습니다.

  4. 조대협님 안녕하세요. 반갑습니다.
    조대협님의 블로그는 즐겨보고 있습니다.

    레퍼런스란 참 중요하죠. 그런데 제가 하는 컨설팅은 레퍼런스를 찾기가 참 어려운 분야입니다. 국내에서는 제대로 하고 있는 회사를 찾기가 어렵고, 외국에서는 당연한 것들이니까요. 새로운 솔루션을 제안하는 것이면 쉬울텐데, 소프트웨어 개발 문화를 향상하고, 개발프로세스를 정비하고, 스펙을 쓰고, 소스코드를 관리하고 하는 것들은 워낙 기초이고 당연한 것들이어서, 꼭필요하다는 것을 증명하기가 짜증나는 경우입니다. 그럼에도 왜 그렇게 해야 하는지 증명하기를 요구하는 경우도 있습니다. 그리고 이런 부분까지 너무 ROI를 따지는 경영자들은 대부분 소프트웨어 개발자체를 너무 이해하고 있지 않기 때문에 성과를 내기도 어렵고 왠만하면 일하고 싶은 생각이 없죠.

    또 지적한바와 같이 국내 소프트웨어 회사들의 구현 기술이 뛰어난 것은 동의합니다. 그런데, 이를 뒷바침하여 글로벌 경쟁력 있는 소프트웨어를 만들어내고 유지할 수 있는 프로세스, 시스템, 조직등이 저변이 취약하여 일정 수준 이상을 뛰어넘지 못하고 있는 것을 보면 안타까죠.

  5. 컨설턴트이던 개발회사이든 레퍼런스는 클라이언트가 안심하고 일을 맞길 수 있느냐 없느냐를 결정하는데 중요한 사항 중 하나라고 생각합니다.

    예를 들어 개발회사 A가 국내 최대 이통사에 솔루션 K를 납품하고 운영한 경험이 있다고 하더라도 이건 가입자 2천만명을 처리한 경험이 있다라는 이야기밖에 되지 않죠.
    이런경우 가입자 6천5백만명을 갖고 있는 해외 모 이통사에서는 해당 업체 A에 뭔가를 맞기기에 불안할 수밖에 없을겁니다. 수치상으로도 3배가 넘는 트래픽을 감당해야 하니...

    그래서 많은 회사들이 양질의 레퍼런스를 늘릴 기회가 된다면 적자를 감수하고서라도 프로젝틀를 진행하려고 하는게 아닐지요.

    글 잘 읽고 갑니다. :)

  6. 안녕하세요. 우울한딱따구리님

    당연한 말씀입니다. 그렇게 중요한 시스템을 도입한다고 한다면 레퍼런스가 아주 중요하죠. 그런데 저희 컨설팅 분야는 그렇게 수치적으로 뭔가 보여주기가 어려운 측면이 있습니다. 소프트웨어 회사를 분석해서 조직 및 프로세스를 개선하고 교육을 시키고 하는데, 뭔가 증명해 보이기는 어렵죠. 제가 만난 수많은 회사들의 소프트웨어 개발 역량은 대부분 10점만점에 1,2점인데 비해서 마음만은 8,9점이죠. 이런 회사들도 설득할 수 있는 증거들이 필요할 것도 같네요. ^^

  7. Blog Icon
    [1002]

    컨설팅 전/후 효과에 대한 분석을 위해 어떤 요소들을 측정하나요? 생산성과 운영비용에 대한 측정, 결함율 분석, 잠재 리스크 및 리스크에 대한 비용과, 프로세스 개선 뒤의 생산성 향상 및 운영비용 감소, 결함율 감소, 리스크 감소 등에 대하여 정량적 혹은 정성적으로 어떻게 분석하는지 궁금합니다.

  8. 이것이 정량적으로 측정이 거의 불가능합니다. 하지만 가끔 이런 것들에 대한 정량적인 자료들이 있기는 하더군요. 코드리뷰 전후의 소프트웨 결함 및 처리 비용 비교, 전문적인 테스트 팀이 있는 경우와 없는 경우의 비교 등등 하지만 그 숫자들을 액면 그대로 믿기 어렵고 그 성과가 회사마다 너무 다르고 또 너무 당연한 것들이기 떄문에 컨설팅 후에 그 성과를 수치적으로 평가를 하지는 않습니다.

  9. Reference는 둘째 치더라도 정성/정량적인 사항은 담당자 선에서 보고서엔 필수적으로 포함을 시켜야 하기때문에 요구할꺼에요. 또 컨설팅 입장에서의 고객 Case Study, 고객 만족도/반응도 를 제시하여 주는 것도 좋은 마케팅 툴 중에 하나죠.. 국내 Infra가 취약하긴 하지만.. 그래도 취약한 Infra의 담당자 및 임원을 객관적인 자료로 제안/설득 및 향후 도입효과를 측정해주는 것도 컨설팅 회사의 주요 Activity이지 않나 싶습니다.

  10. 안녕하세요. Peter님
    지금까지는 어떻게 보면 불모지와 같았었는데, 점차 그런 자료들이 필요해보이는 군요. 저희 회사에서도 그동안의 경험으로 많은 자료가 축적이 되었으므로 점차 그런 정량적인 데이터를 만드는 것을 시도해볼 필요가 있어보이네요. 감사합니다.

악순환 vs. 선순환

2009.05.22 12:24 by 전규현


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




지난번 글 (이 바닥을 못 벗어 난다.)의 추가 글입니다.
회사가 Risk가 큼에도 불구하고 Domain 지식이 점점 더 매달릴 수 밖에 없는 이유와 선순환을 하려면 어떻게 해야 하는지 좀더 현실감 있는 예를 보여주려고 합니다.
회사마다 상황이 모두 다르기 때문에 각자의 상황과 1:1로 다 일치하지는 않지만 참고하실 수는 있을 겁니다.
그럼 악순환과 선순환에 대해서 알아보죠.

Domain 지식에 점점 매달리게 되는 악순환의 고리

  • 주먹구구식 개발
  • 개발자에 의존한 코딩 중심의 개발 주도
  • 없거나 빈약한 개발 프로세스 및 개발 문서
  • 회사의 지식은 개발자 머리 속에 보관
  • 개발자 간 지식의 공유가 어려움
  • 후배 개발자들에게 지식 전달이 잘 안됨
  • 프로젝트가 커질수록 협업이 점점 어려워짐
  • 점점 더 경험 많은 개발자에 의존하게 됨
  • 경험 많은 개발자는 계속 더 바빠짐
  • 경험 많은 개발자들도 체계적인 개발은 꿈도 못 꾸고 매일 밑바닥 개발에 매달림
  • 개발자들이 Domain 지식은 점점 늘어가는데 소프트웨어 공학지식은 잘 늘지 않음
  • 회사에서는 신규 직원을 뽑아도 같이 협업이 잘 안되므로, 동일 Domain의 경험이 많은 개발자를 선호하게 됨
  • 경험 많은 개발자들이 퇴사를 해서 회사가 큰 타격을 입기도 함
  • 또 고참 개발자들이 퇴사할 까봐 전전긍긍하게 됨
  • 회사에서는 개발자들의 머리 속에 있는 지식을 공유하고 체계적으로 개발하고 싶으나 방법을 모름
  • 이에 대한 개혁을 해보려고 해도 번번히 고참 개발자들의 방해로 무산됨
  • 점점 더 경험 많고 Domain 지식이 풍부한 개발자들에게 의존하게 됨
  • 규모 있는 개발을 못하고 인원수에 의존한 개발을 하게 됨
  • 회사는 성장을 못하고 정체하게 됨
  • 고참 개발자들은 성장을 못하고 매일 밑바닥 코딩과 문제 해결에 매달리게 됨
  • 또 주먹구구식, 가내 수공업식 개발을 반복하게 됨

프로세스 중심의 선순환의 고리
  • 회사가 소프트웨어 개발에 필요한 적절한 프로세스와 인프라스트럭처 시스템을 갖추고 있다.
  • 개발자들은 프로세스 중심으로 개발이 되도록 잘 훈련 되어 있다.
  • 프로젝트 진행 시 꼭 필요한 스펙 문서와 설계 문서를 적절하게 만든다.
  • 문서와 코드에 대해서 적절히 Peer review가 이루어져서 지식의 전달이 잘 되고 결함이 사전에 제거된다.
  • 고참 개발자들은 코딩 보다는 주로 아키텍처와 비즈니스에 대해서 고민하고 해결한다.
  • 잘 작성된 스펙 문서와 설계 문서를 보고 후배 개발자들이 코딩하고 테스트 팀이 테스트를 진행한다.
  • 고참 개발자들은 오랜 개발 경력으로 Domain 지식도 풍부하지만 소프트웨어 공학 지식 및 경험도 풍부하다.
  • 후배 개발자들은 Domain 지식은 부족하지만, 설계 문서를 보고 인프라스트럭처 시스템을 활용해서 프로세스에 따라 개발하는데 별 문제가 없다.
  • 신규 개발자를 뽑아도 교육이 용이하고 바로 실무에 투입하기가 쉽다.
  • 고참 개발자들이 퇴사를 해도 상당히 많은 지식이 문서화 되고 이미 후배들에게 전파가 되어 있으므로 회사의 타격이 상대적으로 적다.
  • 퇴사한 고참 개발자들은 이직이 용이하고 더 높은 연봉으로 타 회사로 옮길 수 있다.
  • 회사에서는 Domain 지식이 너무 매달리지 않고, 실제로 Software 공학 지식이 뛰어나고 Software 개발 자체를 잘하는 인재를 선호하게 된다.
  • 회사가 성장하고 개발 규모가 커져도 문제 없이 대응할 수 있다.

그럼 악순환에서 선순환으로 바뀌는 방법에 대해서 의문을 가질 수 밖에 없습니다.
이는 참 어려운 숙제입니다. 
운동을 안한다. -> 몸이 무거워진다. -> 운동을 더 안한다. -> 몸이 더 무거워진다.
이런 악순환의 고리를 끝는 것은 무엇을 까요? 일단 운동을 시작한다? 99%는 실패할 겁니다.
운동은 습관도 안들어 있고, 제대로 운동하는 방법도 모르고, 또 귀찮아지면 언제든지 포기하고, 잘못된 운동 방법으로 다칠 수도 있습니다. 그러면 운동에 대한 나쁜 기억만 쌓이고 다음번에는 더욱더 운동을 시도하지 않게 될 겁니다.

그래서 악순환의 고리를 끝는 것을 쉽게 얘기를 할 수 있어도 현실적으로 가능한 방법을 제시하는 것은 쉽지 않습니다. 물론 가장 적절한 방법도 회사마다 다릅니다.

하지만, 악순환의 고리를 끝는 방법 중에서 필수 요소는 경영자의 의지입니다. 경영자가 이러한 상황을 전혀 이해 못하고 있거나 의지가 없다면 그냥 계속 악순환의 고리를 돌면서 영업이나 잘하는 수 밖에 없습니다.
개발자들이 으쌰으쌰해서 점진적으로 개혁을 해보려는 시도는 매우 더딜뿐만 아니라 다양한 도전 및 방해로 무산될 가능성이 큽니다. 그래도 그런 과정에서 개발자들이 본인 스스로 공부는 될 수 있겠네요.

경영자가 의지만 있다면, 조직, 시스템, 프로세스적인 다양한 측면에서 효과적이고 적절한 개혁을 시도하여 회사를 바꿔나가서 점점 선순환의 고리로 옮겨 갈 수 있습니다. 


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

전규현 소프트웨어이야기 Domain지식, 문서, 소프트웨어 개발, 프로세스

  1. 오픈 세미나에 와주셔서 늦은 시간까지 열강해 주신것 너무 감사드립니다. 좋은글을 잘 읽고 갑니다.

  2. 황상철님 안녕하세요.
    열심히 하시는 모습이 보기 좋았습니다. 젊은 개발자들은 만나는 것은 언제나 즐거운 일입니다.

    주제가 조금 어려워서 전달이 잘 되었을지 걱정입니다. 만약 다음에 기회가 된다면, 좀더 쥬니어들에게 직접 와닫는 주제를 한번 정해봐야겠습니다. 감사합니다.

나는 혼자가 아니다.

2009.05.15 23:18 by 전규현


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



지금 내가 생각하고 행동하는 것은 나 스스로의 힘이 아닙니다. 과거의 수많은 대가들이 이룩해 놓은 지식, 경험과 지혜를 간접적으로 배우면서 자라온 내가 있고 그 바탕 위에 내가 존재 합니다.
이런 성현들의 지식이 없다면 지금의 내가 존재 할 수 있을까요? 원시인과 별 차이 없는 내가 있겠죠.

소프트웨어를 개발하다 보면 수많은 문제에 부딪히는데 그 대부분은 이미 과거에 소프트웨어 개발의 대가들이 다 겪은 후에 그 해결책을 다 만들어 좋은 것들입니다. 그렇지 않고 소프트웨어 역사상 처음 발생하는 이슈는 거의 없습니다.

그런데 많은 개발자들의 개발 행태를 보면 마치 최초의 선구자 같이 행동을 합니다. 과거에서 배우지 않고 자신의 지식과 경험 테두리 안에서 별 희안한 방법들을 생각해 냅니다.

피아노를 배우려고 하는데, 모짜르트도 모르고 그냥 혼자 피아노를 연습하는 것 같습니다. 지금의 피아노 연주 기술은 과거의 수많은 음악가들이 없었다면 존재 할 수 없죠. 또 그 기술은 혼자서 인터넷 보고 익힐 수 있는 것이 아니고 스승에게 배우고, 혼자서 또 부지런히 연습을 해야 합니다.

문서를 왜 써야 하는지? 
Peer review를 왜 해야 하는지? 
소스코드를 어떻게 관리해야 하는지? 
빌드는 어떻게 해야 하는지? 
고객이 요구사항을 자주 바꾸는데 어떻게 해야 하는지?
테스트는 어떻게 해야 하는지?
Internationalization은 어떻게 해야 하는지?
버그 관리는 어떻게 해야 하는지?
개발 시간을 어떻게 단축할 수 있는지?

이외에도 수천가지 소프트웨어 개발 이슈들은 이미 과거의 대가들이 다 고민하고 방법들을 제시해 놓은 것들입니다. 하지만 이를 배울 스승이 부족하고, 책만 보고 배우기는 어렵기 때문에 나름대로의 방법들을 사용하고 있습니다. 그래서 결국에는 한계에 부딪히게 됩니다.

이러한 지식들을 총칭해서 소프트웨어 공학이라고 합니다. 과거의 대가들에게서 간접적인 도움을 받으면서 소프트웨어를 효과적으로 제대로 개발을 하려면 소프트웨어 공학에 관심을 가져야 합니다. 책을 보면서 간접 경험을 하고 전문가나 스승을 만날 기회가 있다면 최대한 많이 배우려고 노력하고, 가장 좋은 방법은 그런 대가들이 바글바글한 회사에 취직해서 직접적인 경험을 하는 것이지요. 

이미지출처 : Microsoft Office Online

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

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

  1. 개발자의 자존심이 남이 이미 겪은 문제일것이다라는 걸 생각도 못하게 가끔은 막더군요
    그래도 아주 드문 문제들은 구글신의 힘을 빌어도 안나오니(어쩌면 키워드 문제일지도..)
    이럴때 만큼은 자존심을 발동해도 되려나요 ^^

    그래도 남이 걸은 길을 걷는 것보다는, 자기가 스스로 길을 찾아 가며(비록 남이 길을 만들어 놨더라도) 한걸음씩 성숙하는게 더 좋지 않을까 생각을 해봅니다.

  2. 구차니님 안녕하세요.
    시행착오를 줄이면서 스스로 길을 찾는 것도 좋은 방법이라고 생각합니다. 뭐든지 적절히 조절하는 것이 좋겠지요.

  3. "가장 좋은 방법은 그런 대가들이 바글바글한 회사에 취직해서 직접적인 경험을 하는 것이지요. "
    -> 이 말이 너무 와닿는군요. 서브버전이 scm의 한 종류라는 것도 모르는 9년차 선배가 있는 회사를 다니는 중 입니다...

  4. 두렁청해님 안녕하세요.
    우리나라 대부분의 소프트웨어 회사의 현실이 그러니 크게 실망하지 마세요. 회사가 아니더라도 경험할 곳은 많으니 두렁청해님이 한번 lead 해 보세요.

  5. 수습도 안끝난 신입이라 힘이 하나도 없네요
    말은 좋은거 있으면 같이 배우자~ 좋은 안 내봐라~ 이러면서 막상 자기가 하던 방식 아니면 할려고 안하더군요~
    물론 설명해드렸지요~^^
    서브버전 쓰면서 커밋, 체크아웃, 업데이트 3가지만 잘 사용해도 희망을 가질텐데 서브버전 서버를 ftp처럼 쓸려고 하더군요.ㅠㅠ

거만한 속빈 강정

2009.04.09 21:58 by 전규현


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



소프트웨어 개발 경험도 개발자가 미국 실리콘밸리의 소프트웨어 회사에 입사해서 5년이면 배울 수 있는 것(소프트웨어를 개발하는 방법)을 우리나라에서는 10년, 20년 아니 30년을 소프트웨어만 개발해도 배우지 못합니다.

오히려 이런 경험 많은 고참 개발자들은 배울 수 있는 기회가 눈앞에 와도 배울 수가 없게 됩니다.
책을 하나 봐도 대부분 아는 내용이라고 저자를 평가 절하하지만 아는 수준이라는 것이 용어 한번 들어보고 샘플 좀 사용해 본 정도인 경우가 대부분입니다.

예를 들어 소스코드관리시스템에 대한 내용을 봐도 내가 대형SI회사에서 10년 넘게 개발을 했는데, 이런 것을 모를까봐?라고 생각하지만 고작 소스코드 백업 받듯이 저장하고 태깅 좀 한 정도 가지고 소스코드 관리를 제대로 하고 있다고 착각합니다. 

오히려 이러한 개발자들은 온갖 화려한 기술과 온갖 툴 및 기법에 능숙해서 UML의 도사이고 자신은 아키텍트라고 하면서도 진짜 설계는 할 줄도 모릅니다. 이런 고참 개발자들은 아무것도 모르는 신참 개발자보다 제대로 배우기는 훨씬 어렵습니다. 신참 개발자들은 책이나 강연을 통해서 배움이 기회가 왔을 때 자신은 잘 모르고 부족하다고 생각을 하기 때문에 받아드리려는 마음이 있으나 이런 고참 개발자들은 자신들이 잘 알고 개발을 잘하고 있다고 착각하기 때문에 즉 자신의 무지를 모르기 때문에 배움을 받아드리려고 하지 않습니다. 또 자신이 해왔던 방식이 나름대로 편하다고 생각해서 바꾸기를 싫어하고 괜히 바꿨다가 회사에서 자신의 위상이 흔들리면 어떡할까 하는 걱정도 하곤 합니다.

2,3년 된 신참 개발자들은 회사에서 제대로 된 개발 환경 및 교육의 기회만 주어진다면 4,5년 안에 이런 고참 개발자들보다 훨씬 뛰어난 실력을 갖는 것은 그리 어려운 일이 아닙니다. 또 배우려고 하지 않는 고참개발자들은 세계 최고의 소프트웨어 대가가 와도 이들을 가르칠 수는 없습니다. 그냥 그렇게 회사에서 정치나 하면서 연명을 하는 수밖에 없습니다. 다른 회사로 이직을 하면 자신의 위상이 확 떨어지니 회사에 꼭 붙어 있어야겠지요. 물론 은퇴 전에 회사가 망하면 큰 일지만 말입니다. 

그런 일을 당하지 않으려면 마음을 바꿔 먹어야 합니다. 물론 정말 실력이 뛰어난 개발자들도 많이 있지만, 자신이 소프트웨어 개발을 잘하고 있다고 착각하는 고참개발자들은 늦었지만, 바뀌어야 합니다. 

자신이 정말로 뛰어난 개발자인지? 뛰어나다고 착각하는 것인지? 어떻게 아냐고요?

  • 후배 개발자들이 많이 있는데 아직도 주로 코딩에만 매달리면서 자신이 코딩을 하지 않으면 개발이 잘 안될 것 같습니까? 
  • 문서를 만들면서 개발을 하는 것보다 코딩부터 개발을 하고 문서는 불필요하다고 생각하시나요?
  • 문서를 만들어도 다른 개발자들이 이해를 잘 못하나요? 
  • 자신은 개발을 정말 잘하는데 후배 개발자들은 정말 실력이 떨어진다고 생각이 드나요?
  • 후배들이 실력이 딸려서 같이 일하기 정말 힘듭니까?
  • 후배들에게 잘 설명해줘도 원하는대로 개발이 진행이 잘 안됩니까?
  • 개발은 기가 막히게 하는데 회사의 비즈니스 상황은 잘 모르나요?
  • 개발에만 집중하고 소프트웨어 기획, 테스트, 배포 등의 전반의 내용은 잘 모르나요?
  • 해당 Domain 지식(업무지식)에 대해서 도사급이라 다른 업계로 이직은 싫은가요?
  • 소스코드관리, 버그관리는 기초기능만 사용하나요? (기초의 기준이 뭔지 알기 어렵겠군요.)
  • 개발프로세스는 불필요하거나 불편한 것이라고 생각하시나요?
  • 경영자들에게 기술이나 아이디어를 설명해도 경영자들이 이해를 잘 못하나요?

너무 많아서 다 나열할 수가 없네요. 

이중에 몇 가지만 해당해도 착각하고 있는 것일 가능성이 대단히 높습니다. 착각에서 빨리 벗어나는 것이 자신의 미래를 위해서 이롭습니다.

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

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

전규현 사람과 기술 UML, 강연, 개발자, 고참, 소프트웨어 개발, 신참, 실리콘밸리, 프로세스

  1. Blog Icon
    Jake

    안녕하세요 레이님.
    속빈강정같은 고참 개발자를 가려내는 방법이나 착각에서 벗어나라는 조언 보다는 실리콘밸리에서 5년이면 배우는 것이 무엇이며 한국에서는 왜 10년 20, 30년을 해도 그것들을 못배우는지, 그리고 어떻게하면 5년이면 그런 것들을 배울수 있게 하는지를 조언해주셨으면 더 좋았을것 같습니다.

  2. Jake님 오랫만입니다.
    실리콘밸리에서 5년이면 배우는 것이 소프트웨어를 개발하는 방법이죠. 우리나라 개발자들도 다들 소프트웨어를 개발하고 있는데 이렇게 얘기하면 이상하다고 생각하겠지만, 제 경험에 의하면 정말로 다릅니다. 일단 미국은 60년의 소프트웨어 역사를 통해서 소프트웨어를 개발하는 방법에 대해서 체계를 갖추고 있고, 개발자들은 그런 회사에서 개발하면서 자연스럽게 익히는 것을 우리나라의 개발자들은 그런 기회가 없습니다. 그냥 코딩 실력과 몇몇 지식과 기법을 통해서 개발을 하는데, 그 기초가 너무 취약합니다. 그것이 무엇이냐고 물으면 책을 몇권 써야 설명이 다 되겠지요. 물론 미국에도 엉터리로 개발하는 회사도 있고 우리나라에도 잘하는 회사들도 많죠. 하지만 그 비율이 현격하게 차이가 나는데 문제가 있습니다.

    골프를 배우려고 하는데, 혼자서 책보고 비디오 보고 배우는 것과 골프를 처음 시작할 때부너 골프 코치에게 배우는 것의 차이라고 할까요? 그럼 코치에게 배우는 것은 무엇인가? 너무 많아서 한마디로 말할 수 없습니다. 또 우리나라에는 골프를 배울 수 있는 골프코치가 그리 많지 않고 미국에는 널려 있는 상황과 비슷합니다.

    또, 제대로된 방법 딱 하나를 상세하게 설명해주면 그대로 따라하면 되지 않을까?라고 생각해도 골프도 그렇게 안된다는 것은 쉽게 예상할 수 있듯이 소프트웨어도 그렇게는 안되죠.

    그럼 어떻게 하면 배울수 있나? 인도의 개발자들처럼 미국이나 소프트웨어 선진국에 가서 배우는 것이 가장 좋은 방법이나 어렵죠. 그리고 고참개발자들은 이미 늦은 경우도 많구요. 이글의 말미에도 적었지만, 우선 마음부터 고쳐 잡아야죠. 그래야 여러가지 기회가 있을 때 받아드릴려고 하겠죠. 그 기회는 책이나, 강연이나, 전문가를 만나거나, 컨설팅을 받거나 등등 여러가지가 될 수 있습니다. 이럴 때 마음이 닫혀 있다면 배우지 못합니다.

  3. 요즘 저도 느끼는 거지만 SI를 7년 했더니 더이상 실력 향상이 안되는거 같습니다.
    좀더 심화 있는 개발을 하고 싶은데 매일 하는게 업무만 틀리고 거기서 거기인 느낌입니다.
    솔루션쪽으로 가고 싶지만 국내 솔루션은 열악한 환경이라 먹고 살려니 계속 SI에 남아 있게
    되네요.

  4. 묘재님 안녕하세요.
    SI가 나쁜 것은 아니지만, 환경은 그리 좋지 않습니다. 우리나라의 SI의 개발 형태를 보면 업무지식(Domain지식) 위주로 개발이 진행되므로 오래 개발을 할 수록 업무나 비즈니스 로직은 점점 잘 알게 되지만, 소프트웨어 개발 실력을 향상할 기회는 상대적으로 적어집니다. 솔루션을 개발해보는 것은 다양한 경험 측면과 생각의 다변화 면에서는 긍정적이네요. 하지만 솔루션을 개발하는 회사나 부서의 환경도 별차이가 없다면 결국 본인이 스스로 공부하고 찾아다니면서 익혀야 하는데, 어려운 일입니다. 묘재님도 끊임없이 공부하시는 것 같으니 잘 될겁니다. ^^

  5. Blog Icon
    아름드리

    저 같은 경우 대부분 혼자 일하면서 어떻게 해서든 실력을 키우고 싶어 책을 보고 구글을 했습니다. 그제야 문서화, 소스 관리, 빌드 시스템, 테스트 등 제가 반드시 알아야 하는 것들이 있다는 것 알았습니다.
    주위 개발자들에게 개발 프로세스를 적용해 보자고 해도 다들 무관심이네요. 저라도 성과를 얻으면 조금이라도 관심을 보일까 생각해 열심히 노력하고 있습니다.

  6. 아름드리님 안녕하세요.
    본인이 아는 것보다 남을 설득하는 것은 10배이상 힘듭니다. 특히 본인이 완전히 확실히 알지 못하고 같이 잘 해보자고 하는 입장이면 더욱 어렵죠. 그리고 아름드리닙도 책보고 구글보고 할 수 있는 것은 한계가 있다는 것을 느낄 수 있을 겁니다. 책보고 골프를 배우는 것과 같죠. 제가 무료 세미나도 하고 있으니 관심있으면 연락주세요. 감사합니다.

  7. Blog Icon
    bluepoet

    Ray 님 안녕하세요. 항상 글 잘보고있습니다.
    저도 2년차 소프트웨어 개발자인데. 전 외국계 대기업회사에 근무하고있습니다. 처음에는 제가 배웠던 소프트웨어 프로세스대로 철저하게 지켜지는게 너무나 대단해보였습니다. 2년차가 되니까 이것저것 생각이 많아졌나봅니다. Qa team, Release team, Dev Team,Arch Team간에 Customer 가있는 Project의 경우 Process를 가지고 상당한 논의가 되곤합니다..이런 모습을 보면서 꼭 Process를 지켜야되는것이 올바른 길은 아니라는생각도 해보게 되었습니다. 외국계지만 여전히 지적해주신 사항들을 숙지못하고 Process에 관심이없는 엔지니어들도 많답니다..

    저도 좀더 포괄적으로 이해할수있는 능력을 길러야겠습니다.
    ^^

  8. bluepoet님 안녕하세요.
    개발 2년차인데 벌써 이런 경험을 하고 생각을 하고 있다는 것은 아주 긍정적입니다. 미래가 총망되네요. ^^

  9. 글을 읽고 오전내내 괴로웠습니다. 그동안 정말 뭘 한건지 그리고 앞으로는 또 어떻게 해야할지... 더욱더 마음이 무거워지네요...좋은글 감사합니다.

  10. redef님 안녕하세요. 깨달음은 한순간에 오기도 하더군요. 아직 기회가 많이 있으니 잘하실 것 같습니다. ^^

  11. 우물 안 개구리는 누가 우물밖으로 개구리를 꺼내주기 전까지는 자기가 어디에 있는지 모르는것과 마찬가지이듯, 시스템으로 돌아가는 대기업이나 몇몇 업체를 제외한 대부분의 중소기업에서는 회사가 개인의 이런 경력발전을 위한 지원을 해주지 않거나 기회를 주지 않으면 개발자 스스로 이러한 걸 깨우치기는 어려운 것도 사실입니다.

    실상은 지적하신바와 같이 막상 이런 흔치 않은 기회가 와도 개발자 스스로가 그걸 거부하거나 준비가 되어 있지 않아 그 기회를 잡지 못하는 경우도 많다라는 것이 문제죠. 특히 초급 개발자나 프리랜서/소규모 회사를 너무 오래 다닌 개발자 중에는 '난 코딩만 할꺼야' 라는 마인드를 갖고 있는 것도 문제이고요.

    사내 정치라는 것에 대해서 개인적인 의견은, 이건 정말 2명 이상 모인 집단에서는 어디서나 발생하는 현상이라는 겁니다. 기본적으로 정치가들이 워낙 부정적인 의미라 나쁘게 들리긴 합니다만... 아무튼 문제는 기본적으로 개발자/공대출신 사람들이 이 정치력이 별로 없다라는 거겠죠. -_-;;

    글 잘 읽고 갑니다. :)

  12. 우울한딱따구리님 안녕하세요. 경험하지 않고 깨닫거나 스스로 알아내는 것은 기적이거나 천재겠죠?

  13. 학교 다닐때 경험하고 깨닫는건 학습, 경험하지 않고도 깨닿는 걸 지능이라고 배운 것 같은데데... 개인적으로 경험하지 않고 스스로 꺠우친 것들은 그리 많지 않은 것 같습니다. ㅜ.ㅜ

  14. 지식으로 깨우칠 수 있는 것이 있고, 골프와 같이 경험 없이 지식만으로는 익힐 수 없는 것이 있습니다. 소프트웨어도 지식과 경험이 모두 필요한 분야라고 생각합니다. ^^

다 만들었어요. 이제 테스트만 하면 되요.

2008.12.12 13:34 by 전규현


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



소프트웨어를 개발하는 회사에서는 자주 듣는 말입니다.
그런데, 이 테스트가 언제 끝날지 모르는 경우가 많습니다.

소프트웨어 개발 컨설팅을 하면서 정말 놀란 것 중의 하나가 대부분의 회사가 릴리즈 시 "알파", "베타", "RC", "GA", "FCS"와 같은 단계를 거치지 않는 다는 것이었습니다. 
대부분이 알파수준의 소프트웨어를 만들어서 만족스러울 때까지 테스트와 수정을 동시에 병행한다는 것이었습니다. 이는 큰 회사나 작은 회사나 별 차이가 없었습니다. 개발을 단계적으로 진행하지 않는 회사는 업무와 일정에 대한 정교한 구분 없이 일을 진행하다가 적당한 시점에서 한번의 테스트를 통해 제품을 완성하려고 합니다.
이를 빅뱅(Big bang) 테스트라 하는데 이 방법이 운 좋게 개발 기간을 단축시켜 줄지도 모른다는 기대감으로 일을 중구난방으로 진행하는 것입니다. 하지만 이는 전혀 근거가 없는 생각이며, 테스트를 한번에 끝낸다고 프로젝트가 더 빨리 끝나지는 않습니다. 이 방법은 테스트 기간 내내 혼란에 휩싸이게 만들고, 테스트가 언제 끝날지 도저히 예측할 수 없으며, 일정 기간 내에 품질이 얼마나 향상될 수 있을지 추측조차 하기 어렵습니다. 심지어 통합조차 잘 되지 않기 때문에 내포되어 있는 버그가 얼마나 되는지도 파악하기 어렵습니다. 결국 프로젝트 일정이 가시권에서 점점 멀어지게 됩니다. 운이 좋으면 밤을 새면서 일정대로 프로젝트를 마칠 것이고, 그렇지 않으면 프로젝트가 실패하게 됩니다. 



소프트웨어 프로젝트는 개발 단계 별로 관리하는 것이 좋습니다. 단계 별로 진행을 하면 각 단계가 명확해지기 때문에 프로젝트 진행 상황이 눈에 들어오고, 혼란으로 인한 재작업이 줄어 들며, 프로젝트 일정을 단축시키고, 비용을 절약해 줍니다.
특히, 높은 품질의 제품을 출시하기 위해서는 제품 및 프로젝트의 성격에 알맞게 단계 별 릴리즈를 하는 것이 좋습니다. 릴리즈는 알파, 베타, RC(Release Candidate)단계로 나뉘고 각각의 릴리즈 일정은 미리 계획하여 정해 둬야 합니다.


각 단계에는 다음과 같은 의미가 있습니다.

  • 프리알파(Pre-alpha): 알파 이전에 만들어내는 빌드들입니다. 개발 버전(Engineering version)이라고 하기도 합니다. 일일빌드(Daily Build)의 결과물도 프리알파에 해당합니다. 아직 기능이 모두 다 구현이 되어 있지 않습니다.
  • 알파(Alpha): 기능이 모두 구현되었으나, 버그는 꽤 많은 상태, 설치도 안되어서 기능을 확인해 볼 수도 없는 등의 버그는 없어서 모든 기능을 테스트 해 볼 수는 있습니다. 일부 작동이 안 되는 기능이 있습니다. 일반적으로 알파버전부터 테스트팀의 공식적인 테스트가 시작됩니다. 이를 알파테스트라고 부릅니다.
  • 베타(Beta): 중요한 버그는 거의 수정이 되어서 작은 버그들만 남아 있습니다. 베타 버전은 종종 사용자 평가(Evaluation) 및 외부 테스트(Field Test)를 위해서 외부에 배포되기도 합니다. 이런 목적으로 배포되는 버전을 베타 릴리즈라고 부르며 베타 버전을 사용해 보는 사용자를 베타 테스터라고 부릅니다. 베타버전 이전에 프리베타(Pre-beta)를 만드는 경우도 있습니다
  • RC(Release Candidate): 출시를 위해서 만들어진 버전입니다. FCS(First Customer Shipment), 감마(Gamma) 또는 델타(Delta)라고 부르기도 합니다.
  • GA(General availability): RTM(Release to Manufacturing)이라고 부르기도 합니다. RC 중에서 테스트를 통과하여 출시 할 수 있는 버전입니다. 일반적인 경우 마지막 RC와 동일합니다. 
이런 식으로 테스트팀에 전달하는 버전이 어느 수준인지 알려주어야 합니다. 그렇지 않으면 알파수준의 버전을 가지고 곧 고객에게 전달할 수 있을 것 같은 착각에 빠지기도 합니다.

모든 소프트웨어를 개발할 때마다 이 같은 단계를 전부 다 거쳐야 하는 것은 아닙니다. 제품의 규모와 난이도, 성격에 따라서 단계를 서로 다르게 정해야 합니다. 대규모 제품이거나 복잡한 팩키지 제품은 이 단계들을 거치는 것이 일반적입니다. 이런 제품을 한번에 높은 품질로 만들어 내기는 어렵기 때문입니다.

하지만 소규모 제품이거나, 고객의 수가 아주 적거나, 업그레이드 프로젝트라서 복잡도가 낮을 경우라면 처음부터 원하는 품질 수준에 근접하게 제품을 만들어 낼 수 있습니다. 이런 경우라면 테스트 단계를 간략하게 해서 진행할 수 있습니다.
저작자 표시 비영리 변경 금지
신고

전규현 개발프로세스 STAGE, 소프트웨어 개발

  1. 드디어 "소프트웨어 개발의 모든 것" 책을 구입했습니다. 어제부터 틈틈이 읽고 있는데
    역시 내용이 알차군요. 실전경험에서 나오는 포스같은것이 느껴집니다. 앞으로도 좋은 글
    많이 부탁드립니다.

  2. 헝그리맨님 안녕하세요.
    궁금하신 내용이 있으면 언제든지 얘기해주세요.
    감사합니다.

  3. 좋은 글 잘 봤습니다. 여러가지 생각들이 머리속에서 떠오르는 글이네요. ^^
    일정을 준수하며 프로젝트를 진행한다는건 항상 어려운 숙제처럼 늦겨지네요.
    프로토타입이 완성되고, 테스트가 진행되면 생각치 못한 사항들....
    매번 경험하는거지만, 처음은 간단한 것부터가 시작이지만 욕심이라는건 끝이 없나 봅니다.

  4. 태양공원님 안녕하세요.
    적어주신 방법은 "발전적인 프로토타이핑"이란 모델과 비슷하네요. 처음에 기술을 검증한 프로토타입을 만들고 점점 기능을 더해가는 겁니다. 프로토타입을 만드는 방법은 일반적인 프로젝트와 다르게 간단하게 진행합니다. 하지만 이 방법은 잘못하면 주먹구구식 개발로 빠질 수 있다는 단점이 있습니다.

  5. 잘 계획된 일정도... 실제 현장에서는 끊임없는 사용자의 변경요구로 인해 프로젝트의 마지막 단계까지 변경이 발생하는 경우가 허다하죠. 테스트 일정은 계속 지연되고 결국은 빅뱅테스트가 진행되어버곤 하죠. --;;

  6. 필넷님 안녕하세요.
    맞습니다. 그런 경우가 허다하지요. 그래도 원리와 원칙을 안다면 그런 상황에서도 좀더 잘 대응할 수 있겠죠. 제가 접한 수많은 회사는 별다른 생각없이 으례 그렇게 빅뱅테스트를 하고 있더군요. 이런 경우라면 문제겠죠.

  7. 빅뱅테스트에 익숙해진 우리나라 소프트웨어 개발 현실이 안타깝습니다.
    제대로된 소프트웨어 관련 관리자나 아키텍트가 절대적으로 부족한 듯합니다. 그리고 이를 뒷받침해줄 안목높은 경영진이 있어야 하는데, 여러모로 그런분들 만나기가 참 힘드네요~

    제대로된 테스트를 통하여 높은 수준의 어플리케이션이 제대로 평가받을 날을 기대합니다~
    좋은글 잘 읽고 갑니다 :)

  8. 장성진님 안녕하세요.
    더 좋은 방법이 있는데, 해오던 방법이 더 익숙해서, 잘 몰라서, 우리는 다르다고 생각해서 비효율적인 방법을 그냥 고수하는 경우가 많습니다.

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

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

소프트웨어 회사의 개발 역량 평가표

2008.10.29 10:14 by 전규현


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




아래 평가표는 소프트웨어 개발 회사나 개발팀이 얼마나 역량을 갖추고 있는지 평가하는 표입니다.

아래 각 문항에서 "예"(1점)에 해당하면 Checkbox를 체크하시면 됩니다.

1.전사적으로 소스코드관리시스템을 딱 하나만 사용하고 있다.
2.모든 소스코드 및 개발문서는 소스코드관리시스템에 저장되어 있다.
3.각 마일스톤마다 Baseline을 설정하고 있다.
4.소스코드관리시스템에 체크인 시 메시지를 작성하는 규칙을 가지고 있고, 모든 개발자가 이를 지키고 있다.
5.모든 소스코드는 리뷰를 하고 있다.
6.자동으로 일일빌드를 하고 있다.
7.전사적으로 버그관리시스템을 딱 하나만 사용하고 있다.
8.모든 버그를 버그관리시스템에 등록하고 있으며 다른 곳에 별도로 관리하지 않는다.
9.모든 직원이 버그관리시스템에 스스로 이슈를 등록한다.
10.프로젝트의 스펙문서를 가지고 있다.
11.스펙문서를 모든 관련자가 충분히 리뷰한다.
12.스펙이 바뀜에 따라 스펙문서가 업데이트되고 있다.
13.스펙 변경이 통제 관리되고 있다.
14.1,2일 단위의 상세한 일정을 가지고 있다.
15.일정은 개발자가 산정한다.
16.일정은 지속적으로 업데이트되고 있다.
17.별도의 테스트 팀이나 테스터가 있다.
18.테스트 케이스를 가지고 있다.
19.프로젝트 리스크 관리를 하고 있다.
20.리스크에 대한 백업 플랜이 있으며 리스크 관리계획이 주기적으로 갱신된다.
합계:

평가 결과 분석

  • 20점 - 소프트웨어 개발의 기초가 아주 잘 되어 있습니다. 소프트웨어 프로젝트를 수행하는데 별 문제가 없습니다.
  • 15점 이상 - 이 정도면 기초가 매우 양호합니다. 지금까지도 프로젝트를 꽤 잘 수행하고 있었을 것입니다. 몇 가지만 보완하면 될 것 같습니다. 100m를 20초에 뛰던 사람이 17초에 뛰는 것보다 12초에 뛰던 사람이 11초에 뛰기가 더 어려운 법입니다. 수행 능력 향상을 위한 현실적인 방법을 보강할 필요가 있습니다..
  • 10점 이상 - 프로젝트 진행을 개선하기 위해 여러 시도를 했겠지만, 여전히 많은 개선 욕구를 느끼고 있을 것입니다. 현실적인 많은 부분을 개선하는데 전문가가 도움이 될 수 있습니다..
  • 10점 미만 - 만약 프로젝트에 성공했다면 기적이나 운이라고 여겨야 합니다. 지금 당장 조치를 취해야 합니다. 효율적인 개선을 위해서는 전문가의 도움이 꼭 필요합니다.

분석결과 점수가 나오신 분은 Comment나 방명록에 올려주세요.

그리고 같이 역량을 높일 수 있는 방안에 대해서 의논해 나가길 희망합니다.

 


저작자 표시
신고

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

  1. 좋은 글 잘 읽었습니다.

    어휴~ 이번에도 10점아래로 점수가 나오네요..
    여러 모로 의미있는 테스트라고 생각합니다.

    한가지 한국 소프트웨어업계에서 부족한 점이 인력구조인것 같습니다.
    대부분의 소프트웨어 개발에 정확한 역활분배가 이루어지지 않고 있습니다.

    거의 모든 개발자는 슈퍼 개발자라고만 생각하는 경향이 있습니다.
    개인적으로는 "스티브 맥코넬"이 "프로페셔널 소프트웨어 개발"이란 책에서 이야기했듯이 소프트웨어 개발 부분에서도 전문화가 이루어져야 한다고 생각합니다.

    전문적인 UI 개발자, 전문적인 업무로직 개발자, 전문적인 테스터, 전문적인 형상관리자, 전문적인 아키텍트, 전문적인 네트워크 관리자 등등..
    이런 조건들이 갖추어 진다면 대부분의 회사들이 10점에서 15점은 충분히 넘을 수 있다고 생각합니다.

    다만 아직 우리나라 소프트웨어 기업에서 이렇게 전문성 있는 인재를 채용하거나 육성하기에는 우리나라의 소프트웨어 시장규모나 기업의 여건이 녹녹하지 않은 것 같습니다.

    어서 빨리 이러한 여건이 충분히 갖추어진 환경이 제공되어 만드신 "소프트웨어 회사의 개발 역량 평가표"에 20점 만점을 받는 기업들이 많아지길 기원합니다.

    아무쪼록 오늘도 좋은 하루 보내시구요~ 늘 행복하시길 기원드립니다. ;-)

  2. 10점 근처만 되도 우리나라 여건에서 훌륭합니다.
    미국에서는 one-man company를 해도 각 기능을 구분해서 일을 합니다. 그러면서 필요한 문서도 다 만들죠. 그렇게 하는 것이 주먹구구보다 더 효율적이고 나중에 회사가 점점 커져도 일을 나줘 줄 수 있습니다. 그런데, 우리나라는 그렇게 할 수 있는 훈련이 거의 안되어 있어서 회사가 크나, 작으나 주먹구구이고 큰 회사들은 외국에서 방법론을 들여와서 기계적으로 따라하다가 더 비효율적으로 되곤하지요.
    갈길은 멉니다. - -;

  3. Blog Icon
    read

    안녕하세요~
    제가 책을 완전히 소화 하지 못해서 생기는 의문일까요?
    위에 평가 항목에 대해서 모두 지키면 곧 20점이면 정말로 프로젝트 수행 시 문제가 없나요?
    현재 20점이 나오는것은 아니지만, 위 항목들을 다 지킨다고 했을때 결과가 궁금 합니다.

  4. 안녕하세요. ^^

    소프트웨어공학을 소프트웨어 개발에 적용하는 이유는 빠른 시간안에 적은 비용으로 소프트웨어를 만들이 위함입니다. 위 항목들은 그중에서 기초적이고 중요한 지표들을 모아 놓은 것입니다.

    각 항목들은 보기에는 그리 어렵게 보이지 않을지 몰라도 하나하나 내포되어 있는 것들은 대단히 큰 것들입니다. 즉 하나하나 지키는 회사와 지키지 않는 회사의 차이는 엄청납니다.

    실제로 20점이 나오는 회사는 어떤지 말씀을 드리죠. 이 평가 항목은 소프트웨어 회사의 모든 역량을 체크하지는 않습니다. 가장 기초적인 역량 및 다른 역량들을 미루어 짐작할 수 있는 것들입니다. 글로벌 소프트웨어 회사들은 모두 20점이 나온다고 할 수 있습니다. 또, 20점이 나온다고 무조건 성공하는 것도 아닙니다. 소프트웨어를 제대로 만들 수 있는 기초적인 역량을 갖췄다는 의미입니다. 다른 회사들과의 경쟁에서 우위에 서기 위해서는 이 20가지 이외에 필요한 것이 훨씬 많습니다.

    하지만 제가 접한 거의 모든 소프트웨어 회사들은 20점 만점에 10점 미만이었고, 이정도의 기초되 되지 않고서는 글로벌 경쟁은 꿈도 꾸지 못하는 겁니다. 일단 이 평가에서 20점에 이르게 되면 기초를 갖춘 것이고, 이때부터 해야 할 것도 많습니다.

  5. Blog Icon
    chan

    와우,, 글 잙읽었습니다. 저는 계산을 하여 보니 3점이 나오는군요. ㅎㅎㅎㅎㅎㅎㅎ ㅠㅠ

  6. 안녕하세요. chan님

    변화가 필요한 상황이네요. ^^

  7. 좋은글 잘 읽었습니다.
    계산해보니 17점 나오네요.
    그런데 형상관리나 이슈관리 시스템은 꼭 하나만 써야 하나요?
    지금은 하나만 쓰고 있지만 전엔 CVS 형상관리도구나
    지라, 버그질라, 멘티스 등의 이슈관리 시스템을 CI도구로는 컨티넘이나 허드슨을 사용했으나
    지금은 SVN으로 통합되었고 자체개발한 이슈관리 시스템을,
    CI도구는 컨티넘과 허드슨을 사용하고 있습니다.
    "꼭 하나"여야만 하는 이유가 있을까요?

    사실 통합빌드(CI)를 위한 기술은 CI도구와 더불어 maven, ant등의 기술이 혼용될수 있고
    이때 소스코드 백업을 위해 Git + SVN 등 여러 도구를 혼합할 수 있는데 "꼭 하나"하는지에
    대해서 궁금해지네요. 물론 아무생각없이 백화점식 도구를 사용하면 안되지만
    목적이 명확해서 도구를 혼용한다면 하나보다 더 효율적이지 않을까 하는 생각도 해봅니다.

  8. 안녕하세요. 임병인님
    17점이면 엄청난 점수인데요. 제가 지금까지 만나본 회사중에서 최고점입니다. ^^
    특별한 이유가 없다면 하나만 쓰는 것이 정답입니다. 자세한 이유는 제가 쓴 책을 보시기 바랍니다. :)
    그리고 자체개발한 이슈관리시스템은 -1점으로 계산 해주세요. ^^ 그 이유도 책에 있습니다.
    어쨋든 대단히 좋은 개발문화를 가지고 계신 것 같습니다.

    빌드를 위해서 maven, nexus, ant등을 혼용해서 쓰는 것은 하나를 쓰는 겁니다. 각각의 목적이 다르죠. 그리고 빌드는 한 회사에서도 여러가지 방법을 사용합니다.

    Git+SVN도 목적을 달리는 하는 것이기 때문에 목적에 맞게 쓰면 됩니다.

  9. Blog Icon

    비밀댓글입니다

  10. 안녕하세요.

    제가 하는 일이 컨설팅이고 SW 개발 프로세스 컨설팅도 한분야입니다.

    관심이 있으시면 gracegyu@gmail.com으로 메일 주세요.

    감사합니다.

  11. Blog Icon
    김홍완

    안녕하세요. 전 요즘은 모바일웹을 만들고 있습니다.
    큰 규모는 아니고요.
    빌드나 소스관리, 버그관리 시스템에 대한 용어를 거의 사용하고 있지 않아서
    체크문항에 체크된 것이 6개네요.

    하지만, 왠지 10점미만에 대한 내용이 좋지 않아서 기분이 썩 좋지는 않네요.
    소규모 팀운영에는 10점 미만이라도 문제가 없을듯 한데,
    전사적 차원에서 보면 문제가 되겠다는 생각입니다.

    암튼 많은 생각을 하게 하는 질문이네요.

    언제나 좋은 글 감사히 보고 있습니다.
    수고하시고, 건강하세요 ~

  12. 안녕하세요. 김흥완님

    저같은 경우 혼자서 개발을 해도 20점 가까이 나옵니다. 실제로 1,2명이 시작하는 실리콘밸리 스타트업(벤처기업)들도 거의 20점이 나옵니다. 그렇게 해야 개발이 더 빨리 되고 잘되기 때문입니다.

    그만큼 기본적인 문화와 저변의 차이가 큽니다.

    소규모팀이라도 거의 20점이 나와야 정상적이고 효율적으로 개발이 되는 겁니다. 그럼에도 불구하고 소규모팀에서는 부족한 것이 많아도 개발이 문제없이 되는 것처럼 보이는 것은 소규모이기 때문이지 문제가 없는 것이 아닙니다. 비효율적인 부분이 차지하는 비율이 그렇게 크지 않기 때문입니다. 하지만 조직이 조금만 커지면 금방 문제가 급속하게 커집니다.

    당장이라도 필요한 것들을 하나씩 갖춰나가시기를 바랍니다.

    감사합니다.

  13. Blog Icon
    김홍완

    좋은 말씀 감사합니다. 지금 확인했네요.
    새글이 올라와서요~ ㅎㅎㅎ

    그리고, 김홍완 입니다.

    오늘도 수고하시고요~

  14. Blog Icon
    fghj1

    10년 가까이 된 작은 게임 회사에 있습니다. 2점 나오네요.
    개발 단계에 있는 게임인데 경영진이 생각하는 서비스 시기보다 이미 1년 이상은 늦어지고 있는 것 같아요. 여러가지 원인이 있겠지만 큼직하게 생각나는 것은 팀간에 분단(?)과 서로에 대한 평가에 있어서 배타적인 것. 특정 개발자에 의해 의사 결정이 좌지우지 되는 것. 노력한만큼 돌아오는 댓가가 없다는 것. 오랜 기간 회사가 운영 되다보니 초기 멤버들에 우물안 생각과 행동, 그리고 그러한 것을 타파하려는 의지가 없어보이는 경영진 등이 아닐까 생각됩니다.

    이곳에 입사한지 1년을 넘기고 있는데 올해 한해를 더 두고보고 이직을 심각히 고려해봐야 할 것 같습니다. 그렇다고 더 좋은 회사로 갈 수 있는 것도 아니고... 이직 보다는 차라리 해외로 나가는 것에 좋겠다는 생각을 더 많이 하게 됩니다. 물론, 해외로 나간다고 모든 문제가 해결되는 것은 아니겠죠. 언어, 인맥, 학연 등등 아무것도 없는 해외에서 혼자 처음부터 시작해야 하니까요. 그만큼 시간과 노력, 고통이 따르겠지만 제가 경험한(경력 7년차) 한국 게임 회사 현실이 바뀌길 기다리기 보다 해외에서 제 살길을 모색하는 것이 더 빠를 것 같다는 생각이 듭니다.

    물론, 개발자로써 제 자신에 대한 반성도 늘 하고 있답니다. 하지만, 반성하고 노력해서 더 개선 시키려 해도 회사가 혼자 어떻게 될 수 있는 개체(?)가 아니다 보니 부디쳐 싸우기 보다 편한 길을 찾아 피해가게 되는 것 같습니다. 그리고 그 결론이 해외인 것 같기도 하구요...

    제 생각이 틀리다면 '전규현'님에 따끔한 질타 부탁드립니다.

  15. 안녕하세요.

    지금 겪고 계신 상황이 우리나라의 다른 대부분의 SW회사의 상황과 크게 다르지는 않습니다. 개발자에게 좋은 회사들도 있지만 많지는 않습니다.

    특히나 게임회사는 아주 독특합니다. 게임은 SW 역량보다도 기획역량이 더 중요한 위치를 차지하기 때문이기도 하고 체계적인 개발과는 좀더 거리가 먼것이 현실입니다.

    해외로 나간다는 것은 좋은 생각이나 언어와 문화의 걸림돌이 있습니다. 영어를 아주 잘하거나 외국의 개발문화에 아주 익숙해야 합니다. 우리나라에서 7년정도 고생을 했으면 우리나라 개발문화에 익숙해서 해외에서는 적응이 어려울지도 모릅니다. 해외라도 게임회사라면 좀더 적응하기 쉬울 수도 있겠습니다.

    우선 게임업계에 계속 있을지를 결정하셔야 하고 다음에 국내에 계속 있을지도 결정하셔야 겠네요. 결정은 본인의 몫이니 잘 결정하기 바랍니다.

  16. 19점이 나오네요. 2번의 경우는 모든 개발문서가 정말로 소스코드관리시스템에 저장되어야 하는지는 좀 의문스럽습니다. 개발문서나 시나리오, 와이어프레임 기타 등등은 Jira라든가 Wiki, 혹은 팀 내 공유폴더 등의 형태로 관리될 수 있다고 생각합니다.

  17. 우울한딱따구리님 안녕하세요.

    2번 빼고 19점인가요? 대단하십니다. ^^ 돈없는 회사는 다 잘해서 20점 나오기 어려운데 여건이 좋으신가 보네요.

    2번에 대해서 설명하면 다음과 같습니다.
    개발문서에는 여러가지가 있고 Baseline에 들어가는 문서가 있고 Baseline에 들어가지 않는 문서가 있습니다.
    여러 문서중에서 Baseline에 들어가는 문서는 많지 않습니다. Baseline에 들어가는 문서는 소스코드와 한쌍으로서 같이 업데이트가 되어야 하는 문서들입니다.
    스펙(SRS), 설계서 등이 그 예입니다. 제가 쓴 책에 자세히 설명이 되어 있습니다.
    나머지 문서들은 해당 문서를 만들기 위한 Temporary 문서이거나 다른 용도로 사용하는 문서들입니다.
    예를들어 기획서, 개발계획서, 테스트 계획서 등은 Baseline에 들어가지 않습니다.

    Baseline에 들어가는 문서는 소스코드관리시스템에 들어가서 소스코드와 같이 Baseline을 생성해야 합니다. 그래야 해당 Baseline의 프로그램, 소스코드, 문서가 다 짝을 이루고 그래야 제대로된 형상관리가 됩니다.

  18. Blog Icon
    Creed

    소규모일본회사에서 근무하는 1인입니다. 한국회사실정과는 다르지만 체크해본결과

    11점정도 나오네요. 기본적인 시스템은 갖추어져있고 그것을 따르지만 좀더 구체화된
    시스템이 정석화되어 있지않습니다.

    제대로 된 시스템만 도입된다면 따르는것은 시간문제인것같습니다.(일본인특성상.)

  19. Blog Icon
    다크

    소프트웨어 개발 팀의 역량을 개발자 역량에 대한 척도없이도 개량화 할 수 있다고 믿는 것이 놀랍군요!!!

  20. Blog Icon
    사나이

    미국 소프트웨어 엔지니어로 근무중입니다. 17점 나오네요

  21. Blog Icon
    Ad Scientia

    십 수년 전에 개발자로 일하던 회사의 점수를 내 보니 12 점 나왔습니다. 일정과 리스크 관리는 PM이 했을 텐데 전 그런 문서를 본 적이 없어서 점수를 먹이지 않았습니다. 의료용 제품을 만들어서 FDA 개발 권장 사항을 따르던 회사였습니다. 실리콘 밸리에 있었는데요... 지금은 M&A되어 없어졌지요... 감사합니다. 옛날 기억이 소록소록 나네요...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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