2025. 6. 19. Andrej Karpathy: Software Is Changing (Again)

Andrej Karpathy의 'Software Is Changing (Again)' 강연 내용을 빠짐없이 정리함.

서론: 다시 변하는 소프트웨어

• Andrej Karpathy는 업계에 진출하려는 학생들을 환영하며 지금이 매우 독특하고 흥미로운 시기라고 말함.
• 근본적인 이유는 소프트웨어가 다시 변하고 있기 때문임.
• 이 강연은 전에도 했지만, 소프트웨어가 계속 변하고 있어 새로운 내용이 많음.
• 소프트웨어는 70년간 근본적인 변화가 없다가 최근 몇 년간 두 번이나 급격히 변했음.
• 이는 새로 작성하고 다시 작성해야 할 소프트웨어가 엄청나게 많다는 것을 의미함.

소프트웨어 1.0 vs 2.0

• 'map of GitHub'를 소프트웨어의 지도로 소개함 (디지털 작업을 위한 컴퓨터 명령어 모음).
• 몇 년 전, 그는 새로운 유형의 소프트웨어인 소프트웨어 2.0을 발견함.
• 소프트웨어 1.0: 당신이 컴퓨터를 위해 작성하는 코드.
• 소프트웨어 2.0: 신경망, 특히 그 가중치.
• 2.0은 직접 작성하는 것이 아니라, 데이터셋을 조정하고 옵티마이저를 실행하여 신경망의 파라미터를 생성함.
• 당시 신경망은 그저 결정 트리 같은 또 다른 분류기로 여겨졌음.
• Hugging Face는 소프트웨어 2.0 시대의 'GitHub'임 (Model Atlas도 언급).
• 시각화 자료의 거대한 점은 이미지 생성기 'flux'이며, 이를 미세 조정하는 것은 2.0 공간에서의 'git commit'과 같음.
• 요약: 1.0 = 컴퓨터 코드, 2.0 = 신경망을 프로그래밍하는 가중치 (예: AlexNet).

소프트웨어 3.0: LLM

• 최근까지 신경망은 '고정된 기능'(예: 이미지->카테고리)을 수행했음.
• 근본적인 변화는 대규모 언어 모델(LLM)을 통해 신경망이 프로그래밍 가능해졌다는 것임.
• 이는 새로운 종류의 컴퓨터이며, 소프트웨어 3.0이라 부를 만함.
• 프롬프트가 이제 LLM을 프로그래밍하는 프로그램이 됨.
• 놀랍게도 이 프롬프트는 영어로 작성됨.
• 예시 (감정 분류):
  • 1.0: 파이썬 코드 작성.
  • 2.0: 신경망 훈련.
  • 3.0: LLM에 프롬프트 (예: few-shot 프롬프트).
• 요즘 GitHub 코드는 1.0(코드)과 3.0(영어)이 혼재되어 있음.
• 그는 이에 큰 충격을 받았으며, 영어로 컴퓨터를 프로그래밍한다는 내용이 현재 그의 고정 트윗임.

스택을 잠식하다

• 테슬라 오토파일럿(Autopilot) 작업 당시, 입력이 조향/가속으로 이어지는 스택이 있었음.
• 초기에는 C++ 코드(1.0)가 많았고, 이미지 인식을 위한 일부 신경망(2.0)이 있었음.
• 시간이 지나 오토파일럿이 개선되면서, 신경망(2.0)의 역량과 크기가 커짐.
• 결정적으로, C++ 코드(1.0)가 삭제되기 시작함.
• 원래 1.0으로 작성된 기능(여러 카메라와 시간 축의 정보 취합 등)이 2.0으로 이전됨.
• 소프트웨어 2.0이 말 그대로 소프트웨어 1.0 스택을 잠식함.
• 그는 지금 똑같은 현상이 다시 일어나고 있으며, 새로운 소프트웨어(3.0)가 스택을 잠식하고 있다고 봄.

세 가지 패러다임

