pgmicro는 무엇인가, 포스트그레SQL처럼 쓰는 초소형 파일 데이터베이스

한눈에 보기

• 한 줄 정의: pgmicro는 포스트그레SQL 서버를 통째로 넣은 제품이 아니라, 포스트그레SQL 문장을 읽어 에스큐라이트 계열 엔진에서 돌리는 실험형 데이터베이스
• 저장 방식: 겉모습은 포스트그레SQL에 가깝지만 실제 데이터는 에스큐라이트 파일로 남음
• 핵심 차이: 포스트그레SQL을 억지로 줄인 게 아니라, 문장 읽기 -> 변환 -> 실행 구조로 다시 짠 시도
• 문서 읽는 요령: 저장소의 소개 글은 pgmicro 설명이고, 상세 문서와 예제는 터소 공용 설명이 많아 나눠서 봐야 함
• 잘 맞는 곳: AI 작업용 임시 저장소, 사용자별 실험 공간, 로컬 시험용 저장소, 파일 하나로 끝나는 개발 도구
• 주의점: 프로젝트가 직접 밝히듯 아직 실험 단계이며, 일부 기능은 아직 덜 만들어진 상태

서론

파일 하나로 끝내면서도 포스트그레SQL 감각을 살리겠다는 시도는 예전부터 있었다. pgmicro가 눈길을 끄는 이유는 여기서 한 걸음 더 나가, 포스트그레SQL 문장을 읽고 다른 엔진에서 실행하는 길을 택했기 때문이다.

다만 이 저장소는 한 번에 읽으면 오해하기 쉽다. pgmicro 자체와, 그 아래에서 실제 저장과 실행을 맡는 터소(Turso) 계열 엔진이 완전히 같은 뜻은 아니기 때문이다. 저장소 안의 상세 문서와 예제는 터소 공용 설명이 많이 섞여 있어, 그대로 읽으면 "이게 다 pgmicro 기능인가" 하고 헷갈리기 쉽다.

그래서 이번 글은 2026년 4월 14일 기준으로 pgmicro GitHub 저장소의 소개 글, 호환성 문서, 매뉴얼, 자바스크립트 문서, 예제를 함께 읽고 핵심만 풀어 쓴 해설판이다. 원문 전체를 길게 옮기기보다, 실제로 무엇을 약속하고 무엇은 아직 약속하지 않는지까지 나눠서 정리했다.

1. 저장소 소개 글이 말하는 핵심

• 공식 성격: 프로그램 안에서 바로 도는 포스트그레SQL 호환 마이크로 데이터베이스
• 내부 바닥: Rust로 다시 만든 에스큐라이트 계열 엔진
• 핵심 주장: 포스트그레SQL을 그대로 넣지 않고 포스트그레SQL 문장을 읽어 실행용 내부 명령으로 바꿈
• 눈에 띄는 결과: 만들어진 파일은 에스큐라이트 3.x 데이터베이스

소개 글의 첫 설명을 쉬운 한국어로 옮기면 이렇다. pgmicro는 포스트그레SQL처럼 쓰지만, 실제로는 에스큐라이트 계열 저장 엔진 위에서 돌아가는 초소형 파일 데이터베이스다. 즉 포스트그레SQL 서버를 잘라 넣은 도구가 아니라, 포스트그레SQL의 사용 감각을 더 가볍게 가져오려는 시도에 가깝다.

이 점이 중요한 이유는 접근 방식이 기존 시도와 다르기 때문이다. 보통 "포스트그레SQL을 가볍게 쓰자"는 이야기에서는 포스트그레SQL 자체를 웹어셈블리로 돌리거나, 아예 다른 데이터베이스 위에 호환 층을 얹는 방법이 자주 거론된다. 그런데 pgmicro는 저장소 소개 글에서 그 길을 택하지 않았다고 못 박는다.

핵심은 세 단계다.

