컴파일러도 프로그래밍을 끝낼 것이라고 예상되었다: 2026년 데이터가 AI 코딩 에이전트에 대해 말하는 것

요약

AI 코딩 에이전트는 프로그래밍을 끝내지 않을 것이다. 그들은 1957년 FORTRAN이 수식 번역을 자동화한 것과 같은 방식으로 프로그래밍의 또 다른 층을 자동화할 것이다. 이것은 hrih.si에 게시되고 Hacker News에 제출되어 150포인트와 197개의 댓글을 얻은 널리 논의된 에세이의 주장이다. 에세이 자체의 증거는 양방향으로 작용한다: AI 코딩 도구의 채택은 2023년 개발자의 70%에서 2025년 84%로 증가했지만, 긍정적 반응은 같은 기간 77%에서 60%로 하락했으며, METR의 무작위 대조 시험에서는 경험 많은 개발자가 자신의 저장소에서 AI를 사용할 때 19% 더 오래 걸리면서도 20% 더 빠르다고 믿는 것으로 나타났다.

에세이의 핵심 주장은 소프트웨어 작업의 병목이 코드 작성에서 코드 검토로 이동했으며, 프로그래밍의 어려운 부분—무엇이 존재해야 하는지 결정하는 것—은 여전히 인간의 작업이라는 것이다. Hacker News 댓글 작성자들은 컴파일러 비유를 대체로 거부하며, 컴파일러는 정확한 입력에서 정확하고 반복 가능한 출력을 생성하지만 LLM은 그렇지 않다고 주장했다.

1954년 FORTRAN 보고서는 코딩과 디버깅을 제거하겠다고 약속했다

1954년 11월 10일, IBM의 프로그래밍 연구 그룹은 FORTRAN이라는 새 언어에 대한 예비 보고서를 완성했다. 보고서는 FORTRAN이 "코딩과 디버깅을 사실상 제거"할 것이며 문제가 그것 없이 작업하는 비용의 "절반 미만"으로 해결될 것이라고 명시했다. 그 시대의 어셈블러와 컴파일러는 통칭 자동 프로그래밍이라고 불렸다.

FORTRAN은 1957년에 출시되었다. 그것은 한 종류의 코딩을 제거했다—이제 거의 아무도 수식을 기계 명령어로 수동 번역하지 않는다—하지만 디버깅은 살아남았다. 에세이의 저자는 자신의 프로젝트에서 12시간마다만 저장되는 북마크로 거슬러 올라가는 버그를 쫓는 일에 대해 언급한다.

에세이가 식별한 패턴은 일관적이다: 무언가가 자동화되면, 그 일을 하던 사람들은 수동으로 그 일을 중단하고, 분야는 계속 성장한다. GitHub의 2025년 보고서는 1억 8천만 명 이상의 개발자를 집계했으며, 지난 12개월 동안 3천 6백만 명 이상이 합류했다.

에세이가 제시하는 추상화의 사다리

에세이는 프로그래머의 업무에서 무언가를 제거한 각 단계의 타임라인을 제시한다:

1947 — 어셈블리 언어. 프로그래머는 원시 숫자로 명령어를 작성하는 것을 중단했다. Kathleen Booth의 "Coding for A.R.C."에 기인.
1957 — FORTRAN. 프로그래머는 수식을 기계 명령어로 수동 번역하는 것을 중단했다.
1972 — C. 프로그래머는 새로운 기계마다 같은 프로그램을 다시 작성하는 것을 중단했다.
1981 — The Last One. 영국 회사 D.J. "AI" Systems의 BASIC 프로그램 생성기로, 마지막으로 구매할 프로그램이 될 것이라는 전제로 판매되었다. 검토자들은 일부 비즈니스 프로그램에 유용하다고 평가했다. 그것은 마지막이 아니었다.
2008 — Stack Overflow. 프로그래머는 모든 오류 메시지를 혼자 해결하는 것을 중단했다.
2010 — npm. 프로그래머는 모든 것을 직접 작성하는 것을 중단했다.
2021 — GitHub Copilot. 프로그래머는 상용구를 입력하는 것을 중단했다.
2025 — 코딩 에이전트. 프로그래머는 대부분의 코드를 입력하는 것을 중단했다.

