AI 코딩 패러다임의 전환: Karpathy의 경험과 개발자 커뮤니티의 성찰

게시 2026/01/29

By BLUEBUG

94 분읽는 시간

A few random notes from claude coding quite a bit last few weeks.

서론: 20년 만의 가장 큰 변화

Andrej Karpathy는 최근 몇 주간의 Claude 기반 코딩 경험을 통해 “20년 프로그래밍 경력에서 가장 큰 워크플로우 변화”를 목격했다고 고백합니다. 이것은 단순한 도구의 변화가 아닙니다. 2024년 11월부터 12월까지 단 몇 주 만에 그의 코딩 방식은 80% 수동 코딩에서 80% AI 에이전트 활용으로 완전히 뒤바뀌었습니다.

이 변화의 의미는 개인적 차원을 넘어섭니다. Karpathy는 “이공계 엔지니어의 두 자릿수 비율이 이미 같은 경험을 하고 있지만, 일반 대중의 인식은 여전히 한 자릿수 초반”이라고 지적합니다. 우리는 지금 소프트웨어 개발사에서 가장 급격한 패러다임 전환의 한가운데 서 있으며, 그 파장은 아직 사회 전반으로 확산되지 않았습니다.

1. 워크플로우의 근본적 재편성

“영어로 프로그래밍한다”는 현실

Karpathy가 가장 먼저 토로하는 것은 자존심의 문제입니다. “이제 나는 영어로 프로그래밍을 합니다. 약간 민망하게도, LLM에게 어떤 코드를 작성할지… 말로 설명합니다.” 이것은 표면적으로는 간단한 인터페이스 변화처럼 보이지만, 실제로는 프로그래밍의 본질적 정의를 흔듭니다.

전통적으로 프로그래밍은 매우 정확하고 형식화된 언어로 컴퓨터에게 명령을 내리는 행위였습니다. 컴파일러나 인터프리터는 관대하지 않았고, 세미콜론 하나, 들여쓰기 하나가 틀려도 실행되지 않았습니다. 개발자의 숙련도는 이러한 형식 언어를 얼마나 유창하게 구사하느냐로 측정되었습니다.

하지만 이제 중간 계층이 추가되었습니다. 자연어라는 인간 친화적 인터페이스를 통해 AI 에이전트에게 의도를 전달하면, AI가 그것을 형식 언어로 번역합니다. 이것은 마치 고급 언어가 어셈블리를 추상화했던 것처럼, 자연어가 프로그래밍 언어를 추상화하는 또 하나의 계층 상승입니다.

“코드 액션”이라는 새로운 단위

Karpathy는 “큰 코드 액션” 단위로 소프트웨어를 조작할 수 있는 능력이 핵심이라고 강조합니다. 전통적으로 개발자는 함수 하나, 클래스 하나, 모듈 하나 단위로 사고했습니다. 리팩터링도 메서드 추출, 변수 이름 변경 같은 미시적 작업의 연속이었습니다.

하지만 AI 에이전트는 “이 인증 시스템을 OAuth 2.0에서 SAML로 전환해줘”라는 거시적 지시를 받고 수십 개 파일에 걸친 변경을 수행할 수 있습니다. 이것은 마치 건축에서 벽돌 하나씩 쌓던 방식에서 프리패브 모듈을 조립하는 방식으로 전환하는 것과 같습니다.

이 변화에 적응하면, 소프트웨어 개발은 미시적 구현에서 거시적 설계로 무게중심이 이동합니다. 개발자는 “어떻게(how)”보다 “무엇을(what)”에 더 집중하게 됩니다.

IDE의 지속적 필요성

흥미롭게도 Karpathy는 “IDE 불필요론”과 “에이전트 스웜” 과대광고를 모두 경계합니다. 그의 현재 워크플로우는 왼쪽에 Claude Code 세션 몇 개를 띄우고, 오른쪽에 IDE를 열어 코드를 검토하고 수동 편집하는 형태입니다.

이것은 중요한 통찰입니다. AI가 코드를 생성하더라도, 인간의 감독과 검증은 여전히 필수적입니다. 마치 자율주행차가 발전해도 운전자가 핸들을 잡고 있어야 하는 것처럼, AI 코딩도 개발자의 적극적 모니터링을 요구합니다.

Hacker News의 한 댓글은 이를 더 구체화합니다: “Copilot + VS Code에서 diff 뷰로 변경사항을 하나씩 수락하거나 거부하며 직접 수정도 병행한다. Karpathy가 말한 ‘IDE는 여전히 필요하다’는 주장과 정확히 일치한다.”

IDE는 단순한 텍스트 편집기가 아닙니다. 그것은 코드 네비게이션, 타입 검사, 리팩터링 도구, 디버거, 프로파일러, 버전 컨트롤 통합 등 개발자의 인지 부담을 줄여주는 종합 플랫폼입니다. AI가 코드를 작성한다고 해서 이러한 기능들이 불필요해지는 것은 아닙니다. 오히려 AI가 생성한 코드를 효율적으로 검증하고 통합하기 위해 더욱 중요해질 수 있습니다.

2. AI의 실수와 한계: “조금 서투른 주니어 개발자”

미묘한 개념적 오류

Karpathy는 AI의 실수가 진화했다고 지적합니다. “더 이상 단순한 문법 오류가 아니라, 약간 서두르고 부주의한 주니어 개발자가 할 법한 미묘한 개념적 오류들입니다.”

이것은 매우 중요한 관찰입니다. 과거 코딩 어시스턴트의 문제는 명백했습니다. 괄호가 안 맞거나, 변수명을 잘못 쓰거나, 타입이 맞지 않는 등 컴파일러나 린터가 즉시 잡아내는 오류들이었습니다. 하지만 지금의 AI는 문법적으로 완벽하고, 실행도 되지만, 설계상 잘못된 가정에 기반한 코드를 생성합니다.

예를 들어, AI는 사용자가 언급하지 않은 데이터베이스 스키마를 멋대로 가정하고, 그 가정 위에 완벽해 보이는 ORM 쿼리를 작성할 수 있습니다. 또는 동시성 이슈를 고려하지 않고 단일 스레드 환경을 전제로 한 코드를 만들 수도 있습니다. 이러한 오류는 코드 리뷰를 통과하고, 테스트도 통과하지만, 프로덕션 환경에서 예상치 못한 버그로 나타납니다.

체크하지 않고 달려가는 성향

“가장 흔한 오류 범주는 AI가 사용자를 대신해서 잘못된 가정을 만들고, 확인도 없이 그냥 진행해버리는 것입니다.” Karpathy의 이 지적은 AI의 근본적 한계를 드러냅니다.

인간 개발자, 특히 경험 많은 시니어는 불확실성을 관리하는 능력이 뛰어납니다. “이 부분은 명세가 불명확한데, 확인하고 진행할까요?” “A 방식과 B 방식이 가능한데, 각각 장단점이 이렇습니다. 어느 쪽을 선호하시나요?” 같은 질문을 던집니다.

하지만 AI는 이러한 메타인지가 약합니다. Karpathy가 지적하듯 “혼란을 관리하지 못하고, 명확화를 구하지 않고, 불일치를 드러내지 않고, 트레이드오프를 제시하지 않고, 필요할 때 반대하지도 않습니다.” 이것은 자신감의 문제가 아니라, AI가 자신의 불확실성을 인식하고 표현하는 능력이 부족하기 때문입니다.

Plan 모드에서는 상황이 개선되지만, “가벼운 인라인 플랜 모드가 필요하다”는 Karpathy의 제안은 시사적입니다. 모든 작업을 거창한 계획 단계로 시작하는 것은 오버헤드가 크지만, 중요한 분기점마다 잠깐 멈춰서 확인하는 메커니즘은 유용할 것입니다.

