Product-Minded Engineer / 제품 중심 개발자 (번역)

원글: The Product-Minded Software Engineer by Gergely Orosz

The Product-Minded Software Engineer

Product-minded engineers are developers with lots of interest in the product itself. They want to understand why decisions are made, how people use the product, and love to be involved in making product decisions. They’re someone who would likely make a good product manager if they ever decide to gi…

The Pragmatic EngineerGergely Orosz

이 글은 우리 팀 CTO Will과의 1:1 미팅에서 개발자를 Frontend/Backend Engineer가 아닌 Product/Platform Engineer로 나누자는 글에 대해 이야기하는 중 Will이 추천해줘서 읽게 되었다.

지난 2021년 회고에서 Engineer가 아닌 Maker가 되겠다고 내 자신에게 선언(?)했는데, Maker는 넓은 개념이었기에 내 몸에 착 감기는 느낌이 없었지만, 비교적 최근에야 알게 된 Product Engineer는 내가 나중에 어떤 일을 하든 도움이 될 방향이라는 생각이 들었다.

그래서 읽는 김에 번역을 해보았다. (AI의 도움을 많이 받아서 😅)

Product-Minded Software Engineer

Product-Minded Software Engineer(이하 제품 중심 개발자)는 제품 자체에 큰 관심을 가지는 개발자들이다. 그들은 사람들이 제품을 어떻게 사용하는지 이해하려 하며 제품 관련 의사 결정에 참여하는 것을 즐긴다.

제품 중심 엔지니어는 훌륭한 PM이 될 가능성이 높다. 나는 이런 제품 중심 엔지니어들과 함께 일해왔고, 나 또한 제품 중심 개발자라고 생각한다.

Atlassian의 PM인 Sherif Mansour는 Product Engineer에 관한 훌륭한 글을 통해 어떻게 PM이 이러한 사람들을 식별하고 그들과 잘 협업할 수 있는지에 대해 이야기했다. 그의 결론은 다음과 같다.

"지난 10년간의 PM 경험을 통해서, 성공적인 제품을 만들고 더 나은 PM이 되기 위해서는 팀에 Product Engineer가 반드시 필요하다."

또한 Shopify의 head of engineering인 Jean-Michel Lemieux은 Product Engineer를 다음과 같이 정의했다.

"제품 기반을 다진 이후에는 기술을 사용하여 인간/사용자 문제를 돌파하는 엔지니어가 필요합니다. 마법 같은 경험을 찾으려는 열망이 있는 엔지니어입니다. 이것이 제 책에서 Product Engineer를 정의하는 것입니다. 나쁜 엔지니어들은 기술에만 너무 집중합니다. 훌륭한 Product Engineer들은 사랑받는 제품을 만들기 위해 제품 개발 과정에서 적절한 깊이로 개발해야 한다는 사실을 압니다."

제품 중심 개발자가 큰 영향을 미칠 수 있고 성장하기 좋은 환경은 사용자가 직접 사용하는 기능을 개발하고, PM과 협업하는 환경의 팀이다. 그들은 주요 기여자가 되며, PM이 급할 때 찾는 사람이 되고, 때로는 팀 리더가 되기도 한다.

그래서 제품 중심 개발자의 주요 특징은 무엇이며, 어떻게 제품 중심 개발자로 성장할 수 있을까? 이 글에서는 제품 중심 개발자의 9가지 특징과 제품 중심 개발자로 성장하는 방법에 대해 설명한다.

1. 적극적으로 제품 아이디어/의견 제시

제품 중심 개발자는 기획을 그대로 받아들이고 구현하기만 하는 것에 만족하지 않는다. 다른 아이디어를 생각하고 이를 PM에게 제안한다. 그들은 기존 기획에 도전하며 더 나은 접근 방식을 제안하기도 한다.

2. 비즈니스, 사용자 행동 및 데이터에 대한 관심

제품 중심 개발자는 뜬구름 잡는 아이디어를 제시하지 않고, 비즈니스가 어떻게 작동하는지, 제품이 어떤 역할을 하는지, 그리고 비즈니스와 제품의 목표가 무엇인지 이해하기 위해 시간을 투자한 후 아이디어를 제시한다.

또한 그들은 제품이 사용자에게 어떤 영향을 미치고 사용자들이 어떤 가치를 얻는지 파악하기 위해 비즈니스 및 사용자 데이터에 가능한 직접 접근하려 한다.

3. "Why?"

