# CTO로서의 역할에 대한 고찰 - v3: 개발 프로세스 및 협업 방식 정립

> 작성일: 2025-12-10
> 대상: 내부 팀원
> 시리즈: CTO 업무 정립 과정 3/10

## v2에서의 깨달음

문서화는 지식을 보존하는 방법이다. 하지만 문서만으로는 부족하다. 팀이 어떻게 일하는지, 어떻게 협업하는지에 대한 **프로세스**가 필요하다.

프로세스라고 하면 무겁고 관료적인 것을 떠올린다. 하지만 프로세스의 본질은 **예측 가능성**이다. "이런 상황에서는 이렇게 한다"는 약속이 있으면 혼란이 줄어든다.

우리 같은 작은 팀에게 필요한 것은 복잡한 프로세스가 아니다. **최소한의 약속**이다.

## 현재의 문제점

지금 우리 팀의 개발 방식을 솔직하게 보면:

- **Git 브랜치 전략이 없다**: 누구는 main에서 바로 작업하고, 누구는 브랜치를 만든다
- **코드 리뷰가 일관적이지 않다**: 바쁘면 건너뛰고, 여유 있으면 한다
- **배포가 수동적이다**: 누군가 "배포해주세요" 하면 수동으로 한다
- **테스트가 없다**: 손으로 테스트하고 "잘 되네요" 하고 넘어간다
- **커밋 메시지가 제각각이다**: "fix", "update", "asdf" 등등

이런 상태로는 팀이 커질 수 없다. 사람이 늘어나면 혼란만 가중된다.

## Git 브랜치 전략: GitHub Flow

큰 회사에서 쓰는 Git Flow는 우리에게 너무 복잡하다. 우리에게 맞는 것은 **GitHub Flow**다.

### 규칙
1. **main 브랜치는 항상 배포 가능한 상태**
2. **새 작업은 브랜치를 만들어서**
3. **브랜치 이름은 명확하게**: `feature/기능명`, `fix/버그명`
4. **작업이 끝나면 PR**
5. **리뷰 통과 후 main에 머지**
6. **머지 즉시 배포**

### 예시
```bash
# 새 기능 개발
git checkout -b feature/user-authentication
# 작업...
git commit -m "feat: 사용자 인증 기능 추가"
git push origin feature/user-authentication
# PR 생성 → 리뷰 → 머지 → 배포
```

간단하다. 하지만 이것만 지켜도 코드 품질이 올라간다.

## 커밋 메시지 규칙: Conventional Commits

커밋 메시지는 코드의 역사다. "fix"라는 메시지로는 나중에 아무것도 알 수 없다.

### 규칙
```
<타입>: <제목>

<본문> (선택)
```

### 타입
- `feat`: 새 기능
- `fix`: 버그 수정
- `docs`: 문서 수정
- `refactor`: 리팩토링
- `test`: 테스트 추가/수정
- `chore`: 빌드, 설정 등

### 예시
```
feat: 사용자 로그인 API 추가

POST /api/login 엔드포인트 구현
JWT 토큰 발급 로직 추가
```

이렇게 쓰면 나중에 `git log`만 봐도 무슨 일이 있었는지 알 수 있다.

## 코드 리뷰 프로세스

코드 리뷰는 품질 관리의 핵심이다. 하지만 우리는 리소스가 부족하다. 어떻게 효율적으로 할 것인가?

### 기본 원칙
1. **모든 코드는 리뷰를 거친다** (예외 없음)
2. **리뷰는 24시간 내에** (늦어도 다음 근무일 내)
3. **리뷰어는 1명** (작은 팀이므로)
4. **긴급한 경우**: 사후 리뷰 허용

### PR 체크리스트
PR을 올릴 때 작성자가 확인할 것:
- [ ] 로컬에서 테스트 완료
- [ ] 관련 문서 업데이트
- [ ] 커밋 메시지 규칙 준수
- [ ] 스크린샷 첨부 (UI 변경 시)

