프로덕트 소식은 넘쳐나지만 대부분 이런 게 나왔대에서 끝납니다. 그래서 뭘 어떻게 하라고? 내 작업에 어떻게 써먹지? 거기까진 연결이 잘 안 되죠. 따라서 요즘 프로덕트 메이커는 바로 쓸 수 있는 것, 그 중에서도 주목해볼 만한 것을 엄선해서 매주 금요일에 전달드리려 합니다.

요즘 프로덕트 메이커는 매주 세 가지를 골라 전합니다:

써볼 것: 하루 만에 GitHub 스타 400개 받은 65줄짜리 텍스트 파일
참고할 것: GPT 전체를 200줄로 압축하면 남는 것 - Karpathy의 MicroGPT
적용해볼 것: 구글 14년차가 정리한 14가지 교훈

1. 써볼 것: 하루 만에 GitHub 스타 400개 받은 65줄짜리 텍스트 파일

오늘 써볼 것에서 소개할 CLAUDE.md는 AI 코딩 도구의 행동 규칙을 담은 65줄짜리 마크다운 파일입니다. Claude Code에서 바로 쓸 수 있고, Cursor나 VS Code 확장으로도 설치할 수 있습니다.

이 파일을 만든 건 forrestchang이라는 개발자인데요. OpenAI 공동창업자 Andrej Karpathy가 X에서 AI 코딩 도구의 문제점을 상세히 지적한 글에서 영감을 받아, 그 관찰을 4가지 원칙으로 정리한 겁니다. 공개 직후 GitHub에서 하루 만에 스타 400개를 달성했고, 현재는 6,500개를 돌파한 상황입니다. 또, Hacker News 메인에도 올라 활발한 토론이 벌어지기도 했죠. 흥미로운 건 이 파일이 고작 65줄이라는 겁니다. 수조 원을 들여 훈련시킨 거대 AI 모델에, 65줄짜리 텍스트 파일 하나를 얹었을 뿐인데 정말 코드 품질이 달라지는 걸까요? 아래에서 좀 더 살펴보겠습니다.

무슨 문제를 해결해 주나요?

AI 코딩 도구를 써본 분들은 공감하실 텐데요. Claude Code든 Cursor든, AI한테 코드를 시키면 자주 겪는 문제가 있습니다.

첫째, AI가 멋대로 추측하고 달려갑니다. 모르면 물어봐야 하는데, 물어보지 않아요. 알아서 해석하고 알아서 만들어버립니다. 나중에 보면 전제 자체가 틀린 경우가 많죠.
둘째, 코드를 불필요하게 복잡하게 만듭니다. 100줄이면 될 걸 1,000줄로 짜요. 요청하지 않은 추상화를 덧붙이고, 사용하지 않을 설정 옵션을 미리 만들어둡니다.
셋째, 건드리지 말아야 할 코드까지 건드립니다. 함수 하나만 고쳐달라고 했는데, 옆에 있는 주석을 슬쩍 지우거나 관련 없는 코드를 리팩터링합니다.

이건 Karpathy가 직접 관찰하고 공유한 문제이기도 합니다. Karpathy는 2025년 12월부터 AI 에이전트로 코딩하는 비율을 80%까지 올렸는데요. 그 과정에서 발견한 공통적인 실수 패턴을 X에 상세히 공유했습니다. forrestchang은 이 내용을 4가지 원칙으로 정리해서 CLAUDE.md 파일로 만들었고, 그게 바로 이 가이드라인입니다.

어떻게 쓰나요?

설치 방법은 간단합니다. Claude Code를 쓴다면 터미널에 한 줄만 입력하면 됩니다.

npx skills add forrestchang/andrej-karpathy-skills

Cursor나 VS Code를 쓴다면, 프로젝트 루트 폴더에 CLAUDE.md 파일을 직접 추가해도 됩니다. 확장 마켓플레이스에서도 설치할 수 있고요.

파일 안에는 4가지 원칙이 들어 있습니다.

원칙 1. 코딩 전에 생각하기 → AI가 멋대로 추측하지 않고, 불확실한 부분이 있으면 사용자에게 물어보도록 만듭니다. 여러 가지 해석이 가능한 요청을 받았을 때, 하나를 골라 달려가는 게 아니라 선택지를 보여주고 확인을 구합니다.
원칙 2. 단순하게 짜기 → 요청받은 것만 구현하고, 그 이상은 하지 않도록 합니다. 테스트 기준은 간단해요. 시니어 엔지니어가 보고 "이거 너무 복잡한데?"라고 말할 것 같으면 다시 줄이는 겁니다.
원칙 3. 수술하듯 정밀하게 수정하기 → 요청과 직접 관련 있는 코드만 수정합니다. 변경한 모든 줄이 사용자의 요청으로 거슬러 올라갈 수 있어야 합니다.
원칙 4. 목표 기반으로 실행하기 → AI한테 "뭘 해라"라고 지시하는 대신, "성공 조건이 뭔지" 알려주고 스스로 반복하게 합니다. 테스트를 먼저 짜게 하고, 통과할 때까지 루프를 돌게 하는 방식이죠.

