LightVela 문서

요약

Hermes Agent의 "두뇌"는 교체할 수 있지만, 교체되는 것은 전체 에이전트가 아니라 모델 레이어뿐입니다. 모델 레이어는 요청 구문 분석, 단계 계획, 호출할 도구 선택, 답변 표현 등 이번 요청에서 어떻게 사고할지를 결정합니다. 에이전트 레이어에는 정체성(SOUL.md), 사용자 프로필(USER.md), 세션 간 사실(MEMORY.md 및 memories/), 축적된 방법(skills/), 메시지 채널, 자동 작업, 작업 디렉터리가 포함되며 모두 모델 외부에 있습니다. 따라서 모델을 전환해도 삭제되지 않습니다. LightVela에서 하나의 에이전트는 한 번에 정확히 하나의 활성 모델을 사용합니다. 모델을 전환해도 메모리, 클라우드 스토리지 파일, 스킬 또는 자동 작업 설정은 지워지지 않으며 이후 응답에 사용되는 엔진만 변경됩니다. 전환 후 에이전트가 낯설게 느껴진다면 원인은 거의 항상 메모리 손실이 아니라 새 모델의 지시 이행, 컨텍스트 압축, 표현 방식이 다르기 때문입니다.

---

이 질문이 반복해서 나오는 이유

"에이전트를 더 강력한 모델로 바꿀 수 있나요?"는 에이전트 제품에서 자주 나오는 질문입니다. 곧이어 "모델을 바꿔도 에이전트가 나를 기억하나요?"라는 질문이 따라옵니다.

두 질문을 함께 던지는 데에는 모델과 에이전트가 같은 것이라는 흔한 오해가 숨어 있습니다. 이런 관점에서는 에이전트를 LLM을 감싼 채팅 인터페이스로만 보기 때문에, 모델을 바꾸면 비서 전체가 바뀌고 처음부터 다시 시작해야 한다고 생각하기 쉽습니다.

그것이 실제로 사실이라면 에이전트는 장기적인 가치를 유지할 수 없습니다. 지난 주에 설명하신 프로젝트 맥락, 신중하게 조정한 톤, 캡처한 워크플로우 등 모든 것이 기술 업그레이드를 할 때마다 재설정됩니다. 아무나 믿고 쓸 수 있는 제품이 아닙니다.

Hermes Agent는 반대 전제를 기반으로 구축되었습니다. 모델은 교체 가능한 구성 요소이고 에이전트는 지속되는 구성 요소입니다. 이 기사에서는 실제로 이것이 무엇을 의미하는지 설명합니다.

---

1. 먼저 세 가지를 분리하세요: 모델, 런타임, 장기 자산

모델 전환을 이해하려면 먼저 에이전트가 수명 주기가 서로 다른 세 개 이상의 레이어로 구성된다는 점을 알아야 합니다.

대부분의 사람들은 첫 번째 레이어와 채팅 창만 보고 중간의 런타임과 그 아래의 자산 레이어는 누락됩니다. 그러나 이 두 개의 하위 레이어는 몇 달 동안 사용해도 에이전트를 "동일한 것"으로 인식하게 만드는 요소입니다.

유용한 비유: 모델은 사람이 지금 생각하는 방식이고 런타임은 사람의 몸과 손이며 장기적인 자산은 정체성, 기억 및 직업적 습관입니다. 누군가가 생각하는 방식을 바꾼다고 해서 그 사람이 다른 사람이 되는 것은 아닙니다. 왜냐하면 정체성과 메모리는 그에 따라 바뀌지 않았기 때문입니다.

---

2. 모델 레이어: 이번 요청에서 사고하는 방식을 담당

한 번의 요청을 처리하는 동안 모델 레이어는 단순히 텍스트만 생성하지 않습니다. 적어도 다음 네 가지를 결정합니다.

1. 해석 — 암시했지만 자세히 설명하지 않은 제약 조건을 포함하여 메시지를 구체적인 목표로 전환합니다.
2. 계획 — 작업에 필요한 단계 수, 어느 단계가 먼저인지, 연구가 실행에 앞서야 하는지 여부를 판단합니다.
3. 도구 호출 결정 — 파일 읽기, 웹 검색, 명령 실행 여부와 인수를 결정합니다.
4. 표현식 — 포함할 세부 사항 및 사용할 형식을 포함하여 결과를 읽을 수 있는 언어로 구성합니다.

