AI 에이전트 만들기, 매일 돌리는 구조

실제로 하나를 만들어 매일 돌려 보려는 분께 맞춘 글입니다.

4주 동안 에이전트를 자동 실행하면서 확인한 구조는, 모델을 먼저 고르는 흐름보다 언제 실행할지와 어디까지 행동하게 할지, 결과를 누가 반영할지를 먼저 고정해야 다음 실행에서도 같은 방식으로 관리할 수 있다는 점에서 출발합니다. 한 번의 실행으로 끝나지 않습니다.

처음에는 글을 만들고 저장소에 반영하면 충분해 보입니다. 그러나 자동 실행에는 터미널에서 보이지 않던 함정이 남습니다.

먼저 결론부터

• 에이전트를 돌릴 때는 트리거, 도구 권한, 출력 경로 세 가지를 먼저 정하고 모델 선택은 그다음에 합니다.
• 우리는 macOS의 launchd로 매일 10시 30분에 실행하며, 잠자는 동안 놓친 일정만 깨어난 뒤 처리합니다.
• 헤드리스 실행에는 읽기·쓰기·검색과 git, gh, hugo처럼 필요한 도구만 명시합니다.

트리거 = launchd, 매일 10:30
허용 도구 = read, write, search, git, gh, hugo
출력 경로 = PR 생성만 허용
main 직접 push = 차단

• 에이전트는 PR만 열고 사람은 내용을 확인한 뒤 머지하므로, 잘못된 결과를 되돌릴 수 있습니다.
• 병렬 실행은 블로그별 저장소로 분리하고, 시작 전에 작업 폴더가 깨끗한지 확인한 뒤 지저분하면 건너뜁니다.
• 실행마다 세션 아이디를 로그에 남기고, PR 없이 끝난 실행과 자동 환경의 PATH·자격증명을 확인합니다.

매일 10시 30분에 깨웁니다

우리는 macOS에서 launchd를 실행기로 씁니다. 실행 시각은 매일 10시 30분입니다.

실행기 = launchd
시각 = 매일 10:30
잠자기 중 놓친 일정 = 깨어난 뒤 실행
전원이 꺼진 동안 놓친 일정 = 실행하지 않음

여기에는 실행 시각 외의 조건이 있습니다. launchd는 잠자는 동안 지나간 일정은 깨어나면 실행하지만 전원이 꺼져 있던 동안 지나간 일정은 버리므로, 매일 반드시 결과가 생긴다는 전제로 후속 작업을 묶으면 비어 있는 날의 처리를 따로 감당해야 합니다. 이 차이는 직접 실행하며 확인했습니다.

자동 실행 환경은 터미널과 다릅니다. PATH가 넘어오지 않을 수 있고, 보호된 폴더는 읽지 못하며, git 자격증명도 터미널의 것과 다를 수 있습니다. 터미널에서 성공한 명령을 자동 실행에도 그대로 기대하지 않습니다.

도구 권한의 경계

권한은 좁게 잡았습니다.

헤드리스 실행에서는 사람이 도중에 확인해 주지 않으므로, 읽기·쓰기·검색과 git, gh, hugo처럼 작업에 필요한 명령만 권한 목록에 넣어야 실행이 멈추지 않으면서도 허용 범위가 불필요하게 커지지 않습니다. 목록 밖은 실행하지 않습니다.

허용: 읽기, 쓰기, 검색
허용 명령: git, gh, hugo
허용하지 않음: 그 밖의 모든 도구와 명령

권한 목록은 작업 순서와 함께 봐야 합니다. 글을 읽고 작성한 뒤 저장소 상태를 확인하고 PR을 여는 흐름에 필요한 도구만 남기면, 사람 확인 없이 진행할 범위가 분명해집니다.

PR만 열도록 둡니다

출력 경로는 PR로 고정했습니다.

에이전트가 만든 결과를 바로 main에 반영하지 않고 PR만 열게 한 뒤 사람이 머지하도록 두면, 실행 자체는 자동으로 유지하면서도 잘못된 글이나 변경 사항을 저장소의 기본 이력에 넣기 전 확인할 수 있습니다. main 직접 push는 막아 뒀습니다.

이 구조가 되돌릴 수 있는 유일한 장치입니다. PR이 없으면 작업이 끝났다고 보지 않습니다.

병렬 실행의 작업 경계

같은 저장소에서 여러 에이전트를 돌리면 서로의 변경을 덮어쓸 수 있습니다. 우리는 블로그별로 저장소를 나눠 병렬로 띄웁니다.

시작 시점에는 작업 폴더가 깨끗한지 먼저 봅니다. 이전 실행이 남긴 파일이나 변경이 있으면 그 배치는 건너뜁니다. 이 확인을 빼면 새 작업과 이전 작업의 경계가 사라집니다.

시작 전 확인 = 작업 폴더가 깨끗한가
깨끗함 = 실행
지저분함 = 건너뜀
저장소 구성 = 블로그별 분리

조용한 실패와 세션 기록

가장 위험했던 문제는 실패가 드러나지 않은 경우였습니다. 글을 모두 쓴 뒤 커밋 직전에 한도에 걸려 실행이 죽었고 파일만 남았으며 PR이 열리지 않아 아무도 알아차리지 못했고, 다음 날에는 남은 파일 때문에 배치 전체가 멈췄습니다.

실행마다 세션 아이디를 로그에 적습니다. 나중에 같은 세션을 되살려 고칠 수 있기 때문입니다(실행 결과만 남기지 않습니다). PR 생성 여부와 세션 기록을 함께 보면, 중간에 멈춘 실행을 다음 배치 전에 찾을 수 있습니다.

마무리

첫 실행 전에는 실행 시각, 허용 도구, PR 생성 조건을 한 장의 설정으로 적어 두는 편이 좋습니다. 그다음에는 작업 폴더를 일부러 지저분하게 만든 경우와 PR 직전 실행이 멈춘 경우를 확인해 두면, 실제 배치에서 무엇을 봐야 할지 정할 수 있습니다.

여기 적은 깨진 지점은 공식 문서의 설정 항목만 읽어서 나오지 않았습니다. 공식 문서는 launchd, git, gh 같은 각 도구의 기능을 설명하지만, 저장소 분리 방식과 권한 목록, 실패 뒤 남은 파일이 다음 실행에 미치는 영향은 4주 동안 직접 돌린 운영 조건에서 생긴 기록이기 때문입니다.