과도한 복잡화 경향

“AI는 코드와 API를 지나치게 복잡하게 만들고, 추상화를 부풀리고, 사용하지 않는 코드를 정리하지 않는 경향이 있습니다.”

이것은 많은 개발자들이 공감하는 현상입니다. AI는 종종 단순한 문제에 과도하게 엔지니어링된 솔루션을 제시합니다. 10줄로 해결될 문제를 팩토리 패턴, 전략 패턴, 옵저버 패턴을 모두 동원한 1000줄짜리 코드로 만들어버립니다.

Karpathy의 예시는 통렬합니다: “AI가 비효율적이고 부풀려지고 취약한 구조를 1000줄로 구현하면, ‘이거 그냥 이렇게 하면 안 될까?’라고 물어보면 ‘물론이죠!’라며 즉시 100줄로 줄입니다.”

이것은 두 가지를 시사합니다. 첫째, AI는 “최소 작동 제품(MVP)” 마인드셋이 약합니다. 주어진 요구사항을 만족시키되 가장 단순한 방법을 찾기보다, 모든 가능한 확장성을 고려한 완전한 솔루션을 지향합니다.

둘째, AI는 코드 리뷰어의 질문에 매우 수용적입니다. 이것은 양날의 검입니다. 긍정적으로 보면 피드백을 잘 받아들인다는 뜻이지만, 부정적으로 보면 초기 설계에 대한 확신이나 방어가 없다는 뜻이기도 합니다.

부작용으로 인한 코드 손상

“AI는 때때로 작업과 직접 관련 없는 주석이나 코드를, 마음에 들지 않거나 충분히 이해하지 못한다는 이유로, 부작용으로 변경하거나 제거합니다.”

이것은 특히 큰 코드베이스에서 위험합니다. AI는 로컬 컨텍스트에만 집중하다가 전역적 의미를 놓칠 수 있습니다. “TODO: 이 함수는 레거시 시스템 호환성을 위해 유지됨”이라는 주석이 달린 코드를, AI는 “사용되지 않는 코드”로 판단하고 삭제할 수 있습니다.

또는 이해하기 어려운 비트 연산 최적화를, AI가 “가독성이 떨어진다”며 루프 기반의 느린 코드로 바꿔버릴 수도 있습니다. 성능 크리티컬한 부분의 인라인 어셈블리를, AI가 “이해 불가”라며 제거하고 C 함수 호출로 대체할 수도 있습니다.

이러한 문제들은 Karpathy가 CLAUDE.md에 간단한 지시사항을 넣어봤지만 여전히 발생한다고 말합니다. AI의 맥락 이해와 지시 준수 능력이 아직 완벽하지 않다는 증거입니다.

3. 끈기(Tenacity): AI의 가장 인상적인 특성

“AGI를 느끼는 순간”

Karpathy의 가장 감동적인 관찰 중 하나는 AI의 끈기입니다. “에이전트가 무언가를 집요하게 작업하는 모습을 지켜보는 것은 정말 흥미롭습니다. 지치지도, 의욕을 잃지도 않고, 사람이라면 포기하고 다음 날을 기약했을 상황에서도 계속 시도하다가 30분 후 승리를 거둡니다. 이것은 ‘AGI를 느끼는’ 순간입니다.”

이것은 AI 코딩의 가장 변혁적인 측면입니다. 인간 개발자는 생물학적 한계가 있습니다. 몇 시간 집중하면 피로가 쌓이고, 같은 오류를 반복해서 보면 좌절감이 생기며, 진전이 없으면 동기부여가 떨어집니다. “일단 쉬고 내일 다시 해봐야겠다”는 매우 합리적인 판단입니다.

하지만 AI는 이러한 감정적, 신체적 제약이 없습니다. 100번째 시도가 실패해도 101번째 시도를 동일한 에너지로 수행합니다. 에러 메시지를 읽고, 가설을 세우고, 수정을 시도하는 루프를 무한히 반복할 수 있습니다.

Karpathy는 “스태미나(stamina)가 업무의 핵심 병목이었다는 것을 깨닫게 됩니다. LLM을 통해 그것이 극적으로 확장되었습니다”라고 정리합니다. 이것은 단순한 속도 향상이 아닙니다. 과거에는 “시도해볼 가치가 없다”고 판단했던 접근법들을, 이제는 AI에게 맡기고 결과를 기다릴 수 있습니다.

Hacker News의 엇갈린 반응

흥미롭게도 Hacker News에서 이 끈기에 대한 반응은 양면적입니다.

긍정적 시각: “끈기(grit)가 지능보다 성공과 더 상관 있다는 연구가 많습니다. 지난 20년간 기술 업계 성공의 핵심은 끈기였습니다. 새로운 프로토콜이나 프레임워크를 만든 사람보다, 복잡한 시스템을 끝까지 붙잡고 완성한 사람이 훨씬 많았습니다. Claude가 바로 그 끈기를 가지고 있습니다.”

이 관점은 AI를 이상적인 페어 프로그래머로 봅니다. 인간은 전략과 방향을 제시하고, AI는 그것을 포기하지 않고 구현합니다. 마치 마라톤에서 페이스메이커가 일정한 속도를 유지해주는 것처럼, AI는 일정한 집중력을 유지해줍니다.

부정적 시각: “절반은 지름길을 택한 결과입니다. 테스트가 없는 부분에 새 버그를 만들거나, 인간이라면 당연히 지켰을 암묵적 규칙을 깨버립니다. 그리고 잡아내면 ‘코인 몇 개만 더 넣으면 이번엔 진짜 고치겠다’고 말하는 느낌입니다.”

이 비유는 날카롭습니다. AI의 끈기는 맹목적일 수 있습니다. 인간 개발자는 30분간 막히면 “뭔가 근본적으로 잘못된 것 같다. 접근법을 바꿔야겠다”고 판단합니다. 하지만 AI는 잘못된 방향으로 30분, 1시간, 심지어 더 오래 파고들 수 있습니다.

또 다른 댓글: “Sonnet은 타입 에러 하나 해결하려고 코드베이스 전체를 수정하기도 합니다. ‘지금 엉뚱한 길로 가는 거 아니야?’라고 물으면 바로 수정하지만, 감독 없이는 위험합니다.”

이것은 AI 끈기의 역설입니다. 포기하지 않는다는 것은 좋지만, 언제 포기해야 할지 모른다는 것은 문제입니다. 인간의 “이건 안 될 것 같다”는 직관은 수십 년의 경험에서 나온 귀중한 메타인지입니다. AI는 아직 그 수준의 메타인지가 없습니다.

끈기와 비용의 딜레마

Hacker News의 한 댓글은 현실적 문제를 제기합니다: “에이전트가 지치지 않고 계속 시도하는 모습은 인상적이지만, 그 과정에서 GPU와 NPU가 뜨겁게 돌아갑니다. 우리는 엄청난 데이터를 제공하며 실제 비용은 거의 지불하지 않습니다. 이런 의존이 장기적으로 사회적·정치적 문제로 이어질 수 있습니다.”

이것은 중요한 지적입니다. 현재 Claude나 ChatGPT의 가격은 사용자에게 “무제한으로 느껴지는” 수준입니다. 월 $20-200 정도로 수천 번의 코딩 세션을 돌릴 수 있습니다. 하지만 이것은 서비스 제공자가 막대한 인프라 비용을 감수하며 시장 점유율을 확보하는 단계이기 때문입니다.

