AI Agent 시대, 기업은 무엇을 소유해야 하는가

인터페이스가 바뀌면 통제권의 위치도 바뀐다

기존 업무 환경에서 사용자는 직접 시스템을 선택했습니다. ERP에 접속하고, CRM을 열고, 사내 문서를 검색한 뒤 필요한 데이터를 분석했습니다. 흐름의 중심에는 애플리케이션을 선택하는 사람이 있었습니다.

사용자 → 애플리케이션 → 데이터

Agent가 업무의 중심 인터페이스가 되면 이 구조가 달라집니다. 사용자는 시스템을 하나씩 선택하는 대신 원하는 결과를 말합니다.

지난 분기 영업 실적을 분석해서 실적이 떨어진 고객사를 찾고, 담당자가 후속 조치해야 할 항목을 정리해줘.

Agent는 어떤 데이터를 찾고, 어떤 문서를 참고하고, 어떤 시스템을 호출할지 판단해야 합니다. 분석 방법뿐 아니라 어디까지 실행할 수 있는지도 알아야 합니다.

업무 맥락 이해 → 의도 파악 → 계획 → 도구 선택 → 실행 제안

과거에는 사용자가 애플리케이션을 선택했다면, 앞으로는 Agent가 그 선택의 상당 부분을 맡게 됩니다. 정보에 접근하고 행동을 결정하는 새로운 통제 지점, 즉 Control Point가 생기는 것입니다.

기업 데이터보다 중요한 것은 Enterprise Context다

기업에는 이미 많은 데이터가 있습니다. 문서, 데이터베이스, ERP, CRM, 메일, 메신저, 회의록에 업무 정보가 쌓여 있습니다. 하지만 데이터가 존재한다는 사실만으로 AI가 조직을 이해하는 것은 아닙니다.

한 고객사의 신규 사업 제안을 예로 들어보겠습니다.

• A사에 신규 사업을 제안하고 있습니다.
• 영업팀 B가 해당 프로젝트를 담당합니다.
• 지난 회의에서 가격 정책을 수정하기로 했습니다.
• 특정 계약 조건에는 법무팀 검토가 필요합니다.
• 최신 제안서는 Google Drive에 있습니다.
• 고객의 최근 요청은 이메일에 남아 있습니다.

이 정보들은 서로 다른 시스템에 흩어져 있어도 하나의 업무를 설명합니다. 사람은 고객, 담당자, 결정사항과 후속 작업을 연결해 이해합니다. AI에게는 연결되지 않은 데이터 조각으로 남을 수 있습니다.

실제 업무에는 누가, 무엇을, 왜 하고 있는지, 정보 사이에 어떤 관계가 있는지, 현재 상태는 무엇인지, 어떤 규칙과 권한이 적용되는지가 필요합니다.

이 글에서 말하는 Enterprise Context는 바로 이런 기업의 업무 맥락입니다. 데이터를 많이 모으는 것을 넘어, 그 데이터가 조직 안에서 갖는 의미와 관계를 이해할 수 있게 만드는 것입니다.

검색을 잘하는 AI와 일을 이해하는 AI는 다르다

기업용 생성형 AI의 많은 초기 도입은 RAG에서 출발했습니다. 문서를 검색 가능한 형태로 만들고 질문과 관련된 내용을 찾아 모델에 전달하는 방식입니다. 이는 기업 지식에 접근하는 데 유용합니다.

그러나 Agent가 업무를 수행하려면 검색 결과만으로 부족한 경우가 있습니다.

이 계약 건, 지금 어떻게 되고 있어?

이 질문에는 계약서를 찾는 것 이상의 이해가 필요합니다. 계약 상대, 협상 단계, 최근 회의의 결정, 관련 이메일, 담당자, 적용되는 내부 규정을 함께 봐야 할 수 있습니다.

같은 계약서라도 협상 중인지, 법무 검토 중인지, 최종 승인을 받았는지에 따라 다음 행동은 달라집니다.

따라서 필요한 것은 문서 검색을 대체하는 또 하나의 검색 기능이 아닙니다. 검색을 포함하되 업무 객체와 관계, 현재 상태를 연결하는 Context Layer입니다. 검색이 필요한 근거를 찾는 일이라면, 업무 이해는 그 근거가 지금 어떤 의미를 갖는지 판단할 수 있게 하는 일입니다.

