태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

7명이 할 수 있는 일을 70명이 하고 있는 이유

2012.08.15 23:10 by 전규현


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





최근에 한 글로벌 소프트웨어 회사(Y사, 가칭)의 한국 지사 관계자에게 들은 이야기이다.

비단 Y사 얘기만은 아니다. 세계적인 소프트웨어 회사의 한국지사에서 종종 벌이지는 일이다.


Y사의 본사에서는 처음에 한국지사를 만들었을 때 한국에서도 미국의 개발 프로세스를 따를 것을 종용했다고 한다. 하지만 한국에서 채용된 개발자들은 미국의 개발 프로세스는 너무 무겁다고 한국 방식으로 개발했다고 주장을 했다. 그리고는 미국의 개발 주문에 대해서 믿을 수 없는 속도로 해결을 해나가기 시작했고, 미국 본사는 이런 경이로운 결과를 보고는 한국식 개발을 묵인할 수 밖에 없었다.


그뒤 몇 년이 지난 지금은 어떻게 되었을까? 미국 본사의 개발 프로세스를 착실히 따른 호주 지사와 엄청난 차이를 보이고 있다고 한다. 똑같은 일을 호주 지사에서는 7명이 처리를 하고 있고 한국 지사에서는 70명이 야근까지 해야 간신히 처리를 하고 있다고 한다. 


그렇게 된 이유가 분석/설계도 없이 빨리빨리 개발을 하다보니 아키텍처가 엉망이고 개발자들이 많이 바뀌었는데 내용을 아는 사람도 별로 없다고 한다. 뭐 하나 고치려고 해도 보통 어려운 것이 아니라고 한다.


전해 들은 얘기라서 과장이 있다고 해도 문제가 심각하고 이미 많이 망쳐 놓은 것은 사실이다.


글로벌 소프트웨어 회사라고 하더라도 한국에 와서 착각하는 것들이 있다. 놀라운 속도를 보여주는 한국식 개발방식을 신기해 하지만 그 문제점을 피부로 심각하게 알지 못한다.  스펙도 제대로 작성하지 않고 분석/설계/구현을 섞어서 빠르게 개발하는 것이 신기해 하지만 얼마나 큰 문제가 있는지 실리콘밸리 회사들도 잘 모른다. 그런 식으로 개발해 본적이 없기 때문이다.


그렇다고 글로벌 소프트웨어 회사가 본사의 개발 프로세스를 강제화 한다고 잘 적용되는 것은 아니다. 한국에서 잔뼈가 굵은 개발자들은 몸에 밴 개발 방식 때문에 적응하기가 매우 어렵다. 차라리 신입사원들을 뽑아서 교육시키면서 개발을 하는 것이 더 빠를지도 모른다.


이는 한국의 소프트웨어 회사 내부에서도 그대로 적용된다. 글로벌 소프트웨어 회사의 개발 프로세스가 아무리 좋다고 하더라도 한국의 소프트웨어 회사에는 바로 적용이 안된다. 대부분은 무리한 시도이고 실패한다.


변화를 감당할 수 있을만큼씩 조금씩 바꿔나가야 한다.


image by  ChristopherA


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

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

전규현 소프트웨어이야기 분석, 설계

개발자의 취향

2012.08.02 06:24 by 전규현


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





소프트웨어 프로젝트를 진행할 때 합리적인 결정보다는 개발자의 취향대로 진행되는 경우가 많다.


이 경우 Architecture상의 심각한 문제점을 내포하게 된다.


제대로된 분석과 설계를 통해서 Architecture가 결정되어야 하는데 개발자 취향에 맞는 개발언어를 선택하고 검증이 안된 기술을 선택하면 그 Risk는 고스란히 프로젝트가 떠안아야 한다.


Architecture를 결정할 때 고려해야 하는 요소는 개발자의 취향이 아니다. 회사의 미래 비즈니스 전략을 고려해야 하고, 현재 개발자들의 구성과 역량, 제품의 성격과 로드맵이 중요한 고려사항이다. 