에세이는 이 단계가 다른 단계와 종류가 아니라 속도에서 다르다고 주장한다: GitHub Copilot의 미리보기는 2021년 6월에 출시되었고, 2025년에는 Stack Overflow 설문조사의 개발자 84%가 AI 도구를 사용하거나 사용할 계획이었다. 신기함에서 기본이 되기까지 4년.

2026년 데이터가 실제로 보여주는 것

채택률은 높고 반응은 그렇지 않다. 에세이에서 인용된 가장 큰 정기 점검인 Stack Overflow 개발자 설문조사는 2023년 AI 도구를 사용하거나 사용할 계획인 개발자가 70%에서 2025년 84%로 증가했으며, 전문 개발자의 절반이 매일 사용한다고 보고했다. 긍정적 반응은 반대 방향으로 움직여 2023년 77%에서 2025년 60%로 하락한 후 2026년 62%로 소폭 상승했다.

2025년에는 AI 출력의 정확성을 신뢰하지 않는 개발자(46%)가 신뢰하는 개발자(33%)보다 많았다. 응답자의 66%가 선택한 가장 많이 선택된 불만은 "거의 맞지만 완전히 맞지 않는 AI 솔루션"이었다. 45%는 AI 생성 코드를 디버깅하는 데 더 오래 걸린다고 말했다.

에세이는 방법론적 주의 사항을 언급한다: 2026년 Stack Overflow 설문조사는 "사용 또는 계획" 질문을 제거하고 신뢰 질문을 다시 작성하여 두 추세선이 2025년에 중단된다. 2023년에는 약 90,000명의 개발자가 응답했고 2026년에는 30,000명 이상이 응답했다.

Andrej Karpathy는 2025년 2월 "바이브 코딩"이라는 용어를 만들어 "바이브에 완전히 굴복하는" 관행을 설명했다. Stack Overflow가 그 해에 이에 대해 물었을 때, 개발자의 72%가 그것이 자신의 전문 업무의 일부가 아니라고 말했고, 추가로 5%는 단호하게 아니라고 말했다.

METR의 무작위 시험: 빠르게 느끼는 것은 측정이 아니다

에세이는 METR의 2025년 무작위 대조 시험을 AI 붐에 대한 가장 좋아하는 연구라고 부른다. 열여섯 명의 경험 많은 오픈 소스 개발자가 자신의 저장소—수년 동안 작업해온 프로젝트—에서 246개의 실제 이슈를 작업했으며, 각 이슈는 AI 도구를 허용하거나 금지하도록 무작위로 할당되었다.

시작 전에 개발자들은 AI가 시간을 24% 단축할 것으로 기대했다. 완료 후에는 시간이 20% 단축되었다고 믿었다. 시계는 AI로 19% 더 오래 걸렸음을 보여주었다. 둔화 폭은 2%에서 39% 사이로 넓다. 설정은 주로 Cursor와 Claude 3.5 및 3.7 Sonnet이었다. 논문의 전문가 예측은 훨씬 더 낙관적이었다: 경제학자들은 39% 시간 단축을 예측했고 ML 연구자들은 38% 시간 단축을 예측했다.

METR은 2025년 8월부터 57명의 개발자와 800개 이상의 작업으로 더 큰 복제를 시도했다. 2026년 2월, METR은 데이터가 신뢰하기에는 너무 부정확하다고 말했는데, 주로 개발자들이 "AI 없이 일하고 싶지 않다"며 참여를 계속 거부했기 때문이다. 초기 수치는 복귀 개발자에게 18%의 속도 향상을 암시했지만, 속도 향상이 전혀 없을 수도 있는 넓은 범위를 포함했다.

에세이의 핵심은 의도적으로 좁다: 얼마나 빠르게 느끼는지는 측정이 아니다. AI가 자신을 더 빠르게 만드는지 알고 싶은 팀은 다른 모든 것을 측정하는 방식으로 측정해야 한다.

METR의 시간 지평 곡선: 약 6개월마다 두 배

