증명하기, 1부: AI 스타트업에게 ‘아마도 맞을 것이다’는 충분하지 않은 이유

AI 시대에 Startup의 성패를 가르는 기준은 첨단 모델이나 대규모 훈련 데이터 세트가 아니라 신뢰입니다. 주요 차별화 요소는 사용자가 그 기업을 신뢰하는지 여부와 “AI가 잘못되면 어떻게 될까?”라는 질문에 대한 답을 제시할 수 있는지 여부입니다. 단지 확률론적 확신이 아니라 수학적 확실성을 갖추어야 합니다. 규제가 심한 시장에서는 모델 역량보다 검증이 갈수록 중요해지고 있습니다.

이제 막 시드 투자를 마무리한 상황입니다. AI 기반 대출 도우미가 지난 주에 200명의 베타 사용자를 대상으로 서비스를 시작했습니다. 셋째 날, 한 고객이 계약금 8%만으로도 일반 주택담보대출 자격이 된다는 챗봇의 답변 내용을 스크린샷으로 찍어, 그 내용을 소셜 미디어에 올렸습니다. 하지만 회사 정책상 최소 계약금은 20%여야 합니다.

그 게시물을 가장 먼저 본 사람은 공동 창업자였습니다. 두 번째로는 투자자가 보았고 법률 고문이 그 다음으로 게시물을 확인했습니다.

이는 가상의 이야기가 아닙니다. 2026년에 AI 제품을 구축하는 기업들이 실제로 겪고 있는 현실입니다. 불과 2년 전만 해도 50명의 엔지니어가 필요했을 제품을 이제는 불과 3명이 팀으로 개발하고 있으며, 아이디어에서 MVP까지 도달하는 시간도 몇 달에서 며칠로 단축되었습니다.

하지만 검증 없는 속도는 오히려 법적 리스크가 됩니다. 생성형 AI는 할루시네이션을 불러일으키거나, 자체 정책과 모순되거나, 고객에게 잘못된 답변을 제공하는 제품을 쉽고도 위험할 정도로 빠르게 출시할 수 있도록 만들었습니다. 단순히 “제공했다”와 “신뢰할 수 있는 제품을 제공했다” 사이의 간극, 바로 거기에서 Startup이 실패하게 됩니다.

근본 원인은 구조적인 문제에 있습니다. 대규모 언어 모델은 확률적 시스템입니다. 즉, 다음으로 가능성이 있는 토큰을 예측하여 텍스트를 생성합니다. 이 프로세스에는 설계상 무작위성이 수반됩니다. 온도, 샘플링 전략, top-k/top-p 파라미터는 모두 변동성을 야기합니다. 동일한 프롬프트라도 실행할 때마다 다른 답이 나올 수 있습니다. 이것이 LLM이 창의적이고 유용한 이유지만, 그와 동시에 정확성이 요구되는 작업에서 근본적으로 신뢰할 수 없는 이유이기도 합니다. 이 예의 모델은 잘못된 모기지 자문을 제공하려고 의도한 것이 아니라, 가장 가능성이 높은 다음 토큰을 예측한 것뿐입니다.

모든 AI 스타트업은 이 딜레마를 해결해야 합니다. 고객, 규제 기관 및 투자자에게 정확성을 보장하면서 확률론 시스템을 구축하는 방법은 과연 무엇일까요?

AI가 틀린 답을 내놓으면 어떻게 되나요?

AI가 잘못된 지침을 제공하고 고객이 이에 따라 행동할 때 그 결과는 여러분의 몫이 됩니다. 의료 AI가 수백 건의 환자 상호 작용에 대해 보험 보장 결정을 잘못 제시한 경우, 심각도 등급에 따라 위반 건당 137 USD에서 68,928 USD 사이의 HIPAA 민사 벌금이 발생할 수 있으며, 최근 물가연동 조정 수치에 따르면 위반 범주당 연간 상한선은 2,067,813 USD에 달합니다. 따라서 미처 문제를 인지하기도 전에 벌금이 총 자금을 초과할 수 있습니다. GDPR에는 심각한 위반에 대한 벌금이 2,000만 EUR 또는 전 세계 연간 총 매출액의 4% 중 더 높은 금액으로 규정되어 있습니다. EU 고객 데이터를 처리하는 초기 단계의 Startup에게 이는 단순한 벌금으로 끝나는 문제가 아니라 사실상 사업 중단을 의미합니다. 자격이 없는 사람의 대출을 승인하는 핀테크 챗봇은 규제상 법적 책임을 초래합니다. 보험 적용 약관을 잘못 인용하는 보험 봇은 이길 수 없는 계약상의 분쟁을 야기합니다.

