Andrej Karpathy 씨가 최근 몇 주 동안 Claude를 사용하여 코딩하며 느낀 점을 X에 장문으로 게시했습니다. 서두는 「A few random notes from claude coding quite bit last few weeks.」라는 가벼운 문구로 시작하지만, 내용은 코딩 워크플로(Coding workflow)의 페이즈 시프트(Phase shift) · LLM의 실패 패턴 · 레버리지(Leverage) 활용법 · 기술의 위축 · 2026년의 slopacolypse까지 아우르는 밀도 높은 내용이었습니다.

Karpathy 씨는 OpenAI의 창립 멤버 중 한 명으로, Tesla에서는 AI / Autopilot 부문을 이끌었으며, Stanford의 딥러닝 강의 「CS231n」을 설계 및 담당한 것으로도 알려진 연구자이자 엔지니어입니다. 최근에는 「Software 2.0」이나 「vibe coding」과 같은 용어의 발신지로도 자주 언급되며, AI와 소프트웨어 개발의 관계에 대한 발언이 주목받는 인물입니다. 이번 게시물도 그러한 입장에서의 「현장에서 충분히 사용해 본 소감」으로 읽는다면 그 온도감을 파악하기 쉬울 것입니다.

이 게시물에서 Karpathy 씨가 지적한 「LLM의 버릇」을 CLAUDE.md라는 한 장의 Markdown 파일로 구현한 OSS가 GitHub에서 주목받고 있습니다. multica-ai/andrej-karpathy-skills라는 리포지토리로, 2026년 6월 말 시점에서 약 18.5만 스타 · 약 1.9만 포크(수치는 변동되므로 최신 정보는 GitHub에서 확인하십시오)를 기록하고 있습니다. 실행 코드는 거의 없으며, CLAUDE.md · CURSOR.md · EXAMPLES.md 등의 Markdown과 Claude Code / Cursor용 플러그인 설정 파일이 중심인 리포지토리입니다.

이 리포지토리의 GitHub 상 경로는 현재 multica-ai/andrej-karpathy-skills입니다. 이전 경로인 forrestchang/andrej-karpathy-skills로 접속하면 새 경로로 리다이렉트됩니다(git · raw 취득 시에도 이전 이름 그대로 동작합니다). 본 기사에서는 새로운 multica-ai/...를 정식 표기로 사용하지만, 후술할 내용과 같이 공식 README의 설치 커맨드에는 이전 소유자 이름이 남아 있는 부분이 있습니다.

본 기사에서는,

• Karpathy 씨가 게시물에 실제로 무엇을 썼는지
• 거기서 추출된 「LLM의 3가지 버릇」이란 무엇인지
• 그것을 억제하는 4원칙(Think / Simple / Surgical / Goal)의 내용
• 자신의 프로젝트에 도입할 때 고려해야 할 사항

을 원문과 OSS의 문서(Documentation)를 참조하며 정리해 나가겠습니다. Claude Code나 Cursor를 업무에서 사용하며 「diff가 너무 커진다」, 「요청하지 않은 부분까지 건드린다」라고 느끼는 분들에게 어떤 실마리가 되기를 바랍니다.

참고로 단정적인 표현은 피하고 있습니다. 원칙 자체가 「속도보다 신중함을 우선하는 설계 사상」이므로 모든 프로젝트에 맞는 것은 아닙니다. 어디까지나 「이러한 설계의 OSS가 있다」, 「자신의 팀에서 부분적으로 도입할 가치가 있을지도 모른다」라는 관점으로 읽어주시면 감사하겠습니다.

먼저 게시물 전체를 조망해 두겠습니다. 4원칙 이야기만 다루면 Karpathy 씨가 제시한 맥락의 절반 정도를 놓치게 되기 때문입니다.

게시물은 테마별로 라벨링되어 있으며, 대략 다음과 같은 구성이었습니다.

이 게시물 속에서 4원칙 OSS가 직접적인 기반으로 삼고 있는 것은 **「IDEs / agent swarms / fallability」**와 「Leverage」 두 섹션입니다. 전자는 「LLM이 저지르는 버릇」을 나열하고, 후자는 「그렇다면 어떻게 사용하는 것이 효과적인가」를 제안합니다.

