How I hardened my multi-agent AI support copilot

개요

기술 블로그 시리즈의 두 번째 게시물은 여러 에이전트 AI 지원 코파일럿에 대한 실제 티켓이 발생했을 때 드러난 약점과 이를 보완하기 위한 과정을 다룹니다.

주요 내용

* SKILL.md는 문서이고 에이전트는 실행자입니다.
* 초기에는 SKILL.md 파일을 실행 가능한 워커로 착각했으나, 실제로는 특정 에이전트가 특정 도구를 사용하여 실행하도록 하는 지침 문서임이 밝혀졌습니다.
* 이를 해결하기 위해 .claude/agents/ 디렉토리에 각 에이전트의 정의, 도구, 실행 방식 등을 명시한 markdown 파일을 추가했습니다.
* 설정 오류 발생 시 빠르게 실패해야 합니다.
* 설정이 불완전할 때 시스템이 자동으로 건조 실행(dry-run) 모드로 전환되어 실제 데이터 없이도 그럴듯한 결과를 도출하는 문제가 있었습니다.
* 이를 개선하기 위해 세션 시작 시 validate-expertise 스킬을 실행하여 필수 설정 필드의 누락 여부를 확인하고, 누락 시 실행을 중단하도록 변경했습니다. YAML 파일에도 필수 필드에 대한 주석을 추가했습니다.
* 하위 에이전트에서는 슬래시 명령이 작동하지 않습니다.
* 하위 에이전트에서 슬래시 명령(/skill-name)을 사용하면 스킬이 발견되지 않았다는 오류 대신, markdown 파일을 직접 읽는 방식으로 처리되어 실제 실패를 숨기는 문제가 있었습니다.
* 모든 슬래시 명령 구문을 실제 markdown 파일 읽기 및 실행 지침으로 수정했습니다. 또한, 온보딩 에이전트를 도입하여 설정 파일 작성을 자동화하고 상호작용적으로 구성 값을 확인하도록 개선했습니다.
* 인터페이스를 인증 정보뿐만 아니라 제약해야 합니다.
* 하위 에이전트가 부모 세션의 도구(MCP tools)를 상속받지 못하고 인증에 실패하는 문제가 발생했습니다.
* CRM 스킬을 직접 호출하는 방식으로 수정하고, ID 확인을 부모 세션에서 동기적으로 처리하도록 변경하여 하위 에이전트에서 인증 문제를 분리했습니다.
* 로컬 개발 인증과 프로덕션 인증은 다른 시스템입니다.
* 로컬 개발 환경에서 az login이 작동한다고 해서 하위 에이전트에서도 동일하게 작동하지 않으며, 로컬 인증을 프로덕션 인증 전략으로 사용할 수 없음을 확인했습니다.
* 프로덕션 환경에서는 워크로드 ID 모델(관리 ID, 워크로드 ID 페더레이션, 서비스 주체 등)을 사용하는 방향으로 설계해야 합니다.
* IncidentContext는 내구성이 있고 계층화되어야 합니다.
* 초기에는 IncidentContext가 주로 프롬프트와 메모리 상태에 존재했지만, 작업 재개, 중단 방지, 감사 추적을 위해 파일 기반으로 변경했습니다.
* IncidentContext를 단순한 데이터 덩어리가 아닌, 입력, 수집 중인 증거, 합성된 가설, 검토자 주석, 최종 감사 기록 등 단계별로 분리하여 관리하는 계층화된 접근 방식의 중요성을 강조했습니다.
* 생각보다 더 많은 부분을 테스트할 수 있습니다.
* AI 시스템 전체를 수동으로 테스트하는 대신, 정적 유효성 검사, 결정론적 로직 테스트, 에이전트 간 계약 테스트, 실제 사고 사례를 활용한 골든 케이스 테스트, LLM 평가 등 다양한 엔지니어링 기법을 적용하여 테스트 범위를 확장했습니다.
* CI/CD 파이프라인에 테스트를 통합하여 자동화된 결과를 얻도록 했습니다.

시사점

이러한 문제점들을 해결하는 과정에서, 여러 에이전트 시스템은 실제 소프트웨어처럼 테스트 가능하고, 경계를 명확히 하며, 암묵적인 행동에 의존하지 않도록 개선되었습니다. 디버깅 순서를 실행 체인 중심으로 재정렬하는 접근 방식은 다른 다중 에이전트 시스템에도 적용할 수 있는 중요한 방법론입니다.