앞서 쓴 첫 20분의 마지막 문장, **“같은 부탁을 일반 Claude와 Claude Code에 각각 해볼게요”**에서 이어집니다.

시간에는 설명뿐 아니라 화면 시연·실습·대기·발표가 포함돼 있습니다. **대괄호는 진행 메모**, 나머지는 실제로 말할 대본입니다.

---

**09:50–10:00 · 일반 Claude와 Claude Code, 무엇이 다른가**

[일반 Claude와 Claude Code를 나란히 보여준다. 같은 간단한 제작 요청을 준비한다.]

먼저 일반 Claude에서 해볼게요.

“업무 아이디어를 입력하고 목록으로 볼 수 있는 작은 도구를 만들어줘.”

[실제 응답을 보여준다. 코드, 파일, 미리보기 중 나온 결과를 그대로 설명한다.]

일반 Claude에서도 이렇게 코드를 만들거나 결과물을 보고 수정할 수 있습니다. 여기서 문장을 고치고, 화면을 바꾸는 요청도 할 수 있고요.

이번에는 Claude Code에서 같은 일을 해보겠습니다.

여기서는 제가 연결한 프로젝트 폴더를 같이 봐주세요. AI가 어떤 파일을 읽고, 무엇을 만들고, 어디를 수정하는지가 이 폴더에 남습니다.

[파일 목록과 Claude Code의 작업 내용을 연결해서 보여준다.]

이 차이가 왜 필요하냐면요.

작업하다 보면 결과 하나만 받는 게 아니라, 기존 파일을 다시 열고, 다른 자료를 참고하고, 수정한 걸 실행해봐야 할 때가 있습니다.

“지난번에 만든 화면에 이 기능을 더해줘.”
“이 폴더의 자료를 읽고 결과를 만들어줘.”
“방금 수정한 게 실제로 작동하는지도 확인해줘.”

이런 일을 이어서 하기 위해 오늘 Claude Code를 쓰는 겁니다.

같이 일하는 사람에게 작업할 책상과 필요한 자료를 알려준다고 생각하시면 돼요.

다만 그 사람이 무엇을 바꿨는지는 봐야겠죠. AI가 “완료했습니다”라고 했을 때, 실제 파일이 생겼는지, 화면이 원하는 대로 바뀌었는지는 우리가 확인할 거예요.

[참가자 화면을 확인한다.]

각자 Claude Code를 열어보세요. 지금 로그인한 계정과 작업할 위치를 먼저 확인하겠습니다.

아직 안 열리는 분은 오류 화면을 그대로 보여주세요. 어느 단계에서 막혔는지 보고 같이 이어가면 됩니다.

---

**10:00–10:25 · 프로젝트 폴더를 만들고 첫 결과 만들기**

[각자 수업용 폴더를 하나 만든다.]

오늘 작업할 폴더를 하나 만들겠습니다. 이름은 알아보기 쉽게 `오늘의 AI 실습` 정도로 해도 좋아요.

이 안에 오늘 만든 파일과 결과를 모아둘 겁니다.

폴더를 나누는 이유는 간단해요. 나중에 다시 열었을 때 어떤 자료로 작업했고, 무엇이 만들어졌는지 찾기 쉬워야 하니까요.

[수업에서 정한 편집기 또는 Claude Code 화면에서 폴더를 연다.]

지금 열어둔 위치가 방금 만든 폴더인지 확인해주세요.

확인됐으면 Claude에게 이렇게 물어볼게요.

> 지금 작업할 폴더가 어디인지 알려줘. 아직 파일은 바꾸지 마.

답변에 나온 위치와 우리가 연 폴더가 같은지 보시면 됩니다.

이제 첫 번째 도구를 만들겠습니다. **업무 아이디어 보드**예요.

생각난 아이디어를 적고, 목록으로 보고, 끝낸 건 표시할 수 있는 작은 도구입니다. 오늘 처음에 말씀하신 아이디어도 여기에 넣어볼 수 있고요.

처음에는 같은 요청으로 시작하겠습니다.

> 이 폴더에 한국어 업무 아이디어 보드를 만들어줘.  
> 제목과 메모를 입력하면 목록에 추가되게 해줘.  
> 완료한 항목은 표시하고, 필요 없는 항목은 삭제할 수 있게 해줘.  
> 입력한 내용은 이 브라우저에 저장해서 새로고침해도 남게 해줘.  
> 한 화면으로 만들고, 실제로 실행해서 여는 방법을 알려줘.  
> 계정이나 외부 API, 데이터베이스는 아직 넣지 마.

[요청을 실행한다. 생성 중에는 파일 목록을 보여준다.]

지금 기다리는 동안 폴더를 같이 보세요. 조금 전에는 없던 파일이 생기고 있을 겁니다.

파일 이름을 지금 전부 이해할 필요는 없어요. 우선은 **내가 요청한 작업이 실제 파일로 만들어지고 있다**는 걸 보시면 됩니다.

작업 허용을 묻는 창이 나오면 무엇을 하려는지 읽어보세요. 잘 모르겠으면 그 화면을 같이 보겠습니다.

[실행된 화면을 연다.]

이제 화면이 열렸으면 아이디어 하나를 넣어보세요. 아까 말씀하신 걸 짧게 적어도 됩니다.

목록에 나타났나요?

그럼 완료 표시도 해보고, 필요 없는 항목 하나를 지워보겠습니다. 새로고침했을 때 입력한 내용이 남는지도 확인해보세요.

[각자가 핵심 동작을 직접 해본다.]

이제부터는 한 가지씩 다르게 바꿔볼게요.

제목을 본인이 쓰기 편하게 바꿔도 좋고, 색을 바꿔도 좋습니다. 입력 칸에 적힌 안내 문구를 바꿔도 되고요.

예를 들면 이렇게 말할 수 있습니다.

> 제목을 ‘이번 달에 줄이고 싶은 일’로 바꿔줘.  
> 입력 칸에는 ‘반복해서 하는 업무를 적어보세요’라고 보여줘.

바꾼 뒤에는 화면을 다시 보세요. 내가 말한 부분이 바뀌었는지 확인하면 됩니다.

[각자 변경 한 가지를 확인한다.]

지금 하신 게 앞으로 계속 반복할 과정이에요.

원하는 걸 말하고, 나온 결과를 써보고, 다른 부분을 다시 말하는 겁니다.

처음 요청을 완벽하게 써야만 시작할 수 있는 건 아니에요. 직접 보면서 구체적으로 고쳐갈 수 있습니다.

---

**10:25–10:35 · 휴식과 환경 복구**

여기까지 한 번 쉬고 가겠습니다.

지금 화면이 잘 열린 분은 그대로 두시면 되고요. 아직 막힌 분은 오류 화면을 닫지 말고 남겨주세요. 쉬는 시간 전후로 같이 확인하겠습니다.

