프로그래밍은 1954년부터 죽어왔다. AI가 마침내 변화시킬 수 있을까?

2031년 화요일 아침 7시 40분, 당신은 아직 코드를 한 줄도 작성하지 않았습니다. 아마 오늘 하루 종일 그러지 못할 것이고, 괜찮습니다.

당신이 잠든 사이, 네 개의 에이전트(agents)가 어제 오후에 정리했던 백로그를 처리했습니다. 그중 세 개는 작업을 완료했습니다. 이들의 풀 리퀘스트(pull requests)가 당신을 기다리고 있으며, 각각 테스트 코드, 기능 작동의 짧은 녹화 영상, 그리고 확신하지 못하는 부분에 대한 메모가 첨부되어 있습니다. 네 번째 에이전트는 새벽 2시 13분에 멈추고 대신 질문 하나를 남겼습니다:

사양(spec)에는 환불액이 원래 카드로 돌아간다고 되어 있습니다. 그런데 이 고객의 카드는 3월에 만료되었습니다. 어떻게 처리해야 할까요?

그 에이전트는 하루 종일 환불 코드를 작성할 수 있습니다. 하지만 자신의 회사가 카드가 만료된 고객에게 무엇을 빚지고 있는지 결정할 수는 없기 때문에, 작업을 멈추고 질문을 던졌습니다. 이는 마치 신입 사원에게 바라는 정확한 모습입니다. 당신의 아침은 이런 식으로 흘러갑니다. 세 개의 풀 리퀘스트를 읽고, 지원팀(support)에 가서 누군가와 이야기를 나누고, 아무도(인간이든 기계든) 다시 추측할 필요가 없도록 규칙을 명확하게 문서화하는 것입니다.

2031년의 가상의 하루. 에이전트들은 밤과 오후 동안 작업하고; 인간은 검토하고, 질문 하나에 답하며, 규칙을 문서화하고 다음 날 밤 계획을 세웁니다. (hrih.si의 대화형 그림)

어쨌든 크기에 맞춰 그린 가상의 하루입니다. 빨간색 표시는 오직 사람이 기다리느라 작업이 멈춘 시간만을 나타냅니다.

제가 그 화요일을 꾸며낸 것입니다. 하지만 이것은 공상 과학 소설이 아닙니다. 밤새 사람의 개입 없이 작동하는 에이전트는 오늘날 존재하며, 그중 하나는 매일 밤 열 시에 제 컴퓨터에서 실행됩니다. 이 에이전트는 작은 프로젝트를 발명하고, 구축하고, 테스트하며, 저는 아침 식사 시간에 그것이 무엇을 만들었는지 알게 됩니다. 처음에는 제가 무엇을 만들어냈는지 전혀 알지 못했습니다. 그 결과물이 바로 Rule Safari이며, 이 사이트에 라이브 프로젝트로 존재하며 작동 방식에 대한 기사가 함께 있습니다.

그렇다면 이것이 프로그래밍의 끝일까요? 사람들은 70년 넘게 그런 질문을 던져왔습니다. 저는 그것이 위안이 되기도 하고, 동시에 약간 의심스럽기도 합니다.

프로그래밍은 1954년부터 끝나고 있었다

1954년 11월 10일, IBM의 프로그래밍 리서치 그룹(Programming Research Group)은 FORTRAN이라는 새로운 언어에 대한 예비 보고서를 완성했습니다. 그 보고서에는 FORTRAN이 "코딩과 디버깅을 사실상 제거해야 한다"는 문장이 있었습니다.

저는 이 문장이 좋습니다. 너무나 확신에 차 있었고, 심지어 예산까지 제시했습니다. FORTRAN 없이 할 때보다 "절반도 안 되는 비용"으로 문제를 해결할 수 있다는 것이었죠. 당시 업계는 이런 종류의 것을 부르는 이름이 있었습니다. 어셈블러(Assemblers)와 컴파일러(compilers)는 *자동 프로그래밍(automatic programming)*이라고 불렸습니다. 원하는 바를 설명하면 기계가 프로그램을 작성해 주었습니다.

