스프레드시트와의 대화를 멈추고, 신뢰할 수 있는 재무 분석을 만들자

URL: https://www.youtube.com/watch?v=e9-br9hveRI
날짜: 2026-10-18
채널: aiDotEngineer
원문 제목: Stop Chatting With Spreadsheets — Francesco Galletta & Felippe Felisola Caso, Monzo

메타데이터

• 영상 ID: e9-br9hveRI
• 원본 게시일: 2026-10-17
• 발표자: Francesco Galletta, Felippe Felisola Caso
• 소속: Monzo
• 분류: AI·LLM
• 영상 길이: 1시간 50분 34초

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

금융 분석을 에이전트에게 맡길 수 있으려면, 그럴듯한 답을 빠르게 내놓는 것만으로는 부족하다. 도메인 맥락을 함께 정의하고, 반복 계산을 결정론적으로 실행하며, 각 결론의 근거와 결정 주체를 추적하고, 독립적인 검증과 의미 있는 승인 지점을 하네스(harness)에 설계해야 한다.

• 모델과 사용자는 같은 용어를 써도 서로 다른 의미를 떠올릴 수 있다.
• LLM의 확률적 생성에 산술과 반복 업무를 맡기면 같은 입력에서 결과가 달라질 수 있다.
• 금융 데이터의 출처뿐 아니라 가정과 계산 과정, 계산 코드의 버전까지 추적해야 한다.
• AI가 실제 세계의 결과에 책임을 질 수 없으므로, 사용자는 중요한 결정과 결과를 통제할 수 있어야 한다.
• 검증은 책임을 다른 사람이나 다른 에이전트에게 넘기는 일이 아니라, 편향과 사각지대를 줄이는 독립적인 피드백 루프다.

재무 분석 하네스는 단순히 모델에 긴 지침을 붙이는 프롬프트가 아니다. 계획과 가정을 작은 결정 단위로 나누고, 코드와 테스트처럼 반복 가능한 부분은 코드로 고정하며, 불확실한 해석은 사람이 되돌아보고 수정할 수 있도록 기록하는 작업 환경이다. 신뢰는 모델의 능력을 믿으라고 요구해서 생기는 것이 아니라, 결과가 어떻게 만들어졌는지 확인하고 바꿀 수 있는 구조를 통해 쌓인다.

1. 출발점: 재무 분석의 병목은 속도가 아니라 신뢰다

1.1. 데이터 팀의 경험과 워크숍의 목적

1. 발표자들의 배경

   1. Francesco는 베네수엘라 출신으로 영국에서 약 7년을 보낸 뒤 마드리드로 이주했다. 금융 서비스 데이터 팀과 Nubank, Monzo에서 일했고, 도시마다 맛집을 찾아다니는 일을 좋아한다. 개인 시간에는 직접 무언가를 만들고 몰두하는 편이다.
   2. Felippe는 브라질 출신으로 영국으로 이주한 지 약 1년 반 됐다. 대학 전에는 하루 7시간씩 피아노를 연습했지만 전기공학을 전공했고, 우연히 Google Data Studio를 접하면서 데이터 분야에 들어왔다. 대시보드가 너무 길어 파피루스 두루마리처럼 스크롤해야 했던 시절을 농담으로 회상했다.
   3. Felippe는 스타트업과 소규모 팀, 스케일업을 거쳐 Nubank와 Monzo에서 일했다. 현재 Monzo에서 데이터 팀의 내부 생산성을 높이는 AI 기반 솔루션을 만들며, 업무 밖에서는 자연이나 실내 암벽 등반을 즐긴다.
   4. 두 사람은 금융 서비스 데이터 팀에서의 경험을 바탕으로 AI가 실제 업무에 주는 영향을 다룬다. Monzo에서 AI 도입은 토큰 사용량 극대화가 아니라 구체적인 사업 가치와 비용 대비 효과에 초점을 둔다. Monzo의 사내 에이전트 기능은 별도 세션에서 다룰 주제이며, 여기서 만드는 것은 Monzo 제품이나 공식 구현을 대표하지 않는 일반적인 실습 사례다.

2. 만들기보다 문제에 접근하는 방법이 어렵다

   1. 코드를 만들고 모델을 호출하는 일 자체는 점점 쉬워졌지만, 문제를 어떻게 정의하고 어떤 결정을 내려야 하는지 모르면 시행착오의 무작위성에 의존하게 된다.
   2. 사용자가 이미 Claude나 ChatGPT로 백그라운드 작업을 돌릴 수 있다면 처리 속도는 핵심 병목이 아니다. 더 중요한 병목은 결과와 사용자를 잇는 연결, 즉 결과를 믿어도 되는지 판단할 수 있는가다.
   3. 금융은 개인의 숫자, 전략, 예산, 지식과 잘못된 통념이 함께 얽힌 맞춤형 영역이다. 투자회사 리서치부터 개인 예산과 재무 계획까지 금융 분석의 범위는 넓다.
   4. 결혼 비용처럼 사소해 보이는 문제도 고정비, 변동비, 시점, 불확실한 인원 수가 얽히면 단순 계산으로 끝나지 않는다. 돈은 이해관계가 크므로 투명성과 신뢰를 시스템에 내장해야 한다.

1.2. 신뢰를 위한 다섯 가지 설계 원칙

1. 신뢰 관련 도구는 부품이고, 원칙이 설계의 기준이다

   1. 트레이스(trace), 유닛 테스트(unit test), 계획, 평가(evaluation), 관측성(observability), 루프와 그래프는 모두 도움이 되지만, 그것만 나열한다고 신뢰가 완성되지는 않는다.
   2. 목표는 특정 제품이나 기술의 설명서를 따르는 것이 아니라, 돈과 관련된 문제를 맡길 만큼 신뢰할 수 있는 시스템의 설계 원칙을 정하는 것이다.
   3. 워크숍의 간단한 프로토타입은 완성된 UI나 프로덕션 제품이 아니다. 응답이 즉각적이고 인터페이스가 매끄러운지보다, 신뢰를 구축하는 장치가 실제 사용에서 어떤 느낌을 주는지 살펴보는 데 목적이 있다.

