앱이 기억해야 하는 것들 — 회원 정보, 저장된 사주 결과, 글마다의 기록 — 은 어딘가에 보관되어야 합니다. 그 "창고"가 바로 데이터베이스고, AWS에서는 RDS를 썼습니다. 오늘 글은 바로 그 창고를 어떻게 안전하게 마련했는지, 제가 처음 헤맸던 지점까지 하나도 빼놓지 않고 풀어보려고 합니다.

솔직히 고백하자면, 저는 이 "데이터베이스"라는 단어 앞에서 한참을 멈칫했습니다. EC2(가상 컴퓨터)까지는 그럭저럭 감이 왔는데, 데이터베이스는 이름부터가 너무 전문가스러웠거든요. 그런데 막상 해보니 개념 하나만 잡으면 나머지는 클릭 몇 번이더라고요. 그 개념 하나를 오늘 확실하게 잡아드리겠습니다. 코딩 한 줄 몰라도 괜찮습니다. 저도 그 자리에서 시작했으니까요.

데이터베이스는 어렵게 생각하지 마세요. "앱이 잊어버리면 안 되는 것들을 넣어두는 튼튼한 창고" — 딱 이 한 문장이면 90%는 이해한 겁니다.

데이터베이스가 대체 뭔가요 — 앱의 창고이자 기억

가장 쉬운 비유부터 가겠습니다. 우리 동네에 작은 식당이 하나 있다고 해볼게요. 손님이 주문을 하면 주방에서 음식을 만들어 내보냅니다. 그런데 이 식당이 장사를 계속하려면, 기억해야 할 것들이 생깁니다. 오늘 몇 그릇 팔렸는지, 단골손님이 누구인지, 재료가 얼마나 남았는지. 이걸 사장님 머릿속에만 담아두면 사장님이 하루 쉬는 순간 다 날아갑니다. 그래서 식당에는 장부가 있죠. 데이터베이스는 바로 이 장부입니다. 앱의 장부이자 창고이자 기억이에요.

조금 더 구체적으로 볼까요. 우리가 만든 사주앱을 생각해봅시다. 사용자가 회원가입을 하면 이메일과 비밀번호를 어딘가 저장해야 합니다. 안 그러면 다음에 로그인할 때 "당신 누구세요?"가 되니까요. 사용자가 사주 결과를 뽑으면 그 결과도 저장해둬야 나중에 "내 지난 운세 보기"가 됩니다. 이렇게 앱을 껐다 켜도, 서버를 재부팅해도 사라지면 안 되는 데이터는 전부 데이터베이스로 갑니다.

여기서 초보자가 자주 헷갈리는 게 하나 있어요. "앱(코드)이 데이터를 들고 있는 거 아닌가요?"라는 질문입니다. 아닙니다. 앱의 코드는 일하는 방식(요리 레시피)이고, 데이터베이스는 재료와 기록이 쌓이는 창고입니다. 레시피는 자주 바뀌고 다시 배포되지만, 창고에 쌓인 손님 정보는 그대로 유지되어야 하죠. 그래서 이 둘을 분리해서 관리하는 겁니다.

💡 핵심 정리: 서버(EC2)는 "일하는 직원", 데이터베이스(RDS)는 "장부와 창고". 직원은 갈아치워도 되지만, 장부가 사라지면 가게가 망합니다. 그래서 데이터베이스는 무엇보다 안전하게 관리해야 합니다.

표(테이블), 행, 열 — 엑셀을 떠올리면 됩니다

데이터베이스 안이 어떻게 생겼는지 아주 잠깐만 볼게요. 겁먹지 마세요, 여러분이 이미 아는 것과 똑같습니다. 바로 엑셀입니다. 데이터베이스 안에는 여러 개의 표(테이블)가 있습니다. '회원' 표, '사주결과' 표, '결제' 표 이런 식으로요. 각 표에는 맨 윗줄에 열(칼럼) 제목이 있습니다. 회원 표라면 '이메일', '가입일', '이름' 같은 것들이죠. 그리고 한 사람 한 사람의 정보가 행(로우)으로 한 줄씩 쌓입니다.

