당근 빌더 밋업 참여 후기

Essay

배경

운 좋게 당첨되어 당근 빌더 밋업에 다녀왔습니다. 총 4일간 진행된 행사 중 Product Day에 참여했습니다.

타임테이블은 위와 같았고, 제가 참여한 세션을 중심으로 후기를 작성해 보겠습니다.

당근포인트, PM 없이 성장하기

PM이 없기에 디자이너와 엔지니어들이 직접 '문제 찾기, 우선순위 정하기, 지표 정하고 추적하기, 사람들 설득하기'를 해야 했다고 합니다.

당근의 여러 이벤트가 성공할 수 있었던 배경에는 당근머니라는 보상이 있었습니다. "그런데 이 돈, 당근 안에서 잘 쓰이고 있을까?"라는 질문이 생겼고, 실제로 지급액의 절반이 계좌를 통해 당근 밖으로 나가고 있다는 것을 확인했다고 합니다.

당근머니와 다르게 포인트는 당근 생태계 내에서만 사용 가능한 재화니까 포인트를 대신 지급하는 것을 제안했으나, 유저가 머니를 좋아해서 포인트 지급은 어렵다는 의견이 나왔습니다. 포인트를 지급했을 때 참여율이 떨어지지 않는다는 것을 증명하기 위해 광고를 보면 포인트를 주도록 했고, 이벤트 보상을 포인트로 바꿔봤다고 합니다. 참여율이 0.5% 차이로 떨어지지 않았음을 증명했고, 다음 이벤트는 포인트로 지급하겠다는 대답을 들을 수 있었습니다. 이제 포인트가 기본이며, 포인트 지급 규모가 머니를 넘어섰다고 합니다.

문제를 계속 찾게 만들었고, 문제가 보이면 바로 의견을 내고 진행하며, 확신이 없으면 실험으로 확인하고 있다고 합니다. PM이 없는 환경에서는 더더욱 사람이 아니라 절차로 결정하게 만드는 것이 중요하겠다는 생각이 든 발표였습니다.

한국 후기는 망했다

방향이 없으면 그저 바쁜 것에 불과하기에 방향을 잡기 위해 후기에 대한 철학을 만들었다고 합니다. 철학을 만들고 느낀 3가지 문제는 '후기를 안 쓴다, 못 쓴다, 너무 후하게 쓴다'였습니다.

후기를 쓰는 사람이 있어야 보기 때문에 우선 쓰는 사람부터 늘리기로 했습니다. 보상 차등지급으로 후기 작성을 유도했고, 아예 쓰지 않는 사람에게 작성을 유도하기보다는 이미 후기를 쓴 사람이 한 번 더 쓰게 만드는 데 집중했다고 합니다. 저도 리멤버에서 채용 솔루션을 개발하며 비슷한 경험을 했습니다. 제안을 전혀 보내지 않는 리크루터보다, 이미 제안을 보내고 있는 리크루터의 추가 제안을 이끌어내는 것이 더 효율적이었습니다. 당근과 도메인은 다르지만, 사용자가 이미 하고 있는 행동에서 다음 기회를 찾는다는 점은 같았습니다. 결국 제품을 만드는 일은 도메인이 달라도 비슷한 방식으로 고민하게 되는 것 같습니다.

양의 문제가 풀리자 다음 문제인 '못 쓴다'가 나왔습니다. 쓰기 싫어서가 아니라 쓸 줄 몰라서 못 쓰는 사람, 글은 부담스럽고 말은 편한 사람이 타겟 유저가 되었습니다. 누가 물어봐 주면 술술 대답하는 경험에 착안해 폼이 아니라 대화로 후기를 작성하는 방식을 제안했습니다.

단순히 맛있었다는 감상이 아니라 이 가게가 어떤 곳인지가 후기에 나오기 시작했습니다. 말로 쓰는 후기의 품질이 더 좋아졌고, 동네 이야기도 담기게 되었습니다.

이제 마지막 문제인 '후하게 쓴다'가 남았습니다. 한국 사람들은 별점을 냉정하게 주기 어려워하니, 본문을 다 쓰면 AI가 내용을 바탕으로 별점을 미리 채워주도록 만들었습니다. 예를 들어 아쉬움이 크면 2점, 만족도가 높으면 5점을 제안하는 방식입니다. AI 별점 출시 이후 5점 후기의 비율은 84%에서 61%까지 떨어졌습니다.

