CTF에서 Rabbit Hole은 난이도일까, 불쾌함일까?
들어가며
이 글은 2026년 8월 CCA Korea 2026 광복절 기념 세미나에서 발표한 「Rabbit Hole은 난이도일까, 불쾌함일까?」를 블로그 글로 다시 정리한 것입니다. 결론부터 말하면, Rabbit Hole은 존재 자체로 좋거나 나쁘지 않습니다. 반증할 수 있으면 난이도이고, 납득할 수 있으면 학습이며, 돌아올 수 없으면 불쾌함이라고 생각합니다.
시작은 문제를 풀다 떠오른 질문 하나였습니다. "이 경로는 정말 풀이의 일부일까, 아니면 시간을 쓰게 만들기 위한 가짜 길일까?" 최근 CTF에서 수상한 기능이나 복잡한 공격면을 파고들었는데 실제 풀이와 무관했던 경험이 반복되면서, 이 질문을 제대로 정리해 보고 싶어졌습니다.
제 경우는 메모 페이지와 봇이 있는 웹 문제였습니다. 메모 페이지에 봇까지 있으니 당연히 XSS 문제라고 생각했고, 이를 위한 체이닝과 각종 트릭을 시도했습니다. 그렇게 대회 시간 내내 XSS와 메모 페이지에서 가능한 공격만 붙잡고 있었습니다. 결과적으로 메모 페이지는 풀이와 상관이 없었고, 문제는 CSS leak 계열이었습니다. 돌아보면 "메모 + 봇 = XSS"라는 익숙한 패턴이 첫인상을 지배했고, 막힐 때마다 가설 대신 공격 방법만 바꾸고 있었습니다.
저는 같은 현상을 네 위치에서 겪었습니다. 참가자로서 문제를 풀었고, 출제자로서 YISF(한국 청소년 정보보호 페스티벌)를 비롯한 여러 대회의 문제를 만들고 운영했으며, AI Agent로 CTF 풀이를 자동화하는 연구와 동아리 교육을 운영하며 학습자가 헤매는 모습을 지켜봤습니다. 같은 "틀린 길"도 어디에 서 있느냐에 따라 전혀 다르게 보였고, 이 글은 그 네 시선을 정리한 기록입니다. 정답을 내리는 글이 아니라, 제 경험과 주변 의견을 바탕으로 한 지금의 생각이라는 점을 먼저 밝혀 둡니다.
Rabbit Hole이란 무엇인가
이 글에서 Rabbit Hole은 "그럴듯해 보이는 가설이나 길에 깊이 빠져서, 다른 가능성을 못 보고 시간을 계속 쓰는 상태"를 말합니다. 흔히 출제자가 넣은 시간 낭비용 함정으로만 이해하지만, 그렇게 정의하면 범위가 너무 좁습니다. 애매한 서버 응답, 도구의 오탐, 로컬과 원격 환경의 차이, 참가자가 한 가설에 매달리는 것도 똑같이 Rabbit Hole을 만듭니다.
비슷하게 쓰이는 세 단어를 이 글에서는 다음처럼 구분하겠습니다. 정확한 학술 정의는 아니고, 이 글에서 쓰기 위한 구분입니다.
| 용어 |
이 글에서의 의미 |
| Red Herring |
주의를 다른 곳으로 돌리기 위해 배치한 가짜 단서 |
| Decoy |
출제자가 의도적으로 만든 가짜 경로나 공격면 |
| Rabbit Hole |
참가자가 특정 가설에 실제로 깊게 빠지는 현상 |
핵심은 Decoy는 Rabbit Hole을 만들 수 있지만, 모든 Rabbit Hole이 Decoy는 아니라는 점입니다. 가짜 단서가 있어도 참가자가 곧바로 배제할 수 있다면 Rabbit Hole이 아닙니다. 반대로 출제자가 의도하지 않았더라도 참가자가 오래 빠지면 그것은 Rabbit Hole입니다.
빠지는 과정: "조금만 더 하면 될 것 같다"
Rabbit Hole에 빠지는 과정은 대체로 같은 루프를 돕니다.
- 수상한 단서를 발견한다.
- 그 단서로 유력한 가설을 세운다.
- 분석과 Exploit을 반복한다.
- 실패를 "가설은 맞고 페이로드가 틀렸다"로 해석한다.
- 더 복잡한 시도를 만들어 다시 3번으로 돌아간다.
문제는 실패 그 자체가 아닙니다. 실패를 보고도 "가설이 틀렸다"가 아니라 "거의 다 왔다"로 받아들이는 순간 빠져나오기 어려워집니다. 이 루프는 사람과 LLM이 거의 똑같이 돈다는 점에서, 뒤에서 다룰 AI 관점과도 이어집니다.
왜 지금 이 질문인가
처음 문제를 출제하던 2023~2024년에 제가 배운 "좋은 CTF 문제"의 기준은 분명했습니다. 불필요한 게싱을 줄이고, 의도하지 않은 요소를 정리하고, 기술과 아이디어로 풀이에 도달하게 하는 것입니다. 실제로 풀이에 쓰이지 않는 함수나 API, 설명 없는 Fake Flag를 넣으면 리뷰에서 "실제 풀이에 쓰이지 않는다면 제거하는 게 좋겠다"는 요청을 받았습니다.
그런데 LLM이 CTF에 들어왔습니다. 모든 문제가 자동으로 풀린다는 뜻은 아니지만, 구조가 익숙하고 소스 코드가 충분히 주어진 문제라면, LLM이 분석부터 Exploit 작성까지 걸리는 시간을 크게 줄여 줍니다. 깔끔하고 정직한 문제가 LLM에게도 쉬운 문제가 되기 시작한 것입니다.
그래서인지 최근 제가 참가한 대회에서는 "가짜 길"이 다시 보이기 시작했습니다. 취약해 보이는 미사용 기능, 정답과 무관한 공격면, LLM이 헛수고하게 만드는 경로를 일부러 넣어 LLM 풀이를 막으려는 시도(Anti-LLM)가 이야기됩니다. 모든 대회가 그렇다는 주장은 아닙니다. 다만 Decoy는 LLM만 방해하지 않고 사람도 함께 방해한다는 점이 이 글의 출발점입니다.
하나의 Rabbit Hole, 네 개의 경험
참가자: 결국 시간의 문제
참가자에게 Rabbit Hole은 기술보다 시간을 어디에 쓸지의 문제라고 생각합니다. 대회 시간과 팀 인력은 제한되어 있고, 한 가설에 30분을 쓰면 다른 가설을 볼 30분이 사라집니다. 그리고 쓴 시간이 길수록 "여기까지 했는데", "페이로드만 틀린 것 같은데" 하며 가설을 버리기가 더 어려워집니다.
여기서 참가자는 단순히 수상한 길을 파는 게 아니라, 수상해 보이는 증거를 계속 "발견"합니다. 처음 본 흔적에 계속 끌려가고, 응답이 조금만 달라져도 진전으로 오해하며, 팀 안에서 같은 가설을 여러 명이 반복 검증하기도 합니다.
그렇다고 모든 삽질이 무의미하지는 않습니다. 틀린 길에서도 왜 틀렸는지를 얻었다면, 비슷한 취약점을 구별하는 감각과 다음에 무엇부터 볼지에 대한 기준이 남습니다. 그래서 참가자에게 필요한 것은 Rabbit Hole을 피하는 능력보다, 빨리 알아채고 돌아오는 습관입니다. 이 습관은 뒤의 "빠져나오는 질문"에서 정리합니다.
출제자: 어려움과 불친절함은 다르다
출제자에게 Rabbit Hole은 난이도 설계 도구라고 생각합니다. 정답 경로를 바로 드러내지 않고, 무엇부터 볼지 고민하게 하고, 아는 기법 하나를 그대로 대입하는 풀이를 막습니다. 넣는 쪽에도 분명한 이유가 있습니다.
다만 어려운 문제와 불친절한 문제는 다릅니다.
| 어려운 문제 |
불친절한 문제 |
| 필요한 지식이 깊다 |
구분할 근거가 없다 |
| 추론 단계가 많다 |
출제자만 아는 정보가 필요하다 |
| 검증이 필요하다 |
운영 오류와 헷갈린다 |
| 실패 후에도 단서가 남는다 |
풀이 후에도 납득되지 않는다 |
출제자가 리뷰에서 보는 것은 보통 의도 풀이와 비의도 풀이인 것 같습니다. 그런데 참가자 경험을 크게 좌우하는 것은 세 번째, "풀이는 아닌데 너무 그럴듯한 길"입니다. 리뷰에서 "이 가짜 경로에 참가자가 몇 분을 쓰게 될까"를 함께 따져야 하는 이유입니다.
또 하나 갈리는 지점은 가짜 기능을 "추가"했는지, 실제 구조에서 "발생"하게 했는지입니다. 의미 없는 코드나 무관한 취약점을 억지로 끼워 넣은 문제보다, 서비스에 실제로 필요한 기능에서 자연스럽게 생긴 Rabbit Hole이 훨씬 납득됩니다. 결국 출제자가 스스로 물어야 할 것은, 이 장치가 참가자의 분석 능력을 보는지 아니면 출제자 마음 맞히기나 인내심을 보는지인 것 같습니다.
AI: 더 설득력 있게 틀리기
LLM은 그럴듯한 첫 가설을 매우 빠르게 만듭니다. 이것은 장점이지만, 틀렸을 때 비용이 커집니다. LLM은 종종 처음 세운 가설을 반증하기보다 도구 결과를 그 가설에 끼워 맞춰 해석하고, 실패하면 필터나 인코딩, 환경 탓으로 돌리며 더 복잡한 페이로드를 만듭니다. 앞에서 본 루프를 더 빠르고 더 그럴듯한 문장으로 도는 셈입니다.
그래서 AI에게 "풀어줘"만 요청하면 답 대신 근거 없는 확신만 돌아올 수 있습니다. "이 가설이 틀렸다면?", "가짜임을 확인할 가장 간단한 실험은?", "언제 이 가설을 버릴까?"를 함께 묻고, 직접 확인한 것과 추측을 나눠 적게 해야 합니다. 동시에 Rabbit Hole은 무지성 자동 풀이를 막고 사람이 중간에서 후보를 검토하고 잘라내는 역할을 다시 요구하기도 합니다. 이 부분은 AI Agent 연구 관점에서 따로 다룰 만한 주제라 여기서는 짧게만 다룹니다.
교육: 실패는 언제 학습이 되는가
교육 관점에서 목표는 학습자를 헤매지 않게 하는 것이 아닙니다. 헤맨 시간이 판단력으로 남게 하는 것입니다.
| 생산적인 실패 |
무의미한 삽질 |
| 틀린 이유를 설명할 수 있다 |
왜 틀렸는지 알 수 없다 |
| 다음 문제에 쓸 기준이 남는다 |
반복 작업만 남는다 |
| 비슷한 기술의 차이를 이해한다 |
배운 것이 "출제자 마음 맞히기"뿐이다 |
| 풀이 후 납득된다 |
정답을 봐도 납득되지 않는다 |
힌트도 같은 기준으로 볼 수 있습니다. "A 기능을 사용하세요"는 방향을 알려주지만, "현재 가설이 맞다면 어떤 응답 차이가 있어야 할까요?"는 검증 기준을 줍니다. 좋은 교육용 힌트는 어디를 더 볼지보다 어디를 그만 봐도 되는지를 알려주는 것 같습니다.
여섯 명에게 물었습니다
제 생각만으로 결론을 내리지 않기 위해, 보안 분야에서 일하거나 공부하는 여섯 분에게 같은 질문을 했습니다. "CTF에서 Rabbit Hole은 필요한 난이도일까요, 아니면 문제의 질을 떨어뜨리는 장치일까요?" 정식 설문이 아니라 익명으로 정리한 개인 의견이며, 보안 커뮤니티 전체를 대표하지 않습니다.
의견은 크게 세 방향으로 나뉘었습니다.
| 입장 |
응답 수 |
주된 근거 |
| 필요하거나 현실적으로 불가피하다 |
3 |
무지성 LLM 풀이를 막고, 사람이 후보를 검토하는 Human-in-the-loop를 만든다 |
| 조건부로 허용할 수 있다 |
2 |
얕고 검증 가능해야 하며, 실제 기능과 자연스럽게 맞물려야 한다 |
| 문제의 질을 떨어뜨린다 |
1 |
AI를 전제로 한 설계가 인간 기술 경쟁의 본질을 약화시킨다 |
찬성 쪽 의견은 Rabbit Hole이 단순한 방해가 아니라, 실제 환경처럼 여러 공격 지점을 직접 확인하게 만든다는 점을 강조했습니다. 다만 여러 답변에서 같은 단서가 반복됐습니다. 사람이 보면 합리적인 비용으로 가짜임을 판단할 수 있어야 한다는 것입니다.
가장 강한 반론도 가볍게 넘길 수 없습니다. Anti-LLM을 전제로 문제를 만드는 순간 CTF가 "AI가 낭비할 경로를 설계하는 대회"로 바뀔 수 있다는 지적입니다. Rabbit Hole 없이도 사람이 더 잘 푸는 문제는 만들 수 있지만 설계와 검수에 훨씬 많은 리소스가 들고, Decoy가 핵심 아이디어를 가리면 주객이 뒤바뀐다는 주장입니다.
입장은 갈렸지만 반복해서 나온 공통 조건이 있었습니다.
- 가짜 경로가 실제 Flag 경로보다 깊어서는 안 된다.
- Rabbit Hole임을 확신할 수 있는 단서가 있어야 한다.
- 그 단서를 확인하는 비용은 작아야 한다.
- 실제 기능과 자연스럽게 맞물려야 한다.
- 검증 과정에서 분석 경험이 남아야 한다.
특히 첫 번째, "Rabbit Hole은 실제 풀이보다 얕아야 한다"는 기준이 가장 직관적이었던 것 같습니다.
좋은 Rabbit Hole과 나쁜 Rabbit Hole
제 결론은 Rabbit Hole을 "있다/없다"로 평가하지 말고, "돌아올 수 있는가, 납득할 수 있는가"로 평가해야 한다는 것입니다. 아래 기준은 객관적 법칙이 아니라 제 경험과 여섯 분의 의견을 합친 현재의 판단입니다.
| 좋은 Rabbit Hole |
나쁜 Rabbit Hole |
| 실제 풀이보다 얕다 |
가짜 경로가 실제 풀이보다 정교하다 |
| 간단한 실험으로 가짜임을 확인할 수 있다 |
운영 오류와 구분할 수 없다 |
| 서비스 구조에 자연스럽게 존재한다 |
AI 방해만을 위해 억지로 추가됐다 |
| 다른 단서로 돌아올 수 있다 |
출제자만 아는 정보가 있어야 빠져나온다 |
| 실패해도 판단 기준이 남는다 |
시간과 토큰만 소비한다 |
| 풀이 후 납득된다 |
풀이를 봐도 이유를 알 수 없다 |
참가자가 빠져나오기 위한 질문
가설을 테스트하기 전에 성공 조건뿐 아니라 실패 조건도 정해 둡니다. 언제 포기할지 정하지 않은 시도는 실험이 아니라 기도에 가깝습니다.
- 1. 이 가설이 맞다면 무엇이 관찰되어야 하는가?
- 2. 어떤 결과가 나오면 이 가설을 포기할 것인가?
- 3. 지금 얻은 결과는 증거인가, 착시인가?
- 4. 실패 원인이 구현의 문제인가, 가설 자체의 문제인가?
좋은 참가자는 공격을 잘하는 사람만이 아니라, 틀린 가설을 빨리 접고 돌아올 수 있는 사람입니다. AI에게 일을 맡길 때도 이 질문을 그대로 프롬프트와 종료 조건으로 넘기면 됩니다.
출제자를 위한 체크리스트
Rabbit Hole을 넣기 전에 다음 여섯 가지를 확인해 볼 것을 제안합니다. 하나라도 완전히 비어 있다면, 그 Rabbit Hole은 난이도보다 불쾌함에 가까워질 가능성이 높습니다.
- 깊이: 가짜 경로가 실제 풀이보다 복잡하지 않은가?
- 가짜 확인: 가짜임을 확인할 최소 실험이 있는가?
- 돌아올 길: 다른 단서로 정답 경로에 돌아올 수 있는가?
- 비용: 사람에게 요구하는 시간이 난이도에 비해 과하지 않은가?
- 자연스러움: 문제의 기능과 세계관에 맞는가?
- 납득: 풀이를 본 참가자가 "그래서 아니었구나"라고 수긍할 수 있는가?
순서도 중요합니다. "LLM을 막는가?"보다 "사람에게 무엇을 요구하는가?"를 먼저 묻는 것입니다.
아직 정답은 없습니다
지금 CTF 출제는 쉽게 풀리지 않는 고민 앞에 있다고 생각합니다. 깔끔한 구조는 사람에게 공정하지만 LLM도 빠르게 이해하고, 복잡한 Decoy는 LLM의 비용을 올리지만 사람의 경험도 함께 나쁘게 만듭니다. 둘을 동시에 잡는 방법은 아직 없고, Rabbit Hole은 그 사이에서 나온 임시방편일 수 있습니다. 출제자가 게으르거나 악의적이어서 생기는 문제가 아니라, 환경이 바뀌면서 생긴 어려운 숙제라고 생각합니다.
그래서 제가 생각하는 균형점은 맞는 길을 무작정 숨기는 것이 아니라, 틀린 길을 검증하고 돌아올 수 있게 만드는 것입니다. 단서가 너무 노골적인 문제는 긴장감이 없고, 함정만 많은 문제는 불쾌합니다. 목표는 "AI도 못 풀게 만들기"가 아니라 사람이 납득할 수 있는 검증 경로를 남기는 것입니다.
더 큰 변화도 보입니다. 앞으로의 CTF는 취약점 발견과 Exploit 작성뿐 아니라, AI가 내놓은 후보 중 무엇을 믿을지 고르고 틀린 가설을 멈추는 능력까지 평가하게 될지도 모릅니다. 그것이 CTF 실력의 확장인지, 전혀 다른 게임의 시작인지는 아직 모르겠습니다.
정리하면 이렇습니다. Rabbit Hole은 반증할 수 있으면 난이도이고, 납득할 수 있으면 학습이며, 돌아올 수 없으면 불쾌함입니다. 정답이 없는 질문인 만큼 네 가지 관점과 여러 사람의 의견을 모아 제 생각을 정리해 보았습니다. 여러분은 이 논제를 어떻게 바라보시나요? 다양한 분들과 이 이야기를 더 나눠 보고 싶습니다.