LightVela 문서

요약

모델을 전환해도 Hermes Agent가 사용자를 잊지 않는 이유는 모델, 페르소나, 메모리가 서로 분리된 세 레이어에 저장되기 때문입니다. 모델은 추론과 생성을 담당하고, SOUL.md는 역할과 표현의 경계를 정의하며, USER.md와 MEMORY.md(memories/ 포함)는 사용자 프로필과 세션 간 정보를 보관합니다. LightVela에서 모델을 전환하면 이후 응답에 사용되는 엔진만 바뀝니다. 메모리, 클라우드 스토리지 파일, 스킬, 자동 작업 설정은 지워지지 않고 채팅 기록도 이동하지 않습니다. 전환 후 실제로 "다르게 느껴질" 수는 있지만, 이는 데이터 손실이 아니라 새 모델의 지시 이행, 컨텍스트 압축, 답변 길이, 도구 호출 성향이 다르기 때문입니다. 두 경우를 구분하는 방법은 하나입니다. 에이전트가 분명히 알고 있어야 할 사실을 물어보세요. 답할 수 있다면 스타일 차이이고, 답할 수 없다면 메모리 레이어를 점검해야 합니다.

---

말투가 달라졌다면 메모리도 사라진 걸까요?

모델을 전환하면 표현과 답변 길이가 달라지고, 이전 대화에서 언급하던 배경을 더 이상 먼저 꺼내지 않는 경우가 많습니다.

거의 모든 사람의 첫 번째 반응은 "나를 잊어버렸어요"입니다. 그러한 반응은 자연스러운 것입니다. 일상 생활에서 누군가가 공유된 기록을 참조하는 것을 중단하면 우리는 그들이 잊어버린 것으로 의심합니다.

그러나 에이전트 시스템 내부에서는 이 비유가 오해를 불러일으킵니다. '언급하지 않는다'와 '모른다'는 전혀 다른 것입니다. 첫 번째는 표현 전략입니다. 두 번째는 데이터가 누락되었습니다. 진단, 수정 비용, 심각도가 다르며 이를 하나로 통합한다는 것은 존재하지 않는 문제를 해결하는 데 시간을 소비한다는 것을 의미합니다.

이 기사에서는 두 가지를 명확하게 구분하고 실행 가능한 테스트를 제공합니다.

---

1. 다섯 개의 레이어: 바뀌는 것과 유지되는 것

먼저 모델을 전환할 때 실제로 바뀌는 레이어와 그대로 유지되는 레이어를 구분해야 합니다.

핵심 포인트: 마지막 4개 레이어는 모두 모델 외부에 있습니다. 모델이 교체되면 해당 파일과 디렉터리는 원래 위치에 그대로 유지되고 새로운 모델은 이를 읽고 적용합니다.

이것이 문서에서 모델을 전환해도 에이전트의 메모리, 클라우드 스토리지 파일, 스킬 또는 자동 작업 설정이 지워지지 않는다고 명백하게 기술할 수 있는 이유입니다. 이는 누군가 추가한 보호 기능이 아니라 계층화된 저장소의 자연스러운 결과입니다. 전체 분업에 대해서는 "Hermes Agent의 두뇌를 교체할 수 있습니까? 모델 레이어 대 에이전트 레이어"를 참조하세요.

---

2. 그럼 왜 정말 다르게 느껴지는 걸까요?

데이터가 그대로인데도 사용 경험이 달라지는 이유는 무엇일까요? 같은 컨텍스트라도 모델마다 해석하고 표현하는 방식이 다르기 때문입니다.

모델은 다음과 같은 실제 치수에 따라 다릅니다.

2.1 지시 따르기

SOUL.md의 제약은 그대로지만 새 모델이 이를 더 느슨하거나 엄격하게 적용할 수 있습니다. "결론을 먼저 제시하라"고 적어도 어떤 모델은 매번 그대로 따르고, 다른 모델은 복잡한 질문에서 근거를 먼저 쌓은 뒤 결론을 제시할 수 있습니다.

표시됨: 성격이 변경되었습니다. 사실: 규칙은 변경되지 않았습니다. 준수가 변경되었습니다.

2.2 컨텍스트 압축

답변을 작성할 때는 기존 배경을 얼마나 다시 언급할지 결정해야 하며, 모델마다 판단이 다릅니다. 어떤 모델은 "이전에 X를 언급했습니다"라고 적극적으로 상기시키고, 다른 모델은 사용자가 이미 안다고 보고 바로 요점으로 들어갑니다.

