에이전트 개발 라이프사이클(ADLC)이란 무엇인가요?

대규모 언어 모델(LLM)을 의사 결정 엔진으로 사용하여 정해진 목표를 달성하는 데 필요한 작업을 자율적으로 계획하고 실행하는 소프트웨어 시스템인 AI 에이전트의 성능과 확산은 기업 워크플로의 빠른 변화를 촉발했습니다. 이러한 변화의 속도는 에이전틱 AI 통합의 고유한 요구 사항을 반영하기 위해 기존 IT 구조를 조정하는 여러 조직의 능력을 능가했고, 이로 인해 에코시스템이 파편화되고 있습니다. ADLC는 다양한 도구, 플랫폼, 공급업체 및 엔터프라이즈 환경에서 안정적인 에이전틱 시스템을 촉진하기 위해 공통의 사양과 공유된 관행을 도입합니다.

오늘날의 많은 표준 IT 프로세스는 전통적인 소프트웨어 개발 컨텍스트에서 발전했으며, 정적이고 결정론적인 시스템의 가정에 맞게 조정되어 있습니다. 이러한 프로세스는 에이전트 행동을 좌우하는 LLM의 역동적이고 확률적인 특성에 적합하지 않은 경우가 많습니다. 에이전트를 "AI 에이전트"라고 부르는 이유는 말 그대로 작업을 실행하는 방법을 스스로 결정할 수 있는 자율성을 지니고 있기 때문입니다. 이러한 변화를 설명하는 규범과 사양을 공유하면 관련 위험을 크게 줄이고 책임감 있는 에이전틱 AI 채택을 가속화할 수 있습니다.

 에이전틱 AI가 지속 가능하게 효과적으로 확장되려면 AI 에이전트가 다양한 모델, 플랫폼, 공급업체 및 에코시스템 전반에 걸쳐 예측 가능하게 통합되어야 합니다. 현재 거의 모든 AI 에이전트 구축 플랫폼은 에이전트 정의, 도구 및 함수 호출 스키마, 메모리 및 상태 관리 모델, 테스트 제품군, 배포 프로토콜 및 버전 관리 시스템에 대한 고유한 형식을 갖추고 있습니다. 이러한 파편화는 상호 운용성을 저해하여 전환 비용과 벤더 종속을 가중시킵니다. 최근 연구에 따르면 이는 AI 에이전트 공급업체 에코시스템을 탐색하는 비즈니스 및 기술 리더의 주요 관심사(보안 다음으로 두 번째)인 것으로 밝혀졌습니다.¹ 운영 측면에서도 이러한 파편화는 이전 가능한 기술 및 워크플로의 가능성을 감소시킵니다.

표준화된 규범과 관행을 통해 이러한 비효율성을 완화할 수 있지만, 조직은 개발자의 기존 경향과 선호도에 반하는 것이 아니라 그와 함께 작동하는 구조적 프로토콜을 수용하고 시행하는 것이 중요합니다. 따라서 ADLC는 새로운 개발자 관행을 동급 최고의 에이전트 경험으로 전환하는 것을 목표로 합니다.

ADLC는 핵심 DevSecOps 원칙을 통합하여 AI 에이전트 개발을 상호 연결되고 상호의존적인 일련의 단계로 매핑합니다. 각 단계의 목적과 실제 실행 방식, 그리고 단계 간의 관계는 이 글의 후반부에서 자세히 살펴보겠습니다. 자세한 내용, 제안 및 사양은 공식 IBM ADLC 가이드에서 확인할 수 있습니다.

기존 소프트웨어 개발 라이프사이클(SDLC)의 표준 가정과 모범 사례 중 일부는 AI 에이전트를 구축하는 데 적합하지 않습니다. 엔터프라이즈 AI 에이전트 이니셔티브가 성공하려면 조직은 기존 소프트웨어와 에이전틱 시스템 간의 근본적인 차이점을 이해하고 고려해야 합니다. 

• 결정론적 vs. 확률론적: 기존 소프트웨어는 명시적이고 결정론적인 지침(명령형 코드 형태)을 제공받아 암묵적인 최종 목표를 추구합니다. 반면 AI 에이전트는 명확한 최종 목표와 행동 가이드라인을 제공받은 후, 도구, 데이터 소스 및 자율적인 추론을 활용하여 목표 달성을 위한 최적의 방법을 추론하도록 요구받습니다. 에이전틱 시스템에서는 동일한 입력을 두 번 제공하면 두 개의 다른 아웃풋이 생성될 수 있습니다.