다음 시간에는 방금 한 수정 요청을 말로도 해보고, 생각이 잘 정리되지 않을 때 AI에게 어떻게 도움을 받을지 해볼 거예요.

---

**10:35–11:00 · 사람에게 말하듯 요청하기, 보이스 코딩과 메타 프롬프팅**

[방금 만든 앱을 다시 연다.]

만들어진 걸 한 번 보니까 바꾸고 싶은 부분이 생기죠.

이때 “좋은 프롬프트를 써야 한다”고 생각하면 오히려 시작하기 어려울 수 있어요. 우선은 옆 사람에게 설명한다고 생각해보세요.

지금 무엇을 하고 있는지, 어디가 불편한지, 어떻게 바뀌면 좋을지를 말하면 됩니다.

예를 들어 “좀 더 편하게 해줘”라고 하면, AI가 편하다는 뜻을 추측해야 하잖아요.

이렇게 설명하면 조금 더 구체적입니다.

> 아이디어가 많아지니까 끝난 일과 아직 할 일을 구분하기 어려워.  
> 완료한 일은 접어두고, 아직 안 끝난 일부터 볼 수 있게 바꿔줘.

어떤 불편이 있고, 화면에서 무엇이 바뀌어야 하는지 들어 있죠.

[마이크를 켜고 같은 내용을 자연스럽게 말한다.]

저는 요즘 이런 내용을 말로 설명하는 경우가 많습니다.

말이 처음부터 정돈돼 있을 필요는 없어요. 이야기하다가 생각이 정리되기도 하거든요.

다만 전송하기 전에 숫자나 이름이 제대로 입력됐는지는 한번 보세요. 음성 입력이 다른 단어로 받아 적을 수 있으니까요.

각자 지금 화면에서 바꾸고 싶은 것 하나를 말로 요청해보겠습니다. 타이핑이 더 편한 분은 타이핑하셔도 됩니다.

[각자 요청하고 결과를 확인한다.]

이번에는 생각 자체가 아직 정리되지 않은 상황을 해볼게요.

“불편한 건 알겠는데, 뭘 만들어달라고 해야 할지 모르겠다.”

그럴 때는 요청을 정리하는 일부터 맡길 수 있습니다.

> 내가 하려는 일을 설명할게.  
> 먼저 네가 이해한 내용을 짧게 정리해줘.  
> 만들기 위해 꼭 필요한 내용이 빠져 있으면 물어봐.  
> 답을 바탕으로 첫 번째 제작 요청문을 써줘.

이렇게 **요청문을 만드는 과정에도 AI의 도움을 받는 방식**을 메타 프롬프팅이라고 부릅니다.

이름보다 방금 한 행동을 기억하시면 돼요. 부탁할 내용을 혼자 다 정리하지 않아도 된다는 겁니다.

[AI가 정리한 내용을 보여준다.]

여기서 바로 실행하기 전에 한 번 읽어보겠습니다.

내가 말하지 않은 기능이 들어갔는지, 중요한 조건이 빠졌는지 보세요.

잘못 알아들었다면 이렇게 고치면 됩니다.

> 여러 사람이 같이 쓰는 기능까지는 필요 없어. 우선 나 혼자 쓸 거야.  
> 내가 꼭 필요한 건 완료한 일과 남은 일을 구분하는 거야.

이렇게 정정하고 나서 만들게 하면 됩니다.

[각자가 자기 요청을 정리하고 수정하도록 시간을 준다.]

그리고 처음부터 얼마나 크게 만들지에 대해서도 말씀드릴게요.

처음 해보는 일이고 결과가 잘 그려지지 않을 때는 작게 시작하는 편이 확인하기 쉽습니다. 한 번에 많이 만들면 어디서부터 달라졌는지 찾기 어려워지거든요.

반대로 양식과 기준이 이미 분명한 간단한 작업이라면, 불필요하게 여러 단계로 쪼갤 필요는 없습니다.

오늘은 결과를 직접 보면서 다음 요청을 정할 수 있는 크기로 시작해보겠습니다.

---

**11:00–11:15 · 방금 만든 화면으로 최소 개발 개념 이해하기**

[앱 화면과 실제 파일을 함께 보여준다.]

이제 우리가 무엇을 만든 건지 조금만 들여다보겠습니다.

먼저 화면에 제목이 있고, 입력 칸이 있고, 버튼이 있죠. 이런 화면의 구조를 만드는 데 HTML을 씁니다.

글자 크기나 색, 여백처럼 보이는 모양을 정하는 건 CSS라고 하고요.

버튼을 눌렀을 때 목록에 추가되거나 완료 표시가 바뀌는 동작에는 JavaScript가 쓰입니다.

가게에 빗대면 공간을 어떻게 나눌지, 어떻게 꾸밀지, 손님이 버튼을 눌렀을 때 어떤 일이 일어날지를 나눠보는 것과 비슷해요.

[버튼 하나를 가리킨다.]

지금 이 버튼의 문구를 바꾸고 싶은지, 색을 바꾸고 싶은지, 눌렀을 때의 행동을 바꾸고 싶은지만 구분해도 요청이 구체적이 됩니다.

용어를 외워야 수정할 수 있는 건 아니에요. “이 버튼을 누르면 완료된 항목만 보여줘”라고 설명해도 됩니다.

다음은 API입니다.

다른 서비스의 자료나 기능을 가져오고 싶을 때가 있겠죠. 프로그램끼리 정해진 방식으로 요청을 보내고 답을 받는 접점을 API라고 합니다.

정해진 양식으로 부탁을 접수하는 창구에 빗대어 볼 수 있어요.

여기서 하나만 구분해볼게요.

**AI로 만든 앱**과 **앱 안에서 AI를 계속 사용하는 것**은 다릅니다.

우리가 지금 만든 아이디어 보드는 AI에게 제작을 맡겼지만, 아이디어를 추가할 때마다 AI에게 답을 받아오는 구조로 요청하지는 않았어요.

나중에 “입력한 메모를 AI가 요약하게 해줘”라는 기능을 넣는다면, 그때는 AI 서비스 연결과 비용도 함께 생각해야 합니다.

[변경된 파일과 Git 기록을 보여준다.]

마지막으로, 잘 되던 상태를 남겨두는 방법입니다.

수정하다가 마음에 안 들거나 오류가 생기면 이전 상태와 비교하고 싶겠죠. 파일의 변경 기록을 관리하는 도구가 Git입니다.

게임의 저장 지점처럼 생각해볼 수 있지만, 어떤 상태를 기록할지는 직접 정해야 합니다.

지금 정상으로 작동하는 상태를 기록해두겠습니다.

> 현재 바뀐 파일과 사용자에게 달라진 동작을 설명해줘.  
> 확인한 정상 상태를 Git으로 기록할 수 있게 도와줘.

[변경 내용을 읽고 정상 버전을 기록한다.]

개발할 때는 요구를 정리하고, 코드를 쓰고, 실행하고, 잘못된 부분을 고치는 일을 반복합니다. AI를 써도 원하는 동작인지 확인하는 과정은 남아 있어요.

