태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

개발자에게 필요한 중요한 습관, “중복 없애기”

2015.02.03 19:54 by 전규현


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





대기업이나 중견 기업들은 소프트웨어 개발 문제를 해결하기 위해서 복잡한 프로세스를 도입하곤 한다. 이 때 “중복”의 함정에 쉽게 빠진다. 문서를 비롯해서 소스코드까지 동일하거나 비슷한 내용이 여기저기 중복해서 작성되게 된다. 처음에는 이런 중복이 별 문제 없어 보이지만 시간이 흐를수록 생산성은 기하급수적으로 떨어지게 된다.


비효율적임에도 중복이 필요한 곳은 원자력 발전소나 우주선을 개발할 때다. 나사 하나만 바뀌어도 여러 문서를 확인하고 문제가 없는지 완벽하게 교체해야 하기 때문이다.  하지만 대부분의 소프트웨어는 적은 비용으로 빨리 개발하는 것이 목적이다.


그러기 위해서 소프트웨어 개발자가 가져야 할 중요한 습관 중 하나는 “중복 없애기”다. 이는 개발자뿐만 아니라 다른 직종에서도 필요하지만 소프트웨어 개발에서는 더욱 더 필요하다. 무분별한 중복이 가져오는 비효율성은 업무 생산성을 2배, 3배, 심지어는 10배이상 떨어뜨린다. 10배가 과장은 아니다.


필자는 과거 글로벌 기업의 호주 지사는 7명이 할 수 있는 일을 한국지사에서는 70명이 야근을 하면 힘겹게 일을 하는 사례를 소개한 적이 있다. 초기에는 한국지사가 세계에서 가장 빠른 개발 속도를 보였지만, 몇 년 만에 속도가 10배로 느려진 사례였다. 그 이유에는 여러 가지가 있지만 “중복의 지옥”도 중요한 이유 중 하나다.


“중복 없애기”는 소프트웨어 개발의 생산성을 높이는 매우 중요한 습관이며 그냥 개발자 각자의 습관에 맡겨 놓을 수는 없는 중요한 활동이다. 회사 차원으로 관심과 의지를 가지고 정착을 해나가야 하는 중요한 문화다.


그럼 소프트웨어를 개발할 때 어떠한 중복이 있는지 알아보자.


첫째, 소스코드 내의 중복이다.


적게는 한 단어, 한 줄부터 또는 몇 줄을 복사해서 반복적으로 사용하거나 많게는 함수 하나를 통째로 복사해서 조금 고쳐서 쓰는 경우다. 누구나 그렇게 하면 안된다고 알고 있지만 가장 흔히 벌어지는 현상이다.


비슷비슷한 내용을 개발할 때는 비슷한 코드들이 반복되는데 이를 추상화해서 별도의 모듈로 만들면 좋지만 시간과 노력이 들어간다. 당장 시간에 쫓기는 개발자들은 가장 빠른 방법인 Copy & Paste를 선택하곤 한다. Copy & Paste의 남발은 지옥문으로 스스로 걸어 들어가는 꼴이다. 당장은 개발이 빠르지만 시간이 흐를수록 기하급수적으로 생산성이 떨어진다.


소스코드에 의미를 알기 힘든 숫자들이 가득한 경우도 마찬가지다. 그 숫자의 의미는 개발자가 코딩할 당시는 정확하게 알고 있었어도 시간이 흐르면 본인도 남도 의미를 모르게 되는 경우가 많다. 게다가 해당 값을 일괄 변경해야 할 경우에는 불가능해지기 도 한다. 소스코드에는 숫자가 0 또는 1을 제외하고는 보여서는 안된다. 알아보기 쉬운 이름으로 정의를 해서 사용해야 한다.


소스코드 중복을 최소화하는 좋은 방법은 코드 리뷰다. 이미 호떡집에 불 난 것 같은 상황에서 매일 바쁘게 개발을 하고 있다면 무슨 방법도 소용이 없지만 코드 리뷰를 통해서 코드의 중복을 찾아내고 바로 고치는 것이 좋다. 물론 리뷰 전 코딩 시에 개발자 모두가 중복의 폐해를 명심하고 중복을 없애기 위해서 노력하는 것이 가장 좋은 방법이다.


둘째, 소스코드 파일의 중복이다.


과거 하루가 멀다하고 피쳐폰이 쏟어져 나올 때 피쳐폰을 가장 빠르게 개발하는 방법은 가장 비슷한 피쳐폰의 소스코드를 통째로 가져다가 조금 고쳐서 개발하는 것이었다. 그런 전략으로 피쳐폰 하나의 모델을 3개월만에 만들어내는 기적을 행하였었다. 물론 복사된 소스코드가 넘쳐나면 버그가 하나 발견되면 수십, 수백개의 모델에서 동시에 고쳐야 하지만 해당 모델을 빨리 단종시켜버리는 전략으로 대응이 가능했다. 고객의 불만은 친절한 서비스로 보답하면 된다.


그렇게 해서 비즈니스는 성공했을지 몰라도 개발문화에는 엄청난 폐해를 가져왔다. 그런 식으로 개발하는 것이 몸에 익어서 한번 익숙해진 습관은 쉽게 바꾸기 어려워지게 되었다.


나중에 스마트폰을 개발하는 과정에서도 그러한 습관은 불쑥 불쑥 튀어나오게 되었다. 이러한 습관이 팽배한 상황에서는 전사적으로 같이 사용할 공통 프레임워크를 만드는 일은 쉬운 일이 아니다. 


CTO나 Chief Architect가 이끄는 그룹에서 회사의 현재의 기술적인 요구뿐만 아니라 미래의 비즈니스 전략을 고려하려 향후 몇 년을 사용할 수 있는 공통 프레임워크를 설계하고 만들고 유지시켜 나가야 한다. 이런 와중에도 성질 급한 영업 위주의 경영자들의 수많은 방해와 도전을 막아 낸다는 것도 쉽지 않다. 전사적으로 몸에 베어버린 습관은 버리기 어렵기 때문이다.


셋째, 개발의 중복이다.


다른 팀에서 서로 비슷한 것들 개발하는 것이다. 두 번째와 비슷하지만 이번에는 각 팀에서 서로 모르고 개발을 하는 것이다. 그러다 보면 비슷한 것들을 여러 팀에서 개발하게 된다. 이는 회사차원에서 대단히 낭비 일뿐만 아니라 부서간에 개발 정보나 노하우가 공유되지 않는다는 증거이다. 


고급개발자가 될수록 자신의 팀의 개발뿐만 아니라 다른 팀의 개발 프로젝트도 두루 두루 관여를 해야 한다. 설계 리뷰에도 참여를 하고 코드리뷰에도 참여를 해야 한다. 이러한 문화는 중복을 줄여줄 뿐만 아니라 개발자의 개발 역량을 향상하는데도 도움이 된다.


넷째, 문서의 중복이다.


흔히 하는 착각 중에 개발 문서를 정말 많이 꼼꼼하게 적으면 개발이 잘 될 것으로 생각하는 것이 있다. 개발문서가 아예 없는 것도 문제지만 문서가 정말 많은 것은 더 문제가 된다. 


