Pollinations의 무료 엔드포인트(endpoint)는 첫 번째 요청에 몇 초 만에 응답했으며, 팀의 대화에서는 이미 이를 데모에 사용할 수 있다는 생각이 떠오르고 있습니다. 이 응답은 단 한 가지 사실만을 증명합니다. 즉, 테스트가 진행된 특정 초에 해당 경로(route)가 살아 있었다는 점입니다. 이는 엔드포인트가 연속된 5개의 카드, 회의 중 3개의 병렬 표시, 또는 두 번째 관찰자를 위한 동일한 프롬프트의 재호출을 견딜 수 있는지에 대해서는 아무것도 말해주지 않습니다.

데모를 위해서는 단 한 번의 호출 운이 아니라, 팀에게 정직하게 약속할 수 있는 빈도(frequency)와 병렬성(parallelism) 프로필이 중요합니다. 이 글의 입장은 간단합니다. Pollinations AI API는 단일 성공 응답이 아니라, 일련의 통제된 실행을 통해 확인된 빈도와 병렬성 범위 내에서만 소규모 데모에 적합하다는 것입니다.

다음으로는 각 실행에서 어떤 변수를 기록해야 하는지, 관찰 로그(load-profile)를 어떻게 읽어야 하는지, 왜 공개된 공식 제한 사항들이 스스로 모순되는지, 그리고 부하 상황에서 엔드포인트가 정직한 오류 대신 무엇을 반환하는지에 대해 다룹니다. 여기에는 자체 실행 결과는 포함되어 있지 않습니다. 이 카드는 그 결과를 포함하지 않으며, 타인의 문서화된 수치를 이 글의 측정값으로 제시하지도 않습니다. 아래에는 독자가 직접 일련의 테스트를 수행할 수 있도록 하는 프로토콜과 출처 분석이 담겨 있습니다.

왜 단 한 번의 응답이 연속적인 시연에 대한 준비성을 증명하지 못하는가

흔히 하는 생각은 이렇습니다. 요청에 응답했으니 엔드포인트는 시연에 적합하다는 것입니다. 하지만 이는 실제 시나리오가 시작되는 지점에서 무너집니다. 시연은 단 한 번이 아니라 일련의 호출(series of calls)이기 때문입니다. 첫 번째 응답은 콜드 스타트(cold start)를 측정할 뿐, 반복 상황에서의 안정성을 측정하는 것이 아닙니다.

이러한 차이는 요청 간의 간격(interval)에 제한이 걸려 있는 무료 경로(free route)에서 특히 두드러집니다. Pollinations의 문서(documentation)는 액세스 수준을 다음과 같이 설명합니다: 등록 없는 익명 액세스(anonymous access)는 기본 모델에 대해 15초당 1회 요청, 무료 등록 후 Seed 레벨은 5초당 1회, 유료 Flower 레벨은 3초당 1회, 기업용 Nectar는 모든 모델에 대해 "제한 없는(no limits)" 액세스로 명시되어 있습니다 (APIDOCS.md, 2026-07-18 접속 기준). 만약 데모가 15초당 1회의 호출로 구성된다면 이는 하나의 작동 모드이지만, 만약 5개의 병렬 호출(parallel calls)이 연속적으로 이루어진다면 이는 전혀 다른 문제가 되며, 공개된 간격 정보만으로는 이에 대해 답할 수 없습니다. 이 표에는 병렬성(parallelism)에 대한 언급이 전혀 없기 때문입니다.

만약 이 시나리오가 일회성 시연에서 지속적인 통합(integration)으로 발전한다면, 동일한 측정 프로토콜을 다른 경로에서도 실행할 수 있습니다. provod.ai API는 OpenAI 및 Anthropic 프로토콜과 호환되므로, 이미 작성된 코드에서 base_url과 키(key)를 교체하는 것만으로 전환이 가능합니다. 하지만 이는 통합에 관한 별개의 문제이지, Pollinations의 수치를 다른 엔드포인트(endpoint)에 그대로 적용해야 할 근거는 아닙니다. 경로 간의 비교는 자체 로그가 확보된 후 아래에서 다시 다루겠습니다.

각 통제된 실행(controlled run)에서 기록해야 할 사항

일련의 테스트가 무언가를 증명하기 위해서는 각 실행이 재현 가능(reproducible)해야 합니다. 입력 단계에서는 네 가지 변수를 기록합니다: 정확한 요청(동일한 프롬프트(prompt) 및 파라미터(parameters)), 빈도(요청 간 간격), 병렬성(동시에 열려 있는 연결 수), 그리고 액세스 수준입니다. 출력 단계에서는 세 가지 필드를 로그(log)로 남깁니다: HTTP 상태(HTTP status), 응답 대기 시간(waiting time), 그리고 관찰된 모든 제한 사항입니다.

