AI 에이전트 생애주기 관리의 새 접근법, ADLC의 부상
AI 에이전트 도입이 기업 현장 전반으로 빠르게 확산되면서, 소프트웨어 개발 방식의 근본적인 재검토가 요구되고 있다. 기존의 소프트웨어 전달 방식은 결정론적 실행 경로와 명확히 정의된 애플리케이션 동작을 전제로 설계됐다. 그러나 소프트웨어 자체가 작업 수행 방법을 스스로 결정하는 에이전트형 AI 시스템 환경에서는 기존 방식을 그대로 적용하기 어렵다는 한계가 뚜렷이 드러나고 있다.
가장 큰 차이는 에이전트가 비결정론적이고 맥락 의존적인 행동을 보인다는 점이다. 전통적인 애플리케이션은 코드와 구성 설정에 따라 동작이 결정되지만, 에이전트는 작업 처리 방식, 사용할 도구, 수행할 행동을 동적으로 결정할 수 있다. 에이전트의 동작은 모델, 프롬프트, 도구, 데이터, 메모리, 런타임 맥락의 영향을 받는다.
기존의 소프트웨어 개발 생애주기는 이런 새로운 요구사항을 충족하도록 설계되지 않았으며, 소프트웨어를 설계·평가·관찰·거버넌스·운영하는 방식 전반에 변화가 필요해졌다. 에이전트 개발 생애주기(ADLC, Agent Development Life Cycle)의 필요성이 부각되는 배경이다.
ADLC는 에이전트 정의와 설계부터 개발, 배포, 운영에 이르는 모든 단계에 지속적 평가, 에이전트 관찰 가능성, 에이전트 신원 관리, 도구 접근 제어, 거버넌스 등 에이전트 특화 고려 사항을 통합함으로써 기존 소프트웨어 개발 관행을 확장한다.
이제 ADLC의 주요 측면과 에이전트 구축·운영의 고유한 요구사항을 어떻게 충족하는지 살펴본다.
에이전트 정의터 시작하라
코드 작성을 시작하기 전에, 에이전트가 해결해야 할 문제와 범위·경계, 성공 판단 기준을 명확히 정의해야 한다.
예를 들어, 호텔 예약 에이전트는 사용자가 적합한 호텔을 찾고, 옵션을 비교하며, 예약을 생성·수정·취소하는 작업을 지원할 수 있다. 또한 범위 설정 시 에이전트가 담당하지 않는 영역도 명확히 규정해야 한다.
범위를 바탕으로 측정 가능한 성공 기준을 수립해야 한다. 예를 들어, 에이전트는 유효한 예약 요청의 95%를 사람의 개입 없이 처리해야 하며, 사용자의 명시적 승인 없이 예약을 확정해서는 안 된다.
구현 방법을 결정하기 전에 에이전트의 목표와 경계를 팀 전체가 명확히 공유할 수 있다.
에이전트 동작 설계
먼저 그 사용례에 에이전트가 실제로 필요한지 판단해야 한다. 결정론적 워크플로로 문제를 해결할 수 있다면, 에이전트 도입은 불필요한 복잡성을 초래할 수 있다.
에이전트 방식이 필요하다고 판단되면, 적절한 프레임워크, 아키텍처, 패턴을 결정해야 한다. 단일 에이전트를 사용할지, 감독자와 전문 에이전트를 조합할지, 또는 다른 오케스트레이션 패턴을 적용할지 검토해야 한다.
에이전트가 정의된 범위를 수행하는 데 필요한 도구와 데이터를 결정해야 한다. 에이전트가 사용할 수 있는 도구뿐 아니라 수행 가능한 작업의 한계도 명시해야 한다. 예를 들어, 호텔 예약 에이전트는 객실 가용성 확인 및 예약 도구에 접근할 수 있어야 하지만, 객실 가격 변경이나 환불 처리 권한은 부여해서는 안 된다.
설계 단계에서는 에이전트가 맥락과 메모리를 처리하는 방식, 동작 평가 방법도 명시해야 한다. 평가 기준과 데이터셋을 정의하고, 품질·안전성·지연 시간·비용 및 기타 관련 요소의 허용 한도도 설정해야 한다.
설계 결정 사항은 구현의 청사진이 된다. 이후 선택한 프레임워크를 활용해 에이전트를 개발하며, 앞서 ‘정의’ 단계에서 수립한 성공 기준을 토대로 개발 전반에 걸쳐 평가를 수행한다.
최종 결과를 넘어선 평가
평가는 에이전트 개발에서 핵심적인 역할을 하며, 에이전트 생애주기 전반에 걸쳐 지속된다. 개발 단계에서 참조 데이터셋을 활용해 평가를 수행할 수 있으며, 실제 운영 환경이나 유사한 환경에서도 지속적으로 평가할 수 있다.
평가자는 결정론적 규칙, 모델 기반 판단, 또는 도메인별 로직을 활용해 수립된 기준에 따라 에이전트 동작의 다양한 측면을 평가한다.
전통적인 테스트와 달리, 에이전트 평가는 최종 출력에만 국한될 수 없다. 에이전트는 작업 수행 중 의사 결정과 행동을 취하기 때문에, 결과에 이르는 경로가 결과 자체만큼 중요하다. 에이전트가 기대하는 결과를 달성하더라도 비효율적인 경로를 택하거나 권한 밖의 행동을 수행할 수 있다.
따라서 정확성, 유용성, 안전성, 도구 사용, 오류 복구, 효율성, 추론 품질, 어조 등 다양한 차원을 고려해야 한다. 각 차원은 서로 다른 평가자가 담당하며, 특정 품질 측면을 점검하는 방식으로 운영할 수 있다. 여러 평가자를 활용하면 출력 결과와 그에 이르는 행동 모두를 포함하는 종합적인 품질 프로파일을 구성할 수 있다.
엔터프라이즈 통합 소프트웨어 전문 업체 WSO2에서 진행한 로보틱스 사용례에서 에이전트는 로봇을 제어하며 쓰레기통을 찾는 임무를 맡았다. 이 작업에는 로봇 이동, 이미지 촬영, 촬영한 이미지에서 쓰레기통을 확인하는 과정이 포함됐다. 에이전트는 결국 쓰레기통을 찾았지만, 경로 효율성 평가에서 낮은 점수를 받았다. 반복적인 회전과 이미지 촬영이 비효율적이라는 판단이었지만, 실제로 에이전트가 물리적 환경을 파악하기 위해 필수적인 행동이었다. 문제는 에이전트가 아니라 평가자에게 있었다. 문제 해결을 위해 환경과 제약 조건을 반영한 맞춤형 평가자를 개발했고, 에이전트 동작 개선에 활용했다.
핵심은 ‘작동한다’는 사실만으로는 충분하지 않다는 점이다. 에이전트가 운영되는 환경의 맥락에서 올바른 에이전트 동작의 기준을 수립해야 한다.
에이전트 시스템의 관찰 가능성
에이전트의 동작을 파악하려면 개발 단계와 실제 운영 이후 모두에서 실행 중 발생하는 사항에 대한 가시성이 필요하다. 전통적인 관찰 가능성은 로그, 지표, 트레이스를 통해 애플리케이션의 가시성을 확보한다. 그러나 에이전트형 시스템은 모델 상호작용, 도구 호출, 검색, 에이전트 간 상호작용, 에이전트가 작업 수행 시 따르는 실행 경로 등 새로운 유형의 상호작용과 실행 패턴을 도입하므로, 새롭게 이해해야 한다.
분산 트레이싱 같은 기존 관찰 가능성 기반 기술은 에이전트형 시스템에도 여전히 높은 관련성을 갖는다. 문제는 트레이싱 자체가 아니라, 개별 에이전트의 특화된 동작을 설명하는 공통 시맨틱 체계가 없다는 점이다. 전통적인 트레이싱은 서비스, 요청, 데이터베이스 호출 및 기타 애플리케이션 작업을 묘사하는 데 적합하지만, 모델 상호작용, 도구 호출, 에이전트 핸드오프, 에이전트 실행 경로 같은 개념은 추가적인 시맨틱이 필요하다.
공통 시맨틱이 없으면 서로 다른 에이전트 프레임워크가 동일한 작업을 다르게 표현한다. 예를 들어, 도구 호출 방식을 포착하는 방법이 프레임워크마다 달라 이기종 환경에서 에이전트 동작을 일관되게 이해하기 어렵다.
오픈텔레메트리(OpenTelemetry) 같은 표준이 에이전트 특화 상호작용을 위한 공통 시맨틱 컨벤션을 개발하면서 격차가 좁혀지고 있다. 이 컨벤션은 관찰 가능성 도구가 프레임워크 전반에서 에이전트 동작을 수집·분석·시각화하는 일관된 기반을 제공한다.
에이전트 경계 적용
관찰 가능성을 통해 에이전트의 활동을 파악할 수 있지만, 가시성만으로는 충분하지 않다. 설계 단계에서 설정한 경계도 런타임에 적용해야 한다.
에이전트가 모델 컨텍스트 프로토콜(MCP, Model Context Protocol) 서버를 통해 제공되는 도구 등 다양한 도구를 통해 기업 시스템을 사용할 때, 어떤 에이전트가 요청을 하는지, 그 에이전트가 수행할 수 있는 작업은 무엇인지 파악해야 한다. 에이전트 신원 및 역할 관리의 필요성이 여기에서 비롯된다.
접근 제어 정책은 설계 단계에서 설정한 경계를 에이전트가 호출할 수 있는 도구와 작업을 지정하는 권한으로 전환할 수 있다. 이 정책은 에이전트와 에이전트가 접근하는 도구 사이의 제어 지점에서 적용할 수 있다.
호텔 예약 에이전트는 가용 객실 검색과 예약을 수행하도록 설계되지만, 객실 가격 변경이나 환불은 처리할 수 없다. 런타임에서는 관련 검색 및 예약 기능을 허용하는 동시에 가격 변경이나 환불 요청을 차단함으로써 이 제한을 적용한다.
설계 단계에서 설정한 경계가 에이전트 운영 중에도 유지된다.
에이전트와 대규모 언어 모델 상호작용 거버넌스
에이전트 생애주기 전반에 걸쳐 에이전트가 대규모 언어 모델(LLM)과 상호작용하는 방식을 통제해야 한다. 모델 사용량과 비용을 관리하고, 필요한 안전성 및 보안 정책을 적용하는 작업이 포함된다.
에이전트형 워크플로는 에이전트가 계획을 수립하고, 도구를 사용하며, 결과를 평가하고, 반복 작업을 수행하는 과정에서 여러 차례 모델을 호출할 수 있다. 모델과 토큰 사용량을 추적하고, 예산을 설정하며, 사용량을 허용 범위 내로 유지하기 위한 한도를 적용해야 한다.
안전성과 보안도 다뤄야 한다. 모델 입력과 출력에 가드레일을 적용해 개인 식별 정보 노출, 유해 콘텐츠, 프롬프트 인젝션, 기타 정책 위반 등의 문제를 감지하거나 방지할 수 있다. 또한 에이전트가 접근할 수 있는 모델과 접근 조건을 정의할 수도 있다.
이런 메커니즘은 에이전트와 대규모 언어 모델의 상호작용을 기업이 설정한 보안·안전성·비용·운영 한도 내에 유지한다.
기업 전반으로의 ADLC 확장
에이전트 도입이 확대될수록 ADLC 역량을 일관되게 적용하기가 점점 어려워진다. 팀마다 다양한 프레임워크, 모델, 도구, 환경을 사용해 에이전트를 개발·운영할 가능성이 높다. 에이전트와 팀의 수가 증가할수록 일관성 유지는 더욱 어려워진다.
평가, 관찰 가능성, 신원 및 접근 관리, 가드레일, 예산, 런타임 정책을 서로 다른 도구와 방식으로 처리할 경우, 단편화와 중복 작업이 발생할 수 있다. 공통 정책 적용, 일관된 제어 유지, 기업 전체의 통합적인 에이전트 현황 파악이 어려워진다.
에이전트 제어 플레인의 가치가 바로 여기에 있다. 에이전트 제어 플레인은 전체 에이전트 포트폴리오에 걸쳐 이런 역량을 일관되게 적용·관리하는 표준 레이어를 제공하면서, 각 팀이 사용례에 가장 적합한 프레임워크·모델·도구를 활용해 에이전트를 개발할 수 있도록 지원한다.
에이전트 제어 플레인을 통한 ADLC 운영화
에이전트 제어 플레인은 에이전트 생애주기 전반에 걸쳐 ADLC 역량을 일관되게 적용·관리하는 공통 방식을 제공한다.
기업은 각 에이전트를 목적, 담당자, 버전, 도구, 의존성과 함께 등록해 에이전트 포트폴리오 전반의 가시성을 확보할 수 있다. 또한 평가 요구사항을 CI/CD 파이프라인에 통합하고, 에이전트를 환경 간에 승격하기 전에 품질·안전성·도메인별 임계값을 게이트로 활용할 수 있다.
런타임에서는 신원 및 접근 정책을 통해 에이전트가 접근할 수 있는 도구와 기업 시스템을 제어할 수 있다. 가드레일, 예산, 사용량 한도는 대규모 언어 모델과의 상호작용을 통제한다. 트레이스와 지표는 에이전트 동작에 대한 통찰을 제공하며, 온라인 평가를 통해 에이전트가 기대되는 품질·안전성 기준을 지속적으로 충족하는지 평가한다.
이런 역량은 개발 팀이 특정 에이전트 프레임워크, 모델, 환경으로 표준화하도록 강요하지 않으면서 에이전트를 일관되게 관리하는 방법을 제공한다.
생애주기는 에이전트가 운영 환경에 도달했다고 해서 끝나지 않는다. 런타임 동작은 팀이 다음 버전의 에이전트를 개선하는 데 활용할 수 있는 정보를 제공한다.
에이전트의 동작이 변하거나 기대 임계값 이하로 떨어지면, 팀은 트레이스와 평가 결과를 활용해 원인을 파악할 수 있다. 이후 에이전트를 개선하고, 정책이나 권한을 조정하며, 평가를 업데이트하고, 새 버전을 배포할 수 있다.
정의·설계·평가·배포·관찰·거버넌스를 반복하는 지속적인 생애주기가 형성되며, 운영 중 얻은 학습 내용이 다음 반복 주기에 반영된다.
에이전트 제어 플레인은 기업 전반에서 에이전트 도입이 확대됨에 따라 ADLC 역량을 일관되게 적용하는 데 필요한 공통 기반을 제공한다.
빠르게 기반을 구축하라
공통 기반을 조기에 구축하면 필요한 보안 제어와 가시성을 갖춘 상태에서 설계·개발부터 운영까지 에이전트 생애주기 전반에 걸쳐 일관된 관리가 가능하다. 이 기반은 나중에 소급 적용하는 것보다 초기에 구축하는 것이 훨씬 수월하다.
에이전트 도입이 확대될수록 일관된 제어를 유지하기 어려워진다. 특히 에이전트가 정의된 경계 내에서 운영되면서 더 많은 모델, 도구, 기업 시스템에 접근하게 될수록 그 어려움이 커진다.