웬만한 규모의 소프트웨어를 개발할 때 문서는 SRS(Software Requirements Specification)를 포함해서 한두 개면 된다. 이것도 딱 필요한 만큼 가능하면 적게 적어야 한다. 그런데 프로세스를 강화한 회사들은 개발문서만 수십 개를 적는 경우가 있다. 이러면 필수적으로 같은 내용이 여러 문서에 적히게 된다. 처음 작성할 때는 복사를 해서 작성을 하면 되지만 프로젝트의 내용은 계속 바뀌게 되어 있다. 그런데 이렇게 여러 문서에 많이 적어 놓게 되면 나중에 고칠 때 어렵거나 불가능하게 된다. 결국 쓰레기만 쌓이게 된다.


이런 문서들에는 서로 다른 내용이 남아 있게 되고 나중에는 어느 것이 맞는 내용인지 알 수 없게 된다. 이런 경험을 가진 개발자들은 개발 프로세스, 방법론 다 필요 없다고 생각하게 된다. 나쁜 경험이 가져오는 폐해다. 


제일 나쁜 것은 미련한데 부지런 한 것이다. 부지런하게 잔뜩 중복 소스코드, 문서를 만들어 놓은 상황이라면 어찌할 도리가 없다. 처음부터 중복을 없애는 노력을 문화적으로 프로세스적으로 실천해야 한다. 어려운 것은 가장 알맞은 정도의 수준으로 정하는 것이다. 교과서에서 필요한 만큼이 이만큼이라고 설명할 수는 없다. 경험을 통해서 배워야 한다.



이글은 ZDNet Korea에 기고한 칼럼입니다.



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

전규현 개발프로세스

  1. Blog Icon
    김성엽

    좋은 내용 잘 읽었습니다.

  2. Blog Icon

    비밀댓글입니다

주먹구구식 개발이 통하는 이유

2012.08.27 06:46 by 전규현


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





우리나라의 많은 소프트웨어 회사들은 주먹구구식 개발에 대한 환상이 있다.

특히, 첫번째 시스템을 주먹구구식으로 개발을 해서 성공했는데 지금은 좀더 체계를 갖췄는데 더 개발이 잘 안된다면 과거 진짜 주먹구구식으로 개발할 때를 그리워하고 그 때로 돌아가고 싶어 한다.


여기 이와 관련된 과거 글이 있다. 

2012/07/26 - [소프트웨어이야기] - 옛날에는 개발을 더 잘했는데


주먹구구식으로 개발을 하다가 현재 체계를 갖추려고 노력하고 있다면 아직은 불완전할 뿐더러 반쯤은 주먹구구인 것이다. 그럼 주먹구구식 개발은 어떤 것인지 정의를 내려보자. 크게 5가지로 설명할 수 있다.


첫째, 스펙/설계 없이 개발을 하는 것이다. 또는 기능명세서, 시방서 등의 문서에 기능만 정리하여 개발하는 것이다. 이 방법은 프로젝트 전체 범위를 알 수 없을 뿐더러 좋은 아키텍처를 만들 수도 없고, 개발자들이 효과적으로 일을 나눠서 개발할 수도 없으며 프로젝트 진척상황을 거의 파악할 수 없다. 일정 지연은 일상이고 그야말로 끝나봐야 아는 것이다.


둘째, SVN, Git 등의 소스코드관리시스템과 Jira, Mantis, Redmine 등의 이슈관리시스템 없이 개발하는 것이다. 둘중 하나라도 사용하지 않으면 심각한 문제이다. 일단 쓰기만 하더라도 다행이지만 제대로 쓰는 것은 정말 어렵다. 대부분은 10% 정도의 기능밖에 사용하지 못하지만, 100% 기능을 활용해야 한다.


셋째, 혼자 북치고 장구치고 다하는 것이다. 일을 전문적으로 나눠서 하는 것이 아니고, 혼자서 기획, 분석, 설계, 코딩, 테스트, 빌드 등등 다 하는 것이고 이런 개발자가 여럿이고 서로 중복되서 일을 하기도 한다. 첫째에서도 언급했듯이 스펙이 제대로 작성되어야 일을 효과적으로 나눌 수 있는데 스펙이 없거나 부실하면 이런 현상이 벌어진다. 또, 회사의 조직이 소프트웨어 개발에 알맞게 효과적으로 구성되어 있지 않아도 이런 일이 벌어진다. 소프트웨어는 전문가들이 협업하여 개발하는 것이다.


넷째, 프로세스 없이 대충 개발하는 것이다. 흔히들 프로세스는 개발을 더 느리게 만든다고 주장하곤 한다. 그러면서 회사에서 프로세스를 만들려고 하면 반대 주장을 펼친다. 과거에 개발하던 방법을 서로 암묵적으로 알고 있다가 대충 개발을 하고 서로 이심전심으로 문제를 해결해 나간다.


다섯째, 리뷰, 공유 없이 개발하는 것이다. 가끔은 대충 기능목록 작성해서 마케팅이나 영업, 경영진과 리뷰를 하기도 하지만 제대로 된 리뷰는 아니다. 개발자를 제외하고는 지금 어떤 제품을 만드는지 정확하게 파악이 안된다. 심지어는 개발자들도 잘 모른다. 다 만들어봐야 어떤 제품을 만들었는지 알게 된다. 그러니 만들기 전에는 무슨 문제가 발생할지 몰라서 만드는 도중에 수많은 문제가 발생하고 재작업은 수시로 이루어 진다. 심지어는 80%쯤 만들었다가 아키텍처가 잘못된 것을 발견하고 다 버리고 다시 만들기도 한다.


정도의 차이는 있을 수 있다. 다섯가지 중에서 하나 이상이면 아직 주먹구구식 개발에서 완전히 벗어난 것이 아니다. 스스로도 주먹구구식으로 개발을 하고 있는지 평가를 해보자.


2008/10/29 - [소프트웨어이야기] - 소프트웨어 회사의 개발 역량 평가표


그럼에도 불구하고 주먹구구식 개발이 여전히 통하는 이유는 무엇일까?


첫째, Software의 크기가 아주 작다.

빌딩은 제대로 된 분석/설계 없이, 프로세스 없이 만드는 것은 불가능하다.

하지만 개집은 그런 것 필요 없다. 대충 만들어도 문제 없이 만들 수 있다. 한 사람이 머리 속으로 모든 것을 설계해서 만들 수 있는 정도의 규모라면 주먹구구식 방법도 훌륭한 방법이다.


둘째, 이직률이 극도로 낮다.

한번 개발을 해 놓으면 개발자들이 절대로 퇴사를 하지 않고 끝까지 책임져준다. 


셋째, 회사 규모가 작다.

개발자도 몇 명 안되서 서로 너무 잘 알고 모든 이슈가 더 구두로도 공유가 되고 급한 이슈는 자리에서 바로 일어나서 공유가 되고 논의할 수 있다. 가족적인 분위기에서 주먹구구식 방법이 훌륭하게 작동한다.


넷째, 소프트웨어 업그레이드가 없다.

한번 개발해 놓은 시스템이 업그레이드가 필요 없는 경우이다. 어떻게 든 첫번째 개발을 해 놓으면 문제가 없다.


그럼, 주먹구구식 개발이 앞으로도 계속 통할까?


