2026 당근 Builder Meetup — Android Day 후기

당근 Builder Meetup의 Android Day에 다녀왔습니다. 여덟 개 발표와 네트워킹에 참여하며 인상 깊었던 내용을 정리했습니다.

읽기 전에

현장에서 세션을 들으며 빠르게 남긴 메모를 바탕으로 정리한 글입니다. 정리하는 과정에서 실제 발표 내용과 다르게 이해하거나 옮긴 부분이 있을 수 있으니 양해 부탁드립니다.

행사 개요

• 일시 · 2026년 9월 14일(월) 13:00–20:00
• 장소 · 모나코 스페이스 지하 1층 A홀
• 주제 · AI를 활용한 Android 개발, 앱의 속도와 품질 개선, 개발자의 역할 확장과 팀 문화
• 출처 · Android Day 공식 안내 및 시간표

현장에서는 당근 캐릭터 굿즈와 개발자 스티커 팩도 받았습니다. 알찬 발표에 귀여운 굿즈까지 더해져 기분 좋은 하루였습니다.

세션 1. 키노트 — 에이전트가 코드를 짜는 시대, 당근 Android 팀은 어떻게 일하고 있나

코드 생성 이후의 병목과 팀 공통 기반

당근 Android 팀은 대규모 리팩터링과 PoC(개념 검증)에 AI를 활용하기 시작했습니다. 코드 작성이 빨라지자, 늘어난 코드를 리뷰하고 검증하는 과정과 무거운 로컬 빌드가 새로운 병목이 됐습니다.

여러 사람이 AI를 효율적으로 활용할 수 있도록, 개인이 쓰던 에이전트 규칙과 스킬을 팀 공통 자산으로 정리하고 플러그인을 사내 마켓플레이스에 공유했습니다. 빌드는 원격에서 병렬로 실행하고 캐시를 공유해 한 개발자가 여러 에이전트의 작업을 동시에 진행할 수 있게 했습니다. 발표에서는 이런 변화와 함께 1인당 코드 생산량이 약 3.6배 늘었다고 소개했습니다.

배포·운영 자동화와 역할 확장

자동화는 배포 이후까지 이어졌습니다. 릴리즈 준비와 배포를 자동화하고, 운영 중 수집한 데이터로 문제의 원인을 분석해 수정안을 마련했습니다. 수정안은 빌드와 테스트를 거치고, 사람은 대응 우선순위와 최종 반영 여부를 판단했습니다.

이렇게 확보한 시간은 제품 기획에 활용했습니다. 개발자가 직접 데이터를 살펴보고 요구사항과 명세를 작성하며 PoC를 제안·구현했습니다. 앞으로는 비개발 직군이나 다른 플랫폼 개발자도 Android PoC를 시도할 수 있도록 코드·문서·디자인 시스템 등 개발 기반을 정비할 계획입니다.

내 생각

개발자의 AI 활용이라고 하면 코드를 얼마나 빠르게 작성할 수 있는지에 먼저 관심이 쏠리기 쉽습니다. 당근은 여기서 더 나아가 설계와 검증, 배포와 운영까지 서비스 생애주기 전반으로 AI 활용을 넓혀 가고 있다는 점이 인상적이었습니다.

특히 비개발 직군이나 다른 플랫폼의 개발자도 AI 에이전트의 도움으로 Android PoC를 직접 시도할 수 있도록 기반을 마련한다는 점이 흥미로웠습니다. AI가 개발 속도를 높이는 것을 넘어, 아이디어를 직접 구현해 볼 수 있는 사람의 범위까지 넓힌다는 점이 기억에 남았습니다.

세션 2. AI는 점점 잘하는데, 어디까지 맡겨도 될까요?

변경의 성격에 따른 리뷰 분담

AI로 코드 생산량이 늘면서 리뷰 부담도 커졌습니다. 전년 대비 PR 수는 40%, 코드 양은 73% 증가했습니다. 당근은 파일 이동·이름 변경·포맷 정리처럼 검증이 쉬운 변경부터 AI 리뷰를 적용했습니다. 기계적으로 판정할 수 있는 부분은 스크립트에 맡기고, 최종 머지 여부는 사람이 판단했습니다.

AI 리뷰 도입 후 평균 머지 시간은 65시간에서 46시간으로 줄었습니다. 리뷰의 품질을 높이기 위해 코멘트에 중요도를 표시하고, 중복 지적이나 PR 범위를 벗어난 제안도 걸러냈습니다. 사람이 중요한 문제에 집중할 수 있도록 한 것입니다.

리뷰 피드백으로 개선하는 팀 규칙

