직함은 그대로인데 하는 일이 달라지기 시작했다는 얘기를 요즘 자주 듣습니다. 분명 PM인데 요즘 하는 일은 3년 전 PM이 아니고, 디자이너라면서 코드를 만지고 있고, 백엔드 개발자인데 제품 기획 회의에 앉아 있고요. 저도 비슷한 위화감이 들었는데, 한동안 이름 붙이지 못한 채 지나쳤습니다. 그런데 앤트로픽에서 클로드 코드(Claude Code)를 총괄하는보리스 체르니(@bcherny)가 그 변화를 트윗 한 장으로 꽤 깔끔하게 정리해줬더라고요.

지난 6월 28일에 올린 이 트윗은 이틀 만에 좋아요 1만 9천, 리트윗 2천을 넘겼습니다. 답글만 856개가 달렸고요. 그는 "엔지니어링, 프로덕트, 디자인, 데이터 사이언스 같은 직군이 새로운 종류의 역할로 녹아드는 지금(melt into a new kind of role), 앞으로 역할이 어떤 모습일지 생각해봤다"며 자기 팀에서 관찰한 다섯 가지 유형, 그러니까 아키타입을 제시합니다.

이 아키타입을 먼저 살펴보고, 이것이 어떤 의미인지 어떻게 활용하면 좋을지 생각해본 내용을 공유해보겠습니다.

체르니가 본 다섯 가지 유형

체르니가 꼽은 다섯은 프로토타이퍼, 빌더, 스위퍼, 그로워, 메인테이너입니다.

프로토타이퍼는 완전히 새로운 아이디어를 쏟아냅니다. 대부분은 출시되지 않고 버려지죠. 국내로 옮기면 해커톤 이틀 만에 데모 세 개를 뚝딱 만들어 오는 그 사람입니다. 빌더는 그 프로토타입을 실제 프로덕션급 제품·인프라로 빠르게 옮깁니다. "돌아가는 데모"를 "고객이 쓰는 서비스"로 만드는 역할이고요. 스위퍼는 UI를 정리하고 코드와 시스템을 단순화하고 안 쓰는 기능을 걷어내고 성능을 최적화합니다. 리팩터링과 기술 부채 청소를 즐기는 사람이 여기 해당됩니다.

그로워는 이미 만든 제품을 반복해서 개선하며 PMF, 그러니까 제품-시장 적합성을 끌어올립니다. 지표 보고 A/B 테스트 돌리고 리텐션을 파는 그로스 담당이 떠오르죠. 마지막으로 메인테이너는 성숙한 시스템을 안전하고 안정적이고 빠르게 유지합니다. 대규모 트래픽을 몇 년째 사고 없이 떠받치는 인프라·SRE 쪽이고요.

체르니는 이와 같은 아키타입을 소개하며 두 가지 내용을 덧붙였습니다.

먼저, 많은 사람들이 이중 2~3가지 역할을 하고 있으며, 이 역할들이 직무와 크게 연결되지 않는다고 합니다. 앤트로픽만 봐도 어떤 디자이너는 프로토타이퍼(유형 1)에, 어떤 디자이너는 빌더(유형 2)에, 또 어떤 디자이너는 스위퍼(유형 3)에 해당하고, 엔지니어도 PM도 데이터 사이언티스트도 마찬가지라는 것입니다.

두 번째로, 건강한 프로덕트 팀은 프로덕트의 단계에 따라 이 아키타입의 사람들이 섞여 있어야 한다고 말합니다. PMF 이전 초기 제품은 프로토타이퍼·빌더·스위퍼의 힘이 필요하고 PMF를 잡고 성장하는 제품은 빌더·스위퍼·그로워에 유지보수를 조금 얹은 조합이 필요하다고 제안합니다. 성숙한 제품은 스위퍼·그로워·메인테이너에 약간의 빌더로 돌아간다고 하고요. 같은 사람이라도 초기 스타트업에서는 딱 맞다가 성숙기 조직에 가면 상황이 다를 수 있다는 뜻이기도 합니다.

앤트로픽 블로그에 따르면 클로드 코드 팀은 애초에 ‘Member of Technical Staff’라는 하나의 직무 타이틀 아래서 프로덕트·디자인·인프라·리서치를 다 다루는 구조로 굴러간다고 하는데요. 역할 별로 직함을 나누지 않으니, ‘모두가 다 한다’는 것이 기본 전제가 되는 것입니다. 보리스 체르니가 다섯 가지 아키타입을 제안하게 된 배경도 직함이 없는 팀에서 사람들이 실제로 어떻게 일하는지를 관찰한 결과가 아닐까 합니다.

이미 시작된 변화

사실 이같은 이야기를 하는 것이 체르니만은 아닙니다. 이미 직군이 ‘녹는’ 현상은 업계 곳곳에서 나타나고 있고, 새로운 이야기도 아닙니다. 세일즈를 하는 개발자, 개발을 하는 디자이너에 대한 이야기가 주변에서도 종종 들려오고요. 운영팀이 기존에 개발자에게 요청할 업무들을 직접 하게 됐다는 이야기도 심심치 않게 들리죠. 얼마 전 레니의 뉴스레터에는코덱스 앱 리드가 출연해 팀에서도 역할이 많이 붕괴되고 있다고 말했습니다. PM이 기술 용어를 쓰고 코드를 짜거나 디자이너도 엔지니어링을 말한다는 것이죠.

