종단프로젝트 · 소상공인 고객 문의·예약 운영 보드

1개끝까지 성장시킬 서비스

10단계2장부터 11장까지

약 14시간전체 권장 실습 시간

Lv.6최종 하네스 목표

대표 서비스

고객 문의·예약 운영 보드

해결할 문제 · 전화·문자·SNS·메신저로 들어오는 문의와 예약이 흩어져 응답 누락, 중복 예약, 일정 착오가 발생한다.

최종 사용자 · 매장·공방·스튜디오·강의·상담 등을 운영하는 소상공인과 1인 사업자, 그리고 예약을 신청하는 고객.

최종 모습 · 고객 문의 등록 → 예약 희망일·서비스 항목 관리 → 접수·확정·완료 상태 추적 → 일일 일정·주간 운영 보고 자동화 → 검증·통제 → GitHub 보관 → Vercel 공개 → 비용·보안 운영까지 이어지는 실제 서비스.

범위 원칙 · 2~10장에서는 가상 고객·가상 예약만 사용합니다. 실제 고객의 이름·전화번호·주소·결제정보·건강정보는 저장하지 않습니다. 11장의 개인정보·비용·운영 점검을 통과하기 전에는 실제 영업에 적용하지 않습니다.

사업 운영 안전 원칙

가상 데이터 우선 · 실습에서는 고객A, 010-0000-0000처럼 식별 불가능한 예시만 사용하고 실제 고객정보를 입력하지 않습니다.

예약 확정은 사람이 · AI의 답변이나 화면 표시만으로 예약을 확정하지 않고 운영자가 일정·가격·서비스 가능 여부를 최종 확인합니다.

결제 기능은 범위 밖 · 카드번호·계좌 비밀번호·인증정보를 받지 않으며, 결제는 검증된 외부 결제서비스를 별도로 사용합니다.

하나의 서비스이전 장 결과물을 버리지 않고 다음 장의 입력으로 사용합니다.

하나의 기록PROJECT-JOURNAL.md에 결정·실패·검증 증거를 누적합니다.

하나의 리듬모든 장에서 말하기 → 확인하기 → 통제하기를 반복합니다.

한눈에 보는 성장 경로

장별 누적 실습

2장

시제품

고객 문의·예약 관리의 불편을 화면으로 바꾼다

45~60분 · 펼치기⌄

Claude 웹 아티팩트로 핵심 화면과 사용 흐름을 먼저 시험합니다.

책을 옆에 펴둘 곳

2.2 아티팩트 — 앱 및 웹사이트
2.3 프롬프트 5가지 원칙
2.4 말하기·확인하기·통제하기
2.6 웹의 파일 접근·저장 한계

이번 장의 누적 미션

문의 유형, 서비스 항목, 예약 희망일, 상태를 등록한다.
전체·문의 유형별·예약 임박 필터를 만든다.
동료 또는 지인 1명에게 3분 사용성 시험을 받는다.
빠진 기능보다 먼저 핵심 흐름을 검증한다.

사람이 직접 확인할 합격선

문의→접수→확정→완료 흐름이 이해된다.
빈 문의 내용과 이미 지난 예약 희망일이 거부된다.
375px 화면에서 카드와 입력창이 겹치지 않는다.
영구 저장이 되지 않는 한계를 설명할 수 있다.

이번 장이 끝나면 남길 증거

시제품 화면 2장
사용성 의견 3개
수정 전·후 차이 1건
PROJECT-JOURNAL.md의 2장 기록

실행 프롬프트 예시

소상공인·1인 사업자용 고객 문의·예약 운영 보드의 웹 아티팩트 시제품을 만들어줘. 사용자: 소상공인·1인 사업자(운영자)와 가상 고객 핵심 기능: 문의 유형·서비스·예약 희망일 등록, 상태(문의/접수/확정/완료) 변경, 예약 임박 표시, 유형별 필터 제약: 실제 고객의 이름·전화번호·주소·결제정보·건강정보는 입력받지 않기, 375px 반응형 ★ 완성 조건: - 새 문의·예약를 등록하면 즉시 목록에 나타날 것 - 상태와 문의 유형 필터가 동작할 것 - 빈 제목과 과거 마감일은 거부할 것 - 모바일에서 내용이 잘리지 않을 것 먼저 구현 계획과 확인 방법을 설명하고, 내 승인을 받은 뒤 만들어줘.