AI가 팀의 맥락을 이해하도록 서비스 도메인과 개발 규칙을 Rule 문서로 정리했습니다. 문서가 늘어난 뒤에는 작업과 관련된 내용만 읽도록 범위도 정했습니다.

이 규칙을 개선하는 데도 AI를 활용했습니다. 같은 피드백이 세 번 쌓이면 Rule 후보로 올리고, 실제 PR 코멘트에서 반복되는 내용을 찾아 초안을 만들었습니다. 사람이 승인한 규칙은 다음 리뷰에 적용해, 팀의 경험이 리뷰 기준에 계속 반영되도록 했습니다.

내 생각

AI로 코드 생산량이 늘어난 만큼, 리뷰를 어떻게 감당할지는 여러 회사가 함께 고민하는 문제라고 생각합니다. 당근은 변경의 성격에 따라 사람과 AI, 스크립트의 역할을 나누고, 리뷰 코멘트에도 중요도 기준을 적용했습니다. 이런 기준을 통해 리뷰 속도를 높이면서도 안정성을 함께 지키려는 접근이 좋았습니다.

프로젝트의 맥락을 담은 문서를 관리하는 데도 AI를 활용한다는 점이 흥미로웠습니다. 실제 리뷰에서 나온 피드백으로 규칙 초안을 만들고, 사람이 승인한 내용을 다시 리뷰에 활용하는 방식입니다. 문서를 한 번 작성하는 데서 끝내지 않고, 팀의 경험이 쌓일수록 점진적으로 개선하는 과정이 인상적이었습니다.

세션 3. 필요할 때만, 바뀔 때만, 한 번만 — DFM과 Build Cache

필요한 기능만 배포: DFM

모듈이 450개가 넘는 당근 Android 앱은 앱 용량과 빌드 비용을 함께 줄여야 했습니다. 먼저 동영상 편집 기능에서 사용자에게 불필요한 용량을 배포하는 문제를 해결했습니다.

편집 모듈에 포함된 리소스를 CDN으로 옮겨 필요할 때 내려받도록 하자, 모듈 용량이 200MB에서 40MB로 줄었습니다. 남은 40MB도 편집 기능을 쓰는 사용자에게만 내려주기 위해 온디맨드 DFM(Dynamic Feature Module)을 도입했습니다.

처음에는 기능 전체를 옮기려 했지만, Hilt를 통한 의존성 주입과 R8 설정 등을 함께 바꿔야 해 복잡성이 컸습니다. 최종적으로 기능 코드는 기본 설치 영역인 base 모듈에 두고, 용량 대부분을 차지하는 네이티브 라이브러리(SO 파일)만 분리했습니다. 덕분에 다운로드 실패 시 안내를 표시하기 쉽고, 로컬 개발도 수월해졌습니다.

이 과정은 200MB 모듈을 팀 단위로 해결하기를 참고

빌드 구성과 실행 결과의 재사용

빌드에서는 반복 작업을 줄였습니다. Configuration Cache로 구성에 영향을 주는 입력이 같으면 태스크 그래프와 구성 상태를 재사용해, 구성 시간을 약 3분에서 11초로 줄였습니다.

태스크 실행 결과는 Remote Build Cache로 공유했습니다. 개발자나 CI가 이미 만든 결과를 입력이 같은 작업에서 받아 쓰는 방식입니다. 비용과 필요한 기능을 고려해 캐시 서버를 직접 구축하고, 연결 설정은 사내 Gradle 플러그인으로 배포했습니다.

발표에서 공유한 빌드 시간은 캐시 적용 전 5분 44초에서 적용 후 1분 53초로 줄었고, 캐시 히트율은 53%였습니다. 필요한 기능만 배포하고, 바뀌지 않은 구성과 이미 만든 결과를 재사용한다는 공통된 원칙으로 작업량을 줄였습니다.

내 생각

빌드 시간 단축은 기능 개발에 비해 우선순위가 밀리기 쉽지만, 저는 중요하게 생각합니다. 빌드 한 번에서 1초를 줄이면 팀원 10명이 한 번씩 빌드할 때 총 10초를 아낄 수 있습니다. 하루에도 여러 번 반복되는 작업인 만큼, 작은 개선이 팀 전체에 쌓이는 효과는 큽니다. 이렇게 확보한 시간을 더 중요하고 가치 있는 일에 쓸 수 있다는 점에서 의미 있는 투자라고 느꼈습니다.

저도 평소 두세 개의 코드 수정 작업을 병렬로 진행하는데, 빌드 시간이 병목이 되는 경우가 있었습니다. 그래서 한 번 만든 결과를 동료들과 공유하고, 병렬로 진행하는 작업에서도 재사용한다는 접근이 특히 와닿았습니다.

