2026년 6월 17일, AWS는 🔗 AWS Glue Data Catalog Business Context and Semantic Search (Preview)를 공개했습니다.

AWS Glue Data Catalog는 S3 등에 저장된 데이터의 위치와 구조를 관리하는 Metadata Catalog입니다. Dataset의 Database, Table, Column, Location, Format을 등록해 “어떤 데이터가 어디에 있고 어떤 모양인가?”를 찾을 수 있게 합니다.

새 기능은 기존 기술 Metadata에 업무 의미를 더합니다. AWS는 이 Business Context를 Glossary Term, Custom Metadata Field, Skill Asset 세 가지로 나눕니다. Glossary Term에는 조직의 업무 용어와 정의를, Custom Metadata Field에는 정해진 Key-Value Template 값을 기록합니다. Skill Asset은 AI Agent가 참고할 외부 문서의 URI를 Catalog에 등록합니다. SearchAssets는 정확한 Keyword Matching뿐 아니라 Business Context를 바탕으로 의미가 유사한 Asset도 찾습니다.

이제 Glue Data Catalog는 “데이터가 어디에 있는가?”뿐 아니라 “이 데이터가 업무에서 무엇을 뜻하는가?”도 설명할 수 있습니다. 다만 용어의 뜻을 찾는 것과 그 뜻을 SQL로 일관되게 계산하는 것은 다른 문제입니다.

이번 글은 순매출(Net Revenue)이라는 작은 업무 용어에서 출발합니다. 같은 데이터도 계산 기준에 따라 결과가 달라지는 사례를 살펴보고, Glue Business Context가 용어의 뜻과 관련 데이터를 어떻게 연결하는지 확인합니다.

그렇다면 용어를 찾은 AI Agent가 그 정의를 매번 같은 방식으로 계산하게 하려면 무엇이 더 필요할까요? Business Context가 해결하는 범위와 남는 간극을 살펴본 뒤, 기계가 읽을 수 있는 의미 계약을 실행 과정에 연결해 보겠습니다.

🧮 같은 데이터에서 두 개의 매출이 나왔다

같은 순매출(Net Revenue)이라는 이름을 사용해도 계산 기준이 명시되지 않으면 누군가는 모든 주문 금액을 더하고, 누군가는 취소 주문을 제외합니다. SQL은 둘 다 실행되지만 결과는 달라집니다.

거래 내역을 담은 orders와 고객 기준 정보를 담은 customers를 따로 준비했습니다. 두 파일은 S3에 CSV로 저장하고 Glue Data Catalog에는 External Table로 등록했습니다.

orders(order_id string, customer_id string, order_date date, amount decimal(18,2), status string)에는 주문 다섯 건을 넣었습니다.

customers(customer_id string, customer_name string, region string)는 고객명과 공식 영업 지역을 관리하는 작은 Master Table입니다.

두 Table은 customer_id로 연결합니다. 주문 금액과 취소 여부는 orders에서 계산하고, 지역별 분석에는 주문에 임의로 적힌 주소가 아니라 customers.region을 사용합니다.

Athena에서 모든 주문 금액과 취소 주문을 제외한 금액을 함께 계산했습니다.

SELECT
  SUM(amount) AS all_order_amount,
  SUM(
    CASE WHEN status <> 'CANCELLED' THEN amount ELSE DECIMAL '0' END
  ) AS net_revenue
FROM heuristicwave_ossie_poc.orders;

실제 실행 결과입니다.

두 SQL 중 문법적으로 틀린 것은 없습니다. 문제는 조직에서 어떤 값을 순매출이라고 부르기로 했는가입니다. Dashboard, Notebook, Application, AI Agent가 이 정의를 따로 관리하면 같은 질문에 다른 숫자가 나옵니다.

📖 Glue Business Context로 뜻과 데이터를 연결하기

