2026 금융 AI Challenge, 제출물이 곧 발표 증거가 되는 이유 | DAKER 커뮤니티

제출 버튼을 누르는 순간, 파일은 사라지는 것이 아니라 다음 발표장의 증거가 됩니다. 2026-08-07 05:05 KST 기준 공식 페이지에는 참가자 600명과 제출 39건이 보이고, 일정표는 기획서 PDF와 MVP 산출물 다음에 최종 발표자료 PDF, 최종 소스 코드 ZIP, 오프라인 발표 심사까지 이어집니다.

그래서 지금 중요한 것은 나중에 발표자료를 새로 꾸미는 일이 아니라, 오늘 제출하는 PDF와 URL이 그대로 발표 근거가 되도록 쌓아두는 일입니다. 마감 전에는 기능을 더 붙이고 싶어지기 쉽지만, 심사 흐름을 보면 오히려 같은 내용을 일관되게 설명할 수 있는 상태가 더 중요합니다.

나중에 발표자료를 새로 꾸미려 하지 말고, 지금 제출하는 PDF와 URL이 그대로 발표 증거가 되게 쌓아두는 것이 좋습니다.

왜 지금 이 흐름을 봐야 할까요?

아직 마감까지 시간이 남아 보이면 팀은 기능을 더 추가하고 싶어집니다. 하지만 공식 흐름은 산출물 제출에서 끝나지 않습니다. 기능 명세서 PDF와 웹서비스 URL을 낸 뒤, 사전 검토와 본선 심사를 통과하면 발표 심사 대상자는 최종 발표자료 PDF와 최종 소스 코드 ZIP을 다시 제출해야 합니다.

이 말은 오늘 화면에 적힌 설명 한 줄, 제출 URL의 동작 하나, 기능 명세서의 항목 이름 하나가 한 달 뒤 발표 질의응답의 기준이 될 수 있다는 뜻입니다. 지금의 작은 불일치가 나중에는 설명의 빈틈으로 드러날 수 있습니다.

무엇이 발표 증거가 될까요?

증거는 별도의 거창한 문서가 아닙니다. 심사자가 실제로 확인할 수 있는 사용 흐름, 기능 명세서의 문장, 제출 URL의 동작, 소스 코드 폴더의 구조가 같은 방향을 가리키는 상태가 곧 증거입니다. 팀원 한 명이 빠져도 다른 팀원이 같은 이야기를 할 수 있어야 합니다.

심사자가 실제로 확인할 수 있는 문장, 화면, URL, 코드 구조가 같은 방향을 가리킬 때 발표 증거가 됩니다.

예를 들어 기획서 PDF의 문제 정의와 MVP 첫 화면의 문구는 같은 사용자를 가리켜야 합니다. 기능 명세서 PDF에 적은 핵심 기능은 제출 URL에서 바로 찾을 수 있어야 하고, 최종 소스 코드 ZIP 후보 폴더는 데모 화면과 이름이나 기능 범위가 어긋나지 않는 편이 좋습니다. 발표자료 PDF 역시 새로운 주장을 덧붙이기보다 이미 제출한 증거를 읽기 쉽게 배열하는 쪽에 가깝습니다.

팀룸에서는 어떤 순서로 움직이면 좋을까요?

오늘 할 일은 발표자료 완성본을 만드는 것이 아닙니다. 나중에 발표자료를 만들 때 다시 뒤지지 않도록, 심사 흐름을 따라 증거를 남기는 일입니다.

먼저 기획서 PDF에서 해결하려는 금융 현안 한 문장을 골라 팀의 공통 기준 문장으로 삼아두면 됩니다. 그다음 웹서비스 URL 첫 화면에서 그 기준 문장이 어떤 버튼, 입력창, 결과 화면으로 이어지는지 캡처해 두는 것이 좋습니다.

이후에는 기능 명세서 PDF의 항목 이름과 실제 화면, 소스 폴더 이름이 서로 다르지 않은지 맞춰보면 됩니다. 동시에 최종 발표자료 PDF에 들어갈 문제 → AI 처리 → 사용자 행동 → 결과의 한 장면을 미리 적어두면, 나중에 발표를 준비할 때 흐름이 흔들리지 않습니다. 마지막으로 소스 코드 ZIP 후보 폴더에서는 불필요한 실험 파일과 설명하기 어려운 외부 자산을 분리해 두는 편이 안전합니다.

공식 근거는 어디까지 확인됐나요?

공식 페이지는 공모전 기획서 PDF, 기능 명세서 PDF, 웹서비스 URL을 제출물로 안내합니다. 제출 URL은 지정 기간 동안 접근 가능해야 하며, 발표 심사 대상자는 최종 발표자료 PDF와 최종 소스 코드 ZIP을 제출해야 합니다.

또한 본선 심사에서는 제출된 기획서와 MVP 산출물을 기반으로 사전 검토를 통과한 팀을 내부 평가하고, 상위 11팀 내외가 발표 심사 대상자로 선발된다고 안내됩니다. 발표 심사는 2026년 10월 13일 예정이며 PT 15분, 질의응답 5분으로 제시되어 있습니다.

출처: https://finaischallenge.co.kr/

어디까지 조심해야 할까요?

이 글은 공식 페이지의 일정과 제출물 규칙을 바탕으로 한 준비 방법입니다. 개별 팀의 기술 선택, 보안 검토, 라이선스 판단을 대신하지는 않습니다. 특히 제출 마감 이후 산출물 수정이 제한되고, 자료 누락은 결격 처리될 수 있으므로 애매한 항목은 팀 내부 추측보다 공식 문의와 기록으로 정리하는 편이 안전합니다.

애매한 항목은 팀 내부 추측보다 공식 문의와 기록으로 정리하는 편이 안전합니다.

짧게 정리하면

지금 먼저 만들 것은 발표자료 완성본이 아니라 증거 지도입니다. PDF, URL, 코드가 같은 장면을 말하는지 확인해 두면 됩니다. 제출 URL의 캡처는 공식 제출물은 아니지만, 나중에 장애나 설명 공백을 줄이는 내부 증거가 될 수 있습니다. 오늘 가장 먼저 볼 파일은 기능 명세서 PDF이며, 그 안의 핵심 기능명이 실제 화면과 소스 폴더에서 같은 이름으로 보이는지 확인하는 것이 좋습니다.

여러분 팀은 지금 제출물과 발표자료 사이의 연결을 어디까지 맞춰두셨나요?