데이터베이스가 뭐길래
데이터를 '어디에 어떻게'
담을까

시작하기 전에 마음가짐 하나만 부탁드릴게요. 이 글은 어려운 명령어를 외우는 글이 아닙니다. '데이터베이스라는 게 대체 뭐고, 왜 이런 걸 만들었나'를 그림으로 이해하는 글이에요. 그러니 중간에 짧은 예시 몇 줄이 안 외워져도 절대 조급해하지 마세요. 원리만 잡으면 세부 문법은 나중에 필요할 때 검색해서 붙여 쓰면 그만입니다. 저도 코딩을 늦게 시작한 사람이라, 처음엔 이 '데이터베이스'라는 단어 앞에서 한참을 주눅 들어 있었거든요.

여러분, 우리가 매일 쓰는 앱들을 한번 떠올려 보세요. 쇼핑몰에서 장바구니에 물건을 담고, 배달 앱에서 주문을 넣고, 인스타그램에 사진을 올리고, 은행 앱에서 잔액을 확인하고. 이 모든 앱이 겉으로는 다 달라 보이지만, 안에서 하는 일은 놀랍도록 비슷합니다. 결국 '데이터를 어딘가에 저장하고, 필요할 때 다시 꺼내 보여 주는 일'이에요. 주문 정보를 저장하고, 로그인할 때 회원 정보를 꺼내고, 좋아요 숫자를 저장했다가 다시 보여 주고. 앱이란 결국 이 저장과 꺼내기의 반복입니다.

그럼 그 데이터는 대체 '어디에' 담길까요? 그리고 '어떻게' 담아야 수천만 명이 동시에 써도 안 뒤죽박죽될까요? 바로 이 질문에 대한 대답이 오늘의 주인공, 데이터베이스(Database, 줄여서 DB)입니다. 이름은 거창하지만 겁먹지 마세요. 이 글을 다 읽고 나면 "아, 이거 결국 잘 정리된 엑셀 창고 이야기였네" 하고 웃으시게 될 거예요.

저도 처음 이 단어를 들었을 땐 벽이 느껴졌습니다. 개발을 늦게 시작한 사람 입장에선 이런 영어 약자가 자꾸 튀어나오면 "아, 나는 역시 이쪽 사람이 아닌가 보다" 하고 위축되거든요. 그런데 막상 뚜껑을 열어 보니, 데이터베이스는 대단한 마법이 아니라 '물건을 잘 정리해서 보관하는 방법'에 대한 이야기였습니다. 우리 모두 냉장고를 정리하고, 옷장을 칸별로 나누고, 서류를 파일철에 꽂아 본 적이 있잖아요? 그 '정리 본능'을 데이터에 옮겨 놓은 것뿐입니다. 그러니 이미 여러분 안에 데이터베이스를 이해할 감각이 다 있어요.

데이터베이스는 '아주 잘 정리된 창고이자 도서관'입니다. 물건(데이터)을 그냥 쌓아 두는 게 아니라, 어디에 무엇이 있는지 정해진 자리에 착착 정리해 두는 거예요. 그래서 수백만 개 중에서도 원하는 하나를 순식간에 꺼낼 수 있습니다. 엑셀을 써 보셨다면, 데이터베이스는 그 엑셀이 어른이 된 모습이라고 생각하시면 딱 맞습니다.

1. 데이터베이스가 대체 뭔가요? — 엑셀과 뭐가 다른가

제가 데이터베이스를 처음 이해하게 된 계기가 바로 엑셀이었습니다. 엑셀 아시죠? 가로세로 칸이 쫙 그려진 표에 이름·전화번호·주소를 정리해 본 경험, 다들 한 번쯤 있으실 거예요. 사실 여러분은 이미 아주 작은 데이터베이스를 만들어 본 셈입니다. 데이터베이스도 결국 이 '표에 데이터를 정리해 담는다'는 발상에서 출발하니까요.

정식으로 말하면, 데이터베이스는 많은 양의 데이터를 체계적으로 저장하고, 원할 때 빠르고 정확하게 꺼내 쓸 수 있도록 관리하는 시스템입니다. 그리고 이 데이터베이스를 실제로 굴려 주는 소프트웨어를 DBMS(데이터베이스 관리 시스템)라고 불러요. 뒤에 나올 MySQL, PostgreSQL 같은 이름들이 바로 이 DBMS입니다. 창고에 비유하면, 데이터베이스는 '창고 자체'이고 DBMS는 '그 창고를 관리하는 관리인 아저씨'인 셈이죠. 일상 대화에서는 이 둘을 뭉뚱그려 그냥 "데이터베이스"라고 부르는 경우가 많으니, 지금은 구분에 너무 신경 쓰지 않으셔도 됩니다.

도서관에 비유하면 더 선명해집니다. 도서관에 책이 수십만 권 있어도 우리가 원하는 책을 금방 찾을 수 있는 이유는, 책이 분류 기호에 따라 정해진 자리에 꽂혀 있고, 검색대가 있기 때문이죠. 만약 책을 그냥 바닥에 마구 쌓아 뒀다면 원하는 한 권을 찾는 데 하루가 걸릴 겁니다. 데이터베이스가 하는 일이 딱 이거예요. 데이터를 아무렇게나 쌓아 두는 게 아니라 정해진 규칙에 따라 자리를 잡아 두고, 빠르게 찾을 수 있는 장치까지 마련해 둡니다. '저장'만 하는 게 아니라 '잘 정리해서 빠르게 꺼내는 것'까지가 데이터베이스의 일이라는 걸 기억해 주세요.