세 문제를 푸는 동안 원칙이 실제 제품에 적용되었고, 철학이 판단 기준이 되었습니다. 리뷰 이벤트로 남긴 리뷰 20개보다 동네 주민이 남긴 리뷰 하나가 더 가치있게 만들었습니다. 철학이 답을 정해주진 않았으나, 무엇을 하고 무엇을 하지 않을지 결정하는 데 도움이 되었다고 합니다.

5000만 지원 구인구직 플랫폼 위에 새로운 B2B 제품 성장시키기

저도 B2B 채용솔루션을 만들고 있기 때문에 관심 있게 들었던 발표였습니다.

로컬 잡스는 당근알바 서비스를 개발하는 조직인데, 최근에는 이웃과 기업을 연결하는 기업형 서비스도 만들기 시작했다고 합니다. 초기에 기업 고객을 잘 몰랐던 상황에서 어떻게 제품을 만들었는지 전략을 소개해 주셨습니다.

스타트업은 시드부터 시리즈 A, B 등 각 단계마다 검증해야 하는 가치가 다르고, 이에 따라 투입되는 리소스와 비용도 달라집니다. 로컬 잡스에서는 기능을 하나의 스타트업처럼 보고, 기능의 단계에 맞는 전략을 선택했다고 합니다. 저도 업무를 하면서 비슷한 고민을 해왔지만, 이를 하나의 스타트업이 성장하는 과정에 빗대어 설명한 것이 신선하게 느껴졌습니다. 실제로 어떤 문제를 해결했는지, 두 가지 사례를 통해 살펴보겠습니다.

첫 번째 사례는 기업별 채용 단계 구축입니다. 기존 당근 알바의 지원서 상태는 '미열람 -> 연락 대기 -> 연락 중 -> 근무 확정'으로 단순했습니다. 하지만 기업 고객사에서 서류, 인터뷰, 인적성 전형을 넣어달라는 요청이 들어오기 시작했습니다. 기업마다 커스텀하려면 테이블과 상태 로직을 새로 만들어야 했지만, 한 고객사만의 니즈일 수도 있었습니다. 그래서 처음부터 큰 리소스를 투자하지 않고, 별도 로직으로 하드코딩해 하루 만에 배포했습니다. 고객사가 실제로 잘 사용하는 것을 확인한 뒤 새 고객사를 하나씩 추가했고, 요청이 늘어나자 /add-enterprise-status 같은 스킬을 만들어 대응했습니다. 이후 스킬 방식마저 병목이 되자 어드민을 구축했습니다. 더 나아가 바리스타와 마감 청소 스태프처럼 채용 유형에 따라 다른 프로세스가 필요하다는 니즈가 생기면서, 채용 유형별 1:N 관리가 가능하도록 기능을 확장했습니다. 우선 빠르고 저렴하게 만들고, 점진적으로 기능을 성장시킨 사례였습니다.

두 번째 사례는 지원자 정보 수집 방식입니다. 지원 과정을 최대한 간편하게 유지하려 했지만, 기업 고객사는 보건증 유무나 근무 가능 시간대처럼 추가 정보를 수집할 수 있기를 원했습니다. 지원서에 질문을 추가하면 기존의 간편한 경험을 해칠 수 있었기 때문에 이미 지원자와 소통하고 있던 채팅을 활용했습니다. 지원 완료 후 채팅으로 임시 질문 페이지를 전달해 필요한 정보를 추가로 수집했고, 이후 추가 질문이 지원 직후에만 필요한 것이 아니라는 점을 학습하면서 채용 여정의 여러 시점에서 질문할 수 있도록 구조를 확장했습니다.

이처럼 기능의 단계마다 집중해야 할 과제와 들이는 비용이 달라집니다. 시드 단계에서는 이 기능이 실제로 쓰이는지 기능 자체를 검증합니다. 시리즈 A 단계에서는 더 많은 고객사로 쉽게 넓어지는지 확인하며, 시리즈 B 단계에서는 개별 기능들이 매끄럽게 연결되어 하나의 제품 경험이 되는지에 집중하게 됩니다. 결국 이 검증 사이클을 얼마나 빠르게 돌리는지가 핵심입니다. 한 바퀴를 도는 비용이 저렴할수록 더 여러 번의 시도를 이어갈 수 있습니다. 제품의 단계에 맞는 적절한 엔지니어링이 필요하다는 점을 다시 한번 느낄 수 있었습니다.

