비즈니스 의미에 AI 에이전트 적용하기: 시맨틱 레이어, 온톨로지 및 MCP 도출 실습

AI 에이전트가 잘못 작동할 때, 문제는 보통 모델 자체가 아닙니다. 에이전트는 귀하의 용어가 무엇을 의미하는지 배운 적이 없었기 때문입니다. 시맨틱(Semantic) 모델과 **온톨로지(Ontologies)**가 이 문제를 해결하며, 여기 작은 실습 스케치를 소개합니다.

우리 모두 이런 경험을 해봤습니다. 누군가에게 과제를 맡겼는데, 돌아온 결과물이 우리가 상상했던 것과 다르죠. 그때 문득 '이 사람은 바보인가'라는 생각이 듭니다.

하지만 실제로 무슨 일이 일어났는지 생각해 보면, 그들은 지능이 부족한 것이 아니었습니다. 맥락(context)이 부족했을 뿐입니다. 어떤 보고서를 말하는지, 어떤 고객을 '활성(active)'으로 간주해야 하는지, 또는 팀에서 '긴급(urgent)'하다는 말이 이번 주가 아니라 오늘이라는 것을 알지 못했던 것입니다. 그들은 자신이 이해한 대로 정확히 행동했습니다. 문제는 공유된 의미에 있었습니다.

AI 에이전트도 똑같은 일이 발생합니다. 만약 에이전트를 디지털 직원으로 취급한다면, 신입 사원이 실패하는 것처럼 작동하며, 같은 해결책이 필요합니다: 방향 제시와 교육입니다.

'바보 에이전트' 문제

다음 과제를 생각해 보세요:

현재 **파운데이션 모델(foundation models)**은 **추론(reason)**하고, **작성(write)**하며, **계획(plan)**을 세우고, **도구 호출(call tools)**할 수 있습니다. 하지만 이 모델들에는 귀하의 세계가 담겨있지 않습니다. 즉, 귀하의 비즈니스 용어, 규칙, 개념 간의 관계, 그리고 무엇이 허용되는지에 대한 정보가 부족합니다.

사람은 이러한 지식을 몇 달간의 온보딩(onboarding), 대화, 실수, 멘토링을 통해 흡수합니다. 반면 에이전트는 프롬프트와 몇 개의 문서, 그리고 하나의 과제를 받으면 작동하고, 그러다 보니 우리가 오해받는 경우가 생겨 놀라곤 합니다.

따라서 유용한 질문은 "어떻게 하면 더 똑똑한 에이전트를 얻을 수 있을까?"가 아닙니다. 오히려 "이 에이전트에게 여기서 사물들이 무엇을 의미하는지 어떻게 가르칠 수 있을까?"입니다.

시맨틱 모델: 어휘력 (vocabulary)

시맨틱 모델(semantic model)은 귀하의 데이터와 용어가 비즈니스 언어에서 무엇을 의미하는지를 정의합니다. 에이전트가 단순히 cust_stat_cd = 3이라는 컬럼 이름을 보는 대신, 여기에 정의가 붙은 "활성 고객(Active Customer)"으로 인식하게 됩니다.

이는 좋은 관리자가 신입 사원에게 첫날에 건네주는 용어집과 같습니다.

매출액이란 예약금(bookings)이 아닌 인식된 매출액(recognized revenue)을 의미합니다.
활성 고객이란 지난 90일 이내에 무언가를 구매한 고객입니다.
지역은 배송 주소지가 아니라 영업 지역 지도(sales territory map)를 따릅니다.

이렇게 설정되면 에이전트는 답을 지어내는 대신, 용어가 무엇을 의미하는지 찾아보게 되며, 이는 잘 온보딩된 직원이 행동하는 방식과 같습니다.

온톨로지: 조각들이 연결되는 방식 (how the pieces connect)

**시맨틱 모델(semantic model)**은 여러분에게 단어들을 제공합니다. 반면 **온톨로지(ontology)**는 그 단어들 사이의 관계, 즉 도메인 내 개념들과 그 속성들, 그리고 이들이 어떻게 연결되는지를 제공합니다.

송장(invoice) 예시를 들어보겠습니다:

• 고객(Customer)은 하나 이상의 계정(Account)을 가집니다.
• 계정(Account)은 송장(Invoice)을 받습니다.
• 송장이 기한이 지난 경우(overdue)는 오늘 날짜가 만기일과 유예 기간(grace period)을 더한 날짜보다 늦을 때입니다.
• 담당자(Contact)는 고객(Customer)의 직원이며, 역할(role)이 재무(Finance)인 경우에만 결제 승인을 할 수 있습니다.