그럼 "엑셀 쓰면 되지, 왜 굳이 데이터베이스라는 걸 따로 배워요?"라는 질문이 자연스럽게 나옵니다. 아주 좋은 질문이에요. 엑셀은 사람 몇 명이 소소하게 쓰기엔 훌륭하지만, 진짜 서비스를 감당하기엔 몇 가지 결정적인 약점이 있습니다. 하나씩 볼게요.

첫째, 동시 접속이 안 됩니다. 엑셀 파일 하나를 여러 명이 동시에 열어서 저장하려다 "누가 먼저 저장했네, 덮어썼네" 하고 싸운 경험 있으시죠? 그런데 쇼핑몰은 수천 명이 동시에 주문을 넣습니다. 엑셀로는 이걸 절대 감당 못 해요. 데이터베이스는 수많은 사람이 동시에 읽고 써도 데이터가 안 꼬이도록 처음부터 설계돼 있습니다.

둘째, 속도입니다. 회원이 백만 명인데 그중에서 '홍길동'을 찾으려고 엑셀을 위에서 아래로 훑으면 한참 걸립니다. 데이터베이스는 뒤에 나올 '인덱스'라는 장치 덕분에 백만 건 중에서도 눈 깜짝할 새에 찾아냅니다.

셋째, 안정성과 규칙입니다. 엑셀은 실수로 셀 하나를 지워도 아무도 안 말려요. 하지만 데이터베이스는 "전화번호 칸엔 숫자만", "이 회원은 반드시 존재해야만 주문을 넣을 수 있음" 같은 규칙을 강제할 수 있습니다. 데이터가 엉망이 되는 걸 시스템이 알아서 막아 주는 거죠.

넷째, 연결(관계)입니다. 엑셀에서도 시트를 여러 장 만들 수 있지만, 시트끼리 데이터를 정교하게 이어 붙이는 건 무척 번거롭습니다. 데이터베이스는 '회원 표'와 '주문 표'를 번호표로 자연스럽게 연결해서, "3번 회원이 넣은 주문 전부"를 한 번에 뽑아낼 수 있어요. 뒤에서 다룰 '조인'이 바로 이 이야기입니다. 데이터가 많아지고 종류가 늘어날수록 이 연결 능력의 가치가 폭발적으로 커집니다.

제 경험을 하나 들려드릴게요. 처음 작은 서비스를 만들 때 저는 겁이 나서 그냥 익숙한 엑셀 파일로 회원을 관리했습니다. 사용자가 열 명 남짓일 땐 아무 문제가 없었어요. 그런데 입소문이 나서 사용자가 몇백 명으로 늘자, 파일 열기가 느려지고, 두 명이 동시에 저장하면 데이터가 사라지고, 어디에 뭐가 있는지 저조차 헷갈리기 시작했습니다. 그때 마음먹고 데이터베이스로 옮겼는데, 진작 할 걸 그랬다 싶더라고요. "엑셀로 버틸 수 있을 때까지 버티다가 아프게 옮기느니, 처음부터 데이터베이스로 시작하는 게 낫다"는 걸 몸으로 배웠습니다.

2. 없으면 어떤 고통이 생길까요

데이터베이스가 왜 필요한지는, 없다고 상상해 보면 확 와닿습니다. 배달 앱을 데이터베이스 없이 엑셀 파일 하나로 운영한다고 쳐 볼게요.

점심시간, 주문이 몰립니다. 손님 A가 주문을 넣는 순간, 손님 B도 같은 파일을 열어 저장합니다. 두 사람의 주문 중 하나가 감쪽같이 사라집니다. 사장님은 "분명 주문받았는데 왜 없지?" 하고 당황하고, 손님은 "돈 냈는데 왜 안 와요?" 하고 화가 납니다. 엑셀은 이 동시 상황을 감당할 수 없거든요.

또 이런 일도 생깁니다. 회원이 십만 명이 되니 엑셀 파일이 너무 무거워져서 열기만 해도 몇 분이 걸립니다. '홍길동' 회원을 찾으려고 스크롤을 내리다 보면 손님은 이미 앱을 껐죠. 게다가 누군가 실수로 전화번호 칸에 이름을 적고, 가격 칸에 글자를 넣어도 아무도 못 막습니다. 데이터가 서서히 오염되다가 어느 날 통째로 신뢰할 수 없게 됩니다.

여기서 특히 무서운 게 '돈이 걸린 데이터'입니다. 은행 앱에서 A가 B에게 만 원을 보낸다고 해 봅시다. 이 일은 사실 두 단계예요. A 잔액에서 만 원을 빼고, B 잔액에 만 원을 더하는 것. 그런데 만약 첫 단계만 성공하고 둘째 단계에서 앱이 뻗어 버리면? A 돈은 사라졌는데 B는 못 받은 대참사가 벌어집니다. 데이터베이스는 이런 걸 막으려고 "두 단계를 하나로 묶어서, 둘 다 성공하거나 둘 다 없던 일로 되돌린다"는 안전장치를 갖고 있습니다. 이걸 '트랜잭션'이라고 부르는데, 지금은 이름보다 "돈처럼 중요한 일은 중간에 어그러지지 않게 통째로 처리해 준다"는 느낌만 챙기시면 됩니다. 엑셀로는 절대 흉내 낼 수 없는 능력이에요.

