'분당 N자 속도가 빠르다'는 기준을 찾아보았지만, 그런 것은 없었습니다. 낭독 임계값을 정직하게 설정하기

📝 원래 Zenn에 일본어로 게시되었습니다. 이 글은 영어 버전입니다.
Canonical: https://zenn.dev/uya0526_design/articles/satellite3_metrics-rationale

📚 이 글은 저의 "낭독 속도 측정기 개발 로그" 시리즈 중 satellite article #3입니다. 전체적인 맥락을 보려면 메인 기사를 참조하세요.

이 글의 위치

낭독 속도 측정기는 말하기 속도를 "약간 빠름"과 같은 **평가 라벨 (evaluation label)**로 변환하고, 정체율 (stagnation rate)을 "적음"과 같은 라벨로 변환합니다. 이러한 라벨들은 궁극적으로 Claude Haiku의 피드백을 위한 토대가 됩니다.

그렇다면 — 저는 어떤 근거로 임계값 (thresholds, 구분선)을 그렸을까요? 이 글은 그 "근거"를 파헤칩니다.

제 조사 결과에 따른 짧은 답변은 다음과 같습니다:

"분당 N자 = 빠름/느림"에 대한 학술적 임계값을 정의하는 논문을 찾을 수 없었습니다."

이 글은 확고한 근거가 없다는 것을 알게 된 후, 제가 어떻게 정직하게 선을 그었는지에 대한 기록입니다. 지표 숫자 그 자체보다, 왜 그 숫자를 선택했는지에 대해 투명하게 공개하는 것이 평가 앱을 신뢰할 수 있게 만든다고 믿습니다.

💡 저는 공개적으로 TypeScript를 배우고 있는 전직 Java 엔지니어입니다. 이 글은 주로 디자인 결정에 관한 내용입니다.

왜 "근거"에 집착하는가?

평가 앱은 사용자에게 "당신의 읽기 속도는 약간 빠릅니다"와 같이 **판단 (judgment)**을 내립니다. 일단 판단을 내리기 시작하면, "왜 그렇게 말할 수 있는지"를 설명하지 못할 경우 그것은 단순한 추측에 불과합니다.

특히 이 앱은 라벨을 Claude Haiku에 직접 전달하여 코칭을 생성합니다. 만약 기초가 되는 라벨의 근거가 불분명하다면, 그 위에 구축된 피드백은 모래 위의 성과 같습니다. 그래서 저는 먼저 임계값에 대한 근거를 확실히 하기로 결정했습니다.

조사해야 할 두 가지 사항:

말하기 속도 (speaking speed) (분당 글자 수)에 대한 판단 근거
정체율 (stagnation rate) (침묵의 비율)에 대한 판단 근거

결과적으로, 이 두 가지는 완전히 다른 _종류_의 근거를 가지고 있었습니다.

속도 임계값 (Speed Thresholds): 학술적 임계값은 없음 → 경험칙(Rule of Thumb)에서 도출

내가 찾아낸 것

말하기 속도에 대해 먼저 학술적 근거를 찾아보았습니다. 그 결과는 다음과 같습니다.

말하기 속도는 전통적으로 모라 수 (mora count)를 기준으로 측정되어 왔으나, 청취자 관점에서의 선행 연구는 그 자체로 매우 부족합니다.
일본어는 초당 음절 수가 많은 "빠른 언어"로 간주되지만, 정보 밀도와 상관관계가 있어 언어 전반에 걸친 전체 정보 전달률 (information-transfer rate)은 유사하다는 연구 결과가 있습니다.

하지만 이 중 어느 것도 개별 사용자의 낭독이 빠른지 느린지를 판단하는 근거로 쓰일 수는 없었습니다. "분당 N자이면 빠르다"라고 명시하는 학술적 임계값은 찾을 수 없었습니다.

내가 채택한 근거: 아나운서 기준

그래서 나는 경험칙 (rule-of-thumb)에 기반한 근거를 채택했습니다. 전제는 다음과 같습니다: 아나운서에게 기대되는 속도는 분당 300자이다.

