내 RDS 인스턴스에는 공개 엔드포인트가 없습니다.
배스천 없이 AWS SSM으로 닿으세요.
AgentsRoom은 내 데이터베이스로 향하는 AWS Session Manager 포트 포워딩 세션을 열고 그 위로 SQL 클라이언트를 연결합니다. 이 세션은 AWS-StartPortForwardingSessionToRemoteHost 문서와 함께 aws ssm start-session을 실행하며, 머신에 이미 설정된 AWS 프로필로 인가됩니다.
데이터베이스는 프라이빗 서브넷에 그대로 있고, 보안 그룹도 닫힌 채로 있으며, 인터넷에 새로 노출되는 것은 없습니다. 달라지는 것은 이제 드디어 질의할 수 있다는 점, 그리고 AI 코딩 에이전트도 읽기 전용으로 질의할 수 있다는 점입니다.
AgentsRoom이 인터넷에 아무것도 열지 않고 AWS Systems Manager를 통해 프라이빗 서브넷의 RDS 인스턴스에 닿는 방식.
흔해서 지루할 정도인데, 막상 부딪히면 오후 하나를 통째로 삼키는 구성이 있습니다. Amazon RDS 인스턴스가 프라이빗 서브넷에 있습니다. 공개 엔드포인트는 없습니다. 보안 그룹은 애플리케이션에서 오는 트래픽만 받아들이고 그 외에는 아무것도 받지 않습니다. 그 VPC 어디에도 인바운드 SSH 포트는 없습니다. 누군가 옳은 일을 해서 닫아 두었으니까요. 그런데 지금, 버그 하나를 이해하려면 행 세 개를 봐야 합니다.
전송 문제는 AWS Systems Manager Session Manager가 이미 풀어 두었습니다. VPC 안의 관리형 EC2 노드는 내 컴퓨터의 로컬 포트를, 그 노드가 닿을 수 있는 제3의 호스트로 전달할 수 있습니다. 프라이빗 서브넷의 RDS 인스턴스가 바로 그 제3의 호스트죠. 그 일을 하는 문서가 AWS-StartPortForwardingSessionToRemoteHost이고, 명령은 aws ssm start-session입니다. 특별할 것도 없고, 데이터베이스에 설치할 것도 없습니다.
AgentsRoom은 그 명령을 대신 실행하고, 반대편 끝에 SQL 클라이언트를 붙여 줍니다. 인스턴스와 리전과 프로필을 한 번만 고르고 거기에 데이터베이스 연결을 붙여 두면, 그 뒤로 그 데이터베이스를 여는 일은 클릭 한 번입니다. 세션은 내 AWS 프로필이나 SSO 로그인으로 인가되므로, 이 구간을 위해 저장되는 키도 비밀번호도 없습니다.
흔히 쓰는 우회로에는 모두 대가가 있습니다
같은 문제에 대한 세 가지 답, 그리고 각각이 청구하는 비용.
유지해야 하는 배스천 호스트
퍼블릭 서브넷의 점프 박스는 패치하고, 모니터링하고, 비용을 내다가 결국 잊어버리게 되는 서버입니다. 인바운드 SSH 포트를 하나 달고 있고, 사람이 들어오고 나갈 때마다 어긋나는 인가 키 목록을 들고 있으며, 부주의한 수정 한 번이면 세상에 열리는 보안 그룹을 가지고 있습니다. 가끔 누군가 데이터베이스에 닿기 위해서만 존재하는데도요.
행 세 개를 보려고 켜는 VPN
클라이언트 VPN은 행 세 개짜리 질문에 답하려고 내 컴퓨터 전체를 네트워크 안으로 밀어 넣습니다. 프로비저닝하고, 배포하고, 갱신하고, 회수해야 하며, 나머지 네트워크 연결과 부딪히고, 네트워크를 옮겨 다니는 노트북에서는 가장 먼저 망가지는 조각입니다. VPN을 갖춘 팀 대부분이 그 옆에 배스천도 그대로 두고 있습니다.
여기저기 복사되는 자격 증명
모두가 결국 기대게 되는 대안은 더 나쁩니다. 엔드포인트와 비밀번호가 채팅 메시지, 공유 노트, 실수로 커밋된 스크립트, 또는 AI 에이전트에 보낸 프롬프트에 남습니다. 접근 권한이 아무도 추적하지 않는 곳으로 퍼지고, 나중에 회수하려면 자격 증명을 교체한 뒤 모든 사본이 사라졌기를 바라는 수밖에 없습니다.
프라이빗 RDS 인스턴스에서 결과 집합까지
한 번만 해 두는 네 단계, 그다음부터는 클릭 한 번.
AWS SSM 연결을 저장하세요
연결 관리자에서 연결을 추가하고 전송 방식을 AWS SSM으로 설정하세요. 데이터베이스에 닿을 수 있는 관리형 EC2 노드의 인스턴스 ID(i-0123456789abcdef0)와 AWS 프로필, 리전을 입력합니다. 비밀번호 칸도 키 칸도 없습니다. 세션은 이미 머신에 있는 AWS 자격 증명으로 인가되기 때문입니다.
데이터베이스를 추가하고 그 연결로 경유하세요
RDS 엔드포인트를 호스트로 삼아 MySQL이나 MariaDB 연결을 추가하고, 포트와 사용자와 데이터베이스를 채우세요. 경유 연결 항목에서는 직접 연결 대신 방금 저장한 AWS SSM 연결을 고릅니다. 설정은 이것이 전부입니다. 엔드포인트는 프라이빗한 채로, 보안 그룹은 닫힌 채로 남습니다.
AgentsRoom이 세션을 엽니다
연결을 열면 AgentsRoom이 운영체제에 비어 있는 루프백 포트를 요청한 다음, AWS-StartPortForwardingSessionToRemoteHost 문서로 aws ssm start-session을 시작합니다. RDS 엔드포인트를 host로, 데이터베이스 포트를 portNumber로, 확보한 포트를 localPortNumber로 넘기죠. 그리고 그 포트가 실제로 TCP 연결을 받아들일 때까지 기다린 뒤에야 터널이 준비됐다고 선언하므로, 클라이언트가 너무 일찍 연결하는 일이 없습니다.
직접 질의하거나, 에이전트에게 맡기세요
SQL 콘솔은 포워딩된 포트로 127.0.0.1에 연결하고, 다른 연결과 똑같이 동작합니다. 스키마 브라우저, 한 번에 구문 하나, 상한이 걸린 결과 집합까지요. AI 코딩 에이전트도 MCP로 같은 연결에 읽기 전용으로 질의할 수 있고, 비밀번호는 결코 받지 않습니다. 연결을 닫으면 세션 프로세스도 함께 종료됩니다.
AgentsRoom이 띄우는 명령
여기에 독자 프로토콜은 없고, JavaScript로 다시 구현한 것도 없습니다. AgentsRoom은 AWS CLI를 자식 프로세스로 띄우되 셸을 거치지 않고 인자를 직접 전달하며, 그 출력을 읽습니다. 포트 포워딩 세션을 손으로 열어 본 적이 있다면, 이미 알고 있는 바로 그 한 줄입니다.
aws ssm start-session \
--target i-0a1b2c3d4e5f \
--document-name AWS-StartPortForwardingSessionToRemoteHost \
--parameters host=acme-prod.abc123.eu-west-1.rds.amazonaws.com,\
portNumber=3306,localPortNumber=54321 \
--profile acme-prod --region eu-west-1인스턴스 ID, 엔드포인트, 리전, 프로필은 저장해 둔 연결에서 가져옵니다. 로컬 포트는 연결을 열 때 운영체제가 고릅니다.
노드 뒤의 데이터베이스가 아니라 관리형 노드 자체로 포워딩하는 것은 host=localhost를 쓴 같은 문서입니다. 그래서 연결 유형 하나가 프라이빗 서브넷의 데이터베이스와, 접속한 인스턴스에서 돌아가는 서비스를 모두 감당합니다.
동작하려면 먼저 갖춰져 있어야 하는 것
AgentsRoom은 내 AWS 설정을 운전할 뿐, 대신해 주지는 않습니다. 다섯 가지가 준비돼 있어야 하고, 그것은 Session Manager를 그냥 쓸 때 필요한 다섯 가지와 똑같습니다.
내 컴퓨터의 AWS CLI
AgentsRoom은 aws 바이너리를 직접 호출합니다. 터미널에서 aws ssm start-session이 동작한다면 여기서도 동작합니다.
session-manager-plugin
Session Manager는 CLI 옆에 설치된 플러그인을 필요로 합니다. 플러그인이 없으면 세션이 즉시 종료되는데, AgentsRoom은 멈춰 선 채로 기다리는 대신 CLI가 출력한 오류를 그대로 보여 줍니다.
동작하는 AWS 프로필 또는 SSO 로그인
인가는 내 자격 증명에서 오고, --profile과 --region으로 전달됩니다. AgentsRoom은 프로필 이름과 리전을 저장할 뿐, 키도 비밀도 저장하지 않습니다.
VPC 안의 관리형 노드
Systems Manager에 등록되어 SSM Agent가 돌고 있고, 세션을 허용하는 인스턴스 프로필이 붙은 EC2 인스턴스입니다. 트래픽이 지나가는 노드이며, 자기 자신에게 인바운드 포트는 필요하지 않습니다.
노드에서 데이터베이스로 가는 경로
데이터베이스 보안 그룹이 데이터베이스 포트로 들어오는 노드의 트래픽을 받아들여야 하고, IAM 정책이 그 문서로 ssm:StartSession을 허용해야 합니다. VPC의 나머지는 바꿀 것이 없습니다.
이 터널이 하는 일, 그리고 하지 않겠다고 정한 일
이 구성을 노트북에 그대로 남겨 둬도 안전한지를 결정하는 성질들.
루프백 전용
포워딩된 포트는 127.0.0.1에만 바인딩되고 그 외에는 어디에도 바인딩되지 않습니다. 이렇게 닿은 데이터베이스는 로컬 네트워크에 다시 게시되지 않으므로, 카페 Wi-Fi가 내 노트북을 프로덕션으로 향하는 열린 프록시로 만들어 버리는 일이 없습니다.
OS가 고르는 포트
AgentsRoom은 운영체제에 비어 있는 포트를 요청해 세션에 넘깁니다. 알아맞혀야 할 고정 포트도, 미리 예약해 둘 것도, 지금 돌고 있는 다른 것과 부딪힐 일도 없습니다.
준비됐다는 말은 정말 준비됐다는 뜻
터널은 로컬 포트가 실제로 TCP 연결을 받아들인 뒤에야 준비 완료가 되고, 끝내 받아들이지 않으면 CLI가 출력한 오류와 함께 포기합니다. 임의로 정한 대기 시간도, 아직 듣고 있지도 않은 포트에 연결하는 클라이언트도 없습니다.
이 구간에는 키도 비밀번호도 없음
SSM 세션은 내 AWS 프로필이나 SSO 세션으로 인가됩니다. AgentsRoom이 저장하는 것은 인스턴스 ID, 프로필 이름, 리전이며, 그 설정을 읽은 누군가가 그대로 재사용할 수 있는 것은 하나도 없습니다.
데이터베이스는 읽기 전용 그대로
데이터베이스 연결은 만들어질 때 읽기 전용입니다. 쓰기에는 해당 연결을 쓰기 가능으로 바꾸는 일과 명시적인 확인이 함께 필요하고, 프로덕션으로 표시된 연결은 그 확인에서 그 사실을 분명히 알립니다.
호출당 구문 하나
한 번의 호출에는 정확히 구문 하나만 담기므로 세미콜론 뒤에 숨는 것이 없고, 결과 집합에는 상한이 있어 넓은 질의가 창이나 에이전트 컨텍스트를 뒤덮지 못합니다.
이것이 접근 권한을 넓히는 게 아니라 좁히는 이유
터널이라는 말은 구멍처럼 들리고, 그 반사 신경은 옳습니다. 프라이빗 데이터베이스에 닿는 방법 대부분은 실제로 공격 표면을 넓히니까요. 이 방법은 오히려 좁힙니다. 데이터베이스 쪽에서 열리는 것은 없고, VPC 어디에도 인바운드 포트가 새로 생기지 않으며, 관리형 노드에도 자기 SSH 리스너가 필요 없습니다. 트래픽은 노드에서 Systems Manager 서비스로 나가고, 내 컴퓨터는 거기서 그 트래픽과 만납니다.
인가는 이미 조직이 관리하고 있는 자리에 그대로 남습니다. 세션은 머신에 이미 설정된 프로필이나 SSO 로그인을 통해 내 AWS 아이덴티티가 부여합니다. 다시 말해 다른 Session Manager 세션과 똑같이 로그가 남고, 그 아이덴티티가 회수되는 날 함께 회수되며, 누가 키를 들고 있느냐가 아니라 IAM 정책으로 범위가 정해집니다. AgentsRoom이 저장하는 것은 인스턴스 ID, 프로필 이름, 리전이고, 그중 자격 증명은 하나도 없습니다.
데이터베이스 쪽 가드레일은 모든 AgentsRoom 연결이 받는 것과 같습니다. 기본은 읽기 전용, 호출당 구문 하나, 상한이 걸린 결과 집합, 그리고 쓰기 확인을 더 까다롭게 만드는 프로덕션 표시. MCP로 질의하는 AI 에이전트는 결과 집합을 받을 뿐 비밀번호는 받지 않으며, 에이전트가 쓰는 도구는 사람에게 그 연결이 무엇을 허용하든 읽기 외에는 전부 거부합니다.
MySQL과 MariaDB뿐, PostgreSQL은 그중에 없습니다
데이터베이스 클라이언트가 MySQL 와이어 프로토콜을 사용하므로, 동작하는 엔진은 MySQL과 MariaDB입니다. RDS에서는 RDS for MySQL, RDS for MariaDB, 그리고 Aurora MySQL 호환 에디션이 여기에 해당합니다. RDS for PostgreSQL과 Aurora PostgreSQL은 지원하지 않고, SQL Server, Oracle, MongoDB, SQLite도 마찬가지입니다. 이 사실은 다운로드한 뒤가 아니라 그 전에 아셔야 합니다.
SSM 전송 자체는 TCP 포트를 전달할 뿐이라 엔진을 가리지 않습니다. PostgreSQL에 빠져 있는 것은 그 위에 얹을 클라이언트이지, 아래에 깔린 터널이 아닙니다. 다음에 어떤 엔진이 올지는 사람들이 요청하는 것으로 정해지므로, 필요한 엔진이 빠져 있다면 공개 백로그에 어느 것인지 남겨 주세요. 그대로 집계됩니다.
내 데이터베이스 엔진 요청하기에이전트도 질의할 수 있습니다, 읽기 전용으로
연결이 만들어지고 나면, AI 코딩 에이전트는 그 연결을 이름으로 지목해 AgentsRoom MCP로 사용할 수 있습니다. db_list는 저장된 연결과 그 메타데이터를 반환하고, db_schema는 SQL 한 줄 없이 스키마와 테이블과 컬럼을 훑고, db_query는 구문 하나를 실행해 상한이 걸린 행을 반환하며, db_connection_new는 아직 저장되지 않은 데이터베이스를 미리 채운 폼으로 제안해 사용자가 검토하고 저장하게 합니다.
에이전트가 요청하면 SSM 세션은 AgentsRoom이 직접 엽니다. 그래서 에이전트는 AWS 자격 증명도, 데이터베이스 비밀번호도, 포트 번호도 만지지 않습니다. 돌아가는 것은 결과 집합입니다. db_query는 연결이 무엇을 허용하든 읽기 전용이고, 그 규칙은 MCP 프로세스가 아니라 데스크톱 앱에 있어서 에이전트가 다른 것을 요청하도록 설득당해도 그대로 유지됩니다.
이 일을 제대로 해 두는 이유가 바로 이것입니다. 프라이빗 서브넷의 프로덕션 리플리카를 상대로 디버깅하는 에이전트는 버그를 설명해 주는 행을 읽되, 그 행을 바꿀 경로도, 자기 컨텍스트로 흘릴 자격 증명도, 앱이 닫힌 뒤 그 데이터베이스에 닿을 방법도 없습니다.
자주 묻는 질문
공개 엔드포인트가 없는 RDS 인스턴스에 어떻게 연결하나요?
AWS SSM 포트 포워딩 세션을 통해서입니다. 데이터베이스에 닿을 수 있는 관리형 EC2 노드를 가리키는 AWS SSM 연결을 저장한 다음, RDS 엔드포인트를 호스트로 하는 MySQL 또는 MariaDB 연결을 만들고 경유 연결 항목에서 그 SSM 연결을 고르세요. AgentsRoom이 aws ssm start-session으로 세션을 열고 포워딩된 루프백 포트에 SQL 클라이언트를 연결합니다. 데이터베이스는 공개 엔드포인트 없이 그대로 있고, 보안 그룹도 바뀌지 않습니다.
AgentsRoom은 어떤 SSM 문서를 사용하나요?
AWS-StartPortForwardingSessionToRemoteHost입니다. host에는 데이터베이스 엔드포인트를, portNumber에는 데이터베이스 포트를, localPortNumber에는 내 컴퓨터에 확보한 루프백 포트를 지정합니다. 이 문서는 관리형 노드를 거쳐 제3의 호스트로 포워딩하는데, 프라이빗 서브넷의 RDS 인스턴스가 정확히 그 경우입니다. 노드 자체로 포워딩하는 것은 host=localhost를 쓴 같은 문서입니다.
그래도 배스천 호스트가 필요한가요?
아니요. 이 용도에서는 Session Manager가 점프 박스를 대신합니다. 관리형 노드에는 인바운드 SSH 포트도 공인 IP도 필요 없고, 트래픽은 노드에서 Systems Manager 서비스 쪽으로 나가며, 내 컴퓨터는 바깥에서 그 세션에 합류합니다. 관리할 키 목록도, 계속 지켜봐야 할 퍼블릭 서브넷도 없습니다.
내 컴퓨터에는 무엇이 설치돼 있어야 하나요?
AWS CLI와 session-manager-plugin, 그리고 동작하는 AWS 프로필이나 SSO 로그인입니다. AgentsRoom은 aws 바이너리를 직접 호출하므로, 터미널에서 aws ssm start-session이 동작하면 여기서도 동작합니다. 플러그인이 없으면 세션이 즉시 종료되고, AgentsRoom은 보이지 않는 프롬프트 앞에서 멈춰 있는 대신 CLI가 출력한 오류를 보여 줍니다.
AgentsRoom이 이걸 위해 AWS 키를 저장하나요?
아니요. 세션은 머신에 이미 설정된 AWS 자격 증명으로 인가되며, --profile과 --region으로 CLI에 전달됩니다. AgentsRoom이 저장하는 것은 인스턴스 ID, 프로필 이름, 리전이고, 이것들은 자격 증명이 아닙니다. 데이터베이스 비밀번호는 별개입니다. OS 키체인으로 암호화된 보관소에 담기며, AI 에이전트에게 반환되는 일은 없습니다.
터널은 어떤 로컬 포트를 쓰고, 누가 거기에 닿을 수 있나요?
연결을 열 때 운영체제가 비어 있는 포트를 고르고, 터널은 그것을 127.0.0.1에만 바인딩합니다. 로컬 네트워크의 어떤 것도 거기에 닿을 수 없고, 알아맞힐 고정 포트도 없습니다. 터널은 그 포트가 실제로 TCP 연결을 받아들인 뒤에야 준비된 것으로 간주되며, 연결과 함께 닫힙니다.
RDS for PostgreSQL에서도 되나요?
아니요. 데이터베이스 클라이언트는 MySQL과 MariaDB만 지원하므로, RDS에서는 RDS for MySQL, RDS for MariaDB, Aurora MySQL 호환 에디션이 대상입니다. RDS for PostgreSQL과 Aurora PostgreSQL은 오늘 기준 지원하지 않고, SQL Server, Oracle, MongoDB, SQLite도 마찬가지입니다. SSM 터널 자체는 TCP 포트를 전달할 뿐이라 엔진을 가리지 않습니다. 빠져 있는 것은 그 위에 얹을 클라이언트입니다. 공개 백로그에 원하는 엔진을 남기면 그대로 집계됩니다.
데이터베이스 대신 EC2 인스턴스 자체로 포워딩할 수 있나요?
네. host=localhost를 쓴 같은 문서이므로, 관리형 노드에서 듣고 있는 서비스에도 같은 방식으로 닿습니다. 같은 AWS SSM 연결은 그 인스턴스에 평범한 터미널 세션도 열어 주는데, 인바운드 SSH 포트가 전혀 없는 머신에서 에이전트 CLI를 실행하는 방법이 바로 이것입니다.
AI 에이전트가 터널을 통해 데이터베이스에 질의할 수 있나요?
네, 읽기 전용으로요. 에이전트는 AgentsRoom MCP를 통해 저장된 연결의 이름을 지목하고, 앱이 SSM 세션을 열어 구문을 직접 실행하며, 돌아오는 것은 결과 집합뿐입니다. 에이전트는 AWS 프로필도, 엔드포인트 자격 증명도, 데이터베이스 비밀번호도 받지 않으며, db_query는 사람에게 그 연결이 무엇을 허용하든 읽기 외에는 전부 거부합니다.
이런 기능도 마음에 드실 거예요
데이터베이스 연결
MySQL과 MariaDB 연결을 저장하고, SSH 터널이나 AWS SSM 세션으로 프라이빗 서브넷의 데이터베이스에 닿고, AI 에이전트가 MCP로 질의하게 하세요. 기본은 읽기 전용, 호출당 구문 하나, 결과 집합에는 상한이 있으며, 비밀번호는 에이전트에 전달되지 않습니다.
SSH 연결
SSH 연결을 저장하고, SSH로 내장 터미널을 열어 Claude Code, Codex, Antigravity CLI를 원격 서버나 VPS에서 바로 실행하세요. SSH 키 또는 비밀번호 인증, 프로젝트별 연결 프로필을 지원하며, 별도의 SSH 클라이언트가 필요 없습니다.
시크릿 관리자
API 키, 토큰, 비밀번호를 OS 키체인에 저장하고, 개발 명령과 에이전트 환경에서 {{secret:NAME}}로 참조하면 AgentsRoom이 실행 시점에 실제 값을 채웁니다. 에이전트는 이름만 볼 뿐 값은 보지 못하며, 서버로 동기화되는 것은 아무것도 없습니다.
원격 플릿
소유한 모든 Mac에서 Claude, Codex 및 Antigravity 코딩 에이전트를 실행하고 팀원들을 초대하여 실시간으로 동일한 에이전트에서 협업하세요. 사무실 기계, 홈 기계, 빌드 서버, 공유 팀 프로젝트 : 모두 단일 통합된 종단 간 암호화된 뷰에서.
아무도 닿을 수 없는 데이터베이스에 질의하세요
AgentsRoom을 다운로드하고, AWS SSM 연결을 저장하고, MySQL이나 MariaDB 데이터베이스를 거기에 연결한 뒤, 배스천도 VPN도 공유된 비밀번호도 없이 프라이빗 RDS 인스턴스에 질의하세요.
컴패니언 앱: 이동 중에도 에이전트를 모니터링
Claude, Codex, Antigravity CLI 또는 다른 AI 공급자를 사용하세요.
버그와 요청을 공개 백로그로 바로 보내세요.
AgentsRoom의 실제 모습.