표시됨: 우리가 논의한 내용을 잊어버렸습니다. 실제로: 회상이 작동하고 있지만 단순히 다시 언급하지는 않았습니다. 기억상실증으로 오인되는 경우가 가장 많다.

2.3 답변 길이 선호

동일한 질문에 대해 답변 길이는 모델 간에 몇 배나 다를 수 있습니다.

표시됨: 더 멍청해졌거나 장황해졌습니다. 사실: USER.md의 기본 설정이나 명시적 요청을 통해 조정 가능한 다른 기본 자세한 정보입니다.

2.4 도구 호출 경향

일부 모델은 답하기 전에 파일을 읽거나 검색하는 경향이 강하고, 다른 모델은 주어진 컨텍스트에 더 많이 의존합니다.

표시됨: 도구 사용이 중단되었습니다. 사실: 호출을 위한 임계값이 다릅니다.

2.5 언어 스타일

문장 표현, 사용자를 부르는 방식, 말투가 모두 달라질 수 있습니다.

다음으로 나타남: 다른 사람이 되었습니다. 사실: 가장 표면적이며 가장 무해한 범주입니다.

함께 보면 이 5가지 특성은 하나의 특성을 공유합니다. 모두 알고 있는 내용이 아니라 표현 방식에 관한 것입니다. 이것이 바로 아래 테스트의 기초입니다.

---

3. 알려진 사실 하나로 원인을 구분하기

느낌만으로 판단하지 말고, 답이 이미 정해진 사실 질문으로 확인하세요.

방법: 명시적으로 말했고 이미 장기 메모리에 있어야 하는 확실한 사실(프로젝트 이름, 언어 선호도, 명시적 제약 조건)을 생각해 보세요. 전환 후 정확히 그것에 대해 물어보십시오.

해석:

이 테스트는 표현식 변수를 제거하기 때문에 작동합니다. 즉, 확실한 답이 있는 사실에 대해 질문하므로 스타일이 어떻게 변경되든 정확성은 객관적입니다.

---

4. 모델 전환 후 전체 점검표

다음 점검 순서는 대부분의 모델 전환 상황에 적용할 수 있습니다.

1. 스위치가 적용되었는지 확인 - 선택한 모델이 콘솔에 표시되어야 합니다. 이는 "전환했다고 생각했지만 전환하지 않았습니다"를 배제합니다.
2. 간단한 테스트 메시지 보내기 — 새로운 모델 응답이 정상적으로 나오는지 확인하세요. 전환 후 첫 번째 응답이 약간 느린 경우 다른 항목을 변경하기 전에 한 번 기다렸다가 다시 시도하세요.
3. 알려진 사실 테스트 실행 — 섹션 3을 사용하여 메모리 레이어를 확인합니다.
4. 페르소나가 여전히 기대에 부합하는지 확인하세요 — 톤과 한계가 SOUL.md 내에 유지되는지 확인하세요. 드리프트가 분명하다면 키 제약 조건을 더 구체적으로 만드세요.
5. 스킬이 여전히 발동하는지 즉시 확인 — 일치하는 상황에서 스킬을 시도하고 스킬 로드를 확인합니다.
6. 자동 작업 출력 품질 검토 — 모델 필드를 동기화하는 것이 아니라 출력 품질을 검토하고 있다는 점에 유의하세요. 자동 작업에는 "고정된 모델" 설정이 없습니다.
7. 클라우드 저장소 파일이 손상되지 않았는지 확인 — 전환 시 해당 파일이 다시 작성되지 않습니다. 이것은 단지 검증일 뿐입니다.

널리 유포된 주장에 따르면 전환 후 각 자동 작업의 모델을 다시 동기화해야 한다는 주장이 있기 때문에 6단계를 강조할 가치가 있습니다. 실제로 자동 작업은 이름, 일정(고정 평일, 고정 간격 또는 일회성), 작업 지침, 활성 시간 창 및 알림 채널로 구성되며 모델 필드는 없습니다. 따라서 올바른 조치는 한 번의 실제 실행을 기다리고 출력 품질이 여전히 기대치를 충족하는지 확인하는 것입니다.

---

5. 전환 후 실제로 동작하지 않는 경우

답변 스타일이 달라진 것이 아니라 실제로 응답하지 않는다면 별개의 문제입니다. 다음 순서로 원인을 확인하세요.