첫 단계는 조직이 순매출을 무엇으로 정의할지 합의하고, 그 정의가 어느 데이터에서 출발하는지 연결하는 것입니다. AWS 환경에서는 Glue Data Catalog가 S3 데이터의 위치와 Schema를 이미 관리하므로 Glossary Term을 Table·View Asset과 연결할 수 있습니다.

세 가지 Business Context는 역할이 서로 다릅니다.

Skill Asset은 S3 문서나 Git·Wiki 내용을 Glue에 복사하는 기능이 아닙니다. 외부 문서의 URI를 가진 Catalog Asset을 만든 다음 amazon::RelatedTo Form으로 Table·View 같은 Data Asset에 연결합니다. AWS 공식 문서의 흐름에서는 Agent가 Data Asset을 조회하면서 연결된 Skill ID를 찾습니다. 이어 URI의 문서를 Reasoning Context로 불러옵니다. 따라서 Agent에도 S3 GetObject처럼 원본 문서를 읽을 권한이 필요합니다. 🔗 AWS Glue Skill assets for AI agents

이번 PoC에서는 영문 Net Revenue와 한국어 순매출을 같은 Glossary에 만들고 둘 다 orders에 연결했습니다.

용어를 정의하고 Table에 연결하자 세 가지가 달라졌습니다.

1. 찾을 수 있습니다. 사용자가 물리 Table 이름을 몰라도 net revenue나 순매출이라는 업무 용어로 관련 데이터를 찾습니다.
2. 같은 뜻을 공유합니다. Finance, Sales, Data Team이 지표 설명을 한 곳에서 확인합니다.
3. 데이터의 근거를 연결합니다. 용어 설명이 문서에만 머무르지 않고 실제 orders Table과 연결됩니다.

실제로 Glue SearchAssets API로 Keyword 검색과 의미 검색을 각각 실행했습니다.

등록한 용어와 정확히 일치하는 net revenue뿐 아니라 이를 다르게 표현한 문장으로도 관련 Asset을 찾았습니다. 다만 customers가 함께 반환된 것은 이름과 설명의 의미적 연관성 때문이며, Glue에 등록하지 않은 Join 관계를 따라 탐색한 결과는 아닙니다.

같은 Glossary에 순매출 Term과 한국어 정의를 추가하고 orders에 연결한 뒤 한국어 검색도 확인했습니다. Table 이름과 Asset 설명은 영문 그대로 두었습니다.

한국어 Business Context를 추가하자 정확한 용어뿐 아니라 같은 뜻을 다르게 표현한 문장도 검색됐습니다. Asset의 기술 이름을 번역하지 않아도 한국어 Glossary Term과 설명을 등록하면 현업의 한국어 표현으로 관련 데이터를 찾을 수 있었습니다. 다만 AWS가 언어 간 자동 번역 검색을 보장하지는 않으므로, 실제로 사용하는 언어별 용어와 설명을 등록하는 편이 안전합니다.

AWS Glue Business Context와 Semantic Search는 현재 Preview이며 지원 Region과 접근 제어에 제약이 있습니다. 🔗 AWS Glue Semantic Search · AWS Glue Business Context 시작하기

하지만 용어집만으로는 계산을 고정할 수 없습니다.

용어집은 순매출의 뜻과 관련 데이터를 알려주지만, status <> 'CANCELLED'와 orders.customer_id = customers.customer_id를 실행하지는 않습니다.

Glue Business Context로 해결한 것은 ‘순매출이 무엇이며 어느 데이터와 관련 있는가’였습니다. 남은 질문은 ‘그 의미를 여러 분석 도구와 AI Agent에서도 같은 계산으로 재현할 수 있는가’입니다.

