재무 설계사들이 직접 에이전트를 만든 방법

URL: https://www.youtube.com/watch?v=gpmze-6ueGU 날짜: 2026-10-12 채널: aiDotEngineer 영상 길이: 8분 54초 원문 제목: We Let Our Financial Planners Write the Agents — Matthew Ragone, Range 출연: Matthew Ragone, Range 재무 설계사

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코드를 모르는 현업 전문가가 자신의 업무 판단과 안전장치를 스킬(skill)로 명시하면, 엔지니어링 조직에 의존하지 않고도 실제 업무를 수행하는 에이전트를 만들고 팀 전체에 배포할 수 있다.==

• 생산성의 병목은 타이핑 속도가 아니라 한 사람이 한 장소에만 있을 수 있다는 시간·동시성의 제약이다.
• 좋은 에이전트는 별도의 챗봇 창이 아니라 업무가 실제로 존재하는 곳에서 실행되며, 일반적인 금융 지식이 아니라 Range의 구체적인 업무 방식을 따라야 한다.
• 현업 전문가가 실제 사례를 설명하고, 질문·판단 기준·금지선을 스킬에 담은 뒤, 다섯 단계의 반복 검증과 소유권·리뷰어 체계로 운영해야 신뢰할 수 있다.

Range는 일체형 자산관리 회사이며 고객에게 나가는 결과물이 금융 조언인 규제 산업에 속한다. 따라서 에이전트는 현금흐름 분석이나 보험 분석의 초안을 만들 수 있지만, 고객에게 아무것도 직접 보내지 않는다. 모든 추천은 재무 설계사가 완전히 검토하고 조정한 후에만 전달된다. 핵심 변화는 사람의 판단을 없앤 것이 아니라, 사람이 다른 고객과 통화하는 동안 첫 번째 초안을 미리 만들어 두는 데 있다.

1. 배경: 챗봇 보조에서 비동기 업무 수행으로

재무 설계사들이 에이전트를 만들게 된 출발점은 거창한 자동화가 아니라, 고객 메시지를 조금 더 명확하고 친절하게 다듬어 달라고 챗봇에 붙여 넣는 일이었다. 그 방식은 몇 분을 절약했지만 사람이 하던 작업 전체를 그대로 남겼다.

1.1. 현업 전문가의 위치와 규제 환경

1. 업무의 중심은 금융 설계다

   1. 매튜 라고네는 엔지니어가 아니라 공인 재무 설계사(Certified Financial Planner)다.
   2. 평소 고객과 현금흐름(cash flow), 세금(taxes), 보험(insurance), 은퇴(retirement), 상속·유산(estate)을 상담한다.
   3. Range의 플래닝 팀에서 AI 도입을 이끄는 역할도 맡고 있다.

2. 결과물과 검토 절차에는 높은 책임이 따른다

   1. 업무가 규제 산업에서 이뤄지고, 산출물은 실제 고객에게 제공되는 금융 조언이다.
   2. 검토 단계는 선택 사항이 아니다.
   3. 플랫폼을 만든 사람의 관점이 아니라 플랫폼을 전달받아 업무에 쓰는 사람의 관점에서 구축 방식을 설명한다.
   4. 목적은 특정 공급업체를 홍보하는 것이 아니라 Range에서 실제로 작동한 방법을 재현할 수 있게 하는 것이다.

1.2. 진짜 병목: 빠른 작성이 아니라 동시성의 한계

1. 챗봇 사용만으로는 수동 작업이 남는다

   1. 고객 메시지를 챗봇에 넣고 더 명확하거나 친근하게 고쳐 달라고 요청하는 방식은 유용했다.
   2. 그러나 사람이 여전히 모든 작업을 수동으로 수행했고, 단지 약간 더 빠르게 수행했을 뿐이다.
   3. 타이핑 속도가 빨라져도 동시에 여러 고객의 일을 처리할 수는 없다.

2. 한 사람은 한 장소에만 있을 수 있다

   1. 설계사가 한 고객과 통화하는 동안 다른 고객의 플랜을 만들 수는 없다.
   2. “더 빨리 쓰기”는 이 제약을 해결하지 못한다.
   3. 해결책은 사람이 다른 곳에 있는 동안에도 작업이 진행되는 구조다.

