저는 프로덕션 환경에서 충분한 시간을 보냈기에, 대부분의 'AI 통합 (AI integrations)'이 실제로는 그저 미화된 복사-붙여넣기 루프에 불과하다는 것을 알고 있습니다. 대시보드에서 훌륭한 데이터를 발견하면, 이를 수동으로 JSON 형식으로 내보낸 다음, Claude에 붙여넣고 요약을 요청합니다. 데모용으로는 작동할지 모르지만, 실제 엔지니어링 작업 관점에서는 근본적으로 결함이 있는 방식입니다.

시스템을 운영하는 방식을 실제로 변화시키는 진정한 전환은 더 나은 LLM (Large Language Models)에 관한 것이 아닙니다. 그것은 바로 MCP (Model Context Protocol)에 관한 것입니다. 에이전트가 제가 인간 미들웨어 (human middleware) 역할을 하지 않아도 실제로 여러분의 스택에 접근하여, 데이터베이스를 쿼리하고, 워크플로 (workflow)를 트리거할 수 있게 될 때, 비로소 흥미로운 일이 벌어집니다.

최근 저는 ToolJet와 같은 로우코드 (low-code) 환경과 이러한 신흥 MCP 호환 클라이언트 (Cursor, Claude Desktop 등) 사이의 간극을 어떻게 메울 수 있을지 살펴보고 있었습니다. 만약 여러분이 ToolJet를 사용한다면, 이미 비즈니스 로직 (business logic)을 한곳에 모아둔 상태일 것입니다. 문제는 전통적으로 그 로직이 인간을 위해 설계된 UI 뒤에 갇혀 있다는 점입니다.

'읽기 전용' 에이전트의 문제점

어디에서나 이런 모습을 볼 수 있습니다: 데이터 읽기만 허용하는 MCP 서버 말입니다. 물론, "대기 중인 주문이 몇 개인가요?"라고 묻고 싶을 때는 아주 좋습니다. 하지만 엔지니어로서 저의 업무는 단순히 모니터링하는 것이 아니라, 대응하는 것입니다. 만약 에이전트가 ToolJet 항목에서 심각한 오류를 발견했는데, 이를 수정하는 유일한 방법이 제가 ToolJet 메뉴의 세 단계를 수동으로 탐색하여 '재시도 (Retry)'를 클릭하는 것이라면, 저는 실제로 아무것도 자동화하지 못한 것입니다. 저는 단지 병목 현상 (bottleneck)을 옮겼을 뿐입니다.

Vinkius를 위해 ToolJet MCP 서버를 구축했을 때, 우리는 발견 (discovery)에서 실행 (execution)으로의 전환에 집중했습니다. 단순히 list_tables를 하는 것만으로는 충분하지 않습니다. 행동할 수 있는 능력이 필요합니다.

도구 세트 분해

이 특정 구현이 제공하는 것을 살펴보면, 에이전트의 역량을 정의하는 네 가지 기본 요소 (primitives)가 있습니다.

1. 발견 단계: list_tables 및 query_table

LLM은 스키마 (schema)를 알지 못하면 무용지물입니다. list_tables 도구는 에이전트가 가장 먼저 호출하는 기능입니다. 이 도구는 ToolJet Database 워크스페이스를 조사하여 실제로 어떤 데이터가 존재하는지에 대한 정신적 지도 (mental map)를 구축합니다.

구조를 파악하고 나면, query_table 단계로 넘어갑니다. 이것은 단순한 키-값 (key-value) 조회에 그치지 않습니다. SQL SELECT 문을 지원하기 때문에, 자연어 (natural language)를 통해 조인 (join) 및 복잡한 필터링을 수행할 수 있습니다. 만약 제가 Cursor에게 "최근 30일 동안 주문을 하지 않은 브라질 고객을 모두 찾아줘"라고 말하면, 에이전트는 SQL을 구성하고 이를 ToolJet 데이터베이스에서 실행하여 결과를 제공합니다. 수동으로 데이터를 내보낼(export) 필요가 없습니다.

2. 쓰기 단계: insert_row

