이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

피오나 펑은 지금 엔지니어라는 직업을 가장 빠르게 바꾸고 있는 바로 그 도구를 만드는 팀을 이끌고 있어요. Anthropic에서 Claude Code와 Cowork의 엔지니어링·PM 조직 전체를 총괄하죠. 25년 넘게 엔지니어로 일했고, Microsoft에서 11년간 Visual Studio와 TypeScript를, Meta에서는 Facebook Marketplace(현재 연간 1,000억 달러 이상의 거래액을 만들어 내는 서비스)와 첫 VR·AR 안경, 그리고 Instagram의 인프라를 만들었어요.

얼마 전 Anthropic은 자사 엔지니어들이 2021~2025년 시기와 비교해 분기당 평균 8배 많은 코드를 출하한다는 그래프를 공개했는데, 몇 년간 평탄하던 선이 갑자기 위로 솟구치는 모양이었죠. 코딩이 더 이상 병목이 아닌 시대에 소프트웨어 팀이 어떻게 일하는지, 그 한복판에 있는 사람의 이야기를 들어봤어요.

IBM의 Vim에서 Claude Code까지, 25년의 변곡점들

Q. 25년 넘게 엔지니어로 살아오셨는데, 그 사이 사고방식을 크게 바꾼 순간들이 있었나요?

이렇게 과거를 돌아보는 거 좋아해요. 첫 시작은 IBM이었어요. DB2의 운영체제 서비스 팀에서 일했죠. 그때 저는 "스택에서 어려운 영역이 뭘까, 운영체제에 가까운 낮은 레벨로 갈수록 더 하드코어하고 더 많이 배울 수 있겠지"라고 생각했어요. 운 좋게 IBM 인턴십에 들어갔고요.

그런데 IBM에서 Microsoft로 옮길 때 큰 변화가 있었어요. IBM에서는 IDE 없이 주로 Vim과 터미널 디버깅으로 일했거든요. 그러다 Microsoft에 합류했는데, 제가 얼마나 순진했냐면 IDE라는 게 뭔지도 몰랐어요. 2000년대 초였는데, 그때는 팀을 골라서 들어가는 것도 아니었고요.

Q. Microsoft에는 어떻게 합류하게 되셨어요?

제가 그 자리를 얻은 것 자체가 참 감사한 일이었어요. 2000년에 닷컴 버블이 터졌거든요. 그래서 제 졸업 동기들 때는 많은 회사가 채용을 안 하거나 동결 상태였어요. 그런 와중에 Microsoft가 오퍼를 줬으니 얼마나 운이 좋았는지 몰라요. 그쪽에서 "당신은 Visual Studio 팀에서 일하게 될 거예요"라고 하는데, 저는 Visual Studio가 뭔지도 몰랐어요. 유닉스 학교 출신이었거든요. 그래서 "Visual Studio라는 이름을 보니, 이거 더 나은 그림판 프로그램인가요?"라고 물었어요. 매니저 표정이 "이게 무슨 소리지?" 하는 얼굴이었죠.

Q. 그 Visual Studio가 결국 커리어의 큰 부분이 됐죠?

맞아요. 첫 11년 커리어에서 제일 아꼈던 일이 됐어요. IDE라는 걸 처음 써본 게 그때였거든요. Visual Studio 팀에 합류해서 "와, 디버거가 있고, 중단점을 걸 수 있고, 멀티스레드 디버깅도 되는구나" 하는 걸 봤을 때, 그 단계적인 변화가 충격적이었어요.

제가 특히 좋아했던 건, 제가 Visual Studio 에디터 팀에 있었다는 점이에요. 그러니까 VS 에디터를 써서 VS 에디터를 만든 거죠. 제가 도그푸딩(자기 회사 제품을 직접 사용해 보는 것)에 빠진 것도 그때부터예요. 저 자신뿐 아니라 팀원들에게도 만족스러운 경험을 만들고 싶었거든요. 그 시절을 떠올려 보면, 소셜 미디어가 나오기 전이라 대부분의 엔지니어가 고객 피드백을 빠르게 듣기가 더 어려웠어요. 사용자 리서치 세션이나 고객 방문은 있었지만, 요즘처럼 빠른 피드백은 못 받았죠. 그런데 저는 운이 좋았어요. VS 팀원 모두가 VS를 손에 달고 쓰는 사람들이었으니까, 우리끼리 엄청나게 빠른 피드백을 주고받을 수 있었거든요.

Q. 소프트웨어를 CD에 담아 출하하던 시절도 겪으셨다고요. 그때와 지금은 '계획'의 의미가 어떻게 다른가요?

그때는 실제로 소프트웨어를 CD에 담아 매장 선반에 올렸어요. 그래서 마감이 진짜로 빡빡했죠. 제조 공정에 넘겨서 CD를 찍고, 그걸 선반에 올릴 준비가 됐는지 확실히 해야 했으니까요. 그러다 온라인으로 소프트웨어를 배포할 수 있게 된 게 또 하나의 큰 변화였어요.

