"소유권과 실패 행동을 둘 다 말해야 경계가 완성돼."
필요와 소유를 나눠
제품 경계는 앱에 없는 것으로 설명되곤 해. 가족 시스템에서는 변경을 싸게 만드는 것이기도 해. 브레인 주인 하나, 목소리 주인 하나, 크롬 주인 하나, 글쓰기 orchestrator 하나 말이야.
경계를 건너는 모양
요청 방향과 데이터 권한, 재시도 책임, 실패 행동이 있는 ownership map을 써. Inkwell은 entry와 job state를, 형제는 자기 능력을 소유하고 경계에는 canonical data 복사본 대신 reference가 건너가.
복제의 유혹
모호한 공유는 고아 실패를 만들어. 양쪽이 서로 retry와 저장, 삭제를 할 거라 생각하지. 과한 소유는 시스템을 복제하고 부족한 소유는 책임자를 없애. 경계는 handoff와 돌아오는 길을 둘 다 말해야 해.
요청과 참조만 건너가
이 경계를 감사할 때 code import만 보지 마. 어떤 요청이 어느 주인에게 가고, 결과가 값인지 managed reference인지, 실패와 retry를 누가 설명하는지 따라가. credential과 canonical history, voice catalog 같은 주인 데이터가 Inkwell 안에 복사돼 있으면 편한 integration이 아니라 두 번째 시스템이야.
직접 경계표를 써
Inkwell dependency마다 누가 retry하고 누가 실패를 보여주는지까지 ownership table을 만들어. 정상 성공뿐 아니라 timeout과 stale output, sibling unavailable, schema mismatch도 넣어. 양쪽이 서로 처리할 거라고 가정하는 빈칸이 하나라도 있으면 그게 다음 장애의 주인이야.
덜 소유할수록 더 자기다워져
Inkwell의 정체성은 브레인이나 목소리 엔진을 새로 만드는 데 있지 않아. 원문 우선 흐름과 펜 없는 리뷰, 필사 화면, 늦은 결과의 착지 규칙을 한 경험으로 묶는 데 있어. 경계는 제품에서 빠진 부분이 아니라 그 조합을 가능하게 하는 기능이야.
이 경계의 실제 payload
ownership map 한 줄에는 canonical data와 요청 방향, 돌아오는 reference, retry 책임, 사용자에게 실패를 보여줄 주인이 같이 있어야 해. 정상 성공만 적은 표는 반쪽짜리야. sibling unavailable일 때 누가 어떤 state를 남기는지까지 써야 실제 경계가 돼.
복붙한 능력은 잠깐 가깝지만 canonical 주인과 갈라지는 순간 가장 먼 dependency가 돼. 요청과 provenance-bearing reference만 경계를 건너게 해.