스크린샷
온보딩
일기 목록
일기 작성
마음 달력
감정 추이
키워드 분석
AI 캐릭터
설정
AI 기반 감정 케어 다이어리
당신의 일기를 분석하여 감정 상태를 파악하고,
따뜻한 위로의 메시지와 맞춤형 행동 지침을 제공합니다.
로컬 데이터베이스(SQLite)에 안전하게 저장되며, 날짜별로 일기를 관리하고 조회할 수 있습니다.
최신 Groq 모델(gpt-oss-120b + Qwen Vision)으로 실시간에 가까운 감정 분석을 제공합니다. (2026년 7월 모델 업데이트 완료 — 안정성/효율성 향상)
감정 추이 차트, 감정 정원(🌱→🌻), 키워드 태그 클라우드로 나의 감정 패턴을 시각화합니다.
AI가 분석한 감정 상태에 기반하여 공감 메시지와 맞춤형 행동 지침을 제안합니다.
일기는 계정 없이 기기 안에 보관되고, AI 분석 순간에만 암호화되어 전송됩니다. 클라우드 동기화는 하지 않습니다.
320dp~600dp+ 다양한 화면 크기에 최적화된 반응형 디자인으로 모든 기기에서 편안하게 사용할 수 있습니다.
4자리 PIN + SHA-256 암호화로 민감한 일기를 안전하게 보호합니다. 인증된 세션에서만 접근 가능하며 통계에서 완전히 제외됩니다.
v1.4.64에서는 일기를 쓰다 앱을 벗어나면 쓰던 글이 통째로 사라지던 구간을 없앴습니다 — 기존 보호 장치가 "제출 버튼을 누른 뒤"부터만 동작한다는 점을 코드에서 확인하고, 사용자가 가장 오래 머무는 작성 중 구간에 자동 임시저장을 넣었습니다. 같은 릴리스에서 "통과하지만 아무것도 검증하지 않던" 테스트를 실제로 실패할 수 있는 형태로 교체하고, 오래 방치돼 PR을 막던 코드 포맷 검사도 복구했습니다. v1.4.62에서는 앱이 사용자에게 고지한 내용과 코드가 실제로 하는 일이 어긋나 있던 문제를 찾아 바로잡았습니다 — 안내 문구를 의심하는 대신 데이터가 외부로 나가는 지점을 코드에서 전수 조사해 전송 항목 인벤토리를 먼저 확정하고, 그 위에 고지 문서를 다시 세웠습니다. 같은 점검에서 인증 없이 공개돼 있던 서버 엔드포인트 3종을 발견해 제거했습니다. v1.4.61에서는 여러 차례 수정했는데도 재발하던 알림 버그의 진짜 원인을 찾아 해결했습니다 — 클라이언트만 보던 시야를 서버까지 넓혀 근본 원인을 규명하고, 회귀를 놓쳤던 기존 테스트의 구조적 결함까지 함께 고쳤습니다. v1.4.60에서는 사용자 화면 변화 없이 코드 건강도만 끌어올리는 Health Check 리팩토링을 진행했습니다 — 아키텍처 경계를 코드로 강제하는 자동 게이트 도입, 1,200줄 규모 God Class 분해, 날짜 포맷 중복 제거, 데드코드 정리(57파일 변경 · 1,748 테스트 그린). 아래에는 이전 v1.4.54까지의 성능 최적화 묶음(3-way LLM 합의로 도출한 Groq 응답 SQLite 캐싱·알림 큐 diff 알고리즘·JSON 파싱 isolate 오프로드 등)도 함께 소개합니다.
일기를 쓰다가 전화를 받거나, 홈 버튼을 누르거나, 뒤로가기를 잘못 누르면 쓰던 글이 전부 사라졌습니다. 앱에 저장 장치가 없었던 것은 아닙니다 — 다만 코드를 따라가 보니 그 장치는 제출 버튼을 누른 다음부터만 동작했고, 정작 사용자가 가장 오래 머무는 작성 중 구간에는 아무 보호도 없었습니다. 증상을 하나씩 막는 대신 보호받지 못하는 구간이 어디서 시작해 어디서 끝나는지를 먼저 특정하고, 그 구간 전체를 담당하는 기능을 새로 넣었습니다. 이제 타이핑을 잠시 멈추면 알아서 보관되고, 앱을 벗어나는 모든 경로(뒤로가기·홈 버튼·시스템의 강제 종료)에서 마지막 내용까지 기록한 뒤 빠져나갑니다. 다시 들어오면 안내와 함께 그대로 되살아납니다.
같은 기능도 어디까지 만드느냐에 따라 위험이 갈립니다. 이번에는 데이터베이스를 건드리지 않기로 했습니다 — 임시 보관본은 항상 한 건뿐이라 표를 새로 만들 이유가 없었고, 데이터베이스 구조를 바꾸면 기존 사용자 데이터를 옮기는 위험이 따라오기 때문입니다. 제출할 때 적용되는 최소 글자 수 제한도 임시저장에는 일부러 넣지 않았습니다. 그 제한을 그대로 가져오면 아홉 글자까지 쓴 글은 보호받지 못하는데, 이는 기능의 목적과 정반대입니다. 첨부 사진은 고르는 즉시 앱의 영역으로 복사합니다 — 사진 선택기가 돌려주는 위치는 운영체제가 임시로 쓰는 공간이라 다음 실행 때 사라지고, 그대로 두면 복원했을 때 사진만 깨져 보이기 때문입니다. 각 판단의 근거는 변경 이력에 남겼고, 남은 한계 두 가지도 고치지 않았다는 사실과 그 이유를 함께 공개해 두었습니다.
"문제가 없어야 한다"를 애초에 문제가 생길 수 없는 입력으로 확인하면 그 테스트는 영원히 통과합니다. 코드가 망가져도 통과하므로, 있으나 마나가 아니라 있으면 오히려 해롭습니다 — 안전하다는 착각을 주기 때문입니다. 이번에 그런 단언 다섯 건을 찾아 실제로 실패할 수 있는 형태로 바꿨습니다. 함께, 오래 방치돼 코드 검사 단계를 막고 있던 코드 서식 불일치 53개 파일도 정리했습니다. 원인은 관리 소홀이 아니라 언어 도구의 서식 규칙이 바뀐 것이었고, 검사가 저장소 전체를 보기 때문에 일부만 고치면 의미가 없어 서식 변경만 담은 별도 커밋으로 분리했습니다. 최종 확인은 자동 테스트 1,814건 통과와 실제 단말 검증 7종입니다.
앱이 사용자에게 약속한 것과 코드가 실제로 하는 것이 일치하는지 점검했습니다. 결과는 정반대였습니다. 첫 실행 안내는 "일기가 외부로 전송되지 않는다"고 말하고 있었지만, 코드상 일기 저장과 AI 분석은 분리할 수 없는 하나의 동작이어서 저장하는 모든 일기 본문이 예외 없이 외부 분석 서버로 전송되고 있었습니다. 개인정보 처리방침 역시 자동 생성 템플릿을 그대로 쓰고 있어, 실제로 사용하는 외부 서비스 이름이 문서 전체에 한 번도 등장하지 않았습니다. 문서를 읽고 고치는 대신 데이터가 밖으로 나가는 지점을 코드에서 하나씩 짚어 전송 항목 인벤토리를 먼저 만들고, 그 인벤토리를 근거로 안내 문구와 방침을 다시 썼습니다. 작성 도중 스스로 쓴 문장 하나가 코드와 다르다는 것을 발견해 되돌린 과정도 포함됩니다 — 고지 문서는 "그럴듯한 문장"이 아니라 검증된 사실이어야 하기 때문입니다.
알림 서버에 관리자용 HTTP 엔드포인트 3개가 인증 장치 없이 공개돼 있었습니다. 그중 하나는 요청에 담긴 문구를 검증 없이 그대로 전체 사용자에게 푸시로 발송하는 기능이어서, 외부에서 임의의 알림을 전 사용자에게 보낼 수 있는 상태였습니다. 코드 주석 자체가 "인증 권장, 현재는 미적용"이라고 적혀 있었지만 오랫동안 그대로 남아 있었습니다. 곧바로 지우는 대신 앱 코드 전체를 검색해 이 엔드포인트를 호출하는 곳이 한 군데도 없음을 먼저 확인했고 — 즉 제거해도 사용자 기능에 영향이 없다는 근거를 확보한 뒤 — 삭제하고 운영 환경에 반영했습니다. 배포 후 실제로 호출해 404가 돌아오는 것까지 확인했으며, 같은 기능이 인증 없이 다시 들어오지 않도록 재도입 조건을 코드에 주석으로 못 박았습니다. 정기 알림 발송 기능은 영향 없이 그대로 동작합니다.
푸시 알림에 {name}님이라는 치환되지 않은 문구가 간헐적으로 노출되는 문제가 여러 차례 수정에도 재발했습니다. 원인은 고친 곳과 터지는 곳이 서로 다른 시스템에 있었다는 점이었습니다. 과거 수정들은 모두 앱(클라이언트) 문구만 정리했지만, 실제 발신원인 서버(Cloud Functions)의 알림 템플릿에는 개인화 문구가 그대로 남아 있었고, 앱은 특정 조건에서 서버 문구를 손대지 않고 그대로 표시하는 구조였습니다. 증상이 전체 발송의 약 14%에서만, 그것도 특정 조건에서만 나타나 재현이 어려웠던 이유까지 코드 근거로 특정한 뒤 발신원을 고쳤습니다. 서로 다른 세 개의 AI 모델로 독립 교차 진단을 수행해 결론을 검증하고, 놓친 누출 경로가 없는지 전수 확인했습니다.
이 버그를 막았어야 할 테스트는 이미 존재했지만, 문제가 될 수 없는 입력만 넣고 검사하고 있어 항상 통과했습니다. 겉보기엔 초록불이지만 실제로는 아무것도 보장하지 않는 상태였습니다. 이번에는 알림 문구 후보를 무작위가 아닌 전수 순회로 검증하고, 미래에 추가될 다른 형태의 치환 문구까지 함께 차단하도록 규칙을 일반화했습니다. 나아가 새 테스트를 수정 전 코드에 실행해 실제로 15건이 실패하는지 확인하는 절차를 거쳐, 이 테스트가 다시 공허해지지 않았음을 증명했습니다. 테스트가 있다는 사실보다 그 테스트가 실패할 수 있는가를 검증하는 것이 회귀 방지의 핵심이라는 점을 반영한 작업입니다.
리팩토링이 아키텍처를 서서히 무너뜨리는 것을 막기 위해, 레이어 경계 규칙을 실행 가능한 게이트로 고정했습니다. 화면(presentation) 코드가 데이터 계층을 직접 참조하지 않는지, 위기 감지 안전장치(SafetyBlockedFailure·안전 알림 ID)가 유지되는지를 매 품질 검사마다 자동 검증하고, 위반 시 머지 전에 실패로 드러납니다. 규칙을 '문서'가 아니라 '코드'로 강제해, 팀이 커지거나 시간이 지나도 설계 원칙이 흐트러지지 않도록 했습니다.
일부 화면이 데이터 저장 계층을 직접 만들고 호출하던 결합을 제거했습니다. 비밀 일기 인증·온보딩 완료 상태 등을 도메인 UseCase 경유로 전환하고, 객체 조립은 의존성 주입(DI) 루트 한 곳으로 모았습니다. 결과적으로 화면은 '무엇을' 할지만 알고 '어떻게' 저장하는지는 몰라도 되는 구조가 되어, 데이터 소스 교체와 테스트가 쉬워졌습니다. (화면→데이터 직접 import·직접 생성 모두 0건)
하나로 뭉쳐 있던 알림 설정 서비스(1,262줄)를 역할별 모듈로 나눴습니다. 감정 거리 기반 응원 가중치, 메시지 선택(결정론/레거시 경로), 7일 알림 큐 계획을 각각 독립 파일로 분리하고, 기존 진입점은 얇은 facade(729줄)로 남겨 호출하는 쪽 코드 변경 없이 내부만 재구성했습니다. 응원 메시지 랜덤 로직의 미묘한 동작(동일 조건이면 항상 같은 메시지가 나오는 seed 결정성)은 골든 테스트로 그대로 보존했습니다.
5개 파일에 흩어져 있던 날짜 포맷 코드를 DateFormatter 한 곳으로 통합했습니다. 화면에 보이는 글자가 한 글자도 바뀌지 않도록 골든 테스트 9건으로 먼저 고정한 뒤 중복 코드를 제거해, 요일·오전/오후 표기 같은 규칙을 한 곳에서만 관리하게 됐습니다. 또한 실제로 쓰이지 않는 위젯·유틸 10개 파일을 전수 교차 검증 후 삭제했습니다. 이번 릴리스 전체는 사용자 화면·동작 변화 없이 유지보수성만 끌어올린 내부 개선입니다.
알림 신뢰성을 높이기 위한 엔지니어링 작업 완료. 모든 알림 ID(주간 인사이트 2002, 안전 후속 2004, CBT 동적 3001+)를 NotificationService에 중앙 집중화하여 중복/충돌 위험 제거. 동적 ID 생성 시 pending 알림 검사로 충돌 자동 회피 로직 추가. 큐 적용(_applyCheerMeQueueDiff)에서 per-item 오류 처리로 부분 실패 시에도 나머지 알림 정상 예약 보장 (Crashlytics 로깅 포함). mindcare 알림 {name} 패턴 금지 검증, 감정 경계값/부분 실패 시나리오 테스트 대폭 강화. 장기적으로 사용자 알림 경험의 안정성과 코드 유지보수성을 크게 향상시켰습니다.
3-way LLM 합의 기반 P0 작업으로, 동일 일기 재분석 비용을 0에 가깝게 만들었습니다. groq_analysis_cache 테이블을 신설하고 (model, content, character, userName, imageHashes, promptVersion)을 SHA-256 해시 키로 사용합니다. content는 공백 압축으로 정규화하며, 1000건 임계 시 last_used_at 기반 LRU eviction이 작동합니다. 위기 감지(is_emergency=true) 응답은 캐시 제외로 매번 재평가하여 안전성을 보장하며, PromptConstants.version 변경으로 일괄 무효화 가능한 설계입니다.
매 호출마다 7일치 Cheer Me 큐를 통째로 cancel + reschedule 하던 비용을 제거했습니다. 신규 notification_diff_planner.dart는 getPendingNotifications()로 추출한 현재 상태와 새 plan을 결정적 ID 기준으로 비교하여 변경된 알림만 cancel/reschedule 합니다. 동일 plan 재적용 시 platform channel 호출 0건을 보장하며, 캐시 적중은 reminder_unchanged analytics 이벤트로 모니터링됩니다.
최적화 작업의 객관적 검증을 위해 측정 인프라부터 구축했습니다. firebase_performance ^0.10.0+11를 도입하고, PerformanceTraces.measure() 헬퍼로 TimelineTask(local DevTools)와 Firebase Trace(prod 텔레메트리)를 동시에 래핑합니다. db.getAllDiaries, groq.analyze, notification.applySettings, first.diaryList.paint 4개 핵심 trace 정의. prod에서만 collection enable로 debug 빌드 노이즈를 차단합니다.
Vision 응답(약 1500토큰, 4KB+)의 메인 isolate 파싱이 일으키던 프레임 드롭을 해결했습니다. AnalysisResponseParser의 진입점을 top-level 함수로 추출하고 compute() API로 isolate에 오프로드했습니다. 4KB 미만 작은 응답은 isolate 생성 비용을 피해 메인에서 처리하며, isolate 실행 실패 시 메인 fallback으로 안정성을 보장합니다.
단일 시점 reminder를 7일치 일별 큐로 재설계했습니다(+1176/-322 lines). 자가응원 메시지 변경, 사용자 이름 변경, 시간 변경 등 다양한 트리거에서 큐 전체를 멱등적으로 재생성하며, 새로운 requiresCheerMeQueueRebuild() 게이트로 불필요한 재생성을 차단합니다. getRandomMindcareBody() 폴백 로직 정비로 빈 메시지 알림 발생 가능성도 제거했습니다.
분석 직후 provider.invalidate()로 SQLite 풀스캔이 발생하여 발생하던 새로고침 깜빡임을 제거했습니다. DiaryListController.addOrUpdateDiary()를 신설해 메모리 상태를 직접 갱신하며, DiaryAnalysisController는 invalidate 대신 이 메서드를 호출하도록 변경되었습니다. 결과적으로 일기 분석 완료 → 목록 화면 표시까지 SQLite I/O가 0회 발생합니다.
이전 리팩토링 과정에서 누락된 retry 로직을 복원했습니다. 5xx 응답과 타임아웃에 대한 지수 백오프 재시도가 다시 활성화되어, Groq API 일시 장애 시에도 분석이 안정적으로 완료됩니다. 테스트 472줄을 전면 재구성하여 retry 시나리오(횟수, 백오프, 최종 실패 등)를 명시적으로 검증합니다.
Groq 무료 티어 8K TPM 제약으로 2장 이상 사진 첨부 시 413 오류가 재현되는 문제를 에뮬레이터 실측으로 확인한 뒤, 저장(5장)과 API 전송(1장)을 분리하는 방어적 설계로 해결했습니다. Vision payload는 384px JPEG로 별도 다운스케일하되 저장본 품질은 유지하고, 413/429 실패 시 Repository 레이어에서 텍스트 분석으로 자동 폴백합니다. Clean Architecture 관점에서 DataSource(클램프) → Repository(폴백) → Presentation(안내 문구)로 책임을 계층 분리했으며, integration smoke test + Marionette UI E2E로 검증했습니다. 외부 API 한도를 앱이 흡수하는 실무 패턴 사례입니다.
v1.4.57에서 도입한 Qwen Vision 모델(qwen3.6-27b)의 실사용 중 400 오류(json_validate_failed, Too many images)를 실측·재현 후 근본 원인을 분석해 수정했습니다. thinking 모드가 completion 예산을 소진하는 문제 → reasoning_effort: none 적용, Groq 3장 이미지 제한 → datasource 레벨 클램프, 413 TPM 초과 → 사용자 친화적 오류 메시지. TDD로 회귀 테스트 2건을 추가해 API payload 계약을 고정했습니다. 외부 API 제약을 앱 레이어에서 흡수하는 방어적 설계 패턴의 사례입니다.
Groq 폐기 모델 대응으로 텍스트 분석 모델을 openai/gpt-oss-120b, 이미지 분석 모델을 qwen/qwen3.6-27b으로 교체. reasoning 모델 특성을 반영해 max_completion_tokens 상향 + 파라미터 최적화(텍스트 전용). 에뮬레이터 실증 테스트로 JSON 품질, 한국어 응답, 위기 감지 경로(is_emergency) 모두 검증 완료. 사용자 영향 최소화 + 비용 효율 향상.
모든 P0/P1 작업을 RED-GREEN-REFACTOR로 진행했습니다. notification_diff_planner_test.dart 8건(동일 plan 0-call 검증), groq_cache_key_test.dart 9건(해시 결정성·정규화), groq_analysis_cache_test.dart 7건(CRUD + LRU + emergency 제외), diary_repository_impl_test.dart +254줄 등 신규 41건을 포함해 1696/1696 통과를 유지하며 flutter analyze 클린입니다.
Self-Encouragement 시스템에 시간대 기반 메시지 필터링을 구현했습니다. MessageRotationMode.timeAware 선택 시 morning(5-11h)/afternoon(12-17h)/evening(18-4h)로 분류하여 시간대에 맞는 메시지를 우선 전달합니다. 매칭 메시지 없을 시 전체 풀 폴백을 포함한 안전장치도 설계했습니다. 설정 UI에 '시간대 맞춤 선택' RadioListTile을 추가하고, 메시지 입력 다이얼로그에 ChoiceChip 4종(전체/아침/오후/저녁) 시간대 태깅 UI를 구현했습니다.
메시지 선택 로직이 UseCase와 Service 두 곳에 중복되어 있던 구조적 문제를 해결했습니다. GetNextSelfEncouragementMessageUseCase + 테스트 총 485줄을 삭제하고, NotificationSettingsService를 유일한 메시지 선택 경로로 통일했습니다. 이로써 emotionAware/timeAware 로직 변경 시 단일 수정 지점만 관리하면 되는 구조가 확립됐습니다.
selectMessage() 단위 테스트 6케이스(시간대 필터링 경계값, emotionAware 가중치 검증)와 MessageInputDialog 위젯 테스트 17건(timeCategory 선택/해제, 수정 모드 프리로드, record 반환값 검증)을 추가했습니다. 전체 테스트 1,633건 통과, flutter analyze 0 errors를 유지합니다.
EmpathyMessage가 항상 SingleChildScrollView 안에 렌더링됨에도 maxLines: 4 + AnimatedCrossFade + TextPainter 측정으로 내부에서 truncation을 유발했습니다. 렌더링 컨텍스트를 분석해 불필요한 상태 관리를 전면 제거하고 StatelessWidget으로 전환했습니다. 코드 90줄 → 62줄, HapticFeedback·AppDurations import 삭제.
4개 독립 원인이 동시에 작용한 복합 버그를 체계적으로 분석하고 수정했습니다. (D) 정규식 [,의은을이]? → (?:[,의은을이]|에게|께)? alternation. (C) getRandomReminderTitle() userName 인자 전파 누락. (B) valueOrNull AsyncLoading → await .future. (A) hasPlaceholder 검사로 bake-in 리터럴 강제 재스케줄.
온보딩
일기 목록
일기 작성
마음 달력
감정 추이
키워드 분석
AI 캐릭터
설정
MindLog와 함께 나의 감정을 기록하고 이해해보세요.