팀이 크리에이티브 파이프라인 (creative pipeline)에 NovelAI로의 자동 호출을 설계했는데, 통합 단계에서 필요한 단계에 대해 문서화된 공개 엔드포인트 (public endpoint)가 없다는 사실이 밝혀집니다. 표준적인 반응은 적절한 시점에 브라우저를 열고 로그인하여 활성 세션 (active session)의 데이터를 파이프라인의 다음 단계로 전달하는 운영자를 배치하는 것입니다. 수동적인 우회는 아키텍처 (architecture) 문제를 해결하는 것이 아니라 은폐하는 것이며, 이를 파악하는 것은 사고가 발생한 후가 아니라 구현 전에 이루어져야 합니다.

이 분석의 입장은 검증 가능합니다. 만약 NovelAI의 공개 계약 (public contract)이 필수적인 서버 측 단계를 확인해주지 않는다면, 해당 단계는 아키텍처에서 제외하거나 세션 우회 없이 재구성해야 하며, 여기서 수동적인 핸드오프 (handoff)는 임시방편으로서 적절하지 않습니다. 브라우저 탭을 열어둔 사람이 옆에 있다고 해서 계약의 부재가 계약이 되는 것은 아니며, 이렇게 구축된 의존성은 조만간 계정 리스크로 돌아옵니다.

이 글은 "NovelAI API가 있는가"에 대한 리뷰나 우회 방법에 대한 지침이 아니라, 성사되지 못한 요구사항에 대한 사후 분석 (postmortem)입니다. 파이프라인의 모든 필수 단계는 네 가지 필드(공개 인터페이스, 인증 유형, 자동화 규칙, 문서화된 중단 요인)를 기준으로 검토되며, 결과는 세 가지 솔루션 중 하나로 기록됩니다: 확인된 서버 측 단계, 아키텍처에서의 제외, 또는 새로운 독립적 시나리오.

NovelAI가 공개 계약으로서 제공하는 것은 무엇인가?

NovelAI의 공개 영역은 서로 호환되지 않는 여러 계약으로 나뉘어 있으며, 첫 번째 설계 오류는 이를 하나의 API로 간주하는 것입니다. NovelAI 문서(2026-07-18 접속)는 Swagger UI를 통해 문서화된 로그인, 구독, 사용자 데이터 및 스토리를 위한 REST "Primary API"와, 각각의 문서 페이지를 가진 텍스트 및 이미지 생성을 위한 별도의 특화된 생성 API (generation API)를 설명합니다. 각 계약은 고유한 주소와 인증 모델을 가지고 있으며, 이를 혼동하는 것은 아직 아무것도 확인되지 않은 단계를 아키텍처에 포함시키는 것을 의미합니다.

인증 방식 또한 두 가지이며, 이 둘 사이의 차이가 무엇을 자동화할 수 있는지 자체를 결정합니다. 문서에 따르면, 사용자 애플리케이션의 제3자 개발자는 최종 사용자로부터 로그인과 비밀번호를 수집하는 대신, 계정 설정에서 생성된 사용자 본인의 Persistent API Token을 요청해야 합니다. 이 토큰은 한 번만 표시되며 대화창을 닫은 후에는 복구되지 않습니다. 토큰을 재생성하면 이전 토큰은 즉시 무효화되며, 문서상에 조용한 자동 로테이션 (silent automatic rotation) 메커니즘은 존재하지 않으므로, 통합 과정에서 토큰이 재생성될 때마다 저장된 토큰을 수동으로 업데이트해야 합니다.

두 번째 인증 흐름은 아키텍처적으로 독립적입니다. /login 엔드포인트는 로그인과 비밀번호를 access key로 변환하며, 이 key는 30일 동안 유효한 access token을 발급합니다. 이 흐름은 Aedial/novelai-api (2026-07-18 접근 가능)와 같은 독립적인 클라이언트 라이브러리들에 의해 구현되고 문서화되어 있으며, 사용자가 발급한 Persistent API Token과 동일하지 않습니다. 어떤 단계를 지원 가능한 것으로 간주할지 선택할 때 이 차이를 놓쳐서는 안 됩니다.

