DynamoDB는 어떤 규모에서도 10밀리포(ms) 미만의 응답 속도를 제공하는 완전 관리형 NoSQL 키-값(Key-Value) 데이터베이스이다.

1. DynamoDB의 특징

1.1. 스키마리스 (Schemaless)

• 테이블 생성 시 데이터의 모든 열을 정의할 필요가 없다.
• 오직 기본 키(Partition Key & Sort Key)만 정의하면 되며 각 데이터(Item)마다 서로 다른 속성을 가질 수 있어 유연하다

1.2. 무한한 확장성

• 데이터 용량이 GB에서 TB로 늘어나도 성능 저하 없이 자동으로 저장 공간과 처리량을 분산한다.

1.3. 완전 관리형 (Serverless)

• 서버를 생성하거나 패치할 필요가 없다.
• 설치, 복제, 백업 설정 등 인프라적인 고민을 AWS가 모두 대신 처리한다.

---

2. 서버리스 아키텍처에서 DynamoDB를 선호하는 이유

백엔드 개발자가 Lambda와 같은 서버리스 기술을 사용할 때 DynamoDB를 1순위로 고려하는 이유는 다음과 같다.

2.1. 연결 방식의 차이 (HTTP vs TCP)

• RDS: 전통적인 TCP 연결 방식을 사용한다. 서버리스(Lambda)는 요청이 올 때마다 수많은 인스턴스가 생성되는데 이때마다 DB 연결(Connection)을 맺고 끊는 비용이 크고 연결 수 제한이 쉽게 걸린다.
• DynamoDB: HTTP 기반의 API 호출 방식을 사용한다. 연결 상태를 유지할 필요가 없어 Lambda의 폭발적인 확장(Scaling)에 완벽하게 대응한다.

2.2. 가동 속도와 확장 속도

• Lambda는 0.1초만에 수천 개가 뜰 수 있다. DynamoDB 역시 이러한 트래픽 급증을 즉각적으로 처리할 수 있도록 설계되어 있어 ‘Cold Start’나 ‘Connection Pool’ 이슈에서 자유롭다.

2.3. 비용 최적화 (On-Demand)

• 서버를 24시간 켜놓는 비용을 지불하는 대신, 실제 읽고 쓴 만큼만 비용을 지불하는 ‘온디맨드’ 모드를 제공한다.
• 트래픽이 없는 새벽 시간에는 비용이 거의 발생하지 않는다.

---

3. 백엔드 개발자가 알아야 할 데이터 모니터링

나같은 MySQL에 익숙한 개발자가 가장 어려워하는 부분이다. DynamoDB는 쿼리 방식이 제한적이다.

• Partition Key (PK): 데이터를 분산 저장하는 기준이다 (예: user_id)
• Sort Key (SK): 같은 PK 내에서 데이터를 정렬하고 범위를 검색하는 기준이다 (예: created_at)
• GSI(Global Secondary Index): 기본 키 외의 속성으로 검색이 필요할 때 만드는 인덱스이다 (예: 유저 아이디 대신 이메일로 검색하고 싶을 때 사용한다)

---

4. MySQL vs DynamoDB: 언제 무엇을 사용할까

비교 항목	MySQL (RDS)	DynamoDB
데이터 구조	엄격한 스키마, 복잡한 Join 가능	유연한 구조, Join 불가능 (코드에서 처리)
트랜잭션	매우 강력함 (ACID)	지원하지만 MySQL만큼 유연하진 않음
확장 방식	수직 확장 (서버 사양 업그레이드)	수평 확장 (자동 분산 보관)
적합한 사례	정교한 통계, 복잡한 관계의 데이터	대규모 로그, 단순 정보 조회, 빠른 알림/채팅

---

5. 실무 적용 팁

1. TTL (Time To Live): 특정 시간이 지나면 데이터를 자동으로 삭제해주는 기능이다. 세션 관리나 일정 시간이 지나면 사라지는 알림을 구현할 때 매우 유용하며 비용도 절감된다.
2. DynamoDB Streams: 데이터가 추가/수정/삭제될 대 이를 감지하여 Lambda를 실행할 수 있다 (예: 사용자가 가입하면 환영 메일 발송)
3. DAX (DynamoDB Accelerator): 응답 속도를 마이크로초 단위로 줄여야 하는 경우 사용하는 인메모리 캐시이다.