← 자료실 홈
직접 코딩 0% · WORKER CAPSTONE PROJECT

하나의 서비스를
끝까지 키우는 실습

직장인 대표 프로젝트 「팀 업무 요청·진행 보드」를 2장의 시제품에서 11장의 운영 서비스까지 성장시킵니다. 매 장에서 새 앱을 만들지 않습니다. 책의 해당 절을 다시 펴고, 어제 만든 같은 서비스에 오늘의 능력을 더합니다.

1개끝까지 성장시킬 서비스
10단계2장부터 11장까지
약 14시간전체 권장 실습시간
Lv.6최종 하네스 목표

대표 서비스

팀 업무 요청·진행 보드

해결할 문제 · 메신저·메일·구두로 흩어진 업무 요청 때문에 담당자, 마감일, 진행 상태를 놓친다.

최종 사용자 · 요청을 남기는 팀원, 처리하는 담당자, 현황을 보는 관리자.

최종 모습 · 요청 등록 → 담당자·기한 지정 → 상태 변경 → 주간 보고 → 통제·검증 → GitHub 보관 → Vercel 공개 → 비용·보안 운영까지 연결된 실제 서비스.

범위 원칙 · 처음부터 회사의 진짜 데이터를 넣지 않습니다. 2~10장은 가상 팀·가상 요청으로 완성하고, 11장 운영 점검 이후 조직 정책을 확인한 뒤 실제 적용을 판단합니다.

한눈에 보는 성장 경로

장별 누적 실습

2장
시제품

문제를 화면으로 바꾼다

45~60분 · 펼치기⌄

Claude 웹 아티팩트로 서비스의 화면과 사용 흐름을 먼저 시험합니다.

책을 옆에 펴둘 곳

  • 2.2 아티팩트 — 앱 및 웹사이트 만들기
  • 2.3 프롬프트 5가지 원칙
  • 2.4 말하기→확인하기→통제하기
  • 2.6 웹의 저장 한계

이번 장의 누적 미션

  • 팀원이 업무 요청을 등록하는 화면을 만든다.
  • 요청 제목·내용·희망기한·긴급도를 입력하게 한다.
  • 담당자·상태·마감 임박 표시가 있는 목록을 만든다.
  • 직장 동료 1명에게 보여주고 불필요하거나 빠진 항목을 기록한다.

사람이 직접 확인할 합격선

  • 요청 등록과 상태 변경 흐름이 화면에서 이해된다.
  • 375px에서 입력 폼과 목록이 겹치지 않는다.
  • 실명·전화번호·고객정보 없이 가상 데이터만 사용한다.
  • 웹 아티팩트는 여러 사용자의 데이터를 영구 저장하지 못한다는 한계를 설명할 수 있다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
팀 업무 요청·진행 보드의 화면 시제품을 웹 아티팩트로 만들어줘. 요구사항: 1. 요청 제목, 내용, 희망 기한, 긴급도 입력 2. 담당자와 상태(접수·진행·완료) 표시 3. 마감 임박 요청 강조 4. 요청 목록 필터 5. 375px 모바일 반응형 ★ 완성 조건: - 요청을 등록하면 목록에 나타날 것 - 상태를 바꾸면 즉시 반영될 것 - 빈 제목은 등록되지 않을 것 - 모바일에서 겹치지 않을 것 먼저 계획을 설명하고, 내 승인을 받은 뒤 만들어줘.
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 3장 준비로 계속합니다.
3장
준비

하나뿐인 프로젝트 작업장을 만든다

20~30분 · 펼치기⌄

앞으로 11장까지 계속 사용할 폴더와 실행 환경을 준비합니다.

책을 옆에 펴둘 곳

  • 3.2 터미널 열기
  • 3.3 ls·cd·mkdir·복사/붙여넣기·Ctrl+C
  • 3.4 uv 설치와 uv --version
  • 3.5 완료 체크리스트

이번 장의 누적 미션

  • Documents에 team-request-board 폴더를 만든다.
  • 폴더 안으로 이동해 Claude Code의 전용 작업장으로 정한다.
  • uv 설치 상태를 확인한다.
  • PROJECT-JOURNAL.md를 만들어 장별 결정과 검증 결과를 누적할 준비를 한다.