세션 4. 레고처럼 조립하고 분해하는 중고거래 게시글 상세화면

복잡한 화면 조건을 도메인으로 정리

중고거래 게시글 상세는 하루 평균 1.5억 번 넘게 노출되는 화면입니다. 국가, 보는 사람, 거래 상태와 유형을 조합하면 96가지 경우가 생기고, 바로구매 버튼 하나도 거리나 판매자·구매자 여부에 따라 표시 조건이 달랐습니다.

당근은 이런 조건을 화면 곳곳에서 반복해서 판단하지 않도록, 보는 사람과 거래 맥락을 도메인 타입으로 구분했습니다. 이를 바탕으로 상황에 맞는 UI를 선택하는 책임은 팩토리에 모았습니다.

팩토리로 선택하고 렌더러로 조립

화면은 이미지·제목·본문·하단 버튼 등의 블록으로 나누고, 각 블록을 그리는 역할을 렌더러에 맡겼습니다. 팩토리가 국가나 실험 조건에 맞는 렌더러를 선택하면, 페이지는 그 목록을 순서대로 호출해 화면을 구성합니다. 공통 영역은 재사용하고 필요한 블록만 바꿀 수 있는 구조입니다.

A/B 테스트도 팩토리에서 렌더러를 선택하는 방식으로 적용했습니다. 실험이 끝나면 채택한 구현만 남겨 정리할 수 있습니다. 발표에서는 이렇게 도메인의 의미와 선택 기준, 각 블록의 역할을 코드에 드러내면 사람과 AI 모두 맥락을 이해하기 쉬워진다고 설명했습니다.

내 생각

화면에 보이는 요소를 그대로 구현하기보다, 먼저 구현하려는 대상과 조건을 추상화한 점이 인상적이었습니다. 컴포지트 패턴처럼 작은 블록을 조합하고, 팩토리 패턴으로 상황에 맞는 구성을 선택하면서 가독성과 유지보수성, 확장성을 높여 간 과정이 흥미로웠습니다.

마지막에 발표자가 전한 ‘사람이 이해하기 좋은 코드는 결국 AI도 이해하기 쉽다’는 의견에도 공감했습니다. 평소 제 생각과도 맞닿아 있어 특히 반가웠습니다.

세션 5. 저도 할 수 있어요! 제품이 만들어지는 길목마다 AI 사용하기

개발자가 AI의 도움으로 기획부터 운영까지 참여 범위를 넓힌 사례를 소개했습니다. 예를 들어 “AI로 짧은 글을 작성하면 거래 완료율이 높아질까”라는 가설을 검토하려면 글 길이별 거래 완료율을 살펴봐야 합니다. 이전에는 데이터 분석가에게 요청하고 기다려야 했지만, DA Agent를 도입한 뒤에는 간단한 분석을 직접 수행할 수 있게 됐습니다. 실험 설계와 배포 후 지표 확인에도 에이전트를 활용했습니다.

구현 과정의 반복 작업과 운영 문의에도 AI를 활용했습니다. 번역 스킬로 번역문의 일관성을 관리하고 Android와 iOS에 맞는 문구 키를 생성했습니다. 운영 문의는 온콜 봇이 먼저 확인해 해결 방안을 제시하면서 담당자의 대응을 도왔습니다.

플랫폼 간 협업 방식도 달라져, 백엔드 개발자가 AI의 도움으로 Android 저장소에 직접 PR을 올리는 사례가 생겼습니다. 다만 데이터 분석·실험·다른 플랫폼 관련 작업은 반드시 리뷰를 받도록 했습니다. 참여 범위를 넓히면서도 결과를 검증하는 과정은 유지했습니다.

내 생각

AI를 활용하면 개발자가 구현뿐 아니라 기획 단계에도 적극적으로 참여할 수 있다는 점이 흥미로웠습니다. 아이디어를 제안하는 데서 더 나아가, 직접 데이터를 살펴보고 가설을 세우며 실험을 설계하는 모습이 인상적이었습니다.

개발자 스스로 기획자의 역할도 맡을 수 있다는 점에서, 직군별 업무 영역을 나누던 경계가 점차 낮아지고 있다고 느꼈습니다. 각자의 전문성을 바탕으로 제품을 만드는 더 넓은 과정에 참여할 수 있다는 가능성이 와닿았습니다.

세션 6. 자주 배포하고, 문제는 먼저 발견하기

배포 상태 시각화와 자동 모니터링