사람들은 이러한 관계를 천천히 파악하며 거의 기록으로 남기지 않습니다. 하지만 온톨로지는 이를 기계가 사용할 수 있는 형태로 문서화합니다.

한 가지 명확히 할 점은 온톨로지(ontology) 자체는 아무것도 강제하지 않는다는 것입니다. 그것은 도메인에 대한 설명일 뿐입니다. 지식 그래프 쿼리(knowledge graph query), 워크플로우의 검증 단계, 또는 에이전트가 호출하는 도구 등 무언가가 그것을 읽고 행동해야 합니다. 다음 섹션에서는 이것이 어떻게 보이는지 보여줍니다.

코드에서 어떻게 보이는가

이것은 프로덕션 디자인이 아니라 형태를 보여주기 위한 의도적으로 작은 스케치입니다. 두 가지 요소로 구성됩니다. 정의(definition)를 제공하는 도구와 에이전트가 행동하기 전에 호출하는 규칙 검사입니다.

먼저, MCP 도구로 노출되는 시맨틱 모델을 사용하여 에이전트가 추측하는 대신 용어를 조회하도록 합니다.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("business-glossary")
...

도출(Elicitation): 서버가 되물어보게 하기

폴백(fallback)에 주목하세요. 용어가 정의되지 않은 경우, 서버는 추측이나 단순 오류를 반환하지 않습니다. MCP 도출(elicitation)을 사용하여 일시 중지하고 클라이언트를 통해 질문을 던집니다. 이때 원하는 답변을 설명하는 작은 스키마가 함께 제공됩니다. 사용자는 수락하고 정의를 입력하거나, 거부하거나, 취소할 수 있으며, 도구가 각 경우를 처리합니다. 이 폴백이 가장 큰 행동 변화를 가져오는데, 의미의 격차(gap in meaning)가 아는 사람이 채우고 답변은 저장되어 다음 조회에 성공하게 하기 때문입니다.

알아두면 좋은 두 가지 세부 사항이 있습니다. **도출(Elicitation)**은 모델에게가 아니라 클라이언트를 통해 사용자에게 전달됩니다. 서버가 모델에게 무언가를 질문하도록 하려면, 그것은 **샘플링(sampling)**이라는 다른 MCP 기능입니다. 그리고 도출은 선택적인 클라이언트 기능이므로, 프로덕션 환경에서는 이를 지원하지 않는 클라이언트를 처리해야 합니다. 예를 들어, 대신

에이전트 워크플로우에서 이는 "이메일 초안 작성(draft the email)"과 "이메일 전송(send the email)." 사이에 위치하는 노드 역할을 합니다. 만약 validate_followup이 어떤 값을 반환하면, 에이전트는 수신자를 수정하거나 중단하고 질문합니다. 더 큰 시스템에서는 규칙들이 하드코딩된 함수 대신 그래프 스토어(graph store)나 규칙 엔진(rules engine)에 존재할 것입니다. 하지만 아이디어는 같습니다. 즉, 지식이 프롬프트 외부로 작성되고 무언가가 이를 확인하는 방식입니다.

행을 제거하면 사람과 에이전트 모두 어리석게 보이기 시작합니다. 모든 칸을 채우면, 평범한 작업자(사람 또는 디지털)도 믿음직스러워집니다.

에이전트가 실패했을 때 가장 먼저 살펴볼 것들

모델을 교체하기 전에 다음 사항들을 확인해 보세요:

• 작업이 의존하는 용어들을 정의했는가?
• 이러한 개념들이 어떻게 관련되는지 설명했는가?
• 규칙과 경계가 무언가가 확인할 수 있는 곳에 작성되어 있는가?
• 동일한 실수가 반복되지 않도록 평가(evals)와 같은 피드백 루프가 존재하는가?

대부분의 경우, 이 질문들 중 하나에 대한 답은 '아니요'입니다. 이는 모델의 결함이 아니라 우리 측의 설계상의 간극(design gap)입니다.

요약

누군가에게 방향을 제시한 적이 없는데도 그 사람을 어리석다고 부르는 것은 학습자보다 가르치는 쪽의 문제에 대해 더 많은 것을 말해줍니다. 에이전트도 예외는 아닙니다. 시맨틱 모델(Semantic models)과 온톨로지(ontologies)는 당신이 부족한 지식(tribal knowledge)을 공유된 지식(shared knowledge)으로 전환하는 방법이며, 이 공유된 지식이 어떤 작업자라도 당신이 의도한 방식으로 작업을 수행할 수 있게 만듭니다.

다음번에 에이전트가 무언가를 잘못했을 때, 그것이 무엇을 몰랐는지 물어보고 가르쳐주세요.

감사합니다
Sreeni Ramadorai