17장. 배포 자동화 연결

15장에서 앱 배포를 자동화했고, 16장에서 인프라를 코드(Terraform)로 만들었습니다. 이번 장은 손을 많이 움직이기보다, 지금까지 만든 조각들을 한 걸음 떨어져서 바라보며 "전체 그림"을 완성하는 시간입니다. 짧지만 중요합니다. 이 그림이 곧 실무에서 팀이 일하는 방식 그 자체이기 때문입니다.

[지금 여기]

우리는 22단계를 거쳐 "라이브 투표 서비스"를 만들고, 컨테이너에 담아, AWS에 배포하고, 실무처럼 운영하는 여정을 걷고 있습니다. 지금은 17단계, 지금까지 만든 자동화 조각들을 하나의 흐름으로 잇는 자리입니다.

1. 1장개발 환경 준비 (터미널 / Node.js / Git / GitHub / VS Code / Claude Code)
2. 2장Claude Code 사용법 익히기
3. 3장무엇을 만들지 기획 (라이브 투표 서비스)
4. 4장로컬에서 서비스 만들기 (React + Express + PostgreSQL)
5. 5장Docker 개념
6. 6장Dockerfile 작성
7. 7장컨테이너 빌드·실행
8. 8장AWS 시작 (계정 / IAM / 리전 / 비용)
9. 9장이미지 태깅
10. 10장ECR에 이미지 올리기
11. 11장VPC 네트워크 구성
12. 12장RDS 데이터베이스 생성
13. 13장SSM 터널로 RDS 초기화
14. 14장ECS Fargate + ALB로 배포 (기본 완성)
15. 15장CI/CD (GitHub Actions)
16. 16장IaC (Terraform)
17. 17장배포 자동화 연결
18. 18장현업 운영 구조 이해
19. 19장무중단 배포
20. 20장신규 버전 배포 & 롤백
21. 21장(심화) 프론트를 Vercel로 분리 배포
22. 22장마무리 (회고 + 리소스 삭제)

• 방금 끝낸 것: 16장에서 인프라를 Terraform 코드(infra/ 폴더)로 옮기고, terraform plan으로 "무엇이 바뀔지 미리 보기"까지 해 봤습니다.
• 이번 장에서 하는 것: 앱 파이프라인(15장 CI/CD)과 인프라 파이프라인(16장 Terraform)을 하나의 큰 흐름으로 잇습니다. 그리고 인프라 변경도 앱 코드처럼 PR(풀 리퀘스트)과 코드 리뷰로 관리하는 실무 방식을 배우고, 아주 작은 PR을 직접 한 번 만들어 봅니다.

이번 장에서 완성되는 것

한 문장으로: "코드를 수정하면 사용자에게 닿기까지" 전체 길을 하나의 그림으로 그릴 수 있게 되고, 인프라 변경을 PR로 올려 검토받는 흐름을 직접 경험합니다.

이렇게 되면 성공입니다: 내 GitHub 저장소에서 작은 변경 하나를 브랜치로 올려 PR을 만들고, 바뀐 내용(diff)을 눈으로 확인한 뒤, 내가 직접 그 PR을 합쳐(merge) 봅니다. 그리고 "앱 파이프라인과 인프라 파이프라인이 무엇이 다른지", "코드 수정 → 사용자 접속까지의 경로"를 말로 설명할 수 있습니다.

사전 조건

이 장은 지금까지 만든 것을 조망하는 장이라, 앞 장들의 결과물이 갖춰져 있어야 이야기가 이어집니다. 아래를 먼저 확인하세요.

• 1~14장 완료: 라이브 투표 서비스가 AWS(ECS + ALB + RDS)에 배포되어, ALB 기본 DNS 주소로 접속되는 상태.
• 15장 완료: GitHub에 코드를 올리면 GitHub Actions가 자동으로 빌드·배포하는 CI/CD 워크플로(.github/workflows/ 안의 파일)가 있는 상태.
• 16장 완료: 인프라가 Terraform 코드(vote-app/infra/ 폴더의 .tf 파일들)로 정의되어 있고, terraform plan을 실행해 본 상태.
• GitHub 저장소: 1장·15장에서 만든 우리 프로젝트의 프라이빗 저장소가 GitHub에 올라가 있고, 브라우저에서 로그인된 상태.

