국내 최초 광고 MCP를 출시하며, 개발자의 역할은 어디까지 넓어졌을까?
광고주 질문 중심으로 광고 조회 MCP를 설계하고 OAuth 2.1 인증과 운영 대시보드를 구축했습니다. 출시 후 사용 행태와 도그푸딩을 검증하며 AI 기반 광고 수정 기능의 다음 단계를 도출했습니다.
광고주 질문 중심으로 광고 조회 MCP를 설계하고 OAuth 2.1 인증과 운영 대시보드를 구축했습니다. 출시 후 사용 행태와 도그푸딩을 검증하며 AI 기반 광고 수정 기능의 다음 단계를 도출했습니다.
모델 교체 뒤 자동 프롬프트 캐시 구분점 정책 변화로 비용이 3.2배 증가한 원인을 분석했습니다. 고정부 경계에 명시 구분점을 두고 히트율과 비용을 운영 지표로 관리했습니다.
Aurora MySQL에서 인덱스 DDL 수행 시 Reader 버퍼풀이 비워지는 현상을 다뤘습니다. 원인으로 지목된 엔진 결함과 3.14 릴리즈까지의 대응 과정을 소개합니다.
QAHub로 테스트 기록과 실제 기기 실행 환경을 통합하고, 코드·AI 혼합 Flow를 구성했습니다. Self-healing과 Path Replay로 반복 테스트의 안정성·실행 시간·AI 호출 비용을 개선했습니다.
독립적으로 발화하는 웹뷰·OS 오버레이를 Promise 기반 우선순위 큐로 직렬화했습니다. 큐와 로컬 시퀀서의 책임을 분리해 순서 변경과 검증 복잡도를 낮췄습니다.
당근의 회원과 인증을 책임지는 Identity Service Team의 관점에서 인증이 어떻게 변화해 왔는지 소개하는 글입니다. 인증 관련 팀의 역할과 책임 범위를 개괄적으로 다루고 있습니다.
당근 프론트엔드 코어 팀이 웹뷰를 넘어서는 개발 환경을 위해 Lynx를 선택한 배경을 소개합니다. 포스트 제목상 Lynx 도입 이유를 다루는 기술 공유 글입니다.
레퍼런스가 거의 없는 Lynx를 당근이 왜 선택했는지 다룬 글입니다. 프론트엔드 개발 환경과 배포 인프라 관점에서 도입 맥락을 살펴봅니다.
당근 실험플랫폼이 지표 UI화, 상호배제 그룹, Experiment MCP로 실험 운영 병목을 줄인 사례를 소개했습니다. 실험 설계와 반복 작업을 더 빠르고 편하게 만들기 위한 구조와 자동화 방향을 다뤘습니다.
프론트엔드와 백엔드를 한 팀으로 합쳐 조율과 대기 비용을 줄인 사례를 소개했습니다. 문서화와 AI, Runbook이 안정성과 속도를 함께 받쳐줬습니다.
천만 MAU를 버티기 위한 커뮤니티 시스템의 구조와 선택을 소개했습니다. 웹앱과 서버앱, 모듈과 이벤트 분리로 확장성과 운영성을 함께 확보한 사례입니다.
당근 레슨/과외가 숨은 수요를 발견하고 PMF를 찾기까지의 과정을 공유했습니다. 수요자 중심 실험과 진입점 개선으로 전국 오픈 단계까지 확장한 사례입니다.
디자인시스템은 컴포넌트만 만드는 일이 아니라 제품 판단 기준을 쌓는 일이라고 설명했습니다. AI가 UI를 빠르게 만들수록 패턴과 맥락을 정리하는 역할이 더 중요해졌습니다.
200개 이상 DB를 BigQuery로 옮기던 ELT 운영 문제를 DT Platform으로 분리·표준화했습니다. UI와 DSL, 자동 마이그레이션으로 리드타임과 리뷰 병목을 줄였습니다.
배포 내역을 정형화해 Notion에 쌓고, LLM으로 비개발자도 읽을 수 있는 릴리즈 노트를 자동 생성했습니다. 별도 인프라 없이 기존 도구만으로 커뮤니케이션 비용을 줄인 사례입니다.
내부 PyPI 프록시 앞단에 얇은 프록시를 두어 CodeArtifact를 PyPI처럼 사용하도록 구성했습니다. 또한 PEP 691의 upload-time을 활용해 cooldown 정책을 중앙에서 적용했습니다.
LiteLLM 공급망 공격을 계기로 사내 PyPI 프록시에 쿨다운 정책을 도입했습니다. PEP 503과 PEP 691을 함께 활용해 최근 업로드 패키지를 필터링하고 전사에 일괄 적용했습니다.
프롬프트 한 줄로 만드는 화면의 한계를 짚고, 디자인 시스템에 맞는 의사결정 자동화가 핵심이라고 설명했습니다. 어드민, CLI, 에이전트로 발전한 Kraft와 Plan/Orchestra 구조도 소개했습니다.