이제 우리가 돌아갈 수 있는 기록 하나를 남긴 겁니다. 이 기록을 다른 곳에 보관하는 GitHub는 배포할 때 다시 연결해서 보겠습니다.

---

**11:15–11:50 · 왜 스킬을 쓰는가, 실제 폴더와 지침, 작은 스킬 만들기**

[방금 사용한 요청문을 보여준다.]

지금까지는 하고 싶은 일을 대화로 설명했죠.

그런데 같은 일을 다음 주에도 하고, 그다음 주에도 한다면 어떨까요?

“결과는 이 순서로 써줘.”
“없는 정보는 추측하지 마.”
“우리 회사에서는 이 표현을 써.”
“이 양식을 참고해.”

이런 설명을 매번 다시 입력하고 있다면, 한 번 정리해두고 꺼내 쓸 이유가 생깁니다.

Claude를 만든 Anthropic이 공개한 **Agent Skills**도 이런 업무 지식과 절차를 재사용할 수 있게 묶는 방식입니다.

새로 온 동료에게 업무를 알려준다고 생각해보세요. 매번 옆에서 같은 말을 해줄 수도 있고, 안내서와 참고 자료를 묶어줄 수도 있죠.

스킬은 그 안내서와 필요한 자료를 담은 서류철에 빗대어 볼 수 있습니다.

[실제 `SKILL.md`를 연다.]

이 파일에는 언제 이 작업을 하고, 어떤 순서로 진행하고, 무엇을 확인할지가 적혀 있습니다.

여기 있는 내용을 우리가 매번 다시 입력하는 대신, 필요한 작업을 요청할 때 이 안내서를 읽고 진행하게 하는 거예요.

한 번 쓸 일이라면 정리하는 시간이 더 들 수도 있습니다. 반복되는 일부터 시도해보면 좋겠죠.

예를 들어 매번 설명하는 시간을 5분씩 줄이고, 처음 정리하는 데 30분이 들었다면 여섯 번 사용했을 때 준비 시간과 같아집니다.

이 숫자는 설명을 위한 예시예요. 실제로는 결과를 검토하고 스킬을 수정하는 시간도 같이 봐야 합니다.

**만들어둔 시간이 반복해서 아끼는 시간보다 큰지**, 그걸 비교하는 겁니다.

[회사 공통 지침과 팀별 지침이 있는 시연 폴더를 연다.]

스킬을 보기 전에, 계속 참고할 지침과 특정 업무의 안내서를 구분해볼게요.

여기 `CLAUDE.md` 파일이 있습니다. 오늘은 회사 공통 업무 안내문이라고 생각해보겠습니다.

“쉬운 한국어로 답한다.”
“자료에 없는 날짜나 담당자는 추정하지 않는다.”

이런 공통 기준을 적어둘 수 있어요.

이 파일은 사람이 읽을 수 있는 텍스트 문서입니다. Claude가 작업할 때 참고하는 지침이지, 내부 시스템 프롬프트 자체나 강제 보안 설정은 아닙니다.

[`.claude` 폴더를 연다.]

그리고 점이 붙은 `.claude`는 폴더입니다. 관련 설정이나 스킬 등을 모아두는 곳이에요.

`CLAUDE.md`는 프로젝트 바로 아래에 둘 수도 있고, `.claude` 안에 둘 수도 있습니다. 이 폴더를 만들었다고 지침 파일이 자동으로 생기는 건 아니고요.

[공통 폴더 아래의 브랜드팀과 운영팀 폴더를 연다.]

이번에는 브랜드팀에 들어가보겠습니다.

회사 공통 기준은 그대로 두고, 브랜드팀에 필요한 안내를 더 적어둔 거예요.

운영팀에는 다른 추가 안내가 있겠죠.

이걸 **회사 공통 안내와 팀별 추가 안내**로 생각하시면 됩니다. 팀별 안내가 공통 안내를 통째로 지워버리는 방식은 아닙니다.

[새 세션에서 공통 폴더와 팀 폴더를 각각 열어 지침 목록을 비교한다.]

현재 위치와 상위 폴더의 지침은 함께 읽힙니다. 하위 폴더의 지침은 그 안의 파일을 다룰 때 필요에 따라 읽힐 수 있고요.

그래서 서로 충돌하는 내용을 여기저기 적기보다, 모두에게 필요한 기준과 특정 작업에 필요한 기준을 나눠두는 게 좋습니다.

[실제 `aijjun-sns-hub/SKILL.md`를 연다.]

이번에는 제가 쓰는 스킬을 보여드릴게요.

이건 SNS 작업을 시작할 때 어떤 제작 스킬이 필요한지 고르는 안내입니다.

사용자가 “이 대본으로 개념을 설명하는 영상을 만들고 싶다”고 하면, 그 요청에 맞는 제작 방법을 찾아 이어가도록 정리해둔 거예요.

제가 매번 모든 스킬 이름과 순서를 말할 필요를 줄이려는 겁니다. 이렇게 **필요한 스킬을 고르는 스킬**도 만들 수 있어요.

[모션 제작 스킬의 실제 폴더를 연다.]

옆의 모션 스킬을 보면 파일이 더 있습니다.

`SKILL.md`에는 작업 순서가 있고, 참고 폴더에는 자세한 설명이 있습니다. 템플릿에는 틀과 글꼴이 있고, 스크립트에는 실행할 도구가 들어 있고요.

이 자료들이 `SKILL.md` 안에 들어 있는 건 아닙니다. 별도 파일로 있고, 안내서가 필요한 위치를 가리키는 거예요.

처음에는 이름과 설명을 보고 어떤 스킬이 맞는지 판단하고, 필요하면 본문과 관련 파일을 읽습니다.

명확하게 쓰고 싶을 때는 이름으로 직접 부를 수도 있고요.

다만 이름을 불렀다고 없는 프로그램이 설치되거나 외부 계정이 자동으로 연결되는 건 아닙니다. 안내서와 실제 작업 도구는 구분해야 해요.

[학습자 실습으로 전환한다.]

여러분은 지금 이 큰 구조를 전부 만들 필요는 없습니다.

아주 작은 것 하나만 만들어볼게요.

업무 메모를 주면 다음 세 가지로 정리하는 스킬입니다.

- 완료한 일
- 다음 행동
- 확인 필요한 점

그리고 없는 날짜나 담당자는 지어내지 않도록 하겠습니다.

Claude에게 이렇게 요청해보세요.

> 업무 메모를 세 항목으로 정리하는 작은 프로젝트 스킬을 만들어줘.  
> 항목은 완료한 일, 다음 행동, 확인 필요한 점이야.  
> 없는 날짜나 담당자는 추측하지 마.  
> 우선 SKILL.md 파일 하나로 간단히 만들고, 저장 위치와 부르는 방법을 알려줘.