NHK 아나운서 표준은 "분당 300자"입니다. 이는 프로그램 제작진 사이에서 공유되는 지식이며 대본을 작성하는 가이드 역할을 합니다.
최근에는 속도가 빨라지는 추세입니다. NHK는 약 분당 380자, 상업 방송사는 약 400자 정도라고 합니다.
스포츠 중계와 같이 빠른 전달을 요구하는 환경에서는 분당 400자가 넘는 경우도 흔합니다.

아나운서는 **언어 전문가 (language professionals)**의 영역에 있습니다. 따라서 일반 독자가 이 속도에 도달한다면, 나는 이를 이미 "약간 빠름" 단계에 진입한 것으로 설정했습니다.

임계값 (채택된 버전)

속도 라벨	분당 글자 수
느림	– 149
...

이 지점에서 **앱 특화적인 설계 결정 (app-specific design decision)**이 들어갑니다. 일반적인 표에서는 보통 "NHK 표준인 약 300자 = 보통"으로 설정하지만, 이 앱은 의도적으로 이를 이동시켜, 전문가 표준인 300자를 일반인 기준 "약간 빠름"의 _시작점_으로 배치했습니다.

그 이유는 이 앱의 사용자가 **일반적인 독자(ordinary readers)**이기 때문입니다. 만약 전문가 수준을 "표준"으로 설정한다면, 거의 모든 사람이 "느림"이라는 판정을 받게 될 것이고, 코칭은 의욕을 꺾는 방향으로 흐르게 됩니다. "일반인이 전문가 수준에 도달하면, 그것은 이미 빠른 편에 속한다"라고 설정하는 것이 격려를 위한 도구로서 더 자연스러운 프레임워크(framing)입니다.

☕ 코드로 매핑하기: 이러한 임계값(thresholds)은 thresholds.ts 파일에 상수(constants)로 존재합니다. 숫자들의 근거(300 = 전문가 표준 등)에 대한 설명은 코드 주석이 아니라, 이 글과 LEARNING_LOG에 기록되어 있습니다. Java 용어로 표현하자면, "설정 값들을 상수로 추출하고, 그 의도는 설계 문서(design docs)에 남겨두는 것"과 같습니다.

기사 및 UI에서 정직하게 작성하기

임계값을 제시할 때 제가 주의했던 점은 "Claude가 엄격한 학술적 근거를 바탕으로 판단하고 있다"라는 오해를 불러일으키지 않는 것이었습니다.

학술적 임계값은 존재하지 않으므로, 제가 경험적인 기준(rule-of-thumb basis, 아나운서 표준인 분당 300자)을 채택했다는 점을 정직하게 작성합니다.
커스텀 배치(custom placement)의 의도를 명확히 밝힙니다. 즉, 전문가 표준인 300자를 일반인의 "약간 빠름" 시작점으로 설정했다는 점을 설명합니다.
더 엄밀히 말하면, 분당 글자 수(chars/min)는 단순화된 지표이며, 실제로는 분당 모라(mora/min)가 일반적인 측정 단위라는 점을 언급합니다.

이를 "엄격한 과학"인 것처럼 꾸미기보다는, "나는 이러한 근거를 바탕으로 이렇게 선을 그었다"라고 과정을 보여주는 것이 평가 앱으로서 더 많은 신뢰를 얻을 수 있다고 판단했습니다.

정체율(Stagnation-Rate) 임계값: "자"조차 없습니다

속도보다 더 근거가 없는

정체율(전체 발화 중 침묵이 차지하는 비율)의 경우, 결론은 속도보다 훨씬 더 어려웠습니다.

"정체율이 X% 미만이면 좋다"라는 수치적 임계값의 근거는 속도보다 찾기가 훨씬 더 어렵습니다. 이는 속도가 가진 것과 같은 "수치적 자(numeric ruler)\

이는 일반적인 원칙으로서도 까다로운 문제입니다. 화자가 휴지(pause)를 두지 않는다는 사실 자체가 유창한 말하기의 증거로 간주되지는 않습니다. 실제로 연구에 따르면 휴지는 다음과 같은 중요한 기능을 수행합니다:

