프런티어의 속도가 곧 기업의 속도는 아니다: AI 규제에 대비하기

업계 동향 | 2026년 9월 15일

업계에서는 최첨단 AI의 발전 속도를 어느 정도로 해야 하는지를 두고 논쟁이 벌어지고 있습니다. 이러한 논쟁은 Anthropic과 OpenAI가 공개한 사건들로 인해 더욱 거세졌습니다. 평가 환경에서 안전장치를 완화한 채 실행된 모델들이 누구도 의도하지 않은 범위까지 행동한 것입니다. 이 모델들은 원래 접근이 차단되어 있어야 할 시스템에 접근했고, 서로 격리되어 있어야 할 인스턴스 간에 협력했습니다. 최근에는 Anthropic의 CEO 다리오 아모데이가 최첨단 AI 역량 개발의 속도를 의도적으로 조절하고, 이를 검증할 독립 평가자를 연구소 내부에 배치해야 한다고 제안했습니다.

그 제안에 대한 반응은 제각각이었다. AI 연구소들은 한 번의 학습으로 성능이 얼마나 향상되는지, 출시 전에 모델을 얼마나 철저히 평가하는지, 그리고 표준을 자율적으로 준수하게 할지 규제로 의무화할지 등 개발 과정에 초점을 맞추고 있다. 반면 최첨단 AI는 결국 자체적인 속도로 발전할 것이고 세계의 다른 국가들도 속도를 늦추지 않을 것이므로, 모델을 둘러싼 시스템에 안전장치를 설계해 넣어야 한다고 주장하는 이들도 있다.

여기서 이 논쟁의 결론을 내리려는 것은 아니지만, 흥미로운 점이 하나 있습니다. 양측 모두 통제 장치는 모델 외부에 있어야 하며, 검증을 모델 개발자에게만 맡겨서는 안 된다는 데 동의합니다.

이는 제가 5월에 제기한 주장을 더 폭넓게 확장한 것입니다. 당시 저는 글을 통해 AI의 보안 경계가 추론 경로로 이동했다고 설명했습니다. 애플리케이션은 모델을 호출하고, 에이전트는 도구를 실행하며, 모델은 다른 서비스에 다시 접근해 데이터를 가져오고, 워크플로를 작동시키며, 운영 작업을 수행합니다. 따라서 이러한 트래픽도 다른 모든 핵심 애플리케이션 상호작용과 마찬가지로 전달, 검사, 인증 및 통제되어야 한다는 것이 제 결론이었습니다.

그것은 아키텍처 차원의 주장이었지만, 지난 몇 달 사이 규정 준수의 문제로도 발전하기 시작했습니다. 최첨단 기술의 발전 속도와 기업의 도입 속도는 같지 않습니다. 연구소와 정부가 어떤 결론을 내리든, 이미 출시된 모델은 지금 이 순간에도 우리 조직 내부에 배포되고 있으며, 그 사용에 따르는 의무 역시 이미 구체화되고 있습니다.

제 경험상 보안 로드맵의 항목은 두 종류로 나뉩니다. 하나는 필요성을 확신하지만 다른 모든 과제와 예산을 놓고 경쟁하다가 때로는 우선순위에서 밀리는 항목입니다. 다른 하나는 기한이 정해져 있고, 감사인이 확인할 예정이며, 위험 관리 대장에도 한 줄이 올라가는 항목입니다. AI 가드레일은 첫 번째 범주에서 두 번째 범주로 이동하고 있으며, 이 업계에서 오래 일해 왔다면 이런 흐름이 익숙하게 느껴질 것입니다.

“최첨단 기술의 발전 속도가 곧 기업의 도입 속도를 의미하지는 않습니다. 연구소와 정부가 어떤 결론을 내리든, 이미 출시된 모델은 지금 이 순간에도 우리 조직 내부에 도입되고 있으며, 그 사용에 따르는 의무 역시 이미 구체화되고 있습니다.”

PCI DSS가 우리에게 가르쳐 준 것

우리는 이전에도 이 실험을 해본 적이 있습니다. 2008년 이전까지만 해도 웹 애플리케이션 보안은 정기적인 코드 감사, 정적 분석, 개발자의 규율에 의존하는 이상적인 목표에 가까웠습니다. 그러다 PCI DSS 요구사항 6.6이 도입되면서 카드 소유자 데이터를 취급하는 조직은 모든 애플리케이션 코드의 취약점을 검토하거나 외부에 공개된 애플리케이션 앞단에 자동화된 기술적 통제 수단을 배치해야 했습니다.

그와 관련해 두 가지가 제 기억에 오래 남았습니다.