회사가 잘되면 회사는 커지게 되어 있다. 개발자 수는 많이 늘게 되고 더 이상 자리에서 일어나 뒤로 돌아도 모든 개발자의 얼굴을 볼 수 없게 된다. 과거처럼 공유가 그렇게 잘 되지 않는다.


개발자들이 영원히 이직하지 않고 직원으로 있기를 바란다면 너무 큰 욕심이다. 개발자들은 언젠가는 이직을 하게 마련이고, 개발자들이 이직을 해도 개발은 잘 돌아가도록 되어 있어야 한다. 주먹구구식으로 계속 개발을 하게 된다면 아무리 가족적인 분위기라고 하더라도 직원이 Risk 요인이 된다.


Software 회사의 경영자라면 지금 대충 잘 굴러가는 것 같다고 해서 방심하면 안된다. 회사가 잘 되면 회사는 커지고 직원도 늘고 더 복잡해질 것이다. 문제를 모르고 방심하다가 문제가 터지고 나면 터진 댐을 막으려고 하는 것처럼 어렵다. 항상 미리 준비를 해야 하는 것이다.


물론, 처음부터 제대로 하는 것이 가장 빨리 개발하는 방법이고 좋지만 그것을 깨닫기는 매우 어렵다. 대부분은 문제가 터진 후에 우왕좌왕 한다. 주먹구구식 개발이 지금은 통할지도 모른다. 하지만 곧 주먹구구식 개발이 문제가 되는 상황이 올 것이고 이미 문제가 되고 있다면 너무 늦지 않았기만 바랄 뿐이다. 늦었다고 생각할 때가 가장 빠른 때이다.


image by Tolka Rover


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

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

전규현 개발프로세스 공유, 리뷰, 주먹구구, 프로세스

  1. Blog Icon
    RF

    소프트웨어 개발에 관심이 많은 대학생으로써 재밌게 잘 보고 갑니다.
    저런 능력을 키우고 싶은데 ... 더 공부해야겠습니다.

  2. RF님 안녕하세요.

    어치피 학교에서는 기본적인 프로그래밍과 전산 원리 등을 배우죠. 나머지는 대부분은 실제 일하면서 현실에서 배우는 겁니다. 좋은 환경을 가지 회사를 선택하는 것이 매우 중요한 요소라고 생각합니다.

  3. Blog Icon

    비밀댓글입니다

  4. 안녕하세요. 아주 작은 회사를 제외하고는 제대로 된 회사를 찾기는 어렵고 회사마다 다 다릅니다. 콕 찝어서 얘기하기는 어렵습니다.

Template과 Sample의 함정

2012.07.19 10:22 by 전규현


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






소프트웨어 개발 프로세스나 방법론에 관심을 가지게 되면 Template과 Sample에 눈이 가게 된다.


소프트웨어를 체계적으로 개발해 보겠다는 생각을 하면 가장 먼저 "문서"를 만들어야 겠다는 생각을 하게 된다.

그러면서 자연스럽게 선진 Software 회사에서는 어떻게 문서를 만드는지 관심을 가지게 된다.


그래서 인터넷에서 이런 저런 Template을 찾아서 시도를 해보지만 대부분은 만족스러운 성과를 내지 못한다.


가끔은 세계적인 방법론에서 제시하는 수십가지 복잡한 Template를 가져다가 내용채우기를 시도하다 오히려 더 비효율적으로 변하기도 한다.


우리는 흔히 남이 잘 작성해 놓은 Sample이나 Template를 몇개 보면 그대로 따라할 수 있을 것으로 생각하는 경향이 있다. 


이 방법은 코딩에서는 꽤 효과가 있었다. 하지만 문서작성은 코드 작성보다는 복잡한 이슈들이 있다. 문서에는 문장하나하나가 글자 그대로 써있는 것보다 많은 과정과 노력을 들여서 탄생한 것이다. 따라서 결과물만 보고 그 정도 수준의 문서를 만들어 낼 수는 없다.


Template과 Sample을 보고 따라하는 것이 이를 보지 않은 것보다 못한 경우가 많다. 예를 따라하다보면 전체를 보지 못하고 흉내내는 것에 불과하게 된다.


따라서, Template과 Sample을 오히려 보지 않는 것이 좋고 보더라도 따라할 생각보다는 그 구성은 어떻게 되는지 분석하고 자신의 회사에 맞게 고민을 해보는 것이 좋다.


Template보다는 내용을 적는 방법과 리뷰하는 방법을 익히는 것이 더 중요하다. 제대로 배운다고 하더라도 Template의 진의를 파악하고 제대로 문서를 작성하는데는 꽤 오랜 시간이 필요하다.


Template과 Sample의 함정에 빠지지 말고 핵심이 무엇인지 파악하자.


Image by courgettelawn

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

전규현 개발프로세스

한 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회사도 분석/설계 역량이 별로 없습니다.

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

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

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

문서는 얼마나 적어야 할지?

2011.10.27 17:26 by 전규현


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





소프트웨어 개발 프로젝트에서 문서는 적게 적어야 한다.

다시 말하면 "보통의 회사에서는 문서는 필요한만큼만 가장 적게 적어야 한다."

물론 문서를 많이 적으면 여러 각도에서 상세히 적기 때문에 중복은 많이 발생하지만 잘못된 가능성을 충분히 줄여준다.

예를 들어서 스펙문서를 제대로 하나를 효과적으로 적으면 95%를 커버하는데 이를 99.9%까지 커버하도록 적으려면 10배의 비용을 더들여서 수십개의 문서를 만들어야 한다.

절대 문제가 생기면 안되는 원자력 발전소, 우주선, 생명유지장치는 이렇게 할 수도 있다. 실제로는 이런 경우도 다 그렇게 하는 것은 아니다.

문서를 아무리 많이 적어도 완벽을 기해야 하는 경우는 여러 문서를 적어야 하지만 보통의 SW 개발 프로젝트에서 이러한 경우는 거의 없다. 대부분의 SW 개발 프로젝트는 가장 적은 비용으로 가장 빨리 끝내야 한다. 그러기 위해서는 문서를 가장 적게 또한 효과적으로 적어야 한다.

아래에 문서를 만드는 4가지 경우가 있다.
  1. 문서 거의 없이 개발하는 경우 (쓸모 없는 문서, 개발중에 안보는 문서, 나중에 문서를 만드는 경우도 여기 해당) 
  2. 스펙문서를 포함해서 한두개의 문서를 효과적으로 적는 경우 
  3. 각 단계에서 수십개의 문서를 철저히 만드는 경우 (거대 방법론)
  4. 거대 방법론을 흉내 내지만 문서는 거의 안보는 경우. 문서따로 개발따로 (우리 주변에서 흔히 보는 경우)
  5. 최종 결과물만 거대 방법론 흉내내는 경우. 나중에 제출용으로 문서를 만든다. (이것도 친근하다)
이중에서 당연히 권하는 것은 1번이고 다음은 2번이다.
3,4,5번 보다는 차라리 2번이 낫다.

문서를 많이 적는 것은 중복이 많아지고 결국에 서로 Conflict가 나고 업데이트도 안되며 정작 개발시 거의 쓸모없어진다. 하지만 문서를 가장 효과적으로 적게 적는 것은 수십개의 문서를 적는 것보다 훨씬 더 어렵다.

