Karpathy가 던진 경고, Vibe Coding과 Agentic Engineering은 같은 게 아니다

Andrej Karpathy는 Sequoia AI Ascent 2026 무대에서 본인이 만든 “vibe coding”이라는 용어에 스스로 거리를 두는 발언을 했다. “프로그래머로서 이렇게 뒤처졌다고 느낀 적이 없다”는 고백이었다. OpenAI 공동 창립자이자 Tesla AI 디렉터를 거친 사람이 한 말이라 더 무겁다.

핵심 요약

  • 2025년 12월을 기점으로 에이전트 코딩이 “수정 없이 동작하는” 임계점을 통과했다.
  • Vibe coding은 바닥(floor)을 올리고, Agentic engineering은 천장(ceiling)을 올린다. 책임·보안·SLA(서비스 수준 약속)가 완전히 다르다.
  • AI가 만든 코드의 40~62%가 보안 취약점을 안고 있다. 2026년 3월 한 달간 AI 코드가 직접 원인이 된 공개 취약점(CVE)만 35건이었다.

2025년 12월에 무슨 일이 있었나

Karpathy는 인터뷰 도입부에서 시점을 콕 집는다. “agentic 도구를 1년 가까이 써오면서 코드 청크에 자잘한 수정을 해왔는데, 12월이 되자 청크가 그대로 동작했다.” 그가 쓴 표현은 “stark transition”, 분명한 단절이다.

이 전환점은 수치로도 드러난다. Hostinger 조사에 따르면 2026년 3월 기준 전체 개발자의 82%가 AI 코딩 도구를 쓰거나 도입을 준비 중이다. 엔터프라이즈 채택은 전년 대비 340%, 비기술 사용자는 520% 늘었다. Fortune 500 기업의 87%가 vibe coding 플랫폼을 굴린다.

도구 시장도 같은 속도로 부풀었다. Cursor는 $29.3B 가치평가에 ARR $1B+를 돌파했고, 2025년 5월에 나온 Claude Code는 2026년 초 연환산 매출 $2.5B 이상에 도달했다. 점유율은 GitHub Copilot 29%, Cursor와 Claude Code가 각각 18%다.

여기서 한 가지 짚어둘 게 있다. Karpathy 같은 사람이 “뒤처졌다”고 느꼈다는 건, 도구를 안 쓰던 사람의 자조가 아니다. 1년 내내 도구를 쓰던 사람이 어느 시점부터 도구의 출력에 손을 대지 않게 됐다는 뜻이다. 그게 더 무섭다.

Vibe Coding과 Agentic Engineering은 같은 게 아니다

Karpathy는 두 단어를 같은 자리에 두지 말라고 못박는다.

구분Vibe CodingAgentic Engineering
역할바닥(floor)을 올림천장(ceiling)을 올림
적합 영역시제품, 내부 도구, 사이드 프로젝트전문 SW, 운영 프로덕트, 고객 대면 시스템
사용자비개발자 포함전문 엔지니어
책임사용자 본인조직과 엔지니어링 규율

그가 던진 한 문장이 가장 강렬하다. “Vibe coding을 했다는 이유로 취약점을 도입해도 된다는 면죄부는 없다. 당신은 여전히 자신의 소프트웨어에 책임진다.” 한국 B2B 조직의 책임 소재, SLA, 보안 거버넌스 관점에서 이 한 줄이 가장 중요하다.

같은 맥락에서 “10x 엔지니어” 담론도 사망 선고를 받는다. Karpathy는 단언한다. “10x는 더 이상 상한이 아니다. 이걸 정말 잘하는 사람들은 10x를 한참 넘어선다.” 인사·평가·보상 체계가 새 축을 받아들여야 한다는 뜻이다.

Software 3.0, 프롬프트가 곧 프로그램이다

Karpathy의 Software 3.0 정의는 의외로 단순하다. MindStudio 해설을 빌리면 컨텍스트 윈도우가 RAM, 모델 가중치가 CPU, 프롬프트가 프로그래밍이다.

패러다임프로그래밍 단위컴퓨터
Software 1.0명시적 코드(Python·C)결정론적 CPU
Software 2.0학습된 가중치GPU 학습
Software 3.0프롬프트·컨텍스트 윈도우LLM 인터프리터

Karpathy는 자신의 MenuGen 앱 사례를 스스로 깎아내리며 든다. 레스토랑 메뉴 사진을 받아 음식 이미지를 덧씌우는 앱인데, 사실 Gemini와 Nano Banana 프롬프트 하나면 똑같이 만든다. “이 앱 자체가 존재하지 말았어야 했다”는 그의 말은 가볍게 들리지만 뜻이 무겁다. 기존 SaaS(클라우드로 빌려 쓰는 소프트웨어) 사업의 상당수가 모델 한 번 호출로 무너진다는 의미다.

