--- title: "AI 코딩이 빨라질수록 보안 테스트 자동화가 더 급해졌다" published: 2026-05-08T06:05:03.704Z canonical: https://jeff.news/article/2395 --- # AI 코딩이 빨라질수록 보안 테스트 자동화가 더 급해졌다 AI가 만든 코드가 빠르게 늘면서 개발 속도는 빨라졌지만, 검증되지 않은 코드와 취약한 오픈소스가 그대로 유입될 위험도 커지고 있다는 지적이 나왔다. 스패로우는 전통적인 보안 테스트만으로는 AI 개발 속도를 따라가기 어렵고, 보안 테스팅을 개발 워크플로우 안에 자동화해 넣어야 한다고 봤다. 특히 SBOM과 앞으로의 AIBOM까지 포함해 소프트웨어 공급망을 추적하는 체계가 중요해지고 있다. ## AI 코딩은 빨라졌는데, 보안 검증은 그대로면 답이 없음 - AI를 활용한 개발이 보편화되면서 검증되지 않은 코드가 대량으로 들어오는 상황이 됐음 - 스패로우 발표에 따르면 AI가 생성한 코드는 최근 46% 규모로 급증함 - 개발자는 단순 코드 작성 같은 반복 작업을 AI에 맡기면서 생산성을 끌어올리고 있음 - 그 결과 개발 속도는 약 2배 빨라졌고, 배포 사이클과 릴리즈 주기도 같이 짧아지는 흐름임 - 문제는 속도가 빨라진 만큼 취약점도 더 빠르게 들어올 수 있다는 점임 - 윤종원 스패로우 최고기술책임자(CTO)는 AI가 만든 코드를 “검증되지 않은 코드”로 봐야 한다고 지적함 - AI가 자동으로 만들어준 코드라고 해서 안전하다는 보장은 없음 - 더 빡센 건, AI가 추천하거나 끌어온 오픈소스도 항상 안전하다고 볼 수 없다는 부분임 > [!IMPORTANT] > 개발 속도가 약 2배 빨라졌다는 건 좋은 소식이지만, 보안 검증이 그대로면 취약한 코드도 그 속도로 배포될 수 있다는 뜻임. ## 오픈소스 의존성은 이미 너무 커졌음 - 요즘 소프트웨어는 사실상 오픈소스 위에 올라가 있다고 봐도 됨 - NPM 같은 패키지 생태계가 커지면서 한 프로젝트에 수백 개, 많게는 수천 개 오픈소스가 들어가는 사례도 있음 - AI는 개발자가 쓸 만한 오픈소스를 찾아주는 역할까지 하고 있음 - 편하긴 한데, 그만큼 어떤 의존성이 들어왔는지 모르면 나중에 터졌을 때 추적이 빡세짐 - 취약한 구성요소 하나가 전체 소프트웨어에 영향을 줄 수 있다는 게 핵심 리스크임 - 오픈소스 라이브러리 하나에 취약점이 있어도 그걸 포함한 서비스 전체가 영향권에 들어갈 수 있음 - AI가 코드와 의존성을 빠르게 추가하는 환경에서는 사람이 일일이 리뷰하는 방식만으로는 한계가 큼 - 그래서 스패로우는 보안 테스팅을 AI 기반 개발 워크플로우 안에 자동화해 넣어야 한다고 봄 ## 보안 테스트도 개발 파이프라인 안으로 들어가야 함 - 스패로우가 강조한 해법은 애플리케이션 보안 테스팅 자동화임 - 생성된 코드와 구성요소 안에 취약점이 있는지 식별하고 제거하는 과정임 - 전통적인 방식의 보안 테스트는 AI가 만들어내는 코드 양과 속도를 따라가기 어렵다는 판단임 - 결국 개발자가 코드를 만들고 배포하는 흐름 안에서 실시간으로 위험을 걸러내는 구조가 필요함 - 여기서 중요한 키워드가 소프트웨어자재명세서(SBOM)임 - SBOM은 소프트웨어에 포함된 모든 컴포넌트, 라이브러리, 의존성을 기계가 읽을 수 있는 형태로 정리한 명세서임 - 취약점 영향 범위를 파악하고 라이선스 컴플라이언스를 관리하는 데 쓰임 - 미국과 유럽연합(EU)은 SBOM 기반 규제를 고도화하는 중이고, 한국도 소프트웨어 공급망 가이드라인을 발간한 상태임 > [!NOTE] > 한국 정부는 지난해 범부처 정보보호 종합대책에서 2027년 공공 SBOM 제도화를 예고했음. 이건 국내 SI, 보안, 공공 프로젝트 쪽 개발 조직에도 꽤 직접적인 이슈임. ## SBOM 다음은 AIBOM 얘기까지 나옴 - SBOM 활용은 크게 생성, 보강, 증명, 공유, 검토 5단계로 설명됨 - 먼저 SBOM을 만들고, 필요한 데이터를 보강함 - 이후 해당 내용이 신뢰할 수 있는 소스에서 만들어졌고 변조되지 않았다는 점을 증명함 - 마지막으로 SBOM을 수요처에 전달하고, 공급사와 수요사가 내용을 검토해 합의하는 흐름임 - 이제는 코드뿐 아니라 AI 모델 자체도 관리 대상이 되고 있음 - AI 모델을 포함한 소프트웨어가 늘면서 AI 자재명세서(AIBOM)가 필요하다는 의견이 나옴 - 윤 CTO는 AI 모델의 위험성도 제기되는 만큼 SBOM이 AIBOM 형태로 발전할 가능성이 있다고 봄 - 소프트웨어 안에 어떤 AI 모델이 들어갔는지 추적하고 관리해야 새로운 취약점에도 대응할 수 있다는 얘기임 --- ## 기술 맥락 - 이번 얘기의 핵심은 “AI로 코드를 빨리 쓰자”가 아니라 “빨라진 코드 유입 속도에 보안 검증을 어떻게 맞출 거냐”예요. AI가 생성한 코드가 46% 늘고 개발 속도가 약 2배 빨라졌다면, 사람이 마지막에 몰아서 검사하는 방식은 병목이 될 수밖에 없거든요. - 그래서 보안 테스팅을 별도 단계로 두기보다 CI/CD 같은 개발 흐름 안에 넣자는 방향이 나와요. 코드가 생성되고, 빌드되고, 배포되는 과정에서 취약점과 위험한 의존성을 자동으로 걸러야 실제 개발 속도를 따라갈 수 있기 때문이에요. - SBOM이 중요한 이유는 “우리 서비스에 뭐가 들어갔는지”를 기계가 읽을 수 있게 남겨두기 때문이에요. 수백, 수천 개 오픈소스가 얽힌 프로젝트에서는 취약한 구성요소 하나가 발견됐을 때 영향 범위를 빠르게 찾는 게 곧 대응 속도가 되거든요. - AIBOM 얘기까지 나오는 건 소프트웨어의 구성물이 코드와 라이브러리에서 끝나지 않기 때문이에요. AI 모델이 제품 안에 포함되면 그 모델도 추적, 검증, 위험 관리 대상이 되고, 이 흐름은 공공 SBOM 제도화가 예고된 한국 개발 조직에도 남 얘기가 아니에요. ## 핵심 포인트 - AI 생성 코드는 최근 46% 규모로 늘었고 개발 속도는 약 2배 빨라졌다는 분석이 나왔다 - AI가 만든 코드와 AI가 추천한 오픈소스는 안전하다고 가정하면 안 된다 - SBOM은 컴포넌트, 라이브러리, 의존성을 기계가 읽을 수 있게 정리해 취약점 영향 범위와 라이선스 문제를 추적하는 장치다 - 한국 정부도 2027년 공공 SBOM 제도화를 예고한 상태라 국내 개발 조직에도 직접 영향이 있다 - AI 모델까지 포함한 소프트웨어가 늘면서 AIBOM으로 관리 범위를 넓혀야 한다는 주장도 나온다 ## 인사이트 AI 코딩 도구를 생산성 도구로만 보면 놓치는 게 큼. 코드 작성 속도가 2배 빨라졌다면, 보안 검증도 그 속도에 맞춰 자동화되지 않으면 취약점도 2배 빠르게 배포될 수 있다는 얘기다.