AI 시대 엔지니어링 팀 구축: 세계에서 가장 AI에 몰입한 팀의 운영 비결

핵심 요약

분기당 코드 8배 증대: 2021년 대비 2025년 앤트로픽 엔지니어들의 생산성이 급증
코딩은 더 이상 병목: AI 도구로 인해 엔지니어의 역할과 책임감이 근본적으로 변화
높은 자율성 = 높은 책임감: 새로운 엔지니어링 팀 문화의 핵심 원칙
도그푸딩의 중요성: 리더와 엔지니어가 직접 제품을 사용해야 진정한 품질 보장 가능
비동기 에이전트 작업: 루틴과 자동화로 매니저의 업무 방식 완전히 재정의
역할의 모호화: PM, 디자이너, 데이터 과학자까지 모두가 '빌더'로 변신
팀 문화 유지의 어려움: 빠른 성장 속에서 문화를 살아 숨 쉬는 실체로 유지해야 함

AI 도구가 엔지니어링을 완전히 바꾸다

앤트로픽의 엔지니어링 팀에서 일어나는 변화는 소프트웨어 역사에서 전례 없는 수준입니다. 2021년부터 2025년까지 불과 4년 만에 분기당 평균 8배나 많은 코드를 배포하고 있다는 사실은 단순한 숫자가 아닙니다. 이는 엔지니어링이라는 직업 자체가 어떻게 변하고 있는지를 보여주는 명확한 신호입니다.

과거 25년간 소프트웨어 엔지니어로 일해온 피오나 펑은 이러한 변화를 가장 가까운 거리에서 목격하고 있습니다. IBM에서 Vim과 터미널 디버깅으로 시작한 그녀의 경력은 Microsoft의 Visual Studio 시대를 거쳐, 현재 Claude Code를 활용한 완전히 새로운 개발 패러다임까지 도달했습니다.

코딩은 더 이상 병목이 아닙니다. 이것이 의미하는 바는 깊습니다. 예전에는 "우리가 엔지니어링 리소스가 충분한가?"라는 질문이 회사의 성장을 결정했습니다. 지금은 다릅니다. "우리가 얼마나 야심 차게 생각할 수 있는가?"가 새로운 질문입니다. 이론적으로 모든 것이 가능해졌기 때문입니다.

하지만 이 혁명적인 변화는 동시에 새로운 문제를 야기합니다. 누구나 코드를 작성할 수 있게 되면서 검증 문제가 부각됩니다. 품질을 어떻게 보장할 것인가? 출시된 모든 것이 정말 필요한 것인가? 사용자에게 가치를 제공하는가? 이러한 질문들이 앤트로픽 팀에서 매일 고민되는 현안입니다.

높은 자율성과 높은 책임감의 동전 양면

앤트로픽 팀이 채택한 가장 핵심적인 원칙은 "높은 자율성에는 높은 책임감도 따른다" 는 것입니다. 이것은 단순한 구호가 아니라 조직 문화의 뿌리입니다.

엔지니어에게 코딩할 자유를 준다는 것은 좋습니다. 하지만 그 자유와 함께 반드시 따라와야 할 것이 있습니다: "당신이 해결하려는 가설은 무엇인가?"라는 질문입니다. 단순히 기능을 구현하는 것이 아니라, 왜 이 기능이 필요한지, 사용자에게 어떤 가치를 주는지를 명확히 해야 한다는 뜻입니다.

이 원칙이 실제로 어떻게 작동하는지 살펴보면, Claude Code 팀의 일일 루틴이 가장 좋은 예시입니다. 피오나는 아침마다 커피를 마시면서 피드백 채널을 확인합니다. 예전에는 이것이 단순히 정보 수집이었다면, 이제는 Claude의 도움을 받아 자동화됩니다.

Claude는 피드백 채널을 모니터링하고, 주요 이슈를 분류하고, 심지어 개선 사항을 담은 PR(Pull Request)까지 준비해줍니다. 피오나는 잠에서 깨어나 이러한 정보를 검토하고, 필요하면 승인하고, 그렇지 않으면 피드백을 제공합니다. 이것이 바로 "높은 책임감"이 작동하는 방식입니다. 자동화가 많아질수록, 리더의 검증과 최종 판단이 더욱 중요해집니다.

