개발팀 내의 업무 구분에 대해서만 말씀드리겠습니다.

개발팀 내의 역할 구분은 보통 2가지 형태로 나타납니다.

첫째, 개발자가 어떤 단위시스템을 통째로 맡아서 요구사항 분석부터 설계, 개발, 시험, 인도까지 모두 책임지는 방법과
둘째, 개발팀원을 잘 분리해서 분석 담당, 설계 담당, 개발 담당, 시험 담당, 인도 담당으로 각각 나누어 해당 단계만 책임지는 방법이 있습니다.

첫째 방법을 쓰게 되면 개발자는 진정한 엔지니어로 발전할 수 있습니다.
이런 업무를 담당하는 개발자는
해당 시스템이 어떻게 동작해야 하는지 업무적으로도 잘 파악하고 있어야 하고
고객이 원하는 요구사항도 면담과 협상을 통해 충분히 도출할 수 있어야 하고
기능 구현을 위한 설계 능력도 충분히 갖추어야 하고
모든 기능을 버그 없이 개발할 수 있어야 하고
사용자/운영자지침서, 설치프로그램 같은 결과도 제공할 수 있어야 합니다.
그러나 현재 사회에서 양산하고 있는 초급 개발자들은 이런 일을 맡을 만한 수준이 안 됩니다.
보통 회사에 입사한 후 2~3년 정도의 경력자들이 조금씩 업무에 눈뜨게 됩니다.

둘째 방법은 철저히 역할 분담입니다.
경력이 있고 업무파악이 능숙한 중고급 개발자가 분석/설계를 담당하고
업무전체를 보는 능력은 없지만 코딩 하나는 똑소리 나는 초급 개발자가 개발을 담당하고
사소한 거 하나 안 놓치는 꼼꼼한 개발자가 시험하고
고객 입장에서 생각할 줄 아는 개발자가 매뉴얼 만들고 결과를 인도합니다.
장점은, 분야별로 개발자를 투입하기 때문에 일종의 전문가 시스템이 형성됩니다.
단점은, 경력이 쌓일수록 등급을 향상시켜 다른 분야로 전향을 해야 하는데
해당 분야에만 안주할 가능성이 있어서 발전이 없이 고착될 수 있습니다.

-----

첫째 방법은 보통 개발조직의 초기 단계로
소수의 개발자로 구성된 조직에서 주로 사용합니다.
초급이건 고급이건 모든 개발자가 분석, 설계, 개발 등등 골고루 다 합니다.
경력자에게 초급 개발자를 붙여 사수-부사수 개념이 생겨
사수가 분석,설계,개발을 하고 부사수가 개발을 보조하는 구성도 생깁니다.

이런 개발 시스템은 나중에 한계가 옵니다.
프로젝트 규모가 커지면 커질 수록 한두명이 담당하기엔 벅차게 되고
팀원을 충원하여 역할을 분담하게 됩니다.
그러나 팀원을 충원한다고 해서 그 팀원이 경력자가 하던 일을 맡을 수 있는 건 아니기 때문에
원래 하던 사람이 계속 일하게 되고, 신입이 그 일을 맡으려면 1~3년의 경력이 쌓여야 됩니다.
결국 인력 낭비가 발생하게 되죠.

그래서 인력 낭비를 하지 않으려면 경력자가 분석, 설계 (아키텍트)를 담당하고
초급자가 코딩 (코더)을 담당하는 구조로 진행하게 됩니다.
이런 경우의 초급자는 코딩만 열심히 해 줘도 큰 도움이 됩니다.
초급의 어중간한 지식 가지고 분석, 설계 내용에 이러쿵 저러쿵 해 봐야
업무 진행에 방해만 될 뿐입니다. (분석, 설계 담당자가 이미 그 업무에 대해 경력자인 것을 생각하면 됩니다)

-----

어느 쪽이 더 좋은지는 뚜렷하게 말할 수 없습니다.
시기에 업무에 따라 어느 한쪽이 더 좋을 수도, 나쁠 수도 있습니다.
그렇지만 개발팀이라는 조직이 있고 그 조직에 팀장과 팀원이 있다면
업무 구분은 자연스럽게 두번째 형태대로 흘러가게 됩니다.
주로 팀장(+부팀장)이 아키텍트 역할을 맡고 팀원은 코딩과 시험을 담당하게 되죠.

