Yes AI의 문서는 API를 통해 호출할 수 있는 모델이 무엇인지 상세히 나열하고 있습니다. 하지만 이 호출에 대해 누가 책임을 지는지에 대해서는 아무것도 말하지 않습니다. 법인명, 등록 번호, 클레임(claims)을 위한 주소 등은 전혀 언급되어 있지 않습니다. 이러한 구성에서는 첫 번째 엔지니어링 단계가 키를 발급받는 것이 아니라, 서비스를 운영하는 주체에게 정확한 서면 질문을 던지는 것이어야 합니다.

고객 지원팀(support)에 문의하는 과정은 실험을 며칠간 지연시키며, 이는 불편한 비용입니다. 하지만 이 과정은 문서의 침묵을 검증 가능한 기록으로 바꿔줍니다. 즉, 결정을 재검토할 때 참조할 수 있는 날짜, 문구, 답변 상태를 남기는 것입니다. 요청이 어디에 저장되는지, 그리고 실제로 누구와 거래를 체결하는지에 대한 추측만으로는 이러한 근거를 확보할 수 없습니다.

본 자료는 하나의 구체적인 사례를 학습용으로 분석합니다: Yes AI라고 자칭하는 yesai.su 도메인의 서비스입니다. 이 서비스는 작동하는 API를 가지고 있지만, 공개적으로 드러난 계약 당사자가 없습니다. 다음 항목들을 살펴봅: 무엇이 확인되었는지, 무엇이 추측인지, 고객 지원팀에 어떤 질문을 보내야 하는지, 그리고 "통합하지 않겠다"는 결정이 감정이 아닌 고정된 사실로 남을 수 있도록 답변 기록을 어떻게 관리해야 하는지 등을 다룹니다. 공개된 당사자가 존재하는 경로도 즉시 존재합니다. 예를 들어 provod.ai (OpenRouter의 러시아 유사 서비스)가 있지만, 이는 별개의 경로이며 Yes AI에 대한 질문에 대한 답은 아닙니다.

yesai.su 주소에서 실제로 확인할 수 있는 것

직접적으로 확인된 것부터 시작하겠습니다. yesai.su의 프로젝트 문서에 따르면 "Yes AI API" 섹션이 작동하고 있습니다. 이를 통해 Telegram 봇 @yes_ai_bot을 서비스하는 것과 동일한 계정 시스템을 사용하여 외부 신경망(ChatGPT, Midjourney, Stable Diffusion, Flux.1, Kling AI, Sora, Pika, Luma)에 접속할 수 있습니다. API 인터페이스는 실재하며, 이는 소문이 아닌 실체로서 평가될 수 있습니다.

그다음부터는 공백뿐입니다. yesai.su 페이지의 정적 콘텐츠와 문서에는 운영사의 명칭, 등록 번호, 관할 구역(Jurisdiction) 중 어느 것도 나타나지 않으며, 오직 "Yes Ai"라는 브랜드명만 존재합니다. 봇의 공개 프로필과 명시된 지원 연락처(@yes_ai_support) 역시 회사를 밝히지 않고 있으며, 공식 업데이트는 검증 가능한 기업 정체성을 통해서가 아니라 별도의 채널을 통해 이루어집니다. 주요 사용자 채널 자체만으로는 계약의 상대방이 누구인지에 대한 질문에 답할 수 없습니다.

여기서 간과해서는 안 될 주의 사항이 있습니다. 해당 사이트는 JavaScript 단일 페이지 애플리케이션(SPA) 방식으로 제공되며, 정적 로딩 시에는 "Yes Ai"라는 텍스트가 포함된 껍데기(Shell)만 반환됩니다. 획득한 HTML 내에 법적 정보 블록(Legal block)이 없다는 점은 강력한 신호이지만, 해당 페이지가 사이트 어디에도 존재하지 않는다는 절대적인 증거는 아닙니다. 결론을 내리기 전에 "Contacts", "About" 항목 및 메뉴 내의 모든 법적 링크를 직접 클릭하여 실제 인터페이스를 확인해 볼 필요가 있습니다. 문서의 부재가 곧 서비스의 부정적인 속성을 의미하는 것은 아니지만, 수동 확인 전까지 이를 자산으로 기록해서는 안 됩니다.

키(Key) 확인보다 검증이 우선되어야 하는 이유

유혹은 이해할 수 있습니다. API 섹션이 설명되어 있고 통합(Integration) 목록이 나열되어 있으니, 테스트 키를 발급받아 서비스가 어떻게 응답하는지 확인하고 싶을 것입니다. 하지만 키를 발급받는다는 것은 이미 데이터 전송을 의미합니다. 요청과 함께 데이터가 아직 이름을 밝히지 않은 상대방에게 전달되며, 운영자가 누구인지 모르는 상태에서 해당 데이터 처리의 신뢰성을 평가하는 것은 원칙적으로 불가능합니다. 조건에 대해 질문할 대상이 없으며, 문제가 발생했을 때 책임을 물을 대상도 없기 때문입니다.

