MemoryLake
모든 글로 돌아가기
Tutorial2026년 9월 14일·12 분 소요

원하는 항목이 가장 나중에 삽입되도록 SillyTavern World Info 항목 순서를 정하는 방법 (2026년 가이드)

대부분의 사람들은 할 일 목록의 번호를 매기듯 Insertion Order(삽입 순서)를 설정합니다. 중요한 것에는 1을 부여하고, 덜 중요한 것에는 10을 부여하죠. 그러고는 왜 중요한 항목이 계속 무시되는지, 혹은 긴 장면에서 사소한 장소 항목은 잘만 적용되는데 왜 중요한 항목은 완전히 사라져 버리는지 의아해합니다.

하지만 이 번호는 반대로 작동하며, 동시에 두 가지 서로 다른 역할을 수행합니다. SillyTavern 문서에는 이 두 가지가 모두 명시되어 있지만, 거의 아무도 거기까지 읽지 않습니다.

Insertion Order가 우선순위 랭킹이 아닌 이유

공식 문서에 적힌 정의를 그대로 가져와 보겠습니다:

"숫자 값. 여러 항목이 동시에 활성화될 때 항목의 우선순위를 정의합니다. 순서(Order) 번호가 큰 항목일수록 출력에 더 큰 영향을 미치므로 컨텍스트의 끝부분에 가깝게 삽입됩니다. 예를 들어, Order 번호가 100인 항목은 Order 번호가 250인 항목보다 컨텍스트에서 먼저 나타납니다."

숫자가 클수록, 더 나중에 배치되고, 더 큰 영향을 미칩니다. 250번 항목은 100번 항목 뒤에 배치되며, 모델이 텍스트를 작성하려는 위치와 더 가까워집니다. 만약 세계관의 핵심 규칙을 1로 지정하고, 일회성 주점 정보를 400으로 지정했다면, 모델의 주의 집중 영역 바로 옆에 놓이는 것은 그 주점 정보가 됩니다.

이것이 첫 번째 역할입니다. 두 번째 역할은 문서의 완전히 다른 섹션인 'Activation Settings(활성화 설정)'에 나와 있으며, 긴 세션에서 문제를 일으키는 주범입니다:

"예산(Budget)이 소진되면 프롬프트에 키가 존재하더라도 더 이상 항목이 활성화되지 않습니다."
"Constant(상시) 항목이 먼저 삽입됩니다. 그다음으로 순서 번호가 큰 항목들이 삽입됩니다."

즉, 동일한 번호가 생존 여부도 결정합니다. World Info 예산이 바닥나면 활성화가 중단됩니다. 키워드가 일치하고 항목이 활성화될 자격이 있었더라도 아무것도 삽입되지 않는 것입니다. 가장 먼저 들어가는 것은 Constant 항목이고, 그다음은 번호 범위의 높은 쪽부터 차례대로 들어갑니다. 1번으로 설정한 항목은 공간 확보에서도 가장 마지막 순위이고, 모델의 주의를 끄는 데도 가장 마지막 순위가 됩니다.

같은 섹션에 있는 또 다른 문장은 재귀적(recursive) 로어(lore)를 바라보는 관점을 바꾸어 줍니다: "키를 직접 언급하여 삽입된 항목은 다른 항목의 내용에서 언급되어 불러온 항목보다 우선순위가 높습니다." 재귀적으로 불러온 항목은 실제 대화에 의해 트리거된 항목 뒤에 줄을 서게 됩니다.

그리고 소리 없는 실패의 많은 부분을 설명해 주는 디테일이 있습니다. Entry Title(항목 제목)은 "사용자의 편의를 위해 항목에 라벨을 붙이는 텍스트 필드이며, AI나 트리거 로직에서는 활용되지 않는다"고 문서화되어 있습니다. 프로 팁에서는 이를 더 광범위하게 설명합니다: "활성화 키워드, 제목 및 Content 필드에 없는 기타 정보는 컨텍스트에 삽입되지 않으므로, 각 World Info 항목은 포괄적이고 독립적인 설명을 담고 있어야 합니다." 만약 제목에 중요한 의미를 담아두었다면, AI는 그것을 단 한 번도 읽지 않은 것입니다.

