2026 당근 Builder Meetup, Product Day 참여후기
들어가며
지난 9월 15일, 2026 당근 Builder Meetup에 다녀왔습니다. 4,300만 명 이상이 가입한 서비스를 만드는 당근 팀이 이미 해결한 문제부터 지금 풀고 있는 문제까지, 그 과정과 고민을 공유하는 자리입니다.
최근 저는 혈압 관리 서비스인 모비닥 환자앱을 개발하며 “사용자가 모비닥으로 혈압을 꾸준히 기록하게 하려면 무엇이 필요할까?”에 집중하고 있는데요. 이번에 참여한 Product Engineering Day에서는 “당근포인트, PM 없이 성장하기”, “기획, 개발, 디자인 다 한다고 프로덕트 엔지니어일까?”처럼 개발자가 AI를 활용해 직접 서비스 문제를 정의하고 풀어 온 경험을 들을 수 있었습니다. 그 경험들 속에서 지금 고민에 적용해 볼 만한 인사이트를 얻을 수 있었습니다.
제가 참여한 세션을 이 글의 세 가지 이야기로 묶으면 다음과 같습니다.
이번 글에서는 저에게 가장 인상 깊었던 세 가지 인사이트를 나눠보려고 합니다.
- 빠르게 만들되, 사용자가 다시 돌아올 이유를 찾기
- 문제를 직접 이해하고, 작은 근거로 설득하기
- AI로 직군의 경계를 넘나드는 환경 만들기
1. 빠르게 만들되, 사용자가 다시 돌아올 이유를 찾기
한 번 서비스를 쓴 사용자가 다시 돌아오게 하려면 무엇이 필요할까요? 이 질문에 대한 힌트를 얻기 위해 “하드코딩에서 플랫폼까지, 현장결제 실험루프” 세션에 참석했습니다. 당근페이 현장결제는 동네 가게에서 당근 앱의 QR로 결제하는 서비스로, 팀은 지난 1년 동안 결제 시장의 후발 주자로서 어떻게 하면 사용자가 당근페이를 쓰고 또 쓰게 할지 실험해 왔습니다.
저는 많은 사용자에게 안정적으로 서비스를 제공하려면, 처음부터 재사용할 수 있게 구조를 잘 추상화하고 확장성까지 고려한 코드로 시작했을 거라고 생각했습니다. 하지만 현장결제팀은 실험 속도를 위해 제휴 기능 일부를 의도적으로 하드코딩하는 것을 선택했습니다. 그리고 나중에서야 계속 쓸 기능이라고 확인되거나 반복적으로 비용이 들 때, 그 부분을 자동화하거나 플랫폼으로 이동시켰습니다. PMF와 BM 세션에서도 같은 맥락의 이야기를 했는데, 초기에는 코드의 완성도보다 사용자에게 줄 가치를 확인하는 일을 먼저 둔다는 점이 두 팀 모두 같았습니다.
매장에 노출을 늘린 다음, 팀이 결제를 늘리기 위해 선택한 방법은 프로모션이었습니다. 타임딜, 할인, 결제 쿠폰처럼 혜택을 바꿔 가며 실험했고 결제 횟수도 늘었습니다. 하지만 혜택이 끝나면 한 번 쓰고 떠나는 사용자가 대부분이었고, 월 4회 이상 결제하는 사용자는 5%도 되지 않았습니다.
팀은 숫자를 더 뜯어보며 다시 오는 사용자의 공통점을 찾았습니다. 첫 결제 후 7일 안에 한 번 더 결제한 사용자는 60일 안에 다시 결제한 비율이 61.5%였고, 그렇지 않은 사용자는 20.9%였습니다. 첫 결제 직후의 두 번째 결제가 습관으로 이어지는 신호였던 것입니다. 문제는 그 두 번째 결제를 혜택만으로 계속 만들기는 어렵다는 점이었습니다. 혜택을 더 올리는 것 말고 다른 동기가 필요했던 팀은, 결제를 게임처럼 재미있게 만들면 다시 오지 않을까 판단했습니다. 그래서 결제할 때마다 어항 아이템을 모으는 게임을 만들었습니다.
결과는 팀의 기대와 달랐습니다. 아이템만 받는 1, 2회차에서는 다음 결제로 넘어오는 비율이 30% 안팎에 머물렀고, 실제 혜택이 가까워지는 3, 4회차에서야 55%, 75%로 올랐습니다. 4회를 모두 채운 비율도 기대했던 20%에 한참 못 미치는 3.53%였습니다. 즉, 사용자는 게임이 재미있어서가 아니라 끝에 받을 혜택 때문에 결제했던 것입니다.
팀은 게임 요소를 덜어내고 2주 단위 스탬프로 바꿨습니다. 이벤트 참여율은 34%에서 88%로 올랐지만, 재결제율은 2.7%p 오르는 데 그쳤습니다. 참여는 늘었어도 혜택 없이 다시 올 이유까지 만든 것은 아니었습니다. 팀은 성공을 “프로모션으로 오른 결제량이 아니라, 혜택이 끝나도 다시 꺼내는 사용자”로 정의하고 있습니다. 하지만 아직 첫 결제의 95%는 여전히 프로모션에서 나오고 있고, 팀은 혜택 없이도 다시 올 가치를 찾기 위해 실험을 계속 이어가고 있습니다.
모비닥에서도 첫 기록 뒤 일주일 안에 두 번째 기록이 있었는지가 이후 기록 습관으로 이어질지 보여주는 신호가 될 수 있습니다. 그리고 현장결제팀처럼, 두 번째 혈압 기록을 혜택이 아니라 환자에게 줄 수 있는 어떤 가치로 만들지가 저에게 남은 문제입니다.
오프닝 키노트에서는 알림이 사용자의 의도를 다음 행동으로 나아가게 한다고 설명했습니다. 혈압 기록은 앱에서 버튼을 누르기 전에 기기 앞에 가서 측정하는 일이 먼저입니다. 그래서 첫 기록에서 다음 측정과 기록까지 이어지도록 돕는 흐름과, 알림 같은 보완 장치가 있는지 살펴보려 합니다.
그리고 꾸준히 쌓인 혈압 기록을 병원 진료에서 쓸 수 있게 하고, 환자가 몰랐던 자신의 건강 상태를 알게 해 준다면, 그것이 혜택 없이도 다시 기록할 이유가 될 수 있는지 가설을 세우고 빠르게 실험해 보려 합니다.
2. 문제를 직접 이해하고, 작은 근거로 설득하기
가설을 세우겠다고 했지만, 무엇을 근거로 삼고 어떻게 확인할지는 또 다른 문제입니다. 저는 사용자가 원하는 것을 알려면 사용자 인터뷰가 가장 중요하다고 막연히 생각해 왔습니다. 그런데 이번 Meetup에서 만난 당근 개발자들은 인터뷰보다 먼저, 스스로 사용자가 되고 있었습니다.
엔지니어로 시작해 지금은 당근모임, 당근아파트 같은 제품을 이끄는 리더들은 패널토크에서 내가 만든 제품을 직접 써 보는 “개밥먹기” 문화를 강조했습니다. “기획, 개발, 디자인 다 한다고 프로덕트 엔지니어일까?” 세션에서도 “문제는 내 문제를 풀 때 제일 잘 풀린다”며, 회사의 문제를 내 문제로 만드는 과정을 보여 주었습니다.
네트워킹 시간에는 현장결제팀에 문제 정의를 사용자 인터뷰로 하는지, 데이터로 하는지 따로 여쭤보았습니다. 인터뷰도 해 봤지만 사용자가 속마음을 잘 말해 주지 않아 정확한 이유를 찾기 어려웠고, 그래서 데이터에서 빈틈을 찾아 가설을 세우는 방식으로 시작한다는 답을 들었습니다.
이 이야기를 들으며, 제품을 만드는 저 스스로가 문제에 가장 가까운 사용자라는 걸 다시 생각하게 됐습니다. 그래서 저부터 불편함 없이 쓰는 서비스를 만들고, 그다음 팀을 만족시키고, 그 뒤에 사용자 인터뷰로 넓혀 가는 순서로 해 보려 합니다. 저로부터 시작한 기능이라도 배포한 뒤에는 데이터가 의미 있게 변하는지 보며 가설을 검증하려 합니다.
문제를 찾았다면 그다음은 함께 일하는 팀을 설득하는 일입니다. “당근포인트, PM 없이 성장하기” 세션에서는, 이벤트 보상으로 주던 당근머니의 47.5%가 계좌로 빠져나가는 걸 보고 당근 안에서만 쓸 수 있는 포인트로 바꾸려던 팀이 겪은 설득의 어려움을 들을 수 있었습니다.
첫 제안은 “유저들이 머니를 좋아한다”는 이유로 거절됐습니다. 그래서 팀은 머니는 절반가량이 밖으로 나가지만 포인트는 당근 안에 남는다는 데이터를 만들어 다시 찾아갔습니다. 하지만 이번에는 포인트를 쓸 곳이 부족하고, 사용자가 포인트를 잘 모른다는 이유로 또 거절됐습니다. 팀은 세 번째에 방향을 바꿔, 포인트로 주면 참여가 줄어들 거라는 우려 자체를 시험했습니다. 한 이벤트의 보상만 포인트로 바꿔 보니 참여율이 12.1%에서 11.6%로 거의 그대로였고, 이 결과를 들고 가자 “다음 이벤트는 포인트로 해볼게요”라는 답을 받았습니다. 이후 보상에서 포인트가 차지하는 비중은 92%까지 올랐습니다.
이 과정을 보며, 내 주장을 뒷받침하는 데이터도 중요하지만 설득할 상대가 무엇을 우려하는지 확인하고 그 우려에 답하는 데이터도 준비해야 한다는 걸 알게 됐습니다.
3. AI로 직군의 경계를 넘나드는 환경 만들기
문제를 찾고 팀을 설득해도, 실행이 개발자 한 사람에게 몰리면 그곳이 병목이 됩니다. “개발 딸깍, 디자인 딸깍, 운영 딸깍” 세션은 당근 POS를 AI로 만들어 매장 2,000곳에 배포한 이야기였습니다. 저는 AI로 개발 속도를 높인 이야기라고 생각했는데, 발표자는 4시간 만에 핵심 기능을 만든 뒤부터가 진짜 문제였다고 했습니다. 고치기 어렵고, 협업하기 어려웠기 때문입니다.
그래서 팀은 개발을 모르는 디자이너와 운영매니저도 기여할 수 있는 개발 루프를 만들었습니다. 코드를 읽지 못하는 디자이너와 운영매니저의 변경은 리뷰 자동화와 테스트 매장으로 검증했습니다. 디자인이 다음 병목이 되자 UI를 직접 고칠 수 있는 AI 스킬을 만들어, 디자이너가 이틀 만에 커밋 73개를 남기게 하였습니다. 또한 사장님의 POS 오류 문의가 들어오면 AI가 로그와 기기 정보로 원인을 먼저 분석해, 운영매니저가 개발자를 기다리지 않고 대응할 수 있는 환경을 만들었고, 두 달 동안 사장님 문의 316건을 처리했습니다. 그리고 개발자는 이 루프가 지속 가능하게 돌아가도록 조율하는 데 집중합니다.
“기획, 개발, 디자인 다 한다고 프로덕트 엔지니어일까?” 세션에서도, 엔지니어가 각 직군과 함께 기획, 디자인, 데이터 분석, 개발의 전문성을 스킬로 만들어 에이전트에 달아 두고, 누구나 Claude나 슬랙봇으로 불러 개발을 맡기거나 데이터를 분석할 수 있는 환경을 만든 경험을 공유했습니다. 여기서 엔지니어는 프론트와 백엔드 레포마다 AI가 따라야 할 작업 지침과 코드를 검토하는 리뷰 에이전트를 갖춰 두는 일을 책임집니다.
두 세션을 보며, AI 시대에 개발자의 또 하나의 역할은 함께 일하는 동료들도 AI를 쉽고 안전하게 쓸 수 있는 환경을 만들어 팀의 병목을 없애는 것이라고 느꼈습니다. 사내에 아직 AI를 쓰기 어려워하는 동료들이 어디서 막히는지부터 살피고, 제품에 직접 기여할 수 있는 환경을 하나씩 만들어 가려 합니다.
마치며
이번 Meetup에 가져간 질문은 “사용자가 모비닥으로 혈압을 꾸준히 기록하게 하려면 무엇이 필요할까?”였습니다. 세션을 듣고 나니 이 질문은 세 가지로 나뉘었고, 각각 아래와 같은 생각으로 이어졌습니다.
- 다시 기록할 가치는 무엇일까: 첫 기록 뒤 일주일 안의 두 번째 기록을 신호로 삼아, 병원 진료에 쓰이는 기록처럼 다시 기록할 가치에 대한 가설을 세우고 빠르게 확인하기
- 가설은 무엇을 근거로 세우고 어떻게 확인할까: 먼저 사용자가 되어 불편을 찾아 기능을 만들고, 데이터가 의미 있게 변하는지 보며 개선이 됐는지 확인해 다음 가설의 근거로 삼기. 팀을 설득할 때는 상대의 우려에 답하는 데이터까지 함께 보기
- 실험을 누가 빠르게 돌릴까: AI로 기획, 개발, 지표 확인을 넘나들고, 동료들도 AI로 직군의 경계를 쉽게 넘나들 수 있는 환경을 만들어 팀 전체가 가치를 더 빠르게 찾기
이 글이 AI와 함께 제품을 만드는 방식을 고민하는 분들께 조금이나마 도움이 되었으면 좋겠습니다. 읽어 주셔서 감사합니다.