Cloud Modernization 14

데이터 성격에 맞는 AWS DB 서비스 선택 가이드

데이터베이스 서비스 이름이 많아지면 관계형과 비관계형을 어떤 기준으로 골라야 하는지 막힌다.

근거 · 교안 p51-p56

RDS와 NoSQL 서비스 선택을 데이터 성격으로 판단하기 ?? ???

1장: 끝없는 서비스 이름, 큰 그림으로 분류하기

솔라는 태블릿 화면에 떠 있는 단어들을 노려보았다. AWS 데이터베이스 서비스 목록. RDS, Aurora, Redshift, DocumentDB, DynamoDB, ElastiCache… 이름들은 낯설지 않았다. 여기저기서 한 번쯤은 들어본 이름들이었다. 하지만 목록으로 마주하니, 마치 빽빽하게 들어찬 상점 간판들처럼 느껴졌다. 어느 가게에 들어가야 할지 전혀 감이 잡히지 않는 이국의 시장 한복판에 선 기분이었다.

“이거 봐, 언니.”

솔라가 거실 소파에 앉아 책을 읽던 루나에게 태블릿을 내밀었다.

“데이터베이스를 골라야 하는데, 뭐가 이렇게 많아? 다 비슷비슷한 것 같고, 뭘 기준으로 봐야 할지 모르겠어. 그냥 알파벳순으로 나열된 이름들 같아.”

솔라의 목소리에는 짜증 섞인 막막함이 묻어났다. 그녀의 생각은 ‘모든 서비스는 각자 복잡하고, 명확한 분류 기준 같은 건 없다’는 결론으로 향하고 있었다. 하나하나 검색해서 특징을 외우는 것 말고는 방법이 없어 보였다.

루나는 솔라의 태블릿을 잠시 들여다보더니, 화면을 톡톡 두드려 목록만 남기고 다른 창들을 모두 닫았다. 그리고는 화면을 옆으로 돌려 가로로 길게 눕혔다.

“이 이름들을 외우려고 하면 금방 지칠 거야. 하나씩 공부하기 전에, 한번 직접 나눠보는 건 어때?”

“나눈다고?”

“응. 여기에 두 칸을 만든다고 생각해 봐.”

루나는 허공에 손가락으로 커다란 사각형 두 개를 그렸다.

“한쪽에는 ‘관계형 데이터베이스 같은 것’을, 다른 한쪽에는 ‘비관계형 데이터베이스 같은 것’을 넣어보는 거야. 솔라 네가 아는 만큼만, 느낌으로.”

그건 시험이 아니었다. 정답을 맞히라는 압박도 없었다. 루나의 제안은 복잡한 문제를 풀기 전, 어질러진 책상을 정리하는 것에 가까웠다. 솔라는 잠시 망설이다가 루나의 말대로 머릿속에서 두 개의 바구니를 떠올렸다.

“음… 일단 RDS는 확실히 관계형이지. 수업에서 그렇게 배웠으니까. Aurora도 RDS랑 비슷하다고 했으니… 이것도 관계형 바구니에.”

솔라는 손가락으로 화면의 ‘RDS’와 ‘Aurora’를 콕 찍어 왼쪽 허공으로 옮기는 시늉을 했다.

“그리고 DynamoDB. 이건 대표적인 NoSQL이니까 비관계형 바구니. DocumentDB도 이름부터 ‘문서’니까, JSON 같은 걸 다룰 테고… 그럼 비관계형이겠네.”

이제 남은 건 Redshift와 ElastiCache였다. 솔라는 잠시 고민에 빠졌다.

“Redshift는… 잘 모르겠어. 데이터 분석에 쓴다고 들었는데, SQL을 쓴다고 하니 관계형 같기도 하고… 아닌 것 같기도 하고. ElastiCache는 캐시인데, 데이터베이스인가? 이것도 애매한데.”

솔라는 잠시 말을 멈추고 자신이 분류한 결과를 돌아보았다. 완벽하지는 않았다. 여전히 물음표가 붙은 이름들이 남아있었다. 하지만 중요한 변화가 생겼다. 아까까지만 해도 그저 의미 없는 이름의 나열로 보였던 목록이, 이제는 성격이 다른 두 개의 뚜렷한 그룹으로 보이기 시작했다.

전에는 모든 서비스가 개별적인 선택지처럼 보여 열 개가 넘는 문을 하나씩 다 열어봐야 할 것 같았다. 하지만 이제는 눈앞에 큰 갈림길이 나타난 것 같았다. ‘관계형’이라는 문과 ‘비관계형’이라는 문. 어느 쪽으로 갈지 먼저 정하면, 선택지가 절반으로 줄어드는 셈이었다.

