팟캐스트 AI + a16z 에서 Resend의 창립자이자 CEO인 제노 로차(Zeno Rocha)가 a16z 파트너 요코 리(Yoko Li)와 함께한 인터뷰를 소개합니다. 에이전트, 그리고 MCP로 구동되는 생성형 AI가 개발자들의 이메일 경험은 물론 프로그래밍 전반의 세계를 어떻게 재편하고 있는지 다루는 인터뷰죠.
아! 모르는 분들을 위해 알려드리자면, AI + a16z는 유명한 벤처 캐피탈 회사인 Andreessen Horowitz (a16z)에서 운영하는 AI 관련 팟캐스트 시리즈랍니다.
오늘 에피소드가 어떤 내용을 다루는지 간단히 먼저 설명할게요.
첫 번째로는, 개발자 경험(Developer Experience)에 대한 제노의 집착이 어떻게 에이전트 경험(Agent Experience) 설계로 진화하게 되었는지 언급하고요. 그 다음으로 이메일이라는 보편적인 도구가, 에이전트가 이메일을 보내고, 해석하고, 최적화하는 미래를 대비해 어떻게 다시 설계되고 있는지 얘기 나눕니다.
더불어, 에이전트 친화적인 API를 만든다는 것이 실제로 어떤 의미를 가지는지, 그리고 신생 MCP 프로토콜이 어떻게 프로슈머(prosumer)와 개발자 모두의 창작 사이클을 단축시키고 있는지에 대한 대화가 이어집니다.
그럼, 지금부터는 두 사람의 대화를
최대한 현장감 있게 살려서 전달해볼게요.
(인삿말 생략)
Yoko Li
최근 들어, 에이전트 중심의 애플리케이션이 많이 등장하고 있고, 개발자들이 LLM을 활용해 완전히 새로운 경험을 만들고 있습니다. 흥미로운 점은, 제가 만난 많은 개발자들이 이제는 단지 인간을 위한 서비스를 만드는 것뿐만 아니라, 에이전트를 위한 경험도 함께 구축해야 한다고 말하고 있다는 거예요.
Zeno Rocha
네, 그렇죠.
개발자 경험 전반을 구축해 온 창업자로서, 저는 이 부분에 대해 정말 많은 생각을 하고 있어요. 10년 넘게 저는 개발자 경험에 꽂혀 있었고, 지금은 이게 에이전트 경험으로 옮겨가고 있습니다. SaaS 제품을 만드는 저희 입장에서도, 이 제품이 에이전트들이 사용하기 더 쉬워지도록 만드는 방법을 고민하고 있어요. 예를 들어, 예전에는 가입 시에 봇을 막기 위해 reCAPTCHA를 넣었지만, 이제는 봇이 가입하는 걸 막아야 할지 진지하게 고민해야 해요.
Resend는 이메일 API 인프라 제공업체로, 개발자들이 거래성 이메일이나 마케팅 이메일을 쉽게 보낼 수 있도록 도와줍니다. 저희는 이제 “이 에이전트들이 이메일을 가장 쉽게 보낼 수 있도록 하려면 어떻게 해야 할까?”를 끊임없이 생각하고 있어요. 제품의 각 영역에서 어떻게 하면 더 에이전트 친화적으로 만들 수 있을까 하는 고민을 하고 있는 거죠.
Yoko Li
‘에이전트 경험’이라는 용어도 참 흥미롭습니다. 저는 이 용어를 들으면, “이건 개발자 경험인데, 에이전트를 위한 걸까? 아니면 인간 개발자가 에이전트를 만들 수 있도록 돕는 개발자 경험일까? 아니면 그 중간 어딘가일까?” 하는 생각이 들어요.
Zeno Rocha
저는 개발자 경험이란 건 모든 작은 요소들의 합이라고 생각해요. 그런 작은 디테일들이 좋은 개발자 경험을 만들고, 나쁜 경험도 만들죠. 에이전트에 대해서도 마찬가지예요.
에이전트가 1등 시민인 세상을 만든다고 생각한다면, 우리가 지금까지 해오던 많은 일을 다시 생각해 봐야 해요. 예를 들어, 우리 업계에서 SendGrid, Postmark, Mailgun 같은 곳에 가서 서비스를 신청하면, 계정을 승인받기까지 이틀이나 걸리는 수동 인증 절차를 거쳐야 해요. 그런데 에이전트가 우선인 세계에서는 이틀씩 기다리는 건 말도 안 되죠. 에이전트는 그 정도로 기다리지 않아요. 그래서 Resend는 처음부터 마찰을 없애는 데 집중했어요. 회원가입하면 1분 안에 바로 이메일을 보낼 수 있도록 했습니다.
저희가 그렇게 제품을 설계했던 이유는, 전반적인 사용자 경험을 더 좋게 만들고 싶었기 때문이었어요. 그런데 알고 보니 이게 에이전트에게도 엄청난 해방감을 주더라고요. 그래서 저는 이걸 GX(Generative Experience)를 확장하는 것이라 생각해요. 대체하는 게 아니라, 이미 인간 개발자를 위해 문서나 지식 기반에 투자한 것들이 결과적으로 LLM의 출력 품질을 높이는 데도 도움이 돼요.
Yoko Li
이메일은 사실 모든 개발자들이 개인적으로든 프로젝트를 만들든 반드시 사용하게 되는 서비스잖아요. 누군가가 회원가입하면 환영 이메일을 보내고, 이런 흐름들이 있으니까요. 그럼 에이전트의 관점에서 이메일 세계는 어떤 모습일까요? 앞으로 에이전트들이 각자의 이메일 주소를 가지고 이메일을 주고받고 처리하게 될까요? 아니면 이메일 서비스를 프로그램적으로 활용하는 방식이 달라질까요?
Zeno Rocha
자율주행차로 비유하자면, Waymo 같은 기업은 새로운 도로를 만들 수 없었어요. 기존 도로 위에서 제품이 작동하도록 만들어야 했죠. 저는 이와 비슷하게, 이미 우리가 가진 API와 SDK, 프로토콜을 활용해야 한다고 생각해요. 물론 한계와 차이점도 분명히 존재하죠. 예를 들어, LLM.txt라는 포맷이 존재하는 이유는 LLM이 HTML, React 코드보다 일반 텍스트를 훨씬 잘 처리하기 때문이에요. 이메일도 마찬가지예요. 이메일을 보낼 때 사용할 수 있는 포맷은 HTML과 플레인 텍스트 두 가지뿐이죠. 그런데 요즘은 오히려 HTML보다 플레인 텍스트가 LLM이 처리하기 더 쉽고, 비용도 적게 듭니다. 그래서 API 키와 권한 설정도 새롭게 생각해야 해요. 사용자인가, 서비스 계정인가? 이 부분도 많은 고민이 필요합니다.
Yoko Li
LLM.txt가 존재하는 이유를 보면, LLM은 이런 정보를 더 잘 다루기 때문이에요. 반면, 인간은 웹사이트 전체를 복사하려면 스크래퍼를 짜야 하니까 귀찮아서 그냥 LLM.txt에서 복사해서 ChatGPT에 붙여 넣죠. 이메일도 마찬가지예요. 과거에는 시각적인 요소가 많은 마케팅 이메일이 효과적이었어요.
Zeno Rocha
그런데 이제 에이전트가 에이전트에게 이메일을 보내는 세상이 오면, 내용 위주의 이메일, 즉 마크업을 줄이고 플레인 텍스트 중심으로 가는 것이 훨씬 중요해질 겁니다.
Yoko Li
요즘 저는 애플리케이션이나 심지어 CLI 툴을 생성하는 데 대해 계속 생각하고 있어요. 저는 Cursor의 열렬한 팬이라 매일 사용하고 있는데요. 동시에, 소비자로서 이미 쓰고 있는 다양한 툴들을 어떻게 더 통합해서 흥미로운 경험을 만들어낼 수 있을까 계속 궁금해하고 있습니다. 소비자가 AI를 활용해서 완전히 새로운 콘텐츠를 생성한다면 어떤 모습일까요?
Zeno Rocha
두 달 전만 해도 제 생각은 완전히 달랐어요. Resend에 가입하는 사용자들에게 제가 항상 물어보는 게 있었거든요. “어디서 오셨어요? 뭘 하고 계세요?” 그런데 어느 날, 사람들이 이렇게 말하기 시작했어요. “Lovable에서 왔어요”, “Bolts에서 왔어요”, “Vzero에서 왔어요”, “ChatGPT가 추천했어요”, “Claude가 추천했어요.” 이런 식의 답변이 점점 많아지는 걸 보고, 저는 “아, 지금 뭔가 새로운 세계가 펼쳐지고 있구나” 하는 걸 실감했어요.
이런 ‘text to app’ 애플리케이션들—즉 텍스트 기반으로 앱을 생성해주는 툴들—은 정말 흥미롭습니다. 이들은 특정 사용자 유형이 특정한 웹사이트나 앱을 만들 수 있도록 도와주는 데 특화돼 있어요. 저는 앞으로 모든 산업군마다 이런 툴이 하나씩 생겨날 거라고 생각해요. 결과물은 조금씩 다르겠지만, 각 산업에 맞춘 무언가가 항상 필요하게 될 겁니다.
Yoko Li이런 앱들의 UI를 보면 거의 비슷해요. 왼쪽엔 챗 인터페이스, 오른쪽엔 프리뷰. 하지만 진짜 중요한 건 오른쪽 상단의 버튼이에요. 그 버튼, 즉 콜 투 액션(CTA)이 진짜 본질입니다. Bolt, Lovable, Vero 같은 경우에는 그 버튼이 ‘출판하기’, 즉 웹사이트를 실제로 배포하는 기능이에요. 그게 진짜 “아하!” 하는 순간이죠. 코드 생성이나 투두 앱 만드는 게 핵심이 아니라, 그걸 실제로 라이브로 띄우는 게 진짜인 거예요. 앞으로는 각 분야마다 그런 툴이 등장하게 될 거예요. 그리고 그 툴마다 “새로운 콜 투 액션”이 존재하겠죠.
이메일 세계로 돌아와 보면, 이메일을 생각하면 저는 항상 두 가지 입장에서 봐요. 발신자거나 수신자죠. 비개발자라면, 이메일이 잘 구조화돼서 정확한 사람에게 잘 보내지도록 하고, 오픈율도 잘 나오길 바랄 거예요. 수신자 입장에서는 내가 원하는 정보를 빨리 받거나, 읽는 것이 즐거운 메일이길 바라죠.
그렇다면 AI 시대의 이메일은 뭐가 달라질까요? 본질적인 추상화는 비슷할까요, 아니면 효율성 향상을 위한 변형일까요?
Zeno Rocha
이메일을 보낼 때 늘 어려운 건 “누구에게, 언제, 어떤 메시지를 보낼까?”예요. 그래서 ‘맞춤화’는 어느 때보다 더 중요해졌죠. 요즘 AI SDR 도구들이 많이 생겼지만, 단지 상대방의 마지막 LinkedIn 메시지 기반으로 개인화하는 건 이제 부족해요.
그리고 이메일을 똑같이 렌더링하려면 진짜 어려움이 많아요. Outlook, Gmail, Yahoo Mail 등에서 동일하게 보이게 하려면 정말 많은 작업이 필요해요. 이건 발신 측의 도전이죠. 수신 측에서는 “이메일이 진짜로 필요하냐”, “내가 원하는 정보냐”, “이게 메인함에 있는지, 스팸함에 있는지” 등등도 중요하죠. 양쪽 다 많은 과제가 있습니다.
Yoko Li
이메일을 활용해 진짜 다양한 경험을 만들어낼 수 있어요. 예를 들어, 저랑 제 남편은 우리 고양이가 주방 조리대에 올라가면 우리에게 이메일과 문자로 알림을 보내주는 앱을 만들었어요. 코드는 별로 없었지만, 이런 걸 만드는 건 진짜 재미있었어요. 결국 모두는 ‘알림’이 필요하니까요.
이런 ‘text to app’ 류의 애플리케이션에서, 이메일과 더 잘 통합해서 소비자들이 더 잘 활용할 수 있는 흥미로운 활용 사례에는 뭐가 있을까요? 그들이 이미 발견한 것 외에, 앞으로 발견할 수 있는 건 어떤 걸까요?
Zeno Rocha
저희는 2년 전 ‘React Email’이라는 오픈소스 프로젝트를 시작했어요. 이 프로젝트의 비전은 “이메일 작성 방식을 현대화하자”였죠. TypeScript, Tailwind, React 같은 현대적인 기술을 이메일에도 접목시키자는 취지였습니다. 이 산업은 정체돼 있고, 혁신이 부족하다고 느꼈거든요.
그래서 그걸 만들어냈고, 정말 많은 사람들이 매일 사용하고 있어요. 그런데 이제 LLM이 등장하면서 완전히 새로운 기회가 열렸어요. 예전에는 며칠이 걸리던 작업이 이제 몇 시간, 몇 분 만에 가능해졌고, LLM 덕분에 몇 초 만에도 가능해졌어요. 이건 단지 개발자만이 아니라, 마케터나 디자이너, 프로덕트 매니저처럼 코딩을 못하는 사람들도 이메일을 만들 수 있게 해주죠.
또 ‘new email’이라는 툴을 만들었고, 이건 아이디어에서 이메일 템플릿까지 몇 초 만에 갈 수 있도록 도와줍니다. 저는 이런 방식이 각 산업마다 형태는 다르지만 반드시 등장할 거라고 생각해요.
Yoko Li
예를 들어, 제가 마케터나 디자이너인데 이메일을 보내고 싶다면, 기존의 new email 같은 툴들을 어떻게 활용해서 고품질 이메일을 보낼 수 있을까요? 제 친구 중에 Uber에서 디자이너로 일하는 사람이 있는데요, 그 친구가 어느 날 그러더라고요. “지난 2주 동안 Figma를 한 번도 안 켰어. 그냥 Cursor나 v0 같은 도구로 다 프로토타입을 만들었어.” 이 말을 듣고 저는 정말 놀랐어요. “와, 이건 개발자의 정의 자체를 다시 쓰는 거구나.” 그게 이메일 세계에서도 똑같이 일어나는 거예요.
Zeno Rocha
예전에는 이메일을 만들려면 에이전시에 외주를 줘야 했고, 예쁜 이메일을 디자인해서 넘기면 그걸 코드로 바꿔주는 작업이 필요했어요. 근데 결과물은 종종 예쁘지만 내부 코드는 엉망이었죠. 이제는 그걸 LLM에게 맡길 수 있어요. 그리고 진짜 창작자, 즉 이메일의 카피를 생각하고 전체적인 톤 앤 매너를 고민하는 사람에게 권한을 넘길 수 있게 됐어요. 창작자 스스로가 계속 수정하고 실험해볼 수 있게 된 거죠.
여러분도 아시겠지만, 우리가 뭔가를 만들 때 첫 번째 버전은 항상 완벽하지 않아요. 오히려 시작일 뿐이죠. 그래서 그걸 직접 보면서 “오, 이거 작동하네, 그럼 다음엔 뭘 더 해볼 수 있지?” 하는 식으로 아이디어가 발전하죠. 그런데 예전에는 에이전시와 논의하고 수정 요청하고 피드백 받고 다시 반영하는 데 시간이 너무 오래 걸렸어요. 그 시간들이 사실은 창의적인 사람의 반복 실험에 쓰였어야 했던 시간인데 말이에요. 이젠 그걸 바로 바로 자기 손으로 해볼 수 있는 세상이 온 거죠. 이건 진짜 창작 루프를 극단적으로 단축시켜 줍니다.
Yoko Li
이 얘기를 하니까, 예전 유화 화가들이 흰 캔버스에 바로 그림을 시작하기 부담스러워서 먼저 회색 물감을 바르고 헝겊으로 문질러 색을 입힌다는 얘기가 떠오르네요. 빈 캔버스는 너무 무섭거든요. 근데 살짝 색이 들어가면 덜 부담스럽고 뭔가 행동을 취할 용기가 생겨요. 이게 지금 우리가 만든 이메일 생성 도구와 비슷하다고 느껴요.
Zeno Rocha
실제로도 그랬어요. 어제 있었던 일인데, 저희가 new email이라는 제품을 몇몇 친구들에게 줘봤거든요. 그 중 한 친구가 그러더라고요. “나는 뭔가 창의적인 이메일을 만들고 싶은데, 처음 몇 번 프롬프트를 넣을 때까지는 계속 비슷한 결과가 나와서 아쉬워.” 왜 그럴까 생각해보니, 저희가 시스템 프롬프트에 “애플 스타일의 이메일을 만들어줘. 곡선 테두리에 블랙 앤 화이트 느낌으로.”라고 지시문을 넣어놨더라고요.
처음에는 이렇게 하면 기본값이 예뻐서 좋겠다고 생각했지만, 되려 창의적인 사람에게는 제약이 되었던 거죠. 그러니까 처음 버전은 꼭 필요해요. 근데 그 후의 반복이 너무 느리면 그것도 안 좋죠. 이 균형이 정말 중요한 포인트예요.
Yoko Li
이건 이미지 생성의 세계와도 비슷해요. LORA(스타일별 소형 학습 모델)를 훈련시켜서 인상파 스타일, 만화 스타일 같은 특정 스타일을 먼저 정한 다음 거기서 출발하고, 이후엔 자기가 원하는 스타일로 수정해나가죠. 일종의 조각처럼요. 이메일 템플릿도 이제는 예술적 표현 수단이 되는 시대예요. 예전에는 혼자 하기 어려웠던 걸, 이제는 직접 해볼 수 있게 됐거든요.
예전엔 이메일 템플릿이란 게 전부 바닐라 HTML이었어요. 진짜 너무 정적이고, 2025년이 된 지금도 여전히 그렇게 되어 있다는 게 안타까울 정도였죠. 저도 처음 업계에 들어왔을 때부터 이건 좀 이상하다고 느꼈고, 그 이후로 거의 진화가 없었어요. 그래서 저희가 새로운 경험, 새로운 추상화 레벨을 만드는 거예요. 새로운 사용자층을 위해서요.
Zeno Rocha
웹은 그동안 정말 많이 진화했잖아요. 예전엔 Ajax나 IE6 같은 브라우저 간 호환 문제가 엄청났지만, 이제는 그런 문제 거의 없어요. 근데 이메일은 여전히 Outlook, Superhuman, Notion Mail 같은 클라이언트마다 다르게 보이는 문제를 안고 있어요. 지금 이 순간에도 이메일 렌더링 문제는 여전히 미해결 과제로 남아 있습니다.
Yoko Li
생성이라는 행위에 대해서 이야기하다 보면, 이게 ‘에이전틱 워크플로우(agentic workflow)’일까? 나는 지금 어떤 의미에서는 에이전트를 만들고 있는 것 같은데, 또 어떤 면에서는 이게 진짜 에이전트인가? 싶은 거예요. 여러분이 생각하는 ‘에이전트’의 정의는 뭔가요?
Zeno Rocha
저는 ‘에이전트’라는 개념을 도구 세트가 특정 목적을 달성하기 위해 실행되는 일련의 프로세스로 생각해요. 몇 단계를 거쳐 결과에 도달하긴 하지만, 여전히 하나의 일에 집중하는 흐름이죠. 예를 들어, new email이라는 제품에서는 이메일 템플릿을 만드는 에이전트가 있고, 그걸 전송하거나 예약하는 또 다른 에이전트가 있어요. 그러니까 여러 에이전트가 동시에 작동할 수 있죠. 마치 한 회사 안에 마케팅 담당자, 디자인 담당자처럼 각각의 역할이 나뉘어 있는 것처럼요.
저는 이걸 일종의 ‘멀티스텝 LLM 실행 프로세스’로 생각해요. 시스템 수준에서 하나의 프로세스라고 보면 되는데, 차이점은 그 중간에 LLM이 판단을 한다는 거죠. 나머지는 기술적인 세부 사항일 뿐이고요. 한쪽 끝에는 한 번만 실행되는 생성 프로세스가 있어요. 그것도 어떤 의미에선 에이전트라고 볼 수 있죠. 코파일럿이 그런 예예요. 다른 한쪽 끝에는 AGI 같은 형태가 있는데, 이건 이메일도 보내고 은행 계좌도 관리하는 전방위적 에이전트죠.
그래서 저는 개발자로서 이 공간에서 다양한 방식으로 에이전트를 만들어 보고 있어요. 플랫폼이라면, “에이전트가 우리에게 쉽게 방문하게 하려면 어떻게 해야 하지?” “다른 개발자들이 우리 기반으로 쉽게 도구를 만들게 하려면?” 이런 걸 고민하겠죠. 반대로 개발자 입장에선, “다른 플랫폼에서 쓰이는 다양한 API를 내가 일일이 다시 구현하지 않고 어떻게 쉽게 통합할 수 있을까?”가 관건일 거예요.
Yoko Li
이런 관점에서 개발자들에게 어떤 조언을 해주시겠어요? 에이전트를 만들고 싶어하는 개발자들에게, 지금은 어떤 게 좋을까요?
Zeno Rocha
요즘 부상하고 있는 표준은 확실히 MCP(Model Context Protocol)예요. 아직은 이 MCP를 다른 AI 모델들이 도입할까 말까 하는 과도기죠. 만약 OpenAI 같은 곳이 MCP를 채택한다면, 그때부터는 완전히 게임 체인저가 될 거예요. 그게 사실상 표준이 되는 순간이죠.
저는 API 제공자로서 Resend를 위한 MCP를 만들고 싶어요. 그래야 다른 에이전트들이 Resend를 통해 이메일을 보낼 수 있고, 연락처 목록을 보고, 사람을 추가하거나 삭제하고, 이메일 성과를 보고, 클릭률 높은 이메일을 기준으로 최적화할 수 있게 되죠. 이런 식으로 계속 발전시킬 수 있는 가능성이 열려 있어요. 이건 계속 진화하는 생태계라서 정답은 없어요. MCP 서버 목록을 모아놓은 갤러리를 만들거나 MCP 마켓플레이스를 만들려는 시도들도 나오고 있고요.
이런 흐름은 마치 예전에 API가 막 등장하던 시절 같죠. Rapid API 같은 마켓플레이스가 생기면서, 사람들이 “이제 API도 쇼핑하듯이 찾을 수 있겠네” 하는 인식이 있었으니까까요. 어느 정도까지는 그게 유용했어요. 하지만 결국 중요한 건 문제를 해결하는 거예요. 예를 들어, 결제 기능이 필요하면 Stripe API를 찾고, 이메일이면 Resend API를 쓰는 식으로요.
MCP 포맷은 굉장히 흥미로운데, 지금은 인터페이스가 한정적이에요. Cursor, Claude 데스크탑, Windsurf 같은 에디터뿐이잖아요. 그런데 만약 이게 소비자 레이어까지 확장된다면? 그땐 정말 엄청난 일이 일어날 수 있다고 생각해요.
그리고 또 하나 흥미로운 건, 스스로 “나는 MCP 서버일까, 클라이언트일까?” 라는 질문을 하게 된다는 거예요. 꼭 하나만 골라야 할 필요는 없거든요. 여러분이 만든 new email이나 Resend 같은 경우, 둘 다 될 수 있어요.
예를 들어, “linear에서 상위 10개 피처 요청을 가져오고, 그걸 바탕으로 이메일 초안을 작성한 다음, 전송해줘.”라고 말하면, 세 가지 서비스를 연결해서 하나의 작업을 수행하게 만들 수 있어요. 우리는 Resend를 통해 팀 전체가 함께 이메일을 작성하고, 회의가 끝나면 바로 발송하는 구조를 만들었어요. 정말 재미있죠.
대부분의 MCP 관련 유스케이스는 지금까지는 ‘로컬 퍼스트(local-first)’ 방식이에요. 왜냐하면 현재의 MCP 클라이언트 구현 방식이 그렇게 되어 있거든요. SSE(Server-Sent Events)는 구현이 번거롭기 때문에, 대부분은 MCP를 ‘명령형(command-style)’으로 구현해서 로컬에서 명령을 실행하는 방식이에요. 이 프로세스가 외부의 써드파티 API들을 호출하도록 설계돼 있는 거죠.
Yoko Li
그렇다면, MCP가 진정한 생태계로 확장되기 위해 지금 무엇이 부족하다고 생각하나요?
Zeno Rocha
제 생각에는 가장 큰 걸림돌은 바로 다른 모델들의 채택이에요. 그게 가장 중요한 요소죠. MCP는 지금 여러 가지 전선에서 확장 중이에요. 예를 들어, 파일 시스템 접근, 데스크탑에서 실행되는 Apple API 접근 같은 것들이 그 예에요. 최근 Raycast 릴리스를 보면, 이들이 AI 확장을 구축하고 데스크탑 레벨에서 다양한 워크플로우를 통합하는 걸 볼 수 있죠.
이처럼 우리는 점점 더 하위의 추상화 레이어까지 탐험하고 있어요. 우리가 할 수 있는 일이 점점 더 많아지고 있다는 얘기예요. 예를 들어, Apple Notes에 들어가서 내 노트를 가져오고, 그걸 다른 작업에 활용하는 거예요. 이건 정말 매혹적인 흐름이고, 사람들이 이 생태계를 계속 받아들이기를 바라고 있어요.
Yoko Li
그렇다면, 앞으로 어떤 종류의 MCP 워크플로우가 더 많이 확산될까요?
Zeno Rocha
‘시스템 오브 레코드(system-of-record)’ 계열의 애플리케이션들이 이 새로운 혁신의 중심에 설 거라고 생각해요. 왜냐하면 모든 이슈들은 이미 Linear에 있고, 이메일은 Gmail에, 노트는 Notion이나 Apple Notes에 저장돼 있잖아요. 그러니까 이 정보들을 기반으로 다음 작업을 연결하는 게 자연스럽게 될 거예요.
Yoko Li
정말 흥미롭네요. ‘데이터 중력(data gravity)’이라는 개념이 여기에 정확히 들어맞는 것 같아요. 그리고 한 가지 궁금한 점은, 지금 존재하는 MCP 관련 클라이언트나 서버들이 대부분 **자체 데이터베이스를 운영하고 있는가?**라는 점이에요. 상태(state)를 저장하려면 어딘가에 기록이 필요하니까요.
Zeno Rocha
그 질문 정말 좋아요. 상태 저장이 필요하다는 건 명백하죠. 예를 들어, 우리가 앞서 말한 텍스트 기반 앱 생성기들, 예를 들면 Lovable이나 V0 같은 툴들은 Supabase 같은 걸 쓰고 있고, Rapid이나 Create.xyz는 Neon을 씁니다. 저는 이 도구들 사이의 경쟁이 결국 “누가 마찰을 가장 줄일 수 있는가”, “누가 Postgres 데이터베이스를 더 빨리 띄울 수 있는가”가 될 거라고 봐요.
MCP가 전면에 나서게 되면, 이런 데이터베이스들이 정말 빨리 생성되고 상태를 저장할 수 있어야 하고, 어쩌면 완전히 새로운 형태의 데이터베이스가 필요해질지도 몰라요.
Yoko Li
너무 공감돼요. 최근에 Resend가 LLM이나 에이전트들에게 계속 추천되더라고요. 훈련 데이터에 많이 포함됐기 때문이겠죠. 저도 ChatGPT에 이메일 초안을 요청하면, 바로 React Email 템플릿이 나오는 걸 보고 “얘가 이걸 어떻게 알았지?” 하고 놀란 적이 있어요.
그렇다면, Resend를 가지고 개발자들이 만들 수 있는 좀 더 창의적인 결과물은 어떤 게 있을지 궁금하네요.
Zeno Rocha
정말 흥미로운 사례가 많아요. 예를 들어, 최근에 본 것 중에 매일 새로운 콘텐츠를 생성해서 보내는 AI 뉴스레터가 있었어요. 콘텐츠 소스가 너무 다양해요. X(구 Twitter)에서 최신 뉴스를 가져오고, 다른 매체들에서도 가져와서 조합해요. 그리고 수신자 맞춤형 뉴스레터를 만들어내는 거예요.
기존에는 ‘모두를 만족시키려다 아무도 만족 못 시키는’ 방식이었잖아요. 근데 이건 진짜 각자에게 딱 맞는 뉴스레터를 만들어주는 방식이에요. 저는 그게 정말 좋더라고요. 그리고 어떤 사람들은 Resend 계정 하나에 수천 개의 도메인을 연결해 두기도 해요. 새 앱을 만들 때마다 새 도메인을 만들어서 이메일 발송 기능까지 바로 셋업하는 거죠.
Yoko Li
와, Resend에서 그런 게 가능해요? 프로그램적으로 새 도메인을 생성하는 거요?
Zeno Rocha
가능해요. 예를 들어, Payload CMS는 클라우드 기반 제품을 제공하는데요. 사용자가 가입하면 자체 서버를 배포할 필요 없이 바로 클라우드 인스턴스를 만들어줘요. 이때마다 Resend로 새 도메인을 프로비저닝하고, 이메일 발송 기능까지 자동으로 설정되죠. DKIM이나 SPF 레코드를 수동으로 등록할 필요 없이요. 처음부터 이메일 발송이 가능한 상태가 되는 거예요. 예전엔 이게 굉장히 어려운 일이었죠.
그래서 저는 진짜 에이전트들이 자기 도메인을 갖는 시대가 기대돼요. 에이전트 기반 사이드 프로젝트들이 앞으로 인간보다 훨씬 많아질 수도 있다고 생각해요. 에이전트들이 아이디어를 떠올리고 “이 도메인 사용 가능한지 확인해볼까?”, “가능하네? 바로 사자.” 하는 식으로 움직이겠죠.
Yoko Li
저는 새로운 프로젝트 아이디어가 떠오를 때마다 도메인을 사는 걸 정말 좋아하거든요. 사실 대부분은 쓰지도 않는데, 매년 도메인 요금으로만 몇 백 달러는 그냥 쓰고 있는 것 같아요. 얼마 전엔 친구가 저한테 문자를 보내서 “야, li가 최상위 도메인(TLD)이라는 거 알았어? 내 성이랑 같아!” 하더라고요. 제 이름도 흔하지 않아서 yoko라는 도메인을 바로 등록할 수 있었어요. 지금은 그 도메인이 제 웹사이트로 리디렉션되죠.
Zeno Rocha
저도 n-o, 그러니까 노르웨이의 최상위 도메인 .no를 갖고 싶었는데요. z.no라는 도메인을 노렸는데 누가 이미 가져가 버렸더라고요. 아직도 시도하고 있어요.
Yoko Li
이미 누가 가져간 거였어요?
Zeno Rocha
네, 누가 이미 등록했더라고요.
Yoko Li
음… 그럼 우리는 에이전트를 만들어서 도메인을 체크하게 하면 되겠네요. 매일 확인해서 사용 가능해지면 자동으로 사도록요.
Zeno Rocha
진짜요.
Yoko Li
그럼 AI 분야에서 앱을 만들거나, 에이전트를 위한 앱을 만들고자 하는 개발자들에게 조언을 해주신다면, 뭐라고 말하고 싶으세요? 지금 이 AI의 물결을 어떻게 타야 할까요?
Zeno Rocha
요즘 개발자이자 창업자로서 매일 여러 가지 모자를 쓰고 살아가고 있는데요. 지난 2년 동안은 AI를 일부러 피해서 살았어요. 그 강력함은 알았고 사용자로서는 열심히 썼지만, 직접 만드는 데는 손을 못 댔어요. 회사 만드는 데 너무 바빴거든요. 그러다 어느 날 “이제 진짜 AI를 써야겠다” 하고 마음먹고 시작했어요.
그래서 제일 먼저 한 건 도구 체인을 바꾸는 일이었어요. 예전엔 VS Code를 썼다면, 이제는 Cursor로 바꿔봐야 해요. 처음엔 진짜 불편했어요. 익숙하던 확장 기능들도 안 되고, “이 Cursor 진짜 싫다…” 했죠. 근데 지금은 Cursor 없인 못 살아요. Raycast도 마찬가지고, 데스크탑 수준에서 AI가 도와주는 툴들을 점점 더 쓰고 있어요.
그러니까 첫걸음은 내가 쓰는 툴에서부터 AI를 넣는 것이에요. 그리고 다음은 실제 유스케이스를 찾는 것이에요. Stripe 팀과 얘기했을 때도 비슷한 이야기를 들었어요. Stripe API는 정말 방대하잖아요. 근데 그들은 API 스펙 전체를 가지고 MCP 서버를 자동 생성하지 않았어요. “우리 사용자들이 실제로 어떤 작업을 하는가?”에서 출발해서 필요한 부분만 MCP로 노출한 거예요. 꼭 전체 커버리지가 필요하지는 않다는 거죠.
그게 제가 전통적인 소프트웨어 엔지니어에서 AI 엔지니어로 전환하면서 배운 가장 큰 교훈이에요. AI 도구로 직접 만들면서, 내 삶에서 실제 문제를 해결하거나 개선할 수 있는 부분을 찾는 것. 예를 들면, 너희가 만든 고양이 알림 앱처럼요. 진짜 내가 겪고 있는 문제를 해결하는 건 언제나 최고예요. 또는 단순히 내가 ‘이거 궁금해!’ 하고 파고드는 것도요. 그게 결국 제일 멋진 결과로 이어지더라고요.
Yoko Li
좋아요. 그럼 마지막 질문이에요. 저 이 질문 창업자들한테 묻는 거 정말 좋아하는데요—혹시 시간이 있다면, 만들고 싶은 사이드 프로젝트가 있나요?
Zeno Rocha
와, 저 사이드 프로젝트 진짜 많아요. 예를 들면 제가 만든 Dracula 테마요. 그냥 매일 겪는 문제를 해결하고 싶어서 만들었어요. 예전엔 코드 에디터, 브라우저, 기타 툴마다 다 다른 테마를 써야 했거든요. 저는 툴을 바꿀 때마다 인지 부담이 너무 커서, 그냥 모든 곳에서 통일되게 쓸 수 있는 테마를 만들고 싶었어요. 그게 Dracula의 시작이었죠.
Resend도 마찬가지예요. 제 고통을 해결하려고 만든 거예요. 요즘은 개인적인 일들, DMV(차량 등록청) 가서 차량 등록 갱신하고, 보험 관련된 것들 처리하는 그런 일들이 너무 싫어요. 그런 거 다 자동화해주는 에이전트가 있다면 정말 좋겠어요. DMV용 에이전트, 누가 만들면 저 진짜 1호 고객 될 거예요. 이 글 보고 있다면 제발 만들어 주세요. 꼭 알려 주세요.
Yoko Li
Dracula 테마 얘기 나와서 그런데, 제가 처음 당신 만났을 때 진짜 깜짝 놀랐어요. “어, 이 사람 그 유명한 Dracula 만든 사람이야?” 했었거든요. iTerm 색상 테마에서 항상 상위권에 있잖아요. 근데 이 테마는 어떻게 시작된 거예요?
Zeno Rocha
그 얘기는 좀 미쳤죠. 지금 Dracula는 사용자 수가 900만 명이에요. 여전히 사이드 프로젝트일 뿐이고요. Resend가 메인 프로젝트죠.
처음 시작은 독일에서 스페인으로 여행하던 중이었어요. 비행기에서 갑자기 너무 아파서, 혼자 있었는데 스페인은 처음이라 진짜 무섭더라고요. 결국 마드리드에 비상 착륙하고, 응급차로 병원에 실려 갔어요. 약 처방 받고 괜찮아지길래 “이제 호텔 가도 될까요?” 했더니 “아뇨, 병원에 더 있어야 해요.” 그래서 결국 3주 동안 입원했어요.
처음 며칠 지나고 좀 나아지자, 동료들에게 “노트북 좀 갖다 줄 수 있어요?” 했어요. 그때 컴퓨터는 비행기에 놓고 그냥 실려 왔거든요. 컴퓨터 받아서 병원 침대에서 코딩을 하기 시작했어요. 너무 행복했죠. 근데 하루는 잠깐 물 가지러 나갔다 오니까, 누가 병실에서 제 노트북을 훔쳐갔어요. 병원에서요! 진짜 최악이었어요.
다음 날 동료들이 새 노트북을 가져다줬고, 저는 새로운 기계 세팅을 시작했어요. 단축키, 테마 다 설정하면서 “왜 도구마다 테마가 다 다르지?” 하는 생각이 들었죠. 그래서 모든 툴에서 쓸 수 있는 테마를 직접 만들기로 한 거예요. 그게 Dracula의 시작이었어요. 병원에서 만든 거죠.
Yoko Li
당시에도 인기 테마는 있었어요? 예를 들면 Monokai 같은 거요?
Zeno Rocha
네, Monokai나 밝은 크림색 계열 테마도 있었어요. 근데 저는 진한 색감이 좋았어요. Dracula는 그냥 어두운 테마여서 그렇게 이름 붙인 것 같아요. 특별한 이유는 없어요. 근데 그 테마가 제 인생을 바꿨어요. 나중엔 프로 버전을 출시했는데, 색상 팔레트 하나로 30만 달러 넘게 벌었어요. 그 덕분에 “나도 진짜 회사를 세울 수 있겠구나” 하는 자신감을 얻었고, 그게 지금의 Resend로 이어졌어요.
Yoko Li
와… 그 얘기 너무 멋져요. 지금도 이메일 템플릿을 팔고 있는 사람들 많은데, Resend는 새로운 사용자층이 이메일 템플릿을 직접 만들어서 판매까지 할 수 있게 도와주는 플랫폼이 되고 있네요. 예쁘게 만들기만 하면, 직접 팔 수도 있고요.
Zeno Rocha
맞아요. 아직은 React Email 템플릿을 판매하는 사용자 사례는 없지만, 그걸 위한 라이브러리들이 많이 생기고 있어요.
Yoko Li
좋아요. 그럼 진짜 마지막 질문입니다. 만약 미래를 들여다볼 수 있는 수정구슬이 있다면, 이메일과 AI의 미래는 어떤 모습일까요?
Zeno Rocha
지금은 여전히 대부분의 행동이 인간에 의해 수행되고 있어요. Supabase 같은 데이터베이스도 인간이 만들었고, Resend의 이메일도 인간이 작성하거나 인간이 초안을 만든 후에 전송되죠. 하지만 앞으로는 이 주체가 에이전트로 바뀌게 될 거예요. 저는 미래의 행동 대다수가 인간이 아닌 에이전트에 의해 수행될 거라고 믿어요. 그게 우리가 살아갈 현실이에요.
그래서 우리는 제품을 만드는 방식 전체를 에이전트 중심으로 다시 생각해야 합니다.
Yoko Li
조금만 더 자세히 이야기해주실 수 있을까요? 이건 너무 중요한 포인트라서요.
Zeno Rocha
제품을 재설계한다는 건 온보딩 단계부터 다시 생각해야 한다는 뜻이에요. 가입할 때 10단계 거치게 하면 안 되고, 계정 승인받느라 이틀씩 기다리게 하면 안 돼요. 데모 요청해서 담당자가 스케줄 잡고 통화하는 방식도 이제는 곤란해요.에이전트는 가능한 빨리 ‘아하!’ 모먼트를 경험해야 하고, 가능한 빨리 행동을 취할 수 있어야 해요. 그래서 권한 관리, 인증 시스템, 역할 기반 접근 제어(RBAC) 같은 것도 완전히 새로 짜야 하죠.
그리고 SaaS마다 활동 로그 페이지가 있잖아요. 지금은 인간 사용자가 뭘 했는지 기록하는 용도인데, 이제는 에이전트의 행동을 훨씬 더 정밀하게 기록해야 합니다다. 왜냐면 에이전트는 분명히 실수할 거고, 그 실수가 뭔지 인간이 추적 가능해야 하거든요. 특히 파괴적인 행동을 했을 때, 누가 왜 그랬는지를 알아야 해요. 이게 앞으로 제품 설계에서 완전히 달라질 포인트예요.
왜냐하면 앞으로 인간만이 유일한 사용자가 아니게 될테니까요.
Yoko Li
정말 강력하고 멋진 이야기였어요. 오늘 나와주셔서 정말 감사해요. 너무 재미있었습니다.
Zeno Rocha
저야말로 감사합니다.
AI 시대, 가장 확실한 대비를 위해
지금 바로 배울 수 있는 [ AI ] 관련 강의가 준비되어있어요.
지금 바로 아래에서 관심을 끄는 강의를 눌러 확인해보세요.
 테디노트의 RAG 비법노트 : 랭체인을 활용한GPT부터 로컬 모델까지의 RAG 가이드 |
 모두의 AI 케인의 Agent로 완성하는 RAG:데이터 별 아키텍처 설계를 중심으로 |
차원이 다른 연구 프로세스 |
2025 AI 시대 일잘러를 위한 비현실적인 |
