Andrej Karpathy의 최근 몇 주간 Claude 코딩 경험에 대한 단상
(x.com/karpathy)코딩 워크플로우의 변화
- 2024년 11월에는 80% 수동+자동완성, 20% 에이전트 코딩이었으나, 12월에는 이 비율이 역전되어 80% 에이전트 코딩, 20% 수정/터치업으로 전환
- 실질적으로 영어로 프로그래밍하는 상황이 되었으며, LLM에게 어떤 코드를 작성할지 말로 지시하는 형태
- 자존심이 상하는 부분이 있지만, 대규모 "코드 액션" 단위로 소프트웨어를 다루는 힘이 너무나 유용
- 이에 적응하고, 설정하고, 사용법을 배우고, 가능/불가능한 것을 파악하면 더욱 효과적임
- 약 20년간의 프로그래밍 경력에서 가장 큰 기본 코딩 워크플로우 변화이며, 불과 몇 주 만에 발생함
- 상당수(두 자릿수 퍼센트)의 엔지니어들에게 비슷한 일이 일어나고 있을 것으로 예상되나, 일반 대중의 인식은 한 자릿수 초반 퍼센트 수준으로 추정
IDE/에이전트 스웜/오류 가능성
- "더 이상 IDE 필요 없다" 또는 "에이전트 스웜" 관련 과대광고는 현재로서는 과장이라고 생각함
- 모델은 여전히 실수를 하며, 실제로 중요한 코드가 있다면 매의 눈으로 감시해야 하고, 옆에 큰 IDE를 띄워두는 것이 필요
- 실수의 성격이 변화함: 더 이상 단순 문법 오류가 아니라, 약간 부주의하고 성급한 주니어 개발자가 저지를 법한 미묘한 개념적 오류
- 가장 흔한 오류 유형: 사용자 대신 잘못된 가정을 세우고 확인 없이 그대로 진행
- 추가적인 문제점:
- 혼란을 관리하지 못함
- 명확화 요청을 하지 않음
- 불일치를 드러내지 않음
- 트레이드오프를 제시하지 않음
- 반박해야 할 때 반박하지 않음
- 여전히 다소 아첨하는(sycophantic) 경향이 있음
- 플랜 모드에서는 나아지지만, 경량의 인라인 플랜 모드가 필요함
- 코드와 API를 과도하게 복잡화하는 경향도 있고, 추상화를 비대하게 만들고, 작업 후 죽은 코드를 정리하지 않음
- 1000줄에 걸쳐 비효율적이고 비대하며 취약한 구조를 구현하는 경우가 있으며, "이렇게 하면 안 되나요?"라고 물으면 "물론이죠!"라며 즉시 100줄로 줄임
- 작업과 무관하더라도 마음에 들지 않거나 충분히 이해하지 못한 주석과 코드를 변경/삭제하는 경우가 여전히 있음
- CLAUDE.md에 지침을 넣어 간단히 수정 시도를 해도 이런 문제들이 발생
- 이런 문제에도 불구하고 여전히 순수하게 거대한 개선이며, 수동 코딩으로 돌아가기는 매우 어려움
- 현재 워크플로우: 왼쪽에 ghostty 윈도우/탭에서 소수의 Claude Code 세션, 오른쪽에 IDE로 코드 확인 및 수동 편집
끈기(Tenacity)
- 에이전트가 쉬지 않고 무언가에 매달리는 것을 보는 것은 매우 흥미로움
- 지치지 않고, 의기소침해지지 않으며, 인간이라면 다음을 기약하며 오래전에 포기했을 상황에서도 계속 시도함
- 무언가와 오랫동안 씨름하다가 30분 후 결국 성공하는 것을 지켜보면 "AGI를 느끼는" 순간 같음
- 스태미나가 작업의 핵심 병목이라는 것을 깨닫게 되며, LLM을 손에 들면 이것이 극적으로 증가됨
속도 향상
- LLM이 보조하는 것의 "속도 향상"을 어떻게 측정할지 불분명함
- 하려던 일이 확실히 훨씬 빨라진 느낌이지만, 주요 효과는 하려던 것보다 훨씬 더 많은 것을 하게 됨:
- 이전에는 코딩할 가치가 없었을 온갖 것들을 코딩 가능
- 지식/스킬 문제로 이전에는 작업할 수 없었던 코드에 접근 가능
- 속도 향상이지만, 더 많은 부분은 확장(expansion) 일 가능성이 있음
레버리지
- LLM은 특정 목표를 충족할 때까지 루프를 돌리는 데 탁월하며, 이것이 "AGI를 느끼는" 마법의 대부분
- 무엇을 할지 지시하지 말고, 성공 기준을 주고 지켜볼 것
- 테스트를 먼저 작성하게 하고 그것을 통과하게 할 것
- 브라우저 MCP와 루프에 넣을 것
- 정확성이 매우 높을 것 같은 나이브 알고리듬을 먼저 작성하고, 정확성을 유지하면서 최적화 요청
- 명령형에서 선언형으로 접근 방식을 바꾸면 에이전트가 더 오래 루프를 돌며 레버리지를 확보함
재미
- 예상하지 못한 부분은 에이전트와 함께하면 프로그래밍이 더 재미있어 진다는 것
- 빈칸 채우기 식의 지루한 작업이 제거되고 창의적인 부분만 남음
- 막힘/정체(재미없는 상태)가 줄어들고, 더 많은 용기를 경험하게 됨 — 항상 함께 긍정적 진전을 이룰 방법이 있기 때문
- 반대 감정을 가진 사람들도 있음: LLM 코딩은 코딩 자체를 좋아하는 엔지니어와 만드는 것을 좋아하는 엔지니어로 나누게 됨
퇴화(Atrophy)
- 수동으로 코드를 작성하는 능력이 서서히 퇴화하기 시작했다는 걸 알게 됨
- 생성(코드 작성) 과 판별(코드 읽기) 은 뇌에서 다른 능력
- 프로그래밍에 관련된 작은 문법적 세부 사항들로 인해, 작성에 어려움을 겪더라도 코드 리뷰는 문제없이 가능
슬로파칼립스(Slopacolypse)
- 2026년은 GitHub, Substack, arXiv, X/Instagram 및 일반적으로 모든 디지털 미디어에 걸쳐 슬로파칼립스(저품질 AI 생성 콘텐츠 범람)의 해가 될 것으로 예상
- 실제 진정한 개선 외에도 훨씬 더 많은 AI 과대광고 생산성 극장이 나타날 것(그게 가능하기나 한가?)
질문들
- "10X 엔지니어"에게 무슨 일이 일어나고 있을까? — 평균과 최고 엔지니어 간의 생산성 비율? 이 비율이 크게 증가할 가능성 있음
- LLM으로 무장하면, 제너럴리스트가 스페셜리스트를 점점 더 능가하게 될까? LLM은 빈칸 채우기(마이크로)에서 대전략(매크로)보다 훨씬 뛰어남
- 미래의 LLM 코딩은 어떤 느낌일까? 스타크래프트를 하는 것 같을까? 아님 팩토리오를 하거나, 음악을 연주하는 것 같을까?
- 사회의 얼마나 많은 부분이 디지털 지식 노동에 의해 병목처럼 막혀있을까?
TLDR
- Claude와 Codex 등 LLM 에이전트 역량이 2025년 12월경 어떤 종류의 일관성 임계점을 넘어 소프트웨어 엔지니어링 및 관련 분야에 위상 변화(phase shift) 를 발생 시킴
- 지능 부분이 갑자기 나머지 모든 것 — 통합(도구, 지식), 새로운 조직 워크플로우의 필요성, 프로세스, 더 일반적인 확산 — 보다 상당히 앞서 있는 느낌
- 2026년은 업계가 새로운 역량을 소화하는 고 에너지의 해가 될 것
이 글에 있는 내용 기반으로 Claude Code 의 동작을 개선시키는 skills 버전도 공개되었네요.
Karpathy-Inspired Claude Code Guidelines : https://github.com/forrestchang/andrej-karpathy-skills
계속해서 드는 의문이지만 이미 수작업 코딩으로 몸에 익은 사람들이 LLM을 감독하는건 좋은데 새로 배우는 사람들은 LLM이 만들어주는 코드만 쳐다보면 어떻게 이게 맞는지 아닌지 알기 어려울 것 같아요
옛날 어셈블러로 짜던 사람들은 컴파일러 나올 때 개떡같은 어셈 출력물 내놓는 컴파일러를 어떻게 믿냐 같은 생각을 했으려나요
그때도 C로 짜면서도 어셈 출력물이 원하는대로 나오도록 유도하면서 코딩했을텐데
AI 시대도 더 발전하면 사람의 감독 없이 자연어로 완성본이 잘 나오게 될지 궁금하긴 합니다.
어셈 전문가들은 아직도 컴파일러 욕합니다. 결국 중요한건 극한의 최적화가 필요한 상황에선 그런 스페셜리스트가 필요하다는 건데 ai에 대입해보면 ai가 이무리 발전해도 극한으로 잘 짜는 사람을 이기기 힘들수도 있습니다. 제네럴하게는 이미 어떤 인간도 ai를 이길 수 없지만요. 또한번의 알파고 모먼트로 알파코드 대결이 있으면 재밌을듯
만들어주는 코드를 분석하고 이해하려는 노력이 있다면 괜찮을 것 같습니다.
컴파일러는 조금 다른 개념인게, 규칙기반으로 어셈블리를 생성하므로 결정적 영역이기 때문에 오히려 한번 검토하면 그 다음은 문제가 재발하지 않지만, LLM은 확률적 영역이기 때문에 문제가 재발할 여지가 있으니까요.
이 확률 정확성 더 발전하면 100프로에 가까워질지 모르나, 자연어 요구 자체가 부정확하다면 결국 결과도 부정확해지므로 좋은 완성본은 결국 사람한테 달려있지 않나 싶습니다.
저도 학생 때부터 LLM을 접한 주니어 분들이 걱정되더라고요. 주니어 채용 풀이 조금 안좋아진 것 같다는 생각도 들긴하는데, 증명하기는 또 어렵고...
개인적으론 CS지식만 있으면 별 차이 없지 않나 싶어요
아니면 제가 지금 활용하는 방식은 손이 엄청 빠르고 코드를 모두 쳐주는 친구와 페어 프로그래밍 하는 느낌으로 사용해서 그럴지도...
결국 깊게 개발하다보면 추상화 레이어 안쪽을 알아야 할 때가 오기 마련인데
자연어 프롬프트와 생성된 코드 사이의 간극은 너무 커서 프롬프트에서 LLM 추상화 레이어 안쪽으로 들어가는건 힘들어보여요
지금의 우리들은 머릿속에 있던 명세의 개념을 프롬프트로 LLM에 전달한 다음 작성된 코드를 다시 읽어서 검증하는 방식이니
다른 사람이 작성한 코드를 리뷰하는 형태에 가까워서 추상화 안쪽으로 들어가는 느낌이 들진 않네요
크게 공감하고 있습니다. 최근 프로젝트에서 10만줄 정도 커밋했고 (실제 코드량은 더함) 평균 2-3개의 에이전트를 사용하고 있습니다. 저는 95% 정도 에이전트가 작성하는 것 같습니다.
하지만 여전히 테스트나 죽은 코드들에 대해서는 관리가 필요하고, 테스트 케이스와 테스트 성공 조건에 대한 디테일이 필요합니다. 무엇을 어디까지 해야하는지에 대한 관리가 중요합니다. 그러기 위해서는 플랜뿐 아니라 하네스를 만들어주는 아키텍처, Rules 등의 셋팅을 지속적으로 업데이트 해야합니다.
Hacker News 의견들
-
에이전트가 지치지 않고 계속 시도하는 모습을 보는 게 흥미로움
GPU와 NPU가 뜨겁게 돌아가며, 우리는 평소라면 공유하지 않을 데이터까지 넘기고 있음
지금은 편리한 거래처럼 보이지만, 장기적으로 의존성과 사회적 문제가 커질 위험이 있음
결국 이 거대한 게이트키퍼에 종속되는 구조가 될 수 있음-
끈기가 지난 20년간 테크 업계에서 성공의 핵심 요소였다고 생각함
- 새로운 프로토콜이나 프레임워크를 만든 사람보다, 복잡한 시스템을 끝까지 붙잡고 해결한 사람이 훨씬 많았음
- Claude 같은 모델이 바로 그 끈기를 보여줌
- 하지만 이런 끈기가 항상 좋은 건 아님
- 종종 망치로 나사를 박는 것처럼, 비효율적인 방식으로 문제를 해결하려는 모습 같음
- 단기적으로는 결과를 내지만 장기적으로는 부작용을 남김
- AI가 항상 올바른 길로 간다고 보기 어려움
- 테스트가 없는 부분에서 새로운 버그를 만들거나, 인간이라면 당연히 지킬 암묵적 규칙을 깨기도 함
- 결국 “코인 좀 더 넣으면 이번엔 진짜 고쳐줄게요” 같은 느낌을 줌
- 비용 문제는 과장된 우려라고 생각함
- 이미 Kimi K2.5나 GLM 4.7 같은 오픈 모델이 상용 수준에 근접했고, 운영비도 낮음
- 진짜 돈이 드는 건 학습 단계이지, 추론 단계는 이윤이 남는 구조임
- “AI는 점점 싸질 것이다”라는 말에 동의함
- 인류 역사상 기술이 비싸진 채로 남은 적은 거의 없음
- 실제로 작년 대비 절반 수준으로 비용이 줄었음
-
끈기가 지난 20년간 테크 업계에서 성공의 핵심 요소였다고 생각함
-
AI와 함께 일하면서 두뇌 위축보다 더 큰 문제는 자기만족과 무기력으로 변하는 것 같음
처음엔 빠른 결과에 도파민이 솟지만, 반복될수록 AI가 프로젝트 방향을 자기 멋대로 끌고 가는 느낌임
결국 내가 원하던 창의적 실험은 사라지고, AI의 잠재공간 중력에 빨려 들어감
이건 마치 둠스크롤링처럼, 계속 다음 출력을 보고 싶어지는 중독적 루프임- 나도 비슷한 경험을 함
Rust와 Bevy로 멀티플레이 게임을 만들고 있는데, 코드가 잘 돌아가도 내가 이해하지 못하는 코드가 됨
예전엔 도구를 완전히 이해해야 여기까지 왔을 텐데, 지금은 반쯤 작동하는 게임을 만들었지만 ECS가 뭔지도 모름
유지보수나 긴급 대응을 생각하면 이건 진짜 위험한 상태임 - 단순한 뇌 위축이 아니라, 학습 방향의 전환이 문제라고 봄
우리는 이제 모델을 배우는 데 집중하고, 스스로 사고하는 법을 잊고 있음
LLM 사용법은 계속 바뀌기 때문에, 결국 영원한 러닝 트레드밀 위에 서 있는 셈임 - 반면 어떤 사람은 “코딩은 자전거 타기 같다”고 말함
오랜 공백이 있어도 감각은 남아 있고, 다시 타면 금방 돌아옴 - 또 다른 문제는 ‘읽기 위축’ 임
LLM이 모르면 그냥 포기하고, 문서를 읽지 않으려는 개발자가 늘고 있음
직접 문서를 읽어 스크린샷까지 보여줘도 “이게 맞을까?”라며 의심함 - LLM 사용이 틱톡식 도파민 루프와 닮았다고 느낌
짧은 쾌감 때문에 계속 프롬프트를 던지고, “이번엔 뭐가 나올까”를 기다리게 됨
- 나도 비슷한 경험을 함
-
LLM 코딩은 ‘코딩을 좋아하는 사람’과 ‘빌딩을 좋아하는 사람’ 을 나누는 계기가 됨
나는 결과를 만드는 걸 좋아하는 빌더형이라, 이 변화가 즐거움
반면 코딩 자체를 즐기는 사람들은 이 흐름에 불편함을 느낌- 나도 그 중 하나임
프로그래밍의 매력은 문제를 구조화하고 직접 실행하는 과정에 있었음
지금은 “내가 코딩을 하는 게 아니라 시키는 느낌”이라 흥미가 줄어듦 - 사실 이런 논쟁은 새롭지 않음
과거에도 컴파일 vs 인터프리트, 타입 vs 무타입, 빠른 배포 vs 유지보수성 같은 대립이 있었음
결국 성공한 소프트웨어는 혼란스러운 초기 단계에서 안정적 확장 단계로 넘어가는 과정을 거침
AI가 이 과정을 돕는지, 오히려 복잡하게 만드는지는 아직 확신이 없음 - 또 다른 시각으로는 ‘설계 자체를 즐기는 사람’ 도 있음
단순히 결과물이 아니라, 시스템 구조를 짜는 과정에서 재미를 느낌 - LLM 회의론은 탑다운 vs 보텀업 개발 스타일의 충돌로 볼 수도 있음
- 하지만 “AI를 신뢰할 수 있느냐”는 여전히 문제임
인간 팀원은 책임과 신뢰가 있지만, LLM은 그렇지 않음
- 나도 그 중 하나임
-
AI가 10배 생산성 향상을 가져올 수 있다는 생각이 흥미로움
DevOps가 개발-운영 협업 방식을 바꿔서 고성능 팀을 만들었고, 이게 팀 버전의 10X에 가까운 효과로 이어짐
AI 코딩을 잘 쓰려면 DevOps처럼 지속적 개선, 워크플로우 변경, 자동화/검증으로 신뢰를 쌓는 과정 필요
DevOps도 새로운 개념 학습과 팀 문화 변화가 필요해서 널리 퍼지지 못했듯, AI 코딩도 학습/문화 변화가 없으면 10X 잠재력이 있어도 적응이 더딜 수 있음
정착을 위해 교육과 엔지니어링 문화 변화 필요 -
LLM이 대규모 코드베이스에서 쓸모없다고 느꼈음
특히 복잡하고 상호작용이 많은 코드에서는 거의 도움이 안 됨- 하지만 나는 Claude 코드로 98% 작성된 iOS 앱을 3개월 만에 완성했음
- “이런 사례는 대부분 그린필드 프로젝트”임
기존 대형/복잡 코드베이스에 넣는 것은, 면밀한 리뷰가 붙는 제한적 변경이 아니면 위험함
단순 구조에서 파일 목록을 주고 에이전트에게 구현을 맡기는 방식은 인상적이지만, 복잡도가 올라가면 프롬프트가 점점 더 세부 지시로 내려가야 성과가 남 - “ChatGPT가 아니라 Codex나 Claude CLI 같은 로컬 컨텍스트 도구를 써야 함”
-
Opus 4.5 모델이 진짜 전환점이었음
이전 모델과 달리, 이제는 복잡한 모노레포에서도 실질적 도움을 줌 - “LLM이 쓸모없다”는 평가는 맥락 부족 때문일 수 있음
새 팀원이 같은 정보로 일했을 때보다 나은지 비교해볼 것 - LLM은 LLM이 만든 코드베이스에서 더 잘 동작하는 경향이 있음
상용 사내 코드베이스는 고객 요구에 맞춘 반복 개발로 지저분해지고, 초기 가정과 요구가 점점 어긋나며 기술 부채가 생기게 됨
LLM을 써서 헬퍼 분리/모듈화/리네이밍 같은 리팩터로 현재 요구에 맞게 정리하면, 이후 에이전트 동작이 더 예측 가능해짐 - 좋은 문서화와 아키텍처 설명, 스타일 가이드 같은 프로젝트 문맥 정리가 중요
요구사항/수용 기준/유저 스토리를 markdown으로 정리하고, 계획을 세부적으로 쓰게 한 뒤 구현으로 넘어가는 단계적 흐름이 필요
-
AI의 끈기와 체력이 인간의 한계를 넘어서는 지점이 인상적임
연구에서도 지능보다 끈기(grit) 가 성공과 더 밀접하다고 함
LLM은 예산이 허락하는 한 무한한 끈기를 가짐 -
최근 몇 달간 AI 성능이 오히려 퇴보한 것처럼 느껴짐
규칙을 잊고, 과도한 계획과 과설계 코드를 생성함
다만 프론트엔드(HTML + Tailwind)에서는 여전히 유용함- 이에 “이건 마치 FrontPage 시절로 돌아간 느낌”
- 다른 사람은 “그건 Sonnet 모델일 것, Opus 4.5를 써볼 것”
-
IDE나 에이전트 스웜에 대한 과도한 기대는 시기상조라고 느낌
- 10년째 쓰던 JetBrains를 버리고 Zed와 Claude Code만 쓰고 있음
- 예전엔 몇 달 걸릴 작업을 몇 시간 만에 완성할 수 있게 됨
-
iPhone 앱을 만들며 Claude의 영어 프롬프트 기반 코드 생성력에 감탄함
- Swift 경험이 없어도 C++ 배경만으로 충분히 진행 가능했음
- 큰 프롬프트보다 작은 단위로 기능을 추가하고 검토하는 방식이 훨씬 효율적임
- 이 과정을 Prompt → Review → Test (PRET) 라는 새로운 워크플로우로 부르고 있음
LLM 코딩은 코딩 자체를 좋아하는 엔지니어와 만드는 것을 좋아하는 엔지니어로 나누게 됨
저도 주변에서 듣는 얘기들을 종합해보면 결국 이렇게 나뉘는 것 같아요.