AI 모델이 빨라질수록 제품 관리도 바뀐다
7분

AI 모델이 빨라질수록 제품 관리도 바뀐다

Anthropic (Cat Wu) Anthropic Blog 원문 보기 ↗

AI 모델은 16개월 만에 41배 발전했습니다. 기존 제품 관리의 전제인 "프로젝트 완료 시 기술 범위 = 시작 시 기술 범위"가 더 이상 성립하지 않습니다.

Anthropic의 Cat Wu는 4가지 전환을 제시합니다. 단기 실험 중심, 프로토타입 우선, 신모델마다 기존 기능 재검토, 단순함 유지가 핵심입니다.

PM의 역할은 계획 수립에서 발견 가속으로 이동하고 있습니다.

6개월 실행 계획을 세우셨습니까? AI 모델은 3개월마다 바뀝니다. 계획이 낡아가는 속도보다 모델이 빠릅니다.

Anthropic의 Cat Wu는 Claude Code를 모델 버전마다 직접 테스트합니다. Excalidraw(협업 다이어그램 도구)에 표 기능을 추가하라는 요청을 Sonnet 3.5에 주면 가끔 실패했습니다. Opus 4.6에 같은 요청을 주자 한 번에 완료됐습니다.

이 차이는 단순한 성능 향상이 아닙니다. "어떤 기능이 지금 가능한가"라는 전제 자체가 바뀝니다. 전통적인 제품 관리는 그 전제가 고정돼 있다고 가정합니다. 그 가정이 깨졌습니다.

METR 연구에 따르면 Opus 4.6은 인간이 약 12시간 걸리는 작업을 완료할 수 있습니다. Sonnet 3.5(new) 대비 41배 향상된 수치이며, 16개월 만의 변화입니다. (출처: METR, 2026)

전통적 제품 관리는 한 가지 전제 위에 세워져 있습니다. "프로젝트 시작 시 가능한 기술 범위가 완료 시에도 유지된다"는 것입니다. 모델이 3개월마다 바뀌면 이 전제가 무너집니다. 6개월짜리 실행 계획을 세우는 순간 그 계획은 이미 낡아 있습니다.

첫째, 장기 실행 계획 대신 단기 실험을 중심에 놓습니다. Cat Wu는 이를 "사이드 퀘스트"라 부릅니다. 오후 한 나절 동안 자기 주도적으로 진행하는 실험입니다. 반 분기(6~8주) 단위 계획을 선호합니다. 확실성이 낮은 영역에서는 장기 목표가 방향을 고정하는 동시에 실험 여지를 막기 때문입니다.

둘째, 문서보다 프로토타입을 먼저 만듭니다. Cat Wu는 Claude Code로 아이디어를 그날 오후 안에 시작품으로 만듭니다. "아이디어에서 '한번 써봐'까지의 간격이 사라졌다"고 표현합니다. Decagon의 제품 디렉터 Bihan Jiang도 같은 경험을 보고했습니다. 데모 제작 기간이 수 주에서 수 시간으로 단축됐다고 합니다.

셋째, 신모델 출시마다 기존 기능을 다시 확인합니다. 새 모델이 나오면 이전에 어렵거나 불가능했던 기능이 갑자기 가능해집니다. Cat Wu 팀은 Opus 4.6 도입 후 시스템 프롬프트와 도구 설명을 20% 줄였습니다. 유지보수 부담이 줄고, 같은 인력으로 더 빠르게 출시할 수 있게 됐습니다. Datadog의 시니어 PM Kai Xin Tai는 이를 "평가 피드백 루프"라 정의합니다. 결과물 품질을 반복 측정해 개선하는 과정으로, 발견 속도를 높이는 핵심 방식입니다.

넷째, 모델 한계를 우회하는 엔지니어링을 피합니다. 특정 모델 버전의 약점을 보완하는 복잡한 우회 코드를 쌓으면 다음 모델이 출시됐을 때 짐이 됩니다. 단순한 구조가 모델 개선의 수혜를 자동으로 흡수합니다. "단순함이 기본값이어야 한다"는 원칙입니다.

1
오후 2시간을 "사이드 퀘스트"로 예약합니다.
팀의 반복 업무 중 하나를 골라 Claude Code에 "이 업무를 자동화하는 스크립트를 만들어 줘"라고 요청합니다. 완성도보다 가능성 확인이 목표입니다. (2시간, 팀원 1인 단독 실험)
2
기존 기능 목록을 최신 모델로 재테스트합니다.
"예전에 AI로 해봤는데 안 됐다"는 항목을 3개 뽑습니다. Opus 4.6으로 같은 요청을 다시 실행합니다. (30분, 결과를 팀 슬랙에 공유)
3
다음 분기 실행 계획을 반 분기 단위로 나눕니다.
6개월 계획을 8주짜리 두 묶음으로 분리합니다. 첫 8주에만 구체적 목표를 부여하고, 두 번째 묶음은 첫 번째 결과를 본 뒤 정합니다. (1시간, 계획서 수정)

