목소리를 위한 두 번째 악보

“아 진짜?”라는 다섯 글자는 놀람도 되고, 비꼼도 되고, 지친 체념도 된다. 글자는 같은데 목소리는 전혀 다르다.

텍스트 음성합성 모델은 이 빈칸을 매번 추측한다. 높낮이, 길이, 강세, 숨, 속도, 멈춤, 감정의 방향을 문맥과 프롬프트에서 복원한다. 모델이 좋아질수록 추측은 그럴듯해지지만, 창작자 입장에서는 다른 문제가 남는다.

잘 추측하는 것과 원하는 발화를 반복해서 재현하는 것은 같은 능력이 아니다.

영상 편집자에게 타임라인이 있고 음악가에게 악보가 있듯, 음성 생성에도 자연어 프롬프트와 음소 코드 사이의 중간 제어층이 필요할 수 있다. 이 글은 그 중간층을 훈민정음의 ‘소리를 조립해 적는다’는 발상에서 다시 생각해보는 설계 실험이다.

문제는 한글이 아니라 ‘평문’이다

일상 문장은 의미 전달에 효율적이지만 실제 발화 정보를 크게 압축한다.

아 진짜?

이 한 줄에는 보통 다음 정보가 명시돼 있지 않다.

• 첫 음절의 시작 높이와 끝 높이
• ‘진짜’의 길이와 강세
• 질문 끝에서 올라가는지 내려가는지
• 숨 섞인 소리인지 단단한 발성인지
• 단어 사이의 멈춤
• 놀람인지, 비꼼인지, 짜증인지

사람끼리는 문맥과 표정으로 채운다. 음성모델도 통계적으로 채운다. 하지만 더 직접적인 제어가 필요한 더빙·게임 대사·캐릭터 보이스·교육용 발음에서는 “적당히 슬프게” 같은 지시가 매번 같은 음향 결과를 보장하지 않는다.

따라서 이 글의 질문은 좁다.

사람이 읽을 수 있으면서 기계가 구조화된 제어값으로 변환하기도 쉬운 ‘발화 주석층’을 만들 수 있을까?

훈민정음에서 빌릴 것은 자부심이 아니라 설계 원리다

훈민정음은 자음과 모음을 조합해 음절을 만들고, 중세국어에서는 방점처럼 음높이와 관련된 정보를 덧붙이는 표기도 사용했다. 이것이 현대 음성 AI용 언어가 이미 존재했다는 뜻은 아니다. 역사적 표기와 현대 음향 제어는 목적도 변수도 다르다.

다만 한 가지 설계 힌트는 얻을 수 있다.

기본 글자와 부가적인 소리 정보를 분리해 겹쳐 쓴다.

평문을 그대로 두고 필요한 구간에만 길이·피치·강세·발성 같은 표지를 덧붙인다면, 사용자는 전문 음성학 표기를 전부 배우지 않고도 발화를 조금 더 직접 편집할 수 있다.

예를 들어 개념 수준에서는 이렇게 적을 수 있다.

아↗ 진짜↗?!     놀라며 올라가는 발화
아↘ 진짜↘?      낮고 지친 의문
아ˉ 진짜↘       첫 음절을 길게 끌고 낮게 끝냄
!아 진짜?!      강한 어택
아{whisper}      속삭임 지시

이 기호들이 정답이라는 뜻은 아니다. 오히려 기호를 무엇으로 정할지는 가장 나중 문제다. 먼저 어떤 제어 변수가 실제 생성 품질과 반복성을 개선하는지 확인해야 한다.

이미 있는 도구들과 무엇이 다른가

새 표기법은 ‘새롭다’는 이유만으로 가치가 생기지 않는다. 이미 더 정교한 체계들이 있다.

여기서 가장 위험한 착각은 “한글의 조합성이 좋으니 이 방식도 당연히 좋을 것”이라고 점프하는 것이다. 문자체계의 우수성과 UI의 사용성, 그리고 모델 제어 성능은 별개의 문제다.

최소한으로 시작해야 한다

초기 아이디어에는 길이, 피치, 강세, 숨, 감정, 웃음, 조음까지 많은 기호를 넣을 수 있다. 그러나 모든 변수를 한꺼번에 노출하면 표기는 금세 악보가 아니라 암호가 된다.

실험용 1차 버전이라면 오히려 네 가지 정도로 줄이는 편이 낫다.

1. 길이 — 짧게 / 보통 / 길게
2. 피치 방향 — 상승 / 하강 / 평탄
3. 강조 — 일반 / 강조
4. 휴지 — 짧은 멈춤 / 긴 멈춤

