Tessa's Dev Blog

🐛 Nuxt SSR 환경에서 `useState`에 함수 저장 시 발생한 Serialization 오류

Thu, 21 May 2026 00:00:00 GMT

🐛 Nuxt SSR 환경에서 `useState`에 함수 저장 시 발생한 Serialization 오류

Nuxt 3 · SSR · useState · Payload Serialization

직접 진입과 SPA 네비게이션에서 동작이 갈리는 이유를 파헤친 기록

TL;DR

Nuxt 3의 useState는 SSR → CSR 전달 과정에서 payload를 직렬화(serialize)하는데, 이때 함수(function) 타입은 직렬화가 불가능해 500 에러가 발생한다. import.meta.server 가드로 서버 측 등록을 우회해 해결했지만, 근본적으로는 "함수를 전역 상태에 담는" 설계 자체를 재고할 필요가 있었다. 대안으로는 Pinia setup store 내부에 핸들러를 보관하는 방식이 가장 자연스러워 보인다.

📌 개요

항목	내용
환경	Nuxt 3, Vue 3 (Composition API), SSR
영향 범위	새로고침 플로팅 버튼이 동작하는 모든 라우트
발생 조건	페이지 직접 진입(URL 입력) 또는 브라우저 새로고침 (= SSR 경로)
해결 방식	`import.meta.server` 가드로 서버 측 registry 등록 차단
소요 시간	(작성 시 채우기)

🔥 증상

❌ 페이지를 직접 진입(브라우저 주소창에 URL 입력) 또는 브라우저 새로고침 시 → 500 에러 발생
✅ 탭/링크 클릭으로 SPA 네비게이션 시에는 정상 동작
즉, SSR이 동작하는 경로에서만 발생, CSR 전환 경로에서는 미발생

이 패턴은 거의 항상 "SSR에서만 깨지는 무언가" — 윈도우 객체 접근, hydration mismatch, 또는 payload 직렬화 실패 — 셋 중 하나를 의심하게 된다.

🔍 원인 분석

🧪 1차 시도 — 인터페이스/옵션 확인

우선 호출되는 컴포저블의 타입과 인터페이스를 한 차례 점검
useAsyncData의 server: false 옵션을 적용해 SSR 시점에 API 호출을 우회하면 정상 동작하는지 확인
결과: 여전히 동일한 500 에러 발생
의미: API fetch 자체의 문제가 아님. SSR 렌더링 파이프라인의 더 앞단에서 깨지고 있다.

🧪 2차 시도 — API 동작 순차 배제

페이지에서 호출되는 API들을 하나씩 비활성화하며 어디서 터지는지 좁혀보려 함
결과: 모든 API가 SSR 시점에서 동일하게 실패함
의미: 특정 API의 문제가 아니라 SSR 렌더링 자체가 망가져 있다. 페이로드 직렬화 단계를 의심해야 함.

🧪 3차 시도 — SSR 코드 / `useState` 분석 → 🎯 원인 발견

최근 도입한 refresh registry 패턴의 useState 저장값을 점검
registry에 각 컴포저블의 refresh 함수(function) 가 그대로 등록되고 있었음
Nuxt 3는 SSR 렌더링 후 클라이언트로 페이로드를 전달할 때 devalue를 사용해 상태를 직렬화한다. 함수는 직렬화 대상이 아니다.
따라서 SSR 렌더 도중 registry에 함수가 등록되는 순간, 응답 직전 payload serialization에서 깨지며 500을 반환한 것

// ❌ Before — 서버에서도 함수가 useState에 등록됨
const registry = useState<Record<string, () => Promise<void>>>(
  'refresh-registry',
  () => ({})
)

export function useRegisterRefresh(key: string, fn: () => Promise<void>) {
  registry.value[key] = fn // ← SSR 페이로드 직렬화 시 폭발
}

// ✅ After — 서버에서는 등록 자체를 스킵
export function useRegisterRefresh(key: string, fn: () => Promise<void>) {
  if (import.meta.server) return // 🛡️ SSR 가드
  registry.value[key] = fn
}

registry는 클라이언트에서만 의미 있는 상태(사용자 인터랙션으로 트리거되는 새로고침 함수들의 모음)이므로, 서버에서 굳이 채울 필요가 없다. 가드를 두는 것이 자연스러운 결론.

🌱 문제 발생의 배경

처음부터 registry 패턴이었던 것은 아니다. 요구사항이 한 단계씩 늘어나면서 점진적으로 구조가 커진 케이스다.

1차 구현 — 스크롤 시 노출되는 "새로고침 플로팅 버튼" 작업
- 단순히 refreshTrigger를 자식 컴포넌트에 prop/provide로 내려주고, 각 컴포넌트에서 자체적으로 refresh를 수행
요구사항 변경 — UI/UX에서 새로고침 시 전체 화면 loading indicator 추가 요청
- 개별 컴포넌트들의 상태를 모아 "전체가 새로고침 중인지"를 알 필요가 생김
- → isRefreshing 전역 상태 도입
구조 변경 — 일원화된 흐름을 위해 registry 패턴 도입
- 각 컴포저블이 마운트 시점에 자신의 refresh 함수를 registry에 등록
- 플로팅 버튼 클릭 → refreshAll() → registry의 모든 함수를 Promise.all로 실행 → isRefreshing 토글
테스트 통과 — SPA 네비게이션 환경에서는 모든 flow가 정상 동작
🔥 사건 발생 — 직접 진입/새로고침(=SSR 경로)에서 500

회고 포인트: SPA 내부 동선만 테스트했기 때문에, registry에 함수가 등록되어 payload에 포함되는 시점이 클라이언트뿐이었다. 직접 진입 케이스에서는 첫 페이지가 SSR로 그려지므로 등록 시점이 서버로 옮겨가 폭발했다. 향후 SSR 환경에서는 "직접 진입/새로고침 경로"를 반드시 회귀 테스트에 포함해야 한다.

💭 회고 및 대안 고찰

이번 이슈는 단순히 가드 한 줄로 해결됐지만, 그보다 더 본질적인 질문은 "애초에 함수를 전역 상태에 넣는 것이 옳은가?" 였다. 가능한 대안들을 정리해본다.

A. `useState` 대신 `ref`(모듈 스코프)로 관리

// composables/useRefreshRegistry.ts
const registry = ref<Record<string, () => Promise<void>>>({}) // 모듈 스코프

export function useRefreshRegistry() {
  return { registry, register, refreshAll }
}

✅ 모듈 스코프 ref는 SSR 페이로드 직렬화 대상이 아님 → 직렬화 오류는 발생하지 않는다.
❌ 그러나 Nuxt SSR에서 모듈 스코프 변수는 요청 간 공유되어 다른 사용자의 상태가 섞일 수 있다. (Nuxt 공식 문서가 useState를 권장하는 이유이기도 함)
❌ 실용적으로는 "registry는 클라이언트에서만 의미 있으니 SSR 메모리 공유는 문제 안 됨"이라고 합리화할 수 있지만, "왜 SSR-safe한 useState를 안 쓰지?" 라는 질문에 매번 답해야 한다는 점에서 코드 컨벤션상 깔끔하지 않다.
→ 채택할 거라면 명시적인 주석/네이밍(_clientOnlyRegistry 등)이 필수.

B. Event Bus (mitt 등) 도입

// utils/refreshBus.ts
import mitt from 'mitt'
export const refreshBus = mitt<{ refresh: void; refreshDone: string }>()

// 각 컴포저블에서
onMounted(() => {
  refreshBus.on('refresh', handleRefresh)
})
onBeforeUnmount(() => refreshBus.off('refresh', handleRefresh))

✅ 함수를 상태에 담을 필요가 없어진다. 각 컴포넌트는 자기 리스너만 등록하면 됨 → 직렬화 이슈 원천 차단.
✅ 컴포넌트 마운트/언마운트 라이프사이클과 자연스럽게 묶여 cleanup이 명확하다.
⚠️ isRefreshing 같은 "전체 상태"는 별도 관리 필요. (e.g., refreshDone 이벤트를 모아 카운트하는 작은 store)
⚠️ Event bus는 흐름이 코드 상에서 추적하기 어려워지는 단점이 있다. 누가 발행하고 누가 구독하는지 IDE 레퍼런스만으로 보이지 않는다.
→ 작은 규모에선 매우 깔끔하지만, 화면 수가 늘어나면 디버깅 난이도가 올라간다.

C. Pinia Store + Action 직접 호출

export const useRefreshStore = defineStore('refresh', () => {
  const handlers = new Map<string, () => Promise<void>>() // store 인스턴스 내부 Map
  const isRefreshing = ref(false)

  function register(key: string, fn: () => Promise<void>) {
    if (import.meta.server) return
    handlers.set(key, fn)
  }

  async function refreshAll() {
    isRefreshing.value = true
    try {
      await Promise.all([...handlers.values()].map(fn => fn()))
    } finally {
      isRefreshing.value = false
    }
  }
  return { register, refreshAll, isRefreshing }
})

✅ Pinia의 state만 SSR 직렬화 대상이고, setup store 내부의 일반 변수(Map, 클로저 등)는 직렬화 대상이 아니다. 함수도 store 내부에 안전하게 보관 가능.
✅ isRefreshing만 reactive state로 두면 자연스럽게 SSR-safe.
✅ 의존성과 흐름이 명시적 → 테스트/추적이 쉽다.
⚠️ Pinia 의존을 새로 추가해야 한다면 비용. (이미 쓰고 있다면 사실상 베스트)
→ 현재 코드베이스에 Pinia가 이미 있다면 이 방법이 가장 자연스럽고 안전해 보인다.

D. `provide` / `inject` (컴포넌트 트리 의존성 주입)

부모(layout 또는 페이지)에서 registry를 만들고 자식에서 inject 해서 등록
✅ Vue 트리 안에 갇히므로 SSR 페이로드와 무관
❌ 트리 외부(plugin, util 등)에서 호출 불가 → 활용 범위가 좁다.

📊 비교 정리

방식	SSR 직렬화 안전	흐름 추적 용이성	도입 비용	추천도
`useState` + 함수 등록 (현재)	❌ (가드 필요)	보통	낮음	△ (가드로 봉합)
모듈 스코프 `ref`	⚠️ (요청 간 공유 주의)	보통	낮음	△
Event Bus	✅	❌ 약함	낮음	○ (소규모)
Pinia Setup Store	✅	✅ 강함	낮음(이미 사용 중)	◎
`provide` / `inject`	✅	보통	낮음	△ (범위 제약)

잠정 결론: 현재는 가드로 봉합했지만, 후속 리팩토링 시 Pinia setup store 내부 Map으로 핸들러를 보관하고, isRefreshing만 reactive state로 노출하는 형태로 옮기는 것이 가장 깔끔할 듯하다.

🧠 배운 점

SSR과 CSR의 가장 큰 차이는 "상태가 직렬화되어 네트워크를 건너간다"는 점이다. CSR 기반으로만 작업해온 패턴 — 특히 함수/클래스 인스턴스/Symbol 등을 전역 상태에 거리낌 없이 담는 패턴 — 은 SSR에서는 곧장 폭탄이 된다.
useState의 정체성을 다시 확인했다. 단순한 "전역 ref"가 아니라, 요청 단위로 격리되고 SSR → CSR로 페이로드를 통해 전달되는 상태다. 그래서 직렬화 가능한 값(POJO, 원시값, 배열, 일반 객체)만 담아야 한다.
테스트 동선은 사용자가 페이지에 도달할 수 있는 모든 경로를 포함해야 한다. SPA 내부 네비게이션과 직접 진입/새로고침은 SSR 관점에서 완전히 다른 코드 경로다.
패턴 도입(여기서는 registry 패턴) 자체가 잘못된 것은 아니지만, "이 자료구조가 어디서 살아야 하는가 — 서버? 클라이언트? 둘 다?" 를 먼저 묻고 들어갔으면 더 빨리 도달했을 결론이었다.

📚 참고 자료

Nuxt 3 useState 공식 문서 — payload serialization 관련 설명
devalue — Nuxt가 payload 직렬화에 사용하는 라이브러리, 지원/미지원 타입 확인
Nuxt import.meta 문서 — import.meta.server / import.meta.client 가드 패턴
Pinia Setup Store — store 내부 비-reactive 변수 활용

AWS 시험 회고

Tue, 28 Apr 2026 00:00:00 GMT

AWS 시험 회고 ☁️

약 1달 만에 쓰는 시험 후기

2026년 04월 03일, AWS SAA-C03 (AWS Certified Solutions Architect - Associate) 시험을 응시했다. 후기를 쓰는 지금으로부터 약 1달 전쯤의 일이다.

이직 과정이 마무리되고, 새로 들어가는 회사 면접에서 클라우드 관련 질문을 받았는데 제대로 된 답변을 하지 못했던 기억이 난다. 네트워크, 인프라 관련 지식이 전체적으로 빈약했던 터라, 시간이 남는 김에 겸사겸사 준비를 시작해 한 3~4주 정도 준비 기간을 거쳤다.

처음에는 방대한 문제 범위에 당황하기도 했다. 4지선다 형식이라 질문-답변을 그냥 외우는 방식일 거라 막연히 기대했는데, 어느 정도 사고가 필요한 유형이라 많이 당황했던 기억이... 😅 그래도 차근차근 문제를 풀고 개념을 익히며 준비했고, 걱정했던 것보다 높은 점수로 자격증을 취득할 수 있었다. 🎉

시험 준비 방법 📚

1~2주차 — 강의 듣기

기본기도 없고 실무 활용 경험도 부족했기 때문에 개념부터 제대로 익혀야겠다는 생각에, 유명한 Stephane Maarek의 강의를 신청해서 들었다.

여러 블로그에서 경고하듯 강의 분량이 상당해서 시간적 여유가 없는 분들에게 선뜻 추천하기는 어렵지만, 내용이 비교적 상세하고 Hands-on 실습 과정이 꽤 유용했다. 중간중간 시험 팁도 짚어주고, 무엇보다 서비스별 Use Case와 비용 비교 파트가 문제 풀이 시에 정말 많은 도움이 됐다.

평소 실무에서 접하는 서비스는 한정적인 경우가 많은 만큼, 낯선 서비스에 대한 기본 이론과 시험에서 주의해서 봐야 할 포인트를 강의로 익힌 뒤 Dump 문제 풀이로 넘어가는 흐름을 추천한다.

3주차 — Dump + 강의 노트 정리

Dump 문제 풀이는 오답 정리를 별도로 진행하지 않았다. 문제를 비교적 빠르게 푸는 편인데도 수백 문제를 한꺼번에 풀다 보면 정리할 시간이 나지 않기도 하고, 유사한 문제를 계속 틀리다 보면 결국 어떤 유형(예를 들면 비용 효율적인 답을 고르는 문제)과 어떤 서비스에서 자주 막히는지 감이 잡히기 때문이다. 오답 정리보다는 자주 등장하는 시나리오와 키워드를 중심으로 강의 노트와 함께 정리해나갔다.

총 약 400~500문제 정도를 풀었고, 시간 날 때마다 틈틈이 진행했다. 여러 블로그에서 공유하는 Dump PDF를 다운로드받아 풀거나, 검색으로 나오는 시험 사이트들을 그때그때 활용했다. Examtopics의 경우 일정 문제 수를 넘기면 유료로 전환되어서, 약 50문제 풀이 후에는 PDF 문제 중 헷갈리는 답변의 Discussion 확인 용도로만 검색하고 별도 구매는 하지 않았다.

3주차 후반쯤에는 Cloud Pass 앱으로 합격했다는 후기를 보고 앱을 다운로드해 문제를 풀었다. 개인적으로는 정말 강추한다. 수록 문제가 1,000개가 넘는데, 시간 관계상 다 풀지는 못했다. 유사하거나 동일한 문제도 꽤 있었으니, 영역별로 집중해서 풀어보는 방식을 추천한다. 많이 풀면 풀수록 어떤 부분이 약한지, 어떤 함정 옵션에 자주 넘어가는지 파악할 수 있고, 이를 기반으로 추가적인 학습 및 개념 정리를 할 수 있다.

4주차 — 키워드 위주 개념 정리 & 백서(White Paper) 읽기

어느 정도 문제를 풀고부터는 자주 틀리는 키워드 위주로 AWS 공식 Documentation을 찾아보고 다시 문제를 푸는 방식으로, 헷갈리는 시나리오에 대한 나만의 정리를 해나갔다.

백서(White Paper)를 읽는 것도 꽤 도움이 됐다. 예상 문제가 직접 나오는 건 아니지만, Best Practice를 설명해주기 때문에 해당 케이스와 부합하는 시나리오에서 선택지를 소거하고 최적의 답을 찾아내는 데 좋은 길라잡이가 되어 주었다. 특히 장애 복구(Disaster Recovery) 관련 백서는 꼭 한 번 읽어보길 추천한다.

시험 응시 🖥️

온라인 테스트로 진행했다.

시험 일정을 예약하면 이메일을 받게 되는데, 시험 환경 테스트는 사전에 꼭 진행해야 한다. System test는 시험 환경이 조금이라도 달라지면 다시 진행하기를 권장하는데, 내 경우에는 Email을 받자마자 한 번, 시험날 약 1시간 전에 한 번 더 진행했다. 시험 환경 때문에 시험에 불이익을 받는 불상사를 받으면 굉장히 억울할테니, 여러 번 검증하는 걸 추천한다.

실제 시험 Check-In을 하면 준비된 신분증 촬영, 주변 환경 촬영을 진행한다. 이 과정을 거친 후 매칭된 감독관과 채팅을 통해 시험 전 추가 검증 절차를 진행한다. 채팅을 통해 음성 통화도 진행할 수 있는데 이 과정에서 간단한 의사소통을 하고, 요구 사항에 대응해야 하기 때문에 기본적인 영어 의사소통을 할 수 있어야 한다. 주변 환경 체크를 꽤 꼼꼼히 진행하고, 웹캠으로 주변을 360도 촬영해 달라는 요청도 받았던 만큼 시험 전 주변 정리는 미리 해두는 편이 좋다.

모든 절차를 마무리하고 감독관의 승인이 떨어지면 바로 시험에 응시하면 된다.

나의 경우 ESL 추가 시간은 별도로 신청하지 않았고, 영어로 문제를 푸는 게 더 익숙해서 영어로 응시했다. 문제 풀이를 빠르게 하는 편이라 시간은 넉넉했다. 첫 번째 풀이에 약 60분을 쓴 뒤, 나머지 시간은 Flag 표시해 둔 문제를 다시 검토하고 헷갈렸던 답변을 재확인하는 데 활용했다.

시험 결과 🏆

결과가 보통 5시간 이내에 나온다는 말에 계속 기다렸는데, 내 경우에는 그렇게 빠르지 않았다.

시험 시작이 8시 30분이었고 완료하고 나니 거의 11시였는데, 새벽 3시까지 뜬눈으로 기다렸지만 결과가 오지 않았다. Credly에서 뱃지가 먼저 날아오는 경우가 많고, 먼저 안 날아오는 경우 그렇게 좋은 지표가 아니라는 말에 떨어졌나... 좌절하며 결국 포기하고 잠들었다가, 아침에 일어나니 자격증 배지 등록 관련 이메일이 반갑게 도착해 있었다. 😄 ~~이 메일을 얼마나 기다렸는지...~~ <br> ~~자기 전까지 안 오길래 다음 시험을 준비해야하나 무진장 마음고생했다...~~ <br> ~~환율이 올라 20만원이 넘는 시험인지라...~~

시험을 마치며 💬

Dump 문제가 그대로 나온다는 후기도 있고, 예상치 못한 질문에 당황했다는 후기도 봤는데, 내 경우에는 Dump가 그대로 나오는 경우는 거의 없었다. 문제 자체를 많이 푼 편은 아니라 못 봤거나 잊어버린 문제가 출제되었을 수는 있지만, 전체적으로는 Dump만으로 완전히 대비할 수 있는 시험은 아니었다.

다만 여러 블로그에서 강조하듯, 키워드와 시나리오 위주로 개념을 정리하는 것은 확실히 효과가 있다. 수능의 킬러 문항처럼 의도적으로 까다롭게 낸 문제도 몇 개 있었지만, 그런 문제를 제외하면 대부분 정리해둔 개념 범위 안에서 출제됐다. 결국 얼마나 논리적인 사고로 최적의 답을 추론할 수 있는가를 보는 시험이라는 느낌이었다. 대부분의 문제는 2개의 선택지를 소거하고, 남은 2개 중에서 고민하는 구조였고 — 그 안에서 나만의 답을 찾는 데 꽤 많은 시간을 쏟았다.

조금은 충동적으로 응시한 시험이었지만, 나름대로 빡세게 준비했고 그만큼 좋은 결과를 얻을 수 있어 만족스럽다. 3년이 지나기 전에 Professional Level 시험도 도전할 예정이다. 🚀

aspect-ratio Troubleshooting on Safari

Thu, 23 Apr 2026 00:00:00 GMT

aspect-ratio Troubleshooting on Safari

TL;DR — Safari에서 렌더링 중 레이아웃이 순간적으로 틀어졌다 복원되는 fluctuation 현상. 부모 div에 width/height가 둘 다 명시된 상태에서 자식 img에 aspect-ratio를 주면, Safari가 이미지 로딩 중 사이즈를 잘못 계산해 인접 요소를 튕겨낸다. 해결책은 이미지 컴포넌트에서 aspect-ratio를 제거하고 object-fit: cover로 대체하는 것이다.

배경

기능 개발 진행 후 확인하는 도중 Safari에서 요소의 높이가 shifting 되었다가 다시 원하는 형태로 복원되는 fluctuation 문제가 발생했다. 디자인 시스템의 공통 이미지 컴포넌트(ex - ImageComponent)는 외부에서 ratio prop을 받아 내부 <img> 태그에 CSS로 aspect-ratio를 주입하는 구조였다. Chrome/Firefox에서는 정상 동작했으나, Safari에서만 렌더링 도중 레이아웃이 순간적으로 틀어졌다가 복원되는 현상이 발견되었다.

상위 컨테이너의 width/height가 고정되어 있어 렌더링이 완전히 끝나면 크기와 정렬은 맞춰진다. 그러나 렌더링 완료 이전, 이미지 처리 도중에 요소가 순간적으로 잘못된 크기를 갖고 이 과정에서 위아래 인접 요소들이 padding이나 margin이 갑자기 생긴 것처럼 튕겨나갔다가 다시 원래 자리로 돌아오는 증상이 반복되었다. 네트워크 속도가 느릴수록 이미지 수신 latency가 길어지면서 현상이 더 뚜렷하게 관측되었다.

아래는 실제 증상을 재현한 애니메이션이다. 아이콘 이미지가 로딩되는 동안 일시적으로 세로로 늘어나 인접한 해시태그 chip들을 36px 아래로 밀어냈다가, 로딩 완료 후 원래 자리로 돌아오는 fluctuation 현상을 보여준다.

컴포넌트 구조

문제가 발생한 DOM 구조를 대략적으로 표시하면 다음과 같다.

flex-container
└── flex-container
      └── flex-container
            └── div.icon-wrapper        ← width: 40px; height: 40px; border-radius: 50%
                  └── ImageComponent    ← aspect-ratio: 1 prop 전달됨
                        └── <img>

문제가 된 코드

<!-- 사용처 -->
<IconWrapper>
  <ImageComponent :src="imgSrc" aspect-ratio="1" />
</IconWrapper>

/* IconWrapper */
.icon-wrapper {
  width: 40px;
  height: 40px;
  border-radius: 50%;
  overflow: hidden;
}

/* ImageComponent 내부 — aspect-ratio를 prop으로 주입 */
img {
  aspect-ratio: v-bind(aspectRatio); /* → aspect-ratio: 1 */
}

엔진 처리 흐름 비교

width + height + aspect-ratio가 모두 설정된 요소를 두 엔진이 처리하는 방식을 나타낸 다이어그램이다.

flowchart TB
  shared["width + height + aspect-ratio<br/>(element has all three set)"]

  shared -->|"layout starts"| wk1["RenderBox layout starts"]
  shared -->|"layout starts"| bl1["LayoutNG build phase"]

  wk1 --> wk2["shouldComputeLogicalHeight<br/>FromAspectRatio()"]
  wk2 -->|"height set → skip"| wk3["computeLogicalHeight()<br/>aspect-ratio bypassed"]
  wk3 --> wk4["❌ aspect-ratio 무시됨<br/>stretch 높이 그대로 적용"]

  bl1 --> bl2["ComputeBlockSize()<br/>treats ratio as hint"]
  bl2 -->|"ratio overrides"| bl3["height recomputed<br/>width ÷ aspect-ratio"]
  bl3 --> bl4["✓ aspect-ratio 적용됨<br/>올바른 비율 렌더링"]

  style shared fill:#CECBF6,color:#3C3489,stroke:#AFA9EC
  style wk2   fill:#FAC775,color:#854F0B,stroke:#EF9F27
  style bl2   fill:#FAC775,color:#854F0B,stroke:#EF9F27
  style wk4   fill:#F5C4B3,color:#993C1D,stroke:#F0997B
  style bl4   fill:#9FE1CB,color:#0F6E56,stroke:#5DCAA5

출처:

WebKit: WebCore/rendering/RenderBox.cpp — shouldComputeLogicalHeightFromAspectRatio()

Blink: blink/renderer/core/layout/

원인 분석

1. `aspect-ratio`는 weak declaration이다

CSS 스펙상 aspect-ratio는 약한 선언(weak declaration) 이다. width와 height가 둘 다 명시된 경우, 브라우저는 aspect-ratio를 무시하고 명시된 값을 우선한다.

/* ❌ 이 상태에서 aspect-ratio는 무시된다 */
.icon-wrapper {
  width: 40px;
  height: 40px; /* height가 확정값으로 존재 */
}
img {
  aspect-ratio: 1; /* 무시됨 */
}

2. 3단 중첩 flex의 `align-items: stretch` 전파

Flexbox의 기본값은 align-items: stretch다. 3단 중첩된 flex 컨테이너를 거치면서 이 stretch 값이 누적 전파되어, .icon-wrapper의 높이가 flex 라인 높이에 맞게 강제로 늘어날 수 있다. 이렇게 늘어난 높이가 img에 전달되면 aspect-ratio와 충돌한다.

flex (stretch) → flex (stretch) → flex (stretch) → div height 결정
                                                           ↓
                                                   img가 이 height를 받음
                                                   → aspect-ratio 충돌

3. Safari vs Chrome의 해석 차이

	Chrome (Blink)	Safari (WebKit)
`height`가 명시된 상태에서 `aspect-ratio` 처리	aspect-ratio를 힌트로 사용해 재계산	명시된 `height`를 확정값으로 간주, aspect-ratio 무시
stretch로 전파된 높이 처리	aspect-ratio가 있으면 높이를 재계산	전파된 height를 그대로 확정값으로 사용

Chrome은 aspect-ratio가 있으면 height를 재계산하고, Safari는 height가 있으면 aspect-ratio를 무시한다.

CSS 스펙이 이 엣지 케이스를 명확하게 정의하지 않기 때문에 두 브라우저 모두 스펙 위반은 아니다. Safari가 스펙에 더 엄격하고, Chrome이 더 관대하게 해석한다고 볼 수 있다.

4. Safari + lazy loading → layout fluctuation

loading="lazy" 이미지는 로드 전에 intrinsic size를 알 수 없다. Safari에서는 이 상태에서 HTML width/height attribute 기반의 자동 비율 계산도 적용되지 않아 문제가 복합된다.

참고: WebKit Bugzilla #224197

이 두 가지가 결합되면 다음과 같은 순서로 fluctuation이 발생한다.

1. 이미지 로드 전
   → Safari가 aspect-ratio를 무시한 채 stretch 높이로 img 크기를 잡음
   → 잘못된 크기가 상위 flex에 전파 → 인접 요소 밀려남

2. 이미지 수신 완료
   → 컨테이너의 고정 width/height가 최종 기준이 되어 크기 복원
   → 인접 요소 다시 원래 자리로 돌아옴

3. 결과
   → 렌더링 완료 후에는 정상으로 보이지만
   → 네트워크 latency만큼 fluctuation이 지속되어 사용자에게 노출됨

이는 Chrome이 aspect-ratio를 힌트로 사용해 이미지 로드 전에도 올바른 크기를 미리 계산하는 것과 대비되는 동작이다. Chrome에서는 fluctuation 자체가 발생하지 않는다.

해결 방법

핵심 원칙

부모가 width + height를 둘 다 확정하고 있는 경우, 자식 img의 aspect-ratio는 무의미하거나 충돌을 유발한다.
이 경우 aspect-ratio의 역할은 object-fit: cover로 대체해야 한다.

수정된 코드

<!-- 사용처 — aspectRatio prop 전달 제거 -->
<IconWrapper>
  <ImageComponent :src="imgSrc" />
</IconWrapper>

/* IconWrapper — 크기와 모양을 여기서 확정 */
.icon-wrapper {
  width: 40px;
  height: 40px;
  border-radius: 50%;
  overflow: hidden;
  flex-shrink: 0; /* flex 환경에서 찌그러짐 방지 */
}

/* ImageComponent 내부 — 부모를 채우는 역할만 담당 */
img {
  width: 100%;
  height: 100%;
  object-fit: cover; /* 비율 유지하며 크롭, aspect-ratio 대체 */
  display: block;    /* inline 기본값의 baseline 공백 제거 */
  /* aspect-ratio 제거 */
}

aspectRatio prop이 반드시 필요한 경우

만약 컴포넌트 외부에서 비율을 제어해야 하는 요구사항이 있다면, img가 아닌 wrapper div에 aspect-ratio를 적용하고 height는 제거한다.

/* ✅ aspect-ratio는 wrapper에서 제어, height는 제거 */
.icon-wrapper {
  width: 40px;
  /* height 제거 */
  aspect-ratio: v-bind(aspectRatio); /* 1, 16/9 등 외부에서 주입 */
  border-radius: 50%;
  overflow: hidden;
  flex-shrink: 0;
}

img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  display: block;
}

수정 전/후 비교

	수정 전	수정 후
비율 제어 위치	`img` (자식)	제거 / wrapper로 이동
Safari 증상	렌더링 중 fluctuation → 인접 요소 튕김	없음
저속 네트워크	증상 심화 (이미지 latency에 비례)	무관
Chrome/Firefox 동작	정상 (관대한 해석)	정상
이미지 크롭 방식	미정의	`object-fit: cover`

타 라이브러리의 설계 판단

같은 문제를 어떻게 회피했는지 주요 라이브러리를 비교하면, 이번 픽스 방향이 업계 표준과 일치함을 확인할 수 있다.

Chakra UI v3 `<Image>`

aspectRatio prop을 받지만, img 자체에는 절대 aspect-ratio를 주지 않는다. 내부 구조는 다음과 같다.

// Chakra UI Image — aspectRatio prop 전달 시 내부 렌더링 구조
<Box
  position="relative"
  aspectRatio={ratio}     // ← wrapper Box에만 aspect-ratio 적용
  overflow="hidden"
>
  <img
    style={{
      position: "absolute",
      inset: 0,             // top/right/bottom/left: 0
      width: "100%",
      height: "100%",
      objectFit: "cover",
    }}
  />
</Box>

img에 position: absolute를 주는 것이 핵심이다. absolute 요소는 flex formatting context에서 이탈하기 때문에 부모 flex의 align-items: stretch 전파 경로 자체가 끊어진다. wrapper Box는 height를 명시하지 않은 채 aspect-ratio만 갖기 때문에 Safari의 shouldComputeLogicalHeightFromAspectRatio()가 true를 반환해 비율 계산이 정상 작동한다.

참고: Chakra UI Image 컴포넌트 문서

Next.js `<Image>`

width + height prop을 필수로 받아 크기를 미리 확정한다. aspect-ratio는 사용하지 않는다.

// Next.js Image — 내부 렌더링
<span style={{ display: "inline-block", width, height }}>
  <img style={{ width: "100%", height: "100%", objectFit: "cover" }} />
</span>

이미지 로드 전에도 공간이 pixel 단위로 확정되기 때문에 CLS(Cumulative Layout Shift)가 0이 된다.

세 접근 비교

	직접 `aspect-ratio` (문제 케이스)	Next.js `<Image>`	Chakra UI `<Image>`
비율 제어 위치	`img` 직접	width + height 명시	wrapper `Box`
`img` position	flex child (static)	static / absolute	`absolute` (inset: 0)
flex stretch 영향	받음 (Safari 문제 원인)	없음	없음
Safari 안전성	불안정	안정	안정
공통 원칙	—	`img`에 `aspect-ratio` 주지 않음	`img`에 `aspect-ratio` 주지 않음

부록: flex `align-items: stretch` 기본값 이해하기

Safari 버그의 근본 원인이 되는 align-items: stretch 기본값의 동작을 세 단계로 정리한다.

1단계: stretch (기본값) — 버그 발생

align-items를 명시하지 않으면 stretch가 적용된다. 가장 키가 큰 flex 자식의 높이로 모든 자식이 맞춰진다.

flex-container (align-items: stretch — 기본값)
  ├── sibling (height: 96px — 가장 키 큰 자식)
  └── icon-wrapper (height: 96px ← stretch로 결정)
        └── img (height: 100% = 96px, aspect-ratio 무시됨)

.flex-container { display: flex; /* align-items 미지정 → stretch */ }
.icon-wrapper   { width: 44px; /* height 없음 → stretch로 결정 */ }
img             { aspect-ratio: 1; /* Safari에서 무시됨 */ }

2단계: flex-start 적용 — stretch 해제

flex-container (align-items: flex-start)
  ├── sibling (height: 96px)
  └── icon-wrapper (height: 44px ← 자체 크기 유지)
        └── img (height: 100% = 44px, aspect-ratio 정상)

.flex-container { display: flex; align-items: flex-start; }
.icon-wrapper   { width: 44px; height: 44px; }
img             { width: 100%; height: 100%; object-fit: cover; }

3단계: position: absolute 분리 — Chakra UI 방식

img를 position: absolute로 꺼내면 flex formatting context를 완전히 이탈해 stretch 전파 경로 자체가 차단된다.

flex-container
  └── icon-wrapper (position: relative, aspect-ratio: 1, width: 44px)
                    → 높이: 44px (aspect-ratio로 결정)
        └── img (position: absolute, inset: 0)
                    → flex 자식 아님 → stretch 무관

.icon-wrapper {
  width: 44px;
  aspect-ratio: 1;    /* wrapper에서 비율 제어 */
  position: relative;
  border-radius: 50%;
  overflow: hidden;
}
img {
  position: absolute; /* flex context 이탈 */
  inset: 0;
  width: 100%;
  height: 100%;
  object-fit: cover;
}

align-items: stretch가 중첩 flex에서 전파되는 과정

3단 중첩 flex에서는 이 효과가 누적된다.

flex-A (stretch) → flex-B (stretch) → flex-C (stretch) → icon-wrapper 최종 height 결정
                                                                 ↓
                                                   img가 이 height를 받음 → aspect-ratio 충돌

각 레벨을 통과할 때마다 stretch는 자식의 cross-axis 크기를 컨테이너에 맞게 확장한다. 중첩이 깊을수록 최종 img에 전달되는 height가 예상 밖의 값이 될 가능성이 높다.

WebView Bridge 통신 Part 1

Sun, 12 Apr 2026 00:00:00 GMT

WebView Bridge 통신 — Part 1: 개요 및 이론

웹뷰에서 네이티브 앱과 어떻게 대화하는가 — 프로토콜, 패턴, Bridge Pattern까지

1. WebView란 무엇인가

WebView는 네이티브 앱(iOS/Android) 안에 웹 콘텐츠를 렌더링하는 내장 브라우저 컴포넌트다. 사용자 입장에서는 앱처럼 보이지만, 실제로는 HTML/CSS/JavaScript로 만들어진 웹 페이지가 네이티브 껍데기 안에서 동작하고 있다.

┌─────────────────────────────────┐
│        네이티브 앱 (iOS/Android) │
│  ┌───────────────────────────┐  │
│  │         WebView           │  │
│  │  ┌─────────────────────┐  │  │
│  │  │   HTML/CSS/JS (웹)  │  │  │
│  │  └─────────────────────┘  │  │
│  └───────────────────────────┘  │
└─────────────────────────────────┘

플랫폼별 WebView 구현체

플랫폼	컴포넌트	내부 엔진
iOS	`WKWebView`	WebKit (Safari 엔진)
Android	`WebView`	Chromium (Blink 엔진)
React Native	`<WebView>` 컴포넌트	플랫폼 네이티브 WebView 래핑

하이브리드 앱 아키텍처

WebView를 활용한 하이브리드 앱은 크게 두 가지 방식으로 나뉜다.

Full WebView: 앱 전체가 웹으로 구성. 네이티브는 껍데기 역할만 함
Partial WebView: 일부 화면(주문, 결제, 이벤트 등)만 웹으로 구성하고 나머지는 네이티브

후자가 실무에서 훨씬 흔하며, 이때 네이티브와 웹 간 통신이 반드시 필요해진다.

2. 왜 웹과 앱 간 통신이 필요한가

웹(WebView)과 네이티브 앱은 서로 다른 실행 환경에서 동작한다. 웹은 브라우저 샌드박스 안에 갇혀 있고, 네이티브 기능(카메라, 햅틱, 푸시 알림, 키체인 등)에 직접 접근할 수 없다.

통신이 필요한 대표적인 시나리오

웹 → 네이티브 방향 (명령)

시나리오	설명
네비게이션	웹 페이지에서 네이티브 뒤로가기 스택을 pop하거나 탭을 전환
햅틱 피드백	버튼 탭, 찜하기 등 사용자 인터랙션에 촉각 피드백 요청
카메라/갤러리	웹에서 사진 촬영 또는 앨범 접근 요청
생체 인증	Face ID / 지문 인증 요청
푸시 알림 권한	알림 권한 요청 다이얼로그 트리거
소셜 공유	네이티브 share sheet 호출
결제	네이티브 결제 SDK 호출 (인앱결제, 카카오페이 등)

네이티브 → 웹 방향 (데이터 전달)

시나리오	설명
인증 토큰	네이티브 키체인/키스토어에 저장된 JWT를 웹으로 전달
유저 정보	네이티브에서 관리하는 사용자 프로필 데이터 전달
딥링크	외부에서 들어온 딥링크 정보를 웹에 전달
기기 정보	OS 버전, 앱 버전, 디바이스 ID 등 전달
네트워크 상태	오프라인 전환 이벤트 등 전달

이처럼 웹이 단독으로 처리할 수 없는 영역이 명확히 존재하기 때문에, 웹뷰 환경에서 양방향 통신 채널 — 즉 Bridge — 이 필수적이다.

3. WebView 통신 프로토콜

플랫폼마다 웹과 네이티브가 통신하는 방식이 다르다.

3.1 iOS: WKWebView

iOS에서는 WKWebView와 WKScriptMessageHandler를 사용해 JavaScript ↔ Swift/Objective-C 통신을 구현한다.

웹 → 네이티브 (JavaScript → Swift)

// JavaScript (웹)
window.webkit.messageHandlers.bridge.postMessage({
  type: 'HAPTIC_SELECTION'
})

// Swift (네이티브)
class BridgeHandler: NSObject, WKScriptMessageHandler {
  func userContentController(
    _ userContentController: WKUserContentController,
    didReceive message: WKScriptMessage
  ) {
    guard let body = message.body as? [String: Any],
          let type = body["type"] as? String else { return }

    switch type {
    case "HAPTIC_SELECTION":
      let generator = UISelectionFeedbackGenerator()
      generator.selectionChanged()
    default: break
    }
  }
}

// WKWebView 설정
let config = WKWebViewConfiguration()
config.userContentController.add(bridgeHandler, name: "bridge")
let webView = WKWebView(frame: .zero, configuration: config)

네이티브 → 웹 (Swift → JavaScript)

// Swift: 웹의 전역 함수를 직접 호출
webView.evaluateJavaScript("window.bridgeCallback('\(jsonString)')")

// JavaScript (웹): 전역 함수로 수신
window.bridgeCallback = function(json) {
  const message = JSON.parse(json)
  // 메시지 처리
}

iOS의 특징: postMessage()에 JavaScript 객체를 그대로 전달할 수 있다. 내부적으로 직렬화가 처리된다.

3.2 Android: JavascriptInterface

Android에서는 @JavascriptInterface 어노테이션으로 Kotlin/Java 메서드를 JavaScript에 노출한다.

웹 → 네이티브 (JavaScript → Kotlin)

// JavaScript (웹) — Android는 문자열만 허용하므로 JSON 직렬화 필요
window.Android.postMessage(JSON.stringify({
  type: 'NAVIGATE_BACK'
}))

// Kotlin (네이티브)
class AndroidBridge(private val activity: Activity) {
  @JavascriptInterface
  fun postMessage(json: String) {
    val message = JSONObject(json)
    when (message.getString("type")) {
      "NAVIGATE_BACK" -> activity.onBackPressed()
    }
  }
}

// WebView 설정
webView.settings.javaScriptEnabled = true
webView.addJavascriptInterface(AndroidBridge(this), "Android")

네이티브 → 웹 (Kotlin → JavaScript)

webView.evaluateJavascript("window.bridgeCallback('$jsonString')", null)

Android의 특징: @JavascriptInterface 메서드는 문자열 인자만 받을 수 있다. 객체를 주고받으려면 반드시 JSON 직렬화/역직렬화가 필요하다.

3.3 React Native: WebView

React Native는 react-native-webview 라이브러리를 통해 웹과 통신한다.

웹 → 네이티브

// JavaScript (웹뷰 내부) — 문자열만 허용
window.ReactNativeWebView.postMessage(JSON.stringify({
  type: 'HAPTIC_IMPACT',
  payload: { style: 'medium' }
}))

// React Native
<WebView
  onMessage={(event) => {
    const message = JSON.parse(event.nativeEvent.data)
    if (message.type === 'HAPTIC_IMPACT') {
      Haptics.impactAsync(Haptics.ImpactFeedbackStyle.Medium)
    }
  }}
/>

네이티브 → 웹

// injectJavaScript로 JS 실행 (true 반환값 필요)
webViewRef.current.injectJavaScript(`
  window.bridgeCallback('${jsonString}'); true;
`)

플랫폼별 통신 방식 비교

구분	iOS (WKWebView)	Android (WebView)	React Native
웹 → 네이티브	`webkit.messageHandlers.{name}.postMessage(obj)`	`Android.{method}(str)`	`ReactNativeWebView.postMessage(str)`
네이티브 → 웹	`evaluateJavaScript(js)`	`evaluateJavascript(js, cb)`	`injectJavaScript(js)`
데이터 타입 (웹→네이티브)	객체 직접 전달 가능	문자열만	문자열만
전역 수신 창구	`window.bridgeCallback` (커스텀)	`window.bridgeCallback` (커스텀)	`window.bridgeCallback` (커스텀)

4. 자주 쓰이는 Bridge 통신 패턴

4.1 단방향 Fire-and-Forget

가장 단순한 패턴. 웹이 명령만 보내고 응답을 기다리지 않는다.

웹 ──[NAVIGATE_BACK]──→ 네이티브

window.webkit.messageHandlers.bridge.postMessage({ type: 'NAVIGATE_BACK' })

사용 사례: 네비게이션, 햅틱 피드백, 소셜 공유 트리거

4.2 Request-Response (요청-응답)

웹이 요청을 보내고, 네이티브가 처리 후 콜백으로 응답한다.

웹 ──[AUTH_TOKEN_REQUEST]──→ 네이티브
웹 ←──[AUTH_TOKEN_RECEIVE]── 네이티브

// 1. 수신 핸들러 등록
window.bridgeCallback = function(json) {
  const message = JSON.parse(json)
  if (message.type === 'AUTH_TOKEN_RECEIVE') {
    useToken(message.payload.token)
  }
}

// 2. 요청 전송
window.ReactNativeWebView.postMessage(JSON.stringify({
  type: 'AUTH_TOKEN_REQUEST'
}))

사용 사례: 인증 토큰 조회, 기기 정보 조회, 권한 상태 확인

4.3 Event-Driven (이벤트 기반)

네이티브가 웹의 요청 없이 이벤트를 push한다. 수신 핸들러만 미리 등록해두면 된다.

웹 ←──[AUTH_USER_RECEIVE]── 네이티브 (앱 초기화 시 자동 push)
웹 ←──[DEEP_LINK_RECEIVED]── 네이티브 (외부 딥링크 수신 시)

사용 사례: 딥링크 처리, 네트워크 상태 변화, 푸시 알림 수신

4.4 Promise-based Bridge

콜백 중첩을 피하기 위해 Bridge 호출을 Promise로 래핑한다.

function callBridge(requestType, responseType, timeout = 5000) {
  return new Promise((resolve, reject) => {
    const timer = setTimeout(() => reject(new Error('Bridge timeout')), timeout)

    window.bridgeCallback = (json) => {
      const message = JSON.parse(json)
      if (message.type === responseType) {
        clearTimeout(timer)
        resolve(message.payload)
      }
    }

    window.ReactNativeWebView.postMessage(JSON.stringify({ type: requestType }))
  })
}

// 사용
const { token } = await callBridge('AUTH_TOKEN_REQUEST', 'AUTH_TOKEN_RECEIVE')

장점: async/await 문법으로 가독성 향상
주의: 동시에 여러 요청이 발생하면 bridgeCallback 충돌 가능 → requestId 패턴으로 대응

4.5 Message Queue 패턴

WebView 로드 전에 도착하는 네이티브 메시지를 잃지 않기 위한 큐 패턴.

const messageQueue = []
let isReady = false

// 네이티브 메시지 수신 창구 (앱 초기화 즉시 설치)
window.bridgeCallback = function(json) {
  if (!isReady) {
    messageQueue.push(json)  // 준비 전 메시지는 큐에 보관
    return
  }
  processMessage(JSON.parse(json))
}

// 웹앱 초기화 완료 후 호출
function onAppReady() {
  isReady = true
  messageQueue.forEach(json => processMessage(JSON.parse(json)))  // 밀린 메시지 처리
  messageQueue.length = 0
}

사용 사례: 딥링크 처리, 앱 시작 시 유저 정보 push 등 타이밍 민감한 시나리오

5. Bridge Pattern (디자인 패턴)

GoF(Gang of Four)의 Bridge Pattern은 구조 패턴(Structural Pattern) 중 하나로, Abstraction(추상화) 과 Implementation(구현) 을 분리하여 둘 다 독립적으로 확장할 수 있게 한다.

"Decouple an abstraction from its implementation so that the two can vary independently." — GoF Design Patterns

5.1 핵심 구조

Abstraction
  └─ impl: Implementor  ← 합성(composition)으로 주입
        ├─ ConcreteImplementorA
        └─ ConcreteImplementorB

RefinedAbstraction extends Abstraction
  └─ 도메인 특화 메서드 추가

Abstraction: "무엇을 할지"를 정의. 실제 동작은 impl에 위임
Implementor: 구현체의 인터페이스(계약)
ConcreteImplementor: 실제 플랫폼/환경별 구현
RefinedAbstraction: Abstraction을 상속해 도메인 특화 메서드 추가

5.2 WebView Bridge에 Bridge Pattern이 적합한 이유

WebView 통신 구현의 핵심 문제는 환경 분기다.

"햅틱 피드백을 보내라"는 명령이 있을 때...
  → 실제 앱(RN):   window.ReactNativeWebView.postMessage(JSON)
  → 실제 앱(iOS):  window.webkit.messageHandlers.bridge.postMessage(obj)
  → 실제 앱(AOS):  window.Android.postMessage(JSON)
  → 브라우저(개발): console.log로 시뮬레이션

Bridge Pattern 없이 구현하면 환경 분기 코드가 기능 메서드마다 반복된다.

// ❌ Bridge Pattern 없이 — 조건 분기가 기능마다 중복
function goBack() {
  if (window.ReactNativeWebView) {
    window.ReactNativeWebView.postMessage(JSON.stringify({ type: 'NAVIGATE_BACK' }))
  } else if (window.webkit?.messageHandlers?.bridge) {
    window.webkit.messageHandlers.bridge.postMessage({ type: 'NAVIGATE_BACK' })
  } else if (window.Android) {
    window.Android.postMessage(JSON.stringify({ type: 'NAVIGATE_BACK' }))
  } else {
    console.log('[Dev] NAVIGATE_BACK')
  }
}

function hapticSelection() {
  // 위와 동일한 분기 코드가 또 반복...
}

Bridge Pattern을 적용하면 환경 분기 로직을 구현체 한 곳에 격리하고, 기능 메서드는 깔끔하게 유지된다.

// ✅ Bridge Pattern 적용 후
class HapticBridge extends BridgeAbstraction {
  selection(): void {
    this.send({ type: 'HAPTIC_SELECTION' })  // 플랫폼을 전혀 모름
  }
}

// 플랫폼 분기는 NativeBridge.send() 한 곳에만 존재
class NativeBridge implements IBridgeImpl {
  send(message): void {
    if (window.ReactNativeWebView) { ... }
    else if (window.webkit?.messageHandlers?.bridge) { ... }
    else if (window.Android) { ... }
  }
}

5.3 Bridge Pattern vs 유사 패턴 비교

패턴	목적	차이
Bridge	Abstraction과 Implementation을 독립적으로 확장	둘 다 계층 구조를 가질 수 있음
Adapter	호환되지 않는 인터페이스를 연결	기존 코드를 변경 없이 사용하기 위한 사후 적용
Strategy	알고리즘을 런타임에 교체	단일 레벨의 알고리즘 교체, Abstraction 계층 없음
Facade	복잡한 서브시스템에 단순한 인터페이스 제공	계층 분리가 목적이 아님

Part 2: 실전 구현 — Nuxt 3 프로젝트의 Bridge 아키텍처

참고 자료

iOS / Apple 공식 문서

WKScriptMessageHandler — JavaScript 메시지를 수신하는 핸들러 프로토콜. userContentController(_:didReceive:) 메서드 명세
https://developer.apple.com/documentation/webkit/wkscriptmessagehandler
WKUserContentController.add(_:name:) — window.webkit.messageHandlers.{name}.postMessage() JavaScript 함수를 앱에 등록하는 메서드
https://developer.apple.com/documentation/webkit/wkusercontentcontroller/add(_:name:)
WKWebView.evaluateJavaScript(_:completionHandler:) — Swift에서 JavaScript 문자열을 실행하는 메서드. 네이티브 → 웹 방향 통신에 사용
https://developer.apple.com/documentation/webkit/wkwebview/evaluatejavascript(_:completionhandler:)

Android 공식 문서

WebView — Android Developer Guide — addJavascriptInterface, evaluateJavascript, settings.javaScriptEnabled 등 Android WebView 전반 가이드
https://developer.android.com/develop/ui/views/layout/webapps/webview
@JavascriptInterface annotation — JavaScript에 노출할 Kotlin/Java 메서드를 지정하는 어노테이션 명세
https://developer.android.com/reference/android/webkit/JavascriptInterface

React Native WebView

React Native WebView 통신 가이드 — window.ReactNativeWebView.postMessage, onMessage prop, injectedJavaScript, injectJavaScript 양방향 통신 상세 설명
https://github.com/react-native-webview/react-native-webview/blob/master/docs/Guide.md

Bridge Pattern (GoF)

Bridge Pattern 개요 — Abstraction과 Implementation 분리 원칙, 적용 맥락, 유사 패턴(Adapter, Strategy, Facade)과의 비교
https://refactoring.guru/design-patterns/bridge
Bridge Pattern TypeScript 예제 — Abstraction, ExtendedAbstraction, Implementation, ConcreteImplementationA/B 구조의 전체 코드
https://refactoring.guru/design-patterns/bridge/typescript/example

WebView Bridge 통신 Part 2

Sun, 12 Apr 2026 00:00:00 GMT

WebView Bridge 통신 - Part 2: 실전 구현

webview-study 프로젝트의 Bridge 아키텍처 — 설계 결정부터 컴포넌트 연동까지 Part 1: 개요 및 이론

1. 전체 아키텍처 개요

레이어 구조

Vue 컴포넌트 / 미들웨어
  └─ composable (useBridge)
       └─ Feature Bridge — Refined Abstraction
            ├─ NavigationBridge  goBack() / switchTab()
            ├─ HapticBridge      impact() / selection() / notification()
            └─ AuthBridge        requestToken() / onTokenReceived()
                  │
                  └─ BridgeAbstraction — Abstraction 베이스
                        └─ impl: IBridgeImpl
                              ├─ NativeBridge  (RN / iOS / Android)
                              └─ MockBridge    (브라우저 개발 환경)

디렉토리 구조

bridge/
  core/
    IBridgeImpl.ts          # Implementation 인터페이스 (계약)
    BridgeAbstraction.ts    # Abstraction 베이스 클래스
  features/
    NavigationBridge.ts     # Refined Abstraction: 네비게이션
    HapticBridge.ts         # Refined Abstraction: 햅틱
    AuthBridge.ts           # Refined Abstraction: 인증
  impl/
    NativeBridge.ts         # Concrete Implementation: 실제 네이티브
    MockBridge.ts           # Concrete Implementation: 브라우저 시뮬레이터
  index.ts                  # 환경 감지 + 싱글턴 export

types/
  bridge.ts                 # 메시지 타입 중앙 관리

composables/
  useBridge.ts              # Vue 컴포넌트용 composable

plugins/
  bridge.client.ts          # Nuxt client-only 플러그인 (SSR 격리)

설계 원칙

원칙	적용 방식
환경 분기 격리	플랫폼별 `postMessage` 로직은 `NativeBridge.send()` 한 곳에만 존재
메시지 타입 중앙 관리	`types/bridge.ts`가 웹·네이티브 양쪽의 프로토콜 계약
개발 환경 독립	`MockBridge`로 네이티브 앱 없이 전체 기능 개발·테스트 가능
SSR 안전	`bridge.client.ts` 플러그인으로 `window` 접근을 클라이언트 전용으로 격리
싱글턴 공유	모듈 레벨 싱글턴으로 앱 전체에서 동일 인스턴스 + 핸들러 상태 유지

2. 메시지 타입 설계

types/bridge.ts는 웹과 네이티브가 주고받는 모든 메시지의 형식을 정의한다. 이 파일 하나가 양쪽의 통신 프로토콜 계약이 된다.

2.1 메시지 식별자

// enum 대신 const object + as const 사용
// 이유: enum은 런타임에 실제 객체를 생성하지만, const object는 트리셰이킹에 유리
export const BridgeMessageType = {
  NAVIGATE_BACK: 'NAVIGATE_BACK',
  NAVIGATE_TAB: 'NAVIGATE_TAB',
  HAPTIC_IMPACT: 'HAPTIC_IMPACT',
  HAPTIC_SELECTION: 'HAPTIC_SELECTION',
  HAPTIC_NOTIFICATION: 'HAPTIC_NOTIFICATION',
  AUTH_TOKEN_REQUEST: 'AUTH_TOKEN_REQUEST',
  AUTH_TOKEN_RECEIVE: 'AUTH_TOKEN_RECEIVE',
  AUTH_USER_RECEIVE: 'AUTH_USER_RECEIVE',
} as const

// `typeof X[keyof typeof X]` 패턴으로 value union type 추출
export type BridgeMessageTypeValue = (typeof BridgeMessageType)[keyof typeof BridgeMessageType]
// → 'NAVIGATE_BACK' | 'NAVIGATE_TAB' | 'HAPTIC_IMPACT' | ...

2.2 메시지 방향 분리

// 웹 → 네이티브 (Outbound)
export type OutboundBridgeMessage =
  | NavigateBackMessage
  | NavigateTabMessage
  | HapticImpactMessage
  | HapticSelectionMessage
  | HapticNotificationMessage
  | AuthTokenRequestMessage

// 네이티브 → 웹 (Inbound)
export type InboundBridgeMessage =
  | AuthTokenReceiveMessage
  | AuthUserReceiveMessage

// 전체 (방향 무관)
export type BridgeMessage = OutboundBridgeMessage | InboundBridgeMessage

방향을 타입으로 분리하면 잘못된 방향으로 메시지를 보내는 실수를 컴파일 타임에 방지할 수 있다.

2.3 개별 메시지 타입

// 네비게이션
export type TabName = 'home' | 'products' | 'wishlist' | 'mypage'

export interface NavigateTabMessage {
  type: typeof BridgeMessageType.NAVIGATE_TAB
  payload: { tab: TabName }
}

// 햅틱 — iOS UIFeedbackGenerator 스펙 기준
export type HapticStyle = 'light' | 'medium' | 'heavy'
export type HapticNotificationType = 'success' | 'warning' | 'error'

export interface HapticImpactMessage {
  type: typeof BridgeMessageType.HAPTIC_IMPACT
  payload: { style: HapticStyle }
}

export interface HapticNotificationMessage {
  type: typeof BridgeMessageType.HAPTIC_NOTIFICATION
  payload: { notificationType: HapticNotificationType }
}

// 인증
export interface AuthTokenReceiveMessage {
  type: typeof BridgeMessageType.AUTH_TOKEN_RECEIVE
  payload: {
    token: string
    expiresAt: number  // Unix timestamp (ms)
  }
}

export interface AuthUser {
  id: string
  email: string
  name: string
  avatarUrl?: string
}

2.4 공통 응답 타입 + 핸들러 타입

// 네이티브가 처리 결과를 돌려줄 때의 공통 형식
export interface BridgeResponse<T = unknown> {
  success: boolean
  data?: T
  error?: string
}

// receive()에 등록하는 콜백 타입
export type BridgeMessageHandler<T extends BridgeMessage = BridgeMessage> = (
  message: T,
) => void

3. Core 레이어

3.1 IBridgeImpl — Implementation 인터페이스

모든 구현체가 반드시 따라야 하는 계약. BridgeAbstraction은 이 인터페이스에만 의존하기 때문에, 구현체가 바뀌어도 Abstraction 코드는 전혀 수정할 필요가 없다.

// bridge/core/IBridgeImpl.ts
export interface IBridgeImpl {
  /** 웹 → 네이티브 방향 메시지 전송 */
  send(message: BridgeMessage): void

  /** 네이티브 → 웹 방향 메시지 수신 핸들러 등록 */
  receive(type: BridgeMessageTypeValue, handler: BridgeMessageHandler): void

  /** 현재 환경에서 이 구현체를 사용할 수 있는지 여부 */
  isAvailable(): boolean
}

세 메서드만으로 Bridge의 전체 통신 계약이 완성된다.

3.2 BridgeAbstraction — Abstraction 베이스

Feature Bridge들의 공통 베이스 클래스. "무엇을 할지"만 정의하고 "어떻게 할지"는 impl에 위임한다.

// bridge/core/BridgeAbstraction.ts
export abstract class BridgeAbstraction {
  // protected: 자식 클래스(Feature Bridge)에서만 접근 가능, 외부에서 직접 사용 불가
  protected readonly impl: IBridgeImpl

  constructor(impl: IBridgeImpl) {
    this.impl = impl
  }

  protected send(message: BridgeMessage): void {
    this.impl.send(message)
  }

  protected receive(type: BridgeMessageTypeValue, handler: BridgeMessageHandler): void {
    this.impl.receive(type, handler)
  }

  isAvailable(): boolean {
    return this.impl.isAvailable()
  }
}

send()와 receive()가 protected인 이유: Feature Bridge의 도메인 메서드(goBack(), selection() 등)를 통해서만 통신하도록 강제하기 위함이다. 외부에서 raw 메시지를 직접 보내는 것을 막는다.

4. Implementation 레이어

4.1 NativeBridge — 실제 네이티브 구현체

플랫폼별 분기 로직이 여기에 집중된다. Feature Bridge는 이 내부를 전혀 알 필요가 없다.

// bridge/impl/NativeBridge.ts
export class NativeBridge implements IBridgeImpl {
  private readonly handlers = new Map<BridgeMessageTypeValue, BridgeMessageHandler[]>()

  isAvailable(): boolean {
    return (
      !!window.ReactNativeWebView ||
      !!window.webkit?.messageHandlers?.bridge ||
      !!window.Android
    )
  }

  send(message: BridgeMessage): void {
    // 우선순위 체인: 처음 감지된 채널만 사용
    if (window.ReactNativeWebView) {
      // React Native: 문자열만 허용 → JSON 직렬화
      window.ReactNativeWebView.postMessage(JSON.stringify(message))
      return
    }
    if (window.webkit?.messageHandlers?.bridge) {
      // iOS WKWebView: 객체를 그대로 전달 가능
      window.webkit.messageHandlers.bridge.postMessage(message)
      return
    }
    if (window.Android) {
      // Android JavascriptInterface: 문자열만 허용 → JSON 직렬화
      window.Android.postMessage(JSON.stringify(message))
    }
  }

  receive(type: BridgeMessageTypeValue, handler: BridgeMessageHandler): void {
    const existing = this.handlers.get(type) ?? []
    this.handlers.set(type, [...existing, handler])

    // window.bridgeCallback을 전역 수신 창구로 설치 (중복 설치 방지)
    // 네이티브 앱은 `window.bridgeCallback(JSON.stringify(message))` 형태로 호출
    if (!window.bridgeCallback) {
      window.bridgeCallback = (json: string) => this.dispatch(json)
    }
  }

  private dispatch(json: string): void {
    let message: BridgeMessage
    try {
      message = JSON.parse(json) as BridgeMessage
    } catch {
      console.error('[NativeBridge] 메시지 파싱 실패:', json)
      return
    }
    const handlers = this.handlers.get(message.type) ?? []
    handlers.forEach((handler) => handler(message))
  }
}

포인트: send()의 우선순위 체인 덕분에 하나의 구현체가 RN / iOS / Android 세 환경을 모두 처리한다.

4.2 MockBridge — 개발/테스트용 시뮬레이터

네이티브 앱 없이 브라우저에서도 Bridge 동작을 확인할 수 있다. send()는 console.log로 출력하고, emit()으로 네이티브 응답을 시뮬레이션한다.

// bridge/impl/MockBridge.ts
export class MockBridge implements IBridgeImpl {
  private readonly handlers = new Map<BridgeMessageTypeValue, BridgeMessageHandler[]>()

  isAvailable(): boolean {
    return true  // 개발 fallback이므로 항상 사용 가능
  }

  send(message: BridgeMessage): void {
    // DevTools 콘솔에서 [MockBridge] 접두어로 확인
    console.log(`[MockBridge] → send:`, message.type, message)
  }

  receive(type: BridgeMessageTypeValue, handler: BridgeMessageHandler): void {
    const existing = this.handlers.get(type) ?? []
    this.handlers.set(type, [...existing, handler])
  }

  // 개발/테스트 전용: 네이티브 응답을 시뮬레이션
  // NativeBridge에서는 window.bridgeCallback이 이 역할을 담당
  emit(message: BridgeMessage): void {
    const handlers = this.handlers.get(message.type) ?? []
    handlers.forEach((handler) => handler(message))
  }
}

브라우저 DevTools 콘솔에서 직접 emit()을 호출해 토큰 수신 등을 테스트할 수 있다:

// DevTools 콘솔에서
import { authBridge } from '/bridge/index.ts'
authBridge.impl.emit({
  type: 'AUTH_TOKEN_RECEIVE',
  payload: { token: 'test-token', expiresAt: Date.now() + 3600000 }
})

5. Feature Bridge 레이어

5.1 NavigationBridge

// bridge/features/NavigationBridge.ts
export class NavigationBridge extends BridgeAbstraction {
  /** 네이티브 앱의 navigation stack을 pop한다 (웹의 history.back()과 다름) */
  goBack(): void {
    this.send({ type: BridgeMessageType.NAVIGATE_BACK })
  }

  /** 네이티브 BottomTabBar의 탭을 전환한다 */
  switchTab(tab: TabName): void {
    this.send({ type: BridgeMessageType.NAVIGATE_TAB, payload: { tab } })
  }
}

5.2 HapticBridge

iOS UIFeedbackGenerator의 세 가지 피드백 타입에 대응한다.

// bridge/features/HapticBridge.ts
export class HapticBridge extends BridgeAbstraction {
  /** 충격 피드백 — 버튼 탭, 스와이프 등 물리적 인터랙션 */
  impact(style: HapticStyle): void {
    this.send({ type: BridgeMessageType.HAPTIC_IMPACT, payload: { style } })
  }

  /** 선택 피드백 — 찜하기, 체크박스 토글 등 항목 선택 */
  selection(): void {
    this.send({ type: BridgeMessageType.HAPTIC_SELECTION })
  }

  /** 알림 피드백 — 작업 성공/실패/경고 결과를 촉각으로 전달 */
  notification(notificationType: HapticNotificationType): void {
    this.send({ type: BridgeMessageType.HAPTIC_NOTIFICATION, payload: { notificationType } })
  }
}

5.3 AuthBridge

웹뷰는 네이티브 키체인/키스토어에 직접 접근할 수 없다. Bridge를 통해 토큰을 요청하고 응답을 핸들러로 받는다.

// bridge/features/AuthBridge.ts
export class AuthBridge extends BridgeAbstraction {
  /** 네이티브 앱에 JWT 토큰을 요청한다 */
  requestToken(): void {
    this.send({ type: BridgeMessageType.AUTH_TOKEN_REQUEST })
  }

  /** 토큰 수신 핸들러 등록 */
  onTokenReceived(handler: (token: string) => void): void {
    // payload 추출 래핑 패턴:
    // 메시지 전체 객체가 아닌 token만 추출하여 호출자에게 전달
    // → 호출자가 Bridge 내부 메시지 구조를 알 필요가 없음
    this.receive(BridgeMessageType.AUTH_TOKEN_RECEIVE, (message) => {
      const { payload } = message as AuthTokenReceiveMessage
      handler(payload.token)
    })
  }

  /** 유저 정보 수신 핸들러 등록 */
  onUserReceived(handler: (user: AuthUser) => void): void {
    this.receive(BridgeMessageType.AUTH_USER_RECEIVE, (message) => {
      const { payload } = message as AuthUserReceiveMessage
      handler(payload.user)
    })
  }
}

payload 추출 래핑 패턴: receive()에 등록하는 내부 콜백에서 필요한 데이터만 추출해서 외부 핸들러를 호출한다. 덕분에 컴포넌트는 BridgeMessage 구조를 몰라도 된다.

6. 환경 감지와 싱글턴

6.1 환경 감지

// bridge/index.ts
export type BridgeEnvironment = 'react-native' | 'ios' | 'android' | 'mock'

export function detectEnvironment(): BridgeEnvironment {
  if (typeof window === 'undefined') return 'mock'  // SSR 안전장치
  if (window.ReactNativeWebView) return 'react-native'
  if (window.webkit?.messageHandlers?.bridge) return 'ios'
  if (window.Android) return 'android'
  return 'mock'  // 브라우저/개발 환경 fallback
}

우선순위 체인:

1. window.ReactNativeWebView  →  'react-native'
2. window.webkit.messageHandlers.bridge  →  'ios'
3. window.Android  →  'android'
4. (없으면)  →  'mock'

6.2 팩토리 함수 + 싱글턴

// 팩토리: 환경에 따라 구현체 결정
export function createBridgeImpl(env?: BridgeEnvironment): IBridgeImpl {
  const resolvedEnv = env ?? detectEnvironment()
  // RN / iOS / Android 세 환경은 모두 NativeBridge로 통합
  // 각 채널의 차이는 NativeBridge.send() 내부에서 처리
  if (resolvedEnv === 'mock') return new MockBridge()
  return new NativeBridge()
}

// 모듈 레벨 싱글턴 — 앱 전체에서 동일 인스턴스 + 핸들러 상태 공유
const impl = createBridgeImpl()

export const navigationBridge = new NavigationBridge(impl)
export const hapticBridge = new HapticBridge(impl)
export const authBridge = new AuthBridge(impl)

싱글턴으로 관리하는 이유:

핸들러 등록 상태를 앱 전체에서 일관되게 유지
불필요한 객체 생성 방지
onTokenReceived() 등 이벤트 기반 핸들러가 의도치 않게 중복 등록되는 것을 막음

7. Nuxt 통합: Plugin + Composable

7.1 Client-Only Plugin

// plugins/bridge.client.ts

// .client.ts 접미사 → Nuxt가 서버에서 이 파일을 실행하지 않음
// window, ReactNativeWebView 등에 안전하게 접근 가능
import { navigationBridge, hapticBridge, authBridge } from '@/bridge'

export default defineNuxtPlugin((nuxtApp) => {
  // provide('bridge', value) → 앱 전체에서 nuxtApp.$bridge로 접근 가능
  nuxtApp.provide('bridge', {
    navigation: navigationBridge,
    haptic: hapticBridge,
    auth: authBridge,
  })
})

7.2 Composable

Plugin의 $bridge를 사용할 수도 있지만, 더 직관적인 composable을 제공한다.

// composables/useBridge.ts
import { navigationBridge, hapticBridge, authBridge } from '@/bridge'
import type { NavigationBridge } from '@/bridge/features/NavigationBridge'
import type { HapticBridge } from '@/bridge/features/HapticBridge'
import type { AuthBridge } from '@/bridge/features/AuthBridge'

export function useNavigationBridge(): NavigationBridge {
  return navigationBridge
}

export function useHapticBridge(): HapticBridge {
  return hapticBridge
}

export function useAuthBridge(): AuthBridge {
  return authBridge
}

composable이 싱글턴을 그대로 반환하는 이유: Bridge는 Vue 반응형 상태가 아니라 통신 채널이기 때문에 ref로 감쌀 필요가 없다.

8. 컴포넌트 연동 예시

8.1 HapticBridge — 찜하기 버튼

<!-- components/ProductCard.vue -->
<script setup lang="ts">
import { useHapticBridge } from '@/composables/useBridge'

const hapticBridge = useHapticBridge()
const isWishlisted = ref(false)

function handleWishlist() {
  isWishlisted.value = !isWishlisted.value
  hapticBridge.selection()  // 찜하기 토글 시 선택 피드백
}
</script>

<template>
  <button
    :aria-pressed="String(isWishlisted)"
    @click.prevent="handleWishlist"
  >
    {{ isWishlisted ? '찜 해제' : '찜하기' }}
  </button>
</template>

8.2 NavigationBridge — 뒤로가기 (폴백 포함)

<!-- components/AppHeader.vue -->
<script setup lang="ts">
import { useNavigationBridge } from '@/composables/useBridge'

const router = useRouter()
const navigationBridge = useNavigationBridge()

function handleBack() {
  if (navigationBridge.isAvailable()) {
    // 네이티브 환경: 네이티브 navigation stack pop
    navigationBridge.goBack()
  } else {
    // 브라우저 환경: 웹 히스토리 back 폴백
    router.back()
  }
}
</script>

isAvailable() 체크 후 폴백을 두는 패턴은 웹뷰와 브라우저 모두에서 동일한 컴포넌트를 사용할 수 있게 해준다.

8.3 AuthBridge — 토큰 요청 + 수신

// middleware/auth.ts (개념 코드)
import { authBridge } from '@/bridge'

export default defineNuxtRouteMiddleware(() => {
  // 1. 수신 핸들러 먼저 등록
  authBridge.onTokenReceived((token) => {
    // 토큰을 받으면 Pinia store나 cookie에 저장
    useAuthStore().setToken(token)
  })

  // 2. 토큰 요청 전송
  authBridge.requestToken()
})

onTokenReceived() → requestToken() 순서가 중요하다. 핸들러를 먼저 등록하지 않으면 토큰이 도착했을 때 받을 수단이 없다.

9. SSR 환경 격리 전략

Nuxt 3은 기본적으로 SSR을 사용한다. 서버에는 window가 없으므로 Bridge 코드를 서버에서 실행하면 오류가 발생한다.

위험 상황

// ❌ 서버에서 import하면 즉시 오류
import { navigationBridge } from '@/bridge'  // window 접근 발생

대응 방법

1. .client.ts 플러그인으로 격리

plugins/
  bridge.client.ts  ← 서버에서 절대 실행되지 않음

Bridge 싱글턴은 이 플러그인이 import할 때 초기화된다. 서버는 이 파일을 실행하지 않으므로 window 접근이 발생하지 않는다.

2. detectEnvironment()의 안전장치

export function detectEnvironment(): BridgeEnvironment {
  if (typeof window === 'undefined') return 'mock'  // SSR → 즉시 mock 반환
  // ...
}

3. 컴포넌트에서 직접 import할 때

// ✅ onMounted 또는 import.meta.client 가드 사용
onMounted(() => {
  const { authBridge } = await import('@/bridge')
  authBridge.requestToken()
})

위험 수준별 정리

상황	위험 수준	대응
SSR에서 `window` 접근	HIGH	`.client.ts` 플러그인으로 격리
`window` 타입 미정의	LOW	`types/global.d.ts`에 Window 인터페이스 확장
AuthBridge 핸들러 타이밍	MEDIUM	핸들러 먼저 등록, 요청은 나중에
네이티브 앱 없는 테스트	MEDIUM	MockBridge + `emit()`으로 시뮬레이션

10. 전체 흐름 다이어그램

웹 → 네이티브 (찜하기 햅틱 피드백)

[사용자 찜하기 클릭]
        │
        ▼
ProductCard.vue — handleWishlist()
  hapticBridge.selection()
        │
        ▼
HapticBridge.selection()         Refined Abstraction
  this.send({ type: 'HAPTIC_SELECTION' })
        │
        ▼
BridgeAbstraction.send()         Abstraction
  this.impl.send(message)
        │
        ├── [네이티브 환경] ──▶ NativeBridge.send()
        │                         ├─ RN:  ReactNativeWebView.postMessage(JSON)
        │                         ├─ iOS: webkit.messageHandlers.bridge.postMessage(obj)
        │                         └─ AOS: Android.postMessage(JSON)
        │
        └── [브라우저 환경] ──▶ MockBridge.send()
                                  console.log('[MockBridge] → send: HAPTIC_SELECTION')

네이티브 → 웹 (인증 토큰 수신)

[네이티브 앱이 토큰 전송]
        │
        ▼
window.bridgeCallback('{"type":"AUTH_TOKEN_RECEIVE","payload":{"token":"..."}}')
        │
        ▼
NativeBridge.dispatch(json)
  JSON.parse(json) → message
  handlers.get('AUTH_TOKEN_RECEIVE') → [wrappedHandler]
  wrappedHandler(message)
        │
        ▼
AuthBridge.onTokenReceived 내부 래퍼
  const { payload } = message as AuthTokenReceiveMessage
  handler(payload.token)           payload에서 token만 추출
        │
        ▼
컴포넌트/미들웨어의 콜백
  (token: string) => { ... }       깔끔한 인터페이스로 수신

레이어별 책임 요약

┌────────────────────────────────────────────────────────────┐
│               Vue 컴포넌트 / Nuxt 미들웨어                  │
│  hapticBridge.selection()  |  authBridge.requestToken()    │
└──────────────────────────┬─────────────────────────────────┘
                           │ composable (useBridge)
┌──────────────────────────▼─────────────────────────────────┐
│              Feature Bridge  (Refined Abstraction)          │
│    NavigationBridge | HapticBridge | AuthBridge            │
│    도메인 특화 메서드, send()/receive() 호출                 │
└──────────────────────────┬─────────────────────────────────┘
                           │ extends
┌──────────────────────────▼─────────────────────────────────┐
│              BridgeAbstraction  (Abstraction)               │
│    impl.send() / impl.receive() 위임                        │
└──────────────────────────┬─────────────────────────────────┘
                           │ IBridgeImpl (의존성 주입)
┌─────────────────┬────────▼────────────────────────────────┐
│   NativeBridge  │              MockBridge                  │
│  (실제 네이티브) │           (브라우저/테스트)               │
│  RN/iOS/Android │        console.log + emit()             │
│  postMessage    │                                         │
└─────────────────┴─────────────────────────────────────────┘

마치며

이 프로젝트에서 WebView Bridge를 구현하며 배운 핵심:

타입이 프로토콜이다 — types/bridge.ts의 메시지 타입이 웹-네이티브 계약이 된다. 타입이 맞지 않으면 컴파일 단계에서 잡힌다.
환경 분기는 한 곳에 — NativeBridge.send() 밖에서는 플랫폼 분기가 없다. Feature Bridge는 iOS인지 Android인지 전혀 모른다.
개발 환경을 먼저 설계하라 — MockBridge와 emit()이 없었다면 네이티브 앱 없이 Bridge 관련 기능을 개발하거나 테스트하는 것이 불가능했을 것이다.
SSR은 항상 고려대상으로 두어야 한다 — window에 접근하는 코드는 반드시 .client.ts로 격리하거나 typeof window === 'undefined' 가드를 달아야 한다.
Bridge Pattern의 진짜 가치 — Feature Bridge가 플랫폼을 몰라도 된다는 것은 단순한 코드 정리가 아니다. 나중에 새 플랫폼(예: 데스크톱 WebView)이 추가되거나, MockBridge를 테스트용 Spy로 교체할 때 Feature Bridge 코드는 손댈 필요가 없다.

Part 1로 돌아가기: 개요 및 이론 — WebView란, 프로토콜, 통신 패턴, Bridge Pattern

참고 자료

프로젝트 소스 파일

이 문서의 모든 코드 예시는 아래 실제 구현 파일에서 발췌했다.

파일	역할
`bridge_plan.md`	전체 구현 계획, MVP 체크리스트, Phase별 설계 결정 사항
`types/bridge.ts`	`BridgeMessageType`, `BridgeMessage` union, `BridgeResponse`, `BridgeMessageHandler` 타입 정의
`bridge/core/IBridgeImpl.ts`	`send()` / `receive()` / `isAvailable()` 3개 메서드로 구성된 Implementation 인터페이스
`bridge/core/BridgeAbstraction.ts`	`protected send()` / `receive()` 위임 메서드를 갖는 abstract Abstraction 베이스 클래스
`bridge/impl/NativeBridge.ts`	ReactNativeWebView → webkit → Android 우선순위 체인, `window.bridgeCallback` 전역 수신 창구
`bridge/impl/MockBridge.ts`	`Map` 기반 이벤트 에미터, `emit()` 네이티브 시뮬레이션 메서드
`bridge/features/NavigationBridge.ts`	`goBack()`, `switchTab()` Refined Abstraction
`bridge/features/HapticBridge.ts`	`impact()`, `selection()`, `notification()` Refined Abstraction
`bridge/features/AuthBridge.ts`	`requestToken()`, `onTokenReceived()` payload 추출 래핑 패턴
`bridge/index.ts`	`detectEnvironment()`, `createBridgeImpl()` 팩토리, 모듈 레벨 싱글턴 export
`plugins/bridge.client.ts`	Nuxt client-only 플러그인 — `defineNuxtPlugin` + `nuxtApp.provide()`
`composables/useBridge.ts`	`useNavigationBridge()`, `useHapticBridge()`, `useAuthBridge()` composable

Nuxt 3 공식 문서

Nuxt 3 Plugins — defineNuxtPlugin, .client.ts 네이밍 컨벤션, nuxtApp.provide() 사용법. bridge.client.ts 구현의 직접 근거
https://nuxt.com/docs/guide/directory-structure/plugins
Nuxt 3 Composables — useNuxtApp()을 통한 plugin injection 접근 패턴. useBridge.ts composable 설계 근거
https://nuxt.com/docs/guide/directory-structure/composables
Nuxt App 인스턴스 — runtime nuxt app instance 접근 방법, $injected 프로퍼티 네이밍 규칙
https://nuxt.com/docs/guide/going-further/nuxt-app

iOS Haptics — Apple 공식 문서

HapticStyle (light / medium / heavy) 과 HapticNotificationType (success / warning / error) 타입이 아래 iOS 스펙을 기준으로 설계됐다.

UIImpactFeedbackGenerator — light / medium / heavy 강도 충격 피드백. HapticBridge.impact(style:) 의 근거
https://developer.apple.com/documentation/uikit/uiimpactfeedbackgenerator
UISelectionFeedbackGenerator — 항목 선택 시 피드백. HapticBridge.selection() 의 근거
https://developer.apple.com/documentation/uikit/uiselectionfeedbackgenerator
UINotificationFeedbackGenerator — success / warning / error 알림 피드백. HapticBridge.notification(type:) 의 근거
https://developer.apple.com/documentation/uikit/uinotificationfeedbackgenerator

📘 AWS DB 백서 (Whitepaper Summary)

Fri, 27 Mar 2026 00:00:00 GMT

📘 AWS DB 백서 (Whitepaper Summary)

출처: Building Modern Applications Using AWS Databases (AWS 공식 백서, 2024) 목적: SAA-C03 시험 대비 핵심 개념 정리 최종 업데이트: 2025

1. Purpose-Built Database 선택 전략

핵심 원칙

단일 관계형 DB로는 현대 애플리케이션의 모든 요구사항을 충족할 수 없다.

소셜, IoT, 모바일, 글로벌 서비스는 각기 다른 데이터 모델이 필요
마이크로서비스 아키텍처에서 각 팀은 워크로드에 최적화된 DB를 독립적으로 선택해야 함
AWS는 15종 이상의 Purpose-built DB 제공

AWS DB 포트폴리오

유형	서비스
Relational	Amazon Aurora, Amazon RDS
Key-Value	Amazon DynamoDB
Document	Amazon DocumentDB
In-Memory	Amazon ElastiCache, Amazon MemoryDB
Graph	Amazon Neptune
Wide-Column	Amazon Keyspaces
Time-Series	Amazon Timestream
Search	Amazon OpenSearch Service

🛒 E-Commerce 아키텍처 예시 (시험 단골 출제)

기능	선택 DB	이유
상품 검색	Amazon OpenSearch	인덱스 최적화 검색
장바구니 / 결제	Amazon Aurora	트랜잭션 무결성 필요
고객 리뷰 (별점)	Amazon DynamoDB	단순 Key-Value 구조
상품 추천	Amazon Neptune	그래프 기반 관계 탐색

Managed vs Self-Managed

AWS 완전 관리형이 처리하는 것:

프로비저닝, HA 구성, 자동 패치/업그레이드
자동 백업, 장애조치(Failover)
Self-healing 스토리지, 자동 스케일링

개발자/DBA가 집중할 수 있는 것:

스키마 설계, 쿼리 최적화, 접근 제어, 신규 기능 개발

:::tip "관리 부담 최소화", "운영 오버헤드 감소" → 완전 관리형(Managed) 서비스 선택이 정답 패턴 :::

2. 스케일링 전략

2-1. Serverless 자동 스케일링

구현 방식	지원 서비스
Vertical Auto Scaling	Aurora, Neptune, Timestream for LiveAnalytics
완전 서버리스 (compute + storage 모두 자동)	Aurora DSQL, DynamoDB, ElastiCache, Keyspaces

:::tip 피크 기준 프로비저닝 대비 최대 90% 비용 절감, 사용량 기반 과금 → "가변 트래픽 + 비용 최적화 + 관리 Zero" = Serverless 계열 :::

2-2. Vertical vs Horizontal Scaling

Vertical Scaling   → 인스턴스 크기 증가 (CPU / RAM / Network)
                     운영 중단 없이 실시간 동적 조정 가능

Horizontal Scaling → 노드 추가로 분산 처리
                     방법: 읽기 레플리카 추가 / 파티셔닝 / 샤딩

:::tip

읽기 성능 개선 → Read Replica 추가 (Horizontal)
단일 인스턴스 성능 향상 → Vertical Scaling :::

2-3. Data Partitioning

테이블을 컬럼 값 기준으로 서브셋(파티션) 으로 분할
파티션 방식: Range / List / Hash
샤딩과의 차이: 파티션은 같은 DB 인스턴스 내 분할 (다른 노드 불필요)
앱에 투명하게(Transparent) 동작 — 코드 변경 없음
Aurora DSQL이 자동 지원

:::tip 파티셔닝 ≠ 샤딩. 파티셔닝은 단일 인스턴스 내 분할 :::

2-4. Sharding (Aurora PostgreSQL Limitless)

데이터를 여러 독립 노드에 분산 (Shared-Nothing 아키텍처)
각 샤드는 독립적인 데이터 서브셋 처리
Aurora PostgreSQL Limitless Database:
- 완전 관리형 샤딩 — 수동 라우팅 로직 불필요
- 초당 수백만 트랜잭션 커밋 지원
- 페타바이트급 확장
- 샤드 추가/제거 시 자동 리밸런싱

:::tip 초대규모 OLTP 쓰기 확장 → Aurora PostgreSQL Limitless 직접 샤딩 구현 없이 AWS가 라우팅 관리 = "개발 오버헤드 최소화" :::

3. In-Memory: ElastiCache vs MemoryDB

비교표

항목	ElastiCache	MemoryDB
분류	캐시 (Non-durable)	완전 내구성 In-Memory DB
엔진	Valkey, Memcached, Redis OSS	Valkey, Redis OSS
읽기 레이턴시	마이크로초	마이크로초
쓰기 레이턴시	마이크로초	수 밀리초 (Multi-AZ 동기 쓰기)
데이터 내구성	소량 손실 가능	Zero 손실
HA	99.99%	99.999%
멀티리전	-	Active-Active 지원

ElastiCache 상세

단일 노드: 초당 100만 req 처리
클러스터: 초당 5억 req 처리
Primary 장애 시 복제본 자동 승격 → 미복제 데이터만 손실
Valkey = Redis OSS 대체 (Redis가 2024년 3월 BSD 3-Clause 라이선스 변경 후 Linux Foundation 주관)

MemoryDB 상세

쓰기 시 Multi-AZ 트랜잭션 로그에 동기 기록 후 응답
읽기는 마이크로초 유지
가용성 99.999%

선택 기준

데이터 손실 허용 가능 + 원본 DB 별도 존재 → ElastiCache (캐시 레이어)
데이터 손실 절대 불허 + DB 자체가 In-Memory  → MemoryDB

:::tip

"캐시 vs 내구성 인메모리 DB" 선택 문제 자주 출제
분기점 = 데이터 손실 허용 여부
마이크로서비스에서 Network Latency 시 상쇄용 캐시 사용 = Best Practice :::

4. 고가용성 & 운영 안정성

4-1. Multi-AZ 구성 패턴

Aurora Multi-AZ:

3개 AZ에 데이터 자동 복제, 비용은 1개분만 과금
Writer 장애 시 → Reader로 자동 Failover
Read Replica를 다른 AZ에 분산 배치

RDS Multi-AZ:

Standby에 동기 복제 → Failover 자동
Standby는 읽기 불가 (Single Standby 기준)
Multi-AZ with 2 Readable Standbys: 읽기 가능 + 1초 미만 다운타임

DynamoDB Multi-AZ:

3개 AZ에 자동 파티셔닝·복제·동기화
Failover 불필요 — Multi-active 구성

4-2. 가용성 SLA 비교

가용성	서비스
99.999% (5 nines)	Aurora DSQL, DynamoDB, Keyspaces, MemoryDB
99.99% (4 nines)	RDS, ElastiCache, DocumentDB, Timestream

:::tip 미션 크리티컬 + 최고 가용성 요구 → Aurora DSQL 또는 DynamoDB :::

4-3. Blue/Green Deployments

대상: Amazon RDS 및 Aurora 모두 지원
원리:
- Blue = 현재 프로덕션
- Green = AWS가 자동 생성하는 완전 관리형 스테이징
장점:
- 전환 소요 시간: 1분 미만
- 데이터 손실: Zero
- 메이저 버전 업그레이드, 스키마 변경 시 다운타임 없음
RDS Multi-AZ (2 Readable Standbys) + RDS Proxy:
- 마이너 버전 업그레이드 다운타임: 1초 미만

:::tip

"다운타임 없는 메이저 업그레이드" → Blue/Green Deployments
"1초 미만 다운타임" → RDS Proxy 함께 언급 :::

5. Multi-Region 배포 전략

3가지 전략 비교

전략	쓰기 가능 리전	일관성	주요 서비스
Read Replica	Primary 1개	비동기(Eventually)	RDS, Aurora Global DB, DocumentDB, Neptune
Active-Active + Eventual	모든 리전	Eventual (보통 1초 이내)	DynamoDB Global Tables, MemoryDB Multi-Region, Keyspaces
Active-Active + Strong	모든 리전	Strong Consistency	Aurora DSQL, DynamoDB Global Tables (강한 일관성 모드)

5-1. Multi-Region 읽기 복제본

변경사항 비동기 복제 → 읽기를 로컬 리전에서 처리
쓰기는 Primary 리전으로만
용도: 글로벌 읽기 성능 향상 + DR(재해복구)

:::tip 글로벌 읽기 성능 + 쓰기는 단일 리전 허용 → Multi-Region Read Replica :::

5-2. Active-Active + Eventual Consistency

DynamoDB Global Tables:

모든 리전에서 읽기 + 쓰기 동시 가능
비동기 복제 (보통 1초 이내)
충돌 해결: Last Writer Wins
리전 장애 시 → 다른 리전으로 즉시 전환, DB Failover 불필요

MemoryDB Multi-Region:

비동기 복제, 마이크로초 읽기, 99.999%

Keyspaces:

Apache Cassandra 호환, Active-Active, 99.999%

:::tip

전 세계 사용자 쓰기 + 약간의 일관성 지연 허용 → DynamoDB Global Tables (Eventual)
충돌 해결 = Last Writer Wins :::

5-3. Active-Active + Strong Consistency ⭐

Aurora DSQL:

서버리스 분산 SQL (PostgreSQL 호환)
멀티리전에서 강한 일관성 보장
Failover 없이 항상 최신 데이터 접근
인프라 관리 Zero, 읽기·쓰기 독립 스케일링
SLA: 99.999% (멀티리전)
쓰기 처리량: 분산 SQL DB 중 가장 빠름

DynamoDB Global Tables (Strong Consistency 신규):

최소 2개 리전에 동기 쓰기 후 응답
강한 일관성 + Multi-active + 무한 확장
리전 장애 시 다른 리전으로 트래픽 전환 → 항상 최신 데이터

:::tip

멀티리전 + Strong Consistency = Aurora DSQL 또는 DynamoDB Global Tables (강한 일관성)
"리전 장애 시 Failover 없이 자동 전환" = 이 두 서비스의 핵심 강점
Aurora DSQL ≠ Aurora. 별개 서비스임을 명심 :::

6. Zero-ETL

기존 ETL의 문제점

직접 코드 작성·테스트·유지보수 필요
테이블/필드 변경 시 파이프라인 전체 수정
복잡하고 취약하며 확장 한계 존재
데이터 이동 지연(lag) → 실시간 분석 불가
적합하지 않은 케이스: 사기 탐지, 광고 최적화, 공급망 추적

AWS Zero-ETL 통합 구성

Sources (운영 DB)                   Targets (분석/검색)
─────────────────                   ───────────────────
Aurora                      →→→     Amazon Redshift
DocumentDB                  →→→     OpenSearch Service
RDS for MySQL               →→→     SageMaker Lakehouse
DynamoDB                    →→→     S3, Glue
RDS, CloudWatch             →→→

특징:

코드 없이 클릭 몇 번으로 설정 완료
페타바이트 규모 운영 데이터 Near-Real-Time 분석/검색
여러 Aurora 인스턴스 → 단일 Redshift로 통합 → 전사 인사이트

:::tip

"ETL 파이프라인 없이 + 실시간 분석" → Zero-ETL
여러 Aurora 인스턴스 → 단일 Redshift 통합 패턴 암기
Redshift의 Materialized Views, Data Sharing, Federated Access 함께 활용 가능 :::

7. Vector Search & Generative AI

FM/LLM의 두 가지 한계

Knowledge Cut-off — 훈련 데이터 기준일 이후 정보 없음
도메인 특화 지식 부재 — 사내 데이터, 전용 지식 없음

→ 해결책: RAG (Retrieval Augmented Generation)

RAG 워크플로우

[Ingestion 단계]
소스 데이터 (S3 등)
    ↓ 청킹 (Context Window 크기로 분할)
임베딩 모델 (Embedding Model)
    ↓ 벡터 생성
벡터 DB 저장

[Agency 단계]
사용자 쿼리
    ↓ 임베딩 변환
벡터 유사도 검색 (ANN 알고리즘: HNSW, IVFFlat)
    ↓ 관련 청크 검색
FM에 컨텍스트로 주입
    ↓
응답 생성

:::tip

ANN 알고리즘: HNSW, IVFFlat 이름 기억
Bedrock Knowledge Bases = Ingestion + Agency 워크플로우 완전 자동화 :::

벡터 지원 AWS DB (기존 DB에 벡터 내장)

서비스	벡터 지원 방식
Aurora PostgreSQL	pgvector 익스텐션
RDS for PostgreSQL	pgvector 익스텐션
DynamoDB	Zero-ETL → OpenSearch 연동
Amazon Neptune	GraphRAG 지원
MemoryDB	인메모리 벡터 검색
DocumentDB	벡터 검색 내장
OpenSearch Service	Vector Engine (Serverless 포함)

핵심 이점: 기존 운영 DB에 벡터 기능 내장 → 별도 전용 벡터 DB 불필요 = 데이터 마이그레이션·중복·추가 비용·운영 복잡도 모두 제거

GraphRAG (Amazon Neptune 기반)

Neptune이 여러 소스(텍스트·이미지·영상·오디오 등 비정형 포함) 자동 그래프화
검색 시 그래프 탐색 → 더 포괄적·정확한 LLM 응답
조직 데이터의 80% 이상이 비정형 → GraphRAG의 강점
Bedrock Knowledge Bases에 Neptune 통합 내장

:::tip

비정형 데이터 + 관계 중심 검색 + RAG = GraphRAG + Neptune
S3 비정형 데이터 자동 그래프 생성 가능 :::

8. 데이터 마이그레이션

AWS DMS (Database Migration Service)

온프레미스 / 타 클라우드 DB → AWS DB 마이그레이션
지원 유형:
- Homogeneous (동종): MySQL → Aurora MySQL
- Heterogeneous (이종): Oracle → Aurora PostgreSQL (SCT 필요)
SCT (Schema Conversion Tool): 이기종 DB 스키마 자동 변환

:::tip 마이그레이션 + 운영 중단 최소화 → DMS. 이기종 변환 → SCT + DMS 조합 :::

마이그레이션 지원 프로그램

프로그램	내용
AWS Professional Services	전문가 마이그레이션 지원
Database Migration Accelerator (DMA)	고정 비용, DB+앱 변환 AWS 팀 대행
Database Freedom	자격 고객 대상 전문 조언 + 마이그레이션 지원
AWS DMS Partners	파트너 생태계 활용

:::tip 레거시 상용 DB(Oracle 등) 탈피 + 비용 절감 = Database Freedom 프로그램 :::

9. DB 서비스 선택 매트릭스

서비스	유형	주요 Use Case	HA SLA	스케일링
Amazon Aurora	Relational (MySQL/PG)	OLTP, 금융, 이커머스	99.99%	Read Replica + Serverless v2
Aurora DSQL	Distributed SQL (PG)	멀티리전 OLTP + Strong Consistency	99.999%	완전 서버리스, 자동 수평
Amazon RDS	Relational (6개 엔진)	일반 관계형	99.99%	Read Replica + Multi-AZ
DynamoDB	Key-Value / Document	고처리량 OLTP, 세션, 카탈로그	99.999%	완전 서버리스, Global Tables
ElastiCache	In-Memory Cache	DB 캐시, 세션 스토어	99.99%	클러스터 5억 req/s
MemoryDB	In-Memory DB (Durable)	인메모리 성능 + 내구성	99.999%	멀티리전 Active-Active
Neptune	Graph DB	소셜 그래프, 추천, GraphRAG	99.99%	Serverless 지원
OpenSearch	Search / Analytics	전문 검색, 로그 분석, 벡터	-	Serverless Vector Engine
Keyspaces	Wide-Column (Cassandra)	IoT, 타임스탬프 데이터	99.999%	완전 서버리스, 멀티리전
DocumentDB	Document (MongoDB)	JSON 문서, 콘텐츠 관리	99.99%	읽기 복제본
Timestream	Time-Series	IoT 센서, 모니터링 메트릭	99.99%	Serverless (LiveAnalytics)

🎯 시험 단골 패턴 요약

상황	정답
가변 트래픽 + 비용 최적화 (unpredictable traffic/pattern + cost-effective)	Serverless 계열
읽기 성능 향상 (read heavy)	Read Replica 추가
데이터 손실 허용 캐시 (data loss allowed)	ElastiCache
데이터 손실 불허 인메모리 (data loss not allowed)	MemoryDB
멀티리전 Eventually Consistent	DynamoDB Global Tables
멀티리전 Strong Consistency	Aurora DSQL 또는 DynamoDB Global Tables (Strong)
다운타임 없는 메이저 업그레이드 (major upgrade without downtime)	Blue/Green Deployments
ETL 없는 실시간 분석	Zero-ETL (→ Redshift / OpenSearch)
RAG 자동화	Bedrock Knowledge Bases
그래프 기반 추천/관계 탐색	Amazon Neptune
이기종 DB 마이그레이션	DMS + SCT
초대규모 OLTP 쓰기 확장	Aurora PostgreSQL Limitless

🔐 IAM Security Best Practices

Fri, 27 Mar 2026 00:00:00 GMT

🔐 IAM Security Best Practices

출처: AWS IAM 공식 문서 — Security best practices in IAM

URL: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html

목적: SAA-C03 시험 대비 핵심 개념 정리

1. Identity 관리 원칙

핵심 원칙: 임시 자격증명 사용

장기 자격증명(Long-term credentials) 대신 임시 자격증명(Temporary credentials)을 사용하라.

Long-term credentials  = IAM User Access Key  → 보안 리스크 높음
Temporary credentials  = IAM Role (STS)        → 권장 방식

1-1. 휴먼 사용자 — Federation + IdP 사용

권장 방식:

휴먼 사용자(개발자, 관리자, 운영자)에게 개별 IAM User 생성 금지 권고
대신 외부 IdP(Identity Provider)와 페더레이션 사용

구현 방법:

상황	권장 방식
다중 계정 중앙 관리 (권장)	AWS IAM Identity Center (SSO)
단일 계정 소규모	IAM + SAML 2.0 또는 OIDC 직접 페더레이션
모바일/웹앱 사용자	Amazon Cognito Identity Pools

지원 프로토콜:

SAML 2.0: Active Directory Federation Services(ADFS), Shibboleth 등
OIDC: GitHub Actions 등 AWS 외부에서 실행되는 워크플로우

이점:

사내 디렉토리(AD 등)와 통합 → 별도 IAM User 관리 불필요
장기 Access Key 배포/관리 불필요
계정 탈퇴 시 IdP에서 비활성화만 하면 AWS 접근 자동 차단 :::tip
"사내 AD 기반 SSO로 AWS 접근" → IAM Identity Center + SAML
"GitHub Actions가 AWS 리소스에 접근" → OIDC 페더레이션
중앙 집중식 다중 계정 접근 관리 → IAM Identity Center (구 AWS SSO) :::

1-2. 워크로드 — IAM Role 사용

원칙: EC2, Lambda 등 AWS 리소스는 IAM Role 사용 (Access Key 절대 금지)

EC2 인스턴스     → Instance Profile (IAM Role)
Lambda 함수      → Execution Role (IAM Role)
ECS 태스크       → Task Role (IAM Role)
GitHub Actions   → OIDC → IAM Role AssumeRole

왜 Role인가?

STS(Security Token Service)가 임시 자격증명 자동 발급·갱신
Access Key가 코드/환경변수에 하드코딩되는 리스크 제거
AWS SDK가 Instance Profile / 환경 체이닝으로 자동 자격증명 획득 :::tip
"EC2에서 S3 접근" → EC2에 IAM Role 부여 (Access Key 코드 내 설정 X)
IAM User가 필요한 예외 케이스: IAM Role을 지원하지 않는 레거시 시스템 :::

2. Credential 보안 관리

2-1. Access Key 관리

원칙	내용
장기 키 최소화	가능한 IAM Role로 대체. 불가피할 경우만 IAM User Access Key 사용
정기 로테이션	필요한 경우 주기적으로 갱신. AWS Config 룰로 90일 미사용 키 탐지
미사용 키 제거	45일 이상 미사용 → 비활성화 또는 삭제 (CIS Benchmark 권고)
하드코딩 금지	코드, 환경변수, Git 저장소에 Access Key 절대 포함 금지

감지 도구:

IAM Credential Report: 계정 전체 자격증명 현황 보고서
IAM Last Accessed Information: 마지막 서비스/액션 사용 시간
AWS Config Rules: 특정 일수 이상 미사용 키 자동 탐지

2-2. Secrets 관리 Best Practice

DB 패스워드, API Key 등 시크릿 → AWS Secrets Manager
                                   (자동 로테이션 지원)

단순 설정값, 비시크릿 파라미터  → SSM Parameter Store Standard
                                   (무료)

:::tip RDS 패스워드 자동 로테이션 → Secrets Manager :::

3. 최소 권한 원칙 (Least Privilege)

원칙 정의

작업 수행에 필요한 최소한의 권한만 부여하라. 초과 권한은 의도치 않은 동작 및 보안 사고의 원인.

구현 단계

1단계: AWS Managed Policy로 시작 (빠른 설정)
          ↓
2단계: 실제 사용 패턴 파악 (CloudTrail 로그 분석)
          ↓
3단계: IAM Access Analyzer로 최소 권한 Policy 자동 생성
          ↓
4단계: Customer Managed Policy로 세밀한 권한 적용

IAM Access Analyzer 활용

기능	설명
Policy Generation	CloudTrail 로그 기반으로 실제 사용 권한만 추출한 Policy 자동 생성
Policy Validation	100개 이상의 정책 검사. 과도하게 허용적인 권한에 보안 경고
External Access Findings	외부(다른 계정/인터넷)에서 접근 가능한 리소스 탐지

:::tip

"CloudTrail 기반으로 최소 권한 자동 생성" → IAM Access Analyzer Policy Generation
"외부 접근 가능 리소스 탐지" → IAM Access Analyzer External Access :::

흔한 실수: 와일드카드 권한

// ❌ 절대 금지 — Full Admin 권한
{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

// ✅ 올바른 방식 — 특정 서비스·리소스·조건 명시
{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "Bool": {"aws:SecureTransport": "true"}
  }
}

:::tip "Action": "*" + "Resource": "*" = 보안 위반. 제거 또는 세분화 필요 :::

Permission Boundary (권한 경계)

IAM Identity/Role에 설정 가능한 최대 허용 권한 상한선
개발자가 자신보다 높은 권한의 Role/User 생성하는 권한 상승(Privilege Escalation) 방지
Permission Boundary를 벗어난 권한은 실제 Policy에 있어도 거부됨

Permission Boundary = 울타리
Identity-based Policy = 울타리 안에서의 실제 권한

→ 두 Policy의 교집합만 유효

:::tip 개발자에게 IAM 관리 권한 위임 + 권한 상승 방지 → Permission Boundary :::

4. MFA (다중 인증)

MFA 적용 원칙

대상	요구 수준
루트 계정	Hardware MFA 강력 권고 (YubiKey 등)
특권 IAM User (관리자)	MFA 필수
일반 IAM User	MFA 강력 권고
Console 로그인	MFA 조건 Policy로 강제 가능

MFA 강제 Policy 패턴

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

→ MFA 없이 로그인 시 모든 작업 거부

MFA 기기 유형:

Virtual MFA: Google Authenticator, Authy (소프트웨어)
Hardware MFA: YubiKey, Gemalto (물리 장치) — 루트 계정 권장
FIDO Security Key: FIDO2/WebAuthn 지원 하드웨어 키

:::tip

루트 계정 + 강력 보안 → Hardware MFA
MFA 없이 API 접근 차단 → aws:MultiFactorAuthPresent: false 조건으로 Deny :::

5. IAM Policy 구성 전략

5-1. Policy 평가 로직 (시험 핵심)

1. Explicit Deny       → 있으면 즉시 거부 (최우선)
2. Organizations SCP   → OU/계정 단위 guardrail
3. Resource-based Policy (+ Identity-based Policy)
4. Permission Boundary → 최대 허용 상한
5. Session Policy      → AssumeRole 시 추가 제한
6. Identity-based Policy
                        ↓
결론: Default = Implicit Deny
      모든 레이어 통과 + Explicit Allow 있을 때만 허용

:::tip "Explicit Deny는 어떤 Allow보다 우선" — 평가 순서 암기 필수 :::

5-2. Policy 유형 비교

유형	부착 대상	특징
Identity-based	User, Group, Role	가장 일반적. 인프라 권한 정의
Resource-based	S3, SQS, KMS 등 리소스	크로스 계정 접근 허용 가능
Permission Boundary	User, Role	최대 허용 권한 상한 설정
SCP	OU, 계정 (Organizations)	Guardrail. Allow 부여 안 함. 허용 범위만 제한
Session Policy	AssumeRole 호출 시	임시 세션의 권한 추가 제한

5-3. User vs Group vs Role 운영 Best Practice

IAM User   → 원칙적으로 사람에게 생성 지양 (Federation 우선)
              불가피하면 최소 권한 + 주기적 자격증명 감사

IAM Group  → 다수 User에 동일 Policy 일괄 적용
              User에게 직접 Policy 부착 금지 → Group을 통해 관리

IAM Role   → AWS 리소스, 크로스 계정 접근, 페더레이션 사용자
              임시 자격증명 자동 발급 (STS AssumeRole)

:::tip

Policy를 직접 User에 부착하지 않고 Group 통해 관리 = 운영 복잡도 감소 Best Practice
계정 수 증가 → Group/Role 기반 관리가 필수 :::

6. 크로스 계정 & 외부 접근 제어

6-1. SCP (Service Control Policies)

AWS Organizations에서 OU 또는 계정 단위로 적용
Allow를 부여하지 않음 — 최대 허용 범위(Guardrail)만 설정
루트 계정도 SCP를 벗어날 수 없음

활용 예시:

프로덕션 OU → SCP: us-east-1, ap-northeast-2 리전만 허용
개발 OU     → SCP: 고비용 GPU 인스턴스 유형 차단
전체 ORG    → SCP: 특정 서비스(Redshift 등) 생성 금지

:::tip

특정 리전 차단 + 조직 전체 → SCP
SCP는 Allow 부여 안 함. 기존 Allow 권한의 허용 범위를 제한 :::

6-2. IAM Identity Center (AWS SSO)

다중 계정 접근을 중앙에서 단일 포털로 관리
Identity Source: 내장 디렉토리 / 외부 SAML IdP / Active Directory
Permission Set = 계정별 권한 집합 정의
장점: 각 계정에 별도 IAM User 생성 불필요

6-3. 외부 접근 감사

IAM Access Analyzer:

S3 버킷, IAM Role, KMS Key, Lambda 등의 외부 접근 가능 여부 자동 탐지
의도치 않은 퍼블릭/크로스 계정 공개 즉시 발견 :::tip "외부에서 접근 가능한 리소스 자동 탐지" → IAM Access Analyzer :::

7. 모니터링 & 감사

7-1. AWS CloudTrail

모든 AWS API 호출 기록 (누가 / 언제 / 무엇을 / 어디서)
S3 버킷에 로그 저장 → Log File Validation 활성화 (무결성 검증)
IAM 보안 감사의 기본 기반 :::tip "누가 리소스를 변경했는가" → CloudTrail :::

7-2. 불필요한 자격증명 정기 정리

정리 대상:

미사용 IAM User, Role, Group
만료된 Policy 및 권한
90일 이상 미사용 Access Key
45일 이상 미사용 패스워드/Access Key (CIS 기준)

도구:

IAM Credential Report: 계정 전체 자격증명 현황 CSV 다운로드
IAM Last Accessed: 서비스/액션별 마지막 사용 시간
AWS Config Rules: 자동 탐지 및 알림

:::tip "미사용 권한 자동 탐지 + 최소 권한 정책 생성" → IAM Access Analyzer + Last Accessed 정보 조합 :::

7-3. AWS Config

리소스 구성 변경 이력 추적
Compliance Rules:
- iam-user-no-policies-check: User에 직접 Policy 부착 여부
- iam-root-access-key-check: 루트 Access Key 존재 여부
- mfa-enabled-for-iam-console-access: MFA 미설정 User 탐지
Auto-remediation: 비준수 시 Lambda 통해 자동 수정 가능

8. 루트 계정 보호

루트 계정 보안 수칙

항목	권고 사항
일상 사용	절대 금지 — 루트 전용 작업 외 사용 금지
Access Key	생성하지 말 것. 기존 것 즉시 삭제
MFA	Hardware MFA 필수 활성화
이메일	루트 계정 이메일 보안 강화 (2FA 적용)
비밀번호	복잡한 비밀번호 + 안전한 저장소 보관

루트 계정만 할 수 있는 작업:

계정 해지
결제 정보 변경
Support 플랜 변경
IAM Identity Center 활성화 (조직 관리 계정)
S3 버킷 정책이 모든 요청을 차단할 때 버킷 정책 삭제

Centralized Root Access (Organizations)

AWS Organizations 관리 계정에서 멤버 계정의 루트 자격증명 중앙 제어
멤버 계정의 장기 루트 자격증명 제거 및 복구 방지
필요 시 임시 특권 세션(Break Glass)으로만 루트 수준 작업 수행

:::tip

루트 Access Key = 즉시 삭제
"루트 계정 모니터링" → CloudTrail + CloudWatch 알람 연동
AWS Config Rule: iam-root-access-key-check :::

9. 시험 단골 패턴 요약

상황	정답 키워드
사내 AD로 AWS 접근	IAM Identity Center + SAML 2.0 페더레이션
GitHub Actions → AWS 접근	OIDC + IAM Role AssumeRole
EC2에서 S3 접근	IAM Role (Instance Profile) — Access Key 절대 X
다중 계정 권한 중앙 관리	IAM Identity Center (Permission Set)
OU 단위 서비스 사용 차단	SCP (Service Control Policy)
개발자 권한 위임 + 상승 방지	Permission Boundary
미사용 권한 자동 탐지	IAM Access Analyzer + Last Accessed
최소 권한 Policy 자동 생성	IAM Access Analyzer Policy Generation (CloudTrail 기반)
외부 접근 가능 리소스 탐지	IAM Access Analyzer External Access Findings
MFA 없이 API 접근 차단	`aws:MultiFactorAuthPresent: false` Deny Policy
API 호출 감사 로그	CloudTrail
리소스 구성 변경 자동 탐지	AWS Config Rules
루트 계정 Access Key	즉시 삭제 (생성 자체 금지)
DB 자격증명 자동 로테이션	AWS Secrets Manager
단순 설정값 저장	SSM Parameter Store (무료)

🚨 AWS Disaster Recovery — Whitepaper Summary

Mon, 23 Mar 2026 00:00:00 GMT

🚨 AWS Disaster Recovery — Whitepaper Summary

출처: Disaster Recovery of Workloads on AWS: Recovery in the Cloud

Publication: February 12, 2021 | AWS Well-Architected Framework

핵심 개념 정의
Business Continuity Plan (BCP)
Data Plane vs. Control Plane
DR 전략 4가지
Active/Passive vs. Active/Active
Failover 트래픽 라우팅 서비스
AWS 핵심 DR 서비스
DR 테스팅 (Testing Disaster Recovery)
전략 선택 가이드
비용 최적화 관점
📌 시험 자주 출제 포인트 총정리

1. 핵심 개념 정의

Disaster (재해)란?

워크로드 또는 시스템이 Primary 배포 위치에서 비즈니스 목표를 달성하지 못하도록 방해하는 이벤트.

자연재해, 기술 장애, 인위적 실수 모두 포함.

RTO & RPO

지표	정의
RTO (Recovery Time Objective)	서비스 중단 후 복구까지 허용 가능한 최대 시간 ("얼마나 빨리 돌아올 수 있는가?")
RPO (Recovery Point Objective)	마지막 데이터 복구 시점부터 허용 가능한 최대 시간 ("얼마만큼의 데이터 손실을 허용하는가?")

재해 발생
    │
    ├─── RPO ───→ (마지막 백업 시점)
    │                   데이터 손실 범위
    │
    └─── RTO ───→ (서비스 복구 시점)
                    서비스 다운타임 범위

📌 RTO, RPO가 낮을수록 비용과 복잡도 증가 — 비즈니스 요구사항에 맞는 수준 선택 필수

Resiliency vs. DR vs. High Availability

개념	정의	범위
Resiliency	인프라/서비스 장애 복구 능력	광범위
High Availability	단일 구성요소 장애 시에도 서비스 지속	AZ 레벨 단일 장애
Disaster Recovery	일회성 재난 이벤트 발생 시 복구	데이터 센터/리전 레벨

DR은 HA와 별개이며, HA가 완벽해도 DR 전략은 별도로 필요함.

2. Business Continuity Plan (BCP)

DR 전략은 BCP(비즈니스 연속성 계획)의 하위 집합이어야 함 (독립적인 문서 아님)
비즈니스 영향 분석 (Business Impact Analysis)으로 워크로드 중단의 비즈니스 영향 정량화
DR 목표는 비즈니스 요구사항, 우선순위, 맥락에 기반해야 함

예시: 지진으로 물류가 차단되면 eCommerce 앱 DR이 완벽해도 BCP가 물류를 해결 못하면 비즈니스 목표 달성 불가.

3. Data Plane vs. Control Plane

DR 전략 설계 시 핵심 구분:

구분	역할	가용성 목표	Failover 시 사용
Data Plane	실시간 서비스 제공	높음	✅ 권장
Control Plane	환경 설정/관리	낮음	❌ 지양

:::important Failover 작업에는 Data Plane 작업만 사용 — Control Plane 작업(예: AWS Backup 복원)은 재해 시 접근 불가능할 수 있음. ::: :::tip 백업에서 데이터 복원은 Control Plane 작업 → 정기적 주기 복원(Scheduled Periodic Restore)을 미리 설정하여 복원된 데이터스토어를 항상 보유해야 함. :::

4. DR 전략 4가지

전략 비교 한눈에 보기

전략	RPO	RTO	비용	복잡도	트래픽 유형
Backup & Restore	시간 단위	시간 단위	최저 💲	최저	Active/Passive
Pilot Light	분 단위	수십 분	중간 💲💲	중간	Active/Passive
Warm Standby	초 단위	분 단위	높음 💲💲💲	높음	Active/Passive
Multi-Site Active/Active	Near-zero	Near-zero	최고 💲💲💲💲	최고	Active/Active

비용/복잡도 (낮음 → 높음):
Backup & Restore → Pilot Light → Warm Standby → Multi-Site Active/Active

RTO/RPO (높음 → 낮음, 즉 복구 시간 길어짐):
Multi-Site Active/Active → Warm Standby → Pilot Light → Backup & Restore

전략 1: Backup & Restore (백업 및 복원)

개념: 데이터를 정기적으로 백업 → 재해 발생 시 복원

[Primary Region]                    [Recovery Region]
EC2 / RDS / EBS 등
    │
    ├── 스냅샷 생성 (같은 리전)
    └── 스냅샷 복사 ─────────────────→ S3 / Glacier 저장
                                         (재해 시 복원)
                                         인프라도 IaC로 재배포

특성:

가장 단순하고 가장 저렴한 전략
Recovery 시 인프라 배포 + 코드 배포 + 데이터 복원 모두 필요 → 높은 RTO
PITR(Point-in-Time Recovery) 활용 시 RPO를 약 5분까지 낮출 수 있음
모든 워크로드에 기본 적용 (다른 전략과 함께 사용)

AWS 서비스:

AWS Backup: EC2, EBS, RDS, DynamoDB, EFS, FSx 등 중앙 집중 백업 관리
S3 + S3 Glacier: 백업 저장 (Glacier: 수시간 복원)
CloudFormation / CDK: 인프라 코드(IaC)로 복원 시간 단축
Amazon EventBridge + Lambda: 감지 자동화 → RTO 단축

적합한 경우:

비즈니스 크리티컬하지 않은 워크로드
단일 AZ/데이터 센터 장애 수준의 재해만 고려할 때
비용 절감이 최우선일 때 (cost-effective)

전략 2: Pilot Light (파일럿 라이트)

개념: 데이터는 항상 복제 유지 → 핵심 인프라만 Recovery Region에 배포 → 컴퓨팅(EC2 등)은 꺼진(Shut-off) 상태

[Primary Region]               [Recovery Region]
앱 서버 (Active)               앱 서버 = 0개 (배포 안 됨)
RDS Primary ─── Async 복제 ──→ RDS Replica (항상 실행)
ELB / ASG                      ELB / ASG (배포됨, 트래픽 없음)
    │                               │
    │       재해 발생               │
    └───────────────────────────────→
                    AMI에서 EC2 인스턴스 배포 + 스케일 아웃
                    DNS/Global Accelerator로 트래픽 전환

특성:

데이터는 항상 라이브 복제 (DB는 항상 켜짐)
컴퓨팅 리소스는 재해 시 비로소 배포 → 배포 시간 포함 = RTO 수십 분
Warm Standby 대비 비용 절감 (컴퓨팅 비용 없음)
Pilot Light vs Warm Standby 핵심 차이: Pilot Light는 컴퓨팅 없음 → 재해 시 "Turn on"(배포) 필요

AWS Elastic Disaster Recovery (DRS):

Pilot Light 전략을 기반으로 구현
에이전트 기반 블록 레벨 연속 복제 (Block-level replication)
On-premises/EC2 → AWS로 복제 가능 (단, RDS 제외 — EC2 기반 DB만)
RPO: 초 단위 / RTO: 분 단위 달성 가능
Staging Area에 복제본 유지 (저비용 스토리지 + 최소 컴퓨팅)
비파괴적(Non-disruptive) 테스트 드릴 지원
Failover/Failback 모두 지원

AWS 서비스:

Aurora Global Database (복제)
Amazon S3 + CloudFormation (백업 + IaC)
Route 53 / Global Accelerator (트래픽 전환)
AWS Elastic Disaster Recovery

전략 3: Warm Standby (웜 스탠바이)

개념: Recovery Region에 축소된(Scaled-down) 완전한 기능의 환경 항상 실행 → 재해 시 스케일 업(Scale up)만 하면 됨

[Primary Region]               [Recovery Region]
앱 서버 × N개 (Full)          앱 서버 × 1개 (Minimum) ← 항상 실행
RDS Primary ─── 복제 ───────→ RDS Replica (항상 실행)
ELB / ASG (Full)               ELB / ASG (Minimum)
    │                               │
    │       재해 발생               │
    └───────────────────────────────→
                    Scale Out만 하면 됨 (배포 불필요)
                    DNS/Global Accelerator로 트래픽 전환

특성:

항상 최소한의 프로덕션 환경이 실행 중 → 즉시 일부 트래픽 처리 가능
재해 시 스케일 업만 필요 → Pilot Light보다 낮은 RTO
Pilot Light와 비교: 코드와 인프라가 이미 실행 중인 것이 차이
Full Scale = "Hot Standby"라고도 불림

Pilot Light vs Warm Standby 차이 요약:

항목	Pilot Light	Warm Standby
컴퓨팅 상태	배포 안 됨 (꺼짐)	최소 규모로 실행 중
재해 시 행동	배포 + 스케일 아웃	스케일 아웃만
RTO	더 높음	더 낮음
비용	더 낮음	더 높음
즉시 트래픽 처리	❌	✅ (축소된 용량)

AWS 서비스:

Aurora Global Database / RDS Multi-Region Replica
EC2 Auto Scaling (스케일 업)
Route 53 / Global Accelerator (Failover 라우팅)

전략 4: Multi-Site Active/Active (멀티 사이트 액티브/액티브)

개념: 2개 이상의 AWS Region에서 동시에 트래픽 처리 → 한 리전 장애 시 트래픽만 재라우팅

[Region A: Active]             [Region B: Active]
앱 서버 (Full)                 앱 서버 (Full)
RDS ←──── 양방향 복제 ─────→  RDS (Aurora Global)
    ↑                              ↑
    └──── Route 53 / Global Accelerator ────┘
              (두 리전 모두 트래픽 수신)

재해 발생 시: 트래픽을 장애 리전에서 빼는 것만으로 복구

특성:

RPO: Near-zero / RTO: Near-zero 또는 Zero
비동기 데이터 복제로 Near-zero RPO 달성
가장 높은 비용과 복잡도
쓰기 충돌(Write Conflict) 관리 필요 (두 리전에 동시 Write 가능)
데이터 복제는 일부 재해로부터만 보호 → PITR(Point-in-Time Recovery)도 함께 필요

트래픽 라우팅:

Route 53: 지역별 라우팅 정책 (Geoproximity, Latency 등), 비율 기반 가중치
Global Accelerator: AWS Edge Network 활용 → 낮은 지연 시간, DNS 캐시 문제 없음, Traffic Dial로 리전별 비율 설정

5. Active/Passive vs. Active/Active

항목	Active/Passive	Active/Active
해당 전략	Backup & Restore, Pilot Light, Warm Standby	Multi-Site Active/Active
동작	Primary에서 트래픽 처리, DR은 Standby	모든 리전에서 트래픽 처리
Failover 방법	DNS/Global Accelerator로 트래픽 전환	장애 리전에서 트래픽 빼기만
데이터 충돌	없음	쓰기 충돌 관리 필요

6. Failover 트래픽 라우팅 서비스

서비스	특징	Active/Active 지원	DNS 캐시 문제
Amazon Route 53	DNS 기반, 다양한 라우팅 정책 지원	✅	있음
AWS Global Accelerator	Anycast IP, AWS Edge 네트워크 직접 진입	✅	❌ 없음
Amazon CloudFront	Origin Failover (요청 단위), 이후 요청은 Primary로	제한적	-

:::tip Global Accelerator: DNS 캐시 문제 없음, 낮은 지연 시간 → Active/Active, Pilot Light, Warm Standby 모두 적합 :::

7. AWS 핵심 DR 서비스

서비스	역할	주요 전략
AWS Backup	EC2, EBS, RDS, DynamoDB 등 중앙 집중 백업	Backup & Restore
AWS Elastic Disaster Recovery (DRS)	블록 레벨 연속 복제, Failover/Failback	Pilot Light
Aurora Global Database	리전 간 복제 < 1초, 최대 5개 Secondary	Pilot Light, Warm Standby
RDS Read Replica (Cross-Region)	비동기 복제	Pilot Light, Warm Standby
S3 Cross-Region Replication	객체 복제	모든 전략
CloudFormation / CDK	IaC로 DR 리전 인프라 신속 배포	Backup & Restore
AWS Resilience Hub	RTO/RPO 목표 달성 여부 지속 검증 및 추적	모든 전략
Route 53 / Global Accelerator	Failover 트래픽 라우팅	모든 전략
Amazon EventBridge + Lambda	재해 감지 자동화, RTO 단축	모든 전략

8. DR 테스팅 (Testing Disaster Recovery)

:::warning ⚠️ DR 전략은 정기적으로 테스트하지 않으면 실제 재해 시 작동 보장 불가 :::

핵심 원칙

DR 구현을 검증하고 DR 리전으로의 Failover를 정기 테스트하여 RTO/RPO 달성 여부 확인
"거의 실행되지 않는 복구 경로" 패턴 피하기: 드물게 테스트된 경로는 실제 장애 시 실패 위험

테스트해야 하는 이유 (실제 사례):

가정: Secondary DB가 Read-only 쿼리를 담당
     Primary 장애 시 Secondary로 Write 가능하다고 생각

현실: 오랫동안 Failover 테스트를 안 했다면
     → Secondary 용량이 부족하거나
     → 서비스 쿼터가 충족 안 될 수 있음

DR 테스트 방법

방법	설명
Backup 테스트	백업 복원 정기 실행 (단순히 백업 생성으로 충분 아님)
Failover 드릴	실제 DR 리전으로 Failover 시연
Chaos Engineering	의도적 장애 주입으로 복구 능력 검증
DR 드릴	Isolated Subnet에서 실행 → 프로덕션 미간섭

:::note 💡 AWS Resilience Hub: RTO/RPO 목표 달성 여부를 지속적으로 검증하는 서비스 :::

9. 전략 선택 가이드

단순한 데이터 센터 장애 수준 + 비용 최소화
                    ↓
            Backup & Restore

데이터 센터 장애 수준 + RPO/RTO 수십 분 + 비용 절감
                    ↓
               Pilot Light
               (또는 AWS Elastic Disaster Recovery)

리전 레벨 장애 + RPO/RTO 분 단위 + 비즈니스 크리티컬
                    ↓
             Warm Standby

리전 레벨 장애 + Near-zero RPO/RTO + 미션 크리티컬
                    ↓
         Multi-Site Active/Active

규제 요건: 데이터 레지던시 요구사항이 있어 단일 리전만 사용 가능한 경우 → AZ를 Region 대신 DR 사이트로 활용 가능

10. 비용 최적화 관점

AWS는 물리적 Backup Data Center의 고정 자본 비용(CapEx) → **실제 사용량 기반 운영 비용(OpEx)**으로 전환
온프레미스 DR은 항상 2번째 데이터 센터 풀 운영 비용 → AWS에서는 Pilot Light/Warm Standby로 최소 비용만 유지
Glacier / Glacier Deep Archive: 백업 저장 비용 대폭 절감 (아카이브 데이터)
필요 이상으로 엄격한 전략 선택 금지 → 불필요한 비용 발생

📌 시험 자주 출제 포인트 총정리

포인트	내용
RTO 정의	서비스 중단 후 복구까지 허용 최대 시간
RPO 정의	마지막 데이터 복구 시점 이후 허용 최대 시간 (데이터 손실 허용 범위)
RTO/RPO 낮을수록	비용과 복잡도 증가
Data Plane vs Control Plane	Failover에는 Data Plane 작업만 사용 권장
Backup & Restore RTO/RPO	가장 높음 (시간 단위) / 비용 최저
Pilot Light 특징	데이터 라이브 복제, 컴퓨팅 배포 없음
Pilot Light vs Warm Standby	Pilot: 재해 시 "Turn on"(배포) / Warm: 재해 시 "Scale up"만
Warm Standby 특징	최소 규모 환경 항상 실행, 즉시 일부 트래픽 처리 가능
Multi-Site Active/Active	Near-zero RPO/RTO, 모든 리전 Active, 쓰기 충돌 관리 필요
Active/Passive 해당 전략	Backup & Restore, Pilot Light, Warm Standby
Active/Active 해당 전략	Multi-Site Active/Active
AWS Elastic DRS 전략	Pilot Light 기반, 블록 레벨 연속 복제
AWS Elastic DRS 대상	On-premises 또는 EC2 기반 앱/DB (RDS 제외)
Global Accelerator 장점	DNS 캐시 문제 없음, Edge 네트워크 활용
DR 테스팅 필수 이유	드물게 실행되는 복구 경로는 실제 장애 시 실패 가능
Backup에서 자동 복원	AWS SDK로 AWS Backup API 호출 (자동 복원 기본 미지원)
DR 목표 지속 추적	AWS Resilience Hub
단일 리전 규제 환경 DR	AZ를 Recovery Site로 활용

🌐 AWS Networking — VPC

Mon, 23 Mar 2026 00:00:00 GMT

🌐 AWS Networking — VPC

CIDR · VPC · Subnet · IGW · NAT · NACL · Security Group

VPC Peering · Endpoints · VPN · Direct Connect · Transit Gateway · Network Firewall

CIDR — IPv4 주소 체계
VPC (Virtual Private Cloud)
Subnet (서브넷)
Internet Gateway (IGW)
Bastion Host
NAT Gateway vs. NAT Instance
Security Groups vs. NACLs
VPC Flow Logs
VPC Peering
VPC Endpoints (AWS PrivateLink)
Site-to-Site VPN
AWS Direct Connect (DX)
Transit Gateway
VPC Traffic Mirroring
IPv6 & Egress-only Internet Gateway
AWS Network Firewall
네트워킹 비용 (Networking Costs)
AWS 네트워크 보안 계층
VPC 전체 요약
📌 시험 자주 출제 포인트
📚 참고 자료

CIDR — IPv4 주소 체계

CIDR (Classless Inter-Domain Routing)

IP 주소 범위를 정의하는 방법. Security Group 규칙 및 AWS 네트워킹 전반에 사용.

WW.XX.YY.ZZ/32   → 단 1개의 IP
0.0.0.0/0        → 모든 IP
192.168.0.0/26   → 192.168.0.0 ~ 192.168.0.63 (64개 IP)

Subnet Mask 빠른 계산:

CIDR	사용 가능 IP 수	Subnet Mask
/32	1	255.255.255.255
/31	2	-
/30	4	-
/28	16	-
/24	256	255.255.255.0
/16	65,536	255.255.0.0
/8	16,777,216	255.0.0.0

📌 공식: 사용 가능 IP 수 = 2^(32 - mask 숫자)

Private IP 범위 (IANA 지정)

범위	CIDR	용도
10.0.0.0 ~ 10.255.255.255	10.0.0.0/8	대규모 네트워크
172.16.0.0 ~ 172.31.255.255	172.16.0.0/12	AWS Default VPC 범위
192.168.0.0 ~ 192.168.255.255	192.168.0.0/16	홈 네트워크

나머지 IP는 모두 Public IP.

VPC (Virtual Private Cloud)

항목	내용
리전당 최대 VPC 수	5개 (Soft limit, 증가 요청 가능)
VPC당 최대 CIDR 수	5개
CIDR 최소 크기	/28 (16 IP)
CIDR 최대 크기	/16 (65,536 IP)
허용 IP 범위	Private IP 범위만 (10.x, 172.16-31.x, 192.168.x)

:::warning ⚠️ VPC CIDR은 기업 네트워크와 겹치면 안 됨 (VPN/Direct Connect 연결 시 라우팅 충돌) :::

Default VPC

모든 신규 AWS 계정에 자동 생성
EC2 인스턴스 생성 시 Subnet 미지정 시 Default VPC에 배치
기본적으로 Internet Connectivity + Public IPv4 주소 부여
Public/Private IPv4 DNS 이름 모두 제공

Subnet (서브넷)

VPC 내 IPv4 주소의 하위 범위, 특정 AZ에 종속
AWS는 각 Subnet에서 5개의 IP를 예약 (사용 불가)

예시: 10.0.0.0/24 Subnet

주소	용도
10.0.0.0	Network Address
10.0.0.1	VPC Router용 (AWS 예약)
10.0.0.2	Amazon-provided DNS용 (AWS 예약)
10.0.0.3	미래 용도 (AWS 예약)
10.0.0.255	Network Broadcast Address (AWS는 VPC에서 Broadcast 미지원, 예약)

:::tip 29개의 IP가 필요하다면 `/27` (32 IP - 5 = 27 < 29) 불가 → `/26` (64 - 5 = 59) 필요 :::

Internet Gateway (IGW)

VPC 내 리소스가 인터넷에 연결되도록 하는 게이트웨이
수평 확장, 고가용성, 이중화 지원
VPC와 별도로 생성 후 연결 (1 VPC : 1 IGW)
IGW 자체만으로는 인터넷 접근 불가 → Route Table 수정 필수

[EC2] → Route Table → Router → IGW → Internet

Bastion Host

Public Subnet에 위치한 EC2 인스턴스
Private Subnet의 EC2 인스턴스에 SSH 접근하기 위한 Jump Server 역할

보안 설정:

Bastion Host Security Group:
  Inbound: Port 22 허용 — 회사 공인 IP(CIDR)에서만

Private EC2 Security Group:
  Inbound: Port 22 허용 — Bastion Host의 Security Group 또는 Private IP에서만

NAT Gateway vs. NAT Instance

목적: Private Subnet의 EC2가 인터넷(외부)에 접근 가능하도록 (반대 방향은 차단)

항목	NAT Gateway	NAT Instance
관리	AWS 완전 관리형	직접 관리 (OS 패치 등)
가용성	AZ 내 고가용성	스크립트로 Failover 구현
대역폭	최대 100 Gbps (5 Gbps 기본, 자동 확장)	EC2 Instance Type에 따름
보안 그룹	❌ 불필요	✅ 직접 관리
Bastion Host	❌ 불가	✅ 가능
비용	시간당 + 전송량	EC2 비용 + 네트워크 비용
상태	현재 권장	구식 (2020년 지원 종료)

NAT Instance 필수 설정:

Public Subnet에 배치
Source/Destination Check 비활성화
Elastic IP 연결
Route Table에서 Private Subnet → NAT Instance로 라우팅

NAT Gateway 고가용성 구성

[AZ1: Private Subnet] → [NAT-GW-1 (AZ1)] → IGW → Internet
[AZ2: Private Subnet] → [NAT-GW-2 (AZ2)] → IGW → Internet

NAT GW는 단일 AZ 내에서만 고가용성
Multi-AZ 구성: AZ별로 별도 NAT GW 생성 (AZ 장애 시 크로스 AZ Failover 불필요)

Security Groups vs. NACLs

트래픽 흐름

Inbound:  Internet → [NACL Inbound] → [Security Group Inbound] → EC2
Outbound: EC2 → [Security Group Outbound] → [NACL Outbound] → Internet

비교

항목	Security Group	NACL
적용 레벨	EC2 인스턴스 레벨	서브넷 레벨
규칙 유형	Allow만	Allow + Deny 모두
상태	Stateful (Inbound 허용 시 Outbound 자동 허용)	Stateless (Inbound/Outbound 각각 명시 필요)
규칙 평가	모든 규칙 평가 후 결정	낮은 번호부터 순서대로 평가, 첫 매칭 적용
자동 적용	명시적으로 지정해야 함	서브넷 내 모든 EC2에 자동 적용

NACL 규칙 특성

규칙 번호: 1 ~ 32766 (낮은 번호가 높은 우선순위)
마지막 규칙: (asterisk) — 일치하는 규칙 없으면 Deny
새로 생성된 NACL: 모든 트래픽 Deny
Default NACL: 모든 Inbound/Outbound 허용 → 수정 금지, Custom NACL 사용 권장
특정 IP 차단에 적합 (Security Group은 Deny 불가)
규칙 추가 시 100 단위 증분 권장

Ephemeral Ports (임시 포트)

클라이언트가 서버에 연결할 때 응답을 받을 임시 포트를 무작위로 할당
운영체제별 임시 포트 범위:
- IANA/Windows 10: 49152 ~ 65535
- Linux Kernel: 32768 ~ 60999

NACL에서 Ephemeral Port 고려 예시 (Web → DB 통신):

Web-NACL Outbound:  TCP 3306 → DB Subnet CIDR 허용
DB-NACL Inbound:    TCP 3306 ← Web Subnet CIDR 허용
DB-NACL Outbound:   TCP 1024-65535 → Web Subnet CIDR 허용  ← 임시 포트!
Web-NACL Inbound:   TCP 1024-65535 ← DB Subnet CIDR 허용   ← 임시 포트!

VPC Flow Logs로 SG/NACL 트러블슈팅

Flow Log Action	원인
Inbound REJECT	NACL 또는 Security Group 차단
Inbound ACCEPT + Outbound REJECT	NACL 차단 (Stateless)

💡 Security Group은 Stateful이므로 Inbound ACCEPT 시 Outbound는 자동 허용됨.

VPC Flow Logs

VPC / Subnet / ENI 레벨에서 IP 트래픽 정보 캡처
AWS 관리형 인터페이스(ELB, RDS, ElastiCache, NAT GW 등)도 캡처 가능
대상: S3, CloudWatch Logs, Kinesis Data Firehose

Flow Log 필드:

version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status

분석 아키텍처:

VPC Flow Logs → CloudWatch Logs → Contributor Insights → Top-10 IP
VPC Flow Logs → CloudWatch Logs → Metric Filter → Alarm → SNS
VPC Flow Logs → S3 → Athena → QuickSight

:::important ⚠️ CloudWatch Logs로 전송 시 IAM Role에 logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents 권한 필요 :::

VPC Peering

AWS 내부 네트워크로 두 VPC를 프라이빗 연결
같은 네트워크처럼 동작

제약 조건:

CIDR 범위 겹치면 안 됨
Non-transitive: A-B, B-C 피어링이 있어도 A-C 직접 연결 안 됨 → A-C 피어링 별도 생성 필요
연결 후 양쪽 VPC의 Route Table 모두 업데이트 필요
서로 다른 계정/리전 간 VPC Peering 가능
피어링된 VPC의 Security Group 참조 가능 (같은 리전, 다른 계정 간)

VPC-A ←→ VPC-B ←→ VPC-C
A와 C가 통신하려면 별도 A-C 피어링 필요 (B를 통한 전이 없음)

VPC Endpoints (AWS PrivateLink)

Public Internet을 거치지 않고 AWS 내부 네트워크로 AWS 서비스에 접근
IGW, NAT GW 없이 AWS 서비스 접근 가능
수평 확장, 이중화

Endpoint 유형

항목	Interface Endpoint	Gateway Endpoint
구현	ENI (Private IP) 생성	Route Table에 Gateway 추가
Security Group	✅ 필요	❌ 불필요
지원 서비스	대부분의 AWS 서비스	S3, DynamoDB만
비용	시간당 + GB당	무료
확장	ENI 기반	Route Table 기반 (자동 확장)

S3 Endpoint 선택 기준:

일반적으로 → Gateway Endpoint 권장 (무료, Route Table만 수정)
On-premises (VPN/Direct Connect), 다른 VPC, 다른 리전에서 접근
                                  → Interface Endpoint 필요

Site-to-Site VPN

On-premises ↔ AWS VPC 간 암호화된 VPN 터널 (공용 인터넷 경유)

구성 요소:

구성요소	설명
VGW (Virtual Private Gateway)	AWS 측 VPN Concentrator, VPC에 연결
CGW (Customer Gateway)	고객 측 소프트웨어 앱 또는 물리 장비

설정 필수 사항:

CGW 디바이스의 공인 IP 사용 (NAT 뒤에 있으면 NAT의 Public IP)
서브넷 Route Table에서 VGW Route Propagation 활성화
On-premises → EC2 Ping 필요 시 Security Group에 ICMP 프로토콜 Inbound 허용

AWS VPN CloudHub

여러 Site와 VPN 연결을 하나의 VGW에 연결 → Hub-and-Spoke 구성
각 Site 간 보안 통신 (저비용)
공용 인터넷 경유 (암호화됨)
동적 라우팅 + Route Table 설정 필요

AWS Direct Connect (DX)

On-premises ↔ AWS 간 전용 물리 Private 연결 (인터넷 미경유)
DC → AWS Direct Connect Location → VGW → VPC
IPv4, IPv6 모두 지원

Use Cases:

대용량 데이터셋 처리 (높은 대역폭, 낮은 비용)
실시간 데이터 피드 (일관된 네트워크 성능)
Hybrid 환경 (온프레미스 + 클라우드)

Direct Connect 연결 유형

유형	용량	특징
Dedicated Connections	1/10/100 Gbps	물리적 Ethernet 포트 전용
Hosted Connections	50 Mbps ~ 10 Gbps	AWS Direct Connect Partner 통해 요청, 온디맨드 용량 조정 가능

:::important ⚠️ 신규 연결 구축 리드 타임: 보통 1개월 이상 :::

Direct Connect 암호화

데이터 전송 중 암호화 기본 없음 (Private 연결이지만 비암호화)
암호화 필요 시: Direct Connect + Site-to-Site VPN 조합 → IPsec 암호화

Direct Connect Gateway

여러 리전의 여러 VPC에 Direct Connect를 연결할 때 사용
단일 Direct Connect로 여러 리전의 VPC에 접근

Direct Connect 이중화 (Resiliency)

수준	구성
High Resiliency	여러 위치(Location)에 각 1개 DX 연결
Maximum Resiliency	여러 위치에서 각각 별도 디바이스에 2개 이상 DX 연결

Direct Connect 장애 시 Backup

DX 장애 대비 Backup으로 Site-to-Site VPN 연결 설정 가능

Transit Gateway

수천 개의 VPC + On-premises를 Hub-and-Spoke(Star) 방식으로 연결
VPC Peering의 Non-transitive 문제 해결 (Transit GW는 Transitive)

항목	내용
연결 가능 대상	VPC, Direct Connect Gateway, VPN Connection (CGW)
범위	Regional Resource (크로스 리전 지원, 리전 간 TGW Peering)
계정 공유	AWS Resource Access Manager (RAM) 사용
Route Tables	VPC 간 통신 제어 가능
특이 기능	IP Multicast 지원 (다른 AWS 서비스 미지원)

Transit Gateway — ECMP (Equal-Cost Multi-Path)

ECMP: 여러 최적 경로로 패킷 전달하는 라우팅 전략
VPN → Transit Gateway 연결 시 여러 Site-to-Site VPN으로 대역폭 배가 가능

연결 방식	최대 처리량
VPN → Virtual Private Gateway	1.25 Gbps (2개 터널)
VPN → Transit Gateway (ECMP)	2.5 Gbps (2 터널 사용) → VPN 추가로 배가 가능

💡 Direct Connect를 여러 계정과 공유할 때도 Transit Gateway + RAM 조합 사용

VPC Traffic Mirroring

VPC 내 네트워크 트래픽을 캡처하여 분석
소스: ENI / 대상: ENI 또는 NLB
같은 VPC 또는 VPC Peering된 다른 VPC 간에도 가능
Use Cases: 콘텐츠 검사, 위협 모니터링, 네트워크 트러블슈팅

IPv6 & Egress-only Internet Gateway

AWS의 모든 IPv6 주소는 Public + 인터넷 라우팅 가능 (사설 IPv6 범위 없음)
VPC에서 IPv4는 비활성화 불가, IPv6는 선택적 활성화 (Dual-Stack)
EC2는 Private IPv4 + Public IPv6 모두 가짐

Egress-only Internet Gateway:

IPv6 전용 NAT Gateway 역할
VPC 인스턴스의 IPv6 아웃바운드 허용, 인터넷에서의 IPv6 인바운드 차단

방향	IPv4	IPv6
Private → Internet	NAT Gateway	Egress-only IGW
Internet → Private	차단	차단

:::note 📌 EC2 인스턴스 시작 실패 시 — IPv6 주소 공간은 매우 넓으므로 고갈 아님. IPv4 주소 고갈이 원인 → Subnet에 새 IPv4 CIDR 추가 :::

AWS Network Firewall

VPC 전체를 Layer 3 ~ Layer 7까지 보호
내부적으로 AWS Gateway Load Balancer 사용
AWS Firewall Manager로 Cross-Account 중앙 관리

검사 가능한 트래픽:

VPC ↔ VPC
인터넷 Inbound/Outbound
Direct Connect & Site-to-Site VPN

세밀한 제어 (Fine-grained Controls):

IP/Port 기반 규칙
Protocol 기반
Stateful Domain List: .mycorp.com 등 도메인 허용/차단
Regex 패턴 매칭
Active Flow Inspection (침입 방지, IPS 기능)
로그 전송: S3, CloudWatch Logs, Kinesis Data Firehose

네트워킹 비용 (Networking Costs)

EC2 인스턴스 간 트래픽 비용

경로	비용
EC2 인바운드 트래픽	무료
같은 AZ 내 EC2 간 (Private IP)	무료
다른 AZ 간 EC2 (Public/Elastic IP)	$0.02/GB
다른 AZ 간 EC2 (Private IP)	$0.01/GB
리전 간 (Inter-Region)	$0.02/GB

💡 Private IP 사용 권장 (Public IP 대비 절반 비용 + 더 나은 성능)

S3 데이터 전송 비용

경로	비용
S3 Ingress (업로드)	무료
S3 → 인터넷	$0.09/GB
S3 Transfer Acceleration	+$0.04 ~ $0.08/GB
S3 → CloudFront	무료
CloudFront → 인터넷	$0.085/GB (S3 직접보다 저렴 + 캐싱)
S3 Cross-Region Replication	$0.02/GB

NAT Gateway vs. Gateway VPC Endpoint (S3 접근 비용)

방법	비용
NAT Gateway → IGW → S3	NAT GW 시간당 $0.045 + 처리 GB당 $0.045 + S3 데이터 전송
Gateway VPC Endpoint → S3	Gateway Endpoint 사용 무료 ($0.01 In/Out 동일 리전)

✅ Private Subnet에서 S3 접근 시 Gateway VPC Endpoint가 훨씬 저렴

AWS 네트워크 보안 계층

L3-4 네트워크 보호:  NACLs, Security Groups
L3-7 완전 보호:      AWS Network Firewall (Gateway LB 내부 사용)
DDoS 보호:           AWS Shield (Standard/Advanced)
악성 HTTP 요청 차단:  AWS WAF
멀티 계정 관리:       AWS Firewall Manager

VPC 전체 요약

CIDR              : IP 범위 정의
VPC               : 리전 내 격리된 가상 네트워크 (최대 5개/리전)
Subnet            : AZ에 종속된 IP 범위 (5개 IP AWS 예약)
IGW               : VPC → Internet (Route Table 수정 필요)
Bastion Host      : Public EC2 → Private EC2 SSH Jump 서버
NAT Instance      : 구식, Source/Dest Check 비활성화 필요
NAT Gateway       : AWS 관리형, Private → Internet (IPv4)
NACL              : Stateless, Subnet 레벨, Allow + Deny
Security Group    : Stateful, EC2 레벨, Allow만
VPC Peering       : Non-transitive, CIDR 비중복 필수, Route Table 업데이트
VPC Endpoints     : Gateway(S3/DynamoDB, 무료) / Interface(PrivateLink, 유료)
VPC Flow Logs     : IP 트래픽 캡처 → S3/CloudWatch/Firehose
Site-to-Site VPN  : VGW + CGW, 공용 인터넷 경유 암호화
VPN CloudHub      : Hub-and-Spoke 다중 Site VPN
Direct Connect    : 전용 물리 연결 (Private, 암호화 없음)
DX Gateway        : 단일 DX로 여러 리전 VPC 접근
Transit Gateway   : 수천 VPC/VPN/DX Hub-and-Spoke, IP Multicast
Traffic Mirroring : ENI 트래픽 캡처 분석
Egress-only IGW   : IPv6 전용 NAT GW
Network Firewall  : L3-7 완전 VPC 보호

📌 시험 자주 출제 포인트

포인트	내용
Subnet 예약 IP	5개 (첫 4개 + 마지막 1개)
VPC당 최대 CIDR	5개
CIDR 최소/최대	/28 (16개) ~ /16 (65,536개)
IGW만으로 인터넷 접근	Route Table 수정 필요
NAT Instance Source/Dest Check	반드시 비활성화
NAT GW 최대 대역폭	100 Gbps (자동 확장)
NAT GW Security Group	없음 (불필요)
NAT GW Multi-AZ HA	AZ마다 별도 NAT GW 생성
NACL vs SG 상태	NACL: Stateless / SG: Stateful
NACL 규칙 평가	낮은 번호부터 순서대로, 첫 매칭 적용
Default NACL	모든 트래픽 허용 (수정 금지)
특정 IP 차단	NACL의 Deny 규칙 사용 (SG는 Deny 불가)
VPC Peering Transitive	없음 → 각 VPC 쌍마다 별도 Peering
Gateway Endpoint 대상	S3, DynamoDB만
Gateway Endpoint 비용	무료
Interface Endpoint + On-premises	Site-to-Site VPN/DX 경유 접근 시 Interface Endpoint
Direct Connect 암호화	기본 없음 → DX + VPN으로 IPsec 추가
Direct Connect 연결 리드 타임	1개월 이상
DX Gateway	단일 DX로 여러 리전 VPC 접근
Transit Gateway 특이점	IP Multicast 지원 (AWS 유일)
Transit GW 계정 공유	AWS Resource Access Manager (RAM)
VPN → TGW 대역폭	2.5 Gbps (ECMP), VPN 추가 시 배가 가능
VPN → VGW 대역폭	1.25 Gbps
EC2 시작 실패 이유	IPv6 주소 고갈 아님 → IPv4 주소 고갈
Egress-only IGW 대상	IPv6 아웃바운드만
Private → S3 최저 비용	Gateway VPC Endpoint (무료)
Flow Log Action REJECT (Inbound)	NACL 또는 SG 차단
Flow Log Action ACCEPT+REJECT	NACL (Stateless) 차단

📚 참고 자료

🌐 AWS CloudFront & Global Accelerator

Sun, 22 Mar 2026 00:00:00 GMT

🌐 AWS CloudFront & Global Accelerator

CDN을 통한 콘텐츠 가속과 네트워크 레벨 애플리케이션 가속의 핵심 서비스

두 서비스 모두 AWS Global Edge Network를 활용하지만 목적과 동작 방식이 다름

CloudFront 개요
CloudFront Origins (콘텐츠 원본)
CloudFront vs. S3 Cross-Region Replication
CloudFront 캐시 동작 (Caching)
CloudFront Geo Restriction (지역 제한)
CloudFront + S3 보안 아키텍처 (OAC)
AWS Global Accelerator
CloudFront vs. Global Accelerator 비교
시험 자주 출제 포인트 총정리
참고 자료

CloudFront 개요

CDN (Content Delivery Network): 콘텐츠를 Edge Location에 캐시하여 사용자에게 낮은 지연시간으로 제공
전 세계 수백 개의 **Edge Locations (Points of Presence)**에서 콘텐츠 캐시
DDoS 보호: AWS Shield + AWS WAF(Web Application Firewall)와 통합

CloudFront Origins (콘텐츠 원본)

CloudFront가 콘텐츠를 가져오는 원본 서버는 크게 세 가지로 나뉜다.

1. S3 Bucket

파일 배포 및 Edge Location에 캐시
CloudFront를 통한 S3 업로드 (Ingress) 지원
*OAC (Origin Access Control)**로 S3 Bucket 보안 강화

[사용자]  →  [CloudFront Edge]  →  [S3 Bucket]
                                      ↑
                              OAC로 보호
                              (S3 Public 비활성화 유지)

:::tip S3 Bucket을 CloudFront Origin으로 사용할 때는 OAC 사용. 구세대 방식인 OAI(Origin Access Identity)는 deprecated 예정. :::

2. VPC Origin

VPC Private Subnet에 호스팅된 애플리케이션에서 콘텐츠 제공
인터넷에 노출하지 않고 Private 리소스에서 직접 트래픽 수신:
- Private ALB (Application Load Balancer)
- Private NLB (Network Load Balancer)
- Private EC2 Instances
기존 방식(Public Network)의 경우 Edge Location의 Public IP를 Security Group에 허용해야 했으나, VPC Origin 방식은 이 불편함을 해소

[사용자]
    │
    ▼
[CloudFront Edge]
    │  (VPC Origin 방식 — 인터넷 미경유)
    ▼
[Private ALB / NLB / EC2]  ← 인터넷에 노출 불필요

3. Custom Origin (HTTP)

S3 Static Website (S3 정적 웹사이트 엔드포인트)
모든 Public HTTP Backend (온프레미스 서버, 다른 클라우드 등)

CloudFront vs. S3 Cross-Region Replication

시험에서 두 서비스를 비교하는 문제가 자주 출제됨.

항목	CloudFront	S3 Cross-Region Replication
범위	전 세계 모든 Edge Location 자동 적용	복제할 리전을 각각 직접 설정
업데이트 반영	TTL 만료 시 반영 (캐시 기간 동안 지연)	Near real-time 업데이트
접근 방향	읽기/쓰기 가능 (Ingress 지원)	읽기 전용 (Read only)
적합한 콘텐츠	전 세계에서 접근하는 Static 콘텐츠 (이미지, 영상 등)	소수 리전에서 낮은 지연시간으로 Dynamic 콘텐츠 제공
데이터 복사	복사 없음 (캐시만)	실제 객체를 다른 리전으로 복제

CloudFront 캐시 동작 (Caching)

TTL (Time To Live)

CloudFront는 TTL 동안 캐시된 콘텐츠를 사용자에게 제공
TTL 동안은 Origin에 요청하지 않음 → Origin 부하 감소
TTL은 Cache-Control, Expires Header로 제어 가능

Cache Invalidation (캐시 무효화)

Origin 콘텐츠를 업데이트해도 TTL이 만료되기 전까지 CloudFront는 변경을 모름
CloudFront Invalidation을 직접 실행하면 TTL 무시하고 캐시 강제 갱신

Invalidation 경로 예시:
/**          → 전체 캐시 무효화
/images/**   → /images/ 하위 전체 무효화
/index.html  → 특정 파일만 무효화

:::tip[Deployment Tip] 콘텐츠 파일명에 버전/해시를 포함시키면 (예: app.v2.js) Invalidation 없이도 새 버전 즉시 제공 가능. :::

CloudFront Geo Restriction (지역 제한)

특정 국가 사용자의 콘텐츠 접근을 제어
국가 판별: 3rd Party Geo-IP Database 사용

설정	설명
Allowlist	승인된 국가 목록의 사용자만 접근 허용
Blocklist	차단된 국가 목록의 사용자는 접근 거부

Use Case: 저작권법(Copyright Laws)에 따른 콘텐츠 배포 제한

CloudFront + S3 보안 아키텍처 (OAC)

CloudFront를 통해서만 S3에 접근하고 직접 접근은 차단하는 패턴.

[사용자]
    │
    ▼
[CloudFront Distribution]
    │  OAC로 인증된 요청만
    ▼
[S3 Bucket] ← Block Public Access 활성화 유지
              Bucket Policy: CloudFront Service Principal만 허용

Bucket Policy 예시 (OAC):

{
    "Effect": "Allow",
    "Principal": {
        "Service": "cloudfront.amazonaws.com"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
        "StringEquals": {
            "AWS:SourceArn": "arn:aws:cloudfront::ACCOUNT:distribution/DISTRIBUTION_ID"
        }
    }
}

CloudFront Signed URL / Signed Cookies

Private 콘텐츠에 대한 접근 제어 — S3 Pre-signed URL과 다름

항목	CloudFront Signed URL	CloudFront Signed Cookie
접근 범위	파일 1개에 대한 접근	여러 파일 또는 전체 경로 접근
사용 시나리오	개별 파일 다운로드 링크	프리미엄 멤버십 전체 콘텐츠 접근

S3 Pre-signed URL과의 차이점:

항목	S3 Pre-signed URL	CloudFront Signed URL
경유 서버	S3 직접 접근	CloudFront Edge → S3
권한 범위	생성자의 IAM 권한 상속	CloudFront Key Pair 기반
캐시 활용	❌ S3 직접 접근	✅ CloudFront 캐시 활용
IP 제한	불가	가능 (정책에 포함)

:::note CDN을 통해 Private 콘텐츠를 제공할 때는 CloudFront Signed URL/Cookie 사용. S3 Pre-signed URL은 S3 직접 접근이므로 CDN 캐시 혜택 없음. :::

CloudFront Price Classes

CloudFront Edge Location은 지역별로 데이터 전송 비용이 다름
Price Class로 사용할 Edge Location 범위를 제한하여 비용 절감

Price Class	포함 지역	비용
Price Class All	전체 Edge Location	가장 비쌈, 최고 성능
Price Class 200	대부분 지역 (비용 높은 일부 제외)	중간
Price Class 100	가장 저렴한 지역만 (북미, 유럽 등)	가장 저렴

CloudFront Origin Groups (Failover)

Primary Origin이 실패하면 Secondary Origin으로 자동 Failover
High Availability 구성에 활용

[CloudFront Distribution]
    │
    ├── Primary Origin (us-east-1 S3)  ← 정상 시 사용
    └── Secondary Origin (us-west-2 S3) ← Primary 실패 시 자동 전환

Lambda@Edge / CloudFront Functions

Edge Location에서 코드를 실행하여 요청/응답을 동적으로 처리.

항목	CloudFront Functions	Lambda@Edge
런타임	JavaScript	Node.js, Python
실행 트리거	Viewer Request/Response	Viewer/Origin Request/Response
실행 위치	CloudFront Edge (경량)	리전 Edge Location
최대 실행 시간	1ms	5~10초
요청 수/초	수백만 req/s	수천 req/s
사용 사례	Header 조작, URL 리다이렉트, A/B 테스트	복잡한 로직, 외부 API 호출

AWS Global Accelerator

문제 정의

글로벌 사용자가 특정 리전에 배포된 애플리케이션에 접근할 때, Public Internet을 통한 **다수의 Hop(경유지)**으로 인해 지연 시간과 패킷 손실 발생.

[일본 사용자]  →  Public Internet  →  [us-east-1 ALB]
               (수많은 라우터 경유 → 높은 지연, 불안정)

해결: AWS 내부 네트워크 활용

[일본 사용자]  →  [도쿄 Edge Location]  →  AWS 전용 백본망  →  [us-east-1 ALB]
               (짧은 Public Internet 구간)    (고속, 안정)

Anycast IP

Global Accelerator는 애플리케이션에 2개의 Anycast IP 할당
Unicast IP: 하나의 서버가 하나의 IP를 보유
Anycast IP: 여러 서버가 같은 IP를 보유, 클라이언트는 자동으로 가장 가까운 서버로 라우팅

Anycast IP: 1.2.3.4  ← 전 세계 어디서 요청해도 같은 IP
    │
    ├── 도쿄 Edge → 도쿄 사용자 처리
    ├── 런던 Edge → 유럽 사용자 처리
    └── 버지니아 Edge → 미국 사용자 처리

Global Accelerator 주요 특성

항목	내용
고정 IP	2개의 Anycast IP (변경 없음)
지원 리소스	Elastic IP, EC2, ALB, NLB (Public/Private 모두)
Health Check	애플리케이션 헬스 체크, 비정상 시 1분 이내 Failover
보안	외부에 노출되는 IP가 단 2개 → 화이트리스트 관리 용이
DDoS 보호	AWS Shield 통합
클라이언트 캐시 이슈	IP가 변경되지 않으므로 DNS 캐시 문제 없음

CloudFront vs. Global Accelerator 비교

📌 시험에서 가장 자주 출제되는 비교 — 반드시 구분

항목	CloudFront	Global Accelerator
주요 기능	콘텐츠 캐싱 및 배포	네트워크 레벨 트래픽 가속
캐싱	✅ Edge Location에 콘텐츠 캐시	❌ 캐시 없음 (프록시만)
콘텐츠 처리	Edge에서 콘텐츠 직접 제공	Edge에서 패킷을 원본 서버로 전달
프로토콜	HTTP/HTTPS 전용	TCP, UDP 모두 지원
IP 주소	동적 IP (DNS로 접근)	고정 Anycast IP 2개
Failover	느림 (DNS TTL 영향)	1분 이내 빠른 Failover
적합한 Use Case	Static/Dynamic HTTP 콘텐츠 가속	게임(UDP), IoT(MQTT), VoIP, 고정 IP 필요, 빠른 Regional Failover

간단 선택 기준:

HTTP 콘텐츠를 전 세계에 빠르게 배포 → CloudFront
캐시와 무관한 TCP/UDP 애플리케이션 가속 → Global Accelerator
고정 IP 2개로 방화벽 화이트리스팅 필요 → Global Accelerator
HTTP 요청이지만 Static IP 또는 빠른 Failover 필요 → Global Accelerator

📌 시험 자주 출제 포인트 총정리

포인트	내용
CloudFront 보안 통합	AWS Shield + WAF
S3 Origin 보안	OAC (Origin Access Control) (구: OAI deprecated 예정)
VPC Origin	Private ALB/NLB/EC2를 인터넷 노출 없이 Origin으로 사용 가능
Cache Invalidation	`/` 또는 `/path/` 로 TTL 무시 강제 갱신
Geo Restriction 판별	3rd Party Geo-IP Database 사용
CloudFront vs S3 CRR	정적 전세계 배포 → CloudFront / 소수 리전 동적 콘텐츠 → S3 CRR
Signed URL	파일 1개 접근 제한
Signed Cookie	여러 파일 또는 경로 전체 접근 제한
CloudFront Signed URL vs S3 Pre-signed URL	CloudFront: Edge 캐시 활용, IP 제한 가능 / S3: S3 직접 접근, IAM 권한 상속
Price Class 100	가장 저렴한 지역만 (북미, 유럽 등)
Origin Failover	Primary 실패 시 Secondary로 자동 전환
CloudFront Functions	경량 JS, 1ms, Viewer Request/Response
Lambda@Edge	복잡한 로직, 5~10초, Viewer + Origin 트리거
Global Accelerator IP 수	2개의 Anycast IP
Global Accelerator Failover	1분 이내
Anycast IP 개념	여러 서버가 같은 IP 공유, 클라이언트는 가장 가까운 서버로 라우팅
Global Accelerator 지원 프로토콜	TCP + UDP (CloudFront는 HTTP만)
고정 IP 화이트리스팅	Global Accelerator (IP 2개만 노출)
Non-HTTP 가속 (UDP, MQTT, VoIP)	Global Accelerator

📚 참고 자료

🐳 AWS Container Services

Sun, 22 Mar 2026 00:00:00 GMT

🐳 AWS Container Services

Docker · ECS · ECR · EKS · App Runner · App2Container

컨테이너 기반 애플리케이션 배포 및 관리의 전체 스택

Docker 기초
AWS에서의 Container 관리 서비스
Amazon ECS (Elastic Container Service)
Amazon ECR (Elastic Container Registry)
Amazon EKS (Elastic Kubernetes Service)
AWS App Runner
AWS App2Container (A2C)
Container 서비스 선택 가이드
📌 시험 자주 출제 포인트 총정리
📚 참고 자료

Docker 기초

개념

애플리케이션을 Container로 패키징하여 어떤 OS, 어떤 환경에서도 동일하게 실행
"Works on my machine" 문제 해결: 개발/테스트/운영 환경 불일치 제거
Use Cases: 마이크로서비스(Microservices), 온프레미스 앱의 AWS Lift-and-Shift

Docker Image 저장소

저장소	설명
Docker Hub	Public 저장소, OS/기술별 Base Image 제공
Amazon ECR (Private)	AWS 관리형 Private 저장소
Amazon ECR Public Gallery	Public Image 저장소

Docker vs. Virtual Machine

Virtual Machine:
  [Hardware] → [Hypervisor] → [Guest OS 1] → [App A]
                           → [Guest OS 2] → [App B]

Docker:
  [Hardware] → [Host OS] → [Docker Engine] → [Container A: App A]
                                           → [Container B: App B]

Docker: Host OS 커널 공유 → 가볍고 빠름
VM: 각각 완전한 OS 포함 → 무겁지만 강한 격리

AWS에서의 Container 관리 서비스

서비스	역할	인프라 관리
Amazon ECS	AWS 자체 컨테이너 플랫폼	EC2(직접) 또는 Fargate(관리형)
Amazon EKS	관리형 Kubernetes	EC2(직접) 또는 Fargate(관리형)
AWS Fargate	Serverless 컨테이너 플랫폼	인프라 불필요
Amazon ECR	Container Image 저장소	-
AWS App Runner	완전 관리형 웹앱/API 배포	완전 자동

Amazon ECS (Elastic Container Service)

EC2 Launch Type

ECS Cluster 위에 직접 EC2 Instance를 프로비저닝/관리
각 EC2 Instance에 ECS Agent 설치 필수 → ECS Cluster에 등록
AWS는 Container의 시작/중지만 담당

[ECS Cluster]
  ├── EC2 Instance 1 (ECS Agent 실행)
  │     ├── Container A
  │     └── Container B
  └── EC2 Instance 2 (ECS Agent 실행)
        └── Container C

Fargate Launch Type

EC2 Instance 없이 완전 Serverless로 컨테이너 실행
Task Definition만 생성하면 AWS가 알아서 컨테이너 실행
스케일링: Task 수만 늘리면 됨 — EC2 Instance 관리 불필요

[ECS Cluster]
  └── Fargate Task A  ← AWS가 인프라 자동 관리
  └── Fargate Task B
  └── Fargate Task C

EC2 Launch Type vs. Fargate 비교

항목	EC2 Launch Type	Fargate
인프라 관리	직접 EC2 프로비저닝/패치	❌ 불필요
비용	EC2 비용 (장기 사용 시 유리)	Task별 CPU/RAM 사용량 과금
스케일링 복잡도	EC2 + Task 두 레벨 관리	Task만 관리
Spot Instance 활용	✅ 가능	✅ Fargate Spot 가능
맞춤 설정	높음 (EC2 직접 제어)	낮음

ECS IAM Roles

두 가지 Role을 명확히 구분 — 시험 빈출

Role	사용 주체	목적
EC2 Instance Profile	ECS Agent (EC2 Launch Type만 해당)	ECS 서비스 API 호출, CloudWatch 로그 전송, ECR 이미지 Pull, Secrets Manager/SSM 접근
ECS Task Role	각 ECS Task	Task별로 다른 AWS 서비스 접근 권한 부여

EC2 Instance
  └── ECS Agent (EC2 Instance Profile 사용)
        └── ECS Task A (Task Role A: S3 Read 권한)
        └── ECS Task B (Task Role B: DynamoDB Write 권한)

:::tip Task Role은 Task Definition에서 정의. EC2 Instance Profile과 독립적으로 동작. :::

ECS Load Balancer 통합

Load Balancer	지원 여부	권장 상황
ALB	✅	대부분의 Use Case (권장)
NLB	✅	고처리량/고성능, AWS Private Link 연계
CLB	✅ (비권장)	고급 기능 없음, Fargate 미지원

ECS - Data Volumes (EFS 연동)

ECS Task에 EFS 파일 시스템 마운트 가능
EC2 및 Fargate Launch Type 모두 지원
어떤 AZ에서 실행되든 동일한 EFS 데이터 공유

Fargate + EFS = 완전 Serverless 영구 스토리지

:::important Amazon S3는 ECS Task에 파일 시스템으로 마운트 불가 (S3는 Object Storage). :::

ECS Service Auto Scaling

ECS Service(Task 레벨) Auto Scaling과 EC2 Instance Auto Scaling은 별개임.

ECS Service Auto Scaling 정책:

정책	설명
Target Tracking	특정 CloudWatch 지표의 목표값 유지
Step Scaling	CloudWatch Alarm 기반 단계별 조정
Scheduled Scaling	특정 일시에 미리 스케일링

스케일링 지표:

ECS Service Average CPU Utilization
ECS Service Average Memory Utilization
ALB Request Count Per Target

EC2 Launch Type — Auto Scaling EC2 Instances

ECS Service가 스케일 아웃되면 EC2 인스턴스도 함께 늘어야 함.

방법	설명
Auto Scaling Group	CPU Utilization 기반 EC2 Scale Out
ECS Cluster Capacity Provider	Task 실행에 필요한 용량 부족 시 자동으로 EC2 추가 (ASG와 연동)

:::tip Capacity Provider가 권장됨: Task 수요에 따라 EC2를 자동 프로비저닝. :::

ECS 이벤트 기반 아키텍처

Pattern 1: S3 → EventBridge → ECS Task (On-demand)

[사용자] → S3 Upload
              │
              ▼ EventBridge Rule
         [ECS Task 실행] → S3에서 파일 가져오기 → DynamoDB 저장
         (ECS Task Role: S3 + DynamoDB 권한)

Pattern 2: EventBridge Schedule → ECS Task (Batch)

[EventBridge: 매 1시간] → ECS Task 실행 → S3 Batch Processing

Amazon ECR (Elastic Container Registry)

항목	내용
저장소 유형	Private Repository / Public Repository (ECR Public Gallery)
통합	ECS와 완전 통합, 백엔드는 Amazon S3
접근 제어	IAM 기반 (권한 오류 → IAM Policy 확인)
부가 기능	이미지 취약점 스캔(Vulnerability Scanning), 버저닝, Image Tags, Lifecycle 정책

[Docker Build] → [docker push] → [ECR] → [ECS Pull] → [Container 실행]
                                     ↑
                              IAM 권한 필요
                              (Pull 시 ECR에 대한 읽기 권한)

Amazon EKS (Elastic Kubernetes Service)

개요

완전 관리형 Kubernetes Cluster 서비스
Kubernetes: 컨테이너 자동 배포, 스케일링, 관리를 위한 오픈소스 시스템
ECS와 유사한 목적이지만 다른 API (Kubernetes API)
Cloud-agnostic → 다른 클라우드/온프레미스의 Kubernetes와 호환

:::tip

선택 기준:
- 이미 Kubernetes를 사용 중이거나 멀티 클라우드 전략 → EKS.
- AWS에서 새로 시작 → ECS가 더 단순. :::

EKS Node Types

유형	설명	관리 주체
Managed Node Groups	EKS가 EC2 Node 생성 및 관리, ASG 자동 관리	AWS
Self-Managed Nodes	사용자가 EC2 생성 후 EKS Cluster에 등록	사용자
AWS Fargate	Serverless, Node 관리 불필요	AWS

Managed/Self-Managed: On-Demand 또는 Spot Instance 모두 지원

EKS Data Volumes

EKS Cluster에 StorageClass Manifest 지정 필요
CSI (Container Storage Interface) 드라이버 사용

스토리지	Fargate 지원
Amazon EBS	❌
Amazon EFS	✅
FSx for Lustre	❌
FSx for NetApp ONTAP	❌

AWS App Runner

소스 코드 또는 Container Image로부터 웹앱/API를 완전 자동으로 배포
인프라 경험 불필요 — 빌드, 배포, 스케일링, 로드 밸런싱, 암호화 모두 자동
VPC 접근 지원 → DB, Cache, 메시지 큐 연결 가능

[Source Code 또는 Container Image]
          │
          ▼
   [App Runner]
   ├── 자동 빌드
   ├── 자동 배포
   ├── 자동 스케일링
   ├── 로드 밸런서
   └── HTTPS 자동 설정

Use Cases: 웹앱, API, 마이크로서비스, 빠른 프로덕션 배포

AWS App2Container (A2C)

Java / .NET 웹 애플리케이션을 Docker Container로 변환하는 CLI 도구
온프레미스(베어 메탈, VM) 또는 다른 클라우드에서 실행 중인 앱을 AWS로 Lift-and-Shift
코드 변경 없이 레거시 앱 현대화(Modernization) 가속

A2C 프로세스

1. Discover & Analyze
   앱 인벤토리 생성 + 런타임 의존성 분석

2. Extract & Containerize
   앱 + 의존성 추출 → Docker Image 생성

3. Create Deployment Artifacts
   ECS Task Definition / EKS Pod Definition 생성
   CloudFormation Template (인프라: 컴퓨팅, 네트워크) 생성
   CI/CD Pipeline 생성

4. Deploy to AWS
   Docker Image → ECR 등록
   → ECS / EKS / App Runner 배포

Container 서비스 선택 가이드

컨테이너 이미지 저장이 필요한가?
└── 예 → Amazon ECR

어떤 컨테이너 오케스트레이터를 사용할 것인가?
├── AWS Native, 간단한 설정 원함 → Amazon ECS
│     ├── 서버 관리 직접 하고 싶음 → EC2 Launch Type
│     └── Serverless 원함          → Fargate Launch Type
│
└── Kubernetes 사용 중 or 멀티 클라우드 → Amazon EKS
      ├── 서버 관리 직접 하고 싶음 → Managed/Self-Managed Nodes
      └── Serverless 원함          → Fargate

코드만 있고 인프라는 전혀 신경 쓰기 싫음 → App Runner

기존 Java/.NET 앱을 컨테이너로 이전 → App2Container

📌 시험 자주 출제 포인트 총정리

포인트	내용
EC2 Instance Profile vs Task Role	Instance Profile: ECS Agent용 / Task Role: 각 Task용, Task Definition에서 정의
ECS + EFS	멀티 AZ 공유 영구 스토리지, Fargate와 함께 Serverless 영구 스토리지
S3 ECS Task 마운트	불가 (Object Storage는 파일 시스템 마운트 불가)
ECS Capacity Provider	Task 수요에 따라 EC2 자동 프로비저닝
ECR 권한 오류	IAM Policy 확인
ECR 백엔드	Amazon S3
EKS Kubernetes 특징	Cloud-agnostic, 오픈소스
EKS Fargate EFS 지원	✅ (EBS는 Fargate에서 미지원)
App Runner	소스코드/Container Image → 인프라 없이 자동 배포
App2Container 대상	Java, .NET 앱
App2Container 결과물	Docker Image(ECR) + Task/Pod Definition + CloudFormation Template + CI/CD Pipeline
Fargate Auto Scaling	EC2 관리 불필요, Task 수만 조절
ALB vs NLB (ECS)	대부분 ALB / 초고성능 또는 Private Link → NLB
CLB + Fargate	미지원
EKS Spot Instance	Managed/Self-Managed Node에서 지원

📚 참고 자료

📊 AWS Database & Data Analytics

Sun, 22 Mar 2026 00:00:00 GMT

📊 AWS Database & Data Analytics

RDS · Aurora · ElastiCache · DynamoDB · DocumentDB · Neptune · Keyspaces · Timestream

Athena · Redshift · OpenSearch · EMR · QuickSight · Glue · Lake Formation · Flink · MSK

DB 유형 전체 비교
RDS (요약)
Aurora (요약)
ElastiCache (요약)
DocumentDB
Amazon Neptune
Amazon Keyspaces (for Apache Cassandra)
Amazon Timestream
Amazon Athena
Amazon Redshift
Amazon OpenSearch Service
Amazon EMR (Elastic MapReduce)
Amazon QuickSight
AWS Glue
AWS Lake Formation
Amazon Managed Service for Apache Flink
Amazon MSK (Managed Streaming for Apache Kafka)
빅데이터 수집 파이프라인 아키텍처
📌 시험 자주 출제 포인트

DB 유형 전체 비교

유형	서비스	특징
RDBMS (OLTP)	RDS, Aurora	SQL, JOIN 가능
NoSQL	DynamoDB, ElastiCache, Neptune, DocumentDB, Keyspaces	JOIN/SQL 없음
Object Store	S3, S3 Glacier	대용량 객체, 아카이브
Data Warehouse (OLAP)	Redshift, Athena, EMR	SQL 분석, BI
Search	OpenSearch	전체 텍스트 검색, 비정형
Graph	Neptune	관계 데이터 시각화
Ledger	QLDB (Quantum Ledger DB)	변경 불가 트랜잭션 이력
Time Series	Timestream	시계열 데이터

RDS (요약)

Managed: PostgreSQL / MySQL / Oracle / SQL Server / DB2 / MariaDB / Custom
Provisioned Instance Size + EBS Volume
Read Replicas, Multi-AZ, Storage Auto Scaling
IAM, Security Groups, KMS(rest), SSL(transit)
PITR 최대 35일, Manual Snapshot 무제한
RDS Custom: Oracle/SQL Server 전용, OS 및 DB 직접 접근 가능
Use Case: RDBMS/OLTP, SQL 쿼리, 트랜잭션

Aurora (요약)

PostgreSQL/MySQL API 호환, 스토리지와 컴퓨팅 분리
스토리지: 3 AZ × 2 = 6개 복사본, Self-healing, Auto Scaling
컴퓨팅: Multi-AZ DB Cluster, Read Replica Auto Scaling
Aurora Serverless: 예측 불가/간헐적 워크로드
Aurora Global: 리전당 최대 16 Read Instance, 리전 간 복제 < 1초
Aurora ML: SageMaker/Comprehend 통합
Aurora Cloning: 기존 클러스터에서 빠르게 새 클러스터 생성 (스테이징 DB)
Use Case: RDS와 동일 + 더 높은 성능, 가용성, 유연성

ElastiCache (요약)

Managed Redis / Memcached, Sub-millisecond 지연
Redis: Multi-AZ, Read Replicas, Backup, AOF 영속성
Memcached: Sharding, 비영속, 멀티스레드
보안: IAM, Security Groups, KMS, Redis AUTH
애플리케이션 코드 변경 필요
Use Case: Key/Value 캐시, 세션 스토어, DB 쿼리 결과 캐시

DocumentDB

Aurora의 AWS 구현처럼, DocumentDB는 MongoDB의 AWS 구현
JSON 데이터 저장/쿼리/인덱싱
Aurora와 유사한 배포 개념: Fully Managed, 3 AZ 고가용성
스토리지 자동 증가 (10 GB 단위)
초당 수백만 req로 자동 확장
Use Case: MongoDB 워크로드를 AWS로 이전

Amazon Neptune

완전 관리형 Graph Database
수십억 개 관계 저장, Millisecond 단위 쿼리
3 AZ 고가용성, 최대 15 Read Replicas
Use Cases: 소셜 네트워크, 지식 그래프(Wikipedia), 사기 탐지, 추천 엔진

Neptune Streams

Graph 데이터 변경의 실시간 순서 보장 스트림
HTTP REST API로 접근
Use Cases: 변경 알림, OpenSearch/ElastiCache 동기화, 리전 간 복제

Amazon Keyspaces (for Apache Cassandra)

Apache Cassandra 호환 완전 관리형 DB
Serverless, Scalable, Multi-AZ (3 AZ 복제)
Cassandra Query Language (CQL) 사용
Single-digit millisecond 지연, 초당 수천 req
On-Demand 또는 Provisioned with Auto-scaling
PITR 최대 35일
Use Cases: IoT 디바이스 데이터, 시계열 데이터

Amazon Timestream

완전 관리형 Time Series Database, Serverless
하루 수조 개 이벤트 처리, 관계형 DB 대비 100배 빠름, 1/10 비용
스토리지 티어링: 최근 데이터 → 메모리 / 과거 데이터 → 저비용 스토리지
내장 시계열 분석 함수 (Near real-time 패턴 식별)
SQL 호환, 암호화(transit/rest)
Use Cases: IoT, 운영 모니터링, 실시간 분석

Amazon Athena

S3에 저장된 데이터를 Serverless SQL로 분석
Presto 기반, Standard SQL 사용
지원 포맷: CSV, JSON, ORC, Avro, Parquet
가격: 스캔된 데이터 TB당 $5.00
Amazon QuickSight와 연동하여 BI 대시보드 구성

성능 최적화 (비용 절감):

방법	효과
Columnar 포맷 (Parquet, ORC)	스캔 데이터 감소 → 비용 대폭 절감
Glue로 변환	CSV → Parquet/ORC 자동 변환
데이터 압축	bzip2, gzip, snappy 등
S3 Partitioning	가상 컬럼 기반 파티셔닝으로 스캔 범위 축소
큰 파일 사용	> 128 MB 권장 (소형 파일 오버헤드 제거)

Federated Query:

관계형/비관계형/S3 등 다양한 소스를 SQL로 통합 쿼리
Lambda 기반 Data Source Connector 사용 (CloudWatch Logs, DynamoDB, RDS 등)

📌 시험 Tip: "S3 데이터를 Serverless SQL로 분석" → Athena

Amazon Redshift

PostgreSQL 기반이지만 OLAP (데이터 웨어하우스), OLTP 아님
Columnar Storage + 병렬 쿼리 엔진 → Petabyte 규모 분석
Athena보다 Index 덕분에 더 빠른 Join/집계
BI 도구 (QuickSight, Tableau) 통합

클러스터 구조

[Leader Node]   : 쿼리 계획 + 결과 집계
[Compute Nodes] : 실제 쿼리 실행 (N개)

두 가지 모드: Provisioned Cluster / Serverless Cluster

Snapshots & DR

일부 클러스터에 Multi-AZ 모드 지원
Snapshot = 클러스터의 PITR 백업 (S3 내부 저장, Incremental)
자동 백업: 8시간마다 / 5 GB마다 / 스케줄 기반
수동 백업: 명시적 삭제 전까지 유지
다른 리전으로 Snapshot 자동 복사 설정 가능

데이터 로딩 방법

방법	설명
Kinesis Data Firehose	Firehose → S3 → COPY로 Redshift 적재
S3 COPY 명령	IAM Role로 S3에서 직접 COPY (VPC 라우팅 가능)
EC2 + JDBC	배치로 데이터 전송 (대량 Insert가 유리)

Redshift Spectrum

S3 데이터를 Redshift에 로딩하지 않고 직접 쿼리
Redshift Cluster가 있어야 함 (쿼리는 수천 개 Spectrum 노드에서 처리)

Amazon OpenSearch Service

Amazon ElasticSearch의 후속 서비스
어떤 필드든 전체 텍스트 검색 가능 (DynamoDB는 Primary Key/Index만)
다른 DB의 보완재로 일반적으로 사용
Managed Cluster 또는 Serverless 모드
기본 SQL 미지원 (플러그인으로 활성화 가능)
데이터 수집: Kinesis Data Firehose, IoT, CloudWatch Logs
보안: Cognito, IAM, KMS, TLS
OpenSearch Dashboards (시각화) 포함

OpenSearch 통합 패턴

DynamoDB + OpenSearch:

[앱 CRUD] → [DynamoDB] → [DynamoDB Stream] → [Lambda] → [OpenSearch]
[앱 검색] → OpenSearch API → 검색 결과 → DynamoDB에서 상세 조회

CloudWatch Logs:

CloudWatch Logs → Subscription Filter → Lambda → OpenSearch (Real-time)
CloudWatch Logs → Subscription Filter → Firehose → OpenSearch (Near real-time)

Kinesis:

KDS → Firehose → OpenSearch (Near real-time)
KDS → Lambda   → OpenSearch (Real-time)

Amazon EMR (Elastic MapReduce)

Hadoop 클러스터 기반 빅데이터 분석 플랫폼
수백 개의 EC2 인스턴스로 구성된 클러스터
Apache Spark, HBase, Presto, Flink 번들 포함
프로비저닝/설정 자동화, Auto Scaling, Spot Instance 통합

노드 유형 및 구매 옵션

노드 유형	역할	특성
Master Node	클러스터 관리, 상태 조율	Long-running
Core Node	작업 실행 + 데이터 저장	Long-running
Task Node	작업 실행만	일반적으로 Spot Instance

구매 방식	특징
On-Demand	안정적, 종료 없음
Reserved	비용 절감 (가용 시 EMR 자동 사용)
Spot	저렴하지만 종료 가능, 덜 안정적

Amazon QuickSight

Serverless ML 기반 BI(Business Intelligence) 서비스
인터랙티브 대시보드 생성, 자동 확장, Session 단위 과금
SPICE 엔진: 데이터 Import 시 In-memory 계산
Enterprise 버전: Column-Level Security (CLS)

통합 데이터 소스:

RDS, Aurora, Redshift, Athena, S3, OpenSearch, Timestream
Salesforce, Jira, Teradata, 온프레미스 DB (JDBC)
파일: xlsx, csv, json, tsv, elf/clf

대시보드 공유:

Users (Standard) / Groups (Enterprise) — QuickSight 내부 개념 (IAM과 별개)
대시보드 공유 전 반드시 Publish 필요
대시보드를 보는 사용자는 기저 데이터도 볼 수 있음

AWS Glue

완전 관리형 ETL (Extract, Transform, Load) 서비스, Serverless
S3 또는 RDS 데이터 → Glue ETL(변환) → Redshift 로드

Glue Data Catalog

S3, RDS, DynamoDB, JDBC → Glue Data Crawler → Glue Data Catalog (메타데이터)
Athena, Redshift Spectrum, EMR이 Catalog를 통해 데이터 검색

Glue 주요 기능

기능	설명
Job Bookmarks	이미 처리한 데이터 재처리 방지
DataBrew	코드 없는 사전 빌드 변환으로 데이터 정제
Glue Studio	ETL Job 생성/실행/모니터링 GUI
Streaming ETL	Kinesis Data Streams, Kafka, MSK 기반 스트리밍 ETL (Spark Structured Streaming)

CSV → Parquet 변환 패턴

[S3 Input] ─(Put)─→ Glue ETL (CSV → Parquet 변환) → [S3 Output]
                              ↑ Lambda/EventBridge 트리거 가능
→ Athena가 Parquet 파일로 훨씬 적은 비용으로 쿼리 가능

AWS Lake Formation

Data Lake = 분석용 중앙 데이터 저장소
복잡한 수동 단계(수집, 정제, 이동, 카탈로그) 자동화
정형/비정형 데이터 결합
Source Blueprints: S3, RDS, 관계형/NoSQL DB
Row-level / Column-level Fine-grained Access Control
AWS Glue 위에 구축

중앙 권한 관리

[Athena] ─→ [QuickSight]
[Lake Formation] ← Column-level 접근 제어 설정
→ Athena, QuickSight가 Lake Formation의 권한을 따름
→ 각 서비스별로 별도 접근 제어 불필요 → 중앙 집중식 보안

Amazon Managed Service for Apache Flink

이전 이름: Kinesis Data Analytics for Apache Flink
Java, Scala, SQL로 데이터 스트림 처리
소스: Kinesis Data Streams 또는 Amazon MSK (Kafka)
완전 관리형: 프로비저닝, 병렬 처리, 자동 스케일링, 백업(Checkpoint/Snapshot)
⚠️ Amazon Data Firehose에서 직접 읽기 불가 (Data Streams에서만)

Amazon MSK (Managed Streaming for Apache Kafka)

Kinesis의 대안: AWS에서 완전 관리형 Kafka
Kafka Broker Node + Zookeeper 노드 자동 관리
VPC 내 배포, Multi-AZ (최대 3 AZ)
데이터를 EBS에 원하는 기간만큼 저장
MSK Serverless: 용량 관리 없이 Kafka 실행

Kinesis Data Streams vs. Amazon MSK

항목	Kinesis Data Streams	Amazon MSK
메시지 크기	1 MB 제한	기본 1 MB, 최대 10 MB 설정 가능
구조	Shards	Kafka Topics with Partitions
확장	Shard 분할/병합 가능	파티션 추가만 가능
암호화 (in-flight)	TLS	PLAINTEXT 또는 TLS
암호화 (at-rest)	KMS	KMS

MSK Consumers: Apache Flink, Glue (Streaming ETL), Lambda, EC2/ECS/EKS 앱

빅데이터 수집 파이프라인 아키텍처

[IoT Devices]
      │
      ▼
[Kinesis Data Streams]  ← 실시간 수집
      │
      ▼
[Kinesis Data Firehose] ← Near real-time 전달
      │
      ▼
[S3 (Ingestion Bucket)] ← Raw 데이터 저장
      │         │
      │         ▼ (선택)
      │    [SQS → Lambda] ← 이벤트 기반 처리
      │
      ▼
[Amazon Athena]         ← Serverless SQL 분석
      │
      ▼
[S3 (Reporting Bucket)] ← 분석 결과 저장
      │
      ├──→ [QuickSight]  ← BI 대시보드
      └──→ [Redshift]    ← 데이터 웨어하우스

📌 시험 자주 출제 포인트

포인트	내용
DocumentDB	MongoDB 호환 AWS 구현
Neptune Use Case	소셜 그래프, 사기 탐지, 추천 엔진
Keyspaces	Apache Cassandra 호환
Timestream	시계열 DB, IoT/운영 모니터링
Athena 가격	스캔된 TB당 $5
Athena 비용 절감	Parquet/ORC 포맷 + Partitioning
Athena Federated Query	Lambda Data Source Connector 사용
Athena vs Redshift	간단 S3 쿼리 → Athena / 복잡 Join/집계 → Redshift
Redshift Spectrum	S3 데이터를 Redshift에 로딩 없이 쿼리
Redshift 리전 간 Snapshot	자동 복사 설정 가능
OpenSearch 특징	어떤 필드든 검색 가능 (DynamoDB와 차이)
Glue Catalog	Athena/Redshift Spectrum/EMR이 사용하는 메타데이터 저장소
Lake Formation 특징	Row/Column 레벨 세밀한 접근 제어
Flink 소스	Kinesis Data Streams 또는 MSK (Firehose 아님)
MSK vs Kinesis	MSK: 메시지 크기 최대 10 MB, 파티션 추가만 가능
QuickSight SPICE	In-memory 계산 엔진
QuickSight Users/Groups	QuickSight 내부 개념 (IAM과 별개)
EMR Task Node	주로 Spot Instance 사용

🏛️ AWS Identity & Access Management — Advanced

Sun, 22 Mar 2026 00:00:00 GMT

🏛️ AWS Identity & Access Management — Advanced

AWS Organizations · IAM Conditions · Permission Boundaries

IAM Identity Center · Directory Services · Control Tower

AWS Organizations
IAM Conditions (정책 조건)
IAM Roles vs. Resource-Based Policies
IAM Permission Boundaries (권한 경계)
AWS IAM Identity Center (구: AWS SSO)
Microsoft Active Directory (AD) & AWS Directory Services
AWS Control Tower
전체 Identity 서비스 선택 가이드
📌 시험 자주 출제 포인트

AWS Organizations

Global Service — 여러 AWS 계정을 중앙 관리
Management Account: 최상위 계정 (결제 권한 보유)
Member Accounts: 하나의 Organization에만 소속 가능

주요 장점

항목	내용
Consolidated Billing	모든 계정 비용을 단일 결제 수단으로 통합
Volume Discount	사용량 합산으로 EC2, S3 등 볼륨 할인
Reserved Instance 공유	미사용 RI를 다른 계정에서 공유
API 자동화	API로 계정 자동 생성 가능

OU (Organizational Units)

Root
├── Management Account
├── OU: Production
│     ├── Account A
│     └── Account B
├── OU: Development
│     └── Account C
└── OU: Security
      └── Account D (Log/Audit)

SCP (Service Control Policies)

OU 또는 계정에 적용하는 IAM Policy 형태의 최대 권한 상한선
Management Account에는 적용되지 않음 (항상 Full Admin)
Allow/Deny 모두 명시 가능 — 기본적으로 아무것도 허용하지 않음 (IAM과 동일)
Root에서 각 OU를 거쳐 Target Account까지 명시적 Allow가 있어야 효과 발생

실제 유효 권한 =
  SCP(Org 레벨) AND SCP(OU 레벨) AND IAM Identity Policy

💡 Use Case: 특정 리전 잠금, 특정 서비스 사용 금지, 루트 계정 작업 제한

Tag Policies

Organization 전체에서 태그 표준화 강제
특정 서비스/리소스에 비준수 태깅 작업 방지
태그가 없는 리소스에는 영향 없음
AWS Cost Allocation Tags + ABAC(Attribute-based Access Control)와 연계
비준수 리소스 리포트 생성 + EventBridge로 비준수 태그 모니터링

IAM Conditions (정책 조건)

주요 조건 키:

조건 키	설명	예시
`aws:SourceIp`	API 호출 출처 IP 제한	회사 IP에서만 접근 허용
`aws:RequestedRegion`	API 호출 대상 리전 제한	ap-northeast-2만 허용
`ec2:ResourceTag`	태그 기반 접근 제한	Environment=prod 인스턴스만
`aws:MultiFactorAuthPresent`	MFA 적용 여부	MFA 없으면 차단

S3 버킷 vs. 객체 권한 레벨

Bucket 레벨: arn:aws:s3:::test
  → s3:ListBucket 적용

Object 레벨: arn:aws:s3:::test/*
  → s3:GetObject, s3:PutObject, s3:DeleteObject 적용

aws:PrincipalOrgId

모든 Resource Policy에서 사용 가능
AWS Organization의 멤버 계정에서 오는 요청만 허용

"Condition": {
    "StringEquals": {
        "aws:PrincipalOrgID": "o-xxxxxxxxxx"
    }
}

IAM Roles vs. Resource-Based Policies

Cross-Account 접근 시 두 가지 방법

방법	특징
IAM Role Assume	Role을 Assume하면 원래 권한을 포기하고 Role 권한만 가짐
Resource-based Policy	Principal이 원래 권한을 유지하면서 리소스에 접근

중요한 시나리오:

Account A의 User가 Account A의 DynamoDB를 스캔하고
Account B의 S3에 결과를 저장해야 할 때:

→ IAM Role Assume 불가 (Account A DynamoDB 권한 포기해야 해서)
→ Account B S3에 Resource-based Policy로 Account A User 직접 허용 ← 정답

EventBridge — 서비스별 권한 방식

Target	필요한 권한 방식
Lambda, SNS, SQS, S3, API Gateway	Resource-based Policy
Kinesis Stream, EC2 ASG, SSM Run Command, ECS Task	IAM Role

IAM Permission Boundaries (권한 경계)

User와 Role에만 적용 (Groups에는 불가)
Managed Policy로 IAM 엔티티가 가질 수 있는 최대 권한 상한선 설정

실제 유효 권한 =
  Permission Boundary AND Identity-based Policy

Organizations SCP와 함께 사용 시:

유효 권한 = Organizations SCP AND Permission Boundary AND IAM Policy

Permission Boundary Use Cases

Use Case	설명
비관리자에게 권한 위임	새 IAM User를 만들 수 있되 Permission Boundary 내에서만
개발자 Self-service	자신의 정책을 직접 관리 가능, 단 권한 에스컬레이션(관리자 권한 획득) 방지
특정 User만 제한	Organizations/SCP 대신 단일 User에게만 적용

AWS IAM Identity Center (구: AWS SSO)

Single Sign-On: 한 번 로그인으로 모든 것에 접근
지원 대상:
- AWS Organizations의 모든 계정
- 비즈니스 클라우드 앱 (Salesforce, Box, Microsoft 365)
- SAML 2.0 지원 앱
- EC2 Windows Instance

Identity Providers (IdP)

유형	내용
Built-in	IAM Identity Center 내장 Identity Store
3rd Party	Active Directory (AD), Okta 등

Fine-grained 권한 및 할당

Multi-Account Permissions:

Permission Sets: IAM Policy 컬렉션 → 사용자/그룹에 할당 → AWS 계정 접근 정의

Application Assignments:

많은 SAML 2.0 비즈니스 앱에 SSO 접근
URL, 인증서, 메타데이터 제공

ABAC (Attribute-Based Access Control):

사용자 속성(부서, 직책, 로케일) 기반 세밀한 권한
권한을 한 번 정의 → 속성 변경으로 AWS 접근 수정

Microsoft Active Directory (AD) & AWS Directory Services

Active Directory 개념

Windows Server에서 운영, AD Domain Services 포함
사용자 계정, 컴퓨터, 프린터, 파일 공유, 보안 그룹의 중앙 관리 DB
객체(Object)는 Tree로 구성, Tree 그룹 = Forest

AWS Directory Services 3가지

서비스	설명	On-premises AD
AWS Managed Microsoft AD	AWS에서 자체 AD 운영, MFA 지원	Trust 연결 가능
AD Connector	On-premises AD로 요청 프록시 (Gateway 역할)	사용자는 On-premises에서 관리
Simple AD	AD 호환 관리형 디렉터리	On-premises AD와 연결 불가

IAM Identity Center + AD 통합 방법

방법 1: AWS Managed Microsoft AD 사용 (바로 통합)

[IAM Identity Center] ↔ [AWS Managed Microsoft AD]
→ Out-of-the-box 통합

방법 2: Self-Managed (On-premises) AD 사용

방법 A: Two-way Trust
[IAM Identity Center] ↔ [AWS Managed AD] ↔(Trust)↔ [On-premises AD]

방법 B: AD Connector (더 높은 Latency)
[IAM Identity Center] ↔ [AD Connector] ↔(Proxy)↔ [On-premises AD]

AWS Control Tower

보안/규정 준수 Multi-Account AWS 환경을 빠르게 설정 및 관리
AWS Organizations를 사용하여 계정 생성

주요 장점

항목	내용
자동화	환경 설정 클릭 몇 번으로 자동 완료
Policy 관리	Guardrail로 지속적 정책 관리
규정 준수 모니터링	인터랙티브 대시보드
위반 자동 수정	정책 위반 감지 및 remediation

Guardrails

유형	수단	예시
Preventive (예방)	SCP	특정 리전 외 리소스 생성 금지
Detective (탐지)	AWS Config	태그 없는 리소스 식별

전체 Identity 서비스 선택 가이드

AWS 계정 다수 관리         → AWS Organizations + SCP
한 번 로그인으로 전체 접근  → IAM Identity Center (SSO)
외부 사용자 앱 인증         → Amazon Cognito User Pools
AWS 리소스 직접 접근 권한   → Amazon Cognito Identity Pools
Windows AD 마이그레이션     → AWS Managed Microsoft AD
On-premises AD 연동 프록시  → AD Connector
AD 없는 단순 호환 디렉터리  → Simple AD
Multi-Account 거버넌스       → AWS Control Tower

📌 시험 자주 출제 포인트

포인트	내용
SCP 적용 대상	Management Account 제외 모든 계정/OU
SCP 기본 동작	아무것도 허용하지 않음 (명시적 Allow 필요)
Tag Policy 영향	태그 없는 리소스에는 영향 없음
Permission Boundary 적용	User와 Role만 (Groups 불가)
유효 권한 공식	SCP AND Boundary AND IAM Policy
Cross-Account: Role vs Resource Policy	Role: 원래 권한 포기 / Resource Policy: 원래 권한 유지
EventBridge Lambda/SNS/SQS 권한	Resource-based Policy
EventBridge Kinesis/ECS 권한	IAM Role
IAM Identity Center 구 이름	AWS Single Sign-On (SSO)
IAM Identity Center + AD 바로 통합	AWS Managed Microsoft AD
AD Connector 역할	프록시 (사용자는 On-premises에서 관리)
Simple AD 제한	On-premises AD와 연결 불가
Control Tower 계정 생성 방법	AWS Organizations 사용
Preventive Guardrail 수단	SCP
Detective Guardrail 수단	AWS Config
aws:PrincipalOrgID 조건	Organization 멤버 계정에서 오는 요청만 허용

📨 AWS Integration & Messaging

Sun, 22 Mar 2026 00:00:00 GMT

📨 AWS Integration & Messaging

SQS · SNS · Kinesis · Amazon MQ

애플리케이션 간 결합(Coupling)을 제거하고 독립적인 확장을 가능하게 하는 핵심 서비스

메시징 서비스 개요

서비스	패턴	핵심 특징
SQS	Queue (Pull)	메시지 큐, Consumer가 직접 Pull
SNS	Pub/Sub (Push)	하나의 메시지를 다수 Subscriber에게 Push
Kinesis	Real-time Streaming	실시간 대용량 데이터 스트리밍
Amazon MQ	오픈 프로토콜 브로커	MQTT, AMQP 등 기존 온프레미스 프로토콜 지원

Decoupling의 이유:

Synchronous 통신:  [앱 A] ─직접 호출─→ [앱 B]   ← 한쪽 장애 시 전체 영향
Asynchronous 통신: [앱 A] → [Queue/Topic] → [앱 B] ← 독립적 확장 가능

Amazon SQS (Simple Queue Service)

Standard Queue

항목	내용
Throughput	무제한 (Unlimited)
메시지 보존 기간	기본 4일, 최대 14일
메시지 최대 크기	256 KB
지연 시간	< 10ms (Publish/Receive)
전달 방식	At-least-once delivery (중복 가능)
순서 보장	Best-effort ordering (순서 미보장)

SQS 메시지 흐름

[Producer] ─ SendMessage API ─→ [SQS Queue] ─ Poll ─→ [Consumer]
                                                          │
                                                   처리 완료 후
                                                   DeleteMessage API

Consumer는 한 번에 최대 10개 메시지 수신 (Receive)
메시지는 Consumer가 DeleteMessage API를 호출하기 전까지 Queue에 유지
Consumer는 EC2, Lambda, 온프레미스 서버 등 어디서든 실행 가능

Message Visibility Timeout (메시지 가시성 타임아웃)

Consumer가 메시지를 Poll
    │
    ▼
메시지가 다른 Consumer에게 "비가시(Invisible)" 상태로 전환
    │
    ▼
기본 30초 내에 처리 + DeleteMessage 완료 → 메시지 영구 삭제
처리 실패 / 시간 초과 → 메시지가 다시 Queue에 "가시(Visible)" 상태로 복귀
                          → 다른 Consumer가 재처리 (중복 처리 가능)

항목	내용
기본값	30초
타임아웃 연장 방법	ChangeMessageVisibility API 호출
너무 낮으면	처리 시간 초과로 중복 메시지 발생
너무 높으면	Consumer 크래시 시 재처리까지 오랜 대기

Long Polling (롱 폴링)

Consumer가 Queue에 메시지가 없을 때 **일정 시간 대기(Wait)**하여 메시지 도착 시 즉시 수신
Short Polling (기본): 메시지 없으면 즉시 빈 응답 → API 호출 낭비
Long Polling 장점:
- SQS에 대한 API 호출 수 감소 → 비용 절감
- 지연 시간(Latency) 감소
- 애플리케이션 효율 향상
대기 시간: 1초 ~ 20초 (20초 권장)
설정: Queue 레벨 또는 API 레벨 (WaitTimeSeconds 파라미터)

💡 Long Polling이 Short Polling보다 항상 권장됨

SQS 보안

항목	내용
In-flight 암호화	HTTPS API
At-rest 암호화	AWS KMS
Client-side 암호화	클라이언트 직접 처리
접근 제어	IAM Policies
SQS Access Policy	S3 Bucket Policy 형태 — Cross-Account 접근, SNS/S3 등 다른 서비스의 쓰기 허용 시 사용

SQS + Auto Scaling Group (ASG) 패턴

[요청]
  │
  ▼
[Frontend App (ASG)] ─ SendMessage ─→ [SQS Queue]
                                           │
                                     CloudWatch Metric
                                     (ApproximateNumberOfMessages)
                                           │ Queue 길이 임계값 초과
                                           ▼
                                     [CloudWatch Alarm]
                                           │
                                           ▼
                                     [Backend ASG Scale Out]
                                           │
                                     ReceiveMessage ─→ DB Insert

활용 시나리오:

Frontend와 Backend를 완전히 분리(Decouple)
Backend 처리 속도보다 요청이 빠를 때 SQS를 Buffer로 활용 → 데이터 유실 없음
ApproximateNumberOfMessages CloudWatch Metric → ASG Scaling 트리거

Amazon SQS - FIFO Queue

항목	Standard Queue	FIFO Queue
순서	Best-effort (미보장)	엄격한 FIFO 보장
중복	가능 (at-least-once)	정확히 1회 전송 (Exactly-once)
Throughput	무제한	배치 없음: 300 msg/s / 배치: 3,000 msg/s
중복 제거	-	Deduplication ID 기반
순서 그룹	-	Message Group ID (필수 파라미터)

📌 Message Group ID: 같은 Group ID 내 메시지는 순서 보장. 서로 다른 Group은 병렬 처리 가능.

Amazon SNS (Simple Notification Service)

Pub/Sub 패턴

[Event Producer]
      │
      ▼
[SNS Topic]  ← 메시지 1회 발행
   │  │  │
   ▼  ▼  ▼
[Sub1] [Sub2] [Sub3] ...  ← 모든 Subscriber가 메시지 수신

항목	내용
Subscriber 수	토픽당 최대 12,500,000개
Topic 수	계정당 최대 100,000개
데이터 지속성	❌ 전달 실패 시 메시지 소멸

지원 Subscriber 유형:

SQS, Lambda, Kinesis Data Firehose, HTTP/HTTPS Endpoint
Email, SMS, Mobile Push Notification

SNS 보안

SQS와 동일한 구조:

In-flight: HTTPS / At-rest: KMS / Client-side: 고객 직접 처리
IAM Policies + SNS Access Policy (Cross-Account, S3 등 서비스가 SNS에 쓰기 허용)

SNS Message Filtering (메시지 필터링)

JSON Policy로 각 Subscription이 수신할 메시지를 필터링
필터가 없는 Subscription → 모든 메시지 수신

[SNS Topic: 주문 이벤트]
      │
      ├── [SQS: 주문완료 큐]    ← Filter: {"state": ["placed"]}
      ├── [SQS: 취소 큐]       ← Filter: {"state": ["cancelled"]}
      └── [Lambda: 전체 처리]   ← Filter 없음 (모든 메시지 수신)

SNS + SQS Fan-Out 패턴

문제: S3 Event는 하나의 Rule에 하나의 대상만 설정 가능 해결: SNS Topic을 중간에 두고 여러 SQS Queue로 Fan-Out

[S3 Event] ─→ [SNS Topic] ─→ [SQS Queue A] → 썸네일 생성
                          ─→ [SQS Queue B] → 메타데이터 저장
                          ─→ [SQS Queue C] → 감사 로그

Fan-Out 장점:

완전한 Decoupling, 데이터 유실 없음
SQS: 데이터 영속성, 지연 처리, 재시도 가능
나중에 Subscriber 추가 가능 (기존 아키텍처 변경 없이)
Cross-Region Delivery 지원 (다른 리전의 SQS Queue에 전달 가능)

SNS → Kinesis Data Firehose → S3 패턴

[서비스] → [SNS Topic] → [Kinesis Data Firehose] → [S3 / Redshift / OpenSearch]

SNS가 직접 지원하지 않는 대상(S3 등)에 데이터를 전달할 때 Firehose를 중간 단계로 활용.

SNS FIFO Topic

SQS FIFO와 유사한 기능:
- Message Group ID 기반 순서 보장
- Deduplication ID 또는 Content-Based Deduplication으로 중복 제거
Subscriber: SQS Standard 또는 SQS FIFO Queue
제한된 Throughput

SNS FIFO + SQS FIFO = Fan-Out + Ordering + Deduplication 동시 달성

Amazon Kinesis

Kinesis 서비스 구성

서비스	역할
Kinesis Data Streams	실시간 스트리밍 데이터 수집 및 저장
Amazon Data Firehose	스트리밍 데이터를 S3/Redshift/OpenSearch 등으로 전달
Kinesis Data Analytics	SQL로 스트리밍 데이터 실시간 분석

Kinesis Data Streams

데이터 흐름:

[Producers: App, IoT, Click Stream] → [Kinesis Data Streams] → [Consumers: Lambda, ECS, App]

항목	내용
데이터 보존	기본 24시간, 최대 365일
Replay	✅ 데이터 재처리(Replay) 가능
삭제	❌ 만료 전 삭제 불가 (Immutable)
메시지 크기	최대 10 MiB (일반적으로 소규모 실시간 데이터)
순서 보장	동일 Partition ID 내에서 순서 보장
암호화	At-rest: KMS / In-flight: HTTPS

Kinesis Data Streams - Capacity Modes

모드	Provisioned	On-Demand
용량 설정	Shard 수 직접 지정	자동
입력 처리량	Shard당 1 MB/s (or 1,000 records/s)	기본 4 MB/s (or 4,000 records/s)
출력 처리량	Shard당 2 MB/s	자동
스케일링	수동	최근 30일 피크 기반 자동 확장
과금	Shard 시간당	시간당 + 데이터 GB당

Amazon Data Firehose (구: Kinesis Data Firehose)

완전 관리형, Serverless, 자동 스케일링
Near Real-Time 전달 (버퍼링으로 인한 약간의 지연)
사용한 만큼 과금 (Pay for what you use)

지원 대상 (Destinations):

AWS: Amazon S3, Amazon Redshift, Amazon OpenSearch Service
3rd Party: Splunk, MongoDB, Datadog, NewRelic
Custom: HTTP Endpoint

데이터 변환:

Lambda로 Custom 변환 (예: CSV → JSON)
Parquet/ORC 변환, gzip/snappy 압축

Kinesis Data Streams vs. Amazon Data Firehose

항목	Kinesis Data Streams	Amazon Data Firehose
목적	스트리밍 데이터 수집/저장	스트리밍 데이터 전달/로드
실시간성	Real-time	Near Real-time (버퍼링)
관리	Producer/Consumer 코드 직접 작성	완전 관리형
스케일링	Provisioned 또는 On-Demand	자동 스케일링
데이터 저장	✅ 최대 365일	❌ 저장 없음
Replay	✅ 가능	❌ 불가

SQS vs. SNS vs. Kinesis — 최종 비교

항목	SQS	SNS	Kinesis
방식	Pull (Consumer가 가져감)	Push (Subscriber에게 전달)	Pull / Enhanced Fan-Out (Push)
데이터 지속성	✅ (소비 후 삭제)	❌ (미전달 시 소멸)	✅ (최대 365일)
Replay	❌	❌	✅
Consumer/Subscriber 수	Worker 수 제한 없음	12,500,000 Subscribers	Shard별 분배
순서 보장	FIFO Queue만	SNS FIFO Topic만	Partition ID별
처리량 설정	불필요 (자동)	불필요 (자동)	Shard 직접 관리 (Provisioned) 또는 On-Demand
Use Case	작업 큐, 비동기 처리	이벤트 알림, Fan-Out	실시간 대용량 스트리밍, 분석

Amazon MQ

왜 Amazon MQ인가?

SQS/SNS는 AWS 독점(Cloud-Native) 프로토콜 사용
기존 온프레미스 애플리케이션은 오픈 표준 프로토콜 사용:
- MQTT, AMQP, STOMP, OpenWire, WSS 등
클라우드 이전 시 애플리케이션 재설계 없이 기존 프로토콜 그대로 사용 가능

Amazon MQ 특성

항목	내용
지원 브로커	RabbitMQ, ActiveMQ
스케일	SQS/SNS만큼 확장되지 않음 (서버 기반)
고가용성	Multi-AZ with Failover
기능	Queue 기능(~SQS) + Topic 기능(~SNS) 동시 지원

📌 선택 기준: 새로운 애플리케이션 → SQS/SNS 사용. 기존 온프레미스 Message Broker 마이그레이션 → Amazon MQ 사용.

📌 시험 자주 출제 포인트 총정리

포인트	내용
SQS 메시지 최대 크기	256 KB
SQS 기본 보존 기간	4일, 최대 14일
SQS 한 번에 수신 최대 메시지 수	10개
Visibility Timeout 기본값	30초
Visibility Timeout 연장 방법	ChangeMessageVisibility API
Long Polling 대기 시간	1~20초 (20초 권장)
FIFO Throughput	배치 없음: 300 msg/s, 배치: 3,000 msg/s
FIFO 중복 제거	Deduplication ID
FIFO 순서 그룹	Message Group ID (필수)
SNS 최대 Subscriber 수	12,500,000개/토픽
SNS 데이터 지속성	❌ 미전달 시 소멸
SNS Filter Policy 없으면	모든 메시지 수신
Fan-Out 패턴	SNS → 여러 SQS
S3 Event → 여러 대상	SNS Fan-Out 사용
Kinesis 데이터 보존	기본 24h, 최대 365일
Kinesis 메시지 삭제	불가 (만료 시까지 유지)
Kinesis 순서 보장 단위	Partition ID
Provisioned Mode 입력	Shard당 1 MB/s
Provisioned Mode 출력	Shard당 2 MB/s
Kinesis Replay	✅ 가능 (SQS/SNS는 불가)
Data Firehose 실시간성	Near Real-time (버퍼링)
Data Firehose Replay	❌ 불가
Amazon MQ 지원 브로커	RabbitMQ, ActiveMQ
Amazon MQ 선택 기준	기존 오픈 프로토콜(MQTT, AMQP 등) 마이그레이션 시
SQS ASG 트리거 지표	ApproximateNumberOfMessages

📚 참고 자료

🔍 AWS Monitoring, Troubleshooting & Audit

Sun, 22 Mar 2026 00:00:00 GMT

🔍 AWS Monitoring, Troubleshooting & Audit

CloudWatch · EventBridge · CloudTrail · AWS Config

리소스 상태 모니터링, API 감사, 규정 준수 관리의 3대 축

세 서비스 한눈에 비교

서비스	핵심 역할	주요 질문
CloudWatch	성능 모니터링 + 로그 + 알람	"지금 CPU가 얼마나 되나?"
CloudTrail	API 호출 감사 기록	"누가 언제 어떤 API를 호출했나?"
AWS Config	설정 변경 기록 + 규정 준수 평가	"리소스 설정이 어떻게 바뀌었나? 규정 준수하나?"

📌 리소스 삭제 원인 조사 → CloudTrail 먼저 확인

Amazon CloudWatch

CloudWatch Metrics

AWS 모든 서비스에서 지표(Metric) 제공
Namespace 단위로 지표 그룹화
Dimension: 지표의 속성 (Instance ID, 환경 등), 지표당 최대 30개 Dimension
지표에 Timestamp 포함
Custom Metrics 생성 가능 (예: RAM 사용률 — 기본 제공 안 됨)

CloudWatch Metric Streams

CloudWatch Metrics를 Near real-time으로 대상에 지속 스트리밍
대상: Kinesis Data Firehose (→ S3, Redshift 등)
3rd party: Datadog, Dynatrace, New Relic, Splunk, Sumo Logic

CloudWatch Logs

항목	내용
Log Group	임의 이름, 보통 애플리케이션 단위
Log Stream	인스턴스/로그파일/컨테이너 단위
만료 정책	영구 보존 ~ 1일~10년 설정 가능
기본 암호화	활성화됨 (KMS 커스텀 키 설정 가능)

CloudWatch Logs 전송 대상:

Amazon S3 (Export)
Kinesis Data Streams
Kinesis Data Firehose
AWS Lambda
OpenSearch

주요 Log Sources:

SDK, CloudWatch Logs Agent, CloudWatch Unified Agent
Elastic Beanstalk, ECS, Lambda, VPC Flow Logs, API Gateway, CloudTrail, Route 53

CloudWatch Logs Agent vs. Unified Agent

항목	CloudWatch Logs Agent	CloudWatch Unified Agent
버전	구버전	신버전 (권장)
로그 전송	CloudWatch Logs만	CloudWatch Logs
시스템 지표	❌	✅ (RAM, Process 등 추가 수집)
설정 관리	-	SSM Parameter Store 중앙 관리

Unified Agent 수집 지표: CPU, Disk metrics/IO, RAM, Netstat, Processes, Swap Space → EC2 기본 Out-of-the-box Metrics(Disk, CPU, Network)보다 상세한 수준

CloudWatch Logs Insights

CloudWatch Logs에서 SQL 유사 쿼리로 로그 분석
AWS 서비스 및 JSON 로그에서 필드 자동 검색
여러 Log Group, 여러 계정 동시 쿼리 가능
쿼리 저장 및 Dashboard 추가 가능
⚠️ Query Engine — 실시간 엔진 아님 (과거 데이터만 조회)

CloudWatch Logs S3 Export

로그 데이터를 S3로 내보내기 (API: CreateExportTask)
데이터 가용까지 최대 12시간 소요
Near real-time 또는 실시간 아님 → 실시간이 필요하면 Subscriptions Filter 사용

CloudWatch Logs Subscriptions

실시간 로그 이벤트 처리 및 분석용
대상: Kinesis Data Streams, Kinesis Data Firehose, Lambda
Subscription Filter: 특정 조건의 로그만 대상으로 전달
Cross-Account Subscription: 다른 계정의 KDS/KDF로 전달 가능

CloudWatch Alarms

Alarm States:

OK / INSUFFICIENT_DATA / ALARM

Alarm Targets:

EC2 Instance: 중지/종료/재부팅/복구
Auto Scaling Action 트리거
SNS Topic 알림 → 이를 통해 사실상 모든 것 가능

Composite Alarms:

여러 알람 상태를 AND/OR 조건으로 조합
"알람 노이즈(Alarm Noise)" 감소에 효과적

EC2 Instance Recovery:

StatusCheckFailed_System Alarm → 복구 실행
복구 후: Private/Public/Elastic IP, Metadata, Placement Group 동일 유지

알람 테스트 (CLI):

aws cloudwatch set-alarm-state \
  --alarm-name "myalarm" \
  --state-value ALARM \
  --state-reason "testing purposes"

CloudWatch 특화 Insights 서비스

서비스	대상	기능
Container Insights	ECS, EKS, EC2 Kubernetes, Fargate	컨테이너 메트릭 + 로그 수집 (EKS: 컨테이너화된 CW Agent 필요)
Lambda Insights	Lambda (Lambda Layer 형태)	Cold Start, 시스템 메트릭, 진단 정보
Contributor Insights	VPC Flow Logs, DNS 등 모든 CW Logs	Top-N 기여자 파악 (예: 상위 IP, 최다 오류 URL)
Application Insights	EC2 기반 앱 (Java, .NET 등) + AWS 서비스	문제 자동 감지 대시보드, SageMaker 기반

CloudWatch Network Synthetic Monitor

On-premises ↔ AWS 애플리케이션 간 네트워크 성능 문제 감지
Agent 설치 불필요
ICMP/TCP 트래픽 테스트 (Direct Connect 또는 Site-to-Site VPN 경유)
패킷 손실, 지연, Jitter 측정 → CloudWatch Metrics로 발행

Amazon EventBridge (구: CloudWatch Events)

핵심 기능

기능	설명
Cron Jobs	특정 시간/주기 기반 스케줄 실행
Event Pattern	특정 이벤트 발생 시 규칙 트리거
대상	Lambda, SQS, SNS, KDS, Step Functions, ECS Task, API Gateway, Batch 등

Event Bus 유형

유형	설명
Default Event Bus	AWS 서비스 이벤트 수신
Partner Event Bus	SaaS 파트너 이벤트 (Zendesk, Datadog 등)
Custom Event Bus	커스텀 앱 이벤트

Event Bus는 Resource-based Policy로 다른 계정에 공유 가능
이벤트 아카이브(Archive) + Replay 가능

Schema Registry

EventBridge가 Event Bus의 이벤트 스키마를 자동 분석/추론
스키마 기반 애플리케이션 코드 자동 생성 (이벤트 구조 사전 파악)
스키마 버저닝 지원

EventBridge Resource-based Policy

특정 Event Bus의 권한 관리
다른 계정/리전의 이벤트 허용/거부
Use Case: AWS Organization 전체 이벤트를 단일 계정/리전으로 집계

EventBridge 보안 (Target 별 권한)

Target 유형	권한 방식
Lambda, SNS, SQS, S3, API Gateway	Resource-based Policy
Kinesis Streams, EC2 ASG, SSM Run Command, ECS Task	IAM Role

AWS CloudTrail

AWS 계정 내 모든 API 호출 기록 (기본 활성화)
콘솔, SDK, CLI, AWS 서비스를 통한 호출 포함
로그 대상: CloudWatch Logs 또는 S3
Trail은 모든 리전 또는 단일 리전 적용 가능

CloudTrail 이벤트 유형

유형	기본 기록	설명
Management Events	✅	리소스 작업 (IAM, EC2 서브넷 생성, 로깅 설정 등)
Data Events	❌ (고볼륨)	S3 Object 레벨 작업 (GetObject, DeleteObject 등), Lambda 실행
CloudTrail Insights Events	별도 활성화	비정상적인 활동 자동 감지

CloudTrail Insights

비정상 활동 감지:
- 부정확한 리소스 프로비저닝
- 서비스 한도 도달
- IAM 작업 급증
- 주기적 유지보수 누락
정상 Management Event로 Baseline 생성 → Write Event 지속 분석
이상 탐지 결과: CloudTrail 콘솔 + S3 이벤트 + EventBridge 이벤트 생성

CloudTrail 이벤트 보존

기본 보존: 90일
90일 이상 보존: S3 로그 저장 + Athena 분석 조합

CloudTrail + EventBridge 패턴

[사용자 API 호출]
      │
      ▼
[CloudTrail 기록]
      │
      ▼
[EventBridge 이벤트]
      │
      ▼
[SNS 알림 또는 자동화]

예시:

DeleteTable (DynamoDB) → CloudTrail → EventBridge → SNS 경보
AssumeRole (IAM) → CloudTrail → EventBridge → SNS 경보
AuthorizeSecurityGroupIngress (EC2) → CloudTrail → EventBridge → SNS 경보

AWS Config

리소스 설정 변경 기록 및 규정 준수(Compliance) 평가
리전별 서비스 (리전 간 집계 가능)
설정 데이터를 S3에 저장 → Athena로 분석 가능

답할 수 있는 질문들:

SSH가 제한 없이 열려 있는 Security Group이 있나?
Public Access가 열린 S3 Bucket이 있나?
ALB 설정이 시간에 따라 어떻게 바뀌었나?

Config Rules

AWS Managed Rules: 75개 이상 기본 제공
Custom Rules: Lambda 기반 커스텀 평가 로직
트리거: 설정 변경 시 또는 주기적 평가
⚠️ Config Rules는 예방(Deny) 기능 없음 — 규정 준수 평가만

가격: Free Tier 없음, 리전당 설정 항목 $0.003, 규칙 평가 $0.001

Config 리소스 뷰

특정 리소스의 규정 준수 변화 타임라인
특정 리소스의 설정 변경 타임라인
특정 리소스 관련 CloudTrail API 호출 타임라인

Config Rules — Remediations (자동 수정)

비준수 리소스를 SSM Automation Document로 자동 수정
AWS Managed Automation Document 또는 Custom Document (Lambda 호출 가능)
Remediation Retry 설정 가능 (자동 수정 후에도 비준수 시)

예시:

IAM Access Key 만료 (NON_COMPLIANT)
    → Auto Remediation: AWSConfigRemediation-RevokeUnusedIAMUserCredentials

Config Rules — Notifications

EventBridge: 비준수 리소스 발생 시 트리거 → 자동화
SNS: 설정 변경 + 규정 준수 상태 알림 (SNS Filtering 또는 클라이언트 측 필터 활용)

CloudWatch vs. CloudTrail vs. Config 비교

항목	CloudWatch	CloudTrail	Config
목적	성능 모니터링 + 알람 + 로그	API 호출 감사 기록	설정 변경 기록 + 규정 준수
질문	"CPU가 높은가?"	"누가 API를 호출했는가?"	"설정이 바뀌었는가? 규정에 맞는가?"
범위	리전 (글로벌 집계 가능)	글로벌 서비스	리전 (집계 가능)

ELB 관점에서 세 서비스 역할

서비스	ELB에서의 역할
CloudWatch	Incoming Connection 모니터링, 에러 코드 비율 시각화, 성능 대시보드
Config	Security Group 규칙 추적, 설정 변경 이력, SSL 인증서 상시 부착 여부 규정 준수
CloudTrail	API 호출 추적 (누가 LB 설정을 변경했는가?)

📌 시험 자주 출제 포인트

포인트	내용
EC2 기본 미제공 지표	RAM (Unified Agent로 추가 수집 필요)
Custom Metric	RAM, 프로세스 등 직접 푸시 필요
CW Logs → S3 Export	API: CreateExportTask, 최대 12시간 소요 (Near real-time 아님)
CW Logs 실시간 전송	Subscription Filter → KDS/KDF/Lambda
Cross-Account Logs	Cross-Account Subscription 사용
CW Alarm 테스트	`set-alarm-state` CLI 명령으로 강제 ALARM
Composite Alarm	AND/OR 조건 조합, 알람 노이즈 감소
EC2 Recovery	동일 Private/Public/Elastic IP, Metadata, Placement Group 유지
Container Insights + EKS	컨테이너화된 CW Agent 필요
Lambda Insights 배포	Lambda Layer 형태
Contributor Insights	Top-N 기여자 파악
EventBridge Target 권한	Lambda/SNS/SQS: Resource-based Policy / Kinesis/ECS: IAM Role
EventBridge Replay	✅ 아카이브된 이벤트 재생 가능
CloudTrail 기본 보존	90일
90일 이상 CloudTrail 보존	S3 + Athena
CloudTrail Data Events	기본 비활성화 (고볼륨)
CloudTrail Insights	비정상 활동 → CloudTrail 콘솔 + S3 + EventBridge
리소스 삭제 원인 조사	CloudTrail 먼저
Config Rules 기능	규정 준수 평가만 (Deny/차단 불가)
Config Auto Remediation	SSM Automation Document
Config 서비스 범위	리전별 (리전 간 집계 가능)

⚡ AWS Serverless

Sun, 22 Mar 2026 00:00:00 GMT

⚡ AWS Serverless

Lambda · API Gateway · DynamoDB · Step Functions · Cognito

서버를 프로비저닝하지 않고 코드와 함수만 배포하는 패러다임

Serverless 개요

Serverless ≠ 서버가 없음 — 서버를 관리/프로비저닝하지 않는 것

AWS Serverless 서비스

AWS Lambda, DynamoDB, Amazon Cognito, API Gateway

Amazon S3, SNS, SQS, Kinesis Data Firehose

Aurora Serverless, Step Functions, Fargate

AWS Lambda

EC2 vs. Lambda

항목	EC2	Lambda
서버	직접 프로비저닝	관리 불필요
실행 방식	항상 실행 중	On-demand (요청 시 실행)
시간 제한	없음	최대 15분 (900초)
스케일링	수동 또는 ASG	자동
과금	실행 여부 무관	요청 수 + 실행 시간

Lambda 제한 (Limits) — per Region

📌 시험 빈출 수치

실행 (Execution):

항목	제한
Memory	128 MB ~ 10 GB (1 MB 단위)
Max Execution Time	900초 (15분)
Environment Variables	4 KB
/tmp 디스크	512 MB ~ 10 GB
Concurrent Executions	1,000 (증가 요청 가능)

배포 (Deployment):

항목	제한
압축 .zip 크기	50 MB
비압축 코드 + 의존성	250 MB
Environment Variables	4 KB

💡 RAM을 늘리면 CPU와 네트워크 성능도 함께 향상됨.

Lambda 지원 런타임

Node.js, Python, Java, C#/PowerShell, Ruby
Custom Runtime API: Rust, Golang 등
Lambda Container Image: Lambda Runtime API를 구현한 컨테이너 이미지 사용 가능
- 임의의 Docker Image는 ECS/Fargate 권장 (Lambda Container Image와 다름)

Lambda 가격

과금 항목	내용
요청 수	첫 1,000,000 req 무료 / 이후 $0.20 / 100만 req
실행 시간	월 400,000 GB-seconds 무료 / 이후 $1.00 / 600,000 GB-sec

400,000 GB-sec = 1GB RAM → 400,000초 / 128MB RAM → 3,200,000초

Lambda Concurrency & Throttling (동시 실행 및 조절)

계정당 기본 동시 실행 한도: 1,000개
        │
        ▼
Throttle 발생 시:
  ├── Synchronous 호출 → 429 ThrottleError 즉시 반환
  └── Asynchronous 호출 → 자동 재시도 (최대 6시간, 지수 백오프)
                          → 최종 실패 시 DLQ(Dead Letter Queue)

Reserved Concurrency (예약 동시 실행):

특정 함수에 동시 실행 상한을 예약 설정
다른 함수가 한도를 다 쓰지 못하도록 보호
여러 Lambda가 같은 계정 한도를 공유하므로 한 함수가 폭발적 요청 시 다른 함수 Throttle 가능

Cold Start & Provisioned Concurrency

Cold Start 문제:

새 인스턴스 시작 → 코드 로드 + Init 코드 실행 (handler 외부)
→ 첫 요청의 지연 시간 높음 (대형 패키지/SDK 사용 시 더 심각)

Provisioned Concurrency:

함수 호출 전에 미리 인스턴스를 워밍업 → Cold Start 없음
Application Auto Scaling으로 스케줄 또는 목표 활용률 기반 관리

Lambda SnapStart (Java / Python / .NET)

최대 10배 성능 향상 (추가 비용 없음)
새 버전 배포 시 Lambda가 함수를 초기화하고 메모리/디스크 Snapshot 저장
이후 호출은 저장된 Snapshot에서 즉시 시작 → Init 과정 생략

SnapStart 비활성화: invoke → [Init → invoke → shutdown]
SnapStart 활성화:   invoke → [snapshot에서 복원 → invoke → shutdown]

Lambda Networking (VPC 연동)

기본 동작 (Default):

Lambda는 AWS 소유 VPC에서 실행
→ 고객 VPC의 RDS, ElastiCache, 내부 ELB에 접근 불가

Lambda in VPC:

Lambda → ENI(Elastic Network Interface) 생성 → 지정 Subnet에 연결
→ VPC 내 리소스(RDS, ElastiCache 등) 접근 가능

VPC ID, Subnet, Security Group 지정 필요

Lambda + RDS Proxy:

[많은 Lambda 호출] → [RDS Proxy] → [RDS/Aurora]
(직접 연결 시 DB Connection 과다)  (Connection Pooling으로 보호)

RDS Proxy는 Public 접근 불가 → Lambda도 반드시 VPC 내 배포 필요
IAM 인증 강제 + Secrets Manager 연동

Lambda에서 RDS/Aurora 호출 (Invoke Lambda from DB)

RDS for PostgreSQL, Aurora MySQL에서 DB 내 이벤트 기반 Lambda 호출 가능
예: 신규 사용자 INSERT → Lambda → SES로 환영 이메일 발송
DB 인스턴스가 Lambda에 아웃바운드 접근 권한 필요 (Public / NAT GW / VPC Endpoint 중 하나)
DB Instance에 Lambda 호출 권한 필요 (Lambda Resource-based Policy + IAM Policy)

RDS Event Notifications

DB 인스턴스 자체의 이벤트 알림 (데이터 변경 아님)
이벤트 카테고리: DB Instance, Snapshot, Parameter Group, Security Group, RDS Proxy, Custom Engine Version
Near real-time (최대 5분 지연)
SNS 또는 EventBridge로 알림 전송

CloudFront Functions vs. Lambda@Edge

Edge에서 코드를 실행하여 CloudFront 요청/응답을 동적으로 처리.

항목	CloudFront Functions	Lambda@Edge
런타임	JavaScript만	Node.js, Python
처리량	수백만 req/s	수천 req/s
최대 실행 시간	< 1ms	5~10초
메모리	2 MB	128 MB ~ 10 GB
패키지 크기	10 KB	1 MB ~ 50 MB
트리거	Viewer Req/Res	Viewer/Origin Req/Res (4가지)
네트워크/파일 접근	❌	✅
요청 Body 접근	❌	✅
가격	더 저렴 (Free Tier 있음)	Free Tier 없음
코드 작성 위치	CloudFront 내	us-east-1 리전

CloudFront Functions Use Cases: Cache Key 정규화, Header 조작, URL 리다이렉트, JWT 인증 Lambda@Edge Use Cases: 복잡한 로직, 외부 API 호출, 파일시스템 접근, 3rd Party 라이브러리

Amazon DynamoDB

특징

NoSQL, Serverless, 완전 관리형, Multi-AZ 복제
초당 수백만 req, 수조 개 행, 수백 TB 스토리지
Single-digit millisecond 지연 시간
IAM 통합 보안, 자동 스케일링
Standard / Infrequent Access (IA) Table Class

기본 구조

항목	내용
Primary Key	생성 시 결정 (변경 불가)
Item 최대 크기	400 KB
Attribute	언제든 추가 가능, null 허용 → Schema 유연성
지원 타입	Scalar(String, Number, Binary, Boolean, Null), Document(List, Map), Set

Read/Write Capacity Modes

항목	Provisioned Mode	On-Demand Mode
용량 설정	RCU/WCU 미리 지정	자동
스케일링	Auto-scaling 가능	자동
비용	프로비저닝 용량 과금	실제 사용량 과금 (더 비쌈)
적합 워크로드	예측 가능한 트래픽	예측 불가, 급격한 Spike

DynamoDB Accelerator (DAX)

DynamoDB를 위한 완전 관리형 인메모리 캐시
Microsecond 지연 시간 (캐시된 데이터)
기존 DynamoDB API와 호환 → 애플리케이션 코드 변경 불필요
기본 TTL: 5분

DAX vs. ElastiCache:

DAX	ElastiCache
개별 Object, Query/Scan 캐시	집계 결과(Aggregation) 캐시
DynamoDB 전용	범용 캐시

DynamoDB Streams

DynamoDB 테이블의 Item 변경(CUD) 이벤트 스트림.

항목	DynamoDB Streams	Kinesis Data Streams
보존 기간	24시간	최대 365일
Consumer 수	제한적	많음
처리 방법	Lambda Triggers, KCL Adapter	Lambda, Firehose, Analytics, EMR 등

Use Cases: 실시간 반응, 크로스 리전 복제, Lambda 트리거

DynamoDB Global Tables

Active-Active 복제 (모든 리전에서 Read/Write 가능)
다중 리전에서 저지연 접근
DynamoDB Streams 활성화 필수

DynamoDB TTL (Time To Live)

만료 Timestamp 기반 자동 Item 삭제
Use Cases: 세션 데이터, 규정 준수, 오래된 데이터 정리

DynamoDB 백업

방식	내용
PITR (자동 백업)	최대 35일, 복원 시 새 테이블 생성
On-Demand Backup	명시적 삭제 전까지 유지, 성능 영향 없음, AWS Backup으로 Cross-Region 가능

DynamoDB ↔ S3 연동

항목	Export to S3	Import from S3
전제 조건	PITR 활성화 필수	-
포맷	DynamoDB JSON / ION	CSV / DynamoDB JSON / ION
용량 소비	Read Capacity 미사용	Write Capacity 미사용
결과	기존 테이블 유지	새 테이블 생성

Amazon API Gateway

항목	내용
인프라 관리	불필요 (Lambda + API Gateway = 완전 Serverless)
주요 기능	API 버저닝, 환경 관리(dev/prod), 인증/인가, Rate Limiting, API Key, 캐싱, SDK 생성
지원 프로토콜	REST, HTTP, WebSocket

API Gateway Endpoint Types

유형	설명	특징
Edge-Optimized (기본)	CloudFront Edge Location 경유	글로벌 클라이언트, API는 단일 리전
Regional	동일 리전 클라이언트용	수동으로 CloudFront 결합 가능
Private	VPC 내부에서만 접근	Interface VPC Endpoint (ENI) + Resource Policy 필요

API Gateway 인증

방법	Use Case
IAM Roles	내부 애플리케이션
Cognito	외부 사용자 (모바일 앱 등)
Custom Authorizer	자체 인증 로직 (Lambda 기반)

ACM (AWS Certificate Manager) 연동:

Edge-Optimized: 인증서는 us-east-1에 있어야 함
Regional: 인증서는 API Gateway와 같은 리전에 있어야 함
Route 53에 CNAME 또는 A-alias 레코드 설정 필요

AWS Step Functions

Lambda 함수들을 시각적 워크플로우로 오케스트레이션
기능: 순차/병렬 실행, 조건 분기, 타임아웃, 에러 핸들링
EC2, ECS, 온프레미스, API Gateway, SQS, DynamoDB 등과 통합
Human Approval (사람의 승인 단계) 구현 가능
Use Cases: 주문 처리, 데이터 파이프라인, 웹 애플리케이션 워크플로우

Amazon Cognito

목적

외부 사용자(웹/모바일 앱 사용자)에게 AWS 리소스에 대한 Identity 부여

📌 Cognito vs. IAM: 수백 명의 외부 사용자, 모바일 사용자, SAML 인증 → Cognito

Cognito User Pools (CUP)

앱 사용자를 위한 Serverless 사용자 DB
기능: 이메일/비밀번호 로그인, 비밀번호 재설정, 이메일/전화 인증, MFA
Federated Identity: Facebook, Google, SAML 계정으로 로그인
API Gateway 및 ALB와 통합

Cognito Identity Pools (Federated Identities)

사용자에게 임시 AWS 자격증명(Temporary AWS Credentials) 발급
AWS 서비스에 직접 접근 가능 (S3, DynamoDB 등)
사용자 소스: Cognito User Pools, 3rd party 로그인
IAM Policy를 Cognito에서 정의 (user_id 기반 세밀한 권한 제어 가능)
인증/미인증 사용자별 기본 IAM Role 설정 가능

CUP vs. Identity Pools

항목	User Pools	Identity Pools
목적	로그인/인증	AWS 리소스 접근 권한 부여
결과물	JWT Token	임시 AWS 자격증명
통합	API Gateway, ALB	S3, DynamoDB 직접 접근

📌 시험 자주 출제 포인트

포인트	내용
Lambda 최대 실행 시간	15분 (900초)
Lambda 메모리 범위	128 MB ~ 10 GB
Lambda 기본 동시 실행 한도	1,000개
Throttle (Sync)	429 ThrottleError
Throttle (Async)	자동 재시도 최대 6시간, 지수 백오프
Cold Start 해결	Provisioned Concurrency
SnapStart 지원 런타임	Java, Python, .NET
Lambda + RDS Proxy	Lambda는 VPC 내 배포 필수
CloudFront Functions 실행 시간	< 1ms
Lambda@Edge 실행 시간	5~10초
CloudFront Functions 트리거	Viewer Req/Res만
Lambda@Edge 트리거	Viewer/Origin Req/Res (4가지)
DynamoDB Item 최대 크기	400 KB
DAX 지연 시간	Microsecond
DAX 기본 TTL	5분
DAX vs ElastiCache	DAX: 개별 Object / ElastiCache: 집계 결과
DynamoDB Streams 보존	24시간
Global Tables 전제	DynamoDB Streams 활성화 필수
Global Tables 방식	Active-Active
DynamoDB PITR 최대	35일
Export to S3 전제	PITR 활성화 필수
Import from S3 결과	새 테이블 생성
API Gateway Edge-Optimized ACM	us-east-1 인증서
Cognito User Pools 통합	API Gateway + ALB
Cognito Identity Pools 결과물	임시 AWS 자격증명

🗄️ AWS Storage — Extended Services

Sat, 21 Mar 2026 00:00:00 GMT

🗄️ AWS Storage — Extended Services

Snow Family · FSx · Storage Gateway · Transfer Family · DataSync

Hybrid Cloud, Data Migration, High-Performance File Systems의 핵심 서비스

AWS Snow Family

⚠️ 중요: 단종(Discontinuation) 공지

Effective November 12, 2024: 구세대 Snowball Edge 모델 3종 단종

Snowball Edge Storage Optimized 80TB

Snowball Edge Compute Optimized (52 vCPUs)

Snowball Edge Compute Optimized with GPU

대부분의 Data Migration 워크로드에서 AWS DataSync를 대안으로 사용 권장

Snow Family 개요

인터넷/네트워크를 통한 전송이 어렵거나 느린 경우 물리적 장치(Physical Device)를 통해 데이터를 오프라인으로 이전하는 서비스.

네트워크 전송의 문제점:

Limited connectivity      → 오지, 선박, 원격지에서 인터넷 없음
Limited bandwidth         → 대용량 데이터 전송에 수주~수개월 소요
High network cost         → 대역폭 비용 과다
Shared bandwidth          → 업무 트래픽과 경합
Connection instability    → 전송 중 연결 끊김 위험

📌 Rule of Thumb: 네트워크로 전송 시 1주 이상 걸린다면 → Snow Family 검토

Snowball Edge

모델	특징	주요 Use Case
Storage Optimized	스토리지 중심, 최대 수백 TB	Petabyte 규모 Data Migration
Compute Optimized	EC2, Lambda 실행 가능	Edge Computing + Data Migration

Edge Computing (엣지 컴퓨팅)

인터넷 연결이 제한되거나 없는 **현장(Edge Location)**에서 데이터 처리
Snowball Edge를 현장에 배치하여 On-site Computing Power 제공

Edge Computing Use Cases:

현장 예시: 도로 위 트럭, 바다 위 선박, 지하 광산
사용 목적:
  - EC2 Instance 또는 Lambda 실행
  - 데이터 전처리 (Preprocessing)
  - Machine Learning Inference
  - 미디어 트랜스코딩 (Media Transcoding)

Snowball → S3 → Glacier 아키텍처

📌 시험 포인트: Snowball로 Glacier에 직접 import 불가

[Snowball 장치] → Import → [Amazon S3] → Lifecycle Policy → [Amazon Glacier]
                                          (자동 전환)

Snowball로 데이터를 S3로 먼저 import한 뒤, S3 Lifecycle Policy를 이용해 Glacier로 전환해야 함.

Snow Family 서비스 선택 가이드

서비스	용량	형태	Use Case
Snowball Edge	수십~수백 TB	가방 크기 장치	Petabyte 이하 Migration, Edge Computing
Snowmobile	최대 100 PB (Exabyte)	45피트 트럭 컨테이너	Data Center 전체 이전

Snowmobile: 10 PB 이상의 대규모 Migration에 Snowball보다 효율적

Amazon FSx

AWS에서 3rd-party High-Performance File System을 완전 관리형으로 제공
NFS, SMB, Lustre 등 기존 프로토콜 그대로 사용 가능 → On-premises 워크로드를 클라우드로 Lift-and-Shift

FSx for Windows File Server

Windows 환경을 위한 완전 관리형 공유 파일 시스템
핵심 지원 기능:
- SMB Protocol + Windows NTFS
- Microsoft Active Directory 통합, ACL, 사용자 쿼터(User Quotas)
- DFS (Distributed File System) Namespaces: 여러 파일 시스템을 하나로 묶어 접근

항목	내용
용량/성능	수십 GB/s, 수백만 IOPS, 수백 PB
Linux 지원	✅ Linux EC2 Instance에서도 마운트 가능
On-premises 접근	✅ VPN 또는 Direct Connect 경유
High Availability	Multi-AZ 구성 지원
백업	일별 S3 자동 백업

Storage Options:

옵션	특징	Use Case
SSD	저지연, 고IOPS	DB, 미디어 처리, 데이터 분석
HDD	저비용, 높은 처리량	홈 디렉터리, CMS

FSx for Lustre

Linux 기반 병렬 분산 파일 시스템 (Parallel Distributed File System)
이름 유래: "Linux" + "cluster" = Lustre
*HPC(High Performance Computing)**를 위한 최고 성능 파일 시스템

항목	내용
성능	수백 GB/s, 수백만 IOPS, Sub-millisecond Latency
S3 통합	S3를 파일 시스템처럼 Read 가능, 연산 결과를 S3로 Write 가능
On-premises 접근	✅ VPN 또는 Direct Connect 경유

Storage Options:

옵션	특징	Use Case
SSD	저지연, 랜덤 I/O	소규모 랜덤 파일 작업
HDD	고처리량, 순차 I/O	대규모 순차 파일 작업

Primary Use Cases: Machine Learning, HPC, Video Processing, Financial Modeling, Electronic Design Automation (EDA)

FSx for Lustre — File System Deployment Options

📌 시험 포인트: Scratch vs Persistent 차이를 명확히 구분

항목	Scratch File System	Persistent File System
목적	임시 저장소	장기 저장소
데이터 복제	❌ 없음 (서버 장애 시 데이터 소실)	✅ 동일 AZ 내 복제
장애 복구	없음	분 단위 자동 복구
성능	6x 더 빠름 (200 MBps/TiB Burst)	표준
Use Case	단기 처리, 비용 최적화	장기 처리, 민감 데이터

FSx for NetApp ONTAP

NetApp ONTAP을 AWS에서 완전 관리형으로 제공
기존 ONTAP 또는 NAS(Network-Attached Storage) 환경 워크로드를 AWS로 이전 시 최적

항목	내용
지원 프로토콜	NFS, SMB, iSCSI (3종 동시 지원)
OS 호환성	Linux, Windows, macOS, VMware Cloud on AWS, EC2, ECS, EKS 등 폭넓게 지원
용량	스토리지 자동 축소/확장
기능	Snapshots, Replication, 압축(Compression), 중복 제거(Deduplication)
클로닝	Point-in-time Instantaneous Cloning (새 워크로드 테스트에 유용)

FSx for OpenZFS

OpenZFS 파일 시스템을 AWS에서 완전 관리형으로 제공
기존 ZFS 기반 워크로드를 AWS로 이전 시 최적

항목	내용
지원 프로토콜	NFS (v3, v4, v4.1, v4.2)
성능	최대 1,000,000 IOPS, 0.5ms 미만 Latency
기능	Snapshots, 압축(Compression), Point-in-time Instantaneous Cloning

FSx 선택 가이드

Windows 파일 서버 필요 (SMB, AD 연동)     → FSx for Windows File Server
Linux HPC, ML, 대규모 병렬 처리           → FSx for Lustre
NFS + SMB + iSCSI 동시 지원, ONTAP 이전  → FSx for NetApp ONTAP
ZFS 이전, 초고속 NFS (100만 IOPS)        → FSx for OpenZFS

AWS Storage Gateway

Hybrid Cloud for Storage

On-premises ↔ AWS 클라우드 간 브릿지(Bridge) 역할
S3는 독점 스토리지 기술 (NFS처럼 표준 프로토콜이 아님) → On-premises에서 직접 접근 불가 → Storage Gateway가 해결

Use Cases: Disaster Recovery, Backup & Restore, Tiered Storage, On-premises Cache & Low-latency File Access

S3 File Gateway

On-premises 애플리케이션이 NFS / SMB 프로토콜로 S3에 접근하도록 지원
최근 사용 데이터는 File Gateway에 로컬 캐시 → 빠른 접근 속도

지원 S3 Storage Classes:

✅ S3 Standard
✅ S3 Standard-IA
✅ S3 One Zone-IA
✅ S3 Intelligent-Tiering
❌ S3 Glacier 직접 지원 안 함
   → Lifecycle Policy로 S3에서 Glacier로 전환

SMB + Active Directory 통합:

SMB Protocol 사용 시 Microsoft AD로 사용자 인증 가능
Bucket별로 IAM Role 기반 접근 제어

Volume Gateway

iSCSI Protocol을 통한 Block Storage 제공 (S3 백업)
EBS Snapshot으로 On-premises 볼륨 복원 가능

모드	설명	데이터 위치
Cached Volumes (캐시 볼륨)	최근 데이터만 로컬 캐시, 전체는 S3	주 데이터: S3 / 캐시: On-premises
Stored Volumes (저장 볼륨)	전체 데이터셋 On-premises, S3에 주기적 백업	주 데이터: On-premises / 백업: S3

Tape Gateway

물리 테이프 기반 백업 프로세스를 사용하는 기업을 위한 Virtual Tape Library(VTL)
기존 테이프 방식의 백업 소프트웨어(iSCSI Interface)를 그대로 사용하면서 클라우드로 이전
백업 데이터: Amazon S3 + Glacier 백업

[On-premises Backup Software] → iSCSI → [Tape Gateway] → [S3 / Glacier]
(기존 테이프 프로세스 유지)                 (가상 테이프 라이브러리)

지원 백업 소프트웨어: Veeam, Backup Exec, NetBackup 등 주요 벤더 호환

Storage Gateway 유형 선택 가이드

NFS/SMB로 S3 접근 (파일 공유)           → S3 File Gateway
iSCSI Block Storage + S3 백업           → Volume Gateway
  ├── 전체 On-premises 저장 + 스케줄 백업   → Stored Volumes
  └── 최근 데이터 캐시 + 나머지는 S3       → Cached Volumes
기존 테이프 백업 소프트웨어 그대로 유지    → Tape Gateway

AWS Transfer Family

Amazon S3 또는 Amazon EFS로의 파일 전송을 위한 완전 관리형 FTP 서비스
기존 FTP 기반 파일 교환 인프라를 AWS로 이전할 때 사용

지원 프로토콜

프로토콜	설명	보안
FTP	File Transfer Protocol	❌ 비암호화
FTPS	FTP over SSL	✅ SSL 암호화
SFTP	Secure File Transfer Protocol (SSH 기반)	✅ SSH 암호화

주요 특성

항목	내용
인프라	완전 관리형, Scalable, Reliable
가용성	Multi-AZ
과금	Provisioned Endpoint 시간당 요금 + 데이터 전송(GB) 요금
인증 통합	Microsoft AD, LDAP, Okta, Amazon Cognito, Custom
저장 대상	Amazon S3 또는 Amazon EFS

Use Cases: 파일 공유(File Sharing), 공개 데이터셋 배포, CRM, ERP 시스템 연동

AWS DataSync

대용량 데이터를 자동화하여 빠르게 전송하는 온라인 데이터 이전 서비스

전송 방향

방향	Agent 필요 여부
On-premises → AWS (NFS, SMB, HDFS, S3 API 등)	✅ DataSync Agent 설치 필요
다른 Cloud → AWS	✅ Agent 필요
AWS → AWS (Storage 서비스 간)	❌ Agent 불필요

지원 대상 스토리지

DataSync가 동기화할 수 있는 AWS 서비스:

Amazon S3  (모든 Storage Class, Glacier 포함)
Amazon EFS
Amazon FSx for Windows File Server
Amazon FSx for Lustre
Amazon FSx for NetApp ONTAP
Amazon FSx for OpenZFS

핵심 특성

항목	내용
속도	Agent 1개로 최대 10 Gbps 활용 (Bandwidth Throttle 설정 가능)
스케줄링	시간별(Hourly), 일별(Daily), 주별(Weekly) 예약 실행
메타데이터 보존	File Permissions + Metadata 그대로 유지 (NFS POSIX, SMB 등)
무결성	전송 중 및 완료 후 데이터 무결성 검증
재시도	실패한 전송 자동 재시도

DataSync vs Storage Gateway — 실무 패턴

📌 시험 핵심 패턴: 두 서비스를 함께 쓰는 것이 Best Practice

Phase 1 — 초기 Data Migration:
  [On-premises NFS] → [DataSync Agent] → [Amazon S3 / EFS]
  (대용량 데이터를 빠르게 일회성 또는 반복 이전)

Phase 2 — 지속적 On-premises 접근 유지:
  [On-premises App] → [S3 File Gateway] → [Amazon S3]
  (마이그레이션 후에도 On-premises 앱이 로컬처럼 접근)

항목	DataSync	Storage Gateway
주요 목적	데이터 이전(Migration) 및 동기화	On-premises ↔ AWS 지속적 연동
사용 시점	초기 대량 이전, 정기 배치 동기화	이전 완료 후 지속적 Hybrid 접근
프로토콜	NFS, SMB, HDFS, S3 API 등	NFS, SMB, iSCSI
캐시	❌	✅ 로컬 캐시 제공

전체 Storage 서비스 비교 (Storage Comparison)

서비스	분류	특징	핵심 키워드
S3	Object Storage	범용 객체 스토리지	Buckets, Keys, 11 9's
S3 Glacier	Object Archival	장기 아카이브, 저비용	Vault, 최소 90~180일
EBS	Block Storage	EC2 1:1 네트워크 드라이브	AZ-bound, Snapshot
Instance Store	Block Storage	EC2 직결 물리 디스크, 임시	Ephemeral, 최고 IOPS
EFS	File Storage	Linux 멀티 인스턴스 공유 NFS	POSIX, Multi-AZ
FSx for Windows	File Storage	Windows SMB, AD 통합	NTFS, DFS
FSx for Lustre	File Storage	Linux HPC 병렬 파일 시스템	Sub-ms, S3 통합
FSx for NetApp ONTAP	File Storage	NFS+SMB+iSCSI 멀티 프로토콜	광범위 OS 호환
FSx for OpenZFS	File Storage	ZFS 관리형, 초고속 NFS	100만 IOPS, 0.5ms
Storage Gateway	Hybrid	On-premises ↔ Cloud 브릿지	S3 File/Volume/Tape
Transfer Family	File Transfer	FTP/FTPS/SFTP 관리형	FTP 프로토콜, S3/EFS
DataSync	Data Transfer	자동화 온라인 데이터 이전	Agent, 10Gbps, 스케줄링
Snow Family	Physical Transfer	오프라인 대용량 이전	오지/단절 환경, Petabyte

📌 시험 자주 출제 포인트 총정리

포인트	내용
Snowball → Glacier	직접 import 불가 → S3 먼저 import → Lifecycle Policy로 Glacier 전환
"1주 이상 걸리면"	Snow Family 검토
Snow Family 대안 (2024~)	대부분 AWS DataSync 권장
Snowmobile 기준	10 PB 이상 대규모 Migration
FSx for Windows 특징	SMB + NTFS + AD 통합, Linux EC2에서도 마운트 가능
FSx for Lustre 이름	Linux + cluster
FSx Scratch vs Persistent	Scratch: 데이터 복제 없음, 6x 빠름 / Persistent: AZ 내 복제, 분 단위 복구
FSx for NetApp ONTAP 프로토콜	NFS + SMB + iSCSI 동시 지원
FSx for OpenZFS 성능	1,000,000 IOPS, <0.5ms
NetApp ONTAP & OpenZFS 공통 기능	Point-in-time Instantaneous Cloning
S3 File Gateway Glacier	직접 지원 안 함 → Lifecycle Policy 경유
S3 File Gateway + SMB	Active Directory 사용자 인증 통합
Volume Gateway Cached	최근 데이터 로컬 캐시, 전체는 S3
Volume Gateway Stored	전체 On-premises, 주기적 S3 백업
Tape Gateway	Virtual Tape Library, 기존 테이프 소프트웨어 그대로 사용
DataSync Agent	On-premises → AWS 전송 시 필수, AWS → AWS는 불필요
DataSync 속도	Agent 1개당 최대 10 Gbps
DataSync 스케줄	시간별 / 일별 / 주별
DataSync 메타데이터	File Permissions + Metadata 보존
DataSync + File Gateway	초기 이전은 DataSync, 이후 지속 접근은 File Gateway
Transfer Family 저장 대상	S3 또는 EFS
Transfer Family 프로토콜	FTP, FTPS, SFTP (3가지)
Transfer Family 인증	AD, LDAP, Okta, Cognito, Custom

📚 참고 자료

🔐 AWS S3 Security

Fri, 20 Mar 2026 00:00:00 GMT

🔐 AWS S3 Security

S3 보안의 모든 것 — Encryption, Access Control, Data Protection

AWS SAA 시험에서 S3 관련 문제의 절반 이상이 이 파일의 내용에서 출제됩니다.

S3 Encryption Overview
SSE-S3 (S3-Managed Keys)
SSE-KMS (KMS-Managed Keys)
SSE-C (Customer-Provided Keys)
DSSE-KMS (Dual-Layer SSE)
Client-Side Encryption (CSE)
Encryption in Transit
Default Encryption vs. Bucket Policy 우선순위
S3 Bucket Key
S3 Access Logs
Pre-signed URLs
MFA Delete
S3 Object Lock & Glacier Vault Lock
CORS (Cross-Origin Resource Sharing)
S3 Access Points
S3 Object Lambda
VPC Endpoint for S3
핵심 요약 & 시험 포인트
참고 자료

1. S3 Encryption Overview

암호화 유형 한눈에 비교

유형	키 관리 주체	키 저장	요청 Header	특징
SSE-S3	AWS	AWS 내부	`x-amz-server-side-encryption: AES256`	기본값, 무료
SSE-KMS	AWS KMS	KMS	`x-amz-server-side-encryption: aws:kms`	CloudTrail 감사, 추가 비용
DSSE-KMS	AWS KMS	KMS	`x-amz-server-side-encryption: aws:kms:dsse`	이중 암호화, 규정 준수
SSE-C	Customer	Customer (AWS에 저장 안 함)	HTTPS 필수, 매 요청마다 키 전달	고객 완전 통제
CSE	Customer	Customer	-	업로드 전 클라이언트 측 암호화

선택 가이드:

별도 요구사항 없음                → SSE-S3 (기본값)
키 사용 감사 로그 필요 (규정 준수)  → SSE-KMS (Customer Managed Key)
이중 암호화 규정 준수 필요         → DSSE-KMS
키를 완전히 직접 통제             → SSE-C
AWS가 원본 데이터를 절대 보면 안 됨 → Client-Side Encryption

2. SSE-S3 (S3-Managed Keys)

AWS가 키를 완전히 생성, 관리, 교체 — 사용자 개입 없음
AES-256 알고리즘 사용
2023년 1월 5일부터 모든 신규 Object에 기본 자동 적용 (추가 비용 없음)
Cross-Account 공유 가능

요청 방법:

PUT /my-object HTTP/1.1
x-amz-server-side-encryption: AES256

Bucket Policy로 SSE-S3 강제 예시:

{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
        "StringNotEquals": {
            "s3:x-amz-server-side-encryption": "AES256"
        }
    }
}

3. SSE-KMS (KMS-Managed Keys)

AWS KMS(Key Management Service)를 통해 키 관리
SSE-S3 대비 추가적인 제어와 감사 기능 제공

SSE-KMS 장점:

키 사용 이력 → AWS CloudTrail에 자동 기록 (언제, 누가, 어떤 Key로 접근했는지)
Customer Managed Key (CMK) 생성/교체/비활성화 직접 제어
Cross-Account 접근 세밀한 권한 설정

SSE-KMS 단점 (시험 포인트):

Upload 시 GenerateDataKey KMS API 호출
Download 시 Decrypt KMS API 호출
KMS 쿼터 제한: 리전별 5,500 / 10,000 / 30,000 req/s
고처리량 환경에서 KMS 병목 발생 가능 → Service Quotas Console에서 증가 요청

요청 방법:

PUT /my-object HTTP/1.1
x-amz-server-side-encryption: aws:kms
x-amz-server-side-encryption-aws-kms-key-id: arn:aws:kms:...  (선택, 생략 시 AWS Managed Key 사용)

Bucket Policy로 SSE-KMS 강제 예시:

{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::my-bucket/*",
    "Condition": {
        "StringNotEquals": {
            "s3:x-amz-server-side-encryption": "aws:kms"
        }
    }
}

Cross-Account 고려사항:

AWS Managed Key (aws/s3): 같은 계정에서만 사용 가능
다른 계정과 SSE-KMS 데이터 공유: 반드시 Customer Managed Key(CMK) 사용

4. SSE-C (Customer-Provided Keys)

고객이 키를 직접 생성/관리, AWS는 암호화/복호화 작업만 수행
AWS는 키를 저장하지 않음 — 요청 처리 후 즉시 메모리에서 삭제
고객이 키 분실 시 데이터 복구 완전 불가

필수 요건:

반드시 HTTPS 사용 (HTTP 요청 시 S3가 거부)
모든 Upload/Download 요청마다 HTTP Header로 키 전달

PUT /my-object HTTP/1.1
x-amz-server-side-encryption-customer-algorithm: AES256
x-amz-server-side-encryption-customer-key: [Base64 인코딩된 키]
x-amz-server-side-encryption-customer-key-MD5: [키의 MD5]

:::warning ⚠️ AWS 콘솔에서 SSE-C 객체 접근 불가 (CLI/SDK만 가능 — 키를 매번 전달해야 하므로) :::

5. DSSE-KMS (Dual-Layer SSE)

KMS 키를 사용한 이중(Dual-Layer) 서버 사이드 암호화
AES-256을 두 번 독립적으로 적용:
1. AWS KMS Data Encryption Key로 1차 암호화
2. 별도 S3 관리 암호화 키로 2차 암호화
엄격한 규정 준수(Compliance) 요구사항이 있는 환경용
SSE-KMS보다 높은 비용 및 지연 시간 증가

6. Client-Side Encryption (CSE)

데이터를 S3에 Upload하기 전 클라이언트 측에서 직접 암호화
AWS SDK의 Amazon S3 Client-Side Encryption Library 활용
AWS는 암호화된 데이터만 수신 — 원본 데이터에 접근 불가
고객이 키와 암호화 라이프사이클 완전 관리

[클라이언트]                    [S3]
  원본 데이터
      │ 클라이언트 측 암호화
      ▼
  암호화된 데이터  ──HTTPS──→  암호화된 데이터 저장
                              (S3는 내용 모름)

7. Encryption in Transit

S3는 두 가지 Endpoint 제공:
- HTTP Endpoint: 암호화 없음
- HTTPS Endpoint: In-flight Encryption (SSL/TLS)
HTTPS 권장, SSE-C에서는 HTTPS 필수
대부분의 클라이언트/SDK는 기본적으로 HTTPS 사용

HTTPS 강제 (aws:SecureTransport)

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "Principal": "*",
        "Action": "s3:*",
        "Resource": [
            "arn:aws:s3:::my-bucket",
            "arn:aws:s3:::my-bucket/*"
        ],
        "Condition": {
            "Bool": {
                "aws:SecureTransport": "false"
            }
        }
    }]
}

:::tip `aws:SecureTransport: false`를 Deny하면 HTTP 요청 차단. Bucket과 Object 모두 Resource에 포함해야 함. :::

8. Default Encryption vs. Bucket Policy 우선순위

:::tip Bucket Policy가 Default Encryption보다 먼저 평가됨 :::

Object Upload 요청
        │
        ▼
1️⃣ Bucket Policy 평가
   (Deny 조건에 해당하면 요청 거부)
        │ Policy 통과
        ▼
2️⃣ Default Encryption 적용
   (Header 없으면 기본 암호화 설정으로 처리)

실제 시나리오:

Default Encryption을 SSE-KMS로 설정해도, Bucket Policy에서 aws:kms Header가 없는 요청을 Deny하면 정책이 우선 적용
x-amz-server-side-encryption Header 없이 Upload하면 → Default Encryption 적용 (SSE-S3 또는 SSE-KMS)

9. S3 Bucket Key

SSE-KMS 사용 시 KMS API 호출 횟수를 줄이기 위한 기능
Bucket Key가 활성화되면:
- S3가 버킷 레벨에서 단기 Bucket-level KMS Key를 생성
- 개별 Object마다 KMS 호출 대신 Bucket Key로 Data Key 생성
- KMS 호출 수 대폭 감소 → 비용 절감 + CloudTrail 로그 감소

Bucket Key 비활성화:
  Object 1  →  KMS API Call  →  Data Key 1
  Object 2  →  KMS API Call  →  Data Key 2
  Object 3  →  KMS API Call  →  Data Key 3  (많은 KMS 비용)

Bucket Key 활성화:
  Bucket  →  KMS API Call  →  Bucket Key
    Object 1  →  (Bucket Key로)  →  Data Key 1
    Object 2  →  (Bucket Key로)  →  Data Key 2
    Object 3  →  (Bucket Key로)  →  Data Key 3  (KMS 비용 대폭 감소)

10. S3 Access Logs

감사(Audit) 목적으로 S3에 대한 모든 요청을 다른 S3 Bucket에 로그로 기록
어떤 계정, 어떤 요청(인가 여부 포함)이든 모두 기록
로그 데이터를 Athena 등 데이터 분석 도구로 분석 가능
로깅 대상 Bucket과 로그 저장 Bucket은 같은 AWS Region에 있어야 함

:::warning ❌ 절대 금지: 모니터링 대상 Bucket = 로그 저장 Bucket → Logging Loop 발생 → Bucket 크기 지수적 증가

✅ 올바른 구성: [모니터링 Bucket] → Access Logs → [별도 Logging Bucket] :::

11. Pre-signed URLs

제한된 시간 동안만 유효한 S3 객체 접근 URL
S3 Console, AWS CLI, SDK로 생성 가능
URL을 받은 사용자는 URL 생성자의 권한(Permission)을 그대로 상속 (GET/PUT)
Bucket을 Public으로 열지 않고 일시적으로 특정 사용자에게 접근 허용

유효 시간

생성 방법	유효 시간
S3 Console	최소 1분, 최대 12시간 (720분)
AWS CLI	기본 3,600초, 최대 604,800초 (7일)

활용 예시

[앱 서버] ─ Pre-signed URL 생성 ─→ [사용자 브라우저]
                                          │
                                          ▼
                                    [S3 객체 직접 접근]
                                    (Bucket은 Private 유지,
                                     유효 시간 내에만 접근 가능)

Use Cases:

로그인한 사용자에게만 프리미엄 영상 다운로드 허용
동적으로 생성되는 업로드 URL (사용자 Profile 이미지 업로드)
일시적인 파일 공유

12. MFA Delete

Versioning이 활성화된 Bucket에서 중요 작업 시 MFA(Multi-Factor Authentication) 코드 요구

MFA가 필요한 작업

✅ MFA 필요:
  - Object Version 영구 삭제 (Permanently delete an object version)
  - Versioning 비활성화 또는 Suspend

❌ MFA 불필요:
  - Versioning 활성화
  - Delete Marker 추가 (= 일반 Delete 작업)
  - Version 목록 조회

설정 규칙

항목	내용
설정 가능 주체	Bucket Owner (Root 계정)만 가능 — IAM User 불가
전제 조건	Bucket에 Versioning 활성화 필수
설정 방법	CLI 또는 SDK만 가능 (Console 미지원)

13. S3 Object Lock & Glacier Vault Lock

S3 Object Lock

WORM (Write Once Read Many) 모델 적용
지정된 기간 동안 Object Version 삭제/수정 불가
Versioning 활성화 필수

Retention Mode 비교:

Mode	설명	Root 포함 삭제 가능?
Compliance Mode	어떤 사용자도(Root 포함) 수정/삭제 불가. 보존 기간 단축 불가	❌ 절대 불가
Governance Mode	대부분 사용자는 불가. `s3:BypassGovernanceRetention` 권한 보유자만 가능	✅ 특별 권한자만

Retention Period:

Object를 고정 기간 동안 보호
기간 연장(Extend)은 가능, 단축(Shorten)은 Compliance Mode에서 불가

Legal Hold:

보존 기간과 무관하게 무기한 잠금
s3:PutObjectLegalHold IAM 권한으로 자유롭게 적용/해제 가능
예: 소송 진행 중 증거 보전

Glacier Vault Lock

S3 Glacier Vault에 Vault Lock Policy (JSON) 적용
WORM 모델로 아카이브 데이터 보호
한 번 Lock되면 누구도 정책 변경/삭제 불가 — Root 포함
규정 준수(Compliance) 및 데이터 보존(Data Retention) 요구사항 충족

[Vault Lock Policy 작성]
        │
        ▼
[24시간 이내 검증 기간] ← 이 기간 중에만 정책 수정 가능
        │ 검증 완료 후 Lock 실행
        ▼
[정책 영구 잠금] ← 이후 절대 변경 불가

14. CORS (Cross-Origin Resource Sharing)

기본 개념

Origin = Scheme (Protocol) + Host (Domain) + Port
- 예: https://example.com (scheme=https, host=example.com, port=443)
웹 브라우저의 Same-Origin Policy: 다른 Origin의 리소스 요청 기본 차단
CORS Headers로 다른 Origin에서의 요청 허용 가능

Same Origin vs. Cross Origin

Same Origin   (허용):  https://example.com/app1  →  https://example.com/app2
Cross Origin  (차단):  https://example.com        →  https://other.com

S3에서 CORS 설정이 필요한 경우

S3 정적 웹사이트에서 다른 S3 Bucket의 리소스 참조
웹 앱(다른 도메인)이 S3 Bucket의 파일을 직접 요청

CORS 설정 예시 (S3 Bucket에 적용)

<CORSConfiguration>
  <CORSRule>
    <AllowedOrigin>https://www.example.com</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
  </CORSRule>
</CORSConfiguration>

<AllowedOrigin>: 허용할 출처 (로 전체 허용 가능)
<AllowedMethod>: 허용할 HTTP 메서드
<AllowedHeader>: 허용할 Header
<MaxAgeSeconds>: Pre-flight 결과 캐시 시간

:::tip CORS 설정은 리소스를 제공하는 Bucket (파일이 있는 쪽)에 설정. 요청하는 쪽이 아님. :::

15. S3 Access Points

개념

S3 Bucket에 대한 독립적인 접근 포인트 생성
각 Access Point마다 고유한 DNS 이름 + 독립적인 Access Point Policy 보유
대규모 Bucket의 보안 관리 단순화 (Bucket Policy 복잡성 해소)

[S3 Bucket]
    │
    ├── [Access Point: /finance/*]
    │       Access Point Policy: Finance 팀만 읽기/쓰기
    │
    ├── [Access Point: /analytics/*]
    │       Access Point Policy: Analytics 팀만 읽기
    │
    └── [Access Point: /logs/*]
            Access Point Policy: Logging 서비스만 쓰기

Access Point Policy

Bucket Policy와 유사한 JSON 형식
Access Point Policy + Bucket Policy 모두 허용해야 접근 가능

VPC Origin (VPC 전용 Access Point)

[EC2 - Private VPC]
        │
        ▼
[VPC Endpoint (Gateway or Interface)]
        │
        ▼
[S3 Access Point (VPC Origin)]
        │
        ▼
[S3 Bucket]

VPC 내부에서만 접근 가능한 Access Point 정의
VPC Endpoint 생성 필수
VPC Endpoint Policy에서 대상 Bucket과 Access Point에 대한 접근 허용 필요

16. S3 Object Lambda

개념

S3에서 Object를 반환할 때 Lambda Function이 데이터를 변환한 후 반환
원본 Object는 변경 없음 — 요청자에게만 변환된 결과 제공
Bucket 1개로 여러 형태의 데이터 제공 가능

아키텍처

                    [원본 S3 Bucket]
                           │
            ┌──────────────┼─────────────────┐
            │              │                 │
    [일반 Access Point] [Object Lambda   [Object Lambda
                          Access Point 1]   Access Point 2]
                               │                  │
                         [Lambda: PII         [Lambda: XML
                          Redaction]           → JSON 변환]
                               │                  │
                         [Analytics App]    [Modern App]

주요 Use Cases

Use Case	설명
PII Redaction (개인정보 마스킹)	분석용/비운영 환경에서 개인정보 제거 후 반환
Format Conversion	XML → JSON, CSV → Parquet 등 포맷 변환
Image Processing	요청자에 맞게 이미지 리사이징, 워터마크 삽입

17. VPC Endpoint for S3

S3를 인터넷 경유 없이 VPC 내부에서 직접 접근
Gateway Endpoint 타입 사용 — 무료
Private Subnet의 EC2가 NAT Gateway 없이 S3 접근 가능

❌ 인터넷 경유 방식:
[EC2 - Private Subnet] → [NAT Gateway] → [Internet] → [S3]
              (NAT Gateway 비용 + 데이터 전송 비용 발생)

✅ VPC Gateway Endpoint 방식:
[EC2 - Private Subnet] → [VPC Gateway Endpoint] → [S3]
              (비용 없음, 인터넷 경유 없음)

설정 구성요소:

Route Table에 S3용 Prefix List 경로 추가 (자동)
VPC Endpoint Policy로 접근 가능한 Bucket/Action 제한 가능

:::tip S3와 DynamoDB는 Gateway Endpoint (무료). 다른 서비스는 Interface Endpoint (비용 발생). :::

18. 핵심 요약 & 시험 포인트

암호화 결정 트리

암호화 필요?
├── 아니요 → 그래도 SSE-S3 기본 적용됨 (2023년~)
└── 예
    ├── 키 감사 로그 필요? (CloudTrail)
    │   ├── 예 → SSE-KMS (CMK)
    │   │         KMS 쿼터 고려, S3 Bucket Key로 비용 절감
    │   └── 아니요 → SSE-S3 (무료, 간단)
    ├── 이중 암호화 규정 준수?  → DSSE-KMS
    ├── 키를 직접 통제/관리?   → SSE-C (HTTPS 필수)
    └── AWS가 원본 못 봐야 함?  → Client-Side Encryption

보안 레이어 평가 순서

Object Upload 요청
    │
    1️⃣ Bucket Policy 평가 (Deny 조건 확인)
    │
    2️⃣ Default Encryption 적용 (Header 없으면 기본값)
    │
    3️⃣ IAM Policy 확인 (User/Role 권한)

📌 시험 자주 출제 포인트 총정리

포인트	내용
S3 기본 암호화 (2023~)	SSE-S3 자동 적용, 추가 비용 없음
SSE-S3 Header	`x-amz-server-side-encryption: AES256`
SSE-KMS Header	`x-amz-server-side-encryption: aws:kms`
SSE-C 필수 요건	HTTPS (HTTP 요청 시 S3가 거부)
SSE-C 키 저장	AWS는 키 저장 안 함, 매 요청 시 Header로 전달
SSE-KMS Cross-Account	Customer Managed Key(CMK) 필수
SSE-KMS 병목	KMS 쿼터 초과 가능, S3 Bucket Key로 KMS 호출 감소
Bucket Policy 평가	Default Encryption보다 먼저 평가
HTTPS 강제 정책	`aws:SecureTransport: false` → Deny
Access Logs Loop 방지	모니터링 Bucket ≠ 로그 저장 Bucket (절대 같아선 안 됨)
Pre-signed URL 유효 기간	Console 12h / CLI 최대 7일 (604,800초)
Pre-signed URL 권한	생성자의 권한 상속
MFA Delete 설정 주체	Root 계정(Bucket Owner)만 가능
MFA Delete 전제	Versioning 활성화 필수
MFA Delete 필요 작업	영구 버전 삭제, Versioning Suspend
MFA Delete 불필요 작업	Versioning 활성화, Delete Marker 추가
Object Lock 전제	Versioning 활성화 필수
Compliance Mode	Root 포함 누구도 수정/삭제 불가
Governance Mode	`s3:BypassGovernanceRetention` 권한자만 수정 가능
Legal Hold	보존 기간과 무관, 무기한 잠금
Glacier Vault Lock	한 번 Lock 후 변경 불가 (Root 포함)
CORS 설정 위치	리소스를 제공하는 Bucket에 설정 (요청하는 쪽 아님)
Access Points	각자 독립 DNS + 독립 Policy
VPC Access Point	VPC Endpoint + Endpoint Policy 모두 설정 필요
S3 Object Lambda	원본 변경 없음, Lambda가 변환 후 반환
VPC Endpoint 타입	S3, DynamoDB → Gateway Endpoint (무료)

📚 참고 자료

🪣 Amazon S3 (Simple Storage Service)

Thu, 19 Mar 2026 00:00:00 GMT

🪣 Amazon S3 (Simple Storage Service)

AWS의 핵심 빌딩 블록 — "무한히 확장 가능한" 객체 스토리지

내구성 99.999999999%(11 9's), 시험 전 영역에서 고빈도 출제

S3 기본 개념
S3 보안 (Security) 개요
정적 웹사이트 호스팅 (Static Website Hosting)
버저닝 (Versioning)
복제 (Replication)
스토리지 클래스 (Storage Classes)
S3 Lifecycle
성능 (Performance)
S3 Batch Operations
S3 Event Notifications
S3 Analytics - Storage Class Analysis
S3 Storage Lens
Requester Pays
핵심 요약 & 시험 포인트
참고 자료

1. S3 기본 개념

🪣 버킷 (Buckets)

객체(파일)를 저장하는 컨테이너 (= 디렉터리)
버킷 이름은 전 세계 모든 계정에서 고유 (Globally Unique Name)
버킷은 리전(Region) 레벨에서 생성됨 — 글로벌 서비스처럼 보이지만 실제는 리전별

버킷 이름 규칙:

소문자, 숫자, 하이픈만 사용
3~63자
IP 주소 형태 불가
소문자 또는 숫자로 시작
xn-- 접두사 불가, s3alias 접미사 불가

📄 객체 (Objects)

항목	내용
키 (Key)	객체의 전체 경로 (prefix + 객체명)
최대 객체 크기	5TB
5GB 초과 업로드	멀티파트 업로드 (Multi-part Upload) 필수
메타데이터	텍스트 키/값 쌍 (시스템 또는 사용자 정의)
태그 (Tags)	유니코드 키/값 쌍, 최대 10개 (보안/라이프사이클 활용)
Version ID	버저닝 활성화 시 부여

s3://my-bucket/images/2025/photo.jpg
              └─────prefix──────┘└─name─┘

:::note ⚠️ S3에는 실제 "디렉터리" 개념이 없음 — 키의 슬래시(/)가 구조처럼 보이게 하는 것뿐. :::

🎯 주요 Use Cases

백업/스토리지, 재해 복구(DR), 아카이브, 하이브리드 클라우드 스토리지,
애플리케이션 호스팅, 미디어 호스팅, 데이터 레이크/빅데이터 분석,
소프트웨어 배포, 정적 웹사이트

2. S3 보안 (Security) 개요

🔐 상세 내용은 별도 파일 참고: AWS_S3_Security_Notes.md

(Encryption, Access Points, Object Lambda, MFA Delete, Object Lock, CORS, Pre-signed URL, Access Logs 포함)

보안 정책 계층

레이어	종류	설명
User-based	IAM Policies	특정 IAM User/Role에 API 허용 정의
Resource-based	Bucket Policy	Bucket-wide JSON 정책, Cross-Account 가능
Resource-based	Object/Bucket ACL	세밀한 객체 단위 제어 (비활성화 가능)
계정 레벨	Block Public Access	전체 계정 또는 버킷 단위 Public 차단

접근 허용 조건 (IAM Principal이 S3 객체에 접근하려면):

(IAM 권한 ALLOW  OR  Resource Policy ALLOW)
            AND
       명시적 DENY 없음

Bucket Policy 핵심 활용

{
    "Version": "2012-10-17",
    "Statement": [{
        "Sid": "PublicRead",
        "Effect": "Allow",
        "Principal": "*",
        "Action": ["s3:GetObject"],
        "Resource": ["arn:aws:s3:::examplebucket/*"]
    }]
}

Public read 허용 (정적 웹사이트)
Upload 시 Encryption 강제
Cross-Account 접근 허용
aws:PrincipalOrgID 조건으로 AWS Organizations 단위 접근 제어

Block Public Access

기본값: 모든 Public 접근 차단 (데이터 유출 방지)
계정 레벨 설정 가능 → 전체 계정 Bucket 일괄 차단
정적 웹사이트 공개 시 반드시 비활성화 + Bucket Policy 허용 둘 다 필요

3. 정적 웹사이트 호스팅 (Static Website Hosting)

S3로 정적 HTML/CSS/JS 웹사이트 호스팅 가능
URL 형식:
- http://bucket-name.s3-website-{region}.amazonaws.com
- http://bucket-name.s3-website.{region}.amazonaws.com

설정 체크리스트:

✅ Static Website Hosting 활성화
✅ Block Public Access 비활성화
✅ Bucket Policy에서 s3:GetObject 허용 (Principal: *)
✅ index.html 지정

💡 403 Forbidden 오류: Bucket Policy가 Public read를 허용하지 않는 것. CloudFront + OAC(Origin Access Control)를 사용하면 S3를 Public으로 열지 않고도 웹사이트 서비스 가능.

4. 버저닝 (Versioning)

버킷 레벨에서 활성화 — 객체 단위 활성화 불가
같은 키로 업로드 시 버전 번호가 증가 (1, 2, 3…)
실수 삭제 방지 + 이전 버전 롤백 가능

상황	동작
버저닝 활성화 전 파일	버전 ID = `null`
버저닝 비활성화(Suspend)	기존 버전 삭제되지 않음 — 신규 업로드만 버전 없음
파일 삭제 시	실제 삭제 아닌 Delete Marker(삭제 마커) 추가
Delete Marker 삭제 시	파일 복원됨

버전 1 → 버전 2 → 버전 3 (현재)
                    │ 삭제
                    ▼
              [Delete Marker] → 파일이 없는 것처럼 보임
              Delete Marker 삭제 → 버전 3 복원

:::tip 📌 복제(Replication) 사용 시: 버저닝이 소스/대상 버킷 모두에서 필수 :::

5. 복제 (Replication)

종류

유형	설명	주요 Use Case
CRR (Cross-Region Replication)	다른 리전으로 복제	규정 준수, 지연 시간 감소, 계정 간 복제
SRR (Same-Region Replication)	같은 리전 내 복제	로그 집계, 운영/테스트 계정 간 실시간 동기화

주요 특성

항목	내용
사전 요건	소스 + 대상 버킷 모두 버저닝 활성화 필수
복제 방식	비동기 (Asynchronous)
계정	서로 다른 AWS 계정 간 복제 가능
IAM	S3에 적절한 IAM 권한 부여 필요
기존 객체	복제 활성화 후 새 객체만 자동 복제
기존 객체 복제	S3 Batch Replication 사용 (실패 객체 재시도도 가능)

삭제 동작

Delete Marker 복제:   선택적 설정 (기본값: 복제 안 함)
Version ID 포함 삭제: 복제 안 함 (악의적 삭제 방지)

⚠️ 체이닝 없음

버킷 1 → (복제) → 버킷 2 → (복제) → 버킷 3

버킷 1의 객체는 버킷 2에만 복제됨
버킷 3에는 자동 복제 안 됨 (No "chaining" of replication)

6. 스토리지 클래스 (Storage Classes)

📊 전체 비교표

스토리지 클래스	가용성	내구성	AZ 수	검색 시간	최소 보존 기간	주요 Use Case
S3 Standard	99.99%	11 9's	≥3	즉시	없음	자주 접근하는 데이터
S3 Standard-IA	99.9%	11 9's	≥3	즉시	30일	비정기 접근, 빠른 조회 필요
S3 One Zone-IA	99.5%	11 9's	1	즉시	30일	재생성 가능한 보조 백업
S3 Glacier Instant Retrieval	99.9%	11 9's	≥3	밀리초	90일	분기별 접근, 즉각 복원
S3 Glacier Flexible Retrieval	99.99%	11 9's	≥3	분~시간	90일	백업, 아카이브
S3 Glacier Deep Archive	99.99%	11 9's	≥3	12~48시간	180일	장기 보관, 최저 비용
S3 Intelligent-Tiering	99.9%	11 9's	≥3	자동	없음	접근 패턴 예측 불가
S3 Express One Zone	99.95%	높음	1	단일 자릿수 ms	없음	초저지연, AI/ML

클래스별 상세

S3 Standard (범용)

자주 접근하는 데이터, 낮은 지연 + 높은 처리량
동시 2개 시설 장애 허용 (내결함성)
Use Case: 빅데이터, 모바일/게임, 콘텐츠 배포

S3 Standard-IA / S3 One Zone-IA (비정기 접근)

Standard보다 저렴하나 검색 시 요금 발생
One Zone-IA: 단일 AZ → AZ 파괴 시 데이터 손실, 재생성 가능 데이터에만
Use Case: Standard-IA → DR/백업, One Zone-IA → 온프레미스 보조 백업, 재생성 가능 데이터

S3 Glacier (아카이브 3종)

Glacier 유형	검색 옵션	검색 시간	최소 보존
Glacier Instant	-	밀리초	90일
Glacier Flexible	Expedited (긴급)	1~5분	90일
	Standard (표준)	3~5시간
	Bulk (대량)	5~12시간 (무료)
Glacier Deep Archive	Standard	12시간	180일
	Bulk	48시간

S3 Intelligent-Tiering (자동 계층 이동)

월별 소액 모니터링 + 자동 계층화 수수료 발생
검색 요금 없음 (Intelligent-Tiering의 핵심 장점)
접근 패턴에 따라 자동 이동:

Frequent Access  (기본)         ← 자동
Infrequent Access               ← 30일 미접근 시 자동 이동
Archive Instant Access          ← 90일 미접근 시 자동 이동
Archive Access (선택, 설정 필요) ← 90~700일
Deep Archive Access (선택)      ← 180~700일

S3 Express One Zone (신규, 2023)

단일 AZ 내 Directory Bucket에 저장
단일 자릿수 밀리초 (single-digit millisecond) 지연 시간
S3 Standard 대비 최대 10배 성능, 비용 50% 절감
SageMaker, Athena, EMR, Glue와 최적 통합
Use Case: AI/ML 훈련, 금융 모델링, HPC, 미디어 처리

7. S3 Lifecycle

개요

Lifecycle Rules를 사용해 객체를 자동으로 다른 Storage Class로 전환하거나 삭제
비용 최적화의 핵심 기능 — 시험에서 "가장 비용 효율적인 스토리지 전략" 문제의 정답

[Standard] →(30일)→ [Standard-IA] →(60일)→ [Glacier Flexible] →(365일)→ 삭제

Lifecycle Rule 종류

규칙 유형	설명	예시
Transition Actions	특정 시간 후 다른 Storage Class로 이동	생성 60일 후 Standard-IA로 이동
Expiration Actions	특정 시간 후 객체 삭제(만료)	365일 후 로그 파일 삭제

Transition Actions (전환 규칙)

Standard  →  Standard-IA  →  Glacier Instant  →  Glacier Flexible  →  Deep Archive
         ↑                ↑
     최소 30일          최소 90일
     Standard 이후       IA 이후

전환 방향: 항상 아래 등급으로만 가능 (상위 클래스로 되돌아가지 않음)
각 Storage Class로 전환되기까지 최소 보존 기간 충족 필요

Expiration Actions (만료 규칙)

활용	설명
오래된 객체 삭제	Access log 파일 365일 후 자동 삭제
이전 버전 삭제	Versioning 활성화 시 non-current version 삭제
불완전한 Multipart Upload 삭제	일정 기간 완료되지 않은 Part 정리
Expired Delete Marker 삭제	불필요한 Delete Marker 자동 정리

Rule 적용 범위

Prefix 기반: 특정 경로에만 적용 (예: s3://mybucket/logs/*)
Tag 기반: 특정 Tag가 있는 객체에만 적용 (예: Department:Finance)

시험 시나리오 예시

Q: 6개월간 자주 접근, 이후 1년간 가끔 접근, 그 이후 보관이 필요한 데이터의 비용 최적화 방법은?

생성 후 0~6개월:  S3 Standard
        ↓ Lifecycle Rule: 180일 후 전환
6개월~1.5년:     S3 Standard-IA
        ↓ Lifecycle Rule: 365일 후 전환
1.5년 이후:      S3 Glacier Flexible Retrieval

8. 성능 (Performance)

🔢 S3 Baseline Performance (기준 성능 수치)

📌 시험 핵심 수치 — 자주 출제됨

S3는 높은 요청 속도에 자동으로 스케일링 (지연 시간 100~200ms)
Prefix당 초당 요청 처리량:
- PUT/COPY/POST/DELETE: 3,500 req/s
- GET/HEAD: 5,500 req/s
버킷 내 Prefix 수 제한 없음
Prefix를 4개로 분산 시: GET/HEAD 22,000 req/s 달성 가능

s3://bucket/folder1/sub1/file   ← prefix: /folder1/sub1/
s3://bucket/folder1/sub2/file   ← prefix: /folder1/sub2/
s3://bucket/folder2/sub1/file   ← prefix: /folder2/sub1/
s3://bucket/folder2/sub2/file   ← prefix: /folder2/sub2/
→ 각 prefix에서 5,500 GET/s × 4 = 22,000 GET/s

🚀 S3 Transfer Acceleration

S3 버킷으로의 장거리 파일 전송 속도 향상
AWS CloudFront의 **엣지 로케이션(Edge Location)**을 경유:

[사용자 (일본)]  →  [CloudFront Edge (일본)]  →  [AWS 전용 백본망]  →  [S3 버킷 (us-east-1)]
                    빠른 업로드                       고속 전용선

Use Case: 전 세계에서 하나의 S3 버킷으로 데이터를 빠르게 집계할 때
버킷 레벨에서 활성화, 별도 엔드포인트 사용

📦 Multipart Upload (멀티파트 업로드)

5GB 초과 시 필수, 100MB 초과부터 권장
파일을 여러 파트로 분할하여 병렬 업로드 → 속도 향상
파트 업로드 실패 시 해당 파트만 재시도

[100GB 파일]
    │ 분할
    ├── Part 1 (10GB) ─→ S3
    ├── Part 2 (10GB) ─→ S3  (병렬)
    └── Part N (10GB) ─→ S3
                          │
                    완료 시 S3가 합성

🔍 S3 Byte-Range Fetches (바이트 범위 가져오기)

파일의 특정 바이트 범위만 병렬로 GET 요청
다운로드 속도 향상 (병렬 처리)
파일의 일부만 조회 가능 (헤더 데이터 파싱 등)

📊 S3 Select & Glacier Select

S3 Select: SQL 쿼리로 S3에서 필요한 데이터만 서버 사이드 필터링
전체 파일 다운로드 없이 필요한 데이터만 추출 → 비용, 트래픽 절감
CSV, JSON, Parquet 형식 지원

전체 CSV 다운로드 후 필터링 → [큰 파일 전체 전송]  ← 비효율
S3 Select 사용             → [필요한 행만 반환]    ← 효율적

9. S3 Batch Operations

기존 S3 객체에 대해 단일 요청으로 대규모 작업 수행
Job = 객체 목록 + 수행할 Action + 선택적 파라미터

지원하는 작업 (Actions)

Action	설명
Copy objects	버킷 간 객체 복사
Modify metadata	객체 메타데이터/속성 일괄 변경
Encrypt	미암호화 객체 일괄 암호화 (SSE-KMS 등으로 전환)
Modify ACLs/Tags	ACL 또는 Tag 일괄 수정
Restore from Glacier	Glacier 객체 일괄 복원
Invoke Lambda	각 객체에 대해 Lambda Function 실행

작동 흐름

S3 Inventory로 객체 목록 생성
        │
        ▼
Athena로 필터링 (특정 조건의 객체만 선택)
        │
        ▼
S3 Batch Operations Job 생성
        │
        ▼
진행률 추적 + 재시도 자동 관리 + 완료 알림 + 리포트 생성

💡 실무 활용: 기존 미암호화 객체를 SSE-KMS로 일괄 전환할 때, S3 Replication 활성화 이전의 기존 객체를 복제할 때 (S3 Batch Replication)

10. S3 Event Notifications

지원 이벤트 유형

S3:ObjectCreated, S3:ObjectRemoved, S3:ObjectRestore, S3:Replication 등
Object 이름으로 필터링 가능 (예: .jpg)

이벤트 대상 (Destinations)

S3 이벤트 발생
    │
    ├──→ SNS Topic  ← SNS Resource Policy 필요
    ├──→ SQS Queue  ← SQS Resource Policy 필요
    └──→ Lambda Function  ← Lambda Resource Policy 필요

:::important 📌 중요: S3 → SNS/SQS/Lambda 연결 시 IAM Role이 아닌 Resource-based Policy(리소스 정책) 설정 필요 :::

S3 Event Notifications with Amazon EventBridge

S3 Bucket  →  Amazon EventBridge  →(Rules)→  18개 이상 AWS 서비스

EventBridge 사용 시 장점:

고급 필터링: JSON Rules로 Metadata, Object size, 이름 기반 필터링
Multiple Destinations: Step Functions, Kinesis Streams/Firehose 등
Archive / Replay Events: 이벤트 재처리 가능
Reliable delivery: 신뢰성 높은 전달 보장

💡 선택 기준: 단순한 트리거는 SNS/SQS/Lambda 직접 연결. 복잡한 라우팅이나 다양한 Destination이 필요하면 EventBridge 경유.

11. S3 Analytics - Storage Class Analysis

언제 객체를 다른 Storage Class로 전환할지 분석 및 권장
지원 범위: Standard → Standard-IA 전환 분석만 가능
- ❌ One Zone-IA, Glacier는 직접 분석 불가
Report는 S3 버킷에 CSV 형식으로 출력
분석 초기화 소요 시간: 24~48시간
Daily 업데이트

S3 Analytics 분석 결과
        │
        ▼
Lifecycle Rules 설계의 출발점으로 활용

💡 Lifecycle Rules를 처음 설계하거나 개선할 때 S3 Analytics를 먼저 실행해서 데이터 기반으로 전환 시점 결정 권장

12. S3 Storage Lens

전체 AWS Organization 수준에서 S3 스토리지 사용량과 활동을 분석·최적화하는 도구
30일간 사용량 및 활동 지표 집계
이상 탐지(Anomaly Detection), 비용 효율화, 데이터 보호 Best Practice 적용
집계 단위: Organization, 특정 Account, Region, Bucket, Prefix
기본 대시보드(Default Dashboard) 제공 또는 커스텀 대시보드 생성
일별 S3 버킷으로 메트릭 내보내기 가능 (CSV, Parquet)

Default Dashboard

Multi-Region, Multi-Account 데이터 시각화
Amazon S3가 사전 구성 (Preconfigured)
삭제 불가 (단, 비활성화는 가능)

주요 Metrics 카테고리

카테고리	주요 지표	활용 목적
Summary Metrics	StorageBytes, ObjectCount	가장 빠르게 증가하는 Bucket/Prefix 파악
Cost-Optimization Metrics	NonCurrentVersionStorageBytes, IncompleteMultipartUploadStorageBytes	7일 이상된 불완전 Multipart Upload 탐지, 저비용 클래스 전환 후보 파악
Data-Protection Metrics	VersioningEnabledBucketCount, MFADeleteEnabledBucketCount, SSEKMSEnabledBucketCount	데이터 보호 Best Practice 미준수 Bucket 탐지
Access-Management Metrics	ObjectOwnershipBucketOwnerEnforcedBucketCount	Object Ownership 설정 현황 파악
Event Metrics	EventNotificationEnabledBucketCount	Event Notification 설정 현황
Performance Metrics	TransferAccelerationEnabledBucketCount	Transfer Acceleration 활성화 현황
Activity Metrics	AllRequests, GetRequests, PutRequests, BytesDownloaded	스토리지 요청 패턴 파악
Detailed Status Code Metrics	200OKStatusCount, 403ForbiddenErrorCount, 404NotFoundErrorCount	HTTP 오류 패턴 분석

Free vs. Advanced (Paid)

항목	Free	Advanced (Paid)
자동 제공 여부	✅ 모든 고객 자동 제공	추가 비용
기본 Metrics 수	~28개	더 많은 추가 지표
데이터 보존 기간	14일	15개월
CloudWatch 연동	❌	✅ 추가 비용 없이 CloudWatch 게시
Prefix 레벨 집계	❌	✅
Advanced Cost Optimization / Data Protection	❌	✅

13. Requester Pays

기본: Bucket 소유자가 모든 S3 Storage 비용 + 데이터 전송 비용 부담
Requester Pays 활성화 시: 요청자(Requester)가 데이터 다운로드 요청 비용 부담
대용량 Dataset을 다른 계정과 공유할 때 유용
요청자는 반드시 AWS에 인증(Authenticated) 되어야 함 — 익명(Anonymous) 접근 불가

일반 Bucket:        [요청자] →(무료 다운로드)→ [S3]  → 비용: Bucket Owner 부담
Requester Pays:     [요청자] →(유료 다운로드)→ [S3]  → 비용: Requester 부담

14. 핵심 요약 & 시험 포인트

S3 Architecture Overview
├── 보안: IAM Policy + Bucket Policy + Block Public Access (+ ACL)
├── 암호화: SSE-S3(기본) / SSE-KMS(감사 필요) / SSE-C(고객 키) / CSE
│          → 상세: AWS_S3_Security_Notes.md 참고
├── 가용성: Versioning + CRR/SRR Replication
├── 비용: Storage Class + Lifecycle Rules
├── 성능: Multipart Upload + Transfer Acceleration + Prefix 분산
└── 운영: Event Notifications + Batch Operations + Storage Lens

Storage Class 비용 순서 (비쌈 → 저렴)
Standard > Standard-IA > One Zone-IA > Glacier Instant > Glacier Flexible > Deep Archive

Glacier 최소 보존 기간
├── Instant / Flexible Retrieval: 90일
└── Deep Archive:                 180일

Glacier Flexible Retrieval 검색 시간
├── Expedited: 1~5분
├── Standard:  3~5시간
└── Bulk:      5~12시간 (무료)

Glacier Deep Archive 검색 시간
├── Standard: 12시간
└── Bulk:     48시간

📌 시험 자주 출제 포인트 총정리

포인트	내용
Bucket 이름	전 세계 고유, 소문자/숫자/하이픈만, 리전 레벨 생성
최대 Object 크기	5TB
5GB 초과 업로드	Multipart Upload 필수
기본 암호화 (2023~)	SSE-S3 자동 적용, 추가 비용 없음
SSE-C 필수 요건	HTTPS (HTTP 요청 시 거부)
SSE-KMS Cross-Account	Customer Managed Key(CMK) 필수
Bucket Policy vs Default Encryption	Bucket Policy가 먼저 평가됨
MFA Delete 설정 권한	Bucket Owner (Root 계정)만 가능
Versioning Suspend	기존 버전 삭제 안 됨
버저닝 전 파일 Version ID	`null`
Replication 전제조건	소스+대상 모두 Versioning 활성화
기존 객체 복제	S3 Batch Replication 사용
Replication 체이닝	없음 (Bucket 1→2→3 자동 복제 안 됨)
Transfer Acceleration	CloudFront Edge Location 경유
Baseline Performance	Prefix당 PUT 3,500/s, GET 5,500/s
S3 Select	SQL로 서버 사이드 필터링, 전송 비용 절감
S3 Event → SNS/SQS/Lambda	Resource-based Policy 필요 (IAM Role 아님)
S3 Event + EventBridge	18개 이상 Destination, 고급 필터링, Replay 가능
S3 Analytics 대상	Standard → Standard-IA만 (Glacier 불가)
S3 Analytics 소요 시간	24~48시간
Storage Lens Default Dashboard	삭제 불가 (비활성화만 가능)
Storage Lens 데이터 보존	Free: 14일 / Advanced: 15개월
Requester Pays	요청자 비용 부담, 익명 접근 불가
Object Lock	WORM, Versioning 필수
Compliance Mode	Root 포함 누구도 수정/삭제 불가
Governance Mode	특별 권한(`s3:BypassGovernanceRetention`) 있으면 수정 가능
Legal Hold	보존 기간 무관, 무기한 잠금
Glacier Vault Lock	한 번 설정 후 변경 불가
Static Website 403	Block Public Access 또는 Bucket Policy 미설정
One Zone-IA	단일 AZ, AZ 파괴 시 데이터 손실
Intelligent-Tiering 장점	검색(Retrieval) 요금 없음
Pre-signed URL 유효 기간	Console 12h / CLI 최대 604800초(7일)

📚 참고 자료

⚖️ AWS ELB (Elastic Load Balancer) & ASG (Auto Scaling Group)

Wed, 18 Mar 2026 00:00:00 GMT

⚖️ AWS ELB (Elastic Load Balancer) & ASG (Auto Scaling Group)

고가용성(High Availability)과 확장성(Scalability)의 핵심 서비스

ELB는 트래픽을 분산하고, ASG는 인스턴스 수를 자동으로 조절합니다.

1. 확장성 & 고가용성 개념

📈 스케일링 방향

방향	영어 표현	방법	예시
수직 확장 (Scale Up/Down)	Vertical Scalability	인스턴스 크기 증가	t2.micro → t2.large
수평 확장 (Scale Out/In)	Horizontal Scalability (= Elasticity)	인스턴스 수 증가/감소	ASG, 로드 밸런서

수직 확장 (Scale Up):   [작은 서버]  →  [큰 서버]        ← 한계 있음 (하드웨어 상한)
수평 확장 (Scale Out):  [서버1]  →  [서버1][서버2][서버3]  ← 이론상 무제한

수직 확장: RDS, ElastiCache 같은 **비분산 시스템(Non-distributed Systems)**에 일반적
수평 확장: 웹 애플리케이션, 현대 분산 시스템에 일반적

🏢 고가용성 (High Availability)

애플리케이션을 **최소 2개의 데이터 센터(= AZ)**에서 운영
목표: 하나의 데이터 센터 장애 시에도 서비스 지속 (Survive a data center loss)
수평 확장과 함께 설계되는 것이 일반적

EC2 HA 구성 예시:
    [Load Balancer]
    /             \
[EC2 - AZ1]  [EC2 - AZ2]   ← 한 AZ 장애 시 다른 AZ가 트래픽 처리

2. ELB 개요

🔀 로드 밸런서란?

여러 다운스트림 서버(EC2 등)에 트래픽을 분산하는 서버
애플리케이션에 단일 접근 지점(Single Point of Access, DNS) 제공

왜 ELB(관리형)를 쓰는가?

직접 구성	AWS ELB (관리형)
초기 비용 낮음	비용이 있음
유지보수·패치 직접	AWS가 관리 (업그레이드, 유지보수, HA 보장)
설정 복잡	설정 간단 (Configuration knobs 제공)
AWS 서비스 통합 어려움	EC2, ASG, ECS, ACM, CloudWatch, Route 53, WAF 등과 통합

ELB의 주요 역할

다운스트림 인스턴스 장애 시 seamless하게 처리 (Health Check)
SSL 종료(SSL Termination, HTTPS 처리)
쿠키 기반 고정성(Stickiness)
AZ 간 고가용성
퍼블릭/프라이빗 트래픽 분리

❤️ Health Check (헬스 체크)

LB가 인스턴스 정상 여부를 지속적으로 확인하는 기능
특정 포트와 경로(Route)에 요청 → 200 OK면 정상, 아니면 비정상
비정상 인스턴스로는 트래픽을 전송하지 않음

LB → GET /health (포트 80)
       ↓
   200 OK → 정상 → 트래픽 전달
   기타   → 비정상 → 트래픽 차단

3. 로드 밸런서 유형 비교

유형	출시	레이어	프로토콜	주요 특징
CLB (Classic)	2009	L4/L7	HTTP, HTTPS, TCP, SSL	구세대, Deprecated
ALB (Application)	2016	L7	HTTP, HTTPS, WebSocket	경로/호스트/쿼리 기반 라우팅
NLB (Network)	2017	L4	TCP, TLS, UDP	초고성능, 정적 IP
GWLB (Gateway)	2020	L3	IP (GENEVE 6081)	3rd Party 가상 어플라이언스

:::tip 💡 권장: 항상 신세대(ALB, NLB, GWLB) 사용. CLB는 Deprecated. :::

4. ALB (Application Load Balancer)

🌐 특징

레이어 7 (Layer 7, HTTP 레이어) 전용
HTTP/2, WebSocket 지원
HTTP → HTTPS 리다이렉트 지원
고정 호스트명(Fixed Hostname) 제공
클라이언트 IP는 인스턴스에 직접 전달되지 않음 → X-Forwarded-For 헤더로 확인

클라이언트 IP: 1.2.3.4
  │
  ▼
[ALB]  ──→  EC2: X-Forwarded-For: 1.2.3.4
               X-Forwarded-Port: 443
               X-Forwarded-Proto: https

🗺️ 라우팅 규칙 (Routing Rules)

라우팅 기준	예시
URL 경로 (Path)	`/users` → 서비스 A, `/posts` → 서비스 B
호스트명 (Hostname)	`api.example.com` → API 서버, `web.example.com` → 웹 서버
쿼리스트링 (Query String)	`?platform=mobile` → 모바일 서버
HTTP 헤더 (Headers)	특정 헤더 값에 따라 분기

💡 마이크로서비스와 컨테이너에 최적: ECS와 연동 시 동적 포트 매핑(Dynamic Port Mapping) 지원.

🎯 Target Groups (대상 그룹)

대상 유형	설명
EC2 Instances	Auto Scaling Group으로 관리 가능
ECS Tasks	ECS 자체 관리
Lambda Functions	HTTP 요청 → JSON 이벤트로 변환
IP Addresses	반드시 프라이빗 IP

Health Check는 Target Group 레벨에서 수행
ALB는 여러 Target Group으로 동시 라우팅 가능

5. NLB (Network Load Balancer)

⚡ 특징

레이어 4 (Layer 4, 전송 계층) — TCP & UDP 트래픽 처리
초고성능: 초당 수백만 요청 처리, 초저지연(Ultra-low Latency)
AZ당 정적 IP(Static IP) 1개 보유 → Elastic IP 할당 가능 (특정 IP 화이트리스팅에 유리)
극한 성능, TCP/UDP 트래픽 처리에 사용

🎯 Target Groups

EC2 Instances
IP Addresses (반드시 프라이빗 IP)
Application Load Balancer (NLB 뒤에 ALB 배치 가능)
Health Check: TCP, HTTP, HTTPS 프로토콜 지원

[정적 IP: 1.2.3.4]        ← 클라이언트가 고정 IP로 접근 (방화벽 화이트리스팅)
     [NLB]
       │
   [ALB / EC2]

6. GWLB (Gateway Load Balancer)

🛡️ 특징

레이어 3 (Layer 3, 네트워크 계층) — IP 패킷 수준 처리
3rd Party 네트워크 가상 어플라이언스 배포·확장·관리
GENEVE 프로토콜 (포트 6081) 사용

두 가지 역할

역할	설명
Transparent Network Gateway (투명 네트워크 게이트웨이)	모든 트래픽의 단일 진입/출구점
Load Balancer	가상 어플라이언스들에 트래픽 분산

인터넷 트래픽
     │
     ▼
  [GWLB]  ← 모든 트래픽이 먼저 여기를 통과
     │
[방화벽/IDS/IPS 어플라이언스 Fleet]
     │
     ▼
  [EC2 앱]

주요 Use Case: 방화벽(Firewalls), 침입탐지/방지 시스템(IDS/IPS), 딥 패킷 검사(Deep Packet Inspection), 페이로드 조작

7. ELB 주요 기능

🍪 Sticky Sessions (세션 고정, Session Affinity)

동일 클라이언트가 항상 동일한 인스턴스로 라우팅되도록 설정
CLB, ALB, NLB 지원 (NLB는 쿠키 없이 동작)
Use Case: 사용자 세션 데이터(로그인 정보 등)를 인스턴스 로컬에 저장하는 앱

:::warning ⚠️ 단점: 트래픽 불균형 발생 가능 (일부 인스턴스에 부하 집중) :::

쿠키 유형:

쿠키 종류	생성 주체	쿠키 이름	특징
Custom Cookie	애플리케이션(Target)	직접 지정	커스텀 속성 포함 가능, AWSALB/AWSALBAPP/AWSALBTG 이름 사용 불가
Application Cookie	LB	`AWSALBAPP`	ALB 생성
Duration-based Cookie	LB	`AWSALB` (ALB), `AWSELB` (CLB)	만료 시간 기반

🌍 Cross-Zone Load Balancing (교차 AZ 로드 밸런싱)

	활성화 시	비활성화 시
동작	모든 AZ의 인스턴스에 균등 분산	같은 AZ의 인스턴스에만 분산

활성화:  AZ1(10대) + AZ2(2대) → 전체 12대에 균등 분배 (각 8.3%)
비활성화: AZ1(10대) → AZ1 10대만, AZ2(2대) → AZ2 2대만 (각 AZ 50%)

LB 유형	기본값	교차 AZ 데이터 비용
ALB	활성화 (기본)	없음 (No charges)
NLB / GWLB	비활성화 (기본)	활성화 시 데이터 요금 부과
CLB	비활성화 (기본)	없음

🔒 SSL/TLS 인증서

SSL (Secure Sockets Layer) / TLS (Transport Layer Security): 클라이언트 ↔ LB 간 전송 암호화 (In-flight Encryption)
TLS는 SSL의 최신 버전 (현재 대부분 TLS 사용)
인증서는 **CA(Certificate Authority)**에서 발급 (Comodo, DigiCert, GoDaddy 등)
LB는 X.509 인증서 사용
*ACM (AWS Certificate Manager)**으로 인증서 관리 권장

📛 SNI (Server Name Indication)

하나의 웹 서버(LB)에 여러 SSL 인증서를 로드하여 여러 도메인을 서비스하는 기술
클라이언트가 SSL 핸드셰이크 시 접속할 호스트명을 먼저 전달 → 서버가 올바른 인증서 선택
ALB, NLB, CloudFront만 지원 — CLB는 미지원

LB 유형	SSL 인증서	SNI 지원
CLB	단 1개	❌
ALB	여러 개 (리스너당)	✅
NLB	여러 개 (리스너당)	✅

⏳ Connection Draining (연결 드레이닝)

LB 유형	명칭
CLB	Connection Draining
ALB / NLB	Deregistration Delay (등록 해제 지연)

인스턴스가 비정상이거나 등록 해제 중일 때 진행 중인 요청(In-flight Requests)을 완료할 시간 부여
해제 중인 인스턴스에 새 요청 전달 중단
설정 범위: 1~3600초 (기본값: 300초)
0으로 설정 시 비활성화 (즉시 연결 종료)

💡 짧은 요청이 많은 서비스: 낮은 값 설정 (ex: 30초). 긴 처리가 필요한 서비스: 높은 값 설정.

8. ASG (Auto Scaling Group)

📐 개념

[Load Balancer]
      │
  [ASG]
  ├── EC2 (최소: min)
  ├── EC2 (현재: desired)
  └── EC2 (최대: max)

트래픽 증가 → Scale Out (인스턴스 추가)
트래픽 감소 → Scale In  (인스턴스 제거)

비용 없음: ASG 자체는 무료, 실행되는 EC2 인스턴스 비용만 지불
비정상 인스턴스 감지 시 자동으로 새 인스턴스 생성 (Re-create)
새 인스턴스를 자동으로 LB에 등록

⚙️ ASG 구성 요소

Launch Template (시작 템플릿) — 인스턴스 설정의 청사진

항목	내용
AMI + Instance Type	이미지와 인스턴스 사양
EC2 User Data	부트스트랩 스크립트
EBS Volumes	스토리지 설정
Security Groups	방화벽 규칙
SSH Key Pair	접속 키
IAM Roles	인스턴스에 부여할 권한
Network + Subnets	배치할 네트워크 설정
Load Balancer	연결할 LB

:::important 구세대 Launch Configurations는 Deprecated. 반드시 Launch Template 사용. :::

크기 설정:

Min Size: 최소 실행 인스턴스 수 (가용성 하한)
Max Size: 최대 실행 인스턴스 수 (비용 상한)
Desired Capacity: 현재 목표 인스턴스 수

📊 CloudWatch와 ASG 연동

CloudWatch 알람(Alarm)이 트리거되면 Scale Out/In 정책 실행
메트릭 예시: 평균 CPU 사용률 (Average CPU) — ASG 전체 인스턴스의 평균값

CPU > 70% → CloudWatch Alarm → ASG Scale Out (+2 인스턴스)
CPU < 30% → CloudWatch Alarm → ASG Scale In  (-1 인스턴스)

9. ASG 스케일링 정책

🔄 Dynamic Scaling (동적 스케일링)

정책 유형	설명	예시
Target Tracking Scaling (목표 추적)	특정 지표를 목표값으로 유지	평균 CPU를 40%로 유지
Simple / Step Scaling (단순/단계)	알람 트리거 시 고정 수량 추가/제거	CPU > 70% → +2, CPU < 30% → -1
Scheduled Scaling (예약)	알려진 사용 패턴에 맞춰 사전 설정	매주 월요일 09:00에 5대로 확장

🔮 Predictive Scaling (예측 스케일링)

ML로 미래 부하를 예측하여 사전에 스케일링 예약
반복적인 패턴이 있는 워크로드에 효과적

📏 스케일링에 좋은 지표

지표	설명	적합한 상황
CPU Utilization (CPU 사용률)	ASG 전체 평균 CPU	컴퓨팅 집약적 앱
RequestCountPerTarget	인스턴스당 요청 수	웹 서버, API 서버
Average Network In/Out	평균 네트워크 입출력	네트워크 집약적 앱
Custom Metric	CloudWatch에 직접 푸시한 지표	비즈니스 로직 기반

⏸️ Scaling Cooldown (스케일링 쿨다운)

스케일링 활동 후 기본 300초(5분) 대기 — 지표가 안정될 때까지 추가 스케일링 중단
권장: 미리 구성된 AMI (Ready-to-use AMI) 사용 → 인스턴스 준비 시간 단축 → 쿨다운 기간 축소 가능

🔐 LB Security Groups 구성 패턴

인터넷 (0.0.0.0/0)
        │ HTTP/HTTPS
        ▼
[Load Balancer Security Group]   ← 0.0.0.0/0:80, 443 허용
        │ 포트 80
        ▼
[EC2 Security Group]             ← LB Security Group에서 온 트래픽만 허용
        (인터넷에서 직접 접근 불가)

10. 핵심 요약

로드 밸런서 선택 가이드
├── HTTP/HTTPS, 경로·호스트 기반 라우팅   → ALB (Layer 7)
├── TCP/UDP, 초고성능, 정적 IP 필요       → NLB (Layer 4)
├── 3rd Party 보안 어플라이언스 삽입      → GWLB (Layer 3)
└── (구세대)                              → CLB (사용 지양)

SNI 지원: ALB, NLB, CloudFront (CLB 미지원)
Cross-Zone LB: ALB 기본 활성화, NLB/GWLB 기본 비활성화

ASG 스케일링 정책
├── Target Tracking    → 목표 지표 자동 유지 (가장 간단)
├── Simple/Step        → 알람 기반 고정 수량 조정
├── Scheduled          → 사전 예약 (알려진 패턴)
└── Predictive         → ML 기반 사전 예측

핵심 수치
├── Connection Draining 범위: 1~3600초 (기본 300초)
├── ASG Cooldown 기본: 300초
└── ELB Health Check: 포트 + 경로(/health 일반적)

📌 시험 자주 출제 포인트

포인트	내용
클라이언트 실제 IP 확인	ALB → X-Forwarded-For 헤더
NLB 정적 IP	AZ당 1개 정적 IP, Elastic IP 할당 가능
GWLB 프로토콜	GENEVE (포트 6081)
SNI 지원 LB	ALB, NLB (CLB 미지원)
CLB SSL 제한	SSL 인증서 1개만, 다중 도메인은 CLB 여러 개 필요
Cross-Zone 과금	NLB/GWLB는 활성화 시 데이터 요금 부과
ASG 쿨다운 단축	미리 구성된 AMI 사용 → 부팅 시간 단축
Launch Configurations	Deprecated → Launch Template 사용

📚 참고 자료

🗄️ AWS RDS & Aurora (관계형 데이터베이스)

Wed, 18 Mar 2026 00:00:00 GMT

🗄️ AWS RDS & Aurora (관계형 데이터베이스)

AWS 관리형 관계형 DB 서비스 — 시험 고빈도 영역

RDS는 다양한 엔진을 지원하고, Aurora는 AWS 전용 고성능 DB입니다.

1. RDS 개요

🔑 RDS (Relational Database Service)란?

SQL 기반 관계형 데이터베이스를 위한 AWS 관리형 서비스 (Managed DB Service)
사용자가 DB 엔진만 선택하면 나머지는 AWS가 운영

지원 DB 엔진

엔진	특징
PostgreSQL	오픈소스, 기능 풍부
MySQL	가장 널리 사용되는 오픈소스
MariaDB	MySQL 포크, 오픈소스
Oracle	상용 엔터프라이즈 DB
Microsoft SQL Server	상용 엔터프라이즈 DB
IBM DB2	상용 엔터프라이즈 DB
Aurora	AWS 독자 개발 (PostgreSQL/MySQL 호환)

2. RDS vs EC2에서 DB 직접 운영

항목	RDS (관리형)	EC2에서 직접 운영
프로비저닝·OS 패치	AWS 자동	직접 관리
연속 자동 백업 (PITR)	✅	직접 구성
모니터링 대시보드	✅	직접 구성
읽기 복제본 (Read Replica)	✅ (간편 설정)	직접 구성
Multi-AZ 구성	✅ (간편 설정)	직접 구성
유지보수 창 (Maintenance Window)	✅	직접 관리
스토리지 자동 확장	✅	직접 관리
SSH 접속	❌ (관리 불가)	✅
스토리지	EBS 기반	선택 가능

3. RDS Storage Auto Scaling

RDS 인스턴스의 스토리지가 부족해질 때 자동으로 용량 확장
수동으로 DB 스토리지를 확장할 필요 없음
Maximum Storage Threshold (최대 스토리지 임계값) 설정 필수

자동 확장 조건 (모두 충족 시)

1️⃣ 여유 스토리지 < 할당 스토리지의 10%
        AND
2️⃣ 저용량 상태가 5분 이상 지속
        AND
3️⃣ 마지막 수정으로부터 6시간 이상 경과

💡 Use Case: 예측 불가한 워크로드(Unpredictable Workloads)가 있는 애플리케이션. 모든 RDS 엔진 지원.

4. RDS Read Replicas (읽기 복제본)

📖 개념

읽기 요청(SELECT)을 메인 DB에서 분산하여 읽기 성능 향상
비동기 복제 (ASYNC Replication) → 최종 일관성 (Eventually Consistent)
- 복제 전에 읽으면 약간 오래된(Stale) 데이터가 조회될 수 있음

[Primary DB] ──ASYNC 복제──→ [Read Replica 1]
             ──ASYNC 복제──→ [Read Replica 2]  ← 읽기 전용 쿼리
             ──ASYNC 복제──→ [Read Replica N]

📋 주요 특성

항목	내용
최대 복제본 수	15개
복제본 위치	동일 AZ, 교차 AZ, 교차 리전 모두 가능
복제 방식	비동기 (ASYNC)
승격 가능 여부	✅ 독립 DB로 승격 가능 (Promote to own DB)
사용 가능 작업	SELECT만 (INSERT, UPDATE, DELETE 불가)

:::warning ⚠️ 애플리케이션 수정 필요: Read Replica를 사용하려면 연결 문자열(Connection String)을 복제본 엔드포인트로 업데이트해야 함. :::

💰 Read Replica 네트워크 비용

복제본 위치	데이터 전송 비용
동일 리전 내 (AZ가 달라도)	무료
교차 리전 (Cross Region)	요금 부과 (비동기 복제 데이터 전송)

💡 Read Replica 활용 시나리오

[상황]
운영 DB: 정상 트래픽 처리 중
팀 요청: 분석용 리포팅 애플리케이션 추가

[잘못된 방법]  운영 DB에서 직접 분석 쿼리 실행 → 성능 저하
[올바른 방법]  Read Replica 생성 → 분석 쿼리는 복제본에서 실행
              → 운영 DB 영향 없음

5. RDS Multi-AZ (재해 복구)

🔄 개념

동기 복제 (SYNC Replication) — 메인 DB의 모든 변경사항을 즉시 Standby에 동기화
단일 DNS 이름 — 장애 시 애플리케이션 수정 없이 자동 페일오버 (Automatic Failover)

[Primary DB] ──SYNC 복제──→ [Standby DB]
     │                           │
     └────── 단일 DNS ───────────┘
             (자동 전환)

📋 주요 특성

항목	내용
복제 방식	동기 (SYNC)
목적	재해 복구 (Disaster Recovery, DR)
엔드포인트	단일 DNS 이름 (페일오버 시 앱 수정 불필요)
페일오버 트리거	AZ 장애, 네트워크 장애, 인스턴스 장애, 스토리지 장애
스케일링 목적	❌ (읽기 분산에 사용 불가, 스케일링 아님)

:::tip 📌 Read Replica는 Multi-AZ로 설정 가능 → Standby 복제본을 이중 보호 :::

🔧 Single-AZ → Multi-AZ 전환

Zero Downtime — DB 중지 없이 전환 가능
AWS 콘솔에서 "Modify(수정)" 클릭만으로 완료

내부 동작:
1. 현재 DB 스냅샷 생성
2. 새 AZ에 스냅샷에서 Standby DB 복원
3. 두 DB 간 동기화 확립 완료

📊 Read Replica vs Multi-AZ 비교

항목	Read Replica	Multi-AZ
복제 방식	비동기 (ASYNC)	동기 (SYNC)
주요 목적	읽기 성능 향상	재해 복구 (DR)
쓰기 가능 여부	❌	❌ (Standby는 쓰기 불가)
엔드포인트	복제본별 별도	단일 DNS
AZ 수	1개 이상	2개 (Primary + Standby)
수	최대 15개	1개 (Standby)

6. RDS Custom

Oracle, Microsoft SQL Server에만 지원
표준 RDS: AWS가 DB와 OS를 완전 관리 (SSH 불가)
RDS Custom: OS와 DB에 대한 관리자 수준 접근 권한 제공

기능	RDS	RDS Custom
설정 자동화	✅	✅ (기본)
OS 접근	❌	✅
DB 접근 (SSH/SSM)	❌	✅
패치 직접 설치	❌	✅
네이티브 기능 활성화	❌	✅

:::note 💡 커스터마이징 전: 반드시 DB 스냅샷 생성 후 Automation Mode 비활성화 :::

7. Amazon Aurora

✨ 개요

AWS가 독자 개발한 독점 기술 (Proprietary Technology) (오픈소스 아님)
PostgreSQL, MySQL과 호환 (드라이버 교체만으로 마이그레이션 가능)
AWS 클라우드에 최적화: MySQL 대비 5배, PostgreSQL 대비 3배 성능 향상 주장
스토리지 자동 증가: 10GB 단위, 최대 128TB (이전 256TB에서 업데이트)
최대 15개 복제본, 복제 지연 10ms 미만 (Sub 10ms replica lag)
즉각적인 페일오버 (Instantaneous Failover) — HA Native
RDS 대비 약 20% 비용 증가 (하지만 효율성으로 상쇄)

🏗️ Aurora 고가용성 & 스토리지 아키텍처

[Aurora Writer (Master)]  →  [Read Replica] × 최대 15개
         │
         ▼
[분산 스토리지 클러스터]
├── AZ 1: 복사본 2개
├── AZ 2: 복사본 2개
└── AZ 3: 복사본 2개
     → 총 6개 복사본 (3 AZ × 2)

항목	내용
총 데이터 복사본	6개 (3개 AZ에 각 2개씩)
쓰기 성공 기준	6개 중 4개 이상 성공 시
읽기 성공 기준	6개 중 3개 이상 가능
자가 복구	Peer-to-Peer 복제로 자동 복구 (Self-healing)
스토리지 구성	수백 개 볼륨에 스트라이핑(Striped)
Master 페일오버	30초 이내 자동 전환

🔗 Aurora 엔드포인트

[Writer Endpoint] ──→ [Master (쓰기)]          ← 항상 마스터를 가리킴
[Reader Endpoint] ──→ [Read Replicas (읽기)]   ← 복제본 간 로드 밸런싱
[Custom Endpoint] ──→ [특정 복제본 서브셋]      ← 분석 쿼리 등 특수 목적

엔드포인트 유형	설명
Writer Endpoint	마스터 자동 추적 (페일오버 시 자동 전환)
Reader Endpoint	모든 Read Replica에 연결 분산
Custom Endpoint	특정 인스턴스 서브셋 지정 (고성능 인스턴스에만 분석 쿼리 전달)

⚙️ Aurora DB 클러스터 주요 기능

기능	설명
Automatic Failover (자동 페일오버)	Master 장애 시 30초 내 자동 전환
Backup & Recovery	자동 백업, PITR 지원
Isolation & Security	VPC, KMS 암호화, IAM 통합
Industry Compliance	각종 규정 준수
Push-button Scaling	버튼 클릭으로 용량 조정
Automated Patching	Zero Downtime 자동 패치
Advanced Monitoring	세밀한 모니터링
Backtrack	백업 없이 특정 시점으로 데이터 복원 (Restore data at any point in time without using backups)

8. Aurora 고급 기능

🌐 Aurora Serverless

실제 사용량 기반 자동 DB 인스턴스화 및 오토스케일링
비정기적(Infrequent), 간헐적(Intermittent), 예측 불가한(Unpredictable) 워크로드에 적합
용량 계획 불필요
초 단위 과금 (Pay per second) — 경우에 따라 비용 효율적

🌍 Global Aurora

유형	설명
Aurora Cross Region Read Replicas	재해 복구(DR)용, 간단히 구성 가능
Aurora Global DB ⭐	전용 글로벌 아키텍처

Aurora Global DB 특성:

1개 Primary Region (읽기/쓰기)
최대 5개 Secondary(보조) 리전 (읽기 전용)
보조 리전당 최대 16개 Read Replica
리전 간 복제 지연 1초 미만 (< 1 second)
보조 리전 승격 시 RTO(Recovery Time Objective) < 1분
지역별 지연 시간 감소에 효과적

🤖 Aurora Machine Learning

Aurora에서 SQL 쿼리로 ML 기반 예측 수행
Aurora ↔ AWS ML 서비스 간 최적화된 보안 통합

지원 서비스	용도
Amazon SageMaker	ML 모델 (범용)
Amazon Comprehend	감성 분석 (Sentiment Analysis)

Use Case: 사기 탐지(Fraud Detection), 광고 타겟팅, 감성 분석, 상품 추천

🔄 Babelfish for Aurora PostgreSQL

Aurora PostgreSQL이 Microsoft SQL Server의 T-SQL 명령을 이해하도록 지원
MS SQL Server 기반 애플리케이션을 코드 수정 거의 없이 Aurora PostgreSQL로 마이그레이션 가능

9. RDS & Aurora 백업

🔄 자동 백업 (Automated Backups)

항목	RDS	Aurora
백업 주기	매일 전체 백업 (지정 백업 창)	지속 백업
트랜잭션 로그	5분마다 백업	지속
PITR (Point-in-Time Recovery)	최근 5분 전까지 복원 가능	동일
보존 기간	1~35일 (0으로 설정 시 비활성화)	1~35일 (비활성화 불가)

📸 수동 스냅샷 (Manual DB Snapshots)

사용자가 직접 트리거
보존 기간 무제한 (자동 백업은 최대 35일)
오래 DB를 중지할 경우: 스냅샷 저장 후 삭제 → 나중에 복원 (스토리지 비용 절감)

🔃 복원 옵션 (Restore Options)

방법	설명
백업/스냅샷 복원	새 DB 인스턴스 생성 (기존 DB 덮어쓰기 불가)
MySQL RDS ← S3	온프레미스 DB 백업을 S3에 저장 후 새 RDS에 복원
MySQL Aurora ← S3	Percona XtraBackup으로 백업 → S3 → 새 Aurora 클러스터 복원

🔁 Aurora Database Cloning (클로닝)

기존 Aurora DB 클러스터에서 새 클러스터 빠르게 생성
스냅샷 & 복원보다 빠름
Copy-on-Write 프로토콜 사용:

초기 상태: 원본과 클론이 동일한 스토리지 볼륨 공유 (복사 없음 → 빠름)
         │
         ▼
클론에 데이터 변경 발생 시: 변경된 데이터만 별도 스토리지에 분리 저장

Use Case: 프로덕션 DB에 영향 없이 스테이징 DB 즉시 생성 (Useful to create a staging database from a production database without impacting the production database)

10. RDS & Aurora 보안

🔐 보안 레이어

보안 항목	내용
저장 데이터 암호화 (At-rest Encryption)	AWS KMS 사용, 생성 시 정의 필수
전송 데이터 암호화 (In-flight Encryption)	TLS 기본 활성화 (AWS TLS 루트 인증서 사용)
IAM 인증	사용자명/비밀번호 대신 IAM 역할로 DB 접속
보안 그룹 (Security Groups)	RDS/Aurora에 대한 네트워크 접근 제어
SSH 접속	❌ 불가 (RDS Custom 제외)
감사 로그 (Audit Logs)	활성화 시 CloudWatch Logs로 전송 (장기 보존)

🔑 암호화 관련 핵심 규칙

마스터 암호화 ← Read Replica 암호화 여부 결정
  │
  ├── 마스터 암호화 → 복제본도 암호화 가능
  └── 마스터 미암호화 → 복제본 암호화 불가 ❌

미암호화 DB → 암호화 변환 방법:
  1. DB 스냅샷 생성
  2. 스냅샷 복사 시 암호화 활성화
  3. 암호화된 스냅샷으로 새 DB 복원

11. 핵심 비교 요약

RDS vs Aurora

항목	RDS	Aurora
엔진	여러 엔진 선택	PostgreSQL/MySQL 호환
성능	표준	MySQL 5배, PostgreSQL 3배
스토리지	EBS (수동 확장)	자동 확장 (최대 128TB)
Read Replica 수	최대 15개	최대 15개
복제 지연	일반적	Sub 10ms
페일오버	수분	30초 이내
비용	기준	20% 높음
데이터 복사본	1~2개	6개 (3 AZ × 2)
SSH 접속	❌	❌
Backtrack	❌	✅
Serverless	❌	✅

📌 시험 자주 출제 포인트

포인트	내용
Read Replica 복제	비동기 (ASYNC) → 최종 일관성
Multi-AZ 복제	동기 (SYNC) → 재해 복구 목적
Multi-AZ 목적	DR (재해 복구), 스케일링 아님
Read Replica 비용	동일 리전은 무료, 교차 리전은 유료
Read Replica 용도	SELECT만 (쓰기 불가)
Single→Multi-AZ	Zero Downtime 전환 가능
Aurora 복사본 수	6개 (3 AZ, 각 2개)
Aurora 쓰기 정족수	6개 중 4개
Aurora 읽기 정족수	6개 중 3개
Aurora 페일오버	30초 이내
Aurora Global 복제 지연	1초 미만
Aurora Global RTO	리전 승격 시 1분 미만
Aurora Backtrack	백업 없이 특정 시점 복원
Aurora Cloning	Copy-on-Write, 스테이징 DB 생성에 활용
RDS 자동 백업 보존	최대 35일
Aurora 자동 백업	비활성화 불가
MySQL Aurora S3 복원	Percona XtraBackup 필요
RDS 암호화 키	AWS KMS
암호화 DB 복제본	마스터 미암호화 시 복제본 암호화 불가
RDS Custom 지원 엔진	Oracle, MS SQL Server만

📚 참고 자료

💾 AWS Storage

Wed, 18 Mar 2026 00:00:00 GMT

💾 AWS Storage

EC2와 함께 사용하는 핵심 스토리지 서비스 정리

EBS · EFS · EC2 Instance Store · AMI

1. 스토리지 유형 비교
2. EBS (Elastic Block Store)
3. EBS 볼륨 타입
4. EBS Snapshots (스냅샷)
5. EBS Encryption (암호화)
6. EBS Multi-Attach
7. EC2 Instance Store
8. AMI (Amazon Machine Image)
9. EFS (Elastic File System)
10. 핵심 비교 요약
📌 시험 자주 출제 포인트
📚 참고 자료

1. 스토리지 유형 비교

EC2 인스턴스가 사용할 수 있는 스토리지 종류

├── Block Storage (블록 스토리지)
│   ├── EBS (Elastic Block Store)  — 네트워크 연결, 영구, AZ 종속
│   └── EC2 Instance Store         — 하드웨어 직결, 임시(Ephemeral), 초고속
│
└── File Storage (파일 스토리지)
    └── EFS (Elastic File System)  — 네트워크 파일시스템, 멀티 AZ, 멀티 인스턴스

항목	EBS	EC2 Instance Store	EFS
연결 방식	네트워크 (Network-attached)	하드웨어 직결 (Hardware)	네트워크 파일시스템
영속성	✅ 영구 (인스턴스 종료 후에도 유지 가능)	❌ 임시 (인스턴스 중지/종료 시 소멸)	✅ 영구
AZ 범위	특정 AZ에 종속	특정 인스턴스에 종속	멀티 AZ 공유 가능
성능	좋음 (설정에 따라 다름)	최고 (직결 I/O)	좋음 (처리량 확장 가능)
공유 가능	제한적 (Multi-Attach: io1/io2만)	❌	✅ 수백 인스턴스 동시 마운트
OS 지원	Linux, Windows	Linux, Windows	Linux 전용 (POSIX)
비용	프로비저닝 용량 기준 과금	인스턴스 비용에 포함	사용량 기준 과금 (gp2의 약 3배)

2. EBS (Elastic Block Store)

📦 개념

"네트워크 USB 스틱 (Network USB Stick)" — 인스턴스와 네트워크로 통신
실행 중인 인스턴스에 연결 가능한 네트워크 드라이브 (Network Drive)
인스턴스 종료(Terminate) 후에도 데이터 영구 보존 가능
특정 AZ에 종속 — AZ 간 이동 불가 (스냅샷을 통해 이전)

[EC2 Instance]  ←── 네트워크 ───→  [EBS Volume]
  us-east-1a                         us-east-1a (동일 AZ 필수)

⚙️ 주요 특성

속성	설명
용량 (Capacity)	생성 시 크기(GiB)와 IOPS를 미리 프로비저닝
과금 방식	프로비저닝한 전체 용량 기준 (사용량 무관)
용량 변경	운영 중 온라인으로 증가 가능 (감소 불가)
연결 대상	기본적으로 한 인스턴스에만 연결 (Multi-Attach 예외)

🗑️ Delete on Termination 속성

볼륨 유형	기본값	의미
루트 EBS 볼륨 (Root Volume)	활성화 (Enabled)	인스턴스 종료 시 자동 삭제
추가 EBS 볼륨 (Additional Volume)	비활성화 (Disabled)	인스턴스 종료 후에도 볼륨 유지

💡 실무 팁: 데이터 보호가 필요한 경우 루트 볼륨의 Delete on Termination을 비활성화하거나, 별도 데이터 볼륨을 추가로 구성하세요.

3. EBS 볼륨 타입

시험 핵심: 부트 볼륨(Boot Volume)으로 사용 가능한 타입은 gp2, gp3, io1, io2 Block Express 뿐. HDD 계열(st1, sc1)은 부트 볼륨 불가.

📊 전체 타입 비교

타입	분류	크기 범위	최대 IOPS	최대 처리량	부트 볼륨	주요 용도
gp3	SSD 범용	1GiB~16TiB	16,000	1,000 MiB/s	✅	대부분의 워크로드 ⭐
gp2	SSD 범용	1GiB~16TiB	16,000	250 MiB/s	✅	gp3 전환 권장
io1	SSD 고성능	4GiB~16TiB	64,000 (Nitro)	1,000 MiB/s	✅	고성능 DB
io2 Block Express	SSD 고성능	4GiB~64TiB	256,000	4,000 MiB/s	✅	미션 크리티컬 DB
st1	HDD 처리량 최적화	125GiB~16TiB	500	500 MiB/s	❌	빅데이터, 로그
sc1	HDD 저비용	125GiB~16TiB	250	250 MiB/s	❌	콜드 데이터, 최저가

🔵 General Purpose SSD (gp3 / gp2)

gp3 — 현재 권장 범용 타입 ⭐

기본 IOPS 3,000, 처리량 125 MiB/s 제공
IOPS(최대 16,000)와 처리량(최대 1,000 MiB/s)을 독립적으로 설정 가능
적합: 시스템 부트 볼륨, 가상 데스크톱, 개발/테스트 환경

gp2 — 구세대 (마이그레이션 권장)

IOPS와 볼륨 크기가 연동 (3 IOPS/GiB), 크기 늘려야 IOPS 증가
5,334 GiB에서 최대 IOPS(16,000) 도달
소규모 볼륨은 3,000 IOPS까지 버스트 가능

💡 gp2 → gp3 전환: 동일 성능 기준 약 20% 비용 절감. 독립 IOPS 설정으로 유연성도 향상.

🟠 Provisioned IOPS SSD (io1 / io2 Block Express)

지속적인 고IOPS가 필요한 미션 크리티컬 비즈니스 애플리케이션
DB 워크로드처럼 스토리지 성능과 일관성에 민감한 애플리케이션에 최적
16,000 IOPS 초과가 필요한 경우 필수

항목	io1	io2 Block Express
크기	4GiB ~ 16TiB	4GiB ~ 64TiB
최대 PIOPS	64,000 (Nitro EC2) / 32,000 (기타)	256,000
IOPS:GiB 비율	50:1	1,000:1
지연 시간	낮음	서브 밀리초 (Sub-millisecond)
EBS Multi-Attach	✅	✅

🟤 Hard Disk Drives (st1 / sc1)

부트 볼륨으로 사용 불가
크기 범위: 125GiB ~ 16TiB

타입	별칭	최대 처리량	최대 IOPS	적합한 용도
st1	Throughput Optimized HDD (처리량 최적화 HDD)	500 MiB/s	500	빅데이터, 데이터 웨어하우스, 로그 처리
sc1	Cold HDD (콜드 HDD)	250 MiB/s	250	비정기 접근 데이터, 최저 비용

4. EBS Snapshots (스냅샷)

📸 개념

특정 시점의 EBS 볼륨 백업 (Point-in-time Backup)
스냅샷 시 볼륨을 꼭 분리(Detach)할 필요는 없으나 권장
스냅샷은 AZ 또는 리전 간 복사 가능 → AZ 간 볼륨 이전 수단

us-east-1a [EBS Volume] → 스냅샷 생성 → us-east-1b [새 EBS Volume] 복원
                             (S3에 저장됨)

✨ 스냅샷 주요 기능

기능	설명	비용/속도
EBS Snapshot Archive	스냅샷을 '아카이브 티어(Archive Tier)'로 이동	75% 저렴, 복원에 24~72시간 소요
Recycle Bin (휴지통)	삭제된 스냅샷을 지정 기간 동안 보존	보존 기간: 1일~1년 설정 가능
Fast Snapshot Restore (FSR)	스냅샷의 전체 초기화를 강제하여 첫 사용 시 지연 없음	비용 높음 ($$$), 즉시 사용 필요 시

💡 실무 팁: 자주 접근하지 않는 스냅샷은 Archive Tier로 이동하고, 실수 삭제 방지를 위해 Recycle Bin 규칙을 설정하세요.

5. EBS Encryption (암호화)

🔒 암호화된 EBS 볼륨의 특성

볼륨 내 저장 데이터 (Data at rest) 암호화
인스턴스 ↔ 볼륨 간 전송 데이터 (Data in flight) 암호화
해당 볼륨으로 생성된 모든 스냅샷 암호화
암호화된 스냅샷으로 생성한 모든 볼륨 암호화
암호화/복호화는 AWS가 투명하게 처리 (사용자가 별도 조작 불필요)
지연 시간에 미치는 영향 최소화
AWS KMS (AES-256) 키 활용

🔄 미암호화 볼륨 → 암호화 변환 절차

1️⃣ 기존 미암호화 EBS 볼륨의 스냅샷 생성
        │
        ▼
2️⃣ 스냅샷 복사 시 암호화 옵션 활성화 (Encrypt the EBS snapshot using copy)
        │
        ▼
3️⃣ 암호화된 스냅샷으로 새 EBS 볼륨 생성 (볼륨도 자동으로 암호화됨)
        │
        ▼
4️⃣ 원본 인스턴스에 새 암호화 볼륨 연결

📌 시험 포인트: 미암호화 스냅샷을 복사(Copy)할 때 암호화를 활성화하면 암호화된 스냅샷으로 변환 가능. 암호화된 볼륨의 스냅샷은 항상 암호화됨.

6. EBS Multi-Attach

동일 AZ 내 여러 EC2 인스턴스에 같은 EBS 볼륨을 동시에 연결
각 인스턴스는 볼륨에 대한 전체 읽기/쓰기 권한 보유
io1 / io2 Block Express 타입만 지원

항목	내용
최대 연결 인스턴스 수	16개
사용 가능 파일시스템	클러스터 인식 파일시스템 필수 (XFS, EXT4 등 일반 파일시스템 사용 불가)
주요 Use Case	클러스터형 Linux 애플리케이션의 고가용성 확보 (ex: Teradata)

:::warning 일반 XFS, EXT4 파일시스템은 Multi-Attach 환경에서 데이터 충돌 발생. OCFS2, GFS2 같은 클러스터 인식 파일시스템 사용 필요. :::

7. EC2 Instance Store

⚡ 개념

EC2 인스턴스에 물리적으로 직결된 하드웨어 디스크
네트워크 경유 없이 직접 I/O → EBS보다 훨씬 높은 I/O 성능

⚠️ 핵심 제약: 임시 스토리지 (Ephemeral Storage)

인스턴스 중지(Stop) 또는 종료(Terminate) → 데이터 완전 소멸 ❌
인스턴스 재부팅(Reboot) → 데이터 유지 ✅

항목	내용
성능	매우 높음 (수백만 IOPS 가능)
영속성	❌ 임시 (인스턴스 중지/종료 시 소멸)
하드웨어 장애 시	데이터 손실 위험
백업/복제	사용자 책임

적합한 Use Case:

버퍼 (Buffer)
캐시 (Cache)
임시 데이터 (Scratch data / Temporary content)
빠른 읽기/쓰기가 필요한 임시 연산

❌ 데이터베이스, 영구 보관 데이터에는 절대 사용 금지

8. AMI (Amazon Machine Image)

🖼️ 개념

AMI (Amazon Machine Image, 아마존 머신 이미지): EC2 인스턴스의 커스터마이징 템플릿
OS, 소프트웨어, 설정, 모니터링 에이전트 등을 미리 패키징
빠른 부팅/설정: 필요한 소프트웨어가 이미 포함되어 있어 User Data 스크립트 최소화
특정 리전에 귀속, 리전 간 복사 가능

📂 AMI 소스 유형

유형	설명	예시
Public AMI	AWS가 제공하는 공식 AMI	Amazon Linux 2, Ubuntu, Windows
Own AMI	직접 생성·관리하는 커스텀 AMI	사내 표준 이미지
AWS Marketplace AMI	벤더가 제공하는 상용 AMI	방화벽, DB, 보안 솔루션 등

🛠️ AMI 생성 프로세스

1️⃣ EC2 인스턴스 시작 후 소프트웨어/설정 커스터마이징
        │
        ▼
2️⃣ 인스턴스 중지 (데이터 무결성 보장을 위해 Stop 권장)
        │
        ▼
3️⃣ AMI 빌드 (내부적으로 EBS 스냅샷도 함께 생성)
        │
        ▼
4️⃣ 다른 인스턴스를 해당 AMI로 신속하게 실행

💡 골든 AMI (Golden AMI) 패턴: 표준화된 기업 환경 이미지를 AMI로 만들어 두고, Auto Scaling Group에서 사용. 배포 속도와 일관성 향상.

9. EFS (Elastic File System)

📁 개념

관리형 NFS (Network File System) — 여러 EC2에 동시에 마운트 가능
멀티 AZ에서 동시 접근 가능
용량 자동 확장 (페타바이트 규모까지), 사용량 기반 과금 (Pay-per-use)
Linux 기반 AMI 전용 (Windows 미지원, POSIX 파일시스템)
NFSv4.1 프로토콜 사용
보안 그룹(Security Group)으로 접근 제어
KMS 기반 저장 데이터 암호화

           [EFS]
          /  |  \
    [EC2]  [EC2]  [EC2]
    AZ-1   AZ-2   AZ-3
    (동시 마운트 가능, 파일 공유)

주요 Use Case: 콘텐츠 관리(Content Management), 웹 서빙(Web Serving), 데이터 공유, WordPress

⚡ 성능 모드 (Performance Mode)

EFS 생성 시 설정, 이후 변경 불가

모드	특징	적합한 Use Case
General Purpose (기본값)	저지연, 범용	웹 서버, CMS, 일반 파일 공유
Max I/O	높은 지연 허용, 높은 처리량, 고도 병렬 처리	빅데이터, 미디어 처리, HPC

🔄 처리량 모드 (Throughput Mode)

모드	설명	특징
Bursting	저장 용량 기반 처리량 (1TB = 50MiB/s + 최대 100MiB/s 버스트)	예측 가능한 소규모 워크로드
Provisioned	저장 용량과 무관하게 원하는 처리량 설정	ex: 1TiB 용량에 1GiB/s 처리량
Elastic ⭐	워크로드에 따라 처리량 자동 확장/축소	읽기 최대 3GiB/s, 쓰기 최대 1GiB/s, 예측 불가한 워크로드에 권장

🗂️ 스토리지 클래스 (Storage Classes)

라이프사이클 정책(Lifecycle Policy)으로 N일 후 자동 계층 이동

계층	접근 빈도	특징
Standard	자주 접근	기본 계층, 빠른 응답
Infrequent Access (EFS-IA)	비정기 접근	저장 비용 저렴, 조회 시 추가 요금
Archive	연 몇 차례	50% 더 저렴

💡 비용 절감: 라이프사이클 정책으로 90% 이상 비용 절감 가능

🌐 가용성 및 내구성 (Availability & Durability)

유형	특징	적합한 환경
Standard (Multi-AZ)	여러 AZ에 분산 저장	프로덕션
One Zone	단일 AZ	개발/테스트, 비용 절감 필요 시
One Zone-IA	단일 AZ + 비정기 접근 계층	최대 비용 절감

10. 핵심 비교 요약

EBS vs EFS vs Instance Store

데이터 영속성
  영구 ──────────────────────────── 임시
  EFS          EBS          EC2 Instance Store

공유 범위
  멀티 인스턴스/멀티 AZ ──────── 단일 인스턴스
  EFS              EBS (기본)    Instance Store

성능
  중간           중간~높음       최고 (직결)
  EFS             EBS            Instance Store

상황	선택
OS 루트 볼륨	EBS gp3
고성능 DB (높은 IOPS)	EBS io2 Block Express
여러 인스턴스 파일 공유	EFS
임시 캐시·버퍼 (최고속도)	EC2 Instance Store
자주 쓰는 이미지 배포 표준화	AMI
콜드 데이터, 최저 비용	EBS sc1 or EFS Archive

📌 시험 자주 출제 포인트

포인트	내용
부트 볼륨 가능 타입	gp2, gp3, io1, io2 Block Express (HDD는 불가)
EBS AZ 이전 방법	스냅샷 생성 → 다른 AZ에서 복원
EBS 암호화 키	AWS KMS (AES-256)
미암호화 → 암호화	스냅샷 복사 시 암호화 옵션 활성화
EBS Multi-Attach	io1/io2만, 동일 AZ 내, 최대 16개 인스턴스
Instance Store 데이터 유지	재부팅(Reboot)만 유지, Stop/Terminate 시 소멸
EFS OS 지원	Linux 전용 (POSIX), Windows 미지원
EFS 처리량 모드 권장	예측 불가 워크로드 → Elastic
EFS 비용 절감	라이프사이클 정책 → 최대 90% 절감

📚 참고 자료

🖥️ AWS EC2 (Elastic Compute Cloud)

Mon, 16 Mar 2026 00:00:00 GMT

🖥️ AWS EC2 (Elastic Compute Cloud)

EC2 = Infrastructure as a Service (IaaS)

가상 서버를 온디맨드로 임대하여 컴퓨팅 리소스를 유연하게 사용하는 서비스

EC2 개요
EC2 인스턴스 타입
Security Groups (보안 그룹)
SSH 접속 방법
구매 옵션 (Purchasing Options)
Spot Instance 심화
IP 주소 & Elastic IP
배치 그룹 (Placement Groups)
탄력적 네트워크 인터페이스 (ENI)
EC2 최대 절전 모드 (Hibernate)
Best Practices
핵심 요약
참고 자료

1. EC2 개요

☁️ EC2가 제공하는 것

기능	서비스	설명
가상 서버 임대	EC2	다양한 OS/스펙의 가상 머신
가상 드라이브	EBS	네트워크 연결 블록 스토리지
로드 분산	ELB	여러 인스턴스에 트래픽 분산
자동 확장	ASG	수요에 따른 인스턴스 수 조절

⚙️ EC2 설정 옵션

EC2 인스턴스 구성 요소
├── OS: Linux / Windows / macOS
├── CPU: vCPU 수, 프로세서 아키텍처 (x86, ARM/Graviton)
├── RAM: 메모리 크기
├── Storage
│   ├── Network-attached: EBS (Elastic Block Store), EFS (Elastic File System)
│   └── Hardware: EC2 Instance Store (임시, 고속)
├── Network: 네트워크 카드 속도, 공인 IP 설정
├── Security Group: 방화벽 규칙
└── User Data: 최초 실행 시 부트스트랩 스크립트

🚀 EC2 User Data (부트스트랩)

인스턴스 최초 시작 시 딱 한 번만 실행
root 권한으로 실행됨
자동화할 수 있는 작업 예시:

#!/bin/bash
# EC2 User Data 예시
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from EC2 $(hostname -f)</h1>" > /var/www/html/index.html

💡 활용 팁: 소프트웨어 설치, 설정 파일 다운로드, 환경변수 설정 등 초기화 작업을 자동화할 때 사용. 복잡한 설정이 필요하면 CloudFormation 또는 Ansible 연계 권장.

2. EC2 인스턴스 타입

🏷️ 명명 규칙

m  7  g  .  2xlarge
│  │  │       └── 크기 (nano / micro / small / medium / large / xlarge / 2xlarge ...)
│  │  └────────── 추가 속성 (g=Graviton, a=AMD, i=Intel, n=고속 네트워크)
│  └───────────── 세대 (숫자가 높을수록 최신)
└──────────────── 인스턴스 패밀리 (m=범용, c=컴퓨팅, r=메모리, i=스토리지 등)

📊 인스턴스 패밀리별 용도

패밀리	대표 타입	특징	주요 Use Case
General Purpose	m7i, m7g, t3	CPU/메모리/네트워크 균형	웹 서버, 코드 저장소, 소규모 DB
Compute Optimized	c7i, c7g, c6a	고성능 CPU 중심	배치 처리, 미디어 트랜스코딩, HPC, ML
Memory Optimized	r7i, r7g, x2	대용량 메모리	인메모리 DB, 실시간 빅데이터, SAP HANA
Storage Optimized	i4i, d3, h1	고속 로컬 스토리지	OLTP, Redis 캐시, 데이터 웨어하우스
Accelerated Computing	p4, g5, trn1, inf2	GPU/NPU 탑재	AI/ML 학습·추론, 게임 스트리밍

⚡ Graviton (ARM 기반) 인스턴스 — 2025 핵심 트렌드

AWS Graviton 프로세서 기반 EC2 인스턴스는 x86 기반 인스턴스 대비 최대 40% 향상된 가격 대비 성능을 제공합니다.

세대	인스턴스 예시	특징
Graviton2	m6g, c6g, r6g	1세대 ARM, 검증된 안정성
Graviton3	m7g, c7g, r7g	20% 향상된 네트워크 대역폭
Graviton4	m8g (신규)	최신 세대, 최고 효율

:::warning ARM 아키텍처이므로 애플리케이션이 x86 바이너리에 의존하는 경우 멀티 아키텍처 빌드 테스트 필요. Docker 이미지도 arm64 지원 여부 확인 필수. :::

🔀 버스터블 인스턴스 (T 시리즈)

기준 CPU 성능 + 필요 시 일시적으로 버스트 가능
CPU 크레딧 방식: 평소에 크레딧 적립 → 부하 시 소진
개발/테스트, 트래픽 변동이 큰 소규모 앱에 적합

t3.micro:  기준 20% CPU, 필요 시 최대 100%까지 버스트
t3.large:  기준 30% CPU, 필요 시 최대 100%까지 버스트

:::warning 프로덕션 고부하 환경에서 크레딧 고갈 시 심각한 성능 저하 발생. `unlimited` 모드 설정 시 추가 비용 발생. :::

3. Security Groups (보안 그룹)

🔥 개념

EC2 인스턴스 앞단의 가상 방화벽
Allow 규칙만 존재 (Deny 규칙 없음 — NACL과 차이)
IP 또는 다른 Security Group을 참조해 규칙 설정 가능

인터넷
  │
  ▼
[Security Group]  ← 여기서 허용된 트래픽만 통과
  │
  ▼
[EC2 Instance]   ← 차단된 트래픽은 인스턴스가 아예 볼 수 없음

📋 Inbound / Outbound 기본값

트래픽 방향	기본값	의미
Inbound	전체 차단	명시적으로 허용하지 않으면 외부 접근 불가
Outbound	전체 허용	인스턴스에서 외부로 나가는 트래픽 제한 없음

📌 주요 포트 번호

포트	프로토콜	용도
22	SSH	Linux 인스턴스 원격 접속
22	SFTP	SSH 기반 파일 전송
21	FTP	파일 전송 (보안 취약, 비권장)
80	HTTP	웹 서버 (비암호화)
443	HTTPS	웹 서버 (암호화)
3389	RDP	Windows 인스턴스 원격 데스크톱
3306	MySQL/Aurora	DB 접속
5432	PostgreSQL	DB 접속
6379	Redis	캐시 서버 접속

✅ Security Group 활용 팁

1. Security Group 간 참조 (IP 대신)

[App Server SG]  →  Inbound: MySQL(3306) from [DB Server SG]

→ IP 변경 시에도 자동 적용, IP 관리 불필요

2. 트러블슈팅 가이드

증상	원인	해결
앱에 아예 접근 안 됨 (timeout)	Security Group 차단	Inbound 규칙 확인
접근은 되는데 `Connection refused`	앱이 안 떴거나 포트 불일치	앱 상태 확인
특정 IP만 안 됨	Inbound IP 범위 설정 오류	CIDR 확인

:::important[💡 Best Practice] SSH용 Security Group을 별도로 분리하여 관리. 0.0.0.0/0 (전체 허용)은 절대 프로덕션에 사용 금지. :::

4. SSH 접속 방법

플랫폼별 지원 현황

방법	Mac	Linux	Windows < 10	Windows ≥ 10
SSH	✅	✅	❌	✅
PuTTY	❌	❌	✅	✅
EC2 Instance Connect	✅	✅	✅	✅
AWS Systems Manager (SSM)	✅	✅	✅	✅

SSH 접속 예시

# 키 파일 권한 설정 (최초 1회)
chmod 400 my-key.pem

# 접속
ssh -i my-key.pem ec2-user@<공인IP>
# Amazon Linux: ec2-user
# Ubuntu: ubuntu
# CentOS: centos

🌟 EC2 Instance Connect vs SSM Session Manager

구분	EC2 Instance Connect	SSM Session Manager
SSH 키 필요	❌ (브라우저 기반)	❌
공인 IP 필요	✅	❌ (프라이빗 서브넷 가능)
포트 22 오픈 필요	✅	❌
감사 로그	제한적	CloudTrail + S3 완전 기록
보안 수준	보통	최고 (Best Practice)

AWS Systems Manager Session Manager

SSH 포트를 열거나 Bastion 호스트를 사용하지 않고 EC2 인스턴스, 온프레미스 서버, VM 등을 엑세스 할 수 있는 안전하고(secure), 감사가 가능하며(audited), 브라우저 기반(browser-based) 쉘
Benefits
- 보안 (Security) : SSH 포트나 RDP (3389) 포트를 열지 않아도 되어서 높은 보안 수준 유지 가능
- 접근 제어 (Access Control) : IAM 정책을 사용하여 사용자의 접근 제어 가능
- 감사 추적 가능성 (Auditability) : 모든 세션 명령어는 로깅 → CloudWatch Logs가 Amazon S3 등에서 로그 중앙 관리 지원
- SSH Key 관리 ❌ : SSH 키 관리, 저장 및 로테이션이 불필요
- 크로스 플랫폼 (Cross-Platform) : Windows와 Linux 인스턴스 둘다 지원 가능
How to setup?
- SSM Agent 설치
- IAM Role Configuration : AmazonSSMManagedInstanceCore 정책 설정을 통해서 System Manager service와 통신 가능하도록 허용
- Network Connectivity : 인스턴스는 HTTPS (443) 아웃바운드 정책 허용 :::important[💡 2025 Best Practice] 포트 22를 아예 열지 않고 SSM Session Manager로 접속하는 것이 보안상 가장 권장되는 방식입니다. :::

5. 구매 옵션 (Purchasing Options)

🏨 호텔 비유로 이해하기

구매 옵션	호텔 비유	특징
On-Demand	예약 없이 정가로 체크인	유연, 단기, 가장 비쌈
Reserved	1~3년 장기 계약 할인	최대 72% 할인, 안정적 워크로드
Savings Plans	일정 금액 선불, 어느 방이든 OK	유연한 할인 약정
Spot	빈 방 경매, 언제든 퇴실 가능	최대 90% 할인, 중단 가능
Dedicated Host	건물 전체 임대	물리 서버 단독 사용, 라이선스
Dedicated Instance	같은 건물 내 남과 공유 없음	논리적 격리
Capacity Reservation	방 예약만 해두기 (안 써도 요금)	용량 보장, 특정 AZ

💰 비용 비교 및 사용 시나리오

비용 (높음 → 낮음)
On-Demand > Dedicated Host > Reserved > Savings Plans > Spot

유연성 (높음 → 낮음)
On-Demand > Spot > Savings Plans > Reserved > Dedicated Host

On-Demand

Linux/Windows: 초 단위 과금 (최초 1분 이후)
기타 OS: 시간 단위 과금
예측 불가한 단기 워크로드, 신규 앱 테스트에 적합

Reserved Instances (RI)

최대 72% 할인 (3년 전액 선불 시 최대)
고정 조건: 인스턴스 타입, 리전, OS, 테넌시

결제 방식	할인율
No Upfront (선불 없음)	낮음
Partial Upfront (일부 선불)	중간
All Upfront (전액 선불)	최대

Convertible RI: 인스턴스 타입 변경 가능, 최대 66% 할인
Reserved Instance Marketplace에서 남은 기간 판매 가능

Savings Plans

시간당 사용 금액 약정 ($X/시간 형태)
RI보다 유연: 인스턴스 크기, OS, 테넌시 변경 가능
약정 초과분은 On-Demand 요금 적용
취소 불가 (1년 또는 3년 약정)

대부분의 팀에게는 Compute Savings Plans가 절감액과 유연성의 가장 좋은 균형을 제공합니다. AWS는 새로운 약정에 대해 Savings Plans를 권장합니다.

Spot Instances

최대 90% 할인 — AWS에서 가장 저렴
현재 Spot 가격이 설정한 최대 가격 초과 시 2분 경고 후 인스턴스 종료
중단에 견딜 수 있는 워크로드에만 적합:

✅ 적합: 배치 처리, 데이터 분석, 이미지 처리, ML 학습, CI/CD
❌ 부적합: 운영 DB, 결제 시스템, 실시간 서비스

Dedicated Hosts vs Dedicated Instances

항목	Dedicated Instance	Dedicated Host
물리 서버 전용 사용	❌ (계정 내 공유 가능)	✅
소켓/코어 수 가시성	❌	✅
인스턴스 배치 제어	❌	✅
기존 라이선스 활용 (BYOL)	❌	✅
비용	비쌈	가장 비쌈

💡 Dedicated Host 사용 시나리오: Oracle, Microsoft SQL Server 등 소켓/코어 기반 라이선스가 있는 소프트웨어를 클라우드로 이전(Lift & Shift)할 때.

6. Spot Instance 심화

🎯 Spot Instance 작동 방식

사용자가 max price 설정
        │
        ▼
현재 Spot 가격 < max price → 인스턴스 실행 유지
        │
현재 Spot 가격 > max price → 2분 경고
        │
        ├── Stop: Spot 가격이 낮아지면 자동 재시작 (Persistent)
        └── Terminate: 완전 종료 (One-time)

📋 Spot Request 유형

유형	설명	종료 후
One-time	한 번만 요청, 종료 시 끝	재시작 없음
Persistent	가격 조건 충족 시 자동 재시작	자동 재실행

올바른 종료 순서:

1️⃣ Spot Request 취소 (Cancel) — 먼저!
2️⃣ 연결된 인스턴스 종료 (Terminate)

⚠️ 인스턴스만 종료하면 Persistent 요청이 새 인스턴스를 다시 시작시킴

🚢 Spot Fleet — 더 스마트한 Spot 활용

Spot Fleet = Spot 인스턴스 집합 + (선택) On-Demand 인스턴스

Spot Fleet
├── Launch Pool A: c5.xlarge, Linux, us-east-1a
├── Launch Pool B: c5.2xlarge, Linux, us-east-1b
└── Launch Pool C: c5a.xlarge, Linux, us-east-1c

→ 목표 용량에 맞춰 가장 유리한 풀에서 자동으로 인스턴스 요청

Spot Fleet 할당 전략:

전략	설명	적합한 상황
`lowestPrice`	가장 저렴한 풀 우선	비용 최우선 단기 작업
`diversified`	여러 풀에 분산	가용성 중시, 장기 실행
`capacityOptimized`	용량 여유 있는 풀 우선	중단 최소화
`priceCapacityOptimized` ⭐	용량 여유 풀 중 최저가	대부분의 워크로드에 권장

7. IP 주소 & Elastic IP

🌐 공인 IP (Public IP) vs 사설 IP (Private IP)

구분	공인 IP (Public IP)	사설 IP (Private IP)
식별 범위	인터넷 전체	해당 사설 네트워크 내부만
유일성	전 세계에서 유일	같은 네트워크 내에서만 유일
중복	불가	서로 다른 회사 간에는 중복 가능
외부 접근	직접 가능	NAT + 인터넷 게이트웨이 경유 필요
위치 추적	가능 (Geo-location)	불가

[사설 네트워크 A]          [사설 네트워크 B]
  192.168.1.10               192.168.1.10   ← 사설 IP 중복 가능
       │                          │
   [NAT/IGW]                  [NAT/IGW]
       │                          │
       └──────── 인터넷 ──────────┘
           (공인 IP는 유일)

:::tip EC2 인스턴스는 기본적으로 사설 IP는 고정이지만, 공인 IP는 인스턴스를 중지(Stop) 후 재시작(Start)하면 변경됩니다. :::

🔒 IPv4 vs IPv6

항목	IPv4	IPv6
예시	`1.160.10.240`	`3ffe:1900:4545:3:200:f8ff:fe21:67cf`
주소 수	약 37억 개 (고갈 중)	사실상 무제한
현재 상태	인터넷의 주류 방식	IoT 등 신규 기기 확산으로 증가 중

📌 Elastic IP (탄력적 IP)

EC2 인스턴스를 중지(Stop) 후 시작(Start)하면 공인 IP가 바뀌는 문제를 해결하는 고정 공인 IPv4 주소
삭제하지 않는 한 계속 소유 가능
한 번에 하나의 인스턴스에만 연결 가능
인스턴스 또는 네트워크 인터페이스 장애 시, 다른 인스턴스로 빠르게 재매핑(Remap)하여 장애를 마스킹(Masking)하는 용도로 활용 가능
계정당 기본 5개 제한 (AWS에 증가 요청 가능)
연결되지 않은 Elastic IP에는 요금 부과 (낭비 방지용)

⚠️ Elastic IP 사용을 피해야 하는 이유

Elastic IP를 사용하는 아키텍처는 종종 설계가 잘못된 신호입니다 (often reflect poor architectural decisions).

대신 권장하는 방법:

상황	권장 방법
고정 주소가 필요한 경우	DNS 이름(Route 53)을 공인 IP에 연결
외부 트래픽 처리	로드 밸런서(ELB) 사용 → 인스턴스에 공인 IP 불필요
장애 복구	Auto Scaling + ELB 조합으로 IP 의존성 제거

8. 배치 그룹 (Placement Groups)

EC2 인스턴스가 AWS 인프라 내에 어떻게 배치될지를 제어하는 기능
세 가지 전략 중 하나를 선택하여 그룹 생성

📊 배치 전략 비교

전략	핵심 목표	제약	주요 Use Case
Cluster	초저지연, 고대역폭	단일 AZ, 단일 랙	HPC, 빅데이터, 초고속 통신
Spread	최대 가용성, 물리적 격리	AZ당 최대 7 인스턴스	미션 크리티컬, 고가용성 앱
Partition	대규모 분산, 파티션 단위 격리	AZ당 최대 7 파티션, 수백 인스턴스	분산 데이터 시스템 (Hadoop, Kafka)

🚀 Cluster Placement Group (클러스터 배치 그룹)

┌─────────── Availability Zone ───────────┐
│  ┌─────────── 단일 랙 ─────────────┐   │
│  │  [EC2] [EC2] [EC2] [EC2] [EC2]  │   │
│  └─────────────────────────────────┘   │
└─────────────────────────────────────────┘

장점: Enhanced Networking (향상된 네트워킹) 활성화 시 인스턴스 간 10Gbps 대역폭
단점: AZ 전체 장애 시 모든 인스턴스가 동시에 중단됨
Use Case: 빠르게 완료해야 하는 빅데이터 작업 (Big Data job), 초저지연·고처리량이 필요한 애플리케이션

🛡️ Spread Placement Group (분산 배치 그룹)

┌── AZ 1 ──┐   ┌── AZ 2 ──┐   ┌── AZ 3 ──┐
│ [랙1]    │   │ [랙2]    │   │ [랙3]    │
│  [EC2]   │   │  [EC2]   │   │  [EC2]   │
└──────────┘   └──────────┘   └──────────┘

장점: 각 인스턴스가 서로 다른 물리 하드웨어(랙)에 배치 → 동시 장애 위험 최소화, 여러 AZ에 걸쳐 배치 가능
단점: AZ당 최대 7개 인스턴스 제한 (소규모 배포에만 적합)
Use Case: 각 인스턴스가 서로 독립적으로 장애 격리(Isolated from failure)되어야 하는 고가용성 미션 크리티컬 애플리케이션

🗂️ Partition Placement Group (파티션 배치 그룹)

┌──────────────── AZ 1 ──────────────────┐
│  ┌─파티션1─┐  ┌─파티션2─┐  ┌─파티션3─┐ │
│  │ [EC2]  │  │ [EC2]  │  │ [EC2]  │ │
│  │ [EC2]  │  │ [EC2]  │  │ [EC2]  │ │
│  │ [EC2]  │  │ [EC2]  │  │ [EC2]  │ │
│  └────────┘  └────────┘  └────────┘ │
│   (서로 다른 랙, 파티션 간 랙 공유 없음)     │
└────────────────────────────────────────┘

AZ당 최대 7개 파티션, 동일 리전 내 여러 AZ에 걸쳐 배치 가능
그룹당 수백 개의 EC2 인스턴스 지원
파티션 간 랙을 절대 공유하지 않음 → 한 파티션 장애가 다른 파티션에 영향 없음
인스턴스 메타데이터(Instance Metadata)로 자신이 속한 파티션 정보 접근 가능 → 애플리케이션이 토폴로지 인식(Topology-aware) 배포 가능
Use Case: HDFS, HBase, Cassandra, Kafka 등 대규모 분산 데이터 시스템

9. 탄력적 네트워크 인터페이스 (ENI)

🔌 ENI란?

ENI (Elastic Network Interface, 탄력적 네트워크 인터페이스): VPC (Virtual Private Cloud, 가상 사설 클라우드) 내에서 가상 네트워크 카드를 나타내는 논리적 컴포넌트
EBS 볼륨을 필요에 따라 EC2에 붙이듯, 네트워킹 계층도 인스턴스와 독립적으로 분리하여 별도로 관리 가능
특정 AZ (Availability Zone, 가용 영역)에 종속됨 — AZ 간 이동 불가

💡 AWS 공식 블로그 핵심 인사이트: ENI 도입 이전에는 EC2 인스턴스가 특정 서브넷(Subnet)에 속하는 개념이었으나, ENI 도입 이후 서브넷 귀속 단위는 인스턴스가 아닌 ENI 로 바뀌었습니다. 따라서 하나의 인스턴스에 서로 다른 서브넷의 ENI 두 개를 붙여 듀얼 홈(Dual-homed) 환경을 구성할 수 있습니다.

📋 ENI 속성 (Attributes)

속성	설명
기본 사설 IPv4 (Primary Private IPv4)	반드시 1개, 서브넷 대역 내 할당
보조 사설 IPv4 (Secondary Private IPv4)	1개 이상 추가 가능
탄력적 IP (Elastic IP)	사설 IPv4당 최대 1개 연결 가능
공인 IPv4 (Public IPv4)	1개
보안 그룹 (Security Groups)	1개 이상 연결 가능
MAC 주소 (MAC Address)	고유 식별자, BYOL 라이선스에 활용
소스/목적지 확인 플래그 (Source/Destination Check Flag)	NAT·프록시 서버 구성 시 비활성화 필요
종료 시 삭제 플래그 (Delete on Termination Flag)	기본 ENI는 인스턴스 종료 시 자동 삭제

🔄 ENI의 독립적 생명주기 (Independent Lifetime)

EBS 볼륨처럼 ENI도 특정 EC2 인스턴스와 독립적인 생명주기를 가집니다.

ENI 생성 (미리 만들어 놓기 가능)
    │
    ├── 인스턴스 시작 시 연결 (Launch-time attach)
    ├── 실행 중인 인스턴스에 즉시 연결 (Hot attach, 핫 어태치)
    └── 인스턴스 종료 후에도 ENI는 유지 (Delete on Termination = false 시)

🏗️ ENI 주요 활용 패턴

1. 관리 네트워크 분리 (Management Network / Backnet)

EC2 인스턴스
├── ENI 1 (공용 서브넷) ─→ 인터넷 게이트웨이 → 외부 트래픽 처리 (포트 80/443)
└── ENI 2 (사설 서브넷) ─→ VPN 게이트웨이 → SSH 접속·로그·관리 트래픽 (포트 22)

각 ENI에 다른 보안 그룹을 적용해 트래픽을 세밀하게 제어 가능.

2. 멀티 인터페이스 애플리케이션 (Multi-Interface Applications)

로드 밸런서(Load Balancer), 프록시 서버(Proxy Server), NAT 서버 구성 시 두 서브넷 사이에서 트래픽을 전달. 이 경우 소스/목적지 확인(Source/Destination Check)을 비활성화해야 함.

3. MAC 주소 기반 라이선스 (MAC-Based Licensing)

특정 MAC 주소에 묶인 상용 소프트웨어 라이선스를 사용할 때, 인스턴스가 교체·타입 변경이 필요한 경우에도 동일한 ENI(MAC 주소 유지)를 새 인스턴스에 재연결하여 라이선스 재발급 없이 계속 사용 가능.

4. 저비용 고가용성 (Low-Budget High Availability)

1️⃣ ENI를 인스턴스 A에 연결
2️⃣ 인스턴스 A 장애 발생
3️⃣ 새 인스턴스 B 시작
4️⃣ ENI를 인스턴스 B에 재연결 → 수 초 내 트래픽 복구

IP 주소와 보안 그룹 설정이 ENI에 종속되어 있으므로, 인스턴스가 바뀌어도 네트워크 구성이 그대로 유지됨.

🔁 장애 복구 시나리오 (Failover)

[ENI: 10.0.1.50]──→ [인스턴스 A: 정상]
                             │ 장애!
                             ▼
[ENI: 10.0.1.50]──→ [인스턴스 B: 교체됨]
  (동일 IP 유지)      (수 초 내 트래픽 전환)

:::tip ENI는 특정 AZ에 종속(Bound to a specific AZ)됩니다. AZ 간 이동은 불가하므로, 멀티 AZ 고가용성이 필요한 경우 ELB(Elastic Load Balancer)를 사용해야 합니다. :::

10. EC2 최대 절전 모드 (Hibernate)

💤 인스턴스 상태 전환 비교

상태	EBS 데이터	RAM 상태	다음 시작 시
Stop (중지)	✅ 유지	❌ 소멸	OS 부팅 + 앱 초기화 필요
Terminate (종료)	❌ 소멸 (루트 볼륨 기본 삭제)	❌ 소멸	새 인스턴스 시작 필요
Hibernate (최대 절전)	✅ 유지	✅ EBS에 저장 후 복원	훨씬 빠른 재시작

🔧 Hibernate 작동 원리

Hibernate 실행
    │
    ▼
RAM 전체 내용을 루트 EBS 볼륨 파일에 덤프(Dump)
    │
    ▼
인스턴스 중지 (OS가 완전히 종료되지 않음)
    │
    ▼
재시작 시 → EBS에서 RAM 상태 복원 → 중단 지점부터 즉시 재개

:::important OS 재부팅(OS booting)이 없으므로 시작 시간이 매우 빠름. 애플리케이션이 캐시 워밍(Cache Warming)을 다시 할 필요 없음. :::

✅ 지원 조건 (Requirements)

항목	조건
인스턴스 패밀리 (Instance Family)	C3, C4, C5, I3, M3, M4, R3, R4, T2, T3 등
RAM 크기 (RAM Size)	150 GB 미만
인스턴스 크기 (Instance Size)	베어 메탈(Bare Metal) 인스턴스 미지원
AMI	Amazon Linux 2, Linux AMI, Ubuntu, Windows 등
루트 볼륨 (Root Volume)	반드시 EBS, 암호화(Encrypted) 필수, Instance Store 불가, RAM을 담을 충분한 용량 필요
구매 옵션	On-Demand, Reserved, Spot 인스턴스 모두 지원
최대 절전 유지 기간	60일을 초과할 수 없음 (cannot be hibernated more than 60 days)

💡 Hibernate 주요 Use Case

Use Case	설명
장시간 실행 프로세스 (Long-running processing)	재시작 없이 작업 상태 그대로 유지
RAM 상태 보존 (Saving the RAM state)	인메모리 데이터·캐시 유지
초기화가 오래 걸리는 서비스 (Services that take time to initialize)	부팅·캐시 워밍 비용 없이 즉시 재개

:::warning ⚠️ 루트 볼륨 암호화가 필수인 이유: RAM 내용(민감한 데이터 포함 가능)이 EBS 디스크에 평문으로 쓰이는 것을 방지하기 위함. :::

11. Best Practices

💡 인스턴스 선택

1. 워크로드 특성 먼저 파악

CPU 집약적  → Compute Optimized (c 계열)
메모리 집약적 → Memory Optimized (r, x 계열)
스토리지 I/O  → Storage Optimized (i, d 계열)
균형 잡힌 일반 → General Purpose (m, t 계열)
AI/ML 학습   → GPU (p, g 계열) 또는 Trn1
AI/ML 추론   → Inf2 (가장 저렴한 추론 전용)

2. Graviton(ARM) 우선 검토

Graviton(arm64)은 x86 대비 최대 40% 향상된 가격 대비 성능을 제공합니다. 멀티 아키텍처 빌드를 테스트하고 롤아웃 전에 p95/p99 성능을 측정하세요.

💰 비용 최적화 전략

1. Right-Sizing (적정 규모 조정)

2~4주 동안 활용도 데이터를 수집하고, AWS Compute Optimizer 또는 Cost Explorer를 통해 과소 활용 인스턴스를 파악한 뒤 적절한 크기로 조정하세요.

# AWS Compute Optimizer로 우선 분석
# → CloudWatch 지표 기반 권장 인스턴스 타입 제안

2. 구매 옵션 혼합 (Blended Pricing)

안정적 기본 부하  → Reserved Instances 또는 Savings Plans (72% 절감)
변동적 추가 부하  → Spot Instances (최대 90% 절감)
예측 불가 피크   → On-Demand (백업)

기준 부하에는 Savings Plans/Reserved Instance로 커버하고, 기준 초과의 변동 부하에는 Spot Instance를 사용하세요. Spot 용량 부족 시에는 중요 워크로드를 위해 On-Demand로 자동 폴백하도록 구성하세요.

3. 스케줄링으로 유휴 비용 절감

개발/테스트 환경: 업무 시간(09:00-19:00)에만 실행
→ 태그 기반 자동 시작/종료 → 최대 65% 비용 절감

권장 태그 체계:
  Environment = dev | staging | prod
  Schedule    = OfficeHours | AlwaysOn
  Owner       = team-name
  CostCenter  = CC-1234

4. EBS 볼륨 비용 최적화

CloudWatch 또는 Compute Optimizer를 통해 일관되게 낮은 IOPS 또는 처리량을 보이는 볼륨을 식별하고, 더 저렴한 gp3 또는 st1 볼륨 타입으로 다운그레이드를 검토하세요.

볼륨 타입	특징	적합한 용도
`gp3`	비용 효율 높음 ⭐	대부분의 워크로드
`gp2`	구형, gp3보다 비쌈	마이그레이션 고려
`io2`	고IOPS, 고비용	미션 크리티컬 DB
`st1`	저비용, 순차 읽기	로그, 빅데이터
`sc1`	가장 저렴	콜드 데이터

:::tip gp2 → gp3 전환 시 동일 성능에 약 20% 비용 절감 가능. :::

🔐 EC2 보안 Best Practice

1. 인스턴스 접근

포트 22(SSH)를 0.0.0.0/0으로 여는 것 절대 금지
가능하면 SSM Session Manager 사용 (포트 22 불필요)
불가피한 경우 회사 IP 또는 VPN IP만 허용

2. IAM Role 사용

# ❌ 절대 금지: Access Key를 EC2에 직접 저장
export AWS_ACCESS_KEY_ID="AKIA..."
export AWS_SECRET_ACCESS_KEY="..."

# ✅ 권장: EC2 IAM Role 사용 (자동으로 임시 자격증명 관리)
# 인스턴스에 Role만 붙이면 코드에서 자격증명 불필요
import boto3
s3 = boto3.client('s3')  # Role이 자동으로 처리

3. Auto Scaling 활용

Auto Scaling Group
├── Minimum: 2 (최소 가용성 보장)
├── Desired: 4 (평소 운영 수량)
└── Maximum: 10 (트래픽 급증 대비)

→ CloudWatch 지표(CPU 70% 초과 시) 기반 자동 Scale Out
→ CloudWatch 지표(CPU 30% 미만 시) 기반 자동 Scale In

🚨 자주 하는 실수 (Anti-Patterns)

실수	문제	해결책
인스턴스 타입 고려 없이 m5.xlarge 고정	비용 낭비 또는 성능 부족	Compute Optimizer로 분석 후 선택
모든 워크로드에 On-Demand	불필요한 비용	RI + Savings Plans + Spot 혼합
Security Group에서 0.0.0.0/0:22 허용	무차별 대입 공격 노출	SSM 또는 특정 IP만 허용
개발 환경 24시간 가동	불필요한 비용	스케줄 기반 자동 중지
Access Key를 EC2 내 파일로 저장	키 탈취 위험	IAM Role로 대체
인스턴스 스토어에 중요 데이터 저장	종료 시 데이터 소멸	EBS 또는 S3에 저장
구버전 인스턴스 타입 방치	가격 대비 성능 낮음	신세대로 마이그레이션

12. 핵심 요약

EC2 구성 핵심
├── 인스턴스 타입: 워크로드에 맞게 선택 (m=범용, c=컴퓨팅, r=메모리, i=스토리지)
├── User Data: 최초 1회 부트스트랩 (root 권한)
├── Security Group: 상태 기반 가상 방화벽 (Allow만, 기본 Inbound 차단)
└── 접속: SSH / EC2 Instance Connect / SSM Session Manager

IP 주소
├── Public IP: 인터넷에서 식별, 인스턴스 재시작 시 변경됨
├── Private IP: 내부 네트워크 전용, 재시작해도 고정
└── Elastic IP: 고정 공인 IP, 5개 제한, 미연결 시 과금

배치 그룹 (Placement Groups)
├── Cluster:   단일 AZ, 단일 랙 → 초저지연·고대역폭 (10Gbps), 동시 장애 위험
├── Spread:    서로 다른 랙 → 최대 가용성, AZ당 7개 제한
└── Partition: 파티션 단위 격리 → 분산 시스템 (Hadoop, Kafka, Cassandra)

ENI (Elastic Network Interface)
├── VPC 내 가상 네트워크 카드 (논리적 컴포넌트)
├── 특정 AZ에 종속, AZ 간 이동 불가
├── 인스턴스와 독립적 생명주기 (Hot attach 가능)
└── 활용: 관리망 분리, MAC 라이선스, 저비용 고가용성 Failover

Hibernate (최대 절전 모드)
├── RAM 상태를 암호화된 EBS에 저장 → 빠른 재시작
├── 루트 EBS 암호화(Encrypted) 필수
├── RAM 150GB 미만, 최대 60일 제한
└── 구매 옵션: On-Demand / Reserved / Spot 모두 지원

구매 옵션 선택 가이드
├── 단기·불규칙  → On-Demand
├── 안정적 장기  → Reserved Instances 또는 Savings Plans (72% 절감)
├── 중단 허용   → Spot Instances (90% 절감)
├── 라이선스 제약 → Dedicated Host
└── 용량 보장   → Capacity Reservation

비용 최적화 3단계
1️⃣ Right-Sizing: Compute Optimizer로 적정 규모 분석
2️⃣ 구매 혼합: 기본 부하 → RI/SP, 변동 부하 → Spot
3️⃣ 스케줄링: 개발 환경 업무시간만 가동

📚 참고 자료

🔐 AWS IAM (Identity and Access Management)

Sat, 14 Mar 2026 00:00:00 GMT

🔐 AWS IAM (Identity and Access Management)

IAM은 AWS 리소스에 대한 접근을 안전하게 제어하는 **Global Service (글로벌 서비스)**입니다.

"누가(Who) → 무엇을(What) → 어떤 조건에서(Condition) 할 수 있는가"를 정의합니다.

1. IAM 기본 개념

🌍 AWS Region vs IAM

구분	특징
AWS Region	특정 지역에 종속 (Compliance, 지연속도, 가용 서비스, 가격 고려)
IAM	글로벌 서비스 — 리전에 종속되지 않음

Region 선택 기준

Compliance: 데이터 주권 (Data governance) / 법적 요구사항 (Legal requirements)

Proximity: 고객과의 물리적 거리 (지연속도 - Reduced Latency)

Available Services: 신규 서비스는 일부 리전에서만 먼저 제공

Pricing: 리전마다 가격 상이

👤 Root Account

AWS 계정 생성 시 자동으로 만들어지는 최고 권한 계정
일상적인 작업에 절대 사용 금지 — 초기 설정 및 루트만 가능한 작업에만 사용
루트 계정으로만 가능한 작업 예시: 결제 정보 변경, 계정 삭제, Support Plan 변경

👥 Users & Groups

AWS Account
├── Root User (최상위, 공유 금지)
├── Group: Developers
│   ├── User: Alice
│   └── User: Bob
├── Group: Admins
│   └── User: Charlie
└── User: Dave (그룹 미소속도 가능)

User: 조직 내 개별 사람 또는 애플리케이션
Group: User들의 집합 (그룹 안에 그룹 중첩 불가)
하나의 User는 여러 Group에 동시에 소속 가능
User는 반드시 Group에 속할 필요 없음 (단, 권장하지 않음)

2. IAM 정책 (Policies)

📋 정책의 종류

정책 유형	설명	사용 시기
AWS Managed Policy	AWS가 관리하는 사전 정의 정책	빠른 시작, 일반적인 Use Case
Customer Managed Policy	직접 생성/관리하는 정책	세밀한 권한 제어 필요 시
Inline Policy	특정 User/Group/Role에 직접 첨부	1:1 대응, 재사용 불필요 시

🔗 정책 상속 구조

Group: Developers  ──── Policy A (S3 Full Access)
    └── User: Alice  ── Policy B (EC2 Read, Inline)

Group: QA  ──────────── Policy C (CloudWatch Read)
    └── User: Alice (중복 소속)

→ Alice가 최종적으로 갖는 권한: Policy A + Policy B + Policy C

📄 IAM 정책 JSON 구조

{
    "Version": "2012-10-17",
    "Id": "S3-Account-Permissions",
    "Statement": [
        {
            "Sid": "AllowS3Access",
            "Effect": "Allow",
            "Principal": {
                "AWS": ["arn:aws:iam::123456789012:root"]
            },
            "Action": [
                "s3:GetObject",
                "s3:PutObject"
            ],
            "Resource": ["arn:aws:s3:::mybucket/*"],
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "ap-northeast-2"
                }
            }
        }
    ]
}

각 필드 설명:

필드	필수	설명
`Version`	권장	정책 언어 버전 (항상 `"2012-10-17"` 사용)
`Id`	선택	정책 식별자
`Statement`	필수	권한 규칙 배열
`Sid`	선택	Statement 식별자
`Effect`	필수	`Allow` 또는 `Deny`
`Principal`	조건부	정책이 적용될 대상 (Resource-based policy에서 사용)
`Action`	필수	허용/거부할 API 작업 목록
`Resource`	필수	작업이 적용될 AWS 리소스 ARN
`Condition`	선택	정책이 적용되는 조건

💡 최소 권한 원칙 (Least Privilege Principle)

사용자에게 필요한 최소한의 권한만 부여합니다.

불필요한 권한은 공격 표면(Attack Surface)을 넓힙니다.

🏷️ 정책 예시: EC2 + CloudWatch 읽기 권한

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:Describe*",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "cloudwatch:ListMetrics",
                "cloudwatch:GetMetricStatistics",
                "cloudwatch:Describe*"
            ],
            "Resource": "*"
        }
    ]
}

3. IAM MFA & 비밀번호 정책

🔑 비밀번호 정책 설정 항목

최소 길이 지정
특정 문자 유형 필수 포함 (대문자, 숫자, 특수문자 등)
IAM 사용자의 자체 비밀번호 변경 허용 여부
비밀번호 만료 기간 설정 (정기적 변경 강제)
이전 비밀번호 재사용 방지

📱 MFA (Multi-Factor Authentication)

MFA = 알고 있는 것 (비밀번호) + 소유한 것 (기기)

비밀번호가 탈취되더라도, 물리적 기기 없이는 계정 접근 불가.

MFA 기기 옵션:

유형	제품	특징
Virtual MFA	Google Authenticator, Authy	단일 기기에 다수 계정 등록 가능
U2F Security Key	YubiKey (Yubico)	물리적 USB 키, 다수 계정 지원
Hardware Key Fob	Gemalto 제품	전용 하드웨어 OTP
GovCloud용 Key Fob	SurePassID 제품	AWS GovCloud(US) 전용

💡 실무 권장: Root 계정과 관리자 계정에는 반드시 MFA 활성화.

콘솔 접근 권한이 있는 모든 IAM 사용자에게도 MFA 강제 적용 권장.

4. AWS 접근 방법

세 가지 접근 방식

방법	보호 수단	주요 용도
Management Console	비밀번호 + MFA	사람이 직접 사용
CLI (Command Line Interface)	Access Key	스크립트, 자동화
SDK (Software Development Kit)	Access Key	애플리케이션 코드 내

🔑 Access Key 관리

AWS 콘솔에서 사용자가 직접 생성
비밀번호처럼 취급 — 절대 공유 금지, 코드에 하드코딩 금지
Access Key ID = 사용자 이름 / Secret Access Key = 비밀번호 (비유)

# Access Key 설정 예시 (CLI)
aws configure
# AWS Access Key ID: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# Default region name: ap-northeast-2
# Default output format: json

:::warning Access Key는 장기 자격증명(Long-term Credentials)입니다. 가능하면 <strong>임시 자격증명(IAM Role + STS)</strong>을 사용하고, 불가피한 경우 90일 주기로 교체(Rotation)하세요. :::

🖥️ AWS CLI

AWS 서비스의 Public API에 직접 접근
반복 작업 자동화 및 스크립트화 가능
AWS SDK(Python용 Boto3) 기반으로 빌드됨

# 주요 CLI 예시
aws iam list-users                         # 사용자 목록
aws iam create-user --user-name newuser    # 사용자 생성
aws iam attach-user-policy \               # 사용자에 정책 연결
  --user-name newuser \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

📦 AWS SDK

언어별 라이브러리 제공 (Python Boto3, Java, Node.js, Go 등)
애플리케이션 내에 임베드되어 AWS 서비스 호출
Mobile SDK (iOS, Android), IoT Device SDK도 지원

# Python Boto3 예시
import boto3

iam = boto3.client('iam')
response = iam.list_users()
for user in response['Users']:
    print(user['UserName'])

5. IAM 역할 (Roles)

🎭 역할이란?

IAM Role은 사람이 아닌 AWS 서비스가 다른 서비스에 접근할 때 사용하는 임시 자격증명입니다.

EC2 Instance
    └── IAM Role (S3 Read Access 부여)
            └── S3 Bucket 접근 가능

Access Key를 EC2에 직접 저장하는 것보다 훨씬 안전합니다.

주요 Role 유형

Role 유형	설명	예시
EC2 Instance Role	EC2가 AWS 서비스 접근 시	EC2 → S3 파일 읽기
Lambda Function Role	Lambda 실행 시 필요한 권한	Lambda → DynamoDB 쓰기
CloudFormation Role	인프라 배포 권한	Stack 생성 시 리소스 접근
Cross-Account Role	다른 계정의 리소스 접근	멀티 계정 환경

💡 Role vs User 비교

구분	IAM User	IAM Role
자격증명	장기 (비밀번호/Access Key)	임시 (STS 토큰, 기본 1시간)
대상	사람	서비스, 앱, 다른 계정
보안 수준	낮음 (키 유출 위험)	높음 (자동 만료)
권장 여부	사람만, 최소화	워크로드에는 반드시 사용

🔐 Permissions Boundary (권한 경계)

Role이나 User가 가질 수 있는 최대 권한의 상한선 설정
예: DevOps 엔지니어에게 Role 생성 권한은 주되, dev 환경으로만 제한

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:RequestedRegion": "ap-northeast-2"
                }
            }
        }
    ]
}

6. IAM 보안 도구

🔍 IAM Credentials Report (계정 수준)

위치: IAM 콘솔 → Credential Report
계정 내 모든 사용자의 자격증명 상태를 CSV로 다운로드
확인 항목: 마지막 로그인, MFA 활성화 여부, Access Key 사용 일자, 비밀번호 교체 일자

# CLI로 생성 및 다운로드
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d

🔍 IAM Access Advisor (사용자 수준)

위치: IAM 콘솔 → 특정 User 선택 → Access Advisor 탭
사용자에게 부여된 서비스 권한과 마지막 접근 시간 확인
오랫동안 사용하지 않은 권한 → 제거 검토

🔍 IAM Access Analyzer

외부 공개 또는 교차 계정 접근을 허용하는 리소스 자동 탐지
정책 검증 기능: 100개 이상의 체크 항목으로 정책 오류 탐지
신기능 (2025): 미사용 접근(Unused Access) 분석 → 최소 권한 달성 지원

7. Best Practices

✅ 기본 보안 원칙

항목	내용
Root 계정 보호	MFA 설정 후 사용 최소화, 자격증명 잠금 보관
1인 1계정	자격증명 절대 공유 금지
그룹으로 권한 관리	개별 User에 직접 정책 첨부 지양
최소 권한 원칙	필요한 작업에 딱 맞는 권한만 부여
MFA 강제 적용	콘솔 접근 모든 계정, 특히 관리자/루트
Access Key 최소화	장기 키 대신 Role + 임시 자격증명 사용
정기 감사	Credentials Report + Access Advisor 주기적 검토

🏗️ 실무 아키텍처 Best Practice

1. 사람 사용자 → Federation (SSO) 권장

AWS IAM 공식 문서는 사람 사용자에게 직접 IAM User를 생성하는 대신,

AWS IAM Identity Center (구 AWS SSO) 또는 외부 IdP(Okta, Azure AD, Google Workspace)를 통한 Federation을 권장합니다.

개발자 (Okta 로그인)
    └── IAM Identity Center
            └── IAM Role Assume → 임시 자격증명 발급
                    └── AWS 리소스 접근

장점:

퇴사자 계정 한 곳에서 일괄 비활성화
장기 Access Key 없음 (자동 만료 토큰)
CloudTrail에서 개인 추적 가능

2. 워크로드 → 반드시 IAM Role 사용

# ❌ 나쁜 예: Access Key를 코드에 하드코딩
import boto3
client = boto3.client(
    's3',
    aws_access_key_id='AKIAIOSFODNN7EXAMPLE',      # 절대 금지!
    aws_secret_access_key='wJalrXUtnFEMI...'        # 절대 금지!
)

# ✅ 좋은 예: EC2 Instance Role 사용 (자동으로 인증)
import boto3
client = boto3.client('s3')  # Role에서 자동으로 자격증명 가져옴

3. Access Key 사용 불가피한 경우

90일 이내 주기적 교체 (Rotation)
환경변수 또는 ~/.aws/credentials 파일로 관리
코드/레포지토리에 절대 커밋 금지
불필요한 Key는 즉시 비활성화 및 삭제

# Access Key 교체 절차
# 1. 새 Key 생성
aws iam create-access-key --user-name myuser

# 2. 애플리케이션에 새 Key 적용 및 테스트

# 3. 기존 Key 비활성화
aws iam update-access-key --access-key-id OLD_KEY_ID --status Inactive

# 4. 문제 없으면 삭제
aws iam delete-access-key --access-key-id OLD_KEY_ID

4. 정책 작성 팁

// ✅ 좋은 예: 특정 리소스 + 조건 지정
{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::my-bucket/uploads/*",
    "Condition": {
        "StringEquals": {"aws:RequestedRegion": "ap-northeast-2"},
        "Bool": {"aws:MultiFactorAuthPresent": "true"}
    }
}

// ❌ 나쁜 예: 과도하게 넓은 권한
{
    "Effect": "Allow",
    "Action": "*",
    "Resource": "*"
}

5. 멀티 계정 환경 (AWS Organizations)

서비스별/팀별/환경별(Dev/Staging/Prod) 계정 분리
SCP (Service Control Policy): 조직 전체 권한 상한선 설정
계정 간 접근은 Cross-Account Role로만 허용

AWS Organization
├── Root OU
│   ├── Management Account (빌링만)
│   ├── Security OU
│   │   └── Security Account (로그, 감사)
│   ├── Dev OU
│   │   └── Dev Account
│   └── Prod OU
│       └── Prod Account (SCP로 위험 작업 차단)

🚨 자주 하는 실수 (Anti-Patterns)

실수	문제점	해결책
Root 계정으로 일상 작업	전체 계정 탈취 위험	별도 Admin IAM User 사용
`Action: "*"` 남발	과도한 권한 부여	필요한 Action만 명시
Access Key 코드 내 하드코딩	키 유출 시 즉각 위협	IAM Role / 환경변수 사용
오래된 Access Key 방치	미사용 키 유출 위험	주기적 감사 및 삭제
개인별 정책 관리	일관성 없는 권한 관리	Group 또는 Role 기반으로 통합
MFA 미설정	비밀번호만으로 접근 가능	모든 콘솔 접근 계정에 MFA 적용

8. 핵심 요약

IAM 구성 요소
├── Users       → 사람 또는 앱, 콘솔 비밀번호 또는 Access Key
├── Groups      → User들의 집합, 그룹 중첩 불가
├── Policies    → JSON 형식의 권한 문서
├── Roles       → 서비스/앱을 위한 임시 자격증명
└── Root User   → 최고 권한, 일상 작업에 사용 금지

접근 방법
├── Console    → 비밀번호 + MFA
├── CLI        → Access Key
└── SDK        → Access Key

보안 도구
├── Credentials Report → 계정 전체 자격증명 현황
├── Access Advisor     → 사용자별 미사용 권한 파악
└── Access Analyzer    → 외부 노출 및 미사용 권한 자동 탐지

📚 참고 자료

🧩 동시성(Concurrency)

Sun, 26 Oct 2025 00:00:00 GMT

🧩 동시성(Concurrency)

**동시성(Concurrency)**이란 여러 개의 작업을 동시에 처리하는 것처럼 보이게 하는 것이다.

단일 CPU 환경에서 **빠른 전환(Context Switching)**을 통해 여러 작업이 동시에 진행되는 것처럼 보이게 하는 기법으로, CPU가 한순간 하나의 작업만 처리하지만, 빠른 전환 속도로 마치 여러 작업이 겹쳐 실행되는 듯한 효과를 낼 수 있다.

즉 동시성은 실제로 여러 작업이 동시에 실행되는 것이 아니라, **작업의 “진행 순서를 조율”**함으로써 동시에 처리되는 듯한 효과를 만드는 것이다. 따라서 동시성은 ‘일정한 시간 단위 내에서 여러 일을 조율하는 능력이라고 볼 수 있다.

🆚 병렬성(Parallelism)과의 차이점?

병렬성은 여러 작업을 실제로 동시에 처리하는 것이다.

여러 CPU 또는 코어를 사용하여 (물리적으로) 여러 작업을 병렬로 처리한다. 각각의 작업은 별도의 프로세스나 스레드에서 실행되며, 이러한 작업들은 각각이 독립적으로 실행되기 때문에 서로 영향을 주지 않는다.

구분	설명	예시
동시성(Concurrency)	여러 작업을 동시에 겹쳐서 처리하되, 실제 CPU는 하나씩 번갈아가며 처리	한 사람이 전화, 메일, 채팅 업무를 번갈아 가면서 처리
병렬성(Parallelism)	여러 작업을 동시에 여러 CPU 코어에서 수행	3명이 각각 전화, 메일, 채팅 업무를 받아서 동시에 처리

🚦 프론트엔드에서 동시성

브라우저는 사용자 상호작용과 다양한 비동기 이벤트를 동시에 다뤄야 한다.

사용자의 입력 이벤트 (Click, Typing input values 등)
네트워크 통신 (API 요청)
애니메이션 렌더링 (CSS, requestAnimationFrame)
타이머 (setTimeout, setInterval)
React의 상태 업데이트

이러한 작업을 동시에 진행하면서 서로 영향을 주지 않고 매끄럽게 동작하여 사용자의 UX에 부정적인 영향이 가지 않도록 하게 하는 것이 중요하다. 즉, 단일 스레드 환경인 브라우저에서 비동기 이벤트를 효율적으로 스케줄링하여 “사용자 상호작용(User Interaction)과 렌더링이 경쟁하지 않도록” 해야 한다.

📝 동시성이 중요한 몇 가지 사례 (Cases)

💬 검색 자동완성 / 필터링 UI

Situation:
- 사용자가 입력할 때마다 사용자의 입력값을 기반으로 API 요청
- 사용자가 빠르게 타이핑 시 이전 요청에 대한 응답이 돌아오기 전에 새로운 요청 발생
- 나중에 처리된 이전 요청의 응답이 새로운 검색 결과를 덮어쓰는 상황 발생
Problem:
- UI가 최신 상태를 반영하지 못함
- 뒤늦은 응답이 최신 입력을 덮어버리는 Race Condition 발생
How to solve?
- AbortController로 이전 요청에 대한 중단을 통해 Race Condition 방지
- Concurrent Rendering: useTransition을 사용해 입력(우선순위 High) vs. 렌더링(우선순위 Low) 구분지어 우선순위 기준으로 변경사항 처리

📑 탭 전환 + API 요청

Situation:
- 사용자가 탭을 전환하는 순간, 이전 탭의 데이터 요청이 아직 완료되지 않았을 경우
- 전환 후 이전 탭 전환 시 호출했던 요청에 대한 응답 도착 → 새로운 탭의 UI를 이전 요청에 대한 응답이 덮어씀
Problem:
- 상태 꼬임 (State inconsistency)
- 사용자 경험 저하 (잘못된 데이터 표시 또는 UI 깜빡거림 발생)
How to solve?
- AbortController 또는 React Query의 cancelQueries()로 이전 요청 취소
- React의 Concurrent Rendering 활용
  - startTransition을 이용해 전환 렌더링을 낮은 우선순위로 처리

📃 대량 데이터 렌더링 + 사용자 입력

Situation:
- 몇 만 개의 데이터를 렌더링 중에 사용자의 입력 발생
- 렌더링이 끝나기 전까지 사용자의 입력이 UI에 반영되지 않음 (입력이 “먹통”처럼 보임)
Problem:
- 메인 스레드가 렌더링으로 점유되어 입력 이벤트 처리 지연
How to solve?
- Virtualization (react-window, react-virtualized)
- React Concurrent Mode로 렌더링을 나누어 “프레임 단위”로 분할 처리

✏️ 자동 저장(Auto Save) + 사용자 입력

Situation:
- 사용자가 입력 중일 때 일정 주기로 자동 저장 API 호출
- 네트워크가 느릴 경우 이전 입력 값으로 덮어써버림
Problem:
- 서버와 클라이언트의 상태 불일치 (Stale data)
- 입력 중단이나 깜빡임 발생
How to solve?
- 클라이언트에 버전 키(version key) 관리
- 요청 완료 시점 기준이 아닌 입력 타임스탬프 기준으로 반영
- useDeferredValue로 입력값을 늦게 반영해 충돌 방지

🎨 애니메이션 처리 + API 호출

Situation:
- 스크롤 애니메이션, 모션 효과가 있는 상태에서 fetch 요청이 동시에 일어남
- 렌더링 성능 떨어지면서 프레임 드랍(Frame drop) 발생
Problem:
- 동시성 부하로 인해 애니메이션이 끊김
How to solve?
- requestIdleCallback으로 idle 타임에 비동기 호출
- Concurrent Rendering으로 렌더링과 애니메이션 스케줄링 분리

🧩 React의 Concurrent Rendering 이전에 동시성 제어

React 18 이후부터는 React에서 **React 내부 스케줄러(Fiber Scheduler)**가 렌더링 우선순위를 자동으로 조정하여 동시성 제어를 지원한다.

그렇다면 React가 이러한 제어를 하기 이전에는 프론트엔드의 사용자 입력 지연 문제, API 경쟁 상태(Race Condition) 등을 어떻게 처리했을까?

🧩 수동적인 제어 방식

React 18 이전에는 모든 상태 업데이트와 렌더링이 **동기적(Synchronous)**으로 진행되었다.

즉 입력 이벤트, API 호출, 렌더링이 모두 같은 우선순위로 실행되었기 때문에 사용자 입력 중에도 UI가 버벅이거나, 이전 요청이 나중에 도착하면서 최신 상태를 덮어쓰는 등의 문제가 발생했다. 이러한 문제 해결을 위해서 debounce, throttle, request cancellation 등 수동적인 제어 방식을 활용했다.

⚙️ Throttle and Debounce

debounce 함수 구현 예시

→ 사용자가 입력을 멈추고 일정 시간(delay) 동안 아무 입력이 없을 때만 요청을 보냄

function debounce(fn, delay) {
  let timer;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delay);
  };
}

// 검색 API
const handleSearch = debounce((value) => {
  fetch(`/api/search?q=${value}`);
}, 500);

<input onChange={(e) => handleSearch(e.target.value)} />

throttle 함수 구현 예시

→ 200ms 단위로 스크롤 이벤트가 실행하도록 제한

function throttle(fn, limit) {
  let inThrottle;
  return (...args) => {
    if (!inThrottle) {
      fn(...args);
      inThrottle = true;
      setTimeout(() => (inThrottle = false), limit);
    }
  };
}

// 스크롤 이벤트
window.addEventListener(
  'scroll',
  throttle(() => console.log(window.scrollY), 200)
);

함수	작동 방식	대표 사례	함수의 실행 목적
debounce	마지막 이벤트 이후 일정 시간 동안 추가 이벤트 진행이 없을 때 실행	검색 자동완성	“마지막 입력만 반영” → 불필요한 API 호출 방지
throttle	일정 시간 간격마다 한 번만 실행	스크롤/resize 이벤트	“일정 시간을 기준으로 실행” → CPU 부하 완화

⚙️ AbortController (Request Cancellation - 요청 취소)

fetch 요청을 보낼 때 이전 요청이 완료되기 전에 새로운 요청이 발생하면, 이전 요청의 응답이 나중에 도착하면서 UI가 이전 상태로 되돌아가는 문제가 발생했다.

이런 문제를 해결하기 위해 수동으로 요청 제어를 할 수 있는 AbortController를 사용해 이전 요청을 취소하는 방식이 널리 사용되었다.

function useSearch() {
  const controllerRef = useRef();

  const fetchSearchResults = async (query) => {
	  // 진행되는 요청 있으면 취소 (abort)
    if (controllerRef.current) controllerRef.current.abort();
    const controller = new AbortController();
    controllerRef.current = controller;

    try {
      const res = await fetch(`/api/search?q=${query}`, {
        signal: controller.signal, // abort controller를 통한 호출 관리를 위한 signal
      });
      const data = await res.json();
      console.log('결과:', data);
    } catch (error) {
      if (error.name === 'AbortError') {
        console.log('요청이 취소되었습니다.');
      }
    }
  };

  return { fetchSearchResults };
}

🔥 수동적인 제어 방식이 갖는 한계점

UX 불안정성
- 사용자의 입력 타이밍에 따라 반응이 지연되거나, 반영이 느려 보일 수 있음
- 사용자의 입력 타이밍을 추측하여 그에 맞는 실행 시간에 대한 별도 제어가 필요함
렌더링과의 분리 불가
- 이벤트 발생 빈도 제어는 가능하지만, 렌더링 자체의 우선순위 조절은 불가능
React 내부 상태 업데이트와 별개
- React 렌더링 사이클과는 무관하게 동작하여 상태 불일치(stale state) 가능
코드 중복 / 복잡도 증가
- debounce, throttle, abort controller 등을 매 함수마다 따로 관리 필요

🧩 React 18 이후의 변화 - Concurrent Rendering

❓ Concurrent Rendering이란?

Concurrent Rendering은 React 18 버전에서 처음 도입되어, React 19에서도 지속적으로 개선되고 있는 동시적 렌더링(Concurrent Rendering) 기능이다.

기존의 동기적(Synchronous)으로 진행되었던 렌더링 작업을 작은 단위로 분할하여 우선순위 기반으로 스케줄링할 수 있도록 하며, 필요 시 중단 및 재개가 가능하도록 하여 **UI의 반응성(Responsiveness)**을 유지하는 동시적 렌더링 방식이다.

Concurrent Rendering의 특징

변경 우선순위에 따른 렌더링 (Prioritized Updates): React는 Fiber 아키텍처를 기반으로 변경 우선순위에 따라 Fiber 노드를 스케줄링한다. 예를 들어, 사용자 입력과 같은 ‘긴급한 업데이트(high priority)’는 즉시 처리하고, 데이터 fetch나 렌더링과 같은 ‘비긴급 업데이트(low priority)’는 나중에 처리하여 빠르게 반영되어야 하는 변경사항을 우선적으로 처리할 수 있다.
논 블로킹 (Non-Blocking): 렌더링이 메인 스레드를 완전히 점유하지 않고, **일정 단위마다 중단(yield)**하여 이벤트나 사용자 입력을 처리할 수 있는 시간을 확보한다. 따라서 작업량이 많고 복잡한 업데이트를 진행하더라도 애플리케이션은 여전히 끊김 없이 사용자가 상호작용 할 수 있도록 해 UX를 저해하지 않을 수 있다.
세밀한 제어 (Fine-Grained Control): React는 Fiber 단위로 각 업데이트의 우선순위를 계산해서 자동 조정한다. 또한 개발자는 useTransition, useDeferredValue, Suspense 등을 통해 간접적으로 우선순위 힌트를 제공할 수 있다. 이를 통해 개발자는 렌더링 흐름을 직접 제어하지 않고도 UI의 반응성과 렌더링 효율을 균형 있게 관리할 수 있다.

✅ Concurrent Rendering은 React가 렌더링 과정을 **동기적(Synchronous)**에서 스케줄링 가능한 비동기적(Asynchronous) 과정으로 전환함으로써, 복잡한 UI에서도 **입력 반응성(Responsiveness)**과 **렌더링 유연성(Flexibility)**을 확보하여 끊김 없는 사용자 경험(Seamless UX)를 제공할 수 있는 핵심 기술이다.

📚 참고자료

https://yozm.wishket.com/magazine/detail/2996/
https://www.linkedin.com/pulse/react-19-concurrent-rendering-boosting-performance-modern-machado-m707f/

Concurrent Rendering을 활용할 수 있는 React API

Sun, 26 Oct 2025 00:00:00 GMT

Concurrent Rendering을 활용할 수 있는 React API

React 18부터는 내부 스케줄러(Fiber Scheduler)가 Concurrent Rendering을 지원하면서 개발자가 렌더링 우선순위를 직접 제어하거나 힌트를 줄 수 있는 다양한 API가 새롭게 추가되었다.

이 API들은 모두 “UI 반응성을 유지하면서 무거운 렌더링이나 비동기 처리를 부드럽게 실행”하는 것을 목표로 한다.

useTransition

useTransition is a React Hook that lets you render a part of the UI in the background. useTransition은 UI의 특정 부분을 백그라운드에서 렌더링할 수 있도록 하는 React 훅이다.

const [isPending, startTransition] = useTransition();

useTransition 훅의 우선순위 조정

useTransition은 상태 업데이트를 **낮은 우선순위(Transition 상태)**로 마킹해준다.

React는 모든 상태 업데이트를 Lane(우선순위 트랙)에 배치하여 스케줄링한다. startTransition으로 감싼 업데이트는 TransitionLane에 할당되어 (사용자 입력 등과 같이 높은 우선순위 Lane을 부여 받은 작업보다) 낮은 우선순위로 처리된다.

사용자 입력(setKeyword) → SyncLane (높은 우선순위)
필터링(setFiltered)     → TransitionLane (낮은 우선순위)

즉 “지금 바로 반응해야 하는 작업(입력, 클릭)”과 “조금 늦게 반영되어도 되는 작업(리스트 렌더링, 필터링) 결과 표시”를 분리해준다.

📦 사용자 입력 + 검색 필터링 예시

import { useState, useTransition } from 'react';

function SearchList({ items }) {
	const [keyword, setKeyword] = useState("");
	const [filtered, setFiltered] = useState(items);
	const [isPending, startTransition] = useTransition();
	
	const handleChange = (e) => {
		const value = e.target.value;
		setKeyword(value); // 즉시 반영
		
		// 렌더링 여유 있을 때 실행하도록 우선순위 조정
		startTransition(() => {
			const result = items.filter((item) => item.toLowerCase().includes(value.toLowerCase()));
			setFiltered(result);
		});		
	}
	
	return (
		<div>
			<input value={keyword} onChange={handleChange} />
			{isPending && <p>검색 중입니다...</p>}
			<ul>
				{filtered.map((item) => (
					<li key={item.itemId}>{item.name}</li>
				))}
			</ul>
		</div>
	)
}

🧠 동작 원리

setKeyword → 즉시 렌더링 (높은 우선순위)
- 사용자의 입력이 즉각 반영되어 입력 지연이 발생하지 않는다
startTransition 내부의 setFiltered → 낮은 우선순위로 스케줄링
- React는 브라우저가 idle 상태일 때(즉, 여유가 있을 때) 해당 렌더링을 수행한다.
- 만약 렌더링 도중 새로운 high-priority 이벤트가 발생하면, transition 렌더링은 즉시 중단(yield)되었다가 다시 재개된다.
isPending → Transition 상태 동안 true
- 백그라운드 렌더링이 진행 중임을 나타내며, 로딩 표시 등에 활용할 수 있다

⚡장점

✅ 입력 반응성 유지
- 무거운 필터링이나 렌더링이 있어도 입력 타이핑 끊김 현상 발생 방지
✅ 부드러운 전환 (Transition)
- 리스트나 UI 변화가 부드럽게 진행되며, React가 여유 있을 때만 렌더링을 수행
✅ 로딩 상태 표시 가능
- isPending을 통해 Transition 중임을 감지하여, 스켈레톤 UI, 스피너 등을 표시할 수 있음
✅ Race condition 방지
- startTransition으로 감싼 비동기 처리(fetch 등)는 렌더링 반영 시점을 조절하기 때문에,
  - 사용자의 빠른 입력 변경과 서버 응답 도착 간의 **UI 불일치 현상(stale UI)**을 줄이는 데 도움이 된다.
  - (단, 네트워크 요청 자체를 취소하려면 AbortController를 병행해야 한다.)

useDeferredValue

useDeferredValue is a React Hook that lets you defer updating a part of the UI. useDeferredValue는 UI의 특정 부분의 업데이트를 지연시킬 수 있도록 하는 React 훅이다.

const deferredValue = useDeferredValue(value)

공식 문서에 따르면 useDeferredValue는 새로운 콘텐츠가 로딩되는 동안 stale(신선하지 않은 상태)한 콘텐츠를 보여줄 때 사용할 수 있다. (Showing stale content while fresh content is loading)

따라서, useDeferredValue는 **값(value)**을 기반으로 렌더링되는 UI가 있을 때, 그 값을 “조금 늦게 반영”하도록 만들어 UI 반응성을 유지하는 훅이다.

업데이트가 진행될 때, 최초 리렌더링 시에는 이전 값(deferred value)을 그대로 사용하고, 백그라운드에서 새롭게 전달 받은 값을 다음 렌더링 시에 반영함으로서 UI의 상태 불일치를 최소화할 수 있도록 한다.

useDeferredValue 훅의 우선순위 조정

useTransition과 마찬가지로 useDeferredValue로 생성된 값의 업데이트는 TransitionLane에 매핑된다.

사용자 입력(setKeyword) → SyncLane (높은 우선순위)
필터링(setFiltered)     → TransitionLane (낮은 우선순위)

결과적으로 사용자 입력은 즉시 반영하지만 리스트는 조금 늦게 업데이트되는 자연스러운 UX 경험을 제공할 수 있다.

📦 사용자 입력 + 검색 필터링 예시

import { useState, useDeferredValue } from 'react';

function SearchList({ items }) {
	const [keyword, setKeyword] = useState('');
	const deferredKeyword = useDeferredvalue(keyword); // 입력값 늦게 반영
	
	const filteredItems = items.filter((item) => item.toLowerCase().includes(deferredQuery.toLowerCase());
	
	return (
		<div>
			<input value={keyword} onChange={(e) => setKeyword(e.target.value)} />
			<ul>
				{filteredItems.map((item) => (
					<li key={item.itemId}>{item.name}</li>
				))}			
			</ul>
		</div>
	)
}

🧠 동작 원리

setKeyword → 즉시 렌더링 (높은 우선순위)
- 사용자의 입력이 즉각 반영되어 입력 지연이 발생하지 않는다
deferredQuery → keyword의 지연된 버전
- React가 브라우저의 렌더링 우선순위를 고려해 **TransitionLane(낮은 우선순위)**로 스케줄링
- 렌더링이 무거운 경우, React는 사용자 입력이 먼저 처리된 뒤 여유가 있을 때 deferredQuery 기반의 렌더링을 수행

⚡장점

✅ 입력 반응성 유지
- 무거운 필터링이나 렌더링이 있어도 입력 타이핑 끊김 현상 발생 방지
✅ 렌더링 부하 완화
- 무거운 필터링, 정렬, 데이터 렌더링 연산을 브라우저가 idle한 시점에 수행 가능
✅ 다른 훅에서 활용 가능
- useDeferredValue는 React Query, 상태 관리 라이브러리 등에 상태 값에도 적용 가능하여 전역 상태 기반 UI 렌더링 반응성 개선이 가능하다

📚 참고자료

https://react.dev/reference/react/useTransition
https://react.dev/reference/react/useDeferredValue
https://goidle.github.io/react/in-depth-react18-lane/

❓ Zero-runtime CSS-in-JS?

Tue, 30 Sep 2025 00:00:00 GMT

❓ Zero-runtime CSS-in-JS?

최근 진행하고 있는 사이드 프로젝트에서 디자인 토큰 시스템을 개발하면서 Vanilla Extract를 도입하게 되었다. 이 과정에서 자연스럽게 *“Zero-runtime CSS-in-JS란 무엇일까?”*라는 의문이 생겼고, 관련 개념을 공부하다 보니 CSS-in-JS의 등장 배경과 Zero-runtime CSS-in-JS가 어떤 한계를 보완하기 위해 나왔는지 이해할 필요가 있었다.

전통적인 CSS의 한계를 극복하기 위해 등장한 CSS-in-JS, 그리고 그 단점을 보완하기 위해 진화한 Zero-runtime CSS-in-JS까지의 흐름을 정리하고, 두 접근 방식이 실제로 어떤 차이를 보이는지 간단한 벤치마킹을 진행해 보았다.

전통적인 CSS의 문제점

브라우저의 렌더링 동작 방식(Critical Rendering Path)은 다음과 같다:

서버로부터 HTML을 다운로드 받고 DOM 트리를 생성한다.
CSS 파일을 다운로드하고 CSSOM 트리를 생성한다.
DOM 트리와 CSSOM 트리를 결합하여 Render Tree를 생성한다.
Render Tree를 기반으로 레이아웃과 페인트 작업을 거친다.

Render Tree는 실제로 화면에 그려질 요소와 스타일 정보를 결합한 구조다.

이때 CSSOM이 완성되지 않으면 렌더링이 지연되며, CSS 파일이 크거나 선택자가 많을수록 CSSOM 생성 시간이 길어져 사용자 경험을 해칠 수 있다.

이를 개선하기 위한 한 가지 방법으로는 CSS를 작은 단위로 분리해 CSSOM을 빠르게 구성하는 방식을 고려할 수 있다. 하지만 이렇게 분할된 파일이 늘어나면 늘어날수록 관리 포인트가 많아지고, 전역 스코프 문제로 인해 클래스/선택자 충돌 위험이 커지는 단점이 존재한다. 컴포넌트 수가 많아질수록 이 문제는 더 심각해질 것이다.

이러한 한계를 보완하기 위해 등장한 것이 바로 CSS-in-JS다.

🎨 CSS-in-JS

CSS-in-JS는 컴포넌트 안에서 자바스크립트와 함께 CSS를 작성할 수 있게 해준다.

이 방식은 직관적이고, 여러 CSS 파일을 따로 관리하는 것보다 유지보수가 용이하다.

import styled from "styled-components";

const StyledButton = styled.button`
  padding: 0.75em 1em;
  border-radius: 4px;
  background-color: ${ ({ primary }) => ( primary ? "blue" : "gray" ) };
  color: white;
  &:hover {
    background-color: #111;
  }
`;

export default StyledButton;

// App
import StyledButton from './components/StyledButton'

function App() {
	return (
		<div className="app">
			<StyledButton>Button</StyledButton>
			<StyledButton primary>Primary Button</StyledButton>			
		</div>
	)
}

CSS-in-JS의 가장 큰 장점은 스코프 문제 해결이다. 스타일이 컴포넌트 로컬 스코프에 선언되므로 다른 컴포넌트와 충돌할 염려가 없다.

또한 props에 따라 동적으로 스타일을 지정할 수 있어 동적 스타일링이 가능한 점도 큰 장점이다.

CSS-in-JS의 단점

이처럼 CSS-in-JS는 전통적인 CSS의 한계를 극복하기 위해 탄생했지만 모든 문제를 완벽히 해결하지는 못한다.

CSS-in-JS는 런타임 시점에 라이브러리가 스타일을 해석하고 적용하기 때문에 런타임 오버헤드가 발생한다. 또한 전통적인 CSS는 브라우저 캐싱의 이점을 누릴 수 있지만, 런타임에 동적으로 생성되는 CSS-in-JS는 캐싱 효과를 기대하기 어렵다.

🧩 Zero-runtime CSS-in-JS의 등장

Zero-runtime CSS-in-JS는 CSS-in-JS의 단점을 보완하기 위해 등장했다.

대표적으로 Vanilla Extract, Panda CSS 등이 있다.

Vanilla Extract는 빌드 시점에 className을 확정하고 CSS 파일을 정적으로 출력한다. 따라서 런타임에는 단순히 문자열을 바인딩하는 것만으로 빠르게 스타일을 적용할 수 있다.

즉, CSS-in-JS가 제공하는 생산성과 확장성은 유지하면서도, 런타임 오버헤드를 제거하여 성능 문제를 보완하는 방식이다.

🆚 CSS-in-JS vs. Zero-runtime CSS-in-JS 벤치마크

그렇다면 실제로 CSS-in-JS와 Zero-runtime CSS-in-JS는 얼마나 차이가 있을까? 이를 확인하기 위해 React + Vite 환경에서 3,000개의 Box 컴포넌트를 렌더링하고, Styled-components와 Vanilla Extract를 비교하는 간단한 벤치마킹을 진행했다.

📃 벤치마크 시나리오

React + Vite 환경에서 3,000개의 Box 컴포넌트 렌더링
Styled-components vs. Vanilla Extract 비교

CSS-in-JS 벤치마크

코드 예시

Vanilla Extract를 활용한 Box Style

// zero-runtime.css.ts
import { style } from "@vanilla-extract/css";

export const box = style({
  width: "24px",
  height: "24px",
  borderRadius: "4px",
});

export const variants = [
  style({ background: "#1e3a8a" }),
  style({ background: "#2563eb" }),
  style({ background: "#16a34a" }),
  style({ background: "#d97706" }),
  style({ background: "#dc2626" }),
];

export const bordered = style({
  outline: "1px solid rgba(0,0,0,.08)",
});

export const shadowed = style({
  boxShadow: "0 1px 2px rgba(0,0,0,.12)",
});

// ZeroRuntimeBoxes.tsx
import * as styles from "../zero-runtime.css";

type BoxProps = {
  variant: number;
  bordered: boolean;
  shadowed: boolean;
};

function Box({ variant = 0, bordered = false, shadowed = false }: BoxProps) {
  const boxStyles = [
    styles.box,
    styles.variants[variant],
    bordered ? styles.bordered : "",
    shadowed ? styles.shadowed : "",
  ].join(" ");
  return <div className={boxStyles}></div>;
}

type ZeroRuntimeBoxesProps = {
  N: number;
  variantSeed: number;
};

export default function ZeroRuntimeBoxes({
  N,
  variantSeed,
}: ZeroRuntimeBoxesProps) {
  const items = new Array(N).fill(0).map((_, i) => (i + variantSeed) % 5);
  const bordered = variantSeed % 2 === 0;
  const shadowed = variantSeed % 3 === 0;
  return items.map((v, i) => (
    <Box key={i} variant={v} bordered={bordered} shadowed={shadowed} />
  ));
}

Styled Component를 활용한 Box Style


import styled from "styled-components";

type BoxProps = {
  variant: number;
  bordered?: boolean;
  shadowed?: boolean;
};

const Box = styled.div<BoxProps>`
  width: 24px;
  height: 24px;
  border-radius: 4px;
  background: ${(p) =>
      ["#1e3a8a", "#2563eb", "#16a34a", "#d97706", "#dc2626"][p.variant]}
    ${(p) => (p.bordered ? "outline: 1px solid rgba(0,0,0,.08);" : "")}
    ${(p) => (p.shadowed ? "box-shadow: 0 1px 2px rgba(0,0,0,.12);" : "")};
`;

type StyledBoxesProps = {
  N: number;
  variantSeed: number;
};

export default function StyledBoxes({ N, variantSeed }: StyledBoxesProps) {
  const items = new Array(N).fill(0).map((_, i) => (i + variantSeed) % 5);
  const bordered = variantSeed % 2 === 0;
  const shadowed = variantSeed % 3 === 0;
  return items.map((v, i) => (
    <Box key={i} variant={v} bordered={bordered} shadowed={shadowed} />
  ));
}

React DevTools Profiler로 렌더링 시간 측정

Styled Components

Vanilla Extract

Styled-components Mount, Update 시간 출력

Vanilla Extract Mount, Update 시간 출력

(렌더링 시간 비교)

Styled-components 렌더링 시간: 339.3ms
Vanilla Extract 렌더링 시간: 284.5ms
약 16% 차이

(Console 측정 기준)

Mount: Styled-components는 0.50ms, Vanilla Extract는 0.20ms → 초기 렌더링에서 약 2.5배 차이
Update: Styled-components는 0.72ms, Vanilla Extract는 0.08ms → 업데이트에서 약 9배 차이

👉 벤치마크 결과 측정 결과 상 Zero-runtime 방식이 런타임 오버헤드를 줄인다는 점을 확인할 수 있다.

</aside>

✏️ 벤치마킹을 진행하면서…

사실 CSS-in-JS를 활용한 경험이 전무했던 터라, 두 접근 방식이 어떤 차이가 있는지, 그리고 DX(Developer Experience) 측면에서 각각의 장단점이 무엇인지 뚜렷하게 알지 못한 상태에서 이번 벤치마킹을 시작했다.

여전히 거대한 global.css 빌드 결과물의 크기를 줄이기 위해 고군분투하고, 컴포넌트 단위 CSS 모듈화를 두고 치열하게 고민하는 입장에서 이번 미니 벤치마킹은 굉장히 신선한 경험이었다.

특히 컴포넌트 내부에서 스타일을 정의하고 조건부 처리나 variant 기반의 디자인을 적용할 수 있다는 점에서 DX적인 장점을 크게 체감할 수 있었다.

벤치마킹을 진행하며 느낀 두 방식의 차이점은,

Styled-components는 이미 많은 회사에서 활용되는 만큼 생태계와 플러그인이 풍부하고, 직관적인 API를 통해 스타일을 작성할 수 있는 점이 매력적으로 다가왔다. 하지만 런타임 오버헤드라는 태생적인 성능 문제는 피하기 어렵고, 컴포넌트 단위가 커질수록 스타일 코드가 함께 섞이면서 직관성이 떨어질 수 있겠다는 우려도 생겼다.
Vanilla Extract는 CSS-in-JS의 런타임 오버헤드 문제를 최소화하면서도, 현재 설계 중인 디자인 토큰 시스템과 연동하여 테마 관리와 확장을 손쉽게 할 수 있다는 장점이 있었다. 이런 이유로 이번 프로젝트에서는 Vanilla Extract를 도입하기로 결정했다.

전통적인 CSS 방식을 고수하던 관성에서 벗어나, 다양한 스타일링 접근 방식을 직접 경험해 볼 수 있었다는 점에서 이번 벤치마킹은 매우 유익한 시간이었다.

📚 참고자료

https://junghan92.medium.com/번역-우리가-css-in-js와-헤어지는-이유-a2e726d6ace6
https://blog.logrocket.com/css-vs-css-in-js/#render-blocking-css
https://vanilla-extract.style/

🧩 Javascript의 Object

Wed, 20 Aug 2025 00:00:00 GMT

🧩 Javascript의 Object

최근 깊은 복사를 위한 유틸리티 함수를 직접 구현하라는 과제를 받았다.

단순한 객체만이 아니라 Array, Map, Set은 물론 커스텀 객체까지 모두 제대로 복사할 수 있어야 했다. 처음엔 키-값 쌍을 재귀적으로 새 객체에 복사하는 방식으로 해결하려 했지만, 곧 다양한 객체 타입을 정확히 다루려면 자바스크립트의 Object, 속성 구조, 그리고 프로토타입 체계에 대한 이해가 필수적이었다.

이 과정에서 내가 객체 시스템에 대해 얼마나 피상적으로 알고 있었는지 실감했고, 이를 계기로 관련 개념을 깊이 있게 학습하고 정리해보게 되었다.

1) Object란?

객체는 **데이터와 기능(메서드)**를 키–값 쌍으로 저장하는 구조.

const person = {
  name: 'MyName',
  age: 25,
  greeting() {
    console.log("Hello, my name is", this.name);
  }
};

name, age는 속성(property), greeting은 메서드(method).

2) 객체 생성 방법

✅ 리터럴

const obj = { key: 'value', number: 12345 };

✅ 생성자 & Object.create

const obj = new Object();
obj.key = 'value';
obj.number = 12345;

// 원본의 프로토타입/디스크립터까지 유지 복사
const clone = Object.create(
  Object.getPrototypeOf(obj),
  Object.getOwnPropertyDescriptors(obj)
);

Object.create(proto, descriptors): 지정한 프로토타입과 디스크립터로 새 객체 생성.

✅ 클래스

class Person {
  constructor(name, age) { this.name = name; this.age = age; }
}
const personA = new Person("a", 27);

✅ Getter/Setter

const person = {
  firstName: 'value',
  lastName: '12345',
  get fullName() { return `${this.firstName} ${this.lastName}`; },
  set fullName(name) { [this.firstName, this.lastName] = name.split(" "); }
};

3) 속성 접근

const a = new Person("a", 27);
console.log(a.name);      // 점 표기법
console.log(a['name']);   // 대괄호 표기법

4) 속성 추가/수정/삭제

const p = new Person("a", 27);
p.job = 'Developer'; // 등록
p.age = 26; // 변경
delete p.job; // 삭제

Object.defineProperty / defineProperties

const p2 = new Person("a", 27);
Object.defineProperties(p2, {
  job: { value: 'Developer', writable: true, configurable: true, enumerable: true }
});
Object.defineProperty(p2, "favoriteFood", {
  value: 'apple', writable: true, configurable: true, enumerable: true
});

디스크립터로 쓰기/열거/재정의 가능 여부를 제어.
- writable
- configurable
- enumerable

5) 변경 제약: freeze / seal (＋preventExtensions)

Object.freeze() 메서드를 통해 객체를 동결하게 되면 동결된 객체는 더 이상 새로운 속성을 추가하거나 제거하는 것을 방지한다.
- 존재하는 속성의 불변성, 설정 가능성, 작성 가능성이 변경되는 것 역시 방지되며, 존재 속성의 값을 수정하는 것도 방지한다.
Object.seal() 메서드를 통해 객체를 밀봉하게 되면 새로운 속성의 추가가 불가능하며 현재 존재하는 속성을 설정 불가능 상태로 만들어준다. 다만 쓰기 가능한 속성에 대한 속성의 값은 밀봉 후에도 변경할 수 있다는 점에서 Object.freeze() 메서드와 차이가 있다.
동결/밀봉 여부는 Object.isFrozen(), Object.isSealed() 메서드를 통해 확인할 수 있다.

const f = Object.freeze(new Person("a", 25));
f.age = 27; // 무시
console.log(Object.isFrozen(f), Object.isSealed(f)); // true, true

const s = Object.seal(new Person("a", 26));
s.age = 27; // 가능(속성 writable이면)
console.log(Object.isFrozen(s), Object.isSealed(s)); // false, true

메서드	새 속성 추가	기존 속성 삭제	값 변경(쓰기)	디스크립터 변경
`Object.freeze`	❌	❌	❌	❌
`Object.seal`	❌	❌	✅ (writable일 때)	일부 ❌
`Object.preventExtensions`	❌	✅	✅	✅

6) 속성 보유 확인: `hasOwnProperty` vs `Object.hasOwn`

객체가 특정 속성을 자신의 속성으로 가지고 있는지 확인할 때 hasOwnproperty 메서드나 ES2022에 새로 추가된 정적 메서드인 Object.hasOwn()을 사용할 수 있다.

class Person {
  constructor(name, age) { this.name = name; this.age = age; }
  greeting() { console.log("Hi", this.name); }
}
const p = new Person("person", 25);
p.sayHello = function() { console.log("Hello", this.name); };

console.log(p.hasOwnProperty("name"));      // true
console.log(Object.hasOwn(p, "name"));      // true
console.log(Object.hasOwn(p, "sayHello"));  // true
console.log(Object.hasOwn(p, "greeting"));  // false (프로토타입의 메서드)

Object.hasOwn(obj, key)는 안전한 정적 메서드 (인스턴스가 hasOwnProperty를 오버라이드해도 안전).

🧬 프로토타입 체인

🔗 프로토타입

자바스크립트의 모든 객체는 내부 [[Prototype]] 링크를 가진다.
이러한 구조를 통해 객체는 클래스 기반 언어의 상속처럼 공통 속성과 메서드를 상속받거나 참조할 수 있으며, 이렇게 형성된 상속 구조를 **프로토타입 체인(Prototype Chain)**이라고 한다.
- 없으면 자기 자신 → 프로토타입 → … → Object.prototype → null로 탐색.

const arr = [1, 2, 3];
console.log(arr.toString()); // "1,2,3"  (Array.prototype → Object.prototype)

🛠️ 생성자 함수와 프로토타입

new 연산자로 객체를 생성하면 해당 객체는 생성자 함수의 prototype 속성을 자신의 [[Prototype]]으로 연결한다.

function Person(name) { 
	this.name = name; 
}
Person.prototype.sayHello = function () { console.log(`Hi, I'm ${this.name}`); };
const p1 = new Person("Alice");
console.log(p1.sayHello === Person.prototype.sayHello); // true

7) 속성 설명자 조회

const p = new Person("a", 1);
Object.defineProperty(p, "job", {
  value: 'Developer', writable: true, configurable: false, enumerable: true
});
console.log(Object.getOwnPropertyDescriptors(p));

getOwnPropertyDescriptors로 모든 own 속성의 디스크립터를 조회할 수 있다.

8) 객체 순회

for…in

// for...in (자신 + 상속된 enumerable 포함)
for (const k in p) console.log(k, p[k]);

Object.keys / values / entries

// own enumerable만
Object.keys(p);    // 키 배열
Object.values(p);  // 값 배열
Object.entries(p); // [키,값] 배열  (정수 키 → 문자열 키 삽입 순서)

열거 불가능/심볼 키

const obj = { a: 1, b: 2 };
Object.defineProperty(obj, "c", { value: 3, enumerable: false });

console.log(Object.keys(obj));               // ['a','b']
console.log(Object.getOwnPropertyNames(obj));// ['a','b','c']

const sym = Symbol('id');
const o2 = { [sym]: 123, a: 1 };
console.log(Object.getOwnPropertySymbols(o2)); // [Symbol(id)]

9) Map ↔ Object 변환

Object.entries()는 for...in과 같은 순서로 주어진 객체 자체의 enumerable 속성을 키-값 쌍 형태의 배열로 반환한다. 이를 활용하여 Map으로 변환할 수 있다.
반대로 Object.fromEntries는 키-값 쌍 형태의 배열을 객체로 변환해주는 메서드이다. 이를 통해 Map을 Object로 변환할 수 있다.

const object = { a: 1, b: 2, c: 3 };
const map = new Map(Object.entries(object));   // Object → Map

const fromMap = new Map([["a",1],["b",2]]);
const toObj = Object.fromEntries(fromMap);     // Map → Object

10) 객체 복사

✅ 얕은 복사

const copy1 = Object.assign({}, person);
const copy2 = { ...person };

// 프로토타입/비열거 속성까지 살리는 얕은 복사
const copyAll = Object.create(
  Object.getPrototypeOf(person),
  Object.getOwnPropertyDescriptors(person)
);

얕은 복사 시에는 중첩 객체는 참조 공유 → 내부 변경이 원본에 전파한다.
Object.assign()을 통한 복사는 목표 객체로 열거 가능한 속성과 객체의 속성들만 복사할 수 있지만 Object.getPrototypeOf, Object.getOwnPropertyDescriptors를 활용하면 열거 불가능한 속성들도 복사할 수 있다.

✅ 병합

const m = Object.assign({}, obj1, obj2); // 뒤에 온 키가 덮어씀
const m2 = { ...obj1, ...obj2 };

Spread 연산자, Object.assign 메서드를 활용해 다중 객체를 병합할 수 있다. 다만 후자의 키가 덮어씌워지기 때문에 병합 순서에 유의해야 한다.

✅ 깊은 복사 (주의: JSON 기반 한계)

const deepCopied = JSON.parse(JSON.stringify(person));

JSON.parse, JSON.stringify를 활용하여 간단하게 깊은 복사를 할 수 있다. 다만 JSON.parse, JSON.stringify를 사용한 깊은 복사에는 여러가지 제약사항 및 한계가 존재한다.
- 무시/불가: undefined, Function, Symbol, BigInt(에러), Map/Set, Date/RegExp(손실), 순환 참조(에러).
- 대안: 직접 구현 또는 lodash.cloneDeep.

11) 객체 비교

객체는 참조형 타입으로 내부 속성의 값이 동일하더라도 참조값이 다를 경우 서로 다른 객체로 간주된다.

const person = new Person("a", 26);
const copy = { ...person };
console.log(person === copy); // false (참조 비교)

“값 동등” 검사(간단 용도)

JSON.stringify(person) === JSON.stringify(copy);

객체 내부 속성 값이 실제로 동일한지 비교할 때, JSON.stringify를 활용할 수 있다. 단, JSON.stringify는 함수, undefined, Symbol 등은 무시하고, 속성 순서가 다를 경우 다른 경우가 나올 수 있다.
- 함수/undefined/Symbol 무시, 키 순서 영향 가능.
- 정교한 비교는 lodash.isEqual 등 사용 권장.

📚 참고 자료

이벤트 루프 (Event Loop)

Tue, 12 Aug 2025 00:00:00 GMT

🧩 JavaScript의 비동기 처리 개요

자바스크립트는 싱글 스레드 언어이다.

즉 한 번에 하나의 작업만 수행할 수 있으며, 코드 실행을 담당하는 **호출 스택(Call Stack)**도 하나뿐이다.

싱글 스레드 구조는 복잡한 처리가 필요한 동시성 문제를 줄이는 장점이 있지만, 네트워크 요청·파일 읽기처럼 오래 걸리는 작업이 있을 때 전체 실행 흐름을 멈추는 **블로킹(blocking)**이 발생할 수 있다.

이를 보완하기 위해 비동기 처리와 이벤트 루프(Event Loop) 개념이 도입되었다.

❓ JavaScript는 왜 싱글 스레드로 설계되었을까?

자바스크립트가 처음 등장했을 때는 멀티 스레드에 대한 개념이 대중화된 시기가 아니었다. 또한 자바스크립트의 전신인 LiveScript는 브라우저에서 간단한 UI 조작을 위한 스크립트로 사용되었다.

따라서 복잡한 멀티 스레드 제어보다는 “Run-to-Completion” — 하나의 작업이 끝난 뒤 “동기적”으로 다음 작업을 실행하는 순차적 처리 방식 — 이 합리적인 선택이었다.

🔄 이벤트 루프란?

이벤트 루프는 ECMAScript 표준이 아닌, 브라우저/Node.js 런타임이 구현한 매커니즘이다.

자바스크립트 엔진은 동기 실행만 담당하고, 비동기 처리는 브라우저 Web API 또는 Node.js의 c++ 라이브러리인 libuv가 담당한다.

https://dev.to/gautam_kumar_d3daad738680/understanding-call-stack-callback-queue-event-loop-and-microtask-queue-in-javascript-2c7n

✅ 이벤트 루프의 핵심 역할

호출 스택을 감시
스택이 비어 있으면 **큐(Event Queue, Callback Queue)**에 있는 작업을 꺼내 실행

이처럼 이벤트 루프는 메인 스레드와 백그라운드 사이에서 신호등처럼 타이밍을 조율하는 역할을 한다.

📦 호출 스택과 이벤트 루프

호출 스택(Call Stack)은 자바스크립트에서 현재 실행 중이거나 대기 중인 함수를 LIFO(Last In First Out) 형태로 순차적으로 쌓아두는 스택이다.

다음과 같이 실행되는 코드가 있다고 가정했을 때 이 코드들은 어떤 순서로 호출 스택에 쌓이게 되는 걸까?

function a() {
	console.log("a");
}

function b() {
	console.log("b");
}

function ab() {
	console.log("ab");
	a();
	b();
}

ab();

call stack1.mp4

실행 흐름 요약
1. ab()가 호출 스택에 먼저 들어간다.
2. ab() 내부에 console.log가 존재하므로 호출 스택에 들어가 실행이 완료된 후 제거된다. (아직 ab()는 존재)
3. a()가 호출 스택에 들어간다.
4. a() 내부에 console.log가 존재하므로 호출 스택에 들어가 실행이 완료된 후 제거된다. (아직 ab(), a()는 존재)
5. a()에 더 이상 남은 것이 없으므로 호출 스택에서 제거된다. (아직 ab()는 존재)
6. b()가 호출 스택에 들어간다.
7. b() 내부에 console.log가 존재하므로 호출 스택에 들어가 실행이 완료된 후 제거된다. (아직 ab(), b()는 존재)
8. b()에 더 이상 남은 것이 없으므로 호출 스택에서 제거된다. (아직 ab()는 존재)
9. ab()에 더 이상 남은 것이 없으므로 호출 스택에서 제거된다.
10. 이제 호출 스택이 완전히 비워졌다.

이러한 일련의 과정을 거치며 처리해야 할 작업들이 순차적으로 쌓이고 제거되는 과정을 확인할 수 있다.

그렇다면 비동기 작업의 실행은 어떤 식으로 처리될까?

⏰ 비동기 작업과 이벤트 루프

function a() {
	console.log("a");
}

function b() {
	console.log("b");
}

function ab() {
	console.log("ab");
	setTimeout(a, 0); // setTimeout을 추가
	b();
}

ab();

비동기 작업인 setTimeout을 추가했을 때, 호출 스택 내부에서는 다음과 같은 일이 발생한다.

call stack 2.mp4

실행 흐름 요약
1. ab()가 호출 스택에 먼저 들어간다.
2. ab() 내부에 console.log가 존재하므로 호출 스택에 들어가 실행이 완료된 후 제거된다. (아직 ab()는 존재)
3. setTimeout(a, 0)이 호출 스택에 들어간다.
4. 런타임으로 타이머 요청이 전달되고, setTimeout은 스택에서 제거된다.
  1. 메인 스레드(자바스크립트 엔진)는 이 콜백을 delay후에 실행해줘라는 요청을 런타임 환경에 전달한다.
  2. 런타임 환경은 백그라운드 스레드에서 타이머를 관리한다.
  3. 지정한 시간이 지나면, 해당 콜백(a)을 태스크 큐에 등록한다.
  4. 이 과정은 메인 스레드와 병렬로 진행된다.
5. b()가 호출 스택에 들어간다.
6. b() 내부에 console.log가 존재하므로 호출 스택에 들어가 실행이 완료된 후 제거된다. (아직 ab(), b()는 존재)
7. b()에 더 이상 남은 것이 없으므로 호출 스택에서 제거된다. (아직 ab()는 존재)
8. ab()에 더 이상 남은 것이 없으므로 호출 스택에서 제거된다.
9. 이벤트 루프는 호출 스택이 비워져 있는 것을 확인하고, 태스크 큐에서 a()를 꺼내 호출 스택에 넣는다.
10. a() 내부에 console.log가 존재하므로 호출 스택에 들어가 실행이 완료된 후 제거된다.
11. a()에 더 이상 남은 것이 없으므로 호출 스택에서 제거된다.
💡 setTimeout의 실행 흐름

현재 실행 흐름을 보면 setTimeout(() => {}, delay)이 delay만큼 설정된 지연 시간 이후 바로 실행됨을 보장하지 않는다는 것을 알 수 있다.
- setTimeout과 같은 비동기 함수는 자바스크립트 엔진이 아닌 **런타임(브라우저의 Web API/Node.js의 libuv)**에서 처리된다.
- 런타임의 백그라운드 스레드가 타이머를 관리하고, 완료 시 해당 콜백을 **태스크 큐(Task Queue/Callback Queue)**에 등록한다.
- 이벤트 루프는 호출 스택이 완전히 비워진 뒤, 다음 이벤트 루프 사이클에서 큐에 있는 작업을 꺼내 실행한다.
  
  → 따라서 최소 지연 시간이 0ms여도, 메인 스레드가 바쁘거나 다른 작업이 대기 중이면 실행이 지연될 수 있다.

🧩 태스크 큐(Task/Callback Queue)

새롭게 등장한 개념인 태스크 큐는 실행해야 할 태스크를 보관하고 있는 공간이다. 이때 실행해야 할 태스크란 런타임(Web API, libuv)이 처리하는 비동기 함수의 콜백 함수나 이벤트 핸들러 등을 의미한다.

이벤트 루프는 호출 스택이 비어있음을 확인하면 가장 오래된 태스크부터 꺼내 호출 스택으로 순차적으로 보내어 실행한다.

✅ 주요 태스크

setTimeout, setInterval
브라우저 DOM 이벤트 콜백
postMessage, MessageChannel
Node.js: setImmediate (루프의 check phase)

이 과정에서 이벤트 루프는 호출 스택이 비고, 콜백이 실행 가능한 시점이 되면 해당 콜백을 호출 스택으로 전달하는 역할을 한다.

🧩 태스크 큐와 마이크로 태스크 큐

function a() {
	console.log("a");
}

function b() {
	console.log("b");
}

function c() {
	console.log("c");
}

function foo() {
	console.log("foo");
}

foo(); 

setTimeout(a, 0); // setTimeout - 태스크 큐

Promise.resolve().then(b).then(c); // 마이크로태스크 큐

다음과 같은 코드가 있다면 실행 순서는 어떻게 될까?

foo -> a -> b -> c 순으로 실행될 거라 예상했지만 Promise와 관련된 콜백이 먼저 실행됨을 알 수 있다.

이러한 순서로 실행된 이유는 Promise에 대한 콜백은 태크스 큐(콜백 큐)가 아닌 **마이크로 태스크 큐(Microtask queue)**에 등록되기 때문이다.

실행 흐름 요약
1. foo() 호출 스택에 먼저 들어간다.
2. foo() 내부에 console.log가 존재하므로 호출 스택에 들어가 실행이 완료된 후 제거된다. (아직 foo()는 존재)
3. foo()에 더 이상 남은 것이 없으므로 호출 스택에서 제거된다.
4. setTimeout(a, 0)이 호출 스택에 들어간다.
5. setTimeout은 Web API가 타이머 관리를 하므로 호출 스택에서 제거된다.
  1. Web API가 타이머 관리 → 만료 후에 태스크 큐에 a가 등록된다.
6. Promise.resolve()가 호출 스택에 들어간다
7. Promise는 Web API가 관리하므로 호출 스택에서 제거된다.
  1. Promise.resolve().then(b) 평가 → 마이크로태스크 큐에 b를 등록한다.
8. 호출 스택이 비었음을 이벤트 루프가 확인 후 마이크로태스크 큐부터 먼저 비우기 시작한다.
  1. b()를 실행한다 → console.log가 존재하므로 호출 스택에 들어가 b 출력 후 제거된다. → then(c)가 마이크로 테스크로 등록된다.
  2. c()를 실행한다. → console.log가 존재하므로 c를 출력 후 제거된다.
9. 호출 스택이 비었음을 이벤트 루프가 확인 후 태스크 큐에서 a를 가져와 실행한다. console.log가 존재하므로 호출 스택에 넣고 a 출력 후 제거된다.
10. a()에 더 이상 남은 것이 없으므로 호출 스택에서 제거된다.

💡마이크로 태스크 큐(Microtask Queue)

**마이크로 태스크 큐(Microtask Queue)**는 콜백 큐보다 더 높은 우선순위를 가지고 있는 큐다. 콜백 큐에 있는 어떤 태스크들보다도 우선적으로 실행된다. 즉 마이크로 태스크 큐가 빌 때까지 그 어떤 콜백 큐 내의 태스크들도 실행될 수 없다.

마이크로 태스크 큐에 등록되는 태스크들은 대표적으로 Promise 콜백과 Mutation Observer 콜백이 있다.

태스크 큐와 마이크로 태스크 큐 비교

구분	Task Queue	Microtask Queue
콜백	`setTimeout`, `setInterval`
브라우저 DOM 이벤트 콜백
`postMessage`, `MessageChannel`
Node.js: `setImmediate`	`Promise callbacks` (then, catch, finally)
`MutationObserver callbacks`
`queueMicrotask`
Node.js: `process.nextTick`
(* nextTick은 Node에서 마이크로태스크보다 더 먼저 실행되는 별도 큐이다.)
우선순위	낮음	높음
처리 시점	호출 스택, 마이크로 태스크를 모두 비운 뒤 처리

🎨 마이크로 태스크 큐와 렌더링

브라우저는 보통 마이크로태스크 처리 이후 렌더링(페인트)을 시도한다.
마이크로태스크를 과도하게 연쇄 등록하면 렌더링이 지연(Starvation) 될 수 있다.
프레임 단위 작업이 필요한 경우에는 requestAnimationFrame을 고려할 수 있다.

📚 참고자료

모던 자바스크립트 Deep Dive
Inpa Dev: 자바스크립트 이벤트 루프 동작 원리
Understanding Call Stack, Callback Queue, Event Loop, and Microtask Queue in JavaScript
loupe - 콜 스택, 이벤트 루프 시각화

🌐 브라우저란?

Mon, 11 Aug 2025 00:00:00 GMT

🌐 브라우저란?

브라우저(웹 브라우저)는 사용자가 웹에 접근하고 정보를 볼 수 있도록 하는 소프트웨어 애플리케이션이다. 웹 서버로부터 데이터를 받아 사용자가 상호작용할 수 있는 시각적 포맷으로 변환(렌더링, Rendering)하는 역할을 수행한다.

브라우저의 주요 구성 요소:

사용자 인터페이스 (UI) - 뒤로가기, 주소창 등
렌더링 엔진
네트워킹 모듈 (웹 서버와의 통신)
JavaScript 엔진
데이터 저장소 (쿠키, 로컬 스토리지 등)

이 글에서는 렌더링 엔진과, 브라우저가 리소스를 화면에 표시하기까지의 과정인 **Critical Rendering Path(CRP)**를 집중적으로 다뤄보고자 한다.

🚂 브라우저 렌더링 엔진

렌더링 엔진은 HTML, CSS, JavaScript 등 웹 리소스를 받아서 픽셀 단위의 UI로 변환하는 핵심 모듈이다.

브라우저	렌더링 엔진	특징
Chrome, Edge, Opera	Blink	WebKit 기반으로 V8 JS 엔진과 결합, 최신 표준 지원
Safari	WebKit	애플 생태계에 최적화된 iOS 필수 엔진
Firefox	Gecko	오픈 소스 기반, 표준 호환성 우수
구형 IE	Trident	현재는 사용 중단

렌더링 과정의 효율성은 브라우저 성능과 사용자 경험에 직접적으로 영향을 준다. 따라서 렌더링 과정을 이해하고 최적화 하는 과정은 굉장히 중요하다.

Critical Rendering Path

CRP는 브라우저가 HTML, CSS, JavaScript를 처리해 첫 픽셀을 화면에 그릴 때까지 거치는 일련의 과정이다.

CRP 절차:

서버에 리소스 요청 및 응답 수신
HTML 파싱 → DOM(Document Object Model) 생성
- 💡 DOM이란?
  
  HTML 문서의 계층적 구조와 정보를 트리 구조로 표현한 객체 모델이다. 각 노드에 접근, 수정 가능한 API를 제공한다.
- 💡 파싱 vs. 렌더링
  
  파싱(구문 분석 )은 프로그래밍 언어의 문법에 맞게 작성된 텍스트 문서를 읽어 들여 실행하기 위해 일련의 과정을 거쳐 적절하게 변환하는 과정을 의미한다.
  
  문자열 토큰(token)으로 분해 → 토큰에 문법적 의미와 구조를 반영하여 트리 구조의 자료구조인 파스 트리(parse tree/syntax tree) 생성
  
  일반적으로 파스 트리를 기반으로 중간 언어(intermediate code)인 바이트코드(bytecode)를 생성 및 실행한다.
  
  렌더링은 HTML, CSS, JavaScript로 작성된 문서를 파싱하여 브라우저에 시각적으로 출력하는 과정을 의미한다.
CSS 파싱 → CSSOM(CSS Object Model) 생성
DOM + CSSOM → Render Tree 생성
Layout(Reflow) : 렌더 트리의 각 요소 크기 및 위치 계산
- 💡 렌더 트리 (Render Tree)
  
  렌더 트리는 렌더링을 위한 트리 구조의 자료구조로 브라우저 화면에 렌더링하지 않는 노드 (e.g. meta 태그, script 태그 등)와 CSS에 의해 비표시되는 노드들은 포함하지 않는다.
Paint: 계산된 레이아웃을 픽셀 데이터로 변환
Composite: GPU가 레이어를 합성하여 화면에 출력

🔄 Reflow, Repaint

CRP 이후에도 브라우저는 UI 변화에 따라 렌더링 과정을 반복할 수 있다.

Reflow: DOM 요소의 레이아웃(크기/위치) 재계산
Repaint: 레이아웃 변화 없이 스타일(색상, 배경 등)만 다시 그리기

Reflow/Repaint가 발생할 수 있는 예시는 다음과 같다:

자바스크립트에 의한 노드 추가 또는 삭제
브라우저 창의 리사이징(Resizing)에 의한 뷰포트 크기 변경
HTML 요소의 레이아웃에 변경을 유발하는 width/height, margin, padding, border, display, position, top/right/bottom/left 등의 요소 크기 및 위치에 대한 스타일 변경

💡 리렌더링, 특히 Reflow 과정은 비용이 큰 연산이다. 빈번하게 발생하지 않도록 DOM 업데이트를 최소화하는 것이 중요하다.

🚀 렌더링 최적화 전략

렌더링 차단 리소스 줄이기
- CSS
  - <link rel="stylesheet">는 렌더링 차단 → DOM 생성 중단 후 CSSOM 생성 완료 시 재개
  - 핵심 CSS는 Critical CSS 인라인 삽입한다**.**
    - 첫 화면 렌더링에 필요한 최소한의 CSS를 <style> 태그로 HTML 상단에 삽입하여 필수적인 CSS만 빠르게 렌더링할 수 있도록 한다.
  - 나머지 CSS는 media 속성 또는 preload로 지연 로드를 통한 Render blocking 방지 및 최적화를 할 수 있다.
- JS
  - <script>는 기본적으로 HTML 파싱을 차단한다.
  - <body> 하단 배치로 파싱 블로킹을 최소화할 수 있다.
    - 💡 하단 배치를 통해 누릴 수 있는 이점?
      - DOM이 완성되지 않는 상태에서 자바스크립트가 DOM 조작 시 발생할 수 있는 에러 차단
      - 자바스크립트 로딩/파싱/실행으로 인한 HTML 파싱 지연 방지를 통한 페이지 로딩 시간 단축
  - HTML5에서 제공하는 async, defer 어트리뷰트 활용
    - async attribute
      
      HTML 파싱과 외부 자바스크립트 파일의 로드가 비동기적으로 동시에 진행되는 점은 defer 어트리뷰트와 동일하지만 자바스크립트의 파싱과 실행은 로드 완료된 직후 진행된다. 이때 HTML 파싱이 중단된다.
      
      여러 개의 script 태그에 async 어트리뷰트를 지정하면 script 태그의 순서와는 상관없이 로드 완료 순으로 실행되므로 순서 보장이 되지 않는다. 따라서 순서 보장이 필요한 경우 (e.g. script끼리 연관 관계가 존재하는 경우 등) async 어트리뷰트를 지정하지 않아야 한다.
    - defer attribute
      
      async 어트리뷰트와 마찬가지로 HTML 파싱과 외부 자바스크립트 파일의 로드가 비동기적으로 동시에 진행된다.
      
      단 자바스크립트 파싱과 실행은 HTML 파싱이 완료된 직후, 즉 DOM 생성이 완료된 직후(DOMContentLoaded 이벤트) 진행된다. 따라서 DOM 생성이 완료된 이후 DOM 조작 등을 실행해야 하는 자바스크립트 또는 서로 연관 관계가 존재하여 반드시 실행 순서를 지켜야 하는 경우 사용하면 유용하다.
  - ⚠️ 해당 어트리뷰트는 외부 자바스크립트 파일을 로드하는 경우에만 사용할 수 있다. 즉 src 어트리뷰트가 없는 인라인 자바스크립트에는 사용이 불가능 하다.
리소스 크기 최적화
- CSS/JS Minify & 압축을 통해 받아오는 리소스 크기를 최적화할 수 있다.
- 이미지 최적화(WebP, AVIF 등 압축 포맷 활용)와 지연 로딩을 통해 이미지 리소스 관련 최적화를 할 수 있다.

요청 수 줄이기

CSS/JS 병합
- 여러 개의 CSS 또는 JavaScript 파일을 하나로 합쳐 서버 요청 수를 줄이는 기법으로 HTTP/1.1 환경에서는 요청 개수가 많아지면 TCP 연결 지연 + 요청 대기 시간이 누적되는 현상을 완화하므로서 성능 개선 효과를 누릴 수 있다.
HTTP/2 & HTTP/3 활용

💡 HTTP/1.1 vs. HTTP/2 & HTTP/3

HTTP(HyperText Transfer Protocol)는 **웹에서 브라우저와 서버가 통신하기 위한 프로토콜(규약)**이다. HTTP 역시 시간이 지나면서 성능과 보안, 효율성을 개선하기 위해 버전이 업그레이드되었다.

HTTP/1.1의 가장 큰 특징은 커넥션당 하나의 요청과 응답만 처리한다는 점이다. 리소스의 동시 전송이 불가능하여 요청할 리소스의 개수에 비례하여 응답 시간이 증가한다는 단점이 있다. 특히 선두 요청이 지연되면 뒤의 요청이 대기해야 하는 Head-of-line Blocking(HOL Blocking) 문제로 인해 요청 수 최소화를 위한 CSS/JS 병합, 이미지 스프라이트 등의 우회 전략이 필요했다.

HTTP/2는 이같은 HTTP/1.1의 단점을 보완하기 위해 **멀티플렉싱(Multiplexing)**을 지원한다. 멀티플렉싱이란 하나의 TCP 연결에서 여러 요청/응답을 동시에 처리하는 것을 의미한다. HTTP/1.1과 완벽하게 호환되며, **헤더 압축(HPACK)**을 통해 전송 데이터 양을 절감할 수 있는 장점도 있다. 또한 브라우저 요청 없이도 서버가 필요한 리소스를 미리 전송하는 **서버 푸시(Server Push)**기능을 제공한다. ****

HTTP/3는 UDP 기반의 QUIC 프로토콜을 통해 빠르고 네트워크 간의 빠른 전환을 지원하도록 설계되었다. TCP 기반이 아니기 때문에 HOL 블로킹 문제를 근본적으로 완화하고 연결 설정 지연(RTT)을 최소화하여 모바일이나 불안정한 네트워크 환경에서 유리하다. 또한 QUIC은 TLS(전송 계층 보안)를 기본적으로 내장하고 있어 보안성 측면에서도 강화되었다는 장점이 있다.

구분	HTTP/1.1	HTTP/2	HTTP/3
연결 방식	요청마다 TCP 연결 (혹은 파이프라이닝)	단일 TCP 연결에서 멀티플렉싱 (Multiplexing)	QUIC(UDP 기반) 연결
요청 처리	순차 처리 (Head-of-line Blocking)	병렬 처리 가능	TCP HOL 문제 해결, 연결 설정
속도 빠름
헤더 압축	없음	HPACK	QPACK
속도	많은 요청 시 성능 저하	다수의 작은 요청 처리에 유리	네트워크 품질 불안정 시에도 속도 안정적
HTTPS	선택	권장 (사실상 필수)	필수

Above-the-fold 콘텐츠 우선 로딩
- ❓ Above-the-fold?
  
  스크롤 없이 첫 화면에 보이는 영역을 의미한다. 사용자가 페이지를 열었을 때 가장 먼저 보이는 콘텐츠를 빠르게 로딩하여 사용자가 페이지 로딩이 빠르다라고 인식하게 할 수 있다.
- 폰트: font-display: swap;으로 FOUT 허용
  - FOUT(Flash of Unstyled Text)는 웹 폰트 로드 전 브라우저가 기본 폰트로 텍스트를 먼저 렌더링했다가 나중에 웹 폰트 로드 시 교체되는 현상을 의미한다. 초기 지연 문제는 없지만 웹 폰트로 교체 과정에서 텍스트 깜빡임 및 레이아웃 흔들림이 발생할 수 있다.
  - FOIT(Flash of Invisible Text)는 폰트가 로드될 때까지 텍스트를 숨겼다가, 로드 완료 후 한 번에 표시하는 현상을 의미한다. 웹 폰트 교체로 인한 깜빡임은 없지만 초기 표시 자체가 지연되는 문제가 있다.
  - 폰트 최적화 전략
    - font-display 속성을 활용한 폰트 최적화 → font-display: swap 속성을 통해 초기 렌더링 속도 및 접근성을 향상할 수 있다.
    - <link rel="preload" as="font">로 폰트를 사전에 로드한다.
    - 시스템 폰트 fallback 설계하여 레이아웃 변화를 최소화한다.
- 첫 화면 콘텐츠를 빠르게 표시하여 LCP(Largest Contentful Paint) 개선

📚 참고자료

자바스크립트의 데이터 타입

Thu, 17 Jul 2025 00:00:00 GMT

자바스크립트의 데이터 타입

자바스크립트의 데이터 타입은 크게 두 가지로 나눌 수 있다. 기본형과 참조형이다.

자바스크립트 데이터 타입의 종류

기본형과 참조형의 차이점은 기본형은 할당이나 연산 시 값이 담긴 주솟값을 바로 복제하는 반면 참조형은 값이 담긴 주솟값들로 이루어진 묶음을 가르키는 주솟값을 복제한다는 점이다. 이러한 점에서 기본형은 불변성을 띈다.

메모리 구조와 불변성

// 변수 a를 선언하고 'abc'라는 문자열을 할당
var a = 'abc';
// 기본형 값의 변경
a = a + 'def';

위 코드가 실행되었을 때 자바스크립트의 메모리는 다음과 같은 방식으로 작동한다.

먼저 변수 a를 선언하고 문자열 ‘abc’를 할당하면, 자바스크립트 엔진은 ‘abc’라는 문자열 값을 저장하기 위한 별도의 메모리 공간을 확보한 뒤, 이 공간의 주소값을 변수 a가 가르키도록 만든다. 즉, 변수는 문자열 자체를 저장하는 것이 아닌, 해당 문자열이 존재하는 메모리 공간을 참조(포인트)하게 된다.

이처럼 변수는 값을 직접 담기보다는 값을 저장한 메모리 위치를 가르키는 식별자로 동작한다.

그렇다면 이후 a = a + 'def'와 같이 문자열을 변경하려고 하면 어떻게 될까?

표현상으로는 기존 문자열 데이터 'abc'에 'def'가 “덧붙여져서” 변경된 것처럼 보이지만, 자바스크립트에서 문자열은 불변(immutable) 하기 때문에 기존 문자열을 수정하는 것이 아니라, 새로운 문자열 'abcdef'를 생성하고 이를 위한 메모리 공간을 다시 확보한다. 그리고 변수 a는 이제 새롭게 생성된 문자열을 가르키게 된다. 기존의 'abc'가 다른 곳에서 참조되지 않는다면 (참조 카운트가 0인 메모리 주소라면) 가비지 컬렉터의 수거 대상이 될 수 있다.

즉, 변경처럼 보이는 이 동작은 실제로는 새로운 값을 생성해서 변수에 재할당하는 방식으로 이루어진다. 이런 특성 때문에 문자열(String)을 포함한 자바스크립트의 기본형 타입은 불변값이라고 할 수 있다.

💡 문자열은 문자 단위 변경도 불가능!

let s = 'abc';
console.log(s[0]) // a
s[0] = 'z';
console.log(s); // 'abc' => 문자열 내부 요소에 대한 직접 변경을 허용하지 않음

참조형 데이터의 가변성

참조형 데이터가 **가변(mutable)**하다고 하는 이유는 값 자체가 아니라 값을 가르키는 “참조”를 통해 조작되기 때문이다.

var obj1 = {
	a : 1,
	b : 'bbb'
}

var obj2 = obj1;

obj2.a = 2;

console.log(obj1.a); // 2
console.log(obj2.a); // 2

위 예제에서 obj1과 obj2는 동일한 객체를 참조하고 있다. 따라서 obj2.a = 2와 같이 obj2를 통해 객체의 프로퍼티를 변경하면, obj1을 통해 접근해도 변경된 값이 그대로 나타난다. 이는 두 변수가 같은객체를공유하고 있기 때문에, 하나의 변경이 곧 전체 객체에 영향을 주는 것이다.

즉 참조형 데이터는 객체의 구조나 내용을 자유롭게 수정할 수 있으므로 가변성을 가진다라고 볼 수 있다.

var obj1 = {c : 10, d : 'ddd'}
var obj2 = obj1;

obj2 = {c : 20, d : 'ddd'}

console.log(obj1.c);
console.log(obj2.c);

이번 예제에서는 obj2에 새로운 객체를 할당함으로써 참조 대상 자체를 변경했다. 그러면 obj2는 더 이상 obj1과 같은 객체를 참조하지 않고, 완전히 새로운 객체를 가르키게 된다. 따라서 obj2.c의 값을 변경해도 obj1에는 아무런 영향을 주지 않는다.

이처럼, 참조형 데이터가 가변적이라는 말은 참조된 객체의 내부 상태를 수정할 수 있다는 의미이지 참조 자체를 바꾸면 원본도 바뀐다는 의미는 아니다. 즉 가변성이란 참조형 데이터의 내부 프로퍼티를 변경할 수 있다는 특성을 의미한다.

불변 객체 (Immutable Object)

불변 객체는 최근의 React, Vue.js, Angular 등의 라이브러리나 프레임워크, 함수형 프로그래밍, 디자인 패턴 등에서 매우 중요한 기초가 되는 개념이다. 객체의 불변성이 필요한 이유는 주로 예측 가능성, 디버깅 용이성, 성능 최적화, 사이드 이펙트 방지 등과 관련이 있다.

상태 변경 추적 및 예측 가능성 향상

객체가 불변이라면 객체가 변경되었을 때 이전 상태와 이후 상태가 명확하게 구분된다.

const oldObject = {a : 1, b : 2}
const newObject = {...oldObject, b : 3}

예제에서는 oldObject를 직접 수정하지 않고, 변경된 값을 반영한 새로운 객체를 newObject에 생성했다. 이런 방식은 디버깅, 타임 트래블 디버깅, Undo/Redo 기능 구현에 매우 유리하다.

사이드 이펙트(side effects) 방지

같은 객체를 여러 곳에서 참조하고 있을 때, 어느 한 곳에서 누군가가 그 객체를 변경하면 예상치 못한 버그가 발생할 수 있다.

const user = { name : 'user 1', age : 20 }

function updateName(user) {
	user.name = 'Changed user name'; // 원본 user까지 바뀜
}

function updateNameImmutably(user) {
	return {...user, name : 'Changed user name'} // 원본은 그대로 유지한 채 새로운 객체 반환
}

불변 객체는 원본을 건드리지 않고 새로운 객체를 생성하므로써 사이드 이펙트 없이 안정적으로 동작한다.

React, Redux 등 상태 관리 라이브러리에서는 필수 개념

React는 state가 변경되어야만 컴포넌트를 리렌더링한다. 이때 객체를 불변으로 다뤄야 **이전 상태와의 얕은 비교(shallow compare)**가 가능하다.

Redux 또한 store의 상태를 직접 변경하지 않고, 항상 새 상태를 반환해야 하므로 불변성 유지가 핵심이다.

성능 최적화

불변 객체는 참조 값만 비교해도 같고 다름을 판단할 수 있다. 이를 통해 깊은 비교(deep compare) 대신 **얕은 비교(shallow compare)**만으로도 성능 최적화를 이룰 수 있다.

if (prevState == nextState) {
	// 상태가 변경되지 않았으므로 리렌더링 생략 가능
}

얕은 복사와 깊은 복사

불변성을 유지하기 위해 기존 객체의 값을 복사하는 방법에는 **얕은 복사(shallow copy)**와 **깊은 복사(deep copy)**가 있다.

얕은 복사는 바로 아래 단계의 값만 복사하는 방법이고, 깊은 복사는 내부의 모든 값들을 하나하나 재귀적으로 순회하며 전부 복사하는 방법이다.

얕은 복사 (Shallow Copy)

// 얕은 복사
const shallowObj1 = {
	a : 1,
	b : 2,
	c : 3
}

const shallowObj2 = {
	name : "user1",
	urls : {
		portfolio: "http://github.com/user1",
		facebook: "http://facebook.com/user1"
	}
}

const copyObj1 = {...shallowObj1}
const copyObj2 = {...shallowObj2}

copyObj1.a = 4

console.log(shallowObj1.a === copyObj1.a) // false

copyObj2.name = "changed user"

console.log(shallowObj2.name === copyObj2.name) // false

copyObj2.urls.portfolio = "https://notion.com/user1"

console.log(shallowObj2.urls.portfolio === copyObj2.urls.portfolio) // true

위 예제에서 사용된 Spread 연산자는 ES6부터 도입된 문법으로, 배열이나 객체의 전체 또는 일부를 다른 배열이나 객체로 빠르게 복사할 수 있게 해준다.

하지만 이때 주의할 점은 Spread 연산자를 활용한 복사는 앝은 복사라는 점이다.

위 예제에서 shallowObj1과 shallowObj2를 각각 copyObj1과 copyObj2라는 객체에 복사했다.

copyObj1.a와 copyObj2.name은 기본형 데이터를 가진 프로퍼티이므로, 복사 후 값을 변경해도 원복 객체에 영향을 주지 않는다.
그러나 copyObj2.urls 참조형 데이터를 ****가진 프로퍼티이다. 얕은 복사 시 이 객체의 참조만 복사되므로, 복사한 객체에서 내부 값을 변경하면 원본 객체에도 영향을 준다.

따라서 참조형 데이터를 포함한 객체의 불변성을 유지하기 위해서는 반드시 깊은 복사를 통해 하위의 중첩 객체들에 대해서도 재귀적인 복사를 진행하여 원본과 완전히 분리해야만 불변성을 유지할 수 있다.

💡 대표적인 얕은 복사 방법

Spread 연산자 외에도 자바스크립트에서 얕은 복사를 수행할 수 있는 방법은 여러 가지가 있다. 대표적으로 아래 두 가지 방법이 자주 사용된다:

Array.prototype.slice()

배열을 얕은 복사하려면 slice 메서드를 활용할 수 있다. 이 메서드는 start부터 end까지의 요소를 기존 배열에서 추출하여 새로운 배열을 반환한다.
Array.prototype.slice() 활용 예시

const users = [
	{name : 'user1', age : 20},
	{name : 'user2', age : 21},
	{name : 'user3', age : 22},
	{name : 'user4', age : 23},
	{name : 'user5', age : 24},
]
const copyUsers = users.slice()

copyUsers[0].name = 'changed user1'

console.log(JSON.stringify(users) === JSON.stringify(copyUsers)); // true
console.log(users[0].name === copyUsers[0].name) // true

// 내부 객체가 공유되므로, 원본 배열 요소도 변경됨

⚠️ 배열 자체는 새로 복사되지만, 내부 객체는 같은 주소를 참조하므로 변경 시 원본도 영향을 받는다.

Object.assign(target, source)

Object.assign()은 하나 이상의 소스 객체로부터 속성을 복사하여 target 객체에 할당하는 메서드이다. 이때도 내부 객체까지는 복사되지 않기 때문에 얕은 복사만 수행된다.
Object.assign() 활용 예시

const object = {
	a : 1,
	b : [1, 2, 3]
}

const copyObj = Object.assign({}, object);

console.log(object.b === copyObj.b); // true

copyObj.b[0] = 0

console.log(object.b === copyObj.b); // true
console.log(object.b[0] === copyObj.b[0]); // true

// 이때도 마찬가지로 object 내부에 있던 참조형 데이터를 가진 b를 변경했을 때
// 원본 객체 역시 함께 변경되고 있음을 알 수 있다.

깊은 복사 (Deep Copy)

const copyObjectDeep = function (target) {
	let result = {}
	if (typeof target === 'object' && target !== null) {
		for (let prop in target) {
			result[prop] = copyObjectDeep(target[prop]); // 재귀적으로 복사를 수행
		}
	} else {
		result = target;
	}
	return result;
}

위 예제는 범용적으로 객체의 깊은 복사를 수행할 수 있는 재귀 함수이다.

만약 target이 객체인 경우에는 내부 프로퍼티들을 순회하며 copyObjectDeep() 함수를 재귀적으로 호출하고, 객체가 아닌 경우에는 원시 값을 그대로 반환한다.

이를 통해 원본과 복사본이 서로 다른 참조를 가지게 되어, 어느 한 쪽의 (참조형 데이터를 가진) 프로퍼티를 변경해도 다른 쪽에 전혀 영향을 주지 않게 된다.

💡 깊은 복사를 수행하는 주요 방법

자바스크립트에서는 위의 copyObjectDeep처럼 별도로 깊은 복사를 구현하지 않고도 깊은 복사를 할 수 있는 방법을 제공하고 있다:

JSON.stringify() + JSON.parse()

가장 간단한 방법은 객체를 JSON 문자열로 변환한 뒤 다시 객체로 파싱하여 깊은 복사를 수행하는 방식이다.
JSON.stringify → JSON.parse 예시

const object = {
	a : 1,
	b : [1, 2, 3]
}

const copyObject = JSON.parse(JSON.stringify(object))

copyObject.b[0] = 0

console.log(object.b === copyObject.b) // false
console.log(object.b[0] === copyObject.b[0]) // false

// 복사한 copyObject에서 참조형 데이터를 변경했음에로
// 원본 객체에는 영향이 가지 않는 것을 확인할 수 있다

⚠️ 다만 JSON.stringify를 활용한 깊은 복사 방식에는 몇 가지 한계가 존재한다.
- JSON 문자열로 변환이 불가능한 메서드(함수)나 숨겨진 프로퍼티인 proto, getter/seter, Date, RegExp, Map, Set과 같이 변환할 수 없는 객체 등의 속성은 모두 무시하거나 제거된 채 변환하는 제약사항이 있다.
- 순환 참조가 있는 객체는 오류가 발생할 수 있다.
- 이러한 깊은 복사 방식은 httpRequest로 받은 데이터를 저장한 객체를 복사하는 등 순수한 정보만 다룰 때 활용하기 좋은 방법이다.

structuredClone()
1. structuredClone 메서드는 자바스크립트에서 structured clone 알고리즘을 사용하여 주어진 값의 깊은 복사를 생성하는 전역 함수이다. ES2021 이후부터 사용할 수 있는 공식적인 깊은 복사 전역 함수이다. 이 메서드는 새로운 객체로 복사하는 대신 원래 값에서 전송 가능한 객체를 전송할 수도 있다.
2. structuredClone 예시
```
const object = {
	a : 1,
	b : [1, 2, 3]	
}

const copyObject = structuredClone(object)

copyObject.b[0] = 0

console.log(object.b === copyObject.b) // false
console.log(object.b[0] === copyObject.b[0]) // false
```

⚠️ JSON.stringify와 마찬가지로 몇 가지 제약사항이 존재한다.
- 함수 속성은 복사되지 않고 undefined로 처리된다.
- 객체의 프로토타입 체인을 유지하지 않는다.
- 다만 JSON을 활용한 깊은 복사 방법과는 달리 Date, RegExp 등 다양한 타입을 지원한다는 차이점이 있으며 성능적으로 JSON 문자열을 활용하는 방법보다는 빠르다는 장점이 있다. 또한 순환 참조를 지원한다.
- 최신 브라우저 또는 Node.js 환경에서 안전하고 빠른 깊은 복사를 할 때 활용하기 좋은 방법이다.

Lodash 라이브러리의 cloneDeep()
1. Lodash 라이브러리를 활용한다면 cloneDeep() 메서드를 통해 깊은 복사를 진행할 수 있다. Lodash 외에도 Immer, immutable.js 등 다양한 라이브러리들에서 깊은 복사를 위한 방법을 제공하고 있다.
2. Lodash의 cloneDeep()을 활용한 예제
```
import cloneDeep from 'lodash/cloneDeep'

const object = {
	a : 1,
	b : [1, 2, 3],
	f : { g : { h : 100 } } 
}

const copyObject = cloneDeep(object);

copyObject.f.g.h = 999;

console.log(object.f.g.h) // 100
```
- 이러한 라이브러리들은 앞서 언급한 방식에서 제한적이었던 프로토타입 체인 유지, 순환 참조와 다양한 타입 지원 등 폭넓은 깊은 복사 방식을 지원한다.
- 다만 외부 라이브러리에 의존해야 한다는 단점이 존재한다. 또한 번들 크기에 영향을 줄 수 있다.
- 복잡한 구조의 데이터에 대한 깊은 복사가 필요한 경우 안정적으로 사용할 수 있다.

📚 참고 자료

코드 자바스크립트

실행 컨텍스트 (Execution Context)

Sat, 14 Jun 2025 00:00:00 GMT

실행 컨텍스트 (Execution Context)

실행 컨텍스트란 자바스크립트 코드가 실행될 때 **식별자(변수, 함수 등)**를 어떻게 찾아서 동작할지를 결정하는 환경(Context)
자바스크립트가 코드를 어떻게 실행할지 결정하는 공간이며 그 안에 어떤 변수가 어디에 있는지, 어떤 함수를 실행해야 하는지를 담고 있는 실행 정보 저장소

실행 컨텍스트의 3가지 구성 요소

구성 요소	설명
Variable Environment (변수 환경)	변수 선언 정보 저장 (var, 함수 선언 등)
Lexical Environment (렉시컬 환경)	let, const 정보 및 스코프 체인 연결
This Binding	현재 컨텍스트의 this가 무엇인지 가리킴

실행 컨텍스트의 생성과 실행 단계

자바스크립트 엔진은 코드를 실행할 때 두 단계로 나눠서 처리

생성 단계 (Creation Phase)
1. 실행 컨텍스트가 생성
2. 호이스팅 (변수, 함수 선언이 메모리에 등록)
3. 스코프 체인 및 this 결정
실행 단계 (Execution Phase)
1. 코드가 한 줄 씩 실행
2. 변수 할당, 함수 호출 등의 로직이 실제 작동

실행 컨텍스트 스택 (콜 스택)

자바크스립트는 싱글 스레드 기반 언어
한 번에 하나의 컨텍스트만 실행
이 컨텍스트들은 Stack(스택) 구조로 관리하며 이를 **콜 스텍(Call Stack)**이라고 함

function first() {
	second();
	console.log("first");
}

function second() {
	console.log("second");
}

first();

실행 컨텍스트의 흐름
- global() → 가장 먼저 실행
- first() 실행 → 컨텍스트 push
- second() 실행 → 컨텍스트 push
- second() 끝 → 컨텍스트 pop
- first() 끝 → 컨텍스트 pop
- global() 종료

호이스팅(Hoisiting)이란?

호이스팅이란 자바스크립트의 변수와 함수 선언이 해당 범위의 최상단으로 끌어올려지는 것처럼 동작하는 현상
변수와 함수가 코드에 작성된 위치와 관계없이 먼저 메모리에 등록되어 참조 가능하게 되는 것을 의미

변수 선언의 호이스팅

console.log(x); // undefined
var x = 10;

해당 코드는 호이스팅을 통해 다음과 같이 해석

var x; // 선언만 호이스팅 됨
console.log(x); // undefined
x = 10; // 초기화는 호이스팅되지 않음

함수 선언의 호이스팅

sayHi(); // TypeError: sayHi is not a function

var sayHi = function() {
	console.log("Say, Hi!");
}

해당 코드는 호이스팅을 통해 다음과 같이 해석

var sayHi; // 선언 호이스팅
sayHi(); // sayHi는 아직 함수가 아님 -> 에러 발생
sayHi = function() {
	console.log("Say, Hi!");
}

var vs. let/const의 호이스팅 차이

구분	var	let/const
선언	호이스팅됨	호이스팅됨
초기화 시점	undefined로 초기화	초기화 전까지 접근 불가 (TDZ 발생)
사용 가능 시점	선언 이전에도 가능하지만 undefined	선언 이전에 Reference Error

❓ TDZ (Temporal Dead Zone)란?

let이나 const로 선언된 변수는 호이스팅되지만
선언 이전에는 접근이 불가능한 일시적 사각지대(Temporal Dead Zone)에 존재함

console.log(x); // Reference Error
let x = 10;

함수 선언 vs. 표현식 vs. 화살표 함수

종류	호이스팅 여부	정의 전 호출 가능 여부
함수 선언식 (`function`)	전체 호이스팅	가능
함수 표현식 (`var f = function`)	선언만 호이스팅	불가능
화살표 함수 (`const f = () => {}`)	선언만 호이스팅	불가능

스코프 체인 (Scope Chain)

스코프 체인은 자바스크립트에서 식별자를 찾을 때 현재 스코프뿐만 아니라 외부(상위) 스코프까지 순차적으로 탐색하는 구조를 의미
즉 어떤 변수를 사용할 때, 현재 스코프에서 찾고 → 없으면 상위 스코프로 올라가서 → 전역까지 찾는 연결된 검색 과정

스코프의 종류

스코프 종류	설명
전역 스코프	코드 어디서든 접근 가능
함수 스코프	함수 내부에서만 접근 가능
블록 스코프	{} 내부 (ES6 이후 let, const만)

const a = 1;

function outer() {
	const b = 2;
	function inner() {
		const c = 3;
		console.log(a, b, c);
	}
	
	inner();
}

outer(); // 1, 2, 3

a는 전역에서, b는 outer에서, c는 inner에서 찾는 이 참조 경로가 스코프 체인

실행 컨텍스트와의 관계

실행 컨텍스트는 Lexical Environment 정보를 갖고 있고 이 내부에는,
- Environment Record: 현재 스코프의 변수/함수 정보
- Outer Environment Reference: 상위 스코프에 대한 참조
를 가지고 있으며 이 Outer Reference를 따라 올라가는 구조가 스코프 체인

스코프 체인 탐색 시 주의 사항

하위 → 상위 방향으로만 탐색
- 상위 스코프에서 하위 스코프는 알 수 없음
변수가 shadowing되면 가장 가까운 것을 사용

const a = 1;

function test() {
	const a = 2;
	console.log(a); // 2가 가까우므로 2
}

클로저에서 활용됨
- 함수가 종료되어도 상위 스코프 참조가 유지 → 클로저 생성

Tessa's Dev Blog

🐛 Nuxt SSR 환경에서 `useState`에 함수 저장 시 발생한 Serialization 오류

🐛 Nuxt SSR 환경에서 useState에 함수 저장 시 발생한 Serialization 오류

목차

TL;DR

📌 개요

🔥 증상

🔍 원인 분석

🧪 1차 시도 — 인터페이스/옵션 확인

🧪 2차 시도 — API 동작 순차 배제

🧪 3차 시도 — SSR 코드 / useState 분석 → 🎯 원인 발견

🌱 문제 발생의 배경

💭 회고 및 대안 고찰

A. useState 대신 ref(모듈 스코프)로 관리

B. Event Bus (mitt 등) 도입

C. Pinia Store + Action 직접 호출

D. provide / inject (컴포넌트 트리 의존성 주입)

📊 비교 정리

🧠 배운 점

📚 참고 자료

AWS 시험 회고

AWS 시험 회고 ☁️

목차

약 1달 만에 쓰는 시험 후기

시험 준비 방법 📚

1~2주차 — 강의 듣기

3주차 — Dump + 강의 노트 정리

4주차 — 키워드 위주 개념 정리 & 백서(White Paper) 읽기

시험 응시 🖥️

시험 결과 🏆

시험을 마치며 💬

aspect-ratio Troubleshooting on Safari

aspect-ratio Troubleshooting on Safari

배경

컴포넌트 구조

문제가 된 코드

엔진 처리 흐름 비교

원인 분석

1. aspect-ratio는 weak declaration이다

2. 3단 중첩 flex의 align-items: stretch 전파

3. Safari vs Chrome의 해석 차이

4. Safari + lazy loading → layout fluctuation

해결 방법

핵심 원칙

수정된 코드

aspectRatio prop이 반드시 필요한 경우

수정 전/후 비교

타 라이브러리의 설계 판단

Chakra UI v3 <Image>

Next.js <Image>

세 접근 비교

부록: flex align-items: stretch 기본값 이해하기

1단계: stretch (기본값) — 버그 발생

2단계: flex-start 적용 — stretch 해제

3단계: position: absolute 분리 — Chakra UI 방식

align-items: stretch가 중첩 flex에서 전파되는 과정

관련 자료

WebView Bridge 통신 Part 1

WebView Bridge 통신 — Part 1: 개요 및 이론

목차

1. WebView란 무엇인가

플랫폼별 WebView 구현체

하이브리드 앱 아키텍처

2. 왜 웹과 앱 간 통신이 필요한가

통신이 필요한 대표적인 시나리오

웹 → 네이티브 방향 (명령)

네이티브 → 웹 방향 (데이터 전달)

3. WebView 통신 프로토콜

3.1 iOS: WKWebView

웹 → 네이티브 (JavaScript → Swift)

네이티브 → 웹 (Swift → JavaScript)

3.2 Android: JavascriptInterface

웹 → 네이티브 (JavaScript → Kotlin)

네이티브 → 웹 (Kotlin → JavaScript)

3.3 React Native: WebView

웹 → 네이티브

네이티브 → 웹

플랫폼별 통신 방식 비교

4. 자주 쓰이는 Bridge 통신 패턴

4.1 단방향 Fire-and-Forget

🐛 Nuxt SSR 환경에서 `useState`에 함수 저장 시 발생한 Serialization 오류

🧪 3차 시도 — SSR 코드 / `useState` 분석 → 🎯 원인 발견

A. `useState` 대신 `ref`(모듈 스코프)로 관리

D. `provide` / `inject` (컴포넌트 트리 의존성 주입)

1. `aspect-ratio`는 weak declaration이다

2. 3단 중첩 flex의 `align-items: stretch` 전파

Chakra UI v3 `<Image>`

Next.js `<Image>`

부록: flex `align-items: stretch` 기본값 이해하기