여기서 흥미로운 지점이 있어요. 예전엔 엔지니어의 시간이 아주 귀한 자원이었어요. 동시에 CD 출하 같은 아주 단단한 마감도 있었고요. 그래서 주어진 시간을 최대한 잘 쓰려고 계획을 훨씬 많이 했어요. 그런데 지금 Claude Code와 Cowork에서 보이는 변화는, 코딩이 더 이상 병목이 아니라는 거예요. 그 8배 그래프가 보여주듯이요. 이제 엔지니어뿐 아니라 디자이너, PM까지 Claude Code 팀의 모두가 코드를 커밋해요. 더 많은 사람이, 게다가 서로 다른 직군이 코드를 올리는 데다 처리량까지 어마어마하니까, 이제는 "검증(verification)을 어떻게 할 것인가"가 새로운 화두가 됐어요.

AI에 완전히 적응한 팀은 어떻게 일할까

Q. 2026년의 'AI에 완전히 적응한' 소프트웨어 팀은 어떤 모습인가요?

역할의 경계가 흐려지면서, 모두가 '빌더'가 되는 쪽으로 가고 있어요. 제가 최근에 한 일도 그래요. 저는 우리 모든 레포(repo)에 접속하는 Claude Code 원격 세션을 하나 띄워 뒀어요. 이렇게 하면 모두가 무슨 작업을 하는지 훤히 들여다볼 수 있거든요. 이 세션은 우리 Slack 채널 전부와, 우리가 추적하는 모든 지표에도 접근할 수 있어요.

그래서 매달 "재밌는 거 해보자, 한번 돌아보자" 하면서 같이 해요. 제 화면을 공유하고 Claude Code 세션을 함께 돌리는 거죠. "이번 달 집중 영역이 뭐였지? 어떤 제품이 출시됐지? 시장 반응은 어땠지? 피드백 채널은 뭐였지?" 같은 걸 봐요. 예전엔 이런 세션을 그냥 PR이나 버그 수정을 만드는 데만 썼는데, 지금은 제가 지원하는 사람들과 대화를 나누게 해주는 도구로 쓰고 있어요.

Q. 그러니까 단순히 'PR을 빨리 찍어내는' 게 아니라, 매니징 기법으로 쓰신다는 거네요?

맞아요. 출하라는 행위 그 자체를 넘어서, "이게 시장에서 어떻게 됐지? 혹시 버그를 만들지는 않았나?" 같은 걸 보는 거예요. 제가 자주 하는 말이 "새로운 실수를 하라"예요. 실수해도 괜찮으니, 다만 늘 새로운 실수를 하자는 거죠. 그래야 계속 배우니까요. 실수를 0으로 만들겠다고 마음먹으면, 그건 충분히 빠르게 움직이지 않고 있거나 너무 조심하고 있다는 뜻일 수 있거든요.

그래서 Claude한테 "우리가 겪은 인시던트(장애)들을 죽 보고, 하나의 테마를 뽑아낼 수 있을까? 품질 측면에서 우리가 투자하면 좋을 영역은 어딜까? 빈틈이 생기는 핫스팟이 보이나?" 같은 걸 물어봐요. 1년 전만 해도 이런 통찰은 훨씬 더 수작업이었을 거예요. 그때는 못 했을 일이죠.

Q. 8배 많은 코드가 쏟아지는 가운데 품질을 지키는 또 다른 방법이 있을까요?

피드백 채널이 무척 중요해요. 예전 제 아침 루틴은, 커피 한 잔 들고 피드백 채널을 보면서 "만들 시간이 좀 있으면 내가 도울 수 있는 게 뭘까, 빈틈이 보이는 데가 어딜까" 골라내는 거였어요. 매일 아침 했던 일이죠. 그런데 한두 달 전에 '루틴(routines)'이라는 기능을 출시하면서 이게 완전히 바뀌었어요.

이제는 이 모든 걸 자동화하는 루틴을 하나 만들어 뒀어요. 예전엔 제가 직접 프롬프트를 짰다면, 루틴에서는 에이전트가 프롬프트를 대신 짜주는 느낌이에요. 예를 들면 "이 피드백 채널을 계속 지켜보면서 어떤 테마가 있는지 봐줘" 같은 거죠. 그러면 제가 아침에 일어났을 때 잘 정리된 요약이 있고, 심지어 제가 검토할 수 있는 PR까지 몇 개 준비돼 있어요.

Q. 그 피드백은 어디서 오는 건가요?

내부에서도 많이 오고, 이메일이나 여러 채널에서도 와요. 저희는 친구가 메시지를 보내거나, LinkedIn이나 소셜에서 피드백을 받으면 그걸 전부 Slack에 올려요. 물론 파트너십 쪽 채널도 있고요. 그래서 소스별로 여러 채널이 있어요. 들어오는 피드백이 너무 많아서, 그걸 따라잡으려면 Claude의 도움이 필요한 거예요.

Q. 코드 리뷰는 어떤가요? 더 빠르게, 그러면서도 자신 있게 출하하는 방법을 찾으셨나요?

