KDD Cup 700팀 데이터 에이전트, Docker 심사 지연

AI 요약

• 무슨 일: KDD Cup 2026 Data Agents 트랙이 700개 이상 팀 참여와 Docker 제출 심사로 Phase 1 결과 일정을 조정했습니다.
  • 공식 공지는 일부 제출 이미지에서 의심스러운 악성 또는 무단 행동이 관찰돼 compliance check와 technical audit이 필요하다고 설명합니다.
• 평가 구조: Phase 1은 약 60개 A-board와 약 320개 B-board hidden tasks를 나누고, 실행 시간은 각각 2시간과 12시간입니다.
• 개발자 영향: 데이터 에이전트 평가는 모델 점수보다 Docker 격리, 외부 인터넷 차단, 모델 주입, 출력 보존이 먼저 제품 요구사항이 됩니다.
• 주의점: 대회는 Qwen3.5-35B-A3B를 평가 시 주입하므로, 참가팀의 로컬 개발 모델 성능과 공식 점수는 분리해서 봐야 합니다.

KDD Cup 2026의 Data Agents for Complex Data Analysis 트랙이 에이전트 평가의 현실적인 병목을 드러냈습니다. 공식 사이트는 이 대회를 “autonomous AI agents”가 복합 분석 질문을 분해하고, 여러 데이터 소스 위에서 다단계 추론을 수행해 정확한 답을 내는 경진대회로 설명합니다. 그런데 5월 말 공지의 초점은 새 모델 점수나 우승 후보가 아니라 제출량, Docker 이미지, compliance check, technical audit입니다. 700개 이상 팀이 들어오자 평가 인프라와 보안 심사가 대회 일정의 일부가 됐습니다.

공식 Rules와 뉴스 공지를 함께 보면 이 대회는 단순한 리더보드가 아닙니다. 참가팀은 하나의 Docker 이미지로 전체 task 디렉터리를 순회하고, 각 task_<id>의 입력을 읽은 뒤 /output/task_<id>/prediction.csv를 써야 합니다. 평가 환경은 linux/amd64를 전제로 하고, 공식 평가 중에는 환경 변수로 주입된 MODEL_API_URL과 key를 통해 Qwen3.5-35B-A3B를 사용합니다. 개발 중에는 OpenAI, Anthropic, 로컬 모델을 써도 되지만, 공식 채점에서는 주최 측이 통일한 모델로 자동 전환돼야 합니다.

이 설계는 데이터 에이전트 벤치마크가 무엇을 보려 하는지 보여줍니다. 문제는 “어떤 LLM이 더 똑똑한가”가 아닙니다. 같은 모델 조건에서 누가 더 안정적으로 데이터를 찾고, 테이블과 문서를 해석하고, 필요한 Python·SQL 단계를 짜고, 중간 실패를 복구하고, 제한 시간 안에 prediction.csv를 남기는가입니다. 모델을 고정하면 orchestration, retrieval, parsing, timeout control, output validation의 차이가 점수로 드러납니다.

공식 설명은 Data Agent를 “holistic architecture”로 정의합니다. 이 구조는 지식 이해, reasoning, planning을 통해 Data+AI 생태계의 여러 작업을 오케스트레이션합니다. 대회 소개가 내세운 핵심 능력도 구체적입니다. 높은 수준의 분석 질문을 실행 가능한 단계로 분해하고, Python script, SQL query, API call 같은 도구를 고르며, structured table, unstructured document, chart, multimodal data source를 함께 다룹니다. 이 정의는 챗봇형 분석 보조와 다릅니다. 사용자가 질문 하나를 던지면 에이전트가 데이터 준비, 계산, 검증, 답변 생성을 한 컨테이너 안에서 끝내야 합니다.

5월 29일 AoE 기준 업데이트가 중요한 이유는 이 추상적 목표가 운영 비용으로 바뀌는 순간을 보여주기 때문입니다. 공식 공지는 700개 이상 팀이 참가했고 submission volume이 예상보다 커져 compute resources와 scheduling에 substantial load를 줬다고 밝혔습니다. 별도로 일부 제출 Docker 이미지에서 suspected malicious or unauthorized behavior가 관찰됐고, evaluation jobs를 방해해 전체 진행에 영향을 줬다고 설명했습니다. 주최 측은 이후 evaluation을 stable, fair, secure, sustainable하게 유지하기 위해 평가 규칙과 남은 일정을 조정한다고 썼습니다.

