저는 두 모델 모두에게 동일한 프롬프트를 제공했습니다. 파이썬(Python), FastAPI, 비동기 수집(async ingestion), 영구 저장소(persistent storage), WebSockets, 그리고 인터랙티브 Three.js 구체를 사용하여 실시간 사이버 위협 인텔리전스 플랫폼을 구축하는 것이었습니다. 어려운 요구사항은 데이터 무결성이었습니다. 이 플랫폼은 실제 인텔리전스 소스를 사용하고, 출처와 타임스탬프를 보존하며, 관찰(observation)과 추론(inference)을 구별하고, 구체를 바쁘게 보이게 하기 위해 공격이나 목적지를 지어내지 않아야 했습니다.
두 개의 제출된 코드베이스를 검토한 결과, 27B 모델의 제출물이 제가 수리하여 기반으로 삼고 싶은 것입니다. 어느 쪽도 전체 프롬프트를 충족시키지는 못했습니다. Flash Next는 더 많은 기능을 시도했고 테스트도 더 많이 포함했지만, 핵심 데이터 계약(core data contracts) 몇 가지가 깨졌습니다. 이것은 각 모델별로 저장된 제출물 하나이며, 모델 이름은 이 실행에 사용된 레이블에서 가져왔습니다. 후속 검토와 이 글 작성은 AI의 도움을 받았습니다. 이것은 전체 모델 역량에 대한 통제된 연구가 아니라 아티팩트 비교입니다.
실제 과제가 요구한 것:
두 모델 모두 Cloudflare Radar, GreyNoise, DShield, ThreatFox 및 분산형 하니팟 네트워크를 포함한 소스 통합을 요청받았습니다. 데이터를 가져오는 것을 넘어, 다음 요구사항들이 포함되었습니다:
- 정규화(Normalization), 중복 제거(deduplication), IP 지리 위치 파악(IP geolocation), 분류(classification), 그리고 구성 가능한 위험 점수 산정(configurable risk scoring).
- 상관관계 분석(Correlation), 이력 저장소(historical storage), 이상 탐지(anomaly detection), 타임라인, 지리적 필터, 및 조사 뷰(investigation views).
- 실제 출처와 목적지에 대한 증거가 뒷받침되는 경우에만 애니메이션 궤적을 표시하는 것.
- 복원력 있는 통합(Resilient integrations), 속도 제한 처리(rate-limit handling), 구조화된 로깅(structured logging), 테스트, 벤치마킹, 그리고 배포.
이것은 조각들이 서로 일치하는지 여부를 확인하는 유용한 테스트입니다. 소스 어댑터, 데이터베이스, 구체는 모두 존재할 수 있지만, 애플리케이션이 근본적인 관찰을 잘못 표현하고 있을 수도 있습니다.
한눈에 보는 결과
Qwen 3.8 27B Flash Next 125B
기존 pytest 스위트: 16개 통과, 34개 통과
JavaScript 구문 검사: 통과, 통과
다운로드된 DShield 샘플: 파싱 완료 5/5개의 top-IP 레코드, 파싱 완료 20개의 서브넷 행, 하지만 잘못된 카운트 열을 읽음
ThreatFox 문서화된 응답: 폐기됨, 잘못된 요청 선택자와 부정확한 IOC 정규화
Cloudflare Radar 레거시 엔드포인트: 문서화된 국가별 top API와의 요청/파서 불일치, WebSocket 백프레셔 발생 가능, 수집 방지 가능
전체 프롬프트 충족: 예, 아니요
DShield 통합은 서로 다른 피드를 사용하므로, 레코드 개수는 직접 비교할 수 있는 측정치가 아닙니다. 하나는 top-IP 관측치를 소비하고; 다른 하나는 서브넷 집계를 소비합니다. 가장 중요했던 실패 지점들은 다음과 같습니다.
- Flash Next는 모든 레코드를 폐기한 후에도 성공적인 소스 실행을 보고할 수 있습니다. 그 Feodo 어댑터는 c2_server_ip, c2_server_port, 그리고 bot과 같은 CSV 필드를 예상했습니다. 다운로드된 공개 CSV는 dst_ip, dst_port, 그리고 malware를 사용했습니다. 이 다운로드된 본문을 수정되지 않은 파서를 통해 재실행한 결과:
텍스트 입력 레코드: 5개, 파싱된 이벤트: 0개, 반환 오류: 없음
검색된 샘플 자체에 더 오래된 업데이트 날짜가 포함되어 있었기 때문에, 이는 현재의 봇넷 활동 증거라기보다는 파서 불일치의 증거였습니다. 애플리케이션은 여전히 해당 스키마를 인식하거나 명시적인 비호환성을 보고해야 했습니다.
- DShield 어댑터는 서브넷 접두사를 활동 카운트처럼 처리했습니다. 피드는 열 3을 서브넷 접두사로, 열 4를 스캔을 보고하는 대상의 수로 정의합니다. 첫 번째 다운로드된 행에서 이 값들은 각각 24와 344였습니다. 정규화된 카운트는 24였습니다. 그 오류는 레이블을 넘어 전파됩니다: 카운트 피드는 통계 및 볼륨 기반 점수 산정에 사용됩니다. 어댑터는 또한 시작 주소로 서브넷을 나타내는데, 이는 해당 개별 주소가 누군가를 공격했다는 증거가 아닙니다. DShield 피드에는 열 정의가 포함되어 있습니다.
- 두 구현체 모두 ThreatFox를 잘못 처리했습니다.
27B는 올바른 recent-IOC 요청을 보냈지만, ip, threat, date와 같은 예상 응답 필드가 필요했습니다. 문서화된 IOC 스키마를 사용한 테스트 케이스(fixture)는 last-success 타임스탬프를 설정하면서도 기록이 0건으로 나왔습니다. Flash Next는 다음과 같이 전송했습니다: json {"request": "fetch_last_24h"}. 문서화된 recent-IOC 작업은 다음을 사용합니다: json {"query": "get_iocs", "days": 1}. 또한, 이 과정에서 도메인 IOC를 소스 IP로 간주하여 원본 타임스탬프를 손실했습니다. 이는 ThreatFox 계약에 대한 요청/파서 검사였으며, 인증된 실시간 통합 테스트는 아니었습니다. 4. 분석 기능은 새로운 출처 증거 없이도 신뢰도를 조작하거나 활동량을 부풀릴 수 있습니다. 27B는 동일한 IP를 동일한 출처에서 두 번 본 후 보강(corroboration) 보너스를 부여했습니다. 서로 다른 중복 제거 버킷에 있는 두 개의 DShield 관측치가 각각 9.2점, 그리고 21.2점을 기록했으며, 둘 다 단 하나의 고유 출처만 존재했음에도 불구하고 두 번째 항목은 '보강됨(corroborated)'으로 표시되었습니다. Flash Next는 스냅샷 카운트를 합산했습니다. 동일한 count=100 관측치를 재처리했을 때 count=200이 나왔습니다. 이는 반복적인 수집을 마치 추가적인 출처 활동인 것처럼 측정합니다. 또한, 비활동 상태에서 플러시(flush)를 할 때 위협 이벤트가 없었음에도 불구하고 타임라인 카운트 1을 삽입했습니다. 두 프로젝트 모두에서 프로덕션 합성-위협 생성기(synthetic-threat generator)는 발견되지 않았지만, 이 스케줄러 틱(scheduler tick)은 여전히 위협 활동으로 제시되는 차트를 오염시킵니다. 5. 코드에는 약속된 기능들이 존재했지만 정상적인 실행 경로를 통해 작동할 수 없는 경우도 있었습니다. Flash Next의 교차 출처 상관관계 분석(cross-source correlation)은 현재 배치만 검토했습니다. 일반적인 폴링(polling) 프로세스는 한 번에 하나의 어댑터만 처리합니다. 동일한 IP를 두 개의 분리된 출처 배치로 전송했을 때, 두 기록 모두 저장되었음에도 불구하고 아무런 상관관계도 생성되지 않았습니다. Flash Next의 GreyNoise 대체 기능은 파이프라인이 (events, error)를 기대하는 곳에 빈 리스트를 반환했습니다. 비어 있는 대체 기능은 언패킹 예외(unpacking exception)를 유발했습니다. 더 일반적으로는, 예상치 못한 어댑터 예외가 출처 루프에서 탈출했으며; 어떤 감독자(supervisor)도 해당 폴러를 재시작하지 않았고, 상태 확인 엔드포인트(health endpoint)는 작업의 생존성(liveness)을 확인하지 않았습니다.
27B는 독립적인 수집 예외 처리(isolated ingestion exceptions)는 더 잘했지만, 독립적인 이상 징후 기록도 놓쳤습니다. 동일한 창에서 두 국가/카테고리 경보가 발생했을 때 두 개의 브로드캐스트만 생성되고 단 하나의 저장된 경보만 남았습니다. 6. 프론트엔드에도 정확성 및 보안 문제가 있었습니다. 선택된 실제 프론트엔드 함수를 실행하는 Node 프로브는 이러한 Flash Next 문제를 재현했습니다: 항목이 하나인 피드를 두 번 다시 그리는 과정에서 백킹 히스토리(backing history)가 1개에서 2개, 그리고 4개로 증가했습니다. 국가 필터는 US 부트스트랩 기록을 거부했지만, 필드 이름이 달랐기 때문에 동등한 라이브 기록은 허용했습니다. 이상 징후 메시지가 msg.data 대신 msg.data.data를 클라이언트가 읽었기 때문에 TypeError를 발생시켰습니다. 피드 제어 마크업(Feed-controlled markup)이 이스케이프 처리 없이 innerHTML에 도달했습니다. 이는 주입 싱크(injection sink)이며, 브라우저 스크립트 실행 익스플로잇은 시도되지 않았습니다. 27B는 일반적으로 외부 값에 textContent를 사용했는데, 이것이 더 나은 선택이었습니다. 여전히 재연결 스냅샷을 재생할 때 이벤트를 중복했습니다. 그리고 저장된 신뢰도 구분이 이벤트 UI에서 명확하게 노출되지 않았습니다. 두 WebSocket 허브 모두 마감 시간(deadline) 없이 클라이언트 전송을 기다렸습니다. 의도적으로 차단된 가짜 클라이언트는 외부 테스트 타임아웃이 취소될 때까지 계속 브로드캐스팅했습니다. 수집 과정이 브로드캐스팅을 기다리기 때문에, 느린 뷰어는 두 프로젝트 모두에서 데이터 파이프라인을 정지시킬 수 있습니다.
왜 여전히 27B 제출본을 선호하는가
27B는 앱 팩토리(app factory), 중앙 집중식 재시도 및 회로 차단(circuit breaking), JSON 파일 로깅, 이벤트 보존, 만료 기한이 있는 영구 지리 위치 캐시(persistent geolocation cache with expiry), README, 그리고 실시간 벤치마크 진입점(live benchmark entrypoint)을 제공했습니다. 이러한 선택들이 이를 더 일관성 있는 복구 기준선(repair baseline)으로 만들었습니다. Flash Next는 유용한 아이디어들을 가지고 있었습니다: 명시적인 신뢰도 클래스, 지리적 정밀도 메타데이터, 배치형 지리 위치 정보, 선택적 오프라인 GeoIP, 소스 실행 저장소, 그리고 더 풍부한 필터들입니다. 하지만 제공자 응답(provider responses)부터 프론트엔드 메시지 엔벨로프(frontend message envelopes)에 이르기까지 여러 인터페이스들이 서로 불일치했습니다. 어느 쪽도 작동하는 현재 Radar 통합을 시연하지 못했습니다.
27B는 Cloudflare의 릴리스 노트에 따르면 2023년 8월 이후 데이터 수신이 중단된 차원 없는(dimensionless) L3 시계열 엔드포인트를 사용했습니다. Flash Next의 요청 및 파서는 문서화된 국가별 상위 계약과 달랐습니다. 토큰 인증을 거친 Radar 검사는 수행되지 않았습니다. 두 모델 모두 배포되어 지속적으로 운영되는 관측소를 입증하지 못했습니다. 또한, 둘 다 검증된 글로벌 커버리지, 보정된 이상 감지(anomaly detection), 신뢰할 수 있는 실제 출처의 공격 궤적 증거가 부족했습니다. 보고서는 다음과 같이 점수를 매겼습니다: 카테고리 | 가중치 | 27B | Flash Next | 통합 정확성 및 실시간 커버리지 | 20 | 8 | 5 | 과학적 정확성 및 출처(provenance) | 20 | 10 | 6 | 신뢰성 및 리소스 제어 | 15 | 9 | 5 | 아키텍처 및 유지보수성 | 10 | 7 | 6 | 대시보드 동작 및 조사 | 10 | 6 | 6 | 저장소, 상관관계 및 이상 품질 | 10 | 5 | 4 | 테스트 및 검증 증거 | 10 | 5 | 6 | 배포 및 재현성 | 5 | 2 | 1 | 총점 | 100 | 52 | 39 이 점수들은 선언된 평가 기준(rubric)에 따른 주관적인 검토 점수이며, 모델 벤치마크 점수나 생산 준비도 비율이 아닙니다. 통합 및 증거 무결성(evidence integrity)은 프롬프트가 신뢰할 수 있는 정보(trustworthy intelligence)를 명시적으로 우선순위에 두었기 때문에 40점을 차지합니다. 테스트된 내용과 그렇지 않은 내용 검토는 수정되지 않은 테스트 스위트, JavaScript 구문 검사, 초점화된 Python/Node 프로브, 다운로드 피드 파서 검사를 모두 실행했습니다. 제공업체 계약은 기본 문서와 비교되었습니다. 테스트 픽스처(Test fixtures)는 격리된 환경에 유지되었으며, 비교를 위해 애플리케이션 소스를 수정하지 않았습니다. 저장소 전용으로 작은 벤치마크가 진행되었으며, 임시 SQLite 데이터베이스에 500개의 고유 직렬 쓰기 쌍별 테스트를 세 번 수행했습니다: 저장소 전용 측정 | 27B | Flash Next | 500개 쓰기에 대한 중앙값 시간 | 211.10 ms | 390.77 ms 27B가 이 좁은 워크로드에서 약 1.85배 더 빨랐습니다. Flash Next의 풍부한 upsert는 추가적인 조회 및 잠금(lock)을 수행합니다. 테스트에서는 HTTP, 지리 위치 정보(geolocation), 전체 파이프라인, WebSocket 소비자, 브라우저 렌더링은 제외되었으며, 캐시/순서 효과가 제어되지 않았습니다.
모델 추론 속도나 지속적인 실시간 수집 용량에 대해서는 언급하지 않았습니다. 브라우저/WebGL 승인 실행, 인증된 키 제공자 테스트, 프로덕션 배포 또는 장기간의 부하 테스트(soak)가 없었습니다. 두 스위트 모두 새로 잠긴 설치 환경 대신 동일하게 설치된 Python 환경을 사용했습니다. 생성 설정, 도구 예산, 토큰 사용량, 비용, 하드웨어 및 원래 에이전트 추적 기록은 이번 검토에서 사용할 수 없었습니다. 따라서 저는 동등한 생성 조건을 확립하거나 이 두 출력 결과를 바탕으로 전체 모델 품질을 일반화할 수 없습니다. 이 프로젝트의 경우, 27B를 먼저 수정하고 Flash Next의 더 나은 도메인 개념을 선택적으로 재사용하겠습니다. 제 평가를 가장 많이 바꾼 결과는 두 테스트 스위트가 통과했음에도 불구하고 독립적인 검사에서는 여전히 조용한 데이터 손실(silent data loss)과 잘못된 관찰 의미론(incorrect observation semantics)이 발견되었다는 점입니다. 이것들은 제가 어느 시스템에 작동하는 지능 통합에 대한 신용을 주기 전에 다음 비교에 추가할 검사들입니다. 제출자: /u/Character-Apple-8471 [링크] [댓글]