[week06] yenachang924 빵킵 프로젝트, 회고, 주차 기록

members/yenachang924/idea.md

@@ -1,14 +1,14 @@
-# 💡 프로젝트 기획서 — 빵킵 (BbangKeep)
+# 💡 프로젝트 기획서. 빵킵 (BbangKeep)
 
 | 항목 | 내용 |
 | --- | --- |
 | **1. 한 줄 정의** | 품절 전에 원하는 빵을 확보하고 싶은 빵지순례 소비자와, 생산량을 감으로 정하는 동네 빵집 사장을 위한 **선결제 픽업 예약 서비스**. |
-| **2. 문제** | 당일 제조·당일 소진이라 손님은 "가면 그 빵이 있는지"를 알 수 없다 → 오픈런으로 시간을 쓰거나, 헛걸음하거나, 원치 않는 차선을 산다. 사장은 품절 문의 응대에 시달리고 품절 후 방문객은 전부 놓친 매출. 지금 이 둘을 잇는 채널은 인스타 스토리(일방향·예약 불가·24시간 소멸)와 전화뿐. |
-| **3. 해결책** | 사장은 아침 1회 5분, 오늘의 굽는 시간표와 시간대별 수량만 올린다. 손님은 시간대를 골라 정가 선결제로 '킵'하고 줄 없이 픽업. 핵심은 일부러 **하지 않는 두 가지** — 실시간 재고 입력 요구 없음(사장이 지속 가능해야 하니까), 할인 없음(파는 것은 싼 빵이 아니라 "가면 반드시 있다"는 확실함). |
-| **4. 왜 지금** | 수요 쪽: 빵지순례가 대중 취미가 되며 '빵케팅' 신조어까지 생겼는데, 확보 수단만 공백으로 남아 있다. 기술 쪽: AI 코딩 도구로 개발 파트너 없이도 6주 안에 예약 흐름을 붙일 수 있게 됐다 — 작년이라면 기획서에서 멈췄을 규모. (가설) 장기적으로는 쌓인 킵 데이터 위에 LLM을 얹어 "내일 몇 개 구울까"를 제안하는 운영 비서로 확장 가능하나, 데이터 없는 AI 도입은 하지 않는다(순서: 거래 → 데이터 → 자동화). |
-| **5. 사용자** | 1차 사용자는 서울 망원·연남의 중위권 인기 빵집 — 인스타에 품절 공지는 올리지만 예약·웨이팅 앱은 쓰지 않는 곳. 접촉 대상 30곳 리스트업. 2차는 그 가게를 따라다니는 빵지순례형 소비자. (가설) 전국에서 품절이 발생하는 인기 로컬 빵집 약 900곳 — 전체 1.85만 곳의 5% 추산. |
-| **6. 대안·경쟁** | 럭키밀(마감·랜덤박스·할인), 캐치테이블·테이블링(도착한 손님의 줄 관리), 해피오더(프랜차이즈 자체 앱), 인스타 DM(현재 관행). 차별점 한 문장: **"럭키밀이 마감의 랜덤을 판다면, 빵킵은 오픈의 지명을 판다"** — 아침·지명·정가. 웨이팅이 줄을 관리한다면 빵킵은 도착하기 전에 확보한다. |
-| **7. 제품** | 핵심 기능 — ① 사장의 아침 입력을 예약 페이지로 변환 ② 손님의 시간대 선택·**선결제 킵** ③ 품절/마감 원터치. **6주 MVP는 2단계**: (1단계) 내가 콘시어지 운영에 쓸 도구 — 카톡으로 받은 한 줄을 예약 페이지로 만들고 들어온 예약을 가게별로 집계 (2단계) 손님용 예약+결제 페이지. **결제는 샌드박스/테스트 연동**으로 결제창 호출→콜백→성공·실패 분기까지 흐름을 붙여 학습하되, 실 정산 구조는 사업계획서대로 손님→가게 계좌 직접 입금을 유지한다(빵킵은 돈을 만지지 않음). **범위 밖**: 실시간 재고, 실 PG 계약·정산, 네이티브 앱, 회원가입/로그인. |
-| **8. 지속 방법** | 할인 없이 '확보의 값'을 받되, 각 과금은 앞 단계 지표가 증명된 뒤에만 켠다. Phase 0 수수료 0원(이 시기의 수익은 거래 데이터와 사장 신뢰) → Phase 1 소비자 킵 수수료 건당 500원 → Phase 2 가게 거래 수수료 5%(배달앱의 절반) → Phase 3 구독·수요예측 데이터. (가설) 모든 수치는 가정 기반 추산이며, 킵 전환율 5% 미만이면 '오늘의 빵 알림'으로 피벗. |
-| **9. 나(팀)** | 타깃 당사자 — 빵케팅을 직접 겪는 헤비유저라 문제를 몸으로 안다. 캠퍼스 상권 플랫폼 PM으로 소상공인·소비자 양면 시장을 설계해봤다. 22개 출처 교차검증 조사와 반증 가설 중심 검증 설계를 직접 수행 — 아이디어에 취하지 않고 죽여보는 훈련이 돼 있다. 부족한 건 개발 경험이고, 이 6주가 그 보완 과정이다. |
-| **10. 6주 계획** | **3주차** 데이터 모델·화면 설계 + 사장 입력 → 예약 페이지 생성 흐름 1개 완성(가상 빵집 1곳) · **4주차** 예약 접수·집계 붙여서 콘시어지 도구 한 바퀴 돌리기 · **5주차** 손님용 예약 페이지(시간대 선택 → 예약 확정) + **결제 샌드박스 연동**(결제창 → 콜백 → 성공·실패 분기) · **6주차** 배포 + 가상 데이터 시나리오 테스트 + 발표 |
+| **2. 문제** | 당일 제조, 당일 소진이라 손님은 "가면 그 빵이 있는지"를 알 수 없다 → 오픈런으로 시간을 쓰거나, 헛걸음하거나, 원치 않는 차선을 산다. 사장은 품절 문의 응대에 시달리고 품절 후 방문객은 전부 놓친 매출. 지금 이 둘을 잇는 채널은 인스타 스토리(일방향, 예약 불가, 24시간 소멸)와 전화뿐. |
+| **3. 해결책** | 사장은 아침 1회 5분, 오늘의 굽는 시간표와 시간대별 수량만 올린다. 손님은 시간대를 골라 정가 선결제로 '킵'하고 줄 없이 픽업. 핵심은 일부러 **하지 않는 두 가지**. 실시간 재고 입력 요구 없음(사장이 지속 가능해야 하니까), 할인 없음(파는 것은 싼 빵이 아니라 "가면 반드시 있다"는 확실함). |
+| **4. 왜 지금** | 수요 쪽: 빵지순례가 대중 취미가 되며 '빵케팅' 신조어까지 생겼는데, 확보 수단만 공백으로 남아 있다. 기술 쪽: AI 코딩 도구로 개발 파트너 없이도 6주 안에 예약 흐름을 붙일 수 있게 됐다. 작년이라면 기획서에서 멈췄을 규모. (가설) 장기적으로는 쌓인 킵 데이터 위에 LLM을 얹어 "내일 몇 개 구울까"를 제안하는 운영 비서로 확장 가능하나, 데이터 없는 AI 도입은 하지 않는다(순서: 거래 → 데이터 → 자동화). |
+| **5. 사용자** | 1차 사용자는 서울 망원, 연남의 중위권 인기 빵집. 인스타에 품절 공지는 올리지만 예약, 웨이팅 앱은 쓰지 않는 곳. 접촉 대상 30곳 리스트업. 2차는 그 가게를 따라다니는 빵지순례형 소비자. (가설) 전국에서 품절이 발생하는 인기 로컬 빵집 약 900곳. 전체 1.85만 곳의 5% 추산. |
+| **6. 대안, 경쟁** | 럭키밀(마감, 랜덤박스, 할인), 캐치테이블, 테이블링(도착한 손님의 줄 관리), 해피오더(프랜차이즈 자체 앱), 인스타 DM(현재 관행). 차별점 한 문장: **"럭키밀이 마감의 랜덤을 판다면, 빵킵은 오픈의 지명을 판다"**. 아침, 지명, 정가. 웨이팅이 줄을 관리한다면 빵킵은 도착하기 전에 확보한다. |
+| **7. 제품** | 핵심 기능. ① 사장의 아침 입력을 예약 페이지로 변환 ② 손님의 시간대 선택, **선결제 킵** ③ 품절/마감 원터치. **6주 MVP는 2단계**: (1단계) 내가 콘시어지 운영에 쓸 도구. 카톡으로 받은 한 줄을 예약 페이지로 만들고 들어온 예약을 가게별로 집계 (2단계) 손님용 예약+결제 페이지. **결제는 샌드박스/테스트 연동**으로 결제창 호출→콜백→성공, 실패 분기까지 흐름을 붙여 학습하되, 실 정산 구조는 사업계획서대로 손님→가게 계좌 직접 입금을 유지한다(빵킵은 돈을 만지지 않음). **범위 밖**: 실시간 재고, 실 PG 계약, 정산, 네이티브 앱, 회원가입/로그인. |
+| **8. 지속 방법** | 할인 없이 '확보의 값'을 받되, 각 과금은 앞 단계 지표가 증명된 뒤에만 켠다. Phase 0 수수료 0원(이 시기의 수익은 거래 데이터와 사장 신뢰) → Phase 1 소비자 킵 수수료 건당 500원 → Phase 2 가게 거래 수수료 5%(배달앱의 절반) → Phase 3 구독, 수요예측 데이터. (가설) 모든 수치는 가정 기반 추산이며, 킵 전환율 5% 미만이면 '오늘의 빵 알림'으로 피벗. |
+| **9. 나(팀)** | 타깃 당사자. 빵케팅을 직접 겪는 헤비유저라 문제를 몸으로 안다. 캠퍼스 상권 플랫폼 PM으로 소상공인, 소비자 양면 시장을 설계해봤다. 22개 출처 교차검증 조사와 반증 가설 중심 검증 설계를 직접 수행. 아이디어에 취하지 않고 죽여보는 훈련이 돼 있다. 부족한 건 개발 경험이고, 이 6주가 그 보완 과정이다. |
+| **10. 6주 계획** | **3주차** 데이터 모델, 화면 설계 + 사장 입력 → 예약 페이지 생성 흐름 1개 완성(가상 빵집 1곳), **4주차** 예약 접수, 집계 붙여서 콘시어지 도구 한 바퀴 돌리기, **5주차** 손님용 예약 페이지(시간대 선택 → 예약 확정) + **결제 샌드박스 연동**(결제창 → 콜백 → 성공, 실패 분기), **6주차** 배포 + 가상 데이터 시나리오 테스트 + 발표 |

