스캔 결과가 법적 판정처럼 보일 때

AI 에이전트를 EU에 제공할 가능성이 있다면 “우리 코드는 EU AI Act를 통과할까?”라는 질문이 자연스럽게 나옵니다. 이때 파일을 훑어 조항별 PASS를 보여주는 도구는 매력적이에요. 법무 검토 전에 위험한 부분을 빠르게 찾을 수 있을 것처럼 보이니까요.

AIR Blackbox 제작자는 11개 오픈소스 프로젝트의 Python 파일 5,754개를 검사해 평균 점수가 2.2/6이었고, 23개 파일만 여섯 조항에서 모두 PASS를 받았다고 보고했습니다. Article 9에서는 파일의 97%, Article 12에서는 89%, Article 14에서는 84%가 제작자가 연결한 신호를 찾지 못했습니다.

하지만 이 결과를 “EU AI Act가 코드를 검사해 97%를 탈락시켰다”고 읽으면 안 됩니다. EU 기관의 조사도, 법률상 적합성 평가도 아니에요. 도구 제작자가 정의한 파일 단위 휴리스틱의 결과입니다.

23개 PASS가 실제로 뜻하는 것

당시 벤치마크에서 개별 조항의 PASS는 그 조항에 연결된 여러 하위 신호 가운데 하나 이상이 파일에서 발견됐다는 뜻이었습니다. 23개 파일은 이 조건을 여섯 조항 각각에서 충족한 파일이지, EU AI Act의 여섯 조항을 법적으로 준수한다고 판정받은 파일이 아닙니다.

5,754개
검사한 Python 파일
23개
당시 여섯 조항 모두 PASS
97%
당시 Article 9 신호를 찾지 못한 파일

벤치마크 당시 제작자는 Article 9에 위험 분류·접근 제어·위험 감사를, Article 15에 오류 처리와 테스트 등을 연결했습니다. 제작자가 사례로 든 LiteLLM 인증 모듈에는 접근 제어, 구조화된 로그, 타임스탬프, 오류 처리가 이미 있었고요. 여기서 얻을 발견은 “23개 파일에는 특별한 비밀이 없었다”가 아니라, 평소의 운영 통제가 정적분석에서도 유용한 단서로 드러날 수 있다는 정도예요. 나머지 PASS 파일 전체의 공통점은 공개 자료만으로 확인할 수 없습니다.

이 수치는 벤치마크로 복사하기 어렵습니다.

검사에 사용한 저장소별 커밋, 파일 선정 기준, 원시 JSON을 현재 공개 경로에서 재현하지 못했습니다. 오탐·미탐률을 검증한 독립 평가도 확인되지 않았어요. 따라서 2.2/6이나 0.4%를 우리 프로젝트의 합격선 또는 업계 평균으로 사용하면 안 됩니다.

법은 파일이 아니라 시스템을 봅니다

EU AI Act의 해당 의무는 코드 패턴 하나보다 넓습니다. Article 9는 고위험 AI 시스템의 전체 생애주기에 걸쳐 반복적으로 수행하고 문서화하는 위험관리 체계를 요구합니다. Article 11의 기술문서도 docstring이나 타입 힌트가 아니라, 당국이 시스템의 적합성을 평가할 수 있도록 시장 출시 전에 작성하고 최신 상태로 유지하는 문서입니다.

조항법이 요구하는 시스템 수준의 확인v1.15.0 스캐너가 찾는 주요 단서
Article 9위험 식별·평가·완화와 정기 검토오류 처리, fallback·recovery
Article 11적합성 평가가 가능한 최신 기술문서문서화·타입 정보
Article 12시스템 수명 동안 사건을 자동 기록하는 능력로그·감사 추적 호출
Article 14출력을 무시·재정의하거나 안전하게 중단할 사람의 감독 수단human-in-the-loop, 사용량·예산 통제
Article 15정확성·강건성·사이버보안retry·backoff, 프롬프트 인젝션 방어, 출력 검증

오른쪽 열은 현재 공개된 v1.15.0 구현을 요약한 것으로, 5,754개 파일을 검사했던 당시 매핑과 다릅니다. 현재 코드 스캐너는 오류 처리와 fallback·recovery를 Article 9에, human-in-the-loop와 사용량·예산 통제를 Article 14에, retry·backoff와 프롬프트 인젝션 방어·출력 검증을 Article 15에 배치합니다.

로그 호출이 있다고 보존 기간과 감사 가능성이 증명되지는 않습니다. 승인 함수가 있어도 운영자가 제때 개입할 수 있는지 알 수 없고요. 스캐너는 증거가 아니라 확인할 곳을 가리키는 탐색기로 쓰는 게 맞습니다. 저장소 역시 이 도구가 인증된 컴플라이언스 테스트가 아니며 잠재적인 공백을 찾는 출발점이라고 밝힙니다. 자체 평가표는 준비된 72개 fixture와 12개 검사를 대상으로 한 결과이며, 임의의 운영 코드에 대한 정확도를 보장하지 않습니다.

첫 스캔은 결과의 출처를 분리하는 것부터

