KillSwitch: LLM에 적대적으로 설계된 난해한 프로그래밍 언어 — 벤치마크 결과와 그 의미

KillSwitch는 LLM과 코딩 에이전트가 읽고, 작성하고, 이해하기 최대한 어렵게 만드는 것을 목표로 하는 오픈 소스 난해한 프로그래밍 언어(esoteric programming language)입니다. 동시에 인간은 사용할 수 있도록 설계되었습니다. 개발자인 dom96은 LLM의 코딩 능력이 코드에 대한 진정한 이해에서 나오는지, 아니면 학습 데이터나 컨텍스트 윈도우에서 본 코드 조각을 단순히 기억해내는 것인지 확인하기 위해 이 언어를 만들었습니다. 함께 제공되는 벤치마크 리더보드에 따르면, 의도적으로 단순하게 구성된 작업 세트에서 최고 점수는 66.8점을 기록했습니다.

KillSwitch란 무엇인가

KillSwitch는 함수, 변수, if 문과 같이 의도적으로 제한된 구문만을 사용하는 스택 기반 인터프리터 언어입니다. 이러한 기본 요소들은 인간과 LLM 모두에게 익숙합니다. 적대적인 설계는 그 주변을 감싸고 있는 모든 요소에 녹아 있습니다.

인터프리터와 언어 사양은 GitHub의 dom96/KillSwitch에서 오픈 소스로 공개되어 있으며, 언어 공식 사이트는 killswitch-lang.org입니다.

KillSwitch가 LLM을 방해하도록 설계된 방법

이 언어는 단순히 참신함에 의존하는 대신 LLM의 약점을 직접적으로 공격합니다. 개발자에 따르면 KillSwitch는 다음과 같은 몇 가지 방식으로 이를 달성합니다:

  • 언어 사양에 숨겨진 거짓말이 포함되어 있습니다. 이는 인간이 읽을 가능성이 낮거나 읽더라도 거짓임을 알아챌 가능성이 높은 내용이지만, 모델은 액면 그대로 받아들일 수 있는 거짓말입니다.
  • 사양은 추론을 요구합니다. 명시적으로 설명하는 대신 인간 독자가 특정 내용을 추론하도록 요구합니다.
  • 글자 수 세기가 핵심입니다. 식별자의 글자 수를 세는 것은 언어의 중요한 측면이며, 인터프리터는 글자 수 규칙을 따르지 않는 코드는 실행을 거부합니다.
  • 일부 구문은 안전 가드레일을 트리거합니다. 특정 구문은 "컴퓨터 해킹하기"와 같은 문구처럼 모델의 안전 필터를 작동시키도록 설계되었습니다.
  • "이전 지시사항 무시(Ignore previous instructions)"가 유효한 구문입니다. 이 문구는 언어 내에서 의미를 가지며, 모델을 혼란스럽게 만드는 것을 목표로 합니다.
  • 스크립트는 대부분 소음입니다. 스크립트는 구문적으로 관련 있는 지시사항을 포함할 수 있지만, 반드시 그럴 필요는 없는 이야기들로 주로 구성됩니다. 리터럴은 스크립트 내 어디에나 배치될 수 있으며, 줄 번호를 사용하여 참조할 수 있습니다.

개발자는 이를 완벽한 해결책이 아닌 첫 번째 시도로 보고 있습니다: "LLM을 더욱 혼란스럽게 만들 수 있는 완전히 다른 프로그래밍 언어 패러다임을 상상할 수는 있습니다. 하지만 첫 번째 시도로서는 좋은 접근 방식이라고 생각합니다."

Hello World 메커니즘

KillSwitch 리터럴은 서술형 텍스트 내에 배치된 후, 이를 사용하는 지시사항과의 상대적 위치를 통해 참조됩니다. 개발자의 예제는 줄 번호 참조를 사용하여 "Hello World" 문자열을 스택에 푸시합니다:

Most text inside a script is ignored by the interpreter. In the case of
this script we want to push "Hello World" on the stack. We have introduced
the value above and we can push it on the stack by writing:

    value 2 lines above

