이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

"모델이 다 알아서 해주는 미래를 상상하면 제품 만드는 건 쉬워요. 텍스트박스 하나만 있으면 되니까."

캣 우는 이걸 'AGI 약을 적당히 먹기'라고 부릅니다. 너무 많이 먹으면 지금 작동할 제품을 못 만들고, 안 먹으면 곧 시대에 뒤떨어져요. 캣은 클로드 코드와 코워크를 함께 이끌면서, 6개월 걸리던 출시 주기를 1주로 줄인 팀을 운영하고 있어요. 1인 창업가에게도 그대로 적용되는 감각이에요. 지금 모델로 뭘 만들고, 새 모델이 나오면 뭘 빼고, 어디에 베팅해둘지.

AI 시대 PM이 잘못 알고 있는 것

Q. 출시 주기가 6개월에서 1주로 줄었다고 하셨어요. 그 변화가 일하는 방식을 어떻게 바꾸나요?

AI 이전에는 기술 변화 속도가 훨씬 느렸어요. 그래서 6개월에서 12개월 단위로 계획을 세울 수 있었죠. 기능을 비교적 천천히 내놓다 보니, 파트너 팀이랑 조율하는 데 굉장히 큰 비중을 뒀어요. 그쪽 팀이 이 기능을 받쳐줄 다른 기능을 같이 출시해야 우리 기능이 살아나는 구조였거든요. 그때는 코드를 만드는 비용이 너무 비쌌어요.

그런데 지금은 AI 덕분에 엔지니어링이 가속화됐고 모델 성능이 빠르게 좋아지면서, 기능 출시 주기가 6개월에서 한 달, 때로는 일주일, 가끔은 하루로 줄었어요. 이런 환경에서는 일단 빠르게 내보내는 게 중요해요.

PM에게 무엇이 달라졌느냐. 파트너 팀과 분기 단위 로드맵을 정렬하는 데 힘을 덜 쓰고, 어떻게 하면 가장 빨리 제품을 사용자 손에 쥐여줄 수 있을지에 더 집중해야 해요. 우리 제품 어딘가에 '컨셉 코너' 같은 공간을 만들어서, 엔지니어든 PM이든 아이디어가 생기면 그 주 안에 사용자 손에 도착하게 해야 하는 거죠.

AI 네이티브 제품에서 잘하는 PM은 아이디어에서 출시까지의 시간을 어떻게 줄일지를 고민하고, 우리 제품에서 무조건 작동해야 하는 핵심 태스크가 뭔지를 정의해주는 사람이에요.

Q. '빨리 움직이는 것'이 핵심이라고 하셨는데, 팀이 이렇게 빠르게 움직이게 만드는 비결이 뭔가요?

첫째는 명확한 목표 설정이에요. LLM은 너무 범용이라 누구를 위해, 어떤 문제를, 어떤 사용 케이스로 풀 건지가 굉장히 모호해져요. 그래서 좋은 PM은 이렇게 말할 수 있어야 해요. "우리 핵심 사용자는 전문 개발자다. 이 기능이 풀려는 문제는 권한 승인 팝업이 너무 많아서 사용자가 피로감을 느낀다는 거다. 사용 케이스는 엔터프라이즈 전문 개발자가 안전하게 권한 승인 팝업 0개에 도달하는 거다." 이렇게 정의해두면 권한 팝업을 줄이는 수많은 잘못된 접근법을 사전에 걸러낼 수 있어요.

둘째는 반복 가능한 출시 프로세스예요. 클로드 코드는 거의 모든 기능을 '리서치 프리뷰'로 내보내요. 출시할 때 그렇게 명확히 브랜딩하죠. 사용자에게 "이건 초기 제품이고, 우리가 시도해보는 아이디어고, 피드백을 받아서 다듬는 중이고, 영원히 지원될 거라고 약속할 수 없다"고 분명히 알려주는 거예요. 이렇게 하면 출시에 대한 우리 쪽 부담이 줄어들어요. 1~2주 안에 일단 뭔가를 내보낼 수 있죠.