서버 측 자동화로 흔히 잘못 끌어들이는 세 번째 요소는 내장된 Scripting API v1입니다. 이는 로어북 (Lorebook), 문서, 그리고 이야기(story)를 위한 클라이언트 내부 스크립팅이며, 자체적인 권한 모델 (documentEdit, storyEdit, fileDownload, clipboardWrite 등)을 가지고 있습니다. 문서에 따르면 이는 활성화된 로그인 클라이언트 세션 내에서 실행됩니다. 이 API는 원격으로 호출하거나 외부에서 인증할 수 있는 엔드포인트로 어디에도 설명되어 있지 않습니다. 만약 파이프라인의 필수 단계가

이러한 분석 이후에도 독자에게 별도의, 이미 확인된 모델 단계(예: 호환되는 엔드포인트를 통한 텍스트 생성)가 남아 있다면, 이를 러시아의 호환 모델 카탈로그인 provod.ai에 올릴 수는 있습니다. 하지만 이는 별개의 시나리오일 뿐, NovelAI의 규칙을 연장하거나 우회하는 것이 아닙니다.

수동 핸드오프(handoff)가 공백을 메우지 못하는 이유

수동 핸드오프(handoff)의 논리는 합리적으로 보입니다. API가 필요한 단계를 제공하지 않는다면, 운영자가 인터페이스에서 해당 단계를 수행하고 자동화 시스템이 그 결과를 이어받으면 된다는 식입니다. 하지만 실제로는 공백이 메워지는 것이 아니라 은폐될 뿐입니다. 아키텍처상으로는 여전히 "서버 단계 X가 자동으로 실행됨"이라는 요구사항이 유지되지만, 실제로는 사람이 브라우저에서 활성 세션(session)을 통해 이를 수행하기 때문입니다. 계약(contract)은 여전히 존재하지 않으며, 단지 존재하는 것처럼 보이는 외관만 생겼을 뿐입니다.

이러한 외관은 이후에 큰 비용을 치르게 합니다. 활성 세션에 의존하는 핸드오프(handoff)는 다음과 같은 다음 단계로 이어집니다. "수동으로 작업하지 않기 위해 운영자가 자신의 세션 데이터(session-data)를 스크립트에 한 번 전달하게 하자." 이는 명백한 규칙 위반입니다. NovelAI의 서비스 약관(ToS, 2025년 12월 8일 업데이트)은 계정 자격 증명(credentials)을 공유하거나 제3자에게 계정에 대한 원격 액세스를 제공하는 것을 별도로 금지하고 있으며(항목 8.1 및 5.3.2), "자동화"를 목적으로 프라이빗 세션 쿠키(session-cookie)를 추출하는 행위는 결코 넘어서는 안 될 경계선입니다.

덜 명확하지만 두 번째 대가도 존재합니다. 특정 단계가 '제품 기능 (product function)'으로 간주되는 동안, 그것은 SLA(Service Level Agreement), 일정 추정치, 고객에 대한 약속에 포함됩니다. 사실 이는 지원되는 계약(contract)이 없는 수동 작업이며, 규칙 업데이트부터 이전 토큰을 즉시 무효화하는 토큰 재생성(regeneration)에 이르기까지 NovelAI 측의 어떠한 변경 사항에도 무너질 수 있습니다. 따라서 '수동 핸드오프(handoff)를 통해 확인되지 않은 단계를 유지한다'는 기본 결정은 잘못되었다고 생각합니다. 이는 의사 결정권자들에게 아키텍처 부채(architectural debt)를 보이지 않게 만듭니다.

