[심층분석] 앤트로픽이 월스트리트 애널리스트의 하루를 코드로 옮겼다: financial-services 저장소 해부

들어가며: AI 회사가 왜 금융 워크플로우를 직접 코드로 만들었을까

지난 몇 년 동안 AI 업계의 큰 흐름 중 하나는 “범용 모델에서 특정 업무를 대신 해주는 에이전트로”였어요. 처음에는 챗봇에게 질문하고 답을 받는 정도였다면, 이제는 AI가 파일을 열고, 데이터를 가져오고, 여러 단계를 거쳐 결과물을 만들어내는 단계까지 왔거든요.

그런데 금융권은 조금 특별한 동네예요. 투자은행의 주니어 애널리스트가 밤새 엑셀로 밸류에이션 모델을 만들고 파워포인트로 피치 덱을 다듬는 문화가 수십 년째 이어지고 있어요. 이 일들은 반복적이면서도 정확성이 생명이라서, AI로 자동화하기 딱 좋으면서 동시에 잘못하면 큰일 나는 영역이죠.

앤트로픽이 공개한 financial-services 저장소는 바로 이 지점을 노린 거예요. “Claude for Financial Services”라는 이름으로 투자은행(IB), 주식 리서치, 사모펀드(PE), 자산관리(WM) 네 분야에서 자주 보이는 워크플로우를 에이전트, 스킬, 데이터 커넥터 형태로 묶어 공개했어요. 한마디로 “우리가 금융권 고객한테서 가장 많이 본 업무 패턴을 코드로 옮겨놨으니 가져다 쓰세요”라는 메시지예요.

이 저장소가 흥미로운 이유는 금융 도메인 자체보다, 앤트로픽이 “실무용 AI 에이전트를 어떻게 패키징하는가”에 대한 모범 답안을 보여주기 때문이에요. 금융권이 아니어도 우리 회사 업무를 에이전트로 만들 때 참고할 게 정말 많거든요.

저장소 구조: 에이전트, 스킬, 커넥터의 3층 구조

저장소를 열어보면 크게 두 종류의 산출물이 있어요. 에이전트(Agents)와 버티컬 플러그인(Vertical plugins)이에요. 먼저 용어부터 정리할게요.

• 스킬(Skill): 이게 뭐냐면, AI에게 “이 일은 이렇게 하는 거야”라고 알려주는 업무 매뉴얼이에요. DCF 밸류에이션을 어떤 순서로, 어떤 가정을 세워서 하는지 같은 절차와 지식을 파일로 정리해둔 거예요. 신입 사원에게 주는 업무 가이드 문서 같은 거죠.
• 슬래시 커맨드(Slash command): /comps, /dcf, /earnings처럼 슬래시로 시작하는 짧은 명령어예요. 슬랙에서 /remind 치는 것처럼, 복잡한 작업을 한 단어로 호출하는 단축키라고 생각하면 돼요.
• 데이터 커넥터(Data connector): AI가 시장 데이터, 공시 자료, 사내 시스템 같은 외부 데이터에 접근하게 해주는 연결 통로예요. 콘센트에 꽂는 플러그 같은 거예요.
• 에이전트(Agent): 위 세 가지를 조합해서 하나의 업무를 처음부터 끝까지 수행하는 완성품이에요. AI의 역할과 규칙을 정의한 시스템 프롬프트까지 포함돼 있어요.

레고에 비유하면 스킬과 커넥터는 개별 블록, 버티컬 플러그인은 분야별로 블록을 모아둔 세트, 에이전트는 그 세트로 조립해놓은 완성품이에요. 완성품이 마음에 들면 그대로 쓰고, 아니면 블록을 빼서 내 방식대로 다시 조립하면 되는 거죠.

에이전트 목록: 애널리스트의 하루를 그대로 옮겼다

README에 정리된 에이전트를 보면 실제 금융권 업무를 얼마나 세밀하게 관찰했는지 알 수 있어요.

커버리지 & 자문

• Pitch Agent: 비교기업 분석(Comps), 유사 거래 사례(Precedents), 차입매수 분석(LBO)을 돌려서 회사 브랜딩이 입혀진 피치 덱까지 한 번에 만들어줘요. 피치 덱은 투자은행이 고객사에게 “이 거래를 이렇게 진행하자”고 제안하는 발표 자료예요.
• Meeting Prep Agent: 고객 미팅 전에 브리핑 자료 패키지를 준비해줘요.

리서치 & 모델링

• Market Researcher: 섹터나 테마를 던져주면 산업 개요, 경쟁 구도, 동종 기업 비교, 투자 아이디어 후보 리스트까지 뽑아줘요.
• Earnings Reviewer: 실적 발표 콜과 공시 자료를 읽고, 재무 모델을 업데이트하고, 리서치 노트 초안까지 써줘요.
• Model Builder: 이름 그대로 재무 모델을 구축하는 에이전트예요.

