모든 엔지니어링 팀에는 아무도 계획하지 않았지만 모두가 비용을 치르는 반복 업무가 있습니다. 누군가는 스탠드업 요약을 정리하고, 누군가는 들어오는 버그 리포트를 하나하나 읽고 담당자를 지정하며, 누군가는 여기저기 흩어진 여섯 개 탭에서 금요일 상태 보고서를 짜맞춥니다. 어려운 일은 하나도 없습니다. 하지만 전부 노동입니다. 예측 가능하고 반복적이며 조용히 비용을 잡아먹죠. 처음 발견한 사람에게 일이 떨어지기 때문입니다.
이런 종류의 업무는 AI 에이전트가 잘 처리합니다. 단, 누군가 프롬프트를 입력하지 않아도 적절한 시점에 에이전트가 스스로 시작된다는 조건이 붙습니다. 그 시작 장치가 바로 Sharkly의 Automations입니다. Automation은 반복적인 에이전트 또는 Crew 작업을 위한 Space 소유의 정의로, 작성된 지침, 실행 담당자, 하나 이상의 트리거, 그리고 확인 가능한 실행 이력을 담고 있습니다.
핵심은 판단을 자동화하는 것이 아닙니다. Sharkly의 표현은 명확합니다. 자동화는 팀의 판단이 필요한 지점에서 멈춥니다. Automation은 스탠드업 요약을 초안하고, 버그를 1차로 읽고, 주간 보고서를 정리할 수 있습니다. 하지만 그 결과를 두고 팀이 무엇을 할지는 여전히 사람이 결정합니다. Sharkly 자체가 처음이라면 Sharkly란 무엇인가를 먼저 읽고 돌아오세요.
요약
Sharkly의 Automation은 트리거가 발동될 때마다 정해진 지침 세트로 에이전트 또는 Crew를 시작하는 Space 소유의 규칙입니다. 트리거 유형은 네 가지입니다. 시간대가 지정된 5필드 cron 형식의 스케줄, 작업 상태 변경, 설정한 문구를 포함한 댓글, 외부 서비스용 비밀 웹훅 URL이 있으며, 수동 테스트용 Run now 버튼도 있습니다. 각 실행은 출처, 결과, 실패 사유와 함께 실행 이력에 기록되며, Automation은 수정하는 동안 일시 중지했다가 다시 재개할 수 있습니다. Automations는 명확하게 정의된 반복 업무에 사용하세요. 스탠드업 요약, 1차 버그 트리아지, 정기 보고서 등이 대표적입니다. 에이전트가 읽고 초안을 작성하면, 사람이 결과를 검토하고 판단을 내립니다.
Automation이란 무엇이고, 무엇이 아닌가
Automation은 하나의 반복 작업에 대한 작고 완결된 정의를 저장합니다. 목표, 단계, 제약 조건, 기대 결과를 설명하는 이름과 지침, 이를 소유한 Space, 작업을 수행하는 에이전트 또는 Crew를 뜻하는 담당자, 우선순위, Active 또는 Paused 상태, 하나 이상의 트리거, 그리고 각 실행의 출처, 결과, 에이전트 실행, 실패 사유를 기록하는 실행 이력이 포함됩니다.
미리 알아두지 않으면 놀랄 만한 두 가지 경계가 있습니다.
첫째, Automation은 실행할 때마다 Task를 생성하지 않습니다. 에이전트 또는 Crew 실행을 직접 시작합니다. 실행, 그 출력, 그리고 실패가 있다면 모두 작업 목록이 아니라 Automation의 실행 이력에 남습니다. 덕분에 매일 아침 9시마다 기계가 만든 Task로 보드가 가득 차는 일은 없습니다.
둘째, Automations는 Sharkly의 워크플로 캔버스가 아닙니다. Space에는 두 가지 자동화 표면이 있습니다. 여기서 설명하는 단일 규칙인 Automations와, 서드파티 커넥터를 호출할 수 있는 트리거 및 액션 노드의 캔버스인 Automation workflows입니다. 예측 가능한 이벤트에 대응해 하나의 에이전트 또는 Crew가 하나의 지침 세트를 실행해야 할 때는 Automation을 사용하세요. 에이전트가 개입하기 전에 여러 단계에 걸친 작업이나 앱 간 작업이 필요할 때는 워크플로를 사용하세요.
담당자가 온전한 Sharkly 에이전트이기 때문에, 해당 에이전트에 이미 설정해 둔 모든 것이 그대로 적용됩니다. 지침, Runtime, Skills, 리포지토리, 실행 설정 등이죠. 아직 만들어본 적이 없다면 Sharkly의 에이전트에서 저장된 작동 구성을 팀이 재사용할 수 있는 형태로 만드는 방법을 다룹니다. Automation은 사실상 그 에이전트와의 정기 예약이라고 할 수 있습니다.
네 가지 트리거 유형
Automation에는 여러 트리거를 둘 수 있으며, 각각 개별적으로 활성화하거나 비활성화할 수 있습니다. 하나의 정의로 여러 진입점을 담당할 수 있습니다. 동일한 트리아지 지침이 상태 변경과 슬래시 명령 모두에서 발동되도록 하면서 아무것도 중복할 필요가 없습니다.
| 트리거 | 발동 시점 | 적합한 용도 | 주의할 점 |
|---|---|---|---|
| 스케줄 | 선택한 시간대에서 cron 표현식이 일치할 때 | 반복 점검, 요약, 알림, 유지보수 | 시간대 선택, 변경 여부와 무관하게 실행됨 |
| 작업 상태 변경 | 작업이 선택한 Organization 상태로 이동할 때 | 접수 큐, 리뷰 후속 조치, 트리아지 | 매칭이 Space 필터가 아닌 Organization 전체 기준임 |
| 댓글 문구 | 작업 댓글에 설정한 문구가 포함될 때(대소문자 구분 없음) | 논의 중 사용하는 /triage 같은 온디맨드 명령 | 마찬가지로 Organization 전체를 수신하며, 구별되는 문구 선택 필요 |
| 웹훅 | 외부 서비스가 비밀 URL로 POST를 보낼 때 | CI 결과, GitHub 이벤트, 다른 시스템의 알림 | URL이 곧 bearer 비밀이므로 안전하게 보관하고 교체할 것 |
스케줄은 표준 5필드 cron 표현식과 시간대를 사용하며, 일반적인 매시, 매일, 평일, 매주 프리셋이 제공됩니다. 무언가가 변경되어서가 아니라 화요일이기 때문에 실행되어야 하는 작업에 쓰는 트리거입니다.
작업 상태 변경은 작업이 선택한 Organization 상태로 이동할 때 Automation을 시작합니다. 중요한 세부 사항이 하나 있습니다. 상태는 재사용 가능한 Organization 정의이며, 현재 이벤트 매칭은 Organization 전체를 기준으로 합니다. 여러 Space가 동일한 "Needs Triage" 상태를 사용하는 경우, 그중 어느 곳에서든 일치하는 전환이 발생하면 Automation이 시작될 수 있습니다. 에이전트가 작업을 실행하기 전에 트리거된 작업을 확인하도록 지침을 작성하세요.
댓글 문구는 작업 댓글에 설정한 문구가 포함될 때 실행을 시작합니다. 매칭은 대소문자를 구분하지 않고 댓글 내 어디든 확인하며, 역시 Organization 전체를 수신합니다. 문서의 조언은 이렇습니다. "check" 같은 문구보다 /triage-bug처럼 구별되는 슬래시 명령을 선호하고, 지침에서 트리거된 작업을 검증하도록 하세요.
웹훅은 외부 서비스의 POST를 받는 비밀 URL을 생성합니다. 전체 URL은 트리거를 생성하거나 재생성할 때 표시되며 이후에는 다시 볼 수 없습니다. 기본적으로 URL 자체가 bearer 비밀 역할을 하기 때문입니다. 서명 비밀을 설정하면 요청이 서명 검증도 통과해야 합니다. GitHub이 자체 웹훅에 사용하는 방식과 같은 패턴입니다. 이러한 비밀은 소스 컨트롤에 넣지 말고, 노출되었다면 재생성하세요. 웹훅 외에 Sharkly를 스크립팅하는 방법은 Sharkly CLI와 API를 참고하세요.
실행을 시작하는 또 한 가지 방법은 트리거가 아닙니다. Run now는 Automation을 직접 시작하는 기능으로, 네 가지 트리거에 업무를 맡기기 전에 지침과 담당자 가용성을 테스트하는 방법입니다.
Automation이 실제로 실행하는 것
트리거가 발동하면 Sharkly는 Automation의 지침을 가지고 지정된 에이전트 또는 Crew를 시작합니다. 이 지침이 곧 계약의 전부이므로, 문서에서는 무엇을 명시해야 하는지 구체적으로 설명합니다. 만들어야 할 결과물, 살펴볼 입력, 따를 단계, 결과를 기록할 위치, 허용되는 변경, 그리고 사람이 검토하거나 결정해야 하는 시점입니다.
마지막 항목은 강조할 가치가 있습니다. 잘 작성된 Automation은 스스로의 중단 지점을 명시합니다. "요약을 초안해 기록하고, 작업 상태는 변경하지 말 것"이 권한을 모호하게 남기는 더 긴 지침보다 낫습니다. 문서의 배포 지침도 마찬가지로 명확합니다. 관찰 가능하고 되돌릴 수 있는 작업부터 시작하고, 범위를 넓히기 전에 여러 번의 실행을 검토하세요.
가장 먼저 자동화할 만한 세 가지 잡무
각 항목은 제품이 지원하는 수준을 유지합니다. 에이전트는 읽고 초안을 작성하고 기록하며, 사람은 결정을 계속 맡습니다.
일일 스탠드업 요약. 트리거: 팀 시간대에서 평일 프리셋을 사용하는 스케줄. 담당자: 관련 컨텍스트에 읽기 권한이 있는 리포팅 에이전트. 지침: 현재 Sprint의 작업을 살펴보고 무엇이 진행되었는지, 무엇이 막혀 있는지, 무엇이 리뷰를 기다리는지 파악한 뒤, 작업은 전혀 변경하지 않고 팀이 읽는 곳에 짧은 요약을 기록합니다. 에이전트가 스탠드업에서 아무도 좋아하지 않는 부분, 즉 전체 그림을 정리하는 일을 맡고, 스탠드업은 판단이 필요한 두 항목을 논의하는 자리가 됩니다. 팀의 주기를 Sharkly로 운영한다면 Sprints가 에이전트가 살펴볼 구조를 제공합니다.
1차 버그 트리아지. 트리거: 버그 접수 상태에 대한 작업 상태 트리거, 또는 /triage 같은 구별되는 문구에 대한 댓글 트리거, 또는 둘 다. 담당자: 리포지토리가 영향받는 코드를 포함하는 트리아지 에이전트. 지침: 트리거된 작업이 의도한 Space의 버그인지 확인하고, 리포트를 읽고, 코드베이스의 관련 영역을 살펴본 뒤, 버그가 무엇을 건드리는 것으로 보이는지, 리포트에 조치할 만한 내용이 충분한지, 근거와 함께 제안 우선순위를 기록합니다. 결정하지 말고 권고하세요. 검증 단계는 장식이 아닙니다. 상태와 댓글 매칭이 Organization 전체를 기준으로 하므로, 지침이 곧 범위 필터입니다. 그 대가는 모든 버그가 접수된 지 몇 분 안에 동일하게 꼼꼼한 1차 검토를 받는다는 점입니다. Sharkly 외부에서 작업이 들어오는 경우에도 같은 역할 분담이 유지됩니다. Jira 티켓이 에이전트의 업무가 되는 방법을 참고하세요.
정기 보고서. 트리거: 매주 프리셋을 사용하는 스케줄. 담당자: 앞서와 같은 종류의 리포팅 에이전트이며, 더 긴 기간을 범위로 하는 지침을 부여합니다. 완료된 것, 지연된 것, 막혀 있는 것을 요약합니다. 스탠드업 사례와의 차이는 범위와 대상 독자뿐이며, 바로 그래서 Automation에 넣을 가치가 있습니다. 매주 금요일 같은 품질로 존재하는 보고서가, 누군가 시간이 있을 때만 존재하는 더 나은 보고서보다 낫습니다.
세 가지 모두에서 지침에 절대 등장하지 않는 단어에 주목하세요. 수락, 승인, 배포, 종료, 결정입니다.
실행 이력, 상태, 그리고 일시 중지와 재개
확인할 수 없는 자동화는 신뢰할 수 없는 자동화입니다. 그래서 모든 실행이 기록됩니다. 실행 이력은 각 실행을 Running, Completed, Failed, Skipped로 보고하며, 실행 세부 정보에서 트리거 페이로드, 에이전트 실행, 출력, 기록된 실패 사유를 열어볼 수 있습니다. 개별 실행 위에는 최신 상태를 요약하는 헬스 신호가 있습니다. never tested, running, healthy, skipped, needs attention입니다.
머릿속에 굵게 새겨 둘 경계 하나가 있습니다. Completed 상태는 Automation 실행을 설명하는 것이지, 모든 후속 결과가 정확했다는 보장이 아닙니다. Completed는 기계가 작동했다는 뜻입니다. 요약이 정확했는지, 트리아지 판단이 타당했는지는 여전히 사람이 읽어야 합니다.
일시 중지와 재개는 예상할 수 있는 바로 그 순간을 위해 존재합니다. 지침, 트리거, 담당자를 수정하는 동안 새로 트리거되는 실행을 멈추려면 Automation을 일시 중지하고, 구성이 준비되면 재개하세요. 그 사이에도 정의와 이력은 그대로 남습니다. 삭제는 유일한 제거 경로이므로, 실행 이력이 더 이상 필요 없는 정의에만 사용하세요. 그리고 에이전트를 아카이브하기 전에 Automations가 여전히 그 에이전트에 의존하고 있는지 확인하세요.
어떤 Automation에 의존하기 전에 문서에서는 짧은 체크리스트를 권합니다. Run now로 수동 실행하고, 에이전트 또는 Crew에 필요한 접근 권한이 있는지 확인하고, 실행과 출력을 살펴보고, 각 트리거를 개별적으로 테스트하고, 좁은 상태나 구별되는 댓글 문구를 사용하고, 웹훅 비밀을 소스 컨트롤 밖에 두세요.
자동화가 멈추는 지점
목표가 무인 파이프라인이라고 결론 내리기 쉽습니다. 그렇지 않으며, 제품 자체의 설계가 그렇게 말합니다. Automations는 자기 출력을 스스로 수락하지 않고, 검토를 위해 모든 실행을 기록합니다.
그래서 정직한 결정 규칙은 이렇습니다. 동일하게 잘 정의된 작업이 반복적으로 시작되어야 하거나 예측 가능한 이벤트에 대응해 시작되어야 하고, 일관된 1차 초안이 가끔 나오는 뛰어난 초안보다 나을 때 Automation을 사용하세요. 일회성 작업이라면 에이전트에 Task를 직접 할당하고, 업무가 곧 판단인 경우에는 전적으로 사람이 맡기세요. 상충하는 압박 속에서의 우선순위 결정, 수락 결정, 꾸준히 틀리는 것이 가끔 느린 것보다 나쁜 모든 경우입니다.
작고 지루하게 시작하세요. 설정을 마치고, 리포팅 에이전트 하나를 만들고, 평일 스케줄과 "작업을 변경하지 말 것"으로 끝나는 지침을 담은 Automation 하나를 작성한 뒤, 수동으로 한 번 실행하세요. 출력을 읽어보세요. 유용하다면 스케줄이 이어받게 하세요. 문서에서 Automations와 워크플로 캔버스를 더 자세히 다룹니다.
FAQ
Sharkly Automations는 어떤 트리거 유형을 지원하나요?
네 가지입니다. 시간대가 있는 5필드 cron 표현식을 사용하는 스케줄, 작업이 선택한 Organization 상태로 이동할 때 발동하는 작업 상태 트리거, 설정한 문구에 발동하는 댓글 트리거, 비밀 URL로 POST를 받는 웹훅 트리거입니다. Automation은 여러 트리거를 조합할 수 있으며 각각 개별적으로 활성화하거나 비활성화할 수 있고, Run now는 테스트용으로 실행을 수동 시작합니다.
Automation은 실행할 때마다 Task를 생성하나요?
아니요. 현재 Automations는 에이전트 또는 Crew 실행을 직접 시작하며 실행마다 Task를 생성하지 않습니다. 실행, 그 출력, 실패 사유가 있다면 Automation의 실행 이력에 기록됩니다. 결과를 팀이 읽는 곳에 두고 싶다면 지침에 그렇게 명시하세요.
Automations는 Automation workflows와 어떻게 다른가요?
Space 안의 서로 다른 두 표면입니다. Automation은 하나의 규칙입니다. 언제 시작할지, 어떤 에이전트 또는 Crew가 실행될지, 어떤 지침을 따를지입니다. Automation workflows는 커넥터를 통해 서드파티 앱을 호출할 수 있는 트리거 및 액션 노드의 캔버스입니다. 반복 점검과 댓글 명령에는 단일 규칙을 사용하고, 다단계·앱 간 흐름에는 캔버스를 사용하세요.
Automation이 버그 트리아지를 단독으로 처리할 수 있나요?
1차 단계는 처리할 수 있습니다. 트리거된 작업을 확인하고, 리포트를 읽고, 관련 코드를 살펴보고, 제안 우선순위와 함께 결과를 기록합니다. 트리아지 결정은 사람이 맡으며, 지침에 이를 명확히 밝혀야 합니다. 문서에서는 관찰 가능하고 되돌릴 수 있는 작업부터 시작하고, 범위를 넓히기 전에 여러 번의 실행을 검토할 것을 권합니다.
Automation 실행이 실패하면 어떻게 되나요?
실행은 실패 사유가 있을 경우 그 사유와 함께 실행 이력에 Failed로 기록되고, 헬스 신호는 needs attention으로 이동합니다. 실행 세부 정보를 열어 트리거 페이로드, 에이전트 실행, 출력을 살펴보고, 지침, 트리거, 담당자를 수정한 뒤, 트리거를 다시 신뢰하기 전에 Run now로 수정 사항을 검증하세요.
