← 목록 · 04-3 · 무엇으로 나눌 것인가 — 비교의 기준 · 원문 script.md

04-3: 무엇으로 나눌 것인가 — 비교의 기준

반려 16차(rev16, 2026-09-05) — L128 0.61%를 대덕-유성 한 쌍으로 한정·L44 「같은 시점」 모순 해소·mc1 최장÷최단 상한 완화·정리 여유 확대 BD1~BD3 반영(mc5 「유일 최장」은 COMMON 기준 통과라 손대지 않음). 공통 조항 assets/contracts/COMMON.md(4박자 2·6·15·2·§0.18-a 마진 문턱 4%·계산식=화면 표시값 기준(큰값−작은값)÷큰값×100·판정식 0~6·지정 문자열 충돌은 보고·chapter clock=실측 반올림·§0.4 전환-조작 겹침 가산·시점 불일치 한 줄, 한 쌍으로 한정), 계약 assets/contracts/04-3.md(갈고리 rev8 개정)·04-3-rev2.md·04-3-rev3.md·04-3-rev4.md·04-3-rev5.md·04-3-rev6.md·04-3-rev7.md·04-3-rev8.md·04-3-rev9.md·04-3-rev11.md·04-3-rev12.md·04-3-rev13.md·04-3-rev14.md·04-3-rev15.md·04-3-rev16.md·assets/sources.md(인구 원표 URL·확인일, 세대 미확보 기록). 파일럿 author-a/ep-04-2/를 틀로 삼았다. 소재 assets/market.md, 데이터 assets/data/daejeon/README.md(「04-3·05-1 계약용 실측」 절 2차 정정)·assets/data/daejeon/shops_2026-06_clean_gu_category.csv(정제 후 집계).

기본 정보

학습 목표

• 여러 분모 후보 중 질문에 맞는 것을 고를 수 있다
• 절대값 순위와 분모로 나눈 순위가 다를 수 있다는 것을 설명할 수 있다
• 열 이름을 믿지 않고 데이터 사전과 결측 코드를 먼저 확인해야 하는 이유를 설명할 수 있다

구성

합계 25~30분(COMMON §0.1 — 4박자 선언 2·6·15·2=25, 시연 상한 총량에서 역산). 시연 구간의 무발화 조작 시간은 화면 지시에 단가표 유형(파일열기20·열고르기30·검사실행30·AI응답대기30·표작성20·화면전환8, 초)으로 표기한다.

연결

• 이전: 04-2 「데이터를 구하고, 버린다」 — 39열을 13열로 줄이고 80,704행에서 747행을 버려 79,957행을 남겼다
• 다음: 4-4 「상식과 반대로 나올 때」

상세 전개

도입 (2분)

[화면: 두 순위표가 나란히 — 왼쪽 절대값 순위(서구·유성구·중구·동구·대덕구 순), 오른쪽 만명당 순위(중구·서구가 위 묶음, 동구는 그 사이쯤, 대덕구·유성구가 아래 묶음)(재구성 — 촬영 시 실제 완성본 화면으로 교체). · 조작: 화면전환]

(축자)

"오늘은 이 두 순위표가 왜 다른지를 봅니다."

(요점) 지난 차시에서 대전 상가업소정보 원본 39열을 13열로 줄이고, 80,704행 중 747행을 버려 79,957행을 남겼다. 오늘은 그 79,957행으로 처음 숫자를 센다. 왼쪽 표는 자치구별 업소 수를 그대로 늘어놓은 것이고, 오른쪽 표는 같은 업소 수를 다른 숫자로 나눈 것이다. 같은 데이터인데 위쪽 묶음이 다르다.

(요점) 두 표를 겹쳐 놓고 눈으로만 비교해서는 어느 쪽이 맞는지 알 수 없다. 둘 다 계산 자체는 틀리지 않았기 때문이다. 어느 쪽이 「진짜 순위」냐고 묻는 대신, 각 표가 어떤 질문에 답하는지를 먼저 물어야 한다. 오늘은 이 둘 중 하나를 고르는 게 아니라, 무엇을 근거로 골라야 하는지를 정한다.

(축자)

"이번 차시에서 정하는 것은 무엇으로 나눌 것인가입니다."

