하나의 음악적 진실

"모델 하나, 읽는 자 여럿, 복사본 0. view 가 자기 복사본을 갖는 날이 앱이 거짓말을 시작하는 날이야."

모델이 실제로 뭔가

Bonfire 가 곡을 로드하면 딱 하나의 객체를 만들어: 그 곡의 음악적 진실. 키. 스케일 또는 모드. 코드 진행. 타임 그리드 위에 깔린 노트 집합. 섹션, 템포, 비트 그리드. 그 객체가 단일 진실원(SSOT) — 모델 — 이고, 앱의 나머지 전부는 그걸 읽는 자야.

중요한 건, 읽는 자들이 복사본을 안 가져. fretboard 는 자기 노트 리스트를 따로 안 둬. 모델의 노트를 읽고 프렛을 그려. 노트 그리드는 같은 노트를 읽고 블록을 그려. voicing 다이어그램은 모델의 코드를 읽어. Pippa 는 설명을 모델에 근거해. easy-mode 는 모델을 읽고 새 모델을 반환해 — 원본을 절대 변형하지 않아. 진실 하나, 읽는 자 여럿.

왜 복사본이 적인가

앱의 두 부분이 각자 자기 버전의 '코드' 를 쥐는 순간, 갈라져. 하나는 고침을 받고 다른 하나는 못 받아. 재분석이 하나만 갱신해. 이제 fretboard 는 E 마이너라 하고 voicing 패널은 E 메이저라 하고, 유저는 둘 다 못 믿어. 그 발산이 정확히 전작 Guitopia 가 fragment 된 방식이야 — 다른 표현 위에 지어진 다른 표면들, 어느 것도 권위가 아닌. Bonfire 의 답은 잔인하고 단순해: 모델은 하나고, 복사는 금지야.

앱을 붙들어 주는 척추

단일 모델을 척추로 생각해. Capo 식 분석이 거기 붙어. easy-mode 가 거기 매달려. 모든 악기 view 가 거기서 갈비뼈처럼 뻗어. Sidekick 이 그걸 읽어. 척추를 빼 — 기능마다 자기 표현을 키우게 둬 — 그럼 앱이 아니라 가끔 의견 일치하는 기능 더미가 돼. 단일 모델은 있으면-좋은 게 아냐. 이 모든 표면이 같은 곡을 설명하게 해주는 바로 그것이야.

Code

모델 하나, 읽는 자 여럿, 복사본 0·python

song = MusicModel(
    key="E minor",
    scale="E minor pentatonic",
    chords=[...],          # 진행
    notes=[...],           # 타임 그리드 위의 노트
)

# 모든 consumer 가 모델 하나를 READ 해. 누구도 자기 복사본 안 둬:
fretboard.render(song)        # song.notes + song.scale 에서 기하
grid.render(song)             # 시간 위 song.notes 에서 블록
voicings.render(song)         # song.chords 에서 모양
pippa.explain(song)           # song 에 근거한 주장

easy = simplify(song, level=1)   # NEW 모델을 반환;
                                 # `song` 을 절대 변형 안 함

Exercise

쓰는 멀티 패널 앱(디자인 툴, 스프레드시트, 음악 앱)을 열어. '같은 것' 을 보여주는 패널 둘을 찾아. 이제 물어: 둘 다 읽는 밑바탕 값 하나가 있어, 아니면 동기화되는 복사본 둘이야? 신호를 봐 — 한 패널 편집이 다른 패널을 즉시 갱신(모델 하나) vs 지연이나 '새로고침'(복사본).

Hint

패널 간 즉시 갱신은 거의 항상 공유 모델 하나를 뜻해. 수동 새로고침 버튼, 동기화 스피너, '이 view 는 오래됨' 배너는 복사본의 지문이야.