한국 B2B 조직 관점에서 풀면 이렇다. 사내에서 직접 만든 시스템의 약 30%는 Software 3.0 관점에서 다시 보면 존재할 필요가 없다. 어떤 업무 흐름이 모델 호출 한 번으로 사라질 수 있는지, 12개월 안에 목록을 만들어야 한다.

검증가능성, 자동화의 새 좌표축

여기까지가 Software 3.0 이야기다. 그런데 정작 자동화의 속도를 가르는 건 다른 축이다. Karpathy는 verifiability(검증가능성) 프레임워크를 꺼낸다.

“전통 SW는 명세 가능한 것(specify)을 자동화한다. LLM은 검증 가능한 것(verify)을 자동화한다.”

수학, 코딩, 체스, 게임처럼 정답을 기계적으로 가릴 수 있는 분야는 RLVR(검증 가능한 보상 기반 강화학습 — 정답을 채점할 수 있어야 학습이 된다) 환경에서 실력이 가파르게 솟구친다. 반면 글쓰기, 정성 평가, 법무 의견처럼 정답을 가리기 어려운 분야는 상대적으로 더디다.

흥미로운 단서가 있다. Karpathy는 “사실상 거의 모든 것을 어느 정도 검증 가능하게 만들 수 있다 — LLM 판정단을 두면 글쓰기조차 검증 가능해진다”고 덧붙인다. 한국식으로 풀면 사내 업무 100건을 검증가능성 점수(0~10)로 매기고, 7점 이상은 1년 안에 에이전트 업무 흐름으로 옮기고, 4점 이하는 사람이 직접 챙기는(휴먼 인 더 루프) 일로 분리하는 것이 출발점이다.

같은 모델이 천재이자 바보다, Jagged Intelligence

검증가능성과 짝을 이루는 개념이 jagged intelligence다. Karpathy의 비유가 정확히 와닿는다.

“State-of-the-art Opus 4.7이 동시에 100,000라인 코드베이스를 리팩토링하고 zero-day 취약점을 찾으면서도, ’50m 떨어진 카워시까지 걸어갈지 운전할지’를 물으면 가까우니 걸으라고 답하는 대신 운전을 추천한다. 이건 미친 짓이다.”

이 들쭉날쭉함은 두 가지가 겹친 결과다. 검증 가능한 분야에 강화학습(RL)이 몰린 쏠림, 그리고 학습 데이터가 어쩌다 한쪽으로 쏠린 우연. Gary Marcus는 이를 “unpredictable jagged mess”라고 진단했고, OpenAI의 Greg Brockman 본인도 2026년 4월 “현재 기술은 매우 jagged하다, 어떤 작업에서는 초인이지만”이라고 인정한 바 있다.

여기서 실무에 주는 의미는 두 가지다. 하나, 고객을 직접 마주하는 업무 흐름에서 들쭉날쭉한 출력이 한 번이라도 노출되면 신뢰가 무너진다. 모든 운영 업무 흐름에 “사람 최종 승인” 관문과 “에이전트가 스스로 점검(다른 AI가 답을 채점, LLM-as-judge)” 관문 2단을 의무화해야 한다. 둘, 에이전트 출력의 50% 이상이 “이상하다” 판정받는 분야는 자동화 대상에서 빼고 다음 모델 세대를 기다리는 게 합리적이다.

보안 책임자(CISO)가 잠을 잘 수 없는 이유

수치만 놓고 보자. Checkmarx 분석에 따르면 AI가 만든 코드의 40~62%가 보안 취약점을 포함한다. 사람이 짠 코드보다 결함률이 2.74배다. 코드 조각의 약 50%에 취약점이 최소 1개 들어가 있고, XSS(악성 스크립트를 웹페이지에 몰래 끼워 넣는 공격)는 관련 샘플의 86%에서 나타난다.

[아키텍처] AI 모델은 기능을 우선하고 보안은 후순위로 둔다: vibe coding 보안 리스크 구조
출처: Checkmarx — Security in vibe coding

가장 무서운 건 추세다. 2026년 1월 6건, 2월 15건이던 AI 코드가 직접 원인이 된 공개 취약점(CVE)이 3월에는 35건으로 뛰었다. Tenzai 2025-12 연구에서는 주요 AI 코딩 에이전트 5종 모두가 같은 기능을 만들 때 SSRF(서버를 속여 내부 자원에 몰래 요청을 보내게 하는 공격) 취약점을 그대로 넣었다. 가장 흔한 사고는 SQL/JS 인젝션(입력값에 악성 명령을 섞어 넣는 공격), 그리고 코드에 박아둔 비밀번호·API 키가 그대로 저장소에 올라가는(commit·push) 경우다.