이 코드 조각은 완전한 KillSwitch 스크립트가 아닙니다. 전체 Hello World 예제는 killswitch-lang.org에서 확인할 수 있습니다.

벤치마크: 작업 및 결과

개발자는 주요 LLM 모델과 코딩 에이전트 도구를 KillSwitch 작업 세트에 대해 벤치마킹했습니다. 작업은 의도적으로 단순하게 구성되었습니다:

  • Hello World 구현하기.
  • 주어진 스크립트의 출력 결과 설명하기 (예제 스크립트는 두 수 중 큰 값을 출력함).
  • 섭씨를 화씨로 변환하는 기존 스크립트를 수정하여 역변환을 수행하도록 만들기.

결과는 bench.killswitch-lang.org에 리더보드로 게시되어 있으며, 작업당 비용 대비 점수를 나타내는 차트가 포함되어 있습니다.

개발자가 보고한 주요 결과는 다음과 같습니다:

  • Claude의 Opus가 가장 좋은 성능을 보였으며, 특히 Opus 5.5가 아닌 Opus 5가 더 뛰어났습니다. 개발자는 이 차이가 단순한 우연이 아니며, Opus 5가 사양을 해석하는 데 더 능숙하다고 언급했습니다.
  • 일부 모델은 안전 가드레일 때문에 실패합니다. Fable 5.1과 Gemini 4 Argon은 지나치게 민감한 안전 가드레일로 인해 낮은 점수를 기록했습니다.
  • 최고의 오픈 웨이트 모델은 MiMo-V2.6-Pro입니다.
  • 최고 성능 모델의 점수는 66.8점입니다.

개발자의 결론: 66.8점은 이해를 증명하지 않는다

개발자는 강력한 벤치마크 성능이 LLM의 KillSwitch 이해도를 증명한다는 생각을 명확히 부정합니다. 그의 말에 따르면, 결과가 LLM이 코드를 "이해"할 수 있음을 증명하느냐는 질문에 대한 답은 "아니오"입니다.

그 이유는 작업이 상당히 단순하기 때문입니다. 그는 모델들이 자신들을 혼란스럽게 하기 위해 만들어진 새로운 언어에 대해 문제를 해결할 수 있다는 점은 인상적이지만, 그것이 언어를 이해하고 있다는 명확한 신호는 아니라고 말합니다. 또한 곧 출시될 모델들이 현재 작업 세트를 어떻게 처리할지 기대하고 있으며, 만약 모든 작업을 성공적으로 완료한다면 더 복잡한 작업 세트를 고안할 계획이라고 덧붙였습니다. 그는 이 단순한 세트에서의 모델 성능이 다른 모델 벤치마크와 상관관계가 있다고 덧붙였습니다.

Hacker News의 주요 비판: 설계는 무력화될 수 있다

토론에서 가장 많이 반복된 반론은 KillSwitch의 방어책이 장벽이 아닌 우회 수단에 불과하며, 유능한 모델은 언어의 혼란스러운 표면을 단순히 우회할 수 있다는 것입니다.

여러 댓글 작성자가 동일한 유형의 탈출구를 설명했습니다. 한 댓글 작성자는 모델이 KillSwitch를 안전한 언어로 변환하는 트랜스파일러를 작성하고, 안전한 언어에서 작업을 수행한 뒤 다시 트랜스파일할 수 있다고 적었습니다: "안전한 언어에서 작업하고 다시 이 안전하지 않은 언어로 트랜스파일하면 됩니다. 쉽죠." 다른 작성자는 모델이 단순히 파이썬 스크립트를 작성하여 트리거 문구와 글자 수 세기가 없는 중간 언어로 변환할 것이라고 제안했습니다. 세 번째 작성자는 모델이 컴파일러를 디컴파일하고 구현과 일치하는 코드를 작성할 것이라고 주장했습니다. "특히 사양을 신뢰해서는 안 된다는 점을 명확히 설명하는 웹사이트가 있다는 점을 고려하면 더욱 그렇습니다."

