OwlDB 연결은 접속 정보 대신 DB 식별자만 든다

AI에게 사내 DB를 열어 주려면 관리자가 호스트·포트·계정·비밀번호를 OwlAI에 입력합니다. 이 값은 원본을 옮겨 적은 사본이라, DB 서버를 옮기거나 계정 비밀번호를 교체하거나 이중화가 전환되면 다음 조회부터 접속에 실패합니다. DB 관리 솔루션이 이미 수십 개 DB의 접속 정보를 관리하는 회사라면, 같은 정보를 OwlAI에 한 벌 더 적어 두고 원본이 바뀔 때마다 두 곳을 맞춰야 합니다.

OwlDB 연결은 이 사본을 만들지 않습니다. OwlDB는 DB 관리 솔루션이고, OwlDB 연결은 OwlDB가 관리하는 DB 목록에서 골라 만드는 연결입니다. 이 연결에서 OwlAI는 OwlDB의 DB 식별자와 목록 메타데이터만 들고, 접속 정보와 실행은 OwlDB가 맡습니다. 이 글은 OwlDB 연결이 무엇을 받고 실행할 때 무엇을 넘기는지, 그래서 DB 쪽 변화 가운데 OwlAI가 따라가야 하는 것이 무엇만 남는지를 설명합니다.

#접속 정보가 바뀌면 같은 연결을 고쳐야 한다

직접 연결은 관리자가 접속 정보를 손으로 입력한 연결입니다. 여기서는 DB 쪽에서 일어난 변화가 모두 OwlAI에서 고칠 설정이 됩니다.

• 서버를 옮기면 주소를 고치고, 비밀번호도 다시 입력합니다.
• 비밀번호를 교체하면 저장된 비밀번호를 고칩니다.
• 이중화가 전환되면 연결 대상을 새 주 노드로 고칩니다.

고치기 전까지 AI의 조회는 실패합니다. 연결이 가리키는 옛 노드가 살아 있으면 더 곤란합니다. 조회는 성공하고, 실패했다는 신호 없이 오래된 데이터로 답합니다(「AI 조회를 실행할 노드는 등록할 때가 아니라 실행할 때 고른다」).

연결을 지우고 새로 만드는 것으로는 풀 수 없습니다. 연결 하나에는 스키마 분석 결과, 역할마다 준 권한, 테이블 메모가 붙어 있고, 연결을 지우면 이것이 함께 사라집니다. 그래서 접속 정보가 바뀌면 관리자는 같은 연결의 칸을 고칩니다. 원본이 바뀐 사실은 OwlAI가 알 수 없으므로, 언제 고쳐야 하는지도 관리자가 챙겨야 합니다.

#가져온 연결은 주소를 채워 주지만 비밀번호는 남는다

옮겨 적는 수고를 줄이는 흔한 방법은 클라우드 계정에서 DB 목록을 가져오는 것입니다. OwlAI에서도 Supabase나 Amazon RDS의 DB는 주소를 옮겨 적지 않고 가져올 수 있습니다. 관리자가 Supabase에서 OwlAI를 승인하거나 AWS 콘솔에서 CloudFormation 스택을 만들면, OwlAI가 DB 목록을 읽고 관리자가 고른 DB의 주소·포트·TLS를 채운 뒤 잠급니다. 주소를 잘못 옮겨 적을 일은 사라지지만 두 가지가 남습니다.

• 계정과 비밀번호는 관리자가 넣습니다. Supabase는 DB 비밀번호를 알려 주지 않고, OwlAI는 AWS에서 DB 비밀번호를 읽지 않습니다. 관리자가 넣은 비밀번호는 OwlAI가 봉투 암호화로 저장하고, 접속할 때 풀어 씁니다(「DB 백업에 따라가는 비밀번호, 봉투 암호화로 키를 따로 둔다」).
• 주소가 바뀌면 관리자가 편집 창의 다시 가져오기로 같은 DB를 다시 승인받아 새 주소를 채우고, 비밀번호를 넣어 저장합니다. 분석 결과와 권한은 그대로 남습니다.

가져오기는 주소를 옮겨 적는 일을 덜어 줍니다. 하지만 비밀번호의 사본은 여전히 OwlAI 안에 있고, 원본이 바뀌면 사람이 그 사본을 고칩니다.

#OwlDB 연결은 식별자와 목록 메타데이터만 받는다

OwlDB 연결을 만들 때 OwlAI가 OwlDB에서 받는 것은 DB 목록의 메타데이터입니다.

관리자는 이 목록에서 AI에게 열어 줄 DB를 고르고, OwlAI는 그 연결에 OwlDB의 DB 식별자를 적어 둡니다. 스키마 분석 결과, 역할 권한, 테이블 메모는 이 연결에 붙습니다. OwlDB가 관리하는 DB의 서버를 옮기거나 노드 역할이 바뀌어도 OwlDB의 DB 식별자는 그대로이므로, 연결과 거기 붙은 것도 그대로 남습니다.

엔진 종류도 메타데이터에서 받습니다. 프롬프트와 실행부는 엔진 값을 보고 행 제한 문법, 따옴표, 날짜 함수 같은 SQL 방언을 정합니다. 직접 연결에서는 관리자가 엔진을 고르고, 연결을 확인할 때 실제 서버의 엔진과 다르면 OwlAI가 저장을 막습니다. OwlDB 연결에는 엔진을 고르는 칸이 없습니다. OwlDB가 아는 엔진을 그대로 받으므로 두 제품이 같은 DB의 엔진을 다르게 알 일이 없습니다. 표시 이름도 OwlDB가 준 값을 그대로 씁니다.