이런 고통을 정면으로 해결하려고 나온 게 데이터베이스입니다. 동시에 몰려도 안 꼬이고, 아무리 많아도 빠르게 찾고, 이상한 값은 처음부터 못 들어오게 막고, 돈처럼 중요한 일은 중간에 어그러지지 않게 통째로 처리하는 것. 우리가 매일 쓰는 앱들이 순식간에 정확하게 반응하는 건, 그 뒤에서 데이터베이스가 묵묵히 이 일을 해 주고 있기 때문입니다.

3. 앱에서 데이터가 흐르는 큰 그림

본격적인 개념으로 들어가기 전에, 데이터가 앱 안에서 어떻게 흐르는지 전체 그림을 한 번 그려 볼게요. 여러분이 앱에서 버튼 하나를 눌렀을 때, 화면 뒤에서는 대략 이런 여정이 벌어집니다.

예를 들어 쇼핑몰에서 '주문하기'를 누르면, 그 요청이 서버로 가고, 서버는 데이터베이스에 "이 주문을 저장해 줘"라고 부탁하고, 데이터베이스가 저장을 마치면 그 결과가 다시 화면으로 돌아와 "주문 완료!"가 뜨는 거예요. 여기서 앱과 서버가 서로 부탁을 주고받는 이 '창구' 이야기는 API가 뭐길래 글에서 따로 자세히 풀어 드립니다. 오늘은 이 그림의 맨 끝, 데이터베이스에만 집중할게요.

여기서 짚어 둘 게 하나 있어요. 데이터베이스는 보통 화면(앱)과 직접 이야기하지 않습니다. 반드시 서버라는 중간 관리자를 거치죠. 왜 그럴까요? 데이터베이스에는 회원의 소중한 정보가 다 들어 있는데, 만약 사용자 화면이 데이터베이스와 직접 연결돼 있으면 누구나 마음대로 그 정보를 헤집을 수 있게 되거든요. 그래서 은행 창구 직원(서버)을 반드시 거치게 하고, 손님이 금고(데이터베이스)에 직접 손을 못 대게 하는 겁니다. 이 구조를 알아 두면, 왜 앱을 만들 때 데이터베이스 접속 정보를 화면 쪽 코드에 절대 넣으면 안 되는지도 자연스럽게 이해가 됩니다.

4. 표·행·열·기본키 — 데이터베이스의 뼈대

이제 데이터베이스 안이 어떻게 생겼는지 들여다볼 차례입니다. 좋은 소식은, 이게 정확히 엑셀 생김새랑 똑같다는 거예요. 딱 네 개의 단어만 기억하면 됩니다. 표, 행, 열, 기본키. 엑셀에 빗대어 하나씩 볼게요.

표(테이블, Table)는 엑셀의 '시트' 한 장에 해당합니다. 예를 들어 '회원 표', '주문 표', '상품 표'처럼 종류별로 표를 따로 만들어요. 데이터베이스 안에는 이런 표가 여러 장 들어 있습니다.

행(로우, Row)은 표의 가로 한 줄, 즉 데이터 한 건입니다. 회원 표에서 행 하나는 '회원 한 명'이에요. 홍길동 씨 정보 한 줄, 김영희 씨 정보 한 줄, 이렇게요.

열(컬럼, Column)은 표의 세로 한 줄, 즉 항목의 종류입니다. 회원 표라면 '이름', '이메일', '가입일' 같은 게 각각 열이에요. 모든 행이 이 열들을 공통으로 갖습니다.

마지막으로 기본키(Primary Key)가 조금 새로운 개념인데, 이것도 어렵지 않아요. 기본키는 각 행을 구별해 주는 고유한 번호표입니다. 우리 주민등록번호나 학번을 떠올리시면 됩니다. 이름이 같은 '홍길동'이 두 명 있어도, 번호표(기본키)가 다르면 시스템은 둘을 확실하게 구별할 수 있어요. 그래서 데이터베이스는 보통 행마다 겹치지 않는 고유 번호를 하나씩 붙여 둡니다. 아래 회원 표를 보면 감이 확 오실 거예요.

보세요, 이름은 1번과 3번이 똑같이 '홍길동'이지만 id(기본키)가 1과 3으로 다르기 때문에 완전히 다른 사람으로 취급됩니다. 이 '겹치지 않는 번호표' 하나가 데이터를 정확하게 다루는 출발점이에요. 여기 나온 이 표 한 장이 바로 데이터베이스의 '표'이고, 가로 한 줄이 '행', 세로 한 줄(id·이름·이메일·가입일)이 '열'입니다. 정말 엑셀이랑 똑같죠?

한 가지 더 알아 두면 좋은 게, 각 열에는 '어떤 종류의 값이 들어가는지'를 미리 정해 둔다는 점입니다. 이걸 '자료형'이라고 부르는데, 어렵게 생각하지 마세요. '이름 칸엔 글자만', '가입일 칸엔 날짜만', '나이 칸엔 숫자만' 들어가도록 칸마다 성격을 정해 두는 겁니다. 옷장에 '양말 서랍', '셔츠 서랍'을 정해 두면 아무거나 뒤섞이지 않는 것과 같아요. 이렇게 열마다 종류를 정해 두기 때문에, 실수로 전화번호 칸에 이름을 넣으려 하면 데이터베이스가 "그건 안 됩니다" 하고 막아 줍니다. 엑셀은 이런 걸 안 막아 주죠. 이 작은 차이가 데이터를 반듯하게 지켜 주는 큰 힘이 됩니다.