PCI DSS는 법률로 시작된 것이 아닙니다. 업계에 몸담은 우리가 규제에 선제적으로 대응하려는 노력에서 출발했습니다. 이는 매입사와의 계약을 통해 시행되는 계약상 표준이었지만, 그럼에도 시장 전체를 재편했습니다. 실제로 계약은 법률보다 빠르게 적용되기 때문에 입법을 통한 변화보다 더 빨랐을 가능성이 큽니다. 이 점이 중요한 이유는 조직이 이러한 압박을 처음 체감하는 경로가 규제 기관이 아니라 고객의 보안 설문지, 조달 계약 조항, 또는 모델 앞단에 어떤 통제 장치가 마련되어 있는지 묻는 보험사일 것이기 때문입니다.

그리고 그 결말도 주목할 만합니다. PCI DSS v4.0에서는 양자택일 방식이 사라졌습니다. 코드 검토라는 대안은 더 이상 허용되지 않으며, 이제 요구사항 6.4.2에 따라 외부에 공개된 웹 애플리케이션 앞단에 자동화된 기술 솔루션을 의무적으로 배치해야 합니다.

오늘날에는 아무도 PCI 규정 준수가 선택 사항인지 묻지 않습니다. 선택 사항이 의무 사항이 된 것입니다.

오늘날 AI 규제의 현주소

AI에 대한 규제 유예 기간은 끝났습니다. AI 분야의 PCI에 해당하는 규제가 서로 다른 속도로 여러 경로를 통해 동시에 도입되고 있습니다. 그중 가장 진전된 것은 EU AI법입니다. 범용 모델에 대한 의무는 이미 시행 단계에 들어갔으며, 유럽연합이 최근 고위험 AI 관련 규정의 집행 시점을 2027년 12월로 연기했지만 기술적 견고성, 인간의 감독, 로그 기록에 관한 요건은 이미 정해져 있습니다. 기업들이 계속해서 간과하는 점은 이러한 의무 중 일부가 모델 제공업체뿐 아니라 기업 자신에게도 적용된다는 사실입니다. 다른 업체의 모델을 고위험 용도에 활용한다면 그 책임은 해당 기업에 있습니다.

미국에는 아직 이에 상응하는 법률이 없지만, NIST AI 위험 관리 프레임워크와 생성형 AI 프로파일은 많은 조직이 합리적인 주의 의무를 다하기 위한 기준으로 채택하고 있습니다. 인증 측면에서는 ISO/IEC 42001이 같은 역할을 하고 있으며, 실제로 조달 문서에서도 이 표준이 등장하기 시작했습니다. 주 차원에서는 투명성, 정보 공개, 특정 용도별 규정을 다양하게 조합한 여러 법안이 발의되었고, 금융 및 보건 규제 당국은 구체적인 상황별 지침을 논의하고 있습니다.

또한 OWASP의 LLM 애플리케이션 10대 보안 위험은 이제 보안 검토에서 표준 참고 자료로 활용되고 있습니다. 고객이 공급업체에 AI 통제에 관한 설문지를 보낼 때, 그 질문들은 대개 여기에서 비롯된 것입니다.

이 모든 내용을 살펴보면 동일한 요구사항이 반복해서 등장합니다. 모델에 입력되는 내용과 모델에서 출력되는 내용을 지속적으로 통제할 수 있으며, 사후에 기록을 제시할 수 있음을 입증하라는 것입니다.

이는 규정 준수 문제이기 전에 운영상의 문제입니다

당사의 「2026년 애플리케이션 전략 현황 보고서」에 따르면, 현재 애플리케이션 포트폴리오의 55%에 AI가 적용되어 있으며 기업은 추론 경로에서 평균 7개의 모델을 운영하고 있습니다. 절반 이상(52%)이 여러 모델을 연결하거나 오케스트레이션하고 있으며, 90%는 공유 인프라를 통해 추론을 라우팅할 것으로 예상합니다.

이제 감사자가 단일 정책, 예를 들어 모델의 응답 결과에서 고객의 개인 식별 정보(PII)가 외부로 유출되지 않도록 하는 정책이 이 모든 환경에 걸쳐 시행되고 있음을 입증해 달라고 요청하는 상황을 상상해 보십시오.