생각해 보면 작년만 해도 Claude Code 리뷰라는 게 아예 없었어요. 그래서 인간 리뷰어가 아주 큰 병목이었죠. 깊은 전문성이 필요한 중요한 영역은 여전히 사람이 제대로 리뷰하도록 하고 있어요. 다만 도움이 되는 건, "좋은 상태가 어떤 모습인지"를 프레임워크로 만들어 저장소에 체크인해 두는 거예요. Claude는 검증할 프레임워크를 주면 정말 잘하거든요.

그러니까 스펙을 저장소에 체크인하고, 그 스펙을 코드와 함께 자주 최신 상태로 유지하는 거죠. "좋은 상태가 이렇다"는 기준을 저장소에 넣어 두면, Claude 코드 리뷰가 그게 여전히 의도대로 맞춰져 있는지 확인해 줘요.

Q. 테스트 주도 개발(TDD)의 진화 같은 거네요?

맞아요. TDD(Test-Driven Development)는 2000년대에 큰 화두였어요. 테스트를 먼저 쓰고, 그게 실패하는 걸 확인한 다음, 실제 코드를 짜는 거죠. 원리는 좋은데, 저 스스로도 좀 힘들어했어요. "브로콜리부터 먹어야 한다"는 느낌이랄까요. 저는 제품을 출하하고 만드는 데서 큰 짜릿함을 느끼는데, 테스트부터 써야 한다니 좀 그랬던 거죠.

그래서 재밌는 게, 제가 Claude Code로 처음 고친 버그가 있는데, Claude한테 "테스트 주도 개발을 하고 싶어. 테스트를 먼저 써주고, 그게 실패하는 걸 확인한 다음, 실제로 고치고, 이제 그 테스트가 통과하게 해줘"라고 부탁했어요. 예전엔 테스트를 만드는 게 어쩔 수 없이 내야 하는 세금 같았는데, 이제 그게 자동화된 거죠. 오래전부터 있던 원칙들을 다시 꺼내볼 수 있게 됐고, 모델이 더 많은 일을 대신해 주니까 오히려 그 원칙들이 더 효율적으로 돌아가는 거예요.

지금 우리가 뽑는 두 종류의 사람

Q. 지금 채용에서 어떤 사람을 찾으시나요?

크게 두 가지 프로필을 봐요. 하나는 제품 감각을 가진 창의적인 빌더, 다른 하나는 어려운 부분을 맡을 깊은 시스템 전문가예요.

깊은 전문성 쪽부터 말하면, 제가 Claude Code에 처음 합류했을 때 훌륭한 제품 제너럴리스트들은 많았는데, 시스템 배경을 가진 사람이 부족하다는 걸 깨달았어요. 그래서 시스템과 분산 시스템 전문성을 가진 사람들이 더 필요했죠. 모델은 뛰어나지만, 여전히 검증이 필요한 영역이 많거든요. 그래서 깊은 전문성이 필요한 곳에는 계속 투자해야 한다고 봐요.

다른 하나는 제품 감각을 가진 '드리머(dreamer)'예요. 어떤 제품에 진심으로 빠져서, 아이디어를 내고, 직접 만들고, 피드백을 보고, 반복하고, 다듬으면서 그 제품이 만족스러운 경험이 되도록 처음부터 끝까지 책임지는 사람이죠. 이 능력이 Claude Code 팀에서 큰 도움이 됐어요.

Q. '야망'이라는 단어가 떠오르는데요. 모든 게 가능해진 시대에, 그게 팀에서 어떻게 나타나나요?

천장이 올라간 거예요. 누구나 할 수 있는 일의 한계 자체가 높아졌어요. 어제 한 엔지니어와 이야기를 나눴는데, 원래 모바일 엔지니어가 아닌 분이었어요. 그런데 어떤 기능에 모바일 버전을 추가해야 했거든요. 보통은 "잠깐, 나는 안드로이드 전문가가 아닌데" 하고 멈추기 쉬워요. 그런데 그분이 "Claude 덕분에 이제 파트너가 생긴 셈이라, 모바일 화면에서도 이걸 할 수 있어요"라고 하더라고요.

예전 같으면 "그건 너무 어렵고 복잡해" 하고 넘어갔을 기능 아이디어를, 이제는 "아니, 그거 충분히 가능해. Claude Code한테 시키면 그냥 해줘" 하는 식으로 마음가짐이 바뀌는 거죠. 이론적으로는 모든 게 가능해졌으니, 이제는 "얼마나 크게, 얼마나 야심 차게 생각할 수 있느냐"의 문제가 된 거예요.

잘 적응하는 사람과 좌절하는 사람

Q. 잘 적응해서 잘나가는 엔지니어들의 공통점은 뭔가요?

성장 마인드셋이 정말 큰 도움이 돼요. 사실 AI 도구가 나오기 전부터 그랬어요. 저는 그걸 Microsoft에서 Meta로 옮길 때 제대로 배웠어요. 그 첫해에 "성장 마인드셋이 이런 거구나"를 처음 느꼈죠. 늘 배우는 자세, 그리고 나를 여기까지 데려온 것이 앞으로도 계속 통하지는 않는다는 걸 받아들이는 거예요.

