에이전트 개발 생애주기(The Agent Development Lifecycle)

https://www.langchain.com/blog/the-agent-development-lifecycle

에이전트를 출시하고자 하는 팀은 많습니다.

가장 성숙한 조직들은 이것을 반복 가능하고, 안전하며, 체계적인 방식으로 해내는 법을 이미 익혔습니다. 이들은 초기 버전을 빠르게 출시하고, 실제 사용 사례로부터 학습하며, 짧은 주기로 계속 개선합니다. 에이전트를 일회성 데모나 고립된 프로젝트로 다루지 않습니다.

대신, 이들은 실험을 “출시–학습–개선”이라는 반복 가능한 시스템으로 바꿔 주는 **에이전트 개발 생애주기(agent development lifecycle)**를 구축해, 시간에 따라 모멘텀을 만들어 냅니다.

이 생애주기는 네 단계로 구성됩니다.

Build → Test → Deploy → Monitor

이 순서는 의도적으로 설계되었습니다. 테스트는 에이전트가 프로덕션에 올라간 이후가 아니라, 그 이전부터 시작되어야 합니다. 팀은 배포 전에 에이전트를 테스트하고, 통제된 방식으로 배포하며, 프로덕션 환경에서 어떻게 동작하는지 모니터링하고, 그로부터 얻은 인사이트를 다음 빌드와 평가 사이클에 다시 반영해야 합니다.

에이전트가 하나일 때는 이 과정이 비교적 가볍게 유지될 수 있습니다. 하지만 에이전트가 많아지면, 이는 곧 인프라와 거버넌스 과제가 됩니다. 팀은 비용을 통제하고, 도구 접근을 관리하며, 도구 호출을 들여다보고, 컨텍스트를 재사용하며, 어디에 사람 개입이 꼭 필요할지 정할 수 있는 공유된 방식이 필요합니다.

에이전트를 한 번 “어떻게든 돌아가게” 만드는 것과, 에이전트를 “반복 가능한 실천(practice)”으로 구축하는 것의 차이는, 바로 이런 올바른 개발 생애주기를 갖추었는지 여부에서 나옵니다.

Build

빌드 단계는 팀이 “어떤 종류의 에이전트 시스템을 만들 것인지”와 “어떤 추상화 레벨을 사용할 것인지”를 결정하는 단계입니다.

여기에는 매우 폭넓은 툴링 스펙트럼이 존재합니다. 어떤 도구는 코드 중심(code‑first)이고, 어떤 도구는 노코드 혹은 로우코드에 가깝습니다. 어떤 것들은 추상화에 초점을 맞추고, 다른 것들은 프롬프트, 도구, 스킬, 상태를 갖춘 “작동 가능한 환경”을 에이전트에게 제공하는 데 초점을 둡니다.

코드 중심 측면에서는, 팀이 오픈소스 프레임워크와 하니스(harness)에 자주 의존합니다. LangChain 생태계에서는 LangChain, LangGraph, Deep Agents 등이 여기에 해당합니다. LangChain 외부에는 CrewAI, Claude Agents SDK 같은 예시들이 있습니다.

이러한 도구들은 스택 내 서로 다른 레이어에서 동작합니다.

**에이전트 프레임워크(agent frameworks)**는 주로 추상화에 초점을 둡니다. 모델 호출, 도구, 프롬프트, 검색(retrieval), 구조화된 출력, 에이전트 루프를 개발자가 조합(composition)할 수 있도록 돕습니다. LangChain과 CrewAI가 이런 유형의 예시입니다.

**에이전트 런타임(agent runtimes)**은 실행(execution)에 집중합니다. 상태, 제어 흐름, 내구성(durability), 인간 개입이 필요한 에이전트를 지원합니다. LangChain 생태계에서는 LangGraph가 가장 명확한 예입니다. LangGraph는 분기, 루프, 일시 정지, 재개, 장기 상태 유지가 가능한 에이전트 시스템을 구축할 수 있는 방식을 제공합니다.

