에이전트가 데이터베이스에 질의하게 하세요,
허락하기 전까지는 읽기 전용으로
AgentsRoom은 MySQL, PostgreSQL, SQL Server, MongoDB, SQLite, Google BigQuery 연결을 관리하고, AI 코딩 에이전트가 그 연결에 질의를 던질 수 있게 합니다. 기본은 읽기 전용, 한 번에 구문 하나, 비밀번호는 손이 닿지 않는 곳에 둡니다.
실제 행을 읽을 수 있는 에이전트는 데이터를 짐작하지 않습니다. 그 행에 쓸 수 없는 에이전트는 한 줄씩 감시해야 할 위험이 아니게 됩니다.
AgentsRoom이 프라이빗 서브넷의 데이터베이스에 닿아 AI 에이전트의 읽기 전용 질의에 답하는 방식.
데이터를 볼 수 없는 AI 코딩 에이전트는 자기가 상상한 스키마를 상대로 코드를 씁니다. 없는 컬럼을 만들어 내고, 값이 일곱 개인 enum을 세 개라고 가정하고, 버그를 실제 행이 아니라 이론으로 설명합니다. 데이터베이스 연결을 주면 그 문제가 풀립니다. 동시에 그것은 도움이 되던 에이전트를 사고로 바꾸는 가장 빠른 길이기도 합니다. AgentsRoom은 이 긴장 위에서 만들어졌습니다.
연결은 다른 데이터베이스 클라이언트에서 하듯이 앱에 저장합니다. 엔진, 호스트, 포트, 사용자, 데이터베이스, 그리고 서버가 요구하면 TLS까지요. 데이터베이스가 공개 인터넷에서 닿지 않는다면, 이미 AgentsRoom에 저장해 둔 SSH 및 SSM 연결을 사용해 SSH 터널이나 AWS SSM 포트 포워딩 세션으로 연결의 경로를 잡습니다. 프라이빗 서브넷에 있는 데이터베이스가 세상에 열어 두지 않고도 질의할 수 있는 대상이 되는 방식입니다.
모든 연결은 읽기 전용으로 시작합니다. SELECT는 실행됩니다. 데이터를 바꾸는 구문은 그 연결을 쓰기 가능으로 만들고 작업을 확인하기 전까지 실행되지 않습니다. 호출당 구문은 하나만 받아들이므로 세미콜론 뒤에 무언가가 숨을 수 없고, 결과 집합에는 상한이 있어 넓은 질의가 에이전트나 창을 뒤덮지 못합니다. 연결에 프로덕션 표시를 달 수도 있는데, 그러면 실수로 확인을 눌러 버리기가 더 어려워집니다.
읽는 것이 전부는 아닙니다. 한 컴퓨터에서 저장한 연결은 다른 컴퓨터에도 나타나므로, 데이터베이스는 컴퓨터마다가 아니라 한 번만 설정하면 됩니다. 그리고 데이터베이스는 파일로 내보내고, 파일에서 되돌리고, 같은 터널을 지나 다른 서버 위로 그대로 복사할 수 있습니다. 그동안 앱 밖에서 해야 했던 작업들입니다.
에이전트가 운전한다고 전제한 데이터베이스 클라이언트
MySQL, PostgreSQL, SQL Server, MongoDB, SQLite, Google BigQuery. 서버 엔진은 프라이빗 네트워크에서도 닿고, 가드레일은 기본으로 켜져 있습니다.
MySQL, PostgreSQL, SQL Server, MongoDB 연결
데이터베이스마다 연결을 저장하세요. 호스트, 포트, 사용자, 열 데이터베이스, 그리고 서버가 요구할 때의 TLS까지요. 로컬 데이터베이스, 스테이징, 프로덕션 리플리카가 같은 목록에 모이고, 다시 입력하는 대신 고르기만 하면 됩니다.
프라이빗 데이터베이스에 닿기
프라이빗 서브넷의 데이터베이스는 특별한 경우가 아닙니다. 연결의 경로를 SSH 터널이나 AWS SSM 포트 포워딩 세션으로 잡으면, 앱에 이미 저장해 둔 SSH 및 SSM 연결을 재사용해 AgentsRoom이 대신 열어 줍니다. Google Cloud SQL 인스턴스는 연결 이름으로 접속하며, Cloud SQL Auth Proxy를 통해 사용자 본인의 gcloud 로그인을 사용하고 아무것도 저장하지 않습니다.
기본은 읽기 전용
새 연결은 읽기만 할 수 있고 그 외에는 아무것도 하지 못합니다. 질의는 행을 반환하고, 데이터를 바꾸는 구문은 거부됩니다. 안전 모드를 켜는 것을 누군가 기억할 필요가 없습니다. 모든 연결이 안전 모드에서 출발하니까요.
쓰기 앞에 자물쇠 두 개
쓰기에는 하나가 아니라 두 번의 의도적인 행동이 필요합니다. 연결을 쓰기 가능으로 바꿔야 하고, 작업 자체도 명시적으로 확인해야 합니다. 무심코 한 번 클릭한 것이 WHERE 절 없는 UPDATE로 이어질 수 없습니다.
호출당 구문 하나
한 번의 호출에는 정확히 구문 하나만 담깁니다. 세미콜론 뒤에 쌓인 것은 실행되지 않고 거부되므로, 읽기처럼 보이는 읽기가 두 번째 구문을 몰래 끼워 올 수 없습니다. 그 위에 결과 집합 상한까지 더해집니다.
프로덕션에는 표시가 붙습니다
연결에 프로덕션 표시를 달면 확인 절차가 더 까다로워집니다. 중요한 데이터베이스가 로컬 사본과 똑같아 보이지 않게 되죠. 긴 하루의 끝에 있는 당신에게도, 작업 목록을 훑어 내려가는 에이전트에게도요.
어느 컴퓨터에서나 같은 연결
사무실 컴퓨터에서 저장한 연결이 노트북에도 그대로 있습니다. 이름, 호스트, 포트, 사용자, 기본 데이터베이스, 그리고 거쳐 가는 터널까지요. 뒤에 남는 것은 비밀번호 하나뿐입니다. 입력한 컴퓨터에 암호화된 채로 남으니, 각 컴퓨터가 한 번씩만 물어봅니다.
내보내기, 가져오기, 복사
데이터베이스를 .sql 파일로 덤프하고, 그런 파일을 데이터베이스에 다시 밀어 넣고, 한 데이터베이스를 다른 데이터베이스 위로 그대로 복사할 수 있습니다. 대상은 덮어쓰기 전에 백업되고, 아예 통째로 갈아 끼우는 것은 따로 확인받는 별개의 결정입니다.
에이전트는 데이터베이스에 질의할 뿐, 비밀번호를 쥐지 않습니다
데이터베이스 자격 증명은 AgentsRoom이 보관할 뿐 넘겨주지 않습니다. 에이전트가 이름으로 아는 연결에 질의 실행을 요청하면, 앱이 연결을 열고 구문을 실행해 행을 돌려줍니다. 비밀번호는 에이전트가 받는 것에도, 에이전트가 쓰는 질의에도, 에이전트가 남기는 대화에도 들어 있지 않습니다.
읽기 전용 규칙이 나머지 절반이고, 에이전트에게 그것은 말로 빠져나갈 수 있는 것이 아닙니다. 에이전트가 질의에 쓰는 도구는 두 가지가 모두 참이 아니면 읽기 외에는 전부 거부합니다. 연결이 쓰기 가능이어야 하고, 그 연결에 “에이전트 쓰기 허용”을 켜 두었어야 합니다. 이 옵션은 기본적으로 꺼져 있고, 확인은 에이전트의 프로세스가 아니라 데스크톱 앱에서 이루어집니다. 콘솔에서 사용자가 직접 하는 쓰기는 여전히 명시적인 확인을 요구하며, 연결에 프로덕션 표시가 붙어 있으면 그 확인은 의도적으로 더 까다롭습니다. 연결을 에이전트의 쓰기에 열면 그 쓰기는 이 확인 없이 실행되므로, 에이전트에게 맡길 수 있는 데이터베이스에만 이 옵션을 쓰세요. 그 밖의 모든 곳에서는 잘못된 질의의 최악의 결과가 테이블을 잃는 것이 아니라 틀린 답으로 남습니다.
구문 하나 규칙이 고전적인 빈틈을 막습니다. 구문 하나를 담은 호출은 세미콜론과 두 번째 구문으로 늘릴 수 없으므로, 리뷰에서 무해해 보이던 질의가 실행 시점에 다른 일을 할 수 없습니다. SQL Server에는 그 세미콜론이 필요 없으므로, 거기서 읽기란 쓰기나 트랜잭션 키워드가 어디에도 없는 SELECT 또는 WITH이며, 항상 롤백되는 트랜잭션 안에서 실행됩니다. 여기에 결과 집합 상한이 더해지면, 실수는 데이터를 통째로 퍼 가는 일이 아니라 그냥 실수로 남습니다.
엔진 여섯, 그리고 빠져 있는 것들도 이름을 밝힙니다
MySQL과 MariaDB, PostgreSQL, SQL Server(Azure SQL과 Amazon RDS for SQL Server 포함), MongoDB, SQLite, 그리고 Google BigQuery. 변환 계층을 하나 두는 대신 엔진마다 전용 드라이버를 씁니다. 실제로 서로 다르기 때문입니다. PostgreSQL이나 SQL Server 세션은 데이터베이스 하나에 묶이고, MongoDB는 SQL이 아니라 질의를 받으며, T-SQL은 두 구문 사이에 세미콜론이 필요 없고, 내보내기는 그 엔진에 함께 들어 있는 도구로 돌아가고, SQLite는 호스트도 사용자도 비밀번호도 없는, 컴퓨터에 있는 파일일 뿐이며, BigQuery 연결은 Google Cloud 프로젝트 하나와 기본 데이터 세트로 이루어지고, 본인의 Google 로그인(gcloud auth application-default login)으로 접속하며 키는 저장하지 않습니다. 서버 엔진 넷은 서버에 직접 닿고, 서버가 공개 인터넷에 노출되어 있지 않다면 SSH 터널이나 AWS SSM 포트 포워딩 세션을 통해 닿습니다.
Oracle, Redis를 비롯한 나머지는 지원하지 않습니다. SQL Server에서는 SQL 로그인으로 접속하며(Windows, Active Directory, Entra ID 인증은 제공하지 않습니다), 내보내기, 가져오기, 복사가 없습니다. BigQuery에서는 Google이 모든 질의를 읽은 바이트 수에 따라 과금하므로, 연결마다 질의당 과금 상한이 있습니다(기본 1 GiB, 조정 가능). 상한을 넘는 질의는 과금되지 않고 거부됩니다. 테이블 열기는 무료이며 읽기 전용이고, 에이전트는 같은 가드레일 아래에서 같은 db_list, db_schema, db_query 도구를 쓰며 질의마다 읽은 바이트 수를 확인합니다. 여기에도 내보내기, 가져오기, 복사는 없습니다. 이 사실은 다운로드한 뒤가 아니라 그 전에 아셔야 합니다. 다음에 어떤 엔진이 올지는 사람들이 요청하는 것으로 정해지므로, 필요한 엔진이 빠져 있다면 공개 백로그에 어느 것인지 남겨 주세요. 그대로 집계됩니다.
내 데이터베이스 엔진 요청하기데이터베이스를 읽기만 하지 말고, 옮기세요
데이터베이스를 파일로 내보내세요. 파일을 데이터베이스로 가져오세요. 아니면 이미 저장해 둔 SSH 터널이나 AWS SSM 세션을 지나서라도, 한 데이터베이스를 다른 데이터베이스 위로 바로 복사하세요. 엔진마다 자기 공식 도구를 쓰고 디스크로 스트리밍하므로, 수 기가바이트짜리 데이터베이스는 강제 종료가 아니라 진행 표시줄이 됩니다.
이 도구들은 AgentsRoom이 아니라 데이터베이스에 함께 들어 있습니다. mysqldump와 mysql, pg_dump와 psql, mongodump와 mongorestore가 그렇습니다. SQL Server에는 데이터베이스 전체를 스트리밍하는 같은 역할의 도구가 없으므로, SQL Server 연결에는 내보내기, 가져오기, 복사가 없습니다. 도구가 컴퓨터에 없을 때 앱은 어느 것이 없는지 정확히 말하고, 도구가 들어 있는 폴더를 직접 지정하게 해 줍니다. 데이터베이스 클라이언트라면 그래야 하니까요. Dock이나 시작 메뉴에서 실행된 앱에는 최소한의 PATH만 보이기 때문에, 그러지 않으면 도구가 멀쩡히 있는 컴퓨터에서도 없다고 우기게 됩니다.
잘못된 클릭 한 번이 하루를 날리는 곳은 복사입니다. 그래서 복사는 잘 풀리는 경우가 아니라 그 지점을 기준으로 만들어졌습니다.
- 읽기 전용 연결은 무언가 열리기도 전에 가져오기를 곧바로 거부합니다.
- 구문이 하나라도 적용되기 전에, 대상 데이터베이스는 당신이 고른 파일로 덤프됩니다.
- 확인 창은 연결 이름과 데이터베이스 이름을 함께 보여 주고, 연결에 프로덕션 표시가 달려 있으면 더 크게 경고합니다.
- 대상 데이터베이스를 삭제하고 다시 만드는 것은 별도의 옵션이며, 프로덕션 연결에서는 데이터베이스 이름을 직접 입력해야 합니다.
프라이빗 데이터베이스에서 답까지
연결을 저장하고, 경로를 잡고, 직접 질의하거나 에이전트에게 맡기세요.
연결을 저장하세요
데이터베이스를 추가하세요. 호스트, 포트, 사용자, 데이터베이스 이름, 그리고 서버가 요구하면 TLS까지요. 나중에 알아볼 이름을 붙이고, 프로덕션이라면 프로덕션으로 표시하세요.
프라이빗이라면 경로를 잡으세요
데이터베이스에 직접 닿을 수 없다면, AgentsRoom에 이미 저장된 연결로 만든 SSH 터널이나 AWS SSM 포트 포워딩 세션을 연결에 지정하세요. 프라이빗 서브넷의 데이터베이스가 외부에 노출하지 않고도 닿을 수 있는 대상이 됩니다. Google Cloud에서는 대신 Cloud SQL 인스턴스를 선택하세요. AgentsRoom이 Cloud SQL Auth Proxy를 대신 시작합니다.
직접 질의하거나, 에이전트에게 맡기세요
앱에서 구문을 실행하거나, 에이전트가 MCP로 실행하게 하세요. 바꾸기 전까지는 읽기 전용, 호출당 구문 하나, 상한이 걸린 결과 집합, 그리고 모든 쓰기와 내 데이터 사이에 서 있는 명시적인 확인.
에이전트에게 진짜 행이 필요한 순간
프로덕션 데이터를 읽는 것이 수정까지 가는 가장 짧은 길인 순간들.
실제 데이터로 디버깅
버그가 계정 몇 개에서만 나타납니다. 에이전트에게 그 행들을 읽게 하면, 데이터가 어떻게 생겼을지에 대한 이론 세 가지를 내놓는 대신 로직을 깨뜨리는 값을 찾아냅니다.
공개되지 않은 데이터베이스
데이터베이스가 공개 엔드포인트 없이 프라이빗 서브넷에 있습니다. 저장된 연결로 만든 SSH 터널이나 AWS SSM 세션으로 경로를 잡으면, 인터넷에 포트를 열지 않고도 질의할 수 있습니다.
에이전트가 짐작하지 말고 확인하게
마이그레이션이나 질의를 쓰기 전에, 에이전트는 실제로 저장된 것을 들여다볼 수 있습니다. 읽고, 보고하며, 그 연결을 에이전트의 쓰기에 열어 두지 않았다면 그러는 동안 무언가를 바꿀 방법이 없습니다.
쓰기 위험 없는 프로덕션
프로덕션을 읽는 일은 자주 필요하지만, 작업 도중에 프로덕션에 쓰는 일은 거의 필요하지 않습니다. 연결에 프로덕션 표시를 달고 읽기 전용으로 두면, 조사와 파손 사이의 차이가 누군가의 주의력에 기대지 않게 됩니다.
스테이징을 진짜 데이터로 새로 채우기
버그가 진짜 행 위에서만 재현됩니다. 이미 저장해 둔 터널을 지나 데이터베이스를 스테이징 서버 위로 복사하세요. 거기 있던 것은 먼저 덤프해 둡니다.
노트북을 열면 모든 것이 그대로
연결은 계정을 따라다닙니다. 같은 호스트, 같은 터널, 같은 읽기 전용과 프로덕션 표시까지요. 동기화된 비밀번호를 켜면 비밀번호도 종단 간 암호화된 채 따라오므로 아무것도 다시 입력하지 않습니다. 켜지 않으면 컴퓨터마다 비밀번호를 한 번씩 묻습니다.
에이전트는 데이터베이스에 어떻게 질의하나요?
AgentsRoom MCP를 통해, 네 개의 도구로요. db_list는 저장된 연결과 그 메타데이터를 반환하고, db_schema는 SQL 한 줄 없이 스키마와 테이블과 컬럼을 훑고, db_query는 구문 하나를 실행해 행을 반환하며, db_connection_new는 아직 저장하지 않은 데이터베이스를 제안합니다. AgentsRoom은 앞단에 SSH 터널이나 AWS SSM 세션이 있다면 그것까지 포함해 연결을 엽니다. 에이전트에게 돌아가는 것은 결과 집합이지 자격 증명이 아닙니다.
에이전트는 쓰기 가능으로도 설정된 연결에서 “에이전트 쓰기 허용”을 켰을 때만 쓸 수 있습니다. 직접 켜야 하는 이 옵션은 기본적으로 꺼져 있으며, 연결과 함께 계정 전체에 동기화됩니다. 켜면 쓰기가 즉시 실행되므로, 그 데이터베이스를 맡길 만큼 에이전트를 신뢰할 때만 사용하세요. 데스크톱 앱은 이 권한을 메인 프로세스에서 확인하며, db_query는 여전히 호출당 구문 하나만 받습니다.
데이터베이스 등록도 에이전트에게 전적으로 맡길 수 있습니다. db_connection_new는 검토를 거치는 경로를 유지합니다. 호스트, 사용자, 그리고 데이터베이스에 닿을 SSH 또는 AWS SSM 연결로 생성 폼을 미리 채워 열고, 검토하고 비밀번호를 입력하고 저장하는 것은 사용자이며, 저장하기 전까지는 아무것도 기록되지 않습니다. 설정의 “에이전트가 연결을 관리할 수 있음”(기본값 켜짐)을 끄지 않는 한 db_connection_save는 연결을 곧바로 기록하는데, 그때도 비밀번호는 대화를 오가지 않고, 에이전트가 이름만 말한 보관소 시크릿에서 복사됩니다. 에이전트는 데이터를 두고 추론하는 데 필요한 것을 얻고, 그 접근이 보통 사고로 이어지는 경로는 어느 것도 열려 있지 않습니다.
에이전트가 실행하는 모든 쿼리도 볼 수 있습니다. db_query와 db_schema 호출은 SQL과 반환된 처음 몇 행과 함께 오른쪽 패널의 “활동” 탭에 도착하며, 데이터베이스마다 하나의 기록으로 정리됩니다. 에이전트의 아바타가 “데이터베이스” 버튼에 표시되고, 데이터베이스 목록에도 “에이전트 작업 중” 배지와 함께 표시됩니다. 모바일 앱의 에이전트 카드에서 휴대폰으로도 따라볼 수 있습니다. 이 기록은 내 컴퓨터와 휴대폰 사이에서만 오가며, 종단 간 암호화되고 시크릿은 가려집니다. 어떤 결과 집합도 서버에 저장되지 않습니다.
AgentsRoom MCP 살펴보기db_query와 db_schema 호출이 쌓이는 그 “활동” 탭을, 여기서는 저장된 SSH 서버에서 촬영했습니다. 에이전트가 명령 세 개를 실행하면 각각 출력과 종료 코드, 소요 시간과 함께 도착하고, 그다음 그 연결의 기록이 전체로 열립니다. 이 기록은 내 컴퓨터에 남습니다.
자주 묻는 질문
다른 질문하기어떤 데이터베이스를 지원하나요?
AI 에이전트가 내 데이터베이스에 쓸 수 있나요?
프라이빗 서브넷의 데이터베이스에 어떻게 닿나요?
에이전트가 데이터베이스 비밀번호를 보나요?
에이전트가 한 번에 여러 구문을 실행할 수 있나요?
연결에 프로덕션 표시를 달면 무엇이 달라지나요?
행을 아주 많이 반환하는 질의는 어떻게 되나요?
에이전트가 데이터베이스 연결을 추가할 수 있나요?
에이전트는 내 스키마를 어떻게 파악하나요?
데이터베이스 연결이 여러 컴퓨터 사이에서 동기화되나요?
데이터베이스를 덤프해서 다른 곳으로 가져올 수 있나요?
내 연결을 보관하는 계정은 어떻게 보호되나요?
스크린샷
앱의 실제 화면으로, 이 기능이 발전할 때마다 추가됩니다.
자신의 Google 로그인으로 Google BigQuery에 연결 
연결당 하나의 BigQuery 쿼리가 청구할 수 있는 한도를 설정 
직접 TLS 연결은 서버 인증서를 검증하며, 자체 서명 서버에 대한 옵트인 옵션 제공
이런 기능도 마음에 드실 거예요
AWS SSM으로 RDS 연결
공개 엔드포인트가 없는 Amazon RDS 인스턴스에 내 컴퓨터에서 바로 닿으세요. aws ssm start-session과 AWS-StartPortForwardingSessionToRemoteHost 문서를 사용합니다. 유지할 배스천도, VPN도, 인바운드 SSH 규칙도 없습니다. AgentsRoom이 루프백 포트에 세션을 열고 그 위로 데이터베이스 클라이언트를 연결합니다. MySQL, PostgreSQL, SQL Server, MongoDB를 지원하므로 RDS MySQL, RDS PostgreSQL, RDS for SQL Server, Aurora, DocumentDB가 대상입니다.
Cloud SQL Auth Proxy
Cloud SQL for MySQL 또는 PostgreSQL 인스턴스에 내 컴퓨터에서 바로 닿으세요. 프라이빗 IP도, 배스천 VM 없이도 가능합니다. AgentsRoom은 gcloud의 Application Default Credentials(애플리케이션 기본 사용자 인증 정보)로 루프백 포트에 Cloud SQL Auth Proxy를 실행하고, IAM 데이터베이스 인증을 지원하며, AI 에이전트는 읽기 전용으로 질의할 수 있습니다.
SSH 연결
SSH 연결을 저장하고, SSH로 내장 터미널을 열어 Claude Code, Codex, Antigravity CLI를 원격 서버나 VPS에서 바로 실행하세요. SSH 키 또는 비밀번호 인증, 프로젝트별 연결 프로필을 지원하며, 별도의 SSH 클라이언트가 필요 없습니다.
시크릿 관리자
API 키, 토큰, 비밀번호를 OS 키체인에 저장하고, 개발 명령과 에이전트 환경에서 {{secret:NAME}}로 참조하면 AgentsRoom이 실행 시점에 실제 값을 채웁니다. 에이전트는 이름만 볼 뿐 값은 보지 못하며, 서버로 동기화되는 것은 아무것도 없습니다.
Dev Terminals
프로젝트별 터미널 관리자이자 프로세스 실행기. 백엔드, 프론트엔드, 워커를 로컬에서도 원격 서버에서도 한 번의 클릭으로 시작하세요.
AgentsRoom MCP
에이전트가 AgentsRoom 자체를 조종하게 하는 MCP 서버. 프로젝트, 터미널, 백로그, 연결까지, 함께 따라오는 가드레일과 함께요.
에이전트에게 줄 것은 데이터이지 키가 아닙니다
AgentsRoom을 다운로드하고, MySQL, PostgreSQL, SQL Server, MongoDB, SQLite, Google BigQuery 연결을 저장하고, 서버 연결에는 SSH 터널이나 AWS SSM 세션으로 닿은 뒤, 에이전트가 질의하게 하세요. 연결을 에이전트의 쓰기에 열어 주지 않는 한 읽기 전용입니다.
컴패니언 앱: 이동 중에도 에이전트를 모니터링
Claude, Codex, Antigravity CLI 또는 다른 AI 공급자를 사용하세요.
버그와 요청을 공개 백로그로 바로 보내세요.
