Karpathy nanochat: 복잡도 다이얼로 LLM 전체 파이프라인을 봅니다 | DAKER 커뮤니티

Karpathy의 nanochat은 “비싼 모델을 쓰기만 하지 말고, 가능한 한 전체 파이프라인을 보라”는 교육용 실험대입니다. 토크나이저, 사전학습, 파인튜닝, 평가, 추론, 채팅 UI까지 한 흐름으로 이어지면 LLM은 마법이 아니라 데이터·계산·평가·인터페이스의 묶음으로 보입니다. 오늘 확인할 일은 기능을 더 붙이기 전에 복잡도 다이얼을 정의했는지입니다.

오늘 배울 것

복잡도 다이얼은 모델 크기나 단계 수를 한 번에 조절할 수 있게 설계한 손잡이입니다. 다이얼이 있으면 작은 설정으로 전체 루프를 돌리고, 비용과 실패 지점을 먼저 볼 수 있습니다. 바이브 코딩으로 앱을 만들 때도 같은 눈이 필요합니다.

핵심 개념

LLM 제품은 프론트만의 문제가 아닙니다. 호출 비용, 평가 지표, 실패 복구, 사용자 경험이 한 파이프라인입니다. nanochat이 가르치는 태도는 각 단계를 따로 외우는 것이 아니라, 한 장에 이어 그린 뒤 어디서 깨지는지 보는 것입니다.

데모는 빠른데 제품화가 느린 이유는 파이프라인 중간 접착(인증, 배포, 한도, 저장)이 남기 때문입니다. 그 차이는 MenuGen 20% 데모와 80% 제품화 글과 맞닿아 있습니다.

따라 해볼 실습

지금 만드는 AI 기능을 한 장에 적습니다. 입력 → 전처리 → 모델/에이전트 호출 → 평가 → UI.
각 칸에 실패 지표 하나와 비용 지표 하나를 붙입니다. 예: 지연 시간, 토큰 수, 테스트 통과율.
복잡도 다이얼을 하나 정합니다. 예: 데이터 크기, 모델 단계, 도구 호출 횟수. 작은 값으로 먼저 한 바퀴 돌립니다.

작업 기억을 한 노트에 쌓는 습관은 Append-and-review 글과 함께 쓰면 파이프라인 실험 로그가 흩어지지 않습니다.

자주 막히는 지점

기능을 먼저 늘리면 다이얼이 사라집니다. 어떤 변수가 품질을 바꿨는지 모릅니다. 평가 없는 추론만 반복하면 “잘 나온 것 같음”에서 멈춥니다. UI만 예쁘게 만들고 중간 단계 로그를 남기지 않으면 디버깅이 막힙니다.

다음 학습 연결

파이프라인 한 바퀴를 돌렸다면, 다음은 vibe coding과 agentic engineering을 구분해 품질 기준을 올리는 단계입니다. DAKER 학습과 커뮤니티에서 Karpathy 시리즈를 이어서 확인하십시오.

오늘 바로 할 다음 행동: 진행 중인 프로젝트에 복잡도 다이얼 이름과 현재 값을 한 줄로 적어 두십시오.