예상 읽기 시간: 약 11분. 사전 경험 필요 없음.

어색한 왕복 과정

처음으로 데이터 웨어하우스 (Data Warehouse)에 AI를 결합했을 때, 화이트보드에 그린 계획은 합리적으로 보였습니다. 데이터를 웨어하우스에서 '밖으로' 꺼내어, 다른 곳에 있는 AI 서비스로 보내고, 답변을 받아 다시 '가져오는' 방식이었죠. 하지만 실제로 해보니 매우 서툴렀습니다. 데이터는 보안이 유지되는 집을 떠나 네트워크를 가로질러 이동하고, 다른 곳에서 처리된 후 다시 돌아와야 했습니다. 속도는 더 느려졌고 비용은 더 많이 들었으며, 이제는 신경 써야 할 두 번째 장소에 민감한 데이터가 복사되어 있는 상황이 되었습니다.

당연한 질문이 생깁니다: 왜 굳이 데이터를 AI로 옮겨야 할까요? 왜 AI를 데이터로 가져오지 않을까요? 이것이 바로 Snowflake Cortex의 핵심 아이디어입니다. AI 기능이 Snowflake 웨어하우스 내에 직접 구축되어 있어, 모델이 멀리 떨어진 곳이 아닌 데이터 '옆에서' 실행됩니다.

이 포스트를 다 읽을 때쯤이면 Cortex가 무엇인지, 주요 기능은 무엇인지, 어떻게 사용하는지, 주의해야 할 함정은 무엇인지, 그리고 현대적 데이터 스택 (Modern Data Stack)에서 어떻게 자리 잡고 있는지 이해하게 될 것입니다.

참고: Snowflake와 Cortex는 오픈 소스가 아닌 상용 제품입니다.

또는 라이브러리 _내부_에서 근무하는 **사내 전문가 (in-house expert)**를 고용할 수도 있습니다. 문서는 건물 밖을 절대 떠나지 않습니다. 당신은 그저 다가가서 질문하기만 하면 됩니다. 더 빠르고, 더 안전하며, 더 간단합니다.

Cortex는 바로 그 사내 전문가입니다. AI가 데이터가 있는 곳에 거주하므로, 당신은 이미 사용 중인 SQL을 통해 모든 것이 이미 존재하는 바로 그 자리에서 질문을 던질 수 있습니다.

핵심 기능 (The core capabilities)

Cortex는 여러 AI 능력을 하나로 묶어 제공합니다. 다음은 실제로 사용하게 될 기능들입니다.

1. LLM 함수 (단일 SQL 호출로 실행하는 AI)

가장 단순하면서도 놀라운 기능입니다. 일반적인 SQL 함수처럼 AI 모델을 호출합니다. 고객 리뷰 컬럼을 요약하고 싶으신가요? 행(row) 전체에 적용되는 단 한 번의 함수 호출이면 충분합니다. 감성 분석 (Sentiment), 번역 (Translation), 요약 (Summarization) 모두 데이터 웨어하우스에서 바로 실행하는 SQL로 처리됩니다.

-- 쿼리 내부에서 각 리뷰를 요약 (개념적 예시)
SELECT
    review_id,
...

데이터 내보내기(export)도, 별도의 서비스도 필요 없습니다. AI는 데이터 행이 이미 존재하는 곳에서 실행됩니다.

2. Cortex Analyst: 영어로 데이터에 질문하기

이것은 "데이터와 대화하는" 기능입니다. 비즈니스 사용자가 "지난 분기 매출 기준 상위 5개 제품은 무엇이었나요?"와 같이 평이한 영어로 질문을 입력하면, Cortex가 이를 SQL로 변환하여 실행하고 답변을 반환합니다. 이는 데이터 웨어하우스를 SQL을 모르는 사용자도 직접 질의할 수 있는 환경으로 바꿔줍니다.

이 기능을 신뢰할 수 있게 만드는 핵심은 **시맨틱 모델 (semantic model)**입니다. 이는 테이블과 컬럼이 비즈니스 용어로 무엇을 _의미하는지_에 대한 설명으로, 이를 통해 AI가 추측하는 대신 "매출 (revenue)"을 올바른 컬럼에 매핑할 수 있게 합니다.

3. Cortex Search: 관련 텍스트를 빠르게 찾기