감정 이름은 처음부터 기호화하지 않아도 된다. ‘비꼼’이라는 감정표보다 실제 피치·길이·에너지 조합이 더 재현 가능한 제어값일 수 있기 때문이다.

즉 목표는 예쁜 새 문자를 만드는 것이 아니라 다음 변환을 안정시키는 것이다.

사람이 읽는 주석
→ 정규화된 발음·운율 파라미터
→ 모델별 control token / API
→ 음성

표기법은 이 파이프라인의 사용자 인터페이스일 뿐이다.

가장 강한 반론: 필요 없을 수도 있다

이 아이디어에 대한 가장 강한 반론은 단순하다.

모델이 충분히 좋아지면 새 표기법을 배울 이유가 없다.

자연어로 “첫 ‘아’를 300ms 정도 길게, 낮게 시작해서 끝을 살짝 올리고, 비웃듯 힘을 빼줘”라고 말했을 때 모델이 정확히 따라주고 그 결과를 재사용할 수 있다면 별도 기호체계는 추가 마찰에 불과하다.

또 SSML이나 DAW형 시각 인터페이스가 이미 문제를 더 잘 풀 수 있다. 피치 곡선을 마우스로 그리는 것이 ↗를 타이핑하는 것보다 빠를 수도 있다. 전문가는 IPA와 음향 파라미터를 선호하고, 일반 사용자는 자연어를 선호해서 중간 표기층이 누구에게도 최적이 아닐 가능성도 있다.

유니코드 조합문자와 옛한글 자모의 입력·폰트 호환성도 현실적인 병목이다. 눈에는 멋있어도 복사·검색·렌더링이 불안정하면 인터페이스로서는 실패다.

따라서 이 프로젝트가 살아남으려면 ‘문화적으로 흥미롭다’가 아니라 작업 시간을 줄이고 결과의 반복성을 높인다는 것을 보여줘야 한다.

실험은 생각보다 단순하게 만들 수 있다

같은 30~50개의 짧은 문장을 세 방식으로 지시한다.

• 자연어 프롬프트
• SSML 또는 모델이 지원하는 기존 제어
• 경량 주석 표기

그리고 같은 모델·같은 화자·같은 샘플 조건에서 다음을 측정한다.

여기서 주석법이 자연어와 SSML보다 낫지 않다면 접으면 된다. 특정 집단—예를 들어 더빙 디렉터나 발음 교육자—에서만 이득이 있다면 그 집단용 도구로 범위를 줄이면 된다.

무엇이 이 결론을 바꿀까?

다음 결과가 나오면 별도 표기층의 필요성은 약해진다.

• 최신 음성모델이 자연어만으로 동일한 운율을 높은 반복성으로 재현한다.
• 주석을 배운 사용자가 SSML·그래픽 편집기보다 느리고 오류도 많다.
• 기호가 늘어날수록 가독성 저하가 제어 이득보다 커진다.
• 모델마다 control token 의미가 달라 공통 중간표현으로 번역하기 어렵다.
• 블라인드 청취에서 주석 사용 여부에 따른 목표 일치 차이가 없다.

반대로 더 적은 수정 횟수로 더 반복 가능한 발화가 나온다면, 그때부터는 ‘흥미로운 아이디어’가 아니라 실제 인터페이스 문제로 다룰 이유가 생긴다.

결론

훈민정음의 역사적 의미를 AI에 억지로 연결할 필요는 없다. 여기서 쓸모 있는 것은 문화적 권위가 아니라 소리를 분해하고 다시 조합해 표기한다는 설계 습관이다.

평문은 의미에는 효율적이지만 목소리의 많은 변수를 숨긴다. 음성 AI가 그 빈칸을 잘 추측하는 시대에도, 창작자가 결과를 반복해서 통제해야 하는 순간은 남을 수 있다.

그때 필요한 것이 새 문자일지, 작은 주석기호일지, SSML의 더 좋은 UI일지, 아예 피치 곡선을 그리는 화면일지는 아직 모른다.

그래서 가장 정확한 한 문장은 이것이다.

‘한글로 음성을 프로그래밍할 수 있다’는 결론이 아니라, 사람이 읽을 수 있는 경량 운율 표기가 음성 AI의 조종간이 될 수 있는지 실험해볼 가치가 있다.

출처와 범위

• 원문 개념 노트
• 국제음성기호(IPA), Speech Synthesis Markup Language(SSML), 현대 TTS의 prosody/control token은 비교 기준이다. 이 글은 이들 표준을 대체한다고 주장하지 않는다.
• 중세국어의 옛 자모와 방점에 대한 언급은 역사적 설계 영감의 범위이며, 현대 음향 파라미터와 일대일 대응한다고 주장하지 않는다.
• 제안 기호와 평가표는 검증 전 프로토타입 설계안이다.