2026 당근 Builder Meetup, Product Day 참여후기

들어가며

지난 9월 15일, 2026 당근 Builder Meetup에 다녀왔습니다. Builder Meetup은 4,300만 명 이상이 가입한 서비스를 만드는 당근 팀이 이미 해결한 문제부터 지금 풀고 있는 문제까지, 그 과정과 고민을 공유하는 자리입니다.

최근 저는 혈압 관리 서비스인 모비닥 환자앱을 개발하며 “사용자가 모비닥으로 혈압을 꾸준히 기록하게 하려면 무엇이 필요할까?“에 집중하고 있는데요. 마침 이번에 참여한 Product Engineering Day는 개발자가 AI를 활용해 직접 서비스 문제를 정의하고 풀어 온 경험을 나누는 행사여서, 이 고민에 대한 3가지 인사이트를 얻을 수 있었습니다.

“당근포인트, PM 없이 성장하기”, “기획, 개발, 디자인 다 한다고 프로덕트 엔지니어일까?”를 포함해 세션 10개에 참석했고, 이 글에서는 그 세 가지를 세션 이야기와 함께 하나씩 풀어 보려고 합니다.

1. 빠르게 만들되, 사용자가 다시 돌아올 이유를 찾기
2. 문제를 직접 이해하고, 작은 근거로 설득하기
3. AI로 직군의 경계를 넘나드는 환경 만들기

1. 빠르게 만들되, 사용자가 다시 돌아올 이유를 찾기

한 번 서비스를 쓴 사용자가 다시 돌아오게 하려면 무엇이 필요할까요?

이 질문의 힌트를 얻기 위해 “하드코딩에서 플랫폼까지, 현장결제 실험루프” 세션에 참석했습니다. 당근페이의 현장결제는 동네 가게에서 당근 앱의 QR로 결제하는 서비스입니다. 이 팀은 지난 1년 동안 결제 시장의 후발 주자로서, 어떻게 하면 사용자가 당근페이를 계속 쓰게 할지 실험해 왔고, 세션에서는 그 과정의 실패 경험을 자세히 공유해 주셨습니다.

세션을 듣기 전 저는 많은 사용자에게 안정적으로 서비스를 제공하려면, 처음부터 재사용할 수 있게 구조를 잘 추상화하고 확장성까지 고려해야 한다고 생각했는데요. 현장결제팀은 반대로 실험 속도를 위해 제휴 기능 일부를 의도적으로 하드코딩했습니다. 계속 쓸 기능이라고 확인되거나 반복적으로 비용이 들 때에야 개선을 시작했습니다. 서비스 초기에는 무엇보다 사용자에게 줄 가치를 확인하는 일을 먼저 두고 있었습니다.

• 팀이 결제를 늘리기 위해 처음 선택한 방법은 프로모션이었습니다. 타임딜, 할인, 결제 쿠폰처럼 혜택을 바꿔 가며 실험했고 결제 횟수도 늘었습니다. 하지만 혜택이 끝나면 한 번 쓰고 떠나는 사용자가 대부분이었고, 월 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%는 여전히 프로모션에서 나오고 있어, 혜택 없이도 다시 올 가치를 찾는 실험을 이어가고 있습니다.

이 경험은 “처음 혈압을 기록한 사용자가 다음 기록으로 이어지려면 어떤 가치를 줘야 할까?“라는 제 고민과 많이 비슷했습니다. 이번 인사이트를 계기로, 기록을 의사에게 쉽게 공유할 수 있게 하고 환자가 몰랐던 자신의 건강 상태를 해석해 보여 주는 것이 다시 기록으로 이어지는지 실험해 보려고 합니다. 또 다른 세션에서 들은 “알림은 사용자의 의도를 다음 행동으로 이어 준다“는 이야기를 바탕으로, 첫 기록에서 다음 측정과 기록까지 끊기지 않도록 UX 흐름을 다듬고 알림 같은 보완 장치도 붙여 보려고 합니다.

2. 문제를 직접 이해하고, 작은 근거로 설득하기

실험해 보겠다고 했지만, 무엇을 근거로 삼고 어떻게 확인할지는 또 다른 문제였습니다. 저는 근거를 찾으려면 사용자 인터뷰가 가장 중요하다고 막연히 생각해 왔습니다. 그런데 이번 Meetup에서 만난 당근 개발자들은 사용자 인터뷰보다 스스로 사용자가 되어 서비스를 만들고 있었습니다.

• 엔지니어로 시작해 지금은 당근모임, 당근아파트 같은 제품을 이끄는 리더들은 패널토크에서 내가 만든 제품을 직접 써 보는 “개밥먹기” 문화를 강조했습니다. “기획, 개발, 디자인 다 한다고 프로덕트 엔지니어일까?” 세션에서도 “문제는 내 문제를 풀 때 제일 잘 풀린다“며, 회사의 문제를 내 문제로 만드는 과정을 보여 주었습니다.
• 네트워킹 시간에는 현장결제팀에 문제 정의를 사용자 인터뷰로 하는지, 데이터로 하는지 따로 여쭤보았습니다. 인터뷰도 해 봤지만 사용자가 속마음을 잘 말해 주지 않아 정확한 이유를 찾기 어려웠고, 그래서 데이터에서 빈틈을 찾아 가설을 세우는 방식으로 시작한다는 답을 들었습니다.