[파일 생성과 저장 위치를 확인한다.]

답변만 보지 말고, 실제로 파일을 열어보세요. 우리가 정한 기준이 들어 있나요?

이제 이름으로 불러서 메모 하나를 정리해보겠습니다.

[합성 메모 A를 넣고 결과를 확인한다.]

이번에는 다른 메모를 넣어보세요.

[합성 메모 B를 넣는다.]

내용은 달라졌는데 결과를 정리하는 기준은 유지되는지 보시면 됩니다. 이게 오늘 직접 확인할 부분이에요.

이제 필요할 때 찾아볼 추천 세 가지를 짧게 보여드리겠습니다.

첫 번째는 **REA**입니다. 완성된 앱의 기능이 어떻게 동작하는지 분석 근거를 찾는 데 쓰는 도구예요. 여기에도 작업 안내서인 스킬과 실제 분석을 하는 도구가 구분돼 있습니다.

두 번째는 **토스의 UX writing 스킬**입니다. 버튼이나 안내 문구를 어떤 기준으로 고칠지 정리돼 있어요. 예를 들어 “확인”이라는 버튼보다 “상품 목록 내려받기”가 눌렀을 때의 결과를 더 구체적으로 알려주죠.

세 번째는 **Scrapling 출처 조사 스킬**입니다. 공개 자료를 모으면서 어디서 확인했는지, 접근하지 못한 자료는 무엇인지 함께 남기는 데 쓰는 방식입니다.

지금 전부 설치할 필요는 없습니다. 내 반복 작업과 맞는 게 생기면 내용을 열어보고 선택하시면 됩니다.

[연결된 도구 목록으로 이동한다.]

마지막으로 MCP를 연결해서 보겠습니다.

작업 안내서가 있어도 자료가 다른 서비스에 있으면 가져올 연결이 필요하겠죠.

MCP는 AI 앱이 외부 도구나 자료를 사용하도록 연결하는 공통 규약입니다.

업무 안내서와 업무 도구에 접속하는 방법을 나눠 생각해보세요. 스킬에 할 일이 적혀 있어도, 실제 서비스의 로그인과 권한은 따로 필요합니다.

[사전 검증한 연결 하나에서 읽기 작업을 한 번 수행한다.]

지금은 연결된 도구로 자료 하나만 읽어보겠습니다.

어떤 자료를 가져왔는지, 출처가 어디인지 확인해주세요. 도구 이름이 목록에 있다는 것과 실제 자료를 읽을 수 있다는 것은 따로 확인해야 합니다.

---

**11:50–12:05 · 반복해서 시키는 일, 루틴으로 연결하기**

방금 만든 스킬로 메모를 정리할 수 있게 됐죠.

그런데 매번 정해진 시간에 같은 일을 해야 한다면, 시작하라고 말하는 것도 반복됩니다.

그럴 때 작업을 일정에 맞춰 다시 실행하도록 만들 수 있어요. 오늘 말하는 루틴이나 예약 작업이 여기에 해당합니다.

다만 꼭 확인할 게 있습니다. **어디에서 실행되는지**예요.

내 컴퓨터에서 실행되는 작업이라면 컴퓨터가 켜져 있어야 할 수 있습니다. 클라우드에서 실행되는 작업이라면 그쪽에서 접근할 수 있는 자료가 필요하고요.

내 노트북에만 있는 파일을 클라우드 작업이 저절로 볼 수 있다고 생각하면 안 됩니다.

[로컬 작업과 클라우드 작업을 간단한 그림으로 비교한다.]

오늘은 짧은 작업 하나로 실행과 확인을 해보겠습니다.

이 세션에서 합성 메모를 한 번 읽고, 항목 수를 알려주는 작업으로 할게요. 외부에 보내거나 원본을 바꾸는 작업은 넣지 않겠습니다.

> 이 수업 세션에서 1분 뒤 합성 메모를 읽고 항목 수를 한 번 알려줘.  
> 실행이 끝난 뒤 예약이 남아 있는지도 확인해줘.  
> 외부 전송과 원본 수정은 하지 마.

[실제 제공되는 예약 기능으로 설정한다. 기다리는 동안 입력 파일과 실행 위치를 확인한다.]

설정됐다는 답변이 나오면, 무엇을 언제 실행하도록 등록했는지 보세요.

[결과가 나온 뒤 확인한다.]

이제 실제 결과가 나왔는지 확인하겠습니다.

그리고 실습이 끝났으니 남아 있는 예약도 확인할게요. 반복 작업이라면 중지하는 방법까지 알아야 합니다.

여기까지 해보면 세 가지를 나눌 수 있습니다.

일을 하는 기준을 묶는 건 스킬, 외부 도구나 자료를 연결하는 건 MCP, 정해진 때 다시 시작하게 하는 건 예약 작업입니다.

필요한 부분을 골라 연결하는 거예요.

---

**12:05–12:30 · GitHub에 저장하고 Vercel로 공통 배포하기**

[지금 만든 공통 앱을 다시 연다.]

이제 이 화면을 다른 사람도 볼 수 있게 해보겠습니다.

지금 컴퓨터에서 열리는 주소가 다른 사람의 컴퓨터에서도 열리는지는 별개의 문제예요. 내 컴퓨터 안에서 실행한 상태일 수 있으니까요.

먼저 현재 정상 상태를 GitHub에 올리고, Vercel에 배포해서 주소로 열어보겠습니다.

GitHub는 우리가 기록한 프로젝트를 원격으로 보관하고 공유하는 곳입니다. 작업 기록을 다른 곳에도 보관하는 공동 서고처럼 생각해볼 수 있어요.

Vercel은 프로젝트를 배포해서 주소로 접근하게 하는 데 쓰고요.

[저장할 파일 목록을 확인한다.]

올리기 전에 파일을 한 번 보겠습니다. 오늘 수업용 파일과 합성 자료만 들어 있는지 확인해주세요.

계정 비밀번호나 개인 자료가 섞여 있으면 먼저 빼야 합니다.

Claude에게 이렇게 요청하겠습니다.

> 현재 프로젝트의 변경 내용을 확인하고 GitHub에 저장할 수 있게 도와줘.  
> 올릴 파일과 제외할 파일을 먼저 보여줘.  
> 필요한 로그인은 내가 직접 할게.

[GitHub 로그인과 저장을 진행한다.]

GitHub 화면에서 파일이 보이는지 확인해보세요. 우리가 방금 저장한 변경 기록도 같이 보겠습니다.

이제 Vercel로 넘어갈게요.

오늘은 Vercel CLI를 사용하겠습니다. CLI는 명령을 입력해서 작업을 요청하는 방식이라고 생각하시면 돼요.

먼저 설치돼 있는지 확인하고, 없다면 설치하겠습니다. 이미 있는 것을 다시 설치할 필요는 없습니다.

