<aside>
☁️ 클라우드웨이브 · W07 · 주간 허브 · 예상 읽기 5분
</aside>
이번 주에는 인프라를 코드로 표현하는 데서 멈추지 않고, 여러 사람이 안전하게 변경하고 애플리케이션 배포와 운영 보안까지 연결하는 흐름을 정리했다. 첫날에는 웹 서버 클러스터와 로드 밸런서의 요청 경로를 그려 보며 Terraform 상태가 왜 공유되고 잠겨야 하는지 살폈다. 둘째 날에는 모듈과 반복 표현식을 통해 같은 설계를 재사용하는 방법을 익혔다. 셋째 날에는 GitLab CI/CD와 Jenkins Pipeline을 IaC 검증, 이미지 산출물, 배포 승인과 연결했다. 넷째 날에는 프레젠테이션·애플리케이션·데이터 계층을 분리하고 확장과 장애 복구를 관측 가능한 운영 문제로 바라보았다. 마지막 날에는 공동 책임 모델, 최소 권한, 감사 로그, 네트워크 제어와 WAF를 사고 대응의 준비로 묶었다.
프로젝트 맥락은 특정 구현을 복사하는 대신, 지연시간·폭주 트래픽·확장성·보안·가용성·비용을 함께 요구사항으로 바꾸는 추상적인 다리로만 참고했다. 결국 좋은 인프라 코드는 자원을 만드는 문법보다 변경의 경계, 검토의 증거, 실패했을 때 되돌아갈 경로를 명확히 하는 설계에 가깝다는 결론에 도달했다.
가장 크게 달라진 점은 도구를 따로 외우지 않고 하나의 운영 흐름으로 보기 시작했다는 것이다. Terraform은 프로비저닝과 상태를 담당하고, Ansible은 이미 존재하는 호스트의 구성을 맞춘다. CI/CD는 두 작업을 실행 가능한 검증 단계로 묶으며, 관측성과 보안은 배포 뒤에 덧붙이는 장식이 아니라 설계 입력이다. 특히 무중단이라는 표현도 자동 보장이 아니라 용량, 헬스 체크, 연결 드레이닝, 데이터 호환성까지 확인해야 하는 조건부 목표라는 점을 기억하게 됐다.
다음에는 작은 샌드박스 환경에서 상태 백업과 복구 리허설, 모듈 변경의 호환성 검사, 파이프라인 승인 규칙, 알림 기반 장애 훈련을 이어 가고 싶다. 숫자를 임의로 정하기보다 서비스의 SLO와 비용 한도를 먼저 정하고, 각 단계가 어떤 증거를 남기는지 문서화하는 방식으로 학습을 확장할 계획이다.