METR의 또 다른 주요 프로젝트는 AI 에이전트가 스스로 완료할 수 있는 작업의 길이를 추적한다. 이 방법은 인간 전문가가 일련의 소프트웨어 작업에 걸리는 시간을 측정한 다음 에이전트가 절반의 시간에 성공하는 작업 길이를 찾는다.

2019 — GPT-2: 사람이 약 3초 걸리는 작업.
2023 — GPT-4: 약 4분.
2025년 2월 — Claude 3.7 Sonnet: 1시간.
1년 후 — Claude Opus 4.6: 약 12시간.

시리즈 전반에 걸쳐 이 숫자는 약 6개월마다 두 배가 되었다; 2023년 이후로는 약 4개월마다. METR은 현재 작업으로는 16시간 이상이 신뢰할 수 없다고 명시하므로, 5월의 Claude Mythos Preview에 대한 17시간 측정은 선에 표시되지 않는다. METR은 9월에 페이지 업데이트를 중단했다.

에세이는 이 예측의 한계에 대해 명시적이다: "절반의 시간"은 정의에서 많은 역할을 하며, 벤치마크 작업은 실제 코드베이스보다 더 깨끗하고, 점선이 있는 로그 스케일 차트는 많은 나쁜 예측이 시작되는 방식이다. 추세가 대략적으로라도 계속된다면 에이전트는 약 2028년에 한 달치 인간 작업을 절반의 시간에 처리할 것이다.

실험실들이 자신의 코드에 대해 보고하는 것

Google은 2024년 10월에 새로운 코드의 4분의 1 이상이 AI로 생성되었고, 6개월 후에는 "30%를 훨씬 넘는" 비율이라고 말했다.
2025년 3월, Anthropic의 Dario Amodei는 AI가 3~6개월 안에 코드의 90%를 작성할 것이라고 예측했다. 에세이는 너무 이르다고 지적했다.
2026년 5월까지 Anthropic은 자체 코드베이스에 병합된 코드의 80% 이상이 Claude에 의해 작성되었다고 말했다.

코드가 저렴해지면, 대기열은 검토로 이동한다

에세이의 핵심 메커니즘은 대기열 주장이다: 프로세스의 한 단계를 빠르게 하면 작업이 다음으로 느린 단계 앞에 쌓인다. Faros AI의 원격 측정 데이터가 이를 뒷받침한다.

2025년, Faros AI는 1,255개 팀의 10,000명 이상의 개발자로부터 원격 측정 데이터를 살펴보았다. AI 채택률이 높은 팀의 개발자는 21% 더 많은 작업을 완료하고 98% 더 많은 풀 리퀘스트를 병합했지만, 검토 시간은 91% 증가했다.

Faros는 2026년에 22,000명의 개발자로 분석을 다시 실행했다. 개발자당 작업 완료는 34% 증가했지만, 중앙값 검토 시간은 5배 증가했고, 검토 없이 병합되는 풀 리퀘스트는 31% 더 많았으며, 풀 리퀘스트 대비 인시던트 비율은 3배 이상 증가했다.

품질 데이터도 같은 방향을 가리킨다:

Veracode는 2025년에 80개의 코딩 작업에서 100개 이상의 언어 모델을 테스트했고, 결과의 45%에 보안 결함이 있었다.
GitClear는 복사-붙여넣기된 줄이 2021년 변경된 코드의 8.3%에서 2024년 12.3%로 증가한 반면, 리팩토링으로 생성된 이동된 코드는 약 4분의 1에서 10% 미만으로 감소했다는 것을 발견했다.
curl을 이끄는 Daniel Stenberg는 2025년 5월 "AI 슬롭" 버그 보고서를 제출하는 사람들을 차단하기 시작했으며, 프로젝트가 "사실상 DDoS 공격을 받고 있다"고 썼다. 2026년 1월, curl은 버그 현상금을 중단했다.

Fred Brooks는 이미 1986년에 문제를 나누었다

에세이는 Fred Brooks의 1986년 논문 "No Silver Bullet"에 주장을 근거로 두며, 아리스토텔레스의 용어를 빌려 소프트웨어의 어려움을 두 가지로 나눈다. 우연적 어려움은 우리 도구가 일으키는 문제다: 구문, 상용구, 빌드와의 싸움. 본질은 "이 개념적 구성물의 명세, 설계, 테스트"—무엇을 해야 하는지 알아내는 작업이다.