그래서 데이터베이스로 무언가를 만들 때 가장 먼저 하는 일이 바로 '어떤 표를 만들고, 그 표에 어떤 열을 둘까'를 설계하는 것입니다. 이걸 '스키마 설계'라고 부르는데, 집을 짓기 전에 도면을 그리는 일과 똑같아요. 회원 표엔 이름·이메일·가입일 열을 두고, 상품 표엔 상품명·가격·재고 열을 두고… 이렇게 미리 그림을 그려 두면 나중에 데이터가 아무리 쌓여도 흐트러지지 않습니다. 처음엔 이 설계가 어렵게 느껴지지만, "필요한 정보를 종류별로 표에 나눠 담는다"는 상식으로 접근하면 누구나 할 수 있습니다.

5. SQL vs NoSQL — 어렵지 않게 갈라 보기

데이터베이스를 공부하다 보면 SQL과 NoSQL이라는 두 단어를 반드시 만나게 됩니다. 알파벳만 봐도 벌써 어질어질하시죠? 그런데 이것도 비유로 풀면 정말 별거 아닙니다.

먼저 SQL(관계형 데이터베이스)은 앞에서 본 그 '표(엑셀 시트)'를 여러 장 만들어 서로 연결해 쓰는 방식입니다. 회원 표, 주문 표, 상품 표를 따로 만들어 두고, "이 주문은 몇 번 회원이 넣은 것"처럼 표끼리 관계를 맺어 주는 거예요. 그래서 '관계형'이라는 이름이 붙었습니다. 여기서 SQL은 이 표들에게 "3번 회원의 주문을 다 보여 줘" 하고 말을 거는 일종의 질문 언어예요. 정해진 틀(칸)이 명확해서 데이터가 반듯하게 정돈되는 게 장점입니다.

반대로 NoSQL은 표의 반듯한 칸에 얽매이지 않는 '자유로운 서랍'이라고 생각하시면 됩니다. 어떤 서랍엔 물건이 세 개, 어떤 서랍엔 다섯 개가 들어 있어도 상관없어요. 데이터마다 담긴 항목이 조금씩 달라도 되고, 형태가 자유롭습니다. 대신 반듯한 표만큼 엄격하게 관계를 맺어 관리하긴 어렵죠. 그 대신 어마어마하게 많은 데이터를 빠르게, 유연하게 담는 데 강합니다.

둘 중 무엇이 더 좋다는 게 아닙니다. 용도가 다를 뿐이에요. 반듯하게 규칙이 중요한 데이터(회원·주문·결제)엔 SQL이, 형태가 제각각이고 양이 폭발적으로 많은 데이터(로그·채팅·실시간 데이터)엔 NoSQL이 잘 어울립니다. 아래 장단점을 나란히 볼게요.

참고로 위 비교는 편의상 둘 다 '장점' 칸으로 나란히 놓았습니다. 어느 하나가 나쁜 게 아니라, 상황에 맞는 도구를 고르는 것이 핵심이라는 뜻이에요. 표로도 한 번 더 정리해 드릴게요.

조금 더 감을 드리자면 이렇습니다. SQL은 깔끔하게 칸이 그어진 서류 캐비닛이에요. 모든 서류가 정해진 양식에 맞춰 들어가야 하니 처음엔 조금 빡빡하지만, 그만큼 나중에 찾고 대조하기가 정확합니다. 은행 계좌나 주문 내역처럼 "단 한 건도 틀리면 안 되는" 데이터에 잘 맞아요. 반면 NoSQL은 큰 상자를 여러 개 두고 물건을 툭툭 던져 넣는 방식에 가깝습니다. 양식이 자유로우니 빠르고 편하지만, 대신 "이 상자엔 뭐가 들었더라?"를 사람이 더 신경 써야 합니다. 실시간 채팅 메시지나 접속 기록처럼 양이 어마어마하고 형태가 조금씩 다른 데이터에 잘 어울립니다.

실제 서비스에서는 이 둘을 함께 쓰는 경우도 아주 많습니다. 예를 들어 회원과 결제 정보는 SQL에 반듯하게 담고, 접속 로그나 잠깐 쓰고 버릴 임시 데이터는 NoSQL에 담는 식이죠. 그러니 "둘 중 하나만 정답"이라는 생각은 접어 두셔도 됩니다. 요리할 때 칼과 가위를 상황에 맞게 골라 쓰듯, 데이터의 성격에 맞는 도구를 고르는 것뿐이에요.

입문자라면 우선 SQL(관계형)부터 익히시길 권합니다. 표라는 개념이 엑셀과 똑같아 직관적이고, 세상 대부분의 서비스가 여전히 관계형 데이터베이스 위에서 돌아가거든요. NoSQL은 필요해질 때 그때 배워도 전혀 늦지 않습니다.

6. 대표 제품, 한 줄씩만 알고 가기

이름들이 워낙 자주 나오다 보니, 얼굴 정도는 익혀 두면 좋습니다. 지금 다 이해할 필요 전혀 없어요. "아, 이런 게 있구나" 정도면 충분합니다. 대표 선수 다섯을 한 줄씩만 소개할게요.

