태터데스크 관리자

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

태터데스크 메시지

저장하였습니다.

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

2012.06.04 06:03 by 전규현


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






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


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


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


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


그 이유는 "스펙과 설계"에 있다.

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


image by linus_art






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

전규현 프로젝트/설계

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

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

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

  2. Black_H님 안녕하세요.

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

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

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

  3. Blog Icon
    이경희

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

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

  4. 안녕하세요. 이경희님

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

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

  5. Blog Icon
    사자카로스

    안녕하세요.

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

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

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

  6. 안녕하세요. 사자카로스님

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

티스토리 툴바