네 개 모두 이 추론 패스에 속합니다. 이는 즉각적인 경험을 직접적으로 형성하므로 모델을 전환하면 눈에 띄는 느낌 변화가 발생합니다.

마찬가지로 중요한 것은 모델 레이어가 소유하지 않는 것입니다.

• 모델은 귀하의 데이터베이스가 아닙니다. 귀하의 선호 사항, 프로젝트 상태 또는 과거 결론은 저장되지 않습니다.
• 모델은 스케줄러가 아닙니다. 매일 아침 7시에 무언가가 실행되어야 한다는 사실을 알지 못합니다.
• 모델은 채널 관리자가 아닙니다. 응답이 어떤 Telegram 대화로 반환되는지 결정하지 않습니다.

이러한 모든 기능은 모델 외부에 있습니다. 이것이 "모델을 전환하는 것이 에이전트를 전환하는 것이 아니다"라는 기술적 근거입니다.

---

3. 에이전트 레이어: 사고의 연속성을 담당

에이전트 레이어의 책임은 해결하는 문제에 따라 다섯 그룹으로 나눌 수 있습니다.

3.1 정체성과 행동 규칙: SOUL.md

SOUL.md는 에이전트의 정체성, 말투, 우선순위, 하지 말아야 할 일을 정의합니다. 대화할 때마다 즉석에서 바뀌는 분위기가 아니라 지속적으로 적용되는 규칙 모음입니다.

모델 스위치 이후에도 SOUL.md는 여전히 정확히 그 위치에 있습니다. 새로운 모델은 ​​동일한 규칙을 읽고 적용합니다. 더 느슨하게 또는 더 엄격하게 규칙을 따를 수 있지만 규칙 자체는 변경되지 않았습니다. 이러한 구별은 나중에 "느낌이 다르다" 섹션을 이해하는 데 핵심이 됩니다.

3.2 사용자 프로필: USER.md

USER.md는 언어 습관, 선호하는 소통 방식, 자주 사용하는 도구, 명시적으로 피해야 할 사항처럼 사용자에 관한 안정적인 정보를 보관합니다. 덕분에 에이전트가 매번 "긴 답변과 짧은 답변 중 어느 쪽을 원하나요?"라고 다시 묻지 않아도 됩니다.

3.3 세션 간 사실: MEMORY.md 및 memories/

이 레이어는 이미 일어난 일 가운데 보관할 가치가 있는 사실과 결론을 저장합니다. 프로젝트 이름, 지난주에 내린 결정, 특정 매개변수를 현재 값으로 설정한 이유 등이 여기에 해당합니다. Hermes는 이 항목들에 SQLite + FTS5 전문 검색 인덱스를 만들고, 전체 기록을 컨텍스트에 넣는 대신 관련 주제가 나올 때 일치하는 항목만 불러옵니다.

메모리는 영원히 추가 전용이 아닙니다. Atomic add / replace / remove 작업을 통해 유지되며 /memory pending를 통해 검토할 수 있습니다. 전체 설계를 보려면 "더 많은 메모리가 더 좋지 않은 이유: Hermes Agent가 장기적으로 메모리를 선택, 관리 및 업데이트하는 방법"을 참조하세요.

3.4 축적된 작업 방법: skills/

skills/에는 "X 상황이 발생하면 이렇게 처리한다"는 표준 절차가 저장됩니다. 각 SKILL.md에는 일반적으로 트리거 조건을 선언하는 YAML 프런트매터가 있습니다. 이는 사실을 담는 선언적 메모리와 별개인 절차적 메모리입니다. 자세한 내용은 "메모리는 스킬이 아닙니다: Hermes Agent가 사실 메모리와 절차 메모리를 구분하는 방법"을 참조하세요.

3.5 연결 및 스케줄링: 채널, 자동 작업, 작업 디렉터리

