[Kt 에이블스쿨 9기 기자단] DX컨설턴트 8주차 후기

안녕하세요 kt에이블스쿨 9기 기자단입니다.
오늘은 dx컨설턴트 트랙 8주차 후기를 작성하겠습니다.

 

8주차 일정을 간단히 브리핑 하겠습니다.

월요일엔 4차 미프 2일차를 진행했습니다.

이거에 관한 내용은 7주차 후기에 적었으니 궁금하신분들은 이전 게시글 확인해주세요.

화요일엔 아이데이션, 수~금엔 클라우드에 대해 배웠습니다

 

 

화요일에2번째 아이데이션을 진행하였는데요.
여전히 아이디어를 도출하는게 힘들었습니다.
개인적으로 B2B보다는 B2G 위주로 하고싶은 생각이 들었습니다.
왜냐하면 사기업에 비해 상대적으로 많은 정보들이 공개되어있고,

담당자 인터뷰 등 직접적인 조언을 받기에도 공공기관이 수월하다고 생각했습니다.

그렇기에 1차 아이데이션과 마찬가지로 공공기관 중 하나인

농촌진흥청을 대상으로 B2G 아이디어를 도출했습니다.

퍼플렉시티와 함께 자료수집하는데 시간을 많이 할애했습니다.
아예 새로운 아이디어를 내기보다 이미 나와있는 정보를 수집해

현재 진행되고 있는 일에 AI 기술을 합칠 수 있는게 뭐가 있는지

여러 뉴스보도들과 농촌진흥청 문서를 보고 고려해보았습니다.

혼자 준비하며 가장 어렵다고 느껴졌던건 기대효과입니다.
1차 아이데이션 피드백때도 기대효과를 구체적으로 수치로 작성하면 좋다고 하셨지만,

아이디어를 정한 후 어떤 방식으로 수익을 수치로 산출할지 감이 잘 오지 않아 어려웠습니다.
빅프로젝트때 이 부분에 시간을 많이 써야할 것 같다고 생각했습니다.

 

개별과제를 마치고 조별미팅 시간에 제 아이디어를 코치님께 피드백 받았습니다.
이 시간이 정말 유익했습니다.
제가 1차적으로 조사한 부분에서 논리적으로 비어있는 부분을

정확하게 지적해주셔서 놀랐고, 많은 도움이 된 것 같습니다.
또한 B2G로 진행할 시 인건비 관련해서 기대효과로 적으면 안된다고 해주신 것도

빅프로젝트때 도움이 될 것 같습니다.
제 아이디어가 B2G 관점에 잘 맞는다고 해주셔서

B2G로 아이디어를 제안할 때 어떤식으로 하면 될지 감을 잡은 것 같습니다.

 

 

 

수요일엔 본격적인 클라우드 수업을 진행하기 전 기초 느낌으로

DX 컨설턴트라는 직무에 대해 전체적으로 배웠습니다.
강사님이 말씀을 굉장히 잘하신다고 느꼈고,

하루종일 이론 수업이었는데 지루하지 않았습니다.
아래는 교안 기반으로 제가 중요하다고 생각되는 내용을 정리한 내용입니다.

DX 컨설팅 & AWS 핵심 개념 정리

컨설팅 영역 핵심 개념 8가지

역할

DX 컨설턴트

비즈니스 문제를 기술 아키텍처로 해결하는 전략적 파트너 역할을 합니다. 단순히 기술을 구현하는 것이 아니라, 고객의 비즈니스 목표를 먼저 이해하고 그에 맞는 솔루션을 설계하는 것이 핵심입니다.

프레임워크

As-Is / To-Be

현재 상태(As-Is)와 목표하는 미래 상태(To-Be)를 객관적으로 비교하여 GAP(차이)을 분석하는 방법론입니다. 이 차이를 메우는 것이 곧 프로젝트의 과제가 됩니다.

측정

KPI (Key Performance Indicator)

프로젝트의 성공 여부를 정량적으로 판단할 수 있는 핵심 성과 지표입니다. "시스템 응답 속도 30% 개선"처럼 숫자로 표현되어야 의미 있는 기준이 됩니다.

