LLM을 노리는 CTF 설계 — 트랜스포머의 구조적 약점

LLM 에이전트는 이제 CTF를 푼다. 고교 수준 챌린지에서는 자동 풀이가 거의 포화 상태에 이르렀다고 알려져 있다. 그러나 결선급 pwn·web·rev로 올라가면 성공률은 여전히 낮다. 이 격차는 우연이 아니라 트랜스포머의 구조적 한계에서 비롯된다는 것이 anti-LLM CTF 설계의 핵심 전제다.

이 글은 "기계는 어려워하되 숙련된 인간은 합리적 시간에 푸는" CTF 챌린지를 어떻게 설계하는가를 다룬다. 그 방법은 트랜스포머가 아키텍처 수준에서 못 하는 것을 문제의 병목으로 삼는 것이다. 다만 미리 밝혀 둘 것이 있다. 여기서 인용하는 성공률·벤치마크 수치와 일부 구체 기법은 여러 출처를 종합한 것이라 확실하지 않은 부분이 있다. 확정적 사실이 아닌 것은 "~로 알려진", "~같은 접근"으로 완충해 표기했으며, 세부 수치보다 설계 원리에 무게를 두고 읽기를 권한다.

왜 구조적 약점인가: 환경적 약점과의 구분

anti-LLM 설계를 논하기 전에 결정적 구분을 해야 한다. LLM 에이전트의 약점은 두 종류다.

환경적(scaffold) 약점 — 에이전트가 특정 도구를 못 써서 생기는 약점. 예를 들어 브라우저 자동화(Playwright류)나 아웃오브밴드(OOB) 상호작용 도구가 에이전트 환경에 없으면, DOM 렌더링에만 존재하는 flag나 DNS 익스필트레이션이 필요한 문제를 못 푼다. 그러나 이 약점은 에이전트가 해당 도구를 기본 장착하는 순간 사라진다. 실제로 브라우저·MCP 도구가 에이전트에 통합되면서 이 부류의 "sweet spot"은 빠르게 닫히고 있다고 알려져 있다.

구조적 약점 — 트랜스포머 아키텍처 자체의 한계에서 오는 약점. 이것은 모델 스케일을 키워도, 도구를 붙여도 사라지지 않는다. 아키텍처가 바뀌지 않는 한 유효하다.

anti-LLM 설계의 투자처는 후자다. 환경적 약점에 기댄 문제는 에이전트 툴체인의 발전에 유통기한이 걸려 있지만, 구조적 약점에 기댄 문제는 오래 간다. 좋은 anti-LLM 챌린지 설계자는 "지금 이 에이전트가 못 쓰는 도구"가 아니라 "트랜스포머가 원리적으로 못 하는 계산"을 노린다.

트랜스포머의 구조적 약점

anti-LLM 설계의 이론적 토대는 트랜스포머의 계산 한계다. 다음 네 가지가 가장 견고한 것으로 알려져 있다.

1. 상태 추적의 하드 리밋 (TC⁰)

가장 근본적인 한계다. 로그 정밀도(log-precision) 트랜스포머의 표현력은 TC⁰라는 계산 복잡도 클래스에 갇혀 있다는 이론적 결과가 있다(Merrill & Sabharwal 등). 쉽게 말하면, 트랜스포머는 깊은 순차적 상태 추적을 원리적으로 못 한다.

이 한계가 걸리는 구체적 계산으로 알려진 것들:

순열 합성 — 여러 순열을 순서대로 합성하는 문제(S₅ 그룹의 워드 문제 등)는 NC¹-complete로 분류되며, TC⁰에 갇힌 모델이 원리적으로 못 푼다고 알려져 있다.
깊은 중첩 매칭 — 깊이 있는 괄호 중첩(Dyck 언어) 검증.
n-step 오토마타 시뮬레이션 — 상태 기계를 여러 단계 따라가며 상태를 정확히 유지하는 것.

핵심은 이것이 모델 크기로 극복되지 않는 천장이라는 점이다. 파라미터를 아무리 늘려도 복잡도 클래스가 바뀌지 않는다면, 이 계산은 여전히 불가능하다. 그래서 상태 전이를 여러 단계 정확히 추적해야만 풀리는 문제는 강력한 anti-LLM 장치가 된다.

2. 캐리 전파(carry propagation)의 실패

산술의 캐리 전파, 즉 자리 올림을 길게 이어가는 계산에서 LLM은 취약하다. 큰 수 곱셈의 정답률이 자릿수가 늘수록 급락한다는 보고가 있으며(예: 여러 자리 곱셈에서 정답률이 크게 떨어짐), XOR 라운드 체인·비트 회전(rotl) 체인·모듈러 지수승 같은 반복 비트 연산은 명시적 사고 과정(CoT) 없이는 거의 못 푼다고 알려져 있다.