Aikido의 CISO 체크리스트는 5개 차단선을 권한다.

  • AI가 만든 코드는 기본적으로 “믿을 수 없는 것(untrusted)”으로 처리
  • 접근 권한, 본인 확인, 비밀정보 관리(secrets management)를 강제
  • 실서비스 전 테스트 환경(staging) 분리
  • 코드 통합·배포 자동화(CI/CD)에 정적 코드 검사(SAST)·실행 중 검사(DAST)·구성요소 검사(SCA) 의무 통과
  • 외부 API 호출은 허용 목록(화이트리스트)으로 따로 관리

한국 시스템 통합(SI)·금융권은 보통 해외보다 1~2분기 늦게 비슷한 사고를 겪는다. 지금 차단선을 문서로 못박지 않으면 1~2년 안에 침해 사고가 사내에서 일어난다고 보는 게 맞다.

채용은 이미 바뀌었다, 그쪽 회사만 안 바뀐 거다

Karpathy의 채용 재설계 제안은 우회적이지 않다. “퍼즐을 풀게 하는 건 옛 패러다임이다. 새 채용은 진짜 큰 프로젝트를 줘서 구현하게 하라. 예를 들어 에이전트용 트위터 클론을 안전하게 만들어 배포하라. 그러고 나서 내가 10개의 codex 5.4 x high를 돌려서 그 웹사이트를 깨뜨려 보겠다. 그게 깨지지 않아야 한다.”

Google과 Meta는 이미 움직였다. Google은 “code comprehension” 라운드를 신설해 기존 코드베이스를 Gemini와 함께 분석·디버깅·최적화하게 한다. 평가 축은 prompt engineering, output validation, debugging skills다. Meta는 2025-10부터 AI 동반 코딩 인터뷰 파일럿을 돌렸고, 2026년부터 백엔드와 운영 직군 전면 확대다.

한국 조직에 옮기면 채용 평가지표는 4축으로 다시 짜인다. 큰 프로젝트를 스스로 구현하는 힘, 프롬프트를 정밀하게 다루는 능력, AI 출력을 검증하고 오류를 잡아내는 능력, 공격 상황을 가정한 보안 견고함이다. 사내 직급(leveling) 기준에도 “AI 도구를 얼마나 잘 다루는가”를 분명히 적어둬야 한다.

Animals vs Ghosts, 유령에게 책임을 떠넘길 수는 없다

여기서 Karpathy의 가장 시적인 비유가 나온다. Animals vs Ghosts 에세이의 핵심 문장이다.

“우리는 동물을 만드는 게 아니다. 유령을 소환하는 것이다(We are not building animals. We are summoning ghosts).”

동물은 진화와 환경 상호작용으로 학습한다. 본능, 호기심, 생존 동기가 있다. LLM은 그렇지 않다. 인류 문서의 통계적 증류물이다. “Pretraining is our crappy evolution.” 본능이 없고, 야단친다고 더 잘하지도 않는다.

Simon Willison 정리에 따르면 Karpathy는 같은 시기 Dwarkesh 인터뷰에서 “AGI는 여전히 10년 더 걸린다”고 못박았다. 즉 현 LLM을 “거의 사람급 동료”로 전제하는 평가·신뢰 프레임은 잘못된 모델링이다.

실무로 가져오면 이렇다. 계약서, SLA, 법무 책임에 “에이전트 출력의 책임 주체는 항상 사람·조직”임을 분명히 적어둬야 한다. AI 공급업체에 책임을 떠넘기는 SLA는 결국 실패한다. 고객 커뮤니케이션도 마찬가지다. “AI를 도입했으니 더 정확하다”는 메시지는 위험하고, “AI를 도입해 사람의 판단력을 증폭한다”가 정확한 포지셔닝이다.

사내 문서가 진짜 병목이다, Agent-Native Infra

Karpathy가 평소 질색하는 게 하나 있다. 표현도 직설적이다. “왜 사람들이 아직도 나에게 뭘 하라고 시키는가? 나는 아무것도 하기 싫다. 내 에이전트에 복사-붙여넣기할 텍스트가 뭔지만 알려달라.”

[아키텍처] 멀티 에이전트 프레임워크의 엔터프라이즈 아키텍처와 생태계 구조
출처: adopt.ai — Multi-agent frameworks 2026

