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

안녕하세요 에이블스쿨 9기 기자단입니다.
오늘은 10주차 후기에 대해 작성하려고 합니다.
10주차에 한 것들을 간단히 브리핑하자면 , 서버리스 내용의 5차 미니프로젝트를 진행하였고 , 
서비스 아키텍처에 대한 이론을 배웠습니다.
5차미프에 관한 내용은 9주차 블로그에 간단히 후기적어놓았습니다~
 
아래는 제가 서비스 아키텍처를 배우며 주요 용어들을 정리한 자료입니다.
참고해주세요!

서비스 아키텍처 핵심 용어 정리 가이드

본 가이드는 모니터링·관측성, 비용 최적화(FinOps), 아키텍처 스타일(모놀리식/MSA/서버리스), 컨테이너·쿠버네티스, 생성형 AI(Bedrock·RAG), 산업별 아키텍처·규제까지 서비스 아키텍처 전반의 핵심 개념과 작동 원리를 시험·면접에서 바로 설명할 수 있도록 정리한 학습용 가이드입니다.

1. 모니터링 & 관측성 (Monitoring & Observability)

CloudWatch를 중심으로 한 AWS 통합 모니터링과, 시스템 상태를 깊이 들여다보는 관측성(Observability) 개념을 정리합니다.

1-1. CloudWatch 핵심 기능

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
CloudWatch	AWS 리소스와 애플리케이션을 한곳에서 감시하는 통합 모니터링 서비스입니다.	• 4대 핵심 기능: Metrics(지표) + Logs(로그) + Alarms(알람) + Dashboards(대시보드)를 통합 제공합니다. • 역할: 시스템이 정상인지 감시하고, 이상이 생기면 알리고 자동 조치까지 연결하는 모니터링의 중심축입니다.
Metrics (메트릭)	시간에 따라 수집되는 숫자 데이터 포인트(CPU 사용률, 요청 수 등)입니다.	• 기본 제공: EC2의 CPU·네트워크 등은 5분 간격으로 무료 제공되며, 상세 모니터링(1분 간격)은 유료입니다. • 메모리 미제공 주의: EC2의 메모리·디스크 사용률은 기본 메트릭에 없어, CloudWatch Agent를 설치해야 수집됩니다. • 커스텀 메트릭: 직접 정의한 지표는 사용량 기반으로 과금됩니다.
Logs (로그)	애플리케이션·서비스가 남기는 텍스트 이벤트 기록입니다.	• 계층 구조: Log Group(서비스 단위) → Log Stream(인스턴스 단위) → Log Event(개별 기록) 순으로 쌓입니다. • 수집 방식: Lambda는 로그가 자동 전송되지만, EC2는 CloudWatch Agent를 설치해야 합니다. • 보존 기간 필수: 기본은 무기한 보관(비용 발생)이므로 보존 기간을 반드시 설정해야 합니다. • Logs Insights: 쌓인 로그를 쿼리 문법으로 검색·분석할 수 있습니다.
Alarms (알람)	메트릭이 설정한 임계값을 벗어나면 경보를 발생시키는 기능입니다.	• 3가지 상태: OK(정상) / ALARM(임계값 위반) / INSUFFICIENT_DATA(데이터 부족)로 나뉩니다. • 액션 연결: 알람 발생 시 SNS(알림 발송), Auto Scaling(서버 증감), EC2 액션(재부팅 등)을 자동 실행합니다. • 복합 알람: 여러 알람을 조합해 오탐(false alarm)을 줄이고 진짜 장애만 잡아낼 수 있습니다.
Dashboard (대시보드)	여러 지표를 한 화면에 모아 시스템 상태를 시각화하는 도구입니다.	• RED 메트릭 중심: Rate(요청량) / Errors(오류) / Duration(지연)을 핵심으로 구성합니다. • 3계층 드릴다운: 전체(시스템) → 서비스 → 인스턴스 순으로 점점 좁혀 가며 원인을 추적하도록 설계합니다.
자동 복구 (Auto Recovery)	장애를 사람이 개입하지 않고 자동으로 복구하도록 알람과 액션을 연동하는 구조입니다.	• 인스턴스 복구: StatusCheckFailed 알람 → EC2 Recover 액션으로 손상된 인스턴스를 자동 복구합니다. • 자동 확장 연동: CloudWatch 알람 → Auto Scaling의 Scale Out(증설)/Scale In(축소)을 자동 트리거합니다.