엔지니어들도 마찬가지입니다. 보리스 체르니의 사례처럼, 예전에는 "이거 만들기 어렵고 복잡해요"라고 말하던 엔지니어들이 이제는 "아니요, Claude에게 시키면 가능합니다"라고 말합니다. 이것은 단순한 태도 변화가 아니라, 야망의 수준이 근본적으로 달라졌다 는 의미입니다.

더 이상 "할 수 있는 일의 한계"를 먼저 생각하지 않습니다. 대신 "어디까지 야심 차게 갈 수 있을까?"를 먼저 생각합니다. 이것이 새로운 세대 엔지니어를 만드는 방식입니다.

리더의 역할 재정의: 검증, 도그푸딩, 그리고 제품 감각

전통적인 엔지니어링 리더라면 지표를 확인하고 팀을 관리하며 회의를 주도하는 일로 바쁠 것입니다. 하지만 피오나의 접근 방식은 확실히 다릅니다. 그녀는 매일 제품을 직접 사용 합니다.

Meta에서 500명 규모의 조직을 감독하던 그녀가 Anthropic에 합류했을 때, 처음 몇 개월은 개별 기여자(IC) 역할을 했습니다. 이것은 의도적인 선택이었습니다. 코드베이스를 이해하고, 팀원들과 신뢰를 구축하고, 가장 중요하게는 제품을 사용자 입장에서 경험 하기 위함이었습니다.

Meta의 마켓플레이스를 개발할 때 그녀는 직접 MacBook Air를 팔아보려고 했습니다. 마켓플레이스라는 플랫폼에서 판매자로서의 경험을 얻기 위함이었습니다. 그 과정에서 새로운 형태의 사기 수법을 발견했고, 이는 제품 개선으로 이어졌습니다. 데이터 분석만으로는 포착할 수 없었던 문제였습니다.

도그푸딩(Dogfooding), 즉 자신이 만든 제품을 직접 사용하는 것이 리더에게 왜 이렇게 중요할까요? 그 이유는 간단합니다: 사용자의 입장에서 발견되는 문제 는 데이터에는 나타나지 않기 때문입니다.

라틴 아메리카에서 마켓플레이스를 출시했을 때도 마찬가지였습니다. 지표상으로는 특정 지역의 성과가 좋지 않았지만, 직접 현지 안드로이드 폰을 사용해본 피오나는 즉시 원인을 파악했습니다. LTE 연결이 느려서 피드가 제대로 로드되지 않았던 것입니다. 이것은 일화(anecdote)가 데이터(data)를 이기는 순간 이었습니다.

이런 경험이 쌓이면서 피오나는 팀에도 같은 원칙을 강조합니다: "제품과 함께 살고 숨 쉬어야 한다. 그것이 리더로서 팀을 가장 잘 지원하는 방법이다." 이것이 Claude Code 팀이 매월 함께 회의실에 앉아 지난달의 작업을 화면 공유하며 검토하는 이유입니다. 출시된 모든 것을 파악하고, 무엇이 잘되고 무엇이 문제인지 직접 확인하기 위함입니다.

비동기 에이전트 업무의 시대로의 전환

과거의 엔지니어링은 동기식(synchronous) 이었습니다. 문제가 생기면 팀을 모아 함께 해결했고, 코드 리뷰를 받으려면 리뷰어를 기다려야 했습니다. 하지만 지금 앤트로픽에서는 새로운 패러다임으로 전환하고 있습니다: 비동기식(asynchronous) 에이전트 업무.

피오나가 도입한 "루틴(Routines)"이라는 개념이 바로 이것을 가능하게 합니다. 루틴은 크론 작업(cron job)처럼 정해진 시간에 실행되는 자동화된 프로세스입니다. 하지만 단순한 자동화가 아닙니다.

예를 들어, 매일 아침 특정 시간에 다음과 같은 일이 자동으로 일어난다고 상상해보세요:

Claude가 모든 피드백 채널을 분석합니다
버그와 기회를 식별합니다
개선안을 제안합니다
심지어 수정 코드까지 작성합니다
이 모든 것을 PR로 만들어 피오나가 검토하도록 준비합니다

피오나가 아침에 눈을 뜨면, 검토할 준비가 된 PR들이 기다리고 있습니다. 이것이 더 높은 추상화 수준 입니다. 예전에는 사람이 직접 해야 했던 것이 이제는 에이전트가 준비해주고, 사람은 최종 검증만 합니다.