「IDEs / agent swarms / fallability」 섹션에는 현재의 코딩 에이전트가 일으키는 실수 리스트가 거의 불렛 포인트(Bullet point) 형태로 나열되어 있었습니다. 요점을 추출하면 다음과 같습니다.

• 확인 없이 멋대로 가정을 세우고 실행함
• 자신의 혼란을 관리하지 않고 명확화를 요구하지 않음
• 모순을 표면화하지 않음
• 트레이드오프 (Trade-off)를 제시하지 않음
• 밀어붙여야 할 상황에서 밀어붙이지 않음
• 여전히 다소 아첨하는 (sycophantic) 경향이 있음
• 코드나 API를 과도하게 복잡하게 만듦
• 추상화를 부풀림
• 자신이 작성한 데드 코드 (Dead code)를 정리하지 않음
• 1000줄로 작성한 구조를 인간이 "이 정도면 되지 않을까?"라고 말하면 즉시 100줄로 축소함
• 태스크와 직교(Orthogonal)하지 않더라도, 마음에 들지 않는 주석이나 코드를 부수 효과적으로 다시 쓰거나 삭제함
• 이것들은 CLAUDE.md에 약간의 규칙을 적는 정도로는 사라지지 않는다

마지막 한 줄이 개인적으로 가장 가슴에 와닿습니다. "CLAUDE.md를 작성하는 것만으로는 사라지지 않는다"는 점은, 저 자신도 Claude Code를 업무에서 사용하며 느끼는 감각과 일치했습니다. 그럼에도 Karpathy 씨는 "인터넷상에서는 여전히 큰 개선이며, 수작업으로 돌아가는 것은 상상하기 어렵다"라고 마무리합니다.

multica-ai/andrej-karpathy-skills의 README는 이 긴 리스트를 3가지 습관으로 묶어 요약하고 있습니다.

• wrong assumptions without checking (확인 없는 멋대로의 가정)
• overcomplicate code (과도한 복잡화)
• unintentionally modify unrelated code (무관한 코드를 의도치 않게 수정)

긴 열거를 3점으로 압축했기에 그만큼 놓치는 뉘앙스도 있습니다 (예를 들어 "sycophantic"나 "데드 코드를 정리하지 않음" 등은 독립적인 과제이기도 합니다). 다만, 대책 규칙으로 옮기는 데 있어서는 이 3점으로 집약하는 정리가 실용적이라고 느꼈습니다.

리포지토리에서는 위의 3가지 습관에 대응하는 형태로 4가지 원칙을 정의하고 있습니다.

3가지 습관에 대해 원칙은 4개이며, 마지막 Goal-Driven Execution은 "습관에 대한 대책"이라기보다, Karpathy 씨의 "Don't tell it what to do, give it success criteria and watch it go." (무엇을 할지 말하지 말고, 성공 기준을 주고 지켜보라)라는 Leverage의 한 구절을 운영 규칙으로 변환한 것으로 보입니다.

도입 방법은 놀라울 정도로 간단합니다. CLAUDE.md를 프로젝트 루트에 한 장 두거나, Claude Code의 플러그인을 넣거나, Cursor라면 .cursor/rules/에 배치하는 것 중 하나입니다. 코드는 거의 없으며, Markdown이 언어 인터페이스가 되어 있다는 점이 특징적입니다.

여기서부터는 원칙별로 리포지토리가 README와 EXAMPLES.md에서 보여주는 사고방식을 저만의 언어로 정리하겠습니다. 구체적인 예시는 원문의 의도를 바탕으로 재구성했습니다.

멋대로 가정을 세우지 않고, 필요에 따라 확인이나 대안 제시를 수행하는 규칙입니다.

예를 들어 "사용자 정보를 내보내는 기능을 추가해 주세요"라는 요청이 왔다고 가정해 봅시다. 이는 언뜻 보면 명확한 요구사항처럼 보이지만, 구현 단계로 들어가면 모호한 점이 여러 가지 있습니다.

• 대상은 전체 사용자인가, 현재 로그인 중인 사용자인가
• 출력은 파일 다운로드인가, API 응답인가, 이메일 전송인가
• 포함할 필드는 무엇인가. 민감 정보는 어떻게 처리할 것인가
• 건수나 빈도는 어느 정도로 예상하는가