당근은 배포 후 문제를 알아채기까지의 시간을 줄이기 위해 Android Observability를 도입했습니다. Firebase Crashlytics, Firebase Performance Monitoring, Google Play Console 등에 흩어진 데이터를 모아 새 버전의 크래시·ANR(앱 응답 없음)과 성능 상태를 한눈에 보여주는 도구입니다.

담당자는 대시보드에서 배포 상태를 확인하고, 봇(AI Agent)은 BigQuery에 모인 지표를 지속적으로 점검합니다. 팀이 비교 대상과 집계 기간, 이상 징후 기준을 정하면 봇은 그 기준에 따라 문제를 찾아 슬랙으로 알립니다. 담당자는 대시보드와 알림을 바탕으로 배포를 확대할지, 중단하고 원인을 분석할지 판단합니다.

이상 징후 발견에서 수정안 준비까지

실제로 5% 단계 배포 중 봇이 Android 9·10에 집중된 ANR을 발견했습니다. 이어 SQL 버전과 관련된 문제라고 분석하고 Draft PR(초안 PR)까지 준비했습니다. 개발자는 봇이 정리한 분석과 수정안을 검토하는 데서 대응을 시작할 수 있었습니다.

앱이 종료되지 않는 non-fatal 오류는 배포를 멈추지 않고 데이터를 수집했습니다. 유의미한 문제로 판단되면 슬랙으로 알려 다음 버전에 반영하도록 했습니다. 오류의 성격에 맞게 대응하면서 문제를 발견하고 수정하는 데 걸리는 시간을 줄인 사례입니다.

내 생각

문제없이 개발하고 배포하는 것만큼, 발생한 오류를 빠르게 인지하고 수정하는 것도 중요하다고 생각합니다. 이는 앱의 완성도를 넘어 서비스 품질로 이어지고, 사용자에게 좋은 경험을 제공하며 이탈을 줄이는 데도 도움이 될 수 있습니다.

이번 발표에서는 당근이 문제를 발견하고 대응하는 과정을 얼마나 중요하게 생각하는지 느낄 수 있었습니다. 지표를 모아 보여주는 데서 나아가, 이상 징후를 더 빨리 발견하고 수정으로 연결하기 위해 고민한 점이 인상적이었습니다.

세션 7. 안드로이드 개발자의 개발 경계 확장기

결제팀으로 이동한 Android 개발자가 웹과 서버까지 역할을 넓힌 경험을 소개했습니다. 첫 업무였던 웹 결제창의 네이티브 전환을 계기로 웹 운영과 FE 플랫폼까지 맡게 됐고, 이후 익숙한 Kotlin을 사용하는 서버 개발에도 참여했습니다. 쿠폰함 기능에서는 쿠폰 적용 API부터 결제 화면까지 함께 개발했습니다.

새로운 영역에 진입하는 데는 AI가 도움이 됐습니다. Android·웹·서버 저장소의 규칙과 스킬을 하나의 작업 환경인 하네스로 묶어, AI가 각 플랫폼의 기준을 참고하도록 했습니다. 경험이 부족한 영역에서는 개발 시간이 오래 걸리고 버그와 장애도 더 많이 겪었습니다. 한편 작업 전체를 이어서 맡게 되면서 담당자 간 요청과 확인이 줄고, 원인 파악과 수정은 빨라졌습니다.

새로운 기술을 배울 때는 기존 Android 지식을 발판으로 삼았습니다. React의 useEffect로 구독을 시작하고 해제하는 코드를 Compose의 DisposableEffect와 onDispose에 빗대어 AI에게 설명받은 것이 그 예입니다. 기존 지식이 새로운 학습을 돕고, 다른 영역의 경험이 다시 시야를 넓혀 주는 과정을 발표자는 전문성의 양방향 이동이라고 표현했습니다.

내 생각

저도 Android 외에 Flutter와 iOS를 개발해 본 입장에서 공감하는 부분이 많았습니다. AI를 활용하기 전에는 여러 플랫폼을 시도하다가 기존 전문성은 얕아지고, 새로운 영역에서도 충분한 깊이를 쌓지 못해 이도 저도 아닌 개발자가 되는 것은 아닐까 걱정했습니다.

지금은 AI로 새로운 기술에 접근하는 장벽이 낮아지면서, 이런 경험을 조금 다르게 바라보게 됐습니다. 다양한 플랫폼을 경험하면 시야가 넓어지고, 특정 기술에서 익힌 방식에만 머무르지 않고 문제에 맞는 해결책을 찾는 데도 도움이 될 수 있다고 생각합니다. 이렇게 개발 영역을 넓히는 경험이 결국 문제 해결 능력을 키우는 데도 도움이 되지 않을까 기대합니다.

