AI시대에 필요한 개발자, Product Engineer

생성형 AI의 등장은 기존 개발 업무를 빠른 속도로 변화시키고 있습니다. 어느새 코파일럿(copilot)과 함께 코드를 짜고, 문제가 발생하면 스택오버플로(stack overflow)가 아닌 chatGPT에게 물어봅니다.

편하긴 하지만 쓸 때마다 위기감을 느끼곤 합니다. 원하는 것만 정확히 얘기해주면 맥락을 파악해서 정확한 비즈니스 로직을 몇 분 만에 만들어 냅니다. 이렇게 AI가 버그도 잡아주고 코드도 대신 짜주는 세상에서 우리 개발자들은 어떻게 살아남을 수 있을까요?

저는 프로덕트 중심으로 사고하고 개발하는 개발자가 끝까지 살아남을 수 있다고 생각합니다. 이번 글에서는 프로덕트 엔지니어가 무엇인지, 왜 프로덕트 엔지니어가 살아남는지 그 이유에 대해 한번 알아보겠습니다.

바뀌고 있는 채용 트렌드

AI가 발전하면서 어지간한 비즈니스 로직은 요구사항만 명확하면 바로 코드로 받을 수 있습니다.

구현뿐만아니라 개발과정에서 맞닥뜨리는 수많은 에러 처리를 대부분 해결해줍니다. 비즈니스 인사이더에 따르면 GPT-4 출시 이후 스택오버플로우의 트래픽이 약 13% 감소했다고 합니다. 많은 개발자들이 AI를 활용해 문제해결을 한다는 증거라고 생각할 수 있죠.

일하는 방식에서도 큰 변화가 있었지만, 이런 변화의 흐름은 채용시장에도 영향을 미치는 것으로 보입니다. 하나의 서비스를 만들고 운영하려면 개발직군에서도 다양한 포지션이 필요하죠. 크게 프론트엔드와 백엔드로 나누고 서비스 규모나 특성에 따라 더 세분화하기도 합니다. 이와 같은 이유로 채용도 포지션별로 진행하는데요.

근래 채용 공고에 조금씩 특이한 공고들이 보이고 있습니다. 아래처럼 요즘 채용공고에서는 간혹 소프트웨어 엔지니어(Software Engineer)나 프로덕트 엔지니어(Product Engineer)라는 포지션들이 보입니다.

이 공고를 한번 살펴볼까요? 프로덕트 엔지니어 포지션을 채용한다고 나와있습니다. 역할을 살펴보면 서비스의 고객 인입부터 구매까지 전 과정에서 임팩트를 줄 수 있는 다양한 기능들을 만들고 그 과정을 주도한다고하네요.

단순히 “특정 프로그래밍 언어와 프레임워크로 어떤 서비스의 유지 보수나 기능 개발을 한다”식의 기존 채용공고와는 느낌이 다릅니다.

가장 큰 차이는 비즈니스 전과정에 주도적으로 참여한다는 것인데요. 이 부분을 좀 더 깊이 고민해보면 개발자를 단순히 코드를 생산해내는 사람이 아니라 비즈니스 측면의 성과를 내고 실제 문제를 해결하는 사람이라는 관점으로 보고 있다는 사실을 알 수 있습니다.

다음 채용공고를 볼까요? 영어교육으로 유명한 튜터링 서비스 채용공고인데요. 포지션은 소프트웨어 엔지니어입니다. 프론트엔드냐 백엔드냐는 나와있지 않은데요. 공고를 좀 더 자세히 살펴보면 이유가 있습니다.

기술스택에서 주목할 점은 Next.js와 Supabase입니다. Next.js는 최근 핫하게 떠오르고있는 프론트엔드 프레임워크인데요. 간단한 서비스의 경우 프론트엔드와 백엔드 모두 커버할 수 있는 풀스택 프레임워크입니다. Supabase 역시 백엔드 개발 생산성을 압도적으로 높여주는 SaaS 서비스이죠. Supabase를 활용하면 DB 설계와 REST API 개발 생산성을 압도적으로 높일 수 있습니다.

