MUSINSA 무신사

"AI 시대에 개발자를 어떻게 평가하는가." 이 질문 하나로, 하나의 채용 시스템을 설계했습니다. 그 과정을 세 편의 글에 남겼습니다. · Part 1 — The Philosophy | 평가 철학의 재구성 · Part 2 — The Machine | 400명을 분류하는 머신 · Part 3 — The Human | 점수 너머에서 사람이 확인한 것 ───────────────────── 시작은 단순한 가설이었습니다. "AI가 코드를 만드는 시대라면, 코드를 읽는 일도 AI가 한다." 실제로 머신은 잘 작동했습니다. 400여 명의 제출물을 분류하고, Base(기능)와 Depth(사고)를 분리해 채점하고, 각 후보자의 코드를 읽어낸 맞춤 면접 가이드까지 만들어냈습니다. 필터로는 충분했습니다. 그러나 면접장에서 본 것은 달랐습니다. 같은 도구, 같은 시간, 같은 문제. 그런데 결과의 스펙트럼은 넓었습니다. 머신이 같은 패턴으로 분류한 사람들이 면접에서 극단적으로 갈라졌고, 같은 가이드를 받은 면접관이 전혀 다른 깊이의 대화를 이끌어냈습니다. 사람이 개입하는 지점에서, 머신이 보지 못한 것들이 드러났습니다. ───────────────────── 시리즈를 마치며, 한 문장을 덧붙이게 됐습니다. "도구가 강력해질수록, 도구를 쓰는 사람의 판단이 결과를 가릅니다. 적어도 지금은." 처음의 질문은 여전히 유효합니다. 다만 답은 조금 달라집니다. "기계가 이것을 할 수 있는가"에서, "이것이 여전히 사람이 집중해야 할 문제인가"로. 이번 채용을 통해, 그 빈자리의 가장자리는 확인했습니다. 다음 여정은 거기서부터입니다. 🔗 시리즈 전체 읽기 · Part 1 · The Philosophy — [https://lnkd.in/ga4bMEzy] · Part 2 · The Machine — [https://lnkd.in/gN5DptaC] · Part 3 · The Human — [https://lnkd.in/gvbvPQvg]

"후기 10만 개, 다 읽고 계신가요?" 👕👖 정보가 너무 많아 오히려 구매가 망설여진 경험, 다들 있으시죠? 이 문제를 해결하기 위해 'AI 후기 요약 기능'을 도입하며 겪은 생생한 인사이트를 공유합니다. 단순히 AI API를 호출하는 것을 넘어, 진짜 '고객 경험'을 완성하기 위한 치열한 고민들을 담았습니다. 💡 놓치지 말아야 할 3가지 뽀인트  • [기획] 후기 없는 신상품은? '아더 컬러' 후기를 끌어와 요약하는 Fallback 구조 설계  • [개발] 작은 AI 모델의 한계 극복! 복사를 유발하는 구체적 예시 대신 '추상화 템플릿'과 9단계 깐깐한 후처리 도입  • [UX] 플랫폼의 딜레마, 단점 노출은? 완충어(쿠션어)를 적용해 고객 신뢰와 파트너사의 안심을 동시에 확보 단순 기술 도입을 넘어 기술과 고객 경험이 만나는 지점을 고민하는 기획자, 개발자, 디자이너라면? 만족도 84.6%를 달성한 무신사의 런칭 스토리, 아래 링크에서 확인해보세요! 🔗 https://lnkd.in/g9vPU97y #무신사 #AI #프로덕트매니저 #PM #소프트웨어엔지니어 #UX디자인

🚨 "로그가 틀리면 데이터가 틀리고, 결국 고객 경험이 망가집니다." 모바일 앱은 배포 후 즉각적인 수정이 어렵습니다. 배포 전 최종 테스트 단계에서 '앱 로그 검수'를 전면 자동화했습니다. "사람이 눈으로 보던 패킷, 이제는 테스트 코드가 검증합니다." 💪🏻 이렇게 개선했습니다!  • 자동화 연동: Appium UI 테스트 흐름에 맞춰, 타임스탬프 기준으로 GA4 및 사내 시스템 로그(Heathrow) 자동 검증  • 이슈 해소: 앱 강제 종료 시 iOS 로그가 유실되는 SDK 전송(Flush) 특성을 파악 ➡️ '백그라운드 전환 후 종료'로 트러블슈팅 성공  • 결과 및 확장: 핵심 이벤트 누락 및 오수집을 배포 전 단계에서 완벽히 사전 차단. 현재는 Snowplow 기반 파이프라인으로 한 단계 더 고도화 완료! 로그 검수 자동화는 단순한 개발 편의성 개선이 아닙니다. 데이터의 신뢰도를 지키고 릴리즈 리스크를 최소화하는 가장 강력한 'QE 전략'입니다. 수동 검수의 늪에서 벗어나 데이터 품질까지 챙긴 치열한 과정을 공유합니다. 🔗 https://lnkd.in/gTa9fQKm #QE #테스트자동화 #DataQuality #Appium #Snowplow #GA4 #모바일앱테스트 #무신사 #테크블로그

🚀 "AI, 언제까지 래핑해서 사용하실건가요?" 무신사 오프라인 매장에서 느꼈던 '핏(Fit)'에 대한 확신, 온라인으로 그대로 가져올 순 없을까? 이 질문에서 시작된 무신사 O4O팀의 사내 프로젝트 경험을 공유합니다. 초기엔 외부 LLM을 가져다 빠르게 프로토타입을 뽑았습니다. 하지만 구현 속도가 빠른 만큼, 현실의 벽도 뼈저리게 체감했습니다. 💸 트래픽과 함께 폭발하는 비용 🧩 프롬프트 튜닝에만 의존하는 통제력 부재 🚧 누구나 똑같이 만들 수 있는 제로 진입장벽 그래서 우리는 'AI를 쓰는 회사'에서 '데이터 자산을 만드는 회사'로 방향을 틀었습니다. LLM은 그저 가설 검증용 '도구'로만 쓰고, 고객의 체형 데이터를 무신사만의 독보적인 자산으로 축적하는 진짜 기반 기술을 직접 쌓아 올리기로요. 단순한 '기능'을 넘어 장기적인 '뼈대'를 세우고 싶은 분들, 무신사 사내 20% 프로젝트에서 겪은 치열한 고민과 피벗(Pivot) 스토리를 블로그에서 확인해 보세요! 😎👇 🔗 https://lnkd.in/gzSZGQ55 #무신사 #AI #LLM #O4O #LLM

"안녕하신가! 힘세고 강한 아침!" 🌞 글로벌 서비스 리뷰에 '오리털 패딩'이 'オリタルパディング(오리타루패딘구)'로 노출되고 있다면? 생각만 해도 아찔합니다. 😅 최근 무신사에서는 글로벌 서비스의 번역 모델을 GPT-4o-mini에서 구글의 번역 특화 오픈 모델 'TranslateGemma 27B(Q6)'로 전격 교체했습니다. ML 개발자가 아닌 도메인 백엔드 개발자가 번역 모델 교체에 직접 뛰어든 이유는... 글로벌 문장이 늘어날수록 범용 AI의 번역이 단순한 '품질' 문제를 넘어, 비용 폭탄과 운영 리스크로 다가왔기 때문입니다. 🚨 기존 범용 모델이 만들었던 운영의 빈틈  • 맨투맨: スウェット(스웨트)가 아닌 1:1 개인지도를 뜻하는 マンツーマン으로 오역 🤦♂️  • 구어체: 영어 리뷰 한가운데 덩그러니 남은 ㅋㅋ (운영 신뢰도 하락의 주범) "예쁘게 번역하는 것"보다 "사고 치지 않는 안전한 번역"이 절실했고, TranslateGemma는 완벽한 해결책이었습니다. ✨ 직접 도입하고 검증해 본 결과 Q6 양자화로 속도와 서버 비용의 밸런스를 꽉 잡았습니다. 게다가 "딸램이 추천한 웜톤" 같은 찐 한국식 리뷰를 일본 뷰티 용어 "イエベ(옐로 베이스)"로 찰떡같이 의역해 내는 폼 미친 로컬라이징까지 보여줍니다. 오리털 패딩이 '오리타루패딘구'가 되는 걸 보면 "언젠가 고치자"가 아니라 "당장 고쳐야겠다"는 확신이 듭니다. 확실하게 실험하고 검증하면, 운영 관점에서 가장 최적화된 AI 번역 환경을 구축할 수 있습니다. 비용과 리스크 사이에서 줄타기하는 개발자분들께 이번 도입기가 작은 인사이트가 되길 바라며, 자세한 모델별 채점 결과와 뼈 때리는 오역 비교는 아래 글에서 확인해 주세요. 🔗 https://lnkd.in/g9H9pWbU #무신사 #MUSINSA #TranslateGemma #백엔드개발자 #LLM #기계번역

🚀 무신사 글로벌 프론트엔드 팀의 다국어(i18n) 시스템 최적화 여정 13개국 유저를 위한 글로벌 서비스, 다국어 시스템은 어떻게 최적화할 수 있을까요. i18next와 Lokalise를 연동하며 겪은 치열한(?) 고민과 성과를 공유합니다. 💡 번들 사이즈 15% 다이어트 성공!  • 문제: 30여 개 모노레포 환경에서 번역 파일을 통합/동적 로드하다 보니 덩치가 커지고 Tree-shaking이 안 되는 병목 발생  • 해결: VITE_LANG 환경 변수를 활용해 정적 import + 빌드 타임 최적화로 구조 전면 개편!  • 결과: 번들 사이즈 741KB(약 15%) 감소 및 로딩 시간 최대 800ms 단축 🎯 가장 큰 Lesson Learned "업계 베스트 프랙티스(동적 import)가 우리 서비스의 무조건적인 정답은 아닙니다. 빌드 타임에 결정할 수 있는 건 무조건 빌드 타임에 처리하세요!" 해외 유저들의 "느리다"는 피드백을 기술적으로 돌파해 낸 과정, 그리고 번역키 자동 추출 시스템 등 더 자세한 아키텍처 고민이 궁금하시다면? 🔗 https://lnkd.in/gK7GwZz3 #무신사 #프론트엔드 #Frontend #웹개발 #i18n #최적화 #React #성능개선 #Localization

👾 단순히 'AI 코드 리뷰를 도입했습니다'로 끝내고 싶지 않았습니다. LLM 기반 코드 리뷰를 단순한 스크립트에서 '전사 표준 인프라'로 안착시키기까지의 고민과 '과정의 밀도'를 공유합니다. 처음엔 개인 토큰과 몇 줄의 스크립트로 시작된 작은 시도였습니다. 하지만 사내에 가이드를 공유하자마자 슬랙에 달린 43개의 댓글과 열띤 토론은, 이 도구를 무신사 전체 시스템으로 진화시키는 기폭제가 되었습니다. 단순 도입을 넘어, 실제 업무에 완벽히 녹여내기 위해 무신사 엔지니어들은 이렇게 해결했습니다. 🗑️ 봇 코멘트 공해 해결 (스마트 클린업)  • 커밋마다 쌓이는 AI 코멘트 더미에 지치지 않도록, GraphQL을 활용했습니다.  • 사람이 남긴 유의미한 대화(Resolved, Reply)는 보존하고, 방치된 봇 노이즈만 똑똑하게 제거합니다. 🛠️ 전사 표준화와 유연성의 공존 (Composite Action)  • 파편화되는 스크립트 문제를 해결하기 위해 로직을 중앙 저장소에 캡슐화했습니다.  • 전사 공통 품질은 유지하되, 각 팀은 도메인에 맞게 파라미터만 조정해 단 몇 줄의 YAML로 즉시 도입할 수 있습니다. ✍️ 최고의 프롬프트는 가장 짧은 프롬프트:  • 복잡한 지시어가 오히려 노이즈가 되는 최신 LLM의 특성을 고려해, 핵심만 던져 제로샷(Zero-shot) 능력을 극대화하는 'Minimalist Prompting'을 적용했습니다. "앞으로 기술 조직의 격차는 AI 도입 여부가 아니라, 개발 프로세스에 깊숙이 녹여내고 자동화하는 '과정의 밀도'에서 벌어질 것입니다." 개발자 개인의 노하우가 집단 지성을 통해 팀의 규칙이 되고, 전사적인 문화로 자리 잡은 무신사의 생생한 AI 인프라 구축기! 자세한 기술적 챌린지와 해결 과정을 공유 합니다. 🔗 https://lnkd.in/gFqKyfnf #무신사 #Musinsa #무신사테크 #AI코드리뷰 #Claude #GitHubActions #프론트엔드 #백엔드 #개발문화 #LLM #생산성향상

🚨 "이 장애, 지금 당장 대응해야 하나요, 지켜봐도 되나요?" 서비스를 운영하는 PM과 엔지니어라면 장애 발생 시 매번 마주하는 질문입니다. 에러율이 치솟았지만 실제 비즈니스 타격은 없는 경우도 있고, 지표상 에러율은 낮아도 치명적인 수익 누락으로 이어지는 경우도 있죠. 기술적 장애의 크기와 비즈니스 치명도가 항상 일치하지 않는다는 문제의식에서 출발해, '사용자 경험'을 기준으로 장애 심각도(SEV)를 재정의한 팀 무신사 큐레이터 서비스의 노하우를 소개합니다. 단순한 에러율(%) 모니터링을 넘어, 비즈니스 관점에서 치명도를 판단하는 4단계 프로세스입니다. 1️⃣ 핵심 사용자 여정(CUJ) 정의: "어떤 경험이 끊기면 우리 서비스의 핵심 가치가 멈추는가?" 2️⃣ CSP 식별: 전체 여정 중 매출과 전환에 직결되는 핵심 경로(Critical Serving Path)와 비핵심 경로 구분 3️⃣ 우선순위(Priority) 세분화: 고객 구매 경험 단절(P0)부터 내부 운영 불편(P3)까지 비즈니스 영향도에 따른 등급화 4️⃣ SEV 및 얼럿 연동: 합의된 비즈니스 심각도를 엔지니어링 지표(SLI/SLO)로 번역하여 직관적인 대시보드 구축 가장 큰 변화는 "장애 지표는 단순한 숫자가 아니라, 팀이 무엇을 먼저 지켜야 할지 합의된 관점"을 가지게 되었습니다. 이 기준을 세운 후, 장애 대응 시 "에러율이 몇 퍼센트인가요?"가 아니라 "고객 경험이 영향을 받고 있나요?"를 먼저 묻게 되었습니다. 자연스럽게 커뮤니케이션 리소스는 줄고 대응은 훨씬 빠르고 일관되게 변했죠. 여러분의 팀은 어떤 기준으로 장애의 우선순위를 판단하고 계시나요? 팀 무신사의 경험을 공유합니다. 🔗 https://lnkd.in/gCEhuja3 #장애대응 #프로덕트매니지먼트 #SRE #사용자경험 #CUJ #SLI #SLO #팀무신사 #인사이트공유

⏰ 배포 때마다 울리던 오탐 알림 100% 제거, 2주 만에 달성한 비결 매주 수요일 오전 8시, 정기 배포가 시작되면 당연하게 쏟아지던 슬랙 알림들. 하지만 그중 상당수는 실제 장애가 아닌 클라이언트의 실수(4xx)나 배포 중 발생하는 일시적인 소음이었습니다. “진짜 장애가 이 소음들에 묻히고 있다.” 이 문제를 해결하기 위해 2주간 3개 서비스, 27개 SLO, 54개 모니터를 완전히 재구축했습니다. ‘감(感)’이 아닌 ‘데이터’로 접근했을 때 얻은 결과는 놀라웠습니다. ✅ 숫자로 증명한 변화  • 오탐 알림: 일 10회 이상 → 0회 (100% 제거)  • 운영 효율: 전사 확산 시 연간 1,800시간 절감 (엔지니어 1명분 리소스)  • 정확도: 배포 중 Error Budget 소진 오차 10초 이내로 방어  • 저희 팀은 단순히 툴을 설정하는 것을 넘어 '측정의 본질'에 집중했습니다. 1️⃣ 추측 금지: "이 API는 1초면 충분하겠지?"라는 추측 대신, 90일치 APM 데이터를 분석해 p99 기반의 임계값을 설정 2️⃣ 측정 방식의 전환: HTTP 상태 코드의 한계를 깨닫고, APM Error 태그 기반으로 '실제 비즈니스 성공'을 정의 3️⃣ 완전 자동화: 사람이 개입하면 반드시 실수하기에, ArgoCD Hooks를 활용해 배포 시 SLO Correction(오류 예산 제외)을 1초의 오차 없이 자동화 이제 저희 팀은 배포 중에도 평온을 유지(?)하며, 새로 합류한 동료도 대시보드만 보면 시스템의 상태를 이해할 수 있을정도로 빠른 온보딩이 가능했습니다. 성공적인 SRE는 화려한 기술의 도입보다 데이터에 대한 집요함에서 시작된다는 것을 바탕으로, 팀의 시행착오와 Python 스크립트가 담긴 실전 가이드도 함께 공유합니다. 🔗 https://lnkd.in/gf4BqH3b #무신사 #O4O #SRE #SLO #Datadog #ArgoCD #DevOps #Backend #자동화 #데이터기반의사결정

무신사 테크 중 Platform Business Operation(PBO), 정확히 어떤 조직일까요? “PBO는 무슨 일을 하는 팀이죠?” “테크 조직인가요?” 한 번이라도 궁금하셨다면, 이번에는 그냥 지나치지 않으셔도 됩니다. PBO는 단순 운영 조직이 아닙니다. 플랫폼의 비즈니스 문제를 기술적 언어로 재정의하고, 이를 구조 설계로 풀어내는 테크 조직입니다. 우리는 반복 업무를 처리하는 대신 그 일이 반복되지 않도록 시스템을 설계합니다. 사람 중심의 운영을 자동화하고, 비즈니스 요구를 아키텍처와 워크플로우로 구체화합니다. 그 과정을 통해 플랫폼의 확장성과 안정성을 설계하고 고도화합니다. 공식 지원 전, PBO를 직접 들어볼 수 있는 자리를 마련했습니다. PBO를 리드하고 있는 매니저들과의 화상 캐주얼 챗을 통해 지금 어떤 문제를 풀고 있는지, 어디를 향해 가고 있는지, 그리고 내 경험(PM/BE)이 어떤 지점에서 연결될 수 있을지 직접 확인해 보실 수 있습니다. 지원 여부를 결정하기 위한 절차가 아닌, 조직을 이해하는 데 목적을 둔 자리입니다. • 대상: 5년 이상 경력 Product Manager / Backend Engineer • 일정: ~3/2 (월) 뜨거운 관심속에 기간을 연장 했습니다 :D 이번 기회를 통해 PBO를 한 걸음 먼저 확인해 보세요. https://lnkd.in/d2cREBa9