셋째는 크로스펑셔널 파트너를 언제 끌어들이고 그들이 뭘 기대해도 되는지에 대한 프레임워크를 PM이 만들어줘야 해요. 우리는 엔지니어링, 마케팅, 문서 팀 사이에 굉장히 빡빡한 프로세스가 있어요. 엔지니어가 기능이 준비됐다고 느끼고 내부 도그푸딩(자기 팀이 실제 업무에 직접 써보기)을 마치면 '에버그린 런치 룸'이라는 슬랙 채널에 올려요. 그러면 문서 담당, PMM 담당, 데브렐 담당이 바로 뛰어들어서 다음 날 마케팅 발표를 돌릴 수 있어요. PM의 역할이 바로 이런 프로세스를 짜는 거예요.

Q. PRD(제품 요구 사항 문서)는 어떻게 다뤄지나요? 목표 정렬이 중요하다고 하셨는데 PRD 쓰시나요?

저희가 하는 건 크게 두 가지예요. 첫째, 굉장히 엄격한 지표 관리를 해요. 매주 팀 전체와 함께 지표 리뷰를 합니다. 모든 팀원이 우리 비즈니스의 모든 면을 깊이 이해하는 게 목표예요. 핵심 KPI가 뭔지, 어떻게 움직이고 있는지, 무엇이 그걸 움직이게 하는지.

둘째, 팀 원칙(team principles) 리스트가 있어요. 우리 핵심 사용자가 누구인지, 왜 그 사용자가 핵심인지를 명시해둬요. 이걸 모두 글로 적어두는 이유는 누구든 우리 비즈니스가 어떻게 돌아가는지, 우리에게 중요한 게 뭔지, 무엇을 트레이드 오프할 수 있는지를 본인이 이해하고 있게 하기 위해서예요. 이렇게 하면 PM이나 다른 이해관계자에게 막혀 있다는 느낌 없이 각자 결정을 내릴 수 있어요.

가끔은 PRD도 써요. 특별히 모호한 기능에는 한 페이지짜리 문서를 쓰는 게 도움이 돼요. 목표, 사용자가 즐거워할 사용 케이스, 현재 어떤 실패 모드를 고쳐야 하는지를 적어두는 거죠. 인프라 작업이 많이 들어가는 몇 달짜리 프로젝트는 여전히 PRD를 써요.

Q. 인간의 두뇌가 가까운 미래에도 계속 필요할 영역이 어디라고 보세요?

뭐에 집중할지 정하고, 시장이 어디로 가는지 알고, 무엇을 우선순위로 할지 정하는 일. 그리고 우리가 만든 게 좋은지 옳은지 판단하고, 어떤 초기 버전이라도 일단 세상에 내보내는 일. 그것 외에 또 있다면, 인간은 모델이 갖지 못한 수준의 상식을 제공해요.

제품 출시에는 작은 움직이는 조각이 천 개쯤 돼요. 작은 것들이지만 잘못될 수 있는 게 항상 많아요. 모델은 모든 이해관계자가 누군지, 그들끼리 어떻게 연결돼 있는지, 그들의 선호가 뭔지, 그들을 끌어들이려면 어떤 채널로 소통해야 하는지에 대한 감이 늘 좋은 건 아니에요. 이런 좀 더 암묵적인 상식, EQ에 가까운 지식은 여전히 굉장히 가치 있어요.

코드 한 줄 안 짜는 사람도 코워크가 필요한 이유

Q. 클로드 코드, 클로드 데스크탑, 코워크. 각각을 언제 써야 하는지 정리해주실 수 있나요?

저는 클로드 코드를 터미널에서 써요. 일회성 코딩 태스크를 던지면서 최신 기능을 다 쓰고 싶을 때요. CLI(명령줄 인터페이스, 검은 터미널 화면)는 우리 첫 제품 표면이고, 새 기능이 가장 먼저 도착하는 곳이에요. 그래서 가장 강력해요. 한두 개 태스크를 동시에 굴릴 때 주로 써요.

