개발자는 왜 이제 ‘프로덕트 엔지니어’가 되어야 할까?

보이저엑스 이용욱 프로덕트 엔지니어 인터뷰

‘프로그래밍의 종말’, ‘프론트엔드 개발의 종말’은 요즘IT에서 높은 조회수를 기록한 글입니다. 자극적인 주제라고 생각하실 수 있지만, ChatGPT의 등장 이후 개발자들의 불안감이 커지고 있음을 알 수 있습니다. 앞으로 어떤 개발자가 살아남을지, 어떤 역량이 더 중요해질지를 두고도 다양한 논쟁이 이어지고 있죠.

그래서 주목받기 시작한 직무가 있습니다. 바로 '프로덕트 엔지니어(Product Engineer)'인데요. 프론트엔드, 백엔드, 풀스택처럼 기술 영역으로 구분되던 기존 개발자와 달리, 프로덕트 엔지니어는 ‘제품’의 전 과정을 폭넓게 이해하고 참여하는 개발자입니다. 단순히 기능을 구현하는 데 그치지 않고, 사용자를 직접 만나 문제를 정의하며, 기획과 디자인 단계에도 적극적으로 의견을 더합니다.

최근 ‘제품 중심’으로 일하는 조직이 늘어나면서, 프로덕트 엔지니어의 역할 역시 빠르게 확대되고 있죠. 이번 인터뷰에서는 ‘Vrew’, ‘vFlat’ 등 AI 서비스를 만드는 보이저엑스에서 프로덕트 엔지니어로 일하는 이용욱 님을 만났습니다. 그는 ‘VOC STUDIO’라는 VOC 분석 서비스를 처음부터 만들어온 5년 차 개발자인데요. 프로덕트 엔지니어는 실제로 어떤 일을 하고, 어떤 역량을 갖춰야 하는지 등 생생한 제품 개발 이야기를 들어봤습니다.

프로덕트 엔지니어의 ‘일’이란?

Q. 간단히 자기소개 부탁드립니다.

안녕하세요, 현재 보이저엑스에서 'VOC STUDIO'라는 VOC 분석 서비스를 만들고 있는 이용욱입니다. 근무한 지는 5년 정도 되었고, VOC STUDIO에는 처음부터 참여했고, 그전에는 'Vrew'라는 AI 영상 편집 서비스를 만들었습니다.

Q. 아직 국내엔 ‘프로덕트 엔지니어’가 흔하지 않은데요, 한 마디로 정의해 주신다면요?

“제품의 성장이 가장 중요한 엔지니어”라고 정의하고 싶어요. 통상적으로 개발자를 프론트엔드, 백엔드처럼 기술을 기준으로 정의하잖아요. 그런데 VOC STUDIO를 3명이서 처음 만들 땐 그런 경계를 나눌 수가 없었어요. 제품이 성장하지 않으면 지속할 수 없으니, 각자 잘하는 것만 할 수는 없었거든요.

그래서 개발자인 저희가 사용자를 직접 인터뷰하기도 하고, 프론트엔드를 하던 제가 LLM을 학습시키거나, 서버 구조를 짜기도 했죠. 저는 프론트엔드를 가장 잘하지만, 우리 제품이 사용자에게 더 많이 쓰이고, 사용자의 문제를 해결하는 게 더 중요하다고 생각했어요. 이렇게 기술보다 ‘제품 성장’을 우선시하는 게 프로덕트 엔지니어의 일이 아닐까 싶어요.

Q. 기존의 프론트엔드/백엔드 엔지니어, 혹은 프로덕트 매니저(PM)와 비교했을 때, 가장 큰 차이점은 무엇일까요?

앞서 말한 답변과도 비슷한데, 역할에 대한 정의가 다릅니다. 물론 프론트엔드/백엔드 엔지니어도 제품(서비스)의 성장을 위해 일하지만, "프론트엔드 개발자"라고 정의하는 순간, 서비스보다 기술이 그 직군의 정의에 먼저 오거든요. 사람은 기대에 부응하려고 하기 때문에, 이렇게 기술 중심으로 역할을 정의하면 점점 기술 쪽으로 치우치기 마련이에요. 반면, 프로덕트 엔지니어라고 하면, 이 직군에 가장 기대하는 게 ‘서비스를 성장시키는 것’이 되는 거죠. 거기서 차이가 생긴다고 생각합니다.

