공급업체는 오늘 검증을 통과하고 내일은 다른 계약 조건이 될 수 있습니다. 당신은 카탈로그를 비교하고, 가격을 100만 토큰당 루블화로 환산하고, 인증 방식이 당신의 설계에 부합하는지 확인한 뒤, 키를 연결하고 실사 (due diligence) 탭을 닫았습니다. 이 순간부터 당신이 결정을 내렸던 조건들은 제멋대로 흘러가기 시작하며, 당신의 공급업체 카드는 연결된 날짜에 그대로 멈춰 있게 됩니다.

이 글은 Polza.ai를 사용하는 것이 옳은가에 대한 글이 아닙니다. 이미 사용하기로 결정한 후에 무엇을 해야 하는지에 대한 글입니다. 즉, 카탈로그, 가격, 인증 방식 또는 데이터 저장 모드가 변경되었음을 어떻게 감지하고, 이러한 변경 사항을 사후 사고 분석이 아닌 팀의 결정과 연결할 것인가에 대한 이야기입니다.

단호하고 검증 가능한 논지는 다음과 같습니다: 만약 팀이 Polza.ai의 주요 조건에 대한 날짜가 기록된 스냅샷(snapshots)과 각 변경 사항에 대한 결정 사항을 보여줄 수 없다면, 그 팀은 연결 이후의 계약을 추적하고 있는 것이 아니라, 단지 시작할 때의 상태를 기억하고 있을 뿐입니다.

연결이 공급업체 검증의 끝은 아니다

일반적인 기본 설정은 다음과 같습니다: 애그리게이터 (aggregator)에 대한 1차 검증이면 충분하며, 그 이후에는 자동 항법 장치(autopilot) 모드로 살아도 된다는 것입니다. Polza.ai의 이용 약관은 이러한 설정을 정면으로 깨뜨립니다. 제6.4조는 서비스가 "언제든지" 요금을 변경할 수 있는 권리를 규정하며, 제21.2조는 사용자와의 협의 없이 "언제든지" 약관 조건을 변경할 수 있다고 명시하고 있습니다 (user-agreement 페이지, 2026-07-18 참조).

통지 메커니즘은 문제를 더욱 심화시킵니다. 제21.5조에 따르면, 새로운 버전의 약관에 대한 통지는 당신이 텍스트를 읽었는지 여부와 관계없이 인터페이스에 첫 번째 팝업 배너가 표시된 시점에 완료된 것으로 간주됩니다. 서비스의 계속 사용은 동의와 동일시됩니다. API의 경우, 이는 당신의 통합 (integration)이 이미 새로운 조건에 따라 요청을 계속 보낼 수 있음을 의미하며, 공식적인 "동의"는 당신이 아닌 당직 개발자가 본 배너를 통해 인정될 것입니다.

여기서 우리는 하나의 작업 표준(working norm)으로 받아들여야 할 결론에 도달합니다. Polza.ai의 조건은 정적인 공급업체 카드(static card)가 아니라, 반복 가능한 절차(repeatable procedure)로서 확인해야 한다는 것입니다. 만약 당신이 여러 공급업체를 운영하며 별도의 애그리게이터(aggregator)인 provod.ai — OpenRouter의 러시아판를 추가한다면, 로그(journal)는 모두에게 동일하게 유지됩니다. 즉, 동일한 필드, 동일한 스냅샷(snapshot) 형식을 가지되 서로 다른 행(row)으로 기록됩니다.

이러한 제어가 제공하는 가치를 과대평가하지 않는 것이 중요합니다. 이것은 프로덕트 매니저(product manager)의 생각을 읽거나 미래의 요금제를 예측하지 않습니다. 대신, 팀의 다음 결정이 내려지기 전, 이미 게시된 변경 사항을 포착합니다. 즉, 게시되기 전에는 알 수 없으며, 어디에도 게시되지 않는 내용을 찾아내는 것도 아닙니다.

어떤 필드를 관리해야 하는가?