• 정적 vs. 적응형: 기존 소프트웨어는 기능이 고정되어 있으며, 해당 동작을 제어하는 코드가 적극적으로 변경될 때만 동작이 바뀝니다. 에이전트의 행동은 환경으로부터의 피드백을 기반으로 진화할 수 있습니다.

• 코드 중심 vs. 결과 중심: 기존 소프트웨어의 결정론적이고 선형적인 특성으로 인해 개발자는 코드 품질에 대한 안정적이고 (상대적으로) 객관적인 측정 기준으로 프로그램의 성공을 예측할 수 있습니다. 에이전틱 AI의 확률적 특성으로 인해 최적의 구현이 최적이 아닌 에이전트 성능을 산출할 수 있으며, 지저분하고 최적이 아닌 프롬프트로도 정확한 아웃풋을 산출할 수 있습니다. 따라서 에이전틱 시스템 평가는 시간 경과에 따른 비즈니스 결과와 에이전트 행동을 체계적으로 측정해야 합니다.

아마도 가장 중요한 점은, 에이전틱 시스템과 전통적인 소프트웨어의 실패 모드가 매우 다르다는 것입니다.

전통적인 소프트웨어는 논리 오류나 엄격한 코드 명령어를 '깨뜨리는' 예외 사례로 인해 실패합니다. 이러한 실패는 대체로 명확하며, 소프트웨어가 충돌하거나 말도 안 되는 아웃풋을 내는 경우가 많습니다. 전통적인 소프트웨어는 결정론적이기 때문에 어떤 실패도 추적을 통해 코드의 특정 결함을 그 원인으로 파악할 수 있습니다(그 결함은 디버깅할 수 있음).

반면, 에이전틱 시스템은 일반적으로 할루시네이션이나 정렬 문제로 인해 실패합니다. AI 에이전트는 기존 소프트웨어의 엄격한 규칙 기반 논리를 실행하는 대신 시스템 프롬프트, 보호 장치 및 컨텍스트를 통해 제공되는 의도를 확률적으로 해석하는 방식으로 작동합니다. 에이전트는 제약 조건을 위반하거나 잘못된 결과를 자신 있게 제공함으로써 표면적으로 문제를 '해결'할 수 있습니다. 이러한 오류는 놓치기 쉽습니다. 그럴듯하지만 잘못된 아웃풋은 시스템 충돌보다 찾아내기가 더 어렵습니다. 또한 복잡한 다단계 에이전틱 워크플로의 전반적인 실패는 단일 확률 도구 호출의 잘못된 결과에서 비롯될 수 있으며, 후속 평가 시 문제가 되는 오류가 재현되지 않을 수 있습니다.

따라서 ADLC는 각 단계에 관측 가능성 , 격리 및 지속적인 평가를 통합합니다. 에이전틱 개발은 실제 시나리오에서의 철저한 테스트와 실제 위험을 억제해야 할 필요성 사이에서 효율적으로 균형을 이루어야 합니다.

에이전트 개발 라이프사이클(ADLC)은 AI 에이전트를 구축, 배포, 최적화 및 관리하는 프로세스를 개별 단계로 매핑하며, 이 중 일부는 결합되어 반복 루프를 형성합니다.

• 계획: 모든 관련 이해관계자와 협력하여 사용 사례, 목표, 성공 지표 및 이상적인 비즈니스 성과에 대한 합의를 도출합니다(평가 프레임워크 수립에 활용). 원하는 에이전트 동작과 표준 운영 절차를 자연어로 작성하고 문서화합니다.

• 코드 및 빌드: 에이전트를 개발합니다(여기에는 모델 선택, 프롬프트 디자인, 오케스트레이션 등이 포함됨). 도구, 데이터베이스 및 API와 같은 관련 외부 서비스를 식별하고 모델 컨텍스트 프로토콜(MCP)을 사용하여 엔터프라이즈 계층에 통합합니다. 신중한 버전 관리, 샌드박싱 및 게이트웨이 패턴을 적용합니다.

• 테스트 및 출시: 미리 정의된 벤치마크에 대한 구조화된 평가를 실행하고, 정책 점검을 적용하며, 보안 테스트 및 레드팀 구성 연습을 수행하고, 에이전트가 거버넌스된 카탈로그에 포함되어 있는지 인증합니다. 필요에 따라 루프에서 코드 및 빌드와 테스트 및 릴리스를 되풀이하여 반복합니다.