여기서 주의할 점이 하나 있습니다. 이 파일이 AI 코딩의 품질을 극적으로 바꿔주는 마법은 아닙니다. 이 파일을 발견하고 Cursor/VS Code 확장까지 직접 만든 네덜란드 개발자 Michiel Beijen도 블로그에서 리뷰했는데요. 실제로 써봤는데, 효과가 있는지 확신하진 못하겠다고요. LLM은 같은 프롬프트를 줘도 매번 다른 결과가 나오는 비결정적 특성이 있어서, 플라시보와 실제 개선을 구분하기가 어렵기 때문입니다. 그럼에도 수많은 개발자가 효과를 체감한다는 후기도 많습니다.

이 파일이 주목받는 이유는 따로 있어요. AI한테 매번 더 좋은 프롬프트를 쓰려고 애쓰는 것보다, 일하는 방식 자체를 규칙으로 정의해주는 게 더 근본적인 접근이라는 점입니다. 매번 잘 지시하려고 에너지를 쏟는 대신, 규칙을 한 번 세팅해두면 매 작업에 적용되니까요.

누구에게 좋을까요?

Claude Code, Cursor, VS Code에서 AI 코딩을 쓰는 사람
AI가 코드를 짜주면 리뷰하는 데 오히려 시간이 더 걸리는 사람
CLAUDE.md나 .cursorrules 같은 규칙 파일을 아직 안 써본 사람
팀에서 AI 코딩 가이드라인을 만들고 싶은데 어디서부터 시작할지 모르는 사람

반대로, 이미 프로젝트에 맞는 규칙 파일을 잘 운영하고 있다면 굳이 이 파일을 추가할 필요는 없어보입니다. 이 가이드라인은 범용적인 행동 규칙이라, 프로젝트별 맞춤 규칙과 함께 쓸 때 효과가 좋습니다.

2. 참고할 것: GPT 전체를 200줄로 압축하면 남는 것 - Karpathy의 MicroGPT

MicroGPT는 GPT의 학습과 추론 전 과정을 단 하나의 파이썬 파일에 담은 프로젝트입니다. 외부 라이브러리 없이, 순수 파이썬 200줄만으로요. OpenAI 공동창업자이자 전 Tesla AI 디렉터인 Andrej Karpathy가 2월 12일에 공개했습니다.

반응은 즉각적이었습니다. GitHub Gist에 공개된 지 일주일 만에 스타 5,000개 가까이 받았고, 1,000개가 넘는 포크가 생겼습니다. C#, JavaScript, Rust, Common Lisp 등 다른 프로그래밍 언어로 옮기는 작업도 활발히 이어지고 있고요.

Karpathy 본인은 이걸 예술 작품이라고 불렀습니다. 10년간 LLM의 본질을 극한까지 단순화하려는 집착의 결과물이고, 이보다 더 줄일 수는 없다고요.

기존 LLM 교육 자료와 무엇이 다른가요?

GPT가 어떻게 작동하는지 이해하려면 보통 두 가지 벽이 있습니다. 첫째, 수학이 어렵습니다. 둘째, 코드가 복잡합니다. PyTorch 같은 프레임워크가 수만 줄의 코드로 핵심 원리를 감춰버리니까요.

MicroGPT는 이 두 가지 벽을 한꺼번에 없애줍니다. import하는 라이브러리가 os, math, random, argparse 딱 네 개입니다. PyTorch도 없고, NumPy도 없고, TensorFlow도 없습니다. 그런데 이 안에 토크나이저(텍스트를 숫자로 바꾸는 장치), 자동 미분 엔진(신경망이 학습하는 핵심 메커니즘), 트랜스포머 아키텍처, 옵티마이저(학습 속도를 조절하는 장치), 학습 루프, 추론 루프가 전부 들어 있습니다.

어떻게 작동하나요?

MicroGPT는 3만 2천 개의 영어 이름 데이터를 학습해서, 실제로는 존재하지 않지만 그럴듯하게 들리는 새로운 이름을 만들어냅니다. 학습이 끝나면 kamon, vialan, areli 같은 이름이 나오는데요. 이름 생성 자체는 소박해 보이지만, 이게 작동하는 원리는 ChatGPT와 정확히 같습니다.