일단 많이 적어보고 줄여나가는 것보다는 문서를 거의 적지 않는 경우라면 꼭 필요한 것부터 조금씩 늘려가는 것이 좋을 것이다.

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

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

전규현 개발프로세스

  1. 넘침은 부족함만 하지 못하다고 했는데
    사람의 욕심과 보여주기 그리고 비교로 인해서
    이런 작업을 하지 않으면 일을 하지 않는것 같아 보인다는 생각을 고쳐야 할텐데 그게 가장 어려운것 같아요

  2. 안녕하세요. 구차니님

    열심히 코딩하고 있으면 일한다고 생각하고, 아키텍처 고민하고 있으면 논다고 생각하는 경향도 있더군요.

    소프트웨어엔지니어가 경력이 늘어 갈수록 코딩 등의 일은 줄어들고 생각하는 시간이 늘어야 하는데 말이죠.

획일화된 프로세스의 함정

2011.04.03 11:11 by 전규현


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






SW를 개발하는데 있어서 체계화된 프로세스가 필요하다는 것은 당연하다.

대부분의 SW회사가 최소한의 프로세스도 없이 주먹구구식으로 SW를 개발한다. 작은 회사들은 문제가 안되는 것처럼 보이지만 회사가 조금만 커져도 여기저기서 문제가 발생하다.

이런 문제에 시달리다보면 프로세스와 문서화가 이 문제를 해결해 줄것이라고 너무 믿게 된다.
그래서 엄격한 프로세스를 만들고 각 프로세스마다 문서를 꼭 만들게 하고 검사를 하기도 한다. 물론 프로젝트의 종류에 따라서 만드는 필수문서를 다르게 하기도 하지만, 이러한 규정은 개발자들이 요리조리 프로세스를 피해가는데 활용이 되곤 한다.

프로젝트에서 꼭 필요한 문서를 획일적으로 정하는 것은 매우 어렵다. 프로젝트 팀에서 결정하고 이를 존중하는 것이 좋다. 하지만 아직 개발팀의 역량이 부족하고 문화가 부족하다면 개발팀의 결정을 따르기도 어렵다.

가장 좋은 방법은 회사가 작을 때부터 체계적으로 개발하는 방법을 익히고 스펙과 설계를 적절하게 작성해가면서 개발문화를 키워나가고 개발자들의 역량이 같이 커져가는 것이다. 그렇게 되면 회사가 커져도 좀더 복잡한 프로세를 자율적으로 운영할 수 있게 된다.

하지만 대부분이 회사는 이러한 기회를 놓치게 된다.

그래서 택하는 것이 획일화된 프로세스이다. 이 고통스러운 프로세스를 거쳐서 이겨내면 점점 자율적인 프로세스로 바뀌게 되지만 이를 극복하지 못하면 점점 더 복잡하고 엄격한 프로세스를 만들게 된다.

가장 좋은 방법은 회사가 성장함에 따라서 문제가 생기기 이전에 미리 체계를 갖추고 개발자들의 역량을 키우는 것이고, 이미 문제가 발생했다면 최소한의 프로세스만을 만들고 지금이라고 개발자들이 분석, 설계 역량을 키울 수 있도록 회사에서 지원하는 것이다.

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

전규현 개발프로세스 프로세스

  1. 문서 없이도 대부분의 프로젝트들이 별 문제없이 잘 진행되고 있는 상황이기 때문에 개발자들이 필요성을 못느끼고 있는것 같습니다.
    개발자들이 무엇인가를 하게 하려면.. 그것이 필요한 이유에 대한 공감대를 먼저 공유하는것이 중요하다고 봅니다.
    문서화의 필요성을 느끼게 해 줄 수 있는 방법이 있다면.. 문서 작성을 거부감 없이 회사에 전체에 적용 할 수 있겠지요.

    회사가 조금만 커져도 문제가 된다고 하셨는데.. 개발자가 몇 명 정도 되었을때 이런 문서와 프로세스의 부재로 인한 문제가 생긴다고 보시는지요?
    사실 회사를 경영하는 사람 입장에서는 문제가 생기기 직전의 규모까지는 문서와 프로세스를 진행하지 않다가 문제가 생길 만한 규모가 될 정도부터 관심을 가지는것이 가장 합리적인 선택이라고 봅니다.

  2. 이성열

    문화적으로 정착되기 전에는 스스로 필요성을 느끼기 힘듭니다. 문화적으로 정착이 되면 왜 필요한지 생각하지 않고 그냥 당연히 하게 됩니다. 그래서 문화죠.

    그래서 대부분 문제가 크게 터진 다음에 필요성을 느끼게 됩니다. 작은 규모의 회사에서 가장 먼저 터지는 경우는 "개발자의 퇴사"입니다. 그리고 "회사의 성장"입니다.
    둘다 "공유의 문화", "협업의 문화"가 부족해서 문제가 됩니다. 그 방법이 "문서"와 "프로세스"입니다.

    물론 혼자 개발을 해도 이를 지키는 것이 더 빨리 개발할 수 있는 방법이지만 스스로 느끼기는 어렵습니다.

    보통 첫번째 "공유"의 문제는 개발자 10명 쯤에 생깁니다.
    그리고 "관리"의 문제라고 생각하는 이슈들이 25~30명 쯤에서 생깁니다. 하지만 이 또한 "공유", "협업" 부재의 문제에서 생겨납니다. 대부분의 개발 조직은 관리보다는 "투명한 개발"에서 저절로 관리가 되도록 되어 있기 때문입니다.

    관리의 이슈가 되는 것은 100명, 400명 쯤 겪는 이슈입니다. 작은 조직일 때부터 "문화"를 잘 갖춰나간다면 이정도로 커져도 큰 문제가 없습니다. 하지만 "문화"는 엉망인데 "관리"로 해결하려고 하면 문제가 더 커집니다.

    이성열님 회사도 문제가 터진 다음에는 어렵습니다. 개발자들을 설득하는 방법은 개발자들에게 "소프트웨어 공학"을 이해시키고 왜 개발자들이 체계적으로 개발을 해야만 성장을 하고 "고급개발자"가 되는지 납득시키는 겁니다. 주먹구구식으로 개발을 하면 10년을 또는 20년을 개발해도 3년차 개발자와 다를 것이 없습니다. 코딩 속도 조금 빨라진 정도입니다. 저는 그런 개발자에게는 절대 연봉을 5,000만원 이상을 주지 않을 겁니다.

    연봉 1억, 2억 이상 가치의 개발자가 되려면 스펙, 설계를 잘 쓸줄 알아야 합니다. 자기가 코딩까지 다 해야만 개발을 할 수 있으면 평생 초급 개발자입니다. 개발자들에게 나아가야 할 방향을 자꾸 주지시켜서 세뇌를 시켜야 합니다. 이것이 개발자도 회사도 좋은 길입니다.

  3. 저는 문서화를 제가 기억못하기 때문에 합니다.

    기억하고 있다면 대화가 가장 커뮤니케이션이 효율이 좋고..
    기억하지 못한다면 그때 얼른 적습니다.
    그리고 기억하지도 못하고, 문서화도 없다... 그건 무조건 폐기하는 대상입니다.
    너무 단순하죠?

  4. 안녕하세요. whitekid님

    문서화의 첫번째 이유가 자신을 위해서죠. ^^

  5. 돈과 시간이 그 실행의 기준이 될것 같습니다.
    문서화에는 비용이 드니까요.

    저의 생각으로는
    만들어지는 모든 함수를 사전처럼 만들어서 사람들이 공유할 수 있게 된다면
    문서화'도 되고 재사용도 되고' 개발비용과 불필요한 노력도 줄어 들 수 있을것 같습니다.

    더. 나아가. 이 문서화된 데이터가 함수이면서도 UI 에 쓰여질 수 있다면. 엄청난 도구가 될듯합니다.

  6. 안녕하세요. shint님

    저는 문서화는 비용으로 생각하지 않습니다.
    문서화를 비용으로 생각하는

    1. 필요 없는 문서를 경우는 문서를 너무 많이 적거나
    2. 문서를 작성하는 경험과 실력이 부족하거나
    3. 프로젝트가 끝나고 적는 경우입니다.

    문서는 필요한 만큼만 필요한 시기에 적어야 합니다.
    프로젝트에서 가장 중요한 문서는 스펙(SRS)입니다.