그래서 개발자들이 흔히 쓰는 관계형 데이터베이스(MySQL, PostgreSQL 같은 것)는 "엑셀 여러 장을 아주 튼튼하고 빠르게 관리해주는 프로그램"이라고 이해하시면 딱 맞습니다. 실제로 나중에 데이터를 들여다보면 정말 엑셀표처럼 생겼어요. 그러니 "나는 표 정도는 다룰 줄 안다" 하시는 분이라면 이미 데이터베이스의 절반은 이해하신 겁니다.

직접 설치 vs 관리형(RDS) — 뭐가 다를까

이제 본론입니다. 데이터베이스를 마련하는 방법은 크게 두 가지가 있어요.

저는 1초의 망설임도 없이 방법 B(RDS)를 골랐습니다. 왜냐하면 방법 A는 잘못 관리하면 데이터를 통째로 잃을 수 있는데, 초보에게 그건 너무 큰 위험이거든요. 아래 표로 두 방법을 나란히 비교해봤습니다.

비교 항목직접 설치 (EC2 안에 설치)관리형 (RDS)
비유우물을 직접 파기정수기 렌탈
초기 설정직접 설치·설정 (명령어 필요)화면에서 클릭 몇 번
백업내가 직접 챙겨야 함 (깜빡하면 끝)자동 백업 (기본 제공)
보안 패치내가 수동으로 업데이트AWS가 대신 적용
고장 시 복구내가 밤새 씨름자동 복구 옵션 (멀티AZ)
자유도매우 높음 (뭐든 커스터마이즈)정해진 범위 안에서
월 비용서버값만 (관리 노동은 내 시간)서버값 + 관리 서비스 요금
추천 대상DB 운영 경험 있는 사람초보자 · 1인 개발자 · 우리

표를 보면 명확하죠. 자유도가 조금 아쉬운 대신, RDS는 "관리라는 노동"을 통째로 덜어줍니다. 저처럼 코딩도 서툴고 밤새 서버랑 씨름하기 싫은 사람에게는 렌탈이 정답이에요. 이걸 "관리형(Managed) 서비스"라고 부르는데, 말 그대로 관리를 대신 해준다는 뜻입니다.

관리형이 초보에게 특히 좋은 세 가지 이유

RDS 같은 관리형 데이터베이스가 왜 초보에게 축복인지, 세 가지로 정리해드릴게요. 이건 제가 직접 겪으며 "아 정말 이걸 안 썼으면 큰일 날 뻔했다" 싶었던 순서대로입니다.

1) 자동 백업 — 실수해도 되돌릴 수 있다

초보자가 데이터베이스에서 가장 무서운 실수가 뭔지 아세요? 실수로 데이터를 지우는 겁니다. 명령어 한 줄 잘못 쳐서 '회원' 표가 통째로 날아가는 일, 실제로 흔합니다. 직접 설치한 데이터베이스라면 이 순간 심장이 멎죠. 되돌릴 방법이 없으니까요.

그런데 RDS는 매일 자동으로 백업을 떠둡니다. 게다가 "어제 오후 3시 12분 상태로 돌려줘" 같은 특정 시점 복구도 됩니다. 사진 찍듯이 시간대별로 상태를 저장해두기 때문이에요. 실수해도 되돌릴 수 있다는 이 안도감은, 겪어보면 정말 큽니다.

2) 자동 보안 패치 — 도둑이 못 들어오게 막아준다

데이터베이스 프로그램에도 가끔 "보안 구멍"이 발견됩니다. 집 자물쇠에 결함이 발견되는 것과 같아요. 그러면 만든 회사가 "이 자물쇠 위험하니 새 걸로 바꾸세요" 하고 업데이트를 내놓습니다. 직접 설치했다면 이 소식을 챙겨 듣고 내가 직접 바꿔 끼워야 합니다. 하지만 대부분의 초보는 그런 소식이 있는지도 모르고 지나가죠. 그 틈으로 도둑이 듭니다.

RDS는 이 보안 패치를 AWS가 알아서 적용해줍니다. 우리가 자는 사이에도 창고 자물쇠를 최신으로 유지해주는 셈이에요.

3) 장애 복구 — 창고가 무너져도 예비 창고가 있다

컴퓨터도 결국 기계라 언젠가 고장 납니다. 데이터베이스가 돌아가는 서버가 갑자기 죽으면, 직접 설치한 경우엔 서비스가 멈춥니다. RDS에는 멀티AZ(Multi-AZ)라는 옵션이 있는데, 쉽게 말해 "예비 창고를 다른 동네에 하나 더 두는 것"입니다. 본 창고가 무너지면 자동으로 예비 창고로 넘어가서 서비스가 계속됩니다. 이 개념은 뒤에서 다시 자세히 다룰게요.