3. 새로운 하루의 작업 흐름

   1. 설계사가 고객 한 명과 통화하는 동안 에이전트가 다른 고객의 전체 현금흐름 분석 초안을 작성한다.
   2. 보험 분석 초안도 같은 방식으로 미리 준비될 수 있다.
   3. 통화가 끝난 뒤 설계사는 초안을 열어 완전히 검토하고 필요한 부분을 수정한다.
   4. 검토를 마친 설계사가 고객에게 추천 내용을 보낸다.
   5. 에이전트는 어떤 내용도 직접 전송하지 않으며, 고객이 보는 모든 추천은 설계사의 최종 검토를 거친다.

2. 에이전트가 갖춰야 할 두 가지 조건과 ‘스킬’의 의미

좋은 프롬프트 하나만으로는 수동 업무를 비동기 업무로 바꿀 수 없다. 실행 위치와 조직 고유의 판단 방식이 함께 설계되어야 한다.

2.1. 업무가 사는 곳에서 실행하기

1. 복사·붙여넣기용 별도 채팅창의 한계

   1. 에이전트는 업무가 실제로 존재하는 시스템과 흐름 안에서 작동해야 한다.
   2. 설계사가 별도 채팅창으로 자료를 옮겨 넣고 결과를 다시 옮기는 구조라면 수동 작업과 맥락 전환이 남는다.
   3. 업무가 있는 곳에서 초안을 만들어야 사람이 다른 업무를 하는 동안에도 진행이 이어진다.

2. 비동기 초안의 역할

   1. 에이전트는 최종 판단자를 대체하지 않고 첫 번째 초안을 담당한다.
   2. 사람은 초안을 처음부터 작성하는 대신, 이미 준비된 분석을 검토·수정하는 데 시간을 쓴다.
   3. 이 구조는 책임을 제거하지 않으면서 한 사람이 실제로 처리할 수 있는 동시 작업량을 늘린다.

2.2. 일반 지식이 아니라 Range의 방식 가르치기

1. 모델의 일반 지식과 조직의 실무 방식은 다르다

   1. 모델은 금융 계획이 일반적으로 무엇인지 이미 알고 있을 수 있다.
   2. 그러나 Range가 무엇을 먼저 살피는지, 무엇을 항상 표시하는지, 특정 추천을 어떤 표현으로 전달하는지는 별도로 가르쳐야 한다.
   3. 조직의 특정 업무 한 조각을 수행하는 고유한 방식을 문서화해 에이전트가 따르게 만든 것이 스킬이다.

2. 스킬은 조직의 업무 레시피다

   1. 스킬은 단순한 단계 목록이 아니라 한 회사의 판단과 작업 순서를 재현하는 레시피다.
   2. Claude가 스킬을 익히면 정해진 명령에 따라 조직의 프로세스를 반복할 수 있다.
   3. 따라서 스킬의 품질은 코드를 썼는지가 아니라, 현업의 판단이 얼마나 구체적으로 기록됐는지에 달려 있다.

3. 코드 없이 에이전트를 만드는 다섯 단계

다섯 단계는 **선택하기(pick) → 가르치기(teach) → 포장하기(pack) → 테스트하기(test) → 배포하기(ship)**다. 각 단계에는 코드 작성이 필요하지 않지만, 실제 업무를 깊이 이해해야 한다. 업무를 수행하는 사람이 구축자이기도 해야 하는 이유가 여기에 있다.

3.1. 1단계 — 반복되는 워크플로를 고르기

1. 처음부터 가장 화려하고 복잡한 업무를 고르지 않는다

   1. 본능적으로 가장 오래 걸리고 가장 복잡한 업무를 자동화하고 싶어지지만, 시작점으로는 적합하지 않다.
   2. 매주 반복해서 수행하는 업무를 고른다.
   3. 무엇이 좋은 결과인지 이미 알고 있어야 한다.
   4. 나쁜 초안을 한눈에 발견할 수 있어야 한다.

2. 복잡도보다 수작업량을 기준으로 좁힌다

   1. 시작할 때는 가장 복잡하지 않은 워크플로 중에서 수작업이 많이 필요한 것을 권한다.
   2. Range에서는 현금흐름 분석과 보험 검토가 이 조건에 맞았다.
   3. 이 두 업무는 Range에서 수작업이 많이 필요하면서도 결과를 빠르게 판단할 수 있었다.

3. 선택 기준은 빈도와 평가 가능성이다

   1. 자신이 자주 수행하는 업무인지 확인한다.
   2. 결과가 좋은지 나쁜지 빠르게 평가할 수 있는지 확인한다.
   3. 결과를 빠르게 판단할 수 없다면 에이전트를 테스트할 수도, 신뢰할 수도 없다.

3.2. 2단계 — 실제 사례 여러 건으로 가르치기

