관계형 데이터베이스와 NoSQL, 내 앱에는 무엇이 맞을까요?

AI에게 데이터베이스를 연결해달라고 했더니 선택지가 쏟아집니다. Supabase, Firebase, MongoDB. 설명에는 SQL, PostgreSQL, NoSQL 같은 단어까지 따라붙어요. 데이터를 저장해야 한다는 건 알겠는데, 이번에는 어떤 데이터베이스를 골라야 하는지 막막해집니다.

아직 데이터베이스와 스프레드시트 중 무엇을 써야 할지 고민하고 있다면 두 도구의 역할과 선택 기준부터 확인해보세요. 이 글에서는 데이터베이스를 사용하기로 정한 다음의 선택을 다룹니다.

가장 자주 만나는 갈림길은 관계형 데이터베이스와 NoSQL이에요. 둘은 같은 데이터를 서로 다른 모양으로 정리합니다. 어느 한쪽이 항상 더 좋은 것은 아니고, 앱의 데이터가 어떻게 생겼고 그것을 어떻게 사용할지에 따라 선택이 달라져요.

먼저 이름부터 정확히 볼게요

흔히 “SQL과 NoSQL 중 무엇을 쓸까요?”라고 말하지만, 엄밀히는 조금 다른 종류의 단어를 비교하고 있어요.

• 관계형 데이터베이스는 데이터를 표로 나누고 서로 연결하는 저장 방식입니다.
• SQL은 관계형 데이터베이스에 데이터를 넣고 찾고 수정할 때 주로 사용하는 언어입니다.
• NoSQL은 관계형 표가 아닌 다른 모델을 사용하는 데이터베이스들을 묶어 부르는 큰 범주입니다.

NoSQL 안에도 문서형, 키-값형, 그래프형, 와이드 컬럼형처럼 여러 종류가 있어요. 이 글에서는 바이브코딩 입문자가 Firebase의 Cloud Firestore나 MongoDB를 접할 때 가장 자주 만나는 문서형 데이터베이스를 중심으로 비교할게요.

관계형 데이터베이스는 표를 나누고 연결해요

여러 사람이 사용하는 지출 관리 앱을 만든다고 해볼게요. 관계형 데이터베이스에서는 데이터를 성격에 따라 표로 나눌 수 있습니다.

사용자 표

카테고리 표

지출 표

지출 표에는 “민지”와 “식비”를 매번 적는 대신 각각의 id를 저장합니다. 필요할 때 세 표를 연결하면 “민지의 7월 식비”를 찾을 수 있어요. 이렇게 관련된 표의 행을 합쳐 조회하는 것을 조인(join)이라고 합니다.

정보를 한 곳에만 적어두면 이름이 바뀌었을 때도 한 군데만 수정하면 됩니다. 존재하지 않는 사용자의 지출이 생기지 않도록 규칙을 걸거나, 주문 생성과 재고 차감을 한 묶음으로 처리하는 것도 관계형 데이터베이스가 잘하는 일이에요.

Supabase는 프로젝트마다 PostgreSQL 데이터베이스를 제공합니다. 회원, 게시글, 주문, 예약처럼 서로 연결되는 정보가 많은 일반적인 웹서비스에서 자주 선택하는 방식이에요.

문서형 NoSQL은 함께 쓰는 데이터를 묶어요

문서형 데이터베이스는 한 건의 데이터를 JSON과 비슷한 문서로 저장합니다. 같은 지출 기록을 아래처럼 표현할 수 있어요.

{
  "id": "e1",
  "user": { "id": "u1", "name": "민지" },
  "category": "식비",
  "amount": 12000,
  "date": "2026-07-15",
  "memo": "점심 식사"
}

화면에 함께 보여줄 정보를 문서 하나에 묶으면 한 건을 그대로 꺼내 쓰기 편합니다. 어떤 지출에는 영수증 주소가 있고 다른 지출에는 없어도 되는 것처럼, 기록마다 필드가 조금씩 달라지는 데이터도 유연하게 담을 수 있어요.

Cloud Firestore는 문서를 컬렉션에 담는 NoSQL 문서 데이터베이스입니다. 문서 안에 객체나 배열을 넣고, 하위 컬렉션으로 계층을 만들 수도 있어요. MongoDB도 관련 데이터를 한 문서에 포함하거나 다른 문서의 id를 참조하는 방식을 모두 지원합니다.

다만 “NoSQL은 관계가 없다”는 뜻은 아니에요. 문서끼리 id로 연결할 수도 있습니다. 반대로 관계형 데이터베이스인 PostgreSQL도 JSON 데이터를 저장할 수 있어요. 둘의 경계가 칼로 자른 것처럼 완전히 나뉘는 것은 아닙니다.

차이는 저장보다 꺼내 쓰는 방식에서 커져요

데이터베이스 구조는 데이터를 어떻게 입력할지만 보고 정하면 안 됩니다. 앱이 어떤 질문을 자주 할지 함께 생각해야 해요.

지출 앱이 아래와 같은 질문을 자주 한다고 해볼게요.

• 사용자별 이번 달 지출 합계는 얼마인가요?
• 카테고리별 금액을 비교해 주세요.
• 특정 사용자의 지출만 최신순으로 보여주세요.
• 카테고리 이름을 바꾸면 기존 기록에도 반영해 주세요.

이처럼 여러 종류의 데이터를 연결하고, 조건을 바꾸어 집계하고, 같은 정보가 항상 일치해야 한다면 관계형 데이터베이스가 자연스럽습니다.

반대로 아래와 같은 상황이라면 문서형 NoSQL이 편할 수 있어요.

