Day 1 - 데이터베이스 개요: 같은 "DB"라도 쓰임새가 다르다

관리형 데이터베이스란 무엇인가

AWS 콘솔의 데이터베이스 카테고리에는 RDS, Aurora, DynamoDB, ElastiCache, Redshift가 줄줄이 나온다. 외울 대상이 아니라 각자가 어떤 문제를 풀려고 태어났는지를 잡아야 "고객 주문 데이터", "장바구니 임시 저장", "한 달치 매출 분석" 같은 시나리오에서 답이 보인다.

• AWS의 데이터베이스 서비스는 거의 전부 관리형(managed)이다.
• 서버 설치, OS 패치, 백업, 장애 복구 같은 귀찮은 운영 일을 AWS가 대신해준다.
• 직접 EC2에 MySQL을 깔 수도 있지만, 그러면 패치도 백업도 전부 내 책임이 된다.

관리형이 없던 시절엔 무슨 일이 있었나

"관리형"이라는 말이 왜 그렇게 중요한지 감이 안 잡힌다면, 예전 방식이 어땠는지 한 번만 상상해 보면 된다. 회사에 데이터베이스가 필요해지면 담당자는 이런 일들을 순서대로 했다.

1. 서버를 사거나 빌리고, 운영체제와 데이터베이스 소프트웨어를 설치한다.
2. 설정 파일을 손으로 고쳐 성능을 맞춘다.
3. 매일 밤 백업 스크립트를 돌리고, 그게 실제로 복원되는지 가끔 확인한다.
4. 보안 취약점이 발표되면 밤을 새워 패치한다.
5. 서버 한 대가 죽으면 서비스가 멈추니, 똑같은 서버를 한 대 더 두고 데이터를 계속 복제하는 구성을 직접 만든다.
6. 디스크가 꽉 차 가면 미리 알아채고 용량을 늘린다.

이 중 어느 것도 "우리 서비스만의 가치"를 만들지 않는다. 고객이 돈을 내는 이유는 우리 앱이 잘 동작하기 때문이지, 우리가 백업 스크립트를 잘 짜서가 아니다. 관리형 데이터베이스는 이 목록을 통째로 AWS에 넘긴다.

이런 일들을 흔히 차별화되지 않는 힘든 일(undifferentiated heavy lifting)이라고 부른다. 반드시 해야 하지만 아무리 잘해도 경쟁 우위가 되지 않는 작업들이다. 클라우드의 존재 이유를 한 문장으로 줄이면 "이 힘든 일을 대신 맡아 주는 것"이고, 관리형 데이터베이스는 그 대표적인 예다.

이것이 Day별로 반복되는 공동 책임 모델의 데이터베이스 버전이다. RDS 같은 관리형 서비스를 쓰면 엔진 패치·백업·복제 같은 "인프라 운영"은 AWS 책임으로 올라가고, 고객은 데이터 모델링·접근 권한·쿼리 같은 "데이터 안의 일"에 집중한다.

관계형 데이터베이스: RDS와 Aurora

• 가장 전통적인 데이터는 표(table)로 정리된 정형 데이터다. 고객, 주문, 결제처럼 행과 열이 명확하고 서로 관계(JOIN)가 있다.
• 이걸 다루는 게 관계형 데이터베이스(RDBMS)이고, SQL로 질의한다.

관계형 데이터베이스를 처음 듣는다면 엑셀 시트 여러 장이 서로 연결된 것을 떠올리면 정확하다. 고객 시트에는 고객번호·이름·연락처가, 주문 시트에는 주문번호·고객번호·금액이 들어 있다. 두 시트는 고객번호라는 공통 칸으로 이어져 있어서, "3월에 10만 원 넘게 산 고객의 이름과 연락처"를 한 번에 뽑아낼 수 있다. 이렇게 표와 표를 이어 붙이는 것이 JOIN이고, 이 작업을 잘하도록 만들어진 것이 관계형 데이터베이스다.

