엔드포인트(endpoint)의 부재가 캐릭터를 파괴하는 것은 아닙니다. 그것은 단 한 가지, 즉 타인의 인터페이스를 기반으로 제품을 구축하는 것을 금지할 뿐입니다. 만약 당신이 Character.AI의 연결 문자열을 찾으러 이곳에 왔는데 찾지 못했다면, 기술 수준을 바꾸십시오. 여기서 제품 단위는 캐릭터 자체의 설명이 되며, 인터페이스는 구현의 세부 사항으로 남습니다.

다음으로는 왜 서비스에 개발자들이 찾는 API가 없는지, 공식적인 접근 권한 없이도 캐릭터의 어떤 필드들이 이식 가능한 상태로 남는지, 그리고 이식 가능한 사양(specification)이 어떻게 당신의 계정과 릴리스(release)를 위험에 빠뜨리지 않으면서 우회 통합(bypass integration)을 대체할 수 있는지에 대해 다룹니다.

나는 숨겨진 공식 API가 어디에 존재하는지 확인하는 검증자가 아니라, 독립적인 캐릭터 제품의 아키텍트(architect)로서 이 글을 씁니다. 숨겨진 엔드포인트의 존재 여부는 부차적인 문제입니다. 근본적인 질문은 다릅니다. 비공식적인 접근 없이도 이식 가능한 필드들을 통해 캐릭터의 가치를 기술할 수 있는가? 만약 불가능하다면, 독립적인 구현은 아직 준비되지 않은 것이며, 이는 패배가 아닌 정직한 결론입니다.

Character.AI에는 당신이 찾는 그 API가 없습니다

Character.AI에는 개발자를 위한 공식적인 공개 API가 없습니다. 이는 2026년 7월 18일 기준의 상태이며, 해당 날짜를 기준으로 유효한 것으로 간주해야 합니다. 서비스의 사양은 통지 없이, 그리고 버전 관리된 변경 로그(changelog) 없이 변경됩니다.

커뮤니티에서 소위 "character ai api"라고 부르는 것은 커뮤니티 래퍼(community-wrappers)입니다. 가장 유명한 것은 GitHub의 kramcat/CharacterAI 리포지토리로, 메인테이너(maintainer) 스스로 인정했듯이 "Character AI 개발자들의 참여 없이, 그들의 인지 없이" 만들어졌습니다. 이는 이용 약관에서 명시적으로 금지하는 동작에 의존하는 제3자의 코드입니다.

이 과제에는 많은 이름이 있습니다. 리포지토리와 스레드에서는 c ai api로 존재하며, 포럼의 질문에서는 api character ai로 불립니다. 표현은 바뀌어도 요청은 하나입니다. 캐릭터에 대한 프로그래밍적 접근 권한을 달라는 것입니다. 일차적인 출처의 답변 또한 동일합니다. 승인된 접근 권한은 없으며, 비공식적인 접근은 플랫폼이 명시적으로 금지한 동작에 의존하고 있습니다.

policies.character.ai의 이용 약관 (Terms of Service)은 서비스 데이터를 "자동화된 수단"으로 수집하거나, 비인가 도구를 사용하여 제한(limits), 필터(filters), 유료 기능을 우회하거나, 소스 코드에 접근하기 위해 서비스를 리버스 엔지니어링(reverse-engineer)하는 행위를 직접적으로 금지하고 있습니다. 이는 모든 비공식 통합(unofficial integration)이 의존하고 있는 바로 그 동작들입니다. 해당 조항의 문구들은 인덱싱된 실제 문서의 인용문과 독립적인 재구성을 통해 복원되었으므로, 단어의 정확도는 높으나 글자 그대로 보증된 것은 아닙니다. 하지만 금지 사항의 의미에는 의심의 여지가 없습니다.

비공식 인증을 기반으로 구축할 때 잃게 되는 것들

여기서부터 개발자로서의 도박이 시작됩니다. 우회 경로는 가치가 전이 가능해지기 전에 의존성을 만들어내며, 이 의존성은 두 가지 측면을 동시에 타격합니다.

