Claude 금융 에이전트 권한·감사로그 체크리스트 2026 – Excel·PitchBook·KYC 붙이기 전

Anthropic은 2026년 5월 5일 금융 서비스용 Claude 에이전트 템플릿 10개와 Microsoft 365 애드인을 발표했다. 발표 내용은 pitchbook 작성, KYC 파일 검토, 월말 결산 같은 금융 업무를 며칠 단위로 배치할 수 있다는 쪽에 가깝고, Excel, PowerPoint, Word, Outlook 예정, 데이터 커넥터, MCP 앱을 함께 묶는다.

좋은 소식처럼 보이지만 운영팀이 먼저 봐야 할 단어는 “에이전트”보다 “권한”이다. 금융 업무에서 에이전트가 Excel을 읽고, PitchBook 같은 외부 데이터에 접근하고, KYC 문서를 요약하고, 내부 리서치 저장소를 훑는 순간부터 질문은 생산성이 아니라 통제 가능성으로 바뀐다.

이 글은 Claude 금융 에이전트 발표를 기능 목록으로 다시 쓰는 글이 아니다. 실제 도입 검토 표를 만든다면 어떤 권한을 읽기 전용으로 둘지, 어떤 쓰기 액션은 승인 게이트 뒤에 둘지, 감사로그로 무엇을 재현할 수 있어야 하는지를 먼저 정리하는 글이다.

핵심은 단순하다. 금융 에이전트는 “잘 대답하는 모델”이 아니라 “데이터와 도구를 들고 움직이는 작업자”로 봐야 한다. 작업자라면 직무기술서, 접근권한, 승인권자, 로그 보존기간, 사고 시 재현 절차가 있어야 한다.

먼저 봐야 할 구조

Anthropic은 금융 에이전트 템플릿을 skills, connectors, subagents 조합으로 설명한다. skills는 업무 지식과 지시문, connectors는 관리된 데이터 접근, subagents는 비교군 선택이나 방법론 검토 같은 하위 작업을 맡는 추가 모델이라는 구도다.

이 구조를 운영 관점으로 바꾸면 표가 달라진다. skills는 “무엇을 할 수 있다고 가르쳤는가”, connectors는 “어디까지 볼 수 있는가”, subagents는 “누가 어떤 중간 판단을 남겼는가”로 번역된다.

금융권이나 핀테크 팀에서 이 표를 건너뛰면 나중에 사고 조사가 어려워진다. 결과물만 보면 깔끔한 pitchbook인데, 어느 커넥터에서 어떤 데이터를 읽었고, 어느 단계에서 KYC 플래그를 낮췄고, 누가 승인했는지 모르면 실무에서는 반쪽짜리 자동화다.

오픈소스 레포에서 봐야 할 3가지

이번 발표를 뉴스로만 보면 “Anthropic이 금융용 에이전트 10개를 냈다”에서 끝난다. 그런데 GitHub의 anthropics/financial-services 레포를 보면 더 중요한 신호가 보인다. 이건 단일 데모가 아니라 agent plugin, vertical plugin, MCP connector, managed-agent cookbook을 파일 구조로 쪼개 둔 레퍼런스에 가깝다.

첫 번째는 같은 에이전트를 두 가지 방식으로 돌린다는 점이다. 레포는 Claude Cowork 플러그인으로 설치하는 흐름과 Claude Managed Agents API 뒤에서 자체 워크플로 엔진으로 배포하는 흐름을 같이 둔다. 즉 “사용자 데스크톱 옆에서 보조하는 에이전트”와 “백그라운드에서 길게 도는 운영형 에이전트”가 같은 system prompt와 skills를 공유하는 구조다.

두 번째는 vertical plugin 구조다. financial-analysis core plugin에 comps, DCF, LBO, 3-statement, Excel audit 같은 기본 작업과 11개 데이터 커넥터가 모이고, investment-banking, equity-research, private-equity, wealth-management, fund-admin, operations 같은 세로 업무가 그 위에 얹힌다. 이 구조는 나중에 회사별 용어, 템플릿, 승인 정책을 어디에 넣어야 하는지 보여준다.