(요점) 자치구마다 사는 사람 수도, 집 수도, 넓이도 다르다. 그런데 그냥 세면 큰 구가 항상 이기는 것처럼 보인다. 오늘은 세는 방법이 아니라 나누는 기준을 정한다는 것을 짚고 이론으로 넘어간다.

이론 (6분)

(요점, 도입) 앞 차시에서 원본 표를 정제해 셀 수 있는 표를 만들었다. 그런데 그냥 세면 집단마다 크기가 달라서 큰 쪽이 항상 이기는 것처럼 보인다. 이 문제를 푸는 방법을 오늘 배운다.

(축자, 핵심 정의)

"크기가 다른 집단을 비교하려면 공통된 기준으로 나눕니다. 이것을 정규화라고 부릅니다."

(요점) 정규화는 어려운 계산이 아니다. 같은 잣대로 맞춰서 비교하겠다는 약속이다. 그 잣대가 되는 숫자를 분모라고 부른다.

(요점) 분모 후보는 여럿이다 — 인구, 세대 수, 면적, 사업체 수. 각 분모는 서로 다른 질문에 답한다. 인구로 나누면 사람 한 명당 얼마나 있는지를 답하고, 세대 수로 나누면 가구 하나당 얼마나 있는지를 답하고, 면적으로 나누면 넓이당 밀도를 답하고, 사업체 수로 나누면 업종 안에서의 비중을 답한다. 넷 다 계산은 어렵지 않다 — 어려운 건 이 중 어느 것을 고를지다.

(축자)

"분모를 고르는 기준은 그 질문이 누구 단위로 일어나는가입니다."

(요점) 음식을 먹는 것은 사람 단위로 일어난다. 그래서 음식점 밀도는 인구로 나누는 것이 맞다. 그런데 반려동물 용품점을 센다면 다르다. 반려동물은 개인이 아니라 가구 단위로 기르는 경우가 많아서, 그때는 세대 수가 더 맞는 분모가 될 수 있다. 분모는 데이터가 아니라 질문이 정한다 — 데이터 사전에 인구 열이 있다고 해서 무조건 인구로 나누는 게 아니다.

(요점) 분모를 잘못 고르면 숫자는 멀쩡한데 답은 틀린다. 예를 들어 학교 수를 학생 수로 나누지 않고 면적으로 나누면, 넓은데 학생이 적은 지역이 학교가 부족하다는 결론이 나온다. 계산 과정에는 오류가 없는데, 질문과 맞지 않는 분모를 썼기 때문에 결론이 틀린다. 이런 오류는 계산기가 잡아 주지 않는다 — 분모를 고른 사람만 알아챌 수 있다.

(축자, 다른 예)

"확진자 수를 그대로 늘어놓으면 인구가 많은 지역이 항상 위에 있습니다. 인구 10만 명당으로 나누면 유행이 심한 지역이 위로 올라옵니다."

(요점) 이 문장을 풀어 설명한다. 코로나 확진자 수를 절대값으로 줄 세우면 인구가 많은 지역이 거의 그대로 상위에 온다. 인구가 많으니 확진자도 많은 게 당연해서, 이 순위는 사실 인구 순위와 크게 다르지 않다. 인구 10만 명당 확진자 수로 나누면 완전히 다른 지역이 상위에 온다. 앞은 인구가 많다는 것을 보여주고, 뒤는 유행이 얼마나 강한지를 보여준다. 같은 원자료로 다른 질문에 답한 것이다.

(요점) 분모를 하나만 쓰고 끝내지 않는다. 다른 분모로도 한 번 계산해서 순위가 바뀌면, 그 사실을 결론에 적는다. 순위가 바뀐다는 것 자체가 그 비교가 분모에 얼마나 좌우되는지를 보여주는 증거이기 때문이다. 순위가 안 바뀐다면 그것도 결론에 적을 값어치가 있다 — 분모를 바꿔도 흔들리지 않는 결과라는 뜻이기 때문이다.

(요점) 오늘 배운 정규화와 분모 선택은 이 차시 이후 계속 쓴다. 표에 숫자가 나오면 먼저 그 숫자가 어떤 분모로 나뉜 것인지부터 확인하는 습관을 들인다는 것으로 시연으로 넘어간다.