members/yenachang924/project.md

@@ -0,0 +1,22 @@
+# 빵킵 (BbangKeep)
+
+동네 빵집의 오늘 굽는 양을 선결제 픽업 예약으로 바꾸는 서비스.
+사장님은 아침에 한 줄("내일 소금빵 11시 40개, 앙버터 쉬어감")을 적고, 손님은 시간대를 골라 정가로 미리 결제하고 줄 없이 픽업합니다.
+
+- 서비스: https://bbangkeep.vercel.app (데모 계정 `owner@salt.com`, `test@test.com`, 비밀번호 `Test1234!`)
+- 레포: https://github.com/yenachang924/bbangkeep
+- 스택: Next.js 16, Prisma 6, Postgres(Render), Vercel. Spring Boot(Kotlin)로 결제와 재고를 이식하는 중
+
+## 만든 것
+
+- 사장님 AI 비서: 한 줄 문장을 초안 카드로 바꾸고, 사장님이 승인해야 발행. LLM은 게이트웨이 뒤(기본은 룰 파서, 키가 있으면 OpenAI)
+- 재고와 결제: 조건부 원자 UPDATE로 재고 차감, 금액은 서버가 정함, 승인은 멱등, PG는 인터페이스 뒤(모의 PG로 시연)
+- 운영: CI(테스트, 빌드, 브라우저 E2E, API 계약), keepalive, 주간 백업, 픽업 리마인더
+- 문서: ADR 11건, 측정 결과(proof), 인수인계(HANDOFF), OpenAPI 계약
+
+## Claude Code를 어떻게 썼나
+
+- 규약은 AGENTS.md에, 결정은 ADR에, 숫자는 proof에. 에이전트가 읽고 지킬 수 있는 문장으로
+- 마지막 주는 HANDOFF 한 장과 프롬프트로 새 세션을 시작해 PR 단위로 받고, 내가 읽고 머지
+- 스키마 변경, 운영 DB, 시크릿은 승인 없이는 못 건드리게 금지 목록을 먼저 줌
+- MCP 서버로 Claude가 사장님 비서 도구(시간표 조회, 초안, 발행)를 쓰게 함

