2025년 12월 03일·5분
Andrej Karpathy의 딥러닝: AI 출시를 위한 교훈
Andrej Karpathy의 딥러닝은 명확한 가정, 지표, 엔지니어링 우선 워크플로를 통해 신경망을 제품으로 바꾸는 방법을 보여줍니다.
Andrej Karpathy의 딥러닝은 명확한 가정, 지표, 엔지니어링 우선 워크플로를 통해 신경망을 제품으로 바꾸는 방법을 보여줍니다.
딥러닝 데모는 마법처럼 보일 수 있습니다. 모델이 깔끔한 단락을 쓰거나, 물체를 인식하거나, 까다로운 질문에 답합니다. 그런데 그 데모를 사람들이 매일 누르는 버튼으로 바꾸려 하면 상황이 복잡해집니다. 같은 프롬프트가 다르게 동작하고, 엣지케이스가 쌓이며, 와우 순간이 고객 지원 티켓으로 바뀝니다.
이 간극 때문에 Andrej Karpathy의 접근법이 실무자들에게 공감을 얻었습니다. 그는 신경망을 신비한 산물이 아니라 설계하고, 테스트하고, 유지하는 시스템으로 보도록 사고방식을 밀어붙였습니다. 모델 자체가 쓸모없는 건 아닙니다. 제품은 일관성을 요구할 뿐입니다.
팀들이 "실용적인" AI를 원할 때 보통 네 가지를 뜻합니다:
딥러닝은 확률적이고 문맥에 민감한 반면, 제품은 신뢰도로 평가됩니다. 답을 80% 잘 찾는 챗봇도 나머지 20%가 자신감 있게 틀리고 탐지하기 어렵다면 불완전하게 느껴질 수 있습니다.
예를 들어 고객 지원용 "자동 응답" 어시스턴트를 생각해보세요. 소수의 선별된 티켓에서는 좋아 보입니다. 하지만 운영에서는 고객이 속어를 쓰고, 스크린샷을 첨부하고, 언어를 섞어 쓰거나 정책 관련 엣지케이스를 묻습니다. 이제는 가드레일, 명확한 거부 동작, 초안이 실제로 에이전트에게 도움이 되었는지 측정하는 방법이 필요합니다.
많은 사람이 Karpathy의 작업을 수학적 추상보다 실용적 예제로 처음 접했습니다. 초기 프로젝트조차 단순한 요점을 전달했습니다: 신경망은 테스트하고, 깨고, 고칠 수 있는 소프트웨어로 다뤄질 때 유용해진다.
"모델이 작동한다"에서 멈추지 않고 지저분한 실제 데이터에서 작동하게 만드는 것으로 초점이 바뀝니다. 여기에는 데이터 파이프라인, 지루한 이유로 실패하는 학습 실행, 작은 변경으로 결과가 바뀌는 상황이 포함됩니다. 그런 세계에서 딥러닝은 신비로움이 아니라 공학처럼 느껴집니다.
Karpathy 스타일 접근은 비밀 기법보다 습관에 가깝습니다:
이런 기초는 나중에 중요합니다. 제품 AI는 거의 동일한 게임인데 이해관계가 더 큽니다. 초기부터 명확한 입력, 출력, 반복 가능한 실행을 만들지 않으면 AI 기능을 출시하는 일이 추측 게임이 됩니다.
Karpathy의 큰 영향 중 하나는 신경망을 이성적으로 다룰 수 있는 대상으로 본 것입니다. 명확한 설명은 작업을 "믿음체계"에서 공학으로 바꿉니다.
이는 팀에 중요합니다. 최초 프로토타입을 만든 사람이 유지보수를 하는 사람이 아닐 때가 많습니다. 모델이 무엇을 하는지 설명할 수 없다면 디버그할 수 없고, 운영에서 지원하기도 어렵습니다.
초기에 명확성을 강제하세요. 기능을 만들기 전에 모델이 무엇을 보고, 무엇을 출력하며, 어떻게 나아지는지 판별할지 적으세요. 대부분의 AI 프로젝트는 수학이 아니라 기본에서 실패합니다.
나중에 보상이 되는 짧은 체크리스트:
명확한 사고는 규율 있는 실험으로 드러납니다: 다시 실행할 수 있는 하나의 스크립트, 고정된 평가 데이터셋, 버전 관리된 프롬프트, 기록된 지표. 기준선은 정직하게 만들고 진전을 가시화합니다.
프로토타입은 아이디어가 작동할 수 있음을 증명합니다. 출시된 기능은 실제 사람들이 지저분한 환경에서 매일 사용하는지 증명합니다. 이 간극에서 많은 AI 프로젝트가 멈춥니다.
연구 데모는 느리고 비싸고 취약해도 능력을 보여주면 괜찮습니다. 하지만 제품은 우선순위가 바뀝니다. 시스템은 입력이 이상해도, 사용자가 조급해도, 트래픽이 급증해도 예측 가능하고 관찰 가능하며 안전해야 합니다.
운영에서는 지연 시간이 곧 기능입니다. 모델이 8초 걸리면 사용자는 떠나거나 버튼을 반복 누르고, 재시도마다 비용이 발생합니다. 비용도 제품 결정이 됩니다. 작은 프롬프트 변경이 청구서를 두 배로 만들 수 있습니다.
모니터링은 필수입니다. 서비스가 동작하는지뿐 아니라 출력 품질이 시간이 지나도 허용 범위 내에 있는지 알아야 합니다. 데이터 분포 변화, 새로운 사용자 행동, 상류 변경은 오류를 발생시키지 않고 성능을 조용히 망가뜨릴 수 있습니다.
안전 및 정책 검사는 "있으면 좋은" 것을 넘어서 필수로 이동합니다. 유해한 요청, 개인 데이터, 엣지케이스를 일관되고 테스트 가능한 방식으로 처리해야 합니다.
팀은 보통 같은 질문들에 답해야 합니다:
프로토타입은 한 사람이 만들 수 있습니다. 출시하려면 보통 제품이 성공을 정의하고, 데이터팀이 입력과 평가 셋을 검증하고, 인프라가 안정적으로 운영하며, QA가 실패 모드를 테스트해야 합니다.
"내 기계에서 작동한다"는 출시 기준이 아닙니다. 출시 기준은 사용자가 로드가 있는 상태에서 로깅, 가드레일과 함께 해당 기능이 실제로 작동하고 도움이 되는지를 측정할 수 있어야 합니다.
Karpathy의 영향은 기술적 측면뿐 아니라 문화적 측면입니다. 그는 신경망을 다른 공학 시스템에 적용하는 것과 동일한 규율로 구축하고 테스트하고 개선할 수 있는 대상으로 취급했습니다.
코드는 작성하기 전에 가정을 적는 것으로 시작합니다. 기능이 작동하려면 무엇이 참이어야 하는지 말할 수 없다면 나중에 디버그할 수 없습니다. 예:
이들은 테스트 가능한 주장입니다.
다음은 기준선입니다. 기준선은 가장 단순한 것이며 현실 검증 수단입니다. 규칙일 수도 있고, 검색 템플릿이거나, 심지어 좋은 UI로 "아무 것도 하지 않음"일 수도 있습니다. 강한 기준선은 멋진 모델에 수주를 낭비하는 것을 막아줍니다.
계측은 반복을 가능하게 합니다. 데모만 본다면 분위기에 따라 조종하는 것입니다. 많은 AI 기능의 경우 소수의 숫자만으로도 개선 여부를 알려줍니다:
그다음 긴 루프 대신 짧은 루프로 반복하세요. 한 번에 한 가지를 바꾸고 기준선과 비교하며 시도한 것과 변화를 간단히 기록하세요. 진짜 진전이면 그래프로 보입니다.
AI 출시가 잘 되려면 공학처럼 다루세요: 명확한 목표, 기준선, 빠른 피드백 루프.
드래프팅 도구의 실용적 패턴: "전송까지 걸린 초"와 "약간의 편집으로 사용된 초안의 비율"을 측정하세요.
많은 AI 기능 실패는 모델의 실패가 아닙니다. "우리는 성공이 무엇인지 동의하지 않았다"가 원인입니다. 딥러닝을 실용적으로 만들고 싶다면 더 많은 프롬프트를 쓰거나 모델을 학습시키기 전에 가정과 측정을 적으세요.
실제 사용에서 기능을 망가뜨릴 수 있는 가정부터 시작하세요. 흔한 가정은 데이터와 사람에 관한 것입니다: 입력 텍스트는 한 언어다, 사용자는 한 번에 하나의 의도만 묻는다, UI가 충분한 문맥을 제공한다, 엣지케이스는 드물다, 어제의 패턴이 다음 달에도 유지된다(드리프트). 또한 아직 다루지 않을 것을 적으세요: 빈정거림, 법률 자문, 긴 문서 등.
각 가정을 테스트 가능한 항목으로 바꾸세요. 유용한 형식: "X가 주어지면 시스템은 Y를 해야 하고, 우리는 Z로 검증할 수 있다." 구체적으로 적으세요.
한 페이지에 적어둘 다섯 가지:
오프라인과 온라인을 의도적으로 분리하세요. 오프라인 지표는 시스템이 과제를 학습했는지 말해줍니다. 온라인 지표는 기능이 사람들에게 도움이 되는지 말해줍니다. 모델은 오프라인에서 잘 나와도 느리거나 과도하게 자신감 있거나 중요한 케이스에서 틀려서 사용자를 짜증나게 할 수 있습니다.
"충분히 좋다"를 임계값과 결과로 정의하세요. 예: "오프라인: 평가 세트에서 최소 85% 정답; 온라인: 최소 30%의 초안이 최소 편집으로 수용." 임계값을 놓치면 사전에 무엇을 할지 결정하세요: 토글 뒤에 두기, 롤아웃 축소, 낮은 신뢰도 케이스를 템플릿에 라우팅, 또는 일시 중지하고 더 많은 데이터 수집 등.
팀은 종종 AI 기능을 일반 UI 변경처럼 다룹니다: 출시하고 결과를 본 다음 나중에 조정한다. 모델 동작은 프롬프트, 드리프트, 작은 설정 변경으로 달라질 수 있어 이 방식은 빠르게 실패로 이어집니다. 결과는 많은 노력에 비해 도움이 증명되지 않는 것입니다.
실용 규칙은 간단합니다: 기준선과 측정을 말할 수 없다면 아직 출시하지 마세요.
가장 흔한 실패 모드:
구체적 예: AI로 지원 답변 초안을 추가했다고 합시다. 엄지표시(좋아요)만 추적하면 에이전트가 초안 검토에 더 오래 걸리는지, 답변이 정확하지만 너무 긴지는 놓칠 수 있습니다. 더 나은 측정은 "최소 편집으로 전송된 비율"과 "전송까지의 중앙값 시간"입니다.
출시일을 데모가 아닌 엔지니어링 핸드오프로 취급하세요. 기능이 무엇을 하고, 어떻게 작동하는지, 문제가 생기면 무엇을 할지 평이한 말로 설명할 수 있어야 합니다.
출시 전 확인 사항:
또한 실제 트래픽처럼 보이고 엣지케이스를 포함하며 주간 단위로 비교할 수 있는 오프라인 평가 세트를 유지하세요. 프롬프트, 모델, 데이터 정리를 변경할 때마다 같은 세트를 다시 실행해 무엇이 바뀌었는지 확인하세요.
지원팀이 티켓 뷰 안에서 답변 초안을 작성하는 어시스턴트를 원합니다. 어시스턴트는 스스로 메시지를 보내지 않습니다. 초안을 제안하고 사용한 핵심 사실을 하이라이트하며 에이전트에게 전송 전에 검토하고 편집하도록 요청합니다. 이 한 가지 선택만으로 리스크를 낮추며 학습할 수 있습니다.
먼저 "더 나아짐"을 수치로 결정하세요. 기존 로그에서 즉시 측정할 수 있는 결과를 고르세요:
모델을 들이기 전에 지루하지만 현실적인 기준선을 정하세요: 저장된 템플릿과 간단한 규칙 레이어(환불 vs 배송 vs 비밀번호 재설정 감지 후 최적 템플릿 채우기). AI가 그 기준선을 이기지 못하면 준비가 된 것이 아닙니다.
소규모 파일럿을 운영하세요. 몇 명의 에이전트에게 옵트인으로 하고 한 티켓 카테고리(예: 주문 상태)로 제한하세요. 모든 초안에 대해 빠른 피드백을 추가하세요: "도움이 됐나요" 또는 "아니오"와 간단한 이유. 에이전트가 무엇을 바꿨는지 캡처하세요(단순 클릭 여부만이 아님).
사전에 출시 기준을 정의해 추측하지 않게 하세요. 예: 처리 시간이 10% 개선되면서 에스컬레이션이나 재개방이 증가하지 않고 에이전트가 최소 편집으로 초안을 30% 이상 수용하면 출시.
롤백을 트리거할 조건도 정하세요: 에스컬레이션 급증, 만족도 하락, 반복되는 정책 실수 등.
2~4주 내에 출시할 수 있는 한 가지 AI 아이디어를 고르세요. 디버그하고 롤백할 수 있을 만큼 작게 유지하세요. 목표는 모델이 똑똑하다는 것을 증명하는 것이 아니라 기존보다 사용자 결과를 안정적으로 개선하는 것입니다.
아이디어를 한 페이지 계획으로 바꾸세요: 기능이 무엇을 하고 무엇을 하지 않는지, 그리고 어떻게 작동하는지 알 수 있는 방법. 기준선과 추적할 정확한 지표를 포함하세요.
빠르게 구현하려면 Koder.ai (koder.ai)는 채팅 인터페이스로 웹, 서버, 모바일 앱을 생성하고 스냅샷/롤백 및 소스 코드 내보내기 같은 기능을 제공해 더 깊은 통제가 필요할 때 유용합니다.
유지해야 할 습관은 간단합니다: 모든 AI 변경에는 서면 가정과 측정 가능한 출력이 따라야 합니다. 그게 딥러닝이 마법처럼 느껴지는 것을 멈추고 실제로 출시할 수 있는 작업으로 바꾸는 방법입니다.
데모는 보통 정제된, 선별된 입력에서 만들어지고 분위기로 평가되는 반면, 실제 제품은 지저분한 입력, 사용자 압박, 반복 사용에 직면하기 때문입니다.
격차를 줄이려면 입력/출력 계약을 정의하고, 대표성 있는 데이터에서 품질을 측정하며, 타임아웃과 낮은 신뢰도 케이스에 대한 폴백을 설계하세요.
사용자 가치에 연결되고 주간으로 추적할 수 있는 한 가지 지표를 선택하세요. 좋은 기본값:
튜닝을 하기 전에 "충분히 좋은" 목표를 결정하세요.
실제로 배포할 수 있는 가장 단순한 대안을 사용하세요:
AI가 주요 지표에서 기준선을 이기지 못하면(지연/비용을 심각하게 훼손하지 않고) 아직 출시하지 마세요.
실제 트래픽처럼 보이는 작은 세트를 유지하세요. 베스트케이스 예시만 모은 것이 아니어야 합니다.
실용 규칙:
이렇게 하면 진행이 가시화되고 우발적 회귀를 줄일 수 있습니다.
예측 가능하고 테스트 가능한 가드레일로 시작하세요:
가드레일을 선택적 다듬기가 아니라 제품 요구사항으로 다루세요.
시스템 상태와 출력 품질을 모두 모니터링하세요:
또한 실패를 재현하고 상위 패턴을 고칠 수 있도록 입력/출력을(프라이버시 제어와 함께) 로깅하세요.
사전에 최대 예산을 설정하세요: 목표 지연 시간과 요청당 최대 비용.
그다음 추측하지 말고 지출을 줄이세요:
작은 품질 향상이면 프로덕션에서 큰 비용 또는 속도 저하를 정당화하지 못하는 경우가 많습니다.
플래그 뒤에서 점진적으로 출시하세요.
실용적 롤아웃 계획:
롤백은 실패가 아니라 AI를 유지보수 가능하게 만드는 과정입니다.
최소한으로 필요한 역할(한 사람이 여러 역할을 맡을 수 있음):
모두가 지표, 기준선, 롤백 계획에 동의할 때 출시가 잘 작동합니다.
아이디어에서 작동하는 앱으로 빨리 옮기고 싶지만 엔지니어링 규율을 유지하고 싶을 때 사용하세요.
실용적 워크플로:
도구는 반복을 빠르게 하지만 명확한 가정과 측정 가능한 출력은 여전히 필요합니다.