두 표준이 이 흐름의 양축이다. MCP(Model Context Protocol — AI에 외부 도구와 데이터를 연결해주는 표준. Anthropic 주도, 2024년 발표 → OpenAI·Google DeepMind·Linux Foundation 채택, 2026년 월 9,700만 SDK 내려받기)와 llms.txt(Mintlify 주도, 사이트 첫 주소에 두는 마크다운 파일 한 개)다. Karpathy 본인이 공유한 LLM Wiki gist는 한 발 더 나간다. 마크다운 파일을 폴더에 쌓아두고 Claude Code로 물어보는 방식인데, 검색 기반 생성(RAG) 방식보다 약 70배 효율이라는 보고도 나온다.

한국 B2B 조직의 12개월 로드맵은 어렵지 않다. Confluence와 Notion에 흩어진 핵심 문서를 마크다운으로 export해 사내 git repo로 옮긴다. llms.txt와 사내 MCP 서버를 운영한다. 사내 Wiki는 “사람도 읽지만 1차 독자는 에이전트”라는 톤으로 다시 쓴다. 외부 컨텐츠 관점에서도 마찬가지다. 자사 제품과 API 문서가 에이전트 친화적이지 않으면, 1년 안에 자사 제품은 “에이전트가 추천하지 않는” 사각지대로 밀려난다.

사고는 외주할 수 있어도, 이해는 외주할 수 없다

인터뷰의 마지막 한 문장이 가장 오래 남는다.

“You can outsource your thinking, but you can’t outsource your understanding.”

Karpathy는 자신의 지식베이스에 글을 정리하고, LLM에 다양한 각도로 질문을 던지는 행위 자체가 “이해를 만드는 과정”이라고 설명한다. 사고는 외주 가능하지만, 이해는 외주 불가다. 이유는 간단하다. 이해가 없는 사람은 좋은 디렉터가 될 수 없기 때문이다.

CIO Korea의 2026 IT 전망 조사는 한국 기업 생성형 AI 도입 만족도가 58.3%, 금융권은 28.6%로 낮은 편이라고 보고한다. 도구만 사오고 이해는 외주화한 결과로 해석해도 큰 무리가 없다. 시니어 의무 학습 시간을 KPI에 박고, 사내 Wiki에 본인 명의 글을 쓰게 하는 정도의 정공법이 결국 답이다.

90일 안에 뭘 할 수 있을까

길게 끌 필요 없다. Karpathy 인터뷰의 다섯 문장은 다음으로 압축된다.

  1. 2025년 12월, 에이전트 코딩의 임계점이 지나갔다. 한국 B2B 조직은 이미 1~2분기 늦었다.
  2. Vibe coding은 floor를, agentic engineering은 ceiling을 올린다. 두 영역은 책임·보안·SLA가 완전히 다르며 분리 운영해야 한다.
  3. 검증가능성이 자동화의 새 좌표축이다. 사내 워크플로를 verifiability 기준으로 재정렬해야 한다.
  4. LLM은 동물이 아니라 유령이다. 신뢰 모델과 법무 책임을 다르게 설계해야 한다.
  5. 사고는 외주 가능하지만 이해는 외주 불가다. 시니어 인간의 이해 깊이가 곧 조직의 상한이다.

90일짜리 실행 계획으로 옮기면 이렇다. 첫 2주 안에 CEO와 CTO가 모여 5개 안건 중 우선순위를 정한다. 3~4주차에는 보안 책임자(CISO)가 vibe coding 보안 차단선 5개 항목을 문서로 못박아 사내 정책 1차 버전을 배포한다. 5~8주차에는 사내 업무 흐름 100건을 목록으로 정리해 검증가능성과 Software 3.0 점수를 매기고, 상위 5건은 개념검증(PoC, 작게 만들어 가능성부터 확인)에 착수한다. 9~12주차에는 인사와 엔지니어링 총괄(VPE)이 채용 절차 1차 버전을 다시 짠다.

결정권자가 오늘 던져야 할 질문은 하나다. “우리 조직은 vibe coding을 허용하면서 동시에 agentic engineering의 품질 바를 지킬 거버넌스를 갖추고 있을까. 갖추지 못했다면 누가, 언제까지 만들지.” 30초 안에 답이 안 나오면, 다음 임원 회의 안건은 이미 정해진 셈이다.

비슷한 고민을 하는 분이 주변에 있다면 이 글을 공유해주면 좋겠다. 그리고 한 가지 의견이 갈리는 지점이 있다. 운영 코드에 vibe coding 산출물 직접 머지를 전면 금지하는 게 합리적일까, 아니면 SAST·DAST 통과를 조건으로 제한 허용하는 게 현실적일까. 어느 쪽이 맞다고 보는지 궁금하다.

참고 자료

태그

관련 게시물