Q. 엔지니어로서 기술에만 치우치면, 오히려 한계가 있다고 보시나요?

저는 제품이 성장해야 기술적인 성장도 있는 거라고 봐요. 예를 들어, 제품 성장이 없는데 그냥 기술을 배우고 싶다고 도입하면, 문제 해결 능력이 느는 건 아니니까요. 일단 제품이 성장하다 보면, 자연스럽게 더 어려운 문제를 풀어나가는 능력을 배울 수 있죠.

특히 요즘은 AI 때문에 더 그렇게 느껴져요. 제가 몇 년을 투자해서 나갔던 코딩 대회를 ChatGPT가 훨씬 잘하는 걸 보면서도 생각했죠. 지난 3년 동안도 이 정도였는데, 3년 후에는 더 발전할 테니까요. 전문성을 필요로 하는 포지션은 당연히 있겠지만, 점점 그 파이는 작아질 거예요. 오히려 넓게, 자율적으로 책임을 가지고 일할 수 있는 엔지니어에 대한 수요가 더 늘어나겠죠. 앞으로는 수요와 공급이 제너럴리스트한테 좀 더 유리해지지 않을까 싶어요.

조직 속 ‘프로덕트 엔지니어’의 역할은?

Q. 그렇다면 보이저엑스에서 프로덕트 엔지니어는 어떤 일들을 하나요?

보이저엑스에서 가장 중요하게 여기는 건 '사용자'입니다. 사용자가 없으면 제품도, 팀도 없으니까요. 그래서 제품 개발도 사용자를 이해하는 것에서 시작합니다. 개발자들이 직접 사용자 문의에 대응하고 수치를 살펴보기도 하고, 사용자 팀에서 문의 사항이나 인터뷰를 정리해서 공유해 주기도 해요. 그러다 보면 이 문제를 내가 고치고 싶다거나, 이걸 해결해야 더 많은 사람들이 쓸 것 같다라는 생각이 들죠.

그럼 이제 문제를 구체적으로 정의하고, 근거를 모으고, 함께 해결할 사람들을 설득해서 기획과 개발을 시작합니다. 디자이너, 엔지니어, 기획자 등이 모여, 태스크포스가 결성되면 본격적으로 문제 해결 방법을 기획하죠. 여기서 프로덕트 엔지니어는 단순히 엔지니어링만 관여하는 게 아니라, 문제 정의부터 기획, UX까지 다양한 의견을 내고 참여해요.

Q. 직접 고객을 인터뷰한다고 하셨는데, 종종 사용자 의견과 실제 데이터 결과가 다른 경우도 있습니다. 이럴 때는 어떻게 하시나요?

사실 사용자들이 말하는 걸 그대로 받아들여 제품에 반영하면 실패하는 경우가 많습니다. 예를 들어, 한 사용자가 "A라는 기능 있었으면 좋겠어요"라고 했는데, 실제로 그분이 어떤 상황에 처했는지 보면, "이분은 A가 아니라 B가 필요했던 거네."라는 걸 발견할 때가 많아요. 그래서 사용자의 말을 그냥 말로만 받아들이지 말고, 깊게 이해하는 과정이 필요합니다. 실제 사용 케이스를 살펴보는 게 중요하죠.

Q. 실무에서는 주로 어떤 업무에 시간을 쓰시나요?

아무래도 제품 개발의 전체 사이클에 참여하다 보니, 시기마다 조금씩 다른데요. 그래도 개발에 가장 많은 시간을 쓰고 있습니다. 그 다음으로 고객 대응이나 미팅을 하죠. 저희 팀은 아직 작은 팀이다 보니, 고객 문의 대응, 도입 문의 미팅, 컨설팅 등을 프로덕트 엔지니어들이 직접 다니거든요. 물론 제가 내향형이라 힘들 때도 있지만, 사용자분들을 직접 만나 이야기를 듣는 게 도움이 될 때가 정말 많아요.

