프로그래밍은 몰라도
AI는 사용합니다만

오늘은 코딩보다 AI와 일하는 법을 익힙니다

나흘 동안 작은 서비스 하나를 끝까지 만듭니다

오늘은 그 첫 단계입니다. 나흘 뒤에는 기획부터 시연까지 한 번 완주하게 됩니다.

먼저 4일 동안 만들 범위를 정합니다

시작은 스토리보드 작가를 구하기 어렵다는 현실적인 문제였습니다

바로 만들지 않고 무엇을 대신하고 무엇을 남길지부터 물었습니다

요청 예시 · “$grill-with-docs 바로 구현하지 말고 다섯 가지가 구체해질 때까지 한 번에 하나씩 물어봐.”

질문에 답하며 MOVIOLA를 설명하는 한 문장을 만들었습니다

좋은 서비스 설명은 사용자 → 입력 → 핵심 흐름 → 눈으로 확인할 결과를 한 문장에 담습니다.

사람과 AI가 같은 뜻으로 쓰도록 용어를 정했습니다

도메인 언어는 우리 서비스에서 사람과 AI가 같은 뜻으로 쓸 말입니다. 오후에는 각자 3–5개를 정합니다.

기획 문서를 정한 뒤 필요한 기술을 AI에게 물었습니다

서비스 설계서를 먼저 정하고, 그다음 필요한 기술 스펙을 AI에게 묻습니다.

서비스의 흐름을 먼저 그리고 각 단계에서 할 일을 정했습니다

서비스의 시작부터 결과 확인까지 흐름을 그리고, 각 단계에서 필요한 작업을 정했습니다.

만들어보니 컷마다 따로 그리는 것만으로는 부족했습니다

첫 서비스 설계서는 구현 결과를 보며 다시 고칩니다. 틀려서가 아니라, 만들어 봐야 보이는 사실이 있기 때문입니다.

MOVIOLA는 크지만 여러분은 핵심 흐름 하나만 완성합니다

방법은 같습니다. 질문 → 서비스 설계서 → 작은 작업 → 구현 결과를 보고 수정.

매일 시작·작업·마무리 세 구간을 거칩니다

AI가 제안해도 작업 선택, 실행 승인, 완료 판단은 내가 맡습니다.

진행 기록은 매일 같은 다섯 항목으로 남깁니다

별도 워크북은 쓰지 않습니다. Codex와 대화하며 정리하고, 내가 확인한 내용만 프로젝트 문서에 남깁니다.

AI는 대화를 넘어 프로젝트 안에서 직접 작업합니다

이제 AI에게 프로젝트 안에서 범위가 정해진 일을 맡깁니다.

작업이 길어지자 좋은 프롬프트만으로는 부족해졌습니다

모델을 더 세게 시키는 대신, 모델이 일할 수 있는 환경을 설계하기 시작했습니다. 여기서 하네스 엔지니어링이 등장합니다.

사람과 AI는 서로 다른 일을 맡습니다

AI가 만든 결과는 늘 검토합니다

• 빠르게 나오는 초안과 실행 결과
• 빠질 수 있는 조건, 틀릴 수 있는 결과
• 문서로 남기는 지시와 확인 지점
• 검증을 마친 뒤 맡기는 다음 작업

AI가 만든 부분도 마지막에는 내가 직접 설명할 수 있어야 합니다.

막히면 같은 프롬프트를 되풀이하지 말고 작업 조건을 바꿉니다

오늘은 네 가지 작업 도구를 준비합니다

설치하기 전에 세 가지만 확인합니다

• 운영체제와 터미널 · macOS인지 Windows인지, 어느 터미널을 열어야 하는지
• 설치 권한 · 이 노트북에 프로그램을 설치할 수 있는지
• 로그인 계정 · GitHub, OpenAI, Vercel 계정과 이메일에 접근할 수 있는지

Git 저장소가 있어야
AI가 바꾼 전후를 확인하고 되돌릴 수 있습니다

저장소(repository)는 프로젝트 파일과 변경 이력을 함께 관리하는 폴더입니다.

GitHub 계정을 준비하고
첫 커밋을 비공개로 올립니다