이러한 전략없이 특정기술을 맹신하거나 거부하기도 하고 무조건 새로운 기술을 채용하기도 한다.

그러다보면 각 제품마다 중구난방으로 여러 기술이 쓰이고, 유지보수에 심각한 문제를 초래하기도 한다.


그럼 어떻게 하면 이런 잘못된 결정을 막을 수 있을까? 답은 의외로 간단하다. 분석을 제대로 하는 것이다. 제대로된 스펙문서에는 최종 결론 뿐만 아니라 그런 결정에 이르게 된 근거와 의논 과정도 적어야 한다. 그래야 스펙을 읽는 사람들이 의문가 이의를 제기하지 않는다.


예를 들면 다음과 같은 것들이 있다.

  • 현재는 Windows만 지원하지만 3년안에 Mac을 지원할 가능성이 90%라서 엔진은 ANSI-C로 개발을 하고 UI를 QT Framework를 이용한다.
  • Java와 C로 모두 개발이 가능하고, 프로젝트 리더가 C언어를 더 좋아하지만, 기존 제품들이  Java로 되어 있고 회사에 Java개발자가 대부분이므로 Java를 선택한다.
  • 회사에 자연어 처리 전문가가 있지만 자연어 처리 엔진의 직접 개발 비용과 상용라이브러리를 구매했을 때를 비교했다. 10년 후까지의 유지보수 비용을 고려하여 자체 개발보다는 상용라이브러리 구매를 선택했다.
  • 현재 프로젝트는 아이폰/아이패드 용으로만 계획을 세웠지만, 영업부서와 논의결과 안드로이드를 지원할 가능성이 있어서 제품의 난이도가 그렇게 높지 않아서 Adobe Air를 사용하기로 했다.
이러한 결정 과정은 프로젝트를 진행하면 수십가지 또는 수백 번 진행이 된다. 스펙문서에는 이러한 결정과정까지 적어야 정확한 내용이 된다. 또한 중간에 상황이 변경되면 신속하게 영향평가를 할 수 있고 스펙을 변경할 수 있다.

소프트웨어 프로젝트는 개발자의 취향대로 진행되는 것이고 합리적인 근거를 바탕으로한 Architecture 결정에 따라 진행되어야 한다.

Image by kevin dooley



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

전규현 프로젝트/요구사항분석 분석, 설계

한 SI회사의 프로세스에 대한 오해

2012.07.16 09:45 by 전규현


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







필자는 업계의 여러 사람과 얘기할 기회가 많다.


최근에 한 대형 SI회사의 한 PM과 얘기를 한 적이 있는데 프로세스 상의 큰 문제가 있었고, 실제 프로젝트팀에서는 잘못된 프로세스로 인해서 어려움을 겪고 있었다.


SI회사의 오랜 바람 중의 하나가 "공정분리"이다. 즉, 분석/설계/구현을 분리해서 프로젝트를 진행하는 것이다.

"공정분리"가 되지 않은 상태에서는 분석/설계/구현이 뒤엉켜서 개발을 진행한다.


"공정분리"는 분석을 잘해서 설계자에게 넘겨주면, 설계자는 설계를 잘해서 개발자에게 넘겨주고 개발자들은 설계서 그대로 코딩만 하면 되도록 하려는 것이다.


최근 해외 프로젝트가 증가하면서 분석/설계/구현을 뒤엉켜서 진행할 경우 코딩하는 개발자까지 해외 파견을 해야 한다. 그래서 공정분리는 점점 필수가 되었다.


그래서 진행한 것이 해외에서 "분석/설계"를 잘 해서 넘겨주면 국내에서는 개발자들은 그대로 "구현"만 하면 되도록 하는 프로세스를 만든 것이다.


실제로 이 프로세스는 잘 작동하지 않고 있다고 한다. 그동안 해오던 방법과 역량이 분석/설계를 해도 "구현"은 이와 상관없이 알아서 진행하고 모르면 분석가에게 물어가면서 코딩하던 수준이었다. 이런 상황에서 이 프로세스가 잘 작동할리가 만무하다.


