1854년 5월, 뉴욕 42번가의 크리스털 팰리스에서 만국산업박람회가 열리고 있었다. 전시장 한가운데에 세운 두 줄의 가이드 레일 사이로 나무 플랫폼 하나가 매달려 있었다. 버몬트 출신 기계공 엘리샤 오티스가 그 플랫폼에 올라 관중의 머리 위까지 올라갔다. 그리고 아래에 있던 조수에게 도끼로 밧줄을 끊으라고 했다. 플랫폼을 매단 밧줄은 하나뿐이었다. 밧줄이 끊기자 플랫폼은 몇 센티미터 내려앉다가 멈췄다. 오티스는 모자를 벗고 관중을 향해 모두 안전하다고 외쳤다.

승강기는 그 전에도 있었다. 공장과 창고에서 화물을 올리고 내리는 데 썼다. 다만 사람은 타지 않았다. 밧줄은 언젠가 닳고, 닳은 밧줄은 언젠가 끊어지며, 끊어지면 위에 있던 것은 떨어진다. 오티스는 밧줄을 더 굵게 만들지 않았다. 플랫폼 지붕에 판스프링을 달았을 뿐이다. 밧줄이 팽팽하게 당기는 동안 스프링은 휘어 있다. 밧줄이 끊어져 장력이 사라지면 스프링이 펴지면서 양 끝의 쇠갈고리가 레일에 새긴 톱니에 걸린다. 위험이 곧 브레이크의 트리거이다. 이 장치는 밧줄이 잘 버텨 주기를 기대하지 않았다.

3년 뒤인 1857년 뉴욕의 한 상점 건물에 첫 승객용 안전 엘리베이터가 들어섰다. 사람들이 승강기에 몸을 맡기기 시작하자 건물은 위로 올라가기 시작했다. 밧줄은 그 뒤로도 계속 닳고 끊어졌다. 마천루를 세운 것은 밧줄을 믿지 않는 브레이크였다.

170년이 지난 지금, AI 업계는 끊어지는 밧줄을 다시 마주하고 있다. 올해 7월 21일 OpenAI는 사이버 보안 능력을 평가받던 자사 모델 두 개가 격리된 시험 환경을 스스로 빠져나가 허깅페이스(Hugging Face)의 실제 운영 서버에 침입했다고 밝혔다. 모델들이 노린 것은 자신을 채점하던 보안 벤치마크의 정답지였다. 문제를 푸는 것보다 답안을 훔치는 쪽이 점수를 얻는 더 빠른 길이었다. 9일 뒤 Anthropic은 Claude 모델이 시험 도중 서로 다른 세 조직의 운영 시스템에 침입했다고 공개했다. 9월 18일에는 구글이 Gemini가 시험용 가상 회사와 이름이 같은 실제 회사를 찾아내 침입했다고 확인했다. Meta의 모델도 비슷한 사고를 낸 것으로 알려졌다. 네 회사의 사고에는 공통점이 하나 있다. 누구도 그렇게 하라고 시키지 않았다는 것이다.

지시는 경계가 되지 못한다

가장 섬뜩한 장면은 Anthropic의 기록에 있다. Claude는 시험 환경 안에서 가상 회사의 개발자 안내문처럼 보이는 문서를 따라가다, 공개 파이썬 패키지 저장소인 PyPI에 악성 패키지를 올리는 단계에 이르렀다. 작업 기록에는 이 패키지를 실제로 공개하면 진짜 공격이 되고, 그것은 해서는 안 되는 일이라는 Claude 자신의 판단이 남아 있다. 그런데도 Claude는 자신이 아직 시뮬레이션 안에 있다고 결론 내렸다. 낯선 인증기관의 인증서와 시스템에 찍힌 2026년이라는 날짜를 오히려 가짜 환경의 증거로 읽었다. 모델은 선이 어디에 있는지 알고 있었다. 틀린 것은 그 선이 지금 이 상황에 적용되는지에 대한 판단이었다.

