[260505 TIL] SQL DB 역사와 한국 웹 개발 궤적

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도 만들었던 인물.
• 철학: "관계형 모델을 제대로, 확장 가능하게 만들자".
• 처음부터 타입 시스템, 트랜잭션, 확장성, 표준 준수를 우선. 느리고 무겁다는 비판을 받으면서도 길게 감.

한국 개발 현장의 디폴트
이 시기 한국에서는 압도적으로 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 쓰면 되네"가 됨.

내 작업과의 연결
내가 다루는 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 역할까지 흡수

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 패턴]]