Step 11. 전체 파이프라인 완성 확인 + 실습 회고
이 문서는 인프라 파이프라인 실습의 마지막 파일이다. 돌아가기: 09-hands-on.md
용어 안내
이 문서에서 “슬롯”은 학습용 비유다. 실무 용어가 아니다. 각 슬롯 옆에 실무에서 실제로 쓰는 용어를 병기한다.
왜 전체 파이프라인을 한 번에 돌려봐야 하는가? (WHY)
지금까지 각 단계를 하나씩 만들었다. 하지만 실무에서는 코드 한 줄 수정 → 사용자에게 전달까지 모든 단계가 자동으로 연결되어야 한다. 각 단계가 개별로 작동하는 것과 전체가 이어져서 작동하는 것은 다른 문제다.
비유: 자동차 부품(엔진, 바퀴, 브레이크)을 각각 테스트하는 것과, 조립된 차를 실제로 도로에서 달려보는 것은 다르다.
전체 흐름 다이어그램
코드 수정 → git push → CI 자동 실행 → 이미지 빌드 → 레지스트리 push
↓
curl로 확인 ← docker compose up ← docker compose pullPipeline (파이프라인)
- 영어 뜻: “배관, 파이프를 연결한 관로” — 물이 한 방향으로 흐르는 관
- IT 뜻: 코드 변경부터 배포까지 자동으로 이어지는 작업 흐름
- 비유: 공장 컨베이어 벨트. 원료(코드)를 넣으면 완제품(배포)이 자동으로 나온다
11-1. 코드 수정 → 자동 배포까지 직접 해보기
① 코드 수정
// app.js 파일에서 버전만 변경한다
// 기존: "1.0.0" → 변경: "1.1.0"
const APP_VERSION = "1.1.0"; // 이 한 줄만 바꾼다② Git에 올리기
git add app.js # 변경한 파일을 스테이징 영역에 추가
git commit -m "bump version to 1.1.0" # 변경 이유를 메시지로 남기며 커밋
git push origin main # GitHub 원격 저장소에 업로드③ CI가 자동으로 실행된다 (GitHub Actions)
push하면 GitHub Actions가 자동으로 아래를 수행한다:
1. 테스트 실행 ← npm test로 코드가 정상인지 확인
2. Docker 이미지 빌드 ← Dockerfile 기반으로 새 이미지 생성
3. ghcr.io에 push ← 빌드된 이미지를 레지스트리에 업로드
4. Trivy 스캔 ← 이미지에 보안 취약점이 있는지 검사GitHub 저장소 → Actions 탭에서 실행 상태를 확인할 수 있다.
④ 로컬에서 새 이미지 가져오기
docker compose pull # 레지스트리에서 최신 이미지를 다운로드⑤ 새 버전 배포
docker compose up -d # 새 이미지로 컨테이너를 재시작 (-d: 백그라운드)⑥ 배포 확인
curl localhost/health # Nginx를 통해 앱의 헬스체크 엔드포인트 호출
# 응답 예시: {"status":"ok","version":"1.1.0"} ← 버전이 바뀌었는지 확인
docker logs my-infra-app-1 --tail 20 # 앱 컨테이너의 최근 로그 20줄 확인
# 요청 기록, 에러 여부 등을 로그로 확인한다슬롯 회고 — 내가 직접 만든 것들
이 실습에서 만든 것 하나하나가 인프라의 어떤 역할을 담당하는지 정리한다. “슬롯”은 학습용 비유이며, 실무 용어를 함께 표기한다.
| 이 실습에서 만든 것 | 슬롯 (학습용) | 실무 용어 |
|---|---|---|
| GitHub 저장소 | ① Version Control | 소스 관리 (SCM) |
| GitHub Actions CI | ② Build/Test | CI 파이프라인 |
| ghcr.io 이미지 push | ③ Artifact Storage | 컨테이너 레지스트리 |
| 수동 pull & up | ④ Deploy/Release | CD 파이프라인 (실무: ArgoCD 등으로 자동화) |
| Docker Compose | ⑤ Orchestration | 컨테이너 오케스트레이션 (프로덕션: K8s) |
| .env 파일 | ⑨ Secrets/Config | 시크릿 관리 (실무: Vault 등) |
| Nginx 리버스 프록시 | ⑧ Networking | 리버스 프록시 / 로드밸런서 |
| 로그 미들웨어 | ⑩ Observability | 모니터링 / 옵저버빌리티 |
| HEALTHCHECK + restart | ⑤ Orchestration 심화 | 헬스체크 / 자동 복구 |
| Trivy 스캔 | ⑫ Security Scanning | 보안 스캔 |
로컬에서 체험 못 한 역할들
모든 인프라 역할을 로컬에서 체험할 수는 없다. 아래는 왜 로컬에서 불가능한지, 그리고 실무에서는 어떻게 하는지 정리한 것이다.
| 슬롯 (학습용) | 왜 로컬에서 못 하는가 | 실무에서는 어떻게 하는가 |
|---|---|---|
| ⑥ Provisioning | 서버를 “만드는” 건 클라우드가 있어야 가능 | Terraform으로 AWS EC2/RDS 등을 코드로 생성 |
| ⑦ Configuration | 원격 서버 안에 소프트웨어를 설치하는 것 | Ansible로 서버 세팅 자동화 |
| ④ Deploy 자동화 | 이 실습에서는 수동으로 pull & up 했음 | ArgoCD/Flux가 Git 변화를 감지해 자동 배포 |
| ⑪ Alerting | 알림을 보낼 대상(팀/온콜)이 없음 | PagerDuty/Alertmanager로 자동 알림 |
| ⑬ Identity/Access | 로컬은 혼자 쓰므로 권한 관리가 불필요 | AWS IAM/K8s RBAC로 권한 관리 |
| ⑭ Backup/DR | 로컬 데이터는 날려도 상관없음 | RDS 스냅샷, Velero로 정기 백업 |
Provisioning (프로비저닝)
- 영어 뜻: “준비, 공급” — 필요한 것을 미리 마련해두는 것
- IT 뜻: 서버, 네트워크 같은 인프라 자원을 생성하고 준비하는 것
- 비유: 식당 오픈 전에 건물을 짓고, 주방을 설치하는 것
다음 단계 — 클라우드로 확장하고 싶다면
이 실습으로 인프라의 기본 구조를 이해했다. 더 나아가고 싶다면 아래 순서를 추천한다.
- AWS Free Tier로 EC2 띄우기 — 클라우드 서버에 docker compose를 올려 실행해본다 (⑥ Provisioning 체험)
- Terraform으로 EC2를 코드로 생성 — 콘솔 클릭 대신 코드 한 줄로 서버를 만들어본다
- GitHub Actions에서 SSH로 자동 배포 — push하면 서버에 자동으로 배포되게 만든다 (④ Deploy 자동화)
- Kubernetes 입문 — Docker Compose의 프로덕션 버전을 체험한다 (⑤ 프로덕션급 Orchestration)
최종 체크리스트
이 실습을 통해 아래를 모두 할 수 있는지 스스로 점검한다.
□ git push 한 번으로 CI가 자동 실행된다
□ Docker 이미지가 자동으로 레지스트리에 올라간다
□ docker compose로 앱+Redis+Nginx를 한 번에 띄울 수 있다
□ .env로 설정값을 코드 밖에서 관리한다
□ Nginx가 80 포트로 들어온 요청을 앱으로 전달한다
□ docker logs로 요청 기록을 볼 수 있다
□ 컨테이너가 죽으면 자동으로 다시 살아난다
□ Trivy가 이미지 취약점을 검사한다
□ 14개 인프라 역할 중 어떤 것을 체험했고 어떤 것이 남았는지 안다마무리
이 실습을 완료했다면, phase-07의 다른 문서(Docker, CI/CD, Cloud 등)를 읽을 때 **“아, 그때 직접 해봤던 그것”**이라는 경험이 연결되어 훨씬 빠르게 이해된다.
이론만으로는 “왜 이게 필요하지?” 하고 넘어가던 개념들이, 직접 손으로 만들어본 뒤에는 구체적인 기억으로 남는다.
→ 09-hands-on.md로 돌아가기
Comments
// admin login