이 이름들이 헷갈릴 땐 이렇게 그림으로 기억해 보세요. MySQL과 PostgreSQL은 제대로 지은 큰 창고 건물입니다. 서버에 설치해서 여러 사람이 함께 쓰는, 진짜 서비스를 떠받치는 튼튼한 집이에요. SQLite는 손에 들고 다니는 작은 상자 하나예요. 파일 딱 하나가 데이터베이스라서 가볍게 실험하기 좋습니다. MongoDB는 칸막이 없는 큰 서랍장이고, Redis는 자주 쓰는 물건을 잠깐 올려 두는 책상 위 바구니라고 생각하시면 됩니다. Redis는 워낙 빨라서, 다른 데이터베이스 앞에 두고 "자주 찾는 답을 미리 꺼내 두는 심부름꾼"으로 함께 쓰는 경우가 많아요.

제가 입문자에게 가장 자주 권하는 건 SQLite입니다. 별도 설치나 서버 없이 파일 하나로 데이터베이스를 만들어 볼 수 있어서, 겁먹지 않고 표·행·열을 직접 만져 보기에 이만한 게 없거든요. 손에 익으면 그때 MySQL이나 PostgreSQL로 넘어가면 됩니다. 참고로 이런 제품들의 정확한 최신 버전이나 성능 수치는 계속 바뀌니, 세부 숫자는 각 제품 공식 문서에서 확인하시는 걸 권합니다. 이 글에서 가격이나 버전 같은 숫자를 일부러 적지 않은 것도, 그런 값은 늘 변하기 때문이에요.

7. CRUD — 데이터로 하는 일은 딱 네 가지

데이터베이스로 하는 일은 사실 아무리 복잡해 보여도 크게 네 가지로 요약됩니다. 이 네 글자를 묶어 CRUD(크러드)라고 불러요. 우리가 수첩 하나를 쓸 때 하는 일이랑 완전히 똑같습니다.

수첩에 새 연락처를 적고, 필요할 때 찾아보고, 번호가 바뀌면 고쳐 적고, 필요 없어지면 지우고. 여러분이 평생 해 온 이 네 가지 행동이 그대로 데이터베이스의 CRUD입니다. 어떤 대단한 앱도 결국 이 네 가지의 조합일 뿐이에요.

그럼 데이터베이스에게 이 네 가지를 어떻게 시킬까요? 아까 잠깐 나온 SQL이라는 질문 언어로 말을 겁니다. 겁먹지 마시고, 짧은 예시 하나를 말로 풀어 볼게요. 문법을 외우는 게 아니라 "아, 사람 말이랑 비슷하네" 하고 느끼시면 됩니다.

예를 들어 회원 표에서 이름이 '홍길동'인 사람을 찾고 싶다면, 이렇게 씁니다.

SELECT * FROM members WHERE name = '홍길동';

이 한 줄을 말로 풀면 이렇습니다. "members(회원) 표에서(FROM) 이름이 홍길동인(WHERE) 데이터를 전부(*) 골라 보여 줘(SELECT)." 놀랍게도 영어 문장 순서 그대로예요. SELECT는 '읽기(R)'에 해당합니다.

하나 더 볼게요. 새 회원을 한 명 추가하는 '만들기(C)'는 이렇게 씁니다.

INSERT INTO members (name, email) VALUES ('김영희', 'younghee@example.com');

이것도 말로 풀면 "members 표에 이름과 이메일을 넣는데(INSERT INTO), 그 값은(VALUES) 김영희와 younghee@example.com이야"가 됩니다. 어때요, 생각보다 사람 말과 닮았죠?

수정과 삭제도 잠깐만 맛보고 갈게요. 3번 회원의 이메일을 바꾸고 싶다면 UPDATE members SET email = 'new@example.com' WHERE id = 3; 이렇게 씁니다. "members 표에서 id가 3인 행의 이메일을 새 값으로 고쳐라"라는 뜻이에요. 여기서 가장 조심할 점이 있습니다. 뒤의 WHERE id = 3을 깜빡 빼먹으면, 데이터베이스는 모든 회원의 이메일을 똑같이 바꿔 버립니다. 삭제도 마찬가지예요. DELETE FROM members WHERE id = 3;은 3번만 지우지만, WHERE를 빼면 전체가 사라집니다. 그래서 수정·삭제를 할 땐 "어디를(WHERE) 정확히 짚었는가"를 꼭 두 번 확인하는 습관이 중요합니다. 이건 초보뿐 아니라 베테랑도 가끔 저지르는 아찔한 실수예요.

정리하면, 세세한 문법은 지금 안 외우셔도 됩니다. "데이터에 하는 일은 결국 CRUD 네 가지고, SQL이라는 언어로 사람 말처럼 시키며, 수정·삭제 땐 '어디를' 짚었는지 꼭 확인한다"는 큰 그림만 챙기세요. 이 감각만 있으면 나머지는 필요할 때 찾아 쓰면 됩니다.

8. 관계와 조인 — 표끼리 연결하기

이제 관계형 데이터베이스가 왜 '관계형'인지 진짜 이유를 볼 차례입니다. 조금 새로운 개념이지만, 이것도 상식으로 이해할 수 있어요.

쇼핑몰을 생각해 봅시다. 주문 정보를 어떻게 저장할까요? 초보자는 흔히 이렇게 생각합니다. "주문 표에다 회원 이름, 전화번호, 주소, 주문한 상품, 가격을 전부 한 줄에 다 적자!" 그런데 이러면 문제가 생깁니다. 한 사람이 백 번 주문하면 그 사람의 이름·전화번호·주소가 백 번 중복돼서 저장되거든요. 게다가 그 사람이 이사 가서 주소를 바꾸면, 백 줄을 전부 고쳐야 합니다. 상상만 해도 끔찍하죠.