사람이 직접 확인할 합격선

  • ls에서 team-request-board가 보인다.
  • cd 후 현재 프롬프트가 프로젝트 폴더를 가리킨다.
  • uv --version에서 버전이 나오거나, 오류를 그대로 보존해 해결 절차를 기록한다.
  • 실제 회사 자료가 아닌 빈 전용 폴더에서 시작한다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
$ cd ~ $ cd Documents $ mkdir team-request-board $ cd team-request-board $ ls $ uv --version $ claude
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 4장 로컬 앱로 계속합니다.
4장
로컬 앱

로컬에서 작동하는 최소 제품을 만든다

70~90분 · 펼치기⌄

2장의 시제품을 내 컴퓨터의 실제 파일로 옮기고 CLAUDE.md를 프로젝트 헌법으로 만듭니다.

책을 옆에 펴둘 곳

  • 4.3 mkdir→cd→claude와 허락 창
  • 4.4 CLAUDE.md
  • 4.5 모임 정산 앱의 체크리스트·증거 요구
  • 4.6 Esc·@파일·/usage

이번 장의 누적 미션

  • CLAUDE.md에 만들 것·기능·디자인·금지사항·체크리스트를 쓴다.
  • 하나의 로컬 웹앱으로 요청 등록·상태 변경·필터를 구현한다.
  • 처음에는 localStorage로 저장한다.
  • AI의 완료 보고과 별개로 브라우저에서 직접 조작한다.

사람이 직접 확인할 합격선

  • 요청 3건을 등록하고 새로고침해도 남는다.
  • 상태·담당자·기한 필터가 동작한다.
  • 빈 제목과 잘못된 날짜가 거부된다.
  • CLAUDE.md의 체크리스트와 실제 시험 증거가 대응한다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
CLAUDE.md를 먼저 만들어줘. 프로젝트 이름은 팀 업무 요청·진행 보드야. 핵심 기능은 요청 등록, 담당자 지정, 접수·진행·완료 상태 변경, 기한과 긴급도 표시, 필터, localStorage 저장이야. 개인정보와 실제 회사 정보는 요구하거나 저장하지 마. 삭제 전에는 확인을 받아. CLAUDE.md를 읽고 앱을 만든 뒤 완성 체크리스트를 실제로 시험한 과정과 증거를 보여줘. 실패하면 수정하고 처음부터 다시 검증해줘.
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 5장 자동화로 계속합니다.
5장
자동화

주간 보고를 한 줄 명령으로 자동화한다

70~90분 · 펼치기⌄

같은 서비스의 데이터를 이용해 주간 업무 현황 보고서를 자동 생성합니다.

책을 옆에 펴둘 곳

  • 5.1 프롬프트 5단 구조
  • 5.2 엑셀→PDF와 방어 조건
  • 5.3 CLAUDE.md와 Skill.md 역할 구분
  • 5.5 커스텀 명령어
  • 5.7 통합 자동화

이번 장의 누적 미션

  • 샘플 요청 데이터를 CSV 또는 XLSX로 내보내는 기능을 추가한다.
  • Skill.md에 주간 보고 기준(완료·진행·지연·위험)을 정의한다.
  • 샘플 5건으로 PDF 또는 HTML 주간 보고서를 만든다.
  • /주간보고 커스텀 명령을 등록한다.

사람이 직접 확인할 합격선

  • 요청 수·완료 수·지연 수가 원본과 일치한다.
  • 첫·중간·마지막 요청을 사람이 대조한다.
  • 빈 행·잘못된 날짜·엑셀 아닌 파일을 안전하게 처리한다.
  • 보고서에 없는 성과를 지어내지 않는다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
팀 업무 요청 데이터를 주간 보고서로 자동 정리하는 기능을 추가해줘. ① 만들 것: 요청 데이터를 읽어 주간 업무 현황 보고서 생성 ② 요구사항: 완료·진행·지연·고위험 요약, 담당자별 건수, 다음 주 조치 ③ 방어 조건: 빈 행·잘못된 날짜·중복 요청은 경고, 입력에 없는 성과 생성 금지 ④ 체크리스트: 샘플 5건 합계 대조, 첫·중간·마지막 내용 대조 ⑤ 증거: 실제 테스트 과정과 결과 제시 전문 기준은 Skill.md로 분리하고 /주간보고 명령으로 재사용하게 해줘.
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 6장 위험 설계로 계속합니다.
6장
위험 설계

사고가 나기 전에 다섯 고삐를 설계한다

40~50분 · 펼치기⌄