이 방식의 강점은 규칙이 엄격하다는 것이다. 주문에는 반드시 고객번호가 있어야 하고 금액 칸에는 숫자만 들어가니, 돈이 오가는 업무처럼 "값이 틀리면 큰일 나는" 데이터에 강하다. 약점도 같은 데서 나온다 — 칸 구조를 미리 정해 두어야 한다.

Amazon RDS(Relational Database Service)

• MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 같은 익숙한 엔진을 관리형으로 제공한다.
• 기존에 쓰던 DB를 그대로 클라우드로 옮기고 싶을 때 가장 자연스러운 선택이다.

Amazon Aurora

• AWS가 클라우드에 맞게 새로 설계한 관계형 DB로, MySQL·PostgreSQL과 호환된다.
• 같은 MySQL 코드를 쓰면서도 성능이 더 높다(표준 MySQL 대비 수 배).
• 스토리지가 자동으로 늘어난다.
• 여러 AZ에 데이터를 자동 복제해 내구성이 높다.

"기존 Oracle DB를 최소 변경으로 옮기고 싶다" → RDS. "최고 성능과 자동 확장을 원하고 MySQL/PostgreSQL이면 충분하다" → Aurora. 이 두 키워드("기존 엔진 유지" vs "고성능 클라우드 네이티브")가 갈림길이 된다.

15년 된 사내 회계 시스템을 옮기려는 회사가 있다. Oracle 위에서 돌고 수천 줄짜리 저장 프로시저가 얽혀 있어서, "성능이 더 좋으니 Aurora로 가자"고 하면 애플리케이션을 통째로 다시 짜야 한다. 정답은 RDS for Oracle — 쓰던 엔진을 그대로 두고 운영 부담만 넘기는 것이다. 반대로 새로 만드는 서비스라면 처음부터 Aurora가 낫다. "기존 시스템이냐, 새로 만드는 것이냐"가 갈림길이다.

헷갈리기 쉬운 짝: 다중 AZ vs Read Replica

RDS에는 "복제본을 하나 더 둔다"는 점에서 비슷해 보이지만 목적이 전혀 다른 두 기능이 있다. CLF 시험이 아주 좋아하는 대목이다.

다중 AZ(Multi-AZ) 배포는 고가용성(장애 대비)을 위한 것이다. 다른 가용 영역(물리적으로 떨어진 데이터센터)에 대기용 복제본을 두고 데이터를 계속 동기화한다. 주 데이터베이스가 죽으면 AWS가 자동으로 대기 복제본으로 전환(장애 조치, failover)한다. 이 대기 복제본은 평소에 놀고 있으며 읽기 요청을 받지 않는다 — 오로지 보험이다.

Read Replica(읽기 전용 복제본)는 읽기 성능 향상을 위한 것이다. 원본의 사본을 두고 조회 트래픽을 그쪽으로 보내 원본의 부담을 던다. 여러 개 만들 수 있지만, 자동 장애 조치를 위한 장치는 아니다.

⚠️ 함정: 문항에 "가용성을 높이고 싶다"가 나왔는데 Read Replica을 고르거나, "조회 트래픽이 너무 많아 느리다"인데 다중 AZ를 고르는 것이 실수하기 쉽다. 둘 다 "복제본"이라는 같은 단어를 쓰기 때문이다. "복제본을 왜 두는가"를 물어본다 — 보험이면 다중 AZ, 일손 나누기면 Read Replica이다.

NoSQL: DynamoDB

• 표 형태로 깔끔하게 안 떨어지는 데이터도 많다 — 사용자 프로필, 게임 상태, IoT 센서 값처럼 구조가 유연한 데이터.
• 초당 수백만 건의 읽기/쓰기가 필요한 경우도 여기에 해당한다.
• 이럴 때 쓰는 게 Amazon DynamoDB, 완전 관리형 NoSQL(키-값 / 문서) 데이터베이스다.
• 특징은 "서버를 신경 쓸 필요가 없다"는 점이다.
  • 용량을 미리 잡지 않아도 트래픽에 따라 자동 확장된다(온디맨드 모드).
  • 한 자리 밀리초(single-digit millisecond) 수준의 빠른 응답을 어떤 규모에서도 보장한다.

