[작성자:] hoonyoung

Minimalism

AI 시대, PM(Product Manager)의 업무 변화

부제: 생성형 AI가 PM 역할을 어떻게 다시 설계하는가

 

서론

2025년, 생성형 AI는 더 이상 PM 업무를 ‘지원하는 도구’가 아니라 업무 구조 자체를 재설계하는 요인이 되었습니다.
아이디어 발굴, 시장 조사, 사양 초안 작성처럼 시간이 가장 많이 들던 반복 작업들은 AI가 빠르게 처리합니다.
반대로 PM은 전략적 판단, 조율, 제품 방향성 같은 비정형적 결정의 밀도를 높여야 하는 역할로 이동하고 있습니다.

이 글은 Perplexity → Notebook LM → ChatGPT 워크플로우로 분석된
① 역할 변화, ② 필요한 역량, ③ 전략적 시사점을 실무 관점에서 재구성한 것입니다.

정리하면, AI 시대 PM의 핵심 경쟁력은 세 가지로 수렴됩니다.
① AI를 활용한 빠른 실행 속도,
② 조직·기술·요구사항을 연결하는 정교한 조율,
③ 제품을 실제로 ‘동작’하게 만드는 의사결정 역량입니다.

본론

1. PM 역할 변화 — 반복 업무에서 전략적 리더십으로

AI는 시장 분석, 피처 초안, 사용자 시나리오 작성 등 기존의 ‘PM 노동시간’을 잠식하고 있습니다.
결과적으로 PM은 문서를 만드는 사람이 아니라 제품 방향과 의사결정을 설계하는 사람이 되고 있습니다.

특히 다음 네 가지 변화가 뚜렷합니다.

  1. 초안 생산 자동화 → 방향성 검증 중심의 일로 이동
  2. PDLC(Product Development Life Cycle) 단계의 경계가 희미해지고, 엔드투엔드 책임 증가
  3. 내부·외부 Stakeholder를 잇는 조율자의 비중 증가
  4. Time-to-Market 단축 → 빠른 판단이 곧 경쟁력

그리고 이 전환은 실무에서도 체감됩니다.

👉저도 예전에는 초안의 구조부터 문장까지 모두 직접 작성해 나가는 방식이었지만, 최근에는 기본 골격만 빠르게 만들고 AI 피드백을 반영해 방향성과 논리를 조율하는 방식으로 바뀌었습니다. 문서의 완성도보다 ‘맥락(Context)의 빠른 검증’이 더 중요해졌습니다.

AI가 많은 작업을 대신하면서, PM의 실제 가치는
“무엇을 더 빨리 판단하고 더 정확하게 방향을 잡느냐”에 집중되고 있습니다.

2. AI 시대 PM에게 필요한 핵심 역량 — 무엇이 PM을 구분 짓는가

Notebook LM 요약을 기반으로, AI 시대 PM에게 요구되는 핵심 역량은 다음 5가지입니다.

① AI Literacy + 머신러닝 기본기

  • 신경망·NLP·벡터 검색·Transformer 원리
  • 모델 수명주기(MLOps) 이해
  • 데이터 기반 의사결정 역량

👉 이 부분은 저도 그동안 엔지니어 도메인이라고 생각해 깊게 보지 않았지만, 실제 AI 챗봇 프로젝트를 해보니 PM의 판단 정확도를 위해 반드시 필요한 영역이라는 걸 체감했고, 지금도 지속적으로 학습하고 있습니다.

② 프롬프트 엔지니어링 & 고속 프로토타이핑

  • 구조화된 요청 → 즉시 와이어프레임/문서 초안 생성
  • LLM을 활용한 기능 정의 실험
  • Low-code/No-code를 통한 빠른 MVP 검증

👉 몇 번의 구조화된 프롬프트만으로도 바이브코딩 형태의 프로토타이핑이 가능해지면서, 빠른 버전으로 방향성을 검증하는 시간이 크게 단축되었습니다. 초기 가시성이 논의 속도를 높이는 데 큰 도움이 되었습니다.

