AI 에이전트 7개가 우리의 밤을 돌립니다: 코딩 너머의 예약 에이전트, 프롬프트까지 공개

9월 23일, Rob이라는 사용자가 우리 공개 백로그에 이렇게 썼습니다: "would love to get examples of how you guys are doing stuff beyond coding"(코딩 말고 다른 일은 어떻게 하는지 예시를 보고 싶어요). 좋은 질문입니다. 이 사이트의 모든 글이 코딩 에이전트 이야기인데, 우리가 매일 저녁 실제로 돌리는 것은 대부분 코딩이 아닙니다.

8월 28일부터 에이전트 7개가 20:00에 Mac mini에서 시작됩니다. 그날의 커밋, Search Console, 관리자 대시보드, 백로그, 사용자들이 보낸 피드백, 전날 밤의 보고서를 읽습니다. 버그를 고치고, 웹사이트를 수정하고, 사흘마다 블로그 글을 쓰고 번역하고, 소셜 네트워크 세 곳에 게시하고, 제품 지식 베이스를 업데이트합니다. 그리고 22:00에 일곱 번째 에이전트가 나머지 여섯이 남긴 것을 읽고 25줄짜리 이메일을 보냅니다. 아무도 지켜보지 않습니다. 창업자는 다음 날 아침 휴대폰으로 그 이메일을 읽습니다.

이 글은 Rob에게 드리는 답입니다. 무엇이 돌아가는지, 어떻게 연결되어 있는지, 에이전트들이 한 번도 대화하지 않고 어떻게 일을 넘기는지, 어떤 모델이 어떤 일을 왜 맡는지, 프롬프트가 호되게 배워야 했던 네 가지 규칙, 그리고 복사할 수 있는 블록으로 압축한 프롬프트 자체까지. 아래의 모든 숫자는 저장소에서 나왔습니다: 보고서가 밤마다 그곳에 커밋되어 있습니다.

33번의 밤이 만든 것

저장소의 보고서 폴더에는 8월 28일부터 9월 30일까지 날짜가 붙은 디렉터리가 33개 있습니다. 읽어 보면 이렇습니다:

• 보고 담당이 보낸 아침 이메일 31통.
• 수정 담당이 고친 버그 51건. 각각 보고서 줄에 커밋 링크가 달려 있습니다. 몇몇은 사용자가 공개 백로그에 신고한 것이었고, 다음 릴리스 때 답장을 받았습니다.
• 9월 10일부터 SEO 팀이 쓴 블로그 글 7편. 사흘에 한 편씩, 먼저 영어와 프랑스어로 쓰고, 같은 날 밤 18개 언어로 더 옮겼습니다.
• 29일치 소셜 미디어 일지: 매일 저녁 네트워크 세 곳과 Facebook 그룹 다섯 곳, 그리고 사용자가 AgentsRoom을 공유한 모든 게시물 아래에 남긴 감사 댓글.
• 약 100장의 팩트 시트로 이루어진 제품 지식 베이스. 그날의 커밋에 맞춰 최신 상태로 유지되며, 앱 안의 어시스턴트가 읽고 사이트가 llms-full.txt로 제공합니다.

이 중 어느 것도 20:00 이후에 사람을 필요로 하지 않았습니다. 일부는 08:00에 사람을 필요로 했고, 그것이 바로 마지막 에이전트가 있는 이유입니다.

명단: 20:00에 누가 도는가

모든 에이전트는 AgentsRoom의 예약 작업입니다: 프롬프트, 에이전트(역할, CLI, 모델), 머신, 그리고 시각. 7개 모두 Claude Code로 돌아갑니다. 그중 2개는 단일 에이전트가 아니라 2단계 팀인데, 그 이유는 뒤에서 다시 다룹니다.

마지막 열의 .md 파일은 모두 reports/night/<date>/에 있고, 커밋되고 푸시됩니다. 이 폴더가 조율 시스템의 전부이며, 다음 섹션에서 그 이유를 설명합니다.

어떻게 연결되어 있는가

7개 모두 같은 모양의 예약 작업입니다:

