프로덕트에 진심인 엔지니어는 어떻게 일할까? ①

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

제 코드는 엉망이에요

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

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

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

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

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

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

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

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

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

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

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

Step 2. 프로덕트 관점에서 결정하기: 무엇이 중요한 문제일까?

프로덕트 관점으로 생각하는 데 익숙해진 후부터는 프로덕트 관점에서 무엇이 중요한 문제인지 결정할 수 있는 단계로 넘어가야 해요. 기본적인 문제 해결을 위한 마인드셋을 갖췄다면, 그다음으로는 다양한 문제들 중 무엇을 가장 먼저 해결해야 하는지, 문제를 잘 정의하는 레벨로 성장할 수 있어야 하는 건데요. 이번에는 저희 팀에서 어떤 기준을 가지고 문제의 중요도를 결정하고 어떻게 집중할 수 있었는지 소개해 드릴게요.

첫 번째 기준: OKR에 집중해요

엔지니어라면 기술 부채 청산, 최신 기술 도입, 코드 구조 개선과 같은 기술적 과제들을 늘 마주하게 되는데요. 이런 작업들도 기술적 완성도를 높이기 위해 필요하긴 하지만, 모든 걸 하나하나 상시적으로 챙기다 보면 OKR과 직접적으로 관련된 업무에는 소홀해지기 마련이에요. 프로덕트 엔지니어라면 팀이 마주한 여러 문제를 효율적으로 해결하기 위해 기술을 전략적으로 다뤄야 해요. OKR과 관련된 중요도 높은 문제 해결에 더 집중해야 한다는 거죠.

당근알바 팀에서는 우선순위가 높은 업무를 전략적으로 다루기 위해 분기별로 ‘폴리싱 위크(Polishing Week)’를 운영해요. 한 분기가 끝나는 마지막 1~2주 동안 기술적 완성도를 높이기 위한 작업들을 해요. OKR과 관련이 크지 않은 사용자 경험 개선을 몰아서 진행하는 거죠. 폴리싱 위크 덕분에 평소에는 OKR 달성을 위한 핵심 문제 해결에만 전념할 수 있어요. 폴리싱 위크가 없었다면 핵심 목표와 거리가 먼 기술적 문제들에 시간을 많이 소모하게 되고, 여러 작업을 동시에 처리하면서 생기는 비용도 컸을 거예요. 

물론 분기 중에도 새로운 기술 도입이 필요하거나 특정 모듈의 코드 구조를 개선해야 할 때가 생겨요. 일반적으로는 폴리싱 위크에 봐야 할 업무지만, 그 일이 사용자의 문제를 해결하기 위해 시급하다거나 OKR과 명확히 연결된다면 분기 중이라도 당연히 작업해요. 중요한 건 프로덕트 관점에서 중요한 문제들에 집중하기 위해 기술을 전략적으로 활용하려는 의도니까요.

두 번째 기준: 급하지 않은 문제는 지금 풀지 않아요

프로덕트의 성장과 목표를 고려할 때 시급하지 않은 문제들이라면, 과감히 다음 분기로 미룰 수도 있어야 해요. 모든 문제가 아닌, 프로덕트의 가치를 크게 훼손하는 중요한 문제에 먼저 집중하는 거죠. 시간을 계속 투자하면 해결 못할 문제는 없겠지만, 그럴 만한 가치를 가진 문제는 적어요. 어떤 문제를 얼마나 풀 것인지 시간을 전략적으로 배분하는 게 중요해요. 급하지 않은 문제들은 조용히 백로그에 쌓아두는 것만으로도, 불필요한 소통이나 설득 비용을 줄이고 팀원들의 생산성을 높일 수 있어요. 

당근알바 팀 프론트엔드 엔지니어들은 주기적으로 미팅을 진행하는데요. 이 미팅에서는 “이 문제를 꼭 이번 분기에 풀어야 할까요?”와 같은 질문들을 많이 던져요. 어떤 문제들을 안고 갈 것인지 논의하는 거죠. 저희 팀은 프로젝트 관리 소프트웨어 Jira의 우선순위를 엄격히 적용해서 “Priority가 Low인 문제는 이번 분기에 해결하지 않는다”는 규약을 디자인 단계부터 가져가요. 팀의 핵심 과제를 체계적으로 정리하고 속도를 높일 수 있도록 말이죠.

예를 들어 사용자 경험을 개선할 때를 생각해 볼까요. 예전이라면 모든 기능의 온갖 디테일을 챙겼겠지만, 지금은 당근알바에서 중요도가 높은 핵심 액션인 ‘공고 작성하기’와 ‘지원하기’ 이벤트를 더 중점적으로 살펴봐요. 최근에도 구인자가 특정 상황에서 공고 작성이 제한될 때, 문제를 즉각적으로 해결해 주는 대신 문제를 해결할 수 있는 페이지로 넘겨주는 Indirect CTA만 제공된다는 사실을 발견했어요. 현재는 사용자의 문제를 해결할 기술적 수단이 많아진 상황이라, 모두 Direct CTA로 바꾸기를 제안했죠. 우선순위를 기준으로 팀 내에서 공감대가 빠르게 형성되니 속도감 있게 적용할 수 있었어요.

결론적으로 프로덕트 엔지니어들의 사고방식과 결정 기준을 한마디로 요약해 본다면, “프로덕트의 성장을 최우선으로 둔다”는 거예요. 프로덕트의 성장을 위해 기술적 완성도에 대한 과한 욕심을 버리고, 팀의 핵심 목표 달성과 빠른 속도에 집중하는 거죠. 

이런 사고방식과 결정 기준을 가진 프로덕트 엔지니어들이 나아가 어떻게 행동하고 회고하는지, 또 다른 팀원들과는 어떻게 협업하는지는 다음 글에서 더 본격적으로 나눠보려고 해요. 그 이야기들이 궁금하다면 이어지는 다음 글을 확인해 주세요!