③ 윤리·규제·AI 거버넌스 이해

특히 금융/모빌리티/헬스케어 등 한국 규제 산업에선 필수.

  • 편향 방지
  • 개인정보 처리
  • AI Basic Act 대응

④ 전략적 비전 & 제품 직관 강화

  • 반복 업무 자동화 → 상위 레벨 판단 비중 확대
  • 증거 기반 의사결정(Evidence-based Decision)

⑤ 교차 기능 협업(Orchestration)

  • AI 엔지니어, 데이터 과학자, BE/FE, 디자인
  • 조직 간 의사결정 구조 설계

👉 최근 진행한 AI 챗봇 프로젝트에서도 기능 정의보다 ‘R&R 기반의 빠른 결정’이 훨씬 중요한 순간이 많았습니다. 결국 PM은 기술 자체보다 의사결정 구조를 설계하고 조율하는 역할이 핵심이었습니다.

3. 전략적 시사점 — 앞으로 PM이 가져가야 하는 관점

Notebook LM의 인사이트를 실무 기준으로 재구성하면 다음 다섯 가지가 가장 중요합니다.

① PM은 실행자에서 전략적 설계자로 이동한다.

PM이 직접 문서·사양을 만드는 비중은 줄고,
방향·비전·고객 문제 정의 같은 상위 레이어의 중요도가 극대화된다.

② PDLC 자체가 재정의되고 있다.

AI 기반 시나리오 생성과 프로토타이핑으로
시장 출시 속도(Time-to-Market)가 제품 경쟁력의 핵심이 된다.

③ PM은 기술보다 조직을 조율하는 역할이 커진다.

AI 기능 통합, 데이터, 백엔드, UX, 운영팀을 연결하는
오케스트레이터 역할이 필수 역량으로 자리잡는다.

④ 윤리·규제 고려는 선택이 아니라 기본값이다.

특히 한국은 규제 변화 속도가 빠르기 때문에
PM이 규제·윤리를 고려한 IA/UX를 설계할 수 있어야 한다.

⑤ 엔드투엔드 책임이 더 넓어진다.

AI는 기능 간 경계를 흐리고,
PM에게 더 넓은 지식과 의사결정 책임을 요구한다.

결론

AI는 PM을 대체하지 않습니다.
다만 PM이 어떤 방식으로 사고하고 결정해야 하는지를 근본적으로 다시 설계하고 있습니다.

그리고 이러한 변화 속에서,
AI 시대 PM의 핵심 경쟁력은 결국 세 가지로 명확하게 정리됩니다.
① AI를 활용한 실행 속도,
② 여러 조직을 연결하며 방향을 잡는 조율 능력,
③ 제품을 실제로 ‘움직이게’ 만드는 의사결정 역량.

이 세 가지는 단순한 “능력의 목록”이 아니라,
AI 환경에서 PM이 스스로를 증폭시키는 핵심 레버리지입니다.

이 변화는 이미 한국 IT 조직 곳곳에서 시작되었고,
Smart PM, AI-native PM, AI Orchestrator 같은 역할들이
곧 표준적인 PM 역할로 자리 잡게 될 것입니다.

삼성·네이버·현대차의 LLM 전략 비교

 

— 생성형 AI 시대, 세 기업은 어디로 가고 있을까

서론

2025년 현재, 생성형 AI는 더 이상 기술 부서의 실험이 아니라 기업 전략의 핵심 축이 되었습니다.
특히 국내 각 분야의 대표 기업인 삼성전자·네이버·현대자동차그룹은 각자의 산업 영역과 강점을 바탕으로 서로 다른 LLM 전략을 펼치고 있죠.