이런 비동기식 업무 방식으로의 전환은 동시에 새로운 도전을 만듭니다: 컨텍스트 전환(context switching) 의 증가입니다.

과거에는 엔지니어가 깊은 집중 시간을 확보해 몰입 상태에 들어갈 수 있었습니다. 하지만 이제는 수많은 비동기 작업이 요청되고 있습니다. 이메일, 메시지, PR, 자동화된 알림들... 모두가 주의를 요청합니다.

흥미롭게도, 피오나는 이 문제에 대해 아직 완벽한 해결책을 찾지 못했다고 인정합니다. 이것은 미해결 질문 입니다. 우리가 더 많은 일을 비동기적으로 자동화할수록, 리더와 엔지니어들은 더 많은 검증 작업에 시간을 써야 합니다. 개별 집중 시간을 어떻게 보호할 것인가? 이것이 AI 시대 엔지니어링 팀이 직면한 새로운 난제입니다.

코드 리뷰의 자동화: 검증의 새로운 표준 세우기

전통적으로 코드 리뷰는 엔지니어링 팀의 가장 큰 병목이었습니다. 베테랑 개발자들이 주니어 개발자들의 코드를 검토하는 데 수일이 소요될 수 있었습니다. 하지만 이제는 Claude Code Review 라는 새로운 방식이 등장했습니다.

이 방식의 핵심은 명확한 "스펙(specification)"을 만드는 것입니다. 예를 들어, "좋은 코드란 무엇인가?"에 대한 명세를 작성하면, Claude는 이 명세에 맞춰 코드를 검증합니다. 성능 기준, 코드 스타일, 아키텍처 원칙 등을 모두 자동으로 확인할 수 있습니다.

이것은 테스트 주도 개발(TDD)의 진화 와 같습니다. 과거 TDD는 엔지니어에게 힘든 규율이었습니다. "먼저 테스트를 작성해야 한다"는 원칙은 종종 "브로콜리를 먼저 먹어야 한다"는 느낌으로 받아들여졌습니다. 하지만 이제 Claude가 테스트를 작성해주면, 그 부담이 크게 줄어듭니다.

물론, 모든 검증이 자동화될 수는 없습니다. 특히 깊은 시스템 전문성이 필요한 영역 에서는 인간 리뷰어가 여전히 필수입니다. 분산 시스템, 성능 최적화, 보안 등의 영역에서는 경험 많은 엔지니어의 판단이 대체 불가능합니다.

여기서 피오나가 강조하는 원칙은 "신뢰하되 검증하라(trust but verify)" 입니다. Claude와 같은 AI 모델은 정말 훌륭하지만, 여전히 검증이 필요합니다. 따라서 조직은 두 가지를 동시에 해야 합니다:

깊은 전문성이 필요한 영역에는 전문가를 배치
자동 검증으로 대부분의 문제를 선제적으로 포착

이렇게 함으로써 리뷰어의 집중력은 정말 중요한 문제에만 쏟을 수 있게 됩니다.

역할의 경계가 허물어지다: 모두가 '빌더'가 된다

AI 도구의 보급이 만든 가장 흥미로운 변화 중 하나는 전문 분야의 경계가 흐려지는 것 입니다.

전통적으로 소프트웨어 회사의 조직도는 명확했습니다: 엔지니어는 코드를 작성하고, PM(Product Manager)은 기획을 하며, 디자이너는 UI/UX를 만들었습니다. 하지만 이제는 모든 것이 변하고 있습니다.

Claude Code 팀의 PM들은 이제 기능을 직접 구현합니다. 엔지니어링 리소스 부족으로 기다릴 필요가 없기 때문입니다. 데이터 과학자들은? 그들은 이제 "일반 사용자가 Claude로 만든 분석을 검증하는 일"을 주로 합니다. 엔지니어들은 모바일 개발이나 디자인까지 손을 댑니다.

이 현상에 대해 누군가는 이렇게 말했습니다: "역할은 당신이 실제로 하는 일의 가장 높은 비율로 정의된다." 이것은 조직도상의 직책이 더 이상 의미 있는 구분이 아니라는 뜻입니다.

이러한 변화가 긍정적인 측면도 있고 도전 과제도 있습니다.

긍정적 측면:

엔지니어들이 더 제품 중심적 으로 생각하게 됩니다
PM들이 기술적 제약을 더 잘 이해하게 됩니다
조직이 더 유연해집니다

도전 과제:

깊이 있는 전문성이 부족해질 수 있습니다
누가 최종 책임을 지는지 불명확할 수 있습니다
빠르게 움직이는 것 vs. 제대로 하는 것의 균형이 어려워집니다

이것이 피오나가 팀 문화를 유지하는 데 "높은 책임감"을 강조하는 이유입니다. 역할이 모호해질수록, 누가 무엇을 책임질 것인지 더욱 명확해야 합니다.

품질 측정의 새로운 프레임워크: "나쁜(Bad)" vs "슬픈(Sad)"

전통적인 엔지니어링 조직에서는 품질을 다음과 같이 측정했습니다:

버그 발생 수
성능 메트릭
업타임(Uptime)
사용자 만족도

하지만 AI로 생산성이 8배 증가하고 모든 사람이 코드를 작성할 수 있게 되면서, 기존의 메트릭만으로는 부족합니다. 이에 피오나 팀이 도입한 개념이 "나쁜 경험(Bad Experience)"과 "슬픈 경험(Sad Experience)" 입니다.

"나쁜" 경험:

심각하고 복구 불가능한 오류
사용자가 제품을 사용할 수 없는 상태
데이터 손실이나 보안 문제

"슬픈" 경험:

덜 치명적이고 복구 가능한 문제
사용자가 우회할 수 있지만 불편한 상황
UI/UX의 작은 문제들

흥미로운 점은, 여러 "슬픈" 경험이 쌓이면 "나쁜" 경험이 될 수 있다는 것입니다. 따라서 조직은 단순히 "나쁜" 사건만 추적하는 것이 아니라, "슬픈" 사건들의 추세도 모니터링해야 합니다.

이 프레임워크의 장점은 각 팀에게 자율성 을 부여한다는 것입니다. 팀은 자신의 제품 맥락에서 "나쁜 경험"이 무엇인지 정의합니다. 메시징 앱과 재무 소프트웨어에서 "나쁜 경험"의 정의는 당연히 다릅니다.

이러한 접근은 또한 프로액티브(Proactive) 품질 관리 를 가능하게 합니다. 문제가 터지기 전에 작은 신호들을 감지하고 대응할 수 있다는 뜻입니다.

AI가 변화시킨 PM의 역할: 혁신 가능성의 확대

제품 관리자(PM)의 역할도 급격히 변하고 있습니다. 과거 PM의 가장 큰 도전은 기능 요청과 엔지니어링 역량의 불일치 였습니다. 좋은 아이디어가 있어도 개발 자원이 부족해 몇 개월을 기다려야 했습니다.

이제는 완전히 다릅니다. 앤트로픽의 PM들은 Claude를 사용해서 기능을 직접 만들 수 있습니다. 이것은 병목이 사라졌다 는 의미입니다.

더욱 흥미로운 변화는 잠재적 수요(Latent Demand) 발견 입니다. PM들은 단순히 계획된 기능만 만들지 않습니다. 사용자들이 예상치 못한 방식으로 제품을 사용하는 것을 관찰하고, 그것을 더 나은 경험으로 만듭니다.

예를 들어, Claude를 비개발자들이 사용하고 있다는 것을 발견했을 때, 팀은 이 사용 사례를 공식적으로 지원하기 시작했습니다. 이것이 Claude for Small Business 같은 새로운 제품이 나오게 된 배경입니다.

이것이 성장(Growth)의 새로운 정의 입니다. 더 많은 기능을 빨리 출시하는 것이 아니라, 사용자가 정말 필요로 하는 것을 발견하고 그것을 완벽하게 만드는 것입니다.

엔지니어 채용의 미래: 깊이 있는 전문가 vs 창의적인 빌더

AI가 코딩을 자동화하면 엔지니어의 수요가 줄어들 것이라는 예상은 틀렸습니다. 오히려 OpenAI, Anthropic 등 AI 회사들은 엔지니어를 미친 듯이 채용하고 있습니다. 왜일까요?

피오나가 찾는 두 가지 인재상을 보면 그 이유가 명확합니다:

첫째: "제품 감각을 가진 창의적인 빌더"

