안내

본 요약집은 AWS Certified Cloud Practitioner (CLF-C02) 시험 합격을 위해 Module 1부터 Module 9까지의 핵심 서비스, 필수 개념, 빈출 키워드 및 문제 해결 매칭 공식을 압축 정리한 휴대용 요약 문서입니다.

1. 클라우드 개념 및 AWS 기본 원칙 (Module 1)

클라우드 컴퓨팅 6대 핵심 이점 (6 Advantages of Cloud Computing)

1. 자본 비용(CapEx)을 가변 비용(OpEx)으로 전환: 선행 인프라 투자 없이 사용한 만큼만 지불(Pay-as-you-go).
2. 거대한 규모의 경제(Economies of Scale): 수백만 고객의 사용량이 누적되어 AWS가 더 낮은 가격으로 인프라 제공.
3. 용량 추정 불필요(Stop Guessing Capacity): 수요 예측 실패로 인한 리소스 낭비 또는 부족 방지 (오토 스케일링).
4. 속도 및 민첩성 향상(Increase Speed and Agility): 리소스 배포 시간을 몇 주에서 몇 분 단위로 단축.
5. 데이터 센터 운영 및 유지 관리 비용 투자 중단: 랙 설치, 전력, 냉각 등 비즈니스와 무관한 잡무(Undifferentiated Heavy Lifting) 제거.
6. 몇 분 만에 글로벌 확장(Go Global in Minutes): 전 세계 여러 리전에 걸쳐 최소한의 지연 시간으로 앱 배포.

클라우드 배포 모델 3가지

• 클라우드 기반 (All-in Cloud / Public): 모든 인프라와 애플리케이션이 클라우드 상에서 실행됨.
• 온프레미스 / 프라이빗 클라우드 (Private): 자체 데이터 센터에 가상화 기술을 사용하여 리소스를 배포하고 직접 관리함.
• 하이브리드 (Hybrid): 온프레미스 레거시 시스템과 클라우드 리소스를 전용선(Direct Connect)이나 VPN으로 연결하여 통합 운영함.

AWS 클라우드 채택 프레임워크 (AWS CAF - 6대 관점)

• 비즈니스 관점 (Business Perspectives):
  • 비즈니스 (Business): 비즈니스 모델, 가치 창출, 전략적 성과 연계.
  • 인력 (People): 클라우드 역량 교육, 조직 변화 관리, 인재 육성.
  • 거버넌스 (Governance): 포트폴리오 관리, 클라우드 투자 최적화, 비즈니스 프로세스 통제.
• 기술 관점 (Technical Perspectives):
  • 플랫폼 (Platform): 아키텍처 현대화, 워크로드 마이그레이션, 클라우드 네이티브 솔루션 구축.
  • 보안 (Security): 데이터 기밀성/무결성, IAM 권한, 규정 준수 및 위협 방어.
  • 운영 (Operations): 상태 관찰성(Observability), 인시던트 관리, 비즈니스 연속성 유지.

클라우드 마이그레이션 7대 전략 (7 Rs Migration Strategies)

1. Rehost (Lift and Shift): 애플리케이션 변경 없이 그대로 AWS 클라우드(EC2)로 이전.
2. Replatform (Lift, Tinker and Shift): 핵심 아키텍처는 유지하되 일부 구성 요소를 관리형 서비스(RDS 등)로 최적화하여 이전.
3. Refactor / Rearchitect: 클라우드 네이티브(서버리스, 마이크로서비스 등) 기능과 성능을 극대화하도록 애플리케이션을 전면 재설계.
4. Repurchase (Drop and Shop): 기존 소프트웨어를 버리고 SaaS(클라우드 기반 소프트웨어) 서비스로 구매 전환.
5. Retain (Keep / Revisit): 당장 마이그레이션할 준비가 되지 않았거나 비즈니스상 보류할 워크로드를 온프레미스에 유지.
6. Retire: 더 이상 사용되지 않는 불필요한 레거시 애플리케이션을 안전하게 폐기/종료.
7. Relocate (Hypervisor-level): VMware Cloud on AWS 등을 활용해 코드나 설정 변경 없이 하이퍼바이저 수준에서 인프라를 이전.

2. 컴퓨팅 서비스 및 EC2 요금 모델 (Module 2)

Amazon EC2 인스턴스 패밀리 매칭 공식

• 범용 (General Purpose - M, T): 컴퓨팅, 메모리, 네트워킹의 균형 (웹 서버, 소형 DB, 개발 환경).
• 컴퓨팅 최적화 (Compute Optimized - C): 고성능 프로세서 요구 워크로드 (배치 처리, 미디어 변환, 고성능 웹 서버, 머신러닝 추론, 게임 서버).
• 메모리 최적화 (Memory Optimized - R, X, z): 대규모 인메모리 데이터세트 처리 (인메모리 DB, 분산 캐시, 실시간 빅데이터 처리).
• 스토리지 최적화 (Storage Optimized - I, D, H): 순차적 대규모 로컬 스토리지 I/O 요구 (데이터 웨어하우스, 분산 파일 시스템, NoSQL DB).
• 가속 컴퓨팅 (Accelerated Computing - P, G, F): 하드웨어 GPU 가속기 (3D 그래픽 렌더링, 딥러닝 훈련, 자율주행 시뮬레이션).

EC2 요금 옵션 비교

EC2 스토리지: 인스턴스 스토어 vs EBS

• EC2 인스턴스 스토어 (Instance Store): 호스트 물리 서버에 직접 장착된 임시(Ephemeral/휘발성) 블록 스토리지. 인스턴스가 중지/종료되면 데이터가 영구 소실됨 (버퍼, 캐시, 스크래치 데이터용).
• Amazon EBS: 네트워크를 통해 연결되는 영구(Persistent) 가상 블록 스토리지. 인스턴스 중지 후에도 데이터 유지 및 스냅샷 백업 지원.

스케일링 방식

• 수직적 스케일링 (Vertical Scaling / Scale-up): 인스턴스 사양(vCPU, RAM)을 업그레이드.
• 수평적 스케일링 (Horizontal Scaling / Scale-out): EC2 Auto Scaling을 통해 인스턴스 개수를 동적으로 증감.

3. 추가 컴퓨팅 및 인프라 자동화 (Module 3)

서버리스, 컨테이너, 배포 자동화 서비스 매칭

• AWS Lambda: 이벤트 기반 서버리스 컴퓨팅, 코드만 업로드하면 자동 실행/스케일링, 최대 15분 실행, 밀리초(ms) 단위 과금.
• Amazon ECS: AWS 독점의 간단하고 강력한 완전관리형 컨테이너 오케스트레이션 서비스.
• Amazon EKS: Kubernetes 표준 환경을 AWS 상에서 그대로 구동하는 완전관리형 오픈소스 오케스트레이션 서비스.
• AWS Fargate: 서버(EC2)를 직접 프로비저닝하거나 관리할 필요 없는 서버리스 컨테이너 컴퓨팅 엔진 (ECS/EKS 모두 지원).
• Amazon ECR (Elastic Container Registry): 완전관리형 컨테이너 이미지 저장소/레지스트리 (Docker/OCI 표준 지원).
• AWS App Runner: 컨테이너 인프라 지식 없이 소스 코드나 컨테이너 이미지로부터 웹 앱을 전자동 배포하는 서비스.
• AWS Elastic Beanstalk: 개발자가 코드만 업로드하면 인프라 프로비저닝, 로드 밸런싱, 오토 스케일링, 모니터링을 자동 처리하는 완전관리형 PaaS 플랫폼 (기본 인프라 제어 권한 유지).
• AWS CloudFormation: 코드형 인프라 (IaC, Infrastructure as Code) 서비스로, JSON/YAML 템플릿을 통해 AWS 전체 리소스를 선언적으로 자동 프로비저닝 및 반복 배포.

엣지 및 하이브리드 컴퓨팅 (Edge Computing 4총사)

• AWS Outposts: 온프레미스 데이터 센터에 실제 AWS 하드웨어 랙을 직접 설치하여 클라우드와 동일한 AWS API/콘솔로 운영 (초저지연, 데이터 레지던시/주권 법적 규제 완벽 준수).
• AWS Local Zones: 대규모 인구 밀집 대도시(서울, LA 등) 인근에 AWS가 직접 컴퓨팅/스토리지를 배치하여 한 자릿수 밀리초(sub-10ms) 초저지연 제공 (고객 자체 IDC 불필요).
• AWS Wavelength: 5G 이동통신사(SKT, 버라이즌 등) 통신망 데이터 센터 내에 AWS 인프라를 내장하여 모바일 엣지 기기와의 초저지연 실시간 통신 지원 (자율주행, 실시간 게임, AR/VR).
• AWS Snow Family 엣지 컴퓨팅 (Snowball Edge / Snowcone): 인터넷 연결이 끊긴 격리된 환경(선박, 광산, 재난 지역)에서 로컬 데이터 수집, 온보드 EC2 컴퓨팅 및 ML 추론 수행.
• AWS IoT Greengrass: IoT 엣지 디바이스에서 로컬로 데이터를 수집/필터링하고 클라우드 연결 없이도 오프라인 상태에서 Lambda 함수 및 ML 모델을 자율 실행하는 소프트웨어.

엣지 서버리스 컴퓨팅 & 네트워킹 가속 (Edge Serverless & Acceleration)

• Lambda@Edge: CloudFront 엣지 로케이션에서 실행되는 서버리스 함수 (Node.js/Python), 최종 사용자와 가장 가까운 엣지에서 HTTP 요청/응답 변환, 사용자 인증, URL 리디렉션, 동적 웹 렌더링 수행.
• CloudFront Functions: 엣지 로케이션에서 초경량 JavaScript 코드를 마이크로초(µs) 단위로 초고속 실행 (HTTP 헤더 조작, 캐시 키 정규화, URL 재작성).
• AWS Global Accelerator: 2개의 고정 Anycast IP를 활용하여 전 세계 사용자의 TCP/UDP 트래픽을 공용 인터넷 대신 AWS 전용 글로벌 사설 네트워크를 통해 가장 가까운 최적 엔드포인트(ALB, NLB, EC2)로 고속 라우팅 (지연 시간 최대 60% 단축, 패킷 손실 방지).

AWS 엣지 인프라 4대 유형 완벽 비교표

4. 글로벌 인프라 및 고가용성 (Module 4)

글로벌 인프라 구성 3대 요소

• AWS 리전 (Region): 전 세계 지리적 위치, 지리적으로 격리된 최소 2개(대부분 3개 이상)의 가용 영역(AZ)으로 구성됨.
  • 리전 선택 4대 기준: 규정 준수/데이터 주권(최우선 고려), 사용자와의 근접성(지연 시간 단축), 서비스 가용성(신규 기능 여부), 비용(리전별 조세/운영비 가격차).
• 가용 영역 (AZ, Availability Zone): 독립된 전력, 냉각, 물리 보안을 갖춘 하나 이상의 개별 데이터 센터. AZ 간에는 전용 초저지연 광케이블로 상호 연결됨.
  • 고가용성(High Availability) 및 재해 복구(Disaster Recovery)를 위해 다중 AZ(Multi-AZ) 아키텍처 구성 필수.
• 엣지 로케이션 (Edge Location / PoP): 전 세계 주요 도시에 위치한 캐시 서버 거점으로, Amazon CloudFront(CDN), Amazon Route 53(DNS), AWS Global Accelerator, AWS Shield, AWS WAF를 호스팅하여 콘텐츠 전송 지연 시간을 단축하고 엣지 보안을 제공함.

5. 네트워킹 및 트래픽 분산 (Module 5)

핵심 네트워킹 구성 요소

• Amazon VPC: 사용자 전용의 논리적으로 격리된 가상 네트워크 (IP CIDR 블록 정의).
• 서브넷 (Subnet): VPC 내부의 IP 주소 세그먼트 (단일 AZ에 종속).
  • 퍼블릭 서브넷 (Public Subnet): 인터넷 게이트웨이(IGW)로 향하는 라우팅이 있어 인터넷과 양방향 직접 통신 가능.
  • 프라이빗 서브넷 (Private Subnet): 인터넷 직접 경로가 차단된 격리 서브넷 (DB, 백엔드 서버 배치).
• 인터넷 게이트웨이 (IGW): VPC와 공용 인터넷 간의 양방향 통신을 연결하는 확장성 높은 관문.
• NAT 게이트웨이 (NAT Gateway): 프라이빗 서브넷의 인스턴스가 패치/업데이트를 위해 아웃바운드 인터넷 트래픽은 허용하되, 외부에서의 인바운드 접속은 원천 차단하는 관리형 게이트웨이 (퍼블릭 서브넷에 배치).
• VPC 엔드포인트 (VPC Endpoints): 인터넷 게이트웨이나 NAT 장치 없이 VPC 내부에서 AWS 서비스(S3, DynamoDB 등)에 비공개(Private)로 직접 연결하는 통로.
  • 게이트웨이 엔드포인트 (Gateway Endpoint): S3 및 DynamoDB 전용 (무료 제공, 라우팅 테이블 수정 방식).
  • 인터페이스 엔드포인트 (Interface Endpoint / AWS PrivateLink): ENI(사설 IP)를 생성하여 대부분의 AWS 서비스 및 서드파티 서비스에 비공개 연결.

보안 그룹 (Security Group) vs 네트워크 ACL (NACL) 필수 비교

하이브리드 연결 및 DNS/CDN

• AWS Direct Connect (DX): 공용 인터넷을 완전히 우회하여 온프레미스와 AWS 간에 구축하는 전용 비공개 물리적 네트워크 회선 (일관된 대역폭, 고신뢰성, 최고 보안).
• AWS Site-to-Site VPN: 인터넷을 통과하지만 IPsec으로 암호화된 가상 터널을 생성하여 빠르고 저렴하게 연결.
• VPC 피어링 (VPC Peering): 2개의 VPC를 1:1로 직접 연결 (전이적 라우팅 불가).
• AWS Transit Gateway: 수천 개의 VPC와 온프레미스 네트워크를 중앙 단일 허브(Hub-and-Spoke)로 연결.
• Amazon CloudFront: 엣지 로케이션을 활용하여 정적/동적 웹 콘텐츠를 전 세계 사용자에게 저지연 전송하는 글로벌 CDN.

Amazon Route 53 라우팅 정책 6가지

1. 단순 라우팅 (Simple): 도메인에 대해 특정 단일 리소스(IP)로 트래픽 전달.
2. 가중치 기반 라우팅 (Weighted): 지정된 비율(%)에 따라 트래픽을 분산 (새 버전 A/B 테스트).
3. 지연 시간 라우팅 (Latency): 사용자에게 네트워크 지연 시간이 가장 짧은 최적 리전으로 라우팅.
4. 지리 위치 라우팅 (Geolocation): 사용자의 실제 접속 국가/대륙 위치에 따라 라우팅.
5. 지리 근접 라우팅 (Geoproximity): 리소스 지리적 위치와 편향값(Bias)을 기준으로 트래픽 라우팅.
6. 장애 조치 라우팅 (Failover): 헬스체크(Health Check) 기반으로 기본(Primary) 리소스 장애 시 보조(Secondary) 재해 복구 리소스로 자동 전환.

6. 스토리지 서비스 (Module 6)

3대 스토리지 유형 비교 요약

Amazon S3 스토리지 티어 구분

• S3 Standard: 자주 액세스하는 데이터 (핫 데이터, 고성능, 다중 AZ).
• S3 Intelligent-Tiering: 데이터 액세스 패턴을 알 수 없거나 변동이 심할 때 자동 티어링 (모니터링 수수료 발생).
• S3 Standard-IA: 자주 액세스하지 않지만 즉각적인 조회가 필요한 데이터 (콜드 데이터, 다중 AZ, 검색 비용 발생).
• S3 One Zone-IA: 1개 AZ에만 저장하여 20% 저렴 (재생성 가능한 2차 백업용).
• S3 Glacier Flexible Retrieval: 몇 분에서 몇 시간 내 복구 가능한 장기 아카이브 스토리지.
• S3 Glacier Deep Archive: 가장 저렴한 비용, 12시간 이내 검색 가능한 극장기 규정 보관 데이터용.

Amazon S3 핵심 관리 및 보안 기능

• S3 버전 관리 (Versioning): 동일 객체의 여러 버전을 보관하여 의도치 않은 삭제나 덮어쓰기 복구 지원.
• S3 객체 잠금 (Object Lock / WORM - Write Once, Read Many): 정해진 보존 기간 동안 객체의 수정 및 삭제를 원천 차단 (금융/의료 규정 준수용 Compliance 및 Governance 모드).
• S3 수명 주기 정책 (Lifecycle Rules): 시간 경과에 따라 객체를 더 저렴한 스토리지 티어(Standard -> IA -> Glacier)로 자동 이동하거나 만료 삭제.
• S3 복제 (Replication): 다중 리전 복제(CRR) 및 동일 리전 복제(SRR)를 통한 재해 복구 및 지연 시간 단축.
• S3 멀티파트 업로드 (Multipart Upload): 100MB 이상 대용량 객체를 분할 병렬 업로드하여 전송 속도 극대화 및 네트워크 실패 복원력 제공.

특수 파일 스토리지 (Amazon FSx 제품군)

• Amazon FSx for Windows File Server: 완전관리형 네이티브 Windows 파일 시스템 (SMB 프로토콜, Microsoft Active Directory 완벽 통합).
• Amazon FSx for Lustre: 고성능 컴퓨팅(HPC), 머신러닝, 미디어 렌더링 워크로드용 초고속 병렬 파일 시스템 (S3와 완벽 연동).

데이터 마이그레이션 & 하이브리드 스토리지

• AWS Snowcone: 8TB 소형 러기드 엣지 데이터 전송/컴퓨팅 장치.
• AWS Snowball Edge: 80TB~Petabyte 규모 오프라인 대규모 데이터 물리적 마이그레이션 & 엣지 컴퓨팅 장치.
• AWS Snowmobile: 최대 100PB 초대형 엑사바이트 규모 데이터 트럭 운송 솔루션.
• AWS Storage Gateway: 온프레미스와 S3/EBS 간 하이브리드 연동 (File Gateway, Volume Gateway, Tape Gateway).

7. 데이터베이스 및 인메모리 캐싱 (Module 7)

AWS 데이터베이스 포트폴리오 매칭 공식

• Amazon RDS: 관리형 관계형 데이터베이스 (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 엔진 지원).
  • Multi-AZ: 대기(Standby) 복제본에 동기식 복제 -> 고가용성(HA) 및 재해 복구(DR) 목적 (읽기 트래픽 처리 불가).
  • 읽기 전용 복제본 (Read Replica): 비동기 복제 -> 읽기(Read) 트래픽 부하 분산 및 성능 확장 목적.
• Amazon Aurora: AWS 클라우드 네이티브 관계형 DB, MySQL 대비 5배 / PostgreSQL 대비 3배 성능, 3개 AZ에 걸쳐 6개 데이터 사본 자동 복제, 최대 15개 Read Replica 지원.
• Amazon Aurora Serverless: 실제 애플리케이션 요청에 따라 자동으로 시작, 확장, 중지되는 비용 효율적인 서버리스 관계형 DB.
• Amazon DynamoDB: 완전관리형 서버리스 NoSQL 데이터베이스 (Key-Value 및 Document), 한 자릿수 밀리초(sub-10ms) 지연 시간, 오토 스케일링, 글로벌 복제(Global Tables).
• Amazon ElastiCache: 인메모리 캐싱 서비스 (Redis, Memcached 지원), 마이크로초 단위 응답 속도, 백엔드 DB 읽기 부하 대폭 절감.
• Amazon DocumentDB: MongoDB와 완벽 호환되는 완전관리형 문서(JSON) 데이터베이스.
• Amazon Neptune: 수십억 개의 연결 관계를 탐색하는 완전관리형 그래프 데이터베이스 (사기 탐지, 소셜 네트워크 추천).
• Amazon DynamoDB Accelerator (DAX): DynamoDB 전용 인메모리 캐시로 읽기 속도를 밀리초에서 마이크로초 단위로 향상.
• Amazon QLDB (Quantum Ledger Database): 투명하고 변경 불가능(Immutable)하며 암호학적으로 검증 가능한 원장 데이터베이스.
• AWS DMS (Database Migration Service): 소스 DB 가동 중단 없이 동종/이종 DB 간 지속적 데이터 마이그레이션 지원 (AWS SCT를 통해 스키마 변환 병행).

8. AI / ML 및 데이터 분석 (Module 8)

AWS 3-Tier AI/ML 스택

• Tier 1: 사전 구축 AI 서비스 (Pre-built AI Services) (ML 전문 지식 없이 API 호출로 즉시 사용)
  • Amazon Comprehend: 자연어 처리(NLP), 문서 감정 분석, 키워드 추출.
  • Amazon Polly: 텍스트를 사실적인 음성으로 변환 (TTS).
  • Amazon Transcribe: 음성을 텍스트로 변환 (STT).
  • Amazon Translate: 다국어 번역 서비스.
  • Amazon Rekognition: 이미지 및 비디오 객체/얼굴/텍스트 분석.
  • Amazon Textract: 스캔 문서 및 표/양식에서 OCR 텍스트 자동 추출.
  • Amazon Lex: 대화형 챗봇 구축 엔진 (Amazon Alexa 기술 기반).
  • Amazon Personalize: 실시간 개인화 추천 엔진 (Amazon.com 추천 기술 기반).
  • Amazon Kendra: 자연어 검색을 지원하는 기업용 지능형 검색 서비스.
• Tier 2: Amazon SageMaker AI: ML 모델의 데이터 준비, 구축, 훈련, 튜닝, 배포 전 과정을 지원하는 완전관리형 MLOps 플랫폼.
• Tier 3: 프레임워크 및 인프라: PyTorch, TensorFlow, GPU 가속 EC2 인스턴스.

생성형 AI (Generative AI) 도구

• Amazon Bedrock: 단일 통합 API로 최고의 파운데이션 모델(Claude, Stable Diffusion, Amazon Titan 등)을 제공하는 완전관리형 서버리스 서비스.
• Amazon SageMaker JumpStart: 사전 구축된 오픈소스/상용 파운데이션 모델 허브 (클릭 배포 및 미세 조정 Fine-Tuning).
• Amazon Q Business: 기업 내부 데이터 저장소를 안전하게 연결하여 업무 질문에 답변하는 기업용 AI 어시스턴트.
• Amazon Q Developer: IDE 내에서 다양한 언어(Java, Python, JS, C# 등)로 코드 자동 완성과 보안 검토를 수행하는 개발자 전용 AI 어시스턴트.

데이터 파이프라인 및 분석 서비스

• Amazon Kinesis Data Streams: 대규모 실시간 스트리밍 데이터 수집.
• Amazon Data Firehose: 스트리밍 데이터를 준실시간(몇 초 내)으로 S3, Redshift, OpenSearch에 자동 로드하는 완전관리형 ETL.
• AWS Glue: 서버리스 Visual ETL 서비스 & AWS Glue 데이터 카탈로그(메타데이터 중앙 인벤토리).
• AWS Glue DataBrew: 코딩 없이 250개 이상의 기본 변환으로 데이터를 시각적으로 정제 및 정규화하는 데이터 준비 도구.
• AWS Lake Formation: 몇 일 만에 안전한 중앙 데이터 레이크를 구축하고 거버넌스/접근 권한을 일괄 관리하는 서비스.
• Amazon Athena: S3 데이터 레이크에 저장된 원시 데이터를 별도 이동 없이 표준 SQL로 직접 쿼리하는 서버리스 분석 서비스.
• Amazon Redshift: 페타바이트 규모의 대규모 병렬 처리(MPP) 및 열 형식(Columnar) 스토리지를 갖춘 데이터 웨어하우스(DW).
• Amazon EMR: Apache Spark, Hadoop, Hive를 실행하는 대규모 분산 빅데이터 처리 클러스터.
• Amazon QuickSight: 클라우드 기반 대화형 BI 대시보드 및 리포트 시각화 도구 (Amazon Q 통합).
• Amazon OpenSearch Service: 대용량 로그 분석, 실시간 검색 및 시스템 관찰성(Observability) 모니터링.

9. 클라우드 보안, IAM, 컴플라이언스 (Module 9)

AWS 공동 책임 모델 (Shared Responsibility Model)

IAM (Identity and Access Management) 핵심 원칙 & 도구

• 기본 거부 (Default Deny): 모든 권한은 기본적으로 차단되어 있으며 명시적 허용(Allow)이 있어야 접근 가능.
• 최소 권한의 원칙 (Least Privilege): 업무에 꼭 필요한 최소한의 권한만 부여.
• AWS 계정 루트 사용자: 무제한 최고 권한, MFA 필수 설정, 일상 업무 사용 금지.
• IAM 사용자 / 그룹: 고유한 사람/앱 자격 증명 및 권한 상속을 위한 사용자 그룹.
• IAM 역할 (Role): 정적 비밀번호 없이 임시 자격 증명을 부여받는 위임 메커니즘 (EC2가 S3 접근 시, 외부 연동 Federation 시 사용).
• AWS STS (Security Token Service): IAM 역할 수임 시 임시 보안 자격 증명(Session Token 등)을 발급하는 핵심 서비스.
• IAM 정책 (Policy): JSON 문서로 정의 (Effect: Allow/Deny, Action: API 호출 목록, Resource: 리소스 ARN).
• AWS IAM Identity Center: 멀티 계정 및 사내 IDP(Active Directory) 연동 Single Sign-On (SSO) 중앙 관리.
• IAM Access Analyzer: 리소스 정책을 자동 분석하여 의도치 않게 외부 퍼블릭이나 타 계정에 공유된 리소스를 탐지.
• IAM 자격 증명 보고서 (Credential Report): 계정 내 모든 사용자의 비밀번호, 액세스 키, MFA 설정 현황을 CSV 파일로 감사 조회.

보안, 암호화, 위협 탐지 및 규정 준수 서비스 매칭

• AWS Artifact: AWS의 공식 보안 및 규정 준수 보고서(SOC, PCI-DSS, ISO 등)와 온라인 계약(BAA 등)을 무료로 온디맨드 다운로드하는 규정 준수 포털.
• AWS Secrets Manager: DB 비밀번호, API 키 등 보안 암호를 저장하고 자동 교체(Rotation)하는 서비스.
• AWS KMS (Key Management Service): 암호화 키를 생성 및 관리 (키는 KMS 외부로 절대 이탈하지 않음).
• AWS Certificate Manager (ACM): HTTPS 통신을 위한 SSL/TLS 공인 인증서 무료 발급, 프로비저닝 및 자동 갱신.
• AWS Shield Standard: 추가 비용 없이 L3/L4 일반 DDoS 공격을 자동 완화 (Route 53, CloudFront, ELB에 기본 포함).
• AWS Shield Advanced: 전담 DDoS 대응팀(DRT), 상세 진단 보고서, L3/L4/L7 보호를 제공하는 유료 서비스.
• AWS WAF: Layer 7(웹 애플리케이션) 방화벽, Web ACL을 통해 악성 IP 차단 및 SQL Injection/XSS 공격 방어.
• Amazon Macie: S3 버킷에 저장된 개인식별정보(PII) 및 민감 데이터를 기계학습(ML)으로 자동 탐지.
• Amazon Inspector: EC2, 컨테이너(ECR), Lambda의 소프트웨어 취약성 및 보안 모범 사례 위반을 자동 스캔.
• Amazon GuardDuty: 계정 메타데이터 및 네트워크 로그를 분석하여 지능형 위협 및 이상 징후를 탐지 (ML 기반).
• Amazon Detective: GuardDuty 등에서 탐지된 보안 위협의 근본 원인(Root Cause)을 그래프 분석으로 시각화 조사.
• AWS Security Hub: 다양한 보안 서비스의 결과를 단일 대시보드에 집계하고 '인사이트(Insights)'로 정리하여 관리.

10. 시험 직전 1초 컷: 상황별 키워드 매칭 공식 (Cheat Sheet)

그중 하나는 개발하는 방식에 다들 각자 자기만의 확고한 신념이 생겼다는 것이다.

물론 조직 단위의 팀 프로젝트에서는 방식을 통일시키는 경우가 많다. (우리 팀은 아니지만)

여기서는 순전히 내가 개발의 히스토리 중 하나에 대해 쓰고 싶어서 쓴다.

필자는 개발을 할 때 대체적으로 planning, design, build 이렇게 3가지 단계로 놓고 진행한다.

각각의 단계에는 AI가 읽거나 작성한 문서들이 들어 있다. 프로젝트 experience가 쌓이다 보니 느낀 점은, 결국 이 3개의 문서들에 대한 정합성이 맞아야 한다는 것이다.

AI는 결국 잊는다. 무조건 잊는다.

AI는 결국 잊는다. 아무리 context를 크게 가져간다고 해도 결국에는 잊을 수밖에 없다. 그리고 자기가 갖고 있는 기억의 잔존에 의지한다. 우리는 작업 중에 ai가 틀린 답변을 준 것을 여러번 경험해봤고 꽤 많은 경우의 원인이 ai의 잔존 기억을 바탕으로 추론하였기 때문이다.

이러면 결국 남는 것은 history, 즉 문서뿐이다.

ai는 억울하다 읽었을 뿐이다.

문제는 남겨진 문서들 중 어떤 것이 맞고 어떤 것이 틀린지 AI는 전혀 알 수 없다는 점이다.

• 플랜은 제대로 된 건데 디자인 쪽에서 틀린 건지?
• 플랜부터 틀렸는데 구현 쪽에서 이 문제를 발견해서 수정한 건지?

문서들이 서로 다른 이야기를 하고 있다면 AI 입장에서는 누구의 말이 맞는 것인지 알 수 있는 방법이 없다. 결국 혼란스러울 수밖에 없다.

그래서 말입니다

너무 당연한 결론이다.. 그치만 생각보다 지키기 어렵다.. ai가 너무나 많은 것은 토해내고 뿜어낸다. 이 어마어마한 양을 체크하기가 마음처럼 쉽지 않다.

그러므로 더더욱 각 개발 스텝에 문서들이 존재해야 하고, 그 문서들은 서로 같은 이야기를 해야 한다.

Planning, Design, Build 단계의 문서들이 서로 모순 없이 정합성을 유지해야 비로소 AI도 길을 잃지 않고 제대로 작동한다.

개발을 한다고 해서 우리의 손이 항상 키보드 위에서 바쁘게 움직이지만은 않는다.

개발을 모르는 사람이 개발자가 일하는 모습을 본다면 *"왜 가만히 아무것도 안 하고 있지?"*라고 생각할 만한 포인트들이 몇 가지 있다. 몇 년 전만 해도 우리는 컴파일, 빌드, 테스트 코드 실행, CI/CD 파이프라인 배포, 로컬 서버 또는 앱 재시작 등 개발자가 멍하니 있는 것처럼 보이는 '공백의 시간'이 분명히 다수 존재했다.

AI 대격변이 일어나 개발 환경이 크게 바뀐 2026년 현재에도 개발자가 멍해 보이는 공백 시간은 여전히 존재한다. 아니, 체감상 오히려 더 빈번하게, 더 자주 일어난다.

1. "My Code is Compiling!"에서 "AI Idle Time"으로

과거 개발자들 사이에서 유명했던 밈(Meme) 중에 "My Code is Compiling!"(내 코드 컴파일 중이야!)이 있었다. 코드 컴파일이 완료되기를 기다리는 몇 분 ~ 몇십 분의 공백 시간을 핑계 삼아 의자 칼싸움을 하던 모습을 비유한 밈으로, 필자 역시 상당히 좋아했던 해학이다.

이 밈을 2026년 현재에 그대로 사용하긴 힘들지만, 약간 바꿔볼 수는 있겠다.

요즘 개발자들에게는 빌드와 컴파일이 아니라, AI 에이전트가 코드를 짜고 테스트 루프를 돌리는 시간이 새로운 공백 시간이 되었다. 손으로 직접 타이핑하는 시간은 사라졌지만, 에이전트의 수행 결과를 기다리는 이 어중간한 대기 시간이 꽤나 자주 발생한다.

이 현상을 업계에서는 'AI Idle Time Paradox (AI 대기 시간의 역설)'이라 부르기도 한다. 어중간한 10초~3분 단위의 공백 시간이 수시로 발생하면서, AI가 결과를 내놓을 때마다 일어나는 컨텍스트 스위칭(Context Switching)으로 인해 집중력이 깨지고 오히려 피로감이 쌓이는 역설이다.

물론 이 시간을 모두가 무의미하게 가만히 기다리지는 않을 것이다. 누구는 AI가 작성하는 코드를 실시간으로 팔로우할 것이고, 또 누구는 다음에 진행할 다른 작업에 대해 고민하고 고뇌하는 시간으로 사용할 것이다.

2. AI가 코드를 짜는 동안, 우리는 무엇을 해야 하는가?

AI가 코드를 짜주는 동안 생기는 이 어중간한 시간을 우리는 어떻게 써야 할까?

사실 놀아도 된다. 머리를 식히며 재충전하는 시간으로 쓰는 것도 좋은 방법일 것이다.

하지만 이 공백 시간 동안 무엇을 해야 할지 몰라 답답함을 느끼는 분들을 위해, 소프트웨어 공학의 두 거장의 발언을 빌려 몇 가지 방향을 제안해 보고자 한다.

💬 켄트 벡 (Kent Beck, TDD 창시자) *"90% of my skills just went to zero dollars; 10% of my skills just went up 1000x."* (내 기술의 90%[단순 문법 작성 및 구현 스킬]는 가치가 0달러로 떨어졌지만, 나머지 10%[의도 정의, 테스트 설계, 아키텍처 비전]의 가치는 1,000배나 폭등했다.)

💬 마틴 파울러 (Martin Fowler, 리팩터링 및 아키텍처 거장) 그의 블로그(martinfowler.com) 칼럼 시리즈(Exploring Generative AI)를 통해 "AI가 코드를 대신 짜주는 시대일수록, 비결정론적인 AI 코드를 검증하기 위한 TDD와 구조화된 명세(Spec) 기반의 검증 작업이 그 어느 때보다 절대적이다"라고 강조한다.

3. 공백 시간을 채우는 3가지 제안

두 거장의 주장을 바탕으로, AI가 작동하는 공백 시간을 활용할 수 있는 3가지 개발 패턴을 제안한다.

1) 스펙 기반 개발 및 명세 정제 (Spec-Driven Development, SDD)

AI에게 코딩을 맡겨놓은 공백 시간 동안 모니터를 멍하니 바라보지 않고, 다음 구현할 기능의 명세서(Spec)와 에지 케이스(Edge Case)를 정교하게 작성하는 방식이다. 구현을 AI가 맡는 만큼, 의도와 요구사항을 명확히 정의할수록 결과물의 품질이 비약적으로 상승한다.

2) 컨텍스트 큐레이션 (Context Engineering & Governance)

프롬프트 하나하나에 집착하거나 복잡한 시스템에 연연하는 대신, AI가 깨끗한 환경에서 일할 수 있도록 정보 환경(Context)을 청소하고 정돈하는 방식이다. 프로젝트의 CLAUDE.md, 규칙 파일, 의존성 관계 및 컨텍스트 문서를 다듬는 데 공백을 활용한다.

3) 검증 중심 개발 및 딥 디프 리뷰 (Verification-First & Deep Diff Audit)

AI가 코드를 뚝딱 만들어내는 시간 동안 딴짓을 하지 않고, AI가 내놓은 결과물과 아키텍처를 검증하고 평가(Eval)하는 심층 코드 리뷰어로 동작하는 방식이다. AI가 짠 코드의 보안성, 테스트 통과 여부, 아키텍처 오염을 꼼꼼히 체크한다.

4. 우리는 '대체될 코더'인가, '주도적인 개발자'인가

그저 AI에게 무지성으로 *"해줘"라고 던져놓고 결과만 멍하니 기다리는 것은, 스스로가 *"AI에게 언제든 대체될 수 있는 단순 코더"**임을 증명하는 것과 다름없다.

우리는 이미 알고 있다. 아무리 AI 모델의 성능이 좋아지고 비약적인 생산성 향상을 가져다준다 해도, 개발자의 대체 불가능한 핵심 요소는 분명히 존재한다는 것을.

AI는 개발을 원활하게 도와주는 '도구'일 뿐이다. 언제나 개발의 주체는 우리 개발자라는 사실을 잊지 말자.

AWS 보안 소개

• 보안의 핵심 2대 필수 요소: 인증과 권한 부여

  • 인증 (Authentication)
    • 정의
      • 사용자 이름 및 암호 조합, MFA 등 자격 증명(Credentials)을 통해 시스템에 접속하려는 사용자 또는 엔터티의 신원(ID)을 입증하고 확인하는 검증 프로세스
    • 실제 사용 사례
      • 직원이 전용 자격 증명을 사용하여 회사 직원 포털 사이트에 접속 및 로그인함
  • 권한 부여 (Authorization)
    • 정의
      • 신원이 확인된 사용자가 시스템, 애플리케이션 또는 리소스 내에서 수행할 수 있는 특정 읽기/쓰기/수행 작업 범위 및 액세스 권한(Permissions)을 결정하는 통제 프로세스
    • 실제 사용 사례
      • 로그인한 직원이 포털 전체 데이터에 접근하지 못하고, 오직 본인에게 허용된 본인 전용 직원 레코드 영역에 한해서만 접근함
  • 데이터 프라이버시 및 보호에서의 중요성
    • 무단 액세스 및 오용 방지, 고객 신뢰 유지, 신원 도용 및 금융 사기 예방

• AWS 공동 책임 모델 (AWS Shared Responsibility Model)

  • 클라우드 보안의 핵심 원칙
    • 보안은 AWS와 고객 간의 상호 책임 분담 관계에 기반함
  • 고객의 책임: 클라우드 "내"의 보안 (Security IN the Cloud)
    • 정의/범위: 고객이 AWS 클라우드 내에 직접 생성, 배치, 구성, 저장하는 모든 데이터와 워크로드의 보안 관리
    • 구체적 책임 영역
      • 데이터, 시스템, 애플리케이션의 엔드투엔드 보안 관리 및 암호화 설정
      • AWS에 저장하거나 실행할 데이터 및 워크로드의 종류 결정
      • 워크로드 운영을 위해 사용할 AWS 서비스 및 리소스 구성 결정
      • 사용자 계정, 액세스 권한, IAM 정책 및 리소스 접근 제어 관리
  • AWS의 책임: 클라우드 "자체"의 보안 (Security OF the Cloud)
    • 정의/범위: AWS가 인프라의 모든 하부 계층에서 서비스를 운영, 관리, 제어하고 보호하는 전반적인 물리 및 소프트웨어 보안
    • 구체적 책임 영역
      • AWS 서비스를 지원하는 컴퓨팅, 데이터베이스, 스토리지 기본 소프트웨어 및 런타임 관리
      • 가상화 계층 (Hypervisor / Virtualization Layer) 관리 및 격리
      • 서비스를 구동하는 데이터 센터의 물리적 하드웨어 및 글로벌 인프라 보안 (AWS 리전, 가용 영역 AZ, 엣지 로케이션의 물리적 보호)

• AWS 보안 제어 3대 모범 사례 원칙 (AWS Security Controls)

  • 보안 사고 예방 (Prevent): 적절한 권한 부여 및 아이덴티티/액세스 관리(IAM)를 통한 무단 인시던트 사전 차단
  • 다층 보호 (Protect): 네트워크, 애플리케이션, 데이터 전반에 대한 다중 암호화 및 다층 경계 보호막 구축
  • 탐지 및 신속 대응 (Detect & Respond): 보안 인시던트 발생 시 실시간 이상 징후 탐지 및 즉각 자동화 대응