• 한 화면에서 문서 한 건을 통째로 읽는 일이 대부분입니다.
• 상품마다 사양 항목이 크게 달라지는 등 기록의 모양이 자주 달라집니다.
• 데이터가 부모와 자식으로 뚜렷하게 묶이고 함께 사용됩니다.
• 선택한 플랫폼의 문서 조회 방식이 앱의 기능과 잘 맞습니다.

핵심은 무엇을 저장하느냐보다 어떻게 읽고 바꿀 것이냐예요. 문서 구조를 정할 때도 앱이 자주 실행하는 작업과 함께 조회하는 데이터를 먼저 살펴봐야 합니다.

NoSQL이 무조건 더 빠른 것은 아니에요

“관계형 데이터베이스는 오래됐고 느리며, NoSQL은 최신이고 빠르다”는 식으로 이해하기 쉽지만 정확하지 않아요.

관계형 데이터베이스도 큰 서비스를 운영할 수 있고, NoSQL도 잘못 설계하면 여러 번 조회하거나 중복 데이터를 계속 수정해야 합니다. 속도와 확장성은 데이터 양, 인덱스, 조회 조건, 서버 구성, 제품 특성에 따라 달라져요.

“스키마가 없다”는 표현도 조심해야 합니다. 문서형 NoSQL은 기록마다 다른 필드를 허용할 수 있지만, 앱이 안정적으로 동작하려면 결국 어떤 필드가 들어오고 어떤 형태로 읽을지 규칙이 필요해요. 구조가 사라지는 것이 아니라 구조를 정하고 지키는 책임이 데이터베이스와 애플리케이션 사이에서 다르게 나뉘는 것에 가깝습니다.

잘 모르겠다면 관계형 DB부터 시작해도 괜찮아요

로그인한 사용자가 기록을 만들고, 검색하고, 수정하고, 통계를 보는 일반적인 웹앱이라면 관계형 데이터베이스가 무난한 출발점입니다. 특히 아래 항목이 많을수록 관계형 데이터베이스 쪽이 잘 맞아요.

• 회원, 주문, 상품, 예약처럼 서로 연결되는 정보가 많습니다.
• 결제 금액이나 재고처럼 데이터의 정확성이 중요합니다.
• 검색, 필터, 정렬, 합계 조건이 계속 늘어날 예정입니다.
• 앞으로 조회와 통계 조건이 어떻게 늘어날지 확실하지 않습니다.

그렇다고 모든 프로젝트를 관계형 데이터베이스로 만들어야 한다는 뜻은 아니에요. 이미 Firestore 중심으로 앱을 만들고 있거나, 독립적인 문서를 정해진 방식으로 읽는 기능이 중심이라면 문서형 데이터베이스가 더 단순할 수 있습니다. 한 서비스 안에서 관계형 데이터베이스와 검색 엔진, 캐시 같은 다른 저장소를 함께 쓰기도 해요.

처음부터 미래의 모든 상황을 맞히려고 할 필요는 없습니다. 지금 만들 기능을 가장 단순하고 안전하게 구현할 수 있는 쪽을 고르고, 실제 요구가 생겼을 때 구조를 다듬으면 됩니다.

바이브코딩에서는 제품명보다 요구사항을 말해주세요

AI에게 “SQL이 좋아, NoSQL이 좋아?”라고만 물으면 일반적인 장단점 목록이 돌아오기 쉬워요. 내 앱에서 저장할 데이터와 자주 할 작업을 함께 알려주면 훨씬 나은 답을 받을 수 있습니다.

여러 사용자가 함께 쓰는 지출 관리 앱을 만들 거야. 사용자, 지출, 카테고리를 저장해야 하고 월별·사용자별·카테고리별 합계를 자주 조회할 거야. 카테고리 이름을 바꾸면 기존 지출에도 반영되어야 해. 관계형 데이터베이스와 문서형 NoSQL 중 어느 쪽이 더 적합한지 이유와 데이터 구조 예시를 함께 제안해줘.

AI의 추천을 받은 다음에도 세 가지는 직접 확인하세요.

1. 서로 연결해야 하는 데이터가 무엇인가요?
2. 앱이 가장 자주 조회할 화면과 통계는 무엇인가요?
3. 반드시 함께 성공하거나 실패해야 하는 작업이 있나요?

이 질문에 답할 수 있다면 데이터베이스 이름을 모두 외우지 않아도 됩니다.

정리

• 관계형 데이터베이스는 데이터를 표로 나누고 id로 연결합니다.
• NoSQL은 여러 데이터 모델을 묶은 이름이며, 문서형은 함께 쓰는 정보를 문서로 저장합니다.
• 관계형 데이터베이스는 관계, 집계, 일관성이 중요한 앱에 자연스럽습니다.
• 문서형 NoSQL은 함께 읽는 데이터가 뚜렷하고 기록의 모양이 유연해야 할 때 편할 수 있습니다.
• NoSQL이 항상 더 빠르거나 관계형 데이터베이스가 항상 더 안전한 것은 아닙니다.
• 데이터의 모양뿐 아니라 자주 읽고 수정하는 방식까지 보고 선택해야 합니다.
• 판단이 어렵다면 일반적인 웹앱은 관계형 데이터베이스로 시작해도 괜찮습니다.

지난 글에서 앱이 무엇을 기억해야 하는지 정했다면, 이제 한 걸음 더 나아가 보세요. 그 기억들은 서로 어떤 관계이고, 앱은 그것을 어떤 모양으로 꺼내 쓸까요? 이 질문이 데이터베이스 선택의 출발점입니다.