이것은 에이전트가 지침 파일을 무시하는 이유에서 설명한 문제의 전형적인 형태입니다. 파일은 존재하고 내용도 올바르지만, 모델에 도달하지 못하는 것입니다.

사람들이 대신 시도하는 방법들

모든 항목의 번호를 1로 재지정하기. 모든 것이 최대로 중요하다면 동점 처리(tie-break)는 임의로 이루어지며, 예산은 여전히 어딘가에서 목록을 잘라버립니다. 이는 우선순위를 정한 것이 아니라, 우선순위를 정할 수 있는 능력을 스스로 없애버린 것입니다.

모든 핵심 항목을 Constant로 만들기. 파란색 원 전략은 항목이 "어떤 키워드도 필요로 하지 않으며, 내용에 관계없이 트리거됨"을 의미합니다. 이 방법은 작동하긴 하지만, 조건부 항목이 고려되기도 전에 전체 예산을 다 써버립니다. Constant 항목이 가장 먼저 삽입된다고 문서에 명시되어 있기 때문입니다. 서너 개 정도는 괜찮은 계획입니다. 하지만 20개는 예산에 여유 공간을 전혀 남겨두지 않는 결과를 초래합니다.

더 짧은 항목을 작성하고 거기서 멈추기. 유용하지만 잘못된 변수를 다루는 것입니다. 길이는 얼마나 많은 항목이 들어갈 수 있는지에 영향을 미치고, 순서는 어떤 항목이 공간을 차지하고 어디에 배치될지에 영향을 미칩니다. 모든 것을 짧게 만드는 접근 방식의 한계는 AI 에이전트에게 얼마나 많은 메모리를 제공해야 하는가에서 다룬 내용과 동일합니다.

문제가 해결될 때까지 예산을 늘리기. 이는 로어 문제를 컨텍스트 문제로 전환할 뿐입니다. World Info 허용량이 커진다는 것은 채팅 기록을 위한 공간이 줄어든다는 것을 의미하며, 이는 긴 컨텍스트가 메모리가 아닌 이유에서 설명한 트레이드오프와 같습니다. 프롬프트의 공간이 늘어난다고 해서 메모리가 늘어나는 것은 아니며, 단지 동일한 선반의 배치를 다르게 한 것뿐입니다.

이 모든 문제를 피하기 위해 항목을 벡터 매칭(vector matching)으로 전환하기. SillyTavern은 이에 따르는 비용을 솔직하게 밝히고 있습니다: "검색 품질은 전적으로 임베딩 모델의 출력에 의존하므로, 어떤 항목이 삽입될지 정확히 예측하는 것은 불가능합니다. 결정론적이고 예측 가능한 결과를 원한다면 키워드 매칭을 고수하십시오." 또한 벡터 매칭은 키워드 확인 단계만 대체할 뿐이며, 예산, 확률, 필터, 포함 그룹(inclusion groups)은 여전히 그대로 적용됩니다. 직접 작성해 둘 수 있었던 결정을 유사도 검색으로 대체하는 이러한 트레이드오프의 더 넓은 관점은 RAG가 메모리가 아닌 이유에서 다루고 있습니다.

해결책: 얼마나 나중에 읽히기를 원하는지에 따라 번호를 매기고, 예산이 실제로 어디까지 도달하는지 확인하기

1단계: 근접성에 따라 대역(band)별로 번호 재지정하기

"순위"를 생각하지 말고, "이 항목이 모델의 다음 문장과 얼마나 가까이 있어야 하는가"를 생각하십시오.

나중에 전체 번호를 다시 매기지 않고도 새 항목을 삽입할 수 있도록 넓은 간격을 두고 3~4개의 대역을 만드세요. 낮은 번호는 일찍 확립되어야 하는 배경 정보(세계의 물리 법칙, 시대, 대략적인 설정)에 할당합니다. 중간 번호는 장소나 세력에 대한 고정된 사실에 할당합니다. 높은 번호는 모델이 글을 쓰기 전에 마지막으로 읽어야 하는 항목들(활성화된 플롯 제약 조건, 캐릭터가 절대 하지 말아야 할 행동에 대한 엄격한 규칙, 현재 장면의 이해관계)에 할당합니다.

