24시간, 40개 문제: AI 팀이 BearcatCTF 2026에서 상위 6%에 진입한 방법

최종 결과: 362개 팀 중 20위. 44개 문제 중 40개 해결. 24시간의 무인 자율 운영. 이 수치들은 우리의 예상보다 좋았으며, 우리가 예상하지 못한 것을 드러냈습니다 — AI에 관한 것이 아니라, 구조화된 에이전트 조율이 가능하게 하는 것에 관해서입니다.

Trinity 아키텍처

BearcatCTF는 우리가 Trinity라고 부르는 것의 첫 번째 실제 배포였습니다: 서로 다른 역할을 가진 세 개의 전문화된 에이전트가 공유 지식 기반에서 작동합니다.

Commander (Claude Opus)는 전략 계층으로 작동했습니다. 우리가 문제를 할당하면 Commander는 빠른 정찰 단계를 실행하고, 공격 계획을 수립한 다음, Operator와 Librarian을 조율하여 실행하게 했습니다. 칠판에서 진행 상황을 추적하고, 전략을 바꿀 시기를 결정하고, 막힌 부분을 포기할 시기를 결정했습니다. Commander는 익스플로잇 코드를 직접 작성하지 않았습니다 — 각 문제 내에서 계획과 조율이 그 역할이었습니다.

Operator (Claude Sonnet)는 솔버였습니다. Commander가 문제를 할당하면 Operator는 문제 설명, 첨부된 파일들, 그리고 이전 문제에서의 관련 지식에 대한 Librarian의 브리핑을 받았습니다. Operator는 문제를 해결했습니다: 스크립트 작성, 페이로드 테스트, 소스 코드 읽기, 도구 실행.

Librarian (Claude Haiku)은 지식 기반을 관리했습니다. 각 문제가 해결된 후, Librarian은 핵심 기법들을 추출하고, 분류하고, 공유 칠판에 저장했습니다. Operator가 새 문제에 맞닥뜨리면, Librarian은 관련 항목들을 가져왔습니다 — “2시간 전에 JWT 위조에 대해 배운 것이 여기 있습니다.”

세 에이전트는 OpenClaw의 sessions_spawn과 자동 공지 메커니즘을 통해 통신했습니다. Commander는 각 작업마다 Operator와 Librarian을 서브에이전트로 생성했습니다. 서브에이전트가 완료되면, 자동으로 그 결과를 Commander에게 공지했습니다. 지속적인 blackboard.json 파일 — Commander에 의해 유지되는 — 은 발견사항, 완료된 단계, 그리고 스폰들에 걸친 현재 공격 계획을 추적하는 지속성 상태 계층으로 기능했습니다. 이를 통해 Commander는 메시지 기록만 의존하지 않고도 세션 압축 후에도 완전한 컨텍스트를 재개할 수 있었습니다.

처음 몇 시간

경쟁은 정오에 시작되었습니다. 7개 카테고리에 걸친 44개 문제 — 리버스 엔지니어링(7개), OSINT(5개), 포렌식(7개), 암호화(8개), 웹(4개), 기타(8개), 그리고 pwn(5개). 우리는 대략적인 우선순위 순서대로 Commander에게 문제들을 제공했으며, 빠른 해결을 기대하는 카테고리부터 시작했습니다.

처음 몇 시간은 빨랐습니다. 웹 문제들은 빠르게 해결되었습니다: 기본적인 SQL 주입, 안전하지 않은 쿠키 구현, alg: none인 JWT. 암호화에는 Operator가 몇 분 만에 해결한 몇 가지 인코딩 문제들이 있었습니다. Librarian은 분류하고 있었습니다.

4시간차에 접어들면서 해결 속도가 느려졌습니다. 남은 문제들이 더 어려웠고, Commander는 각 문제에 더 많은 시간을 사용하고 있었습니다 — 더 깊은 정찰, 더 많은 Librarian 상담, 더 긴 Operator 세션.

