2026 금융 AI Challenge 제출 전, 기획서 PDF와 기능 명세서 PDF를 구분해 보는 이유 | DAKER 커뮤니티
제출 마감이 같다고 PDF 두 개를 한 문서처럼 다루면, 마지막 업로드 단계에서 가장 쉽게 꼬이곤 합니다. 2026년 7월 31일 05:04 KST 기준 공식 대회 페이지는 2026년 9월 7일 월요일 오전 10시까지 기획서 PDF와 MVP 산출물인 기능 명세서 PDF, 실행 가능한 웹서비스 URL을 제출해야 한다고 안내합니다.
지금은 새 기능을 더 붙이기보다, 두 PDF가 서로 다른 역할을 하면서도 같은 서비스를 설명하는지 먼저 확인하는 편이 안전합니다. 이 대회는 AI 기반 금융 현안 해결 아이디어를 실제 작동 가능한 웹서비스로 구현하는 공모전이고, 공식 페이지는 산출물 제출 뒤 사전 검토를 통과한 팀을 대상으로 본선 심사가 진행된다고 설명합니다. 그래서 기획서 PDF는 왜 이 문제를 풀어야 하는가를 설득하고, 기능 명세서 PDF는 URL에서 무엇을 어떻게 확인할 수 있는가를 안내하는 쪽에 더 가깝습니다.
두 PDF가 같은 말을 반복하면 분량은 늘지만, 심사자가 확인할 경로는 흐려집니다.
기획서 PDF와 기능 명세서 PDF는 무엇이 다를까요?
기획서 PDF는 금융 현안, 대상 사용자, AI 기반 해결 아이디어, 기대되는 서비스 방향을 설명하는 문서에 가깝습니다. 반대로 기능 명세서 PDF는 MVP 웹서비스 URL을 열었을 때 어떤 화면과 기능이 실제로 작동하는지 확인하게 만드는 안내서입니다. 둘 다 같은 대회를 설명하지만, 답하려는 질문이 다릅니다.
기획서 PDF는 선택한 금융 현안과 대상 금융소비자를 먼저 분명히 잡아 주는 역할을 합니다. 기능 명세서 PDF는 실제 화면 이름, 입력값, AI 판단, 결과 화면을 확인 가능하게 적는 문서에 더 가깝습니다. 웹서비스 URL은 기능 명세서에 적힌 핵심 경로가 실행되는지 보여줘야 하고, 두 PDF의 제목, 서비스명, 핵심 사용자 표현은 서로 흔들리지 않는 편이 좋습니다. 또 한 PDF에만 있는 핵심 기능이 있다면 URL이나 다른 PDF에서 어떻게 설명되는지 따로 확인해 두는 것이 안전합니다.
오늘은 어떤 순서로 나누면 좋을까요?
팀 문서가 아직 덜 완성됐어도 괜찮습니다. 먼저 같은 기능 하나를 골라 기획서, 명세서, URL의 역할을 나누면 나머지 기능도 같은 방식으로 정리할 수 있습니다.
기획서 첫 장에는 문제 정의와 대상 사용자를 한 문장으로 적어 두면 됩니다. 기능 명세서 첫 장에는 사용자가 URL에서 처음 확인할 화면 이름을 적는 편이 좋습니다. 그다음에는 그 화면에서 필요한 입력값, AI가 하는 판단, 결과 화면의 다음 행동을 나눠 보고, 웹서비스 URL을 열어 기능 명세서에 적은 화면 순서가 실제로 이어지는지 확인하면 됩니다. 마지막에는 두 PDF의 파일명, 서비스명, 핵심 기능 이름을 맞춘 뒤 제출 탭별로 다시 확인하는 것이 좋습니다.
헷갈리기 쉬운 실수는 무엇인가요?
가장 흔한 실수는 기획서 PDF에 화면 설명을 길게 넣고, 기능 명세서 PDF에는 다시 아이디어 배경을 반복하는 것입니다. 이렇게 되면 제출물은 많아졌는데 MVP 확인 경로는 오히려 선명해지지 않습니다. 공식 페이지가 MVP 산출물로 기능 명세서와 웹서비스 URL을 함께 요구하는 이유를 생각하면, 명세서는 실제 확인 경로에 더 가까워야 합니다.
예를 들어 이상금융거래 탐지 서비스를 만든다면 기획서에는 누구의 어떤 위험을 줄이는지, 왜 AI가 필요한지, 어떤 금융 채널에서 쓰일지를 설명합니다. 기능 명세서에는 의심 상황 입력 화면, 위험 신호 분류 화면, 사용자 행동 안내 화면, 기록 또는 신고 준비 화면처럼 URL에서 확인할 흐름을 적습니다. 같은 서비스를 설명하더라도 문서의 역할은 다릅니다.
기획서는 문제와 해결 방향을 설득하고, 기능 명세서는 실제 확인 경로를 안내해야 합니다.
제출 전에 확인할 점
기획서 PDF와 기능 명세서 PDF가 모두 PDF 형식인지 먼저 확인하는 것이 좋습니다. 두 PDF와 웹서비스 URL이 모두 9월 7일 월요일 오전 10시 마감 기준으로 준비되는지도 함께 봐야 합니다. 제출된 웹서비스 URL은 지정된 확인 기간 동안 접근 가능해야 하므로 로그인, 권한, 배포 상태를 따로 점검해 두는 편이 안전합니다. 제출 마감 이후 산출물 수정이 제한될 수 있으므로 파일명과 버전명은 마지막에 통일해 두는 것이 좋고, 타인의 코드, 데이터, 아이디어 사용 범위는 기획서나 명세서 안에서 설명 가능한 상태로 남겨 두는 편이 좋습니다.
짧게 정리하는 FAQ
기획서에 기능 화면을 넣어도 될까요?
넣을 수는 있습니다. 다만 기획서는 문제와 해결 방향을 설득하는 역할이 먼저이고, 실제 화면 확인 경로는 기능 명세서와 URL에서 더 분명하게 보여야 합니다.
기능 명세서가 기획서보다 짧아도 괜찮을까요?
괜찮습니다. 중요한 것은 길이가 아니라 심사자가 URL에서 확인할 핵심 기능, 화면 순서, 입력과 결과를 빠르게 따라갈 수 있는지입니다.
오늘 바로 할 한 가지는 무엇일까요?
기획서 PDF 목차와 기능 명세서 PDF 목차를 나란히 열고, 같은 제목이 반복되는 부분을 표시해 보면 됩니다. 반복되는 설명은 기획서에는 문제와 이유로, 기능 명세서에는 화면과 동작으로 다시 나누면 제출물의 역할이 더 선명해집니다.
참고 자료
기준일: 2026년 7월 31일 05:04 KST. 일정, 제출물, 평가 흐름은 변경될 수 있으므로 제출 전에는 공식 대회 페이지에서 최신 내용을 다시 확인하는 것이 좋습니다.
여러분 팀은 기획서와 기능 명세서의 경계를 어디에서 가장 자주 헷갈리셨나요?