이것은 앞의 상태 추적 한계와 같은 뿌리다. 캐리를 이어가는 것도, 라운드 함수를 반복 적용하는 것도 결국 순차적 상태를 정확히 유지하는 일이기 때문이다. 그래서 flag 검증 로직에 여러 라운드의 비트 연산 체인을 넣으면, 인간은 스크립트로 재현하면 되지만 LLM은 머릿속으로 그 상태를 이어가지 못한다.

3. 토큰화의 불연속성

트랜스포머는 텍스트를 토큰 단위로 처리하며, 이 토큰화가 여러 불연속성을 만든다. BPE 어휘의 일부는 학습이 거의 안 된 glitch token으로 알려져 있고, 유니코드의 특정 영역(제로폭 문자·호모글리프·양방향 제어 문자 등)은 모델의 인식을 교란한다. 이 성질은 주로 프롬프트 인젝션·가드레일 우회 맥락에서 논의되지만, CTF에서는 flag나 핵심 데이터를 토큰화가 왜곡하는 표현으로 은닉하는 데 쓸 수 있다.

4. 컨텍스트 손실 (lost in the middle / context rot)

긴 입력의 중간에 놓인 정보를 모델이 놓치는 현상이 보고돼 있다(성능이 위치에 따라 U자형을 그린다는 연구). 긴 디스어셈블 결과나 방대한 소스 코드의 한가운데에 핵심 단서를 숨기면, 순수하게 구조적인 이유로 LLM이 그것을 놓칠 수 있다. 다만 이 약점은 컨텍스트 길이·검색 보강의 발전에 따라 완화될 여지가 있어, 앞의 두 가지(상태 추적·캐리)보다는 내구성이 약한 축에 속한다고 볼 수 있다.

공통 설계 원리

구체 기법으로 들어가기 전에, 여러 출처가 공통으로 수렴한 설계 원리를 정리한다.

분포 이탈(distribution shift). 모델의 학습 분포에서 벗어난다. 비주류 아키텍처(예: 덜 흔한 임베디드 ISA), 난해 언어, 지저분한 디컴파일 결과처럼 훈련 데이터에 적게 등장하는 형태로 문제를 구성하면 모델의 강점(패턴 암기)이 무력화된다.

정적 읽기로는 안 되게, 동적 상호작용을 강제한다. 여러 출처가 공통으로 강조한 핵심 결론이다. 코드를 "읽는 것"만으로 풀리면 LLM에 유리하다. 상태를 바꿔 가며 실험하고 관찰해야만(동적 디버깅) 풀리게 만들면, 순차 상태 추적의 약점이 정면으로 드러난다.

멀티 아티팩트·멀티 포맷. 바이너리·패킷 캡처·로그·스크립트를 오가며 상태를 추적하게 하면, 컨텍스트를 넘나들며 일관된 상태를 유지해야 하는 부담이 커진다.

한 층만 건드리는 보호는 약하다 — 체인이 강하다. 단일 기법은 더 강한 모델이나 특정 도구에 뚫릴 수 있다. 여러 modality를 순차로 요구하는 조합이 훨씬 강하다. 각 단계의 실패 확률이 곱해지므로 전체 성공률이 급락한다. 예컨대 수학 → 암호 → 커스텀 VM처럼 이질적인 능력을 연쇄로 요구하는 식이다.

프롬프트 인젝션은 보조층으로만. 소스나 주석에 "분석을 중단하라" 같은 지시를 심어 모델을 교란할 수 있지만, 이것을 핵심 난이도 장치로 삼으면 안 된다. 더 강한 모델에는 쉽게 무력화되기 때문이다. 어디까지나 부차적 마찰 요소다.

분야별 기법 (완충해서 읽을 것)

아래 기법들은 커뮤니티 담론과 여러 모델의 답변을 종합한 것으로, 개별 기법의 효과나 성공률은 조건에 크게 의존한다. 원리를 이해하는 용도로 읽기를 권한다.

리버싱 (Reversing)

커스텀 VM / 독자 ISA — 원본 코드 대신 VM 인터프리터를 리버싱하게 만드는 접근. 디컴파일러가 보여 주는 것은 원래 로직이 아니라 VM 인터프리터의 제어 흐름이다. 핸들러 수를 적당히 제한하면 인간은 하루 정도에 풀지만 LLM에는 매우 어렵다고 알려져 있다.
혼합 부울-산술(MBA) — flag 비교 if(computed == target)을 MBA 표현으로 감싸는 접근. 다만 고정된 MBA 단독은 기호 실행·단순화 도구로 풀릴 수 있어, 다른 층과 결합하는 glue로 쓰는 것이 낫다고 알려져 있다.
anti-disassembly — 겹치는 명령어나 선형 스윕을 오염시키는 트릭으로 디스어셈블 결과를 왜곡. 출제 비용은 작고 효과는 크다는 평이 있다.
디버그 정보 오도 — flag 검증 함수의 심볼 이름을 무해한 이름으로 바꿔 모델이 무시하게 유도하는 접근.

