Bytebase에서 우리는 하루 종일 데이터베이스 액세스 제어(access control) 작업을 수행하므로, AI 에이전트를 실제 데이터베이스에 연결하는 것은 저에게 가설적인 이야기가 아닙니다. Postgres MCP 서버를 선택하는 것은 연결된 데이터베이스에 실제로 중요한 데이터가 들어있기 전까지는 쉬운 일입니다. 일회용 로컬 데이터베이스에서는 잘 작동하던 것이 운영 환경(production)에서는 매우 다르게 동작합니다. 저는 신뢰할 수 있는 로컬 개발과 운영 환경 사이의 이러한 차이를 기준으로 삼고 있습니다. 대부분의 서버는 전자의 경우에는 훌륭하지만, 후자의 경우에는 조용히 위험할 수 있습니다.

안전하게 서버를 구축하는 것은 보기보다 어렵습니다. Anthropic의 자체 레퍼런스 Postgres 서버는 사용자들이 해당 서버의 "읽기 전용(read-only)" 모드가 COMMIT; DROP SCHEMA public CASCADE; 명령을 기꺼이 수락한다는 사실을 발견한 후 아카이브되었습니다. 읽기 전용이었지만, 실제로는 그렇지 않았던 셈입니다. 그래서 저는 기능 목록보다는 두 가지 질문에 더 집중합니다: 에이전트가 실제로 무엇을 할 수 있는가, 그리고 사후에 에이전트가 무엇을 했는지 증명할 수 있는가. 아래의 세 가지 서버는 이 질문들에 대해 매우 다르게 답합니다.

pgconsole

pgconsole은 세 가지 중 가장 최신입니다. 이는 셀프 호스팅(self-hosted)이 가능한 Postgres 콘솔로, 기본적으로 웹 SQL 에디터이지만 내장된 MCP 엔드포인트를 통해 에이전트에게 연결 권한을 넘겨주기도 합니다. 중요한 점은 에이전트가 연결 문자열(connection string)을 절대 볼 수 없다는 것입니다. 에이전트는 토큰을 받으며, 모든 호출은 콘솔을 클릭하는 사람이 사용하는 것과 동일한 액세스 규칙 및 감사 로그(audit log)를 통해 실행됩니다. 에이전트는 pgconsole과 통신하고, pgconsole은 데이터베이스와 통신합니다.

대부분의 데이터베이스 도구는 두 가지 극단 중 하나에 속합니다. 구축을 위해 실제 인프라가 필요한 무거운 플랫폼이거나, 액세스 제어가 전혀 없는 가벼운 에디터입니다. pgconsole은 그 사이의 어색하지만 유용한 중간 지점에 위치합니다. 즉, 팀 제어 기능이 내장된 Postgres 에디터이면서 직접 실행할 수 있는 단일 바이너리로 제공됩니다.

액세스 제어 (Access control)가 이 도구의 핵심이며, 내장된 위임 (Delegation) 및 감쇄 (Attenuation) 기능을 통해 에이전트 (Agent)를 사후에 덧붙이는 것이 아니라 일급 주체 (First-class principals)로 취급합니다.

주요 특징 (Key Features):

• 단일 셀프 호스팅 (Self-hosted) 바이너리. 연결, 사용자 및 액세스 규칙은 GitOps 스타일의 버전 관리되는 pgconsole.toml에 저장되며, npx 또는 Docker로 실행합니다. 별도로 관리해야 할 데이터베이스가 없습니다.
• 세밀한 기본 거부 (Default-deny) 액세스. 7가지 독립적인 권한 (읽기, 쓰기, DDL, 관리자 등)이 연결별로 범위가 지정되며, 규칙이 허용하지 않는 한 아무것도 허용되지 않습니다. pgconsole은 모든 문장을 실행하기 전에 파싱 (Parse)하므로, 파괴적인 쿼리가 읽기 전용 도구를 통해 몰래 실행될 수 없습니다.
• 일급 정체성으로서의 에이전트. 에이전트는 자체 주체로서 인증하거나 사용자를 대신하여 동작합니다. 위임 모드에서는 해당 사용자의 권한을 상속받되, 권한은 사용자의 권한보다 낮게 제한되며 절대 높을 수 없고, 사용자가 액세스 권한을 잃는 즉시 에이전트도 권한을 잃습니다.

alice-claude 에이전트는 Alice를 대신하여 동작하며, 단일 연결에 대해 읽기 전용으로 제한됩니다:

[[agents]]
id = "alice-claude"
on_behalf_of = "alice@example.com"
...

가장 적합한 대상: 전체 플랫폼을 구축하지 않고도 셀프 호스팅 가능한 Postgres 에디터와 진정으로 거버넌스(Governed)가 적용된 에이전트 경로 (별도의 정체성, 위임, 최소 권한 제한)를 원하는 팀.

한 가지 솔직한 주의사항: 아직 초기 단계입니다. 별(Star) 개수는 약 120개이며, Apache-2.0 라이선스를 따르고 최근에 첫 릴리스가 이루어졌습니다.

결론 (Verdict): 이 도구를 실행해야 하는 이유는 바로 액세스 모델에 있습니다. 별도의 에이전트 정체성, 대리 위임 (On-behalf-of delegation), 그리고 신뢰가 아닌 SQL 파서 (SQL parser)에 의해 강제되는, 에이전트가 대리하는 인간과 같거나 그보다 낮은 수준으로 유지되는 권한 감쇄 (Attenuation)가 특징입니다. 이 포스트에서 단 하나의 설계를 기억해야 한다면, 바로 이것입니다.

Supabase MCP

Supabase MCP는 단순히 하위의 Postgres 데이터베이스뿐만 아니라 인증 (auth), 스토리지 (storage), 엣지 함수 (edge functions), 브랜치 (branches) 등 Supabase 프로젝트 전체를 관리합니다. 이러한 광범위함은 매력인 동시에 제약이기도 합니다. 오직 Supabase에서만 작동하기 때문입니다.

이는 오픈 소스 Firebase 대안인 Supabase에서 제공하는 퍼스트 파티 (first-party) 서버이며, 모든 것을 하나의 관리형 표면 (managed surface)으로 취급하는 회사의 철학을 계승합니다. 그렇기에 단순한 SQL을 넘어 인증, 스토리지, 함수 영역까지 깊숙이 도달합니다.

주요 특징:

• 광범위한 범위: 8개의 기능 그룹(계정, 데이터베이스, 디버깅, 개발, 엣지 함수, 브랜칭, 문서, 스토리지)에 걸친 29개의 도구를 제공하며, 단순 SQL을 넘어 마이그레이션 (migrations), TypeScript 타입 생성 (type generation), 서버리스 함수 (serverless functions)를 아우릅니다.
• 호스팅 방식: OAuth 2.1 및 자동 토큰 갱신 (token refresh)을 지원하여 로컬 서버, 바이너리 또는 하드코딩된 자격 증명이 필요하지 않습니다.
• 대부분의 서버보다 강력한 보안 기본 설정: 프로젝트 범위 지정 (project scoping), 기능 그룹 제한, 전용 읽기 전용 역할 (supabase_read_only_user)을 제공합니다.

추천 대상: 에이전트가 단순히 쿼리를 날리는 것을 넘어 프로젝트 전체를 관리하기를 원하는, 이미 Supabase를 사용 중인 팀.

결론: Supabase가 귀하의 플랫폼이라면 탁월한 선택이지만, 그렇지 않다면 무의미합니다. 알아두어야 할 두 가지 사항이 있습니다: 기본 도구 세트가 무겁다는 점(~19.3k 토큰, 선택적 로딩 시 ~4.2k로 감소)과 execute_sql 뒤에 있는 관리 API (Management API) 엔드포인트가 아직 베타 버전이며 행 제한 (row limits)이 없다는 점입니다. 대부분의 서버보다 더 많은 가드레일 (guardrails)을 갖추고 있습니다. 하지만 이곳의 모든 서버와 마찬가지로, 프롬프트 인젝션 (prompt injection)을 완화할 뿐 완전히 해결하지는 못합니다.

Postgres MCP Pro

Crystal DBA에서 개발한 Postgres MCP Pro는 Postgres MCP 서버를 검색할 때 보통 가장 먼저 나타나는 결과입니다. 이 서버는 호스트 중립적(host-neutral)이어서 어떤 Postgres든 지정하기만 하면 되며, 대부분의 서버보다 더 나아간 기능을 제공합니다. 다른 서버들이 "이 쿼리를 실행해" 수준에서 멈출 때, 이 서버는 DBA의 튜닝 도구 모음(tuning toolkit)을 가져옵니다.

Crystal DBA는 자사의 AI 기반 Postgres 툴링으로 가는 진입로(on-ramp)로서 이를 오픈 소스로 공개했습니다. 그 후 2025년 9월에 Temporal이 이 회사를 인수했으며, 그 이후로 서버의 활발한 개발은 대부분 중단되었습니다. 이 점은 중요한 문제이며, 나중에 다시 언급하겠습니다.

