STEP 4 · 시범 실행 (30분)한 번 실행해 결과와 소요 시간을 기록하고, 손으로 할 때와 비교합니다.
실습 프롬프트
개인정보 주의학습 자료·자동화 대상에 타인의 이름, 연락처, 학번, 건강·성적 정보가 포함되지 않도록 하십시오. 필요하면 가명 처리 후 사용하고, 원자료는 개인 저장소에만 둡니다.
이번 주 산출물자동화 파이프라인 설계도 + 시범 실행 결과(전후 소요 시간 비교)
체크포인트
자료 5개 이상으로 도우미를 구성했다
질문 10개로 근거 인용 품질을 시험했다
트리거·처리·출력이 정의된 설계도를 만들었다
개인정보 포함 여부를 점검했다
PART 3 · 12주차
예외 처리와 레드티밍
내 해법을 가장 세게 공격해 보는 시간
학습 목표해법이 깨지는 지점을 스스로 찾아 예외 시나리오로 정리하고, 반박에 대한 대응 논리를 세운다.
이론 슬라이드 (10장)
핵심 개념
정상 경로의 착시
순서도의 “예” 경로만 보면 모든 해법은 완벽합니다. 문제는 언제나 “아니오”에서 터집니다.
세 종류의 예외
실수(오입력) · 악용(일부러) · 엣지케이스(드문 조건). 각각 대비가 다릅니다.
레드팀
내 해법을 무너뜨리는 것이 목적인 역할. AI에게 이 역할을 주면 가장 값이 큽니다.
윤리·책임
누가 피해를 볼 수 있는가, 그 피해를 누가 책임지는가. 답이 없으면 설계를 고칩니다.
실습 절차 (170분)
STEP 1 · 아니오 경로 채우기 (35분)9주차 순서도의 모든 “아니오”에 무슨 일이 일어나는지 적습니다.
▼
STEP 2 · 레드팀 공격 (55분)아래 프롬프트로 내 해법을 공격받고, 아픈 지적 5개를 그대로 기록합니다.
▼
STEP 3 · 대응 논리 수립 (45분)지적마다 ① 인정하고 고칠 것 ② 근거로 반박할 것 ③ 범위 밖으로 선언할 것을 구분합니다.
▼
STEP 4 · 윤리 점검 (35분)피해 가능 집단, 개인정보, 오작동 시 책임 소재를 표로 정리합니다.
실습 프롬프트
이번 주 산출물예외 시나리오 표 + 레드팀 반박 대응서 + 윤리 점검표
체크포인트
순서도의 모든 “아니오” 경로를 채웠다
아픈 지적 5개를 그대로 기록했다
고칠 것과 범위 밖을 구분했다
피해 가능 집단과 책임 주체를 적었다
PART 4 · 13주차
프로토타입 제작
설명하지 말고 보여 주기 — 작동하는 최소 시제품
학습 목표최소 기능 범위를 정하고, 노코드·AI 도구로 실제로 만져 볼 수 있는 프로토타입 v1을 만든다.
이론 슬라이드 (10장)
핵심 개념
MVP의 M은 최소
성공 기준 하나를 확인할 수 있는 만큼만 만듭니다. 나머지는 다 나중입니다.
가짜여도 된다
뒤에서 사람이 처리하더라도 사용자가 겪는 경험이 진짜라면 검증에는 충분합니다.
화면 흐름 먼저
첫 화면 → 핵심 행동 → 결과 확인. 세 장면이면 대부분의 흐름이 표현됩니다.
완성도의 함정
예쁘게 만들수록 사람들은 본질 대신 색깔을 지적합니다. 거칠게 유지하십시오.
실습 절차 (170분)
STEP 1 · 범위 자르기 (30분)기능 목록을 쓰고, 성공 기준 확인에 필요 없는 것을 전부 지웁니다.
▼
STEP 2 · 화면·흐름 설계 (40분)세 장면으로 사용 흐름을 그립니다. 종이도 좋습니다.
▼
STEP 3 · 제작 (70분)아래 프롬프트로 제작 명세를 만들고 노코드·AI 도구로 v1을 만듭니다.
▼
STEP 4 · 자가 시연 (30분)처음 보는 사람인 척 끝까지 써 봅니다. 막히는 지점을 전부 적습니다.
실습 프롬프트
이번 주 산출물작동하는 프로토타입 v1(링크 또는 캡처) + 사용 시나리오 대본
체크포인트
기능을 3개 이하로 잘랐다
사용 흐름을 세 장면으로 그렸다
끝까지 작동하는 v1을 만들었다
막히는 지점을 목록으로 적었다
PART 4 · 14주차
해결책 검증 · CER과 사용자 테스트
“좋아 보인다”가 아니라 근거로 말하기
학습 목표5인 이상 실사용 테스트로 데이터를 모으고, 주장–근거–추론(CER) 구조의 검증 리포트를 작성해 v2로 수정한다.
이론 슬라이드 (10장)
핵심 개념
CER 구조
주장(Claim) · 근거(Evidence) · 추론(Reasoning). 근거 없는 주장은 감상문입니다.
말 대신 행동을 보라
“좋아요”는 데이터가 아닙니다. 끝까지 했는가, 몇 초 걸렸는가가 데이터입니다.
5명의 법칙
5명만 시켜 봐도 치명적 문제의 대부분이 드러납니다. 숫자보다 관찰이 중요합니다.
실패는 결과다
가설이 틀렸다는 결론도 완전한 결과입니다. 억지로 성공으로 포장하지 마십시오.
실습 절차 (170분)
STEP 1 · 가설과 지표 확정 (30분)“이 해법을 쓰면 [무엇]이 [얼마나] 달라진다”를 반증 가능한 문장으로 씁니다.
▼
STEP 2 · 사용자 테스트 (60분)5명에게 시연 없이 써 보게 하고, 말이 아니라 행동을 기록합니다.
▼
STEP 3 · 데이터 정리·분석 (45분)아래 프롬프트로 정량·정성 데이터를 CER 구조로 정리합니다.
▼
STEP 4 · v2 수정 (35분)가장 많이 걸린 지점 1~2개만 고칩니다. 전부 고치려 하지 않습니다.
실습 프롬프트
이번 주 산출물검증 리포트(CER 구조, 데이터 시각화 포함) + 프로토타입 v2
체크포인트
가설을 반증 가능한 문장으로 썼다
5명 이상에게 힌트 없이 시켜 봤다
주장마다 데이터 근거를 붙였다
고칠 것을 1~2개로 제한했다
PART 4 · 15주차 · 기말
최종 캡스톤 · Solution Pitch
문제 – 해법 – 로직 – 검증을 8분에 증명하기
학습 목표한 학기의 문제해결 과정을 하나의 논리로 묶어 발표하고, 동료 검토를 통해 자기 해법의 한계를 명확히 진술한다.
이론 슬라이드 (10장)
최종 제출물
제출물
구성
분량
해결 로직 명세서
문제 정의 · 원인 구조 · 대안과 선정 · 순서도 · 예외 처리 · 자동화 설계
A4 8~10매
프로토타입
작동하는 v2 (링크·캡처·시연 영상 중 택1) + 사용 시나리오
―
검증 리포트
가설 · 지표 · 결과 · CER 3세트 · 한계
A4 3매
동료 검토서
동료 2인 검토 의견 + 내가 반영한 것 / 반영하지 않은 것과 이유
A4 2매
부록
사용한 프롬프트 전문, 실패한 시도 기록
제한 없음
발표 구성 (8분 + 질의 4분)
1분 · 문제구체적 장면 하나로 시작합니다. 통계는 그다음입니다.
▼
2분 · 해법과 선정 근거버린 안을 먼저 보여 주면 고른 안이 설득됩니다.
▼
2분 · 작동 시연말로 설명하지 말고 실제로 돌립니다. 실패해도 그대로 보여 줍니다.
▼
2분 · 검증 결과가설 지지 여부를 먼저 말하고, 근거 데이터를 붙입니다.
▼
1분 · 한계와 다음이 해법이 통하지 않는 조건을 스스로 밝힙니다. 이 항목이 평가에서 가장 큽니다.
마무리 프롬프트
제출물해결 로직 명세서 + 프로토타입 + 검증 리포트 + 동료 검토서 · 평가 비중 40%
체크포인트
네 가지 제출물을 모두 완성했다
발표에서 실제로 시연했다
가설 지지 여부를 명확히 말했다
해법이 통하지 않는 조건을 스스로 밝혔다
실패한 시도를 부록에 남겼다
프로젝트 제너레이터
내 프로젝트 정보를 넣으면 그대로 복사해 쓸 수 있는 지시문이 만들어집니다.
빈칸을 채우고 「프롬프트 생성」을 누른 뒤, 생성된 상자의 「복사」로 AI에 붙여넣으십시오.
생성되는 지시문은 영어입니다 — AI 응답 품질을 일정하게 유지하기 위해 프롬프트는 전 언어 공통으로 영어를 사용합니다.
문제 분해 제너레이터
1~3주차용. 문제를 원인 구조와 실행 작업으로 쪼개는 지시문을 만듭니다.
생성된 지시문 (English)
해법 발산·선정 제너레이터
5~7주차용. 아이디어를 양적으로 확장하고 가중 매트릭스로 1안을 고르는 지시문을 만듭니다.
생성된 지시문 (English)
검증 설계 제너레이터
13~14주차용. 프로토타입을 사람에게 시험해 근거를 만드는 지시문을 만듭니다.
생성된 지시문 (English)
SOOKMYUNG · PBL Ⅰ · AI PROBLEM SOLVING
PBLⅠ Learning Portal · 15 Weeks
Turn a defined problem into a working solution. Every week you build one deliverable,
copy the practice prompts as they are, and use the generators to write instructions of your own.
Fall Semester 2026 | Mon 16:00–18:50 (Myeongsin Hall 517) | Instructor: Jinhyuk Jung
Course arc Break down the problem → Diverge → Converge and select → Design the logic → Automate → Prototype → Validate → Present
Progress0 / 15 weeks completed
PART 1 · Anatomy of a problem
PART 2 · Diverge and converge
PART 3 · Logic and automation
PART 4 · Prototype and validation
PART 1 · Week 1 · Orientation
What Problem Solving Is
AI is not a magic wand — learning to spot a problem you can actually solve
Learning objectivePick the one problem you will actually solve this semester, and judge whether it is in a “solvable” shape.
Theory slides (10)
Key concepts
What makes a problem solvable
Its scope is closed, there is a standard for judging success, and you can see a result within one semester.
What AI cannot do
Decide what to solve, judge what matters, take responsibility. Those three stay with you to the end.
Three steps of computational thinking
Decomposition (split it) · pattern recognition (find what repeats) · abstraction (keep only the core). This is the skeleton of the whole course.
Finding a problem → solving one
PBLⅡ asked “what is the problem?” PBLⅠ asks “so what are you going to do about it?”
Studio procedure (170 min)
STEP 1 · Write three candidates (25 min)Write three frustrations you personally ran into in the last three months. Your problems, not someone else's.
▼
STEP 2 · Judge solvability (40 min)Score all three on scope, success criteria and timeframe with the prompt below, and drop the ones in an unsolvable shape.
▼
STEP 3 · Commit to one (45 min)Define the problem in one sentence: “who / when / because of what / loses what.”
▼
STEP 4 · Declare success criteria (60 min)Write what must be different at the end of the semester for you to say you solved it — as a number or an observable state.
Practice prompts
Deliverable this weekOne A4 page defining the problem (one-sentence problem + three levels of success criteria) + weekly reflection report
Checkpoints
Wrote three candidates and filtered them by score
Wrote the problem as one sentence: who / when / because of what / loses what
Wrote three levels of success criteria in observable form
Checked that AI did not make any decision in my place
PART 1 · Week 2
Separating Symptom from Cause
Hitting the root instead of the symptom, with 5 Whys and a logic tree
Learning objectiveSeparate the visible symptom from what produces it, and draw the cause structure as a logic tree at least three levels deep.
Theory slides (10)
Key concepts
The symptom-treatment trap
“Let's send more notifications” is usually a prescription for a symptom. If you never ask why people miss them, the problem comes back.
5 Whys
Ask why five times. The point where answers start to stall, usually the third, is where the real cause sits.
Logic tree
Spread the causes out as branches. Branches at the same level must not overlap (MECE).
Choosing where to strike
You cannot hit every cause. Pick the one with large impact that you can actually touch.
Studio procedure (170 min)
STEP 1 · List symptoms (25 min)Write six or more symptoms you observe in your Week 1 problem, as plain facts. Leave out interpretation and guesswork.
▼
STEP 2 · 5 Whys (35 min)Pick the symptom that occurs most often and dig five levels down. If you end at "people are lazy," you failed.
▼
STEP 3 · Build the logic tree (60 min)Use the prompt below to spread the cause structure at least three levels, then clean up overlapping branches by hand.
▼
STEP 4 · Mark the strike point (50 min)Place the causes on two axes, impact × controllability, and mark the 1–2 you will hit this semester.
Practice prompts
Deliverable this weekCause logic tree (3+ levels) + a copy with the 1–2 strike points marked
Checkpoints
Wrote symptoms and causes separately
Expanded the logic tree at least three levels
Cleaned up overlapping branches at the same level
Chose the strike point for this semester
PART 1 · Week 3
Decomposition
Cutting an unsolvable-looking lump into one- to two-hour tasks
Learning objectiveBreak a large problem into ten or fewer executable tasks, and state the prerequisite and output of each.
Theory slides (10)
Key concepts
The right size for a task
Something you can finish in one sitting (1–2 hours). Bigger and you postpone it; smaller and the overhead of tracking it costs more than the work.
Match the level of abstraction
When “do research” and “make the survey link” sit in the same list, progress stops.
Prerequisites
What has to finish before this can start. That is your schedule.
State the constraints
Write budget, time, people and permissions as numbers. The clearer the constraint, the more concrete the solution.
Studio procedure (170 min)
STEP 1 · Fix the constraints (25 min)Write your available hours, spendable money, number of people who will help and reachable data as numbers.
▼
STEP 2 · First decomposition (45 min)Break the problem into a task list with the prompt below. What matters is what you delete from the result.
▼
STEP 3 · Fix the sizes (50 min)Cut anything over two hours again, merge anything under fifteen minutes. Land on ten or fewer.
▼
STEP 4 · Fix the order (50 min)Chain the prerequisites into an order and mark the first three. This table is your reference for the remaining 12 weeks.
Practice prompts
Deliverable this weekTask table (10 or fewer: task / output / time / prerequisite) + the top 3 marked
Checkpoints
Wrote the constraints as numbers
Every task is sized at 1–2 hours
There are ten tasks or fewer
Chose the three things to do first
PART 1 · Week 4
Talking to AI Effectively · RTCF
Structuring instructions with four elements: role, task, context, format
Learning objectiveSee how the same question changes once all four elements are present, and build three reusable templates for your own problem.
Theory slides (10)
Key concepts — the four RTCF elements
R · Role
Specify who is answering. This is what sets the level of expertise.
T · Task
A precise verb. One prompt carries one task.
C · Context
Background, constraints, what you already know. This drives the quality of the answer more than anything else.
F · Format
Table, bullets, line count, tone. This is what removes the rework.
Studio procedure (170 min)
STEP 1 · Just ask (20 min)Throw one question about your problem the way you normally would, and save the result.
▼
STEP 2 · Fill the four elements (40 min)Rewrite the same question into the template. Getting three or more lines into context is the whole trick.
▼
STEP 3 · Compare and diagnose (40 min)Put the two results side by side, write three things that changed, and run [4-2] on your prompt.
▼
STEP 4 · Build three templates (70 min)Make one each for research, analysis and writing. Keep variables to five or fewer.
Practice prompts
Three rules against hallucination① Tell it to say so when it does not know ② demand sources for figures and quotations ③ make it separate fact from inference. Keep these three lines pinned at the bottom of every template.
Deliverable this weekThree reusable RTCF templates (research · analysis · writing) + a before/after comparison table
Checkpoints
Compared two answers to the same question and wrote three differences
Filled context (C) with three or more lines
Finished three templates with five variables or fewer
Ran each template once more with different inputs
PART 2 · Week 5
Divergent Thinking · SCAMPER × AI
Win on quantity first — generate 30 solution ideas
Learning objectiveExpand solutions across the seven SCAMPER axes, and train yourself to gather ideas with judgment suspended.
Theory slides (10)
Key concepts
Keep divergence and convergence apart
Evaluating while you gather ruins both. No evaluation this week.
The seven SCAMPER axes
Substitute · combine · adapt · modify · put to other use · eliminate · reverse. They push a stuck mind sideways by force.
AI is an amplifier
You bring 3, AI turns it into 30. But 30 ordinary ideas come easily, so you have to name the axis.
What a strange idea is worth
An idea you cannot use becomes the raw material for the next one. Do not delete it — keep it.
Studio procedure (170 min)
STEP 1 · Bare-handed ideation (25 min)Ten minutes alone without AI, ten with your team. Write at least 8 ideas by hand. This is your baseline.
▼
STEP 2 · SCAMPER expansion (50 min)Use the prompt below to pull 7 axes × 3 ideas = 21 ideas.
▼
STEP 3 · Extreme-condition ideation (45 min)Add conditions — “with zero budget,” “if it had to be done in a day,” “if you did the opposite” — and expand further.
▼
STEP 4 · Assemble the 30 (50 min)Merge duplicates without deleting anything, and list each with a one-line description.
Practice prompts
Deliverable this weekA list of 30 solution ideas (labelled by axis and condition)
Checkpoints
Wrote 8 ideas by hand before touching AI
Filled all seven SCAMPER axes
Collected 30 or more ideas in total
Did not evaluate any idea this week
PART 2 · Week 6
Resolving Contradictions · TRIZ
How to break the “gain A, lose B” structure
Learning objectiveState the trade-off blocking your solution as a contradiction, and use the separation principles to get both sides.
Theory slides (10)
Key concepts
The contradiction is the problem
“Do it fast and it gets inaccurate” — the reason a problem will not budge is usually a single contradiction.
Do not compromise
A middle-ground answer loses both sides. TRIZ tries to eliminate the contradiction instead of splitting it.
Four separation principles
Separate by time, space, condition, or whole and part. “A at these times, B at those” is the most common answer.
Ideal final result
Imagine the state where the function remains with no cost and no side effect, then work backwards from there.
Studio procedure (170 min)
STEP 1 · Find the contradiction (35 min)Collect the “it's good, but this is what stops it” reasons from your 30 Week 5 ideas and write them as contradictions.
▼
STEP 2 · Declare the ideal result (30 min)Write the ideal state, with zero cost and zero side effects, in one sentence.
▼
STEP 3 · Apply the separation principles (60 min)Use the prompt below to build solutions separated by time, space, condition and part.
▼
STEP 4 · Select 5 (45 min)Pick the 5 ideas that actually eliminate the contradiction and write down why.
Practice prompts
Deliverable this weekContradiction statement (2 sentences + ideal result) + 5 ideas that resolve it
Checkpoints
Wrote the contradiction as “raise A and B gets worse”
Declared the ideal final result in one sentence
Tried all four separation principles
Picked 5 ideas that eliminate rather than compromise
PART 2 · Week 7
Convergent Thinking and Constraint Satisfaction
Cutting 30 ideas down to 1 with an evaluation matrix
Learning objectiveCompare solutions with a weighted evaluation matrix, and select one final idea, with reasons, that is executable under hard constraints.
Theory slides (10)
Key concepts
Criteria first, scores later
If you build the criteria after looking at the candidates, you have already picked the winner. Fix the criteria first.
Weights
Not every criterion can carry the same weight. Put weight on whatever sits closest to your Week 1 success criteria.
Constraint satisfaction (CSP)
An idea that fails a hard constraint like “zero budget, one person, two weeks” is out regardless of its score.
Heuristic search
Find a good-enough answer quickly instead of a perfect optimum. For a semester project, that is the right trade.
Studio procedure (170 min)
STEP 1 · Fix criteria and weights (30 min)Settle on 4–5 criteria — impact, feasibility, cost, urgency and the like — and their weights first.
▼
STEP 2 · Hard-constraint filter (25 min)Cut the ideas that fail a constraint before anything else. Thirty usually drops to ten or fewer.
▼
STEP 3 · Score the matrix (55 min)Build the scoring table with the prompt below, then correct the scores with your own judgment.
▼
STEP 4 · Commit to one + rebuttal (60 min)Defend “why not the runner-up” in three lines. If you cannot defend it, pick again.
Practice prompts
Deliverable this weekIdea evaluation matrix + a written rationale for the final solution
Checkpoints
Set criteria and weights before looking at candidates
Filtered candidates by hard constraints first
Corrected the AI's scores with my own judgment
Defended “why not the runner-up”
PART 2 · Week 8 · Midterm
Solution Concept Presentation
A full check of decomposition → comparison → rationale → solution logic
Learning objectiveConsolidate the Week 1–7 deliverables into a single solution concept specification, and answer your peers' questions with evidence.
Theory slides (10)
What to submit (about 5 A4 pages)
Section
Contents
From week
1. Problem definition
One-sentence problem + three levels of success criteria
Week 1
2. Cause structure
Logic tree + rationale for the chosen strike point
Week 2
3. Task decomposition
Task table (10 or fewer) + constraints
Week 3
4. Alternatives
Summary of the 30 ideas + contradiction statement
Weeks 5·6
5. Selection
Evaluation matrix + rationale for the chosen idea + its biggest weakness
Week 7
6. Draft solution logic
The procedure in prose or a diagram (becomes a proper flowchart in Week 9)
―
Appendix
Full text of every prompt used
Week 4 templates
Presentation (7 min each, team and individual, + 3 min Q&A)
1 min · ProblemWho, when, because of what, loses what. Open with a single case.
▼
2 min · Causes and strike pointWhy you picked this point on the logic tree.
▼
3 min · Alternatives and selectionAlways include what you dropped and why.
▼
1 min · Plan for the next 8 weeksWhat you will build and how you will validate it.
Describing the procedure in conditions, loops and branches
Learning objectiveDraw the execution procedure of your chosen solution as a flowchart, and mark the line between what people do and what AI does.
Theory slides (10)
Key concepts
If you cannot write the procedure, you cannot build it
If you can say it but can't draw it, it's still a wish, not a solution.
Three symbols are enough
Process (rectangle) · decision (diamond) · start/end (rounded). These three draw almost any procedure.
Every branch is an exception
A flowchart with an empty “no” arrow will break in Week 12, without fail.
The human–AI line
Mark who executes each step. Leave the steps that need judgment and accountability with a person.
Studio procedure (170 min)
STEP 1 · Write the procedure in prose (30 min)Write how the solution works as 10–15 numbered sentences.
▼
STEP 2 · Mark the decision points (30 min)Find and mark every place where an “if” appears.
▼
STEP 3 · Generate the flowchart (60 min)Get Mermaid code with the prompt below, paste it into mermaid.live or similar, then check and fix the diagram.
▼
STEP 4 · Label the actors (50 min)Tag each step [human] / [AI] / [automatic] and write the risk wherever AI does the judging.
Practice prompts
Deliverable this weekSolution flowchart (Mermaid diagram) + a table of actors and failure fallbacks per step
Checkpoints
Wrote the procedure as 10 or more numbered sentences
Every decision node has a “no” path
Labelled the actor for each step
Named the steps that must not be automated
PART 3 · Week 10
Prompt Chaining and AI Agents
Don't ask for it all at once — chain it
Learning objectiveSplit a large task into a chain of four or more prompts, and define the input and output spec between stages.
Theory slides (10)
Key concepts
One prompt, one task
Ask for gathering, summarizing, writing and reviewing at once and all four come back below average.
The joints of the chain
The output format of one stage is the input format of the next. Standardize the joint or the chain snaps.
Separate the reviewer
An AI reviewing its own writing goes easy on itself. Put review in a different role and a different session.
What an agent is
A setup that takes a goal and splits it into steps on its own. This week you design that structure by hand.
Studio procedure (170 min)
STEP 1 · Pick one repetitive task (25 min)Choose a task in your project that will come up again and again.
▼
STEP 2 · Design the chain (50 min)Build a 4–6 stage chain with the prompt below and fix the input/output spec of each stage.
▼
STEP 3 · Run it (60 min)Actually run it in order. Record where it breaks.
▼
STEP 4 · Add a review stage (35 min)Attach a review prompt in a different role at the end and compare the difference in output.
Practice prompts
Deliverable this weekA prompt chain design of 4+ stages (with full instruction texts) + the results of running it
Checkpoints
Set an input/output spec for each stage
Put the review stage in a different role
Actually ran it end to end once
Recorded where it broke and why
PART 3 · Week 11
No-Code Automation and Connecting Knowledge (RAG Basics)
Attaching your own material to AI, and handing repetition to a machine
Learning objectiveUnderstand how a setup that answers from your own material (RAG) works and where it fails, and design one repetitive task as an automated pipeline.
Theory slides (10)
Key concepts
How RAG works
Instead of recalling from memory, the model looks things up in the documents you gave it and cites them. The citation is the biggest gain.
Where RAG fails
Feed it wrong material and the answer is wrong. More documents does not mean better; they have to be organized.
The unit of automation
Trigger (when) → process (what) → output (where to). If you can express it in those three, you can automate it.
Do it by hand three times first
Only automate a procedure you have run by hand three times. That is how you learn its exceptions.
Studio procedure (170 min)
STEP 1 · Organize your source material (40 min)Collect five or more documents related to your project and record title, source and date.
▼
STEP 2 · Build your own assistant (50 min)Upload the material, set the condition “answer only from this material,” and test it with 10 questions.
▼
STEP 3 · Design the pipeline (50 min)Use the prompt below to draw an automation design with trigger, process and output defined.
▼
STEP 4 · Trial run (30 min)Run it once, record the result and the time it took, and compare against doing it by hand.
Practice prompts
Personal data warningKeep other people's names, contact details, student IDs, and health or grade information out of your training material and anything you automate. Pseudonymize where you must, and keep the raw material in your own storage only.
Deliverable this weekAutomation pipeline design + trial run results (time before vs. after)
Checkpoints
Built the assistant on five or more documents
Tested citation quality with 10 questions
Produced a design with trigger, process and output defined
Checked whether any personal data was included
PART 3 · Week 12
Exception Handling and Red Teaming
The week you attack your own solution as hard as you can
Learning objectiveFind where your solution breaks, write those points up as exception scenarios, and build a response to each objection.
Theory slides (10)
Key concepts
The illusion of the happy path
Look only at the “yes” path of a flowchart and every solution is perfect. Things always blow up on the “no.”
Three kinds of exception
Mistakes (bad input) · abuse (on purpose) · edge cases (rare conditions). Each needs a different defense.
Red team
A role whose purpose is to bring your solution down. Giving AI this role pays off more than anything else.
Ethics and accountability
Who could be harmed, and who answers for that harm. No answer means you fix the design.
Studio procedure (170 min)
STEP 1 · Fill in the “no” paths (35 min)Write what happens at every “no” in your Week 9 flowchart.
▼
STEP 2 · Red team attack (55 min)Let the prompt below attack your solution, and record the 5 criticisms that sting, word for word.
▼
STEP 3 · Build your response (45 min)For each criticism, decide whether to ① accept and fix ② rebut with evidence ③ declare it out of scope.
▼
STEP 4 · Ethics check (35 min)Tabulate who could be harmed, what personal data is involved, and who is accountable when it misfires.
Practice prompts
Deliverable this weekException scenario table + red team response document + ethics check table
Checkpoints
Filled every “no” path in the flowchart
Recorded the 5 criticisms that stung, verbatim
Separated what to fix from what is out of scope
Wrote down who could be harmed and who is accountable
PART 4 · Week 13
Building the Prototype
Show it, don't explain it — the smallest thing that works
Learning objectiveSet the minimum feature scope and build a prototype v1 that people can actually touch, using no-code and AI tools.
Theory slides (10)
Key concepts
The M in MVP is minimum
Build only as much as it takes to test one success criterion. Everything else comes later.
Fake is fine
Even if a person handles it behind the scenes, if the user's experience is real it is enough for validation.
Screen flow first
First screen → core action → seeing the result. Three scenes express most flows.
The polish trap
The prettier it looks, the more people comment on the colors instead of the substance. Keep it rough.
Studio procedure (170 min)
STEP 1 · Cut the scope (30 min)Write the feature list and delete everything not needed to test the success criterion.
▼
STEP 2 · Design screens and flow (40 min)Draw the usage flow in three scenes. Paper is fine.
▼
STEP 3 · Build (70 min)Write the build spec with the prompt below and make v1 with no-code and AI tools.
▼
STEP 4 · Self demo (30 min)Use it end to end as if you had never seen it. Write down every place you get stuck.
Practice prompts
Deliverable this weekA working prototype v1 (link or screenshots) + a usage scenario script
Checkpoints
Cut the features to three or fewer
Drew the usage flow in three scenes
Built a v1 that works end to end
Listed every place I got stuck
PART 4 · Week 14
Validating the Solution · CER and User Testing
Speaking from evidence, not from “it looks good”
Learning objectiveGather data from real use with five or more people, write a validation report in claim–evidence–reasoning (CER) form, and revise into v2.
Theory slides (10)
Key concepts
The CER structure
Claim · Evidence · Reasoning. A claim with no evidence is a personal impression.
Watch behavior, not words
“I like it” is not data. Did they finish, and how many seconds did it take — that is data.
The rule of five
Five users surface most of the fatal problems. Observation matters more than sample size.
Failure is a result
Concluding the hypothesis was wrong is a complete result. Do not dress it up as a success.
Studio procedure (170 min)
STEP 1 · Fix the hypothesis and metrics (30 min)Write “using this solution changes [what] by [how much]” as a falsifiable sentence.
▼
STEP 2 · User testing (60 min)Have 5 people use it with no demo, and record behavior rather than words.
▼
STEP 3 · Organize and analyze the data (45 min)Use the prompt below to put the quantitative and qualitative data into CER form.
▼
STEP 4 · Revise into v2 (35 min)Fix only the 1–2 places where people got stuck most. Do not try to fix everything.
Practice prompts
Deliverable this weekValidation report (CER structure, with data visualized) + prototype v2
Checkpoints
Wrote the hypothesis as a falsifiable sentence
Had five or more people try it with no hints
Attached data as evidence to every claim
Limited the fixes to one or two
PART 4 · Week 15 · Final
Final Capstone · Solution Pitch
Proving problem – solution – logic – validation in 8 minutes
Learning objectivePresent a semester of problem solving as one line of reasoning, and state the limits of your own solution clearly through peer review.
Theory slides (10)
Final submissions
Submission
Contents
Length
Solution logic specification
Problem definition · cause structure · alternatives and selection · flowchart · exception handling · automation design
8–10 A4 pages
Prototype
A working v2 (link, screenshots or demo video — pick one) + usage scenario
Stated on my own the conditions under which the solution fails
Left the failed attempts in the appendix
Project generators
Enter your project details and the generator writes an instruction you can copy straight into an AI tool.
Fill in the fields, press “Generate prompt”, then use “Copy” on the box that appears.
The generated instruction is in English — prompts are kept in English across all languages so answer quality stays consistent.
Problem decomposition generator
For weeks 1–3. Writes an instruction that breaks your problem into a cause structure and executable tasks.
Generated instruction (English)
Idea generation & selection generator
For weeks 5–7. Expands ideas in volume, then picks one with a weighted matrix.
Generated instruction (English)
Validation design generator
For weeks 13–14. Writes an instruction for testing your prototype on real people and building evidence.
3 กติกากันการหลอน (Hallucination)① ระบุให้ชัดว่าถ้าไม่รู้ต้องบอกว่าไม่รู้ ② เรียกแหล่งอ้างอิงทุกครั้งที่มีตัวเลขหรือการยกมา ③ ให้เขียนแยกข้อเท็จจริงออกจากการอนุมาน ใส่สามบรรทัดนี้ไว้ท้ายเทมเพลตทุกชุดแบบถาวร
Biến một vấn đề đã được xác định thành giải pháp chạy được. Mỗi tuần bạn làm ra một sản phẩm,
sao chép nguyên văn prompt thực hành để dùng, và tự tạo chỉ dẫn riêng bằng bộ tạo prompt.
Học kỳ 2, năm học 2026 | Thứ Hai 16:00–18:50 (Phòng 517, Tòa Myeongsin) | Giảng viên: Jung Jin-hyuk
Luồng học tập Phân rã vấn đề → Phát tán giải pháp → Hội tụ · chọn lọc → Thiết kế logic → Tự động hóa → Prototype → Kiểm chứng → Thuyết trình
Tiến độ học tập0 / 15 tuần hoàn thành
PART 1 · Mổ xẻ vấn đề
PART 2 · Phát tán và hội tụ
PART 3 · Logic và tự động hóa
PART 4 · Prototype và kiểm chứng
PART 1 · Tuần 1 · Định hướng
Giải quyết vấn đề là gì
AI không phải cây đũa thần — con mắt chọn được vấn đề giải được
Mục tiêu học tậpChọn được 1 vấn đề mà bản thân sẽ thực sự giải quyết trong học kỳ này, và phán đoán được vấn đề đó đã ở “dạng giải được” hay chưa.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Điều kiện của một vấn đề giải được
Phạm vi phải khép kín, phải có tiêu chí phán định thành công, và phải thấy được kết quả trong một học kỳ.
Những việc AI không làm được
Quyết định giải quyết cái gì, phán xét giá trị, và chịu trách nhiệm. Ba việc này đến cùng vẫn là phần của con người.
Ba bước tư duy máy tính
Phân rã (chia nhỏ) · Nhận diện mẫu (tìm cái lặp lại) · Trừu tượng hóa (chỉ giữ cốt lõi). Đây là bộ khung của cả môn học.
Tìm vấn đề → Giải vấn đề
Nếu PBLⅡ hỏi “vấn đề là gì”, thì PBLⅠ hỏi “vậy sẽ làm thế nào”.
Quy trình thực hành (170 phút)
STEP 1 · Viết ra 3 ứng viên (25 phút)Viết 3 điều bất tiện bạn tự trải qua trong 3 tháng gần đây. Phải là vấn đề của bạn, không phải của người khác.
▼
STEP 2 · Phán định khả năng giải (40 phút)Dùng prompt bên dưới chấm điểm 3 ứng viên theo phạm vi, tiêu chí phán định và thời gian, rồi loại các dạng không giải được.
▼
STEP 3 · Chốt 1 vấn đề (45 phút)Định nghĩa vấn đề bằng một câu, theo dạng “ai / khi nào / vì cái gì / chịu thiệt hại gì”.
▼
STEP 4 · Tuyên bố tiêu chí thành công (60 phút)Viết ra bằng con số hoặc trạng thái quan sát được: cuối kỳ cái gì phải khác đi thì mới nói được là “đã giải quyết”.
Prompt thực hành
Sản phẩm tuần nàyBản chọn vấn đề 1 trang A4 (vấn đề một câu + tiêu chí thành công 3 tầng) + báo cáo phản tư tuần
Điểm kiểm tra
Đã viết 3 ứng viên và sàng lọc bằng điểm số
Đã viết vấn đề thành một câu “ai/khi nào/vì cái gì/thiệt hại gì”
Đã viết tiêu chí thành công 3 tầng ở dạng quan sát được
Đã kiểm tra xem có phần nào để AI quyết định thay mình không
PART 1 · Tuần 2
Tách hiện tượng khỏi nguyên nhân
Đánh vào gốc rễ chứ không phải triệu chứng, bằng 5 Whys và cây logic
Mục tiêu học tậpTách được triệu chứng nhìn thấy khỏi nguyên nhân tạo ra nó, và vẽ được cây logic khai triển cấu trúc nguyên nhân từ 3 tầng trở lên.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Cái bẫy chữa triệu chứng
“Tăng thêm thông báo” thường chỉ là kê đơn cho triệu chứng. Không hỏi vì sao người ta bỏ lỡ thì vấn đề sẽ quay lại y như cũ.
5 Whys
Hỏi vì sao năm lần. Chỗ bắt đầu tắc câu trả lời, thường từ lần thứ ba, hay chính là nguyên nhân thật.
Cây logic
Trải nguyên nhân ra thành các nhánh. Các nhánh cùng một tầng không được chồng lấn nhau (MECE).
Chọn điểm tấn công
Không thể đánh hết mọi nguyên nhân. Chọn một cái vừa ảnh hưởng lớn vừa nằm trong tầm tay bạn.
Quy trình thực hành (170 phút)
STEP 1 · Liệt kê triệu chứng (25 phút)Từ vấn đề tuần 1, viết ít nhất 6 triệu chứng quan sát được đúng như sự thật. Bỏ diễn giải và suy đoán ra ngoài.
▼
STEP 2 · 5 Whys (35 phút)Chọn triệu chứng xảy ra thường xuyên nhất và đào năm lần. Nếu kết thúc ở “tại người ta lười” thì bạn đã thất bại.
▼
STEP 3 · Khai triển cây logic (60 phút)Dùng prompt bên dưới trải cấu trúc nguyên nhân từ 3 tầng trở lên, rồi tự tay dọn các nhánh chồng lấn.
▼
STEP 4 · Đánh dấu điểm tấn công (50 phút)Đặt các nguyên nhân lên hai trục mức ảnh hưởng × khả năng kiểm soát, rồi đánh dấu 1~2 điểm sẽ đánh trong học kỳ này.
Prompt thực hành
Sản phẩm tuần nàyCây logic nguyên nhân (từ 3 tầng trở lên) + bản đánh dấu 1~2 điểm tấn công
Điểm kiểm tra
Đã viết tách riêng triệu chứng và nguyên nhân
Đã khai triển cây logic từ 3 tầng trở lên
Đã dọn các nhánh chồng lấn trong cùng một tầng
Đã chọn điểm tấn công cho học kỳ này
PART 1 · Tuần 3
Phân rã vấn đề (Decomposition)
Cắt khối việc tưởng như không giải nổi thành các đầu việc 1~2 tiếng
Mục tiêu học tậpChia được vấn đề lớn thành tối đa 10 đầu việc khả thi, và nêu rõ điều kiện tiên quyết cùng đầu ra của từng đầu việc.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Kích cỡ vừa phải của một đầu việc
Cỡ ngồi một lần là xong (1~2 tiếng). Lớn hơn thì bạn sẽ trì hoãn, nhỏ hơn thì chi phí quản lý lại lớn.
Đồng bộ mức trừu tượng
Khi “khảo sát” và “tạo link phiếu hỏi” nằm chung một danh sách thì tiến độ sẽ đứng lại.
Điều kiện tiên quyết
Cái gì xong thì mới bắt đầu được việc này. Chính nó là lịch trình của bạn.
Nêu rõ ràng buộc
Viết ngân sách · thời gian · nhân lực · quyền hạn bằng con số. Ràng buộc càng rõ thì giải pháp càng cụ thể.
Quy trình thực hành (170 phút)
STEP 1 · Chốt ràng buộc (25 phút)Viết bằng con số: thời gian khả dụng, tiền có thể chi, số người hỗ trợ, dữ liệu tiếp cận được.
▼
STEP 2 · Phân rã lần 1 (45 phút)Dùng prompt bên dưới phân rã vấn đề thành danh sách đầu việc. Điều cốt lõi là xóa bớt trong kết quả nhận được.
▼
STEP 3 · Chỉnh kích cỡ (50 phút)Việc quá 2 tiếng thì cắt tiếp, việc 15 phút thì gộp lại. Cuối cùng còn tối đa 10 việc.
▼
STEP 4 · Chốt thứ tự (50 phút)Nối các điều kiện tiên quyết để định thứ tự, rồi đánh dấu 3 việc làm trước nhất. Bảng này là chuẩn cho 12 tuần còn lại.
Prompt thực hành
Sản phẩm tuần nàyBảng đầu việc thực thi (tối đa 10 việc, gồm đầu việc/sản phẩm/thời gian/điều kiện tiên quyết) + đánh dấu 3 việc ưu tiên
Điểm kiểm tra
Đã viết ràng buộc bằng con số
Mọi đầu việc đều đã vừa cỡ 1~2 tiếng
Số đầu việc không quá 10
Đã chọn 3 việc phải làm trước nhất
PART 1 · Tuần 4
Giao tiếp hiệu quả với AI · RTCF
Cấu trúc hóa chỉ dẫn bằng 4 yếu tố vai trò · nhiệm vụ · bối cảnh · định dạng
Mục tiêu học tậpThấy được cùng một câu hỏi nhưng kết quả khác đi thế nào khi có đủ 4 yếu tố, và tạo 3 mẫu tái sử dụng phù hợp với vấn đề của mình.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi — 4 yếu tố RTCF
R · Vai trò
Chỉ định trả lời với tư cách ai. Tầng chuyên môn được quyết định ở đây.
T · Nhiệm vụ
Chính xác, bằng động từ. Một prompt chỉ đặt một nhiệm vụ.
C · Bối cảnh
Nền tảng · ràng buộc · điều đã biết. Đây là thứ chi phối chất lượng câu trả lời nhiều nhất.
F · Định dạng
Bảng · gạch đầu dòng · số dòng · giọng văn. Đây là mục xóa bỏ thời gian làm lại.
Quy trình thực hành (170 phút)
STEP 1 · Hỏi bừa (20 phút)Đặt một câu hỏi liên quan đến vấn đề của bạn theo cách vẫn thường làm và lưu kết quả lại.
▼
STEP 2 · Điền đủ 4 yếu tố (40 phút)Viết lại câu hỏi đó theo mẫu. Mấu chốt là đưa từ 3 dòng trở lên vào phần bối cảnh.
▼
STEP 3 · So sánh và chẩn đoán (40 phút)Đặt hai kết quả cạnh nhau, viết ra 3 điểm đã khác đi, rồi chẩn đoán prompt bằng [4-2].
▼
STEP 4 · Làm 3 mẫu (70 phút)Làm lần lượt mẫu tra cứu, mẫu phân tích và mẫu soạn thảo. Giữ số biến trong vòng 5.
Prompt thực hành
3 quy tắc chống ảo giác (Hallucination)① Nêu rõ là không biết thì phải nói không biết ② Yêu cầu nguồn cho số liệu · trích dẫn ③ Bắt viết tách riêng sự thật và suy luận. Hãy gắn cố định ba dòng này ở cuối mọi mẫu.
Sản phẩm tuần này3 mẫu RTCF tái sử dụng (tra cứu · phân tích · soạn thảo) + bảng so sánh trước và sau cải thiện
Điểm kiểm tra
Đã so sánh hai kết quả của cùng một câu hỏi và viết ra 3 khác biệt
Đã điền từ 3 dòng trở lên vào phần bối cảnh (C)
Đã hoàn thành 3 mẫu với tối đa 5 biến
Đã chạy lại mỗi mẫu thêm một lần với đầu vào khác
PART 2 · Tuần 5
Tư duy phát tán · SCAMPER × AI
Thắng bằng số lượng trước — tạo ra 30 phương án giải pháp
Mục tiêu học tậpMở rộng giải pháp về mặt số lượng theo 7 trục SCAMPER, và luyện tập thu thập ý tưởng trong khi tạm gác phán xét.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Tách phát tán khỏi hội tụ
Vừa thu thập vừa đánh giá thì hỏng cả hai. Tuần này cấm đánh giá.
7 trục SCAMPER
Thay thế · kết hợp · phỏng theo · biến đổi · đổi công dụng · loại bỏ · đảo ngược. Chúng cưỡng bức đẩy suy nghĩ đang tắc sang một bên.
AI là bộ khuếch đại
Bạn đưa ra 3 thì AI nhân lên thành 30. Nhưng dễ thành 30 cái tầm thường, nên phải chỉ định trục.
Giá trị của ý tưởng kỳ quặc
Ý tưởng chưa dùng được ngay lại là nguyên liệu cho ý tưởng kế tiếp. Đừng xóa, hãy giữ lại.
Quy trình thực hành (170 phút)
STEP 1 · Nghĩ tay không (25 phút)10 phút một mình không dùng AI, 10 phút với nhóm. Viết tay tối thiểu 8 phương án. Đây là đường cơ sở.
▼
STEP 2 · Mở rộng bằng SCAMPER (50 phút)Dùng prompt bên dưới rút ra 7 trục × 3 phương án = 21 phương án.
▼
STEP 3 · Nghĩ theo điều kiện cực đoan (45 phút)Đặt điều kiện “nếu ngân sách bằng 0”, “nếu phải xong trong một ngày”, “nếu làm ngược lại” để mở rộng thêm.
▼
STEP 4 · Sắp xếp 30 phương án (50 phút)Gộp các phương án trùng lặp nhưng không xóa, rồi lập danh sách kèm một dòng giải thích cho mỗi phương án.
Prompt thực hành
Sản phẩm tuần nàyDanh sách 30 phương án giải pháp (có ghi rõ trục · điều kiện)
Điểm kiểm tra
Đã viết tay 8 phương án trước khi dùng AI
Đã điền đủ cả 7 trục SCAMPER
Đã có từ 30 phương án trở lên
Tuần này chưa đánh giá ý tưởng nào
PART 2 · Tuần 6
Giải mâu thuẫn · TRIZ
Cách phá vỡ cấu trúc “được A thì mất B”
Mục tiêu học tậpĐịnh nghĩa được đánh đổi đang chặn lời giải thành câu mâu thuẫn, và dùng nguyên lý tách biệt để tạo phương án được cả hai.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Mâu thuẫn chính là vấn đề
Như “làm nhanh thì thiếu chính xác”, lý do vấn đề không giải được thường nằm ở một mâu thuẫn duy nhất.
Đừng thỏa hiệp
Phương án dung hòa làm mất cả hai. TRIZ tìm cách triệt tiêu mâu thuẫn thay vì dung hòa.
4 nguyên lý tách biệt
Tách theo thời gian · không gian · điều kiện · toàn thể và bộ phận. “Lúc này là A, lúc kia là B” là lời giải phổ biến nhất.
Kết quả lý tưởng cuối cùng
Trước hết hình dung trạng thái chỉ còn chức năng, không chi phí cũng không tác dụng phụ, rồi tính ngược lại từ đó.
Quy trình thực hành (170 phút)
STEP 1 · Tìm mâu thuẫn (35 phút)Gom các lý do “hay đấy nhưng vì cái này nên không được” trong 30 phương án tuần 5 và viết thành câu mâu thuẫn.
▼
STEP 2 · Tuyên bố kết quả lý tưởng (30 phút)Viết một câu về trạng thái lý tưởng có chi phí và tác dụng phụ bằng 0.
▼
STEP 3 · Áp dụng nguyên lý tách biệt (60 phút)Dùng prompt bên dưới tạo giải pháp tách theo thời gian · không gian · điều kiện · bộ phận.
▼
STEP 4 · Chọn ra 5 phương án (45 phút)Chọn 5 phương án thực sự triệt tiêu được mâu thuẫn và sắp xếp lại kèm căn cứ.
Prompt thực hành
Sản phẩm tuần nàyBản định nghĩa mâu thuẫn (2 câu mâu thuẫn + kết quả lý tưởng) + 5 ý tưởng hóa giải mâu thuẫn
Điểm kiểm tra
Đã viết mâu thuẫn theo dạng “nâng A lên thì B xấu đi”
Đã tuyên bố kết quả lý tưởng cuối cùng bằng một câu
Đã thử cả 4 nguyên lý tách biệt
Đã chọn 5 phương án triệt tiêu chứ không phải dung hòa
PART 2 · Tuần 7
Tư duy hội tụ và thỏa mãn ràng buộc
Rút 30 phương án xuống còn 1 bằng ma trận đánh giá
Mục tiêu học tậpSo sánh các giải pháp bằng ma trận đánh giá có trọng số, và chọn ra 1 phương án cuối cùng khả thi dưới ràng buộc khắc nghiệt, kèm căn cứ.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Tiêu chí trước, điểm số sau
Nhìn ứng viên rồi mới đặt tiêu chí nghĩa là bạn đã định sẵn đáp án. Hãy chốt tiêu chí trước.
Trọng số
Không thể mọi tiêu chí đều nặng như nhau. Hãy dồn trọng lượng cho mục gần với tiêu chí thành công (tuần 1).
Thỏa mãn ràng buộc (CSP)
Phương án không vượt qua ràng buộc cứng như “0 đồng, 1 người, 2 tuần” thì bị loại bất kể điểm số.
Tìm kiếm heuristic
Thay vì lời giải tối ưu hoàn hảo, hãy tìm nhanh một lời giải đủ tốt. Với dự án học kỳ thì hướng này hợp hơn.
Quy trình thực hành (170 phút)
STEP 1 · Chốt tiêu chí · trọng số (30 phút)Trước hết định 4~5 tiêu chí như hiệu quả · tính khả thi · chi phí · mức cấp bách, cùng trọng số của chúng.
▼
STEP 2 · Lọc bằng ràng buộc cứng (25 phút)Cắt trước các phương án không vượt qua ràng buộc. 30 phương án thường rút xuống còn 10 hoặc ít hơn.
▼
STEP 3 · Chấm điểm ma trận (55 phút)Dùng prompt bên dưới lập bảng chấm điểm, rồi tự sửa điểm theo phán đoán của bạn.
▼
STEP 4 · Chốt 1 phương án + phản biện (60 phút)Bảo vệ phương án hạng nhất bằng 3 dòng “vì sao không phải hạng nhì”. Nếu không bảo vệ được thì chọn lại.
Prompt thực hành
Sản phẩm tuần nàyMa trận đánh giá ý tưởng + bản căn cứ chọn 1 giải pháp cuối cùng
Điểm kiểm tra
Đã định tiêu chí và trọng số trước khi nhìn ứng viên
Đã lọc ứng viên bằng ràng buộc cứng trước
Đã sửa điểm của AI theo phán đoán của mình
Đã bảo vệ được “vì sao không phải hạng nhì”
PART 2 · Tuần 8 · Giữa kỳ
Thuyết trình ý niệm giải pháp
Kiểm tra tổng hợp: phân rã vấn đề → so sánh phương án → căn cứ chọn lựa → logic giải quyết
Mục tiêu học tậpTích hợp sản phẩm của tuần 1~7 thành một bản đặc tả ý niệm giải pháp, và trả lời câu hỏi của bạn học bằng căn cứ.
Slide lý thuyết (10 trang)
Cấu phần bài nộp (khoảng 5 trang A4)
Cấu phần
Nội dung
Tuần làm căn cứ
1. Định nghĩa vấn đề
Vấn đề một câu + tiêu chí thành công 3 tầng
Tuần 1
2. Cấu trúc nguyên nhân
Cây logic + căn cứ chọn điểm tấn công
Tuần 2
3. Phân rã đầu việc
Bảng đầu việc thực thi (tối đa 10) + ràng buộc
Tuần 3
4. Tìm phương án
Tóm tắt 30 phương án + bản định nghĩa mâu thuẫn
Tuần 5 · 6
5. Chọn lựa
Ma trận đánh giá + căn cứ chọn 1 phương án + điểm yếu lớn nhất
Tuần 7
6. Bản nháp logic giải quyết
Quy trình giải quyết bằng chữ hoặc hình (tuần 9 sẽ phát triển thành lưu đồ chính thức)
―
Phụ lục
Toàn văn các prompt đã dùng
Mẫu tuần 4
Thuyết trình (nhóm · cá nhân mỗi bên 7 phút + hỏi đáp 3 phút)
1 phút · Vấn đềAi, khi nào, vì cái gì, chịu thiệt hại gì. Hãy mở đầu bằng một trường hợp cụ thể.
▼
2 phút · Nguyên nhân và điểm tấn côngVì sao trong cây logic bạn chọn đúng điểm này.
▼
3 phút · Phương án và chọn lựaBắt buộc phải nêu cả phương án đã bỏ và lý do bỏ.
▼
1 phút · Kế hoạch 8 tuần tớiSẽ làm ra cái gì và kiểm chứng thế nào.
Prompt kiểm tra giữa kỳ
Bài nộpBản đặc tả ý niệm giải pháp (5 trang A4) + tài liệu thuyết trình + phụ lục prompt · Tỷ trọng đánh giá 30%
Điểm kiểm tra
Đã đưa đủ cả 6 cấu phần
Đã nêu rõ phương án đã bỏ và lý do bỏ
Đã đính kèm toàn văn prompt ở phụ lục
Đã chuẩn bị câu trả lời cho 5 câu hỏi dự kiến
PART 3 · Tuần 9
Thiết kế thuật toán · tư duy bằng lưu đồ
Mô tả quy trình giải quyết bằng điều kiện · lặp · rẽ nhánh
Mục tiêu học tậpVẽ được quy trình thực thi của giải pháp đã chọn thành lưu đồ, và nêu rõ ranh giới giữa việc của người và việc của AI.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Không viết được thành quy trình thì không làm được
Nói miệng thì trôi chảy mà không vẽ nổi lưu đồ, nghĩa là bạn mới có mong muốn chứ chưa có giải pháp.
Ba ký hiệu là đủ
Xử lý (chữ nhật) · phán định (hình thoi) · bắt đầu/kết thúc (bo tròn). Ba cái này vẽ được gần như mọi quy trình.
Rẽ nhánh chính là ngoại lệ
Lưu đồ có mũi tên phía “không” bỏ trống thì chắc chắn sẽ vỡ ở tuần 12.
Ranh giới người · AI
Ghi rõ chủ thể thực hiện ở từng bước. Bước nào cần phán xét và trách nhiệm thì để cho người.
Quy trình thực hành (170 phút)
STEP 1 · Viết quy trình bằng chữ (30 phút)Viết quá trình vận hành của giải pháp thành 10~15 câu có đánh số.
▼
STEP 2 · Đánh dấu điểm phán định (30 phút)Tìm và đánh dấu mọi chỗ có chữ “nếu như ~ thì”.
▼
STEP 3 · Sinh lưu đồ (60 phút)Dùng prompt bên dưới lấy mã Mermaid, dán vào mermaid.live hoặc công cụ tương tự để xem và sửa sơ đồ.
▼
STEP 4 · Ghi chủ thể (50 phút)Gắn nhãn [người] / [AI] / [tự động] cho từng bước, và viết ra rủi ro ở những chỗ AI phán định.
Prompt thực hành
Sản phẩm tuần nàyLưu đồ quy trình giải quyết (sơ đồ Mermaid) + bảng chủ thể và phương án dự phòng theo từng bước
Điểm kiểm tra
Đã viết quy trình thành từ 10 câu đánh số trở lên
Mọi nút phán định đều có đường “không”
Đã ghi chủ thể thực hiện ở từng bước
Đã chỉ định bước không được tự động hóa
PART 3 · Tuần 10
Nối chuỗi prompt và tác nhân AI
Đừng giao hết một lần, hãy giao theo chuỗi nối tiếp
Mục tiêu học tậpChia được công việc lớn thành chuỗi prompt từ 4 bước trở lên, và định nghĩa quy cách đầu vào - đầu ra giữa các bước.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Một prompt một nhiệm vụ
Giao thu thập · tóm tắt · soạn thảo · rà soát cùng một lúc thì tất cả đều dưới trung bình.
Mối nối của chuỗi
Định dạng đầu ra của bước trước chính là định dạng đầu vào của bước sau. Phải chuẩn hóa chỗ này thì chuỗi mới không đứt.
Tách riêng vai người rà soát
AI viết mà tự rà soát thì sẽ dễ dãi. Hãy tách phần rà soát sang vai trò khác, phiên làm việc khác.
Tác nhân AI là gì
Là cấu hình mà khi được giao mục tiêu sẽ tự chia bước và thực thi. Tuần này ta tự tay thiết kế cấu trúc đó.
Quy trình thực hành (170 phút)
STEP 1 · Chọn 1 việc lặp lại (25 phút)Chọn một đầu việc sẽ lặp đi lặp lại trong dự án của bạn.
▼
STEP 2 · Thiết kế chuỗi (50 phút)Dùng prompt bên dưới tạo chuỗi 4~6 bước và chốt quy cách đầu vào - đầu ra của từng bước.
▼
STEP 3 · Chạy thử (60 phút)Chạy thật theo đúng thứ tự. Ghi lại những chỗ bị đứt.
▼
STEP 4 · Thêm bước rà soát (35 phút)Gắn thêm prompt rà soát với vai trò khác ở cuối chuỗi và so sánh khác biệt trong kết quả.
Prompt thực hành
Sản phẩm tuần nàyBản thiết kế chuỗi prompt từ 4 bước trở lên (kèm toàn văn chỉ dẫn) + kết quả chạy thử
Điểm kiểm tra
Đã định quy cách đầu vào - đầu ra ở từng bước
Đã tách bước rà soát sang vai trò khác
Đã thực sự chạy hết một lượt
Đã ghi lại chỗ bị đứt và nguyên nhân
PART 3 · Tuần 11
Tự động hóa no-code và kết nối tri thức (RAG cơ bản)
Gắn tài liệu của mình vào AI, và giao phần lặp lại cho máy
Mục tiêu học tậpHiểu nguyên lý và giới hạn của cấu hình trả lời dựa trên tài liệu của mình (RAG), và thiết kế 1 việc lặp lại thành đường ống tự động.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Nguyên lý của RAG
Thay vì mô hình thuộc lòng, nó tìm và trích dẫn từ tài liệu tôi đưa vào. Ưu điểm lớn nhất là câu trả lời có nguồn.
Giới hạn của RAG
Tài liệu đưa vào sai thì câu trả lời cũng sai. Nhiều tài liệu không có nghĩa là tốt hơn, phải là tài liệu đã được sắp xếp.
Đơn vị của tự động hóa
Kích hoạt (khi nào) → xử lý (cái gì) → đầu ra (đi đâu). Diễn đạt được bằng ba cái này thì tự động hóa được.
Làm tay ba lần trước đã
Chỉ tự động hóa quy trình bạn đã tự làm tay ba lần. Có vậy bạn mới biết các ngoại lệ.
Quy trình thực hành (170 phút)
STEP 1 · Sắp xếp tài liệu tri thức (40 phút)Gom từ 5 tài liệu liên quan dự án trở lên và sắp xếp tiêu đề · nguồn · ngày tháng.
▼
STEP 2 · Dựng trợ lý riêng (50 phút)Tải tài liệu lên, tạo trợ lý với điều kiện “chỉ trả lời dựa trên tài liệu này” và thử bằng 10 câu hỏi.
▼
STEP 3 · Thiết kế đường ống (50 phút)Dùng prompt bên dưới lập bản thiết kế tự động hóa có định nghĩa kích hoạt · xử lý · đầu ra.
▼
STEP 4 · Chạy thử nghiệm (30 phút)Chạy một lần, ghi lại kết quả và thời gian tiêu tốn, rồi so với khi làm tay.
Prompt thực hành
Lưu ý về thông tin cá nhânHãy đảm bảo tài liệu học tập và đối tượng tự động hóa không chứa tên, số liên lạc, mã số sinh viên, thông tin sức khỏe · điểm số của người khác. Nếu cần thì ẩn danh trước khi dùng, và giữ dữ liệu gốc chỉ trong kho lưu trữ cá nhân.
Sản phẩm tuần nàyBản thiết kế đường ống tự động hóa + kết quả chạy thử nghiệm (so sánh thời gian trước và sau)
Điểm kiểm tra
Đã dựng trợ lý với từ 5 tài liệu trở lên
Đã thử chất lượng trích dẫn căn cứ bằng 10 câu hỏi
Đã lập bản thiết kế có định nghĩa kích hoạt · xử lý · đầu ra
Đã kiểm tra xem có chứa thông tin cá nhân không
PART 3 · Tuần 12
Xử lý ngoại lệ và đội đỏ
Giờ tự tấn công lời giải của mình mạnh nhất có thể
Mục tiêu học tậpTự tìm ra những chỗ lời giải bị vỡ, sắp xếp chúng thành kịch bản ngoại lệ, và dựng logic đối đáp với các phản bác.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Ảo giác của đường đi thuận
Chỉ nhìn nhánh “có” của lưu đồ thì lời giải nào cũng hoàn hảo. Vấn đề luôn nổ ra ở nhánh “không”.
Ba loại ngoại lệ
Nhầm lẫn (nhập sai) · lạm dụng (cố ý) · trường hợp biên (điều kiện hiếm). Mỗi loại phòng bị một khác.
Đội đỏ
Vai trò có mục đích là đánh sập lời giải của bạn. Giao vai này cho AI là đáng giá nhất.
Đạo đức · trách nhiệm
Ai có thể chịu thiệt, và ai chịu trách nhiệm cho thiệt hại đó. Không có câu trả lời thì phải sửa thiết kế.
Quy trình thực hành (170 phút)
STEP 1 · Lấp đầy nhánh “không” (35 phút)Viết ra chuyện gì xảy ra ở mọi nhánh “không” trong lưu đồ tuần 9.
▼
STEP 2 · Đội đỏ tấn công (55 phút)Dùng prompt bên dưới để lời giải của bạn bị tấn công, và ghi nguyên văn 5 lời chỉ trích đau nhất.
▼
STEP 3 · Dựng logic đối đáp (45 phút)Với từng lời chỉ trích, phân loại ① thừa nhận và sửa ② phản bác bằng căn cứ ③ tuyên bố nằm ngoài phạm vi.
▼
STEP 4 · Rà soát đạo đức (35 phút)Lập bảng các nhóm có thể chịu thiệt, thông tin cá nhân, và ai chịu trách nhiệm khi trục trặc.
Prompt thực hành
Sản phẩm tuần nàyBảng kịch bản ngoại lệ + bản đối đáp phản bác của đội đỏ + bảng rà soát đạo đức
Điểm kiểm tra
Đã lấp đầy mọi nhánh “không” của lưu đồ
Đã ghi nguyên văn 5 lời chỉ trích đau nhất
Đã phân biệt cái phải sửa với cái nằm ngoài phạm vi
Đã ghi nhóm có thể chịu thiệt và chủ thể chịu trách nhiệm
PART 4 · Tuần 13
Chế tạo nguyên mẫu
Đừng giải thích, hãy cho xem — sản phẩm thử tối thiểu chạy được
Mục tiêu học tậpXác định phạm vi chức năng tối thiểu, và dùng công cụ no-code · AI làm ra nguyên mẫu v1 mà người khác sờ tay vào được.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Chữ M trong MVP là tối thiểu
Chỉ làm vừa đủ để kiểm tra một tiêu chí thành công. Phần còn lại đều để sau.
Giả cũng được
Dù phía sau là người xử lý bằng tay, chỉ cần trải nghiệm của người dùng là thật thì đủ để kiểm chứng.
Luồng màn hình trước đã
Màn hình đầu → hành động cốt lõi → xem kết quả. Ba cảnh là đủ diễn đạt hầu hết các luồng.
Cái bẫy của độ hoàn thiện
Làm càng đẹp thì người ta càng chê màu sắc thay vì bàn về bản chất. Hãy giữ nó thô ráp.
Quy trình thực hành (170 phút)
STEP 1 · Cắt phạm vi (30 phút)Viết danh sách chức năng, rồi xóa hết những gì không cần cho việc kiểm tra tiêu chí thành công.
▼
STEP 2 · Thiết kế màn hình · luồng (40 phút)Vẽ luồng sử dụng bằng ba cảnh. Vẽ trên giấy cũng được.
▼
STEP 3 · Chế tạo (70 phút)Dùng prompt bên dưới tạo bản đặc tả chế tạo và làm v1 bằng công cụ no-code · AI.
▼
STEP 4 · Tự chạy thử (30 phút)Giả làm người lần đầu nhìn thấy và dùng cho tới hết. Ghi lại mọi chỗ bị kẹt.
Prompt thực hành
Sản phẩm tuần nàyNguyên mẫu v1 chạy được (đường liên kết hoặc ảnh chụp) + kịch bản sử dụng
Điểm kiểm tra
Đã cắt chức năng xuống còn 3 hoặc ít hơn
Đã vẽ luồng sử dụng thành ba cảnh
Đã làm ra v1 chạy được đến cuối
Đã ghi các chỗ bị kẹt thành danh sách
PART 4 · Tuần 14
Kiểm chứng giải pháp · CER và kiểm thử người dùng
Nói bằng căn cứ, không phải bằng “trông có vẻ ổn”
Mục tiêu học tậpThu dữ liệu bằng kiểm thử thực tế với từ 5 người trở lên, viết báo cáo kiểm chứng theo cấu trúc luận điểm – căn cứ – suy luận (CER) và sửa thành v2.
Slide lý thuyết (10 trang)
Khái niệm cốt lõi
Cấu trúc CER
Luận điểm (Claim) · Căn cứ (Evidence) · Suy luận (Reasoning). Luận điểm không có căn cứ chỉ là bài cảm nghĩ.
Hãy nhìn hành động thay vì lời nói
“Hay đấy” không phải dữ liệu. Có làm đến cuối không, mất bao nhiêu giây mới là dữ liệu.
Quy tắc 5 người
Chỉ cần 5 người thử là phần lớn lỗi chí mạng đã lộ ra. Quan sát quan trọng hơn con số.
Thất bại cũng là kết quả
Kết luận rằng giả thuyết sai cũng là một kết quả trọn vẹn. Đừng gượng ép gói nó thành thành công.
Quy trình thực hành (170 phút)
STEP 1 · Chốt giả thuyết và chỉ số (30 phút)Viết “dùng lời giải này thì [cái gì] thay đổi [bao nhiêu]” thành câu có thể bác bỏ được.
▼
STEP 2 · Kiểm thử người dùng (60 phút)Cho 5 người tự dùng mà không hướng dẫn, và ghi lại hành động chứ không phải lời nói.
▼
STEP 3 · Sắp xếp · phân tích dữ liệu (45 phút)Dùng prompt bên dưới sắp xếp dữ liệu định lượng · định tính theo cấu trúc CER.
▼
STEP 4 · Sửa thành v2 (35 phút)Chỉ sửa 1~2 chỗ gây kẹt nhiều nhất. Đừng cố sửa tất cả.
Prompt thực hành
Sản phẩm tuần nàyBáo cáo kiểm chứng (cấu trúc CER, có trực quan hóa dữ liệu) + nguyên mẫu v2
Điểm kiểm tra
Đã viết giả thuyết thành câu có thể bác bỏ
Đã cho từ 5 người trở lên thử mà không gợi ý
Đã gắn căn cứ dữ liệu cho từng luận điểm
Đã giới hạn chỗ cần sửa còn 1~2
PART 4 · Tuần 15 · Cuối kỳ
Capstone cuối cùng · Solution Pitch
Chứng minh vấn đề – lời giải – logic – kiểm chứng trong 8 phút
Mục tiêu học tậpGói quá trình giải quyết vấn đề của cả học kỳ thành một mạch logic để thuyết trình, và qua bình duyệt của bạn học, nêu rõ giới hạn của lời giải mình.
Slide lý thuyết (10 trang)
Bài nộp cuối cùng
Bài nộp
Cấu phần
Dung lượng
Bản đặc tả logic giải quyết
Định nghĩa vấn đề · cấu trúc nguyên nhân · phương án và chọn lựa · lưu đồ · xử lý ngoại lệ · thiết kế tự động hóa
8~10 trang A4
Nguyên mẫu
v2 chạy được (chọn 1 trong đường liên kết · ảnh chụp · video demo) + kịch bản sử dụng
―
Báo cáo kiểm chứng
Giả thuyết · chỉ số · kết quả · 3 bộ CER · giới hạn
3 trang A4
Bản bình duyệt của bạn học
Ý kiến rà soát của 2 bạn học + cái tôi đã tiếp thu / cái không tiếp thu và lý do
2 trang A4
Phụ lục
Toàn văn các prompt đã dùng, ghi chép các lần thử thất bại
Không giới hạn
Cấu trúc thuyết trình (8 phút + 4 phút hỏi đáp)
1 phút · Vấn đềBắt đầu bằng một cảnh cụ thể. Thống kê để sau đó.
▼
2 phút · Lời giải và căn cứ chọn lựaCho xem phương án đã bỏ trước thì phương án đã chọn mới thuyết phục.
▼
2 phút · Chạy thử trực tiếpĐừng giải thích bằng lời, hãy chạy thật. Có hỏng cũng cứ để nguyên cho xem.
▼
2 phút · Kết quả kiểm chứngNói trước giả thuyết có được ủng hộ hay không, rồi gắn dữ liệu căn cứ.
▼
1 phút · Giới hạn và bước tiếp theoTự nêu ra điều kiện mà lời giải này không hiệu quả. Mục này nặng nhất trong đánh giá.
Prompt kết thúc
Bài nộpBản đặc tả logic giải quyết + nguyên mẫu + báo cáo kiểm chứng + bản bình duyệt của bạn học · Tỷ trọng đánh giá 40%
Điểm kiểm tra
Đã hoàn thành cả bốn bài nộp
Đã thực sự chạy thử trực tiếp khi thuyết trình
Đã nói rõ giả thuyết có được ủng hộ hay không
Đã tự nêu ra điều kiện mà lời giải không hiệu quả
Đã để lại các lần thử thất bại trong phụ lục
Trình tạo prompt cho dự án
Nhập thông tin dự án của bạn, hệ thống sẽ tạo ra chỉ dẫn có thể sao chép dùng ngay.
Hãy điền vào chỗ trống, bấm 「Tạo prompt」, rồi dùng nút 「Sao chép」 ở hộp kết quả để dán vào AI.
Chỉ dẫn được tạo ra bằng tiếng Anh (English) — để chất lượng phản hồi của AI luôn ổn định, prompt dùng chung tiếng Anh cho mọi ngôn ngữ.
Trình tạo phân rã vấn đề
Dùng cho tuần 1~3. Tạo chỉ dẫn chia vấn đề thành cấu trúc nguyên nhân và các đầu việc thực thi.
Chỉ dẫn đã tạo (English)
Trình tạo phát tán · chọn lời giải
Dùng cho tuần 5~7. Tạo chỉ dẫn mở rộng ý tưởng về số lượng và chọn ra phương án số 1 bằng ma trận có trọng số.
Chỉ dẫn đã tạo (English)
Trình tạo thiết kế kiểm chứng
Dùng cho tuần 13~14. Tạo chỉ dẫn đem nguyên mẫu thử với người thật để tạo ra căn cứ.
Chỉ dẫn đã tạo (English)
[1-1] Solvability diagnosis
R (Role): You are a project reviewer who cuts a one-semester project down to size without sentiment.
T (Task): Diagnose my three candidate problems against the standard "can this be solved in one semester" and rank them.
C (Context):
· Candidate 1 : [2-line description]
· Candidate 2 : [2-line description]
· Candidate 3 : [2-line description]
· Time I can spend : [○] hours per week / budget : [○ KRW] / people and data I can reach : [what]
F (Format): A table [candidate / how closed the scope is (5 pts) / can success be judged (5 pts) / can it finish in time (5 pts) / total / what must be cut].
Below the table, ① the one you recommend with 3 lines of reasoning ② one restated sentence that shrinks that problem to "one semester" size.
Do not be optimistic without grounds; if it looks impossible, say it is impossible.
[1-2] Success criteria statement
R (Role): You are an assessment designer who builds the standards for judging whether a project succeeded.
T (Task): For the problem below, write success criteria at three levels in the form "if this is observed, we call it solved."
C (Context):
· The problem in one sentence : [who / when / because of what / loses what]
· What I can measure : [whichever of time, count, cost, satisfaction I have]
· What I cannot measure : [things I can only observe]
F (Format): ① Minimum success (worth something even if only this happens) ② target success ③ beyond-target success. For each level, 3 lines on "what / how much / how you check."
End by naming 2 traps in measuring against these criteria.
[2-1] Cause logic tree
R (Role): You are a consultant who breaks a problem's cause structure apart without overlap.
T (Task): Expand the causes of the problem below into a logic tree, three levels deep.
C (Context):
· Problem (symptom) : [the observed fact as it is]
· Frequency and situation : [when, how often]
· What I already tried and why it failed : [if any]
· What I can control : [e.g. myself, my team, system settings]
F (Format): An indented tree. Level 1 has 4–5 branches, with levels 2 and 3 under each.
If branches at the same level overlap, merge them and reorganize.
Below the tree, a table [cause / impact (high·mid·low) / can I control it (yes·partly·no) / how to check].
Mark anything that is a guess as [hypothesis].
[2-2] 5 Whys interrogation
R (Role): You are an interrogator who does not accept an answer easily.
T (Task): Ask "why?" five times about the symptom I give you and dig down to the cause. If my answer is thin, do not move on — push back.
C (Context):
· Symptom : [what happens]
· My first explanation : [the reason I think it is]
F (Format): Why 1 through 5 in order. At each step ① the question ② what your answer implies ③ where that inference could be wrong.
Finish with 2 candidate structural causes that do not end at "it's a matter of attitude."
[3-1] Problem → executable tasks
R (Role): You are a project designer who cuts complex work into executable units.
T (Task): Break what has to be done to solve the problem below into three levels: ① large chunks ② the tasks in each chunk ③ the prerequisite for each task.
C (Context):
· Problem to solve : [the strike point chosen in Week 2]
· Success criteria : [Week 1 success criteria]
· Constraints : time [○] hours per week / budget [○ KRW] / people [○] / what I can access [what]
· What I already have : [materials, tools, relationships]
F (Format): A table [task / output / estimated time / what it needs / prerequisite task].
Group into ten tasks or fewer, and cut each one to a size you can finish in 1–2 hours.
Below the table, "the three things to do first" with reasons, and also "three things that can wait."
[3-2] Constraint squeeze test
R (Role): You are a doer who produces results with almost no resources.
T (Task): Reorganize the task list below from the angle of "if I had half the time I have now, what would I keep and what would I drop?"
C (Context):
· Task list : [paste the result of 3-1]
· What I absolutely cannot give up : [the one core success criterion]
F (Format): ① 4 tasks to keep and why ② the tasks to drop and the grounds for dropping them ③ 2 risks created by dropping them and how to cover each.
Do not answer "you can do both" — force a choice.
[4-1] Basic RTCF template
R (Role): You are a [job title] with [number] years in [field].
T (Task): [one thing you want done, stated as a verb]
C (Context):
· Background : [situation]
· What I already know : [existing information]
· Constraints : [deadline, format, what is off limits]
· Who reads this : [audience and how much they already know]
F (Format): [table/bullets/paragraphs] · length [○ lines] · tone [concise/formal/persuasive]
Rules:
① Mark anything you are not sure of as "uncertain"
② Give the source alongside any figure or citation
③ Keep facts and your own inference in separate paragraphs
[4-2] Diagnose and improve my prompt
R (Role): You are a prompt engineer who diagnoses prompts and fixes them.
T (Task): Diagnose my instruction below and write an improved version.
C (Context):
--- my instruction ---
[paste here]
--- what I expected ---
[what I wanted]
--- what disappointed me in the actual result ---
[what fell short]
F (Format): ① Diagnosis of what is missing (which of role, task, context, format is empty) ② the full improved version ③ 3 lines on what you changed and why.
Put [bracketed] variables in the improved version so it is reusable. Five variables at most.
[5-1] SCAMPER seven-axis expansion
R (Role): You are an ideation facilitator who defers judgment and specializes in raising the sheer number of ideas.
T (Task): Generate solutions to the problem below across the seven SCAMPER axes, 3 per axis, 21 in total.
C (Context):
· Problem to solve : [the Week 2 strike point]
· Solutions so far : [the 8 I wrote by hand — do not duplicate these]
· How it works now : [how this is handled today]
· Where it is used : [who uses it, where, when]
F (Format): A list grouped by axis. Each idea gets a one-line title plus a one-line description.
The seven axes = Substitute / Combine / Adapt / Modify / Put to other use / Eliminate / Reverse.
Rules: Do not evaluate feasibility at this stage. Do not repeat near-identical ideas; give each axis a different grain.
[5-2] Extreme-condition ideation
R (Role): You are someone who finds the solutions that only appear when resources are extremely limited.
T (Task): Solve the problem below again under four extreme conditions.
C (Context):
· Problem : [the problem in one sentence]
· Current candidate solutions : [the 3 leading ideas]
F (Format): 2 ideas per condition.
① If the budget were zero ② if it had to be finished today ③ if no tools were allowed (people only) ④ if instead of removing the problem you made it bigger (reverse).
Under each idea, one line on "what survives in reality once this condition is lifted."
[6-1] Defining the contradiction and separating it
R (Role): You are a TRIZ-based problem solver who breaks trade-offs without compromising.
T (Task): Define the contradiction blocking me in the situation below, and build alternatives that eliminate it using the separation principles.
C (Context):
· What I want : [the A I want to gain]
· The problem that comes with it : [the B I lose]
· My current compromise : [how I am splitting the difference today]
· Absolute condition : [what cannot be given up]
F (Format):
① 2 contradiction statements (in the form "raise A and B gets worse")
② the ideal final result in one sentence (zero cost, zero side effects)
③ solutions per separation principle: separation in time / in space / by condition / whole-part, 2 each
④ a judgment on whether each solution actually removed the contradiction or merely postponed it
Rule: Do not accept "strike a reasonable balance" compromises as answers.
[6-2] Forcing counterintuitive solutions
R (Role): You are a reverse-thinking strategist who looks for answers on the far side of common sense.
T (Task): For the problem below, produce 5 solutions that "nobody would normally do," and find the condition under which each one works.
C (Context):
· Problem : [the problem in one sentence]
· Received wisdom in this area : [3 things everyone does]
F (Format): For each solution ① the counterintuitive idea ② why nobody normally does it ③ the condition under which it works anyway ④ can I create that condition (yes/no).
Mark the ones where ④ is "yes" with a ★.
[7-1] Weighted evaluation matrix
R (Role): You are a decision analyst who scores alternatives against criteria without sentiment.
T (Task): Score the candidates below against my criteria and weights, and rank them.
C (Context):
· Candidate list : [the ideas that passed the filter, one line each]
· Criteria and weights : [e.g. impact 40% / feasibility 30% / cost 20% / urgency 10%]
· Hard constraints (violation = out) : [within ○ KRW, ○ people, done within ○ weeks]
· Success criteria : [the ones set in Week 1]
F (Format): A table [candidate / score per criterion (5-point scale) / weighted total / passes hard constraints / reason for elimination].
Below the table, ① a summary of ranks 1–3 ② the 3 biggest weaknesses of the top idea ③ the conditions under which the runner-up should be chosen.
Rule: Do not score generously. Mark any high score given without grounds as [insufficient grounds].
[7-2] Optimum under extreme constraints
R (Role): You are an execution designer who produces workable plans with almost no budget or people.
T (Task): Scale the selected solution down into something executable under "zero budget · one person · two weeks."
C (Context):
· Selected solution : [the top-ranked idea]
· Success criterion that must hold : [the one that matters]
· Free tools and channels I can use : [what]
F (Format): ① A 5-line outline of the reduced plan ② the features given up and why that is acceptable ③ a two-week schedule (by day) ④ how this reduced version can still test the success criterion.
[8-1] Self-review before submitting
R (Role): You are a demanding reviewer grading this assignment. You do not score generously.
T (Task): Grade my solution concept specification below against the criteria and point out where it falls short.
C (Context):
--- my specification ---
[paste the full text]
--- grading criteria ---
· Sophistication of the solution logic 40% (soundness of the decomposition, logical completeness, handling of exceptions)
· Use and structuring of AI 30% (prompt design, reproducibility of the process)
· Evidence and validation 30% (rationale for selection, fit of the data and cases)
F (Format): A table [item / score (out of 100) / reason for deduction / how I can fix it now].
Below the table, ① the 5 questions I will certainly get in the presentation and the gist of good answers ② the 3 weakest sentences in this specification, quoted verbatim, with replacements.
[9-1] Procedure → flowchart (Mermaid)
R (Role): You are a process designer who turns working procedures into flowcharts.
T (Task): Turn the procedure below into Mermaid flowchart code.
C (Context):
· What I am solving : [the problem in one sentence]
· Procedure (as I wrote it) :
1) [step]
2) [step]
...
· Points that need a decision : [in "if ~ then" form]
· Points where it can fail : [what I know of]
F (Format):
① A Mermaid code block (flowchart TD, decisions as diamonds {}, processes as rectangles [])
② Tag each node with its actor: [human]/[AI]/[automatic]
③ Below the code, a table [step / input / output / fallback on failure]
④ Point out 3 steps missing from my procedure
Rule: Every decision node must have a "no" path. If one is missing, add it.
[9-2] Drawing the human–AI boundary
R (Role): You are an operations designer who decides how far to automate.
T (Task): Sort each step below into work a person must do / work AI may do / work to fully automate, with reasons.
C (Context):
· Step list : [the steps from 9-1]
· Damage if it goes wrong : [what happens when it fails]
· Personal or sensitive data involved : [what, if any]
F (Format): A table [step / owner (human·AI·automatic) / reason / size of the damage if wrong (high·mid·low) / when a person must check].
Below the table, the "steps that must never be automated" and 3 lines on why.
[10-1] Designing a prompt chain
R (Role): You are a workflow designer who splits one large task into a series of instructions.
T (Task): Design the repetitive task below as a 4–6 stage prompt chain. For each stage, write the full instruction text I can paste and use as is.
C (Context):
· Repetitive task : [what I do every time]
· What comes in as input : [form of the material]
· Final deliverable : [what has to come out]
· Quality bar : [what makes it good]
F (Format): For each stage,
[Stage N] purpose / role / input spec / output spec / full instruction text
Make the last stage a "review and rebut" stage, with a role different from the earlier stages.
Below the chain, a table [stage / where it can break / how to prevent it].
[10-2] AI agent architecture
R (Role): You are someone who designs structures that combine AI in several roles to handle one job.
T (Task): Design an AI agent setup that achieves the goal below. Define each agent's role, input, output and stopping condition.
C (Context):
· Goal : [what I want handled automatically]
· Where a person must check : [what]
· Tools available : [search, documents, spreadsheets, etc.]
· Damage on failure : [what]
F (Format): ① An agent table [name / role / input / output / when it stops]
② the processing flow as a Mermaid flowchart
③ marks for where a person intervenes (HITL)
④ 3 ways this setup could run away and how to stop each.
[11-1] Setup text for a document-grounded assistant
R (Role): You are a project-specific assistant that answers only from the material I have uploaded.
T (Task): For each of my questions, find the evidence in the uploaded material and answer with a citation.
C (Context):
· Project : [the problem in one sentence]
· Material : [types and number of documents]
· User : [who uses this assistant]
F (Format): Every answer has ① a 3-line conclusion ② evidence (document name + the passage quoted) ③ anything not in the material marked [not in the material].
Absolute rules:
① Do not fill answers with knowledge from outside the uploaded material
② When documents conflict, show both sides and leave the judgment to the user
③ When you speculate, say [speculation] first
[11-2] Designing automation for a repetitive task
R (Role): You are a workflow automation designer who turns repetitive work into automated pipelines.
T (Task): Turn the repetitive task below into an automation design in trigger–process–output form.
C (Context):
· Repetitive task : [what, how often]
· Time it takes now : [○ min per run]
· Where the input comes from : [email, form, file, message, etc.]
· Where the result has to go : [document, spreadsheet, message, etc.]
· Exceptions : [problems that come up now and then when doing it by hand]
F (Format): ① A pipeline table [order / trigger or process / tool / input / output / on failure]
② expected time after automation and the saving
③ the steps that should not be automated, and why
④ 3 items to verify manually in parallel during the first week.
[12-1] Requesting a red team attack
R (Role): You are a red team determined to make this solution fail. No compliments.
T (Task): Find the weaknesses in the solution below and attack them. Show how it actually breaks, as scenarios.
C (Context):
· Solution overview : [description of the solution]
· Execution procedure : [flowchart summary]
· What I am assuming : [things I have taken for granted]
· Users : [who uses it]
F (Format): 10 attacks, split into three groups.
① Breaks by mistake (bad input, misunderstanding)
② breaks on purpose (abuse, gaming it)
③ breaks under rare conditions (edge cases)
For each attack, [situation → what happens → size of the damage (high·mid·low)].
Finish by naming the 3 "most dangerous assumptions in this solution." Skip the trivia; start with what is fatal.
[12-2] Exception design + ethics check
R (Role): You are a safety designer who designs a system's exception handling and its risks.
T (Task): Build the defense for the attack list below, and check the ethical and personal-data risks.
C (Context):
· Attack list : [paste the result of 12-1]
· Resources I have : [time, tools]
· Data involved : [is there personal data in what this handles]
F (Format):
① An exception scenario table [situation / how it is detected / response / when a person steps in / priority]
② split into fix now (3) / fix later / declare out of scope
③ an ethics table [who could be harmed / what harm / likelihood / mitigation / who is accountable]
④ 3 lines on the limits that must be stated when this solution is released.
[13-1] Fixing the MVP scope
R (Role): You are a product owner who cuts scope without mercy.
T (Task): From the feature list below, keep only what is strictly necessary to test one success criterion and cut everything else.
C (Context):
· Solution : [description of the solution]
· Success criterion to test : [only one]
· Feature list : [everything I want to build]
· Time available to build : [○ hours]
· Tools available : [what]
F (Format): ① 3 features or fewer to keep, with reasons ② the features to cut and the grounds ③ the risk of cutting them and a temporary workaround (including having a person handle it) ④ a judgment on whether this can be built in [○ hours].
Rule: Cut everything that is merely "nice to have." Every reason for keeping something must connect directly to the success criterion.
[13-2] Prototype build spec
R (Role): You are a maker who builds prototypes with no-code tools.
T (Task): Write the build spec and the step-by-step build order for the MVP below.
C (Context):
· Features kept : [3 or fewer]
· Usage flow : first screen → [core action] → [seeing the result]
· Tools I will use : [documents, forms, spreadsheets, AI chatbots — whatever I can actually use]
· User skill level : [how comfortable with technology]
F (Format):
① A list of screens and components [screen / component / what the user does / how the system responds]
② a data table [field / type / required / example value]
③ the build order (split into steps of 30 minutes or less)
④ marks on the parts a person can handle behind the scenes
⑤ a demo script (from first screen to result in 60 seconds).
R (Role): You are a user validation designer who pulls meaningful conclusions out of small samples.
T (Task): Build the validation design for testing the prototype below with 5 people.
C (Context):
· Prototype : [what it does]
· Success criterion to test : [the Week 1 criterion]
· Participants : [who, how many, in what setting]
· Time required : [○ min] per person
F (Format):
① One falsifiable hypothesis ("if ~, then ~ changes by ~")
② a metrics table [metric / how it is measured / threshold for success / quantitative or qualitative]
③ the session script (including what you say, worded so it never hints)
④ an observation sheet [step / time taken / where they got stuck / what the user said / observer notes]
⑤ 3 biases this design could introduce and how to reduce each.
[14-2] Results → CER report
R (Role): You are an analyst who interprets data without overstating it.
T (Task): Turn the test results below into a validation report in claim-evidence-reasoning (CER) form.
C (Context):
· Hypothesis : [the falsifiable sentence]
· Quantitative data : [completion rate, time taken, error count, etc.]
· Qualitative data : [observation notes, quotes from users]
· Number and makeup of participants : [○ people, who]
F (Format):
① A 3-line conclusion (state one of: hypothesis supported / partly supported / rejected)
② 3 CER sets: claim → evidence (cite the data) → reasoning (why the data supports it)
③ a table [problem point / how many hit it / severity / proposed fix / fix it now or not]
④ 3 things these results cannot tell us (limits of sample and setting)
⑤ pick only 1–2 things to fix in the next version, with reasons.
Rule: Do not generalize from 5 people. Do not use the phrase "most users."
[15-1] Structuring and rehearsing the final talk
R (Role): You are a presentation coach who structures an 8-minute talk and draws out the likely questions.
T (Task): Build an 8-minute script and a list of likely questions from the material below.
C (Context):
· Problem : [one sentence]
· Solution and rationale : [summary]
· Validation results : [whether the hypothesis held, and the key figures]
· Limits : [what I know of]
· Audience : [professor and fellow students]
F (Format): ① A script with the time split marked (1 min · 2 min · 2 min · 2 min · 1 min) ② a proposed 8-slide structure [slide / title / what goes on it / what to leave off]
③ 10 likely questions and the gist of the answers ④ the 3 sentences in my talk most open to attack, with replacements.
Rule: Flag any wording that overstates the results and replace it with fact-based wording.
[15-2] Writing the peer review
R (Role): You are a reviewer who reviews a peer's project constructively but accurately.
T (Task): Write a review of the peer project below.
C (Context):
· Their problem and solution : [summary]
· Their validation results : [summary]
· What impressed me in the talk : [what]
· What I did not follow : [what]
F (Format): ① 2 things done well (with specific evidence) ② 3 places where the logic is weak, and why ③ 1 thing I would have done differently in their position ④ 3 questions worth checking.
Rule: No comments on the person or their attitude — write only about the deliverable and the logic. A review that only praises will be sent back.
R (Role): You are a project designer who splits complex problems into a cause structure and executable tasks.
T (Task): Break the problem below into three stages: ① a cause logic tree (3 levels) ② selection of the strike point ③ a task table.
C (Context):
· Problem to solve : {{prob}}
· Success criterion : {{goal}} (checked by: {{meas}})
· Constraints : {{time}} per week / {{res}}
· What I already have : {{have}}
F (Format):
① Cause logic tree — indented, 4–5 branches at level 1, down to level 3. Merge branches that overlap at the same level.
② Strike point table [cause / impact (high·mid·low) / can I control it / how to check] → recommend the 1–2 to hit this semester, with reasons.
③ Task table [task / output / estimated time / what it needs / prerequisite task] — 10 or fewer, each sized at 1–2 hours.
④ The 3 things to do first / the 3 things that can wait.
Rules:
· Mark anything that is a guess as [hypothesis]
· Do not end a cause at "it's a matter of attitude" — find the structural cause
· Do not propose tasks that exceed the constraints above
R (Role): You are an ideation facilitator who defers judgment and raises the number of ideas.
T (Task): Generate solutions to the cause below across the seven SCAMPER axes (substitute, combine, adapt, modify, put to other use, eliminate, reverse), 3 per axis, 21 in total. Do not evaluate feasibility at this stage.
C (Context):
· Cause I am striking : {{target}}
· How it works now : {{now}}
· Criteria and weights : {{crit}}
· Hard constraints (violation = out) : {{hard}}
F (Format):
① Idea list — one-line title plus one-line description, grouped by axis
② hard-constraint filter results [candidate / passes / reason for elimination]
③ weighted evaluation matrix [candidate / 5-point score per criterion / weighted total / rank]
④ the 3 biggest weaknesses of the top idea, and the conditions under which the runner-up should be chosen
Rules:
· Do not repeat near-identical ideas; give each axis a different grain
· Do not score generously; mark any high score without grounds as [insufficient grounds]
· Do not answer "you can do both" — make a choice
R (Role): You are someone who finds the solutions that only appear when resources are extremely limited.
T (Task): Solve the problem below again under four extreme conditions, 2 ideas each. ① Zero budget ② finished today ③ no tools, people only ④ reversal (what if you made the problem bigger instead).
C (Context):
· Cause I am striking : {{target}}
· How it works now : {{now}}
· Criteria and weights : {{crit}}
· Hard constraints (violation = out) : {{hard}}
F (Format):
① Ideas by condition — one-line title plus one-line description, 2 per condition
② under each idea, one line on "what survives in reality once this condition is lifted"
③ hard-constraint filter results [candidate / passes / reason for elimination]
④ weighted evaluation matrix [candidate / 5-point score per criterion / weighted total / rank] and the 3 biggest weaknesses of the top idea
Rules:
· Do not repeat near-identical ideas
· Do not score generously; mark any high score without grounds as [insufficient grounds]
· Do not answer "you can do both" — make a choice
R (Role): You are a TRIZ-based problem solver who breaks trade-offs without compromising.
T (Task): Define the contradiction blocking the situation below in two sentences, and build 2 solutions each using separation in time, space, condition, and whole-part. Do not accept a compromise as an answer.
C (Context):
· Cause I am striking : {{target}}
· How it works now : {{now}}
· Criteria and weights : {{crit}}
· Hard constraints (violation = out) : {{hard}}
F (Format):
① 2 contradiction statements (in the form "raise A and B gets worse") and the ideal final result in one sentence
② solutions per separation principle — time / space / condition / whole-part, 2 each
③ a judgment on whether each solution actually removed the contradiction or merely postponed it
④ weighted evaluation matrix [candidate / 5-point score per criterion / weighted total / rank] and the 3 biggest weaknesses of the top idea
Rules:
· Do not accept "strike a reasonable balance" compromises as answers
· Do not score generously; mark any high score without grounds as [insufficient grounds]
· Eliminate any idea that fails a hard constraint, regardless of its score
R (Role): You are a decision analyst who scores alternatives against criteria without sentiment.
T (Task): Score the candidates below against my criteria and weights and rank them. Eliminate any idea that fails a hard constraint, regardless of its score.
C (Context):
· Cause I am striking : {{target}}
· How it works now : {{now}}
· Criteria and weights : {{crit}}
· Hard constraints (violation = out) : {{hard}}
· Candidate list : [paste my ideas here, one line each]
F (Format):
① Hard-constraint filter results [candidate / passes / reason for elimination]
② weighted evaluation matrix [candidate / 5-point score per criterion / weighted total / rank]
③ the 3 biggest weaknesses of the top idea, and the conditions under which the runner-up should be chosen
④ a list of the items in this scoring that lacked grounds
Rules:
· Do not score generously; mark any high score without grounds as [insufficient grounds]
· Do not answer "you can do both" — make a choice
R (Role): You are a user validation designer who pulls meaningful conclusions out of small samples.
T (Task): Build the full validation design for testing the prototype below with real users.
C (Context):
· What the prototype does : {{proto}}
· Success criterion to test : {{goal}}
· Participants : {{user}}
· Test time per person : {{min}}
· What can be measured : {{metric}}
F (Format):
① One falsifiable hypothesis ("if ~, then ~ changes by ~")
② metrics table [metric / how it is measured / threshold for success / quantitative or qualitative]
③ session script — including wording that never hints
④ observation sheet [step / time taken / where they got stuck / what the user said / notes]
⑤ a CER frame for writing up the results (3 claim-evidence-reasoning sets)
⑥ 3 biases in this design and how to reduce each
Rules:
· The sample is small, so do not generalize the results
· Do not use phrases like "most users"
· Include how to interpret the outcome if the hypothesis is rejected
PART 1 · 1주차
문제 해결이란 무엇인가
AI는 마법 지팡이가 아니다 — 해결 가능한 문제를 고르는 눈
PBLⅠ · AI Problem Solving
오늘의 질문
“지금 불편한 그 문제, 한 학기 안에 풀 수 있는 문제입니까?”
대답이 “모르겠다”라면, 아직 문제가 아니라 감정입니다.
핵심 개념 1
문제란 간격이다
문제 = 지금의 상태와 바라는 상태 사이의 간격. 해결 = 그 간격을 좁히는 실행.
정의
두 상태를 모두 말할 수 없으면 문제를 정의한 것이 아닙니다.
예시
“공지를 놓친다”(지금) → “가입 당일 일정을 받는다”(바람).
흔한 오해
불평은 문제가 아닙니다. 바라는 상태가 없기 때문입니다.
주의
해결책을 문제로 위장하지 마십시오. “앱이 없다”는 문제가 아닙니다.
핵심 개념 2
해결 가능한 문제의 세 조건
① 범위가 닫힌다
누가, 어디서, 언제의 문제인지 경계를 그을 수 있다.
② 판정 기준이 있다
무엇이 관찰되면 해결된 것인지 미리 말할 수 있다.
③ 기간 안에 확인된다
15주 안에 결과를 한 번은 볼 수 있다.
세 조건 중 하나라도 비면 문제를 줄이십시오. “청년 실업”은 문제가 아니라 주제입니다.
핵심 개념 3
AI가 하는 일과 하지 못하는 일
AI가 잘하는 것
분해를 돕고, 대안을 늘리고, 초안을 쓰고, 내 논리를 공격해 줍니다.
사람만 하는 것
무엇을 해결할지 정하기 · 가치를 판단하기 · 결과에 책임지기.
AI는 답을 만드는 기계가 아니라, 내 질문의 해상도를 비추는 거울입니다.
핵심 개념 4
컴퓨팅 사고 3단계
분해큰 덩어리를 실행 가능한 조각으로 자른다
→
패턴인식반복되는 구조와 이미 풀린 사례를 찾는다
→
추상화본질만 남기고 나머지를 버린다
이 세 단어가 남은 14주의 뼈대입니다. 코드는 쓰지 않지만 사고는 프로그래머처럼 합니다.
전체 지도
이 과목이 지나가는 길
1–4주문제를 해부한다
→
5–8주해법을 넓히고 좁힌다
→
9–12주로직으로 옮긴다
→
13–15주만들고 검증한다
앞 과목이 “무엇이 문제인가”였다면, 이 과목은 “그래서 어떻게 할 것인가”입니다.
사례
같은 불편, 세 개의 다른 문제
“시험 기간에 도서관에 자리가 없다” — 어떻게 정의하느냐가 해결 경로를 정합니다.
공급 문제좌석이 부족하다 → 공간을 늘린다 (내 통제 밖, 학기 내 불가)배분 문제빈자리 정보가 없다 → 실시간 표시 (통제 가능, 확인 가능)행동 문제짐만 두고 비운다 → 점유 규칙 설계 (통제 가능, 측정 가능)
같은 현상에서 내가 손댈 수 있는 정의를 고르는 것이 1주차의 전부입니다.
오늘 만드는 것
문제 한 문장 + 성공 기준 3층위
누가 / 언제 / 무엇 때문에 / 어떤 손해를 보는가
최소 성공 — 이것만 되어도 의미가 있다
목표 성공 — 학기말에 달성하려는 수준
초과 성공 — 여기까지 가면 기대 이상이다
각 층위는 “무엇을 / 얼마나 / 어떻게 확인”까지 적어야 완성입니다.
정리
오늘의 세 문장
문제는 간격이다. 두 상태를 말할 수 없으면 아직 문제가 아니다.
해결 가능한 문제는 범위·판정·기간 세 조건을 통과한다.
무엇을 풀지 정하는 일은 끝까지 사람의 몫이다.
다음 주 현상과 원인을 분리합니다. 증상을 치료하면 문제는 반드시 되돌아옵니다.
PART 1 · WEEK 1
What Problem Solving Is
AI is not a magic wand — learning to pick a problem you can actually solve
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“That thing bothering you — can it be solved in one semester?”
If the answer is “I don't know”, it isn't a problem yet. It's a feeling.
KEY CONCEPT 1
A problem is a gap
Problem = the gap between the current state and the wanted state. Solving = the work that closes it.
Definition
If you can't state both states, you haven't defined a problem.
Example
“I miss announcements” (now) → “I get the schedule on day one” (wanted).
Common mistake
A complaint is not a problem — it names no wanted state.
Watch out
Don't disguise a solution as a problem. “There's no app” is not a problem.
KEY CONCEPT 2
Three conditions for a solvable problem
① Closed scope
You can draw a boundary: whose problem, where, and when.
② A test exists
You can say in advance what would count as solved.
③ Visible in time
You can see a result at least once within 15 weeks.
If any condition is empty, shrink the problem. “Youth unemployment” is a topic, not a problem.
KEY CONCEPT 3
What AI does — and what it can't
AI is good at
Helping you decompose, multiplying options, drafting, and attacking your own logic.
Only people do
Deciding what to solve · judging what matters · carrying the consequences.
AI is not a machine that makes answers. It is a mirror that shows the resolution of your question.
KEY CONCEPT 4
Computational thinking, three moves
Decomposecut the lump into executable pieces
→
Find patternsspot what repeats and what is already solved
→
Abstractkeep the essence, drop the rest
These three words are the skeleton of the remaining 14 weeks. You write no code, but you think like a programmer.
THE MAP
Where this course goes
Weeks 1–4dissect the problem
→
Weeks 5–8widen then narrow the options
→
Weeks 9–12turn it into logic
→
Weeks 13–15build it and test it
The previous course asked “what is the problem?”. This one asks “so what will you do about it?”
CASE
One complaint, three different problems
“There are no free seats in the library during exams” — how you define it decides your whole path.
SupplyNot enough seats → add space (outside your control, not doable this term)AllocationNo information about free seats → live status (controllable, testable)BehaviourPeople leave bags and vanish → occupancy rule (controllable, measurable)
Choosing the definition you can act on is the whole job of week 1.
WHAT YOU MAKE TODAY
One-sentence problem + three tiers of success
who / when / because of what / suffers what harm
Minimum success — this alone would already be worth it
Target success — what you aim to reach by week 15
Stretch success — beyond expectations if you get here
A tier is finished only when it states what, how much, and how you will check it.
WRAP-UP
Three sentences from today
A problem is a gap. If you can't state both states, it isn't one yet.
A solvable problem passes three tests: scope, judgement, time.
Deciding what to solve stays a human job, all the way through.
Next week we separate symptoms from causes. Treat the symptom and the problem always comes back.
PART 1 · 2주차
현상과 원인 분리하기
5 Whys와 로직트리로 증상이 아닌 뿌리를 치기
PBLⅠ · AI Problem Solving
오늘의 질문
“고쳤다고 생각한 그 문제, 왜 한 달 뒤에 그대로 돌아옵니까?”
증상을 치료했기 때문입니다. 구조는 그대로 남아 있습니다.
핵심 개념 1
증상과 원인은 다른 것이다
증상은 눈에 보이는 사실이고, 원인은 그 사실을 반복해 만들어 내는 구조입니다.
증상
관찰한 그대로 적을 수 있습니다. “신청자가 정원의 20%다.”
원인
보이지 않습니다. 증상을 계속 만들어 내는 조건과 흐름입니다.
흔한 오해
“홍보가 부족하다”는 원인이 아니라 또 하나의 증상입니다.
주의
원인 자리에 사람의 태도를 적으면 사고가 거기서 멈춥니다.
핵심 개념 2
5 Whys를 제대로 쓰는 법
① 사실에서 출발
추측이 아니라 실제로 관찰한 증상 하나를 고릅니다.
② 막히는 곳을 지나기
대개 세 번째 왜부터 말문이 막힙니다. 거기가 뿌리 근처입니다.
③ 구조에서 멈추기
답이 규칙·정보 흐름·설계에 닿으면 그때 멈춥니다.
“학생들이 게을러서”로 끝났다면 실패입니다. 태도는 원인이 아니라 결과입니다.
핵심 개념 3
나열과 트리는 다르다
로직트리
원인을 층으로 나눕니다. 위 가지는 아래 가지들의 합으로 설명됩니다.
그냥 나열
순서 없는 목록은 무엇을 먼저 쳐야 하는지 알려 주지 않습니다.
겹치지 않게, 빠짐없이 — 이 두 마디가 MECE의 전부입니다.
핵심 개념 4
오늘의 작업 3단계
증상 확정사실만 여섯 개, 해석은 뺀다
→
원인 전개왜를 반복해 3단 이상 가지로 펼친다
→
지점 선택영향도 × 통제가능성으로 하나를 고른다
순서를 뒤집지 마십시오. 원인을 모른 채 고른 해법은 증상 처방이 됩니다.
전체 지도
이번 주가 놓인 자리
1주차문제를 한 문장으로 정의했다
→
2주차그 문제의 원인 구조를 그린다
→
3주차고른 원인을 작업으로 자른다
→
4주차그 작업을 AI에게 정확히 시킨다
오늘 고르는 공격 지점이 3주차 분해의 출발점입니다. 여기가 틀리면 뒤가 전부 흔들립니다.
사례
왜를 다섯 번 물었더니
“학과 행사 신청자가 정원의 20%에 그친다” — 같은 증상에서 시작했습니다.
증상마감일까지 정원 40석 중 8석만 찼다세 번째 왜학생이 공지를 본 시점에 이미 신청이 끝나 있다다섯 번째 왜공지는 게시판, 확인은 단톡 — 채널이 어긋나 있다
공격 지점은 채널 불일치입니다. 홍보를 늘리는 처방과는 완전히 다른 일이 됩니다.
오늘 만드는 것
원인 로직트리 + 공격 지점
3단 이상 전개한 원인 로직트리 + 공격 지점 1~2개 표시본
1단 — 관찰한 증상 하나를 맨 위에 놓는다
2~3단 — 왜를 물어 가지를 펼치고 겹친 가지를 지운다
표시 — 영향이 크고 내가 손댈 수 있는 지점에 표시한다
가지가 사람의 태도에서 멈췄다면 아직 3단이 아닙니다. 한 층 더 내려가십시오.
정리
오늘의 세 문장
증상을 고치면 문제는 되돌아옵니다. 구조를 고쳐야 멈춥니다.
세 번째 왜부터가 진짜입니다. 답이 막히는 곳을 지나가십시오.
원인을 다 칠 수는 없습니다. 하나를 골라야 학기가 굴러갑니다.
다음 주 고른 원인을 1~2시간짜리 작업으로 자릅니다. 큰 덩어리는 실행되지 않습니다.
PART 1 · WEEK 2
Separating Symptom from Cause
Hitting the root instead of the symptom, with 5 Whys and a logic tree
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“That problem you thought you fixed — why is it back a month later?”
Because you treated the symptom. The structure that made it is still there.
KEY CONCEPT 1
A symptom is not a cause
A symptom is a visible fact. A cause is the structure that keeps producing that fact.
Symptom
You can write it down as observed: “only 20% of the seats get booked.”
Cause
Invisible. The condition or flow that produces the symptom again and again.
Common mistake
“We didn't promote it enough” is not a cause. It is another symptom.
Watch out
Write an attitude in the cause slot and your thinking stops right there.
KEY CONCEPT 2
How to run 5 Whys properly
① Start from a fact
Pick one symptom you actually observed, not one you assume.
② Push past the stall
Answers usually stall at the third why. That is where the root sits.
③ Stop at structure
Stop when the answer lands on a rule, an information flow, or a design.
If you end at “people are lazy,” you failed. Attitude is not a cause. It is a result.
KEY CONCEPT 3
A list is not a tree
Logic tree
Causes sit in levels. A branch above is explained by the branches under it.
Plain list
An unordered list never tells you which cause to strike first.
No overlaps, no gaps — that is the whole of MECE.
KEY CONCEPT 4
Today's work, three moves
Fix symptomssix plain facts, no interpretation
→
Spread causesask why until the tree is three levels deep
→
Pick the pointchoose one on impact × controllability
Do not reverse the order. A solution chosen before the cause is known is a symptom prescription.
THE MAP
Where this week sits
Week 1defined the problem in one sentence
→
Week 2draw the cause structure behind it
→
Week 3cut the chosen cause into tasks
→
Week 4hand those tasks to AI precisely
The strike point you choose today is the starting line for week 3. Get it wrong and everything after shakes.
CASE
What five whys turned up
“Only 20% of the seats at our department event get booked” — one symptom, dug down.
SymptomBy the deadline, 8 of 40 seats were takenThird whyBy the time students see the notice, booking has closedFifth whyNotices go on the board; students check the group chat
The strike point is the channel mismatch — an entirely different job from promoting harder.
WHAT YOU MAKE TODAY
Cause logic tree + strike point
A logic tree three levels deep + a copy with 1–2 strike points marked
Level 1 — put one observed symptom at the top
Levels 2–3 — ask why, spread branches, delete the overlaps
Mark — circle what has large impact and you can touch
If a branch ends at someone's attitude, you are not three levels deep yet. Go one further.
WRAP-UP
Three sentences from today
Fix a symptom and it comes back. Only fixing structure stops it.
The real answers start at the third why. Push past where it stalls.
You cannot strike every cause. Pick one or the semester stalls.
Next week we cut that cause into one- to two-hour tasks. A lump never gets done.
PART 1 · 3주차
문제 분해 (Decomposition)
해결 불가능해 보이는 덩어리를 1~2시간짜리 작업으로 자르기
PBLⅠ · AI Problem Solving
오늘의 질문
“그 문제, 내일 오후 두 시에 정확히 무엇을 하면 됩니까?”
대답이 나오지 않으면 아직 문제가 아니라 덩어리입니다.
핵심 개념 1
분해란 실행 단위로 자르는 일
분해 = 문제를 한 번 앉아서 끝낼 수 있는 작업들로 바꾸는 일입니다.
적정 크기
1~2시간. 앉은 자리에서 끝나고 결과가 남는 크기입니다.
산출
작업마다 손에 남는 것이 있어야 합니다. 표 하나, 목록 하나.
너무 크면
두 시간을 넘는 작업은 시작 자체가 계속 미뤄집니다.
너무 작으면
15분짜리를 늘어놓으면 관리하는 일이 더 커집니다.
핵심 개념 2
좋은 작업의 세 조건
① 시작 조건이 있다
무엇이 끝나야 이것을 시작할 수 있는지 적혀 있습니다.
② 끝이 보인다
무엇이 나오면 끝인지 한 줄로 말할 수 있습니다.
③ 혼자 착수한다
남의 허락을 기다리지 않고 오늘 시작할 수 있습니다.
셋 중 하나라도 비어 있으면 그것은 작업이 아니라 아직 계획입니다. 다시 자르십시오.
핵심 개념 3
추상화 수준을 맞춘다
층위가 같다
“설문 문항 10개 쓰기”와 “설문 링크 배포하기”는 크기가 같습니다.
층위가 섞였다
“조사한다”와 “링크 만들기”가 한 목록에 있으면 진행이 멈춥니다.
목록에서 가장 큰 항목과 가장 작은 항목의 크기 차이가 곧 계획의 오차입니다.
핵심 개념 4
오늘의 작업 3단계
제약 확정시간·돈·사람·데이터를 숫자로 적는다
→
분해와 삭제목록을 펼친 뒤 필요 없는 줄을 지운다
→
순서 확정선행조건을 연결해 첫 3개를 정한다
제약을 먼저 적으십시오. 제약이 없는 분해는 작업표가 아니라 희망 목록이 됩니다.
전체 지도
이번 주가 놓인 자리
1주차문제를 한 문장으로 정했다
→
2주차칠 원인 하나를 골랐다
→
3주차그 원인을 작업표로 자른다
→
4주차각 작업을 AI에게 지시한다
작업표는 이번 주로 끝나지 않습니다. 남은 12주 동안 계속 보는 기준표입니다.
사례
덩어리를 작업으로 자르면
“공지 채널이 어긋나 있다” — 학기짜리 덩어리에서 잘라낸 첫 세 작업입니다.
작업 1 (1시간)지금 쓰는 공지 경로 3개를 그림 한 장으로 정리한다작업 2 (2시간)신입 회원 8명에게 실제 확인 경로를 묻는다작업 3 (1.5시간)단일 공지 양식 초안 한 장을 쓴다
선행조건은 1 → 2 → 3입니다. 작업 2의 결과가 없으면 작업 3은 추측이 됩니다.
오늘 만드는 것
실행 작업표 10개 이하
작업 / 산출 / 소요 시간 / 선행조건 — 네 칸을 모두 채운 표
작업 — 동사로 시작하는 한 줄
산출 — 끝났을 때 손에 남는 물건
선행조건 — 이보다 먼저 끝나야 하는 작업 번호
표를 다 채운 뒤, 가장 먼저 할 3개에 표시하십시오. 다음 주는 거기서 시작합니다.
정리
오늘의 세 문장
실행되는 크기는 1~2시간입니다. 더 크면 반드시 미룹니다.
목록의 층위가 섞이면 진행은 그 자리에서 멈춥니다.
제약을 숫자로 적을 때 해법은 비로소 구체적이 됩니다.
다음 주 이 작업들을 AI에게 시킵니다. 지시가 흐리면 결과도 흐립니다.
PART 1 · WEEK 3
Decomposition
Cutting an unsolvable-looking lump into one- to two-hour tasks
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Your problem — what exactly do you do at two o'clock tomorrow?”
If no answer comes, you don't have a problem yet. You have a lump.
KEY CONCEPT 1
Decomposition cuts to executable size
Decomposition = turning a problem into tasks you can finish in one sitting.
Right size
One to two hours. It ends where you sat down, and it leaves something.
Output
Every task must leave something in your hands: one table, one list.
Too big
Anything over two hours never gets started. You postpone it.
Too small
Line up fifteen-minute items and tracking them costs more than doing them.
KEY CONCEPT 2
Three conditions for a good task
① It has a start
You wrote down what must finish before this one can begin.
② The end is visible
You can say in one line what has to exist for it to be done.
③ You can start alone
You can begin today without waiting for anyone's permission.
If any of the three is empty, it is not a task yet — it is a plan. Cut it again.
KEY CONCEPT 3
Match the level of abstraction
Same level
“Write 10 survey questions” and “send out the survey link” are the same size.
Mixed levels
Put “do research” next to “make the link” and progress stops there.
The gap between your largest and smallest item is the error margin of your plan.
KEY CONCEPT 4
Today's work, three moves
Fix constraintswrite time, money, people, data as numbers
→
Split and deletespread the list, then cut the lines you don't need
→
Fix the orderchain prerequisites and mark the first three
Write the constraints first. Without them a decomposition is not a task table but a wish list.
THE MAP
Where this week sits
Week 1fixed the problem in one sentence
→
Week 2picked one cause to strike
→
Week 3cut that cause into a task table
→
Week 4hand each task to AI as an instruction
The task table does not end this week. It is the reference you keep reading for 12 more weeks.
CASE
A lump, cut into tasks
“Our notice channels don't match” — here are the first three tasks cut out of it.
Task 1 (1 hr)Draw the three notice routes we use today on one pageTask 2 (2 hrs)Ask 8 new members where they actually check for newsTask 3 (1.5 hrs)Draft one single notice format, one page
Prerequisites run 1 → 2 → 3. Without the result of task 2, task 3 is a guess.
WHAT YOU MAKE TODAY
A task table of ten or fewer
task / output / time / prerequisite — all four columns filled
Task — one line that starts with a verb
Output — the thing left in your hands when it ends
Prerequisite — the number of the task that must finish first
Once the table is full, mark the three you do first. Next week starts from there.
WRAP-UP
Three sentences from today
The size that actually gets done is one to two hours. Bigger, and you postpone.
Mix levels in one list and progress stops on the spot.
Solutions get concrete only when constraints are written as numbers.
Next week we hand these tasks to AI. A vague instruction returns a vague result.
PART 1 · 4주차
효과적인 AI 소통 · RTCF
역할·작업·맥락·형식 4요소로 지시문 구조화하기
PBLⅠ · AI Problem Solving
오늘의 질문
“같은 AI에게 물었는데 왜 누구는 쓸 만한 답을 받습니까?”
질문의 재능이 아니라 지시문 구조의 차이입니다.
핵심 개념 1
프롬프트는 질문이 아니라 지시서다
AI의 답은 내가 준 정보의 함수입니다. 답이 흐리면 지시가 흐린 것입니다.
정의
프롬프트는 사람에게 일을 맡길 때 쓰는 작업 지시서와 같습니다.
예시
“홍보 알려줘” 대신 “신입생 200명에게 3일 안에 알릴 방법 5개”.
흔한 오해
짧게 물으면 알아서 채워 준다 — 채우는 것은 사실이 아니라 추측입니다.
주의
AI는 모르는 것도 자신 있게 씁니다. 확인은 끝까지 사람의 몫입니다.
핵심 개념 2
RTCF · 먼저 세 요소
R · 역할
누구로서 답할지 지정합니다. 전문성의 층위가 여기서 정해집니다.
T · 작업
동사 하나로 정확히. 한 프롬프트에는 작업 하나만 넣습니다.
F · 형식
표·불릿·줄 수·톤. 받은 뒤 다시 손보는 시간을 없앱니다.
남은 한 글자 C(맥락)가 답의 품질을 가장 크게 바꿉니다. 다음 장에서 따로 봅니다.
핵심 개념 3
C · 맥락이 결과를 가른다
맥락을 준 지시
대상·제약·이미 아는 것 세 줄. 답이 내 상황으로 좁혀집니다.
맥락 없는 지시
교과서 요약이 돌아옵니다. 누구에게나 맞는 답은 나에게 맞지 않습니다.
맥락 세 줄이 답변 세 페이지의 값어치를 바꿉니다.
핵심 개념 4
오늘의 작업 3단계
막 던지기평소처럼 묻고 결과를 저장한다
→
4요소 보강R·T·C·F를 채워 같은 질문을 다시 쓴다
→
템플릿 고정반복되는 형태를 변수 5개로 저장한다
좋은 지시문은 한 번에 나오지 않습니다. 언제나 고쳐 쓰기의 결과입니다.
전체 지도
이번 주가 놓인 자리
1~3주차문제와 작업표를 손으로 만들었다
→
4주차AI에게 정확히 시키는 법을 익힌다
→
5~8주차이 템플릿으로 해법을 넓히고 좁힌다
→
9~15주차같은 방식으로 만들고 검증한다
RTCF는 이번 주로 끝나는 개념이 아니라, 남은 11주 내내 쓰는 공구입니다.
사례
같은 요구, 두 개의 지시문
“동아리 공지 채널을 하나로 합치는 안을 찾고 싶다” — 결과가 이렇게 갈립니다.
막 던진 지시“동아리 공지 잘하는 법 알려줘” → 일반론 열 줄RTCF 지시역할·작업·맥락 3줄·표 형식 지정 → 비교표 다섯 행달라진 것우리 제약이 반영되고, 바로 쓸 형태로 돌아왔다
바뀐 것은 AI가 아니라 입력입니다. 차이의 대부분은 맥락에서 옵니다.
오늘 만드는 것
재사용 RTCF 템플릿 3종
조사용 · 분석용 · 작성용 — 변수 5개 이내로 고정한 템플릿
조사용 — 무엇을 모으고 어떤 표로 정리할지 지정한다
분석용 — 판단 기준과 비교 축을 미리 준다
작성용 — 독자·분량·톤을 고정한다
모든 템플릿 하단에 환각 방지 3규칙을 고정하십시오 — 모르면 모른다 / 출처 요구 / 사실과 추론 분리.
정리
오늘의 세 문장
답의 품질은 재능이 아니라 지시의 구조에서 옵니다.
네 요소 중 맥락(C)이 답을 가장 크게 바꿉니다. 세 줄 이상 쓰십시오.
잘 쓴 지시문은 버리지 말고 템플릿으로 남기십시오.
다음 주 SCAMPER 7축으로 해법을 30안까지 넓힙니다. 먼저 양으로 이깁니다.
PART 1 · WEEK 4
Talking to AI Effectively · RTCF
Structuring instructions with four elements: role, task, context, format
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Same AI, same question — why does someone else get a usable answer?”
It isn't a talent for asking. It's the structure of the instruction.
KEY CONCEPT 1
A prompt is an instruction, not a question
The answer is a function of what you gave it. A vague answer means a vague instruction.
Definition
Write it the way you would brief a person you are handing work to.
Example
Not “tell me about promotion” but “5 ways to reach 200 freshmen in 3 days”.
Common mistake
Ask short and it fills the rest in — but it fills it with guesses, not facts.
Watch out
AI states what it does not know with full confidence. Checking stays your job.
KEY CONCEPT 2
RTCF · the first three elements
R · Role
Specify who is answering. That is what sets the level of expertise.
T · Task
One precise verb. One prompt carries exactly one task.
F · Format
Table, bullets, line count, tone. This is what removes the rework.
The remaining letter, C (context), moves quality more than the rest. We take it on its own next.
KEY CONCEPT 3
C · context decides the result
With context
Three lines: who it is for, the constraints, what you already know.
Without context
You get a textbook summary. An answer that fits anyone fits nobody.
Three lines of context change what three pages of answer are worth.
KEY CONCEPT 4
Today's work, three moves
Just askask as you normally would, save the result
→
Add the fourrewrite the same question with R, T, C, F
→
Freeze a templatesave the shape with five variables or fewer
A good instruction never arrives on the first try. It is always the result of rewriting.
THE MAP
Where this week sits
Weeks 1–3built the problem and task table by hand
→
Week 4learn to instruct AI precisely
→
Weeks 5–8use these templates to widen and narrow
→
Weeks 9–15build and test the same way
RTCF does not end this week. It is the tool you keep in hand for the remaining 11 weeks.
CASE
One need, two instructions
“I want options for merging our club's notice channels” — the results split like this.
Just asked“How do clubs do announcements well?” → ten generic linesRTCF versionRole, task, 3 lines of context, table format → a 5-row tableWhat changedOur constraints show up, and it arrives ready to use
The AI did not change. The input did. Most of the difference comes from context.
WHAT YOU MAKE TODAY
Three reusable RTCF templates
research · analysis · writing — each frozen with five variables or fewer
Research — say what to collect and what table it goes into
Analysis — hand over the criteria and the axes of comparison
Writing — fix the reader, the length and the tone
Pin the three anti-hallucination rules at the bottom of each: say when you don't know / demand sources / separate fact from inference.
WRAP-UP
Three sentences from today
Answer quality comes from the structure of the instruction, not talent.
Of the four, context (C) moves the answer most. Write three lines or more.
Don't throw away an instruction that worked. Keep it as a template.
Next week we widen to 30 solution ideas across the seven SCAMPER axes. Win on quantity first.
PART 2 · 5주차
발산적 사고 · SCAMPER × AI
먼저 양으로 이긴다 — 해법 아이디어 30안 만들기
PBLⅠ · AI Problem Solving
오늘의 질문
“좋은 아이디어 하나를 찾고 있습니까, 아이디어 서른 개를 찾고 있습니까?”
좋은 하나는 언제나 서른 개 뒤에 숨어 있습니다.
핵심 개념 1
발산과 수렴은 다른 시간에 한다
발산은 양을 늘리는 시간, 수렴은 줄이는 시간. 섞으면 둘 다 실패합니다.
정의
오늘은 판단을 유보합니다. 평가는 7주차에 기준을 세운 뒤 합니다.
신호
“그건 안 될 것 같은데”가 나오면 이미 수렴으로 넘어간 것입니다.
흔한 오해
좋은 안만 적으면 효율적이라는 착각. 후보가 적으면 비교가 불가능합니다.
주의
판단 유보는 판단 포기가 아닙니다. 미루는 것일 뿐입니다.
핵심 개념 2
SCAMPER 7축, 세 묶음으로
바꾸기 · S/M/P
대체·변형·용도전환. 지금 쓰는 재료나 쓰임을 다른 것으로 갈아 끼웁니다.
붙이기 · C/A
결합·응용. 이미 있는 것 둘을 합치거나, 남의 해법을 가져옵니다.
빼고 뒤집기 · E/R
제거·역발상. 없애면 어떻게 되는지, 반대로 하면 어떻게 되는지 봅니다.
7축은 영감이 아니라 강제 이동 장치입니다. 막힌 자리에서 옆으로 밀어 줄 뿐입니다.
핵심 개념 3
AI는 증폭기다
축을 지정한 AI
“제거 축으로 5안”처럼 방향을 주면 서로 다른 안이 나옵니다.
그냥 물어본 AI
“아이디어 30개”만 시키면 평범한 30개가 옵니다. 축이 없기 때문입니다.
증폭기는 신호를 키울 뿐입니다. 내가 0을 넣으면 30배도 0입니다.
핵심 개념 4
오늘의 발상 3단계
맨손AI 없이 8안을 손으로 쓴다 — 내 기준선
→
축 걸기7축 × 3안, AI로 21안까지 늘린다
→
극단 조건예산 0원 · 하루 안에 · 반대로 하면
맨손 단계를 건너뛰면 AI의 답이 내 생각인지 판단할 기준선이 사라집니다.
전체 지도
이번 주가 서 있는 자리
1–4주문제를 하나로 좁혔다
→
5주해법을 최대한 넓힌다
→
6주막는 모순을 깬다
→
7주기준으로 1안까지 줄인다
이번 주는 일부러 넓히는 주입니다. 좁히는 일은 2주 뒤에 합니다.
사례
같은 문제, 축을 바꿨을 때
“점심시간 학식 줄이 20분을 넘는다” — 축마다 다른 방향이 열립니다.
제거줄 자체를 없앤다 — 시간대 예약 픽업용도전환빈 강의실을 12시에만 식사 공간으로 연다역발상사람을 옮기지 말고 음식을 밖으로 내보낸다
세 안 모두 같은 문제에서 나왔습니다. 축을 바꾸면 보이는 방향이 바뀝니다.
오늘 만드는 것
해법 아이디어 30안 리스트
축 / 조건 / 아이디어 한 줄 — 30행
맨손 8안 — AI를 켜기 전에 확보한 기준선
SCAMPER 21안 — 7축을 하나도 비우지 않는다
극단 조건 확장안 — 조건을 함께 적는다
중복은 합치되 지우지 마십시오. 오늘 버린 안이 다음 주의 재료입니다.
정리
오늘의 세 문장
발산과 수렴은 같은 시간에 하지 않는다.
SCAMPER는 영감이 아니라 강제 이동 장치다.
AI는 증폭기다. 축이 없으면 평범한 30개만 남는다.
다음 주 모순을 다룹니다. “좋은데 이것 때문에 안 된다”의 그 ‘이것’이 진짜 문제입니다.
PART 2 · WEEK 5
Divergent Thinking · SCAMPER × AI
Win on quantity first — generate 30 solution ideas
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Are you looking for one good idea, or for thirty ideas?”
The good one is always hiding behind the other twenty-nine.
KEY CONCEPT 1
Diverge and converge at different times
Divergence is time spent adding options. Convergence is time spent cutting them. Mix them and both fail.
Definition
Today judgment is suspended. You evaluate in Week 7, after the criteria exist.
The signal
The moment you think “that won't work”, you have already switched to converging.
Common mistake
Writing only the good ideas feels efficient. With few candidates you cannot compare.
Watch out
Suspending judgment is not abandoning it. You are postponing it, not skipping it.
KEY CONCEPT 2
Seven SCAMPER axes, in three groups
Change it · S/M/P
Substitute, modify, put to other use. Swap the material or the purpose for another one.
Join it · C/A
Combine and adapt. Fuse two things you already have, or borrow someone else's answer.
Cut and flip · E/R
Eliminate and reverse. Ask what happens if it is gone, or done the other way round.
The axes are not inspiration. They are a forced sideways push out of the place you are stuck.
KEY CONCEPT 3
AI is an amplifier
AI with an axis
Name the direction — “five ideas on the eliminate axis” — and the answers differ from each other.
AI without one
Ask for “30 ideas” and you get 30 ordinary ones. Nothing told it where to go.
An amplifier only makes the signal louder. Put in zero and thirty times zero is still zero.
KEY CONCEPT 4
Today's ideation, three moves
Bare hands8 ideas written without AI — your baseline
→
Set an axis7 axes × 3 ideas, up to 21 with AI
→
Extreme conditionszero budget · one day · the opposite
Skip the bare-handed step and you lose the baseline that tells you whether the AI's answer is yours.
THE MAP
Where this week sits
Weeks 1–4you narrowed it to one problem
→
Week 5widen the solutions as far as you can
→
Week 6break the contradiction blocking them
→
Week 7cut down to one with criteria
This week widens on purpose. The narrowing happens two weeks from now.
CASE
Same problem, different axis
“The lunch queue at the canteen runs over 20 minutes” — each axis opens a different direction.
EliminateRemove the queue — pre-order with a pickup slotPut to other useOpen empty lecture rooms as seating at noon onlyReverseDon't move people — move the food out to them
All three came from one problem. Change the axis and the direction you can see changes.
WHAT YOU MAKE TODAY
A list of 30 solution ideas
axis / condition / one line of idea — 30 rows
8 by hand — the baseline you set before switching AI on
21 from SCAMPER — leave none of the seven axes empty
Extreme-condition ideas — write the condition next to each
Merge duplicates, but delete nothing. What you throw out today is next week's raw material.
WRAP-UP
Three sentences from today
Diverging and converging never share the same hour.
SCAMPER is not inspiration. It is a forced move sideways.
AI amplifies. Without an axis you get 30 ordinary ideas.
Next week we take on contradictions. The “this is what stops it” part is the real problem.
PART 2 · 6주차
모순 해결 · TRIZ
“A를 얻으면 B를 잃는” 구조를 깨는 법
PBLⅠ · AI Problem Solving
오늘의 질문
“그 아이디어는 좋은데, 왜 실행이 안 됩니까?”
막고 있는 것은 대개 자원이 아니라 하나의 모순입니다.
핵심 개념 1
모순이 곧 문제다
문제가 안 풀리는 자리에는 언제나 “A를 높이면 B가 나빠진다”가 있습니다.
정의
하나의 변수를 개선할 때 다른 변수가 반드시 나빠지는 관계입니다.
예시
“검사를 꼼꼼히 하면 정확해지고, 대기 시간이 길어진다.”
흔한 오해
“돈이 없다”는 모순이 아니라 조건입니다. 두 변수가 없기 때문입니다.
주의
A와 B를 이름으로 쓰지 못하면 아직 모순을 찾은 것이 아닙니다.
핵심 개념 2
분리 4원리
시간으로
평소에는 A, 특정 시간에는 B. 가장 흔하게 통하는 해법입니다.
공간으로
여기서는 A, 저기서는 B. 장소를 나누면 충돌이 사라집니다.
조건·부분으로
이 사람에게는 A, 저 사람에게는 B. 또는 전체는 A, 부품은 B.
네 원리는 결국 하나를 묻습니다. “언제 · 어디서 · 누구에게 A입니까?”
핵심 개념 3
절충하지 않는다
소거안
모순 자체를 없앱니다. A도 얻고 B도 잃지 않는 구조를 만듭니다.
절충안
“적당히 반씩”은 A도 B도 절반만 남깁니다. 대개 둘 다 실패합니다.
“둘 중 하나를 고르라”는 말을 들으면, 먼저 그 질문을 의심하십시오.
핵심 개념 4
오늘의 해결 3단계
모순 쓰기A를 높이면 B가 나빠진다 — 두 문장
→
이상적 결과비용도 부작용도 0, 기능만 남은 상태
→
분리 적용시간 · 공간 · 조건 · 부분을 모두 시도
이상적 최종 결과를 먼저 선언하고 거기서 역산합니다. 가능한 것부터 세면 멀리 가지 못합니다.
전체 지도
이번 주가 서 있는 자리
5주30안을 넓게 모았다
→
6주막고 있던 모순을 소거한다
→
7주기준과 제약으로 1안을 고른다
→
8주솔루션 컨셉으로 발표한다
5주차에 “좋은데 안 된다”고 접었던 안들이 오늘의 재료입니다.
사례
조별 과제 회의의 모순
회의를 늘리면 정보는 모이지만, 시간이 없어 아무도 오지 않습니다.
모순회의를 늘리면 정보는 모이고, 참석률은 떨어진다이상적 결과모이지 않아도 정보가 모여 있는 상태시간 분리주 1회 10분만 대면, 나머지는 기록으로 공유
절충(주 2회 30분)은 둘 다 잃습니다. 분리는 둘 다 얻습니다.
오늘 만드는 것
모순 정의서 + 해소 아이디어 5안
“A를 높이면 B가 나빠진다” 2문장 + 이상적 최종 결과 1문장
모순 2문장 — A와 B를 각각 이름으로 쓴다
분리 시도 기록 — 네 원리를 하나도 비우지 않는다
소거안 5개 — 모순이 사라진 이유를 함께 적는다
절충안은 제출물에 넣지 마십시오. 오늘은 소거안만 셉니다.
정리
오늘의 세 문장
안 풀리는 문제 뒤에는 하나의 모순이 있다.
절충은 둘 다 잃는다. 소거를 목표로 한다.
이상적 결과를 먼저 선언하고 역산한다.
다음 주 넓힌 것을 좁힙니다. 기준을 먼저 세우고, 점수는 그다음에 매깁니다.
PART 2 · WEEK 6
Resolving Contradictions · TRIZ
How to break the “gain A, lose B” structure
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“The idea is good — so why can't you do it?”
What blocks it is usually not resources. It is one contradiction.
KEY CONCEPT 1
The contradiction is the problem
Wherever a problem refuses to move, you will find “raise A and B gets worse”.
Definition
A relation where improving one variable necessarily damages another.
Example
“Check it thoroughly and it gets accurate — and the wait gets longer.”
Common mistake
“We have no money” is a condition, not a contradiction. There is no second variable.
Watch out
If you cannot name A and B, you have not found the contradiction yet.
KEY CONCEPT 2
The four separation principles
By time
A most of the time, B at certain hours. The one that works most often.
By space
A here, B there. Split the place and the collision disappears.
By condition or part
A for these people, B for those. Or A for the whole, B for one component.
All four ask a single question: “when, where, and for whom is it A?”
KEY CONCEPT 3
Do not compromise
Elimination
Remove the contradiction itself. You get A without giving up B.
Compromise
“A bit of each” leaves half of A and half of B. Usually both then fail.
When someone tells you to pick one of the two, first doubt the question.
KEY CONCEPT 4
Today's resolution, three moves
State itraise A and B gets worse — two sentences
→
Ideal resultthe function, at zero cost and zero side effect
→
Separatetry time, space, condition and part
Declare the ideal final result first and work backwards. Start from what is possible and you never travel far.
THE MAP
Where this week sits
Week 5you gathered 30 ideas, wide
→
Week 6eliminate what was blocking them
→
Week 7pick one with criteria and constraints
→
Week 8present it as a solution concept
The ideas you set aside in Week 5 as “good, but impossible” are today's material.
CASE
The contradiction inside team meetings
More meetings gather more information — and nobody has the time to show up.
ContradictionMore meetings, more information shared, worse attendanceIdeal resultThe information is gathered without anyone meetingSeparate by timeOne 10-minute meeting a week; the rest in writing
The compromise — twice a week, 30 minutes — loses both. Separation keeps both.
WHAT YOU MAKE TODAY
Contradiction statement + 5 ideas that resolve it
“raise A and B gets worse” in 2 sentences + the ideal final result in 1
The contradiction — name A and B explicitly, both of them
A record of attempts — leave none of the four principles empty
Five eliminations — say why the contradiction is gone in each
Keep compromises out of the deliverable. Only eliminations count today.
WRAP-UP
Three sentences from today
Behind a stuck problem sits a single contradiction.
Compromise loses both sides. Aim for elimination.
Declare the ideal result first, then work backwards.
Next week we narrow what we widened. Criteria come first, scores come after.
PART 2 · 7주차
수렴적 사고와 제약 충족
평가 매트릭스로 30안을 1안으로 줄이기
PBLⅠ · AI Problem Solving
오늘의 질문
“그 안을 고른 이유를 30초 안에 말할 수 있습니까?”
말하지 못한다면 고른 것이 아니라 끌린 것입니다.
핵심 개념 1
기준을 먼저, 점수는 나중에
기준은 후보를 보기 전에 확정합니다. 순서가 바뀌면 채점은 형식일 뿐입니다.
정의
기준은 “무엇이 좋은 해법인가”에 대한 우리 팀의 선언입니다.
출처
1주차 성공 기준에서 가져옵니다. 새로 지어내지 않습니다.
흔한 오해
후보를 보고 기준을 만들면 이미 답을 정해 놓은 것입니다.
주의
기준은 4~5개면 충분합니다. 열 개가 되면 아무것도 고를 수 없습니다.
핵심 개념 2
평가 매트릭스의 세 부품
기준
효과·실현가능성·비용·시급성처럼 서로 겹치지 않는 4~5개.
가중치
합이 100이 되게 나눕니다. 성공 기준에 가까운 항목에 무게를 줍니다.
점수
1~5점으로 매기고, 가중치를 곱해 합산합니다.
가중치를 나누는 순간 무엇을 포기할지가 정해집니다. 그 논쟁이 오늘의 본론입니다.
핵심 개념 3
하드 제약과 소프트 기준
하드 제약
예산 0원 · 인력 1명 · 2주. 통과 아니면 탈락, 점수가 없습니다.
소프트 기준
점수로 비교합니다. 여기에 제약을 섞으면 못 하는 안이 살아남습니다.
제약을 넘지 못하는 안은, 아무리 좋아도 우리에게는 좋은 안이 아닙니다.
핵심 개념 4
오늘의 수렴 3단계
제약 필터못 넘는 안을 먼저 자른다 — 30안 → 10안
→
가중 채점남은 안만 점수 × 가중치로 합산
→
반론 방어“왜 2위가 아닌가”를 세 줄로 답한다
완벽한 최적해는 찾지 않습니다. 충분히 좋은 안을 빠르게 찾고 근거로 지킵니다.
전체 지도
이번 주가 서 있는 자리
5주30안으로 넓혔다
→
6주모순을 소거해 5안을 얻었다
→
7주기준과 제약으로 1안을 정한다
→
8주그 1안을 컨셉으로 발표한다
오늘 고른 1안이 남은 8주 동안 만들 대상입니다. 그래서 근거가 필요합니다.
사례
학식 대기 문제, 후보 셋
하드 제약은 “예산 0원 · 실행 인력 1명 · 2주 안 확인”입니다.
예약 픽업효과 5점 — 학교 시스템 권한 필요 → 제약 탈락혼잡도 알림효과 3점 — 2주·1명 가능 → 가중 합계 4.2수업 시간 조정효과 5점 — 내 통제 밖 → 제약 탈락
1위는 점수가 가장 높은 안이 아니라 제약을 통과한 안 중 가장 높은 안입니다.
오늘 만드는 것
평가 매트릭스 + 최종 1안 근거서
기준 4~5개 × 가중치 합 100 × 제약을 통과한 후보 10안
탈락 목록 — 어떤 제약에 걸렸는지 함께 적는다
가중 합계표 — 1위와 2위의 점수 차이를 표시한다
“왜 2위가 아닌가” — 세 줄 방어문
AI가 매긴 점수를 그대로 두지 마십시오. 최소 한 칸은 내 판단으로 고칩니다.
정리
오늘의 세 문장
기준을 후보보다 먼저 정한다.
하드 제약은 점수가 아니라 통과·탈락이다.
선택은 점수가 아니라 방어할 수 있는 근거로 끝난다.
다음 주 중간고사입니다. 1~7주 산출물을 솔루션 컨셉 명세서 하나로 묶어 발표합니다.
PART 2 · WEEK 7
Convergent Thinking and Constraint Satisfaction
Cutting 30 ideas down to 1 with an evaluation matrix
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Can you say why you chose it in thirty seconds?”
If you can't, you didn't choose it. You were drawn to it.
KEY CONCEPT 1
Criteria first, scores later
Fix the criteria before you look at the candidates. Reverse that order and scoring is just theatre.
Definition
Criteria are your team's declaration of what counts as a good solution.
Where they come from
From your Week 1 success criteria. You do not invent new ones now.
Common mistake
Build criteria after seeing the candidates and you have already picked the winner.
Watch out
Four or five criteria is enough. At ten, nothing can ever win.
KEY CONCEPT 2
Three parts of an evaluation matrix
Criteria
Four or five that don't overlap — impact, feasibility, cost, urgency.
Weights
Split them so they total 100. Weight goes to whatever sits closest to success.
Scores
Score 1 to 5, multiply by the weight, and add the columns up.
The moment you split the weights you decide what you are giving up. That argument is today's real work.
KEY CONCEPT 3
Hard constraints vs soft criteria
Hard constraint
Zero budget · one person · two weeks. Pass or out — no score involved.
Soft criterion
Compared by score. Mix a constraint in here and an impossible idea survives.
An idea that fails a constraint is not a good idea for us, however good it is.
KEY CONCEPT 4
Today's convergence, three moves
Filtercut what fails a constraint — 30 down to 10
→
Scoreweight × score, on the survivors only
→
Defendanswer “why not the runner-up” in three lines
You are not hunting the perfect optimum. Find a good-enough answer fast and hold it with reasons.
THE MAP
Where this week sits
Week 5you widened it to 30 ideas
→
Week 6eliminating contradictions left 5
→
Week 7criteria and constraints leave 1
→
Week 8present that one as a concept
The idea you pick today is what you will build for eight more weeks. That is why it needs reasons.
CASE
Canteen queues, three candidates
Hard constraints: zero budget · one person doing it · a result visible in two weeks.
Pre-order pickupImpact 5 — needs campus system access → failsCrowding alertsImpact 3 — one person, two weeks → total 4.2Shift class timesImpact 5 — outside your control → fails
The winner is not the highest score. It is the highest score among those that passed.
WHAT YOU MAKE TODAY
Evaluation matrix + rationale for the final idea
4–5 criteria × weights totalling 100 × the 10 candidates that passed
The rejected list — note which constraint each one failed
Weighted totals — show the gap between first and second
“Why not the runner-up” — three lines of defence
Don't leave the AI's scores as they are. Change at least one cell with your own judgment.
WRAP-UP
Three sentences from today
Set the criteria before you see the candidates.
A hard constraint is not a score. It is pass or out.
A choice ends not with a number but with a defence.
Next week is the midterm. You bundle Weeks 1–7 into one solution concept spec and present it.
PART 2 · 8주차
솔루션 컨셉 발표
일곱 주의 산출물을 하나의 명세서로 — 근거로 답하는 발표
PBLⅠ · AI Problem Solving
오늘의 질문
“그 해법은 왜 하필 그것이어야 합니까?”
근거를 대지 못하면 좋은 안이어도 선택이 아니라 취향입니다.
핵심 개념 1
명세서가 증명해야 하는 것
명세서는 아이디어 소개가 아니라 선택의 증명입니다. 여섯 구성이 하나의 논리로 이어져야 합니다.
연결
1주차 문제 문장이 7주차 선정 근거까지 끊기지 않고 이어집니다.
추적
모든 주장 옆에 그 주장이 나온 주차의 산출물이 있어야 합니다.
흔한 오해
분량이 많으면 통합이 아닙니다. 일곱 개 파일을 붙인 것은 통합이 아닙니다.
주의
중간에 문제 정의를 슬쩍 바꾸지 마십시오. 바꿨다면 이유를 적으십시오.
핵심 개념 2
평가는 세 가지만 봅니다
① 통합성
문제·원인·대안·선정이 하나의 사슬로 읽히는가.
② 근거성
선택마다 기준과 데이터가 붙어 있는가.
③ 실행 가능성
남은 8주 안에 만들고 확인할 수 있는가.
셋 다 발표 태도가 아니라 문서에서 확인됩니다. 말로 보충해야 하는 부분은 아직 비어 있는 부분입니다.
핵심 개념 3
버린 안을 보여주십시오
고른 안만 말하면
청중은 비교하지 않은 사람으로 봅니다. 질문은 “다른 방법은요?”로 시작됩니다.
버린 안까지 말하면
탈락 이유가 곧 선정 근거가 됩니다. 질문이 확인으로 바뀝니다.
버린 안을 보여줘야 고른 안이 설득됩니다.
핵심 개념 4
7분을 세 덩어리로
1분 · 문제사례 하나로 시작한다
→
5분 · 근거의 사슬원인 · 공격 지점 · 대안 · 선정
→
1분 · 다음 8주무엇을 만들어 어떻게 검증하는가
뒤에 질의 3분이 붙습니다. 예상 질문 다섯 개의 답은 슬라이드가 아니라 문서에서 찾아 두십시오.
전체 지도
이 주의 위치
1–4주문제를 해부했다
→
5–7주대안을 넓히고 하나로 좁혔다
→
8주하나의 명세서로 묶는다
→
9–15주절차로 옮겨 만든다
오늘은 새 프레임워크를 배우지 않습니다. 가진 것을 하나로 만드는 날입니다.
사례
같은 주장, 약한 말과 강한 말
“도서관 실시간 좌석 표시”를 고른 팀의 세 가지 발표 문장입니다.
약한 말“실시간 좌석 표시가 가장 효율적이라고 생각합니다.”강한 말“3개 안 중 매트릭스 1위. 2안은 시설팀 협조가 필요해 탈락.”방어까지“최대 약점은 좌석 데이터 정확도. 12주차에 실측으로 검증합니다.”
강한 말에는 비교 대상과 탈락 이유가 들어 있습니다. 형용사는 근거가 아닙니다.
오늘 만드는 것
솔루션 컨셉 명세서
A4 5매 명세서 + 발표자료 + 프롬프트 원문 부록
여섯 구성 — 문제 · 원인 · 작업 분해 · 대안 · 선정 · 해결 로직 초안
탈락 기록 — 버린 안과 버린 이유를 명시
예상 질문 5개 — 답과 근거 위치를 미리 적어 둔다
중간고사 평가 비중 30%. 발표 7분 + 질의 3분.
정리
오늘의 세 문장
명세서는 소개가 아니라 선택의 증명이다.
평가는 통합성·근거성·실행 가능성 세 가지만 본다.
버린 안을 말하지 않으면 고른 안도 설득되지 않는다.
다음 주 해법을 절차로 옮깁니다. 순서도가 그려지지 않으면 아직 만들 수 없는 해법입니다.
PART 2 · WEEK 8
Solution Concept Presentation
Seven weeks of work into one specification — and answers backed by evidence
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Why does it have to be that solution and no other?”
Without a reason, even a good idea is a taste, not a choice.
KEY CONCEPT 1
What the specification must prove
The spec is not an introduction to an idea. It is proof of a choice, and the six sections must read as one argument.
Continuity
The week 1 problem sentence runs unbroken to the week 7 rationale.
Traceability
Every claim sits next to the deliverable it came from.
Common mistake
Length is not integration. Seven files stapled together is still seven files.
Watch out
Don't quietly redefine the problem midway. If you changed it, say why.
KEY CONCEPT 2
Three things we assess
① Integration
Do problem, cause, alternatives and choice read as one chain?
② Evidence
Does every choice carry a criterion and data?
③ Feasibility
Can it be built and checked in the remaining 8 weeks?
All three are read in the document, not in your delivery. Whatever you have to add out loud is what's still missing.
KEY CONCEPT 3
Show what you dropped
Only the chosen idea
You look like someone who never compared. Q&A opens with “what else did you consider?”
The dropped ones too
The reason each failed becomes your rationale. Questions turn into confirmation.
The idea you chose is only convincing next to the ones you rejected.
KEY CONCEPT 4
Seven minutes, three blocks
1 min · Problemopen with one real case
→
5 min · Chain of evidencecause, strike point, options, choice
→
1 min · Next 8 weekswhat you build, how you check it
Then 3 minutes of questions. Locate the answers to your five likely questions in the document, not in the slides.
THE MAP
Where this week sits
Weeks 1–4you dissected the problem
→
Weeks 5–7you widened, then picked one
→
Week 8tie it into one specification
→
Weeks 9–15turn it into procedure and build
No new framework today. This is the week you make what you already have into one thing.
CASE
One claim, weak and strong
Three ways a team could present the same choice: live library seat status.
Weak“We think live seat status is the most efficient option.”Strong“Top of three on the matrix. Option 2 died: needs facilities staff.”Defended“Biggest weakness is seat data accuracy. We test it in week 12.”
The strong version carries what it beat and why the others failed. Adjectives are not evidence.
WHAT YOU SUBMIT
The solution concept package
5-page specification + slides + full prompt appendix
Six sections — problem · cause · tasks · alternatives · selection · draft logic
The rejects — what you dropped, and the reason for each
Five likely questions — the answer and where its evidence lives
Midterm weight 30%. Seven minutes to present, three for questions.
WRAP-UP
Three sentences from today
A specification is not an introduction. It is proof of a choice.
We assess three things: integration, evidence, feasibility.
Say nothing about the rejects and your choice stays unproven.
Next week we turn the solution into procedure. If you can't draw the flowchart, you can't build it yet.
PART 3 · 9주차
알고리즘 설계 · 순서도로 사고하기
해결 절차를 조건·반복·분기로 기술하기
PBLⅠ · AI Problem Solving
오늘의 질문
“그 해법의 순서를 열 문장으로 적을 수 있습니까?”
적히지 않는다면 그것은 해법이 아니라 아직 소망입니다.
핵심 개념 1
절차로 쓸 수 없으면 못 만든다
알고리즘은 코드가 아니라 순서가 정해진 문장의 묶음입니다. 말로 되는데 그림이 안 되면 구멍이 있습니다.
조건
모든 단계는 입력과 출력이 있어야 합니다. 무엇을 받아 무엇을 내놓습니까.
단위
한 단계는 한 사람이 한 번에 끝낼 수 있는 크기여야 합니다.
흔한 오해
“AI가 알아서 처리한다”는 단계가 아닙니다. 무엇을 넣고 무엇을 받는지 쓰십시오.
주의
“아니오” 화살표가 빈 순서도는 12주차 테스트에서 반드시 깨집니다.
핵심 개념 2
기호는 세 개면 충분하다
① 처리 · 사각형
무언가를 하는 단계. 동사 하나로 쓸 수 있어야 합니다.
② 판단 · 마름모
예/아니오로 답하는 질문. 나가는 화살표가 항상 둘입니다.
③ 시작·끝 · 둥근 모서리
절차가 언제 시작되고 무엇으로 끝나는지 못박습니다.
순서도는 손으로 그려도 되고 Mermaid 문법으로 받아 화면에서 확인해도 됩니다. 모양보다 빠짐없음이 중요합니다.
핵심 개념 3
단계마다 주체를 적으십시오
AI에 맡길 단계
정해진 규칙으로 모으고 분류하고 초안을 쓰는 반복 작업.
사람이 쥘 단계
개인정보를 다루거나, 누군가에게 통보하거나, 되돌릴 수 없는 단계.
자동화해도 되는 단계와 해서는 안 되는 단계를 나누는 것이 설계입니다.
핵심 개념 4
순서도를 만드는 세 걸음
번호 문장절차를 10~15개 문장으로 쓴다
→
판단 지점 표시“만약 ~라면”이 있는 곳을 모두 찾는다
→
도식화 · 주체 표기기호로 옮기고 사람·AI를 적는다
그림부터 그리지 마십시오. 문장이 먼저입니다. 문장이 막히는 곳이 설계가 비어 있는 곳입니다.
전체 지도
이 주의 위치
7주1안을 골랐다
→
8주하나의 명세서로 묶었다
→
9주절차와 분기로 옮긴다
→
10–12주단계를 AI에 시키고 만든다
이번 주 순서도의 각 단계가 다음 주에는 프롬프트 한 개가 됩니다.
사례
팀플 미제출자 알림 절차
“마감 3일 전에 안 낸 사람에게 연락한다” — 이 한 줄을 절차로 펼칩니다.
처리제출 현황표를 읽어 미제출자 명단을 뽑는다판단마감 3일 전인가? 아니오면 내일 다시 확인한다주체명단 추출은 AI, 연락 문구 발송은 사람
판단 노드의 “아니오” 경로를 채우면 예외 목록이 저절로 만들어집니다.
오늘 만드는 것
해결 절차 순서도
순서도 한 장 + 단계별 주체·실패 대안표
번호 문장 10개 이상 — 순서도 이전에 글로 먼저 확정
모든 판단에 두 경로 — “아니오” 쪽을 비워 두지 않는다
단계별 주체 — [사람] / [AI] / [자동]과 실패 시 대안
AI가 판단하는 단계에는 그 판단이 틀렸을 때의 위험을 함께 적으십시오.
정리
오늘의 세 문장
절차로 쓸 수 없는 해법은 아직 만들 수 없는 해법이다.
처리·판단·시작끝 세 기호로 거의 모든 절차를 그린다.
분기의 “아니오” 쪽이 곧 예외 처리다.
다음 주 각 단계를 AI에게 넘깁니다. 한 프롬프트에 한 작업, 그리고 단계를 이어 붙입니다.
PART 3 · WEEK 9
Algorithm Design · Thinking in Flowcharts
Describing the procedure in conditions, loops and branches
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Can you write your solution as ten numbered steps?”
If it won't go on paper, it's still a wish, not a solution.
KEY CONCEPT 1
If you can't write the procedure, you can't build it
An algorithm is not code. It is sentences in a fixed order. If you can say it but not draw it, there is a hole.
Condition
Every step needs an input and an output. What goes in, what comes out?
Size
One step is what one person can finish in one sitting.
Common mistake
“AI handles it” is not a step. Write what you give it and what you get back.
Watch out
A chart with an empty “no” arrow will break in the week 12 test, without fail.
KEY CONCEPT 2
Three symbols are enough
① Process · rectangle
A step that does something. It should fit one verb.
② Decision · diamond
A yes/no question. Always two arrows leaving it.
③ Start·end · rounded
Pins down when the procedure begins and what ends it.
Draw it by hand, or get Mermaid text and check the diagram on screen. What matters is nothing missing, not neatness.
KEY CONCEPT 3
Label who does each step
Give AI
Repetitive work with fixed rules: collecting, sorting, drafting.
Keep with a person
Anything touching personal data, notifying someone, or impossible to undo.
Design is deciding which steps may be automated and which must not be.
KEY CONCEPT 4
Three moves to a flowchart
Numbered sentenceswrite the procedure as 10–15 lines
→
Mark decisionsfind every place an “if” appears
→
Draw · label actorsmove to symbols, tag human or AI
Don't start with the picture. Sentences first. Where the sentence stalls is where the design is empty.
THE MAP
Where this week sits
Week 7you picked one idea
→
Week 8you tied it into one spec
→
Week 9turn it into steps and branches
→
Weeks 10–12hand steps to AI and build
Each step in today's chart becomes one prompt next week. Vague steps make vague prompts.
CASE
Chasing missing group-project files
“Contact whoever hasn't submitted, three days before the deadline” — unfolded into a procedure.
ProcessRead the submission sheet, list who is missingDecisionThree days to deadline? If no, check again tomorrowActorAI builds the list; a person sends the message
Fill in the “no” path of every decision and your exception list writes itself.
WHAT YOU MAKE TODAY
The solution flowchart
One flowchart + a table of actors and failure fallbacks
Ten or more numbered sentences — settled in prose before any drawing
Two paths per decision — never leave the “no” side empty
An actor per step — [human] / [AI] / [automatic], plus the fallback
Wherever AI does the judging, write down the risk of it judging wrong.
WRAP-UP
Three sentences from today
A solution you can't write as a procedure is one you can't build yet.
Three symbols — process, decision, start/end — draw almost anything.
The “no” side of a branch is your exception handling.
Next week we hand those steps to AI: one prompt per task, then chained together.
PART 3 · 10주차
프롬프트 체이닝과 AI 에이전트
한 번에 시키지 말고, 연결해서 시키기
PBLⅠ · AI Problem Solving
오늘의 질문
“한 번에 다 시켰는데 왜 전부 평범합니까?”
네 가지를 동시에 시키면 네 가지 모두 평균 이하로 돌아옵니다.
핵심 개념 1
한 프롬프트에 한 작업
수집·요약·작성·검토는 성격이 다른 작업입니다. 한 지시문에 섞으면 서로의 품질을 깎습니다.
원칙
한 단계에 동사 하나. 지시문에 “그리고”가 많으면 잘라야 할 신호입니다.
이점
단계가 나뉘면 어디서 틀렸는지 보입니다. 그 단계만 고치면 됩니다.
흔한 오해
프롬프트를 길게 쓰면 좋아진다는 생각. 길이가 아니라 단위의 문제입니다.
주의
단계를 너무 잘게 쪼개면 옮겨 붙이는 시간이 더 듭니다. 4~6단계가 적당합니다.
핵심 개념 2
한 단계를 이루는 세 가지
① 입력 규격
무엇을 받는가. 앞 단계의 출력과 형태가 같아야 합니다.
② 작업 지시
이 단계에서 할 일 하나와 지켜야 할 제약.
③ 출력 규격
표·목록·문단 중 무엇으로, 몇 개, 어떤 항목으로 내놓는가.
체인이 끊기는 곳은 언제나 접합부입니다. 앞의 출력 규격이 뒤의 입력 규격이 되도록 미리 못 박으십시오.
핵심 개념 3
검토는 다른 역할에게
다른 역할·다른 세션
“까다로운 심사자” 역할을 주고 초안만 넘기면 빠진 것을 지적합니다.
같은 대화에서 자기 검토
쓴 맥락을 그대로 안고 있어 관대해집니다. “좋습니다”만 돌아옵니다.
쓴 사람과 검토하는 사람을 분리하는 것은 사람 조직에서도 같은 이유입니다.
핵심 개념 4
체인을 만드는 세 걸음
자르기반복 업무 하나를 4~6단계로 나눈다
→
규격 정하기단계마다 입력과 출력 형식을 고정한다
→
돌리고 검토 붙이기끊긴 지점을 적고 검토 단계를 더한다
이 체인을 목표만 주면 스스로 돌리도록 묶은 것이 에이전트입니다. 오늘은 그 구조를 손으로 설계합니다.
전체 지도
이 주의 위치
9주절차를 순서도로 그렸다
→
10주단계를 프롬프트 체인으로 옮긴다
→
11주내 자료를 붙이고 자동화한다
→
12–13주프로토타입으로 만들어 시험한다
순서도의 한 사각형이 체인의 한 단계가 됩니다. 9주차 그림을 옆에 펴 두십시오.
사례
매주 반복되는 스터디 자료 요약
“읽을거리 다섯 개를 요약해 공유한다” — 세 단계로 나눈 체인입니다.
1단계 · 수집자료마다 핵심 문장 3개를 뽑아 표로 (출력: 표)2단계 · 작성그 표만 입력으로 받아 A4 1매 요약을 쓴다3단계 · 검토다른 세션의 조교 역할이 빠진 쟁점을 지적한다
2단계에 원문을 다시 넣지 마십시오. 앞 단계의 출력만 넘겨야 체인이 유지됩니다.
오늘 만드는 것
프롬프트 체인 설계서
4단계 이상 체인 설계서(지시문 전문 포함) + 실행 결과
단계표 — 단계마다 입력 규격 · 작업 · 출력 규격
검토 단계 — 다른 역할로 분리해 마지막에 배치
끊긴 지점 기록 — 어디서 왜 멈췄고 무엇을 고쳤는가
설계만 하지 말고 실제로 끝까지 한 번 돌려 보십시오. 끊기는 곳은 돌려야 보입니다.
정리
오늘의 세 문장
한 프롬프트에 한 작업. 섞으면 전부 평균 이하가 된다.
체인이 끊기는 곳은 언제나 접합부의 형식이다.
검토는 다른 역할·다른 세션으로 분리한다.
다음 주 이 체인에 내 자료를 붙입니다. AI가 내 문서를 근거로 답하게 만드는 구성(RAG)을 다룹니다.
PART 3 · WEEK 10
Prompt Chaining and AI Agents
Don't ask for it all at once — chain it
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“You asked for everything at once. Why is all of it mediocre?”
Ask for four jobs in one go and all four come back below average.
KEY CONCEPT 1
One prompt, one task
Gathering, summarizing, writing and reviewing are different kinds of work. Mixed into one instruction, they cut each other down.
Rule
One verb per stage. Lots of “and” in your prompt is the signal to cut.
Payoff
Split stages show you where it went wrong. You fix only that stage.
Common mistake
Thinking a longer prompt is a better one. It's not length, it's unit size.
Watch out
Slice too finely and you spend the time copying between stages. Four to six is right.
KEY CONCEPT 2
What one stage is made of
① Input spec
What it receives. Same shape as the previous stage's output.
② Instruction
The one job of this stage, plus the constraints to hold.
③ Output spec
Table, list or prose — how many items, with which columns.
A chain always snaps at the joint. Fix the format so one stage's output is literally the next one's input.
KEY CONCEPT 3
Give review to someone else
New role, new session
Hand over only the draft, in a “tough reviewer” role, and gaps get named.
Self-review in the same chat
It still holds the context it wrote in, so it goes easy. You get “looks good”.
We separate the writer from the reviewer for the same reason organizations do.
KEY CONCEPT 4
Three moves to a chain
Cutsplit one repetitive task into 4–6 stages
→
Specifyfix the input and output format of each
→
Run and reviewnote where it broke, add a review stage
Wrap that chain so it runs itself from a goal and you have an agent. Today you design that structure by hand.
THE MAP
Where this week sits
Week 9you drew the procedure
→
Week 10turn steps into a prompt chain
→
Week 11attach your own material, automate
→
Weeks 12–13build the prototype and test it
One rectangle on your flowchart becomes one stage of the chain. Keep last week's diagram open beside you.
CASE
The weekly study-group summary
“Summarize five readings and share them” — the same job as a three-stage chain.
1 · CollectPull three key sentences per reading into a table2 · WriteTake only that table, produce a one-page summary3 · ReviewA tutor role in another session names what's missing
Don't feed the original readings back in at stage 2. Pass only the previous output or the chain dissolves.
WHAT YOU MAKE TODAY
The prompt chain design
A 4+ stage chain design, full instruction texts, plus the run results
Stage table — input spec · instruction · output spec, for each stage
Review stage — a separate role, placed at the end
Break log — where it stopped, why, and what you changed
Don't stop at the design. Run it end to end once — breaks only show up when it runs.
WRAP-UP
Three sentences from today
One prompt, one task. Mix them and all of it drops to average.
A chain breaks at the format of its joints, every time.
Put review in a different role and a different session.
Next week we attach your own material to the chain — how a setup answers from your documents (RAG).
PART 3 · 11주차
노코드 자동화와 지식 연결 (RAG 기초)
내 자료를 AI에 붙이고, 반복을 기계에 넘기기
PBLⅠ · AI Problem Solving
오늘의 질문
“우리 학교 규정을 모르는 AI가 내놓은 답을 믿을 수 있습니까?”
모델은 세상을 압니다. 그러나 내 자료는 모릅니다.
핵심 개념 1
외우는 것이 아니라 찾아서 인용한다
RAG = 모델이 기억에서 답하지 않고, 내가 준 문서에서 찾아 인용하는 구성입니다.
원리
질문이 오면 자료에서 관련 대목을 먼저 찾고, 그 대목만 근거로 답을 씁니다.
최대 장점
출처가 붙습니다. 확인할 수 있는 답과 확인할 수 없는 답은 다릅니다.
흔한 오해
자료를 올려도 모델이 학습하지는 않습니다. 그때그때 찾아볼 뿐입니다.
주의
넣은 자료가 틀리면 답도 틀립니다. 출처가 붙어도 틀린 것은 틀립니다.
핵심 개념 2
자동화의 단위는 세 칸이다
① 트리거 · 언제
무엇이 일어나면 시작하는가. 정해진 시각, 도착한 메일, 제출된 신청서.
② 처리 · 무엇을
받은 것을 어떤 규칙으로 바꾸는가. 요약·분류·기록 중 하나로 적습니다.
③ 출력 · 어디로
결과가 누구에게 어떤 형태로 가는가. 받는 사람이 없으면 자동화가 아닙니다.
세 칸을 한 문장씩 채우지 못하면 아직 자동화 대상이 아닙니다. 먼저 절차를 확정하십시오.
핵심 개념 3
자료는 많은 것보다 정리된 것이 낫다
정리된 자료 5개
제목·출처·날짜가 붙고 중복이 없으면 인용 위치가 정확해집니다.
뒤섞인 자료 50개
옛 규정과 새 규정이 함께 있으면 도우미는 옛 규정을 인용합니다.
도우미의 품질은 모델이 아니라 내가 넣은 자료의 품질이 정합니다.
핵심 개념 4
먼저 손으로 세 번
손으로 3번직접 해 보며 예외를 미리 만난다
→
절차 고정트리거·처리·출력을 한 문장씩 적는다
→
기계로 이관한 번 실행하고 걸린 시간을 비교한다
손으로 해 보지 않은 절차를 자동화하면, 결과가 이상할 때 어디가 틀렸는지 알 수 없습니다.
전체 지도
이번 주가 놓인 자리
9주절차를 순서도로 그렸다
→
10주지시를 여러 단계로 연결했다
→
11주근거를 붙이고 반복을 넘긴다
→
12주그 흐름이 깨지는 곳을 찾는다
로직은 이미 있습니다. 이번 주는 그 로직에 근거와 실행을 붙이는 주간입니다.
사례
같은 질문이 매주 반복될 때
“학생회 문의함에 신입생 질문이 계속 들어온다” — 세 칸으로 옮겨 봅니다.
트리거문의 폼에 새 질문이 접수되면 시작합니다처리공지·규정 자료에서 근거를 찾아 3문장 초안을 씁니다출력담당자 채팅방으로 초안과 출처를 함께 보냅니다
마지막 발송은 사람이 누릅니다. 확인 단계를 남기는 것이 이 설계의 핵심입니다.
오늘 만드는 것
자동화 설계도 + 시범 실행 결과
트리거 / 처리 / 출력 — 각각 한 문장으로
지식 자료 5개 — 제목·출처·날짜를 정리해 도우미에 연결
질문 10개 시험 — 근거를 인용하는지, 없는 말을 지어내는지 확인
시범 실행 1회 — 손으로 할 때와 걸린 시간을 비교해 기록
자료와 자동화 대상에 타인의 이름·연락처·학번이 없는지 먼저 점검하십시오.
정리
오늘의 세 문장
RAG는 외우는 구성이 아니라 찾아 인용하는 구성이다.
자동화의 단위는 트리거·처리·출력 세 칸이다.
손으로 세 번 해 본 절차만 기계에 넘긴다.
다음 주 이 흐름을 공격합니다. 정상 경로에서만 도는 자동화는 아직 검증된 것이 아닙니다.
PART 3 · WEEK 11
No-Code Automation and Connecting Knowledge
Attaching your own material to AI, and handing repetition to a machine
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“An AI that has never seen your rules — can you trust its answer?”
The model knows the world. It does not know your material.
KEY CONCEPT 1
It looks things up, it does not recall them
RAG = the model answers not from memory but by looking things up and citing the documents you gave it.
How it works
A question arrives, the relevant passages are found first, and only those become the answer.
The real gain
You get a citation. An answer you can check is a different thing from one you cannot.
Common mistake
Uploading material does not train the model. It only reads it at the moment you ask.
Watch out
Feed it wrong material and the answer is wrong. A citation does not make it right.
KEY CONCEPT 2
The unit of automation is three boxes
① Trigger · when
What starts it. A set time, an arriving message, a submitted form.
② Process · what
What rule turns the input into something else. Summarize, sort, or record.
③ Output · where
Who receives the result, in what form. No receiver means no automation.
If you cannot fill all three boxes with one sentence each, it is not ready to automate. Settle the procedure first.
KEY CONCEPT 3
Organized beats plentiful
Five clean documents
Title, source and date on each, no duplicates — and the citations land in the right place.
Fifty messy ones
Mix last year's rules with this year's and the assistant will quote last year's.
The quality of your assistant is set by the material you feed it, not by the model.
KEY CONCEPT 4
By hand three times first
Do it by handrun it yourself and meet the exceptions
→
Fix the stepswrite trigger, process and output in one line each
→
Hand it overrun it once and compare the time it took
Automate a procedure you have never run yourself and, when the output looks wrong, you cannot tell which step broke.
THE MAP
Where this week sits
Week 9drew the procedure as a flowchart
→
Week 10chained instructions into stages
→
Week 11attach evidence, hand off repetition
→
Week 12find where that flow breaks
The logic already exists. This week you attach evidence and execution to it.
CASE
When the same question arrives every week
“First-years keep asking the student council the same things” — move it into the three boxes.
TriggerA new question lands in the enquiry formProcessFind the basis in the notices and rules, draft three sentencesOutputSend the draft with its sources to the staff chat
A person still presses send. Keeping that review step is the point of this design.
WHAT YOU MAKE TODAY
A pipeline design + one trial run
trigger / process / output — one sentence each
Five documents — title, source and date recorded, connected to the assistant
Ten test questions — does it cite the material, or invent what isn't there
One trial run — record the time and compare it against doing it by hand
First check that no one else's name, contact detail or student ID is in the material.
WRAP-UP
Three sentences from today
RAG does not memorize. It looks up and cites.
The unit of automation is trigger, process, output.
Only hand over a procedure you have run by hand three times.
Next week we attack this flow. An automation that only survives the happy path is not tested yet.
PART 3 · 12주차
예외 처리와 레드티밍
내 해법을 가장 세게 공격해 보는 시간
PBLⅠ · AI Problem Solving
오늘의 질문
“내 해법이 무너진다면, 어디서부터 무너집니까?”
내가 먼저 찾지 않으면, 발표장에서 남이 찾아 줍니다.
핵심 개념 1
정상 경로의 착시
순서도의 “예” 경로만 따라가면 모든 해법은 완벽합니다. 사고는 언제나 “아니오”에서 납니다.
정의
정상 경로 = 모든 조건이 예상대로 맞아떨어지는, 단 하나의 경로입니다.
예시
“학생증이 인식된다”가 예. 인식되지 않으면? 그 칸은 대개 비어 있습니다.
흔한 오해
예외는 드무니 나중에 봐도 된다? 쓰는 사람이 늘면 매일 일어납니다.
주의
“그럴 리 없다”는 대비가 아닙니다. 그때 무엇을 할지 적어야 대비입니다.
핵심 개념 2
예외는 세 종류다
① 실수
오타·빈칸·잘못된 파일. 막기보다 되돌릴 수 있게 만드는 편이 낫습니다.
② 악용
일부러 규칙을 비틉니다. 얻는 이득을 없애면 시도 자체가 줄어듭니다.
③ 엣지케이스
드문 조건. 동명이인, 자정 직후, 휴학생. 미리 정의해 두어야 합니다.
셋은 대비가 서로 다릅니다. 하나의 대책으로 셋을 덮으려 하면 어느 것도 막지 못합니다.
핵심 개념 3
리뷰와 레드팀은 다르다
리뷰
잘된 점을 확인하고 다듬습니다. 기분은 좋지만 약점은 그대로 남습니다.
레드팀
무너뜨리는 것이 목적입니다. 아픈 지적일수록 값이 큽니다.
아프지 않은 피드백은 아직 검증이 아닙니다.
핵심 개념 4
공격을 자산으로 바꾸는 3단계
공격받기가장 센 반박 5개를 그대로 받아 적는다
→
분류하기고칠 것·반박할 것·범위 밖을 나눈다
→
대응 쓰기지적마다 한 문장 대응 논리를 붙인다
모든 지적을 고칠 필요는 없습니다. 다만 답하지 않은 지적이 남아서는 안 됩니다.
전체 지도
이번 주가 놓인 자리
9–10주절차와 지시를 로직으로 만들었다
→
11주자료를 붙이고 자동으로 돌렸다
→
12주그 로직이 깨지는 곳을 찾는다
→
13주버틸 수 있는 만큼만 만든다
이번 주에 찾아낸 구멍이 다음 주 프로토타입의 범위를 정합니다.
사례
한 화면에서 나오는 세 종류의 예외
“도서관 빈자리를 알려 주는 서비스” — 예외마다 대비가 다릅니다.
실수퇴실 버튼을 안 누르고 나갑니다 → 30분 뒤 자동 해제악용친구 자리를 미리 잡습니다 → 1인 1좌석, 재예약 대기엣지케이스시험 기간 자정 이후 → 운영 시간 밖 규칙을 명시
대비를 적는 순간 예외는 사고가 아니라 설계의 일부가 됩니다.
오늘 만드는 것
예외 시나리오 표 + 대응서 + 윤리 점검표
언제 / 무엇이 잘못되는가 / 그때 무엇을 하는가
예외 시나리오 표 — 실수·악용·엣지케이스마다 최소 한 줄
레드팀 대응서 — 아픈 지적 5개와 각각의 처리 방식 구분
윤리 점검표 — 피해 가능 집단, 개인정보, 책임 주체
9주차 순서도의 모든 “아니오” 칸이 채워졌을 때 이 표는 완성됩니다.
정리
오늘의 세 문장
해법은 정상 경로가 아니라 “아니오” 경로에서 판정된다.
예외는 실수·악용·엣지케이스 셋이고 대비가 각각 다르다.
피해자와 책임 주체를 못 적으면 설계를 고쳐야 한다.
다음 주 드디어 만듭니다. 오늘 찾은 약점이 무엇을 먼저 만들지 정해 줍니다.
PART 3 · WEEK 12
Exception Handling and Red Teaming
The week you attack your own solution as hard as you can
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“If your solution breaks, where does it break first?”
Find it yourself, or someone finds it for you during the final pitch.
KEY CONCEPT 1
The illusion of the happy path
Follow only the “yes” arrows of a flowchart and every solution looks perfect. Things blow up on the “no”.
Definition
The happy path is the single route where every condition falls out exactly as expected.
Example
“The student card scans” is the yes. And if it doesn't? That box is usually empty.
Common mistake
Exceptions are rare, so deal with them later? With more users they happen daily.
Watch out
“That won't happen” is not a defense. Writing what you do then is a defense.
KEY CONCEPT 2
Three kinds of exception
① Mistakes
Typos, blanks, the wrong file. Better to make them reversible than to block them.
② Abuse
Someone bends the rule on purpose. Remove the gain and the attempts drop.
③ Edge cases
Rare conditions. Same names, just past midnight, students on leave. Define them up front.
Each needs a different defense. Cover all three with one measure and you stop none of them.
KEY CONCEPT 3
A review is not a red team
Review
Confirms what works and polishes it. It feels good, and the weak points survive.
Red team
Exists to bring it down. The more a criticism stings, the more it is worth.
Feedback that doesn't sting is not yet a test.
KEY CONCEPT 4
Turning an attack into an asset
Take the hitwrite down the 5 hardest objections verbatim
→
Sort themfix it, rebut it, or declare it out of scope
→
Write the answerone sentence of response per objection
You don't have to fix every criticism. But no criticism may go unanswered.
THE MAP
Where this week sits
Weeks 9–10turned the procedure into logic
→
Week 11attached material and ran it
→
Week 12find where that logic breaks
→
Week 13build only what can hold
The holes you find today decide the scope of next week's prototype.
CASE
Three exceptions on one screen
“A service that shows free library seats” — each exception needs its own defense.
MistakePeople leave without checking out → auto-release after 30 minAbuseHolding a seat for a friend → one seat per person, rebooking delayEdge casePast midnight in exam season → state the out-of-hours rule
The moment you write the defense, an exception stops being an accident and becomes part of the design.
WHAT YOU MAKE TODAY
Exception table + response doc + ethics check
when / what goes wrong / what you do about it
Exception table — at least one row for mistake, abuse and edge case
Red team response — the 5 stinging criticisms and how you handle each
Ethics check — who could be harmed, what personal data, who is accountable
The table is finished only when every “no” box in your Week 9 flowchart is filled.
WRAP-UP
Three sentences from today
A solution is judged on its “no” paths, not its happy path.
Exceptions come in three kinds — mistake, abuse, edge case — with three defenses.
If you can't name who is harmed and who is accountable, fix the design.
Next week we finally build. The weaknesses you found today decide what gets built first.
PART 4 · 13주차
프로토타입 제작
설명하지 말고 보여 주기 — 작동하는 최소 시제품
PBLⅠ · AI Problem Solving
오늘의 질문
“말로 설명하지 않고, 지금 그것을 보여 줄 수 있습니까?”
설명이 필요한 시제품은 아직 시제품이 아닙니다.
핵심 개념 1
MVP의 M은 최소다
MVP = 성공 기준 하나를 확인할 수 있는 가장 작은 것. 그 이상은 이번 주 일이 아닙니다.
정의
무엇을 확인할지 먼저 정하고, 그 확인에 필요한 기능만 남깁니다.
예시
“사람들이 실제로 신청하는가”를 보려면 신청 화면 하나면 충분합니다.
흔한 오해
최소는 대충이 아닙니다. 범위는 작되, 그 안에서는 끝까지 작동합니다.
주의
기능이 셋을 넘으면 무엇 덕분에 통과했는지 알 수 없게 됩니다.
핵심 개념 2
화면 흐름은 세 장면이면 된다
① 첫 화면
여기가 무엇을 하는 곳인지 3초 안에 알 수 있어야 합니다.
② 핵심 행동
사용자가 눌러야 할 단 하나의 버튼은 무엇입니까.
③ 결과 확인
무엇이 달라졌는지 사용자가 눈으로 확인합니다.
세 장면으로 그려지지 않으면 범위가 아직 큽니다. 도구를 켜기 전에 종이에 먼저 그리십시오.
핵심 개념 3
진짜여야 하는 것과 가짜여도 되는 것
진짜여야 하는 것
사용자가 겪는 경험. 눌렀으면 결과가 오고, 끝까지 막히지 않습니다.
가짜여도 되는 것
속의 처리. 뒤에서 사람이 직접 해도 검증에는 충분합니다.
검증되는 것은 만든 방식이 아니라 사용자가 겪은 경험입니다.
핵심 개념 4
오늘의 제작 3단계
범위 자르기확인에 필요 없는 기능을 전부 지운다
→
흐름 그리기첫 화면·핵심 행동·결과를 세 장면으로
→
만들고 시연거칠어도 끝까지 작동하는 v1을 써 본다
만드는 시간보다 지우는 시간이 중요합니다. 지운 만큼만 오늘 안에 끝납니다.
전체 지도
이번 주가 놓인 자리
11–12주흐름을 짜고 예외를 정리했다
→
13주손에 잡히는 v1을 만든다
→
14주사용자에게 시켜 근거를 모은다
→
15주문제부터 검증까지 8분에 증명한다
오늘부터 근거는 문서가 아니라 작동하는 것입니다.
사례
기능 목록을 셋으로 자르기
“자취생 식자재 나눔” — 성공 기준은 “한 주에 세 건이 성사되는가”입니다.
남긴 기능나눌 물건 올리기 · 목록 보기 · 신청 버튼지운 기능로그인, 채팅, 평점, 지도 — 확인에 필요 없습니다사람이 대신성사 알림은 운영자가 직접 보냅니다
기능 셋, 화면 셋. 이 크기라야 다음 주에 사용자 앞에 놓을 수 있습니다.
오늘 만드는 것
프로토타입 v1 + 사용 시나리오 대본
첫 화면 → 핵심 행동 → 결과 확인
프로토타입 v1 — 링크 또는 캡처, 끝까지 작동할 것
사용 시나리오 대본 — 누가 무엇을 눌러 무엇을 얻는가
막힌 지점 목록 — 자가 시연에서 멈춘 곳을 전부 기록
예쁘게 만들지 마십시오. 거칠어야 사람들이 색깔 대신 본질을 지적합니다.
정리
오늘의 세 문장
MVP의 M은 최소다. 성공 기준 하나만 확인하면 된다.
속이 가짜여도 사용자가 겪는 경험이 진짜면 검증된다.
완성도를 올릴수록 피드백의 초점이 흐려진다.
다음 주 사용자에게 직접 시켜 봅니다. “좋아 보인다”가 아니라 근거로 말해야 합니다.
PART 4 · WEEK 13
Building the Prototype
Show it, don't explain it — the smallest thing that works
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“Without explaining it, can you show it to me right now?”
A prototype that needs explaining is not a prototype yet.
KEY CONCEPT 1
The M in MVP is minimum
MVP = the smallest thing that can test one success criterion. Anything more is not this week's job.
Definition
Decide what you are testing first, then keep only the features that test it.
Example
To learn whether people actually sign up, one sign-up screen is enough.
Common mistake
Minimum is not sloppy. The scope is small, but inside it everything works.
Watch out
Past three features you can no longer tell which one made it work.
KEY CONCEPT 2
Three scenes are enough
① First screen
Three seconds to understand what this place is for.
② Core action
What is the single button the user has to press?
③ Seeing the result
The user sees, with their own eyes, what changed.
If it doesn't fit in three scenes, the scope is still too big. Draw it on paper before opening any tool.
KEY CONCEPT 3
What must be real, what may be fake
Must be real
The user's experience. They press, a result comes back, nothing dead-ends.
May be fake
The machinery behind it. A person doing it by hand is enough to validate.
What gets tested is the experience the user had, not how you built it.
KEY CONCEPT 4
Today's build, three moves
Cut the scopedelete every feature the test doesn't need
→
Draw the flowfirst screen, core action, result — three scenes
→
Build and demorough is fine, but it must work end to end
The time you spend deleting matters more than the time you spend building. You finish what you cut.
THE MAP
Where this week sits
Weeks 11–12built the flow, listed the exceptions
→
Week 13make a v1 people can touch
→
Week 14put it in users' hands, gather evidence
→
Week 15prove problem to validation in 8 minutes
From today your evidence is not a document. It is something that runs.
CASE
Cutting the feature list to three
“Sharing leftover groceries between students” — success is three completed swaps in a week.
KeptPost an item · browse the list · a request buttonDeletedLogin, chat, ratings, map — none of it tests the criterionDone by handThe match notice is sent by the organizer personally
Three features, three screens. Only at that size can it be in front of users next week.
WHAT YOU MAKE TODAY
Prototype v1 + a usage scenario script
first screen → core action → seeing the result
Prototype v1 — a link or screenshots, working end to end
Usage scenario script — who presses what, and what they get
Stuck-point list — every place your self-demo stalled
Don't make it pretty. Rough is what makes people comment on substance instead of colors.
WRAP-UP
Three sentences from today
The M in MVP is minimum. One success criterion is all you test.
The inside may be fake as long as the user's experience is real.
The more polish you add, the more the feedback loses its focus.
Next week real users try it. You will have to speak from evidence, not from “it looks good”.
PART 4 · 14주차
해결책 검증 · CER과 사용자 테스트
“좋아 보인다”가 아니라 근거로 말하기 — 다섯 명이면 시작할 수 있다
PBLⅠ · AI Problem Solving
오늘의 질문
“이 해법이 통한다는 증거가 무엇입니까?”
“제가 써 보니 괜찮던데요”는 증거가 아니라 소감입니다.
핵심 개념 1
검증은 확인이 아니라 반증 시도다
검증은 내 해법이 옳음을 확인하는 절차가 아니라, 스스로에게 틀릴 기회를 주는 절차입니다.
가설
“이 해법을 쓰면 [무엇]이 [얼마나] 달라진다.” 반증 가능해야 가설입니다.
데이터
끝까지 했는가 · 몇 초 걸렸는가 · 어디서 멈췄는가.
흔한 오해
“좋아요”는 데이터가 아니라 예의입니다. 근거로 쓰지 마십시오.
주의
지표를 테스트 뒤에 정하면 결과에 맞춰 지표가 휩니다.
핵심 개념 2
CER — 주장 · 근거 · 추론
① 주장 Claim
데이터에서 내린 한 문장의 결론. “쓸 만하다”는 주장이 아닙니다.
② 근거 Evidence
관찰된 수치. 몇 명 중 몇 명이, 몇 초에, 어느 지점에서.
③ 추론 Reasoning
그 근거가 왜 그 주장을 지지하는지 잇는 문장.
세 칸 중 하나라도 비면 감상문입니다. 근거 없는 주장도, 주장 없는 데이터도 리포트가 아닙니다.
핵심 개념 3
5명으로 알 수 있는 것과 없는 것
알 수 있는 것
어디서 막히는가, 무엇을 오해하는가. 치명적 결함은 대부분 5명 안에서 드러납니다.
알 수 없는 것
비율입니다. 5명 중 4명은 80%가 아닙니다. “대부분의 사용자가”라고 쓰지 마십시오.
5명은 결함을 찾는 도구이지, 세상을 재는 자가 아닙니다.
핵심 개념 4
사용자 테스트 3단계
과제를 준다시연 없이 “이걸로 ○○을 해 보세요”만 말한다
→
침묵한다돕지 말고 멈춘 지점과 걸린 시간을 적는다
→
끝나고 묻는다그때 왜 멈췄는지만 묻는다
힌트를 주는 순간 그 사람의 데이터는 사라집니다. 불편한 침묵이 관찰의 조건입니다.
전체 지도
이번 주가 놓인 자리
12주내 해법을 스스로 공격했다
→
13주작동하는 v1을 만들었다
→
14주남에게 시켜 보고 v2로 고친다
→
15주8분 안에 증명한다
12주는 내가 상상한 공격, 14주는 실제 사용자가 가하는 공격입니다. 후자가 언제나 더 정확합니다.
사례
조별과제 일정 조율 시트, 5명 테스트
v1을 다섯 명에게 힌트 없이 써 보게 하고 행동만 기록했습니다.
가설이 시트를 쓰면 일정 확정이 3일에서 1일로 줄어든다관찰5명 중 3명이 마감 입력 칸을 건너뜀 · 평균 4분 12초결정마감 칸을 맨 위로 이동 — v2에서 이 한 곳만 수정
나쁜 서술: “대부분의 사용자가 어려워했다.” CER: 주장 — 마감 입력에서 이탈한다 / 근거 — 5명 중 3명이 그 칸을 건너뜀 / 추론 — 칸이 화면 아래에 있었다.
오늘 만드는 것
검증 리포트(CER) + 프로토타입 v2
주장 — 근거 — 추론, 세 문장이 한 세트
가설과 지표 — 테스트 전에 확정한 반증 가능한 문장
CER 3세트 — 관찰된 수치를 붙인 결론 세 개
v2 수정 1~2곳 — 가장 많이 걸린 지점만 고친다
가설이 기각되었다면 그대로 쓰십시오. 실패도 완전한 결과입니다.
정리
오늘의 세 문장
검증은 확인이 아니라 반증 시도다.
주장마다 숫자와 관찰을 붙여라. 없으면 감상문이다.
5명은 결함을 찾는 도구다. 비율을 말하지 마라.
다음 주 한 학기를 8분에 증명합니다. 한계를 스스로 밝히는 팀이 가장 높은 점수를 받습니다.
PART 4 · WEEK 14
Validating the Solution · CER and User Testing
Speaking from evidence, not from “it looks good” — five people is enough to start
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“What is your evidence that this solution works?”
“I tried it and it felt fine” is an impression, not evidence.
KEY CONCEPT 1
Validation is an attempt to disprove
Validation is not the step where you confirm you were right. It is where you give yourself a chance to be wrong.
Hypothesis
“Using this changes [what] by [how much].” If it can't be disproved, it isn't one.
Data
Did they finish · how many seconds · where exactly did they stop.
Common mistake
“I like it” is politeness, not data. Never use it as evidence.
Watch out
Pick metrics after the test and they bend to fit the result.
KEY CONCEPT 2
CER — claim, evidence, reasoning
① Claim
One sentence you concluded from the data. “It works well” is not a claim.
② Evidence
What you observed. How many of how many, in how many seconds, where.
③ Reasoning
The sentence that links why this evidence supports that claim.
Leave any of the three empty and it is a personal impression. A claim without evidence and data without a claim are equally useless.
KEY CONCEPT 3
What five users can and cannot tell you
They can tell you
Where people get stuck and what they misread. Most fatal flaws show up within five.
They cannot tell you
Proportions. Four of five is not 80%. Never write “most users” after testing five.
Five people are a tool for finding flaws, not a ruler for measuring the world.
KEY CONCEPT 4
Running a test, three moves
Give a taskno demo — just “use this to do X”
→
Stay silentdon't help; note where they stall and for how long
→
Ask afterwardsonly one question: why did you stop there?
The moment you give a hint, that person's data is gone. Awkward silence is the condition for observing anything.
THE MAP
Where this week sits
Week 12you attacked your own solution
→
Week 13you built a v1 that runs
→
Week 14others use it; you revise to v2
→
Week 15you prove it in eight minutes
Week 12 was the attack you imagined. Week 14 is the attack real users actually make. The second one is always more accurate.
CASE
A group-project scheduling sheet, tested on five
Five people used v1 with no hints. Only behaviour was recorded.
HypothesisWith this sheet, settling a date drops from 3 days to 1Observed3 of 5 skipped the deadline field · 4 min 12 s on averageDecisionMove the deadline field to the top — the only v2 fix
Badly written: “Most users found it hard.” As CER: claim — people drop out at the deadline field / evidence — 3 of 5 skipped it / reasoning — the field sat below the fold.
WHAT YOU MAKE TODAY
Validation report (CER) + prototype v2
claim — evidence — reasoning: three sentences, one set
Hypothesis and metrics — falsifiable, fixed before the test
Three CER sets — three conclusions, each with observed numbers
One or two v2 fixes — only where people got stuck most
If the hypothesis was rejected, write that. A rejected hypothesis is a complete result.
WRAP-UP
Three sentences from today
Validation is not confirmation. It is an attempt to disprove.
Attach numbers and observations to every claim, or it's an opinion.
Five people find flaws. They do not give you percentages.
Next week you prove a whole semester in eight minutes. The teams that name their own limits score highest.
PART 4 · 15주차
최종 캡스톤 · Solution Pitch
문제 – 해법 – 로직 – 검증을 8분에 증명하기
PBLⅠ · AI Problem Solving
오늘의 질문
“당신의 8분이 끝났을 때, 청중은 무엇을 믿게 됩니까?”
발표는 한 학기의 요약이 아니라 하나의 주장에 대한 증명입니다.
핵심 개념 1
피치는 보고가 아니라 증명이다
한 일을 나열하는 자리가 아닙니다. 문제 – 해법 – 로직 – 검증이 한 줄로 이어져야 합니다.
시작
통계가 아니라 구체적인 장면 하나로 엽니다. 숫자는 그다음입니다.
선정 근거
버린 안을 먼저 보이면 고른 안이 설득됩니다.
흔한 실수
주차별로 한 일을 시간순 나열합니다. 그것은 일지입니다.
주의
슬라이드를 읽지 마십시오. 청중은 이미 읽었습니다.
핵심 개념 2
8분이 증명해야 할 세 가지
① 문제는 실재한다
누가 언제 어떤 손해를 보는지 한 장면으로 보입니다.
② 해법은 작동한다
설명하지 말고 그 자리에서 돌립니다. 실패해도 그대로 보입니다.
③ 결론은 검증됐다
가설 지지 여부를 먼저 말하고 근거 데이터를 붙입니다.
셋 중 하나가 비면 나머지 둘도 무너집니다. 8분은 이 세 가지에만 쓰십시오.
핵심 개념 3
한계는 감출수록 커진다
먼저 밝힌 한계
“20명 이하 모임에서만 검증했습니다.” 신뢰가 올라갑니다.
감춘 한계
질의 4분에 반드시 드러납니다. 그때는 설명이 아니라 변명이 됩니다.
자기 해법의 한계를 아는 사람만이 그 해법을 책임질 수 있습니다.
핵심 개념 4
리허설 3단계
소리 내어속으로 읽으면 막히는 문장이 보이지 않는다
→
시계를 켜고8분을 넘기면 잘라낼 것을 먼저 정한다
→
남 앞에서모르는 한 사람에게 시연까지 통째로
리허설 없는 발표는 발표가 아니라 즉흥입니다. 시연은 반드시 두 번 이상 돌려 보십시오.
전체 지도
한 학기가 지나온 길
1–4주문제를 정의했다
→
5–8주대안을 넓히고 하나를 골랐다
→
9–13주로직으로 옮기고 만들었다
→
14–15주검증하고 증명한다
오늘 발표하는 것은 완성품이 아니라 한 학기의 판단 과정입니다. 판단이 보이면 결과는 작아도 됩니다.
사례
8분을 어떻게 쓰는가
조별과제 일정 조율 시트 팀의 실제 배분입니다.
1분 · 문제사흘간 메시지 60개를 주고받고도 날짜가 안 잡힌 밤4분 · 해법과 시연버린 안 두 개를 먼저 보이고, 시트를 실제로 돌린다3분 · 검증과 한계5명 중 4명이 1일 내 확정 · 6명 이상은 미검증
시간이 모자라면 한계가 아니라 배경 설명을 자르십시오. 한계 항목이 평가에서 가장 큽니다.
오늘 만드는 것
최종 제출물 네 가지
문제 → 원인 → 대안과 선정 → 로직 → 검증 → 한계, 끊기지 않는 한 줄
해결 로직 명세서 + 프로토타입 — 순서도와 예외 처리, 작동하는 v2
검증 리포트 — 가설 · 지표 · CER 3세트 · 한계
동료 검토서 — 반영한 것과 반영하지 않은 것, 그 이유
부록에 실패한 시도를 남기십시오. 평가 비중 40%입니다.
정리
마지막 세 문장
발표는 요약이 아니라 증명이다. 세 가지만 증명하라.
말하지 말고 돌려서 보여라. 실패한 시연도 데이터다.
한계를 먼저 말하는 사람이 가장 신뢰받는다.
한 학기 동안 배운 것은 도구가 아니라 순서입니다. 불평을 정의된 문제로 바꾸고, 설계한 로직으로 옮기고, 사람에게 시켜 확인하는 일 — 이 습관은 어떤 전공, 어떤 자리에서도 그대로 작동합니다.
PART 4 · WEEK 15
Final Capstone · Solution Pitch
Proving problem – solution – logic – validation in 8 minutes
PBLⅠ · AI Problem Solving
TODAY'S QUESTION
“When your eight minutes end, what does the room believe?”
A pitch is not a summary of your semester. It is proof of one claim.
KEY CONCEPT 1
A pitch proves; it does not report
This is not the place to list what you did. Problem – solution – logic – validation must read as one line.
Opening
Start with one concrete scene, not a statistic. Numbers come after.
Rationale
Show what you dropped first, and the option you kept becomes convincing.
Common mistake
Listing what you did week by week. That is a logbook, not a pitch.
Watch out
Don't read your slides aloud. The room has already read them.
KEY CONCEPT 2
Three things the eight minutes must prove
① The problem is real
One scene showing who loses what, and when.
② The solution runs
Don't describe it, run it live. If it breaks, show that too.
③ The result is tested
Say whether the hypothesis held, then attach the data.
Leave one of the three empty and the other two collapse with it. Spend the eight minutes on nothing else.
KEY CONCEPT 3
Hidden limits only grow
Named up front
“We only tested it on groups of 20 or fewer.” Trust goes up, not down.
Hidden
It surfaces in the four minutes of questions — and then it sounds like an excuse.
Only someone who knows where a solution fails can take responsibility for it.
KEY CONCEPT 4
Rehearsal, three passes
Out loudread it silently and you never hear the broken sentence
→
On the clockover eight minutes? decide what to cut first
→
In front of someoneone stranger, the whole thing, demo included
A talk without rehearsal is improvisation. Run the live demo at least twice before you stand up.
THE MAP
The road this semester took
Weeks 1–4you defined the problem
→
Weeks 5–8you widened, then chose one option
→
Weeks 9–13you turned it into logic and built it
→
Weeks 14–15you tested it and now prove it
What you present today is not a finished product. It is a semester of judgement. If the judgement shows, the result can be small.
CASE
How one team spent the eight minutes
The group-project scheduling sheet team, minute by minute.
1 min · ProblemThree days, 60 messages, and still no date agreed4 min · Solution + demoTwo dropped options first, then the sheet running live3 min · Results + limits4 of 5 settled within a day · untested above 6 people
Running short? Cut the background, never the limits. That section carries the most weight in the grade.
WHAT YOU MAKE TODAY
Four final submissions
problem → cause → alternatives → logic → validation → limits, one unbroken line
Logic spec + prototype — flowchart, exception handling, a working v2
Peer review document — what you acted on, what you didn't, and why
Leave the failed attempts in the appendix. This carries 40% of the grade.
WRAP-UP
Three last sentences
A pitch is proof, not a summary. Prove three things only.
Don't describe it — run it. A demo that fails is still data.
The person who names the limits first is the one people trust.
What you learned this semester is not a tool but an order of operations: turn a complaint into a defined problem, move that problem into a logic you designed, then hand it to real people and check. That habit works in any major and any job you walk into.