Andrej Karpathy의 딥러닝: AI 출시를 위한 교훈

딥러닝이 실제 제품에서 자주 사용하기 어려운 이유

딥러닝 데모는 마법처럼 보일 수 있습니다. 모델이 깔끔한 단락을 쓰거나, 물체를 인식하거나, 까다로운 질문에 답합니다. 그런데 그 데모를 사람들이 매일 누르는 버튼으로 바꾸려 하면 상황이 복잡해집니다. 같은 프롬프트가 다르게 동작하고, 엣지케이스가 쌓이며, 와우 순간이 고객 지원 티켓으로 바뀝니다.

이 간극 때문에 Andrej Karpathy의 접근법이 실무자들에게 공감을 얻었습니다. 그는 신경망을 신비한 산물이 아니라 설계하고, 테스트하고, 유지하는 시스템으로 보도록 사고방식을 밀어붙였습니다. 모델 자체가 쓸모없는 건 아닙니다. 제품은 일관성을 요구할 뿐입니다.

팀들이 "실용적인" AI를 원할 때 보통 네 가지를 뜻합니다:

• 반복 가능: 큐레이션된 데모가 아니라 흔한 입력 전반에서 예측 가능하게 동작한다.
• 측정 가능: 감으로 판단하지 않고 숫자로 "좋음"을 정의할 수 있다.
• 유지보수 가능: 데이터, 프롬프트, 모델을 바꿔도 전체가 깨지지 않는다.
• 운영 가능: 출시 후 실패, 비용, 지연, 품질을 모니터링할 수 있다.

딥러닝은 확률적이고 문맥에 민감한 반면, 제품은 신뢰도로 평가됩니다. 답을 80% 잘 찾는 챗봇도 나머지 20%가 자신감 있게 틀리고 탐지하기 어렵다면 불완전하게 느껴질 수 있습니다.

예를 들어 고객 지원용 "자동 응답" 어시스턴트를 생각해보세요. 소수의 선별된 티켓에서는 좋아 보입니다. 하지만 운영에서는 고객이 속어를 쓰고, 스크린샷을 첨부하고, 언어를 섞어 쓰거나 정책 관련 엣지케이스를 묻습니다. 이제는 가드레일, 명확한 거부 동작, 초안이 실제로 에이전트에게 도움이 되었는지 측정하는 방법이 필요합니다.

초기 작업: 신경망을 마법이 아닌 공학으로 대하기

많은 사람이 Karpathy의 작업을 수학적 추상보다 실용적 예제로 처음 접했습니다. 초기 프로젝트조차 단순한 요점을 전달했습니다: 신경망은 테스트하고, 깨고, 고칠 수 있는 소프트웨어로 다뤄질 때 유용해진다.

"모델이 작동한다"에서 멈추지 않고 지저분한 실제 데이터에서 작동하게 만드는 것으로 초점이 바뀝니다. 여기에는 데이터 파이프라인, 지루한 이유로 실패하는 학습 실행, 작은 변경으로 결과가 바뀌는 상황이 포함됩니다. 그런 세계에서 딥러닝은 신비로움이 아니라 공학처럼 느껴집니다.

Karpathy 스타일 접근은 비밀 기법보다 습관에 가깝습니다:

• 단순하더라도 이길 수 있는 기준선을 정하세요.
• "더 낫다/나쁘다"를 결정하는 단 하나의 지표를 선택하세요.
• 한 번에 한 가지씩 바꿔 어떤 변화가 결과를 만들었는지 알게 하세요.
• 최종 점수뿐 아니라 실수와 예제를 들여다보세요.

이런 기초는 나중에 중요합니다. 제품 AI는 거의 동일한 게임인데 이해관계가 더 큽니다. 초기부터 명확한 입력, 출력, 반복 가능한 실행을 만들지 않으면 AI 기능을 출시하는 일이 추측 게임이 됩니다.

실무 엔지니어가 신경망을 이해할 수 있게 만들기

Karpathy의 큰 영향 중 하나는 신경망을 이성적으로 다룰 수 있는 대상으로 본 것입니다. 명확한 설명은 작업을 "믿음체계"에서 공학으로 바꿉니다.