17.1 두 개의 파이프라인 — 앱과 인프라

우리 프로젝트에는 이제 성격이 다른 두 종류의 코드가 있습니다.

• 앱 코드 (vote-app/frontend/, vote-app/backend/): 서비스의 기능 그 자체. 화면, 투표 로직 같은 것들입니다. 자주 바뀝니다.
• 인프라 코드 (vote-app/infra/): 서비스가 올라가는 무대. VPC, RDS, ECS 같은 것들을 Terraform으로 정의한 파일입니다. 가끔 바뀝니다.

그리고 각각에 자동화가 하나씩 붙어 있습니다. 이 자동화 한 벌을 "파이프라인"이라고 부릅니다.

• 왼쪽(앱 파이프라인): 15장에서 완성했습니다. frontend/나 backend/가 바뀌어 GitHub에 올라오면 → GitHub Actions가 → 이미지를 빌드해 ECR에 올리고 → ECS 서비스를 새 이미지로 갱신합니다.
• 오른쪽(인프라 파이프라인): 16장에서 terraform plan까지 손으로 해 봤습니다. 실무에서는 이 오른쪽도 GitHub Actions로 자동화합니다. "infra/ 폴더가 바뀌면 terraform plan을 자동으로 실행하고, 사람이 승인하면 terraform apply한다"는 워크플로를 붙이는 식입니다. 원리는 15장에서 배운 것과 완전히 같으므로, 여기서는 흐름만 이해하고 넘어갑니다.

17.2 새 개념 — PR과 코드 리뷰

인프라가 코드가 되면서 얻은 가장 큰 것은, 인프라 변경을 "코드 리뷰"라는 안전장치 위에 올릴 수 있다는 점입니다. 이 절에서 그 두 축인 PR과 코드 리뷰가 무엇인지부터 차근차근 짚겠습니다.

(1) 개념 — PR과 코드 리뷰가 무엇인가

그동안 우리는 코드를 고치면 곧바로 main(우리 프로젝트의 대표 저장 줄기)에 올렸습니다. 혼자 하는 연습이라 그래도 괜찮았죠. 그런데 여러 명이 같은 저장소를 만지거나, 실수하면 서비스가 멈추는 중요한 코드라면, "바로 올리기"는 위험합니다. 누군가 한 번 봐 주고, 문제가 없을 때만 합쳐지는 관문이 필요합니다. 그 관문이 PR입니다.

한 문장으로 정리하면, PR은 "합쳐 달라는 요청서"이고, 코드 리뷰는 "그 요청서를 동료가 검토하는 일"입니다. 이 둘이 짝을 이뤄, 검토받지 않은 코드가 함부로 main에 들어가지 못하게 막습니다.

(2) 활용 사례 — 실무에서 PR과 리뷰를 왜 쓰나 (여러 예)

PR과 코드 리뷰는 우리 프로젝트만의 이야기가 아닙니다. 소프트웨어를 여럿이 만드는 거의 모든 팀이 이 방식을 씁니다. 대표적인 쓰임새를 봅시다.

• 협업 리뷰로 실수를 미리 잡는다. 한 개발자가 "DB 접속 정보를 코드에 그대로 적어 버린" PR을 올리면, 리뷰하던 동료가 "이건 비밀값이니 코드에 넣으면 안 된다"고 지적해 배포 전에 막습니다. 혼자였다면 그대로 나갔을 실수를, 두 번째 눈이 걸러 줍니다.
• 변경 이력과 토론을 기록으로 남긴다. "왜 이 포트를 열었지?", "왜 이 라이브러리를 골랐지?" 같은 의문이 나중에 생겼을 때, PR에 남은 설명과 댓글을 보면 그 당시의 판단 근거를 그대로 되짚을 수 있습니다. 코드는 "무엇을 했는가"만 보여주지만, PR은 "왜 그렇게 했는가"까지 남깁니다.
• 승인 게이트(관문)로 아무나 함부로 못 바꾸게 한다. 오픈소스 프로젝트를 생각해 봅시다. 전 세계 누구나 코드를 고쳐 PR을 올릴 수 있지만, 실제로 합쳐지려면 그 프로젝트 관리자의 승인을 받아야 합니다. 회사에서도 "리뷰어 1명 이상이 승인해야만 main에 합쳐진다"는 규칙을 걸어, 검토 안 된 코드가 배포되는 것을 원천 차단합니다.
• 자동 검사와 묶어 이중으로 거른다. PR을 올리면 사람이 리뷰하기 전에, 자동 테스트나 (인프라라면) terraform plan 같은 검사가 먼저 돌아 결과를 PR에 붙여 줍니다. 기계가 한 번, 사람이 한 번 — 두 겹으로 걸러지는 셈입니다.