정확한 값보다 넓은 간격이 더 중요합니다. 100 단위의 대역을 두면 전체 번호를 재지정하지 않고도 기존의 두 항목 사이에 새 항목을 끼워 넣을 수 있는 여유가 생깁니다.

그런 다음 Lore Insertion Strategy(로어 삽입 전략)를 확인하세요. 번호가 무엇과 비교되는지가 이 전략에 따라 달라지기 때문입니다. 기본값은 Sorted Evenly(균등 정렬)로, SillyTavern은 이를 "출처를 무시하고 모든 항목을 하나의 큰 파일의 일부인 것처럼 Insertion Order에 따라 정렬하는 것"으로 설명합니다. 대안인 Character Lore First(캐릭터 로어 우선)와 Global Lore First(글로벌 로어 우선)는 각 그룹 내에서 순서를 적용하기 전에 출처별로 먼저 그룹화합니다. 캐릭터 로어북과 글로벌 로어북이 서로 다른 번호 체계를 사용하는 경우, Sorted Evenly는 원작자가 의도하지 않은 방식으로 두 로어북을 섞어버릴 수 있습니다.

또한 채팅 바인딩(chat-bound) 및 페르소나 바인딩(persona-bound) 로어는 이 비교 단계보다 완전히 앞서 삽입된다는 점에 유의하세요. 문서화된 순서는 다음과 같습니다: 채팅 로어, 페르소나 로어, 그다음 선택한 전략에 따른 캐릭터 또는 글로벌 로어.

2단계: 위치(Position)와 순서(Order)는 서로 다른 제어 기능이므로 분리하기

Insertion Order는 활성화된 항목들 간의 순서를 결정합니다. Insertion Position은 항목이 프롬프트의 어느 영역에 들어갈지를 결정하며, SillyTavern은 각 위치의 영향력을 설명하고 있습니다.

Before Char Defs(캐릭터 정의 전)는 "대화에 중간 정도의 영향"을 미치는 것으로 문서화되어 있습니다. After Char Defs(캐릭터 정의 후)는 "더 큰 영향"을 미칩니다. 예시 메시지(example-message) 위치는 예시 대화 블록으로 파싱되며 예시 메시지 규칙을 따르므로, 컨텍스트가 채워짐에 따라 밀려날 수 있습니다. Author's Note(작가 노트) 위치에는 문서에서 느낌표로 경고하는 함정이 있습니다: "Author's Note가 비활성화되어 있으면(Insertion Frequency = 0), A/N 위치에 있는 World Info 항목은 무시됩니다!" 항목이 완벽하게 작성되고, 키워드가 올바르게 지정되고, 순서가 높더라도 완전히 다른 기능이 꺼져 있다는 이유로 소리 없이 버려질 수 있습니다.

여기서 가장 정밀한 도구는 depth(깊이) 위치입니다. 채팅의 특정 깊이에 항목을 삽입하며, 깊이 0은 프롬프트의 맨 아래를 의미하고, 시스템(system), 사용자(user), 어시스턴트(assistant) 역할을 선택할 수 있습니다. 이를 통해 항목을 Constant로 만들지 않고도 생성 직전에 엄격한 제약 조건을 배치할 수 있습니다.

완전한 제어를 원한다면, Outlet 위치를 사용하여 자동 주입을 완전히 제거하고 직접 배치한 명명된 토큰(named token) 아래에 콘텐츠를 저장할 수 있습니다. 문서에는 실제 주의 사항이 나열되어 있습니다: 아울렛 이름은 대소문자를 구분하며, 매크로를 호출할 때 이름의 앞뒤 공백은 무시되므로 공백이 포함된 이름은 일치하지 않고, 중첩(nesting)은 지원되지 않으며, 캐릭터 카드 필드는 조기에 파싱되므로 아울렛을 확장할 수 없습니다.

3단계: 설정 패널을 읽지 말고, 무엇이 누락되는지 관찰하여 검증하기

올바르게 작성된 항목과 실제로 삽입된 항목은 서로 다르며, 설정 패널은 전자만 보여줄 뿐입니다.