우리가 ChatGPT에 질문을 하면, 모델 입장에서 그건 하나의 문서 시작점이에요. 모델은 그 문서를 통계적으로 가장 자연스럽게 이어나갈 뿐입니다. MicroGPT도 같은 원리로 이름이라는 문서를 완성하는 거예요.

차이는 규모에 있습니다. MicroGPT의 파라미터(모델이 학습하는 숫자들)는 4,192개입니다. GPT-2는 15억 개, 최신 LLM은 수천억 개를 가지고 있죠. 하지만 다음 토큰을 예측하고, 어텐션으로 맥락을 파악하고, 역전파로 학습하는 핵심 알고리즘은 동일합니다.

Karpathy의 표현이 정확합니다. 대규모 모델을 가능하게 하는 건 방대한 엔지니어링이지만, 알고리즘의 본질은 이 200줄 안에 모두 담겨 있다고요.

왜 이게 의미 있나요?

이 프로젝트가 단순한 교육용 코드와 다른 점이 세 가지 있습니다.

첫째, 알고리즘과 엔지니어링을 깔끔하게 분리해서 보여줬습니다. 우리가 매일 쓰는 ChatGPT는 거대해 보이지만, 그 거대함의 정체는 원리가 아니라 규모입니다. 더 많은 데이터를 더 빠르게 처리하기 위한 엔지니어링이 99%이고, 핵심 알고리즘은 200줄에 다 들어갑니다. 이걸 눈으로 확인할 수 있다는 게 중요해요.
둘째, 보통 프레임워크가 감춰주는 과정을 직접 구현했습니다. 신경망이 학습하려면, 각 숫자가 결과에 얼마나 영향을 미치는지 자동으로 계산하는 과정이 필요한데요. 보통은 PyTorch가 대신 해줘서 눈에 안 보입니다. MicroGPT는 이걸 40줄 남짓의 코드로 밑바닥부터 만들었습니다.
셋째, 10년간 계속 줄여온 과정의 마지막 단계입니다. Karpathy는 micrograd(자동 미분), makemore(문자 생성), nanoGPT(GPT-2 훈련), nanochat(100달러로 ChatGPT 만들기)를 차례로 만들어왔습니다. MicroGPT는 이 모든 걸 하나의 파일로 압축한 결정체예요. 추가한 게 아니라 계속 뺀 겁니다.

무엇을 얻어가야 하나요?

프로덕트 메이커가 MicroGPT에서 가져갈 건 코드가 아닌, 복잡한 것에서 본질만 남기는 사고방식입니다.

기능을 추가하는 건 누구나 할 수 있습니다. 진짜 어려운 건 빼는 거죠. 이는 Karpathy가 10년에 걸쳐 한 일이기도 합니다. 매번 프로젝트를 만들 때마다 "이건 꼭 있어야 하나?"를 물어서 한 겹씩 벗겨낸 겁니다.

프로덕트를 만들 때도 같은 질문을 해볼 수 있습니다. 지금 내가 만들고 있는 것에서, 핵심이 아닌 것은 무엇인가? 빼도 작동하는 것은 무엇인가?

GPU 없이 일반 노트북에서 몇 분이면 돌아가니까요. 코드를 이해할 필요 없이 실행만 해봐도, 200줄짜리 파일 하나로 AI가 이름을 만들어내는 걸 직접 볼 수 있습니다. 궁금하신 분은 Google Colab notebook에서 실행해 볼 수도 있습니다.

3. 적용해볼 것: 구글 14년차가 정리한 14가지 교훈

Addy Osmani는 구글 Chrome 개발자 경험 팀을 이끌었고, 현재는 Google Cloud AI 디렉터로 일하고 있습니다. Chrome DevTools, Lighthouse 같은 도구를 만든 사람이에요. 4천만 명 이상의 개발자가 그가 만든 도구를 쓰고 있죠.

2월 12일, Osmani가 자신의 뉴스레터에서 구글 14년 경험에서 뽑은 추가 교훈 14가지를 공개했습니다. 이전에 쓴 21가지 교훈이 큰 반응을 받았는데, 사람들이 특히 관심을 보인 건 기술 조언이 아니라 팀과 의사결정에 대한 이야기였대요. 그래서 이번엔 아예 그 주제에 집중했습니다.

흥미로운 건, 14가지 교훈 중 상당수가 코딩과 관련 없다는 겁니다. 의사결정, 실행력, 시스템 설계에 대한 이야기가 대부분이고, 이건 프로덕트를 만드는 사람이라면 직군을 가리지 않고 적용할 수 있는 내용입니다.