이번 프로젝트 내일 끝나?

2011.01.31 13:28 by 전규현


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





SW개발 프로젝트가 언제 끝날지 정확하게 모르는 경우가 허다하다.

프로젝트를 진행하고 있는 개발자나 PM도 이 프로젝트가 언제 끝날지 전혀 감이 안잡히는 경우가 많다. 
하지만 분명한 것은 이 프로젝트가 예정된 종료일까지는 끝나지 않을 것이라는 것은 아주 잘 알고 있다.
이것을 알고 있다면 일정을 연기해야 하는데 언제로 연기를 해야 하는지 알 수 없으니 일정 연기를 요청하기도 어렵다. 일정을 연기 했으면 그 일정은 지켜야 하는데 연기된 일정도 전혀 근거가 없이 그냥 감으로 생각한 일정이기 때문이다. 이런 일정은 또 연기되기 마련이다.

그래서 Due date이 되어서어 끝나지 않음을 알고 일정 연기를 요청하고 한다. 이렇게 촉박하게 일정이 자주 연기가 되면 영업이나 마케팅 부서에서는 도저히 개발팀의 일정을 믿을 수 없어서 자신있게 비즈니스를 하기 어려워진다.

그럼에도 일정이 늦어지고 있는 것을 늦게 알려주는 이유는 미리 얘기를 해봤자 일찍 혼나기 밖에 더하겠냐는 생각때문이기도 하다. 일정이 촉박해지면서 매일 야근을 하면서 열심히 하는 모습을 보여주면 일정을 연기해도 큰게 혼나지 않을 것이라고 생각하곤한다. 

하지만, 경영자 입장에서는 밤새면서 일정 못지키는 프로젝트보다는 6시에 퇴근하고 약속한 일정을 지키는 프로젝트가 훨씬 낫다. 그렇다고 주먹구구로 개발하면서도 일정을 터무니없게 길게 잡으면 곤란할 것이다.

제대로된 조직, 프로세스, 시스템을 갖추고 있는 회사에서 SRS를 적절하게 썼다면 1년짜리 프로젝트에서 1주일 지연이 되는 것을 6개월전에도 알 수 있다. PM은 이런 일정 지연이 생기면 이를 복구하기 위한 다양한 기법들을 사용하게 된다. 따라서 일정에 맞춰서 프로젝트를 마칠 수 있는 가능성은 대단히 높아지게 된다.

더 이상 개발팀에게 "내일은 끝나나?"라고 물어볼 필요가 없다. 개발팀도 신뢰를 회복할 수 있을 것이다.
또한, 더 중요한 것은 6시에 퇴근을 하면서도 프로젝트를 더 일찍 끝낼 수 있다는 것이다.

심정적으로 경험적으로 이것이 믿어지지 않는 분들도 많겠지만, 필요한 만큼 적절히 체계화 된 개발을 하고 SRS와 설계를 적절하게 하면 프로젝트 일정도 지키고 개발자도 행복해진다.

여기서 중요한 것은 적절하게 하는 것이다. 적절하다는 것이 가장 어려운 것 중 하나다.

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

