Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
Kepler의 CEO Vinoo Ganesh는 금융 및 정확도가 중요한 산업 분야를 위한 신뢰할 수 있는 AI 구축에 대해 논했습니다. 그는 대규모 모델이 만능은 아니며, 깊은 기술적 문제 해결과 데이터의 정확성이 핵심이라고 강조합니다. Kepler 팀은 Palantir와 Citadel 등에서 경험을 쌓은 전문가들로 구성되어 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기Vinoo Ganesh는 금융을 시작으로 정확도가 중요한 산업 분야를 위한 AI를 구축하는 Kepler의 CEO입니다. Kepler에 오기 전, 그는 Palantir에서 7년간 근무했고, 대체 데이터(alt data) 회사를 설립하고 매각했으며, Citadel에서 비즈니스 엔지니어링을 이끌었습니다.
AIE New York 세션(화요일 오후 2:55에 Jack Woodroffe와 진행하는 라운드테이블 포함)을 앞두고, 그는 The Daily Context와의 인터뷰를 통해 사람들이 신뢰할 수 있는 AI 구축 방법, Kepler의 모델이 숫자를 절대 작성하지 않는 이유, 그리고 그가 더 큰 모델(bigger model)이 답이라고 믿지 않는 이유에 대해 이야기했습니다.
본 인터뷰는 길이와 명확성을 위해 편집되었습니다.
The Daily Context: 배경과 Kepler에 대해 조금 말씀해 주시겠어요?
Vinoo Ganesh: 저는 Kepler의 CEO Vinoo입니다. Palantir에서 Spark와 컴퓨팅 쪽에 중점을 두고 7년간 근무했습니다. 그 후 대체 데이터 회사를 설립하고 성장시켜 인수하게 했습니다. 그 이후에는 Citadel에서 비즈니스 엔지니어링 책임자였으며, 포트폴리오 매니저를 위해 소프트웨어 제품과 데이터 제품을 구축하는 방법에 집중했는데, 아이러니하게도 이것이 지금 Kepler가 하는 일과 매우 유사합니다.
우리 팀은 Palantir 출신 인재들로 구성되어 있습니다. Sarah는 Palantir Ontology의 엔지니어링 리드 중 한 명이었습니다. Chris는 Palantir에서 15년간 근무하며 많은 최적화 작업을 수행했습니다. Meta, Reflection AI, Datavant, Goldman, Oddity 등 다양한 곳 출신의 동료들이 함께하고 있습니다. 따라서 이 팀은 정보와 데이터의 정확도 및 충실도가 중요한 환경에서 제품을 구축하는 데 오랜 시간을 보낸 사람들로 이루어져 있습니다.
The Daily Context: 정말 놀라운 경력이지만, 그런 회사들을 떠나도록 사람들을 설득하기는 어렵습니다. 채용에 어떻게 접근하시나요?
Vinoo Ganesh: 저희는 우리를 신뢰하고, 이전에 함께 일했으며, 다시 합류하는 것에 대해 매우 긍정적으로 느끼는 사람들이 있어서 매우 운이 좋았습니다. 하지만 솔직히 말해서, 저는 항상
결국 몇 가지 핵심으로 귀결됩니다. 첫째, 우리가 해결하는 문제들이 기술적으로 매우 깊습니다. ChatGPT 래퍼(wrapper)처럼 보이는 것들이 많은 세상에서, 아주 깊은 수준의 기술적 문제는 그런 부분에 동기 부여를 받는 엔지니어들에게는 매우 매력적입니다.
둘째, 저희가 다루는 문제 영역이 인류에게 엄청난 중요성을 가진 요소들을 포함하고 있다는 것이 정말 행운입니다. 네, 저희는 금융 분야에서 시작했지만, 신뢰할 수 있는 AI나 코딩화할 수 있는 엔터프라이즈 지능은 마지막으로 남은 알파(alpha)를 창출하는 이정표와 같습니다. Kepler는 그런 면에서 정말 강력합니다. 만약 모두가 동일한 도구에 접근할 수 있다면, 어떤 알파나 고유성이 남아있을까요? 이것이 많은 사람들에게 실존적인 질문이 됩니다.
셋째, 인재가 복리 효과를 냅니다(talent compounds). 저희는 매우 탄탄한 배경지식을 가진 팀이며, 사람들은 아주 뛰어난 엔지니어들과 함께 일하는 것을 좋아합니다. 저희는 재능에 대해 엄청나게 높은 기준을 가지고 있습니다. Adil에게 물어보시면 알 수 있을 겁니다. 저희는 면접 과정에서 공정하려고 노력하지만, 배경 때문에 위축되는 분들도 계십니다. 그런 피드백을 받았습니다: 'ex-Palantir, ex-Citadel 팀에서 일하고 싶다고요? 무섭게 들리네요.' 저는 우리가 다가가기 쉽고 합리적이라고 생각합니다.
일상적인 맥락: AI와 개인적으로 어떤 관계를 가지고 계신가요?
Vinoo Ganesh: 저희 자신을 '조심스러운 소비자(cautious consumers)'라고 묘사하는 것이 가장 좋을 것 같습니다. AI는 방대한 정보 종합에 정말 도움이 됩니다. 특히 비결정론적인 방식(non-deterministic ways)으로 말이죠. 만약 제가 높은 수준에서 이해하거나, 전반적인 느낌만 알고 싶은 여러 개의 질의(queries)가 있다면, AI가 그 부분에서 매우 강력했습니다.
문제는 사람들이 AI를 부적절한 방식으로 사용할 때 발생합니다. 예를 들어 결정론적(deterministic) 작업이나 정확도가 물질적으로 중요한 작업의 경우입니다. AI는 여러 면에서 매우 긍정적이지만, 당신이 말하는 대부분의 내용에 동조한다는 점도 있습니다. 요청하더라도 단계를 따르지 않습니다. 또한 끊임없이 변화하는 목표물입니다. 모델들이 하루에 대략 하나씩 출시되는 속도로 인해, 이 빠르게 변하는 환경을 따라잡는 것은 매우 어렵습니다. 따라서 올바른 방식으로 배포될 때 강력한 도구이자 가속기 역할을 합니다.
데일리 컨텍스트: 당신의 AIE New York 강연은 무엇에 관한 것인가요?
Vinoo Ganesh: 우리는 매일 AI 깊숙이 관여하고 있기 때문에 AI의 잠재력을 매우 명확하게 봅니다. 하지만 간단한 현실은, 대부분의 회사에서 AI에 대한 깊은 노출과 배포가 여전히 초기 단계라는 것입니다. 스스로를 초(超) AI 지향적이라고 생각하는 곳조차도 보통 Copilot을 몇 가지 질의응답에 던지는 정도에 그칩니다.
저희의 질문은 항상 '왜?'입니다. 저희 팀과 동료들이 사용하는 수준까지 도달하는 데 걸림돌이 무엇인가 하는 것입니다. 이는 신뢰(trust)라는 질문으로 돌아옵니다. 그래서 강연 주제는 AI 시스템에 어떻게 신뢰를 구축하느냐이며, 이에 대한 저희의 견해는 다음과 같습니다. AI 시스템을 진정으로 신뢰하려면 단순히 AI만 사용할 수는 없습니다. 주변 인프라가 필요합니다. 이 인프라는 올바한 시나리오에는 AI를 사용하고, 올바한 시나리오에는 다른 도구를 사용하며, 증거를 제시하고, 마지막으로 이미 작업하고 있는 시스템에 깊이 내장되어야 합니다. 저희가 초기 수용자(early adopters)에서 매일 95%의 경우에 깊이 있게 사용하는 사람들에게로 나아가는 과정이 우리가 이야기할 흥미로운 영역이며 현재 상세하게 작업하고 있는 부분입니다.
데일리 컨텍스트: 왜 뉴욕인가요, 샌프란시스코가 아닌가요?
Vinoo Ganesh: 현장에 투입된 엔지니어로서 저는 고객과 지리적, 감정적으로 가까이 있는 것이 매우 중요하다는 것을 배웠습니다. 저희의 초기 고객들은 뉴욕에 기반을 두고 있습니다. 금융 산업은 주로 이곳에 있지만, 이 문제 영역의 긴급성과 중요성은 개발 속도, 기술 채택 속도, 선점 효과, 그리고 더 스마트해지는 모든 것이 중요한 뉴욕에서 독특하게 포착된다고 생각합니다. SF는 여러 면에서 정말 강력하며, 특히 연구 측면이 강하지만, 저희 Kepler는 자체적으로 상당한 양의 연구를 수행함에도 불구하고 응용(applied) 쪽에 매우 초점을 맞추고 있습니다.
일상적인 맥락: 제 연구에 따르면 Kepler는 출처와 비교하여 인용을 실시간으로 확인하며, 그 결과는 스트리밍됩니다. 이것은 어떻게 작동하나요?
Vinoo Ganesh: 사실 저희는 스트리밍 중이나 실시간으로는 그렇게 하지 않습니다. 저희가 운영하는 방식은 특정 것들은 결정론적 도구(deterministic tools)가 항상 더 잘 처리할 수 있다는 것입니다. 그래서 저희는 '사실(facts)'라고 부르는 것을 추출하는 대규모 전처리 단계(preprocessing steps)를 실행합니다. 이 사실들에는 숫자, 개체(entities), 사람, 장소, 사물 등이 포함될 수 있습니다. 저희는 이러한 사실들에 각 고유한 사실을 설명하는 메타데이터로 주석을 답니다. 이는 관계일 수도 있고, 숫자의 경우 크기(magnitude), 규모(scale), 달러인지 파운드인지 등을 나타낼 수 있습니다.
두 번째 부분은 이 모든 데이터를 출처 기록(provenance records)과 함께 영구 저장한다는 것입니다. 데이터가 Kepler 플랫폼을 통과하면서, 플랫폼과 에이전트들은 일관되게 출처 원장(provenance ledger)에 쓰도록 설계되어 있으며, 이 원장은 주어진 순간에 실제로 취해진 모든 이전 단계를 담고 있습니다. 따라서 저희는 LLM이 내리는 모든 비틀림, 모든 방향 전환, 모든 결정을 볼 수 있고, 결정론적인 변경 사항조차 볼 수 있습니다. 만약 두 숫자가 더해지면, 그 결과를 영구 저장합니다. 두 숫자가 곱해지면, 그 곱을 영구 저장합니다. 그리고 저희는 그 숫자가 거쳐 온 변환의 사슬(chain of transformations)을 보여드릴 수 있습니다.
따라서 많은 부분이 매우 상세한 전처리(preprocessing)와 초기 단계의 매우 상세한 엔지니어링(engineering)에 달려 있으며, 이는 우리가 결정론적(deterministic) 부분과 비결정론적(non-deterministic) 부분 사이를 전환할 수 있기 때문에 더욱 복잡해집니다.
일상적인 맥락 (The Daily Context): Kepler의 최초 공개 주식 온톨로지(ontology)에 대해 설명해주시겠어요? 왜 구축하는 것이 중요했나요?
Vinoo Ganesh: 좋은 질문입니다. 인간은 데이터베이스에서 행과 열이라는 개념으로 생각하지 않습니다. 페이스북 친구들을 생각해 본다면, 아마도 관계의 측면에서 생각할 것입니다. '나는 이 사람의 친구다', '나는 이 사람이 몇 살이라고 믿는다'와 같이요. 우리는 이런 복잡하고 관계 중심적인 방식으로 생각합니다.
우리에게 흥미로운 점은, 특히 금융 생태계에서는 회사 이름처럼 간단한 것조차도 코디파이(codify)하고 개체 해상도(entity-resolve)하는 것이 정말 어려운 문제라는 것입니다. 예를 들어, Palantir와 PLTR는 명백히 같은 것을 지칭하지만, 대부분의 시스템은 이를 쉽게 개체 해상도할 수 없습니다. 이 문제는 사람이 무언가를 말할 때 더욱 복잡해집니다. 만약 제가 회사 CFO인데 Palantir를 언급했고, 이것이 잘못 전사(transcribed)되었다면, 어떤 종류의 표준화(canonicalization)나 개체 해상도를 할 수 있을까요?
우리가 깨달은 것은 LLM이 무언가를 어떻게 해결할지 생각하는 데는 정말 뛰어나지만, 실제로 그 해결을 수행하는 것에는 반드시 능숙하지 않다는 것입니다. 온톨로지를 개발함으로써 우리는 몇 가지를 할 수 있게 되었습니다. 첫째, LLM에게 이 온톨로지와 상호작용할 도구(tooling)를 제공하여, LLM은 자신이 가장 잘 하는 일을 하고 도구는 자신이 가장 잘 하는 일을 하도록 했습니다.
또한 비용 관점에서 매우 신중할 수 있게 해줍니다. 우리는 토큰을 최대한 많이 사용하는 것이 더 이상 멋진 새로운 트렌드가 아닌, '토큰 과잉 시대(post token-maxing)'에 살고 있습니다. 토큰에 지출하는 모든 달러에서 최고의 투자 수익률(ROI)을 얻는 것이 매우 중요해졌습니다. Kepler는 각 작업에 맞는 올바른 도구를 사용하는 것을 기반으로 하며, 때로는 온톨로지(ontology)를 통한 결정론적 시스템이 만능을 하려고 하는 잠재적으로 수조 개의 매개변수를 가진 모델보다 훨씬 나은 해결책입니다. 따라서 이 온톨로지는 LLM과 Kepler 자체 실행 엔진 모두가 비교적 쉽게 탐색할 수 있는 방식으로 전처리된 데이터를 표현할 수 있게 해줍니다.
데일리 컨텍스트: 금융 분야에 대한 응용 사례는 매우 명확합니다. Kepler에게 적합한 다른 산업은 무엇일까요?
Vinoo Ganesh: 규제가 엄격하고, 자료의 정확성이 중요한 모든 산업입니다. 저는 이를 농담 삼아 '비(非)분위기 산업'이라고 불렀습니다. 보험금 청구 조정 같은 것을 생각해 보세요. 보험은 저희에게 매우 흥미로운 잠재적 확장 분야입니다. 제조업도 마찬가지고요. 법률 분야도요. 법률은 데이터, 예를 들어 사건 요약본(case briefs)을 생각해보면 내재적인 구조가 있기 때문에 흥미롭습니다. 선례가 있고; A 대 B와 같은 사례가 있으며; 시간 기반의 특성도 있습니다: 이것이 저것보다 먼저 일어났기 때문에 이 선례가 저 것을 무효화합니다.
따라서 데이터의 정확성이 중요한 모든 산업은 Kepler에게 잠재적인 기회입니다. 이것이 바로 우리가 Kepler를 특정 수직 SaaS 플레이(vertical SaaS play)라기보다는 엔진으로 포지셔닝한 이유입니다. 이제 우리는 여러 다른 산업 전반에 걸쳐 수요가 발생하고 있습니다. 국방 분야는 더 최근의 흥미로운 영역이었고, 펀드 오브 펀드(fund of funds)도 마찬가지입니다. 이 모든 공간들이요.
데일리 컨텍스트: Kepler 약속 중 일부는 모델이 절대 숫자를 작성하지 않는 것입니다. 이것은 어떻게 작동하나요? 그리고 Kepler는 Claude 내부에 커넥터를 가지고 있습니다. Claude가 마지막 마일(last mile)을 전달할 때도 그 약속이 지켜지도록 어떻게 보장하나요?
Vinoo Ganesh: 아마도 제가 받아본 질문 중 가장 좋은 질문일 겁니다. 왜냐하면 저희가 이 주제에 대해 이야기하고 싶어 안달이 났는데 아무도 허락해주지 않기 때문입니다.
몇 가지 말씀드리자면, Kepler가 MCP를 갖게 된 것은 사실 Anthropic 측의 요청이었습니다. 이것은 Kepler가 어떤 존재가 되기를 의도적으로 전략적 위치를 잡은 것이 아닙니다. 왜냐하면 지적하신 대로, 만약 Kepler가 MCP를 거친다고 해도 모델은 여전히 환각(hallucinate)을 일으킬 수 있습니다. 잘못된 숫자를 가져오거나, 다른 많은 문제들이 발생할 수 있습니다.
이 문제를 우리가 어떻게 해결하는지 말씀드리겠습니다. Kepler의 Claude는 앱과 함께 제공되므로, 여러분이 보고 계신 것은 Claude가 텍스트 기반 출력을 하는 것이 아니라 렌더링된 애플리케이션입니다. 이 렌더링된 애플리케이션은 완벽한 감사 가능성(auditability)과 추적 가능성(traceability)을 갖추고 있습니다. 저희는 본질적으로 코드의 덩어리(blob of code) 또는 시각화의 덩어리를 Claude에게 다시 전달하고, Claude가 하는 일은 그것을 출력하는 것뿐입니다. 거의 API 호출과 같아서, Claude의 앱 기능이 Kepler UI를 렌더링합니다. 이것이 모든 숫자를 감사 가능하고 추적 가능하게 만드는 요소입니다.
모델이 숫자를 생성하지 않도록 하려면 어떻게 해야 할까요? 저희가 플랫폼에 내장한 불변성(invariant) 덕분입니다. 데이터와 정보를 전처리하여 사실들(facts)에 식별자(identifiers)를 부여합니다. 모델이 할 수 있는 것은 이러한 사실들을 검색하는 결정론적 도구(deterministic tools)를 사용하는 것입니다. 게터(getter)나 세터(setter) 같은 것에 비유할 수 있습니다. 테이블에서 조회를 수행할 수 있고, 모델은 그 조회를 대체하여 사용합니다.
현재 금융 분야에서는 회사 이름이나 숫자가 우리가 중요하게 생각하는 사실들입니다. 하지만 법률 분야에서는 이와 동일한 아이디어를 법정 사건에 적용하여, 모델이 결과를 반환하기 전에 각 사건이 실제로 존재하는지 확인할 수 있습니다. 따라서 현재 만약 모델이 조회(lookup)를 통해 자신의 출력을 해결할 수 없다면, 그것을 거부합니다. 그 사실을 실제로 진술할 수 없습니다.
Daily Context: 이런 일이 발생하면 어떤 의미가 있을까요?