2026년 7월 11일, Lobsters라는 사이트가 직관에 반하는 일을 하나 해냈다. 십여 년간 써온 유료 데이터베이스 시스템(별도 서버를 빌려 돌려야 하는 MariaDB라는 상용 소프트웨어)을 완전히 무료인 데이터베이스인 SQLite로 바꾼 것이다. 후자는 이른바 「파일형」 데이터베이스로 이해하면 된다. 별도 서버가 필요 없고, 추가 청구서도 발생하지 않고, 몇 줄의 코드로 바로 돌아간다.
이틀 뒤 월요일 아침, 사이트 유지보수자 중 한 명이 커뮤니티 내부에 글을 올렸다. CPU 사용률이 내려갔고, 메모리 점유율이 줄었고, 페이지 로딩이 더 부드러워졌다고. 가장 핵심적인 한 마디. 「MariaDB 서버가 완전히 내려가면, 매달 VPS 비용이 그대로 반토막 난다.」
프로그래머 커뮤니티에서 이 게시물은 폭발했다. 좋아요 384개, 댓글 92개. 기술이 얼마나 화려해서가 아니었다 — 정반대로, 너무나 소박했기 때문이다.
7년째 이어진 데이터베이스 고민
이번 마이그레이션을 이야기하기 전에, 우선 Lobsters가 무엇인지 간단히 짚고 넘어가자. 그것은 프로그래머들이 쓰는 ‘링크 공유 + 토론’ 사이트로, 더 조용하고 더 하드코어한 Hacker News 같은 곳이다. 사용자들이 기술 글을 공유하면 다른 사람들이 투표하고 댓글을 단다. 사이트 규모는 크지 않다 — 데이터베이스 파일이 약 500MB, 일상 트래픽은 보통 서버 하나면 감당된다 — 하지만 십여 년째 안정적으로 돌아가고 있다.
문제는 쓰고 있던 데이터베이스에 있었다. 초창기에 Lobsters는 MariaDB를 선택했는데, 이것은 별도 서버에서 돌려야 하는 상용 데이터베이스 시스템이다. 시간이 지나면서 팀은 이 구성이 너무 무겁다고 느꼈다. 서버가 하나 더 있다는 것은 매달 청구서가 하나 더 붙는다는 뜻이고, 유지보수해야 할 잠재적 장애 지점이 하나 더 늘어난다는 뜻이었기 때문이다. 2018년 8월, 주요 유지보수자 pushcx가 GitHub에 「PostgreSQL로 마이그레이션하자는 논의」라는 제목의 토론글을 올렸다 — 그것도 또 다른 유료 데이터베이스였다.
그 토론글은 7년을 방치되다가, 방향이 PostgreSQL에서 SQLite로 흘러갔다. 진짜 전환점은 2025년 초에 나타났다. 투자 그룹 K1이 MariaDB를 인수하면서, 커뮤니티는 MariaDB의 장기적 전망에 의구심을 품게 되었다. 동시에 Rahul이라는 커뮤니티 멤버가 토론 스레드에 이렇게 물었다. 「Lobsters는 SQLite에서 돌아갈 수 있나?」
SQLite가 무엇인가? 한 마디로, 모든 데이터를 로컬 파일에 저장하는 무료 데이터베이스다. 설치도, 설정도, 별도 서버도 필요 없다. 그것은 Chrome 브라우저 안에도, 위챗 안에도, 당신 폰의 모든 앱 안에도 내장되어 있다 — 세계에서 가장 많이 설치된 데이터베이스 엔진이다. 하지만 오랫동안 그것은 기본값으로 ‘웹사이트에는 부적합’하다고 여겨졌다. 별도 서버가 필요한 전통적 데이터베이스 시스템(MariaDB, PostgreSQL, MySQL)과는 설계 사상이 다르기 때문이다.
Rahul의 그 한마디가 그 기본 가정을 뒤집었다.
첫 마이그레이션: CPU가 100%로 치솟고, 긴급 롤백
2025년 6월, thomas0라는 커뮤니티 기여자가 본격적으로 마이그레이션 작업을 맡았다. 그는 글에서 보기 드문 솔직한 자기 고백을 남겼다. 전체 과정에서 코드 커밋 시도 세 번, 실패한 배포 한 번, 그리고 문제 세 가지를 수정한 뒤에야 최종 성공했다고.
첫 배포는 2026년 2월 21일에 있었다. thomas0와 pushcx는 전화를 한 통 걸어 상세한 배포 체크리스트를 짰고, 모든 것이 계획대로 진행되었다 — 새 코드가 올라가는 순간까지. 사이트는 읽기 전용 모드(데이터가 망가지는 것을 막는 보호 조치)로 들어갔지만, 사용자의 열람 요청만 처리하는데도 서버의 모든 CPU가 100%에 도달해버렸다. 멈춰버렸다. 두 사람이 반나절을 뒤졌지만 원인을 찾지 못했다. 결국 결정은: 롤백.
thomas0는 글에 이렇게 썼다. 「그 실패 이후 기분이 좋지 않았다.」 사전에, 프로덕션 데이터베이스 접근 권한이 없어서 성능 문제가 잠재적 위험일 수 있다는 것을 그는 이미 알고 있었기 때문이다 — 하지만 그의 추측이 확인되었다.
사후 분석 결과, 문제는 세 군데였다. 그중 두 곳은 SQLite가 데이터베이스에서 가장 큰 두 테이블에 대해 「전체 테이블 스캔」을 수행한 경우였다 — 마치 도서관에서 책 한 권을 찾으려고 첫 번째 책장부터 한 권씩 넘겨보고, 색인 번호로 찾지 않는 격이다. 데이터가 적을 때는 괜찮았지만, 데이터가 많아지면 누군가 웹페이지를 열 때마다 서버가 테이블 전체를 처음부터 끝까지 읽어야 해서 CPU가 꽉 찼다. 세 번째는 「N+1 쿼리」라 불리는 비효율 패턴이었다. 데이터를 한 건 조회할 때마다 프로그램이 추가로 N건의 쿼리를 더 날리는 방식. 올바른 방식은 필요한 데이터를 한 번에 전부 가져오는 것이었다.
세 가지 문제 중 두 가지는 SQL 작성 방식에, 하나는 프로그램 로직에 있었다. 어느 것도 SQLite 자체의 결함이 아니었다 — 두 가지 다른 데이터베이스 시스템 사이에서, 똑같은 코드라도 완전히 다른 실행 효율을 낸다는 사실이었다.
두 번째 마이그레이션: 조용한 월요일 아침
2월 21일 롤백 이후, thomas0는 딱 이틀 만에 세 번째 수정안을 커밋했다. 그는 무엇을 했을까?
우선, 첫 배포에서 발견된 두 가지 전체 테이블 스캔 문제를 고쳤다. 쿼리문에 적절한 인덱스를 추가한 것 — 말하자면 그 「큰 테이블」들에 빠른 검색용 목차를 하나 만든 셈이다. 데이터베이스를 아는 사람에겐 기본 중의 기본이지만, 마이그레이션 상황에서 핵심은 이랬다. 원래 MariaDB에서는 이 쿼리들이 다른 실행 경로를 탔기에 성능 문제가 한 번도 드러나지 않았다. SQLite로 바꾸자, 똑같은 쿼리문에 대해 SQLite는 다른 실행 전략 — 전체 스캔 — 을 택했다. 데이터베이스가 바뀌자, 원래의 ‘좋은 코드’가 ‘나쁜 코드’가 된 것이다.
둘째, N+1 쿼리를 고쳤다. 반복 쿼리를 일괄 쿼리로 바꿨다. 프로그램이 데이터베이스에 한 건씩 묻지 않고, 필요한 데이터를 한 번에 전부 끌어오게 했다.
셋째, 그는 일주일을 들여 자신이 직접 짠 스크립트로 Lobsters 실제 데이터량의 절반에 해당하는 테스트 데이터를 로컬에 생성했다 — 실제 프로덕션 데이터를 구할 수 없어 이 방식으로 트래픽을 모사할 수밖에 없었기 때문이다. 이 스크립트 자체가 또 하나의 추가 공수였다.
넷째, 만약을 위해 배포 전에 「슬로우 쿼리 로그」 스위치를 넣었다. 아직 발견되지 않은 성능 문제가 있다면, 시스템이 실행 시간이 100밀리초를 넘는 쿼리를 자동으로 기록해 빠르게 짚어낼 수 있게 했다.
2026년 7월 11일, 두 번째 배포. 이번 결말은 달랐다. 사이트는 정상 작동을 유지했고, CPU와 메모리 곡선은 평온했다. 그들은 채팅 채널에서 사용자 피드백을 지켜보다가 작은 문제 두 가지를 처리한 뒤, 월요일 — 트래픽 정점의 진짜 시험대 — 를 기다렸다.
월요일 오전, 모든 것이 고요했다. pushcx는 내부 채팅에서 이렇게 말했다. 「조용한 월요일을 보냈다.」
왜 「더 단순한」 데이터베이스가 오히려 더 나았을까?
이 이야기의 직관에 반하는 지점은 여기에 있다. SQLite는 MariaDB보다 훨씬 「단촐」하다 — 사용자 권한 시스템이 없고, 대량 동시 쓰기를 지원하지 않고, 네트워크로 원격 접속할 수 없고, 고급 쿼리 문법 상당수를 지원하지 않는다. 하지만 Lobsters가 올려놓고 보니 모든 것이 오히려 나아졌다.
이유는 세 겹이다.
첫째 층: 서버 하나가 적으니 골칫거리도 한 줌 줄었다. 원래 아키텍처에서 Lobsters의 웹 프로그램은 한 서버에서 돌고, MariaDB 데이터베이스는 다른 서버에서 돌았다. 두 기계 사이에는 네트워크 통신이 필요했고, 각각 유지보수하고, 각각 백업하고, 각각 모니터링해야 했다. SQLite는 데이터베이스를 웹 프로그램 내부의 하나의 파일로 만들어버린다 — 데이터가 같은 기계에 있고, 백업은 파일 하나를 복사하는 것일 뿐이다. 「서버 하나면 모든 트래픽을 감당할 수 있는」 Lobsters 같은 사이트에게 독립형 데이터베이스 서버는 자산이 아니라 부채다.
둘째 층: 지연 제거. 사용자가 페이지를 열 때마다 웹 프로그램은 데이터베이스를 조회해야 한다. MariaDB 아키텍처에서는 이 쿼리가 「프로그램→네트워크→데이터베이스 서버→네트워크→프로그램」 왕복을 거친다. SQLite로 바꾸자 조회는 「프로그램→로컬 파일」이 되어, 네트워크 지연이라는 변수가 완전히 사라졌다. 읽기가 쓰기보다 압도적으로 많은 사이트 — 링크 공유 사이트 같은 곳 — 에게 이 변화가 가져오는 응답 속도 향상은 실질적이다.
셋째 층: 비용. 이게 가장 직관적이다. MariaDB 서버의 매달 임대료를 이제 내지 않아도 된다. VPS 비용이 반토막 났다. 이것은 추상적인 ‘비용 절감 효율 증대’가 아니라, 청구서에서 하나의 숫자가 줄어든 그대로의 사실이다.
thomas0는 글에서 몇 가지 기술적 디테일도 적었다. SQLite는 부호 없는 큰 정수를 지원하지 않아 일부 ID 필드의 타입을 바꿔야 했고, SQLite의 정렬 규칙은 MariaDB보다 약해 ASCII 문자 대소문자 무시만 지원하고 전체 UTF-8 표기 처리는 지원하지 않으며, SQLite에 빠진 몇 가지 계산 기능을 메우기 위해 사용자 정의 함수를 썼다고. 이 디테일들은 일반 독자에게 중요하지 않지만, 하나의 진리를 보여준다. 마이그레이션의 본질은, 두 시스템 사이에서 모든 기능이 그대로 돌아가는 새 경로의 한 묶음을 찾아내는 일이라는 것을.
「충분하면 그만」과 소프트웨어 업계의 「복잡성 숭배」
이 이야기가 더 많은 사람에게 알려져야 할 진짜 이유는 기술적 차원에 있지 않다. 그것은 소프트웨어 업계의 뿌리 깊은 습관 하나를 건드린다. 기본값으로 「크고 완전한」 솔루션을 고르지, 「충분한」 솔루션을 고르지 않는다는 것.
Lobsters가 처음 MariaDB를 택한 것은, 당시 웹사이트를 만드는 표준 관행이 「애플리케이션 + 독립형 데이터베이스 서버」였기 때문이다. 이 아키텍처는 십여 년 전에는 합리적이었다 — 그때는 사이트의 성장 기대치가 높고, 트래픽 변동이 크고, 데이터베이스에 완충 능력이 필요했으니까. 하지만 십여 년이 지나도 Lobsters의 규모는 질적 변화를 겪지 않았다. 여전히 중소형 커뮤니티 사이트이고, 일평균 트래픽은 보통 서버 하나면 버틴다. 그런데 그 「혹시 모를」 대비용 데이터베이스 서버는 줄곧 매달 고정 지출을 만들어내고 있었다.
이것은 고립된 사례가 아니다. 소프트웨어 업계에는 「조기 최적화」라 불리는 흔한 실수가 있다. 아직 오지도 않은 규모를 위해 미리 대금을 치르는 것. 스타트업 세 명이 첫 출발부터 Kubernetes 클러스터, 마이크로서비스 아키텍처, 마스터-슬레이브 데이터베이스를 쌓아올리는 것 — 「나중에 확장하기 좋게」 하려고. 이 선택 자체가 틀린 것은 아니지만, 대가는 운영 복잡성, 매달 청구서, 장애 추적 난이도의 세 중첩 상승이다.
한층 더 깊이 들어가서 필자가 지적하고 싶은 것은 이것이다. 기술의 ‘진보’와 ‘적합’은 별개라는 것. 무료이고 데이터를 파일에 저장하는 가벼운 데이터베이스는 기능표상으로는 확실히 상용 데이터베이스보다 화려하지 않다. 하지만 당신이 그 추가된 기능들 — 다중 사용자 권한, 원격 복제, 대량 동시 쓰기 같은 — 을 필요로 하지 않는다면, 그 기능들은 자산이 아니라 짐이다.
물론, 이것이 SQLite가 모든 상황에 맞는다는 뜻은 아니다. thomas0 본인도 댓글란과 네티즌과의 토론에서 솔직히 인정했다. 사이트에 다량의 동시 쓰기 요구가 있거나, 여러 서버가 같은 데이터에 동시 접근해야 하거나, 복잡한 사용자 권한 관리가 필요하다면 SQLite는 적합한 선택이 아니라고. SQLite의 동시성 모델은 「다중 읽기 단일 쓰기」 — 여럿이 동시에 보는 것은 괜찮지만, 같은 순간 쓰기는 한 사람만 가능하다. 「사용자의 열람이 발언보다 압도적으로 많은」 Lobsters 같은 커뮤니티에는 문제가 안 된다. 타오바오나 위챗에게는 재앙이 되겠지만.
핵심은, 진짜로 무엇이 필요한지 자신을 들여다보는 그 행위 자체에 숨어 있다. 이 판단이, 어느 데이터베이스 버전 번호를 고르는 것보다 더 중요하다.
마지막으로
2018년 8월 pushcx가 그 토론글을 올린 시점부터, 2026년 7월 11일 두 번째 배포 성공까지, Lobsters의 데이터베이스 마이그레이션은 거의 8년에 걸쳐 이어졌다. 그 사이 실패 한 번, 코드 수정 세 번, 직접 짠 테스트 스크립트 하나, 직접 짠 데이터베이스 마이그레이션 도구 하나, 그리고 채팅 채널에서 무수히 반복된 「그럼 우리 또 한 번 해볼까」가 있었다.
최종 결과는 한 문장으로 끝낼 수 있을 만큼 단순하다. 십여 년 돌아온 오래된 기술 커뮤니티가, 독립형 서버가 필요한 상용 시스템이던 데이터베이스를 무료 파일형 데이터베이스로 바꿨다. 서버 청구서는 반토막 났다. 월요일 아침은 아주 조용했다.
이것은 「파괴적 혁신」에 관한 이야기가 아니다. 「충분함으로의 회귀」에 관한 이야기다.
참고 링크
- Lobsters 커뮤니티 게시물: 이제 SQLite에서 돌아갑니다 (thomas0 게시)
- GitHub 이슈 #539: MariaDB에서 PostgreSQL/SQLite로의 마이그레이션 전체 역사
- Simon Willison의 보도: Lobsters가 SQLite로 마이그레이션되다
- pushcx의 배포 체크리스트 Gist: 두 번의 배포 전체 조작 단계
- Lobsters 오픈소스 코드 저장소 (GitHub)