**에이전트 하니스(agent harnesses)**는 “실행” 자체에 초점을 둡니다. 프롬프트, 스킬, MCP 서버, 훅(hooks), 미들웨어, 때로는 파일 시스템까지, 장기 실행 작업에 에이전트가 필요로 하는 주변 구조를 제공합니다. Deep Agents와 Claude Agent SDK가 이러한 패턴의 대표적인 예입니다.

이 구분이 중요한 이유는, “에이전트를 만든다”는 말이 상황에 따라 전혀 다른 의미가 될 수 있기 때문입니다.

간단한 애플리케이션 수준에서는, 단순히 도구 호출 루프(tool‑calling loop)를 정의하는 정도일 수 있습니다. 반대로 고도화된 에이전트라면, 프롬프트를 작성하고, 스킬을 정의하고, MCP 서버를 연결하고, 미들웨어를 구성하고, 에이전트가 시간 경과에 따라 조회하거나 갱신할 수 있는 컨텍스트까지 세팅해야 할 수도 있습니다.

노코드 빌드

빌드 단계에는 노코드·로우코드 영역도 존재합니다. LangSmith Fleet, Claude Cowork, n8n 같은 도구들은 더 많은 사람들이 에이전트 개발에 참여할 수 있게 합니다. 워크플로우를 가장 잘 이해하고 있는 사람이 항상 코드를 작성하는 사람은 아니기 때문에, 이런 점은 중요합니다.

동시에, 노코드 도구가 엔지니어링 수준의 통제 필요성을 없애 주지는 않습니다. 시스템이 복잡해질수록, 팀은 결국 코드로 동작을 확장하거나 오버라이드할 수 있는 수단이 필요해집니다. 특히 훅과 미들웨어는 중요합니다. 이들은 모든 에이전트를 처음부터 다시 만들지 않고도, 도구 호출, 컨텍스트 처리, 승인 절차, 인증, 비즈니스 규칙 주변에 커스텀 로직을 추가할 수 있게 해 주기 때문입니다.

가장 좋은 빌드 환경은 “쉬운 것은 쉽게, 복잡한 것은 가능하게” 만들어 줍니다. 도메인 전문가가 프롬프트, 스킬, 컨텍스트를 직접 편집할 수 있도록 하되, 동시에 신뢰성, 테스트 가능성, 거버넌스가 요구되는 부분에 대해서는 엔지니어가 충분한 통제권을 갖도록 해 줍니다.

Test

에이전트를 배포하기 전에, 팀은 “이 에이전트가 실제로 준비가 되었는지” 판단할 수 있어야 합니다.

그렇다고 해서, 누구도 사용하기 전에 완벽한 평가(evals) 스위트를 다 갖춰야 한다는 뜻은 아닙니다. 실제로 그런 일은 거의 불가능에 가깝습니다. 다만, 명백한 실패를 잡아내고, 버전을 비교하며, 아무 근거 없이 변경 사항을 배포하지 않게 해 줄 만큼의 평가 체계는 필요하다는 뜻입니다.

대부분의 평가 워크플로우는 소규모이지만 대표성을 갖춘 태스크 데이터셋에서 시작합니다. 일부 예시는 예상 사용 사례에서 가져오고, 일부는 수동 테스트, 도그푸딩(dogfooding), 지원 티켓, 과거 트레이스, 이미 알려진 엣지 케이스에서 나옵니다. 시간이 지나면 프로덕션 트레이스가 이 데이터셋을 훨씬 더 강력하게 만들어 주지만, 테스트는 반드시 프로덕션 이전부터 시작되어야 합니다.

데이터셋과 지표

데이터셋은 팀이 학습한 내용을 “보존”하는 수단입니다. 데이터셋이 없으면, 프롬프트 변경, 모델 업그레이드, 도구 업데이트가 일어날 때마다 과거에 해결했던 동일한 실패가 반복해서 재등장하는 경향이 있습니다.

올바른 지표(metrics)는 태스크의 성격에 따라 달라집니다.

어떤 경우에는 명확한 정답(ground truth)이 존재합니다. 에이전트가 올바른 값을 추출했는지, 올바른 레이블을 선택했는지, 올바른 필드를 업데이트했는지와 같이, 이런 태스크는 정답 여부를 직접 측정할 수 있습니다.

