Skip to main content

4장. 데이터베이스는 왜 필요한가

웹 서비스를 처음 만들 때 초보자가 가장 자주 하는 생각 중 하나는 이것이다.

"화면만 만들면 되는 것 아닌가요?"

처음엔 그렇게 느껴질 수 있다. 버튼도 있고, 입력창도 있고, 목록도 화면에 잘 보이면 뭔가 서비스가 완성된 것처럼 보인다. 그런데 딱 한 번 새로고침해 보면 현실이 드러난다. 방금 입력한 내용이 사라져 있다. 로그인 상태도 없어졌다. 작성한 글도 흔적 없이 사라진다.

이 순간 알게 된다. 서비스는 화면만으로는 살아 있지 않다. 기억이 있어야 진짜 서비스가 된다.

바로 그 기억을 맡는 곳이 데이터베이스다.

이 장에서는 데이터베이스를 어려운 기술 용어로 보지 않고, 웹 서비스가 왜 반드시 저장소를 필요로 하는지부터 차근차근 살펴보겠다. 핵심은 하나다. 서비스가 사용자와 데이터를 기억하기 시작하는 순간, 데이터베이스는 선택이 아니라 필수라는 점이다.

[1부] 데이터베이스는 왜 필요한가

[1부] 데이터베이스는 왜 필요한가

[1부] 데이터베이스는 왜 필요한가

데이터베이스를 가장 쉬운 말로 설명하면

데이터베이스는 아주 단순하게 말하면 서비스의 기억 창고다. 사용자가 남긴 정보, 서비스가 나중에 다시 써야 하는 정보, 여러 사람이 함께 봐야 하는 정보를 안전하게 보관하는 장소라고 생각하면 된다.

예를 들어 이런 정보들이 있다.

  • 회원의 이메일과 닉네임

  • 사용자가 작성한 글 제목과 내용

  • 각 글의 작성 날짜

  • 누가 어떤 글을 썼는지에 대한 연결 정보

  • 로그인한 사용자가 누구인지 확인하는 데 필요한 정보

이런 것들은 잠깐 화면에 보였다가 사라지면 안 된다. 오늘 가입한 회원이 내일도 로그인할 수 있어야 하고, 어제 쓴 글이 오늘도 보여야 하며, 수정한 내용이 새로고침 후에도 유지되어야 한다. 데이터베이스는 바로 이런 "계속 남아 있어야 하는 정보"를 맡는다.

메모장에 적어 두는 것과 비슷해 보일 수도 있다. 하지만 웹 서비스에서는 한 사람이 아니라 여러 사람이 동시에 쓰고, 찾고, 바꾸고, 지워야 한다. 그래서 단순한 메모장이 아니라 정리 잘 된 창고, 혹은 규칙 있는 기록 시스템이 필요하다.

왜 화면만으로는 부족할까

초보자가 만든 첫 화면은 꽤 그럴듯할 수 있다. 글쓰기 폼도 있고, 저장 버튼도 있고, 목록처럼 보이는 카드도 있다. 하지만 데이터베이스가 없으면 그 화면은 사실상 연극 무대의 소품에 가깝다. 보기에는 서비스 같지만, 실제로는 아무것도 기억하지 못한다.

예를 들어 사용자가 제목과 내용을 입력해 글을 작성했다고 해보자. 저장 버튼을 눌렀을 때 잠깐 화면에 목록이 보일 수는 있다. 하지만 그 정보가 데이터베이스에 저장되지 않았다면, 브라우저를 닫거나 새로고침하는 순간 사라질 수 있다.

이 상태는 화이트보드에 임시로 적어 둔 메모와 비슷하다. 지금 당장은 보이지만, 지워지면 끝이다. 서비스는 이렇게 운영될 수 없다.

웹 서비스가 서비스답게 보이려면 적어도 다음 질문에 답할 수 있어야 한다.

사용자가 남긴 정보가 다음에도 남아 있는가?