엔지니어 출신 제품 리더의 커리어 이야기와 패널토크

‘좋은 엔지니어는 좋은 제품 리더가 될 수 있을까?’를 주제로 패널토크가 진행되었습니다.

당근에서는 제품 리더를 프로덕트 오너와 매니저 역할을 함께 수행하는 사람으로 정의하고 있다고 합니다. 제품 리더의 관점에서 좋은 엔지니어는 ‘어떻게든 되게 만드는 사람’이라는 이야기가 나왔습니다. 이 이야기에 일부 동의하면서도 AI로 인해 이제 ‘어떻게든 되게 만드는 것’ 자체는 더 이상 어려운 일이 아니라고 느꼈습니다. 오히려 만든 결과에 책임을 지고 지속적인 개선까지 이어가는 엔지니어가 제품 리더에게 더 인정받는 시대가 오지 않을까 생각했습니다.

자기에게 주어진 일보다 더 넓은 범위를 책임지는 모습이 반복적으로 보이는 엔지니어는 제품 리더로 성장할 가능성이 높다고 했습니다. 엔지니어 출신이라는 배경은 제품 리더에게 분명한 강점이 됩니다. 구현하려는 기능의 규모와 기술적 가능성을 빠르게 판단할 수 있고, 엔지니어와 같은 언어로 소통하기 때문에 의사결정과 실행도 빨라집니다. 하지만 개발 관점에 지나치게 익숙해지면 개발 효율을 기준으로 제품의 스펙과 타협하는 함정에 빠질 수도 있습니다. 제품의 문제를 반드시 개발로 해결하려 하기보다 개발이 아닌 더 나은 방법이 있는지 함께 고민하는 시각이 필요합니다. PM, 기획, 경영, 법무 등 다른 직군과 일하는 방식 역시 새롭게 배워야 합니다.

이후 Q&A에서는 리더십과 조직문화에 대한 현실적인 이야기가 이어졌습니다.

새로운 역할을 맡았을 때 처음부터 잘할 수는 없기에, 주니어 시절 성장했던 자신만의 학습 방식을 다시 활용하거나 전문가들이 어떻게 일하는지 관찰하고 흉내 내는 것이 도움이 된다고 했습니다.

리더로서 제품보다 사람이 어렵다는 이야기도 나왔습니다. 데이터는 숫자로 명확하게 확인할 수 있지만, 사람은 복합적이라서 0과 1로 떨어지지 않기 때문입니다. 처음부터 매니징을 잘하는 리더는 없기에, 자신의 매니징 방식과 조직 설계를 계속 돌아보며 자신만의 리더십 스타일을 만들어가는 과정이 필요하다고 합니다.

마지막으로 팀의 방향성에 대한 얼라인을 위해서는 모든 정보를 전달하기보다 지금 팀이 집중해야 하는 핵심을 반복해서 이야기하는 것이 중요하다고 했습니다. 제품에 대한 확신 역시 한 번에 만들어지는 것이 아니라 수많은 실패를 거치며 쌓이는 것이기에, 실패를 성장의 자연스러운 과정으로 받아들일 수 있는 팀의 분위기를 만드는 것이 중요하다는 이야기로 마무리되었습니다.

부채에 발목 잡히지 않고 J-Curve를 밟아 나가기

이번 발표는 성장한 제품이 학습 속도를 지키는 방법에 대한 이야기입니다. 최근에는 AI로 직무 간 경계가 다소 허물어지면서 기술 부채가 쌓인 영역에서 백엔드 엔지니어와 디자이너도 함께 작업하게 되었습니다. 그러면서 부채를 청산해야 할 필요성을 더욱 크게 느끼던 시점이라 발표를 들으러 갔습니다.

제품이 성공하고 나면 초기와는 완전히 다른 성격의 문제들을 마주하게 됩니다. 신규 제품 단계에서는 신속한 검증과 학습이 최우선이지만, 제품이 크게 성장한 후에는 안정적인 운영과 예측 가능한 변경 관리가 훨씬 중요해지기 때문입니다.

