Oxide and Friends 팟캐스트 예측 특집에 출연해 1년, 3년, 6년 뒤 기술 업계—특히 코딩 에이전트와 샌드박싱, 보안—에 대한 전망을 정리했다.
이번 뉴스레터에서:
그리고 링크 6개, 인용 5개, 노트 2개
이 뉴스레터가 유용하다면 GitHub를 통해 후원해 주시는 것도 고려해 주세요. 월 $10 이상 후원자는 지난 30일의 가장 중요한 트렌드를 제가 요약한 월간 뉴스레터를 받을 수 있습니다. 8월과 9월 프리뷰도 참고하세요.
화요일에 Oxide and Friends 팟캐스트 녹음에 참여해 기술 업계의 1년, 3년, 6년 전망에 대해 이야기했습니다. 이들의 연례 예측 에피소드에 출연한 건 이번이 두 번째이며, 2025년 1월에 했던 제 예측은 여기에서 볼 수 있습니다. 올해 에피소드의 페이지는 여기이며, 좋아하는 팟캐스트 앱에서 들을 수 있고 YouTube에서 바로 보기도 가능합니다.
Bryan Cantrill은 에피소드를 시작하며 다음 1년 동안 무엇이 올지 그 어느 때보다도 확신이 없다고 선언했습니다. 저도 그 불확실성을 공유합니다. 지난 두 달 사이에 코딩 에이전트가 크게 발전한 덕분에 상황이 크게 바뀔 거라는 확신은 있지만, 그 변화가 정확히 어떤 형태일지는 저도 알 수 없습니다.
다음은 에피소드에서 제가 공유한 예측들입니다.
여전히 LLM이 좋은 코드를 쓸 수 없다고 확신하는 사람들이 있다고 생각합니다. 그 사람들은 2026년에 아주 불쾌한 충격을 맞게 될 겁니다. 앞으로 심지어 다음 3개월이 끝날 때까지도 ‘LLM이 쓰는 코드는 전부 쓰레기고, 웬만한 인간 프로그래머라면 다 더 잘 짠다’는 생각을 계속 붙잡고 있는 건 불가능해질 거라고 봅니다.
2023년에는 “LLM은 쓰레기 코드를 쓴다”는 말이 완전히 맞았습니다. 2024년 대부분도 그랬고요. 2025년에 그게 바뀌었지만, 여전히 회의적인 입장을 유지해도 이해할 수는 있었습니다. 2026년에는 LLM이 생성한 코드의 품질이 ‘부정 불가능한 수준’이 될 것입니다.
이 예측은 제 경험에 기반합니다. 저는 대부분의 사람보다 더 많은 시간을 AI 보조 프로그래밍을 탐구하는 데 썼습니다.
2025년의 핵심 변화( 한 해를 정리한 제 글 참고)는 강화학습(Reinforcement Learning)으로 코드에 특히 맞춰 학습된 ‘추론 모델(reasoning models)’의 도입이었습니다. 주요 연구소들은 모델에서 최고의 코딩 능력을 뽑아내기 위해 1년 내내 경쟁했고, 코드 챌린지에는 성공 조건을 검증할 수 있는 장치가 내장되어 있기 때문에 이 문제는 RL과 완벽하게 궁합이 맞는 것으로 드러났습니다.
11월과 12월에 각각 Claude Opus 4.5와 GPT-5.2가 출시된 이후, 제가 손으로 직접 작성한 코드의 비율은 전체 산출물에서 한 자릿수 퍼센트까지 떨어졌습니다. 제가 아는 다른 많은 숙련 프로그래머들도 마찬가지입니다.
이 시점에서 “LLM은 쓸모없는 코드를 쓴다”는 주장을 계속하면 스스로의 신뢰도를 깎아먹는 것입니다.
올해가 샌드박싱을 해결하는 해가 될 거라고 생각합니다. 저는 다른 사람이 작성한 코드를 제 컴퓨팅 장치에서 실행하되, 그 코드가 악성이거나 버그가 있더라도 제 장치를 파괴하지 못하게 하고 싶습니다. [...] 2026년인데도 여전히 랜덤한 코드에
pip install을 하고, 그걸 실행해서 제 모든 데이터를 훔치고 모든 파일을 삭제할 수도 있는 방식으로 돌린다는 게 미친 일입니다. [...] 앞으로는 누가 쓴 코드든 샌드박스 밖에서 제 어떤 기기에서도 실행하고 싶지 않습니다.
이건 LLM만의 문제가 아니지만, 지금은 무엇을 하는지도 잘 모른 채 코드를 작성하는 사람이 훨씬 늘어난 만큼 더 중요해졌습니다. 샌드박싱은 프롬프트 인젝션과의 싸움에서도 핵심 요소입니다.
이미 쓸 만한 유망 기술이 매우 많습니다. 그중 제가 가장 낙관하는 건 컨테이너와 WebAssembly입니다. 이 문제를 해결하는 데는 실질적인 상업적 가치도 있습니다. 조각들은 이미 갖춰져 있고, 필요한 건 마찰을 줄여 이들을 생산적이고 안전하게 쓰게 만드는 UX 작업입니다.
코딩 에이전트 보안에 관해서는 ‘챌린저 참사’가 한번 터질 때가 됐다고 생각합니다[...] 저를 포함해 정말 많은 사람들이 사실상 루트 권한으로 이런 코딩 에이전트를 돌리고 있잖아요? 온갖 일을 하도록 내버려두고요. 그런데 매번 그렇게 해도 제 컴퓨터가 지워지지 않으니까, “아, 괜찮네”라고 생각하게 됩니다.
이 예측을 통해 제가 좋아하는 최신 AI 보안 에세이를 소개하고 싶었습니다. Johann Rehberger의 AI에서의 일탈 정상화(The Normalization of Deviance in AI)입니다.
‘일탈 정상화’는 사람과 조직이 ‘아직 나쁜 일이 일어나지 않았기 때문에’ 위험한 방식으로 운영하는 데 익숙해지고, 운이 다하는 순간(1986년 챌린저 참사 같은) 엄청난 문제가 터질 수 있다는 현상을 설명합니다.
저는 6개월마다 “곧 헤드라인을 장식할 프롬프트 인젝션 공격이 터질 것이다”라고 예측하는데, 6개월마다 그게 일어나지 않곤 합니다. 이번은 그 예측의 최신 버전입니다!
(지금 많은 프로그래머들이 느끼는 깊은 실존적 공포에 대한 논의 뒤, 분위기를 가볍게 하려고 이 예측을 넣었습니다!)
뉴질랜드의 카카포(Kākāpō) 앵무새들이 뛰어난 번식 시즌을 맞게 될 거라고 생각합니다. 그 이유는 지금 리무(Rimu) 나무가 결실을 맺고 있기 때문입니다. 카카포는 250마리밖에 남지 않았고, 리무 나무가 열매를 잘 맺는 해에만 번식을 합니다. 리무 나무는 2019년 이후로 상태가 나빴는데, 올해는 리무 나무들이 모두 꽃을 피웠어요. 연구자들은 번식 가능한 나이의 암컷 87마리 모두가 알을 낳을지도 모른다고 말하고 있습니다. 250마리밖에 남지 않은 종에게는 엄청나게 좋은 소식이죠.
(방금 위키피디아를 확인했는데, 앵무새 개체 수는 맞췄지만 마지막으로 좋은 번식 시즌이 언제였는지는 틀렸네요. 2022년이 좋은 해였다고 합니다.)
좋은 소식이 거의 없는 한 해에, 이 이야기를 공유할 수 있어 정말 기쁩니다. 더 알아보기:
Kākāpō breeding season 2026 — 2025년 6월 자연보전부(Department of Conservation)의 소개 글.
Bumper breeding season for kākāpō on the cards — 2025년 12월 3일, 오클랜드 대학교.
저는 이 블로그에서 AI 생성 이미지를 자주 쓰지는 않지만, Oxide 팀이 이번 에피소드를 위해 만든 카카포 이미지는 정말 _완벽_합니다:
제번스 역설(Jevons paradox)이 우리 커리어를 구할지 아닐지를 알게 될 겁니다. 지금 소프트웨어 엔지니어라면 누구나 갖는 큰 질문이죠. 우리는 실제로 동작하는 코드를 만들어내는 비용을 과거의 일부로 떨어뜨리고 있습니다. 그게 우리의 커리어가 완전히 평가절하되어 모두 소득의 10분의 1로 살아야 한다는 뜻일까요? 아니면 커스텀 소프트웨어에 대한 수요가 10배로 늘어나서, 이제는 ‘나를 고용하면 예전보다 10배 더 많은 소프트웨어를 만들 수 있다’는 이유로 우리의 역량이 더 가치 있어진다는 뜻일까요? 3년쯤 지나면 이게 어느 쪽으로 갔는지 확실히 알게 될 거라고 생각합니다.
인용문이 모든 걸 말해 줍니다. 코딩 에이전트는 두 가지 방향으로 갈 수 있습니다. 소프트웨어 엔지니어링 기술이 평가절하되거나, 혹은 우리가 그 어느 때보다도 더 가치 있고 더 효율적이게 되거나.
저는 후자를 바라며 손가락을 꼬고 있습니다! 지금까지의 느낌으로는 정말 그쪽으로 가는 것 같습니다.
누군가 AI의 도움을 주로 받아 완전한 웹 브라우저를 만들 것이고, 그건 놀랍지도 않을 거라고 생각합니다. 새로운 웹 브라우저를 만드는 건 제가 상상할 수 있는 가장 복잡한 소프트웨어 프로젝트 중 하나예요[...] 치트키는 적합성 테스트 스위트(conformance suites)입니다. 기존 테스트가 있다면 훨씬 쉬워질 거예요.
오늘날 AI 코딩 회의론자들의 흔한 불만은 “LLM은 장난감 프로젝트에는 괜찮지만 크고 진지한 일에는 못 쓴다”는 것입니다.
저는 3년 안에 그게 완전히 틀렸음이 광범위하게 입증되어, 더는 논쟁거리조차 되지 않을 거라고 생각합니다.
여기서 웹 브라우저를 예로 든 이유는 브라우저를 만드는 일이 방대하고 위압적인 규모의 공식 테스트와 ‘야생의 웹사이트’라는 비공식 요구사항 모두에 맞춰야 하는 코드 작성이기 때문입니다.
코딩 에이전트는 구체적인 목표를 정의하고 그 방향으로 반복(iteration)하게 하는 작업에 정말 강합니다.
웹 브라우저는 그 역량을 가장 극단적으로 활용하는, 제가 생각할 수 있는 가장 야심찬 프로젝트입니다.
컴퓨터에 코드를 타이핑하는 일로 돈을 받는 직업은 천공카드처럼 사라질 겁니다 [...] 6년 뒤에는 ‘그냥 코드를 타이핑하는 일’만으로 돈을 받는 사람은 없을 거라고 생각합니다. 소프트웨어 엔지니어링은 여전히 엄청난 커리어일 겁니다. 다만 소프트웨어 엔지니어들이 하루에 여러 시간을 텍스트 에디터에서 문법을 타이핑하는 데 쓰지 않을 거라고 생각합니다.
AI 보조 프로그래밍에 더 많은 시간을 쓸수록 제 일자리에 대한 두려움은 줄어듭니다. 소프트웨어를 만드는 일—특히 이제 가능해진 속도로 만드는 일—에는 여전히 엄청난 기술, 경험, 깊은 이해가 필요하다는 걸 알게 되기 때문입니다.
하지만 필요한 기술은 바뀌고 있습니다! 자세한 명세를 읽고 그것을 코드 라인으로 변환하는 일은 자동화되고 있습니다. 남는 건 그 외의 모든 것이고, 코딩 에이전트와 함께 일할수록 그 ‘그 외의 모든 것’이 더 커져만 갑니다.
링크 2026-01-02 2025년 Hacker News에서 가장 인기 있었던 블로그들:
Michael Lynch는 개인 블로그를 Hacker News에서 추적해 그 플랫폼에서 얼마나 성과가 좋은지에 따라 점수를 매기는 사이트인 HN Popularity Contest를 운영합니다.
프로젝트의 엔진은 GitHub에 있는 domain-meta.csv CSV입니다. 작성자, 소개, 태그 메타데이터가 포함된 ‘알려진 개인 블로그’의 수작업 큐레이션 목록으로, Michael은 이를 사용해 개인 블로그 글과 다른 유형의 콘텐츠를 구분합니다.
저는 2023, 2024, 2025년 랭킹에서 1위를 했지만, 전체 기간(all time) 기준으로는 Paul Graham과 Brian Krebs에 이어 3위에 올라 있습니다.
브라우저 인스펙터를 뒤져 보다가, 이 사이트를 구동하는 데이터가 오픈 CORS 헤더로 제공된다는 사실을 발견하고 무척 기뻤습니다. 즉 Datasette Lite 같은 외부 서비스로도 손쉽게 탐색할 수 있다는 뜻입니다.
아래는 특정 도메인에 대해, 데이터셋에 처음 등장한 해부터 매년 그 도메인이 몇 위였는지 보여주는(다소 복잡한) 윈도 함수 쿼리를 Claude Opus 4.5가 저를 위해 작성해 준 것입니다:
sqlwith yearly_scores as ( select domain, strftime(’%Y’, date) as year, sum(score) as total_score, count(distinct date) as days_mentioned from “hn-data” group by domain, strftime(’%Y’, date) ), ranked as ( select domain, year, total_score, days_mentioned, rank() over (partition by year order by total_score desc) as rank from yearly_scores ) select r.year, r.total_score, r.rank, r.days_mentioned from ranked r where r.domain = :domain and r.year >= ( select min(strftime(’%Y’, date)) from “hn-data” where domain = :domain ) order by r.year desc
(방금 보니 마지막 and r.year >= ( 절은 사실 여기서는 필요가 없네요.)
제 simonwillison.net 결과를 보면, 2022년에 3위, 2021년에 30위, 2007년에 85위로 나옵니다. 다만 2007년 개인 블로그 중에는 아직 Michael의 목록에 수작업으로 추가되지 않은 것들이 많이 있을 거라고 예상합니다.
또 유용한 점은, 각 도메인마다 그 도메인에서 실제로 Hacker News에 제출된 항목의 상세 정보를 담은 CORS-enabled CSV 파일이 제공된다는 것입니다. 예: https://hn-popularity.cdn.refactoringenglish.com/domains/simonwillison.net.csv. 이 파일을 Datasette Lite에서 본 링크는 여기입니다.
인용 2026-01-02
제 경험상 진짜 문제에 대한 진짜 AI 도입은 다음의 복잡한 혼합입니다: 문제 영역에 대한 맥락, AI 도구에 대한 도메인 경험, 그리고 구식 IT 이슈들. 저는 내부 AI 도입 이니셔티브 중 이 세 가지 모두에 기반하지 않는 것에 대해서는 매우 회의적입니다. 이 점은 초기 단계 회사의 장점이기도 합니다. 종종 한 사람에게서 세 가지 모두를 찾을 수 있거나, 적어도 두 사람 사이에서 해결되거든요. 대기업에서는 이 일을 위해 서로 다른 세 개의 조직이 함께 움직여야 하고, 이건 객관적으로 어렵습니다.
Will Larson, Imprint에서 AI 도입 촉진하기
링크 2026-01-03 Daft Punk는 Harder, Better, Faster, Stronger의 템포를 정할 때 일부러 웃기려 했던 걸까?:
측정 방법에 따라, Harder, Better, Faster, Stronger의 템포는 1분당 123.45비트(BPM)인 것으로 보입니다.
너무 멋진 사실이라, 그냥 사실이라고 받아들이기로 했습니다.
(오늘 Hacker News 댓글에서 처음 알게 된 건데, Veridis Quo는 “Very Disco(매우 디스코)”라는 뜻이고, 그 단어 순서를 뒤집으면 Discovery가 되는데 그게 앨범 이름입니다.)
인용 2026-01-04
농담이 아니고 웃긴 얘기도 아닙니다. 우리는 작년부터 구글에서 분산 에이전트 오케스트레이터를 만들려고 해왔어요. 여러 옵션이 있고, 모두가 같은 방향으로 정렬돼 있지 않죠... Claude Code에 문제 설명을 줬더니, 작년에 우리가 만들었던 걸 한 시간 만에 생성했습니다. 완벽하진 않고 개선 중이지만, 지금이 바로 그런 상황입니다. 코딩 에이전트에 회의적이라면, 여러분이 이미 전문가인 도메인에서 한번 써보세요. 복잡한 걸 처음부터 만들어 보되, 산출물을 평가할 수 있는 사람은 여러분이 되도록요. […]
프롬프트는 아주 자세하지도 않았고, 제가 기밀 정보를 공유할 수 없어서 실질적인 디테일은 없었습니다. Claude Code를 평가하기 위해 기존 아이디어 일부를 바탕으로 한 장난감 버전을 만들고 있었고, 설명은 세 문단이었어요.
Jaana Dogan, 구글 Principal Engineer
노트 2026-01-04
이 이상한 새로운 LLM 보조 세계에서 제가 좋아하는 점 중 하나는, 관리 역할로 옮기거나 부모가 되면서 개인 프로젝트 시간이 사라져서 코딩을 거의 그만뒀던 사람들이 다시 코딩을 시작하는 경우가 많다는 것입니다.
AI 도움 덕분에, 30분만으로도(혹은 다른 일을 하면서도) 유용한 걸 만들 수 있습니다. 더 이상 ‘몰입을 위해 2~4시간을 따로 떼어’ 확보할 필요가 없죠.
과거에 코딩 경험이 충분히 있었다면—그게 몇 년 묵었더라도—이 도구들을 매우 효과적으로 몰아갈 수 있습니다. 특히 관리 경험이 있다면, 그중 꽤 많은 부분이 코딩 에이전트를 “관리”하는 데 그대로 전이됩니다. 명확히 소통하기, 달성 가능한 목표 설정하기, 관련 맥락 제공하기. 관련해서 Ethan Mollick의 최근 트윗도 있습니다:
사람들이 Claude Code/Codex/등을 어떻게 쓰는지 보면, 에이전트 관리는 사실 관리 문제라는 게 분명해진다
목표를 명시할 수 있는가? 맥락을 제공할 수 있는가? 작업을 쪼갤 수 있는가? 피드백을 줄 수 있는가?
이것들은 가르칠 수 있는 기술이다. 그리고 UI는 관리를 지원해야 한다
이 노트는 댓글로 시작했습니다.
인용 2026-01-04
_사용자가 충분히 많아지면, 관측 가능한 모든 행동은 약속 여부와 상관없이 의존성이 된다. 누군가는 당신의 API를 스크래핑하고, 당신의 특이점을 자동화하고, 당신의 버그를 캐시한다. 이건 커리어 수준의 통찰로 이어진다: 호환성 작업을 ‘유지보수’로, 신규 기능을 ‘진짜 일’로 취급할 수 없다. 호환성은 제품이다.
폐기(deprecation)는 시간, 도구, 공감이 포함된 마이그레이션으로 설계하라. 대부분의 ‘API 설계’는 사실 ‘API 은퇴’다._
Addy Osmani, 구글에서의 14년에서 얻은 21가지 교훈
노트 2026-01-04
11월의 GPT-5.2와 Opus 4.5는 변곡점처럼 느껴집니다. 모델이 조금 더 좋아졌을 뿐인데도, 보이지 않는 능력의 경계선을 넘어서는 순간이 있었고, 갑자기 훨씬 더 어려운 코딩 문제들이 가능해진 그런 순간 말이죠.
링크 2026-01-05 Tahoe 아이콘을 정당화하기는 어렵다:
Nikita Prokopov가 macOS Tahoe의 새로운 메뉴 아이콘을 신랄하게 비판한 글입니다. 그는 1992년 애플 HIG 규칙—“복잡한 아이콘으로 사용자를 과부하시키지 말라”—을 인용하며 시작하고, Tahoe가 정확히 그 일을 하고 있다는 증거를 포괄적으로 제시합니다.
제 생각에 애플은 불가능한 과제를 떠안았습니다. 모든 메뉴 항목에 아이콘을 붙이는 일이요. 그런 걸 할 만큼 좋은 은유가 충분하지 않아요.
하지만 설령 충분하다고 해도, 전제 자체가 의심스럽습니다. 모든 것에 아이콘이 붙는다고 해서 사용자가 원하는 걸 더 빨리 찾게 되는 건 아니거든요.
그리고 설령 전제가 타당하다고 해도, 목표를 고려하면 최선을 다했다고 말하고 싶습니다. 하지만 그렇지도 않아요. 은유를 일관되게 적용하는 데도, 아이콘 자체를 디자인하는 데도 일관되게 못했습니다.
링크 2026-01-06 AI를 위한 샌드박스 필드 가이드:
Luis Cardoso가 작성한, 현재 샌드박싱 환경에 대한 이 가이드는 포괄적이고 밀도 높으며 정말 훌륭합니다.
그는 먼저 컨테이너(호스트 커널 공유), 마이크로VM(하드웨어 가상화 뒤의 게스트 커널), gVisor 사용자 공간 커널, 그리고 런타임 내부로 모든 것을 제한하는 WebAssembly/아이솔레이트(isolates)를 구분합니다.
그 다음 글은 용어, 접근법, 그리고 기존 도구 지형에 대해 깊게 파고듭니다.
신뢰할 수 없는 코드를 안전하게 실행하기 위해 적절한 샌드박스를 사용하는 것은 2026년에 해결해야 할 가장 중요한 문제 중 하나라고 생각합니다. 이 가이드는 매우 귀중한 출발점입니다.
인용 2026-01-07
_AGI는 이미 여기 있다! 정확히 언제 도착했는지는 결코 알 수 없을 것이다. 어느 회사의 Pro였는지, 다른 회사의 Pro Max(에디 바우어 에디션)이 처음으로 선을 넘어 조심스럽게 발을 들였는지… 그건 토론할 수 있겠지만. 하지만 일반성(generality)은 달성됐고, 이제 우리는 새로운 질문으로 나아갈 수 있다. [...] 인공 일반 지능(Artificial General Intelligence)에서 핵심 단어는 General이다. 그 단어가 이 AI를 다른 모든 AI와 구분한다. 다른 모든 AI는 특정 목적을 위해 훈련됐기 때문이다. 수십 년에 걸친 대표적 모델들을 떠올려 보라: Mark I Perceptron, LeNet, AlexNet, AlphaGo, AlphaFold… 이 시스템들은 모두 달랐지만 이 점에서는 같았다.
언어 모델도 목적을 위해 훈련됐다… 하지만 놀랍게도, 그 훈련의 메커니즘과 규모는 새로운 무언가를 만들어냈다. 거대한 행동과 반응의 장으로 이어지는 웜홀을 열어버린 것이다. 시간과 공간을 가로질러 모아온 인간의 방대한 글들, 그 모든 멍청한 이유들… 그건 아주 풍부한 연료다. 머릿속에 전부 담아둘 수만 있다면._
Robin Sloan, AGI is here (and I feel fine)
인용 2026-01-07
_[...] 현실은, 어제 여기서 우리 엔지니어링 팀의 75%가 AI가 우리 비즈니스에 미친 잔혹한 영향 때문에 일자리를 잃었다는 것이다. 그리고 내가 커뮤니티를 위해 이런 재미있는 무료 일을 하느라 쓰는 매 초는, 비즈니스를 되살리고 여기 남아 있는 사람들이 매달 월급을 받을 수 있게 만드는 데 쓰지 못하는 시간이다. [...] 2023년 초에 비해 문서 트래픽이 약 40% 줄었다. Tailwind는 그 어느 때보다 인기가 높지만 말이다. 문서는 사람들이 우리 상업 제품을 알게 되는 유일한 경로다. 고객이 없으면 우리는 프레임워크를 유지할 여력이 없다. [...]
Tailwind는 어느 때보다 빠르게 성장했고 어느 때보다 커졌지만, 우리의 매출은 거의 80% 감소했다. 지금으로서는 Tailwind를 더 쉽게 쓰게 만드는 것과 프레임워크 개발을 지속 가능하게 만드는 것 사이에 상관관계가 전혀 없다._
Adam Wathan, Tailwind Labs CEO
링크 2026-01-08 구글은 어떻게 그루브를 되찾고 OpenAI를 앞질렀나:
Wall Street Journal의 이 글에서, 구글이 Gemini로 최근 어렵게 거둔 성공에 대한 몇 가지 흥미로운 소소한 사실을 얻었습니다.
“나노 바나나(Nano Banana)”라는 이름의 유래는 다음과 같습니다:
밤늦게까지 일하는 것으로 구글 내부에서 알려진 Naina Raisinghani는 업로드를 완료하기 위해 새 도구에 이름이 필요했다. 하지만 새벽 2시 30분이었고, 주변에 아무도 없었다. 그래서 그녀는 친구들이 자신에게 붙여준 두 별명인 Nano와 Banana를 섞어 즉석에서 하나를 만들어냈다.
WSJ는 OpenAI의 Daniel Selsam이 Sergei Brin을 ‘은퇴에서 복귀’하게 만든 공로가 있다고 적었습니다:
그 무렵, 최근 은퇴했던 구글 공동창업자 Sergey Brin은 파티에서 OpenAI 연구원 Daniel Selsam과 대화를 나누고 있었다고, 대화에 익숙한 사람들이 전했다. 왜 전일제로 AI를 하지 않느냐고 Selsam이 물었다. ChatGPT의 출시가 컴퓨터 과학자로서 상상력을 자극하지 않았느냐고.
ChatGPT는 AI 챗봇에서 가정용 이름(household name)이 되어가고 있었지만, 구글은 여전히 제품을 제대로 띄우는 데 허둥대고 있었다. Brin은 Selsam의 말에 일리가 있다고 판단하고 업무로 복귀했다.
그리고 드물게 구체적인 사용자 수치도 나옵니다:
10월까지 Gemini는 월간 사용자 6억 5천만 명 이상을 기록했으며, 7월의 4억 5천만 명에서 증가했다.
LLM 사용량 수치로 제가 가장 자주 보게 되는 건 OpenAI가 10월 6일 DevDay에서 발표한 ChatGPT의 주간 활성 사용자 8억 명입니다. 월간과 주간 활성은 직접 비교가 되진 않지만, 시점은 이 Gemini 수치와 비교 가능합니다.
또 저는 ‘Gemini 사용자’가 무엇을 뜻하는지도 늘 확신이 없습니다. Google Docs나 Gmail을 통해 상호작용하는 것도 포함될까요, 아니면 Gemini 채팅 인터페이스를 직접 써야만 사용자로 집계될까요?