이렇게 공정을 분리하려면 "분석/설계" vs "구현" 보다는 "분석" vs "설계/구현"이 더 낫다.


설계가 구현에 좀더 가깝고, 잘된 분석서를 가지고 충분히 "설계/구현"을 할 수 있기 때문이다.


여기서 또 오해가 있는 것이 설계를 잘해서 넘겨주면 그대로 코딩만 하면 될 줄 아는 것이다. 현실에서는 이렇게 잘 진행되지 않는다. 이렇게 하기 위해서는 설계를 너무 자세히 적어야 하고 실제 구현시 많은 문제를 발견하게 된다.


더 좋은 방법은 설계는 꼭 필요한 만큼만하고 구현에 적당한 자유도를 주는 것이다. 


이렇게 제대로 "공정분리"를 하기 위해서 대전제가 하나 있다. 


바로 "분석"역량이 뛰어나야 한다는 것이다. 뛰어난 분석가를 많이 보유하고 있어야 한다.

현재의 분석역량은 기껏해야 "기능"분석과 약간의 "비기능"을 분석하는데 그치고 있다. 분석이 무엇인지 짧은 글에 일일이 설명하기는 어렵지만 분석은 이보다 훨씬 크고 어려운 일이다. 비즈니스전략도 포함해야 하고, 설계도 일부 포함한다. 


필자의 생각으로는 이 SI회사는 당분간 프로세스의 시행착오를 좀더 겪을 것으로 생각된다. 잘못된 프로세스를 바로 잡는데 시간이 걸릴 것이고, 분석역량을 끌어 올리는 일에 시간이 좀더 걸릴 것이다.


시행착오를 겪는 시간은 짧을수록 좋다.


image by Greg McMullin 




 

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

