Notion으로 회사 전체의 출시 운영을 확장한 Vercel

Notion은 Vercel의 수많은 팀이 에이전트를 구축하고 연결하며 배포하는 공간이 되었습니다. 그 중심에는 빠르게 움직이는 릴리즈 문화가 마찰 없이 운영되도록 책임지는 ShipOps 팀이 있죠. ShipOps 팀의 기술 프로그램 매니저이자 자칭 ‘Chief Notion Officer(최고 Notion 책임자)’인 Brian Emerick은 현재의 에이전트 체계를 구축한 주역입니다. 그리고 모든 에이전트는 하나의 핵심 시스템인 Launch Calendar를 중심으로 돌아갑니다.

Vercel에서 무언가를 출시할 때는 세 가지가 반드시 필요합니다. 문서를 작성하고, 체인지로그를 작성한 뒤, Launch Calendar에 등록하는 것입니다. Launch Calendar는 회사 전반에서 언제 무엇이 출시되는지 한 곳에서 확인할 수 있는 Notion 데이터베이스입니다. 모든 릴리즈 커뮤니케이션의 중심 역할을 하며, 엔지니어, 마케팅, 고객 지원 팀이 같은 정보를 공유하며 협업할 수 있도록 합니다.

이론적으로는 단순한 시스템이죠. 하지만 시간이 지나면서 데이터베이스는 모든 구성원의 업무를 모두 담으려다 보니 약 50개의 속성으로 점점 늘어나며 복잡해졌습니다. 가장 처음 도입된 해결 방식은 조건부 로직이 적용된 Notion 양식이었습니다. 어느 정도 도움이 되긴 했지만, 결국 양식이라는 구조적 한계는 벗어나지 못했습니다.

그 다음 등장한 Ship은 Slack에서 대화하듯 Launch Calendar에 출시 항목을 생성할 수 있는 커스텀 에이전트였습니다. 양식을 사용하는 대신 사용자는 이름, 날짜, 링크 등 현재까지 준비된 정보를 전달하기만 하면 되고, 나머지는 에이전트가 처리합니다. 입력된 정보, 추론한 정보, 아직 불확실한 항목을 구분해 정리한 뒤 Launch Calendar 항목을 생성하고 Slack 스레드에 링크를 공유합니다. 목표는 입력 과정을 더 빠르게 만들고, 기존 방식이라면 누락됐을 출시 항목까지 데이터베이스에 더 많이 담는 것입니다.

Ship은 생성 문제를 해결했지만, 출시 항목을 데이터베이스에 등록하는 것만으로는 충분하지 않았습니다. 각 출시 내용을 회사 내 적절한 담당자들이 정확히 인지하고 각자가 이미 사용하는 도구에서 즉시 대응할 수 있어야 했습니다.

그 역할을 바로 Ship-DX가 하죠. Launch Calendar에서 새로운 출시 항목이 생성되거나 업데이트되면, Ship-DX는 문서, 커뮤니티 등 Vercel의 개발자 경험(DX) 팀을 위한 Linear 이슈를 자동으로 생성합니다. Notion에서 세부 내용을 가져와 티켓 설명을 작성하고, 마감일을 설정하며, 하위 이슈를 생성한 뒤 각 작업을 기준으로 모두 적절한 팀에 할당합니다. 공유 Slack 스레드에서 관련 DX 팀과 조율할 수 있도록 출시 담당자에게 알림을 보내기도 합니다. Notion에서 변경 사항이 발생하면 Ship-DX는 Linear 티켓도 함께 업데이트하고, 어떤 내용이 왜 변경되었는지 코멘트로 남깁니다.

이를 위해 Brian의 팀은 Notion Worker를 구축했습니다. 템플릿을 기반으로 Linear 이슈를 생성하기 위해 GraphQL을 직접 호출하고 이후 업데이트와 댓글은 Linear MCP로 넘기는 방식입니다. 이것은 더 큰 흐름의 작은 한 단면에 불과합니다. Notion은 도구들 사이를 잇는 연결 계층의 역할을 하고, Worker가 그 사이의 공백을 메우며 전체 시스템이 작동하도록 합니다.