보안 검토를 통과하지 못해 무산되는 기업 거래, AI가 의사 결정을 내리는 방법을 설명할 수 없어 중단되는 SOC 2 감사, “AI가 잘못되면 어떻게 될까?”라고 묻지만 만족스러운 답을 얻지 못하는 시리즈 A 투자자 등, 직접적인 벌금 외에 부차적인 비용도 발생할 수 있습니다.

프롬프트 엔지니어링과 RAG만으로는 충분하지 않은 이유

LLM을 활용하여 구축되는 모든 스타트업은 비슷한 형태의 안전성 스택을 갖추고 있습니다. 신중한 프롬프트 엔지니어링, 검색 증강 생성(RAG), 어느 정도의 수동 검토 등이죠. 이는 모범 사례들지만 그것만으로는 충분하지 않습니다.

프롬프트 엔지니어링은 경험적이며 증명할 수 없습니다. 모델이 올바른 행동을 하도록 유도하는 지침을 만들지만 모델이 지침을 따른다는 보장은 없습니다. 새 모델 버전으로 업그레이드하거나 새로운 엣지 케이스를 처리하도록 시스템 프롬프트를 조정하면 이전에 안전했던 동작에서 서서히 문제가 발생할 수 있습니다. 강제할 메커니즘 없이 비공식 계약을 통해 안전을 구축하고 있는 셈입니다.

RAG는 검색된 문서를 기반으로 모델의 답변을 뒷받침하여 할루시네이션 발생 가능성을 줄입니다. 이는 실질적인 개선이지만 모델은 여전히 검색된 컨텍스트를 무시하거나 잘못 해석하거나 선택적으로 사용할 수 있습니다. RAG는 더 나은 답변이 나올 확률 쪽으로 확률 분포를 이동시킬 뿐, 잘못된 답변이 나올 가능성을 없애지는 못합니다. ‘일반적으로 정확하다’는 것은 규정 준수 전략이 아닙니다.

수동 QA는 성장 속도에 맞춰 확장되지 않습니다. 적극적인 샘플링(상호 작용의 10%를 확인) 기법에서도 90%는 검증되지 않은 상태로 남습니다. 매달 10만 건의 고객 상호 작용을 처리하는 Startup의 경우, 결과를 샘플 검사하기 위해 리뷰어를 고용하는 데 연간 수십만 USD의 비용이 듭니다. 이는 초기 단계의 팀이 감당하기 어려운 인력 규모이며, 검토하지 않은 90%에 대해서는 단지 문제가 없기를 기대하는 수밖에 없습니다. 이 비용은 일회성이 아닙니다. 고객이 질문을 하는 방식은 시간이 지남에 따라 변화합니다. 사용하는 모델 자체도 지속적으로 변경됩니다. 이전에 신뢰할 수 있었던 동작은 정기적인 모델 업데이트 후에 성능이 저하될 수 있습니다. 지난달에는 효과가 있었으나 다음 달에는 제대로 작동하지 않을 수 있습니다. QA 프로세스를 지속적으로 평가하고, 다시 테스트하고, 조정해야 하기 때문에 한 번 해결하면 되는 문제가 아니라 영구적인 비용 발생으로 이어집니다.

공통점은 이러한 접근 방식이 리스크를 줄여줄 뿐, 확실성을 제공하지는 못한다는 것입니다. 투자자가 "귀사의 AI가 잘못된 결과를 생성할 수도 있나요?"라고 물었을 때, 이러한 도구들만 사용하고 있다면 솔직한 답변은 "아마 아닐 겁니다. 대부분의 경우에는요"가 됩니다. 하지만 그것은 시리즈 A 투자를 성사시키는 답변도 아니고, 규제 기관을 만족시키는 답변도 아닙니다.