1-2. 관측성(Observability) 개념

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
관측성 3기둥 (3 Pillars)	시스템 내부 상태를 외부 출력만으로 파악하는 능력으로, 세 가지 데이터로 완성됩니다.	• 3기둥: Metrics(무엇이 얼마나) + Logs(무슨 일이) + Traces(요청이 어디를 거쳤나) = 완전한 시스템 가시성. • 모니터링과의 차이: 모니터링이 ‘알려진 문제’를 감시한다면, 관측성은 ‘예상 못 한 미지의 문제’의 원인까지 파고듭니다.
SLI / SLO / SLA	서비스 품질을 측정·목표·약속의 3단계로 관리하는 지표 체계입니다.	• SLI(Indicator): 실제 측정값(예: 가용성 99.95%) — ‘측정’. • SLO(Objective): 내부적으로 정한 목표치(예: 99.9% 이상) — ‘목표’. • SLA(Agreement): 고객과 맺는 계약으로 위반 시 보상이 따름 — ‘약속’. • 관계: SLI(측정) → SLO(목표) → SLA(약속) 순으로 점점 구속력이 강해집니다.
에러 버짓 (Error Budget)	SLO가 허용하는 실패의 여유분으로, 100% − SLO로 계산합니다.	• 계산: SLO가 99.9%면 0.1%만큼 실패가 허용되며, 이 여유분이 에러 버짓입니다. • 용도: 버짓이 남으면 새 기능을 공격적으로 배포(속도), 다 쓰면 안정화에 집중(안정성)하여 속도와 안정성의 균형을 잡습니다.
Golden Signals (골든 시그널)	구글 SRE가 제시한, Metrics에서 가장 먼저 확인해야 할 4대 핵심 지표입니다.	• 4개 지표: Latency(지연 시간) / Traffic(처리량) / Errors(오류율) / Saturation(자원 포화도). • 활용: 이 4가지만 잘 봐도 서비스 건강 상태의 대부분을 빠르게 진단할 수 있습니다.

[비교 표] 모니터링 vs 관측성

비교 항목	모니터링 (Monitoring)	관측성 (Observability)
목적	미리 정해 둔 ‘알려진 문제’를 감시	예상 못 한 ‘미지의 문제’의 원인 탐색
접근 방식	임계값·대시보드 기반 사후 알림	Metrics·Logs·Traces로 깊이 파고드는 분석
대표 질문	“시스템이 정상인가?”	“왜 이런 현상이 일어났는가?”

2. 비용 최적화 (FinOps)

클라우드 비용 구조를 이해하고, 분석·태깅·최적화를 통해 비용을 통제하는 FinOps 개념을 정리합니다.

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
비용 3대 요소	클라우드 비용을 구성하는 세 가지 큰 항목입니다.	• 구성 비율(개략): 컴퓨팅 약 60% + 스토리지 약 25% + 데이터 전송 약 15%. • 시사점: 컴퓨팅이 가장 큰 비중이므로 인스턴스 최적화가 비용 절감의 1순위입니다.
CAPEX vs OPEX	비용을 자본적 지출과 운영 지출로 구분하는 회계 관점입니다.	• CAPEX(자본 지출): 서버를 미리 사두는 대규모 선투자 방식(전통 IT). • OPEX(운영 지출): 쓴 만큼만 매달 내는 사용량 기반 방식(클라우드). • 클라우드의 본질: 초기 투자 없이 OPEX로 전환해 유연성과 비용 효율을 얻습니다.
비용 분석 도구	AWS가 제공하는 비용 가시화·최적화 도구 모음입니다.	• Cost Explorer: 비용을 기간·서비스·태그별로 시각화·분석합니다. • Budgets: 예산을 정하고 초과 예상 시 알람을 보냅니다. • Compute Optimizer: 사용 패턴을 분석해 적정 인스턴스 사양을 추천합니다. • Trusted Advisor: 비용·보안·성능 모범사례를 자동 점검해 줍니다.
데이터 전송 비용	네트워크 구간별로 달라지는, 놓치기 쉬운 숨은 비용입니다.	• 규칙: 인바운드(들어오는)는 대체로 무료, 아웃바운드(인터넷으로 나가는)와 AZ·리전 간 전송은 유료입니다. • NAT Gateway 비용 폭탄: 시간당 요금 + 데이터 처리량당 요금이 함께 붙어 트래픽이 많으면 비용이 급증합니다. • 절감 팁: S3·DynamoDB는 VPC 엔드포인트로 우회해 NAT 비용을 줄일 수 있습니다.
비용 태깅 (Cost Tagging)	리소스에 꼬리표(태그)를 붙여 비용을 분류·추적하는 기법입니다.	• 4대 필수 태그: Team(팀) / Project(프로젝트) / Env(환경: dev/prod) / Owner(담당자). • 자동 태깅·강제: 자동 태깅 규칙과 SCP(서비스 제어 정책)로 태그 누락을 강제로 막습니다. • 효과: 어느 팀·프로젝트가 얼마를 쓰는지 정확히 배분(쇼백/차지백)할 수 있습니다.

