Claude 관리형 에이전트를 처음 도입했을 때, Fuller는 팀에 모든 에이전트를 코드로 정의하도록 했다. 에이전트가 갖춰야 할 본연의 형태가 바로 코드라고 믿기 때문이다. 그의 설명에 따르면, "에이전트는 본질적으로 구조화된 텍스트, 즉 프롬프트와 설정의 조합입니다. 텍스트로 이루어진 것은 무엇이든 리포지토리에 올릴 수 있고, 그러면 회사 전체가 열람하고 검토하고 개선할 수 있죠." 에이전트의 프롬프트, 도구 목록, 스케줄, 자격 증명, 메모리는 모두 회사 소프트웨어와 함께 git 리포지토리에서 관리되는 설정 파일에 담긴다. 에이전트의 변경은 반드시 누군가가 승인한 풀 리퀘스트(pull request)를 통해서만 이루어지므로, 모든 에이전트에 버전 이력, 코드 리뷰, 롤백, 감사 추적이 자동으로 보장된다.

Fuller는 일주일에 걸쳐 두 가지 템플릿으로 구성된 스타터 키트를 만들고 전용 git 리포지토리에 보관했다. 하나는 이벤트 구동형 에이전트용으로, 새 작업이 들어오거나 법원에서 문서가 반환되는 등 특정 상황이 발생하는 즉시 실행된다. 다른 하나는 스케줄형 에이전트용으로, 시간별·일별·주별처럼 타이머에 따라 실행된다. 각 에이전트는 표준 구조를 갖춘 자체 폴더에 존재하며, JSON 설정 파일, 마크다운 형식의 시스템 프롬프트, 배포 스크립트, 운영 문서로 구성된다. main 브랜치에 변경사항을 병합하면 에이전트가 자동으로 배포된다. 빌더는 별도의 소프트웨어를 작성할 필요가 없다. 리포지토리를 클론하고 스타터 템플릿을 복사한 뒤, Claude Code에 에이전트가 해야 할 일을 설명하면 설정, 프롬프트, 자격 증명 저장소, 메모리까지 에이전트에 필요한 모든 것이 만들어진다.

기술 격차 해소

Fuller는 재무, 마케팅, 운영, 개발 부서에서 소프트웨어 개발자가 아닌 인원 15명으로 운영위원회를 꾸리고, 이들이 직접 리포지토리를 클론해 Claude Code로 관리형 에이전트를 구축하도록 했다.

목표는 비개발자도 직접 프로덕션 에이전트를 만들 수 있음을 증명하는 것이었다. 모든 에이전트가 개발팀을 거쳐야 한다면, 그 병목이 회사 전체의 속도를 가로막게 된다. 이 방식이 안전할 수 있었던 이유는 참가자들이 소프트웨어를 직접 작성하는 것이 아니었기 때문이다. 설정과 프롬프트를 채워 넣으면, 관리형 에이전트가 런타임을 제공했다.

"PR이 뭔지 설명해야 했어요. 비개발자 중 많은 분들이 PR을 전력 질주하는 것으로 이해하더라고요," 그는 웃으며 말했다. "지금은 그분들이 풀 리퀘스트를 열고 서로에게 보내고 있습니다."

일주일 만에 15명 전원이 작동하는 에이전트를 완성했다. 이들은 각자의 팀으로 돌아가 동료들을 교육했고, 한 달 만에 ABC Legal 전사에 에이전트 50여 개가 가동됐다. 각 에이전트에는 이름, 담당자, 단 하나의 역할이 부여된다.

법률 문서 처리 대부분의 단계에 배치된 에이전트

현재 ABC Legal은 법률 문서 접수 처리의 대부분 단계와 그 주변 운영 업무 전반에 에이전트를 배치해 두고 있다.

AI Code Reviewer는 4개 코드베이스의 모든 풀 리퀘스트를 검토하며, 멀티 모델 분석으로 보안 취약점, 성능 저하, 실수로 커밋된 자격 증명을 잡아낸다. 개발자들은 이제 병합 전에 이 에이전트의 리뷰를 기다린다.

EvidenceChain™ 배송 에이전트는 계정 관리자가 수작업으로 처리하던 주간 업무를 대신 맡게 됐다. ABC Legal은 자체 운영 사이트인 EvidenceChain.com을 통해 법원, 원고, 피고가 현장에서 완료된 송달 기록(담당 소송 대리인 정보, 시도 일시, 문서 배송 사진 등)을 조회할 수 있도록 한다. 한 고객은 이 사이트에서 특정 기록을 지속적으로 제공받길 원했다. 이제 에이전트가 해당 작업에 맞는 데이터베이스 보고서를 조회하고, 관리형 에이전트에 내장된 브라우저로 각 PDF를 가져와 매일 고객의 FTP 서버로 전달한다. 이 에이전트를 구축한 계정 관리자는 이전까지 자동화 경험이 전무했지만, Claude Code에 원하는 내용을 설명하는 것만으로 약 한 시간 만에 만들어냈다.