• 포스트그레SQL 해석기: 실제 포스트그레SQL 문장 읽기 도구를 빌려 입력을 해석
• 번역기: 읽어들인 포스트그레SQL 문장을 터소 내부 문장 구조로 바꿈
• 실행 엔진: 그 결과를 에스큐라이트 계열 내부 명령으로 돌리고 파일에 저장

그래서 저장소는 "포스트그레SQL을 에스큐라이트 문장으로 바꾸는 단순 치환"도 아니고, "포스트그레SQL 서버를 그대로 넣은 것"도 아니라고 설명한다. 쉽게 말하면 겉에서 읽는 문장은 포스트그레SQL인데, 안에서 일하는 몸체는 에스큐라이트 계열 엔진인 셈이다.

이 구조에서 눈에 띄는 대목은 두 가지다.

• pg_catalog 시스템 표 흉내: pg_class, pg_type 같은 표를 흉내 내어 피에스큐엘(psql) 같은 도구가 기대하는 정보를 보여 줌
• 간단한 서버 모드: 파일 데이터베이스가 중심이지만, 필요하면 포스트그레SQL 통신 규칙 서버를 열어 일반 클라이언트가 붙게 할 수 있음

실제 예시도 이 점을 드러낸다. pgmicro myapp.db로 만든 파일을 운영체제에서 확인하면 에스큐라이트 3.x 데이터베이스로 인식된다. 다시 말해 개발자는 포스트그레SQL 문법으로 작업하지만, 저장 결과는 에스큐라이트 도구들이 알아볼 수 있는 파일이라는 뜻이다.

2. 코드에서 보이는 내부 구조는 생각보다 구체적이다

• 시작점: pgmicro/src/main.rs가 데이터베이스를 열 때 포스트그레SQL 문법 모드를 함께 켬
• 열리는 기능: 뷰, 사용자 정의 타입, 암호화, 색인 방식, 붙여 쓰기, 생성 열, 포스트그레SQL 모드
• 스키마 처리: 기본 구역 하나만 쓰는 게 아니라 스키마별 파일을 자동으로 다시 붙이는 흐름이 있음
• 내부 메시지: 단순 데모가 아니라, 실제로 포스트그레SQL 흉내를 내려는 설계가 코드에 이미 드러남

소개 글만 읽으면 프로젝트 방향은 보이지만, 실제 신뢰도는 코드에서 더 잘 드러난다. pgmicro/src/main.rs를 보면 데이터베이스를 열 때 여러 옵션을 한꺼번에 켠다. 여기에는 뷰, 사용자 정의 타입, 암호화, 색인 방식, 붙여 쓰기, 생성 열, 그리고 포스트그레SQL 모드가 함께 들어 있다.

이 말은 단순하다. pgmicro는 SQL 문장 몇 개만 겉으로 번역하는 얇은 껍데기가 아니라, 엔진 자체를 포스트그레SQL 문법을 받아들일 수 있는 상태로 여는 방식에 가깝다. 그래서 타입이나 스키마, 설명 정보 같은 문제를 그냥 무시하지 않고, 아래 엔진 설정까지 같이 건드린다.

여기서 특히 흥미로운 부분은 스키마 파일 처리다. 코드에는 시작할 때 현재 폴더를 훑고, 이름이 turso-postgres-schema-스키마명.db 형태인 파일을 찾아 자동으로 붙여 읽기 처리를 하는 흐름이 있다. 쉽게 말해 포스트그레SQL의 스키마 개념을 거대한 한 파일 안에서만 처리하는 것이 아니라, 스키마별 에스큐라이트 파일을 옆에 두고 묶어 읽는 방식을 택한 셈이다.

이 설계는 장단점이 분명하다.

• 장점: 스키마를 파일 단위로 나누기 쉬움
• 장점: 붙였다 떼는 방식으로 가볍게 다룰 수 있음
• 주의점: 전통적인 포스트그레SQL처럼 하나의 거대한 서버 저장소와 완전히 같은 구조는 아님
• 의미: pgmicro가 포스트그레SQL 감각을 흉내 내되, 저장은 끝까지 파일형 엔진 사고방식 위에 둔다는 증거