에세이의 본질에 대한 설명은 새벽 2시 13분에 멈춰 진행하는 대신 질문을 하는 가상의 에이전트다:

명세서는 환불이 원래 카드로 돌아간다고 말합니다. 이 고객의 카드는 3월에 만료되었습니다. 어떻게 해야 할까요?

에이전트는 하루 종일 환불 코드를 작성할 수 있지만, 카드가 만료된 고객에게 회사가 무엇을 빚졌는지 결정할 수는 없다. AI는 우연적 어려움에 매우 능숙해지고 있다. 본질은 여전히 인간의 책상 위에 있다.

주니어 채용 붕괴는 에세이가 가장 싫어하는 부분이다

2025년 8월, Erik Brynjolfsson과 스탠포드 디지털 경제 연구소의 동료 두 명은 ADP 급여 데이터를 사용하여 누가 채용되고 있는지 조사했다. 22세에서 25세 사이의 소프트웨어 개발자 고용은 2022년 말 최고치보다 거의 20% 감소했다. 나이든 개발자는 눈에 띄는 변화를 보이지 않았다.

다음 해 8월에 발표된 업데이트(2026년 6월까지의 데이터)는 AI에 노출된 일자리의 젊은 근로자가 덜 노출된 동료보다 19% 낮은 수준임을 발견했다. 경험 많은 근로자는 상당한 격차를 보이지 않았다. 대부분의 효과는 회사가 처음부터 더 적은 수의 젊은 사람을 고용하는 데서 비롯된다.

Indeed의 소프트웨어 개발 직업 게시물 지수는 2025년 5월 39% 하락한 저점을 기록한 후, 2020년 2월보다 약 21% 낮은 수준이다. 에세이는 스탠포드 저자들이 자신들의 발견을 인과적이 아닌 기술적이라고 부르며, 다른 요인들이 작용하고 있다고 지적한다: 금리가 상승했고, 많은 회사가 팬데믹 기간 동안 과잉 채용했다—Indeed의 지수는 2022년 초 2020년 수준의 두 배 이상으로 정점을 찍었다.

에세이의 우려는 견습이다. 시니어 엔지니어는 직장에서 만들어진다. 대부분 실제 팀에서 주니어로 일하면서: 지루한 티켓을 처리하고, 프로덕션을 한 번 망치고, 누군가 친절하게 이유를 설명해주는 것이다. 에이전트가 지루한 티켓을 가져가면, 다음 시니어 엔지니어는 어디서 오는가? 에세이는 코드를 많이 작성해본 적이 없다면 코드를 잘 검토하기 어렵다고 지적한다. 제안하는 답은 다른 종류의 견습이다—옆에 시니어와 함께 에이전트 작업을 검토하고, 작은 시스템 하나를 처음부터 끝까지 소유하며, 에이전트가 구축할 명세와 테스트를 작성하는 것이다.

2031년을 위한 다섯 가지 추측

에세이는 명시적인 예측으로 끝나며, 다시 검토될 추측으로 간주한다:

팀은 더 작아지고, 훨씬 더 많아진다. Y Combinator의 Jared Friedman에 따르면, Winter 2025 배치의 4분의 1은 코드베이스가 약 95% AI 생성이었다. 2월에 Block은 약 4,000개의 일자리를 삭감했고, Jack Dorsey는 AI 도구와 "더 작고 평평한 팀"을 지적했다. 에세이는 여전히 전반적으로 소프트웨어 일자리가 줄어들 것으로 기대하지 않으며, 미국 노동통계국의 2025년부터 2035년까지 소프트웨어 개발자, QA 분석가 및 테스터의 10% 성장 예측을 인용하고, Jevons 역설을 언급한다—William Stanley Jevons는 1865년에 더 효율적인 증기 기관이 영국이 더 많은 석탄을 태우게 만들 것이라고 주장했다.
명세와 테스트가 소스가 된다. 코드는 컴파일러의 출력과 더 비슷해진다: 검사할 수는 있지만, 수동으로 편집되는 경우는 드물다.
한 명의 청중을 위한 소프트웨어. 작동하는 도구가 분기가 아닌 저녁 하나의 비용이 들 때, 사람들은 오늘날 스프레드시트를 만드는 것처럼 소프트웨어를 만들 것이다.
코드 읽기가 직업이 된다. 에세이는 채용 공고에 "검증 엔지니어"와 같은 직업이 나타나고, 검토자에게 기록, 위험한 줄, 에이전트가 작성하지 않은 테스트를 보여주는 도구가 등장할 것으로 기대한다.
모든 변경에는 라벨이 붙는다. 풀 리퀘스트는 누가 또는 무엇이 작성했는지, 누가 확인했는지, 무엇이 검증되었는지를 일상적으로 명시할 것이다.