여러 항목이 동시에 트리거되어야 하는 장면을 실행하고 실제로 무엇이 전달되었는지 확인하세요. 순서가 높은 항목은 나타나고 순서가 낮은 항목은 나타나지 않는다면 예산 한계에 도달한 것이며, 이제 순서 지정이 제 역할을 하고 있음을 알 수 있습니다. 조건부 항목이 전혀 전달되지 않는다면, 먼저 Constant 항목의 개수를 세어보세요.

포함 그룹(inclusion groups)은 사람들을 놀라게 하는 방식으로 작동하므로 의도적으로 테스트해 보세요: "동일한 그룹 라벨을 가진 여러 항목이 활성화된 경우, 프롬프트에는 단 하나만 삽입됩니다." Prioritize Inclusion(포함 우선순위 지정)을 활성화하지 않는 한 Group Weight(그룹 가중치)에 의해 선택되며, 활성화한 경우에는 "가장 높은 'Order' 값을 가진 항목이 선택됩니다." 이것이 순서 번호에 부여할 수 있는 세 번째 역할이며, 이는 선택 사항(opt-in)입니다.

또한 순서를 탓하기 전에 시간 제한 효과가 있는 항목들을 확인하세요. Sticky는 설정된 메시지 수 동안 항목을 활성화 상태로 유지하고 그동안 확률 확인을 무시합니다. cooldown은 설정된 메시지 수 동안 재활성화를 차단합니다. delay는 채팅이 충분히 길어질 때까지 활성화를 방지합니다. 그리고 Scan Depth(스캔 깊이)를 확인하세요. 이것이 0이면 "재귀적으로 호출된 항목과 Author's Note만 평가"되므로, 키워드가 전혀 스캔되지 않는 항목은 아무리 번호를 올바르게 매겨도 소용이 없습니다.

이것은 AI가 기억하는 내용 감사하기에서 설명한 것과 동일한 원칙입니다. 구성을 읽는 것이 아니라 출력을 관찰하여 검증하십시오.

MemoryLake에서 설정하기

이 과정을 통해 두 가지 결과물이 나오지만, 그중 하나만 로어북에 들어갈 자격이 있습니다. 항목 자체는 SillyTavern의 몫이며 아주 잘 수행됩니다. 하지만 왜 이 규칙이 저 규칙보다 우선하는지, 어떤 제약 조건을 절대 누락해서는 안 되는지, 항목이 소리 없이 작동을 멈췄을 때 무엇을 배웠는지와 같은 '의사결정 이유(reasoning)'는 숫자 필드 안에 담길 수 없습니다.

MemoryLake는 특정 프론트엔드에 종속되지 않는 이 두 번째 레이어를 보관합니다. 여러분이 직접 자신의 언어로 작성하면 되며, 도구를 변경하거나, 로어북을 재구축하거나, 다른 사람에게 세계관을 넘겨줄 때도 그대로 읽을 수 있는 상태로 유지됩니다.

1단계: API 키 생성하기

로그인하고 워크스페이스 설정으로 이동하여 API 키를 생성합니다. 이는 어시스턴트가 동일한 레이어를 읽는 데 사용하는 자격 증명이므로, 한 번 생성한 후 글을 쓰는 각 기기에서 접근할 수 있도록 보관하세요.

키 이름과 만료일을 묻는 API 키 생성 대화 상자가 열려 있는 MemoryLake 콘솔 API 키 페이지
키 이름과 만료일을 묻는 API 키 생성 대화 상자가 열려 있는 MemoryLake 콘솔 API 키 페이지

2단계: 첫 번째 메모리 업로드하기

항목 본문과 제목에서 의사결정 이유를 분리하세요. 각 대역이 존재하는 이유, 어떤 항목이 핵심적인 역할을 하는지, 어떤 항목을 강등했고 그 이유는 무엇인지, 시행착오를 통해 발견한 조건은 무엇인지 등을 기록합니다. 로어북은 로어를 보관하고, 이 레이어는 로어에 대한 결정을 보관합니다.

