AI 시대의 데이터베이스

주문 시스템에서 `orders.customer_id`가 존재하지 않는 고객을 가리키지 못하게 하는 foreign key는 화면 한 곳의 validation보다 강한 공유 규칙입니다. 관리자 도구, batch job과 새 mobile API가 모두 같은 database를 사용해도 제약은 동일하게 적용됩니다. Unique constraint는 같은 결제 식별자의 중복 저장을 막고, check constraint는 수량이나 상태 값의 허용 범위를 data 가까이에서 지킵니다.

Transaction의 의미는 query 여러 개를 빠르게 묶는 것이 아니라 외부에 보일 상태 전환을 정의하는 데 있습니다. 재고를 줄인 뒤 주문 생성이 실패하면 두 변경을 rollback해야 하고, 동시에 두 사용자가 마지막 재고를 주문할 때는 isolation 수준과 lock 방식이 어떤 결과를 허용하는지 알아야 합니다. 단순히 transaction을 사용했다는 사실만으로 모든 동시성 문제가 사라지지는 않습니다.

Schema migration도 “컬럼을 추가했다”에서 끝나지 않습니다. 구 version과 신 version application이 함께 실행되는 rolling deployment에서는 먼저 호환 가능한 column을 추가하고 data를 backfill한 뒤 읽기 경로를 전환하고 마지막에 제약을 강화하는 단계가 필요합니다. 큰 table의 validation과 index build는 lock과 I/O를 만들 수 있으므로 실제 data 규모에서 소요 시간과 차단 범위를 측정해야 합니다.

관계형 모델을 선택하지 말아야 할 조건도 있습니다. 관계와 transaction보다 하나의 aggregate를 통째로 읽고 쓰는 접근이 대부분이고 schema가 매우 빠르게 달라지거나 지역 간 가용성이 강한 우선순위라면 다른 저장 모델이 더 단순할 수 있습니다. 다만 “join이 느리다”는 추측만으로 분리하기보다 query plan, cardinality, consistency 요구와 장애 복구 방식을 같은 workload에서 비교해야 합니다.

문서 database는 객체 구조를 한 record에 함께 저장해 application model과 읽기 단위를 맞추기 쉽습니다. 대규모 key-value access와 수평 분산이 중요한 서비스에서는 관계형 join을 줄이고 partition key로 요청 위치를 예측하는 장점이 있습니다. 대신 여러 document에 걸친 규칙, 중복 data의 갱신과 새로운 query pattern은 application 책임이 될 수 있습니다.

PostgreSQL이 JSON type과 indexing, partitioning과 extension을 제공하면서 관계형 제약이 필요한 core data와 유연한 attribute를 한 운영 경계에서 다루는 선택지가 생겼습니다. 그렇다고 모든 workload를 한 database에 넣어야 하는 것은 아닙니다. 장애 domain, 독립 확장, backup과 팀 ownership 비용까지 포함해 polyglot persistence와 통합 운영을 비교해야 합니다.

Embedding은 문장이나 이미지의 의미를 완벽히 저장하는 정답표가 아니라 model이 학습한 표현을 고정 차원의 숫자로 바꾼 결과입니다. 같은 의미의 표현이 가까워질 가능성이 있지만 숫자, 부정, 최신 사실과 domain 용어는 기대와 다르게 배치될 수 있습니다. Model과 전처리가 바뀌면 기존 vector와 같은 공간에서 직접 비교할 수 없는 경우도 생깁니다.

Exact search는 모든 vector와 거리를 계산해 현재 metric에서 가장 가까운 결과를 찾지만 data가 커지면 비용이 증가합니다. HNSW와 IVFFlat 같은 approximate index는 일부 후보만 탐색해 속도를 얻는 대신 recall, memory, build와 update 비용을 교환합니다. 대표 query와 정답 set으로 recall@k, tail latency와 index build 시간을 함께 측정해야 index 선택이 근거를 가집니다.

RAG는 문서를 vector database에 넣고 model을 호출하는 한 단계가 아닙니다. Source 수집, parsing, 정제, chunk, embedding, index, query 변환, candidate 검색, 권한 filter, rerank, context packing, generation과 citation이 이어집니다. 답이 틀렸을 때 각 stage의 입력과 revision을 보존하지 않으면 prompt 문제인지 누락된 source인지 구분할 수 없습니다.

예를 들어 최신 인사 규정이 답에 나오지 않았다면 ingest가 이전 revision을 읽었는지, table parser가 핵심 행을 잃었는지, chunk가 질문과 다른 표현을 썼는지, ACL filter가 허용 문서를 제거했는지 차례로 확인합니다. Citation도 URL 문자열만 붙이는 것이 아니라 실제 답 문장을 지지하는 span과 source revision을 가리켜야 합니다.

Agent가 자연어로 database를 검색할 때 model에게 raw SQL과 관리자 credential을 주면 query 실수와 prompt injection이 곧 data 노출이나 변경으로 이어질 수 있습니다. 허용된 view, row-level policy와 parameterized query를 제한된 tool 뒤에 두고 결과 수와 민감 field를 server에서 통제해야 합니다.

권한 filter는 검색 뒤 결과를 숨기는 후처리가 아니라 candidate를 만들기 전에 적용해야 합니다. 권한 없는 vector가 rerank나 model context에 들어간 뒤 화면에서만 가리면 이미 정보가 처리 경계를 넘었습니다. Tenant, subject, source revision과 policy decision을 retrieval trace에 남기고 권한 변경 뒤 cache와 index에서도 제거되는 시간을 검증해야 합니다.

