이번 주 목표 SAA 시험에서 가장 자주 나오는 "이 요구사항엔 어떤 DB를 써야 하나?" 유형을 확실히 잡는다.

글의 구성

• Part I. 개념편 — 각 서비스가 무엇이고, 어떻게 동작하는가
• Part II. 비교편 — 네 서비스를 나란히 놓고 판별하기
• Part III. 비용·최적화편 — 같은 아키텍처에서 돈을 어떻게 아끼는가

0. 들어가며

0-1. 왜 DB 비교가 SAA의 핵심인가

SAA 시험은 "서비스 이름 암기"가 아니라 요구사항 → 서비스 선택 문제로 나온다. 문제는 보통 이렇게 생겼다.

"한 스타트업이 모바일 게임을 운영한다. 사용자 프로필은 단순한 키-값 형태이고, 트래픽은 이벤트 때마다 수십 배로 튄다. 운영 인력은 최소화하고 싶다. 어떤 데이터베이스를 선택해야 하는가?"

여기서 "단순한 키-값", "트래픽 급변", "운영 최소화"라는 세 단어가 곧 DynamoDB를 가리킨다. 즉 시험은 키워드 → 서비스 매핑 능력을 묻는다.

DB 영역은 시험 도메인 1(복원력 있는 아키텍처), 도메인 2(고성능 아키텍처), 도메인 4(비용 최적화)에 모두 걸쳐 있어서 출제 비중이 특히 높다.

0-2. 먼저 정리하고 갈 기본 용어

본문에서 계속 나올 단어들이다. 여기서 한 번 정리하고 시작하자.

!

그림 1. DB 선택 의사결정 트리 — "관계형인가? → 예: RDS/Aurora, 아니오: DynamoDB → 캐시가 필요한가? → ElastiCache/DAX" 형태의 플로우차트를 넣을 자리. draw.io 또는 Excalidraw로 제작 예정.

Part I. 개념편

1. Amazon RDS — 관리형 관계형 데이터베이스

1-1. "관리형(Managed)"이 무슨 뜻인가

학교 프로젝트에서 MySQL을 직접 써봤다면 이런 일을 해봤을 것이다.

1. EC2 인스턴스를 켠다
2. apt install mysql-server로 설치한다
3. 설정 파일을 만지고 포트를 연다
4. 보안 패치가 나오면 직접 업데이트한다
5. 백업 스크립트를 크론탭에 등록한다
6. 서버가 죽으면... 새벽에 일어나서 고친다

RDS는 3~6번을 AWS가 대신 해준다. 이게 "관리형"의 의미다. 지원 엔진은 6가지: MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Db2.

⚠️ 시험 함정 예시 "DB 서버에 로그 수집 에이전트를 직접 설치해야 한다. 어떻게 해야 하는가?" → RDS는 OS 접근이 막혀 있어서 불가능하다. 정답은 "EC2에 DB를 직접 설치(self-managed)"다. RDS 문제에서 SSH, 커스텀 데몬 설치, OS 커널 설정 같은 말이 나오면 거의 함정이다.

그림 2. RDS 책임 공유 모델 — 하드웨어/OS/DB엔진/데이터를 계층으로 쌓고, 어디까지가 AWS 책임이고 어디부터가 사용자 책임인지 색으로 구분.

1-2. 스토리지 오토스케일링 — 디스크가 알아서 늘어난다

DB를 만들 때 "스토리지 20GB"처럼 용량을 정한다. 그런데 서비스가 잘 되면 데이터가 늘어난다. 디스크가 꽉 차면 DB는 그냥 멈춘다. 이걸 막아주는 기능이다.

동작 조건 (셋 다 만족해야 발동)

• 여유 공간이 전체의 10% 미만
• 그 상태가 5분 이상 지속
• 마지막 증설 이후 6시간이 지남

예시: 100GB 디스크에서 여유가 8GB로 떨어지고 5분이 지나면 → AWS가 자동으로 늘려준다.

Maximum Storage Threshold(최대 스토리지 임계값)를 설정해두면 무한정 늘어나는 걸 막을 수 있다. 버그로 로그가 폭주해서 디스크가 10TB까지 늘어나는 사고를 방지하는 안전장치다.

1-3. 읽기 전용 복제본 (Read Replica) — 읽기를 나눠 받는다

문제 상황: 쇼핑몰 DB 하나에 주문 처리(쓰기)와 마케팅팀 통계 쿼리(읽기)가 몰린다. 마케팅팀이 무거운 집계 쿼리를 돌릴 때마다 주문이 느려진다.

해결: 읽기 전용 복사본을 따로 만들어서, 통계 쿼리는 그쪽으로 보낸다.

• 목적: 읽기 성능 확장(Scale Out) — 성능을 위한 기능
• 복제 방식: 비동기 → 최종 일관성
  • 즉 원본에 방금 들어온 주문이 복제본에는 몇 밀리초~몇 초 뒤에 보일 수 있다
  • 통계·리포트에는 괜찮지만, "결제 직후 잔액 조회" 같은 데는 부적합
• 개수: RDS 최대 5개(엔진마다 다름), Aurora는 최대 15개
• 위치: 같은 AZ / 다른 AZ / 다른 리전까지 가능
• 승격(Promote): 복제본을 독립된 DB로 승격시킬 수 있다
• 애플리케이션이 읽기용 주소를 따로 알고 연결을 나눠줘야 한다 (코드 수정 필요)

💡 다른 리전 복제본 활용 예시 본사는 서울, 사용자 절반은 미국. 미국 리전에 읽기 복제본을 두면 미국 사용자의 조회 응답이 태평양을 왕복하지 않아 훨씬 빨라진다.

1-4. Multi-AZ 배포 — 죽어도 살아남기

문제 상황: 서울 리전의 한 데이터센터(AZ)에 장애가 났다. 내 DB가 거기 있었다.

해결: 다른 AZ에 똑같은 DB를 하나 더 두고, 장애 시 자동으로 넘긴다.

• 목적: 고가용성(HA) / 재해 복구 — 성능 확장이 아님 (이게 제일 중요한 구분)
• 복제 방식: 동기 (원본과 대기본에 동시에 써야 성공 응답)
• 대기(Standby) 인스턴스는 평상시 읽기도 쓰기도 못 한다. 그냥 대기만 한다
• 장애 시 자동 페일오버, 엔드포인트 주소는 그대로 유지
  • → 애플리케이션 코드를 전혀 안 고쳐도 된다. DNS가 알아서 새 서버를 가리킨다

⚠️ 가장 많이 나오는 함정 "읽기 성능이 부족하다. Multi-AZ를 켜면 되는가?" → 안 된다. 대기 인스턴스는 읽기를 안 받는다. 정답은 Read Replica.

반대로 "AZ 장애에 대비해야 한다. Read Replica를 만들면 되는가?" → 자동 페일오버가 없으므로 부적합. 정답은 Multi-AZ.

그림 3. 좌측에 Read Replica(비동기·읽기 분산), 우측에 Multi-AZ(동기·페일오버) 구조를 나란히 배치. SAA에서 가장 많이 헷갈리는 두 개념이므로 반드시 시각화할 것.

📝 핵심 비교표

💡 Multi-AZ DB Cluster: 대기 인스턴스를 2개 두면서 읽기까지 받을 수 있게 만든 신형 옵션. "고가용성도 필요하고 읽기 성능도 필요하다"는 문제에서 정답이 될 수 있다. 기존 Multi-AZ(대기본이 놀고 있음)의 아쉬움을 보완한 버전이라고 이해하면 된다.

1-5. 백업과 복구

두 가지 방식이 있고, 시험은 보존 기간으로 둘을 구분한다.

① 자동 백업 (Automated Backup)

• 매일 1회 전체 스냅샷 + 5분마다 트랜잭션 로그를 저장
• 덕분에 PITR(Point-In-Time Recovery, 특정 시점 복구) 가 가능하다
  • 예: "오늘 오후 2시 37분에 실수로 DELETE를 날렸다" → 2시 36분 상태로 되돌릴 수 있다
• 보존 기간: 1~35일 (0으로 두면 자동 백업 꺼짐)
• DB를 삭제하면 자동 백업도 같이 사라진다

② 수동 스냅샷 (Manual Snapshot)

• 내가 원할 때 직접 생성
• 직접 지우기 전까지 무기한 보존 — DB를 삭제해도 남아 있다
• 예: 마이그레이션 직전 안전장치, 감사(audit) 대비 장기 보관

1-6. RDS Proxy — 커넥션 폭주 막기

문제 상황: Lambda 함수가 요청마다 DB에 접속한다. 트래픽이 몰려 Lambda가 1,000개로 늘어나면 DB 커넥션도 1,000개가 열린다. MySQL의 기본 최대 커넥션은 훨씬 작아서 DB가 뻗는다. 이걸 커넥션 폭증(connection storm) 이라고 한다.

해결: 중간에 프록시를 두고 커넥션 풀(연결 재사용 창고) 을 관리한다.

• Lambda들은 프록시에 붙고, 프록시가 DB와의 실제 연결 몇 개를 돌려쓴다
• 페일오버 시간을 최대 66% 단축 (프록시가 새 마스터를 먼저 찾아준다)
• VPC 내부에서만 접근 가능, IAM 인증을 강제할 수 있음

🧪 내 논문 연결점: 서버리스 함수가 폭발적으로 스케일아웃될 때 DB 커넥션이 병목이 된다. RDS Proxy는 이 "다대일 자원 경합"을 완충하는 계층이다. 오토스케일링이 컴퓨팅만 늘려도 하위 자원(커넥션)이 스케일되지 않으면 전체가 무너진다는 좋은 사례이기도 하다.

1-7. 보안

• 저장 시 암호화(at rest): KMS(AES-256) 사용. DB 생성 시에만 켤 수 있다
  • 이미 만든 비암호화 DB를 암호화하려면? → 스냅샷 생성 → 암호화 옵션을 켜서 스냅샷 복사 → 그 스냅샷으로 복원 (시험 단골)
• 전송 중 암호화(in transit): SSL/TLS
• 인증: 비밀번호 또는 IAM 데이터베이스 인증
  • IAM 인증은 15분짜리 임시 토큰을 발급받아 접속. DB 비밀번호를 코드에 안 박아도 된다
• 네트워크: 보안 그룹(인스턴스 레벨 방화벽)으로 제어. NACL은 서브넷 레벨이라 결이 다르다

2. Amazon Aurora — 클라우드 네이티브 관계형 DB

2-1. Aurora는 RDS와 뭐가 다른가

RDS는 기존 MySQL/PostgreSQL을 그대로 클라우드에 올린 것이다. Aurora는 AWS가 스토리지 계층을 아예 새로 설계해서 만든 MySQL/PostgreSQL 호환 DB다.

"호환"이라는 말이 중요하다. 내부 구현은 완전히 다르지만 애플리케이션 입장에선 MySQL/PostgreSQL 드라이버를 그대로 쓸 수 있다.

• MySQL 대비 최대 5배, PostgreSQL 대비 최대 3배 처리량
• 스토리지가 10GB에서 시작해 128TB까지 자동 확장 — 용량을 미리 정할 필요가 없다
• 백업, 복구, 복제가 스토리지 계층에서 처리돼서 인스턴스 부담이 적다

2-2. 아키텍처 — 6개 복제본, 3개 AZ, 쿼럼

Aurora의 모든 장점은 이 구조 하나에서 나온다. 핵심은 컴퓨팅과 스토리지의 분리다.

일반 DB는 서버 안에 디스크가 붙어 있다. Aurora는 DB 인스턴스(계산) 와 공유 스토리지 볼륨(저장) 이 분리돼 있고, 스토리지는 여러 서버에 흩어져 있다.

쿼럼(Quorum)이란?

여러 복사본 중 "몇 개가 동의하면 유효한 것으로 인정할지"를 정한 정족수다. 국회 의결정족수와 같은 개념이다. 전부의 동의를 기다리지 않아서 빠르고, 일부가 죽어도 진행되니까 튼튼하다.

Aurora의 규칙:

• 데이터를 3개 AZ에 걸쳐 6개 복제본으로 저장
• 쓰기: 6개 중 4개가 확인되면 성공 처리 (4/6 쿼럼)
• 읽기: 6개 중 3개만 살아 있으면 가능 (3/6 쿼럼)

이 규칙에서 자동으로 따라 나오는 결론:

• 복제본 2개를 잃어도 → 읽기·쓰기 모두 정상 (4개 남았으니 쓰기 쿼럼 충족)
• 복제본 3개를 잃어도 → 읽기는 가능 (3개 남았으니 읽기 쿼럼 충족)
• AZ 하나가 통째로 날아가도(=2개 손실) 서비스가 안 멈춘다

여기에 자가 복구(self-healing) 가 붙는다. 손상된 블록을 감지하면 다른 복제본에서 데이터를 가져와 알아서 고친다.

그림 4. Aurora 아키텍처 — 상단에 Writer 1개 + Reader N개, 하단에 3개 AZ에 걸친 공유 스토리지 볼륨(6개 복제본)을 그리고 화살표로 연결. "컴퓨팅 ↔ 스토리지 분리"가 시각적으로 드러나야 함.

