대규모 언어 모델(LLM)에 기반한 시스템이 실제 데이터를 다루거나 영향력 있는 의사결정을 내리기 시작하면, «대체로 작동한다»는 말은 더 이상 허용되는 기준이 아니다. Stack Overflow Blog의 자료는 LLM 시스템 성숙도 모델의 네 번째 단계에서, 서로 연결된 네 가지 관행을 통해 아키텍처 자체에 안전성과 거버넌스를 구축할 것을 제안한다. 네 가지 관행은 다중 보호 장치, 모든 시스템 경계에서의 개인정보 제어, 변조할 수 없는 감사 기록, 명확한 범위로 제한된 메모리다.
하나의 보호 지점이 아닌 다중 보호 장치
이 자료는 모델 출력에 단일 필터만 사용하는 방식을 비판하고, 각 보호 장치를 독립적으로 테스트하고 순서를 정할 수 있는 작은 소프트웨어 계약으로 만들 것을 제안한다. 요청은 입력과 프롬프트 인젝션 시도를 검사하는 계층, 그라운딩 제약과 출력 형식을 검사하는 계층, 정책 위반이나 개인정보를 결과에서 정제하는 계층, 비즈니스 규칙을 검증하는 계층을 차례로 통과한다. 이어서 올바르게 보이지만 실제로는 잘못된 사례를 위해 보조 판단자를 활용하고, 마지막으로 신뢰도를 평가해 결정을 실행할지 아니면 사람에게 에스컬레이션할지를 정한다.
기본 원칙은 «중단으로의 실패»다. 보호 장치가 고장 나거나 사용할 수 없게 되면 요청을 자동으로 통과시켜서는 안 된다. 또한 모든 차단 작업을 운영 신호로 기록해야 한다. 지표가 갑자기 증가하면 공격, 버전의 성능 저하 또는 배포 결함을 의미할 수 있기 때문이다. 이 자료는 실제 제약이 허용되지 않는 출력을 표현할 수 없도록 만들어야 하며, 모델이 우회할 수 있는 텍스트 지시만으로 충분하다고 여겨서는 안 된다고 강조한다.
개인정보는 경계에서 처리한다
시스템 구성 요소 사이의 모든 전환은 보안 경계를 이룬다. 데이터 유입, 모델로의 전송, 로그나 의사결정 원장에 기록하는 작업, 다른 서비스로 전달하는 작업이 이에 해당한다. 이 자료는 중앙 집중식 민감도 분류를 권고하며, 알려지지 않은 필드는 기본적으로 개인정보로 간주한 뒤 각 경계를 통과하기 전에 데이터를 제거하거나 마스킹하거나 토큰화할 것을 제안한다.
의사결정 기록에서는 결정의 근거를 입증하기 위해 민감한 페이로드 전체를 저장해서는 안 된다. 대안은 HMAC와 테넌트별 전용 키를 사용한 keyed hash가 포함된 정제된 요약이다. 이 자료는 이메일이나 카드 번호처럼 무작위성이 낮은 데이터에 일반적인 SHA-256을 사용하면 역추측이 가능해진다고 지적한다. 또한 재해싱 시 동일한 결과가 나오도록 JCS 사양과 같은 정규화되고 결정적인 JSON 표현을 채택해야 한다.
단순히 로그를 보존하는 대신 과거를 입증하는 감사 기록
이 자료는 문제 해결에 적합하고 순환 삭제되거나 구조화되지 않을 수 있는 운영 로그와, 모든 결정과 그 이유만 추가 기록하는 감사 원장을 구분한다. 이 원장에는 결정 ID, 테넌트, 권한, 모델·프롬프트·결정·신뢰도 버전, 라우팅 경로와 함께 정제된 요약 및 해시 처리된 입력이 포함된다.
수정 사항은 이전 기록을 변경하지 않고, 대체하는 기록을 가리키는 새로운 항목을 생성한다. 변조를 탐지하기 위해 항목은 해시 체인으로 연결하며, 번호의 순서와 완전성을 검증한다. 그러나 체인만으로는 꼬리 부분을 삭제하거나 전체 기록을 다시 구성하는 행위를 막을 수 없다. 따라서 이 자료는 항목에 서명하고 정기적인 체크포인트를 외부 저장소에 게시할 것을 제안한다. 또한 두 개의 동시 쓰기 작업이 체인에 두 갈래를 만들지 못하도록 추가 작업을 잠금 아래에서 수행해야 한다.
분류된 메모리와 제공되는 것과 획득하는 것 사이의 경계
멀티테넌트 시스템에서 메모리는 단순한 기능이 아니라 데이터 거버넌스의 문제다. 이 자료는 테넌트 공유 지식, 에이전트 작업 공간, 임시 워크플로 컨텍스트, 감사 기록, 시맨틱 지식, 사용자 대화와 같은 별도의 범주를 제안한다. 각 범주에는 접근 범위, 민감도 정책, 데이터 저장소 자체에서 강제되는 파티션 키가 있어야 한다. 테넌트 간 읽기나 쓰기는 금지하고, 한 사용자의 대화가 다른 사용자의 의사결정 에이전트와 격리되도록 해야 한다.
또한 이 자료는 팀이 제공하는 초기 데이터와 시스템이 획득하는 운영 데이터를 구분한다. 초기 데이터에는 프롬프트, 규칙, 테스트 세트, 그라운딩 데이터가 포함되고, 운영 데이터에는 메모리, 드리프트 신호, 세션 컨텍스트가 포함된다. 전자는 버전으로 관리되고 실행 중에는 변경할 수 없어야 하며, 후자는 감사 기록을 삭제하지 않고 정의된 범위 내에서 정리할 수 있다. 운영 데이터에서 추출한 새로운 동작은 이후 버전에 통합하기 전에 검토와 테스트를 거쳐야 한다. 이 자료에 따르면 학습은 추적할 수 없는 부작용이 아니라 소프트웨어 변경 요청에 가까운 방식으로 이루어져야 한다.
이러한 관행이 중요한 이유
이 제안의 실질적인 가치는 단일 도구가 아니라 독립적인 계층에 신뢰를 분산하는 데 있다. 출력 정제는 비즈니스 규칙 검증을 대신할 수 없고, 감사 기록은 원시 데이터 보유를 정당화하지 않으며, 벡터 데이터베이스를 사용한다고 해서 메모리가 안전해지는 것도 아니다. 여전히 엔지니어링 결정이 필요한 미해결 제약으로는 각 시스템에 적합한 데이터 범주 정의, 보존 및 접근 정책 설정, 사람의 검토가 필요한 사례 결정, 메모리 정리가 의사결정에 필요한 입력을 제거하지 않는다는 입증이 있다.