저는 1인 개발자입니다. 어느 순간이든 저를 대신해 수익을 창출하거나, 데이터를 스크래핑하거나, 사고하는 몇 가지 상시 가동 프로세스(always-on processes)를 운영하고 있습니다. Polymarket 폭락 복구 트레이딩 봇, 약 14,000개의 항목이 포함된 디렉토리를 재생성하는 주간 사이트 스크래퍼(site-scraper), 몇 개의 API 서버, 시크릿 스캐너(secret-scanner), DB 유지 관리 작업(DB-retention job), 그리고 전략을 검토하거나 취약점을 탐색하기 위해 LLM을 호출하는 몇 개의 예약된 에이전트들까지 포함해서 총 13개입니다.

수개월 동안 이것들은 launchd plist 파일, 흩어져 있는 crontab 라인, 그리고 제가 잊어버리고 지내던 nohup … & 프로세스들의 난잡한 집합체로 존재했습니다. 그러다 프로세스 하나가 조용히 죽어버리면 — 대개 대시보드의 숫자가 움직이지 않는 것을 보고서야 며칠 뒤에야 알아차리곤 했습니다. 이것이 전형적인 에이전트 운영(agent-ops)의 실패 모드입니다: 수많은 독립적인 자율 프로세스, 그러나 통합된 관리자(supervisor)는 없음. 각각은 개별적으로 단순하지만, 집합적으로는 감사가 불가능한 상태였습니다.

저는 Kubernetes를 원하지 않았습니다. 1인 개발자의 상시 가동 작업들을 관리하기에 k8s는 과도한 도구(sledgehammer)입니다. 관리하려는 모든 것보다 제어 평면(control plane)이 더 무겁기 때문입니다. 제가 원한 것은 단 하나의 질문에 대해 정직한 답을 줄 수 있는 가장 작은 도구였습니다: 실행되어야 할 모든 것이 실제로 실행 중이며, 실제로 작동하고 있는가?

그래서 저는 ForgeOS를 만들었습니다. 모든 프로세스를 단일 YAML 파일로 정의된 하나의 **엔진(engine)**으로 취급하는 아주 작은 커널(약 1,900 라인의 Python 코드, 무거운 의존성 없음 — 오직 pyyaml만 사용)입니다.

세 가지 엔진 유형, 하나의 기본 단위

daemon        long-running        트레이딩 봇, API 서버, 수집기(collectors)
cron          scheduled           주간 내보내기(export), 일일 스캔
intelligence  scheduled + LLM     정해진 일정에 따라 실행되고 출력이 다시 파이프(piped)로 들어오는 Claude-CLI 에이전트

세 번째 유형은 사람들이 눈살을 찌푸릴 수도 있는 것이라 미리 변호해 두겠습니다. 지능형 엔진(intelligence engine)은 그저 운 좋게 LLM을 호출하는 cron job일 뿐입니다. 스케줄링, 상태 확인(health checks), 로깅 방식 모두 다른 엔진과 동일합니다. 제가 "AI 에이전트"를 특별 대우해야 하는 존재가 아니라 백업 작업과 동일한 기본 단위(primitive)로 모델링하기 시작한 순간, 전체 시스템은 단순해졌습니다. 정해진 일정에 따라 전략을 검토하는 에이전트나 매일 밤 실행되는 DB 정리(DB-prune) 작업은 구조적으로 동일하며, 단지 command만 다를 뿐입니다.

실제로 내 삶을 바꾼 부분: 상태 확인(health) + 자가 치유(self-heal)

각 엔진은 자신의 설정(config) 파일 내에 "건강함(healthy)\

2. 코드 깊숙이 숨기지 말고, 설정(config)에 종료 조건(kill conditions)을 선언하세요. 제 트레이딩 엔진은 kill_condition: daily_loss > $10 OR cash < $20와 같은 조건을 엔진 정의 바로 옆에 명시합니다. 봇의 소스 코드 400줄 아래에 숨겨두지 않습니다. 안전 제한(safety limit)을 그것이 관장하는 엔진 바로 옆에 보이게 유지하는 것이, 제가 돈을 움직이는 프로세스를 실제로 무인(unattended) 상태로 실행할 수 있게 만든 핵심입니다. 한눈에 볼 수 없는 안전 제한은 신뢰할 수 없는 안전 제한입니다.

3. AI 에이전트를 일반적인 엔진(ordinary engines)으로 모델링하세요. 특별한 "에이전트 런타임(agent runtime)"을 만들고 싶은 유혹이 들겠지만, 이를 거부하세요. 정해진 일정에 따라 실행되는 LLM 호출은 단지 비용이 많이 드는 command를 가진 크론 잡(cron job)일 뿐입니다. 다른 모든 것과 동일한 상태 확인 루프(실행되었는가? 출력 로그가 신선한가?)와 동일한 재시작 정책(restart policy)을 부여하세요. 비결정론(non-determinism)은 command 내부에 존재하며, 이를 둘러싼 감독(supervision)은 지루할 정도로 단순해야 합니다.

솔직한 고백: 여전히 부족한 점

로그 신선도(log-freshness)는 "실행되었는가"에 대한 답은 줍니다. 하지만 "잘 실행되었는가"에 대한 답은 주지 못합니다. 지능형 엔진(출력이 비결정론적인 텍스트인 LLM)에게는 바로 이 질문이 실제로 중요한 문제입니다. 현재 저에게 이 과정은 여전히 수동 검토 단계입니다. 에이전트는 안정적으로 실행되지만, 그 전략 검토가 좋았는지를 판단하는 것은 인간의 영역입니다. 저는 아직 품질 검사(quality check)를 자동화하지 않았으며, 단순한 "LLM이 LLM을 채점하는" 루프가 저를 완전히 배제할 만큼 신뢰할 수 있는지 아직 확신하지 못합니다. 만약 여러분이 정해진 일정에 따라 작동하는 에이전트의 비결정론적 출력에 대한 상태 확인(health-checking) 문제를 해결했다면, 어떻게 했는지 진심으로 듣고 싶습니다. 그것이 이 설계의 열려 있는 경계(open edge)입니다.

상태 (Status)

ForgeOS는 **출시 전 단계(pre-release, v0.1.0)**이며 공개적으로 빌드되고 있습니다. 아직 PyPI나 공개 리포지토리(public repo)에 올라와 있지 않으며, 현재는 소스 체크아웃을 통해 설치할 수 있습니다 (프로젝트 루트에서 pip install -e .). 제가 지금 이 글을 쓰는 이유는 아키텍처(선언적 엔진 + 로그 신선도 기반 상태 확인 + 자가 치유, k8s 미사용)가 재사용 가능한 부분이며, 여러분이 제 코드를 실행하든 안 하든 그 자체로 가치가 있기 때문입니다.

만약 여러분이 현재 장기 실행(long-running) 또는 예약된(scheduled) 에이전트들을 관리하고 있다면 — systemd를 사용하시나요? 호스팅된 오케스트레이터(orchestrator)를 사용하시나요? 아니면 자체 개발한 시스템을 사용하시나요? — 댓글을 통해 여러분의 사례를 공유해 주시면 좋겠습니다. 특히 마지막 미해결 과제인, 출력이 비결정론적 텍스트(non-deterministic text)인 에이전트의 상태를 어떻게 헬스 체크(health-check)하는지에 대해 논의해보고 싶습니다.