주요 특징 (Key Features):

• 성능 분석 (Performance analysis): 인덱스 튜닝 (index tuning), EXPLAIN 실행 계획 검사 (inspection), 그리고 데이터베이스 상태 점검 (health checks). 이것이 진정한 차별점입니다.
• 두 가지 액세스 모드: 제한 없음 (unrestricted, 전체 읽기/쓰기, 임의의 SQL) 및 제한됨 (restricted, 읽기 전용, 쿼리 실행 시간 제한 포함).

가장 적합한 대상 (Best For): 에이전트가 단순히 행(row)을 읽는 것을 넘어, 느린 쿼리를 진단하거나 인덱스를 제안하기를 원하는 개발자 및 DBA.

이 서버를 선택하기 전에 고려해야 할 두 가지 사항이 있습니다:

• 기본 설정이 제한 없음(unrestricted)이며, 모든 README 예제에서 이를 사용합니다. 설치 직후 에이전트는 전체 쓰기 권한과 임의의 SQL 실행 권한을 갖게 됩니다. 개발 샌드박스(dev sandbox) 이상의 용도로 사용하려면 --access-mode=restricted를 설정하십시오. 기본적으로 안전 장치를 해제한 상태로 배포하는 것은 제가 동의하지 않는 선택입니다.
• 인수 이후 개발이 정체되었습니다. 마지막 태그 릴리스(v0.3.0)는 2025년 5월이었으며, 2025년 9월 Temporal 거래 이후 커밋이 급감했습니다(마지막 커밋은 2026년 1월에 이루어졌습니다). streamable-HTTP 전송과 같이 병합된 작업들이 릴리스나 Docker 이미지에 포함되지 않았으며, 사용자들이 이를 요청하고 있습니다, SSE 환경에서의 커넥션 풀 누수(connection-pool leak under SSE)를 포함하여 63개의 이슈가 해결되지 않은 채 열려 있으며, 이 누수 이슈는 가장 많은 반응을 얻고 있습니다.

결론(Verdict): 튜닝 기능은 진정으로 훌륭하며, 여전히 실무 작업에 활용할 만한 가치가 있는 이유입니다. 하지만 운영 환경(production)에 도입하기 전에는 첫날부터 제한 없는 기본 설정을 변경하고, 검증된 버전을 고정(pin)하며, 정체된 유지보수 상태를 반드시 고려하십시오.

Postgres MCP 서버 비교표

요약 (Summary)

이 세 가지 중 완성된 것은 없습니다. 본인의 위치에 따라 선택하십시오:

• pgconsole는 가장 강력한 액세스 모델(별도의 에이전트 ID, 대리 수행 (on-behalf-of), 권한 축소 (attenuation))을 갖추고 있지만, 가장 최근에 출시되었습니다. 관리된 에이전트 경로를 가진 셀프 호스팅 (self-hosted) 에디터에 적합합니다.
• Supabase MCP는 Supabase를 사용하고 있다면 가장 완성도가 높습니다. 이미 Supabase를 사용 중일 때 적합합니다.
• Postgres MCP Pro는 가장 풍부한 툴킷을 보유하고 있지만, 인수(acquisition)로 인해 모멘텀을 잃었습니다. 제한 없는 기본 설정을 해제한 후, 개발 환경에서 느린 쿼리를 진단할 때 적합합니다.

세 가지 모두 노트북에서는 훌륭하지만, 동일한 구조적 이유로 프로덕션 (production) 환경에서는 더 위험해질 수 있습니다. Simon Willison은 이를 치명적인 삼중주 (lethal trifecta)라고 명명했습니다. 즉, 개인 데이터에 접근할 수 있는 에이전트, 신뢰할 수 없는 입력에 대한 노출, 그리고 데이터를 외부로 다시 보낼 수 있는 방법이 결합된 상태를 의미합니다. 올바르게 범위가 지정된 자격 증명 (credential)이라 할지라도 당신을 구원해주지는 못하는데, 공격은 권한이 아니라 프롬프트 (prompt)를 통해 들어오기 때문입니다. 따라서 진짜 테스트는 "에이전트가 데이터베이스에 쿼리를 날릴 수 있는가"가 아닙니다. "프롬프트가 에이전트에게 해서는 안 될 일을 시켰을 때 어떤 일이 발생하는가"입니다.