현재 앱 개발 진행중인 doing _ / 작업중인
디버깅 3주 자동
‣
이건 대형 기능 요청 10개를 정리해둔 확인 큐야. 상단에 진행 규칙이 적혀있으니 그대로 따라줘 — 핵심만 요약하면:
- "진행 상태" 표에서 아직 "답변 대기"인 항목 중 하나를 골라서, 그 항목 섹션에 정리된 "결정이 필요한 것"을 나한테 하나만 물어봐.
- 절대 여러 항목을 한꺼번에 묻지 마 — 작업 병목 방지가 목적이야.
- 내가 답하면 그 항목 섹션에 "결정 사항"으로 기록하고, 실제 구현 계획은 TODO.md의 "완료된 것"으로 옮긴 다음, 표의 상태를 "완료"로 바꿔.
- 그 다음 항목으로 넘어가서 똑같이 반복해.
- 구현이 필요한 항목은 실제로 코드를 작성/테스트하고, flutter analyze + flutter test + iOS 빌드까지 확인한 뒤에 완료 처리해줘.
먼저 표를 보여주고, 아직 안 물어본 것 중 첫 항목부터 시작해줘.
---
문서 :
# 블루프린트: 기능 요청 인테이크 큐 (2026-07-29)
> **다른 세션/다른 Claude 창에서 이어서 진행하는 법**: 이 문서와 TODO.md는
> 대화 기록이 아니라 이 저장소의 실제 파일이라, 이 프로젝트 폴더에서 연
> 어떤 Claude 세션이든 곧바로 이어서 작업할 수 있다. "BLUEPRINT_FEATURE_INTAKE.md
> 읽고 진행해줘" 정도만 말하면 된다. 새 세션은 아래 "진행 상태" 표에서
> "답변 대기"인 항목 중 아직 물어보지 않은 걸 골라 사용자에게 확인 질문을
> 하나만 던지고 기다린다 — **여러 항목을 한꺼번에 묻지 않는다**(작업
> 병목 방지, 사용자 명시 요청). 답변이 오면 그 항목 섹션에 "결정 사항"을
> 적고, 실제 구현은 TODO.md의 "완료된 것"으로 옮긴 뒤, 위 표의 상태를
> "완료"로 바꾼다. 그다음 항목으로 넘어간다.
## 왜 이 문서가 필요한가
2026-07-29에 사용자가 한 번에 10개에 가까운 대형 요청을 쏟아냈다. 전부
TODO.md에 바로 정리해서 넣는 대신(각 항목의 실제 의도를 얕게 해석한 채
문서만 쌓일 위험, 그리고 일부는 이미 내린 결정 — 예: 혼전순결 도메인
분리 — 과 충돌할 수 있음), **하나씩 사용자에게 확인받고 나서** 착수하기로
했다. 이 문서는 그 확인 큐다.
**규칙**:
- 이 문서에 있는 항목은 전부 "답변 대기" 상태다. 사용자 답변을 받기 전엔
구현에 착수하지 않는다(단, 항목 8의 척도 방향처럼 "버그인지 사실
확인"만 필요한 조사성 작업은 예외 — 이미 1차 조사는 마쳤다, 아래 참고).
- 답변을 받으면 이 문서의 해당 항목에 결정 사항을 기록하고, 실제 작업
계획은 TODO.md의 "완료된 것"/로드맵으로 옮긴다. 이 문서 자체는 계속
"다음 항목 확인 대기" 큐로만 남는다.
- 한 번에 여러 항목을 동시에 확인하지 않는다 — 사용자가 "지금 당장 작업
병목이 안 생기게" 해달라고 명시했으므로, 답변이 오는 대로 그 항목만
처리하고 나머지는 계속 대기시킨다.
## 진행 상태
| # | 항목 | 상태 |
|---|---|---|
| 1 | 질문 생성/타이밍/미응답 디버그 로그 (3주 보관) | 답변 대기 (지금 질문함) |
| 2 | 좋음/나쁨 이분법 탈피 — 유의미한 질문만 | 대기 |
| 3 | 실시간 카드 테이블 체크인 UI | 대기 |
| 4 | 쌍둥이 태그(자동 상관관계 명명) | 대기 |
| 5 | 패턴 드리프트 감지 + 버전 히스토리 리포트 | 대기 |
| 6 | 위치 스캔/현재 지역 태그 | 대기 |
| 7 | 일기 원인추론 + 복합 태그 + 유사상황 알림 + 의학상식 + 소급기록 상세 | 대기 |
| 8 | 동일주제 태그 세분화 + 척도 방향 검증 | **조사 완료, 확정 안 됨** (아래 참고) |
| 9 | 감정 변곡점 시간대: 언급시간 vs 발생시간 구분 + 자주쓰는 옵션 상단 | 대기 |
| 10 | 혼전순결("다짐") 앱 기능 병합 + AI 문의함 | 대기 (민감 — 과거 사고 이력과 연관) |
---
## 1. 디버그 로그 (질문 생성/타이밍/미응답, 3주 보관)
**원문 요약**: 시스템에서 나온 질문과, API를 통해 새로 만들어진 질문
전부 — 언제 나왔는지(타이밍), 사용자가 마주했지만 답하지 않은 것까지 —
디버깅용으로 로그를 남기고 싶다. 3주치 보관.
**이미 있는 것과의 관계**: `TagSettingsService`의 `question_stats`가
asked/skipped/answered/lastAskedAt을 태그별 **누적 집계**로만 들고 있다
(개별 이벤트 로그가 아님). 이건 "지금 이 태그가 얼마나 자주 스킵됐는지"는
알 수 있지만 "7/15 14:32에 '피로도' 질문이 떴고 사용자가 답 안 하고
넘어갔다" 같은 **개별 이벤트 단위 타임라인**은 없다. `ai_import_logs`,
`app_error_logs`처럼 이벤트 로그 테이블 패턴은 이미 DB에 있음
(`lib/db/database.dart`) — 같은 패턴으로 `question_event_logs` 테이블을
추가하고, 3주 지난 로그는 주기적으로 정리하는 방식이 될 것.
**결정이 필요한 것**:
- 로그를 앱 안에서 보는 화면이 필요한가, 아니면 설정의 "디버거용 JSON
복사"(`tool/analyze_backup.dart`)에 이 로그도 포함시켜 거기서만 보면
충분한가?
- "3주"는 실제 보관 기간(그 이후 자동 삭제)인가, 아니면 "최근 3주만
보여주고 그 이전은 남아있어도 상관없다"는 뜻인가?
---
## 2. 좋음/나쁨 이분법 탈피 — 유의미한 질문만
**원문 요약**: 하루를 계속 좋았다/아니었다로만 정의하지 말고, 그 질문이
유의미할 때만 물어보게 해달라.
**이미 있는 것과의 관계**: 2026-07-28에 "무의미한 데이터 그만 묻기"
(저신호 질문 자동 억제, `TagSettingsService.isLowSignal`)를 이미
구현했지만, 그건 **카테고리 척도 질문**(학업/수면 등)에만 적용된다. 이
요청은 그보다 근본적 — **총평 자체("좋은 하루/힘든 하루")를 매번 강제로
묻는 게 맞는지**를 묻는 것으로 읽힌다.
**결정이 필요한 것**:
- 총평 질문을 아예 선택적으로 만드는 건가(스킵 가능하게), 아니면 다른
형태(예: 척도 질문들의 평균으로 자동 산출하고 "이게 맞나요?"로만
확인)로 바꾸자는 건가?
- 이걸 하면 `PatternEngine`의 핵심 통계(`brokenRate` 등)가 전부 이
총평(`Outcome.good/tough`)에 의존하는데, 총평이 선택적이 되면 그 계산
기반 자체를 다시 설계해야 할 수 있음 — 이 여파를 감수할 만큼 중요한
변경인지 확인 필요.
---
## 3. 실시간 카드 테이블 체크인 UI (하스스톤 스타일)
**원문 요약**: "오늘 컨디션 체크"를 카드를 테이블에 올려놓는 형태로 —
카드를 놓으면 감정 상태 등이 실시간으로 변하는 걸 지켜볼 수 있게. 시간대는
옆 라벨 + 밸브를 돌려서 조정.
**성격**: 이건 로직이 아니라 **완전히 새로운 인터랙션 디자인**(드래그
앤 드롭 카드, 실시간 애니메이션, 다이얼/밸브 컨트롤)이라 지금 있는
`RiskCheckScreen`을 손보는 수준이 아니라 사실상 새 화면을 처음부터
설계/구현하는 작업.
**결정이 필요한 것**:
- 이게 기존 "오늘 컨디션 체크"(`RiskCheckScreen`)를 대체하는 건가, 별도
실험적 화면으로 병행하는 건가?
- "카드를 테이블에 올리면 감정 상태가 실시간으로 변한다"는 게 구체적으로
뭘 보여주는 건지(예: 선택한 카드들의 조합으로 `PatternEngine.assess`
결과가 실시간 갱신되는 걸 시각화하는 것?) 더 구체적인 그림/예시가
있으면 도움이 될 것.
---
## 4. 쌍둥이 태그 (자동 상관관계 명명)
**원문 요약**: "친교가 있으면 항상 피곤하다" 같은 패턴이 데이터로 보이면,
"친교 = 피곤"처럼 그 관계 자체를 하나의 명명된 개념으로 만들어달라.
**이미 있는 것과의 관계**: `PatternEngine.coOccurringTags`/
`findProtectiveCombos`가 이미 "이 태그와 저 태그가 자주 같이 나타나고,
그때 힘든 하루 비율이 어떻게 달라지는지"를 계산한다. 지금 요청은 그
결과를 **사용자에게 보여줄 때 "쌍둥이 태그"라는 명명된 관계로 승격**하자는
것 — 계산 로직은 이미 있고, "이걸 관계 하나로 이름 붙여서 저장/재사용"
하는 레이어만 없음.
**결정이 필요한 것**:
- 이름은 시스템이 자동으로 짓는가("친교↔피곤"), 사용자가 확정/이름
붙이는 단계가 있는가?
- 확정 기준은 기존 `findProtectiveCombos`와 같은 표본/효과크기 문턱을
재사용하면 되는지, 아니면 "쌍둥이"는 더 엄격한(항상 같이 나타나는)
기준이 필요한지?
---
## 5. 패턴 드리프트 감지 + 버전 히스토리 리포트
**원문 요약**: 사용자의 데이터가 어느 시점부터 예전 예측과 달라지기
시작하면, "다수결"(그동안 쌓인 전체 평균)을 고집하지 말고 그 시점을
"변화의 시기"로 보고 그때부터 새 패턴을 서서히 형성해야 한다. 리포트에도
"이전 버전 → 지금, 그리고 왜 바뀌었는지 추론"을 역사처럼 보여달라.
**이미 있는 것과의 관계**: `PatternEngine.tagRisks`에 이미
`useRecencyWeighting`(반감기 감�쇠, 8개월)이 있어 오래된 기록의 영향력을
서서히 줄이긴 하지만, 이건 "완만한 감쇠"일 뿐 **"이 시점에 뚜렷한 전환이
있었다"를 감지하고 그 지점을 리포트에 명시적으로 표시**하는 기능은 없다.
`lib/models/life_event.dart`(다른 세션이 최근 추가한 "인생 이벤트" —
새 직장/이사 등을 사용자가 직접 등록하면 "이전 vs 지금"을 나눠서 비교)가
비슷한 목적이지만, 그건 **사용자가 수동으로 등록**하는 이벤트 기반이고
이번 요청은 **데이터 자체에서 자동으로 전환점을 감지**하자는 것이라
방향이 다르다.
**결정이 필요한 것**:
- 통계적으로 "변화"를 어떻게 판정할지(예: 최근 N건과 그 이전 N건의
brokenRate 차이가 문턱을 넘으면?) — 표본이 적은 개인 일기 데이터에서
이런 변화점 탐지는 오탐이 잦을 수 있는데, 어느 정도 확신이 있어야
"전환"으로 인정할지 기준이 필요.
이미 있는 `life_event`(수동 등록) 기능과 어떻게 역할을 나눌지도 정리
필요 — 자동 감지가 "이런 변화가 있는 것 같아요, 인생 이벤트로
등록할까요?"를 제안하는 식으로 연결하는 것도 방법.
---
## 6. 위치 스캔 / 현재 지역 태그
**원문 요약**: 설문 중 "지금 지역 스캔하기" 버튼을 누르면 지역명과 그
지역에서 보통 뭘 하는지를 데이터로 만들고, 나중에 그게 장소 태그로 굳어짐.
**성격**: 위치 권한(iOS `NSLocationWhenInUseUsageDescription` 등) +
`geolocator`류 새 패키지 + 새 데이터 모델(장소 이름, 좌표 또는 역지오코딩
결과, 그 장소에서의 활동 이력)이 필요한 완전히 새로운 기능. 옛
"다짐"(sex) 앱 시절엔 `LocationType`이 있었던 걸로 보이는데(TODO.md
초반 기록 참고), 그건 사용자가 직접 고르는 카테고리였지 GPS 기반은
아니었음.
**결정이 필요한 것**:
- 위치 정보는 민감한 데이터다 — 이 앱은 지금까지 전부 로컬/Keychain
중심으로 프라이버시를 지켜왔는데(클라우드 백업도 opt-in), 위치 데이터도
같은 원칙(로컬에만 저장, 절대 서버 전송 안 함)으로 가는 게 맞는지 확인.
- "지금 스캔하기"는 실시간(오늘) 기록에서만 쓰는 건지, 소급 기록("어제")
에도 쓸 수 있게 할 건지(소급 기록에서 "지금 스캔"은 의미가 이상해짐).
---
## 7. 일기 원인추론 + 복합 태그 + 유사상황 알림 + 의학상식 + 소급기록 상세시간
**원문 요약**: 하루 메모에서 감정 변곡점의 원인("무엇이 감정을 이기게
했는지/거지같이 만들었는지")을 찾고, "건강 안 좋음" 같은 단순 태그를
"속이 안 좋았다"처럼 더 구체적인 복합 태그로 세분화. 나중에 비슷한
상황이면 "이전에 이런 상황에서 이랬을 때 더 별로였어요, 하지만 이러면
좋을 거예요"처럼 과거 행동-결과 연관성을 알려주고, 의학 상식도 곁들임.
소급 기록("어제")에는 정확한 시간대·누구와 있었는지도 남길 수 있게.
**이미 있는 것과의 관계**: 이 항목은 사실 여러 개가 섞여 있다.
- "메모에서 원인 추론 + 복합 태그" → `ClaudeReportService.
extractTagsFromNote`가 이미 메모에서 태그를 뽑고 있음 — "더 구체적인
복합 태그"로 프롬프트를 개선하는 방향.
- "비슷한 상황에 과거 연관성 알려주기" → `PatternEngine.
buildInteractionSummary`/`describeRiskPattern`이 이미 비슷한 일을 하지만
지금은 리포트/체크인 화면에서만 쓰임 — 이걸 실시간 체크인 중에
"이전에 비슷했을 때는…" 식으로 끼워 넣는 확장.
- "의학 상식" → `FatigueEngine`의 `scientificBasis` 패턴(사용자 데이터
근거와 일반 지식을 분리해서 보여주는 방식)을 그대로 재사용 가능.
- "소급 기록 상세 시간대/누구와" → 이미 TODO.md "시간대·요일·이벤트 맥락
확장"에 "소급 기록 시간대 입력 UI" 항목으로 등록돼 있음(2026-07-28).
"누구와"는 거기에 없던 새 요구사항이라 추가 필요.
**결정이 필요한 것**:
- 이건 사실상 4개 하위 기능인데, 전부 한 번에 원하는지 아니면 이 중
일부(예: 복합 태그 세분화)부터 먼저 할지 우선순위가 필요.
- "의학 상식"은 이 앱이 지금까지 지켜온 "진단하지 않는다, 관찰된 행동만
다룬다"(Adaptive Life OS 기획의 금지 원칙과 동일 정신) 선을 넘지 않는
선에서 — 예를 들어 "이 증상은 의료 전문가와 상담이 필요할 수 있어요"
같은 면책 문구가 필요한 수준인지 확인 필요.
---
## 8. 동일주제 태그 세분화 + 척도 방향 검증 (조사 완료)
**원문 요약**: 같은 주제로 보이는 태그를 세분화. 그리고 긍정/부정 척도가
반대로 표시되는 경우를 방지 — 예: "건강 1~5(안좋음→좋음)"인데 실제
데이터 환산은 "5~1"(반대)이었다면, 그 기간 수치를 반전시키고 표현을
통일해달라.
**지금까지 조사한 것**: `Entry.categoryRatings`, `TagCatalog.
deriveTagsFromRatings`, `defaultScaleAnchors`를 전부 확인했고, 1점=나쁨/
5점=좋음, "부진"=낮은 점수, "양호"=높은 점수로 **일관되게** 맞아 있음을
확인했다 — 지금 파악한 범위에서는 반전을 못 찾았다. 단, 다른 세션이
동시에 추가한 화면(`pattern_graph_screen.dart` 등)까지 전부 훑진
못했다.
**결정이 필요한 것**:
- 반전처럼 보인 게 **어느 화면, 어느 날짜/카테고리**였는지 구체적 사례를
알려주면 거기서부터 정확히 추적 가능. 재현 가능한 사례 없이는 "고쳤다"고
확인해줄 방법이 없음.
- "동일주제 태그 세분화"는 구체적으로 어떤 태그들이 뭉뚱그려져 보였는지
예시가 필요(예: "학업"과 "공부" 같은 근접 중복은 이미
`planDuplicateTagMerges`/`planSemanticTagMerges`가 다루고 있음 — 그걸로
충분한지, 아니면 다른 세분화를 말하는 건지).
---
## 9. 감정 변곡점 시간대: 언급시간 vs 발생시간 구분 + 자주쓰는 옵션 상단
**원문 요약**: 감정 변곡점의 시간대는 "언급한 시간"이 아니라 "실제
있었던 시간"을 기준으로 하고, 그걸 물어볼 때 "방금/3시간 전"처럼 물어봐
달라. 자주 쓰는 옵션이 상단에 오도록.
**이미 있는 것과의 관계**: TODO.md에 이미 "소급 기록 시간대 입력 UI"로
등록돼 있는 항목(2026-07-28)과 거의 같은 요청 — 이번엔 **입력 방식까지**
구체화됨("방금/3시간 전" 같은 상대 시간 선택지, 자주 쓰는 것 상단 노출
— 사용 빈도 기반 정렬).
**결정이 필요한 것**:
- 상대 시간 선택지 목록을 고정할지(방금/1시간 전/3시간 전/오늘 아침/
어제 저녁 등), 자유 입력도 허용할지.
- "자주 쓰는 옵션 상단"은 `TagSettingsService`의 질문 우선순위 스코어링과
비슷한 개인화 로직이 필요 — 이것도 재사용 가능한 패턴.
---
## 10. 혼전순결("다짐") 앱 기능 병합 + AI 문의함
**원문 요약**: "다짐"(혼전순결) 앱 기능을 이 앱에도 합쳐달라. 사용자는
한동안 성공해서 매번 물어볼 말이 없는 상태 — 아침/점심/저녁마다 매번
물어보면 너무 무관한 질문 세례가 될 것 같으니, **채팅으로 언급하기
전까지는 계속 성공으로 간주**하는 방식으로. 그리고 문의 사항 박스를 만들면
AI가 처리해서 함께 추론에 반영.
**왜 이게 특별히 민감한가**: `BLUEPRINT_APP_ISOLATION.md`에 기록된 실제
사고 — 원본 "다짐"(현재 `/Users/rogan/Desktop/appDev/sex` 폴더)과
"하루기록"이 번들 ID를 공유했다가 Keychain 데이터가 섞이고 앱이 서로
덮어써진 사건이 있었다. 그 사고 이후 두 앱은 **의도적으로 완전히
분리**됐다(번들 ID, 스키마, 도메인 전부). 지금 요청은 그 분리된 도메인을
**같은 앱 안에서 다시 통합**하자는 것이라, 실수로 되돌리는 게 아니라
의도한 재통합인지 명확히 해야 한다.
**결정이 필요한 것**:
- 이건 "같은 앱에 새 모드 하나 추가"인가, 아니면 정말로 옛 "다짐" 코드
(`/Users/rogan/Desktop/appDev/sex`)의 스키마/로직을 가져오는 건가?
후자라면 어떤 데이터를 옮길지(그쪽 앱에 실제 사용 기록이 있다면)도
정리 필요.
- "채팅으로 언급하기 전까지 계속 성공으로 간주"는 구체적으로 — 체크인
때마다 매번 "오늘도 지켰나요?"를 안 묻고, 기본값을 "성공"으로 깔아둔 채
사용자가 채팅/메모에서 스스로 실패를 언급했을 때만 그날을 실패로
기록한다는 뜻으로 이해했는데 맞는지.
- "문의 사항 박스"는 지금 앱에 없는 완전히 새로운 채널(사용자 피드백/
문의 입력 → AI가 읽고 처리) — 이게 위 혼전순결 기능과 왜 묶여 있는지
(문의함이 혼전순결 전용인지, 앱 전체 공용 기능인지) 확인 필요.
디버깅 3주 자동