AI 조회 하나에 주문 화면까지 느려지지는 않을까

#무거운 조회는 실행 전에 걸리고, 이유는 AI에게 돌아간다

AI가 운영 DB에서 수억 건짜리 테이블을 조건 없이 훑기 시작하면, 같은 DB를 쓰는 주문 화면과 정산 배치가 그 순간부터 함께 느려집니다.

OwlDB와 함께 쓰면 이런 조회는 실행되기 전에 걸러지고, 실행 중에 자원을 넘치게 쓰면 DB 세션째 멈춥니다. 걸러진 이유는 AI에게 돌아가고, AI는 그 이유를 읽고 SQL을 고쳐 다시 씁니다.

#OwlAI만으로도 시간과 행 수에 상한이 걸린다

OwlAI만 써도 조회마다 시간 예산이 걸립니다. 예산을 넘으면 OwlAI가 조회를 취소하고, 그 취소가 실패할 때를 대비해 DB 쪽에도 시간 제한을 함께 걸어 둡니다. 사용자가 답변을 멈추면 DB로 이미 보낸 조회에도 취소가 전달됩니다(「운영 DB에 AI를 붙이자는 말에 보안팀이 묻는 세 가지」). 한 번에 받아 오는 행 수에도 상한이 있습니다.

이 장치들은 모두 조회가 시작된 뒤에 작동합니다. 직접 연결은 연결 하나로 DB를 들여다보기 때문에, 그 DB에서 지금 세션이 몇 개 돌고 있는지, 이번 조회가 얼마나 무거울지를 미리 판단할 근거가 부족합니다.

#OwlDB와 함께 쓰면 세 단계로 막는다

OwlDB는 DB를 관리하는 쪽이라 DB의 지금 상태를 이미 알고 있습니다. 그래서 무거운 조회를 세 단계로 다룹니다.

실행 전에는 판정합니다. AI가 실행 계획을 확인하면 OwlDB가 그 계획이 OwlDB에 정해 둔 기준을 넘는지 함께 판정하고, 넘으면 어느 부분이 무거운지 짚어서 돌려줍니다.

실행 중에는 CPU·입출력·메모리·시간에 상한이 걸립니다. 실행 계획으로는 가벼워 보였는데 실제로 돌려 보면 무거운 조회가 있어서입니다.

그리고 OwlDB는 1초마다 세션을 살피다가 예산을 넘은 세션을 강제로 끝냅니다. 직접 연결에서 OwlAI가 할 수 있는 일은 취소 요청을 보내고, 그 요청이 듣지 않을 때를 대비해 DB에 시간 제한을 걸어 두는 데까지입니다. DB가 이미 시작한 작업을 언제 멈출지는 그 뒤 엔진이 정합니다. OwlDB는 DB 세션 자체를 끝냅니다.

#막힌 조회는 AI가 고친다

조회를 막기만 하면 사용자는 답을 받지 못합니다. OwlDB가 돌려주는 거절에는 비용 기준을 넘었는지, 행 수 상한을 넘었는지와 함께 문제가 된 부분이 실려 있습니다. AI는 다음 단계에서 기간 조건을 더하거나 필요한 컬럼만 고르는 식으로 SQL을 다시 씁니다. 다시 쓴 SQL이 통과하면 사용자 눈에는 조금 늦게 나온 답 하나가 보일 뿐입니다.

읽기용 복제 서버가 잠시 없거나 DB가 바쁜 경우처럼 SQL과 상관없는 사유로 막히면 OwlAI가 잠시 뒤 알아서 다시 시도합니다.

#도입 전에 확인할 것

• 운영 DB에서 AI 조회에 허용할 실행 시간과 자원 상한
• 무거운 조회가 막혔을 때 DB 관리자가 받아 볼 기록
• 분석·조회를 운영 노드 대신 보낼 스탠바이 노드가 있는지(「스탠바이 DB를 AI 조회에 활용할 수 있을까」)