문서에 대한 질의응답을 위해, Cortex Search는 텍스트 데이터에서 가장 관련성 높은 구절을 찾아냅니다 (LangChain 포스트에서 다룬 RAG 패턴의 검색(retrieval) 부분). 이 기능이 내장되어 있으므로 별도의 검색 시스템을 구축할 필요가 없습니다.

4. Cortex Agents: 다단계 추론 (multi-step reasoning)

가장 최신 레이어는 위 기능들을 결합하고, 관련 데이터를 검색하며, SQL을 생성하고, LLM 함수를 호출하여 플랫폼의 보안 경계 내에서 더 복잡한 다단계 추론 (multi-step reasoning) 질문에 답할 수 있는 에이전트 (agents)입니다.

flowchart LR
    U[User asks in English] --> A[Cortex Analyst / Agent]
    A --> SEM[Semantic model:<br/>what columns mean]
...

왜 "데이터 옆의 AI"가 중요한가

번거로운 왕복 과정(round trip)과 비교했을 때 세 가지 실질적인 장점이 있습니다.

• 보안 및 거버넌스 (Security & governance): 데이터가 Snowflake를 절대 떠나지 않으므로, 동일한 액세스 제어 및 감사 추적 (audit trail) 내에 머뭅니다 (Unity Catalog 포스트의 주제를 기억하세요, 거버넌스는 중요합니다). 민감한 복사본이 여기저기 흩어질 일이 없습니다.
• 단순성 (Simplicity): SQL입니다. 기존의 분석가들은 새로운 스택을 배우거나 모델 서빙 (model-serving) 인프라를 구축할 필요 없이 AI를 사용할 수 있습니다.
• 속도 및 비용 (Speed & cost): 대규모 데이터셋을 네트워크를 통해 외부 서비스로 보냈다가 다시 가져오는 과정이 필요 없습니다.

작은 엔드 투 엔드 (end-to-end) 맛보기

이 모든 매력은 사용자가 해야 할 일이 매우 적다는 점에 있습니다.

-- 1. 클래식 AI-as-SQL: 하나의 쿼리로 번역 및 요약
SELECT
    ticket_id,
...

AI가 데이터로 찾아왔습니다. 데이터는 집에 머물렀습니다.

흔한 실수와 주의사항 (gotchas)

1. 시맨틱 모델 (semantic model) 건너뛰기

Cortex Analyst의 성능은 제공된 비즈니스 정의의 수준에 달려 있습니다. 시맨틱 모델이 없다면, 어떤 컬럼이 "매출 (revenue)"을 의미하는지 추측하게 되며, 잘못 추측할 수도 있습니다. 명확한 시맨틱 정의에 투자하는 것이 "인상적인 데모"를 "신뢰할 수 있는 답변"으로 바꾸는 핵심입니다.

2. AI가 생성한 SQL을 맹목적으로 신뢰하기

모든 Text-to-SQL과 마찬가지로, Cortex도 겉보기에는 맞지만 중복 계산을 하거나 필터를 누락하는 쿼리를 생성할 수 있습니다. 특히 의사결정을 이끄는 데이터라면, 생성된 숫자를 신뢰하기 전에 이미 알고 있는 총계와 비교하여 무결성 검사 (sanity-check)를 수행하십시오.

3. 여전히 비용이 발생한다는 점을 잊는 것

수백만 개의 행에 걸쳐 AI 함수를 실행하는 것은 컴퓨팅 자원 (compute)을 소비하며 (Snowflake는 이 컴퓨팅 자원에 대해 비용을 청구합니다). 단순히 "확인해 보기 위해" 전체 이력에 SUMMARIZE를 적용하는 것은 빠르게 비용이 비싸질 수 있습니다. 작은 데이터 조각(slice)에서 먼저 테스트한 다음, 의도에 따라 규모를 확장하십시오.

4. 일반적인 챗봇(chatbot)으로 취급하는 것

Cortex는 데이터에 근거한(grounded) 질문에서 빛을 발합니다. 이는 자유롭게 돌아다니는 일반적인 어시스턴트를 위해 만들어진 것이 아닙니다. 잘 모델링된 데이터와 명확한 질문을 제시하십시오. 데이터에 포함되지 않은 내용에 대해 답변하기를 기대하지 마십시오.

