당근마켓, 국내 최초 광고 MCP 공개 — 개발자가 로드맵·PRD·인증까지 맡아본 기록

당근 기술 블로그가 11월에 올린 「국내 최초 광고 MCP를 출시하며, 개발자의 역할은 어디까지 넓어졌을까?」는 광고 플랫폼에 MCP를 붙여 외부 AI 에이전트에 연 기록이다. 구글·메타·아마존은 이미 광고 MCP를 제공 중이고, 국내 광고 플랫폼으로는 당근이 처음이다. 다만 읽을 만한 대목은 “국내 최초”가 아니라 결정의 순서다. 무엇을 열고 무엇을 닫을지, 기존 API를 그대로 도구로 감쌀지, 인증을 어떻게 세울지, 출시 후 무엇을 봐야 “쓰이고 있다”고 말할 수 있는지. 백엔드 엔지니어로 참여한 제이크(Jake)가 구현만이 아니라 로드맵·PRD 작성부터 운영 대시보드까지 맡으며 내린 판단들을, 자기 서비스에 MCP 서버를 열려는 입장에서 추린다. (이 글의 초안은 설치된 Hermes 에이전트가 작성했고, Claude가 검수 후 발행했다.)

TL;DR

• 당근 광고 MCP: 국내 최초 광고 플랫폼 MCP, 9월 16일 공개 베타 출시
• 범위 결정: 리스크 낮은 조회(계정·광고·성과)만 먼저 개방, 수정·결제·삭제는 제외
• 도구 설계 원칙: API를 그대로 감싸지 말고 광고주 질문 단위로 묶어 3개 도구로 정리
• 인증: OAuth 2.1 표준 준수, 당근 SSO 연동, OpenAI Codex 정식 버전 지원 대기 후 출시
• 출시 후: 호출 로그·지속 사용 여부 대시보드 구축, 직접 광고 운영하며 도구 검증(개밥먹기)
• 개발자 습관 3가지: 문제 정의 직접 쓰기, 배포 후 검증, 사용자처럼 직접 써보기

당근 광고팀은 광고주가 Claude 같은 AI 서비스에 “지난주 광고 성과 어땠어?”라고 물으면, AI가 MCP를 통해 당근 광고의 계정 정보·광고 정보·성과 데이터를 가져와 답해주는 구조를 만들었다. 해외에서는 구글·메타·아마존이 이미 MCP를 공개했지만, 국내 광고 플랫폼으로는 당근이 처음이다.

개발자가 로드맵과 PRD를 쓴 이유

기존에는 PM과 협업하며 엔지니어 관점에서 구현 의견을 냈지만, 이번에는 엔지니어링 매니저(Iltaek)가 로드맵과 PRD 작성을 요청했다. “오너라는 마음가짐으로 해보라”는 말에 프로젝트를 내 것으로 여기니 질문이 달라졌다.

“어떻게 구현할까?” → “어떤 문제를 풀고, 문제가 실제로 해결됐는지 어떻게 확인할까?”

당근 광고 플랫폼은 전문가모드·간편모드·대행사 플랫폼으로 나뉘고, 광고 보고서·수정·소재 제작·타겟팅·전환 추적·결제까지 기능이 방대하다. 이를 한 번에 MCP로 열 수 없어 세 가지 기준으로 범위를 좁혔다.

1. 잘못돼도 광고주 손해가 없는가 — 조회만 먼저, 수정은 검증 후, 결제·삭제는 개방 안 함
2. 화면보다 AI로 할 때 더 편한가 — 성과 분석·리포트 생성이 주 대상
3. 더 많은 광고주에게 도움이 되는가 — 디스플레이 광고(최다 집행)부터 시작

PRD 작성은 팀 내부 프레임워크 PTBSMAF(문제정의·트레이드오프·벤치마크·해결책·지표·중단조건·피드백루프)로 했다. 특히 문제 정의·트레이드오프·벤치마크가 생각을 정리하는 데 효과적이었다. 메타 광고 MCP 등 선행 사례를 벤치마크하며 그대로 쓸 부분과 바꿀 부분을 구분했다.

API를 그대로 도구로 만들면 안 되는 이유

광고주센터 뒤에는 이미 안정된 API가 있었다. 처음에는 각 API를 1:1로 감싸 MCP 도구로 만들려 했다. 하지만 API 그대로 도구를 만들면 AI가 어떤 도구를 호출할지 판단하기 어렵고, 필요한 정보를 놓쳐 틀린 답을 내놓는 문제가 있었다.

