GS · 52g · RALPHTHONPRE-COURSE · 2026.09.18

BUILD · CHECK · LEARN · LOOP

현장에서 일하는
진짜 실무자를 위한 AI

우리 현장의 우리 조직의 문제를 꺼내고, AI에게 맡기고, 직접 확인하고, 다시 고칩니다.

GS 개발자 리그 사전교육정구봉 · Team Attention

오늘의 약속01–03 MIN

TWO HOURS · ONE WORKING LOOP

오늘 끝나면, AI에게 일을 맡기는 문장이 달라집니다.

1

문제를 말로 꺼냅니다

정리된 기획서부터 쓰지 않습니다. 최근 현장의 실제 장면을 voice로 길게 설명합니다.

2

작게 만들어 봅니다

팀원마다 다른 가설로 단일 HTML 프로토타입을 만들고 직접 눌러봅니다.

3

검증하며 계속 맡깁니다

Goal, 경계, 완료조건을 주고 결과를 확인한 뒤 다음 실행을 결정합니다.

두 시간의 지도03–04 MIN

행사를 이해하고, 한 번 만들어 보고, 내 문제로 돌아옵니다.

20분Ralphthon과 제출·심사 흐름을 이해합니다.

60분voice, 문제 정의, Goal, Ralph loop를 함께 실습합니다.

10분쉬고, 만든 결과를 서로 확인합니다.

20분 + 10분내 현장 문제에 적용하고 Q&A로 막힌 지점을 풉니다.

오늘의 실습 폴더는 그대로 가져가서 Day 1에 이어 씁니다. 강의가 끝나도 작업 맥락이 남아야 합니다.

GS · 52g · RALPHTHON04–07 MIN

WHAT IS RALPHTHON

사람이 방향을 정하고,
AI가 오래 실행하고,
팀이 결과와 증거를 확인합니다. 잘 만든 화면만 보는 해커톤이 아닙니다. 어떤 문제를 골랐고, 무엇을 맡겼고, 어디까지 확인했는지가 함께 남습니다.

행사 전체 흐름07–11 MIN

Day 1, 첫 Ralph를 시작합니다.
Day 2 오전에는 직접 마무리합니다.

DAY 1 · 09.21

13:00

개회식13:30 사인회·공간 투어

14:10

팀어텐션 세션개발자 리그 · 아이디어와 Ralphthon 안내

15:00

Vercel 세션15:00~16:00 햄버거 자유 이용

15:30

스펙 작성15:30~17:30

17:30

첫 Ralph 시작손대면 가재탈 룰 시작 · 코치 지원

18:00

석식18:00~19:00

19:00

Codex Ambassador 이정민 세션

19:30

신건호 · 박준영 · 김승진 패널토크모더레이터 신건호 · 패널 박준영·김승진

20:00

네트워킹 · 1:1 Codex 팁

21:00

야식·클로징

DAY 2 · 09.22

09:00

체크인·아침 간식

10:00

가재탈 룰 해제10:00~12:00 핸즈온·제출 정리

12:00

제출 잠금·중식

13:00

현장 AI 패널

14:00

결선 4팀 발표14:00~14:30 아이스크림·파이 자유 이용

15:00

투표·심사15:00~15:30

15:30

시상15:30~16:00

16:00

폐회식

제출과 심사11–15 MIN

결과물과 작업 기록을
함께 제출합니다.

제출할 것 여섯 가지

데모 링크
데모 영상
GitHub 저장소
발표자료
세션 로그
/goal 프롬프트 파일

1차 심사에서 보는 네 가지

에이전트 활용 기록
/goal 기본 구성
결과 중심 위임 설계
완료와 검증 설계

AI가 전 팀을 채점하고 심사위원이 상위 10팀을 검증합니다. 검증된 상위 10팀은 팀당 OpenAI API Credit USD 1,000을 받습니다. 결선은 4팀이며 발표 5분, 질의응답 3분입니다. 최종 점수는 검증된 1차 50 + 발표 25 + 참가자 투표 25이며, 발표 운영은 현장 상황에 따라 조정될 수 있습니다.

PART 01 · 우리 현장의 문제15–16 MIN

어느 계열사에서 오셨나요?
손들고, 짧게 소개해주세요.

자이S&DGS EPSGS ITMGS건설GS네트웍스GS동해전력GS리테일GS차지비GS칼텍스GS파워GS풍력발전

소속 계열사·이름·맡고 있는 일