“아.”

솔라의 입에서 나지막한 탄성이 터져 나왔다.

“전부 다 따로따로인 게 아니었구나. 일단 크게 ‘관계형’과 ‘비관계형’으로 나누고 시작하면 되는 거였어.”

그녀는 다시 태블릿 화면을 보았다. 더 이상 AWS 서비스 목록은 혼란스러운 이름의 집합이 아니었다. 양쪽에 선명한 푯말이 세워진 갈림길이었다. ‘어떤 길로 가야 하는가?’라는 다음 질문이 떠올랐지만, 적어도 어디서부터 시작해야 할지는 분명해졌다. 복잡한 문제를 마주했을 때, 세부 사항에 파고들기 전에 큰 덩어리로 묶어보는 것. 이 간단한 접근법 하나가 막막했던 시야를 틔워주었다.

솔라는 방금 전과는 다른 눈으로 루나를 보며 물었다.

“좋아, 이제 두 그룹으로 나눌 수 있겠다는 건 알겠어. 그런데 언니, 이 두 갈래 길에서… 내 데이터는 어느 쪽으로 가야 하는 걸까? 그걸 결정하는 기준은 뭐야?”

2장: 내 데이터에 맞는 DB 유형 찾기: 관계형 vs. 비관계형

솔라의 질문이 거실 공기에 내려앉았다. “내 데이터는 어느 쪽으로 가야 하는 걸까? 그걸 결정하는 기준은 뭐야?” 갈림길을 발견했지만, 어느 쪽으로 가야 할지 모르는 상황. 막막함이 다시 고개를 들려는 찰나였다.

루나는 말없이 소파 앞의 낮은 테이블 서랍을 열어 하얀 노트와 펜을 꺼냈다. 태블릿의 밝은 화면 대신, 익숙한 종이의 질감이 눈앞에 펼쳐졌다. 루나는 노트를 펼쳐 두 개의 커다란 사각형을 나란히 그렸다. 마치 지난 장에서 솔라가 머릿속으로 떠올렸던 두 개의 바구니를 그대로 옮겨온 것 같았다. 왼쪽 사각형 위에는 ‘관계형’, 오른쪽 위에는 ‘비관계형’이라고 적었다.

“말로 기준을 나열하기 전에, 아주 간단한 데이터를 가지고 직접 그릇에 담아보자.”

루나는 펜으로 노트를 가리키며 말했다.

“여기 두 종류의 데이터가 있다고 상상해 봐. 하나는 ‘사용자 프로필’이고, 다른 하나는 ‘사용자 활동 로그’야.”

솔라는 고개를 끄덕였다. 사용자 프로필은 이름, 이메일, 가입일처럼 규격이 뚜렷한 정보일 것이다. 활동 로그는 로그인, 글쓰기, 댓글 달기 등 사용자의 모든 행동을 시간 순서대로 기록한, 훨씬 자유로운 형태의 데이터일 테고.

“우선 ‘사용자 프로필’ 데이터를 ‘관계형’ 그릇에 담아볼까? 어떤 모양이 될 것 같아?”

“그건 쉽지.”

솔라는 자신 있게 펜을 건네받았다. 그녀는 ‘관계형’이라고 적힌 사각형 안에 익숙한 표를 그리기 시작했다. 사용자 ID, 이름, 이메일, 가입일이라는 열(column)을 만들고, 그 아래에 가상의 사용자 데이터를 몇 줄 채워 넣었다. 마치 잘 정리된 엑셀 시트 같았다. 모든 칸이 빠짐없이 채워져 있고, 구조는 명확했다.

사용자 ID이름이메일가입일
101솔라sola@example.com2023-01-10
102루나luna@example.com2022-05-20

“좋아. 그럼 이번엔 ‘사용자 활동 로그’를 ‘비관계형’ 그릇에 담아보자. 이건 표가 아니라, 그냥 데이터를 덩어리로 묶는다고 생각해 봐.”

솔라는 잠시 고민했다. 활동 로그는 종류가 다양했다. 로그인 기록, 게시글 작성 기록, 댓글 기록… 모든 활동이 똑같은 정보를 담고 있지는 않았다. 그녀는 한 사용자의 활동을 예로 들어 중괄호를 이용해 묶어보기 시작했다.

{
  "사용자 ID": 101,
  "활동": [
    { "시간": "2023-10-26 09:00", "종류": "로그인" },
    { "시간": "2023-10-26 09:05", "종류": "게시글 작성", "게시글 ID": 55 },
    { "시간": "2023-10-26 09:10", "종류": "댓글 작성", "게시글 ID": 48, "내용": "좋은 글이네요!" }
  ]
}

