화자 소개
- Benoit Schillings, Google DeepMind Research 부사장(VP of Research)
- 45년간 코드를 써온 베테랑. Apple II·Commodore 64 시절 어셈블리 언어로 시작한 세대
- 1년 반 전까지 Google X 소속 — Waymo, Google Glass 등을 만든 조직
- 현재 팀의 미션: "1개월~1년 사이에 Gemini를 더 뛰어나게 만드는 데 필요한 모든 기술 개발" (1주일은 너무 근시안적이고, 1년보다 먼 미래는 예측 불가능하다는 이유로 이 구간을 잡음)
- 코드 외에도 추론(reasoning)의 진화, 토폴로지 연구(새로운 네트워크 구조), 강화학습 기초 연구도 담당
Layer 1: 핵심 주장 (3~5개)
1. "코드를 쓰는 것"은 이미 끝난 문제(solved problem)다 — 진짜 어려운 건 소프트웨어 엔지니어링이다
- 근거: "제미나이한테 함수를 마지막으로 짜달라고 한 게 언제였는지 기억도 안 난다. 짜준 걸 보고 '내가 더 잘 짤 수 있겠는데'라고 생각했던 게 마지막이었다" — 즉 문법·구문 수준의 코드 생성(superhuman syntax generation)은 이미 인간을 능가함
- 반면 진짜 어려운 지점은 "입사 첫날 3,500만 줄짜리 PHP 코드베이스를 마주하고 뭔가를 고쳐야 할 때" — 이게 진짜 소프트웨어 엔지니어링이며, 여기서 극도의 복잡성(extreme complexity)을 다루고 잘게 쪼개는 능력은 아직 프론티어 모델도 발전 중인 영역
2. 코드 학습 데이터는 고갈되고 있다 — 다음 단계는 셀프플레이(self-play)
- 근거: 현재 GitHub에 새로 올라오는 코드의 80%가 이미 머신이 생성한 코드 → 인간 지식을 마이닝해서 학습시키는 방식은 한계에 도달
- 대안: 알파제로(AlphaZero)처럼 코드도 스스로 문제를 만들고, 스스로 답의 타당성을 판단하고, 심지어 아키텍처까지 스스로 평가하는 셀프플레이 단계에 진입 중
- 비유: "뛰어난 소프트웨어 엔지니어를 방에 2년간 가둬놓고 피자만 주면서 '더 나은 엔지니어가 돼라'는 미션만 주면 어떻게 할까? 스스로 검증 가능한 챌린지를 만들고 계속 풀 것이다 — 우리도 모델에게 똑같이 시킬 수 있다"
- 즉, 앞으로 초인간적 코딩 능력의 한계는 데이터가 아니라 얼마나 많은 컴퓨팅/셀프플레이 시간을 투입하느냐에 달림
3. 코드가 거의 공짜가 되면서, 경제성과 신뢰의 구조가 근본적으로 바뀐다
- "코드를 쓰는 게 어렵고 비싼 일"이라는 전제 위에 지금까지의 소프트웨어 엔지니어링 문화·인프라·회사들이 세워져 있었는데, 이제 그 전제가 무너짐
- 예측: "1년 안에 우리는 Gemini나 다른 모델이 생성한 코드를 아무도 직접 들여다보지 않게 될 것이다" — 마치 오늘날 컴파일러가 뽑아낸 어셈블리 출력을 아무도 확인하지 않는 것처럼
- 함의: 코드 리뷰의 의미가 바뀌고, 대신 "이 산더미 같은 코드가 미시적 수준에서도 안정적으로 동작하는지" 보장하는 새로운 가드레일과 프로세스가 필요해짐
4. 다음 프론티어는 능동적 보안 가드레일과 "귀납적 아키텍처(inductive architecture)"
- 보안: 이미 모델이 코드를 스캔해 엄청난 수의 취약점을 찾아내는 사례들이 보고되고 있음(발표에서 언급된 사례는 화자가 "mythos"라 발음했으나 정확한 고유명사는 자막상 불분명 — 원문 확인 필요) → 패치 경쟁은 "끝나지 않는 레이스"가 될 것이므로, 화자 팀의 목표는 취약점을 찾아 고치는 게 아니라 애초에 모델이 "처음부터 올바른 코드"를 쓰도록 가르치는 것(맥락 의존성이 커서 매우 어려운 문제)
- 귀납적 사고: 오늘날 모델은 한 도메인의 지식을 다른 도메인으로 전이하거나, 두 개념의 교집합을 찾아 연역적 사고로 연결하는 능력이 아직 부족함. 복잡한 문제를 올바르게 분해(decomposition)하는 계획 능력을 가르치는 게 핵심 과제
5. 평가 방식(benchmark), 사고 방식(모달리티), 프로그래밍 언어 자체도 다시 설계해야 한다
- 기존 벤치마크 비판: "SWE-bench는 코드가 실행되고 올바른 출력을 내는지만 검증한다 — 그건 소프트웨어 엔지니어링의 아주 작은 일부일 뿐"
- 대안 예시: 텍스트 압축 문제 — 10MB 코드를 주고 "손실 없이(lossless) 최고의 압축기를 짜라"는 오픈엔디드(open-ended) 과제. 손실함수 = 압축된 파일 크기 + 소스코드 크기. 이런 끝나지 않는(never-ending) 문제가 모델에게 새로운 알고리즘을 창조하도록 강제함
- 모달리티: 소프트웨어 엔지니어링은 토큰의 연쇄(chain of tokens)가 아니라 시각적 활동(블록 다이어그램, 데이터 흐름)에 가까움 — Gemini를 처음부터 멀티모달로 설계한 이유. 공간적/동적 표현으로 사고하는 모델이 필수가 될 것
- 언어: Python 등 기존 언어는 인간을 위해 만들어졌지 안전하고 신뢰할 수 있는 코드를 위해 만들어진 게 아님. 코드 작성의 고통이 사라진 지금, 오히려 Lean 같은 정리증명 언어에서 영감을 받아 "설계상 완벽할 수밖에 없는" 강타입 언어를 새로 만드는 것도 검토할 시점 — 인간이 읽을 수 있을 필요조차 없을 수도 있음
Layer 2: 세부 논증 및 예시
오리진 스토리 — Pitchfork 프로젝트 (2018, Google X)
- 목표: ML로 코드 작성 속도를 어떻게 높일 수 있는가 — 특히 작은 수정 하나에 3일씩 걸리는 리뷰 사이클을 어떻게 압축할지
- 당시 일부는 "영어로 코드를 쓰는" 바이브 코딩을 이야기했지만, 화자 본인도 "프로그래밍 언어가 왜 있는데, 영어는 프로그래밍 언어가 아니다"라며 완전히 무시했었다고 고백 — "내가 틀렸다"
- 2018년 Google 내부 발표 때는 "왜 ML로 코드를 짜야 하냐"며 아무도 관심 주지 않았음. 이 저항감은 화자 자신의 커리어 궤적(어셈블리 → C++/컴파일러 → 가비지 컬렉션 언어 → 지금은 Python + 바이브 코딩)에서 매번 겪었던 저항감과 닮았다고 회고 — "늙은 개도 새 재주를 배울 수 있다"
소프트웨어의 3개 시대 구분
- 머신이 한계였던 시대: 어셈블리 언어 시절. 기계의 마지막 성능 한 방울까지 짜내야 했음
- 클라우드/모듈화 시대: 컴퓨팅이 저렴해지며 성능보다 "모듈 설계 능력"이 병목이 됨. 라이브러리·함수를 어떻게 쪼갤지가 핵심. 이 시대를 규정한 진짜 제약은 하드웨어가 아니라 인간 뇌의 작업기억(context) 한계 — 전형적인 인간은 컨텍스트를 7~9개 토큰 정도만 유지 가능. 이 한계가 소프트웨어 프로세스 전체(코드 리뷰, 함수 분리 관습 등)를 결정해왔다는 통찰
- AI 프론티어 시대(현재): 코드를 쓰는 것 자체는 더 이상 도전이 아님. 병목은 "내가 진짜 원하는 게 무엇인지"를 명세하는 일. 인간의 남은 역할은 (a) 아키텍트/방향 설정자, (b) 귀납적 사고(inductive thinking) — 시스템을 넓은 맥락에서 보고 패턴을 감지해 판단을 내리는 역할
코드가 학습 데이터로서 특별했던 이유, 그리고 그 특별함이 끝나가는 이유
- 코드는 (1) 데이터가 압도적으로 많았고(GitHub 스크레이핑), (2) 검증이 상대적으로 쉬웠음(실행/컴파일/유닛테스트로 정답 여부 확인 가능) — 이 두 조건이 오늘의 성과를 만들었음
- 하지만 지금은 신규 GitHub 코드의 80%가 머신 생성물이라 "인간 지식 마이닝"이라는 원천이 고갈 중
- 해법은 셀프플레이(AlphaZero 방식): 모델이 스스로 챌린지를 만들고, 스스로 정답 유효성과 아키텍처 품질까지 판단하며 수억 시간의 자기 대국을 돌리는 것. 이제 관건은 데이터가 아니라 "얼마나 많은 컴퓨팅/셀프플레이 시간을 투입할 수 있는가"
코드가 거의 공짜가 된 이후의 함의
- "설계와 적정성(design and adequacy)" 문제: 폭발적으로 늘어날 코드 더미 앞에서 어떻게 미시 수준의 신뢰성을 유지할 것인가 — 인간이 계속 맡아야 할 역할로 지목
- "아무도 코드를 읽지 않게 된다": 코드 리뷰는 남아있지만, 1년 안에 모델이 생성한 코드를 아무도 직접 들여다보지 않게 될 거라 예측. 컴파일러의 어셈블리 출력을 오늘날 아무도 확인하지 않는 것과 같은 궤적
- 이 때문에 능동적 가드레일이 필요: 취약점 탐지 후 패치는 "영원히 끝나지 않는 레이스"(모델이 취약점을 찾음 → 패치 → 더 똑똑한 모델이 더 깊은 취약점을 찾음 → 반복)가 될 것이므로, 화자 팀은 애초에 "처음부터 올바르게" 쓰도록 가르치는 방향을 추구 중 (맥락 의존성이 커서 매우 어렵다고 인정)
벤치마크와 사고 모달리티에 대한 비판
- SWE-bench는 "코드가 돌아가고 올바른 출력을 내는지"만 확인 — 이건 소프트웨어 엔지니어링의 극히 일부에 불과하다고 명시적으로 비판("SWE-bench is infamous in my book")
- 대안으로 제시한 오픈엔디드 평가 예시: 텍스트 압축 — 10MB 코드를 주고 무손실 최고 압축기를 작성시키는 과제. 손실함수는 (압축된 파일 크기 + 소스코드 자체 크기)의 합. 정답이 없는 끝나지 않는(never-ending) 문제라서 모델이 새로운 알고리즘을 창조하도록 강제한다는 점이 핵심
- 사고는 "토큰의 연쇄"가 아니라는 주장: 코드 작성은 본질적으로 시각적 활동(블록 다이어그램, 데이터 흐름도)이라는 점을 강조. Gemini를 처음부터 텍스트를 여러 모달리티 중 하나로만 취급하는 멀티모달 모델로 설계한 이유가 바로 이것이며, 앞으로 공간적/동적 표현으로 사고하는 능력이 필수가 될 것
새로운 프로그래밍 언어에 대한 제안
- Python 등은 인간을 위해 발명된 언어이지, 안전하고 신뢰할 수 있는 코드를 위한 최적 언어는 아님
- 코드 작성의 "고통"이 더 이상 존재하지 않는 지금, 오히려 강타입(strongly typed) 언어나 Lean(정리증명 언어) 스타일의 영감을 받아 "설계상 완벽함(정확성)의 부담을 모델에게 지우는" 새로운 언어를 만드는 게 나을 수 있다는 아이디어 제시
- 이런 언어는 인간이 읽을 수 있는 형태일 필요조차 없을 수 있다고 언급
코드를 넘어서 — "원자(atoms)와 과학"으로의 확장
- 코드로 실험하는 것이 사실상 공짜가 되면서, 이 실험 능력이 다른 과학 도메인에도 빠르게 전이되고 있다는 관찰
- 화학: 인간은 화학을 아주 얕은 수준(a very small sliver)만 이해함. 분자에 원자가 20개를 넘어가면 인간은 그게 무엇을 할지 사실상 모른다고 인정. 1만 개의 원자를 조합하면 "생명체처럼 보이기 시작한다"는 표현으로 잠재력을 강조
- 생물학: "자연은 엄청난 엔지니어링을 해놓고 문서화는 형편없이 했다"는 비유 — 모델이 인간에게는 포착되지 않는 관계들을 발견할 수 있는 영역
- "우리 눈에 보이지 않는 금(the gold we cannot see)": 인간은 정글에서 생존하기 위한 진화적 훈련의 결과물이지 양자컴퓨팅을 위해 진화한 게 아니라는 비유를 들며, 인간의 인지적 편향 때문에 존재 자체를 인지하지 못하는 발전과 돌파구들이 있을 것이라 주장. ML이 그런 사각지대를 드러낼 것이라는 기대로 마무리
Layer 3: 핵심 발언 직접 인용
"Software engineering is not about writing code. Software engineering is the first time you join a company and you realize that there are 35 million lines of PHP in the codebase and that you need to make some changes. That's the day you understand what software engineering is." "소프트웨어 엔지니어링은 코드를 쓰는 게 아닙니다. 소프트웨어 엔지니어링이란, 회사에 처음 입사해서 코드베이스에 3,500만 줄짜리 PHP가 있다는 걸 깨닫고 거기서 뭔가를 바꿔야 한다는 걸 알게 되는 그 순간입니다. 그날이 바로 소프트웨어 엔지니어링이 무엇인지 이해하게 되는 날입니다."
"When is the last time I got Gemini to write a function for me? And I looked at the function and I was like, I can do that better. It's over." "제미나이한테 함수를 짜달라고 한 게 마지막으로 언제였을까요? 그 함수를 보고 '내가 더 잘 짤 수 있겠는데'라고 생각했던 게 마지막이었어요. (그런 시절은) 끝났습니다."
"I think that 80% of the new code added to GitHub today is machine generated. So the notion of human bringing some knowledge that can be used for mining and to train model is reaching an end. But the good news is that we can do selfplay." "오늘날 GitHub에 새로 추가되는 코드의 80%는 머신이 생성한 것이라고 생각합니다. 그래서 모델 학습을 위해 인간이 지식을 마이닝할 수 있게 제공한다는 개념 자체가 끝나가고 있어요. 그런데 좋은 소식은, 우리가 셀프플레이를 할 수 있다는 겁니다."
"We're now in a world where writing code is free or nearly free... I would predict that in one year we'll let Gemini or other model generate the code and nobody will actually look at it." "이제 우리는 코드 작성이 공짜이거나 거의 공짜인 세상에 살고 있습니다... 1년 안에 우리는 제미나이나 다른 모델이 코드를 생성하게 놔두고 아무도 실제로 그걸 들여다보지 않게 될 거라고 예측합니다."
"SWE-bench is infamous in my book because SWE-bench verifies if a piece of code runs and produce the right output. That's only a small part of code engineering." "제 기준에선 SWE-bench는 악명이 높습니다. SWE-bench는 코드 한 조각이 실행되고 올바른 출력을 내는지만 검증하거든요. 그건 코드 엔지니어링의 아주 작은 부분에 불과합니다."
"I always think that code writing is a very visual activity... saying that code will be just a set of tokens that you emit that are going to be the code I think goes only up to a certain point." "저는 항상 코드 작성이 매우 시각적인 활동이라고 생각합니다... 코드가 그저 당신이 뱉어내는 토큰들의 집합일 뿐이라고 말하는 건, 어느 지점까지만 유효하다고 생각합니다."
"Once you have more than 20 atoms in your molecule it's like wow we don't know what that thing is going to do... Biology is the case of nature did an incredible engineering job and terrible job at documentation." "분자에 원자가 20개를 넘어가는 순간 '와, 우리는 이게 뭘 할지 전혀 모른다'는 상황이 됩니다... 생물학은 자연이 엄청난 엔지니어링을 해놓고 문서화는 형편없이 해놓은 사례입니다."
"Humans are incredibly biased in what we feel is the correct solution. I mean, we're the result of an evolutionary training that help us survive in the jungle, right? Not doing quantum computing." "인간은 무엇이 올바른 해법인지 느끼는 데 있어 엄청나게 편향되어 있습니다. 우리는 결국 정글에서 생존하도록 도운 진화적 훈련의 결과물이지, 양자컴퓨팅을 하도록 훈련된 게 아니잖아요."
Layer 4: 실행 포인트 및 시사점
- 코드 생성 자체를 목표로 한 역량 투자는 수익 체감이 빠르다. "함수를 짜는" 수준의 작업은 이미 모델이 인간보다 나은 경우가 흔해졌다는 것이 화자의 진단 — 개인/팀 역량은 "복잡한 대규모 코드베이스를 분해하고 관리하는 능력(멀티스텝 코드베이스 엔지니어링)"과 "문제를 정확히 명세하는 능력" 쪽으로 옮겨가야 함
- 코드 리뷰 프로세스를 지금부터 재설계 검토. 화자는 "1년 내 아무도 AI가 짠 코드를 직접 안 볼 것"이라 예측함 — 실제로 그렇게 되지 않더라도, "리뷰가 사람이 코드를 읽는 것"이라는 전제가 흔들릴 미래에 대비해 자동화된 검증/가드레일 체계를 미리 준비하는 것이 리스크 관리 측면에서 유효
- 보안은 "찾아서 고치기"가 아니라 "애초에 올바르게 쓰게 하기"로 프레임을 바꿔야 한다. 취약점 탐지-패치 사이클은 밑 빠진 독에 물 붓기가 될 가능성이 높다는 경고 — 정적 분석/가드레일보다 생성 단계에서의 정확성 확보에 투자 우선순위를 둘 근거
- 평가지표를 다시 살펴볼 것. "코드가 돌아가는지"만 보는 평가(SWE-bench류)로 조직의 AI 코딩 역량이나 도구를 판단하는 것은 오도될 수 있음 — 오픈엔디드형 과제(예: 압축률처럼 끝없이 개선 가능한 지표)로 실제 역량을 가늠하는 방식을 고려
- 텍스트/토큰 중심 사고의 한계를 인지. 코드/시스템 설계를 다이어그램·시각적 표현으로 다루는 도구·워크플로우가 앞으로 더 중요해질 가능성 — 텍스트 프롬프트에만 의존하는 워크플로우의 한계를 미리 인식
- "코드가 공짜가 된 이후"의 확장 영역(화학·생물학 등 실험이 저렴해지는 도메인)을 관찰할 가치가 있음. 소프트웨어를 넘어 "빠르고 저렴한 실험"이 가능한 어떤 도메인이든 비슷한 폭발적 변화가 올 수 있다는 시사점
- 개인 커리어 관점: 화자 본인이 45년간 여러 패러다임 전환(어셈블리 → 컴파일러 → GC 언어 → 바이브 코딩)에 매번 저항했다가 결국 적응했다고 고백한 대목은, 새로운 도구에 대한 본능적 거부감이 정상적 반응이지만 결국 적응이 필요하다는 실용적 메시지로 읽을 수 있음
원문 출처
- 자막: YouTube 자동 생성 영어 자막 (한국어 자막 다운로드는 429 Too Many Requests로 실패하여 영어 자막 기반으로 번역/정리함)
- 화자 이름 발음: 자막상 "Benois Schillings"로 표기되었으나 정식 표기는 "Benoit Schillings"로 통일함