같은 AI를 쓰더라도, 각자 풀고 싶은 문제는 다를 겁니다.

지난주 · SK AI Hackathon16–17 MIN

작은 업무 문제부터,
스핀오프를 고민할 큰 문제까지.

지난주 SK AI Hackathon을 운영하면서 봤습니다.
연구부터 사내 에이전트까지, 문제의 범위가 다양했습니다.

01

작은 업무 문제

내가 매일 부딪히는 불편에서 시작합니다.

02

연구 · 사내 에이전트

조직 안에서 AI를 쓸 자리를 찾습니다.

03

스핀오프 가능성

새로운 사업으로 이어질 문제도 정의합니다.

무엇이 바뀌었나17–19 MIN

AI가 가장 먼저 낮춘 것은
작게 시도하고 버리는 비용입니다.

기존 방식

선택만들기 전에 오래 비교합니다.

첫 구현사람과 예산을 먼저 확보합니다.

실패이미 쓴 비용 때문에 방향을 바꾸기 어렵습니다.

학습완성한 뒤에야 실제 반응을 봅니다.

→

AI와 일하는 방식

선택질문 하나를 골라 바로 시험합니다.

첫 구현단일 HTML처럼 가장 작은 형태로 만듭니다.

실패작게 버리고 다른 가설로 다시 만듭니다.

학습직접 써본 관찰로 다음 방향을 정합니다.

현장 문제 예시19–21 MIN

이 정도 크기면 오늘 바로 시험할 수 있습니다.

운영

교대 인수인계 점검기

빠진 항목을 표시하고 다음 담당자가 확인할 목록을 만듭니다.

영업

미팅 후속 조치 정리기

메모에서 약속, 담당자, 날짜를 뽑아 확인 가능한 목록으로 바꿉니다.

물류

예외 상황 분류판

지연·파손·주소 오류를 입력하면 우선 확인할 절차를 보여줍니다.

안전

현장 점검 누락 확인기

점검표의 빈 항목과 사진이 필요한 항목을 한 화면에서 확인합니다.

지원

반복 문의 초안 도우미

상황을 고르면 필요한 확인 질문과 답변 초안을 준비합니다.

내 업무

이번 주에 두 번 설명한 일

이미 반복해서 설명한 일은 맥락도 알고 검증도 할 수 있어 좋은 출발점입니다.

이번 해커톤 · 참가자 지원21–22 MIN

오늘부터 해커톤이 끝나는 날까지,
GPT-6 Astra를 한도 없이.

9월 18일 사전교육부터 9월 22일 행사 종료까지 사용할 수 있습니다.

먼저, 앱을 설치해주세요.

구글에서 ChatGPT 다운로드 검색

chatgpt.com/ko-KR/download/ ↗

문제 선택22–24 MIN

세 질문에 “예”라고 답할 수 있는 문제를 고릅니다.

1

내가 실제로 겪었나?

어제나 이번 주의 구체적인 장면을 말할 수 있어야 합니다.

2

직접 확인할 수 있나?

누가 대신 평가해주지 않아도 결과를 눌러 보고 판단할 수 있어야 합니다.

3

작은 화면으로 시험할 수 있나?

로그인·DB·사내 연동 없이도 핵심 흐름을 흉내 낼 수 있어야 합니다.

보안 데이터, 참가자 정보, 사내 비밀은 실습 입력에 넣지 않습니다. 상황을 일반화하고 가상 데이터로 시험합니다.

일을 맡기는 관점24–26 MIN

AI 시대의 병목은 구현 지식보다
일을 끝난 상태로 설명하는 능력에 가깝습니다.

방법만 지시

“이 표를 예쁘게 만들고 버튼도 넣어줘.”

요청한 요소는 생기지만, 누가 언제 무엇을 판단해야 하는지는 남습니다.

결과를 설명

“다음 근무자가 2분 안에 누락을 찾고 담당자를 정하게 해줘.”

AI는 방법을 제안할 수 있고, 사람은 실제로 2분 안에 찾는지 확인할 수 있습니다.

좋은 위임은 방법을 전혀 말하지 않는 것이 아닙니다. 결과, 경계, 확인 방법이 먼저 보여야 합니다.

VOICE FIRST26–28 MIN

정리해서 말하려고 멈추지 마세요.
AI에게 최대한 voice로 밀어 넣어보세요. 상황, 사람, 예외, 답답했던 순간, 이미 해본 방법을 한 번에 말합니다. AI가 먼저 구조를 잡게 합니다.

