코드 작성 다음으로 맡길 일: 작은 저장소의 에이전트형 CI

AI 코딩 도구를 이야기할 때는 새 기능을 만드는 장면이 자주 나옵니다. 작은 저장소를 혼자 관리할 때에는 새 기능보다 의존성 업데이트, 문서의 예제 수정, 실패한 테스트의 원인 좁히기처럼 반복되는 유지보수가 더 큰 부담일 수 있습니다. 에이전트형 CI는 이런 일을 저장소의 변경 흐름 안에서 맡기는 방식으로 소개되고 있습니다.

GitHub의 2026년 2월 글은 agentic CI를 실제로 자동화할 수 있는 작업과 아직 사람의 검토가 필요한 부분으로 나누어 설명합니다. 특정 도구를 직접 운영한 경험으로 말하지 않고, 공식 소개를 바탕으로 작은 저장소에서 시험할 수 있는 절차와 위험 경계를 정리하겠습니다. GitHub의 Continuous AI 사례 글은 공급사 관점의 안내라는 점을 염두에 두어야 합니다.

자동화 후보는 반복성과 실패 비용으로 고릅니다

에이전트에 맡길 일은 “AI가 잘할 것 같은 일”보다 실패했을 때 되돌리기 쉬운 일에서 고르는 편이 낫습니다. 문서 링크 확인, 린터가 지적한 단순한 형식 수정, 낮은 위험도의 의존성 변경은 결과가 작고 테스트하기 쉽습니다. 인증, 결제, 데이터 마이그레이션, 권한 정책처럼 잘못 바뀌면 복구가 어려운 코드는 첫 실험 대상으로 적절하지 않습니다.

작업 후보를 아래 세 질문으로 걸러 보십시오.

• 반복되는가: 사람이 매번 같은 절차를 수행하는 일인가요?
• 검증할 수 있는가: 테스트나 정적 분석으로 성공 조건을 확인할 수 있나요?
• 되돌릴 수 있는가: 변경 범위를 작은 pull request로 제한하고 쉽게 취소할 수 있나요?

세 질문 가운데 하나라도 답이 불분명하다면 자동 실행 대신 제안서나 draft pull request만 만들게 하십시오. “작업을 끝내라”는 넓은 지시보다 변경 파일, 허용 작업, 금지 영역, 성공 조건을 좁혀야 검토가 가능합니다.

저장소 권한과 실행 권한을 따로 설계합니다

에이전트가 코드를 읽을 수 있다는 것과 쓰거나 외부로 전송할 수 있다는 것은 다른 권한입니다. CI에 토큰이 연결되어 있다면 프롬프트가 의도하지 않은 동작을 유도하거나, 의존성 설치 스크립트가 권한을 악용할 가능성을 고려해야 합니다. 저장소 쓰기, Actions 실행, 네트워크 접근, 비밀값 읽기 권한을 한꺼번에 주지 말고 작업에 필요한 범위로 줄이십시오.

처음에는 비밀값을 읽지 못하는 별도 작업 흐름에서 제한된 쓰기 권한으로 결과만 제안하게 할 수 있습니다. 외부 네트워크가 필요 없는 일은 네트워크를 막고, 설치 스크립트를 실행해야 한다면 허용할 도메인이나 패키지 범위를 정합니다. 생성된 변경은 사람이 확인하기 전에 기본 브랜치로 합쳐지지 않도록 보호 규칙도 점검해야 합니다.

여기서 중요한 것은 설정 이름보다 실제 권한 경로입니다. 재사용 워크플로, 조직 수준의 토큰, 앱 설치 권한, 저장소 정책이 서로 어떻게 연결되는지 확인하십시오. 모델이 “완료”라고 보고했다는 이유로 CI 로그나 diff 검토를 생략하지 않습니다.

한 가지 작업으로 기준선을 만듭니다

