이 글에서 얻을 수 있는 것
- 작업 완료 조건과 장애 경계를 먼저 정의한 뒤 배포 방식을 선택하세요.
- 애플리케이션 런타임 배포와 모델 추론 배포는 별개의 결정입니다. 모델을 직접 구축해야 한다고 전제할 필요는 없습니다.
- 장시간 실행되는 작업을 복구하려면 실행 상태와 외부 비즈니스 시스템에 발생한 부수 효과를 함께 확인해야 합니다.
- 비즈니스 결과, 실행 추적 기록, 예외 사례, 복구 훈련을 종합해 검증하세요.
- 점진적 배포와 롤백은 진행 중인 작업, 상태 호환성, 이미 수행된 비즈니스 데이터 쓰기까지 고려해야 합니다.
프로덕션 배포 로드맵: 먼저 경계를 정의하고 항목별로 검증하기
AI Agent를 프로덕션 환경에 배포할 때 핵심은 모델을 추가하거나 오케스트레이션을 복잡하게 만드는 것이 아닙니다. 작업 실패 시 상태를 판단하고 복구할 수 있으며, 변경 시 검증하고 되돌릴 수 있도록 만드는 것입니다. 작업과 완료 조건 정의, 실행 방식 선택, 런타임과 상태 저장소 구축, 보안 경계 적용, 대표성 있는 작업 평가를 순서대로 진행한 뒤, 소규모 트래픽으로 점진적 배포를 수행하고 온콜 대응과 롤백을 준비하는 것이 좋습니다.
먼저 트리거 조건, 입력, 호출이 허용된 도구, 최종 업무 결과, 시간 초과 처리, 사람의 확인이 필요한 단계를 명확히 하세요. 고정된 절차로 이미 요구 사항을 충족한다면, 단지 “Agent화”를 위해 멀티 Agent를 도입할 필요는 없습니다. 워크플로와 Agent 중 무엇을 선택할지는 Anthropic의 Agent 구축 방식에 관한 논의를 참고하세요. 시스템 인터페이스 연동과 도구 권한에 관한 자세한 내용은 AI Agent를 기업의 기존 시스템에 연동하는 방법을 확인하세요.
배포 방식 선택: 제약 조건에 따라 판단하기
아래 표는 아키텍처 제약 조건을 비교하기 위한 것으로, 성능이나 가격에 대한 결론을 제시하지 않습니다. 후보 플랫폼의 기능, 할당량, 운영 책임은 해당 플랫폼의 최신 문서를 기준으로 확인해야 합니다.
| 형태 | 더 적합한 조건 | 중점 확인 사항 |
|---|---|---|
| 관리형 런타임 | 기반 인프라 유지보수를 줄이고 싶으며, 작업 패턴이 플랫폼 제한에 부합하는 경우 | 실행 시간, 네트워크 경계, 상태 영속화, 로그 내보내기 및 할당량 |
| 일반 컨테이너 서비스 | 컨테이너 배포 및 운영 역량을 이미 갖춘 경우 | 재시작 후 복구, 큐 또는 스케줄링, 탄력적 확장 및 상태 점검 |
| Kubernetes | 팀이 이미 클러스터 관리 체계를 갖추고 있으며, 배포·확장 및 축소·릴리스 제어를 세분화해야 하는 경우 | 클러스터 운영, 리소스 격리, 프로브, 릴리스 전략 및 상태 호환성 |
모델 API를 통해 추론을 사용할 때 배포 대상은 일반적으로 애플리케이션 런타임, 통제된 도구 및 상태 서비스입니다. 추론 환경을 자체 구축할지는 지연 시간, 데이터 경계, 모델 가용성 및 운영 요구 사항을 기준으로 별도 평가합니다. Kubernetes Deployment 문서의 롤링 업데이트 및 리비전 롤백 메커니즘을 참고할 수 있지만, 이것이 Agent를 반드시 Kubernetes에 배포해야 한다는 뜻은 아닙니다.
최소 프로덕션 아키텍처: 요청, 실행, 상태 및 관측 연결
调用方 → 鉴权入口/请求校验 → 任务执行器（同步短任务或异步任务 ID）
→ Agent 运行逻辑 → 模型端点/受控工具 → 状态存储与结果核验
→ 日志、指标、追踪与告警
짧은 작업은 결과가 나올 때까지 기다릴 수 있습니다. 호출자가 기다릴 수 있는 시간을 초과하거나 프로세스를 넘어 복구해야 하는 경우에는 작업 ID를 반환하고, 클라이언트가 상태를 조회하거나 완료 알림을 받도록 할 수 있습니다. 작업 상태, 취소의 의미와 처리 방식, 타임아웃 경계 및 결과 조회 권한을 정의하세요.
시스템 연동에 관한 내용은 여기서 반복하지 않습니다. 앞서 소개한 AI Agent를 기업의 기존 시스템과 연동하는 방법을 참조하세요. 온콜 대응 및 엔지니어링 협업 책임은 FDE의 엔지니어링 납품 책임과 협업 범위를 참고할 수 있으며, 구체적인 책임은 프로젝트에서 명확히 정해야 합니다.
릴리스 산출물 준비: 변경 사항을 재현 가능하게 만들기
코드, 의존성 잠금 파일, 실행 이미지, 환경 설정, 프롬프트 템플릿, 모델 및 도구 설정의 버전을 변경 이력에 포함하세요. 의존성은 빌드 과정에서 검증하고, 개발·테스트·프로덕션 환경은 분리하세요. 자격 증명은 통제된 설정 메커니즘을 통해 주입하고 코드 저장소나 일반 로그에 기록하지 마세요. 모델 API 키, 도구 서비스 자격 증명 및 업무용 ID는 각각 별도로 관리하세요.
릴리스 체크리스트에서는 최소한 다음 사항을 확인해야 합니다.
- 실행 진입점, 상태 점검, 리소스 제한 및 종료 신호 처리가 검증되었는지;
- 의존성 버전, 이미지 다이제스트 및 설정 변경을 추적할 수 있는지;
- 프롬프트, 도구 계약, 모델 식별자 및 주요 매개변수의 버전이 기록되어 있는지;
- 회귀 테스트 샘플 및 평가 결과를 릴리스 버전과 연결할 수 있는지;
- 롤백 대상 버전이 시작될 수 있으며, 현재 상태 형식을 읽거나 처리를 명시적으로 거부할 수 있는지.
장기 실행 작업 복구: 체크포인트가 업무의 정확히 한 번 실행을 보장하지는 않음
복구 가능성은 작업 기록, 실행 상태, 업무 부수 효과라는 세 가지 측면과 관련됩니다. 작업이 대기열에 있는지, 실행 중인지, 사람의 개입을 기다리는지, 어느 단계까지 실행되었는지, 외부 시스템에 쓰기가 성공했는지를 파악해야 합니다. 대화 텍스트만 저장해서는 실행 당시의 맥락과 상태를 복원하기에 충분하지 않을 수 있으며, 체크포인트만으로는 외부 쓰기 작업의 결과를 입증할 수도 없습니다.
LangGraph를 예로 들면, 문서는 스레드별 실행 상태를 저장하는 checkpointer와 스레드 간 데이터를 공유하는 store를 구분합니다. 프로세스 재시작 후 복구하려면 적합한 영속성 백엔드가 필요하며, 쓰기, 읽기, 격리, 보존 및 장애 복구를 검증해야 합니다. 인메모리 저장기는 재시작 후에도 데이터가 유지된다는 근거로 삼을 수 없습니다. 자세한 내용은 LangGraph 영속성 문서를 참조하세요.
재시도 전략에서는 개별 시도의 타임아웃, 재시도 가능한 오류, 재시도 횟수 소진 후 처리를 구분해야 합니다. 부수 효과가 있는 도구에는 멱등성 키나 중복 제거 메커니즘을 설계하고, 재시도 전에 업무 처리 결과를 먼저 조회해야 합니다. 호출이 타임아웃되었다고 해서 쓰기가 발생하지 않은 것은 아닙니다. 결과를 확인할 수 없으면 담당자의 수동 확인으로 넘기거나 보상 절차를 실행하세요. 체크포인트, 큐, 재시도만으로는 종단 간 정확히 한 번 처리 보장이 성립하지 않습니다. LangGraph 장애 처리 문서를 참조하세요.
보안 통제: 고위험 작업에 차단 조건 설정하기
배포 전에 최소한 다음 사항을 검증하세요:
- 외부 문서, 웹페이지 및 사용자 입력이 임의로 도구 권한을 확대할 수 없어야 합니다.
- 도구 서비스는 매 호출마다 신원, 리소스 범위 및 매개변수를 검증해야 하며, 영향이 큰 작업에는 사람의 명시적인 확인이 필요합니다.
- 자격 증명은 환경별로 격리하고 교체할 수 있어야 하며, 로그는 민감도에 따라 수집을 최소화하고 민감 정보를 마스킹하며 보존 기간을 설정해야 합니다.
- 승인 기록은 요청, 작업자, 실행 예정 작업 및 최종 업무 처리 결과와 연결되어야 합니다.
- 권한 초과, 프롬프트 인젝션, 중복 제출 및 민감 데이터 유출 테스트에는 모두 예상되는 거부 결과가 정의되어 있어야 합니다.
OWASP 에이전트형 AI 위협 및 완화 자료는 위협 목록을 작성하는 데 도움이 될 수 있지만, 해당 시스템의 보안이나 규정 준수를 입증하지는 않습니다.
평가 게이트: 결과와 과정을 함께 살펴보기
에이전트가 스스로 “완료했다”고 보고하는 것을 검수 기준으로 삼지 마세요. 각 작업 유형에 대해 대상 레코드의 상태, 출력 형식, 금지된 작업 등 실제 환경에서 확인할 수 있는 성공 조건을 정의하세요. 실행 추적 기록을 보존하여 계획 수립, 도구 호출 또는 결과 검증 중 어디에서 실패했는지 파악할 수 있도록 하세요. Anthropic의 에이전트 평가 방법 설명을 참고할 수 있습니다.
테스트 사례에는 정상 입력, 필드 누락, 상충하는 정보, 도구 타임아웃, 권한 거부, 중복 요청 및 외부 콘텐츠를 통한 유도를 포함해야 합니다. 중요한 사례는 여러 번 실행하고 결과의 변동을 기록할 수 있습니다. 배포 게이트에는 작업 결과, 금지된 작업, 예외 처리, 복구 훈련 및 수동 인계 경로를 포함할 수 있습니다. 임계값은 업무 위험, 기존 기준선 및 테스트 결과를 바탕으로 정하세요.
모니터링: 품질, 지연 시간, 복구 및 비용
각 지표의 산정 기준, 수집 지점, 알림 조건 및 담당자를 정의하세요:
| 항목 | 관측 지표 | 검증 방법 |
|---|---|---|
| 비즈니스 결과 | 완료된 작업 수, 유효한 작업 수, 최종 상태 | 모델 응답만 집계하지 않고 비즈니스 시스템의 상태와 대조 |
| 사람의 개입 | 인계율, 승인 대기, 수동 수정 사유 | 필수 승인과 시스템 실패를 구분 |
| 안정성 | 엔드투엔드 P95, 도구 오류, 재시도 횟수, 타임아웃 및 복구 결과 | 작업 유형과 의존성별로 구분하고 집계 기간을 명확히 정의 |
| 비용 | 토큰 사용량, 모델 및 도구 호출, 성공한 작업 1건당 비용 | 성공한 작업 수를 분모로 사용하고 비용 범위를 정의 |
실행 추적은 다단계 실행에서 발생한 이탈을 파악하는 데 사용하고, 비즈니스 최종 상태는 작업 완료를 확인하는 데 사용합니다. 로그에서 비식별화할 필드, 접근 범위, 보관 기간은 프로젝트별로 정해야 합니다. 출시 초기에는 기준선을 관찰한 뒤 비즈니스 위험에 따라 알림 임계값을 조정합니다.
점진적 배포, 롤백 및 진행 중인 작업 처리
배포 전에 코드, 프롬프트, 모델 설정, 도구 계약의 조합을 대상으로 회귀 테스트를 수행합니다. 먼저 제한된 트래픽이나 저위험 작업에서 검증한 다음 트래픽을 점진적으로 확대합니다. 비즈니스 결과 이상, 권한 초과 테스트 실패, 오류 및 지연이 팀에서 정한 한계를 초과하는 경우 등 중단 조건을 설정합니다.
장애 발생 시 새 작업 접수를 일시 중단하거나 고위험 도구를 비활성화하고, 실행 중·대기 중·완료된 작업을 파악한 뒤 외부 시스템에 발생한 부수 효과를 확인하고 검증된 버전으로 롤백합니다. 이전 버전이 현재 상태 형식과 호환되는지 검증합니다. 자동 복구가 불가능한 작업은 담당자에게 인계하거나 승인된 보상 처리를 수행합니다. Kubernetes를 사용하는 경우 Kubernetes Deployment를 배포 참고 자료로 활용할 수 있습니다. 애플리케이션을 롤백해도 이미 수행된 비즈니스 데이터 쓰기는 자동으로 취소되지 않습니다.
교육용 실습: 장애 주입으로 복구 경로 검증하기
다음은 교육용 실습 설계이며, 고객 사례나 실측 성과가 아닙니다. 작업을 “보고서를 생성하고, 담당자 확인 후 결과를 저장하기”로 설정하고 매번 예상 결과, 실제 결과, 증거를 기록합니다.
| 장애 주입 시나리오 | 인수 검증 중점 사항 |
|---|---|
| 모델 또는 도구 의존성 타임아웃 | 개별 호출 타임아웃과 작업 전체 제한 시간을 구분하고, 비즈니스 결과를 확인한 후 재시도하는지 검증 |
| 실행 프로세스 재시작 | 작업 상태가 영속적으로 저장되는지, 검증 가능한 지점부터 재개되는지 검증 |
| 중복 요청 또는 중복 전달 | 멱등성 보장이나 중복 제거를 통해 중복 쓰기를 방지하는지 검증 |
| 이전 애플리케이션 버전으로 롤백 | 상태 형식의 호환성을 확인하는지, 호환되지 않을 때 안전하게 중단하고 담당자에게 인계하는지 검증 |
실습에서는 비즈니스 상태와 실행 기록이 예상과 일치하는지 확인하고, 예외 작업의 담당자와 처리 절차를 명확히 해야 합니다.
운영 배포 인수 체크리스트
- 작업 범위, 완료 기준, 금지 동작, 담당자 확인 시점을 문서화했습니다.
- 배포 형태가 작업 소요 시간, 복구 요구 사항, 팀의 운영 역량에 부합합니다.
- 의존성, 이미지, 프롬프트, 모델 설정, 도구 계약을 추적할 수 있습니다.
- 작업 상태, 영속적 저장, 비즈니스 부수 효과를 각각 검증할 수 있으며, 재시도에 멱등성 보호가 적용되어 있습니다.
- 권한, 프롬프트 인젝션, 민감한 로그, 담당자 승인에 대한 테스트를 통과했습니다.
- 평가에 대표 작업, 예외 샘플, 결과 검증, 복구 시나리오가 포함되어 있습니다.
- 지표 정의, 알림 담당자, 점진적 배포 중단 조건, 당직 절차를 확정했습니다.
- 롤백 대상 버전, 진행 중인 작업 처리, 상태 호환성, 비즈니스 보상 처리 경로에 대한 실습을 완료했습니다.
배포 시 자주 묻는 질문
질문: 반드시 Kubernetes를 사용해야 하나요? 답변: 꼭 그렇지는 않습니다. 팀에 작업 실행 시간, 상태 복구, 네트워크 격리 및 운영 요구 사항을 충족하는 플랫폼이 이미 있다면, 에이전트 때문에 클러스터의 복잡성을 높일 필요는 없습니다.
질문: 에이전트를 배포하려면 모델을 직접 구축해야 하나요? 답변: 꼭 그렇지는 않습니다. 모델 API로 추론을 수행한다면 일반적으로 애플리케이션 런타임, 통제된 도구, 상태 관리 구성 요소만 배포하면 됩니다. 추론 인프라를 직접 구축할지는 데이터 경계, 지연 시간, 가용성 및 운영 요구 사항을 별도로 평가해 결정하세요.
질문: 서비스가 재시작되면 작업이 사라지나요? 답변: 작업 기록, 실행 상태의 영속화, 복구 절차 검증 여부에 따라 달라집니다. 프로세스 메모리에만 의존해서는 재시작 후 복구를 지원할 수 없습니다. 중복 실행을 방지하려면 외부 시스템에 대한 쓰기 작업의 성공 여부도 확인해야 합니다.
질문: 재시도로 인한 중복 쓰기를 어떻게 방지하나요? 답변: 비즈니스 작업에 멱등성 키나 중복 제거 기록을 적용하고, 재시도 전에 외부 시스템 상태를 확인하세요. 확인할 수 없다면 자동 재시도를 일시 중지하고 수동 확인이나 보상 처리 절차로 전환하세요.
질문: 출시를 위한 성공률 임계값은 얼마로 설정해야 하나요? 답변: 공통으로 적용할 수 있는 수치는 없습니다. 작업 위험도, 비즈니스 기준선, 테스트 결과를 바탕으로 출시 승인 기준과 알림을 설정하고, 금지된 동작의 차단, 수동 개입, 복구 및 비즈니스 결과도 함께 검증하세요.
자주 묻는 질문
참고 자료 및 실무 리소스
원문 문서를 직접 확인하거나 관련 자료를 내려받아 프로젝트 논의에 활용하세요. 외부 자료는 출처 사이트의 최신 안내를 기준으로 합니다.