지금 프로덕트 업계에서 가장 조용하고 가장 빠르게 일어나고 있는 변화가 있다. 누가 가장 위험한 플레이어인가에 대한 정의가 바뀌고 있다는 것. 예전엔 전략적 사고를 가진 PM, 깔끔한 프로세스를 가진 디자이너가 핵심 인재였다. 지금은 다르다. 아이디어를 가장 빠르게 현실로 만들어내는 사람이 조직에서 가장 큰 레버리지를 가진다.
핵심 이슈: 역할의 경계가 무너지고 있다
dev.to에 올라온 한 아티클은 이 변화를 정확하게 짚는다. "대기업에서 가장 위험한 디자이너는 직접 배포할 수 있는 사람"이라는 제목의 글은, 오랫동안 유지되어 온 디자이너-엔지니어-PM의 역할 분리 모델이 AI로 인해 근본적으로 흔들리고 있다고 진단한다. 과거의 핸드오프 모델—디자이너가 목업을 넘기면 엔지니어가 구현하는 구조—은 빌드 비용이 높고 반복 속도가 느릴 때는 합리적이었다. 하지만 AI가 아이디어를 현실로 바꾸는 비용 자체를 낮춰버리면서, 병목은 이제 "만들 수 있는가"가 아니라 "충분히 빠르게 검증할 수 있는가"로 이동했다.
메타·구글 출신 프로덕트 리더 Nikhyl Singhal은 요즘IT의 보도에 따르면, 시니어 프로덕트 리더 125명이 모인 커뮤니티 Skip을 운영하며 이 변화를 가장 가까이서 관찰하고 있는 인물이다. 그의 진단은 직설적이다. "PM의 절반 정도는 빌더가 아닌 정보 전달자 유형이고, 이 사람들은 위기에 처해 있다." 3년 전까지 PM의 하루는 정보를 정리하고 층층이 전달하는 일이 대부분이었다. 그 역할이 AI로 빠르게 대체되면서, 남는 것은 두 가지뿐이다. 판단력과 직접 만드는 능력.
맥락 해석: 코드는 이미 디자인 재료가 됐다
이 변화의 핵심을 이해하려면 코드에 대한 관점을 바꿔야 한다. 코드는 더 이상 구현 수단만이 아니다. 특히 AI 프로덕트에서는 코드가 Figma보다 훨씬 현실에 가까운 프로토타이핑 재료다. 정적 목업은 화면이 어떻게 생겼는지를 보여주지만, 인터랙션에 생명이 있는지는 보여주지 못한다. AI 추천이 언제 등장하는지, 사용자가 출력을 신뢰하는지, 트랜지션이 도움이 되는지 방해가 되는지—이런 것들은 코드로 만들어봐야 알 수 있다.
dev.to의 AI 소프트웨어 엔지니어 전직 사례도 같은 결을 보여준다. 6개월의 공백 후 다섯 개의 프로덕트와 새로운 아키텍처를 들고 돌아온 그는, Claude Code와 Cursor Agents 같은 도구가 이제 오토컴플리트가 아닌 실제 엔지니어링 파이프라인의 협업자로 자리잡았다고 말한다. "AI가 개발자를 대체한다"는 내러티브는 이미 정점을 찍고 내려왔다. 대신 더 정확한 명제가 남았다. AI는 개발자 시간의 가치를 재배분한다. 보일러플레이트에 쓰던 시간은 줄고, 아키텍처 판단과 프로덕트 사고에 쓰는 시간의 가치가 올라간다.
Singhal이 운영하는 125명 커뮤니티에서 최근 쇼앤텔 행사가 열렸다. 참가자 전원이 노트북을 열고 자신이 직접 만든 것을 보여주며 서로 경쟁했다. 3년 전만 해도 프로덕트 리더 모임에서 코드를 보여주는 건 상상하기 어려운 장면이었다. 이게 지금 업계가 어디로 가고 있는지를 단적으로 보여준다. 12개월 사이 125명 중 14명이 창업자로 전환했다. 빌더 성향의 PM이 역대 최고의 기회를 잡고 있다.
시사점: 프론트엔드 개발자의 포지셔닝은 어떻게 달라져야 하나
프론트엔드 개발자 입장에서 이 흐름은 위협이 아니라 기회다. 디자이너와 PM이 코드 쪽으로 이동하고 있다면, 코드를 기반으로 프로덕트 사고까지 할 수 있는 프론트엔드 개발자는 그 어느 때보다 강력한 포지션을 가질 수 있다. 관건은 단순히 코드를 잘 짜는 것이 아니라, 아이디어에서 검증까지의 거리를 가장 빠르게 좁히는 능력이다.
구체적으로는 세 가지 역량이 중요해진다. 첫째, 고피델리티 프로토타이핑 속도다. Cursor, Claude Code 같은 도구를 활용해 정적 목업이 잡지 못하는 인터랙션의 실질적 감각—타이밍, 애니메이션, 반응성—을 빠르게 코드로 구현하는 능력. 둘째, 워크플로우 판단력이다. B2B 제품에서 온보딩 흐름 하나를 개선하면 활성화율이 달라지고, 승인 경험 하나를 정리하면 운영 오류가 줄어든다. 이런 임팩트를 판단하고 우선순위를 세우는 눈. 셋째, 빠른 학습 루프 설계다. 만들고 배포하고 학습하는 사이클 자체를 시스템처럼 설계하는 것—이게 AI 시대 프론트엔드 개발자의 진짜 차별점이다.
아키텍처 관점에서도 시사점이 있다. 다섯 개의 프로덕트를 독립 레포로 관리하다 공유 패키지 레이어로 통합한 사례는, "속도를 위해 공유를 포기해야 한다"는 통념이 잘못됐음을 보여준다. 공유 로직과 독립 배포는 상호 배타적이지 않다. 빠른 빌더가 되려면 좋은 아키텍처 판단이 먼저다.
전망: 2년 안에 새 기준이 잡힌다
Singhal은 이 혼란이 영원하지 않을 거라고 했다. 인터넷이 등장했을 때도 PM의 일하는 방식이 뒤집혔지만, 몇 년 지나 새 기준이 잡혔다. 지금도 2년 정도면 안정될 거라는 게 그의 관측이다. 다만 그 2년이 결정적이다.
지금 이 시점에서 프론트엔드 개발자에게 필요한 건 거창한 커리어 재설계가 아니다. 오늘 손에 잡히는 문제 하나를 골라서, Cursor나 Claude Code로 직접 만들어보는 경험이다. 빌더 성향은 타고나는 게 아니라, 직접 만들어본 경험이 한 번 쌓이면서 두려움이 기쁨으로 전환되는 그 순간부터 시작된다. 그 첫 번째 순간을 지금 만들 수 있다면, 이미 새 기준의 앞쪽에 서 있는 것이다.