세 번째는 커넥터의 위치다. 레포는 Daloopa, Morningstar, S&P Global, FactSet, Moody’s, LSEG, PitchBook, Chronograph, Egnyte 같은 MCP provider를 financial-analysis core에 모아 둔다. 이 말은 실무 도입에서 “어떤 에이전트를 쓸까”보다 “어떤 데이터 접근을 공통 계층에 둘까”가 먼저라는 뜻이다.

그래서 이 레포를 볼 때는 별점 숫자나 에이전트 이름보다 폴더 구조를 먼저 보는 편이 좋다. plugins/agent-plugins는 업무 단위, plugins/vertical-plugins는 공통 스킬과 커넥터, managed-agent-cookbooks는 headless 배포 패턴이다. 금융 에이전트 도입 문서도 이 세 층을 그대로 옮겨서 써야 덜 꼬인다.

권한 표는 기능표보다 먼저 만든다

첫 번째 표는 기능표가 아니라 권한표여야 한다. “Excel에서 모델을 업데이트한다”가 아니라 “사용자가 이미 볼 수 있는 Excel 파일만 읽는가, 새 파일을 만들 수 있는가, 기존 모델을 덮어쓸 수 있는가, 외부 공유 링크를 만들 수 있는가”처럼 쪼개야 한다.

Claude의 Microsoft 365 커넥터 문서는 권한이 delegated permissions 방식이라고 설명한다. 쉽게 말하면 Claude가 사용자의 Microsoft 365 계정을 대신해 움직이며, 사용자가 원래 볼 수 있는 데이터 범위 안에서 접근한다는 구조다.

이 말은 편하지만 동시에 함정도 있다. 사용자가 이미 너무 넓은 SharePoint 권한을 갖고 있으면 에이전트도 그 넓은 세계를 볼 수 있다. 그래서 에이전트 도입은 AI 설정만 만지는 일이 아니라 기존 IAM, SharePoint 권한, 그룹 정책을 같이 청소하는 일이다.

Claude 커넥터 문서도 조직 Owner 또는 Primary Owner가 커넥터를 팀에 추가하고, 개별 사용자가 인증해 연결하는 흐름을 둔다. 또한 Team과 Enterprise 플랜 Owner는 연결된 서비스에서 어떤 액션을 허용할지 제한할 수 있다고 안내한다.

아래 표처럼 읽기와 쓰기를 나누면 도입 회의가 덜 흐려진다.

영역 기본 허용 승인 필요 차단 후보
Excel 모델 열람, 요약, 셀 참조 설명 새 시트 생성, 모델 복제, 수식 대량 수정 원본 모델 덮어쓰기, 외부 공유 링크 생성
PitchBook·시장 데이터 조회, 출처 포함 요약, 비교군 초안 비교군 확정, 밸류에이션 메모 반영 미검증 데이터를 최종 덱에 자동 삽입
KYC·고객 파일 문서 분류, 누락 항목 체크 위험등급 변경 제안, 추가자료 요청 초안 고객 상태 자동 승인, 제재 리스트 예외 처리
월말 결산 차이 항목 탐지, 설명 초안 조정분개 초안 생성 ERP 원장 직접 반영
리서치 저장소 내부 문서 검색, 출처 링크 외부 발송용 요약 생성 비공개 리서치 원문 외부 전송

이 표에서 중요한 것은 “AI가 똑똑한가”가 아니다. 같은 작업이라도 읽기, 초안, 승인, 실행이 다르고, 금융에서는 이 네 단계를 한 덩어리로 허용하면 통제 비용이 폭발한다.

감사로그는 예쁜 보관함이 아니라 재현 장치다

