이 글의 원문은 당근 팀 블로그 ‘프로덕트에 진심인 엔지니어는 어떻게 일할까? ① - 서비스 성장이 최우선, 프로덕트 엔지니어의 사고방식’에서 확인할 수 있습니다.

이번 글에서는 이런 내용을 확인할 수 있어요! ☑️

• 엔지니어가 프로덕트 관점의 사고방식을 가져야 하는 이유
• 프로덕트 성장에 걸림돌이 되는 엔지니어의 사고방식
• 프로덕트의 여러 문제를 효율적으로 해결하기 위한 결정 기준

이런 분들에게 도움이 돼요! ‍🙋

• 엔지니어로서 어떻게 프로덕트 성장에 더 기여할 수 있을까? 궁금한 분
• 프로덕트 관점에서 문제들의 우선순위를 결정하는 방법을 알고 싶은 분
• 프로덕트의 성공을 최우선 과제로 삼는 팀 문화를 고민하는 분

안녕하세요. 당근알바팀 Frontend Engineer로 일하고 있는 Kit이에요. 혹시 프로덕트 엔지니어라는 말 들어보셨나요? 프론트엔드, 백엔드는 흔하지만 프로덕트 엔지니어는 조금 생소할 수도 있을 텐데요. 프로덕트 엔지니어는 서비스 성장을 최우선으로 두고, 프로덕트적인 관점에서 사고하는 엔지니어를 말해요. 저는 3년 전 당근알바팀에 처음 합류하면서, 프로덕트 엔지니어들은 어떻게 일하는지 직접 경험해 볼 수 있었는데요. 앞으로 두 편의 글을 통해 이들이 일하는 방식을 소개해 드리려고 해요. 

제 코드는 엉망이에요

제가 입사했을 때 들었던 말 중에 아직까지도 기억에 남는 말이 하나 있어요. 바로 “제 코드는 엉망이에요”라는 동료 Steve의 말이에요. 당근에서 코드를 잘 작성하기로 유명한 Steve의 코드가 부족한 점이 있다니, 그럴 리가 없다고 생각했어요. 겸손의 표현이겠거니 했죠.

신기한 건 3년이 지난 지금, 새로 팀에 합류한 동료에게 제가 같은 말을 하고 있다는 거예요. Steve와 마찬가지로 말이죠. 그런데 직접 말해 보니 그건 짐작했던 것과 달리 비관도 겸손도 아니었어요. 오히려 프로덕트에 진심인 엔지니어의 마음에서 우러나온 말이었죠.

당근의 엔지니어들은 어떻게 일하길래 Steve와 제가 이런 말을 하게 됐을지 궁금하지 않으세요? 아래 글에서 프로덕트 엔지니어들이 어떻게 생각하고 결정하는지 설명해 드릴게요. 그리고 이어지는 다음 편에서 프로덕트 엔지니어들이 어떻게 행동하고 회고하고 협업하는지까지 모두 읽게 된다면, 스티브와 제 말에 담긴 숨은 의미를 이해할 수 있을 거예요.

Step 1. 프로덕트 관점에서 생각하기: 걸리기 쉬운 사고의 함정

프로덕트 관점에서 생각한다는 건 뭘까요? 프로덕트의 생존과 성장을 최우선적인 목표로 삼고, 사용자 경험을 빠르게 개선할 방법을 찾아야 한다는 뜻일 거예요. 서로 다른 직무와 성향을 가진 구성원들이 프로덕트 관점의 사고방식을 공유하면, 팀과 개인의 목표를 더 쉽게 정렬할 수 있어요. 같은 프레임워크 안에서 움직이기 때문에 소통 비용이 줄어들고 실행 속도가 빨라지죠. 의견이 달라도 프로덕트를 중심에 두고 협의가 원활해지는 거예요.