전규현 개발프로세스 SI회사, 분석, 설계, 프로세스

  1. 요즘 써주신 글 중에서 가장 좋은 글인 것 같습니다. ^^
    보석 같은 키워드들이 많네요. - 자유도, 분석의 중요성 등
    분석이 참 중요하죠.
    초기 방향을 잘못 잡으면, 팀원이 아무리 열심히 해도 엉뚱한 방향으로 가는구나 하는 느낌이 듭니다.
    그나저나 SI는 워낙 넓은 분야를 커버하다 보니,
    깊이 있는 분석이란 참 뛰어난 분들의 영역인 것 같고요~

    고맙습니다.

  2. 제임스님 안녕하세요.

    SI회사의 분석가들은 분석역량보다는 도메인지식이 뛰어난 사람이 많습니다. 고객의 업무를 고객보다 잘 아는 경우가 많지만 업무지식을 쌓아가는 방식으로 성장하다보니 분석 역량이 떨어져서 고객의 요구사항 파악이 부족하고 스펙관리가 떨어지고 설계/개발자에게 스펙 전달이 잘 안됩니다. 결국에 분석가가 구현단계까지 도움을 많이 줘야 하는 경우가 많습니다.

    이러다보니 세계적인 방법론을 도입해서 문서만 수십가지를 만들어도 별로 나아지는 것은 없이 문서를 많이 만들려고 고생만 합니다.

    세계적인 방법론보다는 제대로된 분석 역량을 익히는 것이 더 중요합니다. 결론은 전문가에게 배우는 거죠. ^^

  3. Blog Icon
    LInE.

    설계자와 개발자의 롤이 명확한(철저히 분리된..) 프로젝트를 한 적이 있는데, 설계단계 진행시 설계자 설득하느라 바쁘고 개발단계 진행 시 개발자와 설계자 커뮤니케이션 문제 때문에 아주 골머리 썩었었습니다.-_ㅜ

    개발자들은 투입되자마자 설계문서를 파악하고 코딩에 들어가야 하는데, 작성가이드를 해 준 설계문서의 항목이 너무 많고 자세하다고 설계자들이 반발.. 하지만 아무리 생각해 봐도 그정도의 설계항목이 본문에 말씀하신 "꼭 필요한 만큼" 이라고 생각이 되어 개발자들이 코딩하려면 그정도는 설계를 해 줘야 코딩들어갈 수 있다고 설득하느라 한참 시간 보내고,

    또 막상 개발자들이 코딩 들어가니 왠걸 진짜 "설계문서에 있는 기능만" 구현을 해 놓더라구요. 예를 들면 단위테스트 진행 시 기본적인 유효성검사도 되어 있지 않아 개발자에게 말을하면 "설계문서에 없었다."... 설계자들은 어떻게 그런것 까지 문서화 하냐, 필수입력이라고 해 놓았으면 당연히 유효성체크 해놔야 하는거 아니냐고 서로 싸우고...

    본문의 내용이 너무나도 공감가서 한마디 적고 갑니다...

    좋은 글 항상 잘보고 있습니다. 항상 감사합니다. ^^

  4. 안녕하세요. LInE. 님

    항상 시행착오를 통해서 배우지만, 시행착오를 가장 적게 겪는 것이 중요한 것 같습니다. 시행착오를 겪다가 너무 오랜 시간이 지나기도 하죠. ^^

  5. Blog Icon
    manwal

    제가 고민하던 내용을 정확하게 짚어 정리해주시니 너무 공감됩니다. 이런 경험들을 기록해두는 것이 매우 중요하다는 생각이 듭니다.

  6. 감사합니다. Manwal님

  7. Blog Icon
    GF

    최근 다른 회사와 프로젝트를 진행하게 되었는데, 그 회사에서는 약 3년을 끌어온 개발건이 있었습니다. 전규현님의 글들에 늘 나오는 대로 스펙과 설계 등의 문서는 아예 없고, 개발팀장이 교체될때마다 주먹구구식으로 진행이 되어왔기에 1년을 예상하고 시작한 프로젝트가 3년이 되어도 완결이 안되고 있더군요.
    이러한 상황에서, SI회사 혹은 컨설턴트를 통해 분석/설계 부터 다시해서 새로 시작하는 것이 나을지요?
    내부에 개발자를 채용해서 진행을 하는 것은 많이 지친듯 보입니다. 사람도 요새는 더 뽑기도 어렵구요...

  8. 안녕하세요. GF님

    이미 망쳐 놓은 경우가 가장 어려운 경우입니다.
    제가 SI회사도 컨설팅을 하고 교육을 하기 때문에 꽤 아는데 SI회사도 분석/설계 역량이 별로 없습니다.

    일단 이대로 진행해서 어떻게든 마무리 하는 방법과 다시 분석/설계를 진행하는 방법을 비교해 봐야 하는데 현재 진행상황이 어느 정도 인지 파악을 먼저 해야 합니다.

    분석/설계를 다시 진행하려면 직접 하시던지, 저희회사에 의뢰를 하는 것이 좋을 것 같습니다. 직접 하시면 시행착오를 겪을 수는 있지만 그래도 내용을 잘 아실 것이기 때문에 가능할 수도 있습니다.

    혹시 진행하시다가 궁금한 점이 있으면 메일로 문의해주세요. 진짜 답답하시면 제 사무실로 한번 찾아오시면 자세히 설명 드리겠습니다. ^^

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

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

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

UML전문가가 설계전문가?

2009.04.15 23:28 by 전규현


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




종종 "소프트웨어 설계를 잘 하려면 UML을 잘 알아야 합니까?"라는 질문을 받습니다. 

사실 넘치는 기법들이 개발자들을 더 혼란스럽게 하는 것에 종종 화가 날 때가 있습니다.
기법은 기법일 뿐입니다. 내용은 아니죠.

UML은 잘 정리된 모델링, 설계 기법이며 툴이고 많은 장점을 가지고 있다고 생각합니다.
그럼에도 불구하고 소프트웨어 설계라고 하고 UML을 떠올리는 것을 보면 UML이 본의 아니게 나쁜 일도 했다는 생각이 듭니다. 

