18장. 현업 운영 구조 이해

이 장을 마치면: 실무 서비스가 "죽지 않기 위해" 갖추는 구조(여러 대, 여러 곳, 자동 확장)와 감시 장치(헬스체크·로그·모니터링·알람), 그리고 장애가 났을 때의 대응 흐름을 이해할 수 있다. 새로 만드는 것은 없고, 이미 만들어 둔 것들의 운영적 의미를 재발견합니다.

[지금 여기]

우리는 22단계를 거쳐 "라이브 투표 서비스"를 직접 만들고, 컨테이너에 담아, AWS 클라우드에 배포하고 있습니다. 아래가 그 전체 여정 지도입니다. 지금은 18단계, 배포 자동화를 끝내고 그 위에서 "실무 운영"의 큰 그림을 잡는 자리에 있습니다.

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장마무리 (회고 + 리소스 삭제)

• 방금 끝낸 것: 17장에서 배포 자동화를 하나로 연결했습니다. 이제 코드를 GitHub에 올리면 이미지가 빌드되고 ECS로 자동 배포됩니다.
• 이번 장에서 하는 것: "이렇게 배포된 서비스가 365일 24시간 안 죽고 돌아가려면 무엇이 필요한가?"를 이해합니다. 손으로 새 리소스를 만들기 보다, 이미 우리가 만들어 둔 구조가 운영 관점에서 어떤 의미였는지 재발견하고, AWS 콘솔에서 그 흔적을 눈으로 확인합니다.

이번 장에서 완성되는 것

한 문장으로: "죽지 않는 서비스"의 세 기둥 — 튼튼한 구조(SPOF 제거· 멀티 AZ·오토스케일링), 감시 장치(헬스체크·로그·모니터링·알람), 장애 대응 흐름 — 을 이해하고, 우리 서비스에서 그 각각이 어디에 있는지 짚을 수 있게 됩니다.

이렇게 되면 성공입니다: 누가 "너희 서비스는 서버 한 대 죽으면 어떻게 돼?", "트래픽 몰리면?", "장애 나면 뭐부터 해?"라고 물었을 때, 우리 구조를 가리키며 답할 수 있고, ECS 콘솔에서 CPU·메모리 그래프가 이미 쌓이고 있는 것을 직접 열어 보여 줄 수 있습니다.

사전 조건

이 장은 새로 만드는 것이 없어 실습 준비물은 가볍습니다. 다만 우리가 "이미 만들어 둔 것"을 운영 관점으로 다시 보는 장이라, 1~17장이 끝나 아래가 갖춰져 있어야 이야기가 손에 잡힙니다.

• 14장까지의 기본 완성: ECS Fargate 서비스(vote-service)가 태스크를 띄우고 있고, ALB(vote-alb)의 기본 DNS 주소로 투표 화면이 열립니다.
• 11~12장의 네트워크·DB: VPC(vote-vpc) 안에 2개 AZ로 나뉜 서브넷, 그 위의 RDS(vote-db)가 있습니다.
• 15~17장의 자동 배포: GitHub에 올리면 자동으로 배포되는 파이프라인이 연결돼 있습니다.
• AWS 콘솔 로그인: 8장에서 만든 계정으로 AWS 콘솔에 로그인할 수 있고, 리전이 서울 ap-northeast-2 로 되어 있습니다. (콘솔 오른쪽 위 리전 이름이 "서울"인지 확인하세요. 이 장의 맛보기는 우리 리소스가 있는 서울 리전에서 봐야 합니다.)

이 장의 맛보기는 모두 화면을 열어 보기만 하는 안전한 확인입니다. 새로 만들거나 지우는 것이 없으니 요금이 늘거나 서비스가 바뀔 걱정은 하지 않아도 됩니다.

배포까지 자동화한 우리에게 남은 질문은 이것입니다. "이 서비스가 365일 24시간 안 죽고 돌아가려면 무엇이 필요한가?" 이번 장은 그 답의 큰 그림을 잡는 시간입니다. 아래 세 절을 차례로 봅니다 — 18.1 죽지 않는 구조, 18.2 감시 장치, 18.3 장애 대응 흐름.

18.1 죽지 않는 서비스의 구조 — 여러 대, 여러 곳, 자동 확장

