데이터베이스란? 엑셀 쓰던 사장님의 기초 가이드

안녕하세요, 3Min API 개발을 이끌고 있는 yeonghyeon입니다.

지난 글들에서 채원씨도, 저도 "데이터베이스"라는 단어를 자주 언급해 왔습니다. 웹훅을 설명할 때도, JSON과 스키마를 이야기할 때도, AI 시대의 데이터 준비를 말할 때도 빠지지 않았습니다.

그런데 정작 "데이터베이스가 무엇인가"는 한 번도 따로 다룬 적이 없습니다. 오늘은 이 단어를 확실히 잡고 가겠습니다. 앞으로 API, JSON으로 이어질 시리즈의 첫 번째 조각입니다.

이 글의 목표는 한 가지입니다. 데이터베이스라는 말 뒤의 복잡한 기술을 공부하기 전에, 먼저 "내 비즈니스의 데이터를 머릿속이 아니라 표로 정리하는 감각"을 잡는 것. 이 감각만 잡히면 나머지는 필요할 때 자연스럽게 따라옵니다. 그래서 사전지식은 없어도 괜찮습니다. 엑셀을 "표 형식으로 데이터를 정리하는 도구" 정도로만 알고 계시면 수월하고, 그마저 없으셔도 본문에서 함께 살펴볼 예정이니 편하게 읽어 주시기 바랍니다.

데이터베이스란 무엇인가

사전적 정의부터 보겠습니다. 위키백과는 데이터베이스를 "체계적으로 정리된 데이터의 집합"이라고 설명합니다. 기술 용어로는 이것을 저장하고 관리하며 검색할 수 있게 해주는 시스템을 DBMS(DataBase Management System)라고 부르지만, 일상에서는 둘을 뭉뚱그려 "데이터베이스(DB)"라고 부릅니다.

한 줄로 요약하자면 이렇습니다.

데이터베이스 = 데이터를 구조화해서 저장하고, 빠르게 찾고, 여러 사람이 동시에 쓸 수 있게 만든 시스템.

이 정의를 억지로 외울 필요는 없습니다. 사실 여러분은 이미 여러 개의 "데이터베이스"를 매일 쓰고 계시기 때문입니다.

일상 속 데이터베이스

다음 세 가지를 떠올려 보시기 바랍니다.

• 주소록: 이름, 전화번호, 주소가 한 줄씩 정리되어 있습니다. 특정 이름을 찾으면 바로 번호가 나옵니다.
• 도서관 대출 카드: 책마다 카드가 있고, 누가 언제 빌렸는지 적혀 있습니다. 빌리면 쓰고, 반납하면 지웁니다.
• 편의점 재고 장부: 상품명과 수량, 입고일이 적혀 있습니다. 팔리면 줄이고, 들어오면 늘립니다.

세 가지의 공통점이 보이십니까? 정해진 형식이 있고, 반복해서 같은 모양의 데이터가 쌓이며, 필요할 때 빠르게 찾아볼 수 있다는 점입니다. 이것이 데이터베이스의 본질입니다. 종이든, 엑셀이든, 전용 서버든 도구가 바뀔 뿐 원리는 같습니다.

데이터베이스의 종류

현대 데이터베이스는 용도에 따라 여러 종류로 나뉩니다. 가볍게 훑어보겠습니다.

• 관계형 데이터베이스(Relational, RDB): 가장 널리 쓰이고 가장 오래된 방식입니다. 데이터를 엑셀처럼 "표"로 저장하고, 표끼리 관계를 연결합니다. MySQL, PostgreSQL, Oracle 등이 여기에 속합니다.
• 문서형 데이터베이스(Document): 표가 아니라 JSON 같은 문서를 통째로 저장합니다. 구조가 자주 바뀌는 데이터에 유리합니다. MongoDB가 대표적입니다.
• 그래프 데이터베이스(Graph): 사람과 사람, 물건과 물건 사이의 "관계" 자체를 중심에 놓습니다. 소셜 네트워크나 추천 엔진에 적합합니다.
• 벡터 데이터베이스(Vector): AI 시대에 떠오른 방식입니다. 텍스트나 이미지를 숫자 배열로 저장해 "의미가 비슷한 것"을 빠르게 찾아냅니다.

