덜 저장하고 더 가볍게: Vibe Coder Server의 SQLite 전환

Vibe Coder Server가 더 가벼운 구조로 바뀌고 있습니다. 메시지 히스토리와 통계 기능을 걷어내고, 별도 PostgreSQL 서비스에 대한 의존성을 없애며, 애플리케이션이 직접 사용하는 SQLite3 하나로 저장 구조를 단순화하는 작업입니다. 목표는 분명합니다. 언제 다시 검색할지 모르는 기록을 끝없이 쌓지 않고, 저장공간과 메모리 부담을 줄여 원격 바이브코딩이라는 핵심 경험에 더 집중하는 것입니다.

기능을 더하는 것만이 발전은 아니다

Vibe Coder Server는 개발자의 실제 필요에서 시작한 도구입니다. 외부에서 집 밖 작업실의 개발 서버에 접속하고, 브라우저 안에서 Claude Code·Codex·OpenCode(GLM)의 터미널을 열어 짧은 시간에도 작업을 이어가기 위해 만들어졌습니다. 직접 사용하면서 필요한 기능을 빠르게 더하다 보니 프로젝트, 콘솔, 빌드, 히스토리, 검색, 사용량과 여러 통계 화면까지 범위가 계속 넓어졌습니다.

각 기능은 만들어질 당시 나름의 이유가 있었습니다. 대화를 나중에 검색할 수 있으면 편리할 것 같았고, 사용량과 작업 통계가 쌓이면 개발 과정을 더 잘 이해할 수 있을 것 같았습니다. 그러나 매일 직접 쓰는 도구에서는 “있으면 좋은 기능”과 “없으면 작업할 수 없는 기능”의 차이가 점점 선명해졌습니다. 히스토리와 통계를 보기 위해 접속하는 날보다 AI 터미널을 열고 프로젝트를 계속 만드는 날이 압도적으로 많았습니다.

그래서 이번 변화는 새 기능을 추가하는 업데이트가 아니라 제품의 중심을 다시 확인하는 작업입니다. 원격에서 안정적으로 터미널을 열고, 끊기지 않는 세션 안에서 AI와 개발하며, 필요한 파일과 빌드 결과를 확인하는 흐름을 남깁니다. 그 흐름에 직접 기여하지 않으면서 저장과 계산, 유지보수 비용을 만드는 부분은 과감히 덜어냅니다.

메시지 히스토리와 통계를 제거하는 이유

메시지 히스토리는 처음에는 든든한 안전망처럼 보입니다. 언젠가 과거의 해결 방법을 다시 검색할 수도 있고, 프로젝트가 어떻게 변했는지 돌아볼 수도 있습니다. 문제는 그 “언젠가”가 언제인지 알 수 없다는 데 있습니다. Claude Code, Codex, OpenCode가 주고받는 메시지와 도구 실행 결과는 생각보다 크고 빠르게 늘어납니다. 여러 프로젝트를 장기간 운영하면 사용자가 의식하지 않는 사이 데이터베이스가 계속 커집니다.

저장은 한 번으로 끝나지 않습니다. 스키마를 유지하고, 검색 인덱스를 만들고, 오래된 데이터를 정리하고, 백업과 복원 범위에 포함해야 합니다. 통계 기능도 마찬가지입니다. 화면에 숫자 하나를 보여주기 위해 원본 이벤트를 수집하고 집계하며, 데이터 형식이 달라질 때마다 호환성을 관리해야 합니다. 거의 열어보지 않는 화면이라도 서버 입장에서는 지속적인 책임입니다.

• 무기한 저장 압박 해소: 다시 볼 가능성이 불분명한 AI 대화와 실행 이벤트를 계속 축적하지 않습니다.
• 저장공간 부담 감소: 메시지 본문, 도구 결과, 검색 인덱스와 통계용 집계 데이터가 늘어나는 구조를 줄입니다.
• 개인 데이터 범위 축소: 프로젝트 맥락이 담긴 대화를 별도 데이터베이스에 장기간 복제하지 않는 방향을 택합니다.
• 백업 단순화: 핵심 설정과 프로젝트를 보호하는 일에 집중하고, 가치가 낮은 대규모 기록의 백업 부담을 줄입니다.
• 유지보수 감소: 히스토리 검색, 통계 집계, 보관 기간과 마이그레이션을 위한 코드를 덜어냅니다.