5분 voice dump28–31 MIN

아래 순서로 말하면 충분합니다.

1. 언제, 어디에서 벌어진 일인지 2. 누가 무엇을 하다가 막혔는지 3. 지금은 어떻게 버티고 있는지 4. 예외가 생기면 무엇이 깨지는지 5. 결과가 좋아졌다고 볼 증거가 무엇인지 6. 절대 건드리면 안 되는 경계가 무엇인지

말할 때 지키는 규칙

멋진 해법부터 제안하지 않습니다.
실제 사람 이름과 민감정보는 빼고 역할로 말합니다.
중간에 반복해도 괜찮습니다.
모르는 부분은 “모른다”고 남깁니다.
AI가 질문하기 전에는 구현하지 못하게 합니다.

Voice → Brief31–33 MIN

AI에게 요약을 맡기되, 사실과 추정을 갈라놓습니다.

방금 말한 내용을 아래 다섯 칸으로 정리해줘. • 실제로 관찰한 장면 • 내가 문제라고 해석한 부분 • 아직 확인하지 못한 가정 • 첫 프로토타입으로 확인할 질문 하나 • 이번 실습에서 제외할 범위 내 말에 없는 사실을 보태지 말고, 모호한 부분은 질문해줘. 아직 구현하지 마.

좋은 브리프는 길이가 짧아서 좋은 것이 아닙니다. 다음 질문과 첫 실험이 분명해서 좋습니다.

팀으로 일하는 순서33–35 MIN

팀 회의 전에, 각자 AI와 문제를 발전시켜 옵니다.

각자 말한다같은 현장을 봐도 놓친 장면과 중요도가 다릅니다.

각자 만든다작은 프로토타입으로 자기 가설을 눈에 보이게 합니다.

서로 써본다말의 크기보다 실제 사용 경험으로 비교합니다.

합친다살릴 흐름과 버릴 가정을 정하고 하나의 스펙으로 묶습니다.

빈손으로 모이면 목소리가 큰 사람의 문장부터 붙잡기 쉽습니다. 작은 결과물을 들고 모이면 비교할 수 있습니다.

Exploration35–37 MIN

초반에는 완성품 하나에 매달리지 않습니다.
서로 다른 가설을 빠르게 여러 개 만듭니다.

A

입력부터 줄인다

현장 사용자가 최소한의 정보만 적어도 다음 행동을 알 수 있게 합니다.

B

누락부터 찾는다

이미 작성한 기록에서 빠진 항목과 위험한 빈칸을 먼저 보여줍니다.

C

인수인계부터 만든다

내용을 다음 담당자가 바로 읽을 수 있는 전달 카드로 바꿉니다.

세 화면을 각각 20분에 만들면, 한 화면을 한 시간 동안 상상하는 것보다 더 많은 판단 근거가 생깁니다.

가장 작은 실행 형태37–39 MIN

첫 프로토타입은 단일 HTML이면 충분합니다.

좋은 이유

브라우저에서 바로 엽니다.
링크나 파일로 바로 공유합니다.
화면과 동작을 한 번에 봅니다.
버리거나 다시 만들기 쉽습니다.
서버·계정·DB 없이 핵심 흐름을 시험합니다.

첫 실험에서 미룹니다

사내 시스템 연결
실제 운영 데이터
권한과 계정 체계
완벽한 디자인 시스템
배포 자동화와 운영 대시보드

연결이 꼭 있어야만 시험 가능한 문제라면 가상 데이터와 클릭 흐름으로 판단 질문부터 확인합니다.

PART 02 · RALPH LOOP

AI에게 오래 맡긴다는 것은
오래 기다리는 일이 아닙니다.
검증하고 고치게 만드는 일입니다.

원래 하던 일40–42 MIN

좋은 실무는 원래 한 번에 끝나지 않았습니다.

목표무엇을 바꿀지 정합니다.

실행작은 범위를 실제로 만듭니다.

확인결과와 기대를 대조합니다.

피드백유지·수정·중단을 정합니다.

마케팅도, 개발도, 운영도 결과를 보고 다음 행동을 바꿉니다. AI에게도 이 구조를 줍니다.

Ralph loop42–44 MIN

처음 공개된 형태는 놀랄 만큼 단순했습니다.

구조를 읽는 예시 · 실행하지 않습니다2025.07.14

while :; do cat PROMPT.md | coding-agent ; done

반복문보다 중요한 것

매 실행에서 드러난 실패를 명세·계획·검증에 반영하고 다음 실행에 남깁니다.