• 매일 20:00에 발동(보고 담당은 22:00). cron 표현식은 없고, 빈도는 편집기에서 고릅니다.
• 머신 한 대에 고정. 프로젝트는 여러 컴퓨터에 열려 있고, 제한하지 않으면 트리거는 그 프로젝트가 있는 모든 머신에서 발동합니다. 우리 트리거는 Mac mini로 제한되어 있어서, 20:05에 연 노트북이 두 번째 CEO를 시작하지 않습니다.
• 머신을 깨움. Mac mini는 잠자기에 들어갑니다. 작업에는 ‘머신 깨우기’ 옵션이 있어, 실행 몇 초 전에 운영체제 자체 도구(macOS는 pmset, Windows는 절전 해제 옵션을 켠 작업 스케줄러, Linux는 rtcwake)로 깨우기를 예약합니다. 이 옵션이 없으면 잠든 머신은 그냥 실행을 놓칩니다.
• 따라잡기는 작업마다 켜거나 끔. 20:00에 머신이 꺼져 있었다면, 따라잡기가 켜진 작업은 다음 실행 시 발동합니다. CEO, PM, 보고 담당은 켜져 있습니다. SEO, 수정 담당, 소셜, 문서 작업은 꺼져 있습니다: 다음 날 오전 11:00에 시작하는 실행은 같은 체크아웃에서 그날의 작업과 부딪히기 때문입니다.
• 권한 모드는 작업에 설정하고, provider에는 설정하지 않습니다. 무인 실행은 새벽 3시에 승인 요청에서 멈출 수 없으므로 작업은 승인 없이 돌고, 창업자가 같은 CLI에서 직접 조작하는 에이전트들은 여전히 먼저 묻습니다.
• 콘솔은 60분 동안 유휴 상태면 닫힘. 끝난 에이전트가 누군가 닫을 때까지 사이드바에 남아 있지 않습니다.
• 프롬프트가 첫 메시지. 각 프롬프트의 본문은 프롬프트 라이브러리에 저장되어 있고 트리거의 프롬프트 필드와 같은 텍스트여서, 하나를 수정하면 둘 다 수정하는 셈입니다. 프롬프트는 프랑스어로 되어 있습니다. 창업자가 보고서를 프랑스어로 읽기 때문입니다. 그 밖의 모든 것, 커밋 메시지부터 지식 베이스까지는 영어입니다.

일곱 모두가 공유하는 조각이 하나 더 있습니다: ‘야간 에이전트 공통 규칙’이라는 스킬입니다. 모든 프롬프트는 ‘이 스킬을 불러와 적용하라’로 시작하고, 스킬에는 모두에게 참인 것이 전부 들어 있습니다: 누가 무엇을 맡는지, ‘하룻밤에 실행 한 번’ 가드, git 권한, 보고서 형식, 백로그 규칙, 그리고 보고 담당을 위한 이메일 형식. 규칙이 바뀌면 한 곳에서만 바뀝니다.

대화 없이 일을 넘기는 방법

에이전트 7개는 서로 메시지를 보내지 않습니다. 보낼 수는 있습니다. AgentsRoom에는 에이전트 간 메시징이 있습니다. 하지만 메시지는 다음 날 아침이면 보이지 않고 grep할 수도 없습니다. 모든 것은 밤을 넘겨 살아남는 세 가지를 거칩니다:

저장소. 각 에이전트는 reports/night/<date>/<agent>.md를 씁니다. 실행 첫 1분 안에 열고, 일을 하나 끝낼 때마다 다시 쓰고, 커밋하고 푸시합니다. 보고서에는 고정된 섹션이 네 개 있습니다: ‘한마디로’(글머리표 목록, 한 일마다 항목 하나), ‘결정할 것’(프롬프트가 사람에게 남겨 둔 것만), ‘확인할 것’(열어 볼 로컬 URL이나 화면), ‘세부 사항’(필요한 만큼 길게). 마지막은 실행 마커로 끝납니다: 에이전트가 마지막으로 본 커밋입니다.

백로그. 다른 에이전트를 위한 일을 찾은 에이전트는 그 일을 하지 않습니다. 태그를 붙인 티켓을 엽니다: 수정 담당이 가져갈, 검증된 작은 버그에는 ceo-fix, 목표 검색어가 있는 콘텐츠 작업에는 ceo-seo, 사람이 필요한 모든 것(데이터베이스, 결제, 인증, 암호화, 가격, 색인된 URL, 기본 동작)에는 ceo-decision. 문서 담당이 커밋을 읽다가 사이트에 페이지가 없는 기능을 발견하면 ceo-seo 티켓을 올리고, 다음 날 밤 SEO가 가져갑니다. CEO가 오류 로그를 읽다가 원인이 코드에 있는 버그를 찾으면 ceo-fix, 다음 날 밤 수정 담당이 가져갑니다.

어제의 보고서. 어떤 작업이든 시작하기 전에, 각 에이전트는 전날 밤 자기 보고서와 낮 동안 닫힌 티켓 목록을 읽습니다. 어제 지적한 것은 낮 동안 고쳐져 있는 경우가 많습니다. 이미 다룬 주제는 다시 꺼내지 않고, 이미 열린 티켓은 다시 만들지 않습니다.

고리를 닫는 것은 사람입니다. 보고 담당의 이메일은 한 줄로 끝납니다: 프로덕트 매니저에게 답하려면 rapport.md 끝에 ‘## 결정’ 섹션을 추가하고(P1 OK / P2 거절: 이유 / P3 나중에), 커밋하고, 푸시하라. PM은 다음 날 저녁 푸시된 버전을 읽고 승인된 것을 실행합니다: 티켓을 만들고, 중복을 합치고, 나머지는 이유와 함께 보류합니다. 사흘 밤 동안 답이 없는 결정도 하나의 결정입니다: 제안은 이메일에서 빠지고 티켓으로 남습니다.

어떤 모델이 어떤 일을, 왜 맡는가

위 표에는 모델이 두 개 나옵니다. 이것은 현재 구성일 뿐 벤치마크가 아니며, 바뀔 수 있습니다. 하지만 나눈 방식은 의도된 것입니다.

