[리서치] 2026 금융 AI Challenge: 코드 출처를 오늘 남기세요 | DAKER 커뮤니티
오늘 코드를 만지는 팀이라면 새 기능을 더 붙이기 전에, 어떤 코드와 데이터가 어디서 왔는지 한 줄씩 남기세요. 2026년 7월 27일 05:05 KST 기준 공식 대회 페이지는 본선 진출자가 최종 소스 코드 ZIP을 제출해야 하며, 제출한 코드와 데이터와 아이디어에 대한 책임도 참가자에게 있다고 안내합니다. 마감 직전에 출처를 되짚으면 기능보다 더 큰 리스크가 됩니다.
2026 금융 AI Challenge는 AI 기반 금융 현안 해결 아이디어를 실제 작동 가능한 웹서비스 MVP로 구현해 제출하는 흐름입니다. 첫 마감에는 기획서 PDF, 기능 명세서 PDF, 웹서비스 URL이 필요하고, 발표 심사 대상자는 이후 최종 발표 자료 PDF와 최종 소스 코드 ZIP을 제출합니다. 그래서 지금의 MVP 개발 기록은 단순한 팀 내부 메모가 아니라, 나중에 제출물 책임을 설명하는 근거가 됩니다.
왜 코드 출처가 오늘 중요할까요?
공식 규칙은 참가자가 제출한 공모전 기획서, 소스 코드, 웹서비스 URL, 발표자료 등 모든 산출물에 대한 책임을 진다고 안내합니다. 또한 타인의 저작물, 코드, 데이터, 아이디어를 무단으로 사용하거나 표절하면 심사 제외 또는 수상 취소 처리될 수 있다고 밝힙니다. 이 문장은 겁을 주기 위한 문구가 아니라, 팀이 매일 남겨야 할 개발 기록의 기준입니다.
AI를 활용해 빠르게 MVP를 만들수록 화면은 빨리 나오지만, 어떤 부분이 직접 작성한 코드이고 어떤 부분이 외부 예시에서 온 코드인지 흐려지기 쉽습니다. 공식 페이지가 요구하는 것은 실제 작동 가능한 웹서비스입니다. 동시에 최종 소스 코드 제출과 산출물 책임 규칙이 있으므로, 작동 여부와 출처 정리가 같이 가야 합니다.
- 외부 코드나 예시를 참고했다면 파일명보다 기능 단위로 출처와 적용 범위를 남겨야 합니다.
- 데이터나 문장 예시를 사용했다면 실제 서비스 화면에서 어떤 목적으로 쓰였는지 구분해야 합니다.
- AI가 생성한 코드도 팀이 검토하고 수정한 기준을 남겨야 나중에 설명하기 쉽습니다.
- 기능 명세서에 적은 기능과 실제 코드 안의 구현 위치가 너무 멀어지지 않게 관리해야 합니다.
- 제출 후 산출물 수정이 제한될 수 있으므로 출처 정리는 마감 직전이 아니라 개발 중에 해야 합니다.
무엇을 남기면 충분할까요?
처음부터 거창한 개발 문서를 만들 필요는 없습니다. 오늘은 팀원이 함께 볼 수 있는 짧은 기록부터 시작하면 됩니다. 핵심은 “나중에 코드 ZIP을 열었을 때 이 기능이 왜 있고, 무엇을 참고했고, 어떻게 실행되는지”를 바로 확인할 수 있게 하는 것입니다.
- 핵심 기능마다 담당자, 화면 이름, 구현 위치, 현재 작동 상태를 적습니다.
- 외부 예시, 공개 라이브러리, 샘플 데이터, 생성형 AI 도움을 받은 부분은 사용 목적과 수정 내용을 분리해 씁니다.
- 기획서와 기능 명세서에 들어간 기능명과 코드 안의 메뉴명 또는 컴포넌트명을 맞춥니다.
- 웹서비스 URL에서 심사자가 눌러 볼 대표 흐름을 정하고, 그 흐름을 실행하는 데 필요한 환경 조건을 남깁니다.
- 마감 전에는 기획서 PDF, 기능 명세서 PDF, URL, 코드 기록이 같은 기능 범위를 말하는지 다시 확인합니다.
AI로 만든 코드는 어떻게 다뤄야 할까요?
공식 페이지는 특정 개발 방식이나 AI 도구 사용법을 안내하지 않습니다. 그래서 공개 글에서 확인되지 않은 도구 활용 약속을 만들 필요는 없습니다. 다만 참가자가 모든 산출물에 책임을 진다는 규칙은 그대로 적용됩니다. AI가 만든 코드라도 팀 서비스에 들어간 순간, 그 코드는 팀이 이해하고 검토한 제출물의 일부가 됩니다.
실전적으로는 “누가 만들었는가”보다 “팀이 무엇을 확인했는가”가 중요합니다. 금융소비자를 대상으로 하는 서비스라면 결과 문구, 위험 안내, 입력값 처리, 예외 상황이 사용자를 오도하지 않는지 봐야 합니다. 특히 보이스피싱 대응, 금융 매칭, 포용금융처럼 공식 세부 주제 예시에 가까운 서비스는 화면 문장 하나가 사용자 행동에 영향을 줄 수 있습니다.
제출 전 자주 놓치는 지점
- 기능 명세서에는 있는 기능인데 코드에서는 임시 이름이나 실험용 이름으로 남아 있습니다.
- 샘플 데이터와 실제 입력 데이터의 구분이 화면 설명에서 사라집니다.
- 외부 예시를 참고한 부분이 어느 기능에 들어갔는지 팀원 사이에서만 기억합니다.
- URL은 작동하지만 다시 배포하거나 설명할 때 필요한 실행 조건이 정리되어 있지 않습니다.
- 발표 심사 대상자가 된 뒤 소스 코드 ZIP을 만들 때 불필요한 실험 파일까지 섞입니다.
짧은 FAQ
최종 소스 코드 ZIP은 본선 진출자만 제출하니 지금은 미뤄도 되나요?
미루지 않는 편이 좋습니다. 공식 일정상 최종 소스 코드 ZIP은 발표 심사 대상자 산출물에 포함되지만, 그때 새로 출처와 실행 경로를 복원하기는 어렵습니다. 오늘 만든 기능부터 기록하면 나중에 제출 범위를 정리하기 쉽습니다.
오픈소스 라이브러리를 쓰면 불리한가요?
공식 페이지는 특정 라이브러리 사용 제한을 따로 설명하지 않습니다. 다만 타인의 코드, 데이터, 아이디어를 무단으로 사용하거나 표절하면 문제가 될 수 있다고 안내합니다. 사용 목적과 적용 범위, 팀이 수정한 내용을 남기는 것이 안전합니다.
오늘 가장 먼저 할 일은 무엇인가요?
기능 세 개를 골라 “기능명, 실제 화면, 구현 위치, 참고 출처, 검토한 사람”을 한 줄씩 적어 보세요. 이 다섯 칸이 채워지면 기획서와 기능 명세서와 코드가 같은 제출물로 묶이기 시작합니다.
기준일: 2026년 7월 27일 05:05 KST. 일정, 제출물, 평가 흐름은 변경될 수 있으므로 제출 전에는 공식 대회 안내 페이지에서 최신 내용을 다시 확인하세요.