2-1. FinOps 3단계 & 최적화 기법

FinOps 3단계 사이클: Inform(비용 가시화) → Optimize(최적화) → Operate(운영·문화 정착) 를 반복합니다.

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
Inform (가시화)	비용을 보이게 만들어 어디에 얼마가 쓰이는지 파악하는 1단계입니다.	• 핵심 활동: Budgets 알람 + Cost Explorer 분석 + 100% 태깅으로 비용을 투명하게 만듭니다.
Optimize (최적화)	파악된 비용을 실제로 줄이는 2단계입니다.	• 핵심 기법: Right Sizing(적정 사양 조정) + RI/Savings Plans(약정 할인) + Spot(유휴 자원) + S3 Lifecycle(저장소 등급 자동 이전).
Right Sizing	실제 사용률에 맞춰 인스턴스 크기를 적정하게 조정하는 활동입니다.	• 핵심 지표: CPU·메모리 사용률을 보고 과하게 큰(저활용) 인스턴스를 작게 낮춥니다. • 효과: 성능 손실 없이 가장 손쉽게 컴퓨팅 비용을 줄이는 방법입니다.
RI vs Savings Plans	장기 약정으로 할인받는 두 가지 방식입니다.	• 예약 인스턴스(RI): 특정 인스턴스 타입·리전을 1·3년 약정 → 할인폭은 크지만 유연성이 낮습니다. • Savings Plans: ‘시간당 사용 금액($/h)’을 약정 → 인스턴스 타입을 바꿔도 할인이 적용돼 더 유연합니다.

[비교 표] EC2 4가지 요금 모델

요금 모델	특징	적합한 상황
On-Demand	약정 없이 쓴 만큼 정가 지불(가장 비쌈, 가장 유연)	단기 테스트, 예측 불가 트래픽
Reserved (RI)	1·3년 약정, 최대 70%+ 할인, 유연성 낮음	상시 가동 핵심 서버·DB
Savings Plans	시간당 사용 금액 약정, RI보다 유연	꾸준한 사용량 + 타입 변경 가능성
Spot	유휴 자원 경매, 최대 90% 할인, 강제 회수 위험	중단돼도 되는 배치·분석·CI

3. 아키텍처 스타일 & 전환 전략