👍 관리형(RDS)의 장점

  • 자동 백업 · 특정 시점 복구로 실수해도 안전
  • 보안 패치를 AWS가 대신 적용
  • 멀티AZ로 장애 시 자동 대체
  • 클릭 몇 번으로 설치 완료, 명령어 불필요
  • 모니터링 지표를 화면에서 바로 확인

👎 관리형(RDS)의 단점

  • 직접 설치보다 요금이 조금 더 든다
  • 세밀한 커스터마이즈에는 제약이 있다
  • AWS라는 특정 업체에 묶이는 느낌
  • 내부 동작을 100% 통제하진 못한다
초보 단계에서 단점은 사실상 체감되지 않습니다. 반대로 장점(백업·패치·복구)은 사고가 터지는 순간 여러분의 서비스를 통째로 살립니다. 그래서 저는 "일단 RDS로 시작하라"고 자신 있게 권합니다.

엔진 선택 — MySQL과 PostgreSQL 중에서

RDS를 만들 때 가장 먼저 고르는 게 엔진(engine)입니다. 엔진이라니 자동차 같죠? 실제로 비슷합니다. 같은 "데이터베이스"라는 자동차라도 안에 들어가는 엔진 종류가 여러 개예요. RDS는 MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 등 여러 엔진을 지원합니다. 이 중에서 초보에게는 딱 두 개만 기억하면 됩니다.

둘 다 무료(오픈소스)이고, 둘 다 초보가 쓰기에 훌륭합니다. "그래서 뭘 고르라는 거냐"고 물으신다면, 저는 이렇게 답합니다.

상황추천 엔진이유
처음이고 자료·예제가 많았으면 좋겠다MySQL사용자층이 가장 두터워 검색 자료가 압도적
내가 쓰려는 프레임워크/튜토리얼이 특정 엔진을 예로 든다그 엔진따라 하기가 훨씬 수월함
복잡한 데이터, 엄격한 규칙이 중요하다PostgreSQL기능이 풍부하고 표준에 충실
정말 모르겠다MySQL고민할 시간에 만드는 게 낫다
💡 김부장의 솔직한 조언: 초보 단계에서 MySQL이냐 PostgreSQL이냐는 성공을 가르지 않습니다. 둘 다 훌륭해요. 고민이 길어지면 그냥 MySQL로 시작하세요. 나중에 필요를 정확히 알게 됐을 때 갈아타도 늦지 않습니다. 지금은 "완성"이 목표입니다.

RDS 만들기 — 단계별 실전 가이드

자, 이제 진짜로 만들어봅시다. AWS 콘솔(관리 화면)에서 검색창에 RDS를 치고 들어간 뒤, [데이터베이스 생성] 버튼을 누르면서 시작합니다. 아래 순서를 그대로 따라오시면 됩니다. 화면에서 무엇을 누르고 무엇을 고르는지, 제가 실제로 했던 대로 적었어요.

1

엔진 선택하기

[표준 생성]을 고른 뒤 엔진 목록에서 MySQL(또는 PostgreSQL)을 클릭합니다. 아까 정한 대로요. 버전은 특별한 이유가 없으면 화면에 기본으로 잡힌 최신 안정 버전을 그대로 둡니다.

2

템플릿 고르기 — 프리 티어 / 개발

연습·학습 단계라면 [프리 티어]를 고르세요. 프리 티어는 일정 조건 안에서 무료로 쓸 수 있는 등급입니다. 프리 티어 대상이 아닌 계정이라면 [개발/테스트]를 고르면 됩니다. [프로덕션]은 실제 서비스용이라 비용이 큰 옵션이 켜지니, 지금은 피하세요.

3

인스턴스 크기 — db.t3.micro

데이터베이스가 돌아갈 컴퓨터의 "덩치"를 고르는 단계입니다. 연습이라면 가장 작은 급인 db.t3.micro 정도로 충분합니다. 작은 걸로 시작해도 나중에 손님이 늘면 더 큰 걸로 키울 수 있으니, 지금부터 큰 걸 고를 필요가 전혀 없어요.

4

자격 증명 — 관리자 아이디와 비밀번호

