2026 . 오은

~~~~~~><>

SQL DB 역사와 한국 웹 개발 궤적

2026.05.05

SQL DB 역사와 한국 웹 개발 궤적

Claude와 나눈 대화 정리. SQL 데이터베이스의 역사적 흐름과, 그것이 한국 웹 개발 시장 및 우리 팀 시니어 분의 커리어 궤적과 어떻게 맞물리는지를 정리한 문서.

1. 시작 — 관계형 모델의 탄생 (1970년대)

  • 1970년, IBM 연구원 Edgar F. Codd가 논문 "A Relational Model of Data for Large Shared Data Banks" 발표.
  • 그 전까지 DB는 계층형(IMS) 또는 네트워크형(CODASYL) 구조 — 데이터 구조와 접근 경로가 단단히 묶여 있어서 스키마 변경 시 애플리케이션도 다 고쳐야 했음.
  • Codd의 아이디어: 데이터를 테이블(관계)로 표현하고, 어떻게(how) 가져올지가 아니라 무엇을(what) 가져올지만 선언하자.
    • → 선언형 쿼리 언어 = SQL의 철학적 뿌리.
  • IBM은 System R이라는 프로토타입을 만들고, 거기서 쓴 쿼리 언어가 SEQUEL (나중에 SQL로 개명).
  • 그러나 IBM은 자기네 메인프레임 DB 사업(IMS)을 보호하느라 System R 상용화를 늦춤 → Oracle이 그 빈틈을 파고듦.

2. Oracle의 부상 (1977~1990년대)

  • 1977년, Larry Ellison이 IBM의 System R 논문을 읽고 먼저 상용화하기로 결심.
  • 1979년 Oracle V2 출시 — 세계 최초의 상용 SQL 데이터베이스. (IBM DB2보다 4년 빠름)
  • Oracle 30년 지배의 비결 = 기술 + 타이밍 + 영업력 + 친위대(DBA 생태계).
  • 그 시절 DB는 정말 어려웠음 — 메모리 부족, 디스크 IO 병목, 트랜잭션 정합성. Oracle DBA는 고연봉 전문직.

3. 오픈소스 진영 등장 (1990년대 중반)

비슷한 시기에 철학이 정반대인 두 DB가 등장.

MySQL (1995)

  • 스웨덴에서 시작. 모토는 "빠르고 단순하게".
  • 초기에는 트랜잭션도 외래키도 없었음.
  • 웹 시대 게시판/블로그/초기 SaaS에 딱 맞음.
  • **LAMP 스택(Linux + Apache + MySQL + PHP)**의 M = MySQL → 2000년대 웹 폭발기에 사실상 표준이 됨.

PostgreSQL (1996, 뿌리는 1986년 Postgres)

  • UC Berkeley의 Michael Stonebraker가 시작한 학술 프로젝트가 뿌리.
  • Stonebraker는 그 전에 Ingres라는 또 다른 초기 관계형 DB도 만들었던 인물.
  • 철학: "관계형 모델을 제대로, 확장 가능하게 만들자".
  • 처음부터 타입 시스템, 트랜잭션, 확장성, 표준 준수를 우선. 느리고 무겁다는 비판을 받으면서도 길게 감.

[!note] 한국 개발 현장의 디폴트

이 시기 한국에서는 압도적으로 MySQL/MariaDB. 내가 다뤄본 셋(MariaDB, MySQL, SQLite)이 모두 그 계열인 게 우연이 아님.

4. MariaDB의 분기 (2009)

  • 2008년 Sun이 MySQL 인수 → 2010년 Oracle이 Sun 인수 → MySQL이 Oracle 손에 들어감.
  • MySQL 창립자 Monty Widenius가 "Oracle이 MySQL을 죽일 거다"라고 판단, 2009년 MariaDB로 포크.
  • 이름은 그의 둘째 딸 이름에서 따왔다고 함...;
  • 지금 MariaDB와 MySQL은 사실상 다른 DB로 분기. 문법은 거의 호환되지만 옵티마이저, 스토리지 엔진, 클러스터링이 꽤 다름.

5. NoSQL의 도전과 회귀 (2009~2015)

도전기

  • 2010년 전후로 "관계형 DB는 빅데이터/웹스케일에 안 맞다"는 주장이 폭발.
  • MongoDB, Cassandra, DynamoDB, Redis 등장.
  • 슬로건: "스키마 없이 빠르게, 수평 확장으로".

