AI 운영 기본
3줄 요약
- AI 운영은 모델 호출 성공률만 보는 것이 아니라 latency, token, validation, retrieval, tool, 비용, 보안을 함께 보는 일이다.
- provider 장애, rate limit, schema 실패, RAG 품질 저하, tool 중복 실행은 모두 운영 런북이 필요하다.
- 좋은 운영은 장애 전 feature flag, fallback, degrade mode, quota를 미리 준비한다.
핵심 정리
- AI 기능도 SLO를 가져야 한다.
- AI 특화 지표에는 validation failure rate, refusal rate, fallback rate, retrieval empty rate, tool error rate가 있다.
- 장애 대응은 즉시 완화와 재발 방지로 나눈다.
- provider 장애가 전체 서버 장애로 번지지 않게 circuit breaker가 필요하다.
- 비용 폭증도 운영 장애로 취급한다.
헷갈리는 지점
- AI 장애는 모델 provider가 해결해야 한다고 생각하기 쉽다.
- 핵심은 provider 장애를 제품 장애로 번지지 않게 하는 것은 백엔드 책임이라는 점이다.
- fallback, queue, degrade, 사용자 메시지를 설계해야 한다.
- 비용 문제는 운영 장애가 아니라고 생각하기 쉽다.
- 핵심은 비용 폭증이 quota 차단과 서비스 중단으로 이어질 수 있다는 점이다.
확인 질문
- AI 특화 운영 지표에는 무엇이 있는가?
- validation failure rate, refusal rate, fallback rate, retrieval empty rate, tool error rate, token usage다.
- provider 장애에 대비하는 대표 장치는 무엇인가?
- timeout, retry 제한, circuit breaker, fallback, degrade mode다.
장애 대응 런북
3줄 요약
- 장애 런북은 증상, 즉시 완화, 원인 확인, 재발 방지, 담당자를 포함해야 한다.
- AI 장애는 모델, prompt, context, retrieval, tool, provider, worker 중 어디서 났는지 분리한다.
- 장애 후에는 eval case와 alert threshold를 업데이트해야 한다.
핵심 정리
- 답변 지연은 token, provider latency, queue depth, vector DB latency를 본다.
- JSON 실패는 prompt, schema, refusal, output truncation을 본다.
- RAG 품질 저하는 index, metadata filter, chunking, reranker를 본다.
- tool 중복 실행은 retry, idempotency, agent loop를 본다.
- prompt injection은 입력 경로와 tool result를 함께 조사한다.
헷갈리는 지점
- 장애 때 prompt부터 고치면 된다고 생각하기 쉽다.
- 핵심은 원인 분리 없이 prompt를 고치면 새 회귀가 생긴다는 점이다.
- trace로 stage를 먼저 좁힌다.
- 장애 대응은 개발팀만 하면 된다고 생각하기 쉽다.
- 핵심은 인프라, 보안, CS, 제품팀이 함께 움직여야 할 때가 많다는 점이다.
확인 질문
- AI 장애 후 반드시 추가해야 하는 것은 무엇인가?
- 재현 가능한 eval case, 런북 업데이트, 필요한 alert 조정이다.
- 장애 원인을 stage로 나누는 이유는 무엇인가?
- 모델 문제인지 retrieval, schema, tool, worker 문제인지 알아야 올바르게 고칠 수 있기 때문이다.
비용 운영
3줄 요약
- AI 비용은 token, retry, batch, eval, embedding, 로그에서 발생한다.
- tenant별 quota, 기능별 budget, prompt version별 usage 추적이 필요하다.
- 비용 폭증은 기술 장애처럼 alert와 차단 정책을 가져야 한다.
핵심 정리
- 사용량 기록에는 feature, tenant, user, model, prompt version, input/output token이 필요하다.
- retry storm은 비용과 rate limit을 동시에 악화시킨다.
- batch/eval은 production quota와 분리하는 것이 좋다.
- prompt cache hit rate는 비용과 latency에 영향을 준다.
- 비용 제한은 사용자 경험과 함께 설계해야 한다.
헷갈리는 지점
- 트래픽이 작을 때는 비용 관측이 필요 없다고 생각하기 쉽다.
- 핵심은 초기부터 usage 구조를 잡아야 나중에 분석 가능하다는 점이다.
- 비용 로그는 나중에 복구하기 어렵다.
- 저렴한 모델만 쓰면 비용 문제가 끝난다고 생각하기 쉽다.
- 핵심은 긴 context와 retry가 단가 차이를 쉽게 넘어선다는 점이다.
확인 질문
- AI 비용 관리를 위해 최소로 기록할 것은 무엇인가?
- feature, tenant, model, prompt version, input/output token, retry count다.
- 비용 폭증을 장애로 봐야 하는 이유는 무엇인가?
- quota 차단, 예산 초과, 서비스 품질 저하로 이어질 수 있기 때문이다.