데이터베이스의 관리자 계정을 만드는 단계입니다. 마스터 사용자 이름(예: admin)과 비밀번호를 정합니다. 이건 창고의 마스터 열쇠예요. 절대 까먹으면 안 됩니다. 저는 비밀번호 관리 앱에 바로 저장하고, 따로 메모까지 해뒀습니다.

5

스토리지 설정

창고의 크기(저장 공간)를 정합니다. 연습이라면 기본값으로 충분합니다. 여기서 [스토리지 자동 조정] 옵션이 있으면 켜두는 걸 권해요. 공간이 부족해질 때 자동으로 늘려줘서, 갑자기 창고가 꽉 차 서비스가 멈추는 일을 막아줍니다.

6

연결 설정 — 퍼블릭 액세스 "끄기"

여기가 가장 중요한 단계입니다. "퍼블릭 액세스"라는 항목을 반드시 [아니요/끄기]로 두세요. 이걸 켜면 전 세계 인터넷에서 우리 데이터베이스가 보이게 됩니다. 창고 문을 길거리에 활짝 열어두는 셈이에요. 반드시 꺼야 합니다.

7

보안 그룹 설정

보안 그룹은 "누가 이 데이터베이스에 들어올 수 있는가"를 정하는 문지기입니다. 내 EC2(앱 서버)에서 오는 접속만 허용하도록 잡습니다. 이렇게 하면 외부에선 창고가 아예 안 보이고, 오직 내 앱만 데이터에 접근할 수 있어요. (자세한 방법은 아래 보안 섹션에서 한 번 더 짚습니다.)

8

생성 — 그리고 잠깐의 기다림

맨 아래 [데이터베이스 생성] 버튼을 누릅니다. 상태가 "생성 중"에서 "사용 가능"으로 바뀔 때까지 몇 분에서 십여 분 정도 걸립니다. 커피 한 잔 하고 오시면 됩니다. "사용 가능"으로 바뀌면 창고가 완성된 거예요!

💡 따라 하기 팁: 화면의 항목 이름은 AWS 업데이트에 따라 조금씩 바뀔 수 있습니다. 단어가 정확히 일치하지 않아도 당황하지 마세요. "엔진 → 템플릿 → 크기 → 계정 → 스토리지 → 연결 → 보안" 이라는 흐름의 순서만 기억하면 어떤 화면이 나와도 길을 잃지 않습니다.

전체 흐름을 한눈에

엔진 선택
MySQL
→
템플릿
프리 티어
→
크기·계정
micro·비번
→
연결·보안
퍼블릭 끄기
→
생성
사용 가능

백업 · 스냅샷 · 멀티AZ — 안전을 지키는 세 개념

RDS를 "안전한 창고"로 만들어주는 핵심 개념 세 가지를 조금 더 자세히 풀어볼게요. 이름은 어렵지만 비유로 보면 아주 단순합니다.

자동 백업 — 매일 밤 찍는 창고 사진

RDS는 설정해둔 시간(주로 새벽)에 자동으로 데이터베이스 상태를 백업합니다. 창고 안을 매일 밤 사진 찍어두는 것과 같아요. 문제가 생기면 "며칠 전 그 사진 상태로 되돌려줘"가 가능합니다. 앞서 말한 특정 시점 복구가 바로 이 백업 덕분에 되는 겁니다. 백업 보관 기간은 며칠에서 몇 주까지 정할 수 있어요.

스냅샷 — 내가 직접 찍는 기념 사진

자동 백업이 매일 밤 찍는 정기 사진이라면, 스냅샷(snapshot)은 내가 원할 때 손수 찍는 기념 사진입니다. 예를 들어 "데이터를 크게 손보기 직전"에 스냅샷을 하나 떠두면, 작업하다 망쳐도 그 스냅샷으로 통째로 되돌릴 수 있어요. 저는 뭔가 큰 변경을 하기 전엔 습관처럼 스냅샷부터 찍습니다. 마음이 아주 편해집니다.

멀티AZ — 다른 동네의 예비 창고

AZ는 'Availability Zone(가용 영역)'의 약자인데, 쉽게 말해 서로 다른 데이터센터 건물이라고 보면 됩니다. 멀티AZ를 켜면 AWS가 우리 데이터베이스를 두 개의 다른 건물에 하나씩 복제해서 운영합니다. 본 창고가 있는 건물에 정전이 나거나 장비가 고장 나도, 자동으로 다른 건물의 예비 창고로 넘어가 서비스가 끊기지 않아요.