시연 (15분 + 조작)

[화면: 소상공인 설문조사 파일이 열려 있다. 「지역경제활성화를 위한 노력」 열 헤더가 보인다. 옆에 우리 탐침 보고서의 「주관식 응답」이라는 문구도 함께 띄운다(재구성 — 촬영 시 실제 실행 화면으로 교체). · 조작: 파일열기]

(요점) 999 사고부터 본다. 대전 소상공인 설문조사 파일을 연다. 이 파일의 「지역경제활성화를 위한 노력」이라는 열을, 우리 탐침 보고서는 처음에 「주관식 응답」이라고 적어 뒀었다.

(축자)

"열 이름을 믿지 않습니다. 데이터 사전을 먼저 읽습니다."

(요점) 「주관식 응답」이라는 우리 기록만 보고 텍스트를 그대로 쓸 준비를 했다면 여기서 멈춰야 한다. 우리가 붙인 이름이 아니라 파일에 실제로 들어 있는 값을 봐야 다음 판단을 할 수 있다.

[화면: 이 열의 고유값 집계 결과 — 35개, 최빈값 999(재구성 — 촬영 시 실제 실행 화면으로 교체). · 조작: 검사실행]

(요점) 열어 보니 자유 텍스트가 아니라 고유값 35가지 — 999 하나, 단일 응답 여섯, 조합 스물여덟짜리 선택형이었다. 여러 응답을 함께 고르는 복수응답이라 조합이 스물여덟 가지나 늘어난 것이다. 그중 가장 많은 값이 999다. 31,635행 중 17,638행, 55.8퍼센트가 999다. 한 행에 평균 6.18개 열이 999로 채워져 있다 — 이 설문 하나가 아니라 여러 열에 걸쳐 같은 코드가 반복된다는 뜻이다.

(축자)

"999는 숫자가 아니라 코드입니다."

(요점) 999는 0이 아니고 빈칸도 아니다. 앞 차시에서 배운 「0과 빈칸은 다른 뜻」의 세 번째 경우다 — 무응답이라는 것을 표시하려고 사람이 일부러 넣은 결측 코드다. 이걸 숫자로 계산에 넣으면 평균과 합계가 통째로 틀어진다. 절반이 넘는 행이 999인 열로 분모를 만들면, 그 분모는 실제 값이 아니라 무응답 코드가 만든 숫자다. 오늘 분모 계산에 이 열은 쓰지 않는다.

(요점) 이 사고는 각색이 아니다 — 이 열을 처음 받았을 때 실제로 자유 텍스트라고 믿고 분류를 준비하다가, 열어 보고서야 선택형이라는 것을 알았다. 데이터 사전을 나중에 읽으면 이렇게 늦게 알아챈다.

[화면: 절대값 순위표 — 2026-06 정제 후 구별 업소 수(79,957행 기준). 서구 27,509·유성구 18,949·중구 13,373·동구 11,727·대덕구 8,399(재구성 — 촬영 시 실제 실행 화면으로 교체). · 조작: 표작성]

(요점) 절대값부터 센다. 지난 차시에서 정제해 남긴 79,957행 기준, 2026년 6월 구별 업소 수는 서구 27,509, 유성구 18,949, 중구 13,373, 동구 11,727, 대덕구 8,399이다. 이대로 보면 서구가 1위, 유성구가 2위, 중구가 3위, 동구가 4위, 대덕구가 5위다.

(축자)

"이 순위표만 보면 서구가 이겼다고 말하고 싶어집니다. 그런데 서구는 대전에서 가장 큰 구이기도 합니다."

(요점) 크다는 게 두 가지 뜻으로 섞여 있다 — 업소가 많다는 뜻과, 원래 사람이 많이 산다는 뜻이다. 이 표만으로는 둘을 구분할 수 없다.

[화면: 대전광역시 「대전의 통계」 첫 화면으로 전환 — 2026-07 구별 인구 원문. 서구 464,428·유성구 371,855·중구 224,034·동구 218,050·대덕구 163,823(재구성 — 촬영 시 실제 실행 화면으로 교체). · 조작: 화면전환]

