카파시 신경망 레시피: AI 코딩 디버깅을 작게 검증하는 법 | DAKER 커뮤니티
카파시의 신경망 레시피는 AI 코딩 에이전트가 만든 코드를 디버깅할 때도 그대로 쓸 수 있습니다. 신경망 레시피란 데이터, 기준선, 과적합, 검증을 작은 순서로 확인해 조용한 실패를 줄이는 절차를 의미합니다.
오늘은 Andrej Karpathy가 2019년 공개한 A Recipe for Training Neural Networks를 바탕으로, 한국어 학습자가 바로 적용할 수 있는 바이브 코딩 디버깅 루프를 정리합니다. 핵심은 "한 번에 많이 고치기"가 아니라 "실패 하나를 잡고, 가설 하나만 바꾸고, 증거로 확인하기"입니다.
DAKER 학습 디렉터리용 NotebookLM 이미지: 카파시 신경망 레시피의 대표 카드와 AI 코딩 디버깅 워크플로 카드.
오늘 배울 것은 무엇인가요?
한 줄 요약: AI가 빠르게 코드를 만들어도 디버깅은 느리고 작게 해야 합니다.
오늘 배울 것은 세 가지입니다.
Karpathy의 신경망 훈련 레시피가 왜 디버깅 방법론인지 이해합니다.
AI 코딩 에이전트에게 맡길 작업을 작은 검증 루프로 바꿉니다.
실패 로그, 테스트, 스크린샷을 완료 기준으로 쓰는 습관을 만듭니다.
카파시 신경망 레시피가 왜 AI 코딩 디버깅에 맞나요?
Karpathy는 신경망 훈련이 "새는 추상화"이고, 많은 실패가 예외 없이 조용히 일어난다고 설명합니다. 문법 오류처럼 즉시 터지는 문제가 아니라, 데이터 전처리, 라벨, 학습률, 평가 방식이 조금씩 틀어져도 모델은 그럴듯하게 돌아갈 수 있다는 뜻입니다.
AI 코딩도 비슷합니다. 에이전트가 만든 앱은 빌드가 통과해도 요구사항을 놓칠 수 있고, UI가 보여도 모바일에서 깨질 수 있고, 테스트가 있어도 중요한 경계값을 빼먹을 수 있습니다. 그래서 "빨리 많이 바꾸기"보다 "작은 기준선부터 신뢰하기"가 더 중요합니다.
핵심 포인트는 다음과 같습니다.
데이터를 먼저 봅니다. 코드보다 입력과 실패 사례를 먼저 확인합니다.
멍청한 기준선을 둡니다. 가장 단순한 구현이나 테스트가 먼저 통과해야 합니다.
한 배치 과적합처럼 작은 성공을 만듭니다. 전체 기능 전에 최소 사례 하나를 끝까지 통과시킵니다.
복잡도는 한 번에 하나만 올립니다. 여러 수정이 동시에 들어가면 원인을 잃습니다.
AI 코딩 에이전트에게 어떤 순서로 맡기면 좋을까요?
아래 순서가 실무에서 가장 덜 흔들립니다.
실패를 캡처합니다.
에러 로그, 재현 명령, 깨진 화면, 기대 결과를 한 곳에 모읍니다.
최소 재현 예제를 만듭니다.
전체 프로젝트가 아니라 실패를 일으키는 가장 작은 입력과 경로를 고릅니다.
기준선을 고정합니다.
"현재는 이 테스트가 실패한다"를 먼저 확인합니다. 실패가 재현되지 않으면 수정도 믿기 어렵습니다.
AI에게 가설 하나만 맡깁니다.
"이 실패를 통과시키기 위해 인증 미들웨어만 확인해"처럼 범위를 좁힙니다.
검증 증거를 요구합니다.
테스트 출력, 타입체크, 스크린샷, 로그 중 하나 이상을 완료 조건으로 둡니다.
다음 복잡도를 하나만 추가합니다.
모바일, 권한, 빈 상태, 느린 네트워크 같은 조건을 한 번에 하나씩 넣습니다.
따라 해볼 실습은 무엇인가요?
오늘 20분 실습입니다.
최근 AI가 만든 코드 중 실패한 사례 하나를 고릅니다.
repro.md에 실행 명령, 입력, 기대 결과, 실제 결과를 씁니다.테스트가 없다면 실패를 보여 주는 가장 작은 테스트 하나를 만듭니다.
AI에게 "이 테스트 하나만 통과시키고, 바꾼 파일과 검증 명령을 보고해"라고 요청합니다.
통과 후 같은 방식으로 두 번째 실패만 추가합니다.
짧은 프롬프트 예시는 이렇게 쓸 수 있습니다.
이 변경은 한 번에 하나의 가설만 검증합니다.
현재 실패: 로그인 후 /dashboard가 403을 반환합니다.
목표: 이 실패를 재현하는 테스트를 먼저 만들고, 통과에 필요한 최소 수정만 하세요.
완료 보고: 변경 파일, 테스트 명령, 실패 전후 결과를 알려 주세요.자주 막히는 지점은 무엇인가요?
가장 흔한 실수는 "AI가 이미 원인을 알 것"이라고 생각하는 것입니다. 하지만 실패 조건이 흐리면 AI는 그럴듯한 수정을 넓게 뿌립니다. 그러면 코드는 더 복잡해지고 원인은 더 흐려집니다.
실수 방지 체크리스트입니다.
실패가 한 명령으로 재현되는가?
수정 전에 실패하는 테스트나 로그를 확인했는가?
AI에게 한 번에 하나의 파일 영역만 맡겼는가?
"빌드 성공" 말고 사용자 행동 기준을 확인했는가?
스크린샷, 테스트 출력, 로그 중 하나를 저장했는가?
비교표로 보면 차이가 더 선명합니다.
방식 | 빠른 바이브 코딩 | 카파시식 디버깅 |
|---|---|---|
시작점 | "고쳐 줘" | 실패 재현 |
범위 | 여러 파일 동시 수정 | 가설 하나 |
기준 | 결과가 좋아 보임 | 테스트/로그/스크린샷 |
위험 | 원인 추적 불가 | 속도는 느리지만 신뢰 가능 |
다음 학습 연결은 어디로 이어지나요?
이 글은 어제 올린 카파시 시리즈와 연결됩니다. 작은 모델을 직접 만지는 태도는 카파시식 AI 학습법: 작은 모델을 직접 만져라에서 다뤘고, 성공 조건을 먼저 쓰는 관점은 Software 2.0: 코드를 쓰는 대신 목적함수를 설계하는 시대와 이어집니다.
방법론의 한계도 있습니다. 모든 문제를 작은 테스트로 즉시 바꿀 수는 없습니다. UX 판단, 전략, 데이터 품질처럼 사람의 리뷰가 필요한 영역은 여전히 남습니다. 다만 코드, 모델, 에이전트 작업처럼 검증 가능한 영역에서는 작은 루프가 실패 비용을 크게 줄입니다.
공식 출처:
Andrej Karpathy, A Recipe for Training Neural Networks: https://karpathy.github.io/2019/04/25/recipe/
FAQ
카파시 신경망 레시피를 꼭 딥러닝 학습에만 써야 하나요?
아닙니다. 데이터 확인, 기준선, 작은 과적합, 한 번에 하나씩 복잡도 추가라는 절차는 AI 코딩 디버깅에도 잘 맞습니다.
AI 코딩 에이전트에게 가장 먼저 줘야 할 정보는 무엇인가요?
실패 재현 방법입니다. 에러 로그, 실행 명령, 기대 결과, 실제 결과가 있어야 AI의 수정 범위를 좁힐 수 있습니다.
테스트가 없는 프로젝트에서는 어떻게 시작하나요?
가장 작은 실패 하나만 테스트로 만드세요. 처음부터 전체 테스트 체계를 만들기보다 현재 문제를 고정하는 테스트가 먼저입니다.
스크린샷도 검증 증거가 될 수 있나요?
UI 문제에서는 충분히 유용합니다. 단, 가능하면 스크린샷과 함께 viewport 크기, 기대 상태, 확인한 날짜를 함께 남기세요.
다음에는 무엇을 공부하면 좋나요?
다음 글에서는 append-and-review 노트로 AI 작업 기억을 관리하는 방법을 다룹니다. 오늘 실패 로그 하나를 남겨 두면 다음 학습이 훨씬 쉬워집니다.