서비스가 죽는 이유는 다양합니다. 서버 한 대가 고장 나고, 데이터센터에 문제가 생기고, 갑자기 사용자가 몰려 과부하가 걸립니다. 실무 아키텍처는 이 각각에 대비책을 겹겹이 세워 둡니다. 이렇게 "웬만한 사고에도 서비스가 계속 돌아가는 성질"을 한 단어로 부릅니다.

대비 1. 한 대가 아니라 여러 대 — 단일 장애점 없애기

[활용 사례] SPOF는 이런 데서 문제가 됩니다.

• 개인 블로그(서버 한 대): 그 서버를 재부팅하는 몇 분간 사이트 전체가 먹통입니다. 서버 한 대가 곧 SPOF입니다.
• 결제 시스템의 DB 한 대: 앞단 웹서버를 아무리 여러 대 둬도 뒤의 데이터베이스가 한 대뿐이면, 그 DB가 죽는 순간 결제 전체가 멈춥니다.
• 일상 비유 — 집 인터넷 공유기: 온 가족이 공유기 하나에 물려 있으면, 그 공유기가 고장 날 때 집 전체 인터넷이 끊깁니다. 공유기가 SPOF입니다.

핵심은 "한 개짜리를 찾아내 여러 개로 만든다"입니다. 우리가 ECS 서비스의 태스크를 2개로 둔 것이 바로 이것입니다. 하나가 죽어도 다른 하나가 받치고, 그 사이 ECS(지배인)가 새 태스크를 띄워 다시 2개를 맞춥니다. 이미 우리는 SPOF 하나를 없애 둔 셈입니다.

대비 2. 한 곳이 아니라 여러 곳 — 멀티 AZ

[활용 사례] 여러 곳에 나눠 두면 이런 사고를 견딥니다.

• 은행·증권 서비스: 한 데이터센터에 정전·화재가 나도 거래가 멈추면 안 되니, 애초에 여러 지역·여러 센터에 시스템을 복제해 둡니다.
• 대형 클라우드의 리전 장애: 실제로 특정 지역의 클라우드 데이터센터 하나가 몇 시간 멈추는 사고가 종종 일어납니다. 이때 여러 AZ(또는 여러 리전)에 걸쳐 둔 서비스는 살아남고, 한 곳에만 있던 서비스는 같이 멈춥니다.
• 예비 발전기 비유: 병원이 정전에 대비해 자가발전기를 두듯, 멀티 AZ는 "한 곳이 나가도 다른 곳이 받는" 예비를 상시 켜 두는 것입니다.

이것도 이미 해 뒀습니다. 11장에서 서브넷을 2개 AZ에 나눴고, ALB도 두 AZ에 걸쳐 있고, 태스크 2개도 두 AZ에 나뉘어 배치됩니다. 남은 약한 고리는 DB입니다. 우리 RDS는 비용 때문에 한 AZ에만 있는데, 실무에서는 RDS의 "다중 AZ" 옵션을 켜서 예비 DB를 다른 AZ에 두고, 주 DB 장애 시 자동 전환되게 합니다. (12장에서 서브넷 그룹이 2개 AZ를 요구했던 이유가 이 예비 자리였습니다.)

대비 3. 몰려오면 늘린다 — 오토스케일링

[활용 사례] 트래픽이 들쭉날쭉한 서비스일수록 빛납니다.

• 쇼핑몰의 세일 순간: 블랙프라이데이나 명절 이벤트가 열리는 몇 시간만 트래픽이 평소의 수십 배로 뛰었다가 가라앉습니다. 그 몇 시간만 서버를 늘렸다 줄입니다.
• 티켓팅·수강신청 오픈: 정각에 사람이 한꺼번에 몰립니다. 오픈 직전에 자동으로 서버를 불려 두고, 상황이 끝나면 되돌립니다.
• 뉴스 속보: 큰 사건이 터지면 특정 페이지에 트래픽이 폭증합니다. 미리 예측할 수 없으니, 수치를 보고 자동으로 대응하는 편이 안전합니다.
• 새벽엔 줄여 비용 절감: 반대 방향도 중요합니다. 한가한 시간엔 태스크를 줄여 요금을 아낍니다. 쓴 만큼 내는 클라우드 요금과 맞물려 비용과 안정성을 동시에 잡습니다.