여러 사용자의 정보를 구분할 수 있는가?

필요할 때 원하는 정보만 다시 찾아올 수 있는가?

잘못된 정보나 오래된 정보를 수정하거나 삭제할 수 있는가?

이 질문에 "예"라고 답하게 해 주는 기반이 바로 데이터베이스다.

서비스가 '기억'을 갖는 순간

데이터베이스의 필요성은 어떤 거창한 서비스에서만 생기지 않는다. 오히려 아주 작은 서비스에서도 금방 드러난다.

예를 들어 우리가 만들 서비스에 회원가입과 로그인 기능이 있다고 해 보자. 그렇다면 서비스는 최소한 이것을 기억해야 한다.

"이 이메일로 가입한 사용자가 있다."

"이 사용자의 닉네임은 무엇이다."

"이 사람이 작성한 글은 이것들이다."

"이 글은 아직 삭제되지 않았다."

이 중 하나라도 기억하지 못하면 서비스가 흔들린다. 회원가입은 했는데 다음날 로그인할 수 없고, 글은 썼는데 작성자 정보가 없어지고, 수정은 했는데 예전 내용으로 돌아가 버린다.

즉, 데이터베이스가 필요한 시점은 생각보다 빠르다. 대단한 분석 기능이나 복잡한 통계가 없어도 된다. 사용자의 행동 결과를 나중에도 남겨야 하는 순간, 이미 데이터베이스가 필요하다.

데이터베이스가 하는 네 가지 기본 일

웹 서비스에서 데이터베이스는 보통 네 가지 기본 일을 한다. 개발에서는 이것을 흔히 CRUD라고 부른다. 영어 약자라 처음엔 낯설지만, 뜻은 아주 단순하다.

  • Create: 새 데이터를 만든다. 예를 들어 회원가입, 글 작성이 여기에 해당한다.

  • Read: 저장된 데이터를 읽는다. 글 목록 보기, 상세 페이지 보기, 검색 결과 보기 같은 일이다.

  • Update: 기존 데이터를 수정한다. 프로필 수정, 글 수정이 대표적이다.

  • Delete: 데이터를 지우거나 사용하지 않도록 처리한다. 글 삭제, 계정 삭제 등이 여기에 들어간다.

처음에는 이 네 가지가 너무 평범해 보여서 중요하지 않게 느껴질 수 있다. 하지만 웹 서비스의 대부분은 결국 이 네 가지 동작의 조합으로 이루어진다. 로그인도 사용자 정보를 읽는 일이고, 글 작성도 새 데이터를 만드는 일이며, 검색도 데이터를 읽되 조건을 붙여 가져오는 일이다.

그래서 데이터베이스를 이해한다는 것은 복잡한 기술을 외우는 것이 아니라, 서비스가 데이터를 어떻게 다루는지 이해하는 것에 가깝다.

예시로 보면 더 분명해진다

우리가 이 책에서 만들 서비스는 회원가입, 로그인, 글 작성, 수정, 삭제, 목록, 상세, 검색까지 포함된 작은 풀스택 웹 서비스다. 이 안에서 데이터베이스가 왜 필요한지 장면별로 보면 훨씬 선명해진다.

회원가입은 왜 저장이 꼭 필요할까

사용자가 회원가입을 한다는 것은 단순히 폼을 한 번 제출하는 행동이 아니다. 서비스 입장에서는 "이제 이 사람을 우리 서비스의 사용자로 기억하겠다"는 선언에 가깝다.

이때 데이터베이스가 없다면 가입 정보는 금방 사라진다. 그러면 사용자는 가입 직후에는 된 것처럼 보여도, 나중에 다시 로그인할 수 없다. 서비스는 누가 누구인지 전혀 기억하지 못하기 때문이다.

