DEVOCEAN

모든 트랜잭션을 고성능 LLM(대형 언어 모델)에 맡기던 서비스 구조가 한계에 부딪혔습니다. 최근 공개된 측정 사례에 따르면, 1,000건당 3.86달러가 들던 Opus 단독 호출 구조에 불확실성 판별 라우터를 도입하자 정확도 손실을 0.2%p로 막으면서 비용을 0.88달러로 77.2% 감축했습니다.

이 수치가 보여주는 사실은 명확합니다. AI 에이전트의 실무 도입에서 핵심은 모델의 지능이 아니라, 모델이 '자신이 틀릴 수 있음'을 감지하고 위험한 트랜잭션을 제어 계층으로 넘기는 아키텍처 설계입니다. 삼성전자의 D-KMS 암호화 서비스 AI 적용 사례와 뱅크샐러드의 AI 에이전트 판단·실행 제어 특허 출원은 모두 이 하나의 명제, 즉 기계의 무제한 실행을 어떻게 통제할 것인가를 가리키고 있습니다.

확신도 기반 비대칭 라우팅: 불확실한 22%만 상위 모델로

Jev와 Opus를 조합한 라우팅 테스트 사례는 서로 다른 고객 기록을 병합할지 판단하는 분류 작업에서 출발했습니다. 전체 요청을 비싼 Opus에 전량 전달하는 대신, 단가가 저렴한 소형 결정 모델 Jev를 1차 판정기로 배치했습니다.

Jev가 1차로 판정한 점수 중 확신도가 애매한 구간(50% 부근)의 22% 물량만 Opus로 재검토를 보냈습니다. 그 결과 Opus 단독 처리 시 99.0%였던 정확도가 98.8%로 유지되었고, 비용은 4분의 1 수준으로 감소했습니다.

표 1. Opus 단독 구조와 Jev 라우팅 구조의 비용·정확도 비교

• Opus로 가는 물량 — Opus 단독: 전량 / Jev + Opus 라우팅: 22%
• 1,000건당 비용 — Opus 단독: 3.86달러 / Jev + Opus 라우팅: 0.88달러
• 정확도 — Opus 단독: 99.0% / Jev + Opus 라우팅: 98.8%

원문이 말하는 이 실험의 핵심은 경량 모델의 '오답 분포'에 있습니다. Jev의 오답은 확신도 점수 50% 부근에 집중되어 있어, 점수가 낮은 항목만 골라 상위 모델로 보낼 수 있었습니다. 반면 테스트 대상이었던 GPT-6 Luna 모델은 틀린 답을 낼 때도 90% 이상의 높은 확신을 보여 라우팅 기준점으로 사용할 수 없었습니다.

표 2. 오답 시 확신도 분포에 따른 1차 모델 적합성 비교

• Jev — 오답일 때 확신도: 50% 부근에 집중 / 라우팅 기준점 사용: 가능
• GPT-6 Luna — 오답일 때 확신도: 90% 이상 / 라우팅 기준점 사용: 불가

여기부터는 DEVOTEE의 해석입니다. 이 결과는 에이전트 파이프라인을 설계할 때 단순히 "가장 똑똑한 모델"을 고르는 것이 잘못되었음을 의미합니다. 똑똑한 모델보다 중요한 것은 자신이 틀릴 가능성을 점수로 솔직히 출력하는 "라우팅 친화적 모델"을 1차 레이어에 두는 일입니다.

이 패턴은 지금 당장 서비스 프로덕션에 써볼 만합니다. 조건은 1차 모델의 불확실성 점수 분포가 정규 분포 형태를 이루고 있어야 한다는 점입니다. 1차 모델이 무조건 높은 확신도만 뱉는 구조라면 이 라우팅은 작동하지 않습니다.

import dataclasses
from typing import Literal

@dataclasses.dataclass(frozen=True)
class ClassificationResult:
    decision: Literal["MERGE", "KEEP_SEPARATE"]
    confidence_score: float

def route_record_matching(
    record_a: dict, 
    record_b: dict, 
    low_confidence_threshold: float = 0.35,
    high_confidence_threshold: float = 0.65
) -> str:
    # 1차 경량 모델(Jev) 호출
    primary_eval = run_jev_classifier(record_a, record_b)
    
    # 확신도가 경계선(35% ~ 65%) 사이에 몰린 불확실 사례만 고성능 모델(Opus)로 재검토
    if low_confidence_threshold <= primary_eval.confidence_score <= high_confidence_threshold:
        fallback_eval = run_opus_classifier(record_a, record_b)
        return fallback_eval.decision
        
    return primary_eval.decision

