AI 보안 도구가 부족한 지점과 결정론적 빌드 증거가 다루는 영역

논지를 좁게 정의하면

이 글은 보안 분야에서 AI를 반대하는 주장이 아닙니다. 모델은 코드를 읽고, 탐지 결과를 설명하고, 수정을 제안하는 데 능숙하며, 이를 잘 활용하는 팀은 더 빠르게 움직입니다. 논지는 더 좁습니다. 나중에도 유효해야 하는 기록에는 확률적 모델이 1차 출처로 적합하지 않다는 것입니다. 규제 기관에 제출하는 SBOM, 출시한 아티팩트의 출처 증명, 그리고 "우리가 영향을 받았는가?"라는 질문에 대한 답이 여기에 해당합니다.

기록이 유효한지는 세 가지 속성이 결정합니다. 아래 각 섹션에서 하나씩 예시와 출처를 들어 살펴봅니다.

1. 재현성: 두 번 물어도 같은 답

보안 기록은 다른 사람이 같은 입력으로 같은 답을 얻을 수 있어야만 쓸모가 있습니다. 언어 모델은 이를 보장하지 않으며, 공급업체들도 그렇게 밝힙니다.

• Anthropic 문서: "temperature를 0으로 설정하더라도 결과가 완전히 결정론적이지는 않으며, 동일한 입력이 API 호출마다 다른 출력을 낼 수 있습니다."
• Copilot Autofix에 대한 GitHub의 설명: "같은 경고와 코드라도 실행 가능한 제안을 만들지 못할 수 있으며, 시도할 때마다 제안이 달라질 수 있습니다."
• SecLLMHolmes 프레임워크를 만든 연구진은 IEEE S&P 2024에서 8개의 LLM을 228개 코드 시나리오로 테스트했습니다. 연구진은 모델이 "비결정론적인 응답을 제공"하며, "소스 코드에서 함수나 변수 이름만 바꾸거나 라이브러리 함수를 추가하는 것만으로" PaLM2와 GPT-4가 각각 26%와 17%의 경우에 틀린 답을 냈다고 보고합니다.

예시. 두 엔지니어가 같은 어시스턴트에게 어떤 서비스가 새로운 보안 권고의 영향을 받는지 묻습니다. 한 명은 "아니요"라는 답을, 다른 한 명은 "가능성이 있으니 전이적 종속성 트리를 확인하세요"라는 답을 받습니다. 어느 답도 기록이 아니며, 6개월 뒤 감사인 앞에서 재현할 수도 없습니다.

빌드 기록에는 이런 문제가 없습니다. 추론하는 것이 아무것도 없기 때문입니다. CRACI는 작업이 실행되는 동안 패키지 소스에서 가져오는 패키지를 관찰하며, SBOM은 그 관찰의 기록입니다.

2. 감사 가능성: 어떻게 아는지 보여 주기

감사는 "어떻게 알 수 있습니까?"라는 질문에 달려 있습니다. 모델은 유창한 답을 내놓을 수 있지만, 그 설명은 증거가 아닙니다. SecLLMHolmes 평가에 따르면 LLM은 평가하는 취약점에 대해 "부정확하고 충실하지 않은 추론"을 제시하므로, 판정은 맞더라도 그 설명은 성립하지 않을 수 있습니다.

표준은 자신의 출처를 스스로 설명하는 기록 쪽으로 움직이고 있습니다. CISA가 NSA, FBI, 국제 파트너와 함께 발표한 2026년 SBOM 최소 요소는 SBOM Tool Name, SBOM Tool Version, 그리고 SBOM이 "빌드 전(before build)", "빌드(build)", "빌드 후(after build)" 중 언제 생성되었는지를 나타내는 SBOM Generation Context를 추가합니다. 같은 문서는 "조직은 SBOM 작성자의 관행에서 비롯되었든 부적절한 도구 선택에서 비롯되었든, 오류를 조직의 위험 관리 결정에 고려할 수 있다"고 경고합니다.

예시. 고객 설문지가 SBOM을 어떻게 생성했는지 묻습니다. "어시스턴트가 리포지토리를 읽고 작성했다"는 생성 컨텍스트이긴 하지만 검토자가 확인할 수 있는 것은 아닙니다. "릴리스 빌드 중 CI 러너 안에서 기록되었으며, 작업의 완전성 상태는 Complete다"는 검토자가 빌드와 대조해 검증할 수 있습니다.

3. 완전성: 본 적 없는 것은 보고할 수 없습니다

모델은 제공된 정보를 바탕으로 추론합니다. 모델이 읽는 파일이 소프트웨어를 설명하지 않으면 답도 설명하지 못하며, 출력 어디에도 그런 사실이 드러나지 않습니다. CISA의 2026년 가이드는 수신자의 판단을 기준으로 삼습니다. 수신자는 "SBOM에 구성 요소가 나열되어 있지 않으면 새로 보고된 취약점이 자신에게 영향을 주지 않는다고 결론 내릴 수 있어야 합니다." 이는 목록에 없다는 것이 빌드에 없다는 뜻일 때만 성립합니다.