전규현 개발프로세스 일정, 프로젝트

  1. 적절하게 하는것 이라는 말 적극 공감합니다.
    저희도 제품 마무리 짓고 있는데 아직도 SRS 설계를 하긴 했는데 적절히 안해서 일정이 연기되는 상황을 몇번 겪고나니 참 가슴이 쓰라립니다 ^^

  2. 안녕하세요. 드럼캡님
    SRS를 쓰셨다고 하셨는데, 부족한 것인지 과한 것인지 궁금하군요. 대기업에서는 부족하면서도 과하게 적곤 합니다.
    즉, 필요한 것은 빠지고, 기능은 설명을 너무 과하게 적습니다.
    SRS를 적절히 적는 것은 설계를 하고 구현할 개발자들이 설계를 구현을 무리없이 할 정도입니다. 전혀 물어보지 않고 개발할 수 있는 것은 과도하게 적은 것이고, 너무 많이 물어봐야 하면 부족하게 적은 것입니다. 또한 기능 위주로 적은 것은 빠진 부분이 너무 많아서 나중에 큰 문제가 됩니다.

  3. 항상 그렇지만 적절한것이 가장 중요하면서도 어려운것 같아요.
    그리고 디버깅을 하다보면 다른것들까지 계속 손을 보게 되다보니 일정은 계속 늘어나게 되더라구요.
    그럴때에는 확실하게 이것 까지만 이번 릴리즈에 버그를 잡고
    알려진 버그로 남기는 것도 방법이긴 하지만 크리티컬이라면 이것까지만 잡고.. 이것까지만... 라는
    개발자의 욕심으로 인해서 일정이 무제한으로 늘어나게 되죠 ^^;

    이런걸 보면 저도 개발자이지만 적당하게 선을 긋는 법을 조금더 터득해야 할텐데 매번 아쉬움을 느끼게 됩니다.

  4. 구차니님 안녕하세요.
    개발 일정에 테스트 기간까지 모두 포함해야 합니다. 프로젝트에 따라서 테스트 기간이 구현기간보다 더 긴 경우도 있습니다.

    그런데 흔히 테스트 기간은 너무 짧게 잡아 놓고 마치 구현기간에 거의 출시 가능한 제품을 만들어 낼 수 있을 것 같은 생각을 하곤 합니다.

    구현과 테스트 기간의 비율은 하나의 정답이 있는 것이 아니고 프로젝트의 성격과 난이도에 따라서 달라집니다. 이것을 판단하는데 경험도 필요합니다.

    또한 출시를 할지 말지 결정하는 회의를 Go-live회의라고 합니다. 이 회의를 통해서 버그를 몇개 안고 출시를 할지 고쳐서 출시를 할지 결정하게 됩니다.

  5. Blog Icon
    탁..

    (문제제기에 대해 늘 공감하며 보고 있습니다. 감사합니다) 어떻게 하면 적절히 할 수 있을까요? 프로젝트 예측이라는 게 제겐 참 어려운 일인데. 어떻게 하면 요구사항으로 실제 완성이 되기 까지의 기간을 예측을 할 수 있나요?

  6. 안녕하세요. 탁..님

    프로젝트 일정 예측에 가장 필요한 자료는 SRS입니다. SRS를 제대로 작성하게 되면 각 Task는 1~2일 단위로 쪼갤 수 있습니다. 이를 WBS라고 합니다. 일정이 이렇게 작게 쪼개지지 않고 몇주 또는 몇달 단위로 관리를 한다면 일정을 관리할 수도 없고 늦어지고 있는지 판단할 수 없습니다.

    이러려면 SRS를 잘 적어야 하는데 이는 하루이틀에 가능한 일이 아닙니다. 제대로 방법을 배워야 하고 경험해야 하고 실제 프로젝트에서 수십번 해봐야 합니다. 제대로 적으려면 수년이 걸리고 10년을 적어봐도 계속 더 잘적을 것들이 남아 있는 분야입니다.

    일단 개발해야 할 것을 꼼꼼히 적는 것에 서 출발해보세요. 물론 이것만으로는 스펙(SRS)의 20~30%만 커버한다고 생각하면 됩니다. 그래도 시작은 되죠.

  7. Blog Icon
    bluemonk

    예측이란 틀릴 수 있기 때문에 예측 아닐까요? 주식도 보면 주식 전문가라고 하는 사람들도 시장 예측을 하죠. 대부분 확인 과정이 없어서 그럴 수도 있지만 많은 경우 맡지 않는 것 같습니다. 그들의 예측이 맞지 않을때 왜 맞지 않는데 예측에 대한 책임을 지지 않는 거야 라고 생각한 것도 있습니다. 그러면 왜 그들에게 책임을 지라고 사람들은 묻지 않을까요? 사람들 다 틀릴 수 있다고 생각하기 때문인 것 같습니다. 프로젝트 기간 또한 비슷하지 않을까요? 다들 틀리 수 있다는 가정을 하지 않는데 어려움이 있는 것 같습니다. 무조건 기간을 맞춰야 한다는 문제가 상황을 힘들게 하는 것 같습니다. 선을 그어놓고 당사자들이 맞춰서 뛰어라 하는 상황이 많은 건 아닐까 생각해 봅니다.

  8. Blog Icon
    bluemonk

    또한 프로젝트에 대한 예측과 그에 따른 결과가 어떻게 됐는지. 어떤 부분이 예측을 힘들게 하는지. 어떤 이유 때문에 연기 되었는지에 대한 검증이 없고 또한 그 검증에 대한 소프트웨어 업체간의 정보 공유가 없는 것이 문제이지 않을까요? 그 부분에 대한 노하우가 쌓이지 않고 공유되지 않는 것이죠. 다들 닥친 프로젝트 마치고 유지보수 하는데 여력을 쏟지 그 과정에 대한 검증과 과정에 대한 리부가 없는 시간의 환경 또한 문제인 것 같습니다.

  9. 안녕하세요. bluemonk님

    예측은 틀릴 수 밖에 없죠. 정확한 예측은 프로젝트가 끝날 때 하는 것이라고들 합니다. 하지만 프로젝트 일정과 비용을 전혀 예측할 수 없다면 비즈니스를 할 수가 없죠.

    프로젝트를 시작할 때 하는 예측은 흔히 2배정도 차이가 난다고 합니다. 심지어 5배 이상 차이나는 경우도 있습니다. 하지만 SRS를 쓰고 설계를 하는 과정에서 상당히 정확한 일정을 예측할 수 있게 됩니다. 프로젝트는 우리의 통제하에 있는 것이라도 예측 가능하게 됩니다. 통제권을 잃어버리면 예측이 안되죠. 이렇게 프로젝트가 언제 끝날지 모르는 프로젝트도 허다합니다.

    프로젝트 예측은 개발자들이 하는 것으로 위에서 일정이 고정되어서 내려오면 그냥 열심히 해는 것가지고는 안되고 스펙 기반하에 일정을 단축할 수 있는 다양한 방법을 동원해야 합니다. 이또한 일정이 상당히 정확하게 예측이 되어야 단축할 수 있는 방법도 동원할 수 있습니다.

  10. Blog Icon
    bluemonk

    스펙 기반하에 해야 하는 것이 맞는 것 같습니다. 그 스펙이 바뀐다면 어쩔 수 없는 거 같습니다. 그 스펙이라는게 SRS 를 쓰면서 다시 한번 범위가 검증되는 것도 맞는 것 같습니다.
    사람들은 자연에서 법칙을 찾고 싶어합니다. 그리고 그것을 숫자화(수치화, 수식화) 합니다. 그래야 예측 가능하고 통제 가능하다고 생각하기 때문입니다.
    그래서 앞에 이야기 한데로 숫자화 하는 노력이 필요한 것 같습니다. 법칙이나 조건 같은거라고 할 수도 있겠죠. 다만 이러한 상황 속이라도 예측이 빗나갈 수 있다는 전제는 반드시 존재해야 한다고 생각합니다. 인간도 자연의 일부이니까요. 그 예측이 틀린 것에 대한 책임이 너무 큰 것 같다는 생각이 듭니다. 그 책임이 주로 개발자에게 돌아오는 것 같아서 더욱 그렇습니다. 왜 그런 환경에 대한 부분에 대한 인프라에 대해서는 신경을 쓰지 않으면서 개발자에게만 그주로 그 책임을 묻는 것 같습니다. 프로젝트 예측이 가능하게끔 정보를 쌓고 이를 공유하는 것이 필요하다고 생각합니다.

소프트웨어 관료화

2009.08.31 22:25 by 전규현


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




"공무원 수는 해야 할 일의 경중이나 업무 유무에 관계없이 일정한 비율로 증가한다", "공무원은 서로를 위하여 서로 일을 만들어 낸다", "유능하지 못한 사람은 공무원이 된다."
이는 그 유명한 파킨슨의 법칙입니다.

소프트웨어를 개발할 때도 이와 같은 함정이 도사리고 있습니다.
주먹구구식으로 소프트웨어를 개발하다가 체계적으로 개발하고 싶은 요구가 생길 때 프로세스팀을 구축하고 개발 프로세스를 정립하다 보면 파킨슨의 법칙에 빠지기 쉽습니다. 

프로세스팀의 구성원들은 진짜 소프트웨어 전문가로 구성되는 경우가 드믑니다. 여기서 말하는 소프트웨어 전문가란 코딩만 잘하는 개발자가 아니고, 구축, 설계, 테스트, 형상관리, 버그 추적, 빌드, 릴리즈, 방법론 등 소프트웨어 관련 여러 분야의 지식과 경험을 두루 갖추고 있는 사람입니다.

이런 비전문가로 구성된 프로세스 팀은 소프트웨어 개발의 내용을 속속들이 잘 모르고 너무 형식에 치우칠 수 있고, 끊임없이 프로세스팀이 할 일을 만들어 내기 위해서 프로세스를 점점 복잡하게 만들곤 합니다. 이들은 어떤 것이 정확하게 올바른 방법인지 잘 몰라서 그렇게 하기도 하고, 자신들의 밥줄을 견고하게 하기 위해서 여기저기 승인 절차를 많이 추가해서 프로세스팀이 소프트웨어 개발 프로세스의 중요한 역할을 하고자 한다.

