직군이 녹는다 Claude Code 팀의 5가지 아키타입

직군 이름이 의미를 잃어갈 때

"백엔드 개발자를 뽑습니다"라는 문장은 그 사람이 실제로 어떤 일을 잘하는지 거의 알려주지 않는다. AI 도구가 직군 사이의 벽을 허물수록 이 문제는 심해진다. 엔지니어가 디자인을 만지고, 디자이너가 프로토타입을 코드로 짜고, PM이 데이터 파이프라인을 돌리는 팀에서 직군명은 점점 명함 장식에 가까워진다.

Claude Code를 만든 Anthropic의 Boris Cherny가 이 지점을 건드리는 글을 올렸고, 사흘 만에 조회 300만을 넘겼다. 질문은 하나다. 직군이 하나의 역할로 녹아내리고 있다면, 앞으로 사람을 구분하는 축은 무엇이 되어야 하는가?

그가 자기 팀을 들여다보고 꺼낸 답은 직군이 아니라 다섯 개의 아키타입(archetype) 이다. 다만 분류 자체보다 그가 붙인 두 개의 단서가 이 글의 진짜 내용이다. "이 역할들은 직무와 상관이 없더라"는 것, 그리고 "제품 단계에 따라 필요한 조합이 달라진다"는 것.

1. 프로토타이퍼 (Prototyper)

완전히 새로운 아이디어를 내는 사람. 아이디어를 쏟아내지만 그중 대부분은 출시되지 않는다.

"대부분 안 나간다"는 단서를 원문이 이 아키타입에만 붙였다는 점을 눈여겨볼 만하다. 이 자리의 성과는 채택률이 아니라 시도 횟수로 재야 한다는 선언이다. 그걸 인정하지 않는 조직에서 프로토타이퍼의 다른 이름은 "일만 벌이고 안 끝내는 사람"이다.

2. 빌더 (Builder)

프로토타입이나 아이디어를 빠르게 프로덕션 수준의 제품과 인프라로 바꿔내는 사람.

'만들 줄 아는 사람'이 아니라 '프로덕션까지 끌고 가는 사람'이다. 데모와 제품 사이의 거리를 아는 사람이라면 이 구분이 왜 필요한지 안다. 다섯 아키타입 중 유일하게 세 단계 조합 모두에 — 주력으로든 보조로든 — 이름을 올린 자리이기도 하다.

3. 스위퍼 (Sweeper)

UI를 정리하고, 코드와 시스템을 단순화하고, 기능을 걷어내고(unship), 성능을 최적화하는 사람.

목록에서 가장 눈에 띄는 단어는 unships다. 빼는 일을 누군가의 '뒷정리'가 아니라 독립된 아키타입의 본업으로 세운 것. 기능을 붙인 사람은 늘 이름이 남지만 걷어낸 사람은 남지 않는 게 보통의 조직인데, Cherny는 그 일을 전면에 올렸다. 세 가지 제품 단계 전부에서 주력으로 꼽힌 유일한 아키타입이라는 점이 그 무게를 말해준다.

4. 그로워 (Grower)

이미 만들어진 제품을 반복 개선해 PMF(Product-Market Fit)를 끌어올리는 사람.

0→1이 아니라 1→10의 사람이다. 빌더와 붙어 있는 것처럼 보이지만 원문은 둘을 명확히 가른다. PMF 이전 단계의 팀 조합에 그로워가 없다는 점이 그 증거다 — 개선할 대상이 아직 없는데 개선의 달인을 앉혀둘 이유가 없다.

5. 메인테이너 (Maintainer)

성숙한 시스템을 맡아 규모가 커져도 안전하고, 안정적이고, 빠르고, 효율적이도록 지키는 사람.

다섯 중 가장 저평가되기 쉬운 자리다. 잘하면 아무 일도 일어나지 않는 것이 성과이기 때문이다. 원문의 배치에서 이 아키타입은 PMF 이후에만 등장한다. 뒤집어 말하면, 초기 팀에 메인테이너 성향의 사람을 먼저 앉히는 건 사람이 아니라 배치가 틀린 것이다.

핵심은 분류가 아니라 조합

다섯 개 목록은 사실 서론이다. Cherny가 하고 싶었던 말은 이쪽이다.