그리고 GL Reconciler도 있어요. GL은 총계정원장(General Ledger)인데, 회사의 모든 거래가 기록되는 회계 장부예요. 이 장부와 은행 거래 내역 같은 외부 기록이 맞는지 대조하는 작업을 “대사(Reconciliation)”라고 하는데, 그걸 해주는 거예요. 카드 명세서와 가계부를 맞춰보는 일의 기업 버전이라고 보면 돼요.

여기서 재미있는 설계 포인트가 하나 있어요. 각 에이전트 플러그인이 자기가 쓰는 스킬을 통째로 번들링하고 있어서, 에이전트 하나만 설치하면 다른 건 필요 없다는 거예요. 의존성 지옥 없이 “이거 하나만 깔면 돼”를 보장한 거죠.

설계 철학 1: 한 소스, 두 배포 경로

이 저장소에서 가장 눈여겨볼 아키텍처 결정은 “같은 소스에서 두 가지 방식으로 쓸 수 있다”는 거예요.

1. Claude Cowork 플러그인으로 설치: 애널리스트가 자기 데스크톱 업무 환경에서 바로 에이전트를 불러 쓰는 방식이에요.
2. Claude Managed Agents API로 배포: 회사가 이미 갖고 있는 워크플로우 엔진(업무 자동화 시스템) 뒤에 에이전트를 붙이는 방식이에요. /v1/agents 엔드포인트로 에이전트 템플릿을 올리면 서버에서 돌아가요.

Managed Agents가 뭐냐면, 쉽게 말해 “AI 에이전트 호스팅 서비스”예요. 에이전트를 직접 만들면 대화 상태 관리, 도구 실행, 에러 처리, 재시도 같은 인프라 코드를 다 짜야 하거든요. Managed Agents는 그 귀찮은 부분을 앤트로픽 서버가 맡고, 개발자는 “어떤 역할의 에이전트가 어떤 스킬을 쓰는지”만 정의해서 올리면 돼요. 직접 서버를 세팅하는 대신 클라우드 함수를 쓰는 것과 비슷한 편의성이에요.

중요한 건 두 경로가 같은 시스템 프롬프트와 같은 스킬을 쓴다는 점이에요. 데스크톱에서 테스트해본 에이전트가 회사 시스템에 배포돼도 똑같이 동작한다는 뜻이거든요. “내 컴퓨터에서는 되는데요”라는 고전적인 문제를 설계 단계에서 막은 거예요.

저장소에 managed-agent-cookbooks 폴더가 따로 있는 것도 이 때문이에요. 쿡북은 요리책처럼 “이렇게 하면 이 결과가 나와요”를 단계별로 보여주는 예제 모음이에요. claude-for-msft-365-install 폴더는 마이크로소프트 365 환경에 연결해 쓰는 설치 가이드로 보이는데, 금융권이 엑셀과 파워포인트 없이는 돌아가지 않는 곳이라는 걸 정확히 알고 있는 거죠.

설계 철학 2: 모든 결과물은 사람의 서명을 기다린다

README 맨 위에 굵직한 경고문이 있어요. 요약하면 이래요.

> 이 저장소의 어떤 것도 투자, 법률, 세무, 회계 자문이 아닙니다. 에이전트는 모델, 메모, 리서치 노트, 대사 결과 같은 애널리스트 작업물의 초안을 만들며, 자격을 갖춘 전문가의 검토를 위한 것입니다. 투자 추천, 거래 실행, 리스크 확정, 장부 기장, 고객 온보딩 승인은 하지 않습니다. 모든 결과물은 사람의 최종 승인을 위해 대기 상태로 놓입니다.

이걸 그냥 법적 면책 문구로 넘기면 안 돼요. 이건 에이전트 설계의 경계선이거든요. 개발 용어로 바꾸면, 에이전트가 “쓰기 권한”을 갖는 범위를 명확히 제한한 거예요. 초안을 만드는 건 되지만, 실제로 돈이 움직이거나 법적 효력이 생기는 액션은 절대 자동으로 실행하지 않아요. 이걸 흔히 “휴먼 인 더 루프(Human-in-the-loop)”라고 부르는데, 사람이 반드시 결정 고리 안에 들어가 있는 구조라는 뜻이에요.

금융권에서 이건 선택이 아니라 필수예요. 규제 기관이 “AI가 자동으로 거래를 실행했다”는 상황을 용납하지 않을뿐더러, AI가 만든 숫자 하나 틀리면 수백억이 오갈 수 있으니까요. 그래서 이 저장소는 “AI가 사람을 대체한다”가 아니라 “AI가 밤새 초안을 만들어두면 사람이 아침에 검토하고 서명한다”는 모델을 코드로 구현한 거예요.

업계 맥락: 왜 레퍼런스 구현이 중요한가

이 저장소는 제품이라기보다 레퍼런스 구현(Reference implementation)에 가까워요. “이 기술을 이렇게 쓰는 게 정석이야”라고 보여주는 모범 예제라는 뜻이에요. 비슷한 접근을 다른 방식과 비교해볼게요.