members/yenachang924/retrospective.md

@@ -0,0 +1,26 @@
+# 빵킵 6주 회고
+
+## 무엇을 만들었나
+동네 빵집의 오늘 굽는 양을 예약으로 바꾸는 선결제 픽업 서비스. 사장님은 아침 한 줄, 손님은 시간대 선택과 결제.
+https://bbangkeep.vercel.app / https://github.com/yenachang924/bbangkeep
+
+## 워크플로우가 바뀐 것
+1. 1주: 내 코드를 Claude에게 채점시켰다. 발견은 Claude, 결정은 나.
+2. 2주: 규칙은 커밋되어야 존재한다. 문서는 해석되지만 훅은 실행된다.
+3. 4주: 맨땅 대신 비슷한 서비스를 먼저 읽었다. 가져올 것, 버릴 것, 달라야 할 것을 적고 설계.
+4. 매주: 결정은 ADR, 수치는 proof. 막힌 곳도 "알려진 구멍"으로 적어두고 넘어갔다.
+5. 6주: HANDOFF 한 장으로 새 세션이 기능을 이어 만들었다. 내 역할은 무엇, 왜, 어디까지.
+
+## 배운 것
+- 제약이 구조를 만들었다. PG가 없어서 PaymentGateway, 키가 없어서 LlmGateway, 채널이 없어서 NotificationGateway. 같은 모양을 세 번 쓰니 내 것이 됐다.
+- AI는 발행하지 않는다. 초안을 쓰고 사람이 승인한다. 결제에서 클라이언트를 믿지 않는 태도를 LLM에도 똑같이 적용했다.
+- 에이전트에게 "하지 말 것"을 먼저 주면 나머지는 빨라도 안전하다.
+- 측정하면 보인다. 느리다고 느낀 것이 콜드스타트가 아니라 리전 거리였다.
+
+## 아쉬운 것
+- 사용자가 아직 없다. 코드보다 노출이 늦었다.
+- 실결제와 알림톡은 키와 사업자등록 뒤에 있다.
+- 빠르게 들어온 코드를 다 읽지 못한 구간이 있다. 그래서 Spring의 approve, cancel은 내 손으로 남겨뒀다.
+
+## 다음
+써 줄 가게 한 곳 찾기. Spring approve, cancel 직접 구현해서 같은 계약 테스트 통과시키기.