• 인증 vs 권한 부여 및 AWS 공동 책임 모델 비교 요약표

AWS 보안 제어

무단 엑세스 차단

• AWS 보안 기본 통제 원칙

  • 기본 거부 (Default Deny)
    • IAM 사용자를 새로 생성하면 기본적으로 모든 API 호출 및 AWS 리소스 작업이 거부됨
    • 명시적으로 권한을 허용(Allow)하지 않는 한 계정 내에서 어떤 리소스(EC2, S3 버킷 등)도 생성하거나 조회할 수 없음
  • 최소 권한의 원칙 (Principle of Least Privilege)
    • 사용자, 시스템, 애플리케이션에 해당 업무를 수행하는 데 꼭 필요한 최소한의 명시적 액세스 권한만 제공하고, 나머지 모든 권한은 차단하는 핵심 보안 모범 사례

• IAM 핵심 자격 증명 5가지 (IAM Identities & Controls)

  • 1. AWS 계정 루트 사용자 (AWS Account Root User)
    • 정의: AWS 계정 생성 시 기본 제공되는 계정 소유자이자 최고 권한 자격 증명
    • 특징: 계정 내 모든 리소스 및 서비스에 대한 무제한 전체 접근 권한(Full Admin Access) 보유
    • 보안 모범 사례: 복합적이고 강력한 암호 설정, 2가지 이상의 확인 단계를 거치는 다중 인증(MFA) 필수 활성화, 일상 업무에는 사용하지 말고 IAM 사용자/역할을 별도 생성하여 활용
  • 2. IAM 사용자 (IAM User)
    • 정의: AWS 서비스 및 리소스와 지속적으로 상호 작용하는 사람(직원) 또는 애플리케이션에 대한 고유 자격 증명
    • 특징: 사용자 이름과 정적 자격 증명(비밀번호, Access Key)으로 구성되며, 사용자마다 개별 IAM 사용자를 생성하여 고유한 보안 자격 증명 세트를 갖도록 권장함
  • 3. IAM 그룹 (IAM Group)
    • 정의: 동일한 직무와 권한을 공유하는 IAM 사용자들의 집합체(Collection)
    • 특징: 그룹에 IAM 정책을 연결하면 그룹 내 모든 사용자가 해당 권한을 일괄 상속받음 (예: 개발팀, 재무팀 단위의 관리 효율화)
  • 4. IAM 역할 (IAM Role)
    • 정의: 정적 자격 증명(ID/비밀번호)이 없으며, 필요 시 임시로 권한을 수임(Assume)하여 사용하는 보안 자격 증명
    • 특징: 특정 역할을 수임하면 이전 역할의 권한을 포기하고 새 역할의 권한을 일시적으로 획득함. 사용자, 외부 자격 증명 연동(Federation), AWS 서비스 간 접근(예: EC2가 S3에 접근) 시 임시 위임 권한 부여에 활용
  • 5. IAM 정책 (IAM Policy)
    • 정의: AWS 서비스 및 리소스에 대한 액세스 권한(허용/거부)을 정의한 JSON 형식 문서
    • JSON 정책 구문의 3대 핵심 구성 요소:
      • Effect: 권한 허용 여부 (Allow 또는 Deny 2가지 옵션만 선택 가능)
      • Action: 허용하거나 거부할 특정 AWS API 호출 지정 (예: s3:ListBucket)
      • Resource: 해당 API 작업이 적용될 특정 AWS 리소스 ID/ARN 지정 (예: coffee_shop_report 버킷)

• 기업 규모 권한 연동 및 Single Sign-On 서비스

  • 자격 증명 연동 (Identity Federation)
    • 사내 기존 기업 계정 시스템(Active Directory 등)의 자격 증명을 IAM 역할에 매핑하여, 사용자가 개별 IAM 사용자 생성 없이 기존 회사 계정 정보로 AWS에 접속하는 방식
  • AWS IAM Identity Center
    • 정의: SSO(Single Sign-On) 설정을 지원하여 사용자가 단일 자격 증명으로 여러 AWS 계정 및 사내 애플리케이션 리소스에 간소화되어 안전하게 로그인하도록 관리하는 서비스

• IAM 5대 자격 증명 및 정책 요소 비교 요약표

AWS IAM 실습 데모 & 추가 액세스 관리 서비스

• IAM 실습 데모: IAM 사용자 생성, 그룹 추가 및 임시 역할 생성 절차

  • 1. IAM 사용자 생성 (john_doe)
    • IAM Dashboard -> Users -> Create user 선택
    • 사용자 고유 이름 john_doe 지정 및 AWS Management Console 접속 권한 부여 옵션 선택
  • 2. IAM 그룹 생성 (employees) 및 권한 정책 연결
    • 개별 사용자마다 정책을 일일이 매핑하는 것보다 그룹 단위 관리가 효율적임
    • Create Group -> 그룹 이름 employees 지정
    • 권한 정책 유형의 2가지 구분:
      • AWS 관리형 정책 (AWS Managed Policy): AWS에서 직접 생성 및 최적화하여 제공하는 표준 독립형 정책 (예: ViewOnlyAccess)
      • 고객 관리형 정책 (Customer Managed Policy): 세부적인 사용자 지정 통제를 위해 조직이 직접 작성 및 관리하는 커스텀 정책
    • employees 그룹에 AWS 관리형 정책 ViewOnlyAccess 연결 후 Create User Group 실행하여 사용자 john_doe를 그룹에 추가 (그룹의 모든 권한 자동 상속)
  • 3. 임시 IAM 역할 생성 (s3_read_only)
    • Roles -> Create Role -> Trusted Entity Type으로 AWS account 선택
    • 보안 강화를 위해 Require MFA (다중 인증 필수) 옵션 체크
    • 최소 액세스 권한 설정을 위해 S3 읽기 전용 정책(AmazonS3ReadOnlyAccess, AmazonS3TablesReadOnlyAccess) 검색 및 연결
    • Role Name으로 s3_read_only 입력 후 역할 생성 완료
    • 역할 수임 효과: 이 역할을 수임(Assume)한 사용자는 정적 자격 증명 없이 S3 버킷에 대한 임시 읽기 권한만을 위임받아 안전하게 작업 수행 가능

• 추가 보안 및 액세스 관리 서비스군 (Identity & Secrets Services)

  • AWS IAM Identity Center (페더레이션형 ID 및 SSO 관리)
    • 정의: 계정과 애플리케이션 전체의 자격 증명 및 액세스 관리를 중앙 집중화하고 Single Sign-On(SSO)을 지원하는 서비스
    • 핵심 개념 (페더레이션형 ID 관리, Federated ID Management): 직원이 사내 단일 자격 증명 세트(Active Directory 등) 하나로 여러 AWS 계정, 도메인, 외부 애플리케이션에 일괄 접속하도록 지원
  • AWS Secrets Manager (보안 암호 관리 및 자동 교체)
    • 정의: 데이터베이스 자격 증명(ID/비밀번호), API 키, 비공개 토큰 등 민감한 보안 암호(Secrets)를 전체 수명 주기 동안 암호화 관리, 자동 교체(Rotation) 및 안전하게 검색·조회하는 서비스
    • 보안 암호(Secrets)의 대상: 데이터베이스 접속 계정, OAuth API 키, 비공개 서명 토큰 등 기밀 유지 정보
  • AWS Systems Manager (하이브리드 노드 관리 및 패치 자동화)
    • 정의: AWS 리전, 계정, 멀티 클라우드 및 온프레미스 하이브리드 환경 전체에 존재하는 모든 노드(Node)에 대한 중앙 집중식 가시성을 제공하고 운영 관리를 자동화하는 서비스
    • 노드(Node)의 개념: 네트워크, 시스템 또는 인프라 구조 내에 접속된 개별 연결 지점(EC2 인스턴스, 온프레미스 서버 등)
    • 주요 기능: OS 세부 정보 및 자격 증명 신속 조회, 사용자 계정 관리, 레지스트리 편집, 자동 보안 패치 적용 지원

• 추가 액세스 관리 서비스 비교 요약표

네트워크 및 애플리케이션 보호

• 서비스 거부 공격의 개념 및 차이점

  • DoS (Denial of Service, 서비스 거부 공격)
    • 정의: 단일 공격자가 웹 애플리케이션에 과도한 네트워크 트래픽 및 소켓 요청을 전송하여 인프라 용량 과부하를 유발하는 공격
    • 결과: 웹 애플리케이션이 응답 불능 상태에 빠져 일반 정상 고객의 정당한 서비스 요청이 거부됨
  • DDoS (Distributed Denial of Service, 분산 서비스 거부 공격)
    • 정의: 인터넷상의 감염된 수많은 컴퓨터 시스템(일명 좀비 봇, Zombie Bots)을 악용하여 부지불식간에 대상 웹 애플리케이션으로 대규모 무차별 트래픽을 동시 발송하는 공격
    • UDP Flood 공격 사례: 국립 기상청 같은 정당한 인터넷 서비스에 가짜 요청(응답 반환 주소를 공격 대상 IP로 조작)을 발송하여 메가바이트 단위의 기상 데이터가 피해 서버의 네트워크 용량을 꽉 채워 마비시키는 무차별 대입 공격

• AWS 인프라 수준의 자동 방어 체계 (Infrastructure Protection)

  • 보안 그룹 (Security Groups)
    • 올바른 프로토콜 요청 트래픽만 선별 허용함 (UDP Flood 등 목록에 없는 프로토콜 사전 차단)
    • 개별 EC2 인스턴스 호스트 레벨이 아닌 AWS 네트워크 수준(VPC/가상화 경계)에서 운영되므로, 전체 AWS 리전의 막대한 용량을 활용해 대규모 공격을 일차적으로 흡수 및 무력화
  • Elastic Load Balancing (ELB)
    • 애플리케이션 진입점 역할을 수행하며, 트래픽을 프론트엔드 인스턴스로 전달하기 전에 먼저 수용 및 분산하므로 서버의 직접 과부하 방지 (리전 수준 실행)
  • AWS 리전 (AWS Region)
    • 전 세계에 분포된 여러 리전, 가용 영역(AZ), 엣지 로케이션의 메가급 인프라 용량을 바탕으로 단일 시스템에 과부하를 유발하기 어렵게 인프라가 설계됨

• 전용 네트워크 및 애플리케이션 보호 서비스

  • AWS Shield Standard
    • 정의: 가장 일반적으로 자주 발생하는 L3/L4 수준의 DDoS 공격으로부터 모든 AWS 고객 리소스를 추가 비용 없이 기본으로 자동 보호하는 서비스
    • 주요 특징: 실시간 분석 기술로 악성 네트워크 트래픽을 탐지 및 완화하며, Elastic Load Balancing, Amazon CloudFront, Amazon Route 53 등 주요 서비스에 기본 포함됨
  • AWS Shield Advanced
    • 정의: 대규모 및 정교한 DDoS 공격에 대비해 상세한 공격 진단 보고서 및 능동적 완화 기능을 제공하는 유료 프리미엄 서비스
    • 주요 특징: Amazon CloudFront, Amazon Route 53, ELB와 완벽 통합되며, 전담 DDoS 대응팀(DRT) 지원 제공
  • AWS WAF (Web Application Firewall)
    • 정의: 웹 애플리케이션으로 유입되는 Layer 7(HTTP/HTTPS) 네트워크 요청을 실시간 모니터링 및 필터링하는 웹 애플리케이션 방화벽
    • 주요 특징: 웹 액세스 제어 목록(Web ACL) 및 IP 규칙 세트와 수신 쿼리를 비교하여, 차단 목록의 IP 주소나 악성 서명 요청에 대해 즉각 액세스를 거부(Block)하고 정상 요청만 허용 (Allow)
    • ML 연동 방어: 기계 학습 기능을 갖추고 있어 변화하는 최신 위협 패턴을 스스로 인지하며, AWS Shield Advanced 및 CloudFront/ALB와 연동해 커스텀 방어 규칙 적용 가능

• AWS DDoS 방어 체계 및 보호 서비스 비교 요약표

데이터 보호

• 데이터 암호화의 기본 개념

  • 자물쇠와 열쇠(Key) 메커니즘: 올바른 암호화/암호 해독 키(Key)를 보유한 승인된 주체만 데이터를 인지 가능한 형태로 해독하여 액세스하도록 무작위 문자열로 변환하는 기술
  • 목적: 민감 개인정보(전화번호, 신용카드 정보 등) 유출 차단, 고객 신뢰 유지, 신원 도용 및 금융 사기 예방

• 암호화의 2가지 핵심 형태 (Data Status)

  • 저장 시 데이터 암호화 (Encryption at Rest)
    • 정의: 데이터가 유휴 상태(Idle)로 디스크나 데이터베이스 스토리지에 이동하지 않고 저장되어 있을 때의 보호 형태
    • 적용 예시: 데이터베이스 레코드, EBS 볼륨, S3 버킷 객체, 스냅샷 등
  • 전송 중 데이터 암호화 (Encryption in Transit)
    • 정의: 데이터가 소스에서 목적지로 네트워크를 통해 한 위치에서 다른 위치로 이동할 때의 보호 형태
    • 프로토콜 메커니즘: SSL (Secure Sockets Layer) 및 업데이트된 최신 TLS (Transport Layer Security) 프로토콜 사용
    • 인증서 기반 네트워크 보호: 웹 브라우저의 자물쇠 아이콘 및 HTTPS (Hypertext Transfer Protocol Secure) 표기를 통해 전송 중 민감 데이터 패킷 스니핑/탈취 사전 방지

• AWS 스토리지 내장 데이터 보호 기능 (Built-in Data Protection)

  • Amazon S3
    • 기본적으로 모든 새 S3 버킷에 암호화가 자동 구성되어 있으며, 버킷에 업로드되는 모든 새 객체는 저장 시 자동으로 서버 측 암호화됨
  • Amazon EBS
    • EC2 인스턴스의 부팅(Boot) 볼륨 및 데이터(Data) 볼륨, EBS 스냅샷에 대해 저장 시 암호화 적용 가능
  • Amazon DynamoDB
    • AWS KMS 키를 활용하여 모든 DynamoDB 테이블 데이터에 대해 서버 측 저장 시 암호화(SSE)가 기본 활성화됨

• 전용 AWS 데이터 보호 서비스군 (AWS Data Protection Services)

  • AWS Key Management Service (AWS KMS)
    • 정의: 광범위한 AWS 서비스 및 애플리케이션 전반에서 데이터 암호화에 사용되는 암호화 키를 생성하고 관리하는 완전관리형 키 관리 서비스
    • 주요 특징: 임의의 숫자 문자열 형태인 암호화 키는 AWS KMS 외부로 절대 유출되거나 이탈하지 않음. IAM 사용자/역할을 통해 키 관리 액세스 권한을 제어하며, 필요 시 키를 일시 비활성화(Disable) 가능
  • Amazon Macie (ML 기반 S3 민감 데이터 검색)
    • 정의: 기계 학습(ML) 및 패턴 인식 자동화를 활용해 Amazon S3 버킷에 저장된 민감 정보(개인식별정보 PII, 금융 정보 등)를 모니터링하고 자동 발견하는 보안 서비스
    • 주요 특징: 저장된 민감 데이터의 보안 태세 평가 및 규정 준수(Compliance) 요건 충족에 유용함
  • AWS Certificate Manager (ACM)
    • 정의: 전송 중 데이터 암호화를 제공하는 SSL/TLS 디지털 인증서의 발급, 프로비저닝, 갱신 및 관리를 중앙 집중화하는 서비스
    • 주요 특징: AWS 서비스(Amazon CloudFront, Elastic Load Balancing 등) 및 연동된 온프레미스 리소스에 HTTPS/TLS 인증서를 적용하여 네트워크 통신 보안 확보

• AWS 데이터 암호화 형태 및 보호 서비스 비교 요약표

보안 인시던트 탐지 및 대응

• 보안 인시던트 탐지 및 대응의 목적

  • 예방과 경계 보호 조치를 넘어서, 시스템 취약성 및 실시간 지능형 위협이 발생했을 때 이를 지속 탐지하고 근본 원인을 분석하여 문제 해결 시간(TTR, Time to Resolve)을 대폭 단축함

• 4대 보안 탐지 및 대응 전용 서비스

  • Amazon Inspector (자동화된 취약성 및 규정 준수 평가)
    • 정의: Amazon EC2 인스턴스, 컨테이너(ECR), AWS Lambda 함수에 대한 자동 보안 평가를 실행하여 애플리케이션의 보안 및 규정 준수를 개선하는 평가 서비스
    • 주요 검사 항목: EC2 인스턴스 오픈 액세스 노출, 취약한 패치/소프트웨어 버전 설치, 보안 모범 사례 위반 여부 자동 스캔
    • 평가 결과 제공: 심각도(Severity) 수준에 따라 우선순위가 지정된 보안 결과(Findings) 목록 제공, 식별된 이슈에 대한 자세한 설명 및 해결 권장 사항 포함 (API를 통한 결과 검색 가능)
  • Amazon GuardDuty (지능형 위협 탐지 및 실시간 모니터링)
    • 정의: AWS 계정, 메타데이터, 네트워크 활동의 지속적 스트림 모니터링을 통해 인프라 및 리소스 전체에서 지능형 위협 탐지(Threat Detection)를 제공하는 서비스
    • 분석 메커니즘: 알려진 악성 IP 주소 목록(위협 인텔리전스), 이상 탐지(Anomaly Detection), 기계 학습(ML)을 통합 활용하여 정확하게 위협 식별
    • 탐지 결과 및 자동 대응: 위협 세부 결과 및 해결 권장 단계 제공, AWS Lambda 함수와 연동하여 문제 해결 단계를 자동 수행하도록 구성 가능
  • Amazon Detective (위협 조사를 위한 근본 원인 시각화 분석)
    • 정의: 탐지된 보안 위협의 근본 원인(Root Cause)을 신속히 파악할 수 있도록 AWS 계정 전반의 조사 프로세스를 간소화하고 자동화하는 보안 분석 서비스
    • 분석 메커니즘: AWS 리소스에서 로그 데이터를 자동 수집 후, 기계 학습(ML) 및 그래프 분석(Graph Analysis)을 적용해 대화형 시각화 자료 구축
    • 시각화 이점: 구성 가능한 타임라인 동안 리소스 및 사용자 간의 상호 작용을 대화형 그래프 보기를 통해 통합 제공하여 빠른 위협 분석 지원
  • AWS Security Hub (중앙 집중식 보안 및 규정 준수 통합 대시보드)
    • 정의: 다양한 AWS 보안 서비스(GuardDuty, Inspector, Macie 등) 및 파트너 서비스의 보안 결과를 단일 위치와 표준 형식으로 자동 집계 및 통합 관리하는 서비스
    • 주요 특징: 보안 결과를 '인사이트(Insights)'라는 실행 가능한 의미 있는 그룹화로 자동 정리, 보안 및 규정 준수(Compliance) 상태를 하나의 종합 보기로 확인, 자동화된 대응으로 문제 해결 시간(TTR) 대폭 단축

• AWS 4대 보안 탐지 & 대응 서비스 통합 비교 요약표

AWS Marketplace 보안 리소스 (AWS Marketplace Security Solutions)

• AWS Marketplace 서드파티 보안 카테고리

  • 정의: AWS 인프라 상에서 실행되는 독립 소프트웨어 벤더(ISV)의 서드파티(Third-party) 보안 소프트웨어 및 서비스를 검색하고 바로 구매·배치할 수 있는 온라인 디지털 카탈로그

• Marketplace 4대 서드파티 보안 솔루션 카테고리

  • 1. 위협 탐지 및 예방 도구 (Threat Detection & Prevention Tools)
    • 기능: 시스템 및 네트워크 전반의 악의적인 활동, 맬웨어, 비정상 패턴을 탐지하고 실시간 차단
  • 2. 자격 증명 및 액세스 관리 도구 (Identity & Access Management Tools)
    • 기능: 사용자 세부 권한, 세분화된 인증 및 접근 자격 증명을 외부 IDP 연동과 함께 고도로 제어
  • 3. 데이터 보호 도구 (Data Protection Tools)
    • 기능: 민감 정보(PII, 카드정보 등)를 암호화, 토큰화, 유출 방지(DLP)를 통해 안전하게 다층 보호
  • 4. 규정 준수 및 거버넌스 도구 (Compliance & Governance Tools)
    • 기능: 다양한 산업/컴플라이언스 보안 규정 요구 사항(ISO, SOC, PCI-DSS 등) 충족 여부를 자동 검증하고 관리

• AWS 공식 보안 리소스 vs AWS Marketplace 서드파티 카테고리 비교 요약표

AI 및 기계 학습 소개

• 인공 지능(AI)과 기계 학습(ML)의 개념 체계

  • 인공 지능 (Artificial Intelligence, AI)
    • 정의
      • 인간의 지적 능력(인간과 유사한 태스크 수행)을 시뮬레이션하고 구현하는 지능형 컴퓨터 시스템 개발에 중점을 둔 광범위한 학문 및 기술 분야
    • 특징/이점
      • 단순 규칙 이행을 넘어 구체적인 맥락 이해, 이미지 인식, 자연어 처리, 의사결정 등 인간 수준의 작업을 수행함
  • 기계 학습 (Machine Learning, ML)
    • 정의
      • 명시적인 프로그래밍 명령을 일일이 작성하지 않아도, 방대한 데이터로부터 학습하여 복잡한 태스크를 스스로 수행하도록 시스템을 훈련하는 AI의 하위 분야
    • 특징/이점
      • 과거 데이터에 숨겨진 복잡한 패턴을 발견하여 새로운 상황에 대한 예측 및 조치를 스스로 도출함

• 기존 프로그래밍 방식 vs 기계 학습(ML) 방식 비교

  • 기존 프로그래밍 (Rule-based Programming)
    • 작동 메커니즘: 개발자가 사전 정의된 고정 규칙(If-Then) 및 정적 관계를 명시적으로 코딩함
    • 예시 (커피숍 주문 시스템): "캐러멜 라떼 구매 이력 고객 -> 덴마크 치즈 추천" 규칙을 하드코딩함
    • 한계: 개별 고객의 성향이나 상황 변화, 제품 특성을 유연하게 반영하지 못함
  • 기계 학습 (ML-based Pattern Recognition)
    • 작동 메커니즘: 방대한 수의 과거 판매 및 고객 반응 데이터를 분석하여 숨겨진 패턴을 추출하고 모델을 생성함
    • 예시: 명시적 규칙 없이도 고객의 구체적 구매 패턴과 취향을 종합 판단하여 정교하고 개인화된 음식/메뉴를 자동 추천함
    • 이점: 고객 만족도 향상 및 매출 증대를 동시에 달성 (고객과 매장의 윈윈 효과)

• 기계 학습(ML)의 핵심 동작 메커니즘

  • 훈련 (Training)
    • 방대한 과거 데이터(판매 기록, 소셜 미디어 게시물, 센서 측정값, 고객 피드백 등)를 입력하여 데이터 내 숨겨진 패턴과 상관관계를 찾아내고 ML 모델을 생성하는 과정
  • 추론 (Inference)
    • 훈련된 ML 모델에 새로운 데이터(실시간 고객 입력 등)를 적용하여 학습한 패턴을 바탕으로 예측이나 최종 결정을 내리는 과정

• 비즈니스 혁신을 위한 AI/ML 주요 사용 사례

  • 개인화 추천 엔진 (Personalization Engine)
    • 고객별 개별 취향과 행동 양식을 반영한 실시간 맞춤형 상품 추천 (커피-음식 조합 등)
  • 대화형 AI 키오스크 (자연어 처리, NLP 기반)
    • 자연어 처리(NLP)를 통해 고객의 음성 주문을 실시간 이해하고 결제 시스템에 입력
    • 고정 규칙이 아닌 실시간 대화 흐름에 맞춰 에스프레소 샷 추가나 시즌 신메뉴 제안 등 능동적 질문 수행
  • 소셜 미디어 트렌드 분석 및 미래 수요 예측
    • 현지 소셜 미디어 트렌드 데이터와 과거 판매 실적 데이터를 결합 분석
    • 다음 주 인기 음료 예측, 신메뉴 레시피 아이디어 자동 생성, 원두 구매량 및 미래 매장 수요 예측

• AWS의 AI/ML 서비스 생태계 및 데이터의 중요성

  • AWS AI/ML 서비스 채택 이점
    • 처음부터 인프라와 알고리즘을 구축하는 시간/비용을 절감하고, 온디맨드 방식으로 AI를 신속 도입 가능
    • Amazon SageMaker AI: 맞춤형 ML 모델의 생성, 훈련, 배포를 종합 지원하는 완전관리형 도구
    • 사전 구축된 AI 서비스 (Pre-built AI Services): 언어 번역, 이미지 인식 등 일반적인 태스크를 위한 즉시 활용 가능한 서비스 제공
  • 올바른 데이터 수집 및 정제의 필수성
    • AI/ML 모델은 판매 기록, 소셜 미디어, 센서 데이터 등 다양한 출처의 훈련 데이터에 의존함
    • 데이터 수집, 정제(Cleaning), 가공 프로세스가 미흡할 경우 AI 예측 정확도가 보장될 수 없으므로 체계적인 데이터 관리가 필수적임

• 기존 프로그래밍 vs 기계 학습(ML) 비교 요약표

AWS 기반 AI/ML

AWS 기반 ai/ml

• 산업계에서의 다양한 ML 비즈니스 해결 과제

  • 전자 상거래 및 운영 최적화
    • Amazon.com의 개인화 추천 엔진 구축 및 물류 주문 처리 센터(Fulfillment Center) 작업 최적화
  • 추세 예측 (Trend Prediction)
    • 주식 시장 동향 파악, 미래 주가 예측, 원자재 및 상품 가격 변동성 추정
  • 지능형 의사결정 및 자동 라우팅 (Automated Decision Making)
    • 콜센터 대화형 음성 프롬프트(IVR) 요청을 분석하여 발신 고객을 최적 부서로 자동 라우팅
  • 이상 현상 탐지 (Anomaly Detection)
    • 온라인 뱅킹 및 금융 거래 시스템에서 부정 결제, 이상 거래, 사기 행위(Fraud) 실시간 감지

• AWS AI/ML 3-티어 솔루션 스택 (3-Tier Stack)

  • 티어 1: AI 서비스 (AWS AI Services)
    • 정의
      • 개발자가 기계 학습 전문 지식 없이도 API 호출만으로 특정 비즈니스 기능을 즉시 사용할 수 있도록 사전 훈련(Pre-trained)되어 제공되는 완전관리형 서비스 계층
    • 대표 서비스 및 특징
      • Amazon Polly: 텍스트를 자연스러운 음성으로 변환 (Text-to-Speech)
      • Amazon Comprehend: 텍스트 문맥 분석, 키워드 추출 및 감정 분석 (Sentiment Analysis)
  • 티어 2: ML 서비스 (AWS ML Services)
    • 정의
      • 기업 고유의 비즈니스 데이터를 기반으로 맞춤형 ML 모델을 직접 제작할 때 사용하는 완전관리형 플랫폼 계층
    • 대표 서비스: Amazon SageMaker AI
      • 완전관리형 인프라, 도구, 워크플로를 제공하여 자체 ML 모델을 구축(Build), 훈련(Train), 배포(Deploy)함
      • 단일 통합 환경 내에서 모델 훈련 실험 추적, 데이터 시각화, 모델 디버깅 및 모니터링을 포괄적으로 수행
  • 티어 3: ML 프레임워크 및 인프라 (ML Frameworks & Infrastructure)
    • 정의
      • 고도로 전문화된 딥러닝/ML 솔루션 구축을 위해 널리 사용되는 오픈소스 프레임워크와 목적별 하드웨어를 직접 제어하는 딥 커스텀 계층
    • 주요 구성 요소
      • 널리 사용되는 ML 프레임워크 (PyTorch, TensorFlow 등)와 통합되는 목적별 가속 칩셋 (Purpose-built Chips) 활용
      • ML 워크로드에 특화된 전용 Amazon EC2 가속 인스턴스 환경에서 모델 호스팅 및 훈련 수행

• AWS AI/ML 3-티어 솔루션 스택 비교 요약표

AWS AI/ML 솔루션 (3-Tier 상세)

• 티어 1: 사전 구축된 AWS AI 서비스 (Pre-built AI Services)

  • 언어 서비스 (Language Services)
    • Amazon Comprehend
      • 정의: 자연어 처리(NLP)를 사용하여 문서 내 핵심 문구, 언어, 감정(Sentiment) 등 핵심 인사이트를 자동 추출하는 서비스
      • 주요 사용 사례: 콘텐츠 자동 분류, 고객 감정 분석, 규정 준수(Compliance) 모니터링
    • Amazon Polly
      • 정의: 텍스트를 실제와 같은 다국어, 다양한 성별 및 억양의 자연스러운 음성으로 변환(Text-to-Speech, TTS)하는 서비스
      • 주요 사용 사례: 시각 장애인을 위한 가상 어시스턴트, e-러닝 애플리케이션, 음성 접근성(Accessibility) 개선
    • Amazon Transcribe
      • 정의: 음성을 다국어 텍스트로 자동 변환(Speech-to-Text, STT)하며, 화자 식별, 사용자 지정 어휘, 실시간 트랜스크립션을 제공하는 서비스
      • 주요 사용 사례: 고객 콜센터 통화 내용 트랜스크립션, 비디오 자동 자막 생성, 미디어 콘텐츠용 메타데이터 추출
    • Amazon Translate
      • 정의: 여러 언어 간의 실시간 및 배치(Batch) 텍스트 번역을 지원하는 신경망 기계 번역 서비스
      • 주요 사용 사례: 다국어 문서 번역, 글로벌 애플리케이션 다국어 연동
  • 컴퓨터 비전 및 검색 서비스 (Computer Vision & Search Services)
    • Amazon Kendra
      • 정의: 자연어 처리(NLP)를 사용하여 대량의 엔터프라이즈 콘텐츠 내에서 쿼리 문맥을 이해하고 정확한 답변을 도출하는 지능형 검색 서비스
      • 주요 사용 사례: 사내 지식 기반 지능형 검색, 챗봇 검색 연동, 애플리케이션 내부 검색 통합
    • Amazon Rekognition
      • 정의: Amazon S3에 저장된 이미지 및 동영상 내의 물체, 사람, 텍스트, 장면, 활동을 식별 및 분석하는 컴퓨터 비전 서비스
      • 주요 사용 사례: 부적절한 콘텐츠 자동 조정(Moderation), 사용자 자격 증명/얼굴 확인, 미디어 분석, 홈 오토메이션
    • Amazon Textract
      • 정의: 단순 OCR을 넘어 문서, 양식, 표(Table) 내의 타이핑 텍스트 및 손글씨(Handwriting) 텍스트를 자동 감지하고 추출하는 서비스
      • 주요 사용 사례: 금융, 의료, 정부 기관의 각종 문서/서식/양식 텍스트 자동 추출 및 프로세스 신속화
  • 대화형 AI 및 개인화 서비스 (Conversational AI & Personalization Services)
    • Amazon Lex
      • 정의: 자연어 이해(NLU) 및 자동 음성 인식(ASR) 기술을 활용해 음성 및 텍스트 대화형 인터페이스(챗봇)를 구축하는 서비스
      • 주요 사용 사례: 가상 어시스턴트, FAQ 자연어 검색, 애플리케이션 대화형 봇
    • Amazon Personalize
      • 정의: 과거 사용자 행동 데이터를 기반으로 고객 맞춤형 권장 사항(추천)을 제공하는 지능형 추천 엔진 서비스
      • 주요 사용 사례: 맞춤형 미디어 스트리밍 추천, 전자 상거래 제품 추천, 실시간 인기 상승 항목 추천

• 티어 2: ML 서비스 (Amazon SageMaker AI)

  • Amazon SageMaker AI의 개념
    • 인프라 관리 부담 없이 자체 ML 모델을 구축(Build), 훈련(Train), 배포(Deploy)할 수 있도록 단일 IDE 및 사전 훈련된 수백 개의 모델을 제공하는 완전관리형 ML 플랫폼
  • SageMaker AI의 3대 핵심 이점
    • 다양한 ML 도구 선택 (Flexible Tools): 데이터 사이언티스트용 IDE부터 비즈니스 분석가용 노코드(No-Code) 인터페이스까지 다양한 페르소나별 도구 제공
    • 완전관리형 인프라 (Fully Managed Infrastructure): 비용 효율적이고 고성능 인프라를 AWS가 자동 분산 관리하여 개발자가 모델 개발에만 집중하도록 지원
    • 반복 가능한 ML 워크플로 (Repeatable MLOps): 전사적 MLOps 관행 및 거버넌스를 자동화·표준화하여 시스템 투명성과 감사(Audit) 기능을 제공

• 티어 3: ML 프레임워크 및 인프라 (Frameworks & Infrastructure)

  • 개요
    • ML 훈련 프로세스를 완전하게 제어해야 하는 고도의 기술적 조직을 위한 딥 커스텀 하드웨어 및 소프트웨어 계층
  • 핵심 구성 요소
    • ML 프레임워크 (ML Frameworks): PyTorch, Apache MXNet, TensorFlow 등 사전 구축 및 최적화된 딥러닝 라이브러리 및 도구 전면 지원
    • AWS ML 인프라 (ML Infrastructure): ML에 최적화된 Amazon EC2 가속 인스턴스(GPU/전용 칩셋), Amazon EMR, Amazon ECS 등 고성능·고유연성 워크로드 환경 제공

• 티어 1 사전 구축 AWS AI 서비스 요약표

AWS 기반 생성형 AI 소개

• AI - ML - 딥러닝 - 생성형 AI 계층 구조
  • 딥러닝 (Deep Learning, DL)
    • 정의
      • 인간의 뇌 신경망을 모방한 인공 뉴런(수학적 함수 계층)을 사용하여 다차원 정보 및 복잡한 패턴을 훈련하는 기계 학습(ML)의 하위 분야
    • 특징/이점
      • 인공 뉴런의 각 계층이 이전 계층의 정보를 요약·전달하는 방식으로 컴퓨터 비전, 자연어 처리(NLP) 등 고도의 복잡한 문제를 해결함
  • 생성형 AI (Generative AI)
    • 정의
      • 사전 훈련된 초대형 파운데이션 모델(FM)을 기반으로 대화, 스토리, 이미지, 동영상, 음악, 코드 등 새로운 콘텐츠와 아이디어를 창작하는 딥러닝의 고도화된 한 종류
    • 핵심 기반: 파운데이션 모델 (Foundation Models, FM)
      • 방대한 데이터 컬렉션을 활용해 사전 훈련된 초대형 기계 학습 모델
      • 단일 태스크만 수행하는 기존 ML 모델과 달리, 하나의 사전 훈련된 FM으로 여러 다중 태스크(Multi-Task)를 유연하게 수행할 수 있음
    • 대규모 언어 모델 (Large Language Models, LLM)
      • 인간의 언어 작동 원리를 학습하기 위해 방대한 양의 텍스트 데이터로 훈련된 대표적인 파운데이션 모델 유형

AWS 생성형 AI 솔루션

• Amazon SageMaker JumpStart

  • 정의
    • 컴퓨터 비전, NLP, 테이블 형식 데이터 등 다양한 영역의 사전 구축 ML 솔루션 라이브러리를 보유하여 모델 구축, 훈련, 배포 프로세스를 신속 가속화하는 SageMaker AI 내 기계 학습 허브
  • 핵심 기능 및 특징
    • 클릭 몇 번만으로 사전 훈련된 모델을 즉시 배포할 수 있으며, 분야별 자체 데이터를 활용해 특정 사용 사례에 맞게 모델을 미세 조정(Fine-Tuning) 가능함
  • 일반적인 3대 사용 사례
    • 신속한 ML 모델 배포 (Fast Model Deployment): 깊은 ML 전문 지식이 없어도 사전 훈련된 모델을 즉시 신속하게 배포함
    • 미세 조정된 사용자 지정 솔루션 (Fine-Tuned Customization): 도메인 특화 데이터를 활용해 사전 훈련된 파운데이션 모델(FM)을 미세 조정함
    • ML 실험 및 프로토타입 (ML Experiments & Prototypes): 특정 솔루션 접근 방식을 결정하기 전 여러 파운데이션 모델의 성능을 상호 비교·검증함

• Amazon Bedrock

  • 정의
    • 인프라 관리 없이 단일 통합 API를 통해 Amazon 자체 FM 및 주요 AI 스타트업(Claude, Stable Diffusion 등)의 고성능 파운데이션 모델에 액세스할 수 있도록 설계된 완전관리형 서비스
  • 핵심 기능 및 특징
    • FM 모델들을 신속하게 실험하고, 비공개(Private) 데이터로 안전하게 미세 조정하여 AWS 애플리케이션에 원활하게 통합할 수 있음
  • 일반적인 3대 사용 사례
    • 엔터프라이즈급 생성형 AI (Enterprise-Grade GenAI): 엔터프라이즈급 보안, 개인정보 보호 기능, 높은 확장성을 바탕으로 프로덕션에 즉시 사용할 수 있는 생성형 AI 앱 구축
    • 다중 모달 콘텐츠 생성 (Multimodal Content Generation): 텍스트 및 이미지 등 여러 가지 미디어 콘텐츠 유형을 동시에 창작할 수 있는 애플리케이션 개발
    • 고급 대화형 AI (Advanced Conversational AI): 기업 사내 데이터 리포지토리에 연결하여 높은 정확도의 답변을 제공하는 지능형 대화 에이전트 개발

• Amazon Q 제품군 (Amazon Q Business & Developer)

  • 정의
    • 기업의 비즈니스 프로세스를 간소화하고 의사 결정을 가속화하며 직원의 업무 생산성을 획기적으로 향상시키는 대화형 생성형 AI 어시스턴트
  • Amazon Q Business
    • 정의: 회사의 내부 정보 리포지토리 및 공통 시스템에 대한 보안 연결을 통해 긴급한 질의에 답변하고 업무 조치를 수행하는 비즈니스 어시스턴트
    • 주요 사용 사례: 사내 정보 요청 답변, 자동화된 워크플로 실행, 내부 인사이트 추출 및 보고서 생성
  • Amazon Q Developer
    • 정의: C#, Java, JavaScript, Python, TypeScript 등 다양한 코딩 언어로 개발을 가속화할 수 있도록 전체 함수 및 논리적 코드 블록 단위 추천 코드를 생성하는 전문 개발 어시스턴트
    • 주요 사용 사례: 코드 생성 속도 향상, 코드 수명 주기 내 안정성 및 보안성 강화, 자동화된 코드 검토(Code Review) 수행

• AWS 생성형 AI 주요 솔루션 비교 요약표

데이터 분석

데이터 분석 소개

• 전통적 데이터 분석 (Data Analytics)의 개념 및 필요성

  • 정의
    • 분석가가 원시 과거(Historical) 데이터를 수집, 변환, 처리하여 의사 결정에 필요한 중요한 인사이트와 추세를 도출해 내는 전통적 분석 과정
  • AI/ML과의 관계 및 차이점
    • 공통점: AI/ML과 전통적 데이터 분석 모두 정제되고 액세스 가능한 대용량 데이터를 필수 기반으로 사용함
    • 소규모 데이터세트에서의 경제성: 데이터 규모가 소형인 경우 데이터 분석 방식이 AI/ML 모델 구축에 비해 비용과 처리 속도 측면에서 훨씬 효율적이고 경제적임
    • 설명 가능성(Explainability) 및 정밀성: 규제 기관 승인이나 통계적 가설 검증 등 판단 근거를 논리적으로 명확히 입증해야 하는 영역에서 필수적임
  • 대표적인 실제 사용 사례 (3가지)
    • 금융 분야 대출 심사 설명: 대출 회사가 고객에게 대출/융자 결정의 판단 이유를 투명하게 설명
    • 의학 연구 임상시험 분석: 의학 연구자가 가설 검증(Hypothesis Testing) 등 전통 통계 방법으로 임상 시험 데이터 분석
    • 보험사 위험 평가 모델 투명성 확보: 규제 기관의 요건을 충족하고 승인을 얻기 위해 위험 평가(Risk Assessment) 모델의 정당성 증명