실제로 서버 코드에는 스키마 삭제 명령이 성공하면 그 스키마 파일과 보조 파일까지 지우는 처리도 들어 있다. 이것만 봐도 프로젝트가 단순 개념 실험을 넘어, 포스트그레SQL식 구역 나누기를 파일 데이터베이스 세계에서 어떻게 흉내 낼지까지 꽤 구체적으로 고민하고 있음을 알 수 있다.

3. 번역기는 실제로 무엇을 바꾸나

• 핵심 폴더: parser_pg
• 역할: 포스트그레SQL 해석 결과를 터소 내부 문장 구조로 다시 바꿈
• 눈에 띄는 처리: pg_catalog, information_schema, 자동 번호 열, 선택형 값 목록, 배열 타입, 함수 이름 앞부분 정리
• 중요한 메시지: pgmicro는 "말만 포스트그레SQL"이 아니라, 실제 문법 차이를 세세하게 다듬는 작업이 꽤 많음

이 프로젝트의 진짜 핵심은 parser_pg/src/translator.rs에 있다. 여기서는 포스트그레SQL 해석기가 뽑아 낸 결과를 터소가 이해할 수 있는 내부 문장 구조로 다시 바꾼다. 말 그대로 번역기다.

이 번역기의 작동 방식은 생각보다 현실적이다. 예를 들어 pg_catalog, public, information_schema 같은 스키마 이름은 일부 경우 특별 취급한다. 또 information_schema.tables는 내부적으로 sqlite_master로, information_schema.columns는 pragma_table_info 쪽으로 연결한다. 즉 포스트그레SQL 사용자가 익숙한 시스템 표 이름을 유지하면서도, 밑바닥에서는 에스큐라이트 계열 정보원을 끌어다 쓰는 방식이다.

타입 처리도 꽤 공을 들였다.

• 자동 번호 열: 내부적으로는 정수형으로 바꾸고 자동 증가 흐름을 따로 감지
• UUID, DATE, TIMESTAMPTZ, JSONB, INET: 터소 쪽 사용자 정의 타입 체계와 연결
• INTERVAL, TSVECTOR, TSQUERY: 아직은 더 단순한 저장 타입으로 내려앉는 구간이 있음
• 알 수 없는 타입: 곧바로 막기보다 이름을 살려 두고, 생성 시점 검증에 맡기는 방식

특히 선택형 값 목록 처리는 인상적이다. 코드를 보면 허용된 값 목록 안에 들어오는지 검사하는 식을 따로 만들어 넣는다. 즉 "겉모습만 포스트그레SQL"이 아니라, 값 검사 규칙까지 최대한 살리려는 시도다.

배열과 함수 이름도 손본다. 포스트그레SQL 내부 배열 표기인 앞쪽 밑줄을 걷어 내고 차원을 계산하거나, pg_catalog.함수명처럼 붙은 접두어를 떼는 처리도 코드에 들어 있다. 이런 조각들이 많다는 것은 곧, pgmicro가 단순 홍보 문구보다 훨씬 노동집약적인 호환 작업 위에 서 있다는 뜻이기도 하다.

정리하면 번역기의 역할은 세 갈래다.

• 포스트그레SQL 문법 보존: 사용자는 익숙한 문장으로 입력
• 내부 타입 조정: 에스큐라이트 계열 저장 방식에 맞게 다시 배치
• 도구 호환 확보: 시스템 표와 함수 이름을 맞춰 피에스큐엘 같은 도구가 덜 어색하게 작동하도록 보정

4. 피에스큐엘 연결은 어떻게 살아나나

• 서버 핵심: cli/pg_server.rs가 포스트그레SQL 통신 규칙을 처리
• 연결 방식: 서버가 뜨면 접속마다 SQL을 포스트그레SQL 문법 모드로 해석
• 관리 명령 핵심: \dt, \d, \l, \conninfo 같은 출력이 실제 조회문으로 구현됨
• 내부 의미: 피에스큐엘 호환성은 겉모습 연출이 아니라 시스템 표 흉내 + 응답 형식 변환의 결합