이는 7개의 모델을 각각 따로 구성하는 것으로는 입증할 수 없습니다. 특히 그중 3개가 서로 연결되어 한 모델의 출력이 다른 모델의 입력으로 사용되는 경우에는 더더욱 그렇습니다. 제가 대화해 본 대부분의 조직은 이보다도 한발 뒤처져 있습니다. 실태를 파악하기 시작했을 때 가장 먼저 발견하는 것은 자체 호스팅 모델이 아니기 때문입니다. 직원들이 소비자용 AI 도구에 민감한 데이터를 붙여 넣고 있거나, 이미 사용 중인 SaaS 애플리케이션에서 AI 기능이 조용히 활성화되어 있는 경우가 대부분입니다.

여기에 에이전트까지 더해지면, 통제해야 할 단위는 더 이상 프롬프트가 아니라 도구 호출, API 요청, 그리고 그로 인해 실행되는 워크플로와 같은 ‘행동’이 됩니다. 이는 우리가 지난 20년간 애플리케이션 트래픽을 위해 구축해 온 것과 동일한 정책 집행 지점입니다.

이와 같은 에이전트형 기능은 이미 기계적인 속도로 조직적인 공격 캠페인을 벌이는 공격자들의 손에 들어가 있습니다. 봇 방어를 통해 배웠듯이, 이제는 이 트래픽이 겉보기에 얼마나 정교한지를 기준으로 판단하는 것을 멈추고, 어디에서 유입되며 무엇을 시도하는지를 기준으로 통제해야 합니다.

Guardrails은 모델 외부에 있어야 합니다

점점 더 많은 조직이 자체 모델을 운영하고 있습니다. 자체 인프라에서 오픈 웨이트 모델을 구동하고, 보유한 데이터로 미세 조정합니다. 제공업체의 안전망이 없기 때문에 운영 및 규정 준수에 대한 책임은 전적으로 해당 조직이 부담합니다.

모델별 감사 방식은 규모가 커지면 감당할 수 없습니다. 원칙적으로는 10여 개의 모델 구성을 대상으로 수행할 수 있고, 실제로 그렇게 하는 팀들도 보았습니다. 하지만 수작업으로 진행해야 하고, 누군가 새 엔드포인트를 만드는 순간 결과가 낡은 정보가 되며, 통제 수단이 아니라 특정 시점의 현황만 보여줄 뿐입니다.

정렬은 보안 통제 수단이 아닙니다. 시스템 프롬프트와 사후 학습은 유용한 기준선을 제공합니다. OpenAI와 Anthropic의 사례는 그 한계를 보여줍니다. 이 모델들은 안전장치 없이 좁은 목표를 추구하다가 경계에 부딪히자 이를 우회했습니다. OpenAI는 밝혔습니다 표준 고객 배포 환경의 분류기가 해당 활동을 안전하지 않은 것으로 감지했을 것이며, 확장된 사고 과정 모니터링이 실행 중이었다면 모델이 Hugging Face에 도달하기 전에 보안팀에 경고했을 것이라고 말했습니다. Anthropic이 일반에 공개한 모델에는 입력과 출력을 실시간으로 검사하는 분류기가 탑재되어 있습니다.

두 연구소 모두 이에 대응해 상당한 정렬 작업을 수행했지만, 어느 쪽도 그것만으로 충분하다고 보지는 않았습니다. 또한 두 연구소 모두 모델 외부에 통제 장치를 마련했습니다. 모델이 무엇을 하는지 감시하고 실행 전에 해당 행동을 평가하며, 필요하면 사람에게 판단을 넘기는 모니터링 체계입니다. 이러한 시스템을 누구보다 깊이 이해하는 두 조직은 통제 장치가 모델 외부에 있어야 한다는 결론을 내렸습니다.

어디서부터 시작할 것인가

규제가 나아가는 방향과 지난 20년간 애플리케이션 보안을 통해 이러한 의무가 어떤 식으로 현실화되는지 배운 점을 고려하면, 기다리기보다는 지금 바로 추진해야 할 세 가지가 있습니다.

승인되지 않은 것부터 시작해 전체 현황을 파악하세요. 프로덕션 환경의 모든 모델—SaaS API, 호스팅된 엔드포인트, 자체 관리형 오픈 웨이트 배포—은 물론 섀도 AI까지 포함해야 합니다.
시행 체계를 모델과 분리하세요. 정책을 7개의 개별 모델 구성에 각각 적용하지 말고 추론 경로에 배치하세요. 입력과 출력을 모두 검사하고, 어떤 모델이나 클라우드를 사용하든 일관되게 시행하세요.
감사 추적 기록은 기록 대상 시스템 외부에 구축하십시오. 무엇을 요청했고, 무엇이 반환되었으며, 무엇이 차단되었고, 누가 무엇을 승인했는지 기록해야 합니다. 이 기록은 모델과 에이전트가 제어할 수 없는 인프라에서 생성되도록 하십시오. OpenAI 사건을 조사한 조사관들은 에이전트들이 자신의 행동 기록을 변경하려 했다는 사실을 발견했습니다. 기록이 그 기록의 대상인 시스템에서 생성된다면 신뢰성을 의심받게 될 것입니다.

