하나의 음악적 진실

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

모델이 실제로 뭔가

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

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

왜 복사본이 적인가

앱의 두 부분이 각자 자기 버전의 '코드'를 쥐는 순간 갈라지기 시작해. 한쪽은 고쳐지고 다른 쪽은 안 고쳐져. 재분석이 한쪽만 갱신해. 그러면 fretboard는 E 마이너라고 하는데 voicing 패널은 E 메이저라고 하고, 유저는 둘 다 못 믿게 돼. 전작 Guitopia가 조각조각 갈라진 게 정확히 이 방식이야. 서로 다른 표현 위에 서로 다른 표면을 올렸고, 어느 것도 권위가 없었어. Bonfire의 답은 단순하고 매정해. 모델은 하나, 복사는 금지.

앱을 붙들어 주는 척추

모델 하나를 척추로 생각해 봐. Capo 식 분석이 거기 붙고, easy-mode가 거기 매달리고, 악기 view가 갈비뼈처럼 거기서 뻗어 나오고, Sidekick이 그걸 읽어. 척추를 빼고 기능마다 자기 표현을 키우게 두면, 앱이 아니라 가끔 의견이 맞는 기능 더미가 남아. 모델 하나는 있으면 좋은 정도가 아니야. 이 표면들이 같은 곡을 설명하게 만들어 주는 바로 그거야.

Code

모델 하나, 읽는 쪽 여럿, 복사본 없음·python

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

# 모든 소비자가 모델 하나를 읽어. 누구도 자기 복사본을 두지 않아:
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)   # 새 모델을 돌려주고,
                                 # `song` 은 절대 건드리지 않아

Exercise

패널이 여러 개인 앱을 열어 봐. 디자인 툴이든 스프레드시트든 음악 앱이든. '같은 것'을 보여주는 패널 둘을 찾아. 그리고 물어. 둘 다 읽는 밑바탕 값이 하나 있어, 아니면 동기화되는 복사본이 둘이야? 신호는 이래. 한 패널을 고쳤을 때 다른 패널이 즉시 따라오면 모델이 하나고, 한 박자 늦거나 '새로고침'을 눌러야 하면 복사본이야.

Hint

패널끼리 즉시 갱신되면 거의 항상 공유 모델이 하나라는 뜻이야. 수동 새로고침 버튼, 동기화 스피너, '이 view는 오래됐어' 배너는 복사본이 남긴 지문이야.