잘 된 설계는 형식에 구애 받지 않고, 소프트웨어를 구현하기 충분하게 소프트웨어 구조를 잘 설명한 것입니다. UML이 그 중의 하나가 될 수도 있고, 전통적인 Flowchart, DFD, 수도코드나 글로 설명할 수도 있습니다. 설계는 어떠한 다이어그램을 그리고 어떤 툴을 쓰냐에 따라서 잘 되었는지 결정되는 것이 아니고 어떤 식으로 접근해서 설계를 하였고, 리뷰 하였는지가 더 중요하고, 이를 보고 구현을 담당한 개발자(본인일지라도) 충분히 구현할 수 있는 적당한 정도가 좋습니다. 그리고 미래의 비즈니스 비전에 대응할 수 있는 구조여야 합니다.

따라서 나는 설계를 시작할 때 종이와 연필 또는 화이트보드를 가지고 시작합니다. 개발자들이 토론을 하면 깔끔하게 컴포넌트를 나누는 것으로 설계를 시작합니다. 
설계 초기부터 툴을 이용해서 정리를 시작하면 감이 잘 안 오고 잦은 수정 때문에 귀찮을 수가 있습니다.

UML을 아는 것은 좋습니다. 남들이 UML로 작성해 놓은 것을 읽을 수는 있어야 하니까요.

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

전규현 프로젝트/설계 dfd, Flowchart, UML, 기법, 다이어그램, 리뷰, 설계

  1. 좋은 말씀이십니다.
    저도 설계를 최초 시작할때는 역시 볼펜과 종이를 가지고 시작합니다.

    물론 사전 요구사항 분석은 기본이지요. 그리고 나서 전체적인 시스템 구조를 어떻게 가져가야 할까를 종이로 열심히 그림으로 그리죠^^! 툴을 잘 다룬다면 좋겠지만, 꼭 잘 다뤄야만 전문가인건 아니죠^^!

  2. 돌이아버님 안녕하세요. ^^
    연필이 좋으면 글을 더 잘 쓸 수 있다는 것과 비슷합니다. 물론 좋은 연필을 사용하면 전혀 나쁠 것은 없지만, 글을 잘 쓰기위해서는 좋은 연필을 사기보다는 책을 많이 읽고 글쓰는 법도 배우고 글도 많이 써봐야죠.

  3. Blog Icon
    작은악마

    당연한 글인데 읽는 순간 많은 생각이 드네요.

    옛날 UML을 보고 감탄하고 그에 따라 볼려고 애쓰다보니.. 가장 핵심적인 면을 놓친것이 많았다 싶습니다.
    사실 적용한다고 해놓고 막상 한건 -_- 문서만 UML 형식으로 만들곤 했지만 말입니다..

  4. 작은악마님 안녕하세요. 축구 좋아하는 어린이가 멋진 축구화 보고 황홀해하고 축구화 살려고 축구는 안하고 맨날 아르바이트 하는 격이죠. 축구화 신경안쓰고 맨날 연습했으면 훨씬 잘할 것을...

  5. 다들 일정관리 어떻게 하고 있나 몇몇 회사분들게 물어보니
    "이것저것 다써봤지만 결국 비지오와 액셀 그리고 달력으로 돌아왔어 ㅎㅎㅎ"
    이렇게 결론이 나더군요.

    "툴이나 기법이 중요한게 아니고 사람이 중요하구나"
    라는걸 다시 느낀것 같습니다.

  6. 안녕하세요. 당근천국님

    저도 왠만한 프로젝트 일정관리 아직도 엑셀로 합니다. ^^ 그게 더 나아요.

이 정도도 안되면서 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회사에서 몇년 일해보는 것인데 그렇지 않다면 분석전문가와 같이 프로젝트를 하면서 실제로 스펙을 적어보는 겁니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바