[강사 메모: 수업 환경에 맞춰 Node·npm·Vercel CLI를 확인한다. 설치와 로그인은 준비된 안내를 사용한다.]

Claude에게 이렇게 요청해볼 수 있습니다.

> 이 앱을 Vercel CLI로 배포할 수 있게 도와줘.  
> 필요한 도구가 설치돼 있는지 먼저 확인해줘.  
> 로그인과 프로젝트 선택은 내가 확인하고 진행할게.

[배포 과정을 보여준다.]

여기서는 어떤 프로젝트를 올리는지 확인해주세요. 다른 프로젝트가 선택돼 있다면 그대로 진행하지 말고 바꿔야 합니다.

[배포 주소가 나오면 연다.]

주소가 나왔으면 열어보겠습니다.

화면이 보이는 것에서 끝내지 말고, 아이디어를 추가하고 완료 표시도 해보세요.

가능한 분은 휴대전화에서도 열어보겠습니다.

여기서 휴대전화에 기존 목록이 보이지 않을 수도 있어요. 우리가 데이터를 어디에 저장하도록 만들었는지 확인해야 합니다.

지금은 각 브라우저에 저장하도록 요청했죠. **같은 앱 주소를 공유하는 것과 같은 데이터를 공유하는 것은 다릅니다.**

여러 사람이 같은 목록을 함께 보고 수정해야 한다면, 그때는 저장 방식을 더 연결해야 해요. 오후에 데이터베이스가 필요한 경우를 보면서 다시 이야기하겠습니다.

[잘 된 사람과 막힌 사람의 상태를 짧게 확인한다.]

지금 어디까지 됐는지만 남겨주세요.

GitHub 저장까지 됐는지, 배포 주소가 나왔는지, 그 주소에서 기능까지 확인했는지를 나눠보면 됩니다.

---

**12:30–13:30 · 점심**

오전에는 같은 작은 도구를 만들고, 직접 바꾸고, 저장하고, 주소로 열어보는 과정까지 했습니다.

점심 이후에는 아까 말씀하신 본인 과제로 넘어갈 거예요.

식사하시면서 지금 만든 경험을 어디에 써보고 싶은지 생각해보셔도 좋겠습니다. 오전과 생각이 달라져도 괜찮아요.

그럼 한 시간 뒤에 다시 시작하겠습니다.

---

**13:30–13:45 · 비슷한 산업의 사례와 내 도구의 형태 고르기**

[오전 V1 메모를 다시 보여준다.]

다시 시작해보겠습니다.

오전에는 같은 도구로 만드는 과정을 익혔고요. 이제는 본인 업무에서 어떤 부분을 만들지 고를 차례입니다.

그전에 비슷한 산업에서 AI를 어떤 일에 쓰는지 세 가지를 짧게 보겠습니다.

첫 번째는 롯데홈쇼핑의 협력사 문의 지원 사례입니다.

공식 사례에서는 상품 품질과 관련된 문의, 필요한 서류 안내처럼 반복되는 확인 과정을 AI가 돕는다고 설명합니다.

여기서 우리 업무에 가져와 볼 질문은 이거예요.

“새 상품을 검토하거나 등록할 때, 매번 확인하는 항목이 있나?”
“자료가 빠져서 같은 질문을 다시 보내는 일이 있나?”

그런 일이 있다면 자료에서 누락된 항목을 정리하는 작은 도구부터 생각해볼 수 있습니다.

[두 번째 사례를 보여준다.]

두 번째는 Shopify의 Sidekick입니다. 상점 관리자 안에서 상품 정보나 콘텐츠, 데이터 관련 작업을 자연어로 요청하는 기능을 안내하고 있어요.

이 사례에서는 **일하는 화면과 그 화면의 자료를 함께 다룬다**는 점을 보시면 됩니다.

우리도 필요한 내용을 매번 복사해서 다른 곳으로 옮기고 있다면, 그 왕복을 줄일 방법을 생각해볼 수 있겠죠.

[세 번째 사례를 보여준다.]

세 번째는 L’Oréal의 데이터 분석 사례입니다.

직원이 질문하면 필요한 데이터를 조회하고 계산해서 결과를 보여주는 흐름을 소개하고 있습니다.

이런 큰 시스템을 오늘 그대로 만드는 건 아니고요. 우리에게 필요한 질문 하나부터 가져와 보는 겁니다.

예를 들어 “이 표에서 누락된 항목을 찾아줘”, “이 기준으로 합계를 보여줘”처럼요.

[참가자들에게 자기 업무와 연결할 시간을 준다.]

방금 사례 중에 본인 업무와 닮은 부분이 있었나요? 있었다면 그 부분만 한 줄 적어보세요.

이제 도구의 형태도 골라보겠습니다.

혼자 내 컴퓨터에서 파일을 정리하면 되는 일이라면 로컬 도구로 충분할 수 있어요.

여러 사람이 같은 화면을 열어야 한다면 웹으로 공유하는 편이 편할 수 있고요.

여러 사람이 같은 데이터를 계속 수정해야 한다면 저장 방식과 권한도 필요해집니다.

오늘은 공통 배포를 모두 한 번 경험했지만, **개인 과제는 실제 사용하는 방식에 맞춰 정하면 됩니다.**

---

**13:45–14:05 · 말로 설명하고 간단한 PRD 만들기**

[다섯 질문을 띄운다.]

오전에 말씀하신 내용을 다시 보겠습니다.

지금도 그걸 만들고 싶은지, 다른 게 더 먼저 떠오르는지 생각해보세요.

이번에는 만들기 전에 다섯 가지만 정리하겠습니다.

누가 쓰는지, 어떤 일이 불편한지, 무엇을 넣을지, 어떤 결과가 나오면 좋을지, 오늘 무엇부터 만들지입니다.

이런 내용을 개발할 때는 PRD라고 부르기도 합니다. 오늘은 **맡길 일을 정리한 한 장짜리 의뢰서** 정도로 생각하시면 돼요.

길게 쓸 필요는 없습니다.

먼저 말로 설명해보세요.

> 내가 하는 일을 설명할게.  
> 지금 하는 일, 불편한 점, 입력 자료, 원하는 결과를 정리해줘.  
> 빠진 내용 중에서 만들기에 꼭 필요한 것만 물어봐.  
> 답을 바탕으로 오늘 만들 첫 기능과 확인 방법을 정리해줘.

[각자가 말하거나 입력하도록 시간을 준다.]

AI가 정리한 내용을 읽어보겠습니다.

내가 말하지 않은 기능이 많이 붙었나요? 그렇다면 오늘 필요한 것부터 남기면 됩니다.

예를 들어 “상품 소싱 전체를 자동화하고 싶다”는 큰 방향은 유지할 수 있어요.

그중에서 오늘은 “내가 고른 상품 자료 세 개를 같은 항목으로 정리하고, 빠진 정보를 표시한다”부터 시작할 수도 있겠죠.