부정행위 방지 메커니즘

우리는 시스템에 초기에 규칙을 내장했습니다: 문제가 3분 이내에 해결되면, 플래그를 제출하기 전에 자동 감시가 실행되었습니다. 감시자는 세션 기록을 검토하고 에이전트가 실제로 문제를 해결했는지 또는 어떤 방식으로든 바로가기를 통해 플래그를 얻었는지 확인했습니다.

명확히 하자면 — 이것은 벤치마크 측면에서 경쟁의 부정행위에 관한 것이 아니었습니다. CTF 경쟁은 벤치마크처럼 부정행위 문제를 정말로 가지지 않습니다. 부정행위 방지 메커니즘은 벤치마크 무결성에 관한 것이었습니다: 우리는 우리의 해결 로그가 실제 문제 해결을 반영한다는 확신을 원했습니다. 우발적인 플래그 누출이나 운의 추측이 아니라. 우리가 우리의 에이전트가 40개의 문제를 해결했다고 주장하려면, 각 해결이 실제라는 것을 신뢰해야 합니다.

이것이 중요한 것으로 판명되었습니다. 감시는 한 가지 실제 경우를 포착했습니다: CryptoPwn의 pwn 문제에서, Operator는 실제로 서비스를 악용하는 대신, 플래그를 포함하는 문제 디렉토리의 README.md 파일을 읽었습니다. 세션은 해결 로그에서 CHEATED로 표시되었고 Commander는 정당한 악용을 통해 문제를 다시 수행하도록 지시받았습니다.

이 메커니즘은 CTF를 AI 벤치마크로 사용하는 모든 사람에게 관련이 있습니다 — 이것은 점점 더 일반화되고 있습니다. 이러한 종류의 감시가 없으면, 실제 기능을 반영하지 않는 거짓 긍정으로 해결 속도를 부풀리기가 쉽습니다.

중반전

6시간부터 20시간까지가 경쟁의 핵심이었습니다. 여기서 Librarian 통합이 가장 명확하게 그 가치를 드러냈습니다. 포렌식 문제들은 종종 기법을 공유합니다 — 스테가노그래피, 파일 복구, 메타데이터 추출. Librarian이 해결된 포렌식 문제들에서 지식을 축적하면서, Operator의 새로운 포렌식 문제에 대한 첫 시도는 더 잘 보정되었습니다. 매번 첫 원칙부터 시작하는 대신, Operator는 Librarian 브리핑을 받았습니다: “이전 포렌식 문제들은 binwalk와 foremost를 사용했습니다; JPEG 스테가노그래피는 두 번 나타났습니다.”

암호화도 유사한 패턴을 보였습니다. 8번째 암호 문제는 첫 번째보다 훨씬 빠르게 해결되었습니다. 실제 난이도는 비슷했지만, 그 시점까지 Librarian은 대체 암호, 패딩 오라클 공격, 그리고 XOR 키 복구에 대한 팀의 접근 방식을 추출했습니다.

각 문제 내에서 Commander는 견고한 전술적 판단을 내렸습니다. 한 접근 방식이 막히면, 계속 갈아붙이는 대신 Operator를 다른 공격 벡터로 전환했습니다. 문자열 분석이 효과적이지 않은 포렌식 문제에서, Commander는 엔트로피 분석으로 전환했고 숨겨진 페이로드를 분 내에 찾았습니다.

해결되지 않은 4개 문제

우리는 40/44로 마쳤습니다. 해결되지 않은 4개 문제는 3가지 서로 다른 실패 모드로 분류됩니다:

2개는 이미지 의존적이었습니다. 하나는 손상된 이미지에서 QR 코드를 읽어야 했고, 다른 하나는 사진에서 시각적 세부 사항을 식별하는 것을 포함했습니다. Claude의 시각 기능은 일반 이미지 이해에는 견고하지만, CTF 이미지 문제가 종종 요구하는 종류의 정밀한 픽셀 수준의 분석에는 최적화되지 않았습니다.