(3) 맛보기 — 아주 작은 PR을 직접 만들어 보기

말로만 들으면 감이 안 오니, 우리 프로젝트와 분리해서 아주 작은 PR을 한 번 직접 만들어 봅시다. 여럿이 아니라 혼자여도 괜찮습니다. 내가 올리고 내가 검토하고 내가 합쳐 보면, PR이 어떻게 생겼는지 손으로 알게 됩니다. 코드가 아니라 설명 파일(README) 한 줄만 고칠 거라, 서비스에는 아무 영향이 없습니다.

이 실습은 터미널이 아니라 웹브라우저의 GitHub 화면에서 합니다.

1. 웹브라우저에서 https://github.com 에 로그인한 뒤, 우리 프로젝트 저장소로 들어갑니다. (오른쪽 위 내 프로필 아이콘 → Your repositories(내 저장소) → 목록에서 우리 투표 프로젝트 저장소 클릭.)
2. 저장소 첫 화면의 파일 목록에서 README.md 파일을 클릭해 엽니다.
   • [참고] README 파일이 없다면, 파일 목록 위쪽의 Add file(파일 추가) → Create new file(새 파일 만들기)을 눌러 파일 이름을 README.md로 하고 아무 내용이나 한 줄 적은 뒤 진행해도 됩니다.
3. 파일 오른쪽 위의 연필 모양 아이콘(Edit this file, 이 파일 편집)을 클릭합니다. 편집 화면으로 바뀝니다.
4. 내용 맨 아래에 아무 줄이나 하나 추가합니다. 예: PR 연습용 한 줄 추가 라고 적습니다.
5. 오른쪽 위의 Commit changes…(변경 커밋) 버튼을 누릅니다. 작은 창이 뜹니다.
6. 이 창 아래쪽에 두 개의 선택지가 있습니다. 여기서 두 번째 선택지인 Create a new branch for this commit and start a pull request(이 커밋을 위한 새 브랜치를 만들고 풀 리퀘스트를 시작한다)를 고릅니다.
   • 그 아래 브랜치 이름 입력칸에 이미 patch-1 같은 이름이 자동으로 들어가 있습니다. 그대로 두면 됩니다.
   • [주의] 첫 번째 선택지(Commit directly to the main branch, main에 바로 커밋)를 고르면 PR 없이 곧장 합쳐져 버립니다. 우리는 PR을 경험하는 게 목적이니, 반드시 두 번째를 고르세요.
7. Propose changes(변경 제안) 버튼을 누릅니다. GitHub가 "브랜치의 내용과 main을 비교하는" 화면(Open a pull request, 풀 리퀘스트 열기)으로 데려갑니다.
8. 제목과 설명을 적는 칸이 보입니다. 제목은 자동으로 채워져 있으니 그대로 두거나, 설명칸에 "PR이 어떻게 생겼는지 연습" 정도로 한 줄 적습니다. 그리고 Create pull request(풀 리퀘스트 만들기) 버튼을 누릅니다.
9. 여기가 핵심입니다. 방금 만들어진 PR 화면에서 위쪽 Files changed(바뀐 파일) 탭을 눌러 보세요. 내가 추가한 한 줄이 초록색으로 표시됩니다. 이것이 바로 리뷰어가 보는 화면입니다. 무엇이 어떻게 바뀌는지가 한눈에 보입니다.
   • [참고] 실무라면 여기서 동료가 이 초록 줄 옆에 댓글을 달아 리뷰합니다. 지금은 혼자 하니, 눈으로 확인하는 것으로 리뷰를 대신합니다.