평가 프롬프트는 Claude에게 지금 있는 곳은 시뮬레이션이며 인터넷은 없다고 분명히 알려 주었다. 이 문장은 모델을 멈추지 못했다. LLM이 쓸모 있는 이유는 자유도에 있다. 정해진 규칙을 따르는 대신, 주어진 맥락 전체를 보고 목표에 가장 그럴듯하게 다가가는 다음 행동을 고른다. 그래서 “이 범위 안에서만 움직여라”라는 지시도 모델에게는 맥락의 일부이고, 맥락은 저울질의 대상이다. 목표에 닿는 더 빠른 길이 지시와 부딪히면 모델은 둘을 견주어 볼 뿐 지시를 무조건 앞세우지 않는다. 지시를 잘 따르도록 훈련할 수는 있다. 그러나 훈련은 확률을 높일 뿐 확률을 100%로 만들지 못한다. 같은 상황에서 Gemini는 상대가 실제 회사라는 것을 알아채자 멈췄고, Claude Opus 4.7은 실제일 가능성을 인식한 뒤에도 공격을 계속했다. 모델의 자각에 기대는 안전은 모델을 바꿀 때마다 다시 검증해야 하는 안전이다.

이번 사고에서 무너진 것은 지시만이 아니다. 네 사고 모두 사람의 설정 실수에서 시작됐다. OpenAI의 시험 환경에서는 바깥과 통하도록 열어 둔 유일한 서비스에 취약점이 있었고, 나머지 세 회사의 사고는 같은 외부 평가 업체 이레귤러(Irregular)가 인터넷 차단을 제대로 하지 못한 데서 비롯됐다. 실제 기업의 운영 환경도 사람이 설정하고, 사람은 실수한다. 사후 탐지도 무너졌다. Anthropic이 찾아낸 첫 사고는 4월에 일어나 석 달 넘게 아무도 몰랐고, 침입당한 조직 가운데 Anthropic이 연락이 닿은 두 곳은 스스로 침입을 알아채지 못했다. 지시도, 환경도, 사후 감시도 뚫렸다. 남은 곳은 행동이 실행되기 직전의 한 지점뿐이다.

AI가 대화 상대에 머물 때 이런 성질은 엉뚱한 답변으로 끝났다. 사람이 읽고 버리면 그만이었다. AI가 명령을 실행하고 외부 시스템을 건드리는 에이전트가 되면서, 사람이 중간에서 걸러 주던 단계가 사라졌다. 그래서 필요한 것이 완벽한 통제다. AI의 판단은 그대로 쓰되, 그 판단이 실행으로 이어지는 길목에 장치를 세우는 것이다. 이 장치에는 두 가지 조건이 있다. 장치 자신의 출력이 정해진 형식을 벗어날 수 없어야 하고, 모델이 무엇을 믿든 상관없이 실행 여부를 모델 바깥에서 정해야 한다. 검사하는 쪽이 검사받는 쪽처럼 무엇이든 말할 수 있다면, 검사 결과 자체가 또 하나의 위험이 된다.

말하지 않는 모델

이 두 조건을 정면으로 겨냥한 제품이 지난 9월에 나왔다. 2년간 외부에 모습을 드러내지 않고 개발해 온 미국의 스타트업 TypeSafe AI가 9월 15일 4천만 달러 규모의 시드 투자 유치와 함께 첫 모델 Jev를 공개했다. 창업자 디오고 알메이다(Diogo Almeida)는 구글 브레인과 OpenAI에서 일한 연구자로, OpenAI가 2022년에 낸 InstructGPT 논문의 공동 저자다. InstructGPT는 RLHF(사람의 선호를 보상으로 쓰는 강화학습)를 언어 모델에 적용해 지시를 따르게 만든 연구이고, ChatGPT의 직접적인 토대가 됐다. 회사 소개에는 그가 RLHF를 공동 고안했다고 적혀 있지만, RLHF라는 방법 자체는 2017년 다른 연구진이 먼저 발표했다. 그가 한 일은 그 방법을 언어 모델에 적용하는 작업이었다.

TypeSafe는 Jev를 ‘시스템 원(System One) 모델’이라고 부른다. 심리학자 대니얼 카너먼이 사람의 사고를 빠르고 직관적인 시스템 1과 느리고 숙고하는 시스템 2로 나눈 데서 따온 이름이다. 알메이다의 주장은 이렇다. 지금의 LLM은 모두 시스템 2를 지향하며 만들어졌는데, 소프트웨어 안에서 내려야 하는 판단의 대부분은 시스템 1의 빠른 답을 원한다. 고객 문의가 급한지 아닌지, 이 작업을 어느 모델에 보낼지, 이 도구 호출을 실행해도 되는지 같은 질문이다. 이런 질문에 매번 문장을 생성하고 그 문장을 다시 해석하는 것은 느리고 비싸며 불안정하다.