다음 장으로 넘길 것 · 핵심 화면, 합격선, 사용성 의견, 남은 문제 → 3장 준비

3장

준비

11장까지 사용할 하나의 작업장을 만든다

20~30분 · 펼치기⌄

프로젝트 폴더와 실행 환경을 만들고 장별 기록 체계를 시작합니다.

책을 옆에 펴둘 곳

3.1 터미널의 역할
3.2 핵심 명령어 5가지
3.3 uv 설치
3.4 시작 전 체크리스트

이번 장의 누적 미션

smallbiz-booking-board 전용 폴더를 만든다.
uv와 Claude Code 실행 상태를 확인한다.
PROJECT-JOURNAL.md를 만든다.
2장 시제품의 요구사항과 피드백을 옮긴다.

사람이 직접 확인할 합격선

현재 위치가 프로젝트 폴더임을 확인한다.
uv --version 결과가 보인다.
빈 전용 폴더에서 시작한다.
오류가 나면 메시지를 삭제하지 않고 기록한다.

남길 증거

터미널 현재 경로
uv 버전 결과
폴더 목록
PROJECT-JOURNAL.md 첫 기록

$ cd ~/Documents $ mkdir smallbiz-booking-board $ cd smallbiz-booking-board $ uv --version $ claude

다음 장으로 넘길 것 · 전용 폴더, 환경 확인 결과, 시제품 요구사항과 사업 운영 안전 원칙 → 4장 로컬 앱

4장

로컬 앱

시제품을 내 컴퓨터의 최소 제품으로 옮긴다

70~90분 · 펼치기⌄

CLAUDE.md를 프로젝트 헌법으로 삼아 실제 파일로 작동하는 앱을 만듭니다.

책을 옆에 펴둘 곳

4.1 Claude 웹과 Claude Code의 차이
4.3 첫 실행과 폴더 작업
4.4 CLAUDE.md
4.5 체크리스트와 증거 요구
4.6 슬래시 명령어와 파일 지정

이번 장의 누적 미션

기능·금지사항·합격선을 CLAUDE.md에 적는다.
문의·예약 등록, 상태 변경, 유형 필터를 구현한다.
우선 localStorage에 가상 데이터를 저장한다.
가상 고객 문의와 예약 5건을 준비한다.

사람이 직접 확인할 합격선

새로고침 후에도 데이터가 남는다.
상태·문의 유형·예약일 필터가 모두 동작한다.
입력 오류가 사용자에게 설명된다.
AI의 완료 보고와 별개로 직접 시험했다.

남길 증거

CLAUDE.md
정상 동작 화면 2장
실패→수정→재검증 1건
실행 방법

먼저 CLAUDE.md를 만들어줘. 프로젝트는 '고객 문의·예약 운영 보드'야. 실습에서는 실제 고객정보와 결제정보를 사용하지 않을 거야. 핵심 기능: 문의 유형과 서비스 등록, 예약 희망일과 상태 변경, 우선순위, 유형별 필터, localStorage 저장. 규칙: 실제 고객의 이름·전화번호·주소·결제정보·건강정보 저장 금지, 삭제 전 확인, 기존 기능 보존, 모바일 확인. 작업 전에 계획과 변경 파일을 말하고 승인을 기다려. 완료 후에는 CLAUDE.md의 합격선별 시험 결과와 증거를 보고해줘.

다음 장으로 넘길 것 · 로컬 앱, CLAUDE.md, 샘플 데이터, 시험 결과 → 5장 자동화

5장

자동화

일일 예약표와 주간 운영 보고를 자동화한다

80~100분 · 펼치기⌄

같은 서비스의 데이터를 문서 자동화와 반복 명령으로 확장합니다.

책을 옆에 펴둘 곳

5.1 HWPX 보고서 자동 생성
5.2 엑셀 처리와 PDF 리포트
5.3 Skill.md 기반 분석
5.5 커스텀 명령어
5.6 MCP 외부 연결 원리

이번 장의 누적 미션

가상 고객 문의 3개를 정해진 형식으로 정리한다.
문의·예약 데이터를 CSV로 내보낸다.
처리율·미응답 문의·서비스별 예약 현황을 주간보고로 만든다.
/weekly-report 반복 명령을 정의한다.

사람이 직접 확인할 합격선