측정

ROI (Return on Investment)

투자 대비 효과를 수치로 나타낸 지표입니다. 경영진 설득과 프로젝트 정당성 확보의 핵심 근거로 사용됩니다. (효과 - 투자비용) / 투자비용 × 100으로 계산합니다.

요구사항

FR / NFR

FR(기능 요구사항)은 시스템이 '무엇을 해야 하는가'를 정의합니다. NFR(비기능 요구사항)은 성능, 보안, 가용성, 확장성 등 시스템의 '품질 수준'을 정의합니다. NFR을 놓치면 기능은 동작하지만 쓸 수 없는 시스템이 됩니다.

관계 관리

이해관계자 (Stakeholder)

프로젝트에 영향을 주거나 받는 모든 사람들입니다. 영향력(Power)과 관심도(Interest)를 기준으로 4개 그룹으로 분류하여 소통 전략을 다르게 가져갑니다.

5W1H — 문제 구조화 프레임워크

What

무엇을

문제/과제가 무엇인가

Who

누가

이해관계자는 누구인가

When

언제

기한과 일정은 언제인가

Where

어디서

어떤 환경/범위에서

Why

왜

근본 원인과 목적은

How

어떻게

해결 방법과 수단은

고객이 요구사항을 말할 때 Why(왜)를 반드시 물어보세요. 고객이 "서버를 늘려달라"고 하더라도, 실제 원인이 트래픽 급증인지 코드 비효율인지에 따라 해결 방법이 완전히 달라집니다.

SMART — 목표 설정 프레임워크

S

Specific

구체적

M

Measurable

측정 가능

A

Achievable

달성 가능

R

Relevant

현실적

T

Time-bound

기한 명시

나쁜 목표: "시스템 성능을 개선한다"
좋은 목표: "3개월 내에 API 평균 응답 속도를 현재 1,200ms에서 400ms 이하로 단축한다"

이해관계자 관리 매트릭스

영향력 (Power) ↑

긴밀하게 관리

영향력 높음 + 관심도 낮음
주요 의사결정자. 핵심 보고 대상이지만 세부사항보다 요약 보고를 선호합니다.

중점 관리

영향력 높음 + 관심도 높음
프로젝트의 핵심 파트너. 가장 적극적으로 소통하고 의견을 반영해야 합니다.

모니터링

영향력 낮음 + 관심도 낮음
정기적인 최소한의 업데이트만 제공합니다.

정보 제공

영향력 낮음 + 관심도 높음
충분한 정보를 제공하여 만족시켜야 합니다.

낮음관심도 (Interest) →높음

기술 영역 핵심 개념

클라우드

AWS (Amazon Web Services)

전 세계에서 가장 널리 사용되는 1위 클라우드 플랫폼입니다. 컴퓨팅, 스토리지, 네트워크, 데이터베이스 등 200개 이상의 서비스를 제공합니다.

보안

IAM (Identity & Access Management)

AWS 리소스에 대한 사용자 인증 및 접근 권한을 안전하게 제어하는 서비스입니다. 최소 권한 원칙(Least Privilege)에 따라 필요한 권한만 부여하는 것이 기본 원칙입니다.

인프라

리전 / AZ (Region / Availability Zone)

리전은 지리적으로 분리된 독립 영역(예: ap-northeast-2 = 서울)이며, AZ는 하나의 리전 안에 존재하는 하나 이상의 물리적 데이터센터 그룹입니다. 서울 리전에는 현재 4개의 AZ가 있습니다.

보안

MFA (Multi-Factor Authentication)

아이디·비밀번호 외에 추가 인증 단계를 거치게 하는 다중 인증 방식입니다. 루트 계정과 관리자 계정에는 MFA를 반드시 설정해야 합니다.

설계

Well-Architected Framework

AWS에서 제안하는 클라우드 설계 프레임워크로, 인프라를 올바르게 설계했는지 평가하는 기준이 됩니다. 6개 기둥(Pillar)을 기반으로 아키텍처를 점검합니다.

고가용성

Multi-AZ