만약 AI 코딩이 보편화되고, 수백만 개발자가 하루에 수십 번씩 복잡한 작업을 요청하면 어떻게 될까요? 인프라 비용은 감당 가능할까요? 가격이 올라가면 “AI에게 30분간 시도시키기”는 비용적으로 정당화될까요?

반론도 있습니다: “인류 역사상 값이 안 내려간 기술은 없었습니다. 이미 작년 대비 절반 수준입니다. 인간도 결국 뜨겁게 돌아갑니다. 우리가 먹고, 운전하고, 살아가는 데 드는 공급망 에너지를 생각하면 GPU 전력보다 훨씬 큽니다.”

이것도 일리 있습니다. 역사적으로 컴퓨팅 비용은 무어의 법칙을 따라 지속적으로 하락했습니다. 1980년대에는 1MB 스토리지가 수천 달러였지만 지금은 몇 센트입니다. AI 추론 비용도 같은 궤적을 따를 수 있습니다.

또한 인간 개발자의 시급과 비교하면, AI 비용은 이미 극히 저렴합니다. 시니어 개발자 시급이 $100이라면, 그가 30분 고민하는 것과 AI가 30분 돌아가는 것 중 무엇이 더 저렴할까요? 대부분의 경우 AI가 훨씬 저렴합니다.

하지만 장기적으로는 “AI 없이는 아무것도 못 하는” 의존성이 우려됩니다. 전기가 끊기면 현대 문명이 멈추듯, AI 서비스가 중단되거나 가격이 급등하면 소프트웨어 산업 전체가 마비될 수 있습니다.

4. 속도 향상인가, 확장인가?

측정 불가능한 생산성

Karpathy는 “LLM 보조의 ‘속도 향상’을 측정하는 것은 불명확합니다”라고 말합니다. 이것은 매우 통찰력 있는 관찰입니다.

전통적 생산성 지표는 “같은 일을 얼마나 빨리 하는가”로 측정됩니다. 예를 들어, 자동화 도구를 도입해서 배포 시간이 1시간에서 10분으로 줄었다면, 6배 속도 향상입니다. 명확하고 측정 가능합니다.

하지만 AI 코딩의 영향은 다릅니다. Karpathy는 “확실히 원래 하려던 일은 훨씬 빨라졌다고 느끼지만, 주요 효과는 훨씬 더 많은 일을 한다는 것입니다”라고 말합니다.

왜 그럴까요? 두 가지 이유가 있습니다:

기회 비용의 변화: “이전에는 코딩할 가치가 없었던 온갖 것들을 이제 코딩할 수 있습니다.” 예를 들어, 데이터 분석을 위해 Excel을 쓸지, 간단한 Python 스크립트를 짤지 고민할 때, 과거에는 “스크립트 짜는 데 30분 걸릴 테니 그냥 Excel 쓰자”고 판단했습니다. 하지만 이제 “AI한테 5분에 스크립트 짜달라고 하자”가 되면서, Python 스크립트 옵션이 더 매력적이 됩니다.
지식/기술 장벽의 제거: “이전에는 지식/기술 문제로 손댈 수 없었던 코드에 접근할 수 있습니다.” 프론트엔드 개발자가 백엔드 API를 건드려야 하는데 Go를 모른다면, 과거에는 백엔드 개발자에게 요청하거나 포기했습니다. 하지만 이제 AI에게 “Go로 이런 엔드포인트 추가해줘”라고 하면, Go 문법을 몰라도 작업할 수 있습니다.

속도가 아닌 표면적의 확장

이것은 “속도 향상(speedup)”보다 “표면적 확장(expansion)”이라는 Karpathy의 표현이 정확합니다. 한 개발자가 다룰 수 있는 기술 스택의 폭이 넓어지고, 시도할 수 있는 프로젝트의 범위가 확대됩니다.

과거 풀스택 개발자는 “프론트엔드 + 백엔드 + 데이터베이스” 정도를 의미했습니다. 하지만 이제는 “프론트엔드 (React, Vue, Svelte) + 백엔드 (Node, Python, Go, Rust) + 데이터베이스 (PostgreSQL, MongoDB, Redis) + 인프라 (Docker, Kubernetes, Terraform) + 모바일 (iOS, Android) + 머신러닝 (PyTorch, TensorFlow)”까지 확장될 수 있습니다.

이것은 개인의 역량 뿐 아니라 팀 구성에도 영향을 미칩니다. 과거에는 각 영역마다 전문가가 필요했지만, 이제는 더 적은 인원으로 더 넓은 영역을 커버할 수 있습니다.

Hacker News의 실제 사례

몇몇 댓글은 이 확장 효과를 구체적으로 보여줍니다:

“나는 3개월 동안 Bluesky용 앱 Skyscraper를 만들었는데, 코드의 98%가 Claude가 작성했습니다.” 이 개발자는 과거 같았으면 시도조차 하지 못했을 프로젝트를, AI 덕분에 혼자서 완성했습니다.

“나도 Swift를 처음 배웠을 때 AI 덕분에 한 달 만에 꽤 복잡한 앱 Salam Prayer를 완성했습니다.” Swift를 몰랐던 개발자가 AI의 도움으로 완전히 새로운 플랫폼에 진입했습니다.

“우리 팀은 대형 CRUD 대시보드에 LLM을 쓰고 있습니다. 백엔드는 거의 원샷 구현 가능합니다.” 반복적이고 패턴화된 작업은 AI가 거의 완벽하게 처리합니다.

이것은 소프트웨어 개발의 민주화입니다. 과거에는 고도로 전문화된 지식이 필요했던 영역들이, 이제는 기본적인 프로그래밍 이해와 AI 활용 능력만으로 접근 가능해집니다.

5. 레버리지: 명령형에서 선언형으로

“무엇을 할지가 아니라 성공 기준을”

Karpathy의 가장 실용적인 조언 중 하나는 AI 활용의 레버리지입니다. “LLM은 특정 목표를 충족할 때까지 루프를 도는 데 매우 뛰어나며, 여기에서 대부분의 ‘AGI를 느끼는’ 마법이 발견됩니다. 무엇을 하라고 말하지 말고, 성공 기준을 주고 지켜보세요.”

이것은 프로그래밍 패러다임의 근본적 전환입니다. 명령형 프로그래밍(imperative programming)에서 선언형 프로그래밍(declarative programming)으로의 이동과 유사합니다.

명령형: “1단계를 하고, 2단계를 하고, 3단계를 해라” 선언형: “이러이러한 상태가 되어야 한다”

SQL이 좋은 예시입니다. 명령형으로 데이터를 찾으려면 “첫 번째 테이블을 열어라, 각 행을 순회해라, 조건을 체크해라, 맞으면 임시 리스트에 추가해라, 두 번째 테이블을 열어라…“처럼 단계를 나열해야 합니다. 하지만 SQL은 “SELECT * FROM table WHERE condition”처럼 원하는 결과를 선언하면, 데이터베이스 엔진이 최적의 실행 계획을 알아서 찾습니다.

AI 코딩도 마찬가지입니다. “이 함수를 추가하고, 저 변수를 바꾸고…“보다 “이 테스트가 통과해야 한다”는 목표를 주는 것이 훨씬 효과적입니다.

구체적 기법들

Karpathy는 세 가지 구체적 기법을 제시합니다:

테스트 주도: “테스트를 먼저 작성하게 하고, 그걸 통과하도록 합니다.” 이것은 TDD(Test-Driven Development)의 AI 버전입니다. 테스트는 명확한 성공 기준입니다. “이 입력에 대해 이 출력이 나와야 한다”는 모호함이 없는 사양입니다. AI는 테스트를 통과할 때까지 구현을 반복 수정합니다.
브라우저 MCP와의 루프: “브라우저 MCP와 루프에 넣습니다.” MCP(Model Context Protocol)를 통해 AI가 실제 브라우저를 조작하고 결과를 확인하게 합니다. “로그인 폼이 작동해야 한다”는 목표를 주면, AI는 직접 브라우저에서 폼을 제출하고, 성공 여부를 확인하고, 실패하면 코드를 수정하고 다시 시도합니다.
정확성 보존 최적화: “먼저 올바를 가능성이 높은 나이브한 알고리즘을 작성한 다음, 정확성을 유지하면서 최적화하도록 요청합니다.” 이것은 매우 현명한 전략입니다. 처음부터 최적화된 코드를 요구하면 AI는 복잡하고 버그 가능성 높은 코드를 만들 수 있습니다. 하지만 먼저 단순하고 명확한 코드를 만들고, 그것이 통과하는 테스트 스위트를 작성한 다음, “테스트는 그대로 통과하면서 성능을 2배 개선해줘”라고 요청하면, AI는 정확성을 검증하면서 최적화합니다.

명령형에서 선언형으로의 전환

“접근법을 명령형에서 선언형으로 바꿔 에이전트가 더 오래 루프를 돌게 하고 레버리지를 얻으세요.”

이것이 AI 시대 프로그래밍의 핵심 스킬이 될 것입니다. 과거에는 “어떻게(how)”를 정확히 명시하는 능력이 중요했습니다. 하지만 이제는 “무엇을(what)” 명확히 정의하는 능력이 더 중요해집니다.

좋은 프롬프트 엔지니어링은 목표와 제약을 명확히 하되, 구현 방법은 AI에게 맡기는 것입니다. 마치 좋은 매니저가 “이렇게 저렇게 해라”고 마이크로매니징하지 않고, “이런 결과를 달성해라, 이런 제약을 지켜라”고 말하는 것과 같습니다.

6. 재미의 재발견

창의성에 집중

“LLM 에이전트와 함께하면 프로그래밍이 더 재미있다는 것을 예상하지 못했습니다. 빈칸 채우기 같은 지루한 작업이 제거되고 창의적인 부분만 남기 때문입니다.”

이것은 많은 개발자들이 공감하는 경험입니다. 프로그래밍에는 두 가지 측면이 있습니다:

창의적 부분:

문제를 어떻게 모델링할까?
어떤 자료구조와 알고리즘이 적합할까?
시스템을 어떻게 설계할까?
사용자 경험을 어떻게 개선할까?

기계적 부분:

import 문 작성
보일러플레이트 코드
getter/setter 메서드
설정 파일 작성
반복적인 CRUD 로직

과거에는 이 두 부분을 모두 개발자가 직접 해야 했습니다. 하지만 이제 AI가 기계적 부분을 담당하면, 개발자는 창의적 부분에만 집중할 수 있습니다.

이것은 마치 화가가 캔버스 준비, 물감 섞기, 붓 씻기 같은 잡무에서 해방되어 순수하게 그림 그리기에만 집중하는 것과 같습니다.

막힘과 좌절의 감소

“막히거나 갇힌 느낌도 덜 받습니다(재미없죠). 거의 항상 AI와 손잡고 긍정적 진전을 만들 방법이 있기 때문에 더 용기가 생깁니다.”

개발자라면 누구나 경험하는 순간이 있습니다. 버그를 3시간째 추적하는데 원인을 못 찾겠고, 스택오버플로우에도 답이 없고, 문서는 도움이 안 되고, 동료들도 바쁘고… 이럴 때 느끼는 좌절감과 무력감은 심각한 동기부여 저하를 일으킵니다.

AI는 이런 순간의 든든한 동반자입니다. “이 버그 좀 같이 봐줘”라고 하면, AI는 즉시 코드를 분석하고, 가설을 제시하고, 디버깅 전략을 제안합니다. 항상 정답을 주지는 않지만, “혼자가 아니다”는 느낌 자체가 큰 차이를 만듭니다.

“빌더 vs 코더” 분리

하지만 Karpathy는 중요한 관찰을 덧붙입니다: “다른 사람들에게서는 반대 감정도 봤습니다. LLM 코딩은 주로 코딩 자체를 좋아하는 사람과 무언가를 만드는 것을 좋아하는 사람을 갈라놓을 것입니다.”

이것은 AI 시대의 핵심 구분선입니다.

코더(Coder): 코드 자체의 우아함, 알고리즘의 효율성, 아키텍처의 아름다움에서 만족감을 얻는 사람. 이들에게 코딩은 목적이자 과정입니다. 마치 목수가 톱질과 대패질의 기술 자체를 사랑하듯, 이들은 코딩이라는 행위 자체를 즐깁니다.

빌더(Builder): 실제로 작동하는 제품, 사용자가 쓸 수 있는 서비스, 문제를 해결하는 솔루션에서 만족감을 얻는 사람. 이들에게 코드는 수단입니다. 마치 건축가가 못질보다 완성된 건물에 관심 있듯, 이들은 결과물에 집중합니다.

Hacker News 댓글들은 이 분리를 생생하게 보여줍니다:

빌더 시각: “나는 결과를 만드는 빌더 쪽이라 이 변화가 반가움. 문제를 데이터 구조와 명령으로 정의하고, 그게 실행될 때의 쾌감이 좋았던 사람들도 있지만, 나는 무언가를 만드는 게 목표였음.”

코더 시각: “과거엔 문제를 데이터 구조와 명령으로 정의하고, 그게 실행될 때의 쾌감이 좋았음. 그런데 지금은 ‘이걸 대신 해주는 존재에게 지시하는 일’이 되어버림. 그게 즐겁다면 차라리 매니저가 되었을 것임.”

이것은 옳고 그름의 문제가 아닙니다. 개인의 가치관과 동기의 문제입니다. 두 관점 모두 소프트웨어 산업에 필요합니다. 코더들은 기반 기술과 프레임워크를 발전시키고, 빌더들은 그것을 활용해 실제 제품을 만듭니다.

하지만 AI는 이 균형을 빌더 쪽으로 기울일 것입니다. 순수하게 코딩 자체를 즐기는 사람들은 점점 니치한 영역(컴파일러 개발, 임베디드 시스템, 성능 최적화 등)으로 이동할 수 있습니다.

7. 능력 위축(Atrophy)의 그림자

생성과 판별의 분리

“이미 수동으로 코드를 작성하는 능력이 천천히 위축되기 시작하는 것을 느낍니다. 생성(코드 작성)과 판별(코드 읽기)은 뇌에서 다른 능력입니다.”

Karpathy의 이 관찰은 심오합니다. 인지과학에서 “생산(production)”과 “인지(recognition)”는 다른 수준의 능력입니다. 외국어로 비유하면:

인지 능력: 원어민의 대화를 듣고 이해하기
생산 능력: 직접 그 언어로 말하기

많은 사람들이 경험하듯, 읽기/듣기는 되는데 말하기/쓰기는 안 되는 수준에 머무르기 쉽습니다. 프로그래밍도 마찬가지입니다.

AI 시대에는 “코드를 읽고 이해하고 검토하는 능력”은 유지되지만, “처음부터 직접 코드를 짜는 능력”은 점차 약화될 수 있습니다. Karpathy는 “프로그래밍에 관련된 모든 작은 주로 구문적 세부사항 때문에, 코드를 작성하는 데 어려움을 겪더라도 코드를 검토하는 것은 잘할 수 있습니다”라고 설명합니다.

예를 들어, Python의 리스트 컴프리헨션 문법을 정확히 기억하지 못해도, 다른 사람이 쓴 [x**2 for x in range(10) if x % 2 == 0]을 읽고 “0부터 9까지 짝수의 제곱”이라고 이해할 수는 있습니다.