제 경험상으로 말씀드리자면
팀원을 팀장급으로 키우기 위해 훈련시키는 상황이 아니라면
분석설계는 팀장 또는 부팀장(아키텍터)이 담당하고, 팀원(코더)은 개발만 열심히 하는 구조가 좋다고 하겠습니다.


주정섭 님이 쓰신 글 :
: 게시판 글을 쓸 때마다 누군가 기가 막힌 반론을 제기해서, 지금까지 내가 깨우치지 못한 것을 알게 해주는 댓글이나 반론글이 굴비들처럼 달리길 정말 고대합니다. 따라서 반론은 항상 환영합니다. 모두들 생각이 같다면 무슨 재미로 살겠습니까? 사람들은 각기 생각이 달라야 하며, 그 생각을 자유롭게 표현하고 토론해야 발전이 있는 것이므로 앞으로도 항상 임프님의 반론 기대합니다.
:
: 과거 다른 게시판에 글을 쓸때 반론이라기보다는 악플에 가까운 댓글들을 보고 너무 실망해서 한동안 글쓰는 것을 중지 한적이 있었습니다. 그런데, 임프씨의 글들을 보면 조만간 어떤 주제를 두고 제대로 싸워보고(?) 싶은 생각이 굴뚝 같습니다. 생각 깊은 사람과 토론하면서 싸울 기회는 좀체로 드물기 때문에, 임프씨와 토론하면서 싸울 기회 항상 고대하겠습니다.
:
: 그런데,...
:
: 임프씨의 댓글에서 정확히 내 글에 동의하지 않는 점이 어떤 것인지 잘 이해가 안되는데..
:
: 원래 이번 글의 주제는 "이것저것 다 잘하는 팔방미인 개발자가 되기보다는 하나라도 잘 해라" 였습니다. 어떤 컴 언어를 잘하려면 단순히 문법 뿐만 아니라, 그 언어가 제공하는 기본적 라이브러리( 델파이인 경우 VCL) 또한 매우 잘 숙지해야만  합니다. 컴언어와 일반 언어는 다르지만, 영문법만 달달 외운다고 회화가 되지 않듯이, 어떤 언어를 잘 사용하려면 그언어의 기본 라이브러리 숙지가 매우 중요하다는 것에는 백번 동감하며, 어쩌면 언어 문법 이상으로 기본 라이브러리의 품질이 개발 생산성에 더 영향을 끼친다는 점에도 백번 동감합니다.
:
: 그런데, 개발자의 역할 구분에서 아키텍트와 코더라는 단어를 사용했는데, 내가 제대로 이해한것인지는 모르겠습니다만,  개발에서 아키텍트는 핵심 설계와 주요 라이브러리를 맡는 능동적 존재이며, 코더는 오로지 기계적으로 규정된 방식으로 타이핑만하는 수동적 존재여야 하고, 개발 팀은 이렇게 아키텍트와 코드라는 업무 영역을 따로 둬야 하는 것이라고 생각한다면 여기에는 반대입니다.
:
: 개발팀 내에서 팀원간의 업무 구분에 대해서 지금까지 여러 시도는 해봤지만,  사실 나도 여태껏 제대로 정립해본 바가 없기 때문에, 지금 당장 어떤 의견은 제시할 수 없지만, 로보트같이 일하는 개발자는 매우 좋지 않다고 생각합니다. SF 소설같은 이야기같지만, 로보트같이 일하던 개발자가 미쳐서 폭주하면 문제가 매우 심각하기 때문입니다. 이 로봇개발자들의 코드 품질 수준을 항상 균일하게 유지하는 것이 매우 쉽지 않기 때문입니다.
:
: 개발팀 내의 업무 구분에 대해서 다른 생각이 있다면 또 다른 글을 올려주시고 여기에 대해서 한번 토론해 봅시다. 여기에 대해서 생각은 많지만 사실 나도 뾰족한 방법을 아직 찾아내지 못해서 무지 고민하고 있을 따름입니다.