인프라를 여러 AZ에 분산 배포하여 물리적 장애 시에도 서비스가 유지되도록 고가용성을 확보하는 방식입니다. RDS, ELB 등 주요 서비스에서 기본 옵션으로 제공됩니다.

보안

계층 방어 (Defense in Depth)

단일 보안에 의존하지 않고, 네트워크·호스트·애플리케이션·데이터 등 여러 레이어에 보안을 중첩 적용하는 전략입니다. 하나의 레이어가 뚫려도 다음 레이어가 방어합니다.

비용

Right Sizing

워크로드와 실제 사용량에 맞는 적정 사양의 리소스를 선택하여 불필요한 비용을 최소화하는 최적화 작업입니다. 과잉 프로비저닝과 과소 프로비저닝 둘 다 피해야 합니다.

Well-Architected 6기둥 (6 Pillars)

운영 우수성

운영 자동화, 모니터링, 지속적 개선

보안

데이터 보호, 접근 제어, 감사 추적

안정성

장애 복구, 고가용성, 탄력적 설계

성능 효율성

적정 리소스 선택, 수요에 따른 확장

비용 최적화

불필요한 지출 제거, Right Sizing

지속 가능성

에너지 효율, 탄소 발자국 최소화

6기둥은 서로 트레이드오프가 있습니다. 예를 들어 안정성을 높이기 위해 Multi-AZ를 구성하면 비용이 올라갑니다. 비즈니스 상황에 맞는 균형점을 찾는 것이 Well-Architected의 핵심입니다.

DR (Disaster Recovery) — RTO & RPO

복구 시간 목표

RTO (Recovery Time Objective)

장애 발생 후 서비스가 정상적으로 복구되기까지 허용 가능한 최대 시간입니다.
"몇 시간 안에 복구되어야 하는가?"

복구 시점 목표

RPO (Recovery Point Objective)

장애 발생 시 허용 가능한 최대 데이터 손실 범위(시간 기준)입니다.
"최대 몇 시간 전 데이터까지 잃어도 되는가?"

RTO와 RPO 값이 낮을수록(= 더 빠른 복구, 더 적은 데이터 손실) 비용이 기하급수적으로 증가합니다. 비즈니스 영향도에 따라 적정 수준을 정의하는 것이 중요합니다.

FR vs NFR 비교

구분	FR (기능 요구사항)	NFR (비기능 요구사항)
정의	시스템이 무엇을 해야 하는가	시스템이 얼마나 잘 해야 하는가
예시	로그인 기능, 결제 처리, 파일 업로드	응답 시간 200ms 이하, 99.9% 가용성, 암호화 필수
간과 시 결과	기능이 없어 서비스 불가	기능은 있지만 느리거나 불안전해 사용 불가

1일차 핵심 인사이트

솔루션보다 문제 정의가 먼저입니다. 고객이 원하는 솔루션을 바로 구현하면 정작 진짜 문제를 해결하지 못할 수 있습니다.

Why를 3번 물어보세요. 고객의 요구사항 뒤에 숨어있는 본질적인 비즈니스 목적을 파악하기 위해 '왜?'를 반복적으로 질문하는 습관이 중요합니다.

숫자 없는 문제 정의는 의미가 없습니다. "느리다"는 주관적입니다. "응답 시간이 1,200ms다"는 측정 가능한 문제 정의입니다.

모든 요소를 100점으로 만들 필요는 없습니다. 비즈니스 상황에 따라 안정성 99.9%와 99.999%의 비용 차이는 엄청납니다. 적정 수준을 찾는 것이 진짜 실력입니다.

클라우드 기술은 수단이지 목적이 아닙니다. 궁극적인 목표는 비즈니스 문제를 해결하는 것이며, AWS는 그 도구 중 하나입니다.

오늘의 학습 흐름 회고

