AX의 다음 병목, 컨텍스트와 암묵지

AX 에이전트가 운영 단계에서 멈추는 이유를 컨텍스트 엔지니어링, 암묵지, 지식 그래프, 온톨로지 관점으로 해설하고 작은 업무 단위의 시작 기준을 정리합니다.

AI 전환, 즉 AX를 이야기할 때 우리는 자주 모델 성능부터 봅니다. 어떤 LLM을 쓸 것인가, 프롬프트를 어떻게 쓸 것인가, 에이전트를 몇 개 붙일 것인가가 먼저 논의됩니다. 그런데 현장에서 막히는 지점은 조금 다릅니다. 모델이 부족해서라기보다, 모델이 업무를 판단할 만한 맥락을 제때 받지 못해서 멈춥니다.

가상 예시. 한 제조 기업이 고객 클레임 자동 분류 에이전트를 도입했습니다. 모델 성능은 충분했고, 프롬프트도 잘 설계했습니다. 그런데 막상 운영에 올리니 에이전트가 멈춥니다. 이 클레임이 어느 제품 라인에 속하는지, 해당 고객 계약에 SLA 예외 조항이 있는지, 이전 동일 유형 클레임이 어떻게 처리됐는지, 승인 권한이 누구에게 있는지—이 정보가 여러 시스템에 흩어져 있어 에이전트가 판단을 못 합니다. 문제는 모델이 아니라 컨텍스트 공급 구조였습니다.

사람도 마찬가지입니다. “이 이슈 처리해줘”라는 말만 듣고 바로 의사결정할 수 있는 사람은 없습니다. 고객이 누구인지, 현재 계약 조건은 무엇인지, 예외 규정은 있는지, 어떤 시스템에 반영해야 하는지, 권한은 어디까지인지 알아야 합니다. 여기에 문서에는 없지만 숙련자가 알고 있는 판단 순서, 자주 발생하는 예외, 고객별 응대 감각 같은 암묵지도 작동합니다. AI 에이전트도 다르지 않습니다. AX의 다음 경쟁력은 더 긴 프롬프트가 아니라, 필요한 컨텍스트와 암묵지를 안정적으로 공급하는 구조에서 갈립니다.

프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

프롬프트 엔지니어링은 “어떻게 물을 것인가”의 문제입니다. 역할을 주고, 출력 형식을 정하고, 예시를 넣어 모델의 답변 스타일을 조정합니다. 단순 질의응답이나 정형화된 문서 작성에는 여전히 유효합니다.

하지만 업무 에이전트는 질문 하나에 답하는 수준을 넘어섭니다. 여러 시스템에서 데이터를 찾고, 중간 결과를 기억하고, 조건을 검증하고, 도구를 호출하고, 실행 결과를 다시 판단해야 합니다. 이때 필요한 것은 좋은 문장 하나가 아니라 컨텍스트의 설계입니다.

컨텍스트 엔지니어링은 AI가 현재 과제를 수행하는 데 필요한 지시, 사실, 규칙, 도구, 권한, 이전 상태를 언제 어떤 형태로 제공할지 설계하는 일입니다. 큰 컨텍스트 창에 모든 문서를 밀어 넣는 방식과는 다릅니다. 오히려 중요한 것은 “많이 넣는 것”이 아니라 “지금 필요한 것을 구조화해서 넣는 것”입니다.

참고: Neo4j는 컨텍스트 엔지니어링을 “적절한 시점에 적절한 지시·도구·증거를 제공하는 설계”로 정의하며, 프롬프트만으로는 ID, 필터, 이전 의사결정, 사실, 도구 사용 이력을 안정적으로 추적하기 어렵다고 설명합니다.

무엇이 달라지나: 한눈에 보는 차이

이 표가 말하는 핵심은 하나입니다. 프롬프트를 아무리 다듬어도, 에이전트가 판단에 필요한 사실과 규칙을 받지 못하면 업무는 멈춥니다.

지식 그래프는 컨텍스트의 지도다

기업 데이터는 보통 표, 문서, 로그, 메타데이터, 위키, 업무 시스템에 흩어져 있습니다. 벡터 검색만으로도 관련 문서를 찾을 수는 있지만, 업무 판단에는 관계가 필요합니다. 이 설비가 어느 라인에 속하는지, 이 고객이 어떤 계약과 연결되는지, 이 지표가 어떤 공정 조건의 영향을 받는지 같은 연결 정보가 있어야 합니다. 특히 “이 조건이면 먼저 이 담당자에게 확인한다”처럼 숙련자의 암묵지가 관계와 규칙으로 남지 않으면, 에이전트는 관련 문서를 찾아도 다음 행동을 정하기 어렵습니다.

여기서 지식 그래프가 중요해집니다. 지식 그래프는 엔터티와 관계를 노드와 엣지로 표현해, AI가 단순히 문서를 검색하는 것을 넘어 업무 세계의 연결 구조를 따라가게 합니다. 예를 들어 “최근 불량률 상승의 원인 후보를 찾아줘”라는 질문은 문서 몇 개를 찾는 문제가 아닙니다. 제품, 공정, 설비, 레시피, 작업 이력, 검사 결과, 변경점 사이의 관계를 좁혀 가는 문제입니다.