데스크탑은 프론트엔드 작업이 필요할 때 진가를 발휘해요. 제가 좋아하는 사용법 하나는 프리뷰 기능이에요. 웹 앱을 만드는 중이라면 클로드 코드와 데스크탑을 함께 띄우고, 오른쪽에 프리뷰 패널을 열어서 클로드와 대화하면서 실시간으로 만들어지는 웹 앱을 봐요.

그래픽 환경이 더 편한 사람에게도 좋아요. 비기술자에게는 터미널이 굉장히 낯설어요. 무서운 팝업이 컴퓨터에 막 뜨고, 다른 제품들처럼 클릭해서 돌아다닐 수 없으니까요. 그래서 터미널이 불편한 분들에게는 데스크탑을 강력 추천해요.

웹과 모바일은 외출 중에 태스크를 시작하기에 좋아요. CLI와 데스크탑은 노트북 앞에 있어야 쓸 수 있는데, 산책 중에 노트북을 안 들고 다닐 때가 있잖아요. 모바일이 있으면 그런 외출 중 시작이 가능해요.

코워크는 결과물이 코드가 아닌 모든 일에 자리를 잡아요. 슬랙 0으로 가는 일이든, 인박스 0이든, 다가오는 고객 미팅용 슬라이드 덱이든, 어떤 기능의 목표 문서나 출시 계획 문서를 빠르게 쓰는 일이든. 저는 머릿속에서 이렇게 나눠요. 결과물이 코드면 클로드 코드나 데스크탑. 결과물이 코드가 아니면 코워크.

Q. 코워크가 빠르게 성장하고 있는데 사람들이 아직 어디에 쓸지 잘 몰라요. 캣은 어떻게 활용하세요?

코워크를 시작할 때 가장 먼저 해야 할 건 본인 역할에 관련된 데이터 소스를 다 연결하는 거예요. 코워크는 컨텍스트가 풍부해야 결과물을 잘 만들 수 있거든요. 저는 구글 캘린더, 슬랙, 지메일, 구글 드라이브를 다 연결해놨어요. 코워크가 필요한 컨텍스트를 알아서 찾고, 질문하고, 스레드를 끌어다 쓸 유연성을 갖게 되는 거죠. 결과물 품질이 엄청나게 올라가요.

어제 밤에 한 작업을 예로 들어볼게요. 곧 '코드 위드 클로드' 컨퍼런스가 있고, 거기서 제가 발표 몇 개를 해요. 그중 하나가 클로드 코드의 어시스턴트에서 에이전트로의 전환을 다루는 발표예요. 그 발표에서 보여주고 싶었던 게 두 가지였어요. 이 전환을 가능하게 한, 우리가 출시한 제품들 전부. 그리고 내부에서 데모로 쓸 만한 성공 사례들.

저는 코워크에 다뤄야 할 포인트 초안을 넣고 제가 하고 싶은 이야기 흐름을 알려줬어요. 그러고 한 시간 동안 코워크가 일했어요. 트위터를 훑어서 우리가 뭘 출시했는지 봤고, 슬랙의 여러 채널을 살폈어요. 이걸 다 종합해서 20페이지짜리 덱을 만들어줬고, 저는 오늘 아침에 일어나서 그걸 읽었어요. 꽤 좋았어요. 직접 만들었으면 몇 시간 걸렸을 슬라이드 덱이 꽤 좋은 초안으로 나와 있는 거예요. 그래서 저는 데모가 훌륭한지에만 집중할 수 있었어요.

Q. 어제 그 슬라이드 덱을 만들 때 어떤 프롬프트를 넣으셨어요?

대충 이렇게 썼어요. "코드 위드 클로드 컨퍼런스용 슬라이드 덱을 만들어줘. 우리 PMM이 다뤄야 한다고 제안한 내용은 이거야. 내가 직접 만들었지만 마음에 안 드는 현재 초안은 이거야. 먼저 자세한 아웃라인 제안을 만들어줘. 그리고 기조 발표(이 발표가 더 중요해)와 너무 겹치지 않게 해줘."

