AI 음악 생성에서 「A, B, C, D…」나 「January, February, March…」와 같은 **열거형 가사 (Enumerated Lyrics)**를 쓰면, 다른 문장과 동일한 품질의 프롬프트를 작성했음에도 불구하고 발음이 뭉개져 알아듣기 어려워지는 경우가 있다. 작곡 커뮤니티에서는 흔히 **「LMNOP 문제」**라고 불리는 현상으로, 알파벳 송의 "L-M-N-O-P" 부분이 마치 잰말놀이(fast talk)처럼 뭉개져 들리는 것에서 유래했다.

이 기사에서는 실제로 AI 작곡 파이프라인(ACE-Step 1.5 · 완전 로컬)으로 8곡을 생성하고, mlx-whisper로 가사 일치율을 실측한 로그를 바탕으로, ①LMNOP 문제의 원리와 대책, ②대책을 세웠음에도 무엇이 일어났는가, ③더 나아가 「프롬프트를 수정하여 재생성한다」는 일견 올바른 대응이 열거형 가사에 한해서는 역효과가 되었다는 실측 결과를 보여준다.

LMNOP 문제란 무엇인가

열거(알파벳 · 숫자 · 요일 · 월 이름 등)는 가사 중에서도 특수한 구조를 가지고 있다. 일반적인 문장이라면 발음이 다소 흔들려도 문맥으로 보완할 수 있지만, "B"와 "D", "M"과 "N" 같은 단음절 기호열에는 보완할 수 있는 문맥이 없다. 일정한 간격으로 리듬을 타게 되면 인접한 음이 뭉개져 리스너(및 음성 인식)가 구별할 수 없게 된다.

사내 음악 생성 프로젝트에서 축적된 설계 원칙에는 이 대책으로서 다음과 같은 내용이 명문화되어 있다.

• 열거계는 각 항목을 등간격으로 두지 않고, 그룹화(Grouping)를 바꾼다 (예: ABCD / EFG / HIJK / LMN / OPQ / RST / UVW / XYZ)
• 숫자는 영어 단어로 쓴다 ("30"이 아니라 "thirty")
• 문자는 A - B - C와 같이 하이픈으로 구분하여 표기한다
• 1행당 48단어 · 610음절로 구성하며, 병렬되는 행의 음절 수를 ±1~2 범위 내로 맞춘다
• 열거 시 "and"를 끼워 넣지 않는다

실물로 보는 대책 — 사용한 프롬프트와 가사

알파벳을 다루는 악곡에서 실제로 사용한 caption(ACE-Step용 프롬프트)과 가사는 다음과 같다. 설계 원칙을 그대로 적용하여 LMNOP 문제를 피하기 위해 그룹화를 변경했다.

caption: children's song, cheerful, playful, simple melody, ukulele,
glockenspiel, acoustic guitar, clear female vocals, warm, sing-along
duration: 100s / BPM 100 / C major
...

교과서적인 대책을 세운, 일견 「올바른」 프롬프트이다.

실측 — 대책을 세웠음에도 왜 수치가 어긋났는가

생성한 8곡을 mlx-whisper(large-v3-turbo · 완전 로컬)로 전사(Transcription)하고, 실제 사용 가사와의 일치율을 측정했다. 각 곡은 동일한 프롬프트로 seed를 달리하여 2~4회(take) 생성했기 때문에, 같은 곡 · 같은 프롬프트라도 테이크별 일치율에는 편차가 발생한다.

솔직히 말하자면, 범위가 가장 큰 것은 비열거형인 07 Seasons(75.2pp)이다. 다만 이 곡의 v1b(0.0%)는 채점 기록상 「Whisper가 "Thank you"를 환청하는 불량 테이크」이며, 01 ABC Song의 v1b(16.7%)도 「코러스가 루프 붕괴(불량 테이크)」라고 명기되어 있다. 즉, 생성 엔진 측의 글리치(Glitch)와 테이크별 편차가 섞여 있어, 범위의 크기만으로는 「열거형이라서 뭉개졌다」고 단정 지을 수 없다.

본론 — 프롬프트 수정은 열거형 가사에만 역효과였다