이 선택은 기록이 전혀 중요하지 않다는 뜻이 아닙니다. 오래 보존해야 하는 결정과 지식은 프로젝트의 README, CLAUDE.md, AGENTS.md, 이슈와 소스 코드처럼 목적이 명확한 문서에 남기는 편이 더 찾기 쉽고 오래갑니다. 터미널 대화 전체를 보존하는 것과 프로젝트에 필요한 지식을 정리하는 것은 서로 다른 일입니다.

PostgreSQL 사이드카에서 SQLite3 하나로

현재 공개 버전은 Vibe Coder Server 애플리케이션과 PostgreSQL을 별도 컨테이너로 실행합니다. 많은 메시지를 검색하고 통계를 집계하는 구조에서는 PostgreSQL의 강력한 질의와 인덱스 기능이 합리적인 선택이었습니다. 하지만 그 기능을 제거하면 데이터베이스에 요구하는 역할도 달라집니다. 단일 사용자의 프로젝트 메타데이터와 설정, 꼭 필요한 운영 상태를 보존하는 데 별도 데이터베이스 서버가 반드시 필요한지 다시 질문할 수 있습니다.

SQLite3는 데이터베이스 서버 프로세스를 따로 띄우지 않고 하나의 파일을 애플리케이션에서 직접 사용합니다. Vibe Coder Server처럼 한 명의 운영자가 자기 개발 머신에서 사용하는 도구에는 이 단순함이 큰 장점이 됩니다. Docker Compose에서 PostgreSQL 서비스, 네트워크 연결과 데이터베이스 계정 설정을 덜어낼 수 있고, 데이터의 위치도 더 쉽게 이해할 수 있습니다.

기대하는 변화: 저장공간, 메모리, 성능

1. 저장공간이 예측하기 쉬워진다

히스토리를 계속 저장하면 사용 기간과 프로젝트 수, AI 응답 길이에 따라 데이터가 끝없이 증가할 수 있습니다. 기록 자체뿐 아니라 검색을 위한 인덱스와 데이터베이스 내부 관리 공간도 필요합니다. 필수 상태만 SQLite 파일에 남기면 무엇이 공간을 사용하는지 파악하기 쉬워지고, 백업할 대상과 보관 기간도 단순해집니다.

2. 메모리 압박을 줄인다

별도 PostgreSQL 컨테이너는 아무 작업이 없을 때도 일정한 메모리와 프로세스 자원을 사용합니다. Vibe Coder Server에서는 AI CLI, 빌드 도구, Android SDK와 여러 프로젝트 터미널이 동시에 자원을 요구할 수 있습니다. 데이터베이스 계층을 단순화해 확보한 여유를 실제 코딩 세션과 빌드에 사용하는 것이 제품 목적에 더 가깝습니다.

3. 애플리케이션의 반응성을 높인다

성능 향상은 SQLite라는 이름만으로 자동으로 보장되지는 않습니다. 실제 효과는 제거된 데이터 수집 경로, 줄어든 쿼리와 백그라운드 작업, 단순해진 화면과 서비스 구조에서 함께 나옵니다. 메시지마다 저장과 집계를 수행하던 경로를 줄이면 터미널 스트림과 사용자 입력 처리에 더 집중할 수 있고, 시작과 종료 과정에서 확인해야 할 외부 서비스도 줄어듭니다.

4. 설치와 문제 해결이 단순해진다

