이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.
- 기업 운영 수준의 AI 기능은 어떤 체크리스트를 가져야 하는가?
- 인프라팀, 보안팀, 데이터팀, 기획팀, CS팀과 각각 무엇을 논의해야 하는가?
- 인프라 인력이 AI 기능에서 겪는 고충은 무엇인가?
- 백엔드 개발자는 어떤 운영 정보를 숫자로 설명해야 하는가?
개요
기업 운영 수준에서 AI 기능은 단순 기능이 아니라 새로운 운영 표면이다. 외부 provider, vector DB, worker, queue, prompt, eval, 개인정보, tool 권한, 비용 예산이 함께 움직인다.
백엔드 개발자는 AI 기능을 “SDK 하나 추가”가 아니라 운영 시스템으로 설명할 수 있어야 한다.
운영 체크리스트
- 기능 owner가 있는가?
- model provider와 fallback 정책이 있는가?
- prompt/model/schema 변경 관리가 있는가?
- timeout, retry, circuit breaker가 있는가?
- tenant별 quota와 비용 알림이 있는가?
- 개인정보와 민감정보 흐름이 문서화되어 있는가?
- RAG 권한 필터가 DB 권한과 일치하는가?
- eval regression gate가 있는가?
- audit log와 trace가 있는가?
- 장애 런북과 degrade mode가 있는가?
인프라팀과의 접점
인프라팀과는 다음을 논의한다.
- outbound network와 provider endpoint
- API key와 secret rotation
- queue와 worker autoscaling
- vector DB 용량, backup, latency
- embedding batch와 online serving 분리
- observability cardinality와 로그 비용
- gateway timeout과 streaming
- provider 장애 시 circuit breaker
인프라팀의 고충은 예측 불가능성이다. AI 요청은 입력 길이, 모델 latency, retry, token 사용량, tool 호출 수가 크게 흔들린다. 백엔드 개발자는 예상 QPS, token P95, job duration P95, queue depth 한계를 제공해야 한다.
보안팀과의 접점
보안팀과는 다음을 논의한다.
- 개인정보가 provider로 나가는가?
- 데이터 보존과 삭제 정책은 무엇인가?
- prompt injection 방어는 어디에 있는가?
- MCP tool 권한은 어떻게 제한되는가?
- read-only와 write tool이 분리되어 있는가?
- audit log가 충분한가?
- 관리자 권한 tool에 approval이 있는가?
보안팀을 장애물로 보지 않는 편이 좋다. AI 기능은 기존 웹보다 데이터 흐름이 복잡해서 초기에 threat model을 같이 잡아야 나중에 덜 아프다.
데이터팀과의 접점
데이터팀과는 다음을 논의한다.
- 문서와 데이터의 source of truth
- embedding 대상과 제외 대상
- 문서 삭제와 재색인
- eval dataset 생성과 개인정보 제거
- 품질 라벨링
- 데이터 freshness
RAG 품질 문제는 모델보다 데이터 품질 문제일 때가 많다.
기획/제품팀과의 접점
제품팀과는 사용자 경험을 논의한다.
- AI가 모를 때 어떻게 말할 것인가?
- 답변 근거를 보여줄 것인가?
- 품질 저하나 fallback을 사용자에게 표시할 것인가?
- human handoff는 어디서 일어나는가?
- AI 결과를 사용자가 수정할 수 있는가?
AI 실패 메시지는 기술팀 혼자 정하면 어색해지기 쉽다.
CS/운영팀과의 접점
CS팀은 실제 사용자 불만을 가장 먼저 본다.
- 잘못된 답변 신고 흐름
- 답변 source 확인 방법
- 사용자별 요청 로그 조회 권한
- AI 결과 수정과 재생성 절차
- 장애 공지 문구
CS가 원인을 추적할 수 있게 prompt version, source id, trace id를 내부 화면에 연결하면 좋다.
코드로 이해하기
AI 기능 launch checklist를 YAML로 관리할 수도 있다.
feature: document-qa
owner: platform-ai
slo:
p95_latency_ms: 8000
validation_failure_rate: 0.02
cost:
tenant_monthly_token_budget: 5000000
security:
pii_sent_to_provider: false
audit_log: true
rag:
permission_filter: server_enforced
delete_reindex_runbook: true
operations:
fallback_mode: related_documents_only
incident_runbook: docs/runbooks/document-qa.md이런 문서는 인프라와 보안, 제품 대화를 쉽게 만든다.
장애 상황과 대응
기업 장애 대응에서는 즉시 완화와 재발 방지를 나눈다.
즉시 완화:
- 기능 flag off
- fallback model
- related documents only
- queue 처리로 전환
- tenant quota 제한
재발 방지:
- eval case 추가
- prompt/schema rollback path
- alert threshold 조정
- 권한 필터 테스트 추가
- runbook 업데이트
실전 팁
- AI 기능 출시 전 “끄는 방법”을 먼저 정한다.
- provider 장애를 가정한 게임데이를 작게라도 해 본다.
- 로그 원문 저장은 기본값으로 켜지 않는다.
- vector DB와 원본 DB 권한 모델 차이를 문서화한다.
위험 신호!
- AI 기능 owner가 없다.
- 인프라팀이 provider 호출량과 token 예산을 모른다.
- 보안팀이 데이터 흐름을 모른다.
- 장애 때 기능을 끌 방법이 없다.
- CS가 잘못된 답변의 source를 확인할 수 없다.
확인 질문
확인 질문
- 인프라팀이 AI 기능에서 가장 힘들어하는 점은 무엇인가?
- latency, token, retry, worker, provider 의존성이 예측하기 어렵고 로그 비용까지 커질 수 있다는 점이다.
- 기업 운영 AI 기능에서 “끄는 방법”이 중요한 이유는 무엇인가?
- provider 장애, 비용 폭증, 보안 사고 때 전체 서비스를 보호하기 위해 빠른 차단이나 degrade가 필요하기 때문이다.
Spring AI 적용 연결
- 기업 운영 수준의 Spring AI 서비스는 provider 계약, secret, observability, eval gate, rollback, data policy를 한 세트로 본다. 구체 체크는 12. Production Readiness와 인프라 협업에서 이어진다.
- 장애 대응 체계는 11. Observability와 장애 대응 런북과 함께 검증한다.