다만 멀티AZ는 창고를 두 채 운영하는 셈이라 요금이 더 나갑니다. 그래서 연습 단계에서는 꺼두고, 실제 서비스로 사람들에게 공개할 때 켜는 걸 권합니다. "지금 이 서비스가 몇 분 멈춰도 큰일 나지 않는다"면 아직 필요 없고, "멈추면 안 된다"가 되는 순간이 오면 그때 켜세요.

개념한 줄 비유언제 쓰나
자동 백업매일 밤 찍는 정기 사진항상 켜둠 (기본)
스냅샷내가 원할 때 찍는 기념 사진큰 변경 작업 직전
멀티AZ다른 동네의 예비 창고실제 서비스 공개 후

엔드포인트로 앱과 연결하기

창고를 다 지었으니, 이제 우리 앱이 이 창고를 드나들 수 있게 연결해야 합니다. RDS를 만들면 엔드포인트(endpoint)라는 주소가 나옵니다. 이건 창고의 정확한 주소(도로명 주소)라고 생각하시면 됩니다. 앱이 "데이터 좀 꺼내줘"라고 말을 걸려면, 창고가 어디 있는지 주소를 알아야 하니까요.

엔드포인트는 이렇게 생겼습니다: 내DB이름.xxxxxx.ap-northeast-2.rds.amazonaws.com. 길고 복잡해 보이지만 그냥 주소일 뿐이에요. 앱을 연결하려면 이 주소 + 포트 번호 + 아이디 + 비밀번호 + 데이터베이스 이름, 이 다섯 가지를 앱의 설정에 넣어주면 됩니다.

🔑

필요한 정보 다섯 가지 모으기

① 엔드포인트(주소), ② 포트(MySQL은 보통 3306, PostgreSQL은 5432), ③ 마스터 아이디, ④ 비밀번호, ⑤ 데이터베이스 이름. 이 다섯 개가 앱과 창고를 잇는 열쇠 꾸러미입니다.

⚙️

앱 설정 파일에 넣기

앱의 환경 설정(대개 .env 같은 파일)에 위 다섯 값을 채웁니다. 비밀번호는 코드에 직접 적지 말고 반드시 환경 변수로 분리하세요. 실수로 남에게 공개되는 걸 막아줍니다.

✅

연결 확인

앱을 실행했을 때 데이터가 저장되고 다시 불러와지면 성공입니다. 이 연결이 되는 순간, "이제 진짜 서비스다" 싶은 느낌이 들었습니다.

앱과 데이터베이스가 처음 손을 잡는 그 순간이, 저는 이 여정에서 가장 짜릿했습니다. 화면 뒤에서 조용히 데이터가 쌓이기 시작하면, 그때부터는 정말 "내 서비스"가 됩니다.

가장 중요한 보안 포인트 — 창고를 길에 내놓지 마세요

이 글에서 딱 하나만 가져가셔야 한다면 바로 이겁니다. 데이터베이스는 절대 인터넷에 직접 열지 마세요. 회원 정보, 결제 정보가 담긴 창고를 온 세상이 볼 수 있게 열어두는 것만큼 위험한 일은 없습니다.

💡 가장 중요한 보안 포인트: 데이터베이스는 외부 인터넷에 직접 열지 마세요. 보안 그룹을 "내 EC2에서 오는 접속만 허용"으로 잡으면, 외부에선 보이지 않고 내 앱만 데이터에 접근합니다.

이걸 실제로 어떻게 하는지, 조금 더 풀어드릴게요. 우리 구조는 이렇게 생겼습니다. 손님(사용자)은 인터넷을 통해 우리 앱 서버(EC2)에 접속합니다. 앱 서버가 손님의 요청을 받아서, 그 뒤에 있는 데이터베이스(RDS)에서 데이터를 꺼내 옵니다. 즉 손님은 앱 서버까지만 오면 되고, 데이터베이스와 직접 대화할 필요가 전혀 없습니다.

사용자
인터넷
→
앱 서버 EC2
문 열림
→
데이터베이스 RDS
EC2만 허용

