Inside Figma’s PM OS: skills, agents, and Auto XP
원본 영상: Inside Figma’s PM OS: skills, agents, and Auto XP
채널: How I AI
개요
Figma의 제품 관리자 에즈라가 AI로 해결하려 한 첫 문제는 일상적인 업무 누락이었다. 제품 출시 전에 지원팀에 알리고, 회의 내용을 정리해 동료에게 전달하고, 특정 기능의 담당자를 찾는 일이 출발점이었다. 여러 역할을 동시에 수행하는 PM에게 AI는 중요하지만 자꾸 빠뜨리는 일을 꾸준히 처리하도록 돕는 도구였다.
개인용 자동화는 동료들과 공유하는 PM OS로 발전했다. 영상에서 31개 스킬을 갖춘 것으로 소개되는 PM OS는 조직 정보, 업무 맥락, 기억, 작업 지침을 묶은 저장소다. 대화는 Slack 업무 파악과 문서 작성, 자기 코칭, 브라우저를 이용한 제품 점검을 거쳐 실험 자동화 시스템 Auto XP와 실시간 글쓰기 보조 도구로 이어진다.
이 사례들의 공통점은 AI가 다음 행동에 필요한 맥락을 찾아 업무 흐름에 참여한다는 것이다. 에즈라는 그 효용을 설명하면서도 PM OS의 비교 성능을 평가할 벤치마크는 마련하지 못했으며, Auto XP도 자신이 구상한 운영 방식에 아직 완전히 도달하지는 않았다고 말한다.
빠뜨리는 일을 줄이는 데서 시작한 PM OS
“적절한 곳에서 게을러지기”
에즈라는 엔지니어들에게 자신의 목표를 “적절한 곳에서 게을러지는 것”이라고 말한다고 한다. Figma에 합류할 때는 회사 전체가 AI를 적극적으로 활용하고 있을 것으로 예상했지만, 자신이 본 범위에서는 엔지니어링 이외 조직의 업무 활용 사례가 많지 않았다.
그는 Claude Code를 사용하며 자신의 반복 업무를 자동화하기 시작했다. 이를 지켜보던 다른 PM들이 관심을 보였고, 당시 제품 책임자도 PM 전반의 AI 활용을 높이려면 무엇이 필요한지 물었다. 개인의 작업 방식을 다른 사람도 쓸 수 있는 형태로 바꾸는 계기였다.
자동화 대상을 고르는 기준은 제대로 하지 못하거나 아예 하지 못하는 일이었다. 출시 과정에서 지원 조직을 적절한 시점에 참여시키는 일, 회의 내용을 정리하는 일, 코드나 기능의 담당자를 찾는 일이 여기에 해당했다.
진행자는 이를 기본적인 업무 수행 수준을 높이는 일과 더 높은 성과의 가능성을 여는 일로 나누어 설명한다. 에즈라의 출발점은 전자에 가까웠다. 동료가 필요한 정보를 받지 못하거나 자신을 기다려야 하는 상황을 줄이는 것만으로도 가치가 있다는 접근이다.
조직의 맥락을 먼저 갖추다
PM OS는 터미널에서 사용하는 간단한 저장소로 시작했다. 세션이 열리면 사용자가 어떤 PM인지, 누구와 일하는지 등의 정보를 읽고 기억 파일과 스킬을 활용한다. 에즈라는 이를 PM의 비서실장 역할에 비유한다.
대표적인 기능은 조직 내 담당자를 찾는 것이다. 에즈라에 따르면 Figma에는 여러 조직도 도구가 있었지만, 정보가 업무에 유용한 방식으로 연결되어 있지는 않았다. PM OS는 누가 어느 팀에서 일하고 특정 영역을 담당하는지 파악해 문서 작성에도 활용한다. 사용자가 매번 엔지니어링 매니저나 디자이너를 알려주지 않아도 관련 검토자를 포함하는 식이다.
큰 조직에서는 어떤 결정에 누가 참여해야 하는지, 다른 팀이 비슷한 일을 하는지 알아내는 것 자체가 어렵다. PM OS는 업무를 조직 안에서 진행하는 데 필요한 기초 맥락부터 마련했다.
Slack에서 후속 행동을 찾다
에즈라가 하루에도 여러 번 실행한다는 what’s up 스킬은 관련 Slack 대화와 프로젝트 정보를 모은다. 이를 통해 누구에게 무엇을 전달해야 하는지, 아직 결정되지 않은 일이 무엇인지 파악한다. 진행 중인 실험의 상태를 함께 살펴보는 변형도 있다고 설명한다.
이 스킬은 중요한 채널과 대화의 전체 스레드를 읽고 후속 행동과 미해결 결정을 찾는다. 에즈라는 이를 일종의 “메타 Slack”처럼 사용한다.
스킬에는 Figma 내부에서 정보를 찾는 방법이 상세히 담겨 있다. 에즈라는 모델이 발전한 지금은 일부 지침이 지나치게 구체적일 수 있다고 인정하면서도, 조직의 복잡한 정보 구조를 탐색하는 데 유용했다고 회고한다. 별도 설정이 없는 Codex와 비교해 지금도 얼마나 더 나은지 궁금하지만, 이를 평가할 벤치마크를 만드는 데는 성공하지 못했다고 말한다.
함께 쓰되, 계속 줄여가는 스킬
공통 기반과 개인 작업 공간
PM OS의 기본 구조는 단순하다. agents.md가 도구의 행동 방식을 정하고, 여러 스킬이 언제 실행되어 무엇을 할지 설명한다. 실행 시 새 버전이 있는지 확인하는 명령 훅도 둔다.
온보딩 과정에서는 기본 템플릿을 바탕으로 개인용 구성을 만든다. 공통으로 내려받는 저장소와 개인 작업 공간을 나누어, 사용자가 자신의 내용을 비공개로 보관하면서 공통 기반을 활용하도록 했다.
GitHub를 사용해 본 적 없는 PM들도 함께 쓸 수 있어야 했다. 에즈라와 동료들은 당시 사용할 수 있는 도구를 조합해 배포와 개인화 문제를 해결했다.
실제 사용으로 걸러내다
초기 개발은 소수의 PM이 작은 Slack 채널에서 아이디어를 나누고 PR을 올리는 방식으로 진행됐다. 먼저 다양한 스킬을 빠르게 만들고, 이후 불필요한 것을 줄였다.
PM들이 함께한 오프사이트에서는 도구를 설치하고 사용하며 직접 수정해 보도록 했다. 무엇이 좋고 나쁜지 적극적으로 비판하도록 했고, 그 과정에서 스킬이 추가되거나 축소·삭제됐다. 에즈라는 모델의 성능이 좋아질수록 더는 필요하지 않은 지침을 빼려고 한다고 말한다.
사용량을 자동 수집하는 계측 장치는 두지 않았다. 사용자가 감시받는다고 느끼지 않기를 바랐고, 본업 외 시간을 활용한 프로젝트라 계측에 쓸 시간도 부족했다. 대신 Slack에서 직접 피드백을 받았다. 이후 엔지니어링 매니저들이 사용하기 시작했고, 데이터 과학자들은 이를 바탕으로 별도의 버전을 만들었다고 한다.
산출물 제작과 자기 코칭
Build Artifact는 간단한 HTML 산출물을 만들고 내부 호스팅 도구로 게시하는 작업을 돕는다. 에즈라는 팟캐스트 시연용 대시보드도 이 방식으로 만들었다고 설명한다. HTML 템플릿과 선호하는 CSS 구성을 활용해 다른 사람에게 보여줄 결과물을 만드는 용도다.
FigJam을 활용하는 스킬도 소개된다. 한 PM이 만든 빌더는 Figma MCP를 통해 워크숍 템플릿을 생성한다. 에즈라는 결과물의 구성과 동작 방식에 제작자의 취향이 많이 담겨 있다고 말한다. 작업 절차와 함께 좋은 결과물에 대한 판단 기준도 재사용하는 셈이다.
또 다른 활용은 자기 코칭이다. 과거에 사람을 관리하다가 다시 개인 기여자 역할을 맡은 에즈라는 다른 사람에게 조언을 구하기 전에 자신의 문제를 정리하는 데 이 스킬을 쓴다. 회사의 경력 단계별 기대, 자신이 받은 피드백, 과거의 상호작용을 함께 제공한다.
예를 들어 동료와 소통이 어려울 때, 이전에도 그 사람의 의도를 오해했다가 대화로 풀었던 경험을 떠올리게 할 수 있다. 에즈라는 이런 맥락이 자신이 문제를 과도하게 받아들이는지, 소통 방식을 조정해야 하는지 생각하는 데 유용하다고 평가한다. 다른 사람의 조언을 구하기 전, 먼저 자신의 반응을 돌아보는 사용법이다.
브라우저에서 실제 업무를 수행하다
읽고 쓰기 좋은 환경으로
초기 PM OS는 Claude의 터미널 인터페이스에서 사용했다. 하지만 글을 많이 읽고 쓰는 PM 업무에서 모든 내용을 고정폭 글꼴로 보는 경험은 불편했다.
팀은 로컬에서 실행되는 웹 프런트엔드를 만들었다. 브라우저에서 마크다운을 읽기 좋게 표시하고 모바일에서도 사용할 수 있도록 했다. 에즈라는 로컬 네이티브 버전도 만들어 보았다고 덧붙인다.
촬영 당시 그가 주로 사용하는 환경은 Codex였다. 특히 브라우저 조작 기능을 높이 평가한다. 고정 좌석이 없는 사무실에서 다음 날 좌석을 예약하도록 예약 실행을 설정한 사례는, 매번 기억하고 처리해야 하는 작은 업무를 맡기는 예다.
FigJam의 테스트 절차를 따라 제품을 점검하다
제품 업무에 적용한 사례는 버그 배시다. 팀은 FigJam에 테스트 계정, 이동 경로, 수행할 행동, 확인할 사항을 정리해 둔다. 에즈라는 자신과 AI가 사용할 계정을 각각 확보하고, AI에게 브라우저에서 시나리오를 수행하게 한다.
소개한 대상은 Figma 내부의 요청 모달을 더 명확하고 간결하게 만드는 작업이었다. 에즈라는 문구와 흐름 뒤에 복잡한 조건과 로직이 있다고 설명한다. AI는 정해진 절차를 따라 점검하고, 작업을 마치면 수행 내역을 FigJam 보드에 기록했다.
에즈라는 입력란에 많은 이모지를 넣었을 때 발생하는 문제와, 팀 이름에 따라 좌석 요청 문구의 영어 관사가 어색해지는 문제를 발견 사례로 든다. 자신이 놓쳤을 세부 사항을 AI의 꾸준한 점검이 찾아냈다고 평가한다.
한편 FigJam에 남기는 댓글이 지나치게 번거로워지지 않도록 계속 조정하고 있다고 말한다. 문제를 발견하는 능력과 함께, 결과를 동료에게 전달하는 방식도 다듬고 있었다.
Auto XP: 실험과 다음 실험을 연결하다
실험하지 못했던 영역에 주목하다
성장 PM인 에즈라는 실험에 배정하지 않고 흘려보내는 트래픽을 큰 낭비로 본다고 말한다. Auto XP는 이 문제의식에서 출발했다.
그가 주목한 대상은 사람이 원래 시간을 들이지 않았을 제품 영역이었다. 모델이 엔지니어링, 데이터 분석, UX 문구 작성의 일부를 처리하고 제한된 범위에서 아이디어를 낼 수 있게 되면서, 작은 성장 PM처럼 계속 실험하는 시스템을 구상했다.
에즈라는 한 엔지니어가 Auto XP를 운영하고 있으며 여러 실험이 진행 중이라고 설명한다. 첫 실험에서는 큰 성과를 얻었다고도 말한다.
Slack 스레드로 역할을 연결하다
Auto XP는 Slack의 활동을 계기로 실행되는 세 개의 Cursor 자동화로 구성된다. 전용 채널에서 사람이 실험을 제안하거나 반복 실행하도록 둘 수 있다. 설정 페이지에서 시도할 실험을 찾아보라고 요청하는 식이다.
데이터 과학자 에이전트는 이탈과 퍼널, 사용자 구성 변화 등을 살펴본다. UX 라이팅 에이전트는 문구 아이디어를 제안하고, 엔지니어 역할의 에이전트는 PR을 통한 구현을 맡는다. 에즈라는 문구 변경에서 프런트엔드 디자인으로도 범위를 넓혀가는 중이라고 설명한다.
각 단계는 같은 Slack 스레드에 진행 상황을 남긴다. 담당자는 하나의 실험이 어떤 분석과 가설을 거쳐 구현되는지 같은 대화 흐름에서 확인할 수 있다.
출시 전 통합 검토와 후속 실험
Auto XP가 목표로 하는 사람의 개입 지점은 출시 직전의 통합 검토다. 데이터 분석 결과, 가설, UX 문구, 코드를 함께 확인한 다음 실험을 시작한다. 단계마다 검토와 인계를 반복하는 부담을 줄이려는 설계다.
실험이 끝나면 웹훅이 결과 분석을 다시 촉발한다. 시스템에는 에즈라가 성장 PM으로 일하며 쌓은 판단 지침이 들어 있다. 결과를 평가하고, 더 탐색할지 또는 발견한 성과를 더 활용할지 판단해 다음 실험을 준비하도록 한다.
그가 구상한 흐름에서는 사람이 결과를 확인할 때 이미 다음 반복 작업이 시작되어 있다. 다만 에즈라는 실제 구현이 아직 그 이상에 완전히 도달하지는 않았다고 설명한다. Auto XP는 기회 발견과 구현, 종료 후 분석을 연결해 PM이 매번 후속 작업을 시작시켜야 하는 부담을 줄이려는 시도다.
글을 쓰는 순간 근거를 찾는 도구
짧은 판단을 글쓰기 흐름 안에 넣다
마지막 주요 시연은 실시간 글쓰기 보조 프로토타입이다. 에즈라는 텍스트 질문에 점수, 참·거짓, 선택지처럼 제한된 형태의 답을 빠르고 저렴하게 반환하는 모델을 활용했다고 설명한다.
그가 주목한 것은 작업 중간에 짧은 판단을 자주 실행하는 방식이다. 작성자가 잠깐 타이핑을 멈출 때마다 비어 있는 부분이나 근거가 필요한 주장이 있는지 확인하도록 했다.
도구는 TK나 괄호처럼 나중에 채우려고 남긴 표시를 찾는다. 근거를 보충해야 할 표현을 감지하면 연결된 자료 라이브러리에서 관련 내용을 검색한다.
에즈라가 해결하려 한 문제는 글을 쓰다가 숫자나 인용문을 찾으러 가면 원래 쓰려던 문장을 잊어버리는 상황이다. 작성자가 생각을 이어가는 동안 도구가 옆에서 자료를 찾도록 하는 것이다.
자료가 뒷받침하는 내용만 제안하다
시연에서는 무엇을 “생각했다”는 문장을 미완성으로 남겼을 때, 라이브러리에 그 생각에 관한 정보가 없어 내용을 채울 수 없다는 반응을 설명한다. 반면 인터뷰한 작가들이 무엇을 말했다는 문장을 쓰면 관련 인터뷰 인용문을 가져온다.
31:10 - 라이브러리에 근거가 없는 미완성 문장에 대한 도구의 반응
작성자가 아직 밝히지 않은 생각과 이미 수집한 인터뷰 자료를 구분해 다루는 방식이다. 도구는 연결된 자료에서 뒷받침할 수 있는 내용을 찾도록 설계됐다.
시연 중에는 내부 방화벽 뒤로 옮긴 API의 접근 여부를 확인하는 등 실행이 매끄럽지 않은 순간도 있었다. 에즈라는 글쓰기와 근거 검색을 결합한 프로토타입을 보여주며, 같은 방식을 면접에도 적용할 수 있을지 생각을 확장한다. 지원자의 경력을 미리 제공하고 대화를 음성으로 받아 적으면서 관련 경험을 검색하는 보조 도구에 대한 구상이다.
개인 에이전트와 실패를 다루는 태도
후반부에는 개인 에이전트 경험이 이어진다. 에즈라는 별도의 웹사이트나 앱을 찾아가지 않고 iMessage로 요청할 수 있는 경험을 좋게 평가한다. 자전거를 타다가 발견한 도로의 움푹 팬 곳을 음성 메시지로 전달하고, 에이전트가 신고를 처리하게 하는 사례를 든다. 주소를 기억했다가 나중에 웹사이트에 입력하는 과정을 줄이는 용도다.
다만 처음 강한 인상을 받은 도구라도 계속 같은 빈도로 사용하는 것은 아니라고 말한다. 여전히 메시지를 받지만 답하지 않는 경우도 있다고 덧붙인다.
대화는 AI가 원하는 결과를 주지 않을 때의 반응으로 마무리된다. 에즈라는 AI에 의식이 있다고 생각해서 친절하게 대하는 것은 아니라고 말한다. 계속 무언가에 화를 내는 행동이 자신에게 좋지 않다고 느끼기 때문이다.
결과가 나쁘면 자신의 지시와 누적된 대화 맥락도 돌아본다고 한다. 로컬·원격 세션을 전환하면서 반복 승인을 요구받았던 경험에서는, 같은 대화에서 권한이 있다고 거듭 말해도 문제가 해결되지 않았다. 그는 대화가 풀리지 않는 반복에 빠졌을 때 새 대화에서 다시 시작하는 편이 낫다는 교훈을 얻었다고 설명한다.
핵심 정리
PM OS는 조직의 맥락을 기억하고 업무 누락을 줄이는 데서 출발했다. 누가 검토해야 하는지, 누구에게 답해야 하는지, 어떤 결정이 남았는지를 찾는 기능이 문서 작성과 더 복잡한 작업의 기반이 됐다.
공유한 스킬도 계속 손질했다. 실제 사용 피드백을 받아 줄이거나 삭제했고, 모델이 발전하면서 불필요해진 지침을 제거하려 했다. 브라우저 점검에서는 문제 발견뿐 아니라 결과를 기록하고 전달하는 방식까지 조정했다.
Auto XP는 실험의 분석·구현·후속 반복을 연결하고, 글쓰기 도구는 작성 중 필요한 근거를 찾아준다. 에즈라가 보여준 활용 방식은 사람이 맥락을 다시 설명하고 다음 작업을 시작시키는 부담을 줄이는 방향으로 이어진다.