게임에서 시작해,
지금은 웹이 만나는 문제를 풀어가고 있어요.

전사 웹프론트의 일하는 방식 재설계

그룹장을 맡기 전인 2023년, 서버 조직 구조를 따라 도메인별로 나뉜 전사 웹프론트의 일하는 방식을 바꾸는 안을 세 차례에 걸쳐 만들었습니다. 1월에는 흩어진 공통 기술을 전사 단위로 모으는 그룹 구조 개편안을 작성해, 디자인시스템 TF(4개 팀 14명), 개발 도구 공통화, 공통 기술 워킹그룹으로 나누고 워킹그룹마다 시니어 개발자를 함께 두는 안을 제안했습니다.

4월에는 조직별 업무와 인력 배치를 진단해, 명확한 담당 없이 여러 조직이 나눠 하던 공통 업무를 맡을 조직을 먼저 분리하고, 웹프론트 조직을 모아 웹앱 게이트웨이와 백오피스 플랫폼 같은 파트별 플랫폼을 키우는 단계별 개선안을 만들었습니다.

7월에는 100명에 가까운 전사 웹프론트 개발자가 기획, 디자인, 서버, QA와 맞닿는 지점마다 비효율을 줄일 장치를 둔 로드맵을 그렸습니다. 기획과 디자인 사이에는 어드민 디자인 가이드라인을, 디자인과 개발 사이에는 우아한공방을, 서버와 프론트 사이에는 인터페이스 공유 방식을, QA와의 사이에는 테스트 플랫폼과 기능 단위 프리뷰 배포를 두고, 요청부터 운영 배포까지의 반복 업무는 업무 자동화 도구로 줄이는 구성입니다.

이 안은 우아한공방 1.0 배포(2023.10), 프리뷰 배포와 업무 자동화 도구 운영, 2024년 1월 조직개편으로 이어졌습니다. 조직개편에서는 제가 맡던 웹프론트 조직을 서비스, 플랫폼, 공통의 세 팀으로 나눠 두 팀은 새 리더가 맡도록 했고, 전사 공통 업무를 공식 업무로 맡는 배민공통서비스웹프론트개발팀을 신설해 직접 이끌었습니다. 이 팀에서 개선안의 파트별 플랫폼에 해당하는 웹뷰 통합 게이트웨이와 Module Federation 어드민 플랫폼을 만들었습니다.

리더를 통한 조직 운영과 인력 배분

그룹장, 직군리드, 파트리드, 엔지니어의 역할을 구분하고 운영 가이드를 작성했습니다(2026.01). 10개 영역에 직군리드 10명과 파트리드 15명을 두었습니다. 직군리드는 도메인 기술 방향과 리소스 배분을 제안하고, 파트리드는 차기 리더 육성을 맡도록 했습니다. 구성원도 RFC로 기술 과제를 제안할 수 있도록 했습니다.

2025년 4분기 인력을 조직과 과제 단위로 배치하면서, 제품 과제와 함께 피처 플래그, 기술 표준화, 장애 대응 어드민 등 공통 기술 과제에도 인력을 배정했습니다.

채용이 제한된 시기에 조직 간 로테이션을 구상하고, 2026년 5월부터 7월까지 11명의 이동을 관련 조직과 협의해 진행했습니다. 사업에 필요한 인력과 구성원의 성장 기회를 함께 고려했고, 모든 이동이 순조롭지는 않았지만 대부분 새 조직에 자리를 잡았습니다.

약 80명이 참석하는 전사 웹프론트개발 시스템 회의를 주관하고, 서버 그룹장과 별도 미팅을 만들었습니다. 그룹 예산으로 워크숍과 스터디, 공유회를 운영했고, 2026년 4월에는 그룹의 첫 사내 밋업(66명 참석)과 외부 신청자 1,582명 중 110명을 초대한 첫 외부 오픈 밋업을 열었습니다.

사업과 조직 변화에 맞춘 목표 운영

그룹장을 맡은 뒤 그룹 목표를 OKR로 세워 운영했습니다. 2025년 4분기에는 안정적인 배포와 운영 기반, 데이터 기반 품질 측정, 그룹 문화의 3개 Objective와 10개 KR을 세우고 실행 과제 14개 중 12개를 마쳤습니다. 소나큐브를 전체 서비스에 적용해 테스트 커버리지 평균 20%를 확보했고, 1, 2티어 서비스에 표준 배포 시스템을, 그룹 전체에 Sentry 표준을 적용했으며, 시니어가 이끄는 사내 교육을 8회 열었습니다.

