인프라 협업 기본
3줄 요약
- AI 기능은 provider outbound, secret, queue, worker, vector DB, observability, 비용을 만들기 때문에 인프라 협업이 필수다.
- 인프라팀의 가장 큰 고충은 AI workload의 latency, token, 비용, 호출 패턴이 예측하기 어렵다는 점이다.
- 백엔드 개발자는 기능 요구보다 QPS, token P95, job duration, queue depth, provider quota를 숫자로 설명해야 한다.
핵심 정리
- AI 기능은 단순 SDK 호출이 아니라 새로운 외부 의존성과 운영 표면이다.
- provider API를 쓰면 outbound, secret, rate limit, 장애 대응이 필요하다.
- RAG를 쓰면 vector DB, embedding worker, indexing batch가 필요하다.
- agent와 MCP를 쓰면 tool server, audit log, 권한, network policy가 필요하다.
- observability를 많이 남기면 로그 비용과 개인정보 위험이 커진다.
헷갈리는 지점
- AI 기능은 애플리케이션 코드이므로 인프라팀 관여가 적다고 생각하기 쉽다.
- 핵심은 AI 기능이 외부 API와 데이터 인프라, 비동기 작업을 늘린다는 점이다.
- 인프라팀은 장애와 비용을 함께 책임지게 된다.
- 인프라팀이 보수적으로 반응하면 기술을 막는다고 느끼기 쉽다.
- 핵심은 인프라팀이 예측 불가능한 workload와 secret, 비용, 장애 반경을 걱정한다는 점이다.
확인 질문
- AI 기능에서 인프라팀과 초기에 합의할 것은 무엇인가?
- outbound, secret, quota, worker, queue, vector DB, logging, fallback, runbook이다.
- 인프라팀이 AI workload를 어려워하는 이유는 무엇인가?
- 입력 길이, token, latency, retry, tool 호출 수, 비용이 크게 흔들리기 때문이다.
배포 전략
3줄 요약
- AI 기능 배포는 코드 배포뿐 아니라 prompt, model, schema, retrieval profile, index 변경을 함께 관리해야 한다.
- feature flag, canary, shadow eval, rollback, prompt versioning이 중요하다.
- 모델과 prompt 변경은 작은 설정 변경처럼 보여도 사용자 품질을 크게 바꿀 수 있다.
핵심 정리
- prompt 변경은 기능 변경이다.
- model 변경은 품질, 비용, latency, safety behavior를 바꾼다.
- schema 변경은 저장 데이터와 downstream workflow에 영향을 준다.
- vector index 변경은 RAG 품질과 권한에 영향을 준다.
- 배포 전 eval, 배포 후 observability 확인, rollback 경로가 필요하다.
헷갈리는 지점
- prompt는 코드가 아니므로 배포 절차가 가벼워도 된다고 생각하기 쉽다.
- 핵심은 prompt가 모델 동작을 바꾸는 실행 계약이라는 점이다.
- 리뷰와 eval, rollback이 필요하다.
- 모델 변경은 성능 개선이라고만 생각하기 쉽다.
- 핵심은 출력 형식, 거절률, 비용, latency가 함께 바뀔 수 있다는 점이다.
확인 질문
- AI 기능 배포에서 코드 외에 관리해야 할 artifact는 무엇인가?
- prompt, model profile, schema, retrieval profile, vector index, tool schema, eval dataset이다.
- canary 배포가 AI 기능에 유용한 이유는 무엇인가?
- 전체 사용자에 적용하기 전에 품질, 비용, validation 실패를 작은 트래픽에서 확인할 수 있기 때문이다.
Self-hosted와 Cloud 선택
3줄 요약
- Cloud provider API는 빠르게 시작하기 좋고 운영 부담이 낮지만 외부 의존성과 데이터 전송, 비용 종속성이 생긴다.
- Self-hosted LLM은 데이터 통제와 비용 구조 장점이 있지만 GPU, serving, scaling, monitoring 부담이 크다.
- 선택은 기술 취향이 아니라 데이터 민감도, latency, 비용, 운영 역량, 규제 요구로 판단한다.
핵심 정리
- cloud API는 모델 업데이트와 serving 운영을 provider가 맡는다.
- self-hosted는 모델 artifact, GPU, batching, capacity planning, 장애 대응을 직접 맡는다.
- hybrid 전략도 가능하다. 일반 요청은 cloud, 민감 데이터는 self-hosted, 개발은 local model을 쓸 수 있다.
- self-hosted가 항상 싸거나 안전한 것은 아니다.
- 인프라팀의 GPU 운영 역량을 현실적으로 봐야 한다.
헷갈리는 지점
- self-hosted는 호출당 과금이 없으니 무조건 싸다고 생각하기 쉽다.
- 핵심은 GPU, idle capacity, 운영 인력, 장애 대응 비용이 있다는 점이다.
- cloud provider는 외부라서 무조건 위험하다고 생각하기 쉽다.
- 핵심은 계약, 데이터 정책, 암호화, 접근 제어로 관리 가능한 경우도 있다는 점이다.
확인 질문
- self-hosted LLM을 선택하기 전에 확인할 것은 무엇인가?
- GPU 운영 역량, 모델 크기, QPS, latency, 비용, monitoring, rollback, 보안 요구다.
- cloud API의 장점은 무엇인가?
- 빠른 도입, 운영 부담 감소, 최신 모델 접근, scaling 위임이다.