이는 팀에 중요합니다. 최초 프로토타입을 만든 사람이 유지보수를 하는 사람이 아닐 때가 많습니다. 모델이 무엇을 하는지 설명할 수 없다면 디버그할 수 없고, 운영에서 지원하기도 어렵습니다.

유지보수할 계획으로 설명하라

초기에 명확성을 강제하세요. 기능을 만들기 전에 모델이 무엇을 보고, 무엇을 출력하며, 어떻게 나아지는지 판별할지 적으세요. 대부분의 AI 프로젝트는 수학이 아니라 기본에서 실패합니다.

나중에 보상이 되는 짧은 체크리스트:

• 정확한 입력과 출력은 무엇인가(형식, 한계, 마스킹)?
• 반드시 이겨야 할 기준선은 무엇인가(규칙, 검색, 템플릿, 더 작은 모델)?
• "좋다"는 무엇인가(숫자, 루브릭, 또는 둘 다)?
• 용납할 수 없는 실패는 무엇인가(안전, 프라이버시, 브랜드 톤)?
• 누가 얼마나 자주 결과를 검토하는가?

재현성은 설명의 일부다

명확한 사고는 규율 있는 실험으로 드러납니다: 다시 실행할 수 있는 하나의 스크립트, 고정된 평가 데이터셋, 버전 관리된 프롬프트, 기록된 지표. 기준선은 정직하게 만들고 진전을 가시화합니다.

프로토타입에서 제품으로: 출시하면 무엇이 달라지나

프로토타입은 아이디어가 작동할 수 있음을 증명합니다. 출시된 기능은 실제 사람들이 지저분한 환경에서 매일 사용하는지 증명합니다. 이 간극에서 많은 AI 프로젝트가 멈춥니다.

연구 데모는 느리고 비싸고 취약해도 능력을 보여주면 괜찮습니다. 하지만 제품은 우선순위가 바뀝니다. 시스템은 입력이 이상해도, 사용자가 조급해도, 트래픽이 급증해도 예측 가능하고 관찰 가능하며 안전해야 합니다.

갑자기 신경 쓰이는 제약들

운영에서는 지연 시간이 곧 기능입니다. 모델이 8초 걸리면 사용자는 떠나거나 버튼을 반복 누르고, 재시도마다 비용이 발생합니다. 비용도 제품 결정이 됩니다. 작은 프롬프트 변경이 청구서를 두 배로 만들 수 있습니다.

모니터링은 필수입니다. 서비스가 동작하는지뿐 아니라 출력 품질이 시간이 지나도 허용 범위 내에 있는지 알아야 합니다. 데이터 분포 변화, 새로운 사용자 행동, 상류 변경은 오류를 발생시키지 않고 성능을 조용히 망가뜨릴 수 있습니다.

안전 및 정책 검사는 "있으면 좋은" 것을 넘어서 필수로 이동합니다. 유해한 요청, 개인 데이터, 엣지케이스를 일관되고 테스트 가능한 방식으로 처리해야 합니다.

팀은 보통 같은 질문들에 답해야 합니다:

• 허용 가능한 최대 응답 시간과 요청당 비용은 얼마인가?
• 모델이 실패하거나 타임아웃될 때 폴백은 무엇인가?
• 품질을 정의하는 지표와 알림을 트리거할 임계값은 무엇인가?
• 안전하지 않거나 규정에 맞지 않는 출력을 어떻게 막을 것인가?
• 품질이 떨어지면 어떻게 빨리 롤백할 것인가?

모델 기술만으로는 충분하지 않다

프로토타입은 한 사람이 만들 수 있습니다. 출시하려면 보통 제품이 성공을 정의하고, 데이터팀이 입력과 평가 셋을 검증하고, 인프라가 안정적으로 운영하며, QA가 실패 모드를 테스트해야 합니다.

"내 기계에서 작동한다"는 출시 기준이 아닙니다. 출시 기준은 사용자가 로드가 있는 상태에서 로깅, 가드레일과 함께 해당 기능이 실제로 작동하고 도움이 되는지를 측정할 수 있어야 합니다.

