처음 풀고 싶었던 문제는 단순히 "정해진 시간에 Aside를 실행할 수 있을까?"가 아니었어요.
Aside 공식 문서를 보면 무료 플랜에서 동시에 활성화해 둘 수 있는 루틴은 최대 3개입니다. 반복하고 싶은 일이 네 개, 다섯 개로 늘어나면 어느 작업을 끄고 켤지부터 관리해야 해요.
그런데 이미 계속 돌아가는 다른 에이전트가 있고, 그 에이전트도 자기 크론이나 루틴을 갖고 있습니다. 그렇다면 시간 관리는 그쪽에 맡기고, 실행 시각이 됐을 때 Aside CLI만 호출하면 어떨까 싶었습니다.
다른 에이전트의 루틴
→ Aside 실행 상태 확인
→ Aside CLI로 작업 시작
→ 세션과 최종 답변 확인
→ 성공했을 때만 완료 처리이 글에서 말하는 "루틴 한도를 피한다"는 뜻은 Aside의 모델 사용량이나 과금 한도를 우회한다는 의미가 아닙니다. 스케줄을 외부에 두어 Aside 안의 활성 루틴 3칸을 쓰지 않는 구조를 뜻해요.
처음 문제는 시간 예약보다 루틴 3칸이었어요
Aside의 내장 루틴은 두 종류입니다.
- Cron routine은 정해진 시각마다 새 작업을 시작합니다.
- Heartbeat routine은 기존 채팅을 깨워 그 문맥으로 이어갑니다.
기능 자체는 편합니다. 다만 무료 플랜은 활성 루틴을 최대 3개까지만 유지할 수 있고, Pro 플랜은 활성 루틴 수에 제한이 없다고 공식 문서에 적혀 있습니다.
매주 요약하기, 특정 대화 이어가기, 자료 확인하기처럼 반복 작업을 하나씩 넣다 보면 무료 플랜의 세 칸은 금방 찰 수 있어요. 그래서 Aside 안에 루틴을 더 만드는 대신, 외부 에이전트가 스케줄을 가지고 있다가 공식 CLI를 호출하는 쪽으로 방향을 바꿨습니다.
Aside 내장 루틴
시간 판단 + 작업 실행
외부 에이전트 방식
외부 에이전트가 시간 판단 + Aside는 작업 실행핵심은 Aside를 덜 쓰는 게 아니라 역할을 나누는 것입니다. 다른 에이전트는 시계를 보 고, Aside는 실제 작업을 합니다.
실제 외부 에이전트 루틴을 만들기 전에 호출 구간부터 시험했어요
이번 실측에서는 장기 실행되는 에이전트 크론을 새로 등록하지 않았습니다. 먼저 같은 역할을 하는 macOS 외부 스케줄러로 가장 작은 시험을 만들었어요. 스케줄러가 5초를 기다렸다가 Aside CLI를 호출하게 했습니다.
이렇게 한 이유는 간단합니다. 처음부터 장기 루틴을 만들면 실패했을 때 스케줄 문제인지, Aside CLI 문제인지, 모델 연결 문제인지 섞여버립니다. 우선 아래 한 구간만 떼어 확인했습니다.
외부 스케줄러
→ Aside CLI
→ 실제 모델 응답제공자와 모델은 claude-code/claude-opus-5-5로 고정했고, 속도는 default로 두었습니다.
새 작업과 같은 대화 이어가기를 각각 호출했어요
새 작업에는 aside exec를 썼습니다. 예약 시각에서 약 0.07초 뒤 시작했고, 10초쯤 지나 새 세션 하나가 idle 상태로 끝났습니다. 실행 기록에서 지정한 제공자와 모델, 사용한 도구, 최종 답변까지 확인했어요.
같은 대화를 이어갈 때는 방금 만든 세션에 aside session resume을 호출했습니다. 약 0.15초 뒤 시작해 6초쯤 만에 끝났고, 세션 수를 늘리지 않은 채 앞 대화의 문맥으로 답했습니다.
aside exec \
--account "$ACCOUNT" \
--host local \
--profile "$PROFILE_ID" \
--provider claude-code \
--model claude-opus-5-5 \
--speed default \
--effort minimal \
--permission ask \
"실행할 작업"
aside session resume \
--account "$ACCOUNT" \
"$SESSION_ID" \
"앞 대화의 문맥으로 이어서 할 작업"두 호출 모두 Aside의 routine이나 settings를 새로 만들거나 바꾸지 않았습니다. 즉, 이 시험에서는 Aside의 활성 루틴 칸을 추가로 쓰지 않고 새 작업과 기존 대화 이어가기를 실행했습니다.
한 번 성공한 뒤 외부 반복 호출도 두 번 돌려봤어요
다음에는 임시 launchd 작업을 두 번 발화시켰습니다. Aside가 실행 중인 상태에서 두 호출은 각각 약 2.6초와 2.4초가 걸렸고, 서로 다른 새 세션에서 지정한 답을 정확히 돌려줬습니다.
시험이 끝난 뒤에는 임시 작업과 plist를 모두 지웠습니다. 영구 스케줄러는 남기지 않았어요.
여기까지 확인한 사실은 두 가지입니다.
- 외부 스케줄러가 Aside CLI를 반복 호출할 수 있습니다.
- 이 호출을 위해 Aside 내장 루틴을 새로 만들 필요는 없었습니다.
반대로 네 개 이상의 외부 루틴을 장기간 동시에 운영해 무제한 확장까지 증명한 것은 아닙니다. 이번에는 호출 경로와 두 번의 반복 실행까지만 확인했어요.
루틴 칸을 아껴도 호출 비용까지 사라지는 건 아니었어요
외부 에이전트로 시간을 관리하면 Aside의 활성 루틴 칸은 아낄 수 있습니다. 그렇다고 실제 모델 실행 비용까지 없어지는 것은 아니에요.
이번 기록에서는 새 작업 한 번이 약 0.39달러, 같은 대화 이어가기 한 번이 약 0.02달러였습니다. 반복 시험의 두 호출은 각각 약 0.35달러였어요.
작업 길이와 문맥이 달랐기 때문에 이 숫자를 고정 단가로 볼 수는 없습니다. 루틴 개수 문제와 모델 사용량 문제는 서로 다른 층이라는 점이 중요했습니다.
아끼는 것: Aside의 활성 루틴 슬롯
그대로 남는 것: 실제 모델 호출과 그에 따른 사용량이 구조가 돌아가려면 Aside가 먼저 살아 있어야 했어요
외부 스케줄러만 정상이라고 끝은 아니었습니다. Aside 본체와 백그라운드 프로세스를 모두 끈 뒤 같은 로컬 호출을 실행하자 아래 오류와 함께 실패했습니다.
Failed to request daemon auth challenge: fetch failed
Aside isn't running on this machine.
- Start Aside Browser and retry, or
- control another machine / Aside Cloud instead: run 'aside login' once, then 'aside exec --host <host>' (see 'aside host list').새 세션은 생기지 않았고 Aside가 자동으로 다시 켜지지도 않았습니다. 현재 확인한 로컬 방식에서는 외부 에이전트가 시간을 맞추는 것만으로 부족하고, 실행 전에 Aside와 프로필 연결 상태를 확인해야 합니다.
Wi-Fi가 끊겼다가 돌아왔을 때도 인터넷 연결만 복구해서는 두 번 연속 Connection error가 났습니다. Aside를 재시작하고 프로필이 connected로 돌아온 뒤에야 다음 호출이 성공했어요.
그래서 운영 흐름은 아래 처럼 잡았습니다.
1. 다른 에이전트의 루틴이 시간을 판단한다.
2. Aside와 백그라운드 프로세스를 확인한다.
3. 프로필이 connected인지 확인한다.
4. 새 작업은 exec, 같은 대화는 session resume으로 호출한다.
5. 세션 상태와 최종 답변을 확인한다.
6. 검증을 통과했을 때만 완료 처리한다.기본 CLI 세션은 완료 배너와 소리를 보내는 분기까지 가지 않았습니다. 결과 알림이 필요하다면 외부 에이전트가 최종 답변을 확인한 뒤 따로 맡는 편이 맞습니다.
그래서 루틴 한도를 피한다는 말을 이렇게 정리했습니다
이번에 만든 구조는 Aside의 무료 기능을 속여서 내장 루틴을 네 개로 늘리는 방식이 아닙니다.
Aside 안의 활성 루틴 수는 그대로 둔다.
대신 다른 에이전트가 더 많은 스케줄을 관리한다.
실행 시각마다 공식 Aside CLI를 호출한다.실제로 확인한 범위에서는 외부 예약 호출, 새 작업 시작, 같은 대화 이어가기, 두 번의 반복 실행이 모두 가능했고 Aside routine/settings 변경은 0건이었습니다.
다만 실제 다른 에이전트에 장기 크론을 설치해 네 개 이상을 계속 운영한 것은 아직 확인하지 않았습니다. 절전이나 로그아웃 뒤 자율 복귀도 안전 조건이 없어 실행하지 않았어요. 따라서 현재 결론은 "내장 루틴 3칸을 쓰지 않는 외부 호출 경로는 작동한다"까지입니다. "무제한으로 오래 운영해도 된다"까지는 아닙니다.
처음 목표는 스케줄을 다른 에이전트에 맡겨 Aside의 활성 루틴 3칸을 아끼는 것이었습니 다. 이번에는 그 구조 중 외부 스케줄러가 CLI를 호출하는 구간까지 확인했습니다.