회귀의 이유

5~10년 지나서 분위기가 바뀐 두 가지 이유:

  1. 트랜잭션과 조인이 없다는 게 생각보다 큰 고통. 결국 애플리케이션 코드에서 다시 구현하게 됨.
  2. PostgreSQL이 NoSQL의 좋은 점을 흡수.
    • JSON/JSONB 타입 (2012, 2014)
    • 배열 타입
    • 전문 검색
    • 지리 정보(PostGIS)
    • → 결과적으로 "그냥 PostgreSQL 쓰면 되네"가 됨.

[!tip] 내 작업과의 연결

내가 다루는 pg_trgm GIN 인덱싱이나 search_words text[] + GIN array_ops 최적화가 바로 이 흐름의 한가운데. 관계형이면서 NoSQL적 유연성을 가진 DB가 PostgreSQL.

6. 클라우드와 분리 시대 (2015~현재)

  • AWS RDS, Aurora, Google Cloud SQL, Azure SQL → DB 운영 자체가 서비스화.
  • 스토리지와 컴퓨트의 분리: Aurora, Snowflake, Neon — DB 엔진은 그대로, 스토리지는 분산 객체 스토리지에. (내가 RDS Proxy 다룰 때 마주친 흐름)
  • OLTP/OLAP 경계 흐림: ClickHouse, DuckDB, MotherDuck. 특히 DuckDB는 "SQLite의 OLAP 버전".

7. 지금 PostgreSQL의 위상

지난 5년간 PostgreSQL은 사실상 개발자 디폴트 DB가 됨. 이유:

  • 표준 SQL을 가장 충실히 따름
  • 확장성(extension 생태계)이 압도적
  • JSON 같은 유연한 기능도 다 있음
  • 무료
  • 클라우드 어디서든 매니지드 서비스로 사용 가능
  • pgvector 같은 확장으로 AI 시대 벡터 DB 역할까지 흡수

[!important] Oracle → PostgreSQL 흐름의 진실

"Oracle 자리를 PostgreSQL이 차지한다"는 단순화된 주장은 과장이지만, 방향성 자체는 업계가 실제로 가고 있는 방향. 신규 프로젝트에서 Oracle을 새로 도입하는 경우는 정말 드물고, 대부분 PostgreSQL부터 검토하는 게 현실.

8. 한국 웹 개발 시장의 특이성

"한국은 거의 계속 Java로 일했어야 했다"

  • 전자정부 표준프레임워크가 2009년부터 Java/Spring 기반으로 사실상 강제됨.
  • 정부, 공공기관, 금융, 대기업 SI는 거의 다 이걸 따라야 했음.
  • 한국에서 "안정적인 일자리 = SI = Java"라는 공식이 20년 가까이 유지.
  • 지금도 정부 입찰 공고는 Spring/JSP 기반이 압도적.

다른 나라랑 비교하면 특이함. 미국/유럽은 2010년대 들어 Rails, Node.js, Django가 스타트업/중소 시장을 빠르게 잠식했다고 한다. 한국은 그 흐름이 훨씬 느림? "Java 아닌 걸로 일하려면 SI 메인 시장을 떠나야 했다"가 한국 개발자들의 분기점이었을까?

"JSP보다 LAMP가 핫했다" (2000년대 중반)

  • JSP는 그때도 "무겁고 설정 복잡하고 배포 귀찮은" 이미지.
  • PHP는 FTP로 파일만 올리면 바로 돌아갔고, 호스팅 비용도 쌌음.
  • 카페24 같은 한국 호스팅 업체들이 PHP/MySQL을 기본 상품으로 밂.
  • 개인 사이트, 중소기업 홈페이지, 커뮤니티는 거의 다 PHP.
  • **그누보드, 제로보드(나중에 XE)**가 한국 웹의 진짜 인프라.

워드프레스의 SI 침투 (2010년대 중반~)

  • 2010년대 중반부터 한국 SI 중소 시장에 워드프레스 폭발적 유입.
  • 이유: "홈페이지 + 블로그 + 간단한 관리자" 정도면 처음부터 짜는 것보다 워드프레스 + 플러그인 + 약간의 PHP 커스텀이 훨씬 효율적.
  • SI 입장에서 마진이 좋음 — "기획 1주, 개발 2주, 납품" 회전율 가능.
  • 한국 PHP 개발자 상당수가 자연스럽게 워드프레스 커스터마이저가 됨.

