[특집] 프로그래밍은 특별하지 않다 — 글리프의 질문: '예술가들은 AI가 예술에 나쁘다는 걸 안다. 왜 프로그래머는 자신이 예술가라는 걸 모를까?'

크게 보기

들어가며: 싫다면서 왜 쓰는가

2026년 10월 9일 금요일, 한 개인 블로그에 짧은 글이 올라왔습니다. 제목은 「프로그래밍은 특별하지 않다(Programming Isn't Special)」. 부제는 이렇습니다.

예술가들은 AI가 예술에 나쁘다는 걸 안다. 왜 프로그래머들은 우리가 예술가라는 걸 모를까?

쓴 사람은 글리프 레프코위츠(Glyph Lefkowitz). 파이썬 네트워크 프레임워크 Twisted의 창시자이고, 오늘날 JavaScript의 Promise와 모든 주류 언어의 async/await로 이어진 Deferred를 만든 사람입니다. 파이썬 공동체에서는 20년 넘게 이름을 알린 원로 개발자죠.

글은 하루 만에 퍼졌습니다. 해커뉴스에는 올라온 지 3분 만에 등록돼 182점, 댓글 202개를 모았습니다. 그런데 도중에 사용자 신고로 첫 페이지에서 내려갔다가 "왜 이 글이 신고됐냐"는 항의가 이어지자 운영자 dang이 "사용자들이 신고했습니다. 신고를 해제했습니다"라며 되살렸습니다. 로브스터스에서는 65점·댓글 36개, 글리프의 마스토돈 공지는 즐겨찾기 288개·부스트 226개를 받았습니다. 블루스카이에서 가장 많은 공감을 받은 인용은 개발자가 아닌 사람의 것이었습니다. "나는 프로그래머가 전혀 아닌데도 이 글이 정말 생각할 거리를 줬다." 한국어로도 짧은 공유가 돌았습니다. "개발자들은 이런 것을 좀 읽어야 한다."

왜 이렇게 반응이 뜨거웠을까요. 같은 주에 나온 숫자 두 개를 나란히 놓으면 보입니다.

호감은 오르는데 행복은 내려갑니다. 매일 몇 시간씩 쓰지만 중요한 결정은 맡기지 않습니다. 비즈니스 인사이더는 같은 날 이 설문을 "개발자들은 번아웃되고, 무기력하고, AI가 몰고 온 재편에 직면해 있다"는 제목으로 보도했습니다. 한 개발자의 말이 인용됐습니다. "확실히 덜 보람 있어요. 따라가지 않으면 뒤처질 거라는데, AI를 따라가는 건 사실상 불가능해요."

글리프가 겨냥한 건 이 모순입니다. 싫어하면서, 비참해하면서, 그래도 쓴다. 그리고 그는 그 체념 밑에 깔린 논리를 하나 찾아냅니다. "프로그래밍은 예술이 아니니까." 작가와 화가와 음악가는 자기 일이 예술이라고 믿기에 저항하는데, 프로그래머는 자기 일이 그저 기능이라고 믿기에 저항할 이유를 못 찾는다는 겁니다.

글리프의 답은 제목 그대로입니다. 프로그래밍은 특별하지 않다. 그냥 예술이다. 그리고 예술은 우리가 생각하는 것보다 훨씬 평범하다.

이 특집은 이 짧은 글을 끝까지 따라갑니다. 글이 기대고 있는 생각들은 하나하나가 수십 년 된 지적 전통입니다. 1972년 존 버저의 『보는 방법』, 1974년 도널드 크누스의 튜링상 강연 「예술로서의 컴퓨터 프로그래밍」, 1985년 피터 나우르의 「이론 세우기로서의 프로그래밍」, 1983년 리산 베인브리지의 「자동화의 아이러니」, 1991년 레이브와 웽어의 「정당한 주변적 참여」. 그리고 글리프 자신의 작품인 Deferred가 있습니다. 그 내부 구조를 열어 보면 그의 주장이 어디서 왔는지 보입니다. 마지막으로 2026년의 데이터가 있습니다. Anthropic의 무작위 실험, METR의 '불가능해진 실험', 스탠퍼드의 '탄광 속 카나리아', 한국은행의 청년 고용 보고서가 이 논증을 얼마나 받쳐 주는지, 혹은 어디서 흔드는지 따져 봅니다.

1. 글리프는 누구인가: '코드 시인'이라 불리다 놀림받은 소년

글을 읽기 전에 쓴 사람을 알아 두면 좋습니다. 이 글은 이론가의 글이 아니라 자기 작품을 증거로 내미는 장인의 글이기 때문입니다.

글리프는 이번 글에서 10대 후반 시절을 고백합니다. 그때 그는 자신을 "코드 시인(code poet)"이라고 불렀고, 이메일 서명과 자기소개에도 그렇게 적었습니다. 돌아온 건 조롱이었습니다. 당시 말로는 "가식적", 요즘 말로는 "크린지". 결국 그는 서명에서 그 말을 지웠습니다. 사회적으로는 코드를 시에, 혹은 예술에 비유하는 게 우스운 일이라고 받아들였습니다. 하지만 "마음속에서는 그 생각을 버리지 않았다"고 씁니다. 그 생각을 서른 해쯤 품고 있다가 꺼낸 글이 이번 글입니다.

그는 AI에 대해 처음 말하는 사람도 아닙니다. 지난 2년 동안 그의 블로그는 생성형 AI를 둘러싼 논쟁의 한 축이었습니다.

이 목록에서 보이듯 이번 글은 경제·환경·윤리 같은 바깥의 논거를 거의 쓰지 않습니다. 그런 이야기는 이미 다른 글에서 했으니까요. 이번에는 오직 하나, 창작 노동으로서의 프로그래밍만 다룹니다. 그래서 짧고, 그래서 날카롭습니다.

2. 원문 따라 읽기: 다섯 개의 절, 하나의 삼단논법

원문은 짧습니다. 영어로 2,000단어가 조금 넘고, 소제목 다섯 개로 나뉩니다. 그런데 뼈대만 추리면 놀랍도록 단단한 삼단논법입니다.

대부분의 반론은 대전제가 아니라 소전제를 겨냥합니다. "코드는 기능이지 예술이 아니다"라는 반론이죠. 글리프는 이 반론을 미리 알고 있었고, 그래서 글의 3분의 2를 소전제를 지키는 데 씁니다. 그 방어 방식이 독특합니다. 프로그래밍을 예술의 높이로 끌어올리는 대신 예술을 프로그래밍의 높이로 끌어내립니다. 하나씩 보겠습니다.

2-1. 「창작 노동(Creative Work)」: 왜 우리만 다른가

첫 절은 사실 나열입니다. 링크가 문장마다 붙어 있습니다.

• 작가들은 파업을 해서 AI 보호 조항을 얻어 냈다. 2023년 미국작가조합(WGA)의 148일 파업 이야기입니다.
• 수천 명의 예술가가 AI 반대 공개서한에 서명했다. 2024년 10월의 「AI 학습에 관한 성명」입니다.
• 창작 산업이 AI 회사를 상대로 낸 저작권 소송이 너무 많아서 전용 추적 사이트가 있다.
• 인기 유튜버들은 AI를 정말 싫어하고, 음악가이기도 하면 더 싫어한다.

그리고 대조가 나옵니다. "창작 분야 중에서 거의 유일하게, 많은 숙련 프로그래머들은 프로그래밍에 AI를 쓰는 게 괜찮다고 확신한다." 이어지는 문장이 이 글이 퍼진 이유를 압축합니다.

우리는 그걸 싫어하는 것 같고, 그게 우리 모두를 비참하게 만들고 있고, 그게 우리 업계에 하는 짓도 싫어하지만, 그래도 쓰고 있다.

두 개의 링크가 이 문장을 받칩니다. 하나는 2026년 10월 비즈니스 인사이더의 개발자 번아웃 설문, 다른 하나는 사흘 전(10월 6일) 발표된 스택오버플로 2026 개발자 설문입니다. 싫어하면서 쓴다는 이 모순이 글의 출발점입니다. 글리프는 그 모순을 정당화하는 논리가 "프로그래밍은 예술이 아니니까"라고 진단합니다. 도구가 일을 해내고 그 일이 그저 기능적인 것이라면, 무슨 상관이냐는 거죠.

크게 보기

2-2. 「예술은 평범할 수 있다(Art can be Mundane)」: 신비화 벗기기

여기서 글리프는 존 버저의 『보는 방법(Ways of Seeing)』을 꺼냅니다. 이 글 전체의 이론적 지렛대입니다. 핵심은 이렇습니다(3장에서 자세히 다룹니다).

• 한 미술사가가 17세기 단체 초상화를 "깊고 빛나는 검정의 미묘한 변조", "조화로운 융합" 같은 황홀한 문장으로 묘사한다.
• 버저가 보여 주는 실상: 가난한 늙은 화가가 일감이 필요했고, 관리들은 공식 초상화 하나쯤 있으면 좋겠다고 생각했다. 돈을 주고 그리게 했고, 그래서 그림이 생겼다.
• 잘 그린 그림이다. 아름답기까지 하다. 하지만 평범한 목적으로 주문된 일이었고, 그 목적에 잘 맞았다. 신성한 유물이 아니었고 지금도 아니다.

크게 보기

글리프는 여기서 미학 자체를 깎아내리지 않는다는 점을 분명히 합니다. "나도 좋은 미학 철학을 사랑한다… 오히려 더 많이 해야 한다." 그가 반대하는 건 감상의 깊이가 아니라 창작 행위를 다른 노동보다 신비롭게 떠받드는 것입니다.

그리고 사다리를 하나 보여 줍니다. 우리는 소설가의 일을 신비화하고 기자의 일을 깎아내린다. 기자는 그래도 카피라이터보다는 존중받는다. 하지만 "소설가와 카피라이터 사이에 초월적인 구분은 없다. 기술의 상당 부분이 같고, 그 구분은 상업과 기회의 우연일 뿐이다." 실제로 유명한 작가 중 상당수가 두 역할을 다 거쳤습니다. 글리프는 이게 우연이 아니라고 말합니다. 평범한 단어를 다루는 일이야말로 예술적인 단어를 다루는 훌륭한 연습이기 때문입니다. "평범한 창의성도 여전히 예술적이니까."

크게 보기

이 절이 놓은 덫은 이렇습니다. 예술의 문턱을 "숭고함"에서 "평범한 창작 노동"으로 낮추면, 프로그래밍은 자동으로 그 안에 들어옵니다. 이제 남은 건 코드도 미적일 수 있다는 걸 보여 주는 일입니다.

2-3. 「코드는 아름다울 수 있다(Code can be Beautiful)」: 한 사람의 시

이 절은 고백으로 시작합니다. 10대 후반의 글리프는 자신을 "코드 시인(code poet)"이라고 불렀고, 이메일 서명과 자기소개에도 그렇게 썼습니다. 그리고 "가식적"이라는 놀림을 받았습니다(요즘 말로는 "크린지"). 결국 서명에서 지웠지만 마음속에서는 그 생각을 버리지 않았다고 합니다.

그 증거로 자기 이력에서 가장 유명한 물건, Deferred를 꺼냅니다.

Deferred는 비동기 작업 실행에 관한 의도적인 시다. 그 문제의 미학과 그것을 쓰는 경험에 의식적으로 눈을 두고 만들었다. 그것이 영향력을 가진 건 미학에 집중했기 때문이다.

출발점은 지겨움이었습니다. RPC(원격 프로시저 호출) 클라이언트·서버 프로그램에서 호출할 때마다 성공 콜백과 실패 콜백(errback) 두 개를 넘겨야 했습니다. 그 두 콜백은 "일을 잘 해냈지만 못생겼고 쓰기 짜증 났다". Deferred는 기능적 결함이 아니라 미적 불만에서 태어났습니다. 5장에서 이 구조를 해부합니다.

글리프는 과장하지 않으려 조심합니다. "시가 존재한다고 위대한 시인 것은 아니다. 그저 시일 뿐이다." 그리고 소프트웨어의 미적 문화는 순수 예술보다 민속 서사시(folk epic poetry)에 가깝다고 말합니다. 호메로스 이전의 구전 서사시처럼, 여러 장인이 차례로 자기 것을 더해 원본이 거의 녹아 없어지는 전통이라는 겁니다. MochiKit.Async에서 jQuery Deferred, JavaScript Promise, async/await까지. 그리고 자기도 "원본"은 아니었다고 덧붙입니다. E 언어의 Promise에서 많이 빌려 왔으니까요.

이 절에서 가장 중요한 문장은 아마 이것입니다.

코드를 의도적인 예술적 표현으로 만들려면, 그 문제 영역을 꽤 오래 곱씹어야 한다. 천 개의 콜백 인자를 손으로 넘기는 지겨움을 겪지 않았다면, 나는 그런 걸 만들 기술도, 사실 동기도 없었을 것이다.

이 문장이 글의 마지막 절, "평범한 것을 지켜라"로 가는 다리입니다. 지겨움이 곧 재료였다는 말이기 때문입니다.

그다음 글리프는 다시 사다리를 놓습니다. 대부분의 코드는 이렇지 않다. 대부분의 코드는 이럴 기회도 없다. 평일의 기능적인 코드다. "숙녀를 울릴 수 없는" 코드이고, 말하자면 카피라이팅이다. (이 표현은 2002년 웹코믹 『Achewood』의 한 회에서 왔습니다. 친구가 갑자기 피아노를 잘 치자 고양이 로스트 비프가 한탄합니다. "내 코드는 개의 코드야. 숙녀를 울릴 수도, 노숙자의 인생을 바꿀 수도 없어… 피아노 음악처럼은.") 하지만 대부분의 글도, 대부분의 시각 예술(광고)도, 대부분의 라이브 음악(아무도 듣지 않는 술집 배경 음악)도 마찬가지다. 그래도 의도적으로 미적으로 설계된 코드는 사회적으로도 기술적으로도 중요해지는 경향이 있다.

마지막으로 소프트웨어 공동체의 "자기 신비화" 전통을 짚습니다. "프로그램은 사람이 읽으라고 쓰는 것이고, 기계가 실행하는 건 부수적일 뿐이다"라는 에이벌슨의 말, 유닉스 철학, 파이썬의 PEP 20(「파이썬의 선」), 펄의 철학. 그리고 사용자 쪽의 미적 경험도 있습니다. 페데리코 비티치가 해마다 쓰는 iOS 리뷰는 미적 비평이고, "모든 비디오 게임 리뷰는 소프트웨어 리뷰"입니다.

2-4. 「소프트웨어 문해력에 관한 짧은 여담」

짧지만 쓸쓸한 절입니다. 소프트웨어 공동체에는 비평적 읽기의 전통이 거의 없습니다. 크누스의 문학적 프로그래밍(Literate Programming)은 자주 칭송받지만 거의 실천되지 않습니다. 사용자는 소프트웨어가 어떻게 만들어지는지 뒤죽박죽인 그림을 갖고 있고, 현대 프로그래밍 관행은 일부러 소프트웨어가 하는 일에 대해 나쁜 멘탈 모델을 만들어서 이해를 더 어렵게 합니다. "소프트웨어의 미적 경험은 그 내부 상태와 극단적으로 분리돼 있다."

그리고 한 줄. "이 문제들은 모두 AI보다 수년, 아니 수십 년 앞서지만, 그렇다고 열심히 더 나쁘게 만들 이유는 없다."

2-5. 「평범한 것을 지켜라(Defend The Mundane)」: 결론

마지막 절이 이 글의 진짜 주장입니다.

AI로 모든 카피라이팅, 모든 그래픽 디자인, 모든 지루하고 평범한 예술, 그리고 그래, 모든 지루한 맞춤 워드프레스 테마 개발을 지워 버리면, 사람들이 기량을 끌어올려 마침내 위대한 일을 해내는 데 필요한 엄청난 양의 연습과 숙고의 실전 기회를 모두 없애게 된다. 교육은 훌륭하지만 진짜 기술 발달의 대부분은 일을 하면서 일어나고, 언제나 그래 왔다.

"일을 하면서"에 붙은 링크는 비틀스가 함부르크 클럽에서 보낸 1만 시간에 관한 글입니다(6장).

곧바로 글리프는 오해를 막습니다. 추상화나 자동화를 쓰지 말자는 게 아니다. "프로그래밍은 추상화의 예술이다. 작은 아이디어를 엮어 큰 아이디어로 만드는 법, 작은 것들을 자동화하는 규칙을 이해함으로써 더 큰 시스템의 자동화를 이해하는 법이다." 문제는 AI를 써서 이해를 더 높은 층으로 끌어올리는 대신 이해를 없애 버릴 때, 창의적 의사결정 과정 자체를 파괴할 때입니다. 그건 우리 자신과 사용자, 그리고 다음에 우리 코드를 받을 동료 개발자에게 몹쓸 짓이라는 겁니다. 화가가 관객에게, 음악가가 청중에게 자기 창작물 대신 자동 생성된 땜빵을 내밀 때처럼요.

슬롭은 슬롭이다. 매체가 무엇이든.

그리고 0.1%의 산수가 나옵니다. 평범한 프로젝트마다 이를테면 0.1% 정도의 확률로 위대함이 깃든다. 프로젝트 하나를 AI로 하면 거의 아무 차이도 없다. 하지만 모든 프로젝트를 그렇게 하는 습관을 들이면 위대한 순간의 총 확률이 "가끔은 반드시"에서 "절대 없음"으로 바뀐다(7장에서 직접 계산해 봅니다).

저항의 구체적 방법은 "이 짧은 글의 여백을 훌쩍 넘는다"며 각자에게 맡깁니다. 얼마나 저항할지, 어떤 쓰임에 저항할지는 당신 몫이다. 다만 다른 창작 매체에서 저항할 가치가 있는 만큼, 소프트웨어에서도 저항할 가치가 있다.

마지막 두 문장은 제목을 되받습니다.

프로그래밍은 특별하지 않다. 그건 그냥 예술이고, 예술은 가장 인간적인, 그래서 가장 보편적인 것이다.

제목의 "특별하지 않다"는 비하가 아니었습니다. 프로그래밍만 예외로 빼 주지 말라는 뜻이었습니다. 화가와 작가가 지키려는 것을 프로그래머도 똑같이 지킬 자격이 있다는 겁니다.

3. 핵심 개념 ① 신비화: 존 버저가 정말로 말한 것

글리프 논증의 지렛대는 '신비화(mystification)'라는 단어 하나입니다. 이 말이 어디서 왔는지, 원래 무슨 뜻이었는지 정확히 알아 두면 글리프가 이 말을 어떻게 빌려 썼는지, 그리고 어디서 단순화했는지가 보입니다.

3-1. 1972년, BBC의 30분짜리 텔레비전 시리즈

『보는 방법(Ways of Seeing)』은 원래 책이 아니라 텔레비전 프로그램이었습니다. 1972년 BBC Two에서 방영된 30분짜리 4부작으로, 미술 비평가이자 소설가인 존 버저가 프로듀서 마이크 딥과 함께 만들었습니다. 같은 해 BBC와 펭귄이 일곱 편의 에세이로 된 책을 냈습니다(넷은 글, 셋은 그림만으로 된 '시각 에세이'). 이 책은 이후 반세기 동안 영미권 미대와 인문학 수업의 필독서가 됐습니다.

버저의 출발점은 발터 벤야민의 1935년 글 「기술 복제 시대의 예술 작품」입니다. 버저 스스로 1장의 많은 생각이 벤야민에게서 왔다고 밝힙니다. 벤야민은 사진과 영화가 그림을 무한히 복제할 수 있게 되면서 원본 예술 작품이 지니던 아우라(aura), 즉 지금 여기에 하나뿐이라는 신비로운 권위가 시든다고 했습니다. 그리고 19세기 사람들이 "사진이 예술인가"를 두고 다툴 때 정작 중요한 질문, 곧 "사진이 예술의 본성 자체를 바꿔 버리지 않았는가"를 놓쳤다고 지적했습니다. 이 지적은 2026년의 "코드가 예술인가" 논쟁에도 그대로 적용됩니다. 진짜 질문은 아마 "AI가 창작 노동의 본성 자체를 바꾸고 있지 않은가"일 겁니다.

3-2. 할스의 마지막 두 그림

버저가 든 예는 네덜란드 화가 프란스 할스가 1664년에 그린 두 단체 초상화, 하를럼 양로원의 남자 이사들과 여자 이사들입니다. 늙고 가난한 사람들을 돌보는 시설의 운영진을 그린 공식 초상화죠.

버저는 먼저 한 미술사가가 이 그림들을 묘사한 문장을 인용합니다.

깊고 빛나는 검정의 미묘한 변조가 전체의 조화로운 융합에 기여하며, 힘찬 살빛 색조와 잊을 수 없는 대비를 이룬다…

그다음 그 문장이 지워 버린 것을 보여 줍니다. 그림을 그릴 때 할스는 여든이 넘었고 빈털터리였습니다. 1664년 겨울 그가 얼어 죽지 않은 건 공공 구호로 받은 이탄(泥炭, 땔감) 세 수레 덕분이었습니다. 그리고 그 구호를 관리하던 사람들이 바로 그가 그리고 있던 이사들이었습니다. 버저는 그림 속 인물들의 표정에서 이 긴장을 읽습니다. 가난한 늙은 화가가 자신에게 자선을 베푸는 사람들을 그리는 장면, 이것이 그림의 진짜 드라마라는 겁니다.

그러고는 정의를 내립니다.

신비화란 그렇지 않았다면 뻔히 보였을 것을 설명으로 지워 버리는 과정이다.

"미묘한 변조"와 "조화로운 융합" 같은 문장은 아름답지만, 그 아름다운 문장이 그림이 만들어진 사회적 현실, 곧 돈과 가난과 권력을 시야에서 치워 버립니다. 그림을 시간과 계급을 초월한 걸작으로 떠받드는 순간, 그것이 누군가의 노동이었다는 사실이 사라집니다.

3-3. 글리프는 버저를 어떻게 빌렸나

글리프의 요약은 이렇습니다. "가난한 늙은 화가가 일감이 필요했고, 관리들은 공식 초상화가 있으면 좋겠다고 생각했다. 그래서 돈을 줬고, 그는 그렸고, 그들은 그림을 가졌다." 이 요약은 정확하지만 강조점이 옮겨져 있습니다.

이건 오독이라기보다 차용입니다. 버저가 신비화를 벗겨 계급을 드러냈다면, 글리프는 같은 방법으로 노동을 드러냅니다. 그리고 사실 이 둘은 멀지 않습니다. 버저가 보여 준 할스는 일감이 절실한 노동자였으니까요. 다만 독자는 글리프가 버저의 주장 전체를 전한 게 아니라 자기 논증에 필요한 한 갈래를 빌렸다는 점을 알아 두면 좋습니다.

3-4. 신비화의 사다리: 소설가 > 기자 > 카피라이터

글리프는 신비화를 글쓰기에 적용합니다. 우리는 소설가를 신비화하고, 기자는 깎아내리고, 카피라이터는 더 깎아내립니다. 하지만 기술은 상당 부분 같고, 그 구분은 "상업과 기회의 우연"입니다.

그가 링크한 2011년 『디 올(The Awl)』의 글 「먼저 카피라이터였던 여섯 작가」는 이 사다리를 실제로 오르내린 사람들의 명단입니다.

루슈디의 말이 이 표의 결론입니다. "나는 일하듯 쓴다. 아침에 앉아서 한다. 마감을 어기지 않는다… 글쓰기의 직업적 기술 상당 부분을 나는 광고 일을 하던 그 시절에 배웠다."

위의 「예술인가, 일인가」 카드 실험이 바로 이 사다리를 시험합니다. 시스티나 천장화도, 바흐의 칸타타도, 디킨스의 연재도 모두 주문받은 일이었습니다. 윈도우 95 시작음도, 슈퍼 마리오 1-1도, Deferred도 모두 기능을 위해 만든 것이었습니다. 우리가 앞의 것들에만 '예술' 딱지를 붙인다면, 그건 작업의 성격 때문이 아니라 유명세와 시간이 더한 아우라 때문일 가능성이 큽니다.

4. 핵심 개념 ② 코드는 예술인가: 50년 된 질문

글리프가 "코드 시인"이라는 말 때문에 놀림받았다고 했지만, 사실 이 생각은 컴퓨터 과학의 거장들이 오래전부터 진지하게 해 온 이야기입니다. 글리프가 "소프트웨어에도 자기 신비화의 전통이 있다"고 말할 때 가리키는 것이 바로 이 계보입니다.

4-1. 크누스(1974): 예술은 '아직 다 이해하지 못한 것'을 다루는 일

1974년 11월, 도널드 크누스는 튜링상 수상 강연의 제목을 「예술로서의 컴퓨터 프로그래밍」으로 정했습니다. 그가 쓰던 대작의 제목도 『컴퓨터 프로그래밍의 예술(The Art of Computer Programming)』이었죠. 강연은 1959년 ACM 학회지 사설을 인용하며 시작합니다. 그 사설은 "프로그래밍을 예술에서 규율 잡힌 과학으로 이행시켜야 한다"고 했습니다. 크누스는 이 이분법을 뒤집습니다.

과학은 우리가 아주 잘 이해해서 컴퓨터에게 가르칠 수 있는 지식이다. 무언가를 완전히 이해하지 못한다면, 그것을 다루는 일은 예술이다.

2026년에 이 정의를 다시 읽으면 섬뜩합니다. 크누스의 기준대로라면 컴퓨터에게 가르칠 수 있게 된 것은 더 이상 예술이 아닙니다. LLM이 프로그래밍을 상당 부분 '배운' 지금, 프로그래밍의 어느 부분이 여전히 예술로 남는가 하는 질문이 됩니다. 글리프의 답은 아마 이것일 겁니다. 문제 영역을 오래 곱씹어야만 보이는 것, 지겨움의 정확한 모양을 알아야 설계할 수 있는 추상화. 그건 아직 아무도 컴퓨터에게 가르치지 못했습니다.

이 강연에는 글리프의 글과 놀랍도록 겹치는 단락이 하나 있습니다.

모든 프로그래밍 작업이 재미있을 수는 없다… 하지만 아름다운 도구를 가지고 일한다면 일상적인 작업도 여전히 즐겁다… 부디 쓰는 즐거움이 있는 도구를 주십시오. 특히 우리의 일상적인 과제를 위해서.

Deferred가 정확히 이것이었습니다. 원격 호출이라는 일상적인 과제를 위한, 쓰는 즐거움이 있는 도구. 크누스는 강연을 이렇게 맺습니다. "자신을 무의식적으로 예술가로 여기는 프로그래머는 자기 일을 즐기고, 더 잘할 것이다."

4-2. 브룩스(1975): 장인의 기쁨, 그리고 장인의 고통

『맨먼스 미신』은 일정 관리와 팀 규모에 관한 책으로 유명하지만, 1장에는 프로그래밍이라는 일의 기쁨을 다섯 가지로 정리한 짧은 절이 있습니다. 만드는 기쁨, 남에게 쓸모 있는 것을 만드는 기쁨, 맞물려 돌아가는 부품의 퍼즐 같은 기쁨, 반복되지 않는 일이 주는 배움의 기쁨. 그리고 이 문장이 있습니다.

프로그래머는 시인처럼 순수한 생각의 재료에서 아주 조금 떨어져 일한다. 그는 공중에, 공기로, 상상력을 짜내어 성을 짓는다.

그런데 그다음 절이 「장인의 고통」입니다. "모든 창작 활동에는 지루하고 고된 노동의 시간이 따르고, 프로그래밍도 예외가 아니다." 위대한 개념을 설계하는 건 재미있지만 "자잘한 버그를 찾는 건 그냥 일"이라고요. 브룩스는 기쁨과 고통을 한 직업의 두 면으로 봤습니다. 글리프의 주장은 이 연결을 끊지 말라는 것입니다. 고통을 통째로 덜어 내면 기쁨을 만들 재료도 함께 사라진다는 겁니다.

4-3. 크누스(1984)와 SICP(1985): 프로그램은 사람에게 쓰는 글이다

1984년 크누스는 한 걸음 더 나갑니다. 「문학적 프로그래밍(Literate Programming)」에서 그는 프로그래머를 "에세이스트"에 비유합니다. 그가 만든 WEB 시스템에서는 하나의 소스 파일에 설명과 코드가 섞여 있고, WEAVE가 그것을 사람이 읽는 조판 문서(TeX)로, TANGLE이 기계가 컴파일할 코드(Pascal)로 풀어냅니다. 프로그램은 컴파일러가 원하는 순서가 아니라 사람이 이해하기 가장 좋은 순서로 쓰입니다.

같은 무렵 MIT의 에이벌슨과 서스먼(그리고 공저자 줄리 서스먼)은 『컴퓨터 프로그램의 구조와 해석(SICP)』 서문에 글리프가 인용한 그 문장을 씁니다. 원문 전체는 이렇습니다.

우리는 컴퓨터 언어가 단지 컴퓨터가 연산을 수행하게 하는 수단이 아니라 방법론에 관한 생각을 표현하는 새로운 형식의 매체라는 생각을 확립하고 싶다. 그러므로 프로그램은 사람이 읽으라고 쓰는 것이고, 기계가 실행하는 것은 부수적일 뿐이다.

"표현하는 매체." 붓과 물감, 단어와 문장처럼, 코드가 생각을 표현하는 매체라는 주장입니다. 글리프가 2-4절에서 "문학적 프로그래밍은 자주 칭송받지만 거의 실천되지 않는다"고 아쉬워한 것은 이 전통이 이상으로만 남았다는 뜻입니다.

4-4. 나우르(1985): 프로그램의 본체는 사람 머릿속에 있다

이 계보에서 2026년에 가장 자주 다시 읽히는 글은 덴마크의 컴퓨터 과학자 피터 나우르(ALGOL 60의 공동 설계자, 튜링상 수상자)의 짧은 에세이 「이론 세우기로서의 프로그래밍」입니다. 글리프가 직접 인용하지는 않지만 그의 논증 밑바닥에 깔린 생각입니다.

나우르의 주장은 이렇습니다. 프로그래밍의 핵심 산출물은 코드나 문서가 아니라 프로그래머의 머릿속에 세워지는 '이론'이다. 여기서 이론은 철학자 길버트 라일이 말한 의미로, 사실의 목록이 아니라 '어떻게 할 줄 아는 앎'입니다. 이 프로그램이 현실의 어떤 문제에 대응하는지, 왜 이렇게 생겼는지, 요구가 바뀌면 어디를 어떻게 고쳐야 하는지 아는 것이죠. 그리고 이렇게 씁니다.

프로그램의 죽음은 그 이론을 가진 프로그래머 팀이 해체될 때 일어난다. 죽은 프로그램도 계속 실행될 수는 있다… 죽음이 실제로 드러나는 건 수정 요구에 지적으로 답할 수 없을 때다.

그렇다면 이론은 어떻게 전해질까요. 나우르는 코드와 문서를 읽는 것만으로는 "불충분하다"고 말합니다. 새 프로그래머는 "이미 이론을 가진 프로그래머들과 가까이 접촉하며 일해야" 하고, "가장 중요한 교육 활동은 학생이 적절한 감독과 지도 아래 관련된 일을 직접 하는 것"이라고요.

이 두 번째 질문이 글리프의 마지막 절, "평범한 것을 지켜라"로 이어집니다. 그 전에 글리프가 자기 증거로 내민 Deferred를 직접 열어 보겠습니다.

5. 아키텍처 해부: '시'라는 Deferred는 어떻게 생겼나

글리프가 자기 시라고 부른 물건을 직접 열어 보겠습니다. 비동기 프로그래밍이 낯선 독자를 위해 바닥부터 시작합니다.

5-1. 문제: 기다리는 동안 무엇을 할 것인가

네트워크 서버는 대부분의 시간을 기다리면서 보냅니다. 데이터베이스 응답, 다른 서버의 답, 디스크 읽기를 기다리죠. 가장 단순한 방법은 기다리는 동안 그냥 멈추는 것입니다(동기, blocking). 그러면 손님 한 명을 기다리는 동안 다른 손님 999명이 줄을 섭니다. 스레드를 손님 수만큼 만들 수도 있지만, 스레드는 비싸고 서로 데이터를 건드리다 사고가 납니다.

Twisted(2002년 첫 공개)가 택한 길은 이벤트 루프입니다. 한 스레드가 "준비된 일"만 골라 처리하고, 기다려야 하는 일은 "끝나면 이 함수를 불러 줘"라고 맡겨 두고 넘어갑니다. 이 "끝나면 부를 함수"가 콜백(callback)입니다. 실패했을 때 부를 함수는 Twisted 식으로 에러백(errback)이라고 부릅니다.

문제는 모양이었습니다. 글리프가 겪은 지겨움을 그대로 재현하면 이렇습니다. 사용자를 불러오고, 그 사용자의 글을 불러와 화면에 그리는 두 단계짜리 일입니다.

# Deferred 이전: 호출마다 성공·실패 함수 한 쌍을 넘긴다 (설명을 위한 재구성)
def show_posts(user_id):
    def got_user(user):
        def got_posts(posts):
            render(user, posts)
        def posts_failed(err):
            show_error(err)
        client.call_remote("getPosts", user.id,
                           callback=got_posts, errback=posts_failed)
    def user_failed(err):
        show_error(err)
    client.call_remote("getUser", user_id,
                       callback=got_user, errback=user_failed)

두 단계인데 함수가 네 개, 들여쓰기가 세 칸, 실패 처리가 두 군데로 흩어졌습니다. 단계가 다섯이면 어떻게 될지 상상해 보세요. 훗날 Node.js 개발자들이 콜백 지옥(callback hell)이라고 부르게 될 바로 그 모양입니다. 기능에는 아무 문제가 없습니다. 그런데 못생겼고, 읽기 어렵고, 실수하기 쉽습니다. 실패 처리를 하나 빼먹으면 오류가 소리 없이 사라집니다.

글리프는 2003년 파이콘 논문 「파이썬에서 지연 실행의 일반화」에서 이 시절을 이렇게 회고합니다. "Twisted의 콜백 기반 요청·응답 방식으로 몇 달 일하고 나자, 무언가 더 필요하다는 게 분명해졌다. 오류 때문에 어떤 처리가 소리 없이 멈춰 버리는 일이 잦았다." 그리고 영감의 출처도 밝힙니다. "'X를 돌려주는 메서드'와 'X를 줄 Deferred를 돌려주는 메서드'를 구분하자는 생각은 원래 E 언어의 '언젠가(eventually)' 연산자에서 왔다." 23년 뒤의 에세이에서 한 말("E의 Promise에서 많이 빌려 왔다")과 정확히 같은 이야기입니다.

크게 보기

5-2. 발상의 전환: '나중에 올 결과'를 값으로 만들기

Deferred의 핵심 아이디어는 한 문장입니다. 콜백을 함수에 넘기지 말고, 함수가 '나중에 올 결과'를 담은 객체를 돌려주게 하라.

d = client.callRemote("getUser", user_id)   # 즉시 Deferred를 돌려받는다
d.addCallback(got_user)                      # 성공하면 이걸
d.addErrback(show_error)                     # 실패하면 이걸

달라진 건 작아 보이지만 결정적입니다. 이제 "나중에 올 결과"가 값이 됐습니다. 값이니까 변수에 담고, 함수에서 돌려주고, 다른 함수에 넘기고, 리스트에 모을 수 있습니다(DeferredList). 호출하는 쪽과 결과를 처리하는 쪽이 분리됩니다. 호출 시점에 처리 방법을 다 정해 둘 필요가 없어졌습니다.

아래가 Twisted 공식 문서에 수록된 Deferred의 구조도입니다. 20년 넘게 거의 그대로 쓰인 그림입니다.

크게 보기

출처: Twisted 프로젝트 문서 「Deferred Reference」(MIT 라이선스). 원본은 twisted/twisted 저장소에 있습니다.

그림을 읽는 법입니다.

1단계(위). 데이터를 원하는 쪽(Data Sink)의 메서드가 데이터 원천(Data Source)에 요청합니다. 원천은 결과 대신 Deferred 객체(파란 상자)를 즉시 돌려줍니다. 요청한 쪽은 그 객체에 콜백·에러백 쌍을 매답니다(addCallbacks). 점선 상자 안의 초록·빨강 상자 세 쌍이 그것입니다. 핵심은 쌍이라는 점입니다. addCallback(f)는 에러백 자리를 "통과"로 채운 쌍을, addErrback(g)는 콜백 자리를 "통과"로 채운 쌍을 추가합니다.

2단계(아래, "그날 늦게…"). 결과가 준비되면 원천이 d.callback(결과)나 d.errback(실패)를 부릅니다. 그때부터 결과는 두 차선 중 하나를 따라 아래로 흐릅니다. 오른쪽에 적힌 네 가지 규칙이 이 구조의 전부입니다.

문서의 표현을 빌리면 에러백의 사슬은 "일련의 except: 문의 비동기 버전"입니다. 다시 말해 Deferred는 동기 코드의 try/except 구조를 시간 축 위로 옮겨 놓은 것입니다. 실패가 난 위치와 처리하는 위치를 떼어 놓을 수 있게 되자 앞의 네 함수짜리 코드가 이렇게 줄어듭니다.

def show_posts(user_id):
    d = client.callRemote("getUser", user_id)
    def got_user(user):
        d2 = client.callRemote("getPosts", user.id)
        d2.addCallback(lambda posts: render(user, posts))
        return d2            # Deferred를 돌려주면 바깥 사슬이 그걸 기다린다
    d.addCallback(got_user)
    d.addErrback(show_error) # 어느 단계의 실패든 여기 하나로
    return d

주석의 두 줄이 Deferred의 두 번째 아이디어입니다. 콜백이 또 다른 Deferred를 돌려주면 바깥 사슬은 그 Deferred가 끝날 때까지 멈춰 기다렸다가 그 결과를 이어받습니다(chaining). 비동기 단계를 몇 개든 평평하게 이어 붙일 수 있게 된 것이죠. 실패 처리는 맨 아래 하나로 모였습니다. 아래 위젯에서 두 차선을 직접 움직여 보세요.

5-3. 그 밖의 세부: 실패도 값이다

Deferred 설계에는 덜 알려졌지만 중요한 결정이 두 개 더 있습니다.

5-4. 민속 서사시: 25년 동안 장인들이 더한 매듭

글리프는 Deferred의 영향력이 "그 자체의 지속력보다 그다음에 온 것들에 미친 영향"에 있다고 말합니다. 그 계보를 따라가 보면 그가 왜 "민속 서사시"라는 비유를 골랐는지 이해가 됩니다.

크게 보기

위젯에서 같은 일을 여섯 세대의 문법으로 바꿔 보면, 각 장인이 어떤 매듭을 더했는지 보입니다. 특히 2007년의 inlineCallbacks와 2017년의 async/await를 나란히 놓아 보세요. 거의 같은 모양입니다.

5-5. 이 해부가 글리프의 논증에 주는 것

왜 이렇게 길게 Deferred를 뜯어봤을까요. 이 계보 안에 글리프 논증의 세 가지 증거가 들어 있기 때문입니다.

1. 미적 동기가 기술적 결과를 낳았다. 콜백 쌍은 "일을 잘 해냈다". Deferred는 기능을 추가한 게 아니라 모양을 바꿨고, 그 모양이 25년 동안 업계 전체의 문법을 바꿨습니다. "미적으로 설계된 코드는 사회적·기술적으로 중요해지는 경향이 있다"는 주장의 실례입니다.
2. 지겨움이 재료였다. 천 개의 콜백을 손으로 넘겨 본 사람만이 그 지겨움의 정확한 모양을 압니다. 그 모양을 알아야 그것을 없애는 추상화를 설계할 수 있습니다. 만약 2001년에 콜백 보일러플레이트를 대신 써 주는 도구가 있었다면, 글리프는 지겨움을 느끼지 않았을 테고 Deferred도 없었을지 모릅니다.
3. 장인들의 사슬은 사람을 통해 이어졌다. E → Twisted → MochiKit → jQuery → Promises/A+ → 언어 표준. 각 고리는 앞 사람의 작업을 이해하고 자기 매듭을 더한 사람들입니다. 이해 없이 생성된 코드는 이 사슬에 고리를 보탤 수 없습니다.

세 번째가 가장 무겁습니다. 이건 1985년 피터 나우르가 「이론 세우기로서의 프로그래밍」에서 한 말과 정확히 겹칩니다(4장).

6. 핵심 개념 ③ 평범한 일이 연습장이다: 함부르크에서 라이베리아의 재단사 골목까지

"교육은 훌륭하지만 진짜 기술 발달의 대부분은 일을 하면서 일어나고, 언제나 그래 왔다." 글리프 논증의 실증적 기둥은 이 한 문장입니다. 이 문장은 얼마나 단단할까요. 세 갈래의 연구가 있고, 그중 하나는 글리프에게 불리합니다. 셋 다 보겠습니다.

6-1. 비틀스의 함부르크: 아무도 듣지 않던 연주

글리프가 링크한 글은 2026년 8월 에릭 앨퍼가 쓴 「비틀스가 함부르크의 1만 시간에 대해 가르쳐 줄 수 있는 것」입니다. 이야기는 말콤 글래드웰의 2008년 책 『아웃라이어』에서 유명해졌습니다.

1960년부터 1962년까지 리버풀의 무명 밴드는 독일 함부르크의 홍등가 클럽에서 다섯 차례 장기 공연을 했습니다. 손님은 선원과 취객이었고, 대부분 음악을 듣지 않았습니다. 밴드는 밤마다 몇 시간씩, 때로는 새벽까지 연주해야 했습니다. 존 레넌은 이렇게 회고했습니다. "함부르크에서는 여덟 시간을 연주해야 했다." 레퍼토리가 금방 바닥났고, 낯선 곡을 익히고 즉흥으로 늘이는 수밖에 없었습니다. 글래드웰은 이 시기에 비틀스가 1,200번 넘게 무대에 섰다고 계산했습니다(비틀스 연구가 마크 루이슨은 함부르크 무대 시간을 38주 동안 약 1,100시간으로 셉니다).

크게 보기

이 장면이 글리프의 논증과 겹치는 지점은 분명합니다. 함부르크의 무대는 예술이 아니라 생계였습니다. 술집 배경 음악, 글리프의 표현대로 "대부분의 라이브 음악은 아무도 듣지 않는 술집 배경 음악"이었죠. 그런데 그 평범하고 지루한 반복이 1963년의 비틀스를 만들었습니다. 만약 1960년 함부르크 클럽들이 밴드 대신 주크박스를 들였다면 어땠을까요. 실제로 그런 일이 있었습니다(12장의 '통조림 음악' 이야기).

6-2. 불편한 반론: 에릭슨은 "일은 연습이 아니다"라고 했다

여기서 정직해야 할 대목이 있습니다. "1만 시간의 법칙"의 학문적 원천으로 알려진 안데르스 에릭슨의 1993년 논문 「전문가 수행의 습득에서 의도적 연습의 역할」은 사실 글리프의 주장과 반대 방향을 가리킵니다.

에릭슨과 동료들은 베를린 음악원의 바이올린 학생들을 조사했습니다. 18세까지 혼자 연습한 시간이 '최상위' 그룹은 약 7,410시간, '우수' 그룹은 5,301시간, 음악 교사 지망 그룹은 3,420시간이었습니다. 논문 어디에도 '1만 시간의 법칙'은 없습니다(그건 글래드웰의 요약입니다). 대신 논문은 세 가지 활동을 엄격히 구분합니다.

논문은 심지어 소프트웨어를 예로 듭니다. 숙련된 사용자들도 일하면서는 자기가 아는 몇 개 명령만 계속 쓴다는 것이죠. 즉 에릭슨의 틀에서 보면 "지루한 워드프레스 테마를 백 개 만들어도 실력이 늘지 않을 수 있다"는 반론이 가능합니다.

2014년 맥나마라·햄브릭·오스월드의 메타분석(88개 연구)은 더 아픕니다. 의도적 연습이 수행 차이를 설명하는 정도는 게임 26%, 음악 21%, 스포츠 18%, 교육 4%, 그리고 전문직에서는 1% 미만이었습니다. 연습량만으로 전문가가 되는 건 아니라는 결론이죠(에릭슨 측은 연구들이 '연습'을 너무 느슨하게 정의했다고 반박했습니다).

그런데 아이러니가 있습니다. 비틀스의 함부르크 공연은 에릭슨의 분류로는 '의도적 연습'이 아니라 '일'이었습니다. 돈을 받고, 관객 앞에서, 결과를 내야 하는 공연이었으니까요. 글래드웰이 에릭슨을 빌려 든 대표 사례가 사실은 에릭슨의 이론보다 글리프의 주장을 더 잘 받쳐 주는 셈입니다. 그리고 다음 연구 전통은 바로 그 '일 속의 배움'을 정면으로 다룹니다.

6-3. 정당한 주변적 참여: 견습생은 단추부터 단다

1991년 인류학자 진 레이브와 컴퓨터 과학자 출신 교육학자 에티엔 웽어는 『상황 학습: 정당한 주변적 참여』라는 얇은 책을 냈습니다. 학교가 아니라 일터에서 사람이 어떻게 배우는가를 다룬 책입니다. 레이브는 1973년부터 1978년까지 라이베리아 수도 몬로비아의 '재단사 골목'에서 약 250명의 재단사와 견습생을 관찰했습니다. 책은 여기에 유카탄의 산파, 미 해군 조타수, 정육 노동자, 알코올 중독자 자조 모임까지 다섯 공동체를 비교합니다.

핵심 개념인 정당한 주변적 참여(legitimate peripheral participation)는 세 단어로 나뉩니다.

여기서 결정적인 건 주변의 일이 '평범한 일'이라는 점입니다. 단추 달기는 재단의 예술성과 거리가 멉니다. 하지만 그 일이 없으면 견습생이 공동체 안에 정당하게 머물 자리도 없습니다. 이제 2026년의 소프트웨어 팀을 보죠. 신입에게 맡기던 주변의 일이 무엇이었는지 떠올려 보면 목록이 나옵니다. 작은 버그 수정, 테스트 추가, 문서 정리, 간단한 CRUD 화면, 그리고 글리프가 콕 집은 "지루한 맞춤 워드프레스 테마". 바로 AI 에이전트가 가장 먼저, 가장 잘 가져가는 일들입니다.

나우르(1985)가 말한 "적절한 감독 아래 관련된 일을 직접 하는 것"과 레이브·웽어(1991)의 정당한 주변적 참여, 그리고 콜린스·브라운·뉴먼(1987/1989)의 인지적 견습(시범 → 코칭 → 비계 세우기 → 말로 설명하기 → 성찰 → 탐색)은 모두 같은 그림을 그립니다. 숙련은 일을 하면서, 숙련자 곁에서, 평범한 일부터 쌓인다는 것이죠. 에릭슨의 의도적 연습이 '연습실'의 이론이라면, 이쪽은 '작업장'의 이론입니다. 글리프의 주장은 작업장 쪽에 서 있습니다.

7. 0.1%의 산수: '가끔은 반드시'에서 '절대 없음'으로

이제 글리프의 가장 유명한 문단을 직접 계산해 봅시다.

평범한 프로젝트마다 이를테면 0.1% 정도의 아주 작은 확률로 위대함이 깃든다. 프로젝트 하나를 AI로 한다면, 그래, 아무래도 좋다. 그 프로젝트가 엔지니어의 경력을 정의할 단 한 번이었을 확률은 거의 없다. 하지만 모든 프로젝트를 그렇게 하는 습관을 들이면, 위대한 순간의 총 확률을 '가끔은 반드시'에서 '절대 없음'으로 바꾸게 된다.

크게 보기

수학은 간단합니다. 각 프로젝트가 독립적으로 확률 p로 '위대한 순간'을 낳는다면, 프로젝트 N개 중 적어도 한 번 그 순간을 만날 확률은 다음과 같습니다.

$P(\text{적어도 한 번}) = 1 - (1-p)^{N}$

p = 0.1%일 때 숫자를 넣어 보면 이렇습니다.

개인에게는 "언젠가 한 번쯤"이 업계 전체에서는 "해마다 반드시 몇 명"이 됩니다. 프로그래머 수만 명이 각자 수백 개의 평범한 프로젝트를 하면, 그중 어딘가에서는 해마다 Deferred 같은 것이 태어납니다. 이게 글리프가 말한 "가끔은 반드시(definitely sometimes)"입니다. 그리고 마지막 줄이 핵심입니다. 위임한 프로젝트의 확률이 0이라면, 위임 비율이 100%가 되는 순간 그 합은 0입니다.

아래 시뮬레이터에는 두 가지 모델이 있습니다. 운 모델은 글리프의 문장을 그대로 옮긴 것이고, 실력 모델은 앞 절의 견습 이론을 반영해 손으로 한 프로젝트가 쌓일수록 다음 프로젝트의 확률이 커지게 했습니다. 실력 모델에서는 위임의 효과가 두 번 작용합니다. 시도 횟수가 줄고, 시도당 확률도 덜 자랍니다. 마지막 슬라이더는 반론을 넣어 보는 장치입니다. "AI와 함께 한 프로젝트에서도 위대함은 나올 수 있다"고 믿는다면 올려 보세요.

기본값(1년 12개, 20년, 0.1%)에서 전부 직접 하면 1,000명 중 약 213명이 경력에서 한 번 이상 그 순간을 만납니다. 80%를 맡기면 약 47명으로 줄어듭니다. 실력 모델로 바꾸면 격차는 더 벌어집니다. 물론 이건 장난감 모델입니다. 0.1%라는 숫자 자체가 글리프가 "이를테면"이라고 든 가정이고, 현실의 위대함은 독립 시행도 아닙니다. 하지만 이 산수가 보여 주는 구조, 곧 아주 작은 확률 × 아주 많은 평범한 시도 = 확실한 위대함이라는 구조는 진화와 과학적 발견과 창업이 공유하는 구조이기도 합니다. 그 '아주 많은 평범한 시도'를 줄이는 건 어느 영역에서든 같은 결과를 낳습니다.

8. 증거 ① 자동화의 아이러니: 1983년의 예언과 2026년의 실험

글리프의 글은 에세이라서 논문을 인용하지 않습니다. 하지만 그가 말한 "평범한 일을 없애면 숙련이 사라진다"는 주장은 40년 넘게 연구돼 온 주제입니다. 출발점은 1983년의 네 쪽짜리 논문입니다.

8-1. 베인브리지(1983): 가장 성공한 자동화가 가장 많은 훈련을 필요로 한다

영국의 인지심리학자 리산 베인브리지는 1983년 『오토마티카』에 「자동화의 아이러니(Ironies of Automation)」를 발표했습니다. 대상은 발전소와 화학 공장, 항공기 조종석이었습니다. 이 짧은 논문은 지금까지 수천 번 인용되며 인간공학의 고전이 됐습니다. 아이러니는 여러 겹입니다.

세 번째 아이러니를 2026년의 소프트웨어 팀에 그대로 옮겨 보세요. "현 세대 AI 코딩 시스템은 예전에 손으로 코드를 짜던 시니어들이 감독하고 있다. 그들은 자기 기술에 기대고 있지만, 다음 세대 개발자가 그 기술을 가지리라 기대할 수는 없다." 글리프가 걱정하는 미래가 43년 전 화학 공장 이야기 속에 이미 있었습니다. 네 번째 아이러니도 정확히 들어맞습니다. AI가 쉬운 코드를 가져가면 사람에게는 디버깅과 설계와 예외 처리, 곧 가장 어려운 일만 남습니다. 그런데 그 어려운 일을 해낼 감각은 쉬운 일을 수없이 하면서 생기는 것이었습니다.

8-2. 의학이 먼저 겪었다: 내시경 의사의 선종 발견율

이 아이러니가 실제로 측정된 가장 생생한 사례는 의학에서 나왔습니다. 2025년 8월 『랜싯 위장병·간장학』에 실린 부지인 등의 연구입니다. 폴란드 네 개 센터에서 대장 내시경 경력 2,000건 이상인 숙련 내시경 의사 19명을 관찰했습니다. 이 센터들은 2021년 말부터 AI 보조 용종 탐지 시스템을 도입했는데, 연구진은 AI 없이 한 내시경의 성적이 도입 전후로 어떻게 바뀌었는지 봤습니다.

선종(대장암의 전 단계 용종) 발견율이 28.4%에서 22.4%로, 절대치로 6%포인트(상대치로 약 20%) 떨어졌습니다. 몇 달 동안 AI가 "여기 용종이 있다"고 알려 주는 데 익숙해진 숙련 의사들이 AI가 꺼진 날에는 눈에 띄게 덜 찾아낸 겁니다. 관찰 연구라 인과를 단정할 수 없고, 이후 학술지에 비판 서한과 저자 답변이 오갔습니다. 하지만 의학계는 이미 이 현상에 이름을 붙였습니다. 이미 가진 기술을 잃는 탈숙련(deskilling), 처음부터 기술을 갖추지 못하는 무숙련(never-skilling), 잘못된 기술을 익히는 오숙련(mis-skilling). 2025년 『뉴잉글랜드 의학 저널』의 교육 전략 논문이 이 세 단어를 정리했습니다. 글리프가 걱정하는 건 두 번째, never-skilling입니다.

8-3. 지식 노동자 319명과 뇌파: 생각을 덜 하게 되는가

2025년 CHI 학회에서 마이크로소프트 연구소와 카네기멜런 대학의 리 등은 지식 노동자 319명이 실제 업무에서 생성형 AI를 쓴 사례 936건을 분석했습니다. 결과는 한 줄로 요약됩니다. AI를 믿을수록 비판적 사고를 덜 하고, 자기 능력을 믿을수록 더 한다. 사람들의 비판적 사고는 사라지는 대신 정보 검증, 응답 통합, '과제 관리'로 옮겨 갔습니다. 흥미롭게도 이 논문은 베인브리지를 직접 인용합니다. "일상 과제를 기계화하고 예외 처리만 사람에게 남기면, 사용자는 판단력을 연습할 일상적 기회를 빼앗기고, 그 결과 예외가 정작 닥쳤을 때 위축되고 준비되지 않은 상태가 된다."

같은 해 MIT 미디어랩의 코스미나 등은 「ChatGPT를 쓸 때 당신의 뇌」라는 도발적인 제목의 프리프린트를 냈습니다. 54명이 넉 달 동안 에세이를 쓰며 뇌파(EEG)를 측정했습니다. LLM 그룹은 뇌 영역 간 연결성이 가장 약했고, 첫 세션에서 18명 중 15명(83%)이 방금 자기가 쓴 에세이의 문장을 정확히 인용하지 못했습니다(다른 그룹은 18명 중 2명). 연구진은 이것을 인지 부채(cognitive debt)라고 불렀습니다. 다만 표본이 작고 아직 동료 심사를 거치지 않았으며, 2025년 말 방법론을 비판하는 반박 논문도 나왔다는 점을 함께 기억해야 합니다.

8-4. Anthropic의 실험: 52명, 처음 보는 라이브러리, 17%포인트

글리프의 주장을 가장 직접적으로 시험한 연구는 2026년 1월 Anthropic의 연구진(주디 한원 선, 알렉스 탐킨)이 낸 「AI가 기술 형성에 미치는 영향」입니다. 이 연구가 중요한 이유는 AI를 만드는 회사가 자기 도구의 부작용을 무작위 실험으로 측정했다는 점입니다.

크게 보기

출처: Judy Hanwen Shen·Alex Tamkin, 「How AI Impacts Skill Formation」, arXiv 2601.20245 (2026), 그림 1.

그림 1을 읽는 법입니다. 왼쪽 두 그래프의 점은 평균, 세로 막대는 95% 신뢰구간입니다. 과제 시간(왼쪽)은 AI 그룹이 약 23분, 손 그룹이 약 24.7분으로 AI가 조금 빠르지만 막대가 크게 겹칩니다(p=0.391, 우연으로 설명 가능). 퀴즈 점수(가운데)는 막대가 거의 겹치지 않습니다(p=0.010). 요약하면 AI는 시간을 거의 아껴 주지 못했는데 배움은 크게 깎았습니다. 왜 시간이 줄지 않았을까요. 일부 참가자는 질문을 15개까지 쓰며 전체 시간의 30%(최대 11분)를 AI에게 말을 거는 데 썼습니다.

손 그룹은 오류를 훨씬 많이 만났습니다. 연구진은 바로 그 오류를 스스로 해결하는 과정이 디버깅 실력을 만들었다고 봅니다. 콜백 천 개를 손으로 넘기던 글리프의 지겨움이 Deferred의 재료였듯, 오류를 만나는 지겨움이 디버깅 감각의 재료였던 겁니다.

그림 1의 오른쪽, 그리고 논문의 그림 11이 이 연구의 가장 흥미로운 부분입니다. 연구진은 AI 그룹의 화면 녹화를 하나하나 보며 사람들이 AI를 쓰는 방식을 여섯 가지로 분류했습니다.

크게 보기

출처: 같은 논문, 그림 11.

이 표가 글리프 논증의 가장 정교한 버전입니다. 위의 세 패턴과 아래 세 패턴의 차이는 AI를 썼느냐가 아니라 이해하는 일을 자기가 했느냐입니다. 특히 '생성 후 이해'(86%)와 'AI 위임'(39%)은 겉보기에 거의 똑같습니다. 둘 다 코드를 통째로 받았습니다. 차이는 받은 뒤에 "이게 왜 이렇게 되지?"를 한 번 더 물었느냐 하나뿐입니다. 글리프의 언어로 하면 앞쪽은 AI로 "이해를 더 높은 층으로 끌어올린" 경우이고, 뒤쪽은 "이해를 없애 버린" 경우입니다.

가장 뼈아픈 건 '개념 질문' 패턴입니다. 점수가 높았을 뿐 아니라 전체에서 두 번째로 빨랐습니다. 오류를 스스로 고치는 게 느릴 것 같지만, AI에게 디버깅을 맡기며 15번씩 묻는 것보다 빨랐습니다. 직접 그 습관을 찾아보세요.

이 연구에는 분명한 한계가 있습니다. 표본이 52명이고, 패턴 분석은 인과가 아니라 관찰이며(패턴별 인원은 2~7명), 퀴즈는 과제 직후에 봤고, 도구는 사이드바 채팅(GPT-4o)이었습니다. 연구진은 각주에 Claude Code 같은 에이전트형 도구에서는 이 효과가 "더 뚜렷할 것"이라고 적었습니다. 에이전트는 사람에게 묻지도 않고 끝까지 해 버리니까요.

8-5. METR: 실험이 불가능해졌다는 것 자체가 결과다

AI가 숙련 개발자를 실제로 얼마나 빠르게 하는지 측정한 가장 유명한 실험은 METR의 2025년 7월 연구입니다. 자기 저장소에서 평균 5년을 일한 오픈소스 개발자 16명이 실제 과제 246개를 AI 있이/없이 무작위로 나눠 처리했습니다. 개발자들은 AI가 시간을 24% 줄여 줄 거라 예상했고, 끝난 뒤에도 20% 빨라졌다고 믿었습니다. 실제로는 19% 느려졌습니다. 경제학자들(39% 단축 예상)과 머신러닝 연구자들(38%)의 예측도 모두 틀렸습니다.

METR은 2025년 8월부터 개발자 57명, 과제 800여 개로 후속 실험을 했고 2026년 2월 결과를 공개했습니다. 이번에는 기존 참가자 기준 시간이 18% 줄었다는 추정이 나왔지만, METR은 스스로 이 데이터를 "신뢰할 수 없는 신호"라고 불렀습니다. 이유가 놀랍습니다.

이 사건은 어떤 수치보다 글리프의 걱정을 잘 보여 줍니다. 숙련 개발자에게도 걸어서 도시를 가로지르는 일이 견딜 수 없게 됐다면, 처음부터 걸어 본 적 없는 사람에게는 어떨까요.

9. 증거 ② 사라지는 아랫단: 숫자로 본 견습 사다리

평범한 일이 연습장이라면, 그 연습장이 실제로 줄고 있을까요. 2025~2026년의 노동 시장 데이터는 "그렇다"고 말합니다. 다만 원인이 오직 AI인지는 조심스럽게 읽어야 합니다.

크게 보기

9-1. 미국: 탄광 속 카나리아

스탠퍼드의 브리뇰프슨·찬다르·첸은 미국 최대 급여 처리 회사 ADP의 데이터로 「탄광 속 카나리아」 보고서를 냈습니다. 2025년 8월 첫 버전에서 가장 많이 인용된 숫자는 22~25세 소프트웨어 개발자 고용이 2022년 말 정점 대비 20% 가까이 줄었다는 것이었습니다. 2026년 8월 업데이트(2026년 6월 데이터까지)는 이렇게 정리합니다.

마지막 두 줄이 중요합니다. 젊은 층은 해고되는 게 아니라 애초에 뽑히지 않고 있습니다. 그리고 그 효과는 AI가 사람의 일을 대신하는 곳에 몰립니다. 연구진은 교육 수준을 통제하면 효과가 약해지고 일부 추세는 생성형 AI 이전부터 있었다며, 이 결과가 인과가 아니라 기술(記述)이라고 강조합니다.

벤처캐피털 시그널파이어의 인재 보고서도 같은 방향입니다. 2025년판에서 빅테크의 신입 채용은 2019년 대비 50% 넘게 줄었고, 2026년판에서는 12개 대형 기술 기업의 신입·초급 채용이 2019년 대비 약 65%, 초기 스타트업에서는 약 76% 줄었습니다(전 직군 합산).

9-2. 한국: '연공 편향 기술 변화'

한국은행은 이 현상에 이름을 붙였습니다. 2025년 10월 보고서 「AI 확산과 청년고용 위축」은 국민연금 가입 자료를 분석해, 2022년 7월부터 2025년 7월까지 줄어든 청년(15~29세) 일자리 21만 1천 개 중 20만 8천 개(98.6%)가 AI 노출도가 높은 업종에서 나왔다고 밝혔습니다. 같은 기간 50대 일자리는 20만 9천 개 늘었습니다. 젊은 층의 자리가 사라지는 동안 경력자의 자리는 늘었다는 뜻입니다. 보고서는 이를 연공 편향 기술 변화(seniority-biased technical change)라고 불렀습니다.

2026년 8월 후속 보고서 「청년고용 위축, AI 탓인가? 변화하는 경력 사다리와 대응과제」는 4년간 줄어든 청년 일자리 28만 5천 개 중 26만 8천 개(94%)가 AI 고노출 업종이었다고 보고했습니다. 업종별 청년 고용 감소는 정보서비스업 −31.4%, 출판업 −27.4%, 컴퓨터 프로그래밍업 −16.6%였습니다. 한국은행도 이를 AI의 직접적 인과로 단정하지 말라고 덧붙였습니다. 같은 날 발표된 한국경제인협회 설문에서는 청년의 53.9%가 5년 안에 자기 일이 AI로 대체되거나 줄어들 거라고 답했습니다.

한국은행(2026.8) 업종별 청년 고용 감소율. 막대 길이는 최대 감소율(31.4%) 대비 비율.

이 숫자들을 글리프의 언어로 번역하면 이렇습니다. 출판(카피라이팅과 편집), 정보서비스(웹 콘텐츠와 디자인), 프로그래밍(맞춤 웹사이트와 앱). 글리프가 지키자고 한 바로 그 '평범한 일'이 있던 업종에서 청년의 자리가 가장 많이 사라졌습니다.

9-3. 시간 지연: 왜 지금은 괜찮아 보이는가

이 문제가 무서운 건 지연이 있기 때문입니다. 시니어는 평균 십수 년을 업계에 머물고, 그 자리를 채울 사람들은 이미 사다리 중간에 있습니다. 그래서 주니어 채용이 끊겨도 시니어 숫자는 몇 년 동안 멀쩡해 보입니다. 이 블로그의 「부러진 사다리」 글에서 다뤘듯 LeadDev 조사에서 엔지니어링 리더의 54%가 2026년 주니어 채용을 줄이겠다고 답했습니다. 아래 시뮬레이터로 그 지연을 직접 확인해 보세요. 슬라이더를 움직여도 시니어 곡선은 한참 동안 꿈쩍하지 않다가 2030년대에 꺾입니다.

베인브리지의 세 번째 아이러니가 노동 시장 규모로 재현되는 모습입니다. 지금의 AI 코딩 시스템은 손으로 일하던 세대가 감독합니다. 그 세대가 은퇴할 즈음, 감독할 다음 세대는 어디서 올까요.

10. 추상화인가, 대체인가: 이 논쟁의 진짜 경계선

글리프의 글에서 가장 많이 오해받는 부분이 있습니다. 그는 자동화에 반대하지 않습니다. 오히려 이렇게 씁니다. "프로그래밍은 추상화의 예술이다." 컴파일러가 어셈블리를 대신 써 주고, 라이브러리가 소켓 처리를 대신해 주고, Deferred가 콜백 관리를 대신해 줍니다. 그는 평생 추상화를 만들어 온 사람입니다.

그가 긋는 선은 다른 데 있습니다.

크게 보기

해커뉴스의 archagon은 이 구분을 날카롭게 요약했습니다. "자연어와 코드 사이에 재현 가능하고 결정적인 대응이 있다면, 그건 그냥 프로그래밍 언어라고 부른다." 즉 AI가 컴파일러처럼 결정적이라면 그건 새로운 추상화이고 환영할 일이지만, 지금의 AI는 그렇지 않다는 겁니다.

그런데 8장의 Anthropic 실험은 이 경계가 도구에 있지 않고 쓰는 방식에 있다는 걸 보여 줍니다. 같은 AI를 쓰고도 '생성 후 이해' 패턴은 이해를 끌어올렸고(86%), 'AI 위임' 패턴은 이해를 지웠습니다(39%). 같은 맥락에서 2025년 '바이브 코딩'이라는 말을 만든 안드레이 카파시도 2026년 2월에는 그 말이 이제 낡았다며 '에이전틱 엔지니어링'을 제안했습니다. "99%의 시간 동안 코드를 직접 쓰지 않으므로 '에이전틱'이고, 거기에 예술과 과학과 전문성이 있다는 걸 강조하려고 '엔지니어링'이다." 사이먼 윌리슨도 비즈니스 인사이더에 "코딩 에이전트를 잘 쓰는 건 깊은 기술"이라고 말했습니다.

이 말들은 글리프에 대한 반박처럼 들리지만, 사실 그의 논증을 한 번 더 확인해 줍니다. 에이전트를 잘 쓰는 "깊은 기술"은 어디서 왔을까요. 카파시와 윌리슨은 각각 20년 넘게 손으로 코드를 쓴 사람들입니다. 그들의 판단력은 바로 그 평범한 일의 산물입니다. 그 판단력을 가진 사람이 AI를 쓰면 이해가 위로 올라가고, 판단력이 아직 없는 사람이 같은 방식으로 쓰면 이해가 지워집니다. 글리프의 질문은 결국 이것입니다. 다음 세대의 카파시와 윌리슨은 어디서 판단력을 기를 것인가.

여기 래리 월의 아이러니도 있습니다. 펄의 창시자는 프로그래머의 첫째 미덕으로 게으름을 꼽았습니다. "전체 에너지 소모를 줄이기 위해 엄청난 노력을 기울이게 만드는 성질." 해커 문화는 원래 지루함을 자동화하는 문화였습니다. 그런데 그 게으름은 지루함을 겪어 본 사람의 게으름이었습니다. 월의 게으름도, 글리프의 Deferred도, 지루함을 정확히 아는 사람이 그것을 없앨 구조를 만든 것입니다. 지루함을 처음부터 겪지 않은 사람의 게으름은 다른 것입니다. 그건 구조를 만들지 않고 결과만 받습니다.

11. 반론 지도: 300개의 댓글은 무엇을 두고 싸웠나

해커뉴스, 로브스터스, 마스토돈, 블루스카이에 달린 300여 개의 반응을 읽으면 논쟁이 일곱 갈래로 나뉩니다. 흥미로운 건 가장 많이 나온 반론("코드는 예술이 아니라 공예다")이 글리프의 결론에 가장 덜 위협적이라는 점입니다. 로브스터스에서 가장 많은 추천을 받은 kornel의 댓글이 대표적입니다. "물감으로 예술 작품을 만들 수 있지만, 세상 물감 대부분은 방수 도장에 쓰인다." 그런데 글리프는 이미 "대부분의 코드는 카피라이팅"이라고 인정했습니다. 그의 논점은 방수 도장을 하던 사람이 언젠가 그림을 그리게 된다는 것이었죠. 마스토돈에서 글리프는 짧게 답했습니다. "예술이냐 아니냐의 축은 사실 좋으냐 나쁘냐의 축과 독립적이다."

이 지도에서 이 글이 가장 무겁게 보는 반론은 두 가지입니다.

첫째, 추상화 반론. 앞 장에서 봤듯 AI를 쓰는 방식에 따라 이해를 끌어올리는 도구도 될 수 있습니다. 글리프의 "저항하라"는 결론은 이 가능성을 충분히 다루지 않습니다. 그는 "얼마나, 어떤 쓰임에 저항할지는 당신 몫"이라며 여지를 남겼지만, 독자 상당수는 이 글을 전면 거부로 읽었습니다.

둘째, 데이터의 엇갈림. 글리프는 스택오버플로 설문을 "그래도 쓰고 있다"의 근거로 링크했지만, 같은 설문에서 AI에 대한 호감은 오히려 60%에서 62%로 올랐습니다. 불행하다는 응답도 늘었지만(28.6%→32.6%), 그 둘이 같은 사람인지는 설문이 말해 주지 않습니다. 다만 같은 설문에는 글리프에게 유리한 숫자도 숨어 있습니다. 직장이나 학교에서 AI를 피하는 이유를 물었더니 1위가 "직무 기술을 잃거나, 나를 대체할 AI를 훈련시키게 될까 봐"(17.1%)였습니다. 개발자들 자신도 이 걱정을 하고 있다는 뜻입니다.

반대로 글리프 편에서 원문보다 한 걸음 더 나간 반응도 있었습니다. 블루스카이의 한 사용자는 이렇게 썼습니다. 아무도 Deferred 같은 새 아이디어를 쓰지 않으면 AI의 학습 데이터에도 들어가지 못하고, 그러면 퍼지지도 못한다. "AI가 이미 쓰는 것을 수동적으로 개선하는 방식이 아니면 개선은 멈춘다." 이건 이 블로그의 「왜 Common Lisp가 이제 최고의 언어인가」 특집에서 다룬 문제, 곧 학습 데이터의 관성이 언어와 라이브러리의 진화를 묶는 문제와 정확히 이어집니다. 민속 서사시는 사람이 이어 불러야 다음 연이 생깁니다. 모두가 같은 기계에게 같은 노래를 부르게 하면 서사시는 거기서 멈춥니다.

12. 역사의 거울: 기계 앞에 섰던 장인들은 어떻게 됐나

"새 기술에 저항한 장인들"의 역사는 길고, 결말은 한 가지가 아닙니다. 글리프의 주장을 역사에 비춰 보면 무엇이 보일까요.

이 역사가 주는 교훈은 단순하지 않습니다.

1. 저항한다고 기술이 멈추지는 않았다. 러다이트도, 음악가연맹도 결국 졌습니다. 글리프 비판자들의 말("물결을 막을 수는 없다")에는 역사적 근거가 있습니다.
2. 하지만 저항은 조건을 바꿨다. 러다이트 이후 영국 노동 운동의 언어가 생겼고, 음악가연맹은 그 뒤 녹음 사용료 협약을 따냈고, 미국작가조합은 2023년 148일 파업 끝에 "AI는 작가가 아니고, AI 결과물은 원작이 아니며, 회사는 작가에게 AI 사용을 강요할 수 없다"는 조항을 얻었습니다. 저항의 목표는 기술을 없애는 게 아니라 기술이 들어오는 조건을 정하는 것이었습니다.
3. 매체가 바뀐 곳에서 새 예술이 났다. 사진은 인상주의를, 드럼 머신은 힙합을 낳았습니다. 이 낙관의 조건은 그 새 매체를 깊이 다룰 줄 아는 사람이 있어야 한다는 것입니다. 힙합 프로듀서는 드럼 머신을 수천 시간 만졌습니다.
4. 사라진 건 언제나 '평범한 일'이었다. 극장 반주자, 세션 드러머, 손 직조공. 정상급 연주자와 화가는 살아남았습니다. 사라진 건 그 정상으로 가는 길의 아랫단이었습니다. 글리프가 지키자고 한 것이 정확히 이 아랫단입니다.

그러니 역사는 글리프에게 절반만 손을 들어 줍니다. 저항이 기술을 막지는 못하지만, 저항하지 않으면 조건은 기술을 가진 쪽이 정합니다. 글리프가 마스토돈에 쓴 말이 이 대목에 닿아 있습니다. "우리 업계는 너무 빨리, 너무 강해졌다. 그 힘에 걸맞은 직업으로서의 힘을 만드는 단계를 건너뛰었다… 사람들에게 유명한 소프트웨어 엔지니어 이름을 대 보라고 하면 경영자 이름을 댄다." 작가에게는 조합이, 음악가에게는 연맹이 있었습니다. 프로그래머에게는 무엇이 있을까요.

13. 2026년, 이 글이 서 있는 자리

2026년 10월의 풍경을 정리하면 이렇습니다.

생산성 쪽 증거도 분명히 있습니다. 2023년 펭 등의 실험에서는 코파일럿을 쓴 개발자 95명이 HTTP 서버를 55.8% 빨리 만들었고, 마이크로소프트·액센추어·포천 100대 기업의 개발자 4,867명을 대상으로 한 쿠이 등의 현장 실험에서는 완료한 과제가 26% 늘었습니다. 특히 경력이 짧은 개발자일수록 더 많이 쓰고 더 많은 이득을 봤습니다. 그리고 바로 그 지점에서 글리프의 걱정과 정면으로 만납니다. 주니어가 가장 큰 생산성 이득을 보는 도구가 동시에 주니어의 학습을 가장 크게 깎을 수 있다는 것. Anthropic 실험의 'AI 위임' 패턴(가장 빠르고, 39%)이 그 모습이었습니다.

그래서 2026년에 이 글이 갖는 의미는 "AI를 쓰지 말라"보다 정확한 질문을 던졌다는 데 있다고 봅니다. 이 일은 내 일 중 어느 부분인가? 이미 백 번 해 본 일을 맡기는 것과, 아직 한 번도 제대로 해 보지 않은 일을 맡기는 것은 같은 '위임'이 아닙니다. 앞의 것은 추상화이고, 뒤의 것은 연습장을 지우는 일입니다. 같은 도구, 같은 버튼인데 쓰는 사람의 이력에 따라 의미가 정반대가 됩니다.

14. 실천 체크리스트: 평범한 것을 지키는 방법

글리프는 "구체적 방법은 이 짧은 글의 여백을 훌쩍 넘는다"며 각자에게 맡겼습니다. 여기서는 이 특집에서 본 연구들을 바탕으로 그 여백을 조금 채워 봅니다.

15. 맺으며: 시는 지겨움에서 태어났다

글리프는 10대 후반에 자신을 코드 시인이라고 불렀다가 놀림받고 그 말을 지웠습니다. 그리고 몇 해 뒤, 원격 호출마다 콜백 두 개를 넘기는 일이 너무 지겨워서, 그 지겨움을 없앨 작은 객체 하나를 만들었습니다. 그는 그걸 시라고 부르지 않았습니다. 그냥 Deferred라고 불렀습니다. 그 작은 객체는 25년 동안 MochiKit과 Dojo와 jQuery와 Promises/A+를 거쳐, 지금 이 글을 읽는 브라우저 안의 async/await가 됐습니다. 원본은 거의 녹아 없어졌습니다. 민속 서사시는 원래 그렇습니다.

이 이야기에서 가장 중요한 단어는 '시'가 아니라 '지겨움'입니다. 지겨움을 겪은 사람만이 지겨움의 정확한 모양을 알고, 그 모양을 알아야 그것을 없앨 아름다운 구조를 설계할 수 있습니다. 크누스는 "일상적인 과제를 위한, 쓰는 즐거움이 있는 도구"를 달라고 했고, 래리 월은 게으름을 미덕이라 불렀고, 나우르는 이론이 함께 일하며 전해진다고 했고, 레이브와 웽어는 견습생이 단추부터 단다고 했습니다. 모두 같은 말입니다. 평범한 일은 위대한 일의 재료다.

그래서 "프로그래밍은 특별하지 않다"는 제목은 겸손하게 들리지만 사실은 꽤 대담한 요구입니다. 프로그래머가 지금까지 스스로 포기해 온 것, 곧 자기 일이 창작이라는 인식과 그 창작의 연습장을 지킬 권리를 화가와 작가와 음악가와 똑같이 요구하라는 것이니까요. 해커뉴스의 누군가는 이 글을 신고했고, 다른 누군가는 "왜 이 글이 신고됐냐"고 물었습니다. 아마 둘 다 이 글을 제대로 읽은 사람들이었을 겁니다.

마지막 판단은 글리프의 말대로 각자의 몫입니다. 다만 다음에 AI에게 "이거 통째로 짜 줘"라고 쓰기 전에 한 번만 물어보세요. 이건 내가 이미 백 번 해 본 일인가, 아니면 아직 한 번도 제대로 해 보지 않은 일인가. 앞의 것이라면 그건 추상화입니다. 뒤의 것이라면, 어쩌면 그 안에 당신의 0.1%가 있었을지도 모릅니다.

프로그래밍은 특별하지 않다. 그건 그냥 예술이고, 예술은 가장 인간적인, 그래서 가장 보편적인 것이다. — 글리프, 2026년 10월 9일

함께 읽으면 좋은 글

• 부러진 사다리 — 오늘 주니어를 안 뽑으면, 2031년엔 시니어가 없다
• [특집] AI 때문에 두 번째 뇌를 만들었다 — '이해를 위임하지 마라'의 역사, 과학, 그리고 2026년
• 코드를 보지 마라, 아이디어를 잡아라 — antirez가 던진 불편한 질문
• 코드를 쓰는 시간이 사라지면 무엇이 남나 — 「왜 Common Lisp가 이제 최고의 언어인가」 특집
• [특집] AI가 코드를 쓸수록 설계가 중요해진다
• 바이브코딩 특집: 30분 만에 환자 데이터가 열린 이유

참고 자료

원문과 반응

• Glyph Lefkowitz, "Programming Isn't Special," Deciphering Glyph, 2026-10-09. blog.glyph.im
• Hacker News 토론 (182점, 댓글 202개). news.ycombinator.com/item?id=50017357
• Lobsters 토론 (65점, 댓글 36개). lobste.rs/s/ily7as
• Glyph, "Generalization of Deferred Execution in Python," PyCon 2003. Wayback
• Glyph, "What Is Code Review For?" (2026-03-03), "I Think I'm Done Thinking About genAI For Now" (2025-06-04), "The Futzing Fraction" (2025-08-15). blog.glyph.im
• Twisted Documentation, "Deferred Reference" (구조도 출처, MIT License). docs.twisted.org

예술·장인·신비화

• John Berger, Ways of Seeing, BBC/Penguin, 1972, ch. 1. ways-of-seeing.com
• Walter Benjamin, "The Work of Art in the Age of Mechanical Reproduction," 1935/1936.
• Nate Hopper, "Six Authors Who Were Copywriters First," The Awl, 2011-08-18. theawl.com
• Donald E. Knuth, "Computer Programming as an Art," CACM 17(12):667–673, 1974. doi:10.1145/361604.361612
• Donald E. Knuth, "Literate Programming," The Computer Journal 27(2):97–111, 1984.
• Harold Abelson, Gerald Jay Sussman, Julie Sussman, Structure and Interpretation of Computer Programs, MIT Press, 1984/85, Preface.
• Peter Naur, "Programming as Theory Building," Microprocessing and Microprogramming 15(5):253–261, 1985.
• Frederick P. Brooks Jr., The Mythical Man-Month, 1975, ch. 1.
• Paul Graham, "Hackers and Painters," 2003. paulgraham.com
• Manifesto for Software Craftsmanship, 2009. manifesto.softwarecraftsmanship.org
• Richard Sennett, The Craftsman, Yale University Press, 2008.

연습과 견습

• K. A. Ericsson, R. T. Krampe, C. Tesch-Römer, "The Role of Deliberate Practice in the Acquisition of Expert Performance," Psychological Review 100(3):363–406, 1993.
• B. N. Macnamara, D. Z. Hambrick, F. L. Oswald, "Deliberate Practice and Performance in Music, Games, Sports, Education, and Professions: A Meta-Analysis," Psychological Science 25(8), 2014.
• Jean Lave, Etienne Wenger, Situated Learning: Legitimate Peripheral Participation, Cambridge University Press, 1991.
• A. Collins, J. S. Brown, S. E. Newman, "Cognitive Apprenticeship," 1989.
• Eric Alper, "What the Beatles Can Teach You About 10,000 Hours in Hamburg," 2026-08-13. thatericalper.com

자동화와 기술 형성

• Lisanne Bainbridge, "Ironies of Automation," Automatica 19(6):775–779, 1983.
• Judy Hanwen Shen, Alex Tamkin, "How AI Impacts Skill Formation," arXiv:2601.20245, 2026. arxiv.org / Anthropic 블로그
• J. Becker et al., "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," arXiv:2507.09089, 2025.
• METR, "We are Changing our Developer Productivity Experiment Design," 2026-02-24. metr.org
• H.-P. Lee et al., "The Impact of Generative AI on Critical Thinking," CHI 2025. doi:10.1145/3706598.3713778
• N. Kosmyna et al., "Your Brain on ChatGPT," arXiv:2506.08872, 2025.
• K. Budzyń et al., "Endoscopist deskilling risk after exposure to artificial intelligence in colonoscopy," Lancet Gastroenterol Hepatol 10(10):896–903, 2025.
• S. Peng et al., "The Impact of AI on Developer Productivity," arXiv:2302.06590, 2023.
• Z. Cui et al., "The Effects of Generative AI on High-Skilled Work," Management Science, 2025.

노동 시장과 설문

• E. Brynjolfsson, B. Chandar, R. Chen, "Canaries in the Coal Mine?" Stanford Digital Economy Lab, 2025 (2026-08 업데이트).
• SignalFire, State of Talent Report 2025, 2026.
• 한국은행, 「AI 확산과 청년고용 위축」, 2025.10. / 「청년고용 위축, AI 탓인가? 변화하는 경력 사다리와 대응과제」, 2026.8.
• Stack Overflow, 2026 Developer Survey, 2026-10-06. survey.stackoverflow.co/2026
• Thibault Spirlet, "Developers are burned out, disengaged, and facing an AI-powered reset," Business Insider, 2026-10-06.
• JetBrains, State of Developer Ecosystem 2026.
• Google Cloud, DORA State of AI-assisted Software Development, 2025.

역사

• Richard Conniff, "What the Luddites Really Fought Against," Smithsonian, 2011.
• Brian Merchant, Blood in the Machine, Little, Brown, 2023.
• Matt Novak, "Musicians Wage War Against Evil Robots," Smithsonian, 2012.
• Harry Braverman, Labor and Monopoly Capital, Monthly Review Press, 1974.
• Writers Guild of America, "Artificial Intelligence" (2023 MBA). wga.org