캐릭터 카드 임포트와 이식성: 실제로 따라오는 것들

캐릭터를 앱 사이로 옮기는 것과 내 데이터를 앱에서 빼내는 것은 서로 다른 문제입니다. 대화·메모리·설정은 서비스의 데이터베이스에 있지만, 캐릭터는 보통 파일로 손에 쥘 수 있는 독립된 산출물입니다. 이 차이가 카드를 이해할 가치를 만듭니다. 내가 소유한 카드는 앱이 서비스를 종료하거나, 요금제를 바꾸거나, 더는 쓰고 싶지 않은 무언가로 변해도 남아 있는 유일한 부분이니까요.

파일로 본 캐릭터 카드

커뮤니티 규격에서 카드의 실체는 평범한 PNG(또는 APNG) 이미지에 캐릭터 정의를 tEXt 청크로 써 넣은 것입니다. 이 청크는 이미지 뷰어가 무시하고 카드 지원 앱만 읽는, 이름표가 달린 텍스트 블록입니다. JSON은 UTF-8을 base64로 인코딩해 저장됩니다. 버전 1과 2 카드는 chara라는 청크를, 버전 3 카드는 ccv3라는 별도 청크를 씁니다. 일부 앱은 같은 객체를 순수 .json 파일로도 내보내 주는데, 데이터는 동일하지만 아바타 이미지는 담기지 않습니다.

V3 규격은 두 번째 그릇인 CHARX(확장자 .charx)를 추가했습니다. 루트에 card.json을 두고 그 옆에 assets/ 디렉터리를 둔 ZIP 아카이브로, 카드에서는 embeded:// 형식의 URI로 참조합니다. CHARX가 필요해진 이유는 요즘 카드가 표정 이미지 세트나 배경 아트, 오디오를 함께 담게 되었는데, 그런 것들은 텍스트 청크에 합리적인 크기로 들어가지 않기 때문입니다.

청크가 둘로 나뉜 설계의 실무적 결과는, 같은 카드가 읽는 쪽에 따라 완전해 보이기도 하고 비어 보이기도 한다는 점입니다. chara만 아는 앱에는 V3 전용 파일이 아무 내용도 없는 것처럼 보입니다. 실제로는 V3를 쓰는 도구들이 두 청크를 모두 기록해 하나의 파일이 구·신 클라이언트 양쪽에서 열리도록 하는 경우가 많습니다. 다만 그것은 내보내는 앱의 배려이지 형식이 보장하는 동작은 아닙니다.

세 세대를 항목별로 비교하기

내 카드가 어느 세대인지 알면, 아무것도 시험해 보기 전에 이미 "무엇이 살아남을 수 있는가"를 알 수 있습니다.

규격에서 겉보기보다 중요한 대목이 둘 있습니다. 첫째, V2는 편집 도구가 알 수 없는 키-값 쌍을 파괴해서는 안 된다고 못 박습니다. extensions 객체는 이해하지 못하는 앱조차 보존하는 것이 전제이며, 충돌을 피하려고 키에 앱별 네임스페이스를 붙입니다. 둘째, V3는 V2의 엄밀한 상위집합이므로 하향 경로가 존재합니다. 앱은 V3 카드에서 V2 객체를 되채울 수 있지만, 그 과정에서 데코레이터는 제거해야 합니다. 눈에 보이는 항목은 하나도 빠지지 않았는데 동작만 달라지는 일이 바로 여기서 생깁니다. 각 항목이 무엇을 위한 것인지는 캐릭터 카드 해부학에서 다룹니다.

살아남는 것, 열화되는 것, 애초에 못 가는 것

카드의 내용물을 세 갈래로 나눠 보면 위험이 어디 있는지가 분명해집니다.

이사 도중 사람들을 놀라게 하는 것은 마지막 줄입니다. 캐릭터를 내보내는 일은 관계를 백업하는 일이 아닙니다. 대화 로그와 앱이 나를 위해 쌓아 온 장기 메모리는 별개이고, 대개 얻기 더 어려우며, 쓸 만한 형태로는 아예 못 옮기는 경우도 흔합니다. 이 측면은 컴패니언 앱 데이터 내보내기에서, 메모리가 그렇게 동작하는 이유는 메모리와 연속성에서 다룹니다.

아무도 손대지 않았는데 바뀌는 것이 두 가지 있습니다. V3 카드는 creation_date와 modification_date를 유닉스 타임스탬프로 담고 있는데, 사양은 앱이 내보낼 때 수정 날짜를 새로 기록하도록 정해 두었습니다. 그래서 옮기기만 한 카드도 나중에 보면 편집된 것처럼 보이고, 믿을 만한 출처 정보로 남는 건 원래의 생성 날짜뿐입니다. 직접 만든 카드를 보관하고 있다면 날짜는 내보낸 뒤가 아니라 내보내기 전에 적어 두세요.

임포트가 거부됐다고 해서 늘 카드가 망가진 것은 아닙니다. 사양은 CHARX 파일이 너무 크거나, 손상됐거나, 지원하는 복호화 방법 없이 암호화돼 있거나, 애초에 올바른 zip 파일이 아닐 때 앱이 그 파일을 그대로 거부해도 된다고 허용합니다. 다른 앱에서는 멀쩡히 열리던 파일을 어떤 앱이 거부한다면, 캐릭터를 잃었다고 단정하기 전에 먼저 zip으로 열리는지부터 확인해 보세요.

