빌리지 말고 지어라

"빌린 itinerary 앱은 일부러 널 잊어. 그 망각이 제품이야."

시장은 꽉 찼는데, 비어 있어

여행 소프트웨어는 넘쳐나. TripIt은 예약 확인 메일을 타임라인으로 파싱하고, Wanderlog는 예쁜 날짜별 itinerary를 짜고, Google Trips는 접기 전까지 지도랑 예약을 다뤘고, Notion 템플릿은 뭐든 담아. 근데 왜 또 지어? 그것들이 다 itinerary 앱이고, itinerary 앱은 구조적으로 기억상실이거든. 이번 여행 정리는 도와주는데, 여행이 끝나면 그 지식은 다시 안 여는 아카이브로 가라앉아. 시장은 여행 정리기로 포화됐고, 여행 기억은 텅 비었어.

그 데이터 모델, 누구 거야?

빌리면 데이터 모델은 벤더 거야. 네 여행이 벤더 schema에 살고, 벤더 query에 답하고, 벤더가 보여줄 만하다고 정한 것만 드러나. 빌린 앱한테 '네 번 여행 다니면서 계획했다 계속 건너뛴 데가 어디고 왜야?'라고 물어봐. 그 질문에 맞는 형태 자체가 없어. 여정 여러 개를 가로질러 추론하라고 지은 게 아니라 하나 정리하라고 지었으니까. 엔진을 소유한다는 건 schema를 소유한다는 거야. 장소가 여행마다 다른 뜻이라고, 추천이 rationale를 품는다고, 건너뛴 계획이 삭제가 아니라 이월된다고 네가 정해. 물을 수 있는 질문은 네가 소유한 모델이 정해.

같은 베팅, 엔진 셋

이건 Ember랑 Bonfire가 Waystone보다 먼저 한 바로 그 베팅이야. Ember는 A1111이나 ComfyUI를 빌리길 마다하고 자기 이미지 엔진을 지었어. Bonfire는 탭 서비스를 빌리거나 DAW를 선생으로 비트는 대신 자기 음악 학습 엔진을 지었고. Waystone은 itinerary 앱을 빌리길 마다하고 자기 여행 기억 엔진을 지어. 셋 다, 빌리길 마다하는 건 기능 문제가 아냐. 빌린 앱에 더 예쁜 기능 많아. 빌리길 마다하는 건 쌓인 context의 소유권 문제야. 기능을 빌리면 그 망각까지 같이 빌리는 거거든.

그렇다고 다 새로 지으란 건 아냐. Waystone도 진짜 commodity 조각은 기꺼이 빌려. 지도 타일, geocoder, 브라우저 저장 API. 선은 기억에 긋지 모든 의존성에 긋는 게 아냐. Track 7이 그 선이 어디 지나가는지를 통째로 다루는 트랙이야.

Code

빌림 vs 소유, 물을 수 있는 질문으로·text

빌린 ITINERARY 앱                소유한 여행 엔진
--------------------------------------------------------
"이번 여행 보여줘"          ->   "이번 여행 보여줘"            [둘 다]
"오늘 뭘 계획했지?"         ->   "오늘 뭘 계획했지?"           [둘 다]
"네 번의 여행에 걸쳐
 건너뛴 곳 어디고, 왜?"   ->   답 가능                       [소유만]
"모든 여정에서 엄마가
 좋아한 곳 보여줘"         ->   답 가능                       [소유만]

# schema 가 표현할 수 있는 것만 물을 수 있어.
# 앱을 빌리면 그 한계를 빌리는 거야.

Exercise

지금 빌려 쓰는(구독하는) 도구 세 개를 적어봐. 각각 물어봐. 이건 빌리는 게 맞는 commodity야, 아니면 내 거여야 할 기억을 몰래 쥐고 있어? 내 글, 내 결정, 내가 쌓은 context 말이야. 벤더가 내일 문 닫으면 데이터 잃는 게 제일 아까울 걸 골라. 그게 네 '빌리지 말고 짓기' 후보야.

Hint

테스트는 '문 닫으면?' 질문이야. 벤더가 사라져도 다른 데서 다시 빌릴 수 있는 commodity면 계속 빌려. 몇 년치 쌓인 context가 통째로 날아가는 거면, 넌 네 기억을 빌리고 있던 거고, 그건 소유할 가치가 있어.

시장은 꽉 찼는데, 비어 있어

그 데이터 모델, 누구 거야?

같은 베팅, 엔진 셋

Code

External links

Exercise

Progress

댓글 0