1부에서 인물의 입장과 발언을 정리했다면, 2부는 현실 적용입니다. 핵심은 한마디로 “AI가 빠르게 좋아졌기 때문에 팀이 바로 바뀌어야 한다”가 아니라, 어떤 실수부터 고칠지 순서를 맞추어야 한다는 점입니다.
먼저 분명히 짚고 가겠습니다. Karpathy가 전하는 메시지는 ‘AI 코딩을 무조건 쓰라’가 아니라, 인간이 제일 많이 틀리는 지점이 어디인지 정확히 찍는 신호입니다.
Part 2-1. 바로 적용 가능한 점검표: 1주일 안에 할 일
실무 팀이 이 글만 보고 바로 실행할 수 있는 순서를 제안합니다.
1. 작업의 단위를 ‘기능’이 아니라 ‘목표’로 바꾼다
전통적으로 우리는 PR 단위로만 관리했습니다. AI 시대에는 PR 하나가 수십 개 의도를 품습니다.
- 에이전트에게 “기능 구현”이 아닌 “목표 상태”를 먼저 내린다
- 산출물은 코드 diff보다, 성공 기준으로 정의한다
- 마감 후 검증은 사람이 아닌 오케스트레이션 규칙이 맡는다
예를 들어 “로그인 화면 변경” 대신 “로그인 실패율 24시간 동안 0.2% 감소” 같은 목표로 바꿉니다.
2. 코딩 에이전트가 실패한 흔적을 추적한다
Karpathy의 주장은 한순간 반응이 아닙니다. 핵심은 반복 실패 데이터를 모으는 습관입니다.
- 에이전트별로 재시도 횟수 기록
- 생성 코드에서 사람이 가장 많이 수정한 영역 추적
- 테스트 실패 패턴별 루트카즈 정합성 비교
“잘 돌아가는 날”만 기억하면 팀은 점점 오판합니다. AI가 잘한 날보다 실수한 날이 더 큰 운영 비용을 만들기 때문입니다.
3. 승인 지점을 줄이는 게 아니라, 올바르게 나눈다
많은 팀이 승인 단계를 단순히 더 줄이려고 합니다. 하지만 AI 전환기엔 오히려 승인 설계가 더 정교해져야 합니다.
- 저위험 변경: 빠른 승인 + 자동 테스트
- 중간 위험: 수동 리뷰 + 자동 릴리즈 룰
- 고위험 변경: 단계 배포 + 롤백 조건 사전 등록
핵심은 “누가 승인했는가”가 아니라 “어떤 조건에서 승인했는가”를 기록하는 것입니다.
Part 2-2. Karpathy 발언이 암시한 엔지니어 역할의 재정의
보도된 발언에서 반복되는 흐름을 보면, 그는 역할 이동을 분명히 말하고 있습니다.
- 과거 역할: 구현 자체를 직접 작성
- 현재 역할: 목표 설정, 품질 기준 부여, 실패 시 대처 로직 설계
- 미래 역할: 모델 업데이트에 따라 전략을 재학습
여기서 팀 리더가 흔히 저지르는 실수가 있습니다. “개발자를 AI로 대체”라는 프레임으로 인력 정책을 짜는 겁니다. 그런 프레임은 단기 생산성은 줄 수 있어도 장기 품질을 깎습니다.
대신 필요한 건 ‘기술자 인력의 위계’를 바꾸는 것입니다.
- 코드 작성 능력
- 코드 판단 능력
- 시스템 통합 능력
세 번째가 가장 빨리 가치가 올라갑니다.
Part 2-3. 조직 규칙 6개(짧게, 그러나 강하게)
- 에이전트 프롬프트 템플릿을 버전 관리한다.
- 같은 의도를 매번 같은 톤과 제약으로 발화할 수 있어야 재현성이 나온다.
- 프롬프트-코드-테스트를 한 묶음으로 추적한다.
- “어떤 문장으로 뽑았는지”가 실패 분석에서 다시 필요하다.
- 리뷰를 빠르게 하되, 자동화 가능한 검증은 자동화한다.
- 문법 검사, 보안 스캐닝, 타입 검사, 계약 테스트는 모두 기계가 담당한다.
- 에이전트 실수는 실패가 아니라 데이터 포인트로 본다.
- 어떤 클래스에서 misfire가 잦은지 기록한다.
- 수동 디버깅을 금지하지 않는다.
- 복잡 이슈는 사람이 직접 추적해 인과를 기록해야 한다.
- 월 단위로 작업 프로세스를 점검한다.
- 도구 변경 속도가 빠르므로 운영 규칙도 월 단위 회고를 가져야 한다.
Part 2-4. 커리어 관점: 개인이 가장 먼저 바꿔야 할 두 가지 습관
Karpathy가 던진 경고를 경력 관점으로 번역하면 이렇게 정리됩니다.
습관 1: 코드량 지표에서 벗어나라
평가 기준이 diff의 줄 수였다면, 이제는 문제 해결의 속도와 안정성 비용으로 바뀌어야 합니다.
- 새 기능을 1일 내 전달했는가
- 장애 후 복구 시간이 얼마나 줄었는가
- 팀의 재사용률/재현성 지표가 개선됐는가
습관 2: 모델이 아는 것에 맞추지 말고, 팀이 모르는 위험을 가려라
AI는 강력합니다. 그런데 강력함은 오히려 위험을 덮어버립니다.
- “동작은 된다”를 신뢰하지 말고 “왜 동작하는지 설명 가능한가”를 검증한다.
- 사람의 직관을 지우지 말고, 실험 전 가설을 선명하게 만든다.
결론: 이번 주 실천 과제
Karpathy의 최신 X 목소리는 결국 이 한 줄입니다.
- 새 도구가 문제를 해결한다는 믿음보다, 우리가 새 규칙을 붙일 수 있다는 자신감이 중요하다.
다음 7일 안에 팀 회의에서 바로 정하고 실행할 수 있는 제안입니다.
- 1개 파일은 “AI 생성 후 자동 검증” 워크플로로 바꾸기
- 1개 프로젝트는 단계 배포 전략으로 전환하기
- 1개 미팅은 실패 사례 회고를 기준으로 30분만 할애
그리고 여기서 가장 실무적인 질문 하나만 던집니다.
당신 팀은 지금 AI를 ‘코드 생산기’로 쓰고 있나요, 아니면 ‘제품 신뢰도를 배가시키는 운영 엔진’으로 쓰고 있나요?
적용 체크 소스