프로세스팀은 소프트웨어를 효율적으로 개발하기 위한 방법들을 연구하지만 소프트웨어 개발 프로세스 중간에 직접 끼어들어서 간섭하는 프로세스를 만드는 것은 바람직하지 않다. 소프트웨어를 개발하는데 있어서 여기저기 승인 절차를 잔뜩 집어 넣어 놓는 것도 그리 좋지 않습니다. 승인 절차가 소프트웨어의 무결성을 보장해주진 않습니다. 오히려 관료화된 승인 절차는 아무런 도움이 되지 않는 경우가 많습니다. 소프트웨어는 각 분야의 전문가들이 자율적으로 효과적으로 움직였을 때 가장 효율적으로 개발됩니다. 명시적인 승인 절차가 없더라 승인절차를 거친 것과 같이 모두가 진행상황을 훤히 알 수 있게 됩니다. 이렇게 개발되는 방식이 오히려 소프트웨어 무결성에 더 도움이 됩니다. 승인 절차는 형식적인 승인이 되기 쉽지만, 각 단계의 전문가들이 리뷰를 하고 Unit 테스트를 하고 시스템 테스트를 하고 빌드전문가가 확인을 하고 이러한 전 과정을 통해서 문제가 되는 것들은 발견이 되고 개발도 효율적으로 진행됩니다.

소프트웨어 개발 경험이 부족한 프로세스 팀은 철저한 승인 절차가 아니면 안전한 소프트웨어를 개발하기 어려울 것 같이 생각되지만, 이는 경험 부족에서 오는 착각이거나 관료화의 조짐입니다.

또 소프트웨어 개발에 대한 이해가 부족한 경영자들은 이들이 주장하는 프로세스가 그럴듯해 보이지만 사실은 소프트웨어 개발에 상당부분 걸림돌이 되고 있다는 것을 눈치채기 어렵습니다.

진짜 소프트웨어 전문가로 프로세스팀을 만들 것이 아니면 내부에서 진행하는 여러 개선 시도들이 시간 낭비인 경우 많고, 시행착오 없이 6개월이면 갖출 수 있는 경쟁력을 먼 거리를 돌아서 수년이 걸리거나 영영 경쟁력을 갖추지 못하는 경우도 많습니다. 프로세스팀을 갖추려면 소프트웨어 전문가로 구성을 하거나 내부에 전문가가 없다면 외부에서 도움을 받는 것이 좋습니다.

회사 내에서 소프트웨어 개발을 잘 하는 개발자가 소프트웨어 전문가라고 생각하지는 마세요. 공을 잘 차는 축구 선수일 뿐입니다.  

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

전규현 개발프로세스 관료화, 파킨슨의법칙, 프로세스

  1. 우리나라 공무원은 엘리트라서 말이죠 ㅋㅋ
    저런 이유에서 사수가 있는건 참 좋은것 같습니다
    (사수없이 3년 ㅠ.ㅠ)

  2. 구차니님 안녕하세요.
    사수... 이것에 대해서도 할말이 많습니다. ^^;
    기형적인 구조 떄문에 사수가 아니면 별 뾰족한 방법이 없는 것도 현실이고... 나중에 올릴께요.

  3. Blog Icon
    김경록

    프로세스팀의 구성원들은 진짜 소프트웨어 전문가로 구성되는 경우가 드물다는 말...

    상당히 찔리고 공감이 가네요 ^^;;;

  4. 안녕하세요. 김경록님
    솔직하시군요. ^^
    너 자신을 알라!, 아는 것이 힘이다.
    즉, 자신을 아는 것이 힘이다.

  5. Blog Icon
    hermian

    해결책은 없겠죠.
    철통 밥그릇이 그렇듯...
    전문가가 아닌 사람의 머리를 쪼개서 지식을 넣어 줄 수도 없고...
    참으로 난형난재입니다.

  6. hermian님 안녕하세요.
    지식을 넣어 주는 기술은 300년은 지나야 나올 듯합니다.

  7. Blog Icon
    이혜원

    300년 지나면 가능해지나요??
    가능한 일이면 좋겠습니다.
    어쨌든, Ray님의 글들에 동의 합니다..

  8. 안녕하세요. 이혜원님

    그래서 저희같은 사람의 도움이 필요합니다.
    외부 전무가의 힘을 빌어서 변화를 꾀하는 것이 가장 빠르고 무리없이 변화에 성공할 수 있는 방법입니다.

  9. Blog Icon
    장호진

    제가 유일하게 RSS등록해두고 잘 보고있는 블로그인데 처음 글 남깁니다.
    7년 동안 사수없이 고군분투해오다 보니 남는게 별로 없네요....
    그래서, 요즘 전규현님 책과 블로그의 도움을 받아서 흔히 얘기하는 시스템과 프로세스를 구축하고 있습니다.
    앞으로도 좋은 글 부탁드립니다.
    가끔 글도 남길께요^^

  10. 장호진님 안녕하세요.
    열심히신군요. ^^ 책보고 스스로 뭘 해보는 것이 정말 힘들죠. 궁금하신 것이 있으면 언제든지 문의해주세요. Email은 항상 열려있습니다. :)

프로세스가 창의성을 저해한다고?

2009.04.08 22:08 by 전규현


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




개발 프로세스가 창의성을 저해한다고 싫어하는 개발자, 관리자, 경영자를 종종 만나게 됩니다.
이들이 프로세스를 싫어하는 이유는 과거에 개발 프로세스 도입에 대한 실패의 경험이 있거나 그런 얘기를 종종 전해 듣기 때문입니다.

이렇게 개발 프로세스 도입에 실패하는 이유는 현실성이 없는 이론적인 프로세스를 도입하거나 회사의 역량 수준에 맞지 않는 프로세스를 시도한 경우가 많습니다. 또 인터넷이나 책을 통해서 배우게 된 프로세스를 따라 하다 보면 그 Context를 다 알지 못하고 형태만 비슷하게 흉내 내다가 실패하기도 합니다.

그럼, 그렇다고 프로세스가 없다면 창의성이 샘솟을까요?
개발프로세스가 제대로 갖춰지지 않은 회사는 대부분 각 개발자들의 개인 역량에 따라서 적절히 개발이 이루어지며 개발자들은 역할의 구분 없이 만물박사 식으로 온갖 업무를 처리합니다. 이러다 보면 항상 바쁘고 새로운 기술을 조사한다거나 참신한 생각을 할 틈이 별로 없습니다. 또, 멋진 아이디어가 떠올라도 마땅하게 Follow up할 방법이 없어서 아이디어를 떠올린 개발자가 북치고 장구치고, 경영층도 설득하고, 프로토타입도 만들어보고 시장 조사도 해보고 해야 합니다. 안 그래도 바쁜 마당에서 짬을 내서 또 새로운 아이디어를 Follow up하기는 정말 어렵습니다. 누가 무슨 일을 얼마나 하고 있는지 잘 파악이 안되므로 또 이런 일을 벌여서 괜히 성과도 없이 평가만 안 좋아 질까봐 포기하기 십상입니다. 또 아이디어 낸 사람이 총대를 매야 하기 때문에 그렇다고 기존의 업무가 줄어들지 않기 때문에 공식적으로 이런 활동을 안하려고 합니다.