여기서 정직한 갈림길은 단 하나뿐입니다. 단계에 공개적인 계약(public contract)이 있다면 그것은 서버 기능으로 남아야 하며, 계약이 없다면 해당 단계는 아키텍처에서 제외되거나 그 자체로 검증된 새로운 독립적 시나리오로 재작성되어야 합니다. 활성 세션(live session)에 수동으로 지지대를 대는 세 번째 옵션은 존재하지 않습니다.

실현되지 못한 요구사항의 사후 분석 기록(postmortem-record) 형태

이 방법은 NovelAI 전체를 감사하는 것이 아니라, 하나의 필수 단계를 검증하는 방식으로 구성됩니다. 특정 워크플로우(workflow) 요구사항을 가져와 이를 최소한의 서버 단계로 나누고, 각 단계를 네 가지 필드(공개 인터페이스, 인증 유형, 자동화 규칙, 문서화된 중단 요인)에 따라 검토합니다. 만약 단 하나의 필드라도 공개적인 사실로 채워지지 않는다면, 해당 단계는 확인되지 않은 것입니다.

여기서 출처의 정직성에 대한 주의 사항이 필요합니다. 공식 문서, 서비스 약관(ToS), 또는 독립적인 클라이언트 중 그 어느 것도 Persistent API Token이나 로그인 유도 액세스 토큰(login-derived access token) 대신 인증된 브라우저 쿠키(authenticated browser cookie)를 필요로 하는 작업에 대해 별도의 지원되는 엔드포인트(endpoint)를 설명하지 않습니다. 이로부터 세션(session) 의존적 단계에 대한 계약이 없다는 결론이 도출되지만, 이는 NovelAI가 그러한 계약이 존재하지 않으며 앞으로도 없을 것이라고 긍정적으로 선언한 것이 아니라, 부재로부터 도출된 결론입니다. 개발자는 자신의 구체적인 단계를 동일한 검증 과정을 거치도록 해야 합니다. 이 팩트 팩(fact-pack)은 누군가의 파이프라인에 있는 사적인 요구사항이 아니라, 전체 아키텍처와 규칙을 검증하는 것입니다.

사후 분석 (postmortem) 기록은 다음과 같은 문자열 형식으로 작성하는 것이 편리합니다: "워크플로 요구사항 — 필수적인 서버 측 단계 — 공개 인터페이스/규칙 — 공백 — 종료 또는 재설계 결정". 이러한 문자열 방식은 문구 뒤로 공백을 숨기는 것을 방지합니다. 구체적인 인터페이스와 구체적인 규칙이 나란히 놓이게 되면, "어떻게든 자동화하면 된다"라는 답변은 더 이상 허용될 수 없습니다.

아래는 코드에서 검증된 경로 (confirmed path)와 검증되지 않은 경로 (unconfirmed path)를 분리하는 최소한의 예시입니다. 검증된 경로는 사용자가 직접 발급한 토큰을 사용합니다. 검증되지 않은 경로는 코드 내에 존재하지 않으며, 대신 명시적인 거부 (explicit refusal)가 발생합니다.

import os
import httpx

...

여기서 중요한 것은 코드의 줄 수가 아니라 해결 방식입니다. 검증되지 않은 단계는 "나중에 처리하기 위해 미뤄두는" 것이 아니라, 리뷰와 로그에서 명확히 확인할 수 있는 명시적인 거부로 전환됩니다. 이렇게 함으로써 요구사항이 아키텍처로 몰래 다시 유입되는 것을 방지할 수 있습니다.

규칙과 요금제는 무엇을 말하며, 시스템이 개별적으로 무너지는 지점은 어디인가