Laravel — PHP 진영의 "현대화 선택지"

  • 한국에서 Laravel은 PHP 개발자들의 "워드프레스나 그누보드는 너무 레거시"라고 느낄 때 넘어가는 곳.
  • Ruby on Rails 영향 받은 모던 PHP 프레임워크. MVC + ORM(Eloquent) + Blade 템플릿 + 마이그레이션.
  • SI 중소 시장에서 워드프레스로 안 되는 좀 더 복잡한 프로젝트는 Laravel로 갔음.
  • → 내가 손댄 Laravel Blade 프로젝트가 바로 그 흔적.

9. 얻어 들은 이야기와 궤적

이야기 요약

  • 개발 경력 20년+. 2000년대 초반 시작.
  • 주 업무는 SI.
  • 정부/Java를 거의 안 했기 때문에 PHP LAMP를 잡을 수 있었음.
  • 워드프레스 → Laravel 흐름을 그대로 탐.
  • 지금은 Python(FastAPI), NestJS도 다룸.

판단력

  • NoSQL 시절에도 유행하는 거 다 해봤지만, "결국 SQL로 돌아갈 것"이라고 봤음.
  • 신입~주니어가 새 기술을 "이게 진리다"로 받아들이는 것과 달리, 사이클을 두세 번 돌아보셨으므로 매력과 한계를 같이 봄.
  • 팀 DB를 PostgreSQL로 바꾼 것도 그 판단의 결과. 트렌드 보다는 경험을 바탕으로 선택.

"Next.js 철학은 이해는 되지만 따라가기 피곤"

멘탈 모델:

  • 백엔드는 백엔드, 프론트엔드는 프론트엔드 — 명확히 분리된 세계.
  • PHP: 서버에서 HTML 렌더해서 던지면 끝.
  • Laravel + Vue, FastAPI + React: API 서버와 클라이언트가 깔끔히 분리.

Next.js가 깨는 것:

  • App Router, Server Components, Server Actions로 가면서 서버/클라이언트 경계를 의도적으로 흐림.
  • "use client", "use server" 지시어로 같은 컴포넌트 트리 안에서 경계가 왔다갔다.
  • 데이터 페칭이 컴포넌트 안에서 일어나고, 폼 제출이 서버 액션으로 처리.

왜 피곤하게 느끼시는가:

  • 프론트에서 시작한 사람: "오, 백엔드까지 자연스럽게 확장되네" 느낌.
  • 백엔드에서 시작한 사람: "왜 잘 분리돼있던 걸 다시 섞지?" 느낌.
  • 게다가 Next.js는 버전마다 패러다임이 바뀜 (Pages Router → App Router → Server Actions → PPR…).
  • 6개월마다 베스트 프랙티스가 바뀌는 회전 속도가 한 가지 패러다임으로 일관되게 일해오셨던 분께는 피곤할 것 같다

10. 내 위치 정리

  • 나는 NoSQL로 시작해서 SQL로 돌아온 세대.
  • 1세대 LAMP 개발자: SQL을 당연히 시작. NoSQL은 "추가 옵션".
  • 내 세대: NoSQL을 디폴트로 배웠다가, 업계가 SQL로 회귀하는 흐름에 다시 적응.
  • → "NoSQL이 왜 매력적이었는지"와 "왜 한계가 있었는지"를 둘 다 몸으로 아는 세대.
  • SQL만 써온 사람은 도큐먼트 모델이 어떨 때 적합한지 감이 없고, NoSQL만 한 사람은 정규화의 가치를 모름. 둘 다 겪은 사람이 더 입체적인 판단 가능.

핵심 메시지

MongoDB는 잘못된 도구가 아니라, 잘못 권유받았던 시기가 있었다가 더 정확한 표현. 지금도 이벤트 스토어, 로그, CMS, IoT 데이터 같은 영역에서는 좋은 선택지.

관련 노트

  • [[PostgreSQL GIN 인덱싱과 한국어 검색]]
  • [[search_words text[] + array_ops 성능 최적화]]
  • [[Prisma 듀얼 스키마 아키텍처 - smc-lens]]
  • [[NestJS Better Auth 패턴]]