• 데이터 통합 저장소 및 파이프라인 개념

  • 데이터 레이크 (Data Lake)
    • 정의: 기업 내 다양한 시스템과 형식을 가진 모든 정형/비정형 원시(Raw) 데이터를 단일 위치에 대규모로 통합 적재하는 거대한 중앙 저장소 (예: Amazon S3)
  • ETL / ELT 파이프라인 (Data Pipeline)
    • 정의: 여러 출처에 흩어져 있는 데이터를 수집, 변환, 로드하여 분석 도구 및 AI 알고리즘이 소비할 수 있는 형태로 자동 처리하는 조립 라인(Assembly Line) 성격의 파이프라인
    • ETL (Extract - Transform - Load)
      • 1. 추출 (Extract): 다양한 소스 시스템에서 원시 데이터 수집
      • 2. 변환 (Transform): 다운스트림 분석 도구가 사용할 수 있는 일관된 형태로 정제 및 가공
      • 3. 로드 (Load): 데이터 웨어하우스(Amazon Redshift)나 분석 플랫폼 대상 시스템에 적재
    • ELT (Extract - Load - Transform)
      • 원시 데이터를 먼저 대상 시스템에 수집 및 로드(Load)한 후, 필요에 따라 다운스트림에서 변환(Transform)하는 방식
    • ETL 불필요 (Zero-ETL) 환경: 데이터가 이미 사용 가능한 일관된 표준 형식으로 대상 위치에 존재하는 경우 변환 과정 없이 즉시 활용

• AWS 데이터 분석 서비스 통합 생태계 (Data Analytics Ecosystem)

  • 데이터 파이프라인 단계별 핵심 서비스군
    • 데이터 수집 (Ingestion): Amazon Kinesis, AWS Glue
    • 스토리지 & 데이터 레이크 (Storage & Data Lake): Amazon S3 (데이터 레이크), Amazon Redshift (데이터 웨어하우스)
    • 데이터 처리 및 연산 (Processing): Amazon EMR (대규모 분산 클러스터 처리)
    • 시각화 및 비즈니스 인텔리전스 (Visualization & BI): Amazon QuickSight
  • 동일 데이터세트 기반의 다중 팀 활용 사례 (Single Dataset, Multiple Uses)
    • Amazon S3 데이터 레이크에 원시 데이터세트를 통합 수집한 후:
      • 마케팅/경영진 팀: Amazon QuickSight를 통해 비즈니스 인텔리전스(BI) 대시보드 시각화 및 인사이트 분석 수행
      • 데이터 사이언스 팀: Amazon SageMaker AI를 통해 동일한 S3 데이터세트를 직접 참조하여 ML 모델 훈련 수행

• ETL 파이프라인 방식 및 AWS 데이터 분석 서비스 요약표

AWS 기반 데이터 파이프라인

• 데이터 파이프라인 (Data Pipeline)의 개념 및 목적

  • 정의
    • 데이터 소스에서 대상 스토리지 및 분석 시스템으로 데이터를 수집, 카탈로그화, 변환, 전달하는 전 과정을 자동화하는 데이터 조립 라인(Assembly Line)
  • 핵심 이점
    • 프로세스 간소화를 통해 수동 데이터 처리 개입을 최소화하고 데이터 오류 발생율을 절감함

• 데이터 파이프라인 5단계 아키텍처 및 핵심 AWS 서비스군

  • 1단계: 데이터 수집 서비스 (Data Ingestion)
    • 수집 방식 구분: 지연시간 없는 즉시 처리를 위한 실시간 수집 vs 지연시간이 허용되는 정기 지연 처리를 위한 배치 수집
    • Amazon Kinesis Data Streams
      • 정의: 애플리케이션, 센서, 라이브 스트림에서 테라바이트(TB) 규모의 데이터를 실시간으로 수집하는 서버리스 스트리밍 서비스
      • 주요 특징: 자동 프로비저닝 및 오토스케일링 지원, 다수의 애플리케이션이 동일 스트림 데이터를 동시에 소비 가능 (예: 금융사의 실시간 주식 시장 시세 수집 및 즉각 거래 판단)
    • Amazon Data Firehose
      • 정의: 수집된 스트리밍 데이터를 몇 초 내(Near Real-time)로 데이터 레이크, 데이터 웨어하우스, 분석 서비스로 자동 로드하는 완전관리형 스트리밍 ETL 서비스
      • 주요 특징: 데이터 캡처 후 목적지 자동 로드 (예: IoT 스마트 홈 디바이스 로그 수집 및 장기 보관용 데이터 레이크 적재)
  • 2단계: 데이터 스토리지 서비스 (Data Storage)
    • Amazon S3 (Data Lake)
      • 정의: 방대한 양의 정형/비정형 원시 데이터를 거의 무제한으로 유연하게 저장할 수 있는 표준 객체 스토리지 데이터 레이크 솔루션
      • 주요 특징: 데이터 증감에 따라 크기가 자동 조정되는 높은 탄력성과 데이터 유연성 제공
    • Amazon Redshift (Data Warehouse)
      • 정의: 페타바이트(PB) 규모의 정형 및 반정형 데이터를 저장하고 비즈니스 인텔리전스(BI)에 최적화된 완전관리형 데이터 웨어하우스
      • 주요 특징: 열 형식(Columnar) 스토리지 및 대규모 병렬 처리(MPP) 지원, 비용 효율적 종량제 쿼리 분석 수행
  • 3단계: 데이터 카탈로그화 서비스 (Data Cataloging)
    • 메타데이터 관리의 필요성: 데이터의 찍힌 장소/시간 정보처럼 조직 데이터세트에 대한 메타데이터 인벤토리를 생성하여 데이터 탐색 효율화
    • AWS Glue 데이터 카탈로그 (AWS Glue Data Catalog)
      • 정의: 확장 가능한 중앙 집중식 관리형 메타데이터 리포지토리
      • 주요 특징: 다양한 데이터 스토어 및 분석 서비스 간 메타데이터를 전달하고 중앙 관제하여 파이프라인 검색 성능 향상
  • 4단계: 데이터 처리 및 변환 서비스 (Data Processing)
    • AWS Glue
      • 정의: 데이터 분석을 바로 시작할 수 있도록 데이터를 정제 및 변환하는 완전관리형 서버리스 ETL 서비스
      • 주요 특징: Visual ETL 작업 생성, 코드 없이 스크립트 작성(No-Code), Glue 데이터 카탈로그 연동 메타데이터 기반 자동 변환 지원
    • Amazon EMR
      • 정의: Apache Spark, Apache Hadoop, Apache Hive 등 널리 사용되는 오픈소스 빅데이터 프레임워크를 활용하는 대규모 분산 데이터 처리 서비스
      • 주요 특징: 인프라 프로비저닝, 클러스터 관리, 오토스케일링을 자동 처리하며, 빅데이터 전문 지식과 사용자 지정 커스텀 구성이 필요한 조직에 적합
  • 5단계: 데이터 분석 및 시각화 서비스 (Data Analytics & Visualization)
    • Amazon Athena
      • 정의: 표준 SQL문으로 Amazon S3 또는 하이브리드/멀티클라우드 환경의 다양한 데이터 소스(관계형, 비관계형, 객체)를 직접 쿼리 분석하는 완전관리형 서버리스 서비스
      • 주요 특징: 별도 DB 인프라 구축이나 ETL 없이 S3 데이터를 직접 조회하며, 실행한 쿼리 스캔 용량에 대해서만 과금
    • Amazon Redshift (고성능 분석 엔진)
      • 정의: 대규모 데이터세트에 대해 빈도가 높은 고성능 OLAP SQL 쿼리를 대규모 병렬 구조로 처리하는 데이터 웨어하우스
    • Amazon QuickSight
      • 정의: 다양한 데이터 소스에서 대화형 BI 대시보드 및 리포트를 빠르게 생성하는 클라우드 네이티브 비즈니스 인텔리전스 서비스
      • 주요 특징: Amazon Q 자연어 쿼리(NLQ)가 통합되어 사용자가 자연어로 질의하여 몇 초 내 유용한 인사이트를 구축, 발견, 공유 가능
    • Amazon OpenSearch Service
      • 정의: 비즈니스 및 운영 데이터를 실시간으로 검색, 모니터링, 분석하는 오픈소스 검색 엔진 관리형 서비스
      • 주요 특징: 애플리케이션 모니터링, 로그 분석, 시스템 관찰성(Observability), 웹사이트 검색 및 실시간 시각화 대시보드 제공

• AWS 데이터 파이프라인 5단계 핵심 서비스 요약표

실제 환경에서의 클라우드

데이터 분석 및 AI/ML

• 실무 비즈니스 시나리오: 전자 상거래 앱의 실시간 데이터 분석 및 추천 ML 모델 파이프라인

  • 비즈니스 목표: 앱 사용자 행동 및 과거 구매 데이터를 수집·가공하여, 데이터 과학자의 임시(Ad-hoc) 분석과 ML 엔지니어의 추천 ML 모델 지속 훈련을 동일 데이터세트로 자동화함

• 엔드투엔드 데이터 파이프라인 8단계 흐름 (End-to-End Workflow)

  • 1단계: 개인화 추천 제공 (ML Inference)
    • 전자 상거래 앱이 훈련된 ML 모델을 사용하여 고객에게 실시간 맞춤형 제품 권장 사항(추천)을 제공함
  • 2단계: 트랜잭션 데이터 저장 (Amazon DynamoDB)
    • 애플리케이션을 통해 수집된 과거 고객 구매 트랜잭션 데이터를 Amazon DynamoDB에 저장함
    • 기술적 한계: DynamoDB는 저지연 읽기/쓰기에는 최적이나, 전체 데이터를 스캔하여 ML 모델을 훈련하는 용도로는 부적합하여 데이터 레이크로의 이관이 필수적임
  • 3단계: 스트리밍 데이터 수집 및 집계 (Kinesis Data Streams & Data Firehose)
    • DynamoDB와 Firehose 간 직접 연동이 불가능하므로, 먼저 Amazon Kinesis Data Streams로 DynamoDB 데이터 변경 사항(CDC)을 스트리밍함
    • Amazon Data Firehose가 Kinesis Data Streams로부터 수집된 데이터를 수신하여 준실시간으로 집계 및 전달 준비함
  • 4단계: 데이터 변환 및 포맷팅 (AWS Lambda)
    • DynamoDB 소스 데이터는 JSON 형태이나, ML 엔지니어 및 데이터 과학자는 .csv 표준 포맷을 필요로 함
    • Data Firehose가 AWS Lambda 함수를 자동 간접 호출하여 JSON 소스 데이터를 .csv 포맷으로 실시간 변환 처리함
  • 5단계: 중앙 데이터 레이크 통합 적재 (Amazon S3)
    • 변환이 완료된 .csv 데이터를 중앙 데이터 레이크인 Amazon S3 버킷에 저장하여 복수의 데이터 소비팀이 동시 활용할 수 있도록 전달함
  • 6단계: 데이터 카탈로그화 및 메타데이터 정의 (AWS Glue Data Catalog)
    • AWS Glue 데이터 카탈로그를 메타데이터 리포지토리로 사용하여 S3에 저장된 .csv 데이터의 스키마 및 물리적 위치를 설명하는 카탈로그 테이블을 정의함
  • 7단계: 임시 SQL 데이터 분석 (Amazon Athena)
    • 데이터 과학팀은 S3 밖으로 데이터를 별도 이동하지 않고, Glue 데이터 카탈로그의 스키마 정보를 참조하여 Amazon Athena를 통해 표준 SQL 쿼리를 실행해 비즈니스 인사이트를 도출함
  • 8단계: ML 모델 지속 훈련 (Amazon SageMaker AI)
    • ML 엔지니어링팀은 Amazon SageMaker AI를 통해 S3 데이터 레이크에서 최신 데이터를 직접 읽어와 개인화 추천 ML 모델의 새 버전을 지속적으로 훈련(Re-training)함

• 실제 환경에서의 데이터 분석 & AI/ML 서비스 연동 가이드표

데이터 베이스 소개

• AWS 공동 책임 모델과 데이터베이스 서비스 분류

  • 완전관리형 서비스 (Fully Managed Services)

    • 정의
      • AWS가 하드웨어 프로비저닝, 자동 스케일링, 운영체제 및 DB 패치 적용, 백업, 성능 최적화, 보안 패치, 모니터링 및 지표 제공 등 거의 모든 하부 및 상부 운영 태스크를 직접 처리하는 방식
    • 특징/이점
      • 데이터베이스 운용과 관련된 복잡한 관리 부담이 제거되어 고객의 책임 수준이 3가지 범주 중 가장 적음
      • 고객은 오직 데이터 구조 설계(스키마)와 데이터에 대한 액세스 제어 관리만 전담하면 됨

  • 관리형 서비스 (Managed Services)

    • 정의
      • AWS가 백업, OS 및 DB 패치 적용, 하드웨어 프로비저닝 등 일상적인 기본 인프라 운영 태스크를 처리하고, 상위 세부 설정은 고객이 담당하는 방식
    • 특징/이점
      • 기초 인프라 관리 수고는 덜어주나 고객의 관리 영역 및 책임이 완전관리형에 비해 증가함
      • 고객은 데이터베이스 세부 구성, 쿼리 최적화, 성능 튜닝 판단 및 결정에 대한 책임을 짐

  • 비관리형 서비스 (Unmanaged Services)

    • 정의
      • AWS는 기본적인 물리 인프라만 제공하며, 데이터베이스 엔진 설치부터 구성, 유지관리까지 전 과정을 고객이 직접 수행하는 방식
    • 특징/이점
      • 고객이 DB 소프트웨어 설치, 구성, 패치 적용, 정기 유지보수, DB 보안, 백업, 고가용성(HA) 설정, 성능 최적화 등 관리 전반에 걸쳐 가장 큰 책임을 짐
      • 대표 예시: Amazon EC2 인스턴스를 생성한 후 사용자가 직접 MySQL 등 데이터베이스 관리 시스템(DBMS)을 가동하는 형태

• AWS 데이터베이스 서비스 관리 유형 비교 요약표

AWS 데이터베이스 서비스

관계형 데이터베이스 서비스

• 관계형 데이터베이스 (Relational Database)의 기본 개념

  • 정의
    • 데이터를 행(Row)과 열(Column)로 이루어진 정형 테이블 구조에 저장하고, 공통 속성(Key)을 매개로 다른 테이블과의 연관 관계를 형성하는 데이터베이스 아키텍처
  • 주요 특징
    • 정형 쿼리 언어(SQL)를 사용하여 데이터 조작 및 관리를 수행함 (예: MySQL, PostgreSQL, MariaDB, MS SQL Server, Oracle 등)
    • 정형 데이터를 이해하기 쉽고 일관성 있으며 확장 가능한 방식으로 저장하여 트랜잭션 수용 및 데이터 연관성 추적에 최적화됨
    • 예시 (레스토랑 인벤토리 시스템): ID, 제품 이름, 크기, 가격 등 단일 상품의 속성을 개별 레코드로 행 단위 관리함
  • 온프레미스 DB의 AWS 이관 방식
    • EC2 기반 리프트 앤 시프트 (Lift and Shift): 온프레미스의 기존 DB 배포 환경을 그대로 EC2 인스턴스로 이전하여 OS, CPU, 메모리, 스토리지 변수를 사용자가 직접 제어함 (AWS Database Migration Service(DMS) 활용 가능)
    • AWS 관리형/완전관리형 서비스 채택: 인프라 및 DB 패치, 백업의 자동화를 위해 Amazon RDS나 Amazon Aurora로 전환함

• Amazon Relational Database Service (Amazon RDS)

  • 정의
    • 백업, OS 및 DB 패치 적용, 하드웨어 프로비저닝, 장애 조치 등 복잡한 일상적 관리 태스크를 자동 처리해 주는 관리형 관계형 데이터베이스 서비스
  • 지원 데이터베이스 엔진 (6종)
    • Amazon Aurora, MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, Oracle Database
  • 주요 이점 및 핵심 기능
    • 비용 최적화 (Cost Optimization)
      • 초기 물리 하드웨어 인프라 구매 및 설치 비용이 없으며, 실제 사용한 컴퓨팅 및 스토리지 리소스에 대해서만 종량제로 과금됨
      • 백업, 모니터링, 패치 등 반복 관리 업무의 자동화를 통해 전반적인 운영 비용(OPEX)을 감축함
    • 다중 AZ 배포 (Multi-AZ Deployment)
      • 다른 가용 영역(AZ)에 대기(Standby) 예비 인스턴스를 두고 데이터를 실시간 자동 복제함
      • 주 인스턴스 실패, 유지 관리, 영역 중단 시 수동 개입 없이 자동으로 예비 인스턴스로 장애 조치(Failover)를 수행하여 가동 중지 시간을 최소화함
    • 성능 최적화 및 확장성 (Performance & Scalability)
      • 기본 인스턴스의 읽기 트래픽 부하를 오프로드할 수 있는 읽기 전용 복제본(Read Replica) 지원
      • Amazon RDS 성능 개선 도우미(Performance Insights)를 통해 데이터베이스 로드를 실시간 분석하고 성능 병목을 신속 해결함
      • 필요에 따라 DB 컴퓨팅 및 스토리지 리소스를 수직적/수평적으로 손쉽게 조정 가능함
    • 다층 보안 제어 (Security Controls)
      • VPC 네트워크 격리, 저장 데이터 암호화(Encryption at Rest), 전송 중 암호화(Encryption in Transit) 지원
      • 고객은 보안 조치 구현 및 암호화 옵션 구성에 대한 책임(공동 책임 모델)을 가짐
    • 자동 백업 및 수동 DB 스냅샷
      • 정기적인 자동 백업과 더불어 사용자 요구에 따라 전체 DB 인스턴스의 특정 시점을 수동 백업하는 DB 스냅샷 생성 지원 (시점 복원 및 장기 보관 목적)
  • 주요 실제 사용 사례
    • 웹 애플리케이션 백엔드, 기업 워크로드, 전자 상거래 플랫폼 제품 인벤토리 관리 등

• Amazon Aurora

  • 정의
    • MySQL 및 PostgreSQL과 완벽 호환되며, 불필요한 I/O 작업을 원천 차단하도록 클라우드 네이티브로 재설계된 고성능 완전관리형 관계형 데이터베이스 서비스
  • 주요 이점 및 핵심 기능
    • 초고성능 및 높은 가용성 (High Performance)
      • 표준 MySQL 대비 최대 5배, PostgreSQL 대비 최대 3배 높은 처리량(Throughput) 성능을 제공함
      • 분산 멀티 테넌트 스토리지 아키텍처를 채택하여 고성능 데이터 처리를 보장함
    • 분산 데이터 복제 및 강력한 내결함성 (Fault Tolerance)
      • 가용 영역(AZ) 3개에 걸쳐 데이터 사본 6개를 자동 분산 복제하며 99.99%의 높은 가용성을 보장함
      • 동일 리전의 가용 영역 전체에 최대 15개의 Aurora 읽기 복제본(Read Replica)을 배치할 수 있음
      • 노드 장애 감지 시 데이터 손실 없이 트래픽을 정상 복제본으로 자동 리디렉션함
    • 스토리지 자동 확장 및 지속 백업
      • 데이터 증가에 따라 스토리지 용량이 10GB에서 최대 128TB까지 자동으로 팽창/축소되어 사전 용량 예측이 불필요함
      • Amazon S3에 데이터를 지속적으로 자동 백업하며, 최대 35일 보존 기간 내에서 특정 시점 복원(Point-in-Time Recovery)을 지원함
    • 다양한 엔진 및 분산 DB 지원
      • MySQL, PostgreSQL뿐만 아니라 분산 SQL 데이터베이스(DSQL) 환경도 전면 지원함
  • 주요 실제 사용 사례
    • 대규모 게임 애플리케이션, 미디어 및 콘텐츠 관리 플랫폼, 실시간 대용량 데이터 분석 시스템 등

• Amazon RDS vs Amazon Aurora 비교 요약표

NoSQL 데이터베이스 서비스

• NoSQL 데이터베이스 (Non-Relational Database)의 기본 개념

  • 정의
    • 관계형 데이터베이스(RDBMS)의 정형 테이블 및 고정 스키마 대신, 키-값(Key-Value) 페어나 문서(Document) 구조를 활용해 데이터를 저장하는 비관계형 데이터베이스 아키텍처
  • 주요 특징
    • 유연한 동적 스키마 (Flexible Schema): 데이터베이스 생성 시 고정 스키마를 정의할 필요가 없으며, 언제든지 속성(Attribute)을 추가하거나 제거 가능함 (모든 항목이 동일 속성을 가질 필요가 없음)
    • 키-값 페어 (Key-Value Pair) 저장 방식: 각 데이터 항목(Item)은 고유한 식별 키(Key, 사전의 단어)를 가지며, 여기에 1개 이상의 관련 속성/값(Value, 단어의 정의)이 매핑됨
    • 다양한 속성 유형: 속성 값은 숫자, 문자열 등 단순 유형부터 집합, 문서(JSON) 등 복잡한 구조를 모두 수용함
    • RDBMS의 한계 극복: 데이터 규모 증가 시 관계형 DB에서 발생하는 고정 스키마 변경 부담 및 스케일링 병목 현상을 해결하여 빠르고 가변적인 비정형 데이터 처리에 최적화됨
  • NoSQL 키-값 데이터 저장 예시
    • 키 1: 이름("John Doe"), 주소("123 Any Street"), 좋아하는 음료("미디엄 라떼")
    • 키 2: 이름("Mary Major"), 주소("100 Main Street"), 생일("1994년 7월 5일") -> 항목별로 가지고 있는 속성이 서로 달라도 문제없이 저장됨

• Amazon DynamoDB

  • 정의
    • 키-값 및 문서 데이터 구조를 모두 지원하며, 데이터 규모와 관계없이 10밀리초 미만의 초고속 성능을 보장하는 완전관리형 서버리스 NoSQL 데이터베이스 서비스
  • 주요 이점 및 핵심 기능
    • 완전관리형 서버리스 (Serverless Architecture)
      • 인프라 프로비저닝, 버전 업그레이드, 유지 관리 기간, 보안 패치 적용, 작동 중지 시간 관리가 전혀 필요 없음
      • 운영체제 및 DB 수준의 관리가 자동화되어 콜드 스타트나 관리에 따른 공수가 발생하지 않음
    • 일관된 초고속 성능 (Sub-10ms Latency)
      • 데이터가 페타바이트급으로 증가해도 한 자릿수 밀리초(10밀리초 미만)의 극도로 짧은 응답 성능을 보장함
      • 데이터를 여러 서버와 고성능 SSD 드라이브에 자동으로 분산 적재하여 안정성을 지님
    • 프로비저닝 용량 자동 확장성 (Auto-Scaling)
      • 트래픽 및 실제 사용량 변화에 맞춰 데이터베이스 처리량을 자동으로 스케일 업/다운함
      • 사용자가 목표 사용률을 지정하면 DynamoDB가 스스로 용량을 프로비저닝하며, 테이블 크기 및 총 데이터 저장량에 제약이 없음
    • 높은 가용성 및 내구성 (99.999% Availability)
      • 단일 AWS 리전 내에 존재하는 독립된 개별 시설(AZ) 3개에 데이터를 실시간 자동 복제하여 99.999% 가용성을 제공함
      • 타 리전에 복제본을 멀티 마스터로 배치하는 글로벌 테이블 (Global Tables) 기능을 제공하여 전 세계 분산 애플리케이션의 내결함성을 극대화함
    • 검증된 대규모 트래픽 처리 성능 (Amazon Prime Day 2024 사례)
      • 48시간 동안 DynamoDB API에 대해 수십조 단위의 호출을 안정적으로 처리함
      • 초당 최고 요청 수가 1억 4,600만 건에 달함에도 관리 개입 없이 무중단 자동 스케일링을 증명함
    • 투명한 데이터 암호화 (Encryption)
      • 저장 데이터 암호화(Encryption at Rest)를 지원하여 모든 데이터가 스토리지에 적재되기 전 백그라운드에서 자동 암호화되며, 전송 중 암호화를 함께 제공함
  • 주요 실제 사용 사례
    • 대규모 게임 플랫폼(사용자 상태/스코어보드), 실시간 금융 서비스 응용 프로그램, 글로벌 모바일 애플리케이션 백엔드 등

• 관계형 DB (RDBMS/RDS) vs NoSQL DB (DynamoDB) 비교 요약표

AWS 데이터베이스 데모

• Amazon RDS (MySQL) 실습 데모

  • RDS DB 인스턴스 생성 절차
    • 엔진 및 템플릿 선택: RDS 대시보드에서 Create database 실행 후 DB 엔진으로 MySQL, 사용 템플릿으로 Free tier 선택
    • 인스턴스 식별자 및 자격 증명 설정: DB 인스턴스 식별자로 database-1 입력, Credentials Settings에서 마스터 사용자 이름(admin) 및 암호(password) 지정
    • 네트워크 및 퍼블릭 액세스 구성: Connectivity 섹션에서 기본 VPC를 선택하고, 외부 SQL 클라이언트 접근 테스트를 위해 Public access = Yes 설정 (실제 운영 환경에서는 보안을 위해 퍼블릭 액세스 차단 권장)
    • 상태 전환: 인스턴스 생성 진행 후 상태가 Creating에서 Available로 변환되면 구동 준비 완료
  • RDS 인스턴스 연결 및 SQL 조작 실습
    • 클라이언트 연결 정보: DB 인스턴스 상세 페이지의 Connectivity & security 탭에 표시된 Endpoint(엔드포인트 주소)와 Port(포트 번호) 및 자격증명을 사용해 연결
    • DDL (테이블 생성 및 외래키 연관): Users, Products, Orders 3개 테이블을 생성하며, 외래키(Foreign Key)를 통해 테이블 간 관계를 정의함
    • DML 및 고정 스키마 검증: Insert 문을 실행해 데이터를 적재함 (모든 행이 동일한 열 구조를 가져야 하는 RDBMS의 엄격한 고정 스키마 특성 확인)
    • SELECT & Join 쿼리: 여러 테이블의 데이터를 외래키 조건으로 결합하는 Join SQL 문을 실행하여 모든 사용자 주문 내역을 단일 결과 집합으로 조회함

• Amazon DynamoDB 실습 데모

  • DynamoDB 독립형 테이블 생성 절차
    • 테이블 및 파티션 키 정의: DynamoDB 대시보드에서 Create table 실행 후, 테이블 이름으로 Orders, Partition key(파티션 키) 이름으로 OrderNumber(숫자 Number 타입) 지정
    • 서버리스 즉시 생성: RDS와 달리 인스턴스 관리나 외래키 개념이 없으며, 테이블 이름과 파티션 키 설정만으로 수 초 내 생성 완료 (Creating -> Active)
  • SDK 데이터 적재 및 스캔/쿼리 실습
    • AWS SDK 기반 데이터 로드: Python 스크립트로 DynamoDB API를 직접 호출하여 항목 10개를 테이블에 자동 데이터 적재
    • Scan (전체 데이터 검색): Explore table items -> Scan 실행하여 테이블 내 모든 데이터(Read All) 10개 항목을 반환받음
    • 동적 스키마 (Dynamic Schema) 검증: 스캔 결과 중 Notes 속성이 일부 항목에만 존재하는 것을 확인하여, 항목마다 속성 구성이 다를 수 있는 NoSQL의 유연한 스키마 구조를 실증함
    • Query (특정 항목 핀포인트 검색): Partition Key 조건으로 OrderNumber = 5를 지정하여 Query를 실행함으로써 단 1개의 해당 항목만 고속 반환받음을 확인함

• RDS(MySQL) 데모 vs DynamoDB 데모 실습 비교 요약표

인메모리 캐싱 서비스

• 인메모리 캐시 (In-Memory Cache)의 기본 개념

  • 정의
    • 자주 액세스하는 데이터를 디스크 스토리지 대신 컴퓨터의 주 메모리(RAM)에 임시 적재하여 데이터 검색 및 응답 속도를 극대화하는 고속 데이터 계층
  • 주요 특징 및 작동 메커니즘
    • 극도로 빠른 속도: 디스크 기반 스토리지 시스템보다 수백 배에서 수천 배 빠른 읽기/쓰기 성능을 제공함
    • 프라이머리 DB 부하 절감: 디스크 기반 프라이머리 데이터베이스(예: Amazon RDS)로 향하는 반복 쿼리를 사전에 차단하여 DB 성능 병목 현상을 방지함
    • 캐시 적중 및 누락 (Cache Hit & Cache Miss) 처리 흐름
      • Cache Hit (적중): 애플리케이션 요청 시 데이터가 캐시에 이미 존재하여 즉시 사용자에게 반환됨
      • Cache Miss (누락): 캐시에 데이터가 없을 경우 백엔드 DB(RDS)에서 데이터를 읽어와 캐시에 저장한 뒤 사용자에게 결과를 전달함 (다음 요청부터 즉시 반환 가능)
    • 적합한 데이터 유형: 사용자 세션 데이터, API 응답, 반복 데이터베이스 쿼리 결과, 정적/반복 참조 정보 등

• Amazon ElastiCache

  • 정의
    • Redis OSS, Valkey, Memcached와 호환되며 마이크로초(Microsecond) 단위의 초저지연 응답을 제공하는 완전관리형 인메모리 캐싱 서비스
  • 지원 인메모리 캐시 엔진 (3종)
    • Redis OSS, Valkey, Memcached
  • 주요 이점 및 핵심 기능
    • 마이크로초(Microsecond) 단위 초저지연 성능 (Sub-millisecond Latency)
      • 1밀리초보다 찰나인 마이크로초(μs) 단위의 응답 속도를 보장하여 읽기 트래픽이 많은 대규모 애플리케이션의 응답성을 극대화함
    • 완전관리형 및 서버리스 (Serverless) 옵션
      • 하드웨어 프로비저닝, OS 및 캐시 엔진 패치 적용, 모니터링, 결함 노드 자동 교체 등을 AWS가 자동화함
      • 트래픽 변동에 맞춰 자동으로 스토리지 및 컴퓨팅 용량이 조절되는 ElastiCache Serverless 옵션을 제공하여 운영 오버헤드를 줄임
    • 데이터베이스 아키텍처 비용 최적화 (Cost Optimization)
      • 캐시 계층이 읽기 트래픽의 상당량을 수용(Offload)하므로 백엔드 데이터베이스(RDS) 인스턴스 스펙을 더 작고 저렴한 클래스로 유지할 수 있어 전체 시스템 비용을 감축함
    • 고가용성 및 자동 장애 복구 (High Availability)
      • 프라이머리 노드 장애를 지속 감지하며, 결함 발생 시 수동 개입 없이 몇 분 내에 복제본(Replica) 노드를 새로운 프라이머리로 자동 승격하여 가동 중지 시간을 최소화함
    • 다중 가용 영역(Multi-AZ) 복제
      • 여러 가용 영역(AZ)에 프라이머리 및 복제본 노드를 분산 배치하여 특정 AZ 인프라 마비 시에도 데이터 접근성을 유지함
    • 다층 보안 및 데이터 암호화 (Encryption)
      • 저장 데이터 암호화 (Encryption at Rest): 디스크 스토리지 및 자동 백업 파일 암호화
      • 전송 중 암호화 (Encryption in Transit): TLS(전송 계층 보안) 프로토콜을 통해 클라이언트와 캐시 노드 간 통신 구간 암호화
  • 전형적인 웹 아키텍처 흐름 (EC2 + ElastiCache + RDS)
    • 사용자 데이터 요청 -> EC2 애플리케이션 서버 -> 1차: ElastiCache 조회 -> (Hit: 즉시 응답 / Miss: 2차: RDS 쿼리 -> ElastiCache 결과 저장 -> 사용자 응답)
  • 주요 실제 사용 사례
    • 웹/모바일 세션 상태 관리, 대용량 DB 쿼리 결과 캐싱, 실시간 게임 순위표(Leaderboard), 콘텐츠 전송 시스템(CDN) 캐시 백엔드 등

• 관계형 DB (RDS) vs 인메모리 캐시 (ElastiCache) 비교 요약표

추가 데이터베이스 서비스

• AWS의 목적별 데이터베이스 (Purpose-Built Databases) 전략

  • 정의
    • "모든 용도에 알맞은 만능 데이터베이스는 없다"는 원칙하에, 애플리케이션 데이터의 고유한 형태와 비즈니스 요구사항에 가장 적합한 전용 데이터베이스를 채택하는 전략
  • 핵심 메커니즘
    • 정형(관계형), 키-값, 문서, 그래프, 블록체인 원장 등 워크로드의 특성에 데이터를 맞추어 선택함으로써 최상의 성능과 비용 효율성을 달성함

• 특수 목적 데이터베이스 서비스군

  • Amazon DocumentDB (MongoDB 호환)
    • 정의: 고정된 관계형 스키마에 부합하지 않는 반정형(Semi-structured) JSON 문서를 관리하도록 설계된 완전관리형 문서 데이터베이스 서비스
    • 주요 이점 및 핵심 기능
      • MongoDB 완벽 호환성: 기존 MongoDB API, 드라이버, 도구를 그대로 보존하여 코드 수정 없이 애플리케이션 마이그레이션이 가능함
      • 유연한 동적 스키마: 사전 정의된 스키마 없이 신속한 반복 개발 및 잦은 데이터 속성 변경을 손쉽게 수용함
      • 스토리지 자동 확장성: 데이터 증가에 따라 스토리지를 10GB 단위 증분으로 최대 64TB까지 자동 확장하며 초당 수백만 건의 요청을 수용함
      • 읽기 처리량 향상 (최대 15개 복제본): 기본 스토리지를 공유하는 읽기 전용 복제본(Replica) 인스턴스를 최대 15개까지 생성하여 읽기 성능을 획기적으로 개선함
    • 주요 실제 사용 사례: 콘텐츠 관리 시스템(CMS), 상품 카탈로그 및 인벤토리 관리, 사용자 프로필 및 개인화 시스템 등
  • Amazon Neptune (그래프 데이터베이스)
    • 정의: 소셜 네트워크, 친구 관계망, 사기 행위 패턴 등 고도로 연결된 데이터세트의 복잡한 관계를 관리하기 위해 특별히 제작된 완전관리형 그래프 데이터베이스 서비스
    • 주요 이점 및 핵심 기능
      • 복잡한 관계 파악 특화 Engine: 관계형 DB에서 쿼리하기 어려운 소셜 웹 및 상호 연결 데이터를 속성 그래프(Property Graph) 및 RDF 모델을 통해 손쉽게 탐색함
      • 밀리초(ms) 단위의 고속 쿼리 성능: 수십억 개의 복잡한 관계를 몇 밀리초(ms) 안에 빠르게 처리하여 대규모 관계 매핑 및 패턴 일치를 수행함
      • 자동 확장 및 고가용성: 스토리지를 최대 64TB까지 자동으로 확장하며, 자동 장애 조치 및 지속 백업을 내장함
    • 주요 실제 사용 사례: 소셜 네트워크 사용자 연결 매핑, 실시간 사기 행위(Fraud) 탐지 시스템, 검색 및 추천 시스템 등
  • Amazon Managed Blockchain
    • 정의: 투명한 데이터 변경 이력 보장 및 공급망 관리를 위해 분산 블록체인 네트워크를 손쉽게 생성하고 관리하도록 지원하는 전용 서비스
    • 주요 실제 사용 사례: 식품 안전을 위한 식자재 공급망(Supply Chain) 추적, 유통 품목 분실 방지, 데이터 이력 보관 등

• 데이터베이스 가속기 & 중앙 집중식 통합 백업 서비스

  • Amazon DynamoDB Accelerator (DAX)
    • 정의: Amazon DynamoDB 비관계형 데이터의 읽기 반응 속도를 대폭 개선하기 위해 기본 제공되는 전용 인메모리 캐싱 계층 (In-Memory Cache Layer)
    • 특징/이점: DynamoDB 읽기 시간을 마이크로초(μs) 단위로 단축시켜 응답성을 극대화함
  • AWS Backup (중앙 집중식 통합 백업 관리)
    • 정의: Amazon EBS 볼륨, Amazon EFS 파일 시스템, RDS 데이터베이스, DynamoDB 테이블 및 온프레미스 데이터 전체에 대해 중앙에서 데이터 보호를 자동 관리하는 통합 백업 서비스
    • 주요 이점 및 핵심 기능
      • 단일 대시보드 중앙 집중 관리: 여러 AWS 서비스 및 계정 전체의 백업 작업, 복원 지점, 규정 준수 상태를 단일 통제면에서 관제하여 구성 오류와 운영 복잡성을 제거함
      • 자동 백업 일정 및 정책 적용: 비즈니스 정책에 따라 백업 일정을 자동화하고, 새 리소스 생성 시 자동으로 백업 대상에 포함시킴
      • 리전 간 백업 이중화 (Cross-Region Replication): 재해 복구(DR)를 위해 백업 데이터를 타 AWS 리전에 자동 복제하여 프라이머리 리전 마비 시 세컨더리 리전에서 신속 복구함
      • 간소화된 규정 준수 및 감사 (Compliance & Audit): 백업 활동 추적, 상세 감사 로그 및 보고서를 자동 유지 관리하여 엄격한 법적/보안 요구사항을 입증함
    • 주요 실제 사용 사례: 전사 중앙 집중식 재해 복구, 규정 준수 통합 백업 정책 수립 등

• AWS 추가 데이터베이스 및 백업 서비스 요약표

우리는 같은 일을 하더라도 이제 결코 예전과 같은 방식과 방법을 사용하지 않는다. 2026년 AI 대격변을 겪은 이후에는 그 격차와 괴리가 더더욱 크게 느껴진다. 우리는 왜 이런 다름을 느끼는 것일까? 단지 AI가 업무 깊숙이 들어왔기 때문일까? 단지 그것만은 아니라는 생각이 든다.

테크 리더들의 파격적인 선언들

• 젠슨 황 (NVIDIA CEO, 2024 WGS): "앞으로의 프로그래밍 언어는 인간의 자연어가 될 것이다."
• 매트 웰시 (전 하버드대 CS 교수, 2026.02): "컴퓨터 공학은 끝났다."
• 보리스 체르니 (Anthropic Claude Code 리드): "소프트웨어 엔지니어라는 직업 타이틀은 곧 사라진다."

개발자로 살아가고 밥벌이를 하는 우리는 심각한 고민에 빠질 수밖에 없다. 테크 리더들이 개발자라는 직업 정체성을 부정하고 있는 상황에서, 우리는 개발자가 '멸종'할 것인가, 아니면 '진화'할 것인가에 대해 진지하게 고민해 봐야 한다.

기존의 개발자들은 언어의 문법과 라이브러리를 숙지해야 했고, 라인 단위로 코드를 작성했으며, 버그 수정 및 리팩토링을 직접 수행했다. 하지만 2026년 현재, 우리는 대부분의 작업을 '손수 직접' 하지 않는다. 물론 여전히 수많은 현장에서 코드를 직접 치고 버그를 고치고 있지만, 그것이 점차 특정 상황에서만 일어나는 예외적인 일이 되어가고 있음을 우리는 부정할 수 없다.