첫 번째는 자격 증명(credentials)과 계정 자체입니다. DocDecoder의 이용 약관에 대한 독립적인 분석에 따르면, 약관 위반 시 계정 중단 여부는 회사의 재량에 달려 있습니다. 즉, 오늘 작동하는 래퍼(wrapper)가 내일은 당신이 서비스 내에서 만든 모든 것에 대한 접근 권한을 앗아가는 대가로 돌아올 수 있습니다. 비인가 접근에 기반한 제품은 점진적으로 고장 나는 것이 아니라, 당신이 통제할 수 없는 순간에 한꺼번에 무너집니다.

두 번째는 콘텐츠에 대한 권리입니다. 이용 약관에 따라 Character.AI는 사용자의 캐릭터 콘텐츠를 사용, 복제, 수정 및 상업화할 수 있는 비독점적이고 전 세계적이며 영구적이고 서브라이선스(sublicensable)를 부여할 수 있는 라이선스를 취득하며, 여기에는 다른 사용자가 이를 "리믹스(remix)"할 수 있도록 허용하는 것도 포함됩니다. 이 과정에서 제작자는 자신이 직접 입력한 고유한 표현, 즉 이름, 배경 이야기, 성격, 시각적 이미지에 대한 권리를 명목상 유지합니다. "플랫폼에 대한 라이선스 + 원본에 대한 당신의 저작권"이라는 이 구조는 독립적인 분석을 통해 꾸며낸 요약이 아닌 실제 문서의 재구성임이 확인되었습니다.

이 두 가지 사항으로부터 도출되는 결론은 하나이며, 이는 규범적입니다. 인증되지 않은 접근은 비공식적인 인증 (unauthorized authorization)으로 우회할 수 없습니다. 이것은 예의의 문제가 아닙니다. 우회의 대가는 제품의 고장과 자격 증명 (credentials)의 리스크이며, 더욱이 이러한 우회로 보호하려는 자산은 여전히 타인의 인터페이스 안에 갇혀 있게 됩니다.

이식 가능한 캐릭터 필드들

좋은 소식은 플랫폼 자체가 이미 캐릭터의 콘텐츠를 채팅과 분리해 두었다는 점입니다. 제작자 스키마 (creator schema)가 이를 증명합니다.

Character.AI의 문서(«Character Book»)에 따르면, Definition 필드(032,000자)는 성격, 배경 스토리, 말투 (speech patterns), 행동 규칙, 그리고 "이름: 대사" 형식의 구조화된 대화 예시가 존재하는 곳입니다. 별도의 Greeting 필드(0500자, 빠른 생성 시 필수)는 첫 대사를 설정하며, 문서의 표현을 빌리자면 상호작용의 톤, 목소리, 그리고 시나리오를 결정합니다.

이는 생각보다 더 중요합니다. 플랫폼은 자체적인 스키마를 통해 규칙과 대화를 채팅 인터페이스로부터 분리했습니다. 즉, "캐릭터의 가치는 타인의 인터페이스와 분리될 수 없다"라는 논쟁적인 명제는 이미 공식 문서 수준에서 틀린 것이 됩니다. 목소리는 Greeting에 있고, 규칙과 대화 예시는 Definition에 있으며, 그 어느 것도 UI가 아닙니다. 이것은 당신의 자체 스키마에 기술할 수 있는 이식 가능한 텍스트입니다.

여기서부터 캐릭터를 다섯 가지 이식 가능한 필드로 나누는 실무적인 분석이 가능합니다: 목소리, 규칙, 기억, 테스트 대화, 그리고 권한. 처음 두 가지는 Greeting과 Definition이라는 공식 필드와 직접적으로 일치합니다. 기억과 권한은 별개의 문제이며, 우리가 나중에 다시 다룰 것인데, 왜냐하면 바로 이 부분들 때문에 순진한 방식의 이식 시도들이 실패하기 때문입니다.

어떻게 이식 가능한 캐릭터 사양(specification)을 구축할 것인가?

