[gemini.google.com 접속 → 새 대화]

아래 앱 SPEC을 5가지 관점에서 검토해줘:

1. 보안: 악용할 수 있는 구멍이 있는가?
2. 수익화: Phase 1에서 실제로 돈을 받을 수 있는가?
3. 범위: 혼자 10주 안에 완성 가능한 규모인가?
4. 누락: 없으면 앱이 작동 안 되는 필수 기능이 빠진 게 없는가?
5. DB: N+1 쿼리·보안 취약점·확장성 문제가 있는 설계인가?

추가로:
- LLM 분류 파이프라인의 신뢰성 점검
- 외부 API 4개 의존성 (호출 한도·응답 변경·인증)
- 한국 서비스 특수 (행정구역 코드·PIPA 등)

[SPEC.md v1 전체 붙여넣기 — 약 8KB]

# Gemini 발견 반영은 단순 수정 작업 → Sonnet으로 전환
/model claude-sonnet-4-6
/effort high

SPEC.md를 v2로 패치해줘:

[즉시 반영 4건]
1. §3 DB 스키마 jupjups 테이블:
   + IP 기반 제한: 한 IP에서 1시간 5회+ INSERT 시 reject (트리거)

2. §3-2 LLM 분류:
   + confidence 임계값 0.7 명시
   + confidence < 0.7 필드는 NULL + source_url 보완
   + 운영자 검수 큐 (어드민 페이지에서 확인·승인)

3. §3 + §8:
   + 개인정보 수집 범위: 카카오 ID·자발적 필터만
   + 미수집 명시: IDFA·디바이스 식별자
   + PIPA 준수 명시

4. §6 수익화:
   + 변호 논리: "수익화 시도는 커뮤니티 신뢰를 망친다"
   + Phase 2 시작 명시: "Phase 1 출시 6개월 후"

[PLAN으로 미루는 2건 — SPEC에는 의도만]
5. API 호출 한도 fallback — PLAN G2 (4주차)에서 본격 구현
6. 행정구역 코드 변경 처리 — PLAN R8 리스크 등록부

git add SPEC.md
git commit -m "SPEC v2: Gemini 1차 6건 분류 (즉시 4 + PLAN 2)"

# BUILD.md Day 2 entry:
# [LogOnTable 트레이스]
# 결정: 6건 중 4건 즉시 SPEC v2 + 2건 PLAN.md로 미룸
# 근거: 정직한 우선순위 평가. "신뢰 본질" 직결 4건은 즉시
# 누적 시간: 1.5h (Day 1) + 2h (Day 2) = 3.5h

git add SPEC.md
git commit -m "SPEC v3: ⚖️ E1 회색지대 결정 본격 (줍줍 표현 + 개인정보 최소)"

# BUILD.md Day 3 entry:
# 결정: 두 회색지대 모두 4단계 프레임 적용
# 부작용 ①: 외부 노출 4자리 일관 의무 발생 (권3에서 본격)
# 누적 시간: 3.5h (Day 1~2) + 3h (Day 3) = 6.5h