Build for the Memo, Not the Demo — Shawn Chan, China Resources Holdings

URL: https://www.youtube.com/watch?v=tJFjeMBKbIY 날짜: 2026-07-30 채널: aiDotEngineer (AI Engineer 컨퍼런스)

---

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

AI 금융 제품은 대부분 ==5분짜리 데모(demo)를 위해 만들어지지만, 진짜 돈이 걸린 순간에는 수백 페이지짜리 내부 심사 문서(memo)를 통과해야 한다== — 그리고 그 memo를 통과시키는 능력은 곧 투자자에게 체크를 받는 능력과 같은 근육이다.

• 15년간 홍콩·중국 본토·영국·미국을 넘나드는 크로스보더 M&A·IPO·전략적 투자 딜을 해온 발표자는 약 200번의 투자위원회 미팅에 앉았고 수백 개의 피치덱을 읽었다
• 투자위원회에서 딜을 승인시키는 것은 숫자의 정확성이 아니라 "신뢰(trust)"이며, 신뢰는 극도로 깨지기 쉽다
• 챗봇이 작성한 문서는 인간보다 문법이 좋고 서식도 깔끔하지만, "확신에 차 있는 것"과 "옳은 것"은 전혀 다른 능력이다

발표자는 이 발표를 단 두 문장으로 요약한다: 첫째, 거의 모든 AI 금융 제품은 사람을 5분간 감탄시키기 위해 만들어지지만, "감탄하지 않는 것"이 유일한 임무인 방(심사위원회)을 통과하도록 만들어진 제품은 거의 없다. 둘째, 제품의 신뢰를 고치는 스킬은 투자자에게 체크를 받게 만드는 스킬과 정확히 동일한 근육이다.

---

1. 발표자 배경과 핵심 통찰

1.1. 15년간 반복해온 하나의 질문

1. 발표자의 고백

   1. 15년간의 업무: 누군가가 매우 자신감 있게 종이 한 장을 건네고, 회사가 1억 달러를 쓰기 전에 "이 종이를 믿을 것인가"를 결정하는 일을 15년간 해왔다
   2. 올해 달라진 점: 이제는 종종 그 자신감 넘치는 종이를 건네는 존재가 챗봇이라는 점만 바뀌었을 뿐, 본질적 업무는 동일하다

2. 챗봇이라는 새로운 종류의 확신범

   1. 챗봇의 장점: 챗봇이 작성한 문서는 종종 인간보다 문법이 좋고, 서식이 깔끔하며, 후속 질문에도 절대 방어적으로 굴지 않고, 스스로에 대해 매우 확신에 차 있다
   2. 확신과 정확성의 괴리: 발표자가 금융업계에서 만난 가장 자신감 있는 사람들 중 다수가 동시에 가장 틀린 사람들이었다. AI는 이 "확신하는 요령"을 인간보다 더 빨리 학습했을 뿐이다

1.2. 발표자의 정체성 — 빌더가 아니라 심사자

1. 발표자의 위치

   1. 테이블 반대편: 발표자는 시스템을 직접 만드는 빌더가 아니라, 시스템을 파는 창업자와 그것을 심사하는 투자위원회 양쪽 테이블 사이에 앉아 신뢰 여부를 결정하는 사람이다
   2. 200번의 투자위원회 경험: 이 경험에서 얻은 새치 머리는 유전이 아님을 확인했다(농담)

2. 커리어 초반의 결정적 경험

   1. 아주 비싸고 세련된 은행원의 프레젠테이션: 자신감에 찬 틀린 숫자로 가득한 아름다운 슬라이드를 발표
   2. 한 명의 조용한 질문: 방 안의 한 시니어가 "이 숫자는 어디서 왔나요?"라고 조용히 물었을 때, 은행원은 마치 한 분기 전체가 지나가는 듯한 침묵의 포즈를 보였다
   3. 교훈: 그 침묵의 포즈 하나가 3년간의 금융 시험보다 금융에 대해 더 많은 것을 가르쳐 주었다

---

2. 데모(Demo)와 메모(Memo) — 서로 다른 두 기계

2.1. 두 기계의 정의

1. 기계 하나 — 데모(Demo)

   1. 정의: 깔끔한 문서 하나를 입력하면 유창한 답변 하나가 나오는 기계로, 유일한 임무는 5분간 방을 "오!" 하고 감탄시키는 것이다
   2. 예시: 휴대폰에게 긴 이메일을 요약해달라고 시키는 것 — 10초간 그럴듯하게 들리기만 하면 데모로서는 충분하다