1. 완료된 실제 고객 사례를 사용한다

   1. 이미 전달한 플랜에서 실제 고객 사례를 여러 건 가져온다.
   2. 각 사례의 작업을 시작부터 끝까지 순서대로 다시 살펴본다.
   3. 가상의 이상적인 사례가 아니라 실제로 처리했던 자료를 사용해야 예외와 판단의 흔적이 드러난다.

2. 행동보다 판단을 소리 내어 설명한다

   1. 단순히 “다음으로 과거 탭을 연다”고 말하는 데 그치지 않는다.
   2. 왜 그 탭을 여는지, 무엇을 찾고 있는지, 어떤 상황이면 멈춰 질문할지를 설명한다.
   3. 어디를 클릭하는지는 기록하기 쉽지만, 왜 그렇게 하는지에 대한 판단이 조직 고유의 업무를 만든다.
   4. 이 판단을 설명하는 과정이 일반적인 조언과 Range의 실제 업무를 가르는 핵심이다.

3. 질문해야 할 순간을 함께 가르친다

   1. 정보가 부족할 때 무엇을 더 확인할지 보여 준다.
   2. 확신한 척 진행하지 않고 사람에게 질문해야 하는 조건을 사례 안에서 드러낸다.
   3. 이러한 중단 조건이 나중에 스킬의 필수 질문으로 전환된다.

3.3. 3단계 — 스킬로 포장하기

1. 스킬은 절차 목록 이상의 것이다

   1. 작업을 어떤 순서로 수행하는지 적는 것만으로는 충분하지 않다.
   2. 순서만 적으면 에이전트가 독자적으로 계속 실행하는 자동화가 된다.
   3. 신뢰할 수 있는 스킬에는 시작 전 질문과 실행 한계가 함께 들어간다.

2. 시작 전에 반드시 물어야 할 질문을 정한다

   1. 에이전트가 일을 시작하려면 무엇을 알아야 하는지 적는다.
   2. 어떤 정보를 확인해야 하는지 적는다.
   3. 무엇을 추측하지 말고 사람에게 확인해야 하는지 적는다.
   4. 이 질문들은 누락된 맥락을 임의로 채우는 일을 막는다.

3. 절대로 혼자 하지 않을 일을 정한다

   1. 무엇을 스스로 수행하면 안 되는지 명시한다.
   2. Range에서 가장 중요한 제한은 고객에게 아무것도 직접 보내지 않는 것이다.
   3. 에이전트는 초안을 작성하고, 설계사가 보낼지 또는 수정할지 결정한다.
   4. 금융 조언의 최종 책임과 고객 커뮤니케이션은 사람에게 남는다.

4. 실행 가능성과 통제 가능성을 함께 확보한다

   1. 질문은 필요한 맥락이 확보된 뒤에만 실행되도록 한다.
   2. 제한은 자동화가 편리함을 이유로 책임 경계를 넘지 않도록 한다.
   3. 절차·질문·금지선을 함께 적으면 반복 가능성과 신뢰성을 동시에 얻는다.

3.4. 4단계 — 실제 사례에서 다섯~열 번 실행하기

1. 초기 버전을 곧바로 팀 전체에 공개하지 않는다

   1. 다른 사람이 보기 전에 실제 사례에서 다섯 번에서 열 번 실행한다.
   2. 이 단계는 가장 건너뛰고 싶어지는 단계지만, 스킬을 완성하는 데 필수다.
   3. 소수의 실제 실행이 수십 명에게 미완성 스킬을 배포한 뒤 생길 정리 작업보다 적은 비용으로 끝난다.

2. 각 실행에서 빠진 판단을 찾는다

   1. 모든 실행은 스킬이 아직 몰랐던 무언가를 가르친다.
   2. 예상하지 못한 엣지 케이스가 나타날 수 있다.
   3. 에이전트가 물어봤어야 하는 질문이 드러날 수 있다.
   4. 자신 있게 말했지만 틀린 지점도 발견될 수 있다.

3. 수정 후 저장하고 다시 실행한다

   1. 문제를 발견하면 스킬을 고친다.
   2. 수정한 스킬을 저장한다.
   3. 같은 실제 사례와 다른 실제 사례에서 반복해서 다시 실행한다.
   4. 반복 과정에서 초안 품질과 질문·제한의 정확도를 높인다.

3.5. 5단계 — 소유자와 리뷰어를 정해 배포하기

