LightVela 문서
요약
Hermes Agent가 정해진 시각에 먼저 연락할 수 있는 이유는 채팅 창에서 계속 기다리기 때문이 아니라, 자동 작업이 실행 시점·수행할 일·결과를 보낼 위치를 반복 가능한 설정으로 저장하기 때문입니다. 예약 시각이 되면 스케줄러는 이전 대화를 재생하는 대신 작업 지침을 바탕으로 독립적인 실행을 시작하고, 알림 설정에 따라 결과를 전달합니다. LightVela의 자동 작업은 이름, 일정(고정 요일·고정 간격·일회성 중 하나), 작업 지침, 활성 시간대, 알림 채널로 구성됩니다. 특정 모델에 작업을 고정하는 필드는 없으므로, 모델 전환 뒤 자동 작업의 모델을 다시 동기화해야 한다는 설명은 적용되지 않습니다. 실행 시 추가로 설명해 줄 사람이 없는 만큼 작업 지침 자체에 목표, 범위, 출력 형식이 모두 담겨 있어야 안정적으로 동작합니다.
"선제적"이라고 해서 계속 감시한다는 뜻은 아닙니다
"매일 아침 뉴스 요약을 알려주세요"는 평범한 지시처럼 들리지만 "지금 뉴스 요약을 알려주세요"와는 근본적으로 다릅니다.
두 번째 경우는 대화입니다. 사용자가 참여하고 있으므로 언제든 후속 설명을 하거나 내용을 수정하고 컨텍스트를 추가할 수 있습니다. 첫 번째 경우는 사용자가 없는 동안 실행해야 하는 작업입니다. 지시를 제대로 이해했는지 확인해 줄 사람도, 결과가 빗나갔을 때 중단시킬 사람도, 결과를 어디로 보내야 실제로 볼 수 있는지 알려 줄 사람도 없습니다.
따라서 선제적 작업에서 어려운 부분은 시간 트리거가 아닙니다. 진짜 어려운 점은 사용자의 참여에 의존하던 대화를 사용자 없이도 성공할 수 있는 작업 지침으로 바꾸는 것입니다. 이 문서는 그 지침에 무엇을 포함해야 하고 어떻게 안정적으로 운영할지를 설명합니다.
1. 자동 작업에 실제로 포함된 내용
LightVela에서 자동 작업을 생성하려면 다음 필드가 필요합니다.
| 필드 | 확인할 질문 | 설명 |
|---|---|---|
| 이름 | 작업을 무엇이라고 부를 것인가? | 목록에서 구분할 수 있도록 "작업 1" 대신 목적이 드러나는 이름을 사용 |
| 일정 | 언제 실행할 것인가? | 지정 요일, 고정 간격, 일회성 중 하나 선택 |
| 작업 지침 | 무엇을 달성해야 하는가? | 실행 시 에이전트가 따르는 프롬프트 |
| 활성 시간대 | 어느 시간에 실행할 수 있는가? | 실행 가능 시간을 제한하며, 비워 두면 하루 24시간 실행 가능 |
| 알림 채널 | 결과를 어디로 보낼 것인가? | 실행 알림을 받을 채널을 선택하는 옵션 |
중요한 점은 "모델" 필드가 없다는 것입니다. 자동 작업은 특정 모델에 고정되지 않으므로 모델 전환 후 각 작업의 모델을 다시 동기화해야 한다는 조언은 이 제품에는 적용되지 않습니다. 전환 뒤에 확인할 대상은 존재하지 않는 모델 필드가 아니라 출력 품질입니다. 이 레이어 구조는 "Hermes Agent의 두뇌를 교체할 수 있습니까? 모델 레이어 대 에이전트 레이어"에서 자세히 설명합니다.
또한 일정은 고정된 평일, 고정된 간격 및 일회성 중에서 선택되며 임의의 cron 표현식이 아닙니다. 이를 미리 알면 크론 모양의 일정을 설계한 후 입력할 곳이 없다는 사실을 알게 되는 수고를 덜 수 있습니다.
2. 세 가지 일정 유형 중 선택
세 가지 일정 유형은 서로 다른 요구를 처리합니다. 목적에 맞지 않는 유형을 선택하면 실행 결과가 기대와 달라질 수 있습니다.
고정된 주중 인간의 리듬이나 작업 주기에 따른 작업에 적합합니다. 월요일 아침에 지난 주의 진행 상황을 요약하고 일요일에 식물에 물을 주라는 알림을 표시합니다. 특정 시간에 고정되어 있다는 것이 특징인데, '그 순간에 이걸 보고 싶다'는 말이 딱 들어맞습니다.
고정 간격은 타이밍이 중요하지 않고 빈도만 중요하며 몇 시간마다 정보 소스를 확인하는 작업에 적합합니다. 그 정의 특성은 이전 실행에서 계산된다는 것입니다. 이는 "이 케이던스를 유지하고 싶습니다."에 적합합니다.
일회성은 특정 날짜의 알림과 같은 단일 이벤트에 적합합니다. 실행 후 종료되며 이후에는 끌 일이 없습니다.
선택 시 간단한 테스트: 귀하의 요구 사항에 시계 시간이 언급되어 있습니까? 그렇다면 고정된 평일을 사용하십시오. 빈도만 있는 경우 고정 간격을 사용합니다. 한 번 발생하면 일회용을 사용하세요.
3. 활성 시간대를 설정하는 이유
활성 시간대는 놓치기 쉽지만 불필요한 야간 알림을 막는 중요한 설정입니다. 작업은 계속 실행하되 특정 시간에는 사용자를 방해하지 않도록 제한할 수 있습니다.
고전적인 경우는 간격 작업입니다. 활성 창 없이 "2시간마다"로 설정하면 야간을 포함하여 24시간 내내 실행된다는 의미입니다. 활성 창을 사용하면 지정한 시간 동안에만 실행됩니다.
비워두면 연속 작동을 의미합니다. 따라서 작업이 실행되어서는 안되는 시간에 실행된 경우 먼저 이 필드를 확인하십시오.
4. 예약 시간이 되면 일어나는 일
이 지점에서 오해가 자주 생깁니다. 예약 작업이 "처음 입력한 문장을 에이전트에게 다시 보내는 것"이라고 생각하면, 기존 대화 맥락에 지나치게 의존하는 지침을 작성하게 됩니다.
실제로 일어나는 일: 스케줄러가 목표 시간에 도달하면 독립적인 에이전트 실행을 트리거합니다. 해당 실행은 작업이 생성된 대화를 재생하는 대신 작업 지침에 따라 작업을 완료합니다.
이는 중요한 결과를 가져옵니다. 작업 지침은 고유한 컨텍스트를 전달해야 합니다. 작업을 생성하는 동안 머릿속에 떠올린 배경 또는 이전에 에이전트로 논의한 세부 사항은 지침에 기록되었거나 장기 메모리에서 이미 캡처되지 않은 한 런타임에 반드시 적용되지는 않습니다.
두 가지 버전을 비교해보세요:
- 상황에 따른: "방금 했던 것처럼 요약을 작성하세요." — 런타임 시 "just did"가 더 이상 존재하지 않습니다.
- 자체 포함: "지난 24시간 동안 읽지 않은 이메일을 요약하여 발신자별로 그룹화하고 그룹당 최대 3개 항목으로 응답이 필요한 메시지만 보관합니다. 각 항목을 한 줄에 글머리 기호 목록으로 출력합니다."
두 번째는 목표, 범위, 필터 기준 및 출력 형식이 모두 내부에 있기 때문에 아무도 없는 상태에서 안정적으로 실행됩니다.
5. 독립적으로 실행할 수 있는 작업 지침 작성법
위의 메커니즘을 고려할 때 신뢰할 수 있는 작업 지침은 일반적으로 네 부분으로 구성됩니다.
먼저, 명시적인 목표 행동입니다. 무엇을 "주의 깊게 관찰"할지가 아니라 해야 할 일을 명시하십시오. '감시'가 완료되었는지 여부는 판단할 수 없습니다. "요약 및 나열"이 완료되었는지 판단할 수 있습니다.
두 번째, 명시적인 범위 경계. 시간 범위(지난 24시간), 볼륨 제한(그룹당 최대 3개), 필터(답장이 필요한 항목만). 경계가 없으면 동일한 작업이 날마다 전혀 다른 결과를 생성할 수 있습니다.
셋째, 명시적인 출력 형식. 목록 또는 산문, 그룹화 또는 단순, 각 항목의 길이. 당신이 그 자리에 없기 때문에 그 순간에 "너무 길다, 줄여라"라고 말할 수는 없습니다.
넷째, 명시적인 예외 처리. 일치하는 항목이 없으면 "오늘 처리할 항목 없음"을 보내야 할까요, 아니면 침묵해야 할까요? 이것이 없으면 "작업이 실행되지 않았습니다"와 "작업이 실행되었지만 아무것도 발견되지 않았습니다"를 구별할 수 없습니다.
네 번째 요점은 가장 흔히 생략되는 점으로, 작업이 건전한지 판단하는 능력에 직접적인 영향을 미칩니다.
6. 권장 적용 순서
자동 작업은 생성만 하고 끝내지 마세요. 다음 순서로 적용하면 대부분의 문제를 일찍 발견할 수 있습니다.
- 먼저 채팅에서 수동으로 확인하세요. 사용하려는 프롬프트를 에이전트로 직접 보내고 출력을 확인하세요. 이렇게 하면 일정을 방해하지 않고 프롬프트가 조정됩니다.
- 해당 결과에 따라 프롬프트를 수정합니다. 출력이 너무 길고, 범위가 너무 넓고, 형식이 불안정합니다. 여기서 모두 수정하세요.
- 작업을 생성하고 일정을 설정합니다. 섹션 2의 테스트를 사용하여 모드를 선택합니다.
- 실제로 읽은 곳에서 알림 채널 지점을 확인하세요. 보지 않은 곳에 전달된 결과는 결과가 없는 것과 같습니다.
- 필요한 경우 활성 시간 창을 설정합니다. 특히 간격 작업의 경우 야간 중단을 방지합니다.
- 실제 실행을 기다린 후 실행 기록을 검토합니다. 이것이 중요한 단계입니다. "생성된 작업"을 완료된 것으로 간주하지 마십시오. 성공적인 저장은 구성이 저장되었음을 의미하는 것이지 출력이 올바르다는 의미는 아닙니다.
- 첫 번째 실제 실행을 기반으로 프롬프트를 다시 한 번 개선합니다. 실제 실행은 수동 테스트와 다를 수 있으며, 이 두 번째 개정은 일반적으로 가장 큰 안정성 향상을 제공합니다.
이 제품은 작업 세부 정보 보기, 작업 목록 편집, 일시 중지 및 삭제를 지원하므로 7단계가 저렴합니다. 작업이 일시적으로 불필요한 경우 구성을 재사용할 수 있도록 삭제하는 것보다 일시 중지하는 것이 좋습니다.
7. 일반적인 증상과 점검 위치
| 증상 | 원인일 가능성이 높음 | 권장 조치 |
|---|---|---|
| 예정 시각에 아무 일도 일어나지 않음 | 작업이 일시 중지되었거나 현재 시각이 활성 시간대 밖임 | 작업 상태와 활성 시간대를 확인 |
| 실행됐지만 결과가 도착하지 않음 | 알림 채널이 없거나 확인하지 않는 곳으로 전달됨 | 알림 설정을 확인 |
| 출력 길이와 형식이 매번 크게 달라짐 | 지침에 범위와 출력 형식이 빠짐 | 5절의 네 요소를 추가 |
| 출력이 수동 테스트와 크게 다름 | 생성 시간의 대화 컨텍스트에 의존하는 지침 | 독립형 명령어로 다시 작성 |
| "결과 없음"과 "실행 안 됨"을 구분할 수 없음 | 지침에 예외 처리가 빠짐 | "결과가 없어도 알림 전송"을 추가 |
| 야간에도 알림이 옴 | 간격 작업에 활성 시간대가 설정되지 않음 | 활성 시간대를 설정 |
문제 해결 시 일반 원칙: 먼저 "실행되지 않음"과 "실행되었지만 잘못된 결과가 발생함"을 구분합니다. 전자는 작업 상태, 활성 창 및 알림 설정을 나타냅니다. 후자는 지침 자체를 가리킨다. 이들은 완전히 다른 해결 경로를 갖고 있으며 이를 함께 조사하는 것은 시간 낭비입니다.
8. LightVela의 접근 방식: 구성하고 검토할 수 있는 선제적 작업
Hermes는 예약 작업 메커니즘을 제공하지만 런타임과 스케줄러를 안정적으로 운영하는 일은 사용자에게 맡깁니다. LightVela는 이를 제품 안에서 설정하고 실행 기록을 검토할 수 있는 기능으로 제공하는 방향을 취합니다.
- 템플릿은 시작 비용을 낮춰줍니다 — 무엇을 자동화해야 할지 확신이 없으면 미리 만들어진 템플릿에서 시작하여 조정하세요.
- 작업 수명 주기는 관리 가능 — 하나의 조건을 변경하기 위해 작업을 다시 빌드할 필요 없이 생성 후 세부 정보 보기, 편집, 일시 중지 또는 삭제가 가능합니다.
- 전달은 선택 가능 — 알림 채널은 선택 사항 토글이므로 실제로 읽은 위치에 결과가 표시됩니다.
- 다른 기능과 분리 — 자동 작업, 모델, 스킬 및 클라우드 스토리지는 독립적으로 구성되며, 모델을 전환해도 자동 작업 설정이 변경되지 않습니다.
- 실패는 추적 가능 — 실행 이상을 진단의 최근 로그와 결합하여 원인을 찾습니다.
핵심 요약
- 자동 작업은 기본적으로 실행 시기, 수행할 작업, 전달 위치에 대한 저장되고 반복 가능한 구성입니다.
- 해당 필드는 이름, 일정(평일 고정 / 고정 간격 / 일회성), 작업 지침, 활성 시간 창, 알림 채널입니다.
- "모델" 필드가 없으므로 "전환 후 자동 작업 모델을 다시 동기화"는 정확하지 않습니다. 일정도 임의의 cron 표현식이 아닙니다.
- 트리거는 이전 대화를 재생하는 것이 아니라 독립적인 실행을 시작하므로 지침은 독립적이어야 합니다.
- 신뢰할 수 있는 지침에는 대상 작업, 범위 경계, 출력 형식, 예외 처리의 네 부분이 포함됩니다.
- 적용 과정에서 가장 중요한 마지막 단계는 작업 생성이 아니라 실제 실행을 기다린 뒤 기록을 검토하는 것입니다.
마지막 업데이트: 2026-08-31
LightVela 문서
앱은 진입점일 뿐이므로 하나의 에이전트가 여러 메시징 앱에 나타날 수 있습니다. 실제 작업 주체는 에이전트입니다. 메시지 게이트웨이는 세 가지 역할을 합니다. Telegram, WhatsApp, Discord, Slack, WeChat 등 구조가 서로 다른 메시지를 하나의 요청 형식으로 정규화하고, 플랫폼마다 페르소나와…
LightVela 문서
모델을 전환해도 Hermes Agent가 사용자를 잊지 않는 이유는 모델, 페르소나, 메모리가 서로 분리된 세 레이어에 저장되기 때문입니다. 모델은 추론과 생성을 담당하고, SOUL.md는 역할과 표현의 경계를 정의하며, USER.md와 MEMORY.