세션 8. 직급 상관없이 바텀업할 수 있는 문화

발표자는 처음에는 AI에 심리적인 거리감을 느껴 적극적으로 활용하지 않았다고 합니다. 당근 입사 후 AI 사용을 장려하는 분위기 속에서 도구에 관심을 갖게 됐고, 필요한 스킬과 에이전트를 직접 만들어 쓰는 단계까지 나아갔습니다.

QR 코드 인식 개선은 이러한 변화가 실제 문제 해결로 이어진 사례였습니다. 사진이 기울어져 있거나, 한 사진에 QR 코드가 여러 개 들어 있거나, 화질이 낮으면 인식이 잘되지 않았습니다. 기존 Android 지식만으로 해결하기 어려웠지만, AI와 함께 원인을 찾아 개선했습니다. 새로운 도구를 시도하도록 장려하는 환경이 익숙하지 않은 문제에 도전하는 계기가 된 것입니다.

번역 기능은 일상에서 발견한 필요를 제품으로 연결한 사례였습니다. 인턴이 마을버스에서 외국인이 당근 앱을 사용하는 모습을 보고 번역 기능을 제안했습니다. 발표에서는 국내 거주 외국인이 인구의 약 5%라는 수치도 제안의 근거로 소개했습니다. 이 아이디어는 PoC(개념 검증)를 거쳐 실제 제품에 반영됐고, 상품 설명과 메시지, 후기 등에 번역 기능이 적용됐습니다.

PoC를 전사 미팅에서 공유한 뒤에는 북미팀에서도 요청이 왔습니다. 발표에서 소개한 미국 타깃 사용자 중 약 9%가 스페인어를 사용하고 있어, 북미에서도 번역 기능이 필요했던 것입니다. 이를 추진할 전담팀(TF)이 빠르게 구성되면서 인턴의 제안이 다른 지역의 프로젝트로까지 이어졌습니다.

이 사례에서 눈에 띄는 점은 제안 이후의 과정이었습니다. 직급에 관계없이 아이디어를 시험해 볼 수 있었고, 그 결과가 제품에 반영됐습니다. 전사 공유를 통해 다른 팀의 수요를 발견했을 때도 빠르게 팀을 구성해 실행으로 옮겼습니다. 개인의 관찰과 시도가 조직의 지원을 받아 실제 변화로 이어지는 문화를 보여줬습니다.

내 생각

다양한 AI 도구를 적극적으로 활용하도록 장려하고, 작은 아이디어도 빠른 의사결정을 통해 실제 TF 구성과 제품 반영으로 연결하는 문화가 좋았습니다. 새로운 도구를 시도하고 아이디어를 제안할 수 있는 분위기와, 이를 빠르게 실행으로 옮기는 추진력이 함께 갖춰져 있다는 점이 인상적이었습니다.

총평

이번 밋업에서는 당근이 AI를 코딩 보조에서 기획, 리뷰, 배포와 운영까지 업무 전반으로 확장해 가는 과정과 노하우를 살펴볼 수 있어 좋았습니다. 각 팀이 실제로 겪는 병목을 찾고, AI를 일하는 방식에 녹여 가는 구체적인 사례가 특히 인상적이었습니다.

코드 생산량이 늘어난 만큼 중요도에 따라 리뷰 기준을 세우고, 팀의 맥락을 담은 문서를 피드백으로 개선하며, 운영 지표를 문제 발견과 수정으로 연결하는 흐름이 기억에 남습니다. 이런 시도가 개인의 활용에 머무르지 않고 팀 공통 도구와 규칙으로 공유되고, 새로운 아이디어를 빠르게 검증하는 문화로 이어진다는 점도 참고할 만했습니다.

다만 Android Day라는 이름에서 기대했던 것에 비해, Android 기술 자체를 깊이 다루는 이야기는 상대적으로 적게 느껴져 아쉬웠습니다. DFM과 빌드 캐시, 게시글 상세 화면의 구조를 다룬 세션도 있었지만, 행사 전체를 돌아보면 AI를 어떻게 활용하고 업무 범위를 넓힐 것인지가 중심에 있었다는 인상이 남았습니다. 그래서 빌드 최적화와 화면 설계처럼 Android 개발 과정의 구체적인 고민을 다룬 세션이 더욱 반가웠습니다.

AI가 개발자의 일하는 방식을 크게 바꾸는 흐름을 이해하고, 실무에 적용할 아이디어를 얻었다는 점에서 유익한 시간이었습니다. 다음에는 AI 활용 경험과 함께 Android 기술 자체의 고민과 시행착오를 깊이 다루는 이야기도 더 많이 들을 수 있기를 기대합니다.