Q. 엔지니어로서 ‘사용자’를 직접 만나면서 느낀 점은요?

“사용자를 이해하는 일이 가장 중요하다”라는 걸 몸소 체험할 수 있었어요. 제 예상과 다른 경우가 정말 많았거든요. 예를 들어, 최근에 VOC 데이터를 차트로 구성해 주는 대시보드 기능을 출시했는데, 처음엔 기대치가 낮았어요. 엑셀에서도 만들 수 있다고 생각했거든요. 그런데 실제 사용자분들의 작업 흐름을 보니, VOC 데이터가 여러 곳에 흩어져 있어서 모으고 정리하는 것부터 엄청 고통스러운 일이더라고요. 데이터가 많다 보니 엑셀도 느려지고 에러가 계속 났어요.

저는 그동안 VOC 데이터를 다뤄본 적이 없으니 그 고통을 몰랐던 거죠. 이렇게 보통 자기중심적으로 해석할 때가 많은데, 사용자를 직접 만나 ‘진짜 문제’를 파악할 수 있게 됐어요. 사용자들의 고충을 직접 보면, '이거 빨리 개선해야겠다'라는 동기부여를 받거든요. 그리고 개선 후에 “너무 좋다”, “편리하다”라는 피드백을 들을 때 정말 뿌듯해지죠.

프로덕트 엔지니어가 되려면 어떤 ‘역량’이 필요할까?

Q. 프로덕트 엔지니어로 일하면서 가장 크게 요구된 역량은 무엇이었나요?

저는 아키텍처 설계나, 프론트엔드 같은 하드 스킬보다는 회복탄력성과 끈기가 가장 중요하다고 봐요. 많은 분들이 공감하시겠지만, 제품 개발은 그리 순탄하진 않거든요. 만약 제품이 100개 나온다고 하면, 그중 1~2개만 성공할까 말까죠. 우리가 잘 아는 피그마, 노션 같은 제품도 사실 수년간 시행착오를 겪고 빛을 본 거고, 보이저엑스도 수많은 제품이 출시 후 실패했거든요. 실패한 기능은 더 많고요.

처음에는 ‘출시하면 대박 날 거야’라며 개발하지만, 성공으로 가는 길은 정말 멀고 험난합니다. ‘VOC STUDIO’도 사용자가 모이지 않아, 제품을 접을 각오를 하고 개발했던 시기가 있거든요. 지금 가장 잘나가는 서비스 ‘Vrew’도 한때 그랬고요. 그러니 이런 시간이 있다는 걸 알고 인내하는 것, 그럼에도 계속 도전하는 게 프로덕트 엔지니어에게 가장 필요한 역량이라 생각해요. 또 어떤 특정 기술이 꼭 필요하다기보다는 빠르게 배우는 게 중요합니다. 최근에는 AI로 잘 모르는 분야도 쉽게 배울 수 있으니까요.

Q. 프로덕트 엔지니어로 빠르게 성장하려면 어떤 경험이 필요할까요?

기술적으로 빠르게 배우려면, 어떤 분야든 깊고 치열하게 공부했던 경험이 중요합니다. 저희 팀엔 철학을 공부하신 분도 있었고, 컴퓨터공학을 전공하지 않은 분들도 있어요. 그런데 빠르게 배우는 분들을 보면 다른 분야에서라도 한 번은 깊게 파본 경험이 있더라고요. 그런 경험이 있으면 새로운 분야를 만나도 어떻게 접근해야 할지 알게 되는 것 같습니다.

두 번째는 스스로 책임지고 결정하는 경험이에요. 제가 만약 팀장님이 시키는 대로만 했으면 크게 배우는 게 없었을 것 같아요. 보이저엑스에선 인턴에게도 서비스에 직접 영향을 주는 기능 개발도 맡기거든요. '이 기능은 이렇게 보여줘야겠다'라고 고민하고, 결정하면서 많이 배울 수 있었죠. 꼭 회사가 아니더라도, 깊게 배워본 경험과 책임지고 무언가를 결정해 본 경험이 쌓이면 빠르게 성장할 수 있다고 생각해요.

