RelationalAI Reasoner GA, Snowflake 에이전트의 최적화 계산

AI 요약

• 무슨 일: RelationalAI가 6월 2일 Snowflake Summit 26에서 Rel의 decision intelligence 기능을 확대했습니다.
  • Prescriptive reasoner GA, predictive reasoner, Rel App, CoWork 연동, push-button post-training private preview가 함께 발표됐습니다.
• 개발자 접점: Snowflake CoCo, Claude Code, OpenAI Codex, GitHub Copilot에서 쓰는 RelationalAI coding agent skills가 포함됐습니다.
• 주의점: OSI 포팅과 post-training은 표준·preview 성격이 강합니다. 실제 평가는 권한, 비용, 모델 재사용 단위로 해야 합니다.

RelationalAI가 2026년 6월 2일 Snowflake Summit 26에서 Snowflake AI Data Cloud 안에서 실행되는 Rel의 새 기능을 발표했습니다. 공식 보도자료는 Rel App, prescriptive reasoner, predictive reasoner, Snowflake CoWork 안의 conversational decision intelligence를 한 묶음으로 설명합니다. 기업 데이터와 semantic estate를 대상으로 한 post-training도 같은 발표에 들어갔습니다. 제품 문구만 보면 “또 하나의 agentic AI 발표”처럼 보이지만, 개발자 관점에서 새로 볼 부분은 따로 있습니다.

이번 발표의 중심은 LLM이 자연어 답변을 만드는 화면이 아닙니다. RelationalAI는 decision agent가 가격, 공급망, 네트워크 운영, 자원 배분 같은 업무에서 action을 고르려면 기업 모델, reasoner 도구, 업무별 post-training이 필요하다고 말합니다. 여기서 기업 모델은 concepts, relationships, rules를 담은 semantic model이고, reasoner는 제약조건과 예측값을 계산하는 엔진입니다. LLM이 “무엇을 할까요”를 말하는 단계에서 “어떤 제약 아래 어떤 선택지가 최적인가”를 계산하는 단계로 제품 범위를 넓힌 셈입니다.

RelationalAI가 새로 내놓은 Rel App은 기업이 어떻게 움직이는지를 공유되고 governed한 표현으로 잡는 도구입니다. 발표문은 concepts, relationships, rules를 명시하고, domain expert가 모델을 탐색하고, 연결을 따라가고, 자연어로 질문하며, Snowflake 안의 자기 데이터에 grounding된 결정을 검토할 수 있다고 설명합니다. 이 설명은 BI semantic layer와 비슷해 보이지만, RelationalAI가 붙인 단어는 analytics가 아니라 decision intelligence입니다. 쿼리 결과를 보여주는 데서 멈추지 않고, 결정 규칙과 제약조건까지 모델 안에 넣겠다는 뜻입니다.

Prescriptive reasoner의 일반 공급은 이번 발표에서 가장 구체적인 실행 신호입니다. RelationalAI는 이 reasoner가 constrained optimization 문제를 풀기 위한 purpose-built tool이라고 설명했습니다. 공급망 배차, 재고 배분, 가격 조정, 네트워크 용량 계획처럼 여러 제약조건이 동시에 걸리는 문제에서는 LLM이 그럴듯한 조언을 쓰는 것만으로 부족합니다. 예산, 재고, SLA, 인력, 위치, 계약 조건이 숫자로 충돌할 때는 최적화 문제를 풀어야 합니다. RelationalAI는 이 계산을 Snowflake 안에서 decision agent가 호출하는 도구로 만들려 합니다.

Predictive reasoner는 다른 절반입니다. 발표문은 graph neural networks를 Snowflake의 enterprise data에 적용해 demand, churn, asset failure 같은 결과를 예측한다고 적었습니다. 예측값만 있으면 “다음 달 이탈 확률이 높은 고객 목록”에서 멈춥니다. Prescriptive reasoner와 묶이면 “이 예측을 전제로 어떤 할인을 누구에게, 어느 채널에서, 어떤 예산 한도 안에서 배정할 것인가”로 이어집니다. RelationalAI가 말한 forecast-to-recommended-action workflow는 이 두 단계를 한 agent workflow 안에 넣겠다는 주장입니다.

개발자에게 더 직접적인 문장은 발표문 중간에 있습니다. RelationalAI는 Snowflake CoCo, Claude Code, OpenAI Codex, GitHub Copilot에서 작동하는 coding agent skills library가 커지고 있다고 밝혔습니다. 이 skills를 통해 joint customers가 선호하는 개발 환경에서 RelationalAI model을 직접 확장하고, decision agent가 쓰는 context를 깊게 만든다는 설명입니다. 일반적인 코딩 에이전트가 애플리케이션 코드를 고치는 동안, 이 skills는 semantic model, reasoner 설정, Snowflake-native data context를 수정하는 쪽에 가깝습니다.