제품 단위(product unit)는 인터페이스가 아니라 사양(specification)이 됩니다. 이를 외부 액세스에 의존하지 않고 당신의 리포지토리(repository)에 존재하는 일반적인 설정(config)처럼 구성합니다.

character:
  voice:          # Greeting에서 추출, 최대 500자: 톤과 첫 번째 대사의 시나리오
  rules:          # Definition에서 추출, 최대 32000자: 규칙과 배경 설정
...

여기의 각 필드는 텍스트이며, 당신이 직접 작성했거나 이전할 권리가 있는 것이기에 이식 가능합니다. 이 스키마(schema)는 타인의 UI를 복제하는 것이 아닙니다. 캐릭터가 어떻게 말하는지, 어떤 규칙에 따라 응답하는지, 무엇을 기억하는지, 그리고 캐릭터가 자기다움을 유지하고 있는지 어떻게 검증하는지와 같은 제품 작업(product work)을 기록합니다.

test_dialogues에 대해 별도로 설명하자면, 이는 회귀 테스트 세트(regression set)입니다. 당신은 '이름: 대사' 형태의 몇 가지 표준적인 대화 교환을 기록합니다. 이는 Definition 문서에서 구조화된 예시(structured examples)라고 부르는 것과 동일합니다. 그리고 모델을 변경하거나 규칙을 수정할 때마다 이를 실행합니다. 만약 캐릭터를 다른 엔진으로 이전한 후 톤(tone)에 맞지 않게 응답하기 시작한다면, 당신은 이를 운영 환경(prod)이 아닌 픽스처(fixture)에서 확인할 수 있습니다. 이것이 바로 대화가 사양 내의 별도 필드로 존재하는 이유입니다. 대화는 캐릭터의 일부인 동시에 캐릭터의 보존성을 확인하는 테스트이기도 합니다.

이 스키마에서 rights는 입력 필터 역할을 합니다. 여기에는 당신이 실제로 생성한 것, 즉 이름, 배경 설정, 성격, 시각적 이미지 등 이용 약관에 따라 창작자에게 권리가 남는 원본 표현물만 포함됩니다. 당신의 것이라고 증명할 수 없는 모든 것은 이식 가능한 사양에 포함되지 않습니다. 이것이 바로 합법적인 이전과 허가되지 않은 복제 사이의 경계입니다.

공식 익스포트(export)는 무엇을 하며, 어떤 점이 부족한가?

승인된 데이터 추출 경로가 존재하며, 여기서부터 시작해야 합니다. Character.AI는 공식적으로 계정 데이터 익스포트(export) 기능을 제공합니다: Settings → Manage Account & Data → Export my data. 결과물은 다운로드 가능한 ZIP/JSON 아카이브 형태로 제공되며, 회사는 이를 데이터 이동성(Data Portability)에 대한 의무(GDPR/CCPA)를 이행하는 것으로 규정합니다.

하지만 이 경로에는 명확한 한계가 있습니다. 2026년의 독립적인 수동 테스트 결과에 따르면, 아카이브에는 user.json, character.json, message.json이 포함되어 있으나, 고정된 메모리(pinned memory)는 "익스포트 시 안정적으로 나타나지 않습니다". 즉, 공식 익스포트조차 모든 제품 필드의 완전한 이동성을 보장하지는 않으며, 메모리가 가장 먼저 누락됩니다. 이는 개인 테스트를 진행한 독립 블로그의 데이터로, 2차 출처입니다. 해당 출처는 관찰 내용을 확인해주지만 1차 검증을 대체할 수는 없으므로, 본인의 계정에서 직접 반복 확인해 보는 것이 좋습니다.

이에 따른 실질적인 작업 순서는 다음과 같습니다:

1. 공식 익스포트를 수행하고 아카이브를 압축 해제합니다.
2. character.json의 내용을 본인 사양(specification)의 voice 및 rules 필드로 옮깁니다.
3. 표준 대화 내용을 test_dialogues로 추출합니다.
4. 익스포트된 메모리를 그대로 믿지 마십시오. 실제로 기억하고 있으며 이동할 권리가 있는 내용을 바탕으로 memory를 수동으로 복구하십시오.
5. rights 필드는 오직 본인의 고유한 원본 표현으로만 채우십시오.