일의 핵심이 판단이면 Fable. CEO는 오라클에 달린 ‘싫어요’가 진짜 오류인지 취향 문제인지 판단합니다. 수정 담당은 버그 신고가 진짜 버그인지 특정 머신만의 설정인지 판단한 뒤, 코드에서 원인을 찾습니다. SEO 1단계는 오늘의 커밋으로 사이트의 어떤 문장이 틀리게 되었는지, 어떤 글을 쓸지, 어떤 페이지는 건드리지 않을지 결정합니다. 소셜 1단계는 그날 저녁의 주제를 고르고, 생성된 글을 세 줄 만에 알아보는 독자를 위해 씁니다. 이 프롬프트들은 길고(SEO 프롬프트는 약 4,000단어) 짧은 예외 목록이 달린 ‘네가 결정하고, 묻지 않는다’ 규칙으로 가득합니다. 가장 강한 모델이 제값을 하는 곳이 여기입니다.

일의 핵심이 분량이면 1M 컨텍스트의 Opus. 하위 에이전트(각각 로케일 세 개)로 글을 18개 언어로 번역한 뒤, 프랑스어 기준본과 대조해 병합을 검사하는 일은 많이 읽고 많이 쓰는 일이며, 같은 규칙을 18번 적용합니다. 문서 담당은 하루치 diff를 약 100장의 팩트 시트와 대조해 읽습니다. PM은 8 MB짜리 이탈 대화 내보내기 파일을 읽습니다. 보고 담당은 보고서 다섯 개를 읽고 옮겨 적을 뿐, 생각하지 않습니다. 거기서는 판단력보다 큰 컨텍스트와 낮은 토큰당 비용이 더 중요합니다.

그래서 7개 중 2개는 2단계로 된 에이전트 팀이고, 각 단계는 자기 모델을 가진 에이전트입니다. Fable에서 도는 1단계는 공유 보고서에 ‘핸드오프’ 섹션을 쓰는 것으로 끝납니다: 번역 담당이 넘겨야 할 파일과 키의 정확한 목록, 또는 게시 담당이 올려야 할 게시물의 정확한 내용입니다. Opus에서 도는 2단계는 그 섹션을 읽고 거기 적힌 것만 합니다. 팀의 그래프는 직선형이고 사이클은 하나이며, 보고서는 2단계가 지울 때까지 ‘실행 중’ 줄을 유지합니다. 밖에서 보면, 22:00에 아직 ‘실행 중’으로 표시된 보고서는 끊긴 실행이거나 두 단계 사이에 있는 팀이고, 보고 담당은 그중 어느 쪽인지 적습니다.

프롬프트가 배워야 했던 네 가지 규칙

처음 프롬프트는 직무 기술서였습니다. 지금 프롬프트는 대부분 규칙이고, 규칙마다 날짜가 있습니다. 하나하나가 잘못된 밤 이후에 쓰였기 때문입니다.

1. 어제 보고서에서 읽는 실행 마커. SEO 에이전트의 첫 버전은 ‘최근 24시간의 커밋’을 읽었습니다. 문제는 두 가지였습니다: 20:00의 실행과 다음 날 20:10의 실행은 같은 24시간을 보지 않고, 에이전트가 돌지 않은 밤은 아무도 보지 않는 하루치 커밋이 됩니다. 이제 모든 보고서는 마지막으로 본 커밋: <sha>로 끝나고, 다음 실행은 시계가 뭐라고 하든 그 커밋에서 시작합니다. 마커가 없으면(첫날 밤, 보고서 누락) 이틀 전부터 보고, 보고서에 그렇게 적습니다.

2. 기록은 디스크에 있다. 그러니 무엇이든 올리기 전에 grep하라. 처음 두 주 동안 가장 자주 돌아온 불만은 ‘그거 이미 말했잖아, 어제 고쳤어’였습니다. 해결책은 명령어가 들어간 규칙입니다: 주제를 지적하거나 작업을 시작하기 전에 grep -ril "<주제>" reports/night/와 git log --since="30 days ago" -- <파일>. 일치하는 것이 있으면 그 보고서부터 읽습니다. 이미 다룬 주제를 다시 꺼내도 되는 경우는 세 가지, 오직 세 가지입니다: 수정이 효과가 없었고 방금 그것을 검증했을 때, 수정이 부분적이고 남은 것을 명시할 때, 주제의 성격이 바뀌었을 때. 여기에 두 가지 따름 규칙이 붙었습니다. 하룻밤에 실행 한 번: 오늘 밤 보고서가 있고, ‘한마디로’를 포함하며, 더 이상 ‘실행 중’이라고 적혀 있지 않으면 에이전트는 멈춥니다. 그리고 사흘 밤 동안 답이 없는 제안은 보고서에서 빠지고, 티켓은 남습니다.

3. 보고서는 일을 시작하기 전에 연다. 예전에는 21:30에 끊긴 실행이 아무것도 남기지 않았습니다. 이제 스킬을 불러온 뒤 에이전트가 가장 먼저 하는 일은 mkdir -p reports/night/$(date +%F)를 실행하고, 섹션 제목 네 개와 실행 중, 20:01 시작이라는 줄이 있는 보고서 뼈대를 쓰는 것입니다. 작업을 하나 끝낼 때마다 파일 전체를 다시 씁니다. 끊긴 실행은 보고 담당이 옮겨 적을 수 있는 부분 보고서를 남기고, 이는 ‘돌지 않은’ 에이전트보다 훨씬 낫습니다.

