사이드 프로젝트마다 DB를 새로 만들어야 할까?

새로운 사이드 프로젝트를 시작하면 사용자 정보와 게시글, 설정을 저장할 DB가 필요하다. 프로젝트가 하나 늘었으니, DB도 하나 더 만드는 게 자연스럽게 느껴진다.

그런데 서비스마다 따로 만든다는 건 어디까지 따로 만든다는 뜻일까? 테이블만 구분하는 것과 데이터베이스를 나누는 것, DB 서버까지 새로 운영하는 건 비용도 관리 범위도 다르다.

이미 운영 중인 DB에 테이블 몇 개를 더 만들면 충분할까? 아니면 새로운 DB를 만들어야 할까? 새 서비스에 필요한 데이터의 경계와, 별도로 유지할 서버의 범위를 어떻게 정할지가 궁금해졌다.

이 질문을 구체적으로 살펴보기 위해 AWS RDS for PostgreSQL을 예로 들었다. 한 DB 안에서 서비스별 스키마를 나누는 구조와 서울 리전 비용을 비교하고, 무엇을 따로 관리할 수 있고 무엇을 함께 감당하는지 살펴봤다.

여러 서비스가 한 서버의 자원을 함께 쓰는 모습. 구체적인 스키마 구성은 아래에서 살펴봤다.

01. DB를 어디까지 나눠야 할까?

먼저 DB 서버와 그 안에 있는 데이터베이스를 구분할 필요가 있다. 서버에는 CPU와 메모리, 저장 공간이 있고, 데이터베이스는 그 안에서 데이터를 저장하고 접근하는 단위다.

PostgreSQL은 한 서버 안에 여러 데이터베이스를 둘 수 있다. RDS에서는 인스턴스가 이 서버의 운영 단위에 해당한다. 서비스별 DB를 따로 만드는 것과, 서비스마다 서버를 하나씩 새로 만드는 것은 다른 선택이다.

한 DB 안에서 스키마로 나누는 구조

스키마는 DB 안에서 테이블을 묶는 공간이다. 예를 들어 app_db 안에 pogam, service_b, service_c 스키마를 두면, 같은 users라는 이름의 테이블도 pogam.users와 service_b.users로 구분할 수 있다.

예시 구성: 서버와 DB는 함께 쓰고, 서비스별 테이블은 스키마로 구분한다.

이 구조에서 서비스 계정은 같은 DB에 접속한다. 대신 각 계정이 사용할 스키마와 테이블의 범위를 권한으로 제한한다. 스키마 이름을 다르게 만든 것만으로 접근까지 자동으로 분리되는 건 아니다.

02. RDS로 계산해본 한 달 비용

작은 서비스 세 개를 운영한다고 가정해보자. 서비스마다 DB 서버를 따로 둘 때와, 서버 하나의 DB 안에 스키마 세 개를 둘 때를 비교했다. 예시로 사용한 구성은 서울 리전 ap-northeast-2의 RDS for PostgreSQL, Single-AZ, 온디맨드다. 한 달은 30일, 720시간으로 계산했다.

각 서비스를 따로 운영할 때는 db.t4g.micro에 gp3 20GiB씩, 합쳐서 운영할 때는 gp3 60GiB를 할당한다고 가정했다. 총 저장 공간을 같게 두고, 인스턴스 구성에 따른 차이를 보려는 계산이다. 이 계산에서 비용 차이를 만드는 건 스키마의 개수가 아니라 서버의 개수와 사양이다.

서울 리전의 시간당 단가는 micro $0.025, small $0.051, medium $0.102다. gp3 저장 공간은 할당 용량 기준으로 월 GiB당 $0.131을 적용했다.

2026년 10월 1일 확인한 공개 요금으로 계산한 예상 비용이며 실제 청구액은 아니다. 세금, 무료 혜택, 할인 약정, CPU 크레딧 추가 요금, 추가 백업·전송·공인 IPv4·모니터링 비용은 제외했다. 표준 지원 기간의 PostgreSQL과 기본 gp3 성능을 가정했다. 표는 동등한 성능을 보장하는 비교가 아니다.

