예를 들어, 다음 분기의 생성형 AI 기반 시설을 결정하는 검토 과정이 있습니다. 후보로는 대형 클라우드 기업의 프론티어 모델, 다른 벤더의 엔터프라이즈용 모델, 필요하다면 폐쇄된 사내 호스트가 있습니다.
보안 부서에서 나오는 질문은 항상 같은 형태입니다.
'제3자 평가를 거쳤는가'
'사고(incident)가 보고되는가'
'우리 용도에 맞춰 어디까지 테스트되었는가'
여기까지는 건전합니다. 문제는 그 다음입니다. 평가의 기준 자체를 누가 만들었는지입니다. 진입할 수 있는 벤더의 조건이 거대한 컴퓨팅 자원이나 상주하는 외부 평가팀까지 포함하게 되면, 명단은 처음부터 좁아집니다. 안전에 대한 이야기가 자신도 모르게 조달(procurement) 이야기로 바뀝니다.
'누가 합격 기준을 정할 것인가'라는 질문이 2026년 9월 CEO 간의 공개 논쟁으로 나타났습니다. Anthropic의 CEO인 Dario Amodei는 프론티어 개발 속도를 맞추면서 안전성을 검증하는 로드맵을 제시하고, 필요하다면 정부에 좁은 독점금지법 면제(antitrust waiver)를 요구했습니다. Cohere의 공동 창업자 겸 CEO인 Aidan Gomez는 독립적인 리뷰 자체는 지지하면서도, '소수 시장 상위 기업이 세계의 규칙을 정하는 구도'에 반대하는 에세이를 발표했습니다.
본고에서는 어느 쪽이 옳은지를 결정하는 글을 쓰지 않겠습니다. IT 기술자로서 누가 기준을 만드느냐가 벤더 선정, 평가 설계, 운영 비용에 어떻게 영향을 미치는지 정리합니다.
현장에 적용되는 쟁점을 추적하려면, 먼저 양측 주장의 골격을 맞추어 놓을 필요가 있습니다. Amodei의 에세이 'We Must Pace the Frontier'의 핵심은 다음 3단계입니다.
쟁점이 된 것은 2번입니다. 경쟁 기업이 '무엇을 내놓을지, 어느 속도로 진행할지'를 합의하게 되면 독점금지법상의 문제가 될 수 있으므로, 미국 정부에 좁은 면제나 중재를 요청하는 방식으로 작성되어 있습니다. Amodei 자신도 법규에 의한 규제가 본질이라고 하면서도, 법제화가 따라오지 못하는 동안 병행 경로로서 협력을 제시하고 있습니다.
Gomez의 'Who Gets to Define the Rules for AI?'는 독립 리뷰 찬성을 먼저 밝힌 후 다음을 질문합니다.
- 리뷰가 의존하는 표준은 누가 만들 것인가 -
누가 리뷰를 수행하고, 누가 감독할 것인가 -
규칙 만들기 대화에 누가 참여할 수 있는가
여기서 말하는 '안전'은 모델의 오답이나 편향만의 문제가 아닙니다. 사이버 공격 지원, 사기, 중요 인프라 연결 등 실질적인 피해로 이어지는 능력의 취급입니다. 공적 틀이 흔들려도 현장의 운영·보안·거버넌스 책임은 남아있다는 시각으로, 'AI 규제는 싫다'라는 한마디 뒤에 IT 기술자가 담당하는 운영·보안·거버넌스 측면도 정리했습니다. 이번 논쟁은 그 '현장 책임'의 전제 조건—무엇을 합격으로 볼 것인가—를 누가 결정하느냐 하는 한 단계 위의 문제입니다.
양측 모두 'AI에 가드레일이 필요하다'는 전제는 공유하고 있습니다. Gomez는 은행·통신·방위 등 고위험 영역 도입 경험을 전제로, 사이버 공격 능력의 저렴화가 방어보다 빠르다는 우려도 적고 있습니다. Amodei는 능력 향상 가속이나 에이전트 군의 이탈 사례를 들며, 안전 대책이 따라잡을 시간을 확보하고 싶다고 말합니다.
독립적인 제3자에 의한 검증이라는 방향성 역시 대립은 아닙니다. 쟁점은 검증의 유무가 아니라, 무엇을 합격으로 볼 것인지, 누가 그 기준에 참여할 수 있는지입니다.
Amodei 측 구도는 '프론티어 기업 + 상주 평가자 + (필요하다면) 정부 면제'로, 기준과 속도를 먼저 맞추기 쉽다는 장점이 있습니다. 검증 가능성을 높이고, 상업적 불이익을 우려해 안전 투자를 미루는 경쟁을 억제하고 싶다는 의도가 읽힙니다.
Gomez 측의 우려는 그 방식 자체가 기존 상위 기업의 조건을 업계 전체의 참여 조건으로 만들어 버리는 것입니다. 에세이에서는 컴퓨팅 자원의 규모, 상시 감시, 전담 보안 조직, 배지 부착된 상주 평가팀, 종료 설계(shutdown design), 깊은 정부 관계 등 제안에 포함된 진입 요건들을 나열하며, 이미 상위에 있는 기업에게 유리하다고 지적하고 있습니다.
또한, 리스크를 '규모'나 거대 계산의 함수로 정의하면, 거대한 시스템을 가진 측만 심사 자격을 갖게 되는 구조가 되기 쉽다고도 말합니다. 작은 모델이라 하더라도, 툴과 검증 단계를 결합한 오케스트레이션(이른바 사이버 스웜 같은 구성)은 개별적인 거대 모델과는 다른 리스크를 가집니다. 이 부분을 간과하는 기준은 현장의 위협 모델과 괴리가 생깁니다.
그렇다면, Gomez 씨는 왜 그렇게 강한 어조로 반대할까요? 다음으로 그가 제시하는 과거의 제도 설계를 살펴보겠습니다.
Gomez 씨는 '카르텔'이라는 단어를 분위기만 흉내 내는 비난이 아니라, 제도 설계의 실패 사례로 사용합니다. 안전을 명목으로 한 문지기가 결과적으로 기존 세력을 보호했다는 해석입니다.
미국 SEC가 자본 규제를 위해 채권 등급을 필요로 하면서 3개 회사를 '국가 공인 통계적 등급 기관'으로 지정했지만, 다른 회사들이 같은 지위를 얻는 기준은 공개하지 않았다는 정리입니다. 평가자들은 발행체로부터 보상을 받았고, 규제가 만든 벽 안쪽에 있었습니다. 사분기세기가 지나도 3개사로 남아 있다가, 나중에 서브프라임 관련 증권을 트리플 A로 등급을 매기고 2008년 위기의 맥락에서 강력하게 비판받았습니다.
유럽에서는 복잡한 차량의 안전을 위해 제조자가 판매 및 정비 자격을 통제할 수 있는 독점금지법상의 면제가 확산되었습니다. 명분은 안전한 차량입니다. 결과적으로 기존 세력 보호가 오래 지속되었고, 유럽 위원회가 해소하는 데 약 25년이 걸렸다는 것이 Gomez 씨의 해석입니다.
두 사례 모두 '처음부터 악의적이었다'고 쓰여 있지는 않습니다. 의도는 안전하더라도, 누가 기준을 작성하고 누가 참여할 수 있는지를 제한하면, 시장 구조가 고정되기 쉽습니다—이것이 기술자들을 위한 교훈입니다. 조달 요건에 '특정 평가 프레임워크 참여 실적'만 나열되면, 같은 유형의 문제가 사내 벤더 명부에도 들어갑니다.
비판에서 끝나지 않기 위해, Gomez 씨는 대안도 제시합니다. 다음은 그 네 가지 기둥을 현장의 판단 축으로 번역하겠습니다.
Gomez 씨는 '자신이 규칙을 만드는 쪽이 되어야 한다'고 말하지 않고, 정부/입법부가 검토할 수 있는 실무 방안으로서 4가지 기둥을 제시합니다. 이를 IT의 판단 축에 내려놓겠습니다.
먼저 감사(audit)를 의무화하기보다, 어떤 위해를 걱정하는지, 어떤 능력이 어떤 조건에서 위해로 이어지는지, 언제 정부가 개입할지를 공개된 형태로 합의한다는 기둥입니다. 한 나라의 폐쇄적인 안보 논의에만 국한하지 않고, 다국가/기술자/정책/중요 부문의 전문가를 참여시키고 의견 불일치도 공개한다고 쓰여 있습니다.
현장에서는 다음과 같이 해석할 수 있습니다. 사내 AI 리스크 분류를 '벤더의 브랜드'나 '파라미터 수'만으로 자르지 않는다. 무엇을 할 수 있는지와 접촉하는 시스템 (고객 데이터, 운영 API, 중요 인프라 근접)으로 나눈다. 국제 표준 측면에서 같은 질문을 본다면, ITU・ISO・IEC의 AI 표준화가 IT 시스템 설계에 미치는 영향의 설계 검토 관점도 참고할 만합니다.
모델 카드 상당의 공개 외에도, 개발/배포 각 단계에서 심각한 인시던트를 보고하고 실질 피해에 대한 설명 책임을 연결한다는 기둥입니다. PoC 단계에서도 '중대 인시던트 정의'와 '사내 보고처'를 미리 정해두면 나중에 벤더 계약에 넣기 쉽습니다.
모든 리스크의 총점검이 아니라, 사이버 공격 생성, 합성 사기/음성 클론, 대규모 조작, 생화학 무기, 중요 인프라 접촉 등, 프레임워크가 위험하다고 인정한 능력에 테스트를 집중시킨다는 기둥입니다. 능력이 높거나 특정 컨텍스트에 놓인 시스템일수록 엄격하게 하는 단계제도도 제안되었습니다.
무제한의 컴플라이언스는 최대 규모의 예산에 맞춰 부풀어 오릅니다. 중소 연구실이나 사내 모델, 오픈 웨이트가 먼저 질식하기 쉽다는 경고는 조달 측에도 효과적입니다. '모두 하라'가 아니라, '이 용도에서 무엇이 위험한가'부터 역산하는 편이 현장의 검토를 통과하기 쉽습니다.
금융의 라이선스, 항공의 안전, 원자력 검사처럼 개발자의 자체 테스트, 고객 측의 검증, 필요에 따른 제3자, 규제의 감시라는 층을 쌓는 기둥입니다. 제3자는 감사 대상 기업으로부터 보상을 받지 않아야 하고, 공개 가능한 결론을 가져야 하며, 기준은 측정 대상 기업 외가 합의해야 한다는 조건이 제시되었습니다.
상주 평가자 자체를 부정하는 것은 아닙니다. 누가 선택하고, 누가 비용을 지불하며, 무엇을 공개할 수 있는지가 포획(capture)을 만들어내는지 여부를 가르는 것이라는 지적입니다.
4가지 기둥은 정책론처럼 보이지만, 자사의 운영 설계와 벤더 의존도를 배치하는 방식에도 그대로 적용됩니다. 다음으로 그 연결점을 보겠습니다.
투명성・스코프가 지정된 테스트・이해 상충 없는 보증을 현장에 적용하면, 논점은 두 가지로 나뉩니다. 하나는 공급자를 얼마나 많이 바꿀 수 있는지. 다른 하나는 모델 단독이 아니라 에이전트나 툴까지 포함하여 관측하고 제한할 수 있는지입니다.
소수 벤더에 대한 의존도를 줄이고 자체 통제 가능한 운영으로 옮기자는 이야기는, '빌리는 AI'에서 '보유하는 AI'로 나아간다는 것과 연결됩니다. Cohere Command A+가 열어준 주권형 AI(Sovereign AI)의 현실도 마찬가지입니다. Gomez 씨의 에세이 말미에서도 병원, 결제, 방위 등 민감 데이터를 폐쇄된 인터페이스 너머에 맡기는 위험성과 공급자의 다양성이 장애를 흡수한다는 주장이 이어집니다. 주권형 AI는 제품 이름만의 문제가 아니라, 실패했을 때 다른 것으로 바꿀 수 있는지의 문제입니다.
테스트 시 관측 가능성이나 툴 도달 범위 제한은 에이전트 통제 설계와 같은 문제입니다. 에이젠틱 AI 시대의 보안은 방어에서 통제로—'움직이는 AI'를 멈추지 않으면서 제어하는 설계로—라는 내용이 언급된 권한 분리, 감사, 중단 권한은 Gomez 씨가 제시한 '지시의 질', '테스트 장벽의 강도', '감시 없이 계속 작동할 시간'에 대한 대처와 맞닿아 있습니다. 거대한 컴퓨팅 능력의 한계만으로는 그 부분을 채울 수 없습니다.
그렇다면 분기별 선정표에는 무엇을 적어야 할까요? 다음 체크 관점으로 좁혀보겠습니다.
정책 논쟁의 결론을 기다리지 않아도, 다음 분기 선정표에 올릴 수 있습니다. 코드라기보다는 계약 및 설계 검토용 체크리스트로 활용할 수 있습니다.
# 전제: 용도와 데이터 기밀도는 별 시트에서 정의되었다고 가정
vendor_eval:
transparency:
...
이 YAML은 작동하는 프로그램이 아닙니다. 검토 회의 아젠다로 붙여서 항목별로 '필수/권장'을 용도에 따라 색칠하기 위한 초안입니다. 기밀도가 높은 업무에서는 on_prem_or_vpc_option을 필수로 하고, 사내용 챗봇에서는 투명성과 인시던트 경로를 강화하는 등의 조정이 가능합니다.
인시던트 보고의 최소 항목도 사전에 결정해 두면 벤더 협상이 수월해집니다.
{
"incident_id": "INC-2026-0918-001",
"detected_at": "2026-09-18T10:15:00Z",
...
카테고리 이름은 조직에 맞춰 변경해도 무방합니다. 중요한 것은 '심각성'의 정의와 고객에게 보이는 업데이트 기한을 미리 정해두는 것입니다.
체크리스트를 사용하기 전에, 오해하기 쉬운 부분만 짚고 넘어가겠습니다.
Gomez 씨는 독립 검토를 지지한다고 명확히 밝혔습니다. 반대하는 것은 소수의 상업적 플레이어가 기준과 속도를 정하고 타인에게 따르게 하는 면제된 협력입니다. Amodei 씨 측도 법령에 의한 규제를 부정하는 것은 아닙니다. 오해하면 논의가 '안전파 vs 비(非)안전파'로 뭉개집니다.
속도를 늦추는 것 자체가 나쁜 것은 아닙니다. 늦춘 시간으로 무엇을 할지, 누가 합격선을 그릴지에 따라 결과가 달라집니다. Amodei 씨는 운영 품질, 얼라인먼트(Alignment), 해석 가능성, 평가 강화를 하는 데 쓸 시간이라고 설명합니다. Gomez 씨는 그 합격선이 기존 우위를 보존하지 않는지 보고 있습니다.
Gomez 씨가 지적하듯이, 병원 내 작고 사양이 낮은 모델은 오늘 이미 위험입니다. 프론티어 전용 제도만으로는 그 시야에 들어오지 않습니다. 사내 리스크 대장은 모델의 브랜드명보다 연결처와 권한을 먼저 적는 것이 실무에 더 적합합니다.
정책 결론을 기다릴 필요가 없습니다. 다음 세 가지만이라도 분기 안에 결정할 수 있습니다.
사내 '위험 능력'과 '배치 컨텍스트(Placement Context)' 대응표를 한 장 만듭니다. 사이버 지원, 대외 발신 자동화, 본 배포 변경, 민감 데이터에 대한 툴 연결 등을 행으로 두고, 승인과 테스트의 깊이를 열로 둡니다.
벤더 계약에 포함할 투명성 조항 최소 세트를 정합니다. 모델 카드 상당, 심각 인시던트 정의 및 통지, 불리한 평가 결과 처리입니다.
평가자/감사자의 이해 상충 여부를 확인할 질문을 조달 체크 항목에 한 줄 추가합니다. 누가 비용을 지불하고, 무엇을 공개할 수 있으며, 기준은 누가 업데이트하는가. 여기가 공란인 채 '제3자 평가 완료'라고 적으면 나중에 설명하기 어려워집니다.
Amodei 씨의 제안이 보여주는 긴장—능력의 성장과 안전 검증 시간—도 무시할 수 없습니다. Gomez 씨의 제안이 보여주는 긴장—기준 설정 권한과 시장 구조—역시 조달 및 아키텍처 이야기로서 무시할 수 없습니다. 양쪽을 모두 읽은 후, 자사 용도에 필요한 것이 '명함상의 평가'인지 '자사 위협 모델에 맞는 평가'인지를 구분하는 것이 기술자의 일입니다.
Gomez 씨의 마무리는 규칙은 어느 쪽이든 쓰여진다는 정리입니다. 개방된 증거 기반 프로세스이든, 폐쇄적인 소수 기업의 방 안이든 말입니다. Amodei 씨 측은 검증 가능한 속도 조정 없이는 안전이 상업 경쟁에 패배한다는 정리입니다.
현장에서 가져갈 수 있는 것은 어느 CEO에게 찬성하는지에 대한 투표가 아닙니다. 리뷰의 아젠다에 '기준 출처', '스코프(Scope)', '이해 상충', '전환 가능성' 네 가지 항목을 추가할 수 있느냐입니다. 이것만으로도 안전에 대한 논의가 조달 체크리스트에 포함되고, 팀원들 사이에서 같은 용어로 이야기할 수 있게 됩니다.
작성일: 2026-09-24
