---
description: 3장 JIRA를 이용한 스크럼과 개발 조직, 코드 리뷰 기법
---

# 3장(2,3) 소프트웨어 팀의 구조, 코드 리뷰

## 2. 소프트웨어 팀의 구조 <a href="#a420fc9a-51f2-4f0b-a089-fbdd0647ac40" id="a420fc9a-51f2-4f0b-a089-fbdd0647ac40"></a>

일반적인 소프트웨어 개발팀의 구조는 소프트웨어를 직접 개발하는 프로젝트 유닛, 전체 프로젝트들을 관리하는 관리조직과 각 개발팀에 공통으로 테스트 등의 지원을 해주는 공통팀과 마지막으로 개발된 시스템을 운영하는 운영팀으로 나눌 수 있다.

### 2.1 프로젝트 유닛 <a href="#id-0ddf2f8b-e529-4f06-9c24-4601dea0559b" id="id-0ddf2f8b-e529-4f06-9c24-4601dea0559b"></a>

`프로젝트 유닛(Project Unit)`은 하나의 시스템을 개발하는 최소 단위이다.

* **프로젝트 매니저(Project Manager)** : 여러 개의 스크럼 팀을 운영하면서 단일 시스템 구현을 관리한다.
* **프로덕트 매니저(Product Manager)** : 고객으로부터 시스템에 대한 요구 사항을 수집하고 시장을 분석하여 시스템에 대한 요구 사항을 정의하고, 우선순위를 정하는 역할을 한다.
* **아키텍트(Architect)** : 전체 시스템에 대한 구조를 설계한다.
* **스크럼 팀(Scrum Team)** : 하나의 프로젝트 유닛은 내부의 서브 시스템이나 컴포넌트 단위에 따라 몇 개의 스크럼 팀으로 나누어진다.
* **스크럼 마스터(Scrum Master)** : 스크럼 마스터는 프로젝트 매니저로부터 받은 요구 사항을 개발원들에게 나눠주고, 관리하는 역할을 한다.
* **개발자(Developer)** : 스크럼 마스터로부터 받은 태스크를 구현한다.
* **테스트(QA)** : 시스템의 특성이나 팀의 구조에 따라서, 해당 스크럼 팀에서 개발된 코드나 기능에 대한 테스트를 수행한다.

### 2.2 관리 조직 <a href="#id-27958728-0555-498c-b319-ff1137efbf42" id="id-27958728-0555-498c-b319-ff1137efbf42"></a>

`프로그램 매니저(Program Manager)`

여러 개의 프로젝트를 동시에 관리하며 개별 프로젝트의 구현보다는 비즈니스 조직과의 커뮤니케이션과 개발 후 서비스에 대한 운영, 고객지원, 판매, UX 등에 대한 전반적인 면을 모두 관리한다.

`수석 프로덕트 매니저(Chief Product Manager, 팀 규모가 클 경우)`

전체 프로덕트 요구 사항에 걸쳐서 전반적인 부분을 관리하는 사람을 치프 프로덕트 매니저라고 한다.

`엔터프라이즈 아키텍트(Enterprise Architect, 팀 규모가 클 경우)`

엔터프라이즈 아키텍트는 전체 시스템에 대한 개념적인 구조와 비즈니스 간에 연결 역할을 하면서 비즈니스와 개발 간의 기술적인 소통 채널이 된다.

### 2.3 공통팀 <a href="#f4491690-5db4-4501-8c41-9bd307fc16ed" id="f4491690-5db4-4501-8c41-9bd307fc16ed"></a>

`공통팀(Shared Unit)`은 개발 기간에 한 팀에 집중되지 않고 중간마다 필요할 때만 사용되므로 자원의 효율성을 위해 전체 팀에 걸쳐 공통된 조직으로 운영하는 것이 좋다.

* **빌드 엔지니어** : 전체적인 빌드 배포를 담당하는 엔지니어이다. CI와 CD 도구를 이용하여 빌드 환경과 테스트 자동화 환경을 구축한다.
* **개발 환경 관리 엔지니어** : 개발환경에 필요한 전반적인 부분을 관리한다.
* **성능 엔지니어** : 시스템 테스트를 위한 부하테스트 작성 및 장애 테스트의 수행, 그리고 병목 구간 발견 및 튜닝에 대한 모든 작업을 수행한다.
* **프로젝트 관리 오피스(PMO)** : 프로젝트 조직이 거대할 경우, 전체 프로젝트를 중앙에서 통제한다.

### 2.4 운영팀 <a href="#id-7b4ed804-8be6-418e-b849-5af6e3e3b610" id="id-7b4ed804-8be6-418e-b849-5af6e3e3b610"></a>

#### 시스템 운영(Technical Operation) <a href="#id-31b6482d-db3e-4d5d-b16a-76a05f97a2cd" id="id-31b6482d-db3e-4d5d-b16a-76a05f97a2cd"></a>

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

* **인프라 엔지니어** : 네트워크 장비, 서버 등 하드웨어 장비에 대한 설치, 설정과 운영을 담당한다.
* **솔루션 엔지니어** : 메시지 큐, MQ, 애플리케이션 서버와 같은 미들웨어를 운영한다.
* **DBA** : 데이터베이스 운영자

