출처: Dev.to

Google Open Knowledge Format: 엔터프라이즈 에이전트가 지식 계층을 필요로 하는 이유 - 도구 그 이상

대부분의 기업 AI 대화는 여전히 잘못된 곳에서 시작됩니다.
모델을 먼저 생각합니다.

어떤 모델을 사용할 것인가? 어떤 프레임워크를 채택할 것인가? 어느 벤더가 가장 좋은 에이전트 플랫폼을 가지고 있는가? 다음으로 연결할 도구는 무엇인가?

이 질문들은 공정합니다. 하지만 실제 기업 아키텍처에서는 가장 어려운 질문이 아닙니다.
더 어려운 질문은 이것입니다:
우리의 AI 시스템이 실제로 비즈니스와 어떻게 이해하고 있는지?

그래서 Google Cloud의 Open Knowledge Format 관련 기사가 제 눈을 끌었습니다. 기사에서는 인간이 읽고 머신이 사용할 수 있도록 지식을 표현하는 간단하지만 중요한 아이디어를 다루고 있습니다. OKF에서는 내용은 마크다운, 컨텍스트는 구조화된 메타데이터로 구성됩니다.

처음에는 이것이 너무 단순해 보일 수 있습니다.
하지만 그 단순함이 핵심입니다.

기업은 지식이 사라지는 또 다른 장소가 필요하지 않습니다. 포털, 카탈로그, 위키, 대시보드, 폴더, 내부 도구 등이 이미 충분히 많이 있습니다.
필요한 것은 인간이와 AI 에이전트 모두에게 검토·버전 관리·거버넌스·검색·재사용이 가능한 방식으로 지식을 패키징할 수 있는 실용적인 방법입니다.

이 아이디어는 에이전트 AI에 매우 관련성이 있습니다.
대부분의 조직은 이미 AI 에이전트가 필요로 하는 지식을 보유하고 있습니다.

그 지식은 데이터베이스, 대시보드, 티켓, 아키텍처 노트, 런북, Confluence 페이지, 데이터 카탈로그, 코드 주석, 사고 보고서, 오래된 프로젝트 문서, 그리고 경험이 풍부한 직원들의 머리 속에서 존재합니다.

문제는 지식이 존재하지 않는다는 것이 아니라, 그것이 분산돼 있다는 것입니다.
일부는 오래되어 있고, 일부는 중복되며, 일부는 부서별(트라이벌)이고, 일부는 도구 안에 잠겨 있으며, 일부는 인간이 읽기 위해 쓰여 있지만 AI 시스템이 신뢰할 수 있게 구조화되지 않았습니다.

이 문제는 AI 어시스턴트에서 AI 에이전트로 전환할 때 심각해집니다.
어시스턴트는 유용한 답변을 줄 수 있습니다. 에이전트는 더 많은 일을 합니다. 계획하고, 도구를 선택하고, 시스템에 쿼리하고, 단계를 실행하고, 출력을 생성하며, 때때로 워크플로를 트리거합니다.

그 결과 잘못된 컨텍스트를 갖는 비용이 훨씬 더 큽니다.

데이터 에이전트는 SQL을 생성하는 방법을 알 수 있지만, 진실 출처가 되는 테이블을 알지는 못합니다.
재무 에이전트는 수익을 계산할 수 있지만, 비즈니스에서는 예약된 수익, 청구된 수익, 인식된 수익, 혹은 현금 수령 중 어떤 것을 의미하는지 알지는 못합니다.

지원 에이전트는 고객 사례를 요약할 수 있지만, 외부에 공유하기 전에 마스크링해야 할 고객 정보가 무엇인지 알지는 못합니다.

배송 에이전트는 프로젝트 상태를 검토할 수 있지만, 거버넌스 규칙, эскала션 경로, 출시 게이트, 의존성 위험을 이해하는지는 의문입니다.

클라우드 비용 에이전트는 절감 권장을 할 수 있지만, 프로덕션에Critical한 환경과 안전하게 종료할 수 있는 환경을 알지는 못합니다.

이 컨텍스트가 없으면 에이전트는 엔터프라이즈 준비가 되지 않으며, 빠르고 자신감 있으며 위험합니다.

에이전트 AI에서 흔히 하는 실수는 더 많은 도구 접근이 곧 더 좋은 능력을 의미한다고 가정하는 것입니다.
데이터베이스를 연결하면 alcance(접근 범위)는 넓어지지만 판단력은 그렇지 않습니다.

많은 도구를 가지고 있음에도 맥락이 약한 에이전트는 여전히 잘못된 출처를 선택하고, 잘못된 규칙을 적용하고, 잘못된 테이블에 쿼리하고, 잘못된 필드를 노출하거나, 잘못된 단계를 자동화할 수 있습니다.

그래서 저는 모든 심각한 엔터프라이즈 에이전트 AI 프레임워크는 세 개의 레이어가 필요하다고 믿습니다:

• 추론 계층
• 도구/액션 계층
• 거버넌스된 지식 계층

대부분의 팀은 앞 두 레이어에 대량으로 투자하고 있습니다. 모델, 오케스트레이션 프레임워크, 프롬프트, 도구, API, 에이전트 워크플로우를 테스트합니다. 그 작업은 필요합니다. 하지만 세 번째 레이어가 기업 차별화의 원천이 됩니다.

모델은 바꿀 수 있습니다. 도구는 통합될 수 있습니다.
하지만 조직의 내부 지식(정의, 운영 규칙, 비즈니스 로직, 예외 사항, 소유권, 아키텍처, 배운 교훈)은 고유합니다. 그것이 실제 자산입니다.