이 지점이 바로 '챗봇 (Chatbot)'의 영역을 벗어나 '에이전트적 (Agentic)' 영역으로 진입하는 단계입니다. 만약 에이전트가 특정 패턴을 식별한다면—예를 들어, 로그에서 로그인 실패 시도가 급증하는 것을 발견한다면—단순히 보고만 해서는 안 됩니다. insert_row를 사용하여 해당 이벤트를 기록하거나 지원 티켓 (support ticket)을 직접 생성할 수 있어야 합니다. 이는 관찰과 기록 유지 사이의 간극을 메워줍니다.

3. 실행 단계: trigger_workflow

제 생각에 이 도구 세트에서 가장 중요한 도구는 이것입니다. ToolJet이 강력한 이유는 워크플로 엔진 (workflow engine)—웹훅 (webhook)을 체이닝하고, 스크립트를 실행하며, 제3자 API (Slack, SendGrid 등)와 상호작용하는 능력—덕분입니다.

trigger_workflow 도구를 사용하면 AI 에이전트가 커스텀 JSON 페이로드 (payload)를 담아 웹훅을 호출할 수 있습니다. 이는 에이전트를 오케스트레이터 (orchestrator)로 변모시킵니다. 저는 에이전트에게 다음과 같이 말할 수 있습니다: "테이블 X에 우선순위가 높은 주문이 있습니다. 해당 주문에 대한 주문 이행 (fulfillment) 워크플로를 트리거하세요." 에이전트는 주문 이행이 어떻게 작동하는지 알 필요가 없습니다. 단지 이 도구를 호출함으로써 복잡한 비즈니스 프로세스를 시작했다는 사실만 알면 됩니다.

보안이라는 거대한 문제 (The Security Elephant in the Room)

보안 문제를 언급하지 않고 AI 에이전트에게 SQL 접근 권한을 부여하는 것에 대해 논할 수는 없습니다. 만약 LLM에게 query_table 도구를 준다면, 파괴적인 명령을 실행하려는 시도를 무엇이 막을 수 있을까요?

운영 환경 수준(production-grade)의 설정에서는 '희망'을 전략으로 삼을 수 없습니다. 이것이 바로 제가 격리된 V8 샌드박스(sandboxes)와 엄격한 거버넌스 정책(governance policies)을 갖춘 Vinkius를 구축한 정확한 이유입니다. ToolJet와 같이 민감한 데이터베이스와 상호작용하는 MCP 서버를 실행할 때는 감사 체인(audit chains, HMAC)과 DLP(데이터 손실 방지, Data Loss Prevention) 규칙을 위반할 경우 실행 컨텍스트(execution context)를 즉시 종료할 수 있는 능력이 필요합니다. MCP 기반 자동화는 인프라의 공격 표면(surface area)을 대폭 증가시킵니다.

실제 사용 방법

저는 항상 마찰이 큰(high-friction) 설정에 반대해 왔습니다. 만약 OAuth 콜백을 구성하고 복잡한 환경 변수를 관리해야 한다면, 아무도 일상적인 워크플로우에서 이를 사용하지 않을 것입니다.

제가 권장하는 설정(그리고 저희가 ToolJet 서버를 위해 구현한 방식)은 3단계 패턴을 따릅니다:

2. 연결 토큰(connection token)을 가져옵니다.
3. 이를 Claude 또는 Cursor 설정에 붙여넣습니다.

그게 전부입니다. 데이터베이스를 IDE에 연결하기 위해 DevOps 학위까지 필요해서는 안 됩니다.

이 특정 서버에 대한 표준 설정 및 문서는 여기에서 확인할 수 있습니다: https://vinkius.com/mcp/tooljet

마치며

우리는 'UI'가 점차 보조적인 인터페이스로 변모하여 주로 구성 및 상위 수준의 감독에 사용되는 반면, 일상적인 운영 작업을 처리하는 주요 '인터페이스'는 에이전트 도구 세트(agentic toolset)가 되는 세상으로 나아가고 있습니다.

만약 당신이 여전히 간단한 질문에 답하기 위해 수동으로 데이터베이스를 쿼리하거나, 대시보드의 버튼을 클릭하여 워크플로우를 트리거하고 있다면, 효율성을 놓치고 있는 것입니다. 도구는 준비되었습니다. 프로토콜은 안정적입니다. 이제 AI에 대해 말하는 것을 멈추고 실제로 AI를 데이터에 연결하기 시작할 때입니다.

MCP는 AI 에이전트의 음악입니다. 저희는 카탈로그를 구축했습니다. Vinkius MCP Catalog를 확인해 보세요.