Thariq Shihipar는 Anthropic의 Claude Code 팀에서 일하는 엔지니어이고, South Park Commons(SPC) 출신입니다. 그는 VC 투자를 받은 게임 회사를 5년간 운영하다 접은 뒤, 2025년 3월 Claude Code를 써 보고 깊이 빠져 Anthropic에 합류했습니다. 이 영상은 그가 SPC에 돌아와 파트너 Evan Tana와 대화하고 청중의 질문을 받은 자리를 담고 있습니다.
대화 전체를 관통하는 개념은 capability overhang입니다. 모델의 지능은 이미 하네스와 사용자가 끌어내 쓰는 수준보다 앞서 있고, Thariq는 지금 모델 개발을 멈춰도 앞으로 6～12개월은 새로운 overhang을 찾아내며 보낼 것이라고 말합니다. 그렇다면 병목은 모델이 아니라 모델과 결과 사이에 있는 하네스, 사용자, 조직입니다. 진행자와 청중의 질문은 이 격차를 누가 어떻게 좁히느냐로 모입니다.
제품과 작업 방식에 대한 Thariq의 답은 네 가지로 정리됩니다. 모델이 따라잡은 스캐폴딩은 지우고, 사람들이 Claude에게 프롬프트하는 감각을 기르도록 가르치고, 확신이 없는 일은 싸게 탐색하고, eval은 무엇이 좋은 결과인지 알게 된 뒤에 만듭니다. 조직과 창업에 대해서는 만드는 비용이 줄어도 무엇을 만들지 정하고 믿는 일은 줄지 않으며, 스타트업은 모델 랩을 보완하는 쪽에 베팅하라고 조언합니다. 다만 Claude가 사용자에 따라 얼마나 먼저 나서야 하는지는 그도 풀지 못한 문제로 남겨 둡니다.
모델은 이미 하네스와 사용자가 끌어내는 것보다 똑똑하다
capability overhang은 모델의 지능이 하네스나 사용자와의 상호작용으로 실제로 드러나는 수준보다 앞서 있는 상태를 가리킵니다. Thariq는 이것을 모델이 영원히 안고 갈 문제로 봅니다. 모델은 세대마다 똑똑해지지만 영역마다 고르지 않고 직관에 어긋나는 방식으로 똑똑해지기 때문에, 새 능력을 어떻게 쓸지는 설명하기 어려운 방식으로 직접 체득해야 합니다.
그가 드는 사례는 컨텍스트 창입니다. 2024년에는 모델이 코딩을 잘하게 되는 길이 컨텍스트 창의 확대라는 생각이 흔했습니다. 1억 토큰짜리 창이 나오면 코드베이스 전체를 넣고 문제를 풀게 된다는 것입니다. Claude Code가 보여 준 답은 달랐습니다. 모델이 스스로 컨텍스트를 만들 수 있다면 같은 문제를 다른 방식으로 풀 수 있고, 이 점을 깨닫지 못했다면 1억 토큰 창이 나오기만 기다리고 있었을 것이라고 그는 말합니다.
plan mode는 overhang이 닫히는 과정을 보여 줍니다. plan mode가 처음 나왔을 때는 질문만 던지면 모델이 제대로 해내지 못했기 때문에, 미리 계획을 명확하게 세운 뒤 실행하게 하는 기능이었습니다. 지금은 Claude Code 팀의 많은 사람이 plan mode를 쓰지 않습니다. 모델이 알아서 올바르게 생각하고, 사용자가 충분히 구체적으로 설명하면 모델이 실행하는 방법도 알기 때문입니다.
손으로 짠 스캐폴딩은 모델이 따라잡는 순간 지워야 한다
진행자 Evan Tana는 지금의 능력에 과적합하지 않고 다음 도약을 활용하려면 프롬프트와 스킬과 에이전트를 어떻게 미리 설계해야 하느냐고 묻습니다. Thariq는 정말 어려운 문제라고 인정하면서, 실제로 Claude Code 팀은 하네스의 많은 부분을 늘 다시 쓰고 있고 프런티어에 머물려면 그럴 수밖에 없다고 답합니다. 그가 제안하는 관점은 과정이 아니라 결과를 받아 쓰는 입장에서 생각하는 것입니다. 과정이 정확히 어떻게 진행될지는 몰라도 결과가 좋아지리라는 점에는 대비할 수 있습니다.
대담 당일 공개된 workflows가 그 예입니다. 검색을 백 번쯤 해야 하는 deep research 같은 작업은 예전에는 사람이 하네스를 직접 코딩해서 처리했습니다. workflows에서는 Claude가 그 작업에 맞는 하네스를 즉석에서 만들어 실행합니다. Claude Code에 이 주제를 오래 조사하라고 프롬프트만 했다면 서브에이전트를 써도 컨텍스트 창 안에서 해내지 못했을 일을, 맞춤 하네스로는 해냅니다.
청중의 질문. 스킬, memory, 계획 기능처럼 여러 플랫폼의 하네스가 비슷한 방식으로 수렴하고 있는데, 결국 하나의 방식으로 통일될 것이라고 봅니까? Thariq는 memory를 예로 들어 답합니다. memory는 RAG로 할지, 파일 검색으로 할지, 학습으로 할지, 어떤 RL 환경을 쓸지까지 선택해야 할 변수가 매우 많은 문제이고, 맞춤 memory 시스템을 만드는 일은 아주 재미있습니다. 문제는 그다음입니다. 창업자가 특정 능력에 맞춰 v1을 만든 뒤 v2를 만들 사람을 끝내 뽑지 못하는 경우가 많습니다. 하네스, 스킬, 프롬프트를 다루는 하네스 엔지니어링이 워낙 희소한 기술이기 때문입니다. 그 결과 memory 시스템은 Opus 4 시절에 만든 상태로 멈춰 있곤 합니다. 그는 이 기술이 잘되고 있는지 스스로 알기조차 어렵다고도 말하고, 이 일을 메타 에이전트에게 재귀적으로 맡길지를 두고는 Anthropic 안에서도 의견이 갈린다고 전합니다.
그래서 Thariq는 스캐폴딩을 만드는 것도 좋지만 지우는 일이 정말 중요하다고 말합니다. 모델이 어떤 일을 잘하게 되면 그 일을 위해 만든 장치를 걷어내야 합니다. Opus 4.7과 4.8은 파일로 memory를 읽고 쓰는 데 능하고, Anthropic도 memory가 그렇게 다뤄질 것으로 봅니다. memory를 파일로 다루는 방향이 자리 잡은 뒤에도 맞춤 스캐폴딩을 유지하는 것은 드문 일이어야 합니다. 컨텍스트 검색을 위한 RAG는 이제 안티패턴에 가깝고 grep을 쓰는 편이 낫지만, 2024년에 RAG 인덱싱을 만든 스타트업은 많습니다.
청중의 질문. 하네스 설계는 도메인마다 달라야 합니까? Thariq는 Anthropic에 오기 전에 자신이 만든 스프레드시트 에이전트를 예로 듭니다. 코드를 생성하는 하네스였고, 스프레드시트 작업에서는 Claude Code보다 나을 것이라고 그는 봅니다. 그러나 Claude Code의 하네스는 모델이 좋아지는 지수 곡선을 더 잘 따라가고, 자신은 자신이 만든 하네스를 혼자 계속 고쳐야 합니다. 그만한 가치가 있는지는 자신도 모르겠다고 그는 답합니다.
모델이 사람보다 앞서 있으면 사람을 가르치는 일이 기능 개발보다 값질 수 있다
Thariq의 관심사는 사람과 에이전트가 주고받는 정보의 양을 늘리는 일입니다. 그가 Claude Code 팀에서 처음 만든 기능 중 하나인 ask user questions는 계획 단계에서 Claude가 작업을 멈추고 사용자에게 하려는 일을 되물어 분명히 하게 합니다. 그전에는 사용자가 원하는 것을 자세히 설명해야 했고, 자신이 모른다는 사실조차 모르는 것까지 미리 알아야 했습니다. 이 기능은 Claude Code에서 가장 인기 있는 기능 중 하나가 되었습니다.
그런데 이 일을 오래 할수록 그는 에이전트 UX를 개선하는 것보다 사람을 가르치는 것이 더 중요할 때가 있다고 느꼈습니다. 모델이 똑똑해질수록 모델이 할 수 있는 일이 훨씬 많아지기 때문입니다. Claude에게 어떻게 프롬프트할지에 대한 멘탈 모델을 쌓도록 돕는 일이 제품 작업을 더 하는 것보다 가치가 클 수 있고, 자신도 그 일을 더 잘한다고 그는 말합니다.
청중의 질문. 파워 유저가 평균 사용자보다 프런티어 모델에서 최대 7배 높은 추론 능력을 끌어낸다는 연구가 있는데, 사용자를 가르치는 UX로 이 격차를 줄일 수 있습니까? Thariq는 두 방향 모두 필요하다고 답합니다. 에이전트 UX도 개선해야 하고 사람을 가르치는 일도 가치가 큽니다. 다만 새로운 것을 계속 배워야 한다는 피로를 사람들이 느끼는 것은 좋지 않은 일이고, 이상적으로는 Claude가 먼저 나서서 딱 필요한 만큼 일을 해 주어야 합니다. 이것이 어려운 이유를 그는 Boris의 예로 설명합니다. 코드베이스를 속속들이 아는 Boris와 자신이 같은 변경을 요청할 때, 자신에게는 Claude가 이 변경이 어떤 연쇄 효과를 낳는지 아느냐고 물어 주는 것이 도움이 되지만 Boris에게는 쓸데없는 질문입니다. 모델과 하네스만이 아니라 사용자와 세계까지 함께 얽혀 있는 문제이고, 그는 이것을 지금 AI에서 가장 큰 문제 중 하나로 꼽습니다.
다음 질문은 Claude Code가 하나의 세션으로 계속 이어지며 기억을 쌓고 먼저 움직이는 행위자가 될 수 있느냐는 것이었습니다. Thariq는 그 방향으로 작업하고 있지만, 그것이 필요할 때 서브에이전트를 띄우는 하나의 Claude일지, workflows 같은 오케스트레이션일지, UX의 문제일지 아직 알아낼 것이 많다고 답합니다.
확신이 없으면 싸게 탐색하고, 문제를 다 안다고 확신할 때만 길게 맡긴다
진행자가 Thariq가 쓰는 메타 프롬프트를 묻자, 그는 문제를 네 칸으로 나눠 본다고 답합니다. 아는 줄 아는 것(known knowns)은 원하는 것이 분명한 경우이고, 남은 질문은 그것을 프롬프트에 실제로 적었느냐입니다. 알면서도 아는 줄 모르는 것(unknown knowns)은 보면 알아보지만 미리 설명하지는 못하는 경우입니다. 모르는 줄도 모르는 것(unknown unknowns)은 그런 일이 가능한지조차 모르거나 시스템을 충분히 이해하지 못한 경우입니다. 모르는 줄 아는 것(known unknowns)은 어떻게 작동하는지는 모르지만 알아내고 싶은 경우입니다. 모든 문제를 이 네 칸으로 나눠 보면 어떻게 프롬프트할지가 드러난다고 그는 말합니다.
칸마다 쓰는 방법이 다릅니다. 프롬프트를 쓰기 귀찮을 때는 거꾸로 모델에게 인터뷰를 시킵니다. 자기 아이디어를 말한 뒤 ask user questions 도구로 자신을 인터뷰하라고 하고 그 질문에 답하는 방식입니다. 디자인처럼 보면 알 수 있는 경우에는 탐색을 여러 개 시킵니다. 이 디자인을 탐색해 HTML 목업을 여러 개 만들어 보여 달라고 한 뒤, 네 개쯤 나온 결과 가운데 마음에 드는 쪽을 다시 탐색하게 합니다.
여기서 그가 강조하는 원칙은 아직 알아내는 중이라면 싸게 하라는 것입니다. UI는 HTML로 만드는 편이 저렴합니다. 실제로 동작하지 않는 모형이기 때문입니다. HTML에서 버튼을 추가하면 그냥 버튼 하나이지만, 실제 앱 안에서는 새 라우트와 reducer 같은 연결 작업이 딸려 옵니다. 백엔드 엔드포인트나 테스트도 마찬가지이므로, 결과물이 원하는 것인지 가장 싸게 확인하는 방법을 찾으면 됩니다.
청중의 질문. 오래 걸리는 작업 하나를 맡기면 자동 컨텍스트 압축에 의존하게 되는데, 범위가 작은 작업을 병렬로 돌리는 편이 낫습니까? Thariq는 Claude Code 팀 안에서도 의견이 갈리고 아주 긴 작업을 선호하는 사람도 있다고 전제한 뒤, 자신은 누가 봐도 야심 찬 작업이면서 미리 다 명세할 수 있는 경우가 아니라면 조금 짧은 작업을 선호한다고 답합니다. Max 20x 요금제의 한도에 걸리는 사람들을 보면, 굳이 길 필요가 없는 작업을 길게 만들었거나 자신이 이 문제를 다 알고 있는지 따져 보지 않은 경우가 많다는 것입니다. 프롬프트 하나에 검증 에이전트 다섯 개를 붙이고 그 결과를 고치는 작업에 12시간을 돌리도록 설계할 수도 있지만, 그 12시간이 필요 없었을 수도 있습니다.
eval은 무엇이 좋은 결과인지 알게 된 뒤에야 만들 수 있다
진행자는 Anthropic 개발자 컨퍼런스에서 에이전트 설계의 핵심 원칙으로 제시된 eval 기반 hill climbing을 들며, 새 모델이 나오면 eval을 돌려 시스템이 스스로 바뀌게 하느냐고 묻습니다. Thariq는 검증 가능한 결과를 향해 반복하는 일에 모델이 좋아졌다는 데서 출발합니다. Karpathy가 공개한 autoresearch는 손실을 줄이라는 목표를 주면 목표에 도달할 때까지 반복하는 하네스이고, 가끔 이상한 일을 하지만 대체로 작동합니다. Bun의 Jared가 Bun을 Rust로 다시 쓴 일도, 매우 엄격한 테스트 스위트를 주면 모델이 작업을 해낸다는 예입니다.
그러나 Thariq는 새 기능을 개발할 때 eval을 거의 쓰지 않습니다. workflows도 긴 작업용 eval을 먼저 만들지 않았고, 그 점수를 보며 개발하지도 않았습니다. eval은 zero-to-one을 위한 도구가 아니므로, 많은 스타트업에는 eval을 만들기보다 빠르게 반복하며 제대로 되고 있는지에 대한 감을 쌓는 편이 낫다고 그는 말합니다. 진행자가 기능이 자리 잡아 유지하고 개선해야 할 때 eval에 투자하는 것이냐고 되묻자, 그는 그럴 수도 있다고 수긍하면서 단서를 붙입니다. 창업자가 첫 시스템을 만든 뒤 다음 시스템을 만들 사람들을 관리해야 할 때 eval은 진행 상황을 보이게 하는 수단이 되지만, 그것이 곧 결과를 만들어 내는 일은 아니라는 것입니다. Anthropic에서도 어떤 부분은 꽤 늦은 단계까지 예술에 가까운 일로 남아 있다고 그는 덧붙입니다.
청중의 질문. eval이 과학이라기보다 예술에 가깝다면, 무언가가 정말 준비되었는지는 어떻게 압니까? Thariq는 하네스 엔지니어링 전체는 예술이지만 eval은 점수를 놓고 hill climbing할 수 있으므로 과학에 조금 더 가깝다고 답합니다. 한계는 모든 문제에 eval을 둘 수 없다는 점입니다. 사람들이 Claude Code가 멍청해진 것 같다고 말할 때 SWE-bench나 SWE-bench Pro를 돌리면 소프트웨어 엔지니어링 성능은 측정할 수 있지만, 사람들이 실제로 말하는 것은 Claude가 계속해야 할 때 너무 일찍 멈춘다는 것일 수 있습니다. 그러면 조기 중단을 측정하는 eval이 필요한데, 그 문제를 직접 보기 전에는 그런 eval이 필요한지 알 수 없습니다.
좋은 eval을 설계하는 일 자체도 매우 어렵습니다. 그는 트위터에서 화제가 된 일본인 사례를 듭니다. 3년 동안 수백만 장의 이미지에 사람의 눈과 입과 골격을 둘러싼 경계 상자를 아주 정밀하게 그린 사람으로, 그 결과물은 다른 어떤 얼굴·골격 인식 시스템보다 낫습니다. 그 일은 지독하게 지루하면서도 높은 숙련이 필요해서 외주를 주기도 어렵고, 그래서 eval은 돈으로 사기도 어렵습니다. Thariq는 AI 분야에서 무언가를 해 보고 싶다는 사람에게 지위가 낮고 매력적이지 않은 일을 고르라고 권하며, eval이 바로 그런 일이라고 말합니다.
만드는 비용이 줄어도 매출은 무엇을 만들지 정하고 밀어붙이는 일에서 나온다
AI가 조직 설계를 어떻게 바꾸느냐는 진행자의 질문에 Thariq는 먼저 선을 긋습니다. Claude Code 팀은 제품을 만들기 위해 그 제품을 쓰는 dogfooding 조직이어서 피드백 루프가 다른 조직과 다르고, 다른 조직이 따라야 할 모델이라고 말하기 어렵다는 것입니다. 대신 그가 출발점으로 삼는 질문은 생산성을 어떻게 매출로 바꾸느냐입니다. 고객사와 이야기하다 보면 PR을 두 배로 늘려도 매출은 전혀 달라지지 않겠다고 느낄 때가 있다고 그는 말합니다. 조직이 하는 일의 상당 부분은 buy-in을 얻고, 무엇을 할지 정하고, 사람들이 그것을 원하는지와 시장이 포화되었는지를 판단하는 일이기 때문입니다. 대부분의 시도는 실패하고, 정말 통하는 것을 찾지 못하면 더 빨리 실패한다고 돈을 더 버는 것도 아닙니다.
그가 쓰는 비유는 1995년의 자동차 딜러입니다. 이메일이 나왔을 때 접수 직원과 팀에게 이메일을 주면 조금 더 빨리 소통하고 생산성도 오르겠지만, 차를 더 팔지는 알 수 없습니다. 반대로 이메일과 웹으로 차를 주문받게 하면 매출이 늘 수 있습니다. 자기 문제에 맞는 이런 비유를 찾는 것이 하나의 방법이라고 그는 말합니다.
진행자는 무엇이든 싸게 만들고 병렬로 띄울 수 있게 되면서 우선순위를 어떻게 정해야 할지 혼란스럽다고 말합니다. 작업 규모를 티셔츠 사이즈로 가늠하던 예전 방식이 이제 무슨 의미가 있느냐는 것입니다. Thariq의 답은 무언가를 만들어 내는 데 필요한 끈기는 거의 줄지 않았다는 것입니다. 그는 Anthropic에서 통한 프로젝트로 Claude Design을 들며, Nate를 처음 만났을 때 이 일이 일어나기를 정말 원하고 결국 해낼 사람이라고 느꼈다고 말합니다. 만드는 비용은 싸졌지만 이제는 buy-in을 얻고 스스로 그 일을 믿어야 합니다. 탐색 단계는 길어져야 하지만, 이것이 방향이라고 정하는 사람은 결국 자신입니다.
청중의 질문. Anthropic은 매우 빠르면서도 품질이 높은데, 다른 조직과 무엇이 다릅니까? Thariq는 인재 수준이 높다는 점과 함께 Dario의 태도를 꼽습니다. 좋고, 빠르고, 싼 것 가운데 둘을 고르라는 트레이드오프는 합리적으로 들리지만, Dario는 셋 다 하면 안 되느냐고 되묻습니다. 합리적인 제품 감각으로 우선순위를 정한 판단이 틀렸을 수도 있고, 진짜 트레이드오프는 끝까지 밀어붙여 현실에서 확인해야 드러나며, 그렇게 드러난 결과는 직관에 어긋날 때가 있다는 것입니다. 그래서 다소 비합리적이더라도 안전한 AI를 만들면서 매출도 크게 내고 세상에 가치를 주며, 위를 향한 경쟁(race to the top)을 할 수 있다고 밀고 나가는 편이 낫다고 그는 말합니다.
스타트업은 불확실성을 즐기며 모델 랩을 보완하는 쪽에 베팅해야 한다
진행자는 SPC의 친구들이 모델 랩에 밀려나지 않고 모델의 발전을 활용하려면 어떻게 해야 하느냐고 묻습니다. Thariq는 AI의 발전 방향을 모두가 예측하기 어렵다는 데서 시작합니다. Dario가 말했듯 Anthropic도 필요한 컴퓨트를 몇 년 앞서 사 두어야 하고, 수십억 달러어치를 산 뒤 그만큼 매출이 나기를 바라는 위험을 집니다. 그는 지금을 프런티어 랩을 포함한 모두가 무엇이 가능한지 알아가는 탐험의 시대로 봅니다.
그래서 스타트업을 한다고 하면 왜 하느냐, Anthropic이나 OpenAI가 하지 않겠느냐는 질문을 받게 된다고 그는 말합니다. 실리콘밸리에서 스타트업은 오랫동안 안전하고 지위 높은 선택이었지만 이제는 그렇지 않습니다. 탐색과 불확실성을 즐길 수 있어야 하고, 그래도 나는 할 수 있다고 정말로 믿는 내적 확신이 가장 중요하다고 그는 말합니다. 자신도 성공한 스타트업을 만들어 본 적이 없으니 전문가는 아니라는 단서도 붙입니다.
구체적인 방향으로 그는 모델 랩을 보완하는 일을 꼽습니다. 세상의 많은 부분은 아직 에이전트를 위해 만들어지지 않아서, 에이전트는 사용자의 건강 데이터나 은행 계좌에 접근하지 못합니다. 이렇게 잠긴 데이터를 에이전트가 쓸 수 있는 형태로 바꾸는 일은 매우 가치 있고, 그 과정에서 새로운 결제 방식이 필요할 수도 있습니다. 규제가 있는 틈새 분야에 AI를 보급하는 일도 마찬가지입니다. 진행자가 데이터 접근 권한을 얻으려 상대를 설득하는 일처럼 사람이 풀어야 하는 문제에서 해자가 생긴다고 덧붙이자, Thariq는 동의하면서도 Anthropic보다 나은 코딩 하네스를 만드는 사람이 나올 수도 있다고 말합니다.
또 하나는 그가 바다를 끓인다(boiling the ocean)고 부르는 발상입니다. 제품에 AI를 얹는 대신, 예전에는 너무 야심 차서 할 수 없던 일을 AI의 능력으로 하는 것입니다. 그는 React 팀에서 일했던, 자막에서 Chang으로 표기된 개발자가 브라우저의 텍스트 렌더링 문제에 시달리다 맞춤 텍스트 렌더링 라이브러리 pretext를 만든 일을 예로 듭니다. 예전에는 할 수 없었을 일을 이제는 그냥 해낼 수 있습니다. 2천만 줄이나 5억 줄의 코드가 필요했던 문제를 이제 풀 수 있다면 무엇을 하겠느냐는 것이 그가 던지는 질문입니다.
반론. 예전이라면 사람들이 좋아하는 개발 도구를 보고 그대로 올라타 큰 사업으로 키웠겠지만, 지금은 Conductor 같은 제품을 의심스럽게 봐야 하지 않습니까? 진행자는 자신이 많이 쓰는 Conductor를 예로 들고, Anthropic을 대표하지 말고 개인으로서 답해 달라며 이렇게 묻습니다. Thariq는 모든 제품이 모델의 능력이 어디로 향할지에 거는 베팅이라고 답합니다. Conductor는 모델이 범용화되고 성능 향상이 S커브처럼 완만해진다는 쪽에 건 좋은 베팅입니다. 사람들이 사랑하는 것을 만들면 좋은 결과로 이어질 길은 많으니 전략적으로 옳은지 지나치게 고민할 필요는 없고, 모델도 계속 싸지고 있다고 그는 말합니다. 어느 베팅이 이길지는 분명하지 않지만, 베팅은 해야 합니다.
정리된 것과 남은 것
Thariq가 대화 내내 되풀이한 생각은 하나입니다. 모델은 이미 하네스와 사용자보다 앞서 있으므로, 더 나은 모델을 기다리기보다 하네스와 사용 방식과 조직을 바꿔 그 격차를 좁혀야 한다는 것입니다.
남은 문제도 그가 직접 밝혔습니다. Claude가 사용자마다 얼마나 먼저 나서야 하는지는 모델, 하네스, 사용자, 세계가 얽힌 문제이고, 그는 이것을 지금 AI의 가장 큰 문제 중 하나로 꼽았습니다. 하네스 엔지니어링을 메타 에이전트에게 재귀적으로 맡길지는 Anthropic 안에서도, Claude Code 팀 안에서도 의견이 갈립니다. 도메인에 맞춘 하네스가 지수 곡선을 따라가는 범용 하네스보다 유지할 가치가 있는지, Conductor 같은 제품 베팅 가운데 무엇이 이길지도 그는 모른다고 말했습니다. 청중이 인용한 7배 격차 연구는 출처가 제시되지 않았고, Thariq도 그 수치에 대해서는 언급하지 않았습니다.