• 1DX 컨설턴트의 역할 이해 — 기술 구현자가 아닌 비즈니스 파트너로서의 관점 잡기
• 25W1H 프레임워크 기반의 고객 요구사항 해석 — 표면적 요구사항과 본질적 의도 분리하기
• 3SMART 목표 설계를 통한 As-Is / To-Be 구조화 — 측정 가능한 목표로 방향 설정하기
• 4요구사항 정의서 작성을 위한 KPI 수립 및 성과 지표 관리 — FR/NFR 구분하여 빠짐없이 정의하기
• 5IAM, 리전, 비용 등 AWS 학습 환경 이해 — 클라우드 기초 개념과 보안 설정 익히기
• 66기둥 설계 원칙을 바탕으로 한 AWS Well-Architected 구조 파악 — 좋은 아키텍처의 기준 이해하기
• 73개 실제 사례와 산출물 리뷰를 통한 아키텍처 사례 분석 — 개념을 실무에 연결하기

---

 

 

 

목요일엔 VPC 네트워킹과 클라우드 인프라에 대해 배웠습니다.
다양한 내용을 배웠기에 꼼꼼히 복습하려고 합니다.
아래는 교안 기반으로 제가 중요하다고 생각되는 내용을 정리한 내용입니다.

AWS VPC 네트워킹 핵심 개념 정리

핵심 개념 8가지

기반

VPC (Virtual Private Cloud)

AWS 클라우드 내에 격리된 가상 네트워크입니다. 모든 인프라 구축의 기반이 됩니다.

주소 체계

CIDR

IP 주소 범위를 유연하게 정의하기 위한 표기법입니다. 10.0.0.0/16처럼 IP와 서브넷 마스크 비트를 함께 표기합니다.

네트워크

서브넷 (Subnet)

VPC 내에서 IP 범위를 쪼개어 사용하는 논리적 구역입니다. 가용 영역(AZ)별로 생성하며, 용도에 따라 Public/Private으로 분리합니다.

네트워크

라우팅 (Routing)

네트워크 트래픽이 목적지를 찾아갈 수 있도록 경로를 결정하는 경로표입니다. 서브넷의 Public/Private 여부를 결정하는 기준이 됩니다.

게이트웨이

IGW (Internet Gateway)

VPC와 인터넷 간의 통신을 가능하게 해주는 관문입니다. VPC당 1개만 연결할 수 있습니다.

게이트웨이

NAT Gateway

Private 서브넷 인스턴스가 외부로 아웃바운드 인터넷 통신을 할 수 있도록 중계해 주는 서비스입니다. 고정 IP(EIP) 설정이 필수이며, 시간당 요금이 발생합니다.

보안

SG (Security Group)

인스턴스 레벨에서 동작하는 Stateful 방식의 방화벽입니다. 허용(Allow) 규칙만 설정할 수 있습니다.

보안

NACL (Network ACL)

서브넷 레벨에서 동작하는 Stateless 방식의 방화벽입니다. 허용(Allow)과 거부(Deny) 규칙을 모두 설정할 수 있습니다.

Security Group vs NACL 비교

항목	Security Group (SG)	Network ACL (NACL)
적용 수준	인스턴스 레벨 (ENI)	서브넷 레벨
상태 관리	Stateful 요청 응답 자동 허용	Stateless 나가는 규칙도 별도 필요
규칙 유형	허용(Allow)만 가능	허용 + 거부(Deny) 모두 가능
규칙 평가	모든 규칙을 종합 평가	번호 순서대로 첫 번째 매칭 규칙 적용
기본 상태	인바운드 차단 / 아웃바운드 허용	기본 VPC: 모두 허용 커스텀 생성 시: 모두 차단
참조 방식	다른 SG 참조 가능 (SG-to-SG)	IP 주소 범위(CIDR)만 지정 가능
주요 사용 시점	일반적인 접근 제어	긴급 IP 차단, 서브넷 단위 추가 보안

실무 비유: SG는 항상 근무하며 허가 목록을 확인하는 정문 경비원, NACL은 비상 시 한 번에 내려버리는 비상 차단봉입니다.

평상시 보안 관리는 SG를 중심으로 하고, 특정 IP를 급하게 차단해야 하는 비상 상황에는 NACL을 활용하는 것이 효율적입니다.

트래픽 흐름으로 보는 패킷의 이동

인바운드 흐름 — 외부에서 내부 DB로 들어올 때

Internet→ IGW→ NACL→ SG (web)→ Web EC2→ SG (app)→ App EC2→ SG (db)→ DB

