AI Work · Claude Code · Organization Design
클로드 코드 창시자가 말하는 AI 시대의 다섯 가지 일하는 사람의 원형
AI가 코딩, 디자인, 분석의 실행 장벽을 낮추면 직함보다 더 중요한 질문이 남는다. “이 사람은 어떤 국면에서 일을 앞으로 밀어내는가?” Boris Cherny의 다섯 원형은 그 질문을 팀 구성과 커리어 언어로 바꿔준다.
한 문장 요약
Boris Cherny가 제안한 핵심은 단순하다. AI 시대의 일은 “엔지니어냐, PM이냐, 디자이너냐, 데이터 사이언티스트냐” 같은 직무 경계만으로 설명하기 어려워지고 있으며, 앞으로는 아이디어를 내는 사람, 실제 제품으로 만드는 사람, 복잡함을 치우는 사람, 시장에 맞게 키우는 사람, 큰 시스템을 안정적으로 지키는 사람이라는 일의 원형이 더 선명해질 수 있다는 것이다.
이 관점이 흥미로운 이유는 직무를 부정해서가 아니다. 오히려 직무 위에 한 겹 더 실용적인 렌즈를 얹는다. 같은 백엔드 엔지니어라도 어떤 사람은 새 문제를 발견하고 실험을 폭발적으로 벌이는 데 강하고, 어떤 사람은 오래된 시스템의 장애 가능성을 줄이고 운영 비용을 낮추는 데 강하다. 둘 다 엔지니어지만 팀이 기대해야 할 기여는 다르다. AI 도구가 실행 자체를 더 싸게 만들수록 이런 차이는 더 잘 보인다.
이 글의 결론: 다섯 원형은 MBTI처럼 사람을 고정하는 이름표가 아니다. 제품의 단계, 팀의 병목, 개인의 성장 방향을 빠르게 토론하기 위한 작업 언어다. 좋은 팀은 원형을 고르게 갖추되, 제품 단계에 따라 무게중심을 바꾼다.
왜 지금 이 구분이 나왔나
오랫동안 조직은 기능 단위로 사람을 나눴다. 요구사항과 우선순위는 PM이 정하고, 화면은 디자이너가 만들고, 코드는 엔지니어가 구현하고, 데이터는 분석가가 해석했다. 이 구조가 작동한 이유는 각 영역의 도구와 지식이 충분히 어려웠기 때문이다. “무엇을 다룰 수 있는가”가 사람을 구분하는 강한 기준이었다.
하지만 Claude Code, Codex, Cursor, Figma의 AI 기능, 데이터 분석 에이전트 같은 도구가 등장하면서 실행의 경계가 낮아졌다. 디자이너가 동작하는 프로토타입을 만들 수 있고, PM이 데이터 쿼리 초안을 뽑을 수 있으며, 엔지니어가 사용자 흐름과 카피까지 더 빠르게 실험할 수 있다. 물론 이 말이 모든 사람이 모든 일을 같은 수준으로 잘한다는 뜻은 아니다. 다만 “할 수 있느냐”보다 “어떤 문제를 어떤 순서로 밀어붙이느냐”가 더 중요해지는 순간이 늘어났다.
Claude Code 공식 문서도 이 변화를 잘 보여준다. Claude Code는 단순히 답변을 하는 챗봇이 아니라 코드베이스를 읽고, 파일을 고치고, 명령을 실행하며, 여러 개발 도구와 연결되는 에이전트형 코딩 환경이다. 이처럼 도구가 실제 작업 표면으로 들어오면 사람에게 남는 가치는 키보드를 얼마나 빨리 치느냐가 아니라 무엇을 시도할지 정하고, 어느 정도 품질에서 멈출지 판단하고, 실패한 실험을 버리고, 시스템이 무너지지 않게 균형을 잡는 능력에 가까워진다.
Business Insider는 이 논의를 “AI 시대에 직함이 바뀌고 있다”는 흐름으로 소개했다. 기사에서는 전통적인 직함이 합쳐지고, “builder” 같은 표현이 넓게 쓰이며, 관리자라는 단어 대신 player-coach나 org lead 같은 말이 등장하는 움직임을 함께 다룬다. 중요한 점은 새 이름을 붙이는 데 있지 않다. 조직도가 실제 일을 설명하지 못하는 장면이 많아졌다는 신호가 중요하다.
5가지 원형 정리
다섯 원형은 직무가 아니라 일의 국면을 가리킨다. 어떤 사람은 1개 원형에 뚜렷하게 맞고, 많은 사람은 2개, 때로는 3개 원형을 함께 가진다. 특히 AI 도구를 잘 쓰는 사람일수록 여러 원형 사이를 오가지만, 그래도 각자가 가장 자연스럽게 에너지를 내는 국면은 다르다.
| 원형 | 핵심 기여 | 좋은 신호 | 주의할 점 |
|---|---|---|---|
| 1. Prototyper 프로토타이퍼 |
새 아이디어를 빠르게 만들고, 가능성을 눈에 보이게 만든다. | 짧은 시간에 여러 대안을 만들고, 실패한 시안을 미련 없이 버린다. | 검증 없이 데모만 늘리면 팀의 집중력이 흐려진다. |
| 2. Builder 빌더 |
살아남은 아이디어를 실제 사용자에게 줄 수 있는 제품과 인프라로 바꾼다. | 프로토타입의 빈틈을 메우고 배포, 오류 처리, 운영 동선을 잡는다. | 너무 빨리 제품화하면 아직 검증되지 않은 방향에 비용을 묶는다. |
| 3. Sweeper 스위퍼 |
복잡함을 치우고, UI와 코드와 시스템을 단순하게 만든다. | 기능을 더하기보다 빼고, 성능과 이해 가능성을 높인다. | 정리의 이름으로 필요한 실험까지 멈추면 제품 학습이 둔해진다. |
| 4. Grower 그로어 |
이미 나온 제품을 반복 개선해 시장 적합성과 성장성을 끌어올린다. | 데이터, 사용자 피드백, 온보딩, 가격, 포지셔닝을 함께 본다. | 성장 지표만 보면 장기 품질이나 사용자의 신뢰를 갉아먹을 수 있다. |
| 5. Maintainer 메인테이너 |
성숙한 시스템을 안전하고 신뢰할 수 있고 빠르고 효율적으로 유지한다. | 장애를 줄이고, 보안과 비용과 운영 품질을 조용히 개선한다. | 초기 제품에 과도한 안정성 기준을 적용하면 속도가 사라진다. |
프로토타이퍼는 “가능한가?”를 보여준다. 빌더는 “실제로 돌아가는가?”를 만든다. 스위퍼는 “이해 가능하고 가벼운가?”를 묻는다. 그로어는 “시장이 더 강하게 반응하는가?”를 본다. 메인테이너는 “규모가 커져도 계속 믿을 수 있는가?”를 책임진다. 이 5개 질문을 한 팀이 모두 다뤄야 제품은 버틴다.
특히 스위퍼는 AI 시대에 더 중요해진다. AI는 만들기를 쉽게 하지만, 쉬운 만들기는 곧 쉬운 누적으로 이어진다. 초안 코드, 임시 기능, 중복 플로우, 어중간한 자동화가 빠르게 쌓인다. 팀이 매주 더 많은 것을 만들 수 있게 됐다면, 매주 더 과감하게 없앨 줄도 알아야 한다. “unship”, 즉 출시한 것을 걷어내는 능력은 성숙한 제품에서 희소한 기술이 된다.
AI 도구가 바꾸는 것은 직무가 아니라 병목이다
Claude Code 문서는 이 도구가 터미널, IDE, 데스크톱 앱, 브라우저에서 동작하며 개발 작업을 자동화하고 여러 파일과 도구를 오가며 기능 구현과 버그 수정을 돕는다고 설명한다. 이것은 “엔지니어가 필요 없다”는 말과 다르다. 병목이 달라진다는 말에 가깝다.
예전 병목
손으로 구현하는 속도, 툴 숙련도, 특정 영역의 진입 장벽, 역할 간 핸드오프 비용.
새 병목
문제 정의, 좋은 검증 신호, 컨텍스트 관리, 불필요한 복잡성 제거, 제품 단계에 맞는 판단.
그래서 다섯 원형은 AI 시대의 “새 직함”이라기보다 병목을 읽는 도구다. 지금 우리 팀이 느린 이유가 아이디어가 부족해서인지, 빌드 품질이 부족해서인지, 너무 많이 쌓여서인지, 성장 루프가 약해서인지, 운영 신뢰가 낮아서인지 구분하게 해준다. 직무명만 보면 “엔지니어가 부족하다”가 되지만, 원형으로 보면 “스위퍼가 없다” 또는 “그로어 없이 빌더만 많다”가 될 수 있다.
제품 단계별로 필요한 조합
Cherny의 틀에서 가장 실용적인 부분은 제품 단계별 조합이다. 모든 팀이 항상 5개 원형을 같은 비율로 필요로 하지는 않는다. 아직 시장이 원하는지 모르는 제품과 수백만 명이 쓰는 성숙한 제품은 전혀 다른 긴장을 갖는다.
PMF 이전에는 프로토타이퍼가 없으면 출발점이 빈약하고, 빌더가 없으면 실험이 실제 사용자 앞에 가지 못하고, 스위퍼가 없으면 실패한 아이디어가 계속 쌓인다. 이 단계에서 메인테이너만 너무 강하면 아직 검증되지 않은 제품을 지나치게 안정적으로 만들다가 배울 기회를 놓친다.
성장기에는 시장 반응을 확인했으니 더 많이 만들고, 더 많이 걷어내고, 더 정교하게 키워야 한다. 이때 빌더는 확장 가능한 제품화를 맡고, 스위퍼는 복잡성 증가를 억제하고, 그로어는 온보딩, 가격, 전환율, 리텐션, 메시지를 반복 개선한다. 사용자가 늘어나므로 메인테이너의 역할도 조금씩 커진다.
성숙기에는 프로토타이핑의 비중이 상대적으로 줄어든다. 이유는 보수적이어서가 아니라 시스템의 실패 비용이 커졌기 때문이다. 이미 신뢰를 얻은 제품에서 가장 큰 위험은 더 만들지 못하는 것이 아니라 너무 많이 붙이고, 너무 느려지고, 너무 자주 깨지는 것이다. 이때 스위퍼와 메인테이너는 성장의 반대편이 아니라 성장의 조건이다.
개인은 이 틀을 어떻게 써야 하나
개인에게 이 틀은 자기소개 문장을 바꾸는 데 유용하다. “저는 프론트엔드 개발자입니다”보다 “저는 초기 제품에서 프로토타입을 빨리 만들고, 살아남은 흐름을 배포 가능한 제품으로 바꾸는 프로토타이퍼 겸 빌더입니다”가 훨씬 더 많은 정보를 준다. “저는 데이터 분석가입니다”보다 “저는 성장기 제품에서 퍼널 병목을 찾고 실험 우선순위를 정하는 그로어입니다”가 더 선명하다.
물론 직무 전문성은 사라지지 않는다. React를 잘 쓰는 능력, 데이터 모델링, 디자인 시스템, 보안, 인프라 운영은 여전히 중요하다. 다만 그것은 재료이고, 원형은 그 재료를 어느 국면에서 어떻게 쓰는지 설명한다. AI 시대에는 재료를 다루는 기본 능력 위에 “어떤 종류의 진전을 잘 만드는가”가 더 많이 드러난다.
| 자가 진단 질문 | 강하게 연결되는 원형 |
|---|---|
| 아무도 답을 모를 때, 짧은 시간에 여러 가능성을 눈에 보이게 만드는가? | Prototyper |
| 거친 시안을 안정적으로 배포 가능한 제품으로 바꾸는 과정에서 에너지가 나는가? | Builder |
| 복잡한 코드, 흐름, UI를 단순하게 만들 때 성취감이 큰가? | Sweeper |
| 제품이 나온 뒤 데이터와 사용자 반응을 보며 반복 개선하는 일이 재미있는가? | Grower |
| 큰 시스템의 장애, 보안, 비용, 성능, 운영 품질을 조용히 개선하는 데 강한가? | Maintainer |
좋은 커리어 전략은 하나의 원형에 갇히는 것이 아니라, 자신의 주 원형과 보조 원형을 의식적으로 조합하는 것이다. 초기 스타트업을 원한다면 프로토타이퍼와 빌더의 근육이 중요하다. 성장 조직으로 가고 싶다면 그로어와 스위퍼의 언어를 익혀야 한다. 플랫폼이나 보안, 인프라, 금융, 헬스케어처럼 실패 비용이 큰 영역으로 갈수록 메인테이너의 신뢰 언어가 강력한 경쟁력이 된다.
리더가 팀에 적용하는 법
팀 리더에게 이 틀은 채용과 배치의 체크리스트가 된다. “엔지니어 5명, 디자이너 1명, PM 1명”이라는 숫자는 실제 병목을 충분히 설명하지 못한다. 같은 7명이라도 모두 빌더라면 새로운 방향을 찾지 못할 수 있고, 모두 프로토타이퍼라면 출시가 계속 미뤄질 수 있다. 모두 메인테이너라면 안정적이지만 시장 학습이 느릴 수 있고, 모두 그로어라면 이미 존재하는 제품을 다듬는 데는 강하지만 0에서 1을 여는 힘이 약할 수 있다.
채용 질문
이 사람이 최근 6개월 동안 만든 진전은 어떤 종류였나? 새 가능성을 열었나, 제품화했나, 복잡성을 줄였나, 성장률을 올렸나, 신뢰를 높였나?
배치 질문
지금 제품 단계에서 가장 부족한 원형은 무엇인가? 현재 팀원이 맡은 역할이 그 사람의 자연스러운 원형과 충돌하고 있지는 않은가?
성과 질문
원형별 성과 기준이 같은가? 프로토타이퍼에게 유지보수 지표만 요구하거나, 메인테이너에게 매주 새 기능 수만 요구하고 있지는 않은가?
리뷰 질문
이번 분기 우리 팀은 무엇을 더 만들었고, 무엇을 없앴고, 무엇을 더 안전하게 만들었고, 무엇을 더 잘 팔리게 만들었나?
원형은 조직 정치의 도구가 아니라 기대치를 맞추는 도구여야 한다. 스위퍼가 기능을 삭제하자고 말할 때 “왜 부정적이냐”고 받아들이면 팀은 복잡성을 계속 떠안는다. 메인테이너가 출시 속도에 제동을 걸 때 “왜 느리냐”고만 보면 시스템 리스크가 쌓인다. 반대로 프로토타이퍼가 완성도 낮은 실험을 많이 던질 때 “왜 이렇게 미완성이냐”고만 보면 새 가능성이 줄어든다. 원형을 이해한다는 것은 각 기여를 제품 단계에 맞게 해석한다는 뜻이다.
오해와 한계
이 프레임워크에는 분명한 한계가 있다. 첫째, 한 팀을 관찰한 가설에 가깝다. 검증된 조직 이론이라기보다 Claude Code 팀이라는 특수한 환경에서 나온 날카로운 관찰이다. 따라서 모든 회사, 모든 직무, 모든 문화권에 그대로 맞는다고 보면 위험하다.
둘째, 원형은 사람을 고정시키기 쉽다. Business Insider 기사에서도 한 업계 인사는 원형이 사람들이 스스로를 하나로 정해버리고 더 이상 질문하지 않게 만들 수 있다는 우려를 제기했다. Cherny 역시 역할은 시간과 프로젝트에 따라 변한다는 취지로 동의했다. 그러므로 원형은 “나는 원래 이런 사람이야”라는 면허가 아니라 “이번 프로젝트에서 나는 어떤 모드로 기여하고 있나”라는 점검표여야 한다.
셋째, AI가 모든 원형을 대신할 것이라는 해석도 성급하다. AI는 프로토타입을 빠르게 만들고, 코드 정리를 돕고, 성장 실험의 초안을 만들고, 운영 점검을 자동화할 수 있다. 그러나 무엇을 버릴지, 무엇을 지킬지, 어느 위험을 감수할지, 어떤 사용자 경험을 선택할지는 여전히 사람의 판단이 필요하다. AI가 실행을 돕는 만큼 판단의 품질은 더 잘 드러난다.
실무적으로 가장 좋은 사용법: 사람을 분류하기 전에 일을 분류하자. 지금 해야 할 일이 탐색인지, 제품화인지, 정리인지, 성장인지, 유지인지 먼저 정하면 누구에게 맡길지, 어떤 AI 워크플로를 붙일지, 어떤 검증 지표를 둘지 더 명확해진다.
내 팀에 바로 적용하는 30분 워크숍
이 프레임워크를 회의에서 쓰고 싶다면 거창한 조직 개편부터 시작할 필요가 없다. 30분이면 충분하다. 먼저 현재 제품 단계를 정한다. PMF 이전인지, 성장기인지, 성숙기인지 팀원들이 각자 판단하게 하고 이유를 말한다. 그 다음 최근 4주 동안 실제로 시간을 쓴 일을 5개 원형 중 하나에 붙인다. 마지막으로 다음 4주에 부족한 원형이 무엇인지 합의한다.
| 시간 | 진행 | 산출물 |
|---|---|---|
| 0~5분 | 제품 단계 합의: PMF 이전, 성장기, 성숙기 중 선택 | 현재 단계 1개와 근거 3개 |
| 5~15분 | 최근 4주 업무를 다섯 원형에 매핑 | 원형별 실제 업무 목록 |
| 15~25분 | 다음 4주 병목 토론 | 부족한 원형 1~2개 |
| 25~30분 | 담당자와 검증 신호 정리 | 누가, 무엇을, 어떤 기준으로 끝낼지 |
이때 중요한 것은 “우리 팀에는 메인테이너가 없다”에서 멈추지 않는 것이다. 더 정확한 질문은 “이번 달에 메인테이너식 일이 필요한데 아무도 그 시간을 배정받지 않았다”이다. 원형은 사람의 성격보다 작업 포트폴리오를 드러낼 때 더 유용하다.
FAQ
Q1. 다섯 원형은 새 직함으로 써도 되나요?+
권장하지 않는다. 원형은 직함보다 유연해야 가치가 있다. 명함에 “Sweeper”를 넣는 순간 다시 고정된 역할이 된다. 채용 공고나 조직도보다 프로젝트 배치, 회고, 팀 병목 진단에 쓰는 편이 더 안전하다.
Q2. 한 사람이 5개를 다 해야 하나요?+
현실적으로는 어렵고, 반드시 그럴 필요도 없다. 초기 창업자나 1인 개발자는 여러 원형을 오가지만, 팀이 커질수록 각자의 주 원형과 보조 원형이 나뉜다. 중요한 것은 모든 사람이 모든 원형을 갖는 것이 아니라 팀 전체가 제품 단계에 맞는 조합을 갖는 것이다.
Q3. AI가 빌더와 스위퍼를 대신하면 사람은 무엇을 하나요?+
AI는 구현과 정리의 많은 부분을 돕지만, 무엇을 만들지, 무엇을 삭제할지, 어느 수준의 위험을 받아들일지 결정하지 않는다. 사람의 역할은 실행자에서 판단자와 운영자로 이동한다. 좋은 프롬프트보다 좋은 검증 기준, 좋은 삭제 기준, 좋은 제품 판단이 더 중요해진다.
Q4. 이 원형은 개발팀에만 적용되나요?+
출발점은 Claude Code 팀 관찰이지만, 원형 자체는 제품, 디자인, 데이터, 마케팅, 운영에도 적용할 수 있다. 예를 들어 마케팅에서도 새 캠페인을 많이 실험하는 사람, 성과가 난 캠페인을 시스템화하는 사람, 메시지를 정리하는 사람, 채널을 키우는 사람, 브랜드 신뢰를 유지하는 사람이 구분된다.
Q5. 우리 팀에 가장 먼저 물어야 할 질문은 무엇인가요?+
“지금 우리 제품 단계에서 가장 부족한 진전은 무엇인가?”가 먼저다. 새 아이디어가 부족한지, 제품화가 늦은지, 복잡성이 과한지, 성장 반복이 약한지, 운영 신뢰가 낮은지부터 구분하면 필요한 원형이 자연스럽게 드러난다.
출처와 참고 링크
아래 링크를 바탕으로 원문 주장, 한국어 요약, 공식 Claude Code 문서, 관련 인터뷰 맥락을 교차 확인했다. WikiDocs는 브라우저 캡처에서 보안 인증 화면이 떠 이미지로 쓰지 않았고, 텍스트 출처로만 사용했다.
- Boris Cherny original post mirror on Digg 2026년 6월 28일 올라온 X 포스트의 미러. Prototyper, Builder, Sweeper, Grower, Maintainer와 제품 단계별 조합을 확인했다.
- GeekNews: 클로드 코드 창시자가 말하는 AI 시대의 다섯 가지 원형 한국어 요약과 커뮤니티 반응을 확인했다.
- WikiDocs: 박재홍의 실리콘밸리 한국어 해설 글의 구조, 핵심 요약, PMF 이전/성장기/성숙기 조합 설명을 참고했다.
- Business Insider: The 5 job archetypes of the future 직함 변화, 유연성에 대한 반론, AI가 각 원형을 어느 정도 지원한다는 맥락을 확인했다.
- Claude Code Docs: Overview Claude Code가 코드베이스를 읽고, 파일을 수정하고, 명령을 실행하며, 터미널/IDE/데스크톱/브라우저에서 동작한다는 공식 설명을 확인했다.
- Claude Code Docs: Best practices 에이전트형 코딩 환경에서 탐색, 계획, 구현, 검증, 병렬 세션이 중요해진다는 공식 권고를 확인했다.
- The Pragmatic Engineer: Building Claude Code with Boris Cherny Boris Cherny의 역할, Claude Code 팀의 병렬 에이전트 활용, 프로토타입 중심 제품 개발 맥락을 확인했다.
'NEWS' 카테고리의 다른 글
| 청년미래적금 신청 방법 및 신청 기간 안내 (0) | 2026.07.03 |
|---|---|
| AI가 일자리보다 먼저 가져가는 것은? (6) | 2026.07.03 |
| 2026 상반기 말아먹었을 때 쓰는 글 (1) | 2026.07.03 |
| AI 추론 속도 야-호: Gemma 4 31B, Cerebras에서 1800 tokens/s급 성능 공개 (0) | 2026.06.30 |
| OpenAI GPT-5.6 시리즈 3종 전격 공개: 플래그십 Sol부터 Terra, Luna까지 (0) | 2026.06.27 |