FORTRAN은 1957년에 출시되었고, 실제로 한 종류의 코딩을 제거했습니다. 이제는 거의 아무도 수식을 손으로 기계어 명령어로 번역하지 않습니다. 디버깅(Debugging)은 아주 잘 살아남았습니다. (이번 달에는 12시간마다만 저장되는 북마크 때문에 발생한 Scry 버그를 추적했기 때문에, 디버깅이 여전히 활발하다는 것을 확인할 수 있었습니다.)

FORTRAN이 실제로 한 일은 지루한 작업 중 일부를 제거하고 그 작업을 다음 단계로 끌어올린 것입니다. 사람들은 레지스터(registers)에 대해 생각하는 것을 멈추고 더 큰 문제들에 대해 생각하기 시작했습니다. 프로그램 작성 비용이 저렴해졌기 때문에, 모두가 더 많은 프로그램을 원하게 되었습니다. 그리고 이 일은 이후 계속 반복되어 왔습니다.

매 단계마다 프로그래머의 짐을 일부 덜어주었습니다. 점선으로 된 것은 등반이 끝났다고 약속했습니다.

제가 가장 좋아하는 단계는 1981년입니다. D.J. "AI" Systems라는 영국 회사가 'The Last One'이라는 BASIC 프로그램 생성기를 판매했습니다. 그 이름 자체가 전체 마케팅 포인트였습니다. 이 프로그램이 모든 프로그램을 대신 작성해 줄 것이므로, 구매할 필요가 있는 마지막 프로그램일 것이라고 홍보한 것입니다.

검토자들은 이를 일부 비즈니스 프로그램에 유용하다고 여겼습니다. 하지만 그것이 끝은 아니었습니다.

모든 단계에서 패턴이 있습니다. 무언가가 자동화되고, 작업을 수행하던 사람들은 그 일을 손으로 하는 것을 멈추지만, 이 분야는 어쨌든 계속 성장합니다. GitHub은 2025년 보고서에서 1억 8천만 명 이상의 개발자를 집계했으며, 그중 3,600만 명이 지난 12개월 동안 가입했습니다.

따라서 저는 AI가 프로그래밍을 끝낸다고 생각하지 않습니다. 다만, 이 단계는 한 가지 면에서 다르다고 생각하는데, 바로 속도입니다. GitHub Copilot의 프리뷰 버전은 2021년 6월에 출시되었습니다. 그리고 2025년에는 Stack Overflow의 설문조사 응답자 중 84%가 AI 도구를 사용하거나 사용할 계획이라고 답했습니다. 단 4년 만에 신기한 것에서 기본(default)이 되었습니다.

실제 2026년의 모습

현재 분위기가 매우 뜨거우니, 수치부터 시작하겠습니다. (분위기에 대해 말하자면: Andrej Karpathy는 2025년 2월에 “vibe coding”이라는 용어를 만들었는데, 이는 코딩할 때 ‘분위기(vibes)에 완전히 몸을 맡기는’ 종류의 코딩을 의미합니다. Stack Overflow가 그해 이 질문을 했습니다. 개발자 중 72%는 이것이 자신의 전문적인 업무 일부가 아니라고 답했고, 또 다른 5%는 단호하게 아니라고 답했습니다. 저는 그들이 그 선택지를 제공했다는 점이 좋습니다.)

Stack Overflow의 설문조사는 우리가 가진 가장 큰 정기 검진이며, 여기서 나타나는 채택 곡선은 가파릅니다. 2023년에는 개발자의 70%가 AI 도구를 사용하거나 사용할 계획이라고 답했지만, 2025년에는 그 수치가 84%로 증가하여 전문 개발자 절반이 매일 그것들을 사용하고 있었습니다.