• 이제 우리는 세 가지 다른 프로그래밍 패러다임(1.0, 2.0, 3.0)을 갖게 됨.
• 업계에 진출한다면 세 가지 모두에 능숙해지는 것이 매우 중요함.
• 각각 장단점이 다름.
• 개발자는 명시적 코드(1.0)를 쓸지, 신경망(2.0)을 훈련할지, LLM(3.0)에 프롬프트할지 결정하고, 이 패러다임 간을 유연하게 전환해야 함.

LLM 비유 1: 유틸리티 (전기)

• Andrew Ng의 "AI는 새로운 전기다"라는 말을 인용함.
• LLM은 유틸리티(전기 등)와 유사한 속성을 가짐.
• LLM 랩스(OpenAI, Gemini, Anthropic)의 Capex(자본 지출, LLM 훈련) = 전력망 구축.
• 이들의 Opex(운영 비용, API로 인텔리전스 제공) = 계량된 접근 (토큰당 비용 지불).
• 우리는 유틸리티에 요구하듯 낮은 지연 시간, 높은 가동 시간, 일관된 품질을 요구함.
• 전기에는 '전환 스위치'(전력망, 태양광, 배터리)가 있음.
• LLM에는 '오픈 라우터'(LLM 유형 간 전환)가 있음.
• 여러 '공급자'(LLM)가 있어도 괜찮음. 소프트웨어라 물리적 공간을 두고 경쟁하지 않기 때문.
• 최첨단 LLM이 다운되면, 이는 세상의 '지능 정전(intelligence brownout)'이며 행성이 더 멍청해지는 것임.

LLM 비유 2: 팹 (반도체 공장)

• LLM 구축에 드는 Capex는 매우 큼.
• '기술 트리'가 빠르게 성장하고 있음.
• 심층 기술 트리와 R&D 비밀이 LLM 랩스에 중앙 집중화되고 있음.
• 하지만 소프트웨어는 유연하고 방어하기 어려워 이 비유는 약간 흐려짐.
• 다른 유사점: 4nm 공정 노드 ≈ 최대 FLOPS를 가진 클러스터. 팹리스 모델(Nvidia GPU 사용) vs 인텔 모델(Google이 TPU 자체 제작).

LLM 비유 3: 운영체제 (가장 적절)

• Karpathy가 가장 적절하다고 생각하는 비유임.
• LLM은 단순한 상품(물, 전기)이 아니라 복잡한 소프트웨어 생태계임.
• 생태계가 비슷하게 형성되고 있음:
  • 폐쇄형 소스: Windows/Mac OS ≈ OpenAI/Anthropic/Gemini.
  • 오픈 소스: Linux ≈ Llama 생태계.
• 이는 시작에 불과하며, 도구 사용 및 멀티모달리티와 결합해 훨씬 더 복잡해질 것임.
• 그의 비유 스케치:
  • LLM = CPU.
  • 컨텍스트 창 = 메모리 (RAM).
  • LLM은 문제 해결을 위해 메모리와 컴퓨팅을 조율함.
• 추가 비유:
  • 앱(VS Code)을 다운로드해 Windows/Linux/Mac에서 실행 ≈ LLM 앱(Cursor)을 가져와 GPT/Claude/Gemini에서 실행.
  • 우리는 컴퓨팅의 1960년대에 있음.
  • LLM 컴퓨팅은 매우 비싸서 클라우드에 중앙 집중화됨.
  • 우리는 네트워크를 통해 상호작용하는 '씬 클라이언트'임.
  • 우리는 '시분할(time-sharing)'을 사용함 (우리는 클라우드에서 실행되는 배치의 한 차원임). 1960년대 컴퓨터가 이랬음.
  • 개인용 컴퓨팅(PC) 혁명은 아직 일어나지 않았음 (경제성이 없음).
  • 일부는 시도 중임 (예: Mac Mini는 메모리 바운드(memory-bound)인 배치 1 추론에 적합함). 이는 초기 징후일 수 있음.
