Concrete First

"짐작을 아키텍처로 만들지 마. 아무도 재방문 안 하는 짐작이 우발적 아키텍처가 태어나는 방식이야."

성급한 확신에 맞서는 규칙

Waystone 아키텍처 문서는 자기 자신한테 특이한 지시를 실어. 미해결 질문을 명시적으로 열어둬라. 프레임워크랑 벤더랑 저장에 대한 짐작을 우발적 아키텍처로 만들지 마라. 그게 concrete-first 원칙이야. 진짜 vertical slice가 그 결정을 유용하게 만들기 전엔 DB도, 지도 provider도, 배포 토폴로지도 안 골라. 결정이 나빠서가 아니라, 증거 전에 내린 결정은 결정의 옷을 입은 짐작이라서야. 아무도 짐작이라 표시 안 한 짐작은 나중에 다들 추론된 거라 여기는 아키텍처로 굳어버리거든.

실제로 이게 어떻게 보이나

v0 엔진은 DB schema로 시작하는 대신 journey를 평범한 파일로 저장해. journey record, plan 문서, append-only breadcrumb 로그. geocoder랑 지도 타일은 v0 선택으로 이름 붙고, 엔진 자기 endpoint 뒤에서 명시적으로 교체 가능해. 그리고 문서는 늘 Open Decisions 목록을 유지해. 마이그레이션 도구, routing이랑 고도 provider, 오프라인 packet 저장, 충돌 해결 표면, native 클라이언트 임계값. 각각이 정직한 답이 '아직 미정'인 자리고, 조용히 기본값으로 흘러가는 대신 그렇게 적혀 있어.

왜 명시적 목록이 중요해

모든 프로젝트가 잠정적 선택을 해. 드문 건 어떤 선택이 잠정적이었는지 적어두는 것이야. 그 목록이 미래 독자, 그러니까 미래의 아빠랑 미래의 Pippa랑 미래의 너한테, '이유가 있어서 골랐다'랑 '그냥 움직이려고 집었다'를 구별하게 해줘. 목록이 없으면 6개월 뒤 코드에서 둘이 똑같아 보이고, 아무도 두 번째 종류를 못 건드려. 첫 번째일 수도 있으니까. Open Decisions 섹션은 우유부단이 아냐. 아키텍처가 아직 움직여도 되는 곳의 지도야.

Code

잠정 vs 결정 — 어느 쪽인지 말해·text

결정됨 (slice 가 증명함)
  cwkPippa 가 뇌를 소유         # invariant, 논쟁 대상 아님
  plan/actual 절대 안 합침       # invariant
  캡처는 로컬에 먼저 커밋        # invariant

V0 선택 (교체 가능, 우리 endpoint 뒤에서)
  DB 아직 아니고 파일 store      # 진짜 slice 가 말해줄 것
  이 geocoder, 이 지도 타일      # 호출자 안 건드리고 교체

OPEN DECISION (정직하게 미정, 적어둠)
  마이그레이션 도구 + 현재 store 를 언제 넘어설지
  routing / 고도 / 오프라인 지도 provider
  갈라진 편집의 충돌 해결 UX
  native 클라이언트의 증거 임계값

# 가치는 LABEL 이야. 없으면 6개월 뒤 짐작과 결정이
# 똑같아 보이고, 아무도 어느 쪽도 못 건드려.

Exercise

네가 일하는 프로젝트를 열고 오늘 load-bearing인 기술 선택 세 개를 찾아. 각각에 정직하게 물어. 증거에서 추론됐어, 아니면 움직이려고 일찍 집고 재방문 안 했어? 이제 그 구별이 적힌 곳이 있는지 찾아봐. 없으면, 그 코드베이스의 모든 잠정 선택이 조용히 아키텍처로 승격된 거야.

Hint

징후는 '왜 이렇게 돼 있지?' 물었을 때 답이 '늘 그랬어'인 거야. 그건 라벨 안 붙은 채 굳어버린 짐작이야. 그때 옆에 '이건 v0 선택, 교체 가능'이라 쓰는 건 한 줄 비용이고, 다음 사람이 네 지름길을 교리로 취급하는 걸 막아.