금융 AI Challenge 본선 전, 제출물 3개가 같은 이야기를 하는지 점검할 때입니다 | DAKER 커뮤니티

2026-08-19 05:09 KST, 공식 화면의 숫자는 조용히 움직였습니다. 참가자 884명, 제출 62건, 저장 135건, 임시저장 12건. 제출 탭을 오가는 손이 늘어날수록, 본선으로 가는 첫 문은 더 선명해집니다.

지금 중요한 것은 새 기능을 더하는 일보다 사전 검토입니다. 기획서 PDF와 기능 명세서 PDF, 실행 가능한 웹서비스 URL이 같은 문제와 같은 해결책을 말하는지 먼저 맞춰보는 것이 좋습니다. 공식 안내는 사전 검토를 통과한 팀을 대상으로 내부 비공개 심사위원단 평가를 진행한다고 밝히고 있습니다.

멋진 데모보다 먼저 통과해야 하는 것은 사전 검토입니다.

왜 지금 이 점검이 중요할까요?

본선 심사는 제출된 기획서와 MVP 산출물을 기반으로 시작됩니다. 여기서 MVP 산출물은 기능 명세서 PDF와 웹서비스 URL입니다. 화면이 좋아 보여도 문서의 문제 정의가 다르거나, URL이 열리지 않거나, 제출물이 누락되면 팀은 평가 이야기로 들어가기 전에 멈출 수 있습니다.

공식 평가 안내에는 부적격 여부와 주제 적합성을 포함한 확인 항목이 담겨 있습니다. 결국 심사자는 먼저 제출물이 제대로 갖춰졌는지, 그리고 대회가 요구한 문제를 정확히 다루고 있는지부터 보게 됩니다.

제출물 3개는 무엇을 같게 말해야 할까요?

기획서 PDF는 제공 양식 기반으로 작성한 뒤 PDF로 제출해야 합니다. 기능 명세서 PDF와 실행 가능한 웹서비스 URL은 MVP 산출물로 함께 제출됩니다. 이 세 가지는 형식만 다를 뿐, 같은 문제 정의와 같은 사용자 흐름을 보여줘야 합니다.

예를 들어 기획서 첫 문장에서 다루는 금융 문제가 기능 명세서 첫 화면에서도 그대로 이어지고, 실제 웹서비스 첫 화면에서도 같은 맥락으로 확인되면 심사자는 팀의 의도를 빠르게 이해할 수 있습니다. 반대로 문서와 서비스가 서로 다른 표현을 쓰거나 해결하려는 문제가 어긋나면, 기능 완성도와 별개로 전달력이 크게 떨어질 수 있습니다.

기획서 PDF, 기능 명세서 PDF, 웹서비스 URL은 같은 문제와 같은 해결책을 설명해야 합니다.

팀룸에서 바로 바꿔볼 수 있는 점검 방식

사전 검토표는 거창한 문서가 아닙니다. 팀원이 같은 화면을 보며 빈칸을 지우는 작업에 가깝습니다. 지금 필요한 질문은 우리 서비스가 얼마나 멋진가보다, 심사자가 첫 화면에서 공식 주제와 제출물을 한 번에 확인할 수 있는가에 더 가깝습니다.

기획서 첫 문장과 기능 명세서 첫 화면이 같은 금융 문제를 가리키는지 맞춰보면 됩니다. 웹서비스 URL은 시크릿 창에서 열어 핵심 기능까지 이동되는지 확인하는 것이 좋습니다. 기능 명세서의 화면 이름과 실제 서비스 메뉴 이름도 같은 표현으로 정리해두면 심사 과정에서 혼선을 줄일 수 있습니다.

또한 사용한 데이터, 코드, 아이디어의 출처와 공개 가능성은 팀 내부 기록에 남겨두는 편이 안전합니다. 제출 전에는 PDF, URL, 팀 전환 상태를 한 사람이 아니라 두 사람이 교차 확인하면 누락 가능성을 줄일 수 있습니다.

사소한 실수가 결격으로 이어지는 지점

공식 규칙은 웹서비스 URL 접근 불가, 제출물 누락, 무단 사용이나 표절, 운영 측 요청 자료 미제출을 위험 신호로 둡니다. 이 항목들은 기술 난도와는 별개입니다. 잘 만든 기능도 제출 칸에서 빠지면 심사 자료가 되지 못합니다.

특히 이번 대회는 AI 기반 금융 현안 해결 아이디어를 실제 작동 가능한 웹서비스로 구현하는 흐름입니다. 문제 정의, AI 판단, 사용자 행동, 결과 화면이 문서와 URL에서 같은 순서로 보여야 심사자가 데모를 보기 전에도 팀이 무엇을 해결하려는지 놓치지 않게 됩니다.

잘 만든 기능도 제출 칸에서 빠지면 심사 자료가 되지 못합니다.

오늘 바로 확인해볼 항목

우선 기획서 PDF, 기능 명세서 PDF, 웹서비스 URL 세 가지가 모두 제출 화면 기준으로 준비됐는지 보는 것이 좋습니다. 이어서 공식 주제인 금융 현안 해결과 서비스 화면의 첫 행동이 직접 연결되는지 확인해보면 됩니다.

URL 접근 기간에 문제가 될 수 있는 로그인, 배포, 외부 호출 이슈도 미리 기록해두는 편이 좋습니다. 마감 후 산출물 수정 제한을 전제로 최종 파일명과 제출 주체를 정리해두면 마지막 순간의 혼선을 줄일 수 있습니다.

짧게 정리하는 FAQ

사전 검토표를 따로 제출해야 하나요?

공식 제출물로 명시된 것은 아닙니다. 다만 본선 평가로 넘어가기 전 누락과 결격을 줄이는 팀 내부 점검표로 유용합니다.

가장 먼저 볼 항목은 무엇인가요?

기획서 PDF, 기능 명세서 PDF, 웹서비스 URL이 같은 문제와 같은 사용자 흐름을 설명하는지 보면 됩니다.

오늘 하나만 한다면 무엇이 좋을까요?

처음 보는 팀원 한 명에게 URL을 열게 하고, 기획서의 문제 정의와 실제 첫 화면이 맞는지 말로 설명해보게 하면 됩니다.

참고 자료

기준일: 2026-08-19 05:09 KST. 공식 페이지는 대회 일정과 운영 방식이 주최·주관기관 사정에 따라 변경될 수 있다고 안내하므로, 최종 제출 전에는 공식 대회 페이지의 규칙과 공지를 다시 확인하는 것이 좋습니다.

여러분 팀은 지금 제출물 3개가 정말 같은 이야기를 하고 있는지, 어디부터 다시 맞춰보고 싶으신가요?