이번 글은 실제 AI 리서치 워크플로우(Perplexity → Notebook LM → ChatGPT) 를 통해 세 기업의 접근법을 조사하고 정리한 결과입니다.
요즘 저도 기업별 LLM 활용 구조를 유심히 보고 있는데, 같은 ‘AI 전략’이라도 산업별로 이렇게 다르다는 게 꽤 흥미롭더군요.
정보의 최신성(Perplexity) + 정밀한 요약(Notebook LM) + 스토리텔링(ChatGPT)을 결합해, AI PM 시점에서 본 전략적 차이와 시사점을 정리했습니다.
국내 대표 기업들이 생성형 AI를 어떻게 바라보는지 궁금했고, 앞으로 각 기업의 전략과 방향성도 함께 확인해보고자 합니다.

본론

🧠 삼성전자 — “온디바이스 AI로 내부 효율 최적화”

삼성의 Gauss AI 전략은 내부 생산성 혁신과 온디바이스 통합에 초점이 맞춰져 있습니다.

  • 핵심 방향: 문서 요약·메일 작성·번역 등 반복 업무 자동화 및 사내 의사결정 지원.
  • 기술 구조: 자체 파운데이션 모델 ‘Gauss 2’ 개발 → 스마트폰, 가전, TV 등 모든 제품에 탑재.
  • 보안 전략: 외부 모델(GPT 등) 사용을 제한하고 내부 모델 로컬 운용으로 보안 강화.

요약 인사이트:
삼성은 AI를 ‘클라우드 기능’이 아닌 ‘제품 기능’으로 내재화한다.
하드웨어 중심 기업으로서 AI를 제품 경쟁력의 핵심 요소로 삼는 전략이다.
결국 AI를 ‘제품 속에서 작동하게 만드는’ 데 초점을 맞춘 점이 가장 인상적이다.

🌐 네이버 — “초거대 모델 기반 서비스 플랫폼 확장”

네이버는 LLM을 플랫폼 전체의 엔진으로 활용합니다.

  • 핵심 방향: 검색·쇼핑·콘텐츠 등 모든 서비스에 ‘HyperCLOVA X’ 적용.
  • 기술 전략: 초거대 자체 모델 기반 + 오픈소스화(SEED) → 개발자 생태계 확장.
  • 비즈니스 확장: 클라우드 기반 B2B 챗봇·AI 솔루션 사업 확대.

요약 인사이트:
네이버는 AI를 ‘하나의 서비스’가 아닌 ‘플랫폼 전반의 연결 조직’으로 활용한다.
자사 생태계를 넓히는 국산 파운데이션 모델 플랫폼 전략이며,
결국 모델을 비즈니스 인프라로 전환하는 방향을 가장 명확하게 보여준다.

🚘 현대자동차그룹 — “모빌리티 전환을 이끄는 하이브리드 AI”

현대차는 LLM을 SDV(소프트웨어 기반 차) 전략의 핵심으로 위치시켰습니다.

  • 핵심 방향: 차량 내 인포테인먼트·디지털 어시스턴트 등 모빌리티 AI 기능 강화.
  • 기술 전략: 자체 모델 ‘글레오’ + 네이버 ‘HyperCLOVA X’ 협업 → 하이브리드 접근.
  • 인프라 기반: 엔비디아 블랙웰 칩을 활용한 AI 팩토리 구축 및 보안 강화.

요약 인사이트:
현대차는 AI를 ‘서비스’가 아닌 ‘제품 진화의 동력’으로 활용한다.
완성차 기업의 한계를 넘어 소프트웨어 기업으로 전환하려는 명확한 의지다.
실제로 네이버·엔비디아와의 협업 구조를 보면, 가장 유연하면서도 실행 속도가 빠른 형태다.

⚖️ 비교 요약 표

구분삼성전자 (Gauss AI)네이버 (HyperCLOVA X)현대차 그룹 (HMG AI)
전략 목표내부 효율 + 제품 AI 통합플랫폼 혁신 + B2B 생태계 확장SDV + 모빌리티 혁신
기술 구조자체 파운데이션 모델, 온디바이스 중심자체 초거대 모델 + 오픈소스 생태계하이브리드(자체 + 협업) 구조
강점하드웨어 연동, 보안 통제데이터 풍부, 개방적 생태계명확한 시장 집중 및 유연성
약점외부 연동 제약, 플랫폼 한계하드웨어 접점 부족전환 속도·내부 조직 부담

