AI 잘 쓰는 법? 기획서의 정의부터 바꿔라
캣 우(Cat Wu)의 철학과 AI 시대 업무 재정의에 관한 심층 분석
원문 출처: 오마이뉴스, 임선영(중국경제미래지도 저자), 2026년 4월 3일
원문 블로그: Anthropic 공식 블로그, “Product Management on the AI Exponential”, Cat Wu, 2026년 3월 19일
작성일: 2026년 4월 3일
목차
- 글의 배경과 문제의식
- 캣 우는 누구인가
- 전제의 붕괴 — “올라가는 바닥 위에서 제품을 만들다”
- 엑스칼리드로 실험 — 불가능에서 당연함으로
- 새로운 PM 워크플로우의 네 가지 축
- 앤스로픽 내부의 실제 작동 방식
- 직군별 재정의 — 모두에게 해당하는 질문
- AI 산업의 중심축 이동 — 모델 경쟁에서 제품 경쟁으로
- 캣 우의 핵심 원칙 — “단순하지만 작동하는 것”
- 한국 사회에 주는 시사점
- 결론 — 용기의 문제
1. 글의 배경과 문제의식
한국의 AI 열풍과 그 이면
2026년 현재, 한국에서는 AI 활용에 관한 뜨거운 열기가 식을 줄 모른다. 기업마다 AI 도입 프로젝트가 줄을 잇고, AI 활용법을 가르치는 강의는 수도 없이 쏟아지고 있다. 챗GPT나 클로드(Claude), 제미나이(Gemini)로 보고서를 작성하고, AI로 회의록을 정리하며, 이미지와 동영상을 생성하고, 바이브코딩(vibe coding)을 시도하고, 오픈클로(OpenClaw) 같은 도구 사용법을 익히는 일이 마치 시대를 살아가는 필수 역량처럼 여겨지고 있다. 이른바 ‘AI를 잘 쓰는 법’을 체득하는 것이 곧 경쟁력이라는 분위기가 팽배해 있다.
그러나 오마이뉴스에 기고한 중국 전문가 임선영은 이 흐름에 근본적인 문제를 제기한다. 그녀가 지목하는 핵심 오류는 단순하다. AI 활용법을 배우는 것은 기존의 일하는 방식을 그대로 유지한 채 도구만 바꾸는 것에 불과하다는 지적이다. 워드프로세서가 타자기를 대체했던 과거의 기술 전환과는 근본적으로 다른 변화가 지금 일어나고 있음에도 불구하고, 많은 이들이 그 차이를 제대로 인식하지 못한 채 ‘도구 숙달’에만 집중하고 있다는 것이다.
워드프로세서가 등장했을 때 사람들이 해야 했던 일은 단순했다. 타자기 대신 키보드와 워드 소프트웨어를 익히는 것으로 충분했다. 일의 본질, 즉 문서를 작성하는 행위 자체는 달라지지 않았다. 그러나 AI는 다르다. AI는 단순한 도구가 아니라, 일 자체를 설계하는 전제를 바꾸는 환경적 변화다. 도구를 바꾸는 것은 익히면 되는 문제지만, 전제를 바꾸는 것은 기존의 것을 해체하는 전혀 다른 차원의 작업이다.
임선영은 이 오류를 가장 선명하게 짚어내고 실질적인 방향을 제시하는 인물로 앤스로픽(Anthropic)에서 클로드 코드(Claude Code)의 프로덕트 헤드(Head of Product)를 맡고 있는 캣 우(Cat Wu)를 주목한다. 그녀가 주목받는 이유는 단순히 중국계 여성이 실리콘밸리 AI 산업의 핵심 의제를 설정하고 있다는 상징성 때문만이 아니다. 그녀가 던지는 질문이 한국과 중국을 포함한 전 세계 AI 업계가 지금 가장 절실하게 마주해야 할 질문과 정확히 맞닿아 있기 때문이다.
2. 캣 우는 누구인가
엔지니어에서 VC, 다시 앤스로픽의 PM 리더로
캣 우(Cat Wu)는 앤스로픽에서 클로드 코드(Claude Code)의 프로덕트 헤드(Head of Product)를 맡고 있는 인물이다. 그녀의 커리어 궤적은 AI 시대 제품 관리자가 갖춰야 할 역량을 그 자체로 보여주는 하나의 실증 사례이기도 하다.
그녀는 스케일 AI(Scale AI), 댁스터(Dagster) 같은 스타트업에서 프로덕트 엔지니어로 커리어를 시작했다. 엔지니어로서 직접 코드를 짜고 제품을 만드는 경험을 쌓은 뒤, 그녀는 벤처캐피털리스트(VC)로 전향했다. 흥미로운 것은 VC 역할을 수행하면서도 그녀는 코드 작성을 멈추지 않았다는 점이다. X(구 트위터)에서 새로운 회사 설립 발표를 스캔하거나 오픈소스 프로젝트의 성장세를 감지하는 등 반복적이고 번거로운 업무를 자동화하는 스크립트를 직접 작성했다. 도구를 쓰는 사람이 아니라 도구를 만드는 사람으로서의 사고방식이 이미 몸에 배어 있었던 것이다.
2024년 8월, 그녀는 앤스로픽에 리서치 PM팀(Research PM team)의 프로덕트 매니저로 합류했다. 이 팀은 앤스로픽의 연구팀과 실제 고객 사이를 연결하여 더 나은 모델을 시장에 전달하는 역할을 담당한다. 그해 가을, 클로드 코드가 내부 도구로 공개되었을 때, 그녀는 즉각 이를 자신의 업무에 활용하기 시작했다. 대규모 사용자 피드백을 분석하는 스트림릿(Streamlit) 앱을 개발하거나, 새로운 벤치마크를 신뢰할 수 있는지 판별하기 위한 평가(eval) 실험을 수행하는 작업에 클로드 코드를 투입했다. 더 나아가 자신의 공식 역할 범위를 훨씬 벗어난 강화학습(RL) 환경을 만들어 모델 훈련 방식을 이해하는 탐색적 작업도 진행했다. 이 모든 작업에서 그녀는 수백 시간의 클로드 코드 프롬프팅을 활용했지만, 직접 손으로 작성한 코드는 단 한 줄도 없었다고 밝혔다.
그녀는 이후 클로드 코드 팀으로 이동해 프로덕트 헤드 역할을 맡았으며, 2026년 3월 19일 앤스로픽 공식 블로그에 “AI 지수적 진화 속의 제품 관리(Product Management on the AI Exponential)”라는 글을 기고하면서 업계 전반에 큰 반향을 일으켰다. 이 글은 실리콘밸리뿐만 아니라 중국과 한국의 AI 개발자 커뮤니티에도 빠르게 퍼져나갔다. 기술 발전의 속도를 아무리 따라가도 AI에 뒤처진다는 불안감의 근본 원인을 날카롭게 지적하고 실질적인 해법을 제시했기 때문이다.
3. 전제의 붕괴 — “올라가는 바닥 위에서 제품을 만들다”
전통적 업무 설계의 토대가 흔들리다
캣 우가 블로그에서 가장 먼저 겨냥하는 것은 전통적인 제품 관리 방법론의 숨겨진 전제다. 그 전제는 놀라울 정도로 단순하고 견고해 보였다. 프로젝트가 시작될 때 기술적으로 가능한 것이, 프로젝트가 끝날 때도 대체로 같은 수준으로 유지된다는 것이다.
이 전제가 존재했기에, 우리가 ‘정석’이라 불러온 업무 방식이 성립할 수 있었다. 충분한 시간을 들여 요구 사항(requirements)을 수집하고, 상세한 기획 문서(PRD, Product Requirements Document)를 작성하며, 팀 간 합의를 거친 뒤 실행에 들어가는 방식이다. 프로덕트 매니저가 두꺼운 기획서와 정교한 로드맵(roadmap)을 작성하는 것은 역량의 증거였고, 이런 문서의 완성도가 곧 그 PM의 전문성을 증명하는 잣대였다.
그러나 AI 모델의 능력이 지수함수적으로 성장하는 오늘날, 이 전제는 더 이상 성립하지 않는다. 분석하고, 문서를 완성하고, 팀 간 합의를 이끌어내는 동안, 모델의 능력은 이미 전혀 다른 수준에 도달해 있다. 캣 우가 이를 표현하기 위해 사용한 문장은 지금 업계에서 하나의 경구처럼 회자되고 있다.
“You are building on a rising floor.”
(당신은 계속 올라가는 바닥 위에서 제품을 만들고 있습니다.)
바닥이 고정되어 있다는 전제 하에 설계도를 완성했을 때, 그 설계도는 이미 움직인 바닥과 어긋나 있다. 전제가 틀렸을 때 그 위에 세워진 방법론은 아무리 정교하더라도 무용지물이 된다. 이것이 많은 PM들이 더 열심히 기획서를 쓰면서도 더 큰 불안감을 느끼는 이유다.
숫자로 보는 기술 진보의 속도
이것이 단순한 수사(修辭)가 아님을 보여주는 데이터가 있다. AI 역량 평가 기관인 METR(Model Evaluation & Threat Research)의 2026년 3월 보고서에 따르면, 오퍼스 4.6(Opus 4.6)은 인간이 처리하는 데 거의 12시간이 걸리는 소프트웨어 작업을 약 절반의 확률로 완료할 수 있다. 불과 16개월 전, 클로드 코드 개발 초기에 사용된 소네트 3.5(Sonnet 3.5) 버전이 처리할 수 있었던 과업의 최대 소요 시간은 약 21분이었다. 16개월 만에 처리 능력이 약 41배 증가한 것이다.
이 수치가 의미하는 바는 명확하다. 어떤 프로젝트가 6개월의 개발 기간을 상정하고 시작된다면, 프로젝트가 완료될 시점의 모델 능력은 착수 시점과 근본적으로 다른 수준에 있을 것이다. 시작할 때 ‘불가능’으로 분류했던 것이 프로젝트 중반에 ‘가능’으로 바뀌어 있을 수 있고, 시작할 때 ‘최선의 우회 방법’으로 구축한 복잡한 구조가 프로젝트 완료 전에 이미 불필요한 레거시(legacy)가 되어 있을 수 있다.
4. 엑스칼리드로 실험 — 불가능에서 당연함으로
하나의 반복 실험이 말해주는 것
캣 우는 자신의 주장을 뒷받침하기 위해 매우 구체적이고 반복 가능한 실험을 제시한다. 2024년 10월, 클로드 소네트 3.5(new) 버전이 출시된 직후부터 그녀는 새로운 모델이 나올 때마다 동일한 과제를 반복하기 시작했다. 오픈소스 화이트보드 도구인 엑스칼리드로(Excalidraw)에 ‘표(table)’ 기능을 추가하는 코드를 클로드 코드에게 요청하는 것이다.
초기에는 모든 모델이 이 작업을 완료하는 데 실패했다. 각 버전의 모델은 이전보다 조금 더 멀리 나아갔지만, 결국 어느 지점에서 막혔다. 그러다 2025년 6월, 오퍼스 4(Opus 4)가 출시되었을 때 모델은 가끔씩 성공을 거두기 시작했다. 이 성과는 클로드 4 모델 출시 행사에서 미리 녹화된 데모(pre-recorded demo) 형태로 공개되었다.
그리고 오퍼스 4.6이 등장했을 때, 상황은 완전히 달라졌다. 오퍼스 4.6은 엑스칼리드로 기능 추가 요청을 “원샷(one-shot)”으로, 즉 단 한 번의 시도로 안정적으로 완수할 수 있는 수준에 도달했다. 그 결과는 수천 명의 전문 개발자들 앞에서 라이브로 시연할 수 있을 만큼 충분히 신뢰할 수 있는 것이었다.
이 실험이 진짜 증명하는 것
표면적으로 이 실험은 모델 성능의 향상을 보여준다. 하지만 캣 우가 이 실험을 통해 정말로 증명하고자 하는 것은 다른 차원에 있다. 바로 “불가능하다”는 전제 위에 설계된 모든 우회 구조와 임시 해법들이 단 한 번의 모델 업데이트로 순식간에 불필요한 복잡성, 즉 “사족(dead code)”이 되어버린다는 사실이다.
많은 팀들이 특정 모델의 한계를 전제로 복잡한 우회 로직을 설계하고, 그 위에 제품의 핵심 기능을 구축한다. 그런데 다음 모델 업데이트 하나로 그 우회 로직이 불필요해지면, 그 위에 쌓인 제품 구조 전체가 일종의 기술 부채(technical debt)로 전락한다. 결국 새로운 모델의 능력을 제대로 활용하려면 기존 구조를 해체하고 다시 설계해야 하는 상황이 반복된다.
캣 우는 이 맥락에서 좋은 프로덕트 매니저의 정의를 새롭게 내린다. 좋은 PM은 기능을 추가하는 사람이 아니라, 시대에 뒤처진 가정 위에 세워진 기능을 과감하게 걷어내는 사람이다. 제거할 용기가 곧 새로운 역량이다.
5. 새로운 PM 워크플로우의 네 가지 축
앤스로픽 클로드 코드 팀이 채택한 네 가지 원칙
캣 우는 앤스로픽이 AI 지수 성장 환경에 적응하기 위해 채택한 네 가지 구체적인 작동 방식을 공개했다. 이것들은 추상적인 원칙이 아니라, 실제 클로드 코드 팀이 매일 운영하는 방식이다.
원칙 1: 장기 로드맵 대신 단기 스프린트로 계획하라
전통적인 제품 관리에서 탐색(exploration)은 로드맵이 확정되기 전에 이루어지는 선행 단계였다. 연구를 하고, PRD를 작성하고, 엔지니어링팀에 넘기는 방식이다. 하지만 앤스로픽 클로드 코드 팀은 이 방식을 버리고 “사이드 퀘스트(side quest)”라는 개념을 도입했다.
사이드 퀘스트란 공식 로드맵 외부에서 구성원 개인이 자율적으로 수행하는 단기 실험이다. 오후 한나절을 들여 아이디어를 프로토타이핑하거나, 불가능하다고 가정했던 기능을 실제로 시도해보거나, 모델을 예상보다 더 강하게 밀어붙여 무슨 일이 일어나는지 관찰하는 것이다. 실패해도 비용이 작고, 성공하면 팀 전체의 방향을 바꿀 수 있는 발견이 된다.
실제로 앤스로픽의 가장 인기 있는 기능들 중 상당수가 이런 사이드 퀘스트에서 탄생했다. 클로드 코드 데스크톱 앱(Claude Code on Desktop), 에이전트가 사용자 입력을 요청하는 AskUserQuestion 도구, 그리고 할 일 목록(todo list) 기능이 모두 사이드 퀘스트에서 시작되었다.
원칙 2: 문서 대신 데모와 평가(eval)를 중심에 두어라
앤스로픽 팀은 기존의 스탠드업 미팅 방식을 버렸다. 대신 새로운 아이디어의 데모를 공유하는 방식으로 진행한다. 내부 사용자들이 직접 사용해보고, 실질적인 참여도가 높은 것들은 더 다듬어져 더 넓은 범위에 공유된다. 프로토타입을 하루 안에 만들 수 있기 때문에 틀린 판단을 내렸을 때의 비용이 매우 낮다.
한 가지 구체적인 사례가 있다. 팀원인 노아(Noah)가 클로드 코드용 플러그인 기능의 기획서(spec)를 클로드 코드에 입력했을 때, 클로드 코드가 생성한 프로토타입이 거의 프로덕션 수준에 가까운 결과물로 돌아왔다. 이 프로토타입이 이후 팀이 실제로 출시한 플러그인 기능의 기준점이 되었다. 캣 우는 이 경험에서 하나의 실용적 팁을 도출한다. 기획서를 작성했다면, 그것을 클로드 코드에 넣어서 빌드해보라. 거친 프로토타입 하나가 문서보다 훨씬 더 많은 것을 바꾼다.
평가(eval) 역시 문서를 대체하는 중요한 도구다. 다수의 클로드 코드 인스턴스를 협력하게 만드는 “에이전트 팀(agent teams)” 기능을 개발할 때, 팀원 코너(Conner)는 에이전트 팀이 잘 작동하는 경우, 그렇지 않은 경우, 그리고 무엇을 개선해야 하는지를 정확히 이해하기 위한 평가 세트를 직접 손으로 만들었다. 측정이 가능해질 때 개선도 가능해진다.
원칙 3: 새 모델이 나올 때마다 기존 기능을 재검토하라
예전에는 기능을 출시하면 그것으로 끝이었다. 그러나 이제는 기능을 출시한 뒤 더 나은 모델이 나오면 그 기능이 드라마틱하게 개선될 수 있다. 모든 모델 출시는 이미 만들어진 것들을 재검토하라는 암묵적 신호다.
이런 방식으로 탄생한 기능이 “크롬과의 클로드 코드 연동(Claude Code with Chrome)”이다. 팀은 사용자들이 클로드 코드로 웹 앱을 만든 다음, 수동으로 크롬의 클로드로 전환해 테스트하고, 다시 복사-붙여넣기로 지시사항을 옮기는 행동 패턴을 발견했다. 이 번거로운 임시방편이 효과적으로 작동하고 있다는 사실 자체가 곧 이것을 내장 기능으로 만들어야 한다는 신호였다. 사용자들이 직접 만들어 쓰는 “해킹”이 있다면, 그것은 제품이 만들어야 할 기능이다.
원칙 4: 단순한 것을 하라(Do the Simple Thing)
앤스로픽 전체에 걸쳐 적용되는 지침이 하나 있다. “작동하는 단순한 것을 하라(Do the simple thing that works).” 모델의 한계를 영리하게 우회하는 복잡한 구현은, 다음 모델 업데이트가 나오는 순간 불필요한 복잡성이 된다. 단순할수록 새로운 모델 능력으로의 교체가 쉬워진다.
이 원칙이 실제로 작동한 대표적인 사례가 있다. 클로드 코드에 처음 할 일 목록 기능을 출시했을 때, 모델이 작업을 완료할 때마다 항목을 체크하는 동작을 신뢰할 수 있을 만큼 일관되게 수행하지 못했다. 팀은 이를 해결하기 위해 몇 번의 메시지마다 에이전트에게 자신의 할 일 목록을 업데이트하도록 시스템 프롬프트 내에 주기적 알림을 삽입했다. 작동하기는 했지만, 그것은 임시방편(hack)이었다. 다음 모델이 나왔을 때, 이 동작은 별도의 알림 없이도 기본적으로 올바르게 수행되었고, 팀은 알림 로직 전체를 제거했다. 오퍼스 4.6 하나로만 시스템 프롬프트를 기존 대비 20% 줄일 수 있었다.
6. 앤스로픽 내부의 실제 작동 방식
롤의 경계가 사라지다
캣 우는 앤스로픽 내부에서 역할의 경계가 어떻게 변하고 있는지를 솔직하게 공개한다. 클로드 코드 팀에서는 디자이너가 코드를 직접 작성하고, 엔지니어가 제품 결정을 내리며, 프로덕트 매니저가 프로토타입을 만들고 평가 실험을 수행한다. 이것이 가능한 이유는 명확한 전략과 목표가 팀원 개개인이 자율적으로 우선순위를 판단할 수 있는 기반을 제공하기 때문이다.
이 맥락에서 PM의 역할도 재정의된다. AI 시대의 PM은 빠른 모델 발전이 만들어내는 모호성 속에서 명확성을 창출하는 사람이다. 팀이 가능하다고 생각하는 것보다 더 크게 생각하도록 밀어붙이는 사람이고, 더 빠르게 출시할 수 있도록 길을 여는 사람이다. 일의 완벽한 통제에 집착하는 것에서 벗어나, 진짜 ‘타협 불가능한 몇 가지’를 정의하고 나머지는 내려놓는 유연성이 새로운 역량이 된다.
캣 우 자신도 완벽주의자였기에 이 전환이 가장 어려웠다고 고백한다. 하지만 AI 제품 개발은 파도 위에서 서핑하는 것과 같으며, 가장 중요한 것은 파도에 올라타 있는 것이라고 그녀는 말한다.
도구 분업의 자연스러운 형성
캣 우의 개인적인 워크플로우도 주목할 만하다. 그녀는 세 가지 도구를 자연스러운 분업 구조로 활용한다.
첫 번째는 클로드닷에이아이(Claude.ai)다. 이것은 그녀의 대화 상대이자 생각을 다듬는 공간이다. 전략 문서의 아이디어를 논의하거나, 까다로운 상황에 어떻게 대응할지 고민하거나, 빠른 답을 얻고 싶을 때 사용한다. 행동(action)을 지시하는 것이 아니라, 함께 생각하는 파트너로서의 용도다.
두 번째는 클로드 코드(Claude Code)다. 이것은 프로토타입, 평가 실험, 스크립트를 만드는 공간이다. 출력물이 코드인 모든 상황에서 사용된다.
세 번째는 클로드 코워크(Cowork)다. 이것은 나머지 모든 것을 처리하는 공간이다. 받은 편지함 정리, 할 일 목록 관리, 슬라이드 자료 제작, 슬랙(Slack) 대화 기록을 검색해 의사결정의 맥락을 파악하는 일, 출장 일정 예약 등 지식 노동의 전반을 커버한다.
7. 직군별 재정의 — 모두에게 해당하는 질문
AI 업계 종사자만의 이야기가 아니다
임선영은 캣 우의 통찰을 AI 업계 종사자에게만 적용하는 것을 경계한다. 이 질문은 특정 직군에 국한된 것이 아니라 AI가 업무의 전제를 바꾸는 모든 조직과 역할에 해당한다. 그녀는 각 직군이 지금 스스로에게 던져야 할 질문들을 구체적으로 제시한다.
프로덕트 매니저(기획자)에게
지금 작성하는 기획서의 구조는 모델 업데이트 한 번으로 전제가 바뀌는 환경에서도 유효한가. 기획의 완성도를 먼저 묻는 것이 아니라, 기획의 수명을 먼저 물어야 한다. 6개월짜리 완성도 높은 기획서가, 3개월 후 모델 업데이트로 전제가 바뀐 세상에서는 이미 레거시 문서가 되어 있을 수 있다. 기획서를 쓰는 데 2주를 투자하는 대신, 하루 만에 프로토타입을 만들어 핵심 가정이 맞는지 먼저 확인하는 방식으로 일의 순서를 바꾸어야 한다.
개발자(엔지니어)에게
지금 작성하는 코드의 구조는 3개월 뒤 AI가 같은 기능을 10배 빠르게 구현할 수 있게 될 때도 여전히 가치가 있는가. 코드를 잘 짜는 능력과, 무엇을 짤지를 결정하는 능력은 이제 전혀 다른 역량이다. AI가 코드 생성 자체를 빠르게 대체하는 환경에서 엔지니어의 핵심 경쟁력은 어떤 코드를, 왜, 어떤 설계 원칙으로 만들지를 판단하는 능력으로 이동하고 있다.
기업 경영진에게
조직의 의사결정 구조는, AI가 데이터 분석과 초안 작성을 대신하는 환경에서도 지금의 속도와 단계가 필요한가. AI 이전 시대에는 느린 협의 구조가 필요한 이유가 있었다. 정보를 수집하고, 분석하고, 합의에 이르는 데 인력과 시간이 필요했다. 그러나 AI가 분석과 초안 작성을 실시간으로 처리하는 환경에서, 6단계의 결재 라인과 3주의 검토 기간은 경쟁력의 원천이 아니라 비용이 된다.
정책 입안자에게
지금 설계하는 규제와 지원 체계는, 기술이 정책보다 빠르게 움직이는 환경에서 무엇을 기준점으로 삼고 있는가. 어제의 기술 지형을 전제로 만들어진 정책은 발효되는 순간 이미 낡아 있을 수 있다. AI 규제와 지원 정책은 특정 기술 상태를 고정된 기준점으로 삼는 방식 대신, 변화에 적응할 수 있는 원칙 기반의 접근이 필요하다.
투자 심사역에게
지금 검토하는 기업의 경쟁 우위는 6개월 뒤에도 같은 이유로 유효한가. AI 시대의 투자 기준은 현재의 제품 상태가 아니라, 그 팀이 전제가 바뀌었을 때 얼마나 빠르게 적응할 수 있는가에 있다. 오늘의 제품 완성도보다 내일의 적응 속도가 더 중요한 평가 지표가 된다.
이 질문들의 공통점은 하나다. AI를 단순한 도구로 보지 않는 것이다. AI를 일 자체의 전제가 바뀌었음을 알리는 신호로 보는 시각이다.
8. AI 산업의 중심축 이동 — 모델 경쟁에서 제품 경쟁으로
모델을 만드는 것과 제품을 만드는 것은 다른 역량이다
AI 산업은 지금 중요한 전환점을 통과하고 있다. 초기에는 더 강력한 모델을 만드는 것 자체가 경쟁의 핵심이었다. GPT-4, 클로드 3, 제미나이 울트라처럼 모델의 성능 자체가 뉴스가 되고, 벤치마크 점수가 경쟁력의 기준이 되는 시대였다.
그러나 지금은 무게 중심이 이동하고 있다. 기존 AI 모델들이 가능성의 공간을 열어놓았다면, 이제 그 가능성을 실제 사용자의 워크플로우(workflow)로 번역하는 능력이 다음 경쟁의 핵심 축이 된다. 모델을 빠르게 만드는 역량과 그 모델을 실제로 작동하는 제품으로 만드는 역량은 전혀 다른 기술 세트를 요구한다.
캣 우는 바로 이 간극, 즉 최첨단 AI 모델 연구와 실제 사용자가 매일 사용하는 제품 사이의 공간에서 일하고 있다. 클로드 코드가 세계 최고 수준의 AI 코딩 도구로 빠르게 성장한 배경에는 모델 성능의 발전만이 아니라, 그 성능을 사용자가 실제로 경험할 수 있는 제품으로 구현하는 팀의 능력이 있다.
9. 캣 우의 핵심 원칙 — “단순하지만 작동하는 것”
이 문장의 진짜 무게는 어디에 있는가
캣 우가 여러 인터뷰와 글에서 반복적으로 강조하는 원칙은 단순해 보인다.
“Do the simple thing that works.”
(단순하지만 작동하는 것을 하라.)
그러나 이 문장의 핵심은 ‘단순함’이 아니라 ‘작동하는(works)’에 있다. 무언가가 실제로 작동하는지를 확인하는 가장 빠른 방법은 분석이 아니라 실행이다. 더 정확하게는, 가정을 현실에 충돌시키는 것이다. 미리 세워놓은 가정을 현실에 던져 넣고, 부서지는 것을 보고, 부서지지 않은 것만 남기는 방식이다. 이것이 그녀가 말하는 “검증되지 않은 가정을 최대한 빨리 현실과 충돌시켜라”의 의미다.
기존 방식에서 문서는 실행의 전제 조건이었다. 먼저 충분히 분석하고 합의를 이룬 뒤에 실행에 들어가는 방식이다. 그러나 캣 우가 말하는 방식에서 문서는 검증의 결과물이다. 먼저 프로토타입을 만들어 가정이 맞는지를 확인하고, 맞다고 판명된 것만 문서로 기록한다. 문서는 생각을 정리하는 도구가 아니라 이미 검증된 현실을 기록하는 도구가 된다.
이 원칙은 앤스로픽이라는 회사 전체에 깔려 있다. 데이터 사이언스 팀, 재무팀, 마케팅팀, 법무팀, 디자인팀이 각자 클로드 도구들을 주도적으로 도입해 활용하기 시작했다. 조직 전체가 특정 팀의 완료를 기다리는 핸드오프(handoff) 없이 동일한 속도로 움직인다.
10. 한국 사회에 주는 시사점
‘AI 활용법 열풍’의 방향을 다시 묻다
임선영의 글은 한국 사회의 현재 AI 학습 열풍에 직접적인 문제 제기를 담고 있다. AI 활용법 강의, 프롬프트 엔지니어링 교육, 도구 사용법 마스터 등에 집중된 한국의 AI 교육 생태계가 과연 올바른 방향을 향하고 있는지를 묻는다.
한국의 대기업과 공공기관이 추진하는 AI 도입 프로젝트 상당수가, 기존의 업무 프로세스를 그대로 유지한 채 특정 단계에 AI 도구를 삽입하는 방식으로 설계되어 있다. 회의록 정리, 보고서 초안 작성, 데이터 분석 보조 등의 용도로 AI를 도입하는 것은 분명히 효율을 높인다. 그러나 이것은 타자기를 워드프로세서로 바꾸는 수준의 전환이지, 일의 전제를 바꾸는 수준의 전환이 아니다.
캣 우의 관점을 한국 맥락에 적용한다면, 지금 한국 기업과 조직이 물어야 할 질문은 “어떤 업무에 AI를 쓸 수 있는가”가 아니라 “AI가 가능하게 된 세상에서 우리의 업무 구조 자체를 어떻게 재설계해야 하는가”가 되어야 한다.
11. 결론 — 용기의 문제
도구 숙달이 아닌 전제 해체의 용기
임선영은 이 글을 하나의 강력한 결론으로 마무리한다. 지금 우리에게 필요한 것은 AI를 더 잘 쓰는 법이 아니라, 일 자체를 처음부터 다시 정의하는 용기라는 것이다.
도구를 잘 쓰는 것은 기술(skill)의 문제다. 새로운 도구를 배우고, 더 정교한 프롬프트를 작성하고, 더 많은 기능을 활용하는 것은 충분한 학습과 연습으로 획득할 수 있다. 그러나 전제를 해체하고 일을 처음부터 다시 정의하는 것은 용기(courage)의 문제다. 익숙한 방식을 내려놓고, 검증되지 않은 방향으로 나아가며, 빠른 실패와 수정을 반복하는 것은 기술보다 심리적 저항을 극복하는 일이다.
캣 우가 증명하는 것은 이것이다. 가장 앞서 있는 AI 회사에서 가장 중요한 제품을 이끄는 사람조차, 지금의 변화에 맞는 새로운 방식으로 일하기 위해 스스로의 완벽주의와 싸워야 했다. 그리고 그 싸움에서 이기는 방법은 완벽한 계획이 아니라, 불완전하더라도 작동하는 것을 빠르게 만들고, 부서지는 가정을 발견하며, 부서지지 않은 것 위에 다음 단계를 쌓는 것이었다.
이것이 AI 시대 일의 방식이다. 도구가 아니라 환경이 바뀌었고, 전제를 해체할 용기가 있는 조직과 개인만이 그 환경에서 실제로 경쟁력을 유지할 수 있다.
부록: 핵심 개념 정리
| 개념 | 설명 |
|---|---|
| Rising Floor | 모델 능력이 지속적으로 향상되어 제품 개발의 기술적 가능성 자체가 계속 높아지는 현상 |
| Side Quest | 공식 로드맵 외부에서 팀원이 자율적으로 수행하는 단기 탐색 실험 |
| Prototype First | 문서 작성보다 먼저 작동하는 프로토타입을 만들어 가정을 검증하는 방식 |
| Eval (평가) | 모델 또는 제품 기능의 성능을 정량적으로 측정하기 위한 테스트 세트 |
| Do the Simple Thing | 모델 한계를 우회하는 복잡한 구현 대신, 다음 모델 업데이트에 적응하기 쉬운 단순한 구현을 선택하는 원칙 |
| Vibe Coding | 자연어로 의도를 설명하면 AI가 코드를 생성하는 방식의 개발 접근법 |
| PRD | Product Requirements Document, 제품 요구사항 문서. 전통적 PM 방식의 핵심 산출물 |
참고 출처
오마이뉴스, 임선영, “AI 잘쓰는 법? 기획서의 정의부터 바꿔라”, 2026년 4월 3일
https://m.ohmynews.com/NWS_Web/Mobile/at_pg.aspx?CNTN_CD=A0003221002Anthropic 공식 블로그, Cat Wu, “Product Management on the AI Exponential”, 2026년 3월 19일
https://claude.com/blog/product-management-on-the-ai-exponentialMETR, “Task-Completion Time Horizons of Frontier AI Models”, 2026년 3월
https://metr.org/time-horizons/
본 문서는 오마이뉴스 기사 원문과 앤스로픽 공식 블로그의 캣 우 기고문을 바탕으로 심층 분석·재구성한 것입니다.