Hacker News 반론: 컴파일러는 LLM이 아니다

토론에서 가장 반복된 반대는 컴파일러 비유가 결정론에서 실패한다는 것이다. 한 댓글 작성자가 말했듯이:

컴파일러는 정확한 입력을 받아 정확한 출력을 반복적으로 생성할 것으로 기대됩니다. LLM이 그렇게 할 수 있다면 컴파일러일 것이고, 우리는 이 논의를 하지 않을 것입니다.

또 다른 사람은 차이를 번역이 아닌 저작으로 보았다:

내가 소설을 쓰고, 누군가 프랑스어로 번역해 출판한다면, 그것은 컴파일러입니다. 내가 간단한 메모를 누군가에게 건네주고 그 사람이 나를 위해 소설을 쓴다면, 그것이 LLM입니다. 이것들은 근본적으로 다른 것들입니다.

세 번째 사람은 변화의 범위가 프로그래밍보다 더 넓다고 주장했다:

컴파일러에는 (대략, 최적화를 제외하고) 입력과 출력 사이에 1:1 대응이 있습니다. LLM을 사용하면 아이디어를 가져와 처음부터 끝까지 전체를 이끌어낼 것입니다. 이것은 우리가 지금까지 해온 것과는 다릅니다. 프로그래밍에 초점을 맞추는 것도 이상합니다: LLM은 모든 정보 관련 직업에 다가오고 있습니다.

역사적 수정: "코딩"은 에세이가 암시하는 것을 의미하지 않았다

여러 댓글 작성자는 1954년 FORTRAN 인용문이 맥락에서 벗어나 읽히고 있다고 주장했다. 한 사람은 코딩이라는 단어가 원래 종이에 쓴 추상 프로그램을 기계 코드로 번역하는 것을 의미했으며, 컴파일러가 처음에 자동 코더라고 불렸다고 설명했다:

컴파일이라는 단어는 링킹과 더 비슷한 것을 의미했습니다: 여러 라이브러리 루틴을 포함하는 이미지를 생성하는 것. 즉, 작품 모음을 책으로 편집하는 것과 유사합니다. 컴파일러 이후, 코딩이라는 단어는 어떤 언어로든 프로그램 코드를 작성하는 것으로 바뀌었습니다. [...] 용어가 재편되는 동안, 구체적인 현실은 단순히 사람들이 어셈블리 언어로 덜 일했을 뿐, 더 적은 사람들이 일하거나 프로그래밍이 끝난 것은 아니었습니다.

또 다른 댓글 작성자는 FORTRAN에 대해 같은 지적을 하며, 그것이 수학 표기법을 옮기는 것으로 간주되었고 코딩으로 여겨지지 않았다고 언급하고, IBM 펠로우 Iverson의 표기법을 사고 도구로 다룬 튜링 상 강연을 인용했다.

"충분히 정확한 명세는 코드다" 반대

한 댓글 작성자는 에세이의 명세와 테스트가 진실의 원천이 된다는 예측에 반박했다:

충분히 정확한 명세는 코드라고 불립니다. 이것은 다시 컴파일러 이야기입니다.

