Karpathy Software 2.0: 명령문 대신 목적함수를 설계해 품질을 가릅니다 | DAKER 커뮤니티

Karpathy의 Software 2.0 관점은 신경망을 “사람이 직접 쓰지 않은 프로그램”으로 봅니다. 핵심 작업이 명령문 작성에서 데이터셋·목표·평가 설계로 이동하면, 바이브 코딩의 품질도 같은 기준으로 갈립니다.

오늘 배울 것

Software 1.0은 사람이 코드를 직접 씁니다. Software 2.0은 사람이 데이터와 목적함수를 만들고, 최적화가 프로그램을 찾습니다. 오늘은 이 관점을 프롬프트와 해커톤 제출에 바로 적용하는 방법을 배웁니다.

영어 프롬프트로 앱을 만드는 시대에도 실제 품질은 “무엇을 성공으로 볼 것인가”를 얼마나 잘 정했는지에 따라 갈립니다. AI 시대의 개발자는 코드를 덜 보는 사람이 아니라, 검증 루프를 더 잘 설계하는 사람입니다.

요구사항, 예시, 실패 케이스, 자동 테스트, 사용자 피드백은 모두 새로운 의미의 프로그래밍 재료가 됩니다. 목적함수가 흐리면 생성 결과가 아무리 많아도 품질이 고정되지 않습니다.

설명용 생성 이미지입니다. 현장 사진이 아닙니다.

프롬프트를 쓰기 전에 성공 조건을 먼저 씁니다. “좋아 보임” 대신 입력-출력 예시와 실패 예시를 둡니다. 데이터와 피드백을 코드만큼 중요하게 관리합니다.

해커톤 데모 전에는 성공 조건 체크리스트 다섯 줄을 만들고, 그중 하나는 반드시 실패 케이스로 둡니다. 통과하지 못하면 기능을 늘리지 않습니다.

“일단 만들어 줘”만 반복하면 화면은 늘어나지만 평가 기준이 없습니다. 반대로 지표만 많고 입력 예시가 없으면 최적화 방향이 흔들립니다. 막히면 성공 조건 문장을 한 줄로 줄인 뒤, 그 한 줄을 통과하는 최소 기능만 남깁니다.

목적함수를 정했다면, 다음엔 완전 자율보다 검증이 빠른 부분 자율(Software 3.0 각도)로 에이전트 루프를 조절해 보면 좋습니다. 학습·해커톤·레이드 가이드에서 검증 가능한 제출 습관을 이어 가십시오.