과도기의 소음에 관하여
최근 한 디자이너 채용 공고를 두고 뜨거운 논란이 있었습니다. 기획 역량은 기본이고, 생성형 AI로 디자인 리소스까지 양산할 수 있는 사람을 찾는 공고였죠. 지원자들의 반응은 차가웠습니다. 연봉을 두 배 주는 것도 아니면서, 왜 이렇게 많은 걸 요구하냐는 것이었죠
궁금해서 현업에서 AI를 적극적으로 쓰는 디자이너 분과 이야기를 나눠봤습니다. 반응은 의외였습니다.
“AI로 작업하면 속도가 3배는 빨라지는데, 회사 입장에선 당연히 그 정도를 ‘기본’으로 요구하지 않을까요? 저는 급여를 받는 입장이지만, 제가 회사라도 그 정도 하는 사람을 뽑을 것 같아요. 그렇지 않으면 손해일 것 같아요.“
순간 머리를 한 대 맞은 것 같았습니다. 누군가는 ‘과하다’고 분노하지만, 누군가는 ‘당연하다’고 말합니다. 저는 이 대화에서 ‘체감하고 있는 사람’과 ‘그렇지 않은 사람’ 사이의 좁혀지지 않는 간극, 그리고 시장에서 발생하는 혼란을 보았습니다.
저는 이 묘한 온도 차이의 실체가 궁금했습니다. 그 답을 찾기 위해서 가장 정직한 데이터인 ‘채용 공고’를 뜯어보기로 했습니다.
개발자는 이미 끝난 전쟁, 기획의 흡수
가장 먼저 눈에 들어온 것은 개발자 채용 공고 였습니다. 개발자의 AI 활용 능력은 이미 우대 사항보단 ‘생존을 위한 기본’에 가까웠습니다.
- N사: Cursor, Claude로 생산성 5배를 증명할 수 있는 분, 프롬프트 전략 제출 필수
- T사: 바이브 코딩 필수, 우리 팀의 기본 작업 방식입니다
- S사: 기획부터 출시까지 주도, Claude Code 능숙자
이 공고들이 말하는 바는 명확합니다. 기획자를 기다리지 말고, 직접 기획해서 개발하고 출시까지 끝내라는 것이죠. 이제 ‘Product Engineer’가 등장하고 있었습니다. 과거의 개발자는 기획자가 넘겨준 문서를 구현하는 사람이었다면, 이제 개발자는 AI라는 파트너와 함께 기획의 영역을 흡수하고 있었죠.
시끄러운 과도기, 디자이너. 역량의 확장
이번엔 디자이너 공고를 살펴보았습니다. 개발자 시장이 이미 AI를 표준으로 흡수했다면, 디자이너 공고는 포토샵, 일러스트레이터 같은 전통적인 툴 옆에 Midjourney, Stable Diffusion 같은 생성형 AI 툴이 ‘필수’ 혹은 ‘우대사항’으로 비집고 들어오고 있었습니다.
영역이 급격히 확장되면서 “이걸 다 해야 해? 요구가 너무 과한거 아니야?”라는 저항과 “당연히 해야지”라는 수용이 충돌하는, 과도기를 겪고 있는 것으로 보였습니다.
PM/PO, 폭풍전야의 침묵
그렇다면 과연 우리, PM/PO는 어떨까요? 원티드에서 인기순 상위 공고 12개를 살펴보았습니다. 결과는 충격적이었습니다.
- AI 도구 명시: 단 1곳. 그마저도 ‘AI 사용이 원활한 분’ 정도로 모호함
- AI 미언급: 11곳 (91.7%)
카카오뱅크를 비롯하여 내로라하는 기업들의 공고 어디에도 ChatGPT, Gemini, Claude 라는 단어는 찾아볼 수 없었습니다. 여전히 공고의 자격 요건은 화면설계, 일정관리, 커뮤니케이션이 주를 이루었습니다.
이 극명한 대조가 보이시나요?
물론 대기업은 보안 이슈로 AI 도입이 제한적일 수 있습니다. 하지만 스타트업 씬에서부터 빠르게 시작되는 변화는 결국 대기업의 채용 기준도 바꿀 것입니다.
침묵은 안전이 아니라 사각지대다
저는 이것이 안전을 의미한다고 생각하지 않습니다. 오히려 이 직군의 변화가 눈에 보이지 않아서 늦게 감지되고 있을 뿐이라고 생각합니다. 개발은 Claude Code, Cursor , 디자인은 Midjourney, Stable Diffusion 등과 같이 대표적인 활용 툴이 바로 떠오르는 반면에, 기획의 결과물인 정책과 구조는 눈에 잘 보이지 않기 때문입니다.
하지만 위기는 이미 시작되었습니다. 앞서 본 개발자 공고처럼, AI를 장착한 Product Engineer들은 조용히 기획의 영역을 흡수하고 있기도 합니다. 개발자가 기획을 하고 싶어서 한다기보단, AI 덕분에 ‘할 수 있게’ 되었고, 기업은 효율성을 위해 그런 개발자를 선호하게 될 것입니다.
이 끝은 어디일까요? 1년 후, PM/PO 공고도 디자이너처럼 논란이 될까요? 같은 요구사항을 보고 누군가는 과하다고 말하고, 누군가는 당연하다고 말할 것입니다.
흡수될 것인가, 고유하게 남을 것인가
그렇다면 더 근본적인 질문이 생깁니다. 개발자 혹은 디자이너가 기획자의 영역까지 완전히 흡수해버릴까요? 아니면 기획자만이 할 수 있는 고유한 영역이 남을까요?
결론부터 말하자면, 의사소통만 하던 커뮤니케이션형 기획자는 흡수될 것이고, 아키텍트형 기획자는 고유하게 남을 것입니다. 단순히 개발자에게 요구사항을 전달하고 일정을 조율하는 역할은 AI를 장착한 개발자가 훨씬 더 잘할 수 있습니다. 이제 단순한 중간 단계는 사라질 운명입니다.
하지만 AI와 개발자가 결코 대체할 수 없는, 프로덕트 아키텍트만의 3가지 핵심 무기가 있습니다.
1.문제를 정의하는 힘
프로덕트 아키텍트는 ’어떻게 만들까‘를 고민하기 이전에, ’무엇을 만들까‘를 먼저 고민합니다. AI는 주어진 문제를 푸는 데는 탁월하지만, “어떤 문제를 풀어야 하는가”는 정의하지 못합니다.
B사가 ’미니CEO‘를 요구하는 이유, K사가 ’시스템 논리적 구조 설계‘를 요구하는 이유가 여기 있습니다.
도메인을 깊이 이해하고, 진짜 문제가 무엇인지 정의하는 능력. 이것이 첫 번째 무기입니다.
2. 전체를 설계하는 힘
Product Engineer는 ’기능‘을 만듭니다. 프로덕트 아키텍트는 ’시스템‘을 설계합니다.
S사의 풀스택 개발자가 ’기획부터 출시까지 주도‘할 수 있는 이유는 단일 기능 하나를 빠르게 만들 수 있기 때문입니다. 하지만 수십 개의 기능이 유기적으로 연결되어 하나의 일관된 경험을 만들어내는 시스템을 설계하는 것은 다른 문제입니다.
K사의 PM이 ’API 구조에 대해 깊이 있는 대화‘를 요구하는 이유, C사가 ‘고객 Journey 전체를 설계’하길 요구하는 이유가 여기 있습니다. 나무를 보는 것과 숲을 설계하는 것은 다릅니다.
3. 가설을 검증하는 힘
마지막은 전달이 아닌 ‘검증’입니다. 과거 기획자는 “이 기능 구현 가능할까요? 얼마나 걸릴까요?“를 물었습니다. 하지만 프로덕트 아키텍트는 ”내가 AI로 프로토타입을 돌려보니, 이 로직이 맞더라“고 증명합니다.
거창한 코딩이 아니라, 내 기획의 핵심 로직을 AI 도구로 빠르게 시뮬레이션 하는 것을 말합니다.
이제 ”개발팀에서 어렵대요“라는 말을 앵무새처럼 전하는 기획자는 설 자리가 없습니다. 문서로 설득하는 대신, 작동하는 결과물로 내 기획의 정합성을 스스로 검증해내는 힘을 가져야합니다. Product Engineer가 득세하는 세상에서, 기획자로서 그들과 대등하게 대화할 수 있는 유일한 열쇠입니다.
1년 뒤, 당신의 이력서에는?
다시 처음의 디자이너 공고 논란으로 돌아가봅시다. 논란의 본질은 결국 ’설명하는 시대‘에서 ’증명하는 시대‘의 이동에 가깝습니다.
1년 뒤, 당신의 이력서에 보유 기술란을 한 번 상상해보세요. 여전히 Figma, Jira, Slack만 적혀있나요? 아니면 Prototyping, Architecture Design 등이 적혀 있나요?
지금 PM/PO 시장의 고요함은 평화가 아니라 폭풍전야의 침묵에 가깝다고 저는 생각합니다. 과도기는 이미 시작되었습니다. 누군가는 파도를 타고 있고, 누군가는 파도가 오는지도 모른 채 해변에서 모래성을 쌓고 있을 뿐입니다.
공고에 ‘AI 역량 필수’라는 한 줄이 뜨기 전인 지금이, 우리가 ‘체감하는 사람’으로 넘어갈 수 있는 골든타임인지도 모릅니다. 당신은 어느 쪽에 서 계실건가요?