그러면 클로드가 제가 보낸 링크를 다 읽고 제안 아웃라인을 만들어줘요. 저는 그 제안과 거기 있는 모든 아이디어를 읽고, 최종 덱에 뭐가 들어갈지 결정해요. 이게 PM 역할이 아직 살아 있는 한 예라고 봐요. 클로드는 훌륭한 브레인스토밍 파트너고, 엄청난 양의 정보를 빠르게 종합해서 가능성을 다 보여줘요. 하지만 최종 결정 - 최종 제품에 뭐가 들어가야 하느냐 - 은 여전히 사람의 몫이에요.

Q. 디자인 시스템 부분은 어떻게 하셨어요? 코워크가 어떻게 앤트로픽 디자인 시스템을 알죠?

저희가 이미 모든 외부 발표에 쓰는 표준화된 덱이 있어요. 그걸 클로드에게 접근하게 해줬어요. 그러면 우리가 어떤 컬러를 쓰는지, 어떤 폰트를 쓰는지, 어떤 슬라이드 포맷이 가능한지 다 보이거든요. 예시 슬라이드 20장 정도가 그 안에 있어요. 피그마 MCP 같은 곳에 슬라이드 포맷을 저장해뒀으면 거기서도 끌어올 수 있어요.

Q. 직접 만든 내부 도구 중에 흥미로운 사례가 있나요?

클로드 코드 영업 팀의 한 분이 자기가 비슷한 덱을 반복해서 만들고 있다는 걸 깨달았어요. 그래서 웹 앱을 하나 만들었어요. 잘 작동하는 핵심 클로드 코드 덱 예시들 - '101'(입문), '201'(중급), '클로드 코드 마스터하기' - 이 들어있는 앱이에요. 거기에 고객별 컨텍스트를 입력하는 기능을 붙였어요. 세일즈포스에서, 공(Gong, 영업 통화 녹음 분석 툴)에서, 다른 노트에서 데이터를 끌어와 특정 고객용으로 덱을 커스터마이징해요.

클로드 코드가 회사 전체에 풀어준 것 중 하나가, 원하는 어떤 커스텀 앱이든 만들 수 있게 진입 장벽을 확 낮춰준 거예요. 그래서 SaaS 도구가 완벽히 맞지 않는 사용 케이스를 위해 사람들이 개인화된 업무 소프트웨어를 마구 만들어요.

AI 시대 PM이 길러야 할 스킬

Q. AI 회사들이 PM을 채용할 때 가장 보고 싶어하는 스킬이 뭔가요?

가장 어려운 스킬은 한 달 뒤 제품이 어떤 모습이어야 하는지 정의하는 능력이에요. 모델이 그 시점에 뭘 할 수 있을지, 사용자 행동이 어떻게 바뀔지가 굉장히 모호해요. 그래도 최고 PM들은 패턴을 봐요. 사용자가 현재 제품의 한계를 어떻게 '오용'하고 있는지를 보고 방향을 잡고, 거기로 꾸준히 실행하다가, 모델 능력이 예상보다 훨씬 좋거나 훨씬 안 좋으면 경로를 바꿔요.

'AGI 약을 적당히 먹는 것'이 굉장히 어려워요. 사람은 누구나 모델이 엄청 똑똑해진 미래를 상상할 수 있고, 그러면 사실 그렇게 복잡한 제품은 필요 없어요. 텍스트박스 하나만 있으면 돼요. 모델한테 원하는 걸 말하면 모델이 너무 똑똑해서 필요한 도구든 통합이든 다 알아서 추가하고, 자기가 불확실할 때를 알아서 명확화 질문을 하면 되거든요. 그런 'AGI 슈퍼 모델'을 위한 제품 만들기는 사실 쉬워요. 어려운 건 '지금 모델'에서 어떻게 최대 능력을 끌어내느냐예요. 어떻게 사용자를 '골든 패스'(가장 잘 작동하는 경로)로 데려가느냐. 어떻게 사용자가 모델의 강점과 상호작용하면서 약점을 메우게 만드느냐. 이 스킬은 굉장히 희소해요.

Q. 그 감각은 어떻게 키우나요?