2026년 상반기에는 CTO 목표인 성장과 AI에 맞춰 역량, 개발 생산성, 데이터 기반 의사결정, 안정 운영, 소속감의 5개 Objective와 26개 KR을 세우고, 도메인 직군별 OKR로 이어지게 했습니다. 안정 운영 KR로는 장애 초동 대응 5분 이내, 프론트엔드 장애 MTTR 30분 이내, 테스트 커버리지 평균 40%(2025년 목표 20%에서 상향)를 두었습니다.

하반기에는 모든 웹프론트 개발자가 목적조직의 목표에 맞춰 일하게 되면서, KR 중심의 그룹 OKR로는 실제 업무를 담기 어렵다고 판단했습니다. 그래서 그룹은 Objective 4개와 Initiative 12개로 방향을 정하고, 직군리드들이 나눠 맡은 19개 도메인별로 Initiative를 직접 등록하도록 바꿨습니다. 진행률과 상태는 직군리드 회의에서 함께 점검합니다.

하반기 그룹 KR은 가용성과 장애 대응만 남겼습니다. 2025년 현황(Critical 장애 감지 3분, 장애 복구 45분, 1, 2등급 장애 기준 가용률 99.999%)을 바탕으로, Critical 외 장애의 감지 시간은 54분 이하(2025년 400.5분)로, 내부 원인 장애의 복구 시간은 30분 이하로, 장애 영향시간 비율은 2.5% 이하(2025년 약 3.5%)로 낮추는 목표를 세웠습니다.

채용과 리더 육성

160회 이상 면접을 진행하며 전사에서 40명 이상을 직접 채용했고, 현재 그룹 구성원의 30% 이상이 직접 채용한 인원입니다. 이 중 약 3분의 1은 T2로 입사해 T3로 승급했습니다.

커머스 웹 조직을 5명에서 25명으로 확대하며 20명을 직접 채용했습니다. 채용 시장을 고려해 커머스 웹의 기술 스택을 Vue에서 React로 옮겼고, 전환 뒤 채용 지원율이 평균 12배 늘었습니다(우아콘 2022 발표).

시니어마다 책임질 기술 영역을 정하는 시니어 커버리지를 도입했습니다(2025.07). 분기별 인원 배치와 역량레벨 승급을 직접 운영하고, 정기적인 1:1과 피드백으로 구성원의 성과와 성장을 지원했습니다.

FE 직무 역량레벨 개정안을 작성해 제안했습니다(2025.04). 비즈니스와 사용자 관점을 평가 기준에 넣고, T3부터 T5까지의 역할 기대치를 사례로 구체화했습니다.

주문 조직에 주도적으로 일할 리더가 필요하다고 보고, 다른 조직에서 적극적으로 일하던 구성원을 주문으로 옮겼습니다(2026.07). 제가 주문 직군리드를 겸하며 하반기 목표를 직접 세웠고, 실장과 함께 이 구성원이 주문에서 신뢰를 쌓도록 지원했습니다. 이 구성원이 주문의 리더로 자리 잡아 지금은 직군리드 역할을 점진적으로 넘기고 있습니다. 저는 주문과 결제 핵심 기능의 회귀를 배포 전에 찾고 기능별로 배포 범위를 나누는 등 장애를 줄이기 위한 구조 개선 과제를 발의해 함께 살피고 있습니다.

신규 앱 심플의 구조 결정과 출시

웹 개발자 약 35명이 참여한 신규 앱 심플에서 심플코어 TF장으로 웹 구조를 정했습니다(2026.01). 약 두 달 안에 탑바와 하단 탭을 뺀 콘텐츠 영역을 모두 웹으로 만들어 임직원 CBT를 열고, 이후에는 화면을 도메인 조직별로 넘겨야 하는 조건이었습니다.

먼저 디자인시스템 담당자들과 2주간 PoC를 진행해, 배민 메인홈에 처음 적용하는 하이브리드 구조(앱 내비게이션과 웹 콘텐츠)를 메인홈부터 메뉴 상세까지 만들어 보고 성능과 스크롤, 화면 전환 문제를 미리 확인했습니다(2025.12 ~ 2026.01).