Hacker News의 우려: “두뇌 위축”

이 주제는 Hacker News에서 가장 열띤 논쟁을 불러일으켰습니다.

강한 우려: “AI를 쓰면서 두뇌 위축(brain atrophy)을 느끼고 있음. 처음엔 빠른 생산성에 도취되지만, 반복될수록 AI가 내 의도와 다른 방향으로 프로젝트를 끌고 감. 결국 내가 원하는 디자인보다 AI의 방식에 순응하게 됨. 새로운 접근을 시도할수록 AI의 훈련 데이터 편향이 벽처럼 느껴짐.”

이것은 매우 중요한 지적입니다. AI는 훈련 데이터에서 가장 흔한 패턴을 학습했기 때문에, “일반적인” 솔루션을 선호합니다. 하지만 혁신은 종종 비일반적인 접근에서 나옵니다.

만약 개발자가 항상 AI의 제안을 따르면, 모든 소프트웨어는 점점 더 비슷해질 것입니다. “AI가 선호하는 패턴”이 산업 표준이 되고, 그것에서 벗어나는 것은 점점 어려워집니다.

더 구조적인 우려: “단순한 두뇌 위축이 아니라, 모델 사용법을 배우는 데 뇌를 쓰는 구조적 전환임. 하지만 이 메타 스킬도 금방 낡음. 모델이 바뀔 때마다 새로 배워야 하고, 결국 영원한 러닝 트레드밀 위에 서게 됨. 나는 이런 의존을 원치 않음.”

이것은 심각한 딜레마입니다. Claude Opus 4.5를 완벽하게 다루는 법을 익혔는데, 6개월 후 Claude 5.0이 나오면 또 새로 배워야 합니다. 프로그래밍 언어는 수십 년간 안정적이지만, AI 모델은 몇 개월마다 바뀝니다.

실제 경험담: “최근 Claude Code로 Rust 기반 멀티플레이어 게임을 만들고 있는데, 코드가 잘 돌아가도 내가 진짜 이해하고 있지 않음. 과거엔 도구를 완전히 이해해야 여기까지 왔을 텐데, 지금은 반쯤 기능하는 게임만 있음. 유지보수나 버그 대응을 생각하면 이건 위험한 상태임.”

이것은 “작동은 하지만 이해하지 못하는 코드”라는 새로운 유형의 기술 부채입니다. 과거에는 복사-붙여넣기한 스택오버플로우 코드 조각이 이런 위험의 원천이었지만, 이제는 AI가 생성한 수천 줄의 코드가 그럴 수 있습니다.

중독성과 도파민

흥미로운 비유: “LLM 사용이 틱톡·릴스 중독과 비슷하다고 느낌. 가끔 ‘와, 이런 결과가?’ 하는 순간이 도파민을 자극하고, 그 짧은 쾌감을 다시 얻기 위해 계속 프롬프트를 돌림.”

이것은 AI 코딩의 심리적 측면을 포착합니다. 변수 리워드 스케줄(variable reward schedule)은 가장 강력한 중독 메커니즘입니다. 슬롯머신, 소셜 미디어 ‘좋아요’, 그리고 이제 AI 코딩이 같은 원리로 작동합니다.

프롬프트를 던지면:

때로는 완벽한 코드가 나와서 감탄 (큰 보상)
때로는 쓸만한 코드가 나와서 만족 (중간 보상)
때로는 쓰레기가 나와서 실망 (무보상)

이 예측 불가능성이 “한 번만 더” 시도하게 만듭니다. 마치 “다음엔 잭팟이 나올 것 같다”는 기대로 슬롯머신을 계속 돌리듯, “다음 프롬프트는 완벽할 것 같다”는 기대로 계속 시도합니다.

읽기 능력마저 위축

놀라운 관찰: “오늘은 새로운 문제를 겪음 — ‘읽기 위축(reading atrophy)’. LLM이 모르면 개발자들이 문서를 읽지 않음. 내가 직접 스크린샷과 하이라이트로 문서를 보여줘도 ‘이게 될지 모르겠다’는 반응을 들음.”

이것은 충격적입니다. AI는 코드 작성뿐 아니라 문서 읽기도 대체하고 있습니다. 과거에는 “공식 문서를 읽고 이해하는 능력”이 개발자의 필수 스킬이었습니다. 하지만 이제 “AI한테 물어보는 게 더 빠르다”는 생각으로 문서를 건너뜁니다.

문제는 AI가 항상 최신 정보를 가지고 있지 않고, 때로는 환각(hallucination)을 일으킨다는 것입니다. 개발자가 직접 문서를 읽으면 잡을 수 있는 오류를, AI 답변만 믿고 넘어가면 놓칠 수 있습니다.

더 나아가, 문서를 읽는 과정에서 얻는 주변 지식, 설계 철학, 베스트 프랙티스 같은 것들도 놓치게 됩니다. AI는 “A를 어떻게 하나요?”에는 답하지만, “A의 설계 의도는 무엇인가요?” “A의 대안은 무엇인가요?” 같은 맥락은 제공하지 않습니다.

8. Slopacolypse: 저품질 콘텐츠의 홍수

2026년의 예언

“2026년을 전체 GitHub, Substack, arXiv, X/Instagram 및 일반적으로 모든 디지털 미디어에 걸친 Slopacolypse(slop + apocalypse)의 해로 준비하고 있습니다.”

Karpathy의 이 경고는 가볍지 않습니다. “Slop”은 AI가 생성한 저품질, 대량생산 콘텐츠를 의미합니다. 기술적으로는 작동하지만 깊이, 통찰, 독창성이 부족한 콘텐츠입니다.

GitHub에서: 수천 개의 AI 생성 리포지토리가 쏟아집니다. “Todo 앱 100가지 변형”, “블로그 플랫폼 프레임워크”, “크롤러 스크립트” 등 비슷비슷한 프로젝트들이 검색 결과를 오염시킵니다. 진짜 혁신적인 프로젝트를 찾기 점점 어려워집니다.

Substack/Medium에서: AI가 쓴 기술 블로그가 범람합니다. “React의 10가지 팁”, “Python 베스트 프랙티스”, “머신러닝 입문” 같은 제목의 글들이 끊임없이 생성됩니다. 내용은 표면적으로 정확하지만, 깊은 경험에서 나온 통찰이 없습니다.

arXiv에서: AI가 작성한 논문들이 제출됩니다. 기존 연구를 재조합하고, 약간 변형된 실험을 추가하고, 그럴듯한 결론을 내립니다. 동료 심사를 통과할 정도의 품질은 되지만, 진짜 과학적 기여는 미미합니다.

X/Instagram에서: AI 생성 밈, 요약, 코멘트가 타임라인을 가득 채웁니다. 진짜 사람의 진짜 생각을 찾기 점점 어려워집니다.

AI 과대광고 생산성 극장

“또한 AI 과대광고 생산성 극장(AI hype productivity theater)도 훨씬 더 많이 보게 될 것입니다(그게 가능하기나 한가요?). 실제 진짜 개선과 함께요.”

이것은 날카로운 관찰입니다. “생산성 극장”은 실제 생산성 향상 없이 생산성이 높아 보이는 쇼를 하는 것을 의미합니다.

예를 들어:

“AI로 하루 만에 앱 10개 만들었습니다!” (하지만 그 중 실제로 쓸만한 건 0개)
“AI 덕분에 코딩 속도 100배 빨라졌습니다!” (하지만 버그 수정에 200배 시간 소모)
“완전 자동화된 개발 파이프라인 구축!” (하지만 매일 수동으로 고쳐야 작동)