같은 댓글 작성자는 비주얼 프로그래밍과 빠른 애플리케이션 개발—Visual Basic이 대표적인 예—이 1990년대에 유행했음에도 에세이의 타임라인에 없다고 지적하고, 모든 프로젝트가 어떤 면에서 고유하기 때문에 기성 구성 요소가 거의 맞지 않고 코드가 의도를 표현하는 가장 정확한 방법으로 남아 있다고 주장했다. 그 관점에서 AI는 다른 사람들이 이미 한 것을 원할 때—재작성, 포팅, 역컴파일—가장 효과적이며, 이는 프로그래밍이 아닌 번역 작업이다.

관련 댓글은 비유에 동의하지만 한 가지 주의를 덧붙였다: "유지보수 가능한 코드를 바이브 코딩하려면 LLM에 명세를 제공해야 합니다. 여전히 코딩이지만, 이제 구문에 대해 걱정하는 대신 명세만 제공할 자유가 있습니다. 비결정적이고 사기치기를 좋아하기 때문에 여전히 검토는 필요합니다."

토론의 다른 주제들

한 댓글 작성자는 컴파일러 비유가 이미 실제로 입증되었다고 관찰했다: "우리는 이제 거의 컴파일러만 사용합니다. 문제를 수정하기 위해 디스어셈블리를 읽은 것은 적어도 10년 전이 마지막이었습니다."
또 다른 사람은 그 변화를 터미널의 도입과 비교했는데, 이는 프로그래밍을 공용 컴퓨터실에서 독방 사무실로 옮겼고, 터미널 이전에는 많은 프로그래머가 여성이었지만 이후 떠났다고 언급했다.
한 댓글 작성자는 직업이 디자인으로 좁혀질 것이라고 예측했다: "우리 아이들 세대에 프로그래머가 되는 것은 구두 수선공이 되는 것처럼 보일 것입니다. 사람들은 여전히 신발을 신고 신발 만드는 데 관여할 것입니다. 하지만 일자리는 대량 생산이 아니라 디자인에 있을 것입니다."
더 직설적인 평가: "나는 이것이 슬픔의 과정에서 협상 단계라고 생각합니다."
한 댓글 작성자는 에세이의 가상 전제가 빨리 낡을 수 있다고 지적하며, 새벽 2시 13분 환불 질문에 대해 "2031년: 왜 안 되는가?"라고 응답했다.
또 다른 댓글 작성자는 에이전트와 야간 작업을 검토하는 일일 화상 통화를 운영한다고 설명하고, 모델에 목소리, 몸, 예절 지침을 제공하는 개인 프로젝트를 연결했다.

댓글에서 제기된 출처 주의 사항

한 댓글 작성자는 에세이를 호스팅하는 블로그가 AI로 작성된 책을 마케팅할 목적으로 출판 직전에 만들어졌다고 주장하며, 약력 페이지에 있는 자리 표시자 텍스트("샘플 소개 · 이것을 개인 약력으로 교체하십시오.")를 지적하고, 저자가 글을 쓰는 데 AI가 얼마나 사용되었는지 질문하자 Reddit에서 차단했다고 주장했다. 같은 댓글 작성자는 에세이의 과학적 출처가 환각보다는 잘 연구된 것처럼 보였다고 인정했다. 이 주장은 검증되지 않았으며 발견 사항이 아니라 댓글로 여기에 보고된다.

결론

에세이의 결론은 FORTRAN이 코더를 제거하지 않고 한 종류의 코딩을 제거했으며, AI가 같은 일을 더 빠르고 더 지저분하게 한다는 것이다. 그것의 서술에서, 2031년의 개발자는 하루를 보내며 무엇이 존재해야 하는지 결정하고, 기계가 구축할 수 있을 만큼 명확하게 설명하고, 돌아온 것이 올바른지 확인한다—항상 어려운 부분이었고, 프로그래머가 타이핑하느라 이전에는 시간이 없었던 작업이다.

이 글에서 가장 강력한 증거는 비유가 아니라 측정 격차이다: METR의 개발자들은 AI가 20% 더 빠르게 만들었다고 믿었지만 시계는 19% 더 느리다고 말했고, Faros AI의 원격 측정은 풀 리퀘스트 볼륨이 대략 두 배가 되는 동안 검토 시간이 5배 증가했음을 보여준다. 컴파일러 비교가 성립하는지 여부와 관계없이, 대기열은 눈에 띄게 이동했다.