7부 · 코드와 실전으로 넓히기 (2) 다음 단계

← 파이썬과 SQL · 목차 · 다음: 부록 →

축하합니다. 데이터베이스를 설계하고, 데이터를 넣고, 질문을 던지고, 안전·빠르게 운영하고, 코드로 다루는 — SQL 입문의 한 바퀴를 완주했습니다. 이 마지막 챕터는 "여기서 어디로?"에 답합니다. SQLite를 넘어 어떤 데이터베이스가 있는지, NoSQL은 무엇인지, 초보가 자주 저지르는 실수는 무엇인지, 그리고 더 배울 거리를 정리합니다.

7.6 SQLite를 넘어: PostgreSQL과 MySQL

우리는 줄곧 SQLite로 배웠습니다. 배운 SQL의 대부분은 다른 데이터베이스에서도 거의 그대로 통합니다 — SELECT·JOIN·GROUP BY·트랜잭션은 표준이니까요. 그렇다면 언제 다른 DB로 갈아타야 할까요? 1부와 6부에서 예고한 SQLite의 한계가 신호입니다.

flowchart TB
    q{"이런 상황인가?"}
    q --> a["여러 사용자가<br/>동시에 많이 쓴다(write)"]
    q --> b["네트워크 너머<br/>여러 서버에서 접속한다"]
    q --> c["수십~수백 GB 이상<br/>대용량·고가용성이 필요"]
    a --> server["서버형 DB로<br/>PostgreSQL · MySQL"]
    b --> server
    c --> server
    stay["혼자 쓰기 / 로컬 분석 /<br/>앱 내장 / 읽기 위주"] --> sqlite["SQLite로 충분"]

    classDef q fill:#fff3a0,stroke:#f1c40f,color:#000
    classDef s fill:#d5e8f2,stroke:#3498db,color:#000
    classDef ok fill:#d5f2e0,stroke:#27ae60,color:#000
    class q q
    class a,b,c,server s
    class stay,sqlite ok

핵심 차이는 구조입니다. SQLite는 파일 한 개에 담기는 "내장형"이고, PostgreSQL·MySQL은 별도 서버 프로그램이 떠 있어 여러 클라이언트가 네트워크로 접속하는 "서버형"입니다. 서버형은 동시 쓰기·권한 관리·대용량·복제 같은 기능을 갖춘 대신, 설치·운영이 더 복잡합니다.

현재(2026년 기준) 가장 널리 쓰이는 관계형 데이터베이스를 보면, PostgreSQL은 스택 오버플로 개발자 설문에서 여러 해 연속 전문 개발자가 가장 많이 쓰는 데이터베이스로 꼽히며 MySQL을 앞섰습니다. PostgreSQL은 완전한 ACID 준수, 풍부한 JSON 지원, 강력한 인덱싱, 그리고 시계열·벡터·지리정보 데이터베이스로도 확장할 수 있는 생태계 덕분에 SaaS·핀테크·이커머스 백엔드 등에 폭넓게 쓰입니다. MySQL은 사용이 쉽고 호환성이 넓어 워드프레스 같은 콘텐츠 관리 시스템과 수많은 웹 애플리케이션을 떠받치는, 여전히 가장 널리 쓰이는 오픈소스 관계형 데이터베이스 중 하나입니다.

입문자를 위한 실용 조언. 특정 제품을 "정답"으로 권하지는 않겠습니다. 다만 새 프로젝트를 시작하며 서버형 오픈소스 DB를 하나 배운다면 PostgreSQL이 무난한 선택으로 자주 거론됩니다(표준 준수·기능·생태계). 기존 워드프레스나 PHP 환경에 얹는다면 MySQL이 자연스럽습니다. 어느 쪽이든, 이 안내서에서 배운 개념이 80~90% 그대로 옮겨 갑니다. 갈아탈 때 새로 익힐 건 주로 설치·접속·관리이지, SQL 자체가 아닙니다.

SQLite와 다른 점 (옮겨 갈 때 만날 것들)

타입이 엄격하다. SQLite의 느슨한 타입(2부)과 달리, PostgreSQL·MySQL은 INTEGER 칸에 글자를 넣으면 거부합니다. 날짜·시간 전용 타입도 따로 있습니다.
접속이 다르다. 파일을 여는 게 아니라 호스트·포트·사용자·비밀번호로 서버에 접속합니다. 파이썬에선 psycopg(PostgreSQL)·mysql-connector(MySQL) 같은 드라이버를 추가로 씁니다.
자동증가·플레이스홀더 표기가 조금 다르다. AUTOINCREMENT 대신 SERIAL/IDENTITY, ? 대신 %s/$1 등. 원리는 같고 표기만 다릅니다.

