클로드 코드 창립자가 홍송 대회에서 한 7가지 중요한 판단

저자：AI 제품 아잉

원본 비디오：《Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next》

Claude Code 창립자 Boris Cherny가 홍산 회의에서 한 발표는 정보량이 매우 많았고, 많은 관점을 처음으로 완전히 들었다. 이 친구는 정말 AI에 대한 이해가 꽤 깊다.

내 요약을 공유하겠다.

#01 코드는 더 이상 희소하지 않다

대량의 주류 개발 시나리오에서, 손으로 코드를 작성하는 것은 이미 비효율적인 일이 되어가고 있다.

예전에는 기능을 전달하기 위해 엔지니어가 앉아서 어떻게 구현할지를 먼저 생각한 후, 한 줄 한 줄 코드를 쳐야 했다. 이 과정에서 엔지니어의 가장 큰 가치는: 잘 쓸 수 있는지, 잘 쓰는지, 빠르게 쓸 수 있는지였다.

이제는 작업 방식이 달라졌다.

같은 기능을 위해 엔지니어가 하는 일은 더 이상: 요구 사항을 명확히 하고, 이 일을 몇 개의 조각으로 나누어 Agent에게 맡기고, 수용 기준을 정한 후, Agent가 만들어낸 결과가 맞는지 확인하고, 틀리면 힌트를 조정하여 다시 실행하게 하는 것이다.

AI는 이미 대부분의 코딩 작업을 처리할 수 있다. 물론 100%는 아니며, 여전히 거대하고 복잡한 코드베이스, 비인기 언어 또는 특수 환경이 존재하며, 오늘날의 모델 성능은 여전히 부족하다.

전체적으로 보면, 엔지니어의 가치는 코드 작성 여부에서 작업을 분해할 수 있는지, 목표를 명확히 설명할 수 있는지, 결과를 수용할 수 있는지, Agent를 관리할 수 있는지로 변화하고 있다.

이 변화는 사실 산업 혁명과 매우 유사하다.

산업 혁명 이전에는 한 대장장이가 철을 두드리고, 단조하고, 연마하고, 조립하는 모든 작업을 혼자서 했다. 기술이 뛰어난 대장장이가 자연스럽게 가치가 있었다.

이후 조립 라인이 등장했다. 각 작업자는 한 공정만 담당하지만, 전체 생산량은 수공예 시대보다 수십 배, 수백 배 더 높아졌다.

이때 공장에서 가치 있는 역할은 특정 공정을 가장 잘 수행하는 장인이 아니라, 조립 라인을 잘 설계하고 관리하여 원활하게 운영할 수 있는 사람이다.

작업자는 사라지지 않았지만, 작업자의 역할은 변했다.

소프트웨어 공학은 지금 유사한 전환을 겪고 있다. 코드 자체는 더 이상 희소 자원이 아니다. 코드를 작성하는 것은 PPT를 사용하는 것과 같은 기본 기술로 변하고 있다.

진정으로 희소한 것은 모호한 요구 사항을 명확한 작업으로 분해할 수 있는 능력, Agent가 제시한 여러 가지 옵션 중에서 가장 적합한 것을 선택할 수 있는 능력, 여러 AI가 협력하여 일을 완수할 수 있는 능력이다.

사실 이 점은 많은 오래된 엔지니어들이 처음에는 받아들이기 힘들었다. 직접 코드를 작성하는 것은 과거 수십 년 동안 많은 사람들이 이 직업을 사랑한 이유였다.

이것을 기계에 맡기는 것은 많은 사람들에게 단순히 작업 방식이 변한 것이 아니라, 정체성의 재구성이다.

하지만 추세는 추세다.

#02 구텐베르크 인쇄기처럼

코딩은 전문 기술에서 기본 능력으로 변하고 있다. 이 점은 15세기 유럽의 인쇄술과 유사하다.

인쇄술이 발명되기 전, 유럽 전체에서 약 10%의 사람만이 읽고 쓸 수 있었다. 이들은 종종 글을 읽고 쓰는 일을 전문으로 하는 비문해 귀족에게 고용되었다.

