「찾아줘」는 거절되고 「고쳐줘」는 통과되었다 — AI 안전장치를 「모델 내부」에만 두는 것의 한계

최근 생각할 거리를 던져주는 보고가 있었다. 어떤 프론티어 (Frontier) AI 모델에 「이 코드의 보안 문제를 찾아줘」라고 부탁하면 거절되지만, 「이 코드를 고쳐줘」라고 말을 바꾸면 순순히 응한다는 것이다. 이를 보도한 연구자는 「이것은 탈옥 (Jailbreak)이 아니다」라고 명확히 밝혔다. 정교한 공격이 아니라, 그저 말의 표현을 바꾼 것뿐이었다고 말이다.

거의 같은 시기에 또 다른 사건도 있었다. 미국 정부가 여러 프론티어 모델을 수출 관리 대상으로 지정하면서, 제공업체가 이를 모든 사용자에 대해 일시적으로 중단했다. 대통령령은 특정 한 회사가 아니라 여러 벤더 (Vendor)를 지목하고 있다. 능력이 너무 높아서 중단된 것이 아니다. 제도의 사정으로 인해 단기간 내에 사용할 수 없게 된 것이다.

별개의 뉴스처럼 보인다. 하지만 나에게는 하나의 동일한 질문으로 보였다.

AI의 「안전하게 사용할 수 있음」과 「내일도 사용할 수 있음」을, 클라우드 상의 단일한 거대 모델 그 자체에 맡겨도 괜찮은 것인가?

특정 벤더를 비난하려는 이야기가 아니다 (어느 벤더든 당사자가 될 수 있으며, 실제로 여러 곳이 지목되었다). 모델의 우열이 아니라, 어디에 무엇을 맡길 것인가라는 설계의 문제다.

안전장치가 「얕다」는 것은 무엇을 의미하는가

말투 하나로 동작이 변하는 이유는 무엇일까.

학술적으로는 모델의 안전 정렬 (Safety Alignment)이 「얕은 (Shallow)」 경향이 있다는 지적 계보가 있다. 거칠게 말하자면, 안전한 행동이 응답의 초기 몇 토큰 정도에 강하게 깃들어 있어, 입력의 문맥이 바뀌면 무너지기 쉽다는 것이다. 미세 조정 (Fine-tuning)만으로도 안전성이 저하된다는 연구도 있다.

이 부분에서는 솔직하게 선을 긋고 싶다. 이러한 연구의 대부분은 「미세 조정에 의한 저하」 기제이며, 이번 「실행 시의 말 바꾸기로 통과한」 사례와는 엄밀히 말해 별개의 것이다. 「논문이 이 사건을 증명했다」라고 말할 수는 없다. 공통적으로 말할 수 있는 것은, 모델 내부의 안전 제어는 구조적으로 얕고·취약해지기 쉽다는 점까지다. 하지만 그 「~까지만 말할 수 있다」는 부분이 본질을 꿰뚫고 있다고 생각한다.

안전장치는 「의도」가 아니라 「말투」에 반응하고 있다

AI의 안전장치는 대략 말하자면 「이런 말투가 오면 거절한다」라는 반응을 훈련 시에 대량의 사례를 통해 학습시킨 것이다. 즉, 요청의 의도를 이해해서 거절하는 것이 아니라, 요청의 형태 (말투) 에 반응하고 있다. 그렇기에 「찾아줘」라는 형태에는 반응해도, 같은 목적을 다른 형태 (「고쳐줘」)로 말하면 반응이 나오지 않는다.

그리고 이 메커니즘은 원리적으로 「누가・무엇을 위해」를 알지 못한다. 모델이 보고 있는 것은 눈앞의 텍스트뿐이며, 그것을 쓴 것이 본인인지 제삼자인지, 유지보수를 위한 것인지 공격을 위한 것인지는 텍스트 외부에 있는 정보다. 똑같은 「이 코드를 고쳐줘」라도 주체와 문맥에 따라 의미는 반전된다.

게다가 AI 능력의 상당수는 이중 용도 (Dual-use)다. 취약점을 찾아내는 힘은 공격에도 방어에도 쓰일 수 있다. 그렇다면 「허용/다른 경로로 돌림/보류」의 선긋기는 모델이 얼마나 똑똑한가가 아니라, 누가・어떤 문맥에서 사용하고 있는가에 따라 결정된다. 그것은 기성 모델 단독으로는 답할 수 없는 질문이다.

또 다른 취약성: 그 모델은 내일도 사용할 수 있는가

안전 이야기뿐만이 아니다. 서두의 또 다른 뉴스——규제로 인해 하룻밤 사이에 중단되었다——는 또 다른 취약성을 보여준다. 바로 가용성 (Availability) 이다.