이미 출시된 항목을 마무리하는 과정에도 같은 원리가 적용됩니다. Ship Closer는 매일 아침 실행되어 Vercel의 공개 체인지로그를 Launch Calendar와 대조하고, 해당 출시가 예정일에 실제로 이루어졌는지 판단합니다. 확신이 서면 해당 항목을 출시 완료로 표시합니다. 확신이 없으면 바로 처리하지 않고 기다립니다. 같은 담당자에게 매일 알림이 가지 않도록 유예 기간이 시스템에 내장되어 있으며, 이후 모든 출시 파트너가 이미 보고 있는 Slack 스레드에서 후속 조치가 진행됩니다. 이는 Vercel의 더 큰 원칙과도 맞닿아 있습니다. 일하는 과정을 공개해 출시에 관여하는 모든 사람이 항상 최신 정보를 확인할 수 있도록 하는 것입니다. Ship Closer는 특정 역할에 집중된 작은 에이전트로, 누군가 직접 기억하고 챙기지 않아도 그 역할을 수행합니다.

Drew Bredvick이 이끄는 Vercel의 GTM 엔지니어링 팀은 영업과 마케팅에서 더 많은 계약을 성사시킬 수 있도록 도구를 구축하는 응용 AI 팀입니다. ShipOps와 달리 Vercel 자체 인프라에 배포하는 완전한 커스텀 에이전트를 코드 기반으로 직접 구축합니다.

하지만 개발을 진행할수록 Notion은 모든 것을 가능하게 하는 핵심 기반이 되어 갔습니다. 팀이 만든 모든 에이전트에는 다섯 가지 구성 요소가 있었습니다. 트리거, 토큰, 컴퓨팅, 프롬프트, 그리고 관찰 가능성입니다. 그중 가장 중요한 것은 프롬프트였습니다. 끊임없이 다듬어야 하는 요소이자 에이전트의 성능을 결정하는 핵심 변수였죠. 그리고 오랫동안 이 프롬프트는 코드베이스 안에 있었습니다.

Vercel의 CRO Nick Bogaty가 영업 에이전트 중 하나의 의사 결정 방식에 대해 질문했을 때, 누구도 깔끔하게 설명할 수 없었습니다. 로직은 GitHub 깊숙이 묻혀 있었고, 엔지니어가 아니면 접근조차 불가능했으며, 풀 리퀘스트와 리뷰, 전체 배포 없이는 수정도 불가능했습니다. 에이전트의 작동을 변경하려면 버그 수정처럼 시간이 오래 걸렸고 불필요하게 많은 사람이 개입해야 했습니다.

해결책은 사용자가 설정할 수 있는 모든 프롬프트를 Notion으로 옮기는 것이었습니다. 그 결과, 이제 영업 리더가 문서를 열어 프롬프트를 직접 수정하면 다음 실행 때 에이전트가 이를 반영합니다. 엔지니어링 팀의 개입은 필요 없습니다. 반복 주기는 대략 하루에서 5분으로 줄었고, 코드가 아닌 비즈니스 로직을 제대로 이해하는 사람들이 에이전트를 계속 정교하게 다듬어 가고 있습니다.

Vercel에서 사용하는 모든 에이전트가 Notion에 있는 것은 아닙니다. 다만 Vercel의 여러 팀에서 Notion은 각기 다른 방식과 이유로 쓰이지만, 결국 에이전트를 작동하게 하는 핵심이 되었습니다. Notion은 일부 에이전트가 실제로 구축되는 캔버스이자, 다른 에이전트들이 올바르게 작동할 수 있도록 지식과 로직을 제공하는 레이어이기도 합니다.

Brian의 팀이 Ship-DX로 만든 패턴은 확산되고 있으며, 가격 정책, 법무, 그리고 다른 파트너 팀을 위한 유사한 에이전트들도 이미 준비 중입니다. 빠른 출시 속도를 내세우는 기업에서 이런 흐름은 우연히 만들어지지 않습니다. 무엇을 먼저 만들지 아는 것에서 시작되죠.