A부터 Z까지 조금씩 다 할 수 있는 제너럴리스트형 디자이너(d/D)
안녕하세요! 저는 서비스디자인을 전공하고 졸업을 앞둔 25살 대학생입니다. UX나 UI 쪽으로 진로를 정한 후 다양한 포지션들을 알아보던 중 ‘프로덕트 디자이너(?)’라는 역할이 눈에 자주 띄더라고요. 그런데 이 직무가 정확히 어떤 일을 하는 건지 헷갈리는 부분이 많아 이렇게 질문드려요!
UX 디자이너(?), UI 디자이너(?), 서비스 디자이너(?)와는 어떤 차이가 있는지 잘 모르겠고, 특히 프로덕트 디자이너(?)가 실제 현업에서 어떤 문제에 책임을 지고, 어떤 프로세스를 리드하는지 궁금해요. 단순히 디자인(d)만 하는 게 아니라 기획, 데이터, 비즈니스까지 고려한다고 들었는데… 그럼 디자이너(D)이자 PM 같은 느낌인 걸까요?
요즘엔 ‘Figma 등’ 툴 활용 능력보다도 문제 정의나 사용자 관점에서 솔루션을 제시하는 힘이 중요하다고들 하시던데, 프로덕트 디자이너(?)는 어떤 역량을 중점적으로 키워야 할지도 알고 싶어요. 신입으로서 준비할 때 꼭 염두에 둬야 할 점이 있다면 조언 부탁드릴게요!
➥ UX 자체는 고정된 ‘직무’라기보다 궁극적으로 지향하는 목표입니다. 따라서 UX는 제품이나 서비스에서 사용자의 경험을 향상시키는 것이 핵심 과업이며, 이 목표를 실현하기 위한 직무 이름들이 필요에 따라 다양하게 파생되어 왔습니다. 회사마다 UX 디자이너(?), UI 디자이너(?), 서비스 디자이너(?), 프로덕트 디자이너(?) 등의 명칭을 달고 있지만, 실제로 담당하는 역할은 상당히 유동적입니다.
그 정의 또한 조직 구조나 산업군에 따라 달라지기 때문에 혼란스러울 수밖에 없습니다. 어떤 조직에서는 UX를 ‘조사’의 영역으로만 한정짓고, 어떤 곳에서는 ‘디자인(D) 전체’로 바라보기도 하니까요. 그럼에도 불구하고 프로덕트 디자이너(d/D)라는 직무명은 수요가 많아 더 자주 들리며 일반적인 관점에서 답변 드려보도록 하겠습니다.
‘프로덕트 디자이너(d/D)’라는 용어는 전통적인 제조업보다 디지털 서비스업계에서 먼저 등장한 개념입니다. 특정 제품의 UX 목표를 달성하기 위해, 하나의 Function Owner에게 전 과정의 책임을 위임하는 구조에서 비롯된 역할이라 할 수 있습니다.
즉, 이는 단순히 디자인(d) 시안만 만드는 사람이 아니라, 기획부터 리서치, UX 구조 설계, UI 작업, 그리고 개발 후 QA에 이르기까지 제품의 한 사이클을 전방위적인 역할을 수행합니다. ‘디자이너(d)’라는 이름으로 불리다보니 오해가 많기도 합니다. 실제로는 전략, 운영, 사용자 경험 전반을 아우르는 포지션으로 이해해야 합니다.
정리하자면, 프로덕트 디자이너(d/D)는 하나의 문제에 대해 기획자처럼 문제를 정의하고, 디자이너(d)처럼 시각화하고, PM처럼 실행과 결과까지 책임지는 사람이라 볼 수 있습니다. 이는 단순히 ‘무거운 역할’이라기보다는, 서비스 성공을 위해 UX 목표 달성이라는 큰 그림을 끝까지 책임지는 구조라고 이해하시면 됩니다.
실제 업무에 들어가면 프로덕트 디자이너(d/D)는 기능 단위의 의사결정은 물론, UI 혹은 UX 관점의 사용자 흐름, 과업 간 우선순위, 데이터에 기반한 개선 사항 등을 종합적으로 다루게 됩니다.
문제를 어떻게 바라보고 정의하느냐부터, 이 기획안이 실제 제품에 반영되기까지 사용자 입장의 논리를 끊임없이 대입하면서도, 비즈니스와 개발의 현실적 제약을 동시에 조율해야 합니다. 때문에 디자인(d) 툴을 잘 다루는 능력도 물론 필수적이나 문제 해결을 위한 전략적 사고와 협업 능력 역시 중요합니다.
또한 이런 업무 특성상, 시각적인 산출물이 아니라 디자인(D)을 만든 이유, 선택한 구조, 제시한 방향의 타당성이 더 중요하게 평가받습니다. 툴은 누구나 익힐 수 있지만, 어떤 문제를 발견하고 어떤 논리로 풀어갔는지는 실무에서 곧 전문성으로 여겨지기 때문입니다.
따라서 신입 UXer가 준비할 때는 ‘디자인(d)’보다 ‘사고방식’에 더 초점을 맞추는 게 좋습니다. 사용자의 문제를 어떻게 정의하고, 어떤 방식으로 접근하고자 했는지에 대한 과정 중심의 UX 포트폴리오가 필요합니다. 단순히 Figma 등 툴을 능숙하게 다루는 것도 중요하지만, 그보다도 문제 해결을 위한 설계력, 사용자 중심의 관점, 그리고 조직 내 협업을 위한 논리적 커뮤니케이션 능력이 핵심입니다.
특히 프로덕트 디자이너(d/D)는 디자인(d) 결과물만을 보는 직무가 아닙니다. 결과물을 도출하는 맥락 전체를 설계하고, 정리하고, 설득할 수 있어야 실무에서 인정받을 수 있습니다. 이 때문에 실무 경험이 있다면 더할 나위 없이 좋지만, 그게 없다면 작은 프로젝트라도 문제정의 → 구조설계 → 결과물 도출의 흐름을 잘 보여주는 훈련이 꼭 필요합니다.
현업에서는 디자인(d/D)을 ‘이론’보다 ‘상황’ 속에서 풀어야 할 일이 대부분입니다. 내가 생각한 UX 이론이나 프레임워크가 현실과 부딪히면서 얼마든지 변경되기도 하고, 갑작스러운 일정이나 조직 구조로 인해 의도한 대로 흘러가지 않는 경우도 많습니다.
그래서 신입 단계에서는 무엇보다 실제 업무 경험을 통해 감각을 익히는 것이 중요합니다. 교육이나 자격보다 짧은 기간이라도 인하우스에서 실무를 경험해보는 것이 훨씬 더 큰 도움이 됩니다. 그런 경험이 곧 UX 목표에 실질적으로 기여할 수 있는 ‘실행력’으로 이어지고, 이는 차후의 커리어 전개에도 직접적인 영향을 미칩니다.
프로덕트 디자이너(d/D)는 경계를 허무는 직무입니다. 디자인(d), 기획, 리서치, 개발 협업 등 어느 한 곳에만 머무르지 않고, 전체 문제 해결의 중심에 서 있는 역할인 만큼, UX에 대한 통합적 시야를 갖추게 됩니다. 그렇기에 장기적으로는 PO나 PM, 혹은 전략 기획자로의 성장도 가능하며 반대로 말하면, 본인이 그만큼 다양한 관점과 복잡한 이해관계를 조율할 준비가 되어 있어야 한다는 뜻이기도 하죠.
UX라는 목표를 위해 다양한 이름의 직무가 존재하는 시대입니다. 그중에서도 프로덕트 디자이너(d/D)는 그 UX 목표를 끝까지 책임지는 오너십을 가진 직무입니다. 멘티님의 질문처럼 ‘디자인(d)만’이 아니라 ‘문제 전체’에 관심을 두고 계신다면, 그 시작점은 이미 충분히 잘 잡고 계신 것이라 말씀드리고 싶습니다. 실무를 통해 감각을 익히고, 작게라도 책임을 져본 경험들을 통해 점점 더 확신을 얻게 되시길 바랍니다.