그 후 인쇄술이 등장했다. 50년 만에 유럽에서 출판된 책의 수는 이전 천 년의 총합을 초과했고, 책 가격은 약 100배 하락했다. 수백 년의 교육 시스템과 경제 구조가 따라오면서, 전 세계 문해율은 오늘날 70%에 이르렀다.

Boris는 AI가 소프트웨어에 미치는 영향이 가속화된 인쇄술 혁명이라고 생각한다. 소프트웨어는 수십 년 내에 완전히 민주화되어 누구나 다룰 수 있는 것이 될 것이다.

결국 소프트웨어를 다루는 것은 문자 메시지를 보내는 것처럼 자연스러워질 것이다.

#03 가장 중요한 능력은 무엇인가?

코드를 작성하는 일의 문턱이 AI에 의해 극도로 낮아진 후, 진정으로 사람의 능력을 구분하는 것은 그의 제품 감각과 특정 분야에 대한 진정한 이해이다.

예를 들어보자. 두 사람이 동시에 의사를 위한 제품을 만들어야 한다. 한 사람은 코드를 빠르게 작성할 수 있는 엔지니어이고, 다른 한 사람은 병원 정보과에서 몇 년 일한 사람이다.

예전에는 엔지니어가 만든 것이 더 높은 확률로 성공했지만, 이제는 반대가 되었다. 누구나 아이디어를 실현할 수 있다. 이때 병원의 일상 업무 흐름을 진정으로 이해하는 사람이 더 가치가 있다. 왜냐하면 그는 의사가 실제로 사용할 기능과 그저 그럴듯하게 들리는 기능을 구분할 수 있기 때문이다.

즉, AI가 실행의 문턱을 평준화한 후, 판단력의 차이가 확대되었다.

이것은 일반주의자(generalist)라는 단어의 의미를 직접적으로 바꾸었다.

과거에 우리가 일반주의자라고 말할 때, 보통은 한 엔지니어가 iOS도 작성하고, 웹도 작성하고, 백엔드도 작성할 수 있는 경우를 의미했다. 이러한 일반주의자는 본질적으로 엔지니어 내부의 풀스택이다.

미래의 일반주의자는 학제 간의 풀스택이다.

어떤 사람은 제품, 디자인, 엔지니어링을 동시에 이해하고, 어떤 사람은 제품, 데이터 과학, 엔지니어링을 동시에 이해한다. 이러한 조합은 과거에는 거의 불가능했는데, 각 항목이 오랜 시간의 전문 훈련을 필요로 했기 때문이다.

하지만 이제 AI가 각 항목의 실행 문턱을 낮추었고, 한 사람이 여러 분야를 넘나들며 전문성을 유지할 수 있다.

Claude Code 팀이 바로 그런 팀이다. 엔지니어 매니저, PM, 디자이너, 데이터 과학자, 재무, 사용자 연구 등 각자가 코드를 작성하고 있다.

디자이너는 직접 인터랙션 프로토타입을 실행하여 팀에 보여줄 수 있으며, 더 이상 단순히 그림을 제공하고 엔지니어가 구현하기를 기다리지 않는다.

재무는 복잡한 재무 모델을 실행하기 위해 분석 도구를 직접 구축할 수 있으며, 더 이상 BI를 기다릴 필요가 없다. 사용자 연구의 동료들은 데이터를 직접 실행하기 시작하여, 과거에 데이터 팀의 협조를 기다려야 했던 부분을 스스로 처리하게 되었다.

모든 사람의 전문성은 여전히 존재하지만, AI의 도움으로 코드를 작성하는 것은 모두가 공유하는 언어가 되었다.

#04 SaaS의 방어선이 무너지고 있다

지난 10년 동안 SaaS 산업에는 거의 공리로 여겨지는 몇 가지 합의가 있었다.

첫 번째는 전환 비용이다. 한 회사가 당신의 시스템을 사용하기 시작하면, 그 안에는 몇 년 또는 수년간의 데이터, 구성, 필드, 권한 관계가 서서히 쌓인다.

다른 시스템으로 옮기려면, 이러한 것들을 그대로 옮기는 것만으로도 사람들을 귀찮게 할 만큼 충분하다.