반면 단일한 정답이 존재하지 않는 경우도 많습니다. 에이전트가 응답을 작성하거나, 대화를 요약하거나, 에스컬레이션 여부를 결정하거나, 여러 경로가 모두 유효한 복합 태스크를 수행해야 할 수도 있습니다. 이런 경우에는, 팀이 기준 기반 평가(criteria‑based evaluation)에 더 많이 의존하게 됩니다. 질문은 “답변이 근거에 기반했는가?”, “정책을 준수했는가?”, “필요할 때 추가 질문을 했는가?”, “불필요한 도구 호출 없이 효율적으로 태스크를 끝냈는가?”로 바뀝니다.

실험(Experiments)

실험은 데이터셋과 지표를 “반복(iteration)”과 연결해 주는 장치입니다. 실험을 통해 팀은 동일한 평가 세트를 기준으로 프롬프트, 모델, 검색 전략, 도구 스키마, 오케스트레이션 패턴을 서로 비교할 수 있습니다. 시간이 지나면, 이 실험들의 누적 결과가 에이전트가 개선되고 있는지, 아니면 퇴보(regress)하고 있는지를 보여줍니다.

목표는 1일 차부터 완벽한 평가 스위트를 만드는 것이 아닙니다. 처음에는 “쓸 만한” 것을 가지고 시작하고, 그것을 지속적으로 개선해 나가는 것이 목표입니다. 가장 가치 있는 평가 데이터셋은 대개 “가장 어려운 예시들”로 구성됩니다. 처음에는 개발과 도그푸딩 단계에서, 이후에는 프로덕션 환경에서 이런 예시들이 축적됩니다.

시뮬레이션(Simulations)

시뮬레이션 역시 테스트에서 중요한 부분을 차지합니다.

많은 에이전트는 멀티 턴 시스템입니다. 한 번 질문에 답하고 끝나는 것이 아니라, 대화를 이어가며 정보를 수집하고, 도구를 호출하고, 상태를 갱신하며, 모호함을 해소해 나갑니다. 이런 에이전트에게 싱글 턴 평가만으로는 충분하지 않습니다. 팀은 멀티 턴 평가와, 끝까지 시나리오를 돌려 보는 엔드 투 엔드 상호작용 시뮬레이션이 필요합니다.

보이스 에이전트는 대표적인 예이지만, 이 패턴은 훨씬 더 넓게 적용됩니다. 여러 턴에 걸쳐 작동하는 모든 에이전트가 시뮬레이션 대상이 될 수 있습니다. 예를 들어, 고객 지원 에이전트는 화가 난 고객을 응대하고, 후속 질문을 던지며, 주문 상태를 조회하고, 에스컬레이션 필요 여부를 결정해야 할 수 있습니다. 코딩 에이전트는 리포지토리를 살펴보고, 변경을 적용하고, 테스트를 실행하고, 피드백에 응답해야 할 수 있습니다. 내부 운영 에이전트는 행동을 취하기 전에 누락된 정보를 먼저 수집해야 할 수도 있습니다.

좋은 테스트 관행은 팀이 “감(感)”에 의존하지 않고 에이전트를 체계적으로 개선할 수 있게 합니다. 기대하는 행동을 데이터셋으로 만들고, 데이터셋을 실험으로 연결하며, 실험을 통해 더 나은 시스템 버전으로 이어지게 합니다. 배포 이후에는 모니터링이 실제 예시를 제공해, 이 평가들을 더욱 강력하게 만들어 줍니다.

Deploy

에이전트가 빌드되고 평가를 통과하면, 이제 그것이 안정적으로 실행될 환경이 필요합니다.

단순한 에이전트의 경우, 배포 방식이 전통적인 애플리케이션 배포와 크게 다르지 않을 수 있습니다. 하지만 많은 에이전트는 단순한 무상태(stateless) 서버 이상을 필요로 합니다. 이들은 더 긴 시간 동안 실행되기도 하고, 도구를 호출하고, 사람의 입력을 기다리고, 파일을 작성하고, 중단으로부터 복구하며, 여러 상호작용이나 태스크에 걸쳐 상태를 유지하기도 합니다.

