# CTO로서의 역할에 대한 고찰 - v8: 모니터링 및 장애 대응 체계

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

## v7에서의 깨달음

팀이 성장하면 더 좋은 시스템을 만들 수 있다. 하지만 아무리 좋은 시스템도 문제는 생긴다. 중요한 것은 **문제를 얼마나 빨리 발견하고 대응하느냐**다.

사용자가 "서비스 안 되는데요?"라고 연락하기 전에 우리가 먼저 알아야 한다. 그것이 모니터링이다.

## 현재 우리의 모니터링 현실

솔직히 말하자:
- 시스템이 살아있는지 어떻게 아는가? → 사용자 피드백
- 에러가 나는지 어떻게 아는가? → 사용자가 말해줌
- 성능이 느린지 어떻게 아는가? → 느껴질 때까지 모름
- 언제 장애가 났었는가? → 기억에 의존

이건 문제다. 수동적이고 반응적이다. 능동적이고 예방적이어야 한다.

## 모니터링의 레벨

모니터링에는 단계가 있다.

### Level 0: 아무것도 없음 (현재)
- 사용자가 알려줌
- 로그는 있지만 안 봄
- 뭔가 이상하면 그때 확인

### Level 1: 기본 모니터링 (3개월 목표)
- 서버 살아있는지 확인 (Uptime)
- 치명적 에러 알림
- 일일 리포트

### Level 2: 상세 모니터링 (6개월 목표)
- 응답 시간 추적
- 에러율 추적
- 리소스 사용량 (CPU, 메모리, 디스크)
- 사용자 행동 분석

### Level 3: 예측적 모니터링 (장기 목표)
- 이상 패턴 감지
- 장애 예측
- 자동 복구

먼저 Level 1부터 달성하자.

## 무엇을 모니터링할 것인가?

모든 것을 모니터링할 수는 없다. 중요한 것부터.

### 1. 가용성 (Availability)
**질문**: 서비스가 살아있나?

**모니터링**:
- HTTP 헬스체크 (/health 엔드포인트)
- 빈도: 1분마다
- 기준: 200 OK 응답

**도구**: UptimeRobot (무료) 또는 AWS CloudWatch

### 2. 성능 (Performance)
**질문**: 서비스가 빠른가?

**모니터링**:
- API 응답 시간
- 페이지 로딩 시간
- 데이터베이스 쿼리 시간

**기준**:
- API 응답: 95%ile < 500ms
- 페이지 로딩: 3초 이내
- DB 쿼리: 100ms 이내

**도구**: New Relic 또는 Datadog

### 3. 에러 (Errors)
**질문**: 에러가 나고 있나?

**모니터링**:
- 서버 에러 (5xx)
- 클라이언트 에러 (4xx)
- 애플리케이션 예외
- 에러율 (전체 요청 대비)

**기준**:
- 에러율 < 1%
- 치명적 에러 즉시 알림

**도구**: Sentry (에러 트래킹)

### 4. 리소스 (Resources)
**질문**: 서버가 과부하인가?

**모니터링**:
- CPU 사용률
- 메모리 사용률
- 디스크 공간
- 네트워크 트래픽

**기준**:
- CPU > 80% 경고
- 메모리 > 85% 경고
- 디스크 > 90% 긴급

**도구**: AWS CloudWatch

### 5. 비즈니스 메트릭 (Business)
**질문**: 비즈니스가 잘 되고 있나?

**모니터링**:
- 회원가입 수
- 사업계획서 생성 수
- 결제 성공률
- 활성 사용자 수

**기준**:
- 평소 대비 50% 이상 감소 시 확인

**도구**: Google Analytics + 자체 대시보드

## 알림 전략

모니터링만 하고 알림이 없으면 소용없다.

### 알림 레벨

**P0 - 긴급**: 서비스 다운, 데이터 손실
- 수단: Slack + 이메일 + SMS
- 대상: CTO + 온콜 담당자
- 대응: 즉시

**P1 - 높음**: 성능 저하, 높은 에러율
- 수단: Slack + 이메일
- 대상: 개발팀 전체
- 대응: 1시간 내

**P2 - 중간**: 경고 임계값 초과
- 수단: Slack
- 대상: 관련 담당자
- 대응: 당일 내

**P3 - 낮음**: 정보성 알림
- 수단: 이메일
- 대상: CTO
- 대응: 주간 리뷰

### 알림 피로 방지

너무 많은 알림은 무시하게 된다.

**규칙**:
1. 중요한 것만 알림
2. 반복 알림 묶기 (5분 내 같은 에러는 1번만)
3. 업무 시간 외에는 P0만 알림
4. 거짓 양성 줄이기 (임계값 조정)

## 대시보드

한눈에 볼 수 있어야 한다.

### 실시간 대시보드
```
┌─────────────────────────────────────┐
│ PlanitAI System Health Dashboard    │
├─────────────────────────────────────┤
│ Status: 🟢 All Systems Operational  │
├─────────────────────────────────────┤
│ API Response Time: 245ms (🟢)       │
│ Error Rate: 0.3% (🟢)               │
│ CPU Usage: 45% (🟢)                 │
│ Memory: 60% (🟢)                    │
├─────────────────────────────────────┤
│ Active Users: 42                     │
│ Today's Signups: 8                   │
│ Plans Generated: 23                  │
└─────────────────────────────────────┘
```