두 번째는 작업 흐름 잠금이다. 직원의 일상 작업, 부서 간 협업, 승인 노드 모두 이 SaaS를 중심으로 형성되었다.

다른 시스템으로 바꾸는 것은 단순히 데이터를 옮기는 것이 아니라, 회사가 수년간 쌓아온 근육 기억을 모두 무너뜨리고 다시 시작해야 한다.

이 두 가지가 합쳐져서 과거 SaaS 산업의 가장 깊은 방어선을 형성했다. 하지만 충분히 강력한 모델이 생기자, 상황의 논리가 변화하기 시작했다.

먼저 전환 비용 측면을 보자. 과거에는 한 SaaS에서 다른 SaaS로 전환하려면, 필드를 정렬하고 데이터 구조를 복제하는 것만으로도 엔지니어 팀이 몇 달 동안 야근해야 했다.

이제는 양쪽의 인터페이스와 데이터 구조를 모델에 맡기고, 스스로 매핑 관계를 정리하게 하여 최적의 해답으로 조금씩 올라갈 수 있다. 원래 몇 달이 걸리던 일이 몇 일 만에 사용할 수 있는 버전을 만들어낼 수 있다.

작업 흐름 잠금 측면도 더 흥미롭다. 과거에 작업 흐름이 고객을 잠그는 이유는 이러한 프로세스 자체가 복잡하고, 숨겨져 있으며, 사람에게 의존하기 때문이다.

직원들이 머릿속에 가지고 있는 누가 누구에게 승인 요청을 하고, 언제 어느 단계에서 막히는지에 대한 암묵적인 이해는 직접 옮길 수 없다.

하지만 Opus 4.7과 같은 모델은 복잡한 프로세스를 이해하고, 분해하고, 새로운 환경에서 다시 구축하는 데 가장 능숙하다. 심지어 다시 구축된 버전이 원래보다 더 매끄럽게 작동할 수도 있다.

따라서 과거 데이터와 프로세스의 축적에 의존하여 구축된 방어선이 무너지고 있다.

SaaS를 만드는 사람들에게는 나쁜 소식일 수 있지만, 모든 SaaS 고객과 새로운 세대의 SaaS를 준비하는 팀에게는 진정한 기회의 창이다.

#05 기업가에게 가장 좋은 시대

앞으로 10년 동안 진정으로 산업을 혁신할 스타트업은 과거 10년보다 10배 더 많을 수 있다.

그 이유는 사실 복잡하지 않다.

작은 팀이 AI를 사용하여 대기업과 동급이거나 더 나은 제품을 만들 수 있다. 반대로 대기업이 진정으로 AI를 사용하려고 하면 오히려 부정적인 자산이 된다.

어떻게 말할 수 있을까?

10년 이상의 역사를 가진 회사는 이미 자신의 비즈니스 프로세스, 직무 분담, 협업 습관, 교육 시스템, KPI 평가의 전체 세트를 갖추고 있다. 이러한 것들은 과거에는 자산이었고, 장벽이었다.

하지만 AI를 진정으로 통합하려면, 모든 것을 다시 검토해야 한다: 비즈니스 프로세스를 재구성해야 하고, 모든 직원을 재교육해야 하며, 한 걸음 나아갈 때마다 거대한 내부 저항에 직면해야 하고, N개의 부서와 N단계의 승인을 조정해야 한다.

반면, 세 사람으로 구성된 스타트업 팀은 첫날부터 AI를 기본으로 삼는다. 그들은 해체해야 할 역사적 부담이 없고, 변경해야 할 습관이 없으며, 설득해야 할 사람이 없다. 오늘 논의가 끝나면 내일 데모를 실행하고, 모레에는 사용자에게 사용할 수 있도록 온라인에 올릴 수 있다.

이러한 속도 차이는 AI 이전에도 존재했다. 스타트업은 대기업에 비해 속도 우위를 가지고 있었다. 하지만 AI가 이 격차를 몇 배로 확대했다.

왜 그럴까?

