콘텐츠로 이동

첫 구현 조각

첫 구현은 Life OS 전체가 아니라 Energy Cockpit + Quest Compiler만 만든다.

첫 화면은 세 구역이면 충분하다.

구역목적
상태 선택지금 상태를 저전압, 과열, 헌터모드, 회피중, 산만함 중 하나로 고름
Quest 후보 3개앱이 지금 착수될 확률이 높은 행동만 보여줌
라운드 패널10분 timer, 한 줄 목표, fallback route, reward

Task에는 최소한 다음 필드가 필요하다.

필드예시
title기획서 완성
domainwork
energy_costmedium
interest_score2
friction_score4
novelty_score1
reward_typevisible_output
deadline_at2026-06-21 18:00
statusinbox / ready / active / done

Fibery를 참고하면 여기서 중요한 점은 Task를 평평한 todo row로 끝내지 않는 것이다. 첫 버전에서는 필드를 적게 두되, 나중에 관계를 붙일 수 있는 object로 저장한다.

관계 후보왜 필요한가
task -> domainwork, health, money 같은 생활 영역별 부하를 보기 위해
task -> energy_state_history어떤 상태에서 어떤 task가 잘 먹혔는지 학습하기 위해
task -> reward보상 패턴과 실행률을 연결하기 위해
task -> source_contextcalendar, note, file, browser context와 이어 붙이기 위해
quest -> session변환된 quest가 실제 라운드에서 먹혔는지 추적하기 위해

Quest는 task에서 파생된다.

필드예시
task_id원본 task
quest_title첫 문단에 공격로 하나 만들기
entry_action문서 열고 제목 아래 첫 문장 하나 쓰기
timebox_minutes10
fallback_action목차 3개만 쓰기
reward_label보이는 산출물 확보

LLM 없이도 먼저 rule-based로 충분하다.

score =
urgency_bonus
+ interest_score * 3
+ novelty_score * 2
+ reward_immediacy * 3
- friction_score * energy_state_weight
- energy_cost_mismatch

상태별 weight:

상태추천 기준
저전압friction 낮고 reward 즉시 오는 task
과열scope 작고 recovery route가 있는 task
헌터모드value 높고 challenge 있는 task
회피중원래 task를 우회하는 proxy action
산만함timebox 짧고 환경 정리가 쉬운 task
  • work/life task capture가 키보드 중심으로 빨라야 한다
  • calendar, browser, editor, file context를 나중에 local signal로 연결할 수 있다
  • privacy-first sensing을 cloud보다 local app에서 시작하기 쉽다
  1. task를 10개 넣을 수 있다
  2. 상태 하나를 고르면 quest 3개가 나온다
  3. quest 하나를 시작하면 10분 라운드가 열린다
  4. 끝나면 done/fork/retry/recover 중 하나를 기록한다
  5. 앱은 “성공률”이 아니라 “잘 먹힌 route”를 보여준다

MVP에는 넣지 않지만, 데이터는 아래 view를 만들 수 있게 쌓는다.

View질문
Energy map저전압/과열/헌터모드별로 어떤 quest가 잘 먹혔나
Domain load어느 생활 영역이 에너지를 과하게 먹고 있나
Reward graph사용자가 실제로 반응하는 보상 패턴은 무엇인가
Recovery routes실패 후 재진입에 성공한 루트는 무엇인가
Quest compiler log원래 task가 어떤 quest 문법으로 바뀌었나