코드를 늘리기 전에 서비스에서 일어날 사고와 통제 장치를 설계합니다.

책을 옆에 펴둘 곳

  • 6.1 오작동 5가지 유형
  • 6.2 프롬프트와 하네스의 차이
  • 6.3 다섯 고삐
  • 6.3.6 휴먼 인 더 루프
  • 6.4 성숙도 진단

이번 장의 누적 미션

  • 부적절 요청·도배·잘못된 상태 변경·서버 중단·현황 미파악 시나리오를 쓴다.
  • 각 사고에 규칙·울타리·검증·복구·모니터링을 대응시킨다.
  • 삭제·일괄 상태변경·배포는 사람 승인 대상으로 정한다.
  • HARNESS-PLAN.md에 설계를 기록한다.

사람이 직접 확인할 합격선

  • 사고 5종 각각에 예방·발견·복구 장치가 있다.
  • 자동 장치와 사람 승인 지점이 구분된다.
  • 실패 반복은 최대 3회 후 멈추도록 정한다.
  • 현재 성숙도를 Lv.1로 진단하고 7장의 목표를 적는다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
현재 팀 업무 요청·진행 보드의 위험을 분석하고 HARNESS-PLAN.md를 만들어줘. 반드시 다섯 고삐로 정리해줘: 1. 규칙 2. 울타리 3. 시험 4. 안전벨트 5. CCTV 삭제·일괄 상태 변경·배포처럼 위험한 행동은 사람이 승인하게 하고, 같은 수정이 3회 실패하면 멈추고 원인을 보고하도록 설계해줘. 아직 코드는 수정하지 마.
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 7장 운영 고삐로 계속합니다.
7장
운영 고삐

여러 사람이 쓰는 통제된 서버로 진화시킨다

120분 · 펼치기⌄

localStorage 시제품을 서버형 서비스로 바꾸고 다섯 고삐를 실제 장치로 구현합니다.

책을 옆에 펴둘 곳

  • 7.1 서버와 두 브라우저 실시간 확인
  • 7.2 규칙 필터
  • 7.3 울타리와 파괴 테스트
  • 7.4 자동 검증+관리자 승인
  • 7.5 PM2 복구
  • 7.6 관리자 대시보드

이번 장의 누적 미션

  • 요청 데이터를 로컬 서버의 data 폴더에 저장한다.
  • 비방·개인정보·기밀 표현을 차단한다.
  • 길이·쿨타임·중복·분당 횟수를 제한한다.
  • 기한·금액·일괄 상태변경은 관리자 승인 대기로 둔다.
  • PM2 자동 재시작과 관리자 대시보드를 추가한다.

사람이 직접 확인할 합격선

  • 두 브라우저에서 같은 요청이 보인다.
  • 빈칸·공백·경계값·중복 등 파괴 테스트를 통과한다.
  • 위험 변경은 승인 전 공개되지 않는다.
  • 서버를 죽인 뒤 PM2 재시작 횟수가 증가한다.
  • 요청·차단·승인대기·오류·재시작을 대시보드에서 본다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
HARNESS-PLAN.md를 읽고 팀 업무 요청·진행 보드를 여러 사람이 쓰는 서버형 서비스로 발전시켜줘. 다섯 고삐를 모두 구현하고, 브라우저 두 개의 동기화·파괴 테스트·관리자 승인·PM2 자동 복구·대시보드까지 실제로 검증해줘. 네가 추가 파괴 시나리오를 최소 3개 발굴해 시험하고 증거를 보여줘.
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 8장 개발 고삐로 계속합니다.
8장
개발 고삐

만드는 AI에도 검사관과 보안 게이트를 붙인다

100~120분 · 펼치기⌄

서비스 검증을 만든 AI에게만 맡기지 않고 별도 reviewer와 실제 근거를 사용합니다.

책을 옆에 펴둘 곳

  • 8.1 프로젝트 스킬 승격
  • 8.2 reviewer 직무기술서·읽기 전용 권한
  • 8.2.3~8.2.4 테스트 검증·적대적 테스트
  • 8.3 Plan 모드와 진짜 데이터
  • 8.4 PreToolUse·PostToolUse 훅
  • 8.5 플러그인