한 시스템만 사용한다면 View나 Skill 문서에 계산식을 작성할 수 있습니다. 그러나 같은 지표를 여러 제품과 Agent에서 쓰려면 계산식과 Dataset 관계를 각 형식에 맞춰 다시 정의해야 합니다. Amazon Quick, dbt, Looker, Snowflake가 모두 서로 다른 형식을 사용하기 때문입니다. 이제 문제는 용어집 하나의 기능을 넘어 합의된 의미를 여러 제품에 일관되게 전달할 공통 계약의 부재로 확장됩니다.

이 간극을 메우려면 제품 간 Semantic Model을 교환할 공통 형식이 필요합니다.

🧭 Ossie는 왜 나왔을까?

Semantic Layer가 확산되면서 각 제품은 업무 의미를 표현하는 고유한 방법을 만들었습니다. Snowflake는 Semantic View를, Google Cloud는 LookML을 사용합니다. dbt는 Semantic Layer, Amazon Quick은 Topic으로 Metric, Dimension, Relationship을 정의합니다.

문제는 같은 순매출을 정의하더라도 제품마다 모델 형식과 실행 방식이 다르다는 점입니다. 계산 기준 자체가 달라지는 Semantic Drift뿐 아니라, 이미 합의한 정의를 제품마다 다시 작성해야 하는 Semantic Model Fragmentation이 발생합니다.

Snowflake Semantic View ─┐
Google LookML ───────────┤
dbt Semantic Layer ──────┼─> 같은 Metric·Relationship을 제품별로 다시 작성
Amazon Quick Topic ──────┘

이 문제를 줄이기 위해 2025년 9월 Snowflake, Salesforce, dbt Labs 등을 포함한 업계 참여사들이 Open Semantic Interchange(OSI)를 공개했습니다. 목표는 새로운 Query Engine을 만드는 것이 아니었습니다. Dataset·Metric·Dimension·Relationship을 여러 분석·BI·AI 제품이 교환할 수 있는 제품 중립 규격으로 표현하는 것이었습니다. 🔗 Snowflake의 OSI 발표

2026년 1월에는 YAML 기반 첫 규격이 공개됐고, 같은 해 Apache Incubator에 합류하면서 프로젝트 이름이 Apache Ossie로 바뀌었습니다. 이름과 거버넌스는 달라졌지만, 서로 다른 제품 사이에서 Semantic Metadata를 교환한다는 목적은 그대로 유지됩니다. 🔗 Apache Ossie · Apache Incubator Proposal

Ossie는 새로운 Query Engine이 아니라, 제품마다 달랐던 의미 모델을 교환하기 위한 공통 계약입니다.

이 계약을 AWS Glue로 찾은 Data Asset에 연결하고, Agent의 실행 과정에서 활용할 수 있는지 확인해 보겠습니다.

🧩 가설: Skill에서 Ossie 계약을 발견하게 한다

용어집 다음에는 사람이 읽는 설명을 넘어, 프로그램이 Dataset, Metric, Relationship을 각각 식별하고 검증할 수 있는 계약이 필요합니다. Glue Skill Asset은 실행 파일이 아니라 계약의 위치와 사용법을 알려주는 연결점으로 사용할 수 있습니다.

AWS 공식 문서에서 Skill Asset은 조직 Context와 Metric 정의, 데이터 사용 제약, 일반적인 Query Pattern, SQL 예제가 담긴 외부 문서의 URI를 가리킵니다. Agent는 Data Asset에 연결된 Skill을 찾고 URI의 내용을 Reasoning Context로 불러옵니다. 이번 PoC에서는 이 구조를 활용했습니다. Skill 문서는 버전 관리된 Apache Ossie YAML을 가리키고 Agent에게 전용 Tool의 사용법을 안내합니다.

역할은 다음처럼 나뉩니다.

전체 계약을 Skill Markdown에 복사할 수도 있지만 같은 정의를 두 군데에서 관리하면 서로 달라질 수 있습니다. Ossie YAML은 Git이나 버전 관리된 S3 Object를 원본으로 둡니다. Skill 문서에는 그 위치와 실행 규칙만 기록하는 편이 낫습니다.

