직무명이 설명하지 못하는 일이 늘어납니다

AI 개발 도구가 팀에 들어오면서 직무 경계가 흐려집니다. 엔지니어가 제품 결정을 내리는 일이 잦아졌습니다. 디자이너는 동작하는 프로토타입을 직접 만들고 PM은 데이터와 시스템 제약까지 들여다봅니다. 예전처럼 구현은 엔지니어링, 기획은 PM, 화면은 디자인으로 깔끔하게 나누기 어렵습니다.

Boris Cherny가 Claude Code 팀을 보면서 미래의 역할을 다섯 가지 유형으로 정리했습니다. 직무명이 아니라 사람이 실제로 어떤 일을 잘하느냐를 기준으로 삼습니다.

이 구분은 조직도가 아니라 제품 생애주기를 따릅니다. 새 제품을 만들 때 필요한 사람과 이미 PMF를 찾은 제품을 키울 때 필요한 사람이 다릅니다. 성숙한 시스템을 지키는 사람은 또 다릅니다.

다섯 가지 작업 유형

맨 앞에 Prototyper가 있습니다. 새 아이디어를 계속 꺼내고 빠르게 실험합니다. 대부분은 실제 제품으로 이어지지 않습니다. 그래도 이 역할이 필요합니다. 뭐가 맞는지 아직 모르는 단계에서는 많이 만들어보고 많이 버리는 사람이 있어야 합니다.

Builder는 그 아이디어를 실제 제품과 인프라로 바꿉니다. 데모가 아니라 운영 가능한 형태로 만드는 일입니다. AI가 초안을 빠르게 뽑아주는 시대일수록 Builder의 판단이 더 중요해집니다. 뭘 남기고 뭘 다시 설계할지 골라야 하기 때문입니다.

Sweeper가 하는 일은 정리입니다. UI를 다듬고 코드와 시스템을 단순하게 만듭니다. 필요 없어졌거나 오히려 거치적거리는 기능은 걷어냅니다. 성능도 손봅니다. 원문에서 눈에 띈 단어가 unship입니다. 좋은 팀은 기능을 더하는 사람만으로는 안 굴러갑니다. 없앨 걸 없애는 사람이 있어야 합니다.

Grower는 이미 나온 제품을 붙잡고 계속 개선해 PMF를 키웁니다. 사용자 피드백과 사용 패턴, 시장 반응을 보면서 제품을 다듬습니다. 새로 만드는 감각과 운영 지표를 읽는 감각이 둘 다 필요합니다.

마지막은 Maintainer입니다. 성숙한 시스템을 맡아 보안과 신뢰성, 속도와 비용 효율을 지킵니다. 규모가 커질수록 이 역할의 무게가 커집니다. 사용자가 많아진 제품에서는 새 기능보다 안정성과 운영 품질이 더 큰 문제가 되기 때문입니다.

한 사람이 두세 역할 유형을 겹쳐 가질 수 있습니다

이 다섯 유형은 직무와 일대일로 묶이지 않습니다. Boris가 짚은 것도 그 부분입니다. 디자이너 중에도 Prototyper가 있고 Builder나 Sweeper에 가까운 사람이 있습니다. 엔지니어든 PM이든 데이터 사이언티스트든 마찬가지입니다.

한 사람이 두 역할을 걸치는 경우가 많고 세 역할을 오가기도 합니다. 어떤 엔지니어는 Builder이면서 Sweeper입니다. 프로토타입을 빠르게 제품화하면서 코드와 인터페이스를 계속 줄입니다. Grower와 Maintainer를 같이 하는 PM도 있습니다. 제품 지표에서 개선점을 찾으면서 성숙한 시스템의 리스크도 챙깁니다.

그래서 이 프레임은 채용 직무표를 바꾸자는 얘기는 아닙니다. 팀에 어떤 작업 성향이 비어 있는지 보는 데 쓰는 도구입니다. 같은 “엔지니어"라도 새 기능만 만들고 정리하는 사람이 없으면 제품은 금방 복잡해집니다. 반대로 Maintainer만 많으면 새 가설을 밀어붙이는 힘이 약해집니다.

제품 단계마다 필요한 조합이 다릅니다

원문에서 제일 실무적으로 쓸 만한 대목은 제품 단계별 조합입니다.

아직 PMF를 찾지 못한 새 제품은 Prototyper, Builder, Sweeper가 강해야 합니다. 아이디어를 많이 내고 빠르게 제품 형태로 바꾼 다음 실험하고 남은 군더더기를 치우는 흐름입니다. 이 단계에서 Maintainer 위주로만 팀을 짜면 속도가 안 납니다.

제품이 성장하고 PMF를 잡기 시작하면 Builder, Sweeper, Grower가 중심이 됩니다. 계속 만들되 아무 기능이나 붙이면 안 됩니다. 이미 나온 신호를 바탕으로 제품을 키우고 복잡해진 곳은 정리합니다. 이때부터 Maintainer도 일부 필요합니다. 사용자가 늘면 장애와 보안, 비용 문제가 바로 따라옵니다.

강한 PMF를 가진 성숙한 제품은 Sweeper, Grower, Maintainer가 핵심입니다. 쓰는 사람이 이미 많으니 안정성과 효율이 중요합니다. 그렇다고 Builder가 완전히 빠지면 안 됩니다. 성숙한 제품도 새 기능과 인프라 개선은 계속 필요합니다.

AI 시대의 팀 설계는 역할보다 일의 성격을 봅니다

이게 Claude Code 팀만의 이야기가 아니라서 흥미롭습니다. AI 도구가 개발 속도를 끌어올릴수록 직무 경계는 더 흐려집니다. 디자이너가 프로토타입을 만들고 엔지니어가 제품 가설을 검증합니다. PM이 자동화 워크플로우를 직접 돌리는 것도 어색하지 않습니다.

그럴수록 “누가 어느 부서인가"보다 “이 제품에 지금 어떤 유형이 부족한가"를 먼저 봅니다. 새 제품인데 Prototyper가 없는지, 성장하는 제품인데 Grower가 약한지, 성숙한 시스템인데 Maintainer가 너무 적은지 점검하는 것입니다.

나도 이 관점이 꽤 현실적이라고 봤습니다. AI가 코드를 더 빨리 뽑아낼수록 Builder만 잔뜩 모인 팀이 오히려 위험합니다. 만드는 사람 못지않게 덜어내는 사람, 키우고 지키는 사람이 같이 있어야 합니다. 제품이 커지면 잘 만드는 능력 하나로는 안 됩니다.

요약

  • 미래의 제품 팀은 직무명보다 Prototyper·Builder·Sweeper·Grower·Maintainer 같은 작업 성향으로 더 많이 설명됩니다.
  • 한 사람이 두세 유형을 겹쳐 가질 수 있습니다. 이 유형은 엔지니어·디자이너·PM·데이터 사이언티스트 같은 직무와 고정되지 않습니다.
  • 제품 단계에 따라 필요한 조합이 달라집니다. pre-PMF는 실험과 제품화, 성장기는 개선과 정리, 성숙기는 안정성과 효율 쪽으로 무게가 옮겨갑니다.