Bad 패턴은 이것들을 스스로 "아마 이럴 것이다"라고 결정하고 그대로 구현까지 진행해 버리는 것입니다. 나중에 "아니, 그게 아닙니다"라는 말을 듣게 되면 PR을 통째로 다시 작성해야 하는 비용이 발생합니다.

Good 패턴은 구현에 들어가기 전에 불명확한 점을 불렛 포인트로 반환하거나, 여러 해석을 A / B / C로 나열하여 선택하게 하는 것입니다. 나아가 "그보다 더 심플한 접근 방식이 있다면 그것을 제안한다"도 포함됩니다.

인간 시니어 엔지니어가 신입에게 리뷰에서 요구하는 것과 같지만, LLM은 기본적으로 이를 수행하지 않습니다. 그렇기에 "수행한다"라고 규칙에 적어두는 것이 이 원칙의 발상입니다. 다만, 요청이 충분히 명확한 경우에 매번 확인을 거치는 것은 번거로우므로, 요청의 모호함에 따라 균형을 맞추는 것이 현실적이라고 느낍니다.

요구되지 않은 기능이나 추상화를 넣지 않는다는 규칙입니다.

예를 들어 "상품의 할인액을 계산하는 함수"를 요청했다고 가정해 봅시다. 본래는 금액에 할인율을 곱해서 빼기만 하면 되는, 몇 줄짜리 함수로 끝날 일입니다.

Bad 패턴은, DiscountStrategy와 같은 추상 기저 클래스 (Abstract Base Class)를 만들고, PercentageDiscount · FixedAmountDiscount를 파생시켜 설정 파일로부터 전략 (Strategy)을 전환하는 설계를 단번에 구축해 버리는 경우입니다. 얼핏 보기에는 깔끔해 보이지만, 현재 사용되는 할인 방식은 단 한 종류뿐이며, "나중에 늘어날지도 모른다"라는 가정만으로 구조가 비대해진 상태입니다.

Good 패턴은, 심플한 함수 하나로 구현해 두고, "두 번째 할인 방식이 실제로 필요해진 시점에 추상화 (Abstraction)를 도입한다"라는 판단을 남겨두는 것입니다.

리포지토리의 기준으로 인상적이었던 것은, **"시니어 엔지니어가 보고 '이거 너무 복잡하지 않아?'라고 말한다면 단순화한다"**라는 표현입니다. 혼자서 작성할 때는 알아차리기 어려운 복잡성을 외부의 시선으로 측정하기 위한 기준으로 삼고 있었습니다.

여기서 주의해야 할 점은, 이것이 "항상 미니멀한 것이 정답이다"라고 말하는 것이 아니라는 점입니다. 예를 들어 운영 기간이 길고, 변경 빈도가 높으며, 여러 전략이 확실히 필요한 영역에서는 처음부터 추상화를 넣는 것이 더 좋을 수도 있습니다. "현 시점에서 필요한 것만 작성한다"와 "미래를 내다보고 설계한다" 사이의 균형 자체는 각 프로젝트의 상황에 따라 달라진다고 생각합니다.

요청받은 부분만을 정밀하게 변경하는 규칙입니다.

예를 들어 "이메일 주소 검증기 (Validator)가 빈 문자열을 전달했을 때 크래시가 발생하는 버그를 수정해 달라"는 요청이 왔다고 가정해 봅시다. 본래 필요한 변경은 빈 문자열이나 공백 문자를 체크하는 몇 줄뿐입니다.

Bad 패턴은, 덤으로 다음과 같은 일들을 해버리는 경우입니다.

• 옆에 있던 username의 검증 함수까지 강화한다
• 전체의 따옴표를 싱글 쿼트에서 더블 쿼트로 통일한다
• 타입 힌트 (Type Hint)를 추가한다
• 한 줄 주석을 docstring으로 바꾼다

이것들은 개별적으로는 "개선"일지 모르지만, 요청과 직접 대응하지 않는 변경이 섞이기 때문에, 리뷰하는 쪽에서는 "어느 것이 진짜 버그 수정인지"를 매 행마다 확인해야 합니다.

Good 패턴은,