제품을 만드는 제가 문제에 가장 가까운 사용자라는 걸 다시 생각하게 됐습니다. 저부터 불편함 없이 쓰는 서비스를 만들고, 그다음 팀을 만족시키고, 그 뒤에 사용자 인터뷰로 넓혀 가는 순서로 해 나가야겠다고 느꼈습니다.

문제를 찾았다면, 이제 왜 그 문제를 풀어야 하는지 설득하는 일이 남습니다. “당근포인트, PM 없이 성장하기” 세션에서는 이벤트 보상으로 주던 당근머니의 47.5%가 계좌로 빠져나가는 걸 보고, 당근 안에서만 쓸 수 있는 포인트로 바꾸려던 팀이 겪은 설득 과정을 들을 수 있었습니다.

• 첫 제안은 “유저들이 머니를 좋아한다”는 이유로 거절됐습니다.
• 팀은 머니는 절반가량이 밖으로 나가지만 포인트는 당근 안에 남는다는 데이터를 만들어 다시 찾아갔습니다. 이번에는 포인트를 쓸 곳이 부족하고, 사용자가 포인트를 잘 모른다는 이유로 또 거절됐습니다.
• 세 번째에는 방향을 바꿔, 포인트로 주면 참여가 줄어들 거라는 우려 자체를 시험했습니다. 한 이벤트의 보상만 포인트로 바꿔 보니 참여율이 12.1%에서 11.6%로 거의 그대로였고, 이 결과를 들고 가자 “다음 이벤트는 포인트로 해볼게요”라는 답을 받았습니다. 이후 보상에서 포인트가 차지하는 비중은 92%까지 올랐습니다.

이 과정을 보며, 직접 사용자가 되어 문제를 찾는 것만큼 상대의 우려에 답하는 데이터로 설득하는 것도 중요하다는 걸 느꼈습니다.

3. AI로 직군의 경계를 넘나드는 환경 만들기

문제를 찾고 팀을 설득해도, 실행이 개발자 한 사람에게 몰리면 병목이 되어 버립니다.

“개발 딸깍, 디자인 딸깍, 운영 딸깍” 세션은 당근 POS를 AI로 만들어 매장 2,000곳에 배포한 이야기였습니다. 단순히 AI로 개발 속도를 높인 사례인 줄 알았는데, 실제로는 개발 이후의 유지보수 그리고 비개발자와 협업하기 어려운 환경이라는 병목에 집중한 세션이었습니다.

• 이 병목을 풀기 위해 개발자는 디자이너와 운영매니저도 제품에 기여할 수 있는 개발 루프를 만들었습니다. 코드를 읽지 못하는 이들의 변경은 리뷰 자동화와 테스트 매장으로 검증했습니다.
• 디자인이 다음 병목이 되자 UI를 직접 고칠 수 있는 AI 스킬을 만들었고, 디자이너가 이틀 만에 커밋 73개를 남겼습니다.
• 사장님의 POS 오류 문의가 들어오면 AI가 로그와 기기 정보로 원인을 먼저 분석해, 운영매니저가 개발자를 기다리지 않고 대응할 수 있게 했습니다. 두 달 동안 이렇게 처리한 문의가 316건입니다.

이 구조에서 개발자는 루프가 지속 가능하게 돌아가도록 조율하는 데 집중합니다.

“기획, 개발, 디자인 다 한다고 프로덕트 엔지니어일까?” 세션에서도 비슷한 경험을 들을 수 있었습니다. 엔지니어가 각 직군과 함께 기획, 디자인, 데이터 분석, 개발의 전문성을 스킬로 만들어 에이전트에 달아 두고, 누구나 Claude나 슬랙봇으로 불러 개발을 맡기거나 데이터를 분석할 수 있는 환경을 만들었습니다. 여기서 엔지니어는 프론트와 백엔드 레포마다 AI가 따라야 할 작업 지침과 코드를 검토하는 리뷰 에이전트를 갖춰 두는 일을 책임집니다.

두 세션을 보며, AI 시대에 개발자의 또 다른 역할은 함께 일하는 동료들도 AI를 쉽고 안전하게 쓸 수 있는 환경을 만들어 팀의 생산성을 높이는 것이라고 느꼈습니다.

마치며

세션을 듣고 나니, “사용자가 모비닥으로 혈압을 꾸준히 기록하게 하려면 무엇이 필요할까?”라는 제 고민이 세 가지로 나뉘었고, 각각 아래와 같은 생각으로 이어졌습니다.

• 다시 기록할 가치는 무엇일까: 첫 기록 뒤 일주일 안의 두 번째 측정을 습관의 신호로 삼아 볼 수 있을지 살펴보기. 의사와 공유하기 쉽게 하고 몰랐던 건강 상태를 해석해 보여 주는 것처럼, 다시 기록할 이유에 대한 가설을 세우고 빠르게 확인하기
• 가설은 무엇을 근거로 세우고 어떻게 확인할까: 먼저 사용자가 되어 불편을 찾아 기능을 만들고, 데이터가 의미 있게 변하는지 보며 개선됐는지 확인해 다음 가설의 근거로 삼기. 팀을 설득할 때는 상대의 우려에 답하는 데이터까지 함께 준비하기
• 실험을 누가 빠르게 돌릴까: 저부터 AI로 기획, 개발, 지표 확인을 오가고, 동료들도 AI로 직군의 경계를 쉽게 넘나들 수 있는 환경을 만들어 팀 전체가 가치를 더 빠르게 찾기

이 글이 AI와 함께 제품을 만드는 방식을 고민하는 분들께 조금이나마 도움이 되었으면 좋겠습니다. 읽어 주셔서 감사합니다.