모델과 이야기하고 직접 쓰는 데 많은 시간을 써요. 제가 정말 좋아하는 게 하나 있어요. 모델한테 자기 행동을 돌아보라고 시키는 거예요.

모델이 예상치 못한 행동을 할 때가 있어요. 예를 들면 프론트엔드 변경을 하고 테스트는 돌리는데 정작 UI를 직접 써보지 않는 경우. "왜 그렇게 했어?"라고 물어보면, 가끔은 "시스템 프롬프트에 헷갈리는 부분이 있었어요"라거나 "프론트엔드 검증이 이 태스크의 일부인 줄 몰랐어요"라거나 "그 검증을 서브 에이전트에 위임했는데 서브 에이전트가 테스트를 안 했고, 저는 그 결과를 확인 안 했어요"라고 답해요. 모델이 왜 그런 결정을 내렸는지 호기심을 갖고 묻는 것만으로, 무엇이 모델을 잘못된 길로 이끌었는지가 드러나요. 그러면 하네스(harness)를 고쳐서 그 간극을 메울 수 있어요.

다음으로 도움이 되는 건 모델 피드백을 가장 정확하게 주는 신뢰할 만한 사용자가 누군지를 알아내는 거예요. 다른 사람들보다 훨씬 더 잘 말로 표현하는 사람이 한 줌 있어요. 어떤 모델이나 모델·하니스 조합이 좋은지를 명확하게 짚어내는 사람들. 피드백을 주는 사람은 많지만 모두의 피드백이 똑같은 무게는 아니에요. 5명 정도 신뢰할 사람을 찾는 게 정말 빠른 피드백을 받는 데 중요해요.

세 번째는 평가(eval)를 만드는 일이에요. 모두가 좋아하는 일은 아니지만 유용해요. 수백 개씩 만들 필요는 없어요. 잘 만든 평가 10개만 있어도 팀이 목표가 뭔지, 거기까지 얼마나 왔는지, 무엇이 비어 있는지를 정량화하는 데 큰 도움이 돼요.

새 모델이 나올 때마다 일어나는 일

Q. 새 모델이 나오면 이미 만든 제품을 다시 손봐야 한다고 하셨어요. 얼마나 자주 그런 일이 일어나요?

새 모델로 인한 변경의 많은 부분이 더 이상 필요 없어진 기능을 빼는 거예요. 모델이 자연스럽게 못 하는 행동을 보완하려고 추가한 일종의 목발 같은 기능들이 있거든요.

대표적 예가 투두 리스트예요. 클로드 코드를 처음 출시했을 때, 사람들이 큰 리팩토링을 요청했어요. "이 20곳을 다 바꿔줘." 클로드 코드가 "좋아요"라고 한 뒤 5곳만 바꾸고 멈췄어요. 우리는 어떻게 20곳을 다 기억하게 만들지 고민하다가, 우리 팀의 시드(Sid)가 "사람이라면 어떻게 할지" 생각해보자고 했어요. 사람이라면 다 바꿔야 할 곳 리스트를 만들죠. 그래서 클로드한테 그런 도구를 줬어요. 투두 리스트요. 그러자 클로드가 20곳을 다 고치게 됐어요.

그런데 오푸스 4(Opus 4) 이후 모델은 강제하지 않아도 자연스럽게 투두 리스트를 자기가 만들어 써요. 예전 모델한테는 "투두 리스트 다 끝냈어? 다 끝내기 전엔 끝낼 수 없어"라고 계속 상기시켜야 했는데, 이후 모델은 별다른 프롬프트 없이도 모든 항목을 끝내야 한다는 걸 알아요. 요즘은 투두 리스트가 사용자 입장에서 보기 좋다는 정도지, 필수 기능은 아니에요.

Q. 그럼 새 모델 출시할 때마다 시스템 프롬프트를 통째로 다시 보세요?

모델을 출시할 때마다 시스템 프롬프트 전체를 다시 읽고, 각 섹션마다 "모델한테 이 알림이 여전히 필요한가?"를 다시 봐요. 필요 없으면 빼요.