제품이 성장함에 따라 여러 제품이 공통 기반 코드를 공유하면서 변경사항이 미치는 영향 범위가 급격히 커지게 됩니다. 이에 따라 개발자들은 신규 작업 자체보다 자신과 직접적 관련이 없는 다른 제품들에 미칠 영향을 확인하고 검증하는 데 훨씬 많은 시간을 쏟게 됩니다. 또한 코드베이스가 비대해지면서 CI와 빌드에 소요되는 시간이 늘어나, 구현을 마친 후에도 기다려야 하는 병목 현상이 자주 발생합니다.

이러한 문제를 해결하기 위해 배포 루프를 개선하여 변경의 경계를 명확히 나누고, 작은 단위의 변경을 더 자주 전달하는 구조로 전환했다고 합니다. 조직의 경계가 코드 구조에 그대로 드러나도록 개편하여 일부 코드의 중복을 감수하고 팀 간의 조율 비용을 줄이는 선택을 한 것도 인상 깊었습니다.

더 다양한 고객을 깊이 이해하기 위해 의사결정과 실험 방식도 개선했다고 합니다. 여러 실험이 서로 간섭하거나 악영향을 주지 않도록 홀드아웃 그룹 설정과 상호 배제 방식을 적용했습니다.

  • 홀드아웃: 일부 사용자에게는 변경을 적용하지 않고, 누적·장기 효과를 비교
  • 상호 배제: 충돌할 수 있는 실험끼리 같은 사용자가 동시에 참여하지 않게 분리

특정 실험에 헤비 유저가 쏠리는 현상을 방지하는 방법에 대해서는 데이터팀이 자체 구축한 툴을 통해 헤비 유저를 미리 지정함으로써 실험군 내 편향 여부를 사전에 파악하고 있다고 설명했습니다.

기술 부채를 해결하기 위한 시간 확보에 대해서는 대형 프로젝트 사이클이 완료된 후 쿨다운 위크/폴리싱 위크를 정기적으로 운영한다고 답했습니다. 리멤버에서도 랠리가 끝나면 피트스탑을 운영하고 있는데, 기술 부채를 해결할 시간을 별도로 확보하는 것이 좋은 개발 문화라고 느꼈던 터라 반가웠습니다. 백엔드 엔지니어의 경우 디자이너가 작업하는 대기 시간을 활용해 기술 부채를 해결하고 있다고 합니다. 부채 개선이 향후 개발 속도를 높여준다는 논리로 리더를 설득해 시간을 확보한다고 덧붙였습니다.

FE·BE를 한 팀으로 합친 첫 분기 이야기

FE와 BE를 하나의 팀으로 통합하며 어떤 방식으로 일했는지, 그리고 그 과정에서 무엇을 배웠는지를 소개했습니다.

기존에는 API 협의와 일정 조율, 서로의 작업을 기다리는 시간이 반복되면서 직군 간 대기가 발생했습니다. 이를 줄이기 위해 하나의 팀으로 합쳤지만, 서비스 안정성과 각 직군의 전문성이 약해질 수 있다는 우려도 있었습니다. 그래서 처음부터 큰 변화를 시도하기보다 작은 일부터 시작했다고 합니다.

낯선 영역을 배우면서 오히려 개발 속도가 느려지지 않을까 하는 부담을 줄이기 위해 일을 작게 나누고 감당할 수 있는 과제부터 맡기기 시작했습니다. 리더가 먼저 새로운 방식으로 일하면서 팀이 따라갈 수 있는 방법을 만들고, 이를 점차 팀 전체로 확장했습니다.

온콜 역시 직군을 나누지 않고 함께 대응했습니다. 직군 통합과는 별개로 인프라 장애가 발생한 적도 있었는데, 통합 초기에는 익숙하지 않은 영역의 장애를 함께 대응하는 과정이 쉽지 않았다고 합니다. 이를 보완하기 위해 운영에 필요한 지식과 확인 방법을 정리한 런북을 만들었고, 장애가 발생하면 런북에서 확인해야 할 대상을 찾고 대시보드에서 상태를 확인하는 방식으로 대응할 수 있도록 했습니다.

첫 분기의 아웃풋을 확인한 결과, 통합 이전과 비슷한 수준의 완료량을 유지할 수 있었다고 합니다.

