Pippa 제안, 사람 확정

"자신 있게 틀린 게 학습 도구가 될 수 있는 최악이야. 정직하게 모르고, 그다음 고쳐지는 게 최선이고."

자동 분석은 진짜로 틀릴 수 있어

Tier A 는 성숙하지, 무오류가 아냐. 코드·키 감지는 jazz 텐션을 틀리고, 빠른 전조를 놓치고, 조성이 모호한 곡에서 갈팡질팡해. 언젠가 고쳐 없앨 버그가 아냐 — 오디오에서 화성을 추론하는 일의 본질이야. Capo 도 같은 한계가 있고, Capo 유저는 일상적으로 그 출력을 고쳐. 안 그런 척하면 학습자한테 틀린 화성을 완전한 자신감으로 가르치는 거야 — 가르치는 게 일 전부인 도구한테 최악의 실패.

오류 가능성을 대화로 만들어

그래서 Bonfire 는 분석을 평결이 아니라 제안 으로 다뤄. 엔진은 신뢰도와 함께 최선의 추측을 내고; Pippa 가 그걸 질문으로 꺼내 — 'E 마이너로 들리는데, 네 귀랑 맞아?' — 사람이 확정하거나 고쳐. 모델은 사람의 답에서 갱신돼. 음악에 대한 최종 권위는 늘 사람이야. 그 루프가 한계를 교육 순간으로 바꿔: 학습자가 라벨을 수동으로 믿는 대신 비판적으로 듣도록 초대돼.

설계 가치로서의 정직

이건 단순한 UX 패턴이 아니라 입장이야. 학습 도구는 모르는 걸 정직하게 밝혀서 신뢰를 벌어. 'E 마이너인 것 같아, 70%' 가 네 번에 한 번 틀리는 조용하고 자신 있는 'E 마이너' 보다 신뢰를 더 쌓아. human-in-the-loop 은 AI 가 실패할 때를 위한 fallback 이 아니라 — 자기 귀를 키워야 하는 유저를 위한 도구의 올바른 모양이야. 고칠 수 있는 게 기능이야.

Code

분석은 평결이 아니라 제안·python

proposal = analyze(audio)        # {"key": "E minor", "confidence": 0.72}

# Pippa 가 사실이 아니라 질문으로 꺼내:
#   "여기 E 마이너로 들리는데 -- 네 귀랑 맞아?"
if human_confirms(proposal):
    model.key = proposal.key
else:
    model.key = human_correction     #최종 권위는 사람

# 고칠 수 있는 게 기능이야.
# 네 번에 한 번 틀리는 자신 있는 라벨이 진짜 결함이야.

Exercise

불확실성을 안 보이고 자동 답을 주는 도구를 찾아(자동수정, 분류기, '스마트' 제안). 대신 'I'm 70% sure — 확인?' 이라 말한다고 상상해. 더 믿을까 덜 믿을까? 너를 가르치려는 도구한테, 어느 설계가 실제로 배움을 돕고 어느 게 그냥 권위 있게 느껴지는지 정해.

Hint

권위 있지만-가끔-틀린 건 확인을 멈추게 훈련시켜. 정직하지만-불확실한 건 계속 듣게 훈련시켜. 학습 도구한텐 두 번째가 핵심 전부야 — 수동적 신뢰가 실패 모드야.