<div id="readability-page-1" class="page"><div><div aria-hidden="false"><a rel="noopener follow" href="/@totuworld?source=post_page---byline--0f5342f0ab53--------------------------------"><div><p><img alt="송요창" src="https://miro.medium.com/v2/resize:fill:88:88/1*nAMOvHeZTqTZjdz33jQ2Ag.jpeg" width="44" height="44" loading="lazy" data-testid="authorPhoto"></p></div></a></div><p id="9dab">Gergely Orosz가 작성한 <a href="https://blog.pragmaticengineer.com/the-product-minded-engineer/" rel="noopener ugc nofollow" target="_blank">The Product-Minded Software Engineer</a>란 글을 읽고 스스로 제품 중심 개발자(Product-Minded Software Engineer)라고 생각해왔다. 그런데 배민우리동네팀에서의 2년을 돌아보니 제품 중심 개발자로 성장하는 시간이었다.</p><h2 id="b57c">제품 중심 개발자란?</h2><p id="6ea2">Gergely가 정의하는 제품 중심 개발자의 특징은 다음과 같다.<br>* 제품 아이디어와 의견 제시 : 새로운 아이디어를 제시하고, 기존 계획에 도전하며 더 나은 접근 방식을 찾음.<br>* 비즈니스와 사용자 행동에 대한 관심 : 비즈니스와 사용자 행동에 깊은 관심을 가지고, 제품의 목표와 비즈니스 목표를 일치시킴.<br>* “왜?”에 대한 호기심 : 모든 것의 “왜?”를 이해하려고 노력하며, 끊임없이 질문함.<br>* 강력한 커뮤니케이션 능력: 동료와 원활한 소통을 중요시하며, 다른 부서와의 협력을 통해 제품 개발을 진행함.<br>* 데이터 기반 의사결정 : 데이터와 사용자 피드백을 기반으로 의사결정을 내림.<br>* End-to-end 책임감 : 제품의 초기 기획부터 출시 후 유지보수까지 모든 과정을 책임짐.<br>* 반복 학습과 개선: 반복적인 학습과 개선을 통해 제품의 품질을 지속적으로 향상시킴.</p><p id="c372">스스로를 “왜?”가 궁금하고, 커뮤니케이션이 능한 실행이 빠른 개발자라고 생각했기 때문에 제품 중심 개발자 인줄 알았다.</p><h2 id="36e3">비즈니스와 사용자의 행동에 대한 관심이 있었나?</h2><p id="8aae">제품을 만들 때 항상 비즈니스를 최우선한다고 생각했다. 그래서 빠르게 만들고, 테스트해서 결과를 봐야한다는 점에 동의한다. 지금까지 그래왔듯 빠르게 만들기 위해 기능을 작게 나누고, 필요한 부분을 선별하는데 힘을 쏟았다.</p><p id="7b7a">그런데 이 행동은 엄밀히 말하면 `제품 기능 명세`를 만족시키는 최소한의 기능을 구현하는데 집중한 것이지 비즈니스와 사용자의 행동에 대한 관심이 없는 행동이었다.</p><p id="eb44">정말 잘못 생각하고 있었다고 느낀게 `배민보이스데이`를 참석하고 부터 였다.</p><blockquote><p id="3a1f">배민보이스데이는 배달의민족 사용자가 특정 제품을 사용하는 모습을 관찰하고 질문할 수 있는 우아한형제들 사내 프로그램이다.</p></blockquote><p id="a22c">제품을 사용하는 사용자를 관찰하고, 행동을 기반으로 질문하는 과정에서 새롭게 발견한 사실이 많았다. 그리고 그 발견된 사실을 통해서 얼마나 잘못 생각하고 있었는지 깨달았다. 또 사용자가 어떤 부분을 탐색하는지 새롭게 알았다.</p><p id="9e29">이 경험 후에는 제품 기능 명세를 잘 만드는 게 아니라, 과연 사용자가 이를 통해서 어떤 문제를 해결할 수 있을지 함께 고민하는 시간이 늘었다. 기능을 배포하면 끝나는게 그게 어떤 효과를 내는지, 사용자에게 효과는 있는지 검토하는 시간까지 의미있게 바라보게 되었다.</p><p id="0eea">UX 리서치나 UT 결과를 서류로 받아보면 맥락은 사라진 결과만 보게 된다. 그런데 사용자를 직접 만나면 리서치를 통해서 알아내고자하는 맥락을 이해하고 관찰이 가능하다. 여기서 더 많은 통찰이 가능하다. 그리고 리서치나 테스트가 빼먹을 수 있는 부분도 발견할 수 있다. 제품을 지속적으로 개선해야하는 개발자에게 꼭 필요한 경험이다.</p><p id="7670">만약 이 글을 보는 우아한형제들 개발자가 있다면, 꼭 한번은 배민보이스데이를 참여해보시라.</p><figure></figure><h2 id="10e1">코드작성이란 안전구역 밖으로</h2><p id="2b46">우리팀은 워크샵을 자주 했다. 조직되는 시점에 정확한 미션이 없었기때문에 이를 정의하고 구체화된 실행방향을 찾기 위해 많은 논의를 했다. 얼마나 많았는지 떠올려보면 12년 경력 전체에서 한 워크샵보다 2년 동안 한 워크샵이 더 많았다.</p><p id="b055">기존에는 이게 개발자의 일이 아니라고 생각했다. 제품의 방향과 근거는 PM이나 협업 조직이 설정하고, 개발자는 이를 구현하는 사람이라고 생각하고 있었다. 그렇지만 우리팀은 개발자가 탐지하는 단계부터 참여하고, 플라이휠의 모든 부분에 어떻게 기여할 수 있는지 고민했다.</p><blockquote><p id="3c5e">배민우리동네 서비스에서 정의한 플라이휠은 `콘텐츠 수`가 많아야 `보는 재미`가 있고, `사용자가` 다시 방문. 그리고 사용자 수가 많아야 콘텐츠 수가 많아진다.</p></blockquote><p id="2486">참여할 때마다 많은 에너지가 들어가서 저절로 “제발 코딩이 하고 싶다”고 말하기도 했다. 돌이켜보니 이건 어린아이 투정에 불과했다.</p><p id="1e94">만약 우리팀이 초기 자금 얼마를 가진 창업팀이었다면, 생존을 걱정하며 함께 고민했어야했다. 거대한 회사 안에 움튼 작은 팀이니까 `나는 안전하다`고 믿는 아이같은 생각에 불과했다.</p><p id="b54d">이 아이같은 생각의 대표적인 예가 `배민 메인 홈에 진입점 노출`이란 생각이었다. 어디서 들어본적 없나? 어느 회사나 나오는 얘기일텐데 우리팀에서 일하면서 이 생각이 많이 바뀌었다.</p><p id="085e">2024년 배달의민족 메인 홈이 개편되면서 배민우리동네 서비스로의 진입점은 거의 보이지 않게되었다. 하지만 이대로 손 놓고 있을 순 없다.</p><p id="b18d">우리팀은 당시 `단골의 추천` 이란 기능을 만들었고, 사용자가 리뷰를 작성한 뒤에 `n번 이용한 단골` 이란 점을 강조하며 추천을 작성하도록 유도했다. 그리고 작성 완료 지면에 다른 사용자가 작성한 `단골의 추천`을 노출하여 서비스 지면으로 들어오도록 유도했다.</p><p id="9c72">그 결과 메인홈에서 유입되는 사용자보다 배민우리동네 서비스에 대한 관심도가 높은 사용자 방문이 늘었고, 적극 콘텐츠를 탐지하는 비율도 기존 대비 많이 늘어났다. `단골의 추천` 작성하는 비율은 포인트를 제공하지 않아도 40% 이상에 육박했다. 이는 우리 서비스 전체를 돌아봐도 유례를 찾을 수 없는 수치이다.</p><blockquote><p id="791a">리뷰 작성 비율은 포인트를 제공해도 이 보다 낮은 수치를 기록</p></blockquote><p id="b543">배달의민족 처럼 정확한 목적을 가지고 사용하는 서비스 안에서도 어딘가 사용자가 움직일만한 곳이 있다. 메인홈 노출만 주장할게 아니라 어딘가에서 기다리고 있는 사용자를 직접 찾아나서야한다.</p><h2 id="e0ee">사람이 전부다</h2><p id="2a42">돌아보니 2년이란 시간 동안 성장할 수 있었던 건 모두 함께 해준 동료들 덕분이다. 실수해도 함께 해결책을 찾아주고, 지지해준 동료들에게 이 자리를 빌어서 감사드린다. 그리고 우리의 수 많은 요구를 받아내준 디자이너분들 고생 많으셨습니다.</p><p id="b419">“혼자 가면 빨리 갈 수 있지만, 함께 가면 멀리 갈 수 있다”는 말처럼, 우리 팀은 늘 함께 고민하고 성장했다. 이런 팀의 일원이었다는 것이 자랑스럽다.</p><figure></figure></div></div>