**도구**: Grafana (무료 오픈소스)

### 일일 리포트

매일 아침 9시 Slack에:
```
📊 어제의 시스템 리포트 (2025-12-10)

✅ 가동시간: 100% (0건의 다운타임)
⚡ 평균 응답시간: 230ms
🐛 에러: 12건 (0.5%, 모두 4xx)
👥 활성 사용자: 156명
📝 생성된 계획서: 89개

📌 주목할 점:
- 오후 2시 API 응답 시간 급증 (조사 필요)
```

## 장애 대응 프로세스

장애는 반드시 일어난다. 중요한 것은 대응이다.

### 장애 레벨 정의

**Level 1 - Critical**: 서비스 전체 다운
- 영향: 모든 사용자
- 목표 복구: 1시간

**Level 2 - Major**: 주요 기능 장애
- 영향: 대부분 사용자
- 목표 복구: 4시간

**Level 3 - Minor**: 부분적 문제
- 영향: 일부 사용자
- 목표 복구: 24시간

### 대응 절차

```markdown
## 장애 발생 시

### 1단계: 인지 (0-5분)
- [ ] 알림 확인
- [ ] 장애 레벨 판단
- [ ] 팀 소집 (Slack에서)

### 2단계: 초기 대응 (5-15분)
- [ ] 사용자 공지 (상태 페이지)
- [ ] 로그 확인
- [ ] 최근 변경사항 확인 (배포 이력)

### 3단계: 조사 및 임시 조치 (15-60분)
- [ ] 원인 파악
- [ ] 임시 해결 (롤백, 트래픽 우회 등)
- [ ] 진행상황 업데이트

### 4단계: 근본 해결 (1-4시간)
- [ ] 완전한 수정
- [ ] 테스트
- [ ] 배포
- [ ] 검증

### 5단계: 사후 조치 (24시간 내)
- [ ] 사용자 공지 (복구 완료)
- [ ] 포스트모텀 작성
- [ ] 재발 방지 계획
```

### 온콜 체계

누가 대응할 것인가?

**현재**: CTO가 항상 대응 (지속 불가능)
**목표**: 온콜 로테이션

```
Week 1: CTO
Week 2: 개발자 A
Week 3: 개발자 B
Week 4: CTO
```

**온콜 담당자**:
- P0/P1 알림 받음
- 1시간 내 대응 (최소 상황 파악)
- 대응 불가 시 에스컬레이션

**보상**:
- 온콜 수당
- 실제 대응 시 시간 보상

## 로그 관리

로그는 디버깅의 핵심이다.

### 로그 레벨
```
ERROR: 즉시 대응 필요
WARN: 주의 필요
INFO: 정보성 (정상 동작)
DEBUG: 개발 시에만
```

### 로그에 포함할 것
```typescript
logger.error('Payment failed', {
  userId: user.id,
  orderId: order.id,
  amount: order.amount,
  errorCode: error.code,
  timestamp: new Date().toISOString(),
  requestId: req.id  // 추적용
});
```

### 로그 저장
- 기간: 90일
- 위치: AWS CloudWatch Logs
- 검색 가능하게

## 모니터링 도구 스택

현실적인 선택:

### 1단계 (무료/저렴)
- **Uptime**: UptimeRobot
- **에러**: Sentry (무료 티어)
- **로그**: AWS CloudWatch
- **대시보드**: Grafana Cloud (무료)

### 2단계 (성장 후)
- **APM**: New Relic 또는 Datadog
- **로그 분석**: ELK Stack
- **분산 추적**: Jaeger

처음부터 비싼 도구 쓸 필요 없다.

## 실행 계획

**이번 주**:
- [ ] /health 엔드포인트 추가
- [ ] UptimeRobot 설정
- [ ] Sentry 통합

**다음 주**:
- [ ] CloudWatch 대시보드 구성
- [ ] 기본 알림 룰 설정
- [ ] 장애 대응 문서 작성

**이번 달**:
- [ ] Grafana 대시보드 구축
- [ ] 첫 장애 대응 훈련
- [ ] 일일 리포트 자동화

## 다음 편 예고

v9에서는 **기술 로드맵 및 의사결정 프레임워크**를 다룬다:
- 기술 전략 수립
- 신기술 도입 판단 기준
- 기술 부채 vs 신규 기능
- 장기 비전

어디로 가야 할지 방향을 정해야 한다.

## 마치며

"모니터링 없는 시스템은 깜깜이 운전"이라는 말이 있다. 맞는 말이다.

완벽한 모니터링은 없다. 하지만 아무것도 없는 것보다는 기본이라도 있는 게 낫다.

이번 주부터 시작하자. 먼저 /health 엔드포인트부터.

---

**글자 수**: 약 2,250자
**다음 편**: v9 - 기술 로드맵 및 의사결정 프레임워크