A4Room
← Devlog 목록

Beatick: 비트박스를 악보로 바꾸는 오디오 AI

목소리로 낸 퍼커션을 kd·sd·hhc·hho로 인식해 공유 가능한 악보로 바꾸기까지. 온셋 검출과 분류 파이프라인을 설계한 이야기입니다.

Beatick은 "비트박스를 눈에 보이는 것으로 바꾸면 어떨까"라는 질문에서 시작했습니다. 입으로 낸 킥·스네어·하이햇 소리를 인식해 악보 형태로 바꾸고, 그걸 다른 사람과 공유하는 커뮤니티 플랫폼입니다. 게임은 아니지만, A4Room이 만드는 "재미있는 소프트웨어"의 한 갈래죠.

Beatick — 녹음에서 악보 변환까지의 흐름

문제: 소리를 '기호'로 바꾸기

비트박스를 악보로 만들려면 두 가지를 알아야 합니다. 언제 소리가 났는가(타이밍)무슨 소리인가(종류)입니다. 우리는 이 둘을 분리해서 풀었습니다.

  1. 온셋 검출(onset detection) — 오디오 파형에서 새로운 타격이 시작되는 순간을 찾습니다.
  2. 분류(classification) — 각 타격 구간을 잘라 kd(킥) / sd(스네어) / hhc(닫힌 하이햇) / hho(열린 하이햇) / UNKNOWN 중 하나로 판별합니다.

분류기는 PyTorch로 학습했고, UNKNOWN 클래스를 일부러 두었습니다. 억지로 4종류 중 하나로 우겨넣는 것보다, "모르겠다"고 정직하게 말하는 편이 사용자 신뢰에 훨씬 나았기 때문입니다.

배운 점

분류 모델에 "모름(UNKNOWN)" 선택지를 주는 것만으로 결과의 체감 정확도가 올라갔다. 틀린 확신보다 정직한 불확실이 낫다.

왜 분석을 '비동기 큐'로 뺐나

오디오 분석은 무겁고 느립니다. 사용자가 녹음을 올릴 때마다 요청 안에서 바로 처리하면 서버가 금방 막히고, 사용자는 로딩 스피너만 바라보게 됩니다. 그래서 흐름을 이렇게 나눴습니다.

녹음/업로드  →  분석 큐에 작업 등록  →  워커가 순차 처리
        →  결과(악보)를 저장  →  준비되면 사용자에게 알림

프런트엔드는 Next.js로, 파일과 결과 저장은 Supabase로 처리했습니다. 업로드 즉시 응답을 돌려주고 분석은 뒤에서 돌리니, 앱이 항상 가볍게 반응했습니다. 무거운 일을 사용자 대기 시간에서 떼어내는 것 — 이게 이 프로젝트의 핵심 설계였습니다.

커뮤니티라서 필요했던 것들

Beatick은 혼자 쓰는 도구가 아니라 공유 플랫폼이라, 아래 것들을 함께 붙였습니다.

정리

Beatick은 "소리를 눈에 보이게" 만든다는 한 가지 아이디어를, 인식 파이프라인 · 비동기 처리 · 커뮤니티 기능이라는 세 축으로 구현한 프로젝트입니다. 게임이 아니어도 A4Room의 방식은 같았습니다 — 작게 시작해, 동작하는 흐름을 먼저 세우고, 거기서 넓혔습니다.