챗봇의 함정

지난 1년 동안의 제품 변경 로그(changelog)를 아무거나 열어봐도 똑같은 움직임을 발견할 수 있습니다. 구석에 있는 채팅 버블, 반짝이는 아이콘, 그리고 제목에 AI라는 단어가 포함된 출시 게시물 말이죠. 이 위젯은 제품에 관한 질문에 답합니다. 때로는 이메일 초안을 작성하기도 합니다. 모두가 이를 출시하고, 모두가 이를 AI-native라고 부르지만, 거의 모든 이들이 잘못된 계층(layer)을 해결하고 있습니다.

채팅 위젯은 당신의 제품에 '관한' 대화(conversation about)입니다. 그것은 UI 위에 자리 잡고 당신의 문서(docs)를 의역할 뿐입니다. 모델은 당신의 도메인(domain)에 전혀 손을 대지 않습니다. 실제로 무언가를 해달라고 요청해 보세요. 신용 전표(credit note)를 발행하거나, 은행 내역을 조정하거나, 분기별 신고서를 제출하라고 말이죠. 그러면 모델은 당신에게 링크 하나를 건네며 행운을 빌어줄 뿐입니다. 당신은 AI-native 제품을 만든 것이 아닙니다. CRUD 앱에 지원 봇(support bot)을 볼트로 조여 붙인 것뿐입니다.

판단 기준은 간단합니다. 만약 채팅 위젯을 제거한다면, 그 소프트웨어가 에이전트(agent)에 의해 작동되는 방식이 더 나아지거나 나빠지겠습니까? 만약 대답이 '아니오'라면, 그 AI는 장식에 불과합니다.

진짜 질문

"사용자가 내 제품에 대해 채팅할 수 있는가"라고 묻는 것을 멈추십시오. 대신 "에이전트가 내 제품을 '운영(operate)'할 수 있는가"라고 물으십시오.

운영한다는 것은 실시간 데이터(live data)를 대상으로, 사람이 개입하지 않고(unattended), 당신의 API가 퍼스트 클래스 통합(first-class integration)에 제공하는 것과 동일한 보장(guarantees)을 가지고 상태를 변경하는 작업(state-changing work)을 수행하는 것을 의미합니다. "내 송장을 요약해줘"가 아닙니다. 송장을 생성하고, 이메일로 보내고, 결제 완료로 표시하고, 고객이 이의를 제기하면 수정 사항을 발행하는 것 — 즉, 타입이 지정된 입력(typed inputs)과 타입이 지정된 결과(typed results)를 가진 개별적이고 호출 가능한 작업(discrete, callable actions)이어야 합니다.

이러한 재정의는 작업을 한 계층 아래로, 즉 프레젠테이션 계층(presentation tier)에서 벗어나 당신의 도메인(domain) 내부로 이동시킵니다. 그리고 이는 불편한 사실을 드러냅니다. 대부분의 제품은 버튼을 클릭하는 인간이나 누군가가 수동으로 연결한 맞춤형 통합(bespoke integration)이 아닌 호출자(caller)를 위한 깔끔한 인터페이스(surface)를 가지고 있지 않다는 사실입니다. 에이전트에게는 그 중간 단계의 무언가가 필요합니다. 즉, 좁은 범위의(narrow), 타입이 지정된(typed), 호출하기 안전하고(safe to call), 재시도하기 안전한(safe to retry) 무언가가 필요합니다.

패턴: 당신의 도메인을 타입이 지정된 도구(typed tools)로 노출하기

패턴: 각 도메인 작업을 도구 (tool) 로 노출하기 — 이름이 지정된 함수로서, 타입이 지정된 입력 스키마 (input schema), 타입이 지정된 출력 스키마 (output schema), 그리고 모델이 이를 언제 호출할지 결정하기 위해 읽는 한 줄짜리 설명 (description)을 가집니다. 모델은 사용자의 HTML을 파싱하거나 REST 경로를 추측하지 않습니다. 대신 기능 카탈로그 (catalog of capabilities)를 보고 하나를 선택합니다.

