직군 분리 사일로 해소를 위한 8인 단일 팀 개편과 운영 원칙
당근 공식 기술 블로그에 따르면 당근 광고실 광고주플랫폼팀은 2026년 4월부터 프론트엔드(FE) 엔지니어 4명과 백엔드(BE) 엔지니어 4명을 합친 총 8명 규모의 단일 팀 운영 실험을 진행했다. 기존에는 광고 생성부터 집행 리포트까지 연결되는 사용자 여정을 개발할 때 FE와 BE가 분리되어 있어 동일 기능임에도 티켓이 이원화되고 API 스펙 확정 대기와 스프린트 일정 불일치 등 조율 비용이 누적되던 구조였다.
팀은 2주 단위 스프린트 체제에서 두 가지 원칙을 적용했다. 첫째는 '배분'으로, 모든 팀원이 스프린트마다 최소 1개 이상의 반대 직군 티켓을 의무적으로 수행하도록 했다. FE 엔지니어에게는 간단한 BE 운영 티켓을, BE 엔지니어에게는 자체 작업에서 파생되는 FE 화면 개발을 배정했다. 둘째는 '시범'으로, BE 출신 엔지니어링 매니저가 FE 화면 구현과 시스템 마이그레이션을 솔선하여 수행하고 검증 도구를 팀에 공유함으로써 낯선 기술 스택에 대한 심리적 장벽을 낮췄다.
기술 문서 축적과 AI 코딩 도구 결합을 통한 교차 개발 실행
팀의 기술 스택은 백엔드가 JVM 계열, 프론트엔드가 React 기반으로 서로 상이했으나, 기존 문서 자산과 AI 코딩 도구를 연계해 진입 비용을 절감했다. 1분기에 사전에 마련해 둔 팀 매니페스토, 워킹 어그리먼트(Working Agreements), 온콜 런북(Runbook), 모니터링 대시보드, 아키텍처 다이어그램 및 데이터베이스(DB) 스키마 문서가 기초 맥락으로 작동했다.
2분기에는 사내 '기술 문서 저장소'를 신설해 수백 건의 도메인 문서와 수정 내역을 집적했다. 프로젝트 진행 중 생성된 기획서와 테크스펙(Tech Spec)은 즉시 AI 에이전트의 입력값(컨텍스트)으로 재활용되었으며, AI 도구가 초안 코드를 신속히 생성하도록 지원했다. 낯선 서비스 장애 대응 시에도 사전 정의된 런북 매뉴얼을 활용해 특정 담당자에게 병목이 발생하지 않고 당번 엔지니어가 대응할 수 있는 기반을 갖췄다.
완료량 수치 유지 이면의 측정 한계와 안정성 지표의 불확실성
당근 광고주플랫폼팀은 통합 전 BE 4명 기준 완료량을 바탕으로 8명 팀의 기대치를 높여 설정했음에도 4번의 스프린트 동안 총 완료량이 줄어들지 않고 유지되었다고 발표했다. 그러나 이를 조직 통합의 완전한 생산성 성공으로 단순화하기에는 명확한 측정 한계가 존재한다. 본 작업량은 팀 내부의 주관적 추정치인 '스토리 포인트(Story Point)'로 집계되어 외부 및 타 조직과의 객관적 비교가 불가능하다.
팀 내부 회고에서도 지적되었듯 AI 도구 활용으로 개별 작업 속도는 빨라졌으나 스토리 포인트 산정 기준이 과거 관행에 머물러 있어 완료량이 과대평가되었을 가능성을 배제할 수 없다. 또한 4월 초 결제(빌링) 중단 등 누적 인프라 장애가 집중된 이후 6월 신규 장애 0건을 기록했으나, 당근 측 역시 이것이 직군 통합의 성과인지 병행된 신뢰성 인프라 투자 효과인지, 혹은 우연에 기인한 것인지 명확한 인과관계를 분리 검증하지 못했다고 인정했다.
속도 중심 타협과 계획 예측가능성 상실이라는 실무적 대가
이번 실험에서 팀은 코드 완성도를 100%까지 끌어올리기보다는 80~90% 수준을 수용하고 실행 속도를 취하는 전략적 타협을 선택했다. AI 작성 코드의 잠재 리스크는 상호 테크스펙 리뷰와 감시 대시보드라는 사후 안전망으로 관리하고자 했다. 그러나 1인이 화면부터 서버까지 완결 짓는 속도가 빨라지자 심각한 계획 예측가능성 상실 문제가 드러났다.
각 엔지니어가 병렬로 업무를 완결하는 과정에서 돌발 작업과 긴급 요청이 무분별하게 유입되었고, 그 결과 2분기 동안 팀이 처리한 전체 업무량 중 약 66.7%(3분의 2)가 스프린트 계획 수립 당시 없었던 무계획 작업으로 채워졌다. 아울러 전체 완료량의 약 33.3%(3분의 1)는 신규 기능이 아닌 운영 및 유지보수에 소모되었다. 빠른 실행력이 정작 팀 차원의 중장기 우선순위 통제력을 약화시키는 결과를 초래한 셈이다.
팀 응집도 약화와 장기 아키텍처 부채에 대한 검증 필요성
풀스택 1인 완결 체제로의 전환은 팀 협업 감각과 심층 전문성 유지 관점에서 새로운 부작용을 남겼다. 동료의 구체적인 업무 진행 상황을 서로 인지하기 어려워지며 '원팀'으로서의 응집도가 저하되었고, 스프린트 도중 수시로 유입되는 작업으로 인한 야근 및 온콜 당번 시 고객 지원(CS) 부담 가중이라는 실무 피로도가 수반되었다.
더욱이 공개된 내용은 2026년 2분기(4월~6월) 한 분기 동안의 단기 실험 결과에 국한된다. 투입된 구체적인 AI 상용 도구 명칭이나 백엔드 세부 언어는 밝혀지지 않았으며, 80~90% 수준의 코드를 지속적으로 수용할 때 장기적으로 시스템 아키텍처 부채가 어떻게 누적되는지, 직군별 심층 전문성의 질적 저하를 어떻게 방지할 것인지는 향후 추가적인 검증과 제도적 보완이 요구되는 영역이다.
출처
당근 기술 블로그의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.
프론트엔드와 백엔드를 한 팀으로 합치면 어떤 일이 일어날까? (새 창)
