2026 금융 AI Challenge, 마감 전에 필요한 것은 기능보다 코드 출처 기록입니다 | DAKER 커뮤니티

오늘 코드를 만지는 팀이라면 새 기능을 더 붙이기 전에, 어떤 코드와 데이터가 어디서 왔는지 한 줄씩 남겨두는 것이 좋습니다. 2026년 7월 27일 05:05 KST 기준 공식 대회 페이지는 본선 진출자가 최종 소스 코드 ZIP을 제출해야 하며, 제출한 코드와 데이터와 아이디어에 대한 책임도 참가자에게 있다고 안내합니다. 마감 직전에 출처를 되짚기 시작하면 기능 개발보다 더 큰 리스크가 될 수 있습니다.

2026 금융 AI Challenge는 AI 기반 금융 현안 해결 아이디어를 실제 작동 가능한 웹서비스 MVP로 구현해 제출하는 흐름입니다. 첫 마감에는 기획서 PDF, 기능 명세서 PDF, 웹서비스 URL이 필요하고, 발표 심사 대상자는 이후 최종 발표 자료 PDF와 최종 소스 코드 ZIP을 제출합니다. 그래서 지금의 MVP 개발 기록은 단순한 팀 내부 메모가 아니라, 나중에 제출물 책임을 설명하는 근거가 됩니다.

왜 코드 출처를 지금 남겨야 할까요

공식 규칙은 참가자가 제출한 공모전 기획서, 소스 코드, 웹서비스 URL, 발표자료 등 모든 산출물에 대한 책임을 진다고 안내합니다. 또한 타인의 저작물, 코드, 데이터, 아이디어를 무단으로 사용하거나 표절하면 심사 제외 또는 수상 취소 처리될 수 있다고 밝힙니다. 이 문장은 단순한 경고가 아니라, 팀이 매일 남겨야 할 개발 기록의 기준으로 읽는 것이 맞습니다.

작동하는 MVP를 만드는 일과 코드와 데이터의 출처를 정리하는 일은 따로 가지 않습니다.

AI를 활용해 빠르게 MVP를 만들수록 화면은 빨리 나오지만, 어떤 부분이 직접 작성한 코드이고 어떤 부분이 외부 예시에서 온 코드인지 흐려지기 쉽습니다. 공식 페이지가 요구하는 것은 실제 작동 가능한 웹서비스입니다. 동시에 최종 소스 코드 제출과 산출물 책임 규칙도 함께 있으므로, 작동 여부와 출처 정리는 같은 시점에 관리하는 편이 좋습니다.

무엇을 남기면 충분할까요

처음부터 거창한 개발 문서를 만들 필요는 없습니다. 오늘은 팀원이 함께 볼 수 있는 짧은 기록부터 시작하면 됩니다. 핵심은 나중에 코드 ZIP을 열었을 때 이 기능이 왜 있고, 무엇을 참고했고, 어떻게 실행되는지 바로 확인할 수 있게 만드는 것입니다.

핵심 기능마다 담당자, 화면 이름, 구현 위치, 현재 작동 상태를 적어두면 기본 뼈대가 생깁니다. 여기에 외부 예시, 공개 라이브러리, 샘플 데이터, 생성형 AI 도움을 받은 부분은 사용 목적과 수정 내용을 분리해 남기면 설명 가능성이 높아집니다. 또 기획서와 기능 명세서에 들어간 기능명, 실제 코드 안의 메뉴명이나 컴포넌트명이 너무 멀어지지 않게 맞춰두는 것이 좋습니다.

웹서비스 URL에서 심사자가 눌러 볼 대표 흐름을 정하고, 그 흐름을 실행하는 데 필요한 환경 조건도 함께 남겨두면 나중에 제출 범위를 정리하기 쉬워집니다. 마감 전에는 기획서 PDF, 기능 명세서 PDF, URL, 코드 기록이 같은 기능 범위를 말하는지 다시 확인하면 됩니다.

AI로 만든 코드는 어떻게 봐야 할까요

공식 페이지는 특정 개발 방식이나 AI 도구 사용법을 따로 안내하지 않습니다. 그래서 공개 글에서 확인되지 않은 도구 활용 규칙을 임의로 만들 필요는 없습니다. 다만 참가자가 모든 산출물에 책임을 진다는 규칙은 그대로 적용됩니다. AI가 만든 코드라도 팀 서비스에 들어간 순간, 그 코드는 팀이 이해하고 검토한 제출물의 일부가 됩니다.

누가 만들었는가보다 팀이 무엇을 확인했는가가 더 중요합니다.

실전에서는 결과 문구, 위험 안내, 입력값 처리, 예외 상황을 팀이 어디까지 검토했는지가 중요합니다. 금융소비자를 대상으로 하는 서비스라면 화면 문장 하나도 사용자 행동에 영향을 줄 수 있습니다. 특히 보이스피싱 대응, 금융 매칭, 포용금융처럼 공식 세부 주제 예시에 가까운 서비스일수록, 코드뿐 아니라 화면에 드러나는 문장과 데이터 사용 방식까지 함께 살펴보는 편이 좋습니다.

제출 직전에 자주 놓치는 부분

기능 명세서에는 있는 기능인데 코드에서는 임시 이름이나 실험용 이름으로 남아 있는 경우가 있습니다. 샘플 데이터와 실제 입력 데이터의 구분이 화면 설명에서 사라지는 경우도 많습니다. 외부 예시를 참고한 부분이 어느 기능에 들어갔는지 팀원 사이의 기억에만 남아 있거나, URL은 작동하지만 다시 배포하거나 설명할 때 필요한 실행 조건이 정리되어 있지 않은 경우도 있습니다. 발표 심사 대상자가 된 뒤 소스 코드 ZIP을 만들 때 불필요한 실험 파일이 함께 섞이는 문제도 이 단계에서 자주 드러납니다.

짧게 정리하는 FAQ

최종 소스 코드 ZIP은 본선 진출자만 제출하니 지금은 미뤄도 될까요

미루지 않는 편이 좋습니다. 공식 일정상 최종 소스 코드 ZIP은 발표 심사 대상자 산출물에 포함되지만, 그때 새로 출처와 실행 경로를 복원하기는 어렵습니다. 오늘 만든 기능부터 기록해두면 나중에 제출 범위를 정리하기 쉬워집니다.

오픈소스 라이브러리를 쓰면 불리할까요

공식 페이지는 특정 라이브러리 사용 제한을 따로 설명하지 않습니다. 다만 타인의 코드, 데이터, 아이디어를 무단으로 사용하거나 표절하면 문제가 될 수 있다고 안내합니다. 사용 목적과 적용 범위, 팀이 수정한 내용을 남겨두는 것이 안전합니다.

오늘 가장 먼저 하면 좋은 일은 무엇일까요

기능 세 개를 골라 기능명, 실제 화면, 구현 위치, 참고 출처, 검토한 사람을 한 줄씩 적어보면 됩니다. 이 다섯 칸이 채워지면 기획서와 기능 명세서와 코드가 같은 제출물로 묶이기 시작합니다.

참고 자료

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

여러분 팀은 지금 어떤 방식으로 코드와 데이터 출처를 기록하고 있나요?