AIREITERFactory Automations를 사용하면 예약된 시간, Slack의 최상위 메시지, GitHub 이벤트, 외부 HTTP 요청으로 Droid 세션을 시작할 수 있습니다. 다만 웹훅 트리거는 아직 Private Preview이며, 예약 실행은 고정된 UTC 시간을 사용해 서머타임 변경을 자동으로 반영하지 않습니다. 아무런 제한 없이 프로덕션에 투입할 단계라기보다는, 범위를 통제한 파일럿에 적합한 상태입니다.
Factory Automations가 실제로 실행하는 것
각 자동화는 트리거, 지시사항, 실행 주체, 실행 대상의 조합으로 구성됩니다(Factory 문서).
| 트리거 | 실행을 시작하는 조건 | 주요 실행 방식 |
|---|---|---|
| 예약 실행 | 자연어로 입력한 주기 또는 5개 필드 cron | 지정한 컴퓨터나 실행 대상에서 실행되며, 관리형 컴퓨터는 자동화 10개를 지원하고 그중 5개는 1분 단위로 예약할 수 있음 |
| Slack | 조건에 맞는 채널 최상위 메시지 | 처음 메시지가 올라온 스레드에 답글을 작성 |
| GitHub | 풀 리퀘스트, 댓글, 푸시, 라벨, 체크 또는 예약 실행 | 설정이 병합된 뒤 GitHub Actions에서 실행 |
| 웹훅 | 다른 서비스에서 보내는 HTTP POST | Droid Computer 또는 실행 템플릿에서 실행되며 Private Preview 상태 |
자동화는 비공개로 유지하거나 조직과 공유할 수 있습니다. 한편 세션 공개 범위는 별도로 적용되며, 자동화가 만든 세션을 누가 열어볼 수 있는지를 결정합니다.
트리거 선택에 따라 운영 방식이 달라진다
예약 실행: 가장 안전한 출발점
예약은 “every Monday at 9am PST” 같은 자연어나 0 9 * * 1 같은 cron 표현식으로 설정할 수 있습니다. Factory는 실행 예정 시간을 미리 보여주지만, cron은 UTC 기준으로 동작합니다. 시간대를 명시해 입력한 값도 고정된 UTC 일정으로 변환되며, 서머타임이 바뀌어도 자동으로 조정되지 않습니다(Factory 문서).
첫 작업으로는 일일 상태 요약, 의존성 점검, 오래된 문서 탐지, 또는 코드를 직접 병합하지 않고 근거를 정리해 주는 PR 리뷰어가 적합합니다.
Slack 메시지: 유용하지만 최상위 신호만 잡는다
Slack 자동화는 접근 가능한 채널에 조건에 맞는 최상위 메시지가 올라왔을 때 시작됩니다. 스레드 답글은 별도의 실행을 시작하지 않습니다. 채널 패턴, 발신자 유형, 키워드, 제외할 키워드, 제외할 발신자 등을 기준으로 메시지를 필터링할 수 있습니다.
실행 결과는 트리거가 된 메시지의 스레드에 답글로 올라옵니다. 여러 자동화가 동시에 조건에 맞으면 첫 번째 자동화만 해당 스레드에 답하고, 나머지는 원본 메시지로 연결되는 별도 메시지를 게시합니다. 비공개 채널 접근 규칙을 포함한 이런 동작은 Factory 문서에 명시되어 있습니다(Factory 문서). 따라서 통제된 장애 대응 채널에는 잘 맞지만, 모든 후속 답글을 빠짐없이 처리해야 하는 워크플로에는 적합하지 않습니다.
GitHub 이벤트: 설정 게이트를 통과하면 강력하다
커스텀 GitHub 자동화는 풀 리퀘스트, 푸시, 댓글, 라벨 변경, 완료된 체크, 예약 실행에 반응할 수 있습니다. 실행 환경은 GitHub Actions이며, 자동화를 만들면 선택한 각 저장소에 설정용 풀 리퀘스트가 생성됩니다.
이 설정용 풀 리퀘스트가 병합되어야 워크플로가 활성화됩니다. 워크플로가 기본 브랜치에 반영되기 전에 시작된 실행은 실패하며, 그 전에는 자동화가 댓글을 달거나 커밋을 푸시하거나 풀 리퀘스트를 열 수도 없습니다. 반복 작업이 이미 저장소 이벤트를 중심으로 돌아가고, 일반적인 풀 리퀘스트 리뷰가 배포 경계로 남아 있다면 GitHub가 가장 강력한 트리거입니다.
웹훅: 기능은 갖췄지만 사용 범위가 제한된다
Factory는 웹훅 자동화를 Private Preview로 제공하며, 활성화를 원할 경우 지원팀에 문의하라고 안내합니다. 외부 HTTP POST로 실행을 시작할 수 있지만 사용자 로컬 머신에서 실행할 수는 없고, Droid Computer나 실행 템플릿이 필요합니다.
Factory는 웹훅 URL과 X-Webhook-Secret 헤더 방식, 그리고 헤더를 설정할 수 없는 발신자를 위한 URL 방식의 인증 옵션을 제공합니다. 문서에서는 URL에 포함된 시크릿이 로그에 남을 수 있으므로 헤더 방식을 권장합니다. 시크릿은 한 번만 표시되며, 값을 교체하면 기존 값은 무효화됩니다(Factory 웹훅 문서).
같은 문서에 따르면 요청 본문은 200 KiB, 분당 허용 요청 수는 60개, 전달 기록 보관 기간은 30일입니다. 동일한 본문에 대한 중복 제거 창은 10분이며, 시간당 실행 상한은 10회입니다. 이런 제어 기능 덕분에 장애 알림 대응을 시험하기에는 충분하지만, 접근 가능 여부가 일정해야 하는 프로덕션 환경에서는 Private Preview라는 상태 자체가 걸림돌입니다.
자동화를 안전하게 운영할지 결정하는 제어 항목
예약 실행, Slack, 웹훅 자동화는 사용자 계정으로 실행하거나 공유 서비스 계정으로 실행할 수 있습니다. 어떤 계정을 쓰느냐에 따라 커넥터 접근 권한, 과금, Slack에 표시되는 발신자 정보가 달라집니다. 실행 대상별 규칙은 Factory 문서에 정리되어 있습니다.
프롬프트는 좁은 범위로 작성하고, 필요할 때 폐기할 수 있는 자격 증명을 사용하세요. 전용 실행 대상을 선택하고, 배포와 병합 권한은 기존 저장소 제어 체계에 남겨두는 편이 좋습니다. Factory의 Slack Marketplace 등록 페이지도 앱이 실수할 수 있다고 명시하며, 코드와 응답을 반드시 다시 확인하라고 안내합니다.
한 사용자는 Linux 데스크톱 앱이 없고 컴퓨터 간 동기화도 지원되지 않는 등 감독 공백을 지적했습니다(X의 @JoelDeTeves 게시물). 데스크톱을 떠난 상태에서도 장시간 실행되는 자동화 작업을 감독해야 하는 팀이라면 이 부분이 중요합니다.
Factory Automations와 단순한 GitHub Action 비교
| 필요한 작업 | Factory Automations | 단순한 GitHub Action |
|---|---|---|
| 저장소를 대상으로 프롬프트 실행 | 네이티브 Droid 세션과 실행 대상 제공 | 팀이 에이전트 런타임과 워크플로 코드를 직접 준비 |
| 예약 작업 | 자연어 또는 cron 지원, UTC 제약 존재 | GitHub cron과 커스텀 로직 사용 |
| Slack 트리거 | 필터와 스레드 답글을 지원하는 최상위 메시지 트리거 | Slack 앱 또는 웹훅 연동을 직접 구성 |
| GitHub 이벤트 | 설정용 PR을 거쳐 GitHub Actions에서 실행 | 워크플로 파일을 직접 작성 |
| 웹훅 | 기능 내장, 단 Private Preview | 엔드포인트, 인증, 재시도, 워커를 직접 구축 |
| 리뷰 경계 | 사람이 검토할 작업을 미리 준비할 수 있음 | 워크플로 권한 설정에 따라 달라짐 |
일일 PR 요약처럼 결정론적인 API 연동이 핵심인 작업이라면 GitHub Action을 선택하세요. 반대로 반복 작업에 조사, 저장소 맥락 파악, 코드 변경안 작성, 사람이 읽을 수 있는 세션이 필요하다면 Factory가 더 적합합니다. 짧은 스크립트 하나를 작성하지 않기 위해 굳이 에이전트 플랫폼을 선택할 필요는 없습니다.
더 큰 권한으로 확장할 수 있는 저위험 파일럿
- 새 풀 리퀘스트 검토나 생성 파일 점검처럼 입력 범위가 명확한 반복 작업 하나를 고릅니다.
- 웹훅보다 예약 자동화로 시작하세요. 프리뷰 접근 권한이 필요 없고 실행 주기를 쉽게 확인할 수 있습니다.
- 결과물은 배포나 병합이 아니라 보고서 또는 풀 리퀘스트로 제한합니다.
- 실패한 실행, 막힌 작업, 변경된 파일, 사람이 수정한 내용을 기록합니다. 병합된 PR만으로는 충분한 근거가 되지 않습니다.
- 작업 유형, 저장소, 트리거 중 한 번에 하나의 축만 확장합니다.
Factory의 워크플로 가이드는 원래 실패를 재현하고, 깨끗한 환경에서 수정 사항을 테스트한 뒤, 인접한 사례에서도 문제가 없는지 확인하고 나서 재사용 가능한 지침으로 남기라고 권장합니다. Automation 파일럿에도 적용하기 좋은 기준입니다.
FAQ
Factory Automations는 웹훅을 지원하나요?
지원합니다. 다만 웹훅 트리거는 Private Preview이며 조직 차원의 활성화가 필요할 수 있습니다. 실행하려면 Droid Computer나 실행 템플릿이 필요합니다. 자세한 내용은 위의 웹훅 섹션을 참고하세요.
Slack 스레드 답글도 자동화를 실행하나요?
아니요. 조건에 맞는 최상위 메시지만 실행을 시작합니다. Slack 메시지 항목을 참고하세요.
예약 실행은 서머타임을 반영하나요?
아니요. Factory는 고정된 UTC 일정을 저장하므로, 현지 서머타임 규칙이 바뀌면 일정을 다시 확인해야 합니다. 예약 실행 항목을 참고하세요.
설정용 풀 리퀘스트가 병합되기 전에 GitHub 자동화가 실행되나요?
아니요. 설정용 풀 리퀘스트가 먼저 기본 브랜치에 반영되어야 하며, 그 전에 시작된 실행은 실패합니다. GitHub 이벤트 항목을 참고하세요.
웹훅 전달이 반복되면 어떻게 되나요?
10분 이내에 동일한 본문이 다시 도착하면 Deduped로 기록되고 새 실행은 시작되지 않습니다. Factory는 필터링됨, 요청 제한 초과, 건너뜀, 실패한 전달도 함께 기록합니다.
끝까지 놓치지 말아야 할 트레이드오프
결과물을 풀 리퀘스트 리뷰 절차 안에 둘 수 있다면 예약 실행이나 GitHub 트리거 작업부터 파일럿으로 시작하세요. Slack은 최상위 메시지를 사용한다는 운영 규칙만 분명하다면 실용적입니다. 웹훅은 테스트에 필요한 기능을 충분히 갖췄지만, Private Preview 상태인 만큼 아직 프로덕션 장애 대응 시스템의 기반으로 삼기에는 이릅니다.