액세스 수준(Access level)은 인증 메커니즘을 결정하며, 이 부분에서 실수하기 쉽습니다. 문서에서는 티어(tier)를 높이는 두 가지 방법을 설명합니다: 브라우저 애플리케이션을 위한 리퍼러 식별(referrer-identification, 예: referrer=myapp.com과 같은 자동 리퍼러 헤더)과 서버 측 액세스를 위한 auth.pollinations.ai의 Bearer 토큰입니다. 문서는 Bearer 토큰을 프론트엔드(frontend) 코드에 배치해서는 안 된다고 명시적으로 경고합니다 (APIDOCS.md, 2026-07-18 접근). 백엔드(backend)에서 일련의 실행을 수행하는 경우에는 이 방식이 유효하지만, 페이지에 내장된 데모의 경우에는 리퍼러(referrer)만 사용해야 합니다.

코드에 비밀 정보(secrets)를 포함하지 않는 bash 기반의 최소한의 실행 프레임워크입니다. BASE 변수에 사용할 생성 호스트(generation host)는 테스트 시점의 문서를 참조해야 합니다: APIDOCS.md에서 gen.pollinations.ai는 문서(docs)로 들어가는 진입점으로만 명시되어 있으며, 생성기(generator) 자체가 아니므로 이를 BASE에 대입해서는 안 됩니다.

PROMPT="cat"
BASE="<APIDOCS.md의 생성 호스트>"
for i in $(seq 1 10); do
...

여기서 &와 wait는 병렬성(parallelism)을 설정하고, sleep은 빈도(frequency)를 설정하며, -w 플래그는 상태(status), 첫 번째 바이트까지의 시간(time to first byte), 그리고 본문 크기(body size)를 로그에 기록합니다. 본문 크기는 완전성을 위한 것이 아닙니다. 아래에서 왜 이것이 상태 코드(status)가 보여주지 않는 숨겨진 제한 사항을 포착하는 데 필요한지 설명하겠습니다.

동일한 원칙이 문서 진입점에도 적용됩니다: 공식 문서는 현재 enter.pollinations.ai/api/docs에서 301 리다이렉트되는 gen.pollinations.ai/docs를 통해 확인할 수 있습니다. 해당 페이지는 JavaScript를 통해 클라이언트 측에서 렌더링되며, 2026-07-18 기준 자동 fetch로는 현재의 제한 사항 테이블을 가져올 수 없었습니다 (문서 진입점, 2026-07-18 접근). 실질적인 결론은 다음과 같습니다: 생성 호스트와 테스트 시점의 구체적인 제한 수치는 이 글에 고정된 값을 사용하지 말고, 문서를 통해 인터랙티브하게 직접 확인하십시오.

공식 제한 수치가 일치하지 않는 이유