회원가입 기능이 제대로 동작하려면 적어도 이메일, 비밀번호를 안전하게 다룬 결과, 닉네임, 가입 시점 같은 정보가 저장되어야 한다. 그래야 다음에 로그인 요청이 왔을 때 "이 사용자는 실제로 존재하는 사람인가?"를 확인할 수 있다.

즉, 회원가입 기능의 핵심은 화면이 아니라 기억이다.

글 작성 기능은 왜 데이터베이스 없이는 반쪽일까

사용자가 글을 작성하는 장면을 떠올려 보자. 제목을 쓰고, 내용을 적고, 저장 버튼을 누른다. 프론트엔드에서는 입력창과 버튼을 보여 줄 수 있다. 저장 완료 메시지도 띄울 수 있다.

하지만 데이터베이스가 없다면, 그 글은 어디에 남을까?

잠깐 화면에 보이는 것만으로는 충분하지 않다. 목록 페이지에서도 보여야 하고, 상세 페이지에서도 열려야 하며, 나중에 다시 접속해도 남아 있어야 한다. 작성자와 연결도 되어야 하고, 수정이나 삭제도 가능해야 한다.

결국 글 작성 기능은 "텍스트를 입력하는 기능"이 아니라 "텍스트를 서비스의 기억 속에 남기는 기능"이다. 이 차이를 이해하면 데이터베이스가 왜 중심인지 바로 보인다.

글 목록과 상세 페이지는 결국 읽기 기능이다

많은 초보자는 목록 화면을 프론트엔드 기능으로만 생각한다. 물론 화면으로 보여 주는 쪽은 프론트엔드다. 하지만 보여 줄 재료를 꺼내 오는 역할은 데이터베이스와 백엔드가 맡는다.

글 목록 페이지가 열릴 때 서비스는 저장된 글들을 읽어 와야 한다. 최신 글부터 보여 줄 수도 있고, 특정 조건으로 정렬할 수도 있다. 상세 페이지는 특정 글 하나를 정확히 찾아와야 한다.

이때 데이터베이스가 없다면 목록도, 상세도 사실상 진짜 기능이 아니다. 하드코딩된 예시 데이터만 보여 주는 전시 화면에 머물게 된다.

서비스가 실제로 살아 움직이려면, 화면 뒤에 "읽을 수 있는 데이터"가 있어야 한다.

수정과 삭제는 왜 더 중요할까

초보자는 보통 "저장만 되면 된 것 아닌가?"라고 생각하기 쉽다. 하지만 실제 서비스는 저장보다 그다음이 더 중요할 때가 많다.

사람은 오타를 낸다. 생각이 바뀌기도 한다. 잘못 올린 글을 지우고 싶을 수도 있다. 서비스가 이런 현실을 받아들이려면 수정과 삭제가 가능해야 한다.

데이터베이스가 없다면 수정은 사실상 새로 쓰는 척만 하는 동작이 되고, 삭제도 화면에서 잠깐 안 보이게 가리는 수준에 머무를 수 있다. 반면 데이터베이스가 있으면 특정 데이터를 찾아 내용을 바꾸거나, 삭제 상태로 바꾸거나, 실제로 제거할 수 있다.

여기서 중요한 것은 데이터베이스가 단순히 "넣는 곳"이 아니라는 점이다. 찾고, 바꾸고, 없애는 일까지 포함해 데이터의 생애 전체를 관리하는 곳이다.

검색 기능도 결국 데이터베이스와 연결된다

사용자가 글이 많아진 서비스에서 검색창을 쓰기 시작하면, 데이터베이스의 역할은 더 분명해진다. 검색은 겉으로 보면 입력창 하나와 버튼 하나일 뿐이지만, 실제로는 저장된 수많은 데이터 중에서 조건에 맞는 것만 골라내는 일이다.

예를 들어 제목에 특정 단어가 들어간 글만 보고 싶을 수 있다. 작성자 기준으로 보고 싶을 수도 있고, 최신순으로 보고 싶을 수도 있다. 이런 기능은 데이터가 체계적으로 저장되어 있어야 가능하다.

