AI 기능을 운영하는 팀들이 한동안 프롬프트 버전 관리에 집중했던 건 자연스러운 흐름이었습니다. 하지만 에이전트가 실제 업무에 들어오면서 병목은 다른 곳에서 터지고 있습니다. 모델 앞단에 붙는 입력이 너무 많아졌기 때문입니다. 시스템 프롬프트, 과거 대화, 검색 결과, 코드 스니펫, 정책 문서, 툴 출력, 사용자 첨부, 팀별 메모가 한 호출 안에 섞입니다. 문제는 이 조각들이 각자 다른 소유자와 다른 갱신 주기를 가진다는 점입니다. 그래서 이제 좋은 팀은 프롬프트 문장보다 컨텍스트 조각의 계약을 먼저 관리합니다.

저는 이 흐름을 Context Contract Registry라고 부르는 편이 가장 정확하다고 봅니다. 핵심은 모델 입력을 그냥 문자열로 보지 않고, 무엇이, 누가, 언제, 어떤 조건으로, 얼마나 오래 들어갈 수 있는지 계약처럼 다루는 것입니다. 이 방식은 컨텍스트 엔지니어링의 런타임 거버넌스를 한 단계 더 밀어붙인 형태이고, 에이전트 메모리 티어링, 코드베이스 지식 그래프 + 시맨틱 인덱스, Schema Constrained Output + Runtime Validator와도 자연스럽게 이어집니다. 출력 제약만 강하게 걸어서는 부족하고, 입력 계약도 같이 관리해야 운영 품질이 안정되기 때문입니다.

이 글에서 얻는 것

  • Context Contract Registry가 왜 단순 프롬프트 저장소나 벡터 검색 설정과 다른지 이해할 수 있습니다.
  • 어떤 입력 조각을 계약 단위로 관리해야 에이전트 품질과 안전성을 같이 끌어올릴 수 있는지 판단할 수 있습니다.
  • 도입 초기에 필요한 지표, 소유권 모델, 차단 규칙을 숫자 기준으로 바로 가져갈 수 있습니다.

핵심 개념/이슈

1) 지금 문제는 “좋은 프롬프트 부족"보다 “입력 조합 무질서"다

실무에서 에이전트 품질이 흔들릴 때 원인은 종종 프롬프트 문장보다 앞단 입력 혼선에 있습니다.

  • 오래된 runbook이 최신 운영 정책보다 먼저 붙는다.
  • 검색 결과가 최근 코드보다 우선순위 높게 들어간다.
  • 사용자 첨부와 팀 정책 문서가 같은 신뢰도로 합쳐진다.
  • 민감 정보가 마스킹 없이 이전 세션에서 흘러 들어온다.
  • 한 팀이 바꾼 템플릿이 다른 팀 워크플로를 조용히 깨뜨린다.

이 상태에서는 모델이 좋아져도 품질이 흔들립니다. 결국 필요한 것은 더 긴 프롬프트가 아니라, 어떤 조각이 어떤 조건에서 입력에 포함될 자격이 있는지를 명시하는 계약입니다.

2) Contract Registry의 핵심 객체는 프롬프트가 아니라 “컨텍스트 조각"이다

Context Contract Registry에서는 보통 아래 같은 단위를 관리합니다.

  • source: 코드 검색, 문서 검색, 세션 메모리, 정책 문서, 사용자 첨부, 툴 출력
  • owner: 플랫폼팀, 서비스팀, 보안팀, 운영팀, 사용자인스턴스
  • freshness: 허용 stale 시간, 예를 들어 10분, 1일, 7일
  • sensitivity: public, internal, restricted, secret-derived
  • shape: 요약문, 표, JSON, 코드 블록, 로그 샘플
  • budget: 최대 토큰 수, 최대 개수, 우선순위
  • validation: 필수 필드, 금지 패턴, 마스킹, provenance

이 구조가 있어야 “검색 5건 붙이기"가 아니라, 운영 runbook은 24시간 이내 수정본만 허용, 사용자가 올린 로그는 PII 마스킹 후 2,000토큰 이하로 축약, 정책 문서는 restricted 등급만 허용 같은 규칙이 생깁니다. 이 점에서 하이브리드 검색 + 리랭커 + 컨텍스트 압축이 검색 품질 레이어라면, contract registry는 입력 거버넌스 레이어에 가깝습니다.