members/yenachang924/week01.md

@@ -15,11 +15,11 @@ git도 서툴고 Claude Code도 터미널에 깐 지 얼마 안 된 상태라, 
 
 ## 1. 환경 세팅 체크리스트
 
-- [x] 설치 & 로그인 — `claude --version` → 2.1.215 확인
-- [x] VS Code 연동 — 확장 설치, 터미널을 프로젝트 폴더에서 여는 것부터 배움
-- [x] `CLAUDE.md` 생성 — `/init` 실행 (→ 아래 6번)
-- [x] 첫 대화 & 첫 수정 — 프로젝트 설명 받고 diff 수락까지 (→ 아래 3·5번)
-- [x] git 커밋 위임 — 커밋·push·PR 브랜치 준비까지 맡겨봄 (→ 아래 5·7번)
+- [x] 설치 & 로그인. `claude --version` → 2.1.215 확인
+- [x] VS Code 연동. 확장 설치, 터미널을 프로젝트 폴더에서 여는 것부터 배움
+- [x] `CLAUDE.md` 생성. `/init` 실행 (→ 아래 6번)
+- [x] 첫 대화 & 첫 수정. 프로젝트 설명 받고 diff 수락까지 (→ 아래 3, 5번)
+- [x] git 커밋 위임. 커밋, push, PR 브랜치 준비까지 맡겨봄 (→ 아래 5, 7번)
 
 ## 2. 공식 문서 읽기
 
