6.3SLA와 기대치 정렬

SLA에 들어갈 항목은 세 부류로 나뉩니다. 그대로 약속할 수 있는 것, 조건을 붙여야 하는 것, 약속해서는 안 되는 것입니다.

항목	약속 가능성	이유
가용성 (월 99.5%)	그대로 가능	인프라 통제 아래 있다
p95 지연	그대로 가능	입력 길이 상한을 함께 걸면 통제된다
평가셋 기준 품질	조건부	어떤 평가셋인지 명시해야 성립한다
처리량 상한	그대로 가능	사업자 측 한도로 표현된다
임의 입력에 대한 정확도	불가	입력 분포가 정해지지 않으면 값이 정의되지 않는다
환각이 없음	불가	확률적 시스템에서 0을 보장할 수 없다

품질을 약속에서 아예 빼면 이해관계자가 불안해합니다. 그래서 조건부 형태로 바꾸는 기술이 필요합니다. 다음처럼 세 요소를 묶으면 검증 가능한 약속이 됩니다.

• 정해진 평가셋: "합의된 평가셋 v3(200건, 운영 유형 비중 반영)에서"
• 통과선: "요약 환각률 2% 이하를 유지한다"
• 재측정 주기와 대응: "월 1회 재측정하며, 2회 연속 미달 시 원인 분석과 개선 계획을 2주 내 제출한다"

이렇게 쓰면 약속의 대상이 "모든 입력에서의 품질"이 아니라 **"정해진 표본에서의 품질과, 벗어났을 때의 절차"**가 됩니다. 후자는 지킬 수 있고 검증할 수도 있습니다.

품질 항목에는 평가셋 갱신 조항을 반드시 붙이십시오. 평가셋이 고정되면 시간이 지날수록 운영 현실과 멀어지고, 결국 아무도 신뢰하지 않는 숫자가 됩니다. "분기마다 최근 운영 사례로 20%를 교체한다"처럼 갱신 규칙을 함께 적어야 합니다. 다만 교체할 때는 이전 판본도 남겨, 지표가 떨어진 것이 시스템 때문인지 평가셋이 어려워졌기 때문인지 구분할 수 있어야 합니다.

"응답이 느리다"는 보고를 받았을 때 가장 먼저 할 일은 어디서 시간을 쓰는지 쪼개는 것입니다. 전체 목표만 있고 구간별 배분이 없으면 개선을 어디에 해야 할지 정할 수 없습니다.

전형적인 검색 기반 응답의 예산 배분은 다음과 같습니다.

구간	예산	실측	초과
검색·재순위	100ms	90ms	없음
모델 호출	150ms	380ms	+230ms
후처리·검증	50ms	50ms	없음
합계 (p95)	300ms	520ms	+220ms

이 표가 있으면 논의가 "느리다"에서 "모델 구간이 예산의 2.5배를 쓴다"로 바뀝니다. 모델 구간을 줄이는 수단은 여러 가지이고, 각각 품질에 다른 영향을 줍니다.

• 출력 길이 제한 — 가장 직접적입니다. 생성 토큰 수가 지연을 지배하는 경우가 많습니다.
• 사고 과정 예산 축소 — 추론 단계를 줄이면 빨라지지만 어려운 입력에서 품질이 먼저 떨어집니다.
• 모델 등급 하향 — 효과가 크지만 품질 영향도 큽니다. 반드시 함께 측정해야 합니다.
• 프롬프트 캐싱 — 고정 접두부가 큰 경우 첫 토큰까지의 시간을 크게 줄입니다. 품질 영향이 없다는 점에서 우선 검토 대상입니다.

체감 지연과 총 완료 시간을 구분하는 것도 중요합니다. 사용자가 결과를 읽기 시작하는 시점이 중요한 화면이라면, 스트리밍으로 첫 토큰까지의 시간을 줄이는 편이 총 완료 시간을 줄이는 것보다 효과적입니다. 반대로 결과 전체를 받아 후속 처리에 넘기는 배치 작업이라면 첫 토큰 시간은 의미가 없습니다. SLA에 어느 쪽을 적을지부터 합의해야 합니다.

지연 항목에는 입력 상한을 함께 명시하십시오. 입력 길이에 제한이 없으면 지연 약속은 성립하지 않습니다. "입력 8,000토큰 이하일 때"처럼 조건을 붙이고, 초과 입력의 처리 방식도 함께 정해 둡니다.