2. 다섯 원칙은 서로의 토대가 된다

   1. 공유 도메인(shared domain): 사용자가 뜻하는 용어와 모델이 이해한 용어, 계획과 가정을 맞춘다.
   2. 일관성(consistency): 계산과 반복 가능한 실행을 코드, 도구 호출, 테스트로 고정해 같은 입력에 안정된 결과를 낸다.
   3. 증거(evidence): 어떤 정보와 계산이 결론을 만들었는지 출처와 흔적을 남긴다.
   4. 책임성(accountability): 중요한 결정의 주체와 승인 지점을 명확히 하고, 사용자가 결과에 대한 책임을 질 수 있게 한다.
   5. 검증(verification): 독립적인 관점과 외부 기준점을 넣어 편향과 사각지대를 찾는다.
   6. 순서는 중요하다. 공유된 맥락이 계획을 만들고, 계획의 결정론적 부분이 일관된 코드가 되며, 코드와 입력의 흔적이 증거가 된다. 증거를 토대로 사람은 책임을 지고, 별도 검증을 통해 자신의 판단까지 되돌아볼 수 있다.

3. 신뢰는 한 번에 완성되지 않는다

   1. 결과를 확인할 수 없으면 사용자는 문제를 던져 놓고 해결을 바라는 블랙박스를 받는다. 그 대신 사람과 함께 진화하고, 막힌 지점을 수정하며, 실패에서 학습하는 시스템을 만들어야 한다.
   2. “에이전트 100개를 넣으면 해결된다”는 식의 규모 확대가 신뢰를 대신하지 않는다. 반복되는 업무 경험과 외부 사례를 반영해 결과가 올바르게 보일 뿐 아니라 실제로 제대로 진행되고 있다는 확신을 줘야 한다.
   3. 다섯 원칙은 모든 상황을 해결하는 만능 공식이나 유일한 모델이 아니다. 위험과 사용 사례에 맞춰 무엇을 적용할지 설계해야 한다.

1.3. 결혼식 예산이라는 실습 사례

1. 농담으로 드러난 실제 복잡성

   1. 참석자들에게 결혼 경험과 하객 수를 묻고, 50명 미만·약 100명·150명·200명 규모의 경험을 손들기로 확인한다. 결혼식은 계산이 단순하고 절차도 매끄러울 것 같지만, 실제 예산을 짜고 비용이 빨리 늘어난 이유를 알아내기는 어렵다는 농담으로 문제를 연다.
   2. 약혼자가 말한 저녁 식사 1인당 비용만 계산하면 끝날 것 같지만, 그 위에 변동 비용 두 가지가 더 있어 최종 비용은 달라진다. 결혼 예산을 과소평가하기 쉬운 이유를 보여주는 사례다.
   3. 청중이 발표자의 결혼 준비를 도와주는 “무급 노동”을 하거나 자기 금융 문제를 직접 다룰 수 있다고 제안한다. 본인의 약혼녀가 보지 않기를 바란다는 농담과, 결혼 예산이 생각보다 어려웠다는 자기희화가 긴장을 풀어 준다.

2. 실습 저장소와 UI

   1. 저장소에는 시작 안내, 결혼 예제, 원칙을 보여주는 하네스, 참가자가 자기 사례를 작업할 폴더가 있다. 참가자는 저장소를 복제하고 환경을 실행하되 처음부터 모든 것을 실행할 필요는 없다.
   2. 화면은 오른쪽 채팅 창에서 문제를 시작하고, 단계와 결정 노드가 표시되는 구조다. 결혼 예제를 열거나 여행·회사·개인 투자처럼 금융 또는 경제생활과 관련된 다른 주제를 선택할 수 있다.
   3. 데이터베이스는 my와 var 폴더에 저장된다. 결혼 예제와 빈 캔버스를 전환하려면 해당 폴더의 DB를 삭제한 뒤 UI를 다시 열어 새로 시작한다.
   4. 이 예제는 완제품이나 최고의 UX를 보여주려는 것이 아니다. 각 단계의 의도, 지침, 계획, 증거, 테스트가 하네스 안에서 어떻게 연결되는지 확인하도록 만든 실험 환경이다. 막히면 진행자에게 도움을 요청하고, 집에 가져가서 무엇이 효과적이었는지 살펴볼 수 있다.
   5. 테이블 만드는 법을 가르치며 테이블을 보여주는 것처럼, 원칙을 설명하는 동시에 그 원칙이 실제로 구현된 구조를 보여준다. 다만 저장소의 코드와 일부 동작은 실습을 위해 단순화되거나 하드코딩되어 있다.

3. 불완전한 정보로 시작하는 결혼식 계획

   1. 첫 요청은 “결혼식 비용을 제때 지불할 수 있는지 모르겠다”는 문제에서 출발한다. 세 차례 지불해야 하며 첫 납부액은 6,000달러, 두 번째 금액은 미정, 마지막은 나머지 금액이다.
   2. DJ 비용은 알지만 장식 비용은 모른다. 하객 수 역시 미정이고, 식사비는 인당 금액으로 계산해야 한다. 사용자는 무엇을 계산해야 하는지조차 정확히 정리하지 못한 채 계획을 요청한다.
   3. 추가 맥락으로 저축은 없고 비용은 본인이 부담하지만 어머니가 약 5,000달러를 줄 수도 있다고 밝힌다. 하객 1인당 비용은 약 150달러, 꽃 장식은 500달러이며 정장도 사야 한다.
   4. 이후 세 번째 결제일에 20,000달러가 들어오는 정보처럼 결과를 크게 바꿀 수 있는 변수를 다룬다. 그 정보가 실제로 확정된 사실인지, 예상인지, 분석에 포함할지 확인해야 한다.
   5. 정돈되지 않은 맥락을 한꺼번에 던져도 에이전트가 “알겠습니다”라며 성급히 계산하지 않는다. 먼저 필요한 질문을 하고, 계획에 필요한 데이터 포인트와 결정 사항을 사용자가 하나씩 검토하게 한다.

2. 공유 도메인: 같은 말을 쓰는 것과 같은 뜻을 아는 것은 다르다

2.1. 도메인 정의와 계획을 함께 만든다

