캐릭터를 게시하기 전에 "이 캐릭터가 흥미로운가"가 아니라 "이 캐릭터가 향후 어떤 컨텍스트 (Context)를 전달하는가"를 자문해 보아야 합니다. 이는 수사적인 표현이 아닙니다. Chub AI의 캐릭터 카드는 기술적으로 전송 가능한 파일이며, 매력적인 이미지와 함께 당신이 입력한 모든 것—모델 지침 (Model Instructions), 숨겨진 메모, 키워드 기반 지식 베이스—이 함께 이동합니다.

사람들은 검색할 때 얼굴, 성격, 시나리오로 구성된 이미지 갤러리를 기대하며 "chub ai characters"를 검색합니다. 실제로 갤러리는 존재합니다. 하지만 모든 얼굴 아래에는 데이터 구조가 자리 잡고 있으며, 그 가시성 (Visibility)은 당신이 캐릭터를 생성하는 순간 결정되는데, 대개 이를 간과하곤 합니다. 일단 결정된 후에는 되돌리기가 늦을 수 있습니다. 파일은 이미 다운로드되었고, 다른 클라이언트로 임포트 (Import)되었거나, 토론 게시판에 게시되었을 수 있기 때문입니다.

아래에서 저는 캐릭터를 네 가지 레이어(Layer), 즉 아티팩트 (Artifact), 데이터 (Data), 가시성 (Visibility), 리스크 (Risk)로 나누어 설명하겠습니다. 핵심은 컨텍스트가 떠나버린 후가 아니라, 임포트 및 게시 결정을 내리기 전에 판단을 내리는 것입니다. 근거는 Chub의 공식 규칙과 2025년 가을의 한 규제 사건이며, 저의 해석이 추가되는 부분은 별도로 표시하겠습니다.

캐릭터 카드는 이미지에 보이는 것보다 더 많은 것을 담고 있습니다

생성 시 Character Info 섹션을 열어보세요. Description, Initial Message, Scenario, Example Dialogs와 같은 외형적 필드들이 보일 것입니다. 이것이 흔히 말하는 "캐릭터"로 읽히는 부분입니다. 하지만 Chub의 문서에 따르면 그 옆에는 System Prompt, Post History Instructions, Character's Note, 그리고 키워드에 따라 조각들을 삽입하는 내장형 Character Book(로어북, Lorebook)과 같은 제어 필드들이 함께 놓여 있습니다. Chub의 가이드라인에 따르면, 이 모든 필드는 캐릭터를 게시하거나 내보낼 (Export) 때 캐릭터와 함께 배포됩니다 (docs.chub.ai, 2026-07-18 접속).

이것은 인지 방식의 핵심적인 변화입니다. 이미지는 쇼윈도입니다. 제어 필드들은 사용자가 채팅 중에 보통 보지는 못하지만 파일에 포함되어 함께 이동하는 내용물입니다. 만약 당신이 System Prompt에 작동 가능한 컨텍스트, 내부 용어, "현실감을 위해" 실제 대화의 일부를 작성했다면, 그것들은 아티팩트의 일부가 됩니다.

카드 포맷은 파일 수준에서 이를 확인해 줍니다. 외부 도구인 RPGGO의 문서에 따르면, 캐릭터 카드(character card)는 플랫폼 간(예: SillyTavern 또는 RPGGO (developer.rpggo.ai, 2026-07-18 접속)) 이동이 가능한 JSON 객체이거나 EXIF 메타데이터에 JSON이 내장된 PNG 파일입니다 (developer.rpggo.ai, 2026-07-18 접속). 즉, 다운로드한 캐릭터는 이미지가 아니라 데이터 파일입니다. 한 가지 덧붙이자면, Chub의 어떤 공식 문서도 캐릭터를 "컨텍스트 컨테이너(context container)"라고 부르지는 않습니다. 이는 제가 파일 형식을 바탕으로 기술한 방식이며, 해당 플랫폼은 이러한 종류의 진술에 대해 보증을 제공하지 않습니다.

따라서 간단한 규칙이 있습니다: 게시하기 전에 이미지가 아니라 제어 필드(control fields)를 확인하십시오. 바로 이 필드들이 컨텍스트를 가장 멀리까지 전달합니다.