도메인별 저장소 분리, 워크스페이스 모노레포, 전 화면 마이크로 프론트엔드를 비교해, 개발 속도와 TF 이후 도메인별 이관을 기준으로 한 저장소 안에 도메인별 독립 프로젝트를 두는 모듈러 모놀리스와 트렁크 기반 개발을 택했습니다. 공통 패키지는 최소한의 공통 컴포넌트, 큐레이션 모듈, 딥링크, 앱 연동 인터페이스로 좁히고 기술 스택을 표준으로 정했습니다.

앱과 웹의 경계는 앱, 서버 담당자들과 함께 정했습니다. 메인홈은 앱과 웹이 같은 API를 쓰고, 웹에 장애가 나면 앱이 최소한의 화면으로 대신하며, 서버 응답에서는 레이아웃과 스타일 로직을 빼고 데이터만 받아 프론트에서 화면을 그리는 원칙을 세웠습니다(2026.01). 이어 웹뷰 화면 템플릿, 장바구니 수량 동기화, 신구 버전 라우팅 같은 경계 결정을 주 단위로 정리했습니다.

정리된 경계는 CBT까지 다시 논의하지 않는다는 원칙을 세워 2월 2일 개발을 시작해 3월 31일 계획대로 운영 배포했습니다. 3월 말에는 OBT까지 남은 과제 20개를 필수, 제외, 재검토로 다시 나눠 범위를 줄이고 TF 인원 구성을 조정했습니다. 4월에는 CBT를 열었고, 심플 웹 주간 싱크를 만들고 앱 협업 창구를 하나로 모았으며, 회고에서 가장 많이 지적된 의사결정 과정과 오너 지정 문제의 개선을 맡았습니다.

앱과 웹의 연동 기반

그룹 RFC로 제안된 웹뷰 캐시 정책을 앱 그룹과 협의해 배민앱의 기본 동작으로 적용했습니다(2025.03). 적용 후 주문, 커머스, 공통 화면의 FCP와 LCP(p75)가 모두 개선됐고, 주문 화면은 FCP가 약 16%, LCP가 약 21% 빨라졌습니다. 이후 배포 파일 종류별 캐시 기준을 그룹 표준으로 정리했습니다(2025.12).

분산된 공통 웹앱을 웹뷰 통합 게이트웨이로 묶었습니다. 서비스마다 따로 두던 도메인, CDN, 저장소를 하나로 합치고, 앱은 원격 설정으로 화면 경로를 받도록 설계했습니다. 아키텍처 정리, 레포 통합, 운영 프로세스 통일 순서로 진행했습니다(2024 ~ 2025).

B마트 웹과 앱 사이의 딥링크, 브릿지, 앱 저장소 호출을 하나의 타입 기반 프로토콜(BWAP)로 묶어 앱 버전별 분기 코드를 정리했습니다(우아콘 2021 발표).

앱 그룹장과 별도 미팅을 만들었고, 2026년 9월에는 앱 그룹과 합동 밋업(111명 참석)을 열었습니다.

Android, iOS, Web을 아우르는 디자인시스템

조직개편으로 디자이너와 Android, iOS, Web 개발자가 함께 일하게 된 디자인시스템팀을 맡았습니다(2026.06). 업무 현황을 정리하고 위키, 채널, 저장소를 통합했습니다. 생성형 AI 플랫폼, 실험, 반복 업무 자동화, 클레이 블루 2.0의 목적별 조 4개로 과제를 나눴고(2026.07), 공통 OKR(2026.06)과 하반기 로드맵(2026.08)을 수립했습니다. 심플 웹 화면의 디자인시스템 적용률은 정적분석으로 측정해, 토큰과 컴포넌트 적용률 100%를 하반기 KR로 두었습니다.

디자인시스템을 AI 기반 화면 생성에 활용하는 플랫폼으로 확장하는 방향을 수립했습니다(2026.05). 데이터, 컴포넌트와 패턴, MCP, 생성 도구의 4계층으로 나누고 2026년 12월까지 MCP와 생성형 UI 프로토타입을 구축하는 것을 목표로 두었고, 우아한공방 MCP를 공개한 데 이어(2026.08) 생성 도구인 클레이디자인을 목표보다 이른 10월에 전사에 열었습니다. Android와 iOS 코드 내보내기까지 지원하며, 9월 21일 OBT 이후 활성 사용자 64명이 화면을 1,143회 생성하고 피그마로 458회 내보냈습니다(2026.10.01 기준).