오늘의 표현

합의한 검증을 통과할 때까지 실행하고 고치되, 사람의 판단이 필요한 경계에서는 멈춥니다.

참고: Geoffrey Huntley, Ralph Wiggum technique · https://ghuntley.com/ralph/

붙어서 지시하기 vs 맡기기44–46 MIN

사람이 매 단계마다 다음 명령을 만들면,
AI가 빨라도 사람이 병목으로 남습니다.

대화 한 턴씩 이어가기

1화면을 만들어줘.

2버튼을 추가해줘.

3오류를 고쳐줘.

4다음 기능을 만들어줘.

→

결과와 검증을 맡기기

목표누가 무엇을 할 수 있어야 하는지

경계이번 실행에서 하지 않을 일

완료직접 확인할 동작과 실패 처리

반복실패하면 고치고 다시 검사

THREE CONTRACTS46–48 MIN

AI가 계속 일하려면
세 가지가 먼저 합의돼야 합니다.

1

Goal

누가 무엇을 할 수 있게 되는가?

2

Boundary

어디까지 맡기고, 어디에서 멈추는가?

3

Done

무엇을 직접 확인하면 끝났다고 말할 수 있는가?

Goal48–50 MIN

Goal은 만들 기능보다
끝난 뒤 가능해질 일을 적습니다.

약한 Goal

“인수인계 웹앱을 만들어줘.”

무엇을 해결하고 누구에게 어떤 변화가 생기는지 확인하기 어렵습니다.

확인 가능한 Goal

“다음 근무자가 2분 안에 누락된 항목과 담당자를 찾게 해줘.”

사용자, 상황, 원하는 변화가 보입니다. 실제로 시간을 재며 확인할 수 있습니다.

사진 찍을 문장: “누가, 어떤 상황에서, 무엇을 할 수 있게 되는가?”

Boundary50–52 MIN

Boundary는 AI가 멈춰서
사람의 판단을 돌려줘야 하는 자리입니다.

데이터

실제 운영 데이터와 개인정보를 사용하지 않습니다. 가상 데이터로 흐름을 시험합니다.

권한

외부 배포, 결제, 계정 생성, 메시지 발송은 사람이 승인하기 전에는 실행하지 않습니다.

범위

이번에는 입력, 누락 확인, 전달 카드까지만 만듭니다. 사내 시스템 연결은 미룹니다.

경계가 선명하면 AI는 그 안에서 더 과감하게 움직일 수 있습니다.

Done52–54 MIN

완료조건에는
누가 그대로 따라 해도 확인되는 장면을 씁니다.

정상 흐름	인수인계 2건을 입력하면 각각 카드로 나타나고, 새로고침 뒤에도 남습니다.
빈 상태	기록이 없으면 무엇부터 입력해야 하는지 한 문장으로 안내합니다.
실패 상황	필수 항목이 비어 있으면 저장하지 않고, 입력한 내용은 지우지 않습니다.
기존 동작	누락 표시를 고친 뒤에도 정상 입력과 새로고침 동작이 그대로 유지됩니다.

GOAL · BOUNDARY · DONE54–57 MIN

이제 세 가지를 한 번에 묶습니다.

Goal 다음 근무자가 2분 안에 누락된 인수인계 항목과 담당자를 찾게 해줘. Boundary 단일 HTML 파일로 만들어. 가상 데이터만 쓰고 로그인·DB·외부 배포는 하지 마. 기존 파일을 지우거나 다른 폴더를 바꾸지 마. Done 2건 저장, 새로고침 유지, 필수값 누락 차단, 빈 상태 안내를 직접 확인해. 실패하면 수정하고 다시 확인한 뒤 실행 경로와 검증 결과를 남겨줘.

공통 실습 준비57–59 MIN

현장 인수인계 누락 점검기를
세 번 다르게 맡겨봅니다.

폴더

gs-ai-practice/
  01-handoff-checker/

Codex에서 이 폴더를 열고 새 작업을 시작합니다.

가상 상황

다음 근무자에게 설비 이상, 조치 내용, 남은 확인, 담당자를 전달합니다. 빠진 항목이 있으면 눈에 띄게 표시해야 합니다.

실제 현장 내용과 사람 이름은 입력하지 않습니다.

실습 A59–61 MIN

먼저 Goal만 줍니다.

현장 인수인계 누락 점검기를 만들어줘. 다음 근무자가 전달 내용을 읽고 빠진 항목을 쉽게 찾을 수 있어야 해.

