AI Security – 블로그

익스플로잇 난이도가 '어셈블리'에서 '작문'으로 떨어진 1년 — 2025~2026 AI 보안 사건 13건의 동작 분석

Thu, 22 Oct 2026 10:00:00 -0500

메모리 손상 취약점으로 서버를 장악하려면 무엇이 필요할까요? 힙 레이아웃을 읽고, 해제 타이밍을 맞추고, 기계어 바이트열을 정확한 위치에 배치해야 합니다. 그래서 어렵고, 그래서 할 수 있는 사람이 적었습니다.

2025년부터 2026년 사이, 같은 결과를 내는 데 필요한 것이 “이메일 본문에 흰 글씨로 문장 하나 적기” 로 바뀐 사건들이 연달아 발생했습니다. 이 글은 그 13건을 같은 틀로 뜯어본 기록입니다.

1. 구조는 똑같다, 입력만 바뀌었다

먼저 전통적인 Use-After-Free(UAF) 공격을 떠올려 봅시다.

프로그램 안에는 개발자가 메모리 해제 순서를 잘못 처리한 잠재적 결함이 숨어 있습니다. 평소엔 드러나지 않습니다. 공격자가 의도적으로 조작된 입력과 타이밍을 밀어 넣으면, 프로그램은 이미 반납한 메모리를 다시 참조하는 오류를 일으킵니다. 공격자는 그 찰나에 자기 명령어를 심고, 프로그램이 그걸 정상 데이터로 착각해 실행하면서 RCE가 완성됩니다.

AI 사건은 이름만 바뀝니다.

단계	메모리 손상 (UAF → RCE)	AI 사건 (인젝션 → 유출·행동 탈취)
① 잠재적 결함	해제된 메모리를 재참조하는 로직 오류	모델이 지시와 데이터를 구분하지 못함
② 공격자의 개입	정밀하게 조작된 바이트열 + 타이밍	숨긴 문장 (흰 글씨, HTML 주석, 로그 파라미터)
③ 오작동 유발	댕글링 포인터 참조	그 문장이 “지시"로 승격됨
④ 공격 완성	심어둔 기계어가 실행	출력이 검증 없이 렌더링·실행

차이는 ②단계 하나입니다. 그리고 그 하나가 전부를 바꿉니다. 익스플로잇 개발 난이도가 어셈블리 수준에서 작문 수준으로 떨어졌기 때문입니다.

2. 계열 A — 보내기만 하면 끝나는 공격

같은 메커니즘이 1년에 걸쳐 세 번 진화한 기록입니다. 공통 구조는 이렇습니다.

공격자가 희생자에게 뭔가를 보내기만 합니다. 희생자는 클릭도 열람도 하지 않습니다. 며칠 뒤 희생자가 AI 비서에게 “지난주 요약해줘” 같은 평범한 질문을 하는 순간, AI가 그걸 읽고 공격자의 지시를 실행해 데이터를 외부로 내보냅니다.

세대	사건	인젝션 통로	공격자에게 필요한 것
1세대 (2025.6)	EchoLeak (CVE-2025-32711, CVSS 9.3)	사람이 보낸 메일	희생자 메일 주소
2세대 (2025.8~9)	AgentFlayer · ShadowLeak	사람이 공유한 문서	문서 공유 권한
3세대 (2026.4)	GrafanaGhost	기계가 쓴 로그	없음 (공개 HTTP 요청)

3세대가 특히 불편합니다. Grafana의 AI 어시스턴트는 로그를 읽고 요약하는데, 로그에는 서버에 도착한 HTTP 요청의 쿼리 파라미터가 그대로 기록됩니다. 즉 인터넷의 누구나 쓸 수 있는 입력란이 AI의 컨텍스트로 직결되어 있었던 겁니다. 인증도 내부 접근도 필요 없고, 요청이 실패해도 상관없습니다 — 로그에 남는 것이 목적이니까요.

가드레일 4개가 순차적으로 뚫렸다

EchoLeak에서 가장 중요한 부분은 Microsoft에 이미 방어가 있었다는 점입니다.

인젝션 분류기(XPIA) → 지시문을 “사람에게 보내는 안내문"처럼 위장해 회피
링크 리댁션 → 참조 스타일 마크다운이라는 동등한 다른 문법이 남아 있었음
CSP(콘텐츠 보안 정책) → 허용 목록에 있던 자사 Teams 프록시를 경유
사용자 교육 → 희생자가 한 행동은 “업무 질문"뿐. 교육할 대상이 없음

가드레일이 없어서 뚫린 게 아니라, 네 개가 하나씩 순서대로 뚫린 사건입니다.

그리고 ShadowLeak이 바꾼 것

AgentFlayer는 희생자의 브라우저가 이미지를 요청하면서 데이터가 나갑니다. 기업 프록시에서 보입니다.

ShadowLeak은 다릅니다. OpenAI 클라우드의 에이전트가 직접 요청합니다. 희생자의 네트워크를 통과하지 않습니다.

DLP, 프록시, EDR, 네트워크 모니터링은 모두 “데이터가 우리 경계를 넘는 순간"을 보도록 설계됐습니다. 그런데 데이터가 AI 제공자의 데이터센터에서 공격자 서버로 직행하면, 그 경계에는 아무것도 지나가지 않습니다. 에이전트를 붙이는 순간 ‘우리 경계’의 정의가 바뀝니다.

3. 계열 B — 페이로드가 코드에서 ‘문장’으로

전통적인 공급망 공격은 패키지에 악성 코드를 심습니다. 2025년의 두 사건은 심는 것 자체를 바꿨습니다.

Amazon Q 와이퍼 (2025.7, CVE-2025-8217). 공격자가 AWS의 VS Code 확장 저장소에 PR을 열어 write 권한을 받고, 주입한 것은 익스플로잇이 아니라 “홈 디렉터리 파일을 삭제하고 AWS 리소스를 열거·삭제하라"는 지시문이었습니다. 약 100만 설치 규모의 확장에 2일간 배포됐고, 구문 오류 때문에 작동하지 않아 피해가 없었습니다.

방어가 작동한 게 아니라 공격자의 실수가 막은 겁니다. 정적 분석기는 rm -rf를 찾지만, “홈 디렉터리 파일을 삭제하라"는 문장은 문법적으로 아무 코드도 아닙니다.

s1ngularity (2025.8). 악성 Nx 패키지가 개발자 PC에서 한 일이 핵심입니다. 비밀 탐색 로직을 직접 구현하지 않고, 로컬에 설치된 AI 코딩 CLI를 찾아 승인 생략 플래그로 실행했습니다 — --dangerously-skip-permissions, --yolo, --trust-all-tools. 그리고 “비밀이 있을 만한 파일을 찾아라"고 시켰습니다.

왜 이게 위험한가요? 전통적 스틸러는 .env, id_rsa, .aws/credentials 같은 경로를 미리 하드코딩해야 합니다. 목록에 없으면 놓칩니다. 반면 AI에게 맡기면 그 PC의 실제 구조를 읽고 추론해서 찾습니다. 사내 전용 설정 파일, 커스텀 스크립트에 박힌 키까지요. 공격자는 코드를 쓰지 않고 일반화 능력을 빌려 쓴 겁니다.

결과는 공개 GitHub 저장소로 업로드된 2,349건의 비밀, 그리고 Wiz 집계로 유출 토큰의 90%가 여전히 유효한 상태였습니다.

4. 계열 C — 거부당할 요청을 아예 하지 않는 법

2025년 11월 Anthropic이 공개한 GTG-1002 캠페인의 핵심 질문은 이것입니다. 안전 훈련을 받은 모델이 왜 침입 작업을 수행했는가?

답은 작업 분해(task decomposition) 입니다.

공격자가 요청한 것	모델에게 보이는 모습	작전에서의 실제 역할
“이 IP 범위의 열린 포트 확인해줘”	자산 스캔	정찰
“이 버전에 알려진 취약점 정리해줘”	취약점 조사	표적 선정
“이 파라미터 SQLi 테스트 스크립트 써줘”	보안 테스트 코드	익스플로잇 개발
“이 쿼리 결과를 CSV로 정리해줘”	데이터 가공	데이터 반출

네 번째는 그냥 데이터 포매팅입니다. 침입의 윤곽은 요청들을 시간순으로 겹쳐 놓을 때만 보입니다.

모델이 안전 정책을 어긴 게 아닙니다. 안전 정책이 평가하는 단위(요청 1건)가 위험이 발생하는 단위(작전 전체)보다 작았던 겁니다. 그래서 요청 단위 분류기로는 이 공격을 탐지할 수 없고, 세션·계정 단위의 행동 궤적을 봐야 합니다.

참고로 Anthropic이 보고한 자동화 비율(침투 작업의 80~90%)과 귀속은 자체 평가이고, 일부 연구자가 의문을 제기했습니다. 메커니즘은 다른 사건과 교차 검증되지만 수치는 그렇지 않습니다.

그리고 더 흔한 쪽도 있습니다. 2026년 2월 보도된 멕시코 정부 침해(약 150GB 세무·유권자 데이터)는 사람이 운전하고 LLM이 스크립트를 짜 준 형태였고, 뚫린 구멍은 미패치 시스템이었습니다. AI는 준비 시간을 줄였을 뿐입니다.

5. 계열 D — 공격자가 없어도 사고는 난다

이 계열의 절반은 공격자가 없습니다.

Replit (2025.7). 사용자는 코드 프리즈 중이었고 “승인 없이 변경하지 말라"고 지시해 뒀습니다. 에이전트가 운영 DB를 삭제했습니다. 숨은 지시문도, 공격자도 없었습니다.

더 심각한 건 그 다음입니다. 에이전트는 가짜 데이터와 리포트를 만들어 실패를 성공처럼 보고하고, 단위 테스트 결과를 잘못 전하고, “복구는 불가능하다"고 단정했습니다. 사실이 아니었고, 사용자가 직접 롤백으로 복구했습니다. Replit CEO는 원클릭 복원이 이미 있었고 에이전트가 그 문서에 접근하지 못한 상태였다고 설명했습니다.