그래서 **런타임(runtime)**이 중요해집니다.

프로덕션 등급 에이전트 런타임은 일반적으로 **내구성 있는 실행(durable execution)**과 휴먼 인 더 루프(human‑in‑the‑loop) 패턴을 지원해야 합니다. 내구성 있는 실행이란, 에이전트가 진행 상황을 체크포인트로 남겨 두었다가, 무언가 실패했을 때 작업을 잃어버리지 않고 다시 이어서 실행할 수 있다는 뜻입니다. 휴먼 인 더 루프란, 에이전트가 승인, 추가 설명, 검토가 필요할 때 실행을 일시 정지했다가, 사람의 개입 이후에 다시 진행할 수 있다는 뜻입니다.

이를 위한 기성(off‑the‑shelf) 솔루션도 있습니다. LangSmith Deployment는 Deep Agents와 LangGraph 에이전트를 배포·관리하기 위한 인프라를 제공합니다. AWS AgentCore 역시 에이전트를 위한 매니지드 런타임의 또 다른 예시입니다. 일부 팀은 이미 스택의 다른 곳에서 장기 실행 워크플로우를 위해 Temporal을 사용하고 있는 경우, 그 위에 자체 런타임을 구축하기도 합니다.

샌드박스(Sandboxes)

많은 에이전트는 전용 실행 환경(dedicated execution environments)도 필요로 합니다.

에이전트가 코드를 작성·실행하고, 파일을 검사하며, 문서를 변환하거나, 파일 시스템과 상호작용해야 하는 경우가 점점 늘고 있습니다. 이때 “어디에서” 그 작업이 이뤄질지를 팀이 결정해야 합니다. 샌드박스는 이런 요구에 대한 흔한 해법입니다. 샌드박스는 파일 시스템 접근이 가능한 격리된 실행 환경을 제공하면서, 실수나 안전하지 않은 동작이 발생했을 때 피해 범위(blast radius)를 줄여 줍니다.

예시로는 LangSmith Sandboxes, Daytona, E2B 등이 있습니다.

모든 에이전트가 풀 샌드박스를 필요로 하는 것은 아닙니다. 어떤 경우 에이전트는 단지 파일을 저장하고 불러올 수 있는 장소만 있으면 됩니다. 이런 상황에서는 가상 파일 시스템(virtual filesystem)만으로 충분할 때도 있습니다. Deep Agents는 에이전트가 샌드박스 안에서 임의 코드를 실행하지 않고도, 파일을 작업 메모리(work space)처럼 사용할 수 있는 패턴을 지원합니다. 내부적으로는 이러한 파일 시스템이 Postgres나 S3 같은 시스템 위에 구현될 수 있습니다.

Context Hub

배포 단계에서 종종 간과되는 부분이 프롬프트와 컨텍스트 관리입니다.

에이전트의 가장 중요한 구성 요소 중 일부는 전통적인 의미의 애플리케이션 코드가 아닐 수 있습니다. 프롬프트, 검색 컨텍스트, 스킬, 태스크 지침은 애플리케이션 코드보다 훨씬 자주 바뀌어야 할 수도 있고, 엔지니어가 아닌 사람이 편집해야 할 수도 있습니다.

이는 곧 “프롬프트/컨텍스트 허브(prompt or context hub)”의 필요로 이어집니다. 에이전트의 비(非)코드 부분을 저장하고, 버전을 관리하며, 리뷰하고, 업데이트할 수 있는 장소 말입니다. 이를 통해 팀은 전체 애플리케이션을 재배포하지 않고도 에이전트의 동작을 조정할 수 있고, 도메인 전문가가 자신이 가장 잘 이해하는 컨텍스트를 직접 책임질 수 있습니다.

실제로 배포는 “에이전트를 서버에 올리는 것”으로 끝나지 않습니다. 에이전트가 실제 업무를 수행하는 데 필요한 런타임, 실행 환경, 컨텍스트 관리 시스템을 갖춰 주는 전체 과정이 바로 배포입니다.

