# Claude Code 창시자, 소프트웨어 엔지니어의 종말을 말하다 [유튜브] > Clean Markdown view of GeekNews topic #30492. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30492](https://news.hada.io/topic?id=30492) - GeekNews Markdown: [https://news.hada.io/topic/30492.md](https://news.hada.io/topic/30492.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-15T09:41:02+09:00 - Updated: 2026-06-15T09:41:02+09:00 - Original source: [youtube.com](https://www.youtube.com/watch?v=PZ9u6DR8qOU) - Points: 7 - Comments: 0 ## Topic Body - **에이전트형 코딩 도구** Claude Code는 코드 작성 자체보다, 제품을 만들고 업무 흐름을 재구성하는데 더 큰 변화를 일으킴 - Microsoft 업무 AI 사용자 조사에서는 빠른 AI 채택 압박, 새 작업물 생성, 더 가치 높은 업무 시간 증가가 함께 나타났지만, **AI 실험 보상**은 낮은 수준에 머묾 - 조직이 단순 사용량을 목표로 삼으면 **토큰 리더보드**와 사용량 부풀리기가 생기며, AI로 가치를 더하는 방식과 연결된 지표가 더 중요함 - Boris Cherny는 엔지니어 직함이 **builder**에 가까운 역할로 바뀔 수 있고, 비엔지니어도 코드를 만들며 엔지니어는 직접 타이핑보다 판단·계획·사용자 이해에 더 집중하게 된다고 봄 - AI 생산성 향상은 노동시간 감소나 일자리 감소로만 이어지지 않으며, 기업은 워크플로를 AI 중심으로 재구성하고 개인은 더 **큰 선택지와 레버리지**를 갖게 됨 --- ### AI 업무 데이터와 조직 지표의 함정 - Microsoft가 **실제 업무에서 AI를 쓰는 사용자 20,000명**을 조사했으며, "전환 역설(transformation paradox)"이라 부르는 현상이 나타남 - **65%** 는 AI를 빠르게 채택하지 않으면 뒤처질까 걱정함 - **58%** 는 1년 전이라면 만들 수 없었을 작업물을 AI 덕분에 만들고 있음 - **66%** 는 AI 덕분에 더 가치 높은 업무에 시간을 쓰게 됐다고 응답함 - 반면 AI 실험에 대해 직장에서 **보상받는다는 응답은 13%** 에 그쳐, 사용 의지와 조직 사이에 간극이 존재 - 별도 Microsoft 연구에서는 관리자가 AI 사용을 직접 보여주면 사용이 **17%** 늘고, 에이전트 신뢰도가 **30%** 상승 - "AI가 미래다"라는 식의 구호보다, 관리자가 **자신이 실제로 쓰는 구체적 방식**을 보여주는 쪽이 결과를 냄 - 직원이 AI로 높인 생산성의 성과를 함께 나눌 수 있다고 믿으면 사용 동기가 달라질 수 있으나, 그렇게 **금전적으로 보상**하는 곳은 거의 없음 - 일부 직장은 토큰 비용을 보조하지만, 그 지원이 늘 좋은 결과로 끝나지는 않음 ### 토큰 맥싱 — 사용량 지표의 부작용 - 주요 기술 기업에서 **토큰 맥싱(token maxing)**, 즉 사용량을 늘리려 토큰을 과도하게 소모하는 현상이 발생 - Amazon 직원들이 Financial Times에 전한 바로는, Amazon이 OpenClaw에서 영감을 받은 내부 도구 **mesh claw**를 도입하고 사용을 장려 - 팀 내 **토큰 사용량 순위표**가 있어, 일부 직원은 생산적이지 않은 에이전트를 의미 없이 돌려 사용량을 끌어올림 - Meta에서는 최대 사용량이 수천억 토큰 규모였고, 수백만 달러 비용에 해당하는 양이 사실상 낭비됨 - Amazon 공식 입장은 토큰 사용량이 관리자 평가 지표가 아니라는 것이지만, 직원들은 관리자가 본다고 여겨 원시 사용량을 늘림 - Amazon에는 개발자 **80%가 매주 AI를 사용**하게 한다는 상부 목표가 존재 - 구체적 보상이 없으면 "AI를 쓰라"는 문구만 지키고 "업무를 더 잘하라"는 본래 취지를 놓침 - 개발자에게는 모호한 추적 방식보다, **가치 창출과 연결된 생산적 지표**가 명확히 필요 ### Claude Code의 탄생과 빠른 확산 - Claude Code는 Anthropic이 전년 5월 출시한 에이전트형 코딩 도구로, **단어를 입력하면 코드를 내놓는 도구** - 출시 **8개월 안에 GitHub에 올라간 전체 코드의 약 4%** 를 담당 - 그해 2월 **연간 매출 실행률 25억 달러**에 도달, 그 수준에 가장 빠르게 도달한 기업용 제품 - 창시자 Boris Cherny는 컴퓨터과학 학위 없이 **경제학을 전공**, 18세에 대학을 중퇴하고 스타트업을 운영했으며 헤지펀드를 거쳐 Meta에서 수석 엔지니어로 5년 근무 후 2024년 말 합류 - 현재 Cherny는 코드를 직접 한 줄도 쓰지 않으면서, **5개 터미널 탭에서 에이전트 5개를 병렬 실행해 하루 20~30개의 풀 리퀘스트를 처리** - 코딩 도구를 만들라는 임무가 아니라 API를 익히려다 **사이드 프로젝트**로 시작 - 초기에는 Claude를 AppleScript에 연결해 자신이 듣던 음악을 보여주는 단순한 형태 - 두 달 안에 Claude Code 버전이 나왔고, **첫날 Anthropic 엔지니어링 팀의 20%** 가 사용 - 2024년 9월 합류해 아주 작은 **labs 팀**에 소속 - 이 팀이 Claude Code, MCP, skills, 데스크톱 앱을 만들었으며, 성공 여부를 알 수 없는 실험적 아이디어가 많았음 - Anthropic은 기업용·코딩·안전성에 집중해 왔고, 제품을 만든다면 **더 나은 코딩 모델과 안전성 연구에 모두 도움이 되는** 코딩 제품이 합리적이라 판단 - 당시 코딩 제품은 대부분 **IDE 확장**이었고, Sonnet 3.5 수준에서는 고급 자동완성에 가까웠음 - 모델은 할 수 있으나 그 능력을 끌어내는 제품이 없는 **모델 오버행(model overhang)** 을 체감, 이 느낌은 지금도 동일 - **별도 UI나 앱 없이 터미널에서 돌아가는** 가장 저렴한 형태로 며칠 만에 제작 - 주변부터 사용자가 퍼져 몇 주 만에 사내 다수가 매일 사용, **출시 5일 안에 엔지니어링 팀 절반이 사용** - 터미널을 꺼리는 엔지니어조차 사용했고, Cherny는 "소프트웨어 엔지니어링이 영원히 바뀌었다"를 분석하기보다 **출시에만 집중** ### 엔지니어는 사라지는가 — 역할의 혼합 - 첫 번째 충격은 **Claude가 듣고 있던 음악을 알려준 순간** - 질문에 Claude가 음악 플레이어를 여는 AppleScript 코드를 작성했고, Cherny는 그 언어를 몰랐으며 그런 식으로 답할 생각도 못 했음 - **엔지니어가 택하지 않았을 방식**으로 문제를 해결 - 모델이 매우 빠르게 발전해, 모델 위에 제품을 만들 때 **매달 재조정**이 필요 - Co-work로 항공편 8개와 호텔 5개를 예약, 유일한 실수는 1박 약 **5,000달러**짜리 호텔이라 예산 초과 → 해당 건만 재예약 - 추세는 **지수 곡선**이라 누구도 정확히 알 수 없으며, 두 가지가 동시에 일어남 - 엔지니어 생산성이 높아져 **같은 일에 더 적은 엔지니어**가 필요한 기업 - 한 명당 생산성이 높아져 더 많은 제품·사업을 벌이며 **더 많은 엔지니어**가 필요한 기업 (Cherny 팀은 좋은 엔지니어 부족에 계속 막혀 최대한 빠르게 채용 중) - 역할이 흥미롭게 **섞이는 중** - 매니저 Fiona는 15년간 코딩하지 않았지만 합류 후 코딩, 프로덕트 매니저 Cat과 디자이너 Megan 등 팀 전원이 코딩 - 비엔지니어는 코드를 조금 더 쓰고, Cherny 같은 엔지니어는 6개월 넘게 코드를 직접 쓰지 않으면서도 하루 종일 무언가를 만듦 - **빌더·엔지니어·프로덕트 매니저** 중 무엇이라 부를지는 불확실하나 역할 자체는 분명히 변화 ### 트랙터 비유 — 기술 확산의 시간 - **트랙터는 1890년대 Iowa에서 John Frick이 발명**했지만, 미국에서 트랙터가 말보다 많아진 것은 1960년대로 **약 70년**이 걸림 - 트랙터는 수확량과 생산성을 크게 높였으나, 사용법을 배우는 **훈련**이 필요했고 초기엔 비싸 말이 더 쌌음 - 성능도 부족해 **밀에는 써도 옥수수에는 못 쓰는** 식이었고, 다양한 작물에 맞추는 데 오랜 시간이 걸림 - 현재 AI 전환은 같은 문제들이 **초고속(speedrun)** 으로 일어나는 상황 - 이는 **평범한 기술(AI as normal technology)** 관점과 연결 — 매우 유능한 모델이 나와도 사람과 조직의 변화는 느림 - 다만 Anthropic의 매출 추이를 보면 이번엔 그 속도가 빠르다는 반론도 존재해, **실제 변화 속도**를 가늠하는 단계 - 컴퓨터는 생산성을 높이지만, 그것이 곧 **노동시간 감소를 뜻하지는 않음** — 같은 시간에 더 많은 일을 하게 됨 ### 코딩은 "해결"되었는가 - "coding is solved"는 **"내가 하는 종류의 코딩"에 한정**된 표현 - Cherny의 작업물인 cloud CLI, 데스크톱 앱, 모바일 앱은 비교적 새롭고 단순한 코드베이스 - 반면 **NASA** 같은 대형 고객의 크고 복잡한 코드베이스에서는 아직 해결되지 않았고, 모델도 완벽하지 않아 실수함 - 엔지니어의 반론(코딩은 타이핑이 아니라 **판단·감각·비판적 사고**이며 에이전트가 약함)은 타당 - Cherny의 예전 하루도 약 **50%만 실제 코드 타이핑**, 나머지는 사용자 대화·브레인스토밍·디버깅·설계·계획 - 모델이 코딩을 맡으면 엔지니어는 사용자와 대화하고 다음을 구상하는 **더 즐거운 일**로 풀려남 - **Claude Code는 6개월 넘게 100% Claude Code로 작성**되었고, Co-work 등 다른 제품도 마찬가지 - 최신 Y Combinator 배치 대담에서 "코드 100%를 Claude Code로 작성"에 수백 명 중 절반이 손을 들었고, "모델로 전혀 작성하지 않는다"에는 단 한 명, 나머지는 50~100% 사이 - **엔지니어링의 변화는 엔지니어링 밖 모든 분야의 선행 지표**라고 봄 - ## 역량 위축 우려와 프로그래밍의 변천 - 직접 코드를 쓰지 않으면 **자기 직업에 대한 이해가 퇴화(atrophy)** 할 수 있다는 우려가 제기됨 - 팀의 엔지니어 **Lena는 즐거움을 위해 주말마다 손으로 C++을 작성**하며, 이런 여지는 늘 존재함 - Cherny는 이를 위축이 아니라 **프로그래밍이 늘 변해 온 흐름**으로 봄 - 소련 시절 천공 카드, 아폴로 프로그램 시기의 종이 위 수작업 계산도 당시엔 "프로그래밍"이었음 - 이후 기계어 → 어셈블리 → JavaScript·Python으로 바뀌었고, 이제는 **에이전트와 대화하는 방식**으로, 곧 **에이전트가 에이전트에게 말해 코딩하는 방식**으로 한 번 더 변화 예상 - 공학용 계산기로 수학 실력이 일부 퇴화해도 계속 계산기를 쓰는 것과 같으며, 다만 그 도구가 초지능이 되어 **은밀히 사용자를 약화시키는 상황**은 다른 문제 - ## 모델 성능 퇴보 논란 - 새 모델 출시 후 "성능이 크게 퇴보했다"는 반발이 주기적으로 나타남 - 실제 버그로 인한 사례가 **2건** 있었고, Anthropic은 원인과 수정 내용을 블로그에 공개 - 그 외 대부분은 **허니문 기간**처럼 모델에 익숙해지며 처음의 경이가 무뎌지는 현상일 가능성 - 1년 전과 달리 지금은 **모델의 코드가 Cherny가 직접 쓸 코드보다 우수** - 과거엔 한 줄씩 세 번 검토해야 했지만, 지금은 Claude에게 맡기고 결과를 다시 점검·테스트하게 하며 동시에 **15개의 Claude를 병렬 실행** ### 생산성 역설과 선택의 확대 - 생산성이 올라도 **노동시간이 줄지 않는** 것은 상당 부분 개인의 선택과 기업의 상황에 달려 있음 - **세탁기 일화**로 설명 - 세탁기 이전에는 한 번 빨래에 5~6시간이 걸리고 약 **3,000ft를 걸어야** 했으며, 불 피우고 물 끓이고 빨래판에 문지르고 짜는 일을 가족 수만큼 매일 반복 - 세탁기는 한 번 빨래 시간을 약 **3시간** 단축 - 이는 **여성의 대규모 노동시장 진입을 가능케 한 요인** 중 하나 - 절약된 시간은 아이와 보내기, 산책, 독서, 친구 만나기, 혹은 공장·사무직 진입 등 **개인의 선택지**를 만들었으며, AI도 동일하게 선택을 넓힘 - CS 학위를 막 마친 22세에 대한 조언: **신입 일자리는 여전히 존재**하지만, 조금이라도 창업 지향이라면 **스타트업 창업**을 권함 - 역사상 창업하기 가장 좋은 **황금기**이며, "당신과 에이전트들"이 거대한 회사를 만들 수 있음 - 실제로 1~3인이 10억 달러 규모 회사와 뛰어난 스타트업을 만드는 중이며, **한 사람의 레버리지가 막대** - 3년 뒤에는 "엔지니어"라 부르지 않을 수 있지만, **코드를 쓰거나 에이전트로 코드를 만드는 사람은 오늘의 100배**가 될 것이라는 전망 ### Claude Co-work — 비엔지니어를 위한 확장 - Co-work는 사람들이 **세금 신고를 하려고 터미널에 Claude Code를 설치**하는 등 코딩 아닌 용도로 쓰는 모습을 보고 시작됨 - 회계·재무·법무는 물론, 항공편 예약, 콘서트 티켓 구매, 워싱턴주 **조개잡이 허가** 구매까지 다양한 비엔지니어링 업무에 사용 - 코딩 제품은 엔지니어가 자신을 위해 만든 것이 남에게도 유용했지만, Co-work는 **비엔지니어 전반을 위해 만드는** 새로운 도전 - 장시간 실행 능력이 핵심 방향 - 약 1년 반 전 Claude Code는 모델 한계로 **30초만 지나도 경로를 벗어나** 개입이 필요했음 - 지금은 매일 밤 수백~수천 개의 에이전트가 **5·10·20시간**씩 실행되며, 이것이 현재의 엔지니어링 방식 - Co-work도 같은 방향으로 가겠지만, 어떤 업무에 그토록 긴 실행이 필요한지는 아직 불명확 - 메모리와 사용자 이해가 좋아지면 **필요를 미리 예측**하는 방향으로 발전 - 예: 남은 팟캐스트 회차와 미섭외 게스트를 파악해 후보를 브레인스토밍하고, 초기 연락 이메일을 **임시보관함**에 넣어 두는 식 - 업무 정의는 "디자인 전체" 같은 **수평적** 방식과, 특정 목표를 끝까지 수행하는 **수직적** 방식으로 나뉠 수 있음 - 수직 예시: Claude가 기능을 만들고 테스트·병합·출시까지 진행 - **Opus 4.7부터 Claude가 더 능동적**으로 변함 - 기능 출시 뒤 **12시간 후 사용자 피드백을 확인하도록 스스로 알림을 예약**하고 버그가 있으면 고치려 함 — 사람이 잊기 쉬운 일을 미리 처리해 만족도가 높았음 - **Claude Mythos**는 대부분에게 외부 공개되지 않았고, 공개된 정보는 주로 **코딩과 사이버보안 성능** — 평소 도약보다 큰 점프이며 사이버·코딩에 특히 강함 ### 일자리 대체의 책임은 누구에게 - 이 전환은 **좋은 효과와 나쁜 효과가 섞이며**, 정확한 시점과 비율은 예측 불가 - Anthropic은 소프트웨어 엔지니어 등의 실업 원천이 될 수 있는 **독특한 위치** - 엔지니어로서 **다가올 변화를 알리고 도구 사용을 교육해 함께 데려가야 한다는 강한 의무감**을 팀과 자주 논의 - 이는 **한 회사가 풀 수 있는 문제가 아니며**, 한 회사가 푸는 것도 바람직하지 않음 (잘못된 해법이 될 수 있음) - 사회 전체가 논의·토론해야 할 문제이며, Anthropic은 **경제 보고서와 정책 논의, 관찰한 내용 공개**로 기여 - Anthropic이 안전성 연구소이면서도 제품을 만드는 이유 중 하나는, **사람들이 직접 경험해 이해하고 사회적 대응에 참여**하게 하기 위함 — 기술을 잠가 두면 누구도 관점을 형성하기 어려움 ### 파워 유저와 AI 격차 - **디지털 격차가 AI 격차로** 바뀔 우려가 있으며, 지금까지 데이터는 AI를 가장 잘 활용하는 사람이 **이미 소득 상위층**에 가깝다는 점을 보여줌 - Anthropic에는 접근성을 넓히는 몇몇 프로그램이 있으나 구체적 이름·방식은 제시되지 않음 - 가장 큰 가치를 얻는 사용자는 **예상과 다른 경우**가 많음 - Opus 4.7 출시 해커톤 우승자는 대체로 전문 엔지니어가 아니라 **전기기사·의사·목수**가 앱을 만든 사례였고, 직전 4.6 해커톤에서도 동일한 경향 - 모델이 충분히 정교해져 **비전문가도 잘 다루는** 단계 - 대기업 도입의 핵심은 **업무 프로세스를 바꿔 Claude를 중심에 두는 것** - 잘 작동하는 방식 하나는 **모두에게 토큰을 주고 안전하게 실험**하게 해, 예상치 못한 사람에게서 아이디어가 나오게 하는 것 - 최고의 아이디어는 선임 엔지니어가 아니라 **구석의 회계 담당자나 GTM 담당자**가 만든 내부 대시보드에서 나올 수 있음 - 오늘 도구를 가장 잘 쓰는 사람이 내일도 그렇다는 보장이 없으므로 **모두가 도구 사용을 배우는 것**이 중요 ### 향후 1년 전망 - 내년에는 **많은 혼란**이 있고, 큰 플레이어들이 적응을 시도해 다수가 성공할 것 - 일부 **전통적 비즈니스 해자**는 약해지고 일부는 유지됨 - **네트워크 효과**(사용자가 많을수록 가치 상승)는 AI와 무관하게 유지 - **규모의 경제**(한계비용 하락)도 자연적 이점이라 사라지지 않음 - 반면 **전환 비용**은 약화 — Claude가 vendor A에서 B로 옮겨 줄 수 있다면 더 이상 큰 해자가 아님 - 사라지는 해자에 의존한 기업은 어려워지고, 다수는 새 해자를 모색 - 예상보다 **훨씬 큰 혁신**이 일어날 것 - 새로운 아이디어는 대기업이 아니라 **1·2·10명 규모의 작은 스타트업**에서 쏟아지고, 그 수가 폭발적으로 증가 - **소재 발견** 스타트업 사례: 석기·철기시대를 지나 실리콘 시대에 이르렀다는 서사로, 새 소재를 찾으면 다음 시대로 진입한다고 보고 Claude로 가능한 분자·설계를 탐색 - 과거엔 자금 마련조차 어려웠던 일을 **소수 팀이 20년 전엔 불가능했던 돌파구**로 만들 수 있음 - 도메인을 잘 아는 사람이 **"Claude 군대"** 를 갖추면 인간 군대를 거느렸을 때보다 훨씬 많은 일을 해냄 - Cherny는 X와 Threads에서의 사용자 응대를 **자동화했지만 직접 하는 것을 선호** - Claude Code의 루프를 루틴으로 옮겨 **30분마다 실행**하며 Threads API·X API로 피드백을 수집 - **사용자와의 직접 상호작용이 가장 좋아하는 일**이며, "작동하지 않는다"는 피드백조차 제품 개선의 원천 - Claude Code는 결함이 많고 이상적 제품과는 거리가 멀지만, **피드백을 듣고 매일 조금씩 개선**하는 것이 좋은 제품을 만드는 유일한 방법 ## Comments _No public comments on this page._