알파벳을 노래하는 것은 AI 음성이 할 수 있는 가장 쉬운 일이어야 합니다. A-B-C-D-E-F-G. 지구상의 모든 아이에게 익숙한 일곱 개의 개별적인 소리입니다. 하지만 AI 음악 생성 기술을 실험해 본 사람이라면 현실은 훨씬 더 복잡하다는 것을 알고 있습니다. 모델에게 알파벳을 노래하라고 시키면, L, M, N, O, P 글자들이 종종 하나의 흐릿한 음절로 뭉쳐버리곤 합니다. "Elemmennopee"는 글자가 아닙니다. 그것은 하나의 증상입니다.
이것이 바로 'LMNOP 문제'이며, 이는 단순히 동요의 문제를 넘어 훨씬 더 광범위하게 적용됩니다. 요일, 번호가 매겨진 지침, 그리고 모든 종류의 순서가 있는 목록은 동일한 약점을 드러냅니다. 최근 한 개발자는 AI 파이프라인을 통해 8곡의 노래를 생성하고, 자동 음성 인식 도구인 mlx-whisper를 사용하여 결과물을 측정함으로써 이를 테스트했습니다. 주관적인 청취에 의존하는 대신, 전사(transcription) 소프트웨어가 AI가 실제로 무엇을 노래했는지 정확히 보고하게 했습니다. 결과는 극명했습니다. 나열(Enumeration)은 일반적인 언어와는 다른 방식으로 합성 가수를 당황하게 만듭니다.
목록이 AI 음성을 망가뜨리는 이유
구어체 언어는 문맥을 담고 있습니다. 누군가 "강아지를 데리고 공원에 갈 거야"라고 중얼거리다가 "강아지"라는 단어를 놓치더라도 문장은 여전히 의미가 통합니다. 주변 단어들이 빈틈을 채워주기 때문입니다. 하지만 목록은 그런 안전망을 제공하지 않습니다. 각 항목은 독립적으로 존재합니다. 만약 모델이 "B"와 "D"의 차이를 흐릿하게 발음한다면, 청자는 부분적인 의미라도 얻는 것이 아니라 그저 소음만을 듣게 됩니다.
알파벳 노래에서 LMNOP 클러스터는 가장 명백한 실패 지점입니다. 음성 모델은 이 시퀀스를 다섯 개의 개별 문자가 아닌 하나의 음성적 덩어리(phonetic blob)로 취급합니다. 각 소리를 고정해 줄 문맥적 단서가 없기 때문에, 합성기는 자음 사이의 전환을 추측합니다. 그리고 대개 그 추측은 틀립니다. 요일이나 번호가 매겨진 단계에서도 똑같은 일이 발생합니다. 모델은 시퀀스를 서둘러 지나가며, 뚜렷한 항목들을 불분명한 소리의 뭉치로 압축해 버립니다.
피해 측정하기
이를 객관적으로 연구하기 위해, 개발자는 8곡의 노래를 생성하고 mlx-whisper를 실행하여 가사 정확도를 측정했습니다. 파이프라인은 간단했습니다. 프롬프트를 작성하고, 오디오를 생성하고, 결과를 전사한 뒤, 전사된 텍스트를 의도한 가사와 비교하는 방식이었습니다.
표준적인 서사형 가사의 경우, 결과물은 상당히 충실했습니다. 단어들이 제 자리에 위치했습니다. 하지만 프롬프트에 목록, 알파벳 또는 나열이 포함되면 mlx-whisper는 횡설수설하는 내용을 반환했습니다. 글자가 사라지거나 합쳐졌습니다. 숫자는 알아볼 수 없는 음절로 변했습니다. 이 실험은 목록이 많은 가사가 산문보다 가독성 면에서 눈에 띄게 더 큰 피해를 입는다는 것을 확인시켜 주었습니다.
도움이 되는 프롬프트 구조
엉망이 된 목록을 수정하기 위해 사후 처리(post-processing)에 의존할 수는 없습니다. 해결책은 첫 번째 음표가 생성되기 전에 이루어져야 합니다. 정교하게 구성된 첫 번째 프롬프트는 모델이 더 명확한 발음을 하도록 강제할 수 있습니다. 이러한 조정에는 비용이 들지 않지만, 모델이 숨을 쉬고 멈추는 방식을 변화시킵니다.
긴 연속 구간을 더 작은 그룹으로 나누기. A-B-C-D-E 대신, 줄을 A-B-C-D와 E-F-G로 구성하세요. 그룹 사이의 아주 작은 재설정(reset)은 모델이 자음을 뭉개지 않고 정확한 자음에서 멈출 수 있는 기회를 제공합니다.
숫자를 철자로 풀어 쓰기. "30" 대신 "thirty"를 사용하세요. 숫자로 쓰인 기호는 추상적인 상징이며, 모델은 때때로 이를 짧고 성대가 울리지 않는 소음으로 압축해 버립니다. 완전한 영어 단어는 음성적 실체를 제공합니다.
글자 주변에 시각적 간격 삽입하기. "ABC"라고 쓰는 대신 하이픈이나 공백을 사용하여 "A - B - C"라고 쓰세요. 시각적 분리는 모델에게 이것들이 하나의 약어나 단어가 아니라 독립된 항목임을 알려주는 신호가 됩니다.
음절 수 고정하기. 각 줄을 6음절에서 10음절 사이로 유지하세요. 변동 폭이 너무 크면 모델은 짧은 줄은 서둘러 읽고 긴 줄은 늘여 읽게 됩니다. 목록은 이미 정밀함을 요구하므로, 불균형한 리듬은 정확한 전달을 거의 불가능하게 만듭니다.
목록에서 "and" 제거하기. 자연스러운 말하기에서 "and"는 접속사 역할을 합니다. 하지만 노래하는 목록에서 "and"는 부드러운 음절을 추가하여 이전 항목의 날카로운 끝부분을 삼켜버리는 경우가 많습니다. "Monday, Tuesday, Wednesday"가 "Monday, Tuesday, and Wednesday"보다 더 깔끔하게 끊어집니다.
재생성의 함정
여기서 인간의 직관이 역효과를 냅니다. 일반적인 가사의 경우, 반복적인 프롬프트 수정(iterative prompting)은 대개 결과를 개선합니다. 어색한 구절이 들리면 단어를 수정하고 다시 생성합니다. 그러면 다음 버전은 더 좋게 들립니다. 테스트 결과, 이 접근 방식은 나열이 없는 노래에는 효과적이었습니다. 하지만 목록이 포함된 노래의 경우, 프롬프트를 다시 쓰는 것이 오히려 결과물을 이해하기 더 어렵게 만들었습니다.
데이터는 명확했습니다. 목록이 없는 노래는 프롬프트 수정 후 개선되었습니다. 반면, 나열이 포함된 노래는 품질이 저하되었습니다.
범인은 어쿠스틱 시드입니다. 가사-음악 생성 모델(lyrics-to-song models)에서 프롬프트를 변경하는 것은 단순히 기존 오디오를 편집하는 것이 아닙니다. 이는 생성의 기반 전체를 다시 섞어버립니다. 모델은 퍼포먼스를 처음부터 다시 구축합니다. 서사적인 텍스트의 경우, 새로운 주사위 굴리기가 더 명확한 테이크(take)로 이어질 수도 있습니다. 하지만 리스트의 경우, 대개 더 심한 발음 뭉개짐을 초래하게 됩니다. 한 글자의 타이밍을 맞췄더니, 다음 시도에서는 모델이 "J", "K", "L"을 뭉개버리는 상황이 발생할 수도 있습니다. 원래 테이크도 결함이 있었지만, 수정본은 종종 하나의 음성적 혼란을 다른 혼란으로 맞바꾸는 꼴이 됩니다.
리스트가 많은 가사를 위한 더 스마트한 워크플로우
재생성(regeneration)은 명확성을 해칠 위험이 있으므로, 프로세스를 바꿔야 합니다. 완벽한 재작성을 쫓는 일을 멈추세요. 대신, 첫 번째 프롬프트를 캐스팅 오디션처럼 다루십시오.
서로 다른 랜덤 시드를 사용하여 정확히 동일한 프롬프트로부터 여러 버전을 생성하십시오. 텍스트는 건드리지 마세요. 가사를 고정하고 모델이 퍼포먼스를 다양하게 시도하도록 두십시오. 당신은 편집 세션을 하는 것이 아니라 오디션을 진행하는 것입니다.
그런 다음 모든 후보를 평가하십시오. 각 버전을 mlx-whisper 또는 유사한 전사(transcription) 도구로 실행하여 어떤 테이크가 프롬프트와 가장 충실하게 일치하는지 측정하십시오. 악기 구성이나 보컬 톤이 약간 덜 다듬어졌더라도, 가사 정확도를 기준으로 승자를 선택하십시오. 리스트가 많은 콘텐츠의 경우, 분위기(vibe)보다 명료도(intelligibility)가 더 중요합니다.
가장 중요한 것은, 수정을 앞 단계에서 미리 처리하는 것입니다. 생성 버튼을 누르기 전에 띄어쓰기 규칙, 음절 제한, 그룹화 등을 적용하십시오. 알파벳 송을 그냥 평범한 영어로 써놓고 나중에 수정하려고 하지 마세요. 리스트가 포함된 경우, 모델은 사후 수정(retroactive edits)에 대해 관대하지 않습니다. A