캘리포니아 SB 53 준수: 프런티어 AI 투명성법(TFAIA) 실무 가이드

2025년 9월 29일, 개빈 뉴섬(Gavin Newsom) 캘리포니아 주지사는 미국 최초로 가장 많은 연산 자원을 사용하는 AI 시스템 개발자에게 구속력 있는 안전, 투명성 및 사고 보고 의무를 부과하는 '프런티어 인공지능 투명성법(TFAIA, Senate Bill 53)'에 서명했습니다. 이 법은 2026년 1월 1일부터 시행되었으며, 지난 6개월 동안 대규모 AI 연구소와 성장 중인 중견 모델 개발자들이 위험을 문서화하고, 거버넌스 프레임워크를 공개하며, 규제 당국에 파멸적 위험 시나리오를 보고하는 방식을 조용히 재편해 왔습니다.

귀하의 조직이 파운데이션 모델을 학습, 미세 조정(Fine-tuning) 또는 실질적으로 수정하거나, 다른 개발자들이 의존하는 대규모 컴퓨팅 클러스터를 운영하고 있다면, SB 53은 현재 미국에서 반드시 이해해야 할 가장 영향력 있는 AI 관련 법안입니다. 본 가이드는 규제 대상, 공개 필수 사항, 15일 이내의 중대 사고 보고 메커니즘 작동 방식, 내부 고발자 보호 의무, 그리고 법령을 실무적인 컴플라이언스 프로그램으로 전환하는 방법을 설명합니다.

SB 53의 실질적인 규제 대상

주별로 확산되고 있는 고용 관련 AI 법안(뉴욕시 지방법 144호 또는 콜로라도 AI 법안 등)과 달리, SB 53은 알고리즘 채용 도구, 신용 평가 모델 또는 세입자 심사 시스템을 규제하지 않습니다. 대신 이 법은 훨씬 더 좁은 범주인 '비범한 컴퓨팅 규모로 학습된 프런티어 파운데이션 모델'과 그로부터 발생할 수 있는 '파멸적 위험 시나리오'를 타깃으로 합니다.

이 법은 두 가지 규제 전통의 교차점에 있습니다. 제조물 책임법에서는 사고 발생 시 기업이 위험 평가 결과를 공개하고 당국에 통지해야 한다는 개념을 차용했습니다. 금융 규제법에서는 대형 기업이 소형 기업보다 더 무거운 공시 의무를 져야 한다는 개념을 가져왔습니다. 그 결과, 두 가지 임계값을 기준으로 한 계층화된 규제 체계가 구축되었습니다.

10^26 FLOPs 컴퓨팅 임계값

SB 53에 따른 "프런티어 모델"은 미세 조정 및 이후 수정을 통한 누적 연산량을 포함하여 10^26회 이상의 정수 또는 부동 소수점 연산(FLOPs)을 사용하여 학습된 파운데이션 모델로 정의됩니다. 이 임계값은 현재 철회된 연방 행정명령 14110의 보고 기준 및 EU AI 법(EU AI Act)의 범용 AI 계층과 의도적으로 일치하므로, 대부분의 대형 미국 연구소들은 이미 자신들이 이 기준을 넘는지 알고 있습니다.

간혹 간과되는 부분은 이 법안이 하위 수정 단계에서의 누적 연산량을 합산한다는 점입니다. 임계값 근처에서 학습된 기본 모델을 가져와 추가 사전 학습을 진행하거나, 강화 학습 미세 조정을 수행하거나, 다른 모델과 가중치를 병합하는 경우, 단일 학습 세션이 10^26 FLOPs를 넘지 않더라도 결과물인 파생 모델은 프런티어 모델 지위를 갖게 될 수 있습니다. 모든 기본 모델, 모든 미세 조정, 모든 증류(Distillation) 및 모든 가중치 병합을 목록화하고 각 단계에서 소비된 FLOPs를 추적하는 것은 이제 필수적인 회계 관리가 되었습니다.

대규모 프런티어 개발자를 위한 5억 달러 매출 임계값