무슨 문제를 해결하려 하나요?

프로덕트를 만드는 사람이 가장 많이 하는 말이 뭘까요. 아마 "해야 하는데"일 겁니다. 해야 하는데 시간이 없고, 해야 하는데 결정이 안 나고, 해야 하는데 뭘 먼저 해야 할지 모르겠고. Osmani가 14년간 관찰한 것도 결국 이 문제입니다. 똑똑한 사람들이 모여도 일이 안 되는 이유는 대부분 능력 부족이 아니라, 결정이 느리거나 구조가 없어서라는 거예요.

14가지 중 프로덕트 메이커에게 가장 와닿을 6가지를 골라서 전달드리겠습니다.

어떻게 해결했나요? (Addy Osmani가 공유한 교훈 중 선별)

1. 최고의 엔지니어는 올바른 문제를 고릅니다

모든 "예"는 다른 무언가에 대한 암묵적인 "아니오"입니다. Osmani는 뛰어난 엔지니어들이 모든 버그, 모든 기능 요청, 모든 부탁에 "예"라고 말하다 번아웃되는 걸 수없이 봤다고 합니다. 달력이 다른 사람의 우선순위로 채워지면, 자기 로드맵은 미완성 프로젝트의 무덤이 됩니다.

큰 영향을 만드는 사람들은 더 빠르거나 더 똑똑해서가 아니에요. 뭘 할지를 더 냉정하게 고르는 겁니다. 잘못된 일을 하는 것의 기회비용은, 잘못된 일을 하고 있다는 것 자체입니다.

2. "해야지"는 계획이 아닙니다. "화요일에 내가 할 것"이 계획입니다

팀은 의도에 빠져 허우적거립니다. 온보딩 플로를 개선해야지, 지연 시간을 줄여야지, API 문서를 정리해야지. 몇 달 후에 같은 항목이 그대로 남아 있죠.

Osmani의 해법은 간단합니다. 의도를 가장 작은 다음 행동으로 바꾸고, 거기에 이름과 날짜를 붙이는 겁니다. "온보딩을 개선해야 한다"가 아니라 "화요일에 Sarah가 사용자 세션 3회를 돌리고 핵심 불편 사항을 정리한다"로 바꾸는 거예요. 모호한 의도는 불안을 만들고, 구체적인 약속은 추진력을 만듭니다.

3. 느린 코드는 증상입니다. 느린 의사결정은 항상 문제입니다

프로젝트가 느려지면 보통 속도를 탓합니다. 사람이 부족하다, 코드가 지저분하다, 열심히 안 한다. 하지만 Osmani의 경험에서 느린 코드는 증상이고, 느린 의사결정이 병이었습니다.

결정이 몇 주, 몇 달씩 걸리면 이유를 파봐야 합니다. 맥락이 공유되지 않아서 트레이드오프를 판단할 수 없는 건지, 책임자가 불분명해서 서로 기다리고 있는 건지, 틀리는 게 두려워서 결정을 미루는 건지.

Osmani가 본 가장 빠른 팀은 최고의 프로그래머가 모인 팀이 아니었습니다. 결정이 몇 주가 아니라 몇 시간 안에 이루어지는 팀이었어요. 권한이 명확하고, 맥락이 공유되고, 틀려도 커리어에 타격이 없는 환경이었기 때문입니다.

4. 영웅 문화를 피하세요. 영웅이 필요 없는 시스템을 만드세요

한 사람이 위기를 구하는 게 반복되는 패턴이라면, 그건 자랑이 아니라 실패 신호입니다. Osmani는 팀들이 영웅을 축하하면서 정작 영웅이 필요해진 근본 원인은 무시하는 걸 봐왔다고 합니다. 그 사람이 떠나면 아무도 시스템을 모릅니다. 영웅에 대한 축하는 구조적 문제를 가려버리는 거예요.

정상적인 경로를 기본값으로 만들어야 합니다. 문서를 쓰고, 지식을 분산하고, 평범한 화요일을 기준으로 시스템을 설계하는 거죠. 위기 상황이 아니라요.

5. AI는 초안을 싸게 만듭니다. 취향이 비싸집니다

이제 누구나 코드를 만들 수 있습니다. 코드, 콘텐츠, 디자인을 만드는 비용이 급격히 낮아지고 있으니까요. AI한테 시키면 한 개 만들 시간에 열 개를 뽑아줍니다.