합의된 SLA가 있어도 기대치는 어긋납니다. LLM 시스템에서 반복되는 경로가 셋 있고, 각각 사전에 문서로 막을 수 있습니다.

첫째, 데모 편향. 앞 수업에서 다룬 그대로입니다. 대응은 데모 시점에 표본 수와 선정 방식을 함께 말하는 것입니다. "이 20건은 대표 유형 위주로 골랐고 롱테일은 포함하지 않았습니다"라는 한 문장이 나중의 긴 해명을 대신합니다.

둘째, 모델 업데이트. 모델이 갱신되면 성능이 대체로 좋아지지만 모든 항목이 좋아지는 것은 아닙니다. 특정 형식을 지키는 능력이나 특정 유형의 판단이 미묘하게 달라질 수 있습니다. 기존 SLA는 갱신 이전의 평가 위에서 합의된 것이므로, 계약에 다음 조항이 필요합니다.

• 모델 버전을 고정할지, 자동 갱신할지 명시한다
• 갱신 시 회귀 평가를 언제까지 수행하고 결과를 어떻게 공유할지 정한다
• 갱신 후 지표가 통과선 아래로 내려가면 이전 버전으로 돌아갈 수 있는지, 그 비용은 누가 지는지 정한다

셋째, 입력 분포 이동. 시스템은 그대로인데 들어오는 요청이 달라져 성능이 내려가는 경우입니다. 신제품 출시, 정책 변경, 계절 요인으로 흔히 일어납니다. 이 경우 지표는 떨어졌지만 시스템이 고장 난 것은 아닙니다. 계약에 "입력 분포가 합의된 평가셋과 크게 달라진 경우 재측정과 기준 재합의를 거친다"는 조항이 없으면, 정상적인 변화가 계약 위반처럼 다뤄집니다.

세 경로 모두 공통점이 있습니다. 기술 문제가 아니라 합의 문서의 공백이라는 점입니다. 아키텍트가 SLA 문서를 검토할 때 확인해야 할 것은 숫자가 아니라 이 조항들의 존재 여부입니다.

SLA는 측정 없이는 종잇조각입니다. 누가 무엇을 언제 보고, 그 결과가 어디로 흘러가는지를 함께 설계해야 합니다.

수집 경로를 두 갈래로 둡니다. 하나는 자동 지표(지연, 오류율, 비용, 사용량)이고, 다른 하나는 사람의 신호(사용자 신고, 상담원 수정, 운영팀 관찰)입니다. 자동 지표만 보면 품질 저하를 놓치고, 사람 신호만 보면 편향된 표본을 봅니다.

사람 신호를 평가셋으로 환류하는 절차가 이 루프의 핵심입니다. 신고가 들어왔을 때 다음 순서로 처리합니다.

1. 재현되는지 확인한다. 재현되지 않으면 입력과 시점을 함께 기록해 둔다.
2. 재현되면 어떤 유형의 실패인지 분류한다.
3. 같은 유형이 평가셋에 있는지 확인한다. 없으면 평가셋에 추가한다.
4. 추가한 뒤 현재 시스템 점수를 다시 낸다.

3단계가 자주 생략됩니다. 신고를 개별 버그로만 처리하면 같은 유형이 계속 재발합니다. 평가셋에 들어가지 않은 실패는 고쳐졌는지 확인할 방법이 없습니다.

리듬을 정해 두는 것도 필요합니다. 매일 볼 것, 매주 볼 것, 분기마다 볼 것이 다릅니다.

주기	보는 것	누가
일	오류율, 지연, 비용 급변	운영팀
주	사람 수정률, 신고 유형 분포	제품·운영
월	평가셋 재측정 결과	아키텍트
분기	평가셋 갱신, SLA 재합의 필요성	전체 이해관계자

마지막으로, 보고에 나쁜 소식을 담는 경로를 미리 만들어 두십시오. 지표가 나빠졌을 때 보고가 늦어지는 조직에서는 문제가 커진 뒤에야 드러납니다. 월간 보고서에 "이번 달 악화된 지표"를 고정 항목으로 두면, 나쁜 소식을 전하는 것이 예외적인 행동이 아니게 됩니다.