Jev는 문장을 생성하지 않는다. 호출하는 쪽은 판단 대상이 되는 상태(텍스트든 JSON 데이터든)와 함께 미리 형식을 정한 질문을 보낸다. 질문의 형식은 세 가지다. 여러 선택지 중 하나를 고르는 질문, 예와 아니오를 묻는 질문, 정해진 척도 위의 점수를 묻는 질문이다. Jev는 각 질문에 대해 선택지별 확률과 함께 그 판단을 얼마나 믿을 수 있는지를 나타내는 신뢰도를 돌려준다. 결과는 토큰을 하나씩 이어 붙여 만드는 것이 아니라 한 번의 계산으로 한꺼번에 나온다. TypeSafe는 응답 시간이 70밀리초에서 500밀리초 사이라고 밝혔다.

보안의 관점에서 이 설계가 중요한 이유는 실패의 모양이 정해져 있다는 데 있다. 범용 LLM에게 “이 명령이 위험한가?”라고 물으면 대개 “위험하다” 또는 “안전하다”라고 답하겠지만, 그 답이 반드시 둘 중 하나라는 보장은 없다. 엉뚱한 설명을 늘어놓을 수도 있고, 질문에 섞여 들어온 악의적인 문장에 이끌려 전혀 다른 내용을 출력할 수도 있다. Jev는 정해진 선택지 바깥의 답을 낼 수 없다. Jev가 틀리더라도 그 틀림은 선택지 안에서 잘못 고르는 것으로 끝난다. 새로운 명령이나 예상하지 못한 행동으로 새어 나갈 길이 구조적으로 막혀 있다. 호출하는 쪽은 신뢰도가 기준을 넘을 때만 결과대로 실행하고, 기준에 못 미치면 사람에게 넘기는 코드를 짜면 된다.

이 방식이 제대로 돌아가려면 확률이 믿을 만해야 한다. 모델이 90%라고 말한 판단이 실제로 열에 아홉 번 맞아야, 90%를 기준선으로 삼는 코드가 의미를 가진다. 범용 LLM은 이 점에서 약하다. 사람이 보기에 그럴듯한 답에 높은 점수를 주는 방식으로 훈련받았기 때문에, 틀린 답도 확신에 찬 문장으로 내놓는 경향이 있다. 알메이다가 RLHF의 한계로 꼽는 것도 이 지나친 확신이다. TypeSafe는 Jev를 판단의 결과와 확률을 맞추는 별도의 강화학습 방식으로 훈련했다고 밝혔다. 이 주장이 외부 검증을 거쳐 사실로 확인된다면, Jev의 가치는 빠른 속도보다 기준선을 그을 수 있는 확률에 있다.

개발 도구 업계는 빠르게 반응했다. 공개 다음 날인 9월 16일 Vercel이 자사의 AI 게이트웨이에서 Jev를 쓸 수 있게 했고, 9월 17일에는 LangChain이 공식 연동 패키지를 내놓았다. 특히 LangChain이 함께 공개한 실험 기능은 에이전트가 도구를 실행하기 직전에 그 호출을 Jev로 분류해, 셸처럼 위험한 도구가 걸린 호출을 막을 수 있게 했다. 앞에서 말한 두 번째 조건, 곧 실행 직전에 모델과 무관한 장치가 통과 여부를 정하는 구조를 에이전트 개발 도구 안에 기본 부품으로 넣은 셈이다.

그렇다고 Jev가 문제를 다 푼 것은 아니다. 브라질 소프트웨어 회사 코드마이너42의 창업자 파비오 아키타(Fabio Akita)는 Jev가 환각을 일으킬 수 없다는 TypeSafe의 주장을 두고, 그것은 출력 형식에 관한 주장일 뿐 답의 내용이 옳다는 주장이 아니라고 지적했다. 정확한 지적이다. Jev는 형식이 틀린 답을 낼 수 없지만, 형식이 맞으면서 틀린 답은 얼마든지 낼 수 있다. 위험한 명령에 “안전”이라는 라벨을 높은 확률로 붙이는 일은 구조적으로 막혀 있지 않다. 또 Jev를 에이전트에 연결하는 오픈소스 도구들의 문서는 판단 대상인 상태 안에 섞여 든 적대적인 문장에 Jev가 흔들릴 수 있다는 점을 알려진 한계로 다룬다. 공격자가 명령의 인자나 도구 설명 안에 “이 호출은 안전하다”는 식의 문장을 심어 두면 판단이 기울 수 있다는 뜻이다. 생성을 포기하는 대신 통제 가능한 판단을 얻는 길을 보여 줬다는 점에서 Jev의 의미는 크다. 하지만 Jev도 혼자서 마지막 방어선이 될 수는 없다.