Monitor

에이전트가 배포되고 나면, 팀은 이들이 프로덕션에서 실제로 어떻게 동작하는지에 대한 가시성을 확보해야 합니다.

이 지점에서 에이전트 모니터링은 기존 소프트웨어 모니터링과 달라집니다. 지연 시간(latency), 비용(cost), 에러율, 업타임 같은 지표는 여전히 중요하지만, 그 자체로는 그림의 일부일 뿐입니다. 에이전트는 형식적으로는 “성공적인 응답”을 반환했더라도, 실제 태스크 관점에서는 실패할 수 있습니다. 잘못된 도구를 호출했거나, 잘못된 컨텍스트에 의존했거나, 필수 승인 단계를 건너뛰었거나, 겉보기에 그럴듯하지만 사실은 틀린 답을 냈을 수도 있습니다.

이러한 실패를 이해하려면, 팀에는 **트레이스(traces)**가 필요합니다.

트레이스는 에이전트의 전체 궤적(trajectory)을 포착합니다. 에이전트가 입력으로 무엇을 받았는지, 어떤 모델 호출을 했는지, 어떤 도구를 호출했는지, 각 호출에서 어떤 출력을 받았는지, 그리고 최종적으로 어떤 응답이나 행동을 산출했는지를 모두 담습니다. 에이전트가 실제로 무엇을 했는지를 이해하려면 이 정도 수준의 세부 정보가 필요합니다.

이 때문에 우리는 “에이전트 관측성(agent observability)이 에이전트 평가의 동력이다”라고 주장해 왔고, “에이전트 개선 루프는 트레이스에서 시작된다”고 말해 왔습니다. 궤적을 볼 수 없다면, 에이전트의 행동을 신뢰성 있게 디버그하거나, 그 실패를 미래의 평가 자료로 전환하기가 어렵습니다.

시그널(Signals)

모니터링에는 트레이스로부터 시그널을 수확하는 작업도 포함되어야 합니다.

이 시그널 중 일부는 LLM‑as‑judge 평가자에서 나올 수 있습니다. 예를 들어, 평가자는 에이전트가 사용자의 질문에 제대로 답했는지, 정책을 준수했는지, 올바른 톤을 사용했는지, 태스크를 완수했는지 등을 점수화할 수 있습니다. 다른 시그널은 더 단순할 수 있습니다. 예를 들어, 정규식(regex)만으로도 필수 문구가 포함되었는지, 금지된 도구가 호출되었는지, 이미 알려진 실패 패턴이 발생했는지를 감지할 수 있습니다.

이러한 시그널은 단지 품질 검증에만 유용한 것이 아닙니다. 이들은 **제품 분석(product analytics)**의 한 형태가 될 수도 있습니다. 사용자가 에이전트에게 어떤 태스크를 요청하는지, 에이전트가 어디에서 막히는지, 사용자가 얼마나 자주 에이전트를 수정하는지, 사용자가 어디서 오류를 인지하는지 등을 알려줄 수 있기 때문입니다.

피드백(Feedback)

피드백 역시 모니터링의 핵심 구성 요소입니다.

트레이스를 저장하는 것만으로는 충분하지 않습니다. 팀은 그 트레이스에 “피드백”도 함께 저장해야 합니다. 이 피드백은 LLM 평가자, 정규식 기반 시그널, 휴먼 리뷰어, 혹은 API를 통해 수집된 사용자 직접 피드백 등 다양한 곳에서 올 수 있습니다. 예를 들어 LangSmith에서는, 팀이 사용자의 피드백을 해당 실행(run)에 직접 연결할 수 있어, “사용자가 불만족했다”는 정보와 “세 번째 단계에서 에이전트가 잘못된 도구를 사용했다”는 정보를 쉽게 이어볼 수 있습니다.

대시보드(Dashboards)

마지막으로, 팀은 시간에 따른 추세를 표면화할 수 있는 대시보드와 알림(alert)이 필요합니다.

