Deep Connector를 구축하던 중 고객의 데이터베이스 버전 요구사항이 Oracle 26ai에서 19c로 바뀌었다. 기존 구현이 26ai의 네이티브 JSON을 사용하고 있었으므로, 변경 요청을 받았다고 접속 대상만 바꿀 수는 없었다. DDL, 저장과 조회 코드, 검색 인덱스, 이관 절차를 함께 검토해야 했다.
이 글은 전환 영향검토서와 성능 비교 쿼리 샘플을 함께 읽고 재구성한 기록이다. 자료에 남은 파일 규모 계측과 정적 검토, 용량 추정, 비교 시험 계획을 구분했다. Oracle 26ai와 19c의 비교 부하 시험 결과나 최종 운영 전환 승인을 보고하는 글은 아니다. 고객사, 실제 계정과 스키마 식별자, 내부 작업 날짜 및 배포 정보는 제외했다.
워크스페이스마다 루트 폴더가 하나 있어야 한다. 제품 요구사항으로는 짧지만, 데이터베이스에 옮기면 “둘 이상 생기지 않는다”와 “없는 상태를 채운다”를 따로 구현해야 한다.
Deep Connector는 루트 중복을 PostgreSQL의 부분 유니크 인덱스와 Oracle의 함수 기반 유니크 인덱스로 막는다. 인덱스가 보장하는 것은 최대 하나다. 루트를 생성하는 작업과 인덱스를 설치하는 작업까지 있어야 제품이 요구하는 상태를 만들 수 있다.
이 글은 구현 코드와 공식 문서를 대조한 설계 설명이다. SQL은 식별자와 구조를 단순화한 개념 예시이며, 글 작성 과정에서 PostgreSQL이나 Oracle에 실행한 실험 결과가 아니다.
애플리케이션은 테이블이 없다고 판단했다. 테이블을 만들려고 하자 Oracle은 권한이 없다고 응답했다. 그런데 테이블은 이미 있었다.
Deep Connector를 온프레미스 환경에 옮기던 중 만난 문제다. 오류를 수정해 이미지를 다시 만들었는데도 기동 로그에는 같은 ORA-01031: insufficient privileges가 남았다. 하나를 고칠 때마다 다른 조건이 드러났다. 결국 오류를 처리하는 코드보다 먼저 살펴봐야 했던 것은 “이 계정에서 무엇이 보이는가”였다.
이 글은 당시 개발 기록을 재구성한 회고다. 고객사, 작업 날짜, 실제 계정명과 배포 식별자는 제외했다. 아래 계정과 테이블 이름은 설명용 가명이며 SQL은 진단 예시다. 글 작성 과정에서 운영 환경이나 Oracle 재현 실험을 다시 실행한 것은 아니다.
평가 화면에 근거 검색 점수가 100%로 나왔다고 하자. 그런데 근거를 요구한 질문 중 실제로 측정한 것은 일부뿐이었다면, 그 숫자를 전체 검색 품질로 읽어도 될까?
Deep Connector의 평가 집계에서는 평균과 함께 근거를 요구한 행 수, 측정 가능한 근거가 있는 행 수를 구분한다. 이 설계를 검토하면서 작은 데이터를 만들어 집계 함수를 실행해 봤다. 같은 입력도 null과 0을 어떻게 처리하느냐에 따라 평균이 30%, 50%, 75%로 달라졌다.
아래 질문과 점수는 집계 규칙을 확인하려고 만든 설명용 데이터다. 고객 문서나 실제 평가 성적을 사용하지 않았다. 실험은 저장소의 특정 구현 스냅샷에서 가져온 순수 함수만 실행했으며, 검색 엔진이나 LLM을 호출한 성능 실험은 아니다.