내 폴더의 Git 커밋을 GitHub에 올려 보관합니다. Day 4에는 이미 올라간 저장소를 Vercel과 연결합니다.

권한 범위와 되돌리는 방법을 먼저 정합니다

설치할 때는 당일 실행 안내서를 그대로 따릅니다

운영체제마다 경로와 명령이 다릅니다. 슬라이드를 옮겨 적지 말고, 같은 안내서에서 복사해 실행합니다.

01안내서 열기QR을 찍거나 아래 버튼을 누릅니다.

02명령 복사내 운영체제에 맞는 명령을 복사합니다.

03함께 확인막히면 반복하지 말고 진행자와 확인합니다.

복사 가능한 설치 안내서 열기 →

휴대전화 카메라로 스캔

creativeengineer-kimjungho.com/
teaching/agentic-ai/day1-install-runbook.html

QR과 버튼은 같은 안내서를 엽니다. 설치가 막히면 명령을 반복하지 말고 오류 화면을 그대로 보여 주세요.

AI에게 안내서를 한 단계씩 풀어 달라고 합니다

스킬은 AI가 반복해서 따를 작업 안내서입니다

이번 수업에서는 스킬을 만들지 않습니다. Matt Pocock의 스킬 묶음을 설치하고 필요한 이름을 불러 씁니다.

준비 상태에 따라 통과 경로가 달라집니다

Matt Pocock 스킬 전체를 프로젝트에 설치합니다

설치한 뒤 프로젝트별 설정을 한 번 진행합니다

스킬 이름 앞에는 $를 붙입니다. 설치나 설정이 멈췄다면 다음 장의 네 가지 정보를 준비합니다.

설치나 설정이 멈췄다면
네 가지 정보를 준비합니다

“다음 한 단계만 알려 줘”라고 요청한 뒤, 다음 장에서 내 진행 경로를 고릅니다.

각자 다른 속도로 진행해도 됩니다

설치가 끝나면 AI 작업 규칙을 준비합니다

설치 확인 → 작업 방식 → 프로젝트 규칙

이제부터는 Codex에 일을 맡기는 다섯 동작과 AGENTS.md에 남길 규칙을 준비합니다.

Codex에는 다섯 동작으로 작업을 맡깁니다

작업 루프는 일이 진행되는 순서이고, 다섯 동작은 각 단계에서 Codex에 요청하는 방식입니다.

AGENTS.md에 프로젝트의 작업 규칙을 남깁니다

AGENTS.md는 Codex가 작업 전에 자동으로 읽는 Markdown 안내 문서입니다. 앱·CLI·IDE에서 같은 프로젝트 규칙을 이어갑니다.

네 가지 원칙으로 AI 코딩의 반복 실수를 줄입니다

복잡한 작업에서는 재작업을 줄이는 대신 조금 느려질 수 있습니다. 단순한 한 줄 수정에는 상황에 맞게 적용합니다.

공통 행동 원칙과 내 프로젝트 규칙을 한 파일에 합칩니다

Codex에서는 AGENTS.md, Claude Code에서는 CLAUDE.md에 넣습니다. 다음 장 QR에서 영문 원문 전체를 엽니다.

QR로 원문을 열고 작업 규칙을 프로젝트에 넣으세요

01

원문 열기

휴대전화로 오른쪽 QR을 스캔합니다.

02

전체 복사

안내 페이지에서 ‘전체 원문 복사’를 누릅니다.

03

파일에 붙여넣기

사용하는 코딩 도구의 프로젝트 안내 파일에 붙여 넣습니다.

Codex→AGENTS.md

Claude Code→CLAUDE.md

휴대전화 카메라로 스캔

복사 안내서 열기

creativeengineer-kimjungho.com/
teaching/agentic-ai/agent-rules.html

두 도구를 함께 사용한다면 같은 작업 규칙을 두 파일에 각각 넣습니다.

기획부터 검토까지 이어지는 스킬 흐름을 사용합니다

오류가 생기면 어느 단계에서든 $diagnosing-bugs로 재현하고 원인부터 확인합니다.

Day 1 오후에는
서비스 설계서 한 장을 완성합니다

대화에서 확인한 결정은 $to-spec 문서와 $to-tickets 작업 목록으로 프로젝트 안에 남깁니다.