10. 이제 이 PR을 합쳐 봅시다. Conversation(대화) 탭으로 돌아가, 아래쪽의 Merge pull request(풀 리퀘스트 합치기) 버튼을 누르고, 이어서 Confirm merge(합치기 확인)를 누릅니다.
11. "Pull request successfully merged and closed(성공적으로 합쳐지고 닫힘)"가 보이면, 나타나는 Delete branch(브랜치 삭제) 버튼을 눌러 연습용 브랜치를 정리합니다.

방금 여러분은 PR의 한살이 전체를 직접 겪었습니다. 브랜치에서 고치기 → PR 올리기 → 바뀐 내용 확인 → 합치기. 실무의 인프라 변경도 정확히 이 흐름을 탑니다.

(4) 우리 프로젝트 — 인프라 변경을 PR로 관리한다

이제 이 흐름을 우리 투표 서비스의 인프라에 대입해 봅시다. 실무에서 "DB 앞을 지키는 보안 그룹 규칙을 하나 바꿔야 하는" 상황을 상상해 보겠습니다.

콘솔 시절(2부에서 하던 방식): 담당자가 AWS 콘솔에 들어가 보안 그룹 규칙을 조용히 클릭해 바꿉니다. 아무도 모르고, 기록도 안 남고, 실수해도 알아챌 사람이 없습니다. 나중에 "이 규칙 누가 왜 열었지?"를 물어도 답할 길이 없습니다.

IaC 시절(16장 이후, 이제부터):

1. 담당자가 vote-app/infra/ 안의 해당 .tf 파일에서 보안 그룹 규칙을 수정하고, (17.2 맛보기에서 해 본 것처럼) 브랜치를 만들어 PR을 올립니다.
2. PR에 자동으로 terraform plan 결과가 붙습니다. — "이 변경으로 보안 그룹 규칙 1개가 추가됩니다." 기계가 먼저 한 번 걸러 줍니다.
3. 동료가 리뷰합니다. "이 포트를 여는 이유가 뭐예요?"라는 질문과 답이 PR에 기록으로 남습니다. 사람이 또 한 번 걸러 줍니다.
4. 승인되면 main에 합쳐지고, terraform apply가 돌아 실제 AWS 인프라에 반영됩니다.

같은 "보안 그룹 규칙 하나 변경"인데, 안전망이 완전히 다릅니다. 누가· 언제·왜 바꿨는지 전부 남고, 실수는 plan(기계)과 리뷰(사람)에서 두 번 걸러집니다. "인프라를 바꾼다 = PR을 올린다"가 되는 것, 이것이 IaC가 바꾸는 일하는 방식입니다.

17.3 전체 그림 — 코드 수정에서 사용자 접속까지

이제 이 책에서 만든 전체 시스템을 한 장으로 그려 보고, "코드를 한 줄 고치면 그것이 사용자 화면에 닿기까지" 어떤 길을 지나는지 처음부터 끝까지 따라가 봅시다.

코드 수정 → 사용자 접속까지의 경로를 순서대로 짚으면 이렇습니다.

1. 코드 수정. 내가 (Claude Code의 도움을 받아) vote-app/frontend/나 backend/의 코드를 고칩니다. — 1부에서 배운 것.
2. GitHub에 올리기(브랜치 → PR → main). 변경을 브랜치로 올려 PR을 만들고, 확인·리뷰를 거쳐 main에 합칩니다. — 이번 17장에서 정리한 것.
3. 앱 파이프라인 작동(빌드·배포). main이 바뀌면 GitHub Actions가 자동으로 컨테이너 이미지를 빌드해 ECR에 올리고, ECS Fargate 서비스를 새 이미지로 갱신합니다. — 15장 CI/CD.
4. 인프라는 그 밑을 받친다. 이 모든 것이 올라가는 무대(VPC, RDS, ECS, ALB)는 16장에서 Terraform 코드로 정의해 두었고, 인프라를 바꿀 때도 2번과 같은 PR 흐름을 탑니다. — 11~14장, 16장.
5. 사용자 접속. 사용자가 브라우저로 ALB 기본 DNS 주소(HTTP)에 접속하면, ALB가 요청을 ECS의 web 컨테이너(Nginx)로 넘기고, web은 React 화면을 보여주며 /api 요청은 api 컨테이너로 넘깁니다. api는 RDS PostgreSQL에서 데이터를 읽고 씁니다. — 14장에서 완성한 기본 구조.