1. 모델 구성이 완료되었는지 확인 — 모델 구성으로 돌아가 대상 모델, 자격 증명 및 공급자 설정을 확인합니다.
2. 계정 가용성 및 할당량 확인 — 귀하의 계정에서 모델을 사용할 수 있고 공급자 측 할당량 또는 잔고가 충분한지 확인하세요.
3. 작동하는 것으로 알려진 모델로 테스트 — 이는 "이 모델에 문제가 있습니다"와 "전체 경로에 문제가 있습니다"를 구분합니다.
4. 진단에서 최근 로그를 확인하세요 — 여전히 응답할 수 없는 경우 로그를 사용하여 문제가 모델, 구성 또는 작업에 있는지 확인한 다음 모델 구성을 재설정할지 여부를 결정합니다.

한 가지 일반 원칙은 기억할 가치가 있습니다. 한 번에 하나의 요소를 변경하고 각 변경 후에 테스트하십시오. 모델을 전환하고, 페르소나를 편집하고, 스킬을 한 번에 추가하면 실패 원인을 지정할 수 없습니다. 문제 해결 중에 이 원칙은 모든 것을 한 번에 구성한다는 느낌보다 훨씬 더 가치가 있습니다.

---

6. 전환이 유용한 경우와 그렇지 않은 경우

전환에는 비용이 듭니다. 다른 표현 스타일에 다시 적응하고 프롬프트를 다시 조정해야 할 수도 있습니다. 따라서 동기를 명확히 하는 것이 좋습니다.

전환 가치:

전환할 가치가 없음:

• 단 하나의 대답이 당신을 실망시켰기 때문이죠. 먼저 프롬프트가 충분히 구체적인지 또는 SOUL.md 제약 조건이 충분히 구체적인지 확인하세요.
• 다른 모델이 더 강하다고 들었거든요. 더 강하다고 해서 작업 혼합 및 비용 프로필에 더 적합한 것은 아닙니다.
• "메모리 문제를 해결합니다." 메모리 문제는 모델 레이어에서 해결될 수 없습니다. 대신 메모리 항목을 검사하세요.

네 번째 행의 "동일한 테스트 메시지"라는 문구가 중요합니다. 매번 다른 질문을 사용하여 모델을 비교하는 경우 모델 차이가 아니라 질문 난이도를 측정하는 것입니다.

---

7. LightVela의 접근 방식: 낮은 위험으로 모델 전환

Hermes는 시스템 구조에서 각 레이어를 분리하지만 모델 접근 권한과 실행 환경은 사용자가 직접 관리해야 합니다. LightVela는 모델 전환을 일상적으로 수행하고 결과를 바로 검증할 수 있는 위험도 낮은 작업으로 제공하는 방향을 취합니다.

• 하나의 에이전트에는 한 번에 하나의 활성 모델이 있습니다 — 전환은 선택을 의미하며 모델당 별도의 에이전트가 필요하지 않습니다.
• 스위치 간에 자산이 안정적으로 유지됩니다 — 메모리, 클라우드 저장소 파일, 스킬 및 자동 작업 설정은 영향을 받지 않으며 채팅 기록은 이동되지 않습니다.
• 스위치는 검증 가능 - 콘솔에 활성 모델이 표시되고 하나의 테스트 메시지가 성공을 확인합니다.
• 실패 위치 찾기 가능 — 진단에서는 모델, 구성 및 작업 문제를 구분하기 위해 최신 로그를 유지합니다.
• 단일 요소 변경이 권장됩니다. 한 번에 하나씩 변경하고 즉시 테스트하는 것이 문서화된 권장 사항입니다.

---

핵심 요약

• 모델, 페르소나, 사용자 프로필, 메모리 및 스킬은 5개의 독립적인 레이어입니다. 전환은 첫 번째 것만 대체합니다.
• 문서화된 동작: 전환 시 메모리, 클라우드 스토리지, 스킬 또는 자동 작업이 지워지지 않으며 채팅 기록도 이동되지 않습니다.
• "느낌이 다르다"는 5가지 표현 계층의 차이(명령 따르기, 컨텍스트 압축, 장황함, 도구 호출 경향, 언어 스타일)에서 비롯됩니다.
• 실제 메모리 손실 여부는 한 단계로 확인할 수 있습니다. 에이전트가 분명히 알고 있어야 할 사실을 물어보세요.
• 자동화에는 고정된 모델 필드가 없습니다. 전환 후에는 해당 필드를 찾기보다는 출력 품질을 검토하세요.
• 문제를 해결하는 동안 하나의 규칙을 유지하십시오. 한 번에 하나의 요소를 변경하고 즉시 테스트하십시오.