ThinkingAI를 찾아주시는 많은 분들이 여쭤보시는 말이 있습니다.
"저희는 이미 Claude Code를 쓰고 있는데요. 굳이 AI Agent 플랫폼으로 바꿔야 할 이유가 있나요?"
이 말을 들었을때 저희가 항상 하는 말이 있습니다 바로 "저희는 LLM 모델을 대체하지 않습니다"라는 답입니다.
ThinkingAI 고객사가 이미 익숙해진 LLM 모델을 그대로 두고, 그 모델이 기업의 비즈니스 데이터 위에서 정확하게 일하게 만드는 쪽을 택했습니다.
범용 AI Agent가 왜 엔터프라이즈 환경에서 단독으로 부족한지, 그리고 LLM 모델을 변경하지 않고도 엔터프라이즈 수준의 AI 활용을 역량을 붙이는 구조가 어떻게 작동하는지에 대한 이야기입니다.
1. 범용 AI Agent는 왜 엔터프라이즈 환경에서 단독으로 부족한가
Code, Codex, Gemini와 같은 범용 AI 모델들은 특정 기업이나 산업에 종속되지 않은 추론·코딩·분석 능력을 갖춘 AI Agent의 기능을 구현할 수 있습니다. 상기한 LLM들은 매일마다 괄목할만한 발전을 보여주며 2026년 현재는 공개된 지식 기반 위에서 글을 쓰고, 코드를 짜고, 데이터를 분석하는 작업에서 높은 수준에 가치를 보여줍니다.
그렇다면 다시 한 번 질문으로 돌아가 보겠습니다. 훌륭한 모델이 있음에도 엔터프라이즈 AI Agent 플랫폼을 왜 써야할까요?
문제는 모델의 성능이 아니라, 그 모델이 담긴 그릇입니다. 모든 기업에는 공개적인 학습 데이터로 채울 수 없는 고유의 맥락이 있고, 범용 에이전트에는 그 맥락이 들어갈 자리가 처음부터 없습니다.
지표 정의(metric definition)가 첫 번째 빈칸입니다. '리텐션'이 D1인지 D7인지, '결제 컨버전'의 분모가 세션인지 유저인지를 에이전트는 알 방법이 없습니다. 하지만 LLM 모델은 지표 정의가 틀렸다는 말을 하지 않기에 (할루시네이션) 더욱 위험합니다. 숫자가 틀렸다면 검증에서 걸리겠지만, 다른 정의로 계산된 숫자는 그럴듯해서 그대로 의사결정에 사용되어 치명적인 나비효과를 야기할 수 있습니다.
시맨틱 레이어(Semantic Layer)가 두 번째입니다. 시맨틱 레이어는 데이터와 비즈니스 언어 사이를 잇는 일종의 번역 계층입니다. 시맨틱 레이어가 없이 나온 분석 결과는 데이터 팀이 다시 검증해야 하고, 검증에 드는 시간이 분석에 아낀 시간을 잡아먹는 역효과를 불러옵니다.
거버넌스 맥락이 마지막 빈칸입니다. 별도의 정책 설정 없이 범용 에이전트를 사내 데이터베이스에 연결하면, 어떤 직원이 어느 데이터까지 볼 수 있는지, 분석 결과를 어디까지 공유해도 되는지를 에이전트가 회사만의 보안 기준으로 판단하고 집행하기 어렵습니다. 기업용 Claude, OpenAI, Gemini 제품이 워크스페이스 권한, 관리자 정책, 감사 로그, 데이터 보존 기능을 제공하긴 합니다. 그러나 데이터 택소노미, 지표 정의, 세밀한 접근제어, 승인 절차는 그 위에 별도로 구성해서 연동해야 합니다.
이건 LLM이 잘못 된 것이 아닌, 설계 범위의 차이입니다. 범용 에이전트는 모든 사용자를 위해 설계됐고, 기업 데이터 환경은 범용 에이전트가 커버하기에는 너무 뾰족한 부분입니다.
2. "교체"이 아닌 "결합"이어야 하는 이유
범용 Agent가 엔터프라이즈 환경에서 한계를 드러낼 때, 많은 팀들이 첫 번째로 떠올리는 해결책은 "성능이 좋아진 새로운 모델로의 교체"입니다. 이것은 틀린 해답입니다.
| ❌ 잘못된 해답 | 지금 쓰는 Claude Code나 Codex를 버리고 무엇으로 갈아타야 하는가 |
|---|---|
| ✅ 맞는 질문 | 지금 쓰는 에이전트가 우리 데이터와 지식에 연결되려면 어떤 구조가 필요한가 |
모델을 교체하면 학습 비용과 매몰 비용이 발생하고, 이미 전사적으로 구축해놓은 워크플로우가 끊어집니다. Claude Code에 적응한 개발자, Codex로 분석을 돌리는 데이터 분석가, 사내에서 직접 만든 에이전트 프레임워크가 있다면 모델 교체는 그저 '새로운 AX를 시도했다는 뿌듯함' 말고 기업에게 줄 수 있는게 없습니다.
기술 표준도 같은 쪽을 가리킵니다. Anthropic의 공식 Claude Code 문서는 MCP(Model Context Protocol, 에이전트가 외부 시스템·데이터 소스와 상호작용하는 표준 인터페이스)를 표준으로 정의하고 있습니다. MCP는 에이전트들이 바깥 세상에서 소통할 수 있는 공통 언어입니다. 이 표준이 자리 잡았다는 건, 기존 에이전트를 그대로 두고 엔터프라이즈 데이터 레이러를 붙이는 경로가 이미 활짝 열려 있다는 뜻입니다.
한 가지 더 짚을 게 있습니다. 범용 에이전트가 AI 기능을 "장착"한 서비스를 하나씩 흡수하는 흐름에서, 살아남고 있는 서비스들의 공통점이 있습니다. "사용자가 LLM 모델 대신 우리의 툴을 써야한다"는 전제를 내려놓고, 범용 에이전트 뒤에서 실제 일을 처리하는 자리를 택했습니다. ThinkingAI의 선택도 같습니다.
교체는 모든 것을 바꾸는 일이고, 통합은 그대로 둔 채 AI 역량을 넓히는 일입니다.
3. 엔터프라이즈 AI 인프라의 통합 아키텍쳐
엔터프라이즈 AI 인프라(Enterprise AI Infrastructure)는 범용 Agent가 기업 고유의 데이터·지식·거버넌스 위에서 정확하고 안전하게 작동하도록 연결하는 인프라 레이어 전체를 의미합니다.
범용 Agent와 엔터프라이즈 데이터 환경을 연결하는 구조는 5개의 계층으로 구성됩니다. ThinkingAI에서 정의한 Agentic Engine과 범용 에이전트 통합 역량 아키텍처는 다음과 같이 작동합니다.
| 계층 | 역할 | 예시 |
|---|---|---|
| ① 고객 진입점 | 사용자가 실제로 작업하는 진입점. 복수의 Agent가 공존 | Claude Code, Codex, 자체 구축 Agent |
| ② 통합 접근 계층 | Agent와 엔터프라이즈 데이터·시스템을 연결하는 공통 언어 (MCP 기반) | MCP 서버, API 연결 |
| ③ AgentOS 제어 | 권한 관리, 거버넌스, 평가, 관찰 가능성(observability)을 담당 | 접근 권한 정책, 감사 로그, Agent 행동 모니터링 |
| ④ AI/데이터 파운데이션 | 시맨틱 레이어, 지표 정의, 실시간·오프라인 데이터 연결 | 비즈니스 지표 정의, 산업 특화 지식베이스 |
| ⑤ 차별화 성장 루프 | 비즈니스 노하우 & 성공 사례 이식, FDE 구축, AI 고도화 및 기술 재확장 | Agentic Engine 특화 Skills, 전담 FDE 팀 |
이 구조에서 핵심은 ①번 계층이 고정되지 않는다는 점입니다. Claude Code를 쓰는 팀, Codex를 쓰는 팀, 자체 Agent를 구축한 팀 모두 아래 레이어와 연결됩니다. 진입점은 그대로 두고, 그 아래에서 작동하는 엔터프라이즈 역량을 연결하는 구조입니다.
③번 AgentOS 제어 계층은 거버넌스 문제를 다룹니다. 어떤 사용자가 어떤 데이터에 접근할 수 있는지, Agent의 행동이 어떻게 기록되고 감사되는지를 이 계층에서 관리합니다. 범용 Agent 단독으로는 이 계층이 없습니다.
④번의 AI/데이터 기반에서의 시맨틱 레이어와 지표 정의도 중요합니다. Agent가 로우 데이터를 기본적인 지식 내에서 해석하는 대신, 비즈니스 맥락을 기반으로 정확한 분석 결과를 돌려줍니다. '리텐션 D7'이 무엇인지, '유효 결제 전환율'의 정의가 무엇인지를 Agent가 아는 상태에서 작동하는 것과 모르는 상태에서 작동하는 것은 결과의 신뢰도에서 차이가 납니다.
4. 게임·핀테크 기업에서 실제로 작동한 통합 방식
이 엔터프라이즈 AI 아키텍처는 실제 기업 현장에서 어떤 형태로 나타날까요? ThinkingAI의 대표적인 고객층인 게임사와 핀테크 기업들은 AI 도입 시 각각 다른 방식으로 같은 구조적 요구가 확인되었습니다.
| 기업 | 쓰고 있던 진입점 | 연결 방식 | 요구한 것 |
|---|---|---|---|
| 자체 AI 프레임워크를 구축한 게임사 | 사내 개발 프레임워크 | MCP + 프리셋 Skill | "ThinkingAI의 AI 역량을 우리 프레임워크에 붙이고 싶다" — Skill 축적과 지식베이스를 도입 근거로 평가 |
| 외부 에이전트 플랫폼을 도입한 게임사 | 외부 에이전트 플랫폼 | MCP 외부 연동 | 데이터 역량을 외부 플랫폼에 연결해 데이터 기반 워크플로우를 돌리는 구조 |
| Claude Code를 표준 도구로 쓰는 게임사 | Claude Code | 지식베이스 연동 (논의 진행 중) | "이 지식베이스를 Claude Code 같은 다른 시스템에서도 조회할 수 있나요?"라고 먼저 문의 |
| 협업툴과 Claude Code를 병행하는 게임사 | Feishu(협업 플랫폼) / Claude Code | 개방형 MCP 생태계 | 외부 MCP로 시스템 간 데이터를 합치는 방식이 기존 사내 툴 환경과 맞는다고 판단 |
한 게임사의 사례는 범용 Agent와 엔터프라이즈 지식베이스의 연결 필요성을 직접적으로 보여줍니다. Claude Code를 전사적으로 활용하고 있었고, 그 상태에서 엔터프라이즈 지식베이스를 Claude Code가 직접 조회할 수 있는지를 확인하고자 했습니다. Claude Code를 교체하려 한 것이 아니라, Claude Code가 기업 지식에 접근할 수 있는 연결 구조를 원했습니다. 게임사가 보유한 리텐션 진단, 결제 퍼널, RFM 세그먼트 같은 산업 특화 분석 노하우를 Agent가 활용할 수 있게 만드는 것이 목표였습니다.
다른 사례는 사용하고 있던 협업툴과 Claude Code를 병행하는 복합 환경에서 발생했습니다. 이 기업은 두 진입점 사이에서 데이터가 분절되는 문제를 경험하고 있었고, MCP를 통한 크로스 시스템 데이터 융합이 가능한지를 검토했습니다. 새로운 Agent를 추가하는 것이 아니라, 기존에 활용하는 생태계 위에 데이터 역량을 연결하는 방식을 선택했습니다. 오픈 MCP 생태계 지원이 기존 내부 툴 환경과 맞닿는다는 점을 엔터프라이즈 AI 에이전트의 도입 가치로 확인했습니다.
두 사례의 공통점은 명확합니다. 사용하던 모델을 버리는 것이 아니라, 사용하던 모델이 기업 데이터와 지식 위에서 정확하게 작동하는 구조를 만드는 방향을 선택했습니다.
게임·핀테크 환경에서 이 구조가 특히 중요한 이유가 있습니다. 이 업종들은 지표의 정의와 해석이 다른 산업들 보다 매우 상이합니다. '결제 전환율' 하나만 해도 게임사의 아이템 구매 퍼널과 핀테크의 금융 상품 가입 퍼널은 구조가 다릅니다. 범용 Agent가 이 맥락을 학습된 지식 내에서 스스로 파악하기를 기대하는 것은 무리입니다. 이런 산업들은 비즈니스 특화 지식베이스와 지표 정의 계층가 구축되어 있어야 Agent가 중요한 실무에 활용할 수 있게 작동합니다.
AI Agent는 이미 많은 팀의 일상 워크플로우에 들어와 있습니다. 우리 회사 데이터 위에서 AI Agent가 정확하고 안전하게 작동하게 만들려면, Agent와 기업 지식·지표·거버넌스를 연결하는 인프라 계층이 필요합니다.
ThinkingAI는 이러한 인프라를 구축하는 엔터프라이즈 에이전틱 AI 플랫폼으로, AI 모델을 결정한 기업을 위해 이 인프라 역할을 하는 방식 중 하나입니다.
지금 쓰는 Agent와 ThinkingAI가 어떻게 연결되는지 직접 확인하고 싶다면, 데모 신청으로 구체적인 통합 방식을 확인해보세요.
