직군이 아니라 역할이다 — 프로토타이퍼부터 메인테이너까지, Agentic 팀이 다시 짜이는 법

명함엔 PO도 PM도 없었는데, 다섯 역할은 다 있었습니다

저희가 만드는 앱은 마인드풀러닝(마인드풀러닝스쿨)의 차세대 러닝 앱입니다. 비교도, 랭킹도, 심지어 시계도 앞세우지 않는 — “오로지 나를 위한 달리기”를 담는 앱이죠. 파운더인 김성우 코치, 개발 총괄, 기획자, 러닝 코치, 그리고 저(프로젝트 매니저)까지, 본업이 다 따로 있는 여덟 명이 2주에 한 번 모입니다. 지난 토요일, 회의록을 정리하다가 저는 이상한 걸 봤습니다.

김성우 코치는 그날 아이디어를 여섯 개쯤 던졌습니다. 캐릭터, 콘텐츠, 후원 구조, 새 요금 방식까지 — 대부분은 이번 출시에 안 들어갑니다. 개발 총괄은 그 사이 화면 하나를 실제로 찍어내고 있었고, 저는 흩어진 기획 문서 대여섯 개를 한 장으로 지우고 합치고 있었습니다. 그리고 회의 밖에서, 합류를 검토 중인 한 개발자가 조용히 물었습니다 — “이거, 보안은 누가 봅니까?”

직군이 아니라 역할이다 — 미래 팀의 다섯 원형

이 프레임은 제 발명이 아닙니다. 클로드 코드(Claude Code)를 만든 보리스 처니(Boris Cherny)가 2026년 6월, 자기 팀을 돌아보며 X에 올린 관찰입니다. 그는 이렇게 시작합니다 — “엔지니어링·프로덕트·디자인·데이터가 새로운 종류의 역할로 녹아든다(melt).” 그 녹아든 자리에 그가 본 다섯 원형(archetype)이 있습니다.

그의 관찰에서 가장 날카로운 지점은 이것입니다 — 이 역할들은 직군에 묶여 있지 않습니다. 실제로 그의 팀에서는 15년간 코드를 안 짜던 매니저가 합류 후 코드를 쓰고, 프로덕트 매니저도 디자이너도 코드를 씁니다. “명함의 직함이 그 사람의 원형을 거의 예측하지 못한다“는 겁니다(2026년 5월 인터뷰).

대부분의 사람은 두 원형에 걸칩니다. 가끔 세 개까지도요. 그리고 건강한 팀은 원형을 골고루 섞되, 제품이 어느 단계에 있느냐에 따라 조합을 바꿉니다.

이 표가 말하는 건 한 문장입니다 — 단계가 다르면 팀의 구성이 달라야 합니다. 오늘의 직군 표(PO·PM·PL·디자이너·엔지니어)로는 이 갈아 끼움이 안 보입니다. 역할로 봐야 보입니다.

같은 앱을 만들어도, 흐름과 역할이 이렇게 달라집니다

말로만 “역할이 바뀐다”고 하면 잘 안 와닿습니다. 그래서 개발의 흐름 자체를 두 장으로 놓아 봤습니다. 위가 어제까지의 방식, 아래가 저희가 옮겨 가는 방식입니다.

차이는 세 가지입니다. ① 기존은 직군이 순서를 나눠 문서로 넘기지만, Agentic은 역할이 유동적이라 한 사람이 프로토타이퍼이자 스위퍼일 수 있습니다. ② 기존은 사람이 모든 단계의 부피를 감당하지만, Agentic은 부피를 에이전트가 집니다. ③ 그리고 가장 중요한 차이 — 기존의 검증(QA)은 맨 끝에 있지만, Agentic의 파수꾼(메인테이너)은 맨 앞·상시로 당겨집니다. 왜 그래야 하는지는 다음 절에서.

저희는 이미 그렇게 일하고 있었습니다 — 다만 이름이 없었습니다