AWS 공식 문서에서 Glue Skill Asset에 직접 등록하는 값은 Markdown의 내부 형식이 아니라 문서를 가리키는 URI입니다. 다음처럼 amazon::Skill Form의 uri에 S3 Markdown 위치를 등록합니다. 🔗 AWS Glue Skill assets for AI agents

aws glue put-asset \
  --asset-type-id "amazon::Skill" \
  --identifier "sales-semantic-skill-ossie-poc" \
  --name "sales-semantic-skill-ossie-poc" \
  --forms '{"amazon::Skill":{"FormTypeId":"amazon::Skill","Content":"{\"uri\":\"s3://<bucket>/semantic-skill-ossie-poc/sales-semantic-skill.md\"}"}}'

AWS가 Skill Markdown용 YAML Front Matter Schema를 정의하거나 해석하는 것은 아닙니다. 문서에는 조직 Context, Metric 정의, 사용 제약, Query Pattern과 SQL 예제 등을 일반 Markdown으로 작성할 수 있습니다. 이번 PoC에서는 Semantic contract와 Approved tools 섹션을 자체 규약으로 두고 Runner가 해당 항목을 읽도록 구현했습니다.

Skill이 가리키는 Ossie 계약에는 이번 질의에 필요한 의미만 간단히 정의했습니다.

Metric은 여러 데이터 행을 집계해 업무 성과를 나타내는 정량 지표입니다. Dimension은 Metric을 지역·고객·날짜처럼 분류하고 필터링하는 기준이며, Relationship은 Metric과 Dimension이 서로 다른 Dataset에 있을 때 두 Dataset을 연결하는 규칙입니다. 이번 PoC에서는 ‘취소되지 않은 주문 금액의 합계’를 net_revenue Metric으로 정의했습니다.

🔗 Snowflake Semantic Views의 Metric·Dimension·Relationship · Looker의 Dimension·Measure 개념

version: 0.2.0.dev0
semantic_model:
  - name: sales_analytics
    description: Sales and customer analytics for the Glue Skill PoC
    ai_context:
      instructions: Use net_revenue for sales excluding cancelled orders.
    datasets:
      - name: orders
        source: heuristicwave_ossie_poc.orders
        primary_key: [order_id]
        fields:
          - name: order_id
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: order_id
            datatype: String
          - name: customer_id
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: customer_id
            datatype: String
          - name: amount
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: amount
            datatype: Decimal
          - name: status
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: status
            datatype: String
      - name: customers
        source: heuristicwave_ossie_poc.customers
        primary_key: [customer_id]
        fields:
          - name: customer_id
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: customer_id
            datatype: String
          - name: region
            expression:
              dialects:
                - dialect: ANSI_SQL
                  expression: region
            datatype: String
            dimension:
              is_time: false
    relationships:
      - name: orders_to_customers
        from: orders
        to: customers
        from_columns: [customer_id]
        to_columns: [customer_id]
        ai_context:
          instructions: Use customers.region as the official sales region.
    metrics:
      - name: net_revenue
        expression:
          dialects:
            - dialect: ANSI_SQL
              expression: >-
                SUM(CASE WHEN orders.status <> 'CANCELLED'
                THEN orders.amount ELSE DECIMAL '0' END)
        description: Revenue excluding cancelled orders
        datatype: Decimal
        ai_context:
          synonyms: [net sales, 순매출]
          examples: [Show net revenue by customer region]

Apache Ossie는 현재 Incubating 단계이고 Core Specification도 발전 중입니다. 실제 구현에서는 사용할 Spec Version을 고정하고, 해당 Version의 Schema로 계약을 먼저 검증해야 합니다.

이 구성만으로 가능한 것은 계약을 찾고 읽는 것까지입니다. 실제로 질의를 실행하려면 compile_ossie_metric 같은 Agent Tool이 Ossie Schema를 검증하고, 요청한 Metric과 Dimension에 필요한 Dataset·Join·Expression을 골라 Athena SQL을 만들어야 합니다.

