2012년 6월 4일 월요일

개발자 100명을 더 투입한다면?

소프트웨어 회사에서 프로젝트를 진행할 때 흔히 벌어지는 문제가 "개발자가 부족해서 프로젝트가 늦어진다"는 것이다.

그럼 거꾸로 애플에서 날고 기는 개발자 100명을 투입시켜 줄테니 프로젝트를 제대로 끝낼 수 있냐고 물어보면 대부분 대답은 "글쎄요"다.

벽돌을 쌓거나 땅을 팔때는 사람을 2배 투입하면 대부분 시간이 반으로 줄어든다.

그런데 소프트웨어를 개발하는 프로젝트에서는 왜 그렇게 잘 안될까?

그 이유는 "스펙과 설계"에 있다.
빌딩을 세울 때는 설계가 명확하게 있다. 이 세상에 설계 없이 만드는 빌딩은 없을 것이다. 그리고 협업이 가능하도록 일이 세분화 되어 있고 전문화 되어 있다.

그런데 유독 소프트웨어(특히 우리나라)에서는 스펙과 설계가 땅파고 벽돌 쌓는 것보다 시원찮다. 그런 상태에서 개발을 하다보니 건설현장에서 빌딩 올라가듯이 개발이 되는 것이 아니고 뒤죽박죽이 된다. 이런 환경에 익숙해진 개발자는 뭐가 문제인지 인지하지 못하는 경우가 대부분이다.

스펙과 설계가 제대로 작성되어야 협업이 가능하다. 

여기서 핵심은 컴포넌트다. 컴포넌트가 일을 깔끔하게 나눠서 일할 수 있을 만큼 깨끗하게 나눠져 있어야 한다. 그래서 부서별, 개발자별로 일을 나눠서 할 수 있고 서로 인터페이스 맞추느라고 시간을 허비하지 않는다. 


스펙과 설계가 제대로 되지 않은 상태에서 개발을 하면 컴포넌트 단위로 일을 나눠서 할 수 없기 때문에 "화면"단위로 일을 나눠서 하기도 하고, 적당히 일을 나눠서 하다가 서로 겹치기도 하고 나중에 통합에 엄청난 시간이 걸리게 된다. 또한 어떻게 소프트웨어가 동작은 한다고 하더라도 그 아키텍처는 뒤죽박죽이 되어서 나중에 유지보수도 엄청나게 어렵게 된다.

그럼 스펙/설계 단계에서 어느 정도까지 설계가 이루어져야 할까?

대답은 의외로 간단하다.  스펙/설계의 결과를 가지고 소프트웨어 개발자들이 충분히 구현을 할 수 있을 정도면 된다. 여기서 "충분히"라는 단어는 몹시 애매하다.

문서만 보고 서로 전혀 대화를 하지 않고도 구현을 할 수 있으면 너무 자세히 적은 것이다. 이렇게 자세히 적으면 시간 낭비이고, 개발자에게 너무 자유도를 없앤 것이다. 

그럼 "충분히"는 어느 정도 일까?  개발자가 설계대로 구현을 하면서 약 5% 정도의 내용은 설계자나 관련된 컴포넌트 개발자와 서로 의논하면서 개발할 수 있을 정도면 적당하다고 할 수 있다. 너무 많은 내용을 의논하면서 구현시 결정해야 한다면 적은 내용이 너무 부족한 것이다. 따라서 "충분히"는 상황에 따라 다른 것이다.

설계가 부족하다면 프로젝트리더(테크니컬리더)는 여러 개발자에게 설명하느라고 시간을 보내고 자신이 담당한 개발을 할 시간이 부족해지고, 개발자들에게 설명을 소홀히 하면 개발자들이 제 멋대로 개발을 해와서 문제가 생기곤 한다. 나중에 이를 고치느라고 시간이 몇배로 낭비된다.

설계는 스펙을 작성할 때부터 시작이 되고 설계 단계에서는 컴포넌트가 다 구분되고 인터페이스가 정의가 되어서 소스코드 상에 모두 적히고 컴파일이 가능하도록 해야 한다.

그러기 위해서는 파일이름, Class이름, Public 함수 이름과 parameter, return값이 모두 정해져야 한다. 그리고 그 설명을 문서에 다는 것은 중복이기 때문에 Doxygen이나 Javadoc을 이용해서 소스코드에 주석으로 설명을 하면 효율적으로 설계 정보를 관리할 수 있다.

이렇게 설계가 완료되면 바로 Daily Build가 가능하며 구현 첫날부터 개발자들은 빌드가 가능한 소스코드에 자신이 맡은 컴포넌트의 내용을 채워나가면 되는 것이다. 즉, 첫날부터 이미 통합이 된 상태에서 개발을 하는 것이다.

이렇게 스펙과 설계를 작성하면 일정 산정의 정확도도 훨씬 올라가고 개발자를 더 투입하더라도 도움이 된다. 또한 외주로 개발하는 것도 가능하다.

물론 외주를 줄 경우에는 "설계"도 외주를 주는 경우가 많으므로 이런 경우는 "스펙"까지를 제대로 작성하면 된다.

이렇게 일을 효과적으로 나눠서 할 수 없다면 스펙/설계를 제대로 작성한 것이 아니다. 개발 시간과 비용도 줄일 수 있다. 가장 중요한 것은 프로젝트가 관리 가능한 상태가 된다는 것이다. 일정과 비용이 상당히 정확하게 예측 가능해지고 일정이 지연 상태를 빠르게 파악할 수 있고 대처를 할 수 있다.  스펙과 설계를 제대로 작성할 수 없다면 온갖 프로젝트 관리 기법은 다 소용없다. 결국 야근 밖에 남지 않는다.