[관계형 RDS/Aurora]              [NoSQL DynamoDB]
 행/열 고정 스키마                유연한 항목(item) 구조
 JOIN으로 관계 표현               단일 키로 초고속 조회
 복잡한 질의에 강함               초대규모 트래픽에 강함

DynamoDB를 이해하는 가장 쉬운 그림은 거대한 물품 보관함이다. 각 칸에는 번호표(키)가 붙어 있고, 번호표를 대면 그 칸의 내용물을 즉시 꺼내 준다. 칸 안에 무엇이 들었는지는 칸마다 달라도 상관없다 — 어떤 칸에는 이름과 이메일만, 다른 칸에는 이름·이메일·생일·취미가 들어 있어도 된다. 대신 "취미가 등산인 사람 전부 찾아 줘"처럼 번호표 없이 내용물을 뒤지는 일은 잘 못한다.

이 성질이 강점과 약점을 동시에 설명한다. 번호표로 찾는 일은 데이터가 100건이든 1억 건이든 똑같이 빠르지만, 여러 표를 이어 붙이는 복잡한 질의나 자유로운 조건 검색은 관계형만 못하다.

모바일 게임 회사가 전 세계 접속자의 게임 상태(레벨, 아이템, 접속 시각)를 저장한다고 가정한다. 조회는 거의 항상 "이 사용자 ID의 데이터를 가져와"라는 단순한 형태인데 초당 수십만 건이 몰리고, 이벤트가 열리면 트래픽이 몇 배로 뛰며, 업데이트마다 저장할 항목이 늘어난다. 단순 키 조회 + 초대규모 + 유연한 구조 — DynamoDB가 태어난 자리다.

"스키마가 자주 바뀌거나", "예측 불가한 대규모 트래픽", "서버 관리 없이"라는 키워드가 보이면 DynamoDB다. 반대로 "복잡한 JOIN", "트랜잭션 정합성", "기존 SQL 앱"이면 RDS/Aurora 쪽이다.

⚠️ 함정: "NoSQL이 관계형보다 더 발전한 최신 기술"이라고 이해하면 곤란하다. 둘은 위아래가 아니라 옆으로 나란히 선 선택지다. 은행 계좌 이체처럼 정확성이 절대적인 업무에는 여전히 관계형이 맞고, 대규모 단순 조회에는 NoSQL이 맞다. 시험도 "무엇이 더 좋은가"가 아니라 "이 상황에 무엇이 맞는가"를 묻는다.

캐시: ElastiCache

• DB는 좋지만, 같은 데이터를 1초에 수천 번 읽으면 DB가 힘들어진다.
• 이때 자주 쓰는 데이터를 메모리에 잠깐 올려두고 빠르게 꺼내쓰는 것이 캐시다.
• Amazon ElastiCache는 Redis와 Memcached를 관리형으로 제공하는 인메모리 캐시 서비스다.
• 대표 용도: 세션 저장, 리더보드, 자주 조회되는 상품 정보 캐싱 등.
• 메모리에서 처리하므로 마이크로초~밀리초 수준으로 매우 빠르다.
• 단, 메모리는 휘발성이라 영구 저장소가 아니라 "앞단 가속기"로 이해해야 한다.

캐시가 푸는 문제는 한 문장이다 — "똑같은 질문을 계속 반복하고 있다." 쇼핑몰 첫 화면의 인기 상품 목록은 5분에 한 번 바뀔까 말까 한데, 방문자가 1초에 수천 명이면 데이터베이스는 같은 답을 수천 번 다시 계산한다. 사서가 매번 서고까지 걸어가 같은 책을 꺼내 오는 셈이다. 그 책을 카운터 위에 올려 두면 되고, 그게 캐시다.

"DB 부하를 줄여라", "응답 지연을 줄여라", "세션/리더보드"라는 신호가 보이면 ElastiCache. 캐시는 원본 DB를 대체하는 게 아니라 앞에 두는 보조 계층이라는 점이 핵심이다.

