당근·문제팀원이 "이 기능 언제 나갔어요?"라고 물을 때마다 매번 git log를 정리하는 비효율. 기술 용어로 가득한 배포 내역이 비개발자에게는 의미 없다.
접근GitHub Actions로 PR 정보를 Notion에 자동 기록한 뒤, 일일 CronJob으로 Notion 데이터를 Claude API에 보내 비개발자도 이해할 수 있는 형태로 요약한다. 프롬프트는 Prompt Studio에서 코드 외부로 관리.
결과분류 체계 + 용어 변환 사전으로 기술 용어를 팀 언어로 자동 번역. 같은 데이터 자산이 주간 자동화, LLM 문맥, 다른 팀 도입 등으로 확산.
당근·문제PyPI 공급망 공격(LiteLLM, PyTorch Lightning)은 보통 일주일 이내 짧은 노출 윈도우 안에 일어난다. 사내 개발자가 무심코 악성 패키지를 설치하면 막을 방법이 없다.
접근모든 패키지 설치를 거치는 사내 PyPI 프록시를 구축. PEP 503 / 691 기반 인덱스 미러에 쿨다운 기반 필터링을 적용하고, 정책은 Central Dogma 로 중앙 관리한다.
결과쿨다운 정책 하나로 PyTorch Lightning 공격을 실제로 차단. 전사 보안 정책이 일관되게 자동 적용되는 구조를 확보.
당근·문제LiteLLM, PyTorch Lightning 등 PyPI 패키지가 공급망 공격으로 악성 버전이 업로드된다. 주요 공격 10건 중 일부는 일주일 미만의 짧은 노출 기간을 가졌다.
접근당근이 내부 PyPI 프록시를 구축해 모든 패키지 설치 요청을 중앙화. PEP 503(HTML) 응답을 클라이언트에 주면서 PEP 691(JSON) API로 업로드 시간을 확인하고, 정해진 쿨다운 기간 안의 패키지를 필터링한다. 정책은 Central Dogma로 동적 관리.
결과PyTorch Lightning 공격 시 쿨다운 정책으로 악성 버전 설치를 자동 차단. 회사 전체에 일관된 보안 정책이 적용된다.
당근·문제AI 바이브 코딩 도구들이 빠르게 UI 를 생성하지만 디자인 시스템 규칙을 따르지 않아 "당근스러운 화면"을 만들 수 없음.
접근Kraft 의사결정 자동화 도구를 어드민 → CLI → 에이전트로 진화시키면서 DesignSpec 중간 표현 + 11개 Scorer 기반 검증 + Mastra 하네스 + Claude Agent SDK + 크로스세션 메모리 누적으로 구조화.
결과SEED 디자인 시스템 준수 여부 자동 검증, 도메인별 맥락 반영, 세션 간 학습이 누적되는 UI 생성 플랫폼 구축.
당근·문제모두가 LLM/AI로 데이터를 다루게 된 시기, 데이터 팀의 역할이 모호해졌다. 단순 SQL 작성/리포트 제공이 셀프서비스로 대체된다.
접근당근 데이터 팀이 지난 1년간 역할을 재정의. 셀프서비스 인프라(쿼리 도구, semantic layer), 데이터 품질 가드레일, LLM 기반 분석 도구 운영으로 이동.
결과분석가가 단순 요청 응대에서 해방돼 더 어려운 문제(데이터 모델링, 실험 설계, 인과 분석)에 집중. 데이터 팀과 다른 팀의 관계가 바뀌었다.
당근·문제당근의 배치 Job 워크로드는 트래픽이 들쭉날쭉하다. 정적으로 노드를 크게 잡으면 유휴 비용이, 작게 잡으면 Job 시작 지연이 SLO 를 깬다.
접근EKS 노드 그룹에 Karpenter 스타일 오토스케일링을 도입. 수요가 있으면 빠르게 프로비저닝하고 유휴일 때 즉시 회수한다.
결과유휴 노드 비용을 약 40% 줄이면서 Job 시작 지연 SLO 를 유지. Job 중심 워크로드에 맞는 오토스케일링 패턴을 정리.
당근·문제batch Job 워크로드는 짧고 변동성이 크다. EKS Node Group 을 정적으로 두면 유휴 노드 비용이 크고, 작게 두면 Job 시작 latency 가 SLO 를 벗어난다.
접근당근이 cluster autoscaler / Karpenter 기반 오토스케일링을 적용. Job 패턴에 맞춰 빠르게 노드를 띄우고 idle 시 빠르게 회수한다.
결과유휴 비용 줄이면서 Job 시작 latency 를 SLO 안으로 유지. AI 학습 같은 burst 워크로드에도 적용 가능.
당근·문제2조 토큰 규모 LLM 으로 상품 카테고리 분류를 학습/운영하면서 마주친 함정과 인사이트.
접근당근이 fine-tuning 전략, 데이터 품질 관리, 분포 변화 대응, 비용 효율적 운영 방법을 정리. "더 큰 모델이 항상 정답" 이 아닌 이유까지.
결과대규모 LLM 운영 노하우 + scaling laws 가 실제 적용되지 않는 경우 식별. ML 운영 실전 가이드.
당근·문제일반 e-commerce 추천 모델로는 "로컬 + 다용도" 슈퍼앱의 사용자 행동을 잘 표현하기 어렵다.
접근당근 데이터 팀이 지역성 / 거래 / 커뮤니티 행동 / 다용도 사용 패턴을 통합 모델링. 임베딩 공간 설계와 long-term 유저 행동 모델링.
결과슈퍼앱 특화 유저 모델로 추천 / 검색 품질 향상. 일반 e-commerce 와 다른 도메인에 맞는 모델링 패턴.
당근·문제당근 숏폼팀의 모듈이 200MB 까지 커져 빌드 시간 / 메인 APK 사이즈가 문제가 됐다.
접근Android Dynamic Feature Module (DFM) 로 숏폼 기능을 on-demand 로 분리. 사용자가 진입할 때만 다운로드.
결과메인 APK 사이즈 감소 + 빌드 시간 단축. 팀 단위 코드 소유권도 명확해짐.