Stop Chatting With Spreadsheets — Francesco Galletta & Felippe Felisola Caso, Monzo

한 줄 핵심

금융 같은 고위험 업무에서 AI를 믿고 맡기려면 속도보다 신뢰를 우선해, 공유 도메인·일관성·증거·책임성·검증을 설계한 하네스를 의도적으로 만들어야 한다.

시간별 요약

1. 0:00
   소개: Francesco와 Felippe 발표자는 Monzo와 데이터 업무 경험을 바탕으로, 스프레드시트와의 단순한 대화를 넘어 신뢰할 수 있는 금융 분석용 하네스를 만드는 이야기를 다룬다. 개인 소개와 함께 실제로는 내부 생산성 도구와 데이터 팀 업무를 AI로 개선해 왔다는 배경이 제시된다.
2. 2:54
   토큰 최대화가 아니라 영향에 집중하기 AI 도입은 많은 토큰을 쓰는 데서 끝나지 않고, 실제 비즈니스 가치와 개인 생산성에 얼마나 기여하는지가 핵심이라고 본다. Monzo에서는 불필요한 비용보다 명확한 효과를 기준으로 AI를 도입하며, 이번 예시는 특정 조직 홍보가 아니라 원리를 보여주기 위한 사례로 제시된다.
3. 4:22
   병목은 속도가 아니라 신뢰다 금융 문제에서 지금의 병목은 답을 빨리 만드는 속도가 아니라 결과를 믿을 수 있느냐는 점이다. 계획, 트레이스, 평가, 루프 같은 기존 요소는 중요하지만, 그것들을 묶는 설계 원리가 있어야 실제로 신뢰를 얻을 수 있다고 강조한다.
4. 7:25
   구성요소보다 설계 원리 오늘의 초점은 특정 기술 스택이 아니라 신뢰를 만드는 설계 원리다. 잘 작동하는 하네스는 UI가 화려해서가 아니라, 사용자가 시스템의 동작을 이해하고 결과를 믿게 만드는 구조를 갖추고 있다.
5. 8:45
   신뢰의 5가지 원칙 신뢰는 공유 도메인, 일관성, 증거, 책임성, 검증이라는 다섯 원칙 위에 쌓인다. 계획을 같은 언어로 세우고, 계산은 코드로 고정하며, 근거를 남기고, 인간이 책임을 지며, 외부 기준으로 다시 확인하는 구조가 필요하다.
6. 12:13
   사례: 결혼식 예산 짜기 예시는 결혼식 비용을 계획하는 개인 금융 문제로 설정된다. 일정한 비용과 불확실한 변수들이 섞인 상황을 통해, AI가 단순 계산기처럼 답을 내는 것이 아니라 복잡한 재무 계획을 함께 정리해야 한다는 점을 보여준다.
7. 17:05
   원칙들은 서로를 보강한다 다섯 원칙은 순서대로 쌓이며 서로를 강화한다. 공유 도메인으로 계획을 만들고, 일관성으로 계산을 고정하고, 증거로 근거를 남기고, 책임성으로 흐름을 통제하고, 검증으로 바깥 시각을 더해야 전체 시스템이 믿을 만해진다.
8. 20:40
   원칙 1: 공유 도메인 사용자와 모델이 같은 용어와 맥락으로 대화해야 계획이 제대로 세워진다. 모델이 안다고 생각하는 것과 사용자가 뜻한 것은 다를 수 있으므로, 질문을 더 세분화하고 가정을 드러내며 서로의 이해를 맞추는 과정이 중요하다.
9. 25:59
   실시간 데모: 에이전트와 계획 세우기 데모에서는 결혼식 예산 정보를 입력하며 에이전트가 질문을 통해 계획을 정교화하는 과정을 보여준다. 애매한 입력을 그대로 밀어붙이지 않고, 필요한 데이터를 끝까지 끌어내서 계획의 품질을 높이는 것이 하네스의 역할이다.
10. 30:42
    계획에서 의사결정 트리로 계획이 한 번 정리되면, 각 항목은 단순한 채팅이 아니라 분기된 의사결정 노드로 구조화된다. 어디에서 정보가 왔는지, 어떤 가정이 들어갔는지, 무엇이 사용자 입력인지가 표시되어 계획의 구조를 추적할 수 있다.