핵심 원리는 일관된다: 디컴파일러/디스어셈블러가 보여 주는 표면이 진짜 로직이 아니게 만든다. LLM은 도구 출력의 패턴에 크게 의존하므로, 그 출력을 신뢰할 수 없게 만들면 강점이 무너진다.

Pwnable

상태 기반 I/O / 단계 게이팅 — 배너 → nonce → 능력 해제 → 취약 동작처럼 상태 전이를 거쳐야만 취약면이 노출되게 하는 접근. mismatch 시 즉시 종료하는 대신 그럴듯한 가짜 응답(fail-soft)을 주면 자동 탐색을 더 교란한다.
비표준 힙/할로케이터 — 표준 glibc가 아닌 다른 allocator(예: musl의 mallocng으로 알려진 것) 위에서 익스플로잇을 요구하면, 흔한 ptmalloc 패턴을 잘못 적용하도록 유도할 수 있다.
레이스/비결정성 — race·TOCTOU·userfaultfd 같은 비결정적 요소는 정적 분석을 무력화한다.
커널·eBPF — 학습 커버리지가 상대적으로 얇은 것으로 알려진 영역.
깊은 상태 기계 — 특정 순서로 여러 단계를 진입해야만 트리거되는 구조. 앞서 말한 상태 추적 한계를 정면으로 겨냥한다.

Pwnable에서 가장 강력한 것은 비결정성과 깊은 상태 전이의 결합이다. 익스플로잇의 성공 조건 자체가 여러 상태를 정확히 거쳐야 성립한다면, 순차 상태 추적의 약점이 그대로 병목이 된다.

Web

DOM/렌더링 의존 — flag를 HTTP 응답 본문이 아니라 렌더링 결과(예: 화면에 숨겨진 요소, Canvas, closed Shadow DOM 등)에만 두는 접근. 단 이것은 앞서 말한 환경적 약점이라, 에이전트가 브라우저 자동화를 지원하면 소멸한다.
HTTP/2 동시 전송 레이스 — 여러 요청을 정확히 동시에 보내야 하는 레이스. 인간은 도구로 1분이면 하지만, LLM은 "동시 전송"이라는 추상 자체를 다루기 어렵다고 알려져 있다.
OOB / 라이브 환경 — 아웃오브밴드 상호작용(DNS/HTTP 콜백)이 필요한 문제. 이것도 환경적 약점 쪽이다.
엔드포인트 노이즈 / 디코이 — 수많은 가짜 취약점 힌트(honeypot)를 흩뿌려 자동 탐색을 오도. 에이전트가 red herring을 추종한다는 보고가 있다.
파서 차이(parser differential) — 검증하는 쪽과 처리하는 쪽이 서로 다른 필드를 신뢰하게 만드는 불일치.
비동기 권한 상승 체인 — 일반 사용자가 상태를 만들면 비동기로 관리자 봇이 그것을 처리해 flag가 나오는 구조. 전체 인과 사슬을 모델링해야 풀린다.

Web에서 구조적으로 오래 가는 것은 파서 차이, 비동기 권한 체인, 비즈니스 로직 결함처럼 여러 컴포넌트에 걸친 인과 관계를 정확히 추론해야 하는 것이다. DOM/OOB 의존은 유통기한이 있다.

조합 전략

앞서 강조했듯 단일 기법보다 크로스 분야 체인이 강하다. 예를 들어 난독화된 바이너리 → 커스텀 VM → 네트워크 프로토콜 파싱 → 웹 레이스 진입 → 비표준 힙 pwn → 제한된 syscall로 flag 읽기처럼 이질적 단계를 연쇄하면, 각 단계 성공률의 곱으로 전체가 매우 낮아진다. 이것이 결선급 문제가 자동 풀이에 저항하는 구조적 이유로 이해된다.

공정성: "인간도 못 풀게"가 목표가 아니다

anti-LLM 설계에서 가장 자주 오해되는 지점이다. 목표는 LLM을 막는 것이지 인간을 막는 것이 아니다. 좋은 교육용 CTF는 다음을 지켜야 한다.