5. AI 출력물에 대한 거버넌스(governance)를 무시하는 것

AI가 생성한 요약이나 답변은 민감한 세부 정보를 드러낼 수 있습니다. 테이블을 보호하는 것과 동일한 액세스 제어(access controls)가 이러한 함수를 실행하고 그 결과를 볼 수 있는 사람에게도 적용되어야 합니다. 편의성이 조용히 접근 권한을 확대하도록 방치하지 마십시오.

Cortex와 함께 AI 및 에이전트(agents) 사용하기

Cortex _자체_가 AI이기 때문에, 여기서의 "AI 관점"은 이를 잘 구축하고 개선하는 것에 관한 것입니다:

• "이 테이블들을 위한 시맨틱 모델(semantic model) 초안을 작성해 줘": 어시스턴트가 컬럼에 대한 비즈니스 정의를 제안하며, 이는 Cortex Analyst를 신뢰할 수 있게 만드는 데 엄청난 도움을 줍니다.
• "Cortex가 왜 이 SQL을 생성했는지, 그리고 이것이 맞는지 확인해 줘": 답변을 신뢰하기 전에 어시스턴트가 사용자의 의도와 생성된 쿼리를 대조하여 검토하도록 하십시오.
• "내장된 Cortex 함수를 사용해야 할까, 아니면 외부 모델을 사용해야 할까?": AI는 귀하의 특정 사례에 따른 트레이드오프(trade-offs)를 추론하는 데 도움을 줄 수 있습니다.

주의 사항: 일상적인 영어로 데이터 웨어하우스(warehouse)를 쿼리할 수 있는 AI는 강력하지만 남용하기 쉽습니다. 모호한 질문은 확신에 찬 틀린 숫자를 반환할 수 있습니다. 의사 결정에는 반드시 사람을 개입시키고(human in the loop), 시맨틱 모델을 검증하며, 일반적인 분석가에게 적용하는 것과 동일한 데이터 액세스 규칙을 준수하십시오.

마무리

Snowflake Cortex는 데이터를 AI로 보내는 대신, 데이터 옆에 AI를 가져다 놓습니다. 데이터가 안전한 보금자리를 떠나지 않고도, 일반 SQL을 통해 웨어하우스 내부에서 모델을 실행합니다. 여러분은 다음을 배웠습니다:

• 정의 (What it is): SQL을 통해 사용할 수 있도록 Snowflake에 내장된 AI 기능 (AI capabilities).
• 기능 (The capabilities): LLM 함수 (AI-as-SQL), Cortex Analyst (영어 질문), Cortex Search (텍스트 검색), 그리고 Cortex Agents (다단계 작업).
• 중요성 (Why it matters): 데이터를 원래 위치에 유지함으로써 얻는 거버넌스 (governance), 단순성, 그리고 속도.
• 주의사항 (The traps): 시맨틱 모델 (semantic model) 생략, 생성된 SQL을 맹목적으로 신뢰, 통제되지 않는 비용, 일반적인 챗봇(chatbot) 기대, 그리고 거버넌스 소홀.
• AI 관점 (The AI angle): 시맨틱 모델 초안 작성 및 생성된 SQL 검토, 그리고 인간이 결정을 검증하는 방식.

다음 단계 (Where to go next)

• Snowflake를 사용 중이라면, 작은 텍스트 컬럼에 하나의 LLM 함수 (예: SENTIMENT)를 적용해 보세요. AI가 SQL로서 (as SQL) 실행되는 것을 보는 순간, 이 개념이 명확히 이해될 것입니다.
• 자연어 질의 (natural-language querying)를 본격적으로 사용하기 전에, 몇 개의 핵심 테이블을 위한 작은 시맨틱 모델 (semantic model)을 작성하세요. 신뢰성은 바로 그곳에 존재합니다.
• Snowflake를 넘어선 더 큰 패턴을 기억하세요: "데이터로 AI를 가져오는 것 (bring the AI to the data)"은 모든 주요 플랫폼에서 나타나고 있으며, 여기서 얻은 아이디어는 다른 곳에도 적용될 수 있습니다.

사내 전문가를 채용하십시오. 그러면 어색한 데이터 왕복 과정은 영원히 사라질 것입니다.