Daemons – AI Agent가 만든 운영 부채를 자동으로 청소하는 백그라운드 프로세스

Show HN: Daemons – we pivoted from building agents to cleaning up after them

Apr 21, 2026•rileyt•View Original

TL;DR Highlight

AI Agent가 코드를 빠르게 생성할수록 쌓이는 PR 관리, 문서 업데이트, 이슈 정리 같은 운영 부채를 .md 파일 하나로 정의한 자율 실행 Daemon이 자동으로 처리해주는 도구다.

Who Should Read

AI Agent(Cursor, Copilot 등)를 팀에 도입했는데 코드 생성 속도는 빨라졌지만 PR 방치, 문서 불일치, 이슈 미분류 같은 운영 관리가 오히려 더 힘들어진 개발팀 리드나 DevOps 엔지니어.

Core Mechanics

Agent는 사람이 직접 실행시키는 방식(human-initiated)이지만, Daemon은 스스로 환경을 감시하다가 변화를 감지하면 자동으로 동작하는 방식(self-initiated)이다. 프롬프트 없이도 작동한다는 게 핵심 차이다.
Daemon은 저장소 안에 .md 파일 하나로 정의한다. YAML frontmatter 영역에 이름, 목적, 감시할 조건(watch), 수행할 루틴(routines), 절대 하면 안 되는 행동(deny), 실행 스케줄(cron 형식)을 선언한다.
frontmatter 아래 Markdown 본문에는 운영 정책, 출력 포맷, 에스컬레이션 규칙, 처리 한도(limits) 등 Daemon이 '어떻게' 행동할지를 자연어로 기술한다. 코드 없이 역할을 정의할 수 있다.
deny 규칙으로 Daemon의 행동 범위를 명시적으로 제한할 수 있다. 예를 들어 issue-labeler Daemon은 라벨 추가만 허용하고 라벨 제거, 이슈 상태 변경, 댓글 작성은 deny로 막아둔다.
limits 섹션으로 한 번 실행 시 처리량을 제한할 수 있다. 예시의 issue-labeler는 이벤트 발생 시 해당 이슈만, 매일 새벽 2시 정기 실행 시에는 최대 20개 이슈만 처리하도록 제한해 과도한 자동화를 방지한다.
watch 조건과 schedule을 동시에 설정해 하이브리드 방식으로 동작할 수 있다. 이벤트가 발생하면 즉시 반응하고, 정기 스케줄로는 놓친 항목을 일괄 처리하는 방식이다.
Daemon 파일은 오픈 포맷으로 설계되어 있어 동일한 .md 파일이 해당 스펙을 지원하는 어떤 provider에서도 동작할 수 있다고 주장한다. 팀 간 공유나 라이브러리화도 가능하다.
공식 제공되는 Daemon 라이브러리로는 PR 리뷰 준비 상태 유지(pr-helper), 이슈 라벨링(issue-labeler), 버그 트리아지, 의존성 업데이트(Codebase Maintainer), 문서 최신화(Librarian) 등이 있다.

Evidence

