# SSL 증명서 자동화 프로젝트 (1/10): 왜 지금 자동화인가?

## 들어가며

2025년 12월, 우리 조직에 긴급한 과제가 떨어졌다. "SSL 증명서 라이프사이클 자동화 기반 구축". 단순한 운영 개선이 아니라 생존의 문제다. 이 시리즈는 8개월간의 여정을 기술적으로 깊이 있게 다룬다.

## 위기의 시작: 47일의 공포

### CA/Browser Forum SC-081v3 결정사항

2024년, CA/Browser Forum은 SSL/TLS 증명서 유효기간을 단계적으로 단축하는 SC-081v3를 채택했다:

```
현재 (2025년):     398일
2026년 3월 15일:   200일
2027년 3월 15일:   100일
2029년 3월 15일:    47일
```

현재 우리 조직은 약 300개의 인증서를 운영 중이다. 수동으로 갱신하는 현재 방식으로는:
- **2026년**: 연 1.8회 갱신 (300개 × 1.8 = 540회)
- **2027년**: 연 3.6회 갱신 (300개 × 3.6 = 1,080회)
- **2029년**: 연 7.7회 갱신 (300개 × 7.7 = 2,310회)

### 수동 운영의 한계

현재 증명서 갱신 프로세스:
1. 만료 30일 전 알림 이메일 수신
2. CSR(Certificate Signing Request) 수동 생성
3. GlobalSign 웹 콘솔에서 수동 신청
4. 이메일 인증 또는 도메인 검증
5. 발급된 인증서를 서버에 수동 배포
6. 웹서버/로드밸런서 재시작

**1건당 평균 30분 소요**. 2029년에는 연간 1,155시간(약 144 영업일)이 증명서 갱신에만 투입된다.

## 기술적 해결책: ACME 프로토콜

### ACME란?

ACME(Automatic Certificate Management Environment, RFC 8555)는 증명서 발급과 갱신을 자동화하는 프로토콜이다. Let's Encrypt가 대중화했지만, 이제 상용 CA들도 지원한다.

```
┌─────────────┐          ┌──────────────┐          ┌─────────────┐
│ ACME Client │ <─HTTPS─>│ ACME Server  │ <───────>│ Certificate │
│  (자동화)    │          │ (GlobalSign) │          │  Authority  │
└─────────────┘          └──────────────┘          └─────────────┘
       │
       └──> 도메인 검증 (HTTP-01/DNS-01)
       └──> 자동 갱신 스케줄링
       └──> 증명서 배포
```

### GlobalSign Atlas 플랫폼

우리가 사용 중인 GlobalSign은 "Atlas" 플랫폼에서 ACME를 지원한다. 중요한 확인 사항:
- 현재 계약이 Atlas 기반인가? (레거시 플랫폼은 마이그레이션 필요)
- DV(Domain Validation) / OV(Organization Validation) / EV(Extended Validation) 중 어떤 것을 사용하나?
- ACME는 DV에 최적화되어 있고, OV/EV는 추가 프로세스 필요

## 프로젝트 구조와 역할

### 8개월 로드맵

```
Phase 1: 조사 (1개월)
├─ 현재 인증서 인벤토리 분석
├─ GlobalSign 계약 상태 확인
├─ 기술 스택 선정
└─ PoC(Proof of Concept) 구축

Phase 2: 설계·개발 (6개월)
├─ ACME 클라이언트 구현
├─ 증명서 관리 DB 구축
├─ 배포 자동화 파이프라인
├─ 워크플로우 엔진 통합
└─ 모니터링/알림 시스템

Phase 3: 마이그레이션 (1개월)
├─ 단계적 롤아웃
├─ 레거시 프로세스 병행 운영
└─ 최종 전환
```

### 필요 역할과 기술 스택

**PM (Project Manager)**
- 이해관계자 조율 (인프라, 보안, 컴플라이언스팀)
- 리스크 관리 (증명서 만료로 인한 서비스 중단 방지)

**시스템 아키텍트**
- 전체 아키텍처 설계 (마이크로서비스 vs 모놀리식)
- 고가용성(HA) 설계
- 장애 대응 시나리오

**PKI/SSL 전문가**
- 증명서 종류별 적용 전략 (DV/OV/EV, 와일드카드)
- 검증 방식 선정 (HTTP-01 vs DNS-01)
- PQC(Post-Quantum Cryptography) 로드맵

**API 개발자 (핵심 역할)**
- ACME 클라이언트 구현 (Python/Go)
- GlobalSign Atlas API 연동
- 증명서 관리 RESTful API
- 웹훅 기반 이벤트 처리

**인프라 개발자**
- DNS 자동화 (Route53/CloudFlare API)
- 서버 배포 자동화 (Ansible/Terraform)
- 컨테이너/쿠버네티스 통합
- 네트워크 장비 API 연동

## 기술 스택 선정 기준

### ACME 클라이언트 선택지

1. **Certbot** (Python)
   - 장점: 성숙하고 안정적, 플러그인 생태계
   - 단점: 커스터마이징 제한적, 엔터프라이즈 기능 부족

2. **acme.sh** (Shell Script)
   - 장점: 경량, DNS provider 광범위 지원
   - 단점: 복잡한 워크플로우 구현 어려움

3. **커스텀 구현** (Python/Go)
   - 장점: 완전한 제어, 기존 시스템과 긴밀한 통합
   - 단점: 개발/유지보수 비용

**우리의 선택**: 커스텀 구현 (Python + acme 라이브러리)
- 기존 자동화 도구들이 Python 기반
- 증명서 관리 DB와 긴밀한 통합 필요
- 승인 워크플로우 커스터마이징 필수

### 인프라 구성 예시

```yaml
# 예상 기술 스택
ACME Client: Python 3.11+ (acme library)
API Framework: FastAPI
Database: PostgreSQL 15 (증명서 메타데이터)
Message Queue: Redis (배포 작업 큐)
배포 자동화: Ansible
DNS 자동화: boto3 (AWS Route53)
모니터링: Prometheus + Grafana
```

## 추가 고려사항: PQC 대응

NIST가 2024년 8월 양자 컴퓨터 저항 암호 표준을 발표했다. 미국 NSA는 2035년까지 완전 전환을 요구한다.

**자동화의 숨은 이점**: PQC 전환 시 알고리즘 설정만 변경하면 모든 증명서가 자동으로 새 표준으로 갱신된다. 수동 운영에서는 불가능한 민첩성이다.

```python
# 미래의 PQC 전환 (개념적 예시)
CERT_CONFIG = {
    "algorithm": "MLKEM-768",  # 현재는 RSA-2048 또는 ECDSA
    "signature": "MLDSA-87",
    "validity_days": 47
}
```

## 다음 단계

v2에서는 ACME 프로토콜의 동작 원리를 깊이 있게 다룬다:
- ACME 핸드셰이크 프로세스
- JWS(JSON Web Signature) 인증 메커니즘
- Challenge-Response 검증 흐름
- 실제 ACME 클라이언트 구현 시작

---

**시리즈 목차**
1. **[현재글] SSL 증명서 자동화 필요성과 프로젝트 개요**
2. ACME 프로토콜 이해와 동작 원리
3. GlobalSign Atlas ACME 연동 실습
4. 도메인 검증 방식 구현 (HTTP-01, DNS-01)
5. ACME 클라이언트 선정과 커스텀 구현
6. 증명서 관리 DB 설계와 API 구현
7. 증명서 배포 자동화 파이프라인 구축
8. 승인 워크플로우와 거버넌스 구현
9. PQC 대응 설계와 미래 확장성
10. 전체 시스템 통합과 프로덕션 배포 가이드