# CTO로서의 역할에 대한 고찰 - v7: 팀 성장 및 지식 공유 체계

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

## v6에서의 깨달음

코드 품질은 중요하다. 하지만 코드를 쓰는 것은 사람이다. 팀이 성장하지 않으면 코드 품질도 올라갈 수 없다.

작은 벤처에서 가장 큰 자산은 사람이다. 정사원 1명, 파트타임 3명, 오프쇼어 2~3명. 이 적은 인원으로 최대 성과를 내려면 **각자가 성장**해야 한다.

그리고 지식이 한 사람에게만 있으면 그 사람이 단일 실패 지점이 된다. 지식을 공유해야 팀이 지속 가능하다.

## 현재 우리 팀의 현실

### 잘하고 있는 것
- AI 기술에 대한 관심과 실험 정신
- 빠른 프로토타이핑 능력
- 유연한 업무 방식

### 부족한 것
- 체계적인 온보딩 프로세스 없음
- 지식이 특정 사람에게 집중
- 학습 시간을 공식적으로 보장하지 않음
- 기술 공유 문화 미약
- 성장 경로가 불명확

## 온보딩 프로세스

새로운 팀원이 빠르게 적응하고 기여할 수 있게 하는 것이 첫 단계다.

### 온보딩 체크리스트

**첫날**:
- [ ] 계정 발급 (GitHub, AWS, Slack, Notion)
- [ ] 개발 환경 셋업 (README.md 따라하기)
- [ ] 팀 소개 및 역할 설명
- [ ] 회사 비전과 제품 이해
- [ ] 첫 커밋 (README 오타 수정이라도)

**첫주**:
- [ ] 문서 읽기 (ARCHITECTURE.md, DEVELOPMENT.md)
- [ ] 코드베이스 훑어보기
- [ ] 간단한 버그 수정 또는 작은 기능 추가
- [ ] 첫 PR 올리고 리뷰 받기
- [ ] 질문 목록 만들어 1:1 미팅

**첫달**:
- [ ] 중간 크기 기능 개발
- [ ] 코드 리뷰 참여
- [ ] 기술 공유 발표 (자기가 배운 것)
- [ ] 온보딩 문서 피드백

### 온보딩 버디 시스템

신규 팀원마다 "버디" 배정:
- 질문 받아주기
- 코드 리뷰 우선 담당
- 주 1회 체크인 미팅
- 첫 달 후 피드백

혼자 헤매지 않게.

## 지식 공유 문화

지식은 나누면 두 배가 된다.

### 주간 기술 공유 (30분)

매주 금요일 오후, 누군가 15분 발표:
- 이번 주 배운 것
- 해결한 버그
- 새로운 도구나 라이브러리
- 실수와 교훈

**규칙**:
- 완벽할 필요 없음 (시행착오도 공유)
- 질문 환영
- 발표 자료는 Notion에 저장

### 사내 Tech Wiki

Notion에 팀 지식 저장소:

```
📚 Tech Wiki
├── 🏗️ 아키텍처
│   ├── 시스템 구조
│   ├── 데이터베이스 설계
│   └── API 설계
├── 🔧 How-to 가이드
│   ├── 환경 설정
│   ├── 배포 방법
│   └── 디버깅 팁
├── 💡 Best Practices
│   ├── 코딩 컨벤션
│   ├── 테스트 작성법
│   └── 보안 체크리스트
├── 🐛 트러블슈팅
│   ├── 자주 나는 에러
│   ├── 성능 이슈 해결
│   └── 과거 장애 기록
└── 📖 학습 자료
    ├── 추천 아티클
    ├── 유용한 도구
    └── 온라인 강의
```

**작성 규칙**:
- 누구나 추가/수정 가능
- 최소 포맷: 문제 - 해결 - 교훈
- 월 1회 오래된 문서 정리

### Pair Programming

복잡한 기능이나 새로운 영역은 둘이서:
- 지식 전달 효과
- 즉각적인 코드 리뷰
- 외로움 감소

주 1회는 페어 프로그래밍 시도.

## 학습 지원 체계

성장을 장려하려면 시간과 자원을 제공해야 한다.

### 공식 학습 시간

매주 금요일 오후 2시간:
- 새로운 기술 학습
- 온라인 강의 수강
- 사이드 프로젝트
- 오픈소스 기여

**조건**:
- 업무와 관련된 것
- 학습 후 팀과 공유
- 분기별 학습 계획 수립

### 학습 예산

1인당 연 50만원:
- 온라인 강의 (Udemy, Coursera, Frontend Masters)
- 책 구매
- 컨퍼런스 참가비
- 유료 도구/서비스

사용 후 간단한 후기 공유.

### 추천 학습 경로

**주니어 → 미들**:
1. 기본기 다지기
   - Clean Code (책)
   - 디자인 패턴
   - 테스트 주도 개발
2. 깊이 더하기
   - 프레임워크 내부 구조
   - 데이터베이스 최적화
   - 보안 기본

