화면으로 말하는가
시작, 플레이, 피드백, 결과, 배포 URL을 먼저 보여주는지 봅니다.
외주 상담에서 가장 시간이 오래 걸리는 부분은 “무엇을 만들지”가 아니라 “어디까지 만들지”입니다. 아래 항목이 있으면 첫 답변에서 가능한 범위와 빠지는 범위를 같이 말할 수 있습니다.
“재밌는 게임 하나”, “간단한 퀴즈”, “관리자도 있으면 좋겠다”처럼만 적힌 문의는 바로 산정하기 어렵습니다. 간단해 보이는 요청 안에 로그인, 저장, 개인정보, 관리자, 외부 연동이 숨어 있는 경우가 많기 때문입니다.
| 상황 | 먼저 볼 페이지 |
|---|---|
| 교육 콘텐츠를 게임으로 만들고 싶음 | 교육용 게임·수료형 퀴즈 |
| 제품이나 서비스를 게임으로 설명하고 싶음 | 웹게임 제작 |
| 작은 게임부터 공개하고 싶음 | 소형 웹게임 제작 |
| 결과 저장과 다운로드가 필요함 | 점수 저장·관리자 포함 웹게임 |
| 아이디어를 보여줘야 함 | 프로토타입·PoC |
| 경품/쿠폰/참여자 운영이 있음 | 이벤트·프로모션 캠페인 |
시작, 플레이, 피드백, 결과, 배포 URL을 먼저 보여주는지 봅니다.
개인정보, 경품, 외부 API, 고급 그래픽, 모든 기기 QA가 1차에 들어가는지 분리해야 합니다.
테스트 URL, 검수 기준, 소스/배포 권한, 유지보수 기간이 계약 전에 보여야 합니다.
게임 화면은 비교적 빨리 상상되지만, 오픈 뒤에 누가 문항을 바꾸는지, 결과 파일을 누가 받는지, 서버와 도메인은 어디에 둘지에서 일이 커지는 경우가 많습니다. 검수 기기와 수정 회차, 소스코드 인수 여부, 오픈 후 유지보수 기간도 계약 전에 정해야 합니다.
교육, 서비스, 제품에 붙는 웹게임이면 g.swagency.kr 기준으로 상담합니다. 경품, 쿠폰, 참여자 명단, 현장 운영, 대량 접속 리포트가 중심이면 이벤트·프로모션 캠페인형으로 보고 별도 페이지에서 예산과 운영 조건을 먼저 확인하는 편이 정확합니다.
| 항목 | 확인 질문 | 결정 기준 |
|---|---|---|
| 산출물 | HTML/JS/CSS 소스, 이미지, 배포 파일, 운영 문서 중 무엇을 받는가 | 운영 주체와 후속 개발 가능성 |
| 검수 | 검수 브라우저, 모바일 기기, 수정 회차, 완료 기준은 무엇인가 | 오픈일과 QA 책임 범위 |
| 저작권·사용권 | 납품 후 사용 범위, 재사용 가능 범위, 외부 리소스 라이선스는 무엇인가 | 고객사 서비스 운영 방식 |
| 유지보수 | 오픈 후 오류 대응, 콘텐츠 수정, 서버 이전 범위가 포함되는가 | 운영 기간과 예산 |
관리자, 개인정보, 경품, 외부 API, 고급 그래픽, 다기기 QA를 빼면 단일 화면 인터랙션, 소형 웹게임, 눌러보는 데모로 시작할 수 있습니다. 반대로 이 항목들이 모두 들어가면 작은 게임처럼 보여도 외주 범위는 커집니다.
사용 목적: 교육 / 제품 체험 / 서비스 온보딩 / 소형 게임 / 데모
대상 사용자: 임직원 / 고객 / 학생 / 전시 관람객 / 내부 심사자
게임 유형: 퀴즈 / 퍼즐 / 카드 / 미션 / 튜토리얼 / 기타
필수 화면: 시작 / 플레이 / 피드백 / 결과 / 문의 또는 다음 행동
저장 데이터: 없음 / 점수 / 랭킹 / 수료 결과 / 관리자 / CSV / 외부 연동
빼도 되는 것: 개인정보 / 경품 / 고급 그래픽 / 대량 트래픽 / 모든 기기 QA
예산과 일정: 희망 예산, 오픈일, 검수 기간
교육, 제품 체험, 소형 게임, 데모 중 어디에 가까운지 먼저 비교합니다.

공공 안전교육 게임

제품 이해형 퀴즈

기억력·매칭 게임

보드게임형 웹게임
됩니다. 사용할 곳, 예산, 일정, 저장할 데이터만 적어도 답변이 빨라집니다. 다만 “게임 하나”만으로는 화면 수, 룰, 저장 범위를 알 수 없어 견적이 늦어집니다.
맡길 수 있습니다. 단, 저가 전체 제작이 아니라 화면 수와 기능이 고정된 소형 웹게임, 프로토타입으로 봅니다. 관리자, 개인정보, 경품, 외부 연동을 빼야 작게 끝납니다.
캠페인은 경품, 쿠폰, 참여자 명단, 현장 운영, 리포트가 중심입니다. 여기서는 교육, 서비스, 제품에 붙는 웹게임을 먼저 다룹니다. 게임 룰이 작아도 운영 책임이 크면 캠페인형으로 분리합니다.
누가 플레이하고, 끝나면 무엇을 보여줘야 하는지부터 정하면 됩니다. 그 다음 저장할 데이터와 빼도 되는 일을 적습니다. 이 두 가지가 있어야 화면 수와 개발 범위를 현실적으로 잡을 수 있습니다.
사용 목적, 플레이어, 게임 유형, 필수 화면, 저장 데이터, 예산, 일정, 제외할 일을 한 장으로 정리하면 됩니다. 내부 결재가 있다면 “1차에 만들 것”과 “후속으로 넘길 것”을 나눠 적는 편이 좋습니다.