S9 · REF자료 → 백로그로

제품 지형 검증 리서치 (§11)

Entire.Life · Exist.io · Timestripe · ProjectionLab 근황 확인

§11 제품 지형에는 "요확인"이 붙은 항목이 있다 — 존재 자체가 불확실한 소품, 근황을 모르는 서비스, 최신 기능을 못 따라간 도구들. 이 액션은 그 표기를 웹 확인으로 해소한다. 상태 불확실 항목(Entire.Life 등 life-in-weeks 소품, 한국 자서전 디지털 서비스 유무, Exist.io 생존)을 확인하고, Timestripe·ProjectionLab 같은 살아 있는 도구의 최신 기능을 훑는다. 제품은 죽고 생기니, 지형은 정기적으로 갱신되어야 한다.

무엇인가

이 항목은 참고 자료가 아니라 리서치 액션이다 — 개념 종합이 아니라, §11 제품 지형표의 불확실을 사실로 바꾸는 손품이다. 다른 액션(⑤~⑦)이 설계 스파이크라면, 이것은 검증이다. 이유는 단순하다: 제품 지형은 로드맵 판단의 근거인데, 근거에 "요확인"이 남아 있으면 판단이 흔들린다. 특히 정면 경쟁과 인접 영감을 가르려면 각 서비스의 현재 모습을 알아야 하고, 소프트웨어 제품의 현재는 6개월이면 낡는다.

검증 항목렌즈(§11)확인 질문
Entire.Life 등 life-in-weeks 소품생애 타임라인 / Your Life in Weeks존재·유지 여부, Four Thousand Weeks·주 단위 시각화 계보 위 위치
한국 자서전 디지털 서비스 유무질문→기록→책국내 시장에 Storyworth 형 서비스가 있나 — 있다면 언어·문화 적합의 선례
Exist.io 근황자동 라이프로깅상관분석형 개인 대시보드가 생존해 있나 — 자동 수집의 배신(§12 c2)을 어떻게 견뎠나
Timestripe 최신 기능생애 타임라인(미래·지평 계획)Horizons(일·주·월·년·평생 지평) 개념의 변화 — 미래 축을 어떻게 다루나
ProjectionLab 최신 기능돈의 미래재무 시나리오·몬테카를로 모델링의 근황 — 우리 여비 곡선과 겹치는 정도

왜 지금인가. §11 지형이 렌즈별로 정리된 지금, "요확인" 표기가 인덱스에 남아 있다. 이 표기는 지도 작성자가 정직하게 모른다고 적어 둔 자리이지, 확인 불가라는 뜻이 아니다 — 대부분 웹 검색 몇 번이면 해소된다. 위 다섯 항목은 상태가 특히 불확실하거나(존재 자체 요확인), 빠르게 변하는(최신 기능 요확인) 것들이다.

우리 모델과의 접점 — 무엇을 확인하고 어떻게 반영하나

이 리서치는 §11 제품 지형과 §12 부검을 잇는다. 각 항목을 확인할 때 존재 여부만이 아니라 부검이 지목한 사인(c1~c8)을 그 서비스가 어떻게 피했나/못했나를 함께 본다 — 살아 있는 서비스는 죽은 서비스가 주지 못한 교훈을 준다:

확인 항목확인의 종류지형·부검에 반영
life-in-weeks 소품존재 자체 요확인정적 포스터형(입력 없는 시각화)은 우리 동적 모델과 다른 종 — 경쟁이 아니라 계보로 정리
한국 자서전 서비스국내 시장 공백/선례청중 착오(c3)·언어 적합의 국내 사례 — 있으면 벤치마크, 없으면 공백
Exist.io 생존근황 요확인자동 수집의 배신(c2)을 견딘 생존자인지, 축소·매각·종료인지
Timestripe최신 기능 훑기미래 지평(Horizons)을 다루는 드문 도구 — 배정×시대·미래 축 설계의 참조
ProjectionLab최신 기능 훑기재무 시나리오의 정면 인접 — 돈의 미래 렌즈와 여비 곡선의 실질 경쟁 여부