기업이 통제해야 할 세 가지 계층

LLM은 추론과 생성에 중요한 역할을 합니다. 하지만 기업용 Agent 전체와 같은 의미는 아닙니다. 모델의 성능과 비용, 업무별 적합성은 달라질 수 있습니다. 기업의 업무 구조까지 그 변화에 종속될 필요는 없습니다.

우리는 기업이 최소한 다음 세 영역을 통제할 수 있어야 한다고 생각합니다.

1. Enterprise Context

데이터와 업무 관계, 조직 구조, 프로젝트 상태, 의사결정의 맥락을 담는 계층입니다. 모델을 바꾸더라도 기업의 지식과 업무 연결 관계를 유지할 수 있어야 합니다.

2. Execution Control

Agent가 사용할 수 있는 도구와 API, 접근 가능한 데이터, 수행 가능한 행동의 범위를 결정합니다. 어떤 사용자에게 어떤 실행 권한이 있는지 기업이 정할 수 있어야 합니다.

3. Verification

실행 제안이 권한, 정책, 보안 및 업무 규칙을 충족하는지 확인합니다. 필요한 승인을 거쳤는지 실행 전에 검증하고, 실행 후에는 결과가 의도와 조건을 충족했는지 확인합니다.

이 세 계층을 독립적으로 관리하면 특정 모델에 대한 의존을 줄일 수 있습니다. 다만 모델 교체에는 품질 평가와 도구 연동 검증이 필요합니다. 독립적인 구조는 교체 가능성을 높이는 기반이지, 모든 모델이 수정 없이 호환된다는 뜻은 아닙니다.

모델은 빌릴 수 있지만, 맥락의 통제권은 남겨야 한다

특정 LLM에 종속되는 위험은 모델 사용 자체보다 더 넓은 곳에서 생길 수 있습니다. 조직 구조와 프로젝트 정보가 특정 플랫폼 안에만 축적되고, 업무 이력이 그 플랫폼의 메모리가 되며, SaaS와 API의 선택까지 외부 플랫폼에 맡기는 경우입니다.

ERP, CRM, 그룹웨어와 사내 시스템이 Agent가 호출하는 실행 수단이 될 때, 중요한 질문은 누가 어떤 API를 어떤 순서로 호출하도록 결정하느냐입니다. 그 결정 기준을 기업이 확인하거나 변경하기 어렵다면 중요한 통제 지점을 잃을 수 있습니다.

필요한 전략은 외부 AI를 차단하는 것이 아닙니다. 좋은 모델은 적극적으로 활용하되, 업무 맥락과 실행 정책을 기업이 관리할 수 있게 하는 것입니다.

여기서 소유란 모든 시스템을 직접 개발하거나 모든 데이터를 물리적으로 내부에 보관해야 한다는 뜻이 아닙니다. 맥락을 내보내고 이전할 수 있는지, 접근 범위를 정할 수 있는지, 공급자를 바꿔도 업무 관계와 정책을 유지할 수 있는지가 핵심입니다.

BeSir가 바라보는 Enterprise AI

BeSir가 풀고자 하는 문제는 AI가 기업의 업무 세계를 이해할 수 있도록 만드는 것입니다. 기업에는 수많은 데이터와 문서가 있지만, 실제 업무는 그 사이의 관계 속에서 이루어집니다.

고객과 프로젝트가 연결되고, 프로젝트와 담당자가 연결됩니다. 회의의 결정사항은 문서와 후속 업무로 이어집니다. AI가 실제 업무에 참여하려면 이런 연결과 맥락을 이해할 수 있어야 합니다.

BeSir는 기업의 데이터와 업무를 연결하는 Enterprise Context Layer를 기반으로, Agent가 필요한 정보를 탐색하고 도구를 활용할 수 있는 구조를 지향합니다.

여기에는 하나의 원칙이 있습니다. LLM이 Enterprise Context의 주인이 되어서는 안 됩니다. 모델은 맥락을 활용해 추론하는 엔진이 될 수 있지만, 기업의 업무 구조와 지식, 권한과 실행 정책은 기업이 통제하는 계층으로 존재해야 합니다.

그래야 모델과 AI 공급자를 바꾸거나 새로운 Agent를 추가할 때도 기업이 쌓아온 업무 자산을 유지할 수 있습니다. 이는 특정 구현 방법을 설명하는 것이 아니라, BeSir가 기업용 AI를 설계할 때 지향하는 방향입니다.