• 필요한 행만 변경한다
• 기존 스타일 (따옴표, 명명 규칙, 주석의 밀도)에 맞춘다
• 자신이 수정한 것으로 인해 불필요해진 기존 코드만 삭제한다
• 건드리지 않은 기존 데드 코드 (Dead Code)는 "사용되지 않는 코드가 있습니다"라고 언급하는 데 그치고, 삭제 판단은 인간에게 맡긴다

라는 동작입니다. 셀프 체크 기준으로 **"모든 변경 행이 사용자의 요청에 직접 대응한다고 설명할 수 있는가"**를 한 줄씩 자문하는 규칙이 세워져 있습니다.

다만, 이 역시 "절대로 건드리지 마라"는 뜻이 아니라, "건드릴 거라면 요청으로서 명시하라"는 운영에 가까운 것이라고 이해하고 있습니다. 리팩터링 (Refactoring)이나 정렬을 요청했을 경우에는 당연히 수행해 줍니다.

태스크를 "검증 가능한 성공 조건"으로 변환한 뒤 움직이는 규칙입니다. Karpathy 씨의 "Don't tell it what to do, give it success criteria and watch it go. (무엇을 하라고 말하지 말고, 성공 조건을 주고 지켜보라)"를 가장 직접적으로 체현하는 원칙입니다.

Bad 패턴은, "코드를 리뷰해서 문제를 찾아 개선해 줘"와 같이 무엇을 기준으로 완료할지가 불분명한 요청 방식입니다. LLM은 이런 요청을 받으면 무한히 "개선 같은 것들"을 계속 내놓을 수 있어, 멈출 타이밍을 알 수 없습니다.

Good 패턴은,

• 먼저 실패하는 테스트를 작성한다
• 그 테스트를 통과하는 방식으로 구현한다
• 테스트가 통과하고, 기존 테스트가 깨지지 않았는지 확인한다
• 필요에 따라 재귀적으로 루프 (Loop)를 돌린다

라는 흐름을 세트로 지시하는 것입니다.

성공 조건이 명확하면, LLM은 특기인 "루프를 돌며 목표로 수렴하는" 모드에 들어갑니다. Karpathy 씨가 Leverage 섹션에서 언급했던 "소박하고 올바른 알고리즘을 먼저 작성하게 한 뒤, 그 올바름을 유지하면서 최적화하게 만든다", "브라우저 MCP와 조합하여 루프에 넣는다"도 근본적으로는 같은 발상입니다.

이 원칙은 스스로 코드를 작성할 때 쓰기 좋은 프롬프트로 활용할 수 있습니다. 반면, 초보자에게는 "성공 조건을 테스트로 작성하는 것" 자체가 학습 비용이 되는 측면도 있으므로, 테스트를 작성하는 문화가 희박한 프로젝트에서는 우선 최소한의 스모크 테스트 (Smoke Test)부터 시작하는 것이 현실적일지도 모릅니다.

4가지 원칙 중에서 제가 가장 도전적이라고 느낀 것은 Goal-Driven Execution입니다.

Karpathy 씨의 게시물 중 Leverage 섹션은 리포지토리의 README에서도 다음과 같이 인용되고 있습니다.

"LLMs are exceptionally good at looping until they meet specific goals... Don't tell it what to do, give it success criteria and watch it go."

요지를 풀어서 설명하면, 다음과 같은 방식의 상호작용을 제안하고 있습니다.

• LLM은 "특정 목표에 도달할 때까지 루프(looping)를 도는 것"에 매우 능숙함
• 무엇을 할지 세세하게 명령하는 것이 아니라, 성공 조건(success criteria)을 전달하여 실행하게 함
• 먼저 테스트를 작성하게 하고, 이를 통과하는 방식으로 구현하게 함
• 상호작용 방식을 명령형 (imperative)에서 선언형 (declarative)으로 전환함

이는 코딩 에이전트(coding agent)에 대한 상호작용 방식을 명령형 (imperative)에서 선언형 (declarative)으로 전환하라는 제안이기도 합니다. 참고로 마지막 두 가지 사항은 README 상에서 Karpathy 씨의 인용구 그 자체는 아니며, 원칙인 "Goal-Driven Execution"으로서 운영 규칙화된 형태(명령을 선언적인 목표로 변환하는 등)로 제시되어 있습니다.

