15초 요약
AI 시대에 살아남는 건 '기획만 잘하는 PM'도, '코드만 잘 짜는 개발자'도 아니다.
전통적인 PM-디자이너-개발자 삼각 구조가 흔들리고 있습니다. AI 도구의 발전으로 한 사람이 기획부터 배포까지 책임질 수 있는 "프로덕트 엔지니어" 역할이 부상하고 있어요. 프로덕트 엔지니어는 LLM을 핵심 도구로 활용하면서 제품 감각과 엔지니어링 역량을 동시에 갖춘 T자형 인재입니다. 조직 구조도 프론트엔드/백엔드 팀 중심에서 온보딩, 결제, 알림 등 기능 단위 스쿼드로 변화하고 있으며, 각 프로덕트 엔지니어가 해당 기능의 엔드투엔드 책임을 지는 방식이 확산되고 있습니다.
알아두면 좋은 용어
- T자형 인재: 한 분야에 깊은 전문성(세로)을 갖추면서 다른 영역도 폭넓게 이해하는 사람
- LLM(Large Language Model): ChatGPT, Claude 같은 대규모 언어 모델. AI 코딩 어시스턴트의 기반 기술
- 스쿼드(Squad): 특정 기능이나 제품 영역을 담당하는 소규모 크로스펑셔널 팀
- 엔드투엔드(End-to-End): 기획부터 개발, 배포, 운영까지 전 과정을 의미
Y's Insight
PM은 기획만, 개발자는 코딩만"이라는 구분이 점점 희미해지고 있습니다. AI 코딩 도구의 발전이 이 변화를 가속화하고 있어요. 예전엔 간단한 기능 하나 만들려면 기획서 작성 → 디자인 요청 → 개발 티켓 생성 → 개발자 배정 → 구현 → QA 과정을 거쳐야 했는데, 이제 AI 도구를 활용하면 아이디어에서 프로토타입까지 혼자서도 가능한 시대가 됐습니다.
코칭했던 PM 중에 개발 경험이 전혀 없다가 Claude나 Cursor 같은 AI 도구로 간단한 내부 툴을 직접 만들어본 분이 있었어요. "개발자한테 요청하면 2주 걸릴 걸 반나절 만에 해결했다"고 하더라고요. 물론 프로덕션 레벨 코드는 아니었지만, 가설 검증 속도가 완전히 달라졌습니다. 반대로 시니어 개발자 중에 사용자 인터뷰를 직접 하고, 데이터 분석해서 기능 제안까지 하는 분들도 늘고 있어요.
핵심은 "PM이 코딩을 배워야 한다"가 아닙니다. "자기 역할의 경계를 스스로 정하지 말라"는 거예요. 기획자가 SQL 쿼리 하나 못 짠다고 부끄러워할 필요 없지만, "그건 개발자 일이니까"라고 선 긋는 순간 성장이 멈춘다. AI는 그 경계를 넘는 데 드는 비용을 극적으로 낮춰줬어요.
다만 현실적인 주의가 필요합니다. 이 글에서 말하는 "프로덕트 엔지니어"가 모든 조직에서 가능한 건 아니에요. 레거시 시스템이 복잡하거나, 도메인 지식이 깊이 필요한 영역에선 여전히 전문 분업이 효율적입니다. 중요한 건 트렌드를 맹목적으로 따르는 게 아니라, "내 맥락에서 어떤 역량을 확장하면 임팩트가 커질까"를 스스로 판단하는 거예요.
이런 액션을 취해보세요
AI 코딩 도구로 작은 자동화를 하나 만들어보세요. 반복 업무 중 하나를 골라 Claude나 ChatGPT에게 "이런 스크립트 짜줘"라고 요청해보는 거예요. Slack 알림 봇, 데이터 정리 스크립트, 간단한 대시보드 등 프로덕션이 아닌 내부 도구부터 시작하면 부담이 적어요. 직접 배포까지 할 필요 없이, "이게 되는구나"를 경험하는 것만으로도 제품을 보는 시야가 달라집니다.
부끄럽지만 저도 아직 자동화를 직접 만들어 본 경험은 없어요. '필요하면 그때 배우지뭐'라는 안일한 생각을 하고 있었거든요. 그런데 요즘 트렌드를 보면, 경력이나 도메인 상관없이 — 심지어 IT 직군이 아니더라도 — 자동화 시도가 필요한 시대가 됐다는 걸 느끼고 있어요. 그래서 저도 조만간 '미니미니 프로젝트'를 개인적으로 시도해보려 합니다 :)
실제 적용 사례
Linear (프로젝트 관리 툴)
- 소규모 팀임에도 빠른 속도로 제품 개선을 이어감
- 엔지니어들이 직접 고객 피드백을 읽고, 기능 우선순위를 정하고, 구현까지 담당
- 결과: 기획-개발 간 핸드오프 시간을 최소화하며 Jira 대안으로 급부상
Vercel
- 프로덕트 엔지니어 문화를 명시적으로 표방
- 엔지니어가 사용자 관점에서 기능을 설계하고, 출시 후 지표까지 책임지는 구조
- 결과: Next.js 생태계를 빠르게 확장하며 개발자 경험(DX) 리더로 자리잡음
근데 말이죠
"프로덕트 엔지니어가 뜬다"는 이야기에 "PM도 이제 코딩 못하면 도태되나?"라는 불안감을 느낄 수 있는데, 그건 오해예요. 핵심은 코딩 스킬 자체가 아니라 "경계를 넘어 문제를 해결하려는 자세"입니다. 또한 이 글에서 다루는 프로덕트 엔지니어 구조는 스타트업이나 개발자 제품 중심 회사에 유리한 모델이에요. 대기업, 규제 산업, 레거시 시스템이 복잡한 조직에서는 여전히 깊은 전문성과 명확한 분업이 더 효율적인 경우가 많습니다. 트렌드를 맹목적으로 따르기보다, "내 조직과 역할에서 어떤 역량을 확장하면 실질적인 임팩트를 낼 수 있을까"를 기준으로 판단하세요.