"대규모 프런티어 개발자"는 직전 역년 동안 본체 및 계열사의 연간 총매출액이 5억 달러를 초과하는 프런티어 개발자로 정의됩니다. 매출 테스트는 연결 기준으로 적용됩니다. 즉, 모회사, 자회사 및 공통적으로 통제되는 계열사의 매출이 합산됩니다. 10억 달러의 투자금을 유치했지만 실제 매출은 4,000만 달러인 소규모 AI 스타트업은 대규모 프런티어 개발자가 아닙니다. 반면, FLOPs 임계값을 넘는 소규모 AI 부서를 보유한 상장 기술 대기업은 거의 확실히 이에 해당합니다.

이 계층 분류가 중요한 이유는 대규모 프런티어 개발자에게 가장 무거운 의무가 부여되기 때문입니다. 이들은 프런티어 AI 프레임워크 공개, 파멸적 위험 평가 실시, 캘리포니아 비상 서비스국(Cal OES)에 분기별 내부 사용 위험 요약서 제출, 익명의 내부 고발자 채널 유지 등을 수행해야 합니다. FLOPs 임계값은 넘었지만 매출 기준에는 미달하는 소규모 프런티어 개발자들도 여전히 투명성 보고서를 발행하고 중대 안전 사고를 보고해야 하지만, 전체 프레임워크 체계를 준수할 책임은 면제됩니다.

공개 필수 사항: 프런티어 AI 프레임워크

모든 대규모 프런티어 개발자는 웹사이트에 프런티어 AI 프레임워크를 게시하고 최신 상태로 유지해야 합니다. 연례 검토는 필수이며, 중대한 수정 사항이 발생하면 변경 후 30일 이내에 업데이트해야 합니다.

신뢰할 수 있는 프레임워크에는 최소한 다음 내용이 포함되어야 합니다.

파멸적 위험 임계값 및 평가 방법. 개발자가 파멸적 임계값을 넘었다고 간주할 기능(화학, 생물학, 방사능, 핵무기 지원, 대규모 주요 인프라 공격, 자율적 에이전트의 통제 상실 시나리오 등)은 무엇입니까? 배포 전에 이러한 기능을 어떻게 테스트할 예정입니까?
위험 완화 전략. 구체적인 배포 전 완화 조치: 거부 학습(Refusal training), 기능 억제, 배포 제한, 모니터링된 액세스, 단계적 출시 및 배포 후 모니터링.
제3자 평가. 어떤 외부 레드팀, 평가 기관 및 감사인이 모델을 평가하며, 그 결과는 어떻게 반영됩니까?
미출시 모델 가중치에 대한 사이버 보안 프로토콜. 배포 전 가중치를 도난으로부터 보호하기 위한 내부자 위협 통제, 하드웨어 보안 모듈(HSM), 네트워크 세분화 및 액세스 로깅.
중대 안전 사고 대응 절차. 사고의 보고 여부를 누가 결정하며, 15일의 보고 기한은 어떻게 시작되고, 회사와 Cal OES 간의 협력은 어떻게 이루어집니까?
내부 거버넌스 메커니즘. 이사회 수준의 감독, AI 안전 책임자의 역할, 에스컬레이션 경로 및 안전 검토 주기.
표준 준수. 법령에서 기초적인 기준으로 취급하는 NIST AI 위험 관리 프레임워크(AI RMF 1.0) 및 ISO/IEC 42001과의 명시적인 매핑.

프레임워크는 단순한 마케팅 문서가 아닙니다. 이는 법무장관이 회사의 공개 서약이 내부 관행과 일치하는지 평가하는 데 사용할 수 있는 규제용 문건입니다. SEC 위험 요인 공시나 SOC 2 시스템 설명서와 동일한 수준의 엄격함으로 이를 작성하는 것이 올바른 자세입니다.

모든 배포 전 투명성 보고서

대형 개발자뿐만 아니라 모든 프론티어 개발자는 새로운 또는 실질적으로 수정된 프론티어 모델을 배포하기 전에 투명성 보고서를 게시해야 합니다. 투명성 보고서는 프레임워크와는 별개인 모델별 문서로, 다음 내용을 포함해야 합니다:

회사명, 웹사이트 및 안전 우려 사항에 대한 연락 방법
모델 출시일 및 지원되는 언어와 출력 방식 목록
의도된 용도 및 적용 가능한 사용 제한 사항
대형 개발자의 경우, 제3자 평가자의 참여 여부 및 방식을 포함한 파멸적 위험 평가 요약 및 결과