7.7 NoSQL: 표가 안 맞을 때

지금까지 배운 건 모두 관계형(SQL) 데이터베이스 — 데이터를 행과 열의 표로 담는 방식입니다. 그런데 모든 데이터가 표에 잘 맞는 건 아닙니다. 구조가 제각각이거나(상품마다 속성이 다른 카탈로그), 초고속 캐시가 필요하거나, 관계망 자체가 핵심인(소셜 그래프) 경우엔 다른 모양의 데이터베이스가 더 어울립니다. 이들을 묶어 NoSQL("Not Only SQL")이라고 부릅니다.

대표적인 종류를 개관하면:

종류	데이터 모양	대표 예	어울리는 곳
문서(document)	JSON 같은 유연한 문서	MongoDB	구조가 자주 바뀌는 데이터
키-값(key-value)	단순 열쇠↔값	Redis	초고속 캐시·세션
그래프(graph)	노드와 관계	Neo4j	소셜망·추천·경로 탐색
검색(search)	역색인 기반 전문 검색	Elasticsearch	텍스트 검색·로그 분석

NoSQL이 SQL을 대체하지 않는다. NoSQL은 "더 좋은 것"이 아니라 "다른 문제에 맞는 것"입니다. 유연함과 수평 확장을 얻는 대신, 관계형이 기본 제공하는 강한 일관성(ACID)·복잡한 조인·표준 질의 언어를 일부 양보하는 경우가 많습니다. 실무에선 둘을 함께 쓰는 경우가 흔합니다 — 주문·결제처럼 정확성이 중요한 "장부"는 관계형(SQL)에, 빠르게 변하는 캐시나 비정형 로그는 NoSQL에. 관계형 SQL을 탄탄히 익힌 것은 어느 쪽으로 가든 든든한 토대가 됩니다.

흥미롭게도 경계는 흐려지고 있습니다. PostgreSQL은 JSON을 잘 다루고, AI 임베딩을 저장·검색하는 벡터 확장(pgvector)까지 갖춰, 하나의 관계형 DB가 여러 역할을 겸하는 흐름도 뚜렷합니다.

7.8 흔한 실수 카탈로그

초보가 자주 밟는 지뢰를 한자리에 모았습니다. 대부분 이 안내서에서 한 번씩 짚은 것들입니다 — 복습 삼아 보세요.

실수	무슨 일이 나나	처방
`WHERE` 없는 `UPDATE`/`DELETE`	모든 행이 바뀌거나 지워짐	먼저 같은 `WHERE`로 `SELECT` 확인 (3부)
`NULL`을 `= NULL`로 비교	항상 결과 없음	`IS NULL`/`IS NOT NULL` 사용 (2부)
문자열 이어붙여 SQL 생성	SQL 인젝션 취약점	`?` 파라미터 바인딩 (7부)
외래키 PRAGMA 안 켬	잘못된 참조가 조용히 들어감	연결마다 `PRAGMA foreign_keys=ON` (3부)
`JOIN`에 `ON` 빠뜨림	카티전 곱으로 행 폭증	항상 `ON`으로 연결 조건 명시 (5부)
`GROUP BY`에 엉뚱한 칸 `SELECT`	예측 불가한 값이 나옴	묶음 기준·집계 함수만 `SELECT` (5부)
`commit()` 빠뜨림(파이썬)	변경이 저장 안 됨	변경 후 `conn.commit()` 또는 `with conn:` (7부)
한 표에 모든 걸 욱여넣음	중복·불일치	적절히 쪼개고 외래키로 연결 (2부)
미리 모든 칸에 인덱스	공간 낭비·쓰기 저하	느려진 뒤 병목 칸에만 (6부)
`WHERE`에서 집계 함수 사용	오류	그룹 조건은 `HAVING`으로 (5부)

7.9 누적 프로젝트, 돌아보기

서점 데이터베이스가 어떻게 자랐는지 되짚어 봅시다.