이 문장은 에이전트 벤치마크 운영자가 마주하는 보안 모델을 압축합니다. 참가자의 Docker 이미지는 답안을 생성하는 프로그램이지만, 동시에 공격 표면입니다. 규칙은 외부 인터넷 접근, 평가 시스템이 주입한 MODEL_API_URL 우회, 다른 LLM 서비스를 primary task-solving model로 호출하는 행위를 금지합니다. container escape 또는 infrastructure probing, /input mount directory 수정, 환경 변수 파괴, 동일 이미지 공유 제출도 금지 목록에 들어갑니다. 대회가 복잡한 데이터 분석 능력을 보려면 컨테이너는 충분히 강해야 하고, 대회가 공정하려면 컨테이너는 충분히 묶여 있어야 합니다.

Phase 1의 A/B-board 분리는 이 비용을 줄이기 위한 장치입니다. 공식 규칙은 hidden set을 A-board 약 60 tasks와 B-board 약 320 tasks로 나눕니다. A-board는 staged leaderboard feedback용이고, 단일 실행 runtime limit은 2시간입니다. B-board는 최종 Phase 1 평가용이며 단일 실행 제한은 12시간입니다. 최종 Phase 1 리더보드는 A-board와 B-board 점수를 가중해 합칩니다. Top 60 팀만 Phase 2에 진출하고, Top 1-40은 Leaderboard 또는 Creative subtrack을 고를 수 있으며, Top 41-60은 Creative subtrack만 들어갑니다.

이 구조는 SWE-bench류 코딩 벤치마크와 닮았지만 데이터 분석에서는 다른 문제가 생깁니다. 코딩 에이전트는 보통 테스트를 실행하고 diff를 제출합니다. KDD Cup Data Agents는 각 task의 입력 구조가 고정되지 않습니다. 공식 FAQ는 context/ 아래 데이터 파일 조합이 task마다 다를 수 있고, csv/, db/, json/, doc/, knowledge.md 같은 하위 디렉터리를 동적으로 감지해야 한다고 설명합니다. 컨테이너 하나가 모든 task를 순회하므로, 한 task가 timeout을 잡아먹거나 crash를 일으키면 뒤의 결과를 잃을 수 있습니다. FAQ가 task별 timeout control과 처리 직후 prediction.csv 기록을 권하는 이유입니다.

채점 방식도 데이터 분석 에이전트의 성격에 맞춰져 있습니다. Leaderboard track은 column-level matching을 사용합니다. 공식 설명에 따르면 column values를 정렬해 signature count로 비교하고, recall 기반 점수에 가벼운 redundancy penalty를 붙입니다. column names와 row order는 scoring에 참여하지 않습니다. 이는 모델이 보기 좋은 표 제목을 붙였는지보다, 실제로 맞는 값 벡터를 만들었는지를 봅니다. 자연어 답변의 그럴듯함보다 계산 결과의 재현성을 우선하는 설계입니다.

이 대회가 개발자에게 주는 메시지는 분명합니다. 데이터 에이전트는 “LLM에게 CSV를 읽혀 답하게 하는 기능”이 아닙니다. 공식 평가에서 필요한 것은 파일 탐색, schema 추론, SQL 또는 Python 실행, 문서 근거 추출, 수치 반올림, 중간 결과 저장, 실패 복구, 로그 관리입니다. 모델 API 호출을 감싸는 앱이 아니라, 제한된 런타임에서 데이터 파이프라인을 스스로 조립하는 시스템입니다. 기업 내부 분석 에이전트를 만드는 팀도 같은 조건을 만납니다. 데이터는 다양하고, 권한은 제한되고, 실행 시간은 유한하며, 결과는 검증 가능해야 합니다.

KDD Cup 2026이 Qwen3.5-35B-A3B를 평가 모델로 고정한 점도 읽을 필요가 있습니다. 참가자는 개발 중 어떤 모델이든 쓸 수 있지만, 제출된 코드는 hardcoded endpoint가 아니라 환경 변수를 읽어야 합니다. 평가 시스템이 모델 주소와 key를 주입하면 코드가 자동으로 주최 측 모델로 바뀌어야 합니다. 이 방식은 모델 선택 경쟁을 줄이고 agent architecture 차이를 보려는 선택입니다. 동시에 실제 제품 환경과도 비슷합니다. 많은 기업은 개발자가 원하는 모델을 마음대로 쓰게 두지 않고, 중앙에서 허용한 endpoint와 감사 가능한 key를 주입합니다.

다만 이 방식은 한계도 만듭니다. 참가팀이 로컬에서 Claude, GPT, Gemini, DeepSeek, Qwen 계열을 비교하며 만든 prompt와 tool loop가 공식 Qwen3.5-35B-A3B 환경에서 같은 안정성을 보장하지 않습니다. 모델별 tool-use 습관, JSON 형식 준수, 긴 문서 처리, 수치 계산 실수는 다릅니다. 따라서 공식 점수는 “최고 모델을 붙였을 때의 데이터 에이전트 성능”이 아니라 “통일된 모델과 제한된 Docker 환경에서의 시스템 성능”으로 읽어야 합니다.