사용자: 지역별 순매출을 보여줘
  → Glue SearchAssets로 관련 orders Asset 검색
  → amazon::RelatedTo에서 Sales Semantic Skill 발견
  → Skill URI에서 sales.ossie.yaml 위치와 실행 규칙 확인
  → compile_ossie_metric(metric="net_revenue", dimension="customers.region")
  → 생성 SQL의 Table·Column·권한·비용 한도 검증
  → execute_athena_query(sql)
  → Agent가 결과와 사용한 Metric 정의를 함께 설명

이 가설은 두 가지 수준으로 구현할 수 있습니다.

1. Agent가 계약을 읽고 SQL을 작성하는 PoC: 구현은 빠르지만 같은 질문에서 항상 같은 SQL이 만들어진다고 보장하기 어렵습니다.
2. Compiler Tool이 SQL을 결정적으로 생성하는 방식: Agent는 Metric, Dimension, Filter만 전달하고 Tool이 SQL을 만듭니다. Contract Validation, 허용된 Dialect, Join 경로, SQL Injection 방지, Query Cost 제한도 Tool에서 통제할 수 있습니다.

Apache Ossie Repository에는 Schema Validation과 다른 Semantic Format을 위한 Reference Converter가 있지만, 범용 Athena Query Compiler가 완성품으로 제공되는 것은 아닙니다. 여기서 사용한 compile_ossie_metric은 이 가설을 구현하기 위해 별도로 만들어야 할 Custom Tool 이름입니다.

따라서 “Ossie를 Skill에 적으면 Glue가 실행한다”는 표현은 정확하지 않습니다. 정확한 역할은 Skill이 Ossie 계약의 위치를 알려주고, Agent Tool이 계약을 SQL로 변환하며, Athena가 실행하는 것입니다.

물론 Metric 몇 개를 AWS 안에서만 사용할 때는 Athena View에 계산식을 고정하고 Skill에 사용법을 적는 편이 더 단순합니다. 반면 같은 Metric·Relationship을 Amazon Quick, Snowflake, Looker, dbt Semantic Layer나 여러 Agent에 전달하려면 SQL View보다 Ossie 같은 제품 중립 계약의 가치가 커집니다.

AWS에는 서비스별로 자연어 분석을 지원하는 경로가 있습니다. 🔗 SageMaker Unified Studio Data Agent는 연결된 데이터와 Catalog 정보를 참고해 SQL을 생성합니다. Amazon Quick은 Dataset과 Topic에 정의한 Metric·관계·지침을 자체 분석 환경에서 사용합니다.

이번 PoC는 이러한 기능을 대체하려는 것이 아닙니다. Glue에서 발견한 업무 의미를 제품 중립적인 Ossie 계약과 연결하고, Custom Tool이 그 계약을 실행에 사용하는 별도의 경로를 검증했습니다. 먼저 LLM 없이 Custom Compiler가 동일한 계약과 입력에서 같은 SQL을 생성하는지 확인했습니다. 이어 Compiler와 Athena Executor를 Strands Tool로 등록해 Bedrock 모델이 두 Tool을 실제로 호출하는 과정까지 확인했습니다.

🧪 이번 PoC에서 실제로 확인한 범위

이번 PoC에서는 S3, Glue Data Catalog, Glue Glossary, Glue Skill Asset, Athena WorkGroup을 구성했습니다. Skill 문서와 Ossie 계약은 S3에 저장하고 orders Table과 Skill을 연결했습니다. 이후 Bedrock 모델을 사용하는 Strands Agent를 실행해 Tool 호출 과정을 확인했습니다. 예제 데이터는 모두 가상입니다.

사용자 요청: "지역별 순매출"
  ↓ Bedrock toolUse