우리 태스크 수는 지금 2로 고정이지만, ECS 서비스에는 오토스케일링을 붙일 수 있습니다. 갑자기 투표가 몰리면 태스크가 4개, 6개로 늘었다가 새벽에는 2개로 줄어드는 식입니다. 늘어난 태스크를 ALB가 알아서 분배 목록(타깃 그룹 vote-tg)에 넣으니, 우리 구조는 이미 오토스케일링을 받아들일 준비가 되어 있습니다.

[맛보기] 우리 서비스가 정말 "여러 개·여러 곳"인지 눈으로 확인하기

지금까지가 이론이었다면, 우리 콘솔에서 실제로 그렇게 되어 있는지 안전하게 열어만 봅시다. (아무것도 바꾸지 않습니다. 보기만 합니다.)

1. 웹브라우저에서 AWS 콘솔(https://console.aws.amazon.com)에 로그인합니다.
2. 오른쪽 위 리전이 서울(ap-northeast-2) 인지 확인합니다. 아니면 눌러서 서울로 바꿉니다. (우리 리소스는 전부 서울에 있습니다.)
3. 위쪽 검색창에 ECS 를 입력해 Elastic Container Service로 들어갑니다.
4. 왼쪽 클러스터(Clusters) 에서 vote-cluster 를 클릭하고, 서비스 목록에서 vote-service 를 클릭합니다.
5. 아래 태스크(Tasks) 탭을 엽니다. 실행 중인 태스크가 2개 보이고, 각 태스크 행의 가용 영역(Availability Zone) 값이 서로 다른 AZ (예: ap-northeast-2a 와 ap-northeast-2c)로 나뉘어 있으면, 방금 배운 "여러 대(SPOF 제거) · 여러 곳(멀티 AZ)"이 눈앞에 실제로 되어 있는 것입니다.

18.2 감시 장치 — 헬스체크, 로그, 모니터링, 알람

구조를 아무리 잘 짜도 문제는 생깁니다. 중요한 것은 문제를 사람보다 먼저 알아채는 장치입니다. 네 겹의 감시망을 정리합니다.

1겹. 헬스체크 — 초 단위의 생존 확인

14장에서 만난 헬스체크가 감시망의 최전선입니다.

ALB는 몇십 초 간격으로 각 태스크에 확인 요청을 보내고, 응답이 이상한 태스크는 분배 목록에서 즉시 뺍니다. 동시에 ECS는 죽은 태스크를 새것으로 교체합니다. 사람이 알아채기도 전에 격리와 복구가 자동으로 일어나는 것입니다.

[활용 사례] 헬스체크는 자동 격리·복구의 방아쇠입니다.

• 로드밸런서 뒤의 서버 무리: 한 서버가 맛이 가면 로드밸런서가 그 서버로는 손님을 안 보냅니다. 사용자는 느려짐조차 못 느낍니다.
• 컨테이너 오케스트레이션(쿠버네티스 등): "응답 없는 컨테이너는 죽여 새로 띄운다"는 자동 재시작이 전부 헬스체크에서 출발합니다.

2겹. 로그 — 무슨 일이 있었는지의 기록

컨테이너들이 남기는 로그는 CloudWatch Logs에 모입니다(14장에서 로그 설정을 해 뒀습니다).

운영에서 로그는 사건의 블랙박스입니다. "새벽 3시에 왜 죽었지?"의 답은 그 시각의 로그에 있습니다. 중요한 점은, 태스크는 죽고 새로 떠도 로그는 CloudWatch에 그대로 남는다는 것입니다. 죽은 태스크와 함께 기록까지 사라지면 원인을 영영 못 찾으니까요.

3겹. 모니터링과 메트릭 — 수치로 보는 상태

[활용 사례] 메트릭은 "터지기 전"을 보여 줍니다.

• 응답 시간이 슬금슬금 느려짐: 아직 죽지는 않았지만 그래프가 우상향 이면 곧 문제가 생긴다는 신호입니다. 미리 손볼 수 있습니다.
• 메모리·디스크가 차오름: 100%에 닿기 전에 그래프로 미리 보이면, 터지기 전에 늘리거나 정리할 수 있습니다.
• 트래픽 추세 파악: 요청 수 그래프를 보면 언제 사람이 몰리는지 알 수 있어, 오토스케일링 규칙(18.1)의 기준을 정하는 근거가 됩니다.

4겹. 알람 — 수치가 선을 넘으면 사람에게 알리기

[활용 사례] 알람은 "사람보다 먼저 아는" 장치입니다.

• 오류율 급증 통보: 배포 직후 오류가 튀면, 사용자 문의가 쌓이기 전에 담당자 휴대폰이 먼저 울립니다.
• 온콜(on-call) 호출: 새벽에 서비스가 다운되면 알람이 당직자를 자동으로 깨웁니다. 사람이 화면을 밤새 지킬 필요가 없습니다.
• 비용 급증 알람: 성능뿐 아니라 요금에도 겁니다. "이번 달 예상 요금이 기준을 넘으면 알려라"로 과금 사고를 막습니다.

실무의 운영자는 화면을 하루 종일 쳐다보지 않습니다. 알람이 오면 봅니다. "장애를 사용자 문의로 알게 되면 실패, 알람으로 알게 되면 정상"이라는 말이 있을 정도로, 알람 설정은 운영의 기본기입니다.

[맛보기] 이미 쌓이고 있는 우리 메트릭 그래프 열어 보기

우리 실습에서 태스크 상태와 로그(1·2겹)는 이미 갖춰져 있습니다. 알람 (4겹)은 실습 범위에서는 만들지 않지만, 그 재료가 되는 메트릭(3겹)이 지금도 저절로 쌓이고 있는 것을 눈으로 확인해 봅시다. (역시 보기만 합니다.)

1. 18.1 맛보기에서 열었던 ECS → vote-cluster → vote-service 서비스 화면으로 갑니다.
2. 위쪽 탭 중 상태 및 메트릭(Health and metrics) 을 클릭합니다. (콘솔 버전에 따라 메트릭(Metrics) 또는 모니터링(Monitoring) 으로 보일 수 있습니다. 그래프가 있는 탭을 찾으면 됩니다.)
3. CPU 사용률(CPUUtilization) 과 메모리 사용률(MemoryUtilization) 그래프가 시간축을 따라 그려져 있으면 성공입니다. 우리가 아무 설정을 안 해도 CloudWatch가 이 수치를 자동으로 모으고 있었던 것입니다.
4. (원한다면) 이 그래프에 "CPU 70% 넘으면 알려라" 같은 기준선을 거는 화면이 바로 알람 설정입니다. 지금은 만들지 말고, "여기에 선을 그으면 알람이 되는구나" 정도만 눈에 담아 두세요.

18.3 장애가 나면 — 대응 흐름의 뼈대

마지막으로, 그래도 장애가 났을 때 실무 팀이 움직이는 순서를 알아 둡시다. 이 흐름이 바로 다음 장들(무중단 배포·롤백)을 이해하는 바탕입니다.

[활용 사례] 흐름은 규모와 상관없이 비슷합니다.

• 작은 팀의 배포 후 사고: 배포하자마자 오류율이 튀면, 원인을 파기 전에 일단 이전 버전으로 되돌려 서비스를 살립니다.
• 큰 회사의 장애 대응 조직: 감지→파악→복구→회고라는 뼈대는 같고, 여기에 역할 분담(지휘·기록·소통)과 포스트모템 문서가 더해질 뿐입니다.

실무의 대응 흐름은 대략 이렇습니다.

1. 감지: 알람이 울린다. (또는 헬스체크 실패, 사용자 문의)
2. 파악: 무엇이, 언제부터, 얼마나 이상한가? 로그와 메트릭을 본다. (18.2에서 열어 본 그 화면들이 여기서 쓰입니다.)
3. 첫 질문 — "방금 뭐가 바뀌었지?": 장애의 가장 흔한 원인은 직전의 배포입니다. 그래서 "최근에 배포된 것"부터 의심하는 것이 정석입니다.
4. 복구 우선: 원인을 완벽히 규명하기 전이라도, 서비스부터 살립니다. 직전 배포가 의심되면 이전 버전으로 롤백하는 것이 가장 빠른 복구인 경우가 많습니다. (원인 분석은 복구 후에 차분히.)
5. 회고(포스트모템): 상황이 끝나면 기록을 남깁니다. 무엇이 문제였고, 어떻게 재발을 막을지. 사람을 탓하지 않고 구조를 고치는 것이 원칙입니다.

여기서 4번을 눈여겨보세요. "복구가 원인 규명보다 먼저"이고, 그 복구의 대표 수단이 롤백입니다. 롤백이 빠르고 안전하려면 두 가지가 준비돼 있어야 합니다 — 돌아갈 이전 버전이 남아 있을 것(우리는 9~10장부터 ECR에 커밋 해시 태그로 버전을 쌓아 왔습니다), 그리고 되돌리는 절차가 간단할 것. 우리가 2부부터 태그를 강조해 온 이유가 이 흐름 안에 있습니다. (여정 지도에서 보듯, 이 흐름을 실제로 손으로 해 보는 것이 20장입니다.)

[확인] 이 장이 제대로 됐는지

이번 장은 "이해"가 목표라, 확인도 눈과 말로 합니다. 아래를 스스로 해 보세요.

• ECS 콘솔의 vote-service 태스크 탭에서 태스크가 2개이고 서로 다른 AZ에 있는 것을 직접 봤다. (18.1 맛보기)
• ECS 콘솔의 상태 및 메트릭 탭에서 CPU·메모리 그래프가 쌓이고 있는 것을 직접 봤다. (18.2 맛보기)
• "서버 한 대 죽으면?" → 태스크 2개+ECS 자동 교체로, "데이터센터 하나 죽으면?" → 멀티 AZ로, "트래픽 몰리면?" → 오토스케일링으로 답할 수 있다.
• "장애 나면 뭐부터?" → 복구(롤백) 먼저, 원인 규명은 그다음 이라고 말할 수 있다.

여기까지 되면 운영의 큰 그림이 잡힌 것입니다.

막히면

이 장은 새로 만드는 게 없어 크게 막힐 일은 없지만, 맛보기에서 자주 나는 상황과 대처입니다.

• ECS에서 vote-cluster 나 vote-service 가 안 보인다. 콘솔 오른쪽 위 리전이 서울(ap-northeast-2) 인지 먼저 확인하세요. 우리 리소스는 전부 서울에 있어서, 다른 리전을 보고 있으면 아무것도 안 나옵니다. 리전을 서울로 바꾸면 보입니다.

• 태스크가 2개가 아니라 0개거나 1개다. 방금 배포 중이라 잠깐 그럴 수 있습니다. 몇 분 뒤 새로고침 해 보세요. 계속 0개라면 서비스가 떠 있지 않은 것이니, 14장의 [확인]으로 돌아가 ALB 주소로 투표 화면이 열리는지부터 점검합니다.

• "상태 및 메트릭" 탭이 안 보이거나 이름이 다르다. AWS 콘솔은 이름이 자주 바뀝니다. 메트릭(Metrics), 모니터링 (Monitoring) 등 그래프가 있는 탭을 대신 찾으세요. 그래프가 보이면 같은 것입니다.

• 그래프가 비어 있거나 "데이터 없음"이라고 나온다. 서비스를 방금 만들었다면 아직 수치가 덜 쌓였을 수 있습니다. 그래프 상단의 기간을 "지난 3시간"처럼 넓게 잡거나, 몇 분 뒤 다시 열어 보세요.

• 뭔가 잘못 눌러 리소스가 바뀔까 걱정된다. 이 장의 맛보기는 모두 "보기(조회)"뿐이라, 목록을 클릭해 상세를 여는 것만으로는 아무것도 바뀌지 않습니다. 만들기(Create)·삭제(Delete)· 업데이트(Update) 같은 버튼만 누르지 않으면 안전합니다.

[체크리스트]

아래가 모두 됐으면 다음(19장 무중단 배포)으로 갈 준비가 된 것입니다.

• □ SPOF가 무엇이고, 태스크 2개·멀티 AZ가 어떤 대비인지 설명할 수 있다
• □ 고가용성이 무엇을 위한 성질인지 한 문장으로 말할 수 있다
• □ 오토스케일링이 무엇이고 우리 구조 어디에 붙는지 안다
• □ 감시 4겹(헬스체크·로그·메트릭·알람)의 역할 차이를 말할 수 있다
• □ ECS 콘솔에서 태스크 2개·다른 AZ를 직접 확인했다
• □ ECS 콘솔에서 CPU·메모리 메트릭 그래프를 직접 확인했다
• □ 장애 대응에서 "복구가 원인 규명보다 먼저"인 이유를 안다
• □ 장애의 첫 질문이 "방금 뭐가 바뀌었지?"인 이유를 안다

운영의 큰 그림이 잡혔습니다.