1. 모델의 지식과 사용자의 지식은 다르다

   1. 모델이 금융 분야의 용어를 알더라도 사용자가 의도한 정의와 같다는 보장은 없다. 개인이나 회사만 쓰는 용어, 특정 지표의 정의, 통상적인 표현의 변형은 모델이 추측할 수밖에 없다.
   2. 모델을 특정 사용자만을 위해 별도로 학습하지 않았다면, 사용자 고유의 정의가 일반적인 정의와 일치하지 않을 수 있다. 따라서 “모델이 똑똑하니 알아서 알 것”이라고 가정하지 말고 계속 확인해야 한다.
   3. 사용자와 모델의 지식은 서로 겹치는 영역이 있지만 완전히 일치하지 않는다. 하네스의 역할은 질문과 설명을 통해 두 지식의 교집합을 넓히는 것이다.

2. 모호한 요구를 계획으로 바꾼다

   1. 사용자가 목표, 제약, 보유 자금, 지출 시점과 미지수를 설명하면 에이전트는 가정을 질문으로 바꾸고 필요한 사실을 수집한다.
   2. 하네스는 무엇을 실행하기 전에 어떤 정보가 필요한지, 계획에 어느 정도 엄밀함이 필요한지 안내한다. 그 결과 사용자는 스스로 중요하다고 생각하지 못했던 질문까지 확인하게 된다.
   3. 계획은 단계와 의사결정 트리(decision tree)로 나뉜다. 각 노드는 어떤 정보에 기반했는지, 사용자가 말한 사실인지, 에이전트의 추론인지, 아직 열린 결정인지 표시한다.
   4. 계획이 수락되었다는 상태는 충분한 대화와 검토 끝에 문제를 단계별로 다룰 수 있다고 판단했음을 뜻한다. 결혼 예제에서는 대략 10분의 질문과 응답 뒤에 단계별 계획이 생성되었다.

2.2. 계획의 출처와 수정 경로를 보이게 한다

1. 결정의 근거를 UI에서 확인한다

   1. 계획 다이어그램에서 노드나 단계를 선택하면 그 결정이 왜 필요했는지, 어떤 맥락과 정보에서 나왔는지 확인할 수 있다.
   2. 에이전트가 사용자 발화를 어떻게 해석했는지, 어떤 말에 기대어 가정을 만들었는지 살핀다. 예컨대 모호한 표현의 특정 키워드 때문에 에이전트가 사용자의 뜻을 잘못 가정했을 수 있다.
   3. 표시를 통해 정보가 사용자에게서 왔는지 에이전트가 제안했는지, 아직 결정되지 않은 상태인지를 구분한다. 마우스를 노드에 올리거나 선택하면 설명과 분석이 나타난다.
   4. 사용자는 잘못된 가정을 특정 노드에서 바로 지적하고 대화를 이어갈 수 있다. 전체 분석을 처음부터 다시 시작하지 않고 해당 부분만 수정하는 것이 목표다.

2. 선형 채팅의 문맥 손실을 줄인다

   1. 기존 채팅은 모든 정보를 한 줄의 긴 대화 문맥에 쌓는다. 열 번 넘게 대화한 뒤 처음부터 다시 하자고 하면 이전 논의가 사라지거나 서로 다른 주제가 뒤섞일 수 있다.
   2. 긴 재무 분석을 개별 결정과 단계로 나누면 하나의 가정을 바꿔도 모든 문맥을 다시 작성하지 않아도 된다.
   3. 채팅 중 떠오른 별도의 질문이 본 분석에 섞이는 문제도 다룬다. 사용자는 종종 멍청한 질문이나 여담이 본 작업을 오염시킬까 봐 별도 대화창을 열고, “이 내용은 다른 데 쓰지 말라”고 반복해서 지시한다.
   4. 실제 사용 방식에 맞는 분기(branch)를 제공하면 별도 질문을 본 분석과 분리했다가 필요한 정보만 다시 합칠 수 있다. 단순히 “여담”이라고 말하라는 지침만으로는 대화 문맥이 분리되지 않는다.

3. 계획은 계속 바뀔 수 있는 사양이다

   1. 결혼 계획과 재무 분석의 요구 사항은 대화가 진행되면서 바뀐다. 사양이 바뀌면 입력, 계산, 결론도 함께 갱신되어야 한다.
   2. 하네스가 계획을 노드별로 구조화하면 사용자의 생각이 변해도 어느 결정과 근거가 달라졌는지 확인할 수 있다.
   3. 명세 주도 개발(spec-driven development)과 닮은 점은 원천이 되는 요구 정의를 가진다는 것이다. 차이는 단일 문서 하나만 유지하는 대신 독립적인 워크플로로 결정과 변경을 표면화한다는 점이다.
   4. 데이터 팀에서는 지표와 차원의 정의, 전제 조건, 원천 데이터가 계속 바뀐다. 이런 변화가 있을 때마다 프롬프트를 처음부터 입력하지 않고도 하네스가 맥락과 결정을 갱신하도록 설계해야 한다.

3. 일관성: 확률적 모델에 반복 계산을 맡기지 않는다

3.1. 계산을 모델의 산술 능력에 의존시키지 않는다

1. 같은 질문에 다른 답이 나오면 위험 신호다

   1. 채팅 모델은 보기 좋고 수학 기호까지 갖춘 공식을 제시하면서도 계산 결과를 틀릴 수 있다. 사용자는 공식 형식이 그럴듯해 “알고 있겠지”라고 생각하지만, 숫자를 확인하면 처음부터 다시 해야 하는 상황이 생긴다.
   2. 같은 계산을 다시 실행했을 때 결과가 달라지는 것은 일관성이 부족하다는 신호다. 설정 온도를 낮추는 것만으로 반복 계산의 신뢰성을 보장할 수 없다.
   3. 확률적 기계에게 매번 같은 결과를 요구하는 대신, 계산과 반복 가능한 실행을 코드와 도구 호출(tool calling)로 옮겨야 한다.

