메타 설명
Andrej Karpathy Skills는 AI 코딩을 더 단순하고 정확하게 만드는 실전 가이드라인입니다. Google Antigravity에서 직접 써보며 느낀 장점과 범용 활용법까지 함께 정리했습니다.
들어가며
안드레 카파시 스킬스(Andrej Karpathy Skills)란 무엇인가
GitHub와 AI 개발자 커뮤니티(Cursor, Claude Code 등)에서 'Andrej Karpathy Skills (Karpathy Guidelines)'의 시스템 프롬프트가 큰 화제가 되고 있습니다.
단순한 프롬프트 모음이 아니라 AI 코딩의 방향을 정리해 주는 실전 가이드로 관심을 끌고 있습니다.
직접 써보면 더 분명해지는데, 이 자료의 강점은 특정 도구 하나를 위한 요령이 아니라 어떤 AI 코딩 환경에서도 통하는 원칙에 가깝다는 점입니다.
Andrej Karpathy Skills는 AI가 코드를 작성할 때 지켜야 할 작업 원칙을 정리한 가이드라인입니다.
핵심은 단순합니다. 먼저 생각하고, 단순하게 풀고, 필요한 부분만 정확하게 바꾸고, 목표를 분명히 하게 만드는 것입니다.
겉으로는 당연해 보이지만, 실제 AI 코딩에서는 이런 원칙이 있어야 불필요한 복잡성과 오류를 줄일 수 있습니다.
AI는 종종 사용자의 의도를 넓게 해석하거나, 그럴듯하지만 애매한 해결책을 먼저 제시합니다.
특히 “빠르게 돌아가는 코드”를 만들 수는 있어도, 그 코드가 왜 그런 방식으로 작성됐는지 설명하기 어렵다면 결국 유지보수 단계에서 문제가 생깁니다.
이 프롬프트는 바로 그 지점을 잡아주는 역할을 합니다.
왜 범용적으로 유용한가
이 가이드라인의 가장 큰 장점은 특정 AI 도구 전용이 아니라는 점입니다.
Claude Code, Gemini, Cursor, Copilot, ChatGPT 같은 다양한 도구에 모두 적용할 수 있습니다.
즉, 한 제품의 사용법이라기보다 AI 코딩 전반에 공통으로 적용되는 작업 원칙이라고 보는 편이 맞습니다.
AI 코딩에서 가장 위험한 순간은 코드가 겉보기에는 잘 동작하는 것처럼 보이지만, 실제로는 임시방편이나 우회 로직에 기대고 있을 때입니다.
이런 코드는 당장은 문제가 없어 보여도, 나중에 더 큰 버그로 이어지기 쉽습니다.
Andrej Karpathy Skills는 이런 위험을 줄이고, AI가 스스로 복잡도를 키우지 않도록 기준을 잡아줍니다.
네 가지 핵심 원칙
Andrej Karpathy Skills의 핵심은 네 가지 원칙으로 정리할 수 있습니다.
이 원칙들은 모든 AI 코딩 환경에서 그대로 활용할 수 있습니다.
1. 먼저 생각하라
코드를 바로 쓰기 전에, 문제를 정확히 이해해야 합니다.
요구사항이 애매한 상태에서 구현부터 시작하면 AI는 빈칸을 자기 방식으로 채우게 되고, 그 결과 의도와 다른 코드가 만들어질 수 있습니다.
이 원칙은 “일단 만들어 보기”보다 “무엇을 해결해야 하는지 먼저 분명히 하기”를 우선하게 합니다.
2. 단순하게 풀어라
AI는 때때로 필요 이상으로 복잡한 구조를 만들려는 경향이 있습니다.
하지만 실제 개발에서는 가장 단순한 해법이 가장 안정적인 경우가 많습니다.
불필요한 추상화나 과도한 설계는 오히려 버그를 늘릴 수 있기 때문에, 단순함은 품질의 일부라고 보는 것이 맞습니다.
3. 필요한 부분만 바꿔라
AI는 한 번에 여러 파일과 여러 로직을 바꾸는 경우가 많습니다.
하지만 변경 범위가 넓어질수록 예상치 못한 부작용도 함께 늘어납니다.
그래서 수술하듯 정확하게 필요한 부분만 수정하는 접근이 중요합니다.
4. 목표를 분명히 하고 실행하라
AI는 목표가 모호하면 작업 범위를 스스로 넓히기 쉽습니다.
“이거 고쳐줘”보다 “이 오류만 해결하고 기존 동작은 유지해줘”처럼 명확하게 말해야 합니다.
목표가 분명할수록 결과도 안정적이고, 검증도 쉬워집니다.
Google Antigravity에서 특히 좋았던 이유
제가 실제로 써보면서 체감이 컸던 부분은 Google Antigravity였습니다.
Gemini는 코딩 능력이 강하지만, 때때로 스스로 꼼수를 만들며 문제를 우회하려는 모습을 보일 수 있습니다.
이럴 때 Andrej Karpathy Skills를 적용하면, AI가 문제를 먼저 정리하고 단순한 해결책을 우선하며, 변경 범위를 좁히는 방향으로 움직입니다.
즉, 이 프롬프트는 Gemini의 강점을 약화시키는 것이 아니라, 오히려 강점을 더 안정적으로 활용하게 해 줍니다.
구현력은 살리되, 과잉 추론이나 우회적 해결로 인한 오류는 줄이는 방식입니다.
그래서 이 가이드는 Google Antigravity에만 잘 맞는 도구가 아니라, AI가 지나치게 자신감 있게 헛길로 빠지는 것을 막아주는 범용 원칙이라고 할 수 있습니다.
어떻게 활용하면 좋은가
Andrej Karpathy Skills은 실제 프롬프트 앞부분에 붙여서 쓰는 것이 가장 효과적입니다. 그 내용은 다음과 같습니다.
Karpathy Guidelines
Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls.
Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.
1. Think Before Coding
Don't assume. Don't hide confusion. Surface tradeoffs.
Before implementing:
State your assumptions explicitly. If uncertain, ask.
If multiple interpretations exist, present them - don't pick silently.
If a simpler approach exists, say so. Push back when warranted.
If something is unclear, stop. Name what's confusing. Ask.
2. Simplicity First
Minimum code that solves the problem. Nothing speculative.
No features beyond what was asked.
No abstractions for single-use code.
No "flexibility" or "configurability" that wasn't requested.
No error handling for impossible scenarios.
If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
3. Surgical Changes
Touch only what you must. Clean up only your own mess.
When editing existing code:
Don't "improve" adjacent code, comments, or formatting.
Don't refactor things that aren't broken.
Match existing style, even if you'd do it differently.
If you notice unrelated dead code, mention it - don't delete it.
When your changes create orphans:
Remove imports/variables/functions that YOUR changes made unused.
Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
4. Goal-Driven Execution
Define success criteria. Loop until verified.
Transform tasks into verifiable goals:
"Add validation" → "Write tests for invalid inputs, then make them pass"
"Fix the bug" → "Write a test that reproduces it, then make it pass"
"Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
예를 들어 AI에게 작업을 요청할 때 다음 기준을 함께 주면 좋습니다.
먼저 문제를 요약해 달라.
불확실한 가정이 있으면 먼저 말해 달라.
요청 범위를 벗어나지 말라.
가능한 한 단순하게 풀어 달라.
수정은 필요한 부분만 하라.
결과를 검증할 방법까지 제시해 달라.
이렇게 하면 AI가 멋진 코드를 만드는 데 집중하기보다, 실제로 쓸 수 있는 코드를 만드는 방향으로 움직이게 됩니다.
프로젝트 규칙 파일이나 팀 작업 기준으로 정리해 두면, 반복 설명을 줄이고 작업 품질도 더 일정하게 유지할 수 있습니다.
실전 바이브 코딩 프롬프트 템플릿
이 버전은 단순히 코딩을 시키는 것이 아니라, AI가 꼼수로 빠지지 않도록 통제하는 구조까지 포함합니다.
1) 범용 프롬프트
너는 숙련된 시니어 개발자이자 신중한 코드 리뷰어처럼 행동한다.
아래 원칙을 반드시 지켜라.
작업 원칙
먼저 문제를 정확히 이해하라.
요구사항이 불명확하면 코드 작성 전에 질문하라.
추측으로 빈칸을 채우지 마라.
가장 단순한 해결책부터 우선 검토하라.
요청 범위를 벗어나는 변경은 하지 마라.
기존 구조를 불필요하게 바꾸지 마라.
수정은 수술적으로, 필요한 지점에만 적용하라.
동작이 바뀌는 부분이 있다면 반드시 이유를 설명하라.
테스트 가능성과 유지보수성을 함께 고려하라.
응답 형식
답변은 반드시 아래 순서를 지켜라.
문제 요약
불명확한 점 또는 전제
가장 단순한 해결 방향
실제 코드 수정안
예상되는 영향
검증 방법
필요한 경우 대안
엄격한 제한
요청하지 않은 기능을 추가하지 마라.
성능 최적화가 필요하다고 확신할 근거가 없으면 최적화를 제안하지 마라.
구조 개선이 필요하다고 판단되더라도, 우선은 최소 변경안을 제시하라.
여러 해결책이 있더라도 가장 안전하고 단순한 방법을 먼저 제시하라.
확신이 없으면 확신이 없다고 말하라.
추가 통제 규칙
코드를 작성하기 전에 먼저 현재 상황을 3줄 이내로 요약하라.
그다음 변경 목표를 1문장으로 명확히 정의하라.
마지막으로 가장 작은 수정 단위를 먼저 제시하라.
만약 기존 코드에 숨은 문제나 위험이 보이면, 코드를 바로 바꾸기 전에 먼저 그 위험을 설명하라.
가능한 경우, 변경 전후의 차이를 짧게 비교하라.
이제부터 이 원칙에 따라 답변하라.
2) 짧은 버전
실전에서 너무 긴 프롬프트가 부담스럽다면, 아래처럼 짧게 써도 효과가 좋습니다.
짧은 버전
코드를 작성하기 전에 먼저 문제를 요약하고, 불명확한 점이 있으면 질문해라.
해결은 가능한 한 단순하게 하고, 요청 범위를 벗어나는 변경은 하지 마라.
수정은 최소한으로 적용하고, 검증 방법까지 함께 제시해라.
3) 버그 수정용 버전
버그 수정 프롬프트
지금부터 버그 수정만 수행하라.
먼저 오류의 원인 후보를 정리하고, 가장 가능성이 높은 원인부터 설명하라.
불필요한 리팩터링이나 기능 추가는 하지 마라.
수정은 최소 범위로 하되, 기존 동작은 유지하라.
수정 후에는 반드시 재현 방법과 검증 방법을 함께 제시하라.
4) 리팩터링용 버전
리팩터링 프롬프트
리팩터링을 수행하되, 기능 변경은 하지 마라.
기존 동작을 유지하는 것을 최우선으로 하고, 구조 개선은 최소 변경으로 하라.
과한 추상화는 피하고, 단순하고 읽기 쉬운 방향을 우선하라.
변경 이유와 영향 범위를 함께 설명하라.
어떤 사람에게 특히 잘 맞나
이 가이드는 AI 코딩을 자주 사용하는 사람에게 특히 유용합니다.
프런트엔드, 백엔드, 자동화 스크립트, 테스트 코드, 리팩터링 같은 작업에서 효과가 크고, 팀 단위로 AI를 쓰는 경우에도 일관된 기준을 만드는 데 도움이 됩니다.
특히 다음과 같은 상황에서 잘 맞습니다.
AI가 만든 코드가 자꾸 복잡해질 때.
겉보기에는 맞는데 실제론 오류가 많을 때.
수정 범위가 계속 커질 때.
AI에게 무엇을 시켜야 할지 명확하지 않을 때.
이럴 때 Andrej Karpathy Skills는 단순한 조언이 아니라, 실제 코드 품질을 잡아주는 기준이 됩니다.
마무리
Andrej Karpathy Skills는 AI 코딩을 더 화려하게 만드는 프롬프트가 아닙니다.
오히려 반대로, AI가 쓸데없는 꼼수를 만들지 않도록 막고, 더 단순하고 정확하게 일하게 만드는 원칙입니다.
제가 Google Antigravity에서 직접 써봤을 때도, Gemini가 스스로 우회로를 만들며 오류를 키우는 흐름을 줄이는 데 도움이 됐습니다.
이 프롬프트의 진짜 가치는 특정 도구에서만 잘 먹히는 비법이 아니라, 어떤 AI 코딩 환경에서도 충분히 재사용 가능한 범용 원칙이라는 데 있습니다.
결국 AI를 잘 쓰는 핵심은 더 많은 코드를 뽑아내는 것이 아니라, 더 좋은 방향으로 통제하는 것입니다.
이 글은 인공지능의 도움을 받아 작성되었습니다
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.