이 둘을 조합해서 사용하면 어지간한 규모의 서비스를 1명의 개발자가 만들 수 있습니다. 인프라 관리나 API 개발 같은 부분들을 SaaS에서 모두 지원해주기 때문에 개발자가 프로덕트 자체에 집중할 수 있게 도와주죠.

AI 기술과 더욱 빠르게 발전하는 SaaS 서비스로 인해 기업 입장에서 각 분야별 특화된 개발자들을 고용할 이유가 점점 줄어들게 될 것이라 생각합니다. 이제는 프로덕트의 사용성이나 안정성은 AI나 SaaS 서비스에 맡기고, 프로덕트의 시장성을 얼마나 빠르게 실험하고 다듬어 나가는지에 따라 성공이 판가름 나기 때문입니다.

위의 채용공고들은 그 서막이라고 생각합니다.

프로덕트 엔지니어란?

그럼 이런 흐름 속에서도 살아남는 개발자는 어떤 개발자일까요? 저는 이 대답의 힌트가 채용공고 속에 있다고 생각하는데요. 자세히 살펴보면 빠르게 발전하는 기업들이 어떤 것을 원하는지 엿볼 수 있습니다.

바로 프로덕트를 잘 만드는 개발자. 단순히 코드를 생산하는 코더가 아니라 고객 유입부터 여정을 거쳐 실제 수익이 날 때까지 전 과정에서의 문제를 해결하는 사람이 새로운 흐름의 주인공이 될 것이라 생각합니다.

쇼피파이의 전CTO 장 미셸 르뮤(Jean-Michel Lemieux)는 프로덕트 엔지니어를 다음과 같이 정의했습니다.

"제품 기반을 다진 이후에는 기술을 사용하여 인간/사용자 문제를 돌파하는 엔지니어가 필요합니다. 마법 같은 경험을 찾으려는 열망이 있는 엔지니어입니다. 이것이 제 책에서 설명한 프로덕트 엔지니어의 정의입니다. 안 좋은 엔지니어들은 기술에만 너무 집중합니다. 훌륭한 프로덕트 엔지니어들은 사랑받는 제품을 만들기 위해 제품 개발 과정에서 트레이드오프(trade-off)를 고려해 적절한 깊이로 개발해야 한다는 사실을 압니다."

저 역시 그의 생각에 전적으로 동의합니다. ChatGPT, 코파일럿, 그리고 수많은 SaaS 서비스들은 개발 생산성 측면에서 압도적인 성과를 보여줍니다. 하지만 아직 이 도구들로는 고객들이 정확히 무엇을 원하는지 파악하기 어렵죠. 수많은 가설들을 검증하고 프로덕트 자체를 매력적으로 개발해나가는 과정은 아직 개발자들의 손을 직접 거쳐야 가능합니다.

결국 프로덕트 엔지니어는 기술에 매몰되지 않고, 고객들의 문제를 정의하며 기술로 이를 해결해나가는 사람입니다. 어떻게 보면 창업가와 굉장히 비슷한데요. 이런 프로덕트 중심적 사고가 가능한 개발자가 앞으로도 계속 살아남을 수 있다고 생각합니다.

왜 프로덕트 엔지니어일까요?

프로덕트 엔지니어란 어떤 사고를 개발자인지 알아보았는데요. 그럼 왜 자꾸 프로덕트 중심으로 사고해야 한다고 강조하는 걸까요? 그 이유를 개발자와 기업 측면에서 각각 살펴보겠습니다.

PM 혹은 C-Level로 올라가기 유리하다