예를 들어 micro 세 개의 컴퓨팅 비용은 0.025 × 720 × 3 = $54다. 저장 공간은 따로 두든 합치든 총 60GiB로 가정했으므로 0.131 × 60 = $7.86으로 같다.

세 서비스가 micro 한 개 안에서 충분히 동작한다면 기본 비용은 월 $36 줄어든다. small 한 개가 필요하면 절감액은 $17.28로 줄어든다. medium까지 올려야 한다면 오히려 따로 운영하는 경우보다 $19.44 더 나온다.

micro는 메모리가 1GiB, small은 2GiB, medium은 4GiB다. micro 세 개의 메모리를 합치면 3GiB지만, 그게 공유 small 한 개의 2GiB와 같은 조건은 아니다. CPU의 기본 성능과 저장 장치의 처리 여유도 달라진다.

합치는 것 자체가 비용을 줄여주는 건 아니었다. 남는 자원을 함께 쓸 수 있을 때 비용이 줄어든다.

03. 서비스 세 개가 서버 하나에 들어갈까?

데이터가 적다는 것만으로 판단하기는 어렵다. 몇 MB의 테이블이라도 쿼리가 복잡하거나 연결이 많으면 서버 자원을 쓸 수 있다.

연결 풀부터 생각해볼 수 있다. 서비스마다 서버 프로세스 세 개를 띄우고, 각 프로세스가 최대 10개의 DB 연결을 유지한다면 세 서비스의 설정상 최대 연결은 90개다. 사용자가 많지 않아도 서버 수와 풀 설정에 따라 연결 수는 커질 수 있다.

스키마를 세 개로 나눠도 인스턴스의 연결 한도가 세 배가 되지는 않는다. 각 서비스의 풀을 따로 보고 끝낼 게 아니라, 전체 합계를 봐야 한다.

여기서 예로 든 t4g는 CPU를 잠깐 많이 쓰는 부하에 대응하는 버스터블 인스턴스다. 기본 성능을 넘어서는 사용이 지속되면 Unlimited 모드의 CPU 크레딧 추가 요금이 생길 수 있다. 저렴한 시간당 단가만으로 비용을 판단하기 어려운 이유다.

그래서 비용 표 다음에는 부하를 확인하는 과정이 필요하다. 세 서비스가 평소에 사용하는 자원뿐 아니라, 한 서비스가 무거운 작업을 할 때 나머지 서비스의 응답 시간이 어떻게 변하는지도 살펴봐야 한다.

04. 스키마와 권한은 함께 나눠야 한다

스키마는 서비스별 테이블을 정리하는 단위다. 접근 범위를 나누려면 서비스별 접속 계정을 만들고, 해당 스키마의 USAGE 권한과 필요한 테이블의 읽기·쓰기 권한을 별도로 설정해야 한다.

예를 들어 포갬의 서비스 계정은 pogam 스키마의 필요한 테이블만 사용할 수 있도록 구성하는 식이다. 여러 서비스에 같은 관리자 계정을 사용하면 권한으로 나눈 경계가 사라진다. 서비스 코드에서 사용하는 계정과 테이블을 변경하는 관리 계정도 구분할 수 있다.

테이블 이름 앞에 스키마를 쓰지 않았을 때는 search_path가 어느 스키마를 먼저 찾을지 결정한다. 하지만 이 설정은 접근 권한을 제한하는 장치가 아니다. public 스키마와 PUBLIC에 부여된 권한도 확인하고, 앞으로 생성할 테이블의 기본 권한까지 맞춰둬야 한다.

접근을 잘 제한해도 성능까지 독립되는 건 아니다. 한 서비스가 CPU나 메모리, 디스크를 많이 쓰면 다른 서비스도 영향을 받을 수 있다. 인스턴스 재시작과 일부 유지보수 작업의 영향도 함께 받는다.