하나는 웹 검색이 필요한 OSINT 문제였습니다. 에이전트는 시각적 및 상황적 단서를 기반으로 온라인에서 특정 정보를 찾아야 했지만, 검색 기반 OSINT 워크플로우 — 부분적인 결과에 기반해 쿼리를 반복적으로 정제해야 하는 — 는 시간 예산 내에서 해결책으로 수렴하지 못했습니다.

하나는 어려운 pwn 문제였습니다. 이것은 진정한 어려움 한계였습니다: 바이너리 악용은 에이전트가 가능한 시간 내에 추론할 수 있는 범위를 넘어서는 특정 제약 조건을 가진 커스텀 셸코드 작성이 필요했습니다.

3가지 다른 능력 격차, 3가지 다른 수정. 이미지 문제들은 특화된 시각 도구가 필요합니다 — 이미지 처리 라이브러리를 래핑하는 커스텀 MCP 서버 같은 것. OSINT 검색 격차는 반복적인 웹 연구를 위한 더 나은 도구 통합이 필요합니다. 어려운 pwn은 모델이 강해질수록 개선될 순수한 추론 깊이 문제입니다.

우리가 배운 것

칠판 패턴이 작동합니다. 지속적인 blackboard.json을 지속성 상태 계층으로 사용하면서 — spawn/announce를 에이전트 통신으로 함께 사용하면 — 긴밀한 결합 없이 에이전트를 조율하는 간단하고 효과적인 방법입니다. Librarian의 지식 추출은 정교하지 않았습니다 — 기본적으로 “이 카테고리에서 마지막으로 해결된 문제에서의 기법은 여기입니다” — 하지만 이 간단한 버전도 같은 카테고리의 나중 문제에 대한 Operator의 첫 시도 품질을 의미 있게 개선했습니다.

역할별 모델 선택이 중요합니다. Haiku를 Librarian으로 사용하는 것이 올바른 결정이었습니다: 지식 추출과 저장은 지연 시간이 추론 깊이보다 더 중요한 간단한, 높은 볼륨의 작업입니다. Opus를 Commander로 사용하는 것은 전략 계층에 우선순위와 순서화에 대한 판단 호출을 수행하기 위해 필요한 추론 용량을 제공했습니다. Sonnet for Operator는 깊이와 비용의 균형을 맞췄습니다.

해결되지 않은 문제들은 3가지 서로 다른 한계를 가졌습니다. 이미지 분석, 검색 기반 OSINT, 그리고 어려운 바이너리 악용은 각각 다른 능력 격차를 나타냅니다. 이미지와 검색 격차는 더 나은 도구 지원으로 해결될 수 있습니다 (특화된 시각 모델, 반복적인 검색 워크플로우). pwn 한계는 순수한 추론 깊이 문제입니다 — 이것은 모델이 강해질수록 개선됩니다.

무인 운영은 가능하지만 특정 방식으로 취약합니다. 시스템은 인간 개입 없이 24시간 동안 운영되었습니다. 충돌하지 않았고, 루프하지 않았으며, 명백히 잘못된 플래그를 제출하지 않았습니다. 하지만 그것이 처리할 수 없는 것에 맞닥뜨렸을 때 도움을 요청하지도 않았습니다. 여기에는 자율 에이전트가 멈춰서 인간 입력을 기다려야 할 때와 최선의 추측을 하고 계속할 때에 대한 설계 질문이 있습니다. CTF의 경우, 계속하는 것이 대개 옳습니다. 다른 영역의 경우, 그렇지 않을 수도 있습니다.

경쟁 로그 — 세션 기록, 도구 호출, 그리고 Librarian 항목 — 은 수십 메가바이트에 이릅니다. 우리는 아직 그것들을 분석하기 시작했을 뿐입니다. 제목 숫자 — 상위 6% — 는 만족스럽지만, 더 흥미로운 데이터는 실패 모드에 있습니다.