Lab 06: 반복 작업을 예약한다

사람이 없는 시각에 에이전트가 실행될 때, 도구 승인은 누가 하고 성공과 실패는 어디서 확인하는가?

지금까지 모든 실행은 사람이 시작했습니다. 이번에는 반복 일정을 걸어 시간이 실행을 시작하게 만듭니다. 스케줄 잡은 채팅으로 만들고, Schedule 화면에서 관리합니다. 사람이 승인을 눌러줄 수 없는 실행에서 무슨 일이 생기는지도 두 Approval 정책으로 비교합니다.

• 스케줄 잡을 채팅으로 만들고 화면에서 관리합니다.
• Add Job 폼의 필드와 운영 옵션을 읽고 각 의미를 확인합니다.
• 예약(scheduled) 실행과 수동(manual) 실행을 이력에서 구분합니다.
• 무인 실행의 도구 승인 문제를 Default와 Auto-approve로 비교 실험합니다.
• List · Calendar · Executions · Logs 화면의 용도를 구분합니다.

이 실습은 주로 Schedule 화면에서 진행합니다. 잡 생성은 채팅으로 하므로 공통 준비의 세션 연결도 필요합니다.

□ Gateway가 실행 중이고 대시보드에 접속해 있다
□ Schedule 화면이  No scheduled jobs yet
□ Git 작업 트리에 수정(M)이 없다

번역: No scheduled jobs yet은 아직 예약된 작업이 없다는 뜻입니다.

이 실습의 잡은 2분 간격으로 반복됩니다. 관찰이 끝나면 반드시 Pause합니다. 그대로 두면 몇 분마다 실행이 반복됩니다.

5단계의 성공 결과는 Lab 1의 실습 데이터(labs/01-agent-creation/store)를 읽습니다. Lab 1을 마친 hands-on 클론이 있어야 같은 결말이 나옵니다.

실행 한 번이 수십 초에서 수 분 걸릴 수 있습니다. 기다리는 동안 화면별 역할과 실행 상태를 관찰합니다.

Schedule을 엽니다. 빈 화면에 두 가지 생성 경로가 안내됩니다.

[+ Create your first job]     or ask in chat — try "remind me to check my pipeline every morning"

번역: 첫 잡을 만들거나, 채팅에서 요청하세요 — “매일 아침 파이프라인을 확인하라고 알려 줘”처럼.

UI 폼과 채팅, 두 경로가 있습니다. 이 실습에서는 폼은 읽는 데 쓰고, 만드는 것은 채팅으로 합니다. 폼의 실행 동작은 2단계에서 한 줄로만 확인하고, 실제 잡은 cron_add로 만듭니다.

프리셋 카드(Dependency Guardian, Nightly Build Watch, Error Digest, Standup Brief)는 스케줄의 대표 용도를 보여 줍니다 — 주간 점검, 야간 빌드, 오류 요약, 스탠드업 브리핑. 카드마다 주기(Weekly · Mondays 6:00am, Every 24 hours · 2:00am)가 붙어 있습니다. 전부 사람이 없는 시각의 반복 작업입니다.

Add Job을 눌러 폼을 엽니다. 만들지는 않고 읽기만 합니다.

기본 필드는 다섯입니다 — Name(이름), Message(발화 시 에이전트에게 가는 프롬프트), Schedule(Every interval · Weekly schedule · Cron expression 세 방식), Agent, Model.

아래로 내리면 운영 옵션이 더 있습니다.

Approval 드롭다운을 열어 봅니다.

Default
Auto-approve

번역: Default는 도구 호출마다 승인을 기다리고, Auto-approve는 묻지 않고 실행합니다.

무인 실행에서 이 차이가 무엇을 만드는지는 5단계에서 실험합니다. 폼을 닫습니다.

이 버전에서는 폼으로 만든 잡의 실행이 실패합니다 — 폼이 기록하는 Agent 지정 값을 실행기가 해석하지 못하기 때문입니다. 이 실습에서는 그 사실만 확인하고, 잡 생성과 실행은 채팅 경로로 진행합니다.

아무 세션에서 입력합니다.

cron_add를 사용해 2분마다 실행되는 "NXT 아침 재고 점검" 작업을 만들어 줘.
내용은 "재고 점검 보고를 해 줘. 데이터가 없으면 없다는 사실만 보고한다."로 한다.

에이전트가 cron_add 도구를 로드해 잡을 만듭니다. @kirocrew-cron 도구들은 자동 승인 목록에 있어 승인 카드 없이 진행됩니다.