이 방향에 맞춰 팀의 일도 바뀌어, 팀 지라 이슈 중 AI 관련 과제 비중이 1월 2%에서 9월 43%로 늘었습니다(2026년 1~9월 678건, 2025년 한 해 18건). 3분기에는 배민실험실 다크테마 베타를 열어 설문 참여자 13명 중 12명이 만족했고, 아이콘 제작 자동화로 3~4시간 걸리던 작업의 초안을 1~2분에 만들 수 있게 했습니다.

디자인시스템은 B마트 서비스 디자인시스템(2020)부터 배민 웹 디자인시스템(2022), 우아한공방(2023년 이후), 백오피스 디자인시스템 통합(2025)까지 이어서 맡았습니다. 기존 디자인시스템을 프로덕트에 적용하며 발견한 문제를 상위 조직과 논의하고 우아한공방 전환을 추진했고, 앱과 백오피스 리더들과 적용 기준을 맞춰 공통 디자인시스템의 사용 범위를 넓혔습니다(2022 ~ 2025).

전사 디자인시스템 TF에서는 웹 리드로 토큰, 컴포넌트, 비즈니스 패턴, 서비스 코드로 계층을 나눈 아키텍처 초안을 작성했고(2024.08), 배포 구조를 잡고 사용 가이드를 썼습니다. 우아한공방 1.0을 배포했고(2023.10), 새 배민스토어 웹사이트에서는 컴포넌트 구현 코드가 75% 줄었습니다(우아콘 2023 발표).

독립 배포와 조직 변화에 대응하는 플랫폼

50개가 넘는 사내 어드민의 중복 개발을 줄이기 위해, 여러 어드민을 독립 배포 가능한 모듈로 조합하는 Module Federation 플랫폼을 도입했습니다. 팀마다 배포 주기와 개발 방식을 유지하면서 인증과 권한은 한곳에서 관리하도록 설계했고, 관리 도구(리모콘)에서 Host 재배포 없이 Remote를 등록하고 버전을 바꿀 수 있게 했습니다(2024). 임직원 제보 어드민에 먼저 적용한 뒤 전사 10개 이상의 프로덕트로 넓혔고, 관리 도구에서 컴포넌트와 페이지 단위 모듈로 나눠 관리하도록 했습니다. 통합 어드민에서는 각 어드민을 따로 떼어 내거나 합칠 수 있게 해 통합 커머스어드민과 통합공통어드민으로도 쉽게 나눴고, 이처럼 도메인을 쉽게 나누고 합칠 수 있다는 점을 들어 어드민 구조에 관한 의사결정을 이끌었습니다. 우아콘 2024에서 발표했습니다.

커머스 웹을 4계층 구조와 아토믹 컴포넌트로 설계했고(2021), 플랫폼 교체에 맞춰 계층 구조를 재설계했습니다(2022). 플랫폼 파트와 서비스 파트의 모노레포, 사내 배포 플랫폼으로 B마트, 배민스토어, 디자인시스템, 쇼핑라이브의 개발과 배포 방식을 맞췄습니다(2022).

장애 대응과 표준 배포 체계

그룹장을 맡은 직후 6개월(2025.06 ~ 11) 동안 웹프론트가 원인인 장애가 11건으로 늘었습니다(취임 전 12개월은 10건). 주문 생성 불가 장애 이후 장애 대응 표준, IC(Incident Commander) 역할과 대응 어드민을 마련했고, 모의 장애 훈련(2025.07, 2025.10)으로 절차를 점검했습니다.

2025년 8월 장애 안정화 계획을 세워 배포 전 릴리즈와 롤백 계획, 시니어 승인, 배포 후 테스트를 필수 절차로 정했습니다. 이어 배민앱 안의 모든 웹 화면에 적용할 표준 배포 시스템 TF를 8개 도메인의 엔지니어와 시작했습니다. 배포 파일은 덮어쓰지 않고 버전으로 관리하는 것을 필수 기준으로 두었고, 2025년 10월 표준 배포 시스템 가이드를, 12월 마이그레이션 가이드를 공개했습니다.