오늘 글은 이 중에서 가장 널리 쓰이고, 비즈니스 현장에서 기본이 되는 관계형 데이터베이스에 집중하겠습니다.

와인샵 사장님 이야기

이론만으로는 감이 잘 오지 않습니다. 실제 상황을 따라가 보는 편이 빠릅니다.

여러분이 작은 와인샵을 연 사장님이라고 상상해 보시기 바랍니다. 처음에는 매장 한 곳, 손님도 하루에 몇 명뿐입니다. 비즈니스가 자라면서 데이터를 관리하는 방식도 함께 자랍니다.

1단계: 수기 장부

오픈 초기에는 노트 한 권이면 충분합니다. 날짜, 손님 이름, 와인 이름, 금액. 이 네 가지를 그날그날 적어 둡니다. 하루 손님이 다섯 명이면 다섯 줄, 열 명이면 열 줄입니다.

이 방식은 놀랄 만큼 강력합니다. 설치도 필요 없고, 정전돼도 읽을 수 있으며, 다른 사람에게 맡기기도 쉽습니다. 다만 규모에 약합니다. 단골이 백 명을 넘어가면서부터 문제가 시작됩니다. "지난달에 Château Margaux 사가셨던 분이 누구였지?" — 장부를 처음부터 끝까지 넘겨봐야 합니다. 재고 파악도 수작업입니다.

2단계: 엑셀

매장이 세 곳으로 늘어납니다. 사장님은 엑셀을 엽니다. 대부분의 경우 한 시트에 모든 거래를 그냥 주르륵 적어 내려갑니다. 가장 직관적이니까요.

판매 관리 시트 (한 시트에 모든 정보)

날짜	고객 이름	연락처	와인 이름	가격	수량
2026-04-01	Alex	alex@example.com	Château Margaux 2020	89,000	1
2026-04-02	Maria	maria@example.com	Pinot Noir Reserve	45,000	2
2026-04-03	Alex	alex@example.com	Riesling Kabinett	32,000	1
2026-04-05	Alex	alex@example.com	Château Margaux 2020	89,000	1

이 방식은 처음엔 편합니다. 한 화면에 다 보이고, 필터·정렬·합계도 엑셀 기본 기능으로 됩니다. 한동안 이걸로 버틸 수 있습니다.

하지만 거래가 쌓이기 시작하면 문제가 얼굴을 내밉니다.

• 같은 정보가 반복됩니다. Alex가 세 번 왔으면 이름과 연락처가 세 번 똑같이 적힙니다. 같은 와인이 팔릴 때마다 와인 이름과 가격이 또 적힙니다.
• 한 번 바뀌면 여러 줄을 고쳐야 합니다. Alex의 연락처가 바뀌었다? 과거 거래 줄을 모두 찾아 일일이 수정해야 합니다. 한 군데라도 빠뜨리면 데이터가 엉킵니다.
• 오타 한 글자가 다른 사람을 만듭니다. "Alex"라고 쳤다가 "alex", 다음에는 "Alexander"라고 적었다면, 나중에 집계할 때 세 사람처럼 보입니다.
• 동시에 수정할 수 없습니다. 두 사람이 같은 파일을 고치면 한쪽 변경이 사라집니다.
• 매장 세 곳의 파일을 누군가 손으로 합쳐야 합니다.
• 온라인몰, 결제 시스템, 회계 프로그램과 자동으로 연결되지 않습니다.

핵심 문제는 "같은 정보를 여러 군데에 반복해서 적는다"는 것입니다. 이 하나의 원인에서 위의 여러 불편이 파생됩니다.

3단계: 데이터베이스

와인샵이 온라인몰을 엽니다. 주문이 24시간 들어옵니다. 낮에는 매장 POS에서, 밤에는 웹사이트에서, 주말에는 협력 레스토랑에서 들어옵니다. 한 시트짜리 엑셀로는 물리적으로 불가능합니다.