이게 어려운 이유는, 우리 모두 지금까지 어떤 방식으로 일해서 여기까지 왔기 때문이에요. "지금까지 성공했는데, 그 성공의 방식을 바꾸라고요?"라는 말은 좀 무섭게 들리거든요. 그래서 늘 호기심을 갖고 배우려는 자세, 그 성장 마인드셋이 저뿐 아니라 잘하는 분들에게도 큰 힘이 됐어요.

Q. AI를 잘 쓰는 사람과 못 쓰는 사람 사이의 격차가 커지고 있어요. 소상공인을 돕는 데 애정이 크신 걸로 아는데, 이 문제를 어떻게 보세요?

이건 제가 정말 애정을 갖는 주제예요. 제가 어릴 때 홍콩에서 캐나다로 이민을 갔는데, 영어를 한마디도 못 했어요. 부모님은 늘 일하셔서, 할머니가 저를 돌보러 함께 오셨죠. 둘 다 영어를 못 했지만, 저는 학교에서 친구들과 말하며 영어를 배웠어요. 할머니에게는 낯선 나라에서 사는 게 무척 고립된 일이었어요. 그런데 어느 여름, 광둥어를 할 줄 아는 사장님이 운영하는 작은 털실 가게를 우연히 찾았어요. 그때부터 매주 그 가게에 갔고, 할머니는 거기서 뜨개질 모임을 찾으셨어요. 작은 동네 가게 하나가 멋진 공동체를 만들어 낸 거죠. 제가 소상공인을 이렇게 좋아하게 된 것도 그때부터예요.

Q. 그 애정이 Cowork 작업으로 이어진 건가요?

그러던 차에 제가 Cowork로 제 사업의 출장비 정산을 하게 됐는데, 정말 마법 같았어요. 제가 하기 싫어하는 일들을 Cowork가 다 해주는 거예요. 그 순간 "내 친구들, 소상공인들은 죽도록 열심히 일하는데, 때로는 아주 얇은 마진으로 운영하는데" 하는 생각이 들었어요. 친구들이 영수증 더미를 쌓아 놓고 인보이스와 정산만 붙잡고 앉아 있는 모습을 본 적이 많거든요. 아무도 그 일을 좋아하지 않잖아요. 그래서 친구 몇 명의 온보딩을 도왔어요.

그게 보람 있었던 게, 제가 PDF랑 인보이스 처리에만 꽂혀 있었는데 친구들은 제가 생각도 못 한 방식으로 Cowork를 쓰더라고요. 식당 두 곳을 운영하는 한 친구는 "내 문서 폴더가 잡동사니 서랍이 됐어. 메뉴판이 몇 개 있는 건 아는데 못 찾겠어"라고 했어요. 그래서 Cowork에 폴더 접근 권한을 주고 메뉴를 찾아냈죠. 그런데 그 친구는 한 발 더 나가서 "현지 손님과 관광객 모두에게 합리적인 가격을 유지하고 싶어"라며, "내 요리 스타일로 이 지역의 비교 대상을 찾아봐줘"라고 하더라고요. 그러자 멋진 시장 분석 같은 게 나왔어요. 매번 제가 뭔가를 배워요.

Q. 그 격차를 어떻게 좁힐 수 있을까요? "AI 싫어, 그럴 시간 없어" 하는 사람들에게요.

AI에 익숙한 분들이라면, 주변이나 가족 중에 그렇지 않은 사람에게 이렇게 시작해 보세요. "AI 도구로 내 삶에 정말 의미 있는 변화를 준 게 뭐였더라"를 떠올려서, 그걸 대화의 물꼬로 삼는 거예요. 저한테 AI는 도구거든요. 빛과 어둠으로 비유하면, 저는 좌절스러운 부분(어둠)도 충분히 이해해요. 하지만 동시에 "아는 게 힘"이라고 느껴요. 도구 쓰는 법을 배워 두면 그게 빛이 될 수 있으니까요.

처음 친구들에게 다가갈 때 저도 좀 어색했어요. 평소에 제 일 얘기를 잘 안 하거든요. "내가 AI 쪽 일을 하는데, Cowork로 뭘 할 수 있는지 보여줘도 될까?" 하고 운을 떼는 게 부자연스럽기도 했죠. 그런데 결국 같이 정말 재밌게 했어요. 그러니 커뮤니티 구성원이든, 좋아하는 동네 가게든, 누군가에게 손을 내밀어 AI가 어떤 도움을 줄 수 있는지 보여주는 일을 함께 해주셨으면 좋겠어요. 지식을 계속 나누지 않으면 격차가 점점 더 벌어질까 봐 걱정되거든요.

잠재 수요를 어떻게 발견하나

Q. Anthropic은 코딩이나 Cowork처럼 큰 기회를 다른 곳보다 먼저 발견해 왔어요. 비결이 있나요?

