심화 가이드AI 심화내 목적에 맞추기

AI가 저장소의 악성 코드를 발견했다면? 코드 리뷰와 공급망 보안의 경계

한 개발자의 AI 코드 검토 사례를 통해 의심스러운 변경을 확인할 때 AI의 역할과 의존성 검토·빌드 환경·사람의 대응을 살펴봅니다.

남다른AI작성·수정 기준
본문 설명과 연결된 이미지
내용 이해를 돕는 개념 일러스트입니다.

AI 코딩 도구가 코드 변경을 읽다가 낯선 패턴을 발견하면, 개발자가 놓쳤을 수 있는 질문을 제기하는 데 도움이 될 수 있습니다. 그러나 AI의 경고 한 번이나 “문제가 없다”는 답변 하나로 저장소 전체의 안전을 판단할 수는 없습니다. 변경의 출처와 실행 경로를 확인하고, 독립적인 보안 검사와 사람의 판단을 함께 사용해야 합니다.

한 개발자는 공개 게시물에서 Claude Code가 브랜치를 합치는 과정에서 수상한 코드 변경을 발견해 병합과 빌드를 멈췄다고 설명했습니다. 이는 작성자가 공개한 경험담이며, 이 글에서 해당 저장소나 감염 과정을 독립적으로 조사한 것은 아닙니다.

무엇이 문제였다고 주장했나요?

게시물 작성자에 따르면 평소처럼 들어온 변경의 설정 파일 끝에 난독화된 코드가 추가되어 있었습니다. 작성자는 AI가 해당 변경을 실행하기 전에 코드 차이, 즉 diff에서 이상 징후를 발견했다고 말합니다. 또한 감염 경로에 대해서는 외부 개발자의 기기를 직접 포렌식할 수 없어 확정하지 못했다고 밝혔습니다.

여기서 구분할 점은 세 가지입니다.

  • 작성자의 설명: 에이전트가 병합 전 의심스러운 변경을 발견했다는 경험담입니다.
  • 확인하지 못한 것: 이 글은 실제 저장소의 코드, 기기 감염 경로와 피해 여부를 독립 검증하지 않았습니다.
  • 실무적으로 생각해 볼 점: 정상적인 개발 흐름에 들어온 변경이라도 실행 전에 출처와 내용을 검토할 필요가 있습니다.

한 사례가 흥미롭다고 해서 AI가 모든 악성 코드를 탐지한다거나, 모든 AI 코딩 도구가 같은 방식으로 병합을 차단한다고 일반화해서는 안 됩니다.

소프트웨어 공급망은 왜 중요한가요?

소프트웨어는 작성한 코드만으로 만들어지지 않습니다. 외부 패키지, 빌드 도구, 개발자 계정, 저장소와 배포 과정이 함께 연결됩니다. 그중 한 경로가 변조되면 정상적으로 보이는 개발 절차를 통해 문제가 전달될 수 있습니다.

예를 들어 새로운 패키지가 추가됐을 때는 이름만 보지 말고 왜 필요한지, 어디에서 왔는지, 어떤 버전인지 확인할 수 있습니다. 빌드 설정에 변경이 있다면 화면에 표시되는 기능이 아니라도 빌드나 배포 과정에 영향을 주는지 살펴봐야 합니다. 이는 일반적인 확인 예시이며 위 게시물의 실제 감염 경로를 단정하는 설명이 아닙니다.

GitHub의 의존성 변경 검토 안내는 풀 리퀘스트에서 추가·삭제·변경된 의존성과 알려진 취약점 정보를 확인하는 기능을 설명합니다. 알려진 취약점 검사도 모든 새로운 악성 행위를 자동으로 찾아내지는 못합니다.

AI는 검토 과정에서 어떤 역할을 할 수 있나요?

AI에게 변경된 파일의 목적을 설명하게 하거나, 기존 설정과 달라진 부분을 요약하고, 사람이 더 확인할 질문을 정리하게 할 수 있습니다. 다만 AI가 설명을 그럴듯하게 만들 수 있다는 사실과 설명이 정확하다는 사실은 다릅니다.

검토 단계할 수 있는 질문별도로 확인할 것
변경 내용어떤 파일과 설정이 바뀌었나요?실제 diff가 설명과 일치하는가
의존성새 패키지는 왜 필요한가요?출처·버전과 알려진 취약점을 확인했는가
실행 범위빌드나 배포 때 무엇이 실행되나요?계정 권한과 네트워크 접근 범위는 적절한가
결과 보고무엇을 확인했고 무엇을 못 봤나요?독립 검사와 사람의 검토가 필요한가

위 표는 실무에 적용할 수 있는 편집 제안입니다. AI가 자동으로 악성 여부를 판정하거나 특정 검사를 실행했다고 가정하지 않습니다.

의심스러운 변경을 발견하면

1. 먼저 실행과 병합을 멈춥니다

의도를 설명할 수 없는 설정이나 의존성이 발견됐다면, 확인이 끝날 때까지 해당 변경을 빌드하거나 배포하지 않는 선택을 고려합니다. 확인을 위해 의심 코드를 무심코 실행하는 일도 피해야 합니다.

2. 실제 변경과 출처를 확인합니다

누가 어떤 경로로 변경을 올렸는지, 원래 요청한 작업과 관련이 있는지 살펴봅니다. 작성자 이름만으로 실제 작성자를 확정할 수는 없습니다. 필요한 경우 저장소 관리자나 보안 담당자와 확인합니다.

3. 영향 범위를 조사합니다

이미 빌드나 배포가 이루어졌는지, 어떤 환경과 자격증명이 접근 가능했는지 조직의 사고 대응 절차에 따라 확인합니다. 노출 가능성이 있다면 담당자의 판단에 따라 자격증명 교체 등 대응을 진행합니다. 모든 의심 사례의 원인과 조치가 같지는 않습니다.

4. 검증 결과와 미확인 항목을 남깁니다

실행한 검사, 확인한 버전, 조사하지 못한 부분을 구분하면 다른 담당자가 이어서 판단하기 쉽습니다. AI가 작성한 보고서도 근거와 실제 검사 결과를 대조해야 합니다. 일반적인 코드 변경 검토는 AI 코딩 결과 확인 가이드를 함께 볼 수 있습니다.

자주 묻는 질문

AI가 악성 코드를 발견했다면 보안 도구는 필요 없나요?

그렇지 않습니다. AI의 설명은 검토를 돕는 한 자료이며, 의존성 검사와 권한 관리, 독립적인 보안 조사 등을 대체한다고 볼 근거는 없습니다.

알려진 취약점 검사를 통과하면 안전한가요?

알려진 취약점 정보에 없는 문제나 새로 유입된 악성 변경은 다른 방식의 검토가 필요할 수 있습니다. 통과 결과가 검사 범위 전체의 안전을 보장하지는 않습니다.

게시물에 나온 감염 경로는 확인된 사실인가요?

작성자 본인은 외부 개발자 기기의 정확한 감염 경로를 포렌식으로 확인할 수 없다고 밝혔습니다. 이 글에서도 그 경로를 확정하지 않습니다.

참고 자료


다음 한 걸음

내 환경에서 막힌 부분은 실행 단계와 함께 질문해 주세요. 바꿔 만든 결과도 함께 나눌 수 있습니다.