• 또 다른 비유:
  • ChatGPT와 텍스트로 대화하는 것 = 터미널을 통해 OS와 대화하는 것.
  • 텍스트 버블 외에 범용적인 GUI가 아직 발명되지 않았음.

결정적 차이: 기술 확산의 방향

• LLM은 초기 컴퓨팅과 한 가지 독특한 차이점이 있음: 기술 확산의 방향을 뒤집음.
• 일반적으로(전기, 암호학, 컴퓨팅, 비행, 인터넷, GPS), 신기술은 정부/기업이 먼저 사용하고 나중에 소비자로 확산됨.
• 초기 컴퓨터: 탄도학/군사 용도.
• LLM: "달걀 어떻게 삶아?" (Karpathy 본인의 사용 예).
• 마법 같은 새 컴퓨터가 군사 기술이 아닌 일상적인 일을 돕고 있음.
• 기업/정부가 소비자 채택 속도보다 뒤처지고 있음.
• 이는 '거꾸로'된 현상이며 초기 앱의 방향성을 알려줌.
• 이 섹션 요약:
  • LLM은 1960년대 수준의 복잡한 운영체제임.
  • 우리는 컴퓨팅을 다시 하고 있음.
  • 시분할 방식으로 제공되며 유틸리티처럼 배포됨.
  • 전례 없는 점: 소수 정부가 아닌 수십억 명의 모든 사람의 손에 즉시 쥐어졌음.
  • "이건 미친 일이다." 이제 우리가 이 컴퓨터를 프로그래밍할 차례임.

LLM의 심리학: '사람의 영혼'

• 이것들이 무엇인지 생각해야 함.
• 그는 LLM을 '사람의 영혼(people spirits)' 또는 사람의 확률적 시뮬레이션으로 생각함.
• 시뮬레이터는 자기회귀 트랜스포머(신경망)임.
• 인터넷 텍스트 전체로 훈련되어 인간과 유사한 심리가 발현됨.
• 초능력:
  • 백과사전적 지식과 기억력 (예: 완벽한 기억력을 가진 영화 <레인맨>처럼 전화번호부나 SHA 해시를 기억함).
• 인지 결함:
  • 환각: 사실이 아닌 것을 지어내며, 자기 인식에 대한 내부 모델이 부족함.
  • 들쭉날쭉한 지능(Jagged Intelligence): 어떤 영역에서는 초인적이지만, 인간은 절대 하지 않을 실수(예: "9.11 > 9.9", "딸기(strawberry)에 R이 2개")를 함.
  • 선행성 기억상실증(Anterograde Amnesia): (영화 <메멘토>, <첫 키스만 50번째>처럼). 인간 동료는 배우고, 자고, 지식을 통합하며 전문성을 쌓음. LLM은 그렇지 않음.
  • 컨텍스트 창은 작업 기억일 뿐임. 가중치는 고정되어 있고 컨텍스트는 매번 지워짐. R&D에서 아직 해결되지 않음.
  • 보안 한계: 속기 쉽고, 프롬프트 인젝션에 취약하며, 데이터를 유출할 수 있음.
• 과제: 이처럼 초능력과 심각한 결함을 동시에 가진 존재를 어떻게 프로그래밍해야 하는가? 결함을 피하고 초능력을 활용하는 방법은?

기회 1: 부분 자율성 앱