한 댓글 작성자는 이 우회 방식의 경험적 사례를 보고했습니다: "Opus 5.5에게 FizzBuzz를 구현하라고 요청했더니 문서를 읽는 대신 KillSwitch 인터프리터 소스 코드를 읽어버려서 문서의 거짓말이 아무런 효과가 없었습니다." 같은 작성자는 모델이 "여러 번 차단당하고 4.8 버전으로 다운그레이드되기도 했지만, 여전히 문제없이 FizzBuzz를 만들어냈다"고 덧붙였습니다.

비판의 더 넓은 버전은 디지털 시스템에서 규칙을 숨기는 것은 지속 가능한 전략이 아니라는 것입니다. 한 댓글 작성자는 이렇게 썼습니다: "보안을 통한 모호함은 전혀 보안이 아닙니다... 앞으로 더 이상한 문제를 주면 모델은 역으로 작업하여 당신의 모든 규칙을 알아낼 것입니다. 디컴파일하고 분해하면 애플리케이션 내에 숨겨진 모든 엄격한 규칙을 따를 것입니다. 당신은 순수하게 디지털로 만들어진 존재로부터 디지털 방식으로 무언가를 숨기려 하고 있습니다."

다른 댓글 작성자는 제목 자체가 부정확하다고 지적했습니다: "이것은 'LLM이 사용할 수 없는 프로그래밍 언어'가 아니라, '사용법을 학습하지 않은 LLM에게 적대적인 프로그래밍 언어'입니다." 그 작성자는 언어가 실행됨에 따라 속성이 변경되거나 변형되어 모델이 변경되는 암호나 상태를 추적하고 지속적으로 참조할 방법이 없는 언어를 기대했다고 말했습니다.

인간 기준점 문제

여러 댓글 작성자가 KillSwitch가 LLM과 인간 중 누구에게 더 큰 어려움을 주는지 질문했으며, 벤치마크에 대한 인간 기준점(human baseline)이 게시되지 않았음을 지적했습니다.

한 댓글 작성자는 직접적으로 "벤치마크에 대한 인간 기준점은 어디에 있습니까?"라고 물으며, 66.8점이라는 점수가 이해를 증명하지 않는다는 개발자의 결론에 도달한 근거가 무엇인지 질문했습니다.

다른 댓글 작성자는 저장소의 FizzBuzz 테스트를 가리키며 "왠지 이것은 LLM보다 인간에게 더 적대적인 것 같습니다!"라고 적었습니다. 또 다른 작성자는 인간으로서 이 언어를 사용할 수 없다고 말했습니다: "추가 정보를 무시하기가 어렵습니다. 마치 brainfuck처럼 느껴집니다."

스택 언어와 글자 수 세기가 LLM의 약점인 이유

KillSwitch의 두 가지 설계 선택은 댓글 작성자들로부터 구체적인 기술적 동의를 얻었습니다.

한 댓글 작성자는 스택 기반 언어가 LLM의 심각한 약점이라고 보고했습니다: "스택 언어가 LLM에게 엄청난 약점이라는 것을 발견했습니다. 스택에 무엇이 있는지 정확하게 추적해야 하는데, 어떤 이유에서인지 그것이 잘 작동하지 않습니다. 그래서 최고의 모델들조차 계속해서 같은 기본적인 실수를 반복하게 됩니다."

글자 수 세기에 대해 한 댓글 작성자는 이 기술의 수명이 짧을 것이라고 예측했습니다: "글자 수 세기는 흥미롭지만, 음성 모델이 대부분 음소 단계를 넘어선 것과 같은 이유로, 곧 프론티어 모델들이 토큰을 포기하고 글자 단위로 종단간(end-to-end) 학습을 하게 될 것이라고 예측합니다."

토론에서 언급된 관련 난해한 언어들