작은 실험은 자동화 전후의 시간을 비교하는 데서 끝나지 않습니다. 사람이 결과를 다시 고치는 시간, 잘못된 제안이 만든 잡음, 실패 시 복구 시간도 비용에 포함해야 합니다. 작업 종류와 대상 브랜치를 고정하고, 몇 차례 실행에서 성공·수정·폐기한 결과를 기록하면 막연한 인상보다 유용합니다.

예를 들어 문서 예제의 링크를 확인하는 작업이라면 입력 문서 목록, 링크 상태 확인 방법, 자동 변경을 허용할 범위, 실패 처리 규칙을 명시합니다. 결과 pull request에는 변경 요약과 검사 결과가 포함되게 하고, 대상 링크가 로그인이나 지역 제한에 따라 달라질 수 있으면 자동 수정하지 않고 검토 요청으로 남기게 합니다.

성공 기준도 “열린 PR 수”가 아니라 유효한 수정 비율, 사람이 들인 검토 시간, 잘못된 자동 변경 수, 되돌린 변경 수로 잡을 수 있습니다. 작은 팀은 지표 수집을 위해 별도 시스템을 만들 필요까지는 없습니다. 간단한 기록표에서 각 실행 결과와 수정 시간을 남기는 것으로도 다음 판단에 도움이 됩니다.

자동 실행보다 중단 조건이 먼저입니다

저장소 구조가 크게 바뀌었거나 테스트가 안정적이지 않으면 에이전트형 CI가 문제를 좁히기보다 새로운 변경을 더할 수 있습니다. 작업이 예상보다 많은 파일을 수정할 때, 권한 오류가 나타날 때, 테스트가 실패했는데 원인이 코드인지 환경인지 불분명할 때는 자동화를 멈추고 사람에게 넘기는 조건을 둡니다.

일정 기간 제안만 받는 관찰 단계를 두고, 결과가 안정된 뒤에도 자동 병합은 별도로 검토하십시오. 저장소에서 허용되는 작업과 검토자를 바꾸었다면 설정 변경 이유와 날짜를 남깁니다. 공급사의 제품 기능과 가격, 지원되는 워크플로는 변할 수 있으므로 실제 도입 시점에 공식 문서를 다시 확인해야 합니다.

작업 프롬프트에는 실행 권한을 설명하는 문구도 넣을 수 있습니다. 예를 들어 테스트와 린터는 허용하지만 배포, 패키지 게시, 프로덕션 데이터 변경은 금지한다고 씁니다. 도구 설정이 이 구분을 실제로 강제하는지 확인해야 하며, 자연어 지시만으로 시스템 권한이 제한된다고 생각해서는 안 됩니다.

실패 작업의 로그에는 저장소 내용이나 비밀값이 섞일 수 있으므로 공개 범위와 보관 정책도 점검하십시오. 자동화가 생성한 이슈나 pull request를 외부 사용자도 볼 수 있는 저장소에서 다룬다면, 로그와 설명문에 내부 경로나 개인 정보가 들어가지 않는지 살펴야 합니다.

에이전트가 만든 변경을 사람이 검토할 수 있도록 PR 설명에 목표, 영향 범위, 검사 요약을 자동으로 넣게 할 수도 있습니다. 다만 설명이 원본 변경과 일치하는지 검토해야 하며, 생성된 요약을 근거 자료처럼 다시 사용하지 마십시오. 변경을 만든 주체와 승인한 사람을 구분해 기록하면 사후에 책임 경로를 확인하기 쉽습니다.

마치며

에이전트형 CI는 반복 업무의 초안을 만드는 데 쓸 수 있지만, 저장소의 책임자를 대신하지는 않습니다. 되돌리기 쉬운 작업 하나를 선택하고 권한·검증·중단 조건을 문서로 잠근 뒤 제한된 pull request로 실험해 보십시오. 첫 단계의 목표는 자동 변경을 늘리는 것이 아니라, 사람이 결과를 검토할 수 있는 흐름을 만드는 것입니다.