Anthropic의 Head of Claude Code인 보리스 처니가 유튜브 채널 Ryan Peterman과 진행하여 2025년 12월 15일 공개된 인터뷰 내용을 리뷰해봤습니다.
보리스는 메타에서 주니어(IC4)로 시작해 Principal Engineer (IC8)까지 올라온 인물로, TypeScript 책 『Programming TypeScript』의 저자이며, 샌프란시스코 TypeScript 밋업을 세계 최대 규모로 성장시킨 인물이기도 합니다. 2024년 Anthropic에 합류하고 최근에는 Claude Code를 만들어서 큰 임팩트를 만들고 있습니다. 인터뷰는 그의 커리어 여정을 매우 깊이 있게 다루고 있어 AI 시대, 커리어를 준비하는데에 큰 도움이 될 것 같습니다.
시작: Meta에서의 성장
"제품 개발에서 잠재 수요(Latent Demand)보다 중요한 건 없다고 생각합니다. Facebook에서 성공한 제품들을 보면, 하나같이 이 잠재 수요를 정확히 포착한 경우였어요. "
Boris는 잠재 수요를 제품 개발의 핵심 원칙으로 꼽습니다. Facebook 마켓플레이스의 탄생 배경이 좋은 예시입니다. Facebook Groups라는 서비스가 있었는데 게시물의 40%가 물건을 사고파는 내용이었습니다. Groups는 원래 커머스용으로 설계된 기능이 아니었는데, 사용자들이 알아서 그렇게 활용하고 있었던 거죠. Facebook은 이처럼 사용자들이 이미 하고 있는 행동을 관찰하고, 그것을 중심으로 제품을 설계했습니다.
"사람들에게 아직 하지 않는 것을 하게 만들 수는 없습니다. 대신 그들이 이미 가진 의도를 찾아서 더 쉽게 실현할 수 있도록 도와주는 것입니다."
사이드 프로젝트의 중요성
나만의 문제를 해결하라
"엔지니어로서 우리의 슈퍼파워는 자동화입니다. 가장 지루한 것들을 자동화할 수 있습니다."
보리스는 코드 리뷰를 할 때마다 특정 이슈에 대해 스프레드시트에 기록했습니다. 같은 종류의 코멘트를 몇 번 달게 되면 그것을 자동화하는 린트 규칙을 작성했습니다. 결국 대부분의 코드 리뷰가 자동화되었습니다.
"만약 같은 문제를 2-3번 겪는다면, 다른 사람들도 그 문제를 겪고 있는지 살펴봐야 합니다."
제너럴리스트의 가치
"저는 제너럴리스트와 일하는 것을 정말 좋아합니다. 코딩도 하면서 제품 작업, 디자인도 할 수 있고, 제품 감각이 있고, 사용자와 대화하고 싶어하는 엔지니어. 이런 엔지니어와 일하는 것이 최고입니다."
사이드프로젝트는 제네럴리스트가 되게 해줍니다. 회사에서 요구하는 일만 하다보면, 이 일이 왜 필요한지에 대한 근본에 대해 의문을 놓치기 쉽습니다. 직접 사이드프로젝트를 하면서 제품을 만들다보면, 평소에는 몰랐던 다른 역할들을 어쩔 수 없이 수행하게 되고, 이것은 좀 더 큰 스케일에서 문제를 바라보는 시각을 길러줍니다.
Anthropic에서는 이 철학이 그대로 적용됩니다. 프로덕트 매니저도 코딩을 하고, 데이터 사이언티스트도 코딩을 합니다. 심지어 모든 직군이 "Member of Technical Staff"라는 동일한 직함을 사용합니다. 직함으로 역할을 구분하지 않고, 필요한 일을 필요한 사람이 하는 문화를 만들기 위해서입니다.
추천 도서: Functional Programming in Scala
"모든 사람에게 추천하고 싶은, 엔지니어로서 가장 큰 영향을 준 기술 서적은 '스칼라로 배우는 함수형 프로그래밍'입니다."
이 책은 폴 키우사노와 루나르 비야르드나손이 저술한 함수형 프로그래밍 입문서로, 개발자 커뮤니티에서 "레드 북(Red Book)"으로 불립니다. 보리스는 이 책이 코딩 문제에 대한 사고방식을 완전히 바꿔놓았다고 말합니다.
"Scala를 오늘날 사용할 일은 없을 수도 있지만, 이 책이 코딩 문제에 대한 사고방식을 가르치는 방식은 대부분의 사람들이 학교나 실무에서 배운 방식과 완전히 다릅니다. 코딩하는 방식이 완전히 바뀔 겁니다."
위임의 기술: High Output Management에서 배운 것
"앤디 그로브가 쓴 '하이 아웃풋 매니지먼트'라는 정말 좋은 책이 있습니다. 가장 지루하게 들리는 책이지만 최고입니다.
보리스는 이 책을 소개하며, 다음과 같이 말했습니다.
"자신이 하기 싫은 것을 위임하지 마세요. 자신이 하고 싶어하고 잘 아는 것을 위임하세요. 그래야 진행 상황을 모니터링하고 잘 진행되고 있는지 확인할 수 있습니다."
이 대목에서 정말 무릎을 탁 쳤습니다. 위임은 분업과는 다른데도, 저는 두 개념을 혼동했던 적이 많았던 것 같습니다. 서로 다른 두 전문가가 각자의 영역에서 협업하는 것이 분업이고, 시니어가 주니어에게 자신이 이미 잘 할 수 있는 일을 맡기는 게 위임인데, 내가 잘하는 것을 계속 내가 하려고 해서 주니어에게 성장의 기회를 충분히 주지 못했던 것은 아닐까 반성이 되었습니다.
기술적 의견 충돌 다루기
보리스는 시니어 엔지니어와의 기술적 의견 충돌을 경험했습니다. 데이터 모델 마이그레이션에 대해 시니어 엔지니어가 강하게 밀어붙인 결정이 채택되었고, 약 6개월에서 1년에 걸쳐 수백 개의 코드를 마이그레이션했습니다. 하지만 시간이 지난 뒤, 그 결정이 잘못되었음을 알게 되었고, 보리스는 시니어 엔지니어를 설득해서 그 결정을 되돌리도록 밀어붙였습니다.
흥미로운 점은 이 경험이 오히려 둘의 관계를 강화시켰다는 것입니다. 결정을 되돌린 시니어 엔지니어는 나중에 보리스의 승진을 지지하는 지지자가 되었습니다. 보리스는 이 상황에서의 핵심을 이렇게 설명합니다.
"먼저 신뢰를 얻어야 합니다. 처음에 한 것처럼 의견이 다르더라도 실행하겠다는 의지를 보여주는 것만큼 간단할 수 있습니다. 또한 좋은 기술적 판단력이 있다는 것을 보여줘야 합니다. 하지만 신뢰를 얻기 전까지는 그것을 할 수 없습니다."
Instagram으로의 이동
타이틀은 중요하지 않다
"레벨은 전혀 중요하지 않습니다. 매우 주니어인 사람이 그것보다 훨씬 높은 성과를 낼 수 있고, 매우 시니어인 사람이 끔찍한 결과를 낼 수 있습니다."
Meta에서는 모든 엔지니어의 직함이 "Software Engineer"였습니다. Anthropic에서는 한 발 더 나아가 엔지니어, PM, 디자이너 할 것 없이 모든 직군이 "Member of Technical Staff"라는 동일한 직함을 사용합니다. 직함이 없으면 신뢰를 직접 얻어야 합니다. 보리스는 이것이 오히려 건강한 방식이라고 말합니다:
"신뢰를 얻어야 합니다. 과거에 멋진 것을 했다고 해서 새로운 회사, 새로운 환경에서 권위를 가질 자격이 있는 것은 아닙니다."
Instagram의 "Unshipping" 문화
"앱에 기능만 추가하면 일부 사용자에게는 좋지만, 그 기능을 사용하지 않는 대부분의 사용자에게는 실제로 나쁩니다."
"Unshipping"은 Instagram에서 보리스가 배운 중요한 철학입니다. 화면은 한정된 자원이고, 모든 기능은 다른 기능과 그 공간을 두고 경쟁합니다. 기능을 계속 추가하기만 하면, 평균적인 사용자는 자신이 쓰지 않는 기능들로 가득 찬 복잡한 앱을 보게 됩니다.
Instagram의 해결책은 "Unshipping"이었습니다. 특정 사용률 기준을 충족하지 못하면 그 기능을 과감히 삭제합니다. 소수의 사용자는 화가 나겠지만, 대다수 사용자의 경험은 더 좋아집니다. 기능을 추가하는 것만큼 빼는 것도 중요하다는 교훈입니다.
Anthropic과 Claude Code
AI를 진지하게 생각하게 된 계기
"처음 ChatGPT를 사용했을 때, LLM은 마법 같았습니다. 지금 제 관점에서 LLM은 우리가 키우고 존재하게 하는 일종의 외계 생명체입니다. 단순한 기술이 아닙니다."
Boris는 SF 소설을 많이 읽는 사람으로서, AI가 잘못될 수 있는 많은 시나리오를 알고 있었습니다. 그래서 가장 작은 방식으로라도 AI가 올바른 방향으로 발전하는 데 기여하고 싶었습니다. Anthropic을 선택한 이유도 여기에 있습니다. 안전(Safety)이 단순한 규제나 세금이 아니라, 회사의 핵심 가치로 자리 잡고 있다는 것을 직접 경험했기 때문입니다.
Claude Code의 탄생
"오늘의 모델을 위해 만들지 마세요. 6개월 후의 모델을 위해 만드세요."
이것이 보리스의 매니저 벤이 준 조언이었습니다. Claude Code 초기에는 보리스 자신도 코드의 10% 정도만 Claude Code로 작성했습니다. 모델이 아직 충분히 뛰어나지 않았기 때문이죠. 하지만 Sonnet과 Opus 4가 출시되면서 상황이 완전히 바뀌었습니다. 제품이 실제로 작동하기 시작했고, 이제 Claude Code의 80-90%가 Claude Code 자체로 작성됩니다.
생산성에 미친 영향도 놀랍습니다. 회사를 운영해보신 분이라면 아래의 말이 얼마나 대단한 이야기인지 쉽게 이해하실 수 있을 것입니다.
"Anthropic의 직원 수가 2025년 한해동안 3배로 증가했음에도, Claude Code 덕분에 엔지니어당 생산성이 거의 70% 증가했습니다."
Vibe Coding에 대한 생각
"AI 코딩은 다른 모든 도구와 같은 도구입니다. 사용법을 배워야 합니다."
안드레이 카파시가 "바이브 코딩"의 단점에 대해 언급한 것에 대해, 보리스는 균형 잡힌 시각을 제시합니다. 핵심은 모델이 작성한 코드든 사람이 작성한 코드든 동일한 품질 기준을 적용하는 것입니다. 코드가 별로면 merge하지 않습니다. 그리고 상황에 따라 접근 방식을 달리합니다. 프로토타입이나 일회성 코드에는 바이브 코딩이 적합하지만, 유지보수가 필요한 코드는 모델과 페어링하면서 신중하게 작성합니다.
가장 중요한 팁은 이것입니다:
"모델에게 자신의 작업을 검증할 방법을 주세요. 브라우저 테스트든, 테스트 스위트든, 시뮬레이터든. 그러면 최종 결과물의 품질이 2-3배 향상됩니다."
생산성과 미래 전망
새로운 생산성 팁
"요즘 제 팁은 예전과 완전히 다릅니다. 요즘 팁은 Claude Code 사용법을 배우고, 여러 Claude를 병렬로 실행하는 방법을 배우는 것입니다."
보리스의 현재 워크플로우는 이렇습니다. 터미널에서 5개의 Claude Code 세션을 병렬로 실행하고, claude.ai에서 5-10개의 Claude를 추가로 실행합니다. 매일 아침 휴대폰에서 몇 개의 에이전트를 시작하고, 컴퓨터 앞에 앉으면 그 결과를 확인합니다. 6개월 전만 해도 이런 방식으로 코딩할 거라고 상상도 못 했을 거라고 합니다.
AI 코딩의 미래
"이 질문을 3개월 후나 6개월 후에 하면 제 대답은 완전히 달라질 겁니다. 6개월 후에는 답이 '이건 실제로 한 명의 엔지니어입니다'일 수도 있습니다."
보리스가 예전에 진행했던 Facebook Groups Comet 프로젝트를 예로 들어봅니다. 당시에는 12명의 엔지니어가 2년에 걸쳐 진행한 프로젝트였습니다. 지금이라면 5명의 엔지니어가 6개월이면 할 수 있을 거라고 추정합니다. 그리고 6개월 후에는 어쩌면 1명의 엔지니어로도 가능할지 모릅니다. 모델이 너무 빠르게 발전하고 있어서 예측 자체가 어렵다는 것이 그의 솔직한 고백입니다.
커리어 조언
"그냥 상식을 사용하세요. 대기업에서는 상식에서 벗어나게 하는 많은 것들이 있습니다. 잘못 정렬된 인센티브도 있고요. 자신을 믿고 상식(Common Sense)에 따라 행동하세요."
핵심 교훈 정리
보리스의 커리어에서 배울 수 있는 핵심 교훈들입니다.
첫째, 잠재 수요를 찾아야 합니다. 사용자에게 새로운 행동을 강요하지 말고, 이미 하고 있는 행동을 관찰하세요.
둘째, 제너럴리스트가 되세요. 코딩뿐 아니라 제품, 디자인, 사용자 리서치까지 관심을 넓히세요.
셋째, 사이드 프로젝트를 하세요. 자신의 문제를 해결하면 다른 사람의 문제도 해결됩니다.
넷째, 신뢰를 먼저 얻으세요. 기술적 의견 충돌 전에 신뢰 구축이 우선입니다.
다섯째, 미래를 위해 설계하세요. 오늘의 제약이 아닌 6개월 후의 가능성을 생각하세요.
여섯째, 검증 루프를 만드세요. AI에게 스스로 작업을 검증할 방법을 제공하면 품질이 크게 향상됩니다.
정리
보리스의 커리어 여정에 대해 들으면서 정말 공감이 많이 되었습니다. 저 스스로도 커리어를 프론트엔드 개발자로 시작했고, PHP와 jQuery를 다루다가 Angular, React를 거쳐왔기 때문에 정말 생각하는 게 비슷하다는 느낌을 많이 받았습니다. 특히, Redux 너무 복잡해서 처음에 이해하기 힘들었다는 얘기는 극공감을 했구요.
또한 저 스스로도 커리어를 시작한 이후로 한번도 사이드프로젝트를 쉬어본 적이 없는 입장에서 사이드프로젝트의 중요성을 강조하는 그의 입장에 완전히 공감했습니다. 결과적으로 성공하지는 못했지만 사이드프로젝트들은 항상 저에게 뭔가를 가르쳐줬습니다. 그리고 사이드프로젝트 그 자체가 아주 좋은 포트폴리오가 되서 사이드프로젝트를 하면서부터는 면접 합격하는 확률이 크게 올라갔죠.
왜냐하면, 면접에서 기술적인 질문들이 들어올 때 사이드프로젝트에서 고민했던 이야기를 할 수 있으니까요. 결국 상대 회사에서 사람을 뽑으려는 이유는 어떤 문제를 풀어주길 바라는 건데, 이미 비슷한 문제를 사이드프로젝트 레벨에서라도 풀어본 사람이라면 대화가 훨씬 잘 풀리기 마련이니까요. 필요하면 라이브 코딩이나 샘플 코드 제공도 즉석에서 가능하다는 점도 플러스였습니다.
제네럴리스트에 대한 이야기도 마찬가지입니다. 저는 스티브 잡스의 "우리 해적이 되자! (Let's Pirate!)"이라는 말을 좋아하는데요. 여기에 대해서는 여러가지 해석이 존재하지만, 제가 이 말을 좋아하는 이유는 다음과 같습니다.
해군과 달리 해적에게는 보급이 없습니다. 늘 인원도 부족하고 자원이 부족합니다. 그래서 모두가 모두의 일을 대신 할 수 있어야 하고, 문제를 풀때는 단순히 문제만 풀어서는 안되고 ROI가 잘 나오는 창의적인 방법을 찾아내야 합니다. 그래서 저는 프론트엔드 개발자로 커리어를 시작했지만, 팀에 필요하다고 하면, 기꺼이 벡엔드 개발자 역할을 수행했고, UX 디자이너가 됐고, DevOps 엔지니어가 되었습니다.
다른 역할을 수행하다보니 다른 역할의 고충도 더 잘 이해하게 되고, 커뮤니케이션도 더 잘 할 수 있게 되었습니다. 새롭게 접한 분야를 통해 저 자신의 적성도 발견하게 되었습니다.
보리스는 본인 스스로도 사이드프로젝트를 쉬지 않은 제네럴리스트이기 때문에, 본인이 같이 일하고 싶은 동료들도 그런 사람들을 선호한다고 말합니다. "그건 제 일이 아닌데요?"라는 자세로는 보리스의 팀에 합류하기는 쉽지 않을 거라는 이야기죠.
이번 보리스의 인터뷰를 보며, AI 시대가 원하는 인재는 "자율적"인 인재, 스스로 문제를 찾고 기꺼이 사이드프로젝트를 시작하는 인재임을 다시 한번 확인할 수 있었습니다. 그리고 Claude Code 같은 도구까지 능숙하게 사용한다면 이전과는 차원이 다른 임팩트를 만들어낼 수도 있겠죠.
그래서 이번 AI혁명은 가만히 있는 사람, 안전한 경계 안에 머무는 사람에게는 재앙이지만, 문제를 해결하는 사람, 경계를 넘나드는 사람에게는 로켓 부스터가 될 것이라고 생각합니다. 저 스스로도 최근 Claude Code Max 플랜을 사용하면서 이전과는 차원이 다른 생산성의 혜택을 보고 있고요, 이번 인터뷰를 통해서 Claude Code를 잘 사용할 수 있는 노하우도 몇 가지 배울 수 있었습니다.
이번 보리스의 인터뷰를 통해 독자 여러분들도 많은 인사이트 얻으셨길 바라며 이만 마칩니다. 감사합니다.
의견을 남겨주세요