1. 소유자가 최신 상태를 유지한다

   1. 스킬마다 업데이트 책임자를 지정한다.
   2. Range의 업무 프로세스는 바뀔 수 있다.
   3. 세법과 세금 규정도 변할 수 있다.
   4. 3월에 맞았던 스킬이 12월에는 틀릴 수 있으므로 지속적인 관리가 필요하다.

2. 작성자와 다른 리뷰어를 둔다

   1. 팀이 의존하기 전에 리뷰어가 스킬을 확인한다.
   2. 리뷰어는 작성자와 다른 사람이어야 한다.
   3. 재무 플랜을 작성자가 혼자 채점하지 않는 것처럼, 스킬도 만든 사람이 혼자 승인하지 않는다.

3. 개인 단축키와 팀 기반 자산을 구분한다

   1. 혼자 쓰는 영리한 단축키에는 공식적인 책임 구조가 없어도 된다.
   2. 다른 15명, 20명, 100명이 의존하는 순간 누군가는 품질과 최신성에 책임져야 한다.
   3. 소유자와 리뷰어가 있는 운영 구조가 개인 실험을 팀이 쌓아 올릴 수 있는 자산으로 바꾼다.

4. 6개월 뒤의 조직적 결과

현업 전문가가 자신의 업무를 직접 스킬로 만들자 에이전트가 특정 업무에 맞게 정교해졌고, 별도의 하향식 명령 없이 다른 조직으로 퍼졌다.

4.1. 규모와 자발적 확산

1. 플래닝 팀에서 회사 전체로 확장됐다

   1. 시작 후 6개월 만에 회사 전체에 24개의 스킬이 생겼다.
   2. 그중 17개는 플래닝 영역에 속한다.
   3. 나머지 흐름은 세일즈, 프로덕트, 마케팅으로 확산됐다.

2. 공식적인 의무화 없이 퍼졌다

   1. 누군가 전사 메모를 보내 사용을 지시한 것이 아니다.
   2. 사람들이 재무 설계사들이 하는 일을 보고 각자 에이전트를 만들기 시작했다.
   3. 스킬은 개발자나 엔지니어가 아니라 설계사·마케터·세일즈 담당자가 작성하고 유지한다.

4.2. 전문성의 세분화와 자연스러운 동료 리뷰

1. 가장 잘 아는 사람이 해당 스킬을 만든다

   1. 보험을 가장 잘 아는 사람이 보험 스킬을 만든다.
   2. 세금 코드와 세법을 가장 잘 아는 사람이 세금 스킬을 만든다.
   3. 도메인 전문가가 자신의 틈새 업무를 직접 구축하면서 스킬이 훨씬 구체적이 됐다.

2. 기존의 플랜 리뷰 습관이 스킬 리뷰로 이어졌다

   1. 재무 설계사들은 원래 서로의 플랜을 검토한다.
   2. 그 업무 습관이 스킬에도 자연스럽게 적용됐다.
   3. 새로 생긴 것은 리뷰 대상이지, 동료의 작업을 점검하는 문화 자체가 아니다.

5. 병목의 이동과 운영 거버넌스

모델이 초안을 만들 수 있는지는 더 이상 핵심 미해결 문제가 아니다. 이제 중요한 질문은 조직의 지식을 어떻게 명시하고 검증하며 책임질 것인지다.

5.1. 이미 해결된 질문과 새로 생긴 질문

1. 모델의 작성 능력은 확인됐다

   1. 모델이 현금흐름 분석 초안을 작성할 수 있는지는 이미 답이 나왔다.
   2. Range에서 실제 업무에 적용해 본 결과, 초안 작성 자체는 가능한 능력이다.

2. 조직이 답해야 할 질문이 남았다

   1. 회사가 업무를 수행하는 방식을 누가 문서로 남길 것인가.
   2. 스킬이 배포되기 전에 누가 테스트할 것인가.
   3. 15명의 다른 사람이 의존하게 된 뒤 누가 소유할 것인가.
   4. 에이전트를 엔지니어링 조직 바깥으로 확산하라는 요구를 받는 팀은 결국 이 질문들을 마주하게 된다.

5.2. 현업 주도 구축의 의미

1. 코드가 아니라 업무 이해가 핵심 자원이다

   1. 다섯 단계 어느 것도 코딩을 요구하지 않는다.
   2. 대신 업무를 실제로 수행하고 좋은 결과와 나쁜 결과를 판별할 수 있어야 한다.
   3. 현업 담당자가 직접 구축하면 일반론이 아니라 조직의 구체적인 판단이 들어간다.

