제 생각은 신동승님과 거의 비슷하지만 조금 다릅니다.

저는 개발팀 내에서의 업무 분화는 수평적 분화와 수직적 분화로 구분해서 생각해볼 수 있다고 봅니다. 신동승님이 말씀하신 것들 중 첫번째 방법은 제 생각에서 수평적 분화와 가깝고 두번째 방법은 수직적 분화와 가깝다고 생각됩니다. 완전히 똑같다는 것은 아니고 가깝다..입니다.

수직적 분화란 간단히 말해서 업무의 책임을 직급 등의 구분으로 할당하는 것이고요. 일종의 결재 단계와 비슷하지요. 수평적 분화란 직급 등과 무관하게 업무 단위로 담당자를 나누고 직급과 무관하게 책임이 주어지는 것을 말합니다.

제가 생각하는 아키텍트와 코더(혹은 하급 개발자)의 구분은 수평적 분화와 수직적 분화 양쪽 모두를 고려한 것이지만, 수직적 분화를 우선적으로 생각한 것입니다. 제가 말한 아키텍트는 일반적으로 말하는 PM의 개념과 비슷하지만 기술의 선택과 구현 방법에서 절대적인 권한을 행사해야 한다는 점에서 특정 유형의 PM에만 해당됩니다. 또 아키텍트는 PM과 일치하지 않을 수도 있습니다.

먼저번 글에도 썼듯이, 아키텍트에게 기술의 선택과 구현 방법에 대한 절대적인 권한이 주어져야 한다는 것은 프로젝트의 일정에 대한 예측 가능성을 높이기 위해서입니다. 하급 개발자가 아키텍트로부터 허가받지 않은 알고리즘이나 기술, 컴포넌트 등을 무원칙하게 채용하여 사용할 경우 아키텍트가 예상했던 기간 내에 프로젝트를 완료할 수 있을 가능성이 낮아지게 되는 것은 당연하겠지요.

그러면 아키텍트와 하급 개발자를 직무별로 구분하여 팀을 운영할 경우 과연 허구헌날 날코딩만 반복하던 하급 개발자가 순조롭게 아키텍트로 넘어갈 수 있느냐의 문제가 있을 수 있습니다. 아키텍트는 처음 업무를 시작할 때부터 아키텍트, 하급 개발자는 죽었다 깨나도 코더에 머물러야 한다면 문제가 있지요. 주정섭님께서 우려하는 부분도 이것과 관련이 있을 거 같구요.

제 생각에 현재 업무 개발의 대세를 이루고 있는 자바 프로젝트의 경우 이미 이런 문제점을 겪고 있다고 생각됩니다. 코딩 경험이 많지 않은 사람이 아키텍트나 모델러를 맡는 경우도 있고, 하급 개발자들, 코더들은 경력이 몇년이나 되든 계속 코더로 남아 있는 경우를 종종 봅니다.

이런 문제를 해결하기 위해서는 아키텍트가 적극적으로 고급 기술을 하급 개발자에게 이전하려는 의지를 가져야 할 것입니다. 없는 시간을 쪼개어서라도 싹이 보이는 코더는 아키텍트의 수준으로 끌어올리기 위해 노력을 해야 합니다. 물론 바쁜 업무 와중에 아키텍트와 코더 양쪽 모두 이런 시간을 낼 수 있겠느냐의 의문이 들 수 있지만, 어차피 계속 일정에 쫓기면서 현재 당면한 프로젝트의 구현 자체에만 쫓겨다니다보면 개선이란 있을 수 없습니다. 그리고 무언가 현실의 개선을 위해 당장의 당면 프로젝트 외에 별도로 시간을 내어야 한다는 사실에도 변함이 없습니다.

어차피 현실 개선을 위해 시간을 내어야 한다면, 당장의 당면 과제와 미래 양쪽 모두에 최대한 개선이 될 수 있는 방향이 되어야 하지 않겠습니까. 그러려면 당장의 프로젝트를 위해서는 기술 등 구현에 필요한 스펙의 결정권은 절대적으로 아키텍트의 결정에 맡김으로써 일정의 지연을 막고, 또 한편으로 여유 시간을 만들어 코더를 아키텍트로 양성하도록 노력해야 한다는 것이 제 생각입니다.

그렇다고 모든 코더를 아키텍트로 키울 필요는 없을 것으로 생각됩니다. 의외로 적지 않은 개발자들이 코더의 위치에 만족할 수 있으며, 또 아키텍트의 자리를 노리는 모든 개발자가 아키텍트로서 훌륭하게 성장할 수 있는 자질과 성실함을 갖춘 것은 아닐 것이기 때문입니다.

이러한 모델은 당장의 프로젝트 일정을 맞추기 위해서뿐만 아니라, 전체 개발 업계를 위해 장기적으로도 좋다고 생각됩니다. 우리나라 개발 업계의 가장 큰 문제로 흔히 언급되는 문제인 '40살이 넘은 개발자' 문제도 이런 모델로만이 극복 가능하다고 생각합니다. 또 프로젝트를 성공시키기 위해 적절한 기술과 관행을 하급 개발자가 수없는 시행착오를 거치지 않고 충분한 경험을 가진 선배 아키텍트로부터 배울 수 있기도 하구요.

아키텍트가 분명히 자리를 잡지 못하면, 다시 말해 프로젝트 내에 확고한 아키텍트가 없으면, 프로젝트의 구성원 모두가 아키텍트를 자처하는 상황이 됩니다. 그러면 당장의 프로젝트가 일정 내에 완료되기도 어려울 뿐 아니라 많은 경험을 가진 선배로부터 하급 개발자로의 기술과 경험의 이전도 어렵습니다. 후배 개발자가 충분한 경험도 없으면서 선배 개발자의 풍부한 경험을 무시하는 경우가 종종 일어나는 것도 이와 무관하지 않다고 생각합니다.

또, 하급 개발자와 아키텍트의 업무 구분이 명확하지 않은 경우, 프로젝트가 실패하거나 목표한 만큼 성공하지 못한 경우 하급 개발자와 아키텍트 사이에 서로 상대에게 책임이 있다고 떠넘길 수 있을 것입니다. 문제를 일으킨 원인이 된 당사자가 스스로 자신의 문제를 인식하지 못하면 당연히 개선의 여지도 있을 수가 없습니다.

제가 주정섭님의 의견에 대해 약간의 의견 차이가 있다고 말씀드렸던 것은, 항구적이지는 않더라도 코더의 영역을 만들 수 있고, 어떤 조건 하에서는 그것이 프로젝트의 일정, 그러니까 생산성에 도움이 될 수 있다고 생각하는 것입니다. 또 그 코더들 사이에서는 크지는 않더라도 비교적 유사한 프로그래밍 언어를 오가는 것이 가능할 수 있다고 말씀드린 것이구요. 물론 이미 말씀드렸던 것처럼 그 폭은 그리 크지 않다고 생각하며, 그렇게 '메뚜기질'을 하는 개발자는 아키텍트로 성장할 기회를 가지기 힘들 것입니다.

계속 토론합시다.
토론 must go on~!
^^;;