Boris Cherny가 말하는 5가지 아키타입 (Archetypes)

Anthropic에서 Claude Code 팀을 이끄는 보리스 체르니(Boris Cherny)는 그들의 팀에 프론트엔드/백엔드/PM/디자이너 같은 구분 없이 'Member of Technical Staff'라는 통일된 명칭을 사용한다고 밝혔다.

대신 직무 형태의 타이틀을 갖는 것 피하고, 제품의 라이프사이클(Lifecycle)에서 어떤 역할을 수행하는가에 따라 팀원의 역할을 5가지 아키타입으로 정의한다.

1. 프로토타이퍼 (Prototyper)
   • 새로운 아이디어를 검증하기 위해 빠르게 수십 개의 시제품(Prototype)을 찍어내는 역할.
2. 빌더 (Builder)
   • 프로토타이퍼가 검증하여 살아남은 아이디어를 실제 사용자가 쓸 수 있는 프로덕션(Production-grade) 수준의 완성도 높은 제품으로 빌드하는 역할.
3. 스위퍼 (Sweeper)
   • AI로 인해 비대해진 시스템을 단순화하고, 코드 및 기능의 비효율을 정리하며, 성과가 없는 기능을 과감히 제거(Unship)하고 리팩토링하는 역할.
4. 그로워 (Grower)
   • 이미 출시된 제품을 사용자 데이터와 피드백을 기반으로 지속적으로 개선하여 PMF(Product-Market Fit)를 극대화하는 역할.
5. 메인테이너 (Maintainer)
   • 성숙 단계에 접어든 제품이 트래픽 증가에도 안정적이고 고성능으로 작동하도록 장기적인 시스템 상태를 관리하는 역할.

이 5가지 역할군은 예전처럼 누군가가 고정적으로 지정해 주는 고정 직무가 아니다. 그때그때 상황과 제품의 단계에 맞춰 본인이 필요한 롤(Role)을 취하며 일한다는 의미다.

롤을 지정해주지 않았는데, 팀원들이 스스로 아키타입을 맡기 시작했다

흥미롭게도 지금 회사에서 올해 초부터 진행 중인 프로젝트에서 이 현상을 똑같이 목격했다. 보리스 체르니의 5가지 아키타입에 대해 팀원들에게 알려주지도 않았고 역할을 배정하지도 않았지만, 프로젝트가 진행되면서 자연스럽게 각자가 이 Role을 스스로 맡아 움직이기 시작했다.

• 서비스 기획자와 프론트엔드 개발자는 자연스럽게 프로토타이퍼가 되어 가장 빠르게 동작하는 최소 제품을 목업 형태로 만들어내고 있다.
• 백엔드 개발자 중 일부는 빌더가 되어 해당 프로토타입을 바탕으로 실제 운영 가능한 프로덕션급 시스템을 구축 중이다.
• 그리고 빌더의 역할을 하던 백엔드 개발자 몇몇은 자연스럽게 스위퍼가 되어 비대해진 코드를 청소하고 구조 단순화 및 코드 품질 리팩토링을 진행하고 있다.
• 필자 역시 빌더에서 스위퍼의 역할을 자처하여 프로젝트를 진행 중이다. AI가 코드를 빠르게 만들어내다 보니 오히려 코드베이스가 쉽게 비대해졌고, 이를 정리하고 아키텍처를 단단하게 다지는 작업이 필수적이었기 때문이다.

프로젝트 초반에는 너무나도 혼란스러웠고, 참여한 인원 대다수가 불만과 불안함을 토로했다. 하지만 제품은 나와야 했고 시간은 흘렀다. 개발자들은 누가 시키지도 않았는데 너무나 자연스럽게 저 5가지 아키타입을 스스로 받아들이며 적응해 가고 있다.

이 프로젝트의 결말이 어떻게 될지는 누구도 모른다. 혹자는 과거의 검증되고 익숙한 방식에서 편안함을 느낄 것이고, 누군가는 변화의 시대에 스텝을 맞춰가고 싶어 할 것이다.

멸종인가 진화인가: 우리는 코더인가, 문제 해결사인가

"AI가 코드를 다 작성해 주고 테스트해 주니 개발자가 할 일은 없다"라고 주장하는 것은 너무 1차원적인 시각이다. 개발자의 역할은 그저 코더(Coder)에 국한되지 않는다.

과거에는 *"이 함수나 쿼리를 어떻게 문법에 맞게 구현하지?"라는 *방법론에 대부분의 시간을 썼다면, 이제는 *"이 시스템을 어떻게 구성해야 확장성과 안정성을 갖출 수 있을까?"하는 *목적과 아키텍처 구조에 대부분의 시간을 할애할 수 있게 되었다.

비즈니스 문제를 정의하고, 전체 아키텍처를 설계하며, 구현을 위한 AI 에이전트를 조율하고 역할을 분배하는 오케스트레이션은 여전히 사람이 해야 하는 영역이다.

물론 2027년, 아니 당장 다음 달이라도 이것조차 하지 않아도 될 정도로 AI가 발전할지 모른다. 그렇기에 남들과 차별화될 부분을 더 빨리 찾아야 하고, 최적화해야 하며, 상당한 수준으로 발전시켜야 살아남을 수 있다.

겨우 6년 차인 초보 백엔드 개발자의 소회이지만, 한 가지 확실한 것은 변화는 너무나도 빠르며 이 거대한 변화의 강물은 우리를 결코 기다려주지 않는다는 점이다.

스토리지 소개

• 데이터 유형별 스토리지 분류 (블록, 객체, 파일)

  • 블록 스토리지 (Block Storage)
    • 정의
      • 데이터를 블록(Block)이라는 관리하기 쉬운 고정 크기 조각으로 나누어 저장하고 처리하는 스토리지 아키텍처
    • 특징/이점
      • 데이터를 수정할 때 전체 파일을 고칠 필요 없이 특정 블록만 개별 업데이트할 수 있어 신속함
      • 데이터베이스나 빈번하고 빠른 업데이트가 요구되는 트랜잭션 애플리케이션의 개발에 적합함
  • 객체 스토리지 (Object Storage)
    • 정의
      • 데이터를 플랫(Flat)한 주소 공간 내에 데이터 본체, 고유 식별자(ID), 그리고 속성 정보인 메타데이터(Metadata)를 포함한 독립된 '객체' 단위로 보관하는 방식
    • 특징/이점
      • 계층적 폴더 트리 구조 대신 '버킷(Bucket)'이라는 단순한 평면 구조를 사용해 대용량 데이터의 구성 및 검색이 용이함
      • 일부 데이터만 수정하는 것이 불가능하며, 변경 사항이 있을 때마다 전체 객체를 새로 작성(덮어쓰기)해야 함
      • 이미지, 동영상, 로그 파일, 백업 데이터 등 지속적으로 수정되지 않는 비정형 데이터 보관에 적합함
  • 파일 스토리지 (File Storage)
    • 정의
      • 디렉토리와 폴더 등의 계층적 파일 시스템 구조를 사용하여 네트워크를 통해 여러 사용자와 애플리케이션이 동시에 데이터에 접근할 수 있게 돕는 공유 스토리지
    • 특징/이점
      • 기존 운영체제의 파일 시스템과 완벽히 호환되므로 애플리케이션의 코드를 수정할 필요가 거의 없음
      • 콘텐츠 관리 시스템(CMS)이나 다수 직원이 공유하는 문서/교육 설명서 보관용 공유 폴더에 적합함

• AWS의 주요 스토리지 서비스 및 추가 기능

  • 블록 스토리지 서비스
    • Amazon EC2 인스턴스 스토어 (EC2 Instance Store)
      • 정의: EC2 인스턴스에 물리적으로 직접 연결되어 단기 임시 데이터 처리에 사용되는 비영구적인 고성능 블록 스토리지
    • Amazon Elastic Block Store (EBS)
      • 정의: EC2 인스턴스와 별개로 영구적으로 지속되는 스토리지 볼륨을 제공하며, 암호화와 스냅샷 백업 기능을 갖춘 관리형 블록 스토리지
  • 객체 스토리지 서비스
    • Amazon Simple Storage Service (S3)
      • 정의: 전 세계 어디서나 원하는 양의 데이터를 저장 및 검색할 수 있도록 제한 없는 확장성과 고내구성을 제공하는 완전관리형 객체 스토리지
  • 파일 스토리지 서비스
    • Amazon Elastic File System (EFS)
      • 정의: AWS 클라우드 서비스와 온프레미스 모두에서 동시에 마운트해 공유할 수 있는 확장 가능한 완전관리형 NFS 기반 파일 시스템
    • Amazon FSx
      • 정의: Windows, Lustre, NetApp ONTAP 등 널리 쓰이는 타사 전문 파일 시스템 엔진을 AWS에서 편리하게 가동하도록 돕는 완전관리형 파일 스토리지
  • 추가 스토리지 서비스
    • AWS Storage Gateway
      • 정의: 온프레미스 환경에서 사실상 무제한의 AWS 클라우드 스토리지 리소스에 원활히 접근할 수 있도록 연동을 제공하는 하이브리드 스토리지 서비스
    • AWS Elastic Disaster Recovery
      • 정의: 물리적, 가상 또는 다른 클라우드에 배치된 서버 환경 전체를 AWS로 신속하게 백업 및 복구하도록 절차를 간소화하는 재해 복구 완전관리형 서비스

• AWS 공동 책임 모델과 스토리지 관리 유형

  • 완전관리형 서비스 (Fully Managed Services)

    • 정의
      • AWS가 하위 하드웨어 인프라부터 상위 스토리지 소프트웨어 스택 전반을 직접 유지 보수하고 복제 및 암호화까지 보장해 주는 유형 (예: S3, EFS 등)
    • 특징/이점
      • 데이터 복제, 내구성 확보, 암호화 등 인프라의 복잡한 세부 관리를 AWS가 전담하므로 고객의 관리 책임 및 부담이 가장 작음
      • 고객은 단지 데이터를 관리하고 적절한 액세스 제어 정책을 셋팅하는 역할만 책임짐

  • 관리형 서비스 (Managed Services)

    • 정의
      • AWS가 스토리지 하드웨어와 물리적 복제, 장비 이중화 같은 기본 하위 인프라 관리만을 전담하고 상위 운영은 고객이 담당하는 유형 (예: EBS 등)
    • 특징/이점
      • 인프라 설비 부담은 없으나 백업 전략 수립, 암호화 키 구성, 볼륨 성능 최적화, 용량 관리 등의 책임은 고객이 직접 져야 하므로 완전관리형 대비 소유 권한 및 관리 영역이 넓음

  • 비관리형 서비스 (Unmanaged Services)

    • 정의
      • AWS는 기본적인 물리적 서버 인프라와 네트워크의 유지보수만을 수행하고, 고객이 그 위의 모든 운영체제 및 데이터를 관리하는 유형 (예: EC2 인스턴스 스토어 등)
    • 특징/이점
      • 데이터의 관리, 백업 및 복구 계획 수립, 암호화 세팅, 성능 최적화 등 거의 모든 고수준의 유지 보수 책임이 전적으로 고객에게 귀속됨

블록 스토리지 (Block Storage)

EC2 인스턴스 스토어 및 Amazon Elastic Block Store(Amazon EBS)

• 블록 수준 스토리지의 기본 개념
  • 정의
    • 데이터를 디스크의 '블록(Block)'이라는 관리하기 쉬운 고정 크기 조각(일련의 바이트)으로 나누어 보관하고, 파일 업데이트 시 전체를 교체하지 않고 변경된 블록만 효율적으로 덮어쓰는 스토리지 아키텍처
  • 특징/이점
    • 데이터베이스, 엔터프라이즈 소프트웨어, 파일 시스템 등 빠르고 잦은 트랜잭션 업데이트가 빈번한 시스템에 매우 효율적임 (랩톱의 로컬 하드 드라이브와 유사한 개념)
• Amazon EC2 인스턴스 스토어 (Instance Store)
  • 정의
    • EC2 인스턴스의 물리적 호스트 컴퓨터에 직접 연결되어 지연 시간이 극도로 짧은 블록 레벨의 임시 물리 스토리지
  • 특징/이점
    • 데이터 지속성 없음 (휘발성/임시적): 물리적 호스트에 바인딩되어 있으므로, EC2 인스턴스가 중지(Stop)되거나 종료(Terminate)되면 호스트가 변경되어 내부에 기록된 모든 데이터가 영구히 소멸함
    • 임시 스크래치 공간, 버퍼, 캐시, 대규모 고성능 연산 데이터 등 데이터 유실을 감수할 수 있는 비영구적 요구사항에 적합함
    • 자동으로 제공됨: 추가적인 비용 지불 없이 특정 EC2 인스턴스 유형 선택 시 기본으로 장착되어 제공됨
    • 초저지연 및 고성능: 호스트 서버에 물리적으로 직접 연결되어 가상화 레이어를 타는 외장 볼륨 대비 극도로 뛰어난 I/O 처리 성능을 자랑함
• Amazon Elastic Block Store (EBS)
  • 정의
    • EC2 인스턴스와 생명주기가 격리되어 인스턴스가 꺼지거나 종료되어도 데이터가 소멸하지 않고 영구 보존되는 외장 가상 하드 드라이브(가상 블록 볼륨) 서비스
  • 특징/이점
    • 데이터 지속성 보장 (영구적): 인스턴스가 정지되거나 가동 중단되어도 EBS 내부에 쓰여진 데이터는 온전히 보존되며 다른 인스턴스에 재부착하여 사용할 수 있음
    • 네트워크 연결 방식: 인스턴스가 실행되는 물리 호스트와 분리되어 가상으로 통신하므로 유연한 마운트 관리가 가능함
    • 성능 단위 (IOPS): 초당 입력 및 출력 작업 수(IOPS)로 성능을 모니터링하고 튜닝함
  • EBS의 세부적인 이점 및 활용 사례
    • 이식성 및 데이터 마이그레이션: 인스턴스에서 쉽게 분리(Detach)하여 다른 인스턴스에 즉시 연결(Attach)할 수 있으며, 스냅샷을 생성해 가용 영역(AZ)이나 리전 간에 볼륨 복사 및 데이터 이동을 손쉽게 수행할 수 있음
    • 유연한 인스턴스 변경: 볼륨 데이터와 무관하게 EC2 인스턴스의 스펙 업그레이드/다운그레이드 시 볼륨만 따로 재장착해 무손실 마이그레이션이 가능함
    • 재해 복구 (Disaster Recovery): 특정 시점의 전체 데이터를 캡처하는 'EBS 스냅샷'을 통해 증분 백업을 지원하며, 긴급 상황 발생 시 다중 리전에서 빠르게 리소스를 복원해 냄
    • 비용 및 성능 최적화: 가동 중지 시간(Downtime)을 겪지 않고 스토리지 용량을 확장하거나 다양한 볼륨 성능 유형(SSD, HDD 등)으로 동적 전환할 수 있음
    • 성능 튜닝: 다양한 요금 및 IOPS(초당 입출력 작업 수) 수준을 만족하는 볼륨 유형을 구비해 수요 변화에 맞춰 즉시 수정 적용이 가능함

Amazon Elastic Block Store(Amazon EBS) 데이터 수명 주기

• 공동 책임 모델 관점에서의 EBS 볼륨 관리
  • 정의
    • 사용자의 데이터를 안전하게 관리하기 위해 프로비저닝, 이동, 프로비저닝 해제, 백업을 비롯한 EBS 볼륨의 전반적인 라이프사이클을 고객이 직접 설계 및 제어하는 책임
  • 세부 책임 사항
    • 백업 전략의 일환으로 정기적인 EBS 스냅샷을 예약 및 관리해야 함
    • 과도한 요금이 청구되지 않도록 스냅샷 비용을 지속 모니터링하고 불필요한 스냅샷을 식별하여 삭제해야 함
    • 스냅샷 내부의 민감 데이터를 암호화하고 무결성을 확인하며, 복원 절차를 정기적으로 테스트해 비상 상황에 대비해야 함
• EBS 스냅샷 (EBS Snapshot)
  • 정의
    • EBS 볼륨의 특정 시점(Point-in-Time) 백업 사본을 생성하여 Amazon S3에 여러 가용 영역에 걸쳐 중복 저장하는 가상 백업 기술
  • 작동 메커니즘
    • 초기 스냅샷: 최초 생성 시 기준점이 되며, 해당 특정 시점의 볼륨에 있는 모든 사용 중인 데이터 블록의 전체 사본을 캡처함
    • 후속 증분 스냅샷: 이전 스냅샷 생성 시점 이후로 새롭게 변경된 데이터 블록만 추적하여 복사하므로 스냅샷 생성 속도가 빠르고 스토리지를 매우 효율적으로 사용함
    • 체인 구조 및 자동 관리: 각 증분 스냅샷은 이전 스냅샷의 참조 값을 가져 체인을 형성하며, 스냅샷 삭제 시에는 다른 스냅샷이 참조하는 공통 데이터는 남겨두고 해당 스냅샷에만 고유했던 데이터만 제거해 안전하게 복원성을 유지함
  • 특징/이점
    • 데이터 보호 및 빠른 복구: 데이터의 손상, 실수로 인한 삭제, 시스템 실패 등의 긴급 상황에서 특정 시점의 원본 볼륨과 완벽히 일치하는 새 볼륨을 즉각 생성하여 복원함
    • 운영 유연성: 스냅샷을 매개로 삼아 리전 간 데이터 마이그레이션, 볼륨 크기 및 성능 조정을 위한 복제, 타 AWS 계정과의 안전한 데이터 공유 등을 수행함
    • 비용 효율성: 변경된 블록만 저장하는 증분 방식을 통해 매번 전체 백업을 수행할 때 발생하는 비용 부담을 획기적으로 줄임
• Amazon Data Lifecycle Manager (DLM)
  • 정의
    • EBS 스냅샷의 생성, 보존 및 삭제 동작을 정의된 규칙 정책에 따라 자동으로 수행해 주는 완전관리형 스냅샷 수명 주기 관리 서비스
  • 특징/이점
    • 수동으로 스냅샷을 일일이 제어하면서 발생하는 인적 장애(실수)를 예방하고 관리 리소스를 대폭 절감함
    • 피크 시간 이외의 스케줄러 설정을 통해 스냅샷 생성 동작이 인스턴스 실시간 성능에 미치는 영향을 최소화함
    • 오래된 백업 데이터를 정의된 기한에 따라 자동으로 파기함으로써 스토리지 비용의 누수를 원천 차단하고 기업의 보안 규정 준수(Compliance) 요건을 일정하게 달성함
  • 설정 및 워크플로 5단계
    • 1단계 (EBS 스냅샷 정책 생성): EC2 콘솔, API 호출, CLI, SDK, CloudFormation을 활용해 자동화 정책 생성
    • 2단계 (대상 리소스 유형 선택): 스냅샷 대상으로 삼을 EBS 볼륨 또는 EC2 인스턴스를 지정
    • 3단계 (볼륨 제외): 스냅샷 포함 범위를 줄이기 위해 루트 볼륨 또는 데이터 볼륨 중 불필요한 볼륨을 제외 설정
    • 4단계 (사용자 지정 일정 설정): 스냅샷의 주기적 생성 스케줄, 보존 및 파기 규칙 등을 커스텀 입력
    • 5단계 (추가 작업 적용): 정책 마무리에 맞춰 태그 지정, 스냅샷 아카이빙, 빠른 스냅샷 복원(FSR) 가동, 리전 간 자동 복사 및 계정 공유 규칙을 최종 셋팅

객체 스토리지

Amazon Simple Storage Service(Amazon S3)

• Amazon Simple Storage Service(S3) 개요
  • 정의
    • 원하는 양의 데이터를 인터넷 어디서나 객체 형태로 안전하게 저장하고 검색할 수 있는 완전관리형 고가용성 객체 스토리지 서비스
  • 특징/이점
    • 대규모 웹 트래픽 급증을 별도의 스케일링 설정 없이 자동 수용하며, 서비스 구동을 위한 물리 서버 및 인프라 관리를 AWS가 전담함
    • 소규모 스타트업부터 대기업까지 비즈니스 수요 변화에 맞춰 유연하게 리소스 규모를 스케일 업/다운할 수 있음
• S3의 핵심 구성 요소
  • S3 객체 (S3 Object)
    • 정의
      • Amazon S3에 저장되는 데이터 스토리지의 기본 단위 (파일)
    • 특징/이점
      • 파일 데이터 본체, 고유 식별자(키/Key), 그리고 속성을 설명하는 메타데이터(Metadata)로 구성됨
      • 개별 객체 업로드 가능한 최대 크기는 5TB이며, 버킷 내에서 고유 키(Key, 파일 경로 및 이름에 대응)로 식별됨
      • 객체는 이미지, 동영상, 스프레딧시트, 문서, 애플리케이션 등 모든 파일 유형을 허용하며 버전 ID, 액세스 제어 정보 등을 포함함
  • S3 버킷 (S3 Bucket)
    • 정의
      • S3 객체들을 저장하고 격리해 관리하는 최상위 컨테이너
    • 특징/이점
      • 디렉토리 계층 구조가 아닌 '버킷'이라는 플랫(Flat)한 평면 구조 주소 공간을 사용하여 데이터를 구성하고 검색함
      • 전 세계 모든 AWS 영역을 통틀어 중복 없는 유일한 글로벌 이름을 지녀야 하며 생성 시 특정 리전을 지정함
      • 총 버킷 크기 및 저장할 수 있는 객체의 수에는 상한선이 없어 사실상 무제한으로 용량을 확장함
      • 버킷 수준에서 버전 관리, 로깅, 암호화, 액세스 권한 등 상세 설정을 조율하고 정책을 적용함
• S3의 주요 기능 및 이점
  • 사실상 무제한 스토리지
    • 정의: 용량 제약 없이 저장하는 데이터 크기에 맞춰 스토리지가 무한히 자동 팽창/수축되는 구조
    • 특징/이점: 사용한 만큼만 요금을 지불하므로 매우 비용 효율적으로 데이터 급증에 대응함
  • 극도로 높은 데이터 내구성 (Durability)
    • 정의: 하드웨어 결함이나 자연재해로 인해 데이터가 유실되지 않도록 보장하는 지표
    • 특징/이점: AWS가 내부적으로 데이터를 자동으로 이중화하여 여러 시설 및 가용 영역에 다중 객체 사본을 상시 중복 저장하므로 99.999999999% (11 9s)에 달하는 극도의 내구성을 제공함
  • 객체 버전 관리 (Versioning)
    • 정의: 동일 객체에 대해 수정이나 삭제 발생 시 이전 빌드 내역을 보존하고 이력을 추적하는 기능
    • 특징/이점: 사용자의 인적 실수로 파일이 삭제되거나 덮어쓰기 되었을 때 언제든지 이전 버전을 복원해 안전성을 확보함
  • 객체 수명 주기 관리 (Lifecycle Management)
    • 정의: 사전에 정의한 수명 주기 규칙에 맞춰 일정 기간이 지난 객체를 더 저렴한 스토리지 클래스로 자동 이관하거나 영구 삭제하는 기능
    • 특징/이점: 데이터 관리 자동화 및 시간 경과에 따른 비용 최적화를 간편히 실현함
  • 광범위한 사용 사례
    • 정의: 단순 백업 저장소부터 고급 비즈니스 아키텍처에 이르기까지 폭넓은 비즈니스 사용 사례 지원
    • 특징/이점: 정적 웹 사이트 호스팅, 백업 및 재해 복구, 미디어 파일 배포, 장기 아카이빙, 대규모 데이터 레이크(Data Lake) 구축 및 규정 준수 기반 보존에 범용적으로 활용됨
• S3 보안 및 액세스 제어 관리 (Security & Privacy)
  • 기본 보안 정책
    • 정의: Amazon S3의 모든 버킷과 객체는 생성 시 기본적으로 완전히 비공개(Private) 상태로 설정되며, 작성한 계정 소유자 외의 접근은 전면 차단됨
  • 세부 보안 제어 기능
    • 버킷 정책 (Bucket Policy)
      • 정의: S3 버킷 리소스에 직접 연결하여 버킷 내부의 객체 및 동작 권한을 통제하는 리소스 기반 정책 문서
      • 특징/이점: 해당 버킷에 요청되는 인바운드/아웃바운드 작업 중 무엇을 허용하고 거부할지 일괄 규정함
    • 자격 증명 기반 정책 (Identity-based Policy)
      • 정의: IAM 사용자, 그룹, 역할에 권한 정책 문서를 직접 연결하여 S3 리소스 액세스를 제어하는 방식
      • 특징/이점: 특정 사용자가 어떤 버킷 및 객체에 접근하고 어떤 액션을 수행할 수 있는지 상세 자격 권한을 규정함
    • 미리 서명된 URL (Presigned URL)
      • 정의: 버킷 정책을 수정하지 않고도, 특정 객체에 대해 시간제한이 걸린 한시적 공유용 URL을 발급해 주는 기능
      • 특징/이점: 외부 파트너나 고객에게 임시 액세스 권한만을 부여해 장기 권한 유지 리스크를 사전에 예방함
    • S3 액세스 포인트 (S3 Access Points)
      • 정의: 다수의 사용자나 대규모 조직이 대량의 공유 데이터세트를 활용할 때, 각 그룹 전용의 고유 액세스 경로와 개별 정책 제어점을 분할 생성하는 기능
      • 특징/이점: 여러 그룹의 다양한 권한 관리 요구사항을 간소화하여 보안 관리의 오류를 사전에 차단함
    • S3 감사 로그 (S3 Audit Logs)
      • 정의: S3 리소스로 향하는 모든 통신 및 요청 세부 사항을 빠짐없이 기록하고 감사 추적을 가능케 하는 기능
      • 특징/이점: 누가, 언제, 어떤 데이터에 액세스했는지에 대한 동작 투명성을 완벽히 확보함
    • 암호화 (Encryption)
      • 정의: 보안 표준을 준수하고 데이터의 기밀 유지를 위해 저장/전송되는 모든 패킷을 암호로 감싸 보호하는 기술
      • 특징/이점
        • 저장 데이터 암호화 (Encryption at Rest): 버킷 디스크에 영구 적재된 데이터 객체를 원천 암호화해 비인가 액세스 및 탈취로부터 보호함
        • 전송 중 암호화 (Encryption in Transit): 클라이언트와 S3 서비스 간 통신 구간을 안전하게 암호화하여 통신 도중 데이터가 변조되거나 스니핑당하는 것을 원천 방지함

Amazon S3 스토리지 클래스 및 S3 수명 주기

• S3 스토리지 클래스 (S3 Storage Classes) 개요
  • 정의
    • 서로 다른 성능, 데이터 액세스 빈도, 복원력, 비용 요구사항을 가진 다양한 워크로드에 맞춰 데이터를 최적의 등급으로 보존하는 S3 저장소 구분 티어
  • 특징/이점
    • 단일 S3 버킷 내에서도 데이터의 활용 양상에 맞게 객체별로 여러 스토리지 클래스를 독립 지정해 조합할 수 있어 극대화된 비용 절감을 실현함
• S3 스토리지 클래스별 핵심 세부 내용
  • S3 Standard
    • 정의: 정기적이고 빈번하게 액세스하는 정적/동적 데이터를 위한 기본 범용 스토리지 클래스
    • 특징/이점: 짧은 지연 시간, 높은 처리량 및 빠른 검색 속도를 저렴한 스토리지 요금으로 제공하며 클래스 미지정 시 기본 할당됨 (예: 클라우드 앱, 동적 웹, 게임, 모바일, 빅데이터 분석)
  • S3 Intelligent-Tiering
    • 정의: 데이터의 액세스 패턴을 알 수 없거나 변동성이 큰 경우, 액세스 빈도에 맞춰 티어 간에 데이터를 자동 이관하는 스토리지 클래스
    • 특징/이점: Frequent Access, Infrequent Access, Archive Instance Access 티어 간의 모니터링 및 데이터 물리적 이관을 AWS가 대행하여 수작업 오버헤드와 추가 관리 공수 없이 비용을 최적화함 (예: 데이터 레이크, 대규모 데이터세트)
  • S3 Standard-IA (Standard-Infrequent Access)
    • 정의: 액세스 빈도는 낮지만 필요할 때 몇 밀리초(실시간) 내로 빠르게 데이터를 가져와야 하는 워크로드를 위한 스토리지 등급
    • 특징/이점: Standard의 지연 시간 및 내구성을 유지하되, 스토리지 요금을 GiB당 저렴하게 제공하며 대신 검색 요금이 부과됨 (예: 장기 백업, 재해 복구용 복제 데이터)
  • S3 One Zone-IA (One Zone-Infrequent Access)
    • 정의: 데이터를 3개 이상의 가용 영역(AZ)에 다중 분산 저장하는 Standard-IA와 달리 단 하나의 가용 영역에만 저장하여 비용을 대폭 절감한 스토리지 클래스
    • 특징/이점: Standard-IA 대비 약 20%의 비용을 절감하나 가용 영역 손실 시 데이터 유실에 취약하므로 보조 백업이나 재생성 가능한 로컬 데이터 적재에 적합함
  • S3 Express One Zone
    • 정의: 초저지연 및 고성능 요구사항이 요구되는 빈번한 액세스용 데이터를 단일 가용 영역에 분산 저장하는 특수 목적 스토리지 클래스
    • 특징/이점: 10밀리초 미만의 매우 일관된 초저지연 데이터 액세스를 보장하며, Standard 대비 액세스 속도는 최대 10배 더 빠르고 요청 처리 요금은 최대 80% 더 절약됨
  • S3 Glacier Instant Retrieval
    • 정의: 1년에 몇 번 수준으로 드물게 액세스하지만 요청 즉시(몇 밀리초 내) 빠른 응답을 받아야 하는 아카이브 전용 스토리지 클래스
    • 특징/이점: Standard-IA 스토리지 클래스와 비교하여 최대 68%의 스토리지 비용을 절감하면서도 동일한 밀리초 단위 지연 시간 및 처리성능을 그대로 보장함 (예: 의료 영상, 보관용 미디어 자산)
  • S3 Glacier Flexible Retrieval
    • 정의: 1년에 한두 번 정도로 거의 액세스하지 않지만 저렴한 아카이브 및 간헐적인 분 단위 백업 복원을 요구하는 데이터 보관 클래스
    • 특징/이점: Standard 및 Instant Retrieval 대비 비용이 현격히 낮으며, 신속 검색(15분)부터 대량 검색(512시간, 추가 비용 없음) 옵션을 탄력적으로 제공함 (예: 비실시간 재해 복구, 장기 오프사이트 백업)
  • S3 Glacier Deep Archive
    • 정의: 7~10년 이상 장기 보존해야 하며 거의 액세스하지 않는 디지털 원본 데이터 보존용 최저가 스토리지 클래스
    • 특징/이점: S3 내에서 스토리지 단가가 가장 저렴하며, 데이터 검색 및 복원에는 기본 12시간이 소요됨 (예: 금융, 의료, 공공 등 규제 산업의 의무 컴플라이언스 아카이브)
  • S3 Outposts
    • 정의: 온프레미스의 AWS Outposts 환경에 S3 API 및 관리 기능을 제공하여 로컬 데이터 상주 요건을 충족시키는 하이브리드 스토리지 클래스
    • 특징/이점: 데이터를 기업의 로컬 물리 서버 근처에 유지해 초고속 통신 성능 및 현지 규정 준수를 동시에 만족함
• S3 수명 주기 (S3 Lifecycle) 및 비용 관리
  • S3 수명 주기 정책 (S3 Lifecycle Policies)
    • 정의: 수동 관리 오버헤드를 없애기 위해 미리 정해진 일수 기준 규칙에 따라 데이터의 스토리지 클래스 전환 또는 영구 파기를 자동으로 처리하는 구성 규칙
    • 작업 유형
      • 전환 작업 (Transition Actions): 생성일 기준 특정 기간이 지났을 때 덜 활성화된 경제적 스토리지 클래스로 객체를 이관하는 동작 (예: 30일 후 Standard-IA로 전환, 60일 후 Glacier Instant Retrieval로 전환 등)
      • 만료 작업 (Expiration Actions): 생성일 기준 특정 기한을 경과한 객체를 S3 버킷에서 안전하게 영구 자동 삭제하는 동작 (예: 365일 후 완전 파기)
    • 대표 사용 사례
      • 주기적 로그 관리: 버킷에 정기 자동 적재되는 애플리케이션 로그는 단기간(한 주~한 달) 보관 후 더 이상 쓰지 않으므로 만료 처리를 통해 자동 소멸시킴
      • 액세스 패턴 변화 문서: 가입 서류 등 최초 보관 후 몇 달 뒤부턴 볼 일이 없는 문서를 실시간 스토리지에서 내리고 규정에 부합하는 장기 아카이브(Glacier)로 전환 후 일정 연도 경과 시 최종 삭제함
  • S3 스토리지 클래스 분석 (S3 Storage Class Analysis)
    • 정의: S3 버킷 내 데이터의 액세스 트렌드 및 활동 패턴을 상시 관측하는 분석 도구
    • 특징/이점: 사용자가 데이터를 더 효율적이고 저렴한 하위 클래스로 이동해야 할 최적의 임계 시점(일수 기준)을 정확히 결정하도록 의사결정 인사이트를 도출함

Amazon S3 스토리지 클래스 한눈에 보기

아키텍트 관점에서의 핵심 요약

1. 지연 시간(Latency)의 기준: Glacier Instant Retrieval까지는 저렴한 아카이브 등급임에도 불구하고 밀리초(ms) 단위의 실시간 접근을 보장합니다. 반면, Flexible Retrieval부터는 데이터를 '녹여서 꺼내는(Restore)' 비실시간 프로세스가 필요합니다.
2. 비용 최적화의 치트키: 데이터의 라이프사이클을 정확히 모를 때는 S3 Intelligent-Tiering을 선택하는 것이 수작업 공수(Overhead)를 줄이는 가장 좋은 대안입니다.
3. 가용성 보장 유무: One Zone이 붙은 클래스(One Zone-IA, Express One Zone)는 단 하나의 AZ에만 데이터를 두기 때문에, 인프라 장애 시 데이터가 유실될 수 있어 반드시 재생성 가능하거나 별도 복제본이 있는 데이터에만 사용해야 합니다.

Amazon S3 데모

• Amazon S3 버킷 및 객체 생성 기본 프로세스
  • S3 버킷 생성 (S3 Bucket Creation)
    • 정의
      • 전 세계 모든 AWS 계정을 통틀어 유일한 버킷 이름을 설정하고, 데이터가 물리적으로 위치할 AWS 리전을 결정하여 저장 장소를 개설하는 절차
    • 특징/이점
      • 생성 단계에서 퍼블릭 액세스 차단(Block all public access) 설정을 활성화해 버킷과 콘텐츠의 외부 무단 노출을 기본 방어함
      • 생성된 버킷 내부에 가상의 폴더를 만들어 데이터의 논리 구조를 수립하며, 암호화 옵션을 적용해 보안을 강화함
  • S3 객체 업로드 및 메타데이터 구성 (Object Upload & Metadata)
    • 정의
      • 로컬 환경에 저장된 파일이나 폴더를 S3의 버킷 또는 하위 폴더로 전송해 객체화하는 프로세스
    • 특징/이점
      • 계층 구조 유지: 드래그 앤 드롭(Drag and Drop) 업로드를 통해 로컬의 다층 폴더 구조를 붕괴시키지 않고 S3 내에 그대로 재현하여 업로드함
      • 시스템 정의 메타데이터: 파일의 크기, 생성 일시, 스토리지 클래스 등 기본적인 상세 속성 정보가 업로드 시점에 자동 기록됨
      • 사용자 정의 메타데이터: 객체 분류 및 인식을 돕기 위해 사용자가 직접 임의의 태그나 메타데이터 속성을 키-값 형태로 부착할 수 있음
      • 업로드 채널 다양화: 웹 콘솔 외에도 CLI(Command Line Interface)나 SDK를 사용한 코딩 기반 일괄/대용량 전송이 가능함
• S3 버킷 수준 및 객체 수준 관리 기능
  • 버킷 수준 관리 및 설정 탭 (Bucket-level Configurations)
    • 정의
      • 개별 버킷 전체 및 그 하위의 모든 파일 그룹에 영향을 주는 거버넌스 및 구성을 설정하는 제어 영역
    • 주요 탭 구성
      • 속성 (Properties) 탭: 객체 버전 관리(Versioning) 사용 여부, 검색 최적화용 태그, 기본 서버 측 암호화, Intelligent-Tiering 아카이브 및 정적 웹 사이트 호스팅 활성화를 제어함
      • 권한 (Permissions) 탭: 퍼블릭 액세스 차단 스위치, 리소스 제어용 버킷 정책(Bucket Policy), 객체 소유권(Object Ownership), 교차 출처 리소스 공유(CORS) 규칙을 제정함
      • 관리 (Management) 탭: 수명 주기(Lifecycle) 규칙, 타 리전으로의 복제(Replication) 구성, 정기 버킷 분석을 위한 인벤토리(Inventory) 수정을 담당함
  • 객체 수준 관리 및 설정 (Object-level Configurations)
    • 정의
      • 버킷 내에 기 저장된 개별 파일 단위로 속성을 조회하고 전용 정책을 부여하는 관리 영역
    • 주요 제어 사항
      • 객체 개요: 고유 객체 URL 주소를 제공하며, 버킷의 퍼블릭 액세스가 해제되고 권한이 승인된 경우 전 세계 누구나 URL을 통해 파일에 직접 연결할 수 있음
      • 객체 속성 세부 정보: 개별 파일 단위의 스토리지 클래스 전환, 실시간 암호화 셋팅, 데이터 위변조를 검증하는 체크섬(Checksum), 객체 잠금(Object Lock) 등을 설정함
      • 버전 관리 (Versions) 탭: 동일 키에 대한 모든 과거 빌드 목록을 추적하여 원하는 백업 시점으로 복원하거나 불필요한 버전의 영구 삭제를 개별 조율함
• JSON 기반 S3 버킷 정책 분석 (S3 Bucket Policy Anatomy)
  • 정의
    • JSON 규격을 채택하여 버킷 리소스 및 그 하위 객체들의 상세 읽기/쓰기 권한을 선언적으로 규정하는 리소스 기반 정책 문서
  • JSON 정책의 5대 핵심 요소
    • Effect (효과): 요청된 API 작업에 대해 최종적으로 허용(Allow)할지 거부(Deny)할지 정의함
    • Principal (보안 주체): 버킷 및 객체 액세스를 허가받거나 제한받을 대상이 되는 AWS 계정 ID 번호, IAM 사용자, 혹은 역할(Role)을 지정함
    • Action (작업): 본 정책의 효과가 작동될 구체적인 S3 API 서비스 액션을 선언함 (예: 크로스 계정 객체 적재를 위한 s3:PutObject 등)
    • Resource (리소스): 본 정책이 권한을 미칠 대상 S3 버킷 및 버킷 내 경로의 ARN 주소를 지정함
    • Condition (조건): 정책의 허용 여부가 발동되기 위한 논리적 조건식을 명시함 (예: 크로스 계정 업로드 시 객체 소유권 메타데이터가 명확히 지정되고 조건에 부합할 때만 작업을 활성화하는 제약 등)

파일 스토리지

Amazon Elastic File System(Amazon EFS)