함정: 캐시는 영구 저장소가 아니다. 메모리는 전원이 나가면 내용이 사라지고, 공간이 부족하면 오래된 데이터부터 밀려난다. 그래서 "고객 주문 기록을 ElastiCache에 저장한다" 같은 선택지는 오답이다. 캐시에 있는 데이터는 언제 사라져도 원본에서 다시 만들어 낼 수 있는 것이어야 한다.

분석/데이터 웨어하우스: Redshift

• 마지막은 성격이 완전히 다른 데이터다 — "지난 3년치 매출을 지역·상품별로 집계해줘" 같은 대량의 데이터를 모아 분석하는 일.
• 이런 분석 질의는 RDS 같은 운영 DB에 던지면 느리고 운영에 방해가 된다.
• Amazon Redshift는 이런 분석 전용 데이터 웨어하우스(Data Warehouse)다.
• 페타바이트급 데이터를 열 기반(columnar) 저장으로 빠르게 집계·분석하도록 만들어졌다.
• 핵심 구분은 OLTP와 OLAP이다.

마트에 비유하면 OLTP는 계산대(손님 한 명의 물건 몇 개를 빠르게, 하루 종일 반복), OLAP는 본사 회의실("지난 3년 지점별 매출 추이"처럼 한 번에 수억 건을 훑어 요약)이다. 계산대에서 그 분석을 돌리면 뒤에 줄 선 손님이 다 멈춘다. 그래서 분석 전용 창구를 따로 두는 것이고, 그게 Redshift다.

"데이터 웨어하우스", "BI", "대량 데이터 분석/집계", "리포팅"이 보이면 Redshift다. 반대로 "실시간 거래/주문 처리"는 OLTP(RDS/Aurora/DynamoDB)다.

그 밖의 데이터베이스 서비스 (가볍게)

AWS에는 특정한 데이터 모양만을 위해 만들어진 데이터베이스도 있다. CLF 수준에서는 이름과 한 줄 용도만 알고 넘어가면 충분하다. 깊이 파고들 필요는 전혀 없다.

예전에는 "회사에 데이터베이스 하나"가 상식이었지만, 지금은 데이터의 성격마다 가장 잘 맞는 것을 골라 쓰는 목적에 맞게 만들어진(purpose-built) 데이터베이스 전략이 표준이다. AWS에 데이터베이스가 이렇게 많은 이유가 이것이다.

헷갈리는 짝 정리

이름이 비슷하거나 역할이 겹쳐 보여 자주 틀리는 조합만 모았다.

DB 선택 키워드 매핑표

문항에 아래 표현이 보이면 오른쪽을 먼저 의심하면 된다.

데이터 성격별 DB 선택 기준

정형 + SQL + JOIN          → RDS / Aurora
유연한 구조 + 초대규모      → DynamoDB
빠른 캐시 + DB 부하 감소    → ElastiCache
대량 분석 + 리포팅          → Redshift

• CLF 시험은 깊은 튜닝이 아니라 "이 시나리오에 맞는 서비스를 고르는 능력"을 묻는다.
• 각 서비스의 한 줄 정체성을 또렷이 기억하는 게 가장 효과적이다.
• 외우려 하지 말고 "이 데이터의 성격이 무엇인가"를 먼저 묻는 습관을 들이면 된다.

데이터베이스 문항은 먼저 "이 데이터의 성격이 무엇인가"를 묻는다. 정형인가 아닌가, 자주 꺼내는가 한 번에 몰아 보는가, 원본인가 사본인가를 따지면 선택지 넷 중 둘은 곧바로 지워진다. RDS는 쓰던 엔진을 그대로 관리형으로 옮긴 것이고, Aurora는 같은 세계를 클라우드용으로 새로 설계해 더 빠르고 자동으로 늘어나게 만든 것이다. Redshift는 계산대가 아니라 회의실에 가깝다. 대량 집계와 리포팅 전용이다.

