훌륭한 SQL 클라이언트들은 이미 아주 많습니다. 하지만 저는 또 다른 하나를 만들었습니다. 오랫동안 "왜?"라는 질문에 대한 솔직한 답변은 그저 개인적인 "취향"이었습니다. 저는 텔레메트리(telemetry)도 없고 번거로운 절차도 없으며, 빠르고, 키보드 우선(keyboard-first) 방식이며, 모노스페이스(monospace) 환경에 최적화된 도구를 원했습니다. 사용자의 방해를 하지 않는 도구 말이죠. 자신을 위해 무언가를 만들기에는 충분한 이유지만, 다른 사람들이 관심을 갖게 만들기에는 약한 이유입니다.

그러다 AI 에이전트(AI agents)가 등장했고, 질문이 바뀌었습니다.

그 누구의 클라이언트도 대비하지 못한 새로운 문제

제 업무의 점점 더 많은 부분이 AI 에이전트를 통해 수행되고 있습니다. 그리고 점점 더 이 에이전트들은 "데이터베이스를 직접 다루기(touch the database)"를 원합니다. 마이그레이션(migration)을 확인하거나, 행(row)의 개수를 세거나, 코드를 작성하기 전에 데이터를 검증하는 작업 말이죠.

에이전트에게 이를 허용하는 순진한 방식은 정말로 우려스럽습니다. 에이전트에게 가공되지 않은 연결 자격 증명(connection credentials)을 넘겨주거나, 가드레일(guardrails) 없이 "이 SQL을 실행하라"는 도구를 연결하는 방식입니다. 이렇게 되면 확률론적 시스템(probabilistic system)이 당신의 데이터에 대해 모니터링되지 않는 쓰기 경로를 갖게 됩니다. 확신에 차서 틀린 UPDATE ... WHERE(또는 WHERE 절 누락) 명령 하나만 실행되어도, 당신은 백업에서 데이터를 복구해야 할 상황에 처하게 됩니다.

저는 에이전트에게 제 데이터베이스를 통째로 넘겨주고 싶지 않았습니다. 대신 규칙과 함께 "빌려주고" 싶었습니다. 제가 사용하던 클라이언트 중 그 개념을 중심으로 설계된 것은 없었기에, 그것이 제 클라이언트가 존재해야 하는 실제 이유가 되었습니다.

설계: 하나의 거대한 신뢰가 아닌, 세 가지 메커니즘

data-peek은 이제 로컬 MCP 서버를 실행할 수 있으므로, 어떤 MCP 클라이언트(Claude Code 등)든 당신의 연결을 대상으로 작동할 수 있습니다. 흥미로운 점은 프로토콜이 아니라 안전 모델(safety model)입니다. 세 가지 독립적인 메커니즘이 존재합니다:

1. 물리적으로 쓸 수 없는 읽기

읽기 도구(run_query, list_schemas, explain_query)는 단순히 읽기 전용(read-only)임을 약속하는 데 그치지 않습니다. 각 쿼리는 **항상 롤백(rolled back)**되는 트랜잭션(transaction) 내에서 실행되며, PostgreSQL의 경우 세션에 추가로 SET TRANSACTION READ ONLY가 설정됩니다. 결과는 500행으로 제한됩니다.

따라서 에이전트가 데이터를 수정하는 CTE(Common Table Expression)나 부수 효과(side effects)가 있는 함수와 같이 교묘한 것을 만들어내더라도, 트랜잭션은 어쨌든 폐기됩니다. "읽기 전용"은 SQL 문자열 매칭이 아니라 데이터베이스에 의해 강제됩니다. 심층 방어(Defense in depth)는 언제나 정규 표현식(regex)보다 강력합니다.

2. 쓰기 작업은 허가를 요청한다 — 인간으로부터

데이터를 변경할 수 있는 도구는 단 하나이며, 스스로 아무것도 실행하지 않습니다. execute_statement는 앱 내의 승인 대화 상자에서 정확한 SQL을 보여주고 사용자가 결정할 때까지 차단합니다. 승인하면 실행되고; 거부하면 실행되지 않으며; 60초 동안 무시하면 자동으로 거부됩니다.

에이전트가 제안하고, 당신이 처리합니다. 이 단일 상호작용이 전체 제품이 되었습니다—모델의 행동을 기대하는 것이 아니라 통제감을 느끼는 순간 말입니다.

