이 글의 목표 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);
    }
}