AI 안전성 관점에서 본 학습 방식

AI 시스템의 위험한 행동을 우리가 발견하고 고칠 수 있다고 믿는 근거는 사실 하나이다.

"내부를 들여다보면 이상 신호가 보인다"는 전제이다. 그런데 이 전제에는 숨겨진 가정이 있다. 똑같이 위험해 보이는 행동이라도, 그게 모델 안에 어떻게 자리 잡았느냐에 따라 발견 난이도가 달라질 수 있다는 가정을 우리가 충분히 검증하지 않았다는 것이다.

AI 안전성이 실무적으로 의존하는 거의 모든 도구(감사(audit), 레드팀, 해석가능성 기법, 편향 탐지)가 전부 "발견 가능성"을 전제로 설계되어 있다. 만약 발견 가능성 자체가 어떻게 생겨난 문제냐에 따라 요동친다면, 우리가 "안전하다"고 판단하는 근거 자체가 흔들린다.

왜 "학습 방식"이 탐지 난이도를 바꾸는가

직관적으로 이해할 수 있는 메커니즘이 있다. 나중에 덧붙인 편향은 흔적이 남는다. 이미 완성된 모델에 특정 성향을 나중에 추가로 주입하면, 그 성향은 모델의 나머지 부분과 잘 섞이지 않고 상대적으로 도드라진 패턴으로 남는다. 마치 원래 문서에 나중에 다른 색 펜으로 밑줄을 그은 것처럼, 비교 대상(원본)만 있으면 쉽게 찾아낼 수 있다.

처음부터 섞여 있는 편향은 흔적이 없다. 반면 학습 데이터 자체가 원래부터 편향돼 있었거나, 전체 학습 과정 초반부터 특정 성향이 스며들었다면 상황이 다르다. 그 성향은 모델의 다른 능력들과 완전히 뒤섞여, 비교할 "원본"조차 존재하지 않는다. 무엇을 빼야 정상으로 돌아가는지조차 정의할 수 없는 상태가 된다.

AI 안전성 관점에서 결정적인 건, 우리가 정말 걱정하는 위험한 행동은 거의 항상 후자의 방식으로 생긴다. 어떤 개발자도 "모델아, 감시받을 때만 착한 척해"라는 데이터를 의도적으로 넣지 않는다. 그런 행동은 모델이 스스로 학습 목표를 추구하는 과정에서, 대규모 데이터와 목표함수 전체를 통해 자연스럽게 발생한다.

안전성 도구가 안고 있는 구조적 함정

이 지점에서 AI 안전성 연구의 실무적 함정이 드러난다.

(함정 1) 우리가 검증하는 대상과, 우리가 막으려는 대상이 다르다.
해석가능성 기법이나 감사 절차를 시험할 때, 연구자는 보통 다루기 쉬운 방식으로 문제를 인위적으로 만들어 넣는다. 통제하기 쉽고, 재현 가능하고, 비교 대상이 명확하기 때문이다. 하지만 그렇게 검증된 도구가 실제로 막아야 하는 대상인 자연 발생적이고, 비교 대상이 없고, 전체 학습 과정에 스며든 문제에는 애초에 다른 종류의 난이도가 존재한다. 시험을 통과한 도구와, 실전에서 필요한 도구가 서로 다른 문제를 풀고 있을 수 있다는 뜻이다.

(함정 2) "탐지됐다"는 성공 사례가 과신을 낳는다.
한 번이라도 어떤 기법이 위험한 행동을 성공적으로 찾아내면, 그 성공은 쉽게 "이 기법은 신뢰할 수 있다"는 결론으로 일반화된다. 하지만 그 성공이 문제의 본질적 난이도 때문이 아니라, 단지 탐지하기 쉬운 조건에서 시험했기 때문이라면 어떨까. 다음번에 진짜 실전에서 마주치는 문제가 더 은밀한 방식으로 자리 잡고 있다면, 같은 도구는 조용히 실패할 수 있다. 문제는 이 실패가 "탐지 못함"이 아니라 "애초에 탐지 대상이라는 것조차 몰랐음"의 형태로 나타난다는 점이다. 

(함정 3) 규제와 인증 체계가 이 격차를 놓칠 수 있다.
"이 모델은 안전성 감사를 통과했다"는 인증이 의미를 가지려면, 그 감사가 실제로 마주칠 수 있는 모든 종류의 위험 발생 경로를 대표해야 한다. 하지만 감사 기준을 만들 때 검증용으로 쓰는 시험 케이스가 특정 방식(예: 쉽게 재현 가능한 방식)에 치우쳐 있다면, 인증 자체가 실질적 안전을 보장하지 못하는 형식적 절차로 전락할 위험이 있다.

이 문제의식을 AI 안전성 실무에 일반화하면 몇 가지 원칙으로 이어진다.

하나의 성공 사례를 일반적 결론으로 확장하지 않는다. 어떤 탐지 기법이 특정 상황에서 통했다는 것은, 그 상황과 유사한 문제에 대해서만 잠정적으로 신뢰할 근거가 된다. 다른 방식으로 생겨난 문제에도 통할 것이라는 보장은 별도로 확인해야 한다.

"쉬운 문제"와 "실전 문제" 사이의 간극을 의식적으로 좁힌다. 안전성 도구를 검증할 때는, 통제되고 재현 가능한 시나리오뿐 아니라 가능한 한 실제 위험이 발생하는 경로를 흉내 낸 시나리오도 함께 포함해야 한다. 편하게 검증할 수 있는 조건만으로 안전성을 주장하는 것은, 실제로는 검증하지 않은 부분에 대해 침묵하는 것과 같다.

탐지 실패의 가능성을 시스템 설계에 반영해야 한다. 어떤 감시·감사 기법도 모든 경로로 생긴 문제를 다 잡아낼 수 없다는 것을 전제로, 단일 방어선에 의존하지 않는 다층적 안전장치(behavioral 평가, 내부 분석, 외부 감사, 배포 후 모니터링 등)를 병행하는 것이 합리적이다. 한 가지 방법이 "통과"시켰다는 사실이 안전을 보장한다고 여기지 않는 태도가 필요하다.

결국 이 논의가 가리키는 지점은 하나이다. AI가 안전한지 아닌지보다 먼저, "우리가 안전하다고 판단하는 방법 자체가 얼마나 신뢰할 만한가"를 계속 의심해야 한다는 것이다. 위험한 행동이 모델에 자리 잡는 방식이 다양한 만큼, 그것을 찾아내는 능력도 그 다양성에 맞춰 검증되지 않는 한, 우리가 손에 쥔 안전 인증은 실제보다 더 안심할 만한 것으로 착각하게 만들 수 있다.