본문으로 건너뛰기
피드

AI를 욕하면서도 진짜 많이 쓰는 PM의 현실적인 사용기

ai-ml 약 6분

글쓴이는 개인 에이전트, 클로드 코드, MCP, KPI 대시보드 등을 실제 업무에 붙이면서 ‘AI가 다 해준다’보다 ‘시작하고 반복하는 사이클이 생겼다’는 변화를 강조한다. 특히 10년 묵은 정책서 정리, 팀 대시보드 구축, 글쓰기 루틴처럼 미뤄온 일을 실제 구조로 바꾼 사례가 핵심이다.

  • 1

    AI 도입 효과는 딸깍 자동화보다 시작 장벽을 낮추고 반복 사이클을 만드는 데 있음

  • 2

    정책서와 KPI 대시보드처럼 오래 밀린 운영 업무를 Git, 대시보드, MCP 기반 구조로 옮김

  • 3

    개인 생산성 향상과 팀 전체 생산성 향상은 다른 문제이며, 조직 맥락과 문서화 수준이 병목이 됨

  • 4

    PM 관점에서는 결과물 생성보다 팀이 공감하는 변화 관리가 더 큰 숙제로 남음

  • 글쓴이는 AI 비판도 많이 했지만, 정작 본인도 AI를 꽤 깊게 쓰고 있다고 털어놓음

    • 포인트는 ‘AI 좋다/나쁘다’ 논쟁이 아니라, 실제로 어디에 붙였을 때 일이 굴러가기 시작했느냐임
    • 개인용으로는 오픈클로 에이전트 3개를 운영하고, 회사에서는 UX 라이팅, 카드뉴스, 정책서 관리, KPI 대시보드, MCP 같은 업무에 붙여 쓰는 중임
  • 개인 쪽 사용 방식은 꽤 분업화돼 있음

    • 메인 에이전트는 개인 업무 전반을 처리하고, 글작성 에이전트는 콘텐츠를 같이 만들고, 개발 에이전트는 PM 관련 스킬·학습·개인 개발 프로젝트를 다룸
    • 집에서 놀던 데스크탑을 밀고 우분투를 설치한 뒤 텔레그램까지 연결했다는 디테일이 있음. 그냥 웹 챗봇 켜놓고 쓰는 수준은 아닌 셈임
  • 회사에서는 더 실무적인 문제에 AI를 붙였음

    • 서비스 톤앤매너를 정리하는 UX 라이팅 프로젝트에서 워딩 검토, 번역, 적용을 진행함
    • 마케팅 카드뉴스 제작에도 협업 형태로 쓰고, 클로드 코드로 Git 기반 정책서 관리와 KPI 대시보드, MCP 운영까지 건드림
  • 제일 큰 변화는 ‘오래 미뤄둔 일’에 손을 댔다는 점임

    • 대표 사례가 정책서임. 10년 동안 팀마다 따로 들고 다니던 문서, 최신인지 아무도 확신 못 해서 결국 사람에게 물어보던 문서들을 서비스 구조 기준으로 다시 잡음
    • 말로만 ‘언젠가 정리해야지’ 하던 것을 Git으로 관리하는 구조로 바꿨고, 지속적으로 업데이트할 수 있는 기반을 만든 게 핵심임
  • KPI 대시보드도 비슷한 맥락임

    • 외부 데이터로는 GA, Clarity 같은 메트릭을 보고, 내부 데이터로는 가입자와 주요 행동지표를 같이 봐야 했음
    • 데이터만 전담하는 인력이 없는 상황에서는 이 조합 자체가 손이 많이 가는 일이었는데, 엔지니어링 팀의 지원을 받아 정보 유출 없이 볼 수 있는 대시보드와 MCP를 만들었다고 함
    • 결과적으로 지금은 팀 전체가 같은 대시보드 화면을 보면서 일하는 상태까지 감

💡

> 여기서 배울 만한 건 ‘AI를 도입했다’가 아니라 ‘AI가 접근할 수 있는 문서와 지표 구조를 만들었다’는 쪽임. 팀 생산성은 프롬프트보다 업무 재료 정리에서 먼저 갈리는 경우가 많음.

  • 글쓰기 방식도 바뀌었음

    • AI에게 다 써달라는 식이 아니라, 머릿속에 흩어진 생각을 꺼내놓고 방향을 같이 잡는 방식으로 쓴다고 설명함
    • 그래서 생각이 글의 형태로 정제되는 속도가 빨라지고, 혼자 쓸 때 막히던 지점이 줄었다는 게 체감 변화임
  • 글쓴이가 말하는 생산성 변화는 ‘빨라졌다’보다 ‘사이클이 생겼다’에 가까움

    • 만들고, 나온 걸 보고, 어디서 틀렸는지 확인하고, 다음에는 덜 막히는 식으로 반복됨
    • 처음엔 수정 시간이 꽤 들었지만, 반복하면서 그 시간이 줄어드는 느낌을 받았다고 함. 딸깍 자동화가 아니라 피드백 루프가 쌓이는 그림임
  • 다만 개인이나 작은 팀의 성공이 곧 조직 전체의 변화는 아님

    • AI를 넣었다고 팀 전체가 갑자기 빨라지는 건 완전히 다른 문제라고 선을 그음
    • 특히 히스토리가 깊은 회사일수록 문서화되지 않은 맥락, 사람끼리 암묵적으로 아는 정보가 많아서 AI가 바로 먹기 어려움
  • PM 입장에서 남은 숙제는 더 분명함

    • 제품만 나오면 끝나는 게 아니라, 이 변화를 팀 전체의 개선으로 어떻게 연결할지 고민해야 함
    • 결국 AI 활용은 도구 문제가 아니라 팀이 공감할 수 있는 업무 방식 변화로 이어져야 한다는 얘기임