#실행할 때도 넘기는 것은 식별자다

AI가 SQL 도구를 부르면 OwlAI는 먼저 이 사용자의 역할이 그 DB를 쓸 수 있는지, 읽기 문장 하나인지를 확인합니다. 그 DB 안에서 어느 테이블을 읽을 수 있는지는 역할마다 둔 DB 계정의 권한이 정합니다(「테이블 권한은 SQL 검사 대신 역할마다 둔 DB 계정이 지킨다」). 이 확인은 직접 연결과 똑같이 돕니다(「SQL 실행기가 둘이어도 판정과 결과 형식은 한 벌만 둔다」). 통과하면 OwlAI는 OwlDB에 실행을 요청합니다. 요청에 싣는 값은 다음 넷입니다.

• DB 식별자
• 질문한 사람의 역할에 대응하는 계정 식별자(「테이블 권한은 SQL 검사 대신 역할마다 둔 DB 계정이 지킨다」)
• SQL
• 행 상한

요청에도 비밀번호는 없습니다. OwlDB가 계정 식별자에 맞는 DB 계정으로 접속하고, 실행할 노드도 그 순간의 노드 역할과 복제 지연을 보고 고릅니다(「AI 조회를 실행할 노드는 등록할 때가 아니라 실행할 때 고른다」). 응답에는 결과와 실제로 실행한 노드가 실려 옵니다. OwlDB가 SQL을 실행하지 않고 돌려보낸 경우에는 사유 코드가 오고, 그 사유를 AI에게 보여 줄지 OwlAI가 다시 요청할지는 「무거운 SQL은 cost 문턱 대신 DB 상태를 아는 OwlDB가 판정한다」·「AI 조회를 실행할 노드는 등록할 때가 아니라 실행할 때 고른다」에서 다룹니다.

OwlDB 연결로 조회할 때 OwlAI는 고객 DB 비밀번호를 저장하지도, 풀지도 않습니다. 직접 연결은 접속할 때 저장해 둔 비밀번호를 풀어 쓰지만, OwlDB 연결에는 풀 비밀번호가 처음부터 없습니다.

#OwlAI가 따라가는 변화는 DB 목록의 변화뿐이다

앞 절의 변화를 두 연결에 나란히 놓으면 다음과 같습니다.

OwlDB 연결에서 OwlAI가 따라가는 것은 DB가 생기거나 이름이 바뀌는 목록의 변화입니다. 접속 정보는 OwlAI에 없으므로, 접속 정보가 바뀌어도 OwlAI에서 고칠 설정이 생기지 않습니다.

#설계에서 고른 것

접속 정보를 받는 대신 받지 않는 쪽을 골랐습니다. 받아 두면 OwlDB가 응답하지 않을 때 OwlAI가 DB에 직접 붙는 길을 만들 수 있습니다. 그런데 그 길은 OwlDB가 역할마다 둔 DB 계정의 테이블 권한(「테이블 권한은 SQL 검사 대신 역할마다 둔 DB 계정이 지킨다」)과 무거운 SQL 판정(「무거운 SQL은 cost 문턱 대신 DB 상태를 아는 OwlDB가 판정한다」) 바깥에 있습니다. 비밀번호를 OwlDB 한 곳에만 두면 교체와 회수도 그 한 곳에서 끝납니다. 대가로 OwlDB가 응답하지 않으면 OwlDB 연결의 조회는 실행되지 않습니다.

연결 출처를 설치 전체가 아니라 연결마다 정했습니다. 연결 출처는 연결을 어디서 만들었는지(직접 입력, Supabase, Amazon RDS, OwlDB)를 적은 값입니다. 실행기를 열 수 있는지, 역할에 테이블 단위 권한을 줄 수 있는지, SSH 터널을 쓸 수 있는지, 접속 대상을 손으로 고칠 수 있는지가 출처마다 다르고, 등록 화면과 API와 실행부와 역할 권한이 모두 출처마다 정의한 규칙 한 벌을 읽습니다(「SQL 실행기가 둘이어도 판정과 결과 형식은 한 벌만 둔다」). 설치 전체를 「OwlDB 모드」로 바꾸는 쪽이 더 단순하지만, 그러면 OwlDB가 다루지 않는 DB를 함께 쓰는 회사는 둘 중 하나를 포기해야 합니다. 연결마다 출처를 정하면 OwlDB를 들여도 쓸 수 있는 DB가 줄지 않습니다.

목록 메타데이터를 OwlAI 쪽에서 고쳐 쓰는 대신 그대로 쓰는 쪽을 골랐습니다. 이름이나 엔진을 OwlAI에서 덮어쓰면 두 제품이 같은 DB를 다르게 부르고, 어느 쪽이 맞는지 따지는 일이 생깁니다. 원본은 OwlDB 한 곳에 둡니다. 대가로 OwlAI 화면의 DB 이름을 바꾸려면 OwlDB에서 바꿔야 합니다.

DB가 몇 개뿐이고 접속 정보가 거의 바뀌지 않는다면 직접 연결로 충분하고, Supabase나 Amazon RDS의 DB라면 가져오기가 주소를 옮겨 적는 일을 덜어 줍니다. DB 목록과 접속 정보를 이미 OwlDB가 관리하고 서버 이전·비밀번호 교체·이중화 전환이 잦은 환경이라면, OwlDB 연결로 붙여 접속 정보를 한 곳에서만 관리하는 쪽이 맞습니다.