가족 안의 플레이어

"NAS 는 미디어 바이트를 소유해. Recall 은 영상에 대한 기억을 소유해. Ashen Reel 은 재생을 소유해."

진짜 아키텍처는 seam 이야

Ashen Reel 의 아키텍처를 그리면, 유혹은 앱 안에 박스를 그리는 거야 — 파서, 엔진, 상태 저장소. 근데 이 앱을 실제로 가능하게 한 아키텍처는 앱 안에 전혀 없어. 형제들 사이의 seam 집합이야: Recall 이 신원을 넘기고, Ashen Reel 이 재생하고, cwkPippa 가 판단하고, NAS 가 바이트를 저장하고, Waygate 나 macOS 가 공유를 마운트해. 중요한 다이어그램은 화살표지, 아무 박스가 아냐.

그래서 앞 트랙들이 계속 같은 데서 끝났어 — 경계. handoff 는 Recall 과의 seam. 자막 레일은 Recall 과의 seam. 사이드킥은 cwkPippa 와의 seam. 읽기 전용 재생은 NAS 와의 seam. Ashen Reel 이 읽을 수 있는 건 형제가 소유한 걸 소유하기를 거부해서야; 그 명료함은 범위에 대한 절제의 직접적 결과야.

협력하는 부분의 시스템에서, 중요한 아키텍처는 seam 이지 아무 한 부분의 내부가 아냐. 혼자 이해할 수 있는 컴포넌트는 책임이 깔끔한 경계에서 끝나는 거야. 것들 사이의 계약을 먼저 설계해; 그럼 각 것의 내부는 거의 스스로 설계돼.

constellation 을, 진짜 모습대로 그린 것 — 계약을 실은 화살표:

깊은 도구의 가족이 mega-app 하나를 이겨. 이것의 대안은 영상을 틀고 '그리고' 아카이브를 색인하고 '그리고' AI 를 돌리고 '그리고' 공유를 마운트하는 단일 앱이었어. 거대하고, 엉키고, 일관되게 유지 불가능했을 거야. 대신 각 관심사가 계약으로 이어진 깊고 좁은 앱이야 — 애플리케이션 규모의 Unix 철학. 각 도구가 이해 가능하게 남고; 각 경계가 테스트할 수 있는 계약이고; 드리프트가 한 번에 한 seam 으로 담겨.

왜 mega-app 은 못 하는데 이건 확장되나

가족 모양은 조용한 초능력이 있어: 커가면서도 이해 가능하게 남아. 새 형제를 추가해 — 음악 엔진, 여행 플래너, 파일 워크벤치 — 그래도 기존 앱을 하나도 더 복잡하게 안 만들었어, 새 앱이 공유 내부로 엉키는 게 아니라 seam 의 계약으로 합류하니까. mega-app 은 아무도 통째를 머릿속에 못 쥘 때까지 축적으로 커. 가족은 노드를 추가해서 커, 각각 여전히 혼자 이해할 만큼 작게. Ashen Reel 이 지어지고, 나가고, 추론될 수 있었던 건 딱, 걔가 아무도 지도 못 그릴 저택에 볼트로 붙인 새 방이 아니라 constellation 의 이해 가능한 노드 하나라서야.

Code

constellation — 박스가 아니라 화살표가 아키텍처야·text

Ashen Reel is one node in a constellation, not an island:

     Recall  --( video_id + timestamp_ms )-->  Ashen Reel
     owns:                                     owns:
     identity, path, transcript,               playback, local convenience state
     releases, annotations                     (resume, prefs, recents)
       |                                          |
       | <--> cwkPippa                            | read-only
       |      (judgment, conversation)            v
       |                                         NAS  (the media bytes)
       |                                          ^
       +----------------------------- Waygate / macOS (mounts the share)

// The design is the ARROWS -- the contracts between apps -- not any one box.
// Each app is deep and narrow; the seams are where the architecture lives.

Exercise

본능적으로 큰 앱 하나로 지을 시스템을 골라서 가족으로 다시 그려: 제일 작은 깊고 단일-목적 컴포넌트 집합으로 쪼개고, 걔네 사이 화살표를 명시적 계약으로 그려(뭐가 넘고, 누가 뭘 소유). 그다음 각 컴포넌트에 물어봐: 혼자 이해되고 테스트될 수 있어? 하나가 못 하면, 걔 경계가 틀렸어. 실제론 별도 노드이고 싶은데 네가 막 엉키려던 책임이 뭐였어?

Hint

좋은 쪼갬의 테스트: 각 노드가 한 가지를 소유하고, 노드 간 모든 상호작용이 공유 내부가 아니라 seam 의 이름 붙은 계약이야. '컴포넌트' 둘이 독립적으로 추론 안 되면, 걘 진짜 하나거나 — 둘 사이 경계가 엉뚱한 데 있어. 화살표를 먼저 설계해; seam 이 깔끔하면 박스는 쉬워져.

진짜 아키텍처는 seam 이야

왜 mega-app 은 못 하는데 이건 확장되나

Code

External links

Exercise

Progress

댓글 0