불과 몇 년 전만 해도 프론트엔드와 백엔드는 명확히 구분된 영역이었다. 리액트(React), 뷰(Vue), 앵귤러(Angular) 같은 프론트엔드 프레임워크가 급속도로 발전하면서, 프론트엔드 개발자는 UI와 사용자 경험(UX)에 집중하고, 백엔드 개발자는 서버와 데이터 관리를 책임지는 역할로 나뉘는 것이 일반적이었다.
하지만 기술이 발전하면서 이러한 경계는 점점 흐려지기 시작했다. 특히, ChatGPT와 같은 AI 기술의 등장으로 개발 패러다임 자체가 바뀌기 시작했다. 코드 작성의 효율성이 극대화되면서, 문제를 정의하고 해결하는 능력이 더욱 중요해졌다. 여기에 Next.js의 API Routes 기능과 같은 기술이 발전하면서, 프론트엔드 개발자가 간단한 서버 로직을 다룰 수 있는 환경도 마련되었다. 이제는 프론트엔드와 백엔드를 따로 구분하기보다, 전체적인 제품 개발을 이해하고 문제를 해결할 수 있는 "풀스택 개발자" 혹은 "프러덕트 엔지니어(Product Engineer)"를 원하는 기업이 늘어나고 있다.
이러한 변화를 마주하면서, 나 또한 "프론트엔드 개발자"라는 역할에만 머물러 있어도 괜찮을까?" 하는 고민이 들기 시작했다. 점점 더 많은 기업이 단순한 UI 개발이 아니라, "사용자의 문제를 정의하고, 이를 기술로 해결할 수 있는 개발자"를 원하고 있었다. 단순한 기능 구현을 넘어, 문제를 발견하고 해결하는 능력을 갖춘 개발자가 되는것이 중요해 질것이라는 생각이 들었다.
Product Engineer란 무엇인가?
프러덕트 엔지니어(Product Engineer)는 단순히 기능을 구현하는 개발자가 아니다. 사용자의 문제를 정의하고, 이를 기술적으로 해결하는 개발자다. 무엇을 만들 것인지 고민하기 전에, 왜 만들어야 하는지부터 생각하는 태도가 중요하다.
어떤 일을 할 때 "이걸 왜 하는가?"를 고민하지 않으면, 프로젝트가 진행될수록 방향이 흔들리고 금방 지치게 된다. 처음에는 좋은 아이디어 같아도, 문제의 본질이 명확하지 않으면 지속하기 어렵다. 그래서 단순한 기능 구현이 아니라, 문제를 제대로 정의하는 과정이 중요하다.
PEC의 8주 과정에서도 코드 작성은 마지막 단계에 배치된다. 기술보다 문제 정의가 먼저이기 때문이다. 특히 1주차에서는 단순히 "이게 불편하니까 만들어야겠다"가 아니라, 이게 정말 문제인지, 해결했을 때 사용자에게 어떤 변화를 줄 수 있는지 깊이 고민하는 시간을 갖는다.
결국, 기술은 문제를 해결하는 도구일 뿐, 가장 중요한 것은 해결해야 할 문제를 제대로 정의하는 것이다. 이런 사고방식이야말로 프러덕트 엔지니어가 갖춰야 할 가장 중요한 역량이라고 생각한다.
골든 서클(Golden Circle)과 문제 정의
문제를 찾는 과정에서 가장 중요하게 다뤄진 개념이 골든 서클(Golden Circle)이다. 이는 문제 해결을 위한 체계적이고 지속 가능한 의사결정 원칙으로, 단순히 "무엇을 만들 것인가?"가 아니라, "왜 만들어야 하는가?"부터 고민하는 방식이다.
골든 서클이란?
- WHY – 왜 문제를 해결해야 하는가?
- HOW – 어떤 방법으로 해결할 것인가?
- WHAT – 무엇을 만들 것인가?
골든 서클 적용 방식
일반적인 접근
"우리는 강력한 배터리를 가진 스마트폰을 만들었습니다. 화면이 크고 성능이 뛰어납니다."
골든 서클 접근
"우리는 사람들의 일상을 더 자유롭게 만들고 싶습니다. 그래서 배터리 걱정 없이 온종일 사용할 수 있도록 만들었고, 누구나 편리하게 쓸 수 있도록 디자인했습니다. 이제, 강력한 배터리를 가진 스마트폰이 탄생했습니다."
많은 사람들이 사이드 프로젝트를 시작할 때 WHAT에서 출발한다. "이런 기능이 있으면 좋겠다"라는 생각으로 시작하지만, WHY 없이 진행하면 방향성을 잃고 프로젝트가 흐지부지되기 쉽다.
그래서 PEC 1주차에서는 단순히 "무엇을 만들 것인가?"가 아니라, "왜 이걸 만들어야 하는가?"에 대한 깊은 고민을 하는 시간을 갖는다. WHY가 명확해야 HOW와 WHAT도 탄탄해진다.
사용자 인터뷰의 중요성
그렇다면, 이런 WHY을 어떻게 찾아 낼 수 있을까? 어떤 문제가 존재하는지, 사용자들이 무엇을 불편해하는지 먼저 파악하는 과정이 필요하다. 그리고 이를 알아내는 가장 효과적인 방법이 바로 "사용자 인터뷰"다.
1주 차 교안에서는 사용자 인터뷰와 개발의 관계에 대해 다루고 있었다.
대충 정리하자면, 아래와 같이 요약할 수 있다.
-
사용자 인터뷰란?
- 사용자의 실제 경험을 듣고 문제점을 파악하는 과정
- 단순한 의견 청취가 아니라, 사용자의 행동과 심리를 분석하는 과정
-
사용자 인터뷰가 개발에 기여하는 점
- 사용자 중심의 제품 설계 가능
- 사용성 테스트를 통해 UI/UX 개선
- 데이터 기반 의사결정 가능
- 접근성 문제 해결
처음에는 "사용자 인터뷰가 Product Engineer와 무슨 관련이 있을까?"라는 의문이 들었다. "문제를 정의하라"라고 하지만, 이미 수많은 서비스를 사용하고 있는 입장에서 어떤 문제를 찾아야 할지 감이 잡히지 않았다.
"내가 불편함을 느끼지 않는다고 해서, 모든 사람이 불편함이 없는 것은 아니다."
내가 겪지 못한 불편함이 존재할 수도 있고, 실제 사용자들은 전혀 다른 시각에서 불편함을 느낄 수도 있다.
결국, 사용자 인터뷰는 문제를 발견하는 과정이며, 이를 통해 무엇을 해결해야 할지 명확히 정의하는 것이 중요하다고 깨닫게 되었다.
WHY를 찾는 과정
처음에 만들고 싶은 서비스가 없었지만, 아이디어가 많은분이 계셨다. 그래서 그분의 아이디어를 기반으로 주제를 선정했다.
선정된 주제: "프로폴리오"
네트워킹 자리에서 자기소개가 어려운 사람들을 위해, 짧은 시간 안에 자신의 개성과 특징을 효과적으로 전달할 수 있도록 돕는 서비스.
이를 구체화하기 위해 반구조화된 사용자 인터뷰 질문지를 먼저 작성했다.
반구조화된 사용자 인터뷰
반구조화된 인터뷰는 기본적인 질문을 준비하되, 사용자의 응답에 따라 추가 질문을 하며 더 깊이 있는 통찰을 얻는 방식이다. 즉, 미리 정해진 틀에 따라 진행하는 것이 아니라, 사용자의 반응과 답변을 바탕으로 대화를 확장해 나가는 과정이다.
아래는 교안에서 설명하는 반구조화 인터뷰의 개념이다.
인터뷰에서 가장 중요한 두 가지 요소
- 공감
- 사용자는 본인이 어떤 문제를 가지고 있는지조차 인지하지 못하는 경우가 많다. 따라서 인터뷰어가 사용자의 입장에서 공감하며 이야기를 이끌어가는 것이 중요하다.
- 유도 질문을 지양해야 한다
- 이미 머릿속으로 서비스에 대한 그림을 그려둔 상태에서, 원하는 답을 이끌어내기 위한 "답정너"식 질문을 던지면 안 된다. 이렇게 되면 인터뷰 결과가 편향될 수 있고, 다양한 시각을 반영하기 어려워진다. 결국, 많은 인터뷰의 답변이 비슷해지는 문제가 발생할 수 있다.
인터뷰 구성
- 기본 질문 (Ice Breaking)
- 사용자가 긴장을 풀고 편안하게 대화할 수 있도록 간단한 질문을 던진다.
- 현재의 경험과 상황
- 네트워킹이나 자기소개 경험에 대해 질문하며, 사용자의 기존 행동 패턴을 파악한다.
- 문제와 필요
- 사용자가 겪고 있는 불편함과 어려움을 탐색한다.
- 서비스 기대와 피드백
- 이런 서비스가 있다면 실제로 사용할지, 어떤 기능이 필요할지 논의한다.
- 추가 질문
- 인터뷰어가 자유롭게 질문하며, 사용자가 더욱 깊은 의견을 제시할 수 있도록 유도한다.
사용자 인터뷰를 진행하면서 깨달은 점은, 사용자는 본인이 겪고 있는 문제를 명확하게 인식하지 못한다는 것이다. 그렇기 때문에, 인터뷰를 통해 사용자의 내면에 숨겨진 니즈를 끌어내는 과정이 무엇보다 중요하다.
아래는 위에서 설명한 내용을 기반으로 작성한 인터뷰지이다.
이렇게 각자의 인터뷰지를 완성하면, 하나의 인터뷰지로 통일하는 과정을 거치고, 아래의 인터뷰지를 통해, 사용자 인터뷰를 진행한다.
인터뷰 결과 요약
인터뷰를 진행하며 얻은 주요 응답을 정리하면, 다음과 같은 문제점과 니즈가 도출되었다.
- 네트워킹 자리에서 구두로만 자기소개를 하다 보니, 상대방이 자신을 제대로 이해하지 못하는 경우가 많았다.
- 소셜 프로필을 작성하는 과정이 번거롭고 어렵게 느껴졌다.
- 자기소개를 간편하게 정리해주는 프로필이 있다면, 네트워킹이 훨씬 수월해질 것 같았다.
- 키워드를 활용해 자신의 개성을 표현할 수 있는 기능이 있으면 좋겠다는 의견이 많았다.
- 상황에 따라 다르게 활용할 수 있도록, 공식적인 자리와 사적인 자리를 구분할 수 있는 멀티 프로필 기능이 필요하다고 느꼈다.
이러한 피드백을 통해, 단순한 프로필 생성이 아니라 자신을 효과적으로 표현하고, 상황에 맞게 활용할 수 있는 시스템이 필요함을 확인할 수 있었다.
페르소나(Persona) 작성
인터뷰 데이터를 바탕으로 가상의 사용자 페르소나를 작성했다. 페르소나는 특정 타겟 사용자의 행동과 니즈를 정리한 것으로, WHY와 HOW를 구체화하는 데 도움을 주는 도구다. 이를 통해 사용자의 실제 고민과 기대를 보다 명확하게 파악할 수 있다.
페르소나 구성 요소
- 행동(Actions) – 사용자가 현재 어떤 방식으로 문제를 해결하고 있는가?
- 동기(Motivations) – 무엇이 사용자를 움직이게 하는가?
- 문제(Pains) – 사용자가 겪고 있는 어려움은 무엇인가?
- 가치(Values) – 사용자가 제품에서 중요하게 여기는 요소는 무엇인가?
각자의 인터뷰 데이터를 바탕으로, 다음과 같은 페르소나를 정리하는 과정을 거쳤다.
이 과정을 통해, 단순한 기능 개발이 아니라 사용자의 실질적인 문제를 해결할 수 있는 방향으로 서비스의 핵심을 구체화할 수 있었다.
마무리
1주 차 세션을 통해, 단순히 "무엇을 만들까?"에서 출발하는 것이 아니라, WHY를 정의하는 것이 얼마나 중요한지 배울 수 있었다. 그리고 그 WHY를 찾기 위해서는 사용자 인터뷰가 필수적이라는 점을 깨닫게 되었다.
이번 주차에서는 사용자 인터뷰를 통해 문제를 찾아내고, 이를 바탕으로 하나의 페르소나를 완성하는 과정을 거쳤다. 이 과정에서 가장 중요한 점은 인터뷰어의 마음가짐이었다. 사용자의 눈높이에서 문제를 바라보고, 공감하는 자세를 갖는 것, 그리고 답정너식 질문을 지양하며 열린 대화를 유도하는 것이 핵심이었다.
다음 주차에서는 이 페르소나를 기반으로 서비스를 구체화하는 과정을 다룰 예정이다.
참고한글
- WHW(Why? How? What? 골든 서클 이론
- 페르소나 정하는데도 데이터가 필요한가요?
- PEC 1주차 교안 및 Miro
0개의 댓글
관련 채용 정보