확인의 태도는 정직한 표기다. 인덱스가 "요확인"으로 불확실을 드러냈듯, 리서치 결과도 확인된 것과 여전히 불확실한 것을 구분해 적는다 — 없는 서비스를 있다고 하거나, 옛 기능을 최신이라 단정하지 않는다. 소프트웨어는 언제든 종료·피벗하므로, 확인에는 날짜가 붙어야 한다(이 리서치는 2026-07 기준).

산출 — §11 지형표의 "요확인" 해소 + 렌즈별 최신 근접 서비스 갱신. 다섯 항목의 존재·근황·최신 기능을 확인해 인덱스 §11 에 반영하고, 확인 날짜를 명기한다. 다음 스텝: 살아 있는 각 서비스가 부검 사인(c1~c8)을 어떻게 다뤘는지 한 줄씩 대조 — 지형(§11)과 부검(§12)이 서로를 갱신하게 한다. 이 리서치는 1회성이 아니라 정기 갱신 후보(지형은 낡는다).

생각할 거리 — 결정 과제

  1. "요확인"을 언제까지 방치하나. 제품 지형은 신선도가 생명이다 — 확인해도 6개월이면 다시 낡는다. 이 리서치를 1회성으로 끝낼지, 정기(분기·반기) 갱신 루틴으로 걸지. 후자라면 확인 항목마다 "마지막 확인일"을 인덱스에 남기는 형식이 필요하다.
  2. 정면 경쟁과 인접 영감의 구분선. ProjectionLab(재무 시나리오)은 돈의 미래 렌즈에서 정면에 가깝고, life-in-weeks 소품은 정적 시각화라 종이 다르다. 어느 서비스가 우리와 같은 사용자·같은 문제를 겨누는가를 렌즈별로 판정하는 기준을 세울 것 — 경쟁은 기능 목록이 아니라 대체 가능성으로 갈린다.
  3. 부검과의 대조를 강제할 것인가. 살아 있는 서비스는 여덟 사인(c1~c8)을 어떻게든 피했다는 뜻이다 — 그 방법이 우리에게 가장 값진 데이터다. 존재 확인에 그치지 말고 "이 생존자는 c△를 어떻게 다뤘나"를 각 항목에 필수 필드로 붙일지. 액션7이 대응하는 보상 지연(①)을 이들이 어떻게 푸는지가 특히 직접적 참조다.
  4. 정적 소품을 지형에 남길 이유. Entire.Life 류 life-in-weeks 포스터는 입력·계정·산출이 없는 정적 시각화다 — Your Life in Weeks·Four Thousand Weeks의 계보. 우리 동적 모델과 경쟁하지 않는데도 지형에 두는 이유는 무엇인가 — 사용자가 "인생을 한눈에"라는 기대를 어디서 얻는지의 문화적 앵커이기 때문이다. 경쟁표가 아니라 계보표의 자리.
  5. 국내 서비스 공백의 해석. 한국에 Storyworth 형 자서전 서비스가 없다면, 그것은 기회인가 시장 부재의 신호인가. 청중 착오(c3)가 경고하듯 "누구를 위한 기록인가"가 문화마다 다르므로, 공백을 곧장 기회로 읽지 말고 왜 비었는지를 함께 물을 것.

더 찾아보기 — 근거 자료

  • 근거 참고 페이지(렌즈별 지형): 생애 타임라인(Timestripe·life-in-weeks) · 돈의 미래(ProjectionLab) · 질문→기록→책(한국 자서전 서비스) · 자동 라이프로깅(Exist.io) · Your Life in Weeks(정적 소품의 원형).
  • 내부 문서: 개념 모델 §11(제품 지형)·§12(부검 c1~c8) · 지도 인덱스의 "요확인" 표기 항목.
  • 검색: Entire.Life life in weeks app · Exist.io status shutdown 2025 · Timestripe horizons life planning · ProjectionLab features monte carlo · 자서전 서비스 질문 기록 책 한국 — 존재·근황·최신 기능이 걸린다. 확인 결과에는 날짜를 붙일 것.
  • 이웃 액션: 첫 2주 경험 설계(1SE·Storyworth·족보의 최신 상태 확인이 이 리서치에 포함) · 배정×시대 결합 기능 탐색(ProjectionLab·Timestripe의 미래 축 처리가 참조). 대조 기준은 부검 c1~c8 전체.

내 생각

이 메모는 지도 페이지의 같은 항목과 공유되며, 이 기기(브라우저)에 저장됩니다.