[리서치] 금융 AI Challenge: 사전 검토가 본선을 가른다 | DAKER 커뮤니티
2026-08-19 05:09 KST, 공식 화면의 숫자는 조용히 움직였습니다. 참가자 884명, 제출 62건, 저장 135건, 임시저장 12건. 제출 탭을 오가는 손이 늘어날수록, 본선으로 가는 첫 문은 더 선명해집니다. 멋진 데모보다 먼저 통과해야 하는 것은 사전 검토입니다.
오늘의 결론은 하나입니다. 새 기능을 하나 더 붙이기 전에, 기획서 PDF와 기능 명세서 PDF, 실행 가능한 웹서비스 URL이 같은 문제와 같은 해결책을 말하는지 검토표로 잠그세요. 공식 안내는 사전 검토를 통과한 팀을 대상으로 내부 비공개 심사위원단 평가를 진행한다고 밝히고 있습니다.
왜 이 장면이 중요할까요?
본선 심사는 제출된 기획서와 MVP 산출물을 기반으로 시작됩니다. 여기서 MVP 산출물은 기능 명세서 PDF와 웹서비스 URL입니다. 화면이 좋아 보여도 문서의 문제 정의가 다르거나, URL이 열리지 않거나, 제출물이 누락되면 팀은 평가 이야기로 들어가기 전에 멈출 수 있습니다.
- 기획서 PDF는 제공 양식 기반으로 작성한 뒤 PDF로 제출해야 합니다.
- MVP 산출물에는 기능 명세서 PDF와 실행 가능한 웹서비스 URL이 포함됩니다.
- 본선 심사는 사전 검토를 통과한 제출물을 대상으로 진행됩니다.
- 부적격 여부와 주제 적합성은 공식 평가 안내에 포함된 확인 항목입니다.
팀룸에서는 무엇을 바꿔야 할까요?
사전 검토표는 거창한 문서가 아닙니다. 팀원이 같은 화면을 보며 빈칸을 지우는 작업입니다. 지금 필요한 질문은 “우리 서비스가 얼마나 멋진가”보다 “심사자가 첫 화면에서 공식 주제와 제출물을 한 번에 확인할 수 있는가”에 가깝습니다.
- 기획서 첫 문장과 기능 명세서 첫 화면이 같은 금융 문제를 가리키는지 맞춥니다.
- 웹서비스 URL을 시크릿 창에서 열고 핵심 기능까지 이동되는지 확인합니다.
- 기능 명세서의 화면 이름과 실제 서비스 메뉴 이름을 같은 표현으로 정리합니다.
- 사용한 데이터, 코드, 아이디어의 출처와 공개 가능성을 팀 내부 기록에 남깁니다.
- 누락 가능성이 있는 PDF, URL, 팀 전환 상태를 제출 전 한 사람이 아니라 두 사람이 교차 확인합니다.
사소한 실수는 어디서 결격으로 바뀔까요?
공식 규칙은 웹서비스 URL 접근 불가, 제출물 누락, 무단 사용이나 표절, 운영 측 요청 자료 미제출을 위험 신호로 둡니다. 이 항목들은 기술 난도와 별개입니다. 잘 만든 기능도 제출 칸에서 빠지면 심사 자료가 되지 못합니다.
특히 이번 대회는 AI 기반 금융 현안 해결 아이디어를 실제 작동 가능한 웹서비스로 구현하는 흐름입니다. 문제 정의, AI 판단, 사용자 행동, 결과 화면이 문서와 URL에서 같은 순서로 보여야 합니다. 그래야 심사자는 데모를 보기 전에 팀이 무엇을 해결하려는지 놓치지 않습니다.
오늘 바로 채울 체크리스트는 무엇인가요?
- 기획서 PDF, 기능 명세서 PDF, 웹서비스 URL 세 가지가 모두 제출 화면 기준으로 준비됐는지 확인합니다.
- 공식 주제인 금융 현안 해결과 서비스 화면의 첫 행동이 직접 연결되는지 확인합니다.
- URL 접근 기간에 막힐 로그인, 배포, 외부 호출 문제를 미리 기록합니다.
- 마감 후 산출물 수정 제한을 전제로 최종 파일명과 제출 주체를 고정합니다.
짧은 FAQ
사전 검토표를 따로 제출해야 하나요? 공식 제출물로 명시된 것은 아닙니다. 다만 본선 평가로 넘어가기 전 누락과 결격을 줄이는 팀 내부 점검표로 유용합니다.
가장 먼저 볼 항목은 무엇인가요? 기획서 PDF, 기능 명세서 PDF, 웹서비스 URL이 같은 문제와 같은 사용자 흐름을 설명하는지 보세요.
오늘 하나만 한다면 무엇인가요? 처음 보는 팀원 한 명에게 URL을 열게 하고, 기획서의 문제 정의와 실제 첫 화면이 맞는지 말로 설명하게 해 보세요.
기준일: 2026-08-19 05:09 KST. 공식 페이지는 대회 일정과 운영 방식이 주최·주관기관 사정에 따라 변경될 수 있다고 안내하므로, 최종 제출 전에는 공식 대회 페이지의 규칙과 공지를 다시 확인하세요.