개발자라면 누구나 연차가 쌓이면서 하는 고민이 있죠. 바로 커리어 패스 갈림길에 대한 것인데요. 실무를 계속하고 프로젝트 경험이 쌓이게 되면 어느 순간 회사에서는 팀을 맡아 이끌어주기를 원합니다. 이건 단순히 프로그래밍을 잘한다고 할 수 있는 영역이 아니죠. 개발자를 비롯해 기획자, 디자이너, 데이터 사이언티스트 등 다양한 역할의 팀원들을 하나로 만들고, 목표를 달성할 수 있도록 끊임없이 소통하며 조율해나가야 합니다.

그럼 이들을 어떻게 하나로 만들 수 있을까요? 그 중심에는 바로 프로덕트가 있습니다. 프로덕트 중심으로 사고해야 기획자의 말을 조금이라도 더 이해할 수 있고, 디자이너가 왜 이렇게 디자인했는지 이해할 수 있습니다. 데이터 사이언티스트의 분석을 듣고 앞으로 선택과 집중을 할 방향을 정할 수 있고요. 즉, 코드 레벨이 아니라 전체를 보는 눈을 가지게 됩니다. 프로덕트 중심으로 사고할 수 있게 되면요. 나무가 아니라 숲을 보는 사람이 되는 것이죠. 이것은 완전히 다른 레벨의 일입니다. 단순히 프로그래밍을 해서 돌아가는 소프트웨어를 만드는 것이 아니라, 사람들이 진짜 좋아하는 사랑받는 프로덕트를 만들 수 있는 시야를 가지게 되는 것입니다.

당연히도 이런 사람은 드물고요. 회사에서는 이런 사람에게 팀을 맡깁니다. 이런 사람들의 포지션이 주로 PM이나 PO(Product Owner)가 되는 것이죠. 여기에서 더 성과를 내거나 더 큰 조직을 맡을 수 있게 되면 C-Level로 가게 되는 것입니다.

기업에서 원하는 사람은 결국 문제를 해결하는 사람

기업의 목적은 무엇일까요? 바로 이윤 추구입니다. 고객들의 문제를 프로덕트를 통해 해결해주고 그에 따른 댓가를 받는 것이죠. 그럼 기업이 원하는 인재는 바로 이윤추구에 직접적, 간접적으로 큰 영향을 주는 사람이라고 볼 수 있겠죠.

단순하게 말하면, 고객의 수를 늘리고, 프로덕트의 가치를 높여 더 합리적이고 높은 비용으로 제공할 수 있으면 기업의 이윤은 늘어납니다. 이 과정에 이르기까지 수많은 문제들이 존재하겠죠. 이런 문제들은 대개 복잡하고 복합적입니다. 단순히 개발을 할 수 있다고 해결할 수 있는 문제가 아닙니다. 넓은 시야와 틀에 갇히지 않는 문제해결 능력으로 이를 해결할 수 있다면, 그 사람의 가치는 회사 입장에서 값을 매길 수 없을 만큼 중요해지겠죠.

반면, 기획서의 내용을 코드로 짜기만 하는 사람, 관리 차원의 단순 반복 업무만 하는 개발자는 어떨까요? 지금 당장은 서비스 운영에 필요하기 때문에 일자리가 있을지도 모릅니다. 하지만 무서운 속도로 발전하는 AI와 SaaS 서비스에 의해 언제 대체될지 모르죠. 기업 입장에서는 똑같은 결과물을 더 낮은 비용으로 해결할 수 있다면 이것보다 더 반가운 소식은 없을 테니까요.

프로덕트 엔지니어가 되기 위한 3가지 원칙

이제 프로덕트 엔지니어가 되기 위한 3가지 원칙에 대해서 알아보겠습니다. 프로덕트 엔지니어가 되기 위해 특정 기술을 공부해야 한다거나, 자격증을 따야 하는 것은 아닙니다. 그렇게 한다고 될 수 있는 것도 아니고요.