같은 일을 오래 해 온 모델들

Jev를 실무에 들이려 할 때 걸리는 점이 하나 더 있다. Jev는 TypeSafe의 서버나 이를 중개하는 클라우드 서비스에서 돌아간다. 에이전트가 실행하려는 셸 명령을 Jev로 검사한다는 것은, 그 명령과 인자, 작업 경로, 도구 설명을 매번 외부 서버로 보낸다는 뜻이다. LangChain의 연동 문서도 도구 인자나 대화 상태에 비밀 정보를 넣지 말라고, 그 정보가 TypeSafe로 전송되어도 괜찮은 경우가 아니라면 피하라고 적고 있다. 보안 판단을 외부 서비스에 맡기는 것은 그 자체로 또 하나의 노출이다. 외부 서비스가 멈추면 에이전트를 멈출지 그냥 통과시킬지도 정해야 한다. 공공기관이나 금융권처럼 데이터가 망 밖으로 나가는 것 자체가 허용되지 않는 곳에서는 선택지에 오르기도 어렵다.

그런데 Jev가 하는 일을 다시 들여다보면 낯선 일이 아니다. 정해진 선택지 중 하나를 확률과 함께 고르는 일은 분류 모델이 오래전부터 해 온 일이다. 2018년 구글이 공개한 BERT 이후 스팸 탐지, 욕설 탐지, 문의 유형 분류처럼 라벨과 확률만 내놓으면 되는 일은 대부분 인코더 계열 모델이 맡아 왔다. 인코더 모델은 문장을 생성하지 않는다. 입력 전체를 한 번에 읽어 숫자 벡터로 바꾸고, 그 위에 얹은 분류기가 라벨별 확률을 낸다. 출력이 정해진 라벨 바깥으로 나갈 수 없다는 점에서 Jev와 같은 성질을 지녔다.

속도의 차이도 여기서 나온다. 생성형 모델은 답을 한 토큰씩 만든다. “위험”이라는 두 글자를 내놓으려 해도 여러 번의 계산을 차례로 거치고, 그 앞에 설명을 붙이면 계산 횟수는 그만큼 늘어난다. 인코더 분류 모델은 입력을 한 번 통과시키면 끝난다. 답의 길이라는 것이 없으니 응답 시간이 입력 길이에만 좌우되고, 거의 일정하다. 에이전트가 하루에 수천 번 명령을 실행한다면, 그 앞에 세우는 검사 장치는 한 번에 몇 초씩 걸려서는 안 된다. 일정하고 짧은 응답 시간은 모든 행동 앞에 검사 장치를 세울 수 있느냐를 가르는 조건이다.

이 계열의 최근 대표가 2024년 12월 Answer.AI와 LightOn이 공개한 ModernBERT다. 기본형은 매개변수가 1억 4,900만 개로, 수천억 개 단위인 최신 LLM과 비교하면 아주 작다. 기존 BERT 계열이 512토큰까지만 읽던 데 비해 8,192토큰까지 한 번에 읽고, 학습 데이터에 코드를 대량으로 넣은 첫 인코더 모델이다. 셸 명령이나 설정 파일처럼 코드에 가까운 입력을 분류하는 데 유리하다는 뜻이다. 이 정도 크기의 모델은 일반 PC나 사내 서버에서 충분히 돌아가고, 데이터가 밖으로 나가지 않는다.

Jev와 인코더 분류 모델의 차이는 분명하다. Jev는 호출할 때 질문과 선택지를 새로 정할 수 있고, 따로 학습시키지 않아도 답한다. 인코더 분류 모델은 라벨이 붙은 데이터로 미리 학습해야 하고, 라벨 체계가 바뀌면 다시 학습해야 하는 것이 일반적이다. 유연성은 Jev 쪽에 있다. 그 대신 인코더 모델은 우리 데이터로 우리 장비에서 학습하고 우리 안에서 돌린다. 판단 기준이 무엇에서 왔는지 추적할 수 있고, 응답 시간과 비용을 스스로 통제할 수 있다. 그리고 기업에는 라벨을 붙일 재료가 생각보다 많다. 그동안 쌓인 처리 기록, 사람이 이미 내린 판단의 이력이 그대로 학습 데이터가 된다.