다른 연구소에서 일해본 적이 없어서 비교는 못 하지만, 우리가 보는 건 '잠재 수요(latent demand)'예요. 코딩은 운이 좋았어요. Anthropic 직원 상당수가 우리 첫 고객이었으니까, 아주 빠른 피드백을 주고받을 수 있었거든요.

Cowork도 그렇게 나왔어요. 코더가 아닌 사람들이 Claude Code를 쓰고 있다는 걸 알아챘거든요. "그 경험을 더 좋게 만들 수 있을까?" 하면서 시작된 거죠. 사실 이건 Anthropic 밖에서, 제가 거쳐온 모든 제품에서도 통했던 방식이에요. 그리고 앞서 말한 소상공인 친구들을 몇 번 방문한 뒤에, 우리는 '소상공인을 위한 Claude(Claude for Small Business)'를 출시했어요. 제 아이디어는 전혀 아니었어요. 다만 제가 친구들과 작업할 때 그들이 "이 플러그인 있어? 저 플러그인 있어?" 하고 물으면 일일이 찾아줘야 했는데, 이제는 Cowork 안에서 토글 하나로 그게 다 묶여 있어요.

Q. 잠재 수요란 결국 뭔가요?

예상하지 못한, 혹은 막 떠오르는 행동을 가까이서 지켜보는 거예요. 그리고 거기에 가설을 세우는 거죠. 사람들이 뭔가를 되게 하려고 온갖 번거로움을 무릅쓰는 모습이 보이면, 그걸 훨씬 매끄럽고 더 나은 경험으로 만들어 줄 수 있지 않을까, 하고요. 소프트웨어를 만들다 보면 고객은 늘 제가 의도하지 않은 방식으로 제품을 써요. 좋은 쪽으로든 나쁜 쪽으로든요. 그래서 가장 좋은 방법은 계속 반복하고, 배우고, 피드백에 가까이 머무는 거예요.

비동기로, 그리고 에이전트 함대로

Q. 엔지니어링의 다음 프론티어는 뭐라고 보세요?

비동기(asynchronous), 즉 동시에 옆에서 기다리지 않아도 되는 방식으로 가고 있어요. 그래서 루틴이 흥미로운 거예요. 예전엔 제가 프롬프트 하나를 던지고 그 결과를 동기적으로 기다렸어요. 그러다 여러 프롬프트를 비동기로 따로 던지기 시작했고요. 그런데 이제는 그 프롬프트들을 대신 만들어 주는 루틴을 만들 수 있어요. 추상화 수준이 한 단계씩 계속 위로 올라가는 거죠.

Q. 루틴이 정확히 어떻게 작동하는 건가요?

예를 들어 예전엔 아침마다 커피를 들고 "이 Slack 채널 좀 봐줘" 하던 일을, 이제는 매일 정해진 시간에 자동으로 실행되는 루틴으로 만들어요. 그리고 그 루틴이 제 대신 에이전트를 띄워서 일을 시켜요. 예전에도 크론 잡으로 자동화는 할 수 있었지만, 이제는 "이 피드백을 보고, 이런 버그가 보이면 다듬을 수 있는 수정안을 만들어줘" 하면 에이전트가 가서 작업을 하고, 제가 일어나면 검토할 PR이 준비돼 있어요.

그러니까 매니저로서 매일 하던 일들, "프로젝트가 어떻게 돼가지? 뭐가 뒤처졌지? 뭘 풀어줘야 하지? 누가 힘들어하지? 어떤 걸 다듬어야 하지?" 같은 걸 루틴으로 써두고, Claude가 그걸 대신 하게 한 다음, "여기 제가 한 일과 검토할 것들이 있어요"를 보여주는 거예요. 검증이 충분히 잘 되면, 어떤 부분은 "그냥 알아서 해" 하고 더 큰 자율성을 주기도 하죠.

Q. 그렇게 여러 에이전트를 비동기로 돌리면, 오히려 정신없지 않나요?

루틴과 비동기 작업이 늘면서 '컨텍스트 스위칭' 부하가 커지고 있어요. 저도 이것저것 띄워 놓고 보니 전환 비용이 높아지더라고요. 흥미로운 건, 예전엔 코딩 집중 시간을 따로 잡아 뒀는데, 이제는 비동기 에이전트로 더 많이 전환할 수 있게 되니까 오히려 제가 띄워 놓은 비동기 작업들을 따라잡을 집중 시간을 다시 블록해 둬야 하더라고요. 20개의 에이전트가 돌고 있으면 끝없이 확인하고 검토해야 하고, 내가 뭘 하고 있었는지 다시 떠올려야 하니까요. 이건 아직 못 풀었어요.

Q. 요즘 '주도성(agency)'이라는 단어가 많이 나오는데, 어떻게 보세요?