새 모델이 진짜 신나는 건 완전히 새로운 기능을 풀어준다는 점이에요. 우리가 이전 모델로 시도해봤는데 정확도가 출시할 만큼 높지 않아서 보류했던 기능이 많아요.

대표적인 게 코드 리뷰예요. 우리는 코드 리뷰 제품을 몇 번 만들어봤고, 과거 단순한 버전 - 슬래시(/) 코드 리뷰 명령어 - 을 내놓기도 했어요. 그런데 최근 모델에 와서야 우리 엔지니어링 팀이 PR 머지 전에 이 코드 리뷰가 통과되는 것에 의존할 만큼 좋아졌어요. 오푸스 4.5, 4.6 그리고 소넷 4.6(Sonnet 4.6)에 와서야 여러 코드 리뷰 에이전트를 동시에 돌려 코드베이스 전체를 훑고, 엔지니어가 머지 전에 해결해야 할 진짜 이슈 목록으로 종합해줄 수 있게 됐어요.

Q. 새 모델이 풀어줄 가능성에 미리 베팅하면서 제품을 만들어두는 거네요?

맞아요. 아직 작동하지 않는 제품을 미리 만들어두는 게 중요해요. 그래야 이 제품이 작동하려면 뭐가 부족한지 알 수 있어요. 그러고 나서 새 모델이 나오면 기존 프로토타입에 갈아 끼우고 "이 새 모델이 그 간극을 메우는지" 보면 돼요.

Q. 클로드 코드와 코워크의 장기 비전은 어떻게 그리세요?

저희는 빌딩 블록 관점으로 봐요. 클로드 코드와 코워크 둘 다 핵심 블록은 '개별 태스크 성공'이에요. 어떤 결과물을 만들고 싶고, 명확한 프롬프트와 설명을 주면, 동료에게 공유하거나 머지할 만한 수준의 결과물을 일관되게 만들어내느냐. 그게 코어 블록이에요. 모델이 똑똑해질수록 태스크 성공률이 훨씬 높아져요.

그러고 나면 동시에 여러 태스크를 하는 단계로 넘어가요. 2025년 말에 '멀티 코딩'이 큰 트렌드였고, 그 이후 더 커지고 있어요. 한 태스크가 잘 되면 6개 태스크를 동시에 할 수 있게 되는 거죠.

모델이 더 똑똑해지면서 이 흐름을 그대로 늘려보면, 다음엔 50개 클로드를 동시에 돌리거나 수백 개를 돌리는 거예요. 그러면 모든 걸 로컬 머신에서 돌릴 수 없어요. RAM이 부족해서요. 아마 원격으로 돌게 될 거고, 사용자가 어떤 태스크를 들여다봐야 할지 알 수 있게 인터페이스를 만들고, 에이전트가 완전히 작업을 검증하도록 만들어서 "끝났다"고 표시될 때 빠르게 확인하고 신뢰할 수 있도록.

그리고 이 과정 자체가 자기 개선되도록 - 사용자가 마음에 안 드는 태스크를 보고 피드백을 주면, 모델이 미래의 모든 실행에 그 피드백을 반영해 다시는 같은 실수를 하지 않게 - 만드는 것. 우리는 사용자를 이 진행 단계 위로 함께 데려가려고 해요.

AI 시대를 살아남는 법

Q. PM, 창업가, 크로스펑셔널 직군 모두 자기 직업의 미래를 걱정해요. 이 전환에서 살아남을 뿐 아니라 잘 살아갈 조언이 있나요?

AI는 모두에게 예전보다 훨씬 큰 레버리지를 줘요. 같은 수동 작업을 여러 번 하고 있다는 걸 깨달을 때마다, 클로드 코드든 코워크든 다른 AI 도구든 그걸 자동화할 방법을 생각해봐요.

대부분의 직업에는 자기가 정말 사랑하는 창의적인 부분과, 진짜 하기 싫은 지루한 부분이 같이 있잖아요. AI의 매력은 그 지루한 부분을 대신해줄 수 있다는 거예요. 그 수동 작업을 할 때마다 학습해서 일반화하고 자동으로 돌릴 수 있어요. 그러면 본인은 창의적인 부분에 집중할 수 있고, 예전보다 훨씬 더 많은 일을 할 수 있어요.