결론

🔍 핵심 차이와 공통 패턴

  • 차이점: 삼성은 하드웨어, 네이버는 플랫폼, 현대차는 모빌리티 중심.
    즉, 각자의 기존 강점을 더 강화하는 방향으로 전략을 설계하고 있습니다.
  • 공통점: 세 기업 모두 ① 내부 업무 자동화, ② 고객 응대 AI, ③ AI 조직 강화 를 핵심 축으로 삼고 있음.
    즉, “AI 내재화 → 운영 효율화 → 서비스 고도화” 단계를 공통적으로 밟는 중입니다.

🔍 인사이트

차이점과 공통점에서 볼 수 있듯이,
AI를 통한 업무 효율화 및 개선은 모든 산업에서 공통적인 필수 영역이며,
각 회사마다의 핵심 강점을 더욱 차별화하고 강화하는 방향으로 작동해야 합니다.
결국 기업의 LLM 전략은 “AI를 어디에, 얼마나 깊이 통합하느냐”로 요약될 수 있습니다.

💬 AI PM 입장에서 본 시사점

  1. AI는 이제 ‘기능’이 아니라 전략 레이어다.
    세 기업 모두 AI를 제품·서비스·조직 전반에 녹이는 방식을 택했습니다.
    PM에게 요구되는 역량은 ‘AI 기획 능력’ 그 자체보다 AI를 통한 서비스 재설계 감각입니다.
  2. AI 도구 활용이 사고 방식을 바꾼다.
    예컨대, Perplexity → Notebook LM → ChatGPT 의 조합은
    단순 검색·요약이 아니라 ‘문제를 정의하고 스토리를 조립하는 사고 루틴’을 만듭니다.
    이것이 곧 AI 시대의 기획자 및 PM의 새로운 리서치 프레임워크입니다.
  3. 앞으로의 기획자는 ‘AI 생태계 조율자’가 된다.
    모델·데이터·UX·윤리까지 모두 교차하는 지점을 연결해야 합니다.
    즉, 기획은 더 이상 문서를 작성하는 일이 아니라 AI와 함께 사고 구조와 전략을 설계하는 일이 됩니다.

✍️ 이 글은 Perplexity로 자료를 수집하고, Notebook LM으로 분석한 뒤, ChatGPT로 정리했습니다.
세 도구를 하나의 워크플로우로 활용하면, 단순한 정보 요약이 아닌 ‘AI 리서치 루틴’을 구현할 수 있습니다.
결국 중요한 건 도구가 아니라, 그걸 통해 어떻게 사고하느냐겠죠.
다음 글에서는 이 루틴을 ‘AI PM의 업무 변화’ 관점에서 확장해보겠습니다.

🚗 현대차 LLM 챗봇 데모 (Hybrid: Rule + RAG)

추석 연휴 간,
개인 프로젝트로 진행한 하이브리드 챗봇 데모를 공개합니다.

Rule의 안정성과 LLM의 확장성을 결합하여,
연휴 기간 동안 바이브코딩 방식으로 직접 구축하고 다듬어 보았습니다.
(※ 현대자동차 공식 챗봇과 무관합니다.)

🎬 Hook: 1분 데모 + 최종 평가 표

👉 Demo: hyundai-chatbot-demo.vercel.app

※ 참고: Vercel 빌드 환경에서는 일부 RAG 질의(띄어쓰기·유사명칭·오탈자 등)의 인식률이 Stackblitz 실험 환경보다 낮게 나타날 수 있습니다.
본 영상은 Stackblitz 기준으로 촬영되었으며, 동일 코드 기반으로 Vercel에서도 대부분 정상적으로 작동합니다.