이 시점부터 필요한 것이 데이터베이스입니다.

여기서 미리 말씀드릴 것이 있습니다. 앞으로 보여드릴 "자동으로 주문이 쌓이는 온라인몰"은 사실 데이터베이스 혼자 만들어내는 풍경이 아닙니다. 웹사이트를 띄우는 웹 서버, 시스템끼리 데이터를 주고받게 해주는 API, 이벤트가 생겼을 때 바로 알려주는 웹훅과 같은 여러 도구가 함께 움직여야 가능한 일입니다. 이 개념들을 한꺼번에 설명하면 오히려 머리가 뒤엉킵니다. 그래서 오늘은 그중에서 "데이터베이스가 맡는 역할"만 똑 떼어내서 보겠습니다. 서버, API, 웹훅 이야기는 이 시리즈의 다음 편에서 차례대로 다루겠습니다.

핵심은 '분리'입니다

2단계에서 드러난 진짜 문제는 "같은 정보를 여러 군데에 반복해서 적는 것"이었습니다. 데이터베이스는 이 문제를 정면으로 해결합니다. 방법은 단순합니다. 성격이 다른 정보를 별도의 표로 쪼개고, 서로를 번호로 연결하는 것입니다.

와인샵의 평면 시트를 세 개의 표로 나누어 보겠습니다.

고객 테이블

고객 번호	이름	연락처
001	Alex	alex@example.com
002	Maria	maria@example.com

상품 테이블

상품 번호	와인 이름	가격
101	Château Margaux 2020	89,000
102	Pinot Noir Reserve	45,000
103	Riesling Kabinett	32,000

판매 테이블

날짜	고객 번호	상품 번호	수량
2026-04-01	001	101	1
2026-04-02	002	102	2
2026-04-03	001	103	1
2026-04-05	001	101	1

세 표를 평면 시트와 비교해 보시기 바랍니다. 차이가 선명합니다.

• 이름은 고객 테이블에 딱 한 번, 와인 이름과 가격은 상품 테이블에 딱 한 번만 있습니다.
• 판매 테이블에는 이름 대신 번호만 들어갑니다.
• Alex가 네 번 왔어도 "Alex"라는 글자는 고객 테이블의 한 줄에만 존재합니다.

왜 번호로 연결할까요? 이름이나 연락처는 바뀌거나 다양하게 쓸 수 있지만, 번호는 한 번 붙이면 변하지 않기 때문입니다. Alex의 연락처가 바뀌어도 고객 테이블 한 줄만 고치면, 그의 과거·미래 모든 거래를 조회할 때마다 항상 최신 정보로 이어서 볼 수 있습니다. 평면 시트에서 "Alex가 적힌 모든 줄을 찾아 고치는" 수고가 사라집니다.

엑셀의 시트 · 머리글 · 한 줄이었던 것이, 데이터베이스 세계에서는 테이블(Table) · 컬럼(Column) · 레코드(Record 또는 Row)라고 불립니다. 이 셋이 기본 단위입니다. 용어는 바뀌지만 보이는 모양은 방금 그 표 그대로입니다.

분리된 구조 위에 시스템이 돌아갑니다

여기까지만 보면 "엑셀로도 시트를 세 개로 나누면 되는 것 아닌가"라고 생각하실 수 있습니다. 맞습니다. 구조 자체는 엑셀로도 흉내낼 수 있습니다. 하지만 실제로 돌아가는 서비스가 되려면 엑셀이 감당하지 못하는 일들을 데이터베이스가 추가로 맡아줍니다.

자, 이제 온라인몰이 열렸습니다. 시스템이 돌아가는 동안 데이터베이스의 판매 테이블에는 이런 식으로 기록이 쌓입니다.

판매 테이블 (자동 기록)

시각	고객 번호	상품 번호	수량	채널
2026-04-14 10:23:14	047	101	1	웹사이트
2026-04-14 10:23:29	112	205	2	매장 POS
2026-04-14 10:23:41	089	101	1	웹사이트
2026-04-14 10:23:55	204	103	3	레스토랑

