📝 이 글은 Zenn (원본)에 일본어로 처음 게시된 글의 영어판입니다. 모든 도표와 수치는 제가 직접 실행하여 얻은 실제 측정값입니다.

테이크는 쌓여가지만, 제 청취 시간은 늘어나지 않습니다

로컬에서 AI 음악 생성을 시작했을 때, 제가 처음 맞닥뜨린 벽은 품질 그 자체가 아니었습니다. 그것은 바로 양 (volume) 이었습니다.

제가 사용하는 생성 엔진은 ACE-Step 1.5입니다. 이는 Apple Silicon에서 MLX를 통해 로컬 API로 실행되는 음악 생성 모델 (0.6B LM 포함)입니다. 영어 보컬 AI 곡을 제작하다 보면, 단 한 곡을 완성하기 위해 필요한 테이크 (take)의 수가 빠르게 쌓입니다. 파라미터(parameter)와 시드(seed)별로 v1 / v2를 만들고, 각각 두 가지 변형을 만듭니다. 곡당 4개의 테이크는 일반적입니다. 이번 배치(batch)에서는 총 32개의 테이크가 나왔습니다.

여기에 문제가 있습니다. 각 테이크를 들어보면, 네, "멜로디는 좋습니다." 반주도 괜찮습니다. 하지만 테이크 중 일정 비율은 가사를 정확하게 부르지 않습니다 — 모음이 다른 단어로 뭉개지거나, 단어 끝맺음이 누락되거나, 구절 전체가 건너뛰어지기도 합니다. 좋은 멜로디에 매료되다 보면 이런 부분을 놓치게 됩니다.

매 배치마다 32개의 테이크를 모두 수동으로 감사(hand-auditing)하는 것은 최종 완성 단계에서만 하루를 통째로 잡아먹습니다. 귀가 피로해집니다. 세 번째 곡쯤 되면 판단력이 흐려집니다. 품질 보증 (quality assurance)을 전적으로 인간의 집중력에 맡기는 것은 설계부터 잘못된 방식이었습니다.

제가 원했던 것은 제가 듣기 _전_에 기계적으로 후보군을 걸러내 주는 저렴한 사전 필터 (pre-filter) 였습니다.

아이디어: 노래를 제대로 부르는지는 전사 (transcription)로 측정할 수 있다

곡의 품질에는 음정, 리듬, 오디오 충실도(audio fidelity), 표현력 등 많은 축이 있습니다. 이 모든 것을 한꺼번에 정량화하는 것은 어렵습니다. 하지만 저를 가장 괴롭혔던 단 한 가지는 "가사를 정확하게 부르는가?"였습니다. 그 하나의 축은 놀라울 정도로 수치화하기 쉽다는 것이 밝혀졌습니다.

아이디어는 간단합니다. 생성된 오디오를 전사(Transcribe)한 다음, 의도한 가사 텍스트와의 일치율을 계산하는 것입니다. 노래를 잘 부른다면 전사 결과가 원래 가사와 가깝게 나타날 것이고, 노래가 무너지면 가사가 서로 멀어질 것입니다. 이를 하나의 숫자, 즉 일치율(match rate)로 압축하면 32개의 테이크(takes)를 기계적으로 순위 매길 수 있습니다.

전사를 위해 저는 mlx-whisper를 선택했습니다. 이는 클라우드 업로드 없이 **완전하게 로컬(fully locally)**에서 실행되는 Apple Silicon 네이티브 Whisper 구현체입니다. API 비용도, 업로드 대기 시간도 없습니다. 생성은 ACE-Step을 통해 로컬에서 이루어지며, 점수 산정 게이트(scoring gate)의 진입점 또한 mlx-whisper를 통해 로컬에서 이루어집니다. 전체 품질 게이트(quality gate)가 제 컴퓨터 내에서 완결됩니다. AI 음악을 혼자서 많이 생성하는 사람에게 이것은 결정적인 요소입니다. 무료이며, 원하는 만큼 반복할 수 있기 때문입니다.

물론 Whisper의 전사가 완벽하지는 않습니다. 하지만 이 단계에서 저에게 필요한 것은 완벽한 전사가 아니라, _테이크들을 서로 비교할 수 있을 만큼의 충분한 재현성(reproducibility)_입니다. 동일한 조건에서 동일한 모델로 모든 테이크를 전사한다면, 나란히 놓고 비교하기에 충분합니다.

파이프라인: 생성과 점수 산정의 분리

제가 구축한 QA 흐름은 다음과 같습니다.

4단계:

1. 생성 (Generate) — ACE-Step 1.5를 사용하여 테이크를 생성합니다. 곡당 v1 / v2 × 2개의 변형(variants)을 만듭니다.
2. 전사 (Transcribe) — 각 출력물을 mlx-whisper를 통해 텍스트로 변환합니다.
3. 가사 일치율 계산 (Compute lyric-match rate) — 전사된 내용과 의도한 가사를 비교합니다. 이것이 자동화된 컷오프 게이트(cutoff gate) 역할을 합니다.
4. 독립적 루브릭 점수 산정 (Independent rubric scoring) — 컷오프를 통과한 후보군을 루브릭(rubric)에 따라 점수를 매깁니다.

제가 의도적으로 고집한 한 가지는 다음과 같습니다: 생성 모델이 자신의 출력물에 직접 점수를 매기게 하지 마십시오.

생성 모델에게 "그 노래 어땠어?"라고 물으면, 그 평가 결과는 모델 자신의 편의성 쪽으로 치우치게 됩니다. 즉, 스스로에게 관대한 점수를 주게 됩니다. 이는 전형적인 "제작자가 곧 심판자가 되는" 상황이며, 품질 게이트 (quality gate)로서 신뢰할 수 없습니다. 따라서 점수 산정은 독립적인 루브릭 (rubric, 평가 기준)에 따라 별도의 프로세스로 실행됩니다. 생성과 평가를 물리적으로 분리하는 것이 이 게이트의 핵심입니다.

마지막으로, 점수가 낮은 결과물만이 최종 결정을 위해 사람의 귀로 전달됩니다. 전체를 전수 조사하는 것이 아닙니다. 인간의 집중력은 기계가 의심스럽다고 표시한 부분에만 집중됩니다. 그 결과, 전체 청취 시간이 급격히 줄어들었습니다.

측정 결과: 32개의 테이크를 8개로 압축

다음은 실제 수치입니다.

• 총 생성된 테이크 (Total takes generated): 32개 (v1 / v2 × 곡당 2개의 변형)
• 세 단계의 품질 게이트(①가사 일치율 ②독립적 루브릭 ③사람의 귀)를 통해 최종 확정된 최적의 테이크: 8개
• 최종 8개 결과물의 평균 가사 일치율 (lyric-match rate): 83.9%
• 최종 8개 결과물의 평균 독립적 루브릭 점수 (independent rubric score): 94.1 / 100
• 게이트 통과 후 재작업을 위해 반려된 횟수: 1회
• 각 곡의 재생 시간: 100–120초 (afinfo로 측정)

깔때기(funnel) 구조를 보면 입구는 넓고(32개) 출구는 좁습니다(8개). 대략 4개의 테이크가 들어가면 1개가 나오는 수율입니다. 나머지 3개는 멜로디가 좋더라도 가사가 깨졌거나 루브릭 기준을 통과하지 못해 탈락합니다. 이러한 "과잉 생산 후 편집"이라는 전제는 대량 생산의 현실입니다. 바로 그렇기 때문에 편집 단계는 반드시 자동화되어야 합니다.

제가 afinfo를 사용하여 길이를 측정한 데에는 이유가 있습니다. 생성 모델이 보고하는 길이는 파일의 실제 재생 길이와 반드시 일치하지는 않기 때문입니다. 숫자로 품질을 논하려면 추정치가 아닌 실제 파일에서 길이를 읽어와야 합니다. 당연한 이야기 같지만, 그 간극을 추측으로 채우는 순간 다른 모든 수치의 신뢰성도 함께 무너집니다.

정정: 낮은 일치율이 반드시 나쁜 노래를 의미하는 것은 아니었다

여기까지 읽으셨다면 "일치율에 의해 잘려 나가면 끝이다"라고 생각하실 수도 있습니다. 저 또한 한동안 그렇게 믿었습니다: 낮은 일치율 = 노래를 제대로 부르지 않음 = 나쁜 노래.

하지만 그것은 틀렸습니다.

일치율이 명확하게 낮게 나온 클러스터(cluster)가 하나 있었습니다. 조사해 보니 공통적인 요인은 노래의 내용에 있었습니다. 단어가 아닌 — 알파벳을 낭독하는 것처럼 — 문자 자체를 노래하는 노래들이었습니다. 이 유형은 일치율이 **75.3%**까지 측정되었는데, 이는 8개 결승전의 평균인 83.9%보다 확연히 낮은 수치였습니다.

하지만 귀로 직접 들어보면 그 노래들은 아주 잘 불려졌습니다. 망가진 것은 노래가 아니라, **Whisper의 전사 (transcription)**였습니다.