애플리케이션을 어떻게 나누고 구성할지에 대한 대표 스타일과, 레거시를 점진적으로 전환하는 전략을 정리합니다.

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
모놀리식 (Monolithic)	모든 기능이 하나의 애플리케이션에 통합된 전통적 구조입니다.	• 장점: 구조가 단순하고 개발·배포가 쉬워 MVP나 소규모 서비스에 적합합니다. • 한계: 규모가 커지면 일부 수정에도 전체를 재배포해야 하고, 부분 확장이 어렵습니다.
MSA (Microservices)	기능을 독립된 작은 서비스 단위로 분리하는 구조입니다.	• 독립성: 팀별로 따로 개발·배포·확장할 수 있어 대규모 서비스에 유리합니다. • 트레이드오프: 서비스 간 통신·데이터 일관성·운영 복잡도가 올라갑니다.
서버리스 (Serverless)	인프라 관리 없이 함수 단위로 코드를 실행하는 구조입니다.	• 특징: 인프라 제로, 자동 확장, 사용량 과금으로 이벤트 기반 처리에 최적입니다. • 주의: Cold Start(첫 실행 지연) 이슈가 있어 지연에 민감한 작업은 보완이 필요합니다.
SOA	Service Oriented Architecture. MSA의 전신이 되는 서비스 지향 구조입니다.	• 특징: ESB(Enterprise Service Bus)라는 중앙 통신 버스를 통해 서비스를 통합합니다. • MSA와의 차이: SOA는 중앙 집중형 통합, MSA는 더 가볍고 분산된 통신을 지향합니다.
하이브리드 (Hybrid)	여러 아키텍처 스타일을 워크로드 특성에 맞게 조합하는 현실적 선택입니다.	• 조합 예시: API는 MSA, 배치 작업은 서버리스, 관리자 페이지는 모놀리식으로 구성. • 의의: 한 가지 정답을 강요하지 않고 각 워크로드에 최적인 방식을 섞어 씁니다.
Conway’s Law (콘웨이의 법칙)	“조직 구조가 시스템 구조를 결정한다”는 경험 법칙입니다.	• 의미: 소통 구조가 곧 소프트웨어 구조로 드러난다는 뜻입니다. • 시사점: MSA로 가려면 시스템뿐 아니라 조직(팀 분리)의 변화도 함께 이뤄져야 성공합니다.
교살자 패턴 (Strangler Fig)	모놀리식을 한 번에 갈아엎지 않고 점진적으로 MSA로 전환하는 전략입니다.	• 방식: 기존 시스템을 그대로 둔 채 기능을 하나씩 새 서비스로 떼어내고, 옛 부분을 서서히 ‘교살(대체)’합니다. • 장점: 서비스 중단 없이 위험을 낮추며 안전하게 현대화할 수 있습니다.

[비교 표] 모놀리식 vs MSA vs 서버리스

비교 항목	모놀리식	MSA	서버리스
배포 단위	전체를 한 번에 배포	서비스별 독립 배포	함수 단위 배포
확장 방식	전체를 통째로 확장	필요한 서비스만 부분 확장	요청당 자동 확장
복잡도	낮음 (단순)	높음 (운영 부담)	중간 (Cold Start 등)
적합한 단계	MVP·소규모 팀	성장기·팀 10명 이상	이벤트 기반·간헐적 작업

4. 컨테이너 & 쿠버네티스 (Container & Kubernetes)

애플리케이션을 일관되게 실행하는 컨테이너 기술과, 이를 대규모로 운영하는 오케스트레이션·MSA 패턴을 정리합니다.