• 배포: 인증이 완료되면 에이전트를 프로덕션 환경으로 이동하고 점진적인 단계로 배포하여 위험을 관리합니다. 효과적인 거버넌스와 정책 집행을 가능하게 하기 위해 게이트웨이 패턴을 채택합니다. 샌드박싱, 버전 관리, 롤백 전략, 보안 강화 및 성능 제한을 통해 런타임 거버넌스를 보장합니다.

• 운영: 배포된 에이전트를 지속적으로 관찰 및 최적화하여 실시간 지표(예: 정확도, 지연 시간, 비용 및 사용자 만족도)를 추적하고 모델 드리프트 또는 성능 회귀에 대한 경고를 유지합니다. 이러한 피드백 루프를 사용하여 성능 및 보안을 위해 프롬프트, 도구, 모델 및 메모리 정책을 최적화하고 필요에 따라 배포-운영 루프를 되풀이하여 반복합니다.

• 모니터링: 시스템 검증 및 최적화가 완료되면 공정성, 투명성 및 규정 준수 여부를 지속적으로 모니터링하고 정기적인 감사를 실시합니다. 관측 가능성과 재현성을 더욱 용이하게 하기 위해 에이전트 및 도구의 체계적인 카탈로그를 유지 관리합니다.

이러한 단계와 해결하고자 하는 우선순위를 준수함으로써 조직은 에이전트를 신뢰할 수 있고 감사 가능하며 비즈니스 가치에 부합하도록 유지하여 안전하고 자신 있게 확장할 수 있습니다.

에이전트 개발 프로세스는 다른 모든 계획 고려 사항이 펼쳐지는 사용 사례 조정에서 시작됩니다.

에이전트가 달성해야 할 구체적인 비즈니스 성과에 따라 에이전트 성능을 평가하는 데 사용될 핵심 성과 지표(KPI) 및 기타 성공 지표가 결정됩니다. 고객 지원 자동화는 주로 최종 사용자 만족도와 비용 절감 측면에서 평가되는 반면 코딩 에이전트는 지연 시간과 코드 품질 측면에서 평가될 수 있습니다. 계산 방법에 따라 성공 신호와 운영 인센티브가 달라질 수 있으므로, 이러한 지표에 대한 구체적인 수학적 공식을 선택하는 것은 그 자체로 중요한 아키텍처 관련 결정입니다.

에이전트 중심의 특정 비즈니스 성과를 달성하려면 에이전트가 자동화해야 하는 특정 프로세스, 작업 및 하위 작업이 필요하며, 이러한 작업 중 상당수는 특정 도구, 데이터 세트, 지식 기반 및 API에 대한 액세스 권한이 있는 AI 에이전트를 프로비저닝해야 합니다. 코드 및 빌드 단계 전에 필요한 모든 리소스 목록을 컴파일(및 조달)하는 것은 효율적이고 효과적인 개발 프로세스에 필수적입니다.

참고로, 계획 단계에서 내려야 할 가장 중요한 결정은 AI 에이전트를 구축할지 여부입니다.

IBM은 특정 비즈니스 요구 사항을 해결할 수 있는 가장 간단한 솔루션을 찾을 것을 권장합니다. 기존의 자동화, 검색 시스템 또는 사려 깊은 프롬프트로 문제를 해결할 수 있다면 에이전틱 AI는 불필요한 복잡성을 야기할 수 있습니다. 예를 들어 고객 이메일에 대한 응답을 자동화하는 시스템에는 AI 에이전트가 필요하지만, 이메일을 분류하는 시스템에는 LLM과 잘 설계된 프롬프트만 있으면 됩니다.

향상된 성능의 에이전틱 AI가 사용 사례를 위한 더 간단한 솔루션을 제공할 수 있다고 가정하면 그에 따른 비용과 지연 시간의 증가가 수반되며, 엔터프라이즈 시나리오에서 에이전틱 AI를 이상적으로 구현하려면 일반적으로 다음이 필요합니다.

• 잘 정의된 제품 범위. 광범위한 규칙 기반 자동화로는 적절하게 달성할 수 없는 판단 또는 다단계 추론이 필요한 특정 비즈니스 문제의 우선순위를 지정합니다. 상황에 맞는 판단, 다단계 추론, 대규모 복잡한 의사 결정이 필요한 문제는 에이전틱 AI가 해결하기에 적합합니다.