발화 속도(Speech rate, 휴지 포함)와 조음 속도(Articulation rate, 발화 부분만 해당)는 **서로 다른 개념 (distinct concepts)**이며, 휴지를 포함하는 쪽이 청각적 인상(auditory impression)과 더 강력한 상관관계를 가집니다.
휴지는 단순히 단어/구/문장의 경계를 표시하는 것뿐만 아니라, 청자에게 정보를 소화할 기회를 주는 중요한 기능을 합니다.

다시 말해, "휴지가 적을수록 좋다"는 공식이 단순히 성립하는 것은 아닙니다.

이를 "내부 지표 (in-house metric)"로 수용하기

여기서 저는 설계상의 결정을 내렸습니다. 정체율(stagnation rate)에 대해서는 학술적 또는 일반적인 근거가 없음을 인정하고, 이 앱을 위한 내부적인 휴리스틱 (in-house heuristic)으로 솔직하게 받아들이기로 했습니다.

정체 라벨 (Stagnation label)	정체율 (`labelMetrics` 이후 %)
Few	– 0.9%
...

"0%를 좋은 쪽으로 배치한" 근거는 문화적 맥락입니다

독자가 자연스럽게 가질 질문을 미리 짚어보겠습니다. "왜 0%(끊김 없는 말하기)를 좋은 쪽(good side)에 두었나요?"

그 근거는 학술적인 것이 아니라, 일본의 문화적 맥락입니다. 일본에는 "tate-ita ni mizu" (직역하면 "세워둔 판에 물을 붓다" — 끊김 없이 유창하게 말하다)라는 표현이 있으며, 이는 끊김 없이 흐르는 듯한 말하기를 "유창함"으로 보는 성향을 반영합니다. 저는 그 함축적 의미에 무게를 두어 선을 그었습니다.

물론 이것이 "정답"은 아닙니다. 위에서 언급했듯이 "휴지는 청자가 정보를 소화하게 하는 기능을 한다"는 연구 결과가 있으므로, 0%가 항상 좋은 것은 아닙니다. 저는 이 영역이 학술적으로 정립되지 않았으며 사람들의 인식이 갈리는 영역이라고 판단했습니다. 그리고 마감 기한이 정해진 Phase 1 내에서 이를 더 깊이 파고들기보다는, 설계자로서 "tate-ita ni mizu" 측의 함축적 의미를 채택했습니다.

⚠️ 이 지표의 한계: 현재 상태에서 정체율 (stagnation rate)은 일본어의 **의미 있는 휴지 (ma)**를 구분하지 못합니다. 문장 부호 지점에서 적절하게 이루어진 0.5초의 멈춤과, 독자가 막혀서 발생한 0.5초의 비틀거림은 모두 동일한 "침묵" 정체로 계산됩니다. 이는 반드시 "휴지 위치의 적절성"과 결합하여 질적으로 검토되어야 하며, 이는 아직 README의 Phase 2에 나열되지 않은 연구 과제입니다. 앱의 푸터(footer)에서도 이러한 한계를 명시하고 있습니다.

두 지표는 서로 다른 종류의 근거를 가짐

요약하자면, 동일한 "평가 지표 임계값 (evaluation-metric threshold)"이라 할지라도, 제가 이를 설정한 근거는 완전히 달랐습니다:

지표	학술적 임계값	채택된 근거	본문에서의 처리 방식
속도 (Speed)	없음	경험칙 (아나운서 분당 300자)	업계 관행 수치를 근거로 제시; 커스텀 배치 방식을 상세히 설명
정체율 (Stagnation rate)	없음 (측정 기준 자체가 없음)	앱 특화 휴리스틱 (heuristic) + 문화적 맥락	학술적 뒷받침이 없음을 명시; 솔직하게 내부 지표 (in-house metric)라고 명명

이것이 제가 이번 글에서 가장 전달하고 싶은 핵심입니다. 근거를 찾을 수 없을 때, "이것은 과학적이다"라는 가식적인 외관을 억지로 만들지 마세요. "학술적 임계값이 없으므로 경험칙을 인용했다", "이를 내부 지표로 수용했다"와 같이 과정을 공개하는 것이, 제 생각에는 평가 앱으로서 실제로 더 강력한 신뢰를 줍니다.