그림을 그리고 나니 차이가 한눈에 들어왔다. 왼쪽의 표는 반듯하고 예측 가능했지만, 오른쪽의 데이터 묶음은 훨씬 자유롭고 유연했다. 로그인 활동에는 없는 ‘게시글 ID’나 ‘내용’ 같은 항목이 다른 활동에는 자연스럽게 포함되어 있었다.

“음… 확실히 활동 로그는 데이터마다 모양이 조금씩 다르니까, 이렇게 묶어두는 게 편하겠네. 스키마가 유연하다는 게 이런 뜻이구나.”

솔라는 자신의 발견에 만족하며 말했다. ‘관계형은 스키마 고정, NoSQL은 유연함.’ 그녀가 어렴풋이 알고 있던 개념이 눈앞에서 증명된 것 같았다.

“거의 다 왔어.”

루나가 말했다.

“그럼 솔라, 반대로 한번 해볼래? 방금 그린 활동 로그를 왼쪽의 관계형 표에 억지로 넣어본다면 어떻게 될까?”

솔라는 펜을 들고 다시 고민에 빠졌다. ‘활동’이라는 하나의 표에 모든 걸 담으려니, ‘게시글 ID’나 ‘내용’ 같은 열(column)이 필요했다. 하지만 로그인 활동의 경우 이 칸들은 텅 비게 될 것이다. NULL 값이 가득한, 구멍 뚫린 표가 만들어질 터였다. 혹은 ‘활동_로그인’, ‘활동_게시글’처럼 여러 개의 표로 쪼개야 할지도 모른다. 그러자면 나중에 사용자 한 명의 모든 활동을 보려면 여러 표를 다시 합치는(JOIN) 복잡한 작업이 필요했다.

그 순간, 솔라의 머릿속에서 무언가 ‘아’ 하고 연결되는 느낌이 들었다.

“알겠다…! 이건 단순히 스키마가 유연하냐 아니냐의 문제가 아니구나.”

솔라가 노트를 번갈아 보며 말했다.

“데이터의 ‘모양’ 자체가 다른 거였어. 사용자 프로필처럼 모든 데이터가 똑같은 구조를 가질 때, 즉 데이터가 ‘정형화’되어 있을 때는 관계형 모델이 딱 맞아. 데이터 무결성을 지키기도 쉽고. 하지만 활동 로그처럼 데이터마다 담기는 정보가 다르고, 그 구조가 예측하기 어려운 ‘비정형’ 데이터는… 억지로 표에 맞추는 것보다 그냥 하나의 문서처럼 통째로 다루는 비관계형 모델이 훨씬 자연스러운 거구나.”

그것은 ‘유연성’이라는 단어 하나로는 설명되지 않는, 더 근본적인 차이에 대한 깨달음이었다. 중요한 것은 DB의 특징이 아니라, 내가 다룰 데이터의 본질적인 성격이었다. 데이터가 가진 고유의 구조, 그리고 그 데이터를 어떻게 읽고 쓸 것인지(접근 패턴)에 따라 적합한 그릇이 정해지는 것이었다.

“이제 AWS 서비스 목록을 다시 보면 느낌이 다를 거야.”

루나의 말에 솔라는 고개를 들어 다시 태블릿을 보았다. RDS, Aurora 같은 관계형 서비스들은 이제 ‘정형화된 데이터를 위한 반듯한 서랍장’처럼 보였다. DocumentDB나 DynamoDB 같은 비관계형 서비스들은 ‘다양한 모양의 물건을 담을 수 있는 유연한 상자’처럼 느껴졌다.

“이제 어떤 데이터를 어느 그릇에 담아야 할지 감이 와. 먼저 내 데이터의 모양부터 분석하고 모델을 정하면 되는 거였어.”

스스로 선택의 기준을 찾아낸 솔라의 목소리에 자신감이 붙었다. 그녀는 잠시 생각에 잠기더니 새로운 질문을 던졌다.

“좋아, 내 데이터가 정형 데이터라서 관계형 DB를 쓰기로 결정했다고 치자. 그런데 RDS만 해도 MySQL, PostgreSQL, MariaDB… 엔진 종류가 또 있잖아. 그리고 이걸 내가 직접 서버에 설치해서 쓰는 거랑, AWS에서 버튼 몇 번 눌러서 쓰는 건 근본적으로 뭐가 다른 거지? 언니가 아까 말한 ‘관리형’이라는 게 그냥 편하다, 그게 다일까?”