평면 시트와 달리 사람이 손으로 치지 않습니다. 웹사이트, POS, 레스토랑의 시스템이 각자 알아서 밀어 넣고 있습니다. 1초에 수십 건씩 서로 다른 곳에서 들어와도 데이터베이스는 흔들리지 않고 받아냅니다.

엑셀과 비교해서 데이터베이스 단계에서 달라지는 것은 다음 네 가지입니다.

1. 여러 시스템이 동시에 접근합니다. 웹사이트, POS, 회계 프로그램이 같은 데이터를 실시간으로 보고 씁니다.
2. 규칙을 강제합니다. "판매 기록에는 반드시 고객 번호와 상품 번호가 있어야 한다"는 규칙을 DB가 직접 검사합니다. 규칙을 어긴 데이터는 아예 들어오지 못합니다.
3. 빠르게 찾습니다. 데이터가 수백만 건이어도 인덱스(index, 일종의 색인)를 통해 특정 고객의 주문을 즉시 찾아냅니다.
4. 자동으로 백업됩니다. 서버가 고장나도 데이터는 다른 서버에 복제되어 있습니다.

엑셀의 한 칸 한 칸을 사람이 관리하던 시대에서, 분리된 구조와 자동화된 규칙이 데이터를 지켜주는 시대로 넘어온 것입니다.

엑셀과 데이터베이스, 나란히 비교하기

지금까지 이야기를 한 장에 정리하면 이렇습니다.

항목	엑셀	관계형 데이터베이스
동시 편집	충돌 발생	수백~수천 명 동시 가능
데이터 무결성	사람이 확인	DB가 자동 검증
검색 속도	행이 많아지면 느려짐	인덱스로 즉시 응답
백업	수동 저장	자동 복제
외부 시스템 연동	수동 내보내기/가져오기	자동 연결 가능
초기 비용	사실상 0	설정·유지보수 필요

중요한 것은 엑셀이 나쁘고 DB가 좋다가 아닙니다. 규모와 속도, 그리고 연결해야 할 시스템의 수가 달라지면 도구도 달라져야 한다는 것입니다. 대부분의 소규모 비즈니스는 엑셀로 시작해도 무방하고, 엑셀 단계에서 데이터 흐름을 이해해 둔 경험이 나중에 데이터베이스로 옮길 때 그대로 자산이 됩니다.

현대 시스템은 데이터베이스를 어떻게 쓰는가

오늘날 우리가 쓰는 거의 모든 서비스 뒤에는 데이터베이스가 있습니다. 온라인 쇼핑몰의 상품 목록, 메신저의 대화 이력, 결제 서비스의 거래 내역, 지도 앱의 매장 정보 — 모두 DB에 저장되어 있습니다. 보이는 화면은 얇은 껍질일 뿐이고, 그 뒤에 쌓인 데이터가 비즈니스의 진짜 자산입니다.

규모 있는 서비스에서 DB는 혼자 일하지 않습니다.

• 여러 대의 서버에 복제되어 장애에도 버팁니다.
• 권한 시스템을 통해 누가 어떤 데이터를 볼 수 있는지 제어합니다.
• 감사 로그가 남아 누가 언제 무엇을 바꿨는지 추적할 수 있습니다.
• 분석용 DB로 데이터를 복사해 매출 분석, 추천 모델 학습에 사용합니다.

데이터는 장부가 아니라 자본입니다. 장부는 덮어두면 잊히지만, 자본은 쌓일수록 복리로 일을 합니다. 잘 정리된 데이터베이스는 시간이 갈수록 회사의 경쟁력이 됩니다.

관계형 말고 '접는 방식'도 있습니다

여기까지 오늘 본 것은 관계형 데이터베이스였습니다. 시트(테이블)를 쪼개고 번호로 연결해 중복을 없애는 방식입니다. 가장 오래되고 가장 널리 쓰이며, 데이터가 수천만 건 단위로 커졌을 때 진가를 발휘합니다.