이 정도의 사용률이라면 개발자들이 이 도구들을 사랑할 것이라고 생각하기 쉽습니다. 하지만 그렇지 않습니다. 호의적인 감정(favorable sentiment)은 2023년 77%에서 2025년 60%로 떨어졌고, 올해는 겨우 62%까지 반등했습니다. 2025년에는 개발자들 중 AI 결과물의 정확성을 신뢰하는 사람(33%)보다 불신하는 사람(46%)이 더 많았습니다. 그들이 지적한 가장 큰 좌절감은 “거의 맞지만, 완벽하지는 않은” 부분이었습니다.

저만 그런가요. '거의 맞는 것'이란 비싼 종류의 오류입니다. 왜냐하면 틀린 부분을 찾기 위해 모든 줄을 읽어야 하기 때문입니다. (응답자의 45%는 AI 생성 코드를 디버깅하는 데 시간이 더 걸린다고 답했습니다.)

사용하거나 계획함: 2023년 70%, 2024년 76%, 2025년 84%. 호의적 감정: 2023년 77%, 2024년 72%, 2025년 60%, 2026년 62%. 정확성 신뢰도: 2023년 42%, 2024년 43%, 2025년 33% (hrih.si의 인터랙티브 그래프)

Stack Overflow 개발자 설문조사, 2023년부터 2026년까지. 2026년 설문조사에서는 “사용하거나 계획함” 질문을 삭제하고 신뢰도 질문을 다시 작성했기 때문에, 이 두 줄은 2025년에서 끝납니다. 2023년에는 약 9만 명의 개발자가 응답했고, 2026년에는 3만 명이 넘는 사람이 응답했습니다.

제가 가장 좋아하는 AI 붐 관련 연구가 있습니다. 그 이유는 매우 직설적이기 때문입니다. 2025년 초, 비영리 연구 그룹인 METR이 제대로 된 무작위 대조군 실험(randomized controlled trial)을 진행했습니다. 숙련된 오픈 소스 개발자 16명이 자신들이 수년간 작업해 온 저장소(repository)의 실제 이슈 246개를 가지고 작업했으며, 각 이슈는 AI 도구를 사용하게 하거나 아예 금지하는 방식으로 무작위로 할당되었습니다.

실험에 앞서 개발자들은 AI가 자신의 작업 시간을 24% 단축시켜 줄 것으로 예상했습니다. 하지만 실험을 마친 후 그들은 시간이 20% 단축되었다고 믿었습니다. 반면, 시계는 AI를 사용했을 때 오히려 19% 더 오래 걸렸다고 기록했습니다.

19%나 더 오래 걸렸다니! 그런데도 그들은 AI가 도움이 되었다고 확신하며 자리를 떠났습니다.

METR (2025년 7월): 개발자 16명, 이슈 246개. 주로 Cursor와 Claude 3.5 및 3.7 Sonnet을 사용했습니다. 전문가들의 예측은 이 논문에서 나온 수치입니다. 속도 저하 폭은 2%에서 39% 사이로 상당한 편차를 보였습니다.

이 내용을 누가 '핫 토픽'으로 스크린샷 찍기 전에 알아두세요: 이것은 초기 2025년 도구를 사용하고, 어떤 모델보다도 잘 아는 코드베이스를 가진 단 16명의 사람을 대상으로 한 연구일 뿐입니다.

METR은 이 실험을 다시 시도했습니다. 더 큰 규모의 연구가 2025년 8월에 시작되었고, 개발자 57명과 800개 이상의 작업이 포함되었습니다. 하지만 METR은 2026년 2월에 그 데이터는 의존하기에는 너무 신뢰도가 낮다고 발표했습니다. 주된 이유는 개발자들이 “AI 없이 일하고 싶지 않다”며 참여를 거부했기 때문입니다. 초기 수치만 놓고 보면, 돌아온 개발자들에게는 평균 18%의 속도 향상이 예상되었지만(속도 저하가 전혀 없을 가능성까지 포함하는 넓은 범위였습니다).

저는 이것이 실험이 실패한 가장 '2026년다운' 방식이라고 생각합니다. 사람들은 AI 없이 그룹에 참여하기를 거부했습니다.