Docker 핵심 흐름: Dockerfile(설계도) → Image(불변 패키지) → Container(실행 인스턴스) → Registry(저장소).

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
Docker	애플리케이션과 실행 환경을 함께 패키징하는 대표 컨테이너 플랫폼입니다.	• 일관성: ‘내 PC에선 됐는데’를 없애 어디서든 동일하게 실행됩니다. • 경량성: 가상 머신(VM)과 달리 OS를 통째로 띄우지 않아 가볍고 빠르게 뜹니다.
Image Layer (이미지 레이어)	도커 이미지를 구성하는 불변(read-only) 레이어들의 스택입니다.	• 캐싱·공유: 변경되지 않은 레이어는 재사용·공유되어 빌드 속도와 저장 효율을 극대화합니다. • 불변성: 각 레이어는 한 번 만들어지면 바뀌지 않아 안정적입니다.
ECS	AWS 네이티브 컨테이너 오케스트레이션 서비스입니다.	• 장점: 쿠버네티스보다 학습 곡선이 낮고 AWS 서비스와 통합이 매끄럽습니다. • 용도: 쿠버네티스가 부담스러운 팀의 컨테이너 운영에 적합합니다.
EKS	AWS가 관리해 주는 Kubernetes(K8s) 서비스입니다.	• 표준 호환: 쿠버네티스 표준과 100% 호환되어 멀티 클라우드·이식성이 좋습니다. • 용도: 이미 K8s를 쓰거나 복잡한 오케스트레이션이 필요한 조직에 적합합니다.
Fargate	서버를 직접 관리하지 않는 서버리스 컨테이너 실행 엔진입니다.	• 서버 관리 0: EC2 노드를 신경 쓰지 않고 CPU·메모리만 선언하면 됩니다. • 연동: ECS·EKS의 실행 방식 중 하나로 선택할 수 있습니다.
Pod	쿠버네티스의 최소 배포·실행 단위입니다.	• 구성: 1개 이상의 컨테이너가 모인 묶음으로, 같은 네트워크·스토리지를 공유합니다. • 수명: Pod는 일시적(언제든 죽고 새로 뜸)이므로 직접 다루기보다 상위 리소스로 관리합니다.
Deployment	“Pod를 N개 유지하라”고 선언하는 상위 관리 리소스입니다.	• 자동 복구: Pod가 죽으면 자동으로 새 Pod를 띄워 원하는 개수를 유지합니다. • 롤링 업데이트: 무중단으로 점진적 버전 교체와 롤백을 지원합니다.
Service / Namespace	Pod에 고정 접근점을 주고(Service), 클러스터를 논리적으로 나누는(Namespace) 리소스입니다.	• Service: 수시로 바뀌는 Pod 앞에 고정 IP·이름을 두어 안정적으로 접근하게 합니다. • Namespace: 한 클러스터를 팀·환경별 구역으로 분리해 관리합니다.
Circuit Breaker (서킷 브레이커)	장애가 다른 서비스로 번지는 것을 막는 MSA 안정화 패턴입니다.	• 3상태: Closed(정상 통과) → Open(장애 감지, 차단) → Half-Open(일부 시도로 회복 확인). • 효과: 죽은 서비스를 계속 호출하다 전체가 무너지는 연쇄 장애를 예방합니다.
Saga	여러 서비스에 걸친 분산 트랜잭션을 관리하는 패턴입니다.	• 보상 트랜잭션: 중간에 실패하면 앞선 단계를 되돌리는 ‘취소 작업’을 연쇄적으로 실행합니다. • 이유: MSA에서는 DB가 분리돼 전통적 단일 트랜잭션이 불가능하기 때문입니다.

[비교 표] ECS vs EKS vs Fargate

비교 항목	ECS	EKS	Fargate
성격	AWS 네이티브 오케스트레이션	관리형 Kubernetes	서버리스 실행 방식
학습 곡선	낮음(간편)	높음(K8s 지식 필요)	낮음(인프라 관리 없음)
서버 관리	EC2 노드 관리 필요(또는 Fargate)	EC2 노드 관리 필요(또는 Fargate)	불필요 (CPU·메모리만 선언)
선택 기준	AWS만 쓰고 단순하게	K8s 표준·이식성 중요	노드 운영을 없애고 싶을 때

5. 생성형 AI 아키텍처 (Bedrock & RAG)

AWS에서 생성형 AI를 서비스에 적용하는 핵심 서비스와, 환각을 줄이는 RAG 구축 방법을 정리합니다.

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
Bedrock	서버 관리 없이 다양한 기반 모델(FM)을 API로 호출하는 완전관리형 생성형 AI 서비스입니다.	• 다양한 FM: Claude, Titan, Llama 등 여러 회사의 파운데이션 모델을 하나의 API로 골라 씁니다. • 서버리스: 모델 인프라를 직접 운영하지 않고 호출량만큼만 비용을 냅니다.
RAG (검색 증강 생성)	외부 문서를 검색해 그 내용을 근거로 답변을 생성하는 기법입니다.	• 환각(Hallucination) 감소: 모델이 지어내지 않고 실제 문서 근거로 답하게 만듭니다. • 작동: 질문과 관련된 문서를 벡터 검색으로 찾아 → 그 내용을 프롬프트에 넣어 → 모델이 답변합니다. • 자동화: Bedrock Knowledge Base로 검색·임베딩 과정을 관리형으로 자동화합니다.
Knowledge Base (지식 베이스)	RAG의 문서 저장·검색을 자동화해 주는 Bedrock의 관리형 기능입니다.	• 연결: S3에 올린 문서를 가져와 임베딩(벡터화)하고 벡터 DB에 저장·검색합니다. • 효과: 직접 벡터 파이프라인을 만들지 않아도 관리형 RAG를 빠르게 구축합니다.