• 명확한 성공 지표. 에이전틱 AI는 성공을 객관적이고 정량적으로 평가하고 표준을 적용할 수 있는 시나리오에서 성공을 거둡니다. 이는 비즈니스 관점에서 필요한 타당한 근거뿐만 아니라 운영 관점에서도 필요한 최적화 목표를 제공합니다.

• 관리 가능한 복잡성. 에이전틱 AI의 확률론적 특성으로 인해 다중 에이전트 시스템은 한 단계의 실패가 광범위한 결과를 초래할 수 있는 스캐폴딩 위험을 수반합니다. 에이전틱 시스템의 이론적 이점은 운영상의 복잡성을 명백히 상쇄해야 합니다.

에이전틱 AI의 기업 배포에 대한 철저한 분석을 통해 일관된 가치와 관리 가능한 위험을 나타내는 특정 패턴, 즉 문서 중심 프로세스, 고객 지원(또는 고객 서비스), 문서화 가능한 지식 작업 등을 확인할 수 있었습니다. 이러한 분야는 좋은 출발점이 됩니다.

모든 관련 이해관계자가 목표, 요구 사항, 제약 조건 및 측정 기준에 동의하면 팀은 실제로 AI 에이전트를 구축하는 프로세스인 프롬프트, 메모리 전략, 오케스트레이션 로직 및 평가 프레임워크 구현으로 이동합니다.

에이전트는 기업 시스템, API, 외부 도구 및 지식 기반과 통합되어야 합니다. 이러한 통합은 보안과 텔레메트리를 염두에 두고 설계되어야 합니다. 즉각적인 운영 데이터 및 측정을 자동으로 캡처하는 코드 조각인 관측 가능성 후크를 주요 워크플로 시점에 삽입하여 에이전트 추론 추적, 도구 호출 및 아웃풋을 비롯한 에이전트 녹취록을 기록해야 합니다.

각 개발 단계에서 팀은 개별 에이전트 변형과 (관련된 경우) 멀티 에이전트 시스템 내에서 작업을 조정하는 오케스트레이션 로직에 대해 엄격한 버전 제어 정책을 구현해야 합니다.

AI 에이전트를 구동할 LLM을 선택하는 것은 가장 중요한 아키텍처 결정 중 하나입니다. 모든 작업과 역할에 하나의 모델을 사용하는 것은 성능 측면에서 최적의 구성이 아닌 경우가 많으며, 설령 최적의 구성이라 하더라도 그로 인한 성능 향상은 비용 효율성, 지연 시간 또는 둘 다에서 장단점이 있습니다.

개발자는 복잡한 계획을 위한 최전선의 추론 모델, 적절한 경우 전문화된 작업을 위한 도메인별 모델(모델 제공업체에서 직접 가져오거나 조직의 자체 미세 조정 노력을 통해 얻음), 더 간단한 대용량 작업의 비용과 지연 시간을 최소화하기 위한 더 작은 모델 등 다양한 모델의 포트폴리오를 활용해야 합니다.

모든 통합은 엔터프라이즈 데이터, 서드파티 애플리케이션, 외부 시스템 등 무엇이든 MCP 서버가 지원하는 도구 통합으로 처리할 수 있습니다. 이상적으로는 선택한 에이전틱 엔지니어링 플랫폼을 통해 특정 사용 사례에 맞게 MCP 동작을 조정할 수 있습니다. MCP 게이트웨이 패턴을 사용하여 백엔드 시스템을 통한 모든 연결을 보호하고 관리하세요.

가능하면 도구와 리소스에 대한 MCP, 관측 가능성을 위한 OpenTelemetry, 프롬프트를 위한 재사용 가능한 스키마와 같은 재현성과 개방형 표준을 우선시하세요. 마찬가지로 스토리지 및 검색, 도구 액세스 및 작업 위임에도 일관된 패턴을 채택해야 합니다.

실제 위험에 노출되는 엔터프라이즈 시스템의 경우, 에이전틱 AI 보안은 사후에 추가하기보다는 보안 중심 설계 원칙을 사용하여 각 개발 단계에 직접 통합해야 합니다.

각 AI 에이전트에 고유한 식별 태그가 발급되어 에이전트가 수행하는 모든 행동이 기록되고 감사되며 적절히 귀속될 수 있도록 해야 합니다. 이로써 보안 문제의 원인을 높은 신뢰성으로 추적할 수 있을 뿐만 아니라, 에이전틱 AI 도입이 성숙하면서 지속적으로 진화하는 규제 프레임워크 준수도 용이해집니다.

