Daemons – AI Agent가 만든 운영 부채를 자동으로 청소하는 백그라운드 프로세스
Show HN: Daemons – we pivoted from building agents to cleaning up after them
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
# .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 authorTerminology
관련 논문
adamsreview: Claude Code용 멀티 에이전트 PR 코드 리뷰 파이프라인
Claude Code에서 최대 7개의 병렬 서브 에이전트가 각각 다른 관점으로 PR을 리뷰하고, 자동 수정까지 해주는 오픈소스 플러그인이다. 기존 /review나 CodeRabbit보다 실제 버그를 더 많이 잡는다고 주장하지만 커뮤니티에서는 복잡도와 실효성에 대한 회의론도 나왔다.
Claude를 User Space IP Stack으로 써서 Ping에 응답시키면 얼마나 빠를까?
Claude Code에게 IP 패킷을 직접 파싱하고 ICMP echo reply를 구성하도록 시켜서 실제로 ping에 응답하게 만든 실험으로, 'Markdown이 곧 코드이고 LLM이 프로세서'라는 아이디어를 네트워크 스택 수준까지 밀어붙인 재미있는 사례다.
AI Agent를 위한 Git: re_gent
AI 코딩 에이전트(Claude Code 등)가 수행한 모든 툴 호출을 자동으로 추적하고, 어떤 프롬프트가 어느 코드 줄을 작성했는지 blame까지 가능한 버전 관리 도구다.
Agent-Native CLI를 위한 설계 원칙 10가지
AI 에이전트가 CLI 도구를 더 잘 사용할 수 있도록 설계하는 원칙들을 정리한 글로, 에이전트가 CLI를 도구로 활용하는 빈도가 높아지면서 이 설계 방식이 실용적으로 중요해지고 있다.
Agent-harness-kit: MCP 기반 멀티 에이전트 워크플로우 오케스트레이션 프레임워크
여러 AI 에이전트가 서로 역할을 나눠 협업할 수 있도록 조율하는 scaffolding 도구로, Vite처럼 설정 없이 빠르게 멀티 에이전트 파이프라인을 구성할 수 있다.
Tilde.run – AI Agent를 위한 트랜잭션 기반 버전 관리 파일시스템 샌드박스
AI 에이전트가 실제 프로덕션 데이터를 건드려도 롤백할 수 있는 격리된 샌드박스 환경을 제공하는 도구로, GitHub/S3/Google Drive를 하나의 버전 관리 파일시스템으로 묶어준다.