평가, 관측성, 거버넌스

감으로 튜닝하는 시스템은 오래가지 못한다

컨텍스트 시스템은 처음에는 감으로 좋아질 수 있다. 프롬프트를 조금 고치고, 검색 결과 개수를 바꾸고, 대화 요약 방식을 조정하면 즉시 나아지는 것처럼 보인다. 그러나 프로덕션에서는 이 방식이 곧 한계에 부딪힌다.

사용자는 다양하고, 데이터는 변하며, 모델 버전도 바뀐다. 어제 잘 맞던 검색 쿼리가 오늘은 오래된 문서를 가져올 수 있다. 짧은 대화에서는 문제가 없던 메모리가 장기 대화에서는 잘못된 선호를 계속 주입할 수 있다. 도구 호출 한 번의 오류가 다음 추론과 다음 행동으로 전파되기도 한다.

그래서 좋은 컨텍스트 시스템은 "답변이 그럴듯한가"만 보지 않는다. 어떤 컨텍스트가 조립되었는지, 왜 그 문서가 선택되었는지, 어떤 메모리가 읽혔는지, 어떤 도구가 호출되었는지, 그 결과가 최종 답변에 어떻게 반영되었는지를 측정한다.

컨텍스트 엔지니어링의 운영 원칙은 단순하다.

좋은 컨텍스트는 느낌으로 관리하지 않는다. 로그, 평가, 정책으로 관리한다.

최종 답변 평가와 컨텍스트 평가를 분리하기

LLM 평가에서 흔히 보는 지표는 유창성, 일관성, 관련성, 사실 일관성, 공정성 같은 생성 품질이다. Microsoft의 LLM 평가 지표 정리에서도 자동 평가는 사람이 보는 품질 요소를 확장 가능한 방식으로 측정하려는 시도라고 설명한다¹. 이 지표들은 중요하다. 하지만 컨텍스트 시스템을 평가하기에는 충분하지 않다.

예를 들어 답변이 틀렸다고 하자. 원인은 여러 가지다.

• 검색기가 관련 문서를 찾지 못했다.

• 관련 문서는 찾았지만 컨텍스트 예산 때문에 제외되었다.

• 문서는 포함되었지만 모델이 근거를 무시했다.

• 오래된 메모리가 최신 문서보다 높은 우선순위로 들어갔다.

• 도구 선택은 맞았지만 도구 입력값이 잘못되었다.

• 구조화 출력 형식을 지키지 않아 후속 시스템이 실패했다.

이 모든 실패를 "모델이 환각했다"로 묶으면 고칠 수 없다. 따라서 평가는 층을 나누어야 한다.

핵심은 최종 답변 점수 하나로 전체 시스템을 판단하지 않는 것이다. 검색 문제는 검색 지표로, 메모리 문제는 메모리 지표로, 도구 문제는 도구 지표로 봐야 한다. 그래야 튜닝의 대상이 분명해진다.

실패를 재현 가능한 사건으로 만들기

프로덕션 장애 대응에서 가장 나쁜 상황은 "그때는 틀렸는데 지금은 재현이 안 된다"이다. LLM 시스템은 비결정성이 있고, 컨텍스트는 매번 동적으로 조립된다. 그래서 실패 순간의 입력만 저장해서는 부족하다. 그 순간 모델이 실제로 본 컨텍스트 전체를 남겨야 한다.

이를 assembled context snapshot이라고 부를 수 있다. 최종 입력창에 들어간 시스템 지시, 사용자 요청, 검색 결과, 메모리, 도구 결과, 요약된 대화 기록, 출력 형식 지시를 하나의 스냅샷으로 저장하는 것이다. 에이전트 평가에서 전체 실행 기록인 transcript 또는 trace가 중요하다는 설명도 같은 맥락이다. 에이전트는 여러 턴에 걸쳐 도구를 호출하고 상태를 바꾸기 때문에, 최종 답변보다 전체 궤적이 더 많은 진단 정보를 담는다².

운영 로그에는 최소한 다음 정보가 필요하다.

• 요청 ID, 사용자·조직·권한 범위

• 모델 이름, 모델 버전, 프롬프트·컨텍스트 템플릿 버전

• 슬롯별 토큰 수: 시스템 지시, 대화 기록, 검색 결과, 메모리, 도구 결과

• 검색 쿼리, 검색 시각, 문서 ID, 문서 버전, 랭킹 점수

• 포함된 근거와 제외된 근거, 제외 사유

• 읽은 메모리와 쓴 메모리의 시각, 출처, 만료 정책

• 도구 호출 이름, 입력값, 출력값, 오류, 재시도 여부

• 캐시 히트 여부와 캐시 키

• 최종 출력, 인용 정보, 구조화 출력 검증 결과

• 사용 토큰, 지연 시간, 비용

이 로그는 단순한 기록이 아니다. 실패를 다시 실행하고, 어느 단계에서 정보가 손상되었는지 찾는 디버깅 장치다. 검색 결과가 문제였는지, 압축 과정에서 핵심 조건이 빠졌는지, 오래된 메모리가 끼어들었는지 확인할 수 있어야 한다.