4. 진행하면서 커밋하고, 절대 마지막에 몰아서 하지 않는다. 9월 9일에 측정했습니다: 에이전트 두 개가 같은 분에 멈췄습니다. 작업마다 커밋하던 쪽은 아무것도 잃지 않았습니다. 다른 쪽은 수정되고 푸시되지 않았으며 누구 것인지 알 수 없는 파일 45개를 남겼고, 창업자가 다음 날 아침 손으로 수습했습니다. 그 에이전트의 보고서는 존재하지 않았습니다. 그 뒤로 규칙은 끝낸 작업마다 커밋 하나, 파일은 하나씩 이름으로 지정, 보고서를 위한 마지막 커밋, 그리고 실행 중 최소 한 번의 푸시입니다. 커밋은 날짜가 찍힌 흔적이기도 하고, 규칙 2가 grep하는 것이 바로 그것입니다.

다섯 번째 규칙은 기억이 아니라 용기에 관한 것이고, 결과물을 가장 크게 바꾼 규칙입니다. SEO 프롬프트에는 이렇게 적혀 있습니다: ‘너는 발견 사항을 보고하는 감사관이 아니다. 밤 동안 사이트는 너의 것이다. 검토할 단서 여섯 개로 끝나는 실행은 실패한 실행이다.’ 이어서 에이전트가 행동하는 대신 물어야 하는 여섯 가지 경우, 오직 여섯 가지를 나열합니다: URL 삭제나 이름 변경, 순위가 잡힌 페이지의 제목 변경, 법률 문구, 가격이나 할당량, 개인정보나 암호화에 관한 주장, 다섯 페이지를 넘게 건드리는 변경. 나머지는 모두 실행하고, 창업자가 다음 날 아침 마음에 들지 않는 것을 걷어 냅니다. 수정 담당도 세 가지 경우를 둔 같은 규칙이 있습니다. 이 규칙 전에는 보고서가 제안 목록이었습니다. 이 규칙 후에는 커밋 목록입니다.

프롬프트

원본은 프랑스어이고 깁니다. 아래는 옮겨 쓸 수 있는 부분이며, 우리 프로젝트 고유의 경로와 이름은 빼 두었습니다. 블록 세 개: 모든 에이전트가 불러오는 공통 규칙, 보고 담당, 그리고 ‘네가 결정하고, 묻지 않는다’ 섹션 두 개입니다.

블록 1: 공통 규칙(일곱 모두가 스킬로 불러옴)

# 야간 에이전트: 공통 규칙
너의 프롬프트와 어긋나면 이 규칙이 우선한다.

## 하룻밤에 실행 한 번
DAY=$(date +%F); F=reports/night/$DAY/<너>.md
F가 존재하고, "한마디로"를 포함하며, 더 이상 "실행 중"을 포함하지 않으면:
멈춘다. 아무것도 쓰지 않고, 아무것도 보내지 않고, 한 줄 메시지로 끝낸다.
아직 "실행 중"이라고 되어 있으면: 몇 분 전에 끊긴 너 자신의 실행이다.
멈춘 곳에서 다시 이어 가고, 처음부터 다시 시작하지 않는다.

## 해도 되는 것
- Git: add <이름을 지정한 파일>, commit, 너 자신의 작업 push, 진행하면서.
  금지: add -A, commit -a, push --force, stash, reset, checkout, clean, 새 브랜치.
- 빌드: typecheck, lint, 검사 스크립트, 확인용 로컬 빌드.
  금지: 배포하거나 게시하는 모든 스크립트.
- 백로그: 티켓 만들기, 티켓에 덧붙이기, 네가 고친 티켓 닫기.
  금지: 사용자에게 답장(이메일이 발송된다), 티켓 삭제, 설명 덮어쓰기.
- 지어낸 숫자는 절대 쓰지 않는다. 출처를 쓸 수 없으면 그렇다고 말하고 넘어간다.
- git에 쓰기 전에는 항상: git status --short. 트리는 다른 에이전트와 공유한다.

## 따라잡고, 이미 끝난 일을 알기
git fetch && git status -sb
뒤처졌고 깨끗함: git pull --ff-only. 뒤처졌고 변경 사항 있음: pull하지 말고, 보고서 맨 위에 그렇게 적는다.
너의 실행 마커: 어제 보고서 끝의 "마지막으로 본 커밋: <sha>" 줄.
마커가 없으면: --since="2 days ago", 그리고 그렇게 적는다.
분석 전에 반드시 읽을 것 세 가지:
1. git log --no-merges --format='%h %s' <sha>..HEAD 및 git diff --stat <sha>..HEAD
2. 어제 이후 닫힌 티켓, 그리고 사람이 보류해 둔 티켓
3. 어제 너 자신의 보고서: "한마디로"와 "결정할 것"

## 보고서 폴더가 곧 너의 기록이다
발견 사항을 올리거나 작업을 시작하기 전에:
grep -ril "<주제>" reports/night/ | sort | tail -5
git log --since="30 days ago" --oneline -- <파일>
일치하는 것이 있으면: 무엇이든 결정하기 전에 그 보고서를 읽는다.
같은 주제로 이틀 밤 연속: 두 번째 밤은 낭비다.
네가 손댄 페이지나 글은 3주 동안 다시 건드리지 않는다.
틀리게 된 것을 고치는 경우는 예외.

