일본과 한국의 GitHub 마케팅 팀은 등록 페이지, 링크, 이메일 캠페인, 고객 데이터베이스 사이에서 각 단계를 수동으로 관리하는 대신, 반복적인 이벤트 운영을 GitHub 안에서 실행 가능한 워크플로로 전환했다. Tomoko Tanaka에 따르면, 프로세스는 하나의 GitHub Issue에서 시작하며, 이후 GitHub Actions가 이벤트 설정, 등록자 목록 검토, 이벤트 종료 후 후속 작업을 수행한다.
이 글은 새로운 제품의 출시를 소개하는 것이 아니라, Tanaka가 기존 GitHub 도구를 사용해 발전시킨 운영 방식을 소개한다. 또한 GitHub Copilot을 활용해 내부 운영 절차 가이드를 자동화로 전환했다. 이 사례의 중요성은 마케팅 운영과 소프트웨어 팀에 익숙한 검토, 변경 이력, 트리거, 반복 가능한 워크플로 같은 개념을 연결한다는 데 있다.
문제: 작은 단계와 연쇄적인 오류
팀의 이벤트에는 엔터프라이즈 개발자를 위한 정기 웨비나, 도쿄의 커뮤니티 모임, 서울의 비공개 임원 세션이 포함된다. 이벤트가 승인되면 반복적인 작업이 이어진다. 랜딩 페이지 복사, 각 채널에 사용할 UTM 태그가 포함된 링크 생성, 초대 메시지 작성, 발송 요청 등록, 두 개의 프로젝트 보드에 이벤트 추가, 그리고 이벤트 당일까지 매일 등록자 목록을 다운로드하고 정리하는 작업이다.
이벤트가 끝난 뒤에는 참석자 목록을 내보내고, 고객 관계 관리 시스템에 업로드할 수 있도록 형식을 다시 구성하고, 레코드에 적절한 태그를 지정하고, 보고서를 작성해야 한다. 각각의 단계가 개별적으로 어렵지는 않지만, 링크나 캠페인 이름의 오류 또는 일일 업데이트 누락은 보고서와 후속 운영에 영향을 줄 수 있다.
워크플로 구축을 위한 세 가지 구성 요소
이 실험은 GitHub의 세 가지 핵심 기능을 기반으로 했다.
- Issue Forms: 빈 텍스트 상자 대신 구조화된 요청 양식으로 작동하며, 이벤트 제목과 날짜, 지역, 캠페인 이름, 대상 고객과 같은 필드를 수집한다. 웨비나와 오프라인 이벤트에 서로 다른 양식이 있지만, 동일한 실행 메커니즘으로 연결된다.
- Labels: 설명용 태그로만 사용되지 않고 실행 키로 사용된다. 예를 들어 event-setup과 같은 라벨을 추가하면 연결된 워크플로가 시작된다.
- GitHub Actions: 작업을 실행하고, 요청 본문에 있는 필드를 읽은 다음, 외부 도구에 연결해 이벤트를 설정하거나 등록자를 추적하거나 후속 작업을 마무리한다.
이 설계에서 Issue는 계획, 논의, 상태를 하나로 묶는 작업 단위가 되며, 의사 결정에 대한 가시적인 기록과 각 변경 사항에 대한 링크를 제공한다. 또한 워크플로 수정은 병합 전에 풀 리퀘스트와 검토를 거치는 소프트웨어 변경으로 다룰 수 있다.
절차를 자동화로 전환하는 GitHub Copilot의 역할
Tanaka는 곧바로 코드를 작성하는 대신 팀의 운영 가이드를 작성해 GitHub Copilot에 제공한 뒤, 대화를 통해 자동화를 발전시켰다. 그녀는 과거 Linux 서버에서 데이터베이스를 운영한 경험 덕분에 이러한 절차를 프로그래밍 가능한 파이프라인으로 바라볼 수 있었다고 말한다. 동시에 자신의 프로그래밍 역량이 예전과 같지는 않다고 인정한다.
계획은 아이디어를 설명하는 대화에서 시작된다. 예를 들어 11월에 AI 지원 개발에 관한 웨비나를 개최하는 경우다. 그다음 Copilot은 저장소 루트에 있는 AGENTS.md 파일을 읽는다. 이 파일은 캠페인 명명 규칙, 회계 분기와 날짜의 연결 방식, 시간대, 초대 메시지 기준을 정하는 Markdown 형식의 가이드다. Copilot은 이러한 규칙과 이전의 유사한 이벤트를 바탕으로 캠페인 이름을 제안하고, 초대 메시지 두 가지 버전을 작성하며, 운영 가이드에서 요구하는 질문을 제시한다.
실제로 무엇이 달라지는가?
이 방식은 계획 단계에서 사람의 판단을 없애지 않으면서 반복적인 수작업을 줄일 수 있게 한다. 대화는 특정 이벤트에 맞게 조정할 여지를 남기고, 자동화는 승인된 뒤 고정된 단계를 수행한다. 글에 따르면 이벤트를 수동으로 준비하는 데는 약 이틀이 걸렸지만, 이제는 하나의 Issue에서 프로세스를 시작한 뒤 설정, 등록자 목록의 일일 점검, 이벤트 종료 후 정리를 실행한다.
결정적인 요소는 GitHub Actions만이 아니라 다른 도구를 프로그래밍할 수 있다는 점이다. 이벤트 관리 플랫폼은 API를 제공하고, 고객 관계 관리 시스템은 필요한 작업을 지원하며 브라우저를 통해 로그인하는 공식 CLI를 사용하므로 Tanaka는 API 키를 설정할 필요가 없었다. 이 글에서 도출하는 규칙은 API 또는 CLI가 있으면 프로그래밍 방식으로 연결할 수 있는 길이 열린다는 것이다. 대상이 이벤트 플랫폼이든 CRM 시스템이든 양식 생성기든 분석 서비스든 마찬가지다.
이 사례는 여러 시장으로 구성된 환경에서 맞춤형 워크플로를 구축하는 이유도 보여준다. APAC 팀은 하나의 시장으로 운영되지 않는다. 동일한 웨비나가 도쿄에서는 일본어로, 서울에서는 한국어로 진행될 수 있으며, 대상 세그먼트와 CRM 필드, 적합한 잠재 고객을 정의하는 기준도 다르다. Tanaka는 이러한 차이에 맞춰 기성 플랫폼을 조정하려면 맞춤화 및 컨설팅 예산이 필요하고 공급업체의 로드맵을 기다려야 할 수 있지만, 내부 구축을 활용하면 풀 리퀘스트와 검토를 통해 워크플로를 변경할 수 있다고 말한다.
이는 기성 마케팅 플랫폼을 없애기 위한 처방도 아니며, 모든 팀에 자동화가 적합하다는 증거도 아니다. 제시된 사례의 실질적인 가치는 먼저 업무를 문서화한 다음, 인간의 유연성이 필요한 의사 결정과 자동으로 실행할 수 있는 반복 단계를 분리하는 데 있다. 또한 이 모델의 성공은 연결 가능한 외부 도구와 정확한 운영 가이드에 달려 있다. 규칙이 불완전하거나 업데이트 없이 변경되면 오류가 사라지는 대신 자동화된 워크플로로 옮겨갈 수 있다.