@@ -65,7 +65,7 @@ git log --oneline -- index.html             → 커밋 다수
 커밋을 맡겼더니 예상 밖의 장면이 이어졌다.
 
 - 커밋 전에 스테이징 상태부터 확인하고, **딱 그 한 줄만** 커밋했다
-- git identity가 설정 안 된 걸 발견하자, 기존 커밋의 author를 조회해 **같은 주소로, 이 저장소에만**(`git config --local`) 설정했다 — 전역 설정은 안 건드렸다
+- git identity가 설정 안 된 걸 발견하자, 기존 커밋의 author를 조회해 **같은 주소로, 이 저장소에만**(`git config --local`) 설정했다. 전역 설정은 안 건드렸다
 - 커밋 메시지에 문자를 잘못 섞은 걸(`@` 혼입) **스스로 발견하고**, "아직 push 전이라 안전하다"는 판단과 함께 `--amend`로 고쳤다
 - push는 자기 판단으로 하지 않고 "원격 반영이 필요하면 말씀해 주세요"에서 멈췄다
 
@@ -78,9 +78,9 @@ Claude도 실수를 한다. 다만 실수를 스스로 감지했고, 고쳐도 
 
 `/init`을 돌리자 CLAUDE.md 작업을 **worktree로 격리**해서 진행했다(내 작업 폴더를 건드리지 않고 딴 방에서 작업). 결과물에서 눈에 띈 것 세 가지.
 
-1. **버그 '사례'가 아니라 '유형'을 문서화했다.** 작업 브랜치 기준에는 GET / 버그가 아직 남아 있었는데, 그걸 알아채고 `GET /` 설명을 특정 파일명에 의존하지 않는 서술로 고쳐 썼다 — "하드코딩된 파일명이 실제 커밋된 페이지와 다르면 루트만 조용히 죽고 API는 다 살아 있어서 놓치기 쉽다"는 식으로.
+1. **버그 '사례'가 아니라 '유형'을 문서화했다.** 작업 브랜치 기준에는 GET / 버그가 아직 남아 있었는데, 그걸 알아채고 `GET /` 설명을 특정 파일명에 의존하지 않는 서술로 고쳐 썼다. "하드코딩된 파일명이 실제 커밋된 페이지와 다르면 루트만 조용히 죽고 API는 다 살아 있어서 놓치기 쉽다"는 식으로.
 2. **주장을 코드 라인과 대조했다고 명시했다.** GREATEST 병합, 5클릭 동기화, 커넥션 풀 설정 같은 기술 서술 전부를 실제 코드와 대조 검증했다고 밝혔다.
-3. **내가 모르던 위험을 문서에 남겼다** — "`index.html`을 로컬에서 열어도 프로덕션 DB를 읽고 쓴다. 쓰기 테스트 전에 API 주소를 localhost로 바꿔라."
+3. **내가 모르던 위험을 문서에 남겼다**. "`index.html`을 로컬에서 열어도 프로덕션 DB를 읽고 쓴다. 쓰기 테스트 전에 API 주소를 localhost로 바꿔라."
 
 첫 대화 요약이 "지금 이 레포의 상태와 문제"를 말한다면, CLAUDE.md는 "다음 세션의 Claude가 헛짚지 않게 하는 지도"에 가까웠다. 같은 레포를 읽고도 산출물의 목적이 달랐다.
 
@@ -110,5 +110,5 @@ Claude도 실수를 한다. 다만 실수를 스스로 감지했고, 고쳐도 
 
 - [ ] `.DS_Store` 제거 + `.gitignore` 추가 커밋
 - [ ] GitHub About의 "SQLite"를 실제(PostgreSQL)에 맞게 수정
-- [ ] 보안 구멍(`/dashboard` 무인증)은 2주차에 권한·훅을 배우면서 처리 예정
-- [ ] 가설 실험: "배포 의도를 CLAUDE.md에 적어두면 Claude의 수정 제안이 달라질까" — A/B로 확인해보고 싶다
+- [ ] 보안 구멍(`/dashboard` 무인증)은 2주차에 권한, 훅을 배우면서 처리 예정
+- [ ] 가설 실험: "배포 의도를 CLAUDE.md에 적어두면 Claude의 수정 제안이 달라질까". A/B로 확인해보고 싶다