2. 기계 둘 — 메모(Memo)

   1. 정의: 실제 돈이 움직이기 전에 실제 투자위원회가 통과해야 하는 진짜 문서로, 수백 페이지의 신고서·회의록·부러진 코와 긁힌 자국(=치열한 협상의 흔적)·지난 화요일 통화 중 급히 받아 적은 메모까지 포함한다
   2. 본질: 절반의 출처는 서로 모순되며, 메모의 임무는 사람을 "오!"하고 감탄시키는 것이 아니라 논쟁에서 살아남는 것이다. 비유하자면 가족 저녁식사인데 삼촌이 스프레드시트를 들고 나타난 상황과 같다

3. 일상 속 비유로 본 갭

   1. 데모의 기준: 휴대폰이 은행 앞에서 왜 당신이 모기지를 받을 자격이 있는지 소리 내어 변호해야 하는 상황을 상상해보라 — 갑자기 "그럴듯함"으로는 부족해지고, "옳아야 하며 그것을 증명까지 해야 하는" 상황이 되는데, 이것이 바로 메모의 본질이다

2.2. 데모와 메모는 결국 만난다 — 역사상 가장 비싼 오타

1. 2023년 2월 사건

   1. 사건 개요: 세계 최대 규모의 테크 기업 중 하나가 신규 AI 어시스턴트를 홍보 데모로 공개했는데, 그 데모에서 우주 망원경에 관한 간단한 질문에 틀린 답을 내놓았다
   2. 결과: 단 한 문장의 오답으로 인해 시장이 반응해 해당 회사 주가가 하루 만에 약 8% 하락했고, 이는 약 1,000억 달러(약 100 billion dollars)의 가치 증발에 해당했다
   3. 핵심 지적: 그 회사의 어느 누구도 "이 주장이 어디서 나온 것인가? 모두가 확인했는가?"라는 단 하나의 질문을 던지지 않았다 — 반면 발표자의 팀에서는 모든 주니어 애널리스트가 무언가를 내보내기 전에 반드시 이 질문을 던지도록 훈련받는다

2. 핵심 통찰 — "안전한 데모는 더 이상 없다"

   1. 결론: 진짜 돈이 지켜보는 순간(그리고 진짜 돈은 항상 지켜보고 있다) 모든 문장은 메모의 문장이 된다. 즉 데모조차 메모의 테스트를 통과하지 못하면 실패한다

---

3. 신뢰가 조용히 깨지는 여섯 가지 방식

3.1. 출처와 사실의 위계를 무너뜨리는 실패들

1. 모델 하나 — 모든 출처가 동등한 신뢰를 받아서는 안 된다

   1. 비유: 감사받은 재무제표의 숫자는 선서 하에 말하는 회계사이고, 애널리스트 노트의 숫자는 파티에서 자신만만한 친구이며, 내부 이메일에서 나온 숫자는 엘리베이터에서 우연히 엿들은 이야기 수준이다
   2. 문제: 대부분의 검색(retrieval) 시스템은 이 위계를 구분하지 못하고, 질문과 가장 가까운 텍스트를 아무거나 잡아채서 마치 복음처럼 건넨다
   3. 실제 사례: 발표자는 매우 비싼 AI 도구가 6개월 전 단체 채팅방에서 누군가 대충 짐작해 보낸 숫자를 자신 있게 인용하는 것을 목격했다. 실제 감사 숫자는 같은 신고서 안에서 세 줄 떨어진 곳에 있었지만, AI는 단지 더 열정적으로 들린다는 이유로 단체 채팅방 버전을 더 좋아했다

2. 모델 둘 — 숫자는 어디서나 항상 서로 일치해야 한다

   1. 사례: 메모 1페이지에는 매출 성장률이 18%라고 적혀 있는데, 아무도 재미로 읽지 않는 11페이지의 작은 표에는 17.4%라고 적혀 있었다. 방 안의 누구도 0.6%포인트의 차이 자체를 신경 쓰지 않았지만, "이 쉬운 산수도 확인 안 했다면 어려운 것은 뭘 확인 안 했겠는가"를 신경 썼다
   2. 산업 규모 사례 — 미국 대형 부동산 기업의 알고리즘 주택 매입: 알고리즘이 주택 가격에 극도로 확신을 가졌지만 실제 주택은 그 가격에 동의하지 않았다. 이 회사는 결국 약 5억 달러(half a billion dollars)를 손실 처리했고, 해당 사업부를 완전히 폐쇄했으며, 전체 인력의 4분의 1을 해고했다
   3. 결론: 모델이 멍청했던 것이 아니라, 점심 이후에도 계속 현실과 숫자가 일치하도록 강제하는 지루한 기계 장치를 아무도 만들지 않았던 것이다. 유창하고 확신에 찬 것은 옳은 것과 같지 않다