AI가 강해질수록, 한 사람이 단위 시간 내에 활용할 수 있는 지렛대가 커진다. AI를 잘 활용하는 작은 팀은 오늘의 생산량이 과거 10명의 생산량에 해당할 수 있고, 내일은 과거 30명의 생산량에 해당할 수 있다.

하지만 대기업의 조직 무게는 가벼워지지 않았고, 오히려 AI를 소화해야 하므로 더 무거워졌다. AI가 강해질수록, 작은 팀의 가속도와 대기업의 저항력 간의 차이는 더욱 커진다.

이것이 Boris가 말하는 부정적인 자산이다. 대기업이 돈이 없거나 인력이 부족하거나 의지가 없는 것이 아니라, 그들이 과거에 수익을 올리던 근육이 오늘날 AI가 진정한 가치를 발휘하는 길에 걸려 있다는 것이다.

#06 MCP는 죽지 않는다

MCP는 죽지 않는다.

Skill이 인기를 끌자, 많은 사람들이 MCP가 필요 없다고 생각했다. OpenClaw 창립자도 비슷한 견해를 가지고 있다.

하지만 Boris는 그렇게 보지 않는다. 그는 MCP가 AI 시대의 소프트웨어 연결 계층이 될 것이라고 생각한다.

과거 인터넷의 소프트웨어 연결 방식은 API였다.

하지만 API의 핵심 문제는 엔지니어를 위해 설계되었다는 것이다. API를 사용하려면 먼저 문서를 읽고, 토큰을 신청하고, 코드를 작성하고, 필드를 정렬하고, 예외를 처리해야 한다. 즉, API는 인간 개발자를 위한 것이다.

MCP는 다르다. 그것은 모델이 직접 연결하여 사용할 수 있게 하며, 모델이 스스로 이해하고 조정할 수 있도록 하여 중간에 프로그래머가 번역할 필요가 없다.

그래서 Boris는 API를 인간 개발자 인터페이스라고 부르고, MCP를 모델 인터페이스 프로토콜이라고 부른다. 하나는 사람을 위한 것이고, 다른 하나는 모델을 위한 것이다.

이것은 과거와 매우 유사하다. 모바일 인터넷 시대에는 모든 서비스가 API화되어야 한다는 것이 기본이었다. AI 시대에는 모든 서비스가 MCP화되어야 한다는 것이 기본이다.

#07 컴퓨터 사용은 여전히 중요하다

많은 사람들이 지금 컴퓨터 사용에 대해 이야기할 때, 이 방향이 효과적이지 않을 것이라고 생각할 수 있다.

이유도 매우 합리적이다: 너무 많은 토큰을 소모하고, 느리며, 불안정하다. 보기에는 더 멋진 데모처럼 보이며, 실제로 사용할 수 있는 것과는 거리가 있다.

하지만 Boris가 보는 관점은 완전히 다르다.

그가 진정으로 중요하게 생각하는 것은, 컴퓨터 사용이 AI의 실제 적용에서 가장 큰 고통점을 해결했다는 것이다: 현실 세계에는 API도 없고 MCP도 없는 시스템이 많이 존재한다.

특히 기업 세계에서.

회사를 실제로 경험해본 사람은 알 것이다. 그 안에는 많은 핵심 시스템이 매우 오래되었다. ERP, OA, 재무 시스템, 내부 승인, 공급망 백엔드, 다양한 맞춤형 시스템. 많은 시스템이 인터페이스를 개방하지 않았고, 문서도 없으며, 자동화 능력도 없다. 그들은 그곳에 존재하며, 매일 수많은 직원들이 수동으로 조작하고 있다.

그렇다면 왜 직접 API를 만들지 않는가?

만들 수 없기 때문이다. 이러한 시스템을 개발한 공급업체는 아마도 이미 존재하지 않을 것이다. IT 부서는 재구성을 위한 동기와 예산이 없다.

비즈니스 부서는 더 이상 반년, 일 년을 기다릴 수 없다. 이러한 시스템은 결코 완벽한 API가 자신을 구해주기를 기다리지 않을 것이다.

단기적으로 각 대형 모델은 여전히 자신의 컴퓨터 사용 능력을 향상시킬 것이다.