• 그가 기대하는 첫 번째 기회임.
• 예시 (코딩): ChatGPT에 가서 복사/붙여넣기를 할 수도 있지만, 왜 '터미널'로 직접 가나?
• Cursor와 같은 전용 앱을 사용하는 것이 훨씬 합리적임.
• Cursor는 초기 LLM 앱의 좋은 예시임.
• 좋은 LLM 앱의 속성:
  1. 전통적인 인터페이스: 인간이 수동으로 모든 작업을 할 수 있음.
  2. LLM 통합: 인간이 더 큰 단위로 작업할 수 있게 함.
  3. 컨텍스트 관리: LLM이 파일 임베딩 등 많은 부분을 처리함.
  4. 오케스트레이션: 여러 LLM 호출(임베딩, 채팅, diff 적용 모델)을 조율함.
  5. 애플리케이션별 GUI: (매우 중요)
     • 텍스트는 읽고 해석하기 어려움.
     • GUI(예: 빨강/초록 diff)는 검토하기 훨씬 쉬움.
     • GUI는 타이핑 대신 명령어(Cmd-Y, Cmd-N) 사용을 가능하게 함.
     • GUI는 인간이 결함 있는 시스템을 감사하고 더 빨리 작업하게 함.
  6. 자율성 슬라이더(Autonomy Slider):
     • Cursor: 탭 완성(낮은 자율성) -> 코드 블록(Cmd-K) -> 파일 전체(Cmd-L) -> 레포 전체(Cmd-I, 완전 자율 에이전트).
     • 사용자가 작업 복잡성에 따라 자율성 수준을 조절함.
• 또 다른 예: Perplexity.
  • 유사한 기능 보유: 정보 패키징, LLM 조율, GUI(출처 인용으로 감사 가능), 자율성 슬라이더(빠른 검색 vs. 리서치 vs. 심층 리서치).
• 그의 질문: 또 어떤 소프트웨어가 부분적으로 자율화될 것인가?
• LLM이 인간이 보는 것을 '보고' 인간이 하는 행동을 '행동'하게 만들어야 함.
• 인간이 감독(루프 안에 머무름)할 수 있어야 함.
• 포토샵에서의 'diff'는 어떤 모습일까?
• 인간을 위해 설계된 기존 소프트웨어(수많은 스위치)는 LLM이 접근할 수 있도록 변경되어야 함.

생성-검증 루프

• 우리는 AI와 협력하고 있음.
• AI = 생성.
• 인간 = 검증.
• 우리는 이 루프를 최대한 빠르게 만들어야 함.
• 속도를 높이는 두 가지 방법:
  1. 검증 속도 높이기:
     • GUI가 극도로 중요함. GUI는 "우리 머릿속의 컴퓨터 비전 GPU"를 활용함.
     • 시각적인 것을 '보는' 것은 재미있고 뇌로 가는 '고속도로'임. 텍스트를 '읽는' 것은 힘든 일임.
     • GUI는 시스템 감사에 탁월함.
  2. AI를 통제 하에 두기(Keep the AI on a Leash):
     • 사람들이 자율 에이전트에 너무 흥분해 있음.
     • 10,000줄짜리 diff는 쓸모없음. 인간이 여전히 병목임 (버그, 보안, 정확성 확인 필요).
     • AI 코딩 지원은 '바이트 코딩'(작은 작업)에는 훌륭하지만, 에이전트가 큰 작업에서 '과잉 반응'하면 좋지 않음.
• 모범 사례:
  • 그는 작은 증분 단위로 작업하며 루프를 빨리 돌리는 자신만의 워크플로우를 개발 중임.
  • 한 블로그 인용: 모호한 프롬프트는 검증 실패로 이어져 시간을 낭비하게 함.
  • 시간을 더 들여 구체적인 프롬프트를 작성하면 -> 검증 성공 확률이 높아져 -> 앞으로 나아갈 수 있음.
• 예시: 교육:
  • 그는 AI 교육에 관심이 많음.
  • ChatGPT에 "물리학 가르쳐줘"라고 하는 것은 작동하지 않음. AI가 "숲속에서 길을 잃기" 때문.
  • 그의 해결책: 중간 산출물(intermediate artifact)을 통해 AI를 통제함.
    • 앱 1: 교사가 앱을 사용해 '코스'(감사 가능한 산출물)를 만듦.
    • 앱 2: 앱이 해당 '코스'를 학생에게 제공함.
    • '코스'(실라버스, 진도)가 AI를 통제함. 이 방식이 성공 확률이 훨씬 높음.