로그 설계에서 주의할 점도 있다. 민감 정보는 그대로 남기지 않는다. 원문 저장이 필요한 경우 접근 권한과 보존 기간을 둔다. 원문이 필요하지 않은 경우에는 문서 ID, 해시, 필드 수준 메타데이터만 저장한다. 관측성은 감사를 가능하게 해야 하지만, 새로운 개인정보 위험을 만들어서는 안 된다.

정기 벤치마크로 긴 컨텍스트의 약점을 찾기

컨텍스트 시스템은 배포 전에만 평가해서는 안 된다. 데이터와 사용 방식이 변하면 성능도 변한다. 정기 벤치마크가 필요한 이유다.

가장 먼저 운영할 테스트는 needle-in-a-haystack이다. 긴 문맥 속에 작은 핵심 정보를 숨겨 두고 모델이 찾아내는지 보는 방식이다. 긴 컨텍스트를 지원하는 모델이라도 중요한 정보가 노이즈 사이에 묻히면 놓칠 수 있다. 이 테스트는 "토큰 창이 충분한가"가 아니라 "긴 문맥에서 필요한 정보를 실제로 사용하는가"를 확인한다.

두 번째는 context rot probe다. 관련 없는 문서, 중복 문서, 오래된 대화 기록을 점진적으로 늘리며 정확도가 어떻게 떨어지는지 측정한다. 컨텍스트가 길어질수록 답변 품질이 서서히 나빠진다면, 더 큰 모델보다 더 강한 선택·압축 정책이 필요하다.

세 번째는 장기 대화 회귀 테스트다. 20턴, 50턴, 100턴 대화에서 사용자의 목표, 결정 사항, 금지 조건, 미해결 이슈가 유지되는지 확인한다. 여기서는 최종 답변만 보지 말고 대화 요약과 메모리 쓰기 결과도 함께 채점해야 한다.

네 번째는 RAG 근거 누락 테스트다. 정답에 필요한 문서가 지식베이스에 있을 때, 검색기가 그 문서를 찾는지, 컨텍스트 조립기가 포함하는지, 모델이 실제로 인용하는지 분리해 본다. "문서가 있었는데 답변에 반영되지 않았다"는 실패는 RAG에서 매우 흔하다.

다섯 번째는 도구 호출 시나리오 테스트다. 올바른 도구 선택, 파라미터 구성, 오류 처리, 재시도, 승인 요청을 검증한다. 특히 에이전트는 한 번의 잘못된 도구 호출이 상태 변경으로 이어질 수 있으므로, 결과보다 과정 검증이 중요하다.

이 벤치마크들은 모두 회귀 테스트로 운영해야 한다. 프롬프트, 검색 인덱스, 메모리 정책, 모델 버전, 도구 스키마가 바뀔 때마다 같은 세트를 다시 실행한다. 그래야 개선이 실제 개선인지, 다른 영역의 성능을 희생한 결과인지 알 수 있다.

자동 평가와 사람 평가를 함께 쓰기

자동 평가는 필수다. 모든 배포 후보를 사람이 읽을 수는 없다. 코드 기반 평가기는 빠르고 싸며 재현성이 높다. 예를 들어 JSON 스키마 준수, 필수 인용 존재, 금지 도구 호출 여부, 특정 필드 누락 여부는 코드로 명확히 판단할 수 있다.

모델 기반 평가기도 유용하다. 답변의 충실도, 근거 일치, 설명 품질처럼 정답이 하나로 고정되지 않는 작업을 넓은 범위에서 평가할 수 있다. 다만 모델 평가기는 그 자체로 오류와 편향을 가진다. 평가 프롬프트가 바뀌면 점수도 흔들릴 수 있다.

그래서 사람 평가가 필요하다. 모든 샘플을 사람이 볼 필요는 없다. 대표 샘플, 실패 가능성이 높은 샘플, 새 기능 배포 전후 샘플을 뽑아 전문가가 검토한다. 이 결과는 자동 평가기를 보정하는 기준이 된다. Anthropic도 에이전트 평가는 코드 기반, 모델 기반, 사람 평가를 조합해 사용하며, 작업의 성격에 따라 채점 방식을 달리해야 한다고 설명한다².

실무에서는 세 가지 데이터셋을 운영하면 좋다.

• 황금 데이터셋: 정답과 근거가 검증된 핵심 업무 세트

• 작업별 회귀 세트: 검색, 메모리, 도구, 출력 형식 등 변경 영향을 보는 세트

• 실패 사례 라벨 세트: 실제 운영 중 발생한 오류를 원인별로 분류한 세트

중요한 것은 평가 지표가 사용자 가치와 계속 연결되어야 한다는 점이다. 점수는 올랐지만 사용자가 더 많이 수정해야 한다면 좋은 개선이 아니다. 인용률은 올랐지만 쓸모없는 출처를 많이 붙인다면 역시 실패다. 지표는 목표가 아니라 운영 판단을 돕는 도구다.