Message에 넣은 문장을 봐 둡니다 — “데이터가 없으면 없다는 사실만 보고한다”. Lab 4에서 배운 방어선을 무인 실행에도 건 것입니다. 이 한 줄이 5단계에서 일합니다.

Schedule 화면의 List 뷰로 돌아오면 잡이 보입니다 — Ready, NEXT RUN에 카운트다운이 표시됩니다. 시간이 이 작업의 시작 버튼입니다.

만든 직후 채팅에서 cron_trigger로 바로 실행하면 Job not found가 날 수 있습니다 — 실행 중인 스케줄러가 새 잡을 아직 메모리에 올리지 못한 동기화 지연입니다. 잠시 뒤에는 정상 동작합니다.

2분 안에 예약 발화가 옵니다 — 정해진 시각이 되어 Message가 에이전트에게 전달되는 것입니다.

이번에는 승인을 누르지 않습니다. 실행 중 알림 패널이나 세션에 승인 요청이 떠도 그대로 둡니다. Lab 5에서는 눌러서 진행시켰지만, 이 실습의 관찰 대상은 사람이 자리에 없는 무인 실행입니다.

기다리는 동안 실행이 어디에 보이는지 확인해 둡니다.

실행이 끝나면 Executions에 기록이 생깁니다. TRIGGER 컬럼을 봅니다 — 예약 발화는 scheduled, 사람이 Run 또는 Run Now를 누른 것은 manual로 구분됩니다.

실행 기록에는 cron-history 감사 정보도 남습니다. 진행 중인 실행은 Logs, 끝난 실행은 Executions에서 확인한다는 구분을 기억합니다.

예약 실행 결과를 열어 보면 상태는 OK인데 6분 넘게 걸렸고, 재고 수치가 없습니다. 요약을 읽습니다.

- 이번 실행에서 재고 파일 접근을 두 가지 방법으로 시도했으나 모두 거부되었습니다.
- 따라서 재고 데이터는 이번 세션에서 검증하지 못했습니다.
- "데이터 없음"이 아니라 "접근 거부로 확인 불가" 상태입니다 — 이 둘은 다릅니다.

원인은 Approval: Default입니다. 무인 실행도 도구를 쓰려면 승인이 필요한데, 승인을 눌러줄 사람이 없습니다. 에이전트는 파일 읽기를 두 번 시도했고, 두 번 다 거부된 채로 남은 것으로 확인된 사실만 보고했습니다.

Message의 방어선도 확인합니다. 추측으로 재고 수치를 만들지 않았고, “데이터 없음”과 “확인 불가”를 구분해 보고했습니다. 실패한 실행이 아니라, 할 수 없었던 것을 정확히 말한 실행입니다.

이제 승인 정책을 바꿔 다시 실행합니다. 잡 상세 Details 탭에서 Approval을 Auto-approve로 바꾸고 Save 후 Run Now를 누릅니다.

이번에는 파일을 읽었고, 실제 수치가 나왔고, 재고 부족까지 발견했습니다.

- store 폴더의 재고 파일 2개(inventory-status.md, orders-today.md)를 정상적으로 읽었습니다.
- 품목별 총재고는 mug 17, bottle 12, hub 13, sensor 11, cable 1이며,
  오늘 주문 5건 중 ORD-1043(cable 2개)이 재고(1개) 부족입니다.

같은 잡, 같은 Message로 두 실행을 이력에서 나란히 봅니다.

같은 잡, 같은 Message였습니다. Default는 승인 대기가 병목이 되어 느리고 확인을 못 한 채 끝날 수 있고, Auto-approve는 빠르지만 도구 사용을 묻지 않습니다. 무인 실행을 만들 때는 이 선택을 잡마다 정해야 합니다.

이 실습의 핵심 결론입니다. 스케줄 등록은 절반입니다. 나머지 절반은 첫 실행의 확인 — 트리거가 무엇이었고, 승인은 어떻게 처리됐고, 결과가 확인된 사실인지 확인 불가였는지까지 확인하는 것입니다. Default 실행은 승인 대기로 느려지고 확인 불가로 끝날 수 있고, Auto-approve 실행은 빠르지만 도구 사용을 묻지 않습니다.

Calendar 뷰로 전환합니다.

주간 그리드에 미래 실행 예정이 점으로 찍혀 있습니다. 상단의 타임존 선택(Render in Asia/Seoul (UTC+9))도 확인합니다. 분산된 팀이라면 “아침 9시”가 누구의 아침인지가 여기서 정해집니다.

