Claude Managed Agents Q&A: 평가·CI/CD·멀티테넌시

URL: https://www.youtube.com/watch?v=QSeaZ6qHyXs 날짜: 2026-10-12 채널: aiDotEngineer 원문 제목: Claude Managed Agents Q&A: Evals, CI/CD and Multi-Tenancy (Part 4 of 4) — Anthropic

📌 핵심 질문 / 관리형 에이전트를 조직과 제품에 안전하게 배포하는 방법

==에이전트 정의를 코드와 YAML로 관리하고, 평가·테넌트 격리·컴퓨팅 환경·코디네이터 패턴을 함께 설계해야 Claude Managed Agents를 조직 규모의 제품으로 운영할 수 있다.==

• NCLI와 YAML을 이용해 에이전트의 장기 리소스를 CI/CD에 연결한다.
• 고객별 워크스페이스·조직·세션 메타데이터를 조합해 데이터를 격리한다.
• GPU나 대용량 메모리가 필요하면 자체 호스팅 샌드박스와 외부 컴퓨트 제공자를 연결한다.

1. 에이전트 정의와 CI/CD

1.1. NCLI와 YAML

1. 구성을 코드로 관리한다

   1. NCLI: Claude Managed Agents API를 감싼 CLI로 에이전트와 장기 리소스를 관리한다.
   2. YAML 정의: 에이전트 설정을 코드베이스에 YAML로 저장해 변경 사항을 검토하고 재현한다.

2. 배포 흐름

   1. 변경 감지: YAML을 수정하면 CI가 변경된 정의를 확인한다.
   2. 동기화: NCLI가 워크스페이스의 에이전트 설정을 업데이트한다.
   3. 조직 규모 적용: 같은 정의를 여러 워크스페이스에 반영해 복사본 간 드리프트를 줄인다.

1.2. 실행 중인 커스텀 도구와 메시지

1. 도구 실행 대기 상태

   1. 현재 실행을 유예한다: 에이전트가 커스텀 도구의 결과를 기다릴 때 실행은 잠시 중단된다.
   2. 대기열을 허용한다: 도구 결과를 처리하는 동안 도착한 메시지는 순서대로 대기시킬 수 있다.

2. 잘못된 직접 호출

   1. 400 오류: 도구 결과를 기다리는 세션에 허용되지 않은 메시지를 직접 보내면 요청이 거부된다.
   2. 코디네이터 사용: 메인 에이전트가 항상 요청을 받을 수 있어야 한다면 커스텀 도구를 서브에이전트로 분리하고 메인이 결과를 전달하게 만든다.

2. 평가와 코드 리뷰

2.1. Anthropic의 평가 방식

1. 새 모델과 도구를 빠르게 검증한다

   1. 내부 데이터셋: 실제 세션과 다양한 업무 사례에서 평가 데이터를 만든다.
   2. 대규모 실행: 클라우드 세션을 동시에 많이 시작해 변경 전후의 결과를 비교한다.
   3. 구성 갱신: 불필요한 도구를 제거하거나 새 도구를 추가하면서 모든 공개 모델에서 동작하는지 확인한다.

2. 평가의 전제

   1. 좋은 데이터가 먼저다: 입력 데이터가 부정확하면 높은 점수도 실제 품질을 의미하지 않는다.
   2. 목표를 명시한다: 생산성·정확성·도구 사용·코딩 품질처럼 무엇을 측정하는지 정의해야 한다.
   3. 과거 세션을 활용한다: 이미 축적된 세션을 재생해 실제 실패 패턴을 평가 케이스로 전환한다.

2.2. 에이전트가 작성한 코드 검토

1. 자동 PR 흐름

   1. 에이전트가 변경을 만든다: 코드 에이전트가 PR과 테스트 결과를 생성한다.
   2. 다중 세션 검토: 여러 에이전트가 변경을 실행·검증·검토해 누락과 오류를 찾는다.
   3. 사람의 승인: 운영 환경에 반영하기 전 사람이 변경의 의도와 위험을 최종 확인한다.

2. 생산량 증가에 대한 대응

   1. 검토 자동화: 에이전트가 PR마다 테스트와 코멘트를 수행해 반복 작업을 줄인다.
   2. 품질 게이트: 통과해야 하는 테스트와 정적 분석 기준을 배포 조건으로 만든다.

3. 공유 리소스와 멀티테넌시

3.1. 조직·워크스페이스·세션의 경계