데이터베이스는 단순히 "보관"만 하는 것이 아니라, 필요할 때 원하는 방식으로 꺼낼 수 있게 정리하는 역할도 한다. 그래서 서비스 규모가 조금만 커져도 데이터베이스의 존재감이 갑자기 커진다.

엑셀이나 메모장으로는 안 될까

처음에는 이런 질문이 자연스럽다.

"그냥 엑셀처럼 표로 저장하면 되는 것 아닌가요?"

작은 실험 정도라면 가능할 수도 있다. 하지만 웹 서비스는 곧 여러 문제를 만난다.

첫째, 여러 사용자가 동시에 접근한다. 한 사람이 파일을 고치는 동안 다른 사람도 데이터를 읽고 쓰려고 할 수 있다. 이때 충돌 없이 다뤄야 한다.

둘째, 사용자별로 권한이 다르다. 내 글만 수정할 수 있어야 하고, 로그인한 사람만 특정 기능을 써야 한다. 단순 파일 저장만으로는 이런 규칙을 다루기 어렵다.

셋째, 데이터 사이의 연결이 필요하다. 사용자와 글, 글과 댓글, 작성자와 권한처럼 서로 연결된 정보가 많아진다. 서비스는 데이터를 따로따로 저장하는 것이 아니라 관계까지 함께 관리해야 한다.

넷째, 검색과 정렬, 조건 조회가 반복된다. "내가 쓴 글만", "최신 글만", "검색어가 포함된 글만" 같은 요청이 많아질수록 단순 파일 방식은 금방 버거워진다.

즉, 데이터베이스는 단순히 멋진 기술이라서 쓰는 것이 아니다. 웹 서비스가 실제로 굴러가려면 자연스럽게 필요해지는 도구다.

데이터베이스는 '아무 데나 저장'이 아니라 '구조 있게 저장'이다

데이터베이스가 중요한 또 하나의 이유는, 정보를 제멋대로 쌓아 두지 않게 해 주기 때문이다.

예를 들어 글 데이터를 저장한다고 해 보자. 제목, 내용, 작성자, 작성일, 수정일 같은 정보가 있을 수 있다. 이런 정보가 일정한 구조 없이 뒤죽박죽 저장되면 나중에 꺼내 쓰기가 매우 힘들어진다.

반대로 구조를 정해 두면 훨씬 다루기 쉬워진다. 어떤 정보가 꼭 필요한지, 어떤 값은 비어 있으면 안 되는지, 어떤 데이터가 누구와 연결되는지 정리할 수 있기 때문이다.

초보자에게는 이것이 다소 딱딱하게 들릴 수 있다. 하지만 실전에서는 엄청 중요하다. 서비스가 커질수록 코드는 AI가 어느 정도 도와줄 수 있어도, 데이터를 어떤 모양으로 기억할지는 사람이 이해하고 결정해야 하기 때문이다.

잘 정리된 냉장고를 생각해 보자. 음식이 보관되어 있을 뿐 아니라, 어디에 무엇이 있는지 찾기 쉽고, 상한 것을 버리기도 쉽고, 필요한 재료를 바로 꺼내기도 쉽다. 데이터베이스도 비슷하다. 중요한 것은 저장 자체보다 정리된 저장이다.

데이터베이스가 없으면 생기는 문제들

데이터베이스의 필요성은 있을 때보다 없을 때 더 선명하게 드러난다.

데이터베이스가 없으면 사용자는 매번 처음 방문한 사람처럼 취급될 수 있다. 로그인 상태를 안정적으로 유지하기 어렵고, 작성한 글이 남지 않으며, 서비스가 여러 사람의 정보를 구분하기도 힘들어진다.

