2026학년도 고등학교 미래인재 프론티어 리더 양성 사전 캠프

Tech/Product Summary (What This Camp Teaches)

1) App-Building Workflow: 2-Day “Make & Release” Plan

• Camp theme: “Solve a Busan Sea problem with an app.”
• Teams: Targeting 4 students per team
• Teams select a real Busan marine issue, then personally create and deploy a web app to address it.
• The camp follows Vibe Coding:
  • Use AI to generate code from prompts
  • Iterate through testing + bug fixing

2) Pre-Camp Requirements / Tutorial Videos

Before camp, you must:

1. Watch Part 1 (this video): learn how to identify the problem and plan the app
2. Watch Part 2: learn Vibe Coding with AI (creating apps via prompting)
3. Research maritime issues in Busan before arriving (collect inconveniences from news and/or personal experiences)

3) AI Coding Tools & Model Choice (GPT/Codex via “ChaechiT”)

• Speakers emphasize “Codex” as the most stable coding tool at the time.
• Because free usage can hit token limits, the camp plans to provide paid accounts.
• The camp uses OpenAI Codex (naming may vary in description—e.g., “Codex” vs “Chaechi…” / “CodingA” nomenclature confusion—though functionally it’s the AI coding app).
• Model guidance:
  • References to 5.6 variants (e.g., Terra/Lite/Solar/Ultra style variants)
  • Recommendation: 5.6 Lite / standard-speed as a practical balance of token usage and performance
  • Warning: larger models can burn tokens extremely fast, risking running out mid-camp

4) Why the App Is a Webpage (Not Native Mobile)

They choose a webpage app to avoid:

• App store review and publication complexity/cost
• Differences between iOS/Android builds

Trade-off:

• Webpages are easy to access from any device with internet
• But they have limited phone-level permissions (e.g., location / push notification complexity)

5) Core “Problem Framing” Method

A structured way to narrow the target user’s problem:

• Break it down into: who / when / what (magnitude) / app intervention

Example:

• “trash + glass shards causing injuries during Gwangalli cleanup”
  • Reframe from “garbage is the problem” → “a specific person is harmed and can’t continue walking”

Emphasis:

• Hypotheses must be plausible and interpretable, not just statistics-driven
• Even if statistics exist, they don’t automatically prove user inconvenience—interpretation matters

6) Vibe Coding Loop: Prompt → Generate → Run → Report Errors → Regenerate

The process:

1. Write a sufficiently specific prompt
2. Let the AI generate code (webpage)
3. Run/verify it
4. If there’s a bug, paste the error message back to the AI and request a fix

Note: Even with the same prompt, LLM output can vary due to LLM variability.

7) Safety/Permissions: “Full Access” vs “Approval” Mode

They discuss Codex permission settings:

• Full authority can be convenient, but risky (e.g., potential file deletion)
• For camps, it may be acceptable on rental camp machines, but:
  • Prefer scoped/approved actions
  • Confirm that changes stay within the intended folder/scope

Key practice: Even when granting permissions, review what the AI modifies.

---

Deployment & Collaboration Stack (GitHub + Public Publishing Like GitHub Pages)

8) Version Control Concepts: Git → GitHub

• Git is explained as:
  • change history / version control
  • the ability to roll back to earlier “save points”
• GitHub is explained as:
  • remote storage on the internet
  • supporting backup, distribution, and collaboration

They also introduce terms like commit and repository, and highlight rollback as a key safety net.

9) Live Distribution via “GitHub Pages” / Public URL

After generating the webpage, the AI publishes it to a public address:

• The goal is not only personal execution
• It’s sharing a URL so others can access the app

10) Collaboration Problem: Ranking Disappears Without Shared Storage

They explain that local browser storage isn’t shared between users.

Solution taught: add a database so all users write/read the same data.

---

Database Tutorial (Google Firebase / Firestore-Like)

11) Firebase for Shared State (e.g., Rankings)

They use Google Firebase to store:

• date
• user nickname
• score

Firebase is described as:

• enabling data persistence
• supporting shared rankings
• solving the “data not synchronized between devices” issue

12) Free-Tier Requirement

They strongly emphasize using the free plan:

• Students should request free usage in prompts
• During setup, students should check prompts/options to avoid paid plans

13) Firebase Setup Procedure (AI + Manual Confirmation)

Students are guided through:

• logging in via a camp-provided Google education account (or personal Google account at home)
• sometimes manually clicking “I agree”
• configuring region (e.g., US or South Korea)
• monitoring usage percentage (e.g., “88%” displayed)

---

Demo Project Used in the Tutorial

• The speaker uses a Brick-breaker game as the hands-on example:
  • dark/light themes
  • ranking display
  • bug fixing (e.g., collision “passes through bricks,” choppy keyboard movement)

What the demo illustrates:

• iterative prompt-based development
• debugging with AI by feeding error reports
• ranking syncing backed by the database

---

Key Review / Analysis Notes (Instructional, Not a Product Review)

• Token cost is a major constraint: large models can become economically/operationally inefficient versus smaller models or more careful iteration.
• App usefulness depends on more than code quality:
  • it must have a reason people will use it
  • it must be accessible to the intended users (especially smartphone accessibility)

---

Main Speakers / Sources (At End)

• Moses Yong — described as an information technology teacher at Seoul Science High School and the primary narrator/instructor.
• Background references include:
  • Korea Meteorological Agency (rip current forecasts)
  • various news sources about Busan maritime issues and topics like tuna/bluefin tuna quotas
• Instruction is primarily attributed to Moses Yong.