Shopify CEO 토비 뤼트케는 지난해 사내 메모에서 "반사적인 AI 사용은 이제 Shopify의 기본 기대"라고 선언했습니다. 인력을 더 요청하기 전에 왜 AI로는 그 일을 못 하는지부터 증명하라는 규칙까지 붙였고요. 샘 올트먼은 앞으로 회사가 1인 혹은 소규모 팀으로 굴러갈 거라고 봅니다. 한 사람짜리 10억 달러 회사가 나오는 것도 가능하다고요. AI를 활용해 회사를 위한 목표를 달성하는 것이 중요하지, 어떤 직군에서 어떤 성과를 내느냐의 구분은 중요하지 않게 된 것입니다.

한국도 마찬가지입니다. 토스는 매주 금요일을 'AI Surf Day'로 두고 AI 실험 시간을 제도화했습니다. AI Surf Club이라는 자발적 모임이 200개 가까이 생겼고 팀 워크숍을 이끄는 에반젤리스트가 142명이라고 하고요. 토스의한 마케팅 팀은 아예 직무를 Builder·Curator·Operator·Scouter라는 역할로 나눠 일합니다. 마케터라는 직함이 아니라 지금 무슨 실행을 하느냐로 팀을 짠 거죠. 체르니의 아키타입과 다른 이름, 같은 발상입니다.

잡코리아는 미국에서 소프트웨어 개발자 채용공고가 1년 새 35% 줄었다는 인디드 집계를 인용하며, 국내에도 곧 비슷한 흐름이 올 거라 보고 '한 분야는 깊게, 여러 분야는 넓게' 아는 T자형 개발자를 생존 전략으로 제시했고요. 카카오는 AI 조직을 목적형 스튜디오 구조로 바꿔 배포 주기를 한 달로 당겼다고 합니다. 더 이상 기존의 기능적으로 분리된 프로덕트 팀이 일하던 방식은 AI 시대에 맞지 않게 된 것이죠.

직군이 오히려 분화된다?

그런데 반대로 직군이 오히려 분화된다는 주장도 있습니다. 대표적으로 앤드루 응은 AI 엔지니어라는 직군이 성숙하면 오히려 다시 쪼개진다고 합니다. 수십 년 전 소프트웨어 엔지니어가 프론트·백엔드·모바일·데브옵스로 갈라졌던 것처럼, AI FDE·LLMOps·Evals·Data·Harness 엔지니어 같은 전문 직군으로 세분화될 거라고 봅니다.

하지만 이 주장도 사실 같은 방향을 향하고 있다고 생각합니다. "전통적인 소프트웨어 엔지니어 타이틀은 유효기간이 지났다"는 것이죠. 녹아서 하나가 되든 새롭게 여럿으로 갈라지든, 예전 그 직함 그대로 머물지는 않는다는 것은 전제로 하고 있습니다.

이러한 직군이 녹는 현상이 정말 AI 효과냐는 의문도 제기됩니다. 체르니 트윗의 상위 답글에서 가장 많은 지지를 받은 게 동의가 아니라 반박이었다는 점이 흥미롭습니다. 모뎀 창업자이자 전 센트리 소속인 벤 비니거는 트위터에 이렇게 적었습니다. "사람들이 소프트웨어 조직이 원래 어떻게 굴러가는지를 이제야 배우는 것 같은데, 그걸 그냥 정상적인 팀 동학인데 AI 탓으로 잘못 돌리고 있다." 프로토타이퍼든 메인테이너든, 잘 돌아가던 팀엔 예전부터 다 있던 역할이라는 거죠. AI가 새로 만든 게 아니라 원래 있던 걸 AI라는 이름표에 갖다 붙였을 뿐이라는 반박입니다.

또 레니의 팟캐스트에 출연한 코덱스 앱 리드 앤드류 앰브로시노는 그렇다고 직군이 아예 사라진다고 딱 잘라 생각하는 것은 아닙니다. 넓이로나 깊이로나 한 사람이 모든 걸 할 수는 없고, 그동안 제품을 만들기 위해 쌓아 올린 모범 사례가 있으며, 그 모범사례를 가진 전문 영역이란 건 여전히 중요하다는 것입니다. 다만 역할을 바꾸기가 쉬워질 거라고 보고 있죠.

그래서 실무자인 나는 무엇을 하나

사실 직군이 정말로 녹냐, 아니냐 그 자체는 중요하지 않은 것 같습니다. 소속 직군에 상관 없이 우리가 우리의 일을 어떻게 정의할지는 언제나 중요했던 것 같습니다. 같은 직함을 갖고 있어도 일하는 방식이나 일에 대한 태도는 모두 다르니까요.

