클로드 코드 담당자와의 대화: 프로그래밍은 이미 ‘해결’되었고, 소프트웨어 엔지니어는 결국 빌더(builder)에게 자리를 내줄 것이다
정리 및 번역: TechFlow
게스트: 보리스 체르니(Boris Cherny), 클로드 코드(Claude Code) 책임자
진행자: 레니 라치츠키(Lenny Rachitsky)
팟캐스트 출처: Lenny's Podcast
원제: 클로드 코드 책임자: 코딩이 해결된 후에는 무엇이 일어나는가 | 보리스 체르니
방송일: 2026년 2월 19일
핵심 요약
보리스 체르니는 앤트로픽(Anthropic)의 클로드 코드 프로젝트 창시자이자 책임자다. 단 한 해 만에 그는 터미널 기반의 간단한 프로토타입을, 소프트웨어 엔지니어링의 역할을 바꾸고 전문 분야 전반에 걸쳐 점차 영향을 미치는 도구로 성장시켰다.
이 대담에서는 다음과 같은 주제들이 다뤄졌다:
- 클로드 코드가 단순히 빠르게 개발된 프로토타입에서, 공개 GitHub 커밋의 4%를 차지하는 도구로 성장했으며, 지난 달에는 일일 활성 사용자 수가 두 배로 증가한 과정.
- 클로드 코드 성공 뒤에 숨은 반직관적인 제품 원칙.
- 왜 보리스는 프로그래밍 문제가 이미 “해결됐다”고 보는가.
- 클로드 코드와 코워크(Cowork)를 형성한 잠재적 수요.
- 클로드 코드와 코워크를 최대한 활용하기 위한 실용적 조언.
- 팀 규모를 축소하고 무제한 토큰 사용 권한을 부여함으로써 더 나은 AI 제품을 만들 수 있는 이유.
- 보리스가 왜 앤트로픽을 잠시 떠나 커서(Cursor)에 합류했다가 단 두 주 만에 다시 돌아왔는가.
- 보리스가 신입 팀원들에게 공유하는 세 가지 핵심 원칙.
주요 인사이트 요약
앤트로픽을 떠났다가 다시 돌아온 진실
- "저를 앤트로픽으로 이끈 건 그 사명, 즉 안전성입니다. 앤트로픽에서 아무 사람이나 붙잡고 '왜 여기서 일하십니까?'라고 물어보면, 답은 언제나 '안전성'입니다. 이런 사명 중심의 문화는 저에게 깊은 공명을 불러일으켰습니다. 제가 개인적으로 필요로 하는 것이 바로 이것임을 알고 있었고, 그것이 없으면 저는 결코 행복하다고 느낄 수 없습니다."
왜 클로드 코드의 성장이 이렇게 빠른가?
- "앤트로픽에서는 '지수적 사고'가 DNA에 각인되어 있습니다—우리 공동 창립자들은 '스케일링 법칙(scaling laws)' 논문의 상위 3명 저자인데, 우리는 정말로 지수적 관점에서 문제를 바라봅니다. 만약 당신이 당시 클로드 코드가 작성한 코드 비율의 지수 곡선을 그려보고, 그 선을 따라 연장해 본다면, 말도 안 되게도 우리가 연말에 100%를 넘어서리라는 게 명백합니다."
- "혁신은 로드맵이 없습니다. 강제로 일어나게 할 수 없습니다. 사람에게 공간, 혹은 말하자면 '안전감'을 줘야 합니다—실패해도 괜찮다는 심리적 안정감, 아이디어의 80%가 실패해도 괜찮다는 여유가 필요합니다."
다음 프론티어는 무엇인가? 프로그래밍은 이미 해결됨
- "프로그래밍은 기본적으로 이미 해결됐습니다—적어도 제가 하는 종류의 프로그래밍은 말입니다. 왜냐하면 클로드가 그것을 해낼 수 있기 때문입니다. 작년 11월 이후로 저는 한 줄의 코드도 수동으로 수정하지 않았습니다. 매일 10개, 20개, 30개의 PR을 제출하는데, 모두 클로드 코드가 작성합니다."
이전 학습(transfer learning)이 가져온 예상치 못한 혜택
- "이 이전 학습 현상은 매우 흥미롭습니다—모델에게 어떤 작업 X를 가르칠 때, 다른 작업 Y에서도 성능이 향상되는 것입니다. 예를 들어, 우리가 쿼드 코드(Quad Code) 기술을 도입한 이후, 우리 엔지니어링 팀 규모는 약 4배 증가했지만, 더 놀라운 사실은 각 엔지니어의 생산성이 200% 향상됐다는 점입니다."
팀 원칙 1: 고의적으로 ‘자원 부족’(Underfund) 상태 유지
- "프로젝트가 고의적으로 '자원 부족' 상태일 때, 사람들은 클로드를 사용할 수밖에 없습니다. 엔지니어 한 명을 단독으로 프로젝트에 배치하면, 그가 빠르게 결과물을 내놓는 데는 스스로 일을 잘 해내고 싶다는 내재적 동기가 작용합니다. 그런데 클로드가 있다면, 이를 통해 업무의 상당 부분을 자동화할 수 있습니다."
팀 원칙 2: 엔지니어에게 무제한 토큰 제공
- "처음부터 최적화하거나 비용을 삭감하려 하지 마세요. 일단 엔지니어에게 가능한 한 많은 토큰을 제공하세요. 입사 후 무제한 토큰을 사용할 수 있도록 하는 것은 제가 매우 지지하는 방식입니다. 이는 사람들이 미친 듯한 아이디어를 자유롭게 시도할 수 있게 해주기 때문입니다. 가장 흥미로운 혁신 아이디어는 바로 이런 마음껏 실험하는 과정에서 탄생합니다."
인쇄기 비유: 재미있는 부분이 바뀌었다
- "가장 적절한 비유는 인쇄기입니다. 저는 더 이상 까다로운 작업—Git 조작, 다양한 도구 사용—을 하지 않아도 됩니다. 그런 건 결코 재미있는 부분이 아니었죠. 재미있는 건, 무엇을 구축할지 명확히 생각해내는 것, 사용자와 대화하는 것, 거대한 시스템과 미래를 고민하는 것, 팀과 협업하는 것입니다. 이제 저는 그런 일들에 더 많은 시간을 쓸 수 있습니다."
다음에 어떤 직업이 바뀔 것인가? 에이전트가 컴퓨터 속으로 들어간다
- "저는 공학과 인접한 여러 직업—제품 매니저, 디자이너, 데이터 과학자—이 먼저 영향을 받을 것으로 봅니다. 결국 거의 모든 컴퓨터에서 수행 가능한 작업으로 확장될 것입니다. 에이전트의 진정한 의미란, 도구를 사용할 수 있는 LLM을 말합니다—그것은 단순히 말만 하는 것이 아니라, 실제로 행동하고, 여러분의 시스템과 상호작용할 수 있습니다."
직업 경로의 재편성: '빌더(Builder)'가 엔지니어를 대체한다
- "연말까지 이러한 경계는 점점 더 모호해질 것이며, 일부 지역에서는 '소프트웨어 엔지니어'라는 직책 이름이 '빌더'로 대체되거나, 모두가 제품 매니저가 되면서 동시에 모두가 코드를 작성하게 될 것입니다. 가장 높은 보상을 얻는 사람들은 호기심 많고, 광범위한 지식을 갖추며, 여러 학문 분야를 아우르는 사람들일 것입니다."
현대판 '잠재적 수요(potential demand)' 프레임워크
- "전통적인 잠재적 수요 프레임워크는 사용자가 무엇을 하고 있는지를 관찰하는 데 초점을 맞춥니다. 그러나 제가 보는 현대적 프레임워크는 조금 다릅니다: 모델이 무엇을 하려고 하는지를 관찰하고, 그것을 더 쉽게 만들어주는 것입니다. 제품 자체가 바로 모델이며, 우리는 그것을 최대한 노출시키고, 최소한의 프레임워크로 감싸서, 모델이 스스로 어떤 도구를, 어떤 순서로 실행할지 결정하도록 하려 합니다."
AI로 10일 만에 코워크(Cowork) 구축하기
- "코워크는 '잠재적 수요'에서 탄생했습니다—우리는 사람들이 클로드 코드를 기술적이지 않은 일에 사용하는 것을 목격했습니다. 결국 우리는 10일이라는 짧은 기간 동안, 전부 클로드 코드를 활용해 코워크를 구축했습니다. 코워크에는 매우 정교한 보안 시스템이 포함되어 있으며, 이 모든 코드는 클로드 코드가 작성했습니다."
앤트로픽의 3단계 AI 보안 체계
- "첫 번째 단계는 정렬(alignment)과 기계적 해석 가능성(mechanical interpretability)입니다; 두 번째 단계는 평가(Eval, 실험실 환경)입니다; 세 번째 단계는 모델이 실제 세계에서 어떻게 행동하는지를 관찰하는 것입니다. 우리는 우리가 준비됐다고 생각하기보다 훨씬 이른 시점에 출시해야 합니다. 그래야 피드백을 얻을 수 있고, 출시 후에도 정렬 및 보안에 대한 많은 것을 배울 수 있습니다."
'에이전트 정체 불안(Agent stalling anxiety)'에 대해
- "저는 아침에 눈을 뜨면, 첫 번째로 아이폰의 클로드 iOS 앱을 열어 어젯밤 에이전트의 진행 상황을 확인합니다. 어느 정도 불안감이 있긴 합니다—어떤 에이전트가 멈춰 버렸고, 그래서 제가 많은 생산성을 잃었다는 느낌이 듭니다. 저는 정말로 iOS로 '코드를 작성'하게 될 줄 몰랐습니다."
AI 제품 구축의 핵심 원칙
- "모델이 당신을 위해 무엇을 할 수 있는지를 묻지 마세요. 대신, 모델이 스스로 할 수 있도록 어떤 도구를 제공할지 생각해보세요. 과도하게 통제하지 말고, 모델을 상자 안에 가두지 마세요. 오늘의 모델이 아니라, 6개월 후의 모델을 위해 항상 구축하세요. 그 모델이 등장할 때, 당신의 제품은 일거에 날아오를 것입니다."
전문 사용자를 위한 팁: 계획 모드(Plan Mode)
- "저는 약 80%의 작업을 시작할 때 계획 모드를 사용합니다. 이는 아주 간단합니다—프롬프트에 '먼저 코드를 작성하지 마세요'라는 한 문장을 삽입하는 것뿐입니다. 계획이 괜찮아 보이면, 그때 모델에게 실행을 지시합니다. 가장 강력한 모델(Opus 4.6)을 사용하면, 오히려 더 저렴해지는 경우가 많습니다."
보리스가 왜 앤트로픽을 잠시 떠나 커서로 갔는가(그리고 왜 돌아왔는가)
진행자 레니: 약 6개월 전, 당신은 앤트로픽을 떠나 커서에 합류했지만, 2주 만에 다시 돌아왔습니다. 무슨 일이 있었습니까?
보리스 체르니:
이것은 제가 경험한 가장 빠른 직장 이동이었습니다. 저는 커서의 열렬한 팬이었기 때문에 커서에 합류했고, 팀을 만나보니 그들의 능력에 감탄했습니다—정말 훌륭한 팀이었고, 멋진 일을 하고 있었으며, AI 기반 프로그래밍의 향방을 다른 사람들보다 훨씬 일찍 인식한 팀이었습니다. 따라서 멋진 제품을 구축하는 일 자체가 저에게 매우 매력적이었습니다. 하지만 막 도착하자마자, 제가 진짜로 그리워했던 건 앤트로픽의 사명이라는 사실을 깨달았습니다. 이것이 제가 앤트로픽에 합류한 원인이기도 했습니다—제가 앤트로픽에 들어가기 전에는 대형 기술 기업에서 일했지만, 저는 실험실에서 이 미친 세상의 미래를 어느 정도 함께 형성하고 싶었습니다.
저를 앤트로픽으로 이끈 건 그 사명, 즉 안전성입니다.앤트로픽에서 아무 사람이나 붙잡고 '왜 여기서 일하십니까?'라고 물어보면, 답은 언제나 '안전성'입니다. 이런 사명 중심의 문화는 저에게 깊은 공명을 불러일으켰습니다. 제가 개인적으로 필요로 하는 것이 바로 이것임을 알고 있었고, 그것이 없으면 저는 결코 행복하다고 느낄 수 없습니다. 어떤 일이든 흥미진진할 수 있지만, 멋진 제품을 만드는 것조차 사명감을 대체할 수 없습니다. 이 깨달음은 매우 빠르고 명확하게 찾아왔습니다.
클로드 코드 1주년
진행자 레니: 이제 앤트로픽으로 돌아가서 당신이 거기서 해낸 일에 대해 이야기해 보겠습니다. 이번 팟캐스트가 공개될 무렵은 클로드 코드 출시 1주년이 거의 되는 시점입니다. 아마 보셨을 세미애널리시스(SemiAnalysis) 보고서에 따르면, GitHub에서 4%의 공개 커밋이 클로드 코드로 작성되었고, 연말까지 이 비율이 5분의 1에 달할 것이라고 예측했습니다. 바로 이 팟캐스트 녹음 당일, 스포티파이(Spotify)는 12월 이후로 자사 최고의 엔지니어들이 한 줄의 코드도 직접 쓰지 않고 전부 AI에 의존하고 있다고 발표했습니다. 당신은 이 1년간의 영향력에 대해 어떤 성찰을 하십니까?
보리스 체르니:
이 숫자들은 정말 미친 수준입니다. 제 예상보다 훨씬 많았고, 게다가 이건 공개 저장소의 커밋 기록일 뿐이며, 사설 저장소까지 포함하면 훨씬 더 높아질 것입니다. 그러나 저에게 가장 미친 건 현재의 숫자가 아니라, 우리의 성장 속도입니다—어떤 측면에서 보더라도,클로드 코드의 성장 속도는 계속해서 가속화되고 있습니다. 단순히 상승하는 게 아니라, 점점 더 빠르게 상승하고 있습니다. 클로드 코드를 시작할 때는 그냥 작은 해킹이었습니다. 앤트로픽은 프로그래밍 제품을 만들고 싶다는 대략적인 방향을 알고 있었고, 회사가 오랫동안 모델을 구축해 온 방식에도 일관된 궤적이 있었습니다:먼저 모델을 프로그래밍 분야에서 매우 강하게 만들고, 다음으로 도구 사용 분야에서 매우 강하게 만들며, 마지막으로 컴퓨터 사용 분야에서 강하게 만듭니다—이는 안전을 고려한 선택입니다. 왜냐하면 AI의 능력이 점점 더 강해짐에 따라, 책임감 있게 발전시켜야 하기 때문입니다.
클로드 코드의 기원 이야기
보리스 체르니:
앤트로픽에 합류한 후, 저는 한 달 동안 여러 가지 이상한 프로토타입을 만들었고, 대부분은 공개되지 않았습니다. 또 한 달은 포스트 트레이닝(post-training)에 투자하며 연구 측면을 이해하려 노력했습니다. 제대로 된 일을 하려면, 자신이 작업하는 레이어 바로 아래의 레이어를 이해해야 한다고 생각합니다.AI 분야에서는 어느 정도 모델을 이해해야만 좋은 제품을 만들 수 있습니다.
클로드 코드의 첫 번째 버전은 클로드CLI(ClaudeCLI)였고, 당시에는 몇 가지 도구를 어떻게 사용하는지를 보여주었습니다—그중 가장 충격적이었던 순간은, 제가 bash 도구를 주었더니, 모델이 스스로 '지금 내가 듣고 있는 음악이 무엇인지'라는 질문에 이 도구를 사용해 답변을 찾았다는 점이었습니다. 이것은 정말 놀라운 일이었는데, 제가 모델에게 '이 도구로 이 일을 해라'고 전혀 지시하지 않았기 때문입니다. 모델이 스스로 추론해낸 것이었습니다. 저는 이걸 내부에 공유했더니, 반응은 단지 두 개의 좋아요뿐이었습니다. 왜냐하면 사람들은 프로그래밍 도구라고 하면 IDE를 떠올리기 때문에, 터미널에서 실행되는 이 도구는 아무도 중요하게 여기지 않았던 겁니다. 터미널 디자인은 좀 이상해 보이고, 정말 이례적이었습니다. 그러나 제가 처음 터미널을 선택한 이유는, 초기 몇 달 동안 제가 혼자였기 때문에, 터미널이 가장 쉽게 구축할 수 있는 방식이었기 때문입니다.
이것은 중요한 제품 교훈입니다—초기에는 자원을 약간 줄이는 게 좋습니다. 이후 우리는 다른 형태로 전환할지 고민했지만, 결국 터미널을 고수하기로 결정한 가장 큰 이유는 모델이 너무 빠르게 개선되고 있어서, 다른 어떤 형태도 그 속도를 따라잡지 못할 것 같았기 때문입니다. 저는 밤늦게까지 이 문제를 고민했습니다:모델은 계속 진화하고 있는데, 우리는 어떻게 해야 할까요? 터미널은 제가 당시 유일하게 떠올린 해답이었고, 결과적으로 출시 후 금방 인기를 끌었습니다. 앤트로픽 내부에서는 폭발적인 인기를 끌었고, 일일 활성 사용자 수는 거의 수직으로 치솟았습니다.
2월에 외부에 공개했을 때는 바로 성공하지는 못했습니다. 몇 달이 지난 후에야 대부분의 사람들이 이 도구가 무엇인지 진정으로 이해하게 되었습니다. 이건 너무 특별해서, 클로드 코드가 성공한 이유 중 하나는 바로 '잠재적 수요' 개념 때문이었습니다—우리는 사람들이 이미 있는 곳에 도구를 가져다 놓고, 기존 워크플로를 약간 더 쉽게 만들었습니다. 물론 터미널이라는 점에서 낯설긴 했고, 사용법을 배우려면 열린 마음이 필요했습니다. 지금은 클로드 코드가 iOS 및 안드로이드 앱, 데스크톱 앱, 웹버전, IDE 플러그인, 슬랙 통합, 깃허브 통합 등 다양한 형태로 제공됩니다—엔지니어가 어디에 있든, 클로드 코드는 그곳에 있습니다. 그리고 이제는 훨씬 더 익숙하고 친근해졌습니다.처음에 이 도구가 실제로 쓸모가 있다는 사실 자체가 이미 놀라웠습니다. 팀이 성장하고 제품이 진화하면서, 작은 스타트업에서 최대 규모의 기술 기업에 이르기까지 전 세계 사용자들이 이 도구를 사용하고 피드백을 주고 있습니다.이 1년을 돌아보면, 우리는 끊임없이 사용자로부터 배우고 있었습니다. 누구도 진정으로 자신이 무엇을 하고 있는지 알지 못했고, 우리는 모두 함께 모색해 왔습니다.
AI가 소프트웨어 개발을 얼마나 빠르게 변화시키고 있는가
진행자 레니: 당신은 1년 전에 이 제품을 출시했습니다. AI로 코드를 작성하게 하는 첫 번째 도구는 아니었지만, 1년 만에 전체 소프트웨어 엔지니어링 산업은 극적으로 변화했습니다. 처음에는 모두가 'AI가 100% 코드를 작성할 수 있을까? 불가능하지 않을까?'라고 말했고, 지금은 '물론이죠, 이미 그렇게 되고 있어요.'라고 말합니다. 세상이 너무 빨리 변하고 있습니다.
보리스 체르니:
2025년 5월, '클로드와 함께 코딩하기(Code with Claude)' 컨퍼런스에서 저는 짧은 연설을 했고, Q&A 시간에 누군가 연말에 대한 제 전망을 물어보았습니다. 저는 이렇게 말했습니다:연말이 되면, 아마도 코드를 작성하기 위해 IDE가 필요하지 않을지도 모릅니다. 이미 일부 엔지니어는 IDE를 사용하지 않고 있습니다. 제가 이 말을 하자마자, 청중 사이에서 탄식 소리가 들렸습니다. 당시 이 예측은 너무 미친 것처럼 들렸지만, 앤트로픽에서는 '지수적 사고'가 DNA에 각인되어 있습니다—우리 공동 창립자들은 '스케일링 법칙' 논문의 상위 3명 저자인데, 우리는 정말로 지수적 관점에서 문제를 바라봅니다. 만약 당신이 당시 클로드 코드가 작성한 코드 비율의 지수 곡선을 그려보고, 그 선을 따라 연장해 본다면, 말도 안 되게도 우리가 연말에 100%를 넘어서리라는 게 명백합니다. 저는 실제로 그렇게 해봤고, 제 개인적으로는 작년 11월에 그 시점이 도래했으며, 그 이후로는 계속 그렇게 되고 있습니다. 지금은 많은 고객들 사이에서도 같은 현상을 보고 있습니다.
AI 혁신에서 실험 정신의 중요성
진행자 레니: 당신이 공유한 이 여정은 정말 흥미롭습니다—어떤 목적 없이 자유롭게 놀아보며, 어떤 일이 벌어질지 지켜보는 느낌이죠. 이는 AI 분야에서 가장 큰 혁신의 핵심 요소처럼 보입니다. 누군가 다른 사람보다 훨씬 더 멀리 모델을 몰고 가려고 끊임없이 노력하고 있는 것이죠.
보리스 체르니:
혁신에 관해 확실한 한 가지는 있습니다:그것은 로드맵이 없습니다. 강제로 일어나게 할 수 없습니다. 사람에게 공간, 혹은 말하자면 '안전감'을 줘야 합니다—실패해도 괜찮다는 심리적 안정감, 아이디어의 80%가 실패해도 괜찮다는 여유가 필요합니다. 동시에 어느 정도의 책임감도 필요합니다: 아이디어가 별로라면, 손해를 인정하고 다음으로 넘어가야지, 더 깊이 빠져들지 않아야 합니다. 클로드 코드 초기에는 이 도구가 실제로 쓸모가 있을지 전혀 몰랐습니다. 2월 외부 출시 당시에도, 제가 작성한 코드의 약 20%만 클로드 코드가 작성했습니다. 5월에는 약 30%였고, 저는 여전히 대부분의 코드를 커서로 작성하고 있었습니다. 11월이 되어서야 100%를 넘었습니다. 하지만 최초의 그날부터, 뭔가 특별한 것을 발견한 느낌이 있었습니다. 저는 매일 밤, 매 주말마다 이 도구를 연구했고,가끔 어떤 단서를 잡으면, 그것을 끝까지 따라가야만 했습니다.
보리스의 현재 프로그래밍 워크플로(100% AI 완성)
진행자 레니: 그렇다면 지금 당신은 100% 코드를 클로드 코드로 작성하고 있습니까? 이것이 당신의 현재 프로그래밍 상태입니까?
보리스 체르니:
네, 100% 코드를 클로드 코드로 작성합니다. 저는 꽤 생산적인 엔지니어입니다. 인스타그램 시절에도 회사에서 가장 생산적인 엔지니어 중 한 명이었고, 앤트로픽에서도 여전히 그렇습니다. 매일 10개, 20개, 30개의 PR을 제출하며, 모두 클로드 코드가 작성합니다. 작년 11월 이후로 저는 한 줄의 코드도 수동으로 수정하지 않았습니다.
저는 여전히 코드를 살펴봅니다—저희가 완전히 신경 쓰지 않아도 될 단계에 도달했다고는 생각하지 않습니다. 특히 많은 사람이 당신의 프로그램을 사용할 때는, 그것이 올바르고 안전한지 반드시 확인해야 합니다. 앤트로픽에서는 클로드가 자동으로 코드 리뷰를 수행하고 있으며, 100%의 PR이 클로드 리뷰를 거칩니다. 하지만 그 후에는 추가로 인적 검토 단계가 있습니다. 이러한 검사 지점은 의미가 있습니다. 다만, 완전히 프로토타입 수준의 코드—실제로 실행되지 않는 코드—의 경우에는 예외입니다.
다음 프론티어는 무엇인가
진행자 레니: 100% 코드가 AI에 의해 작성된다니, 이건 정말 미친 이정표입니다. 이제는 '물론이죠, 세상이 바로 이렇게 돌아가는 거죠'라는 수준이 되었습니다. 그렇다면 다음 소프트웨어 작성 방식의 주요 전환은 무엇입니까?
보리스 체르니:
지금 일어나고 있는 한 가지는,클로드가 스스로 아이디어를 제안하기 시작했다는 점입니다. 클로드는 피드백, 버그 보고서, 원격 측정 데이터 등을 보고, 수정 사항과 출시할 기능을 제안하기 시작했고, 점점 동료처럼 느껴집니다. 두 번째는,우리가 프로그래밍을 넘어 확장하기 시작했다는 점입니다. 지금 이 순간, 프로그래밍은 기본적으로 해결됐다고 말할 수 있습니다—적어도 제가 하는 종류의 프로그래밍은 말입니다. 왜냐하면 클로드가 그것을 해낼 수 있기 때문입니다.
그래서 지금 우리는 다음은 무엇인가? 프로그래밍 외에는 무엇이 있는가? 를 고민하고 있습니다. 이와 인접한 많은 일들이 있고, 제가 보기에 다음에 도래할 것입니다. 또한 더 일반적인 작업들도 있습니다—저는 지금 매일 코워크를 사용해 프로그래밍과 전혀 관련 없는 일을 처리하고 있습니다. 예를 들어, 얼마 전 저는 코워크로 주차 위반 벌금을 납부했고, 우리 팀 전체의 프로젝트 관리도 전부 코워크가 담당합니다—스프레드시트와 슬랙 간 정보 동기화, 이메일 발송 등입니다. 그래서 저는 다음 프론티어가 바로 여기에 있다고 봅니다. 프로그래밍은 기본적으로 해결됐고,앞으로 몇 달 동안, 우리는 전 산업의 다양한 코드베이스와 기술 스택이 차례로 해결되는 모습을 보게 될 것입니다.
진행자 레니: 클로드가 '다음에 무엇을 해야 할지'를 당신을 위해 생각해준다는 점은 흥미롭습니다. 많은 청취자들이 제품 매니저인데, 아마 지금 땀을 흘리고 계실 겁니다. 당신은 클로드를 어떻게 이 용도로 사용합니까?
보리스 체르니:
가장 간단한 방법은 클로드 코드 또는 코워크를 열고, 슬랙 채널을 가리키는 것입니다. 우리는 클로드 코드 내부 피드백을 전담하는 전용 슬랙 채널을 운영하고 있는데, 이 채널은 내부 출시 초기부터 존재해 왔고, 지금까지 끊임없이 피드백이 유입되고 있습니다. 초기에는 누군가 피드백을 보내면, 저는 즉시 들어가 가능한 한 빨리 모든 문제를 해결했습니다—1분이든, 5분이든, 피드백 반복 주기는 매우 빨랐습니다. 이는 사용자에게 '들어주고 있다'는 느낌을 주었고, 일반적으로 제품을 사용하고 피드백을 주면, 그 피드백은 흑홀로 사라지고 더 이상 주고 싶지 않게 되는 반면, 사람들이 '들어주고 있다'는 느낌을 받으면, 계속해서 기여하고 개선에 도움을 주려 합니다. 지금도 저는 같은 일을 하고 있지만, 클로드가 대부분의 작업을 담당합니다.
진행자 레니: 오푸스 4.6의 성능은 크게 향상됐습니까? 전반적으로 이 모델의 진전은 어떠합니까?
보리스 체르니:
확실히 상당한 향상이 있었습니다. 부분적으로는 프로그래밍에 특화된 훈련 덕분입니다. 코덱스(Codex)는 현재 전 세계에서 가장 강력한 프로그래밍 모델 중 하나이며, 그 성능은 계속해서 향상되고 있습니다. 예를 들어, 4.6 버전의 성능은 매우 뛰어나지만, 단순히 프로그래밍 분야의 훈련만이 향상에 기여한 것은 아닙니다. 사실, 다른 분야에서 수행한 훈련도 프로그래밍 작업으로 효과적으로 이전됩니다. 이 이전 학습(transfer learning) 현상은 매우 흥미롭습니다—모델에게 어떤 작업 X를 가르칠 때, 다른 작업 Y에서도 성능이 향상되는 것입니다. 예를 들어, 우리가 쿼드 코드 기술을 도입한 이후, 우리 엔지니어링 팀 규모는 약 4배 증가했지만, 더 놀라운 사실은 각 엔지니어의 생산성이 200% 향상됐다는 점입니다. 예를 들어, PR 제출 수가 크게 증가했는데, 개발 생산성 연구를 하는 사람이라면, 이 성장률은 믿기 어려울 정도입니다.
저는 메타(Meta)에서 일할 때, 페이스북, 인스타그램, 왓츠앱 등 모든 코드베이스를 포함한 회사 전체의 코드 품질 관리를 담당했습니다. 당시 우리는 엔지니어의 생산성 향상에 매우 주의를 기울였습니다. 왜냐하면 코드 품질 향상은 개발 효율성을 직접적으로 높이기 때문입니다. 그러나 수백 명의 엔지니어가 1년 동안 공동으로 노력해도, 생산성 향상은 보통 몇 퍼센트에 불과했습니다.
빠른 혁신의 대가
진행자 레니: 더 놀라운 건, 이러한 변화가 이미 매우 일상화되었다는 점입니다. 우리가 이런 숫자를 들을 때는, AI가 우리의 작업 방식을 바꾸고 있다는 사실 때문에 당연하게 느낄 수 있지만, 소프트웨어 개발, 제품 구축, 나아가 전체 기술 산업에 대한 이러한 거대한 변화는 전례가 없습니다.
보리스 체르니:
물론, 이런 빠른 변화는 몇 가지 도전 과제도 동반합니다.개인적으로 예를 들어, 모델의 업데이트 속도가 너무 빨라서, 때때로 저는 과거의 사고방식에 갇혀 새로운 변화에 적응하지 못하기도 합니다. 저는 심지어 팀에 새로 합류한 구성원들, 특히 막 졸업한 신입사원들이 종종 보다 일반 인공지능(AGI)에 부합하는 전망적인 사고방식으로 업무를 수행하는 것을 발견했는데, 저는 때때로 오히려 뒤처진 느낌을 받습니다.
예를 들어, 몇 달 전에 메모리 누출 문제가 있었습니다—클로드 코드의 메모리 사용량이 증가하여 결국 크래시가 발생했는데, 이는 흔한 공학적 문제입니다. 전통적인 해결 방식은 힙 스냅샷을 취하고 디버거에 넣은 후 전용 도구로 분석하는 것입니다. 저는 바로 그렇게 했습니다. 그러나 팀의 비교적 신입 엔지니어는 클로드 코드에게 바로 물어보았습니다—"헤이 클로드, 메모리 누출이 있는 것 같아요. 찾아줄 수 있나요?" 클로드 코드는 저와 똑같은 일을 했습니다—힙 스냅샷을 취하고, 분석을 위한 작은 도구를 직접 작성한 것입니다. 즉시 생성된 프로그램이었고, 문제를 찾아 PR을 제출했으며, 제보다 더 빨랐습니다. 따라서 우리처럼 오랫동안 모델을 사용해 온 사람들에게는, 끊임없이 현재로 돌아와야 하며, 오래된 모델의 사고 틀에 머물러서는 안 됩니다—이제는 소넷 3.5가 아닙니다. 새 모델은 완전히 다릅니다. 이런 사고방식의 전환은 매우 다릅니다.
클로드 코드 팀의 작업 원칙
진행자 레니: 저는 당신 팀에 특정한 작업 원칙이 있다고 들었습니다. 그중 하나는 '무엇인가를 직접 하는 것보다 더 나은 방법이 있나요? 클로드에게 맡기세요'라는 원칙인데, 방금 말씀하신 메모리 누출 사례가 바로 이를 잘 보여줍니다—당신은 거의 자신의 원칙을 잊어버리고, 클로드에게 먼저 시도해 보라고 하지 않았습니다.
보리스 체르니:
또 한 가지 흥미로운 원칙은 '고의적으로 자원 부족(underfund) 상태 유지'입니다. 자원이 부족할 때, 사람들은 클로드를 사용할 수밖에 없고, 우리는 이를 지속적으로 관찰하고 있습니다. 우리는 때때로 엔지니어 한 명을 단독으로 프로젝트에 배치하기도 하는데, 그가 빠르게 결과물을 내놓는 데는 스스로 일을 잘 해내고 싶다는 내재적 동기가 작용합니다. 그런데 클로드가 있다면, 이를 통해 업무의 상당 부분을 자동화할 수 있습니다. 따라서 자원 부족은 하나의 원칙입니다.
또 다른 원칙은 사람들이 더 빨리 행동하도록 장려하는 것입니다—오늘 할 수 있는 일은 오늘 하라는 원칙으로, 팀 내에서 매우 강조하고 있습니다. 초기에는 이것이 특히 중요했는데, 제가 혼자였기 때문에, 우리의 유일한 강점은 속도였고, 이것이 치열한 프로그래밍 시장에서 생존할 수 있는 유일한 방식이었습니다. 그러나 지금까지도 이 원칙은 여전히 유효합니다.더 빨라지려면 클로드가 더 많은 일을 하도록 하는 것이 좋은 방법이며, 이 두 원칙은 서로를 강화합니다.
왜 엔지니어에게 무제한 토큰을 주어야 하는가
진행자 레니:'자원 부족'이라는 개념은 흥미롭습니다. 일반적으로는 AI가 더 적은 인력으로 더 많은 일을 할 수 있게 해준다고 생각합니다. 그러나 당신은 AI가 더 빨라지게 해줄 뿐 아니라, 더 적은 인력을 사용하면 오히려 AI 도구로부터 더 많은 이익을 얻을 수 있다고 말합니다.
보리스 체르니:
맞습니다. 우수한 엔지니어를 고용한다면, 그들은 방법을 찾을 것입니다. 이는 제가 CTO들과 다양한 기업들과 대화할 때 자주 언급하는 주제이기도 합니다. 제 조언은 일반적으로 다음과 같습니다:처음부터 최적화하거나 비용을 삭감하려 하지 마세요. 일단 엔지니어에게 가능한 한 많은 토큰을 제공하세요. 지금은 일부 기업이 이를 복리로 제공하고 있습니다—입사 후 무제한 토큰을 사용할 수 있도록 하는데, 저는 이를 매우 지지합니다. 이는 사람들이 미친 듯한 아이디어를 자유롭게 시도할 수 있게 해주기 때문입니다. 일단 아이디어가 통하면, 그때 확장과 최적화를 고민하면 됩니다. 그때는 하이쿠(Haiku)나 소넷(Sonnet)으로 오푸스를 대체할지, 규모를 축소할지 등을 고민하면 됩니다. 하지만 처음에는 토큰을 대량으로 사용해 보고, 아이디어가 통하는지 확인해 보는 것이 중요합니다. 엔지니어에게 이 자유를 주는 것이죠.
진행자 레니: 여기서 듣는 사람들은 '물론이죠, 그는 앤트로픽에서 일하니까 토큰을 많이 쓰라고 말할 거야'라고 생각할 수도 있습니다. 그러나 당신은 가장 흥미로운 혁신 아이디어가 바로 이런 마음껏 실험하는 과정에서 탄생한다고 말합니다.
보리스 체르니:
맞습니다. 현실적으로는 소규모로 실험할 때, 한 명의 엔지니어가 개인적으로 실험하는 경우, 토큰 비용은 그들의 급여나 기타 운영 비용에 비해 여전히 상대적으로 낮습니다. 비용이 진정으로 증가하는 건, 어떤 것이 실제로 잘 작동하고 규모가 커질 때입니다. 그때가 최적화의 적기이지, 너무 이른 시점에 최적화하려 해서는 안 됩니다.
진행자 레니: 토큰 비용이 급여를 넘는 기업을 본 적이 있습니까?
보리스 체르니:
앤트로픽에서는,몇몇 엔지니어가 매달 수십만 달러의 토큰을 소비하는 것을 보고 있습니다. 일부 기업에서도 유사한 사례를 보고 있습니다.
프로그래밍 기술은 미래에도 여전히 중요할까
진행자 레니: 당신은 코드를 작성하는 것을 그리워하십니까? 소프트웨어 엔지니어로서, 이제 그것은 당신의 일이 아니게 되었고, 이 사실이 당신을 슬프게 하지는 않습니까?
보리스 체르니:
제게는 흥미로운데, 제가 프로그래밍을 배운 건 실용적인 목적 때문이었습니다. 저는 자학한 엔지니어인데, 대학에서는 경제학을 전공했고, 컴퓨터 과학은 배우지 않았습니다. 하지만 중학교 때부터 프로그램을 작성하기 시작했고, 처음부터 실용적이었습니다.저는 프로그래밍을 배운 이유가 바로 그것으로 '시험을 치르기 위한 수단'이었기 때문입니다—우리에게 그래픽 계산기가 있었고, 저는 답을 프로그램에 입력했습니다. 다음 해에는 문제가 너무 어려워서 문제를 몰랐고, 그래서 작은 대수 방정식 풀이기를 만들었습니다. 프로그램이 문제를 풀어주었습니다. 그리고 나중에는 작은 케이블로 프로그램을 전반 친구들에게 전송할 수 있다는 사실을 알게 되었고, 전반 친구들이 A를 받았습니다. 그러나 결국 들통났고, 선생님이 우리에게 더 이상 그렇게 하지 말라고 했습니다.처음부터 프로그래밍은 제게 단순히 무언가를 만드는 수단이었지, 목적이 아니었습니다.
그 후 저는 프로그래밍 자체에 매료되기도 했습니다—저는 타입스크립트(TypeScript) 책을 썼고, 당시 전 세계에서 가장 큰 타입스크립트 오프라인 모임을 설립했습니다. 제가 이 언어 자체, 함수형 프로그래밍과 타입 시스템을 사랑했기 때문입니다.그러나 프로그래밍은 제게 근본적으로 도구일 뿐이며, 무언가를 하기 위한 방식입니다. 물론 모두가 그렇게 느끼는 건 아닙니다. 어떤 사람들은 프로그래밍 자체의 과정을 즐깁니다. 사람은 모두 다르고, 이 분야가 변하더라도, 이 예술을 즐기고, 직접 코드를 작성하는 데 여전히 공간이 있습니다.
진행자 레니: 당신은 자신의 엔지니어링 기술이 퇴화될까 걱정하십니까?
보리스 체르니:
개인적으로는 크게 걱정하지 않습니다. 프로그래밍은 계속해서 진화해 왔습니다—펀치카드, 스위치, 하드웨어, 종이와 펜, 그리고 지금은 가상 머신에서 실행되는 소프트웨어에 이르기까지, 우리가 프로그램을 작성하는 방식은 이미 약 60년 동안 이어져 왔습니다. 각각의 전환기마다, 사람들은 '이건 진짜 프로그래밍이 아니다'라고 말했습니다. 그러나 저는 앞으로도 여전히 아래 레이어를 이해하려고 노력할 것입니다. 왜냐하면 그것이 더 나은 엔지니어가 되게 해주기 때문입니다. 그러나 이 상황은 아마도 1년 정도 더 지속될 뿐이고, 그 후에는 정말로 중요하지 않게 될 것입니다. 어셈블리어가 프로그래머에게 그랬던 것처럼 말입니다.
감정적으로는,저는 항상 새로운 것을 배우고 싶어 합니다. 프로그래머로서, 이건 새로운 감각이 아닙니다. 왜냐하면 항상 새로운 프레임워크, 새로운 언어가 있기 때문입니다. 이건 우리가 이 분야에서 익숙한 일입니다. 그러나 동시에, 모든 사람에게 똑같지는 않으며, 어떤 사람에게는 상실감, 향수, 또는 기술 퇴화에 대한 느낌이 있을 수 있습니다.
인쇄기 비유: AI의 영향
진행자 레니: 지금 항상 나오는 질문은 '우리는 여전히 프로그래밍을 배워야 할까?'입니다. 학교 학생들은 여전히 프로그래밍을 배워야 할까요? 당신의 관점에서는, 아마 1~2년 내에 이는 더 이상 필수 기술이 아닐 수도 있습니다.
보리스 체르니:
제 관점에서는, 현재 쿼드 코드(Quad Code)나 스마트 에이전트(agents)를 사용해 프로그래밍하는 사람들은 여전히 기본적인 프로그래밍 논리를 이해해야 합니다. 그러나 1~2년 내에 이 이해는 덜 중요해질 수 있습니다.
저는 최근에 어떤 역사적 사건을 비유로 삼을 수 있을지 계속 생각해 왔습니다. 왜냐하면 우리는 이런 현상을 더 큰 역사적 맥락에 놓고, 우리가 이전에 비슷한 기술 전환을 겪어본 적이 있는지 알아보려고 하기 때문입니다. 제가 떠올린 가장 적절한 비유는인쇄기입니다. 1400년대 중반의 유럽에서는 실질적인 문해율이 매우 낮았습니다—1% 미만의 인구, 즉 귀족과 왕에게 고용된 서기관들만 읽고 쓸 수 있었고, 많은 통치자들조차 문맹이었습니다. 그러다 구텐베르크(Gutenberg)와 인쇄기가 등장했습니다. 흥미로운 통계가 있는데, 인쇄기 발명 후 50년 동안 인쇄된 자료의 양이 이전 1,000년 동안의 총량보다 많았습니다. 인쇄물의 수는 급격히 증가했고, 이후 50년 동안 비용은 약 100배 감소했습니다. 그러나 문해율은 1% 미만에서 전 세계 70%까지 상승하는 데 약 200년이 걸렸습니다. 왜냐하면 읽고 쓰는 법을 배우는 건 어렵고, 교육 체계와 여유 시간이 필요하며, 농장에서 하루 종일 일할 수는 없기 때문입니다.
저는 우리가 비슷한 전환을 목격할 가능성이 있다고 봅니다. 그리고 흥미로운 역사적 기록이 있습니다—누군가 1400년대의 서기관을 방문해 인쇄기에 대한 그의 생각을 물어보았는데, 그들은 오히려 흥분했습니다. 왜냐하면 그들은 이렇게 말했기 때문입니다:제가 싫어하는 건 책에서 책으로 베껴 쓰는 일이지, 책 속의 그림 그리기와 제본 작업은 좋아합니다. 이제 제 시간이 해방되어 기쁩니다. 저는 엔지니어로서 이런 감정에 깊이 공명합니다. 저는 더 이상 까다로운 작업—Git 조작, 다양한 도구 사용—을 하지 않아도 됩니다. 그런 건 결코 재미있는 부분이 아니었습니다.재미있는 건, 무엇을 구축할지 명확히 생각해내는 것, 사용자와 대화하는 것, 거대한 시스템과 미래를 고민하는 것, 팀과 협업하는 것입니다. 이제 저는 그런 일들에 더 많은 시간을 쓸 수 있습니다.
진행자 레니: 그리고 놀라운 건, 당신이 구축한 이 도구가 기술적 배경이 없는 사람도 그런 일을 할 수 있게 한다는 점입니다. 저는 스스로 여러 작은 프로젝트를 했고, 막혔을 때 클로드가 도와줬습니다—이전에는 라이브러리와 종속성에 대해 오랜 시간을 소비했던 고통이 지금은 사라졌습니다.
보리스 체르니:
맞습니다. 오늘 아침에 저는 한 엔지니어와 대화했는데, 그는 Go로 서비스를 작성했고, 한 달 동안 작업해 꽤 잘 작동하고 있었습니다. 제가 그에게 느낌이 어땠는지 물어보니, 그는 "사실 저는 Go를 아직 잘 모릅니다…"라고 말했습니다. 우리는 이런 경우를 점점 더 많이 보게 될 것입니다—그것이 올바르고 효율적으로 작동한다는 것만 안다면, 모든 세부 사항을 알 필요는 없습니다.
AI가 다음에 어떤 직업을 바꿀 것인가
진행자 레니: 당신은 AI가 다음에 가장 빨리 충격을 줄 직업이 어떤 것이라고 생각합니까? 기술 분야 내의 제품 매니저, 디자이너, 또는 기술 분야 외의 직업들일까요?
보리스 체르니:
저는 공학과 인접한 많은 직업—제품 매니저, 디자이너, 데이터 과학자—이 먼저 영향을 받을 것으로 봅니다. 결국 거의 모든 컴퓨터에서 수행 가능한 작업으로 확장될 것입니다. 왜냐하면 모델이 이 분야에서 점점 더 강해질 것이기 때문입니다. 코워크는 이런 작업에 접근하는 첫 번째 방식이지만, 첫 번째일 뿐입니다. 저는 코워크가 이전에 한 번도 사용해 본 적 없는 사람들에게 에이전트 기반 AI를 소개했고, 사람들이 처음으로 그런 느낌을 갖게 했다고 봅니다. 엔지니어링 분야를 1년 전으로 돌이켜 보면, 아무도 에이전트가 무엇인지 제대로 몰랐고, 아무도 실제로 사용해 본 적이 없었습니다. 그러나 지금은 그것이 우리의 작업 방식이 되었습니다.
그리고 제가 기술적이지 않은 일, 또는 반기술적인 일—예를 들어 제품 및 데이터 과학—을 바라볼 때, 사람들은 여전히 대화형 AI를 사용하고 있습니다. 즉, 단순한 챗봇입니다. '에이전트'라는 용어는 무분별하게 남용되어 많은 의미를 잃어버렸지만, 그것에는 매우 명확한 기술적 의미가 있습니다:도구를 사용할 수 있는 LLM입니다—그것은 단순히 말만 하는 것이 아니라, 실제로 행동하고, 당신의 시스템과 상호작용할 수 있습니다. 당신의 구글 독스(Google Docs)를 사용할 수 있고, 이메일을 보낼 수 있고, 컴퓨터에서 명령을 실행할 수 있습니다. 따라서 저는 컴퓨터 도구를 사용하는 모든 작업이 다음 대상이 될 것이라고 봅니다. 이것이 제가 앤트로픽에서 이 일을 하는 것이 중요하고 긴급하다고 느끼는 이유이기도 합니다—우리는 이를 매우 진지하게 받아들이고 있으며, 경제학자, 정책 연구자, 사회적 영향 분야의 전문가들을 포함해 다양한 전문가들이 참여하고 있습니다. 우리는 이 주제에 대해 대량으로 논의하려고 하며, 사회 전체가 함께 어떻게 대응할지 알아내는 데 기여하고 싶습니다. 왜냐하면 이것은 우리만의 결정으로 끝나서는 안 되기 때문입니다.
진행자 레니: '제븐스 역설(Jevons paradox)'이라는 개념이 있습니다—우리가 더 많은 일을 할 수 있게 되면, 우리는 더 많은 사람을 고용하게 되고, 실제로는 그렇게 무서운 일이 아닙니다. AI가 엔지니어링 업무의 중요한 부분이 되는 과정에서, 당신은 어떤 경험을 했습니까? 더 많은 사람을 고용했습니까?
보리스 체르니:
클로드 코드 팀은 현재 인재를 모집 중입니다. 개인적으로는, 이 모든 것이 제 작업을 더욱 즐겁게 만들었습니다. 저는 오늘날만큼 프로그래밍을 즐긴 적이 없습니다. 왜냐하면 저는 더 이상 사소한 세부 사항을 처리할 필요가 없기 때문입니다. 우리는 또한 많은 고객들로부터 유사한 피드백을 듣고 있습니다—그들은 클로드 코드를 사랑합니다. 왜냐하면 그것이 프로그래밍을 다시 즐겁게 만들기 때문입니다. 그러나 이 일이 어디로 향할지는 예측하기 어렵습니다. 저는 여전히 역사적 비유를 찾아야 하고, 인쇄기는 정말 적절한 비유입니다—원래 소수만이 가졌던 능력, 즉 읽고 쓰는 능력이 모두에게 열리게 된 것입니다. 이것은 본질적으로 민주화입니다. 모두가 이 일을 할 수 있게 되었고, 그렇지 않았다면 르네상스는 결코 일어나지 않았을 것입니다. 왜냐하면 르네상스는 크게 지식 전파와 문자 기록에 의존했기 때문입니다—그 당시에는 전화도 없었고, 인터넷도 없었고, 문자는 사람들이 대규모로 조정하는 유일한 방식이었습니다. 저는 몇 년 후에는 모두가 프로그래밍할 수 있고, 누구나 언제든지 소프트웨어를 구축할 수 있는 세상을 상상합니다. 그러면 무엇이 풀릴까요? 저는 전혀 상상할 수 없습니다. 마치 1400년대 사람들이 앞으로 무슨 일이 일어날지 상상하지 못했듯이 말입니다. 그러나 저는 전환기에는 이것이 매우 파괴적일 것이며, 많은 사람들에게 고통스러울 것이라고 확신합니다. 이것은 우리 사회가 함께 논의하고 대응해야 하는 일입니다.
AI 시대에 성공하기 위한 조언
진행자 레니: 이 격동의 시대에 자리를 잡고 싶은 사람들을 위해, 당신은 어떤 조언을 해주겠습니까? AI 도구를 더 많이 사용하고, 최신 기술을 익히는 것입니까? 또 다른 조언이 있습니까?
보리스 체르니:
이것이 아마 첫 번째 조언일 것입니다—도구를 사용해 보고, 그것들을 이해하세요. 두려워하지 말고, 대담하게 탐색하고, 최첨단을 따라가세요. 두 번째 조언은:과거보다 더 열심히 '통합형 인재(Generalist)'가 되는 것입니다. 예를 들어, 학교에서는 많은 CS 전공자들이 코드를 작성하는 법을 배우지만, 다른 분야는 거의 배우지 않습니다. 최대한 시스템 아키텍처 정도만 배우는 수준입니다. 그러나 제가 매일 같이 일하는 가장 효과적인 엔지니어들 중 상당수는 다학문적입니다—클로드 코드 팀에서는 모두가 코드를 작성합니다. 우리 제품 매니저도 코드를 작성하고, 엔지니어링 매니저도 코드를 작성하고, 디자이너도 코드를 작성하고, 재무 담당자도 코드를 작성하고, 데이터 과학자도 코드를 작성합니다. 모두가 코드를 작성합니다. 그리고 많은 엔지니어들은 다양한 분야를 아우릅니다. 가장 뛰어난 사람들은 제품 엔지니어이면서 인프라 엔지니어이기도 하고, 디자인 감각이 뛰어난 제품 엔지니어이기도 하며, 강한 비즈니스 직관을 가진 엔지니어이기도 하고, 사용자와 대화하고 사용자의 요구를 잘 이해하는 엔지니어이기도 합니다. 따라서 저는,다음 몇 년 동안 가장 높은 보상을 얻는 사람들은 단순히 AI 네이티브이고, 이런 도구를 잘 사용하는 사람뿐만 아니라, 호기심 많고, 광범위한 지식을 갖추며, 여러 학문 분야를 아우르고, 해결하려는 문제를 더 거시적인 관점에서 바라보는 사람일 것이라고 봅니다—단순히 엔지니어링에만 집중하는 것이 아니라 말입니다.
진행자 레니: 당신은 엔지니어링, 디자인, 제품 관리라는 세 개의 독립된 학문 분야가 장기적으로 가치를 지닐 것이라고 생각합니까? 지금은 이들이 서로 겹치고 서로의 일을 하고 있습니다.
보리스 체르니:
단기적으로는 계속 존재할 것이지만, 우리는 이 역할들 사이에 약 50%의 중복이 나타나고 있음을 보고 있습니다. 많은 사람들이 실제로 같은 일을 하고 있지만, 각자의 전문 분야가 다릅니다. 예를 들어, 제가 작성하는 코드는 약간 더 많을 수 있고, 우리 제품 매니저는 조정, 계획, 예측, 이해관계자 관리 등에 더 집중할 수 있습니다. 저는 실제로, 연말까지 이러한 경계는 점점 더 모호해질 것이라고 생각합니다. 일부 지역에서는 '소프트웨어 엔지니어'라는 직책 이름이 '빌더'로 대체되거나, 모두가 제품 매니저가 되면서 동시에 모두가 코드를 작성하게 될 것입니다.
조사: AI로 인해 어떤 직업이 더 즐거워졌는가
진행자 레니: 저는 트위터에서 비공식 조사를 했습니다. 엔지니어, 제품 매니저, 디자이너들에게 AI 도구를 채택한 이후, 당신의 업무가 더 즐거워졌는지, 아니면 덜 즐거워졌는지를 물어봤습니다. 엔지니어와 제품 매니저 중 70%가 더 즐거워졌다고 답했고, 약 10%는 덜 즐거워졌다고 답했습니다. 흥미로운 건, 디자이너의 경우 55%만 더 즐거워졌다고 답했고, 20%는 덜 즐거워졌다고 답했습니다.
보리스 체르니:
저는 양쪽 사람 모두와 이야기해 보고 싶습니다. 앤트로픽에서는 우리 디자이너 대부분이 코드를 작성합니다—이것은 우리가 채용할 때 평가하는 항목이며, 비기술적 직책에도 기술 면접을 많이 실시합니다. 우리 디자이너 대부분은 AI가 가져온 변화를 프로그래밍 측면에서 즐기고 있습니다. 왜냐하면 이제 엔지니어에게 도움을 청할 필요 없이 직접 수정할 수 있기 때문입니다. 심지어 이전에는 코드를 작성하지 않던 디자이너들 중 일부는 이제 코드를 작성하기 시작했는데, 이는 그들에게 매우 좋습니다. 왜냐하면 스스로 장애물을 제거할 수 있기 때문입니다. 그러나 저는 더 다양한 경험을 듣고 싶습니다. 왜냐하면 상황이 일률적이지 않다고 믿기 때문입니다.
진행자 레니: 따라서 이 팟캐스트를 듣고 계신 분들 중, 업무가 덜 즐거워졌다고 느끼시는 분은, 어떤 점이 당신을 덜 즐겁게 하는지 알려주시면 감사하겠습니다—왜냐하면 대부분의 사람, 즉 70%의 제품 매니저와 엔지니어는 업무가 더 즐거워졌다고 말하고 있기 때문입니다.
보리스 체르니:
우리는 또한 사람들이 다른 도구를 사용한다는 것을 보고 있습니다—우리 디자이너는 클로드 데스크톱 앱을 더 많이 사용하여 코드를 작성합니다. 즉, 데스크톱 앱을 다운로드하고, 그 안에 있는 코드 탭을 사용합니다. 이 탭은 코워크 탭 옆에 있으며, 실제로는 완전히 동일한 클로드 코드 에이전트를 사용합니다. 그리고 가능한 한 많은 클로드 세션을 동시에 실행할 수 있습니다. 우리는 이를 '멀티-병렬 클로드(Multi-parallel Claude)'라고 부릅니다. 이것은 엔지니어가 아닌 사람들에게 더 자연스러운 방식이라고 저는 생각합니다. 이것은 다시 한 번 '사람들이 이미 있는 곳에 제품을 가져다 놓는다'는 원칙으로 돌아갑니다—사람들이 워크플로를 바꾸도록 하지 않고, 새로운 것을 배우도록 강요하지 않으며, 사람들이 무엇을 하든, 그 일을 약간 더 쉽게 만들어 주면, 제품은 더 나아지고, 사람들은 더 좋아하게 됩니다.
제품 개발에서의 '잠재적 수요(Potential Demand)' 원칙
진행자 레니: '잠재적 수요' 원칙에 대해 설명해 주실 수 있습니까? 코워크 출시 시 이 원칙을 언급하셨는데, 이 개념이 무엇인지, 그리고 잠재적 수요를 해제할 때 무슨 일이 일어나는지 설명해 주실 수 있습니까?
보리스 체르니:
잠재적 수요란 다음과 같은 아이디어입니다:당신이 구축한 제품이, 사람들이 제품이 설계된 방식과는 전혀 다른 방식으로 '남용'하면서, 자신이 하고 싶은 일을 하려고 할 때, 이는 제품 구축자로서 제품이 다음에 어디로 가야 할지를 이해하는 데 도움이 됩니다. 예를 들어, 페이스북 마켓플레이스(Facebook Marketplace)가 있습니다. 당시 팀 리더인 피오나(Fiona)는 자주 이 이야기를 들려주었습니다—페이스북 마켓플레이스의 기원은 페이스북 그룹에서 약 40%의 게시물이 물건을 사고파는 것임을 관찰한 데서 비롯되었습니다. 사람들은 물건을 사고팔기 위해 페이스북 그룹을 '남용'하고 있었고, 아무도 이를 위해 전용 제품을 설계하지 않았지만, 그들은 이 용법을 스스로 고안해냈습니다. 왜냐하면 그것이 정말 유용했기 때문입니다. 따라서 사람들이 물건을 사고팔 수 있도록 전용 제품을 구축한다면, 그들이 그것을 좋아할 것이라는 점은 명백했습니다. 페이스북 마켓플레이스는 그렇게 탄생했고, 페이스북 데이팅(Facebook Dating)도 비슷한 방식입니다—개인 프로필 조회 데이터를 보면, 조회의 60%가 서로 모르는 이성 간에 이루어지는데, 이것은 '잠재적 데이팅 행동'입니다. 그래서 데이팅 제품이 탄생한 것입니다.
이 '잠재적 수요' 개념은 코워크의 탄생에도 작용했습니다. 우리는 지난 6개월 동안, 많은 사람들이 클로드 코드를 기술적인 목적이 아닌 다른 용도로 사용하고 있다는 사실을 관찰했습니다. 어떤 사람들은 그것을 토마토를 기르는 데 사용했고, 어떤 사람들은 자신의 유전체를 분석하는 데 사용했고, 어떤 사람들은 손상된 하드디스크에서 결혼식 사진을 복구하는 데 사용했습니다—이 모든 용도는 완전히 기술적이지 않으며, 사람들이 터미널에서 이런 일을 하려고 애쓰고 있다는 점이 분명합니다. 따라서 우리는 아마도 이들을 위해 전용 제품을 구축해야 할 것이라고 판단했습니다.
저는 어느 날 사무실에 들어갔을 때, 우리 데이터 과학자 브렌단(Brendan)이 터미널에서 클로드 코드를 실행하고 있는 것을 보고 충격을 받았습니다—그는 어떻게 터미널을 열었을까요? 이것은 매우 공학적인 제품인데, 많은 엔지니어조차 터미널을 사용하고 싶어 하지 않습니다. 그는 Node.js를 다운로드하고, 클로드 코드를 다운로드한 후, 터미널에서 SQL 분석을 수행했습니다. 그리고 그 다음 주에는 모든 데이터 과학자들이 그렇게 했습니다.사람들이 제품을 설계된 방식과는 다른 방식으로 사용하여, 자신에게 유용한 일을 하려고 할 때, 이것은 분명히 당신이 전용 제품을 구축해야 한다는 강력한 신호입니다.
저는 지금 또 다른 흥미로운 차원이 있다고 생각합니다. 전통적인 잠재적 수요 프레임워크는 다음과 같습니다: 사용자가 무엇을 하고 있는지를 관찰하고, 그것을 더 쉽게 만들어 주고, 그들에게 능력을 부여합니다. 그러나 제가 지난 6개월 동안 본 현대적 프레임워크는 약간 다릅니다:모델이 무엇을 하려고 하는지를 관찰하고, 그것을 더 쉽게 만들어 주는 것입니다. 우리가 처음 클로드 코드를 구축할 때, 많은 사람들이 LLM을 사용해 무언가를 만들 때, 모델을 상자 안에 가두고 '이것이 내가 구축하려는 애플리케이션이다. 너는 이 컴포넌트만 담당하고, 이 방식으로 API와 상호작용해라'라고 말했습니다. 그러나 클로드 코드는 이 방식을 뒤집었습니다—제품 자체가 바로 모델입니다, 우리는 그것을 최대한 노출시키고, 최소한의 프레임워크로 감싸서, 모델이 스스로 어떤 도구를, 어떤 순서로 실행할지 결정하도록 하려 합니다. 이것은 크게 모델 자체의 '잠재적 수요'에 기반합니다—모델이 무엇을 하려고 하는가? 연구에서는 이를
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
深潮TechFlow
