집에 있는 Windows PC를 self-hosted GitHub Actions Runner로 연결하면 휴대폰에서도 작업을 시작하고 결과를 받을 수 있다. 작은 개인 프로젝트에서는 꽤 편리하지만, 편리한 만큼 “내 컴퓨터에서 원격 작업이 실행된다”는 사실을 먼저 생각해야 한다.
러너는 단순한 빌드 서버가 아니다
self-hosted runner에서 실행되는 스크립트는 해당 PC의 파일과 네트워크에 접근할 수 있다. 그래서 저장소에 적힌 workflow를 신뢰할 수 있는지, 외부에서 들어온 코드가 자동 실행될 수 있는지, 어떤 계정 권한으로 runner 서비스가 동작하는지를 먼저 확인해야 했다.
특히 AI agent가 workflow나 스크립트를 수정할 수 있다면 작업 범위를 더 좁혀두는 편이 낫다. 자동화의 목적은 승인 과정을 없애는 것이 아니라 반복 작업을 안전한 범위 안에서 줄이는 것이다.
토큰은 하나로 다 해결하지 않는다
처음에는 하나의 GitHub 토큰에 여러 권한을 주면 편하다. 하지만 그 토큰이 로그나 잘못된 설정을 통해 노출되면 피해 범위도 함께 커진다.
그래서 자동화마다 필요한 권한을 나눠 생각하는 것이 좋다. 코드를 읽는 작업, 브랜치에 쓰는 작업, Actions를 실행하는 작업이 정말 같은 자격 증명을 필요로 하는지 확인한다. 비밀값은 코드나 프롬프트 안에 직접 넣지 않고 GitHub Secrets 같은 별도 저장소에서 주입한다.
실패했을 때 원복할 수 있어야 한다
AI가 작업을 자동으로 수행하게 할수록 성공 경로보다 실패 경로가 중요했다. 허용하지 않은 파일을 수정하거나, Windows runner에서 동작하지 않는 명령을 실행하거나, 테스트를 임의로 추가하는 경우를 생각해야 한다.
작업 전에 변경 허용 경로를 정하고, 예상 범위를 벗어난 변경은 실패 처리하며, Git 상태를 기준으로 원복할 수 있게 해두면 자동화가 잘못된 방향으로 오래 진행되는 것을 막을 수 있다.
자동화는 마지막 단계가 아니라 경계 설정부터 시작한다
runner를 붙이는 일 자체는 어렵지 않다. 오래 운영하려면 누가 무엇을 실행할 수 있는지, 어떤 파일을 바꿀 수 있는지, 실패하면 어디까지 되돌릴지를 먼저 정해야 한다. 자동화의 품질은 성공 횟수보다 실패가 안전하게 끝나는지에서 더 잘 드러난다.