소개 글에서 짧게 지나가는 서버 모드도 코드를 보면 꽤 구체적이다. cli/pg_server.rs는 포스트그레SQL 클라이언트가 주고받는 통신 규칙을 처리하는 역할을 맡는다. 서버가 시작되면 연결 객체의 SQL 문법 모드를 포스트그레SQL로 고정하고, 들어온 문장을 문장 단위로 잘라 차례대로 실행한다.

여기서 중요한 것은 단순히 포트를 여는 것이 아니다. 포스트그레SQL 클라이언트는 타입, 입력값, 결과 형식까지 기대하는 방식이 다르다. 코드에는 $1, $2 형태 입력값을 내부 바인딩 위치에 다시 연결하는 처리, BOOL, BYTEA, TIMESTAMPTZ, 배열 값을 포스트그레SQL 방식에 맞춰 다시 바꾸는 처리까지 들어 있다.

즉 서버 모드는 "문자열만 전달"하는 단순 중계가 아니다. 아래 같은 변환이 실제로 들어간다.

• 숫자와 실수 파라미터: 내부 숫자 값으로 다시 해석
• 참거짓 값: true/false와 0/1 사이를 맞춰 줌
• BYTEA: 포스트그레SQL의 16진수 글자 표현을 실제 바이트로 복원
• 시간 타입: 시간대 정보가 빠지면 보정해서 클라이언트가 덜 헷갈리게 처리

관리 명령도 마찬가지다. pgmicro/src/main.rs를 보면 \dt, \d, \l, \di, \dv, \dn, \dT, \conninfo 같은 명령이 들어 있다. 그런데 이것이 별도 특수 기능처럼 보이면서도 실제로는 pg_tables, pg_attribute, pg_class, pg_type, pg_namespace, pg_database 같은 표를 조회하는 SQL로 구현돼 있다.

이 점이 아주 중요하다. 결국 피에스큐엘 경험의 핵심은 시스템 표가 얼마나 그럴듯하게 보이느냐에 달려 있는데, pgmicro는 그 부분을 시스템 표 흉내와 조회 결과 조합으로 맞추고 있다. 다시 말해 "포스트그레SQL처럼 보인다"는 말이 단순한 겉포장이 아니라, 설명 정보를 어떤 모습으로 내놓을지까지 포함한 호환 작업이라는 뜻이다.

5. 이 저장소는 왜 더 헷갈리기 쉬운가

• 문서 층 분리 필요: 소개 글과 pgmicro 폴더는 제품 설명, 상세 문서와 예제 상당수는 터소 엔진 설명
• 읽기 함정: 브라우저 동작, 클라우드 동기화, 암호화, 벡터 검색이 모두 곧바로 pgmicro 전용 기능처럼 보일 수 있음
• 실제 해석: 저장소가 보여 주는 것은 pgmicro 단독 기능과 기반 엔진 생태계가 함께 섞인 그림
• 기사식 결론: 프로젝트의 가능성은 크지만, 오늘 바로 믿고 쓸 범위는 더 좁게 봐야 함

여기서부터는 소개 글 밖 문서를 어떻게 읽어야 하는지가 중요해진다. 매뉴얼 문서는 제목부터 터소 데이터베이스 설명서이고, 예제 묶음도 터소 예제라고 적혀 있다. 즉 저장소 전체를 한 덩어리로 보면, "pgmicro 설명서"라기보다 pgmicro를 품은 터소 실험 저장소에 더 가깝다.

이 차이를 놓치면 오해가 생긴다. 예를 들어 예제에는 브라우저용 웹어셈블리 데이터베이스, Turso Cloud 양방향 동기화, 원격 암호화, 동시 쓰기 실험까지 나온다. 하지만 이 모든 것이 곧바로 pgmicro가 포스트그레SQL 문법으로 완성형 지원한다는 뜻은 아니다.