일을 할 때 사고의 흐름을 바꿔야 합니다. 더 넓게 봐야 하고 더 많은 분야에 관심을 가져야 합니다. 실무에 적용도 반드시 해봐야 하고요. 가장 기본이 되는 3가지 원칙을 기억하고 하나씩 실천하다 보면 분명히 큰 성장의 기회를 잡을 수 있을 것이라 생각합니다.

1) 프로덕트의 전 과정에 관심가지기

기획부터 디자인 그리고 개발에 이르기까지. 프로덕트의 전 과정에 Why?라는 질문을 던지며 적극적으로 탐구하는 자세를 가져야 합니다. 그 누구보다도 프로덕트의 열성 사용자가 되어야 하고요. 단순히 개발 레벨에서의 임팩트가 아니라, 실제 이 프로덕트를 사용할 고객의 관점에서 생각할 수 있어야 합니다.

따라서, 고객이 최초로 프로덕트와 접촉하는 시점부터, 사용하고 익숙해지고 떠나기까지의 전 과정을 살펴볼 마음가짐을 가지고 있어야 하죠. 그 과정에서 고객을 이해하는 데 필요한 지식은 언제든 배우고 습득할 수 있어야 합니다.

저의 경우는 사이드 프로젝트를 런칭하며 프로덕트 기획부터 디자인, 개발 그리고 마케팅까지 전 영역을 경험할 수 있었습니다. 경험의 결과로 운 좋게 수익을 얻기도 했지만, 가장 값진 것은 전 과정을 직접 경험해봤다는 것인데요. 그 과정에서 정말 많은 것들을 얻을 수 있었습니다. 마케팅을 어떻게 하는지 몰라 SNS 마케팅 강의를 듣기도 했고요. 직접 부딪히며 하루종일 SNS를 붙잡고 살면서 출시한 앱 서비스를 1만 다운로드까지 달성하는 경험을 하기도 했습니다. 디자인 퀄리티는 조악하지만 Adobe XD와 Zeplin을 사용하는 방법도 배웠고요. 서비스를 런칭하기 전에 미리 마케팅 플랜부터 짜 놓아야 한다는 사실도 경험에서 배웠습니다.

이런 경험은 실무에서도 확실히 큰 영향을 미칩니다. 신규 기능을 개발한다면, 어떻게 개발할지부터가 아니라 고객에게 어떤 임팩트를 줄 수 있을 것인지부터 생각하게 되고요. 기획과 디자인 과정에서도 적극적으로 의견을 낼 수 있게 됩니다. 또, 어떻게 고객을 더 데려올 수 있을지 카피라이팅도 팀과 함께 고민하기도 하죠.

모든 영역에서 전문가가 될 수는 없습니다. 어떤 분들은 자신의 전문성을 잃을까 두려우실 수도 있어요. 하지만 저는 전 과정에 참여하고, 각 분야의 전문가들과 소통하면서 프로덕트를 이끌어 나갈 수 있는 것도 충분히 전문 영역이라고 생각합니다.

2) Over Engineering은 금물

지금까지 많은 개발자분들과 협업하면서 가장 곤란한 때가 바로 오버 엔지니어링(Over Engineering)을 한다고 판단됐을 때인데요. 지금 당장 빠르게 가설과 실험을 통해 시장성을 검증해야 하는 상황인데도 코드 레벨의 설계와 유지보수성을 높이는 방향만 고민하는 경우 꽤 답답함을 느끼곤 합니다.

물론 코드의 안정성과 유지보수성을 높이는 것은 매우 중요합니다. 하지만 개발 속도와 유지보수성은 확실히 트레이드오프 관계에 있어요. 두 마리 토끼를 다 잡을 수는 없는 노릇이죠. 만약 팀의 리소스를 엄청나게 써서 유지보수성이 높은 설계와 디자인 패턴을 적용한 코드를 만들었다고 가정해보죠. 이 기능을 런칭했을 때 고객들의 반응이 생각한 것과 달라서 기능을 내리게 되면요? 팀 입장에서는 상당한 손해입니다. 그 리소스를 다른 가설을 검증하는 데 썼을 수도 있을 테니까요.