단일 사례의 성공이 약속의 근거로 무용지물인 이유는 다음과 같습니다. 공식적인 1차 출처(first-party sources)들조차 동일한 수준에 대해 서로 다른 수치를 제공하기 때문입니다. 문서 파일(documentation file)은 간격 기반의 제한을 설명합니다. 즉, 병렬성(parallelism)에 대한 언급 없이 15초당 1회의 익명 접근을 명시합니다. 반면, 동일한 리포지토리(repository) 내의 2025-10-27자 최신 엔지니어링 티켓(issue #4817)은 코드에 실제로 구현된 다른 스키마(schema)를 기록하고 있습니다: 익명 요청은 제한된 모델 세트에 대해 6초 간격 및 1개의 동시 요청, 직접 API 토큰을 사용한 요청은 티어(tier)별 병렬성을 포함한 7초 간격, enter.pollinations.ai를 통해 인증된 요청은 모든 모델에 대해 1초 간격 및 최대 20개의 동시 요청입니다.

이는 단순한 전달 과정의 오독이 아니라, 하나의 프로젝트에 있는 두 개의 1차 출처(first-party sources) 간의 수치적 불일치입니다. 해당 티켓은 "Done" 상태로 표시되어 있습니다. 제한 로직은 shared/ipQueue.js와 shared/auth-utils.js에 존재하며, 티어 우회는 text.pollinations.ai/server.js의 x-enter-token 헤더와 연결되어 있습니다 (issue #4817, 2026-07-18 접속). 여기서 "Done" 상태는 유지보수자가 현재 코드의 구현 상태를 선언한 것을 의미할 뿐, 해당 동작이 문서 파일의 수치와 일치한다는 독립적인 확인을 의미하는 것은 아닙니다. 이 둘은 서로 다른 것이며, 출처를 혼동해서는 안 됩니다.

실질적인 결론은 하나입니다. 게시된 값들이 하나의 안정적인 수치를 형성하지 않는다면, 테스트 시점의 실제 작동 모드를 알 수 있는 방법은 오직 자신의 로그(log)를 확인하는 것뿐입니다. 출처 간의 불일치는 방법론의 장애물이 아니라, 왜 이 방법론이 필요한지에 대한 근거가 됩니다.

429 에러 대신 엔드포인트(endpoint)가 반환하는 것

HTTP 상태 코드만으로는 로그가 거짓말을 할 수 있는 별도의 함정이 있습니다. 공식 리포지토리의 2026-01-13자 버그 리포트에 따르면, 이미지 생성 엔드포인트(endpoint)의 제한(limit)이 발생했을 때 429 에러를 반환하지 않습니다. 대신 약 1.3MB 크기의 플레이스홀더(placeholder) 이미지와 고정된 MD5 해시 2090a5dc21c32952cbf8496339752bd1를 포함한 HTTP 200 응답이 전달됩니다. 반면, 정상적으로 생성된 이미지는 크기가 약 40~80KB이며 각 요청마다 고유한 해시를 가집니다 (issue #7207, 2026-07-18 접속). 리포트 작성자는 표준 429 응답으로 전환할 것을 요청했으나, 스레드 데이터 수집 시점까지 이 동작의 변경 사항은 기록되지 않았습니다.

이러한 이유로 위에서 제시한 실행 프레임워크에서는 응답 코드뿐만 아니라 바디(body) 크기를 로그에 기록합니다. 10번의 "200 OK" 연속 성공은 겉보기에는 완벽한 성공처럼 보이지만, 그중 일부 이미지는 모두 동일한 플레이스홀더일 수 있습니다. 로그에 해시 값을 포함하는 줄을 추가하십시오:

md5sum /tmp/out_$i.bin   # 동일한 해시가 ~1.3MB로 반복되면 결과물이 아닌 플레이스홀더임

이 사실을 입증된 범위 이상으로 확장하지 않기 위해 두 가지 주의사항을 둡니다. 플레이스홀더 동작은 2026-01-13자로 기록되었으며 이미지 생성에 국한된 설명입니다. 별도의 로그 확인 없이 이를 텍스트 엔드포인트(endpoint)로 일반화해서는 안 됩니다. 또한, 2025년 3월 31일부터 익명의 무료 이미지에는 워터마크(watermark)가 포함될 수 있으며, auth.pollinations.ai에 등록하는 것이 이를 제거하고 더 높은 티어(tier)를 얻는 방법으로 문서화되어 있습니다 (APIDOCS.md, 2026-07-18 접속). 따라서 데모 실행 시의 유효한 응답은 첫 번째 테스트와 다르게 보일 수 있습니다.

이는 비용 측면에서 또 다른 층위를 더합니다. Pollen 시스템의 문서에 따르면, 무료 모델(예: Flux 이미지)은 티어와 관계없이 항상 0 Pollen이며, 유료 모델은 Pollen을 소모합니다. 등록된 개발자에게는 매일 Pollen 그랜트(grant)가 추가로 지급되는데, 이는 당일에 소멸하며 구매한 잔액보다 먼저 사용됩니다 (POLLEN_FAQ.md, 2026-07-18 접속). 여기서 "무료"는 전체 경로가 아닌 특정 모델에 해당하며, 이 점 또한 데모 전에 반드시 기록해 두어야 합니다.

로그를 읽고 허용 가능한 데모 모드 할당하기

이 시리즈의 최종 결과물은

만약 시나리오가 VPN 없이 러시아에서 결제를 요구한다면, provod.ai는 루블 잔액, 러시아 카드 결제, SBP(System of Fast Payments) 또는 계좌 이체를 지원하며, 모델은 provod.ai의 추가 수수료 없이 제공업체의 공식 가격으로 이용할 수 있습니다. 이는 Pollinations의 무료 프로필과 불투명한 Pollen 시스템이 팀의 예산이나 예측 가능성 측면에서 더 이상 만족스럽지 않을 때, provod.ai를 예비 경로로서 눈여겨봐야 할 별개이면서도 관련 있는 이유입니다. 하지만 바로 그렇기 때문에, 자체적인 부하 한계를 이번 시리즈를 통해 직접 측정해야 합니다. 방법론의 규칙은 Pollinations의 문서화된 수치나 보고된 수치를 직접 측정하는 대신 다른 경로로 대체하여 적용하는 것을 엄격히 금지하기 때문입니다.