3.2. 모순·사실/추측 구분을 무너뜨리는 실패들

1. 모델 셋 — 모순은 버그가 아니라 선물이다

   1. 핵심 논리: CEO가 실적 발표에서 말한 총 매출 숫자와 공식 신고서의 숫자가 다르다면, 그 격차야말로 실제 이야기에서 가장 흥미로운 지점이며 진짜 실사(diligence)는 그 격차를 파고든다
   2. AI의 반대되는 행동: AI는 부드럽고 도움이 되게 들리도록 훈련되어 있어서, 충돌을 감지하면 조용히 더 듣기 좋은 버전을 골라 넘어가 버린다. 사용자는 애초에 불일치가 있었다는 사실조차 알 수 없다
   3. 실제 경험담: 발표자는 CEO의 숫자와 신고서 숫자가 의미 있게 다른 상황을 직접 겪었는데, 아무도 이를 지적하지 않았고 모두가 그냥 더 듣기 좋은 숫자를 사용했다. 이를 발견한 것은 순전히 한 사람이 우연히 두 문서를 동시에 펼쳐 놓고 있었던 운(luck) 덕분이었다 — "운은 통제(control)가 아니다"
   4. 빌더의 역할: 빌더의 일은 논쟁을 대신 해결하는 것이 아니라, 그 논쟁이 상자 안에서 조용히 사라지는 대신 반드시 사람 앞에서 벌어지도록 만드는 것이다

2. 모델 넷 — 사실과 추측은 반드시 분리된 상자에 있어야 한다

   1. 문제의 문장: "그 회사는 다음 분기에 승인을 받을 가능성이 높다(will likely receive approval next quarter)"는 문장은 사실처럼 읽히고 사실처럼 들리지만 실제로는 추측이다
   2. 실제 사례: 발표자는 초안 3개 버전을 거치며 "승인 받을 가능성이 높다"는 표현이 점점 "승인을 받았다"로 슬금슬금 바뀌는 것을 목격했다. 아무도 거짓말을 하지 않았지만, 추측이 다시 작성될 때마다 조금씩 더 오래 "사실의 옷"을 입고 있다가 결국 그것이 원래 추측이었다는 것을 아무도 기억하지 못하게 되었다. 실제 승인은 예정대로 도착하지 않았고, 그것은 매우 불편한 전화 통화로 이어졌다
   3. 해결책의 힌트: 이 수정은 놀랍도록 저렴하다 — 추측에 태그나 색깔 등, 3주 뒤 누군가의 슬라이드에 복사-붙여넣기 되어도 살아남는 표시를 하나만 남기면 된다

3.3. 출처 추적과 책임 소재를 무너뜨리는 실패들

1. 모델 다섯 — 주장의 출처를 찾을 수 없다면 옳고 그름은 중요하지 않다

   1. 뉴욕 변호사 사례: 챗봇의 도움으로 작성된 법률 서면이 6개의 판례를 인용했는데, 인용 형식은 아름답고 설득력 있었지만 그 6개 판례는 모두 AI가 지어낸 존재하지 않는 사건이었다
   2. 가장 흥미로운 디테일: 제출 전 변호사가 의심이 들어 챗봇에게 "이 판례들이 진짜냐"고 물었더니 챗봇은 "그렇다"고 답했다 — 이는 마치 시계를 판 사람에게 그 시계가 진짜인지 되묻는 것과 같다. 결국 판사는 그에게 벌금을 부과했다
   3. 또 다른 디테일: 가짜 판례들에는 심지어 그럴듯한 당사자 이름과 페이지 번호까지 달려 있었다 — AI는 단지 거짓말을 한 것이 아니라 서식(formatting)까지 아름답게 꾸며 스스로를 인용했다. 틀렸지만 아름답게
   4. 30초 테스트: 누군가 문장을 가리키며 "이게 어디서 나온 건지 보여달라"고 했을 때, 한 번의 클릭으로 정확한 출처 문단에 도달하거나, 아니면 브라우저 탭 7개를 열고 뒤지기 시작해야 한다. 발표자는 실제 미팅에서 방 전체가 자신의 스크롤을 지켜보는 동안 탭 7개를 든 사람이 되어본 적이 있다("10점 만점에 10점, 추천하지 않음"). 이 발표에서 단 한 문장만 기억해야 한다면: "클릭 한 번으로 도달 가능한가가 곧 제품이다. 그 외의 모든 것은 잘 쓰인 포장지에 불과하다."