1️⃣ 왜 만들었나 (Why)

이번 데모는 바이브코딩을 통한 챗봇 구현 프로젝트의 일환으로, 차량 구매 목적의 실제 사용자 시나리오에서 출발했습니다.

기존 챗봇의 경우 기본 정보 제공은 충분했지만, 구매·시승·상담 등 다음 행동으로 자연스럽게 이어지는 흐름은 더 보완될 여지가 있었습니다.

목표는 기존 시스템을 비판하는 것이 아닌, “정보 전달 → 행동 전환” 간격을 줄이는 플로우 설계였습니다.

  • 구매 목적 사용자 시나리오의 개선 포인트
    • 견적/시승 문의까지 이동 단계가 비교적 길어지는 구간
    • 외부 페이지 이동 시 대화 맥락이 단절되는 지점
    • 동일 메뉴/버튼 반복 노출로 인한 탐색 피로

이에 따라 데모는 “FAQ 요약 + 공식 링크(CTA) + 최소 단계 전환”을 원칙으로, 사용자가 질문하면 필요 행동까지 즉시 연결되고 순환되는 경험을 지향했습니다.

2️⃣ 어떻게 만들었나 (How)

Part 1. 분석 & 전략

  • 가설
    1. 목표 행동(구매·시승·AS)까지 경로 단축과 링크/CTA 무결성이 사용자 만족도와 목표(KPI) 전환에 결정적이라고 가정
    2. 또한 LLM 측면에서 유사 발화 대응력(띄어쓰기·별칭·오탈자)이 실사용성에 큰 영향을 준다고 가정
  • 분석
    1. 실제 공식 사이트 캡처·메뉴 트리 분석
    2. Top FAQ 및 유사 발화 수집&정규화
    3. 링크 유효성 및 도메인 점검
  • 전략
    1. 플로우 단순화(Simplify Flow) → 메뉴 통합, CTA 중심 설계, 1~2단계 내 해결
    2. 지속적인 연결(Connect Experience) → 핵심 정보는 대화 내 제공, 필요 시에만 외부 링크
    3. 데이터 최신화(Keep Data Fresh) → 공식 FAQ 247 + 추가 Top 50 정비하여 반영 ( 지식 강화로 RAG 품질 안정화/고도화에 기여)

Part 2. 설계 & 개발

  • 아키텍처(Front-only Hybrid)
    • Rule Layer: 가격·보증·리콜·EV 추천 등 고정 의도 우선 처리
    • RAG Layer: faq.json + BM25 검색 → LLM 요약
    • UX Layer: 칩(Chips), 바텀시트, Sticky CTA(공식 링크/전화)

  • R1 → R2 → R3 개선 사이클
    • R1 (Prototype): Rule 70~80% + RAG 기본(가능성/흐름 우선)
    • R2 (Tuning): Rule 100% + 현대차 공식 FAQ 크롤링 반영 + BM25 교체, 유사 발화 정규화, 자동 테스트 루틴 구축
    • R3 (QA/Deploy): 자동/수동 라벨 교차검증, CTA·Fallback 보강 → 최종 평가 표 기준 전 항목 Pass

Part 3. 자동 테스트 & QA

  • 테스트 루틴
    • 콘솔 기반 runBatch() 자동 테스트 → 수동 라벨링으로 최종 판정
  • 라벨 분포 보정(R1을 예시)
    • 자동: Good 40 / Fair 120 / Bad 136
    • 수동(최종): Good 183 / Fair 2 / Bad 111
    • “자동–수동 일치율: 45.6%” → 임계값·가중치 보정 후 상향
  • 보정 정책(R3 반영)
    • Retrieval TopScore 임계값 조정(예: ≥20=Good 후보)
    • Retrieval 성공 시 CTA 필수 부착, Fallback에도 고객센터 CTA 제공
    • 부분매칭 Good는 Gold 데이터 보강하여 업데이트
      → 위 보정 이후, 본문 상단 최종 평가 표의 기준으로 품질을 점검·정리했습니다.

