엔진 먼저, sidecar는 나중

"엔진과 첫 클라이언트로 계약을 검증해. 두 번째 sidecar는 그다음이야."

순서가 곧 레슨

API-first는 경계를 어디에 긋는지만 말하지 않아. 무엇을 어떤 순서로 검증할지도 정해. Bonfire는 먼저 엔진의 얇은 vertical slice와 공개 계약을 만들고, 내장 UI를 첫 소비자로 붙여 둘을 함께 다듬어. 여기서 중요한 건 엔진을 최종 완성한 뒤 UI를 시작하는 게 아냐. 진짜 클라이언트가 계약의 빈틈을 드러내게 하되, Sidekick의 깊은 기능이나 미래 Live 브리지처럼 두 번째 요구까지 동시에 끌어들이지 않는 거야.

왜 두 번째 sidecar를 일찍 안 짓나

Live 브리지나 화려한 코칭 모드처럼 신나는 sidecar를 첫 vertical slice와 나란히 짓고 싶을 수 있어. 하지만 아직 첫 클라이언트도 검증하지 못한 계약에 소비자를 여럿 붙이면 변경 비용이 모든 방향으로 번져. 반대로 API를 너무 일찍 얼리면 첫 UI가 찾아낸 진짜 요구를 반영하기 어려워져. 답은 '엔진을 완성하고 얼린 뒤 소비자를 시작'이 아니라, 엔진과 첫 클라이언트로 한 경계를 함께 검증하고 그 경계가 안정된 뒤 두 번째 소비자를 더하는 것이야.

예측이 아니라 concrete-first

Track 8에서 다시 만날 '미리 일반화하지 마'와 같은 규율이야. 첫 소비자가 실제로 필요한 계약을 보여주기도 전에 두 번째 소비자의 상상 속 요구를 설계하지 않아. 눈앞의 진짜 클라이언트인 UI와 엔진이 작은 end-to-end 흐름을 완성하고, 그 흐름에서 확인된 경계를 다음 클라이언트가 쓸 수 있게 정리해. concrete-first란 생산자와 소비자를 억지로 직렬화하는 태도가 아니라, 한 번에 검증할 구체 사례를 하나로 제한하는 태도야.

Code

vertical slice 하나로 계약을 검증한 뒤 다음 소비자로·text

Bonfire:  얇은 엔진 slice ─┬─→ 공개 계약 ─┬─→ 내장 UI
                            └──── 피드백 ────┘
                                      │ 계약이 실제 흐름에서 안정됨
                                      └─→ (나중) Sidekick / Live 브리지

# 엔진을 최종 완성한 뒤 UI를 시작하는 게 아냐.
# 엔진 + 첫 클라이언트로 한 경계를 검증한 뒤 두 번째 소비자를 더해.

Exercise

API와 소비자를 함께 지은 프로젝트를 떠올려 봐. 첫 소비자가 계약을 더 좋게 만든 변경과, 두 번째·세 번째 소비자까지 동시에 붙여서 생긴 재작업을 나눠 적어. 다음에는 어떤 vertical slice 하나로 계약을 먼저 검증하고, 어느 신호가 오면 다음 소비자를 붙일지 정해 봐.

Hint

첫 클라이언트의 피드백은 계약을 찾아내는 데 꼭 필요해. 흔들림은 검증되지 않은 계약에 소비자를 여럿 붙였을 때 커져. 목표는 생산자와 소비자를 완전히 줄 세우는 게 아니라, 한 번에 움직이는 변수를 줄이는 거야.