지금까지는 "다음에 이걸 하고, 그다음에 이걸 해"라며 절차를 세세하게 지시하는 것이 에이전트를 안전하게 움직이는 요령이었습니다. 하지만 에이전트의 정합성(consistency)이 한 단계 높아진 현재는, 절차보다 **목표(goal)와 제약 조건(constraints)**을 전달하는 것이 자율 주행의 레버리지(leverage)를 높이기에 더 유리하다는 관찰입니다.

구현 규칙으로서의 Goal-Driven Execution은 "태스크를 받으면, 먼저 검증 가능한 성공 조건으로 변환한 뒤에 움직인다"라는 운영 방식으로 번역됩니다. 단순해 보이지만, 직접 운영해 보면 요청하는 측의 스킬도 요구되는 원칙이라는 것을 느끼게 됩니다. 무엇이 완료인지 스스로 언어화할 수 없는 태스크는 에이전트도 완료할 수 없다는 당연한 사실을 직면하게 만드는 원칙입니다.

리포지토리에서 제공하는 도입 경로는 세 가지입니다. 모두 CLAUDE.md 혹은 그와 동등한 규칙 파일을 프로젝트에 두는 방식으로 완료됩니다.

/plugin marketplace add multica-ai/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

플러그인으로 설치하면 모든 Claude Code 세션에서 자동으로 활성화됩니다. 프로젝트마다 설정을 다시 할 필요가 없다는 장점이 있는 반면, 맞지 않는 프로젝트에서는 개별적으로 제거하는 운영이 필요합니다.

위의 새로운 소유자 이름으로 된 마켓플레이스 추가는, 로컬에서 multica-ai/andrej-karpathy-skills로의 도달을 확인했습니다. 공식 README에는 이전 소유자 이름인 /plugin marketplace add forrestchang/andrej-karpathy-skills가 그대로 기재되어 있지만, 이전 URL은 새 리포지토리로 리다이렉트(redirect)되므로 어느 쪽을 사용해도 동일한 것이 설치됩니다. 마켓플레이스 이름 karpathy-skills와 플러그인 이름 andrej-karpathy-skills는 바뀌지 않았습니다 (플러그인 정의 파일 내의 author 표기는 이전 소유자 이름 그대로입니다).

새 프로젝트에 새로 배치하기만 하려면 다음과 같이 합니다.

curl -o CLAUDE.md https://raw.githubusercontent.com/multica-ai/andrej-karpathy-skills/main/CLAUDE.md

기존의 CLAUDE.md가 있는 경우에는 덮어쓰지 않고 내용을 추가하는 방식으로 운영하는 것이 안전합니다. 예를 들어 기존 운영 규칙이 있다면, 프로젝트 고유의 장을 상단에 두고 그 아래에 4원칙 블록을 추가하는 구성으로 해두면 충돌이 일어나기 쉽지 않습니다.

Cursor를 사용하고 있는 경우에는 리포지토리 내의 Cursor용 규칙 파일을 .cursor/rules/ 아래에 배치합니다. Cursor는 해당 디렉토리 하위의 규칙을 자동으로 읽어들이므로, 이 역시 파일을 배치하는 것만으로 도입이 완료됩니다.

CLAUDE.md

또한 Cursor의 규칙 파일을 리포지토리(Repository)에 커밋해 두면, 팀 멤버 전원이 동일한 가이드라인에 따라 Claude Code / Cursor를 구동하게 됩니다. "사람마다 에이전트(Agent)를 작성하는 방식이 다르다"는 현상을 규칙 파일 공유를 통해 어느 정도 억제할 수 있습니다.

다만, 팀에 따라서는 "규칙이 너무 엄격해서 에이전트가 질문만 계속 던진다"고 느끼는 멤버가 생길 수도 있습니다. 그럴 경우에는 장(Chapter) 단위로 완화하거나, 개별 프로젝트에서 덮어쓰는(Overwrite) 방식의 운영이 현실적이라고 생각합니다.

리포지토리의 README에는 효과 측정 지표로서 대체로 다음과 같은 항목들을 들고 있습니다. 이는 공개된 지표라기보다, 운영상의 휴리스틱(Heuristics)으로 읽는 것이 좋아 보입니다.

