엔지니어 업계에서 「완전히 이해했다 → 아무것도 모르겠다 → 조금 할 줄 안다」의 근거로 붙여지는 예의 그 곡선은,
Dunning-Kruger의 원 논문(1999)에는 존재하지 않는다 - 덧붙여지곤 하는 Bertrand Russell의 명언도, 널리 퍼져 있는 버전은
의역(Paraphrase)이며 원문이 아니다 - 「다크 모드는 절전 효과가 있다」도 실측해 보면, 통상 휘도에서는
3~9% 밖에 차이가 없다 (Purdue 대학교 실측). 효과를 보고 싶다면 색상보다 휘도 - 「PHP 8은 JIT로 빨라졌다」— JIT는
8.0부터 8.4까지 일관되게 기본적으로 비활성화(Default Disabled) 상태이다 (2026년 7월 집필 시점) - 「Markdown은 AI 친화적이다」— 그래서,
누가 측정해 봤나요? 아무도 측정하지 않았기에 필자가 측정했다. 결과, Markdown은 최적화되지 않았다 (상세 내용은 자매 기사) - 이들에 공통적인 것은
「잘 만들어진 도해·단정적인 말투·기본값(Default value)의 미확인」이 검증을 건너뛰게 만드는 구조. 그리고 AI 시대, 이 구조는 가속화되고 있다 (본문에 실화 있음) - 결론:
괴팍함은 미덕이다. 1차 자료를 제시하라. "소스는 나다"는 금지.

대상 독자는 괴팍한 엔지니어이다.

• 스터디 발표 슬라이드에 예의 그 곡선이 나오면 "그거 원전이 있나요?"라고 말하고 싶지만, 분위기를 읽고 말하지 못했던 사람
• "~라더라"라는 말로 기술 선정(Technology Selection)이 진행될 것 같으면 위가 아파오는 사람
• "소스는?"이라고 물었다가 "Qiita 기사입니다"라는 답을 듣고, 먼 산을 바라본 적이 있는 사람

안심해도 좋다. 이 기사는 당신의 그 괴팍함을 엔지니어링의 핵심 기술로서 전적으로 긍정한다. 이하, 필자가 실제로 1차 자료까지 파고들어 확인한 "기술 도시전설" 5가지를 성불시켜 나가겠다.

본 기사의 삽화는 모두 특정 작품이나 밈(Meme) 그 자체가 아니라, 일본 애니메이션풍의 비유로서 생성한 것이다. 유령이 되어 있는 것은 실재하는 그래프가 아니라 "출처 없는 도해"의 개념이다.

또한 필자도 후반부에서 자신이 쓴 자료에 스스로 태클을 걸기 때문에, 잘난 척하는 기사가 아니다. 안심하고 읽어주길 바란다. "그건 당신의 감상 아닌가요"는 이 기사에서는 칭찬이다.

「완전히 이해했다(무지의 산) → 아무것도 모르겠다(절망의 계곡) → 조금 할 줄 안다(계몽의 언덕~고원)」. 엔지니어의 학습 곡선(Learning Curve) 소재로서 너무 사랑받은 나머지, 이제는 이력서에 써도 될 정도인 예의 그 것. 근거로 Dunning-Kruger 효과(1999)가 덧붙여진다.

Kruger & Dunning의 원 논문(Journal of Personality and Social Psychology, 1999, Vol. 77, No. 6)에는, 그 4단계 곡선은 실려 있지 않다. 원 논문이 보여준 것은 "성적 하위 그룹은 자기 평가가 실제보다 높고, 상위 그룹은 약간 낮다"라는 4분위 막대그래프 형태의 결과이지, "산→계곡→언덕→고원"이라는 드라마틱한 여정이 아니다. 그 곡선은 후대의 누군가가 그린 **속류 도해(俗流図解, 저급한 도해)**가 전언 게임을 통해 "원 논문의 그림"으로 승격된 것이다.