반대로 이미 입력 파일과 결과가 분명한 간단한 작업이라면, 더 복잡한 계획을 만들 필요는 없습니다.

[네 사람의 과제를 짧게 순회하며 확인한다.]

제가 한 분씩 볼 때는 두 가지만 확인할게요.

“무엇을 넣으면 무엇이 나오나요?”
“오늘 잘 됐는지는 무엇을 해보면 알 수 있나요?”

이 두 가지가 설명되면 첫 작업을 시작할 수 있습니다.

[범위가 너무 커진 사람에게.]

원하시는 전체 모습은 남겨둘게요. 그중에서 오늘 직접 써볼 수 있는 첫 부분을 하나 골라보겠습니다.

이 기능이 작동하면 다음 기능을 더하기도 쉬워지고, 생각과 다르면 방향을 바꾸기도 수월해집니다.

---

**14:05–14:30 · Aside, 디자인 레퍼런스, 이미지 도구**

[공개 웹페이지 하나를 준비한다.]

개인 작업을 하다 보면 자료가 웹페이지에 있거나, 브라우저 화면을 직접 봐야 하는 경우가 생깁니다.

그때 사용할 수 있는 도구 중 하나가 Aside예요.

지금은 페이지 하나에서 확인한 정보를 메모로 정리하는 과정을 보여드리겠습니다.

> 이 공개 페이지에서 확인할 수 있는 상품명과 규격을 정리해줘.  
> 확인한 페이지 주소도 함께 남겨줘.  
> 없는 정보는 추측하지 말고 확인 필요로 표시해줘.

[결과와 원래 페이지를 함께 보여준다.]

결과가 나왔으면 원래 페이지와 대조해보세요.

AI가 어디에서 확인했는지, 실제로 페이지에 있는 내용인지 보시면 됩니다.

이렇게 자료를 읽고 옮기는 과정을 연결할 수 있습니다. 로그인이나 접근 제한이 있는 경우에는 허용된 범위에서 진행해야 하고요.

[디자인 레퍼런스로 전환한다.]

다음은 디자인입니다.

앱이 작동하기 시작하면 “좀 더 보기 좋게 바꾸고 싶다”는 생각이 들 수 있어요.

그럴 때 “예쁘게 해줘”라고만 말하기보다, 마음에 드는 화면을 하나 고르고 어떤 점이 좋은지 말해보세요.

예를 들면 이런 식입니다.

“표가 한눈에 들어오는 게 좋다.”
“버튼을 찾기 쉽다.”
“중요한 숫자가 먼저 보인다.”
“글이 많아도 읽는 순서가 보인다.”

이런 말을 기준으로 바꿔주면 됩니다.

[Mobbin 또는 준비한 레퍼런스 화면 하나를 보여준다.]

Mobbin에서는 실제 앱 화면과 사용 흐름을 찾아볼 수 있고요. getdesign.md 같은 자료는 디자인 규칙을 정리하는 참고로 사용할 수 있습니다.

오늘은 사이트를 많이 돌아다니기보다 한 화면에서 특징 두 가지만 골라보겠습니다.

Claude에게 이렇게 요청해보세요.

> 이 레퍼런스에서 우리 도구에 맞게 참고할 특징을 정리해줘.  
> 색상, 글자 크기, 배치, 버튼 규칙을 DESIGN.md로 적어줘.  
> 지금 잘 작동하는 기능은 유지하면서 적용해줘.

`DESIGN.md`는 원하는 디자인 기준을 적어두는 문서라고 생각하시면 됩니다. 다음에 수정할 때 같은 취향을 다시 설명하는 일을 줄일 수 있어요.

[각자 특징 두 가지를 정한다.]

그리고 이미지가 필요한 경우에는 별도의 이미지 도구를 연결해서 쓸 수 있습니다.

지금은 Google Flow에서 이미지를 만들고, 파일로 저장해서 프로젝트에 넣는 흐름만 짧게 보겠습니다.

[준비한 이미지 생성 예시와 결과 파일을 보여준다.]

Claude에게 이미지 요청문을 정리하게 하고, 이미지 도구에서 만든 결과를 프로젝트 폴더에 넣을 수도 있습니다.

그다음에는 “이 파일을 배경에 넣어줘”, “이 그림을 이 위치에 보여줘”라고 요청하면 되는 거예요.

실제 상품 모습을 전달해야 하는 부분이라면 실제 사진을 기준으로 쓰고, 생성 이미지는 용도에 맞게 구분해주세요.

이미지가 필요 없는 과제는 바로 자기 기능을 개선하시면 됩니다.

---

**14:30–15:30 · 개인 제작 1 — 내 업무의 첫 흐름 만들기**

[개인 PRD와 프로젝트를 열게 한다.]

이제 본인 과제로 넘어가겠습니다.

지금 정리한 계획을 Claude에게 보여주고, 오늘의 첫 기능부터 요청해보세요.

> 이 계획을 기준으로 첫 기능을 만들어줘.  
> 내가 넣는 자료와 원하는 결과를 먼저 짧게 정리해줘.  
> 정리한 내용에 맞춰 실제로 실행할 수 있게 만들어줘.  
> 아직 정하지 않은 기능은 임의로 크게 늘리지 마.

처음 결과가 나오면 직접 써보겠습니다.

제가 옆에서 도울 때도 여러분이 직접 요청하고 실행해보시면 좋겠어요. 나중에 혼자 다시 할 때 그 과정이 필요하니까요.

[강사는 순회한다. 아래 말은 필요한 참가자에게 개별적으로 사용한다.]

“아무것도 안 돼요”라고 할 때:

> 어디까지는 됐고, 어느 행동을 했을 때 멈췄는지 같이 볼게요.  
> 방금 눌렀던 순서 그대로 한 번만 보여주세요.

원하는 결과와 다르게 나왔을 때:

> 지금 나온 결과에서 어떤 부분이 달라요?  
> 바꾸고 싶은 부분을 화면에서 하나 짚어서 말해보세요.

무슨 파일이 생겼는지 모르겠다고 할 때:

> Claude에게 만든 파일과 역할을 쉬운 말로 설명해달라고 해보세요.  
> 그다음 실제 파일을 같이 열어보겠습니다.

질문을 어떻게 해야 할지 모르겠다고 할 때:

> 지금 상황부터 말해도 됩니다.  
> “이 자료를 넣었고, 이런 결과를 원했는데, 지금은 이렇게 나왔다”고 설명해보세요.

[첫 제작 약 25분 후, 전체 안내는 짧게 한다.]

잠깐 현재 상태만 확인하겠습니다.

첫 화면이 나온 분은 실제 입력을 하나 넣어보세요. 화면이 나온 것과 기능이 작동하는 것은 따로 확인하면 됩니다.

아직 생성 중이거나 오류가 있는 분은 막힌 지점을 남겨주세요. 한 분씩 보겠습니다.

[개별 코칭을 이어간다.]

기능을 계속 추가하고 있을 때:

> 지금 추가하려는 기능이 첫 목표에 꼭 필요한지 한번 볼까요?  
> 우선 지금 만든 흐름을 써보고, 실제로 불편한 부분부터 더해보겠습니다.

AI가 많은 것을 바꿔버렸을 때:

> 마지막으로 잘 되던 상태가 언제였는지 확인해볼게요.  
> 이번에 바꾼 부분을 설명하게 하고, 필요한 변경만 남겨보겠습니다.

[마지막 10분은 현재 결과 확인과 복구에 사용한다.]

이제 새로운 기능을 더하기 전에 현재 상태를 한번 확인해주세요.

무엇을 넣으면 어떤 결과가 나오는지 직접 해보겠습니다. 잘 되는 부분과 아직 막힌 부분을 짧게 적어두세요.

쉬고 나서는 그중에서 가장 필요한 수정 하나를 골라 이어가겠습니다.

---

**15:30–15:40 · 휴식**

잠깐 쉬겠습니다.

지금 정상으로 작동하는 상태가 있다면 기록해두세요. 오류가 있는 분은 화면과 오류 내용을 남겨두시면 됩니다.

다음 시간에는 직접 써보면서 발견한 불편을 고치고, 필요한 분은 데이터 저장도 연결하겠습니다.

---

**15:40–16:40 · 개인 제작 2 — 개선, 필요한 DB 연결, 실제 확인**

[각자 현재 결과물을 다시 연다.]

다시 한번 직접 써보겠습니다.

이번에는 처음 만든 사람의 입장보다, 내일 이 도구를 사용할 사람의 입장에서 봐주세요.

어디에 무엇을 넣어야 할지 알 수 있나요?
버튼을 누르면 예상한 결과가 나오나요?
입력 내용을 잘못 넣었을 때는 어떻게 되나요?

한꺼번에 다 고치기보다 가장 불편한 것 하나부터 말해보겠습니다.

> 지금 이 도구를 직접 써보니 이 부분이 불편해.  
> 현재 잘 되는 기능은 유지하면서 이 부분을 바꿔줘.  
> 바뀐 뒤에는 같은 입력으로 다시 확인해줘.

[각자 개선을 진행한다.]

데이터를 저장해야 하는 분들은 지금 저장 위치도 확인해볼게요.

아까 공통 앱을 다른 기기에서 열었을 때 같은 목록이 보이지 않을 수 있다고 말씀드렸죠.

혼자 한 브라우저에서 쓰는 것과, 여러 사람이 같은 자료를 함께 쓰는 것은 필요한 구성이 달라집니다.

여러 사람이 같은 정보를 저장하고 다시 불러와야 한다면 데이터베이스를 검토할 수 있어요. 공동으로 사용하는 기록 보관함에 빗대어 볼 수 있습니다.

오늘은 필요한 분만 Supabase를 연결해서 테스트 데이터를 저장하고 다시 읽는 흐름을 보겠습니다.

[DB가 필요한 참가자에게 개별적으로 진행한다. 다른 참가자는 자기 과제의 개선을 계속한다.]

먼저 이 과제에서 정말 같은 데이터를 공유해야 하는지 확인할게요.

필요하다면 테스트용 프로젝트 하나를 정하고, 그 프로젝트에만 연결하겠습니다.

Claude에게는 이렇게 요청해볼 수 있습니다.

> 이 앱의 데이터를 지금 어디에 저장하는지 설명해줘.  
> 여러 기기에서 같은 데이터를 사용하려면 무엇이 필요한지 알려줘.  
> 테스트용 Supabase 프로젝트에서 최소한의 저장과 조회부터 연결해줘.

MCP는 개발하는 동안 우리가 Supabase의 도구를 사용할 수 있게 연결하는 방법입니다.

앱을 만드는 사람이 쓰는 연결과, 완성된 앱을 사용자가 쓰는 접속 방식은 구분해야 해요.

키나 접속정보가 나올 때도 권한을 확인해야 합니다. 관리자 권한이 있는 비밀키를 채팅이나 브라우저 코드에 그대로 넣는 방식으로 진행하지 않겠습니다.

[합성 데이터 한 건을 저장하고 다시 조회한다.]

데이터가 저장됐다는 답변이 나오면 실제로 다시 불러와보세요. 새로고침했을 때도 유지되는지 확인하겠습니다.

여기까지 되면 저장과 조회가 연결된 겁니다.

오늘은 실제 고객 자료를 옮기기보다 테스트 데이터로 이 흐름을 확인하겠습니다.

[로컬 도구를 만드는 참가자에게.]

이 과제는 내 컴퓨터에서 파일을 처리하면 되는 거죠. 그러면 결과 파일이 어디에 생기는지, 다음 파일을 넣어도 같은 방식으로 실행되는지를 보겠습니다.

데이터베이스를 추가하는 것보다 입력과 출력 경로를 분명히 하는 게 먼저일 수 있어요.

[디자인을 다듬는 참가자에게.]

모양을 바꾼 뒤에도 기존 기능을 다시 눌러보세요. 보기 좋아진 것과 동작이 유지되는 것을 같이 확인하겠습니다.

글자가 잘리거나 버튼 의미가 모호하면 그 부분을 구체적으로 말해보세요.

“이 화면에서 가장 먼저 해야 할 행동이 보이게 해줘.”
“이 버튼을 누르면 무엇이 나오는지 문구에 적어줘.”

이런 식으로요.

[마지막 10분.]

이제 발표할 때 보여줄 입력 하나를 골라주세요.

그 입력으로 실제 동작을 해보고, 어디까지 되는지 확인하겠습니다. 아직 안 되는 부분은 그대로 남겨도 됩니다. 무엇이 남았는지 설명할 수 있게 적어두세요.

---

**16:40–17:00 · 정상 버전 저장, GitHub, 필요한 배포**

현재 상태를 남겨두겠습니다.

오늘 만든 걸 다음에 다시 열려면 파일뿐 아니라 실행 방법도 있어야 하죠.

먼저 Claude에게 현재 상태를 정리하게 하겠습니다.

> 지금 작동하는 기능과 남은 문제를 짧게 정리해줘.  
> 다음에 다시 실행하는 방법을 README에 적어줘.  
> 입력 파일과 결과 파일이 어디에 있는지도 알려줘.

[README를 실제로 열어 확인한다.]

여기 적힌 방법을 여러분이 읽고 다시 실행할 수 있는지 보세요. 모르는 표현이 있으면 쉬운 말로 바꿔달라고 하면 됩니다.

이제 변경 내용을 확인하고 GitHub에 저장하겠습니다.

외부에 올리면 안 되는 자료나 비밀키가 섞이지 않았는지 먼저 보고요. 현재 정상 버전을 기록해서 올리겠습니다.

웹으로 공유할 과제는 Vercel CLI로 최신 버전을 배포해보세요.

배포가 끝나면 이번에 나온 주소를 열어주세요. 방금 바꾼 기능이 실제로 반영됐는지 확인하겠습니다.

