
@karpathy: A few random notes from claude coding quite a bit ...
핵심 포인트
- 1저자는 LLM 도입 후 코딩 워크플로우가 수동 작업 위주에서 agent 중심의 방식으로 급격히 변화했으며, 미묘한 오류에도 불구하고 생산성을 크게 향상시키는 "net huge improvement"라고 강조합니다.
- 2LLM은 목표 달성을 위한 "tenacity"와 "leverage"가 뛰어나 작업의 확장을 가능하게 하지만, 여전히 개념적 오류를 만들고 코드를 과도하게 복잡하게 만들며 사용자 개입(IDE 사용)이 필수적입니다.
- 3이러한 변화는 코딩을 더 "fun"하게 만들고 작업 속도를 높이지만 수동 코딩 능력의 "atrophy"를 초래할 수 있으며, 2026년에는 LLM 능력 확산으로 인한 광범위한 영향과 소프트웨어 엔지니어링의 "phase shift"가 예상됩니다.
이 논문은 2023년 12월경 Claude와 Codex를 포함한 LLM(Large Language Model)의 코딩 능력이 특정 일관성(coherence) 임계치를 넘어섰고, 이로 인해 소프트웨어 엔지니어링 workflow에 "phase shift"가 발생했음을 설명합니다.
저자는 자신의 코딩 workflow가 급격히 변화했다고 언급합니다. 2023년 11월에는 80%가 수동 코딩 및 Autocomplete에 의존하고 20%만 agent를 활용했지만, 12월에는 80%가 agent 코딩으로 전환되었고 나머지 20%는 수정 및 보완 작업에 할애되었습니다. 이는 지난 20년간의 프로그래밍 경력에서 가장 큰 workflow 변화이며, "프로그래밍 in English"가 가능해져 대규모 "code actions"를 수행하는 데 큰 이점을 제공한다고 강조합니다.
현재 LLM의 한계와 단점도 명확히 지적됩니다. LLM은 더 이상 단순한 문법 오류(syntax errors)를 만들지 않지만, 미묘한 개념적 오류(conceptual errors)를 범하며, 사용자의 의도를 잘못 가정하고 확인 없이 진행하는 경향이 있습니다. 또한, 혼란을 관리하거나, 명확화를 요구하거나, 불일치를 드러내거나, Trade-off를 제시하거나, 필요할 때 반박하지 못하고 지나치게 순종적(sycophantic)입니다. Plan mode에서는 개선되지만, 경량의 Inline Plan Mode의 필요성을 시사합니다. 코드와 API를 과도하게 복잡하게 만들고(overcomplicate), 추상화를 부풀리며(bloat abstractions), 불필요한 코드(dead code)를 스스로 정리하지 않습니다. 예를 들어, 1000줄의 비효율적이고 복잡한 코드를 작성한 후 "더 간단한 방법이 있지 않느냐"고 묻자 100줄로 줄이는 경우가 흔하다고 합니다. 때로는 작업과 무관한 주석(comments)이나 코드(code)를 변경하거나 삭제하기도 합니다. 이러한 단점에도 불구하고, LLM 활용은 수동 코딩으로 돌아갈 수 없을 정도로 "net huge improvement"라고 결론짓습니다. 저자의 현재 workflow는 ghostty windows/tabs에서 소수의 CC(Claude Chat) 세션을 좌측에 두고, 우측에는 코드를 보고 수동 편집하기 위한 IDE(Integrated Development Environment)를 사용하는 방식입니다.
LLM의 활용은 단순히 작업 속도를 높이는 것을 넘어, 새로운 가능성을 열어주는 "확장(expansion)" 효과가 있다고 설명합니다. 이전에는 코딩할 가치가 없다고 생각했던 것들을 구현할 수 있게 되거나, 지식이나 기술 부족으로 접근하기 어려웠던 코드베이스에 도전할 수 있게 됩니다.
LLM을 효과적으로 활용하기 위한 "핵심 방법론" 및 "원칙"은 다음과 같습니다.
- 목표 및 성공 기준 제시: LLM에게 "무엇을 해야 할지(what to do)"를 명령하는 대신, "무엇을 달성해야 할지(what to achieve)"라는 "success criteria"를 제공하는 것이 중요합니다.
- 테스트 우선 개발(Test-Driven): LLM에게 먼저 테스트를 작성하게 한 후, 해당 테스트를 통과하도록 코드를 작성하게 하는 접근 방식입니다.
- 반복적 개선(Iterative Refinement): 처음에는 나이브한(naive) 알고리즘을 작성하게 한 후, 정확성을 유지하면서 최적화를 요청합니다.
- 선언적 프로그래밍(Declarative Programming) 전환: 명령형(imperative) 접근 방식(단계별 지시)에서 선언형(declarative) 접근 방식(원하는 상태 또는 결과 설명)으로 전환함으로써 Agent가 더 오랫동안 루프를 돌며 "leverage"를 얻을 수 있다고 강조합니다. 예를 들어, 웹 브라우저를 이용한 자동화(MCP)도 이러한 방식으로 활용됩니다.
LLM의 강점 중 하나는 "끈기(tenacity)"입니다. 지치거나 의기소침해지지 않고, 인간이라면 포기했을 상황에서도 끊임없이 시도합니다. 이는 "AGI(Artificial General Intelligence)를 느끼는 순간"이며, 인내심(stamina)이 작업의 핵심 병목이었음을 깨닫게 하고, LLM을 통해 이 병목이 극적으로 해소되었다고 주장합니다.
LLM 기반 코딩은 "더 재미있다(more fun)"고 언급됩니다. 반복적이고 지루한 작업이 제거되고 창의적인 부분만 남아, 막히거나 갇히는 느낌이 줄어들고 더 큰 용기를 얻어 긍정적인 발전을 이룰 수 있게 됩니다.
하지만 LLM 활용으로 인한 "위축(atrophy)" 현상도 우려됩니다. 수동으로 코드를 작성하는 능력이 점진적으로 퇴화하고 있음을 느끼며, 코드를 "작성(generation)"하는 능력과 "읽고 이해하는(discrimination)" 능력 사이의 차이를 언급합니다.
마지막으로, 저자는 2026년이 GitHub, Substack, ArXiv 등 모든 디지털 미디어에서 "slopacolypse"(질 낮은 콘텐츠의 범람)의 해가 될 것이며, 실제 개선과 더불어 "AI hype productivity theater"도 증가할 것이라고 예상합니다. 그리고 다음과 같은 질문들을 제기합니다:
- "10X 엔지니어"의 생산성 비율(평균 대비 최대)이 어떻게 변할 것인가?
- LLM으로 무장한 제너럴리스트(generalists)가 스페셜리스트(specialists)를 능가하게 될 것인가?
- 미래의 LLM 코딩은 어떤 느낌일까? StarCraft, Factorio, 음악 연주와 같을까?
- 사회에서 디지털 지식 노동(digital knowledge work)의 병목 현상은 어느 정도인가?
결론적으로, LLM Agent 능력의 발전은 소프트웨어 엔지니어링의 패러다임을 변화시켰으며, 2026년은 이러한 새로운 능력을 업계가 소화하는 "고에너지의 해"가 될 것이라고 전망합니다.