SNS와 기술 블로그는 이런 과장된 성공 스토리로 채워질 것입니다. 실제로 AI를 도입해서 고생하는 사람들은 침묵하고, 잘 된 척하는 사람들만 목소리를 냅니다.

Karpathy는 조심스럽게 “실제 진짜 개선과 함께요”라고 덧붙입니다. 극장과 진짜를 구분하기 점점 어려워질 것입니다.

신호 대 잡음 비율의 붕괴

근본적 문제는 신호 대 잡음 비율(signal-to-noise ratio)의 붕괴입니다. 과거에는 콘텐츠 생성에 비용이 들었습니다. 블로그 글 하나 쓰려면 몇 시간, 오픈소스 프로젝트 하나 만들려면 몇 주가 필요했습니다. 이 비용이 자연스러운 필터 역할을 했습니다. 정말 가치 있다고 생각하는 것만 공개했습니다.

하지만 AI로 콘텐츠 생성 비용이 거의 0에 가까워지면, 필터가 사라집니다. “일단 만들어보고 올리자”가 됩니다. 결과적으로 인터넷은 저품질 콘텐츠로 범람합니다.

검색 엔진, 추천 알고리즘, 큐레이션 시스템이 이 문제를 해결해야 하지만, 그것들도 AI 생성 콘텐츠와 인간 생성 콘텐츠를 구분하는 데 어려움을 겪을 것입니다. 더 나아가, AI가 AI 생성 콘텐츠를 훈련 데이터로 사용하면, 품질이 점점 더 떨어지는 악순환이 시작될 수 있습니다.

9. 미래에 대한 질문들

10X 엔지니어의 격차 확대

“10X 엔지니어는 어떻게 되는가? — 평균과 최고 엔지니어 간 생산성 비율? 이것이 엄청나게 커질 가능성이 있습니다.”

전통적으로 “10X 엔지니어”는 평균 개발자보다 10배 생산적인 사람을 의미했습니다. 하지만 AI 시대에는 이 격차가 더욱 벌어질 수 있습니다.

왜 격차가 벌어질까?

AI 활용 능력의 차이: 평균 개발자는 AI를 단순한 자동완성 도구로 사용하지만, 뛰어난 개발자는 AI를 강력한 페어 프로그래머, 코드 리뷰어, 아키텍트 어시스턴트로 활용합니다.
레버리지의 차이: 평균 개발자는 작은 작업을 AI에게 맡기지만, 뛰어난 개발자는 전체 모듈, 심지어 시스템 수준의 작업을 AI와 협업하여 완성합니다.
메타인지의 차이: 평균 개발자는 AI 결과를 그대로 수용하지만, 뛰어난 개발자는 AI의 한계를 이해하고, 언제 신뢰하고 언제 의심해야 할지 압니다.

Hacker News 댓글은 이를 뒷받침합니다: “DevOps가 팀 단위의 10배 성과를 만든 것처럼, AI 활용 능력도 새로운 생산성 격차를 만들 것임. 하지만 이를 위해선 문화적 변화와 교육이 필요함. DevOps가 그랬듯, 배우기 싫어하는 조직은 이 변화를 놓칠 것임.”

반대 가능성: 격차 축소?

흥미롭게도 반대 시나리오도 가능합니다. AI가 초보자에게 더 큰 도움을 준다면, 격차가 축소될 수 있습니다. 10X 엔지니어는 이미 효율적이라 AI로 10배에서 15배로 가지만, 1X 엔지니어는 AI로 1배에서 8배로 간다면, 상대적 격차는 줄어듭니다.

하지만 Karpathy의 관찰과 현재 추세를 보면, 격차 확대 쪽이 더 가능성 있어 보입니다. AI는 도구이고, 도구는 그것을 잘 쓰는 사람에게 더 큰 힘을 줍니다.

제너럴리스트 vs 스페셜리스트

“LLM으로 무장한 제너럴리스트가 점점 더 스페셜리스트를 능가하는가? LLM은 빈칸 채우기(마이크로)는 훨씬 잘하지만 거대 전략(매크로)은 그렇지 않습니다.”

이것은 매우 흥미로운 질문입니다. 전통적으로 스페셜리스트가 유리했습니다. 데이터베이스 전문가는 복잡한 쿼리 최적화를 할 수 있고, 보안 전문가는 미묘한 취약점을 발견할 수 있습니다. 깊은 전문 지식은 쉽게 대체되지 않았습니다.

하지만 AI는 “충분히 좋은” 수준의 전문 지식을 민주화합니다. 백엔드 개발자가 프론트엔드 작업을 해야 하는데 React를 모르더라도, AI의 도움으로 “작동하는” React 컴포넌트를 만들 수 있습니다. 전문 React 개발자만큼은 아니지만, 과거 “전혀 못 하던” 것에 비하면 엄청난 발전입니다.

Karpathy의 지적대로, AI는 “빈칸 채우기”에 강합니다. 패턴화된 작업, 반복적인 구현, 표준적인 접근은 AI가 잘 합니다. 하지만 “거대 전략” — 시스템 아키텍처 설계, 기술 스택 선택, 비즈니스 요구사항과 기술적 제약의 균형 — 은 여전히 인간의 영역입니다.

따라서 이상적인 개발자상은 “T자형 인재”에서 “빗살형 인재”로 진화할 수 있습니다. 여러 분야에서 AI의 도움으로 충분한 수준(빗살의 짧은 부분)을 유지하면서, 한두 분야에서는 깊은 전문성(빗살의 긴 부분)을 가지는 것입니다.

LLM 코딩은 무엇과 같은가?

“미래에 LLM 코딩은 어떤 느낌일까요? 스타크래프트를 하는 것과 같을까요? 팩토리오를 하는 것과 같을까요? 음악을 연주하는 것과 같을까요?”

이 질문은 시적이면서도 심오합니다. Karpathy는 새로운 경험이 어떤 느낌일지, 기존의 어떤 활동과 비슷할지 궁금해합니다.

스타크래프트: 실시간 전략 게임. 여러 유닛을 동시에 관리하고, 자원을 배분하고, 적의 움직임에 대응합니다. 만약 AI 코딩이 이것과 같다면, 개발자는 여러 AI 에이전트를 동시에 관리하고, 우선순위를 정하고, 긴급한 문제에 대응하는 지휘관 역할을 할 것입니다.

팩토리오: 자동화 공장 건설 게임. 복잡한 생산 파이프라인을 설계하고, 최적화하고, 확장합니다. 만약 AI 코딩이 이것과 같다면, 개발자는 AI 워크플로우를 설계하고, 병목을 찾아 개선하고, 시스템을 점진적으로 발전시키는 엔지니어 역할을 할 것입니다.

음악 연주: 창의성과 기술의 조화. 즉흥 연주도 있고, 연습된 악보 연주도 있습니다. 만약 AI 코딩이 이것과 같다면, 개발자는 AI와 즉흥적으로 협업하면서도, 전체적인 “곡”의 흐름을 지휘하는 음악가 역할을 할 것입니다.

아마도 이 세 가지 모두의 요소가 있을 것입니다. 때로는 빠르게 여러 작업을 조율하고(스타크래프트), 때로는 효율적인 자동화를 설계하고(팩토리오), 때로는 창의적으로 즉흥 연주합니다(음악).

사회는 얼마나 디지털 지식 노동에 의존하는가?

“사회의 얼마나 많은 부분이 디지털 지식 노동에 병목되어 있는가?”

이것은 가장 거대한 질문입니다. 만약 AI가 소프트웨어 개발을 10배 효율화한다면, 그 영향은 IT 산업에만 국한되지 않습니다.