컨테이너가 하나 줄어드는 것은 단순히 Compose 파일이 짧아지는 것 이상의 의미가 있습니다. 데이터베이스 비밀번호, 서비스 간 연결, PostgreSQL 버전과 상태 점검처럼 사용자가 이해해야 할 요소가 줄어듭니다. 문제가 생겼을 때 살펴볼 로그와 복구 경로도 단순해져 셀프호스팅 도구의 진입 장벽을 낮출 수 있습니다.

삭제하지 않는 핵심: 살아 있는 TUI 작업 흐름

경량화 과정에서도 Vibe Coder Server의 핵심은 유지됩니다. 브라우저에서 개발 서버에 접속하고, 프로젝트별로 Claude Code·Codex·OpenCode의 실제 TUI 터미널을 열어 작업하며, 자리를 옮겨도 세션을 이어가는 경험입니다. 최근 JSON 메시지를 해석해 별도 UI로 재구성하던 방식을 줄이고 PTY와 웹 터미널을 중심으로 바꾼 것도 같은 방향의 결정이었습니다.

AI 도구 자체가 이미 대화 맥락과 터미널 인터페이스를 관리한다면, Vibe Coder Server가 같은 데이터를 다시 해석하고 복제하기보다 안정적인 원격 통로와 개발 작업 관리에 집중하는 편이 낫습니다. 프로젝트를 고르고, 세션을 열고, 작업 상태를 확인하고, 필요한 빌드와 파일 작업으로 이동하는 핵심 동선은 남기되 그 주변의 중복 계층을 줄입니다.

전환 과정에서 중요하게 볼 것

• 기존 데이터 처리: PostgreSQL에 저장된 설정과 프로젝트 상태 가운데 무엇을 이전하고 무엇을 종료할지 명확해야 합니다.
• 백업 절차: SQLite 파일을 안전하게 복사할 시점과 애플리케이션 실행 중 백업 방법을 문서화해야 합니다.
• 동시 접근: 웹 요청과 백그라운드 작업이 겹칠 때 잠금과 트랜잭션이 안정적으로 동작하는지 검증해야 합니다.
• 업그레이드 경로: 기존 사용자가 데이터 디렉터리를 유지한 채 새 버전으로 이동할 수 있어야 합니다.
• 실제 측정: 이미지 크기, 유휴·작업 중 메모리, 시작 시간과 주요 화면 응답 시간을 전환 전후로 확인해야 합니다.

이 때문에 아직 개발 중인 구조를 완성된 결과처럼 약속하지 않으려 합니다. SQLite 전환이 반영되는 릴리스에서는 데이터 이전 방법과 되돌리는 방법, 백업해야 할 파일을 README와 CHANGELOG에 함께 정리할 예정입니다. 기존 운영자는 릴리스 안내를 확인하기 전 PostgreSQL 데이터 디렉터리를 임의로 삭제하지 않는 것이 안전합니다.

더 적게 저장하고, 더 오래 쓰는 도구로

기능을 제거하는 일은 새 기능을 소개하는 것보다 설명하기 어렵습니다. 이미 만든 기능을 포기하는 것처럼 보일 수 있기 때문입니다. 하지만 직접 매일 사용하는 도구라면 유지해야 할 이유가 분명하지 않은 기능을 계속 짊어지는 것이 오히려 제품을 느리고 복잡하게 만듭니다.

Vibe Coder Server는 거대한 개발 플랫폼을 목표로 하지 않습니다. 개발자가 자기 서버에 접속해 AI 터미널로 실제 작업을 이어갈 수 있는 조용하고 믿을 만한 작업실을 지향합니다. 메시지 히스토리와 통계를 덜어내고 PostgreSQL에서 SQLite3 중심으로 이동하는 이번 변화는 그 목적에 다시 맞추는 과정입니다. 더 적게 저장하고, 더 적은 자원으로, 핵심 작업에는 더 빠르게 반응하는 서버를 만들겠습니다.

이 글은 2026년 7월 26일 현재 진행 중인 개발 방침과 공개 저장소의 기존 구조를 바탕으로 작성했습니다. 최종 구현과 마이그레이션 절차는 향후 릴리스에서 달라질 수 있습니다.