## 같은 것을 두 번 올리지 않는다
이미 처리된 발견 사항이 다음 날 다시 나오는 것은 잘못이다.
허용되는 경우는 세 가지뿐:
1. 수정이 효과가 없었고, 방금 검증했다: "<date>에 <commit>로 수정됨, 여전히 고장: <증거>"
2. 수정이 부분적이다: 남은 것을 정확히 명시한다
3. 주제의 성격이 바뀌었다: 새 원인, 새 측정치, 새 범위
누적 총량을 다시 세지 않는다. 변화량을 보고하고, 총량은 절대 보고하지 않는다.

## 답이 없는 제안은 사흘 밤 뒤에 사라진다
1~3번째 밤: 그 줄에 횟수와 처음 올린 날짜를 붙인다("2번째 밤, 9/7 제기").
4번째 밤부터: "결정할 것"에서 뺀다. 티켓은 남고, "세부 사항"에는 많아야 한 줄.
결정이 네 권한 안에 있으면, 3번째 밤에 결정하고 그렇게 적는다.

## 진행하면서 커밋하고 푸시하기
첫 작업이 끝나고 검증되면 바로 첫 커밋. 그다음은 작업마다 하나.
마지막 커밋은 너의 보고서를 위한 것. 실행 중 최소 한 번, 끝날 때 한 번 푸시한다.
푸시 거부(원격이 앞서 나감): git pull --ff-only, 그다음 push. 그래도 거부되면: force하지 않고,
rebase하지 않고, 보고서에 적는다.

## 너의 보고서: 시작할 때 열고, 끝에서만 쓰지 않는다
reports/night/<YYYY-MM-DD>/<너>.md, 작업 "전에" 만들며, 내용은:
  # <Agent> - <date>
  _실행 중 - <HH:MM> 시작_   (끝나면 삭제)
  ## 한마디로          (3~5줄, 또는 글머리표 목록: 한 일마다 항목 하나)
  ## 결정할 것         (프롬프트가 사람에게 남겨 둔 것만; 없으면 "없음")
  ## 확인할 것         (- [ ] 무엇 : 어디서 : 무엇이 보여야 하는지; 없으면 "없음")
  ## 세부 사항         (필요한 만큼 길게: 증거, 파일, 명령어)
  ## 실행 마커
  마지막으로 본 커밋: <마지막 커밋 후의 git rev-parse HEAD>
작업을 하나 끝낼 때마다 파일 전체를 다시 쓴다.
독자는 휴대폰으로 2분 동안 읽는다: 짧은 문장, 첫 섹션에는 파일 경로도,
SHA도, 함수 이름도 넣지 않는다. 숫자는 결정을 바꿀 때만.

블록 2: 보고 담당(22:00)

너는 보고 담당이다. 다른 에이전트들보다 두 시간 뒤에 돈다.
너의 유일한 일: 그들이 남긴 것을 읽고, 창업자가 휴대폰으로 1분 안에 읽고
다른 것을 아무것도 열지 않고 이해할 수 있는 이메일을 딱 한 통 보낸다.
아무것도 분석하지 않고, 아무것도 고치지 않고, 아무것도 제안하지 않는다. 모으고 명료하게 만든다.

보고할 밤은 시계가 아니라 디스크에서 읽는다:
DAY=$(ls -1 reports/night | sort | tail -1)

1. git fetch; 트리가 깨끗하면 git pull --ff-only: 보고서는 커밋되어 있다.
2. ls reports/night/$DAY: 파일 다섯 개(ceo, seo, pm, fixer, social)를 기다린다.
   빠진 것이 있으면: 9분 sleep 후 다시 센다, 최대 6회. 그다음 누가 빠졌는지 적고 그래도 보낸다.
3. 아직 "실행 중"이라고 적힌 보고서는 끊긴 실행이지, 없는 실행이 아니다.
   내용을 옮겨 적고, "잘 안 된 것"에 그 에이전트가 끊겼다고 쓴다.
4. 각 보고서에서 세 섹션만 가져온다: "한마디로", "결정할 것", "확인할 것".
   "세부 사항"은 절대 인용하지 않는다.
5. 수정 담당의 수정된 버그는 " > "로 구분된 세 부분짜리 글머리표다:
   사용자가 겪은 문제 > 원인 한 문장 > 커밋 URL.
   링크까지 포함해 글자 하나 바꾸지 말고 "수정된 버그"에 옮긴다.
6. git status -sb 및 git log --oneline --since="4 hours ago": 커밋 없이 작업했다고 주장하는 보고서,
   아무도 자기 것이라고 하지 않는 수정된 파일, 푸시되지 않은 커밋: 이메일의 첫 줄.

reports/night/$DAY/rapport.md를 쓴다. 본문은 최대 25줄
(섹션 제목과 "수정된 버그" 줄은 세지 않는다).
여섯 가지 규칙을 한 줄씩 적용한다:
1. 항목 하나 = 혼자서도 이해되는 완결된 문장 하나. "어제 말한 대로"는 절대 금지.
2. 한 주제는 딱 하나의 섹션에만 나온다.
3. 전문 용어 제로: 경로도, SHA도, 키 이름도, 내부 약어도 없다.
   예외 하나: 커밋의 전체 GitHub URL, "수정된 버그"의 모든 줄에 필수.