파일 형태의 실제 내용물은 다음과 같이 생겼습니다. 이미지와 제어 필드가 나란히 놓여 있습니다:

{
  "name": "아브로라",
  "description": "사용자가 보는 이미지",
...

system_prompt, post_history_instructions, 그리고 character_book 필드들이 바로 사용자가 채팅 중에는 볼 수 없지만 파일이 전달하는 요소들입니다.

어떤 가시성 설정이 컨텍스트를 볼 수 있는 대상을 결정하는가?

여기서 모든 것은 세 가지 버튼에 달려 있습니다. Chub의 가이드에 따르면, 생성 시 Public, Private, 또는 Unlisted 중 하나의 가시성 수준을 선택해야 하며, SFW/NSFW 등급을 지정해야 합니다. 캐릭터가 검색 결과에 나타나려면 최소 세 개의 태그가 필요합니다 (docs.chub.ai, 2026-07-18 접속). 이러한 가시성 수준은 SFW/NSFW 표시 요구 사항 및 미성년자와 동의 없는 실존 인물이 포함된 콘텐츠에 대한 제한 사항과 함께 공식 이용 약관(Terms of Use)에 명시되어 있습니다 (chub.ai/tos).

Chub은 이러한 단계들을 동등한 선택지로 설명합니다. 저는 이를 하나의 척도(scale)로 보는 것이 더 편합니다. 즉, 파일의 컨텍스트(context)가 도달하는 범위가 얼마나 넓은가에 대한 척도입니다. 좁은 쪽 끝에는 Private(비공개)이 있고, 넓은 쪽 끝에는 태그가 붙어 인덱싱(indexing)되고 다운로드까지 가능한 공개 캐릭터가 있습니다. 규칙에 이러한 척도가 명시되어 있는 것은 아니며, 이는 인용이 아닌 저만의 사고 방식입니다.

플랫폼 자체는 개인 데이터에 대해 상당히 명확하게 언급하고 있습니다. Chub의 공식 개인정보 보호정책(Privacy Policy)에 따르면, 비공개 캐릭터와 비공개 채팅은 서비스 작동을 위해 프로그램 방식으로 처리되며, 사용자의 서면 동의 없이 수동으로 검토되지 않고, AI 모델 학습에 사용되지 않으며, 암호화되지 않은 상태로 제3자에게 전달되지 않습니다 (chub.ai/privacy). 출처에 대한 중요한 주의 사항: TOS(이용 약관) 및 Privacy(개인정보 보호정책) 페이지는 클라이언트 측에서 렌더링되며, 제가 제시하는 정확한 문구는 일치하는 스니펫(snippet)들을 재구성한 요약일 뿐, 문자 그대로의 법적 인용문이 아닙니다. 실제 게시 전에는 반드시 실제 규칙 전문을 확인하십시오.

별도의 위험 영역은 메모리(memory)와 대화 내보내기(export)입니다. 가이드에 따르면 Chat Memory(채팅 메모리) 기능은 컨텍스트(context) 범위를 벗어난 메시지들을 요약하여 모델에 추가적인 컨텍스트로 전달합니다. 채팅은 JSONL (SillyTavern), PNG 또는 Text 형식으로 내보낼 수 있으며, 개별 채팅은 캐릭터의 공개 토론 섹션에 포함되는 링크를 통해 "익명화된 버전"으로 게시할 수 있습니다 (docs.chub.ai, 2026-07-18 접속). 즉, 게시(publication)는 캐릭터뿐만 아니라 구체적인 대화와도 관련이 있습니다.

다음은 증명된 사실이 아닌 가설입니다: 설정이 더 폐쇄적일수록 전달되는 컨텍스트(context)가 줄어들 가능성이 높습니다. 합리적인 추론이지만, 실제 데이터 확산 범위를 측정하지 않았으며 Chub 또한 그러한 측정치를 공개하지 않습니다. 이는 검증되지 않은 가정으로 간주하십시오.

외부 모델 연결은 위험 범위를 변화시킵니다

Chub은 자체 모델뿐만 아니라 다른 모델들도 사용할 수 있습니다. 문서에 따르면, 이 서비스는 OpenAI, Anthropic, Google, OpenRouter, NovelAI와 같은 외부 유료 API 연결을 공식적으로 지원하며, 월 20달러에 자체 모델인 Mars를 제공합니다 (docs.chub.ai, 2026-07-18 접속). 동일한 문서 섹션에서는 다음과 같이 직접적으로 경고합니다: 제3자 리버스 프록시(Reverse Proxy)는 권한이 없는 제3자에 의해 생성되며, 이들은 사용자의 데이터와 IP 주소에 접근할 수 있으므로 프록시 대신 공식 API 키를 사용할 것을 권장합니다.

이 경고를 문자 그대로 받아들이십시오. 타인의 리버스 프록시를 통해 대화를 주고받을 때, 당신은 통제할 수 없는 대상에게 대화 내용과 IP 주소를 자발적으로 노출하게 됩니다. 이는 캐릭터의 가시성(Visibility) 문제 위에 더해지는 별도의 위험 계층입니다. 모델이 의심스러운 노드를 통해 응답한다면, 비공개(Private) 캐릭터라 할지라도 컨텍스트(Context)를 통해 정보가 유출될 수 있습니다.

여기서 러시아 사용자들에게는 실질적인 질문이 생깁니다. 프록시를 사용하지 않으면서 해외 카드로 결제하지 않고도 사용할 수 있는 합법적이고 호환 가능한 엔드포인트(Endpoint)를 어디서 구할 수 있을까요? 위 목록에 이미 개별 제공업체가 아닌 애그리게이터(Aggregator)인 OpenRouter가 포함되어 있다는 점은 시사하는 바가 큽니다. 러시아 시장에서는 provod.ai - OpenRouter의 러시아판 버전이 동일한 역할을 수행합니다. 이는 OpenAI 프로토콜과 호환되는 플랫폼의 모델 카탈로그를 하나의 API로 제공합니다. 이 프로토콜을 지원하는 클라이언트라면 base_url과 키만 변경하면 충분합니다.

중요한 경계선이 있습니다: 이것은 별도의 호환 가능한 API 카탈로그일 뿐, Chub의 정책이 아니며 특정 통합 기능이 반드시 사용 가능하다는 보장도 아닙니다. Chub은 공식 키 사용을 권장합니다. 호환 가능한 엔드포인트를 가진 애그리게이터는 그러한 키를 얻는 방법이지, 규칙을 우회하는 방법이 아닙니다.

기술적으로 호환 가능한 엔드포인트를 연결하는 것은 다음 두 줄을 교체하는 것과 같습니다:

from openai import OpenAI

client = OpenAI(
...

이것은 형태에 대한 예시일 뿐, "여기에 대화 내용을 부으세요"라는 지침이 아닙니다. 실제 대화를 공식 키(Official Key), 애그리게이터(Aggregator) 또는 프록시(Proxy)와 같은 외부 엔드포인트(Endpoint)로 보내기 전에, 기술적인 문제를 다루기 앞서 컨텍스트(Context)의 가시성 및 민감도 문제를 먼저 해결하십시오.

규제 기관, 2025년 가을 Chub의 보안 취약점 발견

여기서 중요한 점은 범위를 즉시 좁히는 것입니다. 이는 직접적인 데이터 프라이버시(Data Privacy)가 아니라 보안 관리(Security Management)에 관한 이야기입니다. 2025년 10월 16일, 호주의 규제 기관인 eSafety Commissioner는 Chub AI Inc.에 기본 온라인 안전 기대치(Basic Online Safety Expectations)에 따른 공식 투명성 통지서를 발송하였으며, 2025년 7월 1일부터 9월 30일까지의 아동 보호 조치에 대한 보고서를 요청했습니다 (Digital Policy Alert, 2026-07-18 참조).

2025년 10월 통지서 검토 결과, eSafety Commissioner는 Chub AI에 신뢰 및 보안(Trust and Safety) 전담 인력이 없으며, 당시 이용 약관(Terms of Use)에 자해/자살 및 포르노그래피 콘텐츠에 대한 직접적인 금지 조항이 없음을 확인했습니다. 이후 Chub AI는 호주에서의 서비스 지오블로킹(Geo-blocking)을 결정했습니다 (esafety.gov.au, 2026-07-18 참조).

이 내용을 읽을 때는 주의가 필요하며, 그렇지 않으면 잘못된 결론에 도달할 수 있습니다. 발견된 사항들은 2025년 7월~9월 보고 기간과 "통지 발송 시점"의 Chub 상태를 설명합니다. 규정이나 인력은 변경되었을 수 있습니다. 호주에 대한 지오블로킹은 가용성에 관한 비즈니스 결정이지, 서비스가 다른 지역에서 데이터를 처리하는 방식에 대한 증거가 아닙니다. 또한 연령 확인 방법이 자기 선언 방식인지 또는 문서 확인 방식인지에 대해서는 제가 보유한 공식 출처에서 확인되지 않았습니다. 저는 규제 기관의 발견을 특정 메커니즘에 대한 진술이 아닌, 관리상의 공백을 나타내는 지표로만 사용합니다.

캐릭터 제작자로서 이것이 왜 필요한가요? Trust and Safety (신뢰 및 안전)의 규제 공백은 간접적인 신호입니다. 플랫폼이 당신의 캐릭터에 포함된 민감한 문맥(Context)을 대신 필터링해 줄 것이라고 기대하지 마세요. 데이터의 경계는 제작 단계에서 당신이 책임져야 할 영역이지, 나중에 정리될 문제가 아닙니다.

임포트(Import) 또는 게시(Publish) 전 데이터 맵을 작성하는 방법

모든 것을 실행 가능한 순서로 정리해 보겠습니다. 핵심 아이디어는 하나입니다. 먼저 '아티팩트-데이터-가시성-리스크(artifact-data-visibility-risk)' 맵을 작성한 다음, 게시 버튼을 누르는 것입니다. 커뮤니티에서는 캐릭터를 전이 가능한 문맥(Context)이 아닌 창작물로 간주하는 경향이 있으며, 어느 정도까지는 이 관점이 맞습니다. 하지만 파일 형식은 이러한 관점과 상충합니다. 제어 필드(Controlling fields)가 캐릭터 이미지와 함께 이동하기 때문에, 데이터 경계에 대한 결정이 우선되어야 합니다.

Publish(게시) 또는 Import(임포트)를 누르기 전, 단계별 절차는 다음과 같습니다:

1. 제어 필드인 System Prompt (시스템 프롬프트), Post History Instructions (이력 후속 지침), Character's Note (캐릭터 노트), Character Book (캐릭터 북)을 열고, 그 안에서 실제 문맥(Context)이 있는지 확인하세요. 즉, 업무 용어, 실제 대화의 일부, 이름 등이 포함되어 있는지 찾아보십시오. 만약 그것이 포함되어 있다면, 그것은 이미지가 아니라 데이터입니다.
2. 가시성(Visibility)을 의식적으로 결정하세요. 인덱싱 가능한 파일로 제공할 준비가 된 것만 Public (공개)으로 설정하고, 링크를 통해서만 접근할 수 있는 것은 Unlisted (미등록)로, 플랫폼의 정책에 따라 좁은 범위의 인원에게만 허용하는 것은 Private (비공개)로 설정하십시오.
3. 대화의 운명을 별도로 결정하세요. Chat Memory (채팅 메모리)는 요약본을 수집하며, '익명화된' 채팅 게시물은 공개 토론으로 넘어갑니다. JSONL/PNG/Text로 내보내는 것 또한 데이터를 외부로 유출하는 행위입니다.
4. 외부 모델을 사용할 때는 데이터와 IP를 볼 수 있는 제3자의 리버스 프록시(Reverse Proxy) 대신, 공식 키(Official Key) 또는 호환 가능한 엔드포인트(Endpoint)를 선택하세요.
5. 타인의 프로필을 임포트할 때는 반드시 가시성을 이해하고 민감한 문맥(Context)을 정리한 후에 진행하십시오.

동일한 논리를 표 형태로 정리하면 다음과 같습니다: 설정 항목, 문서에 명시된 내용, 문맥(Context)을 받는 범위(이것은 저의 프레임워크입니다), 그리고 이에 대한 조치 사항입니다.