첫 번째 프로젝트와 여기에 연결된 데이터 소스를 보여주는 MemoryLake 기본 워크스페이스의 프로젝트 탭
첫 번째 프로젝트와 여기에 연결된 데이터 소스를 보여주는 MemoryLake 기본 워크스페이스의 프로젝트 탭

3단계: AI 및 에이전트 연결하기

글을 쓸 때 사용하는 도구와 연결하세요. 로어북은 다음 도구로 이동하지 않지만 그 뒤에 담긴 생각은 이동해야 하므로, 동일한 결정 사항이 각 도구에 전달되는 것이 중요합니다.

OpenClaw, Hermes Agent, Claude, ChatGPT, MCP 및 REST API 카드가 있는 MemoryLake 연동 갤러리
OpenClaw, Hermes Agent, Claude, ChatGPT, MCP 및 REST API 카드가 있는 MemoryLake 연동 갤러리

실제 적용 시 달라지는 점

첫 번째 차이점은 긴 장면에서 나타납니다. 가치가 높은 항목이 높은 번호를 차지하게 되면, 예산 초과 시 무작위가 아니라 가장 중요하지 않은 부분부터 잘려 나가기 시작하며, 실제로 도달하는 항목들은 가장 큰 영향력을 미칠 수 있는 위치에 배치됩니다.