하지만 반대 방향의 접근도 있습니다. 판매 한 건에 관련된 정보(고객·상품·수량·날짜)를 세 시트에 나눠 두지 않고, 한 덩어리의 JSON 블록에 통째로 접어 넣어 저장하는 방식입니다. 이런 저장 방식을 문서형(Document) 데이터베이스라고 부르고, MongoDB가 가장 유명합니다.

엑셀의 세 시트에 흩어져 있던 판매 한 건을 하나의 JSON으로 접으면 이런 모양이 됩니다.

{
  "sale_date": "2026-04-14",
  "customer": { "name": "Alex", "email": "alex@example.com" },
  "items": [
    { "name": "Château Margaux 2020", "price": 89000, "quantity": 1 },
    { "name": "Pinot Noir Reserve",   "price": 45000, "quantity": 2 }
  ]
}

같은 정보지만, 관계형에서는 세 곳에 흩어져 있던 것이 문서형에서는 한 덩어리로 묶여 있습니다. 오늘 배운 관계형의 분리가 문서형에서는 중첩(nesting)으로 바뀐다고 이해하시면 됩니다.

창고 정리와 택배 상자

두 접근의 차이를 비유하자면 이렇습니다.

관계형은 큰 창고를 종류별로 정리해 두는 방식입니다. 고객 선반, 상품 선반, 판매 기록 선반이 따로 있고, 주문이 들어오면 선반 여러 곳에서 필요한 것을 꺼내 조립합니다. 물건이 수만 가지를 넘어가도 창고는 흔들리지 않습니다.

문서형은 택배 상자에 가깝습니다. 주문 한 건에 필요한 것(고객 정보, 상품 목록, 수량, 날짜)을 상자 하나에 담아 그대로 주고받습니다. 받는 쪽에서 상자만 열면 그 주문에 관한 모든 것을 한눈에 볼 수 있습니다.

어느 쪽이 낫고 나쁘다가 아니라, 상황에 맞는 도구가 다를 뿐입니다. 창고 정리는 규모가 커졌을 때 힘을 발휘하고, 택배 상자는 시작이 빠르고 개별 주문을 다루기 편합니다.

작게 시작할 때 문서형이 유리한 이유

작은 팀이 관계형보다 문서형을 먼저 고려하게 되는 이유는 세 가지입니다.

1. 시작이 빠릅니다. 테이블과 관계를 미리 설계하지 않아도, JSON 한 덩어리만 보내면 저장됩니다. 개발자가 없는 작은 팀에게 "오늘 시작하면 오늘 돌아간다"는 결정적입니다.
2. 초기 비즈니스에는 복잡한 관계가 필요 없습니다. 관계형의 강점은 데이터가 수천만 건으로 쌓이고 여러 시스템이 복잡하게 엮일 때 발휘됩니다. 하루 주문 수십 건, 매장 한두 곳 단계에서는 "한 주문에 필요한 정보를 한 덩어리에 담는 것"이 오히려 단순하고 실수도 적습니다.
3. 사건(event)과 자연스럽게 맞습니다. 주문 한 건은 원래 "고객 한 명 + 여러 상품 + 날짜"가 묶인 하나의 사건입니다. 이걸 세 시트에 흩뿌린 뒤 번호로 다시 엮는 것보다, 사건 하나를 한 덩어리로 담아두는 편이 사람의 직관과 가깝습니다.

3Min API가 문서형을 기본으로 택한 배경도 이 세 가지입니다. 물론 시간이 지나 관계형 특유의 기능 — 여러 테이블을 묶어 한 번에 조회하는 것 같은 — 이 필요해지는 순간도 옵니다. 그때를 위해 관계형 기능도 로드맵에 올라와 있습니다. 다만 지금의 출발점은 "작동하는 데까지의 시간을 줄이는 것"입니다.

오늘 바로 해볼 수 있는 것

여기까지 읽으셨다면 데이터베이스의 내부 동작이나 구체적인 설계 방법을 반드시 아실 필요는 없습니다. 이 글의 목적은 단 하나, "내 비즈니스의 데이터를 머릿속이 아니라 표로 정리하는 감각"을 잡는 것이었습니다. 그 감각은 엑셀만으로도 충분히 훈련할 수 있습니다.