eFiling 반려 진단 에이전트는 법원이 서류를 반려하는 즉시 자동으로 실행되어, 작업 세부 내용을 읽고 법원 규정을 확인한 뒤 약 1분 만에 Slack에 진단 결과를 게시한다. 이전에는 직원의 하루를 통째로 잡아먹던 일이었다. 작업 검증 에이전트는 접수되는 모든 작업을 법원과 대조하며, 브라우저로 법원 웹사이트를 탐색해 심리나 사건이 적절히 등록됐는지, 명시된 날짜에 실제로 예정돼 있는지 확인한 뒤, 확인 결과를 바탕으로 작업을 업데이트하고 관할 구역, 법원, 제소 기한 등을 플래그로 표시한다.

변호사 업무 배정 에이전트는 심리를 처리할 변호사를 네트워크에서 탐색하며, 가용 여부를 확인하고 이메일을 발송한 뒤 가용 시간과 비용에 관한 회신을 읽어, 담당 코디네이터가 업무 배정을 확정할 수 있도록 한다.

재무 부문에서는 AR 송금 에이전트가 송금 이메일을 파싱하고 NetSuite 결제 적용 파일을 생성한 뒤 원클릭 승인을 위해 Slack에 게시하고 가져오기를 처리한다. 또한 일별 에이전트가 각 엔지니어링 티켓에 대해 자본화 또는 비용 처리 판정을 내린다. 마케팅팀에서는 Google Ads 분석 에이전트가 채널 담당자에게 주간 권고사항을 게시한다. 운영 부문에서는 Charvis라는 검토 에이전트가 완료된 송달 업무를 검수하며, 현재 컴플라이언스 팀과 약 98%의 일치율을 보이고 있다.

서비스 기한 초과 알림 에이전트는 ABC Legal 운영 적체의 1차 처리 계층을 담당한다. 사람이 일일이 해야 했던 반복적인 첫 단계를 대신하며, 인간의 승인을 위한 단계별 일일 연락 초안을 작성한다.

에이전트를 더 똑똑하게: 수집, 조정, 반복

ABC Legal의 에이전트들은 사람의 감독 하에 작동한다. 수행한 작업이나 권고사항을 Slack에 게시하면, 사람들이 스레드로 답글을 달거나 이모지로 반응을 남긴다.

Fuller는 이 반응 데이터가 훈련 신호로 활용되지 못하고 있다고 판단했다. 물론 모든 에이전트가 이 신호를 필요로 하는 것은 아니다. 대부분의 에이전트는 단일 작업만 처리하며, 출력 결과를 평가하는 사람 없이 독립적으로 실행된다. 등급이 매겨진 피드백을 수집하는 에이전트들에 대해서는 ABC Legal이 세 가지 역할 아키텍처(three-role architecture)를 적용한다. 하나의 워크스페이스, 실행 환경, 자격 증명 저장소를 공유하지만 서로 다른 스케줄로 실행되는 에이전트 세 개가 한 팀을 이루는 구조다. 이 패턴은 Slack의 메시지를 버전 관리되고 사람이 승인한 에이전트 변경사항으로 전환한다:

1. 초기 에이전트(Initial Agent)는 작업이 들어오거나 문서가 반환될 때 대개 실시간으로 업무를 처리하고, 각 행동의 감사 추적을 기록한다.
2. 수집기(Harvester)는 시간별 또는 일별로 실행되어 Slack에서 스레드 답글과 이모지 반응 형태로 올라온 사람들의 피드백을 수집한다. 각 피드백은 레이블이 붙은 데이터 포인트가 된다.
3. 조정기(Tuner)는 주별로 실행되어 전체 데이터를 한꺼번에 검토하고, 모델의 가중치가 아니라 프롬프트나 설정 변경을 제안한다. 초안 작성만 하며, 풀 리퀘스트는 사람이 검토하고 병합한다.

'코드형 배송(deliveries-as-code)'은 Fuller가 작업 라우팅 방식을 조정하기 위해 구축한 에이전트 시스템으로, ABC Legal의 50인 규모 자매 회사 Docketly에서 시작됐다. Docketly는 라우팅 및 처리 규칙을 각각 갖춘 '배송' 단위로 업무를 구성한다. 145개 가량의 규칙셋은 관리 화면의 레코드가 아니라 git의 단일 YAML 파일로 관리되므로, 배송 방식을 조정하려면 파일을 수정하고 풀 리퀘스트를 열면 된다.