보기

AI가 무엇을 임의로 정했나요?

눌러보기

실제로 입력하고 저장할 수 있나요?

메모

가장 마음에 든 점과 가장 불안한 점을 하나씩 적습니다.

실습 B61–63 MIN

다음 작업에서는 Boundary를 더합니다.

같은 Goal로 새 버전을 만들어줘. 단일 HTML 파일 하나로 실행해. 가상 데이터만 사용하고 로그인·DB·외부 API·배포는 하지 마. 기존 A 버전은 보존하고 새 파일로 만들어. 필드는 설비, 이상 징후, 조치, 남은 확인, 다음 담당자로 제한해.

질문: 범위를 줄이니 무엇이 더 선명해졌나요? AI의 선택권이 필요한 곳은 어디였나요?

실습 C63–65 MIN

마지막으로 Done을 줍니다.

B 버전을 아래 완료조건까지 충족하도록 개선해. • 정상 기록 2건을 저장하고 각각 카드로 확인한다. • 새로고침 뒤에도 두 기록이 유지된다. • 설비 또는 남은 확인이 비면 저장하지 않고 이유를 보여준다. • 실패해도 입력한 내용은 남는다. • 기록이 없으면 첫 입력 방법을 안내한다. 직접 실행해 확인하고, 실패하면 수정한 뒤 같은 조건을 다시 확인해. 검증 결과와 내가 열 파일 경로를 남기고 멈춰.

COMMON PRACTICE65–80 MIN

Goal → Boundary → Done
세 번의 차이를 직접 확인합니다.

15:00

5분

A를 만들고 AI가 채운 빈칸을 찾습니다.

5분

B와 C를 이어서 맡기고 결과를 비교합니다.

5분

직접 눌러보고 가장 큰 차이를 한 문장으로 남깁니다.

BREAK80–90 MIN

10분 쉬겠습니다.
돌아오면 내 문제로 첫 Goal을 씁니다.

10:00

PART 03 · FROM PROTOTYPE TO SPEC

한 번 만든 결과를 믿지 않습니다.
직접 써본 관찰로 다음 작업을 정합니다.

Dogfooding91–92 MIN

AI의 완료 보고를 읽기 전에
내가 먼저 써봅니다.

약속한 동작

입력, 저장, 누락 표시, 새로고침이 완료조건대로 작동하나요?

내 일의 변화

다음 담당자가 더 빨리 이해하고 행동을 정할 수 있나요?

다음 선택

수정할까요, 다른 가설을 만들까요, 더 써볼까요, 멈출까요?

화면이 예쁘게 열리는 것과 현장의 일이 나아지는 것은 서로 다른 확인입니다.

관찰 기록92–93 MIN

“별로예요” 대신, 무엇을 하다 어디서 막혔는지 남깁니다.

관찰	누락 표시를 찾는 데 40초가 걸렸고, 빨간 표시가 원인인지 결과인지 이해하기 어려웠다.
해석	강조 색보다 항목의 상태 문장이 먼저 보여야 할 수 있다.
다음 질문	“무엇이 비었는지”를 문장으로 보여주면 20초 안에 찾을 수 있을까?
아직 모름	다른 직무의 사용자가 같은 표현을 이해하는지는 확인하지 않았다.

Spec93–95 MIN

스펙에는
사용자 흐름과 상태, 완료조건을 함께 씁니다.

시작 상황다음 근무자가 교대 직전에 전달 기록을 엽니다.

행동기록을 읽고 누락 항목과 남은 확인을 누릅니다.

제품 반응빈 항목, 담당자, 우선순위를 한 화면에 표시합니다.

확인 결과2분 안에 다음 행동 하나를 선택합니다.

Day 1 15:30~17:30에는 이 흐름을 팀의 문제로 구체화합니다.

States95–96 MIN

실무에서 사고가 나는 곳은
대부분 정상 흐름의 바깥입니다.

정상

필수 항목이 모두 있고 다음 담당자가 확인합니다.

빈 상태

아직 기록이 없을 때 첫 행동을 안내합니다.

실패

저장이나 처리에 실패하면 성공처럼 보이지 않습니다.

재개

중간에 멈춰도 지금 상태와 다음 행동을 찾을 수 있습니다.

완료조건에 상태를 적으면 AI가 테스트할 수 있고, 팀도 같은 결과를 다시 확인할 수 있습니다.

Plan96–98 MIN