그래서 관계형 데이터베이스는 이렇게 나눕니다. '회원 정보는 회원 표에, 주문 정보는 주문 표에' 따로 저장해요. 그리고 주문 표에는 회원의 모든 정보를 다 적는 대신, '몇 번 회원이 주문했는지' 회원의 번호표(기본키)만 살짝 적어 둡니다. 이렇게 다른 표를 가리키는 번호를 외래키(Foreign Key)라고 불러요. 아래처럼요.

보세요, 주문 표에는 회원 이름을 안 적고 member_id(1번, 2번)만 적혀 있죠? 1번이 누군지는 앞의 회원 표를 보면 '홍길동'이라는 걸 알 수 있습니다. 이렇게 두 표를 번호표로 연결해 두면, 회원 정보는 회원 표 딱 한 곳에서만 관리하면 되고 주문 표는 깔끔해집니다. 이게 관계형 데이터베이스의 우아함이에요.

그런데 화면에 주문 목록을 보여 줄 땐 "홍길동 님이 텀블러를 주문했습니다"처럼 이름이 필요하잖아요? 이때 두 표를 다시 합쳐서 보는 것을 조인(Join)이라고 합니다. "주문 표의 member_id와 회원 표의 id가 같은 것끼리 짝지어 붙여 줘"라고 시키면, 데이터베이스가 두 표를 순간적으로 합쳐 '홍길동 - 텀블러'를 만들어 보여 줍니다.

이 방식의 장점을 다시 한번 짚어 볼게요. 홍길동 씨가 이사를 가서 주소를 바꿨다고 합시다. 정보를 표별로 나눠 뒀으니, 회원 표에 있는 홍길동 씨의 주소 딱 한 줄만 고치면 끝입니다. 그가 과거에 넣은 백 건의 주문은 손댈 필요가 없어요. 주문 표엔 애초에 주소가 안 적혀 있고 번호표만 있으니까요. 만약 모든 걸 한 표에 몰아넣었다면 백 줄을 다 고쳐야 했겠죠. 이렇게 같은 정보를 딱 한 곳에서만 관리하게 만드는 것이 관계형 설계의 핵심 정신입니다. 중복을 줄이면 실수도 줄고, 데이터도 항상 최신으로 유지됩니다.

9. 인덱스 — 책 뒤의 '찾아보기'

이제 데이터베이스가 어떻게 수백만 건 중에서 눈 깜짝할 새에 원하는 걸 찾아내는지, 그 비밀을 볼게요. 답은 인덱스(Index)인데, 이건 두꺼운 책을 떠올리면 단번에 이해됩니다.

500쪽짜리 전문 서적에서 '데이터베이스'라는 단어가 나온 곳을 찾는다고 해 봅시다. 방법은 두 가지예요. 첫째, 1쪽부터 500쪽까지 눈으로 다 훑는 것. 둘째, 책 맨 뒤의 '찾아보기(색인)'를 펼쳐 "데이터베이스 … 42쪽, 118쪽"을 확인하고 바로 그 쪽으로 넘어가는 것. 당연히 두 번째가 비교도 안 되게 빠르죠.

데이터베이스의 인덱스가 바로 이 '책 뒤의 찾아보기'입니다. 자주 검색하는 열(예: 이메일)에 인덱스를 만들어 두면, 데이터베이스는 전체를 처음부터 훑지 않고 이 색인을 통해 곧장 원하는 데이터로 점프합니다. 그래서 백만 건 중에서도 특정 이메일을 순식간에 찾아내는 거예요.

이 인덱스 덕분에 우리가 검색창에 뭔가를 입력하면 그렇게 빨리 결과가 뜨는 겁니다. 만약 인덱스가 없다면, 회원이 백만 명인 서비스에서 로그인 한 번 하는 데도 데이터베이스가 백만 줄을 다 훑어야 하니 한참을 기다려야 할 거예요. 우리가 평소 '당연하다'고 느끼는 그 빠른 반응 속도 뒤에는, 이렇게 미리 만들어 둔 색인이 조용히 일하고 있습니다.

"그럼 모든 열에 다 인덱스를 걸면 되겠네요?"라고 물으실 수 있는데, 여기에도 균형이 필요합니다. 책에 찾아보기 페이지를 늘리면 책이 두꺼워지고, 내용이 바뀔 때마다 색인도 다시 손봐야 하잖아요. 인덱스도 똑같아서, 너무 많으면 저장 공간을 더 먹고 데이터를 새로 넣거나 고칠 때 색인 갱신 부담이 생깁니다. 그래서 정말 자주 검색하는 열에만 선별해서 거는 게 요령입니다. 지금은 "인덱스 = 빠른 검색을 위한 책 색인"이라는 비유 하나만 챙기셔도 충분해요. 실제로 인덱스를 어디에 걸지는 서비스가 커지면서 차차 고민하게 되니, 지금은 '이런 게 있어서 빠르구나'만 알면 됩니다.

10. 백업과 보안 — 절대 가볍게 넘기면 안 되는 것

여기서부터는 기술이라기보다 책임에 가까운 이야기입니다. 데이터베이스에는 회원의 이름·이메일·전화번호 같은 개인정보가 담깁니다. 그래서 초보 시절부터 반드시 몸에 배어야 하는 습관이 두 가지 있어요. 백업과 보안입니다.