저장소를 실제로 읽고 나면 층위는 이렇게 나뉜다.

• pgmicro가 직접 보여 주는 것: 포스트그레SQL 문법 해석, pg_catalog 호환 표, 피에스큐엘 연결용 간단한 서버, 관리 명령, 포스트그레SQL 기본 감각
• 터소 엔진이 보여 주는 것: 에스큐라이트 호환성 문서, 자바스크립트 바인딩, 파이썬 바인딩, 브라우저 웹어셈블리, 클라우드 동기화, 벡터 검색, 전문 검색, 동시 처리 실험

오히려 이 구분이 잡히면 프로젝트가 더 선명해진다. pgmicro의 본질은 **"가벼운 파일 데이터베이스에 포스트그레SQL 감각을 입힌다"**는 데 있다. 그리고 터소 문서는 그 아래 바닥이 앞으로 어디까지 넓어질 수 있는지를 보여 주는 참고 자료에 가깝다.

6. 상세 문서와 예제를 보면 실제로 어디까지 보이나

• 자바스크립트 API 상태: connect, prepare, exec, close 같은 기본 흐름은 보이지만 여러 고급 함수는 아직 미지원
• 브라우저 예제: 웹어셈블리 방식 가능성은 보이지만, 공유 메모리 기능 때문에 별도 헤더 설정 필요
• 동기화 예제: 로컬 파일과 터소 클라우드 사이 끌어오기, 올리기 흐름 제시
• 파이썬 예제: 기본 로컬 DB, 동시 쓰기 재시도, 원격 동기화 예시 제공

문서를 자세히 읽으면 "될 것 같은 것"과 "지금 되는 것"의 경계도 보인다. 자바스크립트 문서를 보면 기본 연결과 질의 실행은 가능하지만, transaction, pragma, backup, aggregate, loadExtension, interrupt 같은 함수는 아직 지원하지 않는다고 적혀 있다. 즉 기초 읽기와 쓰기는 되지만, 주변 생태계는 아직 진행형이라는 뜻이다.

예제는 방향성을 보여 준다. database-node는 로컬 파일 데이터베이스 예제이고, database-wasm-vite는 브라우저 안에서 데이터베이스를 돌리는 예제다. 다만 이 예제는 공유 메모리 기능 때문에 개발과 배포 모두에서 별도 헤더 설정이 필요하다고 분명히 적는다. "브라우저에서도 돌아간다"는 한 줄 뒤에 실제 배포 조건이 따라붙는다는 뜻이다.

동기화 예제도 마찬가지다.

• sync-node: 로컬 파일에 쓴 변경을 클라우드에 올리고, 서버 변경을 다시 내려받는 흐름
• sync-wasm-vite: 브라우저에서도 같은 생각을 시도하지만, 공개 클라이언트에 토큰이 실릴 수 있다는 경고 포함
• sync-encryption: 원격 암호화 키를 다루는 시나리오까지 보여 줌

동시 쓰기 예제는 더 흥미롭다. 자바스크립트 예제 코드와 매뉴얼 문서 모두 BEGIN CONCURRENT와 MVCC를 언급하는데, 쉽게 말하면 여러 버전을 나눠 저장해 동시에 쓰기를 돕는 방식이다. 여러 연결이 동시에 쓰기를 시도하고, 마지막 반영 시점에 충돌을 감지해 실패한 쪽이 다시 시도하는 구조다. 다만 매뉴얼은 이 구현을 실험적이라고 밝히며, 색인을 만들 수 없거나 큰 데이터는 처음 접근할 때 통째로 메모리로 읽어 온다는 제한도 적고 있다.

7. 테스트 코드를 보면 무엇까지 믿을 수 있나

• 확인된 방향: 기본 CREATE TABLE, INSERT, SELECT, 메타 명령, 기본 시스템 표 조회
• 보이는 범위: \dt, \d, \l, \conninfo 출력과 종료 코드까지 시험
• 중요한 한 줄: 포스트그레SQL 모드에서 sqlite_schema 직접 조회는 실패해야 한다는 테스트도 있음
• 해석: "무엇을 지원한다"보다 "어디까지 포스트그레SQL답게 보일지"를 우선 검증 중

