앤트로픽이 2026년 5월 5일 금융 서비스용 Claude 에이전트 템플릿 10가지를 공개했다. 핵심은 “금융 AI가 똑똑해졌다”가 아니라, 반복 업무를 바로 붙일 수 있게 skills, connectors, subagents를 한 묶음으로 패키징했다는 점이다.
이 글의 결론부터 말하면, 이번 발표는 일반 사용자가 주식 분석을 대신 맡기는 도구라기보다 금융팀이 피치북, KYC, 월말 결산, 밸류에이션 리뷰 같은 업무를 에이전트 운영 단위로 쪼개는 참고 설계에 가깝다. 즉 모델 뉴스가 아니라 업무 운영 구조 뉴스다. 이 차이를 놓치면 또 “Claude가 애널리스트를 대체한다” 같은 과장 문장으로 뛰어가게 된다. 뛰는 건 좋은데 방향이 틀리면 운동량만 늘어난다.
바로 답
앤트로픽 금융 Claude 에이전트 템플릿은 피치북 생성, 미팅 준비, 실적 리뷰, 모델 빌드, 시장 리서치, 밸류에이션 리뷰, 장부 대사, 월말 결산, 재무제표 감사 준비, KYC 스크리닝을 겨냥한다. 공식 발표 기준으로 템플릿은 Claude Cowork와 Claude Code의 플러그인으로 쓸 수 있고, Claude Managed Agents용 cookbook 형태로도 제공된다.
실무 적용 포인트는 세 가지다. 첫째, 데이터 접근 권한을 업무별로 좁혀야 한다. 둘째, 산출물은 바로 제출하지 말고 사람 승인 게이트를 둬야 한다. 셋째, 에이전트가 쓴 데이터, 도구 호출, 판단 근거를 감사 로그로 남겨야 한다. 금융 업무는 결과가 그럴듯한 것보다 추적 가능한 것이 먼저다.
이번 발표에서 확인된 사실
공식 발표에서 앤트로픽은 금융 서비스에서 시간이 많이 드는 업무를 위해 10개의 ready-to-run agent template을 공개했다고 설명한다. 예시는 피치북 작성, KYC 파일 스크리닝, 월말 결산이다. 또 Claude가 Excel, PowerPoint, Word에서 직접 일하고 Outlook은 예정 기능으로 제시됐다.
템플릿은 단순 프롬프트 묶음이 아니다. 앤트로픽은 각 템플릿을 세 요소로 설명한다. 첫째는 업무 지시와 도메인 지식을 담는 skills, 둘째는 데이터에 통제된 접근을 주는 connectors, 셋째는 세부 작업을 맡는 추가 Claude 모델인 subagents다. 이 구조가 중요하다. 업무 자동화가 프롬프트 한 장에서 끝나지 않고, 권한과 데이터 연결과 하위 검수 역할까지 묶이기 때문이다.
배포 방식도 두 갈래다. 하나는 Claude Cowork 또는 Claude Code 안에서 플러그인처럼 쓰는 방식이다. 분석가가 쓰던 데스크톱 업무 옆에서 같이 움직이는 형태다. 다른 하나는 Claude Platform의 Managed Agents로 돌리는 방식이다. 이 경우 장시간 이어지는 작업이나 정기 스케줄 업무에 더 어울린다.
여기서 TECHTAEK 관점의 핵심은 “어느 모델이 금융 벤치마크 1등인가”보다 “업무가 어떤 실행 경계로 나뉘었나”다. 피치북, 모델, 결산, KYC는 모두 데이터 접근 범위와 승인자와 감사 로그가 다르다. 같은 Claude라도 이 경계를 한 통으로 섞으면 실무에서는 바로 위험해진다.
10개 템플릿을 업무별로 나누면
공식 목록은 크게 두 묶음으로 볼 수 있다. 첫 번째는 리서치와 클라이언트 커버리지다. Pitch builder, Meeting preparer, Earnings reviewer, Model builder, Market researcher가 여기에 들어간다. 이들은 자료를 모으고, 모델을 만들고, 요약하고, 클라이언트용 문서 초안을 만드는 쪽에 가깝다.
두 번째는 재무 운영과 통제 업무다. Valuation reviewer, General ledger reconciler, Month-end closer, Statement auditor, KYC screener가 여기에 들어간다. 이들은 숫자의 일관성, 회계 체크리스트, 감사 준비, 고객 확인, 예외 처리 패키징처럼 틀리면 곤란한 영역에 더 가깝다.
이 두 묶음은 운영 방식이 달라야 한다. 리서치·피치북 쪽은 초안 품질과 출처 연결이 중요하다. 재무 운영·KYC 쪽은 권한, 변경 불가 로그, 승인자, 예외 처리 기준이 더 중요하다. 둘 다 금융 업무지만 위험의 종류가 다르다. 초안이 이상한 것과 장부가 틀린 것은 같은 “오류”라도 데미지가 다르다.
그래서 작은 팀이 이번 발표를 따라 한다면 처음부터 10개를 다 붙이면 안 된다. 먼저 한 업무만 고르는 편이 낫다. 예를 들어 시장 리서치 요약, 실적 발표 리뷰, 월말 결산 체크리스트 초안처럼 사람 검토가 자연스럽게 들어가는 업무가 첫 후보가 된다. KYC 자동 승인이나 재무제표 최종 제출처럼 규제와 책임이 큰 업무는 마지막에 가야 한다.
실무 적용 전 체크리스트
| 체크 항목 | 바로 물어볼 질문 | 실패하면 생기는 일 |
|---|---|---|
| 데이터 권한 | 에이전트가 어느 폴더와 어느 커넥터만 읽나 | 민감 자료가 불필요하게 섞인다 |
| 쓰기 권한 | Excel, PowerPoint, CRM에 직접 쓰기 가능한가 | 초안과 최종본 경계가 무너진다 |
| 승인 게이트 | 고객 제출, 파일링, 회계 반영 전에 누가 승인하나 | 그럴듯한 초안이 실행 문서가 된다 |
| 출처 표시 | 숫자와 문장마다 원천 파일이 남나 | 나중에 검증할 수 없다 |
| 로그 | 도구 호출과 판단 근거가 남나 | 사고 뒤 원인 추적이 안 된다 |
| 예외 처리 | 불확실하면 멈추는가, 추측으로 채우는가 | 빈칸을 자신감으로 덮는다 |
이 표에서 제일 먼저 볼 것은 쓰기 권한이다. 읽기만 하는 에이전트와 파일을 수정하는 에이전트는 완전히 다른 존재다. 읽기 전용 시장 리서처는 틀려도 사람이 고치면 된다. 하지만 장부 대사 에이전트가 원본 파일을 바꾸고, 그 변경이 로그 없이 흘러가면 얘기가 달라진다.
두 번째는 승인 게이트다. 앤트로픽 공식 설명도 사용자가 검토하고 승인하는 루프를 강조한다. 실무에서는 이 문장을 운영 규칙으로 번역해야 한다. “모델이 만들었다”와 “팀이 승인했다” 사이에 체크박스, 담당자, 시간, 파일 버전이 있어야 한다.
세 번째는 출처 연결이다. 금융 업무에서 요약이 빠른 것보다 숫자가 어디서 왔는지가 더 중요하다. FactSet, S&P Capital IQ, PitchBook, Morningstar 같은 데이터 커넥터를 붙인다고 해도, 최종 산출물에 원천 링크나 파일 참조가 사라지면 신뢰도는 바로 떨어진다.
Before / After로 보면 뭐가 달라지나
도입 전에는 사람이 자료를 모으고, Excel 모델을 고치고, PowerPoint로 옮기고, Word나 Outlook에서 메모를 다시 쓴다. 이 과정에서 같은 숫자를 여러 번 복사한다. 복사 자체가 일이 아니라, 복사하면서 맥락이 새는 게 문제다.
도입 후 기대되는 흐름은 다르다. 모델 작업은 Excel에서 시작하고, 그 맥락이 PowerPoint의 피치북으로 이어지며, Word의 메모나 Outlook 초안까지 연결된다. 앤트로픽이 강조한 지점도 이 맥락 이동이다. 앱 사이를 이동할 때 매번 다시 설명하지 않아도 되는 구조를 지향한다.
하지만 이 변화는 장점과 위험을 동시에 만든다. 맥락이 잘 이어지면 반복 설명이 줄어든다. 반대로 잘못된 맥락도 더 오래 살아남을 수 있다. 에이전트가 처음에 틀린 가정을 잡았는데 Excel, PowerPoint, Word까지 그 가정이 같이 따라가면 전체 문서 세트가 한 번에 기울어진다.
그래서 After 구조에서는 중간 검수 지점이 더 중요해진다. Excel 모델이 PowerPoint로 넘어가기 전에 숫자 기준을 확인하고, PowerPoint가 고객용 문서가 되기 전에 메시지와 리스크 문구를 확인하고, Outlook 초안이 보내지기 전에 수신자와 첨부 파일을 확인해야 한다. 자동화는 단계를 없애는 게 아니라, 사람이 봐야 할 단계를 더 선명하게 만드는 쪽이 안전하다.
비용보다 먼저 볼 권한 설계
팀이 이런 템플릿을 보면 보통 비용부터 묻는다. 몇 명 좌석이 필요한지, API 사용량이 얼마나 나오는지, Managed Agents가 더 비싼지 같은 질문이다. 물론 중요하다. 하지만 금융 업무에서는 비용보다 권한 설계가 먼저다.
첫 번째 원칙은 읽기 권한과 쓰기 권한을 분리하는 것이다. 시장 리서치, 실적 리뷰, 피치북 초안은 read-only로 시작해도 충분하다. 원본 파일 수정, CRM 업데이트, 이메일 발송, 회계 반영은 별도 승인 뒤에만 허용해야 한다.
두 번째 원칙은 커넥터별 데이터 범위를 좁히는 것이다. 모든 데이터 소스를 한 번에 열어두면 에이전트는 편해진다. 하지만 감사와 보안은 불편해진다. 특정 업무에는 특정 데이터만 열어야 한다. 피치북 작성용 데이터와 KYC 검토용 데이터는 섞이지 않는 편이 좋다.
세 번째 원칙은 사람의 승인 로그를 남기는 것이다. “내가 봤다”가 아니라 누가, 언제, 어떤 파일 버전을 승인했는지 남겨야 한다. 나중에 문제가 생겼을 때 로그가 없으면 대화방 기억력으로 회계 감사를 하는 상황이 된다. 그건 좀 공포 영화다. 팝콘도 맛없다.
실패 사례를 미리 상상하면
실패 1은 낡은 데이터로 만든 피치북이다. 커넥터가 붙어 있어도 데이터 기준일이 섞이면 문서가 그럴듯하게 틀릴 수 있다. 그래서 모든 표에는 데이터 기준일과 원천이 붙어야 한다.
실패 2는 Excel 수식 드리프트다. 에이전트가 모델을 고치면서 한 시트의 수식 범위만 바꾸고, 연결된 시트는 그대로 두면 숫자가 조용히 틀어진다. 이런 문제는 문장형 검수보다 셀 단위 검증과 변경 diff가 필요하다.
실패 3은 KYC 예외를 자동 통과시키는 것이다. KYC screener는 파일을 모으고 누락을 찾는 데 도움을 줄 수 있다. 하지만 승인 자체를 자동화하면 책임 경계가 흐려진다. 특히 불확실하거나 자료가 충돌하는 건 에이전트가 더 자신 있게 말하게 두면 안 된다. 그럴 땐 멈추고 올려야 한다.
실패 4는 고객 제출 전 승인 누락이다. 피치북이나 커버 메모는 내부 초안과 외부 제출본의 경계가 분명해야 한다. 에이전트가 만든 문서는 기본적으로 초안이어야 하고, 최종본이 되려면 사람 이름과 승인 시간이 붙어야 한다.
실패 5는 감사 로그가 빈약한 것이다. Managed Agents나 플러그인 구조가 아무리 좋아도, 우리 팀이 어떤 권한으로 어떤 도구를 호출했는지 남기지 않으면 운영 실패다. 에이전트 운영에서 로그는 장식이 아니라 안전벨트다. 안전벨트가 멋은 없어도, 사고 났을 때는 갑자기 주인공이 된다.
작은 팀이 따라 한다면 이렇게 시작
1단계는 한 업무를 고르는 것이다. “우리도 금융 AI 에이전트 하자”가 아니라 “이번 달 실적 발표 10개를 읽고 변경점 표를 만들자”처럼 좁혀야 한다. 범위가 좁아야 권한도 좁아진다.
2단계는 read-only로만 시작하는 것이다. 에이전트가 파일을 읽고 요약하고 표를 만들 수는 있지만, 원본 파일이나 고객 제출용 문서는 바꾸지 못하게 한다. 처음부터 쓰기 권한을 주면 문제가 생겼을 때 어디서 잘못됐는지 찾기가 어렵다.
3단계는 출처와 기준일을 강제하는 것이다. 모든 숫자 옆에는 원천 파일, 데이터 공급자, 기준일이 붙어야 한다. 이 규칙을 지키지 못한 산출물은 품질이 낮은 게 아니라 제출 불가로 처리하는 편이 낫다.
4단계는 사람 승인 문장을 정하는 것이다. 예를 들어 “이 문서를 고객에게 보낼 수 있음”과 “내부 검토용 초안으로만 사용”은 완전히 다르다. 승인 문구가 모호하면 운영도 모호해진다. 모호한 자동화는 항상 자신감 있게 사고 친다. 자신감이 죄는 아닌데, 로그 없는 자신감은 위험하다.
5단계는 회고 루프를 만든다. 에이전트가 줄인 시간, 사람이 고친 오류, 중단된 케이스, 승인 누락 위험을 주간 단위로 기록한다. 성공 사례만 모으면 도입 보고서는 예뻐진다. 실패 사례까지 모아야 운영이 좋아진다.
관련 글
- Claude 2026 업데이트는 챗봇보다 작업 OS에 가깝다 – Claude를 앱이 아니라 작업 OS로 볼 때의 큰 흐름입니다.
- Claude Cowork 2026 권한·검수 루프 체크리스트 – 데스크톱에서 직접 움직이는 에이전트 권한 경계를 다룹니다.
- Claude Code subagents는 언제 켜고 언제 메인 세션으로 끝내야 할까 – 하위 에이전트를 쪼개는 기준과 context bloat를 같이 봅니다.
FAQ
앤트로픽 금융 Claude 에이전트는 일반 개인 투자자용인가
주요 대상은 금융기관, 자산운용사, 보험사, 회계·운영팀에 가깝다. 개인 투자자가 참고할 수는 있지만, 공식 템플릿의 강점은 데이터 커넥터, 권한, 감사 로그, Microsoft 365 업무 흐름과 묶일 때 나온다. 개인 투자자라면 매수·매도 자동화보다 리서치 요약과 체크리스트 생성부터 보는 편이 안전하다.
Claude Code에서도 금융 에이전트 템플릿을 쓸 수 있나
공식 발표 기준으로 템플릿은 Claude Cowork와 Claude Code의 플러그인으로 제공되고, Managed Agents용 cookbook 형태도 제공된다. 다만 실사용 가능 범위는 플랜, 조직 설정, 커넥터 접근 권한, 내부 보안 정책에 따라 달라질 수 있다.
피치북이나 월말 결산을 바로 자동화해도 되나
바로 최종 제출까지 맡기는 것은 위험하다. 첫 단계는 초안 생성, 누락 확인, 출처 연결, 검토 표 작성처럼 사람이 승인하기 쉬운 업무가 낫다. 고객 제출, 장부 반영, KYC 승인 같은 결정은 별도 승인 게이트를 둬야 한다.
가장 먼저 도입하기 좋은 업무는 무엇인가
시장 리서치 요약, 실적 발표 리뷰, 미팅 준비 메모처럼 read-only로 시작할 수 있는 업무가 좋다. 월말 결산이나 KYC는 효율 효과가 커 보이지만, 권한과 책임 경계가 복잡해서 검증 루프를 먼저 세운 뒤 들어가는 편이 낫다.
기존 RPA나 매크로와 무엇이 다른가
RPA는 정해진 화면과 규칙을 반복하는 데 강하다. Claude 에이전트 템플릿은 문서, 모델, 커넥터, 하위 에이전트, 승인 루프를 묶어 더 유연한 업무를 다룬다. 대신 유연한 만큼 검증과 로그가 더 중요하다. 똑똑한 도구일수록 안전장치도 같이 똑똑해야 한다.
공식 출처
- Anthropic, Agents for financial services, 2026-05-05
- Anthropic, Claude for Financial Services
- Anthropic financial services marketplace repository
- 내부 캡처 노트:
00.Inbox/260511_[요약] 1 앤트로픽이 금융 실무용 Claude 에이전트 템플릿을 공개했습니다. 기업가치 평가, 피칭 자료, 월말 결산에 쓰이며....md
마무리
이번 앤트로픽 금융 Claude 에이전트 발표는 “AI가 금융 업무를 다 한다”보다 “금융 업무를 에이전트 운영 단위로 포장하기 시작했다”에 가깝다. 그래서 실무자는 모델 이름보다 템플릿 안의 경계를 봐야 한다.
skills는 업무 지식이고, connectors는 데이터 접근이고, subagents는 역할 분담이다. 여기에 권한, 승인, 로그가 붙어야 금융 업무에서 쓸 수 있다. 반대로 이 네 가지가 빠지면 그냥 멋진 자동완성이다. 멋진 자동완성도 좋지만, 결산 파일 앞에서는 멋보다 추적 가능성이 이긴다.