이것이 바로 Model Context Protocol (MCP)가 표준화하는 것입니다. 모든 제품이 각자 자신만의 에이전트 인터페이스를 발명하는 대신, MCP는 전송 방식 (transport)과 형태 (shape)를 정의합니다: tools, resources, 그리고 prompts — 이 모든 것은 발견 가능하며, 도구 (tools)는 stdio 또는 Streamable HTTP를 통해 호출 가능합니다. 도메인을 MCP 도구로 한 번 작성하면, MCP를 지원하는 어떤 클라이언트든 이를 구동할 수 있습니다.

패턴의 형태 (실제 프로덕션 코드는 아님):

server.registerTool(
  "create_invoice",
  {
...

설명 (description)은 주석이 아니라 계약 (contract)의 일부입니다. 모델은 라우팅을 위해 이를 읽습니다. 스키마 (schemas)는 문서가 아니라, 확률론적인 호출자 (probabilistic caller)를 결정론적인 시스템 (deterministic system) 내에 머물게 하는 가드레일 (guardrails)입니다. 그리고 반환 형태 (return shape)에 주목하세요: SDK는 데이터가 서버를 떠나기 전에 outputSchema를 기준으로 structuredContent를 검증합니다. 그 검증이 바로 핵심입니다.

엔지니어들이 직면하는 어려운 부분들

도구 등록은 쉬운 20%에 불과합니다. 나머지 80%는 에이전트 주도 호출 (agent-driven call)을 안전하게 만드는 모든 것이며, 바로 이 지점에서 대부분의 AI-native 출시 제품들이 조용히 무너집니다.

에이전트별 인증 (auth) 및 스코핑 (scoping). 인간의 세션과 에이전트의 세션은 동일한 위협 모델 (threat model)이 아닙니다. 각 에이전트 ID는 자신만의 자격 증명 (credential)과 자신만의 권한 범위 (scope)를 가져야 합니다 — 예를 들어 invoices:write 권한이 payroll:read 권한을 의미해서는 안 됩니다. Bearer 키나 PKCE를 사용하는 OAuth 2.1 권한 부여 코드 흐름 (authorization-code flow) 모두 작동합니다. 중요한 것은 도구 계층이 연결 (connection) 기준이 아닌 호출 (call) 기준으로 스코프를 확인해야 하며, 다른 에이전트들을 무력화하지 않고도 특정 에이전트의 권한을 취소할 수 있어야 한다는 점입니다.

멱등성 (Idempotency). 에이전트는 재시도(retry)를 합니다. 타임아웃이 발생하거나, 계획을 재수립하거나, 네트워크 일시 오류로 응답을 놓쳤을 때 동일한 호출을 두 번 실행할 수 있습니다. 만약 create_invoice가 멱등성을 보장하지 않는다면, 고객은 두 개의 인보이스를 받게 되고 클라이언트는 매우 혼란스러워질 것입니다. 상태를 변경하는 모든 도구(tool)는 멱등성 키(idempotency key)와 서버 측 중복 제거(server-side dedup)가 필요합니다. 이는 인간용 UI에서는 인간이 기계의 속도로 재시도하지 않기 때문에 생략해도 무방한, 다소 지루한 배관 작업(plumbing)과 같습니다.

타입화된 계약 (Typed contracts). outputSchema는 모델이 데이터의 형태를 환각(hallucination)하지 않고 호출을 체이닝(chaining)할 수 있게 해주는 핵심 요소입니다. 산문(prose)이 아닌 구조화된 JSON을 반환하세요. 리스트 작업의 경우, 에이전트가 모든 데이터를 보았는지 추측하는 대신 결정론적으로 페이지를 넘길 수 있도록 실제 페이지네이션(pagination) — { data, total, limit, offset } — 을 반환해야 합니다.

감사 추적 (Audit trail). 비인간 행위자(non-human actor)가 재무적 또는 회계적 상태를 변경할 때,

AI-native ERP인 Frihet에서는 MCP 서버를 일급 제품 인터페이스 (first-class product surface)로 취급합니다. 이는 github.com/Frihet-io/frihet-mcp에서 오픈 소스로 제공되며, npm에서 @frihet/mcp-server로 배포됩니다. 또한 ERP 도메인 전반에 걸쳐 송장 (invoices), 비용 (expenses), 고객 (clients), CRM, 제품 (products), 견적 (quotes), 뱅킹 (banking), 전자 송장 (e-invoicing), 시간 추적 (time tracking), 급여 (payroll), 결산 (period close), 그리고 스페인 및 카나리아 제도 세무 모델을 포함한 **157개의 도구 (tools)**를 노출합니다. 모든 도구는 outputSchema를 통해 타입이 지정된 JSON을 반환하는 REST API 상의 CRUD 작업이며, 도구 목록 조회는 페이지가 구분된 { data, total, limit, offset } 형식을 반환합니다.

에이전트 (agent)는 품목이 포함된 송장을 생성하고, 이를 PDF로 이메일 발송하며, 결제 완료로 표시하고, 고객이 이의를 제기할 경우 신용 전표 (credit note)를 발행할 수 있습니다. 이는 하나의 체인된 흐름(chained flow)이지만 네 개의 개별적인 도구가 사용된 것입니다. 또한 비용을 기록 및 검색하고, 견적서를 초안 작성 및 발송하며, 은행 거래를 분류하고 이를 송장과 매칭할 수도 있습니다.

재무적 인터페이스 (fiscal surface)는 도메인의 깊이가 드러나는 지점입니다. 스페인 세무 신고를 준비하는데, 분기별 IVA (Modelo 303) 및 IRPF (Modelo 130), 연간 390 및 347 요약 보고서, 그리고 카나리아 제도를 위한 IGIC를 포함합니다. 또한 VeriFactu 제출 상태를 확인하고 거부된 기록을 재전송하며, EN16931 전자 송장을 생성하고 TicketBAI를 지원합니다.

인증 모델은 '어려운 부분 (hard-parts)' 섹션에서 다룬 것과 동일합니다. Bearer 토큰으로서의 API 키 (fri_ 접두사 사용) 또는 이를 발급하는 브라우저 OAuth 로그인을 사용하며, 클라이언트별로 선택할 수 있습니다. 이는 부수적인 사항이 아닙니다. 데모 수준의 제품과 실제 운영 환경의 장부 (production books)에 실행을 허용할 수 있는 제품 사이의 차이입니다.

핵심은 도구의 개수가 아닙니다. 도메인이 타입이 지정되고 구조화되며 페이지가 구분된 작업 (operations)으로 노출된다는 점입니다. 따라서 에이전트는 ERP에 대해 채팅하는 것이 아니라, ERP를 직접 운영합니다.

귀하의 제품은 에이전트 네이티브 (agent-native)입니까?

간단한 체크리스트입니다. 만약 '예'라고 답할 수 없다면, 귀하는 AI-native 제품이 아니라 채팅 위젯 (chat widget)을 가지고 있는 것입니다.

• 텍스트가 아닌 도구 (Tools, not text). 에이전트가 귀하의 핵심 역량을 입력 및 출력 스키마 (schema)를 가진 타입 지정 함수 (typed functions)로 나열할 수 있습니까?
• 관찰이 아닌 동작 (Operate, not observe). 에이전트가 단순히 읽고 요약하는 것을 넘어, 상태를 변경(생성, 전송, 수정)할 수 있습니까?
• 범위가 지정된 정체성 (Scoped identity). 각 에이전트가 호출별 범위 (per-call scope)를 가진 고유한 자격 증명 (credential)을 가지며, 독립적으로 취소 가능합니까?
• 멱등성 쓰기 (Idempotent writes). 모든 상태 변경 호출 (mutating call)이 멱등성 키 (idempotency key)를 수용하고 서버 측에서 중복을 제거 (dedup) 합니까?
• 구조화된 결과 (Structured results). 모델이 파싱해야 하는 산문 (prose)이 아니라, 실제 페이지네이션 (pagination) 기능이 포함된 타입 지정 JSON을 반환합니까?
• 복구 가능한 오류 (Recoverable errors). 오류 발생 시 무엇이 잘못되었고 다음에 무엇을 해야 하는지를 결정론적 (deterministically)으로 명시합니까?
• 감사 추적 (Audit trail). 인간이 아닌 모든 상태 변경 (mutation)에 대해 누가 무엇을 했는지 재구성할 수 있습니까?

AI-native는 위에 덧칠하는 레이어가 아닙니다. 그것은 그 아래에 있는 인터페이스, 즉 에이전트가 호출할 수 있는 도구로 노출된 귀하의 도메인 (domain)입니다. 그 표면을 구축한다면 챗봇은 사소한 오차 (rounding error)가 될 것입니다. 그것을 건너뛴다면, 귀하가 가진 전부은 결국 챗봇뿐일 것입니다.