두 Daemon이 서로 관련된 파일을 동시에 수정할 때 충돌을 어떻게 처리하느냐는 질문이 나왔다. agent-coordinator 프로젝트를 만든 개발자는 SQLite의 INSERT...SELECT로 원자적 작업 선점을 구현하고, 각 에이전트에게 별도의 git worktree를 부여해 공유 브랜치에 충돌이 아예 도달하지 않도록 했다는 경험을 공유했다. Daemons가 '추가만 하는(additive)' 방향으로 갈지 아니면 명시적 순서 제약을 .md에 선언하는 방향으로 갈지 궁금하다는 반응이었다.
Claude의 Hooks 기능(https://code.claude.com/docs/en/hooks)과 어떻게 다르냐는 질문이 있었다. 이에 대해 한 댓글은 Hooks는 이벤트 발생 시 1회 실행되는 방식인 반면, Daemon은 여러 이벤트에 걸쳐 상태를 유지하며 관찰하는 지속 프로세스에 가깝다고 설명했다. cron과 상시 실행 서비스의 차이와 같다는 비유를 들었고, 단일 이벤트 트리거가 아닌 여러 이벤트에 걸친 상태 기반 감시가 필요할 때 Daemon 방식이 적합하다고 봤다.
실제로 어떻게 연동되는지 동작 방식이 사이트에서 전혀 설명되지 않는다는 지적이 여러 댓글에서 나왔다. 한 사용자는 '설정하려면 Charlie와 대화하라는 말만 반복되는데 어떻게 대화를 시작하는지 모르겠다'고 불만을 표했고, 또 다른 사용자도 '무엇이 언제 실행되는지 설명이 없다'며 투명성 부족을 지적했다. 이에 팀 측에서는 예시 Daemon 파일(https://github.com/charlie-labs/daemons)과 레퍼런스 문서(https://docs.charlielabs.ai/daemons) 링크를 댓글로 공유했다.
OpenProse(https://openprose.ai/)와 어떻게 다르냐는 경쟁 제품 비교 질문도 있었고, 'callable skills로도 같은 걸 할 수 있는 거 아니냐'는 회의적인 의견도 있었다. schedule에만 결정론적 요소가 있고 나머지는 완전 비결정적이라는 점을 꼬집는 댓글도 있었다.
저장소를 클라우드 플랫폼에 연결하면 해당 플랫폼이 repo 내 Daemon 파일을 읽어서 동작하는 구조인지 묻는 질문이 있었는데, 팀의 명확한 답변은 댓글에서 확인되지 않았다. 동작 아키텍처에 대한 공식 설명이 부족하다는 점이 커뮤니티의 공통된 피드백이었다.

How to Apply

PR 리뷰 품질이 들쭉날쭉하고 설명이 부족한 PR이 자주 올라온다면, pr-helper Daemon을 저장소에 추가해 PR이 열리거나 업데이트될 때마다 자동으로 설명 개선 제안과 리뷰어 컨텍스트 누락 여부를 체크하도록 설정할 수 있다.
Linear나 GitHub Issues에 라벨 없이 방치된 이슈가 쌓인다면, issue-labeler DAEMON.md를 작성해 이슈 생성 이벤트와 매일 새벽 정기 실행을 조합하고 deny 규칙으로 라벨 추가만 허용하면 기존 데이터를 건드리지 않고 안전하게 자동 분류할 수 있다.
Daemon 파일이 오픈 포맷이라고 주장하므로, 팀 내에서 공통으로 쓰는 Daemon을 .agents/daemons/ 디렉토리에 버전 관리하고 신규 프로젝트에 복사해 재사용하는 식으로 운영 자동화를 템플릿화할 수 있다.
두 Daemon이 같은 파일을 수정할 가능성이 있는 경우, 현재 Daemons가 충돌 처리 방식을 명확히 공개하지 않으므로 각 Daemon의 deny 규칙을 최대한 좁게 정의하거나 additive-only(추가만 허용) 방식으로 설계해 충돌 가능성을 원천 차단하는 것이 안전하다.

Code Example

snippet

# .agents/daemons/issue-labeler/DAEMON.md 예시
---
name: issue-labeler
purpose: Ensures every Linear issue has the correct labels from the type and touchpoint label groups.
watch:
  - when a Linear issue is created
routines:
  - add missing labels to a new Linear issue
  - find issues with missing labels and add them
deny:
  - remove labels from issues
  - replace or change existing labels on issues
  - comment on issues
  - change issue status, priority, assignee, or any field other than labels
schedule: "0 2 * * *"
---
## Policy
- Only add labels. Never remove, replace, or overwrite existing labels.
- If an issue already has a label from a group, do not touch that group.
- Apply the single best-fit label from each missing group.

## Limits
- On issue-created events, process only the triggering issue.
- On the daily sweep, label at most 20 issues per activation.

---

# .agents/daemons/pr-helper/DAEMON.md 예시
---
name: pr-helper
purpose: Keeps PRs review-ready.
watch:
  - when a pull request is opened
  - when a pull request is synchronized
routines:
  - suggest PR description improvements
  - flag missing reviewer context
deny:
  - merge pull requests
  - push to protected branches
schedule: "0 9 * * *"
---
## Policy
Focus on short, actionable feedback.

## Output format
1. Findings
2. Suggested edits
3. Questions for author

Terminology

Daemon유닉스에서 유래한 용어로, 사람이 직접 실행하지 않아도 백그라운드에서 스스로 돌아가는 프로세스. 여기서는 AI가 저장소 상태를 감시하다 자동으로 유지보수 작업을 수행하는 자율 에이전트를 의미한다.

operational debt기술 부채(technical debt)와 유사한 개념으로, 코드 자체가 아닌 PR 관리, 이슈 정리, 문서 업데이트, 의존성 패치 등 '운영'과 관련된 작업이 누적되어 팀의 속도를 떨어뜨리는 상태를 말한다.

frontmatterMarkdown 파일 맨 위에 `---`로 감싼 YAML 형식의 메타데이터 영역. 파일의 구조적 설정값을 기계가 읽기 쉬운 형태로 선언하는 곳이다.

watch conditionDaemon이 언제 깨어나 동작을 시작할지 결정하는 트리거 조건. 'PR이 열렸을 때', 'Linear 이슈가 생성됐을 때' 같은 이벤트를 감시한다.

drift코드, 문서, 이슈 등이 시간이 지나면서 실제 상태와 어긋나거나 노후화되는 현상. Daemon이 탐지하고 수정하려는 대상이다.

git worktree하나의 git 저장소에서 여러 작업 디렉토리를 동시에 체크아웃해 독립적으로 작업할 수 있게 해주는 기능. 여러 에이전트가 같은 저장소에서 충돌 없이 병렬 작업할 때 활용된다.