2. 결정론적 코드와 비결정론적 추론을 섞는다

   1. 모델은 상황을 이해하고 적절한 도구를 선택하며, 사용자가 말한 내용의 의미를 해석하는 데 활용한다. 반면 산술, 집계, 범위 검증처럼 결과가 재현되어야 하는 부분은 검증된 코드가 실행하도록 한다.
   2. 모든 금융 서비스 회사가 업무 절차를 똑같이 처리하지는 않지만, 많은 기본 공식과 계산은 공통 라이브러리로 만들고 한 번 구현한 뒤 업데이트할 수 있다.
   3. 모듈화한 코드는 단위 테스트(unit test), 골든 테스트(golden test), 엔드투엔드 테스트(end-to-end test)로 확인한다. 신뢰할 수 있는 라이브러리와 좋은 소프트웨어 엔지니어링 관행도 활용한다.
   4. 모델에게 매번 즉석에서 코드를 새로 만들게 하면 첫 번째나 몇 번째 실행은 맞더라도, 백 번째 실행에서 이미 검증한 작업을 또 다른 방식으로 구현할 수 있다.

3.2. 재무 계산의 재현성과 코드 변경을 관리한다

1. 반복적인 개인 예산 분류 사례

   1. 매달 명세서 항목을 분류하고 합산하며 환불과 지출을 처리하는 업무를 에이전트에게 맡겼더니, 여러 번 잘 되다가도 다음 실행에서 결과가 달라졌다.
   2. 틀린 분류를 바로잡느라 에이전트와 다시 씨름하면 돈과 시간이 더 든다. 계산 규칙을 스크립트로 작성해 두면 필요할 때마다 같은 방식으로 실행할 수 있다.
   3. 도구 사용을 엄격히 설계하지 않으면 모델이 세션마다 다른 코드를 만들어 산술을 직접 처리할 수 있다. 새 세션에서는 이전 코드가 사라져 매 질문마다 새 계산 방식이 생기고, 비결정성이 커진다.

2. 계산 코드와 테스트를 사용자에게 보이게 한다

   1. 계산에 해당하는 단계는 코드로 구현하고, 하네스는 코드와 테스트 상태를 드러내야 한다. 사용자는 어떤 작업이 계산 코드인지, 어떤 테스트가 통과해야 하는지 확인할 수 있다.
   2. 테스트를 실행하라는 기억이나 사용자의 주의력에만 의존하지 않는다. 하네스가 계획의 다음 단계로 테스트 실행을 안내하고, 테스트가 끝나기 전에는 분석이 완료된 것처럼 진행되지 않도록 한다.
   3. 테스트에서 요구하는 정의와 구현이 맞지 않으면 계산식을 바꿨더라도 결론에 도달하지 못하게 막는다. 예를 들어 곱셈 집계를 다른 집계로 바꾸면 기존 분석의 테스트가 실패해야 한다.
   4. 목표는 에이전트가 “생각 중”, “정독 중” 같은 동사를 출력하는 것이 아니라, 사용자의 환경에서 실제로 실행되는 테스트와 검증 가능한 결과를 만드는 것이다.

3. 버전 관리와 근거의 연결

   1. 코드가 버전 관리되고 있다면 같은 분석을 다시 실행할 때 코드 버전이 달라졌는지 확인한다.
   2. 함수 이름은 같더라도 내부 계산 방식이 달라졌다면 결과를 이전과 동일하게 신뢰하면 안 된다. 변경된 계산을 감지해 사용자에게 알려야 한다.
   3. 마스터 스프레드시트가 조용히 수정되어 합리적인 범위에 대한 가정이 바뀌면, 사용자가 잘못한 것이 없어도 결과가 완전히 달라질 수 있다. 계산 코드도 변경 이력을 추적하지 않으면 같은 사각지대에 빠진다.
   4. 신뢰성은 결과 숫자만 확인하는 것이 아니라, 어떤 코드와 버전, 입력과 테스트가 그 숫자를 만들었는지 확인하는 데서 나온다.

3.3. 스킬 지침과 전용 도구 사이의 경계

1. 프롬프트만으로 중요한 반복 업무를 보장하기 어렵다

   1. 스킬이나 지침은 “모든 규칙을 따르고 실수하지 말라”고 모델에 요청하는 방식이다. 요즘 모델이 지침을 대부분 잘 따르더라도, 예기치 않은 상황에서 실패할 나머지 경우를 고려해야 한다.
   2. 내부 사용자가 많아지면 사용자별 설정 파일이나 클라우드 지침에 서로 상충하는 내용이 생길 수 있다. 여러 팀이 스킬과 플러그인을 공유할수록 예외 처리 지침이 늘어난다.
   3. 지침에 “이 경우는 지원하지 않는다고 답하라”는 예외를 계속 덧붙여도, 실제 실행을 결정론적으로 통제하지 못한다.
   4. 재현성과 정확성이 중요한 시점이 오면 프롬프트 기반 스킬만 유지할지, Python 스크립트와 백엔드 코드로 된 전용 도구를 만들지 판단해야 한다.

2. 도구를 만들 가치가 있는 시점

   1. 재현성이 필요하거나 기존 하네스에서 결과가 반복적으로 틀리고, 오류가 업무에 중요한 영향을 준다면 전용 하네스의 가치가 커진다.
   2. 결과를 사용하는 사람이 많거나, 여러 분석가가 회사의 핵심 결정을 지원할 때는 작은 변동성도 큰 위험이 된다. 반대로 영향이 낮고 사람이 결과를 검토하는 간단한 업무라면 가벼운 스킬과 수동 개입으로 충분할 수 있다.
   3. 도구를 만드는 데 너무 몰두해 실제 도끼를 쓰지 못하는 상황을 경계한다. 같은 작업을 여러 채팅창에 복사하고 새 세션을 반복해 열어야 한다면, 그 반복을 한 번에 해결하도록 시스템을 개선할 신호다.

4. 증거: 결과뿐 아니라 결과가 만들어진 경로를 남긴다

4.1. 사실, 가정, 해석을 구분한다