• 전통 금융 데이터 터미널: 데이터와 도구를 폐쇄적으로 제공해요. 강력하지만 비싸고, 우리 회사 방식에 맞게 뜯어고치기 어려워요. 고급 식당 코스 요리 같은 거죠.
• 범용 LLM API를 직접 조합하는 방식: 자유도는 최고지만 밸류에이션 방법론, 규제 준수 같은 도메인 지식을 개발팀이 처음부터 다 넣어야 해요. 재료만 사다가 요리부터 배워야 하는 셈이에요.
• 이 저장소의 방식: 도메인 전문가가 검증한 레시피(스킬)와 반조리 식품(에이전트)을 오픈소스로 주고, 각 회사가 입맛대로 조정하게 해요. “밀키트” 모델이에요.

특히 주목할 점은 금융 도메인 지식 자체를 스킬 파일이라는 형태로 공개했다는 거예요. 지금까지 “AI가 DCF를 할 줄 안다”는 말은 모델이 학습 데이터에서 어렴풋이 배운 걸 의미했는데, 이제는 “이 절차대로 이 가정을 세워서 이 형식으로 출력해라”가 명시적인 파일로 존재하는 거죠. 암묵지가 형식지로 바뀐 거예요. 다른 산업에서도 그대로 따라 할 수 있는 패턴이에요.

한국 개발자에게 주는 시사점

금융권이나 핀테크에서 일하고 있다면

이 저장소를 그대로 가져와 쓰기보다는 구조를 참고하는 게 현실적이에요. 미국 공시 체계(SEC 파일링)와 한국 DART 공시는 형식이 다르고, 한국어 실적 자료도 다르니까요. 하지만 Earnings Reviewer의 “공시 읽기 → 모델 업데이트 → 노트 초안” 파이프라인은 그대로 유효해요. 데이터 커넥터만 DART API로 바꾸고, 스킬의 지시문을 한국 회계기준(K-IFRS)에 맞게 손보는 식으로 시작할 수 있어요.

금융과 상관없는 회사에서 일하고 있다면

오히려 이쪽이 더 배울 게 많아요. 여러분 회사에도 주간 리포트, 고객사 미팅 준비, 장애 회고 문서처럼 “매주 반복되는데 사람이 붙어서 문서를 만들어야 하는 업무”가 분명히 있을 거예요. 이 저장소의 패턴을 적용하면 이렇게 돼요.

1. 업무 절차를 스킬 파일(마크다운 형식의 매뉴얼)로 정리한다.
2. 필요한 데이터 소스를 커넥터로 연결한다.
3. 시스템 프롬프트에 “무엇을 하고, 무엇을 절대 하지 않는지”를 명확히 쓴다.
4. 결과물은 항상 초안 상태로 두고 사람이 승인하게 한다.
5. 로컬에서 테스트한 뒤 같은 정의를 서버로 올린다.

특히 4번은 꼭 가져가세요. 에이전트에게 실행 권한을 주는 건 나중에 언제든 할 수 있지만, 처음부터 자동 실행으로 만들었다가 사고가 나면 되돌리기 어렵거든요.

학습 로드맵

• 1단계: README와 CLAUDE.md를 읽으며 에이전트 하나가 어떤 파일들로 구성되는지 파악하세요. CLAUDE.md는 이 저장소에서 Claude가 작업할 때 따라야 할 규칙을 적어둔 파일이에요.
• 2단계: plugins 폴더에서 /comps 같은 슬래시 커맨드 하나를 골라 스킬 파일이 어떻게 쓰였는지 뜯어보세요. 금융 지식이 없어도 “지시문을 어떻게 구조화하는지”는 배울 수 있어요.
• 3단계: managed-agent-cookbooks의 예제를 따라 에이전트 하나를 API로 배포해보세요. 로컬 플러그인과 서버 배포가 같은 정의를 쓰는 걸 직접 확인하는 게 목표예요.
• 4단계: 내 업무 하나를 골라 같은 구조로 에이전트를 만들어보세요. 초안을 만드는 것까지만 해도 충분히 실용적이에요.

마무리: 에이전트는 이제 패키지가 된다

이 저장소가 시사하는 가장 큰 변화는, AI 에이전트가 프롬프트 한 줄이 아니라 설치하고 배포하고 버전 관리하는 소프트웨어 패키지가 됐다는 거예요. .github/workflows와 .githooks 폴더가 있다는 건 스킬과 에이전트 정의도 코드처럼 CI로 검증하고 커밋 훅으로 관리한다는 뜻이거든요. 프롬프트 엔지니어링이 소프트웨어 엔지니어링으로 흡수되는 순간이에요.

앞으로는 법률, 의료, 제조, 물류처럼 산업별로 이런 레퍼런스 저장소가 계속 나올 가능성이 높아요. 회사들은 그걸 포크해서 자기 방식으로 고쳐 쓰겠죠. 오픈소스 라이브러리 생태계가 그랬던 것처럼요.

여러분 회사에서는 어떤 업무가 가장 먼저 에이전트로 옮겨질 것 같나요? 그리고 그 에이전트에게 “초안 작성”까지만 허락할지, 실행 권한까지 줄지, 어디에 선을 그으실 건가요? 댓글로 여러분의 생각을 들려주세요.