해커톤 소개 웹사이트를 나 혼자 만들어야 한다고? (젝커톤 비하인드 #1)

젝트는 오는 2026년 11월 14일(토), 공식 해커톤 행사인 젝커톤 2026을 엽니다. 이번 젝커톤은 스위프(SWYP)와 공동으로 주최하며, AI 에이전트를 활용해 개발하는 바이브톤 형식으로 진행해요. 예상 참가자는 70명 안팎입니다.

이 시리즈는 그 행사를 소개하는 젝커톤 웹사이트를 만들며 겪은 일을 정리한 비하인드 이야기입니다. 1편에서는 웹사이트를 만들기 전에 무엇을 결정했는지, 특히 무엇을 직접 책임지고 무엇을 덜어냈는지 정리해 보려고 해요.

그래서 웹사이트는 누가 만들 건데#

행사 준비 회의에서 저는 젝커톤 전용 웹사이트를 따로 만들자고 제안했어요. 참가자를 모으려면 행사를 널리 알려야 하고, 신청 전에 궁금해할 정보를 충분히 전달해야 하고, 무엇보다 믿을 수 있는 행사라는 인상을 줘야 한다고 생각했거든요. 이 세 가지를 한곳에서 해결할 접점이 필요했습니다.

제안 자체에는 모두 공감했지만, 곧바로 현실적인 질문이 이어졌어요. 그래서 웹사이트는 누가 만들고, 그 공수는 누가 감당하느냐는 질문이었습니다. 행사 기획과 실행은 서포터즈가 전담하는데, 서포터즈에는 프론트엔드 개발 담당자가 없었어요. 개발을 부탁할 만한 다른 구성원들도 각자의 일로 바빴습니다. 웹사이트가 필요하다는 데에는 모두 동의했지만, 정작 만들 사람이 마땅치 않았던 거예요.

Notion 대신 자체 사이트#

그래서 회의에서 먼저 나온 대안은 Notion이었습니다. 해커톤 정보를 Notion 페이지 하나에 모은 뒤 웹에 게시해서, 그 페이지를 공식 웹사이트로 사용하자는 의견이었어요.

충분히 납득할 만한 제안이었습니다. 당장 공개할 수 있을 만큼 빠르고, 운영진 누구나 내용을 수정할 수 있으니 관리와 유지보수도 쉬워요. 개발자가 없는 팀이 짧은 시간 안에 행사 페이지를 열어야 한다면, 대부분의 경우 이 방법이 가장 합리적일 거예요.

하지만 저는 젝커톤이 이번 한 번으로 끝나지 않기를 바랐습니다. 젝트 구성원은 물론 더 많은 개발자와 디자이너에게 의미 있는 행사로 계속 이어지길 바랐어요. 그렇게 보니 Notion 웹 게시에는 아쉬운 점이 몇 가지 있었습니다. 검색 엔진 최적화(SEO) 설정에 한계가 있어서, 해커톤을 찾는 사람들이 젝커톤을 발견하기 어려울 수 있었어요. 광고나 공유 링크로 처음 들어온 사람에게는 첫 화면이 표시되기까지의 로딩 속도가 곧 첫인상인데, 그 성능을 제가 최적화할 방법도 없었습니다. JDS(젝트 디자인 시스템)와 젝트 브랜드 가이드라인을 얼마나 지킬 수 있을지도 불확실했고요.

그래서 젝커톤을 하나의 브랜드로 키워 가려면 자체 웹사이트가 꼭 필요하다고 구두로 설명했어요. 지금 돌아보면 이 판단에는 제 바람이 꽤 많이 섞여 있었습니다. 젝커톤이 정말 계속 이어질지, 브랜드로 성장할 만한 행사인지는 그 회의에서 증명된 것이 아니었으니까요. 그래도 젝트라는 공동체의 다음을 함께 그려 보고 싶었습니다.

공수에 대한 걱정에는 제가 맡겠다고 답했어요. 빠르게 완성할 테니 걱정하지 않으셔도 된다고요. 제목만 보면 혼자 떠안게 된 이야기처럼 보이지만, 사실 저는 웹사이트를 제안할 때부터 직접 맡을 생각이었습니다. 해낼 수 있다는 자신도 있었어요. 그렇게 행사 정책과 운영 계획을 제외한 웹사이트의 기획, 디자인, 개발, 배포, 운영을 디자이너인 제가 담당하게 됐습니다.

자신감의 근거는 AI와 함께한 경험이었습니다. 저는 요즘 JDS 컴포넌트 작업의 상당 부분을 AI와 함께 진행하고 있어요. 그 과정에서 무엇을 왜 만드는지 분명하게 설명할 수만 있다면, 직접 손으로 하던 작업의 많은 부분을 AI에게 맡길 수 있다는 감각이 생겼습니다. 이 경험은 지난 글 컴포넌트 디자인을 AX로 바꾼 이유에서 자세히 소개했어요.

이번에는 그 범위를 웹사이트 전체로 넓혀 보기로 했습니다. Figma로 화면의 방향을 잡고, Claude Code로 코드를 작성하고, Vercel로 배포하는 흐름이라면 기획부터 공개까지 혼자서도 이어 갈 수 있겠다는 계산이 섰어요. AI와 어떻게 협업했는지는 2편에서 자세히 다룰 예정입니다.

사이트의 세 가지 역할#

맡겠다고 말한 뒤 가장 먼저 마주한 조건은 시간이었습니다. 젝트와 스위프 내부 구성원을 대상으로 한 우선 모집이 10월 12일에 시작될 예정이라, 그 전까지 사이트가 공개되어 있어야 했어요. 10월 3일에 작업을 시작해 12일이 되기 전에 최종 배포를 마쳤으니, 실제 작업 기간은 7일 정도였습니다.

시간이 짧은 만큼, 이 사이트의 역할부터 좁혀야 했습니다. 하고 싶은 것을 모두 담으려 하면 7일은 금방 지나가 버리니까요. 처음 웹사이트를 제안했던 이유로 돌아가 보면, 이 사이트의 역할은 세 가지로 정리됩니다.

1. 알리기: 젝커톤이 어떤 행사인지, 언제 어디서 열리는지 한눈에 전달합니다.
2. 믿게 하기: 젝트의 공식 행사이고 스위프와 공동으로 주최한다는 점, 참가 규정과 개인정보 안내가 갖춰져 있다는 점을 보여 줍니다.
3. 신청하게 하기: 망설이는 사람의 질문에 미리 답하고, 신청 버튼까지 자연스럽게 안내합니다.

역할이 정해지자 화면에 들어갈 내용도 정리됐어요. 사이트는 소개, 일정, 주제, 참가 안내, FAQ 순서로 이어지고, 마지막에는 신청 마감까지 남은 시간을 보여 주는 카운트다운과 신청 버튼이 있습니다. 처음 방문한 사람이 '이게 무슨 행사지?'에서 시작해 '언제 하지?', '무엇을 만들지?', '나도 참가할 수 있을까?'를 거쳐 '한번 신청해 볼까?'에 이르도록, 방문자가 궁금해할 순서대로 정보 구조를 설계했어요.

작은 문구 하나도 같은 기준으로 넣었습니다. 이번 주제가 스포츠라서, 스포츠를 잘 모르는데 참가해도 될지 망설이는 사람이 있을 것 같았어요. 그래서 주제 영역에 "스포츠 팬이 아니신가요?"라는 질문을 두고, 올림픽을 보며 짜릿했던 순간이나 좋아하는 e스포츠, 개인적으로 즐기는 운동과 연결해 도전해 보라는 답을 덧붙였습니다. '신청하게 하기'를 위한 장치예요.

반대로 이 세 가지 중 어디에도 해당하지 않는 것은 과감하게 덜어내기로 했습니다.

만들지 않기로 한 기능#

젝커톤 웹사이트에는 없는 기능이 꽤 많습니다. 자체 신청 데이터베이스도, 로그인이나 회원 정보도 없어요. 신청 내역을 관리하는 관리자 화면도, 참가비를 받는 결제 기능도 없습니다. 사이트는 행사 정보를 전달하고 신청 창구로 연결하는 데까지만 맡아요.

그중 가장 고민이 컸던 것은 신청 기능이었습니다. 참가 신청은 '신청하게 하기'의 핵심이니까요. 고민 끝에 신청서는 직접 개발하지 않고, Notion form을 사이트 안에 임베드하기로 했습니다.

자체 신청 기능을 만드는 것 자체는 어렵지 않았을 거예요. AI와 함께라면 입력 화면과 저장 기능 정도는 7일 안에도 충분히 만들었을 겁니다. 문제는 그다음이었어요. 참가자의 이름과 연락처 같은 개인정보를 제가 만든 데이터베이스에 직접 저장한다면, 그 정보를 보호할 책임도 제가 져야 합니다. 데이터베이스 해킹이나 SQL 인젝션, 미처 파악하지 못한 취약점으로 사고가 발생하면 개인정보 보호법상의 책임까지 따라오고요.

게다가 저는 보안에 대한 기술적 지식이 깊지 않습니다. 이 사실을 인정하고 나니 오히려 선택이 쉬워졌어요. AI가 코드를 빠르게 작성해 줄 수는 있어도, 그 코드가 안전한지 끝까지 검증하고 책임지는 일은 여전히 사람의 몫입니다. 제가 책임질 수 없는 영역이라면, 보안 인프라가 이미 잘 갖춰진 서비스에 맡기는 편이 참가자에게도 더 안전하다고 봤습니다.

관리 측면의 이유도 있었습니다. 젝커톤 2026은 스위프와 공동으로 주최하기 때문에, 행사 운영 계획부터 참가 신청자 목록까지 대부분의 정보를 두 주최측이 함께 공유해요. 이미 Notion으로 협업 페이지를 운영하는 상황에서 신청서만 다른 Form 서비스로 받으면 정보의 맥락이 여러 곳으로 분산되고, 그 서비스의 계정과 공유 설정까지 따로 관리해야 합니다. 신청 내역이 협업 공간에 바로 쌓이는 Notion form이 가장 자연스러운 선택이었어요.

행사 기획은 운영팀의 몫#

신청 기능을 Notion에 맡긴 것처럼, 사이트에 담긴 내용도 제가 혼자 정한 것이 아닙니다. 행사 운영 계획과 정책에 관한 정보는 서포터즈 운영팀이 작성했고, 저는 그 정보를 받아 사이트에 옮기는 역할을 맡았어요. 참가 대상, 팀 매칭 방식, 참가비와 상금, 참가 규정 같은 내용은 모두 운영팀이 고민해서 결정한 것들입니다.

사실 7일 중 가장 막막했던 순간도 여기서 찾아왔어요. 화면은 더미 데이터로 먼저 만들어 두고, 실제 정보를 모아 채워 넣으려던 때였습니다. 행사 기획이 한창 진행 중인 시기여서, 일정과 타임테이블, 참가 문의를 받을 채널 같은 내용은 아직 논의되고 있었어요. 사이트 공개 일정이 기획보다 한발 앞서 달리고 있었던 거예요. 논의가 이어지는 동안 정보가 여러 문서에 나뉘어 정리되다 보니, 어느 문서를 기준으로 삼아야 할지 헷갈릴 때도 있었습니다.

그럴 때마다 운영팀과 함께 기준이 될 정보를 하나씩 맞춰 갔고, 12일 공개 전까지 사이트에 기재된 내용을 여러 번 수정했습니다. 바쁜 와중에도 운영팀이 더블체크와 검수에 많은 시간을 들여 주신 덕분에 공개 일정을 지킬 수 있었어요. 이 과정에서 '알리기'는 화면보다 정보를 하나의 기준으로 모으는 일에서 시작된다는 것을 배웠습니다. 다음에는 화면을 만들기 전에 기준이 될 문서부터 함께 정해 두려고 해요.

공개 이후의 반응#

그렇게 정보를 하나씩 맞춰 가며, 사이트는 10월 12일 내부 우선 모집에 맞춰 공개됐습니다. 16일까지 젝트와 스위프 구성원의 신청을 먼저 받았고, 10월 20일부터는 외부 광고를 시작했어요.

광고를 시작한 뒤 이틀 동안 759명이 사이트를 방문했고, 페이지 조회 수는 982회였습니다. 20일 오후부터 방문자가 빠르게 늘어 저녁 7시 무렵에는 한 시간에 76명이 방문하기도 했어요. 다음 날에도 시간당 20~30명 안팎의 방문이 꾸준히 이어지고 있습니다.

사실 광고 첫날 저녁에는 이 숫자를 실시간으로 지켜보지 못했어요. 그 시간에 개인적으로 맡은 외주 업무를 하고 있었거든요. 밤이 되어서야 Vercel Analytics를 열어 봤는데, 생각보다 훨씬 많은 방문자에 놀랐고 솔직히 재미있었습니다.

숫자보다 반가웠던 건 신청서에 남겨진 답변이었어요. 앞서 소개한 "스포츠 팬이 아니신가요?" 문구 기억나시나요? 평소 스포츠를 즐기거나 자주 보지는 않지만 한번 도전해 보고 싶다고 답한 분이 여럿 있었습니다. 주제는 미리 정해져 있었지만, 그 주제가 진입장벽이 되지 않고 되도록 많은 사람과 함께하는 해커톤이 되길 바랐거든요. 작은 문구 하나가 그 바람에 조금은 보탬이 된 것 같아요.

Notion 대신 자체 사이트를 고른 이유가 실제로 통하는지도 확인해 봤습니다. Google에서 '젝커톤'을 직접 검색해 본 데 이어, 좀 더 객관적으로 확인하려고 메타 태그를 넣고 Google Search Console에서 검색 노출 여부를 살폈어요. 다행히 검색 결과 첫 번째로 정상 노출되고 있었습니다. 로딩 속도와 모바일 사용성도 직접 살펴봤는데, 그러던 중 메이커스 팀원분께 "모바일에서 경험이 이상하다"는 짧은 피드백을 받았습니다. 직접 테스트해 보니, "참가 신청하기" 버튼을 눌러 신청 영역으로 이동해도 Notion form이 늦게 나타나는 문제가 있었어요. 신청하려는 바로 그 순간에 폼이 비어 있었던 거죠. 그래서 사용자가 신청 영역에 닿기 전에 폼을 미리 불러오도록 고쳐, 이동하자마자 폼이 보이게 했습니다.

아직 신청을 받는 중이라 정확한 수치를 공개하기는 어렵지만, 지금 추이라면 처음 예상보다 더 많은 분과 함께하게 될 것 같아요. 관심을 가져 주신 모든 분께 감사드립니다.

판단의 트레이드오프#

여기까지 작성하고 보니, 제가 내린 판단이 모두 잘 맞아떨어진 것처럼 읽힐까 봐 조심스러워요. 모든 판단에는 트레이드오프가 있었습니다.

가장 크게 느끼는 트레이드오프는 유지보수 부담이 저 한 사람에게 몰려 있다는 점이에요. 저는 젝커톤이 계속 이어지는 행사가 되길 바라며 Notion 웹 게시 대신 자체 사이트를 선택했습니다. 그런데 정작 지금 이 사이트를 수정할 수 있는 사람은 저 한 명뿐이에요. Notion 페이지였다면 운영진 누구나 문구 하나쯤은 바로 고칠 수 있었겠지만, 지금은 작은 수정도 모두 저를 거쳐야 합니다. 지속성을 위해 내린 결정이 오히려 저를 이 사이트의 단일 장애 지점(SPOF, Single Point of Failure)으로 만든 셈이죠.

속도를 얻은 대신 검증의 기회를 잃은 것도 트레이드오프였습니다. 작업하는 동안 프리뷰 링크를 여러 번 공유하며 미리 확인할 수 있다고 안내했지만, 별도의 피드백이나 정정 요청은 없었어요. 웹사이트에 대한 검토와 승인은 사실상 저 혼자 했어요. 개발로 치면 리뷰어 없이 혼자 승인하고 머지한 것과 비슷했습니다. 처음에는 의견을 조율할 필요 없이 빠르게 결정하고 곧바로 반영할 수 있어 오히려 편했습니다. 그런데 공개일이 가까워질수록, 아무도 고치라고 하지 않았다는 것이 제가 틀려도 아무도 모를 수 있다는 뜻으로 다가왔습니다. 공개 뒤 짧은 피드백 한마디가 모바일 문제를 찾아 준 걸 보면, 공개 전에 그런 눈이 몇 번만 더 있었어도 좋았겠다는 생각이 들어요.

Notion form 역시 트레이드오프가 분명했습니다. 보안 책임과 정보 분산의 부담은 덜었지만, 그 대신 신청 화면의 디자인과 동작에 대한 통제권을 Notion에 넘겨야 했어요. 모바일에서 폼이 늦게 나타났던 문제도 외부 폼을 임베드했기 때문에 생긴 일이었습니다. 방문에서 신청으로 이어지는 전환율도 사이트에서 바로 측정할 수 없고요.

이 트레이드오프를 미리 알았더라도 같은 선택을 했을지 묻는다면, 아마 그랬을 것 같아요. 다만 당시에는 얻는 것에 더 집중했고, 그 선택의 기회비용은 이제야 또렷하게 보인다는 점을 솔직하게 남겨 두고 싶습니다.

오너십의 다음 방향#

단일 장애 지점의 위험이 가장 크게 드러날 때는 아마 행사 직전일 거예요. 신청 마감과 참가자 발표, 행사 당일까지 사이트의 정보는 여러 번 바뀔 텐데, 광고 첫날 저녁처럼 제가 다른 일에 묶여 있거나 아프기라도 하면 그 변화를 반영할 사람이 없습니다. 운영팀이 바뀐 일정을 공지했는데 사이트에는 이전 정보가 남아 있다면, '알리기'와 '믿게 하기'가 한꺼번에 무너져요.

웹사이트를 맡겠다고 말할 때 제가 가졌던 오너십은 '제가 다 만들고 책임질게요'에 가까웠습니다. 하지만 이제는 오너십이 조금 다른 방향으로 성장해야 한다고 느껴요. 제가 없어도 다른 사람이 이어받을 수 있게 만드는 것까지가 제 몫이라고 생각합니다.

• 수정 방법 남기기: 사이트의 어느 파일에 어떤 정보가 있는지, 문구 하나를 수정하려면 어떻게 해야 하는지 운영진이 따라 할 수 있도록 문서로 정리하려고 해요.
• 피드백을 기다리지 않고 요청하기: '프리뷰를 확인해 주세요'가 아니라 '참가비 안내 문구가 운영 문서와 일치하는지 확인해 주세요'처럼, 무엇을 확인해 주면 좋을지 구체적으로 요청하는 습관을 들이려고 합니다.
• 다음 젝커톤을 위한 인수인계: 젝커톤이 정말 이어진다면, 다음 웹사이트는 다른 누군가가 맡을 수도 있어요. 이번에 내린 판단과 그 이유, 그리고 그 트레이드오프를 기록으로 남기는 일도 그 준비라고 생각합니다. 어쩌면 이 시리즈도 그 기록의 일부일 거예요.

처음 회의에서 들었던 질문으로 돌아가 보면, 해커톤 소개 웹사이트를 혼자 만든다는 것은 모든 일을 혼자 해낸다는 뜻이 아니었습니다. 신청 기능은 Notion에, 행사 정보는 운영팀에 맡기고, 7일이라는 시간 안에서 제가 끝까지 책임질 수 있는 범위를 고르는 일에 더 가까웠어요. 그리고 이제는 그 범위에 '제가 없어도 이어지게 하는 일'까지 넣어야 한다는 것을 배우는 중입니다.

다음 편 예고#

2편에서는 디자이너 혼자 7일 동안 디자인부터 배포까지 어떻게 이어 갔는지 다룹니다. Figma와 Claude Code, Vercel을 오가며 AI와 어떻게 협업했는지, 짧은 일정 안에서 디자인은 어떤 기준으로 결정했는지 이야기해 볼게요. 3편에서는 행사 당일의 모습과 함께, 이 판단들이 정말 옳았는지 시리즈 전체를 돌아보겠습니다.

젝커톤 2026 참가 신청은 10월 31일(토)까지 젝커톤 웹사이트에서 받고 있어요. AI와 함께 무언가를 만들어 보고 싶은 분이라면 직군과 관계없이 누구나 환영합니다.