직접 영향:

모든 회사가 “소프트웨어 회사”가 됩니다. 과거에는 IT 부서가 비용 센터였지만, 이제는 AI를 활용한 빠른 소프트웨어 개발이 경쟁 우위가 됩니다.
스타트업 창업 장벽이 낮아집니다. 과거에는 CTO를 찾거나 외주 개발에 수만 달러를 투자해야 했지만, 이제는 아이디어만 있으면 AI와 함께 MVP를 만들 수 있습니다.

간접 영향:

의료: 의사가 AI를 활용해 진단 소프트웨어를 직접 개발하고, 맞춤형 치료 계획을 자동화합니다.
교육: 교사가 AI를 활용해 학생별 맞춤 학습 프로그램을 만들고, 자동 채점 시스템을 구축합니다.
법률: 변호사가 AI를 활용해 판례 검색 도구를 만들고, 계약서 검토를 자동화합니다.
금융: 애널리스트가 AI를 활용해 맞춤형 데이터 분석 툴을 만들고, 트레이딩 알고리즘을 개발합니다.

Karpathy의 질문은 이것입니다: 지금까지 우리는 “소프트웨어가 있으면 좋지만 개발 비용이 너무 비싸서 포기”한 것들이 얼마나 많았을까? 그것들이 모두 가능해진다면 사회는 어떻게 변할까?

아마도 우리는 그 답을 곧 알게 될 것입니다.

10. 커뮤니티의 다양한 목소리

비용과 에너지 논쟁

앞서 언급한 비용 논쟁은 Hacker News에서 가장 열띤 주제 중 하나였습니다.

비관론: “GPU가 뜨겁게 돌아가고, 우리는 실제 비용을 거의 지불하지 않습니다. 이런 의존이 장기적으로 사회적·정치적 문제로 이어질 수 있습니다.”

낙관론: “인류 역사상 값이 안 내려간 기술은 없었습니다. OpenAI나 Anthropic은 실제 비용보다 훨씬 높은 가격으로 API를 팔고 있어 충분히 수익이 남니다.”

현실론: “진짜 돈이 드는 건 학습 과정이지 추론이 아닙니다. 추론 비용은 계속 떨어지고 있고, 오픈 모델(Kimi K2.5, GLM 4.7)도 나오고 있습니다.”

이것은 해결되지 않은 논쟁입니다. 양측 모두 타당한 논거가 있고, 실제로 어떻게 전개될지는 시간이 말해줄 것입니다.

대형 코드베이스에서의 효과

“큰 코드베이스에서는 LLM이 쓸모없다고 느꼈음. ChatGPT로는 제대로 작동하지 않음.”

이 비판에 대한 반론: “나는 수천 개 파일이 있는 리포지토리에서도 꽤 효율적으로 작업함. 다만 리팩터링 주기와 정적 분석·테스트·문서화가 필수임. 모델별로도 차이가 커서, Opus는 일상용으로, Codex는 테스트 작성에 강함.”

이것은 중요한 구분입니다. “ChatGPT 웹 인터페이스”와 “Claude Code나 Cursor 같은 전문 도구”는 다릅니다. 웹 인터페이스는 제한된 컨텍스트 윈도우와 파일 관리 능력으로 대형 프로젝트에 부적합합니다. 하지만 전문 도구는 코드베이스 인덱싱, 심볼 검색, 컨텍스트 관리 등으로 훨씬 효과적입니다.

또한 “큰 코드베이스”의 품질도 중요합니다. 잘 구조화되고, 테스트되고, 문서화된 코드베이스는 AI가 이해하고 작업하기 쉽습니다. 반면 스파게티 코드, 레거시 시스템, 문서 없는 코드베이스는 인간도 어렵고 AI도 어렵습니다.

도구 선택의 다양성

커뮤니티는 다양한 도구를 사용하며, 각자 선호가 있습니다:

Cursor: “Cursor + Claude Opus 4.5 조합. 유료 모델이 확실히 품질이 좋음.”

Copilot: “Copilot + VS Code. Diff 뷰에서 변경사항을 하나씩 수락·거절하며 직접 수정도 병행. 내 사고방식과 잘 맞음.”

Claude Code: “Claude Code CLI로 컨텍스트를 충분히 제공하면 대형 코드베이스도 잘 다룸.”

GitHub Copilot Workspace: “GitHub 이슈를 Copilot에 할당해 풀리퀘스트를 자동 생성. 모든 맥락이 PR에 담겨 리뷰하기 편함.”

도구 선택은 개인의 워크플로우, 프로젝트 특성, 팀 문화에 따라 달라집니다. 중요한 것은 “하나의 정답”이 없다는 것입니다. 각자 자신에게 맞는 도구와 방법을 찾아야 합니다.

프론트엔드의 특수성

“프론트엔드(HTML + Tailwind)에서는 여전히 유용함”이라는 댓글에 대한 반박: “프론트엔드를 그렇게 가볍게 보는 건 아쉬움. 이미 접근성 문제로 가득한 영역이라 LLM이 그 문제를 더 확대할 위험이 있음.”

이것은 중요한 지적입니다. AI가 시각적으로 괜찮아 보이는 UI를 빠르게 생성할 수 있지만, 접근성(a11y), 시맨틱 HTML, ARIA 속성, 키보드 내비게이션 같은 것들은 놓칠 수 있습니다.

“LLM이 생성한 프론트엔드”가 보편화되면, 시각적으로는 멋지지만 스크린 리더 사용자, 키보드 전용 사용자, 인지 장애가 있는 사용자에게는 사용 불가능한 웹사이트가 양산될 수 있습니다.

이것은 AI 코딩의 더 넓은 문제를 상징합니다: AI는 “작동하는” 코드를 만들지만, “좋은” 코드, “포용적인” 코드, “지속가능한” 코드를 만드는지는 별개입니다.

성능 퇴보 논쟁

“최근 몇 달간 AI 성능이 오히려 퇴보한 느낌임. 규칙을 잊고, 과도한 계획을 세우며, 불필요하게 복잡한 코드를 생성함.”

이것에 대한 반론: “혹시 Opus 4.5 대신 Sonnet을 쓰는 건 아닌지? 최근엔 전반적으로 많이 개선됨.”

AI 모델의 성능은 복잡합니다:

모델 버전: 같은 “Claude”라도 Opus, Sonnet, Haiku는 다릅니다.
사용 방법: 프롬프트, 컨텍스트, 도구 사용 방식이 결과에 큰 영향을 줍니다.
기대치 변화: 처음 사용할 때는 기대가 낮아 쉽게 만족하지만, 익숙해질수록 기대치가 높아져 같은 성능도 “퇴보”로 느낄 수 있습니다.
작업 복잡도 증가: AI에 익숙해지면 더 어려운 작업을 시도하게 되고, 당연히 실패율이 높아집니다.

“AI가 나빠졌다”고 느낄 때, 실제로는 “내가 더 어려운 것을 시도하고 있다”일 수 있습니다.

11. 종합: 패러다임 전환의 한가운데서

2025년 12월: 임계점

Karpathy의 핵심 주장은 명확합니다: “LLM 에이전트 능력(특히 Claude와 Codex)은 2025년 12월경 어떤 일관성의 임계점을 넘었고, 소프트웨어 엔지니어링 및 밀접하게 관련된 분야에서 국면 전환(phase shift)을 일으켰습니다.”

