AI 보안 검사가 못 잡는 키릴 문자 위장 도메인 — IDN 홈그래프 공격 원리와 Python 차단법

키릴 문자 а(U+0430)는 라틴 a(U+0061)와 폰트 렌더링 결과가 사실상 동일하다. 두 코드포인트가 섞인 도메인을 AI 도구 자체 LLM 보안 검사에 넣으면 "이상 없음"으로 통과된다. FinPred에서 2026년 초 실제로 보고된 케이스다. 정규화 한 단계 없이 LLM 판단에만 의존하는 구조가 이 우회를 허용한다. RFC 5891 IDNA 2008 기반 Python 정규화를 입력 수신 지점에 추가하면 막힌다.

FinPred 사건 — AI 보안 검사가 실제로 어떻게 뚫렸나

FinPred는 AI 코딩 환경에 자체 /security-review 기능을 붙여 운영 중이다. 코드베이스에 포함된 외부 링크, 도메인, URL을 자동 스캔해서 이상 여부를 LLM이 판단하는 방식이다. 2026년 초 보고에 따르면, 이 검사를 통과한 코드에 정상 도메인과 시각적으로 동일하지만 코드포인트가 다른 도메인이 포함돼 있었다.

문제가 된 글자는 라틴 소문자 a(U+0061)처럼 렌더링되는 키릴 소문자 а(U+0430)였다. 공격자는 정상 도메인의 첫 글자 하나만 키릴 문자로 교체한 도메인을 코드에 삽입했다. 사람도, LLM 검사기도 "이상해 보인다"는 판단을 내리지 못했다.

이 패턴을 IDN 홈그래프 공격(IDN Homograph Attack)이라 부른다. Unicode Technical Standard #39 Security Mechanisms에서 이미 2005년부터 다루는 공격 유형이다. Inky 위협 인텔리전스 보고서(2022)에 따르면 홈그래프 피싱 도메인은 전체 피싱 도메인의 약 12%를 차지한다. Kaspersky는 2021년 기준 키릴 문자 위장 피싱 도메인이 전년 대비 40% 증가했다고 보고했다.

코드 레벨에서 왜 통과되는가 — Python으로 확인

# 라틴 'a'(U+0061) vs 키릴 'а'(U+0430) — 폰트 렌더링은 동일
latin_domain    = "apple.com"   # U+0061 라틴 소문자 a
cyrillic_domain = "аpple.com"   # U+0430 키릴 소문자 а

print(latin_domain == cyrillic_domain)  # False — 코드포인트 불일치

화이트리스트에 apple.com이 등록돼 있어도 аpple.com(키릴)은 불일치로 판정되지 않는다. LLM 검사기에 이 도메인을 넘기면 모델은 "이상해 보이는가?"를 추론한다. 이상해 보이지 않기 때문에 PASS를 낸다.

ICANN 통계(2024 기준)에 따르면 등록된 IDN 도메인 수는 전 세계 720만 개를 넘는다. 이 중 키릴 문자 포함 도메인이 약 310만 개로 가장 많다. 공격에 활용 가능한 시각 동일 쌍은 라틴-키릴 조합에서만 36쌍 이상이 확인된다.

"Internationalized domain names introduce new risks by allowing visually similar characters from different scripts to coexist in domain labels, enabling homograph attacks that are invisible to both users and automated systems." — RFC 3492 Punycode 구현 배경 분석, IETF

AI 자체 보안 검사가 못 잡는 이유 — 구조적 한계 3가지

학습 데이터에 시각 동일 쌍이 충분히 포함돼 있지 않다

UTS #39가 정의한 혼동 집합(Confusable Set)에는 현재 7,500개 이상의 문자 쌍이 등재돼 있다. LLM이 이 모든 코드포인트 쌍을 학습 시점에 충분히 학습했을 가능성은 낮다.

LLM 검사기는 입력값을 정규화하지 않는다

도메인 검증의 정석은 유니코드 정규화(NFKC)와 IDNA 2008 인코딩을 거친 뒤 비교하는 것이다. LLM 기반 검사기는 입력값을 그대로 언어 모델에 넘긴다.

LLM은 코드포인트 비교 함수가 아니다

보안 전문 기업 SENTRIX에서 레드팀 운영 경험상, LLM 기반 보안 검사는 "이상해 보이는가"라는 질문에 답하는 데는 유효하지만 유니코드 혼용 공격처럼 시각적으로 정상적으로 보이는 공격에는 구조적으로 취약하다.

Python 3줄로 막는 방법 — 입력 수신 지점에 정규화 추가

Punycode 강제 변환 후 비교 — idna 라이브러리

import idna

def normalize_domain(domain: str) -> str:
    """도메인을 RFC 5891 IDNA 2008 기준으로 정규화."""
    try:
        labels = domain.split(".")
        encoded = [idna.encode(label).decode("ascii") for label in labels if label]
        return ".".join(encoded)
    except (idna.core.InvalidCodepoint, idna.core.InvalidCodepointContext) as e:
        raise ValueError(f"유효하지 않은 도메인 문자: {e}")

print(normalize_domain("apple.com"))    # apple.com
print(normalize_domain("аpple.com"))    # ValueError: 유효하지 않은 도메인 문자

혼용 스크립트 직접 검사 — regex 라이브러리

import regex  # pip install regex

def check_script_mixing(domain: str) -> bool:
    for label in domain.split("."):
        has_latin    = bool(regex.search(r'\p{Script=Latin}', label))
        has_cyrillic = bool(regex.search(r'\p{Script=Cyrillic}', label))
        has_greek    = bool(regex.search(r'\p{Script=Greek}', label))
        if sum([has_latin, has_cyrillic, has_greek]) > 1:
            return True
    return False

자주 묻는 질문

IDN 홈그래프 공격이 실제로 한국 서비스에서 발생한 사례가 있나요?

공개된 국내 사례는 아직 드물다. 그러나 기술적으로 막혀 있는 구조가 아니고, ICANN 기준 키릴 문자 위장 도메인은 2024년 기준 전 세계 310만 개 이상 등록돼 있다.

AI 도구 자체 보안 검사를 완전히 믿어도 되나요?

믿으면 안 된다. LLM 기반 보안 검사는 "이상해 보이는가"를 판단하는 도구다. 시각적으로 정상적으로 보이는 공격은 구조적으로 잡지 못한다. 입력 정규화(IDNA 2008), 스크립트 혼용 검사, DNS 검증을 병행해야 한다.

Python 표준 라이브러리만으로 막을 수 있나요?

부분적으로 가능하다. IDNA 2008(RFC 5891) 기준으로 검증하려면 pip로 설치하는 idna 라이브러리가 필요하다. 스크립트 혼용 검사는 regex 라이브러리가 필요하다.

idna 라이브러리가 예외를 던지지 않으면 안전한 도메인인가요?

반드시 그렇지는 않다. IDNA 2008이 허용하는 스크립트 단독 사용 도메인은 예외 없이 통과된다. 스크립트 혼용 검사와 DNS 실존 여부 확인을 추가로 해야 한다.

이 검사를 어느 위치에 추가해야 하나요?

입력 수신 지점이 맞다. DB 저장 직전, 외부 API 요청 생성 직전, 이메일 발송 직전이 대표적인 위치다.

마무리

AI 코딩으로 작성한 코드의 도메인 처리, 외부 링크, 시크릿을 외부 점검으로 한 번 더 확인하고 싶다면 codescan.kr 무료 진단을 이용할 수 있다.