자율주행의 교훈

• 그는 테슬라에서 5년간 부분 자율성을 연구했음.
• 오토파일럿 GUI(계기판)는 신경망이 보는 것을 보여줌.
• 또한 자율성 슬라이더(시간이 지남에 따라 더 많은 작업 수행)가 있음.
• 그의 일화:
  • 2013년 첫 자율주행차(Waymo) 탑승 (구글 글래스로 사진 촬영).
  • 팔로 알토 주변 30분 주행 (고속도로, 시내).
  • 개입 0회.
  • 당시 생각: "와, 자율주행이 임박했다."
  • 하지만 12년이 지난 지금도 여전히 작업 중임.
  • 현재 Waymo조차 텔레오퍼레이션(원격 조작, human in the loop)이 많음.
• 교훈: 소프트웨어는 운전만큼이나 까다로움.
• "2025년은 에이전트의 해"라는 말을 들으면 우려스러움.
• "2020년대는 에이전트의 10년"이 될 것이며 시간이 걸릴 것임. 인간이 루프에 있어야 함.
• 아이언맨 슈트 비유:
  • 그는 아이언맨을 좋아함. 슈트는 두 가지 모두임:
    1. 증강: 토니 스타크가 조종함.
    2. 에이전트: 자율적으로 비행함.
  • 이것이 바로 자율성 슬라이더임.
• 그의 조언:
  • 결함 있는 LLM을 다루는 지금, 우리는 아이언맨 로봇이 아닌 아이언맨 슈트를 만들어야 함.
  • 화려한 자율 에이전트 데모가 아닌 부분 자율성 제품을 만들어야 함.
  • 이 제품들은 인간의 '생성-검증' 루프를 빠르게 만들기 위한 커스텀 GUI/UIUX가 필요함.
  • 하지만 자동화 가능성을 잊지 말고, 제품에 자율성 슬라이더를 탑재하고 시간이 지남에 따라 어떻게 슬라이더를 움직일지 고민해야 함.

기회 2: 바이브 코딩 (Vibe Coding)

• 두 번째 독특한 차원: 프로그래밍 언어가 영어라는 것.
• 이는 모든 사람이 프로그래머가 될 수 있음을 의미. 전례 없는 일임.
• 예전에는 5~10년 공부해야 했지만 이젠 아님.
• 바이브 코딩:
  • 그가 트윗했는데, 별생각 없었지만 거대한 밈(Wikipedia 페이지도 생김)이 됨.
  • "모두가 느끼고 있었지만 말로 표현하지 못했던 것에 이름을 붙여줌."
• 아이들이 바이브 코딩하는 "흐뭇한" 비디오를 보여줌.
• 그는 이것이 소프트웨어 개발의 "입문용 마약(gateway drug)"이 될 것이라 봄.
• 그의 바이브 코딩 경험:
  • Swift를 전혀 모르지만 "아주 기본적인" iOS 앱을 하루 만에 만들었고 폰에서 실행됨.
  • MenuGen을 만듦.
  • 문제: 메뉴를 봐도 음식을 몰라 사진이 필요했음.
  • 앱: 메뉴 사진을 찍으면 이미지를 생성함.
  • (가입 시 5달러 무료 크레딧을 줘서 현재 그에게 "주요 비용 발생원"임).
• 어려웠던 점:
  • 코드 (바이브 코딩 부분)는 쉬웠음 (몇 시간).
  • 그것을 실제로 만드는 것 (인증, 결제, 도메인, Vercel 배포)이 어려웠고 일주일이 더 걸림.
  • 이 "DevOps" 작업은 그가 브라우저에서 클릭하는 일이었고 매우 느렸음.

기회 3: 에이전트를 위한 구축

