소프트웨어 개발팀의 구조

서비스 개발팀의 구조

 

시스템 개발 및 운영에 있어서, 팀의 구조는 매우 중요하다. 효율적인 의사 소통과 협업은 이 팀 구조에 많은 영향을 받는데, 지금까지 여러가지 팀 구조에 대한 레퍼런스가 존재해왔다. 개인적으로 느끼는 생각은, 사실 정답은 없다는 것이다. 비지니스나 팀의 특성, 문화적 특성에 따라서 그 팀 구조는 매우 상이하다. 지금까지 수천명이 들어가는 은행 차세대 프로젝트에서 부터 4~5명으로 구성된 프로젝트 팀, 50명 규모의 프로젝트 팀등 다양한 팀 구조를 경험하거나 직접 셋업 및 운영해왔다. 경험상 보면 보편적으로 많이 사용되는 팀 구조 모델이 있기는 마련인데, 여기서는 지금까지 프로젝트를 해오면서 가장 적절했다고 생각하는 팀 구조에 대해서 소개 하고자 한다. (참고, 이 팀의 구조는 개발과 운영이 분리된 전통적인 서비스 팀 구조이다. http://bcho.tistory.com/721 모델에서 2. 성숙된 팀구조 정도에 해당하며, Devops 기반의 팀 구조에는 해당 하지 않는다.)

  

 

 

Project Unit

Project Unit은 하나의 시스템을 개발하는 최소의 단위이다.

Ÿ   Project Manager : 여러 개의 스크럼 팀을 운영 하면서, 단일 시스템을 구현을 관리 한다. Product Manager와 협업하여, 요구 사항을 각 스크럼팀에 분배하고 관리한다.

Ÿ   Product Manager : 고객으로 부터 시스템에 대한 요구 사항을 수집 하고, 시장을 분석하여 시스템에 대한 요구 사항을 정의하고, 우선 순위를 정하는 역할을 한다. 사용자 관점에서 상세한 흐름과 상세한 요구 사항을 정의한다.

Ÿ   Architect : 전체 시스템에 대한 구조를 설계한다. 필요에 따라서는 기술 선택 및 코드를 통한 프로토타입핑 작업까지 진행한ㄴ다.

Ÿ   Scrum Team

하나의 프로젝트 Unit은 내부의 서브 시스템이나 컴포넌트 단위에 따라서 몇 개의 스크럼팀으로 나뉘어진다. 하나의 스크럼팀은 Scrum Master를 포함하여 4~7명 정도가 적당하다. 이 스크럼팀의 운영에는 유연성을 발휘해야 하는데, 일의 성격이나 팀의 규모에 따라서 한 명의 Scrum Master가 동시에 2~3개의 Scrum Team을 관리할 수 도 있다.

-        Scrum Master : Scrum Master는 Product manager로 부터 받은 요구 사항을 개발원들에게 나눠주고, 관리하는 역할을 한다. 해당 스크럼팀의 구현 Task를 분배하고 관리하는 역할을 한다.

-        Developers : Scrum Master로 부터 받은 Task를 구현한다. 팀의 형태에 따라서 구현 부분에 대한 단위 테스트 (Unit Test)를 직접 구현한다.

-        QA : 시스템의 특성이나 팀의 구조에 따라서, 해당 스크럼 팀에서 개발된 코드나 기능에 대한 테스트를 수행한다. 각 스크럼팀에 테스터를 배치하는 방법도 있지만, 리소스 상황에 따라서 전체 프로젝트 팀에 대한 공통 QA를 배치해서 운영 할 수 도 있다.

Management board

Ÿ   Program manager : Program manager의 경우에는 하나의 프로젝트 조직을 운영하더라도 필수적으로 필요하다. 또는 Project Manager가 Program manager를 겸임할 수 있다.여러개의 프로젝트를 동시에 관리하며, 개별 Project의 구현 보다는 비지니스 조직과의 커뮤니케이션과 개발 후 서비스에 대한 운영, 고객 지원, 판매, UX 등에 대한 전반적인 면을 총 아울러서 관리한다.

Ÿ   Chief Product Manager(Optional-팀규모가 클경우) : 팀 규모가 클 경우, 개별 Product manager 만으로는 전체 Product의 컨셉이 일관성을 잃을 수 있다. 그래서 전체 Product 요구 사항에 걸쳐서 전반적인 부분을 관리하는 사람을 Chief Product Manager라고 한다. 개별 Product manager가 개별 Product에 집중한다면, Chief Product Manager는 이 Product으로 구성된 Portpolio를 관리 하는 역할을 한다.

Ÿ   Enterprise Architect(Optional-팀규모가 클경우) : 시스템의 구조가 커지게 되면 각 개별 프로젝트 팀에 있는 아키텍트로만은 전체 시스템을 그릴 수 없다. 각 프로젝트 팀의 아키텍트가 건물을 그린다면, Enterprise Architect는 전체 도시를 설계하는 개념으로 보면 된다. 프로젝트 유닛의 아키텍트가 기술 지향적이고, 프로토타입핑등 디테일한 설계에 집중한다면, Enterprise Architect는 전체 시스템에 대한 Conceptual한 구조와, 비지니스간에 연계 역할을 하면서, 비지니스와 개발간의 기술적인 소통 채널이 된다.

 

* Program manager와 Project manager의 차이

Project manager는 시스템의 구현 자체에만 포커스를 맞춘다. 주로 테크니컬한 관점에서 프로젝트의 범위와 스케쥴 그리고 리소스를 관리하는 관점이다.

Program manager는 구현을 포함한 운영 및 비지니스와의 관계까지 전반적인 서비스에 대한 부분을 넓게 아우르며, 구현이나 테크니컬한 관점 보다는 외부와의 관계, 비지니스, 사람에 포커스를 맞추며, 외부와의 소통, 정치 그리고 협상(요구사항이나 범위, 리소스)등에 포커싱이 되어 있다.

또 Project manager가 구현단계에만 투입 된다고 보면, Program manager는 전체 프로젝트 기획 단계에서 부터, 개발, 개발 종료후의 운영까지 전반적인 과정을 관리 한다.

전체적인 범위로 보자면 Program manager가 Project manager 보다 더 넓은 범위를 포함한다고 폴 수 있다.

 

Shared Unit

Shared Unit은 개발 기간중에, 한 팀에 집중되서 사용되지 않고, 중간중간 필요한 때만 사용되기 때문에, 자원의 효율성을 위해서, 전체 팀에 걸쳐서 공통된 조직으로 운용하는 것이 좋으며, 이를 통해서 전체 팀에 대한 표준화를 지원할 수 있다.

Ÿ   Build : 전체적인 빌드 배포를 담당하는 엔지니어이다. maven 등의 빌드 스크립트와, fabric등의 배포 자동화 툴을 이용하며, Jenkins와 같은 CI도구를 이용한 빌드 환경과 테스트 자동화 환경을 구축한다.

Ÿ   Development environment management : 개발환경에 필요한 전반적인 부분을 관리한다. git와 같은 VCS 툴에서 부터, JIRA와 같은 Task management, 위키와 같은 협업 도구, 문서 관리 도구등 개발 인프라 관리를 담당하며, 역할을 확장할 경우, VM 기반의 개발 환경 구축, 표준 개발 VM 이미지 (Tomcat, MySQL등이 이미 설치되어 있는) 개발 및 관리. Eclipse와 같은 IDE에 대한 표준화등의 역할을 수행한다. 조직의 규모에 따라서 Build 엔지니어의 역할을 겸임할 수 도 있다.

필요에 따라 개발 서버 세팅 및 개발 서버에 인스톨되는 각종 서버 소프트웨어에 대한 설정을 관리한다.

Ÿ   Performance Engineering : 스크럼팀의 QA 엔지니어 역할이 단위테스트라면, Performance Engineer는 전체 시스템에 대한 통합 테스트 (Integration Test)와 System 테스트에 집중한다. 특히 System Test를 위한 부하테스트 작성 및 장애 테스트의 수행. 그리고 병목 구간 발견 및 튜닝에 대한 모든 작업을 수행한다. 성능 테스트에 대한 깊은 이해와 함께, 튜닝을 위한 지식과 솔루션,애플리케이션에 대한 모든 지식을 겸비해야 한다. (rockstar)

Ÿ   Project Management Office (PMO) : 프로젝트 조직이 거대할 경우, 전체 프로젝트를 중앙에서 컨트롤 한다. 각 프로젝트의 진행 상황을 모니터링 하고, Risk에 대한 관리를 진행하며, 특히 각 릴리즈 일정을 관리한다. 이 외에도 Staff성 업무를 지원하는데, 예산 책정 및 관리, 집행. 외부 업체와의 아웃소싱,컨설팅, 제품 구매 계약. 필요에 따라 법률 검토등의 행정적인 작업을 지원한다.

Operation

시스템 릴리즈 후에, 운영을 담당한다. 보통 운영을 생각하면, 하드웨어나 소프트웨어를 운영하는 시스템 운영만을 생각 하는 경우가 많은데, 서비스를 운영하기 위한 고객 대응까지 포함한 모든 운영을 포함한다.

Technical Operation (시스템 운영)

흔히 Tech Ops 또는 시스템 운영이라고 이야기 하는 분야로, 구현된 하드웨어 및 소프트웨어를 포함한 시스템에 대한 운영을 담당한다.Tech Ops는 시스템의 설치, Configuration, Setup 및 배포와 같이 설치에 대한 전체 프로세스 뿐만 아니라 시스템에 대한 모니터링 및 장애(Incident) 처리까지의 시스템에 대한 기술적인 운영에 대한 전반적인 부분을 담당한다.

-    인프라 엔지니어 : 인프라 엔지니어는 네트워크 장비, 서버 등 하드웨어 장비에 대한 설치,설정 및 운영을 담당한다.

-    솔루션 엔지니어 : 솔루션 엔지니어는, 메세지 큐, MQ, Application Server와 같은 미들웨어에 대한 운영을 한다.

-    DBA(Data Base Administrator) : 다른 미들웨어 시스템도 중요하기는 하지만 데이타베이스의 경우 분야도 비교적 더 넓고, 전문성도 높게 필요하기 때문에 일반적으로 데이타베이스 운영자는 별도로 분리 하는 경우가 많다.

이 Tech Ops에서는 24시간 7일 운영을 하는 것을 24x7 운영이라고 하고, 운영팀을 지리적으로 분리해서 24x7을 지원하는 것을 FTS (Follow the Sun : 해를 따라서 지원)이라고 한다. 팀 A,B,C가 8시간씩 시스템을 운영 및 모니터링 해야 하기 때문에, 여러 대륙에 걸쳐서 팀을 셋업한다.

그리고 근무 시간이 끝난 후에,다음 팀에게 운영을 넘기는 것을 hand over라고 하는데, 어떤 장애가 났는지 자세한 장애의 원인과 상태 진행 상황등을 전달해서 지속적인 운영 하는 절차이다. (일종의 수문장 교대식?). 이 과정에서 적절한 프로세스와 hand over에 대한 문서 템플릿을 구축하는 것이 중요하다.

아울러, 장애 대응이 중요한다. 조직이 아주 크다면 모르겠지만 특정 솔루션에 대해서 장애가 났을때, 전문성이 있는 엔지니어가 있는 팀이 운영을 하고 있지 않다면, 장애에 대한 대응이 불가능하다. 그래서, 장애 발생시 문제 해결이 안되면 전문성을 가지고 있는 사람에게 일을 넘길 수 있는 escalation 프로세스가 필요하다.

시스템에 대한 기술적인 운영은 기술적인 전문성을 갖추는 것도 중요하지만, 더 중요한 것은 적절한 프로세스를 갖춰서, 운영 자체가 물이 흐르듯이 잘 흘러가도록 만드는 것이다.

Service Operation (서비스 운영)

서비스 운영은 구축된 서비스에 대한 운영을 담당한다. 시스템에 대한 기술적인면을 배제한 부분을 포함한다.

-    관리자 (Admin) : 서비스에 대한 관리를 한다. 예를 들어 게시판 관리자나, 포탈 시스템의 관리자 등 시스템에 대한 기술적인 운영이 아닌 비지니스 관점의 운영을 담당한다.

-    고객 지원 (Support) : 기술지원이나 고객 불만 접수와 같은 고객 지원 서비스를 담당한다.

이외에도, 유료화 서비스의 경우에는 빌링이나 정산을 하는 팀. 게임에서는 불법 사용자를 처리하는 사람이나, 서비스에 대한 이벤트 마케팅을 하는 것도 운영의 범주로 볼 수 있다.

 

시스템 개발 및 운영에 있어서, 팀의 구조는 매우 중요하다. 효율적인 의사 소통과 협업은 이 팀 구조에 많은 영향을 받는데, 지금까지 여러가지 팀 구조에 대한 레퍼런스가 존재해왔다. 개인적으로 느끼는 생각은, 사실 정답은 없다는 것이다. 비지니스나 팀의 특성, 문화적 특성에 따라서 그 팀 구조는 매우 상이하다. 지금까지 수천명이 들어가는 은행 차세대 프로젝트에서 부터 4~5명으로 구성된 프로젝트 팀, 50명 규모의 프로젝트 팀등 다양한 팀 구조를 경험하거나 직접 셋업 및 운영해왔다. 경험상 보면 보편적으로 많이 사용되는 팀 구조 모델이 있기는 마련인데, 여기서는 지금까지 프로젝트를 해오면서 가장 적절했다고 생각하는 팀 구조에 대해서 소개 하고자 한다.