Claude Enterprise 감사로그 문서는 감사로그가 Enterprise 조직에서 제공되며, 조직 Owner와 Primary Owner가 최근 180일 로그를 내보낼 수 있다고 안내한다. 또한 Compliance API에서도 감사로그 이벤트를 사용할 수 있다고 설명한다.

여기서 바로 물어야 할 질문은 “로그가 있나요?”가 아니라 “이 로그만 보고 사건을 재현할 수 있나요?”다. 금융 에이전트 사고는 보통 결과물이 틀렸다보다, 어떤 데이터와 어떤 권한과 어떤 프롬프트 흐름으로 그 결과가 나왔는지 설명하지 못할 때 커진다.

Claude 감사로그 문서는 채팅과 프로젝트의 제목과 내용은 감사로그 내보내기에 포함되지 않고 고유 식별자만 내보내진다고 안내한다. 다만 Primary Owner는 데이터 내보내기를 통해 채팅 입력과 출력을 내보낼 수 있다는 설명도 붙어 있다.

이 구조는 로그 설계를 현실적으로 만들어야 한다는 뜻이다. 에이전트 실행 ID, 사용자 ID, 커넥터 이름, 요청 시각, 읽은 데이터 식별자, 승인 이벤트, 생성된 산출물 위치를 내부 운영 로그에 같이 남겨야 나중에 Claude 쪽 로그와 사내 로그를 맞출 수 있다.

OpenAI의 Codex 안전 운영 글도 비슷한 방향을 보여준다. 샌드박스, 승인 정책, 네트워크 정책, agent-aware telemetry를 조합해 에이전트가 무엇을 했고 왜 했는지 감사할 수 있게 만드는 접근이다.

금융 에이전트에도 같은 원칙이 필요하다. 모델 이름과 벤치마크 점수만 남기면 멋있지만, 감사팀이 보는 로그는 멋보다 재현성이 우선이다. 로그가 시를 쓰기 시작하면 회의실 온도가 내려간다.

Excel, PitchBook, KYC는 서로 다른 위험이다

Excel 업무는 겉으로는 사무 자동화처럼 보이지만 실제로는 숫자 모델 변경 위험이다. 금융 모델의 셀 하나가 바뀌면 밸류에이션, 투자 메모, 고객 설명자료까지 줄줄이 바뀔 수 있으므로 원본 모델 직접 수정은 승인 게이트 뒤에 두는 편이 낫다.

PitchBook이나 시장 데이터 커넥터는 출처와 라이선스 위험이 크다. 에이전트가 데이터 제공자의 정보를 읽고 요약할 수 있더라도, 그 요약을 외부 고객용 자료에 어떻게 인용하고 배포할 수 있는지는 별도 계약과 정책 문제다.

KYC는 더 민감하다. 고객 신원, 제재 리스트, 실소유자, 고위험 국가, 부정적 뉴스 같은 정보가 걸리기 때문에 “요약”과 “판정”을 분리해야 한다. 에이전트가 누락 항목을 찾아주는 것은 도움이 되지만, 고객 위험등급을 자동으로 낮추는 것은 완전히 다른 권한이다.

월말 결산이나 감사 검토도 마찬가지다. 차이 항목을 찾고 설명 초안을 만드는 것은 낮은 위험일 수 있지만, 조정분개를 ERP에 직접 반영하거나 감사 결론을 확정하는 것은 사람 승인 없이는 위험하다.

그래서 도입 초기는 “읽기 전용 + 초안 생성 + 사람 승인” 조합이 가장 안전하다. 생산성은 조금 덜 화려해 보여도, 조직이 첫 사고 없이 학습할 시간을 벌어준다.

도입 전 7문장 계약서

도입 문서는 길수록 안 읽힌다. 그래서 실제 회의에서는 아래 7문장만 먼저 합의해도 절반은 간다.

첫째, Claude 금융 에이전트는 사용자가 원래 접근 가능한 데이터만 읽는 것을 기본값으로 한다. 둘째, 원본 파일 수정, 외부 공유, 고객 상태 변경, ERP 반영은 승인 게이트가 없으면 실행하지 않는다.

