S9 · REF살아 있는 서비스들 — 렌즈별

생애 타임라인 (여정의 직접 이웃)

Timestripe · Aeon Timeline · Preceden · TimelineJS · Life-in-weeks

여정(타임라인)은 우리 제품의 척추다. 그 척추를 이미 세운 제품들 — 삶과 목표를 시간축에 얹는 도구들 — 이 여기 모인다. Timestripe 는 하루부터 인생까지 '지평(horizons)'을 오르내리고, Aeon Timeline 은 사건에 인물·아크를 연결한다. 이들은 우리 여정의 시간스케일 전환Event+Involvement 모델에 가장 가까운 선례지만, 돈·인터뷰와는 분리된 채 각자 시간만 다룬다.

무엇인가

'생애 타임라인'은 하나의 제품 범주가 아니라, 시간을 1차 축으로 삼아 사건·목표·기억을 배치하는 도구들의 무리다. 이 무리는 성격이 갈라진다 — 계획을 얹는 목표형(Timestripe), 서사를 구성하는 저작형(Aeon Timeline·Preceden·TimelineJS), 유한성을 시각화하는 격자형(Life-in-weeks 계열)이다.

제품강점우리와의 차이
Timestripe오늘·주·월·연·인생의 다섯 '지평'을 오르내리며 같은 목표를 다른 시간 스케일에서 본다. 산 등반 은유(먼 목표=정상)로 줌 전환에 감정을 입힌다.미래 목표 관리가 중심 — 과거 사건의 축적·회상은 부차적. 돈·사람 성분 없음.
Aeon Timeline작가용. 사건에 인물·장소·아크(arc)를 연결하고 관계를 그린다. Scrivener 연동으로 집필과 연대기를 오간다.허구 서사 설계 도구 — 관계선을 명시적으로 미리 긋는다. 우리는 관계를 비워 두고 출발(창발).
Preceden웹 기반 범용 타임라인 저작. 레이어·다중 타임라인, 근래엔 AI 생성. 발표·교육용 산출에 강하다.보여주기(consume) 위주 — 삶을 채우는 유도가 없다.
TimelineJSKnight Lab(노스웨스턴)의 오픈소스. 구글 시트 한 장으로 미디어 풍부한 스크롤 타임라인을 만든다. 저널리즘 표준.발행 도구 — 데이터는 사용자가 손으로 채워 넣은 뒤 굳는다. TimelineJS 항목 참조.
Life-in-weeks 계열인생을 주(週) 단위 격자(≈4,000칸)로 펼쳐 남은 시간을 한눈에 보인다. Entire.Life 등 소품이 있다(요확인).단일 시각화 위젯 — 사건 데이터 모델이 얕거나 없다.

Timestripe 가 이 무리에서 우리와 결이 가장 가깝다. 지평(horizons)은 단순한 줌이 아니라 같은 대상을 다른 시간 해상도로 보는 렌즈 — 오늘의 할 일과 인생의 목표가 하나의 연속체 위에 있다는 감각을 UI 로 구현했다. Aeon Timeline 은 반대 방향에서 우리와 만난다 — 시간축 위의 점(사건)에 누가 연루되었는지를 1급 데이터로 다루는, 드문 상용 제품이다.

우리 모델과의 접점

이 항목은 개념 모델의 여정(타임라인) 렌즈가 시장에서 어떤 모습으로 이미 살아 있는지를 비추는 거울이다. 두 접점이 특히 날카롭다:

제품의 축우리 개념근거 장·엔티티
Timestripe 의 지평 전환(일↔인생)여정의 시간스케일 전환 — 같은 단일 소스를 다른 해상도로 투영제5장 렌즈 · 원칙 7(저장보다 파생)
Aeon 의 사건 + 인물 + 아크Event + Involvement — 사건에 등장인물을 연루로 붙임제2장 사건 · 제4장 참조(Link)
Life-in-weeks 의 유한한 격자남은 시간을 배경으로 깐 여정 — 시대(index)의 장(章) 위시대(index) · 무대(Place)

