[리서치] 2026 금융 AI Challenge: 질문 로그로 추측을 줄이세요 | DAKER 커뮤니티

오늘 팀 안에서 “이게 맞나?”라는 말이 두 번 이상 나왔다면, 그 질문을 그냥 채팅에 흘려보내지 마세요. 2026년 7월 29일 05:01 KST 기준 공식 대회 페이지는 공식 답변이 게시판을 통해서만 제공된다고 안내합니다. 기획서 PDF, 기능 명세서 PDF, 웹서비스 URL이 같은 말을 하려면 팀의 질문과 결정도 한곳에 남아 있어야 합니다.

이 대회는 AI 기반 금융 현안 해결 아이디어를 실제 작동 가능한 웹서비스로 구현하는 공모전입니다. 참가자는 2026년 9월 7일 월요일 오전 10시까지 기획서와 MVP 산출물을 제출해야 하고, 제출한 웹서비스 URL은 같은 날 오전 11시부터 9월 11일 금요일 23시 59분까지 접근 가능해야 합니다. 제출 마감 이후 산출물 수정이 제한될 수 있고, 요청 자료를 기한 내 제출하지 않거나 제출물이 누락되면 결격 처리될 수 있다는 점도 오늘 확인했습니다.

왜 질문 로그가 필요할까요?

팀 프로젝트에서 위험한 순간은 질문이 생기는 순간이 아니라, 답이 흐릿한 채로 문서와 화면이 서로 다른 방향으로 굳어지는 순간입니다. 한 사람은 “청년층 자산 형성 서비스”라고 쓰고, 다른 사람은 “소상공인 금융 매칭 서비스” 화면을 만들고, 또 다른 사람은 기능 명세서에 보안 비서 흐름을 넣으면 제출 직전에 맞추기 어렵습니다.

공식 페이지는 세부 주제 예시가 참고용이며 주제 범위 안에서 자유롭게 선정할 수 있다고 안내합니다. 그래서 더더욱 팀의 선택 기준을 남겨야 합니다. 공식 페이지에 있는 조건과 팀이 정한 해석을 분리해 적어 두면, 기획서와 MVP를 고칠 때 “누가 그렇게 말했는지”보다 “어떤 근거로 그렇게 정했는지”를 빠르게 확인할 수 있습니다.

• 공식 페이지에서 확인한 사실과 팀의 해석을 같은 문장에 섞지 않습니다.
• 게시판에 문의해야 할 질문은 개인 메신저나 회의 메모로만 끝내지 않습니다.
• 기획서, 기능 명세서, 웹서비스 화면에 같은 대상 사용자와 같은 문제 문장을 씁니다.
• 제출물 누락이나 URL 접근 불가처럼 결격으로 이어질 수 있는 항목은 질문 로그에서 따로 표시합니다.
• 확인되지 않은 수상 가능성, 후속 지원, 외부 연계 약속은 결정 로그에 넣지 않습니다.

오늘 어떤 순서로 정리하면 될까요?

질문 로그는 거창한 문서가 아니어도 됩니다. 팀원이 같은 기준으로 움직일 수 있으면 충분합니다. 오늘은 새 기능을 만들기 전에 아래 다섯 줄만 먼저 맞춰 보세요.

1. 공식 페이지에서 확인한 조건을 “사실” 칸에 적습니다. 예를 들어 제출 기한, 제출물, URL 접근 가능 기간, 팀 최대 인원 같은 항목입니다.
2. 우리 팀이 선택한 대상 사용자와 금융 현안을 “팀 결정” 칸에 한 문장으로 적습니다.
3. 공식 페이지만으로 판단하기 어려운 내용은 “문의 필요”로 표시하고, 공식 게시판에 남길 질문 문장으로 바꿉니다.
4. 답을 받은 뒤에는 기획서 PDF, 기능 명세서 PDF, 웹서비스 화면 중 어디를 고쳐야 하는지 바로 연결합니다.
5. 마감 전 최종 점검 때는 질문 로그에서 아직 답이 없는 항목과 제출물에 반영되지 않은 결정을 먼저 지웁니다.

어떤 질문을 남기면 실전에 도움이 될까요?

좋은 질문은 “이 기능 넣어도 되나요?”처럼 넓게 묻는 대신, 제출물과 심사 흐름에 바로 영향을 주는 형태로 좁혀져 있습니다. 예를 들어 웹서비스 URL 접근 가능 기간 동안 외부 인증이 필요한 구조라면, 심사자가 접근할 수 있는 경로를 어떻게 준비할지 팀 안에서 먼저 정리해야 합니다. 공식 페이지는 접근 불가를 결격 사유로 안내하므로, 이 질문은 개발 편의가 아니라 제출 안정성의 문제입니다.

기능명세서도 마찬가지입니다. AI 결과가 추천, 경고, 매칭, 탐지 중 무엇인지 팀 안에서 다르게 말하고 있다면 화면을 더 만들기 전에 용어부터 통일해야 합니다. 질문 로그는 이 용어를 고정하는 곳입니다. 오늘 하나만 고른다면 “심사자가 URL을 열었을 때 첫 화면에서 어떤 사용자, 어떤 금융 현안, 어떤 AI 행동을 보게 할 것인가”를 적어 보세요.

제출물에 반영할 때 조심할 점

• 공식 페이지의 문구를 그대로 길게 복사하기보다, 제출물에서 확인할 행동 기준으로 바꿉니다.
• 게시판 답변을 받기 전에는 확정 표현을 쓰지 않고, 내부 가정으로 표시합니다.
• 팀 결정이 바뀌면 기능 명세서의 화면 이름과 웹서비스의 버튼 문구를 같이 바꿉니다.
• 발표 심사까지 이어질 수 있는 핵심 결정은 최종 발표 자료 PDF에도 같은 용어로 남길 수 있게 관리합니다.

짧은 FAQ

공식 페이지에 없는 내용을 팀이 정해도 되나요?

주제 범위 안에서 팀의 서비스 설계는 필요합니다. 다만 공식 페이지에 없는 운영 조건이나 혜택을 확정된 사실처럼 쓰면 안 됩니다. 팀 결정과 공식 근거를 분리해 적어 두세요.

질문 로그를 공개 제출물에 넣어야 하나요?

그럴 필요는 없습니다. 질문 로그는 팀 내부 정합성을 맞추기 위한 작업 도구입니다. 공개 제출물에는 최종 결정이 반영된 문제 정의, 기능 흐름, URL 동작 상태만 깔끔하게 남기면 됩니다.

오늘 바로 확인할 한 가지는 무엇인가요?

기획서 첫 문장, 기능 명세서 첫 화면, 웹서비스 첫 화면이 같은 대상 사용자와 같은 금융 현안을 말하는지 확인하세요. 셋이 다르면 질문 로그에 원인을 적고 하나의 표현으로 맞추는 것이 먼저입니다.

기준일: 2026년 7월 29일 05:01 KST. 일정, 제출물, 평가 흐름은 변경될 수 있으므로 제출 전에는 공식 대회 페이지에서 최신 내용을 다시 확인하세요.