2-3. 엔드포인트 — 어디로 접속할 것인가

Aurora는 인스턴스가 여러 개(Writer 1개 + Reader N개)라서 접속 주소도 여러 종류다.

Writer Endpoint의 장점 예시: 마스터가 죽어서 복제본 하나가 승격돼도, Writer Endpoint 주소는 그대로다. 애플리케이션은 아무것도 안 바꿔도 된다.

Custom Endpoint 활용 예시: 일반 API용 인스턴스는 db.r6g.large, 데이터 분석팀용은 db.r6g.8xlarge로 두고, 분석팀에게만 큰 인스턴스를 가리키는 커스텀 엔드포인트를 준다. 무거운 쿼리가 일반 사용자에게 영향을 주지 않는다.

⚠️ Reader Endpoint의 부하 분산은 연결(Connection) 단위이지 쿼리 단위가 아니다. 커넥션 풀을 쓰면 한 번 맺은 연결이 계속 유지되므로 분산이 고르지 않을 수 있다.

2-4. 주요 기능

Replica Auto Scaling 읽기 부하(CPU 사용률 등)에 따라 복제본 개수를 자동으로 늘리고 줄인다. 최대 15개. → 예: 평소 2개, 이벤트 때 8개, 끝나면 다시 2개.

Global Database (글로벌 데이터베이스)

• 1개 주 리전(쓰기) + 최대 5개 보조 리전(읽기)
• 리전 간 복제 지연 1초 미만
• 주 리전 장애 시 보조 리전 승격이 1분 미만
• 예: 서비스 본진은 서울, 미국·유럽 사용자는 각 리전의 보조 클러스터에서 읽는다. 서울에 재해가 나면 미국 리전을 주 리전으로 승격한다.
• 👉 문제에 "전 세계 사용자", "읽기 지연 최소화", "리전 장애 대비"가 같이 나오면 정답

Backtrack (백트랙)

• 백업에서 복원하지 않고 DB를 과거 시점으로 되감기 (Aurora MySQL)
• 복원은 새 클러스터를 만드는 거라 오래 걸리는데, 백트랙은 같은 클러스터를 되돌려서 훨씬 빠르다
• 예: 배포 스크립트가 잘못돼서 테이블을 날렸다 → 5분 전으로 되감기

Database Cloning (클로닝)

• Copy-on-Write 방식으로 클러스터를 복제한다

  Copy-on-Write란? 처음엔 데이터를 복사하지 않고 원본을 같이 바라보다가, 수정이 일어난 블록만 그때 복사하는 기법. 초기 복사 비용이 거의 0이다.

• 예: 1TB 운영 DB를 몇 분 만에 복제해 테스트 환경을 만든다. 안 건드린 데이터는 스토리지도 안 먹는다

Aurora Machine Learning SQL 함수 호출만으로 SageMaker나 Comprehend 모델을 호출한다. 예: SELECT sentiment(review_text) FROM reviews; 형태로 감성 분석 결과를 바로 얻는다.

2-5. Aurora Serverless v2

ACU(Aurora Capacity Unit) 라는 단위로 용량을 표현한다. 1 ACU ≈ 2GiB 메모리 + 그에 상응하는 CPU/네트워크로 보면 된다.

• 부하에 따라 초 단위로 ACU를 올리고 내린다
• 0 ACU까지 축소(scale-to-zero) 가능 → 아무도 안 쓰면 컴퓨팅 요금이 사실상 0
• Aurora Serverless v1은 2025년 3월 31일 지원 종료, 현재는 v2가 표준
• 적합한 워크로드: 사내 관리자 페이지, 개발/스테이징 환경, 계절성이 큰 서비스

예시: 대학 수강신청 시스템. 1년 중 나흘만 트래픽이 폭발하고 나머지는 거의 놀고 있다. 프로비저닝 방식이면 피크에 맞춰 큰 인스턴스를 1년 내내 켜둬야 하지만, Serverless v2는 그 나흘에만 확 올라간다.

2-6. 최신 동향 (참고용, 시험 비중은 낮음)

• Aurora Limitless Database: 샤딩(데이터를 여러 DB에 쪼개 넣는 것)을 자동화해 수평 확장 제공
• Aurora DSQL: PostgreSQL 호환 분산 SQL 데이터베이스. 여러 리전에서 동시에 쓰기(액티브-액티브) 가 가능하면서 강한 일관성을 유지한다. Aurora와는 별개 제품이고 드롭인 대체재가 아니다(지원 안 되는 PostgreSQL 기능이 있음).

3. Amazon DynamoDB — 서버리스 NoSQL

3-1. NoSQL을 왜 쓰는가

관계형 DB(RDS/Aurora)는 강력하지만 두 가지 한계가 있다.

1. 수직 확장(Scale-Up) 위주 — 더 큰 서버로 바꾸는 방식이라 한계가 있다
2. 스키마가 고정 — 컬럼을 추가하려면 ALTER TABLE을 해야 하고, 큰 테이블에선 위험하다

DynamoDB는 수평 확장(Scale-Out) 을 기본으로 한다. 서버를 계속 추가해 나가는 방식이라 이론상 용량과 처리량에 한계가 없다. 대신 JOIN이 없다.

• 완전 서버리스 — 인스턴스 타입을 고르지 않는다. 테이블만 만들면 끝
• 한 자릿수 밀리초 응답
• 기본적으로 3개 AZ에 자동 복제 (설정할 필요조차 없다)
• 항목(Item) 최대 크기: 400KB

적합한 예시: 게임 사용자 프로필, 세션 데이터, IoT 센서 로그, 장바구니, 리더보드 원본 데이터 부적합한 예시: 여러 테이블을 JOIN해서 복잡한 집계를 내는 ERP, 회계 시스템

3-2. 데이터 모델 — 파티션 키와 정렬 키

DynamoDB의 기본 키는 두 가지 형태다.

① 파티션 키만 (Simple Primary Key)

Users 테이블
PK: user_id
  "u1001" → { name: "김동민", grade: 4 }
  "u1002" → { name: "이철수", grade: 2, club: "밴드부" }   ← 속성이 달라도 됨

② 파티션 키 + 정렬 키 (Composite Primary Key)

Orders 테이블
PK: user_id, SK: order_date
  "u1001" / "2026-08-01" → { item: "키보드", price: 89000 }
  "u1001" / "2026-08-03" → { item: "마우스", price: 35000 }
  "u1001" / "2026-08-05" → { item: "모니터", price: 320000 }

이 구조면 "u1001의 8월 주문 전체를 최신순으로" 같은 범위 쿼리가 가능하다.

파티션 키가 하는 일: 값을 해시 함수에 넣어서 데이터가 어느 물리 파티션(서버)에 저장될지 결정한다. 그래서 파티션 키가 곧 데이터 분산의 기준이 된다.

⚠️ 핫 파티션(Hot Partition) 특정 파티션 키에만 요청이 쏠리면 그 파티션 하나가 과부하돼 스로틀링이 난다.

나쁜 예: 파티션 키를 날짜로 잡은 로그 테이블. 오늘 들어오는 모든 로그가 "2026-08-05" 하나에 몰린다. 다른 파티션은 놀고 하나만 죽는다.

좋은 예: 날짜#기기ID 처럼 카디널리티(값의 종류 수)가 높은 키를 쓴다. 요청이 여러 파티션에 고르게 흩어진다.

그림 5. 파티션 키 해싱 → 여러 파티션으로 분산되는 구조. 잘 분산된 케이스와 핫 파티션 케이스를 좌우로 대비해서 그릴 것.

3-3. 읽기 일관성 두 가지

• 결과적 일관된 읽기 (기본값) — 방금 쓴 값이 아직 안 보일 수 있다 (보통 1초 이내에 반영)
• 강력한 일관된 읽기 — 항상 최신값을 보장한다

예시: 게시글 조회수는 결과적 일관성으로 충분하다. 잠깐 1 차이 나도 아무 문제없다. 반면 재고 수량 확인은 강력한 일관성이 필요하다. 재고가 0인데 1로 읽히면 초과 판매가 난다.

3-4. 보조 인덱스 (Secondary Index)

왜 필요한가: DynamoDB는 기본적으로 파티션 키로만 조회할 수 있다. Users 테이블의 PK가 user_id인데 "이메일로 사용자 찾기"를 하려면? 전체를 훑는 Scan을 해야 하는데 이건 느리고 비싸다. 그래서 다른 키로 조회할 인덱스를 만든다.

GSI 예시: Orders 테이블(PK: user_id)에 "상품별 주문 조회"가 필요해졌다. → PK를 product_id로 한 GSI를 만든다. 운영 중에도 추가 가능.

LSI 예시: Orders 테이블(PK: user_id, SK: order_date)에서 "금액순 정렬"도 필요하다 → PK는 그대로 user_id, SK만 price인 LSI. 단, 테이블 만들 때 같이 만들었어야 한다.

⚠️ 시험 함정: "이미 운영 중인 테이블에 새로운 조회 패턴이 필요해졌다" → LSI는 나중에 못 만든다 → 정답은 무조건 GSI.

3-5. 부가 기능

DAX (DynamoDB Accelerator)

• DynamoDB 전용 인메모리 캐시. 밀리초를 마이크로초로 줄인다
• 기본 TTL 5분
• 핵심: 애플리케이션 코드를 안 고쳐도 된다. DynamoDB SDK 엔드포인트만 DAX로 바꾸면 끝
• 예시: 상품 상세 페이지가 같은 상품을 수천 번 조회 → DAX가 다 흡수

DynamoDB Streams

• 테이블의 항목 변경(추가/수정/삭제)을 시간순 이벤트 스트림으로 뽑아준다
• Lambda를 트리거할 수 있고, 보존 기간은 24시간
• 예시: 신규 회원가입(항목 추가) → Streams → Lambda → 환영 이메일 발송

TTL (Time To Live)

• 항목에 만료 시각(Unix timestamp) 속성을 두면 지나서 자동 삭제된다
• 예시: 세션 데이터에 expires_at = 지금+24시간. 하루 뒤 알아서 사라진다

Global Tables

• 여러 리전에 액티브-액티브로 복제 (모든 리전에서 읽기·쓰기 다 가능)
• 사전 조건: DynamoDB Streams 활성화 필수
• Aurora Global Database는 주 리전만 쓰기가 되지만, 이건 양쪽 다 쓰기가 된다는 게 차이점

PITR / Transactions

• PITR: 최대 35일 이내 임의 시점으로 복구
• Transactions: 여러 항목·여러 테이블에 걸친 ACID 보장 (전부 성공 or 전부 실패)

DAX vs ElastiCache — 언제 무엇을?

문제에 "DynamoDB인데 코드 수정 없이 읽기를 더 빠르게"가 나오면 DAX다.

4. Amazon ElastiCache — 인메모리 캐시

4-1. 캐시가 하는 일

문제 상황: 쇼핑몰 메인 페이지가 "이번 주 인기 상품 TOP 10"을 보여준다. 이걸 계산하려면 주문 테이블 수백만 건을 집계해야 한다. 그런데 이 결과는 1분에 한 번 바뀌어도 충분하다. 사용자가 10,000명이면 같은 계산을 10,000번 반복하는 셈이다.

해결: 계산 결과를 메모리에 넣어두고 1분간 그냥 꺼내 쓴다. 이게 캐시다.

ElastiCache는 관리형 인메모리 데이터 스토어다. 지원 엔진은 3가지.

• Valkey — Redis에서 갈라져 나온 오픈소스. 현재 AWS 권장 기본값
• Redis OSS — 오랫동안 표준이었던 엔진
• Memcached — 가장 단순한 순수 캐시

Valkey가 왜 생겼나: Redis가 2024년에 라이선스를 바꾸면서 커뮤니티가 포크했고, Linux Foundation이 관리하는 프로젝트가 Valkey다. Redis와 API가 완전 호환이라 클라이언트 코드를 안 고치고 바꿔 끼울 수 있다.

캐시를 쓰는 이유는 크게 두 가지다.

1. DB 부하 감소 → 읽기 성능 향상 (그리고 DB 인스턴스를 줄일 수 있어 비용도 절감)
2. 애플리케이션을 무상태(Stateless)로 만들기

   무상태란? 서버가 사용자별 정보를 자기 메모리에 안 들고 있는 상태. 세션을 EC2 메모리에 두면, 그 EC2가 죽거나 로드밸런서가 다른 서버로 보낼 때 로그인이 풀린다. 세션을 ElastiCache에 빼두면 어느 서버로 가도 로그인이 유지되고, 서버를 마음대로 늘렸다 줄일 수 있다.

그림 6. ELB → EC2(Auto Scaling) → ElastiCache(캐시 히트/미스 분기) → RDS 구조도. Cache Hit 경로와 Cache Miss 경로를 다른 색 화살표로 구분.

4-2. 캐싱 전략

Lazy Loading 코드 흐름 (의사코드)

data = cache.get(key)
if data is None:          # 캐시 미스
    data = db.query(...)
    cache.set(key, data, ttl=60)
return data