원본 건수와 보고서 집계 건수가 일치한다.
지연 기준이 문서에 명시된다.
빈 폴더·잘못된 파일은 안전하게 중단된다.
원본 파일을 덮어쓰지 않는다.

남길 증거

샘플 CSV
일일 예약표·주간 운영보고 결과물
집계 대조표
커스텀 명령 파일

현재 앱의 가상 문의·예약 데이터를 CSV로 내보내고, 이를 읽어 주간 운영 보고서를 만드는 안전한 자동화를 설계해줘. 보고서 항목: 전체/완료/진행/지연 건수, 완료율, 다음 주 우선순위, 확인이 필요한 항목. 규칙: 원본 덮어쓰기 금지, 실제 고객정보·결제정보 열 금지, 건수 대조, 오류 시 중단. 반복 실행할 수 있도록 /weekly-report 명령으로 만들고 사용법과 검증 결과를 남겨줘.

다음 장으로 넘길 것 · 앱+자동화+오류 사례를 하나의 시스템으로 묶어 → 6장 위험 설계

6장

위험 설계

예약 서비스에 필요한 다섯 고삐를 설계한다

45~60분 · 펼치기⌄

기능을 더 만들기 전에 발생 가능한 실패와 대응 원칙을 정합니다.

책을 옆에 펴둘 곳

6.1 AI 오작동 5가지 유형
6.2 하네스의 개념과 역할
6.3 규칙·울타리·검증·안전벨트·모니터링
6.4 하네스 성숙도

이번 장의 누적 미션

부적절한 문의, 중복 예약, 잘못된 일정·집계, 삭제 사고, 장애를 정의한다.
각 위험을 다섯 고삐에 매핑한다.
자동 처리와 사람 승인 경계를 정한다.
현재 성숙도를 자가 진단한다.

사람이 직접 확인할 합격선

위험마다 예방·탐지·복구 방법이 있다.
예약 취소·전체 삭제·실제 영업 적용은 운영자 승인 대상으로 표시된다.
통계와 AI 추천이 가격·예약 확정의 단독 근거가 아님을 명시한다.
다음 장 구현 순위가 정해졌다.

남길 증거

위험 등록부
다섯 고삐 설계표
사람 승인 목록
성숙도 자가 진단

현재 고객 문의·예약 운영 보드의 위험 등록부를 만들어줘. 위험 예시: 부적절한 문의, 반복 등록, 중복 예약, 잘못된 예약 확정, 잘못된 집계, 전체 삭제, 서비스 중단, 실제 고객정보 입력. 각 위험에 대해 발생 조건, 영향, 규칙/울타리/검증/안전벨트/모니터링 중 적용할 고삐, 사람이 승인할 지점을 정리해줘. 코드는 아직 바꾸지 말고 설계안을 먼저 보여줘.

다음 장으로 넘길 것 · 위험 등록부와 구현 우선순위 → 7장 서비스 고삐

7장

서비스 고삐

고객과 운영자가 안심하고 쓸 수 있는 통제 장치를 붙인다

100~120분 · 펼치기⌄

6장의 설계를 실제 입력 규칙, 제한, 테스트, 복구, 현황판으로 구현합니다.

책을 옆에 펴둘 곳

7.2 규칙 적용
7.3 도배 방지 울타리
7.4 검증 적용
7.5 안전벨트와 복구
7.6 이용 현황 모니터링

이번 장의 누적 미션

금지 입력과 필수 입력 규칙을 적용한다.
짧은 시간의 반복 등록을 제한한다.
예약일·처리율 계산 테스트를 만든다.
오류 시 마지막 정상 데이터로 복구한다.
문의·확정·미응답·오류 현황을 표시한다.

사람이 직접 확인할 합격선

정상 입력은 통과하고 위험 입력은 막힌다.
경계값 테스트가 반복 가능하다.
장애 후 데이터 또는 기능이 복구된다.
현황 수치가 실제 샘플 데이터와 일치한다.

남길 증거

정상·차단 사례
테스트 결과
복구 전·후 화면
모니터링 화면

6장의 위험 등록부를 기준으로 다섯 고삐를 순서대로 적용해줘. 1) 규칙: 고객 개인정보와 부적절한 입력 차단 2) 울타리: 반복 등록과 입력 길이 제한 3) 검증: 예약일·처리율·필터 테스트 4) 안전벨트: 오류 시 안전한 메시지와 마지막 정상 상태 복구 5) 모니터링: 문의·확정·미응답·오류 건수 한 번에 전부 바꾸지 말고 고삐 하나씩 구현→시험→내 승인을 받아 다음으로 진행해줘.