자동 추론이란 무엇인가요?

자동 추론은 수학적 논리를 사용하여 시스템이 무엇을 할 것인지, 하지 않을 것인지에 대한 근거를 제공하는 컴퓨터 과학의 한 분야입니다. 데이터로부터 패턴을 학습하는 기계 학습과 달리, 자동 추론은 수학적 논리, 정리 증명, 제약 조건 해결을 사용하여 가능한 모든 입력의 무한한 공간에 걸쳐 특정 속성이 항상 성립함을 증명합니다.

이 차이는 매우 중요합니다. 기계 학습 모델이 "이 출력은 95%의 확률로 정확하다"고 하는 것은 통계적 주장일 뿐입니다. 반면 자동 추론 시스템이 "이 출력은 유효하다"고 하는 것은, 해당 출력이 사용자가 정의한 모든 제약 조건을 만족한다는 수학적 증명을 구성한 것입니다. 여기에는 신뢰 구간이 존재하지 않습니다. 증명이 존재하든지, 존재하지 않든지 둘 중 하나입니다.

자동화 추론은 대규모 언어 모델(LLM)을 대체하는 기술이 아닙니다. 고객의 질문을 이해하고 자연스러운 답변을 생성하기 위해서는 여전히 언어 모델이 필요합니다. 자동 추론이 제공하는 것은 그 위에 추가되는 검증 계층입니다. 즉, LLM은 생성하고, 자동 추론은 검증합니다.

두 기술이 함께 사용될 때 창의성과 정확성이 공존하는 완전한 스택이 구성됩니다. AI는 여전히 대화형이고, 유용하며, 빠르게 응답할 수 있습니다. 하지만 자동 추론은 사용자가 정의한 비즈니스 규칙과 규제 준수 요건의 범위 안에서만 AI가 동작하도록 보장합니다.

AWS가 자동 추론을 사용하는 방법

AWS는 수년 동안 프로덕션 환경에서 자동 추론을 사용하여 Startup을 비롯한 모든 고객이 운영하는 인프라를 보호해 왔습니다.

• AWS IAM Access Analyzer의 기반이 되는 자동 추론 엔진인 Zelkova는 만족도 모듈로 이론(SMT) 풀이 기법을 사용하여 IAM 및 Amazon Simple Storage Service(Amazon S3) 정책이 의도한 대로 정확하게 작동하는지 수학적으로 검증함으로써, 수동 검토로는 찾을 수 없는 의도하지 않은 액세스 경로를 찾아냅니다.
• 현재 CNCF 샌드박스 프로젝트로 진행 중인 Cedar는 처음부터 자동 추론을 통해 검증되도록 구축된 최초의 권한 부여 정책 언어로, Amazon Verified Permissions를 지원합니다.
• 형식이 검증된 최초의 클라우드 하이퍼바이저인 Nitro Isolation Engine은 약 26만 줄에 달하는 기계 검사 증명을 통해 Amazon Elastic Compute Cloud(Amazon EC2)의 테넌트 격리를 보장합니다.
• AWS의 오픈 소스 TLS 라이브러리인 s2n-tls는 공식 증명을 사용하여 암호화 연산이 타이밍 기반 사이드 채널 공격에 안전하다는 것을 검증합니다.

Startup 빌더들에게 중요한 점은 바로 이것입니다. Amazon Bedrock과 Amazon Bedrock AgentCore를 통해 사용할 수 있는 수학적 검증 기법은 연구실 수준의 실험적 프로토타입이 아닙니다. 이는 AWS가 S3의 내구성, EC2의 격리성, 그리고 AWS 서비스와의 모든 TLS 연결의 보안을 보장하는 데 사용하는 것과 동일한 엔지니어링 원칙을 바탕으로 한 기술입니다. 과거에는 이러한 기술을 활용하려면 형식 검증 박사들로 구성된 사내 전문 팀을 구축해야 했으며, 이는 연구소 수준의 예산을 가진 조직만 누릴 수 있는 사치였습니다. 하지만 이제 Bedrock과 AgentCore는 이러한 역량을 종량 요금제 API 호출 형태로 제공합니다.