교육용 fixture는 회차 S1의 좌석 A3에 두 요청을 동시에 보냅니다. 각 요청이 사전 조회를 마친 뒤 쓰기를 시작하도록 동기화해 순차 테스트에서 드러나지 않는 경합을 만듭니다. 요청을 순서대로 실행한 뒤 우연히 하나만 성공한 결과와 구분합니다. 동시성 fixture는 두 사전 조회가 모두 빈 상태를 보았다는 증거를 남겨 경합 조건이 실제로 만들어졌는지 확인합니다.

검증은 성공 응답 하나와 충돌 응답 하나뿐 아니라 최종 예약 row 하나와 잔여 수량의 한 번 감소를 확인합니다. 응답 status만 맞아도 내부 중복 변경이 남을 수 있습니다. Transaction 실패 직후 잔여 수량을 다시 조회합니다. 화면의 숫자가 cache되어 있으면 저장된 오류를 가릴 수 있으므로 검증은 권한 있는 원본 데이터 조회와 연결합니다.

다른 회차 S2의 A3 예약은 허용되는지도 함께 확인합니다. 단순 좌석 번호만 unique로 만들면 서로 다른 회차의 정상 예약까지 차단하므로 제약 key는 업무 범위를 정확히 반영해야 합니다. 예약 취소 뒤 같은 좌석을 다시 예약할 수 있는지도 정책에 맞게 확인합니다. Active 예약만 제한할지 과거 이력까지 제한할지는 서로 다른 데이터 모델이므로 먼저 업무 규칙을 고정합니다.

Agent의 tool도 같은 저장 계약을 사용하게 하고 우회 쓰기 경로를 별도로 점검합니다. 자연어로 중복을 금지하는 지시보다 실제 제약과 transaction 결과가 충돌 방지의 근거입니다. Batch import와 관리 도구도 같은 제약을 통과하는지 목록으로 확인합니다. 일반 API 하나만 안전해도 다른 writer가 규칙을 우회하면 최종 데이터 일관성은 보장되지 않습니다.

가상 문서 집합은 tenant A와 B를 함께 저장하고 A 사용자가 다섯 문서를 요청합니다. 먼저 A의 허용 문서만 대상으로 exact 기준선을 만들어 실제로 다섯 관련 문서가 존재하는지 확인합니다. 정답 문서의 ID와 revision을 보관해 삭제되거나 바뀐 문서를 계속 기대하지 않게 합니다. 기준선이 오래되면 index 수정이 아니라 평가 자료 갱신이 필요한 상황일 수 있습니다.

Approximate 경로가 두 건만 반환하면 후보 탐색량, 필터 조건과 실제 실행 계획을 기록합니다. 이 상태에서 tenant 조건을 제거해 다섯 건을 채우는 것은 성능 복구가 아니라 권한 위반입니다. Query plan에서 실제 approximate index를 사용했는지도 확인합니다. 설정을 바꿨지만 다른 실행 계획이 선택됐다면 지연 변화의 원인을 탐색 한도 하나로 설명할 수 없습니다.

탐색 설정이나 partition 구성을 바꾸면 동일 질문의 recall과 지연을 다시 비교합니다. 특정 tenant만 좋아지고 다른 tenant의 대기 시간이 늘 수 있으므로 공유 index의 영향을 분리해 관찰합니다. 질문 순서와 cache 조건을 고정한 반복을 사용합니다. 한 후보만 warm cache에서 실행하면 index 설계 차이와 캐시 효과가 섞여 잘못된 속도 결론이 나옵니다.

평가 결과에는 권한 없는 반환 0건을 독립 조건으로 둡니다. Recall이 좋아졌다는 이유로 한 건의 다른 tenant 문서를 허용하지 않아야 검색 품질과 접근 제어가 동시에 성립합니다. 권한 검사에서 제외된 문서 ID는 공개 답변이나 검색 제안에 남기지 않습니다. 본문을 숨겨도 제목이나 존재 여부가 노출될 수 있으므로 반환 형식 전체를 확인합니다.

가상 규정 문서 D7 revision 2를 삭제 fixture로 정하고 파생 chunk ID 목록을 고정합니다. 삭제 전에는 해당 질문에서 D7이 검색되는지 확인해 원래부터 없던 자료로 거짓 통과하지 않게 합니다. 삭제 대상의 내용과 같은 문장을 가진 다른 유효 문서도 함께 둡니다. 문장 문자열을 일괄 삭제하는 방식이 아니라 원문 신원에 따른 삭제인지 확인하는 반례입니다.

Index 삭제는 성공하고 cache 무효화는 실패하도록 주입합니다. 상태 화면이 부분 실패를 보이며 같은 질문에 오래된 답이 남는 경로를 찾는지 확인합니다. 재시작 뒤 남은 cache 삭제 작업이 사라지지 않는지도 시험합니다. 메모리의 완료 목록만 사용하면 과정 중단 후 실패 대상이 잊혀져 오래된 자료가 계속 서비스될 수 있습니다.

재처리 뒤 active index, 결과 cache와 replica를 각각 조회해 D7 revision 2가 0건인지 검사합니다. 전체 문서 수가 하나 줄었다는 집계만으로 특정 파생 데이터의 제거를 증명할 수 없습니다. 조회 결과의 revision을 함께 저장해 0건 판정이 어느 세대를 대상으로 했는지 남깁니다. 서로 다른 시점의 replica 결과를 하나의 완료 상태처럼 합치지 않습니다.

새 revision 3은 별도 fixture로 유지해 삭제 범위가 지나치게 넓지 않은지도 봅니다. 정확한 삭제는 옛 근거를 제거하면서 유효한 최신 문서의 검색과 출처 연결을 보존해야 합니다. 복구용 이전 generation으로 전환하는 시험에서도 철회 목록을 적용합니다. Rollback이 과거 문서 전체를 다시 활성화하면 장애는 복구해도 삭제 약속은 위반할 수 있습니다.