이 프레임을 손에 쥐고 저희 팀을 다시 보니, 아무도 배정하지 않았는데 다섯 원형이 사람마다 붙어 있었습니다. 놀라운 건, 원형이 직군과 전혀 맞지 않는다는 점이었습니다.

Source: 자사 IA 컨트롤 타워(2026-07 · 내부 링크 비공개). 53개 화면을 한눈에 관리·추적하는 이 화면 자체가 프로토타이퍼의 산출물입니다. 가운데 목업에 담긴 창(創) — “내가 할 수 있는 달리기를 하다 보면, 내가 할 수 없던 달리기를 하게 됩니다” — 는 김성우 코치의 문장입니다.

저희 제품은 아직 PMF 이전입니다. 정식 출시 전이고, 실사용자 반복은 시범 기간(가을)에야 시작됩니다. 보리스의 표대로라면 지금 저희에게 필요한 건 프로토타이퍼 + 빌더 + 스위퍼(1·2·3)입니다. 실제로 저희에게 그로어는 없습니다 — 없어야 정상입니다. 여기까지는 이론과 현장이 깔끔하게 맞았습니다.

그런데 딱 하나, 이론과 어긋난 게 있었습니다. 메인테이너였습니다.

Agentic 시대엔, 파수꾼이 맨 앞에 섭니다

보리스의 표에서 메인테이너(5)는 성숙기의 역할입니다. 규모가 커진 뒤에 붙는 일이죠. 그런데 저희는 PMF 이전인데도 메인테이너를 맨 앞으로 당겼습니다. 왜일까요. 이유는 이 시대의 정직한 우려 하나에서 출발합니다.

역할이 유동적일수록, 하네스가 뼈대가 됩니다

여기서 자연스러운 반문이 나옵니다. “한 사람이 두세 원형을 넘나들면, 팀이 오히려 혼란스러워지지 않나요?” 맞는 걱정입니다. 그래서 하네스(harness)가 필요합니다 — 일하는 규칙과 검증 체계, 말하자면 팀 전체가 함께 매는 안전벨트입니다.

[기획 텍스트]
   │  에이전트: 구현 · 테스트 생성 · 회귀 채점 (부피)
   ▼
[동작하는 슬라이스]
   │  ── 관문(HITL) ──  보안 · 결제 · 머지  ← 사람이 지키는 자리
   │  ── 화이트해커 ──  생성자 ≠ 검증자     ← 되묻는 사람
   ▼
[배포]  →  교훈을 각자의 하네스에 재주입  →  다음번엔 자동 관문

저는 컨설팅·비즈니스 판단을 돕는 하네스를 하나 운영합니다. 때로는 훈련시키고, 때로는 그 조언을 그대로 따릅니다. 여러 현장에서 검증됐습니다. 하네스의 가치는 “똑똑한 모델”에 있지 않습니다 — 모델은 갈아 끼우는 부품일 뿐입니다. 가치는 규칙 × 지식 × 검증이 한 체계로 묶여, 누가 어느 원형을 맡든 같은 관문을 통과하게 만드는 데 있습니다.

그리고 하네스는 완성해 놓고 시작하는 게 아닙니다. 만들면서 굴립니다 — 파도를 타듯, 다음 구간이 보이는 만큼만 짓고 나아갑니다(롤링웨이브). 완벽한 공장을 먼저 짓겠다고 제품을 멈추면, 둘 다 못 만듭니다.

여러분 팀에 오늘 해볼 세 가지

이 시리즈에서 다룰 여섯 편

이 글은 지도입니다. 앞으로 다섯 원형을 한 편씩, 저희 러닝 앱을 실제 사례로 풀어갑니다. 각 편은 “이 원형이 Agentic 시대에 어떻게 달라지는가”를 현장 기록으로 다룹니다.

먼저 읽으면 좋은, 이미 발행된 글들입니다.