제가 METR에게서 얻은 교훈은 어떤 헤드라인보다 좁고, 더 유용합니다: 느끼는 속도가 곧 측정 기준이 될 수는 없습니다. 만약 AI가 팀의 생산성을 높이는지 알고 싶다면, 다른 모든 것을 측정하는 방식대로 측정해야 합니다.

계속 상승하는 선

METR의 또 다른 주요 프로젝트는 AI 에이전트가 스스로 얼마나 오랫동안 작업을 완료할 수 있는지 추적합니다. 그들은 일련의 소프트웨어 작업에 대해 인간 전문가들의 시간을 측정하고, 에이전트가 절반의 확률로 성공하는 작업 길이를 찾아냅니다. 2019년에는 GPT-2가 사람이 약 3초 걸리는 작업을 처리했습니다. GPT-4는 2023년에 약 4분까지 도달했으며, Claude 3.7 Sonnet은 2025년 2월에 1시간을 기록했고, Claude Opus 4.6은 그로부터 약 1년 뒤에 12시간에 도달했습니다.

전체 과정을 통틀어 이 수치는 약 6개월마다 두 배가 되었습니다. 2023년 이후로는 4개월에 가까워졌습니다.

GPT-2부터 Claude Opus 4.6까지 AI 에이전트가 절반의 확률로 완료하는 작업 길이, 약 6.2개월마다 두 배 증가. GPT-2: 3초, GPT-4: 4분, Claude 3.7 Sonnet: 60분, GPT-5: 3.4시간, Claude Opus 4.6: 12.0시간. (hrih.si의 인터랙티브 그래프)

METR의 시간 지평(time horizons) (버전 1.1): 각 모델이 절반의 확률로 완료하는 작업 길이(인간 전문가 시간 기준). METR는 현재 작업을 기준으로 16시간을 초과하는 것은 신뢰할 수 없다고 말하므로, 5월에 측정된 Claude Mythos Preview의 17시간 기록은 예외입니다. 점선 부분은 6개월 간격으로 두 배가 되는 추세를 연장한 것입니다. 이것은 약속이 아닌 추세입니다.

이제, 끝에 점선이 있는 로그 스케일(log-scale) 차트는 많은 부정확한 예측들이 시작되는 방식이니 제가 신중해야 합니다. “절반의 확률로”라는 정의는 상당한 노력을 필요로 합니다. 벤치마크 작업은 여러분의 코드베이스보다 더 깨끗합니다. 그리고 METR는 그 페이지 업데이트를 9월에 중단했습니다. 하지만 만약 그 선이 대략적으로라도 계속 이어진다면, 에이전트는 2028년경에 인간의 한 달 분량 작업을 절반의 확률로 처리할 것입니다. 이것이 제가 제시한 2031년 화요일 예측의 근거입니다. 저는 공중에서 꺼낸 것이 아닙니다. 축(axes)만 있는 로그 스케일 차트에서 가져온 것입니다.

이러한 도구를 구축하는 회사들은 이미 그 버전을 살고 있습니다. Google은 2024년 10월에 새로운 코드의 4분의 1 이상이 AI로 생성되었으며, 6개월 후에는 '30%가 넘는' 비율이었다고 밝혔습니다. 2025년 3월, Anthropic의 Dario Amodei는 향후 3~6개월 내에 AI가 코딩의 90%를 작성할 것이라고 예측했습니다. 이는 너무 빨랐습니다. 하지만 2026년 5월까지 Anthropic은 자체 코드베이스로 병합된 코드 중 80% 이상이 Claude에 의해 작성되었다고 말했습니다.

코드가 저렴해지면, 대기열이 움직인다

프로세스의 한 단계를 빠르게 만들면, 작업 부하가 다음으로 느린 단계 앞에 쌓입니다. 토요일 밤 주방에서 일해 본 사람이라면 누구나 아는 사실입니다. 그릴(grill)의 속도를 높이면 접시들이 통로(pass)에서 기다리기 시작합니다.