캐시 미스(Cache Miss) = 캐시에 없어서 DB까지 갔다 오는 것 캐시 히트(Cache Hit) = 캐시에서 바로 나오는 것. 히트율이 높을수록 좋은 캐시다

실무에선 Lazy Loading + TTL 조합이 가장 흔하다. Write Through 단독은 "한 번도 안 읽힐 데이터까지 캐시에 채우는" 낭비가 있다.

4-3. Redis/Valkey vs Memcached (⭐ 단골 비교)

AOF(Append Only File)란? 캐시에 들어온 모든 쓰기 명령을 파일에 순서대로 기록해두는 방식. 서버가 재시작해도 이 파일을 재생하면 데이터가 복구된다. Memcached엔 이런 게 없다.

시험 판별법

• "고가용성 / 영속성 / 백업 / 리더보드(정렬)" → Redis or Valkey
• "단순하고 순수한 캐시 / 멀티스레드 / 데이터 잃어도 무방" → Memcached

4-4. 대표 유스케이스

• 세션 스토어 — EC2가 여러 대여도 어느 서버로 가든 로그인 유지 (SAA 최다 출제)
• 리더보드 — Redis의 Sorted Set은 점수순 정렬이 O(log N)이라 실시간 순위에 최적
• DB 쿼리 결과 캐싱 — 위의 "인기 상품 TOP 10" 케이스
• Pub/Sub 메시징 — 채팅, 실시간 알림
• 속도 제한(Rate Limiting) — "이 IP는 1분에 100회까지" 카운터

Part II. 비교편

5. 종합 비교표 (한 장 요약)

그림 7. 4개 서비스를 축(관계형↔비관계형 / 낮은지연↔높은처리량)에 배치한 2×2 매트릭스. 마지막 복습용 한 장 요약 이미지.

6. 시험 시나리오 → 정답 매핑 (암기용)

Part III. 비용·최적화편

여기부터는 같은 아키텍처를 유지하면서 요금을 줄이는 방법이다. SAA 도메인 4(비용 최적화)에서 직접 출제되는 영역이라 개념편과 분리해 정리했다.

7. 서비스별 과금 모델 — 무엇에 돈을 내는가

클라우드 비용을 이해하는 첫 단계는 "무엇에 과금되는가(과금 축)" 를 아는 것이다. 축을 알아야 어디를 줄일지 판단할 수 있다.

핵심 구분: 프로비저닝형 vs 사용량 기반

• 프로비저닝형 — 미리 잡아둔 만큼 계속 낸다. 안 써도 낸다. 대신 단가가 싸다
• 사용량 기반 — 쓴 만큼만 낸다. 유휴 시간엔 거의 0. 대신 단가가 비싸다

그래서 트래픽이 안정적이면 프로비저닝, 변동이 크면 사용량 기반이 유리하다. 이 교차점을 판단하는 게 비용 문제의 본질이다.

그림 8. x축 "트래픽 변동성 / 가동률", y축 "월 비용"으로 두고 프로비저닝형 vs 서버리스형의 비용 곡선이 교차하는 지점(손익분기점)을 표시.

8. RDS 비용 최적화

① 개발/테스트 DB는 중지한다 스냅샷을 만들고 인스턴스를 중지하면 인스턴스 요금이 멈춘다. (스토리지 요금은 계속 나가고, 최대 7일까지 중지 가능하다는 점은 주의) → 예: 팀 개발 DB를 퇴근 시간에 중지하는 Lambda 스케줄을 걸어둔다.

② 리전 간(Cross-Region) 복제본 주의 같은 리전 AZ 간 복제 트래픽은 무료지만, 리전 간 복제는 데이터 전송 요금이 붙는다. "글로벌 서비스를 만들었는데 비용이 예상보다 크다" 유형의 문제에 자주 등장한다.

③ Reserved Instance (예약 인스턴스) 1년/3년 약정으로 큰 폭 할인. 상시 돌아가는 운영 DB에 적합하다. → 판단 기준: 1년 내내 켜둘 게 확실한가? 그렇다면 RI, 아니면 온디맨드.

④ 백업 보존 기간 조정 자동 백업 35일이 항상 정답은 아니다. 규제 요건이 없다면 7일로 줄여도 된다.

⑤ Graviton(ARM) 인스턴스 전환 같은 성능을 더 싸게 낸다. db.r6g, db.r7g 계열.

9. Aurora 비용 최적화

① Serverless v2 + scale-to-zero(0 ACU) 유휴가 긴 개발/스테이징 환경에서 "안 쓰는 시간의 요금"을 사실상 없앨 수 있다. → 예: 개발 DB를 프로비저닝 인스턴스로 켜두면 밤 12시간도 요금이 나가지만, Serverless v2는 트래픽이 없으면 0 ACU로 내려간다.

② Database Savings Plans Serverless v2와 DSQL은 Reserved Instance 대상이 아니다. 할인 경로가 Savings Plans뿐이라는 게 시험 포인트가 될 수 있다.

③ Cloning 활용 Copy-on-Write라 초기 스토리지 비용이 거의 안 든다. 1TB 운영 DB를 통째로 복사하는 것과 비교하면 차이가 크다.

④ I/O-Optimized 구성 Aurora 표준 구성은 I/O 요청 수에 따라 과금된다. 읽기·쓰기가 아주 많은 워크로드라면 I/O 요금이 따로 안 붙는 구성이 총액에서 더 쌀 수 있다. → 판단 기준: 전체 비용에서 I/O가 차지하는 비중이 대략 25%를 넘어가는지.

10. DynamoDB 비용 최적화 (⭐ 출제 빈도 높음)

10-1. 용량 모드 선택

판단 예시

• 사내 근태 시스템: 평일 9~18시에 일정한 트래픽 → 프로비저닝 + Auto Scaling
• 신규 게임 런칭: 얼마나 올지 아무도 모름 → 온디맨드로 시작, 패턴 파악 후 전환

10-2. RCU/WCU 계산 규칙

용량 단위(Capacity Unit) 는 DynamoDB의 처리량 화폐 단위다.

• 1 WCU = 1KB 항목을 초당 1회 쓰기
• 1 RCU = 4KB 항목을 초당 1회 강력한 일관된 읽기 = 4KB 항목 초당 2회 결과적 일관된 읽기
• 크기는 항상 올림 처리한다

계산 예제 1 — 쓰기

3KB짜리 항목을 초당 100회 써야 한다. 3KB ÷ 1KB = 3 → 올림해서 3 WCU × 100회 = 300 WCU

계산 예제 2 — 강력한 일관된 읽기

8KB짜리 항목을 초당 50회 강력한 일관성으로 읽는다. 8KB ÷ 4KB = 2 → 2 RCU × 50회 = 100 RCU

계산 예제 3 — 결과적 일관된 읽기 (같은 조건)

결과적 일관성은 절반만 쓴다 → 100 ÷ 2 = 50 RCU

💡 핵심: 강력한 일관성은 RCU를 2배 먹는다. "비용을 줄이려면?" 하는 문제에서 요구사항이 허용한다면 결과적 일관된 읽기가 정답.

10-3. 그 밖의 절감 수단

• TTL 활성화: 만료 데이터를 자동 삭제해 스토리지 비용을 줄인다. 삭제에는 WCU가 안 든다
• DAX 도입: 반복 읽기를 캐시가 흡수 → RCU 소비 자체가 줄어든다 (성능 + 비용 동시 개선)
• Scan 대신 Query: Scan은 테이블 전체를 읽어 RCU를 크게 소모한다. 100만 건 테이블에서 1건 찾자고 Scan을 쓰면 100만 건어치 RCU를 낸다
• GSI 남발 금지: GSI마다 별도 스토리지 + 별도 쓰기 용량이 발생한다. 테이블에 쓰기 1번 = GSI가 3개면 쓰기가 사실상 4번
• Standard-IA 테이블 클래스: 저장은 많이 하는데 조회가 드문 데이터(로그 아카이브 등)에 적합. 스토리지 단가가 싸고 요청 단가가 비싸다

11. ElastiCache 비용 최적화

① Valkey로 전환 — 사실상 무조건 이득 서버리스 기준 33%, 노드 기반 기준 20% 저렴하다. Redis OSS와 API가 완전 호환이라 코드 수정 없이 무중단 전환이 된다. 예약 노드를 쓰고 있었다면 기존 할인율도 유지된다.

② 서버리스 진입 장벽이 낮아졌다 Valkey 서버리스는 최소 스토리지가 100MB(Redis OSS의 1/10)라 월 $6 수준부터 시작할 수 있다. 사이드 프로젝트나 소규모 서비스에 부담이 적다.

③ 서버리스 vs 노드 기반 — 어느 쪽이 싼가

• 서버리스 과금 = 저장 데이터(GB-시간) + ECPU

  ECPU란? ElastiCache Processing Unit. 서버리스 전용 처리량 단위다. 1KB 전송당 1 ECPU로 계산한다. 4KB짜리 GET 하나 = 4 ECPU. SORT나 Lua 스크립트처럼 CPU를 더 쓰는 명령은 그만큼 더 소모한다.

• 트래픽이 안정적이고 상시 높다면 노드 기반이 더 쌀 수 있다
• 반대로 변동이 크거나 유휴가 길면 서버리스가 유리하다
• 참고로 Valkey 8.0 기준 서버리스는 13분 안에 0 → 500만 RPS까지 스케일된다

④ 캐시 자체가 비용 절감 수단이다 캐시를 붙이면 DB 부하가 줄어서 RDS/Aurora 인스턴스 크기를 낮출 수 있다. 캐시 요금보다 줄어든 DB 요금이 더 큰 경우가 흔하다. → 문제에서 "성능은 유지하면서 DB 비용을 줄여라"가 나오면 캐시를 떠올릴 것.

12. 비용 관점 시나리오 매핑

13. 오늘의 3줄 요약

1. Read Replica는 성능, Multi-AZ는 가용성 — 이 구분만 확실해도 문제 여러 개가 풀린다.
2. Aurora는 스토리지 계층이 다르다 — 3개 AZ에 6개 복제본, 4/6 쓰기 쿼럼이 모든 장점의 근거다.
3. DynamoDB는 접근 패턴을 먼저 설계한다 — 파티션 키 설계 실패 = 핫 파티션 = 스로틀링.

참고 자료

• AWS 공식 문서 — Amazon RDS / Aurora User Guide
• AWS 공식 문서 — Amazon DynamoDB Developer Guide
• AWS 공식 문서 — Amazon ElastiCache User Guide
• AWS What's New — Announcing Amazon ElastiCache for Valkey (2024.10)
• AWS Database Blog — ElastiCache Serverless 비용 최적화

이 글의 목표 1주차에서 배운 Region과 AZ 위에, 실제로 리소스를 올릴 네트워크 공간을 직접 설계해 본다.

• VPC가 왜 필요한가, Default VPC로는 왜 부족한가
• Subnet에서 IP 주소 5개가 사라지는 이유
• Public Subnet과 Private Subnet을 나누는 진짜 기준은 무엇인가
• Route Table, Internet Gateway, NAT Gateway가 만들어내는 트래픽 흐름
• SAA-C03 실전 문제로 확인하는 출제 포인트

1주차에서 IAM이 "누가 무엇을 할 수 있는가"를 통제했다면, 2주차 VPC는 "트래픽이 어디로 갈 수 있는가" 를 통제합니다. 권한과 경로, 이 두 축이 AWS 보안의 뼈대입니다.

1. VPC는 내가 빌린 부지다

VPC(Virtual Private Cloud)는 AWS 안에 만드는 나만의 가상 네트워크입니다. 흔히 쓰는 비유가 잘 들어맞습니다.

• AWS = 거대한 도시
• VPC = 내가 빌린 부지
• Subnet = 부지를 용도별로 나눈 구획
• EC2 = 그 위에 짓는 건물

중요한 건 EC2든 RDS든 반드시 VPC 안에서만 생성된다는 점입니다. 지금까지 네트워크 설정 없이 EC2를 잘 만들 수 있었던 이유는, AWS가 계정 생성 시 만들어 둔 Default VPC를 쓰고 있었기 때문입니다.

문제는 Default VPC가 Public Subnet만 가지고 있다는 것입니다. 여기에 웹 서버, 앱 서버, DB를 다 올려두면 셋 다 인터넷에서 도달 가능한 위치에 놓입니다. DB가 인터넷에 노출되어 있다는 뜻이고, 이건 사고 나기 딱 좋은 구조입니다.

그래서 Custom VPC를 직접 만들고, 인터넷이 닿아도 되는 영역과 닿으면 안 되는 영역을 갈라야 합니다.

2. CIDR: /24인데 왜 251개인가

이번 주에 가장 확실하게 잡고 넘어간 부분입니다.

10.0.0.0/24 서브넷을 만들면 IP는 총 256개입니다. 그런데 실제로 인스턴스에 붙일 수 있는 건 251개뿐입니다. 5개가 사라집니다.

전통적인 네트워크 상식으로는 예약 IP가 2개입니다. 네트워크 주소 하나, 브로드캐스트 주소 하나. 그런데 AWS는 여기에 3개를 더 가져갑니다.