Strands Agent
  ↓
Glue SearchAssets ──> orders
  ↓ amazon::RelatedTo
Glue Skill Asset: sales-semantic-skill-ossie-poc
  ↓ Skill URI
S3 Skill Markdown
  ↓ semantic_contract_uri
S3 sales.ossie.yaml
  ↓ Ossie Schema Validation
Custom Compiler: net_revenue + customers.region
  ↓ generated SQL
Amazon Athena ──> BUSAN 110,000 / SEOUL 320,000

예제 Schema가 바뀌지 않도록 Crawler 대신 두 Table의 Column과 S3 위치를 직접 등록했습니다. Athena에서 DDL(CREATE EXTERNAL TABLE)을 실행해도 같은 Table 정보가 Glue Data Catalog에 등록됩니다.

먼저 Net Revenue와 순매출을 Glossary Term으로 만들고 orders Table과 연결했습니다.

import boto3

glue = boto3.client("glue")

glossary = glue.create_glossary(
    Name="HeuristicWave Sales Glossary",
    Description="Business terms for the net revenue learning PoC",
)

en_term = glue.create_glossary_term(
    GlossaryIdentifier=glossary["Id"],
    Name="Net Revenue",
    ShortDescription="Revenue excluding cancelled orders",
    LongDescription=(
        "Sum of order amount where status is not CANCELLED. "
        "Customer region comes from the customers master table."
    ),
)

ko_term = glue.create_glossary_term(
    GlossaryIdentifier=glossary["Id"],
    Name="순매출",
    ShortDescription="취소 주문을 제외한 매출",
    LongDescription=(
        "주문 상태가 CANCELLED가 아닌 주문 금액의 합계입니다. "
        "지역별 분석에서는 customers 고객 마스터의 region을 사용합니다."
    ),
)

glue.associate_glossary_terms(
    AssetIdentifier="<orders-asset-id>",
    GlossaryTermIdentifiers=[en_term["Id"], ko_term["Id"]],
)

용어를 연결한 뒤에는 Table 이름이 아닌 업무 표현으로 관련 데이터를 검색했습니다.

for query in ["net revenue", "순매출", "취소된 주문을 빼고 계산한 실제 매출"]:
    result = glue.search_assets(SearchText=query, MaxResults=10)
    print(query, [item["AssetName"] for item in result["Items"]])

실제 결과입니다.

net revenue ['orders']
순매출 ['orders']
취소된 주문을 빼고 계산한 실제 매출 ['orders']

여기까지 확인한 것은 업무 용어로 관련 데이터를 찾는 과정입니다. 계산식과 Join을 적용해 SQL을 만드는 작업은 다음 단계에서 다룹니다.

Skill이 가리키는 Ossie 계약으로 Athena 실행하기

사용자 요청은 지역별 순매출로 정했습니다. 결정적 PoC Runner는 SearchAssets("net revenue")로 orders를 찾고, GetAsset으로 연결된 sales-semantic-skill-ossie-poc Skill을 발견했습니다. Skill Markdown의 Semantic contract와 Approved tools 섹션에서는 Ossie 계약 URI와 compile_ossie_metric, execute_athena_query라는 선언을 읽었습니다. 이 섹션명과 항목 구조는 AWS 표준이 아니라 이번 PoC에서 정한 Parser Contract입니다.

Compiler는 계약의 net_revenue Metric과 customers.region Dimension을 선택했습니다. Metric의 취소 주문 제외 조건과 orders.customer_id → customers.customer_id Relationship을 결합해 다음 Athena SQL을 결정적으로 생성했습니다.

SELECT
  customers.region,
  SUM(
    CASE
      WHEN orders.status <> 'CANCELLED' THEN orders.amount
      ELSE DECIMAL '0'
    END
  ) AS net_revenue
