당근 테크블로그

AI 도구(Lovable, Bolt, v0)가 프롬프트 하나로 화면 초안을 생성하는 시대, 당근 프론트엔드 엔지니어가 디자인시스템 팀의 역할을 다시 정의한다. "컴포넌트와 토큰 제공"을 넘어, 경험에 대한 판단 기준을 쌓고 구조화하는 팀이어야 한다는 주장이다. AI가 80%의 화면을 빠르게 만들어주지만, 99% 수준의 제품 경험으로 끌어올리는 건 여전히 맥락(Context)과 판단의 문제다.

200개 이상 DB의 파이프라인 설정과 실행 코드가 단일 레포에 결합되어 서비스팀이 테이블 추가 시 복잡한 코드베이스를 직접 익혀야 했다.

당근 중고거래 서버 팀이 "이 기능 언제 배포됐냐"는 반복 질문에 드는 커뮤니케이션 비용을 줄이려고, 배포 내역을 비개발자도 읽을 수 있는 릴리즈 노트로 자동 생성한 과정을 다룬다. 핵심 교훈은 두 가지다. LLM 을 붙이기 전에 정제된 데이터 자산을 먼저 쌓아야 하고, LLM 은 PR 을 요약은 해도 독자를 고려해 사내 용어를 번역하지는 않는다는 점이다.

PyPI 공급망 공격(LiteLLM, PyTorch Lightning)은 보통 일주일 이내 짧은 노출 윈도우 안에 일어난다. 사내 개발자가 무심코 악성 패키지를 설치하면 막을 방법이 없다.

LiteLLM, PyTorch Lightning 등 PyPI 패키지가 공급망 공격으로 악성 버전이 업로드된다. 주요 공격 10건 중 일부는 일주일 미만의 짧은 노출 기간을 가졌다.

AI 바이브 코딩 도구들이 빠르게 UI 를 생성하지만 디자인 시스템 규칙을 따르지 않아 "당근스러운 화면"을 만들 수 없음.

모두가 LLM/AI로 데이터를 다루게 된 시기, 데이터 팀의 역할이 모호해졌다. 단순 SQL 작성/리포트 제공이 셀프서비스로 대체된다.

당근의 배치 Job 워크로드는 트래픽이 들쭉날쭉하다. 정적으로 노드를 크게 잡으면 유휴 비용이, 작게 잡으면 Job 시작 지연이 SLO 를 깬다.

batch Job 워크로드는 짧고 변동성이 크다. EKS Node Group 을 정적으로 두면 유휴 노드 비용이 크고, 작게 두면 Job 시작 latency 가 SLO 를 벗어난다.

2조 토큰 규모 LLM 으로 상품 카테고리 분류를 학습/운영하면서 마주친 함정과 인사이트.

일반 e-commerce 추천 모델로는 "로컬 + 다용도" 슈퍼앱의 사용자 행동을 잘 표현하기 어렵다.

당근 숏폼팀의 모듈이 200MB 까지 커져 빌드 시간 / 메인 APK 사이즈가 문제가 됐다.