붙박이 데이터로는 안 되는 일

"탭은 명사야. easy-mode는 동사야. 동사는 저장이 안 돼."

파일의 답은 하나, 플레이어의 질문은 여러 개

저장된 탭은 누가 열어도 같은 바이트야. note-for-note한테는 그걸로 충분해. 원곡 솔로는 고정된 하나니까. 하지만 "쉬운 버전" 은 하나가 아냐. 곡, 플레이어의 손 크기와 가동 범위, 실제로 익힌 스케일, 오늘 목표가 코드 체인지인지 리드의 윤곽을 살리는 일인지에 따라 달라져. 하나만 바뀌어도 알맞은 단순화가 달라져. 파일 하나로 그 답을 전부 미리 담을 수는 없어.

미리 저장할 수 없는 곱집합

easy-mode를 붙박이 콘텐츠로 내놓는다고 상상해 봐. 조합마다 파일이 하나씩 필요해.

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

조합 수는 금세 감당할 수 없는 크기로 불어나. 게다가 앞으로 들어올 플레이어의 프로필은 미리 알 수도 없어. 특정한 사람이 특정한 순간에 특정한 구절을 물어보기 전에는 알맞은 답 자체가 아직 정해지지 않은 셈이야. 이건 저장할 문제가 아니라 계산할 문제야.

그래서 앱이어야 해

여기서 나오는 결론은 이거야. Bonfire가 할 일이 note-for-note였다면 붙박이 사이트나 파일 폴더로도 충분했어. 하지만 할 일이 "내 수준으로"가 되는 순간, 요청마다 답을 새로 만드는 살아 있는 엔진이 필요해져. 그리고 이 단순화가 왜 이 플레이어에게 맞는지 추론하는 Pippa와 짝을 이뤄야 해. 단순화를 빼면 앱이 존재할 이유가 사라져. 단순화는 Bonfire에 딸린 기능 하나가 아니라 Bonfire를 앱으로 만드는 이유야.

(이 생각을 설명하는 교육학 용어도 있어. 비고츠키의 근접발달영역(ZPD), 곧 이미 할 수 있는 것보다 딱 한 걸음 어려운 구간이야. "내 수준으로"는 "내 ZPD 가장자리로"라는 뜻이고, 그 가장자리는 실력이 늘 때마다 움직여.)

Code

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

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

Exercise

쓰는 앱의 기능 하나를 골라서 판단해 봐. 저장된 명사야, 계산된 동사야? 그다음 출력을 바꾸는 입력을 전부 적어. 입력 종류가 적고 닫혀 있으면 붙박이로 둘 수 있어. 목록이 계속 열려 있다면, 특히 '누가 묻느냐'에 따라 답이 바뀐다면 요청할 때 계산해야 해.

Hint

결정적인 입력은 보통 유저 자신이야. 알맞은 답이 *누구* 와 *언제* 에 달리는 순간, 붙박이 파일 하나로 미리 끝낼 수 없는 문제가 돼.