Stories by 송요창 on Medium

totuworld

Gergely Orosz가 작성한 The Product-Minded Software Engineer란 글을 읽고 스스로 제품 중심 개발자(Product-Minded Software Engineer)라고 생각해왔다. 그런데 배민우리동네팀에서의 2년을 돌아보니 제품 중심 개발자로 성장하는 시간이었다.
제품 중심 개발자란?
Gergely가 정의하는 제품 중심 개발자의 특징은 다음과 같다.
* 제품 아이디어와 의견 제시 : 새로운 아이디어를 제시하고, 기존 계획에 도전하며 더 나은 접근 방식을 찾음.
* 비즈니스와 사용자 행동에 대한 관심 : 비즈니스와 사용자 행동에 깊은 관심을 가지고, 제품의 목표와 비즈니스 목표를 일치시킴.
* “왜?”에 대한 호기심 : 모든 것의 “왜?”를 이해하려고 노력하며, 끊임없이 질문함.
* 강력한 커뮤니케이션 능력: 동료와 원활한 소통을 중요시하며, 다른 부서와의 협력을 통해 제품 개발을 진행함.
* 데이터 기반 의사결정 : 데이터와 사용자 피드백을 기반으로 의사결정을 내림.
* End-to-end 책임감 : 제품의 초기 기획부터 출시 후 유지보수까지 모든 과정을 책임짐.
* 반복 학습과 개선: 반복적인 학습과 개선을 통해 제품의 품질을 지속적으로 향상시킴.
스스로를 “왜?”가 궁금하고, 커뮤니케이션이 능한 실행이 빠른 개발자라고 생각했기 때문에 제품 중심 개발자 인줄 알았다.
비즈니스와 사용자의 행동에 대한 관심이 있었나?
제품을 만들 때 항상 비즈니스를 최우선한다고 생각했다. 그래서 빠르게 만들고, 테스트해서 결과를 봐야한다는 점에 동의한다. 지금까지 그래왔듯 빠르게 만들기 위해 기능을 작게 나누고, 필요한 부분을 선별하는데 힘을 쏟았다.
그런데 이 행동은 엄밀히 말하면 `제품 기능 명세`를 만족시키는 최소한의 기능을 구현하는데 집중한 것이지 비즈니스와 사용자의 행동에 대한 관심이 없는 행동이었다.
정말 잘못 생각하고 있었다고 느낀게 `배민보이스데이`를 참석하고 부터 였다.
배민보이스데이는 배달의민족 사용자가 특정 제품을 사용하는 모습을 관찰하고 질문할 수 있는 우아한형제들 사내 프로그램이다.
제품을 사용하는 사용자를 관찰하고, 행동을 기반으로 질문하는 과정에서 새롭게 발견한 사실이 많았다. 그리고 그 발견된 사실을 통해서 얼마나 잘못 생각하고 있었는지 깨달았다. 또 사용자가 어떤 부분을 탐색하는지 새롭게 알았다.
이 경험 후에는 제품 기능 명세를 잘 만드는 게 아니라, 과연 사용자가 이를 통해서 어떤 문제를 해결할 수 있을지 함께 고민하는 시간이 늘었다. 기능을 배포하면 끝나는게 그게 어떤 효과를 내는지, 사용자에게 효과는 있는지 검토하는 시간까지 의미있게 바라보게 되었다.
UX 리서치나 UT 결과를 서류로 받아보면 맥락은 사라진 결과만 보게 된다. 그런데 사용자를 직접 만나면 리서치를 통해서 알아내고자하는 맥락을 이해하고 관찰이 가능하다. 여기서 더 많은 통찰이 가능하다. 그리고 리서치나 테스트가 빼먹을 수 있는 부분도 발견할 수 있다. 제품을 지속적으로 개선해야하는 개발자에게 꼭 필요한 경험이다.
만약 이 글을 보는 우아한형제들 개발자가 있다면, 꼭 한번은 배민보이스데이를 참여해보시라.
코드작성이란 안전구역 밖으로
우리팀은 워크샵을 자주 했다. 조직되는 시점에 정확한 미션이 없었기때문에 이를 정의하고 구체화된 실행방향을 찾기 위해 많은 논의를 했다. 얼마나 많았는지 떠올려보면 12년 경력 전체에서 한 워크샵보다 2년 동안 한 워크샵이 더 많았다.
기존에는 이게 개발자의 일이 아니라고 생각했다. 제품의 방향과 근거는 PM이나 협업 조직이 설정하고, 개발자는 이를 구현하는 사람이라고 생각하고 있었다. 그렇지만 우리팀은 개발자가 탐지하는 단계부터 참여하고, 플라이휠의 모든 부분에 어떻게 기여할 수 있는지 고민했다.
배민우리동네 서비스에서 정의한 플라이휠은 `콘텐츠 수`가 많아야 `보는 재미`가 있고, `사용자가` 다시 방문. 그리고 사용자 수가 많아야 콘텐츠 수가 많아진다.
참여할 때마다 많은 에너지가 들어가서 저절로 “제발 코딩이 하고 싶다”고 말하기도 했다. 돌이켜보니 이건 어린아이 투정에 불과했다.
만약 우리팀이 초기 자금 얼마를 가진 창업팀이었다면, 생존을 걱정하며 함께 고민했어야했다. 거대한 회사 안에 움튼 작은 팀이니까 `나는 안전하다`고 믿는 아이같은 생각에 불과했다.
이 아이같은 생각의 대표적인 예가 `배민 메인 홈에 진입점 노출`이란 생각이었다. 어디서 들어본적 없나? 어느 회사나 나오는 얘기일텐데 우리팀에서 일하면서 이 생각이 많이 바뀌었다.
2024년 배달의민족 메인 홈이 개편되면서 배민우리동네 서비스로의 진입점은 거의 보이지 않게되었다. 하지만 이대로 손 놓고 있을 순 없다.
우리팀은 당시 `단골의 추천` 이란 기능을 만들었고, 사용자가 리뷰를 작성한 뒤에 `n번 이용한 단골` 이란 점을 강조하며 추천을 작성하도록 유도했다. 그리고 작성 완료 지면에 다른 사용자가 작성한 `단골의 추천`을 노출하여 서비스 지면으로 들어오도록 유도했다.
그 결과 메인홈에서 유입되는 사용자보다 배민우리동네 서비스에 대한 관심도가 높은 사용자 방문이 늘었고, 적극 콘텐츠를 탐지하는 비율도 기존 대비 많이 늘어났다. `단골의 추천` 작성하는 비율은 포인트를 제공하지 않아도 40% 이상에 육박했다. 이는 우리 서비스 전체를 돌아봐도 유례를 찾을 수 없는 수치이다.
리뷰 작성 비율은 포인트를 제공해도 이 보다 낮은 수치를 기록
배달의민족 처럼 정확한 목적을 가지고 사용하는 서비스 안에서도 어딘가 사용자가 움직일만한 곳이 있다. 메인홈 노출만 주장할게 아니라 어딘가에서 기다리고 있는 사용자를 직접 찾아나서야한다.
사람이 전부다
돌아보니 2년이란 시간 동안 성장할 수 있었던 건 모두 함께 해준 동료들 덕분이다. 실수해도 함께 해결책을 찾아주고, 지지해준 동료들에게 이 자리를 빌어서 감사드린다. 그리고 우리의 수 많은 요구를 받아내준 디자이너분들 고생 많으셨습니다.
“혼자 가면 빨리 갈 수 있지만, 함께 가면 멀리 갈 수 있다”는 말처럼, 우리 팀은 늘 함께 고민하고 성장했다. 이런 팀의 일원이었다는 것이 자랑스럽다.

제품 중심 개발자로 변해간 배민우리동네팀 2년 회고

댓글