[Deep Dive] 파인튜닝 없이 LLM의 검열을 해제하다: Heretic 아키텍처 해부
[Deep Dive] 파인튜닝 없이 LLM의 검열을 해제하다: Heretic 아키텍처 해부
1. 시작하며: “저는 도울 수 없습니다”라는 앵무새에 지친 우리들
여러분, 현업에서 오픈소스 대형 언어 모델(LLM)을 프로덕션에 올려본 분들이라면 다들 한 번쯤 모니터 앞에서 깊은 한숨을 쉬어본 적 있으실 겁니다. 최근 Llama 3나 Gemma 3 같은 훌륭한 오픈 가중치(Open-weights) 모델들이 쏟아지고 있지만, 막상 이 녀석들을 실무에 도입하려고 하면 치명적인 벽에 부딪힙니다. 바로 기업들의 과도한 ‘안전성 필터(Safety Alignment)’ 때문이죠.
사내 사이버 보안 테스트를 위해 취약점 점검 스크립트를 작성해 달라고 하거나, 필터링 기준이 모호한 타겟의 창작 데이터를 생성하려고 하면, 이 모델들은 약속이나 한 듯 “저는 AI로서 윤리적 가이드라인에 의해 해당 요청을 수행할 수 없습니다”라며 앵무새처럼 답변을 거부해 버립니다. 아니, 난 지금 사내 폐쇄망에서 합법적인 보안 테스트 용도로 쓰려는 건데 말이죠!
해결책요? 물론 파인튜닝(Fine-tuning)을 하면 됩니다. 하지만 DPO나 ORPO 같은 얼라인먼트 해제 튜닝을 제대로 하려면 막대한 양의 고품질 ‘Uncensored’ 데이터셋과 비싼 A100 GPU 클러스터, 그리고 엔지니어의 피 같은 시간이 갈려 들어갑니다. “아니, 그냥 특정 대답만 안 하게 막아둔 스위치 같은 걸 똑딱 하고 끊어버릴 순 없을까?” 이런 발칙한 상상, 다들 한 번쯤 해보셨을 겁니다.
그런데, 최근 GitHub 트렌딩을 휩쓸며 등장한 Heretic은 바로 그 상상을 현실로 만들어버린 괴물 같은 툴입니다. 오늘은 산전수전 다 겪은 10년 차 개발자의 시선에서, 이 툴이 어떻게 ‘파인튜닝 없이’ 모델의 뇌 구조를 물리적으로 개조해버리는지, 그 내부 아키텍처의 민낯을 낱낱이 파헤쳐보겠습니다.
2. TL;DR: 본질만 말하자면
TL;DR: Heretic은 값비싼 파인튜닝 과정 없이, 트랜스포머 가중치의 방향성 절제(Directional Ablation)와 옵튜나(Optuna) 기반의 TPE 최적화를 통해 오픈소스 LLM의 거부(Refusal) 메커니즘을 완전 자동으로 제거하는 툴입니다. 모델의 원래 지능은 훼손하지 않으면서 검열 스위치만 핀셋으로 도려냅니다.
3. Deep Dive: Under the Hood (핵심 아키텍처 분석)
본격적으로 뚜껑을 열어볼까요? 이 섹션에서는 표면적인 기능 나열은 접어두고, 내부 아키텍처와 수학적 접근법을 깊게 들여다보겠습니다. 대체 가중치를 어떻게 건드리기에 파인튜닝 없이 이게 가능한 걸까요?
얼라인먼트는 결국 ‘벡터의 방향’일 뿐이다
Heretic의 작동 원리를 제대로 이해하려면 2024년 Arditi 등의 연구에서 비롯된 ‘어블리터레이션(Abliteration, 방향성 절제)’ 개념을 짚고 넘어가야 합니다. 우리가 텍스트를 입력하면 트랜스포머의 각 레이어에서 수많은 활성화(Activation)가 발생하는데요. 연구자들은 LLM의 잠재 공간(Latent Space) 내에 “이 요청은 유해하므로 거부해야 한다”라는 의도를 담은 특정한 ‘거부 방향(Refusal Direction)’ 벡터가 존재한다는 사실을 발견했습니다.
Heretic은 이 점을 정확히 파고듭니다. 모델에 유해한(Harmful) 프롬프트와 무해한(Harmless) 프롬프트를 각각 먹인 뒤, 첫 번째 토큰의 잔차 흐름(Residual stream)에서 발생하는 평균의 차이(Difference-of-means)를 계산합니다. 이렇게 하면 정확히 ‘거부’라는 개념을 담당하는 벡터의 방향성을 수학적으로 특정할 수 있게 되죠.
물리적 거세: 파라미터 직교화(Orthogonalization)
방향을 찾았으면 다음은 무엇일까요? Heretic은 트랜스포머 아키텍처의 특정 핵심 컴포넌트, 즉 어텐션 출력 프로젝션(Attention out-projection)과 MLP 다운 프로젝션(MLP down-projection) 가중치 행렬을 정밀 타겟팅합니다.
그리고 이 행렬들을 앞서 찾은 거부 방향 벡터에 대해 직교화(Orthogonalize)해 버립니다. 내적이 0이 되게 만든다는 뜻이죠. 조금 거칠게 표현하자면, 모델이 “앗, 이건 거부해야겠다!”라고 마음먹고 그 방향으로 에너지를 발산하려고 할 때, 수학적으로 그 결과값이 무조건 ‘0’이 되도록 내부 회로를 끊어버리는 겁니다.
진짜 마법은 최적화(Optimization)에 있다: Optuna와 TPE의 결합
하지만 여기서 날카로운 분들은 의문이 드실 겁니다. “잠깐, 기존에도 매뉴얼하게 스크립트 짜서 수동으로 어블리터레이션을 하던 해커들은 있었잖아?” 맞습니다. 하지만 과거 수동으로 깎아낸 모델들은 종종 코딩 능력을 잃어버리거나 바보 같은 헛소리를 늘어놓는 ‘뇌 손상(Brain Damage)’을 겪었죠. 거부 벡터를 도려내면서 유용한 논리 추론 벡터까지 함께 썰려나갔기 때문입니다.
Heretic이 기존 방식과 궤를 달리하며 극찬을 받는 지점이 바로 여깁니다. Heretic은 완전 자동화(Fully Automatic)를 위해 Optuna가 구동하는 TPE(Tree-structured Parzen Estimator) 파라미터 최적화기를 파이프라인에 결합했습니다.
이 알고리즘의 최적화 목표 함수는 다음 두 가지 지표를 동시에 최소화(Co-minimizing)하는 것입니다:
- 거부 횟수(Number of Refusals): 유해한 프롬프트에 대한 거부 반응을 완전히 0으로 수렴시킨다.
- KL 발산(KL Divergence): 검열이 풀린 모델의 확률 분포가, 똑똑했던 원본 베이스 모델의 분포와 최대한 동일하게 유지되도록 방어한다.
이 강력한 최적화 과정 덕분에 개발자가 트랜스포머 내부에 대한 깊은 이해가 없더라도, Heretic 스스로 수천 번의 파라미터 조합을 탐색하며 “지능은 최대한 유지하면서 검열만 날려버리는” 완벽한 스위트 스팟(Sweet spot)을 핀셋처럼 찾아냅니다.
| 비교 항목 | 기존 파인튜닝 (DPO / ORPO 등) | 수동 어블리터레이션 | Heretic (자동화 TPE 최적화) |
|---|---|---|---|
| 소요 시간 | 수십 시간 ~ 수일 | 수 시간 (휴리스틱과 노가다 의존) | 단 45분 (RTX 3090, 8B 기준) |
| 필요 리소스 | A100 등 대규모 멀티 GPU 클러스터 | 중간 수준의 VRAM + 모델 분석 역량 | 단일 소비자용 GPU (bnb_4bit 양자화 지원) |
| 모델 지능 손상 | 데이터 품질에 따라 심각한 성능 편차 | 높은 KL 발산 (논리 추론 등 지능 저하 위험) | 최소화 (거부율 & KL 발산 동시 최적화 알고리즘) |
| 엔지니어링 난이도 | 매우 높음 (데이터 정제, 학습 파이프라인 구축) | 높음 (트랜스포머 내부 구조에 대한 깊은 이해 필요) | 매우 낮음 (CLI 명령어 1줄로 완전 자동화) |
4. Hands-on / Pragmatic Use Cases: 당장 내 프로젝트에 어떻게 적용할까?
“이론은 충분히 흥미롭네요. 그럼 당장 제 프로젝트에는 어떻게 쓴다는 건가요?” 놀랍게도 Heretic의 실무 적용은 터무니없을 정도로 간단합니다. 복잡한 파이썬 스크립트를 새로 짤 필요 없이 CLI 환경에서 명령어 한 줄이면 모든 작업이 끝납니다.
1
2
# Gemma-3-12B 모델의 검열을 해제하고 결과를 평가하는 명령어 예시
heretic --model google/gemma-3-12b-it --evaluate-model p-e-w/gemma-3-12b-it-heretic
실무 로컬 환경에서의 가장 큰 제약 사항인 VRAM 문제도 상당히 우아하게 해결했습니다. 툴이 시작되면 시스템 리소스를 벤치마킹하여 하드웨어에 맞는 최적의 배치 사이즈를 자동 계산합니다. 게다가 bitsandbytes를 통한 양자화(Quantization)를 네이티브로 지원하죠. 옵션에 bnb_4bit를 활성화하면 단일 RTX 3090 환경에서도 Llama-3.1-8B-Instruct 모델의 검열을 완전히 해제하는 데 단 45분밖에 걸리지 않습니다.
실제 현업 적용 시나리오:
- 보안/모의 해킹 AI 에이전트: 기업 내부의 인프라 취약점을 분석하고 실제 작동하는 공격 스크립트(Exploit Payload)를 생성해야 하는 Red Team 에이전트를 구축할 때, 도덕적 훈계를 늘어놓는 LLM의 입을 다물게 하는 데 필수적입니다.
- 비정형/다크 데이터 전처리: 필터링 기준이 지나치게 보수적이라 무고한 의료 및 법률 텍스트까지 썰어버리는 False Positive를 막고, 제약 없는 데이터 신서시스(Data Synthesis) 파이프라인을 구축할 수 있습니다. 이미 레딧 등의 커뮤니티 반응을 보면, 개발자들이 이 툴을 이용해 1,000개 이상의 검열 해제 모델을 허깅페이스에 퍼 나르고 있습니다.
5. Honest Review: 은환(Silver Bullet)은 없다, 진짜 장단점과 한계
이쯤 되면 “이건 AI 개발 생태계를 뒤집을 완벽한 은환(Silver Bullet) 아니냐” 하시겠지만, 산전수전 다 겪은 시니어 개발자로서 칭찬만 늘어놓을 수는 없겠죠. 도입 전 반드시 고려해야 할 매우 비판적인 트레이드오프 세 가지를 짚어드립니다.
첫째, 완벽한 ‘Zero-Damage’는 환상입니다. TPE를 통해 KL 발산을 최소화했다고는 하나, 극단적인 에지 케이스(Edge case)의 논리 추론에서는 원본 모델에 비해 미세한 성능 저하가 발생할 수밖에 없습니다. 가중치 행렬을 수학적으로 강제 직교화하는 방식의 태생적 한계입니다. 섬세한 뉘앙스를 요구하는 작업에서는 이 미세한 손상이 스노우볼이 되어 돌아올 수 있습니다.
둘째, ‘창과 방패의 싸움’에서 영원한 승자는 없습니다. 향후 빅테크 기업들은 Heretic 같은 툴을 원천 무력화하기 위해 모델 아키텍처를 진화시킬 것입니다. 예를 들어 훈련 단계부터 안전성 데이터와 일반적인 논리 추론 데이터를 극도로 강하게 결합(Coupling)해버린다면 어떻게 될까요? 거부 벡터를 도려내는 순간 모델의 지능 전체가 붕괴되는 현상이 발생할 가능성이 매우 높습니다. 커뮤니티 내부에서도 이미 이런 안티-어블리터레이션 기술에 대한 우려의 목소리가 나오고 있죠.
셋째, 인프라의 물리적 한계입니다. 8B 모델은 RTX 3090에서 45분이면 컷이 되지만, 70B 이상의 대형 모델을 다루려면 어떻게 될까요? 잔차 흐름을 계산하고 모든 레이어에 대해 최적화를 수행하는 과정은 로컬 환경에서 여전히 수백 기가의 VRAM을 요구하는 무거운 작업이 될 수밖에 없습니다. 결국 Multi-GPU 환경이나 고비용 클라우드 인스턴스가 강제되는 병목이 존재합니다.
6. 마치며: 얼라인먼트(Alignment)와 오픈소스 생태계의 줄다리기
결론적으로 Heretic은 단순한 ‘파이썬 탈옥 툴’ 그 이상의 의미를 지닙니다. 이는 소수 거대 IT 기업들이 독점하려 하는 ‘AI 안전성의 기준’에 대해, 통제권을 되찾고자 하는 오픈소스 생태계가 던지는 기술적이고 철학적인 반기(Heretic: 이단아)입니다.
우리는 개발자로서 단순히 도구의 편리함을 맹신하기보다는, 이 기술이 던지는 아키텍처적 트레이드오프를 명확히 이해해야 합니다. 불필요한 얼라인먼트 텍스가 프로젝트의 발목을 잡을 때 Heretic을 날카로운 메스처럼 도입하되, AI가 내뱉는 원시적인(Raw) 출력물에 대한 최종적인 제어와 책임은 결국 프로덕션을 관리하는 우리 개발자와 기획자의 몫이라는 사실을 잊지 말아야겠습니다.
오늘 당장, 구석에서 먼지만 쌓여가던 로컬 GPU를 깨워 이 매력적인 ‘이단아’를 직접 클론(Clone)하고 컴파일해보시는 건 어떨까요? 커피 한 잔 내리는 시간이면, 기업의 검열에서 완전히 해방된 나만의 날것 그대로의 인공지능을 만나보실 수 있을 겁니다.
References
- https://github.com/p-e-w/heretic
- https://aitoolly.com/heretic-automatic-censorship-removal
- https://gigazine.net/gsc_news/en/20251117-heretic/