이번 장의 누적 미션

  • 주간 보고 Skill.md를 정식 프로젝트 스킬로 등록한다.
  • 읽기·검색·실행만 가능한 reviewer를 채용한다.
  • reviewer가 자동 테스트의 빈틈과 함정 입력을 독립 검사한다.
  • .env 보호 훅과 작업 기록 훅을 설치한다.
  • 큰 수정은 Plan 모드 계획 승인 후 실행한다.

사람이 직접 확인할 합격선

  • reviewer 직무기술서에 Write·Edit가 없다.
  • reviewer 보고서에 심각도·파일·근거·판정이 있다.
  • 메인 AI가 수정하고 reviewer가 재검토한다.
  • .env 우회 수정은 막히고 일반 파일 수정은 허용된다.
  • 작업 로그에 시각·행동·파일이 남는다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
이 프로젝트에 reviewer 서브에이전트를 채용해줘. reviewer는 코드·테스트·주간 보고의 정확성을 독립 검증하되 Read, Grep, Glob, Bash만 사용하고 Write·Edit는 주지 마. 기존 테스트가 체크리스트를 진짜 검사하는지, 통과시키기 위한 테스트는 없는지 적대적으로 검토하게 해줘. 문제 수정은 메인 AI가 하고 reviewer가 재검토해. 또한 .env 보호 PreToolUse 훅과 작업 기록 PostToolUse 훅을 설치하고, 우회 수정·일반 수정·로그 생성을 파괴 시험해줘.
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 9장 GitHub로 계속합니다.
9장
GitHub

지금까지 만든 서비스를 금고에 넣고 시간여행을 시험한다

80~100분 · 펼치기⌄

새 앱을 만들지 않고, 바로 이 서비스와 고삐를 GitHub에 보관하고 롤백합니다.

책을 옆에 펴둘 곳

  • 9.1 PM2와 Git/GitHub의 차이
  • 9.3 업로드 전 검문과 .gitignore
  • 9.3.2 인증·비공개 업로드·사람 확인
  • 9.4 커밋·푸시·시간여행
  • 9.5 /저장 자동화

이번 장의 누적 미션

  • .env·data·logs·node_modules를 검문하고 .gitignore에 넣는다.
  • private 저장소로 업로드하고 인증은 직접 승인한다.
  • 안정 버전을 커밋·푸시한다.
  • 복사 프로젝트를 일부러 망가뜨리고 안정 버전으로 복원한다.
  • /저장 명령을 만든다.

사람이 직접 확인할 합격선

  • GitHub에 .env·data·logs가 없다.
  • CLAUDE.md·스킬·reviewer는 함께 올라간다.
  • 안정·고장 커밋을 이름으로 구분할 수 있다.
  • 롤백 후 요청 등록과 상태 변경이 정상이다.
  • 노출된 비밀은 파일 삭제가 아니라 키 폐기·재발급 대상임을 설명한다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
이 팀 업무 요청·진행 보드를 GitHub 비공개 저장소에 올리기 전에 검문해줘. API 키·암호·사용자 데이터·로그·불필요한 폴더를 찾아 .gitignore에 반영하고 제외 이유를 보고해줘. 내 인증이 필요하면 멈춰서 안내해. 업로드 후에는 .env·data·logs가 없는지 내가 확인할 목록을 줘. 안정 버전 커밋을 만든 뒤, 복사 프로젝트에서 고장 버전을 만들고 안정 시점으로 되돌리는 실습도 안내해줘. 강제 푸시는 금지해.
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 10장 배포로 계속합니다.
10장
배포

동일한 서비스를 Vercel로 이사하고 외부망에서 검증한다

120분 · 펼치기⌄

9장의 같은 저장소를 서버리스 구조로 바꾸고 공개 URL·DB·자동 배포·롤백을 완성합니다.

책을 옆에 펴둘 곳

  • 10.2 Vercel과 GitHub 특정 저장소 연결
  • 10.3.1 서버리스와 외부 DB
  • 10.3.2 Plan 모드 이사 계획
  • 10.3.3 Environment Variables
  • 10.3.4 LTE/5G 검증
  • 10.5 자동 배포·로그
  • 10.6 Vercel 롤백

이번 장의 누적 미션

  • Plan 모드에서 파일 저장·SSE·메모리 제한의 이사 계획을 승인한다.
  • 데이터를 외부 DB로 옮기고 폴링 등 서버리스 방식으로 바꾼다.
  • 관리자 암호·DB 연결값은 Vercel 환경 변수에 직접 등록한다.
  • 컴퓨터를 끄고 LTE/5G에서 등록·상태변경·동기화를 시험한다.
  • 작은 수정의 자동 배포와 이전 Ready 배포 롤백을 시험한다.