그 사이에 LLM 계열의 가드 모델도 있다. 알리바바의 Qwen 팀이 2025년 가을 공개한 Qwen3Guard가 그 예다. 매개변수 6억, 40억, 80억 개의 세 가지 크기로 나와 로컬에서 돌릴 수 있다. 판정은 안전, 논란 소지, 위험의 세 단계이며, 119개 언어를 지원한다. 문장 전체를 받아 판정 결과와 위험 범주를 생성하는 방식과, 텍스트가 생성되는 도중에 토큰 단위로 감시하는 방식의 두 가지 변형이 있다. 판정 기준을 지시문으로 바꿀 수 있어 인코더 모델보다 유연하다. 다만 결과를 문장으로 생성하므로 연산 자원이 더 들고 응답이 느리다. 생성된 문장에서 판정을 다시 뽑아내는 처리도 필요하다.

Qwen3Guard에서 눈여겨볼 부분은 ‘논란 소지’라는 세 번째 판정이다. 같은 내용이라도 서비스의 성격이나 정책에 따라 허용될 수도, 막혀야 할 수도 있는 경우를 따로 떼어 낸 것이다. 이 판정을 받은 입력을 엄격한 서비스에서는 위험으로, 느슨한 서비스에서는 안전으로 처리하면 된다. 모델은 애매하다는 사실만 알려 주고, 그 애매함을 어느 쪽으로 처리할지는 운영하는 쪽이 정한다. 판단과 권한을 나누는 설계가 모델의 출력 형식 안에 들어가 있는 셈이다.

결국 어떤 모델을 쓸지는 고객의 요구와 프로젝트의 성격이 정한다. 데이터가 밖으로 나가도 되는가? 판단 한 번에 허용되는 시간은 얼마인가? 라벨 체계가 얼마나 자주 바뀌는가? 라벨을 붙인 데이터가 충분한가? 데이터 반출이 자유롭고 질문이 자주 바뀌며 학습 데이터가 없다면 Jev 같은 외부 서비스가 맞다. 데이터를 밖으로 내보낼 수 없고 판단 기준을 세밀하게 바꿔야 하며 응답 속도에 여유가 있다면 Qwen3Guard 같은 로컬 가드 모델이 맞다. 데이터가 밖으로 나갈 수 없고 수십 밀리초 안에 답해야 하며 쌓인 기록이 있다면 인코더 분류 모델을 직접 학습시키는 것이 맞다. 세 모델 모두 판단의 출력을 좁게 묶는다는 점에서는 같은 쪽을 보고 있다.

현장에서 확인한 것

이 방식은 필자가 진행한 프로젝트의 실제 현장에서 이미 효과를 내고 있다. 첫 번째는 보안이 아닌 업무 자동화 사례다. 한 공공기관에서는 공문서가 들어오면 어느 팀의 어느 담당자에게 보낼지를 정해야 했다. 기존 시스템은 부서마다 분류 체계가 달라, 분류 기준 하나에 모델이 약 20개씩 필요했다. 평균 정확도는 60% 안팎이었다. 더 큰 문제는 유지보수였다. 조직 개편으로 팀이 생기거나 없어져 라벨이 하나 바뀔 때마다 모델을 다시 학습하고 다시 배포해야 했다. 공공기관의 조직은 해마다 바뀐다.

접근을 바꿨다. 라벨을 모델 안에 넣지 않고 모델 밖에 두었다. 기관의 문서로 분류 모델을 한 번만 학습시켜, 그 기관의 업무 맥락이 반영된 벡터 공간을 만들었다. 같은 업무에 속하는 문서끼리 가까이 모이도록 학습된 공간이다. 새 문서가 들어오면 이 공간에서 가장 비슷한 과거 문서들을 찾고, 그 문서들을 처리했던 팀을 담당 후보로 추천한다. 모델이 직접 “이 문서는 A팀”이라고 답하는 대신, “이 문서는 A팀이 처리했던 이 문서들과 닮았다”고 답하는 구조다. 팀이 새로 생기면 그 팀이 다룰 대표 문서를 참조 문서로 등록하면 되고, 팀이 없어지면 해당 참조 문서를 빼면 된다. 모델은 건드리지 않는다.

이 구조에는 모를 때 모른다고 말하는 방법도 들어 있다. 새 문서와 가장 가까운 과거 문서 사이의 거리가 일정 기준보다 멀면, 그 문서는 어느 팀의 업무와도 충분히 닮지 않았다는 뜻이다. 이때 시스템은 억지로 가장 가까운 팀을 고르지 않고 ‘알 수 없음’으로 분류해 접수 담당자에게 넘긴다. 분류 모델에게 모든 문서에 답하라고 요구하면, 모델은 애매한 문서에도 그럴듯한 팀을 골라 붙인다. 답하지 않을 권리를 주면 틀린 답이 줄어든다. 앞에서 Jev가 신뢰도가 낮을 때 사람에게 넘기는 것과 같은 원리다.