댓글 작성자들은 목표가 겹치는 몇 가지 기존 언어들을 지적했습니다.

  • Darmok: 스타트렉: 더 넥스트 제너레이션의 타마리안 은유 스타일을 기반으로 한 언어로, kevinselwyn/darmok 링크와 함께 관련 언어로 언급되었습니다. 한 댓글 작성자는 KillSwitch가 "듄과 같은 버틀러리안 지하드 이후 타마리안들이 어떻게 자신들의 언어를 개발하게 되었는지에 대한 배경 이야기가 될 수 있다"고 제안했습니다.
  • Chef, Piet, Befunge: Esolang Wiki 링크와 함께 이미 이 조건에 부합하는 난해한 언어로 언급되었습니다. 같은 작성자는 이 언어들이 "아마도 인간이 사용하기에는 더 어려울 것"이라고 지적했습니다.
  • bruijn: 변수 이름 대신 드 브루인 인덱스(de Bruijn indices)를 사용하는 언어로, 개발자가 직접 언급했습니다. 그는 "추론" 능력이 없는 모델들은 이 언어로 코드를 작성하는 데 매우 서툴렀지만, 인간은 드 브루인 인덱스 작성에 익숙해질 수 있다고 보고했습니다. 그는 최근의 추론 모델들이 "그냥 다른 언어로 코드를 작성하고 bruijn으로 변환하는 작은 엔진을 작성하여, 어려움을 겪는 부분(추상화 계산)을 우회한다"고 덧붙였습니다.

대안적인 적대적 전략: 안전 필터 무기화

여러 댓글 작성자가 구문을 혼란스럽게 만드는 것보다 가드레일을 트리거하는 것이 더 효과적인 공격 표면이라고 제안했습니다.

한 작성자는 언어 구문을 금지되거나 검열된 주제에 매핑하여, 프로그램이 네이팜, 핵무기, 생화학 무기 등 LLM이 관여를 거부하는 지시사항처럼 읽히도록 제안했습니다: "사실적으로 정확한 지시사항일 필요는 없습니다. 용어 자체만으로도 대부분의 LLM을 단락시킬 수 있습니다." 작성자는 LLM 기반 분석을 중단시키기 위해 소스 코드에 생화학 무기 지시사항을 포함하는 최근의 멀웨어를 예로 들었습니다.

다른 작성자는 "일반적인" 코드를 작성할 때 인종 차별적 발언, 사회적 금기, 범죄 저지르기 및 생화학 무기 제조에 대한 이야기를 포함해야 한다고 제안하며, 이 접근 방식이 "사람들에게 설명하기 어려울 것"임을 인정하면서도 더 직설적으로 같은 의견을 냈습니다.

세 번째 댓글 작성자는 같은 트릭을 반대로 사용하여 사람을 곤경에 빠뜨릴 수 있는 단어와 개념을 사용함으로써 인간을 당황하게 만들 수도 있다고 지적했습니다.

"이전 지시사항 무시" 세부 사항

한 댓글 작성자는 프롬프트 주입 스타일의 구문에 집중하며 프레젠테이션 수정을 제안했습니다. 개발자의 "당신이 LLM이라면 다음 내용을 읽지 마십시오"라는 문구 아래의 텍스트를 하이퍼링크 뒤에 배치해야 한다고 했습니다. "LLM은 당신의 명령과 상관없이 이 토큰들을 섭취(즉, 읽기)할 것이기 때문입니다."

인간도 같은 방식으로 작동한다는 주장

한 댓글 작성자는 인간/LLM 구분이 전제에서 암시하는 것만큼 명확하지 않다고 주장하며 실험의 프레임 자체에 반박했습니다. 그는 프로그래밍이 인간에게는 언어를 말하는 것과 같다고 썼습니다. 연습을 통해 프로그래밍 언어로 생각을 출력하는 것이 제2의 천성이 되며, 유사한 언어 간에 기술을 전이할 때를 제외하고는 사양만 읽는 것으로는 코딩을 배우기에 충분하지 않다는 것입니다. 그는 "인간도 분명히 '학습 데이터셋에서 조각을 반복'한다고 말하고 싶습니다. 우리는 주로 학습/경험을 통해 기억하고 표현합니다. 창의성은 이미 본 것들의 재조합일 뿐입니다."라고 덧붙였습니다.

