AI 코딩이 빨라질수록 보안 테스트 자동화가 더 급해졌다

AI 코딩은 빨라졌는데, 보안 검증은 그대로면 답이 없음

• AI를 활용한 개발이 보편화되면서 검증되지 않은 코드가 대량으로 들어오는 상황이 됐음

  • 스패로우 발표에 따르면 AI가 생성한 코드는 최근 46% 규모로 급증함
  • 개발자는 단순 코드 작성 같은 반복 작업을 AI에 맡기면서 생산성을 끌어올리고 있음
  • 그 결과 개발 속도는 약 2배 빨라졌고, 배포 사이클과 릴리즈 주기도 같이 짧아지는 흐름임

• 문제는 속도가 빨라진 만큼 취약점도 더 빠르게 들어올 수 있다는 점임

  • 윤종원 스패로우 최고기술책임자(CTO)는 AI가 만든 코드를 “검증되지 않은 코드”로 봐야 한다고 지적함
  • AI가 자동으로 만들어준 코드라고 해서 안전하다는 보장은 없음
  • 더 빡센 건, AI가 추천하거나 끌어온 오픈소스도 항상 안전하다고 볼 수 없다는 부분임

오픈소스 의존성은 이미 너무 커졌음

• 요즘 소프트웨어는 사실상 오픈소스 위에 올라가 있다고 봐도 됨

  • NPM 같은 패키지 생태계가 커지면서 한 프로젝트에 수백 개, 많게는 수천 개 오픈소스가 들어가는 사례도 있음
  • AI는 개발자가 쓸 만한 오픈소스를 찾아주는 역할까지 하고 있음
  • 편하긴 한데, 그만큼 어떤 의존성이 들어왔는지 모르면 나중에 터졌을 때 추적이 빡세짐

• 취약한 구성요소 하나가 전체 소프트웨어에 영향을 줄 수 있다는 게 핵심 리스크임

  • 오픈소스 라이브러리 하나에 취약점이 있어도 그걸 포함한 서비스 전체가 영향권에 들어갈 수 있음
  • AI가 코드와 의존성을 빠르게 추가하는 환경에서는 사람이 일일이 리뷰하는 방식만으로는 한계가 큼
  • 그래서 스패로우는 보안 테스팅을 AI 기반 개발 워크플로우 안에 자동화해 넣어야 한다고 봄

보안 테스트도 개발 파이프라인 안으로 들어가야 함

• 스패로우가 강조한 해법은 애플리케이션 보안 테스팅 자동화임

  • 생성된 코드와 구성요소 안에 취약점이 있는지 식별하고 제거하는 과정임
  • 전통적인 방식의 보안 테스트는 AI가 만들어내는 코드 양과 속도를 따라가기 어렵다는 판단임
  • 결국 개발자가 코드를 만들고 배포하는 흐름 안에서 실시간으로 위험을 걸러내는 구조가 필요함

• 여기서 중요한 키워드가 소프트웨어자재명세서(SBOM)임

  • SBOM은 소프트웨어에 포함된 모든 컴포넌트, 라이브러리, 의존성을 기계가 읽을 수 있는 형태로 정리한 명세서임
  • 취약점 영향 범위를 파악하고 라이선스 컴플라이언스를 관리하는 데 쓰임
  • 미국과 유럽연합(EU)은 SBOM 기반 규제를 고도화하는 중이고, 한국도 소프트웨어 공급망 가이드라인을 발간한 상태임

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 제도화가 예고된 한국 개발 조직에도 남 얘기가 아니에요.