아웃바운드 흐름 — Private EC2에서 외부 인터넷으로 나갈 때

Private EC2→ SG Out→ Private 라우팅→ NAT GW→ Public 라우팅→ IGW→ Internet

NAT Gateway 통과 시 프라이빗 IP가 고정 IP(EIP)로 변환되는 SNAT가 수행됩니다.

비용 최적화 및 리소스 정리 팁

NAT Gateway 비용 주의

시간당 비용 + 데이터 처리 비용이 모두 부과되어, VPC 내에서 비용 부담이 가장 큰 리소스입니다. S3나 DynamoDB와의 통신이 목적이라면, 무료로 사용할 수 있는 Gateway 방식의 VPC Endpoint를 먼저 검토하세요.

미사용 Elastic IP(EIP) 관리

인스턴스나 NAT GW에 연결되지 않은 채 방치된 EIP는 패널티 비용이 발생합니다. 사용하지 않는 즉시 해제해야 합니다.

실습 후 리소스 삭제 순서
의존성 문제로 삭제가 막히지 않도록, 아래 순서대로 역순 삭제를 진행합니다.

NAT GW→ EIP→ EC2→ 서브넷→ IGW→ 라우팅 테이블→ VPC

셀프 체크 Q&A

VPC가 무엇이고 왜 필요한가요?

AWS라는 공용 환경 내에서 나만의 독립적인 네트워크 공간을 만드는 것입니다. 보안 격리 없이는 내부 서버들이 외부에 그대로 노출되거나 침해 위험이 커지기 때문에, 인프라의 안전성을 확보하기 위해 반드시 필요합니다.

Public 서브넷과 Private 서브넷의 라우팅 차이는?

라우팅 테이블에서 외부 전체(0.0.0.0/0)로 향하는 경로의 목적지가 핵심입니다. 목적지가 IGW이면 Public 서브넷, NAT Gateway이면 Private 서브넷입니다.

Security Group과 NACL의 차이를 비유로 설명한다면?

SG는 인스턴스 바로 앞에서 허가된 리스트만 확인하고 통과시키는 Stateful 방식의 경비원입니다. 반면 NACL은 서브넷 입구에서 들어오고 나가는 트래픽을 독립적으로 검사하며, 블랙리스트(거부) 기능까지 갖춘 Stateless 방식의 비상 차단 시스템입니다.

NAT Gateway가 없어도 Private 서브넷이 외부 통신을 할 수 있나요?

기본적으로는 불가능합니다. Private 서브넷에는 IGW로 향하는 경로가 없기 때문에 외부 인터넷으로 직접 나갈 수 없습니다. NAT Gateway를 통해 아웃바운드 통신만 허용하는 것이 일반적인 구성이며, 이렇게 하면 외부에서 직접 접근하는 인바운드는 차단된 상태를 유지할 수 있습니다.

---

 

 

금요일엔 고가용 웹서비스 아키텍처에 대해 배웠습니다.
오늘까지 배운내용을 기반으로 다음주부터 일주일동안의 미니프로젝트가 이어지는데요.
팀원들에게 피해주지 않으면서 진도에 따라가려면 3일간 배운 내용들의 개념만큼은 숙지하는게 좋을 것 같습니다.
아래는 교안 기반으로 제가 중요하다고 생각한 내용을 정리해보았습니다.

ALB + Auto Scaling — 고가용성 아키텍처

단일 서버의 한계를 넘어, 트래픽을 분산하고 서버를 자동으로 늘리고 줄이는 고가용성 인프라 설계를 정리합니다.

핵심 키워드 12가지

로드밸런서

Load Balancer

들어오는 트래픽을 여러 서버에 분산시키는 장치입니다. 마트 계산대의 안내원처럼, 줄이 짧은 곳으로 손님을 보내 특정 서버에 부하가 몰리지 않도록 합니다.

로드밸런서

ALB (Application Load Balancer)

L7(애플리케이션) 계층에서 동작하는 로드 밸런서입니다. HTTP/HTTPS 트래픽을 URL 경로, 호스트명, 헤더 등 콘텐츠 내용을 보고 라우팅할 수 있습니다. 웹 서비스에 가장 많이 사용됩니다.