루프는 네 개의 에이전트로 구성된다. 하나는 주간 판정 결과를 Slack에 게시하고, 수집기는 사람의 피드백을 바탕으로 이모지 반응을 레이블로 변환하며, 조정기는 YAML에 대한 풀 리퀘스트를 열고, 네 번째 에이전트는 병합된 설정을 프로덕션 데이터베이스에 반영한다. 네 번째 에이전트는 사람이 검토하고 승인한 내용만 실행한다. 실제로 잘못 라우팅된 배송에 이모지 반응을 남기면, 해당 배송의 라우팅 규칙 변경이 일주일 내에 병합될 수 있다. 검토만이 유일한 수동 단계다.

Claude 관리형 에이전트를 선택한 이유

Fuller는 여러 프레임워크를 검토한 끝에 Claude 관리형 에이전트를 조직의 에이전트 운영 체계로 낙점했다. 기준은 명확했다. 버전 관리, 세션 추적, 워크스페이스 청구, 모델 선택, 메모리 기본 기능(memory primitives), MCP 연결, 그리고 무엇보다 별도 인프라를 관리할 필요가 없을 것.

플랫폼의 책임 분담 구조는 Fuller가 원하는 운영 방식과 정확히 맞아떨어진다. Anthropic의 관리 인프라가 실행 루프, 세션, 메모리, 콘솔, 모델 자체 등 에이전트 구동에 필요한 모든 것을 담당한다. ABC Legal은 프롬프트, 도구 목록, 트리거 로직, 감사 추적, 그리고 결과에 대한 피드백 루프를 책임진다.

규모가 커질수록 특히 중요하게 작용한 기능들이 있다:

• 버전 관리: 푸시할 때마다 옵티미스틱 락킹(optimistic locking)이 적용된 새 에이전트 버전이 생성된다. 롤백은 간단하다.
• 모델 유연성: 대부분의 에이전트에는 Claude Sonnet, 대용량·고속 작업에는 Claude Haiku, 심층 추론이 비용을 정당화하는 경우에는 Claude Opus를 기본값으로 사용한다. 모델 교체는 한 줄 변경으로 끝난다.
• MCP 연결 및 자격 증명 저장소: 에이전트는 ABC Legal 자체 플랫폼(100개 이상의 도구 지원), 리포팅용 Metabase, 사람 개입형 상호작용을 위한 Slack, 프로젝트 관리용 Atlassian과 연결된다.
• 스케줄 배포: 반복 실행 에이전트는 Bitbucket Pipelines의 cron 스케줄로 구동되며, 리포지토리 접근, 시크릿, 청구가 이미 통합되어 있다.

ABC Legal은 AI 지출을 벤더, 도구, 팀, 활용 사례별로 세분화해 전액 추적한다. 지출은 봄에 에이전트 집합이 순차적으로 가동되면서 증가했다가, 7월부터는 사용량이 계속 늘어나는 와중에도 줄어들기 시작했다. 아래에서 설명하는 효율화 작업의 결과로, 많은 에이전트가 담당하는 업무 비용이 약 50% 절감됐으며 전 부서 약 310명이 Claude를 활용하고 있다.

회사의 비용 접근 방식은 철저히 의도적이다. 수익이 측정 가능한 수직 계열 운영 도구와 에이전트에 지출을 집중하면서, 범용 채팅 및 아이디어 발산 용도는 광범위하게 허용하되 비용은 통제한다. 대부분의 에이전트는 처음에 사람이 루프에 포함된 방식으로 시작한다. 에이전트가 작업이나 티켓을 분석해 권고사항을 만들면, 사람이 검토한 후 실행 여부를 결정하는 구조다. 권고사항은 작업에 저장되어 배너로 표시되고 담당자가 업무 흐름 속에서 수락 또는 거부할 수 있거나, Slack 채널에 게시되어 스레드로 답글을 남길 수 있다. 이러한 응답이 쌓여 좋은 판단과 나쁜 판단에 레이블이 붙은 데이터셋이 형성되고, 이것이 수집기-조정기 루프로 이어져 평가(eval) 작성과 최신 모델들 간의 에이전트 성능 비교가 가능해진다. 에이전트가 해당 특정 작업에서 사람과 동등하거나 더 나은 성과를 증명하면, 자동화 모드로 전환되어 독자적으로 행동한다. 이후에도 성능 변화를 감시하기 위해 동일한 측정 체계 안에 머문다.