AI가 할 수 있다는 것과 해도 된다는 것은 다르다

Agent가 다음과 같이 판단했다고 가정해보겠습니다.

이 고객에게 가격 조건을 변경한 계약서를 보내는 것이 가장 적절합니다.

그 판단이 가능하다는 이유만으로 계약서를 수정하고 고객에게 보내서는 안 됩니다. 사용자의 권한, 결재 절차, 법무 검토 여부, 고객 정보 접근 범위와 업무 정책을 확인해야 합니다.

따라서 실행 전에는 다음 경계가 필요합니다.

AI Proposal → Verification → Execution

AI는 행동을 제안하고, 기업이 정한 규칙과 필요한 승인에 따라 제안을 검증한 뒤 실행합니다. 실행이 끝나면 결과가 의도한 내용과 일치하는지도 확인해야 합니다.

모든 작업에 사람의 승인이 필요하다는 뜻은 아닙니다. 기업은 작업의 위험과 영향에 따라 자동 실행 범위와 승인 조건을 정할 수 있습니다. 중요한 것은 그 기준을 모델이 임의로 바꾸지 못하도록 하는 것입니다.

AI의 수행 능력이 커질수록, 허용된 행동을 구분하는 검증 계층의 역할도 커집니다.

앞으로의 경쟁은 통제 지점에서도 일어난다

AI 산업의 경쟁은 모델 성능을 중심으로 주목받아 왔습니다. Agent가 업무에 깊이 들어갈수록, 누가 맥락을 보유하고 의도 해석과 실행을 통제하는지도 경쟁의 중요한 축이 될 수 있습니다.

기업은 “어떤 모델을 쓰는가”와 함께 다음 질문을 설계해야 합니다.

• 우리 업무 맥락은 어디에 존재하며 다른 환경으로 옮길 수 있는가?
• Agent는 어떤 정보와 최신 상태를 근거로 판단하는가?
• 도구를 선택하는 기준과 데이터 접근 범위는 누가 정하는가?
• 어떤 행동에 승인이 필요하며 누가 승인하는가?
• 실행 결과와 판단 근거를 어떻게 확인할 수 있는가?

이는 모델 선택보다 덜 화려해 보일 수 있습니다. 하지만 기업의 AI 활용이 늘어날수록 장기적인 운영 능력과 공급자 선택권에 직접 연결되는 질문입니다.

Enterprise AI를 구성하는 역할들

기업용 Agent의 구조를 역할 중심으로 보면 다음과 같이 정리할 수 있습니다. 아래는 개념적인 구분이며 특정 제품의 내부 구현을 의미하지 않습니다.

이를 업무 흐름으로 읽으면 맥락과 의도 이해 → 계획과 실행 제안 → 검증·승인 → 도구를 통한 실행 → 결과 확인입니다. Foundation Model은 이 과정에서 추론에 활용되는 엔진입니다.

BeSir가 집중하는 영역은 기업의 맥락을 이해하고 Agent와 실제 기업 시스템을 연결하는 계층입니다. 기업이 그 연결의 기준과 실행 범위를 통제할 수 있어야 한다고 생각합니다.

결국 기업이 소유해야 할 것은 AI의 업무 세계다

앞으로도 더 좋은 모델, 더 저렴한 모델, 특정 업무에 적합한 모델이 등장할 것입니다. 특정 모델을 사용한다는 사실만으로 지속적인 경쟁력을 만들기는 어려울 수 있습니다.

기업의 업무 맥락은 다릅니다. 조직이 어떻게 움직이는지, 고객과 프로젝트가 어떻게 연결되는지, 어떤 의사결정이 있었는지, 어떤 정책과 권한 아래 업무가 수행되는지는 그 기업이 축적한 자산입니다.

Agent 시대에 기업이 소유해야 할 것은 AI가 이해하고 행동해야 하는 기업의 업무 세계입니다. 그리고 그 세계를 다양한 모델에서 활용할 수 있는 독립적인 Context Layer로 만드는 일입니다.

우리는 이것이 Enterprise AI Architecture의 중요한 과제라고 생각합니다.

모델은 빌릴 수 있습니다. 하지만 기업의 Context와 실행 통제권까지 넘겨줄 필요는 없습니다.