1. 출처가 있다는 사실만으로 진실이 되지는 않는다

   1. 하객 수가 100명이라고 입력했더라도 약혼자가 말하지 않고 세 명을 더 초대했다면 전체 예산 모델은 틀어진다. 단순한 결혼 사례도 잘못된 가정 하나가 재무 분석을 무너뜨리는 방식을 보여준다.
   2. 모델은 무엇이 확정된 사실이고 무엇이 추정인지 스스로 안정적으로 구분하지 못한다. 시스템에서 정보의 유형과 신뢰도를 명시해야 한다.
   3. 채팅 중의 비정형적인 생각은 해석 또는 사용자 입력으로 표시할 수 있다. 에이전트의 추론이나 메모리에서 끌어온 정보는 가정으로 취급한다. 은행 명세서에 실제 기재된 거래는 다른 유형의 증거다.
   4. 정보가 어디서 왔는지뿐 아니라 어떤 결정과 계산에 사용되었는지 추적해야 한다. 사용자가 결과를 신뢰하려면 “무엇을 근거로 이 결론을 냈는가”에 답할 수 있어야 한다.

2. 데이터의 원천과 가중치를 보존한다

   1. 데이터 분석과 모델 학습에서 정제된 데이터셋과 라벨링이 중요하듯, 에이전트가 사용하는 증거에도 적절한 중요도와 신뢰 수준을 부여해야 한다.
   2. 금융 데이터라면 어떤 공급자나 커넥터에서 특정 시점의 Apple 가격을 가져왔는지, 그 값이 주식·채권 거래나 투자 분석에 어떻게 쓰였는지 추적할 수 있어야 한다.
   3. 입력 숫자만 기록해서는 충분하지 않다. 어떤 계산과 코드가 그 숫자를 만들어 냈는지도 증거의 일부다.
   4. 정보를 클릭하거나 노드를 선택하면 입력 출처, 연결된 결정, 계산 결과가 강조되어야 한다. 모든 로그를 매번 읽지 않아도 분석의 핵심 경로를 빠르게 살펴볼 수 있다.

4.2. 흔적이 없을 때 생기는 실제적인 실패

1. 마스터 파일의 변경

   1. 회사 공유 드라이브에서 즐겨찾기로 쓰던 마스터 파일이 조용히 바뀌었는데 사용자는 변경을 모를 수 있다. 파일에는 합리적인 값의 범위라는 가정이 들어 있었고, 사용자는 기존 방식대로 숫자를 넣었지만 결과는 완전히 틀렸다.
   2. 코드와 입력의 변경 이력을 남기지 않으면 하네스도 같은 문제를 겪는다. 입력이 같아 보여도 처리 과정이 달라졌다면 결과의 의미가 달라질 수 있다.

2. 근거를 모르는 발표 자료

   1. 팀 자료와 문서를 조사해 핵심 발표 내용을 만드는 시스템이 발표자의 수정 예시 하나에 과도하게 집착해, 그 사례를 슬라이드 곳곳에 반복 삽입할 수 있다.
   2. 경영진이 특정 숫자와 가정의 출처를 물었을 때 작성자가 답하지 못하면 결과물에 대한 신뢰가 떨어진다. 좋은 문장과 그럴듯한 숫자가 있어도 생성 경로를 모르면 충분하지 않다.
   3. 사용자가 “이 수치는 어디서 나왔지?”라고 물을 때 과거 대화 내용을 다시 인용하는 데 그치지 말고, 근거 자료와 출처를 바로 보여줄 수 있어야 한다.

3. 실행 가능한 영수증

   1. 분석의 각 결론에는 입력의 출처, 적용한 가정, 실행한 코드, 통과한 테스트, 코드 버전이 연결되어야 한다. 이는 숫자를 뒷받침하는 “영수증”이다.
   2. UI에서 한 숫자를 선택하면 그 값이 어디서 왔고 다른 계산에 왜 중요한지 처음부터 끝까지 볼 수 있어야 한다.
   3. 흔적을 남기면 사용자는 숫자뿐 아니라 어떤 정보가 결정에 영향을 주었는지도 되짚을 수 있다. 이것이 신뢰와 책임성을 함께 지탱한다.

5. 책임성: 에이전트는 결과에 책임지지 않으므로 사람의 통제점을 설계한다

5.1. 사용자는 결과의 주체다

1. 책임을 모델에게 돌릴 수 없다

   1. 에이전트가 현실 세계의 어떤 결과에도 책임지지 않지만, 결과를 사용하는 사람과 조직은 책임을 진다.
   2. 고용과 보상은 키보드를 두드리는 행위만이 아니라 회사에 내는 성과를 책임지는 데서 나온다. AI가 일을 도와도 팀의 협업과 결과 책임이라는 인간의 역할은 사라지지 않는다.
   3. “Claude가 그렇게 줬다”는 말은 잘못된 결정을 면책하지 않는다. 잘못된 결과의 영향을 감당하는 사람은 여전히 사용자다.

2. 블랙박스와 과잉 승인 사이에서 균형을 잡는다

   1. 아무것도 확인하지 않고 에이전트의 출력을 그대로 승인하면 책임의 공백이 생긴다.
   2. 반대로 변경 때마다 모든 diff를 한 줄씩 읽거나 모든 계산을 매번 승인하라고 하면 실제로 지속하기 어렵다. 모든 PR을 세밀히 검토하는 방식은 잘 설계된 자동화가 아니다.
   3. 하네스는 결과와 사용 사례에 맞는 소수의 명확한 검문소(checkpoint)를 둬야 한다. 테스트가 의미 있는 코드에는 테스트 통과가 신호가 되고, 금융 의사결정처럼 중요한 불확실성에는 사람의 확인이 필요하다.
   4. 검문소는 중요한 판단과 모호성을 해결하는 곳에 둔다. 모든 결정에 “나에게 물어보라”고 하면 알림이 늘어 신호의 가치가 떨어진다.

3. 검토는 책임의 전가가 아니다

   1. 검토자가 있다는 이유로 결과의 책임을 그 사람에게 전부 넘기면 사기를 떨어뜨리고 과부하를 만든다.
   2. 전문가가 모든 셀을 검사하지 않더라도 몇 개의 합계나 익숙한 항목만 보고 “마케팅 비용이 왜 이렇게 큰가?” 같은 이상 징후를 발견할 수 있다.
   3. 하네스는 생성된 작업 단위에서 중요한 결정과 테스트 결과를 검토하게 하고, 검토자가 무엇을 승인하는지 분명히 해야 한다.

5.2. 결정의 주체를 기록하고 안전하게 되돌린다