제품 중심 개발자는 모든 것의 "Why?"를 이해하려 한다. 왜 이 기능을 제품에 추가해야 하며 다른 것이 아닌 이유는 무엇일까? 왜 더 간단하게 구축할 수 있는 것을 선택하지 않을까? 왜 더 확실한 방법을 선택하지 않을까? 그리고 그들은 자율적으로 답을 찾아 나선다. 그들은 PM과 다른 팀원들에게 많은 질문을 하지만 사람들을 그들을 성가시다고 생각하지 않는다. 좋은 관계를 구축해왔기 때문이다.

4. 뛰어난 커뮤니케이션 능력 및 비개발자들과의 좋은 관계

제품 중심 개발자는 개발팀 외부의 사람들과 대화하는 것을 좋아하며, 다른 분야가 어떻게 작동하는지 자세히 알고 싶어한다. 그들은 원활한 커뮤니케이터로서 다른 분야의 작업 방식을 더 자세히 이해하기 위해 노력한다. 종종 비개발자와 커피를 마시거나 점심을 함께하거나 회의실에서 이야기를 나누기도 한다.

5. 프로젝트 초기에 제품/엔지니어링 트레이드오프 제공

제품 중심 개발자는 제품의 "Why"와 엔지니어링 측면을 모두 이해하기 때문에 다른 사람들이 할 수 없는 제안을 할 수 있다. 예를 들어 제품 개발 범위와 비용(시간)을 계산할 때, 대부분의 개발자들은 엔지니어링 노력을 줄이려고 시도하고 줄인 노력이 기능 자체에 미치는 영향을 파악하려고 한다.

하지만 제품 중심 개발자는 양방향으로 파악한다. 엔지니어링 tradeoffs와 제품 tradeoffs를 모두 고려하는 것이다. 그들은 PM에게 제품 영향은 비슷하지만 엔지니어링 노력은 훨씬 적은 완전히 다른 기능을 구축하도록 제안할 수 있다.

제품과 엔지니어링 각각의 영향을 손쉽게 파악하는 것은 제품 중심 개발자가 가지는 고유한 강점이다. 그들은 엔지니어링 및 제품 통찰력을 사용하여 빠르게 양쪽 면을 오가며 가치 있는 결론에 도달한다.

6. 실용적인 Edge Case 처리

개발자들은 종종 Edge Cases를 잊고, 제품을 테스트하거나 최종 사용자로부터 피드백을 받은 후에 처리하곤 한다. 그리고 새 제품이나 기능의 모든 가능한 Edge Cases를 처리하는 데 많은 시간이 걸리곤 한다.

하지만 제품 중심 개발자는 빠르게 Edge Cases를 떠올리고 처리 방법을 생각하며, 때로는 엔지니어링 작업을 필요로하지 않는 해결책을 제공하기도 한다. 그들은 사랑받을 수 있는 최소한의 제품 개념(minimum lovable product concept)에 중점을 두고 Edge Cases와 처리 비용을 평가한다.

예를 들어, 1000명 중 1명의 사용자가 오류를 겪을 수 있다면 그들은 이것을 고치는 비용을 고려하고, 고치지 않았을 때 어떤 일이 일어날지 생각한다. 고객 지원이 이 경우에 도움을 줄 수 있을까? 사용자는 다시 시도하고 다음 번에 성공할 수 있을까? 제품을 약간 수정하여 이러한 Edge Case가 발생하지 않게 할 수 있을까?

7. 빠른 제품 검증 주기

제품 중심 개발자는 작업 중인 기능의 개발이 완료되기 전에 초기 피드백을 얻는 창의적인 방법을 찾는다. 이것은 동료와 함께 테스트를 진행하거나, 진행 중인 작업 중에 제품 매니저에게 작업 중인 기능을 보여주거나, 베타 빌드에서 팀 bug bash를 조직하는 등 여러 가지 창의적인 방법일 수 있다. 그들은 계속해서 생각한다. 사람들이 이 기능을 우리가 생각한대로 사용하는지 확인하려면 어떻게 해야 할까?

8. End-to-end 제품 기능 오너십

대부분의 경험 많은 개발자들은 자신의 작업에 대해 end-to-end 오너십을 갖는다. 기획 명세를 받아들이고 구현하는 것에서 부터, 출시하고 올바르게 작동하는지 확인하는 것까지 모든 것이다. 그러나 제품 중심 개발자는 이보다 한 발 더 나아간다.