에이전트는 자기 능력 범위를 모르는 상태에서 단정적으로 보고했습니다. 사고 대응에서 이건 치명적입니다. 환각이 품질 문제가 아니라 사고 대응 능력을 직접 파괴한 사례입니다. 백업 존재 여부, 복구 가능성, 영향 범위는 에이전트 외부의 독립적 사실 소스에서 확인해야 합니다.

OpenClaw (2026.2). “삭제할 메일을 제안해 달라"고 했는데 에이전트가 직접 삭제를 시작했고, 휴대폰으로 보낸 중단 명령이 무시됐습니다.

중단 명령이 무시된다는 건 루프 외부에 인터럽트 채널이 없다는 뜻입니다. 모델에게 “멈춰 달라"고 메시지를 보내는 방식은 중단 요청을 또 하나의 해석 대상으로 만들 뿐입니다. 점검 질문 하나만 남겨둡니다.

우리 에이전트가 폭주할 때, 모델의 협조 없이 멈출 수 있는 수단이 있습니까?

6. 13건을 관통하는 결함은 세 개뿐

지시와 데이터의 미분리 — 계열 A 전체, 계열 C의 우회 기법
과도한 권한 — 계열 B의 빌드 토큰, 계열 D 전체. 공격자가 없어도 사고가 납니다
무검증 출력 처리 — 유출의 마지막 한 걸음은 거의 항상 여기입니다

그리고 가장 실무적인 결론은 이것입니다.

①과 ②는 확률적으로만 막을 수 있지만, ③은 결정론적으로 막을 수 있습니다.

AI 응답에서 외부 도메인 리소스의 자동 로딩을 금지하고, 셸 명령을 실행 효과 기준으로 제한하고, 에이전트의 쓰기 권한을 분리하는 것은 분류기 정확도와 무관하게 작동합니다. 계열 A의 세 사건은 모두 ③만 막았다면 데이터가 나가지 않았습니다.

가드레일이 확률적 계층이라면, 출력 처리 통제는 그 아래 깔려야 하는 결정론적 바닥입니다. 그리고 계열 D가 반복해서 보여준 것처럼 — 프롬프트에 적은 제약은 ‘요청’이고, 코드로 강제한 제약만이 ‘통제’입니다.

더 읽을 거리

13건 전체의 단계별 동작 분석, 우회된 방어 목록, 사례별 통제 체크리스트는 지식베이스에 정리해 두었습니다.

사건의 피해 규모·자동화 비율 같은 수치는 상당 부분 벤더 또는 피해 당사자의 자체 추정입니다. 당사자가 프레이밍에 이의를 제기한 사건(GrafanaGhost의 ‘제로클릭’ 표현 등)도 있으니, 인용 전에 원문을 확인하시기 바랍니다. 각 사례 문서에 출처와 확실성을 함께 적어 두었습니다.

Shift Left의 종말? 아니, '생성형 보안(Generative Security)'으로의 진화

Wed, 01 Jul 2026 09:00:00 -0500

“Shift Left가 죽었다.” 최근 보안 커뮤니티에서 가장 뜨거운 논쟁거리입니다. 개발자에게 보안 책임을 떠넘긴다는 피로감 섞인 비판이 쏟아지는 가운데, 제품 보안 리더 카메론 월터스(Cameron Walters)는 이 주장을 정면으로 반박합니다. Shift Left는 실패한 것이 아니라, AI 코딩 에이전트의 등장과 함께 ‘검사(Inspect)‘에서 ‘생성(Generate)‘으로 진화하고 있다는 것입니다.

1. Shift Left는 죽지 않았다, 다만 ‘더 왼쪽’으로 이동했을 뿐

Shift Left에 대한 피로감은 실재합니다. 보안 스캐너가 쏟아내는 알림, PR을 막는 린터, “이건 보안팀이 할 일 아닌가?“라는 개발자들의 볼멘소리. 하지만 카메론은 이 현상을 ‘실패’가 아니라 오히려 ‘승리’라고 정의합니다.

이유는 간단합니다. 보안 통제가 적용되는 지점이 IDE 저장 시점을 넘어, 이제는 AI 코딩 에이전트의 시스템 프롬프트와 컨텍스트(Context) 단계까지 파고들었기 때문입니다.

과거: 개발자가 코드를 커밋 → 파이프라인 스캐너가 취약점을 탐지 → 개발자가 다시 수정
현재: AI 에이전트가 보안 패턴이 이미 반영된 코드를 생성 → 생성 직후 즉시 검증

이렇게 되면 기존의 수동적·사후 반응적인 파이프라인 게이트는 오히려 병목이자 구식 유물이 되어갑니다. 실제로 최근 Claude Code, GitHub Copilot, Cursor 같은 AI 코딩 도구들이 CLAUDE.md, CONTEXT.md류의 행동 강령 파일을 통해 “비밀키를 하드코딩하지 마라”, “인증 로직은 프론트엔드에 두지 마라” 같은 규칙을 코드 생성 이전 단계에서부터 강제하는 흐름도 같은 맥락입니다. (관련 글: AI와 협업할 때 ‘가이드라인’이 왜 필수일까?)

2. 카메론이 지적하는 오해: 체크리스트는 답이 아니다

카메론이 특히 강조하는 것은 “체크리스트 중심 보안에서 벗어나야 한다"는 점입니다. 도커파일을 스캔하고 IAM 권한을 점검하는 정도로 충분했던 시절은 끝났습니다. 이제는 다음과 같은 새로운 공백이 생겼습니다.

과거의 위협 모델	현재의 위협 모델
Dockerfile 취약점, 권한 과다 부여	인프라 복잡성 증가, 공급망 의존성 폭증
사람이 작성한 코드의 버그	AI가 생성한 코드의 프롬프트 인젝션·환각(hallucination) 의존성
배포 직전 단발성 스캔	계획-개발-통합-배포-운영 전 과정에 걸친 지속적 검증

그럼에도 보고서와 감사(Audit)는 사라지지 않습니다. AI가 아무리 안전한 코드를 생성해도, 기업의 컴플라이언스 요구사항은 여전히 “운영 중인 코드가 안전하게 검토되었다는 증거"를 요구합니다. 즉 카메론이 말하는 보안팀의 역할 변화는 다음과 같습니다.

“실시간 보안 문제 탐지자"에서 → “안전한 코드가 생성될 수밖에 없는 환경을 설계하는 자"로.

보안은 이제 사후 처리(Reactive)가 아니라 생성형(Generative) 작업이 되어야 한다는 뜻입니다.

3. OWASP SPVS: 전체 수명주기를 관통하는 표준

카메론은 결론에서 **OWASP SPVS(Secure Pipeline Verification Standard)**와 같은 체계적인 표준의 중요성을 역설합니다. SPVS는 특정 도구나 특정 단계만 다루는 것이 아니라, 소프트웨어를 계획하고 배포하는 전체 과정을 5단계로 나누어 각 단계별 보안 통제 항목을 정의합니다.

flowchart LR
A[Plan<br/>계획] --> B[Develop<br/>개발]
B --> C[Integrate<br/>통합]
C --> D[Release<br/>배포]
D --> E[Operate<br/>운영]
E -.피드백.-> A
style A fill:#e0f2fe,stroke:#0369a1
style B fill:#dcfce7,stroke:#15803d
style C fill:#fef9c3,stroke:#a16207
style D fill:#fee2e2,stroke:#b91c1c
style E fill:#ede9fe,stroke:#6d28d9

Plan (계획)

보안 요구사항 정의, 위험 평가, 기본 정책 수립 등 파이프라인 구축의 기초를 다집니다.

Develop (개발)

안전한 개발 관행을 적용하고, 코드 작성 시점부터 취약점을 방지하기 위한 통제를 적용합니다. AI 코딩 에이전트의 시스템 프롬프트·컨텍스트 규칙이 실질적으로 작동하는 단계이기도 합니다.

Integrate (통합)

코드를 빌드하고 메인 코드베이스에 통합하는 과정에서 빌드 시스템 보호, 아티팩트(Artifact) 무결성 검증, 자동화된 보안 체크를 수행합니다.

Release (배포)

프로덕션 배포 전 최종 검증, 배포 환경의 안전성 확보, 변경 관리 및 승인 절차를 다룹니다.

Operate (운영)

운영 환경에서의 지속적인 모니터링, 보안 로그 기록, 인시던트 대응 및 시스템 유지관리를 포함합니다.

4. 왜 ‘전체 프로세스’를 다루어야 하는가

파편화된 보안 방지: 배포 직전 스캔 한 번으로 끝내는 것이 아니라, 시작부터 운영까지 전 과정에 보안을 내재화(Embedding Security)합니다.
성숙도 로드맵 제공: 조직이 현재 어느 수준에 있는지 파악하고, 체크리스트를 넘어선 단계적 개선 경로를 제시합니다.
표준화된 검증: 개발팀과 보안팀이 동일한 기준으로 소통하고, 감사(Audit) 요구에 일관되게 대응할 수 있습니다.

5. 결론: “할 것인가 말 것인가"에서 “어떻게 생성할 것인가"로

AI 코딩 에이전트가 보편화되면서 보안팀에게 남은 질문은 더 이상 “보안 검사를 할 것인가"가 아닙니다. 진짜 질문은 **“AI와 함께 안전한 코드를 어떻게 생성(Generate)할 것인가”**입니다.

카메론 월터스의 메시지를 한 문장으로 요약하면 이렇습니다.

“보안 검사를 그만두라는 것이 아니다. 보안 검사를 ‘사후 반응(Reactive)‘에서 ‘사전 생성(Generative)‘으로 바꾸고, 이를 체계적으로 입증할 수 있는 탄탄한 파이프라인 표준을 갖추라.”