즉 앞의 4개 + 마지막 1개 = 5개입니다. 여기서 두 가지 감각을 얻었습니다.

첫째, VPC는 브로드캐스트를 지원하지 않는데도 .255를 예약합니다. 쓰지도 않을 걸 예약해 두는 이유는 기존 IP 설계 관행과 충돌하지 않기 위해서입니다. 호환성을 위한 자리 비움에 가깝습니다.

둘째, .1과 .2가 예약이라는 건 VPC 라우터와 DNS가 실체를 가진 존재라는 뜻입니다. 서브넷 어디에 인스턴스를 띄우든 게이트웨이는 항상 x.x.x.1이고, DNS resolver는 항상 VPC CIDR base + 2입니다. 이건 나중에 EC2 안에서 /etc/resolv.conf를 열어 보면 그대로 확인됩니다.

작은 서브넷일수록 손해가 크다

서브넷 크기는 최소 /28, 최대 /16입니다.

/28을 쓰면 세 개 중 하나가 날아갑니다. 아껴 쓰겠다고 서브넷을 잘게 쪼개면 오히려 낭비가 커집니다. 실무에서 /24를 기본 단위로 많이 잡는 이유가 여기 있습니다.

3. Subnet: AZ에 묶인다

Subnet은 VPC의 IP 대역을 잘라낸 조각입니다. 여기서 반드시 기억할 제약이 하나 있습니다.

하나의 Subnet은 반드시 하나의 AZ 안에만 존재한다.

Subnet은 AZ 경계를 넘을 수 없습니다. 그래서 고가용성을 원한다면 같은 역할의 서브넷을 AZ마다 하나씩 만들어야 합니다. Public 두 개, Private 두 개, DB 두 개, 이런 식으로 짝을 맞추는 구성이 표준처럼 굳어진 이유입니다.

VPC (10.0.0.0/16)
├─ AZ-a
│  ├─ Public  Subnet 1  (10.0.0.0/24)
│  ├─ Private Subnet 1  (10.0.2.0/24)
│  └─ DB      Subnet 1  (10.0.4.0/24)
└─ AZ-c
   ├─ Public  Subnet 2  (10.0.1.0/24)
   ├─ Private Subnet 2  (10.0.3.0/24)
   └─ DB      Subnet 2  (10.0.5.0/24)

Public과 Private을 나누는 기준

여기서 오해하기 쉬운 지점입니다. 서브넷을 만들 때 "Public"이라는 체크박스를 켜는 게 아닙니다.

Route Table에 Internet Gateway로 가는 경로가 있으면 Public Subnet, 없으면 Private Subnet입니다.

서브넷의 성격은 라우팅으로 결정되는 결과이지, 서브넷 자체의 속성이 아닙니다. 이름을 public-subnet이라고 지어도 IGW 경로가 없으면 그건 Private Subnet입니다.

4. Route Table: 정보가 없으면 드롭된다

Route Table은 "이 목적지로 가는 트래픽은 저기로 보내라"는 규칙 목록입니다. 모든 서브넷은 정확히 하나의 Route Table에 연결됩니다. 명시적으로 연결하지 않으면 VPC의 Main Route Table이 자동 적용됩니다.

Local route는 지울 수 없다

VPC를 만들면 Route Table에 이 규칙이 자동으로 박힙니다.

이 local 경로는 삭제할 수 없습니다. VPC 안의 모든 서브넷은 서로 통신 가능하다는 뜻이고, 이건 라우팅으로 막을 수 없다는 뜻이기도 합니다. 서브넷 사이의 접근 통제는 Security Group이나 NACL로 해야 합니다. (뒤의 SAA 문제에서 그대로 나옵니다.)

Public Route Table

0.0.0.0/0은 "나머지 전부"라는 뜻입니다. 그런데 10.0.0.0/16도 0.0.0.0/0에 포함되지 않나요? 여기서 LPM(Longest Prefix Match) 이 등장합니다.

라우팅은 prefix가 긴 규칙, 즉 범위가 좁은 규칙을 먼저 적용합니다. /16이 /0보다 길기 때문에, VPC 내부로 가는 트래픽은 먼저 local로 처리되고, 거기 걸리지 않은 나머지만 IGW로 나갑니다. 그래서 0.0.0.0/0은 "모든 트래픽"이 아니라 실질적으로 "그 외 전부"로 동작합니다.

Private Route Table

0.0.0.0/0 규칙이 없습니다. 목적지를 모르는 트래픽은 어디로 보낼지 결정할 수 없으므로 그냥 드롭됩니다.

"정보가 없으면 드롭" 이게 AWS 망 분리의 핵심입니다. Security Group이나 NACL로 막는 게 아니라, 애초에 나갈 길 자체를 만들어 주지 않는 것입니다.

5. Internet Gateway: 문을 다는 것과 길을 내는 것

IGW는 VPC와 인터넷을 잇는 관문입니다. VPC당 하나만 붙일 수 있습니다.

여기서 초보자가 흔히 막히는 지점이 있습니다.

IGW를 VPC에 attach했다고 해서 인터넷이 연결되는 게 아니다.

인스턴스가 인터넷과 통신하려면 세 가지가 전부 갖춰져야 합니다.

1. IGW가 VPC에 attach되어 있을 것
2. 서브넷의 Route Table에 0.0.0.0/0 → IGW 경로가 있을 것
3. 인스턴스에 Public IP 또는 Elastic IP가 붙어 있을 것

문(IGW)을 달았다고 길(Route)이 생기는 게 아니고, 길이 있다고 주소(Public IP)가 생기는 것도 아닙니다. 셋 중 하나라도 빠지면 통신은 실패합니다. 트러블슈팅할 때 이 세 가지를 순서대로 확인하는 습관을 들이면 좋습니다.

6. NAT Gateway: Private Subnet이 인터넷을 쓰는 법

Private Subnet의 인스턴스도 인터넷이 필요합니다. apt update도 해야 하고, 외부 API도 호출해야 합니다. 하지만 인터넷에서 들어오는 접근은 막아야 합니다.

즉 필요한 건 outbound만 열린 단방향 통로이고, 그게 NAT Gateway입니다.

흐름을 따라가 보면

이번 주에 가장 헷갈렸던 부분인데, 정리하니 명확해졌습니다. Private Subnet의 트래픽은 결국 Public Subnet의 라우팅을 타고 나갑니다.

[Private Subnet의 EC2]
        │  ① Private Route Table: 0.0.0.0/0 → NAT Gateway
        ▼
[NAT Gateway]  ← 이 친구는 Public Subnet에 산다
        │  ② Source IP를 NAT의 Elastic IP로 변환
        │  ③ Public Route Table: 0.0.0.0/0 → IGW
        ▼
[Internet Gateway]
        ▼
     [Internet]

핵심은 두 가지입니다.

첫째, NAT Gateway는 Public Subnet에 배치합니다. Private Subnet에 두면 NAT 자신이 인터넷으로 나갈 길이 없습니다. 처음엔 이게 직관에 반하는 느낌인데, "NAT는 Private을 위한 장비지만, NAT 자신은 인터넷에 닿아야 한다"고 생각하면 자연스럽습니다.

둘째, NAT Gateway는 Elastic IP를 하나 물고 있습니다. Private 인스턴스가 보낸 패킷의 출발지 주소를 이 EIP로 바꿔 치기 때문에, 외부 서버는 응답을 NAT로 돌려보냅니다. 반대로 외부에서 먼저 연결을 시작할 방법은 없습니다. 여기서 단방향이 성립합니다.

고가용성 함정

NAT Gateway는 AZ 단위 리소스입니다. AZ-a에 NAT 하나만 두고 두 AZ의 Private Subnet이 모두 그걸 바라보게 하면, AZ-a가 죽는 순간 AZ-c의 인스턴스도 인터넷이 끊깁니다.

프로덕션에서는 AZ마다 NAT Gateway를 하나씩 두고, 각 AZ의 Private Route Table이 자기 AZ의 NAT를 가리키게 합니다. 가용성이 올라가는 대신 비용도 올라갑니다.

비용 감각

NAT Gateway는 두 가지 요금이 붙습니다.

• 시간당 요금 (인스턴스처럼 켜져 있는 동안 계속)
• 처리 데이터 GB당 요금

AZ마다 하나씩 두면 시간당 요금도 그만큼 곱해집니다. 그리고 S3나 DynamoDB로 나가는 트래픽까지 NAT를 태우면 데이터 처리 요금이 눈덩이처럼 불어납니다. 이 지점이 SAA 비용 최적화 문제의 단골 소재이고, 정답은 대개 VPC Endpoint입니다. 바로 아래에서 봅니다.

NAT Gateway vs NAT Instance

시험에서 NAT Instance가 정답인 경우는 거의 없습니다. "운영 부담 최소화"라는 문구가 보이면 NAT Gateway입니다.

7. DB Subnet은 Route Table을 건드리지 않는다

Public, Private까지 만들었으면 DB 전용 서브넷이 남습니다. 결론부터 말하면 DB Subnet은 Route Table을 따로 설정할 필요가 없습니다.

"RDS도 패치와 업데이트가 필요할 텐데?"라는 의문이 드는데, RDS는 관리형 서비스라서 AWS 내부 인프라를 통해 스스로 업데이트합니다. 사용자의 VPC 라우팅을 거치지 않습니다.

그래서 DB Subnet은 아무 Route Table에도 연결하지 않고 놔두면 됩니다. 그러면 Main Route Table이 적용되고, 거기엔 10.0.0.0/16 → local 하나만 있습니다. VPC 내부 통신만 되고 인터넷은 완전히 차단된 상태, 딱 원하던 그림입니다.

8. VPC Endpoint: NAT를 우회하는 지름길

Private Subnet의 EC2가 S3에 접근해야 한다고 해봅시다. 순진하게 생각하면 NAT Gateway를 태워야 합니다. 그런데 S3는 AWS 서비스인데, 굳이 인터넷 밖으로 나갔다 들어와야 할까요?

VPC Endpoint는 VPC에서 AWS 서비스로 가는 프라이빗 경로를 만들어 줍니다. 인터넷도 NAT도 거치지 않습니다.

Gateway Endpoint가 시험에서 특히 자주 나옵니다. S3나 DynamoDB + 프라이빗 접근 + 비용 최적화 조합이 보이면 거의 정답입니다. 무료인데다 NAT 데이터 처리 요금까지 없애 주니 이길 수가 없습니다.

9. Security Group vs NACL 한 장 정리

라우팅이 "길"이라면, 이 둘은 "검문소"입니다.

여기서 시험에 직결되는 두 가지가 있습니다.

Security Group은 Deny 규칙을 쓸 수 없습니다. "특정 대상만 차단"은 SG로 구현할 수 없고 NACL을 써야 합니다.

Security Group은 다른 Security Group을 source로 지정할 수 있습니다. IP 대역이 아니라 sg-app-server를 소스로 걸면, 그 SG를 단 인스턴스만 통과합니다. 인스턴스가 늘어나든 IP가 바뀌든 규칙을 고칠 필요가 없습니다. 이걸 Security Group Referencing이라고 부르는데, AWS가 가장 권장하는 패턴입니다.

시험에서 이렇게 나온다 (SAA-C03 실전)

교재로 쓰는 SAA-C03 샘플에서 이번 주 범위에 걸리는 문제들을 뽑았습니다.

Q1. Private 접근 경로 만들기

VPC 안의 EC2가 S3 버킷의 로그를 처리해야 한다. 인터넷을 거치지 않고 S3에 접근하려면?

A. S3용 Gateway VPC Endpoint 생성 B. CloudWatch Logs로 스트리밍 후 S3로 export C. EC2에 Instance Profile(IAM Role) 생성 D. PrivateLink를 쓰는 API Gateway 구성

정답: A

함정은 C입니다. IAM Role은 권한을 주지, 경로를 만들지 않습니다. Role이 있어도 네트워크 경로가 없으면 패킷은 목적지에 닿지 못합니다.

권한(IAM)과 경로(Routing)는 별개의 축이다.

1주차 IAM과 2주차 VPC가 여기서 정확히 맞물립니다. 이 문제 하나만 제대로 이해해도 두 주차를 다 소화한 셈입니다.

Q2. NAT Gateway 비용 최적화

여러 AZ에 걸친 EC2들이 단일 NAT Gateway를 통해 S3와 이미지를 주고받는다. 데이터 전송 요금을 줄이려면?

A. AZ마다 NAT Gateway 생성 B. NAT Gateway를 NAT Instance로 교체 C. S3용 Gateway VPC Endpoint 배포 D. EC2 Dedicated Host 프로비저닝

정답: C

A가 매력적인 오답입니다. AZ 간 데이터 전송 요금은 줄어들지만 NAT Gateway 시간당 요금과 GB당 요금이 배로 늘어납니다. 비용을 줄이려다 늘리는 셈입니다.

Gateway Endpoint는 무료이고, S3 트래픽을 AWS 내부 네트워크로 직접 흘려보냅니다. NAT를 아예 거치지 않으니 데이터 처리 요금 자체가 사라집니다.

"S3 + NAT + 비용"이 한 문제에 같이 등장하면 Gateway Endpoint를 먼저 의심하라.