1. 누가 무엇을 정했는지 표시한다

   1. “에이전트가 가정한 값을 그대로 사용했다”, “사용자가 입력을 수정했다”, “사용자와 에이전트가 합의했다”를 구분할 수 있어야 한다.
   2. 결혼 예산에서 세 번째 결제일에 20,000달러가 들어오는지처럼 결과를 크게 바꾸는 정보는 누가 제공하고 승인했는지 기록한다.
   3. 결정이 다른 결정의 전제가 되면 그 연결을 그래프의 노드와 가지로 표현해, 한 변경이 어디까지 영향을 주는지 추론할 수 있게 한다.

2. 수정과 분기를 보존한다

   1. 금융 분석은 결정이 내려진 뒤에도 정보를 고치거나 맥락을 추가할 수 있어야 한다. 채팅에 문장 하나를 잘못 입력했다는 이유로 분석 전체를 잃어서는 안 된다.
   2. 하객 수를 150명으로 수정하면 계획을 다시 계산하고 관련 단계에 미치는 영향을 보여준다. 입력과 분석 전체의 연결이 유지되어야 한다.
   3. 특정 단계에서 새 대화 가지(branch)를 열면 별도 질문이나 대안을 본 분석과 구분할 수 있다. 필요하면 결과를 본 흐름에 다시 합친다.
   4. 일부 대화는 결론에 영향을 주지 않을 수도 있다. 사용자가 그 사실을 판단해 가지를 무시(dismiss)할 수 있어야 한다.

3. 승인 지점은 위험과 목적에 맞춘다

   1. 에이전트가 여러 시나리오를 만들고 비교 자료를 정리하는 것은 맡길 수 있어도, 사용자의 이익에 영향을 주는 최종 결정을 무조건 위임해서는 안 된다.
   2. 선택지를 나란히 검토하고 어떤 결정이 다음 단계로 이어지는지 확인할 수 있어야 한다.
   3. 잘못된 결정이 뒤의 여러 판단을 오염시키기 전에 중요한 관문을 둬야 한다. 반대로 테스트가 코드 자체를 검증할 수 있다면 같은 내용의 사람 승인을 중복해서 요구하지 않는다.

6. 검증: 독립된 기준점으로 편향과 사각지대를 찾는다

6.1. 반사실적 관점과 외부 기준을 추가한다

1. 자기 판단만으로 자기 판단을 평가하지 않는다

   1. 별도의 관점이 없으면 자신의 편향대로 일을 처리하고 결과가 항상 그럴듯해 보일 수 있다. 검증은 책임을 면제하는 절차가 아니라 판단에 추가 정보를 공급하는 절차다.
   2. 결과를 만든 정보에만 갇히지 않도록 인터넷, 외부 자료, 다른 팀의 정보처럼 독립적인 참조 지점을 활용한다.
   3. 기준 사례(best practice)는 도메인의 올바른 범위를 잡는 데 도움이 되지만, 어떤 도메인도 고립되어 있지 않다. 자신이 선택한 모범 사례만 확인하면 선택적 편향을 강화할 수 있다.

2. 도메인 전문가의 얇은 단면(thin slicing)

   1. BI 분석가가 쿼리와 숫자를 확인해도 오류를 발견하지 못했지만, 다른 팀의 이해관계자는 그해 매출 규모를 알고 있었기 때문에 대시보드 숫자가 틀렸다고 즉시 알아차릴 수 있다.
   2. 전문가는 전체 계산을 처음부터 다시 하지 않아도, 업무 경험의 얇은 단면과 직관으로 결과의 이상 여부를 포착할 수 있다.
   3. 모델은 여러 사람의 일반적인 경험을 평균한 지식을 갖지만 특정 회사의 미묘한 5% 차이가 중요하다는 사실을 모를 수 있다. 팀의 경험을 피드백으로 입력해 모델의 일반 지식과 현장 지식 사이를 조정해야 한다.

3. 검증은 공유 도메인을 계속 갱신한다

   1. 질문과 정정을 통해 사용자는 “우리 회사에서는 이 문제를 이렇게 본다”고 알려주고, 모델은 그 도메인에 맞춰 해석을 조정한다.
   2. 반대로 팀은 모델이 제시한 합리적인 판단이 실제로 맞는지 경험과 외부 자료로 확인한다. 이는 모델의 지식을 사용자에게 맞추는 동시에 사용자의 가정도 시험하는 양방향 피드백이다.
   3. 하네스 없이 모든 항목을 확인하거나 아무것도 확인하지 않으면 적절한 검증 수준을 정하기 어렵다. 적은 비용으로 이상을 찾는 기준점과 검토 루프를 설계해야 한다.

6.2. 별도 에이전트도 검증의 전부는 아니다

1. 도전 과제를 맡은 분기

   1. 계획의 가정과 논리를 건전하게 도전하도록 별도 에이전트(branch)에 임무를 줄 수 있다. 그 검토 결과를 메인 흐름에 합치고, 실제 계획이 어떻게 수정되었는지 기록한다.
   2. 다른 에이전트를 판단자로 생성하는 것만으로는 충분하지 않다. 피드백이 결과와 계획을 개선하는 루프로 이어져야 한다.
   3. 무관한 대화는 무시할 수 있고, 중요한 반론은 근거와 함께 계획에 반영한다.

2. 검증은 맥락에 맞는 외부 관점이다

   1. 사람의 직관, 다른 팀의 지식, 외부 정보, 테스트, 도메인 기준은 서로 다른 종류의 검증을 제공한다.
   2. 무엇이 적절한 참조점인지는 업무마다 다르다. 금융 분야에서는 외부 정보와 강한 검증 루프가 특히 중요하지만, 모든 콘텐츠 제작 업무에 같은 절차가 필요한 것은 아니다.
   3. 검증의 책임은 끝까지 결과를 사용하는 사람과 조직에 남는다. 다른 에이전트가 검토했다고 해서 책임이 사라지지 않는다.

7. 다섯 원칙을 언제, 어느 정도 적용할 것인가

7.1. 하네스 구축 여부와 범용성은 위험에 따라 결정한다

