운영 DB에 AI를 붙이자는 말에 보안팀이 묻는 세 가지

#회의실에서 먼저 나오는 질문

업무 DB에 AI를 연결하자는 이야기가 나오면 DB 관리자와 보안팀은 같은 질문 세 개를 꺼냅니다. AI가 실수로 데이터를 지우면 어떻게 하나. 무거운 조회를 돌려 운영 시스템을 느리게 만들면 어떻게 하나. 볼 수 없어야 할 데이터를 꺼내 보여 주면 어떻게 하나.

OwlAI는 세 질문에 각각 장치를 하나씩 두고, 그 위에 기록을 하나 더 얹어 네 겹으로 답합니다. AI가 쓴 SQL은 DB에 닿기 전에 권한 확인과 읽기 전용 검사를 거치고, 시간 예산 안에서만 돌며, 실행될 때마다 한 줄씩 남습니다.

#AI는 데이터를 읽기만 한다

OwlAI는 연결된 DB를 읽기만 하고, 이 원칙을 세 겹으로 지킵니다. 가장 바깥은 실행 전 검사입니다. AI가 쓴 SQL을 DB로 보내기 전에 살펴서 조회가 아닌 문장은 보내지 않습니다. 그 안쪽에서는 DB가 직접 막습니다. 읽기 전용 모드를 지원하는 DB라면 조회를 그 모드로 열기 때문에, 검사를 빠져나간 쓰기가 있더라도 DB가 거절합니다. 읽기 전용으로 열지 못하면 조회를 아예 실행하지 않습니다.

마지막 겹은 연결 계정입니다. DB 연결 화면은 엔진마다 조회 권한만 가진 계정을 만드는 SQL을 보여 주고, 그 계정으로 연결하도록 권합니다. 앞의 두 겹이 모두 뚫려도 계정에 쓰기 권한이 없으면 데이터는 바뀌지 않습니다.

#무거운 조회는 시간 예산에서 끊긴다

조회 하나에는 실행 시간 예산이 걸립니다. 예산을 넘기면 OwlAI가 조회를 끊고, DB 쪽에도 시간 제한을 함께 걸어 두어 한쪽이 놓쳐도 다른 쪽이 멈춥니다. 한 번에 받아 오는 행 수에도 상한이 있어서 AI가 거대한 결과를 통째로 끌어오지 못합니다.

답변 중지 버튼도 DB까지 닿습니다. 사용자가 버튼을 누르면 이미 DB로 보낸 조회에도 취소가 전달되므로, 화면에서는 멈췄는데 DB에서는 계속 도는 일이 생기지 않습니다.

OwlDB로 연결한 DB라면 한발 앞에서 막습니다. 무거운 조회는 실행되기 전에 OwlDB가 걸러 내고, 실행 중에 자원을 지나치게 쓰는 세션은 OwlDB가 끝냅니다(「AI 조회 하나에 주문 화면까지 느려지지는 않을까」).

#AI는 질문한 사람의 권한만큼만 본다

관리자는 역할마다 질의할 수 있는 DB를 정합니다. 사람은 역할을 하나씩 받고, AI는 질문한 사람의 역할 안에서만 DB를 조회합니다. 허용되지 않은 DB를 조회하려 하면 실행 전에 막힙니다.

OwlDB로 연결한 DB는 이 경계를 테이블 단위까지 나눌 수 있고, 그 경계를 OwlAI가 아닌 DB가 직접 지킵니다(「한 부서에 DB를 열어 주면, 보면 안 되는 테이블까지 따라 열릴까」). 역할마다 열어 줄 테이블을 고르면, 고르지 않은 테이블은 그 역할의 AI가 조회할 수 없습니다.

#누가 무엇을 조회했는지 전부 남는다

AI가 실행한 SQL은 실행될 때마다 한 줄씩 기록됩니다. 관리자는 활동 기록 화면의 SQL 실행 이력 탭에서 누가 언제 어느 DB에 어떤 SQL을 보냈는지, 몇 행을 받았고 어떤 테이블을 읽었는지 봅니다. 채팅에서 실행됐는지 플레이북(반복 업무를 자동으로 돌리는 기능)에서 실행됐는지도 나뉩니다. 권한이나 읽기 전용 검사에 막힌 시도는 거부로 따로 남습니다.

대화를 지워도 이 기록은 남고, CSV로 내려받아 감사 자료로 쓸 수 있습니다. 조회 결과 값은 기록에 남지 않습니다. 기록이 또 다른 유출 경로가 되지 않게 하려는 것입니다.

#도입 전에 IT 부서가 확인할 것

연결을 열기 전에 IT 부서가 정해 두거나 확인할 항목은 다섯 가지입니다.

• 조회 권한만 가진 전용 연결 계정
• 역할별로 허용할 DB 범위(OwlDB로 연결한 DB는 테이블 범위까지)
• 운영 DB 대신 연결할 조회 전용 복제본
• 전송 구간 암호화(TLS) 또는 SSH 터널
• SQL 실행 이력을 점검할 사람과 주기

복제본 연결은 OwlAI가 요구하는 조건은 아니고, 운영 DB의 부담을 덜기 위한 권장 사항입니다. 암호화하지 않은 연결에는 연결 목록에서 암호화되지 않은 연결 표시가 붙어 설정을 놓치지 않게 합니다.