11. 35:48
    긴 일자형 대화가 무너지는 이유 채팅이 길어질수록 처음의 맥락이 사라지고 다시 시작해야 하는 상황이 자주 발생한다. 선형 대화 구조는 모든 것을 하나의 컨텍스트에 억지로 넣기 때문에 복잡도가 커지지만, 하네스는 요소를 분해해 개별적으로 다룰 수 있게 한다.
12. 36:48
    원칙 2: 일관성 금융 계산처럼 결과가 항상 같아야 하는 부분은 모델의 자유로운 추론이 아니라 코드로 처리해야 한다. 같은 입력에 항상 같은 결과를 내는 결정적 경로를 만들지 않으면, 겉보기엔 그럴듯해도 실행할 때마다 다른 답이 나올 수 있다.
13. 55:50
    원칙 3: 증거 좋은 결과보다 중요한 것은 그 결과가 어디서 왔는지 보여주는 것이다. 입력, 추정, 해석, 코드, 데이터 출처를 구분해 남겨야 하며, 그래야 숫자 하나가 왜 그렇게 나왔는지 뒤로 추적할 수 있다.
14. 1:00:17
    "마스터 파일" 공포담 공유 드라이브의 마스터 파일이 바뀐 사실을 모르고 작업해 결과가 틀어지는 사례가 소개된다. 결정적 코드도 동일하게, 변경 이력과 추적 가능성이 없으면 같은 입력처럼 보여도 실제 결과는 달라질 수 있다.
15. 1:06:42
    원칙 4: 책임성 최종 책임은 언제나 사람에게 있으며, AI가 한 일에 대한 결과를 대신 책임질 수는 없다. 너무 많은 개입도, 너무 적은 개입도 비효율적이므로, 의미 있는 지점에만 높은 신호의 검토 게이트를 두는 설계가 필요하다.
16. 1:20:39
    원칙 5: 검증 검증은 또 다른 시각을 더해 편향을 줄이되, 책임을 넘겨주지는 않는다. 전문가도 모든 셀을 다 확인하지는 않지만, 별도의 기준점과 직관적 점검으로 결과가 말이 되는지 빠르게 확인하는 구조가 유용하다.
17. 1:24:16
    골든 예시와 외부 기준점 골든 예시는 내부 기준이지만, 외부의 다른 자료나 도메인 밖의 참조점도 함께 봐야 한다. 한 데이터 소스만 계속 보면 자기 확증 루프에 빠지므로, 다른 관점과 비교해 이상치를 걸러내는 장치가 필요하다.
18. 1:34:05
    Q&A: 하네스는 몇 개나 만들어야 하나? 하네스는 너무 범용적으로 만들면 흐려지고, 너무 자주 새로 만들면 도구를 만드는 데만 시간이 든다. 반복성과 중요도가 높고, 결과 변동이 치명적인 문제일수록 전용 하네스를 만들 가치가 커진다.
19. 1:38:11
    도끼를 너무 날카롭게만 갈지 말라 하네스 설계에만 매달려 실제 사용이 늦어지면 본말이 전도된다. 반복적으로 겪는 고통을 한 번에 해결할 만큼만 설계하고, 그 이상은 과도한 정교화가 되지 않도록 경계해야 한다.
20. 1:44:00
    Q&A: 스킬과 전용 하네스의 경계 스킬과 지시문만으로도 많은 경우는 해결되지만, 사용자가 많아지거나 예외와 변형이 많아지면 신뢰가 흔들린다. 결정적 코드와 검증 구조가 필요한 순간에는 스킬보다 전용 하네스가 더 적합하다.
21. 1:48:31
    핵심: 신뢰를 의도적으로 설계하라 AI는 점점 좋아지지만, 특히 돈이 걸린 문제에서는 여전히 신뢰를 설계로 확보해야 한다. 한 가지 기능만으로 믿음을 얻을 수는 없고, 다섯 원칙을 조합한 전체 경험이 결과의 신뢰도를 만든다.

실무 인사이트

• 금융·데이터처럼 결과의 오차가 큰 비용으로 이어지는 업무에서는, 프롬프트 품질보다 결정적 계산과 추적 가능성을 먼저 설계해야 한다.
• 하네스 설계의 핵심은 사용자가 에이전트와 같은 맥락에 있다고 착각하지 않게 만드는 것이며, 입력·가정·추정·결정의 경계를 명확히 드러내는 데 있다.
• 실무에서는 모든 것을 자동화하기보다, 검토가 필요한 지점만 높은 신호로 남기고 나머지는 코드로 고정하는 방식이 가장 안정적이다.