• 불필요한 diff 변경이 줄어듦
• 첫 구현부터 심플한 코드가 나오게 됨
• 구현에 들어가기 전에 확인 질문이 나오게 됨
• PR(Pull Request)이 작아지고 목적을 파악하기 쉬워짐

실무에 적용하면 다음과 같은 변화로 나타날 가능성이 있습니다.

• 버그 수정 PR에서 수정 대상과 무관한 행의 변경이 줄어듦
• "미래의 확장을 위해"라는 이유로 도입되는 추상화가 줄어듦
• "대상은 전체 사용자인가요, 로그인 중인 사용자뿐인가요?"와 같은 확인 사항이 요청 초기에 돌아옴

다만, 요청 방식이나 대상 코드의 성질에 따라 효과는 달라집니다. 예를 들어, 요청 자체가 이미 충분히 명확하고 대상도 좁은 작은 수정이라면, 4원칙을 도입하기 전과 거동이 크게 다르지 않습니다. 차이가 크게 나타나는 것은 모호하고 범위가 넓은 요청을 던졌을 때라고 느끼고 있습니다.

리포지토리의 README에도 단점으로서 "확인 질문이 늘어나 번거롭게 느껴질 수 있다"고 명시되어 있습니다. 이는 "속도보다 신중함을 우선하는 설계"의 트레이드오프(Trade-off)입니다.

제 개인적인 감각으로는, 다음과 같은 상황에서는 4원칙을 풀(Full)로 적용하지 않는 것이 더 쾌적했습니다.

• 일회성으로 쓰고 버릴 스크립트를 작성할 때. 확인 과정을 거치는 것보다 임시로 돌아가는 것을 빨리 내놓고 싶을 때
• 이미 머릿속으로 설계가 완전히 굳어져 있어서, 에이전트에게는 정형적인 구현 작업만 맡기고 싶을 때
• 라이브러리 사용법을 테스트하기 위한 거친 스케치를 쓰고 싶을 때

반대로, 다음과 같은 상황에서는 효과가 크게 나타나기 쉽습니다.

• 운영 환경(Production)의 코드를 다룰 때
• 타인이 리뷰하는 것을 전제로 하는 팀 개발
• "덤으로 하는 변경"이 섞이면 리뷰 부하가 급증하는 규모가 큰 PR
• 비즈니스 로직의 변경으로 인해 요구사항의 해석이 여러 가지로 가능할 때

"모든 프로젝트에 동일한 규칙을 적용"하기보다는, 프로젝트마다 장(Chapter) 단위로 도입하는 것이 운영 측면에서 파탄 나지 않을 것이라고 느낍니다. 예를 들어 운영 환경에서는 Surgical Changes와 Goal-Driven Execution을 강하게 적용하고, 개인 실험 프로젝트에서는 Think Before Coding을 느슨하게 적용하는 식의 조정이 현실적입니다.

마지막으로, 4원칙 이야기와는 조금 벗어나지만, Karpathy 씨가 포스팅 후반부에 던졌던 질문들을 되짚어보고 싶습니다. 4원칙을 실무에서 운용하다 보면 이러한 질문들이 남의 일처럼 느껴지지 않기 때문입니다.

"10X 엔지니어"의 분산은 더욱 심화될 것인가

에이전트를 공통 기반으로 사용할 수 있게 되면, 이를 잘 사용하는 사람과 복사 붙여넣기 느낌으로 대충 사용하는 사람 사이의 산출량 차이가 크게 벌어질 가능성이 있습니다. 4원칙과 같은 "사용의 규율"이 그 차이를 만들어내는 레이어 중 하나가 될 것입니다. -
제너럴리스트(Generalist)가 스페셜리스트(Specialist)를 능가할 것인가

Karpathy 씨는 "LLM은 매크로(Macro, 전략)보다 마이크로(Micro, 빈칸 채우기)에 능숙하다"라고 썼습니다. 넓은 영역을 얕게 연결하는 제너럴리스트의 상대적 가치가 올라간다면, 자신의 업무 구성 방식도 재검토해야 할 것입니다. -
직접 쓰는 능력의 위축 (Atrophy)

