software

SQLite만 있으면 충분합니다: 2026년을 위한 ‘원-퍼슨 스택’

발행: (2026년 2월 4일 오전 09:08 GMT+9)
8 min read
원문: Dev.to

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line at the top exactly as you provided and preserve all formatting, markdown, and code blocks.

기본 스택이 너무 무겁다

지난 10년 동안 rails new를 실행하면 거의 즉시 기본 데이터베이스를 PostgreSQL로 교체하고, Sidekiq용 Redis 인스턴스를 띄우고, 필요에 따라 검색을 위해 Elasticsearch를 추가했습니다.
비즈니스 로직 한 줄도 작성하기 전에 세 개의 별도 서비스를 관리하고 있었죠.

  • 팀 규모가 10명? 괜찮습니다.
  • “1인 프레임워크”라면? 기술 부채입니다.

Rails 8과 최신 스토리지 하드웨어가 출시되면서 규칙이 바뀌었습니다. 이제 SQLite를 장난감처럼 여기지 말고, 실제 프로덕션 수준의 강력한 엔진으로 대우할 때입니다.

하드웨어 전환: NVMe가 모든 것을 바꾸다

2000년대에 파일 기반 데이터베이스에서 벗어나게 된 이유는 무엇일까요? 회전식 하드 드라이브 때문입니다. 회전 디스크에서의 랜덤 I/O는 엄청나게 느렸고, 동시 쓰기는 악몽과도 같았습니다.

오늘날, $5짜리 VPS조차도 NVMe SSD를 사용합니다—읽기 속도가 약 3 GB/s에 달하고 수십만 IOPS를 제공할 정도로 엄청나게 빠릅니다. 스토리지가 이렇게 빨라지면 병목 현상은 디스크가 아니라 네트워크가 됩니다.

  • Postgres: 앱 → TCP 연결 → 소켓 → Postgres 프로세스 → 디스크 → 네트워크 → 앱.
  • SQLite: 앱 → 직접 시스템 호출 → 디스크.

SQLite는 애플리케이션 프로세스 내부에서 실행함으로써 “네트워크 비용”을 없앱니다.

Rails 8 “Solid” 혁명

Rails 8은 “데이터베이스‑백엔드” 아키텍처에 전념하고 있습니다. Rails 팀은 캐시와 작업을 위해 Redis를 별도로 관리하는 것이 혼자 개발하는 사람들에게 큰 장벽이 된다는 것을 깨닫고, “Solid” 3부작을 도입했습니다. 이 시리즈를 통해 전통적으로 Redis가 담당하던 역할을 SQLite가 처리하도록 합니다.

Solid Queue

백그라운드 작업이 표준 SQLite 테이블에 저장됩니다 — Redis가 전혀 필요 없습니다.

Solid Cache

HTML 조각과 데이터가 SQLite 테이블에 캐시됩니다. 읽기가 로컬에서 이루어지기 때문에(네트워크 지연이 없음) 네트워크 기반 Redis 인스턴스보다 더 빠를 수 있습니다.

Solid Cable

WebSocket pub/sub이 데이터베이스를 통해 처리됩니다.

인프라 다이어그램이 서비스들의 거미줄에서 단일 파일 하나와 단일 서버로 축소됩니다.

하지만… “SQLite는 확장되지 않는다”고?

가장 흔한 반론은 SQLite가 “동시성을 처리하지 못한다”는 것이다. 거짓. WAL(Write‑Ahead Logging) 모드를 활성화하면 SQLite가 동시 읽기 및 쓰기 작업을 훨씬 더 잘 처리할 수 있다.

# config/database.yml
production:
  adapter: sqlite3
  database: storage/production.sqlite3
  timeout: 5000
  pool: 5
  # Enable WAL mode for better concurrency
  pragmas:
    journal_mode: wal
    synchronous: normal

다음 트위터와 같은 서비스를 만들고 있지 않다면, 최신 SQLite의 쓰기 잠금 한계에 도달할 가능성은 낮다. 보통 수준의 VPS에서도 초당 수백 건의 요청은 충분히 가능하다. 만약 그 한계에 도달한다면, 축하한다—당신은 이미 Postgres로 마이그레이션할 여력이 있는 성공적인 비즈니스를 운영하고 있는 것이다. 아직 겪지 않은 문제에 최적화하지 마라.

“N+1” 초능력

우리는 Rails에서 “채팅” 같은 네트워크 호출을 피하기 위해 N+1 쿼리를 최적화하는 데 몇 시간을 보냅니다.

  • Request 1: 10 ms
  • Request 2: 10 ms
  • …

SQLite에서는 N+1 쿼리가 단순히 함수 호출일 뿐이며—놀라울 정도로 빠릅니다. 100개의 레코드를 순회하면서 연관 데이터를 조회해도 전체가 약 2 ms 안에 끝날 수 있습니다. SQLite로 옮기면 데이터베이스 라운드‑트립을 크게 두려워하지 않아도 되기 때문에 더 간단한 코드를 작성할 수 있습니다.

백업은 어떻게 할까? (중요!)

“서버가 죽으면 파일을 잃어버린다.”

이 문제는 Litestream(또는 LiteFS)으로 해결할 수 있습니다. Litestream은 사이드카 프로세스로 실행되며 SQLite의 WAL 업데이트에 훅을 걸어 실시간으로 Amazon S3(또는 기타 객체 스토리지)로 스트리밍합니다. 서버에 화재가 발생하더라도 S3에서 데이터를 끌어와 정확히 다운된 순간까지 데이터베이스를 복구할 수 있습니다—사실 Postgres pg_dump 크론 작업보다 더 간편합니다.

요약: 1인 스택

솔로 개발자의 목표는 속도입니다.

  • 조정할 Docker 컨테이너가 없습니다.
  • 연결 풀 오류가 없습니다.
  • Redis 버전 불일치가 없습니다.
  • 단지 rails server만 실행합니다.

복잡함은 사고를 죽이는 요인입니다. 스택을 단순화하면 실제 제품을 만드는 데 사용할 수 있는 사고력이 더 많이 남습니다.

프로덕션에서 SQLite를 실행할 만큼 용감하신가요? 아래에 의견을 알려주세요!

Back to Blog

관련 글

더 보기 »