2. 모델 여섯 — 결국 누군가는 서명을 해야 한다 (발표자가 가장 좋아하는 모델)

   1. 항공사 챗봇 사례: 한 항공사 웹사이트의 챗봇이 슬픔에 빠진 고객에게 "지금 정가로 티켓을 예약하고 나중에 사별 할인(bereavement discount)을 신청할 수 있다"고 안내했지만, 그런 정책은 실제로 존재하지 않았다. 챗봇은 이를 정중하고 유창하며 자신감 있게 지어냈다
   2. 재판 결과: 고객이 항공사를 심판원(tribunal)에 제소했고, 항공사는 "챗봇은 자신의 행동에 책임을 지는 별개의 법적 주체"라는 방어 논리를 폈다(발표자는 이를 "내 개가 숙제를 먹었어요"의 기업판이라고 표현). 심판원은 이 논리를 받아들이지 않았고 항공사가 배상금을 지불했다
   3. 핵심 교훈: 소프트웨어에 책임을 아웃소싱할 수는 없다. 모든 진짜 결정의 밑바닥에는 사람이 서명을 해야 하며, 만약 당신의 아키텍처 끝에 "펀딩 가능한(fundable) 책임자"가 없다면 당신은 제품을 만든 것이 아니라 변명 생성기(excuse generator)를 만든 것이다 — AI는 그 책임 있는 사람을 대체하는 것이 아니라 그 사람을 중심으로 설계되어야 한다

---

4. 다섯 가지 해결책 — 실제 딜 앞에 시스템을 두기 전 요구하는 것

4.1. 발표자가 벤더에게 요구하는 다섯 가지 (거의 앞선 여섯 가지 실패담의 직접적인 처방)

1. 모든 주장에는 영수증(receipt)이 따라와야 한다

   1. 요구사항: 각 문장은 신뢰 수준(trust level)이 표시된 출처 문단으로 곧바로 연결되어야 하며, 끝에 붙은 인용 탭 형태여서는 안 된다

2. 사실과 추측은 시각적으로 명확히 분리되어야 한다

   1. 요구사항: 페이지를 한눈에 보았을 때 무엇이 증명된 것이고 무엇이 누군가의 최선의 추정치인지 즉시 구분되어야 한다

3. 숫자는 자동으로 서로 일치해야 한다

   1. 요구사항: 수치가 맞지 않는 메모는 시스템이 아예 발행을 거부해야 하며, 새벽 2시에 사람이 손으로 확인하는 방식이어서는 안 된다

4. 모순은 매끄럽게 지워지지 않고 반드시 표면으로 드러나야 한다

   1. 요구사항: 출처들이 서로 다른 말을 할 때, 시스템은 앞쪽에 있는 답을 그냥 골라 넘어가는 대신 손을 들어 이를 알려야 한다

5. 실제 사람의 승인 게이트가 존재하고 기록되어야 한다

   1. 요구사항: 누가, 무엇을, 언제 검토하고 서명했는지가 로그로 남아야 하며, 그 로그 자체가 감사 추적(audit trail)이 된다

4.2. 이 목록에서 빠진 것 — "더 똑똑한 프롬프트"는 없다

1. 핵심 메시지
   1. 다섯 가지 전부 배관·정직성 문제: 이 목록의 어느 것도 "더 큰 두뇌(bigger brain)" 문제가 아니라, 전부 배관(plumbing)과 정직성(honesty)의 문제다
   2. 승자의 조건: 이 카테고리의 승자는 벤치마크 점수로 이기지 않는다. 그들은 지치고 회의적인 금융 담당자가 밤 11시에 브라우저 탭 7개를 열지 않고도 결과물을 신뢰할 수 있게 만들었기 때문에 이긴다

---

5. 창업자에게 적용되는 동일한 논리 — 당신의 피치덱도 결국 메모가 된다

5.1. 피치 이후에 실제로 벌어지는 일

1. 투자자에게도 동일한 원칙이 적용된다

   1. 과정: 피치 미팅을 나오면 발표자 같은 사람이 실제로 앉아서 당신에 대한 내부 메모를 작성하고, 당신이 입으로 말한 모든 숫자는 데이터룸(data room)과 대조되어 확인된다
   2. 결론: 즉 지금까지 문서에 대해 말한 모든 것이 발표자 개인(창업자로서 투자를 받으려는 사람)에게도 그대로 적용된다는 뜻이다

