개발자 가이드는 AI 기반 채팅이 진행되는 동안 데이터베이스 트랜잭션을 계속 열어두면 답변이 왜곡되고 기반 DBMS에 과부하를 일으킬 수 있다고 경고합니다. LLM 기반 도구를 구축하는 팀을 대상으로 한 이 노트는 해당 관행을 "해서는 안 된다"고 명시하며, 대신 네 가지 단기 일관성 패턴을 제안합니다.

이 경고가 중요한 이유

LLM 기반 어시스턴트는 종종 일련의 후속 질문을 던집니다. 레코드를 읽고, 세부 사항을 요청한 다음, 합계를 요청하는 식입니다. 만약 그 단계 사이에 기반 데이터가 변경되면, 어시스턴트는 모순된 수치를 반환할 수 있으며, 결과적으로 답변 하나가 틀리게 됩니다. 유혹적인 해결책은 대화 시작 시 단일 트랜잭션을 열고 채팅이 끝날 때까지 유지하는 것입니다. 하지만 실제로 이 방식은 행 버전(row versions)을 묶어두고, tempdb를 채우며, 잠금(locks)을 유지하고, 커넥션 풀링을 방해합니다.

장기 트랜잭션을 유발하는 요인

  • 멀티턴 프롬프팅(Multi-turn prompting) – LLM은 일반적으로 사용자가 응답을 보기 전에 여러 프롬프트를 생성합니다.
  • 데이터베이스를 호출하는 도구 호출(Tool calls) – 각 턴마다 저장 프로시저, SELECT 또는 UPDATE를 호출할 수 있습니다.
  • 통제되지 않은 트랜잭션 범위 – 개발자는 일관성을 보장한다고 가정하고 전체 채팅을 BEGIN…COMMIT 블록으로 감싸기도 합니다.

채팅이 길어지면 DB 엔진은 트랜잭션이 안정적인 뷰를 볼 수 있도록 원래의 행 버전을 유지해야 합니다. 이러한 버전은 tempdb에 저장되어 공간과 I/O를 소비합니다. 동일한 기간 동안 유지되는 잠금은 동시 쓰기 작업을 차단하며, 유휴 연결(idle connection)은 풀을 고갈시켜 새로운 호출자가 빈 슬롯을 기다리게 만들 수 있습니다.

네 가지 단기 패턴

가이드는 일관성을 대화 단위가 아닌 도구 호출(per-tool-call) 단위의 문제로 다룰 것을 권장합니다. 네 가지 패턴은 다음과 같습니다:

  1. 라이브 문(Live statements) – 각 호출은 기본 격리 수준(default isolation level)에서 실행되어 실행 시점에 커밋된 데이터만 확인합니다. 이는 가장 단순한 모델로, 호출자는 이전 턴 이후에 데이터가 변경될 수 있음을 수용합니다.
  2. 경계가 있는 트랜잭션(Bounded transactions) – 개발자는 몇 개의 문장을 다음 LLM 턴이 시작되기 전에 종료되는 하나의 짧은 트랜잭션 내에 그룹화합니다. 이는 도구 호출 이후까지 지속되지 않으면서 해당 배치에 대한 원자성(atomicity)을 보장합니다.
  3. 스냅샷 읽기(Snapshot reads) – 작업은 정의된 스냅샷 타임스탬프로 시작하여 호출 기간 동안 데이터베이스의 안정적인 뷰를 제공합니다. 동시 쓰기가 발생하더라도 호출 내의 모든 읽기는 동일한 데이터를 봅니다.
  4. 구체화된 보고서(Materialized reports) – 도구는 알려진 차단 시점(cutoff point)의 데이터베이스 상태를 반영하는, 미리 생성된 버전 관리된 결과 세트에서 데이터를 읽습니다. 이후 페이지네이션이나 추가 계산은 이 고정된 데이터 세트에서 수행됩니다.

SQL Server의 경우 READ_COMMITTED_SNAPSHOT이 활성화되어 있는지 확인하십시오. 이름만 보고 모든 것을 판단해서는 안 됩니다.

LLM 기반 앱을 위한 실무 규칙

  • 필요한 것을 배치 처리하십시오 – 질문에 많은 값이 필요한 경우, 각각 새로운 트랜잭션을 시작하는 별도의 쿼리를 발행하는 대신 단일 도구 호출에서 이를 계산하십시오.
  • 결정론적 페이지네이션(Deterministic pagination) – 페이지를 넘기며 결과를 표시할 때는 안정적인 정렬 키, 커서 또는 구체화된(materialized) 결과 세트를 사용하십시오. 사용자가 스크롤하는 동안 트랜잭션을 열어두지 마십시오.
  • 증거(Evidence)를 반환하십시오 – 데이터와 함께 일관성 모델을 명시적으로 나타내는 메타데이터를 포함하십시오: 일관성 클래스, 스냅샷 시작 시간, 보고 차단 시점, 데이터 신선도, 행 수, 데이터베이스 식별자 및 추적 ID(trace ID).
  • 동시성으로 스트레스 테스트를 수행하십시오 – LLM이 프롬프트를 생성하는 동안 동시 쓰기를 시뮬레이션하고, 애플리케이션이 우아하게 재시도하거나 폴백(fallback)하는지 확인하십시오.

결론은 명확합니다. AI 채팅이 데이터베이스 트랜잭션의 수명을 결정해서는 안 됩니다. 일관성의 범위를 각 도구 호출로 제한함으로써, 개발자는 데이터베이스를 건강하게 유지하고 모든 사용자를 위한 성능을 보존하면서도, LLM이 정확하게 답변할 수 있도록 충분히 신뢰할 수 있는 데이터를 제공할 수 있습니다.