• 많은 사람이 2개, 때로는 3개 아키타입에 걸쳐 있다. 하나로 딱 떨어지는 사람이 오히려 드물다.
• 아키타입은 직무와 연동되지 않는다. Anthropic 안에서도 어떤 디자이너는 프로토타이퍼고, 어떤 디자이너는 빌더고, 또 어떤 디자이너는 스위퍼다. 엔지니어도, PM도, DS도 마찬가지.
• 건강한 팀의 조건은 좋은 사람의 합이 아니라 제품 단계에 맞는 믹스다.

제품 단계별 필요한 조합

원문에서는 세 줄의 텍스트인데, 표로 세워놓으면 두 가지 패턴이 드러난다.

1. 스위퍼는 어디에나 있다. 정리하고 걷어내는 일은 제품이 어느 단계든 빠지지 않는다. 복잡도는 단계를 가리지 않고 쌓이기 때문이다.
2. 무게중심이 1번에서 5번으로 흐른다. 단계가 올라갈수록 앞 번호가 빠지고 뒷 번호가 들어온다. 제품은 성장했는데 팀 구성이 창업 초기 그대로라면, 그 팀은 열심히 일하면서 어긋나고 있는 중이다.

Cherny는 단정 대신 질문으로 닫는다. 미래의 프로덕트 역할은 오늘의 도메인별 직군보다 이런 모습에 가깝지 않을까?

반론도 만만치 않았다

답글 900여 개가 달렸고, 가장 호응을 받은 건 동의가 아니라 반론이었다.

"아키타입이라는 발상 자체가 싫다" — Kun Chen의 답글(좋아요 700+). 사람들은 분류를 보는 순간 "아, 내가 저거구나" 하고 자신을 의심하기를 멈춘다. 실제로는 프로젝트가 굴러가는 동안 한 사람의 역할이 계속 바뀌어야 하는데, 라벨은 그 변화를 가로막는다는 지적이다. MBTI가 자기이해의 도구가 아니라 자기합리화의 도구로 소비되는 것과 같은 경로다.

"그냥 지어낸 것 같은데" — Christoph Nakazawa의 한 줄. 데이터가 아니라 한 팀을 눈으로 본 인상 아니냐는 것이다.

둘 다 틀린 말이 아니고, 원문도 그걸 부정할 생각이 없어 보인다. 글은 "Claude Code 팀을 볼 때"라는 한정으로 시작해 물음표로 끝난다. 검증된 프레임워크가 아니라 잘 만든 관찰 메모로 읽는 게 원문의 온도에 맞다.

결론: 라벨로 쓰면 망하고, 좌표로 쓰면 쓸모 있다

"나는 스위퍼 인간"처럼 정체성으로 소비하는 순간 Kun Chen의 지적이 그대로 적중한다. 이 분류의 쓸모는 자기 규정이 아니라 다른 데 있다.

• 팀 진단: 우리 제품은 어느 단계이고, 지금 팀에 몰려 있는 아키타입은 무엇인가. PMF도 없는데 메인테이너만 셋이거나, 성숙한 제품에 프로토타이퍼만 남아 있지는 않은가.
• 커리어 좌표: 직무명 대신 "내가 지금 어떤 아키타입의 일을 하고 있는지"로 자신을 설명해 보면, 옮겨갈 자리가 정말 내가 잘하는 종류의 일인지 훨씬 빨리 판별된다.
• 채용 언어: "시니어 프론트엔드 개발자"보다 "PMF 이후 제품을 정리하고 걷어낼 사람"이 지원자와 회사 양쪽에 훨씬 정확한 정보를 준다.

직군이 정말 녹아내리고 있는지는 아직 모른다. 다만 "당신은 무슨 직군입니까"보다 "당신은 제품의 어느 단계에서 강합니까"가 더 많은 것을 알려준다는 것만은, 이 논쟁의 어느 편에 서든 부정하기 어렵다.

이 글을 읽을 때 감안할 점

• 원문은 트윗 한 편이다. 논문도, 사내 공식 프레임워크도 아니다.
• 근거는 Anthropic Claude Code 팀 한 곳의 관찰이다. 조직 규모와 문화가 다르면 그대로 적용되지 않는다.
• 각 아키타입의 해설과 "핵심은 조합" 이하의 분석은 원문에 없는 필자의 정리다. 원문이 직접 말한 것은 다섯 개의 정의, 2~3개 중첩, 직무 비연동, 단계별 조합 세 줄, 그리고 마지막 질문뿐이다.