(요점) 인구로 나눈다. 구별 인구 원표에서, 서구 464,428, 유성구 371,855, 중구 224,034, 동구 218,050, 대덕구 163,823을 받는다. 다섯 값을 더하면 1,442,190이 나온다. 이 합이 총인구와 맞는 건 당연하다 — 대전의 자치구는 이 다섯이 전부이기 때문이다. 원표가 맞는지는 이 합계가 아니라 출처와 확인일로만 말할 수 있다.

[화면: 업소 수 ÷ 인구 계산 결과 — 만명당 표. 중구 596.9·서구 592.3·동구 537.8·대덕구 512.7·유성구 509.6(재구성 — 촬영 시 실제 실행 화면으로 교체). · 조작: 검사실행]

(축자)

"만 명당으로 나누면 중구가 조금 앞섭니다. 1위라고 말할 정도는 아닙니다. 유성구는 위쪽 묶음에서 아래쪽 묶음으로 내려갑니다."

(요점) 순위가 크게 흔들렸다. 절대값으로는 유성구가 2등이었는데, 인구로 나누니 아래쪽 묶음으로 내려간다. 유성구는 사람 수에 비해 업소가 적다는 뜻이다. 그런데 아래쪽 묶음 안에서도 대덕구와 유성구의 차이는 3.1, 0.6퍼센트뿐이다 — 어느 쪽이 진짜 꼴찌인지 이 표만으로 단정하지 않는다. 위쪽 묶음도 마찬가지다. 중구와 서구는 절대값으로 3위·1위였는데, 인구로 나누면 596.9와 592.3으로 차이가 4.6, 0.8퍼센트다. 조금 앞선다고는 말할 수 있어도, 어느 쪽이 확실한 1등인지 단정하지 않는다.

(축자)

"분모 표 하나 바꿨더니 두 구의 차이가 2.0에서 4.6으로 두 배 넘게 움직였습니다."

(요점) 처음 써 본 인구 분모는 지시서 비율로 추정한 근사값이었고, 지금 쓴 것은 구별 인구 원표다. 분모를 원표로 한 번 바꿨을 뿐인데 두 구의 차이가 두 배 넘게 벌어졌다. 마진이 이렇게 흔들리는 비교는, 분모 하나가 바뀌는 것만으로 결론이 뒤집힐 수 있다는 뜻이다.

(축자)

"업소는 6월, 인구는 7월 값입니다. 한 달 차이가 있는데, 가장 얇은 쌍은 대덕구 인구의 0.61퍼센트만 움직여도 뒤집힙니다."

[화면: 음식 대분류만 다시 계산 — 만명당 중구 175.7·유성구 167.6·대덕구 165.4·서구 158.2·동구 154.6(재구성 — 촬영 시 실제 실행 화면으로 교체). · 조작: 표작성]

(요점) 업종을 음식으로만 좁혀서 다시 나눈다. 중구 175.7이 유성구 167.6을 8.1 앞서 뚜렷한 편이다 — 4.61퍼센트뿐이다. 유성구·대덕구(167.6·165.4)는 차이 2.2, 1.3퍼센트로 한 묶음, 서구·동구(158.2·154.6)도 차이 3.6, 2.3퍼센트로 한 묶음이다. 두 묶음의 경계(대덕구 165.4-서구 158.2, 차이 7.2·4.35퍼센트)도 뚜렷하진 않다. 아래쪽이었던 유성구가 음식만 보면 중구 다음 묶음으로 올라온다 — 업종을 좁히면 순위가 또 바뀐다.

(요점, 전공이 드러나는 곳) 인물이 이 숫자를 식품영양학과에서 배운 것으로 읽는다 — 혼자 사는 사람은 집에서 한 끼를 차려 먹는 단가가 외식보다 오히려 비싸다. 재료를 1인분만 사면 남는 만큼 버리고, 손질·조리 시간은 인분 수와 상관없이 그대로 든다. 대학과 연구단지가 몰린 유성구는 이 원가 구조 때문에 외식 빈도가 자연히 높아질 수 있다고 본다. 확인된 사실이 아니라 인물의 해석이라는 것을 스스로 밝힌다.

(축자)