셋째, 모든 실행은 사용자, 시간, 워크플로우, 커넥터, 산출물 위치를 남긴다. 넷째, 감사로그와 내부 로그를 대조할 수 있도록 에이전트 실행 ID를 산출물 제목이나 메타데이터에 보존한다.

다섯째, KYC와 컴플라이언스 영역에서는 에이전트 출력이 최종 판정이 아니라 검토 초안임을 화면과 문서에 표시한다. 여섯째, 데이터 보존기간과 삭제 정책은 Enterprise retention 설정과 사내 문서보존 규정 중 더 엄격한 쪽을 따른다.

일곱째, 첫 배포는 한 팀, 한 워크플로우, 읽기 전용 커넥터, 제한된 문서 저장소에서 시작한다. 이 문장 하나가 나중에 회고록 제목을 “우리가 어떻게 살았는가”에서 “작게 시작해서 잘 굴렸다”로 바꿔준다.

운영 체크리스트

실제 배포 전에는 아래 항목을 체크한다. 제품 데모가 끝난 뒤 바로 전사 배포로 뛰면 신나 보이지만, 금융 데이터 세계에서 신남은 대체로 로그가 식은 뒤 청구서로 돌아온다.

체크 항목 확인 질문 통과 기준
역할 Owner, Admin, User, Custom role이 분리됐나 커넥터 추가와 로그 내보내기는 Owner 계정으로 제한
커넥터 조직 단위 enable과 개인 인증이 분리됐나 사용자가 개별 인증해야 하며 불필요한 커넥터는 비활성
쓰기 액션 읽기, 초안, 수정, 실행이 분리됐나 원본 변경과 외부 전송은 승인 필요
감사로그 누가 무엇을 했는지 재현 가능한가 180일 로그, Compliance API, 내부 실행 ID 매핑
데이터 보존 대화·프로젝트 보존기간이 정해졌나 Enterprise retention과 사내 보존정책 충돌 없음
KYC 판정 AI 출력이 최종 판단으로 오해되지 않나 화면·문서에 검토 초안 표시, 사람 승인 필수
사고 대응 잘못된 산출물을 추적할 수 있나 산출물 저장소, 실행 ID, 사용자, 입력 데이터가 연결

이 표를 통과한 뒤에야 모델 성능을 이야기하는 편이 좋다. Claude Opus 4.7이 금융 벤치마크에서 높게 나왔다는 발표는 흥미롭지만, 운영 환경에서는 높은 점수보다 낮은 권한이 사고를 더 많이 막는다.

FAQ

Q. Claude 금융 에이전트는 바로 실무에 넣어도 되나요? A. 바로 전사 배포하기보다 한 팀, 한 업무, 읽기 전용 커넥터부터 시작하는 편이 낫다. 특히 KYC, 결산, 고객 자료처럼 규제와 감사가 붙는 업무는 사람 승인 게이트를 먼저 설계해야 한다.

Q. 감사로그만 켜면 충분한가요? A. 부족하다. 감사로그는 중요하지만, 내부 실행 ID, 산출물 위치, 승인 이벤트, 커넥터 접근 기록을 함께 남겨야 실제 사고 조사에서 흐름을 재현할 수 있다.

Q. Microsoft 365 커넥터는 안전한가요? A. Claude 문서는 Microsoft 365 커넥터가 delegated permissions 방식으로 사용자가 이미 권한을 가진 데이터에 접근한다고 설명한다. 따라서 안전성은 커넥터 설정뿐 아니라 기존 Microsoft 365 권한 설계와도 연결된다.

Q. KYC 업무에서 AI가 최종 판단을 해도 되나요? A. 보수적으로는 안 된다. 에이전트는 누락자료 탐지, 문서 요약, 위험 신호 표시 같은 보조 역할로 두고 최종 위험등급 변경과 승인에는 사람 검토를 붙이는 편이 안전하다.

공식 출처

관련 글