가상 예시. 위 제조 기업에서 “불량률 상승 원인 후보”를 묻는다고 생각해 봅시다. 벡터 검색이라면 “불량률”이라는 단어가 포함된 문서 5건을 반환합니다. 지식 그래프가 있으면 다릅니다. 해당 제품 → 사용된 레시피 버전 → 레시피 변경 시점 → 변경 전후 설비 파라미터 → 동일 설비에서 생산된 다른 제품 이력 → 검사 결과 추이. 이 연결을 따라가면 “3주 전 레시피 B 변경 이후 해당 설비에서만 불량률이 올랐다”는 원인 후보를 좁힐 수 있습니다. 문서 검색이 아니라 관계 추적입니다.

AWS가 2026년 6월 소개한 AWS Context도 이 흐름을 보여줍니다. AWS는 기존 데이터의 관계를 지식 그래프로 자동 매핑하고, 에이전트가 런타임에 관리되는 데이터 관계와 비즈니스 규칙, 도메인 지식을 사용할 수 있도록 하는 방향을 제시했습니다. 컨텍스트가 에이전트의 부가 기능이 아니라 엔터프라이즈 AI 인프라의 한 층으로 올라오고 있다는 신호입니다.

AWS Context는 해당 소개 글 기준으로 “Coming soon” 상태입니다. 실제 제공 상태와 지원 범위는 도입 또는 구매 판단 전에 최신 공식 문서로 확인해야 합니다.

그래서 무엇이 달라지나

지식 그래프가 있으면 에이전트의 질문 방식이 바뀝니다. “관련 문서를 찾아줘”에서 “이 엔터티와 연결된 저 엔터티를 조건에 맞게 좁혀줘”로 이동합니다. 이 차이는 에이전트가 “정보를 나열하는 시스템”에서 “관계를 따라 판단하는 시스템”으로 넘어가는 분기점입니다.

온톨로지는 업무 언어를 정하는 일이다

지식 그래프가 연결의 지도라면, 온톨로지는 그 지도를 읽는 언어입니다. 같은 “고객”, “장비”, “재고”, “리스크”라는 단어도 부서마다 뜻이 다를 수 있습니다. 온톨로지는 업무 객체, 속성, 관계, 제약, 가능한 행동을 정의해 사람과 AI가 같은 의미 체계 위에서 일하게 합니다. 이 과정은 베테랑의 암묵지를 모두 자동화한다는 뜻이 아닙니다. 반복적으로 확인되는 판단 기준과 예외 조건을 우선 명시지로 바꿔, 검토 가능하고 관리할 수 있는 규칙으로 만드는 일에 가깝습니다.

Palantir는 온톨로지를 데이터, 로직, 액션, 보안을 통합해 의사결정을 모델링하는 시스템으로 설명합니다. 이 설명은 특정 제품의 아키텍처 관점입니다. 다만 단순한 용어 사전이나 시맨틱 레이어를 넘어 실제 업무 행동과 권한까지 연결해야 AI가 “말만 하는 시스템”에서 “일을 수행하는 시스템”으로 넘어갈 수 있다는 시사점은 참고할 만합니다.

AX 관점에서 온톨로지는 특히 중요합니다. 많은 기업이 생성형 AI PoC에서는 빠르게 성과를 보지만, 운영 단계에서 확산이 느려집니다. 이유는 모델이 업무의 의미와 경계를 모른 채 문서 조각만 보고 답하기 때문입니다. 어떤 경우에 자동 실행할 수 있고, 어떤 경우에는 승인자를 거쳐야 하며, 어떤 데이터는 특정 권한에서만 볼 수 있는지 정의되어야 합니다.

그래서 무엇이 달라지나

온톨로지가 없으면 에이전트는 “답변은 하는데 실행은 못 하는” 상태에 머뭅니다. 온톨로지가 있으면 “이 객체에 대해 이 조건이 충족되면 이 행동을 실행하고, 이 권한 범위에서만 접근하라”는 규칙이 기계가 읽을 수 있는 형태로 존재합니다. PoC와 운영의 간극을 메우는 것이 바로 이 층입니다.

AX 아키텍처는 세 층으로 봐야 한다

앞으로의 AX 아키텍처는 크게 세 층으로 정리할 수 있습니다.

첫째, 모델과 에이전트 층입니다. LLM, 멀티에이전트, 도구 호출, 워크플로우 오케스트레이션이 여기에 해당합니다. 둘째, 컨텍스트 층입니다. RAG, 메모리, 메타데이터, 권한, 실행 로그, 평가 결과가 모델에 공급되는 방식입니다. 셋째, 지식·온톨로지 층입니다. 기업의 업무 객체와 관계, 규칙, 행동, 보안을 정의하는 기반입니다.