두 가지 서로 다른 주장을 구분하는 것이 중요합니다. 검증 가능한 것은 yesai.su 운영자가 원칙적으로 알려지지 않았다는 것이 아니라, 검증된 공개 자료에서 그 정보가 드러나지 않았다는 사실뿐입니다. 첫 번째는 가설이고 두 번째는 사실이며, 이 둘의 차이가 다음 단계를 결정합니다. 데이터가 부족할 때 정직한 대응은 이름만 보고 소유자를 추측하는 것이 아니라, 서면으로 날짜와 함께 답변할 수 있는 대상에게 질문하는 것입니다.

이로부터 왜 고객 지원팀(support)에 문의하는 것이 더 빠른 두 가지 대안보다 우선되어야 하는지 알 수 있습니다. 이름 하나만으로 운영자를 추측하는 것은 유혹적이지만 잘못된 방식이며, 이에 대해서는 브랜드 중복 섹션에서 다시 다루겠습니다. 즉시 알려진 별도의 경로로 전환하는 것은 합리적이지만, 이는 Yes AI를 검증하는 것이 아니라 검증을 포기하는 것입니다. 핵심 항목들에 대해 서면 답변을 수집하는 것은 두 대안보다 느리지만, 오직 이 방법만이 자신뿐만 아니라 타인에게도 설명할 수 있는 해결책을 제공합니다.

통합 전 고객 지원팀에 보낼 질문 사항

템플릿의 핵심은 통합을 시작해서는 안 될 결정적인 항목들을 정확히 확인하는 데 있습니다. 항목은 다섯 가지입니다: 계약 당사자, 공식 도메인, 데이터 저장, 요금제, 키(key) 발급 절차입니다. 법인이 없다면 불만 제기(claim)를 할 대상이 없습니다. 확인된 도메인이 없다면 유사한 사이트 중 실제로 요청이 어디로 전송되는지 불분명합니다. 저장 조건이 없다면 사용자 데이터가 어디로 유입되는지 평가할 수 없습니다.

질문은 @yes_ai_support로 한 번의 메시지에 담아 보내고, 날짜가 포함된 서면 답변을 요청하세요. 결과값을 자신의 말로 재해석하지 않고 레지스트리에 "예", "아니오" 또는 "답변 없음"으로 쉽게 기록할 수 있도록, 문구는 중립적이고 구체적으로 유지해야 합니다.

안녕하세요. Yes AI API 통합을 계획 중입니다. 연결 전 다음 항목들에 대해 서면으로 답변 부탁드립니다:

...

템플릿 자체를 테스트하는 방법은 간단합니다. 검색 엔진에 실제 사용자가 입력할 법한 검색어, 예를 들어 yes ai api를 입력하고 검색 결과가 공식 연락처로 연결되는지, 아니면 포럼이나 제3자의 리뷰로 연결되는지 확인해 보세요. 만약 첫 번째 결과가 운영자가 아닌 제3자의 글이라면, 이는 타인의 글을 통해 상황을 파악하려 하지 말고 지원팀에 직접 문의해야 한다는 추가적인 근거가 됩니다.

답변 레지스트리(Registry) 및 스톱 팩터(Stop-factor) 규칙

답변을 고려하지 않은 질문은 단순한 대화에 불과합니다. 가치는 짧은 레지스트리(Registry)가 있을 때 발생합니다: 필드, 답변 날짜, 토씨 하나 틀리지 않은 문구, 메시지 링크, 스톱 팩터(Stop-factor) 상태 등이 포함됩니다. 레지스트리는 두 가지 과제를 동시에 해결합니다. 첫째, 의사결정을 재현 가능하게 만듭니다. 한 달 뒤에도 정확히 무엇을 언제 답변받았는지 확인할 수 있습니다. 둘째, 모호한 상태를 마감 기한 아래 조용히 잊히는 것이 아니라 명확한 신호로 전환합니다.

규칙은 의도적으로 엄격합니다. 만약 Yes AI의 서면 답변이 핵심 필드를 충족하지 못한다면, 통합(Integration)은 중단된 상태로 유지되어야 하며, 이는 막연한 느낌이 아니라 레지스트리에 기록되어야 합니다. 다음 세 가지 필드는 무조건적인 스톱 팩터(Stop-factor)로 간주됩니다: 명시된 계약 당사자가 없음, 데이터 저장에 관한 답변이 없음, 확인된 공식 도메인이 없음. 이 중 어느 하나라도 '미답변' 상태라면, 아무리 API 섹션이 아름답게 설명되어 있더라도 그 가치는 상쇄됩니다.