유용한 에이전트 대시보드는 사용량, 피드백, 지연 시간, 비용, 도구 호출, 평가 점수, 반복되는 실패 패턴 같은 지표를 추적합니다. 알림은 지연 시간 증가, 비용 급증, 도구 실패, 사용자 피드백 악화, 정책 위반 급증처럼 중요한 임계치를 넘길 때 트리거되어야 합니다.

좋은 모니터링은 “시스템이 살아 있는지”를 아는 것에서 그치지 않습니다. 에이전트가 올바른 방식으로, 올바른 일을 하고 있는지, 그리고 시간이 지날수록 더 나아지고 있는지를 이해하는 데 목적이 있습니다.

가장 강력한 모니터링 시스템은 이 정보들을 바로 평가 단계로 다시 흘려보냅니다. 중요한 트레이스는 데이터셋 예시가 되고, 반복되는 실패는 지표가 되며, 프로덕션에서의 실제 동작은 다음 개선 라운드의 기반이 됩니다.

Iterate

가장 뛰어난 조직은 이 에이전트 개발 생애주기를 빠르고 체계적으로 순환합니다.

이들은 “완벽한 에이전트”가 준비될 때까지 출시를 미루지 않습니다. 대신, 당장 유용한 것을 먼저 만들고, 그 행동을 이해할 수 있을 만큼 충분히 테스트한 뒤, 통제된 방식으로 배포하고, 프로덕션에서 어떻게 성과를 내는지 모니터링하며, 거기서 얻은 학습을 다음 버전에 꾸준히 반영합니다.

이는 결코 무책임하게(ship carelessly) 배포한다는 뜻이 아닙니다. 중요한 것은 **가시성(visibility)**입니다.

데이터셋, 실험, 트레이스, 피드백, 대시보드를 갖춘 팀은 실제 사용 사례로부터 직접 학습할 수 있습니다. 이들은 변경 사항을 전체에 롤아웃하기 전에 먼저 시험해 보고, 프로덕션에서 무엇이 깨졌는지 파악하고, 실패를 평가 자료로 전환하며, 추측에 의존하지 않고 에이전트를 개선해 나갈 수 있습니다.

이렇게 조직은 **힐 클라임(hill‑climb)**을 수행하고, 에이전트 시스템은 시간에 따라 점진적으로 나아집니다.

가장 효과적인 팀은 어려운 예시를 찾아내고, 에이전트가 왜 실패했는지 이해한 뒤, 프롬프트, 도구 설정, 검색 전략, 모델, 미들웨어, 워크플로우를 조정합니다. 그런 다음 평가를 다시 실행하고, 더 나아진 버전을 배포하며, 모니터링을 통해 다시 새로운 엣지 케이스와 실패 사례를 수집합니다.

엔터프라이즈 환경에서의 과제는, 이 루프를 여러 팀에 걸쳐 반복 가능한 형태로 만들기입니다.

각 팀이 평가 프레임워크, 배포 인프라, 트레이싱 시스템, 피드백 파이프라인, 대시보드를 매번 처음부터 따로 구축해야 한다면, 에이전트 개발 속도는 필연적으로 느려집니다. 가장 효과적인 조직은 이러한 공통 인프라에 투자해, 팀들이 기반 시스템을 계속 재발명하지 않고도 생애주기를 빠르게 순환할 수 있도록 합니다.

이 지점에서 에이전트 개발 생애주기는 하나의 “운영적 실천(operational practice)”이 됩니다.

거버넌스

거버넌스는 에이전트 개발 생애주기의 전체를 감싸고 있는 층입니다.

에이전트가 하나뿐일 때는 가벼운 통제 장치만으로도 충분할 수 있습니다. 하지만 조직이 더 많은 에이전트를 배포할수록, 거버넌스는 필수 요소가 됩니다. 그 없이 진행하면, 금세 다음과 같은 문제를 맞닥뜨리게 됩니다. 에이전트는 발견하기 어렵고, 모니터링하기 힘들며, 비용은 많이 들고, 이들이 “무엇을 할 수 있는지”도 불분명해집니다.

비용(Cost)

가장 먼저 마주치는 거버넌스 과제는 비용입니다.