되돌아보니 그 이유는 명확했습니다. Whisper는 자연어 음성을 전사하도록 훈련되었습니다. 문맥이 있는 단어와 문장에는 강합니다. 하지만 언어적 문맥이 희박한 발화 — 예를 들어

그래서 저는 운영 규칙을 확정했습니다: 점수가 낮은 테이크(take)를 버리기 전에, 반드시 귀로 직접 확인하라. 높은 점수는 신뢰할 수 있습니다(노래를 부르고 있기 때문에 일치하는 것입니다). 하지만 낮은 점수는 "노래를 부르지 않음" 또는 "측정할 수 없음" 둘 중 하나를 의미할 수 있으므로, 기계의 판결이 자동으로 사형 선고가 되도록 두지 않습니다. 수치적 게이트(numeric gate)의 올바른 용도는 인간의 청취를 대체하는 것이 아니라, 줄이는 것입니다.

환경 주의사항: Python을 arm64 네이티브로 확보하세요

기초적인 주의 사항 하나를 말씀드리겠습니다. MLX 계열 도구들은 Apple Silicon 네이티브 (arm64) 실행을 전제로 합니다. 이를 놓치면 실행이 되지 않거나 매우 느리게 작동합니다.

흔히 빠지는 함정은 Rosetta를 통해 x86_64 Python을 사용하는 것입니다. Homebrew, pyenv, 그리고 여러 버전의 Python이 공존하는 환경에서는 x86_64 Python이 의도치 않게 우선순위를 가질 수 있습니다. MLX는 네이티브 실행을 가정하므로, 이 상태에서는 실제 성능을 얻을 수 없습니다.

해결 방법은 간단합니다 — 시작하기 전에 Python이 arm64인지 확인하세요:

python3 -c "import platform; print(platform.machine())"

결과가 arm64로 나오면 괜찮습니다. 만약 x86_64가 출력된다면 그것은 Rosetta를 통한 Python이므로, MLX를 실행하기 전에 환경을 전환해야 합니다. 전사(transcription)가 설명할 수 없을 정도로 느리거나 MLX가 제대로 작동하지 않을 때, 모델이나 코드를 의심하기 전에 이 한 줄을 먼저 입력해 보세요. 토대가 기울어져 있다면, 그 위에 아무리 튜닝을 해도 보상받을 수 없습니다.

요점: 숫자는 사전 필터이며, 귀가 최종 판결입니다

완전 무료인 로컬 툴킷(생성을 위한 ACE-Step 1.5, 전사를 위한 mlx-whisper)을 사용하여, "노래를 부르는가"에 대해 숫자로 표시하는 품질 게이트를 구축했습니다. 저는 기계를 통해 32개의 테이크를 걸러내어 8개로 압축했고, 전체 청취 시간을 획기적으로 줄였습니다. 교훈은 다음과 같습니다:

• 대량 QA(Quality Assurance)를 위해서는 먼저 프리필터(pre-filter)를 자동화하세요. 모든 것을 수동으로 감사(audit)하는 설계는 집중력에 의존하며 흐름이 끊기기 쉽습니다. 사전에 기계적으로 순위를 매길 수 있는 단일 수치(여기서는 가사 일치율)를 준비하세요.
• 점수 산정(scoring)과 생성(generation)을 분리하세요. 생성 모델이 스스로를 채점하게 두지 마세요. 별도의 프로세스에서 독립적인 루브릭(rubric)을 사용하는 것이 게이트(gate)의 신뢰성을 확보하는 방법입니다.
• 수치는 프리필터일 뿐, 최종 판결이 아닙니다. 악기(Whisper)의 구조적 한계가 있는 경우 — 예를 들어 글자를 노래하는 곡들 — 낮은 점수가 나타날 수 있습니다. 낮은 점수가 나왔을 때는 폐기하기 전에 항상 귀로 직접 확인하세요.
• 기초를 먼저 검증하세요. MLX를 사용한다면 arm64 네이티브 Python이 필수입니다. 시작하기 전에 platform.machine()이 arm64인지 확인하세요.

자동화의 가치는 "인간을 제거하는 것"이 아니라, "판단이 실제로 필요한 곳에 인간의 판단을 집중시키는 것"에 있습니다. 수치 기반의 게이트는 청취로 들어가는 입구를 좁혀주며, 출구에 있는 귀는 마지막까지 인간의 손에 남아 있습니다. 이러한 분업이야말로 로컬 AI 음악을 대량 생산하면서 품질을 유지하기 위해 제가 현재 내놓은 해답입니다.