CI/CD가 왜 필요한가 — 배포를 사람의 기억에서 시스템으로 옮긴다
수동 배포는 담당자가 서버에 접속해 파일을 복사하고 서비스를 재시작하는 과정을 매번 반복합니다. 이 방식은 빠르게 시작할 수 있지만 버전 추적, 동일 절차 재현, 테스트 누락, 롤백 속도에서 위험이 커집니다. CI/CD의 목표는 “자동화 자체”가 아니라 같은 입력이면 같은 검증과 배포 절차가 반복되는 상태를 만드는 것입니다.
코드를 통합할 때 테스트·정적 검사·빌드가 반복 가능하게 성공하는지 확인합니다.
검증된 결과물을 개발·스테이징·운영 환경으로 동일한 규칙에 따라 전달하고 검증합니다.
CI/CD를 AWS 용어 없이 먼저 보면
처음에는 서비스 이름을 외우지 말고 소스코드 → 검사 → 배포파일 → 서버 반영 → 정상 확인이라는 다섯 단계만 잡으면 됩니다. AWS 서비스는 이 단계를 자동으로 실행하도록 도와주는 도구입니다.
| 쉬운 말 | 자주 쓰는 말 | 뜻 |
|---|---|---|
| 소스코드가 바뀜 | Source / Commit | 어떤 코드 버전을 배포할지 정합니다. |
| 테스트하고 빌드함 | Build / CI | 코드가 깨지지 않았는지 검사하고 실행 가능한 결과물을 만듭니다. |
| 만들어진 배포파일 | Artifact | JAR·ZIP처럼 실제 서버에 전달할 결과물입니다. |
| 배포할 한 버전 | Revision | 어떤 Artifact와 설정을 배포하는지 식별하는 단위입니다. |
| 배포 중 실행할 단계 | Lifecycle Hook | 서비스 중지, 파일 설치, 재기동, 정상 확인처럼 배포 순서마다 실행하는 작업입니다. |
| 다음 단계로 넘어가도 되는지 확인 | Gate | 테스트·승인·Health Check가 통과해야 배포를 계속하게 만드는 문입니다. |
CodePipeline은 순서를 연결하고, CodeBuild는 검사·빌드하고, CodeDeploy는 서버에 반영합니다. Artifact는 그 과정에서 전달되는 “배포할 물건”입니다.
CodePipeline — 각 단계를 연결하는 오케스트레이터
CodePipeline은 Source, Build, Test, Approval, Deploy 같은 Action을 Stage로 연결합니다. 자체적으로 애플리케이션을 빌드하는 서비스라기보다 각 도구를 순서대로 실행하고 결과를 다음 단계로 넘기는 역할에 가깝습니다.
| Stage | 대표 서비스 | 완료 조건 |
|---|---|---|
| Source | GitHub via GitHub App / CodeConnections | 배포할 Commit과 Artifact 식별 |
| Build | CodeBuild | 테스트·빌드 PASS, Artifact 생성 |
| Gate | 자동 Test 또는 Manual Approval | 환경별 승인 조건 충족 |
| Deploy | CodeDeploy 등 | 대상 환경에 Revision 반영 |
| Verify | CloudWatch / Smoke Test | Health·오류율·핵심 기능 확인 |
CodePipeline은 GitHub App 기반 연결을 권장하며 Repository Access 범위를 지정해 사용할 수 있습니다. 개인 OAuth Token을 장기간 보관하는 기존 방식보다 연결 주체와 Repository 권한 관리가 명확합니다.
CodeBuild — 테스트와 빌드를 깨끗한 환경에서 재현한다
CodeBuild는 관리형 빌드 환경에서 명령을 실행하고 결과 Artifact를 만듭니다. 일반적으로 프로젝트 루트의 buildspec.yml에 Phase와 Artifact 규칙을 정의합니다.
| buildspec 영역 | 역할 | Spring Boot 예시 |
|---|---|---|
| version | Buildspec 문법 버전 | 0.2 사용 |
| install | Runtime·도구 준비 | Java Runtime |
| pre_build | 빌드 전 검증 | 환경 확인, 사전 검사 |
| build | 핵심 빌드 명령 | ./gradlew test bootJar |
| post_build | 빌드 후 처리 | 결과 확인·메타데이터 생성 |
| artifacts | 다음 Stage로 전달할 파일 | JAR, appspec.yml, scripts |
테스트가 실패했는데 JAR만 만들어졌다는 이유로 Deploy Stage로 넘어가면 CI의 의미가 사라집니다. 테스트 명령이 실패하면 CodeBuild도 실패하도록 구성합니다.
Artifact는 “무엇을 배포했는지”의 증거
운영 배포 후에는 어떤 Commit에서 어떤 Artifact가 만들어졌는지 역추적할 수 있어야 합니다. Artifact 이름이나 배포 메타데이터에 Commit SHA, Build ID 같은 식별자를 연결하면 장애 시 배포 버전을 빠르게 확인할 수 있습니다.
CodeDeploy — In-place와 Blue/Green을 정확히 구분한다
EC2/On-Premises 기준 CodeDeploy의 큰 배포 타입은 In-place와 Blue/Green 두 가지입니다. 기존 문서에서 “Rolling”을 별도 배포 타입처럼 이해하면 혼동하기 쉽습니다. In-place 안에서 여러 인스턴스에 얼마씩 배포할지는 Deployment Configuration으로 제어합니다.
| 구분 | In-place | Blue/Green |
|---|---|---|
| 대상 | 기존 Instance Group | Replacement Environment |
| 동작 | 기존 Instance에 새 Revision 설치 | 새 환경에 배포 후 트래픽 전환 |
| 롤백 | 이전 Revision 재배포 필요 | 기존 환경 유지 시 트래픽 복귀가 쉬움 |
| 자원 | 추가 자원 부담이 상대적으로 작음 | 전환 동안 두 환경이 필요할 수 있음 |
In-place 배포 속도는 Deployment Configuration으로 조절
| 기본 Configuration | 의미 |
|---|---|
| OneAtATime | 한 번에 한 Instance씩 배포 |
| HalfAtATime | 최대 절반씩 배포 |
| AllAtOnce | 가능한 대상에 한 번에 배포 |
Instance를 Load Balancer에서 제외하고 배포·검증한 뒤 다시 서비스에 넣는 흐름을 구성하면 단일 Instance 재시작보다 사용자 영향도를 줄일 수 있습니다.
AppSpec — 파일 복사보다 Lifecycle Hook이 중요하다
EC2/On-Premises용 appspec.yml은 배포할 파일과 Lifecycle Event에서 실행할 Script를 정의합니다. 핵심은 “새 JAR을 어디에 복사할까?”보다 각 Hook이 실패했을 때 배포가 멈추고 검증 가능한 구조를 만드는 것입니다.
| Lifecycle | 대표 작업 | 실패 시 의미 |
|---|---|---|
| ApplicationStop | 기존 Process 종료 | 정상 종료 실패 여부 확인 |
| BeforeInstall | 디렉터리·백업 준비 | 설치 전 상태 불량 |
| AfterInstall | 권한·파일 배치·설정 | Artifact 설치 실패 |
| ApplicationStart | 새 Version 기동 | Process 시작 실패 |
| ValidateService | Health / Smoke Test | 서비스 준비 실패 |
Validate 단계에서 실제 Health Endpoint, 의존성 연결, 핵심 API 응답을 확인해야 “기동은 됐지만 서비스는 불가능한” 배포를 걸러낼 수 있습니다.
설정과 Secret — Parameter Store와 Secrets Manager 역할을 나눈다
배포 자동화가 잘 되어도 비밀번호와 API Key가 Repository나 Build Log에 노출되면 안 됩니다. 일반 설정과 Secret의 Lifecycle을 구분해 저장소를 선택합니다.
AWS도 자동 Rotation, Cross-Account Access, 세밀한 감사가 필요한 Credential과 Secret에는 Secrets Manager를 권장합니다. Parameter Store의 SecureString은 Rotation이 필요 없는 경량 암호화 설정에 더 적합합니다.
Session Manager — SSH 포트 없이 운영 접속
Session Manager를 사용하면 Instance에 Inbound SSH 포트를 열거나 Bastion Host를 운영하지 않고도 관리 Session을 시작할 수 있습니다. IAM으로 접근을 통제하고 AWS API 활동을 CloudTrail에서 추적할 수 있습니다.
CloudTrail은 StartSession 같은 Systems Manager API 활동을 기록합니다. 사용자가 Session에서 실제로 입력한 Command와 Output을 남기려면 Session Manager Preferences에서 S3 또는 CloudWatch Logs Session Logging을 별도로 설정해야 합니다.
암호화된 터널 내부의 Session Data는 일반 대화형 Session과 같은 방식으로 기록되지 않을 수 있으므로 감사 요건이 있으면 연결 방식을 포함해 설계해야 합니다.
운영 배포 Gate와 Rollback — 자동화의 마지막 20%
CI/CD가 “push하면 바로 운영 배포”를 의미하지는 않습니다. 운영 위험에 따라 자동 Gate와 사람 승인 Gate를 조합하고, 실패했을 때 되돌릴 방법까지 Pipeline의 일부로 설계합니다.
| 단계 | Gate 예시 | 실패 시 |
|---|---|---|
| Source | 보호 Branch, Review 완료 | Pipeline 시작 안 함 |
| Build | Unit Test, Static Check | Artifact 생성 중단 |
| Staging | Smoke / Integration Test | 운영 승격 중단 |
| Production | 필요 시 Manual Approval | 대기 또는 취소 |
| Post Deploy | Health, 5XX, Latency | Rollback 판단 |