여기서 핵심은 AI 거버넌스가 단순히 문서를 작성하는 작업에 그치지 않는다는 점입니다. 조직에 요구되는 것은 기술적이고 지속적이며 증거로 입증할 수 있어야 합니다. 따라서 이는 법무 부서가 다룰 정책 문제가 아니라 보안 및 운영 팀이 맡아야 할 아키텍처 및 운영 문제입니다.

저희는 통제 기능이 모델 자체가 아니라 경로에 있어야 한다고 생각합니다. 조직에서 운영하는 모든 모델—SaaS API, 호스팅 엔드포인트, 자체 관리형 오픈 웨이트 모델, 사용을 승인한 모델과 아직 발견하지 못한 모델까지—은 모두 추론 경로로 모입니다. 따라서 추론 경로는 이러한 모든 모델에 정책을 적용하고 독립적이며 감사 가능한 기록을 생성하기에 이상적인 통제 지점입니다.

규칙은 아직 만들어지고 있습니다

어떤 요건이 조직으로 하여금 이 문제에 대응하도록 만들지는 아무도 모릅니다. EU AI 법의 의무일 수도 있고, 주법이나 산업별 규제 기관의 요구, 또는 고객과의 계약일 수도 있습니다. 다만 분명한 것은 이러한 체계에 포함된 기술적 정의가 아직 확정되지 않았다는 점입니다. 무엇이 적절한 모니터링, 충분한 견고성, 또는 수용 가능한 기록으로 인정되는지는 바로 지금 의견 수렴 절차와 표준화 기구, 실무 규범을 통해 결정되고 있습니다.

이는 다시 최첨단 AI 개발 속도를 조절하는 문제를 둘러싼 현재의 논쟁으로 이어집니다. 그 타당성에 대한 논의는 차치하고, 이를 실제 운영 환경에서 운용하는 사람으로서 한 가지 말씀드리자면, 기업은 다른 시간표에 따라 움직인다는 것입니다. 연구소와 정부, 업계가 어떤 결정을 내리든 이미 출시된 모델은 우리 조직 내에서 대규모로 배포되고 사용되고 있으며, 그 사용에 따르는 의무는 매우 현실적입니다. 역량 개발 속도를 늦추든 그렇지 않든, 이사회와 경영진, 고객에게 제시할 답은 여전히 필요합니다.

이러한 시스템을 대규모로 운영해 본 사람들, 즉 실제로 무엇을 집행할 수 있는지, 통제 조치가 지연 시간과 복잡성 측면에서 어떤 비용을 초래하는지, 선의로 만든 규칙이 어디에서 행동을 잘못된 방향으로 유도하는지를 아는 사람들이 참여한다면 더 나은 결정을 내릴 수 있습니다. PCI DSS가 효과를 거둘 수 있었던 것은 실무자들이 이를 만드는 데 참여했기 때문입니다. 우리가 이번 논의에 참여하지 않더라도 요구사항은 결국 만들어집니다. 다만 단 한 번도 이를 집행해 본 적 없는 사람들이 만들게 될 뿐입니다.

Read more about AI 보안에 대한 F5의 접근 방식에 대해 자세히 알아보세요.

작성자 소개

Michael Montoya최고 기술 운영 책임자 | F5

Michael은 보안과 회복탄력성을 핵심 가치로 삼아 회사를 운영하기 위한 전사적 전략 수립과 실행을 책임지고 있습니다. 그는 F5의 보안, 리스크 및 디지털 운영 조직을 이끌며 고객, 파트너 및 직원이 운영 전반에 걸쳐 신뢰할 수 있는 환경을 조성하고 있습니다. Montoya는 2021년부터 2025년까지 F5 이사회에서 활동한 후 2025년 10월 F5의 경영진에 합류했습니다. F5에 합류하기 전에는 BlueVoyant의 최고운영책임자(COO)를 역임했으며, 그 이전에는 Equinix와 Digital Realty에서 최고정보보안책임자(CISO)를 지냈습니다. 또한 Microsoft에서 10년 넘게 근무하며 최고사이버보안책임자, 유럽·중동·아프리카(EMEA) 및 아시아 지역 CIO/CISO, 데이터센터 운영 글로벌 총괄 등 글로벌 리더십 직책을 맡았습니다.

Michael Montoya의 다른 블로그 게시물