핵심: 인프라를 코드로 재현하고, 변경 사항을 검사한 뒤 팀의 리뷰를 거쳐 반영한다.
한눈에 보는 흐름
왜 배웠는가?
조원이 각자 콘솔을 수정하면 같은 환경을 재현하거나 변경 이유를 추적하기 어렵다. 인프라 구성과 코드 변경을 반복 가능한 과정으로 만들기 위해 학습했다.
핵심 개념
- IaC: 서버·네트워크 같은 인프라 구성을 코드로 관리하는 방식.
- Terraform plan / apply: 바뀔 내용을 미리 확인 / 실제 환경에 반영.
- state: Terraform이 어떤 실제 리소스를 관리하는지 기록한 파일.
- import: 이미 존재하는 리소스를 Terraform 관리 대상으로 등록.
- bootstrap: 이후 자동화를 시작하는 데 필요한 기반을 먼저 준비하는 작업.
- CI: 코드가 바뀔 때 품질·보안 검사를 자동으로 실행하는 과정.
- OIDC: GitHub Actions가 임시 인증을 받아 AWS 역할을 사용하는 데 활용한 방식.
실제 기록 1 · 기반을 만들기 전에 기반을 쓰려 했다
bootstrap 글에서는 원격 state 저장소가 준비되기 전에 그것을 사용하려 해서 작업이 막혔다. 저장소를 먼저 만든 뒤 연결하는 순서를 정리했다.
또한 IAM 설명에 적은 한글 때문에 apply에서 오류가 난 경험을 남겼다. 코드 문법이 맞아도 AWS가 받지 않는 값이 있을 수 있다는 점을 배웠다.
실제 기록 2 · 검사 실패를 Merge 차단으로 연결했다
양혜민·김태형·이재원의 CI 실습에는 Ruff, mypy, pytest, pip-audit, Semgrep, Gitleaks를 연결한 과정이 있다.
이재원은 처음에 검사가 실패해도 Merge 버튼은 활성화되어 있었고, 브랜치 보호와 필수 검사 설정 후에는 실패한 PR의 Merge가 막혔다고 기록했다.
검사 → 실패 시 Merge 차단 → 문제 수정 → 재검사가 하나의 흐름이 된 것이다.
검사 목적과 도구
무엇을 확인하는가? | 실습 도구 |
코드 스타일·일부 위험한 코드 | Ruff |
타입이 맞는지 | mypy |
기능이 예상대로 작동하는지 | pytest |
사용하는 패키지에 알려진 취약점이 있는지 | pip-audit |
취약한 코드 패턴이 있는지 | Semgrep |
키·토큰 같은 비밀값이 섞였는지 | Gitleaks |
프로젝트에 적용한 학습
Wazuh·ALB·실습용 EC2의 Terraform 구성 글에는 Trivy로 설정을 점검한 과정도 있다. 검사 결과를 검토하면서 실습을 위해 의도한 설정과 줄여야 할 위험을 구분하는 기준도 함께 고민했다.
배운 점
자동 실행 자체보다 문제가 있는 변경이 실제 환경까지 들어가지 못하게 하는 조건이 중요하다. CI의 AWS 권한과 외부 PR 처리 범위도 함께 검토해야 한다.
원문과 작성자
- Github Action 실습 — 양혜민
- 【AWS】 공격 환경 구성하기 — 김태형
- Github actions 실습 — 이재원