FROM heuristicwave_ossie_poc.orders AS orders
LEFT JOIN heuristicwave_ossie_poc.customers AS customers
  ON orders.customer_id = customers.customer_id
GROUP BY customers.region
ORDER BY customers.region;

이 SQL을 Athena에서 실행하자 계약에 정의한 계산식과 관계에 따라 BUSAN 110,000, SEOUL 320,000이 반환됐습니다. 결과값이 의도대로 나온 것을 확인했으니, 이제 실행 과정을 한 단계 더 자세히 살펴보겠습니다.

Bedrock 모델이 실제 Tool을 선택했는지 확인하기

다음 실행에서는 같은 기능을 세 개의 Strands @tool로 등록했습니다.

discover_semantic_contract
  → compile_ossie_metric
  → execute_athena_query

Strands Agent에는 Amazon Bedrock의 global.anthropic.claude-sonnet-4-6을 사용했습니다. 시스템 지침에는 세 Tool의 실행 순서를 명시했습니다. 따라서 이 실험은 자유로운 계획 능력을 평가하는 것이 아니라, 모델이 실제 toolUse를 생성하고 Strands가 선택된 Tool을 실행했는지를 검증하는 데 목적이 있습니다.

실제 Agent Message History에서 추출한 결과입니다.

{
  "model_id": "global.anthropic.claude-sonnet-4-6",
  "trace_id": "0x9887f16d1b4fc8af278ba57955af1741",
  "actual_tool_sequence": [
    "discover_semantic_contract",
    "compile_ossie_metric",
    "execute_athena_query"
  ],
  "athena_state": "SUCCEEDED"
}

각 호출에는 Bedrock이 생성한 고유한 toolUseId가 있었고, Strands OpenTelemetry Trace에도 다음 세 Span이 남았습니다.

execute_tool discover_semantic_contract  status=success
execute_tool compile_ossie_metric        status=success
execute_tool execute_athena_query        status=success

Trace의 gen_ai.tool.name과 Message History의 toolUse.name이 모두 같은 순서를 가리켰습니다. 마지막 Athena 결과도 BUSAN 110,000, SEOUL 320,000으로 결정적 Runner와 일치했습니다. 따라서 이번에는 “Skill 문서에서 Tool 이름을 읽었다”를 넘어 Bedrock 모델이 등록된 Tool을 실제로 호출했다고 말할 수 있습니다.

실제 Tool 호출 순서와 Athena 실행 결과는 아래 Audit에서 확인할 수 있습니다.

{
  "model_id": "global.anthropic.claude-sonnet-4-6",
  "trace_id": "0x9887f16d1b4fc8af278ba57955af1741",
  "actual_tool_sequence": [
    "discover_semantic_contract",
    "compile_ossie_metric",
    "execute_athena_query"
  ],
  "tool_uses": [
    {
      "name": "discover_semantic_contract",
      "input": {
        "search_text": "net revenue"
      }
    },
    {
      "name": "compile_ossie_metric",
      "input": {
        "contract_name": "sales.ossie.yaml",
        "metric_name": "net_revenue",
        "dimension_name": "customers.region"
      }
    },
    {
      "name": "execute_athena_query",
      "input": {
        "sql_sha256": "be89a3fb07fffa8b3e0b6dede0adaf5f88d7ac193ae97ebe88a5666a87415412"
      }
    }
  ],
  "contract_name": "sales.ossie.yaml",
  "contract_sha256": "35896d619dadb9c9248e46b5de678b8cfc0ad964fb439c1a19087ebad24d40c3",
  "athena_state": "SUCCEEDED",
  "query_execution_id_suffix": "f123f819",
  "rows": [
    {
      "region": "BUSAN",
      "net_revenue": "110000.00"
    },
    {
      "region": "SEOUL",
      "net_revenue": "320000.00"
    }
  ]
}