완벽하게 임포트해도 다르게 굴러가는 이유

이동이 무손실이었고 모든 항목이 온전히 도착했다고 가정해 봅시다. 그래도 캐릭터가 다른 사람처럼 느껴질 수 있습니다. 카드는 여러 입력 중 하나일 뿐이기 때문입니다. 받는 앱은 자기 기본 시스템 프롬프트를 얹고, 다른 모델을 돌리고, 자기 샘플러 설정을 적용하며, 컨텍스트 윈도를 로어북과 진행 중인 대화에 다른 비율로 배분합니다. 한 앱에서 세계관 서술에 1,000토큰을 잡아 두었던 카드가, 다른 앱에서는 그 대부분이 잘려 나갈 수 있습니다.

이 점은 분명히 말해 둘 가치가 있습니다. 흔한 반응이 카드 편집으로 향하고, 그 결과 원래 앱에서는 멀쩡했던 카드를 망가뜨리기 때문입니다. 먼저 설정을 진단하세요. 지루해진 캐릭터 고쳐 쓰기의 비교 방법이 그대로 통합니다. 고정된 오프닝 메시지, 한 번에 한 변수만. 로어북 항목이 발동하지 않는다면, 원인은 텍스트 유실보다 트리거나 토큰 배분 차이일 가능성이 큽니다 — AI 롤플레이를 위한 세계관 구축을 참고하세요.

아예 문이 없는 앱들

지금까지의 이야기는 두 앱 모두 카드 형식을 다룰 줄 안다는 전제 위에 있습니다. 일반 소비자용 컴패니언 앱 상당수는 그렇지 않습니다. 캐릭터는 데이터베이스의 행으로 존재하고, 편집기에는 짧은 설명 칸 하나만 있으며, 내보내기 버튼은 없습니다. 데이터가 복잡해서가 아니라 이식성이 제품 목표가 아니기 때문입니다. 이걸 공정하게 평가하는 게 중요합니다. 닫힌 앱이 자동으로 더 나쁜 앱은 아니고, 애초에 옮길 생각이 없는 사람도 많습니다. 다만 그 안에서 몇 주에 걸쳐 인격을 다듬을 때 무엇을 감수하는지는 달라집니다.

문이 있는지는 필요해진 뒤가 아니라 미리 확인하세요. 카드 내보내기를 지원하는 앱이라면 보통 설정이나 도움말에 그 사실이 적혀 있고, 내보낼 때 형식 이름을 알려 줍니다. "내보내기"라는 말이 어디에도 없다면 캐릭터는 회수할 수 없다고 보고, 직접 쓴 텍스트의 사본을 따로 보관하세요. 설명·성격·인사말을 담은 평범한 문서 하나면 투박하지만 효과적인 백업이 되고, 어떤 형식 변경도 이를 망가뜨리지 못합니다. 각 앱이 애초에 얼마나 깊은 편집을 허용하는지는 앱 랭킹에서 살펴보는 항목 중 하나이며, MusePick 리뷰는 롤플레이 중심 앱을 이 관점에서 다룹니다.

이동 전 체크리스트

1. 제공되는 것 중 가장 정보량이 많은 형식으로 내보내기. PNG와 JSON이 모두 있으면 둘 다 받으세요. JSON은 살펴보고 고치기 쉽고, PNG는 아바타를 함께 옮겨 줍니다.
2. 세대를 기록해 두기. 내보내기 창은 보통 V2·V3·CHARX 중 하나를 알려 줍니다. 표시가 없다면 V2로 가정하는 것이 안전합니다.
3. 원본 파일은 손대지 말기. 받는 앱에서 다시 내보내면 V3 카드가 조용히 V2로 강등될 수 있고, 강등된 사본에서 데코레이터를 되살릴 수는 없습니다.
4. 임포트한 뒤 편집기를 항목별로 읽기. 원본 카드와 대조하세요. 설명, 성격, 예시 대화, 인사말, 로어북 항목 수. 빠진 것은 대화창이 아니라 여기서 드러납니다.
5. 고정된 오프닝 메시지 세 개를 돌려 보기. 가벼운 것 하나, 감정 부하가 큰 것 하나, 캐릭터가 먼저 움직이길 요구하는 것 하나. 두 앱에서 같은 세 개를 써야 차이에 의미가 생깁니다.
6. 형식이 옮기지 못한 것을 다시 만들기. 아바타와 표정 이미지, 인사말 변형, 도착하지 못한 로어북 항목. 무엇이 실제로 빠졌는지 알고 난 다음, 맨 마지막에 할 일입니다.

이 순서대로 하면 이사는 한 시간이 채 걸리지 않고, 오래 쓸 수 있는 사실 하나를 알려 줍니다. 내 캐릭터의 어느 부분이 파일 안에 있었고 어느 부분이 앱 안에 있었는가 하는 구분입니다. 이 구분이야말로 이식성의 실질이며, 필요해지기 전에 알아 둘 가치가 있습니다. 훗날의 이동을 염두에 두고 처음부터 캐릭터를 만든다면, 첫 롤플레이 캐릭터 만들기와 AI 캐릭터 제작기의 작동 원리가 앱이 아니라 카드에 담아야 할 것들을 다룹니다.

자주 묻는 질문