"확인된 사실은 아니고 제 생각입니다 — 혼자 사는 사람은 집에서 한 끼를 차리는 단가가 외식보다 비쌀 수 있습니다. 대학과 연구단지가 있는 구라서, 그 이유로 외식이 많을 수 있다고 봅니다."

(요점) 셋째 분모로 세대 수도 생각했다. 그런데 구별 세대 수를 믿을 만한 원표로 찾지 못했다. 여러 공공 통계 사이트를 뒤졌지만, 자치구별 세대수를 정적인 URL로 내주는 곳이 없었다.

(축자)

"출처 없는 값 다섯 개를 표에 올리는 것은, 미확인이라고 적어 두는 것보다 나쁩니다."

(요점) 그래서 오늘은 세대 수를 계산 없이 말로만 남긴다. 음식점은 사람이 먹으니 인구가 맞는 분모지만, 만약 반려동물 용품점이었다면 이야기가 다르다.

(축자)

"이 가게들이 반려동물 용품점이었다면, 분모는 인구가 아니라 세대 수였을 겁니다."

[화면: 25칸 격자에 5개 구를 배치하고 만명당 값을 색으로 칠한 타일 지도(재구성 — 촬영 시 실제 실행 화면으로 교체). · 조작: 표작성]

(요점) 지도 API도 경계 파일도 없이 25칸 격자로 대전 5개 구의 자리를 어림해서 만든다. 칸마다 인구 만명당 값을 색으로 칠한다. 중구·서구가 진하고 대덕·유성이 옅다. 실제 행정 경계는 아니지만, 다섯 구의 순위를 한눈에 보여주는 데는 이 정도로 충분하다.

(요점) 이 색은 오늘 고른 분모, 인구 만명당 값으로 칠한 것이다. 세대 수로 나눈 값으로 칠했다면 진하고 옅은 자리가 달라졌을 것이다 — 지도 한 장을 보여줄 때도 어떤 분모로 칠했는지를 함께 밝혀야 한다.

[화면: AI 채팅창. "구별로 비교해 줘"라고 입력하는 장면. 응답이 절대값 표로 뜬다(재구성 — 촬영 시 실제 실행 화면으로 교체). · 조작: AI응답대기]

(요점, 함정) 방금 만든 표를 놓고 에이전트에게 "구별로 비교해 줘"라고만 시킨다. 에이전트는 서구 27,509, 유성구 18,949 같은 절대값 표를 그대로 낸다. 분모가 필요한지 되묻지 않는다.

(재구성 — AI 출력 예시)
구별 업소 수를 비교했습니다.
서구 27,509 · 유성구 18,949 · 중구 13,373 · 동구 11,727 · 대덕구 8,399

(축자)

"물어본 사람이 분모를 말하지 않으면, 에이전트는 절대값으로 답합니다."

(요점) 오늘 이론에서 배운 것이 실제로 부서지는 장면이다. 분모를 정하는 것은 에이전트가 아니라 사람의 몫이다. "비교해 줘"라는 말에는 무엇으로 나눌지가 들어 있지 않다 — 그 빈자리를 채우지 않으면 에이전트는 손에 든 숫자를 그대로 늘어놓을 뿐이다. "인구 만 명당으로 비교해 줘"처럼 분모까지 문장에 넣어야 방금 만든 표가 나온다.

(요점) 절대값 표 자체가 틀린 건 아니다. 다만 그 표만 보고 "유성구가 대전에서 두 번째로 크다"고 말하면, 그건 업소 수 이야기이지 밀도 이야기가 아니다. 무엇을 물었는지에 따라 같은 숫자가 다른 답이 된다는 것을 이 장면이 다시 한 번 보여준다.

정리 (2분)

[화면: 도입에서 봤던 두 순위표가 다시 뜬다. 이번엔 왜 다른지 화살표로 표시(재구성 — 촬영 시 실제 완성본 화면으로 교체). · 조작: 화면전환]

(축자)

"분모를 밝히지 않은 순위는 순위가 아닙니다."