[비교 표] AI Services vs Bedrock vs SageMaker

비교 항목	AI Services	Bedrock	SageMaker
추상화 수준	가장 높음(완성형 API)	중간(FM 호출·커스터마이징)	가장 낮음(직접 제어)
사용 방식	Rekognition·Translate 등 API 호출	기반 모델을 API로 호출·RAG·튜닝	모델을 직접 학습·배포·운영
적합한 사용자	ML 지식 없이 바로 쓰고 싶을 때	생성형 AI를 빠르게 앱에 붙일 때	맞춤 모델을 처음부터 만들 때

5-1. RAG 구축 3단계 (Knowledge Base)

전체 흐름: ① 데이터 준비 → ② Knowledge Base 구성 → ③ 테스트·비교 순으로 진행합니다.

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
Phase 1 데이터 준비	검색 대상이 될 문서를 S3에 올려 준비하는 단계입니다.	• 작업: 설비 점검 매뉴얼 등 문서를 S3 버킷에 업로드합니다. • 권장: 구조화된 마크다운(제목·목록 정리)으로 만들면 검색 정확도가 올라갑니다.
Phase 2 Knowledge Base	Bedrock에서 지식 베이스를 만들어 검색 인프라를 구성하는 단계입니다.	• 흐름: Bedrock KB 생성 → S3 연결 → Titan 임베딩 모델로 벡터화 → Amazon S3 Vectors에 저장. • 의미: 이 단계가 완료되면 질문을 벡터로 바꿔 유사 문서를 찾을 수 있습니다.
Phase 3 테스트	구축한 RAG가 잘 동작하는지 검증하는 단계입니다.	• 작업: Bedrock 콘솔에서 직접 질문을 던져 답변을 확인합니다. • 비교: RAG 적용 답변 vs 일반 LLM 답변의 정확도를 비교해 효과를 검증합니다.

6. 아키텍처 적용 패턴

앞의 서비스들을 실제로 조합해 만드는 대표 아키텍처 패턴입니다.

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
서버리스 REST API	API Gateway + Lambda + DynamoDB로 구성하는 완전 서버리스 API 패턴입니다.	• 구성: API GW(관문) + Lambda(로직) + DynamoDB(DDB, 데이터). • 장점: MVP에 최적이며, 요청이 없으면 유휴 비용이 $0입니다.
비용 최적화 스타트업	완전 서버리스로 풀스택을 구성해 비용을 최소화하는 패턴입니다.	• 특징: 서버 상주 비용 없이 저렴하게 풀스택 서비스를 운영합니다. • 적합: 초기 트래픽이 적고 예측이 어려운 스타트업 환경.
하이브리드 패턴	EC2 + Lambda + Fargate를 워크로드 특성에 맞게 조합하는 패턴입니다.	• 워크로드별 매칭: 상시 가동은 EC2, 이벤트성은 Lambda, 컨테이너 작업은 Fargate로 배치합니다. • 의의: 단일 기술 고집 없이 각 작업에 최적인 실행 환경을 매칭합니다.

7. 산업별 아키텍처 & 규제·보안

산업마다 다른 규제와 제약이 아키텍처를 결정합니다. 제조·금융·의료 도메인의 핵심 패턴과 규제·보안 용어를 정리합니다.

7-1. 제조업 아키텍처 (Manufacturing DX)

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
제조업 DX	제조 현장을 디지털로 전환하는 4대 핵심 과제입니다.	• 4대 과제: 설비 모니터링 + 예측 정비 + 품질 관리 + 공급망 최적화. • 특징: 공장 가동 중단이 곧 손실이므로 안정성이 최우선입니다.
IoT 파이프라인 6단계	센서 데이터가 수집되어 분석되기까지의 표준 데이터 흐름입니다.	• 6단계: 센서 → 엣지(현장 1차 처리) → 스트림(실시간 수집) → 처리 → 저장 → 분석. • 엣지의 역할: 현장에서 먼저 처리해 지연과 전송 비용을 줄입니다.
예측 정비 (Predictive)	고장이 나기 전에 미리 예측해 정비하는 방식입니다.	• 구성: SageMaker(ML) + IoT 데이터 = 고장 시점 예측 → 예상 ROI(투자 대비 효과) 산정. • 효과: 계획 외 가동 중단을 줄여 비용과 위험을 함께 낮춥니다.