자신이 만드는 제품에 열정을 가진 사람
아이디어를 내고 직접 만들고 반복할 수 있는 사람
제품이 즐거운 경험을 제공하는지 검증하는 사람
처음부터 끝까지 제품 책임을 지는 사람

둘째: "어려운 부분을 위한 깊이 있는 시스템 전문가"

분산 시스템, 인프라, 성능 최적화 등에 깊은 지식을 가진 사람
Claude와 같은 AI 모델도 아직 검증하지 못하는 영역을 다루는 사람
"신뢰하되 검증하라"는 원칙을 실현하는 사람

이 두 유형의 엔지니어가 필요한 이유는, AI는 대부분을 자동화할 수 있지만 문제 정의와 깊이 있는 판단은 여전히 인간의 몫 이기 때문입니다.

그렇다면 다음 세대 엔지니어를 어떻게 키울 것인가? 이것이 피오나가 "수정 구슬이 있었으면 좋겠다"고 말할 정도로 고민하는 문제입니다.

과거의 엔지니어 교육 경로는 이랬습니다:

대학에서 자료 구조, 알고리즘 배우기
인턴으로 조금 더 배우기
주니어 개발자로 경험 쌓기
수년간 코드 경험으로 깊이 키우기

하지만 앞으로는 이 경로가 통하지 않을 수 있습니다. 코드를 볼 필요가 없다면, 왜 어셈블리나 메모리 할당 같은 기초를 배워야 할까요?

이것이 대안이 될 수 있습니다:

고급 펠로우십/견습 프로그램: 실무 경험 압축하기
제품 기획부터 출시까지: 실제 문제 해결 경험
깊이 있는 영역의 집중 학습: 특정 분야의 전문성 구축
구축 문화: 아이디어를 빨리 시제품으로 만들어보기

핵심은 "모든 것이 가능하다"는 시대에서, 무엇이 중요한가를 판단할 능력 을 키우는 것입니다.

성장형 사고방식: AI 시대의 최고의 무기

이 모든 변화 속에서 가장 두드러지는 특징은 무엇일까요? 바로 성장형 사고방식(Growth Mindset) 입니다.

피오나가 만난 적응을 잘하는 엔지니어와 좌절하는 엔지니어의 차이는 무엇일까요? 선천적 재능이나 경험의 차이가 아니었습니다. 그것은 배움의 자세 였습니다.

번성하는 엔지니어들 은 "새로운 도구를 배워보자", "이전 방식이 작동하지 않으니 다른 방법을 시도해보자"고 생각합니다.
좌절하는 엔지니어들 은 "하지만 내가 이 방식으로 성공했는데?", "모든 게 너무 빨리 변해"라고 느낍니다.

흥미롭게도, 좌절감 뒤에는 두려움 이 있습니다. 두려움 자체는 나쁜 것이 아닙니다. 인간의 진화적 메커니즘입니다. 문제는 두려움 앞에서 "모든 게 내 통제 밖이다" 라고 생각하는 것입니다.

피오나의 조언은 이렇습니다:

"두려움이 있는 어떤 일에 대해서든, 내가 할 수 있는 것은 무엇인가? 내 통제 범위 안에 있는 것은 무엇인가를 묻는 것입니다. 왜냐하면 때로는 좌절감이 두려움과 '모든 게 내 통제 밖이다'는 느낌에서 오기 때문입니다."

이것은 단순한 긍정적 사고가 아닙니다. 그것은 에이전시(Agency) 를 되찾는 것입니다. 통제할 수 없는 것에 집중하지 말고, 할 수 있는 한 가지 행동에 집중하는 것. 그것이 성장을 향한 첫 걸음입니다.

앤트로픽의 채용 공고를 보면 "성장형 사고방식"이 명시적으로 요구되는 이유가 여기 있습니다. 기술은 빠르게 변하지만, 배우는 자세는 변하지 않기 때문입니다.

소규모 사업과 AI: 다리 놓기

피오나의 또 다른 열정은 소규모 사업들을 AI로 돕는 것 입니다. 어릴 때 할머니와 함께 뜨개질 모임에서 만난 그 커뮤니티의 기억이 여전히 생생합니다.

최근 그녀는 많은 소규모 사업주 친구들이 행정 업무에 시간을 낭비 하고 있다는 것을 발견했습니다. 송장 발행, 경비 처리, 기록 관리... 실제로 하고 싶은 일이 아닌 것들입니다.

