- 임원과 현장 직원이 AI로 만든 업무 도구는 개발팀 검토 없이 실제 데이터와 연결되는 경우가 많습니다. 검토되지 않은 코드는 보안 취약점을 그대로 담습니다.
- 베라코드 2024 보고서는 AI 생성 코드의 45%에서 보안 취약점을 발견했습니다. 깃랩 2024 보고서는 개발자의 80%가 AI 코드를 리뷰 없이 병합한다고 응답했습니다.
- 보안 책임은 코드 작성자가 개발자인지 비개발자인지와 무관합니다. 사내 AI 코딩 정책은 검토 주체와 연결 가능 시스템 범위를 명시해야 합니다.
검토자 없이 데이터에 연결된 코드가 늘어나고 있습니다
한 중견 제조사 마케팅팀 팀장이 고객 구매 이력을 조회하는 스크립트를 AI로 만들었습니다. 영업 데이터베이스에 직접 연결해 팀원 여섯 명이 반년째 사용했습니다. IT팀은 이 도구의 존재를 몰랐습니다. 외부 보안 감사에서 SQL 인젝션 취약점이 발견됐습니다. 고객 데이터 수십만 건이 노출 가능한 상태였습니다.
보안 소프트웨어 기업 베라코드가 2024년에 발표한 'State of Software Security' 보고서는 AI가 생성한 코드의 45%에서 보안 취약점이 발견됐다고 밝혔습니다. 개발 플랫폼 깃랩이 2024년 진행한 'Global DevSecOps Survey'에서는 응답 개발자의 80%가 AI가 작성한 코드를 코드 리뷰 없이 저장소에 병합한다고 답했습니다. 개발자도 이런 상황이라면 비개발자가 만든 코드는 검토 확률이 더 낮습니다.
AI 코딩 도구는 기능을 구현하는 데 최적화돼 있습니다. 보안 취약점을 먼저 경고하지 않습니다. 입력 검증 우회, SQL 인젝션, 하드코딩된 자격증명이 작동하는 코드 안에 섞여 있어도 결과물만 보면 알 수 없습니다.
AI 코딩의 확산이 그림자 IT의 보안 위험을 키웁니다
임원과 현장 직원이 AI로 업무 도구를 만드는 현상은 확산 중입니다. 현장 지식이 있는 사람이 만들기 때문에 도구의 업무 적합성은 높습니다. 문제는 IT팀 밖에서 만들어지고 운영되는 도구가 실제 데이터와 연결될 때입니다.
기존 그림자 IT(엑셀 매크로, 개인 구글 시트)와 AI 코딩의 차이는 연결 범위입니다. 엑셀 매크로는 파일 안에서 작동했습니다. AI가 만든 스크립트는 API를 통해 내부 시스템, 고객 데이터베이스, 외부 서비스에 연결됩니다. 취약점이 있을 때 노출되는 데이터의 범위가 다릅니다.
Ahn Partners 판단: 책임의 소재는 코드를 AI가 썼는지 사람이 썼는지와 무관합니다. 사내 데이터에 연결된 도구는 작성자가 누구든 보안 기준이 적용됩니다. 이 기준을 현업이 알지 못하면 기준은 작동하지 않습니다.
사내 AI 코딩 정책에 두 가지 기준이 있어야 합니다
첫 번째 기준은 검토 주체입니다. 비개발자가 AI로 만든 코드가 사내 시스템에 연결될 경우, 배포 전에 IT팀 또는 지정된 검토자가 확인합니다. 검토 범위는 인증 방식, 입력 처리, 외부 연결 세 항목입니다.
두 번째 기준은 연결 가능 시스템 범위입니다. 비개발자가 만든 도구가 접근할 수 있는 데이터 시스템을 사전에 지정합니다. 고객 개인정보, 재무 데이터, 계약 정보가 담긴 시스템은 별도 승인 없이는 연결하지 않습니다.
Ahn Partners 판단: 현재 IT팀 외부에서 만들어져 사용 중인 AI 생성 도구가 몇 개인지 파악하십시오. 이 도구들이 어떤 데이터에 접근하는지 확인하지 못하고 있다면, 정책보다 현황 파악이 먼저입니다.
한 문장으로 정리하면
AI가 코드를 썼다는 것이 보안 책임을 없애지는 않습니다. IT팀 밖에서 만들어져 사내 데이터에 연결된 도구를 이번 주 안에 목록화하고, 검토 이력이 없는 도구부터 확인하십시오.
점검 목록
- IT팀 외부에서 AI로 만들어져 사내 시스템에 연결된 도구가 몇 개인지 파악하고 있는가
- 비개발자가 만든 코드가 사내 시스템에 연결될 때 배포 전 검토 절차가 있는가
- AI 생성 코드에 하드코딩된 자격증명이나 입력 검증 우회가 있는지 점검한 적 있는가
- 사내 AI 코딩 도구 사용 정책에 보안 기준과 연결 가능 시스템 범위가 명시돼 있는가