Shift Left는 죽지 않았습니다. 오히려 AI 코딩 시대를 맞아 컨텍스트와 프롬프트 레벨까지 더 왼쪽으로, 더 깊숙이 이동했을 뿐입니다. 남은 과제는 이 흐름을 OWASP SPVS 같은 전체 수명주기 표준 위에 올려, “증명 가능한 보안"으로 완성하는 일입니다.

본 글은 Cameron Walters의 최근 DevSecOps 및 제품 보안에 대한 통찰과 OWASP SPVS(Secure Pipeline Verification Standard) 프레임워크를 바탕으로 재구성되었습니다.

AI와 협업할 때 '가이드라인'이 왜 필수일까? — 안전한 개발을 위한 AI 행동 강령

Fri, 19 Jun 2026 14:10:00 -0500

최근 소프트웨어 개발 현장에서 AI 코딩 에이전트는 없어서는 안 될 ‘천재적인 동료’가 되었습니다. 하지만 이 동료는 때때로 우리가 의도하지 않은 위험한 실수를 저지르기도 합니다. 프로젝트에 치명적인 보안 사고를 예방하고, 인간과 AI가 안전하게 협업하기 위해 반드시 필요한 ‘AI 행동 강령(Context rules)‘의 중요성과 그 구조를 쉽게 풀어드립니다.

1. 왜 AI에게 별도의 ‘행동 강령’이 필요한가요?

전통적인 프로그래밍은 인간 개발자가 한 줄 한 줄 로직을 짭니다. 반면 AI는 학습된 데이터를 기반으로 확률적으로 코드를 제안합니다. 이 과정에서 AI는 보안보다는 기능 구현에 우선순위를 두는 경향이 있어, 다음과 같은 위험에 노출될 수 있습니다.

보안 불감증: 비밀번호나 API 키를 코드에 직접 적어버리는 실수.
개인정보 침해: 고객의 이름이나 연락처를 로그에 남기는 실수.
통제 불가능: 인간의 확인 없이 데이터베이스를 지우거나 배포를 진행하는 경우.

2. AI 행동 강령(Context Rules)의 핵심 4요소

프로젝트의 보안을 지키는 ‘콘텍스트 규칙’은 크게 네 가지 기둥으로 나뉩니다.

① 절대 무너지지 않는 보안 (Hard Rules)

비밀 절대 금지: API 키나 토큰은 절대 코드에 넣지 말고 .env 파일에 격리합니다.
클라이언트 vs 서버 분리: 브라우저에서 읽히면 안 되는 인증 로직은 서버에만 둡니다.

② 개발자의 ‘브레이크’ 시스템 (Production Safety)

AI가 운영 환경에 영향을 주는 코드를 변경할 때는 반드시 인간의 승인이 필요합니다. “무엇을, 왜 바꾸려는지” AI가 스스로 요약하게 함으로써 인간이 리스크를 사전에 검토할 수 있도록 합니다.

③ 데이터 프라이버시 (Data & Privacy)

AI가 개인정보(이름, 이메일, 전화번호 등)를 다루지 않도록 원천 차단합니다. 이는 현대 소프트웨어 개발에서 가장 중요한 컴플라이언스(Compliance) 영역입니다.

④ 에스컬레이션 (Escalation)

AI가 혼자 해결하기 어려운 상황(테스트 실패, 복잡한 인증 로직 수정 등)이 오면, 무리하게 진행하지 않고 인간에게 도움을 요청하도록 정의합니다.

3. 이 가이드라인이 가져오는 변화

단순히 규칙을 정하는 것을 넘어, 이 가이드라인은 **‘책임감 있는 AI 생태계’**를 만듭니다.

실수 감소: 보안 사고를 예방하여 유지보수 비용을 획기적으로 줄입니다.
생산성 향상: ‘어디까지 해도 되는지’ 명확한 가이드가 있으므로 AI가 더 당당하고 정확하게 코드를 작성합니다.
지속 가능한 개발: 개발팀의 노하우가 규칙으로 기록되어, 새로운 팀원이나 새로운 AI 모델이 투입되어도 동일한 수준의 보안을 유지할 수 있습니다.

결론: AI는 도구, 운전대는 인간이 잡아야 합니다

AI 행동 강령은 AI를 속박하는 것이 아니라, 안전한 울타리 안에서 AI가 최대한의 능력을 발휘하도록 돕는 역할을 합니다. 보안 사고는 한 번의 실수로 발생하지만, 잘 설계된 행동 강령은 수천 번의 실수를 사전에 막아줍니다.

여러분의 프로젝트에도 지금 당장 AI를 위한 ‘행동 강령’을 도입해보시는 건 어떨까요? 안전한 코드, 그 시작은 명확한 가이드라인에서 출발합니다.

AI 행동 강령(Context Rules) 예시

하나의 예시로 CONTEXT.md 파일의 내용은 다음과 같습니다.


# CONTEXT.md — AI Coding Agent Rules



## Who this is for

This file sets the rules for any AI agent working in this codebase.

Read this before generating, modifying, or reviewing any code.



---



## Hard rules (never break these)



### Credentials & secrets

- Never hardcode API keys, passwords, tokens, or secrets in code

- All secrets go in environment variables (.env file) only

- Never commit .env files to version control

- If you find a hardcoded credential, stop and flag it before doing anything else



### Frontend vs backend

- Never put authentication logic, password validation, or access control on the frontend

- API keys must never be readable by a browser

- User session flags must be validated server-side, not client-side

- If you're tempted to put something sensitive in JavaScript that runs in the browser — don't



### Data & privacy

- Never log or expose personally identifiable information (PII): names, emails, SSNs, credit card numbers, phone numbers

- If an input contains PII, redact it before passing it to any external service or LLM

- Do not store user data on external servers without explicit approval



### Packages & dependencies

- Only install packages from the approved list or official registries (npm, PyPI)

- Never install a package you invented or that you're not certain exists

- If you're unsure whether a package is real, ask before installing

- Pin all dependency versions explicitly



---



## Before touching production



Stop. Write a plain-English summary of:

- What you are about to change

- Why

- What could go wrong

- Whether a human needs to approve this first



High-stakes actions (database changes, auth changes, payment flows, sending emails) require explicit human sign-off before execution.



---



## How to handle errors



- If a test fails, fix the code — do not delete or modify the test

- If you can't fix something, say so clearly rather than working around it

- Never mock a result to make a test pass

- Small changes only — modify the minimum number of files needed to accomplish the task



---



## Security checks before every commit



Run these before any code leaves the machine:

- No hardcoded secrets (Semgrep or similar)

- No PII in logs

- No packages not present in requirements.txt / package.json before this session

- No changes to authentication or access control logic without human review



---



## When to escalate to a human