그러면 차이를 만드는 건 뭘까요. 고르는 능력입니다. 무엇을 만들지, 무엇을 지울지, 무엇을 단순하게 만들지, 무엇을 출시하지 않을지. Osmani는 이걸 취향(taste)이라고 부릅니다. 선택지를 구분하고 올바른 것을 고르는 능력이 희소 자원이 된다는 겁니다. 생산은 싸지고, 편집은 비싸지고, 선택이 전부가 됩니다.

6. 신뢰는 팀의 레이턴시 최적화입니다

신뢰가 있으면 일이 빨라집니다. 이 사람이라면 잘 판단했을 거라는 전제가 있으니까요. 확인 회의를 세 번 잡을 필요 없이, 한 번이면 됩니다. 반대로 신뢰가 없으면 같은 결정을 내리는 데 몇 배의 시간이 걸립니다. Osmani는 기술력은 보통인데 모두의 신뢰를 받아서 큰 일을 해내는 엔지니어를 봤다고 합니다. 반대로 기술력은 뛰어난데 아무도 같이 일하려 하지 않아서 결국 아무것도 못 한 엔지니어도 봤고요.

약속을 지키고, 실수를 솔직하게 인정하고, 다른 사람의 일을 쉽게 만들어줄 때마다 신뢰가 쌓입니다. 코드가 아무리 좋아도, 같이 출시해줄 사람이 없으면 의미가 없으니까요.

적용을 위해 실행해볼 수 있는 것

지금 하고 있는 일 중에서 "내가 안 하면 어떻게 되지?"를 물어보기. 큰 문제가 없다면, 그건 지금 내가 할 일이 아닙니다.
"해야지" 목록에서 가장 중요한 항목 하나를 골라서 "언제, 누가, 무엇을" 형식으로 바꿔보기. 이번 주 안에 할 수 있는 크기로 쪼개기.
반복적으로 내가 나서서 해결해야 하는 일이 있다면, 그 일을 시스템으로 만들 수 없는지 생각해보기. 영웅이 필요 없는 구조가 좋은 구조입니다.
AI로 만든 결과물을 볼 때, 무엇을 남기고 무엇을 뺄지 의식적으로 판단해보기. 생산이 아니라 선택에 시간을 더 쓰기.

정리

이 내용을 기억해두면 좋습니다

AI 코딩의 차이는 모델 성능에서 나오지 않습니다. 구조에서 나옵니다. 65줄짜리 규칙 파일이 수천 개의 스타를 받은 건, AI한테 매번 잘 지시하는 것보다 일하는 방식을 한 번 정의해주는 게 더 효과적이기 때문입니다. 규칙을 만드는 사람과 만들지 않는 사람의 차이가 점점 벌어질 겁니다.
복잡한 걸 더 복잡하게 만드는 건 누구나 합니다. 본질만 남기고 나머지를 제거하는 데 10년이 걸렸다는 게 MicroGPT의 진짜 이야기입니다. Karpathy는 기능을 추가한 게 아니라 매번 한 겹씩 벗겨냈고, 그 끝에 200줄이 남았습니다. 프로덕트도 마찬가지예요. 추가하는 건 쉽고, 빼는 게 어렵습니다.
AI가 초안을 싸게 만들수록, 무엇을 남기고 무엇을 뺄지 판단하는 능력이 비싸집니다. 코드를 짜는 건 AI가 하고, 규칙을 정하는 건 사람이 합니다. 열 개의 선택지를 만드는 건 AI가 하고, 하나를 고르는 건 사람이 합니다. 기술이 아니라 판단이 희소 자원이 되는 시대입니다.

이렇게 적용해보세요

AI 코딩 도구를 쓴다면, 프로젝트 폴더에 규칙 파일 하나 만들어보기. 거창할 필요 없이, AI가 자주 실수하는 패턴 3가지만 적어도 충분합니다.
지금 만들고 있는 프로덕트에서 빼도 되는 기능 하나 찾아보기. 추가하기 전에 "이거 없어도 핵심이 작동하나?" 물어보기.
"해야지" 목록을 "이번 주 화요일에 내가 할 것" 형식으로 바꿔보기. 구체적인 날짜와 이름이 붙어야 의도가 실행이 됩니다.

다음 주에도 여러분이 놓치지 말아야 할 프로덕트 메이커 소식을 정리해서 찾아뵙겠습니다. 요즘 프로덕트 메이커 콘텐츠가 도움이 되셨다면, 꼭 작가 알림 설정을 부탁드립니다! 콘텐츠 내용 중 잘못된 정보나 정정이 필요한 부분이 있다면 댓글로 알려주세요. 빠르게 수정하겠습니다. 다음 주에 또 만나요!