문서 추출 워커가 응답하지 않으면 다른 워커가 작업을 이어받을 수 있어야 한다. 그런데 응답이 늦다는 이유만으로 이전 워커가 종료됐다고 볼 수는 없다. 새 워커가 결과를 저장한 뒤 이전 워커도 완료를 보고할 수 있다.
Deep Connector의 추출 코드를 검토하면서 작업을 가져오는 조건과 결과를 확정하는 조건을 나눠 읽었다. 작업을 처음 점유할 때의 행 잠금만으로는 나중에 돌아온 워커의 쓰기까지 막을 수 없기 때문이다. 결과를 확정할 때도 DB에 기록된 현재 소유자를 확인해야 한다.
아래 순서는 지연 상황을 설명하려고 만든 가정이며 실제 장애 회고가 아니다. 예제는 소유권 조건을 축약한 메모리 모델로, 실제 제품 코드나 다중 인스턴스 DB 실험을 실행한 결과와 구분한다.
Deep Connector를 구축하던 중 고객의 데이터베이스 버전 요구사항이 Oracle 26ai에서 19c로 바뀌었다. 기존 구현이 26ai의 네이티브 JSON을 사용하고 있었으므로, 변경 요청을 받았다고 접속 대상만 바꿀 수는 없었다. DDL, 저장과 조회 코드, 검색 인덱스, 이관 절차를 함께 검토해야 했다.
이 글은 전환 영향검토서와 성능 비교 쿼리 샘플을 함께 읽고 재구성한 기록이다. 자료에 남은 파일 규모 계측과 정적 검토, 용량 추정, 비교 시험 계획을 구분했다. Oracle 26ai와 19c의 비교 부하 시험 결과나 최종 운영 전환 승인을 보고하는 글은 아니다. 고객사, 실제 계정과 스키마 식별자, 내부 작업 날짜 및 배포 정보는 제외했다.
문서 코드를 정확히 입력했는데, 그 코드가 없는 안내문이 먼저 나온다고 하자. 검색 사전이 붙인 동의어가 안내문에 더 많이 등장했기 때문이다. 찾을 수 있는 표현은 늘었지만 사용자가 직접 지정한 단어의 우선순위는 낮아진 셈이다.
DeepConnector의 파일 검색은 사용자 입력과 사전 확장어를 함께 검색하되 점수는 구분한다. 직접 입력한 단어의 일치에는 큰 가중치를 주고, 사전이 보탠 별칭의 일치에는 작은 가중치를 준다. 동의어로 검색 범위를 넓히면서도 원래 검색어를 우선하려는 설계다.
첫 상황은 설계를 설명하기 위한 가정이며 실제 고객 장애가 아니다. 아래 문서와 검색어도 설명용으로 만들었다. 검증에는 특정 구현 스냅샷에서 추출한 실제 스니펫 조립 코드를 사용했고, 검색 서버나 사전 서비스 전체를 실행한 것은 아니다.
워크스페이스마다 루트 폴더가 하나 있어야 한다. 제품 요구사항으로는 짧지만, 데이터베이스에 옮기면 “둘 이상 생기지 않는다”와 “없는 상태를 채운다”를 따로 구현해야 한다.
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을 호출한 성능 실험은 아니다.