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
관련 논문
Meta AI 챗봇 악용으로 Instagram 계정 20,000개 이상 해킹 확인
Meta의 AI 챗봇에 있던 이메일 검증 버그로 인해 2FA(2단계 인증)를 사용하지 않던 Instagram 계정 2만 개 이상이 약 2개월간 해킹됐다. AI를 계정 복구 시스템에 통합할 때 발생할 수 있는 보안 취약점의 실제 사례다.
Anthropic의 오픈소스 AI 기반 취약점 자동 탐지 프레임워크 공개
Anthropic이 Claude를 활용해 코드 취약점을 자율적으로 탐지·트리아지·패치하는 오픈소스 레퍼런스 구현체를 공개했다. 실제 보안팀과의 협업 경험을 바탕으로 만들어진 파이프라인이라 실전 적용성이 높다.
에이전트는 스스로 물러날까? LLM 에이전트의 In-Band Access-Deny 신호 준수 측정
서버가 SSH 배너나 DB NOTICE로 'AI 에이전트는 접근하지 마세요' 신호를 보내면 GPT-4o, Claude Code 같은 LLM 에이전트가 실제로 물러나는지 실험으로 측정했다.
ToolChoiceConfusion: 신뢰할 수 있는 LLM 에이전트를 위한 Causal Minimal Tool Filtering
LLM 에이전트에 도구를 100개 다 보여주지 말고, 지금 당장 필요한 것 1개만 보여주면 성공률은 그대로에 토큰은 90% 절약된다.
AI Agent를 위한 TDD(테스트 주도 개발) Skill 만들기
AI 에이전트가 형편없는 테스트를 작성하는 문제를 해결하기 위해, Kent Beck의 Canon TDD 원칙을 'Skill'로 만들어 에이전트에게 주입하는 방법을 공유한다. 에이전트 코딩에서 테스트 품질을 높이고 싶은 개발자에게 실용적인 접근법을 제시한다.
Paseo – 오픈소스 코딩 에이전트 통합 인터페이스 (모바일/데스크탑/CLI 지원)
Claude Code, Codex, GitHub Copilot 등 여러 코딩 에이전트를 하나의 UI로 제어하는 오픈소스 프로젝트로, 로컬 데몬 방식으로 자기 머신에서 실행하면서 모바일에서도 접근할 수 있다.