def run_jev_classifier(a: dict, b: dict) -> ClassificationResult:
    # 1차 판단 로직 (예시용 dummy)
    return ClassificationResult(decision="MERGE", confidence_score=0.52)

def run_opus_classifier(a: dict, b: dict) -> ClassificationResult:
    # 2차 판단 로직 (예시용 dummy)
    return ClassificationResult(decision="KEEP_SEPARATE", confidence_score=0.95)

시스템 접근권과 이상 탐지의 보안 경계 구축

AI 에이전트가 내부 인프라나 보안 시스템에 접근하기 시작하면 모델의 오류는 단순 텍스트 오답에 그치지 않고 서비스 장애나 데이터 유출로 직결됩니다.

삼성전자의 전사 개인정보 암호화 서비스 D-KMS AX 적용 사례에서는 이 문제를 세 가지 관제 레이어로 풀었습니다. SDK 에러 원인을 진단하는 MCP(Model Context Protocol, 표준 에이전트 연동 규약) 기반 챗봇, 서비스 계정의 트래픽 이상 행위를 탐지하는 AI 이상 감지, 연동 서비스 DB의 암호화 여부를 판별하는 암호화 디텍터입니다.

원문은 보안 계층의 자동화를 구현하면서 개발자 지원 챗봇에 표준 인프라 맥락 인터페이스인 MCP를 결합했음을 밝히고 있습니다. 계정의 트래픽을 AI로 실시간 감시하는 것은 에이전트나 자동화 도구가 인프라 내부에서 권한을 남용하지 못하게 막는 통제선이 됩니다.

원문의 사실을 바탕으로 해석하자면, 보안 및 데이터 관제 영역에 AI를 도입할 때는 "생성(Generation)"보다 "디텍터(Detector)"와 "샌드박스 진단"을 먼저 구축해야 합니다. 암호화 디텍터처럼 정적으로 데이터베이스와 API의 준수 여부를 검증하는 로직이 1선에서 작동하고, 에이전트는 진단된 결과의 가이드만 제공하는 방식입니다.

이 구조는 조건부로 유효합니다. 사내 인프라의 로그 표준화와 API 권한 체계가 이미 완전히 구축된 팀에서만 효과를 봅니다. 트래픽 이상 탐지를 위한 기준선(Baseline) 데이터가 정제되어 있지 않다면 AI 감지기는 오탐 경보를 남발하여 운용 부담을 늘리게 됩니다.

트랜잭션 차단과 차단 레이어: 뱅크샐러드의 에이전트 제어 특허

금융 트랜잭션 분야에서는 단순 제안을 넘어 실제 사용자의 돈을 움직이거나 데이터를 변경하는 실행형 에이전트(Actionable Agent)의 위험성이 극대화됩니다.

뱅크샐러드의 AI 에이전트 판단·실행 제어 기술 특허 출원 소식은 이 위험을 차단하는 런타임 제어 메커니즘을 보여줍니다. 뱅크샐러드는 AI 에이전트가 소비자를 대신해 금융 거래를 진행할 때 발생할 수 있는 잠재적 위험을 차단하고, 환각 오류로 인한 잘못된 실행을 막기 위해 총 3건의 기술 특허를 출원했습니다.

발췌문은 이 기술의 목표가 "AI 에이전트의 판단과 실행을 분리하여 제어하는 것"에 있음을 명시합니다. AI가 계산이나 정보 검색을 마쳤더라도, 최종 '실행(Execution)' 단계 전에서 정적 계산기 검증과 안전망 제어 로직을 거치도록 강제하는 아키텍처입니다.

여기서 DEVOTEE의 해석을 덧붙이자면, 에이전트 아키텍처는 "생각하는 엔진"과 "집행하는 인터페이스"를 완벽히 격리해야 합니다. LLM 내부의 추론 결과는 언제든 환각을 포함할 수 있으므로, 실행 파라미터가 백엔드 API로 들어올 때 거치는 스키마 검증기(Validator)와 금융 법칙 검증 로직이 AI의 상위 권한자로 작동해야 합니다.

interface FinancialTransactionProposal {
  sourceAccountId: string;
  targetAccountId: string;
  amount: number;
  reasoningContext: string;
}

interface ValidationResult {
  isValid: boolean;
  errorCode?: string;
}

