<aside> 🔵
AWS SAA 학습 시리즈 · 6/10 · 약 5분 · AWS SAA 학습 기록: 서비스 선택 기준을 연결하다
</aside>
2025.09~10 학습 기록을 다시 읽으며, 이 주제는 용어를 많이 아는 것보다 요구 사항을 먼저 읽는 습관과 연결된다고 느꼈다. 같은 기능처럼 보이는 서비스도 데이터의 형태, 장애 허용 범위, 운영 책임에 따라 답이 달라진다. 이 글은 특정 구성의 정답을 단정하기보다 선택의 출발점을 정리한다.
데이터베이스 선택은 관계형인지 비관계형인지라는 출발점에서 끝나지 않는다. 조인과 익숙한 SQL 엔진, 관리형 관계형 운영이 필요하면 Amazon RDS를 본다. Aurora는 RDS 안에서 사용할 수 있는 관계형 엔진 선택지로, 호환성과 성능·가용성 요구를 함께 검토한다. DynamoDB는 키-값과 문서 데이터 모델을 쓰는 완전관리형 NoSQL 데이터베이스로, 예측 가능한 액세스 패턴을 중심으로 설계한다.
트랜잭션·관계·복잡한 질의가 중심이면 관계형 모델이 자연스러운지 확인한다. 매우 큰 규모에서 낮은 지연 시간과 운영 부담 감소가 중요하고 파티션 키 중심으로 접근을 설계할 수 있다면 DynamoDB가 후보가 된다. 엔진 이름보다 데이터 모델, 읽기·쓰기 패턴, 일관성 요구, 운영 책임을 순서대로 비교하는 습관이 중요하다.
| 질문 | 판단할 신호 |
|---|---|
| 가용성 | 장애가 나도 서비스가 계속되어야 하는 범위 |
| 운영 부담 | 직접 관리할 구성과 자동화할 구성의 경계 |
| 보안 | 접근 주체, 네트워크 경계, 권한 최소화 |
서비스 이름만 보고 선택하면 비슷한 기능이 모두 정답처럼 보인다. 하지만 ‘반드시 여러 위치에 분산해야 하는가’, ‘중단을 받아들일 수 있는가’, ‘공유 파일 경로가 필요한가’처럼 문장에 있는 제약을 표시하면 후보를 줄일 수 있다. 관리형이라는 표현도 아무것도 설정하지 않아도 된다는 뜻이 아니라, 내가 책임질 운영 영역이 달라진다는 뜻으로 읽어야 한다.
설계 리뷰에서는 요구 사항을 가용성·성능·비용·운영 부담·일관성·보안으로 나누어 적어 본다. 그다음 각 후보가 충족하지 못하는 조건을 한 줄씩 적는다. 이 기록은 선택의 이유를 남기고, 나중에 트래픽이나 데이터 특성이 바뀌었을 때 재검토할 기준이 된다.
서비스를 외우기보다, 먼저 제약을 읽고 그 제약을 가장 적게 훼손하는 선택을 찾는다.