Q3. Subnet 사이 접근 통제

2개 AZ에 Public, Private, DB 서브넷이 각각 있어 총 6개. Private Subnet의 EC2만 RDS에 접근하게 하려면?

A. Public Subnet CIDR로 가는 경로를 뺀 Route Table을 DB Subnet에 연결 B. Public Subnet 인스턴스의 SG를 Deny하는 SG를 DB에 연결 C. Private Subnet 인스턴스의 SG를 source로 Allow하는 SG를 DB에 연결 D. Subnet 사이에 VPC Peering 연결 생성

정답: C

세 개의 오답이 각각 앞에서 짚은 개념을 정확히 저격합니다.

• A가 틀린 이유: local 경로는 삭제할 수 없습니다. VPC 내부 통신을 Route Table로 막는 건 원천적으로 불가능합니다. (4장)
• B가 틀린 이유: Security Group은 Deny 규칙이 없습니다. Allow만 가능합니다. (9장)
• D가 틀린 이유: VPC Peering은 VPC 사이를 잇는 기능이지, 같은 VPC 안의 서브넷용이 아닙니다.

정답 C는 Security Group Referencing입니다. SG는 stateful이므로 응답 트래픽은 자동으로 허용됩니다.

2주차 핵심 정리

1. VPC는 내가 설계하는 가상 네트워크. Default VPC는 Public Subnet뿐이라 실서비스에 부적합하다.
2. Subnet의 IP는 5개가 예약된다. 앞 4개(.0 .1 .2 .3)와 마지막 1개(broadcast). /24는 251개만 쓸 수 있다.
3. Subnet은 AZ를 넘을 수 없다. 고가용성을 원하면 AZ마다 짝을 맞춰 만든다.
4. Public / Private을 가르는 건 Route Table이다. IGW 경로가 있으면 Public, 없으면 Private.
5. local 경로는 삭제할 수 없다. 서브넷 사이 통제는 Security Group과 NACL의 몫.
6. 인터넷 연결의 3요소: IGW attach + Route + Public IP. 하나라도 빠지면 안 된다.
7. NAT Gateway는 Public Subnet에 산다. Private 트래픽은 NAT를 거쳐 IGW로 나간다. AZ 단위 리소스이므로 AZ마다 배치해야 진짜 HA다.
8. S3, DynamoDB는 Gateway Endpoint. 무료이고, NAT 데이터 처리 요금을 없앤다.
9. Security Group은 Allow만, stateful. NACL은 Deny 가능, stateless.

다음 주 예고

3주차는 EC2와 EBS입니다. 이번 주에 만든 Subnet 위에 실제로 인스턴스를 올리고, 인스턴스 타입과 구매 옵션(On-Demand, Reserved, Spot), 스토리지 선택으로 넘어갑니다.

돌아보면 흐름이 이렇게 이어집니다.

1주차 Part 1: 리소스를 어디에 둘 것인가 (Region, AZ) 1주차 Part 2: 누구에게 열어 줄 것인가 (IAM) 2주차: 트래픽이 어떻게 흐를 것인가 (VPC) 3주차: 그 위에 무엇을 올릴 것인가 (EC2)

AWS의 모든 서비스가 결국 이 네 질문의 반복이라는 걸, 2주차를 지나며 조금씩 체감하고 있습니다.

참고 자료

• AWS 공식 문서 — 서브넷 CIDR 블록
• AWS 공식 문서 — VPC의 서브넷
• wikidocs — AWS 직원이 알려주는 AWS 클라우드 아키텍처, 08장 VPC 사용하기
• AWS SAA-C03 Korean Sample (Q004, Q042, Q055)

이 글의 목표 Part 1에서 만든 인프라 위에서 "권한"을 통제하는 방법을 이해한다.

• 루트 사용자 vs IAM 사용자 — 왜 루트를 쓰면 안 되는가
• IAM 4대 구성요소: 사용자 / 그룹 / 정책 / 역할
• 사용자 vs 역할을 언제 쓰는가 (SAA 단골 주제)
• AWS를 제어하는 3가지 방법(콘솔·CLI·SDK)과 액세스 키
• 2024~2025년에 강화된 루트 MFA 의무화 등 최신 보안 정책

IAM은 글로벌 서비스입니다(Part 1 복습). 리전에 묶이지 않고 계정 전체에 적용됩니다.

1. 출발점: 공동 책임 모델과 IAM의 위치

AWS 보안은 공동 책임 모델(Shared Responsibility Model) 로 나뉩니다.

• AWS의 책임 ("of the cloud"): 데이터센터, 하드웨어, 물리 네트워크 등 클라우드 자체의 보안.
• 고객의 책임 ("in the cloud"): 그 위에 올린 데이터·설정·접근 권한의 보안.

이 "고객의 책임" 중 가장 근본이 되는 것이 IAM(Identity and Access Management) 입니다. IAM은 한 문장으로 요약하면:

"어떤 주체(누가)가 · 어떤 리소스(무엇)에 · 어떤 행동(어떻게)을 할 수 있는지 정의하는 시스템"

2. 루트 사용자 vs IAM 사용자

2-1. 루트 사용자(Root User)란

AWS 계정을 처음 만들 때 쓴 이메일 + 비밀번호의 주인이 루트 사용자입니다. 루트는 계정 안의 모든 것에 무제한 권한을 가집니다. 말 그대로 신(神)입니다.

문제는 바로 이 무제한성입니다. 루트 자격 증명이 유출되면 계정 전체가 그대로 넘어갑니다 — 리소스 삭제, 청구 정보 변경, 심지어 계정 폐쇄까지.

2-2. 그래서 루트는 "봉인"한다

모범 사례(Best Practice)는 루트를 일상 업무에 절대 쓰지 않는 것입니다. 대신:

1. 루트로 최초 로그인 → 관리자(Admin) 권한을 가진 IAM 사용자를 하나 만든다.
2. 이후 모든 작업은 그 IAM 사용자로 한다.
3. 루트는 MFA를 걸고 봉인한 뒤, 정말 루트만 할 수 있는 일이 있을 때만 꺼낸다.

루트만 할 수 있는 일 (일부):

• 계정 설정 변경(이메일, 루트 비밀번호)
• 지원 플랜 변경, 계정 폐쇄
• 특정 결제/세금 설정
• 일부 예외적 S3/GovCloud 작업

💡 이 목록은 통째로 외우기보다 "아주 예외적인, 계정 자체에 관한 일"이라는 감각으로 기억하면 됩니다.

2-3. 🔒 최신 보안 정책: 루트 MFA 의무화 (2024~2025)

여기는 최근에 크게 바뀐 부분이라 발표 때 짚어주면 좋습니다.

AWS는 모든 계정 유형의 루트 사용자에게 MFA를 의무화했습니다.

• 2024년 5월: AWS Organizations 관리 계정 루트부터 시작
• 2024년 6월: 독립(standalone) 계정 루트로 확대
• 2025년: 멤버 계정 루트까지 확대 → 결과적으로 모든 계정 유형에 적용

또한 콘솔 최초 로그인 후 35일 이내에 MFA를 등록하지 않으면 접근이 제한됩니다. 즉 이제 "루트 MFA는 선택"이 아니라 사실상 강제입니다.

💡 SAA/실무 시사점: "루트 계정을 안전하게 보호하려면?"의 정답은 항상 MFA 활성화 + 루트 사용 자제 + 액세스 키 미발급입니다.

3. IAM 4대 구성요소

IAM을 이해하는 핵심 뼈대는 다음 4가지입니다.

사용자(User) ──┐
그룹(Group) ───┼── 에 → 정책(Policy)을 붙여 권한을 부여
역할(Role) ────┘

3-1. 사용자 (User)

사람 또는 애플리케이션 하나에 대응하는 고정된 자격 증명입니다.

• 로그인 자격(콘솔용 비밀번호)이나 프로그래밍 자격(액세스 키)을 가질 수 있습니다.
• 각 사용자는 독립적입니다. 개발자 A, 개발자 B는 각각의 IAM 사용자.

3-2. 그룹 (Group)

여러 사용자를 묶어 권한을 한꺼번에 관리하는 단위입니다.

• 예: Developers 그룹에 개발 권한 정책을 붙이고, 신입 개발자를 그 그룹에 넣으면 끝.
• 그룹에는 정책을 붙일 수 있지만, 그룹 자체는 로그인할 수 없습니다. (그룹은 "권한 묶음"일 뿐, 주체가 아님)
• 그룹은 사용자만 담을 수 있습니다. 그룹 안에 그룹을 중첩할 수 없습니다.

💡 실무 원칙: 개별 사용자에게 직접 정책을 붙이지 말고, 그룹으로 관리하세요. 사람이 늘어나도 관리가 깔끔합니다.

3-3. 정책 (Policy)

"무엇을 할 수 있는지"를 정의한 JSON 문서입니다. IAM의 실질적 권한은 전부 정책에서 나옵니다.