이 절차와 표준 배포 시스템을 적용한 뒤 11개월(2025.12 ~ 2026.10) 동안 웹프론트가 원인인 장애는 5건으로 줄었고, 모두 Warning 등급이었습니다. 2025년 장애에서 나온 재발 방지 과제는 72개 중 63개를 마쳤습니다. 2026년 목표는 장애 횟수보다 감지와 복구 시간에 두어, 배포를 위축시키지 않으면서 장애의 영향을 줄이도록 했습니다.

성능 기준과 개선

심플 이후 주요 화면의 p75 LCP를 실측해 그룹 성능 기준(LCP, FCP 1.5초 이하)을 정했습니다(2026.04). 이후 검색과 주문서 화면부터 개선해, 4월 p75 기준 2.7초였던 검색 화면의 LCP가 10월에는 p90 기준으로도 1.5초 수준이 됐습니다.

2022년 회사의 기술 부채 해결 기간(피트스탑)에 주문 영역을 Vue에서 React와 SSR로 옮겨, 새 장바구니의 FCP를 1,146ms에서 375ms로, 페이지 리소스를 4.3MB에서 1.5MB로 줄였습니다(우아콘 2022 발표).

기술 표준과 개발 생산성

그룹장을 맡기 전인 2025년 2월 그룹 RFC 절차를 직접 만들었고, 지금까지 RFC 16건 중 11건을 Sentry 관리 표준, 테스트 작성 표준, 사내 어드민 인증과 권한 표준 같은 그룹 표준으로 확정해 적용했습니다. 2025년 12월에는 절차를 다시 정비했습니다. 푸드, 공통, 주문 도메인의 요구가 맞물리는 기술 결정에서는 관련 조직의 의견을 조율했습니다.

배민공통서비스웹프론트개발팀을 맡아 팀의 책임을 개별 화면 개발에서 공통 플랫폼 구축으로 넓혔습니다. 중복 개발하던 기술은 구성원이 참여하는 자발적 TF 5개로 묶어 표준화했고, 여러 서비스를 적은 인력으로 운영하도록 저장소와 폴더 구조를 통일하고 표준 밖의 기술은 리뷰를 거쳐 도입하도록 했습니다(2025).

코드 리뷰 자동화, 디펜던시 봇, 지라 릴리즈 자동화 같은 사내 개발 도구를 기획하고 개발했습니다(2021 ~ 2025). 이 중 코드 리뷰 봇은 156개 프로젝트에서 3만 건이 넘는 MR을 처리했습니다(2026년 4월 기준).

AI 활용을 그룹 핵심 목표로 정하고 AI TF를 구성했습니다(2025.07). 웹과 앱의 AI 테스트 자동화를 추진하고, 프론트엔드 AI 코딩 도구를 PoC로 비교했습니다(2025.09).

2026년 5월에 세운 4계층 방향을 2027 디자인시스템 구조안으로 넓혔습니다(2026.10). 토큰 같은 디자인시스템 데이터를 OS와 버전별로 관리하는 데이터 계층과 지식베이스, 공통 컴포넌트, MCP와 피그마 플러그인, 생성 도구 같은 응용으로 계층을 나누고, 사용처는 라이브러리 버전에만 의존하게 하는 구조입니다. 역할도 아래 세 계층을 만드는 플랫폼 엔지니어와 디자이너, 그 위에서 직군 구분 없이 서비스를 빠르게 만드는 앱 개발자로 나눴습니다.

배민 웹을 외부 채널에서도 사용할 수 있도록 채널별 Host가 인증과 앱 연동을 담당하는 마이크로 프론트엔드 프로그램을 시작했습니다(2026.09). 첫 적용 과제로 외부 AI 서비스와의 주문 연동을 이끌고 있으며, Host는 라우팅과 앱 연동만 맡고 화면은 각 도메인이 그리는 구조로 정했습니다.

조직 단위의 개발 생산성 개선을 위해 DX팀 신설을 제안했습니다(2026.04). 에이전트용 개발 환경과 사내 개발 플랫폼 운영을 포함한 단계별 로드맵을 작성했습니다.

AI 에이전트가 배포를 요청하고 운영 배포는 승인을 거치는 MCP 기반 자동화를 설계해 제안했습니다(2026.05).