생성 글리치의 영향을 분리하기 위해, 불량 테이크를 포함하는 「범위」가 아니라 각 곡의 베스트 테이크(Best Take)(해당 프롬프트로 낼 수 있었던 최상의 일치율)만을 본다. 8곡 중 7곡은 독립 채점관의 루브릭(Rubric) 지적(영어의 부자연스러움 · 음절 초과 · 연출 부족 등)을 반영하여 프롬프트와 가사를 수정한 「v2」를 재생성했다. v1의 베스트 테이크와 v2의 베스트 테이크를 비교하면 다음과 같았다.

프롬프트 수정(v2) 전후로 베스트 테이크의 일치율이 어떻게 변화했는가. 열거형(파랑)은 3곡 중 2곡이 악화되었고, 비열거형(주황)은 4곡 중 3곡이 개선되었다.

• 열거형 3곡(ABC / Numbers / Days&Months)의 v1→v2 델타(Delta) 평균:
  -10.43pp
• 비열거형 4곡(Weather / What Time / Seasons / Introduce, v2를 재생성한 4곡)의 델타(Delta) 평균:
  +1.25pp

루브릭(Rubric) 채점관의 지적은 "부르기 쉬움", "교육 효과" 등의 관점에서 타당한 것이었다(예: 01 ABC에 TPR 동작어 추가, 02 Numbers의 "and" 혼입 제거). 가사 및 구성 측면에서는 개선되었을 터인데, 열거형만 듣기 쉬운 정도가 나빠지는 방향으로 움직였다. 본 기사 집필 시점(2026년 7월)의 ACE-Step 1.5는 lyrics-to-song형 모델로, 프롬프트 전체(caption 및 구성 태그 포함)를 일괄적으로 음향으로 구현하기 때문에, 가사의 일부만 수정하더라도 생성 전체의 음향적 구현(발음의 안정성)이 다른 시드(seed)를 뽑은 것만큼이나 변해버린다. 열거형의 짧은 기호열은 원래 문맥 보완(context completion)이 작동하지 않아 발음 흔들림의 영향을 직접 받기 때문에, 이 "시드(seed)의 흔들림"이 그대로 청취 불능으로 직결되기 쉽다는 가설을 세울 수 있다.

이 기사의 데이터는 열거형 n=3, 비열거형 n=4라는 단일 배치(batch) 내의 내부 데이터이며, 통계적으로 유의미하다고까지는 말할 수 없다. 다만 사내 채점 기록 자체도 동일한 배치로부터 "가사 수정(v2)과 시드(seed) 운은 독립적이다. v2에서 가사가 좋아지더라도 명료도가 떨어지는 경우가 있으므로, 구버전을 버리지 말고 곡마다 최상의 테이크(take)를 채택하는 것이 정답이다"라는 교훈을 남기고 있으며, 이번 델타(Delta) 계산은 이 교훈과 일치하는 결과가 되었다.

재현 가능한 배움

• 열거형 가사(알파벳, 숫자, 요일, 월 이름)를 포함하는 곡은, 프롬프트를 수정하여 한 곡을 다시 만들기보다, 동일한 프롬프트로 시드(seed)가 다른 여러 테이크(take)를 생성한 후 채점하여 최상의 테이크를 선택하는 방식을 우선한다. 이번 데이터에서는 지적 사항을 반영하기 위한 재작성이 역효과를 낼 확률이 더 높았다.
• 설계 단계에서는 LMNOP 대책(그룹화 변경, 숫자의 영단어화, A - B - C 구분, 음절 수 ±1~2)을 첫 프롬프트에 넣어둔다. 사후 수정보다 효과적이다.
• 일치율만으로 판단하지 말고, 생성 글리치(glitch, 환청·루프 붕괴)와 가사 구조 유래의 흔들림은 분리하여 기록한다. 이번 사례처럼 "범위가 크다 = 가사가 나쁘다"라고 성급히 판단하면, 07 Seasons와 같은 불량 테이크를 설계 원칙의 증거로 오인하게 된다.

mx-whisper를 이용한 일치율 채점의 구체적인 절차(uvx를 이용한 arm64 빌드의 함정 포함)는 기출된 기사 "로컬 AI 작곡의 품질을 수치로 측정하기 — mlx-whisper로 가사 일치율을 채점하는 QA 파이프라인을 만든 실록"에서 해설하고 있다. 본 기사에서는 설계 원칙과 재생성 효과 측정에 집중했다.

Discussion