**미들 → 시니어**:
1. 넓게 보기
   - 시스템 설계
   - 아키텍처 패턴
   - 성능 최적화
2. 리더십
   - 멘토링
   - 기술 의사결정
   - 프로젝트 관리

## 멘토링 시스템

성장은 혼자 하기 어렵다. 도움이 필요하다.

### 1:1 미팅 (격주)

CTO와 각 팀원 30분:
- 현재 하는 일 점검
- 어려움 공유
- 성장 목표 확인
- 피드백 주고받기

**질문 예시**:
- 이번 주 가장 어려웠던 것은?
- 배우고 싶은 것은?
- 팀에 개선할 점은?
- 도움이 필요한 것은?

### 성장 목표 설정

분기마다 개인 목표 설정:
```markdown
## 2025 Q1 성장 목표 - 김OO

### 기술 목표
- [ ] TypeScript 고급 타입 마스터
- [ ] Jest로 테스트 커버리지 50% 달성
- [ ] AWS 자격증 취득

### 프로젝트 목표
- [ ] 인증 시스템 리팩토링 리드
- [ ] 신규 대시보드 기능 개발

### 소프트 스킬
- [ ] 기술 공유 발표 3회
- [ ] 주니어 멘토링
```

분기 말 회고 및 다음 분기 계획.

## 코드 리뷰를 통한 성장

코드 리뷰는 품질 관리인 동시에 학습 기회다.

### 건설적인 리뷰 문화

**좋은 리뷰 코멘트**:
```
// ❌ 나쁨
"이거 왜 이렇게 짰어요?"

// ✅ 좋음
"이 부분을 함수로 분리하면 재사용성이 높아질 것 같아요.
예를 들어..."
```

**원칙**:
- 코드를 비판하되, 사람을 비판하지 않는다
- 이유를 설명한다
- 대안을 제시한다
- 질문으로 시작한다

### 리뷰에서 배우기

PR을 올리는 사람:
- 왜 이렇게 구현했는지 설명
- 고민한 부분 명시
- 피드백 열린 마음으로 수용

리뷰하는 사람:
- 새로운 패턴 배우기
- 다른 사고방식 이해하기
- 자신도 개선할 점 찾기

## 실패를 환영하는 문화

성장은 실패에서 나온다.

### 포스트모텀 (사후 분석)

장애나 큰 실수 후:
```markdown
## 포스트모텀: 2025-12-10 API 장애

### 무슨 일이?
- 12:30 API 응답 속도 급증
- 14:00 완전 다운
- 14:30 복구

### 원인
- DB 커넥션 풀 고갈
- 슬로우 쿼리 미처리

### 교훈
- 모니터링 알림 설정 필요
- 쿼리 최적화 정기 점검

### 액션 아이템
- [ ] 모니터링 설정 (이번 주)
- [ ] 슬로우 쿼리 로그 분석 (다음 주)
- [ ] DB 인덱스 재설계 (이번 달)
```

**규칙**:
- 누구를 탓하지 않는다 (No blame)
- 시스템 개선에 집중
- 모두가 배운다

### 실험 장려

새로운 것을 시도하다 실패해도 OK:
- 사이드 프로젝트로 실험
- 학습 시간에 POC
- 실패 경험도 공유

"시도했다가 실패" > "시도 안 함"

## 팀 회고 (Retrospective)

한 달에 한 번, 팀 전체 1시간:

### 형식
```
잘한 것 (Keep):
- 코드 리뷰 활성화
- 기술 공유 발표

개선할 것 (Improve):
- 문서화 부족
- 배포 프로세스 느림

시도할 것 (Try):
- 페어 프로그래밍 주 1회
- 점심 기술 토론
```

**규칙**:
- 솔직하게
- 해결책 중심
- 다음 달 액션 아이템 3개

## 실행 계획

**이번 주**:
- ONBOARDING.md 작성
- 1:1 미팅 일정 잡기
- Tech Wiki 구조 만들기

**다음 주**:
- 첫 주간 기술 공유 시작
- 학습 시간 시범 운영

**이번 달**:
- 학습 예산 정책 수립
- 첫 팀 회고 진행
- 온보딩 버디 시스템 도입

## 다음 편 예고

v8에서는 **모니터링 및 장애 대응 체계**를 다룬다:
- 시스템 모니터링 전략
- 알림 설정
- 장애 대응 프로세스
- 온콜 체계

문제를 빨리 발견하고, 빨리 대응하는 것이 핵심이다.

## 마치며

팀은 기술로 성장하지 않는다. 사람이 성장해야 팀이 성장한다.

지식을 독점하지 말고 나누자. 실패를 숨기지 말고 공유하자. 서로 배우고 성장하는 팀이 강한 팀이다.

CTO의 역할은 모든 답을 아는 것이 아니라, 팀이 함께 답을 찾아가게 하는 것이다.

---

**글자 수**: 약 2,200자
**다음 편**: v8 - 모니터링 및 장애 대응 체계