프로토타입은 모델 응답이 그럴듯하면 충분하다. 하지만 프로덕션은 다르다. 실제 환불이 실행되고, 실제 사용자 데이터가 오가고, 실제 비용이 청구된다. AI 기능을 서비스에 녹여내는 순간, "모델이 잘 답하는가"보다 훨씬 근본적인 질문 세 개가 동시에 터진다. 이 작업을 AI가 마음대로 실행해도 되는가. 이 호출이 얼마나 드는가. 이 출력을 얼마나 믿을 수 있는가. 이 세 질문은 각각 승인 경계, 비용 제어, 품질 검증이라는 설계 층위로 번역된다. 그리고 세 층위 모두, 프론트엔드가 가장 먼저 손대야 한다.
첫 번째 층위: 승인 경계
2026년 6월 Vercel이 AI SDK 7을 공개하면서 tool approval, durable execution, hardened approval replay를 production agent의 핵심 기능으로 전면에 내세웠다. 메시지는 분명하다. 에이전트가 실제 서비스 상태를 바꾸는 작업을 수행하는 순간, "AI가 할 수 있는 일"과 "서비스가 허용하는 일"은 명시적으로 분리되어야 한다.
실전 설계는 툴을 세 등급으로 나누는 것에서 시작한다. read tool은 조회 중심이므로 자동 실행이 가능하지만 민감 필드는 반드시 툴 레벨에서 제거해야 한다. write tool은 사용자 승인을 거쳐야 하고, 승인 이후에도 서버에서 입력값 해시를 재검증해야 한다. danger tool은 관리자 권한과 2차 승인, 감사 로그가 필수다. getOrder와 refundPayment가 코드상 같은 함수처럼 보여도 서비스 영향은 완전히 다르다는 사실이 이 분류의 출발점이다.
프론트엔드 관점에서 승인 카드는 단순한 UI 컴포넌트가 아니다. 사용자가 "3,900원 환불 승인" 버튼을 눌렀다는 사실만 믿어서는 안 된다. 화면에 amount: 3900이 표시됐더라도 재개 요청에서 값이 바뀌면 사고가 된다. 승인 토큰에는 툴 이름과 입력값 해시를 묶고, 서버는 재개 시점에 다시 계산해 비교해야 한다. Next.js App Router에서 /api/agent/route.ts Route Handler는 단순 프록시가 아니라 세션 확인, 권한 주입, 툴 허용 목록, 타임아웃, 감사 로그가 모이는 정책 실행 지점이 되어야 한다. 승인 화면은 사용자 경험이면서 동시에 보안 기능이다.
타임아웃도 이 층위의 필수 요소다. 모델 응답이 늦거나 외부 API가 멈췄을 때 "처리 중..." 스피너만 보이면 상담 도구 전체가 죽은 것처럼 느껴진다. "결제 로그 조회가 제한 시간 안에 끝나지 않았습니다. 범위를 줄여 다시 시도하세요."처럼 구체적인 메시지가 운영 도구에서 요구되는 최소 UX다.
두 번째 층위: 비용 제어
dev.to에 공유된 한 프리랜서 개발자의 경험은 숫자 자체가 논거다. 매월 420달러였던 AI API 비용이 28달러로 줄었다. 같은 제품, 같은 사용자, 다른 설계. 핵심은 GPT-4o를 모든 호출에 디폴트로 쓰던 습관을 끊고 태스크 복잡도에 따라 모델을 라우팅한 것이다.
비용 최적화의 첫 번째 레버는 모델 라우팅이다. 분류·태깅 같은 단순 작업에 고성능 모델을 쓰는 것은 소믈리에를 고용해 카프리썬을 따르게 하는 것과 같다. 태스크를 chat·code·classify·summarize·reasoning 등으로 유형화하고, 각 유형에 비용 대비 적합한 모델을 매핑하는 라우터를 먼저 만들어야 한다. 실제로 분류 작업 단가를 $0.60/M에서 $0.01/M으로 낮추자 그 항목만 98% 절감됐다.
두 번째 레버는 에스컬레이션 래더다. 가장 저렴한 모델로 먼저 시도하고, 품질 기준을 통과하지 못하면 다음 등급 모델로 올라간다. 실제 워크로드에서 사용자 입력의 80~85%는 단순 쿼리이고, 진짜 추론이 필요한 입력은 5% 내외다. 파레토 분포를 활용한 이 전략이 비용을 90% 가까이 줄이는 실질적인 구조다.
세 번째 레버는 캐싱이다. "환불 정책이 뭔가요?" 같은 FAQ성 쿼리가 매번 LLM에 도달한다면, 그것은 설계 실패다. 메시지 해시 기반 캐시만으로도 히트율 50~80%가 가능하다. 여기에 시스템 프롬프트 압축까지 더하면 입력 토큰 비용도 제어할 수 있다. 비용 제어는 인프라팀의 몫이 아니다. AI 기능의 호출 구조를 설계하는 프론트엔드·풀스택 개발자가 가장 먼저 결정해야 할 아키텍처 선택이다.
세 번째 층위: 품질 검증
dev.to에서 공유된 또 다른 실전 사례는 eval 시스템의 역설을 정면으로 지적한다. 10,000개 이상의 채용공고를 일별로 처리하는 LLM 스코어링 파이프라인을 운영하던 개발자는, 파이프라인이 숫자를 잘 뱉어내고 있을 때 이미 결과의 상당수가 틀려 있었다는 사실을 뒤늦게 발견했다. 시스템은 자신감 있게 틀리고 있었다.
품질 검증의 첫 방어선은 구조화된 출력이다. LLM에 자유형 텍스트를 요청하고 정규식으로 파싱하는 방식은 모델 업데이트 한 번에 조용히 깨진다. Zod 스키마 같은 엄격한 스키마로 출력 형태를 강제하고, 검증 실패 시 원본 응답을 로깅하고 재시도하는 구조가 할루시네이션의 대부분을 데이터베이스 진입 전에 차단한다. hasSalaryData가 false이면 salaryRange 필드 자체가 없는 스키마 설계가 LLM이 데이터를 "지어내는" 것을 구조적으로 막는다.
하지만 구조 검증은 형식 오류를 잡을 뿐이다. 의미적 드리프트는 잡지 못한다. 완벽하게 유효한 JSON이 의미론적으로는 완전히 틀릴 수 있다. 이를 잡는 두 번째 방어선이 임베딩 유사도 기반 드리프트 감지다. 인간이 검증한 양질의 출력 셋으로 기준 임베딩을 만들고, 새 출력의 코사인 유사도가 임계값 아래로 떨어지면 수동 검토로 라우팅한다. 모델 프로바이더가 기본 동작을 업데이트했을 때, 구조 검증은 통과하지만 유사도가 급락하는 신호가 먼저 잡힌다.
세 번째 방어선은 티어 기반 임계값 시스템이다. 모든 출력을 수동 검토할 수는 없다. 유사도 점수에 따라 자동 승인·플래그·수동 검토 구간을 나누고, 임계값은 사람이 직접 레이블링한 데이터로 튜닝한다. 그리고 이 임계값은 모델이 바뀌거나 데이터 분포가 달라질 때마다 재보정해야 한다. eval 시스템 자체도 드리프트하기 때문이다.
세 층위를 하나의 흐름으로
세 층위는 독립된 체크리스트가 아니다. 서로 맞물린 운영 설계다. 승인 경계가 없으면 비용 최적화를 위해 저렴한 모델로 라우팅된 쓰기 작업이 검증 없이 실행된다. 비용 제어 구조가 없으면 품질 검증 파이프라인 자체가 LLM 호출 비용을 폭발시킨다. 품질 검증이 없으면 승인 흐름을 통과한 작업의 출력이 얼마나 신뢰할 수 있는지 알 수 없다.
프론트엔드 개발자에게 이 세 층위가 중요한 이유는 단순하다. 승인 카드, 스트리밍 상태, 에러 메시지, 타임아웃 피드백은 모두 사용자 경험이다. 동시에 이 UI는 서버 승인 토큰, 모델 라우팅 결과, 구조화 출력 검증 결과와 직접 맞닿아 있다. 화면은 운영 상태의 가장 앞단 인터페이스이고, 프론트엔드 설계는 이 세 층위 전체를 사용자에게 번역하는 작업이다.
"AI 챗봇을 붙여봤다"는 이제 데모 수준의 이야기다. 프로덕션에서 설득력 있는 설계는 이렇게 말한다. 툴 호출을 읽기·쓰기·위험 작업으로 분류했고, 쓰기 작업은 승인과 서버 재검증을 거쳤으며, 모델 라우팅으로 비용을 구조적으로 제어했고, 구조화 출력과 임베딩 유사도로 품질 드리프트를 감지했다. 이 세 층위를 동시에 설계한 시스템만이 프로토타입에서 프로덕션으로 살아남는다.