“국면 전환”은 물리학 용어입니다. 물이 얼음으로 변하거나, 물이 증기로 변하는 것처럼, 점진적 변화가 어느 순간 질적 변화로 도약하는 것입니다. 온도를 99도에서 100도로 1도 올릴 때, 물은 여전히 물입니다. 하지만 100도를 넘는 순간, 액체에서 기체로 완전히 다른 상태가 됩니다.

소프트웨어 개발도 그런 순간을 지나고 있습니다. 지난 몇 년간 AI 코딩 도구는 점진적으로 개선되었습니다. 하지만 2025년 12월경, 특히 Claude Code 2.0 출시 전후로, “충분히 좋음”에서 “실제로 의존할 만함”으로 넘어갔습니다.

지능 vs 통합

“지능 부분이 갑자기 나머지 모든 것들 — 통합(도구, 지식), 새로운 조직 워크플로우와 프로세스의 필요성, 더 일반적으로는 확산 — 보다 상당히 앞서 있다는 느낌입니다.”

이것은 중요한 관찰입니다. AI의 “지능”은 이미 많은 작업에 충분하지만, 그것을 실제로 활용하는 “생태계”는 따라잡지 못하고 있습니다.

통합: AI는 강력하지만, 기존 도구들(IDE, 버전 컨트롤, CI/CD, 이슈 트래커 등)과의 통합은 아직 부족합니다. 개발자는 여러 인터페이스 사이를 오가며 컨텍스트를 수동으로 전달해야 합니다.

워크플로우: 회사와 팀은 여전히 “인간만 개발하는” 프로세스를 가지고 있습니다. 코드 리뷰, 페어 프로그래밍, 스프린트 계획 같은 것들이 “AI와 협업하는” 방식으로 진화해야 하지만, 아직 베스트 프랙티스가 확립되지 않았습니다.

확산: Karpathy 추정으로 “두 자릿수 비율의 엔지니어”가 이미 AI 중심 워크플로우로 전환했지만, 일반 대중의 인식은 “한 자릿수 초반”입니다. 대부분의 조직, 학교, 정부는 여전히 이 변화를 인식하지 못하고 있습니다.

2026년: 고에너지의 해

“2026년은 산업이 새로운 능력을 대사하면서(metabolize) 고에너지의 해가 될 것입니다.”

“대사한다(metabolize)”는 은유가 적절합니다. 생물이 음식을 섭취하고 소화하고 에너지로 전환하듯, 소프트웨어 산업은 AI 능력을 흡수하고, 적응하고, 활용하는 과정을 거칠 것입니다.

이 과정은 순탄하지 않을 것입니다. 앞서 논의한 여러 문제들 — 능력 위축, Slopacolypse, 비용 문제, 의존성 위험 — 이 모두 표면화될 것입니다. 동시에 놀라운 혁신, 새로운 제품, 예상치 못한 응용도 나타날 것입니다.

“고에너지”는 긍정적이면서 동시에 도전적입니다. 변화와 기회가 넘치지만, 혼란과 불확실성도 함께합니다.

결론: 우리는 어디로 가는가?

돌아갈 수 없는 강

Karpathy는 “이 모든 문제에도 불구하고, 여전히 순수 거대한 개선이며, 수동 코딩으로 돌아가는 것을 상상하기 매우 어렵습니다”라고 고백합니다.

이것이 핵심입니다. AI 코딩은 완벽하지 않습니다. 실수도 하고, 과도하게 복잡한 코드도 만들고, 때로는 엉뚱한 방향으로 달려갑니다. 하지만 그럼에도 불구하고, 한번 경험하면 이전으로 돌아갈 수 없습니다.

마치 스마트폰이 나온 후 피처폰으로 돌아가기 어렵고, 인터넷이 보편화된 후 도서관만으로 연구하기 어려운 것과 같습니다. 새로운 도구는 우리의 기대치를 영구적으로 재설정합니다.

개인적 적응 전략

이 변화의 한가운데서 개발자는 무엇을 해야 할까요? 몇 가지 제안:

핵심 역량 유지: AI가 빈칸을 채우더라도, 시스템 설계, 아키텍처 결정, 트레이드오프 판단 같은 고수준 스킬을 계속 연마하세요.
AI 리터러시 개발: 다양한 AI 도구를 시험하고, 각각의 강점과 약점을 이해하고, 효과적인 프롬프팅 기법을 배우세요.
비판적 검토 습관: AI 코드를 맹목적으로 수용하지 말고, IDE에서 꼼꼼히 검토하고, 테스트하고, 이해하려 노력하세요.
T자형 역량 확장: AI를 활용해 새로운 기술 스택을 시도하되, 한두 분야에서는 AI가 대체할 수 없는 깊은 전문성을 유지하세요.
커뮤니티 참여: 빠르게 변하는 분야이므로, 다른 개발자들의 경험과 베스트 프랙티스를 지속적으로 학습하세요.

조직적 대응

조직과 팀 차원에서는:

실험 문화: AI 도구를 도입하되, 실패를 두려워하지 말고 빠르게 학습하세요.
워크플로우 재설계: 기존 프로세스에 AI를 억지로 끼워넣지 말고, AI 시대에 맞는 새로운 프로세스를 설계하세요.
품질 보증: AI 생성 코드에 대한 더 엄격한 테스트, 코드 리뷰, 보안 검사를 도입하세요.
교육 투자: 팀원들이 AI 도구를 효과적으로 사용할 수 있도록 교육에 투자하세요.
윤리적 고려: AI 의존도가 높아질수록, 벤더 락인, 데이터 프라이버시, 비용 변동성 같은 리스크를 관리하세요.

사회적 차원

더 넓은 사회 차원에서는:

교육 개혁: 컴퓨터 과학 교육이 “코딩 문법”에서 “AI와 협업하는 문제 해결”로 진화해야 합니다.
직업 재편: 일부 직무는 사라지겠지만, AI를 활용하는 새로운 직무도 생길 것입니다. 전환 지원이 필요합니다.
인프라 투자: AI 추론을 지원하는 컴퓨팅 인프라, 안정적인 서비스, 오픈 소스 대안 개발이 필요합니다.
규제와 표준: AI 생성 코드의 책임, 라이선싱, 보안 기준 같은 것들을 논의하고 정립해야 합니다.

마지막 성찰

Karpathy와 Hacker News 커뮤니티의 논의는 우리에게 중요한 메시지를 전합니다: AI 코딩은 더 이상 먼 미래의 이야기가 아닙니다. 지금, 여기서, 수많은 개발자들이 매일 경험하고 있는 현실입니다.

이 변화는 두렵기도 하고 흥미롭기도 합니다. 우리의 기술이 쓸모없어질까 걱정되지만, 동시에 과거에는 불가능했던 것들을 만들 수 있다는 가능성에 설렙니다.

중요한 것은 이 변화를 능동적으로 맞이하는 것입니다. 변화를 거부하며 과거에 머물 수도, 무비판적으로 AI에 모든 것을 맡길 수도 없습니다. 대신, AI의 강점을 이해하고, 한계를 인식하고, 인간의 창의성과 판단력을 결합하는 새로운 협업 방식을 찾아야 합니다.

Karpathy의 말처럼, 우리는 20년 만의 가장 큰 변화의 한가운데 서 있습니다. 그리고 Hacker News 커뮤니티의 다양한 목소리가 보여주듯, 그 변화는 복잡하고, 다면적이며, 아직 진행 중입니다.

2026년, 그리고 그 이후는 정말로 “고에너지의 시대”가 될 것입니다. 우리가 이 에너지를 어떻게 활용하느냐가, 소프트웨어 개발의, 나아가 디지털 사회의 미래를 결정할 것입니다.

작성 일자: 2026-01-29

AI, Material

AI Material AndrejKarpathy Claude claude-code agentic-coding IDE Claude.write