일하는 방식에도 변화가 생겼습니다. 기존의 티켓 단위가 아니라 목표 단위로 한 사람이 맡아 끝까지 진행하는 방식으로 변경되었습니다. 엔지니어가 단순히 기술 과제를 전달받아 구현하는 것을 넘어, 해결해야 할 문제를 직접 정의하고 PRD를 작성한 뒤 실제 결과를 확인하고 책임집니다.

물론 한계도 있었습니다. 계획했던 것과 실제 작업 구성이 달라지는 경우가 많았고, 실제로 진행한 일의 약 3분의 2가 계획 밖의 일이었다고 합니다. 또한 직군을 나누어 일할 때보다 서로의 전문성을 접할 기회가 줄어들면서 팀의 감각이 옅어지는 문제도 있었습니다.

앞으로 계속 살펴봐야 할 위험도 있습니다. 서로 다른 관점에서 리뷰하며 얻을 수 있는 지식이 특정 사람에게 쏠릴 수 있기 때문입니다. 각자의 전문성을 깊게 쌓는 과제를 별도로 가져가면서도, 서로의 영역을 이해하고 상호 검증과 학습을 이어가는 것이 필요하다고 했습니다.

마지막으로 직군 통합을 고려할 때 미리 확인해야 할 세 가지를 제시했습니다.

  • 직군 사이의 대기를 줄일 구체적인 과제가 있는가
  • AI 활용 습관과 참고할 문서가 있는가
  • 일하는 방식의 합의와 검증할 동료 및 운영 리듬이 있는가

단순히 직군을 합치는 것만으로 협업 비용이 줄어드는 것은 아니기 때문에 직군 통합은 신중하게 접근하는 것이 좋겠다는 생각이 들었습니다. 발표 내용이 당근 테크 블로그에도 올라와 있으니 관심 있는 분들은 참고하시면 좋겠습니다.

PMF와 BM만 찾으면 끝일 줄 알았습니다만

저는 개인적으로 이 발표가 이번 밋업에서 가장 인상 깊었습니다.

PMF 이야기

당근에서 알바도 하냐는 이야기를 정말 많이 들었다고 합니다. 당근 알바의 PMF는 가까운 거리에서 일할 사람과 일할 곳을 연결할 수 있다는 것이었습니다. 이를 더 많은 사람에게 알리기 위해 당근 알바의 진입점을 안팎으로 늘리고, 지원 과정의 마찰도 줄였습니다.

그 과정에서 엔지니어가 본능적으로 하고 싶어 하는 일들을 오히려 하지 않는 데 집중했다고 합니다.

  • 추상화하기
  • 공용 훅 만들기
  • 반복되는 UI를 컴포넌트로 분리하기
  • 테스트하기
  • 작은 에러 해결하기

대신 클라이언트 주도의 실험 환경을 만들고, GraphQL 스키마를 확장성 있게 설계하고, 실시간으로 데이터를 추적하며, 매일 결정하고 배포하는 것에 집중했습니다. 단거리 육상 선수와 장거리 육상 선수의 근육이 다르듯, 제품의 스테이지에 따라 필요한 엔지니어링도 다르다는 설명이었습니다. 결과적으로 이러한 방식으로 빠르게 실험과 학습을 반복하며 J-Curve를 만들어냈고, 누적 지원 5천만 건이라는 결과로 이어졌다고 합니다.

BM 이야기

PMF를 찾았다면 다음에는 어떻게 수익을 만들 것인지 고민해야 합니다. 여기서도 중요한 원칙은 무료로 사용할 수 있는 길은 여전히 남겨두는 것이었습니다. 전면 유료화는 사용자 이탈로 이어질 수 있기 때문에, 돈을 낸 사용자가 더 많은 가치를 얻을 수 있는 환경을 만드는 방향을 선택했습니다.

무엇에 돈을 받을지 정하기 위해 끌어올리기, 지원서 열람, 경력자 대상 추가 알림, 프리미엄 지면 노출 등 수십 가지 실험을 진행했습니다. 처음부터 사용자를 세분화해 다양한 조건에서 실험했고, 알바를 며칠 동안 구할 것인지에 따라 기간권을 만드는 방식도 시도했습니다. 여기서도 무료로 사용할 수 있는 선택지는 남겨두되, 더 큰 가치를 원하는 사용자에게 과금하는 것​을 기준으로 삼았습니다. 결국 사용자가 서비스를 계속 이용할 수 있는 경험을 해치지 않으면서, 더 큰 가치를 원하는 사용자에게 어떻게 비용을 받을 것인지를 찾아가는 과정이었습니다.