ABC Legal이 추적하는 지표는 효율 비율(efficiency ratio)로, 에이전트가 제공하는 가치를 실행 비용으로 나눈 값이다. 모든 관리형 에이전트는 실행할 때마다 시간과 비용 단위로 자신의 가치를 데이터 웨어하우스에 보고한다. 에이전트는 J커브를 그리는 경향이 있다. 처음에는 새롭고 큰 모델을 쓰는 동안 적자를 면치 못하다가, 팀이 평가를 작성하고 더 저렴하고 빠른 모델로 전환하며 토큰을 줄이면서 흑자로 돌아선다.

에이전트 집합 배포를 위한 모범 사례

Fuller가 AI, 특히 Claude 관리형 에이전트를 도입하며 정립한 실천 원칙들은 다음과 같다:

‍

• 모든 것을 코드로 생각하라. "코드는 구조화된 텍스트일 뿐이고, LLM은 텍스트 엔진입니다," 그는 말했다. "비즈니스의 더 많은 부분을 리포지토리의 텍스트로 만들수록, 에이전트가 주는 레버리지가 커집니다." 이는 전통적인 소프트웨어는 물론, 프롬프트, 스키마, 디스패치 규칙, 알림 템플릿, 비즈니스 설정에도 동일하게 적용된다.
• 사람을 루프에 포함시키는 것부터 시작하라. 모든 에이전트는 사람의 검토를 위한 권고사항을 게시하는 것으로 시작한다. 사람의 판단과 일관되게 일치하는 모습을 보인 이후에야 비로소 단독 행동 권한을 얻는다. "모든 에이전트는 혼자 행동하기 전에 신뢰를 쌓습니다. 처음부터 신뢰가 주어지지는 않죠."

• PR을 제어 인터페이스로 활용하라. "에이전트를 의사결정에 참여시키고 싶다면, 그 결정을 풀 리퀘스트처럼 만들어라." 줄 단위 코멘트, 승인 워크플로, 변경 불가능한 감사 추적이 버전 관리와 함께 자동으로 제공되며, AI 리뷰와 사람 리뷰 모두와 자연스럽게 맞물린다.
• 피드백 루프에 투자하라. 수집기-조정기 패턴은 재훈련 없이도 에이전트가 발전하게 한다. Slack 답글과 이모지 반응이 구조화된 신호가 되어 프롬프트 및 설정 변경으로 이어지며, 모두 사람들이 이미 사용하는 풀 리퀘스트 워크플로를 통해 이루어진다.
• 스케줄 작업 단계는 건너뛰어라. ABC Legal은 관리형 에이전트로 넘어가기 전에 스케줄 작업과 로컬 루틴을 구축하는 데 상당한 시간을 소모했다. 당시 제품이 베타 출시 직후였기 때문이다. Fuller의 현재 조언은 처음부터 관리형 에이전트로 바로 가라는 것이다.
• AI 장벽이 아닌 git 장벽을 예상하라. 어려운 부분은 AI 자체가 아니라, 비즈니스 사용자들이 리포지토리를 클론하고 git과 풀 리퀘스트에 익숙해지도록 하는 것이었다. 결국 빠르게 해냈지만, 그것은 실제로 넘어야 할 장벽이었다. Fuller는 툴링 자체에서 이 과정이 더 쉬워지기를 바라고 있다.
• 모든 작업이 에이전트를 필요로 하지는 않는다. 비용은 현실이다. 모든 팀은 비용 대비 가치를 따져야 한다. 핵심은 실제로 시간을 절약하거나 자동화를 만들어내는 실현 가능한 문제를 선별하고, 특정 작업은 에이전트로 처리할 가치가 없다고 기꺼이 판단할 수 있어야 한다는 것이다.

앞으로의 계획

ABC Legal의 에이전트 집합은 계속 확장되고 있다. 현재 진행 중인 프로젝트로는 송달 사진 검토 에이전트, PagerDuty 트리아지 에이전트, 일일 KPI 다이제스트, 기존 에이전트의 조정기 루프 확장 등이 있다.

팀은 또한 '코드형 X(X-as-code)' 후보 발굴에도 나서고 있다. 알림 템플릿, 이벤트 라우팅 규칙, 디스패치 로직처럼 에이전트가 읽고, 추론하고, 개선을 제안할 수 있는 리포지토리로 옮길 수 있는 대상들이다.

Fuller는 이렇게 말한다. "우리는 AI가 스스로 돌아가는 비즈니스를 지원하고, 직원들은 자유롭게 방향을 이끌어 나가는 조직을 만들고 싶습니다."

Claude 관리형 에이전트에 대해 자세히 알아보기.

‍