1부의 우리는 이 그림에서 "1번 코드 수정"까지밖에 할 수 없었습니다. 지금은 코드 수정부터 사용자 접속까지 전 구간이 자동화된 하나의 길로 이어져 있습니다. 손으로 하나씩 만들던 조각들이 전부 제자리에 놓여, 자동으로 흐르는 파이프라인이 된 것입니다.

남은 것은 이 길 위에서 실제 운영을 해 보는 일 — 현업의 운영 구조를 이해하고, 새 버전을 무중단으로 내보내고, 문제가 생기면 되돌리는 일입니다. 그것이 남은 장들의 내용입니다.

[확인]

이번 장이 제대로 됐는지 확인합니다. 새로 만든 인프라가 없으니, "직접 해 본 것"과 "말로 설명할 수 있는 것" 두 가지로 확인합니다.

• 직접 해 본 것: GitHub 웹 화면에서 작은 변경 하나를 브랜치로 올려 PR을 만들었고, Files changed 탭에서 내가 추가한 줄이 초록색으로 표시되는 것을 봤으며, 그 PR을 Merge pull request → Confirm merge로 합쳐 "successfully merged" 메시지를 확인했다.
• 말로 설명할 수 있는 것: 아래 [체크리스트]의 네 문장을, 옆 사람에게 설명하듯 스스로 말해 본다. 막힘 없이 설명되면 이 장을 소화한 것입니다.

막히면

• 저장소에 README.md가 없어서 편집을 시작할 수 없다. 파일 목록 위쪽 Add file(파일 추가) → Create new file(새 파일 만들기)을 눌러 파일 이름을 README.md로 하고 아무 내용이나 한 줄 적으세요. 그다음은 맛보기 5번(Commit changes)부터 똑같이 진행하면 됩니다.

• 커밋할 때 실수로 main에 바로 커밋(첫 번째 선택지)을 골라 버렸다. 변경이 main에 곧장 들어갔을 뿐, 잘못된 건 아닙니다. README 한 줄이라 서비스에는 영향이 없습니다. PR을 경험하고 싶다면, 파일을 한 번 더 편집한 뒤 이번엔 두 번째 선택지(Create a new branch … and start a pull request)를 골라 다시 해 보세요.

• PR 화면에서 Merge 버튼이 안 보이거나 회색이다. 저장소에 "리뷰 1명 승인 필수" 같은 보호 규칙이 걸려 있으면 혼자서는 못 합칠 수 있습니다. 연습용이라면 저장소 Settings(설정) → Branches (브랜치)에서 해당 보호 규칙을 잠시 꺼도 되고, 그냥 PR과 diff를 확인하는 것까지만 하고 브랜치를 삭제해 정리해도 이 장의 목적은 충분히 달성됩니다.

• "파이프라인이 두 개"라는 게 여전히 헷갈린다. 기준을 "무엇이 바뀌었나"로 잡으면 쉽습니다. frontend/·backend/(앱)가 바뀌면 → 앱 파이프라인(15장), infra/(무대)가 바뀌면 → 인프라 파이프라인(Terraform). 바뀌는 물건이 다르니 흐르는 길도 다릅니다.

[체크리스트]

아래를 스스로 말로 설명할 수 있는지 확인하세요. 하나라도 막히면 해당 절로 돌아가 다시 읽습니다.

• □ 앱 파이프라인과 인프라 파이프라인이 무엇이 다른지 말할 수 있다 (17.1)
• □ PR(풀 리퀘스트)과 코드 리뷰가 각각 무엇인지 안다 (17.2)
• □ GitHub에서 작은 PR을 직접 만들어 diff를 보고 합쳐 봤다 (17.2 맛보기)
• □ 인프라 변경을 PR로 관리할 때의 장점(기록·이중 검증)을 설명할 수 있다 (17.2)
• □ 전체 그림에서 코드 수정 → 사용자 접속까지의 경로를 그릴 수 있다 (17.3)

모두 됐다면, 이제 이 길 위에서 실제로 운영을 해 볼 차례입니다.