규칙은 문자 그대로 읽어야 합니다. 바로 이 규칙들이 "기술적으로 가능한 것"을 "허용되지 않는 것"으로 바꿉니다. NovelAI의 서비스 이용 약관 (ToS, 2025년 12월 8일 업데이트)은 서비스 제한을 준수하지 않거나 과도한 부하를 생성하는 봇넷 (botnet) 및 자동화 시스템 (항목 9.1.6)을 금지하며, 계정 정보를 공유하거나 계정에 대한 원격 액세스를 제공하는 것을 명시적으로 금지합니다. Anlatan의 별도 기업 이용 약관 (Terms of Use, 2025년 3월 6일 업데이트)은 스크래핑 (scraping) 및 웹 페이지 모니터링을 포함하여 사이트 자체에 접속하기 위해 "로봇, 스파이더 또는 기타 자동화된 장치"를 사용하는 것을 금지합니다. 이는 토큰 기반 API와는 별개의 경계입니다. 항목 5.6은 Anlatan이 로그인 데이터를 저장하지 않으며, 해당 데이터의 보안에 대한 책임은 사용자에게 있음을 별도로 명시하고 있습니다.

정직성에 대한 유의 사항: 두 법적 페이지 모두 날짜가 기재되어 있으며(2025년 12월 및 2025년 3월), 2026-07-18 기준으로 유효한 범위 내에 있습니다. 하지만 NovelAI와 Anlatan은 공개적인 변경 로그 (change-log)를 제공하지 않으므로, 구현 전에 조용한 수정(silent edit)이 있었는지 확인하기 위해 다시 읽어보는 것이 좋습니다. 이는 단순히 형식적인 절차가 아닙니다. '자동화가 가능한지 여부'를 결정하는 근거가 바로 이 규칙들에 달려 있으며, 이 규칙들은 코드보다 변경에 더 민감하기 때문입니다.

요금제는 또 다른 제약의 축을 형성합니다. 구독 문서에 따르면 Tablet ($10), Scroll ($15), Opus ($25/월) 등급은 컨텍스트 크기, 이미지 생성을 위한 Anlas 포함 여부, 그리고 Opus 전용 모델을 포함한 모델 접근 권한을 결정합니다. 이때 그 어떤 공식 페이지에서도 API의 수치적인 속도 제한 (rate limit)을 공개하지 않습니다. 서드파티 클라이언트 제작자들은 생성 호출이 구체적인 숫자 없이 NovelAI의 속도 제한 (rate-limit)을 따른다고만 언급할 뿐입니다. 이는 확정된 제한이 아니라 확인되지 않은 세부 사항이므로, 아키텍처 설계 시 특정 수치를 전제로 해서는 안 됩니다.

개별 하위 시스템이 중단되는 지점은 공개 상태 페이지 (status-page)를 통해 확인할 수 있으며, 이는 계약의 분리성을 직접적으로 증명합니다. NovelAI는 Website, Image Generation, Text Generation, Login, Payments, Explore를 별도로 모니터링합니다. 이는 아키텍처 및 운영 측면에서 서로 다른 시스템이며, 개별적으로 장애가 발생할 수 있음을 의미합니다. 예를 들어, 2026년 7월 16일에는 Payments에만 장애가 발생하여 당일 해결되었으며, 해당 시간 동안 Login이나 API의 장애는 없었습니다. 출처상에서 세션 자동화 (session-automation) 자체의 장애에 대한 직접적인 전례는 없습니다. 결제 관련 사고는 이와 무관하며, 단지 하위 시스템들이 서로 독립적이라는 점만을 보여줍니다.

단계가 재작성된 경우, 이를 러시아 통합 사례와 어떻게 비교할 것인가

사후 분석 (postmortem)이 완료되어, 하나의 단계가 NovelAI 세션에 대한 어떠한 종속성도 없는 새로운 독립적 시나리오(예: "호환 가능한 엔드포인트를 통한 텍스트 초안 생성")로 재작성되었다고 가정해 봅시다. 그러면 러시아에서의 접속 문제가 별개의 문제로 떠오르며, 이 지점에서 아키텍처 비교가 유용합니다. NovelAI는 두 개의 토큰과 달러 결제를 사용하는 단일 공급자 (single-vendor) 모델을 가지고 있으며, 러시아 통합업체에게는 여기에 결제 및 접속 장벽이 추가로 발생합니다.