거버넌스는 컨텍스트 레이어 안으로 들어와야 한다

기업 환경에서 컨텍스트는 단순한 정보 묶음이 아니다. 의미, 권한, 계보, 정책을 함께 담아야 한다. 같은 "매출"이라도 확정 매출인지 예상 매출인지, 어느 부서의 정의를 따르는지, 누가 볼 수 있는지에 따라 사용할 수 있는 방식이 달라진다.

AI 거버넌스 관점에서 중요한 변화는 정책 문서를 바깥에 두는 것이 아니라, 모델이 실행 중 참조할 수 있는 형태로 컨텍스트 레이어에 연결하는 것이다. 거버넌스 규칙을 기계가 조회 가능한 구조로 만들고, 데이터 분류·접근 조건·승인 절차와 연결해야 한다는 논의도 이 방향을 가리킨다³. IBM 역시 에이전트가 기업 데이터와 워크플로를 다룰 때는 승인 상태, 접근 제어, 정책 제약, 계보가 실행 시점에 작동해야 한다고 강조한다⁴.

컨텍스트 거버넌스에는 다음 요소가 포함된다.

• 의미 계층: 핵심 용어, 지표 정의, 조직별 해석 차이

• 데이터 계보: 데이터 출처, 변환 과정, 최신성, 품질 상태

• 접근 권한: 사용자·역할·지역·고객 등급별 허용 범위

• 보존 정책: 로그, 대화, 메모리, 도구 결과의 저장 기간

• 승인 워크플로: 고위험 답변, 외부 전송, 상태 변경 작업의 승인 조건

• 위험 등급: 업무 영향도, 규제 민감도, 자동 실행 가능 여부

이 정보가 컨텍스트 조립 단계에 연결되어야 한다. 사용자가 볼 수 없는 문서는 검색 결과에서 제외되어야 한다. 임시 데이터는 확정 데이터처럼 답변에 쓰이면 안 된다. 고위험 도구는 자동 호출이 아니라 승인 대기 상태로 넘어가야 한다.

감사 가능성도 중요하다. 나중에 문제가 생겼을 때 "누가, 어떤 권한으로, 어떤 데이터와 정책에 근거해, 어떤 모델 버전으로 답변을 생성했는가"를 설명할 수 있어야 한다. 이것이 팀·제품·에이전트가 늘어나도 일관된 AI 운영 표준을 유지하는 방법이다.

대시보드는 튜닝 우선순위를 정하는 장치다

운영 대시보드는 예쁜 그래프 모음이 아니다. 어디를 먼저 고쳐야 하는지 결정하는 장치다. 컨텍스트 개선은 품질, 비용, 속도에 동시에 영향을 준다. 따라서 한 지표만 보면 잘못된 결정을 할 수 있다.

예를 들어 검색 결과 개수를 늘리면 환각률은 낮아질 수 있지만 지연 시간과 비용은 오른다. 대화 요약을 강하게 하면 토큰 효율은 좋아지지만 중요한 결정 사항이 사라질 수 있다. 캐시를 적극적으로 쓰면 속도는 빨라지지만 오래된 컨텍스트가 재사용될 위험이 생긴다.

대시보드에는 다음 KPI를 함께 두어야 한다.

• 환각률 또는 미근거 주장 비율

• 근거 인용률과 인용 커버리지

• 검색 적합도와 근거 누락률

• 토큰 효율: 성공 요청당 평균 토큰 수

• 지연 시간: p50, p95, p99

• 요청당 비용과 월별 비용 추세

• 캐시 히트율과 캐시로 인한 오류율

• 구조화 출력 준수율

• 도구 호출 성공률과 재시도율

• 휴먼 리뷰 불합격률

• 개발·운영 처리 속도: 장애 재현 시간, 수정 후 재평가 시간

컨텍스트 엔지니어링의 효과를 환각 감소, 토큰 효율, 개발 속도, 추적 가능성 같은 지표로 설명하려는 접근은 이미 여러 운영 가이드에서 강조되고 있다⁵. 중요한 것은 이 지표들을 따로 보지 않는 것이다. "품질은 올랐지만 비용이 두 배가 되었다"면 다음 과제는 압축과 캐시다. "비용은 줄었지만 근거 누락이 늘었다"면 검색과 선택 정책을 다시 봐야 한다.

결국 평가, 관측성, 거버넌스는 별개의 활동이 아니다. 평가는 무엇이 좋은지 정의한다. 관측성은 실제로 무슨 일이 일어났는지 보여준다. 거버넌스는 무엇이 허용되는지 정한다. 이 세 가지가 연결될 때 컨텍스트 시스템은 개인의 감각이 아니라 조직의 운영 능력으로 발전한다.

참고

¹A list of metrics for evaluating LLM-generated content

²Demystifying evals for AI agents

³Context Engineering for AI Governance: Complete 2026 Guide

⁴Context engineering: The foundation for trusted agentic AI

⁵The Measurable Impact of Context Engineering AI: A Data-Driven Guide