요즘 개발자 커뮤니티에서 이런 이야기가 심심찮게 나옵니다.
"나 이제 코드 직접 안 써."
스포티파이는 최고 수준의 개발자들이 12월 이후로 코드를 한 줄도 직접 작성하지 않았다고 공식 발표했어요.
Semi Analysis 보고서에 따르면, 전 세계 GitHub 커밋의 4%가 이미 클로드 코드로 작성되고 있고, 연말까지 전체의 5분의 1에 도달할 거라는 전망도 나왔습니다.
이 보고서는 이렇게 표현했어요.
"우리가 눈을 깜빡이는 사이, AI가 모든 소프트웨어 개발을 집어삼켰다."
이 흐름의 한가운데에 있는 사람이 Boris Cherny예요.
Anthropic에서 클로드 코드를 이끄는 엔지니어이자, 본인 스스로 11월 이후 코드를 한 줄도 직접 쓰지 않고 있는 사람. 그에게 물었습니다.
코딩을 배워야 하는 시대는 정말 끝난 건가요?
터미널에서 시작된 혁명
Q. 클로드 코드 출시 1주년이에요. 전 세계 GitHub 커밋의 4%가 클로드 코드로 작성되고 있다는 숫자를 보셨을 텐데, 이 1년을 돌아보면 어떤가요?
이 숫자들은 제가 상상했던 것보다 훨씬 많아요. 그리고 이건 공개 커밋만 집계한 거예요.
비공개 리포지토리(repository, 코드 저장소)까지 포함하면 실제로는 이보다 훨씬 높을 거라고 봅니다.
저한테 가장 놀라운 건 현재 숫자가 아니라 성장 속도예요. 클로드 코드의 어떤 지표를 봐도 성장이 계속 가속되고 있거든요. 올라가는 게 아니라, 올라가는 속도 자체가 점점 빨라지고 있어요. 지난 한 달만 봐도 일일 활성 사용자(DAU)가 두 배가 됐어요.
처음에 클로드 코드를 만들기 시작했을 때, 이건 그냥 작은 해킹 프로젝트였어요. Anthropic 내부에서 어떤 종류든 코딩 제품을 만들어야 한다는 건 알고 있었지만, 뭘 만들어야 하는지는 명확하지 않았거든요.
Anthropic은 오랫동안 모델을 특정한 순서로 발전시켜왔어요. 먼저 코딩을 잘하게 하고, 그다음 도구 사용(tool use)을 잘하게 하고, 그다음 컴퓨터 사용(computer use)을 잘하게 하는 거예요. 대략 이런 궤적이에요.
제가 처음 들어간 팀은 Anthropic Labs 팀이었어요. 이 팀이 꽤 의미 있는 것들을 만들었는데, 클로드 코드, MCP(Model Context Protocol, 모델이 외부 도구와 소통하는 표준 방식), 데스크톱 앱 같은 것들이에요. 코딩, 도구 사용, 컴퓨터 사용이라는 씨앗이 여기서 뿌려진 거죠.
Q. 첫 번째 프로토타입은 어떤 모습이었나요?
Anthropic에 합류하고 한 달은 이것저것 해킹하면서 보냈어요. 이상한 프로토타입을 잔뜩 만들었는데, 대부분은 출시 근처에도 못 갔어요. 모델의 경계가 어디인지 이해하려는 과정이었죠. 그다음 한 달은 포스트 트레이닝(post-training, 모델 학습 이후 추가 학습 과정)을 했어요. 리서치 쪽을 이해하려고요.
엔지니어로서 좋은 작업을 하려면 내가 일하는 레이어 아래의 레이어를 이해해야 한다고 생각하거든요. 전통적인 엔지니어링이라면 인프라, 런타임, 가상 머신, 언어 같은 걸 이해해야 하잖아요. AI 분야에서 일한다면 모델 자체를 어느 정도 이해해야 좋은 결과가 나와요.
그렇게 우회하고 돌아와서 클로드 코드의 프로토타입을 만들기 시작했어요. 맨 처음 버전의 녹화 영상이 있는데, 당시 이름은 'Claude CLI'였어요.
도구 몇 개를 사용하는 모습을 보여줬는데, 저한테 충격적이었던 건 배시(bash, 터미널 명령어 도구) 도구를 하나 줬더니 그걸로 제가 듣고 있는 음악을 알아내는 코드를 작성한 거예요. "지금 무슨 음악 듣고 있어?"라고 물었을 때요.
제가 모델한테 "이 도구를 이런 용도로 써라"라고 지시한 적이 없거든요. 모델이 도구를 받고, 제 질문에 답할 수 있는 방법을 스스로 알아낸 거예요. 답이 나올지도 확신이 없었던 질문에 대해서요.
Q. 이걸 내부에 공유했을 때 반응이 좋았나요?
내부에 글을 올리고 발표했는데, 좋아요가 2개 달렸어요. 그게 당시 반응의 전부였습니다. 코딩 도구라고 하면 사람들은 IDE(통합 개발 환경)를 떠올리거든요. 꽤 정교한 환경들이요. 터미널 기반이라는 건 이상한 설계 방식이었어요.
사실 터미널로 만든 건 의도적인 선택이 아니었어요. 처음 몇 달은 저 혼자였기 때문에 가장 만들기 쉬운 방식이 터미널이었던 거예요. 그리고 이게 꽤 중요한 제품 교훈이라고 생각해요. 초기에는 리소스를 약간 부족하게 배분하는 게 좋다는 거예요.
출시하기 전에 Ben Mann(Anthropic 공동창업자)이 DAU(일일 활성 사용자) 차트를 만들라고 했어요. 저는 "아직 좀 이르지 않나?"라고 했는데, Ben은 "만들어"라고 했어요. 차트를 만들었더니 그래프가 곧바로 수직으로 올라갔어요. 내부에서 먼저 히트가 된 거예요.
그다음에 다른 형태(form factor)로 만들지 고민했는데, 터미널을 유지하기로 했어요. 가장 큰 이유는 모델이 너무 빠르게 좋아지고 있어서, 다른 형태가 그 속도를 따라갈 수 없다고 느꼈거든요. 밤늦게 "모델이 계속 좋아지는데 어떻게 해야 하지?"를 고민하다가, 터미널이 유일하게 떠오른 아이디어였어요.
이미지 출처 : Hacker News • 2025. 05
사람들이 잘 기억 못하는 게 있는데, 클로드 코드는 처음 외부 출시했을 때 즉각적인 히트가 아니었어요. 얼리 어답터들은 바로 사용했지만, 모든 사람이 이게 뭔지 이해하기까지는 몇 달이 걸렸어요. 너무 달랐으니까요. 물론 지금은 클로드 코드가 iOS, Android 앱, 데스크톱 앱, 웹사이트, IDE 확장, Slack, GitHub 등 엔지니어가 있는 모든 곳에서 사용할 수 있어요.
돌아보면 정말 겸허해지는 경험이었어요. 사용자들로부터 계속 배우고 있거든요. 우리 중 누구도 정확히 뭘 하고 있는지 모르고, 다른 사람들과 함께 알아가고 있는 중이에요.
그 과정에서 가장 좋은 신호는 사용자 피드백이에요.
100% AI 코딩의 현실
Q. 지난 5월 Code with Claude 행사에서 "연말까지 코딩에 IDE가 필요 없어질 수 있다"고 예측했을 때 청중이 놀랐다고 들었어요. 그 예측의 근거는 뭐였나요?
Anthropic에서는 모든 것을 지수함수(exponential)로 생각해요. 이게 DNA에 깊이 박혀 있어요. 공동창업자 세 명이 스케일링 법칙(Scaling Laws) 논문의 첫 세 저자거든요.
그래서 당시 클로드가 작성한 코드 비율의 지수 곡선을 그냥 선으로 쭉 연장하면, 연말에 100%를 넘는다는 게 꽤 분명했어요. 직관과는 전혀 맞지 않더라도요.
그래서 제가 한 건 그냥 선을 연장한 것뿐이에요. 그리고 11월에 실제로 그 일이 일어났어요. 그때부터 쭉 그래왔고, 많은 고객들에게서도 같은 패턴을 보기 시작했어요.
사실 이 과정은 점진적이었어요.
2월에 외부 출시했을 때, 클로드 코드가 작성하는 제 코드 비율은 20% 정도였어요. 그 이상은 아니었어요. 5월에도 30% 정도였고, 저는 여전히 대부분의 코드를 Cursor에서 직접 쓰고 있었어요. 100%에 도달한 건 11월이에요.
시간이 걸렸지만, 초기부터 뭔가 될 거라는 느낌은 있었어요. 뭐가 될지는 분명하지 않았지만요. 그래서 매일 밤, 매주 주말마다 이것만 만졌어요.
Q. 지금 현재, 본인의 코딩은 100% 클로드 코드가 작성하는 건가요?
네. 100% 클로드 코드가 작성합니다.
저는 꽤 다작하는 코더예요. Instagram에서 일할 때도 가장 생산적인 엔지니어 몇 명 중 하나였는데, Anthropic에서 팀 리더이면서도 여전히 그래요. 매일 PR(Pull Request, 코드 변경 요청)을 10개, 20개, 30개 정도 올려요. 매일이요.
100% 클로드 코드가 작성하고, 11월 이후로 단 한 줄도 직접 수정한 적 없어요. 다만 코드를 보기는 해요. 아직 완전히 손을 떼도 되는 단계는 아니라고 생각하거든요.
특히 많은 사람이 실행하는 프로그램이면 정확한지, 안전한지 확인해야 해요. 그리고 Anthropic에서는 클로드가 PR 100%를 자동으로 코드 리뷰하고, 그 뒤에 사람이 한 번 더 확인하는 구조예요. 이 2단계 프로세스가 있어서 안심하고 빠르게 갈 수 있는 거예요.
저는 항상 5개 이상의 에이전트를 동시에 돌리고 있어요. 이 인터뷰를 녹음하는 지금 이 순간에도 5개가 돌아가고 있어요. 하나가 끝나면 결과를 확인하고, 다음 작업을 시키고, 또 다른 걸 확인하는 식이에요. 코딩의 방식 자체가 바뀐 거예요. 이제 코딩은 원하는 걸 설명하는 거지, 실제 코드를 타이핑하는 게 아니에요.
오늘 한 엔지니어와 이야기했는데, Go 언어로 서비스를 만들고 있다고 했어요. 한 달 넘게 작업했고, 서비스는 꽤 잘 돌아가고 있대요. "Go로 쓰는 기분이 어때요?"라고 물었더니, "사실 아직 Go를 잘 모릅니다"라고 하더라고요.
이런 게 점점 더 많아질 거예요. 올바르게 작동하고 효율적이라는 걸 알면, 모든 세부사항을 다 알 필요가 없는 거예요.
Q. 이 생산성 변화를 숫자로 보면 어떤가요?
Anthropic에서 지난 1년간의 숫자가 미친 수준이에요. 클로드 코드 도입 이후에 엔지니어링 팀을 아마 4배 정도 늘렸는데, 엔지니어 1인당 생산성이 200% 증가했어요. PR 기준으로요.
이 숫자가 왜 미친 거냐면, 저는 전에 메타(Meta)에 있었고 회사 전체의 코드 품질을 담당했거든요. Facebook, Instagram, WhatsApp 등 모든 코드베이스요. 거기서 수백 명의 엔지니어가 1년 동안 작업해서 생산성이 몇 퍼센트 포인트 오르는 게 보통이었어요. 그런데 지금은 수백 퍼센트 포인트의 향상을 보고 있으니, 전례가 없는 거예요.
놀라운 건 이게 얼마나 빠르게 당연해졌는지예요. 이 숫자를 듣고 "아 그렇구나" 하잖아요.
소프트웨어 개발, 제품 구축, 테크 전체에 일어나고 있는 변화의 규모가 이렇게 전례 없는데, 너무 쉽게 익숙해지는 거예요.
가끔 스스로 되새겨야 해요. 이건 미친 일이라고요.
"코딩은 해결된 문제입니다"
Q. 100% AI 코딩 이후, 소프트웨어 개발의 다음 큰 변화는 뭐라고 보나요?
지금 일어나고 있는 건 클로드가 아이디어를 내기 시작했다는 거예요. 클로드가 피드백을 살펴보고, 버그 리포트를 보고, 텔레메트리(telemetry, 사용 데이터 수집) 같은 것들을 보면서 버그 수정이나 출시할 것들에 대한 아이디어를 내요. 동료(co-worker) 같은 느낌으로 변하고 있는 거죠.
두 번째는 코딩의 경계를 넘어서기 시작했다는 거예요. 이 시점에서 코딩은 대체로 해결된 문제(solved problem)라고 말해도 될 것 같아요. 적어도 제가 하는 종류의 프로그래밍은요. 클로드가 할 수 있으니까요. 그래서 이제 "그다음은 뭐지?"를 생각하고 있어요. 코딩에 인접한 영역들도 많고, 그 외에 컴퓨터로 하는 일반적인 업무 전반이요.
앞으로 몇 달 안에 업계 전반에서 점점 더 해결될 거라고 봐요. 어떤 코드베이스든, 어떤 기술 스택이든요.
이미 코딩의 경계를 넘어서는 사례가 쏟아지고 있어요.
이미지 출처 : X
지난 6개월 정도, 클로드 코드를 코딩이 아닌 용도로 쓰는 사람이 정말 많았거든요. 트위터에서 누군가는 토마토 재배에 쓰고 있었고, 누군가는 자기 유전체(genome)를 분석하고 있었고, 누군가는 손상된 하드 드라이브에서 결혼식 사진을 복구하는 데 썼고, MRI를 분석하는 사람도 있었어요.
전혀 기술적이지 않은 사용 사례들이에요. 사람들이 터미널이라는 장벽을 넘어서까지 이런 일을 하고 있다는 건, 이 도구가 코딩 너머로 갈 준비가 됐다는 아주 강한 신호였어요.
작년 5월쯤 사무실에 출근했더니, 데이터 사이언티스트 브렌던(Brendan)이 터미널에서 클로드 코드를 돌리고 있었어요. 충격이었어요. 터미널은 엔지니어용 제품이고, 많은 엔지니어도 쓰기 싫어하는 가장 저수준의 작업 방식이거든요.
근데 브렌던은 스스로 Node.js를 다운받고, 클로드 코드를 설치해서 터미널에서 SQL 분석을 하고 있었어요. 그다음 주에는 모든 데이터 사이언티스트가 같은 걸 하고 있었고요.
사람들이 제품을 설계 의도와 다르게 사용하는 걸 보면, 그 용도에 맞는 전용 제품을 만들어야 한다는 뜻이에요. 코워크(Co-work)가 거기서 나왔어요.
Q. "코딩이 해결됐다"면, 다음에 가장 크게 영향받을 역할은 뭔가요?
코딩에 인접한 역할들이 먼저일 거예요. 제품 관리자(PM), 디자인, 데이터 사이언스 같은 거요. 컴퓨터로 할 수 있는 거의 모든 종류의 업무로 확장될 거예요. 모델이 점점 더 잘하게 될 테니까요.
1년 전만 해도 '에이전트(agent)'가 뭔지 아는 엔지니어가 거의 없었어요. 아무도 안 썼어요. 하지만 지금은 그냥 일하는 방식이 됐어요. 비기술 업무를 보면 아직 대부분 대화형 AI, 그러니까 챗봇을 쓰고 있지, 에이전트를 쓴 적이 없어요.
에이전트라는 단어가 너무 남용돼서 의미가 사라진 것 같지만, 기술적으로는 아주 구체적인 의미가 있어요.
도구를 사용할 수 있는 AI예요. 말만 하는 게 아니라, 실제로 행동하고, 시스템과 상호작용할 수 있는 거예요. 구글 독스를 쓰고, 이메일을 보내고, 컴퓨터에서 명령을 실행하고요.
컴퓨터 도구를 이런 식으로 사용하는 거의 모든 직업이 다음 차례라고 생각해요.
Q. 그러면 지금 PM들이 좀 긴장해야 하는 건가요? 클로드가 뭘 만들지까지 제안하기 시작한다면요.
가장 간단한 방법은 클로드 코드를 열어서 Slack 스레드를 가리키는 거예요. 저희한테는 클로드 코드에 대한 내부 피드백이 모이는 채널이 있어요. 2024년에 내부 출시한 이후로 피드백의 소방호스 같은 곳이에요.
초기에 제가 했던 건, 누군가 피드백을 보내면 가능한 한 빠르게, 1분이든 5분이든, 모든 걸 직접 고치러 가는 거였어요. 이 빠른 피드백 순환이 사람들이 더 많이 피드백을 주도록 만들어요. 보통 제품에 피드백을 보내면 블랙홀로 빨려 들어가잖아요. 그러면 다시는 피드백 안 하게 돼요. 사람들이 '들었다'는 느낌을 받으면, 제품을 더 좋게 만드는 데 기여하고 싶어해요.
지금은 같은 일을 하는데, 클로드가 많은 작업을 대신해요.
채널을 가리키면 "여기 제가 할 수 있는 몇 가지가 있어요. PR 두 개 올려놨는데, 볼래요?"라고 하거든요. 저는 "좋아"라고만 하면 돼요.
새 모델이 나올 때마다 리셋되는 사고방식
Q. 모델이 빠르게 좋아지면서, 본인도 사고방식이 따라가지 못하는 순간이 있었다고요?
모델이 너무 빠르게 변하다 보니 예전 방식에 갇히는 순간이 있어요. 새로 들어온 사람이나 신입이 저보다 더 AGI 지향적인 방식으로 일하는 걸 볼 때가 있어요.
몇 달 전에 메모리 릭(memory leak, 메모리 사용량이 계속 증가하다 프로그램이 죽는 현상)이 있었어요. 모든 엔지니어가 천 번쯤 디버깅해본 아주 흔한 문제예요. 전통적으로는 힙 스냅샷(heap snapshot, 메모리 상태를 저장하는 것)을 떠서 특수 디버거에 넣고, 특수 도구로 분석하는 거예요. 저는 이 방식대로 하고 있었어요. 트레이스를 들여다보면서 원인을 찾고 있었죠.
그런데 팀에 새로 온 엔지니어는 그냥 클로드 코드한테 시킨 거예요.
"메모리 릭이 있는 것 같은데, 찾아줄래?"
클로드 코드가 제가 하던 것과 똑같은 걸 했어요. 힙 스냅샷을 떠서, 분석하기 위한 작은 도구를 스스로 만들고, 문제를 찾아서 PR까지 올렸어요. 저보다 빨리요.
이게 지금 시점에서 중요한 마인드셋이에요. 오래 써왔던 사람일수록 현재 모델이 아니라 예전 모델 기준으로 생각하기 쉬워요. 더 이상 Sonnet 3.5가 아니에요. 새 모델들은 완전히 다른 수준이거든요.
Q. 팀에서 이런 마인드셋 전환을 위해 적용하는 원칙이 있다고 들었어요.
몇 가지가 있어요.
하나는 모든 걸 약간 부족하게 투자하는(underfund) 거예요. 프로젝트에 엔지니어 한 명만 배정하기도 해요. 그 사람이 빠르게 출시할 수 있는 이유는 빠르게 하고 싶은 내재적 동기 때문이에요. 좋은 아이디어가 있으면 빨리 세상에 내놓고 싶잖아요. 아무도 강제하지 않아도요. 그럴 때 클로드를 써서 많은 작업을 자동화하게 되거든요.
또 다른 원칙은 속도를 독려하는 거예요. 오늘 할 수 있으면 오늘 하라고 해요. 초기에 저 혼자였을 때 유일한 장점이 속도였거든요. 이 치열한 코딩 도구 시장에서 경쟁할 수 있는 유일한 방법이었어요. 지금도 팀에서 여전히 중요한 원칙이에요.
더 빠르게 가고 싶으면, 클로드한테 더 많은 걸 시키면 돼요.
Q. 일부러 부족하게 투자하면 오히려 더 나은 결과가 나온다는 건 직관에 반하는 것 같은데요?
AI가 더 빠르게 해준다는 것뿐 아니라, 사람이 적으면 AI 도구에서 더 많은 것을 뽑아낸다는 거예요. 훌륭한 엔지니어를 뽑으면 방법을 찾아낼 거예요. 특히 그렇게 할 수 있도록 권한을 주면요.
CTO나 여러 회사 사람들에게 많이 하는 조언이 있는데, 처음부터 최적화하거나 비용을 줄이려고 하지 말라는 거예요.
이미지 출처 : X
시작은 엔지니어에게 가능한 한 많은 토큰을 주는 거예요. "입사하면 무제한 토큰"이 복지로 나오는 회사도 생기고 있는데, 이걸 적극 권장해요. 사람들이 "이건 너무 미친 아이디어야"라고 할 만한 것도 자유롭게 시도할 수 있게 되거든요.
아이디어가 작동하면 그때 최적화하세요. 하이쿠(Haiku)나 소네트(Sonnet)로 할 수 있는지, 오퍼스(Opus) 대신 쓸 수 있는지 그때 따져보면 돼요.
소규모에서는 실제로 큰 비용이 아니에요. 개인 엔지니어가 실험하는 수준이면 토큰 비용이 급여나 다른 사업 운영 비용에 비하면 상대적으로 낮아요. 규모가 커져서 비용이 커지면, 그때가 최적화할 시점이에요. 너무 일찍 하지 마세요.
참고로 Anthropic에서는 월 수십만 달러 수준의 토큰을 쓰는 엔지니어가 나타나기 시작했어요.
코딩에 대한 그리움?
Q. 코드를 직접 쓰지 않게 되면서, 코딩이 그립진 않나요?
저한테 코딩은 항상 실용적이었어요. 뭔가를 만들기 위한 도구였지, 그 자체가 목적은 아니었어요. 독학으로 프로그래밍을 배웠는데, 처음 프로그래밍을 한 이유가 수학 시험에서 커닝하려고 했던 거예요. 그래핑 계산기(TI-83 Plus) 있잖아요. 거기에 답을 프로그래밍해 넣었어요.
다음 해 수학 시험은 너무 어려워서 답을 다 넣을 수가 없었어요. 문제가 뭔지 모르니까요. 그래서 대수학 문제를 풀어주는 작은 프로그램을 만들었어요. 케이블을 구해서 반 전체한테 프로그램을 나눠줬더니 온 반이 A를 받았어요. 물론 다 걸려서 선생님한테 혼났지만요.
처음부터 늘 실용적이었어요. 어느 순간 프로그래밍 자체의 아름다움에 빠지기도 했어요. TypeScript 책도 썼고, 당시 세계에서 가장 큰 TypeScript 밋업을 시작하기도 했어요. 함수형 프로그래밍, 타입 시스템의 아름다움 같은 것들이요. 복잡한 수학 문제를 풀었을 때 느끼는 그 짜릿함과 비슷한 거예요.
하지만 그게 끝은 아니에요.
저한테 코딩은 도구예요. 그리고 지금 이 도구가 훨씬 더 강력해진 거예요.
다만 모든 사람이 이렇게 느끼는 건 아니에요. 팀에 Lena라는 엔지니어가 있는데, 주말에도 C++ 코드를 직접 손으로 작성해요. 그냥 좋아하니까요. 모든 것이 변하더라도, 기술을 즐기고 손으로 만드는 여지는 항상 있을 거예요.
Q. 엔지니어로서 실력이 퇴화할까 걱정되지 않나요?
개인적으로 크게 걱정하지 않아요. 프로그래밍은 연속선(continuum) 위에 있다고 생각하거든요.
아주 오래전에는 종이에 수학을 하는 사람들로 가득 찬 방이었고, 그다음에는 하드웨어였고, 스위치였고, 펀치 카드(punch card)였어요. 소프트웨어로 프로그래밍한다는 방식 자체가 1960년대 이후, 60년 정도밖에 안 됐어요.
일론 머스크가 "AI가 바이너리(0과 1)를 바로 쓰면 되지, 프로그래밍 추상화가 왜 필요하냐"라고 한 적 있는데, 실제로 기술적으로 가능해요. 원한다면 할 수 있어요.
이미지 출처 : computerhope.com
제 할아버지가 소련 최초의 프로그래머 중 한 명이었는데, 펀치 카드로 프로그래밍했어요. 어머니가 어릴 때 할아버지가 펀치 카드 다발을 집에 가져오면, 거기에 크레용으로 그림을 그렸다고 해요.
할아버지는 소프트웨어로의 전환을 직접 보지 못했지만, 어느 시점에 전환이 일어났고, 그때도 아마 "이건 진짜 코딩이 아니야"라고 한 구세대 프로그래머가 있었을 거예요.
초기 ACM 매거진에서 비슷한 글을 본 적 있어요. "이건 진짜 코딩이 아니다"라고 하는 사람들이요. 이 분야는 항상 이런 식으로 변해왔어요.
어떤 면에서는 아래 층을 이해하는 게 여전히 더 나은 엔지니어가 되는 데 도움이 돼요. 앞으로 1년 정도는 그럴 거라고 봐요. 하지만 곧 그것도 크게 중요하지 않게 될 거예요. 프로그래머 아래에서 돌아가는 어셈블리 코드 같은 존재가 되는 거죠.
감정적으로는, 프로그래머로서 새로운 걸 배우는 건 항상 해왔던 일이에요. 새 프레임워크, 새 언어가 항상 나왔으니까요. 다만 모든 사람이 이렇게 느끼는 건 아니고, 어떤 분들은 상실감이나 향수 같은 걸 느낄 수도 있다고 생각해요.
코딩을 오히려 지금이 가장 즐거워요. 지루한 디테일을 안 해도 되니까요. 많은 고객분들도 같은 말을 해요. 클로드 코드 덕분에 코딩이 다시 즐거워졌다고요.
그리고 재미있는 건, 이 모든 변화 속에서도 저희 팀은 채용을 하고 있다는 거예요. 클로드 코드 팀은 사람을 뽑고 있어요. 개인적으로 이 모든 게 일을 더 즐겁게 만들었어요. 코딩의 자잘한 것들을 안 다뤄도 되니까요.
제비언스 패러독스(Jevons Paradox, 효율이 올라가면 오히려 수요가 더 늘어나는 현상)라는 게 있는데, 더 많은 걸 할 수 있게 되니까 오히려 더 많은 사람이 필요해지는 면이 있어요.
구텐베르크 이후의 세계
Q. "코딩을 배워야 하나"라는 질문에 대해서는 어떻게 생각하세요? 1~2년 후에도 코딩을 배울 필요가 있을까요?
지금 클로드 코드 같은 에이전트를 사용하는 사람이라면, 아직은 아래 층을 이해할 필요가 있어요. 하지만 1~2년 후에는 크게 상관없어질 거예요.
이걸 역사에서 어떤 비유가 맞는지 계속 생각했는데, 인쇄기(printing press)가 가장 가깝더라고요. 1400년대 중반 유럽의 문자 해독률(literacy)은 1% 미만이었어요. 읽고 쓸 수 있는 건 소수의 필사가(scribe)들이었고, 이들을 고용한 영주나 왕들조차 종종 읽지 못했어요. 인구의 극소수만이 이 일을 담당했죠.
이미지 출처 : ourworldindata.org
구텐베르크와 인쇄기가 등장한 후 50년 동안, 그 이전 1000년보다 더 많은 인쇄물이 만들어졌어요. 비용은 50년에 걸쳐 100배 떨어졌고요. 문자 해독률은 시간이 좀 걸렸어요. 읽고 쓰기를 배우려면 교육 시스템이 필요하고, 농장에서 종일 일하지 않아도 되는 여유가 있어야 하니까요. 하지만 다음 200년에 걸쳐 전 세계적으로 70%까지 올라갔어요.
재미있는 역사 기록이 있어요. 1400년대의 어떤 필사가 인터뷰에서 인쇄기에 대해 어떻게 느끼냐는 질문을 받았대요. 그 사람은 오히려 기뻐했어요. "제가 싫어하는 건 책 사이의 내용을 베끼는 일이었고, 좋아하는 건 책의 예술 작업과 제본이었는데, 이제 그 시간이 생겼다"고요.
엔지니어로서 비슷한 감정이에요. 코딩의 지루한 세부사항, git 다루기, 온갖 도구 사용하기, 이런 게 재미있는 부분은 아니었거든요.
재미있는 건 뭘 만들지 생각하는 것, 사용자와 대화하는 것, 큰 시스템을 고민하는 것, 미래를 생각하는 것, 팀원들과 협업하는 거예요. 이제 그걸 더 많이 할 수 있게 됐어요.
Q. 그러면 모든 사람이 프로그래밍할 수 있는 세상이 온다는 건가요?
모든 사람이 프로그래밍할 수 있는 세상을 상상해요. 누구든 언제든 소프트웨어를 만들 수 있는 세상이요.
그게 뭘 가능하게 할지는 모르겠어요. 1400년대에 아무도 이 미래를 예측 못한 것처럼요.
인쇄기가 없었으면 우리가 지금 이 대화를 하고 있을 수 없었을 거예요. 마이크도, 우리 주변의 모든 것도 존재하지 않았을 거예요. 이렇게 큰 집단을 조율하는 건 불가능했을 테니까요.
인쇄기가 없었다면 르네상스도 일어날 수 없었어요. 르네상스의 핵심은 지식의 확산이었고, 사람들이 소통하기 위해 쓴 기록물이었으니까요. 그때는 전화도 인터넷도 없었거든요.
저한테는 이게 아주 낙관적인 버전의 미래예요. 정말 기대되는 부분이에요. 상상할 수 없는 거예요.
사실 제가 Anthropic에 합류한 이유도 이것과 관련이 있어요. 일본 시골에서 살면서, SF 소설을 많이 읽었어요. 시골에서 미소 된장을 만들면서 긴 시간 스케일로 생각하다 보니, "이게 어떻게 잘못될 수 있는지 아는데, 더 잘 되도록 기여해야 한다"는 생각이 들었어요. 기술이 한쪽으로만 가는 게 아니라 좋은 방향으로 가려면 누군가가 거기 있어야 하니까요.
하지만 그 과정에서 많은 사람에게 파괴적이고 고통스러울 거라는 것도 사실이에요. 사회로서 이 대화를 해야 하고, 함께 답을 찾아야 해요.
소프트웨어 엔지니어라는 직함이 사라진다
Q. 이 격변의 시기에 어떻게 해야 살아남을 수 있을까요?
도구를 실험하세요.
알아가세요.
무서워하지 마세요.
뛰어들어서 써보고, 최전선에 서세요.
두 번째 조언은 과거보다 더 제너럴리스트(generalist, 다방면의 역량을 가진 사람)가 되라는 거예요. 학교에서 CS(컴퓨터 과학)를 전공하면 코딩을 배우고, 시스템 아키텍처를 약간 배우고, 그 정도잖아요. 하지만 제가 매일 일하는 가장 효과적인 엔지니어들은 여러 분야를 넘나들어요.
클로드 코드 팀에서는 모든 사람이 코딩해요.
PM도 코딩하고, 엔지니어링 매니저도 코딩하고, 디자이너도 코딩하고, 파이낸스 담당자도 코딩하고, 데이터 사이언티스트도 코딩해요. Anthropic의 디자이너들은 대부분 꽤 기술적이에요. 이제 엔지니어를 귀찮게 하는 대신 직접 코드에 들어가서 고치거든요.
코딩을 안 하던 디자이너도 시작했고, 스스로 막힌 걸 해결할 수 있으니 좋아해요. 다들 클로드 데스크톱 앱을 많이 쓰는데, 다운받으면 코드 탭이 있어요. 코워크 바로 옆이에요. 터미널을 여러 개 열지 않아도 클로드 코드의 힘을 그대로 쓸 수 있거든요.
결국 핵심은 사람들이 있는 곳에 제품을 가져가는 거예요. 새로운 워크플로우를 배우게 강요하지 않고, 이미 하고 있는 걸 조금 더 쉽게 만들어주는 거요.
이미지 출처 : “What T-Shaped, Π-Shaped & Comb-Shaped People Mean” by Dave Gerhardt, LinkedIn Pulse
그리고 개별 엔지니어들을 보면, 가장 강한 엔지니어들은 제품과 인프라를 함께 하는 하이브리드형이거나, 디자인 감각이 뛰어난 제품 엔지니어이거나, 비즈니스를 잘 이해해서 다음에 뭘 해야 할지 파악하는 엔지니어이거나, 사용자와 대화하는 걸 좋아해서 사용자가 원하는 걸 전달할 수 있는 엔지니어예요.
앞으로 몇 년간 가장 보상받는 사람들은 AI 네이티브(AI-native)이면서 동시에 호기심이 많고, 여러 분야를 넘나드는 제너럴리스트일 거라고 생각해요. 단순히 AI 도구를 잘 쓰는 것만으로는 안 되고, 엔지니어링 너머의 더 넓은 문제를 볼 수 있어야 해요.
Q. 엔지니어링, 디자인, PM이라는 세 가지 역할 구분이 아직 유효한가요?
단기적으로는 유지될 거예요. 하지만 이미 이 역할 사이에 50% 정도 겹침이 보여요.
많은 사람이 실은 같은 일을 하고 있고, 각자 전문성이 조금씩 다를 뿐이에요. 예를 들어 저는 코딩을 좀 더 하고, PM인 Cat은 조율이나 기획, 예측 같은 걸 좀 더 하는 식이죠.
연말쯤이면 이 경계가 더 흐려질 거라고 봐요. '소프트웨어 엔지니어'라는 직함이 사라지기 시작하고, '빌더(builder)'로 대체되거나, 아니면 모든 사람이 PM이면서 코딩하는 형태가 될 수도 있어요. 많은 사람에게 고통스러운 과정일 거예요.
저희도 아직 1%밖에 안 했다고 느껴요. 클로드 코드를 쓰지 않는 사람, AI를 아예 쓰지 않는 사람이 세상에 훨씬 더 많아요. 아직 시작에 불과해요.
클로드 코드를 잘 쓰는 법
Q. 클로드 코드를 처음 쓰거나, 더 잘 쓰고 싶은 사람에게 프로 팁을 공유해주세요.
먼저 한 가지 전제를 깔면, 클로드 코드를 사용하는 정답은 하나가 아니에요.
개발 도구이고, 개발자는 다 달라요. 선호도도 다르고, 환경도 다르거든요. 자기만의 방법을 찾아야 해요. 다행히 클로드 코드한테 물어볼 수 있어요. 추천도 해주고, 설정도 수정해주고, 자기 자신에 대해 알고 있으니까요.
첫 번째 팁: 가장 뛰어난 모델을 쓰세요. 현재 기준으로 Opus 4.6이에요.
저는 항상 최대 노력(maximum effort) 모드를 켜놓아요. 사람들이 가끔 Sonnet 같은 더 저렴한 모델을 쓰려고 하는데, 덜 똑똑한 모델은 같은 작업에 토큰(token)을 더 많이 쓰게 돼요. 수정도 더 필요하고, 손도 더 잡아줘야 하고요. 그래서 저렴한 모델이 실제로 더 싸다고 확신하기 어려워요.
가장 뛰어난 모델이 오히려 토큰도 적게 들고 더 빠른 경우가 많아요. 직관에 반하지만, 실제 경험상 그래요.
두 번째 팁: 플랜 모드(Plan Mode)를 쓰세요.
저는 작업의 80% 정도를 플랜 모드로 시작해요. 플랜 모드는 아주 단순해요. 모델의 프롬프트에 "아직 코드를 쓰지 마세요"라는 한 문장을 주입하는 게 전부예요. 그게 다예요.
터미널에서는 Shift+Tab을 두 번 누르면 플랜 모드로 들어가요. 데스크톱 앱이나 웹에서는 버튼이 있고요. 모바일에서도 곧 지원할 예정이고, 최근에 Slack 통합에서도 플랜 모드를 출시했어요.
모델과 왔다 갔다 하면서 계획을 세운 다음, 계획이 좋아 보이면 실행시키면 돼요. 그 다음부터는 수정 사항을 자동 승인해요. 계획이 좋으면 Opus 4.6이 거의 매번 한 번에 정확히 만들어내거든요.
세 번째 팁: 다양한 인터페이스를 실험해보세요.
많은 사람이 클로드 코드 하면 터미널을 떠올리는데, iOS, Android 앱, 데스크톱 앱, Slack 통합 등 많은 형태를 지원해요. 저도 지금은 코딩의 3분의 1은 터미널, 3분의 1은 데스크톱 앱, 3분의 1은 iOS 앱에서 해요. 2026년에 폰으로 코딩할 줄은 상상도 못했어요.
저는 항상 에이전트를 여러 개 동시에 돌려요. 지금 이 녹음하는 순간에도 다섯 개가 돌아가고 있어요.
오늘 아침에 일어나서 제일 먼저 한 것도, 폰을 열어서 클로드 iOS 앱의 코드 탭에 들어가 에이전트를 하나 시킨 거예요. 어제 작성한 코드가 맞는지 좀 의심이 되어서 확인시켰는데, 맞더라고요. 이게 지금 코딩이에요.
데스크톱 앱에서는 원하는 만큼 클로드 세션을 동시에 돌릴 수 있어요. 이걸 '멀티 클로딩(multi-quading)'이라고 부르는데, 하나 시작하고, 또 하나 시작하고, 또 하나 시작한 다음에 커피 마시러 가면 돼요. 돌아오면 결과가 나와 있어요.
6개월 후의 모델을 위해 만들어라
Q. AI 제품을 만드는 사람들에게 추가 조언이 있다면요?
모델을 상자에 가두지 마세요.
많은 사람이 본능적으로 모델을 특정 방식으로 행동하게 만들려고 해요. 아주 엄격한 워크플로우를 위에 얹어서 "1단계를 하고, 2단계를 하고, 3단계를 해라"라고 하면서 화려한 오케스트레이터(orchestrator)가 이걸 관리하는 식이죠.
하지만 거의 항상, 모델에게 도구와 목표를 주고 스스로 알아내게 하면 더 나은 결과가 나와요. 1년 전에는 그런 뼈대(scaffolding)가 필요했지만, 요즘은 거의 필요 없어요.
클로드 코드 자체가 이 철학을 따라 만들어졌어요. 제품 자체가 모델인 거예요. 도구가 아주 적어요. 뼈대가 거의 없어요. 모델이 어떤 도구를 어떤 순서로 쓸지 스스로 결정하게 두는 거예요.
전통적인 접근법은 모델을 상자에 넣고 엄격한 워크플로우로 제어하는 건데, 우리는 그 반대로 갔어요. 그리고 그게 훨씬 더 잘 작동했어요.
쓴 교훈(Bitter Lesson)을 기억하세요. 리치 서튼(Rich Sutton)이라는 분이 10년쯤 전에 쓴 블로그 글이 있어요. 핵심은 간단해요.
더 범용적인 모델이 항상 더 특화된 모델을 이긴다는 거예요. 장기적으로 항상 더 범용적인 모델에 베팅하세요.
작은 모델을 쓰거나, 파인튜닝(fine-tuning, 특정 용도로 모델을 추가 학습시키는 것)을 하는 건 특정 이유가 있을 때만요. 워크플로우 뼈대가 성능을 10~20% 향상시킬 수 있지만, 다음 모델이 나오면 그 이득이 사라지는 경우가 많아요. 차라리 다음 모델을 기다리는 게 나을 때가 많습니다.
오늘의 모델이 아니라 6개월 후의 모델을 위해 만드세요. 클로드 코드가 처음부터 맞힌 게 이거라고 생각해요. 초기 버전에서 Sonnet 3.5는 코딩 실력이 아직 충분치 않았어요. 클로드 코드의 베팅은 "어느 시점에 모델이 충분히 좋아져서 코드 대부분을 쓸 수 있을 것"이었어요. 그리고 Opus 4와 Sonnet 4에서 처음 그 변곡이 왔어요.
이미지 출처 : Nature article — “Title of the Article”, Communications Earth & Environment, 2023.
스타트업을 만드는 분들에게 많이 드리는 조언인데, 처음 6개월은 제품-시장 적합(product-market fit)이 별로 안 좋을 거예요. 불편할 거예요. 하지만 6개월 후의 모델을 위해 만들면, 그 모델이 나왔을 때 바로 달릴 수 있어요. 제품이 딱 맞아 떨어지기 시작하거든요.
이건 혁신에 대한 근본적인 태도와도 연결돼요.
혁신에는 로드맵이 없어요. 강제할 수 없어요.
사람들에게 공간을 줘야 하고, 실패해도 괜찮다는 심리적 안전감을 줘야 해요. 아이디어의 80%가 나빠도 괜찮아요. 대신 아이디어가 나쁘면 빨리 손절하고, 더 투자하는 대신 다음 아이디어로 넘어가야 해요.
클로드 코드 초기에 이게 유용할 거라는 확신은 전혀 없었어요. 하지만 뭔가 실마리가 있다는 느낌은 있었고, 그 실마리를 계속 잡아당긴 거예요.
Q. "6개월 후의 모델을 위해 만들어라"를 좀 더 구체적으로 풀면요? 뭘 가정할 수 있는 건가요?
모델이 더 좋아질 방향 중 하나는 도구 사용과 컴퓨터 사용이 점점 더 나아진다는 거예요. 이건 확실히 베팅할 수 있는 방향이에요.
또 하나는 모델이 점점 더 오래 실행될 수 있게 된다는 거예요.
이미지 출처 : Anthropic, Claude documentation
1년 전 Sonnet 3.5로 작업할 때는 15초에서 30초 정도 지나면 방향을 잃기 시작했어요. 복잡한 작업에서 손을 계속 잡아줘야 했죠.
하지만 지금 Opus 4.6은 평균적으로 감독 없이 10분, 20분, 30분 동안 돌아가요. 몇 시간, 며칠 동안 돌아가는 경우도 있고, 몇 주간 돌아간 사례도 있어요. 시간이 지나면서 모델이 아주 오랫동안 돌아가는 게 점점 일상이 될 거예요. 더 이상 옆에 앉아서 지켜보지 않아도 되는 거죠.
Q. 마지막으로, 지금 이 시점에 코딩을 시작하려는 사람에게 한마디 해주신다면요?
뛰어드세요. 지금이 코딩을 시작하기 가장 좋은 때예요.
역설적이지만, AI가 코드를 대신 써주는 시대이기 때문에 오히려 그래요. 예전에는 문법부터 배워야 했고, 프레임워크를 익혀야 했고, 에러 메시지를 구글링하느라 시간을 보냈잖아요. 지금은 그런 과정 없이 바로 뭔가를 만들 수 있어요.
제 할아버지는 펀치 카드로 프로그래밍했고, 저는 계산기로 커닝 프로그램을 만들면서 시작했고, 지금은 폰에서 에이전트한테 말로 시키는 거잖아요.
코딩이라는 행위의 형태는 계속 바뀌어왔어요. 이번에도 바뀌는 거예요.
다만 이번에는 속도가 이전과 비교할 수 없을 만큼 빠르다는 것, 그리고 그 변화의 방향이 더 많은 사람이 만들 수 있는 세상을 향하고 있다는 것. 그게 저한테는 정말 기대되는 부분이에요.
AI를 최대한 레버리지하여, 나만의 스타일로 창업을 꿈꾸는 모든 분들을 위한, 'AI 솔로프리너 클럽'이 진행 중이에요. 제가 운영하는 클럽이며, 새로운 방향을 꿈꾸는 모든 분들께 자신있게 권해드려요.
지금처럼 AI와 소셜미디어를 누구나 쉽게 활용할 수 있는 시기는 역사상 처음이에요. 흐름을 탔을 뿐인데, 인생이 180도 바뀐 제가 직접 이를 증명해요. 그래서 지금이야말로, '나만의 길'을 현실로 만들 수 있는 최고의 타이밍이라고 확신해요.
한 기수당 최대 30명 받는, 프라이빗 클럽입니다. :)
[👉🏻ASC 신청하러 가기]
의견을 남겨주세요