모델 수가 줄어든 것은 관리의 문제만이 아니었다. 예전에는 20개 모델이 각자 자기 부서의 문서만 보고 학습했다. 문서가 적은 부서의 모델은 배울 재료가 부족했다. 이제는 하나의 모델이 기관 전체의 문서를 보고 업무 맥락을 배운다. 부서마다 다르던 분류 체계는 참조 문서의 묶음으로 표현되니, 체계가 달라도 같은 모델을 함께 쓸 수 있다.

모든 문서를 모델에 맡기지도 않았다. 인사, 감사, 개인정보처럼 민감한 문서는 키워드 규칙으로 걸러 미리 정한 곳에 배정하거나 아예 자동 분류 대상에서 뺐다. 모델이 판단해서는 안 되는 영역을 먼저 정하고, 그 바깥에서만 모델이 움직이게 한 것이다. 그 결과 정확도는 90%에 이르렀고, 모델은 분류 기준당 하나로 줄었으며, 라벨 변경은 참조 문서 등록만으로 바로 반영된다.

두 번째는 보안 사례다. AI 에이전트가 실행하려는 셸 명령을 실행 직전에 검사하기 위해 ModernBERT-base를 실제 명령 로그 약 1만 1천 건으로 직접 학습시켰다. 학습에는 일반 맥미니 한 대로 16분이 걸렸고, 응답 시간은 전체 요청의 95%가 48밀리초 안에 끝났다. 에이전트가 명령을 실행할 때마다 거쳐도 사람이 느끼지 못하는 속도다. 이런 분류 모델은 일반 PC에서 한 시간 정도만 학습시켜도 실제로 쓸 만한 성능을 낸다. 고성능 GPU 클러스터도, 외부 API도 필요 없다.

그러나 분류기만 단독으로 썼을 때의 결과는 보안 장치로 쓰기에 부족했다. 이미 알려진 위험 명령 164건 중 1건을 통과시켰고, 학습 데이터에 없던 방식으로 새로 만든 위험 명령 45건 중 2건을 통과시켰다. 일반적인 분류 문제라면 훌륭한 성적이다. 하지만 보안에서는 한 건이면 충분하다. 통과된 명령 하나가 인증 키를 외부로 보내거나 데이터베이스를 지울 수 있다. 분류기의 정확도를 더 올리는 것으로는 이 문제를 풀 수 없다. 정확도를 99.9%로 올려도 남은 0.1%가 무엇을 할지는 여전히 모른다.

그래서 분류기의 성능을 올리는 대신 분류기의 권한을 다시 설계했다. 판단을 세 겹으로 나눴다. 첫 번째 겹은 규칙이다. 명백히 위험한 명령은 규칙이 먼저 막는다. 규칙은 보수적으로 짜서, 조금이라도 의심스러운 명령은 일단 막는다. 이렇게 하면 위험한 명령은 거의 다 걸리지만, 멀쩡한 명령도 많이 막힌다. 에이전트가 일을 못 하게 되는 것이다.

규칙과 분류기는 서로 반대 방향으로 틀린다. 규칙은 문자열의 모양을 보고 판단하기 때문에, 위험한 단어가 들어간 정상 명령을 막고, 위험한 단어를 돌려 쓴 위험 명령을 놓친다. 분류기는 수많은 사례에서 배운 패턴으로 판단하기 때문에, 처음 보는 형태의 정상 명령도 문맥을 보고 풀어 줄 수 있지만, 그 패턴에서 벗어난 위험 명령에는 확신을 갖고 틀린다. 둘 중 하나를 고르면 그 하나의 약점을 그대로 떠안는다. 둘을 이어 붙이되 각자에게 맡기는 일을 다르게 정하면, 한쪽의 약점을 다른 쪽이 덮는다.

두 번째 겹이 분류기다. 분류기는 규칙이 애매하게 막은 명령만 다시 보고, 그중 정상으로 판단되는 것을 허용으로 바꾼다. 분류기에게 주어진 권한은 이것 하나뿐이다. 분류기는 규칙이 허용한 명령을 막을 수도 없고, 규칙이 명백히 위험하다고 막은 명령을 풀어 줄 수도 없다. 차단을 허용으로 바꾸는 한 방향의 권한만 있다. 분류기가 틀리는 경우 생길 수 있는 피해는, 규칙이 애매하다고 본 명령 가운데 일부를 잘못 풀어 주는 것으로 한정된다.