엔지니어링 문화: 가정, 기준선, 반복

Karpathy의 영향은 기술적 측면뿐 아니라 문화적 측면입니다. 그는 신경망을 다른 공학 시스템에 적용하는 것과 동일한 규율로 구축하고 테스트하고 개선할 수 있는 대상으로 취급했습니다.

코드는 작성하기 전에 가정을 적는 것으로 시작합니다. 기능이 작동하려면 무엇이 참이어야 하는지 말할 수 없다면 나중에 디버그할 수 없습니다. 예:

• "사용자는 제안된 답변이 정확하고 톤이 맞으면 수용할 것이다."
• "지연 시간이 800ms 이하가 아니면 사용자가 사용을 중단한다."

이들은 테스트 가능한 주장입니다.

다음은 기준선입니다. 기준선은 가장 단순한 것이며 현실 검증 수단입니다. 규칙일 수도 있고, 검색 템플릿이거나, 심지어 좋은 UI로 "아무 것도 하지 않음"일 수도 있습니다. 강한 기준선은 멋진 모델에 수주를 낭비하는 것을 막아줍니다.

계측은 반복을 가능하게 합니다. 데모만 본다면 분위기에 따라 조종하는 것입니다. 많은 AI 기능의 경우 소수의 숫자만으로도 개선 여부를 알려줍니다:

• 채택률(누가 시도하고 계속 사용하는가)
• 품질(수용률, 전송 전 편집 횟수, 좋아요/싫어요)
• 속도(지연 시간과 유용한 첫 출력까지 시간)
• 비용(토큰, 컴퓨트, 사람 검토 시간)
• 안전(정책 위반, 민감 데이터 누출, 우회 시도)

그다음 긴 루프 대신 짧은 루프로 반복하세요. 한 번에 한 가지를 바꾸고 기준선과 비교하며 시도한 것과 변화를 간단히 기록하세요. 진짜 진전이면 그래프로 보입니다.

단계별: AI 기능을 출시하는 간단한 워크플로

AI 출시가 잘 되려면 공학처럼 다루세요: 명확한 목표, 기준선, 빠른 피드백 루프.

1. 사용자 문제를 한 문장으로 적으세요. 실제 사람이 불평할 법한 문장으로 써보세요: "지원 에이전트가 일반적인 질문에 답장 초안 작성에 너무 많은 시간을 쓴다." 한 문장으로 말할 수 없다면 기능이 너무 클 가능성이 큽니다.
2. 측정 가능한 결과를 선택하세요. 주간으로 추적할 수 있는 한 가지 숫자를 고르세요. 좋은 선택은 작업당 절약된 시간, 초안 수락률, 편집 감소, 티켓 디플렉션율 등입니다. 무엇이 "충분히 좋은지" 미리 결정하세요.
3. 이겨야 할 기준선을 정의하세요. 간단한 템플릿, 규칙 기반 접근, 또는 "사람만"과 비교하세요. AI가 선택한 지표에서 기준선을 이기지 못하면 출시하지 마세요.
4. 대표성 있는 데이터로 작은 테스트를 설계하세요. 현실과 맞는 예시를 수집하세요. 지저분한 케이스 포함. 매일 "훈련 데이터"처럼 읽어버려 정신적으로 학습시키지 않도록 작은 평가 세트를 따로 보관하세요. 통과와 실패 기준을 적어두세요.
5. 플래그 뒤에서 출시하고 피드백을 모아 반복하세요. 내부 소수 그룹이나 소수 비율의 사용자로 시작하세요. 입력, 출력, 도움이 되었는지 여부를 기록하세요. 가장 큰 실패 모드를 먼저 고치고 동일한 테스트를 다시 실행해 실제 진전을 확인하세요.

드래프팅 도구의 실용적 패턴: "전송까지 걸린 초"와 "약간의 편집으로 사용된 초안의 비율"을 측정하세요.

명확한 가정과 측정 가능한 출력(작성해야 할 것)

많은 AI 기능 실패는 모델의 실패가 아닙니다. "우리는 성공이 무엇인지 동의하지 않았다"가 원인입니다. 딥러닝을 실용적으로 만들고 싶다면 더 많은 프롬프트를 쓰거나 모델을 학습시키기 전에 가정과 측정을 적으세요.

