이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- AI 기능을 만들 때 인프라팀과 어떤 운영 계약을 합의해야 하는가?
- 인프라팀은 AI 기능에서 어떤 고충을 겪는가?
- 백엔드 개발자는 어떤 수치를 준비해야 대화가 쉬워지는가?
개요
AI 기능은 인프라팀에게 새로운 운영 부담을 준다. 외부 provider, token 비용, queue, worker, vector DB, 로그 비용, secret이 추가되기 때문이다.
좋은 백엔드 개발자는 “AI 기능 하나 추가”가 아니라 “이런 workload와 의존성이 추가됩니다”라고 설명한다.
합의할 운영 계약
- provider outbound endpoint
- API key와 secret rotation
- timeout과 gateway timeout
- rate limit과 quota
- queue와 worker scaling
- vector DB 운영
- batch indexing 시간대
- observability sampling
- log retention
- 장애 시 feature flag
- fallback과 degrade mode
인프라팀의 고충
AI workload는 예측이 어렵다.
- 사용자 입력 길이가 제각각이다.
- token 사용량이 요청마다 다르다.
- retry가 비용과 트래픽을 증폭한다.
- provider latency가 외부 요인에 따라 달라진다.
- vector DB query와 indexing batch가 충돌할 수 있다.
- prompt/context 로그가 커서 저장 비용이 늘 수 있다.
이 고충을 이해해야 협업이 부드럽다.
백엔드가 준비할 수치
- 예상 QPS
- P95 input token
- P95 output token
- 평균 provider latency
- 최대 job duration
- queue depth 예상
- tenant별 월간 budget
- vector index 크기 증가율
- log volume 예상
정확한 수치가 아니어도 가정과 측정 계획을 제시한다.
코드로 이해하기
운영 계약을 manifest로 남긴다.
ai_feature:
name: document-qa
owner: platform-ai
expected_qps: 5
p95_latency_ms: 8000
provider_timeout_ms: 6000
max_input_tokens: 6000
max_output_tokens: 800
queue_required: false
vector_db_required: true
pii_to_provider: false이 문서는 인프라와 보안 리뷰의 공통 언어가 된다.
장애 상황과 대응
AI 장애가 발생하면 인프라팀은 다음을 봐야 한다.
- provider error
- outbound latency
- queue depth
- worker saturation
- vector DB latency
- log volume spike
백엔드가 trace와 metric을 준비해야 한다.
실전 팁
- 기능 출시 전 인프라팀에게 traffic과 token 추정치를 공유한다.
- “끄는 방법”을 먼저 정한다.
- batch와 online workload를 분리한다.
- 로그 원문 저장은 반드시 보안/인프라와 합의한다.
위험 신호!
- 인프라팀이 provider key 위치를 모른다.
- vector DB 운영 owner가 없다.
- queue depth 알림이 없다.
- 로그 비용을 추정하지 않는다.
- 장애 때 feature flag가 없다.
확인 질문
확인 질문
- AI 기능에서 인프라팀과 숫자로 합의하면 좋은 항목은 무엇인가?
- QPS, token P95, latency, job duration, queue depth, budget, log volume이다.
- 인프라팀이 AI 기능을 어렵게 느끼는 이유는 무엇인가?
- workload와 비용, latency, retry가 요청마다 크게 달라 예측하기 어렵기 때문이다.
Spring AI 적용 연결
- Spring AI 서비스의 운영 계약은 provider quota, timeout, retry, secret, observability, fallback을 포함해야 한다. 체크리스트는 12. Production Readiness와 인프라 협업에서 이어진다.
- 장애 감지와 런북으로 연결하는 기준은 11. Observability와 장애 대응 런북을 함께 본다.