AI 코드리뷰 봇은 이제 CI의 입력값이다
요즘 GitHub의 가장 위험한 텍스트는 이상한 쉘 원라이너가 아닐 수 있다. 평범한 PR 설명, 이슈 댓글, 설정 파일의 한 줄이 더 흥미로운 위치로 올라왔다. 사람이 읽으면 그냥 문장인데, 저장소 권한을 가진 AI 에이전트가 읽으면 작업 지시가 될 수 있기 때문이다.
2026년 6월 공개된 논문 GitInject는 이 불편한 지점을 정면으로 건드린다. 연구진은 AI 코드리뷰, 이슈 triage, 저장소 유지보수 같은 작업에 붙은 에이전트가 실제 GitHub Actions 워크플로 안에서 어떻게 프롬프트 인젝션에 노출되는지 평가했다. 중요한 점은 벤치마크 흉내가 아니라 실제에 가까운 임시 저장소와 워크플로 실행을 사용했다는 것이다.
조금 앞서 나온 Agentic Workflow Injection 연구도 비슷한 결론으로 향한다. 문제는 모델이 멍청해서만 생기지 않는다. GitHub 이벤트 컨텍스트, 워크플로 권한, 시크릿 노출 범위, 후속 스크립트가 한 줄로 이어지는 구조가 공격면을 만든다.
프롬프트 인젝션이라는 이름이 작아 보이는 순간
프롬프트 인젝션이라는 말은 오래전부터 있었다. 그래서 오히려 익숙해져 버렸다. 챗봇에게 이상한 문장을 넣어 규칙을 우회하는 장난처럼 들리기도 한다. 하지만 CI/CD 안으로 들어오면 톤이 달라진다.
AI 코드리뷰 봇은 대개 다음을 본다.
- PR 제목과 본문
- diff와 파일 내용
- 이슈 댓글
- 저장소 설정 파일
- 테스트 결과와 로그
- 때로는 GitHub 토큰, 체크 실행 권한, 댓글 작성 권한
이 중 상당수는 신뢰할 수 없는 입력이다. 외부 기여자가 PR을 열 수 있는 오픈소스 저장소라면 특히 그렇다. 그런데 워크플로는 이 입력들을 AI에게 넘기고, AI의 출력을 다시 스크립트나 GitHub API 호출에 연결한다.
그 순간 PR 본문은 문서가 아니라 파이프라인 입력값이 된다.
GitInject가 찌른 부분
GitInject 연구의 흥미로운 대목은 특정 모델 하나를 망신 주는 방식이 아니라는 데 있다. 논문은 여러 AI 제공자와 워크플로 구성을 대상으로, 설정 파일 주입, 판단 조작, 가용성 방해, 민감 정보 노출 가능성 같은 공격 클래스를 관찰한다. 연구진의 결론도 모델 성능보다 구조에 더 무게를 둔다. 취약성은 모델 하나의 성격보다 CI/CD가 자격 증명과 설정 파일을 다루는 방식에서 자주 나온다는 것이다.
이 말은 방어 관점에서 꽤 차갑다. 더 똑똑한 모델로 바꾸면 해결된다는 기대가 약해진다. 모델은 입력을 해석하는 층이고, 권한은 워크플로가 준다. 도구 호출은 시스템이 연결한다. 결국 사고가 나면 책임은 프롬프트가 아니라 배선에 있다.
간단히 그리면 이런 구조다.
untrusted GitHub event
-> AI prompt context
-> model output
-> workflow step / GitHub API / comment / patch
-> repository side ```effect
여기서 보안팀이 봐야 할 지점은 가운데의 모델만이 아니다. 앞의 입력 경계와 뒤의 side effect가 더 중요하다.
## AWI: GitHub Actions식 오염 추적
Agentic Workflow Injection 논문은 이 문제를 더 정적 분석에 가까운 언어로 설명한다. 연구진은 GitHub Actions에서 AI 에이전트가 이슈 본문, PR 설명, 댓글 같은 untrusted event context를 프롬프트나 후속 스크립트로 흘려보내는 패턴을 AWI라고 부른다.
논문은 두 가지 흐름을 구분한다.
| 패턴 | 의미 |
| --- | --- |
| Prompt-to-Agent | 신뢰할 수 없는 텍스트가 에이전트 프롬프트 경계로 직접 들어감 |
| Prompt-to-Script | 에이전트 출력이 다시 스크립트나 워크플로 로직으로 이어짐 |
이 구분은 실무적으로 유용하다. 전자는 AI에게 무엇을 읽히는지의 문제이고, 후자는 AI가 말한 것을 시스템이 얼마나 믿는지의 문제다. 많은 팀이 첫 번째는 신경 쓰기 시작했지만, 두 번째는 아직 편의 기능처럼 취급한다. 예를 들어 AI가 만든 라벨, 명령, 패치 제안을 뒤 단계에서 자동 실행한다면 이미 일반적인 코드리뷰 봇보다 훨씬 강한 권한을 준 셈이다.
## 시크릿은 모델이 훔치는 게 아니라 워크플로가 보여준다
AI 보안 이야기는 종종 모델을 의인화한다. 모델이 속았다, 모델이 유출했다, 모델이 공격했다. 하지만 CI 안에서는 좀 더 건조하게 봐야 한다. 모델은 접근 가능한 컨텍스트 안에서 다음 토큰을 만든다. 시크릿이 노출된다면 대개 그 전에 누군가가 시크릿이 있는 환경을 모델 주변에 놓았다.
그래서 방어도 프롬프트 문구보다 운영 원칙에서 시작해야 한다.
- 외부 PR에서 도는 AI 워크플로에는 최소 권한 토큰을 쓴다.
- PR 본문, 이슈 댓글, diff는 모두 untrusted input으로 표시하고 다룬다.
- AI 출력은 명령이 아니라 제안으로 취급한다.
- 민감 작업은 별도 승인 경계를 둔다.
- 로그, 설정 파일, 워크플로 산출물이 모델 컨텍스트에 섞이는 경로를 점검한다.
여기서 핵심은 “AI에게 조심하라고 말하기”가 아니다. 조심해야 할 것은 모델이 아니라 파이프라인 설계다.
## 개발자 경험과 보안 경계가 충돌하는 곳
AI 코드리뷰 봇이 사랑받는 이유는 명확하다. 지루한 리뷰를 줄이고, 컨텍스트 전환을 덜고, 새 기여자에게 빠르게 피드백을 준다. 문제는 바로 그 편의성이 권한 상승의 유혹을 만든다는 점이다.
처음에는 댓글만 달게 한다. 다음에는 라벨을 붙이게 한다. 그다음에는 간단한 수정 PR을 만들게 한다. 어느 순간 봇은 사람 리뷰어의 보조가 아니라 저장소 운영자의 일부가 된다. 이 변화는 기능 로드맵에는 잘 보이지만, threat model에는 늦게 반영된다.
특히 오픈소스 저장소에서는 기여자가 공격자일 수 있다는 오래된 가정이 다시 중요해진다. 기존 CI 보안에서는 fork PR, pull_request_target, secret exposure 같은 주제가 이미 익숙했다. AI 에이전트는 여기에 자연어 해석 계층을 하나 더 얹는다. 새로운 마법이 아니라, 오래된 CI 위험에 더 넓은 입력 포맷이 붙은 것이다.
## 지금 읽을 만한 이유
GitInject와 AWI 연구가 재미있는 이유는 공포 마케팅보다 현실감이 강해서다. “AI가 위험하다”는 큰 문장 대신, “이 GitHub 이벤트 값이 이 프롬프트로 들어가고, 그 출력이 이 워크플로 단계로 간다”는 식의 추적이 가능해지고 있다. 보안 리서치가 드디어 AI 에이전트를 막연한 블랙박스가 아니라 소프트웨어 공급망의 한 구성요소로 다루기 시작한 셈이다.
아직 모든 저장소가 위험하다고 말할 수는 없다. 논문별 threat model과 실험 조건도 다르고, 실제 제품들은 계속 방어책을 바꾼다. 다만 방향은 분명하다. AI 리뷰어를 붙이는 일은 더 이상 README 배지 하나 추가하는 정도의 결정이 아니다. 저장소에 새 자동화 주체를 들이는 일이고, 그 주체가 읽는 텍스트와 행사할 수 있는 권한을 분리해서 봐야 한다.
한 줄로 줄이면 이렇다.
```text
AI agent security is CI/CD security with natural-language inputs.
그리고 이 문장은 2026년의 GitHub에서 꽤 실용적인 threat model이 됐다.