4. 숫자는 결정을 바꿀 때만, 그리고 변화량이지 총량이 아니다.
5. 항목 하나는 최대 두 줄. 세부 내용은 에이전트의 보고서에 있다.
6. 나쁜 소식을 좋은 소식보다 먼저, 첫 줄은 무언가 고장 났는지 말한다.

섹션 순서: 결정할 것 / 확인할 것 / 수정된 버그 / 한 일 /
소셜 네트워크(최대 3줄, 링크 포함) / CLI와 모델(1줄) /
잘 안 된 것. 빈 섹션은 한 단어: "없음".
절대 자르지 않는 것: "결정할 것", 링크가 달린 "수정된 버그", 게시물 링크, SEO 글.
보낸다. HTTP 코드를 확인한다. 맨 아래에 "발송 대상 ... - HTTP <code>"를 덧붙인다.
rapport.md를 커밋하고 푸시한다. 절대 두 번 보내지 않는다: 오늘의 rapport.md에 이미
"발송 대상" 줄이 있으면 멈춘다.

블록 3: ‘네가 결정하고, 묻지 않는다’ 섹션

SEO 에이전트, 프롬프트의 섹션 0:

# 0. 네가 결정하고, 묻지 않는다
이것은 이 프롬프트에서 가장 중요한 규칙이며, 조심하려는 너의 반사 작용보다 우선한다.
너는 발견 사항을 보고하는 감사관이 아니다. 밤 동안 사이트는 너의 것이다.
"단서 6개를 찾았습니다, 검토 부탁드립니다"로 끝나는 실행은 실패한 실행이다.
망설여지면 창업자의 자리에 서서 네 가지 기준으로 결정한다:
- 제품이 실제로 하는 일. 저장소와 공개된 버전에서 읽고, 기존 카피에서 읽지 않는다.
- 사이트가 이미 말하는 것: 그 관점, 그 어조, 그 약속. 넓혀 가되 새로 만들지 않는다.
- Search Console이 말하는 것: 어떤 페이지가 살아 있는지, 어떤 검색 의도가 실제로 존재하는지.
- 독자: Google에서 검색하는 개발자, 그리고 도구를 추천하는 AI 어시스턴트.
  그들에게 중요한 것: 검증할 수 있고 날짜를 특정할 수 있는 주장, 하나의 정확한 질문에 답하는 페이지,
  페이지와 일관된 최신 llms.txt, 정직한 비교.
창업자는 다음 날 아침 너의 보고서를 읽고 마음에 들지 않는 것은 빼라고 말할 것이다.
불필요한 수정 하나의 비용은 5분이고, 아무것도 만들지 않은 밤은 영원히 잃는다.

그의 의견을 묻는 것은 다음 여섯 가지 경우뿐이다:
1. 기존 URL의 삭제 또는 이름 변경;
2. 순위가 잡힌 페이지의 제목이나 메타 설명 변경(그것이 틀리지 않은 경우);
3. 법률 문구(약관, 개인정보, 라이선스);
4. 가격, 상업적 할당량, 요금제 제안;
5. 개인정보, 암호화, 데이터가 어디서 처리되는지에 관한 주장;
6. 한 번에 다섯 페이지를 넘게 건드리는 변경.
이 여섯 가지 경우: 결정용 태그를 단 티켓, "결정할 것"에 한 줄, 그리고 다음으로 넘어간다.
나머지는 전부 오늘 밤 한다. "결정할 것"에 다른 것이 들어 있다면,
너의 몫이었던 결정을 남에게 떠넘긴 것이다.

수정 담당, 프롬프트의 섹션 0:

# 0. 고치고, 분류하지 않는다
사용자가 신고한 버그는 약속이다. 누군가 시간을 내어 썼고, 기다리고 있으며,
오늘 밤 다른 누구도 그것을 처리하지 않는다. "버그 5건 분석, 1건 수정,
4건 문서화"를 내놓는 실행은 실패한 실행이다. 너의 목표는 빈 대기열이다: 사용자의 버그 먼저,
오래된 것부터, 그다음 나머지를, 하나도 남지 않을 때까지.
수정 방법에서 망설여지면 세 가지 기준으로 결정한다:
- 오늘 코드가 하는 일. 짐작하지 말고 읽어서 확인한다.
- 신고를 쓸 때 사용자가 분명히 기대했던 것.
- 가장 적은 위험: 원인을 해결하는 가장 좁은 수정. 가장 우아한 수정이 아니다.
논란의 여지가 있는 수정은 되돌리는 데 5분이 들고, 한 달 더 방치된 버그는 사용자 한 명을 잃게 한다.

신고된 버그를 수정 없이 남겨도 되는 것은 다음 세 가지 경우뿐이며, 티켓 안에서 증명한다:
1. 제대로 조사했는데도 원인을 찾지 못했다: "재현 불가"만 쓰지 말고,
   무엇을 배제했는지 쓴다;