지금까지 많은 AX 논의가 첫 번째 층에 집중했다면, 앞으로는 두 번째와 세 번째 층이 더 중요해질 가능성이 큽니다. 모델은 빠르게 범용화되고, 프롬프트 기법은 쉽게 복제됩니다. 반면 기업 고유의 지식 그래프와 온톨로지는 내부 업무를 이해하고 운영에 연결하는 자산입니다.

운영 관점 체크리스트: 우리 조직은 어느 층에서 막히는가

아래 질문 중 3개 이상에 “아직”이라고 답한다면, 모델 교체가 아니라 컨텍스트·온톨로지 층을 점검할 시점입니다.

• 에이전트가 판단에 필요한 데이터를 “어디서 가져오는지” 명시되어 있는가?
• 같은 용어(고객, 장비, 리스크 등)가 부서 간 다른 의미로 쓰이고 있지는 않은가?
• 에이전트가 자동 실행할 수 있는 범위와 승인이 필요한 범위가 규칙으로 정의되어 있는가?
• 에이전트 실행 결과가 다시 지식 구조에 반영되는 피드백 루프가 있는가?
• 컨텍스트 공급 실패 시 에이전트가 “모르겠다”고 안전하게 멈추는 설계가 있는가?

무엇부터 시작해야 할까

처음부터 거대한 엔터프라이즈 온톨로지를 만들 필요는 없습니다. 오히려 작은 업무 단위에서 시작하는 편이 현실적입니다. 반복 문의가 많은 업무, 데이터 출처가 여러 개인 분석 업무, 승인·예외·권한 조건이 명확한 프로세스가 좋은 출발점입니다.

첫 단계는 용어를 맞추는 것입니다. 이 업무에서 중요한 객체는 무엇인지, 객체 사이의 관계는 무엇인지, 판단에 필요한 규칙은 무엇인지 적어야 합니다. 이때 현업 인터뷰를 통해 “문서에는 없지만 실제로는 이렇게 판단한다”는 암묵지를 수집하고, 자동화 가능한 규칙과 사람의 검토가 필요한 판단을 구분하는 것이 중요합니다. 다음은 컨텍스트 공급 방식을 정하는 것입니다. 어떤 정보는 항상 필요한지, 어떤 정보는 상황에 따라 검색해야 하는지, 어떤 도구 결과는 요약해서 넘겨야 하는지 구분해야 합니다. 마지막으로 에이전트가 한 일을 검증하고 다시 지식 구조에 반영하는 피드백 루프가 필요합니다.

시작 판단 프레임: 어디부터 손대야 하나

이 중 하나라도 “예”라면, 그 업무에서 용어 정의 → 관계 매핑 → 컨텍스트 공급 설계 순서로 시작할 수 있습니다.

글을 마치며: 다음 질문

AX는 AI를 도입하는 프로젝트가 아니라, 조직의 지식과 실행 방식을 AI가 읽고 사용할 수 있게 재구성하는 과정에 가깝습니다. 여기에는 데이터베이스와 문서뿐 아니라 사람에게 머물러 있는 암묵지를 발견하고, 필요한 부분을 검토 가능한 업무 규칙으로 옮기는 작업도 포함됩니다. 그래서 다음 질문은 “어떤 모델을 쓸까”에서 멈추면 안 됩니다. “우리 조직의 컨텍스트와 암묵지는 어디에 있고, 어떤 그래프로 연결되어 있으며, 어떤 온톨로지로 설명되는가”를 물어야 합니다.

그 답을 가진 조직일수록 AI 에이전트를 데모가 아니라 운영 체계 안으로 끌어들일 수 있습니다.

구체적으로, 다음 세 질문을 팀 안에서 던져 보길 권합니다.

1. 우리 에이전트가 멈추는 지점은 모델 성능인가, 컨텍스트 부재인가?
2. 우리 업무 객체와 관계는 누가, 어떤 형태로 관리하고 있는가?
3. 에이전트의 실행 결과가 다시 조직 지식으로 돌아가고 있는가?

확인한 출처 / 근거

• AWS, “Context intelligence for your data and AI agents at scale”, 2026-06-17 — AWS Context의 지식 그래프 자동 매핑, 런타임 데이터 관계·비즈니스 규칙·도메인 지식 활용 설명. 해당 글 기준 제공 상태는 “Coming soon”.
• Neo4j, “What is context engineering in AI agents? A practical guide”, 2025-12-19 — 컨텍스트 엔지니어링의 정의와 프롬프트만으로 ID·필터·이전 의사결정·도구 사용 이력을 추적하기 어렵다는 설명. 벤더 관점의 해설임.
• Palantir, “The Ontology system” — 데이터·로직·액션·보안을 통합해 의사결정을 모델링한다는 제품 아키텍처 설명.
• 참고: 모든 사례는 이해를 돕기 위한 가상 예시입니다. 지식 그래프·온톨로지의 도입 범위와 운영 방식은 조직의 데이터 품질, 업무 규칙, 권한 체계에 따라 달라집니다.