조금 더 현실적으로 말하면 이런 문제가 생긴다.

  • 가입은 되는데 다음날 다시 로그인할 수 없다.

  • 글은 써지는데 새로고침하면 사라진다.

  • 목록 페이지가 실제 데이터가 아니라 예시 화면에 머문다.

  • 내 글과 남의 글을 구분하기 어렵다.

  • 검색, 정렬, 수정, 삭제가 불안정해진다.

이쯤 되면 서비스는 더 이상 서비스가 아니라 데모 화면에 가까워진다. 잠깐 보여 주는 발표용 화면은 만들 수 있어도, 실제 사용자가 쓰는 서비스는 되기 어렵다.

서버와 데이터베이스는 어떻게 함께 일할까

이전 장에서 우리는 프론트엔드와 백엔드의 역할을 구분했다. 데이터베이스는 여기서 백엔드의 중요한 동료로 움직인다.

사용자가 화면에서 어떤 행동을 하면, 보통 프론트엔드가 그 요청을 서버로 보낸다. 서버는 그 요청이 가능한지 판단하고, 필요하면 데이터베이스에서 읽거나 저장한다. 그리고 결과를 다시 프론트엔드로 돌려준다.

예를 들어 글을 저장할 때는 이런 흐름이 생긴다. 사용자가 제목과 내용을 입력한다. 프론트엔드가 서버에 저장 요청을 보낸다. 서버는 로그인 여부나 입력값을 확인한다. 문제가 없으면 데이터베이스에 글을 기록한다. 저장이 끝나면 서버가 성공 응답을 보내고, 프론트엔드는 완료 메시지를 보여 준다.

중요한 점은 데이터베이스가 혼자 서비스 전체를 움직이는 것은 아니라는 것이다. 데이터베이스는 기억을 맡고, 서버는 규칙을 확인하며, 프론트엔드는 사용자가 다루기 쉽게 보여 준다. 셋이 함께 움직일 때 비로소 서비스가 된다.

초보자가 꼭 알아야 할 감각: 데이터는 화면보다 오래 산다

처음 개발을 배우면 화면에 더 눈이 간다. 버튼 색, 카드 모양, 간격, 문구가 먼저 보인다. 당연하다. 눈에 보이기 때문이다.

하지만 서비스의 본체는 종종 화면보다 데이터에 더 가깝다. 화면은 바뀔 수 있다. 디자인도 바뀔 수 있다. 버튼 위치도 달라질 수 있다. 그런데 사용자의 계정 정보, 작성한 글, 저장된 기록은 계속 이어져야 한다.

그래서 실전에서는 이런 말이 꽤 중요하다.

화면은 바뀌어도 데이터는 남아야 한다.

이 감각이 생기면 서비스를 보는 눈이 달라진다. "이 버튼을 누르면 뭐가 보일까?"에서 끝나지 않고, "이 행동의 결과가 어디에 저장되고, 나중에 어떻게 다시 불러와질까?"를 함께 생각하게 된다.

바로 그 순간부터 초보자는 단순히 화면을 따라 만드는 사람이 아니라, 서비스 구조를 이해하는 사람으로 한 단계 올라간다.

이 책에서 데이터베이스를 너무 어렵게 보지 않아도 되는 이유

데이터베이스라고 하면 많은 사람이 겁부터 먹는다. 표, 쿼리, 스키마, 관계, 인덱스 같은 낯선 말이 줄줄이 떠오르기 때문이다. 물론 나중에는 이런 개념도 조금씩 만나게 된다. 하지만 지금 단계에서는 다 외울 필요가 없다.

지금 가장 중요한 것은 이 한 가지다.

데이터베이스는 서비스가 기억하기 위해 필요하다.

그리고 그 기억은 대체로 저장하기, 읽기, 수정하기, 삭제하기라는 기본 동작으로 다뤄진다. 이 뼈대만 이해해도 앞으로 배우게 될 로그인, 글 작성, 목록 조회, 검색, 권한 처리 같은 기능이 훨씬 덜 어렵게 느껴진다.