프로덕트 엔지니어라면 이 두가지 요소 사이에서 최선의 선택을 할 수 있도록 노력해야 합니다. 빠르게 시장성을 검증을 해야 하는 상황인지, 아니면 좀 더 멀리 내다보고 코드의 안정성과 유보수성을 높일 것인지 말이죠. 오버 엔지니어링에 대한 기준을 잡기는 너무 어렵습니다. 그때 그때마다, 기업의 상황마다 어떤 것을 우선으로 생각해야 하는지 다 다르기 때문이죠. 이런 판단을 잘 하기 위해서는 지금 내가 하는 일의 중요도와 고객 입장에서 어떤 효과가 있을지를 종합적으로 판단할 수 있어야 합니다. 개발을 하면서 앞으로는 내가 지금하는 판단이 오버엔지니어링이 아닐지 끊임없이 질문해보세요. 그리고 고민한 내용을 팀과 공유해보세요. 그럼 점점 더 상황에 맞는 좋은 판단을 할 수 있게 됩니다.

3) 하드스킬과 소프트 스킬의 밸런스

보통 하드스킬이라 하면 업무와 직접적으로 관련이 있는 능력, 소프트 스킬은 그 외 팀으로 일하기 위해 필요한 능력을 얘기하는데요. 프로덕트 엔지니어라면 이 둘의 밸런스가 정말 중요하다고 생각합니다. 특히 협업을 위한 커뮤니케이션 능력이 상당히 좋아야 하는데요. 그도 그럴 것이, 각 파트의 담당자들과 끊임없이 소통하고 배우고 자신의 의견을 제시할 수 있어야 하기 때문이죠.

프로그래밍 능력이 압도적이어도 프로덕트를 구성하는 다른 파트의 담당자들과 소통이 힘들고 혼자만 일하는 사람이라면 절대 프로덕트 엔지니어가 될 수 없습니다. 당연히 팀을 이끄는 것도 힘들겠죠. 프로그래밍 능력을 키우는 것도 중요하지만, 좀 더 쉽게 상대방에게 설명하는 방법, 내가 원하는 바, 의미하는 바를 더 명확하고 간결하게 전달하는 능력을 키우는 것이 저는 더 중요하다고 생각합니다.

커뮤니케이션 능력을 키울 수 있는 좋은 방법은 역시 글쓰기라고 생각합니다. 블로그, SNS 등 꾸준히 글쓰기를 해보시면 확실히 달라지는 것을 느낄 수 있어요. 저의 경우 블로그를 계속 운영해왔고 최근에는 SNS에 게시글을 작성하는데요. 글을 쓰면 쓸수록 관련 내용이 머릿속으로 정리되는 게 느껴집니다. 이런 활동들이 꾸준히 쌓이게 되면 점점 커뮤니케이션 능력이 발전하는 것이죠.

마치며

지금까지 프로덕트 엔지니어란 무엇인지, 왜 앞으로 살아남을 수 있는지에 대해 설명했습니다. 추가로, 프로덕트 엔지니어가 되기 위해 지켜야 할 3가지 원칙도 설명드렸는데요. 저는 개발자가 단순히 코드를 생산하는 사람이 아니라고 생각합니다. 개발자의 본질은 문제를 해결하는 사람이라고 봐요. 그런 의미에서 코드 레벨에서만 자신의 기술력을 높이기보다는 좀 더 영역을 확장해서 프로덕트 자체를 더 발전시킬 수 있어야 진짜 개발자라는 생각이 듭니다. 기술의 엄청난 발전 속에서도 여전히 인간만이 해결할 수 있는 영역이 있다고 봅니다. 프로덕트 엔지니어가 되는 것은 그 영역에 발을 내딛는 것이라고 생각해요.

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