3장: 운영 부담을 덜어주는 선택: 관리형 서비스의 가치

이전 장에서 사용하던 노트는 여전히 테이블 위에 펼쳐져 있었다. 왼쪽에는 반듯한 표로 그려진 ‘사용자 프로필’이, 오른쪽에는 유연한 구조로 묶인 ‘활동 로그’가 자리를 잡고 있었다. 솔라는 이제 데이터의 모양을 보고 관계형과 비관계형 중 어떤 그릇을 선택해야 할지 분명히 알게 되었다. 그녀는 자신의 가상 프로젝트에 ‘사용자 프로필’ 데이터가 있으니 관계형 DB가 맞겠다고 결론 내렸다.

그녀는 태블릿을 들어 AWS의 RDS(Relational Database Service) 페이지를 열었다. 화면에는 ‘클릭 몇 번으로 관계형 데이터베이스 설정’이라는 문구가 떠 있었다. 솔라는 잠시 생각에 잠겼다. ‘클릭 몇 번.’ 그 말은 편리하게 들렸지만, 동시에 어떤 의구심을 불러일으켰다.

“언니.”

솔라가 화면을 가리키며 입을 열었다.

“내 데이터는 구조가 명확하니까 관계형 DB를 쓰기로 했어. 그래서 RDS를 보고 있는데… 솔직히 잘 모르겠어. 그냥 서버(EC2) 하나 빌려서 내가 직접 MySQL을 설치하는 거랑, 이렇게 AWS가 버튼으로 만들어준 걸 쓰는 거랑 근본적으로 뭐가 다른 거지? 그냥 설치 과정이 편하다는 거? 그것 때문에 돈을 더 내는 건 좀 아까운데.”

솔라의 생각은 명료했다. ‘관리형’ 서비스는 단순히 편의성을 위해 돈을 더 지불하는 비싼 옵션이고, ‘비관리형’(직접 설치)은 번거롭지만 저렴한 방법이라는 이분법이었다. AWS가 대신해주는 ‘설치’라는 작업이 그리 대단해 보이지 않았다.

루나는 솔라의 질문에 대답하는 대신, 옆에 놓인 새 노트를 솔라 쪽으로 밀어주었다.

“좋아, 솔라. 네가 EC2 서버에 직접 MySQL을 설치해서 운영하는 데이터베이스 관리자가 되었다고 상상해 보자. 방금 ‘설치’가 끝났어. 자, 이제부터 네가 해야 할 일은 뭐가 있을까? 체크리스트를 한번 만들어봐.”

“체크리스트?”

“응. 데이터베이스를 ‘운영’하기 위해 필요한 모든 작업 목록.”

솔라는 잠시 어리둥절했지만, 이내 펜을 들고 적기 시작했다. 첫 항목은 당연했다.

1. 데이터베이스 소프트웨어 설치 및 초기 설정

“이건 방금 끝났고.”

솔라는 자신만만하게 말했다. 하지만 다음 항목이 바로 떠오르지 않았다. 설치가 끝나면 그냥 쓰면 되는 것 아닌가? 그녀가 머뭇거리자, 루나가 조용히 첫 번째 질문을 던졌다.

“만약 새벽에 하드웨어가 고장 나서 서버가 꺼지면 어떻게 해? 데이터는?”

“아… 백업. 정기적으로 백업을 받아둬야지.”

솔라는 황급히 다음 항목을 추가했다.

2. 매일 데이터베이스 자동 백업 설정

“얼마 전 뉴스에 나온 것처럼, 데이터베이스 소프트웨어 자체에 심각한 보안 취약점이 발견되면?”

“패치해야지. 보안 패치가 나오면 바로 적용하고…”

3. 보안 패치 및 마이너 버전 업데이트 주기적으로 확인 및 적용

“사용자가 갑자기 몰려서 웹사이트가 느려지기 시작하면? 제일 먼저 어디를 의심하게 될까?”

“데이터베이스. 쿼리가 느려졌거나… 부하가 몰렸거나. 그럼 DB 성능을 계속 지켜봐야겠네.”

4. CPU, 메모리, 스토리지 사용량 등 성능 모니터링 시스템 구축

솔라의 펜이 멈추지 않았다. 루나의 질문은 꼬리에 꼬리를 물고 이어졌다.

“사용자가 계속 늘어서 지금 서버 사양으로 감당이 안 되면?” (5. 필요시 더 높은 사양의 서버로 마이그레이션 (스케일 업)) “읽기 요청이 너무 많아서 부하를 분산해야 한다면?” (6. 읽기 전용 복제본(Read Replica) 만들고 데이터 동기화 설정) “메인 DB가 장애 났을 때, 백업본으로 복구하는 데 시간이 걸리면 서비스는 멈추는 건가?” (7. 장애 대비용 예비 데이터베이스(Standby) 구성 및 자동 장애 조치(Failover) 설정)