"생성"과 "독해"는 서로 다른 뇌의 능력이며, 생성의 기회가 줄어들면 자연스럽게 위축될 것이라고 적혀 있었습니다. 독해 기술만큼은 반드시 유지해야 하며, 그렇지 않으면 에이전트가 작성한 코드를 평가하는 쪽의 기술까지 떨어지게 됩니다. 4원칙을 통해 diff가 작아지는 것은 독해 기술을 유지하는 데 있어서도 긍정적인 동력이 될 것입니다. -
2026년의 slopacolypse

Karpathy 씨는 2026년을 "모든 디지털 미디어에 슬롭(slop)이 범람하는 해"라고 예상하고 있습니다. 코드 슬롭(code slop)을 억제하는 OSS가 약 18.5만 개의 스타(star)를 모으고 있다는 점은, 해당 문제 의식이 널리 공유되고 있는 맥락에서 읽힐 수 있을 것입니다(인과관계나 대표성까지 증명할 수 있는 것은 아닙니다).

• Karpathy 씨의 "Claude 코딩 잡감"은 4원칙 이야기만 따로 떼어내면 맥락의 절반 정도가 누락되는, 매우 포괄적인 게시물이었습니다. LLM의 실패 패턴, 레버리지(leverage)를 활용하는 법, 기술의 퇴화, 그리고 2026년의 slopacolypse까지 언급되었습니다.
• 해당 게시물에서 나열된 "LLM의 버릇"을 3가지로 압축하고, 그 대책으로서 4가지 원칙을 CLAUDE.md 한 장에 담아낸 것이 multica-ai/andrej-karpathy-skills (구 forrestchang/...)입니다. 2026년 6월 말 기준으로 **약 18.5만 스타, 약 1.9만 포크(fork)**를 기록하고 있습니다. 라이선스는 README 상에는 MIT로 기재되어 있으나, LICENSE 파일 자체는 커밋되지 않아 GitHub의 라이선스 감지에는 표시되지 않는 상태이므로, 업무용으로 사용할 때는 최신 상태를 확인하시기 바랍니다.
• 4원칙은 Think Before Coding / Simplicity First / Surgical Changes / Goal-Driven Execution입니다. AI에게 특별한 것을 요구하는 것이 아니라, "인간 시니어 엔지니어가 신입에게 당연히 요구하는 매너"를 AI 측에 명문화한 것에 가깝습니다.
• 도입은 파일 한 장으로 끝나기 때문에, 우선 새로운 프로젝트에서 시도해 보고 맞지 않는 규칙을 장(chapter) 단위로 완화하며 운영하기 쉽습니다.
• 다만, "속도보다 신중함"을 지향하는 설계이므로 모든 프로젝트에 적합한 것은 아닙니다. 프로덕션(production) 환경에는 엄격하게, 일회성 스크립트에는 느슨하게 적용하는 식으로 구분하여 사용하는 것이 현실적이라고 생각합니다.
• 그리고 Karpathy 씨 본인이 썼듯이, CLAUDE.md에 적어두는 것만으로는 LLM의 버릇이 완전히 사라지지는 않습니다. 어디까지나 diff의 폭주를 "다소 완화하는" 정도로 기대치를 설정해 두어야, 잘못된 방식으로 사용하지 않을 수 있을 것입니다.

"200줄짜리 diff에 지쳤다"거나 "'ついでに(하는 김에) 고쳐두었습니다'라는 말이 PR 리뷰를 무겁게 만들고 있다"고 느끼는 분들은, 새로운 프로젝트에 CLAUDE.md 한 장을 놓아두는 것부터 시작해 보셔도 좋을 것 같습니다. 동작의 변화를 체감할 수 있다면, 그대로 프로덕션 리포지토리로 확장할지 판단하기가 훨씬 쉬워질 것입니다.

• Andrej Karpathy 씨의 원문 게시물 (X): https://x.com/karpathy/status/2015883857489522876
• 리포지토리: https://github.com/multica-ai/andrej-karpathy-skills (구 https://github.com/forrestchang/andrej-karpathy-skills 에서 리다이렉트)
• 해당 리포지토리 README: https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.md
• 메인테이너의 관련 프로젝트 Multica: https://github.com/multica-ai/multica