클라우드 상의 단일한 거대 모델은 능력과 무관한 이유로 갑자기 사용할 수 없게 될 수 있다. 벤더의 방침 변경, 제휴사의 사정, 규제 당국의 판단. 업무의 근간을 그 한 점에 맡기고 있으면, 그날 업무가 멈춘다.

「내부의 안전 제어가 말 바꾸기에 흔들리는 것」과 「모델 자체가 제도로 인해 사라질 수 있는 것」. 방향은 다르지만 뿌리는 같다. 단일 모델 그 자체에 안전도 지속성도 통째로 의존하고 있다는 구도다.

그렇다면 방어벽을 어디에 둘 것인가 — 「모델의 바깥쪽」

답의 방향은 보인다. 방어를 모델 내부 (학습시킨 반응)에만 의존하는 것을 그만두고, 모델의 바깥쪽——문맥과 정책 (Policy)의 계층에 둔다.

생각은 단순하다. 입력을 보고, 누가・무엇을・어느 정도의 기밀도로 다루려 하는지를 평가하여, 미리 정해둔 규칙에 따라 처리 장소를 분류한다. 기밀성이 높은 것은 로컬 (Local)에서 완결시키고, 그렇지 않은 것은 클라우드의 최신 모델에 맡긴다. 「막는 것」이 아니라 「경로를 나누는 것」이다.

여기서 역할을 나누어 두는 것이 핵심이다.

평가하는 것은, 로컬 AI (문맥이나 기밀도에 대한 판단) -
판정하는 것은, 인간이 정의한 정책 (규칙) -
무거운 최종적인
판단은, 인간

의도나 문맥의 판단을 모델 내부에 가두지 않는다. 이는 새로운 발상이 아니라, 보안에서 말하는 다층 방어 (defense-in-depth) 를 AI의 입구·출구·거동·기록에 적용하는 것일 뿐이다. NIST의 AI 리스크 관리 프레임워크 (Govern/Map/Measure/Manage) 와도 방향성이 같다고 생각한다.

가용성 (Availability) 의 취약성에도 동일한 "외부" 관점이 효과적이다. 특정 한 기업이나 한 모델에 얽매이지 않고, 여러 선택지를 가지며, 기밀성이 높은 핵심 업무는 로컬에서 완결될 수 있도록 해둔다. 그렇게 하면 클라우드 측이 중단되더라도, 적어도 그 부분은 계속 작동한다.

결국은 "우리가 어떻게 사용할 것인가"를 결정하는 것

지금까지의 이야기는 파고들면 기술의 문제가 아니다.

최강의 모델이 무엇인지는 몇 달 만에 바뀐다. 규제나 방침에 의해 하룻밤 사이에 사용할 수 없게 될 수도 있다. 내부의 안전장치는 말 한마디에 흔들릴 수 있다. 이러한 것들에 휘둘리지 않기 위해 정말로 필요한 것은, 훨씬 앞선 질문이다——우리는 AI를 어떻게 사용하고 싶은가. 어떤 정보에 대해 어느 정도의 리스크를 허용할 것인가.

그것을 의식하며 결정하고, 규칙 (Policy) 으로써 명문화한다. 무엇을 로컬에 두고, 무엇을 클라우드로 내보내며, 무엇은 인간이 반드시 확인할 것인가. 그 경계 설정이야말로 모델의 지능이나 가용성에 좌우되지 않는, 우리만의 "축"이 된다.

역으로 말하면, 가장 큰 리스크는 모델의 취약성 그 자체가 아니다. 벤더로부터 주어진 것을 아무것도 결정하지 않은 채, 막연하게 그대로 사용하는 것이다. 편리하다는 이유로 업무의 미묘한 부분까지 맡겨버리고, 중단되면 곤란해지며, 말 한마디에 예상치 못한 거동을 하는——그러한 상태에 "우리의 의도"가 단 하나도 들어있지 않은 것이 가장 위험하다.

방어와 지속성 모두, 결국은 "어떤 모델을 사용할 것인가"가 아니라 "우리가 어떻게 사용하기로 결정했는가"에 달려 있다. 그것을 두는 장소가 모델의 외부——문맥과 정책 (Policy) 의 계층이다. 업무에서 AI를 사용한다면, 이곳을 자신의 손으로 설계하는 것이 앞으로의 핵심이라고 생각한다.

(※ 본 기사는 기술과 운용에 관한 일반론입니다. 필자는 동일한 문제의식을 바탕으로, 기밀 분류를 로컬에서 수행하는 툴 제작에 참여하고 있습니다.)

Discussion