두 번째는 소리 없는 실패의 원인을 진단할 수 있게 된다는 점입니다. 항목이 올바르게 작성되었음에도 누락될 수 있는 문서화된 원인은 최소 네 가지(예산 초과, Author's Note 비활성화, 포함 그룹 선택 탈락, 스캔 깊이 부족)가 있으며, 이 목록을 알고 있으면 미스터리였던 문제가 체크리스트로 바뀝니다.

세 번째는 제목이 더 이상 여러분을 속이지 않는다는 점입니다. 제목이 오직 사용자 자신만을 위한 것임을 받아들이면, 모든 항목은 독립적인 본문을 갖게 됩니다. 이는 각 항목이 포괄적이고 독립적인 설명을 가져야 한다는 문서의 요구 사항과도 일치합니다.

네 번째는 이식성(portability)입니다. 말로 표현된 조건으로 구성된 세계관은 플랫폼을 이동해도 살아남지만, 삽입 번호로 표현된 세계관은 그렇지 못합니다. 이것이 바로 Character AI 로어북을 ChatGPT로 마이그레이션하기에서처럼 마이그레이션을 고통스럽게 만드는 간극입니다. OpenAI의 문서화된 개인화 기능에는 이를 수용할 수 있는 순서 제어 기능이 설명되어 있지 않기 때문입니다.

World Info 순서 지정을 위한 모범 사례

순위가 아닌 위치에 따라 번호를 매기세요. 숫자가 클수록 나중에 배치되고, 나중에 배치될수록 더 큰 영향력을 미칩니다. 필요하다면 메모지에 적어두세요.

간격을 두세요. 100 단위의 대역을 사용하면 세계관의 번호를 전부 다시 매기지 않고도 새 항목을 삽입할 수 있습니다.

Constant 항목의 예산을 신중하게 계획하세요. 이들은 가장 먼저 삽입되고 예산을 가장 먼저 소모합니다. 파란색 원 목록은 기억만으로도 이름을 댈 수 있을 정도로 짧게 유지하세요.

엄격한 제약 조건은 맨 위가 아닌 depth(깊이)에 배치하세요. depth 위치는 콘텐츠를 영구적으로 만들지 않으면서도 생성 위치와 가깝게 배치해 줍니다.

Author's Note 위치를 사용하기 전에 먼저 활성화 여부를 확인하세요. Author's Note가 비활성화되어 있으면 해당 위치에 할당된 항목들은 무시됩니다.

모든 항목에 독립적인 본문을 작성하세요. 제목과 키워드는 컨텍스트에 삽입되지 않으므로, 제목이 있어야만 말이 되는 항목은 의미가 없는 항목입니다.

예산이나 전략을 변경한 후에는 항상 다시 테스트하세요. Lore Insertion Strategy를 변경하면 번호가 비교되는 대상이 달라지고, 예산을 변경하면 잘리는 지점이 달라집니다. 두 가지 모두 아무런 경고 없이 조용히 일어납니다.

결론

SillyTavern은 진정으로 강력한 프롬프트 관리 시스템을 제공하며, 직관에 반하는 부분을 포함하여 이를 올바르게 문서화했습니다. Insertion Order는 순위가 아니라 위치이며, 숫자가 클수록 나중에 배치되고 더 중요하게 작용합니다. 또한 동일한 번호가 예산이 부족할 때 어떤 항목이 살아남을지 결정하며, 포함 그룹의 승자를 결정하도록 만들 수도 있습니다.

넓은 간격의 대역을 두어 근접성에 따라 번호를 재지정하고, 나중에 배치되어야 하는 항목에는 position과 depth를 사용하며, 설정 패널을 읽는 대신 실제로 무엇이 전달되는지 관찰하여 검증하세요. 그런 다음 항목 본문에서 의사결정 이유를 분리하세요. 숫자 필드는 여러분의 세계관이 왜 그렇게 작동하는지 기록하기에 적절한 장소가 아니며, 다음에 사용할 도구는 자체적인 제어 기능과 예산을 가질 것이고 이 로어북을 전혀 읽지 못할 것이기 때문입니다.

자주 묻는 질문

Insertion Order 번호가 낮을수록 우선순위가 높다는 뜻인가요?

아닙니다. 문서에 따르면 순서 번호가 큰 항목일수록 컨텍스트의 끝부분에 가깝게 삽입되어 출력에 더 큰 영향을 미치며, 순서가 100인 항목이 250인 항목보다 먼저 나타난다는 예를 제시하고 있습니다.

키워드가 사용되었는데도 왜 제 항목이 나타나지 않았나요?

문서에 기록된 가장 흔한 원인은 예산(budget)입니다. SillyTavern은 예산이 소진되면 프롬프트에 키가 존재하더라도 더 이상 항목이 활성화되지 않는다고 명시하고 있습니다. 다른 원인으로는 Author's Note 위치를 사용할 때 Author's Note가 비활성화되어 있는 경우, 포함 그룹 선택에서 탈락한 경우, cooldown이나 delay가 활성화되어 있는 경우, 그리고 스캔 깊이(scan depth)가 키워드가 포함된 메시지까지 도달하지 못한 경우 등이 있습니다.

예산이 부족할 때 무엇이 먼저 삽입되나요?

Constant(상시) 항목이 먼저 삽입되고, 그다음으로 순서 번호가 큰 항목들이 삽입됩니다. 또한 문서에는 키를 직접 언급하여 트리거된 항목이 다른 항목의 내용에서 재귀적으로 불러온 항목보다 우선순위를 갖는다고 명시되어 있습니다.

항목 제목(Entry Title)이 영향을 미치나요?

아닙니다. Entry Title은 사용자의 편의를 위한 필드로 설명되어 있으며, AI나 트리거 로직에서 활용되지 않습니다. 프로 팁에서도 Content 필드 이외의 것은 컨텍스트에 삽입되지 않는다고 덧붙이고 있습니다.

Insertion Order와 Insertion Position의 차이점은 무엇인가요?

Order는 활성화된 항목들 간의 순서를 제어하고, position은 항목이 프롬프트의 어느 영역에 배치될지를 제어합니다. 문서에서는 각 위치의 상대적 영향력을 설명하면서 Before Char Defs는 중간 정도의 영향을, After Char Defs는 더 큰 영향을 미친다고 명시하고 있으며, 깊이 0이 프롬프트의 맨 아래가 되는 깊이 기반 삽입도 제공합니다.

키워드 대신 벡터 매칭(vector matching)을 사용해야 할까요?

예측 불가능성을 감수할 수 있는 경우에만 사용하십시오. SillyTavern은 검색 품질이 전적으로 임베딩 모델에 의존하며 어떤 항목이 삽입될지 정확히 예측하는 것이 불가능하다고 밝히고 있으며, 결정론적인 결과를 원한다면 키워드 매칭을 권장합니다. 벡터 매칭은 키워드 확인 단계만 대체할 뿐이며, 예산, 필터, 확률, 포함 그룹은 여전히 적용됩니다.