우리는 잘나서 AI를 쓴 게 아닙니다
카카오스타일 이미준 BPM의 Wanted HiFive 2026 발표를 듣고 정리한 기록 — AI 파워드 팀이 탄생하는 조건
떨렸습니다. 사람들 앞에 서는 게 떨린 게 아니라, 이 이야기를 꺼냈을 때 “그래서 뭐가 달라졌는데요?”라는 질문을 받을까 봐 떨렸어요. 왜냐하면 이건 AI 예찬론이 아니고, 성공 신화도 아니고, 그냥 살아남기 위해 발버둥 쳤던 이야기거든요.
저는 이커머스를 16년째 만들고 있는 사람입니다. 폭포수 방식의 대기업에서 10년, 애자일을 추구하는 스타트업에서 5년. 업무 전환기가 없었던 건 아닌데, 지금 같은 전환기는 처음이에요. 그리고 그 한가운데서 저는 글로벌 K뷰티 플랫폼 ‘피어나’를 만들고 있습니다. 2025년 12월에 킥오프했고, 2026년 4월부터 프랑스에서 시범 운영을 시작했어요.
그냥 읽으면 별것 없어 보이지만, 그 사이에 얼마나 많은 일이 있었는지를 말하려면 좀 솔직하게 이야기해야 합니다.
우리는 안 할 수가 없었어요.
목표 일정이 말도 안 되게 타이트했고, 팀은 소수 정예였고, 만들어야 하는 건 우리가 잘 모르는 나라를 위한 커머스였어요. 처음엔 외주도 검토했습니다. 근데 외주사들이 주는 일정이 우리가 생각한 것보다 훨씬 길었어요. 그래서 결국 내재화로 방향을 틀면서, 개발 리드 희성J와 처음으로 합의를 봤습니다. 회사에서 쓰는 양식이나 PRD 형태보다 AI 툴을 우선으로 하자. 레거시 시스템과는 최대한 분리해서 만들자. 원 플랫폼이 아니라 현지 맞춤형으로 가자. 그리고 기존에 카카오스타일이 가진 지그재그의 셀러와 상품 풀은 그대로 가져와서 쓰자.
이 네 가지가 생산성의 전제조건이었고, 사실상 동아줄이었어요.
로컬라이제이션 문제도 솔직히 말하면 저희 회사의 트라우마와 연결된 부분이 있었어요. 몇 년 전에 글로벌 서비스를 접은 경험이 있거든요. 그때 만든 방식이 지그재그 베이스의 원 플랫폼이었고, 언어와 국가를 확장하는 방식이었는데, 결국 깨달은 게 하나였어요. 한국인의 사상으로 만들어진 서비스를 그대로 쓰면 현지에서 워킹하지 않는다는 것. 그래서 이번엔 8월부터 10월까지 Claude로 딥리서치를 엄청나게 했습니다. 유럽 이커머스 사이트들을 보면서 “왜 상품 상세에 이미지가 이렇게 없지? 텍스트만 몇 줄인데, 이게 맞는 건가, 아니면 부족한 건가?” 같은 가설들을 계속 문화적 맥락으로 채워나갔고요. 그리고 프랑스인 동료를 한 명 채용해서 지금 같은 팀에서 일하고 있어요.
모든 게 AI 없이는 제때 못 열었을 프로젝트였습니다.
2월 6일
저는 이 날을 기억합니다.
Claude Opus 4.6이 나온 날이에요. 체감하신 분들은 아실 거예요. 그전까지는 각각 따로 쓰던 AI 툴들이 갑자기 여기저기 서비스에 붙기 시작했어요. 커넥터가 생기고, 엑셀에도 붙고, 크롬에도 붙고. 할 수 있는 것들이 갑자기 많아지기 시작했습니다. 그전까지가 실험이었다면, 2월 이후부터는 결과가 괜찮아지기 시작한 거예요.
그때 사내에서 어떤 글이 돌았어요. 제목이 “뭔가가 일어나고 있습니다”였는데, 저희 팀도 그 글을 공유하면서 “우리 팀에도 거대한 무언가가 일어나고 있다”고 했습니다. 과장이 아니라 진짜로요.
마케터는 SNS 데이터 자동화 봇을 만들었어요. 매일 수작업으로 확인하던 인스타그램 구독자 수, 조회수 같은 것들을 직접 크롤러로 만들어서 슬랙으로 자동 리포팅되게 했습니다. 피터라는 분이 직접. 개발자 도움 없이요.
콘텐츠 디자이너 분은 더 나아갔어요. 뷰티 이커머스라 유럽 감성에 맞게 이미지를 정제하는 작업이 많았는데, 처음엔 나노바나나 같은 AI 생성 툴로 해보자고 했다가, 어느 순간 직접 구글 서비스 위에 AI 프롬프트 세팅을 올려서 상품 이미지를 집어넣으면 자동으로 정제된 이미지가 나오는 툴을 만드셨어요. 코딩 지식 없이, 직접. 원래 1시간에 20개씩 만들던 걸, 다른 분과 나눠서 2배 속도로 만들고 있습니다.
운영 프로젝트 매니저 분은 좀 다른 의미로 놀라웠어요. 팀이 작다 보니 이분한테 들어오는 일의 범주가 어마어마했거든요. 다국어 회원 약관 생성, 법 검토, 내부 정책 Q&A와 FAQ, 회사 소개 페이지, CS 챗봇 시나리오 설계와 관리. 그런데 전부 AI로 혼자 처리하셨어요. 특히 챗봇 시나리오는 그 시나리오 빌더의 MCP를 Claude에 연결해서 말로 하면 시나리오가 자동 생성되게 하셨고, 회사 소개 페이지는 디자인 파일 받아서 직접 HTML로 개발해서 올리셨어요.
월권이냐고요? 아니요. 저희는 소수의 팀이고 할 수 있는 사람이 하는 구조로 움직였어요. 이게 생산성의 핵심이었습니다.
저도 바뀌었습니다. 처음엔 최소한 Miro로라도 화면을 그려야 한다고 생각했어요. 그런데 그조차도 없어졌어요. 피그마 MCP를 연결해서 Claude가 프로토타입을 어떻게 만드는지 지켜봤더니, 먼저 HTML로 화면을 구성한 다음에 피그마로 던지는 방식이었거든요. 그 과정을 보면서 깨달았어요. PO 레벨에서 내가 피그마로 만드는 게 어차피 디자이너가 다시 보셔야 하는 상황이라면, 그냥 HTML 샘플을 만들어서 줘도 되는 거잖아. 그래서 일하는 방식이 바뀌었습니다. PRD를 정책 기반의 MD 파일로 작성하고, Claude와 계속 상의하면서 HTML 샘플을 만들어서, 둘을 개발자에게 동시에 전달하는 방식으로요.
그러면서 피그마와 안녕하게 됐어요. 저는 사실 항상 고민이 있었거든요. PM이 쓰는 피그마가 도대체 무슨 의미가 있는가. 디자이너만큼 구체적인 UI를 자꾸 설계하려 드는 나 자신을 발견했을 때, 그게 맞는 건지 항상 의심스러웠어요. 그런데 텍스트 정책과 HTML 샘플로 바뀌고 나니까 소통이 훨씬 명확해졌어요. 우리 소통 사이에 항상 AI가 있으니까요.
데이터도 달라졌어요. 저희 팀에 Redash라는 쿼리 툴이 있는데, 거기서 API 키를 Claude에 주고, 내려받은 개발 로직과 연결해서, 사람의 말로 대시보드를 요청해요. “이런 의도로 이 데이터 보고 싶어. Redash에서 테이블 보고 쿼리 짜서 대시보드 만들어줘.” 그러면 짜주고, 저는 내 의도와 맞는지 검증하고, 틀리면 수정하고. 최근에 물류 담당자분이 새로 조인하셨는데, 오시자마자 “물류 대시보드가 어디 있나요?” 물어보셨어요. 제가 조용히 손을 잡고 Claude 설치해드리고, Claude Code 설치해드리고, Redash API 키 받는 방법 알려드렸어요. 그분은 그날부터 일주일 동안 본인이 필요한 대시보드를 전부 본인 입맛대로 만드셨습니다. 그게 더 생산성이 높았어요. 원하는 걸 찾기 시작하니까 업무에 진입하는 속도도 훨씬 빨랐고요.
신인류를 찾아서
2월에 동료 한 명이 퇴사했어요. 12월 킥오프에는 함께했는데, 유학 때문에 2월에 나가신 분이었죠. PO가 두 명뿐인 팀에서 한 명이 빠진다는 건 작은 일이 아니었어요. 그런데 그보다 더 큰 고민이 생겼습니다. 팀이 일하는 방식이 완전히 AI 향으로 바뀐 이 상황에서, 어떤 사람을 뽑아야 하지?
83개의 서류를 보고, 12번의 면접을 봤습니다. 한 사람을 뽑기 위해.
그 과정에서 많은 걸 느꼈어요. 포트폴리오 수준이 지독하게 높아졌어요. 그런데 만나서 얘기해보면 써진 것보다 설명을 못 하는 경우가 많았어요. GPT 첨삭을 많이 받으신 거죠. PM/PO에는 이론이 많습니다. 가설 설정, 검증, 이론 프레임워크. 그걸 역으로 껴맞춘 포트폴리오가 굉장히 많다는 걸 느꼈어요. 이제 포트폴리오만으로는 실제 의도를 가지고 어떻게 만들었는지를 판단할 수 없어요. 오히려 면접에서야 실제 기획자의 사고에 대한 변별력이 생긴다는 걸 완전히 느꼈습니다.
제가 가장 많이 한 질문이 있어요. “포트폴리오에 쓰인 그 프로젝트, 지금 AI 기술 환경이라면 어떻게 바꿔서 다시 설계해보시겠어요?” 해결한 문제는 같아도, AI 시대에는 해답 자체가 달라질 수 있거든요. 그걸 생각할 수 있는 사람을 찾았어요.
제가 찾은 신인류의 기준은 이런 거였어요. 자기 업무를 바꾸는 데 에고가 없는 사람. 고연차일수록 이게 어려워요. 저도 고연차고, 고연차는 안 될 이유를 수천 가지 찾아내거든요. 그리고 문제 해결 방식 자체가 바뀐 사람. “이다음에 뭐 해야지” 라는 기존 프로토콜 안에서 AI를 찾는 게 아니라, 문제의 시작점부터 AI를 냅다 쓸 수 있는 사람.
예를 들면, 저희 팀에서 상품 이미지나 HTML에 담긴 정보를 추출해서 텍스트로 재생산하는 역할이 있어요. 경험 많은 분들은 보통 “상품의 신규 컬러 파싱해서 넣기” 같은 방식으로만 생각해요. 그런데 저는 “이미 만들어진 이미지와 HTML에서 정보를 뽑아서 자동으로 생성하자”고 떠올릴 수 있는 사람을 원했어요. 기존 문법 밖에서 생각할 수 있는 사람.
면접 과정이 힘들었던 건, 그런 사람이 쉽게 나타나지 않아서가 아니라, 기준이 흐릿해질 때였어요. 잘 꾸며진 언어에 잠깐씩 혹했다가, 얘기하다 보면 껍데기임을 느꼈을 때. AI가 언어를 다들 다듬어주는 시대에, 사고는 여전히 사람의 것이라는 게 역설적으로 더 선명하게 보였습니다.
그렇게 뽑은 분이 입사하자마자 번역 품질 문제를 해결하는 방식을 보여줬어요. 저희가 한국어로 등록된 상품 정보를 영어와 프랑스어로 번역하는 파이프라인을 운영하는데, 단일 프롬프트로 계속 수정하다가 생성-검증-생성-검증 4단계 루프로 바꿨는데도 품질이 잘 안 올라오는 상황이었어요. 이분이 오시자마자 신규 모델을 받아서, SQL로 기존 상품 정보를 뽑아서, 로컬에서 직접 번역 샘플링해보고, 결과가 괜찮다고 판단한 뒤에 개발을 요청하셨어요. 입사 한 달이 안 됐을 때요. 적응 속도가 이렇게 달라집니다.
AI 파워드 PM이 해야 하는 것
제가 이 몇 달을 지나면서 AI 파워드 PM이 뭘 해야 하는지에 대해 계속 생각하는 게 있어요.
자기가 AI를 잘 쓰는 게 아니에요. 팀 전체의 생산성을 바꾸는 게 핵심이에요. 마케터가 크롤러를 만들고 싶다고 했을 때, 직접 만드는 방법을 알려드렸어요. 무언가를 일괄 변경하고 싶다고 했을 때, Claude Code로 본인이 직접 하실 수 있는 방법을 안내했어요. 누군가의 업무에 AI를 먼저 대입해서 샘플을 만들어보고, 가장 빠르게 전파하는 사람. 저는 그게 AI 파워드 PM이 팀과 비즈니스를 바꿀 수 있는 가장 중요한 역할이라고 생각해요.
그리고 한 가지 더. 비용이 낮아진 시대에, 리소스 때문에 요구사항을 커팅하는 걸 조심해야 해요. 상대방이 Claude랑 얘기해봤는데 이게 될 것 같다고 오면, 내가 기존 방식으로 “그건 개발 비용이 있어서…”라고 자르면 신뢰가 깨져요. 경계를 부수는 걸 오히려 전파해야 합니다. 네가 생각한 것 이상도 가능할 수 있어, 하고 알려줘야 하고요. 그 요구사항을 어떻게 정리해서 오면 좋을지, AI 가이드나 프롬프트 스킬을 만들어서 줄 수도 있어요.
그리고 생성-검증 루프. 한 방에 프롬프트를 해결하려 하지 말고, 무조건 루프를 설계하세요. 이것만 해도 품질이 달라집니다.
저희가 AI 파워드 팀이 될 수 있었던 건 잘나서가 아니에요. 두 가지 조건이 있었어요. 하나는 레거시와의 분리. 저희 소스 코드는 Claude가 쓴 코드라서, 텍스트로 읽었을 때 바로 이해할 수 있는 수준이에요. 모든 개발 산출물에 MD 파일이 달려 있어서, 무슨 의도로 어떤 순서에 따라 만들어졌는지가 전부 적혀 있어요. 그러니까 저도 Git에서 내려받아서 Claude Code에 폴더를 연결하고 “지금 쇼핑 파일에서 데이터가 어느 시점에, 어떻게 가공돼서 나가?”라고 물으면 바로 나와요. ERD를 알아야 쿼리를 짤 수 있던 장벽이 여기서 허물어지는 거예요.
다른 하나는, 효율을 먼저 계산하지 않은 것. “이게 진짜 효율적인가?”를 먼저 따졌으면 빠르게 적용하지 못했을 거예요. 소넷만 주면서 효과를 보겠다고 하면 안 되는 거랑 같은 얘기예요. 일단 해보고, 생산성이 올라갔는지는 결과로 판단하는 거예요.
저는 나중에 대부분의 팀들이 조금씩 이쪽으로 갈 거라고 생각해요. 기존 레거시 위에서 AI를 얹는 게 아니라, 분리된 구조에서 새로 시작하는 팀들이 먼저 달라질 거예요. 그리고 경험을 벗어난 해법을 찾는 사람들, 이렇게 했었으니까 여기에 AI를 써야지가 아니라, 아예 AI로 다른 방식을 떠올리는 사람들이 늘어날 거라고요.
당신의 팀은 지금 얼마나 변화하고 있습니까?
그 질문이 불편하게 느껴진다면, 아마 변화하고 있는 거예요. 저도 그랬거든요.
이 글은 Wanted HiFive 2026에서 카카오스타일 이미준 BPM의 발표를 듣고 정리한 기록입니다.