어느새 솔라의 체크리스트는 빼곡하게 채워져 있었다. 처음 생각했던 ‘설치’는 그저 거대한 빙산의 일각에 불과했다. 그 아래에는 백업, 패치, 모니터링, 확장, 고가용성 구성 등, 끝없이 이어지는 운영 업무가 숨어 있었다. 직접 해본 적은 없지만, 상상하는 것만으로도 머리가 아찔했다.

솔라는 멍하니 자신이 만든 목록을 내려다보았다.

루나는 그때서야 솔라가 보고 있던 태블릿의 RDS 페이지를 가리켰다.

“이제 그 목록을 보면서, RDS가 무엇을 해주는지 다시 한번 읽어볼래?”

솔라는 천천히 화면의 기능 설명을 읽어 내려갔다. ‘자동 백업’, ‘소프트웨어 패치’, ‘Amazon CloudWatch를 통한 모니터링’, ‘클릭 몇 번으로 스토리지 또는 컴퓨팅 확장’, ‘다중 AZ 배포를 통한 고가용성 및 장애 조치’…

“어…?”

솔라의 입에서 작은 탄식이 흘러나왔다. 자신이 방금 고생하며 작성한 체크리스트의 거의 모든 항목이 RDS의 기능 목록에 그대로 적혀 있었다. 그것도 ‘자동’, ‘관리형’, ‘간편한’ 이라는 수식어와 함께.

그 순간, 솔라의 머릿속을 지배하던 이분법이 깨졌다. 관리형 서비스는 단순히 ‘설치’를 대신해주는 편리한 도구가 아니었다. 데이터베이스 운영이라는, 보이지 않지만 끝없이 계속되는 책임과 부담을 대신 짊어져 주는 전문가 팀과도 같았다. 내가 지불하는 비용은 ‘설치’라는 일회성 행위에 대한 것이 아니라, 이 모든 체크리스트를 안정적으로 수행해 주는 ‘지속적인 관리’에 대한 가치였던 것이다.

“알겠다…”

솔라가 나지막이 말했다.

“비싼 게 아니었어. 내가 직접 했을 때 들어갈 시간과 노력, 그리고 실수를 저지를 위험까지 모두 포함된 가격이었구나. 이 모든 걸 AWS가 대신 해주면, 나는 그냥 내 애플리케이션 개발에만 집중하면 되는 거네.”

그녀는 ‘운영 부담 최소화’라는 원칙의 무게를 비로소 실감했다. 핵심 가치를 만드는 일에 집중하기 위해, 그 외의 복잡하고 반복적인 운영은 전문가에게 맡기는 것. 그것은 비용의 문제가 아니라 전략의 문제였다.

이제 솔라의 눈앞에 있던 AWS 데이터베이스 서비스 목록은 더 이상 혼란스럽지 않았다. 그녀는 맨 처음 갈림길을 만들었던 노트를 다시 가져왔다. 그리고 그 위에 자신만의 ‘DB 선택 가이드라인’을 정리하기 시작했다.

  1. 데이터의 모양은 어떤가? (모델 선택)

    • 모든 데이터가 같은 구조인가? → 관계형 (예: RDS, Aurora)
    • 데이터마다 구조가 다른가? → 비관계형 (예: DynamoDB, DocumentDB)

  2. 누가 데이터베이스를 돌볼 것인가? (운영 방식 선택)

    • DB 운영보다 서비스 개발에 집중하고 싶다. → 관리형 서비스 (예: RDS, DynamoDB)
    • DB 내부까지 직접 제어해야 하고, 전담 인력이 있다. → 직접 설치 (예: EC2에 설치)

솔라는 완성된 가이드라인을 보며 만족스럽게 고개를 끄덕였다. 이제 그녀에게 AWS의 수많은 데이터베이스 서비스는 복잡한 선택지가 아닌, 명확한 기준에 따라 고를 수 있는 잘 정리된 도구 상자가 되었다. 어떤 데이터를, 누가 운영할 것인가? 이 두 가지 질문만으로도 안갯속을 헤매던 것 같았던 길의 방향이 선명하게 보였다. 그녀는 자신의 프로젝트에 가장 적합한 첫걸음이 ‘AWS의 관리형 관계형 데이터베이스 서비스’라는 것을 스스로의 논리로 증명해냈다.