#### 서비스 운영(Service Operation) <a href="#d3a45002-f1f5-4c31-82e7-e180c40de435" id="d3a45002-f1f5-4c31-82e7-e180c40de435"></a>

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

* **관리자(Admin)** : 서비스에 대한 관리를 한다.
* **고객지원(Support)** : 기술지원이나 고객 불만 접수와 같은 고객 지원 서비스를 담당한다.

## 3. 코드 리뷰 <a href="#id-516a4591-c991-4f00-8823-bd113e9c4c36" id="id-516a4591-c991-4f00-8823-bd113e9c4c36"></a>

`코드 리뷰`란 코드를 실행하지 않고 사람이 검토하는 과정을 통하여 코드에 숨어 있는 잠재적인 결함을 찾아내고 이를 개선하는 일련의 과정을 정의한다.

### 3.1 코드 리뷰 스펙트럼 <a href="#id-5c060d25-391e-4182-a4c1-21baaebd7c91" id="id-5c060d25-391e-4182-a4c1-21baaebd7c91"></a>

정형성에 따라 대표적인 리뷰 방법을 나열해보면 다음과 같다.

**손쉬운 방법** ← 피어리뷰 ← 패스 어라운드 ← 팀 리뷰 → 워크스루 → 코드 인스펙션

### 3.2 코드 인스펙션 <a href="#id-72c7c2aa-4544-4b6d-a125-1f79be1d8997" id="id-72c7c2aa-4544-4b6d-a125-1f79be1d8997"></a>

전문화된 코드 리뷰팀이 시스템이 어느 정도 구현된 단계에서 일정한 패턴을 가지고 코드를 분석한다. 인스펙션 팀은 크게 4가지 역할을 가지고 구성된다.

`중재자(Moderator)`

중재자는 인스펙션팀과 그 대상이 되는 코드를 작성한 개발팀 간의 인터페이스를 담당하고 필요한 리소스와 인프라를 확보하는 작업을 한다. 인스펙션이 언제 끝날 것인지 종료 조건을 정의한다.

`리더(Leader)`

리더는 전체 시스템을이해하여 인스펙션 팀이 어떤 흐름으로 인스펙션을 진행할지에 대한 방향을 제시한다.

`디자이너와 코더(Designer/Coder)`

디자이너가 지시한 방향에 따라서 코드를 검증하고 잠재적인 결함을 발견 및 권장 수정 방안을 만들어낸다.

`테스터(Tester)`

테스터는 인스펙션이 진행 중인 모듈에 대해서 테스트를 수행하고 결함을 찾아내는 역할을 수행한다.

인스펙션은 다음 6단계로 진행된다.

`계획` : 기간,대상,종료 조건,팀 구성 → `오버뷰(Overview)` : 시스템 교육, 팀원 역할 정의 → `준비` : 도구, 환경 구축. 문서 이해와 인터뷰 → `인스펙션` → `재작업` : 결함 수정 → `후처리(Follow-up)` : 결함 수정 확인

### 3.3 팀 리뷰 <a href="#id-672f699b-112c-4ecb-ac92-0e586f9083fc" id="id-672f699b-112c-4ecb-ac92-0e586f9083fc"></a>

리뷰 시간에 `발표자(Author,코드를 만든 사람)`가 코드에 대해 설명하고 팀원은 결함이나 개선안을 찾는다. `중재자`는 리뷰의 주제를 선정하여 리뷰를 진행하고 리뷰에서 나온 의견을 정리하여 액션 아이템으로 기록한다. 액션 아이템들은 프로젝트 매니저가 실제 프로젝트 태스크로 관리해야 한다.

### 3.4 워크 스루 <a href="#id-4f575661-9da1-45f8-8a28-51c54c29af4e" id="id-4f575661-9da1-45f8-8a28-51c54c29af4e"></a>

`워크 스루(Workthrough)`는 단체로 하는 코드 리뷰 기법 중에서 가장 비정형적인 방법이다. 발표자가 리뷰의 주제와 시간을 정해서 발표를 하고 동료로부터 의견이나 아이디어를 듣는 시간을 갖는다.

### 3.5 피어 리뷰 또는 오버 더 숄더 리뷰 <a href="#id-40055171-00f1-4424-847c-7b6a355970c9" id="id-40055171-00f1-4424-847c-7b6a355970c9"></a>

`피어 리뷰`나 `오버 더 숄더 리뷰`는 2\~3명이 진행하는 코드 리뷰 형태다. 코드의 작성자가 모니터를 보면서 코드를 설명하고 다른 한 사람이 설명을 들으면서 아이디어를 제안하거나 결함을 발견하는 방법이다.

### 3.6 패스어라운드 <a href="#a285678d-7361-4277-a78d-b064a2411913" id="a285678d-7361-4277-a78d-b064a2411913"></a>

`패스어라운드(Passaround)` 리뷰는 작성자가 리뷰를 할 부분을 메일이나 시스템을 통해서 등록하면 참석자들이 메일을 통해서 각자의 의견을 개진하는 방식이다.