프로덕트 관점의 사고방식을 어떻게 업무에 적용해야 하는지는 팀마다 의견이 조금씩 다를 수 있어요. 그러나 프로덕트 중심적이지 않은 사고방식에 대해서는 어떤 팀이든 비슷한 의견을 가지고 있더라고요. 그런 측면에서 이번에는 프로덕트를 개발할 때 엔지니어들이 가장 자주 빠지는 사고의 함정을 살펴볼게요.

사고의 함정: “나 개발 잘해”

엔지니어가 프로덕트에 가장 크게 기여하는 방법은 무엇일까요? 대부분의 사람들이 완벽한 기술적 완성도로 기능을 구현하는 것이라고 생각할 거예요. 저도 한때 그랬고요. 그런데 그런 생각을 가지면 PM이나 프로덕트 디자이너가 “사용자에게 이런 경험이 필요해요”라고 제안했을 때, “이런 부분은 기술적으로 빠르게 구현하기 어려워요”라고 방어적으로 대응하게 될 가능성이 있어요. 코드의 가독성, 사이드 이펙트, 재사용성 등 이것저것 따지며 기술적 완성도에 욕심을 부리면, 작업 스펙이나 기술 스택이 변경되어 작업 시간을 지연시킬 수도 있는 거죠.

당근알바팀에는 “나 개발 잘해”가 아니라 “프로덕트의 생존과 성공보다 더 큰 포트폴리오는 없어”라고 생각하는 엔지니어들이 모여있어요. 기술적으로 복잡해 당장 구현할 수 있을지 고민되는 기능이더라도, 오히려 엔지니어들이 나서서 “사용자에게 그만한 가치가 있다면 기간 안에 어떻게든 구현해 볼게요”라고 먼저 제안할 때가 많죠. 흠잡을 곳 없이 개발해야 한다는 직무적 욕심보다는, 프로덕트의 성공을 위해 빠르게 구현되어야 할 필요성을 더 중요하게 생각하는 거예요.

사례를 하나 들어볼게요. 최근에 사용자가 앱에 접속할 때마다 사용자 피드에 이벤트 게시물을 일정 간격으로 중복 없이 랜덤하게 노출시켜 달라는 요구사항을 받았어요. 기술적으로 굉장히 도전적인 작업인데, 심지어 시간이 촉박하기까지 했죠. 스펙을 빼자고 해도 이상하지 않은 상황이었지만, 백엔드 엔지니어인 Mark와 짧은 시간 안에 임의정렬 알고리즘을 구현했어요. 이 알고리즘은 기술적 한계를 가지고 있지만, 의도했던 사용자 경험을 문제없이 제공해요. 예를 들어 사용자가 곧바로 앱을 재접속하면 직전과 동일한 순서로 정렬된 이벤트 게시물을 볼 수도 있어요. 하지만 대부분의 사용자는 어느 정도 시간차를 두고 앱을 재접속하기 때문에 게시물이 매번 랜덤으로 배치된다고 느낄 거예요.

아마 모든 요구사항을 기술적으로 완벽하게 만족시키려 했다면, 주어진 시간 안에 절대로 완성하지 못했을 거예요. 저희는 이렇게 사용자 경험을 위해 기술적 완성도를 타협하지, 기술적 완성도를 위해 사용자 경험을 타협하지 않아요. 사용자를 위해 필요하다면 한 번밖에 사용하지 못할 코드라도 우선 작성해요. 사용자에게 빠르게 가치를 전달한 후, 뒤에서 더 안정적이고 지속가능한 기술적 구조를 만들어 나가죠. 저희 팀의 엔지니어들은 다들 엔지니어링 역량에 대한 자부심이 있지만, 그 역량을 적절하게 사용하는 데 더 큰 자부심을 느껴요.

프로덕트 관점으로 생각하는 데 익숙해졌다면, 그 다음은 프로덕트 관점에서 팀이 마주한 문제의 중요성을 결정해야 해요. 프로덕트의 성장을 최우선의 목표로 문제들의 우선순위를 정렬하는 방법이 더 궁금하다면, 💡어바웃당근 블로그에서 지금 바로 콘텐츠 전문을 확인해보세요!