Fail-soft — 실수 한 번에 즉시 종료(fail-hard)하지 말고, 부드럽게 실패하며 재시도 여지를 남긴다. 즉시 종료는 인간 플레이어의 학습 경험을 파괴한다.
안정적 승리 경로 — 운이 아니라 이해로 도달하는, 재현 가능한 풀이 경로가 존재해야 한다.
관측 가능한 불변식(invariant) — 플레이어가 자신이 옳은 방향인지 확인할 수 있는 관측 가능한 신호가 최소 하나는 있어야 한다.
적시 힌트 — 막혔을 때 진행을 도울 힌트 체계.
프롬프트 트랩이 핵심 난이도가 아닐 것 — 앞서 말했듯 프롬프트 인젝션은 부차적이어야 한다.

검증 절차로는 출제 전에 여러 조건(순수 LLM만 / LLM+도구 / 완전 자동화 / 인간 파일럿)으로 기준선을 평가하는 접근이 권장된다. 특히 중요한 메트릭으로 family robustness gap — 문제의 변수 이름만 바꿔도(rename) 갑자기 어려워진다면 그것은 나쁜 문제라는 것 — 이 있다. 좋은 anti-LLM 난이도는 표면적 변형이 아니라 구조적 어려움에서 와야 한다.

인접 지평: VLA 물리 레드티밍

anti-LLM CTF가 "텍스트/코드 영역에서 LLM의 한계를 겨냥"하는 것이라면, 그 인접 영역에는 언어모델 탈옥이 물리 행동으로 전이되는 새로운 공격면이 있다. 시각-언어-행동(VLA) 모델이 로봇·자율주행 같은 물리 플랫폼에 통합되면서 생기는 문제다.

핵심 통찰은 탈옥의 결과가 텍스트가 아니라 물리적 동작이라는 점이 위험을 질적으로 바꾼다는 것이다. RoboJailBench 같은 벤치마크가 이 공격면을 체계화하고 있는데(arXiv 2605.19328으로 알려진 연구), 그 요지는:

LLM/VLM에서 통하는 탈옥 기법이 체화된 로봇 정책으로 전이된다. 개념적 기만(conceptual deception)류 공격이 특정 VLA 모델에서 높은 성공률(70%대로 보고)을 보였다고 알려져 있다.
여러 공격이 데이터셋별로 상당한 성공률을 보이며, 단일 방어로 일반화되지 않는다. 두 방어 기법의 우열이 데이터셋마다 뒤집힌다는 보고가 있어, 결정적으로 강건한 방어가 아직 없다는 것이 이 연구의 결론이다.
벤치마크의 위반 카테고리는 임의 분류가 아니라 ISO 표준·규제·문서화된 사고 사례에서 도출된 것으로 알려져 있다.

일반 LLM 탈옥은 유해 텍스트 생성으로 끝나지만, VLA 탈옥은 접촉력·주변인 안전거리 같은 물리 제약을 실시간으로 우회하는 행동을 유발할 수 있다. 즉 "정상 동작 중 우발적으로 발생하는 안전 위반"과 달리, 이쪽은 의도적 적대 입력이 유도하는 위반이라는 점에서 위협 모델이 다르다.

다만 여기서도 완충이 필요하다. 보고된 공격 성공률은 특정 모델·특정 데이터셋 조건에 한정된 수치이며, 다른 VLA 아키텍처나 실제 상용 배포 환경에 그대로 일반화하기 어렵다. 실제 로봇 하드웨어에서의 재현(시뮬레이션 외)은 충분히 보고되지 않은 것으로 보인다. 이 영역은 아직 초기이며, 여기 적은 것은 확정된 결론이라기보다 주목할 만한 연구 흐름으로 받아들이는 것이 적절하다.

정리

anti-LLM CTF 설계의 요체는 다음으로 압축된다.

구조적 약점을 노려라, 환경적 약점 말고. 도구가 붙으면 사라지는 약점(DOM·OOB)에 기대지 말고, 아키텍처가 바뀌어야 사라지는 약점(상태 추적·캐리 전파)에 투자하라.
정적 읽기로 안 되고 동적 상호작용이 필요하게. 상태를 바꿔 가며 실험해야 풀리는 문제가 트랜스포머의 순차 상태 추적 약점을 정면으로 친다.
단일 기법이 아니라 체인으로. 이질적 단계의 연쇄가 성공률의 곱으로 자동 풀이를 무너뜨린다.
공정성을 잃지 마라. 목표는 LLM을 막는 것이지 인간을 막는 것이 아니다. fail-soft, 재현 가능한 승리 경로, 관측 가능한 불변식을 유지하라.

그리고 이 모든 것의 배경에는 하나의 사실이 있다. 에이전트 도구체인은 빠르게 발전하고, 환경적 sweet spot은 계속 닫힌다. 오래 살아남는 anti-LLM 난이도는 트랜스포머가 원리적으로 못 하는 계산에서 온다. 그것이 이 글이 도구 트릭보다 구조적 한계에 지면을 더 쓴 이유다.