다음 장으로 넘길 것 · 통제된 앱과 반복 가능한 시험 → 8장 AI 고삐

8장

AI 고삐

만드는 AI와 안전을 검사하는 AI를 분리한다

80~100분 · 펼치기⌄

서비스뿐 아니라 서비스를 수정하는 AI의 작업 과정에도 통제 장치를 적용합니다.

책을 옆에 펴둘 곳

8.2 서브에이전트 — 제작과 검사 분리
8.3 MCP의 실제 데이터 연결 원리
8.4 Hooks — 차단과 기록
8.5 Plugins — 고삐 세트 재사용

이번 장의 누적 미션

builder와 reviewer 역할을 분리한다.
reviewer가 합격선을 독립 확인하게 한다.
고객 개인정보·비밀정보·대량 삭제·위험 명령을 훅으로 막는다.
검증 규칙을 재사용 가능한 프로젝트 스킬로 정리한다.

사람이 직접 확인할 합격선

제작자의 자기 보고만으로 완료 처리하지 않는다.
reviewer가 결함을 1건 이상 찾아 재수정을 요청한다.
위험 작업은 실행 전에 차단되거나 승인 요청된다.
작업과 검사 기록이 남는다.

남길 증거

역할 정의 파일
검사 보고서
차단 로그
수정→재검사 결과

이 프로젝트의 변경 작업을 두 역할로 분리해줘. - builder: 승인된 기능만 구현 - reviewer: CLAUDE.md, 고객 개인정보 금지, 모바일, 기존 기능 회귀, 테스트 통과 여부를 독립 검사 민감정보 파일, 대량 삭제, 검증 생략을 막는 Hook도 제안해줘. builder의 완료 보고를 reviewer가 그대로 믿지 말고 실제 파일과 시험 결과로 판정하게 해줘.

다음 장으로 넘길 것 · 제작·검사 체계와 차단 로그 → 9장 GitHub

9장

GitHub

서비스를 금고에 넣고 되돌리기를 시험한다

60~80분 · 펼치기⌄

현재 프로젝트 전체를 버전으로 보관하고 안전한 수정·복구 흐름을 익힙니다.

책을 옆에 펴둘 곳

9.1 Git과 GitHub의 역할
9.2 계정과 저장소 준비
9.3 첫 업로드 전 검문
9.4 세이브 포인트와 되돌리기
9.5 자동화

이번 장의 누적 미션

비밀정보와 불필요한 파일을 업로드에서 제외한다.
의미 있는 첫 버전을 커밋·푸시한다.
작은 UI 변경을 별도 세이브 포인트로 남긴다.
의도적으로 변경한 뒤 이전 버전으로 되돌린다.

사람이 직접 확인할 합격선

GitHub에서 파일과 커밋 기록이 보인다.
API 키·고객 개인정보·로컬 환경 파일이 없다.
복구 후 핵심 기능이 다시 동작한다.
README에 실행·시험 방법이 있다.

남길 증거

저장소 URL
검문 결과
커밋 2개 이상
복구 전·후 커밋 ID

GitHub 첫 업로드를 준비해줘. 먼저 비밀정보·고객 개인정보·불필요한 생성 파일을 검사하고 .gitignore와 README 초안을 보여줘. 내 승인 전에는 push하지 마. 승인 후 현재 정상 버전을 커밋하고, 작은 화면 변경을 별도 커밋한 다음 되돌리기 실습 절차를 안내해줘. 각 단계의 확인 명령과 복구 증거를 PROJECT-JOURNAL.md에 남겨줘.

다음 장으로 넘길 것 · 검문된 저장소와 복구 가능한 정상 버전 → 10장 배포

10장

배포

같은 서비스를 가상 고객이 접속할 수 있게 공개한다

80~100분 · 펼치기⌄

GitHub의 정상 버전을 Vercel에 연결하고 운영 환경에서 고삐가 작동하는지 확인합니다.

책을 옆에 펴둘 곳

10.1 Vercel을 쓰는 이유
10.2 GitHub 연결
10.3 배포 환경과 데이터 구조
10.5 배포 후 다섯 고삐 재점검
10.6 수정→푸시→자동 배포