실제 사용에서 기능을 망가뜨릴 수 있는 가정부터 시작하세요. 흔한 가정은 데이터와 사람에 관한 것입니다: 입력 텍스트는 한 언어다, 사용자는 한 번에 하나의 의도만 묻는다, UI가 충분한 문맥을 제공한다, 엣지케이스는 드물다, 어제의 패턴이 다음 달에도 유지된다(드리프트). 또한 아직 다루지 않을 것을 적으세요: 빈정거림, 법률 자문, 긴 문서 등.

각 가정을 테스트 가능한 항목으로 바꾸세요. 유용한 형식: "X가 주어지면 시스템은 Y를 해야 하고, 우리는 Z로 검증할 수 있다." 구체적으로 적으세요.

한 페이지에 적어둘 다섯 가지:

• 입력: 모델이 보는 것(필드, 한계, 마스킹)과 "충분히 깨끗"의 정의
• 출력 계약: 반환해야 할 것(형식, 톤, 허용된 동작)
• 오프라인 평가: 채점 규칙이 있는 작은 라벨링된 세트(통과/실패와 지표)
• 온라인 지표: 사용자의 행동(수용률, 편집, 절약된 시간, 재개방된 티켓)
• 가드레일: 언제 거부하고, 질문하고, 더 단순한 흐름으로 폴백할지

오프라인과 온라인을 의도적으로 분리하세요. 오프라인 지표는 시스템이 과제를 학습했는지 말해줍니다. 온라인 지표는 기능이 사람들에게 도움이 되는지 말해줍니다. 모델은 오프라인에서 잘 나와도 느리거나 과도하게 자신감 있거나 중요한 케이스에서 틀려서 사용자를 짜증나게 할 수 있습니다.

"충분히 좋다"를 임계값과 결과로 정의하세요. 예: "오프라인: 평가 세트에서 최소 85% 정답; 온라인: 최소 30%의 초안이 최소 편집으로 수용." 임계값을 놓치면 사전에 무엇을 할지 결정하세요: 토글 뒤에 두기, 롤아웃 축소, 낮은 신뢰도 케이스를 템플릿에 라우팅, 또는 일시 중지하고 더 많은 데이터 수집 등.

팀이 AI를 제품에 추가할 때 흔히 하는 실수

팀은 종종 AI 기능을 일반 UI 변경처럼 다룹니다: 출시하고 결과를 본 다음 나중에 조정한다. 모델 동작은 프롬프트, 드리프트, 작은 설정 변경으로 달라질 수 있어 이 방식은 빠르게 실패로 이어집니다. 결과는 많은 노력에 비해 도움이 증명되지 않는 것입니다.

실용 규칙은 간단합니다: 기준선과 측정을 말할 수 없다면 아직 출시하지 마세요.

가장 흔한 실패 모드:

• 비AI 기준선 없이 출시해서 개선을 입증할 수 없음
• 지연과 비용을 무시한 채 품질만 쫓음(3% 개선이 5배 느려지는 것을 정당화하지 못함)
• "사용자가 좋아한다" 같은 모호한 피드백에 의존하고 계측을 하지 않음
• 실제 트래픽과 맞지 않는 작은 또는 선별된 테스트셋에 튜닝함
• 프롬프트나 모델 업데이트가 이상 출력을 만들 때 롤백 계획이 없음

구체적 예: AI로 지원 답변 초안을 추가했다고 합시다. 엄지표시(좋아요)만 추적하면 에이전트가 초안 검토에 더 오래 걸리는지, 답변이 정확하지만 너무 긴지는 놓칠 수 있습니다. 더 나은 측정은 "최소 편집으로 전송된 비율"과 "전송까지의 중앙값 시간"입니다.

출시 전 빠른 체크리스트

출시일을 데모가 아닌 엔지니어링 핸드오프로 취급하세요. 기능이 무엇을 하고, 어떻게 작동하는지, 문제가 생기면 무엇을 할지 평이한 말로 설명할 수 있어야 합니다.

출시 전 확인 사항:

• 한 문단 문제 진술과 명확한 대상 사용자
• 측정된 기준선(단순해도 됨)
• 사용자 가치에 연결된 주요 온라인 지표 하나와 입력/출력/결과를 캡처하는 로그
• 안전 검토: 가능한 실패 모드, 누가 피해를 볼 수 있는지, UI의 동작(경고, 차단, 확인 요청)
• 롤백 계획과 오너: 무엇이 롤백을 트리거하고 첫 한 시간에 무엇을 확인할지

또한 실제 트래픽처럼 보이고 엣지케이스를 포함하며 주간 단위로 비교할 수 있는 오프라인 평가 세트를 유지하세요. 프롬프트, 모델, 데이터 정리를 변경할 때마다 같은 세트를 다시 실행해 무엇이 바뀌었는지 확인하세요.

예시 시나리오: AI 지원 드래프팅 기능 출시

지원팀이 티켓 뷰 안에서 답변 초안을 작성하는 어시스턴트를 원합니다. 어시스턴트는 스스로 메시지를 보내지 않습니다. 초안을 제안하고 사용한 핵심 사실을 하이라이트하며 에이전트에게 전송 전에 검토하고 편집하도록 요청합니다. 이 한 가지 선택만으로 리스크를 낮추며 학습할 수 있습니다.

먼저 "더 나아짐"을 수치로 결정하세요. 기존 로그에서 즉시 측정할 수 있는 결과를 고르세요:

• 평균 처리 시간(오픈에서 해결까지)
• 편집 비율(에이전트가 초안을 전송 전에 얼마나 바꾸는가)
• 에스컬레이션 비율(상위 티어로 올리는 비율)
• 재개방 비율(7일 내 재개방된 티켓)
• 고객 만족 점수(이미 추적 중이라면)

모델을 들이기 전에 지루하지만 현실적인 기준선을 정하세요: 저장된 템플릿과 간단한 규칙 레이어(환불 vs 배송 vs 비밀번호 재설정 감지 후 최적 템플릿 채우기). AI가 그 기준선을 이기지 못하면 준비가 된 것이 아닙니다.

소규모 파일럿을 운영하세요. 몇 명의 에이전트에게 옵트인으로 하고 한 티켓 카테고리(예: 주문 상태)로 제한하세요. 모든 초안에 대해 빠른 피드백을 추가하세요: "도움이 됐나요" 또는 "아니오"와 간단한 이유. 에이전트가 무엇을 바꿨는지 캡처하세요(단순 클릭 여부만이 아님).

사전에 출시 기준을 정의해 추측하지 않게 하세요. 예: 처리 시간이 10% 개선되면서 에스컬레이션이나 재개방이 증가하지 않고 에이전트가 최소 편집으로 초안을 30% 이상 수용하면 출시.

롤백을 트리거할 조건도 정하세요: 에스컬레이션 급증, 만족도 하락, 반복되는 정책 실수 등.

다음 단계: 다음 AI 출시에 이 교훈 적용하기

2~4주 내에 출시할 수 있는 한 가지 AI 아이디어를 고르세요. 디버그하고 롤백할 수 있을 만큼 작게 유지하세요. 목표는 모델이 똑똑하다는 것을 증명하는 것이 아니라 기존보다 사용자 결과를 안정적으로 개선하는 것입니다.

아이디어를 한 페이지 계획으로 바꾸세요: 기능이 무엇을 하고 무엇을 하지 않는지, 그리고 어떻게 작동하는지 알 수 있는 방법. 기준선과 추적할 정확한 지표를 포함하세요.

빠르게 구현하려면 Koder.ai (koder.ai)는 채팅 인터페이스로 웹, 서버, 모바일 앱을 생성하고 스냅샷/롤백 및 소스 코드 내보내기 같은 기능을 제공해 더 깊은 통제가 필요할 때 유용합니다.

유지해야 할 습관은 간단합니다: 모든 AI 변경에는 서면 가정과 측정 가능한 출력이 따라야 합니다. 그게 딥러닝이 마법처럼 느껴지는 것을 멈추고 실제로 출시할 수 있는 작업으로 바꾸는 방법입니다.