이 접점은 Snowflake CoCo 발표와도 맞물립니다. Snowflake는 Summit 26에서 CoCo를 데이터 작업용 코딩 에이전트 제품군으로 확대했고, Claude Code와 VS Code 같은 외부 개발 환경으로 통합을 넓혔습니다. RelationalAI skills는 그 표면 위에서 “데이터 모델과 reasoning 모델을 에이전트가 변경하는 작업”을 맡을 수 있습니다. 개발팀은 여기서 프롬프트 품질보다 변경 단위를 먼저 봐야 합니다. agent가 만든 semantic relationship 하나가 pricing, churn, routing, capacity decision에 쓰인다면, diff review와 테스트 데이터가 코드 리뷰만큼 중요해집니다.

OSI 이야기는 더 구조적입니다. Snowflake는 2026년 1월 27일 Open Semantic Interchange specification을 공개했습니다. 첫 버전은 Apache 2.0 GitHub repository로 열렸습니다. OSI는 datasets, metrics, dimensions, relationships, contexts 같은 semantic layer 구성을 여러 도구가 해석할 수 있는 vendor-neutral 모델로 표현하려는 표준입니다. Snowflake 블로그는 기업에서 churn rate나 net margin 같은 정의가 도구마다 갇히면 팀이 같은 의미를 반복해서 재구축한다고 설명했습니다.

RelationalAI는 이번 발표에서 OSI launch partner로서 기존 ontology deployments, 예를 들어 Palantir 기반 semantic model을 Snowflake로 port하고 RelationalAI의 advanced reasoning을 재구축 없이 실행할 수 있다고 말했습니다. 이 주장은 강합니다. Palantir Foundry나 AIP를 쓰던 기업이 ontology를 통째로 버리지 않고 Snowflake AI Data Cloud 안의 RelationalAI reasoning으로 가져올 수 있다는 메시지이기 때문입니다. 다만 “재구축 없음”은 보도자료의 표현입니다. 실제 프로젝트에서는 metric definition, permission, lineage, action rule, UI behavior, 운영 알림이 같은 의미로 옮겨지는지 따로 검증해야 합니다.

Open Semantic Interchange 공식 사이트는 working group을 다섯 갈래로 나눕니다. Advanced Metrics & Expression Language, Composability, Catalog Integration, Ontology Representation, Model Converters & Developer Tools입니다. 이 분류는 데이터 에이전트가 왜 semantic layer만으로 끝나지 않는지 보여줍니다. metric 계산식이 portable해야 하고, 모델이 서로를 참조해야 하며, catalog와 governance 도구에 연결돼야 하고, ontology 표현과 converter tooling이 필요합니다. agent가 자연어로 “가장 위험한 고객군을 찾아 대응해줘”라고 요청받으면, 이 모든 층위가 실행 품질에 영향을 줍니다.

Push-button post-training은 아직 private preview입니다. RelationalAI는 기업의 data와 semantic estate를 대상으로 open-source LLM을 특화하는 기능이라고 설명했습니다. 발표문은 이렇게 특화된 enterprise-specific post-trained model이 frontier model과 결합될 때 더 어려운 문제를 낮은 비용으로 풀 수 있고, 회사의 terminology와 decision logic을 배울 수 있다고 주장합니다. 이 기능은 매력적이지만, 공개된 수치가 부족합니다. 어떤 open-source LLM을 대상으로 하는지, post-training 데이터가 어디에 저장되는지, 평가셋을 누가 만들고 승인하는지, 모델 업데이트 후 기존 reasoner 결과가 어떻게 달라지는지 확인해야 합니다.

비용 주장은 특히 조심해서 읽어야 합니다. RelationalAI는 LLM-based reasoning과 domain-specific reasoners를 결합하면 accuracy gain과 cost reduction이 있다고 말했지만, 발표문은 독립 벤치마크나 구체 수치를 제시하지 않았습니다. 비용 절감이 추론 토큰 감소에서 오는지, 최적화 엔진 호출로 반복 프롬프트를 줄이는 데서 오는지, Snowflake 내부 데이터 이동을 줄이는 데서 오는지 분리해야 합니다. 기업 의사결정 workload는 성공한 답변 하나보다 실패한 추천의 비용이 더 클 수 있습니다.

Snowflake Summit 26 주변 반응은 발표의 온도를 낮춰 줍니다. Reddit r/snowflake의 한 참가자는 open semantic interchange, Horizon Context, agentic 기능이 여러 세션에서 제품 pitch처럼 반복됐다고 적었습니다. 같은 글은 SQL 작성과 Python 코딩, dashboard 작성이 자동화될 때 데이터 역할이 어떻게 바뀌는지에 대한 답은 부족했다고 비판했습니다. 다른 참가자는 cost optimization, governance, Iceberg deep dive 세션에는 기술 내용이 있었고, 세션 선택에 따라 경험이 달랐다고 반박했습니다. 이 반응은 RelationalAI 발표를 읽을 때도 유용합니다. 기업 데이터 팀은 agentic이라는 이름보다 실제 검증 가능한 모델, 비용, 권한, 운영 절차를 요구합니다.