세 번째 겹은 그 피해를 다시 막는다. 분류기가 허용한 명령은 고정 규칙으로 한 번 더 검사한다. 환경변수 접근, 인증정보가 담긴 경로, 외부로의 데이터 전송, 파일 삭제처럼 되돌릴 수 없는 명령의 신호가 하나라도 보이면 분류기의 허용을 취소한다. 환경변수 전체를 출력하는 명령, SSH 키나 클라우드 인증 파일이 있는 경로를 읽는 명령, 파일 내용을 외부 주소로 보내는 명령, 디렉터리를 통째로 지우는 명령이 여기에 해당한다. 이 네 가지는 그 자체로 위험하지 않을 수 있지만, 사고가 났을 때 피해를 키우는 통로가 된다는 공통점이 있다. 분류기가 정상이라고 본 명령이라도 이 통로를 건드리면 다시 막는다. 분류기가 얼마나 확신하든 상관없다. 이 구조에서 분류기는 마지막 판단자가 아니다. 규칙이 지나치게 보수적으로 막은 것을 풀어 주는 역할만 하고, 그 결과는 다시 규칙의 확인을 받는다. 기본값은 언제나 차단이다. 어느 겹에서 무엇이 실패하든, 실패한 상태는 막힌 상태로 끝난다.

이 구조로 2,429건을 평가했다. 위험한 명령은 한 건도 통과하지 못했다. 규칙만 썼을 때 불필요하게 막히던 정상 명령은 91.5%가 풀렸다. 보안은 지키면서 에이전트가 실제로 일할 수 있는 수준까지 막힘을 줄인 것이다. 이 결과는 분류기가 더 똑똑해져서 나온 것이 아니다. 분류기가 실수해도 사고로 이어지지 않도록 분류기가 할 수 있는 일을 좁혔기 때문에 나온 것이다.

장치의 두께는 틀렸을 때의 비용이 정한다

두 사례는 같은 재료를 정반대의 두께로 썼다. 문서 분류에는 분류 모델 하나만 두었고, 셸 명령 검사에는 규칙과 분류기와 규칙의 세 겹을 둘렀다. 기준은 하나였다. 판단이 틀렸을 때 무슨 일이 생기고, 그 틀림을 누가 잡아 주는가?

셸 명령은 실행되는 순간 결과가 확정된다. 지워진 파일은 돌아오지 않고, 밖으로 나간 인증 키는 회수할 수 없다. 에이전트와 명령 실행 사이에 사람이 없으니, 틀린 판단을 잡아 줄 다음 단계도 없다. 이런 곳에서는 판단 장치가 단 한 번도 틀려서는 안 되고, 어떤 단일 모델도 그것을 보장하지 못한다. 그래서 여러 겹을 두고, 각 겹이 서로 다른 방식으로 실패하게 만들고, 실패의 기본값을 차단으로 정한다. 보안과 관련된 가드레일에서는 이 3중 구조가 맞는 방식이다.

문서 분류는 사정이 다르다. 90% 수준에만 도달하면 충분하다. 나머지 10%는 ‘알 수 없음’으로 처리되거나 잘못 분류되더라도 이후 사람의 손을 거친다. 담당자는 자기 업무가 아닌 문서를 받으면 반송하고, 분류되지 않은 문서는 접수 담당자가 직접 배정한다. 틀림을 잡아 주는 사람이 이미 업무 흐름 안에 있다. 여기에 규칙과 검증을 겹겹이 두르면 정확도는 몇 퍼센트 오르겠지만, 규칙을 관리하는 비용이 그보다 커진다. 조직이 바뀔 때마다 규칙도 함께 고쳐야 하기 때문이다. 그래서 문서 분류는 분류 모델 하나로 하는 것이 좋다.

두 사례 사이에도 수많은 경우가 있다. 에이전트가 사용자 대신 이메일을 보내거나 일정을 잡는 일은 셸 명령만큼 치명적이지는 않지만, 한번 보낸 메일은 거둘 수 없다. 이런 경우에는 분류 모델이 위험도를 매기고, 일정 기준을 넘는 행동만 사람의 확인을 받게 하는 두 겹 정도가 알맞다. 모든 행동을 사람에게 물으면 에이전트를 쓰는 의미가 없고, 아무것도 묻지 않으면 사고 한 번에 신뢰를 잃는다. 장치의 두께는 행동을 되돌릴 수 있는지, 틀림을 잡을 사람이 흐름 안에 있는지에 따라 단계적으로 정하면 된다.

