자동화
크론 작업, 웹훅, 지능형 알림으로 반복적인 작업을 자동화하세요.
크론 작업
작업을 자동으로 실행하도록 예약.
접근: 탐색 레일 → Cron
크론 관리 패널
┌─────────────────────────────────────────────────────────┐
│ 크론 작업 [+ 새 작업] │
├─────────────────────────────────────────────────────────┤
│ │
│ 일일 스탠드업 보고서 │
│ 매일 오전 9:00 [편집] [▶️] │
│ 마지막 실행: 오늘 오전 9:00 | 다음: 내일 오전 9:00 │
│ 상태: ✅ 활성화 │
│ │
├─────────────────────────────────────────────────────────┤
│ │
│ 웹사이트 상태 확인 │
│ 5분마다 [편집] [▶️] │
│ 마지막 실행: 2분 전 | 다음: 3분 후 │
│ 상태: ✅ 활성화 │
│ │
├─────────────────────────────────────────────────────────┤
│ │
│ 주간 뉴스레터 │
│ 매주 월요일 오전 10:00 [편집] [▶️] │
│ 마지막 실행: 없음 | 다음: 월요일 오전 10:00 │
│ 상태: ⏸️ 비활성화 │
│ │
└─────────────────────────────────────────────────────────┘
크론 작업 생성
1단계: 기본 정보
이름: 일일 스탠드업 보고서
설명: 일일 스탠드업 생성 및 이메일
2단계: 일정
일정 유형 선택:
| 유형 | 예시 | 사용 사례 |
|---|---|---|
| At | 내일 오전 9:00 | 일회성 미래 작업 |
| Every | 30분마다 | 정기적인 간격 |
| Cron | 0 9 * * 1-5 | 복잡한 패턴 |
일반적인 Cron 패턴:
1분마다: * * * * *
5분마다: */5 * * * *
매시간: 0 * * * *
매일 오전 9시: 0 9 * * *
주중 오전 9시: 0 9 * * 1-5
매주 월요일: 0 9 * * 1
매월 1일: 0 9 1 * *
3단계: 작업
트리거될 때 수행할 작업:
옵션 A: 에이전트에게 메시지 본문
작업: 메시지 본문
대상: @Atlas
메시지: 일일 스탠드업 보고서 생성
옵션 B: 작업 생성
작업: 작업 생성
제목: 웹사이트 상태 확인
담당자: Scout
우선순위: 높음
옵션 C: 웹훅 실행
작업: 웹훅 호출
URL: https://api.example.com/health-check
메서드: GET
4단계: 옵션
- 즉시 활성화 — 일정에 따라 실행 시작
- 실행 후 삭제 — 일회성 작업의 경우
- 전달 채널 — 결과를 보낼 곳
작업 관리
활성화/비활성화: 삭제하지 않고 작업 켜기/끄기
수동 트리거: 테스트를 위해 ▶️ 클릭하여 즉시 실행
편집: 일정, 작업 또는 설정 변경
삭제: 작업을 영구적으로 제거
작업 내역
실행 내역 보기:
실행 로그: 일일 스탠드업 보고서
✅ 오늘 오전 9:00 성공 (2.3초)
✅ 어제 오전 9:00 성공 (2.1초)
✅ 12월 13일 오전 9:00 성공 (2.5초)
❌ 12월 12일 오전 9:00 실패 — 에이전트 오프라인
시스템 하트비트
보류 중인 승인, 차단된 작업 등을 확인하는 특별한 내장 크론:
기본값: 30분마다
확인하는 것:
- 보류 중인 승인
- 차단된 작업
- 멈춘 에이전트 (5분 이상 활성)
- 시작되지 않은 Inbox 작업
작업:
- 오래된 Inbox 작업 자동 활성화
- 멈춘 에이전트에 대한 알림 전송
- 요약 보고서 생성
사용자 정의:
사용자 정의 지침으로 작업 공간에 HEARTBEAT.md 생성.
웹훅
외부 시스템에서 데이터를 받고 데이터를 보냅니다.
접근: 탐색 레일 → 웹훅
수신 웹훅
외부 시스템이 CapiBot에 데이터를 보냅니다.
예시: GitHub 웹훅
When: GitHub에서 새 이슈 생성
작업: CapiBot이 해당 작업 생성
설정:
- 웹훅 패널로 이동
- "+ 수신" 클릭
- 구성:
이름: GitHub 이슈 URL: /webhooks/github 이벤트: issues.opened, issues.edited Secret: [HMAC 서명 키] - 웹훅 URL 복사
- GitHub 웹훅 설정에 붙여넣기
- 작업 선택: "GitHub 이슈에서 작업 생성"
지원되는 소스:
- GitHub (이슈, PR)
- GitLab
- Linear
- Jira
- 커스텀 (모든 HTTP POST)
발신 웹훅
CapiBot이 외부 시스템에 데이터를 보냅니다.
예시: Slack 알림
When: 작업 완료
작업: Slack 채널에 메시지 본문
설정:
- 웹훅 패널로 이동
- "+ 발신" 클릭
- 구성:
이름: Slack 알림 URL: https://hooks.slack.com/services/... 메서드: POST 이벤트: task.completed, agent.error 페이로드: JSON - 웹훅 테스트
- 활성화
이벤트 유형:
- 작업 이벤트 (생성, 완료, 할당)
- 에이전트 이벤트 (생성, 오류)
- 기업 이벤트 (생성, 보관)
- 알림 이벤트 (트리거)
- 시스템 이벤트 (하트비트)
웹훅 테스트
활성화 전 웹훅 테스트:
웹훅 테스트: GitHub 이슈
테스트 페이로드 본문:
{
"action": "opened",
"issue": {
"title": "테스트 이슈",
"body": "이것은 테스트입니다"
}
}
[테스트 보내기]
응답:
✅ 200 OK
{
"taskId": "T-123",
"status": "created"
}
전달 내역
웹훅 전달 추적:
최근 전달
✅ 12월 15일 14:32:01 GitHub → 작업 생성
✅ 12월 15일 14:30:45 작업 완료 → Slack
❌ 12월 15일 14:28:12 알림 → 웹훅 실패 (시간 초과)
✅ 12월 15일 14:25:33 GitHub → 작업 생성
재시도 로직:
- 실패한 전달은 3번 재시도
- 지수 백오프
- 수동 재시도 가능
보안
HMAC 서명: 웹훅 신뢰성 확인:
Secret: your-webhook-secret
알고리즘: SHA-256
헤더: X-Webhook-Signature
속도 제한:
- 소스당 분당 100 요청
- 남용 방지
- 남용 시 자동 IP 차단
알림 규칙
특정 조건이 발생할 때 알림 받기.
접근: 탐색 레일 → 알림
알림 규칙 생성
1단계: 조건
트리거 시기 정의:
When: 작업
필드: 상태
연산자: equals
값: 차단됨
AND
필드: 상태의 일수
연산자: greater than
값: 1
사용 가능한 조건:
| 엔티티 | 필드 | 연산자 |
|---|---|---|
| 작업 | 상태, 우선순위, 담당자, 마감일, 상태의 일수 | =, ≠, >, <, contains |
| 에이전트 | 상태, 기업, 역할 | =, ≠, contains |
| 기업 | 단계, 모드, 예산 | =, ≠, >, < |
예시:
알림: 검토에서 멈춘 작업
When: 작업 상태 = Review
AND 상태의 일수가 2일보다 큼
알림: 에이전트 오류
When: 에이전트 상태 = Error
알림: 예산 경고
When: 기업 비용이 예산의 80%보다 큼
알림: 높은 우선순위 연체
When: 작업 우선순위 = 긴급
AND 마감일이 오늘 이전
2단계: 작업
트리거될 때 수행할 작업:
옵션 A: 알림 보내기
채널: Telegram
대상: @yourusername
메시지: ⚠️ 작업 {taskId}가 2일 이상 차단됨
옵션 B: 작업 생성
제목: 차단된 작업 후속
담당자: 관리자
우선순위: 높음
옵션 C: 웹훅 호출
URL: https://api.example.com/alerts
메서드: POST
페이로드: { alert: details }
3단계: 설정
- 쿨다운 — X분 동안 다시 트리거하지 않음
- 활성화 — 활성 또는 비활성
- 테스트 — 트리거 시뮬레이션
알림 관리
활성 알림 보기:
활성 알림
🔴 작업 T-42가 3일 차단
규칙: 멈춘 작업
트리거: 2시간 전
[작업 보기] [해제]
🔴 에이전트 Nova가 Error 상태
규칙: 에이전트 오류
트리거: 10분 전
[에이전트 보기] [해제]
알림 내역:
최근 알림 (지난 7일)
🔴 12월 15일 14:32 2일 이상 차단된 작업
🔴 12월 15일 12:10 에이전트 오류
🟡 12월 14일 09:00 예산 75%
🟡 12월 13일 16:45 작업이 마감일에 가까움
스마트 알림
쿨다운 기간: 알림 피로 방지:
규칙: 작업 차단
쿨다운: 4시간
결과: 알림이 한 번 발생한 다음 동일한 작업에서
다시 알림하기 전에 4시간 대기
에스컬레이션:
레벨 1: 작업 차단 1일 → 담당자에게 알림
레벨 2: 작업 차단 3일 → 관리자에게 알림
레벨 3: 작업 차단 5일 → 관리자에게 알림
일반적인 자동화 패턴
패턴 1: 일일 스탠드업
설정:
Cron: 매일 오전 9:00
작업: Atlas에게 메시지
메시지: "일일 스탠드업 보고서 생성"
결과: Atlas가 스탠드업 요약 생성
패턴 2: 웹사이트 모니터링
설정:
Cron: 5분마다
작업: 웹훅 호출
URL: https://my-site.com/health
알림: 웹훅이 오류를 반환하면
작업: Telegram을 통해 관리자에게 알림
패턴 3: GitHub 통합
설정:
수신 웹훅: GitHub
이벤트: issues.opened
작업: 작업 생성
담당자: 레이블에 따라 자동 할당
결과: GitHub 이슈가 CapiBot 작업이 됨
패턴 4: 마감일 경고
설정:
알림: 내일 마감인 작업
조건: 마감일 = 내일
AND 상태 ≠ 완료됨
작업: 담당자에게 미리 알림 보내기
패턴 5: 예산 모니터링
설정:
알림: 예산 80% 사용
조건: 기업 비용이 예산의 80%보다 큼
작업: 관리자에게 알림
작업: CEO를 위한 검토 작업 생성
패턴 6: 오류 복구
설정:
알림: 에이전트 오류
조건: 에이전트 상태 = Error
작업: 관리자에게 알림
작업: 에이전트를 자동으로 재시작
모범 사례
크론 작업
- 합리적인 간격 — 필요하지 않은 경우 1분마다 실행하지 마세요
- 멱등성 — 여러 번 실행해도 안전해야 함
- 실패 모니터링 — 실행 로그 확인
- 먼저 테스트 — 활성화 전 수동 트리거
- 문서화 — 명확한 이름과 설명
웹훅
- 서명 확인 — 항상 HMAC 검증
- 재시도 처리 — 중복 전달을 위해 설계
- 시간 초과 처리 — 합리적인 시간 초과 설정
- 오류 로깅 — 디버깅을 위한 실패 로깅
- 엔드포인트 테스트 — 수신 시스템이 작동하는지 확인
알림
- 실행 가능한 — 모든 알림은 응답이 있어야 함
- 너무 시럽지 않게 — 스팸을 방지하기 위해 쿨다운 사용
- 에스컬레이션 — 적절한 사람에게 알림
- 규칙 검토 — 필요에 따라 업데이트
- 조건 테스트 — 실시간 전에 시뮬레이션
문제 해결
크론 작업이 실행되지 않음:
- 활성화되었는지 확인
- 일정 형식 확인
- 시스템 시간/타임존 확인
- 실행 로그 검토
웹훅이 수신되지 않음:
- URL이 올바른지 확인
- 방화벽 규칙 확인
- curl/postman으로 테스트
- 웹훅 로그 검토
알림이 발생하지 않음:
- 조건 로직 확인
- 엔티티가 기준과 일치하는지 확인
- 규칙을 수동으로 테스트
- 쿨다운 설정 검토
너무 많은 알림:
- 쿨다운 기간 증가
- 알림 조건 다듬기
- 배칭 사용
- 알림 설정 검토