별도 Snowflake Summit 기능 정리 스레드도 같은 점을 보여줍니다. 사용자는 Apache Iceberg v3, Datastream, CoCo Desktop, Cloud Agents, Skill Catalog, Horizon Context를 포함한 출시와 preview 항목을 모아 달라고 요청했습니다. Semantic Studio, Agent Identify, Prompt Injection Detection도 같은 질문 안에 들어갔습니다. 댓글에는 CoCo ecosystem extensions와 autonomous task execution, audit trails, semantic views, prompt injection detection이 함께 정리됐습니다. 발표가 많을수록 실제 채택자는 “무엇이 GA이고, 무엇이 private preview이며, 무엇이 파트너 발표인가”를 구분해야 합니다.

RelationalAI의 경쟁자는 한 제품군으로만 묶기 어렵습니다. Palantir는 ontology와 action workflow를 오래 밀어온 회사이고, Databricks는 Unity Catalog와 AI/BI로 데이터 거버넌스와 AI 작업을 연결합니다. Microsoft Fabric은 semantic model과 Copilot surface를 결합하고, Salesforce는 Tableau와 Agentforce를 업무 데이터 쪽으로 밀고 있습니다. dbt Semantic Layer, Cube, AtScale, MetricFlow 같은 도구들은 metric과 semantic definition의 재사용 문제를 다룹니다. RelationalAI의 차별점은 Snowflake 안에서 semantic model과 reasoner를 붙이고, coding agent skills로 모델 확장을 개발 workflow에 연결한다는 점입니다.

개발팀이 이 발표를 검토한다면 첫 질문은 “LLM이 더 똑똑해졌는가”가 아닙니다. 더 나은 질문은 “decision agent가 어떤 근거와 제약조건으로 action을 추천했는가”입니다. 예측 모델이 고객 이탈 가능성을 만들고, prescriptive reasoner가 할인 예산을 배정하고, LLM이 담당자에게 설명을 쓰는 구조라면 각 단계의 책임과 로그가 분리돼야 합니다. Snowflake 안에서 실행된다는 점은 데이터 이동과 권한 통제에 장점이 있지만, Snowflake credit, warehouse 사용량, model invocation 비용이 어디에 기록되는지도 같이 봐야 합니다.

두 번째 질문은 agent가 모델을 고칠 때의 리뷰 절차입니다. RelationalAI coding skills가 CoCo, Claude Code, Codex, Copilot에서 모델을 확장한다면, 결과물은 일반 TypeScript diff보다 업무 영향이 클 수 있습니다. relationship 하나가 잘못 연결되면 segmentation, route optimization, inventory allocation, risk scoring이 틀어질 수 있습니다. 따라서 모델 변경에는 샘플 데이터 테스트, 기존 metric 회귀 테스트, domain expert 승인, 운영 적용 전 shadow run이 필요합니다. 코딩 에이전트의 속도를 그대로 semantic model 변경에 적용하면 사고 범위가 데이터 제품 전체로 커질 수 있습니다.

세 번째 질문은 OSI portability의 경계입니다. OSI specification이 Apache 2.0 repository로 열렸고, Snowflake는 foundation-led governance로 옮길 계획을 말했습니다. 이것은 긍정적인 표준화 신호입니다. 그러나 표준이 표현할 수 있는 것과 특정 플랫폼이 실행하는 것은 다릅니다. Palantir ontology의 action, permission, UI affordance, event trigger, operational workflow가 OSI semantic definition으로 모두 보존되는지는 케이스별로 확인해야 합니다. 포팅 프로젝트에서 가장 위험한 문장은 “의미 모델이 옮겨졌으니 의사결정도 같다”입니다.

이번 발표의 실무적 결론은 RelationalAI가 Snowflake 안에서 데이터 에이전트의 계산 도구를 늘렸다는 것입니다. Rel App은 기업 의미 모델을 만들고, predictive reasoner는 예측값을 만들고, prescriptive reasoner는 제약조건 아래 추천 action을 계산합니다. Coding agent skills는 개발자가 쓰는 CoCo, Claude Code, Codex, Copilot 표면에서 그 모델을 확장하게 합니다. OSI는 기존 semantic model을 Snowflake로 옮기는 언어를 제공합니다. 각각은 유용하지만, production에서는 하나의 질문으로 합쳐집니다. 이 agent가 어떤 데이터와 규칙으로, 어떤 비용으로, 어떤 변경 이력을 남기며, 어떤 action을 추천했는가입니다.

RelationalAI Reasoner GA는 “Snowflake에 AI가 더 붙었다”보다 좁게 읽을 때 가치가 있습니다. LLM 답변이 기업 의사결정을 대신하지 못하는 이유는 모델 지식 부족만이 아닙니다. 결정에는 예측, 제약조건, semantic definition, 권한, 비용, 승인 절차가 들어갑니다. RelationalAI는 그 중 semantic model과 reasoner를 Snowflake-native 형태로 묶고, 코딩 에이전트가 이 모델을 다루는 표면까지 열고 있습니다. 다음 검증 지점은 발표문이 아니라 실제 프로젝트의 diff, benchmark, credit bill, audit log, domain expert sign-off입니다.