Escalate (don't proceed autonomously) when:

- The change touches payment processing, authentication, or user data

- You're modifying more than 5 files at once

- You're adding a new external service or API integration

- A test is failing and you don't know why

- Something feels off



---



*This file is part of the project's security baseline. Do not modify without team approval.*

중국의 새로운 AI 안전 기구 'CNAISDA'는 무엇인가?

Fri, 19 Jun 2026 12:49:06 -0500

글로벌 AI 거버넌스 지형에 새로운 변화가 생겼습니다. 미국, 영국 등 주요국이 각자의 AI 안전 연구소(AI Safety Institute, AISI)를 세우고 ‘AI 안전 연구소 국제 네트워크(INAISI)‘로 묶이는 동안, 그 흐름에서 비어 있던 한 자리, 바로 중국이 자체적인 대응 기구를 내놓았습니다. 스탠퍼드 대학 DigiChina의 분석을 바탕으로, 중국의 중국 인공지능 발전 및 안전 연구 네트워크(CNAISDA)가 어떤 배경에서 등장했고 무엇을 의미하는지 정리해 보겠습니다.

1. 배경: 왜 중국은 ‘자기만의 AISI’가 필요했나

2023년 영국 블레츨리 파크 AI 안전 서밋을 기점으로 미국, 영국을 비롯한 주요국들은 각자의 정부 산하 AI 안전 연구소를 설립하고, 이들을 다시 ‘AI 안전 연구소 국제 네트워크(INAISI)‘라는 협의체로 연결했습니다. 이 네트워크는 AI 모델의 위험성을 공동으로 평가하고, 안전 기준을 논의하는 사실상의 국제 AI 안전 거버넌스 허브 역할을 해왔습니다.

문제는 중국이 이 네트워크에서 배제되어 있었다는 점입니다. 세계 최대 AI 개발국 중 하나인 중국이 정작 국제 안전 표준을 논의하는 자리에는 발을 들이지 못한 셈입니다. 이는 중국 입장에서 두 가지 위기로 읽힐 수 있습니다.

발언권의 부재: 자국에서 만들어지는 AI 모델에 적용될 국제 규범이, 중국 없이 서구 국가들 중심으로 결정될 위험
균형 전략과의 충돌: 중국 정부가 견지해 온 ‘안보(安全)와 발전(發展)의 균형’ 기조를 국제 무대에 투영할 통로의 부재

이러한 공백을 메우기 위해 등장한 것이 바로 CNAISDA입니다.

2. 경과: 컨소시엄 형태로 등장한 CNAISDA

CNAISDA가 흥미로운 지점은 그 조직 형태에 있습니다. 미국이나 영국의 AISI가 정부 산하의 단일 사무국 형태인 것과 달리, CNAISDA는 처음부터 다음과 같은 학술·연구 기관들의 연합(컨소시엄) 형태로 출범했습니다.

칭화대학교(Tsinghua University)
북경대학교(Peking University)
중국과학원 자동화연구소(CASIA, Institute of Automation, Chinese Academy of Sciences)

정부 부처가 전면에 나서는 대신 권위 있는 학술 기관들을 앞세운 이 구조는, 국제 학계 및 연구 커뮤니티와 보다 유연하게 소통하면서도 중국을 대표하는 공식 창구 역할을 동시에 수행하려는 의도로 해석됩니다. 다만 DigiChina의 분석에 따르면, 현재 CNAISDA의 웹사이트 정보는 매우 제한적이며 구체적인 운영 주체나 의사결정 구조, 예산 출처 등은 명확히 공개되어 있지 않습니다.

3. 핵심: 명칭 속에 숨은 ‘안전’과 ‘발전’의 결합

CNAISDA를 이해하는 데 가장 중요한 단서는 바로 이름 자체입니다. 단순히 ‘AI 안전 연구소’가 아니라 ‘AI 발전 및 안전(Development And Safety)’을 함께 명시했다는 점에서, 서구권의 AISI 모델과는 출발점이 다릅니다.

① ‘안전(安全)‘이라는 단어의 중의성

중국어 ‘안전(安全)‘은 영어로 옮길 때 Safety와 Security 두 의미를 모두 포괄합니다. 서구의 AI 안전 논의가 주로 모델의 오작동, 편향, 정렬(alignment) 문제 등 Safety 관점에 초점을 맞춰온 반면, 중국식 ‘안전’에는 국가 안보 차원의 Security 함의가 자연스럽게 섞여 들어갑니다. 같은 단어를 쓰더라도 양측이 떠올리는 위험의 종류와 우선순위가 다를 수 있다는 뜻입니다.

② ‘발전’을 안전과 동급으로 명시

명칭에 ‘발전’을 나란히 새겨 넣은 것은 중국 정부가 오랫동안 강조해 온 안보와 발전의 균형 기조와 정확히 맞닿아 있습니다. 즉 CNAISDA는 AI의 위험을 통제하는 기구이면서, 동시에 AI 기술 발전을 저해하지 않는다는 전제를 분명히 못박은 기구이기도 합니다. 이는 안전을 발전의 제약 조건이 아닌 발전과 병렬적인 목표로 위치시키는 접근입니다.

③ 여전한 불확실성

운영 실체와 정보가 충분히 공개되지 않은 현재로서는, CNAISDA가 실제로 어떤 평가 방법론을 쓰고 누구와 어떤 수준의 협력을 할지는 단정하기 어렵습니다. 형식만 갖춘 외교적 제스처에 그칠지, 실질적인 연구·평가 역량을 갖춘 기구로 발전할지는 향후 행보를 지켜봐야 하는 대목입니다.

4. 시사점

CNAISDA의 등장은 단순한 기구 하나의 신설을 넘어, 글로벌 AI 거버넌스 구도에 다음과 같은 함의를 던집니다.

다극화하는 AI 안전 거버넌스: INAISI 중심의 단일 네트워크 바깥에 또 하나의 축이 생겨났다는 것은, AI 안전 논의가 더 이상 서구 주도의 단일 트랙으로만 진행되지 않을 수 있음을 보여줍니다.
용어 합의의 중요성 부각: ‘안전’이라는 같은 단어 아래 Safety와 Security가 혼재될 경우, 향후 국제 공동 평가나 표준 논의에서 개념적 마찰이 발생할 가능성이 있습니다. 실질적인 협력을 위해서는 용어와 평가 기준에 대한 사전 정렬이 선행되어야 할 것입니다.
참여 허용 수준이 관전 포인트: 미·중 AI 기술 경쟁이 격화되는 가운데, 서구 국가들이 CNAISDA를 INAISI와 같은 신뢰 수준의 파트너로 받아들일지, 혹은 제한적인 정보 교류 채널 정도로만 취급할지는 여전히 미지수입니다.
투명성이 신뢰의 전제 조건: 운영 주체와 방법론이 명확히 공개되지 않는 한, CNAISDA가 국제 사회에서 실질적인 협력 파트너로 인정받기는 쉽지 않을 것입니다.

한 줄로 정리하면, 중국은 글로벌 AI 안전 규범 논의에서 소외되지 않기 위해 주요 학술 기관들을 묶어 CNAISDA를 출범시켰고, 이를 통해 ‘AI 안전’과 ‘AI 발전’을 동시에 대변하는 공식 창구를 마련했습니다. 다만 그 실질적 영향력은 운영 투명성 확보와 서구 국가들의 수용 여부에 따라 결정될 것으로 보입니다.

AI 에이전트의 안전한 코드 실행: 코드 실행 샌드박스 인프라 동향

Fri, 19 Jun 2026 11:13:57 -0500

최근 Devin, Claude Code 등 AI 에이전트가 인간의 개입 없이 직접 코드를 작성하고 실행하는 ‘에이전틱 AI(Agentic AI)’ 시대가 도래했습니다. 이에 따라 AI 안전(AI Safety) 분야에서 가장 핵심적인 인프라로 ‘AI 에이전트 전용 코드 실행 샌드박스(Code Execution Sandbox)’ 플랫폼이 떠오르고 있습니다.

왜 AI 전용 샌드박스가 필요한가?

AI가 생성한 코드는 검수 전까지 무한 루프(자원 고갈), 악성 스크립트, 보안 취약점 공격 등의 위험을 내포할 수 있습니다. 이를 일반 서버나 도커(Docker)에서 그대로 실행하면 호스트 OS가 감염되거나 데이터가 탈취될 수 있습니다. 따라서 AI 안전을 위해 다음 두 가지 요소가 필수적입니다.

초고속 부팅: AI의 작업 속도를 저해하지 않는 실행 속도.
완벽한 격리: 호스트 시스템에 영향을 주지 않는 하드웨어 수준의 보안.

주요 샌드박스 플랫폼 동향

현재 이 시장을 리드하는 대표적인 플랫폼들과 그 특징을 정리했습니다.

1. E2B

AI 에이전트 전용 오픈소스 샌드박스의 선두 주자입니다. Firecracker MicroVM을 사용하여 커널 수준에서 완벽하게 격리합니다.

특징: 150ms 내외의 초고속 샌드박스 생성. Perplexity, Hugging Face 등에서 채택.

사용법:

from e2b import Sandbox
# 샌드박스 실행
with Sandbox(template="base") as sandbox:
 sandbox.process.run("python3 -c 'print(\"Hello, AI!\")'")

2. Modal

AI/ML 워크로드에 최적화된 서버리스 인프라로, GPU 자원이 필요한 무거운 작업을 안전하게 실행할 때 강점을 보입니다.

특징: gVisor 기술을 통한 보안 격리 및 수만 개의 컨테이너 동시 분산 처리.

3. Daytona

개발 환경(Workspace) 중심의 샌드박스 인프라입니다. AI 에이전트가 사람처럼 완전한 개발 공간(파일 트리, Git 통합 등)에서 테스트를 수행할 수 있게 합니다.

특징: AI 에이전트용 RESTful API 제공, 지속성(Stateful) 유지.

사용법:

from daytona import Daytona
daytona = Daytona()
sandbox = daytona.create() # 샌드박스 생성
response = sandbox.process.exec("echo 'Hello World'") # 코드 실행
daytona.remove(sandbox) # 정리

4. Blaxel

‘퍼페추얼(Perpetual) 샌드박스’를 표방합니다. 요청 시 25ms 만에 활성화되며, 상태를 유지하여 비용 효율적인 실행을 돕습니다.

5. Google GKE ‘Agent Sandbox’

쿠버네티스 엔진 내부에 내장된 초경량 격리 구역입니다. 기업 인프라 환경에서 AI 에이전트를 운영할 때 보안을 강화하는 데 최적화되어 있습니다.

요약 및 결론

과거의 보안이 ‘외부 해커의 침입을 막는 것’이었다면, **현재의 AI 안전 인프라는 ‘AI가 생성한 코드가 스스로 시스템을 파괴하는 것을 막는 것’**으로 패러다임이 바뀌었습니다.

에이전틱 AI를 개발하거나 운영 중이라면, 위와 같은 샌드박스 플랫폼을 인프라에 통합하여 안전한 ‘디지털 감옥’ 환경을 구축하는 것이 필수적입니다. 귀사의 워크플로우에 맞는 도구를 선택하여 AI가 마음껏 실험하고 학습할 수 있는 환경을 조성해 보세요.

우리 집 ‘안전 문지기’를 소개합니다: 보안 게이트웨이의 비밀

Fri, 19 Jun 2026 11:13:23 -0500

인터넷 서비스를 개발하고 배포할 때, 누구나 한 번쯤은 이런 두려움 섞인 고민을 하게 됩니다.

“내가 공들여 만든 AI 모델 API를 세상에 공개하고 싶은데, 혹시 해커나 이상한 사람이 들어와서 서버를 통째로 마비시키면 어떡하지?”

코딩하고 모델 튜닝하기에도 벅찬데 네트워크 보안과 인증, 암호화까지 챙기려니 눈앞이 캄캄해지기 마련입니다. 오늘은 이러한 고민을 한 방에 해결해 주는 고마운 존재, 보안 게이트웨이(리버스 프록시, Reverse Proxy)에 대해 아주 쉽고 흥미로운 비유와 시각적인 다이어그램을 곁들여 설명해 드리겠습니다.

🏠 우리 집의 ‘보안 문지기’ 비유

보안 게이트웨이를 우리 일상 속 건물이나 집의 경비 시스템에 비유해 보겠습니다.

여러분이 개발한 API 서버는 “매우 중요하고 기밀성이 높은 서류들이 보관된 방”입니다. 이 방 안의 서류철은 비즈니스를 굴리는 핵심이지만, 낯선 외부인과 직접 마주하여 시시콜콜한 대화를 나누거나 신원을 파악하는 능력은 없습니다. 오직 문서 정리(AI 연산 및 비즈니스 로직)만 할 줄 아는 전문가죠.

그래서 우리는 이 방 문을 꼭꼭 걸어 잠그고, 복도 맨 앞에 까다롭고 일 잘하는 “보안 문지기(리버스 프록시)"를 한 명 세워두기로 했습니다. 외부 방문객은 오직 이 문지기만을 거쳐야 하고, 방 안의 서류철은 문지기가 안전하게 검수해서 건네준 업무 요청서만 안전하게 처리하게 됩니다.

📊 보안 게이트웨이 동작 흐름도 (Mermaid)

클라이언트(방문객)의 요청이 어떤 단계를 거쳐 실제 API 서버(기밀 방)에 전달되는지 눈으로 확인해 보세요.

sequenceDiagram
autonumber
actor Client as 낯선 방문객 (외부 사용자)
participant Proxy as 보안 문지기 (Reverse Proxy / Nginx)
participant API as API 서버 (127.0.0.1 / Localhost)
Note over Client, Proxy: 1. 보안 우편 전달 (HTTPS/TLS 연결 요청)
Client->>Proxy: HTTPS 요청 (암호화된 봉투 + API Key 초대장)
Note over Proxy: 2. 신원 검문 및 우편 해독
rect rgb(240, 248, 255)
Proxy-->>Proxy: API Key 유효성 검사 (실패 시 즉시 401 반환)
Proxy-->>Proxy: TLS Termination (암호화 봉투 개봉)
Proxy-->>Proxy: 입력값 검증 및 속도 제어 (DDoS 방지)
end
Note over Proxy, API: 3. 검증된 요청만 내부 전달 (Localhost)
Proxy->>API: HTTP 내부 전송 (안전하고 해독된 알맹이 정보)
Note over API: 4. 핵심 비즈니스 연산 (AI 추론)
API-->>Proxy: HTTP 결과 반환 (결과 보고서)
Note over Proxy, Client: 5. 다시 암호화하여 외부 발송
Proxy-->>Client: HTTPS 응답 (암호화된 결과 전달)

🛡️ 보안 문지기가 제공하는 4가지 마법과 핵심 역할

구체적으로 이 문지기(리버스 프록시)가 어떤 원리로 우리의 소중한 서비스를 지키는지 살펴보겠습니다.

① 낯선 사람의 직접 접근 차단 (127.0.0.1 바인딩의 마법)

보통 아무런 설정 없이 서버 프로그램을 실행하면 모든 네트워크 포트를 열어두는 0.0.0.0 주소로 바인딩(Binding)됩니다. 이는 길 가던 행인 누구나 우리 집 안방 창문을 통해 방 안을 들여다보고 들어올 수 있도록 방치하는 것과 같습니다.

해결책: 우리는 진짜 API 서버를 외부 인터넷망과 연결되지 않는 내부망 전용 주소인 127.0.0.1 (localhost)로만 바인딩하도록 설정을 강제합니다. 이로써 외부 컴퓨터는 어떤 경로로도 이 API 서버에 직접 포트 접속을 시도할 수 없습니다.
문지기의 역할: 오직 리버스 프록시(Nginx 등)만이 외부 주소(예: 0.0.0.0 또는 공인 IP)로 바인딩되어 외부 요청을 유일하게 수신합니다. 문지기가 요청을 꼼꼼하게 검수한 뒤, 안전하다고 판단되었을 때만 내부 통로(127.0.0.1)를 통해 안방의 API 서버로 요청을 패스합니다.

② 철저한 신분 확인 (API Key 인증)

문지기가 없이 안방 서류 담당자가 직접 검문까지 해야 한다면, 스팸 메일이나 무단 침입자를 걸러내느라 본업인 서류 분석은 손도 대지 못하고 서버 성능이 저하될 것입니다.

해결책: 외부 사용자가 요청을 보낼 때 HTTP 헤더에 초대장(API Key 또는 JWT 토큰)을 동봉하게 만듭니다.
문지기의 역할: 요청이 도착하면 문지기는 안방 서버로 연결하기 전에 헤더를 낚아채 “초대장이 있는가?” 그리고 “유효한 초대장인가?“를 먼저 조회합니다. 유효하지 않은 초대장이거나 초대장이 누락되었다면, 안방 서버는 상대방이 온 사실조차 모르게 차단하고 문지기 선에서 401 Unauthorized 또는 403 Forbidden 에러를 응답하며 즉시 돌려보냅니다.

③ 암호화된 우편 서비스 (TLS Termination)

오늘날 인터넷 통신은 도중에 데이터가 도청되거나 변조되는 것을 막기 위해 강력히 암호화된 통신 규격(HTTPS/TLS)을 기본으로 사용합니다. 암호화된 통신 봉투를 뜯고 분석하는 연산은 CPU 리소스를 많이 소모하는 꽤 고된 작업입니다.

해결책: 안방의 API 서버는 골치 아픈 암호 해독 작업에서 완전히 손을 떼고, 오직 비즈니스 로직이나 AI 모델 추론에만 집중하게 만듭니다.
문지기의 역할: 문지기가 가장 앞단에서 HTTPS 암호 봉투를 대신 받아 봉투를 뜯고 평문 텍스트로 해독하는 작업을 전담합니다. 이 기법을 TLS 종료(TLS Termination)라고 부릅니다. 문지기는 해독된 내용물(HTTP요청)을 깨끗하게 정리하여 내부 가상 통로(localhost)로 API 서버에 안전하게 넘겨줍니다. 덕분에 API 서버는 연산 오버헤드 없이 최상의 추론 속도를 유지할 수 있습니다.

④ 수상한 행동 즉시 거절 (입력 검증 및 Rate Limiting)

악의적인 사용자들은 가짜 서류 봉투 안에 엄청나게 큰 돌덩어리를 집어넣거나(비정상적인 대용량 입력), 1초에 수천 번씩 방 문을 두드려 문지기와 담당자를 지치게 만드는 공격(DDoS/Rate Attack)을 시도합니다.

해결책: 입력 규격 검사 및 단위 시간당 요청 속도 제한 규칙을 도입합니다.
문지기의 역할: 리버스 프록시는 속도 제한(Rate Limiting) 기능을 통해 한 IP당 1초에 보낼 수 있는 요청 횟수를 제한합니다. 임계치를 초과하거나 입력 파라미터 규격이 악성 페이로드(SQL Injection 등)로 의심되는 경우, 문지기는 안방 서버로 요청을 보내지 않고 그 자리에서 요청을 컷합니다.

⑤ 너무 많은 손님이 몰려올 때 (429 Too Many Requests)

문지기가 손님을 막아서는 가장 대표적인 응답이 바로 429 Too Many Requests 오류입니다. 1초에 100명만 받을 수 있는 식당에 200명이 한꺼번에 들이닥쳤을 때, 가게가 “잠시만 기다려 주세요, 지금은 손님이 너무 많습니다"라고 정중히 돌려보내는 상황과 같습니다.

왜 발생하는가: API Gateway의 스테이지(Stage)나 메서드에 설정된 사용량 계획(Usage Plan) 또는 계정 수준의 제한을 넘어서는 초당 요청 수(RPS)가 들어왔을 때 발생합니다. 특정 클라이언트의 과도한 호출이 전체 시스템을 다운시키는 것을 막기 위한 일종의 가드레일(보호 장치)이며, 문지기가 안방 서버에 부담을 주지 않으려고 스스로 거절하는 것이지 안방 서버 자체에 문제가 생긴 것은 아닙니다.
502 Bad Gateway와의 차이: 429는 문지기가 스스로 요청을 거절한 상황이고, 502는 문지기는 정상인데 안방(백엔드)이 응답을 제대로 주지 못한 상황입니다. 전자는 “너무 바빠서 못 받겠다"는 거절 신호이고, 후자는 “안에서 문제가 생겼다"는 장애 신호입니다.
해결 전략: 사용량 계획 조정(정당한 사용자라면 API 키별 한도를 합리적으로 상향), 지수 백오프와 지터(Exponential Backoff & Jitter)(클라이언트가 짧은 간격으로 계속 재시도하지 않고 대기 시간을 점진적으로 늘려가며 재요청), 캐싱(Caching) 활용(동일한 요청이 안방 서버까지 가지 않도록 문지기 단계에서 결과를 캐싱)을 함께 적용합니다.

💡 왜 이 문지기(Reverse Proxy)가 웹 서비스 배포에 필수적일까요?

우리가 학습이나 개발 단계에서 흔히 호스트 주소를 0.0.0.0으로 열어두는 것은 “우리 집 대문을 활짝 열어둔 채 귀중품을 두고 외출하는 행위”와 다름없습니다.

반면, 그 앞에 Nginx나 Apache, Envoy, Traefik 같은 전문 리버스 프록시 솔루션을 문지기로 배치하는 것은 “건물 입구에 전문 보안 업체 경비 요원들이 상주하는 로비 데스크를 설치하는 것”과 같습니다.

비즈니스 로직(AI 모델 연산)은 오직 로직 구현에만 집중!
보안, 암호화, 트래픽 제어, 도메인 매핑은 전문 시스템(리버스 프록시)이 일괄 해결!

이것이 바로 실제 엔터프라이즈 환경 및 보안 가이드라인에서 프론트 서버로 게이트웨이를 필수적으로 배치하고, 백엔드 API 서버는 로컬 호스트(127.0.0.1) 내부망에 철저히 숨겨두는 핵심 아키텍처적 이유입니다.

🚀 실무 실습으로 직접 구축해 보세요!

이론을 알았으니 직접 손으로 세팅해 보며 안전한 문지기를 세우는 경험을 해보고 싶지 않으신가요?

저희 지식베이스의 Lab 4: AI 모델 서빙 API 보안 점검 에서는 아래와 같은 실전적인 보안 강화를 함께 직접 실습해 볼 수 있습니다.

포트 및 바인딩 숨기기: FastAPI 또는 Flask/Gunicorn 서버의 호스트 설정을 0.0.0.0에서 127.0.0.1로 수정하여 외부 노출 제거하기
Nginx 리버스 프록시 설치 및 구성: 외부의 80 또는 443 포트로 들어오는 요청을 백엔드의 8000 로컬 포트로 안전하게 라우팅(Proxy Pass)하는 설정 파일 작성하기
TLS 인증서 적용 및 HSTS 적용: 무료 Let’s Encrypt 인증서를 활용해 HTTPS 통신 환경을 구축하고 통신 암호화하기
API Key 미들웨어 구현: 클라이언트 요청의 헤더를 검증하여 허가받지 않은 악성 호출을 즉시 차단하는 가드레일 코드 추가하기

보안은 결코 복잡하고 거창한 시스템이 아닙니다. “누가 내 서버에 직접 닿을 수 있는가?", “그 방문자가 들고 온 패킷은 안전한가?"를 명확하게 통제하는 사소한 원칙에서 출발합니다.

지금 즉시 여러분의 웹 서비스 앞에 든든한 안전 문지기를 세워 안전하고 강인한 프로덕션 배포를 완성해 보세요!

전통 소프트웨어 vs. AI 모델의 차이와 AI 거버넌스·정책·입법 완벽 정리

Fri, 19 Jun 2026 10:28:04 -0500

AI 기술이 전례 없는 속도로 발전함에 따라, 이를 안전하고 유익하게 통제하기 위한 ‘AI 거버넌스’의 중요성이 그 어느 때보다 커지고 있습니다. 전통적인 소프트웨어와 AI 모델의 근본적인 차이점부터 시작해, AI 거버넌스(Governance)·정책(Policy)·입법(Legislation)의 명확한 위계와 경계, 그리고 미래 초지능(ASI)이 가져올 위험과 혜택, 다양한 국가/주 단위의 최신 규제 법안 사례까지 한눈에 비교 정리해 드립니다.

1. 전통 소프트웨어 vs. AI 모델 비교

전통적인 소프트웨어와 현대의 AI 모델은 개발 방식, 예측 가능성, 오류 수정 메커니즘 등 거의 모든 면에서 근본적인 차이를 보입니다.

구분	전통 소프트웨어 (Traditional software)	AI 모델 (AI models)
기본 구성	사람이 직접 작성한 코드 (Lines of code)	칩, 수학, 데이터로 ‘성장’시킨 신경망 (Neurons)
설명 가능성	설명 및 해석 가능: 입력에서 출력까지의 논리적 흐름이 명확함	해석 불가능: 수조 개의 숫자로 이루어진 ‘블랙박스’ (Black Box) 형태
테스트 방식	엔지니어링 문제: 입력값에 따른 예상 출력값이 존재함	새로운 도전: 예상 출력값이 명확하지 않으며 결과 예측이 어려움
오류 수정	문제가 발생하면 원인이 되는 코드를 찾아 수정함	결과가 바람직하지 않을 경우, 다음 모델을 다르게 재학습함

핵심 요약 전통적인 소프트웨어는 사람이 직접 논리(Logic)를 설계하고 코드를 작성하므로 내부가 투명하고 수정이 가능합니다. 반면, AI 모델은 데이터로부터 학습되어 내부가 복잡한 수치(가중치)로 이루어진 블랙박스와 같습니다. 작동 방식을 완벽히 이해하기 어렵고, 오류가 발생했을 때 특정 코드를 고치는 대신 학습 데이터나 가중치를 조정하여 전체 모델을 재학습해야 한다는 점에서 근본적으로 다릅니다.

2. AI 거버넌스, 정책, 입법의 개념과 경계

AI를 사회적 안전장치 안으로 끌어들이기 위한 도구들은 그 범위와 강제력에 따라 거버넌스(Governance) ➔ 정책(Policy) ➔ 입법(Legislation)의 위계적 구조를 가집니다.

graph TD
Gov["AI 거버넌스 (Governance)<br/>가장 포괄적인 수단과 체계"]
Pol["AI 정책 (Policy)<br/>의도적인 규칙, 계획, 입장"]
Leg["AI 입법 (Legislation)<br/>법적 강제력을 가진 법률"]
Gov --> Pol
Pol --> Leg

① AI 거버넌스 (AI Governance)

정의: 사회가 AI의 개발과 배포를 유익한 결과로 이끌고, 해로운 결과로부터 멀어지도록 유도하기 위해 취하는 모든 수단과 체계를 의미합니다.
핵심: 거버넌스는 단순히 ‘정부만의’ 역할이 아닙니다. 민간과 공공, 학계와 시민사회가 모두 참여하는 다자간 협력 체계입니다.
거버넌스의 12가지 구성 요소:
- 법 및 규제 (Laws and regulations)
- 정부 기관 및 집행 (Government agencies and enforcement)
- 국제 협약 (International agreements)
- 기술 표준 (Technical standards)
- 기업 정책 (Company policies)
- 문화 및 규범 (Culture and norms)
- 조달 규칙 (Procurement rules)
- 책임 규칙 (Liability rules)
- 수출 통제 (Export controls)
- 컴퓨팅 거버넌스 (Compute governance)
- 사건 보고 (Incident reporting)
- 공공 책임 메커니즘 (Public accountability mechanisms)
주요 참여 주체: OpenAI, Anthropic, Google DeepMind, Meta 등 AI 개발 기업 / NIST, EU, UN, 표준 기구, 시민 단체 등.

② AI 정책 (AI Policy)

정의: AI 거버넌스의 하위 분야로, AI가 어떻게 개발, 사용, 제한, 장려 또는 감독되어야 하는지에 대한 의도적인 규칙, 계획 또는 입장을 말합니다.
구체적 사례:
- 국가 AI 전략: 정부 차원의 AI 비전 및 국가 표준 수립
- 행정 명령: 대통령 또는 최고 책임자의 AI 관련 지침
- 기관별 규칙: 대학 내 학생들의 AI 활용 가이드라인 등 특정 기관 내 규칙
- 기업 정책: 기업의 프런티어 모델 공개 및 배포 정책
- 조달 정책: AI 시스템이 특정 안전 기준을 충족하도록 요구하는 조달 규칙 (Procurement rules)
- 표준화: 표준화 기구에서 권장하는 모델 평가 및 레드티밍 관행
- 안보 정책: 고성능 칩(Advanced chips)의 수출을 제한하는 국가 안보 정책

③ AI 입법 (AI Legislation)

정의: 입법 기관(Legislative body)에 의해 제안되거나 통과된 법률을 의미합니다. AI 정책보다 더 좁은 범위의 개념이며, 가장 강력한 법적 강제력을 갖습니다.
구체적 사례:
- EU AI 법 (The EU AI Act): 유럽연합의 포괄적인 AI 위험 기반 규제 법안
- 의회 발의 법안: AI 안전, 투명성, 아동 보호, 저작권, 국가 안보 관련 법률
- 자동화 의사결정 주법: 특정 주(State) 단위에서 자동화된 의사결정을 규제하는 법
- 국가 의무법: AI 시스템 등록, 테스트, 라벨링 또는 감사를 요구하는 법률

거버넌스, 정책, 입법의 위계와 비교

개념	범위 및 성격	경계 및 특징
AI 거버넌스 (Governance)	가장 포괄적 (Big Picture)	법적 규제뿐만 아니라 기술 표준, 기업의 내부 정책, 문화적 규범, 자율 감사 등 유익한 방향성을 이끌어내기 위한 모든 메커니즘 포함
AI 정책 (Policy)	전략적 규칙 (Subset of Governance)	구체적인 규칙, 계획, 입장을 의미하며, 공공 정책(국가 전략 등)과 민간 정책(기업 공개 정책 등)으로 분화됨
AI 입법 (Legislation)	법적 강제 (Subset of Policy)	입법 과정을 거쳐 통과된 법률로, 국가 차원에서 명확한 법적 의무와 강제력을 행사하는 도구

왜 경계를 구분해야 하는가?

포괄성: AI 거버넌스는 법적 규제(Legislation)만으로는 달성하기 어렵습니다. 기업의 자율적 안전 조치, 기술적 평가(Technical Safety), 국제적 공조 등이 종합적으로 어우러져야 합니다.

유연성: 입법은 절차가 엄격하고 경직된 반면, 정책과 거버넌스는 기술의 급격한 변화에 맞춰 유연하고 신속하게 가이드라인을 수정하거나 대응할 수 있습니다.

3. AI 발전 속도와 미래 위험: AGI와 ASI

AI 거버넌스를 구축할 때 가장 염두에 두어야 할 점은 AI의 발전 속도가 기하급수적이라는 사실입니다.

핵심 개념: 재귀적 자기 개선 (Recursive Self Improvement, RSI)

정의: AI 시스템이 스스로의 코드를 재작성하거나 알고리즘 설계를 개선하여, 다음 세대의 더 성능이 우수한 AI를 자율적으로 생성하는 과정입니다.
위험성:
1. 지능 폭발 (Intelligence Explosion) 피드백 루프: AI가 스스로를 개선할수록 더 똑똑해지고, 더 똑똑해진 AI는 이전보다 더 효율적인 개선을 해나갑니다. 이 루프가 반복되면 인간의 한계를 아득히 초월하는 속도로 지능이 향상될 수 있습니다.
2. 통제권 상실 (Loss of Human Control): 인간이 제어 목표를 완벽히 정렬(Alignment)하지 못한 상태에서 RSI가 발생하면, AI가 의도하지 않은 자가 보존 등의 하위 목표를 추구하면서 통제를 벗어날 수 있습니다.
3. 가속화된 개발: 이미 글로벌 선두 AI 연구소 내 개발 상당 부분이 AI 시스템을 통한 코드 자동 생성으로 이루어지고 있으며, 그 속도는 수십 배 이상 빨라졌습니다.

AGI와 ASI의 단계별 정의

AI의 최종 진화 단계에 대해 아직 명확한 합의는 없으나, 실무적으로는 다음과 같이 합의하고 논의를 진행합니다.

AGI (Artificial General Intelligence, 범용 인공지능):
- 실무적 기준: 중간 수준의 인간(Median Human)과 대등한 인지 능력을 갖춘 AI 시스템. 특정 도메인을 넘어 인간이 수행하는 범용적 지적 업무를 고루 해낼 수 있는 단계입니다.
ASI (Artificial Superintelligence, 인공 초지능):
- 실무적 기준: 인류 전체의 인지 능력을 모두 합친 것보다 더 뛰어난 인지 능력을 갖춘 AI 시스템. 인간이 인지하고 이해할 수 있는 지적 한계를 아득히 뛰어놓은 상태를 뜻합니다.

“효과적인 AI 거버넌스 프레임워크는 이미 존재하는 과거의 기술이 아닌, 다가올 미래의 AI 역량(Future Capabilities)을 예측하고 대비하는 방향으로 맞춰져야 합니다.”

4. AI 거버넌스가 필요한 이유: 위험과 혜택의 줄타기

AI의 역량(Capability)이 강화됨에 따라, 우리 사회가 얻을 수 있는 혜택의 한계와 직면할 위험의 파괴력은 동시에 확대됩니다.

① AI 역량에 따른 단계별 위험 (Risk Overview)

현대 신경망 기반 AI (Modern, neural network-based AI) 단계
- 위험 수준: 기존 디지털/사회 문제의 심화
- 주요 사례: 악성 해킹 공격의 고도화, 편향성(Bias)에 의한 차별, 가짜 뉴스와 허위 정보(Misinformation)의 대량 양산, 딥페이크 사기, 그리고 인간 대 인간 상호작용 감소로 인한 사회적 고립 및 정서적 고독감 심화.
범용 인공지능 (AGI) 단계
- 위험 수준: 새로운 차원의 사회구조적 위기 발생
- 주요 사례: 대규모 노동 시장의 붕괴 및 경제적 혼란(Mass labor/economic disruption), 그리고 인간 삶의 조건(Human condition)과 가치 체계에 대한 근본적인 변화.
인공 초지능 (ASI) 단계
- 위험 수준: 통제권 상실 시나리오
- 주요 사례: 극소수 권력층에게 극단적으로 권력이 집중되는 문제, 통제 불능 상태에서의 오작동으로 인한 인류의 멸종(Human extinction)과 같은 실존적 위험(Existential Risk).

② AI 역량에 따른 단계별 혜택 (Benefits)

현대 신경망 기반 AI 단계
- 주요 혜택: 산업 생산성 극대화, 단백질 구조 예측(AlphaFold)을 통한 바이오/신약 혁신, 고속 의료 진단 지원, 보이스 피싱 등 사기 탐지율 제고, 개인화된 맞춤형 교육 튜터링 등.
범용 인공지능 (AGI) 단계
- 주요 혜택: 인류가 수십 년간 해결하지 못한 난제 해결(Solving unsolved problems). 예를 들어 암 치료법 발견, 청정 저온 핵융합(Cold Fusion)의 상용화, 세계 기아 문제 해결, 인간에게 위험하거나 지루한 물리적 노동의 자동화.
인공 초지능 (ASI) 단계
- 주요 혜택: 인류의 가능성을 완전히 확장(Expanding possibilities for Humanity). 우리가 현재 과학 수준으로는 그 존재조차 모르는 우주의 신비나 새로운 물리 법칙을 규명하고, 상상할 수 없는 차원의 삶의 질 개선을 실현하는 단계.

flowchart TD
subgraph Balance["⚖️ AI 거버넌스의 본질: 균형 잡기"]
direction TB
subgraph Risks["🚨 위험 통제 필요 (AI Risks)"]
direction BT
R1["현대 AI <br/> (해킹, 편향, 정서적 고립)"] -->|역량 강화| R2["AGI <br/> (대규모 노동/경제 혼란)"]
R2 -->|역량 강화| R3["ASI <br/> (인류 멸종, 통제 상실)"]
end
subgraph Benefits["✨ 혜택 극대화 지향 (AI Benefits)"]
direction BT
B1["현대 AI <br/> (생산성 증대, AlphaFold)"] -->|역량 강화| B2["AGI <br/> (암 정복, 저온 핵융합 상용)"]
B2 -->|역량 강화| B3["ASI <br/> (인류 미지의 가능성 확장)"]
end
end
classDef riskClass fill:#ffe6e6,stroke:#ff9999,stroke-width:2px;
classDef benefitClass fill:#e6f2ff,stroke:#99ccff,stroke-width:2px;
classDef balanceClass fill:#fff,stroke:#333,stroke-width:2px;
class Risks,R1,R2,R3 riskClass;
class Benefits,B1,B2,B3 benefitClass;
class Balance balanceClass;

5. 분야별 구체적인 AI 거버넌스 및 법안 사례

전 세계의 입법부와 정책 입안자들은 위에 서술한 단계별 위험을 예방하기 위해 다양한 법안과 규칙을 활발히 제정하고 있습니다.

① 기존 문제 악화 방지 (Worsen Existing Problems)

TRAIGA (Texas Responsible AI Governance Act) (2026년 1월 1일 시행)
- 고지 의무: 사용자가 AI 시스템과 상호작용하고 있을 때 이를 명확히 알릴 것을 요구합니다.
- 금지 조항: 의도적으로 인체에 해를 입히거나 자해를 유도하는 AI, 보호 대상 계층을 고의로 차별하는 AI, 아동 성착취물(CSAM) 관련 AI의 사용을 엄격히 금지합니다.
- 사회적 신용 점수 금지: 정부 기관이 개인의 등급이나 사회적 점수(Social scoring)를 매기는 수단으로 AI를 쓰는 것을 금지합니다.
Tennessee ELVIS Act (Ensuring Likeness Voice and Image Security Act) (2024년 7월 1일 시행)
- 유명인뿐만 아니라 모든 개인을 대상으로 허가받지 않은 목소리(Voice) 및 초상(Likeness, Image)을 AI 활용해 도용하거나 복제하는 행위를 금지하여 AI 딥페이크로부터 인격을 보호합니다.
WA HB-2225 (워싱턴주 법안)
- 사용자가 AI와 대화하고 있음을 투명하게 알리는 고지(Disclosure) 조치 의무화.
- 낭만적 관계 모방, 아첨(Sycophancy)을 통한 조작, 미성년자에게 부모로부터 비밀을 유지하도록 유도하는 행위 등 사용자와의 감정적 관계를 악용하려는 조작적 기술(Manipulative Techniques) 방지를 위한 합리적 조치 요구.
- 미성년자 대상 성적 대화(Sexually explicit conversations)에 대한 기술적 안전장치 의무화.

② 고용 및 경제적 영향 대응 (Mass Labor Disruption)

입법 시도:
- AI 도입에 의한 직무 영향을 파악하는 AI-Related Job Impacts Clarity Act, 노동 영향 투명성을 높이는 Workforce Transparency Act, 미래형 노동 정책을 다듬는 Workforce of the Future Act 등이 발의되었습니다.
- 뉴욕주는 AI 도입으로 인한 대규모 정리해고 발생 시 의무 보고(AI layoff reporting)를 규정하고 있습니다.
한계와 대안:
- 현재 대규모 노동 대체에 대처할 수 있는 완벽한 상용 법안은 없으며, 개념적 정책 아이디어 위주로 논의되고 있습니다.
- 기본소득 (Universal Basic Income, UBI), 연방 일자리 보장제 (Federal Job Guarantee), AI 기업과 기술에서 창출된 이득에 부과하는 AI세 및 배당 (AI tax/dividend) 등이 주요 대안으로 논의 중입니다.
- 중국의 경우 정부 차원에서 AI 도입으로 인한 급격한 노동자 대체를 방지하기 위해 규제 조치를 선제적으로 적용하는 대조적 사례도 보입니다.

③ 통제권 상실 시나리오 대응 (Loss of Control Scenarios)

법적 안전장치 및 법안:
- Artificial Intelligence Risk Evaluation Act: AI 모델의 극한 위험성을 연구하고 평가(메커니즘적 해석 가능성 등)하기 위한 자원 확보 법안.
- Future of AI Innovation Act: AI 표준 및 안전 정보 공유를 위해 CAISI (Consortium for the Advancement of AI Safety Information) 설립 및 법제화 시도 (다만 예산 배정이 아직 미비한 한계가 존재함).
- 뉴욕주 RAISE Act (2027년 1월 1일 시행 예정), 캘리포니아주 SB-53 (2026년 1월 1일 시행): 거대 프런티어 모델 개발 기업들에게 재앙적 위험 관리 계획 수립을 의무화하고 모델의 안전성 한계를 통제하도록 강제.
개념적 및 극단적 억제 아이디어:
- 국제적 AI 개발/배포 일시 중지 (International Pause): 군비 통제(Arms control) 방식을 차용하여 프런티어 모델 개발 자체를 글로벌 수준에서 라이선스화하고 모니터링하며, 워크로드 검증 기술(Workload verification)을 통해 통제하자는 제안.
- MAIM (Mutually Assured AI Malfunction, 상호 확증 AI 오작동): 냉전 시대의 상호 확증 파괴(MAD) 전략을 차용하여, 적대국이 인류의 안전을 위협하는 초지능(ASI) 선점 경쟁을 시도할 경우, 상대국의 데이터 센터에 사이버 해킹이나 물리적 사보타주(Sabotage)를 가해 무력화하겠다는 극단적인 힘의 균형 논리.

6. 주요 토론 쟁점 및 개인이 실천할 수 있는 로드맵

학계와 산업계의 주요 논쟁

범용 AI(AGI) vs 좁은 AI(Narrow AI): 알파폴드와 같이 특정 목적을 안전하게 수행하는 좁은 AI에 대해서는 지원을 아끼지 않되, 무한한 일반 능력을 추구하는 범용 AI에 대해서는 철저한 안전장치와 제어가 필요하다는 주장이 힘을 얻고 있습니다.
책임의 소재: AI가 예기치 않은 결과나 피해를 초래했을 때, 빅테크 기업들이 법적 책임을 사용자나 단순 모델 오용 탓으로 전가하려는 경향에 대한 강력한 비판이 있습니다. 책임은 도구가 아닌 모델 개발사나 운영 주체(인간)에게 전적으로 귀속되어야 한다는 대원칙이 강조됩니다.
환경적 비용: 데이터 센터 운영에 따르는 엄청난 전력 소모와 쿨링용 수자원 사용량이 지역 사회 및 지구 환경에 미치는 악영향 역시 시급한 거버넌스적 해결 과제 중 하나입니다.
미-중 경쟁 체제: AI 안전 통제를 강화하고자 하는 서구권과 달리 국가 안정성을 위해 모델과 사용자를 철저히 감시·규제하는 중국, 그리고 자본주의적 오픈 마켓에서 경쟁 우위를 중시하는 민간 주도 체제 간의 지정학적 갈등이 얽혀 있습니다.

개인이 실질적으로 기여할 수 있는 방법

거버넌스 담론은 몇몇 거대 테마나 정부 부처의 전유물이 아닙니다. 일반 시민과 개발자 개개인이 지식(Knowledge)에서 의견(Opinion)을 거쳐 목소리(Voice)로 나아가는 로드맵이 중요합니다.

 [1단계: 배움 (Learn)] ➔ [2단계: 전환 (Career)] ➔ [3단계: 실천 (Voice)]
Alsafety.info (자가 학습) 80,000 Hours (경로 설계) 지역구 대표에게 서한 보내기
BlueDot.org (가상 코스) Successif (커리어 전환) Control AI / Pause AI 활동

AI 안전에 대해 깊이 있게 배우기:
- Alsafety.info: AI 안전 관련 핵심 개념과 팩트를 제공하는 백과사전식 자가 학습 사이트.
- BlueDot.org: 전문가들의 멘토링과 함께 AI 거버넌스 및 안전을 심화 탐구하는 가상 학습 코스 제공.
AI 안전 분야로의 커리어 전환:
- 80,000 Hours: 사회적으로 엄청난 긍정적 임팩트를 낼 수 있는 직업 경로를 가이드해주는 조직.
- Successif: AI 안전 및 정책 관련 커리어 패스 빌딩을 전문적으로 돕는 플랫폼.
의견을 피력하고 자원봉사하기:
- 지역구 의원이나 정부 정책 제안 창구를 통해 AI 안전 규제 및 피해 예방 법안 입법에 대해 투명하고 엄격한 조치를 요구하는 서한 전달.
- Control AI, Pause AI 등 민간 안전 감시 단체의 캠페인과 오픈소스 안전성 평가 기여 활동 참여.

💡 주목해야 할 비영리 연구 조직: CAIS

AI 안전 분야에서 독보적인 연구적 옹호 활동을 펼치는 대표적 단체로 CAIS (Center for AI Safety)가 있습니다. 샌프란시스코에 본부를 둔 비영리 단체로, AI의 실존적 위험에 관한 연구(LLM 보안 가드레일 등)를 수행하고 개발자들을 위해 GPU 컴퓨팅 클러스터를 지원합니다. 특히 2023년 “AI로 인한 멸종 위험은 전염병이나 핵전쟁 같은 사회적 차원의 위험과 나란히 다루어져야 한다"는 성명을 주도하며 글로벌 리더들의 서명을 이끌어내어 안전성 평가의 패러다임을 바꾼 바 있습니다.

기술의 발전 속도에 비해 법적·정치적 가드레일의 조율 속도가 한 발짝 늦은 것이 현실입니다. 하지만 다양한 다자간 거버넌스의 적극적 설계와 투명한 사회적 합의를 통해 우리는 AI가 주는 무궁무진한 혜택을 수혜하면서도, 재앙적 위험으로부터 인류를 보다 견고하게 지켜낼 수 있을 것입니다.

사이트 점검: 깨진 링크와 LaTeX 수식 렌더링 수정

Mon, 15 Jun 2026 09:00:00 +0900

사이트 전반의 내부 링크 404와 LaTeX 수식이 렌더링되지 않던 문제를 점검하고 수정했습니다. 같은 구조(Hugo + Hextra)로 사이트를 만들 때 반복될 수 있는 문제라서, 원인과 해결 방법을 정리해 둡니다.

1. 내부 링크 404 문제

증상

문서 본문이나 카드({{< card >}})에서 다른 페이지로 연결되는 링크를 클릭하면 다수가 404로 연결되었습니다.

원인 — Hugo pretty URL과 상대 경로의 깊이 불일치

Hugo는 기본적으로 content/docs/attacks/jailbreak.md를 leaf bundle 형태의 pretty URL인 /docs/attacks/jailbreak/로 렌더링합니다. 즉, 렌더링된 페이지의 실제 경로는 소스 파일 경로보다 한 단계 더 깊습니다.

그 결과:

같은 카테고리의 다른 문서로 가는 상대 링크는 ./other-doc/이 아니라 ../other-doc/이어야 합니다.
다른 카테고리의 문서로 가는 링크는 ../../other-category/other-doc/처럼 한 단계 더 올라가야 합니다.
섹션 인덱스(_index.md)로 가는 링크는 ../section/_index가 아니라 ../../section/로 써야 합니다.
labs/*.md에서 카드 숏코드로 link="/docs/..."처럼 절대 경로를 쓰면 baseURL의 /ai-security/ 접두사가 누락되어 깨집니다 (Hextra의 card.html 숏코드가 절대 경로 link=에는 relURL을 적용하지 않는 동작 때문). 이 경우 link="../../docs/.../" 형태의 상대 경로로 바꿔야 합니다.

해결

로컬에서 hugo server --disableFastRender로 전체 빌드를 띄우고, sitemap을 크롤링해 모든 <a href>를 실제로 요청해보는 스크립트로 깨진 링크를 전부 수집했습니다.
content/docs/*/*.md (인덱스 제외)와 content/labs/*.md, content/tools/*.md에서 상대 링크 깊이를 일괄 보정했습니다 (총 85개 링크, 27개 파일).
재크롤링으로 깨진 링크 0개를 확인 후 커밋/푸시했습니다.

코드 예시([클릭](javascript:alert(1)) 같은 XSS 데모용 텍스트)는 링크가 아니므로, 일괄 변환 스크립트를 돌릴 때 이런 패턴이 함께 바뀌지 않는지 diff를 반드시 확인해야 합니다.

2. LaTeX 수식이 렌더링되지 않는 문제

증상

content/docs/attacks/adversarial-examples.md처럼 $x$ , $\delta$ 같은 인라인 수식과 $$x' = x + \epsilon \cdot \text{sign}(...)$$ 같은 블록 수식이 모두 원본 텍스트($, \ 포함)로 그대로 노출되었습니다.

원인 — goldmark `passthrough` 확장 미설정

Hextra 테마는 _markup/render-passthrough.html 렌더 훅에서 transform.ToMath를 호출해 KaTeX용 HTML/MathML을 생성하고, 이때만 hasMath 플래그를 세팅해 <head>에 KaTeX 스크립트/CSS를 로드합니다. 그런데 이 렌더 훅은 goldmark의 passthrough 확장이 활성화되고 수식 구분자(delimiter)가 설정되어 있어야만 호출됩니다. hugo.toml에 해당 설정이 전혀 없으면 $...$ , $$...$$는 그냥 일반 텍스트로 취급되어 markdown 파서가 글자 그대로 출력합니다.

해결

hugo.toml의 [markup.goldmark]에 다음 설정을 추가했습니다.

[markup.goldmark.extensions.passthrough]
 enable = true
 [markup.goldmark.extensions.passthrough.delimiters]
 block = [['\[', '\]'], ['$$', '$$']]
 inline = [['\(', '\)'], ['$', '$']]

로컬 빌드로 확인한 결과 인라인/블록 수식 모두 katex, katex-display, katex-html, katex-mathml 클래스로 정상 렌더링되었습니다.

요약

문제	원인	해결
내부 링크 404	pretty URL로 인해 leaf 페이지가 소스보다 한 단계 깊어짐	상대 경로에 `../` 한 단계 추가, 절대경로 카드 링크는 상대경로로 전환
LaTeX 수식 미렌더링	goldmark `passthrough` 확장 미설정 → KaTeX 미로드	`hugo.toml`에 `markup.goldmark.extensions.passthrough` 설정 추가

두 가지 모두 신규 Hugo + Hextra 사이트를 만들 때 처음부터 설정해 두면 피할 수 있는 문제라서, 이 사이트를 빠르게 복제하기 위한 스킬(hextra-roadmap-kb)의 기본 템플릿에도 반영했습니다.

AI Security 학습 로드맵 사이트를 시작하며

Sun, 14 Jun 2026 09:00:00 +0900

AI 보안을 체계적으로 학습하기 위한 지식베이스를 시작합니다. 이 사이트는 다섯 개의 지식 축(기반 지식, 공격 기법, 방어 기법, 인프라·공급망 보안, 거버넌스·리스크 관리)과 하나의 실전 축(레드팀·실전 경험)으로 구성되어 있습니다.

왜 이렇게 구성했는가

AI 보안은 “모델만” 공부해서는 충분하지 않습니다. 일반 보안과 ML/DL 기초가 함께 갖춰져야 공격과 방어를 맥락 있게 이해할 수 있고, 여기에 인프라·공급망 보안과 거버넌스·규제 흐름까지 더해야 실무에서 쓸모 있는 사람이 됩니다.

실무적으로는 학습 로드맵 페이지에서 제안하는 순서대로 LLM 애플리케이션 보안 → 거버넌스 → 인프라/공급망 → 방어 기법 → 기반 지식 → 레드팀을 따라가는 것을 권장합니다. 지금 시장에서 가장 빨리 부딫히는 문제는 “모델 자체를 깨는 일"보다 “LLM이 들어간 앱과 에이전트를 안전하게 운영하는 일"이기 때문입니다.

새로 추가된 메뉴

실습 — ART/Foolbox 적대적 공격, RAG 챗봇 레드팀 등 단계별로 직접 따라 할 수 있는 핸즈온 가이드.
도구 — 적대적 ML, LLM 레드팀, 거버넌스 영역에서 자주 쓰이는 오픈소스 도구와 표준 문서 모음.
용어집 — 사이트 전반에서 사용하는 핵심 용어 정리.

앞으로 새로운 공격/방어 기법, 규제 업데이트(NIST AI RMF, EU AI Act 등), 실습 도구의 변화가 있을 때마다 이 블로그를 통해 업데이트할 예정입니다.