• MenuGen을 실제화하는 것이 왜 어려웠나?
• 예시: Clerk로 구글 로그인 추가하기. 설명서가 "이 URL로 가시오, 이 드롭다운을 클릭하시오..."라는 지시의 거대한 목록임.
• 그의 생각: "컴퓨터가 나에게 할 행동을 지시하고 있다... 네가 해! 내가 왜 이걸 하고 있지?"
• 핵심 아이디어: 그냥 에이전트를 위해 만들면 안 되나?
• 디지털 정보의 새로운 소비자/조작자 범주가 생김:
  1. 인간 (GUI를 통해)
  2. 컴퓨터 (API를 통해)
  3. 에이전트 (컴퓨터지만, 인간 같은 "사람의 영혼")
• 우리는 그들을 위한 인프라를 구축해야 함.
• 예시:
  • robots.txt: 웹 크롤러에게 행동 방침을 알림.
  • llm.txt (간단한 마크다운): LLM에게 이 도메인이 무엇에 관한 것인지 알림. 이는 LLM이 HTML을 파싱하는 것보다 훨씬 읽기 쉬움.
  • 문서화:
    • 대부분의 문서는 사람을 위한 것임 (목록, 굵은 글씨, 그림). LLM이 접근하기 어려움.
    • Vercel, Stripe 같은 서비스는 LLM을 위한 전용 문서(예: Markdown)를 만들기 시작함.
    • 예: 그가 3Blue1Brown의 manim 라이브러리를 쓰려 할 때, 문서를 읽는 대신 LLM에 복사/붙여넣기하고 원하는 애니메이션을 설명하자 바로 작동함.
  • 문서 변경:
    • 단순히 마크다운으로 바꾸는 것이 끝이 아님. 내용을 바꿔야 함.
    • 문서에 "클릭하세요"라는 말이 있으면 나쁨.
    • Vercel은 "클릭"을 에이전트가 대신 수행할 수 있는 curl 명령어로 대체하고 있음.
    • (Anthropic의 "모델 컨텍스트 프로토콜"도 언급).
• LLM 친화적 도구:
  • LLM이 소화하기 좋은 형태로 데이터를 만드는 도구들.
  • github.com/... -> getingest.com/...: 레포의 모든 파일을 디렉터리 구조와 함께 하나의 거대한 텍스트 파일로 합쳐줌. LLM에 복사/붙여넣기할 준비 완료.
  • deep.wiki/...: (Devon에서) 원시 콘텐츠뿐만 아니라, 에이전트가 레포를 분석하여 문서 페이지를 구축해 줌. LLM에 붙여넣기 훨씬 더 유용함.
• 중간 지점:
  • 물론 LLM이 미래에 (혹은 오늘날에도) '클릭'하는 법을 배울 수 있음.
  • 하지만 LLM이 '클릭'하게 하는 것은 비싸고 어려우므로, 중간에서 만나(meet halfway) 정보 접근을 쉽게 해주는 것이 여전히 가치 있음.
  • 적응하지 않는 수많은 앱(long tail)이 있을 것이므로 '클릭하는 에이전트'도 필요함.
  • 하지만 다른 모든 서비스는 중간 지점에서 만나는 것이 좋음. 그는 두 접근 방식 모두에 대해 낙관적임.

요약

• 업계에 진출하기 놀라운 시대임.
• 전문가와 바이브 코더들이 엄청난 양의 코드를 다시 작성해야 함.
• LLM은 유틸리티 같고, 팹 같지만, 특히 1960년대 운영체제와 같음.
• 이들은 우리가 함께 일하는 법을 배워야 할 "결함 있는 사람의 영혼"임.
• 우리는 그들을 위해 인프라를 조정해야 함.
• 부분 자율성 제품을 만드는 법('생성-검증' 루프를 빠르게 돌리기)과 에이전트를 위한 코드를 작성하는 법을 설명했음.
• 아이언맨 슈트 비유로 돌아가서:
• 향후 10년간 우리는 슬라이더를 왼쪽(증강)에서 오른쪽(에이전트)으로 옮겨갈 것임.
• 모두와 함께 그것을 만들어갈 것이 기대됨.