Andrej Karpathy가 오늘 X에 공유 포스트 AI 코딩 워크플로우에 대한 생각을 정리한 글 입니다.
원문의 인사이트가 좋아서 통 번역본으로 공유드립니다!
지난 몇 주 동안 Claude로 코딩을 꽤 많이 하면서 든 몇 가지 잡다한 메모들. 코딩 워크플로우에 대한 이야기다.
최근 LLM의 코딩 능력이 크게 향상되면서 나를 포함해 많은 사람들이 그렇듯이
나는 11월까지만 해도 수동 코딩+자동완성 80%, 에이전트 20% 정도였던 비중이
12월에는 에이전트 80%, 수정과 터치업 20%로 빠르게 바뀌었다.
즉, 이제 나는 대부분의 프로그래밍을 영어로 하고 있다.
LLM에게 어떤 코드를 작성해야 하는지를 말로 설명하는 식이다.
자존심이 조금 상하긴 하지만, 소프트웨어를 큰 단위의 “코드 액션”으로 다룰 수 있는 힘이 너무나도 유용하다.
특히 이 도구에 적응하고, 설정하고, 어떻게 사용해야 하는지,
그리고 무엇을 할 수 있고 무엇을 못 하는지를 이해하게 되면 더 그렇다.
내가 약 20년간 프로그래밍을 하면서 겪은 가장 큰 변화이고, 불과 몇 주 만에 일어났다.
엔지니어 중 두 자릿수 퍼센트 이상에게 비슷한 일이 벌어지고 있을 거라고 생각한다.
반면, 일반 대중의 인식은 아직 한 자릿수 퍼센트 수준인 것 같다.
IDE / 에이전트 스웜 / 신뢰성 문제
“이제 IDE는 필요 없다”는 과장과 “에이전트 스웜”에 대한 과장은 둘 다 지금 시점에서는 지나치다고 본다.
모델은 여전히 실수를 하고, 정말로 중요한 코드를 다룬다면 큰 IDE에서 매의 눈으로 지켜봐야 한다.
다만 실수의 종류가 많이 바뀌었다. 이제는 단순한 문법 오류가 아니라,
약간 성급하고 꼼꼼하지 못한 주니어 개발자가 할 법한 미묘한 개념적 오류들이다.
가장 흔한 문제는 모델이 사용자 대신 잘못된 가정을 하고, 그것을 검증하지 않은 채 그대로 밀고 나간다는 점이다. 또한 자신의 혼란을 관리하지 못하고, 명확화를 요청하지 않으며, 불일치를 드러내지 않고, 트레이드오프를 제시하지 않으며, 필요할 때 반박하지도 않는다. 그리고 여전히 다소 아부적이다. 플랜 모드에서는 조금 나아지지만, 가볍게 inline으로 쓸 수 있는 플랜 모드가 필요하다고 느낀다.
또한 코드와 API를 과도하게 복잡하게 만들고, 추상화를 부풀리며 죽은 코드를 정리하지 않는다.
1000줄짜리 비효율적이고, 비대하고, 취약한 구조를 만들어 놓고는 내가 “이렇게 간단히 할 수 있지 않나?”라고 말하면 “물론입니다!” 하며 즉시 100줄로 줄이기도 한다.
작업과 무관한 코드나 주석을 이해하지 못하거나 마음에 들지 않는다는
이유로 바꾸거나 삭제해버리는 경우도 여전히 있다.
이런 문제들은 CLAUDE.md에 몇 가지 간단한 지침을 넣어도 여전히 발생한다.
그럼에도 불구하고, 전체적으로는 엄청난 순이익이며 수동 코딩으로 돌아가는 것은 상상하기 어렵다.
TL;DR: 모두 저마다의 개발 흐름이 있지만, 현재 나의 흐름은 왼쪽에 ghostty 창/탭으로 몇 개의 Claude Code 세션을 두고, 오른쪽에 IDE를 두어 코드 확인과 수동 수정을 하는 방식이다.
끈기(Tenacity)
에이전트가 무언가를 집요하게 파고드는 모습을 보는 건 정말 흥미롭다.
지치지도 않고 의기소침해지지도 않으며, 사람이었다면 이미 포기했을 문제를 계속 시도한다.
30분 동안 고생하다가 결국 해결해내는 모습을 보면 “AGI를 체감하는 순간”이라는 느낌이 든다.
여기서 깨닫게 되는 것은, 작업에서 가장 큰 병목 중 하나가 바로 ‘지구력’이며
LLM은 이를 극적으로 확장시켜 주었다는 점이다.
속도 향상(Speedups)
LLM의 도움으로 얼마나 빨라졌는지를 측정하기는 쉽지 않다. 분명 내가 원래 하려던 일은 더 빨리 하게 되었지만 더 큰 효과는 내가 원래 하려던 것보다 훨씬 더 많은 일을 하게 되었다는 점이다.
1) 예전에는 굳이 만들 가치가 없다고 생각했던 것들을 이제는 쉽게 만들 수 있고
2) 지식이나 기술 부족 때문에 접근하지 못했던 코드에도 접근할 수 있게 되었다.
그래서 이는 단순한 속도 향상이라기보다는 ‘확장’에 가깝다.
레버리지(Leverage)
LLM은 특정 목표를 만족할 때까지 반복하는 데 매우 뛰어나다.
여기에서 대부분의 “AGI를 체감하는” 마법이 나온다. 무엇을 하라고 지시하지 말고, 성공 조건을 주어라.
테스트를 먼저 작성하게 한 뒤 통과시키게 하라. 브라우저 MCP와 함께 루프에 넣어라.
먼저 매우 단순하지만 맞을 가능성이 높은 알고리즘을 작성하게 하고 정확성을 유지한 채 최적화하라고 하라.
명령형에서 선언형 접근으로 바꾸면 에이전트가 더 오래 루프를 돌며 더 큰 레버리지를 낼 수 있다.
재미(Fun)
에이전트로 프로그래밍하는 것이 오히려 더 재미있을 줄은 몰랐다.
자잘한 빈칸 채우기 같은 귀찮은 작업이 사라지고 창의적인 부분만 남기 때문이다.
막히거나 멈춘 느낌도 훨씬 줄었고 거의 항상 함께 진전을 만들어갈 수 있다는 확신 덕분에 더 많은 용기를 얻게 된다. 반대로 느끼는 사람들도 있다. LLM 코딩은 코딩 자체를 좋아했던 엔지니어와
무언가를 만드는 것을 좋아했던 엔지니어를 갈라놓을 것이다.
퇴화(Atrophy)
이미 수동으로 코드를 작성하는 능력이 서서히 퇴화하고 있다는 것을 느끼고 있다.
생성(코드 작성)과 판별(코드 읽기)은 뇌에서 다른 능력이다.
프로그래밍의 많은 세부 사항이 문법적이기 때문에 코드를 쓰는 데는 어려움을 겪더라도 읽고 리뷰하는 것은 비교적 잘할 수 있다.
슬로파칼립스(Slopacolypse)
2026년은 GitHub, Substack, arXiv, X/Instagram 그리고 전반적인 디지털 미디어 전반에 걸쳐 ‘슬롭의 대홍수’가 일어나는 해가 될 것이라 대비하고 있다. 실제적이고 진짜 개선과 함께 AI 과대광고 기반의 생산성 쇼도 훨씬 더 많이 보게 될 것이다.
내가 계속 생각하고 있는 몇 가지 질문들:
“10X 엔지니어”는 어떻게 될까? 평균과 최고 생산성 엔지니어 간의 격차가 훨씬 더 커질 가능성이 있다.
LLM을 무기로 삼았을 때, 제너럴리스트가 스페셜리스트를 점점 더 능가하게 될까?
LLM은 거시 전략보다 미시적인 빈칸 채우기에 더 강하다.미래의 LLM 코딩은 어떤 느낌일까? 스타크래프트를 하는 느낌일까? 팩토리오? 아니면 음악을 연주하는 느낌일까?
사회 전반에서 디지털 지식 노동이 병목인 영역은 얼마나 될까?
Claude와 Codex를 중심으로 한 LLM 에이전트 능력은 2025년 12월쯤 어떤 ‘일관성의 임계점’을 넘어섰고
소프트웨어 엔지니어링과 그 인접 영역에 위상 변화를 일으켰다.
지능 자체는 이제 도구, 지식, 조직 워크플로우, 확산 같은 나머지 요소들보다 앞서 있는 느낌이다.
2026년은 이 새로운 능력을 산업이 소화해 나가는 매우 에너지 넘치는 해가 될 것이다.