즉각적인 조언은 이거예요. 반복되는 부분을 찾아서 클로드에게 넘기세요. 그 자동화의 성공률이 굉장히 높아질 때까지 반복하세요. 그리고 본인이 팀, 제품, 회사를 위해 더 할 수 있는 일이 뭔지, 그동안 사람이 시간이 없어 못 했던 일이 뭔지, "회사가 했어야 했는데 시간이 없어 못 한 사이드 프로젝트"가 뭔지에 집중하세요. AI가 잡일을 해주면 예전엔 없던 20% 시간이 추가로 생겨요.

Q. 자동화를 95%에서 멈추는 사람이 많아요. 그게 왜 문제죠?

자동화가 100% 작동하지 않으면 사실상 자동화가 아니에요. 마지막 5~10%가 시간을 더 잡아먹어요. 자동화를 만드는 것 자체가 직접 하는 것보다 훨씬 느릴 때도 있어요. 그래도 권하고 싶은 건, 100%까지 가져갈 정도로 정말 신경 쓰는 자동화 하나를 스코프 잡고, 그걸 100%까지 가져갈 만큼 끈기를 들이는 일이에요. 클로드에게 본인의 선호를 가르치고 피드백을 주고 스킬을 개선시켜서 100%까지 가게 만드세요. 그래야 거기에 의존할 수 있어요. 95% 자동화에는 정말 가치가 별로 없어요.

저도 이런 실수를 해요. 저는 코워크에게 지메일 인박스 0으로 가는 걸 가르치는 중이에요. 시간이 많이 들었어요. 아직 거기 도달 못 했어요.

Q. 카파시(Andrej Karpathy)가 흥미로운 분리에 대해 얘기했어요. 옛날에 챗GPT나 클로드를 한 번 써보고 "이거 별로네" 하고 포기한 사람들과, 코딩에 써보면서 진짜 강력함을 느낀 사람들 사이에 큰 간극이 있다는 거예요.

큰 시프트는 2024년 세대 제품은 챗 기반이었고, 클로드 코드 세대 제품은 액션 기반이라는 점이에요. 사람들이 진짜 '아하' 하는 순간은 클로드가 자기 대신 행동을 직접 할 수 있다는 걸 느끼는 순간이에요. 에이전트가 "뭘 해야 하는지 알려주는" 게 아니라 "직접 해주는" 거예요. 그 감각을 느끼면 눈이 떠져요.

Q. 마지막으로 이 변화 속에서 진짜 레버리지를 얻고 싶은 사람들에게 강조하고 싶은 게 있다면요?

매일 본인이 실제로 쓰는 앱을 만드세요. 사람들이 AI를 갖고 놀면서 프로토타입 앱을 만들고 워크플로를 짜는 걸 정말 많이 봐요. 그런데 한 번 만들고 다시 안 돌아오는 프로토타입에서는 배우는 것도 제한적이고, 진짜 레버리지도 얻을 수 없어요. 본인이 더 많은 일을 하게 해주지 않는 프로토타입 앱은, AI가 본인 하루에 실제로 가치를 안 주는 거예요. 진짜 사용을 통해서만 가치가 나와요.

반대 극단도 조심해야 해요. 도구 커스터마이징에 너무 빠져서 스킬과 MCP와 워크플로 개선을 잔뜩 추가하는 사람들이 있어요. 그게 본인의 진짜 목표 - 제품을 출시하거나 기능을 만드는 일 - 에서 멀어지게 해요. 커스터마이징에 시간을 너무 쏟다가 정작 잠도 못 자고 핵심 태스크는 안 하는 사람들이 있어요. 단순한 셋업이 사실 더 잘 작동해요.

결국 매일 자기 손이 닿는 앱 하나에 집중하세요. 그게 AI를 진짜로 자기 편으로 만드는 유일한 길이에요.

오늘 레터가 좋았다면, 조쉬의 뉴스레터를 주변에 알려주시거나, 구독을 해주세요. 소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]