"실질적 수정"에는 주요 기능 업그레이드, 새로운 방식 추가, 훈련 데이터 믹스의 유의미한 변경 등이 포함됩니다. 패치 릴리스 및 일상적인 안전 미세 조정(fine-tunes)은 일반적으로 새로운 투명성 보고서를 요구하지 않으나, 경계선에 있는 사례의 경우 나중에 검찰총장이 보고서 미게시 이유를 물을 때를 대비해 서면 근거를 문서화해야 합니다.

15일 이내 중대 사고 보고 기한

사내 법무팀을 가장 놀라게 한 준수 사항은 사고 보고 기한입니다. 프론티어 개발자는 중대 안전 사고를 발견한 후 15일 이내에 캘리포니아 비상 관리국(Cal OES)에 통지해야 하며, 사고가 공공 안전에 임박한 위협이 되는 경우에는 24시간 이내에 보고해야 합니다.

법령은 중대 안전 사고를 광범위하게 정의합니다:

미공개 모델 가중치에 대한 무단 액세스 또는 도난
파멸적 위험의 실현
배포된 모델에 대한 개발자의 통제권 상실
안전 장치를 무력화하는 기만적이거나 회피적인 모델 행동

방어 가능한 내부 프로세스를 구축한다는 것은 사고가 발생하기 전에 다음 세 가지 질문에 답하는 것을 의미합니다:

누가 결정하는가? 단일 책임 임원(종종 최고 AI 안전 책임자 또는 지정된 대리인)이 문서화된 에스컬레이션 기준에 따라 보고 기한을 시작할 권한을 가져야 합니다.
무엇이 기한을 시작하게 하는가? "발견"이 트리거입니다. 15일의 기간은 발견 시점부터 계산되므로, 사고가 언제, 누구에 의해, 어떤 모니터링 시스템을 통해 발견되었는지 정확하게 내부 문서에 기록해야 합니다.
보고서는 어떻게 전송되는가? Cal OES는 개발자 제출물을 위한 기밀 접수 프로세스를 유지합니다. 보고 팀은 실제 사고가 발생하기 훨씬 전에 민감한 기술 세부 사항의 암호화 전송을 포함한 제출 워크플로우를 연습해야 합니다.

대형 프론티어 개발자의 경우, 의무는 사후 사고 보고에 그치지 않습니다. 대형 개발자는 3개월마다(또는 다른 합리적인 일정에 따라) 프론티어 모델의 내부 사용으로 인해 발생하는 파멸적 위험 평가 요약을 Cal OES에 전송해야 합니다. 이러한 분기별 주기는 SB 53의 고유한 특징이며, 미국 법령이 AI 연구소에 지속적인 내부 사용 위험 조사 결과를 행정 기관에 보고하도록 의무화한 첫 사례입니다.

내부 고발자 보호 및 익명 내부 채널

SB 53은 캘리포니아의 일반적인 내부 고발자 제도 위에 "대상 직원"(프론티어 모델의 파멸적 피해 위험을 평가, 관리 또는 해결하는 업무를 담당하는 직원)에게 적용되는 AI 관련 보호 조치를 추가로 규정합니다.

프론티어 개발자는 대상 직원이 다음 대상에게 정보를 공개하는 것을 방해하거나, 공개를 이유로 보복할 수 없습니다:

캘리포니아 검찰총장
연방 규제 당국
직속 상관 또는 조사 권한이 있는 다른 감독자
위험 평가 업무를 담당하는 다른 대상 직원

보호 대상인 정보 공개에는 (a) 개발자의 활동이 파멸적 위험으로부터 공중 보건 또는 안전에 구체적이고 실질적인 위험을 초래한다는 합리적인 믿음과 (b) 개발자가 SB 53 자체를 위반했다는 합리적인 믿음이 모두 포함됩니다.

대형 프론티어 개발자는 익명 내부 보고 채널도 유지해야 합니다. 법령은 다음을 요구합니다:

대상 직원이 파멸적 위험 우려에 대해 익명으로 제보할 수 있는 워크플로우
제보 직원에게 조사 진행 상황에 대한 월별 상태 업데이트 제공
임원 및 이사에게 제보 내용과 결과를 요약한 분기별 브리핑 제공 (단, 부정행위 혐의를 받는 당사자는 브리핑 대상에서 제외)

