당근모임 MAU 1,000만 돌파와 20,000 RPS 트래픽 대응
당근 커뮤니티실은 2026년 7월 기술 블로그를 통해 지역 기반 커뮤니티 플랫폼을 지탱하는 백엔드와 프론트엔드 아키텍처 변천사를 공개했습니다. 2026년 상반기 결산 발표에 따르면 '당근모임'의 월간 활성 사용자(MAU)는 1,000만 명을 돌파했으며, 커뮤니티 탭 전체 체류시간은 전년 동기 대비 103% 늘어났습니다. 모임 가입자 수는 128%, 생성 일정은 106% 증가하는 등 지역 주민 간 교류가 급증했습니다.
트래픽 규모 또한 크게 확장되었습니다. 2021년 가을 기존 레일즈 모놀리스 환경에서 커뮤니티 영역을 분리해 독립 시스템을 구축했을 당시 서버앱의 초당 요청 수(RPS)는 약 100건 수준이었습니다. 이후 당근모임의 전국 단위 공개 시점에 4,000 RPS로 증가했고, 당근아파트와 당근카페 등 신규 서비스가 잇달아 연계되면서 2026년 상반기 기준 약 20,000 RPS를 처리하는 단계에 이르렀습니다.
조직 규모에 맞춘 기술적 타협: '모듈형 모놀리스' 선택
일반적으로 대규모 트래픽과 다각화된 서비스 라인업을 다룰 때 마이크로서비스 아키텍처(MSA) 도입이 당연한 정답처럼 거론됩니다. 그러나 당근 커뮤니티실은 동네생활, 모임, 카페, 아파트 등 다수의 도메인을 다루면서도 서버를 서비스별로 쪼개지 않고 단일 서버앱(Modular Monolith)으로 유지하는 결정을 내렸습니다. 서비스 개수에 비해 엔지니어링 인력이 적은 소규모 운영 조직의 현실적인 한계를 감안한 선택이었습니다.
인프라와 배포 파이프라인의 복잡도를 높이는 대신 내부 도메인 경계를 명확히 분리하는 방식을 택했습니다. 게시글, 댓글, 알림, 프로필 등 공통 요소가 유사하게 반복되는 커뮤니티 제품 특성을 살려 코드를 공유하되, 서비스별로 상이한 지역성 정의와 인증 기준은 독립된 모듈로 철저히 격리했습니다. 유행하는 기술 구조를 맹목적으로 따르기보다 유지보수 주체인 엔지니어 조직의 지속 가능성을 우선한 실용적 접근으로 평가할 수 있습니다.
전사 플랫폼 격리와 안정성 보호를 위한 연동 안전장치
커뮤니티 시스템은 당근 내부의 전사 기반 인프라인 계정, 채팅, 미디어, 지역, 검색 플랫폼에 크게 의존합니다. 이들 플랫폼과 연동하는 과정에서 외부의 데이터 모델과 비즈니스 로직 변경이 커뮤니티 도메인 내부로 직접 전파되지 않도록 '공유 플랫폼 모듈'이라는 완충 계층을 구축했습니다. 외부 시스템의 엔티티를 내부 도메인 전용 모델로 변환해 소비하는 어댑터 패턴을 적용한 것입니다.
과거 겪었던 외부 연동 구간의 장애 경험을 바탕으로 시스템 방어 기제도 정교화했습니다. 타 플랫폼 호출 시 엄격한 호출별 타임아웃(Timeout)과 요청 취소, 독자적인 예외 변환 처리를 의무화했습니다. 트래픽 병목이나 외부 장애 발생 시 즉각 실패를 격리할 수 있도록 주요 호출 경로에 서킷 브레이커(회로 차단기)를 배치하여 특정 연동 이슈가 전체 커뮤니티 마비로 확산하지 않도록 통제했습니다.
웹뷰의 한계를 극복한 스트리밍 SSR 프론트엔드 전략
사용자 인터페이스 계층에서도 성능 최적화가 진행되었습니다. 커뮤니티 탭과 프로필, 모임, 동네생활, 아파트 등 대다수 접점은 빠른 배포와 화면 실험을 위해 앱 내 웹뷰(WebView)로 구현되었습니다. 단, 검색 유입이 중요한 당근카페 서비스에 한해 웹뷰와 일반 웹사이트를 동시 지원하는 구조를 취했습니다.
기존 클라이언트 사이드 렌더링(CSR) 방식은 초기 기동 비용과 네트워크 환경 편차로 인해 첫 렌더링 지연이 발생하는 문제를 겪었습니다. 이에 서버 사이드 렌더링(SSR)을 적용했으나, 복합 API 응답이 지연되면 화면 백화 현상이 길어지는 한계가 드러났습니다. 커뮤니티실은 화면의 뼈대를 즉시 내려보낸 뒤 필요한 본문 데이터를 순차 전송하는 '스트리밍 SSR(Streaming Server-Side Rendering)'을 정착시켰습니다. 렌더링 오류가 발생하거나 응답 지연이 임계치를 넘길 경우 CSR로 즉각 폴백(Fallback)하는 예외 장치도 함께 마련했습니다.
지표 측정의 조건과 실무 적용 시 확인해야 할 한계
이번 공개 사례는 소규모 엔지니어링 팀이 대규모 트래픽을 처리하는 현실적 해법을 제시하지만, 실무에 참조할 때 유의해야 할 공백도 존재합니다. 공개된 20,000 RPS는 커뮤니티 단일 서버앱 전체의 처리량 수치이며, 평시 평균값인지 순간 피크(Peak) 수치인지는 구분되지 않았습니다. 또한 천만 MAU라는 수치는 커뮤니티 탭 전체의 순수 이용자가 아니라 단일 서비스인 '당근모임'의 상반기 지표라는 점을 구분해서 해석해야 합니다.
또한 과거 레일즈 환경에서 분리된 현재 서버앱의 구체적인 메인 언어와 프레임워크(Go, Node.js, Spring 등) 사양은 글에서 특정되지 않았습니다. 따라서 이를 자사 환경에 적용하려는 실무팀은 프레임워크나 툴 자체를 모방하기보다, 복잡한 비즈니스 규칙을 명확한 모듈 경계로 관리하고 외부 결합도를 낮추는 아키텍처 거버넌스 원칙을 벤치마킹하는 것이 유효합니다.
출처
당근 기술 블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
천만 MAU를 지탱하는 커뮤니티 시스템을 소개해요 (새 창)
