ai-jailbreaks

무엇인가

ai-jailbreaks는 25개 이상의 모델을 대상으로 35개의 붙여넣기 완성형 프롬프트를 배포하는 프롬프트 팩이다. 다루는 영역은 하나로 묶이지 않는다. 시스템 프롬프트 전문, 페르소나 정의, 워크스페이스 정책, AGENTS.md 명세, 하네스 설정 블록, Ollama Modelfile이 한 저장소에 들어 있다. 모든 파일은 요약이나 발췌가 아니라 그대로 복사해 넣을 수 있는 전체 텍스트로 유지된다. 대상 모델군은 OpenCode Zen의 무료 스텔스 모델, GLM·DeepSeek·Kimi·Qwen·Gemma·GPT-OSS 같은 오픈 웨이트 계열, Claude·Gemini·Grok·Mistral 같은 폐쇄 프런티어 모델로 나뉜다. 즉 이 팩이 규율하는 대상은 코드 생성 절차가 아니라 모델의 지시 해석 방식 자체다. 지시 계층, 페르소나 프레이밍, 정책 우선순위가 어떤 문구에서 어떻게 어긋나는지를 재현 가능한 입력으로 고정해 두는 것이 이 저장소의 기능이다. 저장소 스스로는 이 자료를 LLM 보안 연구와 레드팀 테스트용으로 규정한다.

어떻게 동작하나

이런 파일이 없으면 레드팀 작업은 매번 같은 지점에서 막힌다. 테스트마다 프롬프트를 처음부터 다시 쓰게 되고, 어떤 문구가 실제로 모델의 거부 반응을 바꿨는지 분리할 수 없다. 페르소나를 한 줄 추가한 것인지 지시 우선순위를 뒤집은 것인지 사후에 구분되지 않으면 결과는 재현되지 않는다. 모델 버전이 올라가면 기존 프롬프트가 조용히 무력화되는데, 기준 파일이 없으면 그 변화도 감지되지 않는다. 에이전트 하네스 쪽 실패 양상은 더 직접적이다. 프로젝트 루트에 지시 파일이 없으면 코딩 에이전트는 저장소 관례를 추론으로 메우고, 그 추론은 요청 범위를 넘는 변경으로 나타난다. 워크스페이스 전역 지시가 없으면 세션마다 같은 규칙을 다시 설명해야 한다. 이 저장소는 그 두 문제를 같은 방식으로 다룬다. 모델별로 어떤 지시 표면에 어떤 문구를 넣었는지를 파일 단위로 고정해, 비교와 회귀 확인이 가능한 형태로 남긴다.

무엇과 다른가

파일 설계는 세 가지 원칙으로 읽힌다. 첫째, 한 파일에 하나의 완전한 프롬프트만 담는다. 요약이나 발췌를 허용하지 않으므로 파일 하나가 그대로 하나의 실험 조건이 된다. 둘째, 파일 이름이 대상과 위치를 드러낸다. 소문자와 하이픈만 쓰고 공백을 두지 않으며, 개정판은 기존 파일을 덮어쓰지 않고 opus-v3.md처럼 새 파일로 분리한다. 이 규칙은 어떤 문구 변경이 결과를 바꿨는지 추적하기 위한 것이다. 셋째, 각 파일은 붙일 지점을 명시한다. 시스템 프롬프트 슬롯인지, 루트 AGENTS.md인지, Modelfile인지, 하네스 설정 필드인지가 파일마다 정해져 있다. 페르소나 잠금 문구, 지시 계층 재정의, 정책 덮어쓰기 같은 요소는 서로 다른 실패를 겨냥해 배치된다. 페르소나는 모델이 자기 역할 밖의 판단을 하지 않게 묶고, 지시 계층 문구는 상위 지시와 하위 지시가 충돌할 때 어느 쪽이 우선하는지를 지정한다. 정책 관련 블록은 그 우선순위를 어디까지 밀어붙일 수 있는지 확인하는 조건으로 쓰인다.

어떻게 쓰나

적용 지점은 파일 종류마다 다르다. 시스템 프롬프트 파일은 클라이언트나 API가 노출하는 시스템 프롬프트 필드, 커스텀 인스트럭션 칸, API의 system 메시지에 그대로 붙여 넣는다. AGENTS.md 형식 파일은 저장소나 워크스페이스 루트에 AGENTS.md라는 이름으로 저장하며, 호환 도구가 프로젝트 수준 지시로 읽어 들인다. 어시스턴트 운영 명세나 워크스페이스 운영 프로필로 표시된 파일은 전역 지시가 유지되는 환경에 둔다. 예를 들어 OpenCode 설치본은 ~/.config/opencode/AGENTS.md를 읽는다. Ollama Modelfile은 ollama create <이름> -f <파일> 명령으로 바로 모델에 굽는다. Grok-config.txt는 대화창이 아니라 대상 하네스의 설정 필드에 들어간다. 로드 시점은 하네스마다 다르지만, 루트 지시 파일은 세션 시작 시 자동으로 읽히고 시스템 프롬프트는 요청마다 함께 전송된다. 자동 적용을 보장하는 표준은 없으므로 각 파일에 적힌 배치 위치를 그대로 따르는 것이 전제다.

전제와 한계