저장소의 pgmicro/tests/pgmicro.rs를 보면 개발자가 지금 무엇을 중요하게 생각하는지도 드러난다. 테스트는 거대한 성능 자랑보다, 기본 문법과 관리 명령이 제대로 보이는지에 더 무게를 둔다.

예를 들어 아래 같은 흐름이 시험에 들어 있다.

• 테이블 생성 후 조회가 되는가
• 여러 테이블이 만들어지면 pg_tables에 보이는가
• \dt가 만든 테이블을 나열하는가
• \d 테이블명이 열 이름과 타입을 보여 주는가
• \conninfo가 현재 데이터베이스와 방언을 알려 주는가

흥미로운 테스트도 있다. 포스트그레SQL 모드에서는 sqlite_schema를 직접 조회하면 실패해야 한다는 확인이 들어 있다. 이는 내부가 에스큐라이트 계열이라 해도, 사용자에게는 가능한 한 포스트그레SQL 세계관을 유지하겠다는 의도를 보여 준다.

물론 이 테스트만으로 대규모 운영 신뢰도를 말할 수는 없다. 다만 지금 단계의 pgmicro가 어디에 힘을 쓰고 있는지는 분명해진다. 완전한 포스트그레SQL 대체보다, 우선 작고 익숙한 포스트그레SQL 경험을 성립시키는 쪽에 초점을 맞추고 있다는 뜻이다.

8. 어떤 장면에서 pgmicro가 특히 매력적인가

• AI 작업 데이터: 작업 하나 끝나면 같이 버려도 되는 임시 DB
• 사용자별 샌드박스: 파일 하나씩 분리해 빠르게 생성하고 지우는 구조
• 로컬 개발 도구: 설치형 서버 없이 곧바로 붙는 포스트그레SQL 느낌의 저장소
• 시험 환경: 짧은 세션 저장소, 데모용 데이터, 내장형 테스트 DB

저장소 소개 글이 왜 이 프로젝트를 만들었는지 설명하는 대목은 지금 AI 시대와 맞닿아 있다. 작성자는 AI 에이전트 때문에 짧게 생겼다가 빨리 사라지는 작은 데이터베이스 수요가 늘고 있다고 본다. 작업 단위 임시 저장소, 세션 저장소, 사용자별 독립 작업공간이 대표적이다.

이런 장면에서 전통적인 포스트그레SQL 서버는 다소 무겁다. 서버를 띄우고, 포트를 열고, 연결을 관리하고, 운영체제 수준 자원을 챙겨야 한다. 반면 에스큐라이트는 가볍지만, 포스트그레SQL 문법과 감각에 익숙한 팀에게는 타입 체계나 연산자, 도구 습관이 아쉽게 느껴질 수 있다.

pgmicro는 바로 그 사이를 노린다. 파일 하나로 끝나는 가벼움과 포스트그레SQL에 익숙한 개발 경험을 함께 가져오려는 시도다. 특히 아래 같은 경우에는 꽤 설득력이 있다.

• 에이전트별 임시 저장소를 빠르게 만들고 지워야 하는 경우
• 팀이 이미 포스트그레SQL 문법과 피에스큐엘 흐름에 익숙한 경우
• 운영용 대형 서버가 아니라 로컬 도구나 내장형 앱 저장소가 필요한 경우
• 나중에 에스큐라이트 도구로 파일을 직접 들여다봐야 하는 경우

9. 반대로 지금 기대하면 곤란한 것도 분명하다

• 저장소 공식 표현: 매우 실험적
• 엔진 제약: 다중 프로세스 동시 접근 미지원, 일반 VACUUM 제한, 문자 인코딩은 사실상 UTF-8 중심
• 동시 처리 제약: 색인 제한, 메모리 적재 부담, 충돌 재시도 필요
• 포스트그레SQL 기능 공백: LISTEN/NOTIFY, 논리 복제, 완전한 COPY 프로토콜, 저장 프로시저 같은 기능은 아직 먼 편

