배포 파이프라인이 끝나길 기다리는 상황이었습니다. 보통은 10분 안에 끝나지만 캐시가 깨지는 날은 40분 넘게 걸리기도 해서, 끝나는 시점을 예측하기 어려웠습니다. 매번 터미널 앞에서 기다리기도 그렇고, 5분마다 상태를 확인하는 Routine을 걸어두기도 애매했습니다.
어떤 작업이었나
배포 상태를 주기적으로 확인하다가 끝나면 알려주는 작업이었습니다. 처음엔 Claude Code Remote의 Routine을 5분 간격 크론으로 걸었는데, 보통 10분이면 끝나는 배포라 체크가 두세 번이면 충분한데도 "아직 배포 중"이라는 똑같은 응답이 계속 쌓였습니다. 반대로 캐시가 깨진 날은 40분이 지나도 5분마다 똑같은 질문을 반복하는 게 비효율적으로 느껴졌습니다. 고정 간격 하나로는 이 변동성을 감당하기 어려웠습니다.
AI를 어떻게 활용했나
이번엔 간격을 지정하지 않고 /loop 스킬을 그냥 호출했습니다.
/loop 배포 파이프라인 상태를 지켜보다가 끝나면 결과를 알려줘. 끝나면 루프도 멈춰줘.
간격을 명시하지 않으면 이 스킬은 "다이나믹 모드"로 동작합니다. 매 턴이 끝날 때마다 다음에 언제 다시 깨어날지를 세션이 직접 정해서 ScheduleWakeup을 호출하는 방식이었습니다. 첫 턴에서는 배포 상태를 확인하고 "아직 빌드 단계"라는 결과와 함께 300초 뒤 재확인을 걸었습니다. 이유를 물어보니 "배포 파이프라인이 평소 10분 안에 끝나는 걸 감안해 300초 간격으로 좁게 체크"라고 답했습니다. 세 번째 턴에서 배포가 20분을 넘기자, 다음 체크 간격이 300초에서 900초로 늘어났습니다. 평소보다 오래 걸리고 있으니 더 급하게 확인할 이유가 줄었다는 판단이었습니다.
배포가 끝나고 상태가 "성공"으로 바뀐 턴에서는 재확인을 걸지 않고 루프 자체를 멈췄습니다. 첫 프롬프트에 "끝나면 루프도 멈춰줘"라고 종료 조건을 넣은 게 실제로 반영된 셈입니다.
처음에 헷갈렸던 부분
처음 몇 번은 "아직 배포 중"이라는 똑같은 결과가 나올 때마다 세션이 매번 짧은 요약을 남겨서, 터미널 로그가 "별일 없음" 메시지로 채워졌습니다. 나중에 알고 보니 이 스킬은 각 턴마다 상태 변화가 없으면 noop으로 표시하도록 되어 있었고, 이런 턴들은 터미널 화면에서 연속으로 접혀서 표시됐습니다. 실제로 뭔가 바뀐 턴(배포 단계가 넘어갔거나, 실패했거나, 끝났을 때)만 펼쳐진 상태로 보여서, 로그를 처음부터 끝까지 읽지 않아도 중요한 지점만 눈에 들어왔습니다.
다른 하나는 체크 간격을 너무 좁게 잡지 않게 만드는 부분이었습니다. 배포 상태 확인처럼 바깥 상태를 직접 조회해야 하는 경우와, 이미 떠 있는 백그라운드 작업처럼 끝나면 알림이 저절로 오는 경우를 구분하지 않으면 후자까지 굳이 폴링을 걸게 되는데, 이번 배포 확인은 전자(외부 파이프라인 상태를 직접 들여다봐야 함)라서 다이나믹 루프를 쓸 이유가 있었습니다. 만약 같은 세션에서 돌린 백그라운드 빌드였다면 굳이 루프를 걸지 않고 빌드가 끝났다는 알림을 그냥 기다리는 게 맞았을 겁니다.
결과와 얻은 팁
- 고정 간격 Routine은 "몇 시에 한 번씩 확인"처럼 주기가 뻔한 작업에 맞고, 끝나는 시점이 들쭉날쭉한 모니터링 작업에는 다이나믹
/loop가 체크 횟수를 훨씬 줄여줬습니다. 이번 배포는 23분 걸렸는데 체크는 총 4번으로 끝났습니다. 5분 고정이었다면 같은 시간에 5번이었을 거고, 40분짜리였다면 8번이었을 걸 생각하면 체감 차이가 컸습니다. - 첫 프롬프트에 종료 조건("끝나면 멈춰줘")을 넣는 게 중요했습니다. 안 넣었을 때는 배포가 끝난 뒤에도 "모니터링을 계속할까요"라는 식으로 다음 체크를 또 걸어서, 직접 멈추라고 다시 말해줘야 했습니다.
- 이미 백그라운드로 돌고 있거나 Routine이 따로 깔려 있는 작업까지 다이나믹 루프로 다시 감쌀 필요는 없었습니다. 끝나면 알림이 오는 작업에 폴링을 또 얹으면 체크 횟수만 늘어날 뿐이었습니다.