7-2. 금융·의료 규제 & 보안 용어

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
PCI-DSS	신용카드 결제 데이터를 보호하기 위한 국제 보안 표준입니다.	• 12개 요구사항: 네트워크 분리, 데이터 암호화, 로그 관리 등 12개 항목을 충족해야 합니다. • 대상: 카드 정보를 저장·처리·전송하는 모든 사업자.
ISMS-P	국내 정보보호 및 개인정보보호 관리체계 인증입니다.	• 특징: 금융사 등은 사실상 필수이며, 연 1회 재인증(사후심사)을 받아야 합니다.
HIPAA	미국의 환자 건강 정보 보호법입니다.	• 핵심 의무: PHI 암호화, 접근 통제, 그리고 클라우드 사용 시 BAA(사업 제휴 협약) 체결이 필요합니다.
PHI	Protected Health Information. 환자를 식별할 수 있는 건강 정보입니다.	• 최고 보호 등급: 이름·진단·기록 등이 결합된 정보로 가장 엄격하게 보호해야 합니다.
CloudHSM	암호화 키를 전용 하드웨어에서 직접 관리하는 보안 모듈입니다.	• 인증 수준: FIPS 140-2 Level 3 인증을 충족합니다. • KMS와의 차이: KMS는 AWS 관리형 공용, CloudHSM은 고객 전용 하드웨어로 통제권이 더 강합니다.
HealthLake	의료 데이터를 표준 형식으로 저장·분석하는 관리형 서비스입니다.	• 표준: FHIR R4 표준 기반의 HIPAA 인증 의료 데이터 저장소입니다.
RTO / RPO	재해 복구(DR) 목표를 정의하는 두 지표입니다.	• RTO(복구 시간 목표): 장애 후 ‘얼마나 빨리’ 복구할지(예: 2시간). • RPO(복구 시점 목표): ‘얼마만큼의 데이터 손실’을 허용할지(예: 1시간 전 시점). • 금융 예시: 강한 규제로 RTO 2시간, RPO 1시간 같은 엄격한 목표를 둡니다.

[비교 표] 금융 vs 의료 아키텍처

비교 항목	금융 아키텍처	의료 아키텍처
핵심 규제	전자금융거래법 + PCI-DSS + ISMS-P	의료법 + HIPAA
핵심 구성	CloudHSM, 5년 감사 로그, Multi-Region DR	PHI 격리, 동의 관리, HealthLake, Comprehend Medical
최우선 가치	거래 무결성·감사 추적	환자 정보(PHI) 보호

공통 설계 원칙: 보안 기둥을 최우선에 두고, 규제 → 요구사항 → 아키텍처 → 감사 자동화 순서로 설계합니다.

7-3. 산업별 설계 & Well-Architected 연결

핵심 키워드	개념 정의	핵심 정보 및 작동 원리
산업별 설계	산업마다 규제와 제약이 아키텍처를 결정한다는 설계 관점입니다.	• 대상 산업: 제조 / 금융 / 유통 / 의료. • 핵심: 기술 선택보다 ‘그 산업의 규제·제약’이 먼저 아키텍처의 틀을 정합니다.
설계 프로세스 (IT인프라 연결)	비즈니스 요구를 아키텍처로 옮기는 표준 사고 흐름입니다.	• 흐름: 5W1H(요구 정의) → As-Is/To-Be(현재·목표) → KPI(성과 지표) → 아키텍처(설계) → WA 체크(검증).
Well-Architected 6기둥	AWS가 제시하는 좋은 아키텍처의 6가지 평가 축입니다.	• 6기둥: 운영 우수성 · 보안 · 안정성 · 성능 효율성 · 비용 최적화 · 지속 가능성. • 용도: 설계가 끝나면 이 6축으로 점검(WA Review)해 약점을 보완합니다.

 
여기까지 읽어주셔서 감사합니다.
이상으로 10주차 후기를 마치겠습니다.