Startup은 자동 추론을 어떻게 사용할 수 있을까요?

Startup 팀의 경우 이제 두 제품을 통해 동일한 수학적 검증 원칙을 직접 사용할 수 있으며, 각 제품은 AI 신뢰 문제의 서로 다른 계층을 지원합니다.

Amazon Bedrock Guardrails의 자동 추론 검사는 SMT 기반 형식 로직(Zelkova와 동일한 접근 방식)을 사용하여 LLM의 출력 콘텐츠가 비즈니스 규칙에 부합하는지 확인합니다. 먼저, 대출 기준, 의료 프로토콜, 규정 준수 규칙 등 비즈니스에 필요한 모든 정책을 정의합니다. 그런 다음 이 시스템은 이를 형식 로직으로 변환하고 모든 LLM 응답을 해당 규칙과 비교, 검증합니다. 모델에서 정책과 모순되는 내용이 발견되면 시스템이 이를 포착하여 정확히 어떤 규칙을 위반했는지와 그 이유를 알려줍니다.

이 게시물 맨 위에서 소개한 모기지 시나리오의 경우 시스템은 8%의 계약금 오류를 포착하고 LLM이 사용자에게 도달하기 전에 답변을 다시 작성할 수 있도록 정확한 금액을 제안했을 것입니다.

Policy in Amazon Bedrock AgentCore는 Cedar(인증을 위한 오픈 소스 정책 언어)를 사용하여 AI 에이전트 작업에 결정론적 경계를 적용합니다. AI가 도구를 호출하여 중요한 결정(예: 민감한 데이터에 액세스하거나, 외부 시스템에 데이터를 작성하거나, 사용자를 대신하여 작업을 수행하는 경우)을 내리는 에이전트 애플리케이션을 구축하는 경우, Policy는 게이트웨이 경계에서 모든 에이전트-도구 간 요청을 인터셉트하여 실행 전에 Cedar 정책과 비교, 평가합니다. 정책의 적용은 결정론적으로 이루어집니다. 이는 에이전트의 추론과는 독립적으로 작동하며, 에이전트 코드의 즉각적인 삽입, 할루시네이션 또는 버그를 우회할 수 없습니다. 의료, 핀테크 또는 법률 분야 Startup의 경우, 수학적으로 검증된 정책을 바탕으로 에이전트가 할 수 있는 일과 할 수 없는 일을 규제 기관에 정확히 제시할 수 있습니다.

AWS의 형식 검증 포트폴리오에 포함된 다른 시스템(Nitro Isolation Engine, s2n-tls, s2n-quic, Dafny)은 간접적으로 사용자에게 이점을 제공합니다. 즉, 실행하는 모든 EC2 인스턴스는 형식이 검증된 격리를 기반으로 하며, 모든 TLS 연결은 형식이 검증된 암호화를 사용합니다. Bedrock Guardrails와 Policy in AgentCore는 형식 검증이 애플리케이션 코드에 직접 적용되는 지점입니다.

두 계층, 하나의 원칙: 확률적 신뢰에 대한 수학적 형식 검증.

이 시리즈의 다음 편에서 다루는 내용

이 글은 3부로 구성된 시리즈 중 1부입니다. 2부: 형식 논리, Cedar 정책, 검증의 경제학에서는 자동 추론 정책의 작동 방식, 비즈니스 규칙이 형식 로직으로 바뀌는 방식, 검증 파이프라인의 형태, 수학적 검증과 수동 QA 팀의 경제성에 대해 자세히 살펴봅니다. 3부: 단계별 구현 플레이북에서는 Bedrock Guardrails AR 검사 및 Policy in AgentCore를 스택에 통합하기 위한 프로덕션 준비 코드 패턴이 포함된 실습 가이드를 제공합니다.