PM은 꼭 기술을 알아야 할까?
서비스 기획자나 PM(PM: Product Manager)를 공부하다보면 한 번쯤 들게되는 의문이 있습니다.
“PM은 기술을 꼭 알아야 할까요?”
비전공자 입장에서 이 질문은 단순한 호기심이 아니라, 실무의 벽처럼 느껴질 수 있습니다. 실제로 현업엔 개발 지식 없이도 잘 일하는 기획자도 있고, 반대로 개발자 출신의 PM도 많습니다. 그래서 기술의 ‘필요 유무’보다는 ‘어느 정도까지 알아야 하는가’가 더 현실적인 질문이라고 생각합니다.
이번 글에서는 기획자 또는 PM이 기술을 반드시 알아야 하는지, 그리고 기술에 대한 이해가 실무에서 어떤 역할을 하는지를 중심으로 이야기해보겠습니다.
기술을 몰라도 시작은 할 수 있습니다. 하지만…
결론부터 말하자면, PM이 반드시 개발을 할 줄 알아야 하는 건 아닙니다. 비전공자 PM도 문제없이 업무를 시작할 수 있죠. 특히 기획 업무의 본질은 ‘문제를 정의하고 해결 방향을 설계하는 것’에 있기 때문에, 초기에는 오히려 커뮤니케이션 능력, 서비스 감각, 논리적인 사고가 더 중요하게 작용하는 경우도 많습니다.
초보 PM이나 주니어 기획자의 경우, 처음부터 기술적 배경이 없다고 해서 크게 불리하지는 않습니다. 오히려 사용자 중심의 시각과 기획 논리만으로도 실무에 참여할 수 있습니다. 특히 스타트업이나 중소규모 기업에서는 비개발자가 맡은 기획 업무가 비교적 직관적이고 실험 중심으로 진행되는 경우가 많기 때문에 진입 장벽이 낮습니다.
하지만 일을 주도적으로 해나가야 하는 단계에 들어서면 이야기가 조금 달라집니다. 기술을 완전히 배제하고 기획하기 어려운 상황이 하나둘씩 생기기 시작합니다. 예를 들면 다음과 같습니다.
- 새 기능을 기획할 때, 이게 기술적으로 가능한지 빠르게 판단해야 하는 상황
- 개발자와의 회의에서 일정과 구현 범위를 논의할 때, 현실적인 기대치를 설정해야 할 때
- API 명세서를 보며 화면 설계서를 그려야 할 때, 데이터의 흐름과 구조를 이해해야 하는 순간
- 서비스에 오류가 발생했을 때, 어느 지점에서 문제가 발생했는지 유추해야 하는 상황
이런 순간에는 기술을 모르더라도 일을 할 수는 있지만, 기술을 이해하고 있으면 훨씬 더 효율적이고 매끄럽게 일할 수 있다는 걸 실감하게 됩니다.
PM에게 필요한 건 ‘코딩 실력’이 아니라 ‘기술 이해력’
그렇다면 PM도 개발을 배워야 할까요? 여기서 중요한 건 PM에게 요구되는 기술 역량의 ‘깊이’입니다. 실무에서 PM에게 직접 코드를 짜라고 요구하는 경우는 드뭅니다. 대신, 기술을 이해하고, 구현 가능성과 리스크를 가늠하며, 팀원들과 원활히 협업할 수 있는 수준의 기술 감각이 필요합니다.
예를 들어 아래와 같은 기술적 개념을 이해하고 있다면, 실무에서 매우 유리하겠죠.
- 프론트엔드와 백엔드의 차이
- API 요청/응답의 흐름과 동작 방식
- 데이터베이스의 기본 구조 (스키마, 조인, 트랜잭션 등)
- 앱과 서버가 어떻게 통신하고 데이터를 주고받는지
- 배포, 빌드, 테스트가 어떤 흐름으로 진행되는지
(프로젝트마다 회사마다 천차만별로 다르겠지만) 이 정도 수준만 돼도 기획자로서 기술 커뮤니케이션에서 겪는 대부분의 어려움을 줄일 수 있습니다. 또한 개발자 입장에서도, 기술을 어느 정도 이해하는 PM과는 이야기가 훨씬 잘 통하고, 신뢰도도 더 쉽게 쌓입니다. 이는 협업의 질로 이어지고, 결국 제품의 완성도에도 영향을 줍니다.
기술 감각을 기르는 현실적인 방법
그렇다면 실무에 있는 비전공자 PM이 기술 이해력을 높이려면 어떤 노력을 해야 할까요? 굳이 코딩 학원을 다니거나 컴퓨터공학 전공 책을 볼 필요는 없습니다. 다음과 같은 방법들을 통해 간접적으로 길러나갈 수 있습니다.
1) 개발자 회의에 적극 참여하기
요청하지 않아도 회의나 코드 리뷰 자리에 앉아 설명을 들어보는 것만으로도 큰 도움이 됩니다. 개발자들이 어떤 기준으로 판단하고 어떤 용어를 쓰는지 감을 잡을 수 있습니다.
2) API 문서와 친해지기
Swagger나 Postman으로 정리된 API 문서를 직접 읽어보며, 어떤 요청에 어떤 응답이 오는지, 어떤 데이터가 필요한지를 파악해보자. 이를 화면 설계서에 반영하면 기획 정확도도 올라갑니다.
3) 사이드 프로젝트나 노코드 툴 실습
Flutterflow, Glide, Softr 등 노코드 툴을 활용해 간단한 앱이나 페이지를 만들어보면 개발자의 시선에서 기능을 설계해볼 수 있습니다. 기술적 제약과 구조를 몸으로 익힐 수 있다는 점에서 매우 효과적입니다.
4) 기술 블로그 읽기
네이버 D2, 카카오 테크, 우아한형제들 기술 블로그처럼 기업의 기술적 고민과 해결 사례를 담은 글들을 읽어보는 것도 하나의 방법입니다. 어려운 내용은 넘기더라도, 맥락을 자주 접하면 자연스럽게 익숙해질 것입니다.
5) 협업 중 대화를 학습의 기회로 삼기
일하면서 막히는 부분이 있다면, 개발자에게 기능 구현 시 어떤 선택지를 고려했는지 물어보는 것만으로도 기술적 맥락을 이해하는 데 도움이 됩니다. 사실 실무 안에서 배우는 게 가장 빠르고 실용적이죠.
PM은 기술자는 아닙니다. 하지만 기술을 이해하는 기획자는 훨씬 더 빠르게, 더 정확하게 팀을 이끌 수 있습니다.
비전공자라고 주저하지 않아도 되지만, 기술을 모른다는 이유로 회의에서 눈을 피하거나, 기획서를 개발자에게 그냥 넘겨주는 태도는 피해야 하겠죠.
기획자는 기술을 배워서 개발자가 되는 것이 아니라, 기획자의 언어로 기술과 대화할 수 있어야 합니다.
지금 당장 어렵고 낯설게 느껴지더라도, 실무 속 작은 습관부터 바꿔나가다 보면 기술은 분명한 '무기'가 되어줄 것입니다.