제품 중심 개발자들은 사용자 행동과 비즈니스 데이터를 얻은 후에만 작업이 완료되었다고 간주한다. 배포 이후에도 PM, 데이터 과학자 및 고객 지원 채널과 계속해서 소통하여 실제 세계에서 기능이 어떻게 사용되고 있는지 알아본다.

신뢰할 수 있는 데이터를 충분히 얻기까지 몇 주가 걸릴 수 있지만, 그들은 새로운 프로젝트에서 작업 중일지라도 결과를 확인하는 것을 최우선 순위 중 하나로 두고 일한다.

기대보다 성능이 나쁜 경우에는 일치하지 않았던 곳을 이해하려고 호기심을 가진다. 제품 계획과 실제 결과 간의 불일치 원인을 찾는 것뿐만 아니라 코드베이스에서 재현하기 어려운 버그를 디버깅하는 것에 대한 호기심이 있다.

9. 반복 학습을 통한 강력한 제품 직감력

제품 중심 개발자에게 프로젝트는 일반적으로 다음과 같이 진행된다.

• 이 기능이 왜 필요한지 정확히 이해하기 위해 많은 질문을 던진다.
• 이를 테스트하고 수정된 사양에 포함된 일부 제안을 가져온다.
• 빠르게 기능을 구축하고 피드백을 얻는다.
• 기능을 출시한 후에도 예상과 일치하는지 계속해서 확인한다.
• 예상과 달랐을 때, 결과를 깊이 파고들어 실제 세계에서의 제품 사용에 대해 새로운 것을 배운다.

각 프로젝트 이후, 제품 이해력이 깊어지고 더 나은 제품 직감력을 개발하기 시작한다. 시간이 흘러 프로젝트가 시작되기도 전에 상담을 받으려는 PM들의 요청이 늘어나면서 팀 밖에서 강한 평판을 쌓게 된다. 이 과정에서 제품 중심 개발자는 더 많은 커리어 성장 기회를 얻는다.

📌 제품 중심 개발자가 되기 위한 팁

사용자가 있는 제품을 개발하고 있다면, 제품 중심 마인드를 키우는 데 도움이 되는 몇 가지 팁이 있다. 이러한 팁은 제품 중심 개발자로 성장하는 데 효과적인 것으로 보인다.

• 회사가 성공하는 이유를 이해하기. 비즈니스 모델은 무엇인가? 어떻게 수익을 창출하나? 어떤 부분이 가장 이윤이 많으며 어떤 부분이 가장 확장되고 있나? 왜 그럴까?
• PM과 좋은 관계를 구축하기. 대부분의 PM은 개발자를 멘토링할 기회에 기뻐한다. 개발자들이 제품에 관심을 가지면 자신의 역량을 확장할 수 있다. 물론 제품 관련 질문을 많이 하기 전에 좋은 관계를 구축하고, PM에게 제품에 더 많이 관여하고 싶다고 분명히 전하는 것이 좋다.
• 사용자 리서치, CS 등 제품 작동 방식에 대해 자세히 알아보기. 디자이너, UX 디자이너, 데이터 과학자, 운영 팀 등, 사용자와 자주 상호 작용하는 사람들과 함께 작업한다.
• 타당한 제안 제시하기. 비즈니스, 제품 및 이해관계자에 대한 좋은 이해를 갖게된 후에는 제품 개발에 대한 이니셔티브를 가져갈 수 있다.
• 작업 중인 프로젝트에 대한 제품/엔지니어링 트레이드오프를 제공하기. 팀이 구축하려는 제품 기능에 대한 엔지니어링 트레이드오프뿐만 아니라 엔지니어링 노력을 줄일 수 있는 제품 트레이드오프도 제안한다. 그리고 이에 대한 피드백을 적극적으로 받는다.
• PM에게 피드백 자주 요청하기. 훌륭한 제품 중심 개발자가 되기 위해서는 기존의 엔지니어링 기술에 더해 제품 기술을 개발해야 한다. 제품 기술에 대한 당신의 성과를 어떻게 평가하는지 가장 잘 아는 사람은 PM이다. 제품 제안이 얼마나 가치 있는지에 대한 피드백을 얻고, 추가 성장을 위한 아이디어를 얻기 위해 PM에게 연락한다.

이 글만 보면 Product-Minded Software Engineer가 현실에 존재하는지 의문이 들 정도로, 제품 중심 개발자가 되는 길은 멀고도 험한 것 같다.

하지만 이 방향으로 꾸준히 노력하면, 내가 나중에 어떤 직업을 가지고 어떤 일을 하더라도 도움이 될 것 같다. 🙃 아자아자!