그 단어, 우리 Claude Code와 Cowork 팀이 특히 중요하게 여기는 거예요. "여기 문제가 있어"라고 하면 팀의 모두가 그 문제를 어떻게 풀지 아이디어를 내요. 높은 주도성이죠. 그런데 우리는 높은 주도성과 함께 높은 책임(accountability)을 둬요. 사람들에게 자유롭게 만들 자유를 주되, "그럼 그것에 대한 책임은 뭐지? 풀려는 문제의 가설은 뭐지?"를 함께 묻는 거예요. 주도성과 책임이라는 같은 동전의 양면이 우리 팀에 잘 맞았어요.

Q. 한편으로는 'ROI를 따져보자'는 분위기도 생겼죠. 생산성을 어떻게 측정하는지 배우신 게 있나요?

엔지니어 생산성은 정말 매력적인 주제예요. 처음엔 코드 라인 수로 시작했어요. 그게 처리량이니까요. 그런데 어떤 엔지니어가 라인 수가 엄청 많길래 봤더니, 그냥 라이브러리를 가져다 옮긴 거였어요. 그럼 "의미 있는 라인 수일까?" 싶죠. 또 프레임워크를 업데이트해서 코드를 더 적게 생성하는데 결과물은 같은 경우도 있고요. 그래서 "PR을 처리하기까지 걸린 시간"으로도 봤어요.

어떤 지표를 쓰든, 제 조언은 "그 결과물(output)이 진짜 원하는 성과(outcome)로 이어지는가"를 보라는 거예요. 토큰을 최대한 많이 쓰는 것(token maxing)도 예전의 코드 라인 수와 비슷한 함정이에요. 제가 좋아하는 말이 "움직임을 진전으로 착각하지 말라"는 거예요. 도구 사용량을 재면 행동을 재는 거지만, 그게 최종 성과를 만드는지는 별개거든요. 그래서 저는 "우리가 풀려는 문제가 뭐지? 그걸 측정하는 좋은 방법이 뭐지?"로 줌아웃해서 봐요.

지표 외에는, 시니어 엔지니어들과의 청취 투어(listening tour)를 정말 권해요. 뭐가 되고 뭐가 안 되는지, 어떻게 더 좋게 만들 수 있는지를 직접 듣는 거죠. 그들이 그걸 팀 전체로 확산시켜 주거든요.

Q. 지표만 보다가 본질을 놓친 경험도 있나요?

초기 Facebook Marketplace 시절 이야기를 할게요. 우리는 지역별로 출시하면서, 확장 전에 만족스러운 제품을 만들고 싶었어요. 초기에 주시한 지표가 '판매자 수'였죠. 그런데 첫 지역 출시 후 보니, 그 지역은 판매자 수는 적은데 사람들이 찾는 물건은 잘 찾고 있었어요. 우리가 원한 건 바로 그거였거든요. 사람들이 필요한 물건을 찾게 돕는 것요. 알고 보니 그 지역은 판매자 수는 적지만 '파워셀러'들이 있었던 거예요. 원래 확장 기준이 '판매자 수'였는데, 그게 파워셀러를 반영하지 못했던 거죠. 그래서 지표를 바꿨어요.

그게 제 조언이에요. 생산성이든 제품이든, 어떤 지표든 한쪽만 보고 맹목적으로 따라가지 않도록 늘 살피세요. 상황이 워낙 빠르게 변하니까, 지표 자체도 조정이 필요할 때가 있어요. 

나쁜 것과 슬픈 것: 품질을 보는 프레임

Q. 속도와 품질을 어떻게 균형 잡으세요?

선제적 품질(proactive quality)에 신경 써요. 특히 핵심 경험이 뭔지 정하고, 더 일찍 품질 문제를 감지하는 거죠. 그래서 우리가 만든 게 "나쁜 것(bad)과 슬픈 것(sad)"이라는 개념이에요.

'나쁜 것'은 회복 불가능한 아주 심각한 오류예요. '슬픈 것'은 고통스럽지만 회복 가능한 지점이고요. 흥미로운 건, '슬픈 것'이 쌓이면 결국 '나쁜 것'으로 이어질 수 있다는 거예요. 여러 제품 화면을 다룰 때는 "이 숫자가 좋은 건가 나쁜 건가"를 판단하기가 어려운데, 성능이나 안정성 수치를 그대로 보는 대신 "우리가 나쁜 경험이라고 생각하는 게 뭔지"에 대한 프레임워크를 갖는 게 도움이 됐어요.

Q. 구체적으로 어떤 걸 '나쁜 것'과 '슬픈 것'으로 보나요?

각 팀에 자율성을 줘요. '나쁜 것'은 회복 불가능한 심각한 오류라는 큰 틀만 정하고, 자기 영역에서 무엇이 나쁜 것이고 무엇이 슬픈 것인지는 팀이 정하게 해요. 예를 들어 CLI에서는 크래시(crash)가 '나쁜 것'이에요. 작업을 잃으니까요. 반면 화면이 깜빡이는 건 '슬픈 것'일 수 있죠. 회복은 가능하니까요.

예전엔 화면마다 대시보드가 따로 있어서 "전체 경험의 테마가 뭐지?"로 줌아웃하기가 어려웠어요. 그래서 각 팀에 무엇이 나쁜 것이고 슬픈 것인지, 그리고 어떤 목표를 잡을지에 대한 높은 자율성을 줬어요.