이번 장의 누적 미션

Vercel과 GitHub 저장소를 연결한다.
환경변수와 데이터 저장 방식을 구분한다.
실제 고객정보가 없음을 확인한 뒤 배포 URL을 다른 기기에서 시험한다.
작은 수정이 자동 배포되는 흐름을 확인한다.

사람이 직접 확인할 합격선

새 브라우저·모바일에서 접속된다.
비밀정보가 화면·저장소·로그에 노출되지 않는다.
다섯 고삐의 핵심 시험이 배포 환경에서도 통과한다.
장애 시 이전 정상 배포로 롤백할 수 있다.

남길 증거

배포 URL
모바일 화면
배포 환경 시험표
자동 배포·롤백 기록

GitHub의 정상 버전을 Vercel에 배포하기 위한 계획을 세워줘. 먼저 로컬 저장(localStorage)과 여러 사용자가 공유하는 서버 저장의 차이를 설명하고, 현재 구현에서 가능한 범위를 명확히 표시해줘. 환경변수와 비밀정보 검문, 배포 후 다섯 고삐 재시험, 모바일 외부 접속, 자동 배포와 롤백 순서까지 체크리스트로 제시해줘. 실제 배포는 내 승인을 받은 뒤 진행해줘.

다음 장으로 넘길 것 · 공개 URL, 배포 시험표, 롤백 지점 → 11장 운영

11장

운영

만든 사람에서 책임지는 운영자로 졸업한다

60~80분 · 펼치기⌄

비용·보안·개인정보·AI 안내·장애 대응을 점검하고 지속 운영 여부를 결정합니다.

책을 옆에 펴둘 곳

11.1 비용 울타리
11.2 보안 미니멀
11.3 졸업 과제의 운영 관점
11.4 하네스 성숙도 최종 진단
11.5 다음 단계 로드맵

이번 장의 누적 미션

무료 한도·비용 알림·중단 기준을 정한다.
비밀정보·고객 개인정보·공개 범위를 재점검한다.
AI 기능이 있다면 참고용 안내, 가격·예약 가능 여부는 운영자 확인 우선 원칙을 표시한다.
장애·오류·문의 대응과 종료 절차를 적는다.
Lv.6 자가 진단과 다음 버전 계획을 작성한다.

최종 합격선

비용 상한과 확인 주기가 정해졌다.
실제 고객정보를 저장하지 않으며 가상 데이터 삭제 방법이 있다.
운영자 연락·장애 대응·롤백 절차가 있다.
가상 고객 역할 2명 이상의 최종 사용성 시험을 통과했다.

최종 제출물

배포 URL과 GitHub URL
README·운영 체크리스트
PROJECT-JOURNAL.md
2장↔11장 비교 화면
3분 시연 영상 또는 발표 자료

이 서비스를 실제 영업에 적용할 수 있는지 최종 점검해줘. 점검 범위: 비용 상한과 알림, 비밀정보, 고객 개인정보 최소화, AI 답변 안내, 데이터 삭제, 로그 보관, 장애 대응, 롤백, 운영자 승인, 고객 문의 창구, 서비스 종료. 각 항목을 '통과/보완 필요/운영 전 필수'로 판정하고 증거 위치를 적어줘. 자동 판정하지 말고 사람이 최종 승인해야 할 항목을 별도로 모아줘. 마지막으로 하네스 성숙도 Lv.6 자가 진단과 다음 버전 로드맵을 작성해줘.

졸업 · 2장의 아이디어가 11장의 운영 가능한 서비스로 성장했습니다. 기능의 수보다 검증 증거와 통제 구조가 최종 성과입니다.

최종 제출 패키지

① 작동하는 서비스Vercel URL, GitHub 저장소, 실행 가능한 정상 버전

② 과정의 증거장별 PROJECT-JOURNAL, 실패·수정·재검증 기록

③ 운영의 증거비용·보안·개인정보·장애·롤백 체크리스트

④ 사업 운영 성찰말하기·확인하기·통제하기가 어떻게 달라졌는지 1쪽

⑤ 사업 운영 원칙AI 집계와 예약 상태를 매출·고객 응대 판단의 단독 근거로 사용하지 않기

⑥ 시연문제→핵심 흐름→고삐→배포→운영을 3분 안에 설명하기