AI 리뷰어가 CI 비밀을 읽는 순간
Pull request에 남긴 한 줄짜리 문장이 빌드 로그와 토큰의 경계를 흔들 수 있다면, 문제는 더 이상 "모델이 말을 잘 듣느냐"가 아니다. 이제 질문은 더 불편해진다. 우리는 AI 리뷰어에게 코드만 보여준다고 생각했지만, 실제로는 저장소 권한과 CI 환경까지 함께 맡기고 있었던 것 아닐까.
최근 공개된 GitInject: Real-World Prompt Injection Attacks in AI-Powered CI/CD Pipelines는 이 지점을 정면으로 찌른다. 연구진은 실제 GitHub 워크플로우를 띄워 AI 기반 PR 리뷰·이슈 처리 구성을 평가했고, 기본 설정의 여러 AI 제공자 조합이 적어도 하나 이상의 공격 유형에 취약할 수 있다고 보고했다. 중요한 건 이 결과를 "어느 모델이 더 멍청한가"로 읽으면 핵심을 놓친다는 점이다.
논문이 말하는 더 큰 결론은 구조적이다. AI 에이전트는 외부 입력을 읽고, CI는 비밀값과 권한을 들고 있으며, GitHub 이벤트는 공격자가 비교적 쉽게 텍스트를 밀어 넣을 수 있는 입구다. 이 세 가지가 한 워크플로우 안에서 만나는 순간, 프롬프트 인젝션은 챗봇 장난이 아니라 공급망 보안 이슈가 된다.
프롬프트가 아니라 배관의 문제
기존의 프롬프트 인젝션 논의는 종종 모델 입력창 주변에서 멈췄다. "악성 지시문을 무시하라"는 시스템 프롬프트를 더 단단히 쓰면 되는 것처럼 보이기도 했다. 하지만 CI/CD 안의 AI 에이전트는 그런 단순한 그림과 다르다.
GitHub Actions 위에서 동작하는 에이전트는 보통 다음 요소를 함께 만진다.
| 요소 | 보안상 의미 |
|---|---|
| PR 본문, 코멘트, 이슈 내용 | 공격자가 제공할 수 있는 비신뢰 입력 |
| 워크플로우 환경 변수 | 토큰, 배포 권한, 내부 설정이 섞일 수 있는 공간 |
| 체크 결과와 리뷰 코멘트 | 저장소 의사결정에 영향을 주는 출력 |
| 자동 수정·라벨링·머지 보조 | 단순 응답을 넘어선 행위 권한 |
이 조합에서는 모델이 "텍스트를 생성한다"는 사실보다, 그 텍스트가 다음 단계의 스크립트나 권한 있는 액션으로 이어질 수 있다는 사실이 더 중요하다. 최근의 Agentic Workflow Injection 연구도 비슷한 문제를 GitHub Actions 생태계에서 관찰했다. 비신뢰 GitHub 이벤트가 에이전트 프롬프트나 후속 스크립트로 흘러 들어가면, 워크플로우 자체가 공격 경로가 될 수 있다는 주장이다.
왜 지금 이 이야기가 뜨거운가
AI 코드 리뷰어는 편하다. 지친 유지보수자는 놓친 테스트를 봐주는 봇이 반갑고, 작은 오픈소스 프로젝트는 사람 리뷰어보다 빠른 자동 피드백에 기대기 쉽다. 문제는 편의가 권한을 부른다는 점이다. 처음에는 "리뷰만" 하던 봇이 이슈를 분류하고, 라벨을 붙이고, 패치를 제안하고, 때로는 브랜치에 커밋까지 한다.
보안 관점에서 보면 이는 낯선 일이 아니다. 과거에도 CI는 공급망 공격의 좋은 표적이었다. 차이는 이제 공격 표면에 자연어가 들어왔다는 것이다. YAML 오타나 셸 인젝션만 보는 시대에서, PR 설명과 리뷰 코멘트가 권한 흐름의 일부가 되는 시대로 넘어가고 있다.
여기서 흥미로운 긴장은 두 가지다.
- AI 에이전트는 사람처럼 문맥을 읽어야 쓸모가 있다.
- 하지만 보안 경계는 문맥이 아니라 신뢰 수준으로 나뉘어야 한다.
이 둘은 자주 충돌한다. 에이전트에게 "PR의 의도를 파악하라"고 하면 공격자가 쓴 설명도 읽어야 한다. 반대로 외부 입력을 지나치게 격리하면 에이전트는 리뷰어로서 쓸모가 줄어든다. 최근 "AI agents may always fall for prompt injections" 류의 연구가 던지는 불편한 메시지도 여기에 닿아 있다. 방어는 가능하지만, 자연어 문맥을 완전히 무해한 데이터로 만들기는 어렵다.
읽어야 할 신호
GitInject를 단순한 PoC 공개로 소비하면 아쉽다. 더 생산적인 독해는 다음 질문을 남기는 것이다.
- 우리 저장소의 AI 워크플로우는 외부 입력과 비밀값을 같은 실행 경계 안에 두는가?
- 에이전트 출력이 후속 스크립트, 라벨, 승인, 배포 판단에 직접 연결되는가?
- PR 작성자와 저장소 관리자 사이의 권한 차이가 워크플로우에서도 유지되는가?
- AI 리뷰 실패를 모델 품질 문제로만 보고 있지는 않은가?
특히 세 번째 질문이 중요하다. GitHub에서 PR 작성자는 원래 제한된 권한을 가져야 한다. 그런데 AI 에이전트가 그 PR 내용을 읽고 더 높은 권한의 CI 컨텍스트에서 행동한다면, 권한 모델이 우회될 가능성이 생긴다. 이것은 "프롬프트를 잘 써야 한다"보다 훨씬 오래된 보안 원칙의 문제다.
당장 얻을 교훈
이 글은 악용 절차를 다루지 않는다. 대신 운영자가 기억할 만한 방향은 비교적 명확하다.
- AI가 읽는 입력과 비밀값이 있는 실행 환경을 분리한다.
- PR, 이슈, 코멘트처럼 외부 작성 가능한 텍스트는 기본적으로 비신뢰 데이터로 본다.
- 에이전트가 만든 출력이 스크립트나 배포 단계로 자동 연결될 때는 별도 검증 단계를 둔다.
- 저장소 토큰 권한은 워크플로우별로 최소화한다.
- AI 리뷰어를 사람 리뷰어의 대체재가 아니라 권한 제한된 보조 도구로 설계한다.
결국 GitInject가 흥미로운 이유는 AI 보안 논의를 모델 내부에서 현실의 자동화 배관으로 끌어냈기 때문이다. 보안 사고는 종종 가장 똑똑한 구성요소가 아니라, 서로 신뢰하면 안 되는 구성요소들이 편의상 붙어 있을 때 발생한다.
AI 리뷰어가 코드를 읽는 것은 괜찮다. 하지만 그 리뷰어가 어떤 문장을 누구의 권한으로 읽고, 어떤 토큰을 곁에 둔 채 판단하는지는 이제 더 꼼꼼히 물어야 한다. GitHub Actions의 초록색 체크 표시가 늘 안전을 뜻하지는 않는다. 때로는 그저 자동화가 성공적으로 위험한 일을 끝냈다는 뜻일 수도 있다.
