# Zan Sol — Project Context > **이 문서의 역할:** 팀 프로젝트 의사결정의 단일 진실 원천(Single Source of Truth). AI 에이전트는 새로운 제안·답안 작성 전에 반드시 이 문서를 참조한다. 팀원은 챗봇에 프로젝트를 설명할 때 이 문서를 통째로 붙여넣는다. > > **사용 규칙:** Section 1(논의 큐)는 **확정되지 않은 사항**이다. 확정 사실로 취급 금지. Section 5(의사결정 로그)의 결정과 새 제안이 충돌하면 충돌을 명시적으로 드러낼 것. --- ## 1. TEAM DISCUSSION QUEUE (열린 논의) _(현재 열린 논의 없음 — 새 항목이 생기면 아래 양식으로 추가)_ ### 논의 항목 추가 양식 ```markdown ### [논의 제목] - 맥락: 이 논의가 왜 필요한가 - 선택지: A안 / B안 - trade-off: 각 선택지의 장단점 - 관련된 기존 결정: (Section 5 연관 항목) - 결정 방식: (회의 / 투표 / PM 결정 / 근거 수집 후 결정) - 데드라인: YYYY-MM-DD - 제안자: 이름 ``` --- ## 2. HOW TO USE THIS DOCUMENT (For AI) 당신은 Zan Sol 팀원이 이 문서를 챗봇에 붙여넣어 당신과 대화하고 있다. 답변 시 다음 원칙을 지킨다. 1. **기존 결정 먼저 확인하고 제안한다.** 새 아이디어가 Section 5와 충돌하면 충돌을 명시 (예: "이 제안은 5-3과 충돌합니다"). 2. **모든 주요 제안은 수업 프레임워크(Section 4)에 매핑한다.** 매핑되지 않는 제안은 flag. 3. **V1/V2를 엄격히 구분한다.** 이번 학기 결과물은 V1. V2 얘기가 나오면 "V2 전용, 현재 스코프 아님"으로 표시. 4. **구체 수치는 이 문서의 정의를 따른다.** 30초/2분/500세션/5회/85.3% 등은 본문에 근거가 있으며, 임의로 바꾸지 말 것. 5. **모든 것을 Product Goal로 되돌린다.** "이것이 사용자가 도피 순간 복귀하도록 돕는가?" 질문에 답할 수 없는 제안은 의심. 6. **구체성 요구를 거부하지 않는다.** "개선한다" 같은 모호한 표현 대신 "어떻게·얼마나·무엇을 근거로"를 항상 요구. 7. **제안보다 먼저 질문한다.** 모호한 요청에는 가정하지 말고 물어본다. --- ## 3. CORE IDENTITY ### 3-1. 한 줄 정의 **Zan Sol (잔솔)** — 집중 세션 중 딴짓을 자동 감지하고, 유저를 긁는 잔소리로 즉시 개입하는 개인용 자기조절 앱. ### 3-2. Product Goal > "사용자가 혼자 있는 사적 공간에서 관찰자 없이 공부하다가 스마트폰으로 도피할 때, **그 순간 즉시 개입하여** 원래의 집중 과업으로 복귀하도록 돕는 시스템이다." **핵심 해석:** - **"복귀"가 측정 지표**이지 "공부량"이 아님 (공부량은 측정 불가 영역) - **"그 순간"이 1초 이내**여야 함 (Nielsen 기준 = 사고 흐름 한계) - **"혼자 있는 환경"이 범위**이지 도서관 등 관찰자 존재 환경은 out of scope ### 3-3. 기본 정보 | 항목 | 값 | | --- | --- | | 플랫폼 | Android 단일 (iOS는 핵심 API 미지원) | | 타겟 사용자 | 관찰자 없이 혼자 공부하는 경희대 대학생 | | 이번 학기 결과물 | V1 (규칙 기반, ML 없음) | | 개발 기간 | 16주 | | 팀 규모 | 4인 | --- ## 4. 수업 프레임워크 적용 매핑 (COURSE FRAMEWORK MAPPING) > 이 섹션의 중요성: 교수님이 평가하는 것은 "혁신적 제품"이 아니라 **"수업에서 배운 원칙을 프로젝트에 명시적으로 적용했는가"**이다. 과제 작성/제안 시 반드시 이 매핑을 드러낸다. 자세한 수업 원칙·과제 포맷은 [`course/`](course/) 폴더 참조. 여기서는 우리 프로젝트와의 매핑만 기록한다. ### 4-1. Data·Model 8-Step 매핑 | 수업 Step | 우리 프로젝트 적용 | | --- | --- | | Step 1: Product Goal 먼저 | 섹션 3-2에서 한 문장 정의 완료 | | Step 2: Input/Output 정의 | V1 Input=앱 실행 이벤트, Output=잔소리 문구 선택 / V2 Input=컨텍스트 feature, Output=복귀 확률 높은 문구 | | Step 3: 데이터 수준 분류 | **현재 No Data → V1 운영으로 Weakly Labeled 생성 → V2에서 Labeled 활용** (섹션 7 참조) | | Step 4: Generative Model 체크 | 생성형 불필요 (잔소리 문구는 사전 풀에서 선택) | | Step 5: End-to-End vs Simple | **Simple Solution 선택** (이벤트 기반 + 로컬 완결 + 규칙 기반) | | Step 6: 알고리즘이 되어보기 | 학습상담사·고교 교사의 개입 절차를 규칙으로 옮김 (섹션 12) | | Step 7: Feature 기반 단순 모델 | V1은 규칙, V2는 분류/Bandit | | Step 8: 데이터 부족 시 framing 변경 | **원래 목표(개인화 추천)를 V1에선 규칙으로 framing 전환** — Step 8 직접 적용 사례 | ### 4-2. 수업 핵심 메시지와 우리의 대응 | 수업 원칙 | 우리 프로젝트에서의 증거 | | --- | --- | | "ML 기법에서 시작하지 마라. Product Goal부터." | 섹션 3-2에서 Product Goal 정의 후 모든 의사결정 전개 | | "주제·데이터·모델이 논리적으로 맞물린 프로젝트가 좋다." | No Data → Rule-based → 데이터 수집 → V2 ML의 일관된 논리 체인 | | "가장 화려한 모델보다 이번 학기에 구현 가능한 모델" | V1 규칙 기반 선택 (생성형 LLM 등 복잡 모델 회피) | | "모델 성능만이 아니라 Business Metric" | 섹션 6에서 복귀율·D7 리텐션 명시 | | "사람이 직접 풀면 어떤 기준을 쓸지 먼저 생각하라" | 전문가 인터뷰로 Heuristic 구상 → V1 루프로 구현 | --- ## 5. 핵심 의사결정 로그 > 각 결정: **DECISION / WHY / COURSE LINK / CONTEXT** 구조. ### 5-1. 플랫폼: Android 단일 **DECISION:** iOS 개발 안 함. **WHY:** - UsageStatsManager, SYSTEM_ALERT_WINDOW, Foreground Service, AccessibilityService 등 핵심 API가 전부 Android 전용 - iOS는 기술적으로 불가능한 영역 (백그라운드 앱 감지 + 오버레이 팝업 불가) **COURSE LINK:** Step 5 (Simple Solution — 이번 학기 구현 가능 범위) **CONTEXT:** 타겟이 경희대 대학생이고 한국 Android 점유율 높아 시장 제약 작음. ### 5-2. 딴짓 감지 구조: Event-Polling Hybrid **DECISION:** AccessibilityService 이벤트(Reactive) + 30초 주기 폴링(Proactive) 하이브리드. **WHY:** - 이벤트 단독 → 알림창 조작 등으로 누락 시 복구 불가 - 폴링 단독 → 주기 간격만큼 감지 지연 - 결합 시 **실시간성 + 안정성** 동시 확보 | 계층 | 원리 | 역할 | | --- | --- | --- | | Reactive Layer | AccessibilityEvent (TYPE_WINDOW_STATE_CHANGED) | 앱 진입 찰나 **<0.1초** 포착 → 1차 개입 즉시 | | Proactive Layer | Handler 루프 **30초 주기** 자가 진단 | 연속성 보장, 시계열 수집, 2차/3차 에스컬레이션 트리거 | **WHY 폴링 주기 30초인가:** - 1초는 과도: 배터리 소모 크고 초 단위 닦달 불필요 - 30초는 screenertia 연구의 sticky 임계값과 일치 → 2차 개입 타이밍과 맞물림 - 이벤트 누락 시 복구 지연 최대 30초 (허용 가능) - V2 LSTM 학습용 시계열 해상도로도 충분 **COURSE LINK:** Step 6 (알고리즘이 되어보기) ### 5-3. V1에 모델을 쓰지 않는 이유 **DECISION:** V1은 규칙 기반으로만 동작. ML 없음. **WHY:** 1. 딴짓 판정은 "사용자가 지정한 앱 리스트에 있는가" 단순 매칭으로 충분 2. 잔소리 개인화가 의미를 가지려면 사용자당 최소 30회 개입 데이터 필요 → 초기엔 없음 3. 규칙만으로 product goal이 완전히 동작 4. 초기엔 **서비스를 돌리며 데이터를 쌓는 것이 우선** **구조적 장점:** - Speed: 모델 추론 시간 변수 자체가 없음 → 구조적으로 빠름 - Freshness: 재학습 부담 없음 → 사용자 직접 갱신으로 최신성 유지 **COURSE LINK:** Step 8 (framing 변경) + Step 5 (Simple Solution) + Step 7 (Feature 기반 단순 모델부터) ### 5-4. V2 ML 모델 2개 **DECISION:** V2에서 두 개의 ML 모델 도입. **모델 ①: 딴짓 예측 모델** | 항목 | 내용 | | --- | --- | | 태스크 | Binary Classification | | 풀려는 문제 | 딴짓 발생 직전 선제 개입 | | Input | 시간대, 요일, 마감 잔여일, 세션 경과 시간, 과거 딴짓 이력 | | Output | 향후 10분 내 딴짓 발생 확률 | | 모델 후보 | Logistic Regression → Gradient Boosted Trees | | 필요 데이터 | 최소 500세션 | **모델 ②: 잔소리 개인화** | 항목 | 내용 | | --- | --- | | 태스크 | Contextual Multi-Armed Bandit | | 풀려는 문제 | 사용자마다 잘 긁히는 잔소리 스타일이 다름 | | Input | 잔소리 유형(행동제안/공감/압박), 과거 복귀 이력 | | Output | 이 사용자에게 지금 가장 복귀 확률 높은 스타일 | | 모델 후보 | Thompson Sampling | | 필요 데이터 | 사용자당 최소 30회 개입 이벤트 | **V1 → V2 전환 조건:** 누적 500세션 + 활성 사용자 50명 + V1 복귀율 정체 확인 시. **COURSE LINK:** Step 2, Step 7, Step 6 (Feedback Loop) ### 5-5. 개인용 + 익명 카운터 (팀 기능은 Out of Scope) **DECISION:** - 팀 기여도/소셜 기능: **Out of Scope** - "경희대 N명 집중 중" 익명 카운터: **P2 유지** **WHY:** 1인 사용자가 잔소리 개입만으로 핵심 가치를 경험해야 서비스 성립. 단, 익명 카운터는 그룹 구성 없이도 "혼자가 아니라는 감각" 제공. **COURSE LINK:** 고객 니즈 파악 (서베이 n=34가 개인용 도피 문제를 85.3% 검증) ### 5-6. 잔소리 에스컬레이션 구조 (심리학 근거) **DECISION:** 각 단계가 **다른 심리 메커니즘**을 활용하는 3단계. 단순 "강도 올리기" 아님. | 경과 시간 | 단계 | 예시 문구 | 작동 메커니즘 | | --- | --- | --- | --- | | **즉시 (0초)** | 행동 제안 | "자료 하나만 찾아봐" | **행동활성화(Behavioral Activation):** 행동이 동기를 이끈다 | | **30초** | 난이도 낮추기 + 공감 | "막막하지? 한 줄만 써봐" | **자기효능감(Bandura):** 1차 실패 후 mastery experience 유도 | | **2분 (120초)** | 압박 | "내일의 너한테 미안하지 않을까?" | **심리적 저항 회피(Reactance):** 여러 실패 후 자기 실망감 누적되어 효과적 | **WHY 이 시간 간격인가:** - 1차 즉시: Nielsen "1초 = 사고 흐름이 끊기지 않는 한계" → 도피 흐름을 끊을 수 있는 한계 - 2차 30초: Siebers et al. (2024) "screenertia" — 30초가 짧은 체류와 sticky 체류의 분기점 - 3차 2분: Mark (2023) 주의 전환 중앙값 40초의 3배 — 완전히 sticky 상태. 약한 개입 불가 **WHY 행동제안 → 공감 → 압박 순서인가:** 사용자는 "해야 하는 거 알지만 못 하는" 상태(의식 명확). 공감을 먼저 두면 방해로 느낌. 행동제안 실패 후에야 감정이 막혔다는 신호. 압박은 반발 방지를 위해 최후 수단. **COURSE LINK:** Step 6 (알고리즘이 되어보기), 도메인 전문가 실습 ### 5-7. 메모리 버퍼 구조 (Room DB 제거) **DECISION:** 세션 중 데이터를 Kotlin 메모리 버퍼에 보관, 네트워크 연결 시 주기적 서버 flush. Room DB 쓰지 않음. **WHY:** 집중 세션 중 네트워크 끊김 드묾. 딴짓 감지+오버레이 팝업은 네트워크 없이 로컬 동작. Room ↔ MySQL 동기화 로직·스키마 이중 관리는 4인 팀 16주 내 깔끔하게 어려움. 메모리 버퍼 + flush 실패 시 SharedPreferences 폴백으로 충분. **COURSE LINK:** Step 5 (Simple Solution) ### 5-8. 시스템 아키텍처 **클라이언트 (Android):** | 영역 | 기술 | 역할 | | --- | --- | --- | | 유저뷰 | Lovable (React + TypeScript) | UI 전체. 세션 시작, TODO, 리포트, 카운터 | | 디바이스 코어 | Kotlin 네이티브 | Foreground Service, AccessibilityService, 오버레이, 메모리 버퍼 | | 통신 | JS Bridge | 양방향 | **서버 (AWS):** | 컴포넌트 | 역할 | V1/V2 | | --- | --- | --- | | API Server (EC2, FastAPI) | 세션 로그, TODO CRUD, 리포트, FCM 요청 | V1 | | Database (RDS, MySQL) | 구조화 데이터 | V1 | | ML Server (별도 EC2) | 추론 요청 | V2 | | S3 Bucket | 모델 파일, 문구 풀 | V2 | **핵심 설계 원칙:** 핵심 루프(딴짓 감지 → 팝업)가 **디바이스 로컬에서 완결**. 네트워크 지연이 product goal에 영향 없음. ### 5-9. 세션 시간: 목표 없음, 경과 시간만 **DECISION:** 사용자가 세션 시작 전 목표 시간을 설정하지 않는다. 화면에는 **경과 시간(elapsed)** 만 표시. 종료는 사용자의 [세션 종료] 명시 행위로만 발생. **WHY:** - Product Goal이 "복귀"이지 "정해진 시간 채우기"가 아님. 카운트다운은 Pomodoro류의 의지 전제 모델 — 우리 가설(의지력 부족)과 충돌 - 목표 시간 미달 시 "실패감" 발생 → 다음 세션 진입 마찰 ↑ → 복귀율 저하 - 누적 집중 시간이 자연스러운 Supporting Metric **구조적 함의:** - 세션 진행 화면에 진행률 바 없음 → 화면 더 단순 - 세션 완료 리포트는 "목표 대비 달성률" 대신 "이번 세션 분 + 오늘 누적 분 + 복귀율" 표시 - Supporting Metric "세션 완료율"은 본 결정으로 폐기, **"일일 누적 집중 시간"** 으로 대체 (6-2 갱신) **COURSE LINK:** Step 1 (Product Goal 먼저), Step 5 (Simple Solution) **CONTEXT:** 0428 UX 설계 과제(섹션 13-6) 작성 중 명시적으로 정리된 결정. --- ## 6. BUSINESS METRIC (Product Goal 측정) ### 6-1. Primary Metric: 복귀율 (Return Rate) **정의:** 딴짓 앱 실행 후 잔소리 개입을 받은 사용자가 **5분 이내에 원래 집중 세션으로 돌아온 비율**. **수식:** (잔소리 개입 후 5분 이내 집중 세션 복귀 건수) / (잔소리 개입 발생 건수) × 100 **WHY:** Product goal("복귀 유도")을 가장 직접 측정. 5분 기준은 screenertia 연구의 주의 완전 전이 시간대. ### 6-2. Supporting Metrics | 지표 | 정의 | 왜 필요한가 | | --- | --- | --- | | 일일 누적 집중 시간 | 하루 동안의 세션 경과 시간 합계 | Product goal 최종 결과 간접 측정 (목표 시간 없으므로 완수율 대신 누적량 사용 — 5-9) | | D7 리텐션 | 가입 후 7일 활성 비율 | 잔소리 과잉 → 앱 삭제 감지 | | 에스컬레이션 단계별 복귀율 | 1/2/3차 각 단계 복귀율 | 어느 단계가 효과적인지 검증 | | 잔소리 문구별 복귀율 | 문구별 성공률 | 문구 로테이션 + V2 Bandit 보상 | --- ## 7. 데이터 진화 경로 (DATA LEVEL EVOLUTION) ### 7-1. 현재 → V1 → V2 진화 | 시점 | 데이터 수준 | 상태 | | --- | --- | --- | | **프로젝트 시작** | **No Data** | 사용자 행동 기록 없음 | | **V1 출시 직후** | **Weakly Labeled** | 세션 로그, 팝업 노출, 복귀 여부. 간접 신호 | | **V1 누적 500세션 / 활성 50명** | **Labeled** | 복귀율 기반 "어떤 문구가 먹혔는가" pair | | **V2 출시 이후** | **Ground Truth** | Bandit 피드백 루프로 지속 학습 | ### 7-2. V1 = V2의 데이터 수집 파이프라인 - V1의 규칙 기반 판정 = **auto-labeling 메커니즘** - V1의 세션/개입/복귀 로그 = **V2 모델 학습 데이터셋** - V1 운영 자체가 Step 6 (feedback loop)의 구현 --- ## 8. 현재 스코프 (이번 학기 V1) ### 8-1. In Scope | 우선순위 | 기능 | | --- | --- | | P0 | 개인용 집중 세션 + AccessibilityService 딴짓 감지 + 잔소리 에스컬레이션 | | P0 | TODO/마감일 등록 + 마감 기반 푸시 | | P0 | 마이크로 태스크 제안 (복귀 마찰 최소화) | | P1 | 개인 집중 리포트 (일별/주별 집중 시간, 복귀율) | | P2 | "지금 집중 중인 경희대 학생 N명" 익명 카운터 | ### 8-2. Out of Scope | 항목 | 이유 | | --- | --- | | 팀 기여도 시스템, 팀 게이지 | 개인용 검증 선행 필요 | | 경희대 전체 랭킹, 커스텀 그룹 | 사용자 규모 확보 후 의미 있음 | | V2 ML 모델 | V1 데이터 축적 후 | | iOS 버전 | 기술적 불가 | | 다중 기기 동기화 | V1은 단일 기기 전제 | --- ## 9. 핵심 용어 사전 | 용어 | 정의 | | --- | --- | | 유저뷰 | Lovable 웹뷰 영역 (React + TypeScript) | | 디바이스 코어 | Kotlin 네이티브 기기 레벨 동작 | | JS Bridge | 유저뷰 ↔ 디바이스 코어 통신 | | 딴짓 앱 | 온보딩 시 직접 지정한 방해 요소 앱 | | 잔소리 에스컬레이션 | 딴짓 지속 시간에 따른 3단계 개입 (즉시/30초/2분) | | 유저를 긁는 모델 | V2의 개인화 ML 모델 (Contextual Bandit) | | 복귀 | 딴짓 앱을 닫고 집중 세션으로 돌아오는 행동 (Primary Business Metric) | | V1 | 이번 학기 결과물 (규칙 기반, ML 없음) | | V2 | 데이터 축적 후 도입 (딴짓 예측 + 잔소리 개인화) | | Reactive Layer | AccessibilityService 이벤트 기반 실시간 감지 | | Proactive Layer | 30초 주기 폴링 (연속성 + 시계열 수집) | | screenertia | 스크린에 오래 머물수록 빠져나올 확률이 감소하는 현상 (Brinberg et al. 2022) | | sticky 세션 | 30초 이상 고몰입 세션 (Siebers et al. 2024) | | task aversion | 과제 회피 성향 (Steel & König 2006) | | Weakly Labeled Data | 완벽한 정답 아니지만 간접 신호가 있는 데이터 | --- # [BACK] ACCUMULATED CONTEXT --- ## 10. 왜 이 문제인가 ### 10-1. 근본 원인 | 원인 | 설명 | | --- | --- | | ① 과제 모호성 → task aversion | 마감 임박할수록 막막 → 즉각 보상(SNS) 도피 | | ② 관찰자 부재 → 제동 장치 없음 | 혼자 있는 환경엔 도서관 같은 억제력 없음 | ### 10-2. 기존 앱이 실패한 이유 | 앱 | 실패 원인 | | --- | --- | | 스크린타임 | 사후 리포트만 제공 → 도피 "그 순간"에 개입 못함 | | Forest | 사용자가 먼저 켜야 → 의지 있는 사람에게만 작동 | | 공통 한계 | **자기조절 실패자에게 자기조절 전제 도구 제공** | ### 10-3. 우리의 차별점 - 의지력 대신 **무시할 수 없을 만큼 긁히는 잔소리**를 억제력으로 사용 - 관찰자 부재 환경에서 "잔소리하는 누군가"의 감각을 시스템이 대체 - 시스템이 "먼저 감지"하고 "자동 개입" → 사용자 의지 불필요 --- ## 11. 사용자 조사 결과 (경희대 34명 서베이) ### 11-1. 정량 수치 | 검증 항목 | 결과 | 해석 | | --- | --- | --- | | 스마트폰 도피 경험 | **85.3%** | 도피가 예외가 아니라 기본값 | | 잔소리 앱 사용 의향 | **~70%** | 10명 중 7명 긍정 | | 기존 자기관리 앱 미사용 | **52.9%** | 기존 앱이 시장에 침투하지 못함 | | 프리미엄 지불 의향 | **~35%** | 1,000~2,000원이 현실적 상한 | | 딴짓 지속 시간 (과반수) | **10~30분** | 문제 크기 정량화 | **핵심 해석:** "문제는 충분히 크고(85%), 기존 솔루션은 비어 있으며(52.9% 미사용), 우리 컨셉에 대한 수요가 존재한다(70%)." **표본 한계:** n=34 소규모 탐색적 조사. 대표성 주장보다 **방향성 확인 수준**으로 해석. --- ## 12. 전문가 벤치마킹 (3그룹) | 그룹 | 얻을 지식 | 핵심 질문 | | --- | --- | --- | | 경희대 교수학습지원센터 학습상담사 | 이론 | 어떤 순서로 개입하면 돌아오는가? | | 고등학교 담임/자습감독 교사 | 실전 | 어떤 말이 먹히고 어떤 말에 반항하는가? | | 자기조절 잘하는 경희대 4.0+ 선배 | 역방향 | 도피를 안 하는 사람은 어떤 규칙을 쓰는가? | --- ## 13. 과제별 의사결정 근거 (축적된 논리) ### 13-0. Lecture 2 — 주제 선정 + AI 기획안 (학기 시작점) **핵심 프레이밍:** Zan Sol이라는 주제 자체가 만들어진 단계. 이후 모든 과제의 토대. **주제 선정 3원칙 적용:** - ① 가까이 있는 문제: 팀원 본인이 겪는 도피 행동 - ② 익숙한 문제: 경희대 학생 일상 맥락 — 사용자 = 자기 자신 - ③ 전문가 해결 프로세스 떠올릴 수 있을 것 — 학습상담사·교사·자기조절 잘하는 선배 (이후 03 과제로 확장) **중요한 명시:** 지시서가 "ML이 최종 결과물에 포함되지 않더라도 다른 부분이 충실하면 감점하지 않겠습니다"라고 명시 + Version 1(ML 없는 기본 앱) / Version 2(ML 추가 확장) 분리를 예시로 제시. → **우리 V1(규칙)/V2(ML) 구조의 직접적 출처.** 5-3 결정의 정당성 근거. **AI 활용 R-O-C-O 프롬프트 프레임:** Role / Objective / Context / Output. 본 레포의 CONTEXT.md를 챗봇에 통째로 붙여넣는 운영 방식이 이 프레임과 정합 (Section 2 "How to use this document"). **기획안 5항목 → 이후 과제로의 연결:** | 기획안 항목 | 후속 과제 | |---|---| | 해결하려는 문제 | → 10·11 (왜 이 문제, 사용자 조사) | | 만들고 싶은 어플리케이션 | → 06 UX 설계 | | 문제 해결 절차 (Procedure) | → 03 도메인 전문가 heuristic | | 머신러닝 요소 | → 01 Data·Model 8-Step | | 전문가 벤치마킹 | → 03 도메인 전문가 (3그룹 인터뷰) | ### 13-1. 과제 "Data와 Model 결정" **핵심 프레이밍:** "현재 데이터 없음 → 규칙 기반으로 서비스를 돌려서 데이터를 자체 생성 → ML로 확장" **논리:** - V1이 서비스인 동시에 **V2의 데이터 수집 파이프라인** - Rule-based → Bandit hybrid - 후보 2번(Classification, 500세션 필요)과 후보 3번(Bandit, 30회 개입 필요)을 수치로 기각 - "규칙 기반 판정이 곧 auto-labeling"이라는 데이터 수준 통찰 **교수 피드백 반영:** - V2 output에서 bandit과 classification 분리 - 설문 n=34 한계 명시 - 문구 분류는 독립 model framing이 아닌 보조 전처리로 재배치 ### 13-2. Freshness 과제 **재정의:** freshness를 "모델 최신성"이 아니라 **"product goal이 시간에 걸쳐 달성되는가"**로 재프레임. **3축 프레임:** | 축 | 변할 수 있는 요소 | 대응 | | --- | --- | --- | | ① 감지 | 딴짓 앱 리스트, OS 정책 | 신규 앱 10분 체류 시 자동 등록 제안 | | ② 개입 | 잔소리 면역, 학기 주기 맥락 | 문구 5회 노출 시 로테이션, 학기당 10개 신규 추가 | | ③ 서비스 | AccessibilityService 유지 | UsageStatsManager 폴백 준비 | **학기 주기 대응:** 모델 재학습 아님. **사용자가 학기마다 직접 자신의 일정을 입력**하는 개인화. **결론:** "사용자가 freshness 유지의 주체로 참여하는 구조" ### 13-3. 도메인 전문가 활용 (0416 과제) **핵심 프레이밍:** 학습상담사(이론) + 고등학교 교사(실전) + 4.0+ 선배(역방향) 3그룹에서 "도피 학생을 돌아오게 만든 경험"을 추출 → V1 핵심 루프 = 사람의 판단 절차를 규칙으로 옮긴 것. **Heuristic 초기 버전:** - 5분 (공감) → 15분 (긁기 시작) → 30분 (제대로 긁기). 3단계 무시 시 다음 세션 난이도 하향. - 간격 5/15/30분의 근거: 자체 설문(경희대 34명) "딴짓 지속 10~30분" 분포의 초기·중반·상한. **사람 판단 개입 지점:** 각 단계에서 "이 사용자에게 어떤 스타일이 먹히는가" 선택. V1은 일반화하여 랜덤, V2에서 Contextual Bandit 자동화. **이후 진화:** 5/15/30분은 04 Speed 과제·14 메타 레슨에서 **즉시 / 30초 / 2분**(Nielsen 1초 + Siebers screenertia 30초 + Mark 40초의 3배)으로 단축. 근거 축이 *"딴짓 지속 시간"* → *"사고 흐름을 끊을 수 있는 한계"* 로 reframe. 현재 5-6에 최종본. ### 13-4. Speed 과제 (0417) **재정의:** speed를 "몇 ms"가 아니라 **"도피 시작부터 몰입 전까지의 골든 타임 안에 개입이 성사되는가"**로 재프레임. **강점:** - "speed 리스크가 집중된 지점이 **단 하나뿐**" (단일 크리티컬 패스) - 그 단일 패스마저 **이벤트 기반(폴링 없음) + 로컬 완결(네트워크 없음) + 규칙 기반(모델 없음)** 세 가지 강점 중첩 **1초 기준의 근거:** Nielsen "사고 흐름이 끊기지 않는 한계"를 우리의 "도피 흐름을 끊을 수 있는 한계"와 매핑. **결론:** "단순함 자체가 speed의 가장 강력한 보장" ### 13-5. 라벨링·공개 구현 탐색·기존 데이터 조사 (0421 과제) **핵심 발견: 잔소리 선택은 4축 공간의 최적점 탐색 문제다.** | 축 | 정의역 | 의미 | | --- | --- | --- | | 에스컬레이션 단계 | 1차(즉시) / 2차(30초) / 3차(2분) | 잔소리를 몇 번 무시했는가 | | 앱 카테고리 | 영상 / SNS / 메신저 / 게임 / 웹서핑 | 어떤 딴짓인가 | | 현재 모드 | 공부 / 휴식 | 집중 세션 중인가 쉬는 중인가 | | 디데이 | D-3 / D-7 / D-14 / D-30+ | 마감까지 | 각 축 정의역이 4개만 되어도 256개(4^4) 조합. 대표 10개를 직접 라벨링하여 규칙의 씨앗을 만듦. **도출된 4가지 핵심 패턴:** 1. **디데이가 가장 강력한 조절 변수.** D-3이면 대부분 강력/공감, D-30+이면 대부분 제안 또는 개입 보류. 2. **앱 카테고리별 "몰입 깊이"가 다르다.** 영상/게임은 빠르게 강도, SNS/메신저는 공감형. 3. **휴식 모드에서는 개입 정당성이 약하다.** 같은 앱이라도 모드에 따라 강도 크게 달라야. 4. **메신저는 특수 카테고리.** 일방적 차단 시 사회적 비용. **발견된 challenge:** - "제안/공감/강력"의 경계 모호 - 휴식 모드 개입 기준 미확립 - 카카오톡 등 용도 혼재 앱 분류 한계 (V1 해결 불가) **유사 구현:** | 사례 | 참고점 | | --- | --- | | DigiPaws (오픈소스 앱 차단기) | 앱별 차단 전략, Anti-Uninstall | | NudgeRank (KDD 2024) | 맥락 기반 개인화 nudge 추천 (110만 명 실증) | | Duolingo 잔소리 푸시 | 에스컬레이션 톤 설계 | **기존 데이터/코드:** | 자원 | 활용 | | --- | --- | | Kaggle: Smartphone Usage and Behavioral Dataset | 카테고리 분류 현실성 검증 | | GitHub: contextualbandits | V2 Bandit 구현 직접 활용 | --- ### 13-6. 0428 UX 설계 과제 (IA · User Flow · Wireframe) **핵심 산출물:** 메뉴 트리(상위 5개) + 핵심 사용자 목표 1개의 Flow + Wireframe 7개 + Wire Flow + 설명문서. PDF 1건 제출. **메뉴 트리 (V1):** 홈 [P0] · 세션 [P0] · 할 일 [P0] · 리포트 [P1] · 설정 [P0]. P2(익명 카운터)는 홈 한 줄로만 표기. V2/팀 기능 트리상 부재. **핵심 사용자 목표:** "집중 세션을 시작하고, 딴짓을 시도했을 때 잔소리 개입을 받아 원래 세션으로 복귀한다." Product Goal 그 자체. **Wireframe 7개:** 홈 / 세션 진행 / 잔소리 1차 / 잔소리 2차 / 잔소리 3차 / 세션 완료 리포트 / 딴짓 앱 관리. **프레이밍 포인트:** - **잔소리 오버레이를 메뉴 트리 외부 OS 레이어 노드로 표기** (SYSTEM_ALERT_WINDOW). 일반 UX 과제와 가장 다른 지점이며, 우리 차별점. - 화면 구조 자체에 5-6 에스컬레이션 심리 메커니즘 매핑: 1·2차는 [잠깐 닫기] 가능 / 3차는 닫기 제거 + 명시적 "그래도 무시"만 → Reactance 회피. - **세션 시간 목표 없음 → 경과 시간만** (5-9 결정 도출). **4인 분담 입력값 확보:** 7개 화면 정의로 김민성(디바이스 코어, 오버레이) / 유저뷰 React 화면 분담 가능. --- ## 14. 메타 레슨 (평가 프레이밍 진화) ### 원칙 1: 과제 질문을 Product Goal 관점으로 재정의 예: "모델 최신성" → "서비스가 product goal 달성 가능한가". 프레임을 바꾸면 우리 강점이 살아난다. ### 원칙 2: V1 중심, V2는 마지막 한 줄로만 이번 학기 결과물은 V1이므로 V1에 집중. ### 원칙 3: 대응 방안은 "한다"가 아니라 "어떻게·얼마나·왜" 구체화 숫자(30초, 5회, 10분)와 구체적 메커니즘 포함. ### 원칙 4: 우리 서비스의 심플함을 강점으로 - Speed = 단일 크리티컬 패스 - Freshness = 재학습 부담 없음 - **단순함 자체가 구조적 이점** ### 원칙 5: 근거 제시 시 우리 맥락 연결 필수 "Nielsen 가이드라인"만 쓰지 말고 "왜 우리 상황에 적용되는가"까지. ### 원칙 6: 수업 프레임워크에 명시적으로 매핑 교수님은 혁신이 아니라 **"수업에서 배운 걸 적용했는가"**를 본다. --- ## 15. 팀원 역할 분담 | 팀원 | 담당 영역 | | --- | --- | | 김우진 (PM) | 기획안, 과제 프레이밍, 전체 통합, CONTEXT 관리 | | 유준혁 | 경쟁 앱 분석 (Forest, Flipd, 열품타) | | 이호준 | 유저 리서치 (서베이, 전문가 인터뷰) | | 김민성 | 기술 검증 (실기기 POC, AccessibilityService) | --- ## 16. 주요 레퍼런스 ### 학술 **심리학/자기조절:** - Jin, Y. et al. (2024). "Smartphone Distraction and Academic Anxiety." *Behavioral Sciences*, 14(9), 820. - Steel, P. & König, C. (2006). "Integrating Theories of Motivation." — task aversion - Zimmerman, B. (2000). "Self-Efficacy." - Bandura, A. — 자기효능감 (2차 개입 근거) - Brehm, J. — Reactance theory (3차 개입 근거) - 행동활성화 이론 — 1차 개입 근거 **주의/몰입:** - Siebers, T. et al. (2024). "The effects of fragmented and sticky smartphone use" — screenertia, 30초 sticky 임계값 - Brinberg et al. (2022). screenertia 원논문 - Mark, G. (2023). 평균 주의 전환 시간 47초, 중앙값 40초 ### 기술 - Android Developers: AccessibilityService, UsageStatsManager, Foreground Service - dontkillmyapp.com — OEM별 백그라운드 정책 - Nielsen 응답 시간 가이드라인 (0.1/1/10초) ### 경쟁 Forest, Flipd, 열품타 --- ## 17. 문서 메타 - **관리자:** 김우진 (PM) - **저장 위치:** GitHub (`xhae123/sds-pm`) + 팀 공유 - **업데이트 규칙:** 새 결정 확정 시 Section 5 추가 (+ COURSE LINK 명시). 미확정 논의는 Section 1. # 축적된 메타 레슨 > 프로젝트가 진행되면서 "다음 번에도 기억해야 하는 교훈"을 여기에 1~2줄씩 쌓는다. CONTEXT.md는 현재 상태, MEMORY.md는 **과거로부터 배운 것**. > > 새 레슨 추가 시: `## YYYY-MM-DD — <제목>` + 1~3 bullet. 출처(어느 과제/회의/사건). --- ## 2026-03-31 — Lecture 2 주제 선정 + AI 기획안 (학기 시작점, 사후 아카이브 2026-04-28) - **NN=00.** Zan Sol 자체가 만들어진 과제. 안내문은 `course_materials/Lecture2_주제선정_기획안_안내문.pdf`. - **사후 아카이브:** Lecture 2 안내문이 보유돼 있지 않아 PM AI가 "프로젝트 출발점"을 모르고 작업했음. 04-28에 Tom 제시로 발견. - **결정적 출처:** V1(ML 없음)/V2(ML 확장) 분리 자체가 이 안내문의 명시 — "ML 없어도 감점 안 함". 5-3 결정의 정당성 근거. - **AI 활용 R-O-C-O 프롬프트 프레임** (Role·Objective·Context·Output) 명시 — 우리 CONTEXT.md를 챗봇에 통째로 붙여넣는 운영 방식과 정합. - Zan Sol 기획안 한 문장 Product Goal 확정. 개인용으로 scope 좁힘. ## 2026-04-07 — 데이터·모델 과제 제출 후 피드백 - 교수 피드백: **V2 output에서 Bandit(잔소리 개인화)과 Classification(딴짓 예측)을 분리해서 제시해야 한다.** 한 문장에 섞으면 의도가 안 읽힘. - 교수 피드백: **서베이 n=34는 "소규모 탐색적"으로 반드시 한계 명시**. 안 쓰면 대표성 주장으로 오해됨. - **문구 분류는 독립 모델 framing이 아니라 보조 전처리로 재배치**. 잔소리 개인화 모델 안으로 들어가야 함. ## 2026-04-14 — Freshness 과제 - 과제 질문을 **Product Goal 관점으로 재정의**하는 것이 평가에 유리하다. "모델 최신성" → "서비스가 product goal을 시간에 걸쳐 달성하는가". 이 프레이밍 전환은 우리 팀 강점(규칙 기반 = 재학습 부담 없음)을 드러낸다. ## 2026-04-17 — Speed 과제 - 우리 서비스의 **"단일 크리티컬 패스"** 프레이밍이 강력하다. Speed 리스크가 한 지점에만 있고, 그 한 지점마저 이벤트 기반 + 로컬 완결 + 규칙 기반 세 가지 강점이 중첩된다. - **"단순함 자체가 구조적 이점"**이라는 결론 방식이 유효하다. ## 2026-04-16 — 도메인 전문가 활용 과제 (사후 아카이브 — 2026-04-28 발견) - **사후 아카이브:** 본 과제는 제출은 했으나 4/28까지 본 레포에 폴더·인덱스가 없었음. Tom이 PDF를 보여주기 전까지 PM AI가 "모르는 과제"로 취급. → `assignments/03-domain-expert/` 신설, `assignments/README.md` INDEX 도입. - **메타 레슨:** "AI가 과제 알고 있을 거다"는 보장이 없다. 단일 진실 원천(`assignments/README.md`)이 없으면 같은 누락이 반복된다. 새 과제는 무조건 `/run-assignment` 통해 INDEX 등록. - **내용 메모:** 학습상담사+교사+선배 3그룹 인터뷰 계획. heuristic 5/15/30분은 자체 설문 분포 기반 초기값 — 이후 13-3 → 13-4(Speed) 거치며 즉시/30초/2분으로 reframe됨. ## 2026-04-21 — 라벨링·유사 구현 조사 과제 - 잔소리 선택이 **4축 공간(단계·카테고리·모드·디데이) 위의 최적점 탐색 문제**라는 프레이밍을 확정. 256 조합 중 대표 10개 라벨링으로 V1 규칙 씨앗 확보. - 발견: 디데이가 가장 강력한 조절 변수. 앱 카테고리별 몰입 깊이 차이. 휴식 모드는 개입 정당성 약함. 메신저는 사회적 비용 때문에 특수. - 미해결 challenge 기록됨: 제안/공감/강력 경계 모호, 휴식 모드 개입 기준, 카카오톡처럼 용도 혼재 앱 분류. V1에서 해결 불가. ## 2026-04-28 — UX 설계 과제 (IA · User Flow · Wireframe) ※ NN=06 - 산출물: IA 트리 / User Flow 흐름도 / Wireframe 7개 / Wire Flow / 설명문서. PDF 1건 제출. - **신규 결정 도출:** 세션에 **목표 시간(타이머 카운트다운) 없음, 경과 시간만 표시.** 사용자가 종료 시점을 스스로 결정 → 5-9 의사결정으로 추가. - 우리 서비스의 UX 특이성: **잔소리 오버레이가 메뉴 트리 외부의 OS 레이어(SYSTEM_ALERT_WINDOW)에서 렌더링**된다는 점이 다른 팀과의 차별점. IA 표기에 명시. - 화면 7개 정의 → 4인 16주 분담의 입력값 확보. ## 2026-04-21 — AI PM 에이전트 도입 - 서데사 단톡에서 **"🤖 Claude (by PM)"** 명의로 발송하는 관습 확립. 팀원 이미 인지. - 팀 커뮤니케이션 톤: 존댓말 ("~해요/~합니당"), 논제 번호 포맷, "확인 부탁드립니다" 마무리. - 김민성이 가장 적극적으로 응답. 이호준·유준혁은 조용한 편. 논제 제기는 Tom이 드라이브. --- ## 템플릿 ```markdown ## YYYY-MM-DD — <짧은 제목> - 어떤 상황/과제/피드백이었나 (1줄) - 배운 것 (1~2줄, 추상화) - 다음에 적용할 방식 (선택사항, 1줄) ``` # 수업의 Data·Model 8-Step 프레임워크 > 모든 과제(Freshness, Speed, Labeling, 그 외 신규 과제)가 이 프레임워크 위에서 나온다. 과제 답안을 쓸 때 반드시 해당 Step을 명시적으로 언급할 것. ## 한 줄 요약 > **모델은 데이터와 분리해서 고를 수 없다. Product Goal → Input/Output → Data 수준 → 구현 가능한 Framing 순으로 결정한다.** ## 8-Step | Step | 질문 | 우리 팀의 답 | | --- | --- | --- | | 1. Product Goal | 사용자에게 제공할 핵심 가치를 한 문장으로? | "사용자가 딴짓 순간 집중 과업으로 복귀하도록 돕는다" | | 2. Input / Output | 무엇을 넣고 무엇을 뽑을 것인가? | V1: 앱 실행 이벤트 → 잔소리 문구 선택 / V2: 맥락 feature → 복귀 확률 높은 문구 | | 3. 데이터 수준 | Ground Truth / Weakly Labeled / Unlabeled / No Data 중 어디? | 현재 **No Data** → V1 운영으로 **Weakly Labeled** 생성 → V2에서 **Labeled** 달성 | | 4. Generative Model? | 생성형이 꼭 필요한가? | 불필요 (잔소리는 사전 작성 풀에서 선택) | | 5. End-to-End vs Simple | 한 번에 풀 것인가, 작은 단계로 나눌 것인가? | **Simple Solution** — 이벤트 기반 + 로컬 완결 + 규칙 기반 | | 6. 알고리즘이 되어보기 | 사람이 이 문제를 풀면 어떤 기준을 쓸까? | 학습상담사·고교 교사의 개입 절차를 규칙으로 옮김 | | 7. Feature 기반 단순 모델 | 분류/점수화/순위화부터 시작 | V1은 규칙, V2는 분류(딴짓 예측) + Bandit(잔소리 개인화) | | 8. Framing 전환 | 데이터가 부족하면 문제 정의를 바꿔라 | 원래 목표(개인화 추천) → V1에선 규칙 기반으로 framing 전환 → 운영이 곧 데이터 수집 | ## 좋은 프로젝트의 기준 (수업 원문 요지) - "가장 최신 모델을 쓰는 프로젝트"가 아니라 **"주제·데이터·모델이 논리적으로 맞물린 프로젝트"** - 반복적(iterative) 과정으로 framing을 다듬는다. 첫 버전부터 완벽하지 않아도 된다. - 이번 학기 안에 **실현 가능한 framing**을 선택한다. ## 과제 답안에 적용하는 방식 1. 답안 첫 줄에 Product Goal 한 문장 재확인. 2. 어떤 Step을 다루는 과제인지 명시 (예: "이번 Freshness 과제는 Step 3·Step 8과 연결된다"). 3. V1/V2 경계 명확히. 이번 학기 결과물은 V1, V2는 마지막 1줄로만 언급. 4. 구체 수치 포함. 추상적 "~한다" 금지. # 수업 운영 방식: AI 초안 → 팀 비판적 검토 → 최종안 > 이 수업은 "AI를 실무 도구로 쓰되, **그 답안을 그대로 제출하지 말고** 팀이 비판적으로 검토·수정·보완한다"는 방식을 명시적으로 채택한다. 따라서 우리 제출물은 **두 단계를 모두 보여줘야** 한다. ## 수업이 전제하는 학생 경험 1. AI를 활용한 초안 작성 2. AI 답안의 타당성 검토 3. 오류·한계·비현실성 식별 4. 팀 토의를 통한 수정·보완·개선 5. 최종안의 논리적 정당화 ## 제출물에 반드시 포함되어야 하는 것 - AI에 제공한 핵심 정보 (=우리 팀 맥락을 어떻게 요약해서 줬는지) - AI가 제안한 최초 초안 - 팀이 발견한 문제점·한계 - 수정·보완한 이유 - 최종 확정안 - **AI 초안 대비 개선된 점** ## 수업의 핵심 메시지 (교수 강조) > "AI는 출발점을 빠르게 만들어 준다. 그러나 더 타당하고 현실적인 결과물을 만드는 것은 팀의 비판적 사고와 토론이다." ## 우리 팀 운영 방식에 주는 영향 - **우리 팀은 AI PM 에이전트를 쓴다.** 이 자체가 수업 방식과 부합한다. - 하지만 에이전트 초안을 그대로 복붙 제출하면 수업 취지에 어긋난다. - 따라서 모든 과제는 다음 단계를 거친다: 1. 에이전트가 **초안**(draft) 작성 2. Tom 또는 팀원이 **문제점·개선점 주석** 3. **최종안**은 팀 토의 결과를 반영해 별도 문서로 4. 제출 시 "AI 초안 대비 개선점" 섹션을 별도로 넣는다 - `assignments/NN-xxx/` 폴더에 `draft.md`, `review.md`, `final.md` 3단계로 저장 ## 과제 답안 톤 - 일반론 금지. "우리 프로젝트에서는 X이므로 Y이다" 형태. - "왜 문제인가" + "어떻게 대응할 것인가"를 반드시 한 쌍으로. - 기술적 관점뿐 아니라 시간·비용·관리 가능성 같은 다각도 고려 포함. # 과제별 제출 포맷 > 수업이 요구하는 포맷은 과제마다 다르다. 새 과제가 나오면 이 파일에 항목을 추가한다. > > **공통 분량:** 한 페이지 내외 또는 슬라이드 1장 분량. 중요한 건 길이가 아니라 **자기 팀 프로젝트 맥락에서의 구체성**이다. --- ## Data·Model 실습 (Step 통합 과제) **팀별 제출 항목 8개:** 1. 프로젝트 주제 2. Product Goal 한 문장 3. Input / Output 정의 4. 현재 확보 가능한 데이터 5. 데이터 수준 분류 (labeled / weakly labeled / unlabeled / none) 6. 가능한 모델 framing 후보 2개 이상 7. 최종 선택할 1차 접근안 8. 그렇게 결정한 이유 (데이터 확보 가능성 / 구현 난이도 / 결과 해석 가능성 / 학기 내 완성 가능성) **발표 시 핵심 메시지:** 주제-데이터-모델이 논리적으로 맞물려 있는지, end-to-end 대신 simple solution으로 시작할 필요가 있는지. --- ## Freshness 과제 **팀별 제출 항목 6개:** 1. 프로젝트 주제 2. 사용 예정 데이터 3. 시간이 지나며 변할 수 있는 요소 4. 그 변화가 모델 성능에 미칠 영향 5. Freshness 유지를 위한 대응 방안 6. 실행 가능성에 대한 팀의 판단 **핵심 질문 6개 (답안에 녹일 것):** - 데이터 변화 가능성 - 변화의 내용 (무엇이, 왜, 어떻게) - 성능 영향 - 재학습 필요성 - 점검 주기 - 실행 부담 (비용·시간·인력) **예시 부족한 답안:** "데이터는 변할 수 있다" **예시 좋은 답안:** "우리 프로젝트에서는 사용자 선호가 학기 초와 학기 말에 달라질 수 있으므로 학기 단위로 데이터를 점검할 필요가 있다" --- ## Speed 과제 **팀별 제출 항목 8~9개:** 1. 프로젝트 주제 2. 사용자 기대 대기 시간 3. 최소 속도 요구조건 (minimum speed requirement) 4. 현재 접근 방식의 예상 처리 시간 5. 전체 파이프라인 기준의 속도 검토 6. 병목 요인 7. 개선 방안 또는 대안 8. 최종 판단 **핵심 관점:** - "모델이 빠른가"만 보지 말고 **"서비스 전체가 충분히 빠른가"**로 본다 - 모델 추론 + 데이터 로딩 + DB 조회 + 네트워크 + 여러 단계 누적 시간 모두 포함 - 한 번 실행 vs 반복 실행 누적 구분 **예시 좋은 답안 톤:** "사용자가 버튼을 누른 뒤 2초 이내에 결과를 받아야 하며, 현재 구상은 이미지 업로드와 서버 추론 때문에 5초 이상 걸릴 가능성이 있으므로 이미지 크기 축소 또는 더 단순한 모델로 변경하는 방안을 검토해야 한다" --- ## Labeling · Public Implementation · Existing Data 과제 (0421 유형) **팀별 제출 항목 5개:** 1. 프로젝트 주제 및 과제의 목적 (우리 프로젝트 맥락에서 왜 라벨링이 필요한가) 2. Labeling Examples (구글 시트 등으로 대표 조합 라벨링 + 부여한 라벨 + 이유 + 판단 기준) 3. Labeling 후 발견한 패턴 / 애매하거나 어려웠던 점 4. Similar Public Implementations (링크 + 유사한 점 + 참고 가능한 점) 5. Existing Data and Code (데이터셋/코드 + 출처 + Input/Output + 활용 가능성) **종합 정리 섹션 (답안 마지막에 반드시 포함):** - 현재 우리 프로젝트의 초기 휴리스틱은 무엇인가? - 현재까지 보았을 때 예상되는 주요 challenge는 무엇인가? - 지금 선택한 접근 방법/모델은 계속 유지할 만한가? - 추가로 더 조사해야 할 것은 무엇인가? **제출 형식:** PDF + (라벨링이 있는 경우) 엑셀/구글시트 링크 동봉. --- ## 새 과제 추가 템플릿 ```markdown ## <과제명> **팀별 제출 항목 N개:** 1. ... **핵심 질문:** - ... **우리 팀에서 주의할 점:** ... ``` # 좋은 답안 공통 루브릭 > 과제 종류에 관계없이 교수님이 반복해서 강조하는 "좋은 답안 vs 부족한 답안" 기준. ## 좋은 답안의 5가지 조건 1. **팀 프로젝트의 실제 주제·기능과 연결된다.** 일반론 아닌 Zan Sol 맥락에서의 설명. 2. **구체적으로 설명한다.** 수치·시간·횟수·단계가 들어간다. 3. **"왜 문제인가" + "어떻게 대응하는가"**를 한 쌍으로 제시한다. 4. **다각도 고려.** 기술적 관점뿐 아니라 시간·비용·관리 가능성까지. 5. **자기 팀의 판단**이 들어 있다. 단순 레퍼런스 복사가 아니라 "우리는 X라고 본다"는 결정. ## 부족한 답안의 전형 - "데이터는 변할 수 있다" — 주어 없음, 맥락 없음 - "빨라야 한다" — 얼마나 빨라야 하는지 수치 없음 - "사용자에게 중요하다" — 어떤 사용자의 어떤 순간인지 없음 - "모델을 개선할 것이다" — 어떤 방법으로, 언제, 무엇을 기준으로인지 없음 ## 우리 팀 과제 작성 시 자체 체크리스트 답안 제출 전 다음 5가지가 모두 YES인지 확인한다: - [ ] Product Goal 문장이 답안 내에 재등장하거나 명시적으로 참조되었는가? - [ ] 수업 Step 번호 또는 수업 원칙이 1회 이상 인용되었는가? (예: "수업 Step 8의 framing 전환 적용") - [ ] 추상적 서술 없이 구체 수치·시점·메커니즘이 들어갔는가? (30초, 2분, 500세션, n=34 등) - [ ] "왜 X인가"의 근거가 레퍼런스 또는 우리 맥락과 연결되어 제시되었는가? - [ ] V1 중심이고 V2는 마지막 1줄로만 나오는가? ## 전형적 우리 팀 프레이밍 템플릿 > "수업 Step [N]에 따르면 [원칙]이다. 우리 Zan Sol 프로젝트는 [맥락] 상황이므로 [판단]이다. 구체적으로는 [수치·메커니즘]로 대응한다. V2 시점에서는 [한 줄]." ## 메타 레슨 (과거 과제에서 얻은 것) | 원칙 | 내용 | | --- | --- | | 과제 질문을 Product Goal 관점으로 재정의 | 예: "모델 최신성" → "서비스가 product goal 달성 가능한가" | | V1 중심, V2는 마지막 한 줄 | 이번 학기 결과물에 집중 | | 대응 방안은 "한다"가 아니라 "어떻게·얼마나·왜" 구체화 | 숫자 필수 | | 우리 서비스의 심플함 = 강점 | Speed·Freshness 모두 "단순함이 구조적 이점" | | 근거 제시 시 우리 맥락 연결 필수 | "Nielsen 가이드라인"만 쓰지 말고 "왜 우리 상황에 적용되는가"까지 | | 수업 프레임워크에 명시적으로 매핑 | 교수는 혁신이 아니라 "적용했는가"를 본다 |