3) 좋은 팀은 입력 계약을 버전 관리하고, 깨지면 롤백한다

프롬프트만 버전 관리하면 실제 운영 문제의 절반밖에 다루지 못합니다. 왜냐하면 사고는 종종 템플릿보다 검색 정책, 메모리 우선순위, 마스킹 규칙, 포함 대상 문서 세트가 바뀔 때 발생하기 때문입니다.

예를 들어 아래 변경은 모두 별도 버전으로 다뤄야 합니다.

  1. billing 도메인 작업에서 회계 runbook을 우선 붙이도록 변경
  2. 장문 로그를 요약 후 원문 10%만 보존하도록 변경
  3. restricted 문서가 developer 작업에는 들어가지 못하게 차단
  4. 세션 메모리 TTL을 7일에서 24시간으로 축소

이런 변경은 모델 성능 튜닝이 아니라 운영 정책 변경입니다. 따라서 release note, canary, rollback이 있어야 합니다. 최근 Inference Router가 모델 선택을 라우팅 규칙으로 다루듯, 입력도 라우팅 규칙으로 다루는 흐름이 강해지고 있습니다.

4) 입력 계약은 품질 문제뿐 아니라 보안과 비용 문제를 동시에 건드린다

Context Contract Registry가 중요한 이유는 품질 안정성만이 아닙니다. 입력 조각을 계약화하면 보안과 비용 통제도 쉬워집니다.

  • 보안: secret-derived 콘텐츠, 고객 데이터, 내부 운영 정책의 혼입을 막을 수 있음
  • 비용: 토큰 비싼 문서를 우선순위 낮추고 압축 정책을 다르게 줄 수 있음
  • 디버깅: 어떤 조각이 실제로 들어갔는지 receipt를 남길 수 있음
  • 규정 준수: 특정 작업군에 허용된 자료원만 사용하게 만들 수 있음

그래서 이 흐름은 툴 권한 manifest와 런타임 attestation이나 Execution Receipt와 결합될 때 효과가 큽니다. 툴은 제한했는데 입력 문맥이 엉켜 있으면 여전히 이상한 결론이 나올 수 있기 때문입니다.

5) 결국 경쟁력은 “무엇을 더 넣나"가 아니라 “무엇을 빼야 하나"에서 갈린다

초기 도입 팀은 컨텍스트를 많이 넣을수록 정확할 거라고 생각하기 쉽습니다. 하지만 실제 운영에서는 과잉 입력이 더 흔한 실패 원인입니다. 오래된 문서, 충돌하는 정책, 관련 없는 로그가 섞일수록 모델은 정답보다 타협적 평균을 내기 쉽습니다.

그래서 좋은 contract registry는 추가 규칙만 있는 시스템이 아니라, 제외 규칙과 우선순위 규칙이 더 강한 시스템입니다.

  • billing 작업에는 마케팅 문서를 기본 제외
  • incident 작업에는 7일 이전 회고 문서 제외
  • production change 작업에는 provenance 없는 외부 검색 결과 제외
  • customer support 작업에는 secret-derived 툴 출력 제외

이 방식은 Change Intelligence Control Plane과도 닮아 있습니다. 중요한 건 더 많은 정보가 아니라, 의사결정에 필요한 정보만 남기는 압축입니다.

실무 적용

1) 최소 기능 버전은 5개 필드부터 시작하면 된다

처음부터 거대한 메타데이터 시스템을 만들 필요는 없습니다. 실무에서는 각 컨텍스트 조각에 아래 5개만 붙여도 효과가 큽니다.

  • owner
  • freshness_ttl
  • sensitivity
  • max_tokens
  • allowed_tasks

이 다섯 개만 있어도 “누가 책임지는지”, “얼마나 오래 믿을지”, “어디까지 넣을지"가 정리됩니다.

2) 의사결정 기준(숫자·조건·우선순위)