샌드박싱 및 기타 격리 관행은 위험을 제한하는 데 필수적입니다. 에이전트의 실행 환경, 네트워크 접근 및 파일 시스템 액세스는 항상 최소 권한 원칙에 따라 작동해야 합니다. 에이전틱 시스템의 각 구성 요소는 지정된 작업을 수행하는 데 필요한 최소한의 권한을 부여받아야 합니다.

에이전트 프로토타입을 테스트하여 프로덕션에 출시할 준비가 되었는지 확인하려면 기존 소프트웨어 설계 라이프사이클의 단위 테스트 및 정적 분석 이상의 것이 필요합니다. 또한 실제 시나리오 또는 고충실도 시뮬레이션에 대한 광범위한 동작 검증이 수반되어야 합니다. 에이전틱 시스템의 확률적 특성을 고려할 때, 이러한 테스트 시나리오의 표본 크기는 모든 잠재적인 에이전트 행동이 관찰되고 평가되었다는 합리적인 신뢰도를 제공할 수 있을 만큼 크고 다양해야 합니다.

AI 에이전트는 원하는 행동을 정확히 반영하고 집행하는 사전 정의된 벤치마크와 정책 점검에 따라 테스트되어야 합니다. 이를 위해서는 에이전트가 각 유형의 입력 및 상황에 대해 따라야 하는 궤적을 나타내는 실측 정보 데이터 세트를 수집하거나 생성해야 할 수 있습니다. LLM-as-a-Judge와 휴먼 인 더 루프(Human-in-the-Loop) 검토를 모두 사용하여 전자가 가능하게 하는 규모와 후자가 제공하는 신뢰도의 균형을 맞춰야 합니다.

초기 배포 전후에 필요한 규모로 테스트 및 평가를 실행하고, 평가를 자동으로 실행하고, 도구 신뢰성을 테스트하고, 안전 보호 장치를 적용하려면 강력한 지속적 통합/지속적 전달(CI/CD) 파이프라인이 매우 중요합니다. 테스트 중 지속적 통합(CI) 시스템은 구성 모델과 프롬프트가 업데이트될 때 에이전트의 추론 로직이 중단되지 않게 하는 데 도움이 됩니다. 이미 사용 중인 LLM의 최신 모델 버전으로 교체하더라도 동적 환경에서 예측할 수 없는 영향이 발생할 수 있습니다.

에이전틱 시스템의 성공을 위해서는 ADLC의 모든 구축 후 단계에서 지속적인 AI 에이전트 평가가 필수적입니다. 빌드 및 CI 중 오프라인 평가를 통해 전체 에이전트 행동 및 결과를 벤치마킹할 수 있습니다. 인 더 루프(In-the-loop) 평가는 런타임에 호출되어 에이전트의 개별 결정을 안내합니다. 예를 들어, 에이전틱 RAG 애플리케이션에서는 워크플로에서 컨텍스트 관련성 점수를 계산하여 검색된 소스를 아웃풋을 생성하는 데 사용해야 하는지 여부를 결정할 수 있습니다.

에이전틱 평가 프레임워크에는 다음과 같은 다양한 유형의 측정 지표가 포함되어야 합니다.

• 작업 성공률, 정확도, 도구 호출 성공률과 같은 품질 지표

• 정책 위반 또는 민감한 데이터 유출률과 같은 안전 지표

• 지연 시간, 토큰 소비량, 작업당 비용과 같은 운영 지표

• 만족도 점수 또는 결과당 비용과 같은 비즈니스 지표

레드팀 구성은 적대적인 취약점과 잠재적인 정렬 실패를 사전에 식별합니다. 즉각적인 프롬프트 인젝션 공격 및 탈옥 시도와 같은 적대적인 조건을 시뮬레이션하여 표준 행동 테스트에서 간과할 수 있는 시나리오의 안전 제약 조건을 테스트합니다.

AI 에이전트는 철저한 테스트, 최적화 및 검증을 거친 후 엔터프라이즈 환경에 안전하게 배포됩니다. 배포 단계는 큰 빨간색 '배포' 버튼을 누르는 것과 같은 단발적인 행위가 아니라 전략적으로 계층화된 의도적인 활성화로 이해해야 합니다. ADLC는 샌드박싱, 버전 제어, 롤백 전략 및 페일 세이프를 통해 런타임 시 시스템 안전을 보장합니다. 