(요점) 오늘 같은 데이터에서 순위가 두 번 갈렸다 — 절대값과 인구 만명당. 세대 수까지 계산했다면 순위가 한 번 더 갈렸을 것이다. 어느 것도 거짓말은 아니다. 다만 무엇으로 나눴는지를 밝히지 않으면 어느 순위도 믿을 수 없다는 것이 오늘의 결론이다. 순위표를 볼 때마다 위쪽 어딘가에 분모가 적혀 있는지부터 확인하는 습관을 들인다. 적혀 있지 않으면, 그 표를 만든 사람에게 물어봐야 한다. 이 습관 하나가 오늘 배운 것 전부를 요약한다.

(축자)

"'1등은 중구'라고 말하고 싶었는데, 숫자는 그렇게 말해 주지 않았습니다. 다음은 4-4 「상식과 반대로 나올 때」입니다."

(요점) 다음 차시로 넘어가는 긴장을 짧게 건다. 오늘 나눈 분모가 답한 것은 「지금 얼마나 있는가」였다.

[자막: 왜 그 분모입니까? 다른 분모로 하면 순위가 바뀝니까?]

근거

업소 수(2026-06, 정제 후 79,957행 기준): assets/data/daejeon/shops_2026-06_clean_gu_category.csv를 awk로 재계산 — 전체 서구27,509·유성18,949·중구13,373·동구11,727·대덕8,399(합 79,957) · 음식 서구7,349·유성6,231·중구3,937·동구3,371·대덕2,709. 04-2 선언값(80,704−747=79,957)과 일치.