Open Knowledge Format 아이디어를 좋아하는 점은 문제를 복잡하게 만들지 않는다는 것입니다. 지식을 읽히고, 이동 가능하고, 구조화되며, 유지보수 가능한 것으로 취급합니다. 마크다운은 인간이 읽고 기여하기에 쉽습니다. 구조화된 메타데이터는 시스템과 에이전트가 지식을 분류하고, 검색하고, 사용하기에 더 쉬워집니다. 버전 관리는 리뷰와 감사를 가능하게 합니다.

이는 중요합니다. 전통 문서는 수동적입니다. 누군가가 쓰고, 누군가가 읽으며, 결국 오래되어 버립니다.
에이전트 AI는 액티브한 지식이 필요합니다. 지식은 런타임에 이용 가능해야 하며, 에이전트가 무엇을 해야 할지, 무엇을 피해야 할지, 믿을 만한 출처를 선택하고, 적용할 규칙을 정하고, 언제 업그레이드(확대)할지를 판단하도록 도와야 합니다.

데이터베이스 스키마는 테이블에 ‘segment’이라는 이름의 컬럼이 있다는 것을 말할 수 있습니다. 그것은 유용하지만 충분하지 않습니다.

에이전트도 알아야 합니다:

• segment이란 무엇인가?
• 정의는 누구에게?
• 어떤 값이 유효한가?
• 필드가 신뢰할 수 있는가?
• 보고에 사용할 수 있는가?
• 외부에 노출될 수 있는가?
• 레거시 예외가 존재하는가?
• 어떤 워크플로가 이를 사용할 수 있는가?

이것은 데이터 접근과 엔터프라이즈 인텔리전스 사이의 간극입니다.

우리의 에이전트 AI 프레임워크에서 OKF와 유사한 구조를 Enterprise Knowledge Layer로 취급하겠습니다. 이 레이어는 엔터프라이즈 시스템과 에이전트 실행 사이에 위치해야 합니다.

에이전트는 사용자 요청을 바로 도구 호출로 이동해서는 안 됩니다. 그곳에서 많은 실수가 발생합니다.
더 나은 흐름은:

• User request
  ↓
• Agent identifies intent and domain
  ↓
• Agent retrieves relevant knowledge
  ↓
• Agent checks source of truth, ownership, caveats, access rules, and usage guidance
  ↓
• Agent plans the action
  ↓
• Agent calls the right tool
  ↓
• Agent produces the answer or executes the workflow
  ↓
• Agent proposes a knowledge update if reusable learning is found

실행 품질이 달라집니다.

간단한 질문 예시: “고객 세그먼트별 수익을 보여 주세요.”

약한 에이전트는 revenue, customer, segment과 같은 이름의 테이블을 찾아 SQL을 생성합니다.
강력한 엔터프라이즈 에이전트는 먼저 지식 계층을 확인합니다:

• 어떤 수익 테이블이 승인된가?
• 어떤 수익 정의가 적용되는가?
• 신뢰할 수 있는 고객 세그먼트 필드는 무엇인가?
• 어떤 조인이 유효한가?
• 어떤 날짜 로직을 사용해야 하는가?
• 레거시 계좌에 대한 주의사항이 있는가?
• 사용자는 이 출력을 볼 수 있나요?

그 후에야 데이터베이스에 쿼리해야 합니다. 이는 자동화와 거버넌스된 인텔리전스의 차이입니다.

AWS SQL 환경(Amazon RDS, Aurora, Redshift)에서는 시작점은 메타데이터 추출입니다.
자동으로 다음과 같은 정보를 추출할 수 있습니다:

• 데이터베이스 이름
• 스키마 이름
• 테이블 이름
• 컬럼 이름
• 데이터 타입
• 주 키
• 외래 키
• 인덱스
• NULL 가능성
• 행 수
• 테이블 주석
• 컬럼 주석
• AWS 태그
• 최신도 지표
• 쿼리 사용 패턴

AWS Glue 크롤러와 Glue 데이터 카탈로그는 메타데이터를 발견하고 중앙 집중화하는 데 도움이 됩니다. information_schema와 같은 데이터베이스 네이티브 소스는 테이블 및 컬럼 수준 구조를 제공할 수 있습니다.

메타데이터는 지식 자체는 아닙니다. 파이프라인은 테이블에 revenue_Amount 컬럼이 있다는 것을 발견할 수 있지만, 이는 예약된 수익, 인식된 수익, 청구된 수익, 혹은 파이프라인 값 중 어떤 의미인지 자동으로 알 수 없습니다. 그 의미는 재무, 영업 운영, 데이터 소유자 또는 승인된 문서에서 나와야 합니다.

따라서 OKF 생성은 반자동화되어야 합니다. 기술 메타데이터는 자동으로 생성되고, 비즈니스 의미는 올바른 도메인 소유자가 검토하고 승인해야 합니다.

각 중요한 SQL 테이블에 대한 지식 파일은 다음과 같은 내용을 포함해야 합니다:

• 비즈니스 목적
• 원본 시스템
• 진실 출처 상태
• 데이터 소유자
• 데이터 스튜어드
• 갱신 주기
• 핵심 컬럼
• 승인된 조인
• 일반적인 사용 패턴
• 금지된 사용 사례
• 데이터 품질 규칙
• 민감도 분류
• 에이전트 사용 가이드
• 알려진 한계

테이블 수준 지식 파일은 단순히 테이블을 설명하는 것이 아니라, 에이전트가 안전하게 사용할 수 있도록 안내해야 합니다.

예시:

---

id: sales.crm.customer_account
kind: table
system: aurora-postgresql
cloud