우리는 뒤에서 Supabase 같은 도구를 사용해 실제 데이터베이스를 다루게 될 것이다. 하지만 도구를 먼저 외우는 것보다, 왜 필요한지 감각을 잡는 것이 훨씬 중요하다. 이유를 이해한 뒤에 도구를 배우면, 기능 하나하나가 훨씬 자연스럽게 연결된다.

AI와 협업할 때도 데이터베이스 이해가 필요한 이유

이 책의 핵심은 AI와 함께 서비스를 완성하는 것이다. 그런데 데이터베이스를 모르면 AI가 만들어 준 결과를 제대로 판단하기가 어렵다.

예를 들어 AI가 글 작성 기능을 만들어 줬다고 하자. 화면은 멀쩡해 보일 수 있다. 입력도 되고, 저장 버튼도 있다. 하지만 실제로 데이터베이스에 기록되지 않는다면 그 기능은 반만 완성된 것이다.

또 어떤 경우에는 목록 화면이 예시 데이터만 보여 주고 있을 수도 있다. 겉으로는 서비스처럼 보여도, 실제 저장된 내용을 읽어 오는 구조가 아니라면 나중에 금방 막힌다.

그래서 AI와 협업할 때도 이런 질문을 할 수 있어야 한다.

"이 데이터는 어디에 저장되나요?"

"새로고침 후에도 남나요?"

"작성자 정보와 연결되나요?"

"수정과 삭제까지 가능한 구조인가요?"

이 질문을 던질 수 있다는 것 자체가 이미 큰 힘이다. 데이터베이스를 안다는 것은 단지 기술 하나를 배우는 것이 아니라, AI가 만든 결과물이 진짜 서비스인지 구분하는 눈을 갖는 일이기도 하다.

이 장의 핵심 정리

데이터베이스는 웹 서비스의 기억 창고다. 회원 정보, 글 내용, 작성자 정보, 검색 대상 데이터처럼 서비스가 나중에도 기억해야 하는 것을 안전하게 저장하고 다시 꺼내 쓸 수 있게 해 준다.

웹 서비스가 진짜 서비스가 되는 순간은 화면이 예쁜 때가 아니라, 사용자의 행동 결과를 기억하기 시작할 때다. 회원가입이 남아 있고, 로그인할 수 있고, 글이 저장되고, 다시 읽히고, 수정되고, 삭제될 수 있어야 한다. 이때 데이터베이스는 선택이 아니라 필수다.

또 데이터베이스는 단순 보관함이 아니다. 데이터를 만들고, 읽고, 수정하고, 삭제하는 흐름의 중심이며, 여러 사용자와 여러 기능이 얽힌 서비스를 질서 있게 운영하게 해 주는 기반이다.

앞으로 우리가 만들 풀스택 서비스에서도 데이터베이스는 아주 자주 등장할 것이다. 글 하나를 쓰는 일, 사용자 한 명이 가입하는 일, 검색 결과 하나를 보여 주는 일 뒤에도 늘 데이터베이스가 있다.

이제 웹 서비스의 큰 그림은 조금 더 또렷해졌다. 브라우저가 보여 주고, 서버가 처리하고, 데이터베이스가 기억한다. 그리고 그 기억이 있어야 서비스는 비로소 어제와 오늘이 이어지는 살아 있는 공간이 된다.

다음 장에서는 이런 흐름 속에서 AI가 개발을 실제로 어떻게 도와주는지를 살펴보겠다.

책 목록

바이브 코딩으로 완성하는 첫 풀스택 웹 서비스

전체 목차 보기

이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.

틸노트는 사용자가 AI를 활용해 노트를 쉽게 작성하거나 편집할 수 있는 서비스입니다.

AI 스퀘어 단톡방에 함께해요

AI 활용과 틸노트 사용 팁을 나누는 오픈채팅방입니다. 입장 비밀번호는 tilnote입니다.

참여하기