Q. 개발자뿐 아니라 기획자, 디자이너와도 협업해야 하는데, 이때 가장 중요한 건 뭘까요?

사실 직군은 크게 신경 쓰지 않고, 그냥 ‘제품을 잘 만들려면 어떻게 해야 할지’를 함께 고민해요. 저는 이게 ‘기술 기반 역할 정의’에서 오는 문제점이라고 생각해요. 자신을 ‘프론트엔드 개발자’, ‘UX 디자이너’, ‘서비스 기획자’라고 정의하면, 그 영역을 대표하는 셈이 되니까 의견 대립도 커지는 것 같아요. “이건 개발 공수가 너무 많이 들어서 안 돼요.”, “이 디자인은 미적으로 별로라 꼭 개선해야 해요.” 같은 대립이죠.

보이저엑스에서는 전 직군이 ‘제품 성장’을 가장 우선순위에 두기 때문에, 다른 직군과 협업할 때 어려운 점은 없어요. 대신 제품 성장에 빠른 릴리즈가 중요하면, 디자이너분들이 디테일한 요소는 생략해 주시기도 하고, 반대로 사용성에 중요한 작업이라면 기술적으로 까다로워도 개발자가 끝까지 해내는 식이죠.

‘AI’로 달라지는 프로덕트 개발 경험

Q. 최근 프로덕트 개발에 AI가 많이 쓰이고 있는데, 어떻게 활용하고 계신가요?
저희 팀은 커서(Cursor) 같은 AI 코드 어시스턴트를 적극적으로 쓰고 있어요. 덕분에 한 사람이 할 수 있는 일의 범위가 3배는 넓어졌습니다. 최근에 만든 ‘VOC 리서치’라는 AI 에이전트도 대부분 혼자 구현했는데, AI 도입되기 전이라면 상상도 할 수 없는 일이었을 겁니다. 이렇게 생산성이 높아지니까 팀 분위기도 달라졌어요. 예전엔 프론트엔드 개발자는 프론트엔드만, 백엔드 개발자는 백엔드만 했는데, 이제는 “프론트엔드도 제가 해볼게요”라며 도전하시더라고요. AI 덕분에 기술 영역의 경계가 옅어지고, 제품 중심으로 일하게 된 거죠.

Q. LLM과 AI 에이전트 기능을 직접 구현해 보기도 하셨는데, 어떠셨나요?

3년 전, 제품 초기에는 상담을 요약하는 LLM을 직접 학습시키고 평가했어요. 그때는 LLM 성능을 유지하면서 원하는 동작을 하도록 학습시키는 게 가장 어려웠죠. 그런데 최근에 만든 VOC 리서치 에이전트는 좀 달랐어요. ChatGPT API를 쓰니까 LLM 성능도 좋았고, 에이전트 구현도 프레임워크가 있어서 어렵지 않았거든요. 대신 사용자에게 무엇이 필요한지 알아내는 게 더 어려웠어요.

처음엔 데이터를 자동 분류해 주는 기능을 만들었는데 반응이 반반이었어요. ‘분류’는 주관적이라 AI 결과가 마음에 안 들면, 한 번 쓰고 쓰지 않더라고요. 그다음엔 대화로 개선할 수 있게 했는데, 이번엔 UX가 문제였죠. 저는 개발자니까 AI의 잠재력을 알지만, 사용자는 기능에 대한 설명이 부족하면 거기서 끝이었거든요. 그래서 정식 출시 때는 디자인에 신경 쓰고, AI가 무엇을 할 수 있는지 예시를 보여주니 반응이 훨씬 좋았어요. 결국 기술보다 사용자 이해가 더 중요하단 걸 다시 깨달았습니다.

Q. 그럼 앞으로 개발자에게 필요한 역량도 달라질까요?

앞으로는 기능 구현이 점점 빨라지면서 종합적인 역량이 더 중요해질 거예요. 더 이상 AI가 만든 코드를 일일이 확인하지 않는 시대가 오고 있죠. 저희 팀은 아직 코드를 검토하고 관리하지만, 그래도 개발 생산성이 빠르게 증가하고 있다는 건 체감해요. 기능을 구현하는 시간이 줄어드니 팀원들이 더 중요한 의사결정을 하고, 고객을 만나고, 문제를 정의하는데 더 많은 시간을 쓰게 됐죠. 아직 “AI는 이런 건 잘 못한다"는 지적도 많지만, ChatGPT가 나온 지 3년밖에 안 됐는데 벌써 이렇게 빠르게 바뀐 걸 생각하면, 결국 시간문제라고 생각합니다.

