직무 경계가 사라지고 있다
"엔지니어를 뽑아야 하나, PM을 뽑아야 하나." AI-First 팀을 구성할 때 테크 리드라면 한 번쯤 이 질문에서 막혀봤을 것이다. Anthropic에서 Claude Code 개발을 총괄하는 보리스 체르니(Boris Cherny)가 최근 X를 통해 내놓은 분석은 그 질문 자체가 틀렸다고 말한다. 미래 제품 조직은 직무(job title)가 아니라 역할(archetype) 중심으로 재편된다는 것이다.
체르니가 제시한 다섯 가지 역할은 이렇다. 아이디어를 끊임없이 실험하는 프로토타이퍼(Prototyper), 프로토타입을 프로덕션 수준으로 밀어 올리는 빌더(Builder), UI와 코드를 단순화하고 불필요한 것을 덜어내는 스위퍼(Sweeper), 출시된 제품의 PMF를 높이는 그로워(Grower), 성숙한 시스템의 안정성과 운영 효율을 지키는 메인터이너(Maintainer)다. 그가 강조한 핵심은 "이 역할들이 기존 직무와는 크게 관련이 없다"는 점이다. 앤트로픽 내부에서도 디자이너가 빌더로, 엔지니어가 스위퍼로 작동하는 경우가 흔하다고 한다.
이 프레임은 Microsoft CEO 사티아 나델라가 YC와의 대담에서 꺼낸 사례와 정확히 맞닿는다. LinkedIn이 프로덕트 디자인·프런트엔드 엔지니어링·PM 기능을 하나의 역할인 '풀스택 빌더'로 통합하기 시작했다는 것이다. Meta CTO 앤드루 보즈워스도 같은 방향에서 경고를 날렸다. AI 도구를 완전히 습득한 개발자와 그렇지 못한 개발자 사이의 "역량 계층화(tiering of capability)"가 심화될 것이라고. 이 세 사람의 발언이 같은 시기에 겹친다는 건, 이게 트렌드 이야기가 아니라 지금 팀 구조를 설계해야 한다는 신호라고 읽는다.
역할 재편, 실전에서는 어떻게 작동하나
이론은 깔끔하다. 문제는 '그래서 내일 당장 어떻게 하냐'다. dev.to에 공유된 Claude Code × Django 실전 워크플로우는 그 질문에 직접 답한다. 핵심은 CLAUDE.md를 계약서처럼 써야 한다는 것이다.
Claude Code는 프로젝트 루트의 CLAUDE.md를 세션 시작 전에 전부 읽는다. 이 파일은 AI가 코드에서 추론할 수 없는 것들—팀의 컨벤션, 건드리면 안 되는 영역, 실행해야 할 정확한 커맨드—을 명시하는 공간이다. 결제 앱(apps/payments/)에 지시 없이 손대지 말 것, 마이그레이션은 반드시 --check 플래그와 함께 생성할 것, 프로덕션 설정파일은 절대 수정 금지. 이런 제약들이 없으면 Claude Code는 "도움이 되려고" 요청하지 않은 파일까지 리팩터링한다. Off-limits 섹션이 가장 중요한 이유다.
어떤 작업을 위임하고 어떤 작업은 직접 해야 하는가. 이 판단이 역할 재편의 실질적인 경계선이다. 직렬라이저 보일러플레이트, ViewSet 구조, 관리 커맨드 뼈대, 뷰·시리얼라이저 단위 테스트—이런 것들은 위임할 수 있다. 반면 스키마 설계는 직접 해야 한다. "user activity를 추적하는 테이블을 추가해줘"라고 하면 AI는 그럴듯한 스키마를 내놓지만, 그 도메인에서 'activity'가 무엇인지, 리포팅 쿼리가 무엇을 집계해야 하는지는 코드베이스 어디에도 없다. 그 맥락은 개발자 머릿속에 있다.
세션 관리도 중요한 설계 포인트다. 90분짜리 세션은 60분쯤 지나면 세션 초반에 심어둔 제약을 잊기 시작한다. 컨텍스트 윈도우가 가득 차면서 "항상 select_related를 써라"는 지시가 최근 도구 호출들에 밀려나는 것이다. 해법은 세션마다 단일 목표를 설정하고, 서브태스크가 완료될 때마다 /compact로 압축하는 것이다. 단, /compact 이후에는 부정적 제약("이건 하지 마라")을 다시 명시적으로 재선언해야 한다. 제약의 생존율이 긍정적 지시보다 낮다.
Ford가 준 경고: 제도적 지식은 자동화되지 않는다
역할을 재설계할 때 가장 위험한 가정은 "AI가 베테랑의 지식을 흡수했다"는 착각이다. Bloomberg가 보도한 Ford 사례는 이 착각의 대가를 숫자로 보여준다.
Ford CEO 짐 팔리는 350명의 베테랑 엔지니어를 AI로 대체하는 도박을 했다. 결과: 2026년 51건의 리콜, 1,100만 대 이상의 차량이 영향을 받았다. Ford VP 찰스 푼이 공개적으로 인정한 실패 원인은 명확했다. "자동화 시스템이 학습한 정보가 베테랑 엔지니어들과 함께 회사를 떠났다." 제도적 지식(institutional knowledge)은 코드베이스와 문서에 담기지 않는다. 수십 년간 특정 부품이 어떻게 실패하는지 직접 겪은 사람의 직관, 그 직관에서 나온 엣지 케이스 판단—이건 학습 데이터로 만들 수 없는 종류의 지식이다.
Ford의 수정 루트도 시사적이다. 350명을 3년에 걸쳐 재고용하고, 이들이 10만 건의 새 AI 스트레스 테스트를 설계하도록 했다. 이번엔 AI가 단독으로 판단하는 게 아니라, 베테랑의 직관이 AI의 테스트 범위를 설계하는 구조였다. 결과는 JD Power 2026 초기 품질 1위, 비용 10억 달러 이상 절감이다. TechCrunch가 집계한 2026년 AI 기반 레이오프 데이터도 같은 방향을 가리킨다. 성장하는 포지션은 'AI 인프라 엔지니어'와 'AI가 복제할 수 없는 물리적 직관을 가진 도메인 베테랑'이다.
팀 리빌딩, 어디서 시작할 것인가
세 가지 소스를 조합하면 AI-First 팀 리빌딩의 설계 순서가 보인다.
첫째, 역할 인벤토리를 먼저 그려라. 지금 팀에 프로토타이퍼·빌더·스위퍼·그로워·메인터이너가 어떻게 분포되어 있는가. 직무 타이틀이 아니라 실제로 어떤 역할을 수행하고 있는가를 기준으로. 특정 역할이 비어 있다면, 그 빈자리가 곧 제품의 약점이다.
둘째, AI 위임 경계를 명문화하라. CLAUDE.md가 Django 프로젝트의 계약서 역할을 하듯, 팀 차원에서 "AI에게 위임하는 작업"과 "사람이 직접 판단하는 작업"의 경계를 문서화해야 한다. 스키마 결정, 도메인 엣지 케이스, 사이드이펙트가 있는 비동기 태스크 설계—이건 AI가 그럴듯하게 생성하더라도 사람이 검증해야 하는 영역이다.
셋째, 제도적 지식을 먼저 확보하라. Ford의 실수는 속도를 위해 지식을 먼저 내보낸 것이었다. AI-First 전환을 시작하기 전에, 팀 내 베테랑이 갖고 있는 도메인 직관을 먼저 구조화해야 한다. CLAUDE.md의 Off-limits 섹션처럼, "왜 이 코드를 건드리면 안 되는가"를 AI가 읽을 수 있는 형태로 남기는 것이 팀 리빌딩의 출발점이다.
AI가 역할을 대체하는 게 아니라, AI를 다루는 역할이 새로 생기는 것이다. 그 역할의 경계를 설계하는 것—그것이 지금 테크 리드의 진짜 일이다.