1. 공유 범위

   1. 워크스페이스 연결: 에이전트·메모리 저장소·MCP 채널은 특정 워크스페이스와 연결된다.
   2. 관리자 권한: 조직 관리자가 워크스페이스를 만들고 접근 권한을 부여한다.
   3. 부분 공유: 전체 구현을 공개하지 않고 에이전트 기능이나 MCP 채널의 일부만 다른 팀에 제공할 수 있다.

2. 접근 통제

   1. 개발자와 최종 사용자 분리: 통합 담당자는 내부 구현을 관리하고 최종 사용자는 제한된 기능만 사용한다.
   2. 리소스 소유권 확인: 공유하기 전에 어떤 조직과 워크스페이스가 에이전트·메모리·채널을 소유하는지 정해야 한다.

3.2. 고객별 에이전트 운영

1. 고객별 워크스페이스

   1. 강한 격리: 데이터 분리와 법적 요구가 중요하면 고객마다 별도 조직이나 워크스페이스를 만든다.
   2. 정의 동기화: YAML로 정의한 에이전트를 NCLI와 CI로 여러 워크스페이스에 동기화한다.

2. 공유 워크스페이스와 세션 메타데이터

   1. 단일 에이전트: 고객별 복사본 대신 하나의 에이전트를 두고 세션 메타데이터에 고객 식별자를 넣을 수 있다.
   2. 구성 선택: 데이터가 섞여도 되는 경우에는 공유 워크스페이스가 운영을 단순화하지만, 고객 간 분리가 필요하면 워크스페이스를 분리해야 한다.

3. 두 고객이 하나의 에이전트를 쓰는 경우

   1. 템플릿 복사 방식: 하나의 에이전트 정의를 여러 워크스페이스에 복사해 고객별 실행 인스턴스를 만든다.
   2. 세션 라우팅 방식: 하나의 에이전트에 고객 ID를 전달하고 세션과 데이터 접근을 식별자에 따라 라우팅한다.

4. 커스텀 컴퓨트와 멀티플레이어 에이전트

4.1. GPU와 대용량 메모리

1. 자체 호스팅 샌드박스

   1. 기본 환경의 한계: 특별한 메모리나 GPU가 필요한 작업은 기본 샌드박스만으로 처리하기 어렵다.
   2. 외부 제공자 연결: Modal, E2B, Daytona 같은 외부 제공자의 인스턴스를 에이전트 작업에 연결한다.

2. 연결 방식

   1. 수동 통합: 외부 컴퓨트 인스턴스를 만들고 에이전트의 작업 주기에 맞춰 시작·종료한다.
   2. 보안 경계: 외부 환경에 어떤 파일과 자격 증명을 전달할지 명시하고, 작업이 끝나면 리소스를 회수한다.

4.2. Slack 멀티플레이어 에이전트

1. 메시지를 세션으로 매핑한다

   1. 스레드 단위 세션: Slack 채널이나 스레드를 Managed Agent 세션과 연결한다.
   2. 발신자 메타데이터: 각 메시지에 발신자 정보를 넣어 에이전트가 누구의 요청인지 구분한다.

2. 메모리와 권한

   1. 채널별 메모리: 채널 단위 에이전트에 독립 메모리를 부여하면 다른 채널의 문맥이 섞이지 않는다.
   2. 응답 권한: 에이전트가 스스로 메시지를 게시할 수 있는 조건과 사람의 승인이 필요한 조건을 분리한다.

5. 장기 실행 세션과 코디네이터 패턴

5.1. 장기 실행의 관찰 가능성

1. 기준 기반 지속 실행

   1. 완료 기준: 장기 작업은 “몇 시간 실행”이 아니라 원하는 결과와 평가 기준을 달성할 때까지 계속하게 한다.
   2. 유한한 사양: 과업·중간 상태·종료 기준을 명시해 에이전트가 불필요하게 반복하지 않게 한다.

2. 세션 이벤트와 상태 업데이트

   1. 이벤트 스트림: 외부 UI는 세션 이벤트 API를 구독해 작업 진행을 표시한다.
   2. 상태 도구: 에이전트가 일정 간격으로 상태를 업데이트하면 몇 시간짜리 작업도 통제 지점을 제공한다.

5.2. 코디네이터와 서브에이전트

1. 메인 에이전트를 항상 응답 가능하게 만든다

   1. 코디네이터: 메인 에이전트는 요청을 받고 작업을 분해하며 서브에이전트에 도구 호출을 위임한다.
   2. 서브에이전트: 별도 세션 스트림에서 커스텀 도구를 실행하고 결과를 메인 에이전트에 반환한다.

