본문으로 건너뛰기
피드

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

ai-ml 약 6분
vote
0
댓글
북마크

글쓴이는 개인 에이전트, 클로드 코드, 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 논문 2편이 구두 발표로 통과됐다

두 연구자가 NeurIPS, WACV, TerraBytes 리뷰 경험을 바탕으로 LLM이 만든 저품질 논문과 환각 인용 문제가 학회 리뷰를 망가뜨리고 있다고 비판한 Q&A 글이다. 리뷰한 22편 중 다수에서 가짜 저자나 조작된 참고문헌이 나왔고, 심지어 신고한 논문 2편이 단순 수정 조건으로 구두 발표에 통과됐다고 한다.

ai-ml

AI 문서 냄새를 항공 매뉴얼식 영어로 잡아주는 에이전트 스킬

ASD-STE100 Simplified Technical English 규칙을 에이전트 스킬로 묶어, LLM이 쓰는 기술 문서를 짧고 오해 적게 만들려는 GitHub 프로젝트다. Claude 6개 모델, 8개 작업, 96회 실행 기준으로 STE 위반이 100단어당 72.9% 줄었고 출력 토큰도 모든 모델에서 감소했다.

ai-ml

딥시크 V4 플래시 0731, 100만 토큰 컨텍스트에 가격까지 꽤 공격적임

딥시크 V4 플래시 0731이 인공분석 지능 지수에서 50점을 기록하며 비슷한 크기의 공개 가중치 모델 중앙값 25점을 크게 웃돌았음. 입력 100만 토큰당 0.14달러, 출력 100만 토큰당 0.28달러라 가격도 공격적이고, 100만 토큰 컨텍스트와 2840억 전체 파라미터, 130억 활성 파라미터 구조가 핵심임.

ai-ml

딥시크 V4 플래시 공개 베타, 에이전트 성능을 대놓고 밀고 있다

DeepSeek가 DeepSeek-V4-Flash API를 공개 베타로 올리고, 모델명만 deepseek-v4-flash로 바꾸면 쓸 수 있게 했다. 이번 업데이트는 에이전트 성능 개선이 핵심이며 Terminal Bench 2.1 82.7, DeepSWE 54.4, DSBench-FullStack 68.7 같은 수치를 내세운다. Responses API 형식과 Codex 적응도 명시되어 있어 코딩 에이전트 쪽에서 바로 비교 대상이 될 만하다.

ai-ml

AI 세션, 이제 진짜 내 데이터가 아닐 수도 있다

추론 API가 단순한 입력-출력 기록에서 벗어나, 제공자 서버에 묶인 상태값과 암호화된 블롭에 의존하는 방향으로 가고 있다는 비판이다. reasoning token, 호스팅 검색, 서버 측 압축, 멀티 에이전트 메시지, 응답 아이디 같은 기능이 편리함을 주는 대신 세션 이식성과 감사 가능성을 깎아먹는다는 게 핵심이다. 글은 로컬 이벤트 로그를 표준으로 삼고, 검색·압축·에이전트 통신을 사람이 읽고 내보낼 수 있어야 한다고 주장한다.