• 채널은 에이전트가 메시지를 받는 진입점과 결과를 돌려보낼 위치를 결정합니다.
• 자동 작업은 사용자가 직접 요청하지 않아도 정해진 시점에 실행할 작업을 결정합니다.
• 작업 디렉터리는 작업의 입력과 출력이 저장되는 위치와 접근 경계를 결정합니다.

세 가지 모두 에이전트 레이어 구성이며 모델이 현재 활성화되어 있는 것과 독립적입니다.

---

4. 레이어를 분리해야 하는 네 가지 실질적 이유

모델과 에이전트를 분리하는 이유는 단순히 아키텍처를 깔끔하게 만들기 위해서가 아닙니다. 실제로 다음과 같은 이점이 있습니다.

이유 1: 모델은 ​​개인 자산이 축적되는 것보다 훨씬 빠르게 개선됩니다. 상당히 강력한 모델은 몇 달 내에 출시될 수 있지만, 공유된 메모리, 기본 설정 및 작업 흐름은 느리게 구축됩니다. 두 가지가 결합되면 업그레이드할 때마다 누적 비용이 발생하며 사용자는 단순히 업그레이드를 거부할 것입니다.

이유 2: 작업마다 다른 모델이 필요합니다. 빠른 초안 작성과 무거운 추론이 반드시 동일한 모델은 아닙니다. 디커플링을 사용하면 각 작업 종류에 대해 별도의 메모리를 사용하여 별도의 에이전트를 유지하는 대신 작업별로 전환할 수 있습니다.

이유 3: 공급자 가용성은 결코 보장되지 않습니다. 공급자가 속도 제한, 오류 또는 정책 변경 시 즉시 구성된 다른 모델로 이동해야 합니다. 메모리가 모델에 연결되면 해당 스위치에는 허용할 수 없는 비용이 발생합니다.

이유 4: 소유권이 명확해집니다. 메모리와 스킬은 독립적인 파일과 디렉터리에 있기 때문에 특정 모델의 액세서리가 아니라 귀하의 자산입니다. 이것이 애초에 "자신만의 에이전트 훈련"이라는 문구를 의미있게 만드는 것입니다.

---

5. LightVela에서 모델을 전환할 때 일어나는 일

앞 절에서 설명한 메커니즘이 실제 제품에서는 어떻게 동작하는지 살펴보겠습니다.

하나의 에이전트는 한 번에 정확히 하나의 활성 모델을 사용합니다. 전환이란 구성된 모델이 현재 활성 상태인지 선택하는 것을 의미하며, 새로운 에이전트를 생성하지 않습니다. 여러 모델을 사용하기 위해 여러 에이전트가 필요하지 않습니다.

전환해도 메모리, 클라우드 스토리지 파일, 스킬 또는 자동 작업 설정은 지워지지 않습니다. 모델 스위치는 후속 응답에 사용되는 엔진만 변경합니다. 채팅 기록을 이동하거나 클라우드 저장소에 파일을 다시 쓰거나 스킬 및 자동 작업 구성을 변경하지 않습니다.

전환 준비 및 확인, 문서화된 흐름에 따라:

1. 대상 모델이 이미 구성되어 있고 계정에서 사용할 수 있는지 확인하세요. 아직 구성되지 않은 경우 먼저 모델 구성을 완료하세요.
2. 새로운 모델이 정상적으로 응답하는지 확인하기 위해 짧은 테스트 메시지를 준비합니다.
3. 전환 후 해당 테스트 메시지를 채팅으로 보내고 에이전트가 응답하는지와 콘솔에 선택한 모델이 표시되는지 확인합니다.
4. 전환 후 첫 번째 응답이 약간 느린 경우 잠시 기다렸다가 다른 항목을 변경하기 전에 한 번 다시 시도하십시오.

흔한 오해를 바로잡으면, 자동 작업은 이름, 일정(지정 요일, 고정 간격, 일회성 중 하나), 작업 지침, 활성 시간대, 알림 채널로 구성됩니다. "이 자동 작업을 특정 모델에 고정"하는 필드는 없습니다. 따라서 모델 전환 후 자동 작업의 모델을 다시 동기화해야 한다는 조언은 맞지 않습니다. 전환 후 확인할 것은 존재하지 않는 모델 필드가 아니라 작업 결과의 품질입니다.

---