인구(2026-07, 원표 — AQ1): 대전광역시 「대전의 통계」 첫 화면(https://www.daejeon.go.kr/sta/index.do, 확인일 2026-09-04, assets/sources.md에 등재)에서 받은 값 — 서구464,428·유성371,855·중구224,034·동구218,050·대덕163,823(합 1,442,190). 이 합이 총인구와 같은 것은 대전 자치구가 이 다섯이 전부라 정의상 항상 참이다 — 원표가 맞는지는 이 합계가 아니라 출처·확인일로만 말할 수 있다(대본 L113과 같은 태도, AR3). rev1까지 쓴 「지시서 비율×총인구」 근사값(464,385 등)은 폐기했다 — 그 값은 구별로 최대 948명(0.4%) 오차가 있었고 저장소 어디에도 원표가 없었다(검증 rev1 FAIL-2).

시점 불일치(AZ4, rev16 정정 — 한 쌍으로 한정): 업소는 2026-06, 인구는 2026-07 값이라 한 달 차이가 있다 — 두 시점을 같은 달로 맞춘 원표가 없어 그대로 쓴다. 발화에 이 사실을 한 번 밝힌다(L128, 축자) — 「가장 얇은 쌍」은 L120의 대덕-유성 쌍(3.1, 0.6%) 하나만 가리킨다. 같은 L120의 중구-서구 쌍(4.6, 0.8%)은 이 문장의 대상이 아니다 — 0.61%는 대덕-유성 쌍에서만 성립하는 계산이라 두 쌍을 한 문장에 같이 지목하면 안 맞는다(rev15b는 이 구분을 빠뜨렸다). 대덕-유성 표시값(512.7·509.6, 차이 3.1)만으로 3.1÷509.6×100=0.61%를 구해 「대덕구 인구의 0.61%만 움직여도 이 쌍은 뒤집힌다」로 재서술 — 새 원자료 조사 없이 표시값 마진 안에서만 구한 숫자다. 실제 인구 이동량은 계산하지 않는다(원자료가 월별 시계열이 아니라 각 시점 스냅샷 하나뿐이라 계산 불가). 중구-서구 쌍(0.78%, 인구 차이 약 1,740명)에 같은 계산을 하면 다른 값이 나온다 — 이 문장은 대덕-유성 하나만 말한다.

만명당·음식만명당(업소÷인구×10,000): 집필자가 python으로 재계산 — 전체 596.9/592.3/537.8/512.7/509.6(중구·서구·동구·대덕구·유성구 순), 음식 175.7/167.6/165.4/158.2/154.6(중구·유성구·대덕구·서구·동구 순). assets/data/daejeon/README.md 「04-3 분모」 2차 정정 표와 20/20 일치. 중구-서구 마진은 4.6 — 근사 인구로 계산했던 rev1의 2.0에서 2.3배 커졌다. 이 변화 자체를 대본 L123(축자)에서 발화로 짚는다 — 「중구가 1위」로 단정하지 않고 「조금 앞선다」로.

인접 쌍 8곳 판정표(AU1, §0.18-a 마진 % = (큰값−작은값)÷큰값×100):

AU1 정정: rev5까지 동구-대덕·대덕-서구·중구-유성 세 쌍을 「작은 값÷」로 계산해 각각 4.90%·4.50%·4.83%(≈4.8%)로 적었다 — COMMON §0.18-a가 계산식을 「큰값÷」으로 못박으면서 4.67%·4.31%·4.65%로 정정. 판정(4% 아래 4쌍·헤지 3쌍·안전 1쌍)은 바뀌지 않는다 — 세 쌍 모두 애초에 4~6% 헤지 구간이었다.

AY3 정정(rev11): §0.18-a에 「마진%는 화면 표시값으로 계산」이 추가됐다 — 음식 두 쌍은 반올림 전 원값(175.7323·167.5653 등)에서 계산해 4.65%·4.31%로 적었던 것이, 화면에 뜬 값(175.7·167.6·165.4·158.2) 그대로 나누면 8.1÷175.7=4.61%·7.2÷165.4=4.35%다. 표시값으로 4.61%·4.35%로 정정 — 판정(둘 다 4~6% 헤지)은 바뀌지 않는다. 인구 만명당 4곳·음식 나머지 2곳은 원값과 표시값 계산이 이미 같아 손대지 않았다.

999 사고(고유값 35 = 999 1 + 단일 6 + 조합 28·999 17,638행 55.8%·행당 평균 6.18개 열): author-c/probe-dj/3b/data/survey.csv(CP949, 31,635행)를 iconv+python csv(quote-aware)로 전수 집계, README L91과 일치(AY4, rev0·rev1의 "조합이 35가지" 발화가 999·단일 응답까지 조합으로 잘못 묶었던 것을 정정). rev0·rev1과 동일 원자료, 변경 없음. 열 이름에 「주관식」 문자열 0건(python 전수 재확인) — 「주관식 응답」은 우리 탐침 보고서(author-c/probe-dj/3b/RESULT.md)의 표기일 뿐이라는 것을 대본 L82·L84에서 밝힌다.

세대 수 — 표를 뺐다(AQ2): assets/sources.md에 「대전 자치구별 세대 수 ❌ 정적 원표 미확보」로 등재돼 있다 — 대전시 「주민등록인구통계」 간행물은 이미지(JPG/PNG), 행안부 jumin.mois.go.kr은 자바스크립트 드릴다운, data.go.kr 「대전광역시_주민등록 현황_20251231」의 xlsx 링크는 대전시 페이지로 되돌아간다(집필자 재확인). 계약이 「출처 없는 값 5개를 납품 표에 두는 것이 미확인보다 나쁘다」고 판단해 세대 분모 표 자체를 뺐다 — slides.md의 table 블록과 script의 관련 화면·계산 문단을 전부 삭제, 「반려동물이었다면 세대가 분모였다」를 인물 대사 한 줄로만 남긴다(L147). 미확인 0건(값을 안 쓰므로 출처 문제 자체가 사라진다).

minutes(rev16 재계산): 이번 rev 실측 총량 = 발화 5,787자÷250(23.15분) + 조작 194초(3.23분) = 26.38분 → 반올림 26. slides.md 앞머리 minutes: 26에 반영(notes.md 「대본 근거 메모」에 재계산 근거, 두 곳이 정본 하나로 일치). chapter clock — BD1 근거 절 확장·L44 트림·정리 확장이 상쇄돼 시연 3,476→3,468자 — (발화+조작) 16.84분, 반올림 17로 불변(slides.md clock: 17분과 일치, AZ2). 크로스체크 26−(6+17+2)=1(0~6 안). §0.4 「전환·조작 겹침」(L111+30초·L149+8초) 반영 시 촬영 최대치 = 5,787÷250(23.15분) + 232초(3.87분) = 27.01분(notes.md 「대본 근거 메모」와 같은 값) — 반올림 minutes·clock과는 별개 지표.

코로나 확진자 수 대비 인구 10만 명당 예시는 신규 계산 없이 이론상 개념 설명으로만 썼다(수치 인용 없음, 웹 조사 대상 아님) — 변경 없음.