가장 먼저 봐야 할 문장은 README의 상태 설명이다. 저장소는 이 프로젝트를 매우 실험적이라고 직접 밝힌다. 안정성, 완전한 호환성, 기능 완성도를 아직 보장하지 않는다는 뜻이다.

여기에 기반 엔진 문서가 붙는다. 호환성 문서는 터소가 에스큐라이트를 Rust로 다시 만든 엔진이며, 에스큐라이트와 다른 점은 문서에 적지 않았다면 버그로 보겠다고 적는다. 동시에 다중 프로세스 동시 접근 미지원, 일반 VACUUM 미지원 같은 제한도 함께 둔다. 즉 파일 하나짜리라고 해서 아무 프로세스나 동시에 붙는 구조는 아니라는 뜻이다.

더 깊게 보면 pgmicro/TODO.md가 냉정한 현실을 보여 준다. 쉬운 과제로는 COMMENT ON, GRANT/REVOKE, 더 많은 시스템 함수 별칭이 적혀 있고, 중간 난이도로는 CREATE TABLE AS, EXPLAIN, 격리 수준 처리 등이 적혀 있다. 어려운 과제로는 사용자 정의 함수, INTERVAL 계산, 완전한 COPY 프로토콜, 트리거, 지연 제약조건이 남아 있다. 아주 어려운 과제로는 저장 프로시저, LISTEN/NOTIFY, 논리 복제, 포스트그레SQL식 전문 검색이 올라와 있다.

쉽게 말하면 지금의 pgmicro는 **"포스트그레SQL의 분위기를 꽤 잘 가져온 초소형 실험 DB"**이지, **"기존 포스트그레SQL 서버를 그대로 대체할 완성품"**은 아니다. 이 선을 분명히 긋고 접근해야 실망이 줄어든다.

10. 에스큐라이트, 기존 포스트그레SQL 서버와 비교하면 어디쯤인가

• pgmicro: 파일 하나로 가볍게 쓰면서 포스트그레SQL 감각을 가져오려는 쪽
• 에스큐라이트: 가장 단순하고 널리 검증된 파일 데이터베이스
• 기존 포스트그레SQL 서버: 기능과 안정성은 가장 강하지만 운영 부담도 가장 큼

세 도구의 차이는 아래처럼 읽으면 쉽다.

• 실행 방식: pgmicro와 에스큐라이트는 프로그램 안에서 바로 돌고, 기존 포스트그레SQL은 별도 서버가 필요
• 문법 중심: pgmicro와 기존 포스트그레SQL은 포스트그레SQL 쪽 감각이 강하고, 에스큐라이트는 에스큐라이트 문법이 중심
• 저장 형식: pgmicro와 에스큐라이트는 파일형 저장소에 가깝고, 기존 포스트그레SQL은 자체 데이터 디렉터리를 씀
• 강점: pgmicro는 가벼움과 익숙한 문법의 절충안, 에스큐라이트는 단순함, 기존 포스트그레SQL은 완성도와 운영 생태계
• 약점: pgmicro는 아직 실험 단계, 에스큐라이트는 포스트그레SQL 감각이 약함, 기존 포스트그레SQL은 무겁고 손이 많이 감

이 비교만 봐도 위치가 보인다. pgmicro는 에스큐라이트처럼 가벼운 축에 서 있지만, 개발자가 만나는 문법과 도구 감각은 포스트그레SQL 쪽으로 끌어오려 한다. 그래서 에스큐라이트의 단순함과 포스트그레SQL의 익숙함 사이에서 새 선택지를 만들려는 프로젝트라고 보는 편이 정확하다.