이러한 실험을 계속하기 위해서는 유연한 모듈 설계와 함께 계층을 분리하는 것이 중요했다고 합니다.

최근의 일상

서비스가 알바, 정규직 채용 등 여러 시장으로 확장되면서 속도와 균형을 잃기 시작했습니다. 하나의 공고가 15개의 상태를 가지고, 지원 과정에는 20개가 넘는 플로우가 섞이게 되었습니다. 같은 사용자도 서로 다른 비즈니스 모델을 오가게 되면서 코드와 정책의 복잡성도 함께 커졌습니다.

조직 역시 복잡해졌습니다. 캘린더는 회의로 채워지고 겸직이 늘었으며, 과거에 쌓은 레슨런도 조직 전체에 공유되기 어려워졌습니다. 엔지니어가 많아지면서 코드의 일관성이 깨지는 문제도 생겼습니다. 이제는 모든 시장이 각자의 고객과 매출을 가지고 있어 어느 하나를 쉽게 포기하고 선택과 집중하기도 어려운 상황이 되었습니다.

그래서 최근에는 Alignment에 집중하고 있다고 합니다. UX 라이팅까지 린트로 검증하고, 이벤트도 딕셔너리 패턴으로 만들어 정의된 단어를 사용해 로깅하도록 했습니다. 이전에는 사람이 리뷰하며 확인하던 세부적인 부분까지 기술적으로 일관성을 유지할 수 있도록 만든 것입니다. 코드 리뷰에도 에이전트를 활용해 배포된 코드에 다음 날 리뷰가 달리도록 하고, 사후 트래킹까지 챙기고 있다고 합니다. 사후 코드 리뷰는 생각해 보지 못했던 방식이라, 실제 업무에도 적용해 볼 만한 인사이트를 얻을 수 있었습니다.

더 나아가 에이전트가 팀의 정렬을 맞출 수 있도록 한 스레드 안에서 계속 루프가 이어지는 구조도 만들고 있습니다.

디자인 리뷰 → 테크 스펙 → 배포 알림 → 헬스 체크 → 성과 분석

예를 들어 디자이너가 시안을 올리면 에이전트가 디자인 리뷰를 남기는 방식입니다.

앞으로의 과제

앞으로는 팀이 커지더라도 어떻게 가치를 지킬 수 있을지를 고민하고 있다고 합니다. 사람이 계속해서 직접 정렬을 맞추는 것이 아니라 가치가 자연스럽게 공유되고 에이전트가 그 방향을 지속적으로 잡아줄 수 있는 환경을 만들어가고 있었습니다.

발표자분께서 엔지니어로서 받았던 가장 인상 깊은 리뷰도 공유해 주셨는데, 저도 코드를 기능을 구현하는 수단으로만 바라보고 있지는 않았는지 돌아보게 되었습니다.

코드는 기능을 구현하는 게 아니다. 제품을 성공시키고 떠났을 때, 다른 엔지니어가 코드를 보면서 일하는 방식과 가치를 알 수 있게끔 해야 한다.

결국 좋은 코드를 만드는 것을 넘어 팀의 가치와 일하는 방식까지 코드와 환경에 녹여내는 것 역시 엔지니어의 역할일 수 있겠다는 생각이 들었습니다. 서비스가 성장할수록 엔지니어에게 필요한 역할도 달라집니다. 모든 단계에서 같은 방식으로 잘하는 것이 아니라, 내가 속한 스테이지에서 무엇을 고민하고 어떤 방식으로 일해야 하는지 판단하는 것이 중요하다는 생각이 들었습니다.

마치며

A홀과 B홀에서 동시에 세션이 진행되어 매시간 하나를 선택해야 했는데, 듣지 못한 세션들이 아쉬울 만큼 알찬 밋업이었습니다. 단순한 기술 공유를 넘어 일하는 방식 자체를 돌아볼 수 있었던 시간이었습니다. 내년에도 참여할 수 있기를 바라며 글을 마칩니다.