내가 직접 결정한 것 / AI에게 요청한 것

영역	세부 사항
나의 결정 사항	최종 임계값, 아나운서 기준의 커스텀 배치, 정체율을 내부 지표로 취급하라는 결정, "tate-ita ni mizu" 맥락 채택, MVP의 한계 명시
...
임계값 숫자와 그 근거는 모두 제가 결정했습니다. AI는 조사와 임시 초안 작성을 도왔지만, "어떤 근거를 채택하고 어떻게 배치할 것인가"는 설계자의 판단입니다.

마치며

이 글은 낭독 평가 임계값을 "어떤 근거로" 도출했는지에 대한 요약이었습니다. 세 가지 핵심 요약은 다음과 같습니다:

속도에 대한 학술적 임계값은 존재하지 않았기에, 저는 경험칙(아나운서 기준 분당 300자)에 근거를 두었으며, 전문가 표준을 일반인의 "약간 빠른" 시작점으로 임의 설정 (custom-placed) 했습니다.
정체율 (Stagnation rate)에는 기준이 전혀 없었기에, 이를 앱 특화적인 휴리스틱 (Heuristic)으로 받아들였습니다. 0%를 양호한 기준으로 설정한 근거는 "tate-ita ni mizu (세워둔 물에 물을 붓다)"라는 문화적 맥락에 기반합니다.
근거가 없을 때는 과학적인 것처럼 꾸미지 말고, 그 과정을 공개하십시오. 그것이 평가 앱을 정직하게 만드는 길이라고 믿습니다.

평가 도구의 가치는 단순히 숫자의 정밀함에 의해 결정되지 않습니다. 그 숫자를 어떻게 정당화했는지 사용자에게 투명하게 공개할 수 있느냐가 핵심입니다. 저는 근거를 찾는 과정에서의 막다른 길조차 기록했는데, 그것이 제가 가장 전달하고 싶었던 것이었기 때문입니다.

상세한 개발 로그는 리포지토리의 LEARNING_LOG에 있습니다.

📦 https://github.com/uya0526-design/reading-speed-meter

주요 참고 문헌 (Main references)

이 글의 근거를 정리하며 참고한 출처들입니다.

Ayumi Marushima, "A Study on the Cognition of Speech Rate," Studies in Linguistics online inaugural issue (2008) [일본어]
Ayumi Marushima, "A Study on the Tempo of Spoken Language," Studies in Linguistics online no. 2 (2009) [일본어]
Ayumi Marushima, "An Experimental-Phonetics Study of Speech Rate from the Speaker's and Listener's Perspectives," doctoral dissertation, University of Tsukuba (2015) [일본어]
NHK 및 상업 방송 아나운서의 낭독 속도에 관한 보고 및 공유된 업계 지식 (Diamond Online 등)

💡 이 글에서 주장하는 바와 같이, 저는 학술적인 "속도 임계값"은 존재하지 않는다고 믿습니다. 위의 자료들은 임계값 자체에 대한 출처가 아니라, "낭독 속도와 휴지 (pause)에 대해 어떻게 생각할 것인가"에 대한 배경 지식입니다. 저는 각 자료를 원문과 대조하여 확인했습니다.

다음은 피날레입니다 — 이 모든 디자인 결정의 근간이 되었던 "AI 협업 개발 (AI-collaborative development)"을 되돌아봅니다 → 위성 #4, "AI 협업 개발에 대한 성찰 및 시행착오 모음" (https://dev.to/uya0526design/not-did-you-use-ai-but-are-you-the-one-driving-reflections-on-building-a-real-product-through-464m).

이 글은 AI 도구 (Claude / Cursor)를 활용한 저의 공개적인 학습 여정의 일부입니다. 임계값과 그 근거에 대한 판단은 저의 것입니다. 저는 글의 구조, 개요, 초안 작성 단계에서 AI와 협업하며, 발행 전 모든 문장을 직접 검토하고 수정합니다.