Python 3.10 이상과 검사할 프로젝트의 로컬 소스, 패키지를 설치하고 명령을 실행할 권한이 필요합니다. 아래 절차는 법적 준수 판정이 아니라 코드에서 초기 통제 단서를 찾는 작업입니다. 확인된 배포판 v1.15.0을 기준으로 설명하지만, 업데이트되면 검사 조건과 출력이 달라질 수 있습니다.

  1. 프로젝트 환경에 패키지를 설치합니다.
    pip install air-blackbox
  2. 설치 버전과 도움말을 먼저 기록합니다. 검사 보고서에 패키지 버전과 실행 날짜를 남기고, 설치된 명령의 도움말에서 옵션을 확인하세요. 과거 벤치마크의 조항 매핑을 현재 출력에 그대로 대입하면 안 됩니다.
  3. 프로젝트 루트로 이동합니다. 운영 저장소라면 별도 브랜치나 읽기 전용 복사본에서 시작하세요.
  4. 첫 비교는 선택적 분석과 이력 저장을 끄고 실행합니다.
    air-blackbox comply --scan. -v --no-llm --no-save
    v1.15.0의 기본 명령은 로컬 게이트웨이 상태를 확인하고 정적 검사와 런타임 검사를 함께 출력합니다. Ollama와 기본 모델이 있으면 AI 분석을 실행할 수 있고, 기본 설정에서는 검사 이력도 로컬에 저장합니다. 위 옵션은 선택적 LLM 분석과 이력 저장을 제외해 첫 정적 결과를 비교하기 쉽게 만듭니다.
  5. 게이트웨이 미연결과 통제 부재를 구분합니다. localhost:8080 게이트웨이가 없어도 정적 검사는 계속될 수 있습니다. 이때 런타임 검사에 관측 데이터가 없다는 결과는 통제가 없다는 증거가 아니라 런타임을 아직 검증하지 못했다는 뜻으로 따로 기록하세요.
  6. 검사별 상태와 evidence 문구를 함께 저장합니다. 현재 CLI는 과거 사례의 조항별 6/6 점수가 아니라 개별 검사마다 PASS·WARN·FAIL을 출력합니다. PASS도 항상 통제 신호를 발견했다는 뜻은 아닙니다. 예를 들어 Article 9의 오류 처리 검사는 직접 LLM 호출을 찾지 못했을 때 조건부로 PASS가 될 수 있습니다. 상태만 옮기지 말고 검사 조건과 evidence를 함께 읽으세요.
  7. 위치가 출력된 항목만 파일과 연결합니다. 일부 검사는 파일명이나 줄 위치 대신 “N개 파일에서 발견” 같은 집계만 보여줍니다. 위치가 없는 결과는 자동으로 코드 위치가 확인됐다고 기록하지 말고, 해당 검사의 탐지 패턴을 기준으로 별도 코드 검색과 수동 확인을 진행하세요.
  8. 시스템 증거와 대조합니다. PASS·WARN·FAIL 모두 법적 판정이 아닙니다. 위험 등록부, 최신 기술문서, 실제 로그 보존, 사람의 중단 권한, 정확성·강건성·보안 테스트에서 통제가 작동하는지 확인합니다.
  9. 마지막으로 적용 범위를 분류합니다. 시스템이 고위험 범주인지, 우리 조직이 제공자와 배포자 중 어떤 역할인지, 어느 시행 일정이 적용되는지 별도로 검토하세요.

첫 성공 기준은 6/6이 아닙니다. 설치 버전과 실행 옵션, 검사별 상태와 evidence를 저장하고, 위치가 실제로 출력된 항목만 해당 파일에 연결했다면 첫 단계는 끝났습니다. 위치가 없는 집계 결과와 런타임 데이터가 없는 검사는 후속 검색·운영 확인 목록으로 분리하세요.

EU 대상 여부와 시행일도 따로 확인해야 합니다

EU 밖의 사업자라도 AI 시스템을 EU 시장에 출시·서비스하거나 그 출력이 EU에서 사용되는 구조라면 적용 범위에 들어갈 수 있습니다. 다만 EU 사용자가 한 명 있다는 이유만으로 일률적으로 결론 내릴 수는 없어요. 제공자·배포자 역할과 실제 시장 제공 관계를 함께 봐야 합니다.

시행 일정도 2026년 8월 2일 하나로 단순화하면 안 됩니다. 법은 그날부터 전반적으로 적용되지만, 현재 공식 안내에서는 Annex III의 특정 고위험 영역은 2027년 12월 2일, 규제 제품에 내장된 Annex I 고위험 시스템은 2028년 8월 2일로 구분합니다. 금지 관행과 AI 리터러시, 범용 AI 의무에는 또 다른 일정이 적용됩니다.

벌금 역시 위반 유형마다 다릅니다. 최대 3,500만 유로 또는 전 세계 연 매출의 7%는 Article 5의 금지 관행 위반 상한입니다. Article 16 등 일반 사업자 의무 위반 상한은 1,500만 유로 또는 3%이며, 중소기업에는 금액과 비율 중 더 낮은 상한이 적용됩니다. Article 9 경고 하나를 곧바로 ‘7% 벌금 위험’으로 연결해서는 안 되는 이유입니다.

한국의 인공지능기본법은 공식 법령 연혁상 2026년 1월 22일 시행됐습니다. 다만 EU 스캐너의 결과로 국내법 적용 여부까지 판단할 수는 없습니다. 국내 분류와 의무는 별도 공식 법령을 기준으로 검토해야 합니다.