실용주의이야기(Pragmatic Story)

엔터프라이즈 시스템을 개발하는 프로젝트에서는 업무별로 팀을 나누는게 보통이다. 하지만 업무팀내에서도 어떤 영역을 개발하느냐에 따라 다시 개발자를 구분하기도 한다. 구분하는 방법을 보면 크게 두가지다.

• 수평적 구분(Horizontal approach) : J2EE 시스템이 JSP, Servlet, EJB 세션빈, 엔티티빈으로 구성되어 있다면 팀을 기술별로 특화해서 나누는 방법이다.
• 장점 :
• 모든 팀이  동일한  API를 사용하기 때문에  일관성을 유지하기 쉽다. 패턴이나 프레임워크의 일관성 유지가 용이해 진다.
• 전문가들은  API에 숙달되기 때문에 애플리케이션 개발이 빨라진다.
  
• 단점 :
• 전문가들은 다른 API에 대해 알려고 하지 않기 때문에 레이어 간에 연결이 끊어질수 있다.
• 병렬로 개발하기 위해서는 레이어 간에 확고한 인터페이스를 정의할 필요가 있다.
• 전문가들은 유스케이스에 대한 권한이 없어서 이해도가 부족하며 기술의 일부만 접할수 있기 때문에 기술이 발전이 느리다.
  
• 수직적 구분(Vertical approach) : 특정 비즈니스 유스 케이스에 따라 나누는 것이다. 검색 엔진을 개발하는 팀이나, 제품 카탈로그를 개발하는 팀, 구매 프로세스를 개발하는 팀과 같은 형태로 나누는 것을 말하는데 이렇게 하면 팀원이 모든 기술를 특정 도메인에 대해 적용해 볼수가 있다.
• 장점 :
• 개발 유스케이스 단위로 처음부터 끝까지 개발을 진행할수 있다.
• 유스케이스가 잘 나누어져 있다면 수평적 개발이 용이해진다. 각 개발자들은 자신이 담당하는 유스케이스를 갖게 된다.
• 개발자들은 넓은 범위의 기술을 배울수 있다.
• 개발자들에게 시스템에서 사용되는 다른 기술을 가르치는데 적합하다.
  
• 단점 :
• 일반적으로 기술을 배우는데 시간이나 비용이 필요하다.
• 전문가들이 개발자들을 가르치기 위해 여러 개발자 그룹과 같이 일해야 하기 때문에 부담이 될수 있다.
• 디자인 패턴, 패러다임, 프레임워크가 유스케이스 별로 달라질수 있다.
• 유스케이스가 독립적이면 팀을 나누는게 어렵다.
  

이 두가지 방법을 혼합해서 사용할수도 있다. 두가지 방법 모두 장/단점을 가지고 있기 때문에 이를 적절히 살리는것이 좋다. 그렇다면 어떤 방법이 더 좋은 것일까 ? 그에 대한 대답은 프로젝트에 달려있다.

• 빨리 프로젝트를 완료해야 하며 어느정도 품질을 유지해야 하는경우

경험적으로 수직적 구분과 수평적 구분을 혼합하는게 우수하다고 알려져 있다. 디자인 패턴이나, 프레임워크 같은 부분은 일관성을 유지하기 위해 특정팀이 담당하면서 전문가들이 중요 컴포넌트의 일관성을 유지해야 한다.

• 개발자들을 교육시키는것이 우선인 경우

개발자들이 폭넓은 기술셋을 경험하게 하는데는 수직적 구분이 적당하다고 알려져 있다. 개발자들은 시스템을 개발하는데 필요한 모든 기술을 경험할수 있다. 숙련된 개발자를 찾기 어려운 상황에 고려할수 있는 대안이 된다.

나는 개인적으로 수직적 구분을 선호하는 편이다. 개발자들에게 발전할수 있는 기회를 주어야 한다고 생각하는 편인데 현실적으로 어려울때가 많은게 사실이다. 게다가 더 힘든건 개발자들이 그런  사항을 이해하지 못할 때 이다.
왜 자신이 배워야 하는지를 이해하려 들기 보다는 자신이 했던 방식만을 고집하는 사람들을 만나는 경우가 가끔 있다. 열린 마음이나 열린 사고는 정치인 한테만 필요한건 아니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.