예시. v2.1.259 시점의 anthropics/claude-code 리포지토리에는 어떤 종류의 종속성 매니페스트나 잠금 파일도 없습니다. 공개된 npm 패키지는 런타임 종속성을 하나도 선언하지 않으며, 사전 빌드된 네이티브 바이너리를 감쌉니다. AI든 아니든 리포지토리를 읽는 도구는 나열할 것이 거의 없지만, 실제로 실행되는 프로그램은 컴파일된 바이너리입니다.

예시. AI 코딩 도구는 이런 빈틈을 직접 만들 수도 있습니다. GitHub는 Copilot Autofix가 "통계적으로 그럴듯한 이름으로 게시된 조작된 종속성을 제안할 수 있다"고 경고합니다. 16개 모델이 생성한 코드 샘플 576,000개를 분석한 USENIX Security 2025 연구에 따르면, 존재하지 않는 패키지를 지어내는 비율이 상용 모델은 평균 최소 5.2%, 오픈 소스 모델은 21.7%였으며, 지어낸 고유 패키지 이름은 205,474개에 달했습니다.

결정론적이어야 하지만, 그것만으로는 충분하지 않습니다

이 주장을 정직하게 펼치려면 다음 사항도 짚어야 합니다. SBOM 생성 도구는 결정론적이지만, 그래도 서로 다른 결과를 냅니다. expressjs/express의 같은 커밋을 대상으로 해도 서로 다른 목록을 반환할 수 있습니다. 각 도구가 무엇을 구성 요소로 볼지, 어떤 파일을 신뢰할지를 스스로 정하기 때문입니다. 이 리포지토리는 잠금 파일을 커밋하지 않으므로, 잠금 파일로 종속성을 해석하는 도구는 package.json 종속성을 하나도 보고하지 못합니다.

결정론적 스캐너는 매번 똑같이 불완전한 답을 재현합니다. 반복 가능성은 필요하지만, 빈틈을 메우는 것은 관찰입니다. 빌드가 실제로 가져온 것을 기록하고, 기록이 불완전하면 그렇다고 알려 주는 것입니다. CRACI는 모든 작업과 캐시를 Complete, Complete with connections, Incomplete, Unavailable, Not recorded 중 하나로 표시합니다.

실제 예시: 새로운 보안 권고의 영향 범위 파악

가상의 상황입니다. 널리 쓰이는 npm 패키지의 특정 버전에 대한 보안 권고가 발표됩니다. Cyber Resilience Act에 따라 제조사는 실제로 악용되는 취약점을 24시간 이내에 ENISA에 보고해야 하므로, 영향 범위 파악은 빠르고 정확해야 합니다.

AI 우선 방식

어시스턴트에게 리포지토리를 확인해 달라고 요청합니다. 어시스턴트는 매니페스트와 잠금 파일, 그리고 어쩌면 Dockerfile을 읽습니다. CI 캐시에서 복원된 패키지, 빌드 단계가 내려받은 도구, 잠금 파일이 없는 리포지토리에서 설치 시점에 해석된 버전은 보지 못합니다. 두 번 물으면 다르게 답할 수도 있습니다. 요약은 유용하지만, 그것을 근거로 보고서에 서명할 수는 없습니다.

기록 우선 방식

CRACI는 조직 수준에서 기본 브랜치를 대상으로 빌드와 리포지토리 전반의 취약점을 집계하고, 새로운 취약점이 나타나면 모니터링 중인 SBOM을 재평가합니다. API는 각 빌드의 CycloneDX SBOM, 네트워크 추적, 출처 증명을 반환합니다. 작업의 기록이 불완전하면 완전성 상태가 직접 살펴봐야 할 곳을 알려 줍니다. 결과 요약은 여전히 모델에 맡길 수 있습니다. 이때 모델은 기록을 생성하는 것이 아니라 기록을 요약하는 것입니다.

기록이 있으면 "어떤 릴리스에 이 패키지가 포함되었는가?"라는 질문은 조사가 아니라 조회가 됩니다.

나란히 비교

각 도구를 강점이 있는 곳에 쓰세요

판단이 도움이 되고 사람이 출력을 확인하는 곳에는 AI를 쓰세요. 코드 리뷰, 탐지 결과 설명, 수정안 작성이 그렇습니다. 출력을 재현하거나, 감사하거나, 완전하다고 믿고 의존해야 하는 곳에는 결정론적 빌드 기록을 쓰세요. SBOM, 출처 증명, 사고 영향 범위 파악이 그렇습니다. CRACI는 더 넓은 CRA 프로세스에 필요한 공급망 증거의 상당 부분을 자동화합니다. CRACI만으로 컴플라이언스가 충족되지는 않습니다.

기록이 어떻게 만들어지는지는 빌드 시점 SBOM 생성에서 확인하거나, CRA가 요구하는 것부터 시작해 보세요.