나아가 괴팍함을 극도로 추구하면, 효과 그 자체에 대해서도 통계적 아티팩트(Statistical Artifact, 평균으로의 회귀 + 자기상관)가 아닌가라는 비판적 재검증이 있다 (Gignac & Zajenkowski 2020, Intelligence지 등). 반론도 존재하며, 학술적으로는 미결착 상태다.

즉 「완전히 이해했다 곡선」은,

「이해한 척」을 설명하는 그림이, 그 자체로 「이해한 척」하며 유통되고 있다는 맛깔나는 재귀 구조를 이루고 있다.

성불해라.

• 곡선을 붙이지 말라는 것은 아니다.
  "잘 알려진 속류 도해이며 원 논문의 그림이 아니다"라고 한마디 덧붙이는 것만으로도 기사의 신뢰성은 급상승한다 - "모두가 아는 그림"일수록 출처를 확인할 가치가 있다. 모두가 알기 때문에 아무도 확인하지 않는다.

예의 그 곡선과 세트로 붙곤 하는 Bertrand Russell의 명언. "세상의 문제는, 어리석은 자일수록 자신감이 넘치고, 현명한 자일수록 의심이 많다는 것이다". 멋지다. 슬라이드의 마무리로 최고다.

널리 유통되고 있는 영어판("fools and fanatics are always so certain of themselves...")은 의역(Paraphrase)이며, Russell의 원문이 아니다. 원문은 다음과 같다.

The fundamental cause of the trouble is that in the modern world the stupid are cocksure while the intelligent are full of doubt.

— 버트런드 러셀 (Bertrand Russell), 1933년 5월 10일 최초 출간

New York American지

게다가 최초 출간 당시의 제목은 "Stupidity Rules"였으며, 유명한 "The Triumph of Stupidity"는 재수록될 때의 제목이다. 명언의 출처를 확인해 보니 제목부터가 전해 내려오는 말(伝言ゲーム)이었다.

"러셀이 이렇게 말했다"라고 말했나?

그건 거짓말이다.

• 명언 인용은 「누가·언제·어디서」라는 3종 세트가 갖춰져야 비로소 인용이 된다. 갖춰지지 않았다면 「~라는 취지의 말이 전해진다」라고 써야 한다.
• 아이러니하게도, 이 명언의 오전파(misinformation)는 전설 그 첫 번째와 완전히 동일한 구조를 띤다. 이해했다고 착각하는 것을 경계하기 위한 소재가, 이해했다고 착각하는 방식으로 운용되고 있다.

"OLED는 검은색 픽셀이 소등되니까, 다크 모드로 설정하면 배터리가 오래간다". 디바이스 설정 이야기에서 반드시 터져 나오는 그 정석적인 이야기.

원리는 맞다. OLED는 자발광 방식이므로 검은색 픽셀은 소등된다. **문제는 정도(degree)**다.