소프트웨어 팀에게도 똑같은 일이 일어나고 있습니다. 2025년, Faros AI는 1,255개 팀에 걸친 10,000명 이상의 개발자들의 원격 측정 데이터(telemetry)를 분석했습니다. AI 도입률이 높은 팀의 개발자들은 21% 더 많은 작업을 완료하고 98% 더 많은 풀 리퀘스트(pull requests)를 병합했으며, 검토 시간은 91% 증가했습니다.

Faros는 2026년에 22,000명의 개발자를 대상으로 다시 테스트를 진행했습니다. 개발자당 작업 완료율은 34% 상승했는데, 이는 매우 좋은 수치처럼 들리지만 나머지 내용을 읽으면 다릅니다. 중앙값 검토 시간(Median review time)이 무려 다섯 배나 증가했습니다. 아무런 검토 없이 병합된 풀 리퀘스트가 31% 늘어났고, 인시던트(incident) 대 풀 리퀘스트 비율은 세 배 이상 급증했습니다.

코드는 저렴해졌지만, 읽는 것은 더 비싸졌고, 일부 팀들은 조용히 읽기를 포기했습니다. 이는 중요한 문제입니다. 왜냐하면 코드가 항상 좋은 것은 아니기 때문입니다. Veracode는 2025년에 80가지 코딩 작업에 대해 100개 이상의 언어 모델을 테스트했으며, 그 결과 중 45%가 보안 취약점(security flaw)을 가지고 있었습니다. GitClear는 복사-붙여넣기 된 코드 라인이 2021년 변경된 코드의 8.3%에서 2024년에는 12.3%로 증가한 반면, 리팩토링(refactoring) 등으로 얻게 되는 이동된 코드(moved code)는 약 4분의 1 수준에서 10% 미만으로 떨어졌다는 것을 발견했습니다.

유지보수자들(maintainers)에 대한 생각도 해봐야 합니다. curl을 이끄는 Daniel Stenberg은 2025년 5월부터 'AI 쓰레기 코드(AI slop)' 버그 리포트를 제출하는 사람들을 금지하기 시작했으며, 해당 프로젝트가

막대 그래프 크기는 측정된 것이 아니라 예시입니다. 2026년의 형태는 위에 제시된 Faros AI의 수치를 따랐으며, 2031년은 제 추측입니다. 연도 간 전환을 통해 어떤 분야에서 업무가 대기하고 있는지 확인해 보세요.

Fred Brooks는 이와 유사한 상황이 1986년에 올 것이라고 보았습니다. 그는 "No Silver Bullet"에서 아리스토텔레스의 말을 빌려 소프트웨어의 어려움을 두 가지 덩어리(essence와 accidents)로 나누었습니다. 'accidents'는 구문(syntax), 상용 코드(boilerplate), 그리고 빌드 과정에서의 문제처럼 우리 도구들이 야기하는 문제입니다. 반면, 'essence'는 그가 "이 개념적 구조의 명세(specification), 설계(design), 그리고 테스트(testing)"라고 부른 것으로, 쉽게 말해: 그 사물이 무엇을 해야 하는지 파악하는 것입니다. AI는 'accidents' 분야에서 매우 능숙해지고 있습니다. 반면, 'essence'는 새벽 2시 13분에 떠오르는 환불 질문과 같으며, 여전히 당신의 책상 위에 남아 있습니다.

우리가 잘라낼지 모르는 발판

이 부분은 제가 가장 좋아하지 않는 데이터입니다.

2025년 8월, 스탠퍼드 디지털 경제 연구소(Digital Economy Lab)의 Erik Brynjolfsson과 동료 두 명은 누가 채용되고 있는지 알아보기 위해 ADP 급여 데이터를 사용했습니다. 22세에서 25세 사이의 소프트웨어 개발자 고용은 2022년 말 최고점 대비 거의 20% 감소했습니다. 나이가 많은 개발자들은 눈에 띄는 변화를 보이지 않았습니다.