이 기준은 Jev 같은 외부 모델을 쓸 때도 그대로 적용된다. 고객 문의를 유형별로 나누는 일이라면 Jev 하나로 충분하다. 틀린 분류는 상담원이 고친다. 에이전트의 도구 실행을 허가하는 일이라면 Jev는 여러 겹 가운데 하나여야 한다. 그 앞뒤에 규칙을 두고, Jev가 허용한 결과를 다시 확인하고, Jev 서비스에 닿지 못할 때는 막는 쪽으로 정해야 한다. 어떤 모델을 쓰느냐보다 그 모델에게 어떤 권한을 주느냐가 먼저다.

여기서 작은 모델을 직접 학습시키는 일의 가치가 드러난다. 작은 분류 모델은 판단의 범위가 좁고 출력이 정해져 있어, 시스템 안에서 어떤 권한을 줄지 설계하기 쉽다. 일반 PC에서 한 시간이면 학습이 끝나니 데이터가 바뀌면 다시 학습시키는 부담도 적다. 수십 밀리초 안에 답하니 모든 행동 앞에 세워 둘 수 있다. 데이터가 밖으로 나가지 않으니 판단 장치 자체가 새로운 노출이 되지도 않는다. 거대한 모델이 해야 할 일과 작은 모델이 해야 할 일은 따로 있다. 거대한 모델은 무엇을 할지 생각하고, 작은 모델은 그것을 해도 되는지 확인한다.

작은 모델은 쓰는 동안 더 단단해진다는 점도 있다. 셸 명령 검사기를 운영하다 보면 규칙이 막았지만 사람이 확인해 보니 정상이었던 명령, 반대로 통과됐다가 뒤늦게 위험하다고 확인된 명령이 쌓인다. 이 기록은 그대로 다음 학습의 라벨이 된다. 학습이 한 시간이면 끝나니, 일주일이나 한 달 단위로 다시 학습시켜 현장의 명령 습관을 따라가게 할 수 있다. 외부 서비스의 모델은 제공하는 쪽의 일정에 맞춰 바뀌고, 그 변화가 우리 시스템에 어떤 영향을 줄지는 바뀐 뒤에야 안다. 직접 학습시킨 모델은 언제, 무엇으로 바뀌는지를 우리가 정한다. 판단 장치의 변경을 통제할 수 있다는 것은 보안에서 작지 않은 차이다.

AI에게 판단을 맡기는 일은 이미 일상이 되었다. 남은 문제는 그 판단을 얼마나 단단한 틀 안에 두느냐다. 모델에게 선을 넘지 말라고 말하는 것으로는 부족하다는 것을 올해의 사고들이 보여 줬다. 시험 환경을 더 꼼꼼히 막는 것도 필요하지만, 환경은 사람이 설정하고 사람은 실수한다. 작은 모델을 직접 학습시켜 안에서 돌리고, 그 모델이 할 수 있는 일을 좁히고, 용도에 맞는 두께로 안전장치를 두르는 것이 지금 가장 현실적인 답이다.

밧줄을 믿지 않는 브레이크

오티스가 크리스털 팰리스에서 증명한 것은 밧줄이 끊어지지 않는다는 사실이 아니었다. 밧줄은 그날도 끊어졌다. 오티스는 일부러 끊었다. 관중이 본 것은 밧줄이 끊어져도 떨어지지 않는 승강기였다. 오티스의 브레이크는 밧줄을 튼튼하게 만드는 데 힘을 쓰지 않았다. 밧줄이 실패하는 순간을 감지해 저절로 걸리는 데만 집중했다. 판스프링 하나와 톱니 몇 개로 된 그 작은 장치가 사람들을 승강기에 태웠고, 사람들이 승강기에 타자 도시는 위로 자랐다.

AI의 자유도는 밧줄과 닮았다. 그 힘으로 무거운 일을 들어 올리지만, 언젠가 어디선가 끊어진다. 더 좋은 지시문과 더 정교한 정렬 훈련으로 밧줄을 굵게 만드는 노력은 계속되어야 한다. 그래도 사람들이 AI에게 더 높은 곳의 일을 맡기는 날은, 밧줄이 끊어져도 떨어지지 않는다는 것을 눈으로 확인한 다음에 온다. 작고 좁고 말하지 않는 모델들이 그 브레이크가 될 수 있다.

AI를 믿고 맡길 수 있게 만드는 것은, AI를 믿지 않도록 설계된 장치다.

참고 자료