Claude for Small Business 를 만든 배경이 여기 있습니다. 자신의 작은 출장 경비를 처리할 때 Claude를 사용했던 경험이 이렇게 확대된 것입니다.

더 흥미로운 것은 사용 사례의 다양성입니다:

식당 주인은 Claude를 사용해 현지 가격과 자신의 메뉴를 비교합니다
작은 마켓은 Claude로 품질 관리를 합니다
자영업자는 Claude로 계약서를 검토합니다

이것이 바로 잠재적 수요(Latent Demand) 입니다. 사람들이 정말 필요로 하지만 누구도 만들지 않아 서비스를 못 받던 것들입니다.

하지만 피오나가 지적하는 과제도 있습니다: AI에 대한 저항 입니다. 많은 사람들이 여전히 "AI를 믿지 못한다" 또는 "나는 AI와 상관없다"고 생각합니다.

그녀의 조언은 이렇습니다:

"만약 공동체나 가족 중에 AI 도구로 정말 의미 있는 삶의 변화를 경험한 사람이 있다면, 그 이야기를 나누세요. 그것이 대화의 시작점이 될 수 있습니다."

이것은 지식이 힘이다 는 믿음에서 나온 실천입니다. 더 많은 사람들이 AI를 배우고 사용할수록, "AI와 AI를 배운 사람들의 격차"가 줄어들 수 있기 때문입니다.

팀 문화의 진화: 빠른 성장 속에서 인간성 유지하기

앤트로픽이 급성장하면서 피오나를 밤 못 자게 하는 것은 기술적 문제가 아닙니다. 그것은 팀 문화 입니다.

문화는 벽에 붙여놓는 구호(Core Values)가 아닙니다. 그것은 살아 숨 쉬는 실체 입니다. 조직의 구성원들이 서로를 대하고, 지원하고, 함께 일하는 방식에서 나타납니다.

앤트로픽 같은 고속 성장 조직에서 문화를 유지하는 것은 매우 어렵습니다. 매월 새로운 팀원들이 들어오고, 기존 팀의 dynamics가 변합니다. 이것을 피오나는 "다루기 좋은 문제" 라고 표현합니다.

Sheryl Sandberg가 한 조언이 떠올랐다고 피오나는 말합니다:

"빠른 성장 속에서 문화를 유지하는 것이 어렵다고요? 그것이 바로 당신이 원하는 문제입니다. 왜냐하면 그것은 당신이 잘 성장하고 있다는 의미이기 때문입니다. 대안 - 성장하지 않거나 채용하지 않는 것 - 은 훨씬 더 나쁩니다."

그렇다면 빠른 성장 속에서 문화를 유지하려면?

1. 다양성과 개방성
팀은 다양한 배경의 사람들로 구성되어야 합니다. 그리고 그들의 의견이 자유롭게 표현될 수 있어야 합니다.

2. "하나의 팀" 정신
결승선에 도달했을 때, 누군가 도움이 필요하면 돌아서서 도와주는 문화. 함께 완주하는 것이 목표입니다.

3. 프로세스의 지속적 평가
"이 프로세스가 여전히 우리의 목적에 부합하는가?"를 계속 묻습니다.

특히 피오나가 강조하는 것은 명시적인 허가 입니다: "당신에게 더 이상 도움이 되지 않는 프로세스는 멈춰도 됩니다."

예를 들어, 그녀는 처음에는 6개월 로드맵을 만들었지만, 3개월 후 대부분이 변했다는 것을 깨달았습니다. 그래서 이제는 "JIT 계획(Just In Time Planning)" 을 합니다: 가벼운 월별 계획과 주간 점검만 합니다.

이것은 조직의 민첩성 을 확보하는 방법이면서, 동시에 팀 신뢰 를 구축하는 방법입니다. 팀원들은 "리더가 우리의 말을 듣고 있다", "불필요한 것을 없애주고 있다"는 것을 느낍니다.

AI 시대의 외로움: 짝 프로그래밍의 귀환

역설적이지만, AI가 엔지니어링을 자동화할수록 외로움이 증가 합니다.

예전에는 엔지니어들이 함께 코드를 만들었습니다. 백엔드는 여러 사람이, 프론트엔드는 여러 사람이 협력했습니다. 자연스럽게 상호작용 이 일어났습니다.