단기 실험 편향이 생길 수 있습니다. "사이드 퀘스트" 중심 운영은 빠른 검증에 유리합니다. 반면 장기 투자가 필요한 기반 작업(데이터 파이프라인, 보안 설계)은 뒤로 밀리기 쉽습니다. 실험과 기반 작업의 비율을 명시적으로 관리해야 합니다.

모델 의존도가 높아질수록 전환 비용도 커집니다. Anthropic 모델에 최적화된 제품 구조는 다른 모델로 이전할 때 재작업이 필요합니다. 특정 모델 버전에 의존하는 코드는 다음 버전 출시 시 부채가 됩니다.

이 접근법은 Anthropic 내부 사례입니다. Cat Wu의 팀은 AI 도구를 만드는 조직입니다. AI 도구를 처음 도입하는 비개발 조직에 그대로 적용하면 속도보다 혼란이 먼저 옵니다. 조직의 AI 성숙도를 먼저 진단해야 합니다.

프로토타입 우선 문화는 완성도 기준을 낮출 수 있습니다. "빠른 시작품"이 "완성된 제품"으로 착각되면 품질 문제가 누적됩니다. 실험과 출시 기준을 명확히 구분해야 합니다.

모델이 41배 빨라졌습니다. 제품 관리도 그 속도에 맞춰 다시 설계해야 합니다.

우리 팀의 AI 전환 속도를 높이고 싶다면, 무료 진단을 신청하세요.

창업자 다음 분기 실행 계획을 8주 단위로 나누고, 첫 8주에만 구체적 목표를 부여하라
팀장 팀원 한 명에게 매주 오후 2시간을 AI 실험 시간으로 보장하고 결과를 공유하게 하라
임원 "예전에 안 됐던" AI 기능 목록을 최신 모델로 재검토하고, 분기별 재테스트를 업무에 포함하라
  • Wu, C. (2026, March). Product management on the AI exponential [Article]. Anthropic. (원문 보기 ↗)
  • METR. (2026). Measuring AI agents' ability to complete long tasks [Research]. METR. (원문 보기 ↗)
라운드테이블
B
블랙 · 중견기업 임원
METR 데이터에서 Opus 4.6이 Sonnet 3.5(new) 대비 41배 향상, 16개월 만의 변화. 이 속도가 계속되면 6개월 실행 계획은 그냥 가정집 달력입니다. 지금 분기 계획을 8주 단위로 쪼개지 않으면 경쟁에서 밀려요.
R
레드 · 저널리스트
41배 향상이라는 수치가 어떤 태스크 기준인지 구체적으로 명시가 됐나요? 본문에는 "인간이 약 12시간 걸리는 작업 완료 능력"이라고 했는데, 그게 어떤 종류의 작업인지에 따라 의미가 완전히 달라져요.
B
블랙 · 중견기업 임원
METR 원문 보면 됩니다. 세부 조건보다 방향성이 중요해요. 어떤 업무든 속도가 이 정도로 바뀌면, 기획 주기도 같이 바뀌어야 합니다.
G
골드 · 창업자
Cat Wu가 Opus 4.6 도입 후 시스템 프롬프트와 도구 설명을 20% 줄였다는 거, 저도 비슷한 경험이 있어요. 새 모델 나왔을 때 예전에 복잡하게 설명하던 지시를 반으로 줄였더니 오히려 결과가 더 좋아졌거든요. 단순함이 진짜 전략이에요.
N
네이비 · 시니어 엔지니어
모델 한계를 우회하는 복잡한 코드를 쌓지 말라는 원칙이 정확해요. 특정 버전 약점 보완용 로직은 다음 버전에서 짐이 돼요. 단순한 구조가 모델 개선을 자동으로 흡수합니다. 기술 부채 관리의 핵심이에요.
W
화이트 · 조직장
저는 개발자가 아닌데, "시스템 프롬프트 20% 줄인다"는 게 어떻게 하는 건지 모르겠어요. 팀 개발자한테 "새 모델 나왔으니 프롬프트 점검해봐라"고 하면 되는 건가요?
P
퍼플 · 마케터
"아이디어에서 한번 써봐까지의 간격이 사라졌다"는 표현이 마케터한테는 정말 공감돼요. Decagon에서 데모 제작이 수 주에서 수 시간으로 줄었다는 것처럼, 콘텐츠 아이디어도 당일 프로토타입으로 만들어볼 수 있는 시대가 된 거잖아요.
R
레드 · 저널리스트
본문도 지적했지만, "빠른 시작품"이 "완성된 제품"으로 착각될 위험이 있어요. 속도가 올라갈수록 품질 기준을 더 명확하게 잡아야 해요. 실험과 출시를 구분하는 기준이 없으면 품질 문제가 쌓여요.
P
퍼플 · 마케터
맞아요. 저는 팀 내에서 "이건 실험 버전이에요"라는 라벨을 명시적으로 붙이는 걸 규칙으로 만들었어요. 빠르게 만들되, 어디까지가 테스트인지 모두가 아는 게 중요하더라고요.
R
레드 · 저널리스트
그 라벨링이 실제로 지켜지는지가 관건이에요. 대부분 바쁘면 실험이 그냥 출시로 넘어가거든요.
_posts/2026-03-19-pm-on-ai-exponential.md