요약
안녕하세요. 당근 광고실 광고주플랫폼팀에서 백엔드 엔지니어로 일하는 제이크(Jake)예요.
얼마 전 저희 팀 엔지니어링 매니저 Iltaek이 프론트엔드와 백엔드를 한 팀으로 합친 이야기를 글로 나눴어요. 그 글이 팀의 경계를 넘어 일하는 이야기였다면, 이번 글은 제가 당근 광고 MCP를 만들며 개발자의 역할을 넓혀 본 이야기예요.
MCP(Model Context Protocol)는 AI 서비스가 외부 서비스의 데이터를 불러올 때 쓰는 표준 연결 방식이에요. 광고주가 Claude 같은 AI 서비스에 “지난주 광고 성과 어땠어?”라고 물으면, AI가 광고 MCP를 거쳐 당근 광고의 계정 정보와 광고 정보, 성과 데이터를 가져와서 답해 줘요. 해외 광고 플랫폼에서는 구글, 메타, 아마존이 이미 MCP를 공개했고, 국내에서는 당근이 처음으로 공식 광고 MCP를 출시했어요.
저는 개발자로 이 프로젝트에 참여하는 줄 알았는데, 하다 보니 로드맵과 PRD부터 출시까지 맡아야 했어요. 이 글에서는 그 과정에서 겪은 일과, 제가 일하는 방식이 어떻게 달라졌는지 이야기해 보려고 해요.
로드맵과 PRD를 처음 써 봤어요
그동안은 PM과 함께 일하면서 엔지니어로서 개발에 필요한 의견을 나누고, PRD를 어떻게 구현할지 고민했어요. 그런데 이번에는 Iltaek에게 로드맵과 PRD까지 맡아 달라는 요청을 받았어요.
솔직히 요청을 받았을 때는 “이것도 개발자인 내 일인가?” 싶었어요. 로드맵은 PM이 그리는 거 아닌가, 내가 로드맵을 제시하는 게 맞나 하는 생각이 먼저 들었어요. 해 본 적 없는 일이라 부담도 됐고요.
그때 Iltaek이 오너라는 마음가짐으로 해 보라고 했어요. 그 말대로 “내 프로젝트”라고 생각하다 보니, 이 프로젝트를 더 잘되게 하려면 뭘 해야 할지 고민하게 되더라고요. 스스로 던지는 질문부터 달라졌어요.
로드맵을 그리려고 하니, 당근 광고 플랫폼은 생각보다 크고 복잡했어요. 전문가모드, 간편모드, 대행사 플랫폼¹까지 합치면 광고주가 할 수 있는 일이 정말 많아요. 광고 보고서, 광고 수정, 소재 만들기, 타겟팅, 전환 추적, 결제와 충전까지요. 이걸 한 번에 다 MCP로 열 수는 없어서, 범위를 좁혀야 했어요.
혹시나 잘못되더라도 광고주에게 손해가 없는 일인지, 화면보다 AI로 했을 때 더 편한 일인지, 더 많은 광고주에게 도움이 되는 일인지, 이렇게 세 가지 기준을 세워 봤어요. 그래서 리스크가 가장 낮은 조회 기능부터 열었어요. 광고를 수정하는 기능은 충분히 검증한 뒤에 열기로 했어요. AI가 예산이나 입찰가를 바꾸다 실수하면 광고비가 의도와 다르게 나갈 수 있어서요. 결제나 광고 삭제처럼 AI로 하는 게 오히려 불편하거나 위험한 일은 아예 열지 않기로 했어요. 그리고 당근 광고에서 가장 많이 집행되는 디스플레이 광고부터 시작했어요.
그렇게 로드맵을 그리고, 그 안에서 이번에 할 일의 범위를 정했어요. 그다음 저희 팀에서 쓰는 PTBSMAF라는 프레임워크로 PRD를 썼어요. 문제 정의(Problem Statement), 트레이드오프(Trade-off), 벤치마크(Benchmark), 해결책(Solution), 지표(Metrics), 중단 조건(Andon), 피드백 루프(Feedback Loop)의 앞 글자를 딴 이름이에요.
그중에서도 문제 정의, 트레이드오프, 벤치마크가 특히 도움이 됐어요. 문제를 제가 이해한 대로 풀어 쓰다 보니 생각이 정리됐고, 조회만 먼저 열면 무엇을 얻고 무엇을 포기하는지 적으면서 트레이드오프가 분명해졌어요. 특히 벤치마크에서는 다른 광고 플랫폼의 사례를 찾아보면서, 그대로 참고할 부분과 우리 상황에 맞게 바꿔야 할 부분이 구분됐어요.
PRD를 쓰면서 이전에는 생각해 보지 못했던 부분까지 고민하게 됐어요. 이 기능으로 플랫폼이 무엇을 얻을지, 어느 제품부터 고려할지, 뭐가 더 나은 방향인지 같은 제품 관점의 고민은 전부 처음이었어요.
이렇게 정한 것들이 정답인지 100% 확신할 수는 없었지만, 적어도 근거를 가지고 정했다는 점은 지금 돌아봐도 만족스러워요. 로드맵은 PM이 그리는 거라고 생각했던 것도, 해 보고 나니 제 선입견이었던 것 같아요.
API를 그대로 옮기면 될 줄 알았어요
로드맵과 PRD로 무엇을 하고 무엇을 하지 않을지 정하고 나니, 이제 도구를 어떻게 만들지 고민할 차례였어요.
광고주센터 뒤에는 이미 잘 돌아가는 API가 있어서, 그걸 MCP 도구로 하나씩 감싸기만 하면 될 거라고 생각했어요. 그런데 API를 그대로 도구로 만들면, AI가 어떤 도구를 써야 할지 헷갈려하고, 필요한 정보를 놓쳐 잘못된 답을 할 수 있더라고요.
예를 들어 광고주가 “이 광고 왜 안 나가?”라고 물었다고 해 볼게요. 광고주센터였다면 광고 정보, 노출 상태, 심사 결과가 한 화면에 같이 보였을 거예요. 그런데 API마다 도구를 따로 만들면, AI가 그중 뭘 부를지 스스로 골라야 해요. 광고 정보만 보고 “켜져 있으니 괜찮아요”라고 답하면서, 광고 심사에서 막힌 건 놓치는 식이에요.
메타 광고 MCP를 직접 연결해 보니, 도구가 많고 설명 방식도 제각각이라 AI가 광고주의 요청을 다르게 이해하는 경우가 있었어요. 로드맵을 그리며 광고주가 AI에게 무엇을 물어볼지 고민했던 게 여기서 도움이 됐어요. API를 그대로 옮기는 대신, 광고주의 질문을 기준으로 도구를 설계하기로 했어요. 그렇게 정리해 보니 좋은 API와 좋은 도구의 기준은 꽤 달랐어요.
이 기준으로, 가장 흔한 요청인 “지난주 성과 분석해 줘”를 예시로 도구를 설계해 봤어요. 이 요청은 어느 계정인지 정하고, 대상을 찾고, 성과를 보는 세 단계로 나눌 수 있어요. 그래서 단계마다 도구를 하나씩 두고 광고주센터 뒤의 여러 API를 3개의 도구로 정리했어요. 앞으로 광고 수정처럼 기능이 늘어나면 도구도 함께 늘어나겠지만, 그때도 이 기준을 지켜 가려고 해요.
제품으로 내놓으려면 챙길 게 많았어요
도구를 다 만들었다고 바로 내놓을 수 있는 건 아니었어요. AI가 광고주의 계정을 대신 다룰 수 있도록 약관을 검토하고 법무팀의 확인을 받아야 했어요. 기존 서버에 부하가 가지 않도록 적절한 호출 한도를 정해야 했고, 광고주용 연결 가이드와 서비스 내 안내 화면도 준비해야 했어요. 그리고 출시 후 운영을 위한 대시보드도 만들어야 했어요.
처음에는 좀 막막했어요. 일정을 챙기고, 회의를 잡고, 다른 팀과 일정을 맞추는 일은 개발자인 저에게 익숙하지 않았으니까요. 그럴 때마다 함께 진행한 PM인 Moana와 이야기하면서 하나씩 풀어 나갔어요.
챙길 일 중에서도 가장 걱정했던 건 인증이었어요. MCP는 인증 방식이 표준으로 정해져 있어요. OAuth 2.1을 따라야 하고, MCP를 연결할 때 광고주 본인의 동의를 거쳐야 해요. 사내에서만 쓰는 게 아니라 외부 광고주에게 공개하려면, 이러한 표준을 반드시 지원해야 했어요. 다행히 당근의 인증을 맡고 있는 Identity Service Team에서 이미 SSO(Single Sign-On)를 제공하고 있었어요.² 그래서 MCP 인증도 지원해 달라고 요청드렸고, 인증 서버를 표준에 맞게 고쳐 주셨어요.
그리고 나서 광고 MCP에 인증 서버를 연동하고 AI 서비스에 연결해 봤어요. 그런데 OpenAI의 Codex에서는 로그인을 누르면 에러가 뜨고 그대로 끊겼어요. OpenAI 문서에는 이 표준을 지원한다고 나와 있어서 더 당황했는데, 알고 보니 그때 이 인증 방식에 대한 지원은 Codex 정식 버전에는 아직 들어가지 않았고 알파 버전에만 막 들어온 참이었어요. 이대로 출시하면 Codex에서는 광고 MCP를 연결할 수 없는 상황이었어요. 그래서 틈날 때마다 새 버전이 나왔는지 들여다봤어요. 출시 전에 정식 버전에서도 지원하게 돼서, 그제야 한숨 돌렸어요.
그렇게 9월 16일, 광고 MCP를 공개 베타로 출시했어요.
출시 후엔 광고주가 어떻게 쓰는지 궁금했어요
원래라면 개발하고 QA하고 프로덕션에 배포하면 끝났다고 생각했을 것 같아요. 그런데 제품을 맡고 보니, 배포하고 나서 의도한 대로 동작하는지가 궁금했어요. 광고주들이 이걸 실제로 어떻게 쓰는지, 어떻게 하면 더 잘 쓰게 할 수 있을지 계속 고민하게 됐어요. 그래서 도구가 호출될 때마다 어떤 광고주가 어떤 AI 서비스에서 어떤 도구를 불렀는지 남기고, 계속해서 MCP를 쓰는지까지 대시보드에서 볼 수 있게 만들었어요.
출시 직후에는 틈날 때마다 대시보드를 열어 봤어요. 간편모드 사장님이 많은지 전문가모드 마케터가 많은지, 대행사 마케터도 쓰는지, 어떤 업종에서 많이 쓰는지 살펴보다 보니, 만들 때 고민했던 것들이 실제로 광고주에게 도움이 되는지 더 알고 싶어졌어요. 누가 시킨 건 아니었지만, 주간 리포트도 써 보고 데이터도 직접 분석해 봤어요.
광고실에서는 광고주 경험을 직접 이해하기 위해 실제 광고를 운영해 보는 개밥먹기(dogfooding)를 하고 있어요. 저도 한 빵집 광고를 맡고 있었는데, 가게 주변 좁은 지역에만 광고를 집행하다 보니 성과가 점점 떨어지고 있었어요. 그래서 광고 MCP를 연결해 에이전트에게 성과 분석을 맡겨 봤어요.
에이전트는 소재 피로도가 높다며 새 소재를 제안했어요. 성과가 낮은 광고를 찾아 끄고, 그 예산을 다른 광고로 옮기라는 제안도 했어요. 소재 피로도까지 짚어낼 줄은 몰라 놀랐어요. 실제 광고를 운영할 때 참고할 만한 제안이었어요.
이 경험을 통해 광고주가 MCP를 잘 쓰고 있는지는 호출 횟수만으로 판단할 수 없다고 느꼈어요. 분석이 광고주의 판단과 실제 운영에 얼마나 도움이 되는지가 더 중요했어요. 그래서 로드맵에서 다음 단계로 미뤄 둔 광고 수정 기능의 필요성도 분명해졌어요. 분석 결과를 실제 광고에 반영해야 운영에 변화가 생기니까요.
다음은 AI로 광고를 고치는 거예요
지금 광고 MCP는 조회만 할 수 있어요. 분석 결과를 광고에 반영하려면 광고주가 광고주센터에 들어가 직접 수정해야 해요. 다음 단계에서는 조회와 수정을 연결해 AI가 광고를 고치고 만들 수도 있게 하려고 해요.
장기적으로는 AI 서비스를 직접 사용하기 어려운 간편모드 사장님도 당근 안에서 에이전트의 도움을 받아 광고를 더 잘 운영할 수 있도록 하고 싶어요. 지금 만든 도구는 외부 AI 서비스뿐 아니라 당근 안의 에이전트에도 그대로 연결할 수 있어서, 도구를 새로 만들지 않아도 돼요.
기능을 넓히는 만큼, 이게 정말 광고주에게 도움이 되는지도 계속 확인하려고 해요. 광고를 더 자주, 더 잘 고칠 수 있으면 광고 성과가 좋아지고, 좋아진 성과는 광고주의 매출로, 다시 당근 광고의 매출로 이어질 거라고 보고 있어요. 광고 MCP는 이 흐름의 첫 단계인 “광고를 더 잘 고치는 일”을 AI로 더 쉽게 만들어 준다고 생각해요.
마치며
사내에 출시 공지를 올리며 감사 인사를 적다 보니, 고마운 분들이 많아서 빠진 분이 없는지 몇 번이나 다시 확인했어요. 제품 하나를 내놓기까지 이렇게 많은 분의 도움이 필요하다는 걸 이번에 알았어요. 갑작스러운 요청에도 함께해 주신 모든 분께 감사드려요.
처음에는 “이것도 개발자인 내 일인가?” 싶었어요. 그런데 내 프로젝트라고 생각하니 질문이 바뀌었어요. “어떻게 구현할까?”에서 “어떤 문제를 풀고, 문제가 실제로 해결됐는지 어떻게 확인할까?”로요. 제가 해 보고 도움이 됐던 습관을 세 가지로 정리해 봤어요.
- 구현하기 전에, 이 일이 어떤 문제를 푸는지 내 언어로 표현해 봐요.
- 배포하고 나서, 문제가 정말 풀렸는지 검증해 봐요.
- 내가 만든 기능을 사용자처럼 직접 써 봐요.
이 글이 개발자로서 역할을 넓혀 보려는 분께 작은 참고가 되면 좋겠어요. 궁금한 점이나 비슷한 경험이 있다면 댓글이나 제 링크드인으로 편하게 남겨 주세요.
각주
- 당근 광고는 광고주의 환경에 맞춰 서비스가 나뉘어요. 간편모드는 쉽고 빠르게 광고를 집행하고 싶은 소상공인 광고주를 위한 서비스이고, 전문가모드는 캠페인, 광고그룹, 소재 단위로 전략을 세우고 정밀한 타겟팅과 성과 분석이 필요한 마케팅 담당자와 광고주를 위한 서비스예요. 대행사 플랫폼은 여러 광고주의 광고를 대신 운영하는 대행사를 위한 서비스예요.
- 당근 SSO가 어떻게 만들어져 왔는지는 Identity Service Team이 쓴 당근의 인증은 어떻게 달라져 왔을까요?에서 볼 수 있어요.
- 같은 광고 소재를 같은 사람들에게 오래 보여 주면, 사람들이 익숙해져서 점점 반응하지 않게 되는 현상이에요. 클릭률이 시간이 지날수록 떨어지는 모습으로 나타나요.
국내 최초 광고 MCP를 출시하며, 개발자의 역할은 어디까지 넓어졌을까? was originally published in 당근 기술 블로그 on Medium, where people are continuing the conversation by highlighting and responding to this story.