### 리뷰어가 볼 것
- **기능**: 요구사항 충족하는가?
- **코드 품질**: 읽기 쉬운가? 유지보수 가능한가?
- **버그 가능성**: 엣지 케이스 처리했나?
- **보안**: 취약점은 없나?

## 테스트 전략

"테스트를 다 짜라"고 하면 아무도 안 짠다. 현실적인 전략이 필요하다.

### 우선순위
1. **핵심 비즈니스 로직**: 반드시 테스트
   - 예: 사용자 인증, 결제, 데이터 처리
2. **버그가 자주 나는 부분**: 테스트로 방어
3. **UI**: 수동 테스트 (자동화는 나중에)

### 최소 목표
- **새 기능**: 핵심 로직은 테스트 코드 포함
- **버그 수정**: 재발 방지 테스트 추가
- **리팩토링**: 기존 테스트 깨지지 않게

완벽하지 않아도 된다. 점진적으로 늘려간다.

## 배포 프로세스

수동 배포는 실수의 온상이다. 자동화가 답이지만, 완전 자동화는 시간이 걸린다. 단계적으로 접근한다.

### 1단계: 체크리스트화 (지금)
```markdown
## 배포 전
- [ ] 테스트 통과 확인
- [ ] 스테이징 환경에서 검증
- [ ] DB 마이그레이션 있는지 확인

## 배포
- [ ] git pull origin main
- [ ] npm install (의존성 변경 시)
- [ ] npm run build
- [ ] pm2 restart app

## 배포 후
- [ ] 헬스 체크 (/health 엔드포인트)
- [ ] 로그 확인 (에러 없는지)
- [ ] 핵심 기능 동작 확인
```

### 2단계: 스크립트화 (다음 달)
```bash
#!/bin/bash
# deploy.sh
echo "배포 시작..."
git pull origin main
npm install
npm run build
pm2 restart app
echo "배포 완료. 헬스 체크 해주세요."
```

### 3단계: CI/CD (장기 목표)
GitHub Actions로 main 머지 시 자동 배포

## 협업 도구

프로세스를 지원할 도구도 필요하다.

### 현재 사용
- **Git/GitHub**: 코드 관리
- **Slack**: 커뮤니케이션
- **Notion**: 문서/기획

### 추가 검토
- **Linear/Jira**: 이슈 트래킹 (지금은 GitHub Issues로 충분)
- **Sentry**: 에러 모니터링 (우선순위 높음)

도구는 필요할 때 추가한다. 미리 다 갖출 필요 없다.

## 실행 계획

이번 주부터 단계적으로 도입:

**이번 주**:
- GitHub Flow 규칙 문서화
- 커밋 메시지 규칙 공유
- PR 템플릿 만들기

**다음 주**:
- 코드 리뷰 체크리스트 작성
- 배포 스크립트 작성

**다음 달**:
- 테스트 커버리지 목표 설정
- CI/CD 파이프라인 구축 시작

## 다음 편 예고

v4에서는 **기술 스택 정리 및 아키텍처 문서화**를 다룬다:
- 현재 기술 스택 정리
- 각 기술을 선택한 이유
- 아키텍처 다이어그램
- 기술 부채 목록

기술 스택은 무기 체계다. 어떤 무기를 가지고 있는지, 왜 그 무기를 선택했는지 알아야 한다.

## 마치며

프로세스는 통제가 아니라 자유를 위한 것이다. 명확한 규칙이 있으면 "이거 어떻게 해야 하지?" 고민하는 시간이 줄어든다. 그 시간에 더 중요한 일을 할 수 있다.

다음 주부터 하나씩 적용해보자. 완벽하게 하려고 하지 말고, 일단 시작하고 개선하자.

---

**글자 수**: 약 2,200자
**다음 편**: v4 - 기술 스택 정리 및 아키텍처 문서화