29CM·문제사용자가 보유한 쿠폰을 어떤 상품에 적용할 수 있는지 확인할 방법이 없었음.
접근Kafka 기반 이벤트 드리븐 아키텍처로 실시간 데이터 동기화. Debezium CDC 로 변경 감지, 반정규화 테이블 구축, Elasticsearch 인덱싱.
결과쿠폰 적용 가능 상품 목록 조회 기능 론칭 및 쿠폰 도메인 전반의 성능·안정성 개선.
29CM·문제모듈화된 iOS 프로젝트에서 SwiftLint 가 증분 빌드마다 전체 코드베이스를 검사해 15~30 초 빌드 시간 소비.
접근Xcode 의 "Based on dependency analysis" 옵션 + xcfilelist + Git diff 기반 변경사항 추적 + Build Pre-actions 활용한 로컬 캐싱. CI/CD 는 danger-swift 통합.
결과SwiftLint 소요 시간 15~30 초 → 1~2 초로 단축. CI 에서 변경 파일만 검사해 린트 오류 누적 문제 해결.
29CM·문제제한된 리소스(0.5명)로 디자인 시스템을 효율적으로 구축하고 유지보수해야 함.
접근어드민은 Ant Design + Custom Theme, 대고객 서비스는 Ruler + TailwindCSS + tailwind-variants. Chromatic + Storybook 으로 QA 자동화, GitHub Projects 로 컴포넌트 추적 관리.
결과어드민 디자인 작업 75%, 개발 작업 87% 시간 단축. 37개 설계 중 30개 구현 완료. 팀 오픈소스 방식으로 기여 문화 확립.
29CM·문제29CM iOS 앱의 Cold Start 시간이 p50 기준 약 1.5 초로 느려 앱 시작 성능 개선 필요.
접근Xcode 15 Mergeable Libraries 도입. Debug 는 Dynamic library 로 빌드 시간 단축, Release 는 Static library 처럼 병합해 앱 시작 시간 개선. Tuist 80 개 모듈 프로젝트에 Manual 방식 적용.
결과Cold Start 400~500ms, Warm Start 180~250ms 개선. 버전 6.39.0 이상에서 약 29% 성능 향상.
29CM·문제프론트엔드 수시 배포에 비해 BVT 자동화 수행 시간이 길어 검증 주기가 맞지 않았고, Slack 봇 트리거 방식도 사용률이 5% 미만에 머물렀다.
접근사람 개입을 제거하고 프론트엔드 배포 파이프라인에 자동 트리거를 연결했다. 웹뷰 구간에 집중하고 테스트 기기를 3대로 병렬화했으며 케이스 단위 멘션 알림을 도입했다.
결과자동화 사용률이 5% 미만에서 100%로 올라 월 100회 이상 실행됐고, 사람 개입 비용을 제거한 설계가 사용률을 결정한다는 교훈을 얻었다.
29CM·문제29CM의 실시간 사용자 행동 데이터가 늘면서 트렌드를 빠르게 감지·반영할 수 있는 처리 기반이 필요했다.
접근Architecture Manifesto의 일부로 Event Streaming을 도입해 실시간 데이터 파이프라인 구조를 정비했다. MUSINSA TECH 유튜브 채널에서 백엔드 엔지니어가 도입 과정과 향후 활용 방향을 발표했다.
결과실시간 처리 기반을 갖춰 트렌드 감지와 대응 속도를 끌어올리는 토대를 마련했고, 후속 활용 시나리오를 공개했다.
29CM·문제29CM 검색 시스템이 체계적으로 구조화돼 있지 않아 개발 효율과 성능이 동시에 떨어졌고, 기능을 추가할수록 코드가 얽혀 고도화가 어려운 상태였다.
접근검색 도메인의 핵심 개념을 먼저 정의하고 이를 기준으로 레이어를 분리한 도메인 기반 아키텍처를 수립했다. 정리된 구조 위에서 속성 패싯 추출 자동화를 첫 고도화 과제로 진행했다.
결과검색 성능과 사용성이 함께 개선됐고, 도메인 정의가 명확해진 덕분에 이후 기능 확장과 리팩토링을 이어갈 기반이 마련됐다.
29CM·문제반복적인 호환성 테스트와 수작업 데이터 준비로 QA 인력이 소진되고 있었고, 긴 시간 동일 작업을 반복하다 보면 집중력이 떨어져 결함을 놓치는 일이 생겼다.
접근Android UI 자동화, API 기반 End-to-End 테스트, 테스트 데이터 자동 생성 도구를 직접 개발해 QA 업무에 엔지니어링 역량을 결합했다.
결과테스트 데이터 생성 자동화로 프로젝트 QA 기간의 리소스를 크게 절감했고, 더 다양한 케이스를 다룰 여력이 생겼다. 팀 전체의 개발·테스트 비용이 함께 줄었다.
29CM·문제주 1회 배포 주기에서 Android UI 자동화의 실패율이 높아 유지보수 비용이 컸다. UI 경로 변경, Webview 핸들러 잔존, 파이프라인 타이밍 문제가 서로 얽혀 원인 파악이 어려웠다.
접근변경된 ID와 경로값을 개발팀과 함께 정비하고, 시나리오별로 케이스를 분리한 뒤 종료 시점에 앱을 재실행해 Webview 핸들러 히스토리를 비웠다. 화면 전환에는 명시적 대기를 넣고 로컬·STF·파이프라인의 다층 검증을 거치도록 했다.
결과초기 대비 fail률이 현저히 낮아졌고, 자동화가 다시 신뢰할 수 있는 회귀 도구로 자리를 잡았다.