• Amazon Elastic File System(EFS) 개요
  • 정의
    • AWS 클라우드 리소스 및 온프레미스 리소스에서 동시 연결하여 사용할 수 있는 리눅스(Linux)용 확장 가능한 완전관리형 네트워크 파일 스토리지 서비스
  • 작동 프로토콜
    • 리눅스 표준인 NFS(Network File System) 프로토콜을 사용해 가동됨
  • 특징/이점
    • 용량 사전 설계나 백업 및 이중화 관리를 AWS가 전담하므로 스토리지 용량 부족 또는 관리 부담이 없음
    • 데이터를 추가하거나 제거할 때마다 스토리지 규모가 자동으로 페타바이트 단위까지 자동 확장 및 축소되어 유연함
• Amazon EFS의 주요 이점 (Benefits)
  • 다중 AZ 이중화 및 고가용성
    • 정의: 리전 내 다중 가용 영역(AZ)에 데이터를 안전하게 자동 복제하여 데이터 유실과 AZ 레벨 장애에 대응하는 구조
    • 특징/이점: 단일 가용 영역 장애 시에도 데이터 손실 없이 파일 시스템에 대한 액세스를 상시 안정적으로 보장함
  • 동시 공유 액세스 (Shared Access)
    • 정의: 수천 개의 동시 NFS 연결을 허용하여 다수의 가상 컴퓨터가 동일 스토리지를 공동 점유하는 구조
    • 특징/이점: 여러 EC2 인스턴스가 동일 파일 시스템에 실시간으로 동시 읽기/쓰기를 처리할 수 있어 협업 및 분산 애플리케이션 분석에 최적임
  • 탄력적 스토리지 및 비용 최적화
    • 정의: 볼륨 크기 프로비저닝 없이 실제 적재된 용량에 대해서만 비용을 사후 지불하는 요금제
    • 특징/이점: 불필요한 스토리지 점유 낭비를 완전히 없애고 데이터 세트의 변동에 경제적으로 대응함
• EBS vs EFS 상세 비교 분석
  • 가용성 및 위치 제약
    • EBS: 가용 영역(AZ) 수준의 리소스이므로 마운트하려는 EC2 인스턴스와 반드시 동일한 AZ 내에 배치되어야 함
    • EFS: 리전(Region) 수준의 리소스이므로 리전 전역 및 타 리전의 가상 인스턴스들과도 네트워크로 자유롭게 연동이 가능함
  • 동시 연결성
    • EBS: 단일 인스턴스에 물리 연결되는 로컬 가상 하드 디스크 구조를 가짐
    • EFS: 다중 가용 영역의 수천 개 인스턴스가 동시에 1개의 EFS 파일 시스템에 붙어 대량 읽기/쓰기가 가능함
  • 용량 스케일링 유연성
    • EBS: 생성 시 볼륨 용량(예: 2TB)을 고정 할당해야 하며, 한도가 차도 시스템이 자동으로 디스크 용량을 늘려주지 않음
    • EFS: 볼륨 크기 제한이 없으며 데이터 파일 추가/삭제에 따라 즉시 실시간으로 자동 조절됨
  • EBS vs EFS 핵심 비교 요약표

• Amazon EFS 데이터 수명 주기 정책 (EFS Lifecycle Policies)
  • 정의
    • 수동 작업을 완전히 없애고 액세스 빈도가 떨어진 파일을 저가형 클래스로 자동 이송 및 관리하는 파일 수명 주기 자동화 기능
  • 수명 주기 정책 규칙 세부 옵션
    • IA(Infrequent Access)로 전환
      • 정의: 분기별로 몇 번만 조회하는 저빈도 데이터를 보관하는 IA 등급으로 파일을 이송하는 정책
      • 기준: Standard 스토리지에 보관된 파일 중 기본 설정값인 30일 동안 액세스가 확인되지 않으면 IA 등급으로 이동함
    • Archive로 전환
      • 정의: 1년에 단 몇 번 정도 조회하는 콜드 데이터를 보관하는 극도의 저비용 아카이브 등급으로 파일을 이송하는 정책
      • 기준: Standard 스토리지에 보관된 파일 중 기본 설정값인 90일 동안 액세스가 발생하지 않으면 Archive 등급으로 이동함
    • Standard로 전환
      • 정의: IA 또는 Archive에 이관된 파일을 다시 읽거나 수정할 때 고성능 기본 Standard 클래스로 다시 승급(롤업)시킬지 여부를 규정하는 정책
      • 기준: 기본적으로 Standard 자동 복귀 정책은 비활성화(Standard로 전환하지 않음) 상태이며, 액세스가 발생하더라도 IA 및 Archive 클래스에 그대로 유지되어 무분별한 비용 인상을 사전 예방함
• Amazon EFS 스토리지 클래스 (Storage Classes)
  • Standard 스토리지 클래스 (EFS Standard & Standard-IA)
    • 정의: 3개 이상의 가용 영역(AZ)에 데이터를 실시간 다중 복제하여 극대화된 가용성을 제공하는 클래스
    • 특징/이점: 높은 물리적 복제 비용으로 인해 기본 스토리지 보존 단가가 One Zone에 비해 상대적으로 비쌈
  • One Zone 스토리지 클래스 (EFS One Zone & One Zone-IA)
    • 정의: 데이터를 단 1개의 지정된 가용 영역(AZ) 내부 시설에만 저장하는 비용 최적화 클래스
    • 특징/이점: 이중화 인프라를 단일 AZ로 좁혀 Standard 등급 대비 큰 폭의 추가 스토리지 비용 절감을 실현함
  • Archive 스토리지 클래스 (EFS Archive)
    • 정의: 1년에 단 몇 번만 조회하며 밀리초 미만의 반응 지연 시간이 필요하지 않은 데이터 보존용 최저가 등급
    • 특징/이점: 기존 Infrequent Access(IA) 등급과 비교하여도 최대 50% 추가 절감된 극강의 비용 최적화 혜택을 제공함

Amazon FSx

• Amazon FSx 개요
  • 정의
    • 타사 전문 파일 시스템 엔진을 AWS 기반에서 고성능이면서 비용 효율적으로 손쉽게 가동할 수 있도록 하드웨어 프로비저닝, 패치, 백업 등을 자동화해 주는 완전관리형 파일 스토리지 서비스
  • Amazon EFS와의 차이점
    • Amazon EFS: 리눅스 환경과 호환되는 NFS(Network File System) 프로토콜 전용으로 가동됨
    • Amazon FSx: Windows File Server, Lustre, OpenZFS, NetApp ONTAP 등 다양한 상용 및 오픈소스 파일 시스템 프로토콜을 광범위하게 지원함
• Amazon FSx의 주요 이점 (Benefits)
  • 파일 시스템 통합
    • 정의: 업계 표준 파일 시스템 프로토콜을 그대로 제공하여 기존 인프라 환경과의 고도화된 연동을 돕는 기능
    • 특징/이점: 기존 기업 애플리케이션, 워크플로, 개발 도구 등의 소스 코드를 수정하지 않고도 클라우드 스토리지로 원활하게 마운트해 통합할 수 있음
  • 관리형 인프라
    • 정의: 기존 파일 시스템의 고급 성능 및 데이터 관리 특성(예: 중복 제거, 압축 등)은 그대로 보존하면서 인프라 유지관리 부담을 제거하는 기능
    • 특징/이점: 서버 하드웨어 관리, 패치 적용, 스토리지 이중화 구성 등의 복잡성을 AWS가 전담하므로 운영 부담이 대폭 줄어듦
  • 확장 가능한 스토리지
    • 정의: 기업 워크로드 요구량에 맞춰 용량과 처리 성능 리소스를 동적으로 신속하게 조정해 주는 기능
    • 특징/이점: 시스템 가동 전에 복잡한 용량 한도 설계나 수동 인프라 증설 작업이 요구되지 않아 유연함
  • 비용 효율성
    • 정의: 실사용 용량 기준 과금 정책 및 수명 주기에 맞춰 오래된 데이터를 저비용 등급으로 내리는 스마트 최적화 모델
    • 특징/이점: 자주 액세스하지 않는 콜드 데이터를 저렴한 등급으로 자동 티어링하는 옵션을 지원하여 총 소유 비용(TCO)을 획기적으로 감축함
• Amazon FSx 파일 시스템 유형 및 사용 사례
  • Amazon FSx for Windows File Server
    • 정의: Windows Server 플랫폼을 바탕으로 가동되어 Active Directory 연동 및 NTFS 권한 제어 등 풍부한 기능군을 지원하는 완전관리형 Windows 공유 파일 시스템
    • 주요 사용 사례
      • 온프레미스의 Windows 기반 파일 서버 환경을 무손실로 AWS에 마그네이션할 때 적합함
      • SQL Server 클러스터 배포 비용을 대폭 절감하고 대규모 공유 스토리지 볼륨을 제공함
      • 가상 데스크톱(VDI) 환경의 프로필 보존 및 스트리밍 워크로드 구성을 간소화함
  • Amazon FSx for NetApp ONTAP
    • 정의: 업계 표준의 데이터 관리 소프트웨어인 NetApp ONTAP 솔루션을 AWS 클라우드 내부로 이식한 완전관리형 다중 프로토콜 공유 스토리지
    • 주요 사용 사례
      • 기존 NetApp 스토리지를 사용하던 온프레미스 워크로드를 구조 변경 없이 손쉽게 AWS로 이관함
      • 현대적인 컨테이너/서버리스 클라우드 애플리케이션의 신뢰성 높은 공유 파일 시스템을 개설함
      • 스냅샷 복제, 재해 복구(DR) 연동, 백업 정책 자동화 등 기업 데이터 관리 체계를 대대적으로 현대화함
  • Amazon FSx for OpenZFS
    • 정의: 오픈소스 OpenZFS 파일 시스템을 완전관리형으로 제공하며 고속 NFS 프로토콜(v3, v4, v4.1, v4.2)을 통해 다중 접근을 보장하는 스토리지
    • 주요 사용 사례
      • 기존 NFS 데이터베이스 환경의 무중단 클라우드 이전을 추진함
      • 초고속 파일 입출력을 요구하는 실시간 데이터 분석 워크로드에 인사이트 도출 속도를 지원함
      • 대규모 콘텐츠 관리 시스템(CMS) 가속화 및 개발/테스트용 고속 임시 파일 시스템 가동
  • Amazon FSx for Lustre
    • 정의: 초대형 병렬 입출력 및 무제한에 가까운 성능 확장성을 자랑하는 고성능 오픈소스 Lustre 파일 시스템을 탑재한 완전관리형 스토리지
    • 주요 사용 사례
      • 기계 학습(ML) 및 딥러닝 트레이닝 모델 적재 가속화
      • 고성능 컴퓨팅(HPC) 클러스터의 공유 스크래치 드라이브 구축
      • 페타바이트급 빅데이터 분석 성능 지원 및 대용량 미디어 렌더링/편집 워크로드 민첩성 강화

추가 스토리지 솔루션

AWS Storage Gateway

• AWS Storage Gateway 개요
  • 정의
    • 온프레미스 환경의 애플리케이션 및 시스템을 무제한의 AWS 클라우드 스토리지 리소스와 원활히 연동해 주는 하이브리드 클라우드 스토리지 서비스
  • 핵심 메커니즘
    • 온프레미스의 로컬 데이터 액세스 시 초저지연 성능을 유지하면서, 자주 쓰이지 않는 데이터를 클라우드로 확장 저장해 스토리지 관리를 간소화함
• AWS Storage Gateway의 주요 이점 (Benefits)
  • 원활한 하이브리드 통합
    • 정의: 온프레미스 애플리케이션과 AWS 클라우드 스토리지 사이를 투명하게 연결하는 기능
    • 특징/이점: 기존 온프레미스 워크플로와 운영 환경을 전면 재작업 없이 그대로 보존하면서 시스템 중단을 최소화함
  • 로컬 캐싱 (Local Caching)
    • 정의: 최근에 사용된 핫(Hot) 데이터를 온프레미스 게이트웨이 로컬 저장소에 상시 유지하는 기능
    • 특징/이점: 빠른 로컬 데이터 읽기 속도를 제공하는 동시에, 사용 빈도가 낮은 데이터만 클라우드로 격리 적재해 디스크 비용을 감축함
  • 중앙 집중식 데이터 관리 개선
    • 정의: 하이브리드 스토리지 전반의 관제를 단일 지점에서 통제하는 기능
    • 특징/이점: 데이터 접근성, 보안 모니터링 및 보안 규정 준수(Compliance)를 일률적으로 관리함
  • 비용 최적화
    • 정의: 온프레미스 장비의 물리적 확장 대신 클라우드 스토리지를 대용량 저장소로 활용하는 요금 모델
    • 특징/이점: 데이터 아카이빙, 백업, 재해 복구(DR) 비용을 클라우드로 전가해 온프레미스 디스크 구매 및 유지 관리 비용을 절감함
• AWS Storage Gateway의 3가지 주요 게이트웨이 유형
  • Amazon S3 File Gateway
    • 정의: 온프레미스 환경에 표준 파일 서버(NFS/SMB) 인터페이스를 제공하여 Amazon S3 객체 스토리지에 파일 형태로 연결하는 게이트웨이
    • 특징/이점
      • 파일 전송 시 자동으로 S3 객체로 저장되며, 지능형 로컬 캐싱을 적용해 정기 사용 데이터의 로컬 읽기를 지원함
      • S3에 적재된 파일은 타 AWS 서비스나 분석 애플리케이션에서 직접 파싱 및 연결이 가능함
  • Volume Gateway
    • 정의: 온프레미스 애플리케이션에 가상 iSCSI 블록 스토리지 볼륨을 제공하며, 데이터를 Amazon EBS 스냅샷 형태로 클라우드에 백업하는 게이트웨이
    • 작동 방식 (2가지 구성 모드)
      • 캐시 볼륨 (Cached Volumes) 모드: 전체 원본 데이터는 Amazon S3 클라우드에 적재하고, 최근 자주 조회한 핫 데이터만 로컬에 캐시하여 지연시간을 단축함
      • 저장 볼륨 (Stored Volumes) 모드: 전체 데이터 세트 원본을 온프레미스 로컬 스토리지에 보존하면서, EBS 스냅샷 형태로 클라우드에 비동기 백업함
  • Tape Gateway
    • 정의: 온프레미스의 물리적 테이프 백업 장비 인프라를 AWS 클라우드 기반의 가상 테이프(Virtual Tape) 인프라로 대체하는 게이트웨이
    • 특징/이점
      • 백업 소프트웨어에는 물리 테이프 라이브러리로 인식되므로 기존 백업 소프트웨어 및 워크플로의 수정이 필요 없음
      • 데이터를 가상 테이프 형식으로 Amazon S3에 저장하며, 오래된 데이터는 S3 Glacier 등 저렴한 아카이브 스토리지 클래스로 자동 이관 가능함
• 주요 실제 활용 사례
  • 재해 복구 (Disaster Recovery): 기존 백업 아키텍처를 고치지 않고 클라우드에 정기 비동기 이중 사본을 백업하여 장애 복구력 강화
  • 장기 데이터 아카이빙: 액세스 빈도가 낮은 데이터를 클라우드로 밀어내어 온프레미스 스토리지 공간 확보
  • 클라우드 여정의 진입점: 시스템 전면 교체 부담 없이 안전하게 백업 영역부터 하이브리드로 클라우드를 도입함

AWS Elastic Disaster Recovery

• AWS Elastic Disaster Recovery 개요
  • 정의
    • 장애 발생 시 가동 중지 시간(Downtime)과 데이터 유실(RPO)을 최소화하도록 온프레미스 및 타 클라우드의 물리적/가상 서버의 블록 수준 데이터를 AWS로 지속 복제하고 신속한 복원 인스턴스를 가동해 주는 완전관리형 재해 복구(DR) 서비스
  • 핵심 지원 범위
    • 온프레미스 물리적 서버(Physical Server), 가상 머신(Virtual Server), 그리고 여타 클라우드 환경의 핵심 워크로드를 전면 지원함
• AWS Elastic Disaster Recovery의 주요 이점 (Benefits)
  • 비즈니스 연속성 및 복원력 강화 (Business Resilience)
    • 정의: 블록 레벨의 실시간 비동기 지속 복제를 통해 중단 발생 시 수 분(Minutes) 이내에 워크로드를 원복하는 기능
    • 특징/이점: 시스템 가동 중단 시 발생하는 비즈니스 손실과 데이터 유실을 최소화하여 고가용성을 유지함
  • 재해 복구 관리 간소화 (Simplified DR)
    • 정의: 직관적인 웹 콘솔 인터페이스를 통해 복잡한 복구 자동화 절차를 셋팅하고 관리하는 기능
    • 특징/이점: 수동 복구 세팅의 복잡성을 제거하고, 비상 상황 시 발생할 수 있는 인적 장애 및 수동 입력 실수의 위험을 원천 차단함
  • 비용 최적화 (Cost Optimization)
    • 정의: 2차 물리 데이터 센터를 상시 대기 가동하지 않고 필요한 시점에만 스토리지 및 컴퓨팅 자원을 할당받는 모델
    • 특징/이점: 고비용의 보조 데이터 센터 유지비와 사전 디스크 자산 투자 비용을 없애고, 실제 비상 상황 및 테스트 복원 시에만 사용량 사후 과금 방식을 적용함
  • 무중단 재해 복구 테스트 (Non-disruptive Testing)
    • 정의: 현재 온프레미스에서 실시간 가동 중인 운영 시스템에 영향을 주지 않고 복구 인스턴스를 독립 기동해 검증하는 기능
    • 특징/이점: 정기적인 장애 조치(Failover) 테스트를 수월하게 집행하여 비상시 신속 복구 전략의 작동성을 사전에 완벽히 보증받음
• 업종별 주요 실제 사용 사례 (Use Cases)
  • 의료 데이터 보호 (Healthcare Data Protection)
    • 적용 내용: 병원 시스템의 온프레미스 환자 기록 서버를 AWS로 지속 복제함
    • 특징/이점: 온프레미스 시스템 장애 시에도 의료 데이터에 끊김 없이 지속 접근할 수 있도록 가용성을 확보하며, 정기 복구 테스트로 엄격한 의료 법적 규정(Compliance)을 준수함
  • 금융 서비스 연속성 (Financial Services Continuity)
    • 적용 내용: 지역 은행의 실시간 거래 처리 시스템 및 핵심 뱅킹 애플리케이션을 AWS로 무중단 지속 복제함
    • 특징/이점: 메인 데이터 센터가 실패해도 수 분 내 신속히 복구하여 금융 거래 마비를 방지하고, 고객 신뢰와 법적 규제를 충족함
  • 제조 운영 복구 (Manufacturing Operations Recovery)
    • 적용 내용: 글로벌 제조업체의 공장 관리 및 생산 계획 시스템 서버를 AWS로 비동기 복제함
    • 특징/이점: 재해 발생 시 공급망(Supply Chain) 단절 및 공장 가동 중단을 최소화하며, 정기적인 장애 조치 테스트로 복구 전략을 상시 검증함

실제 환경에서의 클라우드

스토리지 서비스 비교

• 실제 비즈니스 시나리오별 스토리지 서비스 선택 기준

  • 시나리오 1: 커피숍 (S3 기반 정적 웹 사이트 호스팅)
    • 비즈니스 상황: 커피숍 웹 사이트에 적재되는 대량의 이미지, HTML, CSS, JS 정적 자산을 유연하게 수용해야 함
    • 선택 서비스: Amazon S3
    • 채택 이유 및 이점
      • HTML, CSS, JavaScript, 미디어 파일을 버킷에 업로드 후 정적 웹 호스팅 옵션을 활성화하는 것만으로 손쉽게 웹 사이트를 배포함
      • 트래픽이 폭발적으로 급증해도 사용자의 개입이나 별도 스케일링 설정 없이 인프라가 자동으로 무한 스케일 조절됨
      • 실제로 사용한 스토리지 용량과 버킷 외부로 전송된 아웃바운드 데이터에 대해서만 과금되므로 비용 효율성이 매우 뛰어남
  • 시나리오 2: 피트니스 센터 모바일 앱 (EBS 기반 데이터베이스 최적화)
    • 비즈니스 상황: 수업 예약 모바일 앱의 트래픽 급증으로 관계형 데이터베이스(DB)에서 읽기/쓰기 지연 시간 병목 발생
    • 선택 서비스: Amazon EBS (특히 프로비저닝된 IOPS SSD 볼륨)
    • S3 대신 EBS를 채택한 이유 및 이점
      • S3 객체 스토리지는 비정형 데이터에 적합하며, 데이터베이스에 필수적인 빠르고 연속적인 초저지연 읽기/쓰기 작업을 수용하도록 설계되지 않음
      • EBS는 데이터베이스에 필수적인 블록 수준 액세스(Block-level Access)를 제공하여 트랜잭션 입출력 워크로드를 일관되게 지원함
      • 고성능 프로비저닝된 IOPS SSD(io1/io2 등) 볼륨으로 마이그레이션하여 짧은 지연 시간과 강력한 입출력 속도를 즉시 확보함
  • 시나리오 3: 자동차 정비소 브랜드 (EFS 기반 공유 기술 지식 플랫폼)
    • 비즈니스 상황: 다수 지점의 정비 기사들이 다양한 디바이스와 위치에서 고해상도 이미지, 동영상, 기술 다이어그램에 동시 접속 및 공유함
    • 선택 서비스: Amazon EFS
    • 채택 이유 및 이점
      • 다수의 위치와 다양한 디바이스에서 동일한 파일 및 디렉토리 구조로 공동 접속하므로 공유 파일 시스템 형태가 필수적임
      • 대용량 미디어 자산을 업로드/삭제할 때 서비스 중단 없이 페타바이트 규모까지 자동으로 확장 및 축소됨
      • 높은 집계 처리량(Throughput)과 짧은 지연 시간을 지원하여 고해상도 미디어 처리 및 실시간 동시 협업 워크플로에 최적임

• AWS 3대 핵심 스토리지 요약 비교

  • Amazon S3: 웹 자산, 데이터 레이크, 백업 및 아카이빙을 위한 무한 확장 가능한 완전관리형 객체 스토리지
  • Amazon EBS: EC2 인스턴스 부팅 및 데이터베이스(DB)를 위한 고성능 트랜잭션 전용 블록 스토리지
  • Amazon EFS: 여러 컴퓨팅 서버 간 파일의 실시간 동시 액세스가 필요한 워크로드를 위한 완전관리형 공유 파일 스토리지

• AWS 3대 핵심 스토리지 실무 선택 가이드표

• mattpocock/skills는 TypeScript 교육자 Matt Pocock이 만든 에이전트 스킬 38개 모음. 스킬은 코드가 아니라 에이전트에게 주입되는 작업 절차 지침서(SKILL.md)
• 저장소 공식 분류 기준으로 engineering 16개 / productivity 5개 / misc 4개 / personal 2개 / in-progress 7개 / deprecated 4개. 즉 실전용은 절반 정도, 나머지는 실험작·개인용·폐기
• code-review 스킬로 통제된 A/B 테스트 진행. 결론: 버그 탐지력 향상이 아니라(탐지율 무승부), 리뷰 프로세스의 구조화·감사가능성·재현성 확보
• 핵심 방법론 스킬은 언어 중립이라 Go/Python 프로젝트에도 그대로 적용 가능. 단 3개(misc 카테고리)는 TS/Node 툴링이 전제

1. mattpocock/skills 소개

Matt Pocock은 Total TypeScript로 유명한 TS 교육자인데, 이 저장소는 TS 강의가 아니라 "AI 에이전트로 실제 엔지니어링을 할 때 반복적으로 망가지는 지점"을 잡기 위한 스킬 모음. README가 꼽는 4가지 실패 모드:

1. 정합성 붕괴(Misalignment) — 개발자가 원한 것과 에이전트가 만든 것의 괴리
2. 장황한 출력(Verbose output) — 도메인 용어 없이 장황하기만 한 결과물
3. 동작하지 않는 코드 — 피드백 루프 부재
4. 아키텍처 붕괴 — AI로 빨리 짜다 구조가 썩는 것

각 실패 모드에 대응하는 스킬: 인터뷰로 요구사항을 못 박는 grilling, 도메인 용어를 강제하는 domain-modeling, 피드백 루프를 먼저 만드는 tdd/diagnosing-bugs, 깊은 모듈 설계를 유도하는 codebase-design 등.

2. 스킬이란 — SKILL.md 한 장이 전부다

각 스킬은 실행 파일이 아니라 마크다운 지침서 한 장. 프론트매터(name, description)와 본문(작업 절차, 판단 기준, 금지사항)으로 구성. 호출 시 이 내용이 에이전트 컨텍스트에 주입되고, 에이전트는 그 절차대로 동작.

호출 방식은 스킬마다 두 갈래:

• 자동 호출 가능 (18개) — 프론트매터에 별도 설정이 없으면, 에이전트가 세션 시작 시 description을 읽어두고 요청이 맞으면 알아서 끌어다 사용. "이 버그 진단해줘" → diagnosing-bugs가 자동으로 걸리는 식
• 수동 전용 (20개) — disable-model-invocation: true가 설정된 스킬. 반드시 /이름으로 직접 호출 필요. PRD 작성, 이슈 분해처럼 사용자가 명시적으로 시작하는 워크플로우

참고: "자동"은 보장이 아니라 에이전트의 판단. 확실히 쓰려면 직접 호출이 안전.

3. 설치

# vercel-labs의 skills CLI로 설치 (Claude Code 기준)
npx skills@latest add mattpocock/skills

# 설치 후 Claude Code 재시작 → 최초 1회 설정
/setup-matt-pocock-skills

# 뭘 쓸지 모르겠으면 라우터부터
/ask-matt

설치하면 .claude/skills/에 SKILL.md 저장. 재시작 시 슬래시 명령으로 인식.

설치 시 주의할 점 2가지:

• --all 플래그를 쓰면 Claude Code뿐 아니라 약 48개 타 에이전트 디렉터리(.goose, .cursor, .windsurf...)에 전부 복사. Claude Code만 쓸 땐 그냥 npx skills@latest add mattpocock/skills로 대화형 설치하거나, 설치 후 .claude/와 skills-lock.json만 남기고 정리
• 스킬은 에이전트 전체 권한으로 실행. 낯선 스킬은 SKILL.md를 열어보고 쓰기를 권장

4. 38개 전체 분류

아래 분류는 임의로 나눈 게 아니라 저장소 자체의 디렉터리 구조(skills-lock.json의 skillPath)를 따른 것. 저자 스스로 in-progress(미완성) 7개, deprecated(폐기) 4개, personal(개인용) 2개를 표시해뒀다는 점이 중요 — 그만큼 38개 중 실전 추천 대상은 engineering + productivity를 합친 21개로 좁혀짐.

아래 요약은 38개 SKILL.md 전문을 직접 읽고 작성했고, 표본 5개는 원문 대조 검증까지 진행. [자동] = 자동 호출 가능, [수동] = 수동 전용.

먼저 전체를 한눈에 훑을 수 있는 표부터. 상세 설명은 표 아래 각 소단원에 배치.

4.1 engineering — 핵심 엔지니어링 워크플로우 (16개)

ask-matt [수동] — 이 저장소 스킬 중 뭘 써야 할지 알려주는 라우터.

스킬들을 "flow" 개념으로 정리해서 상황에 맞는 스킬을 안내. 아이디어 다듬기부터 PRD 작성, 이슈 분할, 구현으로 이어지는 메인 플로우와 세션 관리 규칙까지 지도처럼 설명. 38개를 못 외우겠으면 이것만 기억.

code-review [자동] — 고정 지점 이후 diff를 표준·스펙 두 축으로 병렬 리뷰.

git diff <fixed-point>...HEAD를 잡고, Standards(코딩 표준 + Fowler 코드 스멜 12종 체크리스트)와 Spec(원 이슈/PRD 요구사항 충족) 두 서브에이전트를 병렬로 실행. 두 축을 합치거나 재순위화하지 않고 나란히 보고 — 한 축의 통과가 다른 축의 실패를 가리지 않게 하기 위함. 스펙 소스는 커밋 메시지의 이슈 참조 → 사용자 지정 경로 → docs/specs 폴더 순으로 자동 탐색, 없으면 질의. (6장에서 이 스킬로 진행한 A/B 테스트 결과 참고)

codebase-design [자동] — 깊은 모듈 설계를 위한 공유 어휘와 원칙 모음.

module, interface, seam, depth 같은 용어를 정확히 정의하고 일관된 설계 언어를 강제. 작은 인터페이스 뒤에 많은 동작을 숨기는 "깊은 모듈"이 목표. 직접 코드를 고치는 스킬이 아니라 다른 스킬들이 참조하는 어휘 레이어.

diagnosing-bugs [자동] — 어려운 버그를 6단계 진단 루프로 잡는 디버깅 규율.

피드백 루프 구축 → 재현+최소화 → 가설 3~5개 → 계측 → 수정+회귀 테스트 → 포스트모템. 핵심은 1단계: 버그에만 빨간불이 켜지는 빠르고 결정적인 pass/fail 명령을 만들기 전에는 가설조차 금지. "추측으로 고치기"를 구조적으로 차단하는 스킬.

domain-modeling [자동] — 설계 중 용어 사전(CONTEXT.md)과 ADR을 실시간으로 정비.

사용자가 쓰는 용어가 용어집과 충돌하면 즉시 지적, 확정된 용어는 그 자리에서 CONTEXT.md에 반영. ADR은 "되돌리기 어렵고, 맥락 없이는 의아하고, 실제 트레이드오프의 결과"라는 세 조건이 모두 맞을 때만 제안.

grill-with-docs [수동] — 계획을 집요하게 인터뷰하며 ADR과 용어집을 함께 작성.

grilling + domain-modeling 조합 스킬. 인터뷰로 계획을 다듬으면서 그 과정을 문서(ADR, 용어집)로 기록. 코드베이스가 있는 프로젝트면 grill-me 대신 이걸 쓰는 게 메인 플로우.

implement [수동] — PRD나 이슈 기반으로 실제 구현을 진행.

가능하면 사전 합의된 seam에서 tdd 방식으로 진행하고, 타입체크와 테스트를 수시로 실행하며, 완료 후 code-review로 검토 후 커밋. 다른 스킬들이 만든 산출물(PRD, 이슈)을 소비하는 실행 단계.

improve-codebase-architecture [수동] — 코드베이스에서 얕은 모듈을 찾아 리팩터링 후보를 제안.

서브에이전트로 코드베이스를 탐색해 "인터페이스가 구현만큼 복잡한 모듈"을 찾고, 후보별 문제/해결/이점과 before-after 다이어그램이 담긴 HTML 리포트를 생성. 후보를 고르면 grilling으로 설계를 심문.

prototype [자동] — 디자인 질문에 답하기 위한 버리는(throwaway) 프로토타입을 제작.

로직/상태 모델 검증이면 터미널 TUI로 상태 전이를 직접 눌러보게 하고, UI 탐색이면 구조적으로 전혀 다른 변형 3개를 생성. 테스트·에러 처리 없이 제작하며, 질문에 답하면 삭제하거나 검증된 결정만 실제 코드에 흡수.

research [자동] — 백그라운드 에이전트가 1차 출처를 조사해 MD 파일로 기록.

공식 문서, 소스 코드, 스펙 같은 1차 출처만 근거로 삼고 각 주장을 출처까지 추적. 블로그 같은 2차 자료는 근거로 배제. 조사를 위임하고 본인은 계속 작업하는 구조.

resolving-merge-conflicts [자동] — 진행 중인 git merge/rebase 충돌을 끝까지 해결.

충돌의 원 출처(커밋, PR, 이슈)를 읽고 변경 의도를 파악한 뒤, 양쪽 의도를 최대한 보존하는 방향으로 hunk별 해결 → 자동 검사 실행 → 커밋까지 진행. 절대 --abort 하지 않는 방침.

setup-matt-pocock-skills [수동] — 엔지니어링 스킬들이 쓸 저장소별 설정을 초기 세팅.

이슈 트래커(GitHub/GitLab/로컬 마크다운), 트리아지 라벨 어휘, 도메인 문서 레이아웃 세 가지를 사용자와 확인하며 docs/agents/ 아래 설정 문서를 생성. 다른 엔지니어링 스킬 쓰기 전에 저장소당 1회 실행하는 전제 조건.

tdd [자동] — red-green 루프로 남길 가치 있는 테스트를 만드는 TDD 가이드.

실패하는 테스트 하나 → 최소 구현 하나를 반복하는 수직 슬라이스 방식. 테스트는 사전에 사용자와 합의한 seam(공개 인터페이스 경계)에서만 작성하고, 구현 결합·동어반복 테스트 같은 안티패턴을 명시적으로 금지. mocking 가이드(시스템 경계에서만 mock)도 동봉.

to-issues [수동] — 계획/스펙을 트레이서 불릿 방식의 이슈들로 쪼개 발행.

레이어별 수평 분할이 아니라 스키마·API·UI·테스트를 관통하는 얇은 수직 슬라이스로 구분. 각 슬라이스는 단독 데모·검증이 필수. 사용자 승인 후 의존성 순서대로 이슈 트래커에 발행.

to-prd [수동] — 현재 대화 내용을 인터뷰 없이 PRD로 합성해 이슈 트래커에 발행.

추가 질문 없이 지금까지의 대화와 코드베이스 이해만으로 PRD를 작성. 파일 경로나 코드 스니펫은 금방 낡으므로 PRD에서 배제. 충분히 논의된 대화를 공식 문서로 굳히는 단계.

triage [수동] — 이슈와 외부 PR을 상태 머신 기반 역할로 분류·처리.

이슈를 카테고리(bug/enhancement) + 상태(needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix) 라벨로 관리하는 상태 머신을 실행. 버그 재현 검증, 중복/과거 거절 이력 확인까지 진행, 트래커에 남기는 모든 코멘트에 AI 디스클레이머를 첨부.

4.2 productivity — 범용 생산성 (5개)

grilling [자동] — 계획을 빌드 전에 집요한 질문으로 검증.

설계 트리의 각 분기를 따라 내려가며 결정 간 의존성을 하나씩 해소. 질문은 한 번에 하나씩, 각 질문마다 추천 답변을 함께 제시. 코드베이스 탐색으로 답할 수 있는 건 묻지 않고 직접 탐색. 여러 스킬이 이걸 기반으로 동작하는 핵심 프리미티브.

grill-me [수동] — 인터뷰 세션을 시작하는 진입점.

본문이 "Run a /grilling session." 한 줄뿐인 얇은 래퍼. 코드베이스 없는 상황(아이디어 단계)에서 사용. 코드베이스가 있으면 문서까지 남기는 grill-with-docs가 권장.

handoff [수동] — 현재 대화를 다음 에이전트용 핸드오프 문서로 압축.

새 세션이 작업을 이어갈 수 있는 요약 문서를 OS 임시 디렉터리에 저장. 기존 산출물(PRD, 이슈, 커밋)은 중복 없이 경로/URL로만 참조, 민감 정보는 마스킹. 컨텍스트 윈도우가 길어졌을 때의 세션 위생 도구.

teach [수동] — 현재 디렉터리를 학습 워크스페이스로 전환해 여러 세션에 걸쳐 학습 지도.

MISSION.md(학습 동기), 학습 기록, HTML 레슨 파일로 상태를 저장하고, 회상 연습·간격 반복·인터리빙 같은 인지과학 개념을 명시적으로 적용. 프로그래밍뿐 아니라 주제 무관하게 적용 가능.

writing-great-skills [수동] — 스킬을 예측 가능하게 작성·편집하는 원칙 모음.

스킬의 근본 미덕을 "예측 가능성"(매 실행마다 같은 프로세스)으로 정의하고, 자동/수동 호출 선택 기준, 정보 계층화, 프루닝 원칙과 5가지 실패 모드를 정리. 직접 스킬을 만들고 싶을 때 읽는 메타 스킬.

4.3 misc — 특정 툴링 유틸리티 (4개)

4개 중 3개는 TS/Node 특정 툴 종속 — 38개 전체에서 사실상 유일한 언어 종속 그룹.

git-guardrails-claude-code [자동] — 위험한 git 명령을 실행 전에 차단하는 훅을 설치.

Claude Code의 PreToolUse 훅으로 git push, reset --hard, clean -f, branch -D 같은 파괴적 명령을 실행 전에 차단하는 스크립트를 설치하고, 설치 후 차단 동작까지 검증. 언어 무관, Claude Code 전용.

migrate-to-shoehorn [자동] — 테스트의 as 단언을 shoehorn 함수로 교체. (TS 전용)

as Type을 @total-typescript/shoehorn의 fromPartial()로 교체하는 마이그레이션. 테스트 코드 전용이며 프로덕션 사용 금지가 전제.

setup-pre-commit [자동] — Husky + lint-staged + Prettier 프리커밋 훅을 세팅. (Node 전용)

lockfile로 패키지 매니저를 감지하고 훅 설치 후 스모크 테스트까지 진행.

scaffold-exercises [자동] — 강의 실습 디렉터리 구조를 스캐폴딩. (Matt 강의 인프라 전용)

pnpm ai-hero-cli 린트를 전제로 하는 AI Hero 강의 리포 전용이라 일반 사용자에게는 의미가 없음.

4.4 personal — Matt 개인용 (2개)

edit-article [수동] — 아티클 초안을 섹션별로 재구성하고 문장을 정돈. 정보를 DAG로 보고 의존 관계에 맞게 섹션 순서를 정리하는 접근은 참고할 만.

obsidian-vault [자동] — Obsidian 볼트의 노트를 검색·생성·정리. 볼트 경로가 Matt의 개인 경로로 하드코딩돼 있어 그대로 쓰려면 수정 필요.

4.5 in-progress — 미완성/실험작 (7개)

저자가 아직 작업 중이라고 표시한 것들. 흥미로운 아이디어가 많지만 완성도는 보장 안 됨.

• claude-handoff [수동] — handoff 요약을 파일이 아니라 claude --bg로 백그라운드 에이전트에 바로 넘김
• loop-me [수동] — 삶의 반복 패턴을 찾아 위임 가능한 워크플로우 스펙으로 제작
• wayfinder [자동] — 한 세션에 안 담기는 큰 작업을 이슈 트래커 위 "지도"(research/prototype/grilling/task 티켓)로 계획하고 세션당 티켓 하나씩 해결. 아직 질문으로 표현 못 하는 영역은 "Fog" 섹션에 둠. 개인적으로 이 모음에서 가장 야심찬 아이디어라고 봄
• wizard [수동] — 수동 절차(서드파티 설정, 마이그레이션)를 안내하는 인터랙티브 bash 마법사를 생성
• writing-fragments [수동] / writing-beats [수동] / writing-shape [수동] — 글쓰기 3단계 파이프라인: 인터뷰로 글감 파편 수집 → 비트 단위로 골라가며 조립 → 문단 단위로 다듬어 완성. 각 단계가 명확히 구분

4.6 deprecated — 폐기됨 (4개)

저자가 더 이상 권장하지 않는 것들. 설치돼도 쓰지 않는 게 맞음.

• design-an-interface — 병렬 에이전트로 다른 설계안 여러 개를 뽑아 비교 (codebase-design의 Design It Twice로 흡수된 것으로 보임)
• qa — 대화로 버그를 말하면 GitHub 이슈로 등록 (triage로 대체)
• request-refactor-plan — 인터뷰로 리팩터 계획을 다듬어 이슈화
• ubiquitous-language — 대화에서 DDD식 용어집 추출 (domain-modeling으로 대체)

5. 스킬은 따로 노는 게 아니라 "플로우"로 엮여 있음

이 모음의 진짜 설계는 개별 스킬이 아니라 스킬 간 연결. ask-matt이 설명하는 메인 플로우(idea → ship):

아이디어
  → /grill-with-docs   (인터뷰로 다듬기 + ADR/용어집 기록)
  → /to-prd            (대화를 PRD로 굳히기)
  → /to-issues         (독립적인 수직 슬라이스 이슈로 분해)
  → 이슈당 새 세션에서 /implement   (내부에서 tdd 사용)
  → /code-review       (표준/스펙 2축 검토)

