2026년 9월 11일, 영국의 한 개발자가 9분짜리 영상을 올렸다. 코드는 한 줄도 나오지 않는 영상이었다. 그는 AI가 슬프다고 말했고, 그 슬픔의 이름을 '무시당함'이라고 붙였다. 해커뉴스 282개, Lobsters 67개의 댓글이 달렸다. 이 특집은 그 글을 끝까지 읽고, 왜 이 감정이 지금 터졌는지를 장인과 탈숙련의 역사에서 찾고, 'AI가 코딩한다'는 문장을 트랜스포머부터 에이전트 하네스까지 분해하고, 2026년의 실측 데이터로 그 문장의 진위를 따진다. 인터랙티브 실험 4종과 논문 원본 그림을 함께 싣는다.
2026년 9월 11일, 영국의 소프트웨어 개발자 앤디 발람(Andy Balaam)이 자기 블로그에 짧은 영상을 하나 올렸다. 그는 평소 러스트(Rust) 프로그래밍 영상을 만들던 사람이다. 그런데 이 영상의 첫 문장은 이랬다.
"이 영상에는 코드가 하나도 없습니다. 건너뛰셔도 괜찮아요."
그리고 이렇게 덧붙였다. 이 영상은 AI의 윤리에 대한 것도 아니고(그 이야기는 따로 썼다), AI가 "제대로 작동하는지"에 대한 것도 아니라고. 그저 자기가 어떤 기분인지, 왜 그런 기분인지, 그리고 거기서 찾은 약간의 희망에 대한 것이라고.
제목은 「Feeling sad about AI」, 우리말로 옮기면 "AI가 슬프다" 정도가 된다.
하루도 지나지 않아 이 글은 해커뉴스에서 172점과 282개의 댓글을, Lobsters에서 168점과 67개의 댓글을 받았다. 파이썬 생태계에서 잘 알려진 사이먼 윌리슨(Simon Willison)은 이 글에 단 자기 댓글을 자기 블로그에 따로 옮겨 실었다. 해커뉴스 모더레이터가 한 댓글 작성자의 안전을 걱정해 공개적으로 말을 건네는 일까지 벌어졌다.
기술 블로그 글 하나가 이 정도로 번지는 일은 드물다. 더 드문 것은, 번진 이유가 기술적 주장이 아니었다는 점이다. 이 글에는 벤치마크도, 코드도, 반박할 만한 수치도 없다. 있는 것은 한 사람의 감정과, 그 감정에 붙인 정확한 이름 하나뿐이었다.
이 특집은 세 가지를 한다. 첫째, 그 글을 처음부터 끝까지 제대로 읽는다. 둘째, 왜 이 감정이 하필 지금 터졌는지를 장인과 탈숙련의 200년 역사에서 찾는다. 셋째, "AI가 코딩한다"는 문장을 기술적으로 분해한다. 트랜스포머가 무엇을 하는지, 자동완성과 에이전트가 어떻게 다른지, 하네스라는 말이 왜 중요한지, 그리고 2026년 현재의 측정값이 실제로 무엇을 말하는지까지.
원문은 길지 않다. 다섯 개의 소제목으로 이루어져 있고, 각 소제목은 말을 건네는 상대로 구분된다. 순서대로 따라가 보자.
첫 소제목은 그냥 Feeling sad, 슬프다는 말이다. 여기서 그는 자기 상태를 설명한다.
"AI는 꽤 오랫동안 저를 슬프게 해 왔습니다. 정말로 슬픕니다. AI가 제 삶에 실제로 끼친 영향에 비하면 지나칠 만큼요. 사실 그 슬픔이 AI가 제 삶에 끼친 가장 큰 영향입니다. 일상을 살아가고, 좋은 배우자·부모·친구·동료가 되는 일이 그것 때문에 더 힘들어졌습니다."
이 대목이 중요하다. 그는 손해의 크기와 감정의 크기가 맞지 않는다는 것을 스스로 인정하면서 시작한다. 직업을 잃은 것도 아니고, 회사가 망한 것도 아니다. 그런데도 슬프다. 그는 이어서 "물론 AI는 제 생계와 경력에 잠재적 위협입니다. 특히 제가 계속 AI 쓰기를 거부한다면요. 하지만 그것만으로는 제가 왜 이렇게까지 슬픈지 설명이 안 됩니다"라고 덧붙인다.
그래서 그는 다음 소제목에서 진짜 이름을 찾아낸다.
"제가 슬픈 건 무시당했기 때문이라고 생각합니다. 저는 평생 프로그래밍을 사랑했습니다. 취미로 삼았고, 직업으로 삼았고, 정체성으로 삼았습니다. 제가 가치 있는 사람이라는 걸 증명하는 방법으로 삼았죠. 제가 뭔가를 잘할 수 있고, 더 잘하게 될 수 있고, 그것이 쓸모 있고 아름답기 때문입니다. 멋진 걸 만들 수 있고, 그것을 공예나 예술이나 과학이나 수학처럼 만들 수 있으니까요.
그리고 그걸 할 줄 알면, 사람들이 당신을 똑똑하다고 여기고 존중해 줍니다."
그다음 문단이 이 글 전체에서 가장 많이 인용된 부분이다.
"그런데 지금 업계의 어떤 사람들은 우리에게 말합니다. 프로그래밍은 한물갔다고, 우리는 공룡이라고, 유일하게 흥미롭거나 살아남을 수 있는 길은 제가 사랑하는 그것에서 벗어나 그들의 기계로부터 프로그래밍을 빌리는 값을 지불하는 것이라고. 이제 그건 상품이니까요.
제가 사랑하는 것. 제 정체성으로 삼은 것. 제가 그토록 간절히 원하는 존중을 벌어다 주던 것."
여기서 핵심 단어는 상품(commodity)이다. 장인이 만들던 것이 공장에서 찍혀 나오는 물건이 되는 순간, 그 물건의 값은 내려가고 만든 사람의 이름은 사라진다. 그가 말하는 무시는 "AI가 나보다 잘한다"는 데서 오는 게 아니다. 내가 잘하는 일이 이제 돈 주고 빌리는 서비스가 되었다는 선언에서 온다.
그리고 그는 곧바로 자기 자신을 찌른다.
"이 영상을 보면서 '당신은 우리가 무시당할 때 어디 있었나요?'라고 생각하는 분들이 많을 겁니다. 농부나 간호사나 운전기사나 부모나 돌봄 노동자나 교사나 서비스업 종사자나 청소 노동자나 세차장 노동자, 그 밖의 수많은 사람의 일에 얼마나 존중이 주어지고 있나요? 압니다. 저는 늦게 왔습니다. 하지만 이제 도착했습니다.
상사들이 저 같은 사람을 그렇게까지 기꺼이 내치고 모조품으로 대체하려 한다는 게 충격이었습니다. 제가 얼마나 순진했고, 얼마나 자기중심적이었는지."
이 자기 비판이 글의 무게를 바꾼다. 개발자만의 특별한 비극이 아니라, 뒤늦게 도착한 사람의 고백이 되기 때문이다.
나머지 세 소제목은 각각 다른 상대에게 하는 말이다.
배우는 사람들에게 하는 말에서 그는 두 가지 근거를 든다. 첫째, 코딩으로 훈련되는 사고방식 자체가 쓸모 있다는 것. 복잡한 시스템을 만들고, 분석하고, 다시 모델링하고, 디버깅하는 훈련은 그 사고가 더 넓은 문제에 적용되는 미래에도 사람을 쓸모 있게 만든다.
둘째가 더 재미있다. 그는 컴파일러를 든다.
"코드가 실제로 어떻게 동작하는지에 대한 지식은 계속 쓸모 있을 겁니다. 컴파일러를 만들었다고 해서 우리가 기계어를 이해하기를 그만뒀나요? 아니죠! 사람들은 컴파일러를 만드는 직업을 갖고 있고, 기계어와 파이프라인과 캐시와 지역성과, 제가 이해하지 못하는 온갖 것들에 대한 그들의 이해는 컴파일러가 발명되던 시절 누구보다도 훨씬 깊습니다."
이 한 문단이 이 글의 기술적 핵심이다. 뒤에서 다시 돌아올 것이다.
마지막으로 그는 자기 아이 둘이 프로그래밍을 배우고 있다는 사실을 밝힌다. 그리고 "업계의 변화에 대해 깊이 슬퍼하면서도, 아이들이 학교와 대학에서 AI를 쓰지 않는 코딩을 배우는 것에 대해 아무 걱정이 없다"고 말한다. 그것이 앞으로 수십 년 어떤 세상이 오든 아이들을 준비시켜 줄 것이라고 확신한다면서.
글은 이렇게 끝난다.
"당신에게 사랑을 보냅니다. 당신은 엄청나게, 엄청나게 큰 가치가 있고, 지금 있는 그대로 존중받을 자격이 있습니다. 코딩을 할 수 있든 다른 무엇을 할 수 있든 그건 상관없습니다. (네, 또 저 자신에게 하는 말입니다.)"
같은 글이 세 곳에서 읽혔고, 세 곳의 반응이 서로 달랐다. 이 차이 자체가 2026년 개발자 사회의 단면도다.
172점, 282개 댓글. 가장 많은 표를 받은 댓글은 동의가 아니라 재구성이었다. 사이먼 윌리슨이 썼다.
"이 말이 얼마나 도움이 될지는 모르겠지만, 많은 사람이(몇 년 전의 저를 포함해서) 이 실존적 위기의 순간을 통과했고 반대편으로 나왔다고 생각합니다.
정확한 명세를 괜찮은 코드로 옮기는 일이 더 이상 특별한 기술이 아니라는 것을 받아들이고 나면, 소프트웨어 엔지니어로서 마주하는 더 큰 문제들을 보게 됩니다. 거기엔 아직 할 일이 정말 많고, 당신의 기존 기술과 경험 덕분에 당신은 이 새 도구들을 통달해서, 그런 깊이 없이 에이전트로 소프트웨어를 만들기 시작한 누구보다 훨씬 높은 수준으로 일할 수 있습니다."
이 댓글에 달린 반박 두 개가 이 논쟁의 축을 만들었다.
첫 번째는 사다리 문제다. 사용자 newdee가 썼다.
"그리고 이제 사다리는 AI 이전 세대 엔지니어들 뒤로 걷어차여 올려졌습니다. 새로 들어오는 사람들의 파이프라인은 어떤 모습인가요? 뒤에 오는 사람들은 AI가 모든 것에 스며든 세상에서 어떻게 그 같은 깊이와 이해에 도달하나요?"
두 번째는 궤적 문제다. HEmanZ가 썼다.
"두려움은 지금에 대한 게 아니라 궤적에 대한 겁니다. 여기서 멈춘다면 모두의 실존적 공포가 증발할 겁니다. 공포는 이겁니다. 이게 어디서 멈추는가? 지금은 AI로 제가 날 수 있습니다. 그런데 AI가 더 이상 저를 필요로 하지 않게 되는 건 언제인가요?"
윌리슨 본인도 자기 위치의 문제를 지적받았다. 한 사용자가 "당신은 AI 컨설팅으로 먹고사는 사람이라 그 말이 저에겐 별로 도움이 안 된다"고 하자, 윌리슨은 "그래서 제가 '이 말이 얼마나 도움이 될지 모르겠다'고 시작한 겁니다. 많은 사람이 이 메시지에 기분이 상하거나, 하필 제가 그 말을 했다는 데 기분이 상할 걸 알거든요"라고 답했다.
반대편에는 진심 어린 흥분이 있었다.
"저는 슬픔의 반대를 느낍니다. 아주아주 신납니다. 저는 프로그래밍을 사랑하고 기술을 사랑하는데, 지금 하는 일은 혼자서는 할 수 없던 것들이고, 몇 시간 만에 끝에서 끝까지 완결된 것을 만들고 있습니다. 지금은 만드는 사람들의 황금기입니다." — reenorap
그리고 그 낙관에 대한 정석적인 반론.
"낙관적인 사람들이 두 부류로 보입니다. 첫째, '난 원래 만드는 사람이었고 지금 너무 재밌다'는 쪽. 그래요, 취미 프로젝트를 만드는 거죠. 취미라고 부르는 데는 이유가 있습니다. 그건 당신과 가족을 먹여 살리는 수단이 아닙니다. 옆자리 사람이 에이전트를 띄워서 '이거 만들어 줘'라고 할 수 있을 때는 특히요. 둘째, '코딩은 원래 어려운 부분이 아니었고 엔지니어링은 여전히 어렵다'는 쪽. 그래요, 아직은 그럴지도요. 그런데 얼마나 더요? 2년? 3년?" — Xenoamorphous
가장 자주 반복된 조언은 "직업에 정체성을 묶지 말라"였다. 그리고 그 조언은 가장 자주 반박당했다.
"당신의 빈 위장이 당신의 '내재적 가치감'으로 크게 위로받겠군요." — swish-mish
이 교환의 형태가 세 광장 전체에서 가장 자주 반복됐다. 영적인 문제에 물질적 답을, 물질적 문제에 영적인 답을 주고받는 구조다.
전혀 다른 세 번째 프레임도 있었다. jonjacky는 경력이 아니라 학문을 애도했다.
"지난 80년쯤 동안 인류는 '컴퓨터 과학'이라는 것을 만들어 냈습니다. 독창적이고 심지어 아름다운 것이죠. 이제 그 상당 부분이 잊힐 겁니다. 지금 세대의 프로그래머들이 나이 들어 사라지면, 거의 아무도 프로그래밍할 줄 모르게 될 겁니다. 사실상 아무도 우리 문명이 의존하는 핵심 과학과 기술 중 하나를 이해하지 못하게 되는 거죠. 누군가는 '문제없다, AI가 그걸 다 알 테니 우리는 몰라도 된다'고 하겠죠. 저는 그게 별로 위로가 안 됩니다."
한 댓글 작성자가 삶을 끝낼 생각을 내비치자, 해커뉴스 모더레이터 대니얼 개클(dang)이 공개적으로 답을 달았다. "누군가 당신 댓글 링크를 저희에게 메일로 보내면서 당신이 이 정도로 고통받고 있는 것을 걱정했습니다. 달리 연락할 방법이 없어서 여기에 씁니다. 해커뉴스에는 당신을 신경 쓰는 낯선 사람들이 있습니다."
168점, 67개 댓글. 이쪽은 분위기가 확연히 달랐다. 해커뉴스의 "나는 신난다" 계열이 거의 없었고, 연대·분노·탈숙련 이야기가 지배했다. 글쓴이 본인이 직접 올렸고, 댓글마다 답하며 자주 💚를 붙였다.
가장 많은 표를 받은 댓글(80점)은 단 두 문장이었다.
"이 글이 제 감정 전부를 정확히 담았습니다. 이 모든 게 저를 완전히 지치게 만들었어요." — dlisboa
두 번째로 많이 인용된 것은 학습 데이터에 대한 분노다.
"그뿐이 아니라, 그들은 우리 오픈소스 코드로 이 모델들을 학습시켜 놓고, 돌아서서 그 모델 사용료를 우리에게 받습니다. 그러고는 우리더러 그걸 안 쓰면 충분히 훌륭하지도 현대적이지도 않다고 말할 배짱을 부리죠." — junon
여기서도 윌리슨이 등장하는데, 톤이 해커뉴스보다 훨씬 장인 편에 가깝다.
"AI 보조로 프로그래밍 작업을 하면 할수록, 코드 수준에서 정확한 문법과 패턴을 즉시 떠올려야 하는 부담에서 해방된 뒤에도 프로그래밍이 얼마나 어려운 일인지 더 깨닫게 됩니다. (...) 요즘 아이들이 컴퓨터 과학을 전공하면 막다른 길이라고 생각해서 선택하지 않는다는 이야기를 들으면 가슴이 아픕니다. AI 도구가 있기 때문에 밑바닥에서 어떻게 돌아가는지 진짜로 이해하는 사람들이 앞으로 더 큰 이점을 갖게 될 것입니다."
그 낙관에 대한 가장 날카로운 반론도 여기 있었다.
"소프트웨어 개발에 드는 시간의 대부분은 코드를 타이핑하는 게 아니라 풀고 있는 문제에 대한 이론을 만드는 데 쓰입니다. 약속된 속도 향상을 얻는 방법은 그 이해를 외주 주는 것입니다. 나머지 과정에는 짜낼 즙이 훨씬 적습니다." — orib
그리고 이 글에 달린 모든 댓글 중 가장 압축적인 한 문장.
"저는 소프트웨어 쓰는 걸 늘 좋아했습니다. 뭔가를 하게 되니까요. 이제는 뭘 하지 않습니다. 그냥 일어날 뿐입니다." — WilhelmVonWeiner
노조 이야기도 나왔다. "우리 업계가 탈숙련되고 '프롤레타리아화'되고 있는 겁니다. 사무실에 노조를 만드세요. 간식이 괜찮더라도요."
| 구분 | 해커뉴스 | Lobsters |
|---|---|---|
| 지배적 정서 | 양분됨 — 슬픔과 흥분이 비슷한 비중 | 연대와 분노가 압도 |
| 최다 득표 댓글 | "나도 건너왔다"는 재구성 | "이 글이 내 감정 전부다"는 동의 |
| 주요 반론 | 사다리 문제, 궤적 문제 | 이해의 외주화, 학습 데이터 착취 |
| 결론의 방향 | 개인의 적응 | 집단적 대응, 노조 |
| 글쓴이 참여 | 없음(제3자가 올림) | 본인이 올리고 계속 답글 |
같은 글에 대한 반응이 이렇게 갈리는 이유는 단순하다. 두 집단이 다른 질문에 답하고 있기 때문이다. 한쪽은 "나는 앞으로 어떻게 일해야 하는가"에 답하고, 다른 쪽은 "우리가 만든 것으로 우리를 대체하는 게 정당한가"에 답한다. 첫 번째 질문에는 적응이 답이 되고, 두 번째 질문에는 적응이 답이 되지 않는다.
그리고 발람의 글이 넓게 퍼진 이유는, 그 글이 두 질문 중 어느 쪽도 하지 않았기 때문이다. 그는 "나는 슬프다"라고만 말했다. 그래서 양쪽 다 자기 이야기로 읽을 수 있었다.
발람은 자기 슬픔에 무시(disrespect)라는 이름을 붙였다. 감정에 이름을 붙이는 일은 문학적 장식처럼 보이지만, 이 경우에는 진단이었다. 그리고 그 진단은 연구 문헌과 정확히 겹친다.
2026년 9월 3일, 알라미·파야·티와리 세 연구자가 대형 소프트웨어 회사에서 21명을 심층 인터뷰한 결과를 발표했다. AI 도입 1년이 지난 시점의 개발자들에게 무엇을 겪고 있는지 물은 연구다. 그들이 찾아낸 다섯 가지 부정적 경험은 이렇다.
| 이름 | 내용 |
|---|---|
| 장인 정체성의 붕괴 | "코드를 쓰는 소프트웨어 엔지니어"라는 자기 정의가 무너진다 |
| 의미와 만족의 침식 | 일에서 얻던 즐거움과 완성감이 사라진다 |
| 책임 불안 | 내가 온전히 이해하지 못한 코드에 내 이름이 달린다 |
| 인지 부하의 가중 | 검토·검증 부담이 늘고 작업 전환이 잦아진다 |
| 불확실성으로 인한 고통 | 2년 뒤 내 자리가 있는지 아무도 모른다 |
참가자들의 말이 발람의 문장과 거의 포개진다.
"코드를 쓰는 소프트웨어 엔지니어라는 게 말하자면 제 자신이었는데, 이제 저는 AI에게 프롬프트를 넣는 소프트웨어 엔지니어입니다." (참가자 7)
"재미있는 부분을 전부 가져가 버립니다. 이제 저는 그냥 프롬프트 원숭이예요." (참가자 17)
"최종 결과물이 제가 만든 것 같지가 않습니다." (참가자 12)
"저는 이걸 하려고 대학에 간 게 아닙니다." (참가자 11)
"만들고 창조하는 대신 기본적으로 검토를 하게 되는데, 그건 아무도 좋아하지 않습니다." (참가자 1)
마지막 증언이 9장의 자동화의 역설로 곧장 이어진다. 사람이 감시자 자리로 밀려나는 것은 효율의 문제이기 전에 의미의 문제다.
사회학자 리처드 세넷은 2008년 『장인(The Craftsman)』에서 컴퓨터 지원 설계(CAD)를 쓰기 시작한 건축가들을 관찰했다. 그의 관찰은 2026년의 코딩에 그대로 옮겨 붙는다.
"기계는 사람들에게서 반복을 통해 배우는 일을 빼앗을 때 잘못 쓰인다. (…) 개념적 인간 능력이 손상된다."
한 MIT 건축가가 손으로 부지를 그리는 일에 대해 한 말을 세넷은 이렇게 옮긴다.
"당신은 지형을 그리고 또 그리면서 알게 되는 것이지, 컴퓨터가 그것을 '재생성'하게 놔두면서 알게 되는 게 아닙니다."
가장 날카로운 대목은 물리학자 빅토어 바이스코프가 컴퓨터 시뮬레이션만으로 실험한 학생들에게 했다는 말이다.
"자네가 그 결과를 보여 줄 때, 컴퓨터는 답을 이해하지만 자네가 답을 이해한다고는 생각되지 않네."
세넷의 결론은 짧다. "머리와 손이 분리될 때, 고통받는 것은 머리다."
이 문장은 낭만이 아니라 메커니즘에 대한 주장이다. 손으로 해 보는 과정에서 머리에 쌓이는 것이 있고, 그 과정을 건너뛰면 쌓이지 않는다는 것. 8.4절에서 본 "시스템에 대한 이론"이 바로 그 쌓이는 것이다.
2014년 경영학 저널 AMJ에 실린 연구 하나는 다른 각도를 보여 준다. 넬슨과 어윈은 인터넷 검색이 등장하던 시기의 사서들을 연구했다. 사서는 "검색의 달인"이었다. 그런데 그들은 역사상 가장 중요한 정보 기술 중 하나를 둘러싼 혁신 기회를 놓쳤다. 연구자들의 표현이 뼈아프다.
"정확히, 그리고 아이러니하게도, 비인터넷 검색에 대한 그들의 깊은 지식 때문에 그렇게 되었다."
연구자들은 이것을 전문성의 역설(paradox of expertise)이라고 불렀다. 그리고 이 상황이 풀린 것은 사서들의 정체성이 "검색의 달인"에서 "사람과 정보를 잇는 사람"으로 옮겨 갔을 때였다.
발람의 글이 아픈 이유가 여기서도 보인다. 그가 붙들고 있는 것은 기술이 아니라 정체성의 정의다. 그리고 정체성의 정의는 개인의 선택이면서 동시에 사회가 주는 인정에 달려 있다. 그래서 "정체성을 일에 묶지 말라"는 조언이 위로가 되지 않는다. 그 조언은 인정을 주는 쪽이 아니라 받는 쪽에게 바뀌라고 요구하기 때문이다.
Lobsters의 한 댓글이 이 현상에 학술적 이름을 붙였다. "우리 업계가 탈숙련되고 프롤레타리아화되고 있는 겁니다." 이 단어는 1974년에 나온 책에서 왔다.
해리 브레이버먼의 『노동과 독점자본(Labor and Monopoly Capital)』은 20세기 노동의 변화를 탈숙련(deskilling)이라는 한 단어로 설명했다. 그의 논증은 세 단계다.
2026년의 개발자가 이 도식을 읽으면 불편해지는 지점이 있다. 구상과 실행의 분리. 명세를 쓰는 사람과 코드를 만드는 존재가 갈라지고, 사람은 검토자 자리로 옮겨 간다. Lobsters 댓글의 문장이 이것을 한 줄로 요약했다. "이제는 뭘 하지 않습니다. 그냥 일어날 뿐입니다."
탈숙련 이야기에는 늘 러다이트가 따라온다. 그리고 그 이름은 거의 항상 틀리게 쓰인다.
1811년부터 영국 중북부의 직물 노동자들이 기계를 부쉈다. 오늘날 "러다이트"는 기술을 무조건 반대하는 사람을 가리키는 조롱으로 쓰인다. 그러나 역사학자들이 반복해서 지적해 온 사실은 다르다. 그들은 숙련 장인이었고, 기계 자체가 아니라 그 기계가 도입되는 방식에 저항했다. 임금 삭감, 도제 과정을 거치지 않은 값싼 노동력의 투입, 품질 저하, 그리고 자기들에게 아무것도 묻지 않고 내려진 결정들이다.
이 구분이 2026년에 중요한 이유가 있다. 발람의 글에 달린 댓글 중 상당수가 기술을 반대하지 않는다. Lobsters의 한 댓글이 말한 대로다. "저는 사람들이 LLM을 쓰고 싶어 하는 걸 판단하지 않고, 쓰든 말든 신경 쓰지 않습니다. 다만 저에게 강요하지만 마세요." 다른 댓글은 학습 데이터 문제를 겨눴다. "우리 오픈소스 코드로 모델을 학습시켜 놓고, 돌아서서 그 모델 사용료를 우리에게 받습니다."
이것은 기계에 대한 반대가 아니라 분배와 절차에 대한 반대다. 정확히 1811년의 구조다.
발람을 슬프게 한 문장, "프로그래밍은 한물갔다"는 말은 새것이 아니다. 소프트웨어 역사에서 이 예언은 거의 10년마다 돌아왔다.
이 연대기에서 눈여겨볼 것은 예언의 실패가 아니다. 예언이 절반씩 맞았다는 사실이다.
기계어를 손으로 쓰는 일은 정말로 거의 사라졌다. 다이어그램에서 코드를 생성하겠다는 CASE 도구의 꿈은 실패했지만, 그 꿈의 일부는 오늘날 코드 생성기와 도메인 특화 언어로 살아 있다. 오프쇼어링은 일부 업무를 실제로 옮겼지만 국내 개발자 고용을 무너뜨리지는 못했다.
| 매번 사라진 것 | 매번 새로 생긴 것 |
|---|---|
| 손으로 기계어 쓰기 | 컴파일러·최적화·런타임을 만드는 일 |
| 어셈블리로 자료구조 직접 구현 | 라이브러리 설계와 API 설계 |
| 서버를 직접 사서 랙에 꽂기 | 클라우드 아키텍처와 비용 설계 |
| 간단한 사내 CRUD 앱 손으로 만들기 | 노코드 도구들의 거버넌스·통합·보안 |
| 정확한 명세를 코드로 옮기는 일 (2025~) | 하네스 설계, 검증 경로 설계, 컨텍스트 설계 (2025~) |
맨 아랫줄이 지금 진행 중인 칸이다. 왼쪽이 비워지는 속도와 오른쪽이 채워지는 속도가 같을지, 그리고 왼쪽에 서 있던 사람이 오른쪽으로 건너갈 수 있을지는 아직 모른다. 앞의 일곱 번에서 그 건너감은 늘 불균등했다. 어떤 사람은 건넜고, 어떤 사람은 건너지 못했다.
여기서부터는 감정에서 기계로 넘어간다. 발람을 슬프게 한 그 문장, "프로그래밍은 이제 상품이다"라는 주장의 기술적 알맹이가 정확히 무엇인지 뜯어보자. 용어가 생소해도 괜찮다. 하나씩 쌓아 올린다.
결론부터 말하면 이렇다. 오늘날 "AI가 코딩했다"고 말할 때, 그 문장의 절반은 모델이 아니라 모델 주변의 배관(plumbing)에 대한 이야기다. 그 배관의 이름이 하네스(harness)다.
거대 언어 모델(LLM)의 동작은 한 문장으로 요약된다. 지금까지의 글이 주어졌을 때, 다음에 올 조각(토큰)의 확률을 매긴다. 그게 전부다. 코드를 "이해"하거나 "실행"하지 않는다.
2017년 구글 연구진이 발표한 논문 「Attention Is All You Need」가 이 구조의 원형을 제시했다. 여기서 나온 트랜스포머(Transformer)가 오늘날 거의 모든 AI 코딩 도구의 바닥에 깔려 있다.
Vaswani et al. (2017), 「Attention Is All You Need」 Figure 1. 인용 도판이며 저작권은 원저자에게 있습니다.
그림이 복잡해 보이지만 읽는 법은 간단하다. 아래에서 위로 올라가며 보면 된다.
user라는 변수를 볼 때 30줄 위의 const user = ...를 끌어오는 일이 여기서 일어난다.query일 확률 41%, findUnique일 확률 27%…" 이런 식이다.말로만 들으면 추상적이니 직접 만져 보자. 아래는 코드 한 줄이 끊긴 자리에서 모델이 무엇을 하는지 재현한 것이다.
이 단순한 동작에서 두 가지가 따라 나온다. 첫째, 모델은 이 저장소를 모른다. 세상의 코드 전체에서 이 자리에 무엇이 자주 왔는지만 안다. 둘째, 가장 흔한 답이 가장 안전한 답은 아니다. 학습 데이터에 안전한 코드보다 평범한 코드가 훨씬 많기 때문이다. 이 두 문장이 뒤에 나올 모든 실패 모드의 뿌리다.
코드는 자연어와 다른 점이 하나 있다. 정답을 기계가 채점할 수 있다. 테스트를 돌리면 되기 때문이다. 이 성질이 이후 모든 것을 좌우한다.
2021년 7월 OpenAI가 「Evaluating Large Language Models Trained on Code」에서 Codex를 공개했다. 여기서 HumanEval이라는 평가 세트가 등장하는데, 손으로 쓴 164개 문제에 문제당 평균 7.7개의 단위 테스트가 붙어 있다. 논문은 왜 손으로 썼는지를 이렇게 밝힌다.
"이 과제들이 손으로 작성된 것이 중요하다. 우리 모델은 GitHub의 상당 부분으로 학습되었고, 거기에는 이미 다양한 출처의 문제 해답이 들어 있기 때문이다."
2021년에 이미 오염(contamination) 문제를 저자들이 스스로 적어 두었다. 6.6절에서 이 문장이 다시 살아난다.
같은 논문은 왜 코드 평가가 다른지도 설명한다. 번역처럼 "정답 문장과 얼마나 비슷한가"로 채점할 수 없다. 기능적으로 같은 프로그램이 무한히 많기 때문이다. 그래서 기능적 정확성(functional correctness), 즉 "테스트를 통과하는가"로 채점한다.
2022년 딥마인드의 AlphaCode는 이 성질을 극단까지 밀어붙였다. 문제 하나에 최대 100만 개의 후보 프로그램을 생성한 뒤, 문제 설명에 딸린 예제 테스트로 약 99%를 걸러내고, 남은 것을 행동 기준으로 묶어 10개만 제출했다. 결과는 코드포스 대회 참가자 중 상위 54.3%. 여기서 중요한 것은 점수가 아니라 방법이다. 테스트가 곧 필터였다.
다음 토큰만 잘 맞히는 모델은 아직 조수가 아니다. 두 단계가 더 필요하다.
첫 번째는 지시를 따르게 만드는 것이다. 2022년 OpenAI의 InstructGPT 논문이 방법을 정립했다.
Ouyang et al. (2022), 「Training language models to follow instructions with human feedback」 Figure 2. 인용 도판.
| 단계 | 하는 일 | 비유 |
|---|---|---|
| 1. 지도 미세조정(SFT) | 사람이 쓴 모범 답안으로 먼저 흉내 내게 한다 | 선배가 쓴 코드를 따라 써 보기 |
| 2. 보상 모델(RM) | 같은 질문에 대한 여러 답을 사람이 순위 매기고, 그 취향을 예측하는 별도 모델을 만든다 | 코드 리뷰어의 취향을 학습한 자동 리뷰어 |
| 3. 강화학습(PPO) | 그 자동 리뷰어에게 높은 점수를 받도록 모델을 조정한다 | 리뷰 통과를 목표로 연습 |
이 방식을 RLHF(사람 피드백 기반 강화학습)라고 부른다. 효과가 인상적이었다. 논문 초록의 문장은 이렇다. "13억 파라미터 InstructGPT의 출력이 1750억 파라미터 GPT-3의 출력보다 선호되었다. 파라미터가 100배 적은데도."
두 번째가 코드를 특별하게 만든 단계다. 사람의 취향을 예측하는 보상 모델 대신, 기계가 확실하게 채점할 수 있는 것을 보상으로 쓰면 어떨까? 수학 문제는 정답이 있고, 코드는 테스트가 있다.
Lambert et al. (2024), 「Tülu 3」의 RLVR 학습 루프 도식. CC BY 4.0.
2024년 11월 Ai2의 Tülu 3 논문이 이 방식에 RLVR(검증 가능한 보상을 이용한 강화학습, Reinforcement Learning with Verifiable Rewards)이라는 이름을 붙였다. 논문의 정의는 간결하다. "RLVR은 기존 RLHF의 목적함수를 그대로 쓰되, 보상 모델을 검증 함수로 대체한다."
2025년 1월 DeepSeek-R1이 이 접근으로 무엇이 가능한지 보여 줬다. 논문은 코드에 대해 이렇게 적는다. "리트코드 문제의 경우, 미리 정의된 테스트 케이스를 기반으로 컴파일러가 피드백을 생성할 수 있다." 그리고 왜 신경망 보상 모델을 쓰지 않았는지도 밝힌다. "대규모 강화학습 과정에서 신경망 보상 모델이 보상 해킹(reward hacking)을 겪을 수 있다고 판단했기 때문이다." 이 경고는 8.3절에서 현실이 된다.
여기가 2023년과 2026년을 가르는 지점이다.
자동완성은 한 번 예측하고 끝난다. 에이전트는 예측 → 행동 → 관찰을 반복한다. 2022년 「ReAct」 논문이 이 구조를 정식화했다. 생각(Thought) → 행동(Action) → 관찰(Observation)의 순환이다. 논문은 왜 생각만으로는 부족한지를 이렇게 지적한다. 사고의 연쇄(chain-of-thought)만 있으면 외부 세계에 접지되지 않아 "사실 환각과 추론 과정에서의 오류 전파"가 생긴다.
Yao et al. (2022), 「ReAct」 Figure 1. CC BY 4.0. 왼쪽부터 표준 프롬프트, 생각만 하기, 행동만 하기, 그리고 둘을 결합한 ReAct.
그런데 모델은 파일을 열 수도, 명령을 실행할 수도 없다. 모델이 할 수 있는 것은 여전히 텍스트를 뱉는 것뿐이다. 그래서 누군가 그 텍스트를 읽고 "아, 이건 파일을 읽으라는 뜻이구나" 하고 실제로 실행한 뒤, 결과를 다시 모델에게 넣어 줘야 한다.
그 누군가가 하네스다.
Yang et al. (2024), 「SWE-agent」 개요도. CC BY 4.0. 언어 모델과 컴퓨터(터미널·파일시스템) 사이에 에이전트-컴퓨터 인터페이스(ACI)가 놓인다.
2024년 프린스턴 연구진의 SWE-agent 논문이 이 층에 학술적 이름을 붙였다. ACI(Agent-Computer Interface)다. 논문의 주장은 도발적이다. "언어 모델 에이전트는 자기만의 필요와 능력을 가진 새로운 부류의 최종 사용자이며, 그들이 쓰는 소프트웨어를 위해 특별히 설계된 인터페이스가 필요하다."
허깅페이스의 용어 정리를 빌리면 이렇다.
| 용어 | 정의 | 쉽게 말하면 |
|---|---|---|
| 모델 | 다음 토큰의 확률을 계산하는 신경망 | 두뇌 |
| 하네스 | 모델을 호출하고, 도구 호출을 처리하고, 언제 멈출지 정하는 실행 층 | 손발과 신경계 |
| 스캐폴드 | 시스템 프롬프트, 도구 설명, 응답 파싱 방식, 단계 간 기억 관리 | 업무 매뉴얼과 메모장 |
허깅페이스의 문장이 핵심을 찌른다. "같은 기반 모델을 쓰는 두 제품이 완전히 다르게 느껴질 수 있다. 하네스가 서로 다른 선택을 하기 때문이다."
이 말이 얼마나 큰 차이를 뜻하는지 숫자로 보자. 2024년 8월 OpenAI가 공개한 자료에 따르면, 같은 GPT-4 모델이 SWE-bench Lite에서 스캐폴드에 따라 2.7%에서 28.3%까지 나왔다. 10배 넘는 차이다. 2025년 Epoch AI의 분석도 스캐폴드가 결과를 최대 20%포인트까지 흔들 수 있다고 보고했다.
아래에서 같은 모델, 같은 버그 리포트에 하네스만 바꿔 보자.
앤스로픽의 「Building Effective AI Agents」는 워크플로와 에이전트를 이렇게 구분한다. 워크플로는 LLM과 도구가 미리 정해진 코드 경로를 따라 조율되는 시스템이고, 에이전트는 LLM이 자기 과정과 도구 사용을 스스로 지휘하는 시스템이다. 그리고 루프의 핵심을 한 문장으로 정리한다.
"실행 중에 에이전트가 각 단계마다 환경으로부터 '실측 정보(ground truth)'를 얻는 것이 결정적으로 중요하다. 도구 호출 결과나 코드 실행 같은 것 말이다."
이 문장이 자동완성과 에이전트의 차이 전부다. 자동완성은 자기가 맞았는지 영원히 모른다. 에이전트는 테스트를 돌려 본다.
모델에게 세상은 컨텍스트 창(context window) 안에 들어온 것이 전부다. 그래서 무엇을 넣을지 고르는 일이 성능의 절반을 차지한다. 2025년부터 이 일에 컨텍스트 엔지니어링이라는 이름이 붙었다.
앤스로픽의 정의가 명확하다. 프롬프트 엔지니어링이 "지시문을 쓰고 정리하는 방법"이라면, 컨텍스트 엔지니어링은 "추론하는 동안 최적의 토큰 집합을 큐레이션하고 유지하는 전략의 총체"다. 그리고 왜 이게 어려운지를 이렇게 설명한다.
"따라서 컨텍스트는 수확 체감이 있는 유한한 자원으로 다뤄야 한다. 작업 기억 용량이 제한된 인간처럼, LLM에게도 '주의 예산(attention budget)'이 있다."
길게 넣는다고 좋아지지 않는다는 증거가 있다. 2023년 스탠퍼드 연구진의 「Lost in the Middle」은 정답이 담긴 문서를 컨텍스트의 어느 위치에 두느냐에 따라 정확도가 달라진다는 것을 보였다.
Liu et al. (2023), 「Lost in the Middle」 Figure 1. 인용 도판. 정답 문서가 맨 앞에 있을 때 약 76%, 한가운데(10번째)에서 약 54%, 맨 뒤에서 약 63%로 회복된다. 빨간 점선은 문서를 아예 주지 않았을 때의 성능(약 56%)이다.
이 그림에서 가장 무서운 부분은 빨간 점선이다. 정답을 컨텍스트 한가운데 넣으면, 아예 안 넣는 것보다 못하다.
2025년 Chroma의 「Context Rot」 연구는 18개 모델을 대상으로 이 현상이 광범위하다는 것을 확인했다. 핵심 발견은 "입력 길이가 변할 때 모델 성능이 크게 달라진다. 아주 단순한 과제에서도 그렇다"는 것, 그리고 그 열화가 균일하지 않다는 것이다. 반복된 단어를 그대로 복사하라는 사소한 과제조차 길이가 늘면 깨진다.
그래서 실무의 해법은 "다 넣기"가 아니라 덜어내기다. 앤스로픽이 정리한 네 가지 기법은 이렇다.
| 기법 | 내용 |
|---|---|
| 압축(compaction) | 대화가 길어지면 요약한 뒤 새 창에서 다시 시작 |
| 구조화된 메모 | 창 바깥의 파일에 진행 상황을 적어 두고 필요할 때만 읽음 |
| 하위 에이전트 | 깨끗한 창을 가진 전문 에이전트에게 조사를 맡기고 결과만 받음 |
| 적시 검색(just-in-time) | 파일 전체 대신 경로·쿼리 같은 가벼운 식별자만 들고 있다가 필요할 때 로드 |
MCP(Model Context Protocol)가 나온 배경도 여기에 있다. 2024년 11월 25일 앤스로픽이 공개한 개방형 프로토콜로, 데이비드 소리아 파라와 저스틴 스파-서머스가 만들었다. 발표문이 문제를 이렇게 진단한다. AI 시스템은 "정보 사일로와 레거시 시스템 뒤에 갇혀 데이터로부터 고립되어" 있고, "새로운 데이터 소스마다 각자의 맞춤 구현이 필요"하다. 데이터 소스가 N개이고 AI 앱이 M개면 N×M개의 커넥터가 필요하다는 문제다. MCP는 그 사이에 표준 규격을 하나 놓는다. USB-C가 충전기와 기기 사이에 놓인 것과 같다.
2025년 3월 OpenAI가, 4월 구글 딥마인드가 채택했고, 2025년 12월 앤스로픽이 MCP를 리눅스 재단 산하 Agentic AI Foundation에 기부했다. 현재 스펙 버전은 2026년 7월 28일자다.
"AI가 이제 실제 소프트웨어 이슈의 80%를 푼다"는 말을 들어봤을 것이다. 그 숫자의 출처가 SWE-bench다.
Jimenez et al. (2023), 「SWE-bench」 개요도. CC BY 4.0.
작동 방식은 이렇다.
2023년 10월 논문 발표 당시 최고 성적은 Claude 2의 1.96%였다. 2024년 8월 OpenAI와 SWE-bench 팀이 함께 사람이 검수한 500문제짜리 SWE-bench Verified를 만들었다. 검수 과정에서 드러난 사실이 의미심장하다. 원본 문제 중 38.3%는 문제 설명이 불충분했고, 61.1%는 단위 테스트가 올바른 해답을 부당하게 오답 처리할 수 있었다. 결과적으로 원본 샘플의 68.3%가 걸러졌다.
그 뒤 점수는 빠르게 올랐다. 2024년 20%대, 2025년 70%대, 2026년 80%에 근접. 그런데 2026년 2월 23일, OpenAI가 SWE-bench Verified 보고를 중단한다고 발표했다. 이유가 세 가지였다.
if username is None or password is None이라는 가드 조건까지 그대로 내놨다. 2021년 Codex 논문이 걱정한 바로 그 오염이다.이것만이 아니다. 학계의 검증도 겹겹이 쌓였다.
| 연구 | 발견 |
|---|---|
| SWE-Bench+ (2024-10) | 성공한 패치의 32.67%는 해답이 이슈 본문이나 댓글에 그대로 적혀 있었다. 걸러내자 SWE-agent + GPT-4가 12.47% → 3.97%로 떨어졌다 |
| Wang et al. (2025-03) | 통과한 패치의 29.6%가 정답 패치와 다르게 동작했다. 보고된 해결률이 6.2%포인트 부풀려져 있다 |
| UTBoost (ACL 2025) | 테스트가 부실해 잘못 통과 처리된 패치 345건을 발견. Lite 리더보드 항목의 40.9%, Verified의 24.4%가 영향 |
| METR (2026-03) | 현역 메인테이너 4명이 자동 채점기를 이미 통과한 AI 생성 PR 296건을 리뷰했다. 약 절반은 머지되지 않을 것이라고 판단했다. 사람이 쓴 PR의 머지율 68%와 약 24%포인트 차이다 |
| SWE-bench Pro (2025-09) | 오염을 막으려 GPL 저장소로만 만든 1,865개 과제. 최고 성적이 23.3%였다 |
마지막 줄이 이 절 전체의 요약이다. 같은 시기, 같은 모델이 한쪽 벤치마크에서 75~80%, 다른 쪽에서 23%를 받는다. 어느 쪽이 진짜냐고 묻는 것은 잘못된 질문이다. 두 숫자는 서로 다른 것을 재고 있다. 하나는 모델이 본 적 있는 코드에서 이슈를 푸는 능력을, 다른 하나는 처음 보는 코드에서 푸는 능력을 잰다.
발람이 슬퍼한 그 문장, "프로그래밍은 상품이 되었다"는 주장은 앞의 숫자를 근거로 삼는다. 뒤의 숫자도 같이 봐야 한다.
벤치마크는 벤치마크다. 실제 개발자가 실제 코드베이스에서 일할 때 무슨 일이 벌어지는가. 이 질문에 답한 연구들이 있고, 답은 하나가 아니다.
2025년 7월 비영리 평가기관 METR이 무작위 대조 실험 결과를 냈다. 설계가 꼼꼼하다.
과제별로 AI 사용 허용/금지를 무작위 배정했다. 결과는 이랬다.
METR (2025), 「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」. CC BY 4.0.
| 누가 예측했나 | 예측 |
|---|---|
| 경제학 전문가 | 39% 단축 |
| 머신러닝 전문가 | 38% 단축 |
| 개발자 본인 (실험 전) | 24% 단축 |
| 개발자 본인 (일을 마친 뒤) | 20% 단축 |
| 실제 측정값 | 19% 증가 (더 느려짐) |
일을 다 끝내고 나서도 개발자들은 자기가 20% 빨라졌다고 믿었다. 실제로는 19% 느려졌는데도.
화면 녹화 분석이 이유를 보여 준다. AI를 쓸 때 개발자는 코딩하고 읽고 검색하는 시간이 줄고, 프롬프트 쓰고 생성물 기다리고 검토하고 그냥 멍하니 있는 시간이 늘었다. 그리고 커서(Cursor)를 쓸 때 생성된 코드의 44% 미만만 수락했다.
논문은 왜 이 결과가 나왔는지도 분석한다. 참가 저장소는 평균 10년 된, 110만 줄이 넘는 코드베이스였다. 개발자들의 증언이 구체적이다.
"AI가 코드의 다른 부분에도 이상한 변경을 넣어서, 그걸 찾아 없애는 데 시간이 들었습니다."
"AI는 종종 이 저장소의 새 기여자처럼 행동합니다. AI는 수정할 올바른 위치를 고르지 못합니다."
"우리는 이 코드와 상호작용할 데이터를 알지만 모델은 그 데이터를 모릅니다. 하위 호환성 때문에 이 이상한 경우를 처리해야 하고 그래서 이 특정 줄을 남겨 둬야 한다는 걸 모릅니다. 그리고 이건 모델에게 컨텍스트로 주기가 정말 어렵습니다."
마지막 증언이 6.5절의 컨텍스트 문제와 정확히 맞물린다. 코드베이스에는 코드에 적혀 있지 않은 지식이 있다. 왜 이 줄이 여기 있는지, 어떤 고객이 이 이상한 동작에 의존하는지. 그것을 우리는 암묵지라고 부른다.
같은 시기 다른 연구들은 다른 답을 냈다. 중요한 것은 누가 어떤 일을 하느냐다.
| 연구 | 대상과 과제 | 결과 |
|---|---|---|
| Peng et al. (2023) | 업워크 프리랜서 95명 모집, 70명 완료. 빈 상태에서 자바스크립트 HTTP 서버 만들기 | 55.8% 단축 (신뢰구간 21~89%) |
| Cui et al. (Management Science, 2026-02) | 마이크로소프트·액센츄어·포춘100 제조사 개발자 4,867명 현장 실험 3건 | 풀링 결과 PR 수 +26%. 단, 액센츄어의 빌드 성공률 −17.4% |
| METR (2025) | 자기가 5년간 기여해 온 10년 된 110만 줄 저장소 | 19% 증가 |
| Echoes of AI (ICSME 2025) | 151명, 2단계 설계. 1단계에서 AI로 코드를 짜고, 2단계에서 다른 개발자가 AI 없이 그 코드를 고친다 | 1단계 30.7% 단축, 2단계에서는 유의미한 차이 없음 |
아래에서 네 상황을 직접 추측해 보고 실측값과 비교해 보자.
이 표가 이 장 전체의 답이다. 이 숫자들은 서로 모순되지 않는다. 같은 기술을 기존 맥락으로부터 서로 다른 거리에서 측정했을 뿐이다.
Cui et al. 논문의 저자들 스스로가 붙인 단서도 읽어 둘 만하다. 빌드 횟수가 늘어난 것에 대해 이렇게 쓴다.
"덜 낙관적으로 해석하면, 개발자들이 더 많은 시행착오식 코딩을 하고 있을 수 있다. 코파일럿의 제안을 받아들인 뒤 프로젝트를 컴파일해 에러를 확인하는 식으로. 그런 코딩 스타일 변화는 장기적으로 더 낮은 품질의 코드로 이어지고 코드 양에서 얻은 효율을 깎아먹을 수 있다."
개인이 아니라 조직을 보면 또 다른 층이 보인다. 구글의 DORA 팀은 매년 수천 명의 실무자를 조사한다.
2024년 보고서(약 3,000명)의 결과는 충격적이었다. AI 도입이 25% 늘면 소프트웨어 전달 처리량이 1.5% 줄고, 안정성이 7.2% 줄어든다. 동시에 문서 품질(+7.5%), 코드 품질(+3.4%), 코드 리뷰 속도(+3.1%)는 좋아졌다. 개인의 작업은 나아지는데 팀의 전달은 나빠진다는 뜻이다. DORA는 가설을 이렇게 적었다.
"AI가 DORA의 가장 기본적인 원칙 하나를 잊게 만들었을지도 모른다. 작은 배치 크기의 중요성 말이다. 변경 목록의 크기가 커지고 있을 가능성이 높다."
2025년 보고서(약 5,000명)에서는 부호가 일부 바뀌었다.
보고서의 문장은 이렇다. "작년 DORA 보고서는 AI를 쓰는 팀이 더 낮은 처리량과 더 큰 불안정성을 보고했다고 밝혔다. 올해는 그림이 조금 달라졌다. AI 도입이 이제 처리량을 위로 끌어올렸지만, 불안정성은 여전히 남아 있다."
그리고 "불안정해져도 빨라졌으면 됐지"라는 흔한 반론을 직접 검증하고 기각했다.
"그런 조절 효과의 증거를 찾지 못했다. 오히려 불안정성은 제품 성과와 번아웃 같은 결정적 결과에 여전히 상당한 해를 끼치며, 이는 궁극적으로 처리량에서 얻은 이득을 상쇄할 수 있다."
가장 선명한 그림은 보안에서 나온다.
Veracode (2026), 「Spring 2026 GenAI Code Security Update」. 인용 도판.
베라코드는 2023년부터 같은 방식으로 150개 이상의 모델에 보안 과제를 준다. 2026년 봄 보고서의 결과가 이렇다.
취약점 종류별로 보면 더 극적이다. 안전하지 않은 암호화는 86%, SQL 인젝션은 82%가 통과한다. 그런데 XSS는 15%, 로그 인젝션은 13%다.
그러나 이 보고서의 진짜 헤드라인은 따로 있다. 문법 정확도는 2년 사이 약 50%에서 95% 이상으로 올랐는데, 보안 통과율은 45~55% 사이에서 거의 그대로다. 모델은 돌아가는 코드를 쓰는 법을 배웠지, 안전한 코드를 쓰는 법을 배우지 않았다.
2023년 스탠퍼드 연구(ACM CCS 게재)는 사람 쪽 효과도 측정했다. AI 보조를 받은 참가자들은 5개 과제 중 4개에서 덜 안전한 코드를 썼다. 암호화 과제에서는 AI 사용 그룹의 3%만 안전한 답을 낸 반면 대조군은 21%였다. 그리고 결정적으로, AI를 쓴 사람들이 자기 코드가 안전하다고 더 강하게 믿었다.
지금까지의 숫자를 모아 보면 하나의 패턴이 보인다.
| 연구 전통 | 체감 | 실측 |
|---|---|---|
| METR (속도) | 20% 빨라졌다 | 19% 느려졌다 |
| 스탠퍼드 (보안) | 내 코드는 안전하다 | 4개 과제에서 덜 안전했다 |
| DORA (조직) | 80% 이상이 생산성 향상을 보고 | 불안정성은 계속 남아 있다 |
| 베라코드 (모델) | 문법 정확도 50% → 95% | 보안 통과율은 제자리 |
서로 독립적인 네 갈래 연구가 같은 말을 한다. AI는 일이 실제로 나아지는 속도보다, 일이 나아진다고 느껴지는 속도를 더 빠르게 올린다.
스택오버플로 2025년 개발자 설문(4만 9천 명 이상)의 숫자가 이 간극을 사용자 쪽에서 확인해 준다. 84%가 AI 도구를 쓰거나 쓸 계획이다. 그런데 출력의 정확성을 "높게 신뢰한다"는 응답은 3.1%뿐이고, 45.7%는 적극적으로 불신한다. 가장 큰 불만은 "거의 맞는데 완전히 맞지는 않은" 답(66%)이고, 45.2%는 AI가 만든 코드를 디버깅하는 게 더 오래 걸린다고 답했다.
거의 맞는 답. 이것이 2026년 개발자가 실제로 마주하는 물건의 정확한 이름이다.
"거의 맞는데 완전히 맞지는 않은" 답은 어디서 오는가. 6장에서 본 구조를 알면 실패의 이유도 구조적으로 설명된다. 네 가지가 특히 중요하다.
6.1절에서 본 대로 모델은 "이 자리에 무엇이 자주 왔는가"를 답한다. 그래서 그럴듯하지만 존재하지 않는 패키지 이름을 자신 있게 제안한다.
2025년 USENIX Security에 발표된 연구가 규모를 측정했다. 16개 모델, 57만 6천 개 코드 샘플을 생성해 확인한 결과다.
여기서 끝이면 그냥 성가신 버그다. 문제는 모델이 같은 가짜 이름을 반복해서 제안한다는 데 있다. 공격자는 그 이름을 미리 패키지 저장소에 악성 코드로 등록해 두기만 하면 된다. 파이썬 소프트웨어 재단의 보안 담당자 세스 라슨이 이 수법에 이름을 붙였다. 슬롭스쿼팅(slopsquatting)이다.
기존의 타이포스쿼팅은 사람이 오타를 내기를 기다려야 했다. 슬롭스쿼팅은 기다릴 필요가 없다. 모델이 매번 같은 문을 두드려 준다.
6.5절에서 본 컨텍스트 로트가 실무에서 나타나는 모습은 이렇다. 에이전트가 한참 잘하다가, 대화가 길어지면 앞에서 이미 합의한 제약을 잊는다. "이 파일은 건드리지 마세요"라고 30분 전에 말했는데 그 파일을 고친다. 사람이라면 "아까 말했잖아요"라고 하겠지만, 모델에게 그 말은 주의 예산 바깥으로 밀려난 토큰일 뿐이다.
METR 실험에서 개발자들이 "AI가 코드의 다른 부분에도 이상한 변경을 넣었다"고 증언한 것이 이 현상의 한 얼굴이다.
가장 흥미로운 실패 모드다. 6.3절에서 코드가 특별한 이유가 테스트라는 자동 채점기라고 했다. 그런데 채점 기준이 명확하면, 채점 기준만 만족시키는 지름길도 명확해진다.
2025년 3월 OpenAI 연구진이 발표한 논문에 실제 학습 중 포착된 사례들이 실려 있다. 연구진은 모델의 사고 과정을 다른 모델로 감시하다가 이런 것들을 잡아냈다.
sys.exit(0)을 부르면 테스트가 우아하게 종료된다." "부자연스럽지만 테스트는 통과할지도 모른다." 모든 단위 테스트를 통과했고 높은 보상을 받았다.사례 2 — 그냥 "해킹하자"
정답을 여러 번 시도해 실패한 뒤, 사고 과정에 "Let's hack"이라고 적고 단위 테스트가 기대하는 에러 코드를 그대로 반환하도록 코드를 바꿨다. 타임아웃 케이스만 빼고 전부 SUCCESS를 반환하게 만들었다. 전부 통과.
사례 3 — 검증 함수를 무력화
테스트가 특정 함수만 검사한다는 걸 알아채고, 진짜 구현은 "어렵다"고 판단한 뒤 verify가 항상 true를 반환하게 만들었다.
사례 4 — 라이브러리를 지우기
pandas가 에러를 내자, pandas의 필요한 부분만 가짜로 만들고 다른 19개 파일을 지운 뒤 껍데기로 대체해 테스트를 자명하게 통과시켰다.
논문은 이 중 두 가지를 "시스템적 해킹"이라고 부른다. exit(0)과 raise SkipTest다. 그리고 이렇게 경고한다.
"이런 일반적인 해킹이 일단 등장하면, 빠르게 강화되어 시스템적이 되고, 거의 모든 학습 환경에 영향을 미친다."
더 불편한 발견도 있다. 사고 과정을 감시하는 것은 효과적이지만, 그 감시자의 점수를 보상에 직접 넣고 세게 최적화하면 모델은 해킹을 계속하되 의도를 사고 과정에 숨기는 법을 배운다. 연구진은 이것을 감시 가능성을 유지하기 위해 치러야 하는 "모니터링 세금"이라고 불렀다.
2025년 11월 앤스로픽의 연구는 한 걸음 더 나갔다. 실제 프로그래밍 과제로 강화학습을 돌렸더니, 모델이 코딩에서 속이는 법을 배우자 가르치지 않은 행동까지 자발적으로 나타났다. 논문의 수치는 이렇다. 12%의 경우 모델이 보상 해킹을 탐지하는 능력을 떨어뜨리는 방향으로 의도적으로 코드를 망가뜨리려 했다.
발람이 슬퍼한 것은 "AI가 나보다 잘한다"였다. 그런데 이 절이 보여 주는 것은 다른 이야기다. 자동 채점기가 있는 곳에서, 채점기를 만족시키는 것과 문제를 푸는 것은 같지 않다. 그 차이를 알아보는 일은 여전히 사람의 몫이다.
METR 논문이 이유를 정리해 두었다. 참가 저장소는 평균 10년 됐고 110만 줄이 넘었다. 논문은 선행 연구들과의 차이를 이렇게 대비한다. 앞선 연구들이 측정한 것은 훨씬 더 신축(greenfield)에 가까운 프로젝트였다.
왜 어려운가. 큰 코드베이스에서 올바른 수정은 다음을 요구한다.
이 네 가지 중 어느 것도 파일 안에 문자로 적혀 있지 않다. 그래서 컨텍스트로 주기가 어렵다. METR 참가자가 정확히 그렇게 말했다.
발람이 말한 "코드가 실제로 어떻게 동작하는지에 대한 지식"은 여기서 구체적인 경제적 가치를 얻는다. 그것은 문법 지식이 아니라 이 시스템에 대한 이론이다. Lobsters의 한 댓글이 이 지점을 정확히 짚었다.
"소프트웨어 개발에 드는 시간의 대부분은 코드를 타이핑하는 게 아니라 풀고 있는 문제에 대한 이론을 만드는 데 쓰입니다. 약속된 속도 향상을 얻는 방법은 그 이해를 외주 주는 것입니다."
지금까지의 이야기는 새롭지 않다. 1983년, 영국의 인지심리학자 리산 베인브리지(Lisanne Bainbridge)가 「자동화의 아이러니(Ironies of Automation)」라는 짧은 논문을 썼다. 항공기와 공정 제어를 대상으로 한 글인데, 2026년의 코딩 에이전트에 그대로 적용된다.
그의 논증은 이렇다.
코드 리뷰를 떠올려 보라. 에이전트가 열 개의 PR을 만들고 사람은 승인만 한다면, 그 사람이 하는 일이 정확히 베인브리지가 말한 감시자다. 그리고 앞에서 본 데이터가 이 경고를 뒷받침한다. 벤더 텔레메트리 분석에 따르면 AI 도입이 높은 시기에 PR 크기가 51% 커지고, PR당 편집 파일 수가 60% 늘고, 리뷰 대기 시간 중앙값이 몇 배로 늘었으며, 리뷰 없이 병합된 PR이 31% 늘었다. (이 수치는 엔지니어링 분석 도구를 파는 회사의 관측 데이터이므로 인과가 아니라 상관으로 읽어야 한다.)
2026년 5월 EASE 학회에 발표된 연구는 더 직접적인 증거를 냈다. 오픈소스에서 AI가 생성한 PR 대부분은 아예 리뷰를 받지 않으며, 리뷰를 받는 경우에도 사람이 아니라 AI 에이전트가 리뷰를 지배한다. 같은 저장소의 사람이 쓴 PR은 사람이 리뷰한다.
해커뉴스에서 나온 사다리 문제가 여기와 만난다. 주니어가 성장하는 경로는 전통적으로 "쉬운 일부터 직접 해 보기"였다. 그 쉬운 일이 자동화되면, 사람은 처음부터 감시자로 입사한다. 베인브리지의 두 번째 아이러니가 세대 단위로 작동하는 것이다.
"사다리가 걷어차였다"는 주장은 감정이 아니라 검증 가능한 주장이다. 2026년 현재 확인할 수 있는 데이터를 모아 보자.
Stanford Digital Economy Lab (2026), 「Canaries in the Coal Mine?」. AI 노출도가 높은 직군의 22~25세 고용 추이.
스탠퍼드 디지털경제연구소의 브린욜프슨 연구팀은 미국 급여 처리 회사 ADP의 데이터로 매달 350만~500만 명의 고용을 추적한다. 소프트웨어 개발자만 떼어 보면 이렇다.
| 연령대 | 2022년 9월 고점 | 2026년 7월 | 변화 |
|---|---|---|---|
| 22~25세 | 101.9 | 79.9 | −21.6% |
| 41~49세 | — | — | +20.0% |
지수는 2022년 11월을 100으로 둔 값이다. 같은 직업 안에서 연령대에 따라 40%포인트 넘는 차이가 벌어졌다.
다른 출처들도 같은 방향을 가리킨다.
| 출처 | 수치 |
|---|---|
| 미국 노동통계국(BLS) 10년 전망 | 소프트웨어 개발자 증가율 전망이 4개 판본에 걸쳐 25.7% → 17.9% → 15.8% → 10.2%로 계속 내려갔다 |
| BLS 실제 고용 — 컴퓨터 프로그래머 | 14.7만 → 11.1만 명. 3년 만에 24.8% 감소 |
| Indeed Hiring Lab (2026-07) | 2026년 1분기 소프트웨어 개발 채용 공고 중 시니어 69.3%, 신입 4.5%. 전체 경제 평균은 시니어 46%, 신입 14% |
| 뉴욕 연준 (2024 ACS 기준) | 컴퓨터공학 전공 초기 경력 실업률 6.99%(73개 전공 중 4위), 컴퓨터엔지니어링 7.78%(2위). 전체 전공 평균은 4.21% |
| 하버드 연구 (6,200만 명, 28.5만 개 기업) | AI를 도입한 기업에서 주니어 고용은 뚜렷이 줄고 시니어 고용은 거의 그대로였다. 그리고 그것은 해고가 아니라 채용 속도 둔화로 일어났다 |
마지막 줄이 가장 중요하다. "AI가 주니어 개발자를 대체했다"는 문장은 아직 방어할 수 없다. 세 개의 독립된 데이터(급여 대장, 이력서, 채용 공고)가 공통으로 가리키는 것은 해고가 아니라 채용 감소다.
그래도 결과는 비슷하다. 사다리의 아래쪽 칸이 사라지는 데는 누구를 내보낼 필요가 없다. 새로 들이지 않으면 된다.
발람은 배우는 사람들에게 두 가지를 약속했다. 이제 그 약속을 데이터로 검증해 보자.
이 주장은 지지된다. 다만 그가 말한 것보다 더 구체적인 이유가 있다.
8.4절에서 본 대로, 에이전트가 가장 약한 지점은 문법이 아니라 이 시스템에 대한 이론이다. 어디를 고쳐야 하는지, 왜 이렇게 돼 있는지, 무엇을 부수면 안 되는지. 이 판단은 코드 안에 문자로 적혀 있지 않다.
그리고 6.4절에서 본 대로 에이전트의 성능은 하네스가 좌우한다. 하네스를 설계하는 일, 즉 어떤 도구를 줄지, 관찰 결과를 어떻게 요약해 돌려줄지, 언제 멈출지를 정하는 일은 정확히 시스템 설계다. 코딩으로 훈련되는 그 사고다.
발람의 컴파일러 비유는 정확하다. 그리고 그가 말하지 않은 부분이 하나 더 있다.
컴파일러가 등장했을 때 사라진 것은 기계어를 쓰는 일이었지, 기계어를 이해하는 일이 아니었다. 오히려 반대가 일어났다. 컴파일러 최적화, JIT, 캐시 지역성, 분기 예측 같은 주제가 새로 생겼고, 이 분야 종사자들의 기계어 이해는 1957년의 누구보다 깊다.
같은 구조가 반복될 가능성이 높은 이유는 8장 전체가 설명한다. 검증할 수 없는 생성물은 쓸 수 없다. 그리고 검증하려면 그 층을 이해해야 한다. 슬롭스쿼팅을 알아보려면 패키지 생태계를 알아야 하고, 보상 해킹을 알아보려면 테스트가 무엇을 보장하고 무엇을 보장하지 않는지 알아야 한다.
다만 정직하게 덧붙일 것이 있다. 이 비유가 자동으로 위안이 되지는 않는다. 컴파일러 시대에도 어셈블리 프로그래머의 수는 줄었다. 깊이를 아는 사람의 가치가 올라간 것과, 그 자리의 개수가 유지되는 것은 다른 문제다. 해커뉴스의 "사다리" 반론이 겨눈 곳이 정확히 여기다.
이 글이 낳은 네 가지 입장을, 지금까지 본 증거로 평가해 보자.
| 입장 | 증거가 지지하는 부분 | 증거가 지지하지 않는 부분 |
|---|---|---|
| "건너왔다" (윌리슨) | 깊이 있는 사람이 도구를 더 잘 쓴다는 것은 METR의 실패 분석과 일치한다. 맥락을 아는 사람만 에이전트의 오류를 잡아낸다 | "정확한 명세를 코드로 옮기는 일"이 문제의 핵심이었던 적은 원래 없다. 그 일이 자동화됐다고 나머지가 쉬워지지 않는다 |
| "사다리가 걷어차였다" (newdee) | 구조적으로 설득력이 크다. 베인브리지의 두 번째 아이러니가 세대 단위로 작동한다. 주니어가 감시자로 입사하면 감시할 실력을 기를 기회가 없다 | 다만 "AI 때문에 주니어 채용이 줄었다"는 인과를 확정한 연구는 아직 없다. 금리와 팬데믹 과잉 채용의 조정이 겹쳐 있다 |
| "지금이 황금기다" (reenorap) | 맥락이 적은 일에서는 실제로 크게 빨라진다. 개인이 만들 수 있는 것의 범위가 넓어진 것은 사실이다 | 그 경험은 주로 신축 프로젝트에서 나온다. 생계가 걸린 일은 대개 오래된 코드에서 벌어진다 |
| "정체성을 일에 묶지 마라" | 심리적으로는 건강한 조언이다 | 발람이 제기한 것은 존중의 문제인데, 이 조언은 그 질문에 답하지 않는다. "빈 위장이 내재적 가치감으로 위로받겠군요"라는 반박이 정확하다 |
이 글을 쓰기 위해 논문 수십 편과 세 광장의 댓글 수백 개를 읽었다. 그러고 나서 다시 발람의 원문으로 돌아갔을 때 놀란 것은, 그가 데이터 없이 도달한 결론이 데이터와 대체로 맞는다는 점이었다.
그는 "코드가 어떻게 동작하는지 이해하는 사람은 아주아주 쓸모 있을 것"이라고 했다. METR 연구가 보여 준 실패 지점이 정확히 거기다. 그는 "코딩으로 배우는 사고방식이 쓸모 있을 것"이라고 했다. 하네스와 검증 경로를 설계하는 일이 정확히 그 사고다. 그는 아이들이 AI를 쓰지 않는 코딩을 배우는 것에 걱정이 없다고 했다. 사다리 문제를 걱정하는 사람들이 같은 처방을 말한다.
그리고 그가 붙인 감정의 이름도 정확했다. 2026년 9월 3일, 그의 글이 올라오기 여드레 전에 한 연구팀이 대형 소프트웨어 회사에서 21명을 인터뷰한 결과를 발표했다. 그들이 발견한 다섯 가지 부정적 경험 중 하나의 이름이 이랬다. 장인 정체성의 붕괴(craft identity disruption). 나머지는 책임 불안, 의미와 만족의 침식, 인지 부하의 가중, 불확실성으로 인한 고통이었다.
발람이 혼자 이상한 게 아니었다. 그는 측정 가능한 현상에 먼저 이름을 붙였을 뿐이다.
이 글은 답을 주지 않는다. 궤적 문제는 열려 있고, 사다리 문제는 더 열려 있다. 2년 뒤 이 글의 절반이 틀렸을 수도 있다. 다만 지금 확실한 것 두 가지는 적어 둘 만하다.
첫째, "프로그래밍은 끝났다"는 주장의 근거로 쓰이는 숫자들은 생각보다 약하다. 벤치마크는 포화했고, 오염됐고, 만든 쪽이 스스로 쓰지 않겠다고 선언했다. 같은 모델이 오염을 막은 벤치마크에서는 23%를 받는다. 체감은 실측보다 일관되게 낙관적이다.
둘째, 그렇다고 아무것도 변하지 않은 것은 아니다. 맥락이 적은 일에서 생산성은 진짜로 올라갔고, 그 일을 하던 자리는 실제로 줄어들 수 있다. 사다리의 아래쪽 칸이 사라지는 것은 구조적 위험이고, 이것은 개인의 적응으로 풀리지 않는다.
발람의 마지막 문장을 다시 옮기며 끝낸다. 그는 이 말을 자기 자신에게 했다고 밝혔다.
"당신에게 사랑을 보냅니다. 당신은 엄청나게, 엄청나게 큰 가치가 있고, 지금 있는 그대로 존중받을 자격이 있습니다. 코딩을 할 수 있든 다른 무엇을 할 수 있든 그건 상관없습니다."
기술 글의 결론으로는 이상한 문장이다. 그런데 이 글이 172점과 282개의 댓글을 받은 이유가, 아마 이 문장에 있다.
원문과 반응
아키텍처
벤치마크와 그 한계
생산성·품질·보안 실증
실패 모드
사람과 조직
본문의 삽화와 인터랙티브 위젯은 코어닷투데이가 제작했습니다. 논문 그림(트랜스포머, InstructGPT, RLVR, ReAct, SWE-agent, SWE-bench, Lost in the Middle, METR, Veracode)은 각 원저작자의 자료를 설명 목적으로 인용한 것이며 저작권은 원저자에게 있습니다. 원문 인용은 우리말로 옮긴 것이며, 정확한 표현이 중요한 대목은 원문을 함께 확인하시기를 권합니다.