모든 것을 제어하려 하는 것은 아무것도 제어하지 못하는 것과 같습니다. 애그리게이터에게는 통합의 비용, 작동 가능성 및 법적 리스크에 직접적인 영향을 미치는 네 가지 필드, 즉 카탈로그(catalog), 가격(prices), 인증(authorization), 데이터(data)만으로도 충분합니다. 다섯 번째 필드는 공급업체에 관한 것이 아니라 당신에 관한 것입니다: 바로 검토 날짜(review date)입니다.

각 필드에는 Polza.ai 측의 원천 데이터(primary source)가 있으며, 이는 매우 중요합니다. 원천 데이터가 없는 스냅샷은 사실이 아니라 소문에 불과합니다. 아래는 스냅샷을 단순히 전달하는 것이 아니라 재현(reproduce)할 수 있도록, 필드와 그 값이 추출되는 위치를 정리한 지도입니다.

Четыре контрольных поля Polza.ai и их первичные источники

날짜가 포함된 스냅샷과 로그를 어떻게 작성하는가?

스냅샷은 링크를 통해 재검증할 수 있는, 재현 가능한 소스가 포함된 한 줄의 기록입니다. 최소한의 기록 형식은 필드, 값, 날짜, 소스, 영향(impact), 결정(decision)입니다. 앞의 네 가지는 사실을 기술하며, 마지막 두 가지는 당신의 대응을 기술합니다. 마지막 두 가지가 없다면 로그는 아무도 읽지 않는 아카이브(archive)로 전락하고 맙니다.

이미 변화가 확인된 인증(authorization)부터 시작하십시오. Polza.ai API를 확인한 시점에 인증은 기본 URL https://polza.ai/api/v1과 함께 헤더의 Authorization: Bearer YOUR_API_KEY를 사용하는 정적 키(static key) 방식으로 이루어지며, 키는 등록 후 개인 계정에서 발급됩니다. 팀원 누구나 이를 확인할 수 있습니다. "api polza ai"라고 검색하면 스냅샷에서 참조할 동일한 공개 문서가 나타납니다. 하지만 변경 이력(changelog)에 따르면 2026년 4월에 서드파티 애플리케이션을 위한 OAuth 2.0 PKCE 플로우(flow)가 추가되었습니다. 즉, 인증 모델이 초기 연결 이후에 이미 변경되었다는 뜻입니다. 이것이 바로 완벽한 스냅샷 기록 한 줄이 됩니다.

snapshot 2026-07-18

field: авторизация (authorization)
value: "static API key (Authorization: Bearer) + OAuth 2.0 PKCE, 2026년 4월에 추가됨"
...

동일한 방식으로 카탈로그 (catalog), 가격 (prices), 데이터 (data)에 대해서도 한 줄을 생성합니다. 확인 시점의 카탈로그는 OpenAI, Anthropic, Google, DeepSeek, Meta, Mistral, Qwen, Microsoft, Perplexity, Cohere, xAI 및 Minimax의 "400개 이상의 모델"로 명시되어 있습니다 (메인 페이지, 2026년 7월). 변경 이력 (Changelog)에는 새로운 제공업체인 Sber/GigaChat, fal.ai, YandexArt, Yandex AI Studio의 등장과 Kling 2.6/3.0 요금제 업데이트가 별도로 기록됩니다. 이러한 각각의 이벤트는 버전의 날짜를 포함한 새로운 행을 생성하는 근거가 됩니다 (예: 2026년 4월 25일자 v1.5.3).

그다음부터 로그는 단 하나의 규칙에 따라 운영됩니다: 각 행에는 스냅샷 날짜, 필드의 일차적 출처 (primary source), 그리고 영향에 대한 결정 (decision on impact)이 있어야 합니다. 이 세 가지 중 하나라도 누락되면 해당 행은 인정되지 않습니다. 날짜와 출처가 없다면 비교하거나 재검증할 대상이 없기 때문입니다. 또한, 결정 사항이 기록되지 않으면 변경 사항은 고정되어 있지만 처리되지 않은 상태로 남게 됩니다. 이 경우 통제는 형식적인 것에 불과합니다.