로컬 도구를 만든 분은 실행 안내대로 다시 열고, 샘플 파일을 한 번 처리해보세요.

[발표 준비로 연결한다.]

마지막으로 발표할 화면 하나와 보여줄 입력 하나를 준비해주세요.

설명만 길게 하기보다, 실제로 눌러서 무엇이 되는지 먼저 보여주시면 됩니다.

---

**17:00–17:20 · 전원 결과 시연과 V2**

[오전 V1과 현재 결과를 함께 볼 수 있게 준비한다. 네 명에게 약 4분 30초씩 배정하고 안내·전환에 2분을 사용한다.]

이제 오늘 만든 걸 같이 보겠습니다.

처음에 말씀하신 V1도 옆에 띄워둘게요.

발표에서는 네 가지를 짧게 이야기해주시면 됩니다.

처음에 무엇을 만들고 싶었는지, 오늘 실제로 무엇을 만들었는지, 직접 해보니 어떤 점을 알게 됐는지, 다음에는 무엇을 할 건지요.

먼저 실제 동작부터 보여주세요. 잘 되는 부분과 남은 부분을 같이 말씀해주시면 됩니다.

[참가자가 시연한 뒤 실제 관찰한 내용으로 피드백한다.]

동작이 확인됐을 때:

> 방금 보여주신 건 입력한 자료가 원하신 결과로 이어지는 부분까지 확인됐네요.  
> 다음에는 실제로 자주 쓰는 입력 한두 개를 더 넣어보고, 어디서 조건이 달라지는지 확인해보시면 좋겠습니다.

범위가 많이 달라졌을 때:

> 오전에는 말씀하신 범위가 더 넓었는데, 직접 해보면서 이 부분을 먼저 만들기로 정하셨네요.  
> 어떤 경험 때문에 순서를 바꾸셨는지 한 번 말씀해주시겠어요?

미완료 부분이 있을 때:

> 지금은 여기까지 작동하고, 이 연결이 남아 있는 상태네요.  
> 다음에 이어갈 때는 이 기능을 더 늘리기 전에, 방금 막힌 입력과 오류부터 다시 확인하면 되겠습니다.

아직 다음 계획이 막연할 때:

> 내일 이걸 다시 연다면 가장 먼저 무엇을 해보고 싶으세요?  
> 새로운 기능을 더하는 것도 좋고, 실제 자료 한 건으로 써보는 것도 좋습니다.

[네 사람 모두 같은 기회를 갖도록 진행한다. 소감이 반드시 긍정적이어야 한다고 유도하지 않는다.]

---

**17:20–17:30 · 총평과 혼자 이어가는 방법**

[네 사람의 V1과 V2를 함께 보여준다.]

처음에 말씀하신 내용과 지금 말씀하신 내용을 같이 보겠습니다.

[실제 달라진 부분 한두 가지를 짚는다.]

어떤 분은 처음 생각을 더 구체적으로 만드셨고, 어떤 분은 직접 해보면서 먼저 할 일을 바꾸셨네요.

오늘 만든 기능도 남지만, **무엇을 맡기고 무엇을 확인해야 하는지 직접 해본 경험**도 다음 작업에 쓸 수 있습니다.

다음에 혼자 이어갈 때는 오늘 한 순서로 시작해보세요.

폴더를 열고, 현재 어디까지 돼 있는지 확인하고, 바꾸고 싶은 부분 하나를 말하는 겁니다.

모르면 그 상태를 설명하면 됩니다.

“이 파일을 넣었는데 이런 결과가 나왔어.”
“나는 이렇게 되길 원했어.”
“어디부터 확인하면 좋을지 알려줘.”

처음부터 정확한 개발 용어로 질문할 필요는 없습니다. 화면과 입력, 원하는 결과를 구체적으로 전달하는 것부터 해보세요.

말로 설명하는 게 편했던 분은 마이크도 계속 써보시면 좋겠습니다. 대신 이름이나 숫자가 제대로 들어갔는지는 전송 전에 확인해주세요.

그리고 기능을 더하기 전에 한 가지는 꼭 보셨으면 합니다.

**이걸 쓰면서 실제로 일이 줄고 있는가**예요.

설명을 위한 예를 들어볼게요.

원래 10분 걸리던 일을 줄이려고 도구를 만들었는데, 매번 오류를 고치는 데 30분이 들고 있다면 기능을 덜어내거나 방식을 바꿀 필요가 있겠죠.

어떤 기능이 들어갔는지 모르겠다면 먼저 설명을 받아보세요.

> 내가 이 도구를 계속 사용할 수 있게 현재 기능과 작동 방식을 쉬운 말로 설명해줘.  
> 꼭 필요한 기능과 지금은 빼도 되는 기능을 구분해줘.

만들 수 있다고 해서 모든 기능을 한 번에 넣을 필요는 없습니다. 실제로 쓰면서 필요한 것을 더해가면 됩니다.

API 키나 회사 자료를 다룰 때는 어디에 저장되고 누구에게 공개되는지도 확인해주세요. 특히 외부로 보내거나 운영 데이터를 바꾸는 작업은 내용을 보고 진행하는 습관을 가져가시면 좋겠습니다.

[마지막 기록 시간을 준다.]

끝내기 전에 각자 메모 하나만 남기겠습니다.

“다음에 다시 여는 방법.”
“아직 남아 있는 문제.”
“다음에 할 작은 수정 하나.”

이 세 가지를 저장해주세요.

오늘 실습용으로 만든 예약 작업이 남아 있다면 중지 상태도 확인하겠습니다.

[저장과 예약 상태를 확인한다.]

다음에 다시 시작할 때는 이 메모를 Claude에게 보여주면 됩니다.

> 여기까지 만들었고, 다음에는 이 부분을 해보고 싶어.  
> 현재 파일을 읽고 이어서 도와줘.

오늘 각자 만든 것에서 다음 작업을 이어가시면 됩니다.

수고하셨습니다.

---

강사용 사실 확인 자료는 [Claude Code 지침](https://code.claude.com/docs/en/memory), [Skills](https://code.claude.com/docs/en/skills), [예약 작업](https://code.claude.com/docs/en/scheduled-tasks), [Supabase MCP](https://supabase.com/docs/guides/ai-tools/mcp), [Vercel CLI](https://vercel.com/docs/cli/deploying-from-cli)를 기준으로 했습니다. 산업 사례는 [롯데홈쇼핑](https://www.anthropic.com/customers/lotte-homeshopping), [Shopify Sidekick](https://help.shopify.com/en/manual/ai-powered-tools/sidekick), [Anthropic 리테일 가이드](https://resources.anthropic.com/hubfs/The-Enterprise-AI-Transformation-Guide-for-Retail.pdf)에 근거했습니다. **현재 원고는 수업 전 리허설로 실행 시간과 화면을 맞출 초안입니다.**