따로 운영하면 비용이 늘지만, 한 서비스의 운영 작업이 다른 서비스에 미치는 범위를 좁힐 수 있다. 이 차이는 비용 표만으로 드러나지 않는다.

05. RDS의 복구는 서버 단위다

RDS의 자동 백업은 개별 DB만 따로 백업하는 방식이 아니라 인스턴스 전체를 대상으로 한다. 시점 복원을 실행하면 원본을 그대로 둔 채, 해당 시점의 새 인스턴스가 만들어진다.

예를 들어 오후 2시에 A 서비스의 데이터를 잘못 삭제했고, 오후 2시 20분에는 B 서비스에서 정상적인 데이터가 추가됐다고 해보자.

오후 2시 이전으로 복원한 인스턴스를 모든 서비스에 연결하면 A의 삭제는 되돌릴 수 있다. 하지만 B도 오후 2시 20분에 추가된 데이터를 사용하지 못하게 된다. 원본 데이터는 남아 있어도, 전체 서비스의 연결을 과거 상태로 바꾸는 선택이 되는 것이다.

필요한 스키마의 데이터를 복원 인스턴스에서 따로 꺼내 현재 운영 DB에 반영하는 방법도 있다. 다만 어떤 데이터만 되돌릴지, 그동안 발생한 정상적인 변경과 어떻게 맞출지는 별도로 결정해야 한다.

스키마를 나눈다고 인스턴스 단위의 복구 과정까지 각각 독립되는 건 아니었다. 서비스마다 필요한 복구 기준이 다르면 인스턴스 분리의 가치도 커진다.

Single-AZ와 Multi-AZ의 차이도 별도로 봐야 한다. 대기 인스턴스 하나를 두는 Multi-AZ 구성은 가용성을 높이는 선택이지만, 서비스별 자원과 권한을 각각 분리하는 선택은 아니다. 위 비용 표에 고가용성 구성 비용까지 포함됐다고 해석하면 안 된다.

06. 초기에는 함께 쓰고, 성장하면 나누기

서비스가 성장하면 해당 스키마의 데이터를 별도 DB 서버로 옮기는 구성을 검토할 수 있다.

AI로 서비스를 만들기 쉬워진 만큼, 여러 아이디어를 작은 서비스로 만들어 반응을 확인하기도 좋아졌다. 이때마다 DB 서버를 새로 운영하면, 아직 서비스를 검증하는 단계부터 고정 비용이 쌓인다.

운영하는 사람이 같고 사용량이 적은 초기 서비스들이라면, 한 DB 서버의 여유 자원을 함께 쓰는 방식에 비용 효율성이 있어 보인다. 예를 들어 RDS 인스턴스 하나의 DB 안에 서비스별 스키마를 두고, 계정별 접근 범위를 구분하는 구성이다. 어느 정도 규모가 되기 전까지는 이렇게 운영하는 것도 충분히 검토할 만하다.

서비스가 잘되기 시작해 더 많은 자원이 필요해지거나, 다른 서비스와 성능·복구 요구가 달라지면 그때 해당 스키마의 데이터를 별도 DB와 서버로 옮길 수 있다. 실제 사용량을 보고 필요한 사양을 정할 수 있고, 성장한 서비스에 비용을 더 투자할 근거도 분명해진다.

다만 나중에 옮기기 쉽도록 서비스별 스키마와 계정, 테이블 변경 이력은 처음부터 구분해두는 게 좋다. 다른 스키마의 테이블을 참조하는 외래 키나 뷰, 공용 함수가 많아지면 옮길 때 함께 풀어야 하는 연결도 많아진다. 스키마만 따로 내보낸다고 이런 의존성까지 모두 따라오는 건 아니므로, 실제 복원과 전환도 미리 확인할 필요가 있다.