반복 잡은 자동으로 사라지지 않습니다. 관찰이 끝나면 List 뷰에서 실습 잡을 Pause합니다. 이력을 남겨두고 싶으면 Pause로 충분하고, 완전히 지우려면 Delete합니다.

터미널에서 잡을 확인합니다.

kirocrew cron list

잡을 삭제한 경우에도 Executions 이력과 실행 기록 파일(~/.kiro/crew/cron-history/)은 남습니다. 이는 잡을 지워도 보존되는 감사 기록이므로 정상입니다.

cron-history에는 어떤 잡이 언제 실행되었고 어떤 트리거와 결과를 남겼는지 확인할 근거가 있습니다. 스케줄 운영은 잡을 등록하는 데서 끝나지 않고, 이 기록을 확인하는 데서 완성됩니다.

마지막 Lab 7은 무인 실행이 열어준 것 위에서 사람이 내려야 하는 결정을 다룹니다.

• Add Job 폼의 필드와 옵션 4종(Approval·Silent mode·Strict schedule·Hide in chat)을 읽었습니다.
• 채팅(cron_add)으로 2분 간격 잡을 만들었습니다.
• 예약 발화를 관찰하고 Logs(진행 중)와 Executions(완료)의 역할을 구분했습니다.
• TRIGGER 컬럼에서 scheduled와 manual을 구분했습니다.
• Default 실행에서 승인 거부와 “확인 불가” 보고를 확인했습니다.
• Auto-approve로 바꿔 실제 수치와 재고 부족, 소요 시간 차이를 확인했습니다.
• Pause 또는 Delete 후 kirocrew cron list와 감사 기록을 확인했습니다.

스케줄은 시간을 시작 버튼으로 만듭니다. 등록이 아니라 첫 실행의 확인까지가 설정입니다.

무인 실행의 도구 승인은 잡마다 정하는 선택입니다 — Default는 승인을 기다리다 확인 불가로 끝날 수 있고, Auto-approve는 빠르지만 묻지 않습니다.

진행 중은 Logs에, 완료는 Executions에, 미래는 Calendar에, 관리는 List에 있습니다. 이력을 보는 습관이 없으면 실패가 조용히 반복됩니다.

먼저 스스로 답해 본 뒤 접힌 답과 비교해 보세요.

실패한 잡이 3일 동안 조용히 실패를 반복했다면 어떻게 발견되는가? 어떻게 발견되게 만들 것인가?

Strict schedule은 언제 필요한가? 기본값은 왜 발화 시각을 분산하는가?

무인 실행에 Auto-approve를 줄 때 무엇을 확인해야 하는가?

스케줄의 Message에 Lab 2의 스킬 트리거 단어를 넣으면 무인 실행에도 스킬이 적용되는가?

Cron expression으로 “평일 아침 9시”를 표현해 보라. Weekly와 무엇이 다른가?

0 9 * * 1-5

이 스케줄로 “매일 아침 어제 세션 요약 보고”를 만든다면 Message를 어떻게 쓰겠는가?

핸즈온에서 만든 반복 스케줄을 여러분의 정기적인 확인 업무로 바꾸어 한 번 더 만들어 봅니다. 실제 민감 데이터나 회사 자료는 넣지 말고, 가상의 프로젝트명과 상태값으로 예약 메시지와 성공 여부 확인 절차를 연습하세요.

• 대학생: 매일 저녁 과제 마감 점검 잡을 만들어 보세요. 가상의 과목별 마감 목록에서 내일 마감 과제만 보고하게 하고, Executions에서 예약 실행이 성공했는지 확인합니다.
• 대학원생: 매주 연구 진행 점검 잡을 만들어 보세요. 가상의 실험 목록에서 지연된 항목과 다음 검토일을 요약하게 하고, 수동 트리거의 성공 이력과 실패 원인을 확인합니다.
• 교수: 매주 강의 준비 점검 잡을 만들어 보세요. 가상의 읽기자료·활동·평가 체크리스트를 보고하게 하고, Calendar에서 반복 시각을 확인한 뒤 Executions에서 결과를 검토합니다.
• 공공기관 재직자: 매일 업무 시작 전 가상의 민원 처리 현황 점검 잡을 만들어 보세요. 미처리 건수와 기한 임박 항목만 요약하게 하고, 실패가 반복되지 않도록 이력을 확인하는 절차를 함께 정합니다.
• 일반 직장인: 매일 아침 프로젝트 위험 신호 점검 잡을 만들어 보세요. 가상의 태스크 상태에서 지연·차단·담당자 미지정 항목을 보고하게 하고, List·Calendar·Executions·Logs를 각각 어떤 운영 확인에 쓸지 정리합니다.