법원은 보복 소송에서 승소한 원고에게 변호사 비용을 지급하도록 판결할 수 있습니다. 결정적으로, 법령은 입증 책임을 전환합니다. 대상 직원이 보호 대상 활동이 불이익 조치의 기여 요인임을 입증하면, 개발자는 해당 조치가 독립적인 정당한 사유로 인해 발생했을 것임을 입증할 책임을 집니다.

파멸적 위험의 정의

SB 53의 핵심은 "파멸적 위험"에 대한 정의입니다. 법령은 이를 프론티어 모델이 다음 세 가지 인과 기제 중 하나를 통해 50명 이상의 사망 또는 중상, 또는 10억 달러 이상의 재산 피해나 손실에 실질적으로 기여할 수 있는 예견 가능하고 중대한 위험으로 정의합니다:

무기 지원. 화학, 생물, 방사능 또는 핵무기, 또는 이에 상응하는 피해를 주는 사이버 무기의 제작, 배치 또는 사용에 대한 실질적 기여.
통제되지 않은 유해 행위. 인간의 감독이 제한된 상태에서 모델이 행한 행위로서, 인간이 저질렀을 경우 의도가 필요한 중범죄에 해당하는 행위.
통제권 상실. 모델에 대한 개발자의 통제권 상실로 인해 모델이 실질적으로 유해한 행위에 가담하는 경우.

이 정의에는 중요한 제외 사항이 있습니다. 이미 공개적으로 사용 가능한 정보에 근거한 위험, 합법적인 연방 활동으로 인해 발생하는 피해, 모델의 기여가 실질적이지 않은 피해 등은 범위에서 제외됩니다. 이러한 제외 조항 덕분에 이력서 심사에서의 편향, 환각 현상으로 인한 잘못된 의료 조언, 저작권 침해와 같은 일상적인 애플리케이션 위험이 파멸적 위험 체계를 가동하지 않도록 합니다. 그러한 피해들은 실존하지만, SB 53이 아닌 다른 법률에 의해 다루어집니다.

민사 처벌 및 집행

캘리포니아주 검찰총장은 독점적인 집행 권한을 가집니다. 민사 과태료는 위반 행위당 최대 100만 달러에 달할 수 있으며, 위반 행위의 엄중함에 따라 차등 적용됩니다. SB 53 자체에는 사적 소송권이 포함되어 있지 않지만, 내부고발자 보복 방지 조항은 피해를 입은 직원이 제기하는 민사 소송을 통해 독립적으로 집행될 수 있습니다.

실무적으로 집행 리스크는 다음 세 가지 영역에 집중됩니다:

임계값 우회 시도(Threshold gaming). 분명한 프런티어급 성능을 제공하면서도 10^26 FLOPs 미만을 유지하도록 훈련 실행을 구조화하는 기업은 정밀 조사를 받게 될 것입니다. 법령에 명시된 누적 연산량(cumulative-compute) 문구로 인해 이러한 전략은 유효하기 어렵습니다.
프레임워크의 공백. 이행 증거 없이 정책만 나열한 프레임워크는 각 약속 사항을 운영 산출물, 지정된 책임자 및 감사 로그와 연결한 프레임워크보다 공격받기 쉽습니다.
사고 보고 지연. 15일 이내의 보고 기한이나 24시간 이내의 긴급 위협 보고 기한을 지키지 못하는 것은 규제 당국이 역사적으로 강력하게 처벌해 온 명확하고 문서화 가능한 위반 사례입니다.

90일 이행 계획 수립

SB 53 프로그램을 아직 구축하지 않은 조직의 경우, 다음과 같은 순서가 효과적입니다:

1일~30일: 범위 및 격차 분석.

훈련, 미세 조정(fine-tuning), 병합 또는 실질적으로 수정된 모든 파운데이션 모델의 목록을 작성하고 각각의 예상 누적 연산량을 산출합니다.
직전 회계연도의 연결 매출(모든 계열사 포함)이 5억 달러를 초과했는지 확인합니다.
엔지니어링, 보안, 법무, 홍보 및 인사팀 구성원으로 구성된 부서 간 AI 안전 및 컴플라이언스 워킹 그룹을 구성합니다.
현재의 관행을 NIST AI RMF 1.0 및 ISO/IEC 42001과 대조하여 격차를 파악합니다.