6. 전환 후 '느낌이 달라지는' 이유

전환 후의 행동 변화를 메모리 손실로 오해하는 경우가 많습니다. 행동 변화와 데이터 손실은 서로 다른 문제이므로, 둘을 혼동하면 점검 방향도 잘못 잡게 됩니다.

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

테스트는 간단합니다. 알고 있어야 한다고 확신하는 사실에 대해 물어보세요. 이전에 특정 프로젝트 이름이나 기본 설정을 말한 경우 전환 후에 정확히 해당 사항에 대해 물어보세요. 올바르게 대답하면 메모리 레이어가 그대로 유지되고 스타일 차이가 나타나는 것입니다. 실제로 응답할 수 없으면 메모리 파일과 항목이 아직 있는지 확인하십시오.

실용적인 규칙: 한 번에 하나의 요소를 변경하고 각 변경 후에 테스트하십시오. 모델을 전환하고, 페르소나를 편집하고, 스킬을 추가하면 어떤 레이어가 문제를 일으켰는지 알 수 없습니다.

---

7. 모델 전환이 유용한 경우

현재 가장 강력한 모델을 쫓는 것보다 필요에 따라 선택하는 것이 더 유용합니다.

전환 후 에이전트가 작동할 수 없는 경우 다음 순서로 문제를 해결하십시오. 대상 모델의 자격 증명 및 공급자 설정이 완료되었는지 확인 → 모델이 충분한 할당량으로 계정에서 사용 가능한지 확인 → 작동하는 것으로 알려진 모델로 테스트 → 여전히 실패하는 경우 진단에서 최근 로그를 확인하세요.

---

8. LightVela의 접근 방식: 모델은 선택하고 자산은 유지

Hermes는 시스템 구조에서 모델과 에이전트를 분리하지만, 기본적으로 Markdown 파일과 로컬 환경을 직접 관리할 수 있는 사용자를 전제로 합니다. LightVela는 이 분리를 일반 사용자가 제품 안에서 다룰 수 있는 기본 경험으로 제공하는 방향을 취합니다.

• 모델은 전환 가능한 설정이며 설정 시 일회성 결정으로 고정되지 않습니다.
• 메모리, 스킬, 클라우드 스토리지 및 자동 작업은 모델 스위치 전체에서 안정적으로 유지되는 사용자 자산이므로 업그레이드는 결코 다시 시작을 의미하지 않습니다.
• 스위치는 검증 가능: 콘솔에는 활성 모델이 표시되고 채팅의 단일 테스트 메시지는 스위치가 작동했음을 확인합니다.
• 실패는 추적 가능: 진단은 최근 로그를 유지하므로 문제가 모델, 구성 또는 작업 자체에 있는지 여부를 알 수 있습니다.

결과적으로 모델 진행 상황은 귀하에게 직접 전달되지만, 귀하가 이미 축적한 것은 결코 해당 진행 상황의 대가가 되지 않습니다.

---

핵심 요약

• 에이전트에는 교체 가능한 모델 레이어, 장기 실행 런타임, 지속적으로 축적되는 장기 자산이라는 세 가지 이상의 레이어가 있습니다.
• 모델 레이어는 현재 차례에 대한 해석, 계획, 도구 호출 및 표현을 처리합니다. 기본 설정을 저장하거나 일정을 실행하거나 채널을 관리하지 않습니다.
• SOUL.md, USER.md, MEMORY.md, memories/, skills/, 작업 디렉터리는 모두 모델 외부에 있으므로 모델을 전환해도 사라지지 않습니다.
• LightVela에서 하나의 에이전트에는 한 번에 하나의 활성 모델이 있습니다. 전환해도 메모리, 클라우드 스토리지, 스킬 또는 자동 작업이 지워지지 않습니다.
• 자동 작업에는 "고정된 모델" 설정이 없으므로 전환 후 자동 작업 모델을 다시 동기화해야 한다는 주장은 정확하지 않습니다.
• 전환 후 답변이 다르게 느껴지는 이유는 대개 지시 이행, 컨텍스트 압축, 표현 방식의 차이입니다. 메모리 손실 여부는 에이전트가 이미 알고 있어야 할 사실 하나를 물어 확인할 수 있습니다.