"내 AI 에이전트 코드, EU AI Act 통과할까?" 궁금해서 진짜로 파일 5,754개를 스캔해본 사람이 있어요.
결과는 97% 탈락. 근데 통과한 23개 파일엔, 아무도 의도하지 않은 공통점이 하나 있었습니다.
법무팀 숙제인 줄 알았는데
EU AI Act(EU 인공지능법) 얘기가 나오면 다들 반사적으로 변호사와 문서 작업을 떠올려요. 그런데 최근 Hacker News에 올라온 글 하나가 이 통념을 뒤집었어요.
개발자 한 명이 AIR Blackbox라는 오픈소스 정적분석 도구를 만들어, GitHub 스타 341,000개가 넘는 유명 오픈소스 AI 프로젝트 11개의 파일 5,754개를 EU AI Act 6개 조항(Article 9·10·11·12·14·15) 기준으로 스캔했어요. 결과는 이랬어요.
여기까지만 보면 "역시 규제 대응은 어렵다"는 얘기로 끝날 수 있었어요. 그런데 작성자가 남긴 후속 코멘트가 진짜 포인트였어요. 6개 조항을 전부 통과한 파일 중 하나인 LiteLLM의 인증 모듈이 눈에 띄었는데, 애초에 컴플라이언스를 노리고 짠 코드가 아니었다는 거예요. 이미 접근 제어, 구조화된 로깅, 타임스탬프, 에러 핸들링이 있었을 뿐이었어요.
작성자는 이렇게 정리했어요. "팀들이 프로덕션에 AI 에이전트를 배포하면서도 컴플라이언스 인프라가 전혀 없는 건, 신경을 안 써서가 아니라 이걸 쉽게 만들어주는 도구가 없어서다." 다시 말해, EU가 요구하는 건 특별한 법률 지식이 아니라 이미 알고 있던 엔지니어링 기본기였던 셈이에요.
6개 조항 중 뭐가 진짜 발목 잡는데?
조항별로 뜯어보면 난이도 차이가 뚜렷해요. Article 11(기술 문서화)은 98%가 통과했는데, 이유가 허무할 정도로 단순해요 — 파이썬 개발자들은 원래 docstring이랑 타입 힌트를 쓰거든요. 반대로 Article 9(리스크 관리)는 97%가 떨어졌어요. LLM 호출 주변에 에러 핸들링과 폴백 로직을 갖췄는지를 보는 조항인데, 대부분의 프로젝트가 "일단 되게만" 짜여 있었다는 뜻이에요.
| 조항 | 뭘 보는가 | 5,754개 스캔 결과 |
|---|---|---|
| Article 9 | 리스크 관리 (에러 핸들링·폴백) | 97% 탈락 — 전체 중 최하위 |
| Article 10 | 데이터 거버넌스 (PII 탐지·입력 검증) | 개별 수치 비공개 |
| Article 11 | 기술 문서화 (docstring·타입 힌트) | ★ 98% 통과 — 전체 중 최고 |
| Article 12 | 기록 보관 (로깅·감사 추적) | 개별 수치 비공개 |
| Article 14 | 휴먼 오버사이트 (승인·킬스위치) | 개별 수치 비공개 |
| Article 15 | 정확성·보안 (프롬프트 인젝션 방어) | 개별 수치 비공개 |
작성자가 공개한 건 6개 조항 중 최하위(Article 9)와 최고(Article 11) 두 지점뿐이었어요. 나머지 4개 조항의 개별 통과율은 밝히지 않았지만, 평균이 2.2/6이라는 걸 감안하면 대부분 중간 이하였다는 뜻이에요.
같은 스캐너로 프레임워크 3개를 통째로 까본 사람도 있었어요. CrewAI와 LangFlow는 6개 중 4개를 통과했는데, RAG 파이프라인 도구인 Quivr는 1개밖에 못 건졌어요.
| CrewAI | LangFlow | 한눈에 보면 | |
|---|---|---|---|
| 휴먼 오버사이트 | 560줄짜리 human_feedback 데코레이터 보유 | 가드레일 + 프롬프트 인젝션 탐지 | 둘 다 강함 |
| 기록 보관 | PASS | PASS | Quivr만 WARN |
| 총점 | 4/6 | 4/6 | Quivr는 1/6 |
정리하면, 컴플라이언스 점수는 곧 그 프로젝트의 엔지니어링 성숙도 점수였어요. 휴먼 리뷰 훅과 트레이싱을 이미 잘 갖춘 프로젝트가 자연스럽게 상위권이었던 거죠.
주의
이 스캐너로 다른 오픈소스 프로젝트에 "이런 기능 추가해달라"는 이슈를 올리는 사례도 있었는데, 반응이 늘 좋지만은 않았어요. 브라우저 자동화 프레임워크 browser-use에 올라온 요청은 "not planned"로 종료됐어요. 자동 스캔 결과를 근거로 남의 저장소에 이슈를 올리기 전엔 한 번 더 생각해볼 일이에요.
한국 얘기 아니라고 못 하는 이유
EU AI Act의 고위험 시스템 의무는 2026년 8월 2일부터 전면 시행돼요. 위반 시 최대 3,500만 유로 또는 전 세계 매출의 7% 중 큰 금액이 벌금이고요. EU 사용자를 대상으로 서비스하거나 EU 시장에 AI 시스템을 올린다면, 본사가 한국에 있어도 대상이 될 수 있어요.
그리고 한국도 남 얘기가 아니에요. 2026년 1월 22일부터 AI 기본법이 시행됐고, 한국은 EU에 이어 세계 두 번째로 종합 AI 규제 체계를 갖춘 나라가 됐어요. "고영향 AI"로 분류되면 EU AI Act와 비슷하게 리스크 식별·평가·완화 의무가 생기고, 위반 시 최대 3천만 원의 과태료가 붙어요. 다만 과기정통부가 현장 혼란을 줄이기 위해 최소 1년 이상 규제 적용을 유예하기로 한 상태라, 당장 처벌보다는 준비 기간으로 보는 게 맞아요.
즉 EU 쪽은 8월 2일이라는 확정된 데드라인이 있고, 국내는 유예 기간 중이지만 방향은 이미 정해졌다는 뜻이에요. 지금 코드를 손봐두면 두 규제 모두에 동시에 대비하는 셈이 돼요.
3분 자가진단 — 지금 바로 해보는 법
- 설치하기
pip install air-blackbox한 줄이면 끝. 회원가입도, API 키도 필요 없어요. - 스캔 돌리기
프로젝트 루트에서air-blackbox comply --scan. -v실행. 로컬에서만 분석하고 코드는 절대 외부로 안 나가요. - 취약 조항부터 확인
대부분 Article 9(리스크 관리)·10(데이터 거버넌스)에서 걸려요. LLM 호출 주변 에러 핸들링과 입력 검증부터 보세요. - 이미 있는 것부터 인정하기
docstring·타입 힌트가 있으면 Article 11은 이미 거의 통과예요. 새로 만들 것과 이미 있는 것을 구분해서 우선순위를 잡으세요. - 프레임워크 전용 레이어 추가(선택)
LangChain·CrewAI 등을 쓴다면pip install air-blackbox[langchain]처럼 전용 트러스트 레이어를 얹을 수 있어요.
핵심 포인트
제작자 스스로도 못박아요. "인증된 컴플라이언스 테스트가 아니라, 잠재적 갭을 찾는 출발점이다." 스캔 통과가 법적 면죄부는 아니라는 뜻이에요.
