--- title: "AI를 욕하면서도 진짜 많이 쓰는 PM의 현실적인 사용기" published: 2026-05-01T19:05:02.034Z canonical: https://jeff.news/article/2029 --- # AI를 욕하면서도 진짜 많이 쓰는 PM의 현실적인 사용기 글쓴이는 개인 에이전트, 클로드 코드, MCP, KPI 대시보드 등을 실제 업무에 붙이면서 ‘AI가 다 해준다’보다 ‘시작하고 반복하는 사이클이 생겼다’는 변화를 강조한다. 특히 10년 묵은 정책서 정리, 팀 대시보드 구축, 글쓰기 루틴처럼 미뤄온 일을 실제 구조로 바꾼 사례가 핵심이다. - 글쓴이는 AI 비판도 많이 했지만, 정작 본인도 AI를 꽤 깊게 쓰고 있다고 털어놓음 - 포인트는 ‘AI 좋다/나쁘다’ 논쟁이 아니라, 실제로 어디에 붙였을 때 일이 굴러가기 시작했느냐임 - 개인용으로는 오픈클로 에이전트 3개를 운영하고, 회사에서는 UX 라이팅, 카드뉴스, 정책서 관리, KPI 대시보드, MCP 같은 업무에 붙여 쓰는 중임 - 개인 쪽 사용 방식은 꽤 분업화돼 있음 - 메인 에이전트는 개인 업무 전반을 처리하고, 글작성 에이전트는 콘텐츠를 같이 만들고, 개발 에이전트는 PM 관련 스킬·학습·개인 개발 프로젝트를 다룸 - 집에서 놀던 데스크탑을 밀고 우분투를 설치한 뒤 텔레그램까지 연결했다는 디테일이 있음. 그냥 웹 챗봇 켜놓고 쓰는 수준은 아닌 셈임 - 회사에서는 더 실무적인 문제에 AI를 붙였음 - 서비스 톤앤매너를 정리하는 UX 라이팅 프로젝트에서 워딩 검토, 번역, 적용을 진행함 - 마케팅 카드뉴스 제작에도 협업 형태로 쓰고, 클로드 코드로 Git 기반 정책서 관리와 KPI 대시보드, MCP 운영까지 건드림 - 제일 큰 변화는 ‘오래 미뤄둔 일’에 손을 댔다는 점임 - 대표 사례가 정책서임. 10년 동안 팀마다 따로 들고 다니던 문서, 최신인지 아무도 확신 못 해서 결국 사람에게 물어보던 문서들을 서비스 구조 기준으로 다시 잡음 - 말로만 ‘언젠가 정리해야지’ 하던 것을 Git으로 관리하는 구조로 바꿨고, 지속적으로 업데이트할 수 있는 기반을 만든 게 핵심임 - KPI 대시보드도 비슷한 맥락임 - 외부 데이터로는 GA, Clarity 같은 메트릭을 보고, 내부 데이터로는 가입자와 주요 행동지표를 같이 봐야 했음 - 데이터만 전담하는 인력이 없는 상황에서는 이 조합 자체가 손이 많이 가는 일이었는데, 엔지니어링 팀의 지원을 받아 정보 유출 없이 볼 수 있는 대시보드와 MCP를 만들었다고 함 - 결과적으로 지금은 팀 전체가 같은 대시보드 화면을 보면서 일하는 상태까지 감 > [!TIP] > 여기서 배울 만한 건 ‘AI를 도입했다’가 아니라 ‘AI가 접근할 수 있는 문서와 지표 구조를 만들었다’는 쪽임. 팀 생산성은 프롬프트보다 업무 재료 정리에서 먼저 갈리는 경우가 많음. - 글쓰기 방식도 바뀌었음 - AI에게 다 써달라는 식이 아니라, 머릿속에 흩어진 생각을 꺼내놓고 방향을 같이 잡는 방식으로 쓴다고 설명함 - 그래서 생각이 글의 형태로 정제되는 속도가 빨라지고, 혼자 쓸 때 막히던 지점이 줄었다는 게 체감 변화임 - 글쓴이가 말하는 생산성 변화는 ‘빨라졌다’보다 ‘사이클이 생겼다’에 가까움 - 만들고, 나온 걸 보고, 어디서 틀렸는지 확인하고, 다음에는 덜 막히는 식으로 반복됨 - 처음엔 수정 시간이 꽤 들었지만, 반복하면서 그 시간이 줄어드는 느낌을 받았다고 함. 딸깍 자동화가 아니라 피드백 루프가 쌓이는 그림임 - 다만 개인이나 작은 팀의 성공이 곧 조직 전체의 변화는 아님 - AI를 넣었다고 팀 전체가 갑자기 빨라지는 건 완전히 다른 문제라고 선을 그음 - 특히 히스토리가 깊은 회사일수록 문서화되지 않은 맥락, 사람끼리 암묵적으로 아는 정보가 많아서 AI가 바로 먹기 어려움 - PM 입장에서 남은 숙제는 더 분명함 - 제품만 나오면 끝나는 게 아니라, 이 변화를 팀 전체의 개선으로 어떻게 연결할지 고민해야 함 - 결국 AI 활용은 도구 문제가 아니라 팀이 공감할 수 있는 업무 방식 변화로 이어져야 한다는 얘기임 --- ## 기술 맥락 - 이 글에서 중요한 선택은 AI를 ‘답변 생성기’가 아니라 업무 시스템 주변에 붙였다는 점이에요. 정책서, KPI 대시보드, MCP처럼 팀이 계속 쓰는 구조에 연결해야 반복 가능한 생산성이 나오거든요. - 정책서를 Git으로 관리한 것도 그냥 개발자 흉내가 아니에요. 오래된 문서의 가장 큰 문제는 최신 여부를 모른다는 건데, Git을 쓰면 변경 이력과 리뷰 흐름을 만들 수 있어서 문서가 다시 업무 자산이 돼요. - KPI 대시보드와 MCP를 같이 만든 맥락도 비슷해요. AI가 데이터를 잘 읽으려면 먼저 데이터가 안전하게 모이고, 팀이 같은 기준으로 볼 수 있어야 해요. 그래서 정보 유출 없이 접근 가능한 대시보드가 먼저 필요했던 거예요. - 조직 전체로 확산이 어려운 이유는 기술보다 문맥 때문이에요. AI는 문서화된 정보에는 강하지만, 사람들 머릿속에만 있는 히스토리와 암묵지는 바로 읽지 못하거든요. 그래서 PM 입장에서는 도구 도입보다 업무 맥락을 구조화하는 일이 더 큰 숙제가 돼요. ## 핵심 포인트 - AI 도입 효과는 딸깍 자동화보다 시작 장벽을 낮추고 반복 사이클을 만드는 데 있음 - 정책서와 KPI 대시보드처럼 오래 밀린 운영 업무를 Git, 대시보드, MCP 기반 구조로 옮김 - 개인 생산성 향상과 팀 전체 생산성 향상은 다른 문제이며, 조직 맥락과 문서화 수준이 병목이 됨 - PM 관점에서는 결과물 생성보다 팀이 공감하는 변화 관리가 더 큰 숙제로 남음 ## 인사이트 이 글의 좋은 점은 AI를 ‘마법’이나 ‘사기’로 몰지 않고, 진짜 업무에 붙였을 때 어디서 효용이 생기고 어디서 막히는지 보여준다는 데 있다. 개발자에게도 꽤 현실적인 포인트는, AI 도구보다 중요한 게 결국 문서 구조, 데이터 접근, 피드백 루프라는 점이다.