화면·데이터·테스트로 나누지 말고,
사용자가 끝까지 해볼 수 있는 일로 나눕니다.

M1

기록을 남긴다

입력 → 저장 → 다시 열기. 실패 시 입력 보존까지 확인합니다.

M2

누락을 찾는다

기존 기록을 읽고 빠진 항목을 표시합니다. M1도 다시 확인합니다.

M3

다음 행동을 넘긴다

담당자와 남은 확인을 저장하고 전체 인수인계 흐름을 확인합니다.

FIRST RALPH · DAY 1 17:3098–101 MIN

첫 loop에는 제품 전체보다
검증 가능한 한 단위를 맡깁니다.

앞에서 합의한 스펙과 현재 코드를 읽어줘. 이번 실행 범위는 {{M1 또는 선택한 한 단위}}야. 이 단위의 Goal, Boundary, Done을 먼저 확인하고 실행해. 현재 상태 확인 → 구현 → 검증 → 실패 수정 → 재검증을 이어가. Done을 충족하면 실제 증거와 남은 작업을 보고하고 멈춰. 범위 변경, 기존 자료 삭제, 외부 서비스나 새 권한이 필요하면 먼저 물어봐. 확인하지 못한 항목은 완료라고 쓰지 마.

Change & Regression101–103 MIN

요구가 바뀌는 것은 정상입니다.
바뀐 기록과 기존 동작의 재확인이 남아야 합니다.

변경 이유직접 써보니 누락보다 담당자 혼선이 더 컸습니다.

스펙 수정담당자 지정과 확인 상태를 M2에 추가합니다.

영향 확인입력·저장·새로고침 흐름이 깨지지 않았는지 다시 봅니다.

로그무엇을 왜 바꿨는지 다음 실행이 읽을 수 있게 남깁니다.

정상적인 목표 갱신은 허용됩니다. 변경 과정이 로그에 남아야 합니다. 제출 기록 조작은 수상 취소 사유가 될 수 있습니다.

Loop decision103–104 MIN

매 loop 끝에는 다음 기능보다
다음 판단이 먼저입니다.

계속

방향은 맞고 근거가 더 필요합니다.

같은 흐름을 다른 상황에서 더 써보고 관찰을 모읍니다.

수정

문제는 맞지만 해법이 어긋났습니다.

스펙이나 UI를 바꾸고 같은 질문을 다시 확인합니다.

중단

실제 문제가 아니거나 비용이 큽니다.

더 만들지 않고 다른 가설이나 다른 문제로 이동합니다.

중단도 좋은 결과입니다. 작은 프로토타입에서 일찍 중단하면 팀의 시간을 지킵니다.

팀으로 합치기104–107 MIN

코드를 합치기 전에
각 프로토타입에서 살릴 판단을 합칩니다.

1

서로 써본다

만든 사람이 설명하기 전에 다른 팀원이 직접 눌러봅니다.

2

가설을 비교한다

각 화면이 어떤 문제 해석을 담았는지 한 문장으로 적습니다.

3

살릴 흐름을 고른다

좋아 보이는 기능보다 현장 관찰에 가장 잘 답하는 흐름을 고릅니다.

4

새 스펙으로 묶는다

Goal, Boundary, Done을 하나로 합치고 첫 Ralph 단위를 정합니다.

TAKEAWAY107–109 MIN

Day 1에 가져올 것은
완성된 아이디어가 아닙니다.

1

현장의 장면

최근 실제로 막혔던 순간을 voice로 설명합니다.

2

작은 프로토타입

서로 다른 가설을 단일 HTML로 여러 개 만듭니다.

3

검증 기록

직접 써본 관찰과 아직 모르는 것을 나눠 적습니다.

4

첫 Goal

한 단위의 결과, 경계, 완료조건을 적습니다.

Q&A109–119 MIN

“AI를 어떻게 써야 하나요?”보다
“이 일을 맡기다 여기서 막혔어요.”
라고 질문해주세요. 문제 선택, voice 입력, Goal, Boundary, Done, 검증, 팀 합치기 중 어디에서 막혔는지 말해주면 바로 같이 풀어보겠습니다.

SEE YOU ON DAY 1119–120 MIN

우리 현장의 문제를 들고 오세요.
14:10, 첫 팀 스펙부터 시작합니다.

각자 AI와 먼저 대화하고, 작은 프로토타입을 하나 이상 만들어 오면 좋습니다.

구성·시각 참고: kakao-ralphthon-edu.echodelta.kr · GS 맥락에 맞게 재작성