Creative subtrack의 존재도 흥미롭습니다. Phase 2에서 Leaderboard subtrack은 더 어려운 benchmark와 data images, data videos 같은 새 modality를 쓴다고 설명됩니다. Creative subtrack은 성숙하고 쓰기 쉬우며 interface-friendly한 데이터 에이전트 시스템, 투명한 의사결정 과정을 봅니다. 이는 데이터 에이전트 시장의 두 갈래를 반영합니다. 하나는 hidden benchmark 정확도입니다. 다른 하나는 실제 분석가가 사용할 수 있는 UI, explainability, review flow, error handling입니다. 기업 도입에서는 후자가 점수만큼 중요해질 수 있습니다.

커뮤니티 반응은 아직 넓게 번지지 않았습니다. Hacker News나 Reddit의 대형 토론은 확인되지 않았습니다. 검색 결과에서는 Hugging Face forum의 대회 call이 보입니다. 국내에서는 POSTECH HAIV 연구실의 참가 인턴 모집이 올라왔습니다. HKUST Guangzhou의 LinkedIn 홍보도 연구자와 참가자 모집 성격에 가깝습니다. 아직은 대중적 AI 뉴스라기보다 데이터베이스, 데이터 마이닝, 에이전트 연구 커뮤니티의 실험장에 가깝습니다.

그래도 이 대회가 다루는 문제는 넓습니다. 2025년과 2026년의 AI 에이전트 논의는 코딩 에이전트, 웹 브라우징 에이전트, MCP connector, 업무 자동화 쪽으로 크게 확장됐습니다. 데이터 분석 에이전트는 그보다 더 지저분한 입력을 받습니다. 데이터베이스 schema는 불완전하고, CSV는 깨져 있으며, 문서에는 설명과 예외가 섞이고, 결과는 숫자와 표로 검증됩니다. 모델이 답을 쓰는 능력보다, 틀릴 수 있는 계산을 얼마나 좁히는지가 더 중요합니다.

기업 AI 팀이 여기서 가져갈 실무 질문은 네 가지입니다. 첫째, 에이전트가 모든 task를 순회할 때 partial result를 언제 저장하는가. KDD Cup FAQ가 timeout 전에 prediction.csv를 쓰라고 한 부분은 production job에도 그대로 적용됩니다. 둘째, 모델 endpoint를 중앙에서 주입할 때 prompt, parser, retry logic이 모델 교체를 견디는가. 셋째, Docker 또는 sandbox가 외부 인터넷과 비인가 모델 호출을 실제로 막는가. 넷째, evaluation log가 악성 행동, 실수, 단순 timeout을 구분할 수 있는가.

이번 지연은 대회 운영상의 작은 사고로만 볼 수 없습니다. 에이전트 평가가 현실적인 규모로 커질 때 나타나는 기본 비용입니다. 700개 이상 팀이 제출한 Docker 이미지를 돌리려면 compute queue가 필요하고, hidden task 유출을 막아야 하며, 컨테이너가 시스템을 건드리지 못하게 해야 하고, 참가자의 모델 우회를 막아야 합니다. 이는 앞으로 사내 에이전트 평가 플랫폼, vendor benchmark, 조달용 PoC에서도 반복될 문제입니다.

KDD Cup 2026 Data Agents가 던진 질문은 “어떤 에이전트가 사람 대신 분석할 수 있는가”입니다. 5월 말 일정 조정이 던진 질문은 더 운영적입니다. 그 에이전트를 수백 개 팀이 제출했을 때, 누가 어떤 모델을 쓰고, 어떤 파일을 읽고, 어떤 네트워크를 호출하고, 어떤 결과를 남겼는지 어떻게 확인할 것인가. 데이터 에이전트의 다음 경쟁력은 reasoning chain의 길이가 아니라, 제한된 runtime 안에서 검증 가능한 산출물을 남기는 능력으로 측정될 가능성이 높습니다.

KDD Cup의 최종 수상자는 8월 9일 KDD 2026에서 공식 발표될 예정입니다. 그 전에 이미 확인된 사실은 하나입니다. 데이터 에이전트는 연구 주제를 넘어 평가 인프라의 주제가 됐습니다. 대회가 모델을 고정하고 Docker를 요구하며 A/B-board를 나누고 보안 심사를 강화한 것은, 에이전트가 실제 업무 시스템에 들어갈 때 필요한 통제 목록을 미리 보여줍니다. 개발자는 이제 데이터 분석 에이전트를 만들 때 prompt와 모델만이 아니라 컨테이너, 로그, endpoint 주입, partial output, 금지 행동 탐지를 함께 설계해야 합니다.