"일을 나눠서 할 수 있다."는 것은 결국 개발자가 행복하게 일할 수 있도록 해준다.

댓글 7개:

  1. 매번 좋은글 잘 읽고 있습니다. 감사합니다^^
    작년 외주하면서 안 사실인데 대기업 조차도 설계할 능력을 가진 인력이 없다시피 하고요....
    경영진은 설계하는 시간을 '노는 시간'으로 보는게 큰 문제인것 같습니다.

    시간에 쫓겨서 요식행위로 한 설계서가 제대로 될리가 없지요..
    결국 화면단위의 주먹구구식 개발로 인해 생긴 문제는 고스란히 개발자에게로 넘어갔죠.

    그런데 또 그것때문에 다음에 설계를 제대로 하자하면 핑계대지 말래요...
    악순환이에요..

    답글삭제
  2. Black_H님 안녕하세요.

    그래도 흔히 설계를 열심히 한다고 한 결과물을 보면 대규모 방법론을 흉내내서 Template이나 채우는 정도라서 시간만 많이 들어가고 구현시에는 보지도 않는 문서를 잔뜩 만들어냅니다.

    제대로 하는 것을 한번도 본적이 없고 한번도 해본적이 없기 때문에 벌어지는 일들입니다.

    그럴려면 차라리 주먹구구가 더 낫습니다.

    답글삭제
  3. 항상 머리속에서만 맴도는 부분을 명확히 해주셔서 감사하다는 말씀드립니다.

    빠른 아웃풋을 요구하는 경우 스펙/설계에 시간을 많이 투자하지 못해 결국은 "일단은 이렇게 가자" 라는 경우가 많은데 이럴땐 어떻게 해야 하는지가 참 답답합니다.

    답글삭제
  4. 안녕하세요. 이경희님

    개발자들도 시간을 줘도 스펙을 잘 작성하지 못한다는 문제가 있습니다.

    경영자가 스펙을 작성할 시간을 주지 않는다면 스펙을 몰래라도 작성하는 것이 더 낫습니다. 그런 것도 안될 경우는 어차피 문제가 있는 프로젝트를 진행하는 겁니다. 결국 지연되고 난리를 피는 거죠.

    답글삭제
  5. [황과장의 IT 캐스팅] ② 기획자들이여 개발자들의 언어를 이해하자 해커, 긱(geek), 구루의 공통점은 무엇일까요? 바로 개발자를 지칭하는 용어들입니다. 물론 각각의 의미는 조금씩 다르지만 ..

    답글삭제
  6. 안녕하세요.

    코딩은 프로그램 짜다보면 실력은 좋아진다고 보는데요.(익숙해 진다가 맞는 표현이겠죠.)
    설계도 하다보면 늘까요?
    아니면 체계적인 훈련을 할 수 있는 커리큘럼이 있을까요?
    필드에서 쌓이는 개인 경험만이 답일까요?
    극단적으로 회사를 그만두고 좋은 멘토가 있는 회사를 찾는 것이 답일까요?
    (최대한 지금 있는 회사에서 좋은 개발 방향을 제시하고 싶습니다.)

    책에서 나온 내용 숙지해 가며 설계를 해도 이게 잘하고 있는건지 못하고 있는건지... ^^;;
    우물안 개구리가 우물밖으로 나가기 위해 이리저리 뛰어보는 모습입니다.

    본문 글에 컴포넌트를 구분한다고 되어 있는데요.
    컴포넌트는 어떻게 구분하는 것이 맞을까요?
    저같은 경우 감각적(?)으로 필요할 것 같은 컴포넌트로 짤라서 개발했습니다.
    대부분 혼자하는 프로젝트라 구색만 맞으면 됐거든요.(밤이라도 새면서 일정 맞추면 문제가 없었습니다.)
    하지만 다수의 개발자가 참여한 프로젝트에설계자 입장에서
    컴포넌트를 잘 구분하기 위해서는 어떻게 해야 할까요?
    기존 CBD방법론에서 제시한 문서들이 필요한 것이 아닌가 하는 생각이 들기도 합니다.
    개발자들이 개발할땐 필요없는 문서라도 개발자들이 볼 문서를 만들기 위해서는 필요한것이 아닐까요?

    답글삭제
  7. 안녕하세요. 사자카로스님

    설계는 일단 근본 원리를 배워야 하고 경험이 많아야 합니다. 설계는 현재 요구되는 기능뿐만 아니라 미래의 전략까지 담아야 합니다. 또한 설계 결과물을 가지고 많은 개발자들이 나눠서 일을 할 수 있어야 합니다.

    컴포넌트로 나누는 것이 나눠서 일을 할 수 있도록 해줍니다. 혼자 개발을 하더라도 똑같습니다. 대신 혼자개발하면 대충해도 문제가 좀 적겠죠. CBD방법론을 따라야 하는 것은 아닙니다.

    스펙/설계서 외에도 가끔 개발노트와 같이 공유하고 싶은 내용을 남기기도 합니다. 하지만 개발과정에 필요하지 않은 문서를 나중을 위해서 일부러 남길 필요는 없습니다. 그러면 개발문서에 들어가야 할 것이 빠진 경우일 수도 있습니다.

    설계를 학원에 배울 수 있는 과정이 별로 없습니다. 배우는 코스는 많지만 별로 도움이 안됩니다. 그냥 그런 것이 있구나하는 정도입니다. 외부 교육과정에서 배운 설계 방법론을 억지로 실제 프로젝트에 적용했다가 낭패를 볼 가능성이 매우 큽니다.

    경험을 쌓아서 시행착오를 통해 배우거나 제대로 된 회사에서 배우거나 컨설팅을 받아서 배우는 방법이 있습니다.

    답글삭제