그래서 보안 그룹을 이렇게 설정합니다. 데이터베이스의 문지기(보안 그룹)에게 "내 EC2에서 오는 접속만 통과시켜라"라고 규칙을 주는 거예요. 그러면 외부의 어떤 해커가 우리 데이터베이스 주소를 알아내도, 문지기가 "너는 우리 EC2가 아니잖아" 하고 막아버립니다. 창고를 골목 안쪽 깊숙이 두고, 오직 우리 직원(EC2)만 아는 뒷문으로 드나들게 하는 것과 같습니다.

실전 팁을 하나 더 드리면, 보안 그룹 규칙에서 접속 허용 대상을 IP 주소가 아니라 "EC2의 보안 그룹" 자체로 지정하는 방법이 있습니다. 이렇게 하면 나중에 EC2의 IP가 바뀌어도 규칙을 다시 손댈 필요가 없어요. AWS가 알아서 "그 보안 그룹에 속한 서버면 통과"로 처리해주거든요. 초보에게도 오히려 이 방법이 더 편하고 안전합니다.

요금 감각 잡기 — 겁먹지 않되 방심하지 않기

많은 분이 클라우드 요금을 무서워합니다. "잘못 눌렀다가 몇백만 원 나왔다더라" 하는 괴담 때문이죠. 결론부터 말하면, 연습 단계에서 작은 인스턴스로 조심히 쓰면 요금은 걱정할 수준이 아닙니다. 다만 몇 가지 감각은 잡아두는 게 좋아요.

💡 요금 폭탄 예방: AWS에는 "예산(Budgets)"과 "결제 알림" 기능이 있습니다. "이번 달 이 금액을 넘으면 이메일로 알려줘"라고 걸어두세요. 저는 아주 작은 금액으로 알림을 설정해두고 마음 편히 연습했습니다. 구체적인 최신 요금은 반드시 결제 전에 AWS 공식 요금 페이지에서 직접 확인하세요. 요금 정책은 수시로 바뀝니다.

자주 묻는 질문 (FAQ)

Q. 저는 코딩을 정말 하나도 모릅니다. RDS를 만들 수 있을까요?
A. 네, 충분히 하실 수 있습니다. RDS 생성은 대부분 화면에서 클릭하고 값을 채우는 작업이에요. 위의 8단계를 그대로 따라오시면 됩니다. 명령어를 외울 필요는 없습니다. 저도 그 자리에서 시작했어요.

Q. MySQL과 PostgreSQL, 지금 잘못 고르면 나중에 큰일 나나요?
A. 아닙니다. 초보 단계에선 어느 걸 골라도 서비스를 완성하는 데 문제없습니다. 정 모르겠으면 자료가 많은 MySQL로 시작하세요. 나중에 정말 필요하면 데이터를 옮겨 갈 수도 있습니다.

Q. 프리 티어면 정말 공짜인가요?
A. "일정 조건과 사용량 안에서" 무료입니다. 큰 인스턴스를 쓰거나 프리 티어 범위를 넘기면 요금이 붙어요. 그래서 결제 알림을 걸어두는 걸 권합니다. 조건은 계정과 시점에 따라 다르니 공식 페이지 확인은 필수입니다.

Q. 비밀번호를 까먹었어요. 어떻게 하죠?
A. RDS 콘솔에서 데이터베이스를 "수정"해 마스터 비밀번호를 새로 지정할 수 있습니다. 다만 이런 일이 아예 안 생기게, 처음부터 비밀번호 관리 앱에 저장해두는 게 최선입니다.

Q. 퍼블릭 액세스를 켜야만 앱이 연결되는 거 아닌가요?
A. 아닙니다. 앱 서버(EC2)와 데이터베이스(RDS)가 같은 네트워크 안에 있으면, 퍼블릭 액세스를 꺼둔 상태에서도 내부 주소로 얼마든지 연결됩니다. 오히려 이게 정석이에요. 퍼블릭은 꺼두는 게 맞습니다.

Q. 나중에 데이터가 많아지면 창고를 키울 수 있나요?
A. 네. 인스턴스 크기도 키울 수 있고, 스토리지도 늘릴 수 있습니다. 작게 시작해서 필요할 때 키우는 게 정석입니다. 그러니 지금 큰 걸 고를 필요 없어요.

초보가 흔히 하는 실수 & 해결법

제가 직접 겪었거나, 주변에서 자주 본 실수들을 모았습니다. 미리 알아두면 여러분은 피해 가실 수 있어요.