2. 끝맺음의 아이러니

   1. "네 가지 교훈"이 예고만 되고 발표는 끝남: 발표자는 "이제 네 가지 교훈(Four lessons)이 남았다"고 말한 직후 "제 시간이 다 됐네요. 감사합니다(Okay, my time's up. Thank you)"로 발표를 마친다
   2. 이 결말이 갖는 의미: 발표 시간(=제약된 리소스)을 제대로 관리하지 못해 정작 약속한 결론을 전달하지 못한 이 마무리 자체가, 발표 전체가 말하고자 한 "신뢰는 완결성과 검증 가능성에서 나온다"는 주제를 역설적으로 실증한다

---

주요 발언 모음

"Money doesn't follow intelligence. Money follows trust, and the trust is fragile, especially when the thing that wrote the page has never once in its entire life said the words, 'I'm not sure.'" (돈은 지능을 따르지 않는다. 돈은 신뢰를 따르며, 그 신뢰는 취약하다 — 특히 그 페이지를 쓴 존재가 평생 단 한 번도 "나는 확신이 없다"라고 말해본 적이 없을 때 더욱 그렇다.)

"Fluent and confident is not the same as right." (유창하고 확신에 찬 것은 옳은 것과 같지 않다.)

"A contradiction is not a bug. A contradiction is a gift." (모순은 버그가 아니다. 모순은 선물이다.)

"The click-through is a product. Everything else is well-written packaging." (클릭 한 번으로 도달 가능한가가 곧 제품이다. 그 외의 모든 것은 잘 쓰인 포장지일 뿐이다.)

"You can't outsource accountability to your own software. ... If your architecture doesn't have a fundable human at the end of it, you have not built a product. You have built an excuse generator." (당신의 소프트웨어에 책임을 아웃소싱할 수는 없다. 아키텍처 끝에 펀딩 가능한 사람이 없다면, 당신은 제품을 만든 게 아니라 변명 생성기를 만든 것이다.)

"$100 billion for one sentence." (문장 하나에 1,000억 달러.)

---

핵심 데이터 & 수치

• 2023년 2월 대형 테크기업 AI 어시스턴트 데모 사고: 우주 망원경 관련 오답 한 문장으로 주가 하루 만에 약 8% 하락, 약 1,000억 달러 시가총액 증발
• 대형 부동산 기업의 알고리즘 주택 매입 실패: 약 5억 달러(half a billion dollars) 손실 처리, 관련 사업부 폐쇄, 전체 인력의 4분의 1 해고
• 뉴욕 변호사 챗봇 판례 조작 사건: 챗봇이 지어낸 존재하지 않는 판례 6건을 법률 서면에 인용, 변호사에게 벌금 부과
• 항공사 챗봇 사별 할인 오안내 사건: 존재하지 않는 정책을 챗봇이 지어내 안내, 심판원(tribunal)이 항공사 책임 인정 및 배상 판결
• 발표자 경력 수치: 15년 크로스보더 딜 경험, 약 200회 투자위원회 미팅 참석, 수백 개 피치덱 검토 (최대 47페이지 시드 덱까지)
• 메모 vs 데모 불일치 사례: 1페이지 매출성장률 18% vs 11페이지 표 17.4% — 0.6%포인트 차이 자체보다 "쉬운 계산도 확인 안 했다면 무엇을 확인 안 했는가"가 핵심

결론 및 시사점

1. AI 금융/투자 제품을 만들 때는 "5분간 방을 감탄시키는 데모"가 아니라 "감탄하지 않는 것이 임무인 심사위원회를 통과하는 메모"를 기준으로 설계해야 한다
2. 신뢰는 지능이 아니라 출처의 위계, 숫자의 정합성, 모순의 노출, 사실/추측의 분리, 출처 추적성, 그리고 최종적으로 서명하는 사람의 존재라는 여섯 가지 축에서 만들어지거나 깨진다
3. 해결책은 "더 똑똑한 프롬프트"가 아니라 배관(plumbing)과 정직성의 문제다 — 출처 링크, 사실/추측 시각적 분리, 자동 정합성 체크, 모순 표면화, 사람의 승인 게이트와 로그라는 다섯 가지 장치로 구현된다
4. 창업자가 투자자에게 피치할 때도 똑같은 원리가 적용된다 — 피치덱은 결국 투자위원회의 내부 메모가 되고, 입으로 한 모든 숫자는 데이터룸과 대조 검증된다. 즉 제품의 신뢰를 고치는 스킬과 투자를 받는 스킬은 동일한 근육이다