AI IDE, MCP, 자동화 연결은 단순한 편의 도구가 아니라 개발 프로세스의 신뢰 경로를 바꾸는 공급망 자산이다. 이제 공급망 보안은 오픈소스 목록을 넘어, 어떤 도구와 연결에 개발 흐름의 일부를 위임하고 있는지까지 봐야 한다.
이 글은 CVE 이후의 보안 시리즈의 네 번째 글이다.
- 1편: CVE 이후 대응만으로는 늦다: AI 시대 취약점은 번호가 붙기 전에 움직인다
- 2편: AI Slop의 역설: 취약점을 더 잘 찾는 시대에 triage가 더 어려워지는 이유
- 3편: 보안진단은 외주 업무가 아니라 개발 공정이 된다
- 4편: 공급망 보안은 SBOM만으로 끝나지 않는다: AI 개발 도구와 자동화 연결 관리
앞선 글에서는 CVE/NVD 중심 대응의 한계, AI slop과 triage 비용, 보안진단 운영모델 전환을 다뤘다. 이번 글에서는 공급망 보안의 범위를 AI 개발 도구, MCP, 자동화 연결, 개발 환경 거버넌스까지 확장해 본다.
1. 공급망 보안을 너무 좁게 보고 있었다
공급망 보안이라고 하면 보통 먼저 떠올리는 것은 오픈소스 라이브러리다.
어떤 패키지를 쓰는가.
어떤 버전인가.
알려진 취약점이 있는가.
라이선스는 괜찮은가.
SBOM은 있는가.
이 질문들은 여전히 중요하다. 하지만 이제 충분하지 않다.
개발 환경이 바뀌고 있기 때문이다.
개발자는 더 이상 IDE와 터미널만 쓰지 않는다. AI IDE, 코딩 보조 도구, MCP 기반 연결, 이슈 관리 연동, 코드 저장소 연동, 문서 검색, CI/CD 상태 확인 같은 여러 도구를 함께 쓴다.
이 도구들은 단순한 편의 기능으로만 머물지 않는다. 개발자의 작업 흐름 안에서 코드 변경, 검토 요청, 이슈 정리, 테스트 결과 해석, 배포 준비 같은 과정에 영향을 준다.
영향을 주는 도구는 공급망의 일부다.
2. SBOM은 출발점이지 끝이 아니다
SBOM은 중요한 기반이다.
조직이 어떤 라이브러리와 패키지를 사용하는지 모르면 취약점 영향도를 판단할 수 없다. CVE가 공개되어도 내부 사용 여부를 모르면 대응은 늦어진다.
하지만 SBOM은 주로 소프트웨어 구성요소를 다룬다. 그것만으로는 개발과 배포 과정의 전체 신뢰 경로를 설명하지 못한다.
예를 들어 다음 질문은 SBOM만으로 답하기 어렵다.
- 어떤 팀이 어떤 AI 개발 도구를 사용하는가?
- 그 도구는 어떤 내부 시스템과 연결되는가?
- MCP 기반 연결은 누가 관리하고 승인하는가?
- 개발 도구가 생성한 변경 사항은 어떤 검토 절차를 거치는가?
- 자동화 결과가 코드 저장소, 이슈 관리, 빌드 파이프라인과 어떻게 이어지는가?
- 도구 설정 변경은 누가 검토하고 기록하는가?
- 개발 환경에서 발생한 자동화 활동은 어느 정도 추적 가능한가?
이 질문들은 공급망 보안의 질문이다.
다만 전통적인 SBOM 중심 공급망 보안만으로는 잘 보이지 않을 뿐이다.
그림. SBOM은 오픈소스와 라이브러리 목록을 설명하는 출발점이지만, AI IDE, MCP, 내부 RAG, 자동화 커넥터가 만드는 신뢰 경로까지 설명하지는 못한다.
3. AI 개발 도구는 새로운 작업 흐름이다
초기의 AI 코딩 도구는 주로 자동완성과 설명에 가까웠다.
- 코드 자동완성
- 함수 설명
- 테스트 코드 초안
- 리팩토링 제안
- 문서 초안 작성
하지만 최근 도구는 더 넓은 작업 흐름에 들어온다.
- 여러 파일의 변경 방향을 제안한다.
- 테스트 결과를 읽고 원인을 설명한다.
- 이슈 내용을 코드 수정 방향과 연결한다.
- PR 설명을 작성한다.
- 리뷰 의견을 정리한다.
- 반복되는 점검 항목을 체크리스트로 만든다.
- 보안 점검 결과를 개발자 언어로 바꿔준다.
이 변화는 생산성을 높인다. 동시에 보안팀이 봐야 할 범위도 넓힌다.
이제 질문은 “AI 도구를 쓰는가?”가 아니다.
AI 개발 도구가 어떤 작업 흐름에 들어와 있고, 그 결과가 어떤 검토 절차를 거쳐 코드와 운영에 반영되는가?
이 질문이 더 중요하다.
4. MCP와 자동화 연결은 거버넌스 대상이다
MCP나 자동화 연결은 AI 도구가 여러 시스템과 함께 동작하도록 만든다.
이 구조는 유용하다. 문서, 코드 저장소, 이슈 관리, 빌드 상태, 보안 점검 결과를 한 흐름에서 참고할 수 있기 때문이다.
하지만 연결이 늘어날수록 관리해야 할 것도 늘어난다.
| 영역 | 관리 질문 |
|---|---|
| 연결 범위 | 어떤 시스템과 연결되는가? |
| 승인 절차 | 누가 연결을 승인하고 변경을 검토하는가? |
| 역할 구분 | 읽기, 제안, 변경, 승인 역할이 구분되는가? |
| 이력 관리 | 어떤 자료를 참고했고 어떤 결과를 만들었는가? |
| 품질 기준 | 생성된 결과를 어떤 기준으로 검토하는가? |
| 예외 처리 | 고위험 변경이나 민감한 작업은 어떻게 승인하는가? |
| 운영 책임 | 연결 장애, 오작동, 품질 저하 시 누가 책임지는가? |
자동화 연결의 위험은 특정 기술 이름에만 있지 않다.
더 근본적인 위험은 연결 범위와 승인 구조가 불명확한 상태에서 개발 프로세스 안으로 들어오는 것이다.
따라서 MCP와 자동화 연결은 기술 도입 항목이 아니라 거버넌스 항목으로 봐야 한다.
5. 개발자 환경도 공급망의 일부다
전통적으로 공급망 보안은 중앙 저장소, 패키지 저장소, 빌드 시스템에 집중했다.
하지만 AI 개발 도구가 확산되면 개발자 환경의 중요성이 더 커진다.
개발자 환경에는 다음이 함께 존재한다.
- 소스코드
- 브랜치와 PR 작업 흐름
- 내부 문서 접근 경로
- 이슈 관리 도구
- 테스트 스크립트
- 로컬 설정
- IDE 확장
- AI 개발 도구 설정
- 자동화 연결 정보
이 환경은 단순 업무 공간이 아니다. 코드가 만들어지고, 검토되고, 변경 방향이 결정되는 시작점이다.
따라서 개발자 환경은 공급망의 바깥이 아니라 안쪽에 있다.
중앙 빌드 시스템만 안전하게 만든다고 충분하지 않다. 개발자의 작업 환경에서 어떤 도구가 어떤 흐름으로 사용되는지 함께 봐야 한다.
6. AI 개발 도구 점검 항목
AI 개발 도구를 완전히 금지하는 것은 현실적이지 않다.
더 현실적인 방향은 사용 구조를 파악하고, 안전한 기본값을 만드는 것이다.
점검 항목은 다음과 같이 잡을 수 있다.
| 점검 항목 | 확인할 질문 |
|---|---|
| 사용 현황 | 어떤 팀이 어떤 AI 개발 도구를 쓰는가? |
| 적용 범위 | 코드 작성, 리뷰, 테스트, 문서화, 이슈 관리 중 어디에 쓰는가? |
| 연결 시스템 | 코드 저장소, 이슈 관리, 문서, CI/CD 중 무엇과 연결되는가? |
| 변경 절차 | 도구가 제안한 변경은 어떤 검토 절차를 거치는가? |
| 승인 기준 | 고위험 변경은 별도 승인을 받는가? |
| 결과 품질 | 생성 결과의 정확도와 재검토 비율을 측정하는가? |
| 이력 관리 | 주요 자동화 활동과 변경 근거가 남는가? |
| 예외 관리 | 팀별 예외 사용을 누가 승인하고 주기적으로 재검토하는가? |
| 교육 | 개발자가 도구의 한계와 검토 책임을 이해하는가? |
| 비용 가시성 | 사용량과 운영 비용을 공정별로 볼 수 있는가? |
이런 항목은 기존 보안 점검표에 충분히 반영되어 있지 않을 수 있다.
그러나 앞으로는 개발 환경 보안과 공급망 보안의 경계가 점점 흐려질 것이다.
7. 최소 권한보다 먼저 필요한 것은 최소 신뢰 경로다
보안에서 최소 권한은 중요한 원칙이다.
하지만 AI 개발 도구와 자동화 연결에서는 그 전에 신뢰 경로를 그려야 한다.
- 어떤 입력을 참고하는가?
- 어떤 결과를 생성하는가?
- 누가 그 결과를 검토하는가?
- 어떤 단계에서 사람이 승인하는가?
- 어떤 결과가 코드 저장소나 배포 흐름에 영향을 주는가?
- 문제가 생겼을 때 어디까지 되돌릴 수 있는가?
이 흐름이 보이지 않으면 권한을 줄일 수도 없다.
따라서 첫 번째 작업은 모든 것을 막는 것이 아니라, 신뢰 경로를 가시화하는 것이다.
AI 개발 도구가 어떤 정보와 연결되어 있고, 어떤 결과물을 만들며, 어떤 절차를 통해 반영되는지 지도처럼 그려야 한다.
그 다음에 권한 범위, 승인 절차, 로그, 예외 처리, 품질 기준을 설계할 수 있다.
그림. 최소 권한은 신뢰 경로를 그린 뒤에야 설계할 수 있다. 어떤 도구가 무엇을 읽고, 무엇을 제안하며, 어디서 사람이 승인하는지 먼저 보여야 한다.
8. 공급망 대응과 보안진단은 연결된다
앞선 글에서 보안진단을 개발 프로세스 안에 내재화해야 한다고 말했다.
그 말은 단순히 SAST를 CI/CD에 넣자는 뜻이 아니다.
보안진단이 봐야 할 대상 자체가 넓어진다는 뜻이다.
앞으로의 보안진단은 다음을 함께 봐야 한다.
- 코드 취약점
- 오픈소스 의존성
- API 노출
- CI/CD 설정
- 빌드 스크립트
- 배포 절차
- 개발자 환경
- AI 개발 도구 설정
- MCP와 자동화 연결
- 이슈 관리와 코드 변경 흐름
- 보안 점검 결과의 재검증 흐름
이 관점에서 보면 공급망 보안과 보안진단은 따로 떨어진 업무가 아니다.
공급망 보안은 보안진단의 입력이 되고, 보안진단은 공급망 위험을 줄이는 반복 검증 체계가 된다.
9. 결론: AI 도구도 자산이다
AI IDE, MCP, 자동화 연결은 단순 편의 도구가 아니다.
개발자가 어떤 판단을 하고, 어떤 코드를 만들고, 어떤 검토를 통과하는지에 영향을 주는 개발 프로세스의 일부다.
따라서 조직은 AI 개발 도구를 자산으로 관리해야 한다.
AI 시대의 공급망 보안은 다음 질문으로 확장되어야 한다.
우리는 어떤 소프트웨어를 쓰는가?
에서
우리는 어떤 도구와 연결에 개발 프로세스의 일부를 위임하고 있는가?
로.
SBOM은 여전히 필요하다. 하지만 SBOM만으로는 충분하지 않다.
앞으로 필요한 것은 software bill of materials를 넘어, 개발 도구, 자동화 연결, 승인 절차, 변경 이력, 품질 기준을 포함한 더 넓은 신뢰 경로의 지도다.
AI 시대의 공급망 보안은 결국 개발 프로세스 안의 신뢰 경로를 그리는 일이다.
이 글의 산출물은 AI 도구와 MCP 연결을 자산으로 식별하고, 연결 범위, 승인 절차, 변경 이력, 품질 기준을 함께 관리해야 한다는 신뢰 경로 지도다.
현실적인 시작점은 거창할 필요가 없다.
- 조직에서 쓰는 AI IDE, 코딩 보조 도구, MCP 서버, 자동화 커넥터 목록을 만든다.
- 각 도구가 읽는 시스템, 쓰는 시스템, 변경을 제안하는 시스템을 나눈다.
- 읽기, 제안, 수정, 승인 권한을 같은 권한으로 묶지 않는다.
- 도구가 만든 변경과 사람이 승인한 변경의 이력을 남긴다.
- 고위험 저장소, 배포 파이프라인, 운영 비밀정보에 연결되는 예외는 별도 승인과 주기적 재검토 대상으로 둔다.
이 정도만 해도 “AI 도구를 쓰는가”라는 질문은 “어떤 신뢰 경로에 어떤 권한을 맡기고 있는가”라는 질문으로 바뀐다. 공급망 보안은 바로 그 질문에서 시작된다.
이 시리즈를 여기서 닫으면, 핵심은 하나다. CVE가 붙은 뒤 움직이는 방식, 모든 후보를 같은 깊이로 보는 triage, 일회성 보안진단, SBOM만 바라보는 공급망 관리는 모두 같은 한계를 가진다. AI 시대에는 신호가 빨라지고, 후보가 많아지고, 개발 경로가 넓어진다. 그래서 보안은 번호, 리포트, 목록을 기다리는 활동이 아니라 개발 프로세스 안의 신뢰 경로를 계속 검증하는 운영 체계가 되어야 한다.
FAQ
Q1. AI IDE나 MCP를 쓰지 말자는 뜻인가?
아니다. 금지가 아니라 관리가 필요하다는 뜻이다. 어떤 도구가 어떤 시스템과 연결되고, 어떤 결과가 어떤 승인 절차를 거쳐 반영되는지 알아야 한다.
Q2. 이것도 공급망 보안에 포함해야 하나?
포함해야 한다. 공급망은 오픈소스 패키지만이 아니라 코드가 만들어지고, 검토되고, 배포되는 신뢰 경로 전체를 포함한다. AI 개발 도구와 자동화 연결은 그 경로의 일부다.
Q3. 현실적으로 어디서 시작해야 하나?
먼저 조직에서 사용하는 AI 개발 도구, MCP 연결, 자동화 커넥터 목록을 만든다. 그 다음 각 도구가 읽는 시스템, 쓰는 시스템, 변경을 제안하는 시스템을 나누고, 승인 절차와 변경 이력을 관리하면 된다.
시리즈 처음부터 읽기: CVE 이후 대응만으로는 늦다: AI 시대 취약점은 번호가 붙기 전에 움직인다