Q. 사용자가 욕하는 횟수를 세는 대시보드도 있다고 들었어요.

맞아요. 작년 9월쯤 우리 모두가 사용자들의 좌절을 느끼고 있었는데, 팀의 한 엔지니어가 "욕설을 추적해 보면 어떨까요?"라고 제안했어요. 제가 "정말 좋은 아이디어다" 했죠. 평가(eval)가 어려운 이유가 바로 이 사용자 경험 때문이에요. 정확한지뿐 아니라, 만족스럽고 덜 좌절스러운 경험인지를 봐야 하거든요. 욕설 대시보드는 그걸 보는 재밌는 방법이에요.

매니저도 코드를 짠다

Q. 모든 매니저가 IC(개별 기여자)로 시작하게 하신다고요. 왜 그게 중요한가요?

리더가 사람을 지원하는 무거운 책임을 지기 전에, 먼저 IC로서 코드와 코드베이스, 제품에 깊이 파고들 메이커 시간(maker time)을 주는 게 중요하다고 봤어요. 새 팀에 온 매니저는 "관리해야지" 하면서 바로 매니저 도구함을 꺼내 들기 쉬워요. 그런데 그걸 먼저 걱정하지 않고, 엔지니어이자 팀원으로서 어떤 경험인지를 배울 시간을 주면, 팀과 좋은 라포(rapport, 신뢰 관계)가 쌓여요.

제가 하는 PR도 사실 뭘 고치느냐가 중요한 게 아니에요. 매일 제품을 직접 쓰면서 흐름 속에 머무르는 게 핵심이에요. Cowork와 Claude Code는 변화가 너무 빨라서, 대시보드를 다 본다 해도 매일 제품을 직접 끼고 쓰지 않으면 감을 잃거든요.

Q. Meta에서는 500명 조직을 이끄셨는데, Anthropic에서는 IC로 시작하셨어요.

Meta에서도 사실 매니저로 면접을 봤지만, 적어도 첫 분기는 IC였어요. Meta 엔지니어가 된다는 게 어떤 건지 직접 배우고 싶었거든요. 그 전엔 Microsoft에서 엔지니어링을 익혀서 그쪽 코드베이스와 도구, 언어는 다 알았으니까요.

제가 마지막으로 프로덕션 소프트웨어를 출하한 게 아마 2017년쯤일 거예요. 그동안은 뭔가를 망칠까 봐 무서웠어요. 버그를 내거나 제대로 검증하지 못해서 남의 시간을 낭비할까 봐요. 그런데 Claude Code에 온 첫 주에, 평소처럼 엔지니어들 만나서 커피 사주려다가 "잠깐, Claude한테 물어보자" 했어요. Claude가 정말 좋은 온보딩 친구였어요. 코드베이스에 대해 궁금한 걸 물어봤고, 자동 테스트도 도와줬고요. 저는 수동 테스트도 하고 싶어서 "모든 경우를 다 커버하려면 어떻게 수동으로 테스트하면 될까?"를 물었어요. 그게 자신감을 줘서 다시 PR을 출하할 수 있게 됐죠. 매니저로 오래 일하던 친구들이 "Claude 덕분에 다시 코드를 짜고 있어"라고 연락해 오기도 해요.

Q. 엔지니어들이 코드를 직접 안 짜면서 실력이 퇴화할까 걱정되진 않으세요?

팀에서도 이 얘기를 좀 해요. Boris(Boris Cherny, Claude Code 초기 개발자)는 초창기에 코드를 손으로 직접 짰고, 지금은 안 짜지만 그때 코드베이스에 있으면서 지식을 쌓았어요. 그래서 합류하는 엔지니어들에게도 "어떤 작업을 하든 아키텍처나 변경 사항에 대한 이해는 꼭 챙기라"고 해요. 믿되 검증한다(trust but verify)는 거죠.

제가 메타포로 쓰는 건 "한 단계 더 파고들기(double-click)"예요. 내가 의존하는 계층에 대해 늘 한 번 더 깊이 들어가 보는 거예요. 그래야 그 의존성이 바뀔 때 더 잘 알아챌 수 있거든요. 언젠가는 이게 중요하지 않게 될지도 모르지만, 지금의 속도에서는 여전히 그 이해가 필요하다고 봐요.

일자리의 미래, 그리고 다음 세대

Q. AI가 엔지니어를 덜 필요하게 만들 것 같은데, 오히려 다들 엔지니어를 미친 듯이 뽑고 있어요. 어디로 가고 있다고 보세요?

솔직히 취약한 부분을 하나 나눌게요. 다음 세대를 어떻게 키울지가 정말 큰 고민이에요. 제가 엔지니어가 된 경로 자체가 지금과 너무 다르거든요. 학교를 졸업했을 때 그 과정을 어떻게 빨리 감기 해줄 수 있을까요. 그래도 중요한 건, 의존하는 계층에 대해 한 단계 더 파고드는 그 이해는 여전히 갖춰야 한다는 거예요.

