소프트웨어 개발의 기초도 되어 있지 않으면서 무리하게 Peer Review를 시도하다가 실패하기 십상입니다.
개발의 체계도 전혀 없이 코딩위주로 개발을 하고 있다면 Peer Review할 것도 별로 없거니와 Peer Review를 통해서 공유의 문제와 품질을 향상할 수 있을 것으로 착각하는데, 이는 Peer Review를 너무 만만하게 보는 것입니다. 피아노 기초도 안되어 있으면서 쇼팽을 치려는 것과 같고, 기초 체력도 부족하면서 축구의 고급 기술은 배워서 무엇 하겠습니까? 그래서 히딩크가 강조한 것이 기초체력이지요.
Peer Review를 정상적으로 진행하려면 최소한 소스코드관리시스템과 버그관리시스템은 제대로 사용하고 있어야 하며, 스펙과 설계문서를 제대로 만들어야 하며, 코딩 컨벤션을 따라서 개발을 하고 있어야 합니다. 간단하게 2줄로 설명을 했지만, 이 정도의 역량을 가지고 있는 소프트웨어 회사는 흔하지 않습니다. 즉, 대부분의 회사들이 Peer Review를 시행할 준비가 되어 있지 않고, 억지로 시행한다고 해도 그 효과를 제대로 누리기는 어렵습니다.
스펙과 설계문서를 제대로 만든다는 의미는 이미 Peer Review를 모두 포함하고 있는 것입니다. 여기서 또 많은 개발자들이 스펙과 설계문서를 제대로 만들고 있다고 착각할 수도 있겠지만, 현실은 그렇지 않습니다. 필자의 경험에 의하면 많은 회사와 개발자들이 스펙과 설계문서를 만들고 있다고 착각을 하고 있습니다. 이에 관한 얘기들은 추후에 올릴 계획입니다.
이렇게 얘기를 하면 매우 비관적인 것처럼 보이는데 비관적인 것이 사실입니다. 굳이 거짓된 희망의 메시지를 전하고 싶은 생각은 없습니다. 현실이니까요. 이렇게 된 것은 개발자들만의 탓도 아니고 회사에서 제대로 된 개발 환경 및 교육의 기회를 제공했어야 하는데, 그렇지 못했고 많은 회사들이 그냥 개별 개발자들에 의존해서 주먹구구식으로 개발해왔고 뭔가를 시도하려고 한 회사들도 그렇게 좋은 성과를 낸 회사는 별로 없습니다.
결론을 말씀드리면 그럼에도 불구하고 Peer Review를 시행하려고 노력하는 것은 의미가 있다고 할 수 있습니다. 하지만 그와 더불어서 개발의 기초를 닦기 위한 노력도 병행해야 합니다. 이미 개발을 잘하고 있는데 기초가 부족하다고 하면 기분이 나쁠 수도 있는데, 사실이기 때문에 말을 돌려서 하고 싶지는 않습니다. 코딩도 잘하고 꽤 근사한 제품도 만들어 내지만, 효과적인 개발의 체계를 갖추고 있지 못한 것을 사실입니다. 그래서 좀더 좋은 제품을 좀더 짧은 시간에 개발할 수 있는데 그렇지 못하고 개발자들은 제대로 성장할 수 있는 기회를 갖추고 있지 못한 것입니다.
앞으로 개발자로서 10년, 20년 후의 모습이 그려지지 않는다면 소프트웨어 회사로서 제대로 체계를 갖추고 있지 못한 것이 확실합니다. 제대로 소프트웨어를 개발하기 위해서 우선적으로 해야 할 것이 무엇인지 생각해야 합니다.
언제나 글 잘 읽고 있습니다. 빠른 시일 내에 효과적인 스펙 및 설계문서 제대로 만들기에 대한 내용을 볼 수 있길 바래봅니다. :)
답글삭제우울한 딱따구리님 안녕하세요. 모터쇼 다녀오셨군요. 저도 항상 블로그 잘 읽고 있습니다. 처음에 블로그를 시작할 때 스펙을 첫번째 주제로 생각을 하고 있는데, 계속 주변만 서성거리고 있습니다. 블로그를 통해서 스펙을 잘 만드는 법을 습득한다는 것은 과욕이지만 해보는데까지 시도는 해봐야죠. 똑같은을 글을 가지고 1을 얻는 사람도 100을 얻는 사람도 있으니 1명의 독자라도 도움이 된다면 좋겠습니다.
답글삭제소스 코드의 품질을 높이기 위한 방법으로 많은 개발자가 추천하는 방법 중의 하나가 동료간의 소스 코드 리뷰이다. 나 또한 소스 코드 리뷰가 시간 대비 효율 측면에서 좋은 문화이고 소스 코드 품질을 향상시킬 수 있는 좋은 방법이라고 생각한다. 하지만 내가 지난해 진행했던 소스 코드 리뷰는 큰 효과를 보지 못했다. 물론 소스 코드 리뷰에 대하여 사전에 많은 준비를 하지 않은 것이 가장 큰 실패 요인이라고 생각한다. 소스 코드 리뷰를 하기 위하여 개발자간..
답글삭제용역 의뢰를 받다보면,
답글삭제특정 플랫폼을 위한 엔진을 개발하는데 고객이 너무 '배려심'이 많아서 산출물 필요없다고 하시는 경우가 있습니다. 고객 측에서도 개발진이 있으니 완료 보고서를 알아서 쓰겠다고 하는 거죠.
문제는 설계 문서를 쓰지 않으면, '완료 보고'가 아니라 프로젝트 중간 관리 자체를 못하는 건데, 나서서 문서를 쓰겠다고 하니, 아군(?), 적군(?) 할 것 없이 쓸데 없는 짓이라고 말리더군요. 그래도 고집 피워서 겨우 기본 틀 잡아서 문서 제출하고 회의 때마다, 진도/이슈 체크 했더니 더 이상 아무 말도 없습니다.
말씀하신게 옳은 현장의 작은 기업들이나 실무 개발자들은 SRS라던가, 진행 사항 관리를 위해 어떤 서식이 있는지도 모르는 경우가 많습니다. 가장 간단한 서식 몇개를 공개할까 생각 중입니다. 제가 최근들어 고민하는 내용을 그래도 밝혀 주셔서 감사한 마음 담아 주절 거리고 갑니다.
써니님 안녕하세요.
답글삭제고객도 산출물이 필요없다는 직원도 문서는 개발에 필요없다고 생각하고 있는 것이 문제죠. 대부분 문서에 대한 아픈 기억이 있고, 문서는 개발 시간만 늘인다고 생각하는 경우가 많습니다. 제대로 문서를 써본 경험도 전혀 없으면서 엉터리 경험을 가지고 착각을 하는 겁니다. 문서가 제대로 적히지 않으면 요구사항이 제대로 분석이 되지도 않고 서로 다른 생각을 하면 수많은 재작업을 해야 하며 프로젝트의 진척을 확인할 수도 없습니다.
각 프로젝트 상황에 맞게 최소한의 문서를 만들어야 하는데, 쓸데없는 문서만 잔뜩 만들다가 아예 포기해버리는 경우가 대부분입니다.
그리고 몇가지 Template을 공개하는 것은 거의 도움이 안되거나 오히려 방해만 됩니다. Template을 채우는 것을 문서를 작성하는 것으로 착각하기 때문에 그렇게 해 놓고 문서를 작성하고 있다고 할 수 있습니다.
Template은 인터넷에 널려 있는데, 그게 없어서 문서를 작성 못하는 것은 아니고, 우선 문서 작성의 필요성을 못 느끼는 겁니다. 그리고 문서를 작성해본 경험도 거의 없으니 실력도 없는 것인데, 나름대로 문서를 작성하고 있다고 착각하기도 하고요.
문서는 작성을 해보고 리뷰하고 또 배우고, 공부하고 작성하고 리뷰하고 프로젝트 해보면서 계속 실력을 향상시켜나가야지요. 그러면서 자연스럽게 자신의 회사에 알맞는 Template를 만들어가면 좋습니다. 표준 Template을 가지고 시작할 수도 있는데, 대부분의 표준 Template가 매우 Heavy하다데 문제가 있습니다. 또 자신의 회사와 맞지 않을 수도 있고요. 항상 의견 남겨주셔서 감사합니다.
먼저 답글 감사드립니다. 템플릿이 오히려 해가 된다는 말씀에는 깊이 공감합니다.
답글삭제ISO 9001 standard 문서 작업한다고 고생하던 기억이 떠오르네요 ^^;
많은 SI 프로젝트 매니저들이 현실성 없는 양식들을 가지고,
산출물 작성만을 강요하는 상황도 큰 폐해라고 생각 합니다.
이렇게 이야기 하는 것보다 실제로 어떻게 쓰고 있는지 밝히는게 역시 낫겠네요.
역시, 템플릿 자체 보다 중요한 건, What, Why, How 3가지 행동 지침이겠죠.
서식을 만들면서 어떤 고민을 했고, 어떻게 적용했으며, 개선할 점들을 이야기하려고 합니다.
내제된 역량이 부족한 상황에서 문서만 만드는 것은 고역이죠. 그렇다고 실력이 느는 것도 절대로 아닙니다. 오히려 아픈 기억만 쌓입니다.
답글삭제다양한 경험을 블로그에서 소개하는 것은 매우 긍정적인 일인 것 같습니다. 자신의 경험들에 비춰봐서 도움이 될 수도 있고, 이견이 있으면 토론도 할 수 있겠죠. 어떤 글이 올라올지 기대하겠습니다. ^^
Peer Review를 하기 전에 기본 역량이 되어 있어야 하겠군요
답글삭제우리 회사는 소스 코드 관리시스템은 예전부터 사용해왔고
버그 관리시스템은 몇 번 시도하다가 최근에 다시 강력하게 시행을 하여
현재는 안정적으로 버그 관리 시스템에 정착한 정도의 레벨입니다.
스펙 문서와 설계 문서가 가장 취약하군요.
현재 작성하는 문서가 전혀 없는 상태입니다.
하지만 새로 개발하는 프로젝트가 아니라 유지보수 단계의 프로젝트라면
어차피 처음부터 만들어 놓은 스펙과 설계 문서는 없기 때문에
코드 리뷰만을 진행하는것도 어느 정도 의미가 있을것이라 생각합니다.
안녕하세요. 이성열님
답글삭제이제 체계적인 개발을 위한 첫발을 내디신 겁니다. 소스코드관리시스템과 버그관리시스템도 제대로 쓰려면 시간이 한참 더 걸립니다. 제 책을 보시면 조금 도움이 될 겁니다.
현재 겪고 계시는 문제의 50% 이상은 스펙 문서의 부재에서 온다고 보면 됩니다. 유지보수 단계라고 해도 스펙 문서가 없다면 계속 악순환 밖에 될 수 없습니다.
또 다음 제품부터 스펙을 작성하려고 마음을 먹었다고 해서 그렇게 될 가능성은 거의 Zero입니다.
코드 리뷰로 유지해 나가는 것은 차차차선책쯤 됩니다.
답변 감사합니다.
답글삭제우선 우리회사의 사업분야 대해 간단히 설명을 드리면
반도체 장비, LED, SolarCell 장비등의 제어 SW 개발과 머신 비전 알고리즘 ,HW 개발 등입니다.
개발자는 저를 포함 7명이고요 . (제가 사장 )
고객업체에서 개발하는 장비에 들어가는 프로그램믈 만들어야하는데..
기본적으로 1인 1프로젝트 식으로 진행합니다.
2인 1프로젝트를 하더라도 개발 단계에서 GUI, 스퀀스 제어등으로 나누어서 진행하고
개발이 끝나면 거의 1명이 맡아서 합니다.
다행히 어떤 장비를 하던지 기본 SW 라이브러리를 사용하고 GUI등을 비슷한 구조로 만들기 때문에
다른 사람이 분석하는데 큰 문제는 없습니다.
유지보수는 한사람이 다수 프로젝트를 하고 있으나 문제가 생겼을때 서로 도와 줄 수 있을 정도로
각 프로젝트 소스에 대한 이해는 하고 공유하고 있습니다.
장비가 납품되면 유지보수가 자주 일어나는것은 아니지만.. 거의 장비 폐기 전까지 가끔씩이라도 SW 유지보수가 진행되기 때문에 .. 오래된 개발자들은 거의 모든 프로젝트 소스를 디버깅 할 정도까지는 이해하고 있습니다.
일단..개발시 한 프로젝트에 다수가 참여하는 일반적인 다른 업체와는 조금 성격이 다르기는 합니다.
그리고 장비 개발하는 고객사에서 초기에 스펙을 거의 작성하지 않고 , 소프트웨어는 물론 기구 하드웨어 스펙도 정확히 없는 경도 많습니다. 당연히 소프트웨어는 어떤 기능들이 들어가야 하는지 정확한 스펙정의 과정이 전혀 없습니다.
그렇다고 우리가 다 스펙을 작성해서 고객사에 제시하기에는 개발일정이 바로 코딩 들어가도 빡빡 일정이라도 힘들고요. 고객사도 자신들이 원하는 소프트웨어가 어떤 기능이 필요한지 대충 밖에 파악을 못합니다.
결론적으로 고민은 고객쪽에서 요구사항, 스펙 작성 등이 전혀 안되고 있는 상황에서
개발 문서를 어떤식으로 작성해야 하는지 고민입니다.
안녕하세요. 이성열님
답글삭제온라인소프트웨어개발역량 분석도 답장을 보냈으니 확인해보세요. ^^
말씀하신 스펙에 관련된 내용은 전혀 특이한 상황이 아닙니다. 많은 회사들은 자신들만 이러한 상황이라고 생각하는데 그렇지 않습니다. 더 열악한 경우도 많습니다.
이렇기 때문에 스펙을 작성하는 역량이 있어야 합니다. 지금도 스펙을 그냥 문서에 적는 행위로 생각을 하시는 것 같은데 문서에 적는 것은 결과를 기록하는 것 뿐입니다. 분석역량이 있어야 한다는 뜻입니다. 대부분은 회사는 분석역량없이 자신의 상황만을 핑계로 대는 경우가 많습니다.
스펙은 계속 변하고 초기에는 잘 모르기 때문에 분석을 잘하고 상황에 맞게 잘 대처를 해야 합니다. 이는 스펙을 한번 제대로 적어보면 그때 이해를 할 수 있지 그전에는 100번 얘기를 해도 이해하기는 불가능합니다.
또 한가지 위험한 것은 개발자 각각에 전적으로 의존을 하는 것입니다. 개발이 너무 쉬워서 개발자가 교체가 되어도 누구나 다 할 수 있는 것이라면 문제가 없겠죠. (이러면 경쟁력도 없겠죠? ^^) 하지만 그렇지 않다면 개별 개발자에 의존하는 것 자체가 큰 리스크입니다. 회사에서 개발자가 가장 중요한 자산이지만 특정 개발자에 의존하는 시스템은 매우 위험합니다. 개발자가 아플 수도 있고 퇴사를 할 수도 있습니다. 개발자는 팀으로서 힘을 낼 수 있어야 합니다.
회사의 시스템과 프로세스가 80%정도를 차지하고 개발자의 Risk는 20%정도만 유지해야 합니다. 대부분의 회사는 80% 개발자에 의존하기 때문에 개발자가 1,000명이 넘는 회사나 10명이 안되는 회사나 똑같이 인적 Risk가 엄청나게 큽니다.
이렇게 하지 않으면 개발자가 성장하기도 어려워집니다. 회사와 개발자에게 모두 손해입니다.
스펙 작성의 힌트는 제 책을 참조하시기 바랍니다. 제일 좋은 방법은 미국 실리콘밸리의 SW회사에서 몇년 일해보는 것인데 그렇지 않다면 분석전문가와 같이 프로젝트를 하면서 실제로 스펙을 적어보는 겁니다.
열정을 가지고 회사를 운영해나가는 모습이 매우 보기 좋습니다. 궁금한 것이 있으면 언제든지 연락주시기 바랍니다.