퍼듀 대학교(Purdue University)의 실측 연구(MobiSys '21, Google 제작 6개 앱으로 검증)에 따르면:

즉, 평상시 사용하는 휘도에서는 전투력…… 고작 3~9%인가……. 반면 **휘도 그 자체의 영향은 지수적(exponential)**이라서, 100% → 50%로 낮추는 것만으로 OLED의 소비 전력은 약 1/10이 된다. 절전하고 싶다면 색을 바꾸기 전에 휘도를 낮추라는, 아주 노골적인 결론에 도달한다.

진정한 실력자(휘도)는 언제나 곁에서 조용히 빛나고 있다.

참고로 필자는 이 검증 과정에서 스마트폰을 그레이스케일(grayscale) 운용(색을 모두 제거)해 보았으나, 절전 목적으로는 권장하지 않는다. 그 효과는 어디까지나 「무의식적으로 스마트폰을 만지는 횟수가 줄어드는」 계열의 디지털 웰빙(digital wellbeing)과, 자신의 앱 UI가 색상에 너무 의존하고 있지는 않은지 확인하는 접근성(accessibility) 검증에 있다. 색을 지워버리면 정보 계층(information hierarchy)이 설계되지 않은 화면은 순식간에 탄로 난다. 추천한다.

• 「원리적으로 옳다」와 「실용상 의미가 있다」 사이에는 계곡이 존재한다.
  원리로 이야기한다면 양(quantity)을 물어라 — "몇 %나 변합니까?"라는 한마디는 회의에서 가장 기피되면서도 가장 가치 있는 질문이다.
• 고백하자면, 필자도 이 수치를 직접 실측하지는 않았다. 1차 자료를 찾아봤을 뿐이다. 괴팍함의 최저 마지노선은 **"실측, 그것이 불가능하다면 1차 자료"**이다. 재인용의 재인용 단계부터 도시전설이 시작된다.

"PHP 8에 JIT가 도입되었으니, 이제 PHP는 느리지 않다". PHP vs Go 논쟁에서 PHP 측이 쏘는 단골 탄환.

PHP에 JIT가 도입된 것은 사실이다. 하지만 JIT는 PHP 8.0부터 8.4까지 일관되게 기본적으로 비활성화(disabled) 상태이다 (본고 작성 시점인 2026년 7월 기준. 향후 버전에서 바뀐다면 이 글이 새로운 도시전설의 발생지가 될 것이다. 그것이 1차 자료 확인이라는 양식미다).

• 8.3 이전:
  opcache.jit=tracing

하지만 opcache.jit_buffer_size=0

→ 버퍼가 0이므로 실질적으로 무효

• 8.4 이후:
  opcache.jit=disable

또한 opcache.jit_buffer_size=64M

→ 설정 자체로 명시적으로 무효화

8.4에서 바뀐 것은 「무효화하는 방법」이지, 활성화된 것이 아니다 (PHP.Watch / php.net 공식 매뉴얼). 즉, php.ini를 건드리지 않은 당신의 서버에서 JIT는 오늘도 조용히 잠들어 있다. 그런 장비로 괜찮겠는가? —— 괜찮지 않다, 설정을 확인하자.

당신의 운영 환경에 있는 JIT 군(이미지). 가동 중인지 확인하자.

여기서 고백하자면, 필자는 예전에 비엔지니어 클라이언트용으로 「PHP와 Go의 비교 자료」를 쓴 적이 있다. 다시 읽어보니, 인터프리터/컴파일(interpreter/compile) 축과 동적/정적 타이핑(dynamic/static typing) 축을 혼동하여, PHP가 OPcache를 통해 바이트코드(bytecode)로 컴파일 및 캐싱되고 있다는 사실을 무시한 채, "Go는 메모리 관리가 자동이라 안전하다"라고 PHP에도 GC(Garbage Collection)가 있음에도 불구하고 마치 Go만의 장점인 것처럼 적어 놓았다. 완전히 이해했다는 표정으로 써 내려갔던 것이다. 그 자료는 내가 쓰러뜨려야 할 무지의 산이었다 (산은 원 논문에 없지만).

그리고 중요한 대칭성이 있다. "PHP는 느리다"를 막연하게 비판하는 측이 "PHP 8은 JIT로 빠르다"라고 말하는 순간, 똑같은 함정에 빠진다. 기본적으로 비활성화되어 있기 때문이다. 단순화를 비판하는 자는 자신의 단순화에도 찔리게 된다. 참수(介錯, 카이샤쿠)는 1차 자료가 맡는다.

• "기능이 들어갔다"와 "기능이 작동하고 있다"는 다르다.
  기본값(Default value)을 확인하는 것까지가 기술 선정 - 언어 논쟁에서 수치를 제시할 때는 실행 모델(I/O 바운드인지 CPU 바운드인지)과 설정(JIT 유무, OPcache)을 덧붙여야 한다. 덧붙일 수 없다면 그것은 응원 연설이지 비교가 아니다.

"AI에게 읽히려면 Markdown이다. 구조화되어 있어 AI 가독성이 높다". AI 주도 개발 (AI-driven development) 문맥에서 하루도 빠짐없이 들리는 말이다. 필자 또한 자신의 슬라이드에 "AI 가독성이 높은 데이터 파일 = Markdown"이라고 적어 두었었다.

"AI 가독성"을 정량적으로 검증한 자료를, 통설의 유통량에 걸맞을 만큼 본 적이 있는가? 필자는 없다. 그래서 괴팍한 엔지니어로서는, 버즈워드 (Buzzword)를 측정 가능한 축으로 분해하게 된다.

토큰 효율 (Token efficiency) — 동일한 데이터를 JSON / YAML / TOML / Markdown 표 / CSV로 작성하여 토크나이저 (Tokenizer)로 실측한다 (모델마다 토크나이저가 다르므로 "AI 일반"으로 말할 수 없다).
생성 에러 내성 (Generation error tolerance) — "읽히는 형식"과 "쓰게 하는 형식"은 요구사항이 다르다. YAML은 인덴트 (Indent) 지옥 때문에 AI가 생성 시에 넘어지기 쉽지만, 읽기에는 편하다. JSON은 장황하지만 구조가 깨지기 어렵다.
diff 친화성 (diff affinity) — 1행 1레코드 형식은 차이(diff)를 읽기 쉽다. JSON은 정렬 방식에 따라 diff가 처참해질 수 있다.
부분 읽기 내성 (Partial loading tolerance) — Markdown은 헤딩 (Heading)으로 자연스럽게 분할할 수 있지만, JSON은 중간에 끊으면 즉사한다. 컨텍스트 길이 (Context length) 및 과금과 직결되는 실무 문제다.
언어 선정으로의 파급 — 타입 어노테이션 (Type annotation)은 AI에게 문서로서 기능한다. 단, "AI가 읽기 쉬우니까"라는 이유로 기술 선정을 왜곡하는 것은 본말전도다. 어디까지나 가점 요소일 뿐이다.

이 실측은 완료되었으며, 결과는 자매 글로 공개하고 있다. 스포일러를 하나만 남겨두자면——"Markdown이 최적"은 아니었다. 표 형식 데이터를 읽힐 때는 CSV가 압승(토큰 x1.00 대비 정렬된 JSON은 x2.4)이었으며, 생성했을 때의 위험은 구문 에러가 아니라 "Markdown 표가 줄바꿈을 <br>로 조용히 바꿔치기하는" 종류의 탐지할 수 없는 내용 변조였다. 상세한 수치 표와 재현 조건은 자매 글("AI 가독성은 측정 가능한가")에 맡긴다. 측정하지 않은 숫자는 쓰지 않는 것이 이 글의 규칙이다.

• 버즈워드를 보면 "그것은 어떤 축의 이야기이며, 어떻게 측정하는가"라고 물어라. 분해할 수 없는 개념은 대개 운송 중에 사고가 난다.
• "~에 친화적" 계열의 주장은 그 친화성의 단위를 확인하라.

이 글을 조사하던 중 실제로 있었던 이야기를 하겠다.

그레이스케일 (Grayscale) 운용의 효과를 AI에게 리서치시키던 중, 요약 내용 안에 "412명을 대상으로 한 Journal of Behavioral Addictions의 RCT", "마이크로 사카드 (Microsaccade) 빈도가 37% 감소"라는, 매우 그럴싸한 수치가 혼입되어 있었다. 출처 URL을 요구했더니——존재하지 않았다. 실재하는 연구(Holte & Ferraro 등의 피어 리뷰 연구 등)에 실재하지 않는 숫자가 섞여서 나온 것이다.

이것은 이제 전언 게임 (Telephone game)조차 아니다. 전언 도중에 작화를 하는 참가자가 상주하게 되었다는 뜻이다. 도시전설의 생성 속도는 인력 시대보다 확실히 높아졌다.

액자는 훌륭하다. 내용은 연기다. 돋보기(1차 자료 대조)를 들어라.

괴팍한 엔지니어가 나설 차례다. AI의 출력에 포함된 통계치는 1차 URL과 대조할 수 있을 때까지 존재하지 않는 것으로 취급한다. "그럴듯함"은 진실성의 증거가 아니다. 오히려 AI의 "그럴듯함"은 인류 역사상 최고 수준이므로, 그럴듯할수록 의심하는 것이 딱 적당하다.

5가지 전설과 번외편을 나열하면, 공통된 생성 기구가 보인다.

그리고 다섯 번째인 "Markdown은 AI에게 친화적이다"와 번외편이 보여주는 것은, 이 4가지 패턴이 AI에 의해 스케일링(Scale)된다는 현재의 위치다. AI는 유창하게 요약하고, 유창하게 도해하며, 유창하게 "그럴듯한 숫자"를 보완한다. 유창함을 정확성의 대리 지표(Proxy metric)로 삼는 순간, 패배한다.

마지막으로, 내일부터 바로 사용할 수 있는 실무 프로토콜로서 거칠게 정리한다.

1차 자료를 제시하라 — 2차 기사의 재인용은 출처가 아니다. "출처는 나다"라는 말은 논외다 (실측 로그가 있다면 별개다. 그것은 1차 자료다).
도표와 명언일수록 의심하라 — 확산력과 정확성은 독립 변수다.
원리에는 양을, 기능에는 기본값(Default value)을 물어라 — "이론상", "대응 완료"는 공짜로 할 수 있는 말이다.
AI의 통계치는 URL 대조 전까지 존재하지 않는다 — 그럴듯함은 증거가 아니다.
자신의 과거 자료에도 적용하라 — 필자의 PHP/Go 자료처럼, 가장 가까이에 있는 도시전설의 발생원은 바로 자신이다.

"잘은 모르겠지만(Shiran-kedo)"로 마무리하는 간사이 지방의 지혜는, 사실 성실한 불확실성 표명이었을지도 모른다. 하지만 우리는 엔지니어이므로, "잘은 모르겠지만" 대신 출처를 붙이자.

• 문제의 곡선은 원 논문에 없다. 명언은 원문이 아니다. 다크 모드는 생각보다 효과가 없다. JIT는 잠들어 있다. Markdown 우위는 미실측 상태다.

• 이 모든 것들은 "찾아보면 알 수 있는" 것들이었으나,
  잘 만들어진 외관 때문에 찾아보지 못한 채 유통되고 있었다 — AI 시대에 그럴듯한 정보의 생성 비용은 거의 제로가 되었다.
  검증 비용을 지불하는 자의 상대적 가치는 계속해서 올라간다 — 즉, 괴팍한 엔지니어의 시대다. 당당하게 "그거, 1차 자료 있습니까?"라고 말하며 나아가라.

• 더닝-크루거 효과(Dunning-Kruger effect)의 원 논문은 이것이다 (문제의 곡선은 실려 있지 않다) — Kruger & Dunning (1999), J. Pers. Soc. Psychol.

• "그 효과, 거의 통계적 아티팩트(Statistical artifact) 아닌가?"라는 비판 논문 — Gignac & Zajenkowski (2020), Intelligence

• 러셀(Russell)의 원문과 초출(1933-05-10)을 확인할 수 있는 페이지 — WIST Quotations / 본문은 여기 — Internet Archive

• 다크 모드가 생각보다 배터리를 오래 유지하지 못한다는 실측 이야기 — Purdue 대학교 공식 릴리스 (MobiSys '21)

• PHP 8.4에서 JIT 활성화 관련 INI 설정이 이렇게 바뀌었다 — PHP.Watch

• PHP 공식 매뉴얼 — OPcache Runtime Configuration

※ 본 기사는 개인적인 견해이며, 소속 조직의 공식 견해를 대표하지 않는다. 괴팍함은 필자 개인의 자산이다.