새소식
300x250
AI/AI 이슈와 생각들
ABC Legal Agent 사례 - Git · PR · 피드백 루프로 Production Agent를 키운 방법
- -
728x90
안녕하세요! 갓대희 입니다.
이번 포스팅은 [ Claude Managed Agents + ABC Legal의 Agent-as-Code 운영 사례 ] 입니다. : )
요즘 AI Agent 이야기를 보면 보통은 "어떤 모델이 더 똑똑한가", "프롬프트를 어떻게 써야 하나"에 초점이 맞춰지는 경우가 많다.
그런데 이번에 Anthropic이 공개한 ABC Legal 사례는 조금 결이 달랐다. Agent를 잘 만드는 법보다, 만들어진 Agent를 회사 안에서 어떻게 안전하게 운영하고 계속 개선할 것인가에 더 가까운 사례였기 때문이다.
개인적으로는 이번 사례에서 Agent-as-Code, Git, Pull Request(PR), Human-in-the-loop, Feedback Loop, 비용 측정까지 하나의 운영 체계로 묶었다는 점이 가장 인상적이었다.
Anthropic 공식 사례 원문
이번 글의 중심 자료는 Anthropic이 2026년 8월 17일 공개한 How ABC Legal turned every employee into a builder with Claude Managed Agents다. 아래 글에서는 원문의 사례와 수치를 그대로 받아들이기보다, 실제 Production Agent 운영 관점에서 구조와 한계까지 같이 살펴보려 한다.
→ Anthropic 공식 원문 바로가기이 글은 2026년 8월 20일을 기준으로 작성·보강했다. 주요 출처는 Anthropic의 ABC Legal customer story, Claude Managed Agents 공식 문서, Agent Harness Design이다. 제품 상태와 가격, Beta 기능은 바뀔 수 있으므로 실제 도입 전 최신 문서를 다시 확인하길 바란다.
이 글의 핵심
- ABC Legal은 2026년 7월 기준 50개 이상의 Production Agent를 운영하고 있다고 밝혔다.
- 일부 Agent가 담당하는 기존 인간 업무의 비용은 heavy optimization 이전에도 최대 약 50% 줄었다고 보고했다. 회사 전체 인건비가 50% 줄었다는 의미는 아니다.
- 약 310명의 직원이 부서 전반에서 Claude를 일상 업무에 사용하고 있다.
- Agent의 Prompt·Tool·Schedule·Credential·Memory 같은 정의를 Git에 두고, 변경은 Pull Request를 거쳐야만 Production에 반영되도록 만들었다.
- 사람의 Slack 피드백을 Harvester가 모으고 Tuner가 Prompt/Config 변경 PR을 제안한다. 즉, 모델 재학습이 아니라 운영 설정을 지속적으로 개선하는 구조다.
- 핵심은 "Agent를 많이 만드는 것"이 아니라 Versioning · Review · Observability · Feedback · Economics를 갖춘 운영 체계를 만드는 데 있다.
먼저 팩트체크할 부분
Anthropic 글의 제목은 "every employee into a builder"지만, 공개된 숫자를 문자 그대로 해석하면 1,100명 전원이 Agent를 직접 만들었다는 뜻은 아니다. 확인 가능한 수치는 1,100명 규모의 Claude Enterprise 도입, 초기 비개발자 Builder 15명, 약 310명의 일상 사용자, 50+ Production Agent다.
또한 이 자료는 Anthropic의 customer story이므로 독립적인 제3자 감사나 벤치마크 결과는 아니다. 따라서 수치는 "ABC Legal이 추적해 Anthropic이 공개한 사례 데이터"로 보는 편이 정확하다.
목차
- ABC Legal은 어떤 회사이고, 왜 이 사례가 주목받았을까?
- 50+ Agent를 만든 핵심, Agent-as-Code
- 비개발자 15명이 일주일 만에 Agent를 만든 방법
- 실제 Production Agent는 무엇을 하고 있을까?
- Harvester → Tuner → Human Review 자기개선 루프
- Agent Harness와 Managed Agents의 역할 분리
- Agent도 ROI를 측정한다: Efficiency Ratio와 J-Curve
- ABC Legal이 정리한 운영 원칙 7가지
- 개발자 관점에서 이 사례를 어떻게 적용할 수 있을까?
- 도입 전에 꼭 알아둘 제한사항과 현재 Beta 상태
- Q&A
- 정리하며
1. ABC Legal은 어떤 회사이고, 왜 이 사례가 주목받았을까?
법률 문서 전달을 대규모로 처리하는 회사
ABC Legal은 미국의 Legal Document Delivery, 즉 소송·법률 문서를 전달하고 그 과정을 추적하는 업무를 하는 회사다. 회사 공개 사이트 기준으로 미국 전역과 해외를 포함한 대규모 Process Server 네트워크를 운영하고 있다.
Anthropic 사례에서는 ABC Legal이 약 1,100명의 직원에게 Claude Enterprise를 도입한 뒤, 여러 부서에서 각자 반복 업무를 자동화하기 시작했다고 설명한다. 처음에는 꽤 자연스러운 흐름이었다. 누군가 자신의 PC에서 Scheduled Task를 만들고, 또 다른 사람은 별도의 자동화를 만드는 식이었다.
문제는 Agent가 늘어나기 시작하면서 생겼다. 누가 무엇을 만들었는지, 어젯밤 실행됐는지, 얼마의 비용이 들었는지, 어떤 버전이 Production에 올라가 있는지 한눈에 보기 어려워진 것이다.
즉, "AI 자동화가 잘 된다" 다음 단계에서 흔히 부딪히는 운영 문제가 먼저 나타난 셈이다.
| 항목 | 공개된 수치 | 주의해서 볼 점 |
|---|---|---|
| Claude Enterprise 도입 규모 | 약 1,100명 | 1,100명이 모두 Agent를 만들었다는 뜻은 아니다. |
| Production Agent | 50+ | 2026년 7월 기준 회사가 추적한 수치다. |
| Claude 일상 사용자 | 약 310명 | 전 부서에 걸친 daily work 사용자다. |
| 일부 업무 비용 | 최대 약 50% 감소 | 일부 Agent가 담당하는 human task 비용이며, 전체 인건비 지표가 아니다. |
개인적으로는 이 숫자 중 50+ 자체보다, 50개가 넘는 Agent를 통제 가능한 형태로 운영하기 위해 무엇을 바꿨는지가 훨씬 중요한 포인트라고 본다.
2. 50+ Agent를 만든 핵심, Agent-as-Code
Agent를 하나의 소프트웨어처럼 취급한다
ABC Legal의 CTO Brandon Fuller가 선택한 방식은 의외로 개발자에게 익숙하다. Agent를 특별한 AI 객체로 관리하기보다 "구조화된 텍스트 + Configuration"으로 보고 Git Repository에 넣은 것이다.
Agent의 Prompt, Tool List, Schedule, Credential, Memory 같은 요소를 Config 파일로 관리하고, 변경은 반드시 Pull Request를 거치도록 했다. PR이 승인되고 main branch에 Merge되면 Agent가 자동 배포된다.
agent/
├─ config.json
├─ system-prompt.md
├─ deployment/
└─ operational-docs/
위 구조는 원문에 나온 구성 요소를 이해하기 쉽게 단순화한 예시다.
ABC Legal의 실제 Repository 전체가 공개된 것은 아니다. 다만 원문에서는 Agent별로 JSON Config, System Prompt, Deployment Script, Operational Documentation을 표준 구조로 두었다고 설명한다.
Agent 변경 = PR 변경
이렇게 만들면 Agent에도 자연스럽게 Version History, Code Review, Rollback, Audit Trail이 생긴다. 결국 기존 Software Engineering에서 이미 검증해 온 통제 장치를 AI Agent 운영에 그대로 가져온 셈이다.
Starter Template도 두 종류로 단순화
- Event-driven Agent: 새로운 Job이 들어오거나 법원에서 문서가 돌아오는 등 특정 이벤트가 발생할 때 실행
- Scheduled Agent: Hourly, Daily, Weekly처럼 정해진 주기로 실행
빌더는 Repository를 Clone하고 Template을 복사한 뒤 Claude Code에게 "이 Agent가 무슨 일을 해야 하는지" 설명한다. 직접 Runtime을 만드는 것이 아니라 업무 정의와 Configuration을 작성하는 쪽에 집중한다.
ex) 개발자 입장에서 생각하면 새로운 Spring Batch 프로젝트를 매번 밑바닥부터 만드는 대신, 회사 표준 Template과 CI/CD Pipeline이 이미 준비되어 있고 업무 로직만 채우는 방식과 꽤 비슷하다.
3. 비개발자 15명이 일주일 만에 Agent를 만든 방법
Fuller는 Finance, Marketing, Operations, Development 등에서 15명의 Steering Committee를 모았다. 중요한 점은 원문 기준으로 이들 중 Software Developer는 한 명도 없었다는 것이다.
이들에게 Repository를 Clone하고 Claude Code를 이용해 Managed Agent를 만드는 과정을 시켰다. 처음에는 PR이 무엇인지부터 설명해야 했다고 한다.
그런데 결과는 꽤 빨랐다.
시작
비개발자 Builder 15명
비개발자 Builder 15명
1주
15명 전원 Working Agent 구축
15명 전원 Working Agent 구축
확산
각자 팀으로 돌아가 다른 직원 교육
각자 팀으로 돌아가 다른 직원 교육
1개월
약 50+ Agent 운영
약 50+ Agent 운영
여기서 안전장치는 "비개발자가 코드를 마음대로 Production에 올릴 수 있게 했다"가 아니다. 오히려 반대다.
Runtime과 권한, 실행 환경은 Managed Agents가 담당하고, Agent 정의는 Git에 있으며, 변경은 PR과 사람의 승인을 거친다. 비개발자가 참여할 수 있었던 이유는 통제를 없앴기 때문이 아니라, 통제 구조를 표준화했기 때문이다.
의외의 Bottleneck은 AI가 아니라 Git
Fuller가 정리한 운영 원칙 중 하나도 "Git hurdle, not AI hurdle"이다. Prompt를 쓰는 것보다 Repository Clone, Branch, PR 같은 협업 방식을 비개발자에게 익히게 하는 일이 실제 허들이었다는 의미다.
4. 실제 Production Agent는 무엇을 하고 있을까?
이번 사례가 재미있는 이유는 단순 Demo Agent가 아니라 실제 법률 문서 처리와 개발, 재무, 마케팅 업무에 Agent가 들어가 있다는 점이다.
| Agent | 하는 일 | 포인트 |
|---|---|---|
| AI Code Reviewer | 4개 Codebase의 모든 PR을 Multi-model로 분석 | Security Bug, Performance Regression, Committed Credential 등을 Merge 전에 점검 |
| EvidenceChain Delivery | DB Report → Browser로 PDF Retrieval → Customer FTP 전송 | 자동화 경험이 없던 Account Manager가 Claude Code에 설명해 약 1시간 만에 구축 |
| eFiling Rejection Diagnoser | 법원 반려 발생 시 Job Detail과 Court Rule을 확인하고 원인 진단 | 기존에 직원이 수시간 쓰던 업무를 약 1분 안에 Slack으로 전달 |
| Job Verification | 법원 웹사이트를 탐색해 Hearing, Case, Jurisdiction, Deadline 확인 | Incoming Job을 실제 Court 정보와 대조 |
| AR Remittance | Remittance Email을 Parse하고 NetSuite Payment Application File 생성 | Slack에 올린 뒤 사람의 One-click Approval 후 Import |
| Charvis | 완료된 Service Job Review | Compliance Team의 판단과 약 98% 일치 |
| 기타 | Attorney Coverage, Google Ads Analyst, Capitalize-or-Expense, Service-Overdue-Nudger 등 | 개발 조직만이 아니라 Operations·Finance·Marketing까지 확산 |
98%는 "정답률"과 조금 다르게 봐야 한다
원문 표현은 Charvis가 Compliance Team의 판단과 약 98%의 시간 동안 agree한다는 것이다. 따라서 이를 별도의 Ground Truth Benchmark에서 98% Accuracy를 달성했다고 확대 해석하면 안 된다. 인간 팀과의 판단 일치율에 가깝다.
5. Harvester → Tuner → Human Review 자기개선 루프
ABC Legal의 Agent는 실행 결과나 추천 내용을 Slack에 올리고, 사람들은 Thread Reply나 Emoji Reaction으로 피드백을 남긴다.
여기서 재미있는 부분은 이 피드백을 그냥 흘려보내지 않는다는 점이다.
- Initial Agent: 실제 업무를 수행하고 각 Action의 Audit Trail을 남긴다.
- Harvester: Hourly 또는 Daily로 Slack의 Thread Reply와 Emoji Reaction을 수집해 Labeled Data로 만든다.
- Tuner: Weekly로 전체 피드백을 살펴보고 Prompt나 Configuration 변경안을 PR로 작성한다.
- Human Review: 사람이 변경안을 검토하고 Merge한다.
중요: Model Weight를 재학습하는 구조가 아니다
Tuner가 직접 모델의 Weight를 바꾸는 것이 아니다. Prompt와 Config를 수정하는 Pull Request를 제안하고, 최종 Production 반영은 사람이 승인한다. 소프트웨어의 개선 루프와 거의 같은 방식이다.
원문에는 Docketly라는 50명 규모 자매회사에서 시작한 "deliveries-as-code" 사례도 나온다. 약 145개의 Routing Rule을 DB Admin 화면이 아니라 YAML File로 Git에 두고, Agent가 피드백을 모아 변경 PR을 제안한다.
결국 Emoji 하나로 잘못된 Routing을 표시하면, Harvester → Tuner → Human Review → Production 반영까지 한 주 안에 이어질 수 있는 구조다.
개인적으로는 이 부분이 이번 사례의 핵심이라고 본다. 흔히 말하는 "Self-improving Agent"가 Agent가 자기 마음대로 자기 자신을 바꾸는 형태가 아니라, 기존 개발 프로세스 안에서 사람이 승인하는 개선 PR을 반복적으로 만드는 구조라는 점이 현실적이다.
6. Agent Harness와 Managed Agents의 역할 분리
Agent Harness란?
Anthropic은 Agent Harness를 대략 모델 주변의 Software Scaffolding, 즉 Loop, Tools, Context Management, Guardrail 등을 묶는 구조로 설명한다.
쉽게 말하면 LLM 자체가 두뇌라면, Agent Harness는 "이 두뇌가 실제 업무를 하기 위해 어떤 Tool을 쓰고, 언제 반복하고, Context를 어떻게 유지하고, 어디까지 행동할 수 있는가"를 정하는 실행 골격에 가깝다.
| ABC Legal이 관리 | Managed Infrastructure가 담당 |
|---|---|
| Prompt | Execution Loop |
| Tool List | Sessions |
| Trigger Logic | Memory |
| Audit Trail | Console |
| Outcome Feedback Loop | Models / Runtime |
ABC Legal은 내부 플랫폼의 100개가 넘는 Tool, Metabase, Slack, Atlassian 등에 Agent를 연결했다. 모델도 업무 특성에 따라 Sonnet을 기본으로 사용하고, 빠르고 대량인 작업에는 Haiku, 더 깊은 Reasoning이 비용을 정당화할 때는 Opus를 선택한다고 밝혔다.
여기서 중요한 것은 "모델을 하나 고르고 끝"이 아니라, Agent Definition과 Runtime을 분리해 둔 덕분에 모델 교체가 설정 변경에 가까워진다는 점이다.
현재 문서와 사례를 구분해서 보자
ABC Legal 사례에서는 Scheduled Agent 운영에 Bitbucket Pipelines가 등장한다. 한편 현재 Claude Managed Agents 공식 문서 자체도 Cron Expression과 Timezone을 지정하는 Scheduled Deployments 기능을 제공한다. 즉, 사례의 구현 방식과 지금 플랫폼이 지원하는 기능을 같은 것으로 섞어 보지 않는 편이 좋다.
7. Agent도 ROI를 측정한다: Efficiency Ratio와 J-Curve
Agent를 만들기 시작하면 재미있어서 자동화 개수만 늘리기 쉽다. 그런데 ABC Legal은 정반대로 각 Agent가 실제로 얼마나 Value를 만들고, 얼마의 비용을 쓰는지를 함께 본다.
Efficiency Ratio = Value Delivered ÷ Run Cost
각 Managed Agent는 실행할 때마다 자신이 만든 Value를 Hours와 Dollars 단위로 Data Warehouse에 보고한다. 그리고 실행 비용과 비교한다.
처음 만든 Agent는 큰 모델을 쓰고 Token도 많이 소비하며 Eval도 부족해 경제성이 좋지 않을 수 있다. 하지만 업무 데이터를 쌓고 Eval을 만들고, 더 빠르고 저렴한 모델로 바꾸고, Token을 줄이면 어느 시점부터 Positive로 전환될 수 있다. Fuller는 이를 J-Curve처럼 설명한다.
이 수치를 Benchmark처럼 보면 안 된다
Agent별 세부 비용표나 Raw Dataset이 공개된 것은 아니다. 따라서 "모든 기업이 50% 절감할 수 있다"는 식으로 일반화하기보다, Agent 운영에 비용 측정 프레임을 넣었다는 운영 설계를 참고하는 편이 좋다.
Human-in-the-loop에서 Automation Mode로
대부분의 Agent는 처음부터 자동으로 행동하지 않는다. 먼저 사람에게 Recommendation을 보여주고, 사람이 Accept/Reject하거나 Slack에서 피드백을 남긴다.
그 데이터로 Eval을 만들고, 해당 특정 업무에서 Agent가 사람만큼 또는 그보다 나은 품질을 지속적으로 보이면 그때 Automation Mode로 옮긴다.
Autonomy를 먼저 주고 사고가 나면 막는 방식이 아니라, Trust를 증명한 뒤 권한을 올리는 방식이다.
8. ABC Legal이 정리한 운영 원칙 7가지
| 원칙 | 의미 |
|---|---|
| 1. Think of everything as code | Prompt뿐 아니라 Schema, Routing Rule, Notification Template, Business Config까지 Text/Repo로 관리할 수 있으면 Agent가 다루기 쉬워진다. |
| 2. Start with humans in the loop | 처음에는 사람이 Recommendation을 검토하고, 충분히 신뢰를 얻은 뒤 자동화한다. |
| 3. PR = Control Surface | Agent가 관여하는 의사결정을 PR처럼 만들면 Comment, Approval, Audit Trail을 그대로 활용할 수 있다. |
| 4. Invest in the feedback loop | Slack Reply와 Emoji 같은 사람의 반응을 Prompt/Config 개선 데이터로 연결한다. |
| 5. Skip the scheduled-task detour | 개인 PC의 Local Scheduled Task부터 키우기보다 처음부터 관리 가능한 Runtime으로 옮긴다. |
| 6. Expect the Git hurdle | 비개발자에게는 AI보다 Git/PR 협업 방식이 더 큰 학습 장벽일 수 있다. |
| 7. Not every task deserves an agent | Agent 비용은 공짜가 아니다. Value가 Cost보다 큰 업무에 집중한다. |
9. 개발자 관점에서 이 사례를 어떻게 적용할 수 있을까?
ABC Legal의 전체 시스템을 그대로 따라 할 필요는 없다. 다만 회사나 개인 프로젝트에 Agent가 두세 개를 넘어가기 시작한다면 아래 구조는 꽤 현실적으로 적용할 수 있다.
- Agent마다 Owner와 Single Job을 정한다. "무엇이든 하는 Agent"보다 책임 범위를 명확하게 둔다.
- Prompt와 Config를 Git에 넣는다. 운영 화면에서 직접 수정하기보다 변경 이력을 남길 수 있게 한다.
- Production 변경은 PR로 통일한다. Agent가 제안한 수정도 사람이 Review한다.
- 처음에는 Recommendation Mode로 시작한다. 자동 실행 권한은 나중에 올린다.
- Feedback을 구조화한다. 단순 "좋다/나쁘다"가 아니라 어떤 Input에서 어떤 판단이 틀렸는지 남긴다.
- Eval과 비용을 같이 본다. 정확도가 좋아져도 Run Cost가 과하면 Agent가 아닌 단순 Batch/Rule Engine이 더 나을 수 있다.
개인적으로 가장 가져오고 싶은 한 가지
"AI가 수정한 결과도 결국 PR로 들어오게 만든다"는 생각이다. 기존 개발자가 이미 익숙한 Review·Approval·Rollback을 버리고 새로운 AI 전용 통제 시스템을 만드는 것보다 훨씬 현실적이다.
이 관점에서 보면 Agent Engineering의 다음 경쟁력은 Prompt Engineering만이 아니라 Harness Engineering, Context Engineering, Evaluation, Governance, Cost Engineering을 얼마나 자연스럽게 묶느냐에 가까워 보인다.
10. 도입 전에 꼭 알아둘 제한사항과 현재 Beta 상태
사례가 좋아 보인다고 바로 Production에 도입하기 전에 현재 Claude Managed Agents의 제품 상태도 따로 확인해야 한다.
- 현재 Beta: 2026년 8월 19일 공식 문서 기준 Claude Managed Agents는 Beta이며 API 요청에 Beta Header가 사용된다.
- Stateful 구조: Session이 대화 기록, Sandbox State, Output 등을 Server-side에 유지하는 구조다.
- ZDR/HIPAA BAA: 공식 문서는 현재 Managed Agents가 Zero Data Retention이나 HIPAA BAA Coverage 대상이 아니라고 안내한다. 민감 데이터 환경에서는 별도 검토가 필요하다.
- Self-hosted Sandbox: 현재 Self-hosted Sandbox를 Public Beta로 제공해 Tool Execution, File, Network Egress를 자체 Infrastructure 안에서 실행할 수 있다. 다만 Orchestration은 Anthropic 쪽에 남는 구조다.
- 가격: 공식 제품 페이지는 현재 Standard Claude Platform Token Rate에 더해 Active Runtime 기준 Session-hour 비용을 안내한다. 가격은 변경될 수 있으므로 도입 시점에 다시 확인하는 편이 좋다.
Legal Company 사례라고 해서 모든 규제 요구사항이 자동 충족되는 것은 아니다
ABC Legal이 어떤 내부 데이터 분류와 보안 통제를 적용했는지 customer story에 모든 세부사항이 공개된 것은 아니다. 따라서 "법률 회사가 쓰니 우리 회사도 그대로 써도 된다"고 판단하기보다, 자사 데이터 등급·보존 정책·Credential 관리·Network 경계를 별도로 확인해야 한다.
현재 플랫폼은 사례 이후에도 계속 확장 중
Managed Agents에는 Memory, Scheduled Deployments, Vault, Multi-agent Orchestration, Self-hosted Sandbox 같은 기능이 계속 추가되고 있다. 따라서 이 글의 ABC Legal 운영 구조는 "제품 기능 목록"이라기보다 실제 조직이 Managed Runtime을 이용해 Governance를 설계한 한 사례로 보는 편이 좋다.
11. Q&A
Q1. Agent-as-Code는 Anthropic의 별도 제품명인가?
아니다. 이번 사례에서 ABC Legal이 Agent의 Prompt와 Configuration을 Git Repository의 코드처럼 관리한 운영 방식에 가깝다. 핵심은 Versioning, PR Review, Rollback, Audit Trail을 Agent에도 적용하는 것이다.
Q2. 정말 비개발자도 Production Agent를 만들었나?
Anthropic 사례 기준으로 초기 15명의 Steering Committee에는 Software Developer가 없었고, 일주일 안에 모두 Working Agent를 만들었다. 다만 Runtime과 Deployment Structure는 사전에 CTO가 Starter Kit 형태로 표준화해 둔 상태였다.
Q3. 50% 비용 절감은 회사 전체 인건비인가?
아니다. 원문은 일부 Agent가 담당하는 Human Task의 비용이 heavy optimization 이전에도 최대 약 50% 감소했다고 설명한다.
Q4. Tuner가 Agent를 자동으로 고쳐 Production에 반영하나?
아니다. Tuner는 Prompt/Config 변경안을 Pull Request로 제안하고, 사람이 Review한 뒤 Merge한다. Model Weight를 재학습하는 구조도 아니다.
Q5. Claude Managed Agents는 지금 정식 GA인가?
2026년 8월 19일 공식 문서 기준 Beta다. 실제 서비스 도입 전 Beta 조건, Data Retention, Security 요구사항을 다시 확인해야 한다.
Q6. 모든 반복 업무를 Agent로 바꾸는 것이 좋은가?
ABC Legal의 운영 원칙도 그렇지 않다고 말한다. 단순 Rule이나 Batch로 충분한 업무라면 Agent가 오히려 비싸고 복잡할 수 있다. Value가 Cost를 넘는 문제를 고르는 것이 먼저다.
12. 정리하며
처음 이 사례의 숫자만 보면 "50+ Agent", "최대 50% 비용 절감"이 가장 눈에 들어온다. 그런데 전체 내용을 따라가 보면 진짜 배울 점은 숫자보다 운영 방식에 있다.
Agent를 Prompt 한 덩어리로 두지 않고 Git에서 Versioning하고, PR로 변경을 통제하고, 사람의 Feedback을 다시 Prompt/Config 개선으로 연결하고, 마지막에는 Value와 Run Cost까지 측정한다.
결국 Production Agent의 핵심은 더 좋은 Prompt 하나가 아니라, Agent를 Software처럼 운영할 수 있는 시스템을 만드는 것에 가까워 보인다.
개인적으로는 앞으로 Agent 기술이 발전할수록 이 부분이 더 중요해질 것 같다. 모델이 똑똑해질수록 "무엇을 할 수 있나"보다 "어디까지 맡길 것인가, 어떻게 검토할 것인가, 잘못됐을 때 어떻게 되돌릴 것인가"가 실제 서비스에서는 더 큰 문제가 될 테니 말이다.
여기까지 ABC Legal의 Claude Managed Agents 사례를 Agent-as-Code, Git/PR Governance, Feedback Loop, ROI 관점에서 정리해 보았다. Agent를 실제 Production에 붙이려는 분이라면 50개부터 시작하기보다, 작은 Agent 하나를 Repository에 넣고 PR과 Human Review를 붙여 보는 것부터 시작해보면 좋을 것 같다. 감사합니다. : )
참고 자료
- Anthropic — How ABC Legal turned every employee into a builder with Claude Managed Agents
- 본문의 Hank Slack 화면과 Self-improving Agent Loop 이미지는 위 Anthropic Customer Story에 게재된 공식 이미지를 출처 표기와 함께 사용했다.
- Claude Platform Docs — Claude Managed Agents overview
- Anthropic — Claude Managed Agents: get to production 10x faster
- Anthropic — Agent Harness Design: 3 Patterns for Harnessing Claude's Intelligence
- Claude Platform Docs — Scheduled deployments
- Claude Platform Docs — Using agent memory
- Anthropic — Self-hosted sandboxes and MCP tunnels
- ABC Legal 공식 사이트
작성일은 2026년 8월 19일이며, ABC Legal customer story와 Claude Managed Agents 공식 문서를 중심으로 정리했다. 고객 사례의 성과 수치는 ABC Legal이 추적해 Anthropic이 공개한 값이며, 독립적인 제3자 Benchmark나 감사 결과로 일반화하지 않았다. 제품 Beta 상태, 가격, 데이터 보존·보안 조건은 실제 도입 전에 최신 문서를 다시 확인해야 한다.
300x250
'AI > AI 이슈와 생각들' 카테고리의 다른 글
| Google AI SEO 최적화 가이드 리뷰 : AI 검색 시대, 하던 SEO를 잘 하면 된다( AEO·GEO는 SEO의 다른 이름이다) (2) | 2026.05.19 |
|---|---|
| AI 자격증 뭘 따야 할까? 2026 AI 수료증 정리 — Anthropic·Google·IBM 등 플랫폼 별 비교 (3) | 2026.03.17 |
| 토스 앱인토스(3,000만 유저에게 닿는 미니앱 개발) - 간단한 소개 (3) | 2025.11.05 |
| SDD(Spec-Driven Development) + AWS Kiro IDE 적용기 (5) | 2025.09.25 |
| Ollama 활용 아이디어 기록의 글 (feat 로컬 LLM를 어떻게 활용해볼까?) (10) | 2025.08.03 |
Contents
소중한 공감 감사합니다