AI 코딩 시대의 팀 구성: 직무가 아닌 아키타입으로 보기
TL;DR
- Claude Code 팀의 Boris Cherny가 제시한 프레임워크: 엔지니어링/프로덕트/디자인 등 전통적 직무 구분 대신, 일하는 방식에 따른 5가지 역할 아키타입으로 팀원을 이해하자는 제안
- 아키타입은 Prototyper → Builder → Sweeper → Grower → Maintainer로 이어지는 제품 생애주기와 대응됨
- 아키타입은 직무(job function)와 독립적이며, 한 사람이 프로젝트 단계에 따라 여러 아키타입을 오갈 수 있음
- 제품 단계별로 필요한 아키타입 조합이 다르며, 이는 팀 빌딩과 채용 전략에 시사점을 줌
배경: 왜 지금 이 프레임이 나왔나
AI 코딩 도구(Claude Code 등)의 등장으로 코드를 “작성”하는 물리적 비용이 크게 낮아지면서, 한 사람이 기획-구현-운영 전 과정을 커버하는 사례가 늘고 있다. 이 변화 속에서 기존의 “프론트엔드 엔지니어”, “백엔드 엔지니어”, “PM”, “디자이너” 같은 도메인 기반 직함은 실제 업무 방식을 점점 덜 설명하게 된다.
Cherny는 이 문제를 직무가 아니라 **일하는 방식(working style)**을 기준으로 재정의하는 방식으로 접근했다. Claude Code 팀을 관찰한 결과를 다섯 가지 아키타입으로 정리한 것이 이 프레임워크다.
5가지 아키타입 정의
| 아키타입 | 핵심 활동 | 특징 |
|---|---|---|
| Prototyper | 새로운 아이디어 발산 | 산출물 다수가 실제로 출시되지 않음. 탐색 비용을 흡수하는 역할 |
| Builder | 프로토타입 → 프로덕션 전환 | 아이디어와 실제 동작하는 시스템 사이의 간극을 빠르게 메움 |
| Sweeper | UI 정리, 코드/시스템 단순화, 언쉬핑, 성능 최적화 | 기술 부채 감소, 유지보수성 향상에 직접 기여 |
| Grower | 이미 만들어진 제품의 반복 개선 | PMF(Product-Market Fit) 향상이 목표 |
| Maintainer | 성숙한 시스템의 보안·안정성·속도·효율 관리 | 스케일링 국면에서 시스템 신뢰성을 책임짐 |
이 다섯 개는 순서대로 이어지는 파이프라인이라기보다, 동시에 필요한 역량의 집합에 가깝다. 한 명의 엔지니어가 새 기능을 실험적으로 프로토타이핑(1)한 뒤 직접 프로덕션에 배포(2)하고, 시간이 지나 그 시스템의 기술 부채를 정리(3)하는 흐름을 한 사람이 모두 소화하는 경우도 드물지 않다.
핵심 주장: 아키타입은 직무와 무관하다
이 프레임에서 가장 실무적으로 의미 있는 지적은, 이 다섯 가지가 직무(job title)와 독립적인 축이라는 점이다. Cherny는 Anthropic 내부에서도 디자이너, 엔지니어, PM, 데이터 사이언티스트 각각의 그룹 안에 1~3번 유형이 고르게 분포한다고 언급한다.
즉 “프론트엔드 엔지니어”라는 직함만으로는 그 사람이 새로운 걸 계속 만들어내는 프로토타이퍼인지, 기존 시스템을 정교하게 다듬는 스위퍼인지 알 수 없다. 채용 인터뷰나 팀 빌딩에서 직무 라벨 대신 이 아키타입 축으로 사람을 평가하면 훨씬 정밀한 팀 설계가 가능해진다는 함의가 있다.
제품 생애주기별 필요 조합
Cherny는 제품이 처한 단계에 따라 필요한 아키타입 조합이 달라진다고 정리한다.
Pre-PMF : Prototyper + Builder + Sweeper (1+2+3)
Growing / PMF : Builder + Sweeper + Grower + a little Maintainer (2+3+4, some 5)
Strong PMF : Sweeper + Grower + Maintainer + a little Builder (3+4+5, some 2)이 모델을 팀 리소스 배분에 대입해보면:
- 0→1 단계: 실험과 구현 속도가 생명이므로 Builder 비중이 높아야 하고, Prototyper의 발산을 Sweeper가 즉시 정리해줘야 기술 부채가 누적되지 않는다.
- PMF 확보 후 성장 단계: Grower가 핵심이 되지만, 여전히 Builder와 Sweeper가 새 기능 구현과 코드 정리를 뒷받침해야 하며, 이 시점부터 소규모의 Maintainer 역량(모니터링, 안정성)이 필요해지기 시작한다.
- 성숙 단계: Maintainer가 시스템 신뢰성을 책임지는 가운데, Grower가 지속적인 개선을 이어가고, Sweeper가 누적된 복잡도를 계속 덜어낸다. Builder는 이 단계에서 상대적으로 적은 비중만 필요하다.
실무 적용: 팀 구성에 던지는 질문
이 프레임을 실제 팀 운영에 적용한다면 다음과 같은 질문으로 이어질 수 있다.
- 현재 우리 제품은 어느 단계에 있는가? — 그에 따라 필요한 아키타입 조합이 다르므로, 채용/배치 우선순위를 재점검할 필요가 있다.
- 팀원 각자는 어떤 아키타입에 강한가? — 직무 타이틀이 아니라 실제 업무 패턴을 기준으로 재평가해보면, 조직 내 숨겨진 역량 분포가 드러날 수 있다.
- 한 사람이 여러 아키타입을 오갈 수 있는 유연성이 팀에 있는가? — 특히 소규모 팀이나 프리랜서/1인 개발 환경에서는 한 사람이 Prototyper~Maintainer 전 구간을 커버해야 하는 경우가 많고, 이 프레임은 그 전환을 언어화하는 데 유용하다.
마무리
Cherny는 글을 “미래의 프로덕트 역할은 지금의 도메인 기반 직함보다 이런 형태에 가까워지지 않을까?”라는 질문으로 맺는다. AI 도구가 구현의 물리적 장벽을 낮추는 만큼, 조직이 사람을 평가하고 배치하는 축도 “무엇을 만들 줄 아는가”에서 “어떤 방식으로 문제에 접근하는가”로 옮겨갈 가능성이 있다는 관찰로 읽힌다.