1. 두 극단을 모두 피한다

   1. 모든 업무를 하나의 범용 Claude Code·Codex와 지침·스킬로 처리하면 중요한 업무에 필요한 재현성과 검증이 부족할 수 있다.
   2. 새 업무를 할 때마다 처음부터 전용 시스템을 만들면 도구를 쓰는 시간보다 도구를 만드는 시간이 길어진다.
   3. 재현성이 필요하거나 현재 도구의 오류가 반복되고, 결과가 핵심 업무에 쓰이며, 사용자 수가 늘어날수록 전용 하네스의 가치가 커진다.

2. 금융의 위험과 콘텐츠 제작의 위험은 다르다

   1. 신용 분석가 50명이 회사의 핵심 결정을 지원하는 시스템이라면 결과의 변동성이 작아야 하고, 근거와 검증에 더 많은 투자를 해야 한다.
   2. 개인이 소셜 미디어용 AI 영상을 만드는 작업에서는 모든 증거와 책임 추적이 불필요할 수 있다. 결과가 틀렸을 때의 비용과 실패 영향이 다르기 때문이다.
   3. 금융은 금액이 실제로 이동하고 1%의 오류도 큰 손실을 만들 수 있어 다섯 원칙이 적절한 영역이다. 원칙을 적용할지와 깊이는 사용자 수, 업무 중요도, 오류 비용을 함께 보고 정한다.

3. 도끼를 만드는 데만 몰두하지 않는다

   1. 도구가 원하는 결과를 내지 못하면 먼저 반복 작업과 불편을 살핀다. 같은 내용을 여러 채팅에 붙여 넣고 세션을 계속 새로 여는 행동은 워크플로를 정리할 신호다.
   2. 반복적으로 수행하는 일을 모아 한 번의 계획과 실행에서 처리하도록 하네스를 개선한다.
   3. 도구를 구축하는 행위 자체를 목표로 삼지 않는다. 실제로 필요한 안전장치와 제어 수준을 구현하고 업무 결과를 개선하는 것이 목표다.

7.2. AI의 정확도를 약속하기보다 결과를 합의한다

1. 결과 중심으로 성공을 측정한다

   1. “AI를 쓸 수 있으니 쓰자”보다 어떤 결과를 얻고 싶은지를 먼저 정한다.
   2. 예를 들어 BI 팀에 불필요한 문의가 줄었는지, 새 대시보드 검증이 쉬워졌는지, “이 수치는 틀린 것 같다”는 내부 티켓이 줄었는지 추적할 수 있다.
   3. 성공 지표가 정해지면 AI를 어떤 방식으로 사용했는지는 결과를 내기 위한 수단이 된다. AI를 통해 달성할 결과에 대해 이해관계자와 합의하는 일이 AI 자체에 대한 막연한 신뢰를 얻는 것보다 중요하다.

2. “AI가 했으니 200% 정확하다”는 기대를 만들지 않는다

   1. AI가 개입했다고 모든 결과가 완벽하다고 기대하거나 설명해서는 안 된다. AI가 사용됐다는 사실이 검증된 SQL이나 수작업 분석을 대체하지는 않는다.
   2. 분석 과정과 방어 장치를 보여주고, 무엇을 테스트했고 어디에 사람의 판단이 필요한지 구체적으로 설명한다.
   3. 결과가 중요한 업무라면 과정과 측정 지표를 투명하게 해 이해관계자가 신뢰의 근거를 볼 수 있게 한다.

7.3. 도구 분해와 금융의 역할

1. 에이전트 분할은 검색과 결정의 차이를 고려한다

   1. 결혼식 준비를 케이터링, 장소, 사진, 꽃과 비용 시나리오별 에이전트로 나누는 방식을 생각할 수 있다.
   2. 마드리드의 사진작가 상위 5명을 찾는 웹 검색처럼 새로운 검색과 개선된 도구가 충분히 좋은 결과를 주는 일도 있다. 목록을 비교하고 연락하는 단계는 사람이 맡을 수 있다.
   3. 재정적으로 중요한 계산과 예측은 더 세밀한 통제와 재현성이 필요하다. 같은 계산을 매번 다시 하고 싶지 않다면 전용 코드를 구축하는 편이 낫다.

2. 반복 실패가 시스템 구축 동기가 된다

   1. 차 안에서 왕복 약 1시간 동안 음성 모드로 재무 계획을 세우려다 같은 대화를 세 번 반복한 경험은 신뢰할 수 있는 하네스가 필요한 이유를 보여준다.
   2. 오류를 바로잡는 과정에서 같은 금융 계획이 반복해서 잘못되면, AI가 똑똑해지는 것을 기다리는 것만으로 해결되지 않는다. 재현 가능한 처리와 수정 가능한 맥락을 만들 필요가 있다.

3. 금융은 산수만 하는 분야가 아니다

   1. 금융 업무에는 숫자와 공식뿐 아니라 해석과 창의성이 있다. 현금 흐름이 어긋난 이유를 살펴보다가 수익 일부가 한 달 뒤에 반영된 것을 발견하는 상황처럼, 맥락을 읽는 능력이 중요하다.
   2. AI는 이런 모호한 해석을 도울 수 있지만, 핵심 계산과 실제 금전적 결과는 결정론적 장치와 확인 절차로 통제해야 한다.
   3. 에이전트가 10분 만에 해결할 수 있는 간단한 요청처럼 보여도, 현실에서는 100% 신뢰가 필요한 요소와 자유로운 해석이 한 작업 안에 섞여 있을 수 있다.

주요 발언 모음

“돈과 관련된 문제라면, 신뢰는 당연하게 여길 수 없고 특히 투명해야 한다.”

“에이전트는 현실 세계의 어떤 결과도 책임지지 않는다. 하지만 여러분은 책임진다.”

“결과가 그럴듯해 보이는 것만으로는 충분하지 않다. 일이 제대로 진행되고 있다는 확신을 주는 시스템을 만들어야 한다.”

“같은 계산을 매번 다시 만들 필요가 없다면, 한 번 작성하고 필요할 때마다 실행하면 된다.”

“검증은 책임을 전가하는 일이 아니라 사각지대를 줄이기 위한 피드백 루프다.”

“AI 구현에 대한 막연한 신뢰보다, AI로 어떤 결과를 낼 것인지 합의하는 일이 더 중요하다.”

