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 선택, 교체 가능' 이라 쓰는 건 한 줄 비용이고 다음 사람이 네 지름길을 교리로 취급하는 걸 막아.