OS를 스케줄러로: 에이전트를 상시 운영하는 가장 단순한 방법

에이전트를 데모로 한 번 띄우는 것과, 매일 사람 손 없이 굴리는 것은 전혀 다른 문제다. 데모는 한 번의 실행이 성공하면 끝이지만, 상시 운영은 어제 어디까지 했는지·지금 무엇을 해도 되는지·중간에 죽으면 어떻게 이어 붙일지를 매번 답해야 한다.

그래서 “에이전트를 상시 운영하려면 무엇이 필요한가”라는 질문 앞에서 흔히 떠올리는 답이 있다. 워크플로 엔진, 작업 큐, 관리형 오케스트레이터. 우리도 그 길을 검토했다. 그리고 우리 내부 운영 에이전트 하나를 실제로 띄우면서, 가장 단순한 답을 골랐다 — OS가 이미 갖고 있는 것만 쓰는 것.

이 글은 그 에이전트가 무슨 일을 하는지가 아니라, “에이전트를 매일 굴리는 런타임을 무엇으로 짰나”에 관한 글이다.

claude -p는 결국 하나의 CLI다 — OS 스케줄러로 띄운다

상시 운영을 설계할 때 가장 먼저 깨달은 사실은 단순했다. 헤드리스로 도는 에이전트(claude -p)는 결국 하나의 명령어라는 것이다. 입력을 받아 실행하고 종료 코드를 남기는, 여느 CLI와 다를 바 없는 프로세스다.

그렇다면 “정시에 명령어를 실행하는” 문제는 이미 수십 년 전에 풀려 있다. 운영체제의 스케줄러 — cron, 그리고 macOS의 launchd — 가 바로 그 일을 한다. 우리는 별도의 오케스트레이션 레이어를 세우는 대신, OS 스케줄러가 헤드리스 CLI를 깨우게 했다.

# 개념적 스케줄 정의 (익명화)
정해진 주기마다
  → 헤드리스 에이전트 CLI 실행
  → 종료 코드와 로그를 디스크에 남김

핵심은 메커니즘의 얇음이다. 스케줄러는 에이전트가 무슨 일을 하는지 전혀 모른다. 그냥 정해진 시각에 프로세스를 깨우고, 끝나면 잊는다. 에이전트가 어떻게 바뀌든 스케줄러는 손댈 필요가 없다. 런타임의 책임이 명확히 분리되는 것이다.

파일이 곧 상태다 — git이 추적하는 상태머신

스케줄러가 프로세스를 깨우는 것까지는 쉽다. 진짜 어려운 건 그다음이다. 깨어난 에이전트는 “지금 무엇을 해야 하는가”를 어떻게 아는가?

흔한 답은 컨텍스트 윈도우나 데이터베이스다. 우리는 둘 다 택하지 않았다. 상태를 파일에 뒀다 — 구조는 yaml, 서술은 markdown. 그리고 그 파일들을 git으로 추적한다.

# 작업 항목 상태 파일 (일반화)
id: <불투명 식별자>
status: pending        # → running → done | blocked
updated_at: <타임스탬프>
note: |
  사람이 읽는 진행 메모

이 단순한 결정이 공짜로 세 가지를 준다. 재현: 어느 시점의 상태든 git 히스토리로 되감는다. 검사: 사람이 디렉토리를 열어 pending이 몇 개고 무엇이 blocked인지 그냥 읽는다 — 대시보드도 쿼리도 없이. 크래시 안전: 프로세스가 죽어도 상태는 디스크에 남는다. 컨텍스트 윈도우는 휘발하지만 파일은 남고, 다음 실행이 그 파일을 읽고 멈춘 자리에서 이어 간다.

요컨대 에이전트의 모든 결정과 진행이 곧 커밋이 된다. 상태머신을 따로 구현한 게 아니라, 파일시스템과 git이 이미 상태머신이었다.

왜 무거운 인프라를 버렸나

워크플로 엔진과 관리형 오케스트레이터는 분명 강력하다. 재시도·분기·관측 가능성을 잘 갖추고 있다. 우리가 그걸 버린 건 기능이 부족해서가 아니라, 작은 상시 운영 에이전트 하나에 그 무게가 과했기 때문이다.

대가는 명확하다. 엔진을 쓰면 그 자체를 운영해야 한다 — 배포, 버전, 장애 대응, 그리고 무엇보다 “에이전트가 지금 무슨 상태인가”를 그 엔진의 추상을 거쳐서만 볼 수 있다는 블랙박스성. OS 스케줄러 + 파일은 정반대다. 새 인프라가 0이고, 상태는 텍스트 파일이라 누구든 열어 읽는다. 투명하고 재현 가능하다.

여기엔 우리가 별도의 글에서 다룬 자율 운영 원리가 그대로 깔려 있다(에이전트가 워크스트림을 소유한다). 깨어난 에이전트의 상당 부분은 파일을 읽고 다음 상태를 정하는 결정론적 분기이고, LLM 추론은 정말 필요한 지점에서만 부른다 — 그래서 평소의 “심장박동”은 토큰을 거의 쓰지 않는다. 파괴적이거나 비용이 드는 행위 앞에는 승인 게이트를 둔다. 사람이 명시적으로 승인하기 전까지 그 행위는 차단되며, 게이트 자체도 결국 파일의 상태 전이일 뿐이다.

물론 한계도 정직하게 말해야 한다. 분산 스케일아웃이나 초당 수천 작업 같은 영역에서는 이 방식이 답이 아니다. 하지만 “조용히, 안정적으로, 매일 도는 운영 에이전트”에는 더 무거운 것을 얹을 이유가 없었다.

무엇을 배웠나

상시 운영을 직접 굴려 보고 가장 분명해진 교훈은, 진짜 어려운 문제는 LLM이 아니었다는 것이다. 모델은 충분히 똑똑했다. 어려운 건 운영의 기본기였다 — 상태를 어디에 두는가, 죽었을 때 어떻게 복구하는가, 사람이 어떻게 들여다보고 개입하는가.

이 질문들에 우리는 새 인프라가 아니라 이미 손에 있던 프리미티브로 답했다. 스케줄러는 OS에, 상태는 파일에, 이력은 git에, 안전은 게이트에. 화려하지 않지만, 화려하지 않아서 견고했다. “데모 AI”와 “매일 굴러가는 AI”를 가르는 건 모델의 영리함이 아니라 이 운영 설계의 두께다.

---

우리가 우리 내부 운영을 이렇게 굴리며 검증한 패턴은, 에이전트를 한 번 보여주는 데모가 아니라 매일 조용히 일하는 운영 자산으로 만드는 데 그대로 이식된다. 같은 단순함을 당신의 제품과 내부 워크플로에 적용하는 일을 함께 하고 싶다면 — partners@creativengine.ai.