입력→LLM 실행→파싱→채점까지 자동 실행·채점 구조는 주최 측이 고정하고, 참가자는 LLM 행동 지침 프롬프트만 작성합니다.
자문 범위 세 축(문제·데이터셋 / 자동채점 / 리더보드)을 정리하고, 미송 논의가 필요한 열린 결정을 아래에 모았습니다.
미송님 확인 필요 · 결정 5가지
본 문서는 4개 후보 주제 중 ‘설비 정비주기 예측형’ 1개 기준의 상세 설계안입니다.
아래 5가지가 확정되면 배점·문제 수·제출 형태 등 나머지 설계가 정해집니다.
장비 유지보수 이력(합성 데이터) 1건을 보고 고장위험등급과 다음 정비주기 구간을 분류합니다.
참가자는 공개된 샘플 데이터 15행으로 규칙을 추론하고, 채점은 숨겨진 비공개 데이터 30행으로 이뤄집니다.
(30행은 설명·검증용 기준 — 실제 운영 시 리더보드 안정성·변별력을 위해 100~300행 확장 검토)
※ 아래 컬럼 구조·데이터 규모·수치·정답 규칙은 설계 설명을 위한 예시이며, 주최측 확정 시 변경됩니다. (라벨 정의 자체는 설계안)
쉽게 이해하기
군 설비(발전기·전술차량·통신장비·레이더 등)는 갑자기 고장 나면 작전·훈련에 큰 차질을 줍니다. 그래서 고장 뒤 수리가 아니라 징후를 미리 읽어 예방 정비하는 것이 핵심이고, 그러려면 방대한 정비 이력을 판단해야 합니다.
이 대회는 그 판단을 LLM으로 자동화합니다. 정비 이력을 보고 ① 곧 또 고장날 위험이 얼마나 큰지, ② 다음 정비를 언제 해야 하는지를 분류하도록, 참가자가 에이전트 행동 지침을 설계하는 과제입니다.
참가자는 코드를 작성하거나 정답 파일을 직접 제출하지 않습니다. 대신 LLM이 데이터를 어떻게 읽고, 어떤 기준으로 판단하고, 어떤 형식으로 답할지를 설명하는 행동 지침 프롬프트를 씁니다 — 예컨대 "정비가 잦거나 가동시간이 길거나 최근에 고장났으면 위험을 높게 보라"처럼요. 그러면 채점 시스템이 그 지침을 숨겨진 30건에 그대로 실행해, 정답과 얼마나 일치하는지로 점수를 매깁니다.
합성 데이터를 쓰는 이유 — 실제 군 정비 데이터는 보안·반출 이슈가 있어, 정비 업무 구조를 모사한 합성 데이터를 씁니다. 군 장비 정비 맥락은 이해되되 특정 부대·장비·작전 정보는 드러나지 않게 설계합니다.
과제 명세
sample.csv 15행 — 입력 + 정답 공개private.csv 30행 — 입력·정답 비공개, 서버 보관샘플 데이터(sample.csv) 예시 · 4행
| id | 장비 | 수리기간(일) | 비용(원) | 최근1년 정비(회) | 누적가동(h) | 직전고장(일 전) | → 고장위험 | → 다음정비 |
|---|---|---|---|---|---|---|---|---|
| 1 | 발전기 | 6 | 850,000 | 6 | 4,200 | 20 | HIGH | 0-30 |
| 2 | 통신장비 | 2 | 120,000 | 1 | 1,500 | 140 | LOW | 181+ |
| 3 | 전술차량 | 4 | 430,000 | 3 | 3,100 | 60 | MEDIUM | 31-90 |
| 4 | 레이더 | 3 | 900,000 | 3 | 2,600 | 75 | MEDIUM | 91-180 |
아래 규칙은 설명용 예시입니다. 실제 채점용 비공개 데이터의 정답 생성 규칙은 그대로 공개하지 않으며, 복합 조건·경계 케이스·노이즈로 변별력을 확보합니다.
① 고장 위험 등급 · risk_grade
가까운 시일 내 다시 고장 날 가능성을 세 단계로.
정비가 잦고 오래 가동됐거나 최근 고장났을수록 높음.
| HIGH | 정비 ≥ 5회 또는 가동 ≥ 4000h 또는 직전고장 ≤ 30일 |
| MEDIUM | HIGH·LOW 어디에도 해당하지 않음 |
| LOW | 정비 ≤ 2회 그리고 가동 < 2000h 그리고 직전고장 > 90일 |
② 다음 정비 시점 · cycle_range
다음 정비까지 두어도 되는 기간을 네 구간으로.
위험이 클수록 더 빨리 정비해야 함.
| 0-30 | 30일 이내 재정비 · risk=HIGH |
| 31-90 | 1~3개월 · MEDIUM & 가동 ≥ 3000h |
| 91-180 | 3~6개월 · MEDIUM & 가동 < 3000h |
| 181+ | 6개월 초과 · risk=LOW |
참가자는 코드나 정답 파일을 제출하지 않습니다. 대신 LLM이 데이터를 어떻게 읽고, 어떤 기준으로 판단하며, 어떤 형식으로 답해야 하는지를 설명하는 행동 지침 프롬프트를 제출합니다.
주최 측은 모든 참가자에게 동일하게 적용되는 고정 시스템 지시를 구성하고, 그 안에 참가자 행동 지침과 비공개 데이터 입력을 결합해 LLM을 실행합니다. 이후 출력 파싱·정답 대조·점수 산정까지 동일한 절차로 처리하며, 이 고정된 자동 실행·채점 절차를 하네스라고 부릅니다.
즉, 주최 측이 정답 로직을 직접 만들어 참가자의 판단을 대신하는 구조가 아니라, 참가자 행동 지침이 LLM에게 데이터 해석·판단을 얼마나 잘 지시하는지를 평가하는 구조입니다.
참가자가 통제하는 것은 행동 지침 프롬프트뿐입니다 — 비공개 데이터·정답셋·모델 설정·채점 기준·API 키·하네스 내부 로직에는 접근할 수 없습니다. 모델·temperature·출력 형식을 최대한 고정해 재현성을 높이되, LLM 특성상 완전히 동일한 응답은 보장하기 어려워 공식 제출의 원출력·채점 결과를 저장해 이의·재채점·검증 기준으로 씁니다. 정답셋·API 키는 채점 워커에만 격리됩니다. 현재 설명은 참가자가 하나의 행동 지침을 제출하는 단일 지침형 구조 기준이며, 초급자 친화성을 높이려면 데이터 이해·전처리 지침 → 판단 기준·분류 지침 → 최종 출력 형식 지침처럼 단계를 나누는 가이드형 다단계(Shape B)도 검토할 수 있습니다. Shape B 채택 시 제출 UI·DB 스키마·LLM 호출 수·비용·채점 파이프라인이 달라져 미송님·주최측 결정이 필요합니다(열린 결정 ④). 재현성·격리 상세는 시스템 아키텍처 참고.
채점은 리더보드 점수(실시간 경쟁)와 토탈 점수(최종·수상)로 나눕니다.
정확한 배점은 대회 의도·문제 수 확정 후 결정합니다 — 아래 열린 결정 참고.
점수 구조 배점 미정 · 미송 논의
참가자가 실시간으로 겨루며 보는 점수 · 여러 제출 중 최고점 자동 선택.
최종 순위·수상 결정 · 수강률·보안 위반을 점수화할지, 응시/실격 게이트로 둘지는 미송 확인 필요.
코딩 테스트처럼 행동 지침을 작성해 [샘플 실행](공개 샘플)으로 검증·[제출] · 1일 샘플 50회 / 제출 3회.
모바일 우선 · 작업은 세션 지속(중단·재개, 콘솔을 닫아도 서버 저장·백그라운드 진행).
1 2 3 4 5
너는 국방 설비 정비 분석가다.
아래 정비 이력을 보고 고장위험등급과
다음 정비주기를 판단하라.
입력: {{input}}
출력: `위험, 주기` 한 줄 (예: HIGH, 0-30)
| # | 입력 (요약) | 기대 정답 | 에이전트 출력 | 판정 |
|---|---|---|---|---|
| 1 | 발전기 · 정비6 · 4,200h | HIGH, 0-30 | HIGH, 0-30 | 통과 |
| 2 | 통신장비 · 정비1 · 1,500h | LOW, 181+ | LOW, 181+ | 통과 |
| 3 | 전술차량 · 정비3 · 3,100h | MEDIUM, 31-90 | MEDIUM, 31-90 | 통과 |
| 4 | 레이더 · 정비3 · 2,600h | MEDIUM, 91-180 | MEDIUM, 91-180 | 통과 |
| 5 | 화포 · 정비4 · 3,300h | MEDIUM, 31-90 | MEDIUM, 0-30 | 실패 |
[샘플 실행]은 정답이 공개된 샘플 데이터로 즉시 결과를 보여주고, [제출]만 숨겨진 비공개 데이터 30행으로 공식 채점됩니다.
제출 내역 — 공식 제출별 상태·제출 시각·점수·파싱 성공 여부·리더보드 반영을 확인합니다. 상태: 채점 대기 · 채점 중 · 채점 완료 · 검토 필요 · 실패.
LLM 질문 도우미 선택 · 검토 중
VOD 개념·데이터 컬럼 의미·프롬프트 작성 방향을 질문할 수 있습니다. 단, 문제 정답을 직접 요구하거나 비공개 데이터 예측을 대신 시키는 질문은 차단합니다(사용 로그·토큰 기록). 챗봇 탑재 시 서비스 범위·비용·필터링 정책이 달라지므로 개발 범위 결정 필요.
학습·이해를 돕는 기능이며 공식 채점에 직접 관여하지 않습니다. 사용 로그는 운영·보안 목적으로 저장하고, 실제 군사정보·개인정보 입력은 금지합니다.
리더보드는 리더보드 점수(결과값 유효성 · 프롬프트 효율성)로 겨룹니다. 제출 후 통상 수 분 내(최대 15분) 반영하고, 토탈 점수·최종 순위는 별도 공지합니다.
리더보드 (예시 · 리더보드 점수)
| 순위 | 참가자 | 소속 | 점수 | 누적 제출 | 최종 제출 |
|---|---|---|---|---|---|
| 1 | 이○준 | 공군 제1전투비행단 | 97.2 | 18회 | 07-28 22:10 |
| 2 | 박○서 | 수도방위사령부 | 95.8 | 22회 | 07-27 19:44 |
| 3 | 최○민 | 해군 제2함대 | 94.1 | 11회 | 07-28 09:03 |
| ⋯ | |||||
| 1,187 | 홍길동 본인 | 육군훈련소 | 91.3 | 14회 | 07-28 14:22 |
| 1,188 | 정○우 | 제7군단 | 91.2 | 7회 | 07-28 11:57 |
▲ 내 점수 91.3 — 90–100 구간 (상위 12%)
상위·중위·하위 n%로만 노출해 초기 과열·이탈을 방지합니다.
접수 확인 → 백그라운드 채점 → 수 분 내 리더보드 반영. 역추적은 구간·지연 노출로 완화(군 취침시간 고려).
Public 기준 실등수를 열어 최종 스퍼트 동기를 부여합니다.
숨겨둔 정답셋으로 재채점 → 게이밍 무력화, 수상 후보 확정.
제출 접수(웹)와 채점 재실행(워커)을 분리한 비동기 구조 — 마감 폭주에도 접수는 즉시, 무거운 LLM 재실행은 큐·워커가 완충합니다.
스택 비강제: 표기된 기술(React·FastAPI·Redis 등)은 권장 예시일 뿐, 개발팀 기존 스택으로 구현해도 됩니다 — 우리는 아키텍처만 제공합니다. 예상 동시 접속 500명 수준에서는 일반 웹 서버보다 LLM 호출량·채점 큐 대기 시간이 주요 병목이 될 가능성이 높습니다. 그래서 제출 접수와 채점 실행을 분리하고 큐·워커·배치로 완충합니다.
운영자가 신청·수강·제출·채점·수상을 한 화면에서 관리하고, 대규모 LLM 호출 비용을 통제합니다.
관리자 · 운영 기능
비용 · 호출량 예시 모델 단가 변동 시 재산정
개발사 전달 핵심
단순 제출 게시판이 아니라, 참가자가 낸 행동 지침 프롬프트를 서버가 동일 조건에서 재실행하고 LLM 출력을 자동 파싱해 정답과 비교한 뒤 리더보드에 반영하는 비동기 자동채점 시스템입니다.
아래는 주최측·미송 확정이 필요한 항목입니다. 나머지 설계(배점·콘솔·채점)는 이 결정에 맞춰 조정됩니다.
LLM 활용 능력을 겨루는 대회인가, 다양한 주제를 경험시키는 장인가. 문제 수·채점·난이도가 여기서 갈립니다.
출제안은 4개(조달 수요예측·입영 수요예측·드론 탐지·정비주기). 전부/일부/1개 중 무엇을 풀고, 점수는 합·평균·최고점 중 무엇인지.
leaning · 일부 선택 + 문제별 난이도 배점(참여 유도)
리더보드 = 결과값 유효성 + 프롬프트 효율성 / 토탈 = + 수강·형식·보안. 각 항목 정확 배점 확정 필요.
프롬프트 한 장(Shape A)인지, 하네스가 단계를 고정하고 노드별 프롬프트(전처리→분석→구조화, Shape B)를 쓰게 할지.
leaning · 초급 친화 가이드형 다단계(주최측 Data_Sample 구조)
현재 정답 규칙은 단순 임계식이라 컬럼만 붙여넣으면 LLM이 즉답 → 변별력 붕괴. 함정/재설계 필요.
방향 · 비선형 · 특성 상호작용 · 노이즈 · 숨긴 임계