이제는 각 엔지니어가 Claude와 함께 일합니다. 더 빠르고 더 생산적이지만, 더 외로운 경험입니다. 팀원들과의 상호작용이 줄어듭니다.

이를 인식한 Claude Code 팀은 "짝 프로그래밍 점심" 을 시작했습니다. 엔지니어들이 함께 앉아서 각자의 작업을 하되, 서로 옆에서 작업하는 것입니다.

이것은 전통적인 짝 프로그래밍은 아닙니다. 코드를 함께 작성하지 않습니다. 하지만 다른 사람이 어떻게 Claude를 활용하는지 보는 것 자체가 배움이 됩니다. 각 엔지니어의 워크플로가 다르기 때문입니다.

또한 팀은 해커톤 같은 공동 활동 도 합니다. 모두가 함께 시간을 보내고, 함께 성취를 나눕니다.

이것이 "인간 중심적인" AI 도입 의 좋은 예입니다. 효율성만 추구하는 것이 아니라, 사람들의 관계와 연대를 유지하면서 기술을 활용하는 것입니다.

속도 vs 품질: 영원한 대화

모든 엔지니어링 조직이 직면하는 영원한 질문: 빠르게 움직이는 것이 중요한가, 아니면 제대로 하는 것이 중요한가?

AI 시대에는 이 질문이 더 복잡해집니다. 정말 빠르게 많이 만들 수 있으니까요.

피오나의 접근은 프로액티브 품질 관리 입니다. 문제가 터지기를 기다리지 말고, 작은 신호를 감지합니다. "슬픈" 경험들의 추세를 모니터링하면, 큰 문제가 되기 전에 대응할 수 있습니다.

또한 그녀는 청취 투어(Listening Tour) 를 강조합니다. 리더는 정기적으로 팀원들, 특히 선임 엔지니어들과 만나 "무엇이 작동하고 무엇이 작동하지 않는가"를 들어야 합니다. 이것이 대시보드를 확인하는 것보다 훨씬 더 많은 정보를 제공합니다.

속도와 품질의 균형은 문화와 신뢰 에서 나옵니다. 팀이 "리더가 우리의 의견을 듣는다", "우리가 실수해도 괜찮다"고 느끼면, 자연스럽게 품질을 유지하면서 빠르게 움직일 수 있습니다.

리더가 매일 제품을 사용해야 하는 이유

마지막으로 돌아가고 싶은 원칙이 있습니다: 도그푸딩(Dogfooding).

Meta에 입사했을 때, 피오나는 마켓플레이스 팀의 리더였습니다. 수백 명을 감독했지만, 처음 몇 개월은 스스로를 IC(개별 기여자)로 여겼습니다. 팀의 제품을 직접 사용하고 경험했습니다.

시간이 지나면서 많은 리더들이 그 경험의 가치를 깨달았다고 했습니다: "Claude 덕분에 다시 코드를 출시하고 있어요."

왜일까요? 왜 리더가 계속 "손에 흙을 묻혀야" 할까요?

첫째, 감각을 유지하기 위해
지표와 대시보드는 거짓말을 하지 않지만, 불완전합니다. 직접 사용하면서 느끼는 것이 있습니다. 작은 불편함, 보이지 않는 버그, 예상치 못한 사용 패턴들이 있습니다.

둘째, 팀을 정말 이해하기 위해
팀원이 무엇을 어려워하고 무엇에 기쁨을 느끼는지 실제로 알아야 합니다. 그들이 사용하는 도구, 겪는 문제를 직접 경험하는 것이 리더를 더 좋은 의사결정자로 만듭니다.

셋째, 설득력 있는 리더가 되기 위해
리더가 "너희가 이렇게 해야 한다"고 말할 때, 팀은 "저 사람이 정말 알고 말하는 건가?"를 본다고 느낍니다. 하지만 리더가 직접 제품을 사용하고 "내가 이렇게 해보니까 이게 낫더라"고 말하면, 설득력이 다릅니다.

이것이 리더십의 기본 이면서, 동시에 AI 시대의 필수 스킬 입니다. AI가 점점 더 많은 업무를 자동화할수록, 리더의 역할은 더욱 직접적인 경험과 판단 위에 기반해야 합니다.

AI로 인한 기술 퇴화의 우려