Part 4. RAG + Rule 하이브리드

  • 현업에서는 Rule-first를 반영했으나, 본 프로젝트에서는 RAG-first를 도입하여 실험
  • Retrieval 신뢰도(TopScore/Threshold)에 따라 FAQ → OpenDomain → Fallback으로 분기 처리
  • 역할 분리: “Rule = 안정성”, “RAG = 커버리지·설명력”
    ※ Vercel 배포 환경에서는 런타임(Edge vs Node) 및 경로 처리 차이로 인해 일부 질의(띄어쓰기, 유사명칭 등)의 검색 인식률이 Stackblitz 실험 환경 대비 다소 낮게 나타났습니다. 코드 구조와 데이터는 동일하며, 이는 환경 특성에서 비롯된 결과로 판단됩니다.

Part 5. 배포 트러블슈팅

  • Vercel 환경: OpenAI 직접 호출 지양 → /api/chat.ts 에지 프록시
  • 인덱싱 race 방지: ensureRagReady() 싱글톤 초기화 + 임베디드 코퍼스
  • dev/prod 코퍼스 동기화: assets 임베드 + 런타임 /faq.json 덮어쓰기
  • 재할당 경고 해결: const → let
  • 공식 FAQ URL 변경: 리다이렉트 미지원 건은 외부 이슈로 Skip

3️⃣ 결과 & 배운 점 (What / Lessons)

🎯 핵심 성과

  • 최상단 최종 평가 표 기준으로 정확도·라우팅/폴백·링크/CTA·성능·스타일/안전·UI/UX 전 항목 Pass를 달성했습니다.
  • Rule + RAG 결합 구조를 구축하고, 자동 QA 루틴(runBatch)을 적용했습니다.
  • R1→R2→R3 개선 사이클을 통해 품질을 확보하고 프로덕션 레디 수준으로 정비하였습니다.

🧩 진행 중 어려움

  • 마지막 5% 완성 구간에서 시간 소요가 집중되었습니다. (체감상 전체 소요 시간의 20% 이상)
  • 공식 사이트 URL 변경(리다이렉트 미지원)로 일부 항목은 Skip 처리했습니다.
  • 바이브 코딩 시, 프롬프트 반복 입력 시 맥락을 벗어나 필요 이상으로 수정 발생하는 케이스가 많았습니다.
  • 배포 환경(Vercel)에서 RAG 검색 성능이 Stackblitz 대비 약하게 나타났습니다. 이는 런타임 및 빌드 환경 차이로 인한 현상으로, 실 서비스 영향 범위는 RAG 한정으로 나타났습니다.

💡 교훈

  1. 작업 단위는 최대한 작게 쪼개고, 문맥은 명확하게 가져가야 합니다. (챗방 최대한 쪼개기 + 상세한 프롬프트 필요)
  2. 제안 코드는 그대로 적용하기보다 구조를 확인하고 최소 수정으로 해결해야 합니다.
  3. 바이브 코딩은 개발 도구에 가깝습니다(기본 문법·구조 이해가 효율을 좌우).
  4. Agent 로 자동 검수 + 수동 QA 조합으로 효율적으로 시간을 아끼고 품질을 높여줍니다.
  5. 초기 목표는 50% 범위로 설정해야 합니다. 최초 예상보다 2~3배의 시간과 노력이 소요되기 쉬워, 단계별 확장이 현명합니다.
  6. RAG 보정은 생각보다 어렵습니다. (예: 유사 발화·띄어쓰기·별칭 대응 등)

 

P.S. 추석 연휴 내내 작업하여 마지막 보정 작업과 글 작업을 진행하니 어느덧 1주일이 금방이네요. 처음 해보는 바이브코딩은 생각보다 어렵고 힘들었지만, 생각보다 재미있고 많은 걸 배울 수 있었습니다. 더 재미나고 쉬운 바이브코딩 2탄으로 찾아오겠습니다 😊🤩