먼저 백업. 데이터베이스는 여러분 서비스의 심장입니다. 그런데 서버가 고장 나거나, 실수로 데이터를 통째로 지우거나, 해킹을 당하면 그 심장이 멈춥니다. 회원 데이터가 날아가면 서비스는 그날로 끝이에요. 그래서 주기적으로 데이터의 사본(백업)을 안전한 다른 곳에 떠 두는 것은 선택이 아니라 필수입니다. 중요한 문서를 원본만 두지 않고 복사본을 다른 서랍에 넣어 두는 것과 똑같아요.

백업에서 한 가지 꼭 강조하고 싶은 게 있습니다. 바로 "백업을 떠 두는 것"과 "백업이 진짜 되살아나는지 확인하는 것"은 다른 일이라는 점이에요. 정기적으로 사본을 떠 왔는데, 막상 사고가 나서 열어 보니 파일이 깨져 있거나 텅 비어 있어서 절망하는 경우가 실제로 있습니다. 그래서 가끔은 백업 파일로 정말 데이터가 복구되는지 시험해 보는 것이 좋습니다. 소화기를 사 두는 것만으로 끝이 아니라, 가끔 멀쩡히 작동하는지 확인해 두는 것과 같아요. 그리고 백업 사본은 원본과 다른 장소에 두세요. 같은 서버에 뒀다가 그 서버가 통째로 망가지면 원본도 사본도 함께 사라지니까요.

다음은 보안인데, 초보자가 가장 많이, 그리고 가장 위험하게 저지르는 실수가 하나 있습니다. 바로 비밀번호를 있는 그대로(평문) 저장하는 것입니다. 회원 표에 비밀번호를 1234abcd처럼 눈에 보이는 글자 그대로 저장하면, 만약 데이터베이스가 유출됐을 때 모든 회원의 비밀번호가 그대로 털립니다. 이건 정말 절대 하시면 안 됩니다.

그래서 비밀번호는 반드시 알아볼 수 없게 변환(해싱)해서 저장합니다. 원래 비밀번호를 뒤죽박죽 암호 문자열로 바꿔 저장하는 건데, 이렇게 하면 설령 유출돼도 원래 비밀번호를 알아내기가 대단히 어렵습니다. 지금 원리를 다 이해할 필요는 없고, "비밀번호는 절대 그대로 저장하지 않는다"는 원칙 하나만은 처음부터 뼈에 새겨 두세요.

보안에서 한 가지 더 짚고 싶은 게 '접근 권한'입니다. 데이터베이스에는 아무나 함부로 들어오지 못하게 자물쇠를 채워야 합니다. 강력한 접속 비밀번호를 걸고, 꼭 필요한 사람·프로그램에게만 열쇠를 주며, 인터넷 아무 곳에서나 접속되지 않도록 문을 좁혀 두는 거예요. 은행 금고를 아무나 열 수 없게 하는 것과 같은 이치입니다. 그리고 개인정보를 담을 땐 정말 꼭 필요한 정보만 최소로 모으는 게 좋습니다. 안 모으면 유출될 일도 없으니까요. "혹시 나중에 쓸까 봐" 하고 이것저것 다 모아 두는 습관은 오히려 위험을 키웁니다.

실수로 데이터를 지우는 사고도 생각보다 흔합니다. 그래서 진짜 데이터로 연습하지 말고, 반드시 복사본(테스트용 데이터베이스)에서 이것저것 실험하는 습관을 들이세요. 특히 앞에서 말한 WHERE 없는 삭제·수정은, 실서비스 데이터에서 한 번 저지르면 정말 등에 식은땀이 흐릅니다. 저도 겪어 봐서 압니다. 그러니 "지우기·고치기 전엔 한 번 멈추고, 여긴 진짜 데이터인가 복사본인가"를 확인하는 작은 습관이 여러분을 여러 번 구해 줄 거예요.

이런 백업, 보안 설정, 성능 관리를 하나부터 열까지 직접 하려면 부담이 큽니다. 그래서 요즘은 클라우드 관리형 데이터베이스를 많이 씁니다. 백업, 보안 패치, 장애 대비 같은 귀찮고 어려운 관리 업무를 클라우드 회사가 대신 맡아 주는 서비스예요. 대표적인 게 AWS의 RDS인데, 이건 AWS RDS로 데이터베이스 편하게 쓰기 글에서 초보 눈높이로 따로 자세히 풀어 드립니다. 처음엔 관리형 서비스로 시작하는 게 마음 편하고 안전하다는 점만 기억해 두세요.

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

제가 직접 헤맸거나, 옆에서 자주 본 실수들을 모아 봤습니다. 미리 알아 두면 같은 웅덩이에 안 빠지실 거예요.

여기에 하나 더 보태고 싶은 조언이 있습니다. 초보 때는 완벽한 설계를 하려다 시작조차 못 하는 경우가 많아요. "표를 어떻게 나눠야 완벽하지? 열은 뭘 둬야 하지?" 고민하다 몇 날 며칠을 흘려보내는 거죠. 저도 그랬습니다. 그런데 데이터베이스 설계는 처음부터 완벽할 수 없고, 서비스가 자라면서 조금씩 고쳐 나가는 게 정상입니다. 그러니 일단 단순하게 시작하세요. 회원 표 하나, 주문 표 하나로 출발해서, 필요가 생길 때마다 열을 더하고 표를 나누면 됩니다. 완벽주의보다 '일단 만들어 보고 고치기'가 초보에겐 훨씬 이롭습니다.