로드밸런서

NLB (Network Load Balancer)

L4(전송) 계층에서 동작하는 로드 밸런서입니다. TCP/UDP 트래픽을 처리하며 초저지연과 고정 IP가 특징입니다. 게임 서버나 금융 시스템처럼 TCP 고정 IP가 필요한 경우에 사용합니다.

로드밸런서

Target Group

ALB가 트래픽을 보낼 대상 EC2 인스턴스들의 묶음입니다. ALB의 Rules에 의해 어떤 Target Group으로 보낼지 결정되며, Health Check도 Target Group 단위로 수행됩니다.

모니터링

Health Check

ALB가 Target Group 내 각 인스턴스에 주기적으로 요청을 보내 정상 응답 여부를 확인하는 기능입니다. "살아있음"이 아니라 "서비스 가능함"을 확인하는 것이 핵심입니다. Unhealthy 판정 시 해당 서버로의 트래픽 전송을 자동으로 중단합니다.

Auto Scaling

ASG (Auto Scaling Group)

EC2 인스턴스의 수를 정의된 정책에 따라 자동으로 늘리거나 줄이는 그룹입니다. Min / Desired / Max 세 가지 용량값을 설정하고, 스케일링 정책에 따라 Desired 값이 조정됩니다.

Auto Scaling

Launch Template

ASG가 새 인스턴스를 생성할 때 사용하는 EC2 설계도입니다. AMI, 인스턴스 타입, 보안 그룹, User Data(부팅 스크립트) 등을 미리 정의해 둡니다.

Auto Scaling

Scale Out / Scale In

Scale Out은 인스턴스를 추가하는 것(확장)이고, Scale In은 인스턴스를 제거하는 것(축소)입니다. Scale Out은 빠르게, Scale In은 느리게 동작하도록 설정하는 것이 안정적입니다.

스케일링 정책

Target Tracking

CPU 사용률 70% 유지처럼 목표 메트릭 값을 설정하면 AWS가 알아서 인스턴스 수를 자동으로 계산하고 조정합니다. 설정이 가장 간단하고 대부분의 경우 최적이라 기본 선택지로 권장됩니다.

스케일링 정책

Step Scaling

CloudWatch 알람의 임계값 구간에 따라 단계적으로 스케일링하는 정책입니다. "CPU 70~85%면 2대 추가, 85% 이상이면 4대 추가"처럼 세밀하게 제어할 수 있습니다.

스케일링 정책

Scheduled Scaling

예약된 시간에 미리 스케일링하는 정책입니다. "매일 오전 9시에 인스턴스 5대로 증설"처럼 트래픽 패턴이 예측 가능한 경우에 활용합니다.

Auto Scaling

Cooldown (쿨다운)

스케일링 작업 완료 후 다음 스케일링이 시작되기 전 대기하는 안정화 시간입니다. 기본값은 300초(5분)입니다. 쿨다운이 없으면 새 인스턴스가 뜨기도 전에 또 스케일 아웃이 반복될 수 있습니다.

ALB 내부 구조

ALB는 Listener → Rules → Target Group 순서로 트래픽을 처리합니다.

① Listener

포트 80 (HTTP) / 포트 443 (HTTPS) 수신 대기

외부에서 들어오는 요청을 받는 관문

↓

② Rules

조건 평가 — URL 경로 / 호스트명 / 헤더 / 쿼리 파라미터

