개인 자격으로 참가했고, 확인한 대회 규정상 AI 사용도 허용됐다. 공식 CTFd 프로필에는 26위와 5,701점이 기록되어 있다. 공식 결과는 local tracker 집계와 별개다.
공식 CTFd 결과: 26위 · 5,701점
참가 형태 / 규정: 개인 참가 · AI 사용 허용
로컬 tracker: challenge 110개 · 제출 결과 기록 107건 · 로컬 correct 101건 · incorrect 6건
Event)
총무성 전국형 CTF는 제한된 시간 안에 여러 문제를 수집하고 풀어 검증한 뒤 제출하는 운영 문제이기도 했다. 이 글은 challenge answer write-up이 아니라 파이프라인 운영 회고다. 공식 점수와 local tracker, 관찰된 event trace와 확인할 수 없는 부분을 구분한다.
Result)
보존된 tracker에는 challenge 110개가 있다. 제출 결과가 기록된 행은 107개다. 이 중 101개가 correct, 6개가 incorrect이며, 나머지 3개는 결과가 기록되지 않았다. 107건은 자동화된 해결 수가 아니다.
tracker에서 accepted로 기록된 101개 항목의 점수를 단순 합산하면 5,900점이다. 이 값은 official score가 아니다. CTFd 프로필의 5,701점과 199점 차이가 있지만, 현재 evidence만으로는 원인을 확정할 수 없다. 두 숫자는 별도로 다룬다.
Approach)
로컬에 남은 기록에는 challenge 110개와, 20개 ID에 걸친 attachment 21개가 있다. 세션 로그에는 local advisor/model과 remote API를 함께 사용한 흔적이 있다. 작업 병렬화 지시와 별도 submission worker도 확인된다.
다만 challenge별 worker/model 배정, 사람의 개입 시점, retry 횟수는 결과 기록과 연결되어 있지 않다.
저자 제공 event capture에는 대회 중간 CTFd 프로필(29위·4,401점)이 기록되어 있다. 같은 캡처의 OMP 화면과 개별 challenge 이력은 challenge별 운영 내용이 노출되어 공개하지 않았다. 약 13:53 JST의 더 이른 캡처에는 302위·1점이 보였으며, 이는 그림 1의 최종 결과가 아닌 대회 초반 상태다.
아래 보충 timeline은 보존된 control-plane event와 intervention record를 재구성했다. 시간 흐름을 보완하는 파생 자료이며, OMP 화면이나 실제 풀이 시간 측정치는 아니다.
Problem)
Tracker 숫자만으로 pipeline 상태를 알 수는 없다. owner 필드는 비어 있고 challenge별 시작·종료 시각도 충분히 남아 있지 않다. HTTP 요청 성공 여부와 challenge 정답 판정은 별도로 봐야 한다.
예를 들어 queue state가 복제되거나 제출 결과 반영이 늦으면 중복 작업이나 종료된 작업의 재실행이 생길 수 있다. 다만 보존된 기록만으로 실제 사례별 원인까지 복원할 수는 없다.
Bottleneck)
보존된 기록에서 먼저 드러나는 병목은 모델 호출보다 제어면이다.
- Ownership과 state: challenge별 owner/lease가 보존되지 않아 중복 작업과 실제 책임 경계를 셀 수 없다.
- Artifact intake: tracker의 목록과 내려받은 파일이 항상 같은 상태라고 가정할 수 없다. 파일 hash와 provenance를 함께 보존하는 절차가 필요하다.
- Verification: 제출 전에 결과의 형식과 의미를 독립적으로 확인해야 한다.
- Observability: challenge ID 단위의 event log가 있어야 model 성능과 control-plane 지연을 분리할 수 있다.
- Close control: authoritative cutoff와 공식 결과 export가 없으면 늦은 작업을 안전하게 차단하고 tracker를 정산하기 어렵다.
Local vs API)
challenge별 route 기록이 없어 local compute가 API 호출을 얼마나 줄였는지, 사람의 개입이 몇 건이었는지 계산할 수 없다. 정확한 자동화율이나 절감액도 제시하지 않는다.
Architecture v2)
다음 run에서는 challenge ID를 기준으로 단일 canonical queue와 active lease를 둔다. Intake에서 파일 hash와 type을 확인한 뒤 deterministic local analysis부터 한다. 필요한 경우에만 health-checked local model과 명시된 budget의 API route로 escalation한다. 후보는 private evidence store에 보관하고, independent verifier를 통과한 결과만 single submission broker가 한 번 제출한다. cutoff가 오면 broker를 닫고, 공식 score export와 local tracker를 따로 대조한다.
이 설계는 이번 run의 구현 설명이 아니다. 왼쪽 V1은 보존된 event evidence에서 재구성한 경계일 뿐, 완전한 구현 명세가 아니다. 오른쪽 V2는 다음 run을 위한 제안이다.
Retrospective)
다음에는 worker를 늘리기 전에 challenge별 실행 기록과 제출 상태부터 남기겠다.
Evidence / Notes)
- 공식 최종 rank와 score는 Figure 1의 CTFd screenshot에서 확인한다.
- local tracker에는 challenge 110개, 제출 결과 107건(correct 101, incorrect 6, 미기록 3), nominal 5,900점이 기록되어 있다. CTFd 5,701점과 별도이며 199점 차이의 원인은 확인되지 않았다.
- 그림 4는 저자 제공 event capture에서 CTFd 프로필만 남긴 crop이다(29위·4,401점). OMP 화면과 개별 challenge 이력은 공개하지 않았다. 약 13:53 JST의 302위·1점은 더 이른 상태이며 최종 결과가 아니다.
- 보충 timeline은 보존된 event에서 재구성한 파생 자료다. Figure 5의 V1도 retained evidence에서 재구성했으며, V2는 제안이다.
- challenge별 model route와 human-intervention telemetry는 불완전하다. 정확한 automation percentage는 주장하지 않는다.