AI 코딩 도구가 빠르게 확산되면서 “개발자 없이도 제품을 만들 수 있다”는 말이 심심찮게 들린다. 자연스럽게 PM·PO·기획자·마케터·디자이너 같은 비개발 직군 사이에서는 불안감이 커지고 있다. 개발자는 자동화 도구를 활용해 생산성을 높이는데, 나는 이 변화 속에서 어떤 포지셔닝을 가져가야 하는가. 이 글은 그 물음에 현실적인 방향을 제시한다.
왜 지금 비개발 직군이 불안한가
기술 업계에서 개발자 채용 비중이 높아지고, AI 도구 덕분에 소규모 팀이 더 적은 인원으로 제품을 운영할 수 있게 됐다. 스타트업 채용 공고를 보면 “기획+마케팅”이나 “PM+데이터 분석” 같은 복합 역할이 점점 많아지고 있다. 이는 개별 직군의 경계가 흐려지고 있다는 신호다.
그렇다고 PM이나 PO, 비개발 직군이 불필요해지는 방향은 아니다. 정확히는 ‘예전 방식 그대로’ 일하는 사람에게만 위협적이다. 사용자 문제를 정의하고, 이해관계자를 조율하고, 비즈니스 맥락을 연결하는 능력은 AI 코딩 도구가 대체할 수 없다. 그러나 그 능력만으로는 충분하지 않게 됐다.
기술 문해력: 코딩이 아니라 ‘읽는 능력’
많은 비개발 직군이 “나는 코딩을 배워야 하나”를 묻는다. 현실적인 답은 “전부 배울 필요는 없지만, 기술 언어를 읽고 질문할 줄 알아야 한다”이다. 개발자와 대화할 때 API, 데이터베이스, 배포 파이프라인, 쿼리 같은 개념이 낯설면 의사결정 속도가 느려지고 신뢰를 잃기 쉽다.
실제로 PM 역할을 잘 수행하는 사람들은 대부분 코드를 작성하지 않지만, 개발팀이 어떤 식으로 일하는지는 이해한다. 스프린트 단위로 무엇을 왜 우선순위에 두는지, 특정 기능 구현이 왜 2주가 걸리는지를 논리적으로 파악하고 설명할 수 있다.
당장 실천할 수 있는 기술 문해력 기초는 다음과 같다.
- SQL 기초 쿼리로 직접 데이터 꺼내보기 (집계·필터·조인 수준)
- 서비스 내 API 명세(Swagger 또는 Notion 문서) 읽고 엔드포인트 구조 파악하기
- GitHub에서 이슈·PR 코멘트 따라가며 기능 변경 흐름 이해하기
- AI 코딩 도구(Cursor, GitHub Copilot 등)로 간단한 스크립트 직접 실행해보기
데이터 역량: 분석이 아니라 ‘질문 능력’
데이터 분석은 분석가의 영역이 맞다. 그러나 PM·PO는 데이터로부터 올바른 질문을 던질 줄 알아야 한다. “이 기능 출시 후 전환율이 올랐나요?”가 아니라 “출시 후 7일, 어느 단계에서 이탈이 늘었는지, 신규 유입과 기존 사용자를 분리해 보면 어떻게 되나요?”를 묻는 수준이다.
지표를 보는 관점이 명확할수록 데이터 팀과의 협업이 빨라지고, 보고서를 기다리는 시간을 줄일 수 있다. 스프레드시트나 간단한 BI 도구(Looker Studio, Metabase 등)를 직접 다룰 수 있다면 더욱 독립적으로 움직일 수 있다.
핵심은 데이터 사이언티스트가 되는 것이 아니다. ‘결과를 봤을 때 무엇을 확인해야 하는지’를 먼저 정의하는 습관이다. 가설을 세우고, 측정 기준을 미리 정하고, 결과를 해석하는 사이클을 반복하면 된다.
포지셔닝의 재설계: ‘조율자’에서 ‘결합자’로
과거에 PM은 개발팀과 비즈니스팀 사이에서 요구사항을 전달하는 역할로 충분했다. 그러나 AI 도구가 실무 개발 속도를 높이면서, 조율에만 특화된 포지션의 효용은 줄어드는 경향이 있다. 대신 비즈니스 맥락과 기술 맥락을 동시에 이해하며 ‘무엇을 왜 만들지’를 스스로 정의할 수 있는 ‘결합자(connector)’ 역할이 더 필요해졌다.
실제로 채용 시장에서 “GPT 활용 가능”, “SQL 기초 보유”, “데이터 기반 의사결정 경험” 같은 키워드를 강조하는 PM·PO 구직자들이 면접 전환율이 높다는 이야기가 현업에서 회자된다. 이력서에 도구 나열보다 중요한 건, 특정 문제를 데이터와 기술을 활용해 어떻게 해결했는지를 보여주는 구체적 사례다.
스스로에게 물어볼 점검 질문들이다.
- 나는 현재 팀에서 개발자가 없어도 데이터로 어느 수준의 의사결정을 내릴 수 있는가?
- 사용자 인터뷰나 리서치를 설계하고, 결과를 제품 방향에 반영한 사례가 있는가?
- 나만이 볼 수 있는 비즈니스 맥락은 무엇인가? 그것이 팀의 결정에 어떻게 반영됐는가?
도메인 깊이: 대체 불가 영역을 만드는 방법
가장 강력한 생존 전략 중 하나는 특정 도메인에서 깊이를 갖는 것이다. 헬스케어 규제, 금융 컴플라이언스, B2B SaaS의 고객 성공 구조, 교육 서비스의 학습 설계 같은 영역은 기술만으로 접근하기 어렵다. 해당 분야의 맥락과 사용자를 오래 이해한 사람만이 제대로 된 제품 판단을 내릴 수 있다.
도메인 깊이를 쌓는다는 것은 단순히 ‘그 분야에서 오래 일했다’가 아니다. 사용자를 직접 만나 인터뷰하고, 업계 규제와 트렌드를 주기적으로 추적하고, 경쟁 제품을 분석하면서 자신만의 관점을 계속 업데이트하는 것이다. 이 과정이 축적되면, 아무리 기술이 발전해도 쉽게 대체되지 않는 판단 역량이 된다.
실천 방법을 구체적으로 정리하면 다음과 같다.
- 분기마다 실제 사용자 5명 이상과 인터뷰하고 인사이트를 문서화한다
- 자신이 담당하는 도메인의 규제·정책 변화를 뉴스레터나 공식 채널로 추적한다
- 경쟁사 신규 기능이 나올 때마다 왜 그 결정을 했을지를 가설로 분석해 기록한다
- 팀 내 의사결정 순간에 자신의 관점을 문서로 남기고, 결과와 비교해 피드백 루프를 만든다
커리어 전환을 고려한다면: 지금 준비해야 할 것
이직이나 직군 전환을 고민하는 비개발 직군이라면, 먼저 자신의 현재 역량과 이동하려는 역할 사이의 간극을 솔직하게 진단하는 것에서 출발해야 한다. “PM을 하고 싶다”는 막연한 목표보다는 “현재 서비스 기획 경험 3년, SQL 기초 있음, 데이터 분석 경험 부족 → 6개월 안에 스타트업 PM 포지션”처럼 구체화할수록 준비가 명확해진다.
전환 준비에서 많이 놓치는 부분이 포트폴리오다. PM 포트폴리오는 화려한 디자인이 아니라, 문제 정의 → 해결 방식 → 결과 측정의 흐름을 보여주는 것이 핵심이다. 수치가 없으면 과정을 정직하게 서술해도 된다. “출시 후 정량 측정을 못 했지만, 사용자 인터뷰 10건을 통해 주요 불만 포인트를 확인했고 다음 스프린트에 반영했다”처럼 솔직한 서사가 더 신뢰감을 준다.
면접에서 자주 나오는 질문 유형과 준비 방향은 다음과 같다.
- “가장 어려웠던 우선순위 결정 경험은?” → 이해관계자 갈등 상황과 자신의 판단 근거를 구체적으로 준비
- “데이터로 의사결정한 사례는?” → 실제 수치 또는 정성 데이터를 활용한 경험, 결과보다 과정 중심으로
- “개발팀과 갈등을 어떻게 해결했나?” → 기술 맥락 이해 위에서 협상한 경험이 가장 효과적
- “이 서비스의 가장 큰 문제는 무엇이고 어떻게 개선하겠나?” → 사전 분석·가설·측정 방법까지 세트로 준비
개발자 편중 채용 트렌드는 분명 존재하지만, 기술을 이해하고 비즈니스 맥락을 연결하는 사람의 자리는 여전히 필요하다. 변화를 두려워하기보다, 자신의 역량을 솔직하게 진단하고 지금 당장 채울 수 있는 한 가지부터 시작하는 것이 가장 현실적인 전략이다.
누스쿨에는 PM·PO·기획자·마케터 등 비개발 직군의 커리어 전환과 성장을 직접 경험한 멘토들이 있다. 내 상황에 맞는 구체적인 피드백이 필요하다면 누스쿨 멘토링에서 출발해 보자. 이력서 검토부터 포트폴리오 방향, 면접 준비까지 실질적인 도움을 받을 수 있다.
💬 댓글 0