2. 세션 관계

   1. 독립 스트림: 서브에이전트는 메인 스트림과 분리된 실행 흐름을 갖지만 전체 작업의 하위 세션으로 추적된다.
   2. 메인 스트림의 가용성: 메인이 도구 결과를 기다리며 막히지 않아야 새로운 사용자 요청을 계속 수신할 수 있다.

주요 데이터 & 수치

• 전체 구성: Claude Managed Agents 워크숍 4부 중 마지막 Q&A 세션이다.
• 실행 규모: 내부 평가에서는 한 번에 수천~10,000개 세션을 시작해 결과를 비교하는 방식이 언급된다.
• 지원 환경: 기본 샌드박스 외에 Modal·E2B·Daytona와 같은 외부 컴퓨트 제공자를 연결할 수 있다.
• 장기 실행 예시: 기준을 만족할 때까지 수 시간 동안 계속 일하는 에이전트가 설계 대상이다.

주요 발언 모음

“YAML로 에이전트 정의를 관리하면 코드베이스와 CI/CD에서 같은 구성을 반복적으로 배포할 수 있다.”

“고객 데이터가 분리되어야 한다면 고객별 워크스페이스나 조직을 만들고 리소스와 세션의 경계를 명시해야 한다.”

결론 및 시사점

1. 에이전트 정의를 YAML과 CLI로 관리하면 모델 프롬프트가 아니라 배포 가능한 소프트웨어 구성으로 취급할 수 있다.
2. 평가에는 고품질 데이터와 명확한 목표, 과거 세션에서 추출한 실패 사례가 필요하다.
3. 멀티테넌시 설계는 고객별 워크스페이스, 공유 워크스페이스와 세션 메타데이터 사이의 격리 요구를 기준으로 선택해야 한다.
4. GPU와 대용량 메모리가 필요한 작업은 자체 호스팅 샌드박스와 외부 컴퓨트 공급자를 연결해 해결한다.
5. 커스텀 도구를 서브에이전트로 이동하면 메인 코디네이터가 장시간 대기하지 않고 계속 사용자 요청을 받을 수 있다.

핵심 요약 (20줄)

Claude Managed Agents의 에이전트 정의는 YAML과 NCLI로 코드베이스와 CI/CD에 연결할 수 있다.

YAML 기반 배포는 여러 워크스페이스의 설정을 같은 소스에서 동기화하게 한다.

커스텀 도구 결과를 기다리는 세션에 직접 메시지를 보내면 400 오류가 발생할 수 있다.

도구 대기 중인 실행에는 메시지를 대기열에 넣거나 코디네이터를 두는 방식이 필요하다.

평가 품질은 모델보다 먼저 평가 데이터와 측정 목표를 얼마나 정확히 정의했는지에 좌우된다.

실제 세션 기록을 평가 데이터로 전환하면 현업에서 반복되는 실패를 재현할 수 있다.

클라우드 세션을 대규모로 동시에 실행하면 에이전트 구성 변경 전후의 결과를 비교할 수 있다.

에이전트가 작성한 코드는 자동 테스트와 다중 에이전트 검토를 거친 뒤 사람이 최종 승인해야 한다.

조직·워크스페이스·세션 메타데이터는 공유 리소스의 권한과 데이터 경계를 정의하는 핵심 단위다.

고객 데이터의 강한 격리가 필요하면 고객별 조직이나 워크스페이스를 분리해야 한다.

공통 에이전트 정의는 YAML 템플릿을 여러 워크스페이스에 동기화해 재사용할 수 있다.

공유 워크스페이스를 사용할 때는 세션 메타데이터에 고객 식별자를 넣어 요청과 데이터를 라우팅해야 한다.

GPU와 대용량 메모리가 필요하면 자체 호스팅 샌드박스와 Modal·E2B·Daytona를 연결할 수 있다.

Slack 멀티플레이어 에이전트는 채널이나 스레드를 세션에 매핑해 여러 사용자의 요청을 처리한다.

채널별 독립 메모리와 제한된 접근 권한은 서로 다른 대화의 문맥이 섞이는 문제를 줄인다.

장기 실행 에이전트는 실행 시간보다 완료 기준과 중간 상태 업데이트를 중심으로 설계해야 한다.

세션 이벤트 API는 몇 시간 동안 실행되는 작업의 진행 상황을 외부 UI에 전달한다.

코디네이터 패턴은 메인 에이전트가 사용자 요청을 계속 받으면서 서브에이전트에 커스텀 도구를 위임하게 한다.

서브에이전트는 별도 스트림에서 실행되지만 메인 작업의 하위 세션으로 추적된다.

관리형 에이전트의 제품화에는 구성 관리·평가·격리·컴퓨트·관찰 가능성을 한 시스템으로 묶는 설계가 필요하다.