flowchart LR
    p1["1부<br/>파일 1개 + 첫 질문"] --> p2["2부<br/>3 테이블 설계 + 외래키"]
    p2 --> p3["3부<br/>실데이터 + 제약"]
    p3 --> p4["4부<br/>SELECT로 골라내기"]
    p4 --> p5["5부<br/>JOIN + 매출 집계"]
    p5 --> p6["6부<br/>트랜잭션 + 인덱스 + 뷰"]
    p6 --> p7["7부<br/>파이썬으로 주문 처리"]

    classDef done fill:#d5f2e0,stroke:#27ae60,color:#000
    class p1,p2,p3,p4,p5,p6,p7 done

처음엔 책 몇 권을 담는 단일 표였던 것이, 이제 고객·책·주문을 관계로 잇고, 매출을 분석하고, 재고를 트랜잭션으로 안전하게 차감하며, 파이썬 함수로 주문을 처리하는 작은 시스템이 됐습니다. 여기서 더 키운다면: 장바구니(다대다 order_items), 책 카테고리·태그, 리뷰·평점, 재고 알림, 월간 매출 리포트 자동화 같은 것을 같은 원리로 덧붙일 수 있습니다.

7.10 더 배울 거리

방향을 몇 갈래로 제안합니다. 자신의 목표에 맞는 쪽을 고르세요.

데이터 분석으로. SQL + pandas는 시작입니다. 윈도우 함수(5부 맛보기)를 깊이 파고, 시각화(matplotlib·seaborn), 통계로 나아가세요. 분석가의 SQL은 GROUP BY와 윈도우 함수가 핵심입니다.

백엔드 개발로. 서버형 DB(PostgreSQL)와 ORM(객체-관계 매핑: SQLAlchemy·Django ORM 등 — SQL을 객체 코드로 다루게 해 주는 도구), 그리고 마이그레이션(스키마 변경 관리)을 익히세요. 단, ORM을 쓰더라도 그 밑의 SQL을 이해하는 게 중요합니다 — 느린 쿼리를 진단할 때 결국 SQL을 봐야 하니까요.

데이터 엔지니어링으로. 대용량 처리, 데이터 웨어하우스(분석 전용 DB), ETL(추출·변환·적재) 파이프라인으로 시야를 넓히세요.

연습이 최고의 스승. 무엇을 향하든, 실제 데이터로 질문을 던지는 연습이 가장 빨리 늡니다. 관심 있는 공개 데이터셋(공공데이터·캐글 등)을 SQLite에 넣고, "가장 ~한 것은?", "~별 평균은?" 같은 질문을 SQL로 답해 보세요. 막히면 이 안내서의 부록 진단표로 돌아오세요.

7.11 정리

배운 SQL은 대부분 다른 DB로 그대로 옮겨 간다. 동시 쓰기·네트워크 접속·대용량이 필요해지면 서버형(PostgreSQL·MySQL) 으로, 그렇지 않으면 SQLite로 충분하다.
NoSQL(문서·키값·그래프·검색)은 SQL의 대체가 아니라 다른 문제에 맞는 도구. 실무에선 함께 쓰는 일이 흔하다.
흔한 실수는 대부분 이 안내서에서 짚은 것들 — WHERE 누락, = NULL, 문자열 이어붙이기, commit 누락 등. 진단표로 복습하라.
다음 방향은 분석·백엔드·데이터 엔지니어링 등 다양하다. 공통 비결은 실제 데이터로 질문을 던지는 연습.

이것으로 본문을 마칩니다. 마지막 부록에 명령어 빠른 참조, 증상→처방 진단표, 치트시트, 용어집, 공식 문서 링크를 모아 두었으니, 앞으로 곁에 두고 펼쳐 보세요. 즐거운 쿼리 되시길!

직접 해 보기

우리 서점에 "장바구니"(한 주문에 여러 책)를 도입하려면 어떤 테이블을 어떻게 추가해야 할까요? 스키마를 그려 보세요. (3부 다대다 복습)
7.8 실수 카탈로그에서, 자신이 실습 중 실제로 한 번이라도 겪은 실수를 찾아 표시하고, 처방을 다시 읽어 보세요.
관심 있는 공개 데이터셋(CSV) 하나를 pandas로 읽어 to_sql로 SQLite에 넣고, GROUP BY로 흥미로운 질문 하나에 답해 보세요.
(생각해 보기) 여러분의 다음 프로젝트가 "혼자 쓰는 가계부 앱"이라면 SQLite로 충분할까요, 서버형 DB가 필요할까요? 7.6의 판단 기준으로 설명해 보세요.

← 파이썬과 SQL · 목차 · 다음: 부록 →

← 이전7부 · 코드와 실전으로 넓히기 (1) 파이썬과 SQL다음 →부록 · 빠른 참조와 진단