무엇은 좁히고,
누구는 정하지 않는다

LLM이 사용자 질문을 쿼리로 옮겨 준다면, 교묘하게 짠 질문이 남의 데이터에 닿지 않게 하려면 어떻게 해야 할까. 내가 기준으로 삼는 규칙은 이렇다. LLM은 권한 있는 사용자가 무엇을 볼지 좁힐 수는 있어도, 누가 권한을 가졌는지 정해서는 안 된다. 사용자가 마음대로 쓸 수 있는 텍스트를 모델이 읽고 그 해석이 보안 판단에 영향을 주던 LLM 기능을 걷어 내면서 남은 규칙이다. 이번에는 그 규칙을 피해 가는 데서 그치지 않고, 규칙을 바닥에 깔고 기능을 하나 만들어 봤다. 같은 백엔드 설계를 5개 언어로 나란히 구현해 둔 내 예제 프로젝트에서, 소유자 필드가 아예 없는 필터 타입으로 만들었다.

세 단계 중 LLM은 두 곳에만 들어간다

기능은 Account BC에 있다. "이번 달에 얼마 입금했어?"처럼 자기 거래 내역을 두고 자유롭게 묻는 질문에 구조화 데이터 RAG 파이프라인으로 답한다. 굳이 "구조화 데이터"를 붙인 건 여기서 Retrieve가 SQL 조회이기 때문이다. 흔히 RAG라고 하면 문서 저장소를 벡터 임베딩으로 검색하는 모양을 떠올리는데, 그것과는 다르다.

1. 번역 단계에서는 LLM이 질문을 거래 type, fromDate, toDate로 된 구조화 필터로 바꾼다.
2. 조회 단계에서는 평범한 repository 쿼리가 그 필터로 데이터를 가져온다. 여기엔 LLM이 끼지 않는다.
3. 생성 단계에서는 LLM을 한 번 더 불러, 조회해 온 데이터에만 근거해 답을 쓰게 한다.

// application/service/nl-transaction-query-translator.ts — 인터페이스
export interface TransactionFilter {
  readonly type?: TransactionType
  readonly fromDate?: string
  readonly toDate?: string
}
export abstract class NlTransactionQueryTranslator {
  abstract translate(question: string): Promise<TransactionFilter>
}

// application/service/nl-transaction-answer-composer.ts — 인터페이스
export abstract class NlTransactionAnswerComposer {
  abstract compose(question: string, transactions: TransactionSummaryResult[]): Promise<string>
}

세 단계를 엮는 일은 전부 Application 계층의 Query Handler가 맡는다. Controller는 HTTP 요청을 이 Query로 감싸 보내기만 하고, 흐름은 건드리지 않는다. 핸들러는 다음과 같다.

// application/query/ask-transaction-history-query-handler.ts
const filter = await this.translator.translate(query.question)

const { transactions, count } = await this.accountQuery.getTransactions({
  accountId: query.accountId,
  ownerId: query.requesterId, // 항상 인증된 호출자 —
                               // `filter`에서 나온 값은 절대 아님
  type: filter.type,
  fromDate: filter.fromDate,
  toDate: filter.toDate,
  take: 50,
  page: 0
})

const answer = await this.composer.compose(query.question, transactions)
return { answer, matchedCount: count }

가드레일은 어디에 있나

TransactionFilter에는 ownerId 필드가 아예 없다. 들어와도 무시하도록 검증하는 게 아니라, 구조상 그 값을 실을 수가 없다. 번역된 필터가 좁힐 수 있는 건 무엇이 돌아오느냐뿐이다. 누구의 계좌를 조회할지는 LLM 출력이 호출에 들어가기 전에 인증된 요청자 값으로 이미 채워져 있다.

번역이 틀려도 최악은 본인 데이터를 두고 엉뚱한 답을 받는 정도다. 질문을 아무리 교묘하게 짜도 남의 거래 내역에 닿을 길이 없다.

직접 돌려 본 결과

설계 원칙은 돌려 봤을 때 무엇이 나오느냐로 증명된다. 그래서 로컬에 띄운 Ollama로 확인했다. 50,000원과 10,000원을 입금하고 3,000원을 출금한 다음 질문을 던져 봤다.

5개 언어에서 끝까지 안 바뀐 것

기준 구현을 Ollama에 붙여 직접 확인한 다음, 나머지 4개 스택으로 같은 설계를 옮겼다. 이때 기준 구현의 문법을 베끼지 말고 각 언어에서 원래 쓰던 쿼리/CQRS 관례를 따르라고 분명히 일러 뒀다. Java와 Kotlin Spring Boot는 원래 쿼리를 Handler+Bus 없이 평범한 서비스 오케스트레이터로 처리하고 있었다. 그래서 그 방식대로 옮겼고, 가드레일은 그 밑에 똑같이 배선했다.

구현 방식은 언어마다 달랐다. 어디서는 쿼리 버스를 썼고 어디서는 평범한 서비스를 썼다. Kotlin에서는 패키지 프라이빗 규칙 때문에 작은 클래스 두 개를 다시 설계해야 했다. 그래도 ownerId는 인증된 호출자에게서만 받고 모델에게서는 받지 않는다는 가드레일은 한 번도 움직이지 않았다. 어떤 설계가 원칙인지, 원칙처럼 포장한 구현 디테일인지는 보통 여기서 갈린다. 원본과 전혀 다르게 돌아가는 언어로 다시 써도 살아남으면 원칙이다.