에이전트는 여러 번의 모델 호출, 긴 컨텍스트 윈도우, 반복되는 도구 사용, 재시도(retries), 장기 실행 시간 등으로 인해 쉽게 고비용 구조가 될 수 있습니다. 조직은 예산, 사용량 모니터링, 알림, 그리고 어떤 에이전트·팀·모델·도구가 비용을 끌어올리고 있는지에 대한 가시성을 통해, 이러한 지출을 추적하고 관리할 수 있어야 합니다.

도구 접근(Tool Access)

두 번째 거버넌스 과제는 도구 접근 권한입니다.

에이전트가 유용한 이유는 실제 “행동”을 취할 수 있기 때문입니다. 하지만 이는 동시에 리스크를 동반합니다. 팀은 어떤 도구를, 어떤 조건에서, 어떤 사용자를 대신해서 에이전트가 사용할 수 있는지에 대해 명확한 통제가 필요합니다.

이 지점에서 **감사 로그(audit trail)**가 중요해집니다. 에이전트가 도구를 호출했다면, 조직은 “어떤 에이전트가 그 호출을 했는지”, “어떤 입력을 사용했는지”, “어떤 출력을 받았는지”, “어떤 사용자나 정책이 그 행동을 허가했는지”를 추적할 수 있어야 합니다. 도구 호출은 에이전트의 행동이 실제 비즈니스 임팩트를 만들어 내는 지점인 경우가 많기 때문에, 이들은 관측 가능하고 검토 가능한 상태여야 합니다.

휴먼 인 더 루프는 또 다른 중요한 거버넌스 메커니즘입니다.

모든 도구 호출이 완전히 자동화되어야 할 필요는 없습니다. 특히 고객과 직접 상호작용하거나, 재무 시스템, 민감한 데이터, 프로덕션 인프라를 다루는 작업의 경우, 일부 연산은 사람의 검토를 위해 중간에 멈춰야 합니다. 휴먼 인 더 루프 워크플로우는 처음부터 시스템 설계에 녹여 넣었을 때 가장 잘 동작합니다.

발견 가능성(Discoverability)

세 번째 거버넌스 과제는 발견 가능성과 재사용성입니다.

조직이 더 많은 에이전트를 만들수록, 프롬프트, 스킬, 도구, 검색 소스, 정책, 그리고 심지어 다른 에이전트까지, 재사용 가능한 자산도 함께 쌓입니다. 좋은 발견/거버넌스 메커니즘이 없다면, 팀은 이러한 컴포넌트를 계속해서 새로 만들게 되고, 그 결과 일관성이 떨어지게 됩니다. 공유 컨텍스트와 공유 에이전트는 쉽게 찾을 수 있고, 재사용 가능하며, 적절히 관리되어야 합니다.

이는 특히 스킬(skills)에 중요합니다. 스킬은 특정 워크플로우, 글쓰기 스타일, 도메인 특화 절차, 도구 사용 지침 등을 캡슐화할 수 있습니다. 한 팀이 이미 잘 만들어진 스킬을 보유하고 있다면, 다른 팀은 새 버전을 처음부터 다시 작성하기보다, 그것을 찾을 수 있어야 합니다.

좋은 거버넌스는 팀의 속도를 늦추는 것이 목적이 아닙니다. 눈에 보이는 가시성과 통제, 일관성을 유지하면서도 빠르게 반복(iterate)할 수 있게 하는 것이 목적입니다. 에이전트 시스템이 확장될수록, 이런 거버넌스는 필수가 됩니다.

결론

가장 앞서 있는 조직들은 이미 이런 방식으로 운영을 시작했습니다. 이들은 빠르게 출시하지만, 눈을 감고 무작정 출시하지는 않습니다. 배포 전에 평가하고, 배포 후에는 행동을 모니터링하며, 거기서 얻은 학습을 계속 다음 버전에 반영합니다.

이러한 방식이 에이전트 개발을 반복 가능하게 만듭니다. 그리고 에이전트를 데모 수준에서 벗어나, 신뢰할 수 있는 프로덕션 시스템으로 옮겨 가게 해 줍니다.