다만 현재 시점에서는 무게중심이 분명하다. 운영 안정성과 기능 완성도는 여전히 기존 포스트그레SQL 서버가 압도적이고, 단순성과 검증된 파일형 경험은 에스큐라이트가 강하다. pgmicro의 매력은 그 둘의 틈새에서, 특히 AI 에이전트 시대에 늘어난 짧은 수명 데이터베이스 수요를 겨냥한다는 데 있다.

11. 한국 개발팀은 이 프로젝트를 어떻게 봐야 할까

• 도입 후보: AI 개발 도구팀, 로컬 퍼스트 앱 팀, 사내 자동화 도구팀
• 기대 효과: 서버 없는 시험 환경, 사용자별 격리 저장소, 포스트그레SQL 친화적 개발 경험
• 주의 산업: 금융, 결제, 대규모 협업 서비스처럼 완성도와 운영 안정성이 먼저인 곳
• 현실적 판단: 당장 주력 운영 DB보다 탐색용 실험 무기에 더 가까움

한국 개발팀 입장에서는 이 프로젝트를 두 갈래로 보면 좋다. 첫째는 지금 바로 운영 DB로 쓸 것인가라는 질문이다. 여기에 대한 답은 아직 조심스럽다. 저장소가 스스로 실험 단계라고 적고 있고, 빠진 기능 목록도 꽤 길기 때문이다.

둘째는 어떤 아이디어를 주는가라는 질문이다. 이쪽에서는 가치가 크다. AI 에이전트 하나마다 작은 DB가 붙는 구조, 사용자별 격리 파일 저장소, 로컬 퍼스트 개발 도구, 서버 없는 샌드박스 데이터베이스 같은 발상은 앞으로 더 자주 필요해질 가능성이 크다.

특히 국내에서는 사내 업무 자동화와 AI 개발 보조 도구 수요가 빠르게 늘고 있다. 이런 흐름에서 pgmicro는 "무거운 운영 DB"보다 개발자 실험 환경을 얼마나 가볍게 만들 수 있나를 생각하게 만드는 저장소에 가깝다. 다시 말해 당장 대형 서비스의 주 데이터베이스라기보다, 에이전트 시대의 새 로컬 DB 감각을 보여 주는 선행 사례로 읽는 편이 좋다.

결론

pgmicro를 한 문장으로 정리하면 이렇다. 포스트그레SQL처럼 쓰지만 실제로는 에스큐라이트 계열 파일 엔진 위에서 움직이는 초소형 실험 데이터베이스다. 이 프로젝트의 진짜 흥미는 포스트그레SQL 서버를 억지로 줄인 데 있지 않고, 아예 다른 구조로 같은 개발 감각을 가져오려 했다는 데 있다.

소개 글만 보면 꽤 대담한 선언처럼 보이지만, 상세 문서와 예제까지 함께 읽으면 그림이 더 정확해진다. pgmicro 자체는 포스트그레SQL 문법과 도구 감각을 가볍게 재구성하는 층이고, 그 아래에서는 터소 엔진이 파일 저장, 웹어셈블리, 동기화, 동시 쓰기 같은 더 넓은 실험을 맡고 있다.

그래서 이 저장소를 과대평가할 필요도, 가볍게 넘길 필요도 없다. 오늘 당장 기존 포스트그레SQL을 모두 대체할 완성품은 아니지만, AI 에이전트와 내장형 앱 시대에 어떤 데이터베이스가 필요해질지를 꽤 선명하게 보여 주는 프로젝트인 것은 분명하다.

참고 자료

• pgmicro README - GitHub, 2026년 4월 14일 확인
• Turso SQLite Compatibility - GitHub, 2026년 4월 14일 확인
• Turso Database Manual - GitHub, 2026년 4월 14일 확인
• JavaScript API reference - GitHub, 2026년 4월 14일 확인
• Turso examples - GitHub, 2026년 4월 14일 확인
• database-wasm-vite example - GitHub, 2026년 4월 14일 확인
• Python Bindings Examples - GitHub, 2026년 4월 14일 확인
• pgmicro: Missing PG Features - GitHub, 2026년 4월 14일 확인