프론트엔드와 백엔드를 한 팀으로 합치면 어떤 일이 일어날까?
Summary
프론트엔드와 백엔드의 선을 넘다: 당근 광고주플랫폼팀의 원팀 통합 실험기
AI 레버리지와 온콜 런북을 무기 삼아, 경계를 허물고 기적적인 생산성을 증명한 엔지니어들의 이야기
당근 광고주플랫폼팀이 협업 병목과 대기 시간을 극복하기 위해 FE와 BE 직군을 하나로 합쳤습니다. 낯선 시스템 운영과 속도 저하에 대한 우려가 컸으나, 탄탄한 문서화와 AI 코딩 도구의 파워를 결합해 스프린트 속도를 고스란히 유지하는 데 성공했습니다. 이들이 겪은 현실적인 시행착오와 전문성의 역할 변화에 관한 생생한 인사이트를 소개합니다.
- 01스프린트당 최소 1회 반대 직군 티켓 수행 원칙을 통해 조율 비용을 획기적으로 감축했습니다.
- 02AI 코딩 가속기와 기존의 시스템 문서를 결합하여 이종 언어 및 기술 스택 전환 장벽을 극복했습니다.
- 03잘 갖춰진 온콜 Runbook 덕분에 타 직군 멤버도 중단 없이 시스템 장애에 효과적으로 대응할 수 있었습니다.
- 04개발자의 전문성이 코드 생산자에서 AI 결과물의 결함을 걸러내는 '최종 검증자'로 전환되는 경험을 했습니다.
- 05완성도를 80~90% 수준으로 빠르게 타협하는 대신 고속 배포를 취하고 상호 리뷰로 리스크를 감당했습니다.
RECOMMENDATION
직군 간 조율과 대기로 제품 딜리버리가 빈번히 정체되는 소규모 제품 개발 팀에게 강력히 권장합니다. 단, 도입 전에 팀원들의 성숙한 스프린트 합의 체계와 시스템 설계 문서, AI 도구 활용 습관이 갖춰져 있는지 필수적으로 자가 진단해야 합니다.
The Problem
프론트엔드와 백엔드가 서로 다른 팀으로 나누어져 있어 기능 개발 시 API 스펙 조율과 작업 대기가 반복적으로 발생하고 한쪽의 일정이 밀리면 전체 개발 흐름이 함께 지연되는 구조적 병목이 존재했습니다.
The Solution
프론트엔드와 백엔드 엔지니어 총 8명을 하나의 팀으로 통합한 후, 모든 팀원이 스프린트마다 반대 직군의 티켓을 최소 하나씩 해결하도록 배분하고 AI 코딩 도구와 사전에 정리된 시스템 기술 문서 및 장애 대응 런북을 적극 활용했습니다.
The Result
통합 첫 분기 동안 스프린트 완료량이 떨어지지 않고 안정적으로 유지되었으며, 낯선 도메인에 대한 상호 검증과 런북 보완을 통해 6월 한 달간 신규 장애 발생 0건을 기록하는 등 안정적인 운영을 확인했습니다.
Trade-off
1인 풀스택 개발 방식으로 인해 도메인 지식이 특정 인원에게 쏠리거나 전문성이 얕아질 수 있는 잠재적 리스크가 존재하며, 병렬 작업이 가속화되면서 스프린트 계획 외의 긴급 업무 비중이 3분의 2를 차지해 프로젝트의 장기 예측 가능성은 다소 저하되었습니다.
Key Concepts
More from 당근
View all posts from 당근당근의 인증은 어떻게 달라져 왔을까요?
OAuth 2.0OIDCSSO1주 전Laying the Rails Beyond WebView: Why Karrot Chose Lynx
LynxWebViewPerformance2주 전웹뷰 다음의 레일을 깔다: 당근이 Lynx를 선택한 이유
LynxReactQuickJS2주 전실험을 더 편하게 설계할 수 있게: 당근 실험플랫폼 이야기
AB TestingData PlatformLLM Agent3주 전천만 MAU를 지탱하는 커뮤니티 시스템을 소개해요
Modular MonolithStreaming SSROpenAPI1개월 전