다음 글에서는 이 서비스들을 서로 느슨하게 연결해주는 메시징 서비스 — SQS, SNS, EventBridge — 를 본다. 데이터가 어디에 저장되느냐만큼, 시스템 간에 어떻게 메시지를 주고받느냐도 클라우드 설계의 핵심이다.

📖 용어

• 관리형(managed) 서비스 : 서버 설치·패치·백업 같은 운영 잡일을 AWS가 대신 맡아주는 방식.
• 관계형 데이터베이스(RDBMS) : 데이터를 행과 열의 표로 정리하고 SQL로 다루는 데이터베이스.
• JOIN : 여러 표에 나뉜 데이터를 관계를 따라 하나로 이어 붙여 조회하는 것.
• NoSQL : 고정된 표 구조를 쓰지 않는 데이터베이스. 항목마다 필드가 달라도 된다.
• 키-값 저장소 : "이름표(키)를 대면 값을 돌려주는" 단순한 구조. 조회가 아주 빠르다.
• 인메모리 캐시 : 자주 쓰는 데이터를 메모리에 잠깐 올려두고 빠르게 꺼내 쓰는 임시 계층. 원본 저장소가 아니다.
• 데이터 웨어하우스 : 여러 곳의 데이터를 한데 모아 분석·리포팅만 전담시키는 저장소.
• OLTP : 주문·결제처럼 짧고 빈번한 읽기/쓰기를 처리하는 운영 업무.
• OLAP : 대량의 데이터를 모아 집계·분석하는 업무. 리포트와 BI 대시보드가 여기 속한다.
• 스키마(schema) : 데이터를 어떤 칸(열)으로 담을지 미리 정해 둔 구조. 관계형은 엄격하고, NoSQL은 느슨하다.
• 가용 영역(AZ) : 한 리전 안에서 물리적으로 떨어져 있는 데이터센터 묶음. 한 곳이 멈춰도 다른 곳은 살아 있게 하려고 나눠 둔 것이다.
• 다중 AZ(Multi-AZ) : 다른 가용 영역에 대기용 복제본을 두고, 원본이 죽으면 자동으로 넘겨받게 하는 고가용성 구성.
• Read Replica(읽기 전용 복제본) : 조회 트래픽을 나눠 받으려고 만든 읽기 전용 사본. 장애 조치용이 아니다.
• 장애 조치(failover) : 주 시스템이 멈췄을 때 대기 중이던 시스템이 역할을 넘겨받는 것.
• 열 기반(columnar) 저장 : 데이터를 행이 아니라 열 단위로 모아 저장하는 방식. 특정 열만 대량 집계할 때 훨씬 빠르다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

한 회사가 기존 온프레미스 Oracle 데이터베이스를 최소한의 변경으로 AWS로 옮기려 한다. 가장 적합한 서비스는?

• AAmazon RDS
• BAmazon DynamoDB
• CAmazon Redshift
• DAmazon ElastiCache

문제 2

유연한 데이터 구조와 예측이 어려운 초대규모 트래픽을 처리하며 서버 관리가 필요 없는 NoSQL 데이터베이스는?

• AAmazon Aurora
• BAmazon RDS
• CAmazon DynamoDB
• DAmazon Redshift

문제 3

데이터베이스의 읽기 부하를 줄이고 자주 조회되는 데이터의 응답 속도를 높이려 한다. 가장 적합한 서비스는?

• AAmazon Redshift
• BAmazon ElastiCache
• CAmazon RDS
• DAmazon DynamoDB

문제 4

한 회사가 지난 수년간의 판매 데이터를 모아 대규모 집계 분석과 BI 리포트를 만들려 한다. 가장 적합한 서비스는?

• AAmazon Redshift
• BAmazon DynamoDB
• CAmazon ElastiCache
• DAmazon RDS

문제 5

MySQL/PostgreSQL과 호환되면서 표준 대비 높은 성능과 스토리지 자동 확장을 제공하는, AWS가 클라우드에 맞게 새로 설계한 관계형 데이터베이스는?

• AAmazon RDS for MySQL
• BAmazon Aurora
• CAmazon DynamoDB
• DAmazon ElastiCache