초기 KPI는 모델 정답률 하나로 두지 않는 편이 좋습니다. 권장 우선순위는 아래와 같습니다.

  • 1순위: contract violation rate, 금지 소스나 잘못된 freshness가 입력에 섞인 비율
  • 2순위: stale context rate, TTL을 넘긴 조각이 사용된 비율
  • 3순위: unsafe injection block rate, 차단 규칙이 실제로 막은 비율과 정확도
  • 4순위: context rollback readiness, 문제 계약을 15분 안에 되돌릴 수 있는지
  • 5순위: token efficiency, 동일 작업 대비 입력 토큰 절감률

권장 출발값 예시는 아래 정도입니다.

  • restricted 이상 민감도 문서의 무단 혼입률: 0.1% 미만
  • stale context 사용률: 2% 미만
  • high-risk 작업의 contract coverage: 95% 이상
  • 컨텍스트 정책 변경의 canary 적용 비율: 100%
  • 문제 계약 rollback 시간: 15분 이내
  • 동일 작업군 평균 입력 토큰 절감: 20% 이상

중요한 건 비용 절감보다도 잘못된 입력이 들어가서 생기는 조용한 오답을 줄이는 것입니다.

3) 팀 운영 방식도 바뀌어야 한다

Context Contract Registry는 플랫폼팀만의 일이 아닙니다. 소유권 모델이 분명해야 오래 갑니다.

  • 플랫폼팀: registry 구조, validator, rollout, receipt
  • 서비스팀: 도메인 문서 신선도와 허용 작업 정의
  • 보안팀: 민감도 분류, 마스킹, 금지 규칙
  • 운영팀: incident/runbook 계열 freshness 기준

실무에서는 이 역할이 섞이면 업데이트가 느려집니다. 특히 운영 문서는 빨리 바뀌는데, 중앙팀 승인만 기다리면 stale context rate가 올라갑니다.

4) 4주 도입 순서

1주차: 상위 20개 컨텍스트 조각 인벤토리 작성
무엇이 실제로 모델 입력에 들어가는지 먼저 드러냅니다.

2주차: owner, ttl, sensitivity, allowed_tasks 태깅
계약의 최소 필드를 붙이고 누락 조각을 찾습니다.

3주차: validator와 차단 규칙 연결
민감도 위반, stale 초과, 예산 초과를 런타임에서 막습니다.

4주차: canary와 rollback 체계 도입
정책 변경을 전면 적용하지 말고 작은 작업군부터 실험합니다.

5) 실전 설계 예시, “좋은 검색"보다 “들어와도 되는 입력"을 먼저 고정하는 방식

가장 흔한 실패는 검색 정확도가 낮아서가 아니라, 서로 다른 수준의 문맥이 같은 호출 안에서 동등하게 취급되는 것입니다. 예를 들어 운영팀이 incident 대응용 에이전트를 만든다고 가정해 보겠습니다. 이때 contract registry가 없으면 최신 장애 runbook, 오래된 회고 문서, 고객 첨부 로그, 내부 보안 정책, LLM이 직전에 생성한 임시 요약이 한꺼번에 붙기 쉽습니다. 사람은 출처를 구분하지만 모델은 그렇게 안정적으로 구분하지 못합니다.

그래서 저는 설계 초기에 아래처럼 task class별 허용 입력을 먼저 고정하는 방식을 추천합니다.

작업군허용 입력제한 규칙운영상 이유
incident triage최근 24시간 runbook, 최근 배포 기록, 경보 메타데이터외부 검색 결과 기본 금지, 고객 원문 로그는 마스킹 후 2,000토큰 이내속도보다 최신성과 안전성이 중요
code change review변경 diff, 테스트 결과, 관련 모듈 문서, 소유 팀 규약unrelated memory 금지, 7일 지난 임시 메모 제외모델이 과거 대화를 끌어와 엉뚱한 수정을 제안하는 문제 방지
support reply draft고객 티켓, 승인된 FAQ, 공개 문서restricted 정책 문서 금지, billing 데이터는 summary only친절한 답변보다 데이터 경계 유지가 먼저

핵심은 retrieval 품질이 좋아지면 나중에 붙일 수 있지만, 허용 입력의 경계가 흐린 상태에서는 검색을 아무리 개선해도 운영 리스크가 줄지 않는다는 점입니다. 이 흐름은 LLM Gateway Prompt Firewall + DLP과 같이 봐야 더 입체적으로 보입니다. 출력만 검열하는 것이 아니라, 애초에 들어갈 수 있는 문맥을 작업군 단위로 관리해야 하기 때문입니다.