막히거나 결정이 필요할 때마다 멘토와 상의합니다

누가 언제 무엇을 하려는지
한 문장으로 적습니다

서비스의 핵심 동작 흐름을 세 화면으로 확인합니다

디자인 시안이 아닙니다. AI가 화면과 기능을 추측하지 않도록 핵심 동작 순서를 보여주는 화면 메모입니다.

집중 질문으로 기획 내용을 하나씩 구체화합니다

Codex에서 $grill-with-docs를 실행합니다. 질문에 하나씩 답하고, 마지막에 도메인 언어와 결정이 내 뜻과 맞는지 확인합니다.

서비스마다 필요한 말과 그 뜻이 다릅니다

$grill-with-docs로 질문을 주고받으며, 우리 서비스에서 같은 뜻으로 사용할 말을 정합니다.

도메인 언어는 외워서 적용하는 용어 목록이 아니라, 집중 질문을 거쳐 우리 서비스 안에서 합의한 말입니다.

다섯 가지 결정을 확인한 뒤
서비스 설계서를 씁니다

복사해서 쓰세요 · “결정을 다섯 항목과 도메인 언어 목록으로 요약해 줘. 추측은 표시하고, 내가 확인하기 전에는 서비스 설계서를 쓰지 마.”

확인한 결정을 여섯 칸의
서비스 설계서로 옮깁니다

서비스 설계서 맨 위에는 도메인 언어 3–5개와 한 줄 뜻을 함께 적습니다.

공통 기술로 시작하고
꼭 필요한 기술만 더합니다

기술을 고르는 시간이 아니라, 서비스 설계서를 구현하는 데 기본 구성 외에 무엇이 더 필요한지 확인하는 시간입니다.

이번 수업의 공통 웹 기반은
React·TypeScript·Vercel입니다

이 세 가지는 공통 기반입니다. 핵심 기능에 필요한 모델·데이터·외부 기능은 서비스 설계서에 따라 더합니다. Next.js는 필요할 때만 선택합니다.

서비스는 웹 기반·핵심 기능·시각 재료로 구성됩니다

Codex는 구현과 연결을 돕습니다. 필요한 모델·데이터·시각 재료는 서비스 설계서에서 따로 정하고 준비합니다.

서비스의 핵심 동사를 기준으로 필요한 기술을 고릅니다

이번 4일 동안 새 AI 모델을 처음부터 학습하는 것은 기본 범위가 아닙니다. 이미 준비된 핵심 기술을 연결해 한 가지 동작을 끝까지 확인합니다.

시각 재료는 미리 정하되,
핵심 흐름이 작동한 뒤 다듬습니다

Day 1에는 역할과 필요한 재료를 정합니다. 배치·크기·반응형 디테일은 핵심 흐름이 작동한 뒤 다듬습니다.

Day 2는 핵심 흐름을
처음부터 끝까지 작동시킵니다

완료 기준 · 핵심 흐름이 내 노트북에서 끝까지 작동하고, 결과가 서비스 설계서에 적은 의도와 맞는다.

Day 3는 다른 사람이 설명 없이
쓸 수 있도록 다듬습니다

완료 기준 · 다른 사람이 설명 없이 핵심 흐름을 끝까지 완료하고, 막힌 지점이 수정되어 있다.

Day 4는 기능 추가를 멈추고
화면·배포·시연을 완성합니다

완료 기준 · 다듬은 화면, 공개 주소, 끝까지 이어지는 시연과 대체 화면이 준비되어 있다. Day 4 배포 Runbook 열기

보완할 칸 하나와 내일의 첫 작업을 적습니다

Codex 대화를 다시 읽는 대신, 내가 확인해 프로젝트에 남긴 문서와 첫 작업에서 이어갑니다.

도구가 달라도 프로젝트 안내 문서의 역할은 같습니다

역할은 같습니다. 파일 이름은 도구마다 다릅니다. 두 문서는 작업을 안내하며, 보안 규칙을 강제하는 장치는 아닙니다.

카파시의 관찰을 커뮤니티가 작업 규칙으로 정리했습니다

정확한 표현 · “카파시가 직접 쓴 문서”가 아니라 “카파시의 관찰에서 파생된 코딩 에이전트 지침”입니다.