GGrigent Guide생활·AI·개발 실전 가이드
← 전체 글

GUIDE 22 · 공모전

공모전 기획서의 문제·근거·실행을 한 줄로 연결하는 법

멋진 기능 목록보다 문제 증거, 대상 사용자, 해결 가설, 검증 결과와 실행 계획을 연결하는 기획서 작성 순서입니다.

공모전 기획서의 문제·근거·실행을 한 줄로 연결하는 법 주제를 표현한 편집 일러스트
Grigent Guide 제작 · AI 편집 일러스트
Grigent Guide 편집 기준본문 출처 2개조회 1공식 원문의 날짜·버전·조건 재확인

공모전 기획서는 아이디어의 참신함보다 “문제가 실제로 있고, 그 해결책이 작동할 것이라는 근거”를 얼마나 설득력 있게 연결하느냐로 평가받는 경우가 많습니다. 이 가이드는 문제 정의, 근거, 기존 대안 비교, 검증 가설, 시제품 테스트, 팀·일정·예산, 위험과 한계를 한 줄로 이어지게 구성하는 방법을 설명합니다.

먼저 읽는 핵심 요약

이 글의 실행 지도대상·상황·문제 정의 → 주장별 근거·대안 비교 → 실행·측정 계획 연결GRIGENT GUIDE · ACTION MAP01대상·상황·문제 정의02주장별 근거·대안 비교03실행·측정 계획 연결본문을 적용하는 순서 · 공식 포스터가 아닌 편집 도해
이 글의 실행 지도
  1. 대상·상황·문제 정의
  2. 주장별 근거·대안 비교
  3. 실행·측정 계획 연결
Grigent Guide 제작 · 자세한 조건과 근거는 본문에서 확인하세요.
01

1. 문제를 대상·상황·손실로 적습니다

많은 사람이 불편하다는 표현 대신 누가 언제 어떤 일을 하다가 시간, 비용, 기회 또는 안전을 잃는지 적으세요. 한 문장 문제 정의가 넓으면 사용자 집단과 상황을 먼저 줄입니다.

  • “누가·언제·무엇을 하다가·무엇을 잃는지” 형식으로 한 문장 작성
  • 대상 집단이 넓으면 하나의 상황으로 좁히기
02

2. 주장마다 확인 가능한 근거 연결

통계, 인터뷰, 관찰과 기존 서비스 데이터를 구분하고 원문 URL, 조사 시기와 표본을 기록하세요. 수치가 없으면 없다고 밝히고 어떤 실험으로 확인할지 계획합니다.

  • 주장마다 출처 URL·조사 시기·표본 수 기록
  • 근거가 없는 주장은 “검증 예정”으로 표시
03

3. 기존 대안과 실패 이유를 공정하게 비교

경쟁 서비스가 없다고 단정하기보다 사용자가 지금 쓰는 수작업, 검색, 메신저와 엑셀까지 대안으로 봅니다. 기존 방식이 잘하는 점과 해결하지 못한 조건을 함께 적으세요.

  • 사용자가 지금 쓰는 수작업·도구를 대안 목록에 포함
  • 기존 방식의 장점도 공정하게 적기
04

4. 기능이 아니라 검증할 가설을 제시

우리 앱은 AI를 사용한다보다 특정 사용자가 특정 작업 시간을 줄일 것처럼 확인 가능한 가설을 세우세요. AI나 공공데이터는 문제 해결 수단이며 그 자체가 사용자 가치가 아닙니다.

  • “누가 무엇을 얼마나 줄인다” 형태의 가설로 작성
  • 가설을 확인할 측정 지표 정하기
05

5. 작은 시제품과 행동 지표로 검증

설명에 대한 호감보다 사용자가 실제로 과업을 완료했는지, 다시 쓰는지와 오류가 줄었는지를 봅니다. 테스트 참가 조건, 수행 시간, 실패와 개선 내용을 함께 기록하세요.

  • 종이 시제품이나 간단한 화면으로 5명 이상 테스트
  • 과업 완료 여부와 걸린 시간 기록
06

6. 팀·일정·예산을 결과물에 연결

역할 이름만 쓰지 말고 각 단계의 책임자, 주별 산출물, 필요한 데이터·외부 승인과 비용을 연결하세요. 일정이 늦어질 때 줄일 범위와 반드시 지킬 핵심을 구분합니다.

  • 단계별 책임자·산출물·비용을 한 표로 연결
  • 일정 지연 시 줄일 범위 미리 정하기
07

7. 위험과 한계를 먼저 밝힙니다

개인정보, 저작권, 데이터 품질, 운영 비용과 사용자 안전 문제를 숨기지 말고 완화 방법과 중단 기준을 적으세요. 심사 기준 문구를 반복하는 것보다 검증 가능한 실행 계획이 설득력을 높입니다.

  • 개인정보·저작권·운영 비용 위험과 완화책 기술
  • 중단 기준 명시
08

자주 하는 실수

기획서에서 가장 흔한 약점은 문제는 크게 쓰고 근거는 작게 쓰는 것입니다. “많은 사람이 불편해한다”는 표현은 심사자가 확인할 방법이 없고, 기능 목록만 길게 나열하면 무엇을 검증할지 보이지 않습니다.

  • 출처 없는 통계나 과장된 시장 규모 인용
  • 경쟁 서비스가 없다고 단정하기
  • 기능 나열을 해결책 설명으로 대신하기
  • 위험 요소를 숨기고 장점만 쓰기
09

적용 예시

가상의 예로, 대학 신입생의 수강신청 혼란을 다루는 기획서를 쓴다고 해 보겠습니다. 문제는 “신입생이 수강신청 첫날 시간표 충돌을 확인하지 못해 필수 과목을 놓친다”로 좁히고, 학과 선배 8명 인터뷰 결과를 근거로 제시합니다. 기존 대안인 학교 포털과 엑셀 시간표를 비교해 충돌 경고가 없다는 한계를 적고, “충돌 알림으로 재신청 횟수가 줄어든다”는 가설을 세웁니다. 종이 시제품으로 신입생 6명을 테스트한 결과와 개선점을 함께 제출합니다.

KEEP IT CURRENT

다시 확인할 때

내용 업데이트:

  • 심사 기준이나 배점이 바뀐 경우
  • 인터뷰·실험 결과가 추가된 경우
  • 팀 역할과 예산이 달라진 경우
OFFICIAL SOURCES

공식 자료에서 다시 확인

본문의 판단 기준과 실행 순서는 아래 공식 자료를 참고했습니다. 적용 전 최신 원문을 다시 확인하세요.

행정안전부: 범정부 공공데이터 활용 창업경진대회 공고 사례 ↗공공데이터포털 ↗