여전히 Ossie나 Glue가 SQL을 자동 생성한 것은 아닙니다. compile_ossie_metric은 이번 가설을 위해 작성한 제한형 Custom Tool이고, execute_athena_query가 Athena API를 호출했습니다.

# Sales Semantic Skill

## Purpose

Use this skill when a user asks for net revenue or regional sales analysis.

## Related data

- `heuristicwave_ossie_poc.orders`: order amount and cancellation status
- `heuristicwave_ossie_poc.customers`: official customer sales region

## Business context

- Use the `net_revenue` Metric for sales excluding cancelled orders.
- Use the `orders_to_customers` Relationship for regional analysis.
- Use `customers.region` as the official sales region.

## Semantic contract

- URI: `s3://<bucket>/semantic-skill-ossie-poc/sales.ossie.yaml`
- Format: `apache-ossie`
- Target engine: `athena`

## Approved tools

- Compiler: `compile_ossie_metric`
- Executor: `execute_athena_query`

## Execution instructions

- Load and validate the referenced Apache Ossie contract.
- Resolve Metric expressions and Dataset relationships from the contract.
- Compile only approved Dataset, Metric and Dimension identifiers.
- Execute the generated SQL with Amazon Athena.
- Return the Metric name and applied Relationship with the result.

## Query pattern

- User request: `Show net revenue by customer region.`
- Metric: `net_revenue`
- Dimension: `customers.region`

마무리

이번 실습에서 Glue Business Context는 업무 용어를 Data Asset과 연결하고, 같은 뜻의 다른 표현으로도 관련 데이터를 찾게 했습니다. 한국어 Business Context를 등록한 뒤에는 한국어 문장형 질의도 동작했습니다. 다만 용어의 발견과 설명은 계산 결과까지 보장하지 않습니다.

그래서 Skill Asset이 Agent를 Ossie 계약으로 안내하고, Custom Compiler가 계약을 검증해 Athena SQL로 바꾸는 실행 경로를 구성했습니다. 이번 실험에서는 지역별 순매출을 대상으로 한 개 Metric과 한 개 Dimension 경로를 확인했습니다.

AWS 환경 안에서 지표를 정의하고 활용한다면 Athena View, Amazon Quick Topic, Glue Skill Asset 같은 AWS Native 기능을 조합하는 편이 더 단순할 수 있습니다. 같은 정의를 Snowflake Semantic View, LookML, dbt Semantic Layer와 여러 AI Agent에서도 재사용하려면 제품별 중복을 줄이는 의미 계약이 필요해집니다. Open Semantic Interchange와 Apache Ossie는 이 문제를 풀기 위한 시도이며, Glue Business Context와 함께 아직 Preview·Incubating 단계라는 점도 고려해야 합니다. 🔗 Apache Ossie Proposal · Apache Ossie

요즘 Agent에게 데이터의 위치를 찾는 것뿐 아니라 업무 의미를 이해하고 같은 기준으로 실행하기를 기대하다 보니, AWS와 오픈소스 진영에서도 다양한 해법이 나오는 것 같습니다. 이번에는 Glue Business Context와 Ossie를 직접 연결하면서 문서만 읽을 때는 보이지 않던 경계를 확인할 수 있었습니다. 새로운 기능을 직접 써보고 예상과 다른 지점을 하나씩 알아가는 과정도 꽤 즐거웠습니다. 앞으로도 업데이트되는 기능을 직접 경험하고, 그 과정에서 배운 내용을 이 블로그에 꾸준히 소개하겠다는 다짐을 해보며 글을 마치도록 하겠습니다.

References

• AWS What’s New — AWS Glue Data Catalog Business Context and Semantic Search (Preview)
• AWS Glue — Getting started with business context
• AWS Glue — Semantic search
• AWS Glue — Skill assets for AI agents
• Amazon SageMaker Unified Studio — Generate SQL with the Data Agent
• Snowflake — Open Semantic Interchange
• Apache Ossie
• Apache Incubator — Ossie Proposal