메모리는 이동 준비 상태를 나타내는 가장 정직한 지표입니다. 캐릭터에 대한 핵심 사실들이 플랫폼 내부의 "고정된 메모리"에만 머물러 있고 다른 곳에는 없다면, 가치의 일부가 아직 이동 불가능한 상태임을 의미합니다. 이는 출시 후가 아니라 출시 전에 인정해야 할 부분입니다.

타사 API를 사용하지 않는 캐릭터를 위한 독립적 경로

사양(specification)이 수집되었다면, 이를 실행할 엔진이 필요합니다. 여기서 갈림길은 단 하나입니다. 소비자 서비스에 대한 우회 통합(workaround integration)을 구축할 것인지, 아니면 본인의 이동 가능한 아키텍처에 독립적인 모델 경로(model route)를 부여할 것인지의 선택입니다.

독립적인 경로(Independent route)는 Character.AI API도 아니고 그것을 대체하는 것도 아닙니다. 이는 당신의 사양(specification)을 시스템 프롬프트(system prompt)와 규칙으로 받아들이고, 생성(generation)은 일반적인 거대 모델(large model)로부터 가져오는 별도의 레이어(layer)입니다. 이러한 역할 측면에서 provod.ai (러시아의 OpenRouter)를 타인의 인터페이스에 접속하는 방법이 아니라, 본인만의 아키텍처를 위한 모델 경로(model route)로 간주하는 것이 적절합니다.

캐릭터 제품에 있어 이러한 경로가 갖는 실질적인 가치는, 당신이 이미 다룰 줄 아는 방식과 포맷이 호환된다는 점에 있습니다. provod.ai는 Claude, GPT, Gemini, DeepSeek, Qwen을 하나의 접근 방식으로 통합하여 OpenAI 및 Anthropic SDK와 호환되는 단일 API를 제공합니다. 즉, 키(key)와 base_url만 변경하면 캐릭터의 나머지 코드는 건드릴 필요가 없습니다.

from openai import OpenAI

client = OpenAI(
...

러시아 팀의 경우, 이는 결제 문제까지 해결해 줍니다. 루블화 잔액, 통합 청구서, 법인을 위한 서류를 제공하며, 모델은 provod.ai의 추가 마진 없이 제공업체의 가격대로 제공됩니다. 캐릭터 애플리케이션에 있어 이는 사소한 문제가 아닙니다. 애플리케이션은 지속적이고 안정적인 부하를 가지며, 여기서는 일회성 생성 속도보다 예측 가능한 비용이 더 중요하기 때문입니다. 비공식 래퍼(unofficial wrapper)는 결제 증빙 서류도, 예측 가능한 접근성도 보장하지 않습니다. 그것은 플랫폼이 금지한 행위들에 의존하고 있기 때문입니다.

우회인가 사양인가: 어떻게 선택할 것인가?

이 갈림길을 표로 정리하면 이해하기 쉽습니다. 이 표는 당신의 거절 기준이 될 것입니다. 만약 어떤 솔루션이 비공식 인증(unofficial authorization)을 요구하거나 확인되지 않은 API 경로에 의존한다면, 그것은 거절되어야 합니다.

수용 가능한 대가는 정직합니다: 이식 가능한 사양은 타인의 인터페이스를 그대로 재현하지 않습니다. 픽셀 단위로 동일한 채팅 환경을 얻을 수는 없습니다. 하지만 당신은 캐릭터의 제품적 가치—그의 목소리, 규칙, 기억, 그리고 검증 가능한 행동—를 보존할 수 있으며, 규칙을 위반하지 않고도 내일 당장 폐쇄될 수 있는 도구에 릴리스(release)를 종속시키지 않을 수 있습니다.

이 접근 방식이 해결하지 못하는 것은 무엇인가요?

정직한 제약 사항은 보기 좋은 출력보다 중요하기에, 이를 솔직하게 밝히겠습니다.