여기에 온램프 두 개(triage로 이슈 정리, diagnosing-bugs로 버그 잡기)가 메인 플로우에 합류하고, grilling·domain-modeling·codebase-design은 다른 스킬들이 깔고 쓰는 어휘/프리미티브 레이어로 동작. 이슈 단위로 세션을 끊어 컨텍스트를 초기화하는 것까지 플로우에 명시.

6. 직접 해본 A/B 테스트 — code-review 스킬이 바꾸는 것

주장만으로는 근거가 부족해 직접 통제된 실험으로 검증.

설계

• 서브에이전트 2개를 병렬로 띄움. 둘 다 완전히 동일한 자료(원본 이슈 + 코딩 표준 + 리뷰 대상 diff)를 받음
• 대조군: "이 변경 리뷰해줘"만 줌. 스킬 존재를 모름
• 실험군: 동일 자료 + code-review SKILL.md 지침 주입
• 서로의 존재를 모르는 격리 상태 → 유일한 변수는 스킬 주입 여부

리뷰 대상은 장바구니 쿠폰 할인 함수(11줄)이며, 여기에 결함 7개를 의도적으로 삽입: 스펙 위반 3개(음수 방지 없음, 반올림 없음, 유효성 검증/throw 없음) + 표준 위반 4개(JSDoc 없음, 매직 넘버, 공용 반올림 헬퍼 미사용, 입력 검증 없음).

export type Coupon = {
  type: 'percent' | 'fixed'
  value: number
}

export function applyCoupon(subtotal: number, coupon: Coupon): number {
  if (coupon.type === 'percent') {
    return subtotal - (subtotal * coupon.value) / 100
  }
  return subtotal - coupon.value
}

결과

해석 — 스킬은 모델을 똑똑하게 만드는 게 아님

가장 중요한 발견: 스킬을 붙인다고 버그를 더 찾은 게 아님. 강력한 모델은 작은 diff에선 스킬 없이도 결함을 전부 포착. 심지어 대조군이 더 실용적인 제안(exhaustive never 체크)을 한 지점도 있었음.

스킬이 실제로 바꾼 건 프로세스:

1. 커버리지 보장 — 실험군은 통과한 요구사항까지 "MET"로 확인. 대조군은 문제만 나열해서, 나머지를 검토했는지 건너뛰었는지 리포트만 봐선 알 수 없음. 감사 가능성(auditability)의 차이
2. 관심사 분리 — 스펙 축과 표준 축을 나눠서 한 축이 다른 축을 가리는 것을 방지
3. 재현성 — 매번 같은 형태로 나옴. 리뷰어(사람이든 에이전트든)가 여럿일 때 이 일관성이 값어치

즉 스킬의 값은 "똑똑함"이 아니라 "규율"이고, diff가 크고 팀이 클수록 이득이 커지는 종류.

한계 (정직하게)

• 표본은 리뷰 1건. 통계가 아니라 정성적 관찰
• 대조군도 같은 강력한 모델이라 탐지율이 붙었음. 약한 모델이나 더 크고 미묘한 diff였다면 커버리지 보장의 격차가 탐지율로도 드러났을 가능성이 큼

7. 결론 — 골라서 쓰기를 권장

쓰는 걸 추천하되, 38개를 통째로 설치하기보다는 골라서 쓰기를 권장.

• 바로 쓸 만한 것: code-review, tdd, diagnosing-bugs, grilling(+grill-with-docs), domain-modeling, research. 전부 언어 중립이라 TS가 아니어도 됨
• 팀/멀티세션 규모면 추가: to-prd, to-issues, implement, triage, handoff — 단 이슈 트래커 설정(setup-matt-pocock-skills)이 전제
• 거를 것: deprecated 4개, Matt 개인용 2개, 강의 인프라 전용 1개(scaffold-exercises). in-progress 7개는 아이디어 구경용
• 주의: 이미 자체 CLAUDE.md 규칙이 촘촘한 프로젝트면 스킬의 자체 컨벤션(영어 출력, docs/agents/ 문서 레이아웃, 이슈 트래커 전제)과 부딪힐 수 있으니 조정 필요

이 모음에서 개별 스킬보다 더 배울 만한 건 설계 철학이라고 생각: 에이전트에게 "잘해줘"라고 비는 대신, 검증된 작업 절차를 문서로 인코딩하고, 절차끼리 플로우로 엮고, 세션 경계까지 설계하는 것. 스킬을 직접 만들 사람이라면 writing-great-skills 하나만 읽어도 본전은 뽑음.

네트워킹 소개

• 커피숍 비유를 통한 네트워킹 개념
  • 커피숍 바리스타와 계산원 비유
    • 계산원 (퍼블릭 서브넷 역할)
      • 정의
        • 고객과 직접 마주하며 주문을 받고 결제를 처리하는 대외적 접점
    • 바리스타 (프라이빗 서브넷 역할)
      • 정의
        • 고객과 직접 상호 작용하지 않고, 격리된 내부 영역에서 음료 제조에만 몰입하는 내부 자원
• 네트워킹 구성 요소
  • Amazon Virtual Private Cloud (VPC)
    • 정의
      • AWS 클라우드 내부에서 사용자가 정의한 가상 네트워크를 실행할 수 있도록 마련된 논리적으로 격리된 영역
  • 서브넷 (Subnet)
    • 정의
      • 리소스를 역할 및 보안 수준에 따라 그룹화하고 분할하기 위해 VPC를 관리 가능한 크기인 특정 IP 주소 범위로 쪼갠 세그먼트
    • 특징/이점
      • 프라이빗 서브넷은 외부 인터넷 직접 노출을 차단하여 민감한 정보(데이터베이스 등)를 보관함
      • 퍼블릭 서브넷은 고객용 웹 사이트와 같이 인터넷 직접 액세스가 필요한 리소스를 배치함
• 네트워킹 구성 요소: 다이어그램을 통해 연결에 대해 이해
  • 아키텍처 다이어그램 (Architecture Diagram)
    • 정의
      • AWS 클라우드 내에 구축된 네트워크의 구조와 리소스 간의 연결 관계 및 데이터 이동 경로를 나타낸 시각적 맵
    • 특징/이점
      • 시스템의 이중화, 보안성, 확장성을 직관적으로 확인하고 최적의 설정을 검증하는 설계 청사진으로 활용함

• AWS 클라우드 (AWS Cloud)
  • 정의
    • 아키텍처 다이어그램상에서 시스템 전체 영역을 감싸는 가장 바깥쪽에 위치하는 상자
• 리전 (Region)
  • 정의
    • AWS 클라우드 하위에 표시되는 지리적으로 격리된 독립된 물리적 영역 상자
  • 특징/이점
    • 지연 시간, 규정 준수, 가용 서비스, 비용 등을 복합적으로 고려하여 적합한 리전을 결정함
• Amazon VPC
  • 정의
    • 리전 내부의 격리되어 논리적으로 분할된 네트워크 환경을 나타내는 실선 상자
  • 특징/이점
    • 네트워크 내부의 리소스 제어 및 보안 정책 설정을 관리함
• 가용 영역 (Availability Zone, AZ)
  • 정의
    • 리전 내에서 1개 이상의 개별 데이터 센터로 구성되고 각각 별도의 시설에 구축된 물리적 인프라 영역 상자
  • 특징/이점
    • 독립된 전력, 네트워킹, 연결 기능을 갖추고 있으며 다중 AZ 아키텍처는 단일 장애 상황으로부터 서비스를 보호함

• 서브넷 (Subnet)
  • 정의
    • VPC의 세그먼트로서 VPC 내의 특정 IP 주소 범위를 가지며 VPC를 관리하기 쉬운 섹션으로 나누는 단위 상자
• 프라이빗 서브넷 (Private Subnet)
  • 정의
    • 퍼블릭 인터넷에 직접 노출되면 안 되는 리소스를 안전하게 격리하도록 설계된 실선 상자

• 퍼블릭 서브넷 (Public Subnet)
  • 정의
    • 내부에 배치된 리소스에 인터넷과의 양방향 통신을 제공하도록 설계된 파선 상자
  • 특징/이점
    • 외부 인터넷의 통신을 허용하기 위해 인터넷 게이트웨이(IGW)에 연결되어 동작함

aws 클라우드의 네트워크 구성 요소

aws 클라우드 리소스 구성

• Amazon Virtual Private Cloud (VPC) 및 서브넷 기본 개념
  • Amazon VPC 개요
    • 정의
      • AWS 클라우드 내부에서 고객이 소유하고 격리시켜 프로비저닝하는 사설(프라이빗) 가상 네트워크 영역
    • 특징/이점
      • 리소스의 프라이빗 IP 범위를 정의하고, EC2 및 ELB 등의 자원을 그 안에 배치하여 경계를 설정함
      • 가상 네트워크의 설정, 관리, 검증 시간을 단축하여 온프레미스 대비 효율성을 높임
      • 보안 강화: 인스턴스 액세스 제한, 트래픽 스크리닝, 연결 보호 및 모니터링을 통한 강력한 통제권 제공
  • 서브넷 (Subnet)
    • 정의
      • 리소스를 그룹화하고 세부적으로 격리하기 위해 VPC의 IP 주소를 적절한 청크로 쪼갠 하위 섹션
    • 특징/이점
      • 나중에 설정할 네트워킹 보안 규칙과 연계하여 특정 리소스를 퍼블릭 또는 프라이빗 상태로 제어함
      • EC2 인스턴스 등 실제 구동할 컴퓨팅/네트워크 자원들을 포함하는 실질적 공간임
• 외부 인터넷 및 사설 네트워크 연결 수단 (게이트웨이)
  • 인터넷 게이트웨이 (Internet Gateway, IGW)
    • 정의
      • VPC 내부의 리소스와 퍼블릭 인터넷 간의 직접적인 통신(양방향 연결)을 허용하는 전용 출입구
    • 특징/이점
      • 커피숍의 현관문과 같은 비유로서, 이것이 VPC에 연결되어 있지 않으면 외부에서 퍼블릭 리소스에 접근이 절대 불가능함
      • 퍼블릭 웹 사이트, 퍼블릭 로드 밸런서 등 대외용 서비스 배치 시 반드시 장착해야 함
  • 가상 프라이빗 네트워크 (VPN) 및 가상 프라이빗 게이트웨이 (VGW)
    • 가상 프라이빗 네트워크 (VPN)
      • 정의
        • 일반 공개망인 인터넷을 사용하면서도 데이터 유출을 막기 위해 가상의 보안 암호화 터널을 생성해 트래픽을 통과시키는 가상 사설망 기술
      • 특징/이점
        • 패킷을 완전 암호화하여 통신 내용을 외부 감시자로부터 보호함
        • 퍼블릭 네트워크 선로를 공유하여 사용하므로 트래픽이 몰릴 때 대역폭 저하 및 속도 지연이 발생할 수 있음
    • 가상 프라이빗 게이트웨이 (Virtual Private Gateway, VGW)
      • 정의
        • 암호화된 VPN 보안 트래픽이 VPC 내부로 유입되거나 밖으로 나갈 수 있도록 보장하는 AWS 측의 전용 사설 통신 출입구
      • 특징/이점
        • 커피숍의 비공개 사옥 보안 게이트 비유로서, 사원증(인증)을 확인한 승인된 사내 네트워크 트래픽만 내부 VPC에 들어오게 허용함
        • 온프레미스 데이터 센터나 본사/지사 사내 네트워크와 AWS VPC 간에 안전한 하이브리드 VPN 터널링을 설정할 수 있음
  • AWS Direct Connect
    • 정의
      • 고객의 온프레미스 데이터 센터에서 AWS 영역까지 인터넷망을 경유하지 않고 완전한 프라이빗 전용 광케이블 회선을 연결하는 서비스
    • 특징/이점
      • 커피숍으로 바로 이어지는 비밀 전용 통로(마법의 문) 비유로서, 네트워크 혼잡이나 공유 회선 문제를 완전히 우회함
      • 매우 안정적이고 일관된 초고속 고대역폭 전송 성능과 높은 보안 성능을 제공함
      • 데이터 주권 등 법률적 규정 준수(Compliance)를 강하게 충족하며 전용 통신망 파트너를 통해 물리 전용선을 구축함

aws 클라우드에 연결할 수 있는 추가적인 방법

• AWS 클라우드 연결 개요

  • 정의
    • 네트워크, 온프레미스 데이터 센터, 원격 작업자의 다양성에 맞춰 기업이 AWS 클라우드 리소스에 접속할 수 있도록 제공되는 다양한 연결 방식

• AWS Client VPN

  • 정의
    • 원격 작업자와 온프레미스 네트워크를 AWS 클라우드에 보안 연결할 수 있게 지원하는 클라이언트 기반 VPN 서비스
  • 특징/이점
    • 탄력적인 완전관리형 서비스로서 사용자 수요에 맞춰 자동으로 리소스 규모를 스케일 업/다운함
    • 별도의 물리 하드웨어를 구매 및 관리할 필요가 없으며 OpenVPN 기반 클라이언트를 채택함
    • 고급 인증 방식과 안전한 원격 액세스를 신속히 제공해야 하는 대기업 원격 근무 환경에 적합함

• AWS Site-to-Site VPN

  • 정의
    • 기업의 온프레미스 데이터 센터나 지사(Site) 네트워크와 AWS 클라우드 VPC 간에 안전하고 암호화된 터널링 세션을 맺어주는 IPsec VPN 서비스
  • 특징/이점
    • 고가용성, 강력한 보안, 비공개 세션을 생성하며 가상 프라이빗 게이트웨이(VGW)를 거쳐 VPC로 유입됨
    • 주로 원격 지사 위치 간의 애플리케이션 마이그레이션이나 암호화 보안 통신에 필수적으로 적용됨

• AWS PrivateLink

  • 정의
    • 인터넷 게이트웨이, NAT 디바이스, 퍼블릭 IP, Direct Connect 또는 VPN을 거치지 않고, VPC를 다른 VPC나 AWS 서비스에 사설망(비공개)으로 가용성 높게 직접 연결해 주는 프라이빗 연결 기술
  • 특징/이점
    • 마치 고객이 독자적으로 보유한 VPC 내부에서 직접 서비스와 자원을 이용하는 것과 동일한 보안성을 제공함
    • 다른 클라이언트와의 트래픽 정체 현상을 방지하고 비공개 API 엔드포인트 연결을 중앙 제어하여 관리 복잡성을 줄임

• AWS Direct Connect

  • 정의
    • 고객의 온프레미스 데이터 센터나 사무실에서 AWS 인프라 영역까지 인터넷을 완전히 우회하여 물리적인 전용 광케이블 회선으로 직결하는 서비스
  • 특징/이점
    • 인터넷 공유 회선을 사용하지 않아 트래픽 정체 요인이 없고 네트워크 비용이 대폭 절감됨
    • 지연 시간에 민감한 애플리케이션: 일관되게 지연 시간이 극도로 짧은 환경을 조성해 동영상 스트리밍이나 실시간 처리에 최적화됨
    • 대규모 데이터 마이그레이션: 실시간 빅데이터 분석, 신속 백업, 고용량 미디어 브로드캐스트 전송을 위한 신뢰성 있는 대역폭을 보장함
    • 하이브리드 클라우드 아키텍처: AWS와 온프레미스 네트워크를 유기적으로 직결하여 성능 저하 없는 분산 애플리케이션 가동 환경을 형성함

• 추가적인 게이트웨이 서비스

  • AWS Transit Gateway
    • 정의
      • 중앙 집중식 가상 라우터(허브) 역할을 수행하여 수많은 VPC들과 온프레미스 네트워크를 그물망 피어링 대신 일대다(1:N) 형태로 통합 연동해 주는 게이트웨이 서비스
    • 특징/이점
      • 클라우드 인프라가 전 세계로 확장될 때 리전 간 전송 게이트웨이를 피어링하여 관리를 획기적으로 간소화함
  • Network Address Translation (NAT) 게이트웨이
    • 정의
      • 프라이빗 서브넷에 속한 인스턴스가 VPC 외부의 인터넷이나 다른 서비스로 아웃바운드 연결은 수행하게 돕되, 외부에서 해당 프라이빗 인스턴스로의 최초 인바운드 접속 시도는 전면 차단해 주는 주소 변환(NAT) 서비스
  • Amazon API Gateway
    • 정의
      • 소프트웨어 시스템 간 통신을 정의하는 API를 개발자가 손쉽게 대규모로 생성, 게시, 유지 관리, 모니터링 및 보안 제어할 수 있게 돕는 완전관리형 API 호스팅 서비스

서브넷, 보안 그룹, 네트워크 엑세스 제어 목록

• VPC 네트워크 보안 개요

  • 정의
    • 외부 위협으로부터 클라우드 내부 자원을 보호하기 위해 VPC 내부와 서브넷, 인스턴스 등 각 계층별로 적용되는 다층 방어 네트워킹 보안 설계
  • 특징/이점
    • 게이트웨이 경계 보안 외에도 방화벽, DDoS 방지, 암호화, 패킷 스크리닝 등 다양한 보안 계층 도구를 종합 활용함

• 네트워크 액세스 제어 목록 (Network ACL)

  • 정의
    • 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어하는 스테이트리스(Stateless) 기반의 가상 방화벽
  • 특징/이점
    • 출입국 심사 직원 비유: 서브넷 경계를 드나드는 모든 데이터 패킷의 발신 정보와 포트를 규칙 목록(승인/거부 목록)과 대조해 검사함
    • 기본 네트워크 ACL은 기본적으로 모든 인바운드/아웃바운드 트래픽을 허용함
    • 사용자 지정 네트워크 ACL은 명시적 규칙을 추가하기 전까지 모든 트래픽을 차단함 (마지막에 매칭되지 않는 패킷을 전면 드롭하는 명시적 거부 규칙 존재)
    • 한계: 패킷이 서브넷 경계를 통과할 때만 동작하며, 동일 서브넷 내부에서 인스턴스 간에 주고받는 트래픽 흐름은 통제할 수 없음

• 보안 그룹 (Security Groups)

  • 정의
    • Amazon EC2 인스턴스 등 개별 리소스 수준에서 인바운드 및 아웃바운드 트래픽을 세밀하게 제어하는 스테이트풀(Stateful) 기반의 가상 방화벽
  • 특징/이점
    • 아파트 건물의 도어맨 비유: 인스턴스 단위로 동작하며, 들어올 때만 허가 목록을 확인하고 나갈 때는 검사하지 않음
    • 기본적으로 모든 인바운드 트래픽을 차단(거부)하고, 모든 아웃바운드 트래픽을 허용하도록 설정되어 시작됨
    • 허용(Allow) 규칙만 정의할 수 있으며, 거부(Deny) 규칙은 작성할 수 없음 (규칙에 없는 트래픽은 자동으로 모두 차단됨)

• 패킷 필터링 방식 비교 (스테이트풀 vs 스테이트리스)

  • 스테이트풀 패킷 필터링 (Stateful Packet Filtering)

    • 정의
      • 아웃바운드로 나간 요청의 연결 상태(세션)를 메모리에 기억해 두었다가, 해당 요청의 반환 트래픽이 들어올 때 인바운드 규칙 검사를 생략하고 무조건 허용하는 방식 (보안 그룹에 적용)

  • 스테이트리스 패킷 필터링 (Stateless Packet Filtering)

    • 정의
      • 과거에 나간 아웃바운드 요청 상태를 전혀 저장(기억)하지 않고, 인바운드와 아웃바운드 양방향에 대해 매번 독립적으로 규칙 목록과 대조하여 통과 여부를 검사하는 방식 (네트워크 ACL에 적용)

• 서브넷 간 패킷 이동 시나리오 (인스턴스 A에서 다른 서브넷의 인스턴스 B로 송수신 시 검사 순서)

  • 1. 송신 과정 (A -> B)
    • 인스턴스 A 보안 그룹: 아웃바운드 트래픽 자동 통과 (기본 설정상 모든 발신 허용)
    • 서브넷 1 네트워크 ACL: 송신(발신) 규칙에 따라 패킷 검사 후 통과 결정
    • 서브넷 2 네트워크 ACL: 수신(입산) 규칙에 따라 패킷 검사 후 통과 결정
    • 인스턴스 B 보안 그룹: 인바운드 허용 규칙 목록과 대조하여 패킷 진입 허용 여부 판정
  • 2. 반환 과정 (B -> A)
    • 인스턴스 B 보안 그룹: 요청에 대한 회신이므로 아웃바운드 필터 자동 통과
    • 서브넷 2 네트워크 ACL: 스테이트리스이므로 송신 규칙에 따라 패킷 재검사 실행
    • 서브넷 1 네트워크 ACL: 스테이트리스이므로 수신 규칙에 따라 패킷 재검사 실행
    • 인스턴스 A 보안 그룹: 스테이트풀이므로 아웃바운드 요청에 대한 반환 트래픽임을 기억하고 규칙 검사 없이 자동으로 패킷 최종 수용

• 보안 그룹과 네트워크 ACL 핵심 요약

  • 보안 그룹
    • 작동 범위: 인스턴스 수준 (개별 리소스 제어)
    • 연결 상태 유지: 스테이트풀 (Stateful)
    • 규칙 성격: 허용(Allow) 규칙만 정의 가능
    • 반환 트래픽 처리: 인바운드가 허용되면 반환 트래픽은 자동 허용됨
  • 네트워크 ACL
    • 작동 범위: 서브넷 수준 (광범위한 서브넷 경계 제어)
    • 연결 상태 유지: 스테이트리스 (Stateless)
    • 규칙 성격: 허용(Allow) 및 거부(Deny) 규칙 모두 정의 가능
    • 반환 트래픽 처리: 아웃바운드와 인바운드 각각 개별 규칙 통과가 요구됨

• 공동 책임 모델상의 네트워크 보안 책임

  • 정의
    • AWS 인프라의 기본 환경은 AWS가 책임지지만, 그 내부의 가상 네트워크(VPC) 서브넷과 리소스를 안전하게 설계하고 방화벽 규칙을 적용할 책임은 고객에게 있다는 원칙

amazon vpc 데모

• AWS 클라우드에서 Amazon VPC 구축 개요

  • 정의
    • AWS Management Console을 활용해 VPC, 가용 영역별 서브넷, 인터넷 게이트웨이, 라우팅 테이블을 설계하고 구성하는 실제 네트워크 구축 프로세스
  • 특징/이점
    • 고가용성 네트워크의 기본 구성 요소들을 순차적으로 연계 설정하여 인터넷 직접 통신이 가능한 퍼블릭 영역과 차단된 프라이빗 영역을 분리함