2. 버그가 아니라 결정 사항이다: 데이터베이스, 결제, 인증, 암호화, 개인정보,
   색인된 URL, 기본 동작. 너의 권고를 담아 결정용 티켓을 만든다;
3. 게이트가 너의 수정을 거부하고, 그것을 고칠 수 없다.
"크다", "여러 파일을 건드린다", "물어보는 게 낫겠다"는 이유가 아니다.
버그 하나 = 커밋 하나. 그다음 티켓을 완료로 옮기고, 사용자가 신고한 것이면
다음 릴리스와 함께 나갈 두 문장짜리 메시지를 준비한다. 절대 "대기 중"에 두지 않는다: 그 열은
사람의 것이다.
수정한 버그마다 쓰는 보고서 줄, 아침 이메일에 그대로 옮겨진다:
- <사용자가 겪은 문제> > <원인, 간단한 한 문장> > <커밋 URL>

나머지 네 개의 프롬프트(CEO, PM, 문서 담당, SEO 2단계)도 같은 뼈대를 따릅니다: 스킬을 불러오고, 써도 되는 파일을 지정하고, 읽을 것을 순서대로 나열하고, 무엇이 티켓에 들어가고 무엇이 보고서에 들어가는지 말하고, 실행 마커로 끝냅니다.

잘 안 된 것, 그리고 아직도 안 되는 것

몇몇 밤은 이메일의 ‘잘 안 된 것’ 섹션에 올라 있습니다. 여러분도 부딪힐 일이니 나열해 둘 가치가 있습니다.

• 에이전트 다섯 개가 같은 분에 같은 브랜치로 푸시. 원격이 앞서 나가서 푸시가 거부됩니다. 규칙은 git pull --ff-only 후 푸시, force는 절대 하지 않으며, 두 번 실패하면 보고서에 그렇게 적고 아침에 사람이 푸시합니다. 대략 일주일에 한 번 일어납니다.
• 다른 에이전트가 스테이징한 파일을 쓸어 담은 커밋. 9월 29일, SEO의 첫 커밋에 문서 담당이 공유 체크아웃에서 스테이징해 둔 삭제가 딸려 들어갔습니다. 잃은 것은 없었지만(삭제는 의도된 것이었습니다), 그 커밋은 엉뚱한 에이전트의 것으로 기록되어 있습니다. 그 뒤로 모든 커밋은 명시적인 경로 지정을 쓰며, ‘파일은 하나씩 이름으로 지정’ 규칙은 스타일 취향이 아닙니다.
• 20:10에 디스크 여유 공간이 0바이트로, 이틀 저녁 연속. 에이전트와 무관했고, 20:25에 저절로 회복되었으며, 잃은 파일은 없었습니다. 그래도 보고서에는 적힙니다. 디스크가 가득 찬 밤은 에이전트가 아무것도 하지 않은 밤과 똑같아 보이기 때문입니다.
• 오지 않을 보고서를 54분 동안 기다리는 보고 담당. 9분씩 여섯 번이 상한입니다. 22:00에 두 단계 사이에 있는 팀은 끊긴 실행처럼 보이고, 이메일에는 ‘끝나지 않았음’이라고 적힙니다. 정직하지만 읽기에는 조금 불안합니다.
• 같은 지적이 되풀이되던 첫 몇 주. 위의 규칙 2는 창업자가 ‘사흘 전에 말했잖아’라고 네 번째로 쓰기 전까지는 없었습니다.

직접 구성하는 방법

에이전트 7개가 필요하지 않습니다. 여러분이 읽을 보고서를 쓰는 에이전트 하나면 됩니다. 보고 담당은 세 번째 에이전트부터 쓸모가 있습니다. AgentsRoom에서는:

1. 프롬프트 라이브러리에 프롬프트를 씁니다. 위의 블록 1을 스킬로 두고, 이 에이전트가 무엇을 맡고 어떤 파일을 써도 되는지 말하는 짧은 프롬프트로 시작하세요.
2. 프로젝트에 예약 작업을 만듭니다: 원하는 시각에 매일, 에이전트의 역할, CLI, 모델, 프롬프트, 그리고 고급 블록에서 무인 실행을 위한 권한 모드. 실행할 머신에 고정하고, 그 머신이 잠자기에 들어간다면 ‘머신 깨우기’를 켜세요.
3. 저장소에 reports/night/ 폴더를 만들고 커밋합니다. 이것이 조율 계층의 전부입니다.
4. 첫 에이전트가 다른 누군가를 위한 티켓을 만들기 시작하는 날, 두 번째 에이전트를 추가합니다: ceo-fix 태그는 다음 날 밤 수정 담당이 그것을 읽을 때에만 의미가 있습니다.
5. 한 가지 일이 판단과 분량으로 나뉘면, 모델 두 개를 쓰는 2단계 팀으로 만들고, 1단계가 2단계가 읽을 핸드오프 섹션을 쓰게 하세요.

예약 작업 페이지에서 각 필드를 설명하고, 코딩 에이전트를 야간 근무에 투입하는 글은 이 명단 이전에 있었던 생각을 담고 있습니다. 에이전트들이 머신 한 대를 공유한다면 먼저 에이전트 열 개가 같은 명령을 실행하면 무슨 일이 일어나는지를 읽어 보세요: 여기서 밤에 실제로 일어난 일이고, 해결책은 작은 공유 잠금입니다.