예) /api/* → API 서버, /images/* → 이미지 서버

↓

③ Target Group

대상 인스턴스 묶음으로 트래픽 전달 + Health Check 수행

Healthy 인스턴스에만 트래픽 분배

↓

④ EC2

실제 서비스 처리

ASG와 연결되어 자동으로 등록/해제

ALB vs NLB 비교

항목	ALB	NLB
OSI 계층	L7 (애플리케이션)	L4 (전송)
프로토콜	HTTP, HTTPS, WebSocket	TCP, UDP, TLS
라우팅 기준	URL, 호스트명, 헤더 등 콘텐츠 기반	IP, 포트 기반
고정 IP	미지원 (DNS 기반)	지원 (EIP 할당 가능)
주요 사용처	일반 웹 서비스, 마이크로서비스	게임, 금융, IoT 등 초저지연 필요

Auto Scaling Group (ASG) 핵심 개념

Min / Desired / Max 용량 설정

Min (최소)

항상 유지할 최소 인스턴스 수

예) 2

Desired (목표)

현재 유지하려는 인스턴스 수 (정책이 조정)

예) 4

Max (최대)

스케일 아웃 시 넘을 수 없는 상한선

예) 10

스케일링 정책은 Desired 값을 바꿉니다. Desired가 Min보다 낮아지거나 Max보다 높아질 수는 없습니다. Min은 비용의 하한선, Max는 비용의 상한선이기도 합니다.

스케일링 정책 3가지 비교

대부분 권장

Target Tracking

목표값(예: CPU 70%)만 설정하면 AWS가 알아서 인스턴스 수를 계산합니다. 가장 간단하고 자동화 수준이 높습니다.

세밀한 제어

Step Scaling

임계값 구간별로 다른 스케일링 폭을 설정합니다. 트래픽 패턴을 잘 알고 있을 때 세밀하게 제어할 수 있습니다.

예측 가능한 패턴

Scheduled

특정 시간에 미리 스케일링합니다. 점심시간 트래픽 급증처럼 패턴이 예측 가능한 경우에 활용합니다.

Scale Out → Scale In 전체 흐름

Scale Out (확장) 흐름

CPU 사용률 급증→ CloudWatch 알람→ ASG 트리거→ Launch Template으로 EC2 생성→ Health Check 통과→ Target Group 등록 → 트래픽 수신

Scale In (축소) 흐름

CPU 사용률 감소→ CloudWatch 알람 해제→ ASG 트리거→ Target Group에서 인스턴스 제거→ 진행 중 요청 처리 완료 대기→ EC2 종료

Scale In은 진행 중인 요청이 끊기지 않도록 Connection Draining(연결 드레이닝) 과정을 거친 후 종료합니다.

ALB + ASG 보안 설계 원칙

EC2 보안 그룹에 0.0.0.0/0 허용은 금지
외부에서 EC2 IP로 직접 접근하면 ALB의 Health Check, 로깅, 보안 기능이 모두 무력화됩니다. EC2는 오직 ALB를 통해서만 접근해야 합니다.

올바른 보안 그룹 설정
ALB 보안 그룹: 인터넷(0.0.0.0/0)에서 포트 80/443 허용
EC2 보안 그룹: ALB 보안 그룹 ID를 소스로 지정하여 ALB에서 오는 트래픽만 허용
→ 이렇게 하면 EC2 IP를 알아도 외부에서 직접 접근이 불가능합니다.

실습 구축 순서

Launch Template→ ALB 생성→ Target Group→ ASG 생성 및 TG 연결

실습 후 리소스 삭제 순서

ASG→ Launch Template→ Target Group→ ALB→ 보안 그룹

ASG를 먼저 삭제하지 않으면 EC2 인스턴스가 자동으로 다시 생성됩니다. 반드시 ASG 삭제를 가장 먼저 진행하세요.

3일차 핵심 원칙 5가지

• 1
  단일 서버는 단일 장애점 — ALB로 분산하라서버가 1대면 그 서버가 죽는 순간 서비스 전체가 중단됩니다. ALB로 여러 서버에 분산하면 한 대가 장애가 나도 나머지가 트래픽을 받습니다.
• 2
  Health Check는 "살아있음"이 아니라 "서비스 가능함"을 확인서버 프로세스가 실행 중이어도 애플리케이션이 오류 상태일 수 있습니다. 실제 API 엔드포인트에 응답 확인을 해야 의미 있는 헬스 체크입니다.
• 3
  Scale Out은 빠르게, Scale In은 느리게트래픽이 급증할 땐 빠르게 서버를 늘려야 하지만, 줄일 땐 처리 중인 요청이 끊기지 않도록 충분한 대기 시간을 두어야 합니다.
• 4
  EC2 SG에 0.0.0.0/0은 금지 — ALB SG만 허용EC2로의 직접 접근을 차단하고 반드시 ALB를 통해서만 트래픽이 들어오도록 설계해야 보안 계층이 유지됩니다.
• 5
  Target Tracking이 대부분의 경우 최적 — 복잡하게 만들지 마라Step Scaling은 설정이 복잡하고 잘못 설정하면 오히려 불안정해집니다. 특별한 이유가 없다면 Target Tracking으로 시작하는 것이 정답입니다.

셀프 체크 Q&A

ALB가 왜 필요한지 비기술자에게 설명해보세요.

힌트: "마트 계산대 안내원" 비유를 활용하세요.

마트에 계산대가 10개 있어도 안내원 없이 손님이 한 줄로만 몰리면 나머지 9개 계산대는 놀고 1개만 터집니다. ALB는 손님(트래픽)을 한가한 계산대(서버)로 안내하는 역할을 합니다. 덕분에 특정 서버에 부하가 몰리지 않고, 한 서버가 고장 나도 다른 서버로 자동으로 보냅니다.

Auto Scaling의 Scale Out → Scale In 전체 과정을 설명해보세요.

힌트: CloudWatch 알람 → ASG → Launch Template → Health Check → Target Group 흐름

트래픽이 증가해 CPU 사용률이 임계값을 넘으면 CloudWatch가 알람을 발생시킵니다. ASG가 이를 감지하고 Launch Template에 정의된 대로 새 EC2를 생성합니다. 인스턴스가 Health Check를 통과하면 Target Group에 등록되어 트래픽을 받기 시작합니다. 이후 트래픽이 줄면 반대로 Scale In이 발생하고, 연결 드레이닝 후 인스턴스가 종료됩니다.

왜 EC2 SG에 0.0.0.0/0이 아닌 ALB SG를 소스로 지정해야 하나요?

힌트: ALB를 우회한 직접 접근 차단, 보안 계층 유지

0.0.0.0/0을 허용하면 누구나 EC2 IP로 직접 접근할 수 있어 ALB를 완전히 우회할 수 있습니다. ALB의 WAF, 로깅, Health Check 등 보안 기능이 모두 무력화됩니다. ALB 보안 그룹 ID를 소스로 지정하면 ALB를 통한 트래픽만 허용되어, 외부에서 EC2 IP를 알아도 직접 접근이 차단됩니다.

Day 1 ~ 3 전체 학습 흐름 연결

문제 정의 → VPC 설계 → ALB + Auto Scaling — 3일간의 여정

Day 1

문제 정의 & 기초

DX 컨설턴트 역할5W1H 프레임워크Well-Architected 소개

→

Day 2

VPC & 네트워크

VPC / 서브넷 설계SG / NACL 보안라우팅 테이블

→

Day 3

ALB + Auto Scaling

ALB 트래픽 분산ASG 자동 확장고가용성 아키텍처

3일간 배운 것이 합쳐지면:
VPC(네트워크) + SG(보안) + ALB(분산) + ASG(탄력성) = 프로덕션 아키텍처

Day 1: Why — 왜 이 문제를 해결해야 하는가  →  Day 2: Where — 어디에 인프라를 놓을 것인가  →  Day 3: How — 어떻게 안정적으로 운영할 것인가

 

 

여기까지 읽어주셔서 감사합니다.

수업내용과 별개로 지금까지 kt 에이블스쿨을 수강하며 다양한 강사님들의

수업을 들어보았는데요.

모든 강사님들이 장시간동안 강의를 진행하시면서

말을 절지않고 언제나 논리정연하게 말씀하시는게 인상깊었습니다.

저는 발표 대본을 미리 작성하지 않으면 생각이 꼬여

하고 싶은 말을 제대로 전달하지 못하는 경우가 많습니다.

그래서 짧은 발표라도 대본을 미리 작성하는 습관을 들이고 있는데요.

언젠가 저도 강사님들처럼 대본 없이도 전달력 있게 말할 수 있는 역량을 갖추고 싶습니다.

 

이상으로 DX 컨설턴트 8주차 후기를 마치겠습니다.
다음주 5차 미프도 화이팅..ㅠ