기술 맥락

  • 이 글에서 중요한 선택은 AI를 ‘답변 생성기’가 아니라 업무 시스템 주변에 붙였다는 점이에요. 정책서, KPI 대시보드, MCP처럼 팀이 계속 쓰는 구조에 연결해야 반복 가능한 생산성이 나오거든요.

  • 정책서를 Git으로 관리한 것도 그냥 개발자 흉내가 아니에요. 오래된 문서의 가장 큰 문제는 최신 여부를 모른다는 건데, Git을 쓰면 변경 이력과 리뷰 흐름을 만들 수 있어서 문서가 다시 업무 자산이 돼요.

  • KPI 대시보드와 MCP를 같이 만든 맥락도 비슷해요. AI가 데이터를 잘 읽으려면 먼저 데이터가 안전하게 모이고, 팀이 같은 기준으로 볼 수 있어야 해요. 그래서 정보 유출 없이 접근 가능한 대시보드가 먼저 필요했던 거예요.

  • 조직 전체로 확산이 어려운 이유는 기술보다 문맥 때문이에요. AI는 문서화된 정보에는 강하지만, 사람들 머릿속에만 있는 히스토리와 암묵지는 바로 읽지 못하거든요. 그래서 PM 입장에서는 도구 도입보다 업무 맥락을 구조화하는 일이 더 큰 숙제가 돼요.

이 글의 좋은 점은 AI를 ‘마법’이나 ‘사기’로 몰지 않고, 진짜 업무에 붙였을 때 어디서 효용이 생기고 어디서 막히는지 보여준다는 데 있다. 개발자에게도 꽤 현실적인 포인트는, AI 도구보다 중요한 게 결국 문서 구조, 데이터 접근, 피드백 루프라는 점이다.

댓글

댓글

댓글을 불러오는 중...

ai-ml

알파고 핵심 연구자의 새 AI 회사, 제품 없이 1.6조 원 시드 투자 유치

알파고와 알파제로를 설계한 데이비드 실버의 새 AI 스타트업이 매출과 제품 없이 11억 달러 시드 투자를 받았다. 기사에는 홈서비스 전화를 받는 AI 에이전트 스타트업 아보카, AI 데이터센터 전력 수요로 주목받은 소형모듈원전 기업 X-에너지 사례도 함께 담겼다.

ai-ml

아카데미상, AI 배우와 AI 작가의 수상 자격을 못 박아 배제

미국 아카데미가 AI로 만든 출연자나 챗봇이 쓴 시나리오는 오스카 수상 후보가 될 수 없다는 규정을 명문화했다. 다만 영화 제작 과정에서 생성 AI나 디지털 도구를 쓰는 것 자체는 금지하지 않고, 인간의 창작 기여도를 따져보겠다는 쪽으로 선을 그었다.

ai-ml

AI가 설계한 ‘7일 전쟁’은 왜 64일짜리 수렁이 됐나

미국과 이스라엘의 이란 작전은 AI 기반 표적 선정과 빠른 살상연쇄를 앞세웠지만, 전쟁은 64일째 끝나지 않고 있다. 메이븐의 표적 분류 정확도 60%, 여학교 공습 사망자 168명, 브렌트유 126달러 같은 숫자가 AI 전쟁의 한계를 꽤 적나라하게 보여준다.

ai-ml

카카오 플레이MCP, 로컬 AI 에이전트 오픈클로와 연결된다

카카오가 개방형 플랫폼 플레이MCP에서 오픈소스 AI 에이전트 오픈클로 연동을 지원한다. 개발자는 카카오톡 나와의 채팅방, 톡캘린더, 카카오맵, 선물하기 같은 카카오 도구와 200여 개 외부 MCP 서버를 로컬 AI 에이전트에서 직접 붙여 쓸 수 있게 됐다.

ai-ml

카카오 PlayMCP, 오픈소스 AI 에이전트 오픈클로까지 연결

카카오가 MCP 기반 플랫폼 PlayMCP를 오픈소스 AI 에이전트 오픈클로와 연동했다. 개발자가 PlayMCP에 담아둔 200여 개 MCP 서버를 클로드, 챗지피티뿐 아니라 로컬 에이전트에서도 쓸 수 있게 된 게 핵심이다.