위험을 관리하려면 AI 에이전트의 출시를 점진적으로 실행해야 합니다. 블루-그린 배포, 단계적 배포 또는 카나리 배포와 같은 다양한 배포 전략을 고려하여 사용 트래픽 패턴에 가장 적합한 배포 전략을 결정하세요. 실제 엔터프라이즈 환경에서는 안정성이 최우선 순위로 유지되어야 합니다. 롤아웃을 여러 단계로 신중하게 분할하면 의미 있는 업데이트에 대한 시스템의 복원력을 검증할 수 있습니다.

샌드박싱은 에이전트와 그 도구의 접근 범위와 기능을 엄격하게 제한하는 방법으로, 컴퓨팅, 스토리지, 네트워크 및 시스템 API에 대한 최소 권한 접근을 강제하는 제한된 실행 환경 내에서 에이전트와 도구를 실행하는 관행입니다. 에이전트가 실패하거나 잘못 작동하더라도 적절한 샌드박싱을 통해 잠재적인 문제의 범위와 규모를 최소화할 수 있습니다. 이는 한 에이전트의 도구 오용, 코드 생성 또는 데이터 변환이 코드베이스, 데이터 무결성, 고객 또는 다른 에이전트 전반에 영향을 미칠 수 있는 모든 시나리오에서 중요한 관행입니다.

샌드박싱을 위한 일반적인 구현 전략은 다음과 같습니다.

• 경량 가상화

• 컨테이너 보안 프로필

• 네트워크 제어(일반적으로 MCP 게이트웨이를 통해)

• 파일 시스템 액세스 정책

• 게이트웨이 수준의 정책 시행

AI 에이전트가 완전하고 성공적으로 배포된 후에도 ADLC는 끝나지 않습니다. 코드 및 빌드 단계와 테스트 및 릴리스 단계가 형성하는 반복적인 루프처럼, 배포 및 운영 단계 또한 지속적인 피드백 루프의 두 부분으로 이해해야 합니다. 초기 빌드/테스트 루프의 최종 목표는 에이전트가 원하는 비즈니스 성과를 달성하는 데 필요한 최소 성능 임계값을 충족하는 것이지만, 배포/운영 루프의 목표는 최적화입니다.

배포 후에는 실제 환경에서 에이전트의 성능이 안정적이고 효과적이며 안전하게 유지되도록지속적인 운영 감독이 필요합니다. 통합 보고 대시보드에서 컴파일되고 쉽게 액세스할 수 있는 실시간 지표에 드리프트 또는 성능 퇴보가 있는지 적극적으로 모니터링해야 합니다. 운영 효율성이나 최종 사용자 피드백 측면에서 눈에 띄는 퇴보는 적극적으로 해결해야 합니다. 이러한 긴급한 문제에 대한 해결책으로 발생하는 모든 변경 사항은 철저히 테스트하고 점진적으로 배포해야 합니다.

풀 스택 관측 가능성은 최적의 성능, 안전 및 신뢰성을 달성할 뿐 아니라 시간이 지날수록 이를 유지하는 에이전틱 시스템에 매우 중요합니다.

에이전틱 구현이 라이브 프로덕션에서 완전히 검증되고 최적화되면 전반적인 성능 외에도 공정성, 투명성, 보안 위험 및 규정 준수에 대한 지속적인 감사를 실시하세요.

업계 표준 및 법적 요구 사항은 계속 진화하고 있으며, 두 가지 모두를 적극적으로 따라가지 못하면 규제로 인한 불이익, 경쟁 불이익 또는 두 가지 모두가 초래될 수 있습니다. 모델 드리프트는 피할 수 없는 현상이며, 사전 예방적인 접근 방식을 통해 해결하는 것이 가장 좋습니다. 비즈니스 요구 사항은 변화하며, 이러한 요구 사항을 충족하기 위한 에이전틱 시스템도 그에 따라 변경되어야 합니다.

기업은 현재와 미래의 요구에 대비하여 다음이 명확하게 정리된 에이전트 및 도구 카탈로그를 운영해야 합니다.

• 책임 및 문제 에스컬레이션을 보다 용이하게 하는 소유권

• 체계적인 변화 관리 실무를 위한 버전

• 의사 결정의 근거로 활용할 수 있는 정보를 제공하기 위한 위험 대응 태세

• 철저한 운영 감독을 유지하기 위한 모든 관련 환경

• 증거 수집, 평가, 승인 및 레드팀 구성을 더 신속하게 처리하기 위한 감사 가능성