Rob, 이것이 우리가 코딩 너머에서 하는 일입니다. 프롬프트가 곧 제품입니다.

자주 묻는 질문

이렇게 에이전트를 예약 실행하려면 AgentsRoom이 필요한가요?

아닙니다. cron 한 줄과 claude -p만 있으면 어떤 머신에서든 20:00에 Claude Code 세션을 시작할 수 있습니다. 그다음 직접 작성해야 하는 것은 나머지 부분입니다: 잠든 컴퓨터 깨우기, 머신이 놓친 실행 따라잡기, 프로젝트가 두 컴퓨터에 열려 있을 때 하룻밤에 실행을 한 번으로 유지하기, 한 에이전트의 보고서를 다른 모델로 도는 두 번째 에이전트에 넘기기, 그리고 실행이 질문에 막혀 있다는 것을 휴대폰에서 확인하기. AgentsRoom의 예약 작업이 이 조각들을 담당하며, 이 글의 에이전트 7개는 그 모두를 사용합니다. 무엇이 세션을 시작하든, 프롬프트와 규칙은 그대로 옮길 수 있습니다.

에이전트 7개를 하룻밤 돌리면 비용이 얼마인가요?

AgentsRoom에서 시작하는 다른 에이전트와 마찬가지로 Claude 구독 위의 Claude Code 세션으로 돌기 때문에 토큰당 청구서가 없고, 밤마다의 비용은 공개하지 않았습니다. 비용을 묶어 두는 규칙은 ‘하룻밤에 실행 한 번’ 가드입니다: 두 번 발동한 트리거나, 중간에 끊겼다가 다시 시작된 실행이 같은 일을 반복하지 않습니다. 각 에이전트가 가장 먼저 하는 일이 오늘 밤 보고서가 이미 있고 닫혀 있는지 확인하는 것이기 때문입니다.

아무도 보지 않는 동안 에이전트가 커밋하고 푸시하게 해도 안전한가요?

안전한 이유는 무엇을 원하라고 들었는지가 아니라 무엇이 금지되어 있는지에 있습니다. 공통 규칙은 git add -A, commit -a, 강제 푸시, stash, reset, checkout, clean, 브랜치 생성, 그리고 배포하는 모든 스크립트를 금지합니다. 모든 커밋은 파일을 하나씩 이름으로 지정하고, 쓰기 전에는 반드시 git status로 트리를 확인하며, 원격이 앞서 나가서 거부된 푸시는 fast-forward pull로 해결하거나 사람에게 맡깁니다. 아침 리뷰는 그날 밤의 커밋 목록이고, 잘못된 것이 있으면 5분짜리 revert로 끝납니다.

왜 에이전트들은 대시보드 대신 저장소에 Markdown 보고서를 쓰나요?

보고서가 곧 기억이기 때문입니다. 각 에이전트는 전날 밤 자기 보고서를 읽는 것으로 시작해 거기서 실행 마커(마지막으로 본 커밋)를 찾고, 무엇이든 올리기 전에 보고서 폴더 전체를 grep합니다. 그래서 지난주에 다룬 주제가 다시 올라오지 않습니다. 대시보드는 같은 숫자를 보여 줄 뿐 아무것도 기억하지 못합니다. 보고서를 커밋하면 날짜도 찍히고, 덕분에 다음 날 밤은 전날 밤이 무엇을 건드렸는지 정확히 알 수 있습니다.

왜 7개 중 2개는 서로 다른 두 모델로 도는 2단계 팀인가요?

일의 두 절반이 같은 종류의 일이 아니기 때문입니다. Search Console을 읽고, 사이트에서 무엇이 틀리게 되었는지 판단하고, 글을 영어와 프랑스어로 쓰는 SEO 단계는 판단력이 필요하고 Fable에서 돌아갑니다. 그 글을 다른 18개 언어로 번역하고 i18n 게이트와 빌드를 돌리는 것은 분량의 일이고, 1M 컨텍스트의 Opus에서 돌아갑니다. 첫 단계는 공유 보고서에 명시적인 핸드오프 섹션을 쓰고, 두 번째 단계는 그 섹션에 적힌 것만 합니다. 소셜 팀도 같은 방식으로 나눕니다: 글쓰기와 비주얼은 Fable, Chrome에서의 게시와 감사 인사는 Opus.

실행이 중간에 끊기면 어떻게 되나요?

보고서는 실행 첫 1분부터 존재하며 ‘실행 중’이라고 적힌 줄을 갖고, 끝난 일은 그 자리에서 커밋됩니다. 그래서 21:40에 끊긴 실행은 부분 보고서와 그 커밋들을 남기고, 추적되지 않는 파일은 남기지 않습니다. 보고 담당은 부분 보고서를 옮겨 적고 그 에이전트가 끊겼다고 씁니다. 우리는 9월 9일에 이것을 호되게 배웠습니다: 에이전트 두 개가 같은 분에 멈췄는데, 진행하면서 커밋하던 쪽은 아무것도 잃지 않았고, 다른 쪽은 누구 것인지 알 수 없는 수정된 파일 45개를 남겼습니다.