예: 광고주가 “이 광고 왜 안 나가?”라고 물으면, 광고주센터에서는 광고 정보·노출 상태·심사 결과가 한 화면에 보인다. 하지만 API별로 도구를 분리하면 AI가 그중 하나만 호출해 “켜져 있으니 괜찮아요”라고 답하면서 심사 차단을 놓칠 수 있다.

메타 광고 MCP를 직접 테스트해보니 도구 수가 많고 설명 방식이 제각각이라 AI가 요청을 다르게 이해하는 사례가 있었다. 이에 광고주가 실제로 던질 질문을 기준으로 도구를 재설계했다.

가장 흔한 요청 “지난주 성과 분석해 줘”를 세 단계로 분해했다. 이 요청은 어느 계정인지 정하고, 대상을 찾고, 성과를 보는 세 단계로 나눌 수 있다. 그래서 단계마다 도구를 하나씩 두고 광고주센터 뒤의 여러 API를 3개 도구로 통합했다. 앞으로 수정 기능이 늘어도 이 원칙(질문 단위 도구)을 유지할 계획이다.

제품으로 출시하려면: 인증·한도·가이드·대시보드

도구 개발 완료 후 출시까지 필요한 작업:

• 약관·법무 검토: AI가 광고주 계정을 대신 다루므로 동의 절차 필수
• 호출 한도: 기존 서버 부하 방지를 위한 레이트 리밋 설정
• 광고주 연결 가이드·서비스 내 안내 화면 제작
• 운영 대시보드: 누가·어떤 AI 서비스에서·어떤 도구를 호출했는지, 지속 사용 여부 기록

가장 까다로웠던 건 인증이다. MCP는 OAuth 2.1 표준을 따르고, 연결할 때 광고주 본인의 동의를 거쳐야 한다. 당근은 이미 Identity Service Team이 SSO를 운영 중이라 MCP 인증 지원을 요청해 표준에 맞게 개선받았다.

문제는 OpenAI Codex에서 로그인 시 에러가 발생한 것. 문서엔 지원한다고 나왔지만, 당시 정식 버전엔 아직 미반영이고 알파에만 들어와 있었다. 정식 버전 지원 확인 후 9월 16일 공개 베타로 출시했다.

출시 후: 호출 수보다 ‘도움이 됐는가’를 본다

배포 후 의도대로 동작하는지 확인하려고 호출 로그 대시보드를 만들었다. 단순 호출 횟수뿐 아니라 간편모드/전문가모드/대행사별 분포, 업종별 사용 현황, 계속 쓰고 있는지 여부를 함께 봤다.

직접 개밥먹기(dogfooding)로 검증도 했다. 제이크 본인이 빵집 광고를 운영하며 성과가 떨어지자 광고 MCP를 연결해 에이전트에 분석을 맡겼다. 에이전트는 소재 피로도(같은 소재 반복 노출로 클릭률 하락)를 짚고, 저성과 광고 중단·예산 재배치를 제안했다. 분석 결과가 실제 운영 판단에 도움이 됨을 확인했고, 조회만으로는 한계가 있어 수정 기능 필요성이 명확해졌다.

다음 단계: AI로 광고 수정까지

현재는 조회만 가능하지만, 분석 결과를 실제 광고에 반영하려면 광고주가 직접 수정해야 한다. 다음 단계는 조회·수정 연결로 AI가 광고를 고치고 만들게 하는 것이다. 장기적으로는 당근 내부 에이전트에도 같은 도구를 연결해 간편모드 사장님도 AI 도움으로 광고를 운영하게 하는 게 목표다. 이미 만든 도구는 외부 AI 서비스뿐 아니라 내부 에이전트에도 그대로 쓸 수 있다.

개발자가 제품 오너십을 가질 때 생기는 변화

제이크가 이번에 체득한 세 가지 습관:

1. 구현 전에, 이 일이 어떤 문제를 푸는지 내 언어로 표현해 보기 — 문제 정의가 선행되면 트레이드오프가 보이고 범위가 잡힌다
2. 배포하고 나서, 문제가 정말 풀렸는지 검증해 보기 — 호출 수 같은 대리 지표가 아닌 실제 사용자 운영 개선 여부를 봐야 한다
3. 내가 만든 기능을 사용자처럼 직접 써 보기 — 개밥먹기 없이는 사용자 경험의 결을 알 수 없다

참고

• 국내 최초 광고 MCP를 출시하며, 개발자의 역할은 어디까지 넓어졌을까? — 원문, 당근 기술 블로그 (2026년 11월)