3. 모든 것이 기억된다 — 변조 불가능하게

읽기 및 쓰기 작업(에이전트 또는 인간)을 포함한 모든 구문은 로컬 감사 로그(local audit log)에 기록됩니다. 각 항목은 이전 항목의 해시와 함께 해싱되어 체인을 형성합니다. 과거 항목을 편집하거나 삭제하면 그 지점부터 체인이 끊어지며, 이는 원클릭 검증(Verify) 기능을 통해 노출됩니다 (가장 먼저 깨진 항목을 보고합니다). 전체 내용을 CSV/JSON으로 내보낼 수 있습니다.

이는 로컬이며, 기본적으로 비활성화되어 있고, 삭제할 수 있습니다. 아무것도 업로드되지 않습니다—핵심은 제가 아니라 _당신_이 "에이전트가 실제로 무엇을 실행했는지"에 답할 수 있다는 점입니다.

사용 가능하게 만드는 지루한 보장들

• 기본적으로 비활성화됨(Off by default). 서버는 설정에서 켜야만 작동하며, 꺼지면 중단됩니다.
• 로컬호스트 전용(Localhost only). 127.0.0.1에 바인딩되어 있으며, 클라이언트를 취소할 수 있는 베어러 토큰으로 보호됩니다.
• 자격 증명은 절대 외부로 나가지 않음(Credentials never leave). 어떤 도구를 통해서도 연결 비밀번호가 노출되지 않습니다.

설정은 claude mcp add ...라는 단일 명령어를 생성하여 제공하며, 그러면 연결이 완료됩니다.

• UX가 곧 보안입니다. 읽기 전용 트랜잭션 (read-only transaction)과 해시 체인 (hash chain)은 공학적 기반을 지탱하는 요소이지만, 사람들이 이를 신뢰하게 만드는 것은 정확한 SQL을 보여주는 대화창입니다. 눈으로 확인할 수 있는 안전함이 말로만 듣는 안전함보다 강력합니다.
• 보증 범위는 데이터베이스마다 다릅니다. "읽기 전용"은 Postgres에서는 깔끔하고 강제 가능한 개념이지만, 다른 곳에서는 다소 모호할 수 있습니다. 따라서 보증은 계층적으로 이루어집니다. 가능한 경우 DB 수준에서, 그리고 백스톱 (backstop)으로서 문장 (statement) 수준에서 보증합니다. 하나의 메커니즘이 모든 엔진을 커버한다고 가정하는 것은 거짓말이 되었을 것입니다.
• 기본적으로 꺼져 있는 설정 (Off-by-default)은 기능이지, 회피가 아닙니다. 데이터베이스를 에이전트 (agent)에게 넘겨줄 수 있는 도구에게 가장 안전한 기본값은 "사용자가 요청하기 전까지는 아무것도 하지 않는 것"입니다.

그렇다면 — 왜 또 다른 SQL 클라이언트인가?

기존의 훌륭한 10여 개 클라이언트들은 데이터베이스를 쿼리하는 주체가 오직 "사용자 본인"인 세상을 위해 만들어졌기 때문입니다. 이제는 더 이상 그렇지 않으며, "에이전트를 허용하되, 사용자의 조건에 맞춰 허용한다"는 점은 기존 도구에 단순히 덧붙이는 체크박스 같은 문제가 아니라, 실제로 해결되지 않은 설계상의 문제임이 드러났습니다.

data-peek은 PostgreSQL, MySQL, SQL Server, 그리고 SQLite를 위한 빠른 데스크톱 SQL 클라이언트입니다. MIT 라이선스이며 개인 용도로는 무료로 사용할 수 있고, 지속성 보증 (continuity guarantee)이 제공되므로 도입하는 데 있어 큰 모험을 할 필요가 없습니다.

• 90초 데모:
• GitHub (MIT): https://github.com/Rohithgilla12/data-peek
• MCP 설정 가이드: https://datapeek.dev/docs/features/mcp-server

만약 다른 방식으로 에이전트에게 데이터베이스 접근 권한을 부여해 보셨다면, 쓰기 경로 (write path)를 어떻게 처리하셨는지 진심으로 듣고 싶습니다. 그 부분은 제가 아직 가장 고민이 많이 남은 영역이기 때문입니다.