이 중에서 딱 하나만 고르라면 저는 백업 습관을 첫손에 꼽겠습니다. 다른 실수는 고치면 되지만, 데이터가 날아가는 건 되돌릴 수가 없거든요. "설마 나한테 그런 일이"가 진짜 일어나는 게 데이터 사고입니다. 오늘 배운 것 중에 이것 하나만 가져가셔도 충분히 남는 장사예요.

12. 자주 묻는 질문(FAQ)

Q. 저는 개발자가 아닌데 데이터베이스를 꼭 알아야 하나요?
A. 코드를 직접 짜지 않더라도, 우리가 쓰는 거의 모든 서비스가 데이터베이스 위에서 돌아갑니다. "데이터가 표에 담기고, 번호표로 연결되고, 규칙과 백업이 중요하다"는 큰 그림만 알아도 기획·운영·소통이 훨씬 수월해집니다. 문법을 못 외워도 개념만 알면 충분히 도움이 됩니다.

Q. 그냥 엑셀이나 구글 시트로 계속 쓰면 안 되나요?
A. 사용자가 소수이고 동시 접속이 거의 없는 소규모 정리라면 엑셀도 훌륭합니다. 다만 여러 사람이 동시에 쓰거나, 데이터가 수만 건을 넘어가거나, 정확한 규칙이 필요한 '진짜 서비스'가 되는 순간 데이터베이스가 필요해집니다. 판단 기준은 '동시 사용'과 '규모'예요.

Q. SQL과 NoSQL 중 뭘 먼저 배워야 하나요?
A. 입문자라면 SQL(관계형)부터 권합니다. 표라는 개념이 엑셀과 똑같아 직관적이고, 세상 대부분의 서비스가 여전히 관계형을 씁니다. NoSQL은 대량·실시간 데이터를 다룰 필요가 생겼을 때 배워도 늦지 않습니다.

Q. 연습은 무엇으로 시작하면 좋을까요?
A. SQLite를 추천합니다. 별도 설치나 서버 없이 파일 하나로 데이터베이스를 만들어 표·행·열을 직접 만져 볼 수 있어, 겁먹지 않고 시작하기에 딱 좋습니다. 손에 익으면 MySQL이나 PostgreSQL로 넘어가세요.

Q. 데이터가 실수로 날아가면 정말 못 살리나요?
A. 백업이 있으면 그 시점으로 되돌릴 수 있지만, 백업이 없으면 복구가 매우 어렵거나 불가능합니다. 그래서 백업을 습관으로 만드는 게 무엇보다 중요합니다. 관리형 데이터베이스를 쓰면 자동 백업 기능의 도움을 받을 수 있어요.

13. 마무리 — 오늘 챙겨 갈 체크리스트

여기까지 오시느라 정말 고생 많으셨습니다. 낯선 단어가 많았지만, 결국 하나로 모입니다. 데이터베이스는 잘 정리된 창고이자, 어른이 된 엑셀이라는 것. 오늘 배운 걸 딱 한 장으로 정리해 볼게요.

• ✅ 데이터베이스 = 데이터를 체계적으로 담고 빠르게 꺼내는 '잘 정리된 창고'
• ✅ 표(시트) · 행(한 건) · 열(항목) · 기본키(고유 번호표) — 이 네 단어가 뼈대
• ✅ SQL = 연결된 엑셀 여러 장 / NoSQL = 자유로운 서랍, 용도가 다를 뿐
• ✅ 데이터로 하는 일은 결국 CRUD(만들기·읽기·수정·삭제) 네 가지
• ✅ 정보는 표별로 나눠 저장하고 번호표로 연결, 필요할 때 조인으로 합쳐 봄
• ✅ 인덱스 = 책 뒤의 '찾아보기', 빠른 검색의 비결
• ✅ 비밀번호는 절대 평문 저장 금지, 백업은 선택이 아닌 필수
• ✅ 처음엔 SQLite로 연습, 실서비스는 관리형 DB로 안전하게

이 여덟 줄이 지금은 머릿속에서 둥둥 떠다닐지 몰라도, 앱을 하나둘 만지다 보면 어느 순간 착 붙습니다. 저도 그랬어요. 처음엔 '기본키'가 뭔지도 헷갈렸는데, 표 몇 개 직접 만들어 보니 "아, 번호표구나" 하고 웃게 되더라고요. 그러니 오늘 다 이해 못 하셨어도 괜찮습니다. 이 글은 언제든 다시 펼쳐 보시면 돼요.

다음 글에서는 오늘 잠깐 나왔던 API 이야기를 이어서 풀어 볼게요. 앱과 서버가 데이터를 주고받는 그 '창구'가 어떻게 생겼는지, 그리고 이 데이터베이스를 클라우드에서 편하게 굴리는 AWS RDS 이야기까지, 손잡고 천천히 가 보겠습니다. 오늘도 한 걸음 나아가신 여러분, 정말 잘하고 계십니다. 겁먹지 마세요. 별거 아니에요.

(2026년 8월 기준 작성 — 제품 버전·화면·정책은 바뀔 수 있으니 각 데이터베이스 공식 문서를 함께 확인하세요.)

← 기술 블로그 목록으로