다만 아무래도 일에서 AI를 점점 더 적극적으로 활용하게 되는 만큼, 기존의 일하는 방식이 달라지고 있는 것도 사실이고요. 개발자가 하는 일도 이미 코드 작성이 아니라 판단과 검수라는 프레임으로 변하게 된 지도 꽤 됐습니다. 변화가 현실로 다가오고 있으니, 보리스 체르니가 제시한 아키타입으로 지금 시점의 내 일의 변화를 한번 짚어보는 것도 좋다고 생각합니다. 다른 의견도 있을 수 있지만, 저는 현재의 변화를 바라보는 한 가지 좋은 프레임워크가 아닐까 합니다.

이 아키타입을 저는 이렇게 활용해보았습니다.

먼저, 내 아키타입을 이해합니다. 직함 말고 실행 방식으로 나를 다시 보는 것입니다. 나는 새 아이디어를 쏟아낼 때 신나는 사람인가, 남이 벌여놓은 걸 실제 제품으로 완성할 때 몰입하는 사람인가, 지저분한 코드를 걷어낼 때 제일 개운한 사람인가. 직함은 'PM'이나 '프론트엔드'라고 하나로 찍혀 있어도, 실제로 일하는 방식은 두세 유형에 걸쳐 있을 겁니다. 그 조합이 지금의 나예요.

저의 경우에는 프로토타이퍼 성향이 아주 강한 편입니다. 빠르게 뭔가를 만들어보고 일단 돌아가면 만족하는 편이라서, 오히려 그걸 꾸준이 유지하고 개선하는 역량이 좀 약합니다.

그다음으로, 내 제품이 어느 단계인지 살펴봤습니다. 체르니 말대로 PMF 이전이냐, 성장 중이냐, 성숙기냐에 따라 지금 팀이 필요로 하는 아키타입 조합이 다릅니다. 내가 프로토타이퍼 성향이 강한데 회사 제품은 이미 성숙기에 접어들어 스위퍼·메인테이너를 원한다면, 그 간극이 바로 요즘 느끼는 위화감의 정체일 수 있어요. 내 성향과 팀이 요구하는 조합을 나란히 놓고 보면 그 어긋남이 눈에 들어옵니다. 제가 딱 그렇습니다. 다만 요즘엔 회사에서도 AI로 이런저런 새로운 시도를 하게 되다 보니 그나마 프로토타이퍼적인 성향이 만족되고 있는 것 같습니다.

이런 분석에만 멈추면 달라지는 게 없을 것입니다. 마지막으로 한 발 더 나아가서, 그렇다면 지금 내가 약한 부분은 어떤 부분인지, 그걸 보강하려면 어떻게 해야 하는지를 생각해보는 것이 중요한 것 같습니다. 특히나 요즘 시대에는 약한 부분은 AI로 보강할 수 있습니다. 저같은 경우에는 한 가지 아이디어를 실행하는 중간에 그다음 아이디어를 실행할 생각에 막 들뜰 때가 있습니다. 그래서 저는 제가 클로드코드랑 이야기하다가 갑자기 딴 길로 샐 때 실행을 멈추라는 명령을 심어뒀습니다.

이런 프레임워크는 팀을 짜는 리더에게도 유용할 것 같습니다. 지금 우리 제품이 어느 단계고, 그 단계에 필요한 아키타입 조합이 뭔지, 팀에 어떤 유형이 비어 있는지를 직함 대신 실행 방식으로 그려보는 거죠.

아키타입에 갇히지는 마세요

마지막으로 체르니 트윗 답글 중에 인상 깊은 트윗을 소개하려합니다. "자기를 특정 아키타입으로 분류하는 건 종종 사람이 야망을 넓히는 걸 가로막는다. 유연하게 있고, 목표 달성에 중요한 것에 몰두하고, 시간이 지나며 계속 흐려질 역할 경계에는 덜 신경 써라."

아키타입은 지금 이 순간의 내 상태를 읽어보는 프레임일 뿐, 나를 가둬두는 상자 같은 건 아닙니다. 사실 중요한 건 내 일을 통해 가치를 만들어내는 것이지, 내가 어떤 유형인지 이해하는 것 자체가 어떤 가치를 만들어내지는 않으니까요. 프로젝트가 바뀌면 나도 다른 아키타입의 역량을 펼쳐보일 수도 있습니다. 위에 소개한 말이 기우처럼 보이는 측면도 있지만, 한번쯤 생각해봐야 할 지점 같습니다. 일을 하다보면 종종 나도 모르게 주어진, 정해진 틀 안에서만 일하려 하기도 하니까요.

AI로 인한 변화가 너무 빨라 기존의 프레임워크로는 변화를 읽기가 어려워졌습니다. 그러다 보니 이런 앞서가는 사람들이 제안하는 프레임워크를 참고해보는 것도 지금의 위치를 이해하기에 좋은 방법이 아닐까 합니다. 지금 내가 어디에 서 있는지 한번 짚어보고, 내 제품이 그자리를 원하는지, 그렇지 않다면 내가 어느 쪽으로 조금 움직여야 할지를 한번 진단해보고, 또 다음에 프로덕트가 혹은 프로젝트가 바뀌면 다시 이 아키타입으로 내 상황을 바라보는 것도 앞을 모르는 세상에서 나름대로 좋은 길잡이가 되지 않을까 합니다.