static data 로는 불가능

"탭은 명사야. easy-mode 는 동사고. 동사는 저장 못 해."

파일은 답이 하나, 플레이어는 질문이 여럿

저장된 탭은 여는 사람 누구한테나 같은 바이트야. note-for-note 엔 괜찮아 — 원곡 솔로는 고정된 한 가지니까. 근데 "쉬운 버전" 은 한 가지가 아냐. 곡에, 플레이어의 손 크기와 길이에, 실제로 체화한 스케일에, 오늘 목표가 '코드 체인지 잡기' 냐 '리드 모양 살리기' 냐에 달렸어. 그중 하나만 바꿔도 맞는 단순화가 바뀌어. 파일 하나가 그 답들을 한꺼번에 담을 수 없어.

미리 저장 못 하는 곱집합

easy-mode 를 static 콘텐츠로 출하한다고 상상해 봐. 모든 조합마다 파일이 필요해:

(모든 곡) × (모든 플레이어 프로필) × (모든 실력 수준) × (모든 목표)

이 곱은 거의 즉시 저장 가능한 크기를 넘어 폭발해 — 게다가 플레이어 프로필을 미리 알지도 못해. 답은 특정한 사람이 특정한 구절을 특정한 순간에 물어보기 전엔 말 그대로 존재하지 않아. 그게 저장하는 게 아니라 계산하는 것의 정의야.

이게 앱인 이유 전부야

하중을 받는 결론은 이거야: Bonfire 의 일이 note-for-note 였다면 static 사이트나 파일 폴더여도 됐어. 일이 "내 수준으로" 가 되는 순간, 요청마다 새 답을 생성하는 살아 있는 엔진이어야 하고 — 이 단순화가 왜 이 플레이어한테 맞는지 추론하는 Pippa 와 짝을 이뤄야 해. 단순화를 빼면 앱이 존재할 이유가 없어. 단순화는 Bonfire 의 기능이 아니라 Bonfire 의 정당화야.

(밑에 깔린 교육학엔 이름이 있어: 비고츠키의 근접발달영역(ZPD) — 이미 할 수 있는 것 바로 너머의 스위트 스폿. "내 수준으로" 는 "내 ZPD 의 가장자리로" 라는 뜻이고, 그 가장자리는 매주 움직여.)

Code

파일일 수 없는 이유: 살아 있는 입력 넷·python

def easy_mode(
    song: MusicModel,        # 어느 구절
    player: PlayerProfile,   # 손 길이, 체화한 스케일, 버릇
    level: int,              # 오늘 사다리의 칸
    goal: Goal,              # "코드 체인지" vs "리드 모양"
) -> MusicModel:
    """출력은 살아 있는 입력 넷의 함수야. 어떤 파일도 곱집합
    (모든 곡 x 모든 플레이어 x 모든 수준 x 모든 목표)을 미리 저장 못 해.
    누가 묻기 전엔 답이 없어. 그래서 계산하는 거야."""
    ...

Exercise

쓰는 앱의 기능 하나를 골라 정해: 저장된 명사야, 계산된 동사야? 그다음 그 출력을 바꿀 모든 입력을 적어 봐. 입력을 셀 수 있고 적으면 static 일 수 있어. 목록이 열려 있으면(특히 '누가 묻느냐'), 실시간 계산이어야 해.

Hint

결정타 입력은 보통 유저 자신이야. 맞는 답이 *누구* 와 *언제* 에 달리는 순간, static 파일 영역을 영영 벗어난 거야.