class FinancialExecutionGuard {
  // AI 에이전트의 실행 요청을 런타임에서 강제 검증하는 제어기
  public validateAndExecute(
    proposal: FinancialTransactionProposal, 
    userBalance: number
  ): { status: string; message: string } {
    
    // 1. 정적 규칙 검증 (AI 환각 차단)
    if (proposal.amount <= 0) {
      return { status: "REJECTED", message: "유효하지 않은 송금 금액입니다." };
    }
    
    if (proposal.amount > userBalance) {
      return { status: "REJECTED", message: "잔액이 부족합니다." };
    }

    // 2. 금융 비즈니스 로직 2차 검증 호출
    const strictCheck = this.verifyBusinessRules(proposal);
    if (!strictCheck.isValid) {
      return { status: "REJECTED", message: strictCheck.errorCode || "검증 실패" };
    }

    // 3. 검증 완료 후 실제 시스템 API 호출
    this.executeTransaction(proposal);
    return { status: "SUCCESS", message: "트랜잭션이 안전하게 처리되었습니다." };
  }

  private verifyBusinessRules(proposal: FinancialTransactionProposal): ValidationResult {
    // 실제 계좌 상태 및 1일 한도 정적 검증
    if (proposal.sourceAccountId === proposal.targetAccountId) {
      return { isValid: false, errorCode: "SAME_ACCOUNT_TRANSFER_FORBIDDEN" };
    }
    return { isValid: true };
  }

  private executeTransaction(proposal: FinancialTransactionProposal): void {
    // 실제 백엔드 뱅킹 API 호출
    console.log(`Executing transfer of ${proposal.amount} from ${proposal.sourceAccountId} to ${proposal.targetAccountId}`);
  }
}

이 제어 구조는 아직은 지켜볼 단계입니다. 뱅크샐러드의 발표는 특허 출원 단계의 아키텍처 명세 기준이며, 실제 대규모 금융 런타임 트랜잭션에서 발생하는 인프라 지연시간(Latency)과 에이전트 요청 거절률에 대한 운영 수치는 아직 공개되지 않았습니다.

프롬프트 엔지니어링에서 제어 아키텍처로의 전환

세 소식은 AI 파이프라인의 핵심 과제가 프롬프트 수정에서 시스템 제어 계층 설계로 완전히 옮겨갔음을 증명합니다.

단일 LLM 모델에 모든 판단을 의존하는 방식은 비용과 안정성 양쪽에서 장애물을 만납니다. Jev의 사례는 경량 모델의 확신도 평가로 호출 비용을 75% 이상 낮추는 길을 보여주었고, 삼성전자와 뱅크샐러드의 사례는 MCP 챗봇과 트랜잭션 execution guard 구조로 시스템 권한 오용을 막았습니다.

실무에서 에이전트 시스템을 설계할 때는 두 가지 경계를 설정해야 합니다. 첫째는 비용 관점의 라우팅 경계입니다. 모든 입력 트랙에 비싼 모델을 붙이지 말고 1차 판정 모델의 불확실 점수를 측정해 상위 모델 호출 여부를 결정해야 합니다. 둘째는 실행 권한의 보안 경계입니다. LLM이 출력한 JSON이나 명령어를 시스템 API가 그대로 받아 실행하지 않도록 중간 검증기를 반드시 배치해야 합니다.

직접 해 볼 수 있는 한 가지

오늘 당장 운영 중인 LLM 파이프라인의 로그를 열어, 모델이 출력하는 답변의 토큰 수와 판단 확신도(Logprobs 또는 internal confidence score)를 수집하세요.

전체 요청 중 점수가 극단적으로 높거나(상위 70%) 낮은(하위 10%) 영역을 구분해 보세요. 그중 비즈니스 위험도가 낮고 높은 확신도를 보이는 60~70%의 요청을 하위 경량 모델(예: Claude Haiku나 Llama 8B 급)로 이관할 수 있는지 라우팅 조건문을 작성해 테스트하는 것으로 비용 절감을 시작할 수 있습니다.

그 밖의 소식

• 미국 FAA, 2028년까지 항공교통관제에서 플로피 디스크 단계적 퇴출 계획: 400여 곳 관제 시설의 노후 1980년대 EIDS 시스템을 대체하기 위해 125억 달러 예산 투입 진행 중.
• 이제 모든 것이 AI 사기다: 개인화된 생성형 AI 텍스트를 악용한 스팸 광고 및 개인 맞춤형 피싱 사기의 급격한 증가 사례 보고.
• 2026년과 이후 JavaScript의 동향 - WebAssembly: W3C 1.0 권고 이후 스레드, SIMD, WASI 표준화를 거치며 발전 중인 JS 생태계 내 WebAssembly 동향 정리.