Структура записи версионированного журнала изменений условий

Polza.ai는 이미 조건을 변경한 적이 있습니다

"선택된 필드를 통해 변경 사항을 감지할 수 있을 것"이라는 가설은 간단하게 검증됩니다. 일부 변경 사항은 이미 공개되었으며 날짜가 지정되어 있습니다. 변경 이력 (Changelog)은 공급업체가 직접 관리하는 일차적 출처로서, 버전별 카탈로그, 가격, 인증의 변경 사항을 추적합니다. 네 개의 제어 필드 중 세 개에 대해 이는 말 그대로 즉시 사용 가능한 이벤트 피드 (event feed) 역할을 합니다.

법률적인 측면은 이러한 가시성이 단순히 완벽주의 때문이 아님을 확인시켜 줍니다. 개인정보 처리방침 (Personal Data Processing Policy) 또한 버전이 관리되는 문서입니다. 예를 들어, 2025년 12월 8일자 "제2판"은 일방적으로 변경될 수 있으며, 새로운 판은 게시되는 즉시 효력이 발생합니다. 즉, "데이터" 필드는 코드를 통해 변경되는 것이 아니라 문서 게시를 통해 변경되며, 누군가 버전을 대조해 보기 전까지는 당신의 통합 (Integration) 시스템이 이를 전혀 감지할 수 없다는 뜻입니다.

여기서 두 가지 수준의 주장을 구분해야 합니다. 사실(Fact): 변경 이력 (Changelog)은 OAuth PKCE 및 새로운 제공업체(Provider)의 추가를 날짜와 함께 기록했습니다. 결론(Conclusion): 제어 필드의 변경은 결정 사항의 재검토를 요구할 수 있지만, 그 자체로 피해를 입증하는 것은 아닙니다. OAuth 플로우 (OAuth flow)가 정적 키 (Static key)를 사용하는 당신의 통합에 전혀 영향을 주지 않았을 수도 있으며, 이 경우 로그에 남는 올바른 결정은 "변경 사항이 기록되었으나 영향 없음"이 됩니다. 로그가 필요한 이유는 매 버전마다 패닉에 빠지기 위해서가 아니라, 모든 변경 사항에 대해 명확한 결정(Decision)을 내리기 위해서입니다.

암호화 약속은 무엇을 숨기고 있는가?

Polza.ai의 메인 페이지에서 약속은 아름답게 표현되어 있습니다: "모든 대화는 완전히 암호화되어 있으며 저희조차 접근할 수 없습니다." 구매 담당자에게 이것은 기술적 정보가 아닌 마케팅 문구입니다. 여기에는 위협 모델 (Threat model), 저장 범위, 또는 제공업체에 대한 예외 조항이 전혀 포함되어 있지 않습니다.

개인정보 보호 문서 (Privacy documentation)는 이와는 전혀 다른, 훨씬 더 세분화된 그림을 설명합니다. 단일한 암호화 정책 대신, 제공업체별로 서로 다른 데이터 저장 모드가 존재합니다. "안전한" 제공업체 (Azure, Groq, Amazon Bedrock 등)는 데이터를 저장하지 않습니다. "임시 저장" 제공업체 (OpenAI, Anthropic, Cohere, Google Vertex, Mistral, xAI, Inflection)는 데이터를 최대 30일 동안 저장합니다. 일부 제공업체 (DeepSeek, OpenInference)는 모델 학습을 위해 데이터를 잠재적으로 사용할 수 있는 것으로 표시되어 있습니다. 플랫폼 자체는 사용 통계와 미디어 파일을 7일 동안 저장합니다.