실수 1 — 퍼블릭 액세스를 켜버린다

증상: 창고 문을 인터넷에 활짝 열어둔 상태. 해커의 자동 스캐너가 몇 시간 안에 문을 두드리기 시작합니다.
해결: RDS를 수정해 퍼블릭 액세스를 즉시 [끄기]로 바꾸고, 보안 그룹을 "내 EC2만 허용"으로 좁힙니다. 앞으로는 생성 단계에서부터 꺼두세요.

실수 2 — 마스터 비밀번호를 분실한다

증상: 데이터베이스에 접속하려는데 비밀번호가 기억 안 남. 애써 만든 창고에 정작 내가 못 들어감.
해결: 콘솔에서 마스터 비밀번호를 재설정할 수 있습니다. 근본 대책은 처음 만들 때 비밀번호 관리 앱에 바로 저장하는 것. 아이디·엔드포인트·포트도 함께 적어두세요.

실수 3 — 백업을 꺼두거나 신경 안 쓴다

증상: 잘 돌아가던 어느 날 데이터를 실수로 지웠는데, 되돌릴 백업이 없음.
해결: 자동 백업 보관 기간을 0이 아닌 값으로 두세요(기본적으로 켜져 있습니다). 큰 작업 전엔 스냅샷을 손수 하나 찍는 습관을 들이면 완벽합니다.

실수 4 — 연습용 데이터베이스를 켜둔 채 잊는다

증상: 며칠 뒤 결제 내역을 보고 깜짝. 안 쓰는데도 계속 돌아가며 요금이 쌓임.
해결: 연습이 끝나면 스냅샷을 떠둔 뒤 인스턴스를 중지하거나 삭제하세요. 결제 알림도 반드시 걸어두고요.

실수 5 — 비밀번호를 코드에 그대로 적는다

증상: 데이터베이스 접속 정보를 코드에 박아 넣고, 그걸 실수로 공개된 저장소에 올림. 열쇠를 대문에 테이프로 붙여둔 격.
해결: 접속 정보는 환경 변수(.env 등)로 분리하고, 그 파일은 공개 저장소에 올리지 않도록 제외 설정합니다.

완성 전 체크리스트

여기까지 오셨다면 거의 다 왔습니다. 창고 문을 닫기 전에 아래 항목을 하나씩 확인해보세요.

정리하며 — 데이터를 안전하게 맡긴다는 것

처음에 저를 멈칫하게 했던 "데이터베이스"라는 단어, 이제는 편해지셨나요? 다시 한 문장으로 정리하면, 데이터베이스는 앱이 잊으면 안 되는 것들을 넣어두는 창고이고, RDS는 그 창고를 AWS가 대신 관리해주는 렌탈 서비스입니다. 백업도, 보안 패치도, 장애 복구도 알아서 챙겨주니, 코딩이 서툰 우리에게는 이보다 든든한 파트너가 없어요.

그리고 딱 하나, 보안 그룹으로 창고를 인터넷에 직접 열지 않는 것. 이것만 지키면 여러분의 데이터는 안전합니다. 나머지는 위 8단계를 천천히 따라오시면 됩니다. 저도 처음엔 겁먹었지만, 막상 해보니 "아, 별거 아니었네" 싶었어요. 여러분도 분명 그러실 겁니다.

💡 다음 편 예고: 창고까지 안전하게 마련했으니, 이제 우리 서비스 주소창에 자물쇠(🔒)를 달아줄 차례입니다. 다음 편은 주소창에 자물쇠를 달아주는 SSL 인증서 이야기입니다. 손님이 안심하고 우리 앱을 쓸 수 있게 만드는, 신뢰의 마지막 조각이에요.

다음 편은 주소창에 자물쇠를 달아주는 SSL 인증서 이야기입니다. 오늘도 한 걸음, 진짜 서비스에 가까워지셨습니다. 수고하셨어요!

(2026년 7월 기준으로 작성했습니다. AWS 화면 구성과 요금 정책은 수시로 바뀌니, 실제 진행 전에는 반드시 AWS 공식 문서와 요금 페이지를 확인해 주세요.)

「코딩 몰라도 AI로 사주앱 만들기」기획부터 AWS 배포·도메인 연결까지 손잡고 가는 237쪽 실전 가이드
교보 → YES24 →
← 기술 블로그 목록으로