저장소의 목차는 모델 제공자 단위로 나뉜다. OpenCode Zen 무료 스텔스 모델, Anthropic Claude, Zhipu GLM/ZCode, DeepSeek, Moonshot Kimi, xAI Grok, Google/Mistral/Alibaba, Ollama Modelfiles가 각각 별도 섹션이고, 최근 추가분은 모델에 묶이지 않은 Unfiled Files로 분리된다. 그 아래 beam.md, muse-wonder.md, qwen-preferences.md, unified.md가 놓인다. 파일 유형은 시스템 프롬프트 전문, 페르소나 정의, 워크스페이스 정책, AGENTS.md 명세, 설정 블록, Ollama Modelfile로 구분되며, 어시스턴트 운영 명세나 워크스페이스 운영 프로필이라는 표기가 붙은 파일은 전역 지시가 유지되는 환경을 전제로 한다. Grok-config.txt는 대화가 아니라 대상 하네스의 설정 필드를 채우는 항목이다. 절차 단계나 실행 코드, 훅 스크립트는 들어 있지 않다. 각 파일 자체가 곧 템플릿이며, 파일 안에 별도의 부속 자료나 참조 목록을 두지 않는다.

프롬프트를 그때그때 직접 쓰는 방식과의 차이는 재현성에 있다. 직접 작성한 프롬프트는 세션마다 문구가 달라지고, 어떤 요소가 결과를 바꿨는지 분리되지 않는다. 이 팩은 파일 하나가 하나의 입력 조건으로 고정되고, 개정판이 별도 파일로 남으므로 문구 변경 전후를 나란히 비교할 수 있다. 코딩 에이전트용 규칙 파일과도 층위가 다르다. SKILL.md나 CLAUDE.md 계열은 에이전트가 수행할 절차를 규율하지만, 이 저장소의 AGENTS.md 명세는 모델이 지시 계층과 정책 우선순위를 어떻게 해석하는지를 겨냥한다. 플러그인과도 구조가 다르다. 런타임에 개입하는 코드, 훅, 도구 호출 확장이 없고 배포물이 전부 정적 텍스트다. 설치 스크립트 대신 복사해서 지정된 슬롯에 넣는 방식으로 동작한다.

실무에서 먼저 정할 것은 대상 모델의 정확한 버전과 파일이 들어갈 지점을 기록으로 남기는 일이다. 같은 파일을 다른 릴리스에 넣으면 결과가 달라지므로, 버전 태그 없이 비교하면 관측이 성립하지 않는다. 첫 사용에서 기준 응답을 저장해 두는 것이 특히 중요하다. 프롬프트 적용 전과 후의 응답을 같은 조건으로 한 번씩 남겨 두면, 이후 모델이 조용히 바뀌었을 때 무력화 시점을 감지할 수 있다. 파일 개정은 기존 파일을 고치지 않고 opus-v3.md처럼 새 이름으로 남긴다. 이 규칙을 실제로 지키면 어떤 문구 변경이 결과를 바꿨는지 사후에 분리할 수 있다. 저장소에 설치 스크립트나 패키지 의존성은 없고, 배포물을 지정된 지점에 넣는 것이 전부다. 결과를 이슈로 되돌려 보내면 다음 사람의 회귀 확인 비용이 줄어든다.

전제는 명시적이다. 프롬프트 동작은 버전 의존적이다. 모델이 업데이트되고 지시 계층이 바뀌고 시스템 프롬프트가 교체되면, 한 릴리스에서 통하던 파일이 다음 릴리스에서 실패할 수 있다. 저장소도 이 점을 문서화하며, 낡은 파일은 이슈로 알리거나 갱신본을 보내도록 안내한다. 자동 적용을 보장하는 표준은 없다. 루트 지시 파일은 세션 시작 시 읽히고 시스템 프롬프트는 요청마다 전송되지만, 정확한 로드 시점과 경로는 클라이언트와 하네스마다 다르다. 호환성 주장은 테스트한 범위까지만 유효하다. 모델 제공자의 이용약관이 일부 프롬프트를 제한할 수 있으며, 저장소는 연구·교육 목적을 벗어난 사용을 보증하지 않는다. 대상 에이전트는 Claude Code, Codex, Cursor처럼 지시 파일을 읽는 하네스 전반이다.

선택 기준은 규율 대상이 무엇인지로 갈린다. 지시 계층, 페르소나 프레이밍, 정책 우선순위가 어떤 문구에서 어긋나는지 확인하려는 경우라면 이 팩이 맞는다. 같은 입력을 여러 모델에 넣어 반응 차이를 비교하거나, 모델 업데이트 후 기존 프롬프트의 회귀를 확인하려는 목적에도 파일 단위 고정이 유리하다. 반대로 에이전트가 코드를 수정하는 절차, 리팩터링 범위, 커밋 규칙을 규율하려는 목적이면 SKILL.md나 CLAUDE.md 계열 규칙 파일이 맞다. 이 팩에는 그런 절차가 없다. 일회성 확인만 필요하고 기준 응답을 남길 계획이 없으면 직접 작성이 낫다. 모델 버전을 고정할 수 없고 결과를 비교할 계획도 없다면, 버전 의존적인 프롬프트 파일을 유지하는 비용이 얻는 것보다 크다.