정책의 기본 구조:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-study-bucket/*"
    }
  ]
}

핵심 필드 4가지:

• Effect: Allow(허용) 또는 Deny(거부)
• Action: 어떤 행동인가 (예: s3:GetObject)
• Resource: 어떤 리소스에 대해서인가 (ARN으로 지정)
• Condition(선택): 어떤 조건에서만 (예: MFA를 썼을 때만, 특정 IP에서만)

정책 평가의 철칙 — 명시적 거부(Explicit Deny) 우선:

• 기본값은 모든 것이 거부(Deny) 입니다.
• Allow가 하나라도 있으면 허용됩니다.
• 그러나 Deny가 하나라도 있으면, 다른 데서 Allow해도 무조건 거부됩니다.

💡 시험 단골: "사용자에게 Allow와 Deny가 동시에 적용되면?" → Deny가 이긴다.

정책 종류:

• 관리형 정책(Managed Policy): AWS가 미리 만들어 둔 것(예: AmazonS3ReadOnlyAccess) 또는 고객이 만든 재사용 가능한 정책.
• 인라인 정책(Inline Policy): 특정 사용자/그룹/역할에 1:1로 박아넣는 정책. 재사용 불가.

3-4. 역할 (Role) — 가장 중요하고 가장 헷갈리는 것

역할은 "특정 권한 묶음을, 필요할 때 임시로 빌려 쓰는 신분" 입니다. 사용자처럼 고정된 비밀번호나 액세스 키가 없고, 대신 필요할 때 임시 자격 증명(temporary credentials) 을 발급받아 사용합니다.

역할이 왜 중요한가? 자격 증명을 코드나 서버에 심지 않아도 되기 때문입니다.

대표적인 3가지 사용 패턴:

1. AWS 서비스에 권한 주기 (서비스 역할)

   • 예: EC2 인스턴스가 S3에 접근해야 한다.
   • ❌ 나쁜 방법: 인스턴스 안에 액세스 키를 하드코딩 (유출 위험)
   • ✅ 좋은 방법: S3 접근 역할을 만들어 EC2에 부여. EC2는 임시 자격 증명을 자동으로 받아 S3에 접근.

2. 계정 간 접근 (Cross-Account Role)

   • 예: 운영 계정의 사용자가 개발 계정의 리소스에 접근해야 한다.
   • 개발 계정에 역할을 만들고, 운영 계정이 그 역할을 AssumeRole(맡기)해서 잠깐 권한을 빌린다.

3. 외부 사용자에게 임시 권한 주기 (연합, Federation)

   • 회사 사내 계정(예: Google, Active Directory)으로 로그인한 사람에게, IAM 사용자를 따로 만들지 않고 역할로 임시 접근을 준다.

💡 핵심 감각: 역할 = "빌려 쓰는 임시 권한". 누가/무엇이 이 역할을 맡을 수 있는지는 신뢰 정책(Trust Policy) 이 정의합니다.

4. 사용자 vs 역할 — 언제 무엇을 쓰나 (SAA 최다 출제)

💡 한 줄 규칙: "EC2가 S3에 접근하려면?" 같은 문제에서 액세스 키를 심는 선택지는 거의 항상 오답이고, 역할 부여가 정답입니다. 이거 하나만 확실히 잡아도 문제 여러 개를 맞힙니다.

5. AWS를 제어하는 3가지 방법과 액세스 키

같은 IAM 권한이라도, AWS를 조작하는 경로는 3가지입니다.

액세스 키(Access Key) 는 CLI/SDK가 프로그래밍 방식으로 AWS를 호출할 때 쓰는 자격 증명입니다.

• 액세스 키 ID (공개된 식별자) + 비밀 액세스 키(Secret) 한 쌍.
• 비밀 키는 발급 시 딱 한 번만 보여줍니다. 놓치면 재발급해야 합니다.
• 절대 코드/깃허브에 커밋하면 안 됩니다. (유출 사고의 최다 원인)

💡 모범 사례: 서버·앱이 AWS를 호출해야 한다면, 장기 액세스 키 대신 역할(Role)의 임시 자격 증명을 쓰세요. 키 유출 위험 자체를 없앨 수 있습니다. 루트에는 액세스 키를 아예 발급하지 마세요.

6. 계정 보안 베스트 프랙티스 체크리스트

• 루트 사용자에 MFA 활성화 (2024~2025년부터 사실상 의무)
• 루트 일상 사용 금지 — Admin IAM 사용자를 만들어 그걸로 작업
• 루트에 액세스 키 미발급
• 모든 IAM 사용자/그룹에 최소 권한 원칙(Least Privilege) 적용
• 권한은 그룹 단위로 관리
• 서비스 간 접근은 키가 아니라 역할(Role) 로
• 액세스 키는 정기적으로 교체(rotate), 코드에 하드코딩 금지
• 활동 추적을 위해 CloudTrail 활성화 (누가 무엇을 했는지 기록)

7. 1주차 Part 2 핵심 정리

• IAM은 글로벌 서비스. "누가 · 무엇에 · 어떻게"를 통제한다.
• 루트는 무제한 권한 → 봉인. MFA 걸고, 일상은 Admin IAM 사용자로.
• 4대 요소: 사용자(주체) · 그룹(권한 묶음) · 정책(JSON으로 권한 정의) · 역할(임시로 빌려 쓰는 권한).
• 정책은 기본 거부, Allow로 열고, Deny가 최우선.
• 서비스/계정 간 접근은 역할 — 키 하드코딩은 오답.
• 제어 경로 3가지: 콘솔(사람) · CLI(터미널) · SDK(코드). 프로그래밍 접근엔 액세스 키 또는 역할.

✅ 시험에서 이렇게 나온다 (연습용 질문)

1. "EC2 인스턴스가 S3 버킷을 읽어야 한다. 가장 안전한 방법은?" → IAM 역할을 EC2에 부여 (액세스 키 하드코딩은 오답)
2. "한 사용자에게 S3 Allow 정책과 S3 Deny 정책이 동시에 적용된다. 결과는?" → 거부(Deny 우선)
3. "루트 계정을 보호하는 첫 번째 조치는?" → MFA 활성화
4. "운영 계정 사용자가 개발 계정 리소스에 접근해야 한다." → Cross-Account Role + AssumeRole
5. "개발자 20명에게 동일한 개발 권한을 효율적으로 주려면?" → 그룹을 만들어 정책을 붙이고 사용자를 그룹에 추가

📌 1주차 전체 흐름 요약: Part 1에서 인프라(리전·AZ·엣지) 라는 "배경"을 , Part 2에서 권한(IAM) 이라는 "출입 통제"를 이해했습니다.

2주차부터 EC2·VPC·S3 같은 개별 서비스로 들어가면, 결국 전부 "어느 리전/AZ에 두고, 누구에게 어떤 권한으로 열어줄 것인가"의 반복이라는 걸 알게 됩니다.

이 글의 목표 AWS를 "서비스 이름 암기"로 접근하지 않기 위한 베이스를 만든다.

• 왜 클라우드를 쓰는가 (온프레미스와 뭐가 다른가)
• 리전 / 가용 영역(AZ) / 엣지 로케이션이 각각 무엇이고 왜 나뉘어 있는가
• 리전 서비스 vs 글로벌 서비스의 차이 — SAA에서 은근히 헷갈리는 포인트

SAA 시험은 "이 상황에서 어떤 구조가 맞는가"를 묻습니다. 그 판단의 90%는 결국 어디에(리전/AZ) 무엇을 배치하느냐로 연결되기 때문에, 인프라 개념이 1주차의 핵심이라 생각합니다.

1. 왜 클라우드인가: 온프레미스의 단점

클라우드를 이해하는 가장 빠른 길은 "직접 서버를 사서 운영하면 뭐가 힘든가"를 떠올리는 것입니다.

쇼핑몰 서버를 회사 전산실(온프레미스)에 직접 뒀다고 해봅시다. 다음과 같은 문제들이 생깁니다.

• 선투자 부담: 트래픽이 늘어날지 확신도 없는데 서버·네트워크 장비를 미리 사야 한다.
• 용량 예측 실패: 너무 적게 사면 트래픽 몰릴 때 터지고, 너무 많이 사면 대부분 놀린다.
• 확장 속도: 서버 한 대 더 늘리는 데 발주 → 배송 → 설치 → 세팅으로 수 주가 걸린다.
• 장애 대응: 정전, 냉방 고장, 화재 같은 물리적 사고 한 번에 서비스 전체가 죽는다.
• 운영 인력: 하드웨어 교체, 백업, 보안 패치를 전부 사람이 직접 챙겨야 한다.

클라우드는 이 문제들을 "필요한 만큼 빌려 쓰고, 쓴 만큼 낸다"로 뒤집습니다.

CapEx -> OpEx 전환

💡 SAA 관점: 시험에서 "초기 비용을 줄이고 싶다", "수요가 불규칙하다", "빠르게 글로벌 출시해야 한다" 같은 키워드가 나오면 클라우드의 탄력성(Elasticity) 과 종량제(Pay-as-you-go) 를 떠올리면 됩니다.

2. AWS 글로벌 인프라의 3층 구조

AWS의 물리적 세계는 크게 리전(Region) → 가용 영역(AZ) → 데이터센터로 내려가는 계층으로 되어 있고, 여기에 사용자와 가까운 곳에 두는 엣지 로케이션(Edge Location) 이 별도로 붙습니다.

지구
 └─ 리전 (예: 서울 ap-northeast-2)
     ├─ 가용 영역 A (AZ) ── 데이터센터 1..N
     ├─ 가용 영역 B (AZ) ── 데이터센터 1..N
     └─ 가용 영역 C (AZ) ── 데이터센터 1..N

엣지 로케이션 (전 세계 수백 곳) ── CloudFront 캐시 등

2-1. 리전 (Region)

리전은 지리적으로 완전히 분리된 하나의 영역입니다. 서울, 도쿄, 버지니아 북부, 프랑크푸르트처럼 도시 단위로 존재하고, 각 리전은 ap-northeast-2(서울) 같은 고유 코드를 가집니다.

핵심 성질:

• 리전끼리는 물리적으로 독립입니다. 한 리전에 장애가 나도 다른 리전엔 영향이 없습니다.
• 리전 간 데이터는 명시적으로 복제하지 않는 한 자동으로 넘어가지 않습니다. (데이터 주권/규정 준수와 직결)
• AWS는 2026년 기준 약 39개의 리전을 운영 중이고, 계속 늘어납니다. (정확한 수치는 AWS 글로벌 인프라 공식 페이지에서 확인)

2-2. 가용 영역 (Availability Zone, AZ)

AZ는 리전 안에 있는, 서로 물리적으로 떨어진 하나 이상의 데이터센터 묶음입니다.

• 각 리전은 최소 3개의 AZ로 구성됩니다.
• 각 AZ는 독립된 전력·냉방·네트워크를 가집니다. 그래서 한 AZ가 정전으로 죽어도 다른 AZ는 멀쩡합니다.
• 하지만 같은 리전의 AZ끼리는 초저지연 전용 네트워크로 연결돼 있어서, 마치 한 곳처럼 빠르게 통신합니다.

이 "떨어져 있지만 빠르게 연결됨"이 AWS 고가용성 설계의 핵심입니다. 웹 서버를 AZ-A와 AZ-B에 나눠서 띄우면, A가 통째로 죽어도 B가 서비스를 계속합니다. 이게 뒤에 배울 Multi-AZ 아키텍처의 원리입니다.

2-3. 엣지 로케이션 (Edge Location)

엣지 로케이션은 리전·AZ보다 훨씬 촘촘하게, 사용자 가까이에 배치된 캐시 거점입니다.

• 리전/AZ가 "연산과 저장의 본진"이라면, 엣지는 "사용자 코앞의 배달 창고"입니다.
• CloudFront(CDN) 가 대표적으로 이걸 씁니다. 서울 사용자가 미국 리전의 이미지를 요청해도, 서울 근처 엣지에 캐시가 있으면 거기서 바로 응답해 빠릅니다.
• Route 53(DNS)도 엣지 네트워크를 활용합니다.

(참고) Local Zones / Wavelength

시험 비중은 낮지만 개념만 알아두면 좋습니다.

• Local Zones: 리전보다 더 사용자 가까운 곳에 컴퓨팅/스토리지 일부를 두어, 초저지연(한 자릿수 ms)이 필요한 워크로드(실시간 게임, 미디어 편집 등)를 지원.
• Wavelength: 통신사 5G 네트워크 안에 AWS 인프라를 넣어 모바일 초저지연을 지원.

3. 리전은 어떻게 고르는가

리전 선택은 SAA에서 자주 나오는 실무 판단입니다. 기준은 4가지입니다.

1. 지연 시간(Latency): 사용자와 가까운 리전일수록 빠릅니다. 한국 사용자 → 서울 리전.
2. 규정 준수(Compliance): "데이터가 국경을 넘으면 안 된다"는 규제(GDPR 등)가 있으면 특정 리전에 묶어야 합니다.
3. 서비스 가용성(Service Availability): 모든 리전이 모든 서비스를 제공하진 않습니다. 신규/특수 서비스는 특정 리전에만 있을 수 있습니다.
4. 비용(Cost): 같은 서비스라도 리전마다 가격이 다릅니다. 일반적으로 버지니아 북부(us-east-1)가 저렴한 편입니다.

💡 시험 팁: "유럽 사용자 데이터는 유럽 밖으로 나가면 안 된다" → 규정 준수 → 유럽 리전 고정. "지연 시간을 줄이고 싶다" → 사용자와 가까운 리전 + 필요하면 CloudFront(엣지).

4. 리전 서비스 vs 글로벌 서비스 — 헷갈리면 손해 보는 포인트

AWS 서비스는 "어느 범위에서 동작하느냐"에 따라 나뉩니다. SAA에서 조용히 함정으로 나옵니다.

여기서 자주 나오는 오해 몇 가지:

• IAM은 글로벌입니다. 사용자·역할·정책은 리전을 가리지 않고 계정 전체에 적용됩니다.
• S3는 리전 서비스입니다. 버킷은 특정 리전에 만들어집니다. 다만 버킷 이름(네임스페이스)은 전 세계에서 유일해야 해서 "글로벌"처럼 느껴질 뿐입니다. 이 둘을 구분하세요.
• EBS 볼륨은 AZ에 묶입니다. 그래서 AZ-A의 EBS를 AZ-B의 인스턴스에 그냥 붙일 수 없습니다. (스냅샷을 떠서 옮겨야 함)

💡 한 줄 요약: "이 리소스가 죽으면 영향 범위가 어디까지인가?"를 생각하면 범위가 잡힙니다. AZ 서비스는 AZ 단위로, 리전 서비스는 리전 단위로 격리됩니다.

5. 1주차 Part 1 핵심 정리

• 클라우드는 온프레미스의 선투자·확장 지연·물리 장애 문제를 종량제·탄력성으로 해결한다. (CapEx → OpEx)
• 리전 = 지리적으로 독립된 영역, 리전 간 데이터는 자동 복제 안 됨 → 규정 준수의 핵심.
• AZ = 리전 안의 물리적으로 분리된 데이터센터 묶음, 최소 3개, 초저지연 연결 → 고가용성의 핵심.
• 엣지 로케이션 = 사용자 코앞의 캐시 거점 → CloudFront/Route 53, 지연 시간 개선의 핵심.
• 서비스는 글로벌 / 리전 / AZ 범위로 나뉜다. IAM·Route 53·CloudFront는 글로벌, S3는 리전(단 버킷 이름은 전역 유일), EBS는 AZ.

✅ 시험에서 이렇게 나온다 (연습용 질문)

1. "한 데이터센터에 정전이 나도 웹 서비스가 계속 동작해야 한다." → 여러 AZ에 분산 배치 (Multi-AZ)
2. "미국에 있는 원본 이미지를 아시아 사용자에게 빠르게 전달하고 싶다." → CloudFront(엣지 로케이션 캐시)
3. "유럽 고객 데이터는 반드시 유럽 안에 머물러야 한다." → 유럽 리전 선택 + 리전 간 복제 금지
4. "IAM 사용자를 서울 리전에서만 쓸 수 있게 제한하고 싶다." → 함정. IAM은 글로벌이라 리전에 묶이지 않는다.

디자인도 이쁘고 코드도 이쁘게 짤 순 없을까??

이 단순한 생각에서 이 글 시리즈를 작성하게 된 계기가 되었습니다! (대 바이브코딩 시대에, 문서보고 코드짜는 멋쟁이가 되고 싶어...)

리액트를 직접 만든 사람들은 어떻게 생각하고 만들었을까?

React 공식 문서 Thinking in React를 단순히 ‘컴포넌트 나누는 방법’으로 보는 것이 아니라,

제가 열심히 해체 분석해보려 합니다! shout out to sAewoo

React의 본질적 철학(순수 함수 UI, 책임 분리, 단방향 데이터 흐름, 예측 가능성) 관점에서 알아보려고 합니다.

이 관점을 기반으로 다음을 얻을 수 있습니다!:

• React가 왜 이런 방식으로 UI를 구성하도록 가이드를 제시하는지 철학적 이유

• 컴포넌트 설계가 ‘감’에서 ‘원리 기반 판단’으로 전환하기.(추구했던 바!!)

목차

1. Thinking in React 5단계의 나만의 해석
2. 상태 배치(State Architecture)를 판단하는 기준
3. 단방향 데이터 흐름과 예측 가능성 확보

1. UI = f(state): 왜 이 식이 필요할까?

React를 진지하게 이해하려면, 먼저 이 한 줄을 이해해야 한다.

UI = f(state)

React 제작자 들이 하고 싶은 말은 단순하다.

“UI는 직접 조작하는 대상이 아니라, 상태(state)를 넣으면 계산되어 나오는 결과물이어야 한다.”

이 식이 왜 필요한지, 그리고 이게 무너지면 어떤 지옥이 펼쳐지는지부터 짚고 가자.

1.1 기존 UI 패턴이 왜 망가지는가: “상태 지옥”

전통적인 웹 UI는 대부분 이렇게 동작했었다.

• DOM에서 요소를 찾고
• 이벤트가 발생할 때마다
• class를 붙였다 떼었다,
• 텍스트를 바꾸고,
• 여러 상태나 데이터를 “수동으로” 맞춘다.

문제는 상태가 한 군데에 모여 있지 않다는 점이다.

• 서버 응답 결과 일부는 전역 변수에,
• 일부는 DOM attribute에,
• 일부는 컴포넌트 인스턴스 필드에,
• 심지어 유저가 뭔가 조작하면 또 다른 곳에 복사본이 생긴다.

이렇게 되면 필연적으로 이런 상황이 온다.

• 어떤 버튼은 활성화인데, 다른 영역은 여전히 비활성화로 보인다.
• 모달은 닫혔는데, 오버레이는 남아 있다.
• 토글 버튼 텍스트는 ON인데 실제 로직 값은 false다.

즉, “앱의 진짜 상태”와 “눈에 보이는 UI”가 서로 어긋나는 순간부터 디버깅은 감과 운에 의존하는 게임이 된다.

이게 React가 해결하려는 문제의 본질이다.

1.2 React의 관점: “UI를 단순 화면이 아니라 함수로 취급하자”

React는 여기서 접근을 통째로 바꾼다.

• 더 이상 “UI를 어떻게 바꿀지(how)”를 작성하지 말고,
• “지금 상태라면 UI가 어떻게 생겨야 하는지(what)”를 정의하라고 한다.

즉,

UI = f(state)

• 입력: 현재 앱 상태(state)
• 출력: 그 상태에서의 UI 트리(React element tree)

우리는 더 이상 DOM 조작 절차를 나열하지 않는다. 대신 state를 인자로 받아 UI를 반환하는 함수를 설계한다.

이게 “선언형 UI(Declarative UI)”.

“상태가 이렇게 생겼으면, 화면은 이렇게 보여야 한다”를 함수 정의로 고정해 두는 것.

1.3 순수 함수 UI의 세 가지 조건

React가 진짜로 원하는 건 “순수 함수처럼 보이는 UI”다. 순수 함수 UI는 최소한 아래 세 가지를 만족해야 한다.

1. 같은 state == 항상 같은 UI

   • 랜덤, 시간, 전역 mutable 변수 등에 의해 결과가 바뀌지 않는다.

2. UI는 오직 props와 state로만 결정된다

   • 컴포넌트 내부에서 몰래 전역 싱글톤을 직접 바꾸고 참조하는 패턴은 독이다.

3. 렌더링 과정에는 side effect가 없다

   • DOM 직접 조작, 네트워크 요청, 로깅 등은 useEffect 같은 별도 단계에서 처리해야 한다.

이게 지켜져야 다음이 가능해진다.

• 상태만 보면 UI가 어떻게 생겼는지 예측 가능
• 특정 state를 주입해서 화면을 테스트 가능 (그래서 TDD를?)
• UI 변경 이력을 추론 가능(“왜 이렇게 보이는지” 설명 가능)

즉, 테스트 가능하고, 예측 가능하고, 리팩터링 가능한 UI의 최소 조건이 바로 이거다.

1.4 이 식이 설계에 강제하는 구조적 결과

UI = f(state)를 진지하게 받아들이면, 설계는 어쩔 수 없이 다음과 같이 바뀐다.

1. 상태는 함수 밖에서 관리하고, arg로 주입한다.

   • 컴포넌트는 “현재 상태를 기반으로 UI를 그리는 기계”가 된다.

2. 렌더링 로직은 side effect에서 분리된다.

   • 그리는 것(render)과 “반응하는 것(effect)”을 분리해야 순수성이 유지된다.

3. 자식 컴포넌트는 함수 합성처럼 다뤄진다.

   • 부모가 state → UI로 계산한 결과 일부를 props로 넘긴다.
   • 자식은 받은 props를 다시 UI로 매핑하는 작은 함수다.

즉, 전체 React 앱은 거대한:

AppUI = f(globalState)

를 작은 함수 여러 개의 합성으로 분해한 것에 불과하다.

이 관점이 잡히면, 컴포넌트 나누기, props 구조, state 위치 선정은 전부 이 식을 깨지 않기 위한 아키텍처 작업으로 이해할 수 있다.

1.5 UI = f(state)가 깨질 때 벌어지는 사고들

반대로, 이 원칙을 무시하면 어떤 일이 생길까? 대표적인 실패 패턴 몇 가지를 보자.

1. 렌더링 중 전역으로 읽고/수정하는 컴포넌트

   • 테스트 환경에서 상태 주입이 안 된다.
   • 어디서 값이 바뀌는지 추적이 불가능해진다.

2. derived state를 또 다른 state로 중복 저장하는 패턴

   • 예: items와 filteredItems를 둘 다 state로 들고 있기
   • 둘의 동기화를 계속 맞춰야 한다는 건, 결국 언젠가 틀어진다.(디버깅시 매우 까다로워진다.)
   • 사실 filteredItems = f(items, filter)로 매번 계산하는 게 맞다.

3. 렌더링 안에서 DOM을 직접 건드리는 코드

   • React의 렌더링 사이클과 충돌한다.
   • “분명히 상태는 false인데, DOM은 여전히 열려 있음” 같은 모순 발생.

이 모든 문제는 한 줄로 정리된다.

“UI가 state의 함수가 아닐 때, UI와 state는 언젠가 반드시 어긋난다.”

1.6 Thinking in React

이제 “왜 UI = f(state)가 필요한가”는 어느 정도 명확해졌다. 그럼 공식 문서의 5단계는 어디에 위치할까?

• UI를 컴포넌트로 나누기
• 정적 버전 만들기
• 최소한의 상태 찾기
• 상태를 어디 둘지 정하기
• 단방향 데이터 흐름 구성하기

이건 전부 메타 수준에서 보면 한 가지 목적.

“앱 전체를 UI = f(state) 구조에 맞게 재조직하는 절차”

• 정적 버전 만들기는, 순수 함수 UI 먼저 확보
• 최소 상태 찾기는, f의 입력을 필요 최소한으로 압축
• 상태 위치 정하기는, f가 어디서 정의되는지, 책임 단위로 배치
• 단방향 데이터 흐름는, 입력이 어디서 왔는지 추적가능하게 만들기

그래서 이 글 전체의 구조도 이렇게 잡아보자.

1. 1장: UI = f(state) — 왜 이 식이 필요한가 (지금 읽고 있는 부분)
2. 2장: 상태관리와 책임 단위 — f(state)에서 state를 어디서 관리할 것인가
3. 3장: 단방향 데이터 흐름 — state -> UI -> 이벤트 -> state로 이어지는 루프를 어떻게 닫을 것인가

이제 다음 장에서 다룰 질문은 명확하다.

“좋다, UI = f(state)인 건 알겠다. 그럼 그 state는 어디에 둬야 예측 가능한 시스템이 되나?”

그게 바로 2장의 주제, “상태관리 및 책임 단위(State Architecture)”이다.

출처 : https://overreacted.io/the-two-reacts/ https://www.youtube.com/watch?v=x7cQ3mrcKaY https://overreacted.io/a-complete-guide-to-useeffect/ https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

문제

이번 주엔 1. TDD를 활용 하기 (RED-GREEN-REFATOR) 2. 포인트에서의 동시성 락을 어떻게 해결할까? (non-blocking, single-thread 기반의 nest.js)

TDD와의 첫 만남... (시험 2일 전)

사실 첫만남은 매우 비호감입니다; 중간고사와 겹치는 불상사!어쩔 수 없습니다. 해내는게 저이고 말고요.

일단 TDD의 기본 베이스는 이렇습니다.

Red : 실패하는 테스트 코드를 먼저 작성 Green : 테스트 코드를 성공시키기 위한 실제 코드를 작성 Refactor : 테스트 결과에 맞추어 (커버리지나 중복 코드 및 읽기 쉬운 코드 등) 리팩토링을 수행하는 것

개인적으로 느낀 장점은 이렇습니다.

한 번에 조금씩 커밋하고, 메시지는 Claude로 자동화

이렇게 개발하는 방법은 처음 겪어 봤기에 테스트 코드를 작성을 먼저 해봤습니다.

// 동시에 충전과 사용 요청
            const promises = [
                service.chargePoint(userId, chargeAmount), // +3000
                service.usePoint(userId, useAmount),       // -2000  
                service.chargePoint(userId, chargeAmount)  // +3000
            ];

            const results = await Promise.all(promises);

            // 최종 잔고는 15000 + 3000 - 2000 + 3000 = 19000이어야 함
            const expectedFinalBalance = 
                initialBalance + chargeAmount - useAmount + chargeAmount;

            // 모든 연산이 순차적으로 적용되었는지 확인
            // 현재는 동시성 제어가 없어서 예상과 다를 것
            const balances = results.map(result => result.point);
            const maxBalance = Math.max(...balances);

            expect(maxBalance).toBe(expectedFinalBalance);
        }, 10000);

이렇게 spec.ts를 기준으로 가설을 세우고, 동시에 충전과 사용 요청을 만들어 봤습니다.

초기값과 최종값에만 의존하는 상태함수 개념 (간단한 아이디어)

그래도 아직 테스트 코드 자체의 문법이 익숙하지 않아 학습할 필요가 있어 숙달해야할 듯 합니다.

사실 제대로 했을까?

현재 테스트는 최종 상태를 보지 않고 중간 응답의 최댓값으로 판정하므로 신뢰할 수 없움

nest.js의 튜토리얼을 참고해보기!

그렇게 커버리지 100퍼 달성은 refactoring 과정에서 달성을 할 수 있었다? 좋은거 맞아?

마치 문제를 정의하고 틀리게 해결하면 무슨 소용일까요.

가치있는 테스트를 위한 전략과 구현

위의 테스트 코드의 전략과 구현의 글을 보고 좋은 테스트 코드는 무엇인지 잘 숙지를 해야한다는 점입니다.

Fast: 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 함 Independent: 각각의 테스트는 독립적이며 서로 의존해서는 안 됨 Repeatable: 어느 환경에서도 반복 가능해야 함 Self-Validating: 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 함 Timely: 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 함

✨ 핵심 테스트 코드를 목적에 맞게 적절히 구현하는 것이 중요

동시성 락, 싸우지마 애들아!

위 그림을 본다면 덮어쓰기가 2번 동작하네??? 어라,,, 그러면 115달러가 아니고 105달러가 최종 답이네...? John과 Alice는 계좌 금액에 대해 동시 접근을 해...

경쟁 상태(race condition)란?

여러 개의 프로세스가 공유 자원에 동시 접근할 때 실행 순서에 따라 결과값이 달라질 수 있는 현상

그렇다면 어떻게 해결하는 것이 좋을까?

누가 먼저 할래? 그럼 줄 서

• 선택한 접근 방식: Promise 기반 Lock 시스템

왜 이 방식을 선택했는가?

• 1. Node.js 싱글 스레드 특성 활용하기

// 전통적인 Mutex 대신 Promise 기반 접근
private readonly locks = new Map<number, Promise<any>>();

Node.js는 싱글 스레드 이벤트 루프 기반
메모리 내 Map을 통한 간단하고 효율적인 구현
별도 라이브러리 의존성 없음

• 2. 사용자별 독립적 Lock 관리

async withLock<T>(userId: number, operation: () => Promise<T>): Promise<T> {
    const existingLock = this.locks.get(userId);
    // 사용자별 개별 Lock 처리
}

다음과 같은 플로우 차트를 기반으로 기획을 했었다.

사실 이건 거짓 락에 불과한 건데, 제출하고 나서 스스로 분석도 하고 피드백을 참고해보니까...

• 1. 허들(Thundering herd)문제 : 이벤트가 발생하면 모두 동시에 깨어나 하나의 자원을 차지하려고 경쟁하는 현상

if (existingLock) await Promise.race([existingLock, timeout]);
const newLock = operation();
this.locks.set(userId, newLock);

여러 호출이 같은 기존 락이 끝나길 기다린 뒤, 동시에 operation()을 시작할 수 있습니다. 마치 오픈런...

• 2. 해제 제대로 안된다...

    operation().finally(() => this.locks.delete(userId));

나보다 나중에 들어온 작업이 this.locks.set(userId, next)로 새 작업(tail)을 세팅해도, 먼저 끝난 작업의 finally가 무조건 delete를 호출하면 현재 진행 중인 끝 부분도 같이 지워진다.

• 3. 이전 작업 실패 전파

existingLock이 reject 되면 다음 호출도 await에서 같이 터짐 -> 연쇄 실패. (보통 직렬화 큐는 “이전 실패와 무관하게 다음 작업은 진행”이 자연스러움)

• 4. 공정성/대기열 없음

FIFO 보장 없음. “먼저 도착한 요청이 먼저 실행”이 깨지기 쉽습니다.

가차없는 피드백을 받았습니다,,, 사실 map말고 queue를 썼다면 좋을텐데~

다음 목표

시간에 쫓기지 않고 좀 더 CS기반으로 판단해서 구현을 하는 것을 목적으로!

플로우 차트를 그리면서 고민 또 고민을 했어야했고, 왜 맵을 썼는지 이유를 근거해서 구현을 하면 좋을 것 같아.

내가 맞게 했는지 의심하고 또 의심해라

구현을 하면서 테스트코드 자체가 맞다고 생각하면서 구현을 하니 아무것도 성공할 수 없었습니다. 잘못된 테스트는 잘못된 리팩토링을 불러옵니다

사실 프론트엔드 개발만 진행하다 보고, 어쩌다 내일 일경험에서 백엔드도 다뤄야 했어서 조금씩 경험했던 게, 계기가 되었다. 좋은 사람들과 함께 성장할 수 있다는 점도 매우 크게 작용했다. 학교 밖에서의 사람들과 협업할 수 있다니 너무 기쁘다.

10주간의 목표

1. TDD를 앞으로의 프로젝트에서 다룰 수 있을 정도

2. 대용량 트래픽을 활용한 나만의 프로젝트 개발

3. 여러 선배 개발자들의 지식 및 철학 흡수하기

프로그래머스 뉴스 클러스터링

문제 정의

두 문자열에서 연속된 2글자씩 끊어 만든 다중집합을 구성하고, 두 다중집합의 자카드 유사도 J(A, B) = 교집합(A,B) / 합집합(A,B) 를 계산해 65536을 곱해 소수점 아래를 버린 값을 구해야 한다.

• 알파벳만 유효(숫자/특수문자 포함 쌍은 제외)
• 대소문자 구분 없음(모두 소문자로 처리)
• 다중집합(원소 중복 허용) 기준의 교집합/합집합 계산
• 두 집합 모두 공집합이면 유사도 1로 간주, 65536 반환

접근 방법

• 문자열을 순회하며 2글자 쌍을 만들고, 둘 다 알파벳인 경우만 선택

• 소문자로 변환하여 정규화 : tolower() 사용

• 다중집합 구현은 2차원 카운팅 배열 사용: 알파벳 26×26 (a~z)

  • count1[a][b], count2[a][b]

• 교집합 크기: 각 키에 대해 min(count1, count2)의 합

• 합집합 크기: 각 키에 대해 max(count1, count2)의 합

  • 예시의 힌트를 활용했다!

• 개꿀*

• 합집합이 0이면 65536, 아니면 floor((inter/union) * 65536) 반환

구현 코드 (C++)

#include <bits/stdc++.h>

// 어 문자열 문제? 
// 유사도를 구하는데 2개씩 비교 (교집합) / (합집합)
// 집합 A와 집합 B가 모두 공집합일 경우 -> 1

// 확장하니 원소의 중복을 허용하는 다중집합
// (교집합-중복x) / (합집합-중복o)
// 알파벳 + 빈도 수 -> 2차원 <키(a,b), 나오는 빈도> 배열 활용
using namespace std;


int solution(string str1, string str2) {
    int answer = 0;

    int ch_map1[26][26];
    int ch_map2[26][26];

    fill(&ch_map1[0][0], &ch_map1[0][0]+26 * 26, 0);
    fill(&ch_map2[0][0], &ch_map2[0][0]+26 * 26, 0);
    //알바벳 first, second 에 저장되는 cnt -> 0으로 초기화

    for(int i = 0; i < str1.size()-1; i++){
        char a = tolower(str1[i]);
        char b = tolower(str1[i+1]);
        if (isalpha(a) && isalpha(b)) {
            ch_map1[a - 'a'][b - 'a']++;
        }
    }
    for(int i = 0; i < str2.size()-1; i++){
        char a = tolower(str2[i]);
        char b = tolower(str2[i+1]);
        if (isalpha(a) && isalpha(b)) {
            ch_map2[a - 'a'][b - 'a']++;
        }
    }



    int interCnt = 0; //교집합
    int unionCnt = 0; //합집합
    for (int i = 0; i < 26; i++) {
        for (int j = 0; j < 26; j++) {
            interCnt += min(ch_map1[i][j], ch_map2[i][j]); 
            //설명에서 다중집합 확장한 방법
            unionCnt += max(ch_map1[i][j], ch_map2[i][j]);
        }
    }

    if (unionCnt == 0) return 65536; //공집합이면 유사도 1

    //자카드 유사도 계산
    answer = floor( (interCnt*1.0 / unionCnt) * 65536);//소수점 버림

    return answer;
}

핵심 포인트

1. 정규화: 대소문자 무시 -> 모두 소문자 변환
2. 유효 문자 필터링: 2글자 모두 알파벳일 때만 선택하기
3. 다중집합 계산: 교집합은 min, 합집합은 max의 합으로 구현 : 설명 내에 답이 있었다.
4. 엣지 케이스: 합집합이 0이면 65536 반환
5. 상수 크기 맵: 26×26 카운팅 배열로 빠르게 처리 (메모리/속도 유리)

시간 복잡도

• 문자열 전처리: O(|str1| + |str2|)
• 교집합/합집합 계산: O(26×26) = O(1)
• 전체: O(N)

학습 포인트

• 다중집합 교집합/합집합을 빈도 맵으로 구현하는 패턴 이해
• 문자열 전처리와 유효성 검사(isalpha, tolower) 순서 중요
• 자카드 유사도 정의 및 엣지 케이스 처리(공집합)

문제 정의

• 입력: N×N 보드 (0=빈칸, 1=벽)

• 시작점: (0,0)

• 목표점: (N-1, N-1)

• 이동: 상하좌우 한 칸씩 이동

• 비용:

  • 직선 이동: 100원
  • 코너 발생 시: 100 + 500 = 600원

• 목표: 목표칸까지 누적 비용의 최솟값

핵심 인사이트

문제의 핵심

같은 좌표라도 "들어온 방향"에 따라 이후 코너 비용이 달라지므로, dist[x][y]만으로는 최적성 보장이 불가능.

해결 방안

좌표 상황을 (x, y, dir)로 확장하여 dist[x][y][dir]에 "dir로 진입했을 때의 최소비용"을 저장.

알고리즘 선택

비용이 균일하지 않으므로 BFS는 부적합, 다익스트라 알고리즘을 사용해야 한다.

알고리즘 개요

자료구조

// 3차원 거리 배열: dist[x][y][dir]
vector<vector<vector<int>>> dist(
    size, vector<vector<int>>(size, vector<int>(4, INF))
);

// 우선순위 큐 (최소 힙)
priority_queue<block, vector<block>, Cmp> pq;

초기화

• 시작점 (0,0)은 방향이 없음
• (0,0) 인접 유효 칸으로 첫 이동을 직선 비용(100) push

전개 과정

1. pq에서 최소 cost를 꺼냄 (꺼낸 cost != dist이면 스킵)
2. 4방향으로 확장
   • 다음 방향이 현재 dir과 같으면 +100 (직선)
   • 다르면 +600 (코너)
3. 더 작게 갱신되면 dist 갱신 후 pq에 푸시

종료 조건

정답 = min(dist[N-1][N-1][0..3])

구현 포인트

방향 벡터 설정

int dir[4][2] = {{0,-1}, {-1,0}, {0,1}, {1,0}}; 
// 상좌하우 방향, 세로 이동 0,2 / 가로이동 1,3

우선순위 큐 설정

struct Cmp {
    bool operator()(const block& a, const block& b) const {
        return a.cost > b.cost; // 비용 작은 게 top
    }
};

중요한 구현 세부사항

• 첫 이동만 직선 비용 처리 (시작에 방향 X)

자주 나오는 버그와 수정

복잡도 분석

• 블럭 상태의 수: O(4N^2) = O(N^2)
• 시간복잡도: O(N^2 log N) (각 상태에서 최대 4개의 간선, 힙 시간복잡도 포함)
• 공간복잡도: O(N^2)

코드 구조

typedef struct Block {
    int cost; // 지금까지 누적 cost
    int x;    // 현재 x(행)
    int y;    // 현재 y(열)
    int dir;  // 이 칸으로 들어온 방향(0~3)
} block;

#define L_COST 100  // 직선 비용
#define C_COST 600  // 코너 비용 (100 + 500)
#define INF 999999  // 무한대

핵심 로직

// 코너 판별 및 비용 계산
int add = (i == cur.dir) ? L_COST : C_COST;
int nc = cur.cost + add;

// 최적화: 이미 더 좋은 비용으로 갱신되었다면 스킵
if (cur.cost != dist[cur.x][cur.y][cur.dir]) continue;

이 알고리즘은 블럭 상태의 추가와 다익스트라를 결합하여 경로의 방향성을 고려한 최적 경로를 찾는 문제.

이번 기회에 백준 문제풀었던 걸 복기하기 위해 작성을 시작했습니다!! 같이 열심히 백준 풀어봅시다!

이 문제에 대해 간단히 알아봅시다:)

다음과 같은 기능을 구현하는 스택입니다.

push X: 정수 X를 스택에 넣는 연산 pop: 스택에서 가장 위에 있는 정수를 빼고, 그 수를 출력한다. 만약 스택에 들어있는 정수가 없는 경우에는 -1을 출력 size: 스택에 들어있는 정수의 개수를 출력 empty: 스택이 비어있으면 1, 아니면 0을 출력한다. top: 스택의 가장 위에 있는 정수를 출력한다. 만약 스택에 들어있는 정수가 없는 경우에는 -1을 출력한다.

1. 스택 구조란?

스택 구조는 흔히 말하는 FILO(First In, Last Out), 즉 선입후출 구조입니다.

위와 같은 스택 구조는 기본적으로 일직선 적인 구조라 선형구조입니다. 그래서 스택을 배열과 연결 리스트 두 가지 방식으로 짤 수 있습니다.

typedef struct StackNode {
    element data;
    struct StackNode* link;
}stack;

위의 코드는 간단한 스택의 리스트형 구조입니다. 노드끼리 연결해주는 포인터와 데이터입니다. 연결리스트의 기본 요소니 기억해주세요

마지막 부분은 TOP으로 잡겠습니다. 나가는 출구 및 입구!

2. 스택 각 기능 구현

스택에서 필요한 것은 딱 두가지 선형 구조와 어디가 마지막인지 알려주는 탑 입니다.

push : 새로운 노드를 생성하고 데이터를 저장합니다. 새 노드의 link를 현재 TOP으로 설정! pop: 1. 스택이 비어있는 경우 -1을 반환합니다. 2. 스택의 모든 노드를 순회. size: 스택에 들어있는 정수의 개수를 출력 empty: 스택이 비어있으면 1, 아니면 0을 출력 top: 스택이 비어있으면 -1을, top인덱스가 가르키는 노드의 데이터를 반환

3. 답안 코드

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>

typedef int element;

typedef struct StackNode {
    element data;
    struct StackNode* link;
}stack;

void push(element x);
element pop(void); // no top = -1
int size(void);
int empty(void); //empty == 1, not empty == 0
element top(void); // no top = -1

stack* TOP;

int main()
{
    int n;
    char cmd[6];
    int cnt = 0;

    TOP = NULL;

    scanf("%d", &n);

    for (int i = 0; i < n; i++) {
        scanf("%s", cmd);
        getchar();

        if (!strcmp(cmd, "push")) {

            element input;
            scanf("%d", &input);

            push(input);
            continue;
        }

        else if (!strcmp(cmd, "pop")) {
            printf("%d\n", pop());
            continue;
        }

        else if (!strcmp(cmd, "size")) {
            printf("%d\n", size());
            continue;
        }

        else if (!strcmp(cmd, "empty")) {
            printf("%d\n", empty());
            continue;
        }

        else if (!strcmp(cmd, "top")) {
            printf("%d\n", top());
            continue;
        }
    }

    return 0;
}

void push(element x) {
    stack* tmp = (stack*)malloc(sizeof(stack));

    tmp->link = TOP;
    tmp->data = x;
    TOP = tmp;

    return;
}
element pop(void) {
    if (empty()) return -1;
    else {
        stack* old = TOP;

        TOP = old->link;
        element tmp = old->data;
        free(old);
        return tmp;
    }
}
int size(void) {
    stack* tmp = TOP;
    int cnt = 0;

    while (tmp) {
        cnt++;
        tmp = tmp->link;
    }
    return cnt;
}
int empty(void) {
    if (TOP == NULL) {
        return 1;
    }
    else {
        return  0;
    }
}
element top(void) {
    if(empty()) return -1;
    else {
        return (TOP->data);
    }
}