AI로 웹사이트 만들기, 행사 신청 페이지 다음에는 무엇을 자동화할까요?

핵심 요약 (TL;DR)

AI로 웹사이트 만들기를 시작하면 첫 화면에 시선이 쏠립니다. 하지만 행사 페이지는 신청을 받고, 명단을 정리하고, 끝난 뒤 후속 업무로 이어질 때 비로소 일을 덜어 줍니다. GitHub의 일본·한국 마케팅 담당자 Tomoko Tanaka는 9월 11일, 업무 절차를 Copilot에 설명해 행사 운영 자동화를 만든 경험을 공개했습니다.[1] 화면을 만드는 속도보다 참고할 만한 것은, 사람의 결정과 반복 실행을 분리한 방식입니다.

행사 페이지 다음에는 무엇을 연결해야 할까요?

Tanaka의 사례에서는 행사마다 GitHub Issue 하나를 두고 제목·날짜·지역·대상을 구조화합니다. 정해진 라벨이 붙으면 Actions가 기존 행사 페이지를 복제하고, 홍보 채널별 링크와 초대 메일 문서를 준비하며, 결과를 같은 Issue에 남깁니다.[1] 공개 웹사이트를 처음부터 생성한 사례가 아니라, 기존 행사 플랫폼을 연결한 운영 자동화라는 점은 구분해야 합니다.

이 구조를 작은 사업에 옮긴다면 ‘페이지를 예쁘게 만들어 주세요’보다 ‘신청이 들어온 다음 내가 반복하는 일’을 먼저 적어 보세요. 누가 확인하는지, 어떤 정보가 꼭 필요한지, 취소하면 어디를 고쳐야 하는지를 연결하면 화면에 필요한 항목도 선명해집니다. 신청 완료 문구만 있는 페이지와 실제 접수가 확인되는 서비스는 서로 다릅니다.

첫 프롬프트에는 무엇을 적으면 좋을까요?

다음은 사례에서 착안한 설계용 예시이며, 여기서 직접 배포한 실습 결과는 아닙니다.

작은 강의의 신청 페이지를 설계해 주세요. 행사명·일시·정원·신청 상태를 구분하고, 신청 정보는 담당자만 보게 해 주세요. 먼저 화면과 데이터 흐름을 제안하세요. 테스트 데이터로 접수·취소·중복 신청을 확인하고, 외부 메일 발송은 승인 전까지 실행하지 마세요. 완료 보고에는 접수 확인 방법과 미검증 항목을 남겨 주세요.

처음에는 신청 한 건이 담당자 확인 목록에 도착하는 흐름만 완성하세요. 다음 기능은 반복 업무를 관찰한 뒤 붙이면 됩니다.

자동화에 왜 리허설 스위치가 필요할까요?

원문에서 특히 눈에 들어오는 장치는 DRY_RUN입니다. 이 설정을 켜면 외부 시스템을 바꾸지 않고 절차를 연습하며, 행사명·메일 제목·날짜는 실행 전에 담당자가 승인합니다.[1] 잘못된 초대장이 발송된 뒤 사과하는 것보다, 실행될 내용을 미리 보는 편이 훨씬 가볍습니다.

그렇다고 예약 실행만 걸어 두면 끝나는 것은 아닙니다. 저자는 아침 명단 정리 작업이 닷새 동안 조용히 실패한 경험도 적었습니다.[1] 이 수치는 제작자의 운영 보고이지 독립적인 장애 조사 결과는 아닙니다. 실무에서는 성공 로그뿐 아니라 마지막 정상 실행 시점과 실패 알림 경로를 함께 마련하세요. ‘신청자가 없음’과 ‘조회에 실패함’이 같은 빈 목록으로 보이지 않게 만드는 것이 중요합니다.

FAQ: 코딩 경험이 없어도 그대로 따라 할 수 있나요?

저자는 과거 엔지니어로 일한 경험이 있다고 밝힙니다.[1] 완전 초보자의 재현 사례로 읽지는 마세요. 본인 업무에서는 입력 항목과 승인자를 정리하고, 샘플 데이터로 한 단계씩 확인하는 것부터 시작하면 됩니다.

FAQ: 홈페이지와 자동화를 동시에 만들어야 하나요?

그럴 필요는 없습니다. 기존 신청 폼을 그대로 두고 명단 정리만 연결해도 됩니다. 페이지 교체 자체보다 접수 누락을 줄이는 일이 우선입니다.

FAQ: 완성 화면과 배포 주소도 확인됐나요?

이 글은 공식 운영 사례를 해설한 글입니다. 해당 내부 시스템을 직접 실행하거나 별도 공개 데모를 배포하지 않았습니다. 독자 환경에서는 테스트 접수와 담당자 확인까지 끝내야 완료로 볼 수 있습니다.

관찰 시점: 2026-09-13 KST

Sources

[1] https://github.blog/ai-and-ml/github-copilot/marketing-ops-as-code-automating-events-from-planning-to-follow-up-on-github