“금융은 스프레드시트에 숫자를 더하는 일만이 아니라 창의성과 해석의 영역이다.”

핵심 데이터 & 수치

• 영상 길이 6,634초: 약 1시간 50분 34초다.
• 발표자 경력: Francesco는 영국에서 약 7년을 지낸 뒤 마드리드로 이주했고, Felippe는 영국 이주 후 약 1년 반이 지났다고 소개한다.
• 피아노 연습: Felippe는 전기공학을 선택하기 전 하루 7시간씩 피아노를 연습했다고 한다.
• 결혼식 예산: 첫 지불 6,000달러, 미정인 두 번째 지불, 나머지 금액의 세 번째 지불을 계획한다.
• 가능한 가족 지원: 어머니가 약 5,000달러를 보탤 수 있다는 정보는 확정 여부를 확인해야 할 가정이다.
• 하객 및 비용: 하객 1인당 식사 비용은 약 150달러이고 꽃 장식 비용은 500달러이며, 정장 비용도 추가된다.
• 추가 현금 유입 사례: 세 번째 결제일에 20,000달러가 들어오는지에 따라 계획이 바뀔 수 있다.
• 반복 실행 사례: 금융 명세서 분류는 매달 반복되며, 개인 경험으로 같은 재무 음성 대화를 약 1시간 운전 중 세 번 반복했다.
• 검토 규모의 예시: 신용 분석가 50명이 핵심 의사결정에 사용하는 시스템은 개인 실험보다 더 높은 재현성과 통제가 필요하다.
• 오류 허용도: 금융에서는 1% 오류도 큰 금액의 손실로 이어질 수 있다. 모델이 지난 6~9개월 동안 빠르게 발전했어도 신뢰 문제는 남아 있다.
• 99%와 1%는 설명을 위한 대비: 에이전트가 지침을 대부분 따르더라도 나머지 실패 사례가 내부 사용자와 중요한 업무에 영향을 줄 수 있다는 논점이지, 측정된 성공률이 아니다.

결론 및 시사점

1. 신뢰할 수 있는 재무 분석 에이전트를 만들 때는 먼저 사용자와 모델의 도메인 정의를 맞추고, 계획과 가정을 단계별로 검토한다.
2. 반복 가능한 계산은 코드·도구·테스트로 고정하고, 코드와 데이터의 버전을 추적해 같은 입력에 같은 결과가 나오도록 한다.
3. 모든 결론에는 출처, 가정, 계산 과정, 테스트 상태를 연결해 사용자가 결과의 근거를 확인할 수 있도록 한다.
4. 사람이 책임질 중요한 결정에만 명확한 승인 지점을 두고, 사용자가 특정 정보와 결정 단위를 수정하거나 분기할 수 있게 한다.
5. 독립적인 정보와 도메인 전문가의 피드백으로 편향을 줄이되, 다른 사람이나 다른 에이전트에게 책임을 넘기지 않는다.
6. 하네스의 복잡도는 결과의 위험, 반복 횟수, 사용자의 수, 오류 비용에 맞춘다. 모든 작업에 동일한 수준의 통제를 강요하지 않는다.
7. 완벽한 AI를 기대하기보다 어떤 결과를 개선할 것인지 합의하고, 오류를 발견하고 수정할 수 있는 신뢰 메커니즘을 설계한다.

핵심 요약 (20줄)

신뢰할 수 있는 재무 분석은 모델의 속도보다 결과의 근거와 통제 가능성을 우선한다. 재무 업무는 개인과 조직마다 용어와 지표 정의가 달라 모델과 맥락을 맞추는 과정이 필요하다. 결혼식 예산처럼 고정비와 변동비, 미정인 하객 수와 납부 시점이 얽힌 문제는 단순 계산으로 끝나지 않는다. 에이전트는 필요한 정보를 질문하고 사용자가 확인한 사실과 가정을 바탕으로 계획을 단계별로 구성해야 한다. 계획 노드에는 정보 출처와 결정 상태를 표시해 사용자가 특정 가정만 골라 수정할 수 있게 해야 한다. 선형 채팅의 긴 문맥은 주제 혼합과 정보 손실을 낳으므로 분석 단계와 별도 대화 가지를 구분해야 한다. 같은 입력에 같은 결과가 필요한 계산은 LLM의 산술에 맡기지 말고 코드와 도구 호출로 실행해야 한다. 반복 계산 코드는 단위 테스트와 골든 테스트, 엔드투엔드 테스트로 검증하고 버전을 추적해야 한다. 모델이 매번 계산 코드를 즉석 생성하면 새 세션과 반복 실행에서 결과가 달라질 수 있다. 증거에는 입력의 출처뿐 아니라 사실과 추정의 구분, 계산 방식, 코드 버전과 테스트 결과가 포함된다. 사용자는 숫자를 선택해 그 숫자가 어디서 왔고 어떤 결론에 영향을 주었는지 되짚을 수 있어야 한다. 조용히 바뀐 마스터 스프레드시트나 근거를 알 수 없는 발표 자료는 그럴듯한 결과도 신뢰를 잃게 한다. 에이전트는 실제 결과에 책임지지 않으므로 중요한 결정의 주체와 승인 지점은 사람에게 남아야 한다. 모든 변경을 검토하는 방식과 아무것도 검토하지 않는 방식 사이에 목적에 맞는 검문소를 둬야 한다. 하객 수나 현금 유입을 수정했을 때 연관된 계산과 계획이 어떻게 변하는지 확인할 수 있어야 한다. 독립적인 외부 자료와 다른 팀의 지식은 결과를 자기 기준에만 맞추는 편향을 줄인다. 도메인 전문가는 전체 계산을 다시 하지 않고도 경험과 직관으로 이상한 숫자를 빠르게 발견할 수 있다. 다른 에이전트의 검토는 피드백 루프를 보완할 수 있지만 인간의 책임을 대신하지는 않는다. 하네스의 복잡도는 오류 비용과 사용자 수, 재현성 요구에 맞추고 낮은 위험의 업무에는 줄일 수 있다. AI의 정확성을 과장하기보다 개선할 결과를 합의하고 근거와 검증 절차를 투명하게 설계해야 한다.