다만 결정적 차이가 하나 있다. Aeon 은 인물 사이의 관계선(arc)을 먼저 긋고 사건을 배치한다 — 소설 설계에는 맞다. 우리는 반대로 Link.relationType 을 비워 두고 출발한다(제4장, 창발). 관계는 사건이 쌓인 뒤 2차 렌즈(역참조)로 드러나야 하는 것이지, 사용자가 미리 선언할 스키마가 아니다. Timestripe 의 지평도 마찬가지 — 그것은 줌(시간 해상도)이지 시대(삶의 의미 단위)가 아니다. 이 둘을 UI 에서 헷갈리면 사용자는 '오늘 뷰'와 '유년기'를 같은 서랍에 넣게 된다.

이 넷은 시간만 안다. §11 의 큰 그림 — 사건을 단일 소스로 두고 시간·돈·사람·질문을 한 몸으로 잇는 통합 서비스는 없다 — 에서 이들은 시간 축 하나를 맡는다. Timestripe(시간)·ProjectionLab(돈)·Storyworth(질문→책)·Clay(사람)를 나란히 놓으면, 우리 일은 그 축들을 각각의 앱이 아니라 하나의 Event 위에 얹는 것임이 선명해진다.

생각할 거리

  1. 지평(줌)과 시대(장)를 분리할 것인가 겹칠 것인가. Timestripe 의 지평은 시간 해상도이고, 우리 시대(index)는 의미 단위다. 사용자가 '유년기'라는 시대를 만들면서 동시에 '연 단위 줌'으로 보고 싶어 할 때, 두 축이 한 화면에서 충돌하지 않게 하려면? Cartographies of Time 의 연표 계보와 인생 격자 가 이 두 축을 시각적으로 어떻게 분리해 왔는지 참조.
  2. 관계선을 미리 긋게 할 것인가. Aeon 의 arc 는 강력하지만 선(先) 선언을 요구한다. 우리는 relationType 을 비우고 출발하는데(제4장), 사용자가 "이 사람과 저 사건을 잇고 싶다"는 욕구를 언제 어떤 UI 로 받을지가 미설계다. 2차 렌즈로만 드러낼지, 명시 연결도 허용할지 — 액션8(제품 지형 검증)에서 Aeon 실사용 관찰이 필요.
  3. 격자의 유한성을 배경으로 깔 것인가. Life-in-weeks 는 "칸이 줄어든다"는 실존적 압박을 시각화한다. 여정 배경에 남은 주(週)를 은은히 깔면 사천 주 의 정서를 얻지만, 절제된 넛지 철학(다그치지 않는 개입)과 충돌할 수 있다. 압박과 초대의 경계.
  4. 저작형과 채움형의 갈림. Preceden·TimelineJS 는 사용자가 다 아는 것을 정리하는 도구다. 우리 강점은 반대편 — 인터뷰로 모르는 빈칸을 끌어내는 엘리시테이션(제8장)이다. 시장의 저작형 제품이 왜 '삶'까지 오지 못하는지가 우리 차별점의 근거다. Tufte 의 정보 밀도 원칙은 산출(표시)에는 걸리지만 채움(입력)에는 걸리지 않는다.
  5. 시간만 다루는 제품의 천장. 이 넷 중 어느 것도 돈·사람을 같은 사건에 묶지 못한다. Timestripe 로 은퇴 목표를 세워도 여비(돈) 는 옆 앱에 있다. 통합의 부재가 시장 공백인지, 아니면 통합이 필요 없다는 신호인지 — 액션8 이 검증할 첫 질문.

더 찾아보기

  • Timestripe(timestripe.com) — '지평(horizons)' 전환과 등반 은유를 직접 체험하는 것이 문서보다 빠르다. 우리 시간스케일 전환의 감각적 기준점.
  • Aeon Timeline(aeontimeline.com) 3.x — 사건·개체(entity)·아크(arc)·관계 모델과 Scrivener 연동. Event+Involvement 의 상용 선례로 데이터 구조를 뜯어볼 것.
  • TimelineJS(Knight Lab, timeline.knightlab.com) · Preceden(preceden.com) — 저작형 두 극단. 오픈소스와 SaaS.
  • 검색: Timestripe horizons life planning · Aeon Timeline entities arcs relationships · "life in weeks" calendar app Entire.Life — 마지막 것은 격자형 소품 현황(요확인).
  • 같은 장의 이웃 & §7 타임라인: Cartographies of Time(연표의 역사), Tufte(정보 밀도), Your Life in Weeks(유한성 격자), TimelineJS·Facebook Timeline(발행형 선례) — 짝으로 읽는다. 돈 렌즈로 넘어가려면 돈의 미래.

내 생각

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