한 가지 우려가 남습니다: "엔지니어들이 더 이상 코드를 직접 작성하지 않으면 기술이 퇴화하지 않을까?"

피오나의 답변은 "깊이(Double-click) 있는 학습" 의 중요성입니다.

확실히 더 이상 코드 라인을 직접 타이핑할 필요는 없을 수 있습니다. 하지만 의존성을 이해 해야 합니다. 당신의 코드가 사용하는 라이브러리, 프레임워크, 인프라가 어떻게 작동하는지 알아야 합니다. 왜냐하면:

인프라가 변경될 때 대응할 수 있어야 합니다
성능 최적화 기회를 포착할 수 있어야 합니다
보안 취약점을 이해할 수 있어야 합니다

이것은 추상화 계층의 진화 와 같습니다. 어셈블리에서 고급 언어로, 고급 언어에서 프레임워크로, 이제는 AI로 이동했습니다. 하지만 어느 계층에 있든 아래 계층을 이해하는 것 은 여전히 필수입니다.

또한 피오나는 흥미로운 관찰을 합니다: "그렇다면 새로운 학습 경로도 필요하다"는 것입니다. 기존의 "4년 대학 + 인턴십 + 경험"이 아니라, 새로운 형태의 펠로우십이나 견습 프로그램 이 필요할 수 있습니다. 실제 문제를 빨리 풀면서 배우는 방식입니다.

성장을 계속하기 위한 마지막 조언

인터뷰의 마지막, 피오나가 언급한 인생의 좌우명은 인상적입니다:

일할 때: "간단하게 하세요(Keep it simple)"

너무 많이 생각하지 말고, 정말 잘하고 싶은 것이 무엇인지 집중하세요

삶에서: "무엇이든 될 수 있는 세상에서, 친절하세요"

다른 사람이 무엇을 겪고 있는지 모릅니다
작은 친절이 가장 큰 변화를 만듭니다

코로나 시대의 한 일화가 이를 잘 보여줍니다. 그녀는 항상 일대일 면담을 철저히 지켰습니다. 하지만 할머니가 요양원에 계실 때, 갑작스럽게 페이스타임 기회가 생겼습니다. 그녀는 부하 직원에게 물었습니다: "면담을 잠깐 미루면 괜찮을까요?"

부하 직원은 "물론이죠"라고 답했습니다. 그것이 아무것도 아닌 것처럼 보였지만, 그 작은 친절은 피오나에게 할머니를 만날 수 있는 귀한 기회를 선물했습니다.

이것이 진정한 리더십 입니다. 조직 성과도 중요하지만, 인간으로서의 연대와 배려가 있을 때 조직은 진정으로 강해집니다.

결론

세계에서 가장 AI에 몰입한 엔지니어링 팀을 만드는 것은 단순히 기술 채택의 문제가 아닙니다. 그것은:

사람들에게 야망을 품을 자유를 주되, 책임감을 요구하기
자동화할 수 있는 것은 자동화하되, 핵심은 인간이 판단하기
빠르게 움직이되, 팀 문화를 잃지 않기
데이터를 따르되, 직접 경험을 우선하기
깊이 있는 전문가와 창의적인 빌더를 함께 키우기
성장 속에서도 인간으로서의 친절을 잃지 않기

AI 기술은 도구일 뿐입니다. 그것을 어떻게 사용하는가, 그 과정에서 팀과 조직의 문화를 어떻게 유지하는가가 진정한 성공을 결정합니다.

앤트로픽의 사례는 이것이 가능하다는 것을 보여줍니다. 분기당 8배의 생산성 증대를 이루면서도, 팀의 연대와 문화를 지키는 것 말입니다. 그리고 그 중심에 있는 것은 성장형 사고방식을 가진 리더 입니다.

앞으로의 엔지니어링은 어떻게 될까요? 확실한 것은 이 변화가 계속되고 더 가속화될 것이라는 점입니다. 하지만 피오나와 같은 리더들이 보여주는 길을 따르면, 우리는 AI 시대에서도 인간 중심적인 조직을 만들 수 있을 것입니다.

Original source: Building the most AI-pilled engineering team in the world | Fiona Fung (Anthropic)

powered by osmu.app

(Lenny's Podcast) AI 시대 엔지니어링 팀 구축: 생산성 8배 증대의 비결