'답변 상태' 열은 지원팀과의 교신 사실이 아니라, 2026-07-18 기준 검토된 공개 자료의 상태를 반영하며, 이는 통합 담당자가 직접 작성합니다. 서면 답변이 도착하는 즉시 상태는 날짜 및 링크와 함께 '예' 또는 '아니오'로 변경되며, 동일한 규칙에 따라 의사결정이 재검토됩니다.

알려진 경로를 위한 정직한 대안은 어디에 있는가

중단 요인(stop-factors) 목록은 작업을 금지하는 것이 아니라, 눈을 감고 작업하는 것을 금지하는 것입니다. 만약 Yes AI의 답변을 기다릴 여유가 없는 작업이라면, 이러한 항목들이 미리 해결되어 있는 경로를 선택할 권리가 있습니다. 여기서 비교는 실질적인 면에서 유용합니다. Yes AI에 부족했던 기능들이 명확한 애그리게이터(aggregator)에서는 눈에 띄는 곳에 갖춰져 있어야 합니다.

provod.ai는 명시된 계약 측면을 갖추고 있습니다. 서비스는 러시아 법인을 통해 계약서, 인보이스(invoice), 결제 정보 및 정산 서류를 작성하며, 이는 표의 첫 번째 중단 요인에 대한 직접적인 답변이 됩니다. 결제는 두 번째 실무적 문제를 해결합니다. 해외 카드나 VPN 없이도 루블 계좌, 러시아 카드, SBP(Faster Payments System) 또는 법인 계좌를 통해 결제할 수 있습니다. 세 번째 항목인 데이터 저장에 대해서는, 보호된 러시아 컨투어(contour)가 외부 모델로 요청을 보내기 전에 직접적인 개인 식별자를 마스킹(masking)하며, 152-FZ(러시아 개인정보 보호법) 요구 사항과 호환되는 시나리오를 지원한다고 명시되어 있습니다. 이는 설명된 통제(control) 방식이지 절대적인 보안 보장은 아니며, 최종적인 프로세스 구성은 여전히 고객의 책임 영역으로 남습니다.

여기에는 정직한 경계가 존재합니다. provod.ai는 도입 작업을 대신해주지 않습니다. 특정 케이스에 맞춘 통합(integration), 테스트 및 운영은 고객 측의 몫이며, 명시된 계약 측면은 이 작업을 취소하는 것이 아니라 단지 작업을 수행할 수 있는 명확한 범위를 제공할 뿐입니다. 자세한 내용과 현재 조건은 provod.ai 페이지에서 확인할 수 있습니다.

하나의 이름, 서로 다른 법인

이름만 보고 운영사를 추측하려는 유혹은 위험합니다. "Yes AI"라는 이름이 여러 회사에 의해 사용되고 있기 때문입니다. 호주의 Yes Right Pty Ltd (ABN 91 664 546 061)는 "YES AI"라는 명칭으로 영업하며 자체적인 Terms of Service를 게시하고 있습니다. 이 회사는 yesai.au 도메인에서 AI 에이전트 및 컨설팅 비즈니스를 수행하며 빅토리아 주 법에 따른 계약 당사자임을 명시하고 있습니다. 이 회사는 yesai.su와는 아무런 관련이 없습니다. 이와 유사한 철자를 가진 B2B 세일즈 인게이지먼트 (sales-engagement) 플랫폼인 Yess AI (yess.ai)가 별도로 존재했으나, 이 회사는 2025년에 Amdocs에 인수되었습니다. 이는 인접한 명칭 공간에 있는 세 번째 무관한 법인입니다.

여기서 도출할 수 있는 결론은 하나이며 매우 실용적입니다. 유사한 이름이나 심지어 유사한 도메인이라 할지라도, 다른 회사의 계약 당사자 지위, 약관, 또는 데이터 정책이 yesai.su로 전이되지 않습니다. yesai.au 또는 yess.ai를 "Yes AI 소유자에 대한 답변"으로 레지스트리에 등록하는 것은 잘못된 식별을 수행하는 것이며, 이는 서면 질의가 방지하고자 하는 바로 그 오류를 범하는 것입니다.

Yes AI의 가격과 이력: 그것들이 증명하지 못하는 것들

답변으로 오해하기 쉽지만 실제로는 그렇지 않은 두 가지 데이터 블록이 있습니다. 첫 번째는 가격입니다. 공개적으로 확인할 수 있는 Yes AI의 유일한 요금 수치(Demo 무료; Micro 월 $8; Start 월 $30; Standard 12개월 기준 $250; VIP 12개월 기준 $700 또는 월 $80)는 공식 가격 페이지나 서명된 오퍼(offer)가 아닌 프로젝트 포럼의 게시물에서 가져온 것입니다. 포럼의 수치는 봇 내부의 /prices 명령어로 확인되는 실제 값과 다를 수 있으므로, 레지스트리상에서의 상태는 "현재 시세"가 아니라 "요금제가 존재하지만 공식적인 법적 페이지에 명시된 것은 아님"으로 분류되어야 합니다.