사람이 직접 확인할 합격선

  • 외부망 두 기기에서 같은 요청 데이터가 보인다.
  • 재배포 후 데이터가 남는다.
  • GitHub 코드에 비밀이 없다.
  • 도배·승인·관리자 보호가 클라우드에서도 작동한다.
  • Vercel 롤백과 Git 코드 롤백, DB 복구가 서로 다름을 설명한다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
이 프로젝트를 Vercel에 배포하고 싶어. 바로 수정하지 말고 Plan 모드에서 서버리스 이사 계획을 보여줘. 파일 저장·SSE·메모리 카운터를 점검하고 외부 DB와 폴링 방식으로 전환해. 기존 다섯 고삐가 클라우드에서도 유지되어야 해. 환경 변수는 내가 Vercel 화면에서 직접 넣도록 안내하고, 배포 후 컴퓨터 OFF·LTE/5G·두 기기·재배포·롤백 체크리스트를 줘.
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 11장 운영로 계속합니다.
11장
운영

만드는 사람에서 지키는 사람으로 졸업한다

90~120분 · 펼치기⌄

공개된 서비스의 비용·보안·책임을 점검하고 운영 가능한 상태로 마무리합니다.

책을 옆에 펴둘 곳

  • 11.1 이메일 알림·월별 지출 한도·3중 비용 울타리
  • 11.2 보안 미니멀과 운영자의 책임
  • 11.3 하네스 성숙도 Lv.6
  • 11.4 업계 용어·CI/CD 로드맵
  • 11.5 필수 합격선

이번 장의 누적 미션

  • API를 쓴다면 자동 충전 OFF·이메일 알림·월별 한도를 설정한다.
  • 기본 암호 변경·최소 권한·비밀 재검문을 수행한다.
  • 문제 요청 삭제 기능과 연락 경로를 마련한다.
  • 개인정보 최소 수집·로그 보존 기준·AI 참고용 안내를 표시한다.
  • Lv.6 자가진단과 운영 인수인계서를 작성한다.

사람이 직접 확인할 합격선

  • 사용자별 제한·하루 총량·콘솔 한도가 3층으로 존재한다.
  • 관리자 기본 암호가 없고 환경 변수에서 읽는다.
  • GitHub와 공개 화면에 키·개인정보가 없다.
  • 운영자가 문제 요청을 삭제하고 신고를 받을 수 있다.
  • 비용·오류·차단·승인대기·배포 상태를 점검하는 주간 루틴이 있다.

이번 장이 끝나면 남길 증거

  • PROJECT-JOURNAL.md 장별 기록
  • 화면 또는 콘솔 증거 2개 이상
  • 실패·수정·재검증 기록 1건 이상
  • 다음 장에 넘길 파일·URL·설정 목록
실행 프롬프트 예시
팀 업무 요청·진행 보드의 졸업 검사를 진행해줘. 11장의 비용·보안·운영 책임과 Lv.6 합격선을 기준으로 운영 체크리스트를 작성해. 자동으로 바꾸지 말고, 내가 콘솔에서 직접 설정할 항목과 네가 코드에서 검사할 항목을 구분해줘. 검사→보완→reviewer 재검토는 최대 3회까지만 반복하고, 통과해도 내 승인 전에는 GitHub 푸시와 Vercel 배포를 하지 마.
다음 장으로 넘길 것 · 현재 결과물, 검증 증거, 남은 문제를 PROJECT-JOURNAL.md에 적고 → 졸업·운영 루틴로 계속합니다.

최종 제출 묶음

서비스

Vercel 공개 URL, 모바일 외부망 접속 증거, 관리자 화면.

고삐

CLAUDE.md, 프로젝트 스킬, reviewer, 훅, 테스트와 대시보드.

안전

.gitignore, 비밀 부재 확인, 환경 변수, 비용 한도, 개인정보 최소화.

복구

PM2 재시작, Git 롤백, Vercel 롤백을 각각 시험한 증거.

학습 기록

PROJECT-JOURNAL.md에 장별 결정·실패·수정·검증·참조 절 기록.

졸업 시연

말하기→확인하기→통제하기를 5분 안에 설명하고 직접 시연.