• 1단계: Amazon VPC 생성

    ![](https://velog.velcdn.com/images/oi_24/post/92431302-d3d6-406e-a707-39f862d7ec02/image.png)

  • 정의
    • 클라우드 내에 격리된 사설 네트워크의 기본 주소 공간을 프로비저닝하는 작업
  • 설정 세부정보
    • Resource to create: VPC only 선택
    • Name tag: my-vpc
    • CIDR(IPv4 주소 블록 범위): 10.0.0.0/16 지정 (해당 VPC에서 생성되는 모든 리소스는 10.0으로 시작하는 고유 프라이빗 IP를 할당받음)

• 2단계: 가용 영역별 서브넷 생성

    ![](https://velog.velcdn.com/images/oi_24/post/ec535b71-b80e-4d91-a085-99a36fd12edd/image.png)

  • 정의
    • 고가용성(High Availability) 모범 사례에 따라 단일 리전 내의 서로 다른 2개의 물리 가용 영역(AZ)에 퍼블릭 및 프라이빗 서브넷을 각각 분산 배치하는 작업
  • 설정 세부정보
    • 프라이빗 서브넷 생성:
      • private-subnet-1: 가용 영역 us-east-1a, CIDR 블록 10.0.1.0/24 지정
      • private-subnet-2: 다른 가용 영역(예: us-east-1b), CIDR 블록 10.0.2.0/24 지정
      • 주의 사항: 외부 인터넷 접근이 불가능하도록 퍼블릭 IPv4 자동 할당(Auto-assign IP settings)을 활성화하지 않음
    • 퍼블릭 서브넷 생성:
      • public-subnet-1: 가용 영역 us-east-1a, CIDR 블록 10.0.3.0/24 지정
      • public-subnet-2: 다른 가용 영역(예: us-east-1b), CIDR 블록 10.0.4.0/24 지정
      • 필수 설정: 외부 접속용 퍼블릭 IP를 부여하기 위해 퍼블릭 IPv4 자동 할당(Auto-assign public IPv4) 옵션을 명시적으로 활성화(Save)함
    • 주의 사항
      • 단순히 서브넷 이름에 'public'이나 'private'을 기재하는 것만으로는 실제 퍼블릭/프라이빗 기능이 활성화되지 않으며, 인터넷 게이트웨이 연결 및 라우팅 설정이 완료되어야 실질적으로 동작함

• 3단계: 인터넷 게이트웨이 생성 및 연결

  • 정의
    • VPC가 외부 인터넷과 직접 양방향 통신을 처리하기 위한 논리적 출입문을 생성하여 장착하는 작업
  • 설정 세부정보
    • Name tag: my-ig로 인터넷 게이트웨이 생성
    • VPC 연결: Actions 메뉴의 VPC에 연결(Attach to VPC)을 실행하여 대상 VPC(my-vpc)에 게이트웨이를 정상 부착함

• 4단계: 라우팅 테이블 생성 및 서브넷 연결

  • 정의
    • 네트워크 패킷이 올바른 목적지로 이동할 수 있도록 라우팅 규칙(경로)을 정의하고, 이를 특정 서브넷들과 맵핑하는 작업
  • 설정 세부정보
    • 라우팅 테이블 생성: Name을 public-route-table로 정하고 대상 VPC(my-vpc)를 지정하여 생성
    • 라우팅 규칙 추가 (Edit routes):
      • 대상(Destination)에 0.0.0.0/0(모든 외부 트래픽) 입력
      • 대상(Target)에 방금 생성하여 연결한 인터넷 게이트웨이(my-ig)를 지정 및 저장
    • 명시적 서브넷 연결 (Subnet associations):
      • 생성한 라우팅 테이블의 서브넷 연결 탭에서 public-subnet-1과 public-subnet-2를 연결함
      • 이 연결을 거친 서브넷은 인터넷 게이트웨이로 향하는 유효 경로를 가져 실질적인 퍼블릭 서브넷으로 승격되며, 경로가 없는 프라이빗 서브넷들은 격리 상태를 계속 유지함

• 5단계: 보안 규칙 구성 및 리소스 배포 준비

  • 정의
    • 구축된 네트워크 환경의 트래픽을 안전하게 필터링하기 위해 보안 제어를 설정하고 리소스를 추가할 최종 단계를 준비하는 작업
  • 특징/이점
    • 앞서 생성한 CIDR 블록 범위를 소스/대상 정의용으로 활용하여 보안 그룹 및 네트워크 ACL에 정밀한 허용/차단 규칙을 명시함
    • 필터링 정책이 완벽히 구성되면 해당 서브넷에 EC2 인스턴스, 데이터베이스 등의 실제 비즈니스용 리소스를 최종 배포함

글로벌 네트워킹

• 엣지 네트워킹 (Edge Networking) 개요
  • 정의
    • 콘텐츠를 소비하는 사용자 및 데이터를 생성하는 디바이스에 물리적으로 더 가까운 위치에서 정보 저장 및 컴퓨팅 서비스를 수행하는 인프라 아키텍처
  • 특징/이점
    • 로컬에 데이터를 캐싱하거나 연산 태스크를 수행하여 네트워크 통신의 지연 시간(Latency)을 획기적으로 감축함
    • 최종 사용자에게 정체 없는 빠른 응답 속도를 보장하여 전반적인 애플리케이션 인터랙션 만족도를 향상시킴
• Amazon Route 53
  • 정의
    • 최종 사용자를 AWS 내부 및 외부의 인터넷 애플리케이션으로 신뢰성 있게 안내하는 고가용성 및 확장성을 갖춘 클라우드 도메인 이름 서비스 (DNS)
  • 특징/이점
    • 인터넷의 전화번호부/번역기 비유: 사람이 읽을 수 있는 도메인 주소를 컴퓨터가 해석할 수 있는 IP 주소로 신속 변환함
    • 다양한 지능형 라우팅 정책 지원: 지연 시간 기반 라우팅, 지리적 위치(고객의 대륙/국가 위치에 따른 분기), 지리적 근접성, 가중치 기반 라운드 로빈(Weighted Round Robin) 등
    • 도메인 이름 구매 및 등록 관리를 Route 53 한 곳에서 일원화하여 통합 관리할 수 있는 도메인 레지스트라 기능 지원
• Amazon CloudFront
  • 정의
    • 웹 콘텐츠, 동영상, 이미지, 애플리케이션, API 등을 글로벌 엣지 로케이션망을 활용하여 전 세계 사용자에게 신속하게 분배하는 콘텐츠 전송 네트워크 (CDN) 서비스
  • 특징/이점
    • 글로벌 배달 트럭 네트워크 비유: 중앙의 오리진 서버에 매번 직접 패킷을 요청하지 않고, 엣지 로케이션에 사본(캐시)을 미리 보관해 빠르게 반환함
    • 동영상 스트리밍: 동시 대규모 접속자가 몰리는 피크 시간에도 버퍼링을 차단하고 끊김 없는 전송 신뢰성을 확보함
    • 전자상거래 웹 사이트: 대규모 쇼핑 시즌에도 고용량 상품 이미지와 제품 세부 정보를 사용자 부근 엣지에서 즉각 띄워 이탈률을 저하시킴
    • 모바일 앱: 실시간 변동이 잦은 위치/지도 데이터나 미디어 자산을 모바일 디바이스에 지체 없이 안정적으로 로드함
• AWS Global Accelerator
  • 정의
    • 지능형 트래픽 라우팅 및 신속한 장애 조치(Failover) 기술과 AWS의 프라이빗 글로벌 백본 네트워크망을 활용해 글로벌 애플리케이션의 가용성, 보안 및 전송 성능을 극대화하는 서비스
  • 특징/이점
    • 정체가 발생하기 쉬운 공용 인터넷 고속도로망 대신, 트래픽을 위한 독점 보안 고속 차선을 구축하여 기동함
    • 글로벌 온라인 게임: 전 세계 플레이어(예: 도쿄, 뉴욕, 런던 등) 간의 지연 편차를 좁혀 동등하고 매끄러운 반응성의 게임플레이 환경을 보장함
    • 금융 및 은행 서비스: 접속자가 대거 밀리는 피크 타임이나 지역 네트워크 불안 상황에서도 가동 중지 및 지연 없이 신뢰할 수 있는 속도로 금융 거래 및 계좌 액세스를 보장함

실제 환경에서의 클라우드

글로벌 아키텍처

• 실제 환경의 글로벌 네트워크 요구사항
  • 정의
    • 전 세계 사용자를 지원하기 위해 여러 계정, 여러 리전, 다중 VPC 및 온프레미스를 통합하는 복잡한 하이브리드 네트워킹 구조
  • 특징/이점
    • 비즈니스 규모 확장과 지리적 이중화를 실현하여 가동 중지 시간을 방지하고 고성능 가용성을 보장함
• 하이브리드 연결 방식 비교 (Site-to-Site VPN vs Direct Connect)
  • AWS Site-to-Site VPN
    • 정의
      • 퍼블릭 인터넷 위에 보안 암호화 프라이빗 터널을 생성하여 온프레미스 네트워크와 AWS VPC를 가상 프라이빗 게이트웨이(VGW)로 연결하는 서비스
    • 특징/이점
      • 안전하고 유연하며 설정이 신속해 소규모 데이터 전송 및 원격 리소스 액세스에 최적화됨
      • 한계: 공용 인터넷 대역폭을 공유하므로 대용량 데이터 전송 시 속도가 저하되며, 특정 보안 규정 준수 충족에 제약이 있을 수 있음
  • AWS Direct Connect
    • 정의
      • 인터넷을 우회하여 고객 데이터 센터에서 Direct Connect 로케이션을 거쳐 가상 프라이빗 게이트웨이(VGW)까지 물리적인 전용 광케이블 회선을 직결하는 서비스
    • 특징/이점
      • 일관되게 지연 시간이 짧고 대규모 데이터 전송 속도를 대폭 높여 중요한 애플리케이션 성능을 극대화함
      • 동영상 스트리밍, 실시간 백업, 하이브리드 연산 등 고대역폭과 강력한 보안 규정 준수가 필요한 비즈니스에 필수적임
• Direct Connect 장애 조치 및 가용성 설계
  • VPN 장애 조치 (Backup & Failover)
    • 정의
      • 비용 효율성을 극대화하기 위해 Direct Connect 전용선 단선 장애 시 백업 연결용으로 Site-to-Site VPN을 설정해 자동 복구(Failover)하는 이중화 방식
    • 특징/이점
      • 평소에는 전용선을 쓰고 비상시에만 인터넷망 VPN을 사용해 보조 회선 비용을 줄이지만, 장애 복구 시에는 대역폭이 VPN 성능 수준으로 한정됨
  • 보조 Direct Connect 구성
    • 정의
      • 핵심 시스템의 성능 저하 없는 고가용성을 유지하기 위해 또 다른 물리적 Direct Connect 회선을 평행하게 구축하여 상호 백업하는 구조
    • 특징/이점
      • 단선 사고가 일어나더라도 고대역폭과 초저지연 성능을 일관되게 유지하는 강력한 내결함성을 확보함
  • 대역폭 집계 (Bandwidth Aggregation)
    • 정의
      • 네트워크 처리 용량을 물리적으로 증가시키기 위해 여러 개의 Direct Connect 전용선 연결을 하나로 결합하는 기술
    • 특징/이점
      • 회선 여러 개를 묶어 집계 대역폭을 향상시킴으로써 한 번에 대용량 트래픽 전송이 가능한 네트워크 파이프라인을 형성함
  • 하이브리드 아키텍처 연결 경로
    1. 고객 네트워크: 고대역폭 연결을 요구하는 클라이언트 및 백엔드 서버
    2. 콘텐츠 라우터 / 방화벽: 온프레미스 최경계에서 Direct Connect 선로에 유입을 중계하는 전용 게이트 장비
    3. 다중 Direct Connect 연결: 내결함성과 대역폭 향상을 위해 이중화로 연결된 물리 전용 회선
    4. 가상 프라이빗 게이트웨이 (VGW): VPC 관문에서 암호화되거나 격리된 사설 트래픽 통신을 안전하게 최종 수용하는 허브
    5. Amazon VPC: 전용선을 경유해 들어온 트래픽으로 실제 서비스를 처리하는 여러 프라이빗 서브넷 내 컴퓨팅 리소스
• Route 53 & CloudFront 연동을 통한 글로벌 콘텐츠 배포
  • 정의
    • 전 세계 사용자에게 낮은 지연 시간으로 웹 사이트와 미디어를 서비스하기 위해 Route 53 DNS와 CloudFront CDN을 상호 연계하는 통합 글로벌 아키텍처
  • 작동 흐름
    1. 사용자 요청: 사용자가 브라우저를 통해 도메인 주소로 웹 사이트에 접속을 시도하면 Route 53 DNS 서버가 이를 수신함
    2. 라우팅 정책 판정: Route 53가 지연 시간 기반 라우팅 정책 등을 활용해 사용자에게 가장 가까운 리전을 즉각 판정함
    3. 엣지 로케이션 연동: Route 53의 제어에 따라 사용자는 해당 리전과 연동된 최적의 CloudFront 엣지 로케이션으로 연결됨
    4. 다중 AZ 오리진 서버 콘텐츠 인출: 엣지 로케이션은 해당 리전의 다중 가용 영역(AZ)에 안전하게 배포된 고가용성 오리진 서버에서 원본 자원을 불러와 최종 가동시킴

글로벌 시장 진출 소개

• 글로벌 시장 진출 개요
  • 정의
    • 비즈니스가 전 세계 고객에게 서비스를 제공하고 물리적/가상 인프라를 확장하는 과정
  • 특징/이점
    • 현지 수요, 규정 준수, 비용 등 여러 요인을 고려하여 확장 계획 수립 필요
    • AWS는 전 세계 어디서나 강력하고 확장 가능하며 고가용성을 갖춘 애플리케이션을 구현할 수 있도록 지원
• AWS 글로벌 인프라 비유
  • 리전(Region) 선택
    • 정의
      • 새로운 물리적 매장을 열 위치를 결정하는 것과 같이 실제 클라우드 리소스를 배포할 리전을 선택하는 것
    • 고려 사항
      • 현지 수요, 규정, 비용 등 여러 비즈니스 및 기술적 요인
  • AWS 엣지 로케이션(Edge Location)
    • 정의
      • 이동식 커피 카트처럼 전 세계 사용자에게 지연 시간을 최소화하여 콘텐츠를 신속하게 제공하는 소규모 물리적 시설
    • 특징/이점
      • 이미지, 동영상, 정적 자산 등 자주 액세스하는 콘텐츠를 캐시하여 사용자에게 빠르게 제공
      • 중앙 서버(리전)로부터 매번 데이터를 가져오는 대기 시간 단축
  • 코드형 인프라(IaC) 및 AWS CloudFormation
    • 정의
      • 전 세계 모든 지점에서 일관된 프로세스와 커피 맛을 유지하기 위해 레시피 및 장비를 표준화하는 것처럼, 코드로 인프라를 정의하고 배포하는 방식
    • 특징/이점
      • 환경 및 글로벌 배포 전체에서 일관성 있고 신뢰할 수 있는 설정을 구현
      • 비즈니스 성장에 맞춰 신속하고 책임감 있게 리소스 스케일링 가능

aws 글로벌 인프라

aws 리전 선택

• AWS 리전의 중요한 보안 및 데이터 격리
  • 정의
    • 각 AWS 리전은 다른 리전과 완벽하게 격리되어 독립적으로 가동되는 물리적 인프라의 집합
  • 특징/이점
    • 사용자가 명시적으로 데이터를 이동할 권한을 부여하지 않으면 리전의 경계를 벗어날 수 없으므로 철저한 데이터 주권 및 보안을 제공함
• AWS 리전 선택 시 4가지 주요 고려 사항
  • 1. 규정 준수 (Compliance)
    • 정의
      • 특정 국가나 지역의 현지 법률 및 법규(예: 데이터 보호법, 데이터 거버넌스 규제 등)를 준수하기 위해 데이터를 특정 지리적 영역 내에 보관해야 하는 법적 요구사항
    • 특징/이점
      • 리전을 선택할 때 가장 먼저(최우선적으로) 검토해야 하는 결정적인 요인임
      • 예시: 유럽 연합(EU)의 일반 데이터 보호 규정(GDPR) 준수 요구 사항에 따라 프랑크푸르트 등의 EU 리전에 고객 데이터를 저장하고 외부 반출을 차단하는 경우
  • 2. 근접성 (Proximity)
    • 정의
      • 실제 서비스를 이용하는 사용자 기반(고객)의 지리적 위치와 리전 데이터 센터 사이의 물리적 거리
    • 특징/이점
      • 사용자 기반과 지리적으로 가까운 리전을 택할수록 데이터 전송 시 지연 시간(Latency)이 최소화되며 애플리케이션의 반응성과 만족도가 대폭 향상됨
  • 3. 기능 가용성 (Feature Availability)
    • 정의
      • 배포하고자 하는 AWS의 특정 서비스, 신기능 혹은 특정 요구사항을 위한 하드웨어 세팅이 해당 리전에 준비되어 있는지의 여부
    • 특징/이점
      • AWS는 지속적으로 서비스를 신규 리전에 출시/확장하고 있으나 특정 신기능이나 특수 목적의 격리된 서비스(예: 미국 정부 전용 규정 준수를 위한 AWS GovCloud 리전) 등은 특정 리전에서만 선제적으로 제공될 수 있음
  • 4. 요금 (Pricing)
    • 정의
      • 리전별로 운영에 따른 전반적인 서비스 및 인프라의 청구 단가가 다르게 책정되는 과금 특성
    • 특징/이점
      • 동일한 사양의 AWS 서비스 및 기능이라 하더라도, 리전 데이터 센터가 위치한 국가의 현지 조세 체계(세법), 전력/에너지 공급 비용, 토지 비용 등의 운영 인프라 차이에 따라 청구 금액에 상당한 편차가 발생할 수 있음

aws 글로벌 인프라 자세히 살펴보기

• 고가용성 아키텍처 설계
  • 고가용성 (High Availability)
    • 정의
      • 시스템이 장애 없이 지속적으로 가동되어 서비스를 원활하게 제공할 수 있는 능력
    • 특징/이점
      • 특정 물리적 하드웨어나 구성 요소에 결함이 발생하더라도 비즈니스 연속성이 끊기지 않고 심각한 가동 중지 시간을 방지함
  • 민첩성 (Agility)
    • 정의
      • 급격하게 변화하는 비즈니스 요건이나 시장 조건에 맞춰 인프라 서비스를 신속하게 개발, 테스트 및 배포하는 능력
    • 특징/이점
      • 복잡한 하드웨어 수급 절차 없이 가상 자원을 즉각적으로 조달하여 인적/시간적 리소스 효율성을 극대화함
  • 탄력성 (Elasticity)
    • 정의
      • 실제 서비스 수요의 변동 폭에 따라 필요한 리소스 용량을 자동으로 확장(Scale-up)하거나 축소(Scale-down)하는 구조적 특성
    • 특징/이점
      • 트래픽이 폭증할 때는 자원을 확장하여 부하를 분산시키고, 사용량이 적을 때는 리소스를 줄여 불필요한 과금을 절감함
  • 이중화 아키텍처 (Redundancy Architecture)
    • 정의
      • 인프라 중단 사고에 사전 대응할 수 있도록 물리적으로 복제된 다중 백업 장치 및 자원을 상시 유지하는 아키텍처 기법
    • 특징/이점
      • 다중 가용 영역(Multi-AZ) 배포: 하나의 가용 영역에 장애가 일어나더라도 시스템이 이중화된 백업 영역으로 자동 장애 조치(Failover)되어 최종 사용자에게 무중단 서비스를 보장함
      • 다중 리전(Multi-Region) 배포: 한 국가 규모의 물리적 재난이 닥쳐 특정 리전 전체가 마비되더라도 다른 국가의 리전으로 트래픽을 안전하게 장애 조치(Failover)함
• AWS 글로벌 인프라 핵심 구성 요소
  • AWS 리전 (Region)
    • 정의
      • 전 세계에 지리적으로 분산되어 데이터 센터들을 물리적으로 호스팅하고 있는 거대한 독립 영역
    • 특징/이점
      • 개별 리전은 타 리전과 규정, 네트워크상으로 완전히 격리되어 운영됨
      • 모든 AWS 리전은 격리된 전력망과 연결망을 가지는 가용 영역(AZ)을 최소 3개 이상 보유함
  • 가용 영역 (Availability Zone, AZ)
    • 정의
      • 하나의 리전 내부에서 독립적인 물리 전력망, 공조 시스템, 통신 네트워크 연결을 지니도록 상호 격리 설계된 단일 또는 그 이상의 데이터 센터들의 집합
    • 특징/이점
      • 리전 내 다른 가용 영역들과는 초고속 전용 광케이블망으로 긴밀히 소통함
      • 특정 데이터 센터 시설의 화재나 단전 등 내결함성(Fault Tolerance) 시나리오에서 시스템 전반의 붕괴를 예방함
  • 엣지 로케이션 (Edge Location)
    • 정의
      • 유저에게 콘텐츠를 가장 빠른 속도로 전달(캐싱)하기 위해, 리전이나 가용 영역과는 별개로 전 세계 주요 도시 구석구석에 흩어져 있는 소규모 서버 거점
    • 특징/이점
      • 이미지, 비디오, 정적 자산 등 빈번히 조회되는 데이터를 최종 사용자 부근의 캐시에 보관하여 원천 리전 서버로 향하는 통신 거리를 획기적으로 낮추고 전송 속도를 단축함
      • Amazon CloudFront, Amazon Route 53, AWS Global Accelerator 등 핵심 엣지 네트워킹 서비스를 호스팅함
• 주요 엣지 및 관련 서비스
  • Amazon CloudFront
    • 정의
      • 웹 페이지, 비디오, 이미지, API 등 모든 동적/정적 웹 리소스를 낮은 지연 시간과 높은 속도로 최종 사용자에게 제공하는 글로벌 콘텐츠 전송 네트워크(CDN)
    • 특징/이점
      • 전 세계 엣지 로케이션망을 활용하여 밈 이미지나 대용량 파일 배포 속도를 향상시키고 트래픽 급증을 효과적으로 수용함
  • Amazon Route 53
    • 정의
      • 최종 사용자의 트래픽을 원활하게 AWS의 목적지 인프라로 연결 및 안내해 주는 클라우드 기반 고가용성 도메인 이름 시스템(DNS)
    • 특징/이점
      • 인간이 기억하기 편한 도메인 도식 문자열을 컴퓨터용 숫자형 IP 주소로 신속 변환하며 지연 시간이 최저인 최적의 서버 경로로 사용자를 라우팅함
  • AWS Outposts
    • 정의
      • AWS 인프라 서비스, API, 개발 도구를 고객의 자체 온프레미스 데이터 센터나 사무실 내부로 물리적으로 연장하여 직접 실행하게 지원하는 하이브리드 인프라 솔루션
    • 특징/이점
      • 극단적으로 높은 초저지연 로컬 데이터 처리가 필수적이거나, 특정 물리적 국가 경계 내에서만 데이터를 보관하고 동작시켜야 하는 엄격한 법률 규정을 완벽하게 만족함

인프라 및 자동화

• 코드형 인프라 (Infrastructure as Code, IaC)
  • 정의
    • 수동 클릭이나 개별 명령 실행 대신, 인프라의 모든 구성을 텍스트 파일(YAML, JSON 등)로 코딩하여 설계 청사진을 만드는 개발 방식
  • 특징/이점
    • 동일한 설정을 변경 없이 여러 차례 반복하여 신속하게 배포 가능
    • 콘솔 수동 조작 시 발생하는 인적 실수(오류)를 예방하고 재현하기 쉬운 환경 제공
    • Git 등의 소스 제어 도구를 활용하여 인프라 변경 이력을 체계적으로 관리 및 추적할 수 있음
• AWS CloudFormation
  • 정의
    • YAML 또는 JSON 형식의 CloudFormation 템플릿을 생성하여 대규모 AWS 리소스를 선언적 방식으로 정의하고 일괄 모델링/프로비저닝해 주는 AWS의 핵심 IaC 서비스
  • 특징/이점
    • 세부 빌드 명령어 대신 생성하고자 하는 리소스 스펙만 명시하면, CloudFormation이 알아서 백그라운드에서 AWS API를 호출하여 자원을 프로비저닝함
    • 여러 리전(Multi-Region)이나 다중 계정 전체에 동일 템플릿을 적용하여 오차 없는 고가용성 동일 환경을 손쉽게 복제하고 구축 시간 및 비용을 획기적으로 감축함
• AWS 리소스와의 상호 작용 (AWS API 호출 수단)
  • AWS Management Console
    • 정의
      • 웹 브라우저를 기반으로 시각적 UI 환경에서 마우스 클릭을 통해 AWS 리소스를 제어하고 조작하는 그래픽 관리 인터페이스 (GUI)
    • 특징/이점
      • 클라우드를 처음 다루는 초보자 또는 비개발자 직군도 진입장벽 없이 빠르게 액세스하여 조작할 수 있음
      • 청구 및 비용 대시보드 모니터링이나 시각 그래픽 중심의 특화 서비스(예: QuickSight, Neptune) 운영에 매우 유리함
  • 프로그래밍 방식 액세스 (Programmatic Access)
    • AWS CLI (Command Line Interface)
      • 정의
        • 로컬 컴퓨터 터미널이나 쉘 명령줄에서 명령어를 수동 입력하거나 스크립트 파일을 실행하여 AWS 리소스를 통제하는 도구
      • 특징/이점
        • 반복되는 인프라 관리 및 관리 태스크를 쉘 스크립트 자동화 작업(예: Amazon EBS 볼륨의 정기 백업 수행 스크립트)으로 구성할 수 있음
    • AWS SDK (Software Development Kit)
      • 정의
        • 개발자가 사용하는 프로그래밍 언어(Java, Python 등)에 호환되는 라이브러리 API를 제공하여, 자체 구축한 애플리케이션 소스 코드 내에서 AWS의 기능을 내재화하고 통합하게 돕는 소프트웨어 개발 키트
      • 특징/이점
        • 앱 백엔드 프로세스의 일부분으로 실시간 AWS 서비스를 기동할 수 있음 (예: SDK를 활용해 애플리케이션에 유입된 사용자의 파일을 Amazon S3 스토리지에 즉시 자동 저장)

서버리스 컴퓨팅 소개

• AWS 컴퓨팅 옵션 비교 (비관리형, 관리형, 서버리스)
  • 비관리형 서비스 (Unmanaged Services)
    • 정의
      • 기본적인 물리적 인프라만 AWS가 제공하고, 운영 체제(OS) 패치, 애플리케이션 설치, 네트워크/방화벽 구성 등 나머지 모든 구성과 관리를 고객이 직접 제어하는 서비스
    • 대표 서비스
      • Amazon EC2
    • 특징
      • 인스턴스 전체에 대해 아주 높은 수준의 사용자 지정 제어 권한(Control)을 제공하지만, 사용자의 유지보수 및 관리 오버헤드가 큼 (수동 관리)
  • 관리형 서비스 (Managed Services)
    • 정의
      • 사용자가 자신의 요구사항에 맞춰 초기 설정을 구성하면, 가동 유지, 패치, 업그레이드, 장애 극복 등의 운영 작업을 AWS가 백그라운드에서 직접 처리해주는 서비스
    • 대표 서비스
      • Elastic Load Balancing (ELB), Amazon SQS, Amazon SNS 등
    • 특징
      • 인프라 관리 부담을 줄여주므로 사용자는 인프라 유지보수보다 애플리케이션 구축 및 비즈니스 로직 설계에 집중할 수 있음
  • 서버리스/완전관리형 서비스 (Serverless / Fully Managed)
    • 정의
      • 사용자가 애플리케이션을 구동하기 위한 가상 서버나 리소스를 직접 보거나 관리할 필요가 전혀 없는 서비스
    • 대표 서비스
      • AWS Lambda 등
    • 특징
      • 리소스 프로비저닝, 고가용성, 하드웨어 유지 관리, 자동 스케일링이 모두 완전 자동 처리되며 사용자는 작성한 코드 자체만 배포하고 관리함 (편의성에 최적화)

aws 서버리스, 컨테이너, 솔루션 개요

aws lambda

• AWS Lambda
  • 정의
    • 서버를 별도로 프로비저닝하거나 직접 관리하지 않고도, 특정 이벤트(트리거)에 반응하여 코드를 바로 실행하는 대표적인 서버리스(Serverless) 컴퓨팅 서비스
  • 작동 원리
    • 사용자가 코드를 작성하여 Lambda 함수로 업로드하고 이벤트 소스(S3 파일 업로드, SQS 메시지 생성, HTTP 요청 등)를 트리거로 세팅함
    • 해당 이벤트가 발생할 때만 코드가 가동되며, 평상시 유휴 상태에는 하드웨어 리소스나 비용 소모가 없음
  • 요금 체계
    • 실제 코드가 수행된 시간(밀리초 단위로 정확히 계산) 및 함수에 할당한 메모리 용량 크기에 따라 비용이 부과됨
  • 실행 제한 (매우 중요)
    • 최대 지속 시간 제한: 15분
    • 15분 이내에 완료되지 않는 장기 프로세싱 작업에는 적합하지 않으며, 이 경우 다른 컴퓨팅 인스턴스를 선택하거나 작업을 15분 단위 세그먼트로 분리해야 함
  • 프로그래밍 언어 지원
    • Java, Python, Node.js 등을 런타임 환경으로 기본 지원하며, 기타 언어는 사용자 지정 런타임(Custom Runtime)을 구축하여 가동 가능
  • AWS 서비스 통합 및 데모 (SQS 트리거 기반 Lambda 작동 프로세스)
    • 1. 큐 및 메시지 준비
      • SQS 콘솔에서 대기열을 생성한 뒤 테스트 메시지(페이로드)를 전송하여 대기시킴
    • 2. 청사진 (Blueprint) 활용
      • 빠른 연동 테스트를 위해 SQS와 연계된 검증된 템플릿(청사진)을 활용하여 Node.js, Python 등의 런타임 환경으로 Lambda 함수(예: Lambert)를 신속하게 생성함
    • 3. 실행 역할 (Execution Role) 설정
      • Lambda 함수가 SQS 대기열을 지속적으로 감시하고 메시지를 가져올 수 있도록 Amazon SQS 폴러 정책 템플릿 권한이 인가된 전용 실행 역할(예: Demo_Lambert_Role)을 반드시 지정해 주어야 함
    • 4. 트리거 (Trigger) 매핑
      • 대상 SQS 대기열을 Lambda 함수의 유효한 트리거 소스로 구성하여 연결 설정을 완료함
    • 5. 메시지 폴링 및 자동 삭제
      • SQS 대기열에 새로운 메시지가 유입되면 Lambda 함수가 이를 인지하여 지극히 빠른 속도로 메시지를 가공/처리하며, 처리가 성공한 메시지는 SQS 대기열에서 자동으로 영구 소멸됨
    • 6. 모니터링 및 로깅 감사
      • Lambda 콘솔의 Monitor 탭을 통해 지표를 조회하거나, 연동된 Amazon CloudWatch Logs의 로그 그룹(Log Groups) 및 로그 스트림(Log Streams)을 열어 함수가 처리한 실제 데이터 내용과 ID 로그를 검증하고 감사 추적할 수 있음
• Lambda 사용 사례
  • 실시간 이미지 처리
    • 정의: 소셜 미디어 등에 사진 업로드 시 Lambda가 트리거되어 썸네일 크기로 변환 및 필터 처리 자동화
  • 개인화 콘텐츠 전송
    • 정의: 뉴스 피드 접속 등의 이벤트 트리거 시 사용량에 따라 개인 추천 엔진을 자동 가동 및 최적 데이터 송신
  • 온라인 게임의 실시간 이벤트 처리
    • 정의: 점수 획득, 업적 해제 등의 이벤트를 수천 명의 플레이어로부터 실시간으로 받아 서버리스 상태에서 갱신 및 처리

aws 기반의 컨테이너 및 오케스트레이션

• 컨테이너 (Containers)
  • 정의
    • 애플리케이션의 코드, 런타임, 라이브러리, 종속성, 설정 파일 등을 단일 패키지로 묶어 어떤 컴퓨팅 환경에서든 동일하게 작동하도록 격리하는 이식성 높은 가상화 환경
  • 컨테이너 vs 가상 머신(VM)
    • 컨테이너는 호스트 OS 커널을 공유하여 가볍고 부팅 속도가 매우 빠르며 리소스 효율성이 우수함
    • VM은 하이퍼바이저 위에서 각각 별개의 전체 OS를 가동하므로 속도가 느리고 인프라 자원을 상대적으로 많이 소모함
• 컨테이너 오케스트레이션 (Container Orchestration)
  • 정의
    • 수십~수천 개에 이르는 컨테이너의 전체 수명 주기(시작, 중지, 업데이트, 네트워킹, 오토 스케일링, 오류 복구 등)를 자동화하여 통합 관리해 주는 서비스
• AWS 컨테이너 서비스 분류
  • 1. 레지스트리 (Registry)
    • Amazon ECR (Elastic Container Registry): 컨테이너 이미지를 보관하는 ‘창고’
      • 정의: 안전하게 컨테이너 이미지를 보관, 관리, 배포하는 완전 관리형 OCI 표준 준수 레지스트리 서비스
  • 2. 오케스트레이션 (Orchestration)
    • Amazon ECS (Elastic Container Service)
      • 정의: Docker 컨테이너를 가동 및 관리할 수 있도록 지원하는 AWS 독자적인 고성능 컨테이너 오케스트레이션 서비스
      • 특징: 간소하고 통합된 기능 제공. 소규모 팀이나 트래픽 유동성이 있는 애플리케이션 구축에 적합
    • Amazon EKS (Amazon Elastic Kubernetes Service)
      • 정의: 오픈소스 컨테이너 관리 프레임워크인 Kubernetes를 AWS 환경에서 쉽게 다룰 수 있게 보장하는 관리형 서비스
      • 특징: 오픈소스 생태계 통합 및 하이브리드/대규모 배포 시 우수한 통제력과 유연성을 제공함
  • 3. 컴퓨팅/호스팅 플랫폼 (Compute Platforms)
    • Amazon EC2 시작 유형
      • 정의: 가상 서버 인프라를 사용자가 직접 구성하고 가상 머신 수준의 세부 설정을 제어하는 방식
      • 특징: 하드웨어 및 특수한 네트워크 설정의 커스터마이징이 가능하나 서버 유지 관리 오버헤드가 수반됨
    • AWS Fargate 시작 유형
      • 정의: 서버를 프로비저닝하거나 관리할 필요가 없는 컨테이너 전용 서버리스(Serverless) 컴퓨팅 엔진
      • 특징: 컨테이너의 배치 및 가동 스케일링을 AWS가 100% 관리해주며 사용자는 사용한 컨테이너 자원에 대해서만 지불함 (ECS와 EKS 모두 Fargate 시작 유형을 지원함)

추가 컴퓨팅 서비스

• AWS Elastic Beanstalk
  • 정의
    • Java, Python, Node.js, Docker 등으로 작성된 웹 애플리케이션 및 서비스를 신속하게 배포, 관리, 스케일링할 수 있도록 돕는 완전 관리형 서비스 (PaaS)
  • 특징
    • 사용자가 소스 코드와 구성 설정만 업로드하면 인프라 프로비저닝, 오토 스케일링, 로드 밸런싱, 애플리케이션 상태 모니터링을 자동으로 대행함
    • 인프라를 직접 구축할 필요는 없지만, 프로비저닝된 하위 AWS 기본 리소스(EC2 등)에 대한 세부적인 제어 및 수정 권한은 여전히 소유함
  • 적합한 대상
    • 인프라 설정 복잡성을 줄이고 즉시 배포하려는 웹 애플리케이션, RESTful API, 마이크로서비스
• AWS Batch
  • 정의
    • AWS 인프라 리소스를 직접 관리할 필요 없이 대규모 병렬 배치(Batch) 컴퓨팅 워크로드를 자동으로 예약하고 실행해 주는 완전 관리형 서비스
  • 특징
    • 작업의 우선순위와 컴퓨터 리소스 사양에 맞춰 필요한 최적의 컴퓨팅 인프라(EC2 등) 풀을 자동으로 증설, 스케일링, 배포 및 회수함
  • 적합한 대상
    • 과학 계산 시뮬레이션, 대용량 빅데이터 및 유전체 분석 처리, 미디어 트랜스코딩, 기계 학습 모델 훈련
• Amazon Lightsail
  • 정의
    • 저렴하고 예측 가능한 정액제 월별 요금으로 가상 프라이빗 서버(VPS), 인스턴스, 스토리지, DB, 네트워킹을 간편하게 패키지로 제공하는 서비스
  • 특징
    • 복잡한 AWS 관리 콘솔의 설정 없이도 매우 간단한 제어판을 제공하여 인프라 구축의 허들을 대폭 낮춤
  • 적합한 대상
    • 소규모 비즈니스 웹사이트, 저트래픽 개인 블로그(예: WordPress), 개발자 학습용 샌드박스, 단순한 개발/테스트 환경
• AWS Outposts
  • 정의
    • AWS 클라우드 인프라, 서비스, API, 도구를 고객 온프레미스 데이터 센터나 로컬 물리 서버 환경으로 확장하여 서비스하는 완전 관리형 하이브리드 솔루션
  • 특징
    • AWS 퍼블릭 클라우드 환경과 자사 온프레미스 로컬 인프라 간에 완전히 일관된 작동 경험과 도구 세트를 제공함
  • 적합한 대상
    • 규정 준수 및 현지 법률로 인한 물리적 데이터 보존(Data Residency) 요구 충족, 로컬 레거시 시스템과의 연동을 위한 극도로 짧은 지연 시간(Low Latency) 요구 상황

0. 용어설명

• 워크로드

  • 어떤 하나의 완전한 서비스 시스템 단위

• 테넌시(Tenancy)

  • 가상 서버(EC2 인스턴스)가 물리적인 하드웨어(호스트 서버)에 배치되는 방식과 격리 수준을 결정하는 설정

1. amazon ec2 개요 및 기본 개념

• Amazon EC2 (Elastic Compute Cloud)
  • 정의
    • AWS 클라우드에서 크기 조정이 가능한 가상 서버(인스턴스)를 온디맨드로 임대하여 실행할 수 있는 서비스
  • 이점 및 작동 특징
    • 온프레미스 대비 물리적인 서버 인프라 구축 비용과 조달 시간이 전혀 들지 않음
    • 인스턴스가 실행 중(Running) 상태일 때만 사용한 시간만큼 비용을 지불하며, 중지(Stopped) 또는 종료(Terminated) 시 요금 부과가 중단됨
• 가상 머신(VM) 및 멀티테넌시 (Multi-tenancy)
  • 정의
    • 하나의 물리적인 호스트 컴퓨터 리소스를 여러 대의 독립적인 가상 머신(VM) 인스턴스가 분할하여 공유하는 환경
  • 하이퍼바이저 (Hypervisor)
    • 정의
      • 물리 호스트 컴퓨터 위에 가상 머신을 생성하고, 가상 머신 간 리소스 분배 및 철저한 격리를 보장하는 소프트웨어
    • 특징
      • AWS가 물리 호스트 하드웨어와 하이퍼바이저를 완전히 관리하므로, 고객은 복잡한 인프라 관리 없이 운영체제(OS) 수준에서 인프라를 통제함
  • 공유 테넌시 (Shared Tenancy)
    • 정의
      • 하나의 거대한 물리 서버 위에서 내 가상 서버(EC2)와 다른 고객들의 가상 서버가 이웃집처럼 함께 구동되는 방식(일반적인 멀티테넌시 형태)
  • 전용 테넌시 (Dedicated Tenancy)
    • 정의
      • 하드웨어 수준에서 다른 고객과 섞이는 것이 싫을 때, 해당 물리 서버 전체를 우리 회사 가상 서버들만 쓰도록 통째로 임대하는 방식(싱글 테넌시에 가까운 형태)
• EC2 제어 권한 및 스케일링
  • 통제 범위
    • Windows 또는 Linux 운영체제(OS) 선택 및 소프트웨어, 웹 애플리케이션, 데이터베이스 등의 완전 제어 및 설치 권한 보유
  • 수직적 스케일링 (Vertical Scaling)
    • 정의
      • 가동 중인 EC2 인스턴스의 리소스 한계를 넘었을 때, 해당 인스턴스의 사양(CPU, 메모리 크기 등)을 직접 더 크게 변경하는 방식 (스케일 업 / 스케일 다운)

2. amazon ec2 인스턴스 유형

• 인스턴스 패밀리 (Instance Families)
  • 정의
    • 특정 워크로드에 최적화하여 CPU, 메모리, 스토리지, 네트워킹 자원을 다양하게 배합한 가상 서버 규격 그룹
• 5가지 인스턴스 패밀리 분류 (시험 단골 주제)
  • 범용 (General Purpose)
    • 정의
      • 컴퓨팅, 메모리, 네트워킹 자원을 균등하고 균형 있게 제공하는 인스턴스
    • 적합한 태스크
      • 웹 서버, 코드 리포지토리 등. 워크로드의 자원 요구 수준을 사전에 잘 모르는 상태에서 시작할 때 권장됨
  • 컴퓨팅 최적화 (Compute Optimized)
    • 정의
      • 강력한 프로세서(CPU) 연산 파워에 고도로 집중된 인스턴스
    • 적합한 태스크
      • 게임 서버, 고성능 컴퓨팅(HPC), 배치 작업, 기계 학습(ML) 연산, 과학 모델링
  • 메모리 최적화 (Memory Optimized)
    • 정의
      • 대규모 데이터셋을 메모리(RAM) 위에서 빠르게 처리하기 위해 고용량 메모리를 장착한 인스턴스
    • 적합한 태스크
      • 메모리 내 데이터베이스(In-memory DB), 실시간 빅데이터 분석
  • 가속화된 컴퓨팅 (Accelerated Computing)
    • 정의
      • CPU 이외에 그래픽 카드(GPU)나 FPGA 등 하드웨어 가속기(보조 프로세서)를 장착하여 전용 가속 기능을 제공하는 인스턴스
    • 적합한 태스크
      • 부동 소수점 수 계산, 3D 그래픽 처리, 데이터 패턴 매칭
  • 스토리지 최적화 (Storage Optimized)
    • 정의
      • 로컬 스토리지에 존재하는 초대형 데이터셋에 대해 매우 높은 순차적 읽기/쓰기(I/O) 성능을 보장하는 인스턴스
    • 적합한 태스크
      • 분산 파일 시스템, 데이터 웨어하우스용 고성능 스토리지, 대용량 DB
• 인스턴스 크기 선택 및 가상화 유연성
  • 특징
    • 인스턴스 크기가 커질수록 컴퓨팅 용량이 늘어나지만 비용 또한 함께 증가하므로, 비즈니스 예산과의 균형을 맞추는 것이 중요함
    • 한 번 프로비저닝한 인스턴스 유형과 크기에 영구적으로 종속되지 않으며, 요구 성능에 따라 다른 규격으로 신속하게 변경 및 전환할 수 있음

3. aws 리소스를 프로비저닝하는 방법

• AWS API (Application Programming Interface)
  • 정의
    • AWS 서비스와 상호 작용하는 규칙을 사전에 정의해 둔 인터페이스
  • 특징
    • 리소스 생성, 변경, 삭제 등 AWS에서 수행되는 모든 관리 작업은 백그라운드에서 API 직접 호출 (API Call)을 통해 이루어짐
• AWS API 상호 작용 방법 3가지 (시험 단골 주제)
  • AWS Management Console (AWS 관리 콘솔)
    • 정의
      • 웹 브라우저를 기반으로 마우스 클릭을 통해 리소스를 제어하는 그래픽 사용자 인터페이스 (GUI)
    • 특징
      • 시각적이고 직관적이어서 클라우드 학습 초기 단계, 테스트 환경 구축, 예산/청구서 조회, 리소스 모니터링에 매우 적합함
      • 프로덕션 환경에서 대규모 리소스를 반복적으로 수동 배포할 경우, 체크 실수나 오타 등 휴먼 에러(수동 오류)가 발생할 위험이 있음
  • AWS CLI (Command Line Interface)
    • 정의
      • 운영체제의 터미널/명령줄을 사용하여 텍스트 기반 명령어로 AWS 서비스를 호출하는 도구
    • 특징
      • 텍스트 명령어(예: aws ec2 run-instances로 인스턴스 생성)를 통해 작동하므로, 셸 스크립팅 등을 이용한 자동화가 가능하여 오류 없는 예측 가능한 인프라 배포에 유리함
      • 브라우저 기반의 사전 설치 터미널인 AWS CloudShell을 통해서도 간편하게 실행할 수 있음
  • AWS SDK (Software Development Kit)
    • 정의
      • 특정 프로그래밍 언어(Python, Java, C# 등)용 라이브러리와 API 모음집을 제공하여 코드로 AWS 리소스를 다룰 수 있게 해주는 소프트웨어 개발 키트
    • 특징
      • 사용자의 애플리케이션 소스 코드 자체에 AWS 리소스 제어(인스턴스 목록 조회, 파일 업로드 등) 기능을 내장하여 고도로 정교한 프로그래밍 제어를 구현할 때 사용됨
• 컴퓨팅 및 공동 책임 (Shared Responsibility in Computing)
  • 대전제
    • AWS는 클라우드 자체의 보안(하드웨어, 물리 인프라, 하이퍼바이저)을 담당함
    • 고객은 클라우드 내부의 보안(애플리케이션, 데이터, 액세스 제어)을 책임짐
  • 비관리형 서비스 (Unmanaged Services)의 책임 모델
    • 정의
      • 사용자가 필요한 인프라의 세부 설정, 보안 구성 및 관리 태스크를 직접 수행해야 하는 서비스
    • Amazon EC2 인스턴스 배포 시 고객의 책임 범위
      • 가상 가상 방화벽인 보안 그룹(Security Groups) 설정
      • 게스트 운영 체제(OS) 관리, 보안 패치 및 업데이트 적용
      • 데이터 암호화 및 인스턴스 내 구동 소프트웨어 보안 구성

4. 데모: amazon ec2 인스턴스 시작

• EC2 인스턴스 생성 시 주요 구성 요소 (시험 연계 포인트)
  • AMI (Amazon Machine Image)
    • 정의
      • 인스턴스를 시작하는 데 필요한 운영 체제(OS)와 기본 애플리케이션 구성이 들어 있는 템플릿
    • 구성 요소
      • 운영 체제 (OS), 스토리지 설정, 하드웨어 아키텍처 유형, 인스턴스 시작 권한, 사전 설치된 추가 소프트웨어
      • 단 1개의 AMI를 템플릿으로 사용하여 완전히 동일한 설정을 가진 다수의 EC2 인스턴스를 동시에 시작할 수 있음
    • AMI를 사용하는 3가지 방법 (획득 경로)
      • 자체 AMI 생성 (사용자 지정)
        • 필요에 따라 특정 소프트웨어 및 구성을 미리 세팅하여 빌드하는 나만의 맞춤형 이미지
      • 사전 구성된 AWS AMI
        • 일반적인 운영체제 및 핵심 소프트웨어가 탑재되어 AWS에서 기본 제공하는 표준 이미지
      • AWS Marketplace 구매
        • 특정 사용 사례에 맞추어 전문 서드 파티 공급업체가 소프트웨어를 구성하여 제공하는 인증된 이미지를 구매하여 사용
    • AMI의 반복성 (Repeatability)
      • 정의
        • 모든 새 인스턴스에 일관된 환경을 보장하여 재현 가능하게 만드는 특성
      • 이점
        • 개발 및 테스트 환경이 완벽히 일치하여 배포 규모 조정에 유리하고, 설정 누락 등 휴먼 에러를 대폭 줄이며, 대규모 클라우드 환경 관리가 매우 단순해짐
  • 인스턴스 유형 (Instance Type)
    • 정의
      • 인스턴스에 할당할 CPU 및 메모리 사양 결정 (예: t2.micro는 1 vCPU, 1GB RAM 제공)
  • 키 페어 (Key Pair)
    • 정의
      • 생성된 인스턴스에 안전하게 원격 접속하기 위한 비밀키 인증 방식
    • 특징
      • AWS 클라우드에 삽입되는 퍼블릭 키(Public Key)와 사용자가 다운로드하여 로컬에 안전하게 보관하는 프라이빗 키(Private Key) 한 쌍으로 작동함
  • 네트워크 설정 (Network Settings)
    • 특징
      • 인스턴스로 들어오고 나가는 네트워크 트래픽 규칙 설정 (예: 외부 인터넷 사용자의 웹 서비스 접속을 위해 HTTP 트래픽 허용 옵션 활성화)
  • 스토리지 구성 (Configure Storage)
    • 특징
      • 인스턴스에 가상 디스크 공간을 추가하는 설정 (예: gp3 EBS 볼륨을 할당하여 저장 공간 제공)
  • 사용자 데이터 (User Data)
    • 정의
      • 인스턴스가 최초 부팅(시작)될 때 백그라운드에서 자동으로 딱 한 번 실행되는 셸 스크립트
    • 특징
      • 부팅 시점에 소프트웨어 자동 설치 및 환경 설정 작업을 자동화할 수 있음 (예: Nginx 웹 서버 자동 설치 및 기동 스크립트 구동)
• 가동 확인
  • 특징
    • 인스턴스가 실행 중(Running) 상태가 되면, 할당된 퍼블릭 IP 주소를 웹 브라우저 주소창에 입력하여 Nginx 등 가동 중인 웹 서버의 작동 여부를 즉시 검증할 수 있음

5. amazon ec2 요금

• EC2 6가지 핵심 요금 옵션 (시험 필수 출제)
  • 온디맨드 인스턴스 (On-Demand)
    • 정의
      • 장기 약정이나 선불금 없이, 인스턴스가 실행(Running)되는 동안 사용한 컴퓨팅 용량에 대해서만 비용을 지불하는 모델
    • 특징
      • 사용 패턴의 기준치(Baseline)를 파악하지 못한 초기 단계, 단기 테스트 및 실험, 예측이 불가능한 워크로드에 가장 권장됨
  • 절감형 플랜 (Savings Plans)
    • 정의
      • 1년 또는 3년 기간 동안 시간당 일정 수준의 컴퓨팅 사용량(예: 시간당 $10 등)을 유지하기로 약정하여 최대 72%의 비용을 절감하는 요금제
    • 특징
      • 유연성이 매우 높음. 인스턴스 패밀리, 크기, OS, 테넌시, 리전 변경에 제약을 받지 않고 EC2 할인 적용 가능
      • EC2뿐만 아니라 Fargate, Lambda, SageMaker 사용량에도 동일하게 공유하여 할인이 적용됨
  • 예약 인스턴스 (Reserved Instances - RI)
    • 정의
      • 꾸준하고 예측 가능한 상태(Steady-state)의 워크로드에 대해 1년 또는 3년 기간으로 사용 약정을 체결하여 온디맨드 대비 최대 75% 비용을 절감하는 옵션
    • 특징
      • 3가지 결제 옵션 제공: 전액 선결제(All Upfront), 부분 선결제(Partial Upfront), 선결제 없음(No Upfront)
      • 동일 인스턴스 패밀리 내에서 유연한 크기 조정 및 리전 내 여러 가용 영역(AZ)에 할인이 자동 적용됨
  • 스팟 인스턴스 (Spot Instances)
    • 정의
      • AWS 내부의 미사용 예비 컴퓨팅 용량을 요청하여 온디맨드 가격 대비 최대 90% 할인된 가격으로 사용하는 인스턴스
    • 특징
      • AWS에 용량이 부족해지면 인스턴스가 언제든지 강제 회수(중단)될 수 있으며, 회수 전 2분의 경고(알림)가 제공됨
      • 시스템이 중단되어도 무방한 유연한 시작/종료 일괄(배치) 처리 작업, 데이터 분석, 대규모 테스트 워크로드에 매우 적합함
  • 전용 호스트 (Dedicated Hosts)
    • 정의
      • 고객이 독점적으로 사용할 수 있도록 완전히 분리된 실제 물리적 서버 전체를 예약하는 방식
    • 특징
      • 인스턴스의 하드웨어 물리 배치 및 리소스 할당을 직접 완벽하게 제어할 수 있음
      • 기존 소프트웨어 라이선스(BYOL - Bring Your Own License, 예: Windows, SQL Server)를 그대로 유지해야 하거나, 극도로 엄격한 물리 격리 및 규정 준수 요구가 있는 경우 사용
  • 전용 인스턴스 (Dedicated Instances)
    • 정의
      • 다른 AWS 계정 고객의 인스턴스와 물리적으로 격리된 단일 테넌트 하드웨어에서 실행되는 인스턴스
    • 특징
      • 전용 호스트와 달리 실제 물리 서버의 인스턴스 배치나 리소스 세부 할당 제어 권한은 갖지 못하지만, 계정 수준의 물리적 격리 혜택과 공유 인프라의 유연성을 동시에 가질 수 있음
• Amazon EC2 용량 예약 (Capacity Reservations)
  • 정의
    • 특정 가용 영역(AZ)에서 컴퓨팅 용량을 확실하게 미리 확보해 두는 설정
  • 특징
    • 예약한 리소스를 실제로 실행하지 않고 비워두더라도 온디맨드 요금과 동일하게 요금이 청구됨
    • 용량 요구 사항이 엄격하고 절대 서비스 중단이 발생하면 안 되는 중요한(비즈니스 크리티컬) 워크로드에 사용됨

자동 스케일링 및 로드 밸런싱

1. Amazon EC2 스케일링

• 확장성 (Scalability) vs 탄력성 (Elasticity)
  • 확장성 (Scalability)
    • 정의
      • 늘어난 로드를 정상 처리하기 위해 자원을 추가할 수 있는 시스템의 구조적 능력
    • 특징
      • 단기적인 스케일링보다 주로 예상되는 성장을 감당하기 위한 장기적인 용량 계획에 활용됨
  • 탄력성 (Elasticity)
    • 정의
      • 실시간 수요의 변화에 따라 필요 리소스를 자동으로 확보하거나 불필요 리소스를 차단하는 동적 조절 기능
    • 특징
      • 피크 트래픽 타임에는 자동 증설(스케일 아웃)하고, 한적한 밤 시간 등 수요가 적어지면 자동 해제(스케일 인)하여 최상의 비용 효율성을 보장함
• 수평적 스케일링 (Horizontal) vs 수직적 스케일링 (Vertical)
  • 수평적 스케일링 (스케일 아웃 / 스케일 인)
    • 정의
      • 인프라 자원 풀에 동일한 규격의 서버 인스턴스를 추가하거나 삭제하는 방식 (병렬 처리 개수를 증가시킴)
  • 수직적 스케일링 (스케일 업 / 스케일 다운)
    • 정의
      • 구동 중인 개별 단일 가상 서버 자체의 사양(CPU 파워, 메모리 용량 등)을 높이거나 낮추는 방식
• 고가용성을 위한 다중 가용 영역(AZ) 이중화 배포
  • 특징
    • 단일 장애점(SPOF - Single Point of Failure)을 방지하기 위해, 동일 아키텍처의 중복 인스턴스들을 서로 다른 가용 영역(AZ)에 분산 배포하는 것을 모범 설계 사례로 규정함
• Amazon EC2 Auto Scaling
  • 정의
    • 서비스 수요 변화에 발맞춰 실행 중인 EC2 인스턴스의 개수를 자동으로 증감시켜 가용성을 확보하는 완전 관리형 서비스
  • 작동 조건
    • Amazon CloudWatch가 수집한 핵심 지표(CPU 사용률, 네트워크 입출력 등) 데이터를 모니터링하여 자동으로 스케일링 작업이 트리거됨
  • 2가지 조정 접근 방식 (시험 출제율 높음)
    • 동적 스케일링 (Dynamic Scaling)
      • 실시간 수요 및 트래픽 변동치(예: CPU 점유율 80% 초과)에 즉각 반응하여 자원을 늘림
    • 예측 스케일링 (Predictive Scaling)
      • 과거 데이터 패턴과 기계 학습을 통해 예상되는 트래픽 패턴을 예측하고 미리 적절한 수의 인스턴스를 선제적으로 확보함
  • Auto Scaling 그룹 (ASG)의 3가지 핵심 설정값 (시험 빈출)
    • 최소 용량 (Minimum Capacity)
      • 정의: 워크로드를 상시 가동하기 위해 유지해야 하는 물리적 최소 인스턴스 수. 시스템이 이 수치 이하로는 축소되지 않음
    • 원하는 용량 (Desired Capacity)
      • 정의: Auto Scaling이 최적의 상태로 가동하기 위해 목표로 삼는 이상적인 인스턴스 수. 기본적으로 최소 용량과 연동됨
    • 최대 용량 (Maximum Capacity)
      • 정의: 트래픽 폭발 시 비용 과다 지출 및 초과 스케일링을 제한하는 인스턴스 개수의 상한선 임곗값

2. Elastic Load Balancing을 사용하여 트래픽 전달

• Elastic Load Balancing (ELB)
  • 정의
    • 들어오는 애플리케이션 트래픽을 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 자동으로 분산시켜 시스템 성능과 신뢰성을 최적화하는 완전 관리형 부하 분산 서비스
  • 특징
    • 외부 인터넷 트래픽(퍼블릭)뿐만 아니라 내부 백엔드 아키텍처 티어 간의 트래픽(프라이빗)도 관리할 수 있음
    • 로드 밸런서 자체의 스케일링이 자동으로 수행되어, 트래픽 유동성에 탄력적으로 대응함
• ELB의 핵심 이점 (시험 연계)
  • 효율적인 트래픽 분산
    • 정의
      • 여러 가용 서버들로 트래픽을 고르게 나누어 단일 서버의 오버로드를 예방하고 전반적인 리소스 사용을 극대화함
  • Auto Scaling과의 연동 및 고가용성 보장
    • 정의
      • Auto Scaling 그룹과 직접 유기적으로 연동하여, 백엔드 인스턴스가 생성되거나 해제될 때 동적으로 라우팅 풀에 추가 및 제외시킴
      • 사용 가능한 정상 서버(인스턴스)로만 요청을 분산하여 무중단 상태를 유지함
  • 시스템 결합 해제 (Decoupling) 및 관리 간소화
    • 정의
      • 프런트엔드 서비스가 개별 백엔드 인스턴스의 유동적인 IP를 직접 추적할 필요 없이, ELB가 제공하는 단일 웹 URL(단일 접점)만 바라보도록 설계하여 시스템 의존성을 완전히 분리함
      • 하드웨어 패치, 유지 보수, 장애 복구 등의 수동 운영 오버헤드를 경감시킵니다.
• ELB의 4가지 주요 라우팅 방법
  • 라운드 로빈 (Round Robin)
    • 정의
      • 가동 중인 사용 가능한 모든 서버에 순차적으로 트래픽을 균등하게 분산시킴
  • 최소 연결 (Least Connections)
    • 정의
      • 현재 활성화된 세션/연결 수가 가장 적은 서버를 식별하여 새 트래픽을 라우팅함
  • IP 해시 (IP Hash)
    • 정의
      • 클라이언트의 IP 주소를 고유값으로 매핑하여 항상 지정된 동일 서버로 일관되게 트래픽을 보냄 (세션 유지 필요 시 유용)
  • 최소 응답 시간 (Least Response Time)
    • 정의
      • 응답 대기 시간이 가장 신속한 서버를 찾아 트래픽을 우선 전달하여 대기 시간을 최소화함

3. 메시징 및 대기열 처리

• 애플리케이션 아키텍처와 결합도 (Coupling)
  • 긴밀한 결합 (Tightly Coupled) / 모놀리스 (Monolith) 아키텍처
    • 정의
      • 애플리케이션의 모든 구성 요소(데이터베이스, 웹 서버, 비즈니스 로직 등)가 서로 직접 연결되어 동기적으로 통신하는 방식
    • 단점
      • 단 하나의 구성 요소에 장애가 발생하더라도 전체 시스템이 중단되는 연쇄 실패가 발생할 위험이 큼
  • 느슨한 결합 (Loosely Coupled) / 마이크로서비스 (Microservices) 아키텍처
    • 정의
      • 각 구성 요소가 독립된 엔터티로 분리되어 메시지 대기열이나 이벤트를 통해 비동기적으로 간접 통신하는 방식
    • 장점
      • 특정 서비스에 장애가 발생해도 버퍼(대기열)가 메시지를 안전하게 보관하므로, 전체 시스템으로 장애가 전파되지 않고 가용성과 복원력이 유지됨
• 느슨한 결합을 지원하는 3대 AWS 통신 서비스 (시험 단골 주제)
  • Amazon SQS (Simple Queue Service)
    • 정의
      • 소프트웨어 구성 요소 간에 모든 대규모 메시지를 전송, 저장, 수신할 수 있도록 지원하는 비동기식 메시지 대기열 서비스 (Pull 방식)
    • 작동 원리
      • 보낸 쪽(송신자)이 메시지 데이터를 대기열에 담아두면, 받는 쪽(수신자)이 원할 때 대기열에서 이를 꺼내(검색) 처리한 뒤 메시지를 명시적으로 삭제함
    • 장점
      • 수신 서버가 일시적으로 가동 중단되거나 트래픽이 급증(버스트)해도 대기열에 메시지가 안전하게 보존되므로 데이터 유실을 완전 방지함
  • Amazon SNS (Simple Notification Service)
    • 정의
      • 게시자-구독자(Pub-Sub) 모델을 기반으로, 하나의 주제(Topic)에 등록된 다수의 구독자들에게 알림 메시지를 즉시 전송하는 완전 관리형 서비스 (Push 방식)
    • 작동 원리
      • 게시자가 특정 메시지를 게시하면, 대기하지 않고 모바일 푸시 알림, SMS 문자, 이메일, HTTP 웹훅 또는 Lambda 함수 등의 구독자들에게 즉각 전달(팬아웃)함
    • SQS와의 결정적 차이점
      • SQS는 메시지가 처리될 때까지 대기열에서 수령을 기다리지만, SNS는 수령 대기 없이 즉각적인 푸시 응답 및 다중 전송을 수행함
  • Amazon EventBridge
    • 정의
      • 다양한 소스(자체 커스텀 앱, AWS 서비스, 서드파티 SaaS 소프트웨어)에서 발생하는 실시간 데이터를 이벤트 버스(Event Bus)를 통해 다른 타깃 애플리케이션으로 안전하게 라우팅하는 서버리스 이벤트 버스 서비스
    • 장점
      • 이벤트 기반 시스템(Event-Driven System)의 중앙 허브 역할을 하여 서비스 간 통신 흐름의 수신, 필터링, 변환, 라우팅 처리를 극도로 단순화함

aws 클라우드

1. 클라우드 컴퓨팅 개요

• 클라우드 컴퓨팅의 정의
  • 인터넷을 통해 IT 리소스(컴퓨팅 파워, 스토리지, 데이터베이스 등)를 온디맨드(On-Demand)로 제공하고 사용한 만큼 종량제(Pay-as-you-go) 요금으로 지불하는 모델
• 세부 핵심 개념 (시험 빈출 포인트)
  • 온디맨드 (On-Demand)
    • 필요한 만큼 즉시 리소스를 사용하고, 불필요해지면 즉시 삭제하여 요금 청구를 중단할 수 있는 유연함
  • 인터넷을 통한 원격 액세스
    • 인터넷 연결과 웹 브라우저만 있으면 전 세계 어디서든 AWS 계정에 로그인하여 물리적 접촉 없이 인프라를 프로비저닝하고 관리할 수 있음
  • 종량제 요금 (Pay-as-you-go)
    • 약정 계약이나 복잡한 승인 절차 없이 사용하지 않는 인프라는 프로비저닝을 해제하여 비용 낭비를 방지
• 인프라 관리 부담 해소
  • 과거
    • 자체 데이터 센터(온프레미스)를 구축하여 하드웨어 구매, 전원, 냉각, 물리 보안 등을 직접 관리해야 했음
  • AWS 도입 후
    • 사용자는 물리적 인프라를 관리할 필요가 없어짐. 이로 인해 반복적이고 리소스 소모적인 인프라 유지 관리 태스크에서 벗어나 팀이 비즈니스 혁신과 가치 창출에만 집중할 수 있음
• 클라우드 배포 모델 (Cloud Deployment Models)
  • 클라우드 기반 배포 (Cloud-Based Deployment / Public Cloud)
    • 정의
      • 모든 애플리케이션 리소스를 클라우드(예: AWS)에 구축하거나 기존 시스템을 클라우드로 마이그레이션하여 운영하는 모델
    • 특징
      • 리소스가 클라우드 서비스 제공업체의 데이터 센터에 존재하므로, 물리적 인프라 및 가상화 제어에 대한 관리 부담이 전혀 없음. 온디맨드 스케일링과 유연한 비용 구조의 이점을 극대화할 수 있음
  • 온프레미스 배포 (On-Premises Deployment / Private Cloud)
    • 정의
      • 자체 데이터 센터 내부에서 가상화 및 자원 관리 도구(Hypervisor 등)를 활용하여 사설 인프라를 운영하는 모델
    • 특징
      • 하드웨어와 가상화 인프라를 자사가 완전히 소유하고 직접 통제하므로 규정 준수나 보안 통제력은 높지만, 시스템 구축 및 유지 보수에 필요한 모든 기술/자본 비용을 직접 부담해야 함. 탄력성과 유연한 확장은 제한적임
  • 하이브리드 배포 (Hybrid Deployment)
    • 정의
      • 클라우드 기반 리소스와 기존 온프레미스 레거시 시스템을 네트워크(VPN, Direct Connect 등)로 결합하여 상호작용하도록 하는 모델
    • 특징
      • 두 배포 방식의 이점을 결합. 예컨대 규정 준수와 데이터 보안이 중요한 레거시 데이터베이스는 온프레미스에 유지하고, 트래픽 유동성이 심한 프런트엔드 애플리케이션은 퍼블릭 클라우드에 배포하여 리소스를 유연하게 연동함

2. aws 클라우드의 이점

• 고정 비용을 가변 비용으로 대체 (Trade upfront expense for variable expense)
  • 정의
    • 전통적인 온프레미스는 서버, 공간, 유지 관리 등 대규모 선행 투자(고정 비용)가 필요하며 자원 사용률과 관계없이 비용이 나감
  • 특징
    • AWS는 대대적인 투자 없이 소규모로 시작할 수 있고, 매달 실제 사용한 만큼만 지불(가변 비용)하여 유연하게 예산을 절감함
• 거대한 규모의 경제로 이익 달성 (Benefit from massive economies of scale)
  • 정의
    • AWS가 전 세계 수백만 고객의 자원을 위해 대량의 하드웨어를 대규모로 구매하므로 단가가 낮아짐
  • 특징
    • 하드웨어 단가 절감 효과는 고객에게 더 저렴한 가격(종량제 요금 절감)의 혜택으로 직접 환원됨
• 용량 추정 불필요 (Stop guessing capacity)
  • 정의
    • 온프레미스는 향후 예상치를 예측하여 과도한 용량의 하드웨어를 선구매(낭비 우려)하거나, 과소 예측 시 서버 부족으로 서비스 장애 및 고객 이탈을 겪음
  • 특징
    • AWS는 예측이 필요 없으며, 필요할 때 즉시 리소스를 프로비저닝하고 스케일링 메커니즘을 사용해 몇 분 만에 자원을 늘리거나 줄일 수 있음
• 속도 및 민첩성 향상 (Increase speed and agility)
  • 정의
    • 테스트 환경을 즉각 가동하여 새로운 혁신을 위한 실험을 수행할 수 있음
  • 특징
    • 시도가 실패하면 해당 자원을 즉시 삭제하고 비용 발생을 멈출 수 있어, 인프라 획득 시간을 획기적으로 단축하고 개발 생산성을 높임
• 데이터 센터 운영 및 유지 관리 비용 투자 불필요 (Stop spending money running and maintaining data centers)
  • 정의
    • 데이터 센터의 서버 랙 장착, 전원 공급, 냉각 유지 등 물리적인 하드웨어 유지 보수는 모두 AWS가 전담함
  • 특징
    • 기업은 비즈니스 가치와 직접적인 관련이 없는 기계적이고 물리적인 데이터 센터 관리에 시간과 인력을 허비하지 않고 자사 비즈니스에만 집중 가능
• 몇 분 만에 전 세계에 배포 (Go global in minutes)
  • 정의
    • 해외 진출 시 현지 데이터 센터를 구축할 필요 없이, 전 세계의 AWS 리전에 즉시 애플리케이션을 배포 가능
  • 특징
    • 수개월~수년이 걸리던 전 세계 서비스 확장을 단 몇 분 만에 낮은 대기 시간(Latency)으로 실현함

3. aws 글로벌 인프라 소개

• 고가용성 및 내결함성의 정의
  • 고가용성 (High Availability)
    • 정의
      • 가동 중지 시간을 최소화하면서 시스템 및 애플리케이션에 계속 액세스할 수 있도록 보장하는 설계 방식
    • 특징
      • 단일 구성 요소의 실패(장애) 시 다른 구성 요소가 자동으로 그 역할을 대신하여 서비스를 유지함
  • 내결함성 (Fault Tolerance)
    • 정의
      • 시스템의 일부 구성 요소가 여러 개 실패하더라도 데이터 손실이나 서비스 중단 없이 완전히 정상 작동할 수 있도록 아키텍처에 복원력을 구축하는 수준
    • 특징
      • 단일 실패 지점(SPOF)을 제거하기 위해 이중화(Redundancy)를 극대화하는 방식
• AWS 글로벌 인프라 구성 요소
  • 리전 (Regions)
    • 정의
      • 전 세계 여러 지리적 영역에 독립적으로 분산되어 있는 물리적인 인프라 위치 그룹
    • 특징
      • 전 세계 고객과 가깝게 배치하여 네트워크 대기 시간(Latency)을 낮춤
      • 기업은 극단적인 재난 대처를 위해 여러 리전에 인프라를 분산하여 다른 리전으로 장애 조치(Failover)를 수행할 수 있음
  • 가용 영역 (Availability Zones - AZ)
    • 정의
      • 하나의 AWS 리전 내에서 지리적으로 분리되고 격리된 데이터 센터의 클러스터(위치 그룹)
    • 특징
      • 각 리전은 가동 중지 대비 및 고가용성(이중화)을 위해 최소 3개 이상의 AZ를 포함함
      • 한 AZ의 자연재해나 정전이 다른 AZ에 영향을 주지 않도록 충분한 물리적 거리를 두고 설계됨
  • 데이터 센터 (Data Centers)
    • 정의
      • 서버와 네트워크 하드웨어가 설치된 개별적인 물리 건물
    • 특징
      • 각 가용 영역(AZ)은 하나 이상의 독립된 데이터 센터로 구성됨
      • 각 데이터 센터는 중복된 전력(발전기 등), 냉각 시설, 그리고 물리 및 네트워크 연결망을 보유함

4. aws 공동 책임 모델

• 모델의 기본 개념
  • 정의
    • AWS와 고객이 클라우드 환경의 보안을 보장하기 위해 각자의 역할을 분담하는 책임 모델
  • 대전제
    • AWS의 책임
      • 클라우드 자체의 보안 (Security OF the Cloud)
    • 고객의 책임
      • 클라우드 내부의 보안 (Security IN the Cloud)
• AWS의 책임 영역 (Security OF the Cloud)
  • 물리적 인프라 계층
    • 정의
      • 실제 하드웨어 서버, 데이터 센터 건물, 물리적 진입 보안 조치 및 하드웨어 액세스 제어
  • 글로벌 인프라 및 네트워크 계층
    • 정의
      • 전 세계 리전, 가용 영역, 엣지 로케이션에 구축된 네트워크 장비 및 케이블링 제어
  • 가상화 하이퍼바이저 계층
    • 정의
      • 물리적 서버 위에 격리된 가상 환경을 생성하여 각 고객의 워크로드를 안전하게 분리하는 소프트웨어 계층
• 고객의 책임 영역 (Security IN the Cloud)
  • 게스트 운영 체제 (OS)
    • 정의
      • 인스턴스에 탑재되는 운영 체제에 대한 관리 및 암호화 키 소유권
    • 특징
      • AWS는 고객 OS에 진입할 수 있는 백도어나 키가 없으므로, OS의 보안 패치 적용 및 취약점 조치 책임은 100% 고객에게 있음
  • 애플리케이션 및 플랫폼 보안
    • 정의
      • 고객이 직접 탑재하여 실행하는 웹 앱, 비즈니스 로직, 타사 소프트웨어 보안
  • 데이터 관리 및 접근 제어
    • 정의
      • 저장되는 데이터(소비자 정보, 금융/의료 데이터 등)의 외부 공개 범위 제어와 권한 설정
    • 특징
      • 데이터 암호화 설정 및 해독 키(KMS) 관리, IAM을 통한 계정 액세스 권한 제어는 전적으로 고객의 몫임

실제 환경에서의 클라우드

1. 클라우드 개념을 실제 사용 사례에 적용

• 글로벌 인프라 활용 (예: 글로벌 전자 상거래 회사)
  • 지연 시간 (Latency) 최적화
    • 특징
      • 인프라와 사용자의 물리적 거리가 멀어질수록 지연 시간이 길어짐
      • 아일랜드(eu-west-1) 또는 싱가포르(ap-southeast-1) 등 고객의 주요 기반에 가장 가까운 리전을 선택해 배포하여 성능을 극대화함
  • 초기 투자 배제 및 스타트업 경쟁력 확보
    • 특징
      • 대규모 사전 투자금 없이 즉시 글로벌 급 인프라를 확장하여, 소규모 기업이나 스타트업도 대기업과 대등하게 글로벌 비즈니스를 수행할 수 있음
  • 고가용성 및 복원력 설계
    • 특징
      • 최소 2개 이상의 가용 영역(AZ)에 완전히 동일한 환경을 배포함
      • 한 AZ에 장애가 나도 즉시 다른 AZ로 장애 조치(Failover)를 수행하여 중단 없는 서비스를 유지함
• 공동 책임 모델 활용
  • 보안 및 규정 준수 집중화
    • 특징
      • 기업은 물리 데이터 센터의 자물쇠 관리나 하드웨어 폐기 등 클라우드 자체의 보안을 직접 결정할 필요가 없음
      • 대신 결제 시스템의 신용카드 데이터 보안, 고객 접근 권한 제어 등 비즈니스에 직접적으로 중요한 고차원적인 보안(클라우드 내부의 보안)에 인력을 집중할 수 있음

• 하나의 Git 저장소 안에 다른 Git 저장소를 하위 디렉토리로 포함시켜 관리하는 기능임
• 메인 프로젝트에서 공통 라이브러리나 외부 모듈을 독립적으로 관리하고 싶을 때 사용함

왜 쓰는가?

• 공통 코드 관리: 여러 프로젝트에서 똑같이 사용하는 모듈이 있을 때, 매번 복사해서 붙여넣는 대신 서브모듈로 등록해서 코드 중복을 피할 수 있음
• 독립적인 버전 관리: 서브모듈은 특정 커밋 해시를 가리킴. 서브모듈 원격 저장소에 새로운 커밋이 올라가도 메인 프로젝트가 자동으로 영향을 받지 않음. 원하는 시점에 직접 업데이트를 결정할 수 있어 안전함
• 권한 분리: 메인 프로젝트 개발자와 서브모듈 개발자의 접근 권한을 다르게 설정할 수 있음

핵심 명령어 정리

1. 서브모듈 추가하기

git submodule add <서브모듈_저장소_URL> <로컬_디렉토리_경로>

• 명령어를 실행하면 메인 저장소 루트에 .gitmodules 파일이 생성됨
• 해당 파일에 서브모듈의 경로와 URL 정보가 기록되며, 메인 프로젝트는 서브모듈의 특정 커밋 해시를 가리키게 됨

2. 서브모듈이 포함된 프로젝트 클론하기

• 단순히 git clone <메인_저장소_URL>만 하면 서브모듈 디렉토리는 빈 폴더로만 나타남
• 서브모듈의 실제 소스코드까지 정상적으로 가져오려면 아래 두 가지 방법 중 하나를 선택해야 함

방법 A: 클론할 때 한 번에 가져오기

git clone --recursive <메인_저장소_URL>

방법 B: 이미 메인 프로젝트를 클론한 상태에서 가져오기

git submodule init
git submodule update
# 또는 한 줄로 해결
git submodule update --init --recursive

3. 서브모듈 업데이트하기

• 서브모듈 원격 저장소의 최신 커밋을 가져와서 업데이트하고 싶을 때 사용함

  git submodule update --remote

4. 서브모듈 변경사항 저장하고 푸시하기

• 서브모듈 디렉토리 내부에서 코드를 직접 수정한 경우의 프로세스임

1. 서브모듈 디렉토리로 이동하여 변경사항을 커밋하고 서브모듈 원격 저장소에 푸시함
2. 메인 프로젝트 디렉토리로 돌아와서 서브모듈의 변경된 커밋 해시 상태를 확인하고 메인 프로젝트 저장소에도 커밋 및 푸시를 진행함

• 메인 저장소에만 푸시하고 서브모듈 푸시를 깜빡하면 다른 팀원들이 코드를 당겨올 때 에러가 발생하므로 주의해야 함

주의할 점과 단점

• 커밋 해시 기반 관리: 메인 프로젝트는 서브모듈 내부 파일의 세부 변경 사항을 직접 관리하지 않고 특정 '커밋 해시'만 기록함. 이 구조를 이해하지 못하면 협업할 때 꼬이기 쉬움
• 싱크 맞추기 귀찮음: 팀원이 서브모듈 업데이트를 푸시한 경우, 다른 팀원들은 단순히 git pull만 해서는 안 되고 git submodule update를 추가로 실행해 주어야 함. 주기적으로 명령어를 쳐야 해서 번거로움
• 히스토리 추적의 한계: 메인 프로젝트 커밋 로그만 봐서는 서브모듈 내부에서 정확히 어떤 코드가 어떻게 바뀌었는지 파악하기 어려움

한 줄 요약

• 여러 프로젝트에서 공통으로 쓰는 핵심 모듈을 분리해서 깔끔하게 관리하고 싶다면 귀찮음을 감수하고 도입할 가치가 충분함. 단, 협업 시 팀원들과 서브모듈 동기화 규칙을 확실히 정해두어야 삽질을 막을 수 있음

개발자의 역할이 바뀌고 있다고 생각함.

지금까지 개발자는 이슈를 읽고, 분석하고, 구현하고, 검증하는 전 과정을 직접 담당했음. dev-nobiya는 이슈 확인부터 구현, 검증까지 Claude AI가 처리하고, 개발자는 최종 검토만 함.

이제 개발자는 짜는 사람이 아니라 보는 사람임.

dev-nobiya가 뭔데

이슈 트래커에 구현 명세를 작성하고 dev-nobiya run만 실행하면, 브랜치 생성부터 구현, 코드 리뷰, push, 이슈 상태 업데이트까지 자동으로 처리됨.

npm install -g dev-nobiya@beta
cd your-project
dev-nobiya setup   # 이슈 트래커 연동 (대화형)
dev-nobiya run     # 실행

Linear, GitHub Issues, Jira 세 가지를 지원하고, 현재 npm에 베타 버전으로 배포되어 있음.

파이프라인이 어떻게 돌아가냐

이슈 등록 (Todo 상태)
    ↓
브랜치 자동 생성 + 이슈 → In Progress
    ↓
플래닝: Claude가 work-plan.md 작성 → 검증 → 재플래닝  (최대 3회)
    ↓
구현: 태스크 순서대로 구현 → 자기검증 → 재구현  (최대 3회)
    ↓
코드 리뷰: 전체 diff 검토 → PASS/WARN/FAIL → 보완 후 재리뷰  (최대 5회)
    ↓
브랜치 push + 이슈 → Done + 알림 발송

모든 단계에 사이클 상한선이 있어서 AI가 루프에 갇히는 일이 설계상 발생하지 않음.

설계 포인트: 플래너와 검증자를 분리함

플래닝을 작성하는 Claude 세션과 그 플랜을 검증하는 Claude 세션이 분리되어 있음. 같은 세션이 스스로 검증하면 자기 결과물에 관대해지기 때문에, 독립된 세션이 "이 플랜이 요구사항을 제대로 반영했나"를 다시 확인함.

실제로 어떻게 쓰이냐

예를 들어 운영자가 Jira에 이런 이슈를 올렸다고 하면:

"메인 페이지 상단에 있는 dev-nobiya 로고 글자가 좀 작아 보입니다. 조금 더 크게 키워주시면 좋겠습니다."

개발자는 이걸 보고 구현 명세로 변환해서 별도 이슈를 등록함:

views/index.ejs에서 네비게이션 상단의 dev-nobiya 로고 텍스트 폰트 크기를 현재보다 10px 증가시킴. 완료 조건: 로고 텍스트가 기존보다 10px 크게 표시됨, 다른 레이아웃에 영향 없음.

이 상태에서 dev-nobiya run을 실행하면:

1. 이슈 ID 기반으로 브랜치가 자동 생성됨
2. Claude가 이슈를 읽고 work-plan.md를 작성함
3. views/index.ejs의 로고 클래스를 수정함
4. 코드 리뷰 세션이 diff를 검토하고 PASS 판정을 내림
5. 브랜치가 원격으로 push되고 이슈 상태가 Done으로 바뀜

코드는 한 줄도 직접 건드리지 않았음.

파이프라인 외에 붙어있는 것들

멀티 이슈트래커 Linear, GitHub Issues, Jira를 모두 지원함. 어느 트래커를 쓰든 dev-nobiya run 명령어 하나로 동작함.

한국어 / 영어 dev-nobiya setup 실행 시 언어를 선택할 수 있음.

실시간 알림 (Discord / Slack) 단순히 "완료됐습니다" 수준이 아님. 어떻게 구현했는지, 리뷰에서 어떤 문제가 발견됐는지, 왜 PASS 또는 FAIL 판정이 났는지까지 구체적인 내용이 메시지로 옴. 터미널을 켜놓고 기다릴 필요 없이 알림만 보고 AI가 지금 어디서 무엇을 하는지 파악할 수 있음.

만들면서 배운 것

Claude Code를 API가 아닌 CLI로 쓴 이유

처음에는 Anthropic API를 직접 호출하는 방식을 고려했음. 그런데 API는 파일 읽기/쓰기, 터미널 실행, 코드베이스 탐색 같은 도구 호출을 직접 구현해야 함. Claude Code CLI는 그 도구들이 이미 내장되어 있고, claude --print 옵션으로 비대화형 실행이 가능함. 별도 API 키 없이 Claude Code 구독만으로 동작하는 것도 장점임.

세션 분리가 품질을 높임

하나의 긴 세션이 전부 처리하는 것보다, 역할을 명확히 나눈 짧은 세션 여러 개가 더 나은 결과를 냄. 플래너, 검증자, 구현자, 리뷰어가 각자 독립된 컨텍스트에서 판단하게 하면 이전 단계의 편향이나 실수를 다음 단계가 잡아낼 수 있음.

루프에는 반드시 상한이 필요함

AI 세션을 루프로 돌릴 때 탈출 조건만 있으면 이론적으로 무한 루프에 빠질 수 있음. 플래닝 3회, 구현 3회, 리뷰 5회로 사이클 상한을 박아두고, 상한에 도달하면 현재 상태를 기준으로 무조건 다음 단계로 넘기는 구조가 필요함.

마치며

현재 로컬 환경 전용 베타 버전임. 별도 서버나 인프라는 필요 없음.

앞으로 추가하고 싶은 것들이 있음. 원격 실행, 웹 대시보드, 더 많은 이슈트래커 지원 등. 그런데 지금 당장 가장 필요한 건 실제로 써본 사람들의 피드백임.

써보고 불편한 점, 안 되는 케이스, 궁금한 점 GitHub Issues에 남겨주면 반영하겠음.

GitHub: https://github.com/csw9261/dev-nobiya npm: npm install -g dev-nobiya@beta

npm에 배포하기 전에 package.json을 제대로 채워야 함. 빠뜨리면 npm 페이지가 허전하거나 검색에 안 잡힘.

{
  "name": "패키지명",
  "version": "0.1.0-beta.1",
  "description": "패키지 설명 (영어 권장)",
  "license": "MIT",
  "author": "깃헙유저명",
  "homepage": "https://github.com/유저명/레포명",
  "repository": {
    "type": "git",
    "url": "https://github.com/유저명/레포명.git"
  },
  "bugs": {
    "url": "https://github.com/유저명/레포명/issues"
  },
  "keywords": ["키워드1", "키워드2"],
  "files": ["dist/", "prompts/"],
  "bin": {
    "명령어명": "./dist/index.js"
  }
}

각 항목 설명:

• keywords — npm 검색 노출에 직결됨. 핵심 키워드 10개 이내로
• files — npm에 올라갈 파일/디렉토리만 명시. src/, node_modules/ 등은 제외
• bin — CLI 툴이라면 필수. 명령어명으로 터미널에서 실행 가능해짐

2. 버전 관리 (semver)

npm은 major.minor.patch 형식의 semver를 따름.

베타 배포 시엔 프리릴리즈 태그를 붙임:

0.1.0-beta.1
0.1.0-beta.2

3. prepublishOnly 스크립트 추가

TypeScript 프로젝트라면 publish 전에 빌드가 자동으로 돌도록 설정해두는 게 좋음. 빌드 까먹고 올리는 실수 방지.

"scripts": {
  "build": "tsc",
  "prepublishOnly": "npm run build"
}

4. .gitignore vs npm 배포 파일

.gitignore와 npm에 올라가는 파일은 별개임.

• GitHub에 올라가는 것 → git이 추적하는 파일 전체
• npm에 올라가는 것 → package.json의 files 필드에 명시한 것만

즉 src/를 GitHub에 공개하면서 npm엔 dist/만 올리는 구조가 가능함.

배포 전 확인:

npm pack --dry-run  # 실제로 올라갈 파일 목록 미리 확인

5. npm 계정 및 2FA 설정

npm login  # 로그인
npm whoami  # 로그인 상태 확인

2FA가 활성화된 계정이라면 publish 시 인증이 필요함. npmjs.com에서 Granular Access Token을 발급받아 사용하면 편함:

1. npmjs.com → 프로필 → Access Tokens
2. Generate New Token → Granular Access Token
3. bypass two-factor authentication 체크
4. 토큰 복사

publish 시 토큰 사용:

npm publish --tag beta --//registry.npmjs.org/:_authToken=<토큰>

6. 베타 배포

--tag beta를 붙이면 @beta 없이는 설치가 안 됨. 일반 사용자가 실수로 불안정한 버전을 설치하는 걸 방지.

npm publish --tag beta

설치:

npm install -g 패키지명@beta   # beta 태그
npm install -g 패키지명        # stable (태그 없음)

7. 패치 배포 (업데이트)

코드 수정 후 배포할 때는 버전을 올리고 다시 publish:

# package.json version 수정 후
npm publish --tag beta

같은 버전으로 재배포는 불가. 반드시 버전을 올려야 함.

8. 배포 취소

• 72시간 이내 → npm unpublish 패키지명@버전 으로 완전 삭제 가능
• 72시간 이후 → 삭제 불가, deprecated 처리만 가능

npm deprecate 패키지명@버전 "This version is no longer maintained."

마치며

처음엔 복잡해 보이지만 한 번 해보면 별거 없음. 핵심은:

1. package.json 꼼꼼히 채우기
2. files 필드로 올라갈 파일 제어하기
3. 베타는 --tag beta로 안전하게 배포

1. 결론부터 — 거의 같은 도구임

두 환경은 같은 Claude Code 엔진을 공유함. 버전만 약간 다를 수 있음(앱은 번들된 버전, 터미널은 별도 설치).

확인 방법:

# 터미널 버전
which claude
# /Users/choi/.local/bin/claude
claude --version
# 2.1.145 (Claude Code)

# 앱이 번들한 Claude Code
ls ~/Library/Application\ Support/Claude/claude-code/
# 2.1.142  ← 앱 안에 Claude Code가 통째로 들어 있음

즉 앱은 Claude Code를 내장해서 GUI로 감싸 보여줄 뿐이고, 본질은 같음.

2. 무엇이 같은가 — ~/.claude/ 디렉토리 공유

가장 중요한 부분. 두 환경 모두 ~/.claude/ 를 똑같이 읽고 씀. 한쪽에서 만든 설정이 다른 쪽에 그대로 적용됨.

~/.claude/
├── CLAUDE.md                ← 전역 규칙 (양쪽 동일하게 로드)
├── settings.json            ← 설정 (양쪽 공유)
├── projects/
│   └── -Users-choi-Developer-dev-nobiya/
│       └── memory/          ← 자동 메모리 (양쪽 공유)
├── plugins/                 ← 플러그인
└── sessions/                ← 터미널 세션

따라서 다음은 양쪽에서 동일하게 동작함:

• ~/.claude/CLAUDE.md (전역 규칙)
• 프로젝트 루트의 CLAUDE.md (프로젝트 규칙)
• 자동 메모리 (~/.claude/projects/{경로}/memory/)
• Skills, Hooks, MCP 서버 설정
• 권한 / 환경변수 / 슬래시 커맨드

즉 터미널에서 정한 규칙을 앱에서도 그대로 쓸 수 있고, 반대도 마찬가지임. 메모리도 한쪽에서 쌓이면 다른 쪽에서 자동으로 로드됨.

3. 무엇이 다른가

UI / 렌더링

세션 저장 위치

이건 분리되어 있음:

같은 작업을 양쪽에서 하면 세션 히스토리는 따로 쌓임. 다만 메모리·규칙은 공유되므로 컨텍스트 자체는 이어서 사용 가능.

환경적 제약

• 터미널 — shell 환경 그대로. tmux, ssh, 원격 서버 작업과 자연스럽게 결합됨. 백그라운드 프로세스 다루기 편함.
• 앱 — 로컬 GUI 환경. 그래픽 출력(이미지, 다이어그램)이 더 직관적. 원격 서버 작업은 불편함.

4. 실용 가이드

규칙은 한 번만 작성하면 됨

같은 ~/.claude/CLAUDE.md를 양쪽이 읽으므로 중복 작성 불필요함. 프로젝트 규칙도 마찬가지로 프로젝트 루트의 CLAUDE.md 하나면 됨.

메모리도 자동으로 공유됨

앱에서 작업하면서 쌓인 메모리가 터미널에도, 또 그 반대도 자동 반영. 사용자가 직접 옮길 필요 없음.

어떤 걸 언제 쓰는 게 좋은가

팀 공유 관점

CLAUDE.md를 프로젝트 루트에 두고 git으로 커밋해두면 팀원이 어느 환경에서 Claude Code를 쓰든 같은 규칙으로 동작함. 환경별로 따로 공유할 필요 없음.

5. 한 줄 요약

• 터미널 Claude Code와 앱 Claude Code 탭은 같은 엔진, UI만 다름
• ~/.claude/ 디렉토리를 공유하므로 CLAUDE.md·메모리·Skills 모두 자동으로 양쪽에 적용됨
• 다른 건 세션 저장 위치와 UI/환경적 제약뿐
• 그래서 규칙은 한 번만 작성하면 됨

처음에는 별개의 도구처럼 보이지만, 실제로는 하나의 Claude Code를 두 가지 방식으로 띄운 것에 가까움. 환경에 맞춰 골라 쓰되, 규칙·메모리 관리는 한 곳에서 하면 됨.

OpenTelemetry Collector 같은 대형 프로젝트를 분석할 때 한 세션에서 전부 처리하려고 하면 문제가 생긴다.

LLM은 컨텍스트 윈도우 안에서 처리하는 정보가 많아질수록 집중도가 떨어지고, 분석 퀄리티도 함께 낮아진다. 소스가 클수록 "전체를 다 보여주는" 방식은 오히려 역효과다.

[X] 한 세션에서 전부 처리
소스 전체 → [단일 에이전트] → 퀄리티 낮은 분석

[O] 멀티에이전트
소스 전체 → 파트 분할 → [스페셜리스트 A] → 검토/검증
                       → [스페셜리스트 B] → 검토/검증  → 최종 합성
                       → [스페셜리스트 C] → 검토/검증

핵심 원칙은 단순하다. 좁은 컨텍스트 = 깊은 분석

접근법: 오케스트레이터 + 스페셜리스트

구조

오케스트레이터 (메인 세션)
  ├── 전체 구조 파악 및 분석 단위 확정
  ├── 서브에이전트들에게 파트 위임
  ├── 결과 검토 및 cross-cutting 검증
  └── 최종 합성
       ↑
스페셜리스트 에이전트들 (병렬 실행)
  ├── Agent A: 핵심 인터페이스 담당
  ├── Agent B: 데이터 수집/전송 담당
  ├── Agent C: 데이터 처리/라우팅 담당
  ├── Agent D: 서비스/확장 담당
  └── Agent E: 설정/인프라 담당

역할 분리

오케스트레이터는 깊이 파지 않는다. 스페셜리스트가 가져온 결과를 검토하고 검증하고 보완 요청하는 게 주 역할이다.

OpenTelemetry Collector에 적용

프로젝트 구조

OpenTelemetry Collector는 멀티모듈 Go 프로젝트로, 컴포넌트 경계가 명확하게 디렉토리로 나뉘어 있어 에이전트 분할에 적합하다.

opentelemetry-collector/
├── component/      # 핵심 인터페이스
├── pdata/          # 텔레메트리 데이터 모델
├── pipeline/       # 파이프라인 시그널 타입
├── consumer/       # 컨슈머 인터페이스
├── receiver/       # 데이터 수집
├── exporter/       # 데이터 전송
├── processor/      # 데이터 처리
├── connector/      # 파이프라인 라우팅
├── extension/      # 확장 기능
├── service/        # 서비스 오케스트레이션
├── otelcol/        # 메인 바이너리
├── confmap/        # 설정 처리
├── featuregate/    # 피처 플래그
└── internal/       # 내부 유틸리티

에이전트 분할 (5개)

구현: Claude Code Agent 툴

Claude Code에서 이 패턴은 별도 인프라 없이 내장 Agent 툴만으로 구현된다.

병렬 실행

# 메인 세션에서 여러 서브에이전트를 한 번에 호출
Agent(subagent_type="Explore", prompt="Core 분석: component, pdata...")
Agent(subagent_type="Explore", prompt="Receiver/Exporter 분석: receiver, exporter...")
Agent(subagent_type="Explore", prompt="Processor/Connector 분석: processor, connector...")
# → 병렬로 실행, 결과가 메인 세션으로 반환

결과 흐름

스페셜리스트 결과 반환
    ↓
오케스트레이터가 검토
    ↓
cross-cutting concerns 교차 검증
    ↓
누락 부분 보완 요청 (필요시 추가 에이전트 실행)
    ↓
최종 합성

프롬프트 설계 원칙

각 스페셜리스트 프롬프트에 반드시 포함해야 할 것:

1. 담당 범위 명시 - 어떤 디렉토리/패키지만 볼 것인지
2. 분석 포인트 - 인터페이스, 의존성, 핵심 로직 중 무엇에 집중할지
3. 결과 형식 - 오케스트레이터가 검토하기 좋은 구조화된 포맷
4. 경계 명시 - 다른 에이전트 담당 영역은 깊이 들어가지 않도록

오케스트레이터 프롬프트에 반드시 포함해야 할 것:

1. cross-cutting 체크리스트 - 각 에이전트 결과 간 연결 포인트
2. 검증 기준 - 누락/모순 여부 판단 기준
3. 보완 요청 조건 - 어떤 경우에 추가 분석을 요청할지

마치며

이 접근법의 핵심은 컨텍스트 관리다. LLM에게 많은 정보를 한꺼번에 주는 것보다, 적절히 쪼개서 각자 깊이 파게 하고 메인이 검증하는 구조가 실제로 더 나은 결과를 만든다.

대형 오픈소스 프로젝트 분석뿐 아니라, 복잡한 버그 디버깅이나 아키텍처 리뷰에도 같은 패턴을 적용할 수 있다.