하지만, 개발 프로세스를 잘 갖추고 있는 회사는 아이디어를 내기만 하면 일단 회사의 System이 이를 Follow up합니다. 일단 아이디어는 수면 위로 떠올라서 여러 사람과의 Review를 통해서 더욱 Refine되고 정식 절차를 통해서 Prototype을 만들고 마케터는 시장 조사를 하고 영업은 고객들의 의견을 수집해 옵니다. 관리자는 해당 개발자가 아이디어를 발전시킬 수 있도록 정식으로 업무를 할당해서 시간을 빼줍니다. 한마디로 개발자는 기술적인 것만 Follow up해도 됩니다. 물론 모든 아이디어가 제품화 되는 것은 아니지만, 이런 아이디어들이 10개 100개 모여서 성공하는 제품이 나옵니다.

결국 프로세스가 창의성을 저해한다는 생각은 무지의 산물이거나 잘못된 경험의 결과입니다.

문제는 회사의 몸에 딱 맞는 개발프로세스를 갖추는 것이 어렵다는 것입니다. 현재 개발을 어떻게 하고 있는지 조사를 해보면 제각각 일겁니다. 이것부터 통일해 나가면서 조금씩 바꿔가는 것이 스스로 해볼 수 있는 최선의 방법입니다.

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

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

전규현 개발프로세스 Follo up, prototype, Refine, review, System, 마케터, 아이디어, 역량, 제품화, 창의성, 프로세스

  1. Blog Icon
    ~_~

    제가 일하고 있는 곳은 새로운 아이디어가 있다면 알아서 적용시키고 실현 시킨뒤에나 검토가 됩니다. 따라서 회사의 요구대로 아이디어 따위는 일체 생각도 하지 않고 있습니다. 음... 개인시간을 좀더 늘려서 혼자만의 아이디어 스캐치를 해보는게 좋을듯 싶네요

  2. 대부분의 회사가 그런것 같습니다. 또 개인시간이 마음대로 늘어나지 않는 것이 문제죠. 시스템이 잘 갖춰져 있어야 개발자들이 여유가 좀 생기고 좋은 생각도 하게 됩니다.

  3. 회사에 맞게 딱 맞는 프로세스를 도입한다는 것이 정말 힘든 일인줄 압니다.
    이론적인 프로세스를 도입하고 그것에 맞춰서 따라간다는 것은 마치 적응하지 못한 간난아기보고 걸어달라고 하는 것과 마찬가지인것 같습니다. 이론적인 프로세스를 도입한다 하더라도 조직에 맞게 변형해서 수년간 틀을 마련한다면야..되겠지만.말이죠..

  4. moova님 안녕하세요.
    대부분의 프로세스를 시도한 회사들은 주먹구구식으로 개발하는 것보다도 못한 경우가 많습니다. 시행착오에 대한 경험을 얻는 것이 유일한 성과라고 할 수 있습니다. 스스로 조그씩 발전시켜나가거나 전문가의 도움을 받는 것이 좋으나 주변의 프로세스 전문가들이 대부분 moova님이 말씀하신 것처럼 이론 알고 있어서 실패할 가능성이 많습니다. 이렇게 얘기하고 보니까 답이 없네요. - -; 아무튼 과욕은 금물

  5. 창의성을 저해하는 것은 프로세스를 위한 프로세스를 무작정 도입하기 때문인 것 같습니다. 어디서 누가 좋다고 하니까 필요없는 돈을 발라가면서 열심히 도입을 하고, 일단 도입은 해 놨으니 그게 옳건 그르건 무조건적인 준수를 강요합니다. 뭔가 좀 문제가 있다 싶으면 그걸 해결한답시고 또 다른 프로세스를 도입하기를 반복하죠. (순수 IT 회사보다는 제조로 시작한 회사가 그런 경향이 강한 것 같습니다.) 나중에는 프로세스 따라 다니다가 지쳐버리죠.
    회사의 몸에 딱 맞는 개발프로세스를 갖출 수만 있다면 정말 좋을텐데요...

  6. Shawn님 안녕하세요.
    대기업들은 중소기업과 다르게 무리한 프로세스도 꽤 오래 끌고 가고 직원들은 다들 피해가는 방법을 알고 있고, 그렇게 시간이 흘러서 아주 이상한 형태로 진화를 합니다. 겉보기에는 프로세스가 꽤 그럴듯 한 것 같은데 속은 전혀 아니고 오히려 생산성을 저해하는 경우입니다.
    우리나라의 소프트웨어 개발 역사는 너무 짧기 때문에 아직 그런 저변이 부족합니다. 소프트웨어 선진국을 조금씩 흉내내는 것이 좋은 방법입니다.

  7. "멋진 아이디어가 떠올라도 마땅하게 Follow up할 방법이 없어서" 라는 부분에 격하게 공감합니다. :)

  8. 우울한딱따구리님 안녕하세요.
    우리나라 개발자들이 전세계 어느나라의 개발자보다 아이디가 넘치는 것은 저도 인정하는 바입니다. 사실 개별 개발자들의 지식수준이나 코딩 능력도 최고입니다. 그런데 회사나 사회전반의 저변이 이를 못받쳐주니 나이를 먹을수록 경력에 걸맞게 실력을 끌어올리지 못하고, 좋은 아이디어가 사장되는 경우가 너무나 많습니다. 기발팀이던, 회사던, 국가도 System으로 움직여야 하는데, 우리는 아직도 사람이 움직이고 있습니다.

소프트웨어 개발의 극과 극

2009.02.18 01:31 by 전규현


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



꽤 오래 전에 TV에서 "비교체험 극과 극"이라는 프로그램을 방영한 적이 있습니다. 어떤 아이템을 정해서 가장 비싼 것과 가장 싼 것을 비교하는 프로그램이었는데 꽤 재미있게 본 기억이 납니다.

 

소프트웨어를 개발하는 현장에서도 극과 극 현상은 드물지 않게 발생합니다.

 

여러 회사를 분석해보면 완전 주먹구구이거나 또는 너무 무거운 방법론을 도입해서 오히려 부담이 되는 경우가 많습니다. 적당히 중간인 회사를 찾기가 더 어렵습니다.

 

완전 주먹구구식 가내수공업 형태의 개발방식도 문제가 있지만, 몸집과 역량에 걸맞지 않은 거대한 방법론을 무조건 따라하는 것은 더 문제가 큽니다. 그럴 바에는 차라리 주먹구구가 낫습니다.

 

그런 주먹구구회사가 문제를 깨닫고 거대 방법론들을 스스로 연구해서 도입을 하면 그 핵심은 모르고 형식만 따라하는 경우가 많습니다. 그러다보면 프로세스가 너무 복잡하고, 문서도 너무 많이 만들어야 되는 경우가 허다합니다. 이런 시도는 거의 실패한다고 보면 됩니다. 애초에 따라 할 수도 없고, 억지로 따라한다면 비용과 시간은 몇 배로 더 들고 회사는 망하기 길 밖에 남지 않습니다. 국내의 대부분의 소프트웨어 회사들은 그러한 거대 방법론은 필요하지도 않습니다. 또 그렇게 많은 문서는 만들 필요도 없습니다. 개발에 필요한 핵심문서 몇 개만 자신들이 만들고 업데이트하고 감당할 수준 정도만 만들어내야 합니다.

 

극과 극의 양쪽이 아닌 회사에 딱 필요한 수준의 중간점을 찾아서 적용해야 합니다.

 

 

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

전규현 개발프로세스 문서, 프로세스

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바