이것은 기만 행위에 대한 비난이 아닙니다. 쇼윈도에 내걸린 약속과 문서(documentation)상의 문구가 세부 사항에서 서로 일치하지 않는 전형적인 사례이며, 계약에 있어 중요한 것은 바로 문서입니다. 여기에 함정이 숨어 있습니다. 카탈로그에서 모델을 선택하면, 동시에 해당 제공업체(provider)의 데이터 저장 모드를 선택하게 됩니다. 따라서 애플리케이션을 한 모델에서 다른 모델로 전환하면, 사용자 모르게 '저장 안 함'에서 '최대 30일' 또는 '학습에 사용될 수 있음'으로 변경될 수 있습니다. 그렇기 때문에 로그의 '데이터(data)' 필드는 암호화에 관한 단일 행이 아니라 모드 테이블과 날짜를 기록합니다. 개인정보 보호 페이지에는 마지막 수정 날짜가 표시되지 않기 때문입니다.

Три режима хранения данных по провайдерам Polza.ai

가격은 한 번만 확인해서는 안 된다

가격은 가장 유동적인 필드이며 날짜 정보가 가장 불분명합니다. 특정 모델 페이지에는 1M 토큰당 루블(₽) 단위의 비용이 표시됩니다. 예를 들어, 확인 시점의 GPT-4.1은 입력(input)당 208.28 ₽, 출력(output)당 833.11 ₽입니다. 페이지 자체에는 가격 업데이트 날짜가 표시되지 않으며, 하단(footer)에 '2025-2026'이라는 일반적인 저작권 범위만 명시되어 있습니다. 이는 가시적인 신호 없이도 숫자가 변경될 수 있음을 의미합니다.

이것이 얼마나 현실적인지는 출처를 대조하는 과정에서 드러난 불일치를 통해 알 수 있습니다. 동일한 GPT-4.1에 대해 웹 검색을 통한 독립적인 확인 결과, 실제 페이지의 값과는 다른 입력 176.1552 ₽, 출력 704.6208 ₽(1M 토큰당)라는 결과가 나왔습니다. 원인은 밝혀지지 않았습니다. 검색 엔진의 캐시(cache)일 수도 있고, 오래된 스냅샷이거나 서로 다른 요금제 옵션일 수도 있습니다. 솔직히 말씀드리자면, 이것은 '불안정한 가격'에 대한 증거라기보다는, 일회성 확인 대신 날짜가 포함된 스냅샷이 왜 필요한지를 보여주는 사례입니다. 날짜가 없는 두 숫자를 가지고 있다면, 당신은 그중 어떤 것이 '현재'인지 알 수 없습니다.

「가격 (price)」 필드에 대한 실무적인 방법은 간단합니다. 숫자를 기록하고, 스냅샷 날짜를 수동으로 설정하며, 모델 페이지의 URL을 지정하고, 동일한 측정 방식(1M 토큰당 입력/출력)을 유지하는 것입니다. 그렇게 하면 다음 확인 시 누군가의 캐시(cache)와 실제 라이브 페이지를 비교하는 것이 아니라, 비교 가능한 것과 비교 가능한 것을 비교하게 됩니다. 또한 소스의 한계를 기억하세요. GitHub의 공개적인 변경 로그(changelog)는 제품 및 API 변경 사항을 다루지만, 이것이 모든 요금제 변경 사항을 반영하는지는 알 수 없습니다. 따라서 가격은 버전 피드(version feed)뿐만 아니라 모델 페이지에서 직접 확인해야 합니다.

Расхождение цен GPT-4.1 без указания даты снимка

다른 애그리게이터(aggregators)들을 함께 관리하는 방법은?

동일한 필드를 가진 모든 공급업체에 대해 동일한 로그 방식이 적용됩니다. 이는 각 업체의 광고용 쇼윈도가 아닌, 공통된 기준에 따라 실제 비용과 리스크를 파악할 수 있는 편리한 방법입니다. 여기서 provod.ai는 비교를 위한 약속 없이 별도의 애그리게이터(aggregator)로서 로그에 기록됩니다. 동일한 네 개의 필드, 동일한 날짜가 지정된 스냅샷, 그리고 자신만의 행을 갖게 됩니다.