프로덕트 엔지니어가 그리는 다음 ‘커리어’

Q. 앞으로 프로덕트 엔지니어 직군은 더 늘어나게 될까요?

늘어나는 정도가 아니라, 곧 보편적인 개발자의 역할이 될 거라고 봅니다. 얼마 전, GPT-5가 국제 프로그래밍 대회 ICPC에서 인간 프로그래머들을 앞지르고 만점을 기록했고, 30시간 동안 혼자 코딩하는 Claude 4.5도 출시됐고요. 

결국 정답이 있는 분야에서는 사람이 AI를 이길 수 없을 거고, 개발이 그 첫 분야가 될 거예요. 그렇다면 사람들은 정답이 없는 분야로 가야 하죠. 문제를 발굴하고, 정의하고, 해결 방법을 제안하고, 동료와 소통하고, 사용자의 마음을 사는 일처럼요. 지금은 ‘프로덕트 엔지니어’라고 부르지만, 아마 모든 개발자가 이렇게 일하게 될 것 같아요.

Q. 그렇다면 개발자들은 어떤 준비를 하면 좋을까요?

우선 사용자에게 관심을 갖는 게 시작입니다. 저도 사실은 혼자 개발하는 게 더 재미있고 마음도 편하거든요. 하지만 결국 제품과 사용자가 있어야, 개발도 존재할 수 있으니까요. 그래서 내가 개발한 제품이 사용자를 더 행복하게 해주는지, 어떻게 해야 그렇게 할 수 있을지 충분히 고민해 보시면 좋겠어요.

그리고 일할 때 점점 더 많은 영역을 맡아보려고 시도해 보세요. 자기 영역이 아니더라도 "이렇게 하면 어떨까요?"라고 의견을 제시하면서, 영역을 조금씩 넓혀가는 거죠. 다만 일하는 환경도 중요해요. 의사결정을 전부 상급자가 하거나, 개발자와 기획자의 역할이 엄격히 구분된 곳에서는 혼자 이런 역량을 키우기 쉽지 않거든요. 회사를 고를 때 채용 공고(JD)에서 개발자더라도 넓은 범위를 담당하고, 책임지는 역할이 적혀있는지 확인해 보세요. "목적 중심으로 일해요", "작은 스쿼드로 나눠져서 일해요" 같은 표현이 나오면 기회가 주어질 확률이 높아요.

Q. 앞으로 어떤 목표를 갖고 계신가요?

VOC STUDIO를 3년 전부터 아이디어 단계부터 시행착오를 거치며 만들었고, 이제는 뗄 수 없는 관계가 된 것 같아요. 그래서 VOC STUDIO가 CX 매니저들이 VOC를 분석할 때 가장 처음으로 쓰이는 툴이 됐으면 합니다. 또 스케일이 더 큰 문제에 도전해 보고 싶어서, 저희 제품이 미국에도 진출하는 글로벌 제품이 되는 게 목표입니다.

이번 인터뷰를 통해 느낀 건, 프로덕트 엔지니어는 단순히 새로 생겨난 직무가 아니라, 개발자의 다음 단계였다는 점인데요. 무엇보다 ‘제품 성장’이 먼저라는 이 엔지니어의 말처럼, 사용자의 문제에 먼저 다가가려는 적극적인 자세가 점점 더 중요해지고 있습니다. 

AI가 몇 초 만에 뚝딱 코드를 만들어내는 시대, 우리에게 필요한 진짜 경쟁력은 사용자를 이해하고 문제를 스스로 정의할 수 있는 능력 아닐까요?

*현재 보이저엑스는 전 분야에서 적극적으로 채용을 진행하고 있습니다. 관심 있는 분들은 [채용 공고]를 확인해 보세요.

김소희 에디터 sohee@wishket.com

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.