31일~60일: 초안 작성 및 거버넌스.

프런티어 AI 프레임워크를 버전 관리가 가능하고 공개적으로 게시할 수 있는 문서로 초안을 작성합니다.
성능 평가, 위협 모델링, 위험 도메인에서 모델이 프런티어급 성능을 갖춘 것으로 판단하는 기준을 포함한 치명적 위험 평가 방법론을 구축합니다.
문서화된 액세스 로그 및 내부자 위협 모니터링을 포함하여 미공개 가중치에 대한 사이버 보안 통제를 구축합니다.
익명의 내부 보고 채널과 월간 상태 업데이트 및 분기별 이사회 보고를 위한 워크플로우를 수립합니다.

61일~90일: 운영 준비.

가중치 탈취 사고 및 치명적 위험의 현실화 시뮬레이션을 통해 도상 사고 대응 훈련(tabletop exercise)을 실시하고, 15일 및 24시간 보고 워크플로우를 연습합니다.
대상 직원들에게 내부고발자 권리와 익명 채널에 대해 교육합니다.
배포 파이프라인에 있는 모든 모델에 대한 투명성 보고서를 게시하고, 이를 프런티어 AI 프레임워크와 상호 참조합니다.
캘리포니아 비상서비스국(Cal OES)에 제출할 분기별 치명적 위험 요약 보고 및 연례 프레임워크 검토 일정을 예약합니다.

기타 AI 및 개인정보 보호 규제와의 협력

SB 53은 단독으로 존재하는 법안이 아닙니다. 컴플라이언스 팀은 다음 사항들과 연계하여 검토해야 합니다:

법령에서 명시적으로 참조하며 실질적인 거버넌스 토대를 제공하는 NIST AI 위험 관리 프레임워크(NIST AI RMF).
문서화 요건이 상당 부분 겹치며, 하나의 조화된 내부 프레임워크로 두 규제를 모두 충족할 수 있는 EU AI 법의 범용 AI 계층.
고위험 의사 결정 AI에 대한 배포자 의무를 규제하며 하류 고객(downstream customers)에게 적용될 수 있는 콜로라도 AI 법 및 텍사스 책임감 있는 AI 거버넌스 법.
모델 배포와 교차하지만 SB 53과는 독립적으로 운영되는 캘리포니아 소비자 개인정보 보호법(CCPA) 및 자동화된 의사 결정 기술에 관한 캘리포니아 개인정보 보호국(CPPA)의 향후 규칙.
컴플라이언스 기준선을 변화시킬 수 있는 연방 AI 안전 연구소의 자발적 약속 및 향후 제정될 연방 우선 적용 법안.

이 모든 규제 체계 전반에서 정확한 컴플라이언스 기록과 명확한 감사 추적은 필수적입니다. 재무 보고를 뒷받침하는 동일한 문서화 원칙이 AI 거버넌스 보고에도 적용됩니다. 프런티어 AI 프레임워크, 치명적 위험 평가, 사고 로그 및 내부고발자 조사 기록은 최소 5년 동안 보관해야 하며, 경영진 교체나 기업 구조 조정 시에도 유지될 수 있는 방식으로 저장되어야 합니다.

컴플라이언스 및 재무 기록을 감사 가능한 상태로 유지하기

프런티어 AI 프레임워크를 게시하든, 분기별 Cal OES 제출 일정을 관리하든, 검찰총장의 조사에 대비하든, 그 기저에 깔린 규율은 동일합니다. 바로 명확하고 버전 관리가 되며 감사가 가능한 기록을 유지하는 것입니다. AI 네이티브 팀이 코드베이스에 사용하는 것과 동일한 플레인 텍스트 및 버전 관리 방식은 회계 장부 관리에도 훌륭하게 작동합니다. Beancount.io는 재무 데이터에 대한 완전한 투명성과 통제권을 제공하는 플레인 텍스트 회계를 지원합니다. 블랙박스나 벤더 종속성이 없으며, 규제 당국이 요구하는 거버넌스 원칙과 자연스럽게 조화를 이루는 깨끗한 감사 추적을 제공합니다. 지금 무료로 시작하여 왜 많은 개발자와 금융 전문가들이 플레인 텍스트 회계로 전환하고 있는지 확인해 보십시오.