6) 도입 안티패턴, 처음부터 거대한 중앙 레지스트리를 만들려 하지 말 것

현업에서 많이 보는 안티패턴은 세 가지입니다.

첫째, 프롬프트 저장소를 contract registry라고 부르며 대체하는 경우입니다. 이름만 registry고 실제로는 system prompt 문구와 few-shot 예시만 버전 관리하면, 입력 출처와 freshness 문제는 그대로 남습니다.

둘째, 보안팀만 관리하는 중앙 문서 체계로 굳어지는 경우입니다. 민감도 분류는 중앙 통제가 맞지만, TTL과 allowed_tasks까지 전부 중앙 승인으로 묶으면 도메인 팀이 최신 문서를 제때 반영하지 못합니다. 그러면 형식상 통제는 강해졌는데 stale context rate는 오히려 올라갑니다.

셋째, receipt 없이 차단만 거는 경우입니다. 막았다는 사실만 남고 실제 어떤 조각이 허용됐는지 안 남으면, 품질 사고가 나도 원인을 역추적할 수 없습니다. 그래서 contract registry는 validator만이 아니라 receipt까지 한 세트로 봐야 합니다. 이 점은 Execution Receipt와 연결해서 설계하는 편이 훨씬 낫습니다.

실무적으로는 아래 순서가 안전합니다.

  1. high-risk 작업 2, 3개만 먼저 선정한다.
  2. 그 작업에 실제로 붙는 상위 컨텍스트 조각을 캡처한다.
  3. 허용/금지/요약 규칙을 최소 필드로 붙인다.
  4. receipt를 남긴다.
  5. 한 주 동안 violation과 stale 비율을 본 뒤 범위를 넓힌다.

이 순서를 건너뛰고 전사 공통 레지스트리부터 만들면, 멋진 설계 문서만 남고 실제 런타임은 이전 방식 그대로 굴러가는 경우가 많습니다.

트레이드오프/주의점

첫째, 계약을 너무 세밀하게 시작하면 팀이 지칩니다. 모든 조각에 20개 필드를 붙이려 하지 말고, 사고를 자주 내는 조각부터 시작하는 편이 낫습니다.

둘째, 중앙 집중 과잉입니다. 모든 변경을 플랫폼팀만 승인하게 만들면 현업 속도가 떨어집니다. 민감도 높은 규칙만 중앙 승인으로 두고, TTL 같은 운영 필드는 도메인 팀 자율 업데이트가 맞습니다.

셋째, 지표 착시입니다. 토큰이 줄었다고 품질이 오른 것은 아닙니다. stale context rate와 정답률, 사람 수정률을 같이 봐야 합니다.

넷째, receipt 없는 운영입니다. 어떤 입력 조각이 실제 호출에 들어갔는지 남지 않으면 계약 위반을 추적할 수 없습니다.

다섯째, 프롬프트와 계약의 책임 경계가 모호해지는 문제입니다. 지시문 설계와 입력 자격 관리를 같은 저장소에 뒤섞으면 소유권이 흐려집니다. 둘은 연결돼야 하지만 분리 관리가 낫습니다.

체크리스트 또는 연습

체크리스트

  • 모델 입력을 프롬프트 한 덩어리가 아니라 조각 단위로 본다.
  • 각 조각에 owner, freshness, sensitivity, budget를 붙였다.
  • high-risk 작업군에 allowed_tasks 규칙이 있다.
  • contract violation과 stale context를 분리 측정한다.
  • 정책 변경은 canary 후 rollout 하며 rollback 경로가 있다.
  • 실제 호출에 포함된 입력 조각 receipt를 남긴다.

연습 과제

  1. 현재 운영 중인 AI 작업 10개를 골라, 입력에 들어가는 조각을 source / owner / ttl / sensitivity 네 칸으로 다시 분류해 보세요.
  2. 최근 품질 사고 3개를 골라, 프롬프트 자체 문제였는지 아니면 입력 계약 부재였는지 역추적해 보세요.
  3. incident 대응, 코드 수정, 문서 요약 세 작업군에 대해 allowed context 목록과 금지 context 목록을 각각 5개 이내로 설계해 보세요.

관련 글