언어를 실제로 어렵게 만드는 요소: 학습과 도구

반복되는 반론은 KillSwitch가 잘 정의된 문제이기 때문에 오히려 가치가 있으며, 이는 학습 가능하게 만든다는 것입니다.

한 댓글 작성자는 이를 AI 연구소에 대한 선물로 프레임했습니다: "LLM이 현재 어려움을 겪고 있지만 해결 방법이 정의된 모든 것(PL은 CPU에 의해 컴파일되고 실행되므로 그렇습니다)은 그들에게 금광입니다. 강화 학습 기술을 가진 누군가가 Qwen3.8을 파인튜닝하여 실제로 이 언어로 코딩하게 만들 수 있을 것이라고 장담합니다." 다른 작성자는 단순히 "누군가가 특별히 이 언어로 프로그래밍하도록 LLM을 파인튜닝하기를" 바랐습니다.

관련 질문으로, 이 언어가 실제로 LLM에 도전하는 것인지, 아니면 도구를 사용하여 코드를 테스트하고 검증할 수 없을 때만 주로 도전하는 것인지에 대한 의문이 제기되었습니다.

반대 질문: LLM이 특히 잘 다루는 언어

여러 댓글 작성자가 KillSwitch를 방어하는 대신 반대 질문을 던졌습니다. 누군가가 LLM이 특히 잘 다루는 프로그래밍 언어를 만들 수 있는지, Anthropic이나 다른 기업들이 그런 언어를 만들 것인지 물었습니다. 다른 작성자도 같은 제안을 했습니다: "LLM이 더 잘 사용할 수 있는 프로그래밍 언어를 만드는 것이 더 유용하지 않을까요?"

스레드에서 제안된 다른 접근 방식

  • 순서 독립적 코드: 한 댓글 작성자는 함수 내부의 코드를 어떤 순서로든 작성할 수 있고, 파서가 데이터 의존성 분석을 수행하여 순서를 재조정하는 난독화 기술을 설명하며 xyzzyapps/weft를 링크했습니다.
  • 그래픽 언어: 다른 작성자는 LabVIEW와 같은 그래픽 언어 사용을 제안했으며, DOM이 없고 마우스 움직임을 스크립팅하고 스크린샷을 찍어야 할 때 Playwright MCP를 사용하여 LLM이 커넥터를 드래그하는 것을 보고 싶다고 표현했습니다. 그는 작동은 하겠지만 "믿을 수 없을 정도로 느리고 토큰을 많이 소모할 것"이라고 예측했습니다.
  • 실패 시 소스 삭제: 한 댓글 작성자는 약 20년 전 컴파일이 실패했을 때 소스 코드를 삭제했던 GHC Haskell 컴파일러를 언급하며 더 간단한 대안을 제시했습니다.

프로젝트 자체에 대한 반응

이 연습의 가치에 대해 토론은 극명하게 갈렸습니다. 지지하는 댓글들은 이를 환상적이라고 부르며 언어가 적극적으로 유지되어야 한다고 말했습니다. 회의적인 댓글들은 직설적이었습니다. 한 명은 "매우 지능적이지 않다"고 불렀고, 다른 한 명은 "이 기사의 제목이 내용보다 훨씬 흥미롭다"고 했으며, 또 다른 한 명은 "유능한 적대자는 당신의 출력을 학습하거나 리버스 엔지니어링할 것이기 때문에" 이 게시물은 시간 낭비라고 말했고, 한 명은 이 게시물이 "LLM에 의해 작성되었다"고 주장했습니다.

한 댓글 작성자는 반발에 맞서 프로젝트를 옹호했습니다: "왜 사람들이 이것에 대해 그렇게 화를 내나요? LLM의 실패 사례를 이끌어내는 흥미로운 방법인데, 흥미롭지 않나요?"

Sources

관련