2. 신뢰는 사람을 제거해서가 아니라 역할을 재배치해서 만든다

   1. 에이전트는 반복적인 첫 초안을 처리한다.
   2. 설계사는 엣지 케이스 판단, 품질 검토, 고객에게 보낼 최종 추천을 담당한다.
   3. 전송 권한을 사람에게 남기면 자동화의 속도와 규제 업무의 책임성을 함께 유지할 수 있다.

3. 현장 데이터는 아직 제한적이다

   1. 엔지니어링 조직 밖으로 에이전트를 확산한 사례에 관한 현장 데이터는 많지 않다.
   2. Range에서의 경험은 그 공백 속에서 실제로 적용해 본 구축·검증·운영 모델을 제공한다.

주요 발언 모음

“재무 설계사의 제약은 타이핑 속도가 아니었다. 한 번에 한 장소에만 있을 수 있다는 점이었다.”

“사람이 다른 곳에 있는 동안에도 일어나는 일이 그 문제를 해결한다.”

“에이전트는 아무것도 보내지 않는다. 고객이 보기 전에 설계사가 모든 추천을 하나씩 검토한다.”

“스킬은 우리 회사가 특정 업무를 수행하는 방식을 적어 에이전트가 따르게 만든 것이다.”

“단계를 쓰면 혼자 실행하는 것을 얻게 되지만, 질문과 한계를 쓰면 신뢰할 수 있는 것을 얻게 된다.”

“개인적인 영리한 단축키와 팀이 기반으로 삼을 수 있는 것의 차이는 책임성이다.”

“병목은 이동했다. 현금흐름 분석 초안을 만들 수 있는지는 이미 해결됐다.”

핵심 데이터 & 수치

• 영상 길이 534초: 약 8분 54초 동안 현업 전문가 주도의 에이전트 구축법을 설명한다.
• 다섯 단계: 반복 업무 선택, 실제 사례로 교육, 스킬로 포장, 실제 사례에서 테스트, 소유자·리뷰어와 배포의 순서다.
• 5~10회: 팀에 공개하기 전에 실제 사례에서 초기 스킬을 실행하고 수정해야 하는 권장 횟수다.
• 6개월: 도입 후 회사 전체에 24개의 스킬이 생긴 시점이다.
• 24개: Range 전체에 구축된 스킬 수다.
• 17개: 24개 중 플래닝 영역에 속한 스킬 수다.
• 15·20·100명: 미완성 스킬을 팀에 배포했을 때 생길 수 있는 의존 규모의 예시이며, 소수의 사전 테스트가 대규모 사후 정리보다 싸다는 점을 강조한다.
• 3월과 12월: 프로세스와 세법 변화 때문에 3월에 옳았던 스킬이 12월에는 틀릴 수 있다는 유지보수 예시다.

결론 및 시사점

1. 자동화의 첫 후보는 가장 복잡한 업무가 아니라 자주 반복되고 품질을 빠르게 판별할 수 있으며 수작업량이 큰 업무다.
2. 현업 전문가가 실제 사례를 처음부터 끝까지 설명하면서 “무엇을 하는가”뿐 아니라 “왜 하는가”와 “언제 멈춰 질문하는가”를 기록해야 조직 고유의 스킬이 만들어진다.
3. 스킬에는 절차와 함께 시작 전 필수 질문, 추측 금지 조건, 절대로 혼자 수행하지 않을 행동을 명시해야 한다.
4. 금융 조언처럼 위험도가 높은 업무에서 에이전트의 역할은 초안 작성까지로 제한하고, 사람의 완전한 검토와 고객 전송 결정을 필수로 남겨야 한다.
5. 실제 사례 5~10회 반복 테스트로 엣지 케이스와 과신 오류를 찾아 수정한 뒤에야 팀에 공개해야 한다.
6. 배포된 스킬에는 작성자와 별도의 리뷰어, 프로세스와 규정 변화를 반영할 소유자가 필요하다.
7. 도메인 전문가가 직접 만든 스킬은 일반적인 모델 지식보다 조직의 업무 방식과 판단 기준을 훨씬 구체적으로 반영한다.
8. 현업 주도 에이전트 확산의 핵심 과제는 모델 능력 증명이 아니라 지식의 문서화, 사전 테스트, 지속적인 소유권과 책임성 확보다.
9. Range의 사례는 코드를 모르는 설계사·마케터·세일즈 담당자도 업무를 깊이 이해한다면 팀이 의존할 수 있는 에이전트를 만들 수 있음을 보여 준다.
10. 문의 연락처는 mattrange.com이다.