저는 소프트웨어 엔지니어링이 펠로우십이나 도제(apprenticeship) 프로그램 쪽으로 가지 않을까 생각해요. 인턴십은 보통 3개월에 작은 프로젝트였는데, 우리 모두가 얻었던 인생 경험 같은 걸 다음 세대 빌더들에게 어떻게 압축해서 전할 수 있을지가 큰 물음이에요. 어쩌면 중요하지 않게 될 수도 있지만요.

Q. 코드를 한 번도 안 봐도 된다면, 새 엔지니어가 인프라나 메모리 할당 같은 기초를 깊이 이해할 동기가 있을까요?

모델이 충분히 좋아지면 중요하지 않게 될 수도 있어요. 하지만 저는 그 '한 단계 더 파고들기'에, 제품이나 시스템을 개선할 기회가 숨어 있다고 봐요. 다만 그걸 수년간 코드를 타이핑하면서 배울 필요는 없을지도 몰라요.

제 예전 매니저 한 분은 펀치카드로 엔지니어링을 시작한 분이에요. 그런데 요즘 Claude Code로 만든 것들을 저한테 신나서 메시지로 보내요. 펀치카드로 시작한 커리어와 지금은 완전히 다르잖아요. 그러니 우리가 생각해 볼 건, "무엇이 여전히 중요하게 남고, 무엇의 중요도가 바뀌는가"인 것 같아요. 추상화 레이어가 어셈블리, 바이너리처럼 계속 위로 올라가는 거예요. 이제는 코드를 직접 안 봐도 되는, 프롬프트라는 새 추상화 레이어가 생긴 거죠.

Q. 오래 일한 엔지니어일수록 이 변화를 받아들이기 어려울 텐데, 어떻게 적응하셨나요?

변화 속도가 너무 빠르다는 게 핵심이에요. 제가 처음 Claude를 써본 게 아마 Sonnet 3.5나 3.6쯤이었는데, 그때는 옆에서 실수도 좀 했어요. "뭐 하는 거야" 싶었죠. 그때 AI 도구를 거부하던 엔지니어들은 "거봐, 이런 실수를 하잖아"라고 했어요. 그런데 그 기하급수적인 개선 속도를 이해하기가 어려웠던 거예요.

그래서 제가 배우는 것도, 예전에 Claude가 충분치 않아서 자동화하려다 안 됐던 게 있다면, 다음 모델에서는 될 수도 있으니 다시 시도해 볼 가치가 있다는 거예요. 안 됐던 것들도 다시 들여다볼 만해요. 이제 새 역량이 생겼을 수 있으니까요.

더 이상 쓸모없어진 프로세스를 죽이기

Q. 마지막으로, 다른 팀에 줄 만한 실용적인 조언이 있다면요?

Claude Code와 Cowork 팀 문화의 큰 축 하나가, "더 이상 우리에게 도움이 되지 않는 프로세스를 죽일 명시적 권한"이에요. 그러니 자기가 하기 싫거나, 잡음이 많거나, 너무 수작업이라 비용이 큰 프로세스를 하나 골라서 먼저 물어보세요. "이게 아직 제 목적을 다하고 있나?"

제 첫 큰 깨달음이 그거였어요. Claude Code에 막 합류했을 때 "6개월 로드맵 문서를 만들어 보자, 대신 아주 가볍게" 했어요. 정렬을 맞추고 대화를 시작하는 데는 좋은 운동이었어요. 그런데 3개월쯤 지나서 "잠깐, 우리가 이걸 아직 참고하고 있나?" 싶더라고요. 너무 많은 게 바뀌어서요.

Q. 그래서 지금은 계획을 어떻게 하세요?

지금은 '적시 계획(JIT, Just-In-Time planning)'이라고 불러요. 6개월은 너무 길었거든요. 그래서 한 달 단위로 아주 가볍게 해요. 문서도 없어요. 그냥 작은 스프레드시트에 무엇이 중요한지 정렬하는 정도죠. 어떤 프로젝트는 한 달이 넘게 걸리지만, 매주 빠르게 "이게 여전히 이번 달 우선순위가 맞지? 좋아" 정도로 점검해요. 6개월마다 팀 전체를 모아서 큰 테마는 잡되, 판이 워낙 빨리 바뀌니까 계속 흐름을 짚는 게 핵심이에요.

스프레드시트에 항목을 많이 두지도 않아요. 최대한 집중하려고 하죠. "이게 우리가 생각하는 최우선순위야"를 공유하면, 그 우선순위 안에서 각자가 어떻게 기여할지를 정해요. 그게 주도성이고요. 그리고 저는 이것마저도 "어떻게 더 자동화할 수 있을까"를 고민해요. 누군가 스프레드시트를 업데이트하는 게 또 다른 세금처럼 느껴지는 걸 절대 원치 않거든요. 그래서 늘 스스로 물어요. 이 프로세스가 아직 제 목적을 다하고 있나? 분야가 이렇게 빨리 변하고 있으니까요.

소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]