아래 세 단계를 순서대로 해보시기 바랍니다. 전부 엑셀 안에서 끝납니다.

Action 1. 엑셀 세 장으로 비즈니스 그려보기

지금 비즈니스 데이터를 엑셀 한 시트에 몰아서 적고 계시다면, 새 파일을 하나 열어 시트를 세 개로 나누어 보시기 바랍니다. 각각 사람, 물건, 거래에 해당하는 데이터입니다. 업종이 무엇이든 이 세 축으로 대부분의 비즈니스가 표현됩니다. 위에서 본 와인샵 예시 표를 참고하여 실제 데이터 5~10줄만 채워 보시기 바랍니다. 규칙은 하나, 같은 정보는 한 군데에만 적는 것입니다. 사람의 이름은 사람 시트에만, 상품 이름은 물건 시트에만 두고, 거래 시트에는 번호만 적습니다.

Action 2. AI에게 엑셀 정리 조언 받기

채우신 파일을 ChatGPT, Claude, Gemini 중 아무거나 열어 업로드하고 이렇게 물어보시기 바랍니다.

첨부한 스프레드시트는 제 [업종] 비즈니스 데이터입니다. 이 엑셀을 더 잘 관리하려면 시트와 열을 어떻게 나누는 것이 좋을까요? 같은 정보가 여러 군데에 중복되지 않도록 하는 관점에서, 비개발자도 실천할 수 있는 수준으로 조언해 주세요.

여기서 AI가 돌려주는 답은 "데이터베이스 설계도"가 아니라 "더 깔끔한 엑셀 구조"여야 합니다. 그 정도면 충분합니다. 이 과정을 한 번 거치면, 데이터를 구조화한다는 것이 무슨 감각인지 몸으로 이해하게 됩니다.

Action 3. 자동화의 방향 그려보기

엑셀 구조가 정리되었다면, 마지막은 "이 데이터를 언젠가 자동으로 모아야 할 때가 오면 어떻게 할 것인가"입니다. 개발자가 되실 필요는 없습니다. 방향만 잡으면 됩니다.

같은 AI 대화창에 아래 프롬프트를 그대로 복사해서 붙여 넣어 보시기 바랍니다.

다음 서비스 문서를 참고해서 제가 앞서 정리한 엑셀 구조를 나중에 이 서비스로 자동 수집하려면 어떤 순서로 시작하면 좋을지, 비개발자가 이해할 수 있는 말로 단계별로 알려주세요.

https://3minapi.com/llms-full.txt

AI가 돌려줄 답은 대체로 앞에서 본 택배 상자 비유 그대로 "엔드포인트 하나를 만들고, 주문 한 건을 JSON 블록 하나로 보내라"는 방향일 겁니다. 답변이 그렇게 나와도 당황하지 마시기 바랍니다 — 오늘 배운 관계형의 '분리' 구조가 문서형에서는 '접기(중첩)'로 바뀌어 나타나는 것뿐입니다.

AI가 여러분의 비즈니스 상황에 맞춰 첫걸음을 안내해 줄 것입니다. 그 답을 들고, 준비가 되었을 때 개발자 없이 엔드포인트를 만드는 방법을 따라가시면 됩니다.

다음 편으로

오늘은 "데이터를 담는 그릇"인 데이터베이스를 살펴보았습니다. 이 그릇 하나만 있으면 충분할 것 같지만, 실제 비즈니스에서는 그릇에 자동으로 데이터가 쌓이고, 여러 시스템이 동시에 같은 그릇을 바라보아야 합니다. 그 일을 가능하게 해주는 "통로"가 다음 주제입니다.

다음 편에서 그 통로, 즉 API를 다루겠습니다. 와인샵 사장님의 온라인몰이 POS·웹사이트·협력 레스토랑과 어떻게 같은 데이터를 주고받는지 이어서 따라가 보시기 바랍니다.

---

→ 다음 편: API란? 비개발자 사장님을 위한 기초 가이드