학생 동아리는 매년 새로 태어나요. 그리고 매년, 지난해의 기억이 이어지거나 보존되지 않아요
사람이 졸업하면 그가 알던 것도 함께 떠납니다. 왜 그 프로젝트를 그렇게 만들었는지, 무엇을 시도했다 실패했는지, 어떤 기업과 어떻게 협업했는지 — 대부분 몇몇 사람의 머릿속과 흩어진 대화에만 남아요. 그래서 다음 기수는 물려받을 게 있는데도 자꾸 0에서 다시 시작합니다. 우리는 이걸 동아리라면 으레 겪는 일이 아니라, 고쳐볼 수 있는 구조의 문제로 봤어요.
증상은 사소한 질문에서 먼저 드러났어요. 누군가 “그래서 경희대 멋사는 어떤 동아리예요?”라고 물으면, 링크 하나로 답할 방법이 없었거든요. 인스타그램은 있었지만 게시물은 시간순으로 흘러가 버렸고, 무슨 활동을 하는지, 누가 함께하는지, 실제로 뭘 만들었는지 알려면 노션과 인스타그램, 각자의 기억을 한참 뒤져야 했습니다. 조직의 기억이 한곳에 쌓이지 않는다는 문제가, 밖에서 보면 “설명할 링크가 없다”로 나타난 셈이에요.
그래서 목표는 홈페이지 하나를 더 만드는 일이 아니었어요. 처음 온 사람이 경희대 멋사를 한 번에 이해하고, 사람이 바뀌어도 활동과 판단과 배움이 계속 쌓이는 공식 거점 — 사람이 떠나도 조직의 기억은 남는 구조를 만드는 일이었습니다. 홈페이지는 그 구조가 밖에서 보이는 얼굴일 뿐이었고요.
한 가지 전제가 처음부터 깔려 있었어요. 공식 홈페이지는 공개한 다음 날부터 낡기 시작한다는 것. 멤버와 프로젝트, 모집은 계속 바뀌니까, 한 번 잘 만드는 것보다 스스로 갱신되며 낡지 않는 것이 훨씬 어려운 진짜 과제였습니다. 그렇게 두 명의 디자이너, 다섯 명의 개발자와 함께 경희대 멋사의 첫 공식 홈페이지를 만들기 시작했어요.
그렇다고 인스타그램을 접을 이유는 없었어요. 둘은 잘하는 일이 서로 달랐거든요.
인스타그램은 순간에 강해요. 해커톤의 열기, 개강총회의 분위기, 모집이 시작됐다는 소식을 빠르게 실어 나르죠. 그러니 홈페이지가 맡을 자리는 그 반대편이었어요. 흘러가는 소식이 아니라, 한자리에 머무는 맥락이요.
그래서 홈페이지에서는 경희대 멋사가 어떤 곳인지, 무엇을 배우는지, 누가 함께하는지, 실제로 어떤 결과물을 만들어 왔는지가 한 흐름으로 보여야 했어요. 방문자가 “내가 이 동아리에서 무엇을 얻을 수 있을까?”를 어렵지 않게 짐작할 수 있도록요.
첫 화면은 코딩을 배우고 싶지만 어디서 시작해야 할지 막막한 경희대생을 기준으로 잡았습니다. 5초 안에 이런 인상을 주고 싶었어요.
이곳은 친목에만 머무는 동아리가 아니라, 열정 있는 사람들이 함께 배우고 실제로 무언가를 만드는 곳이다.
정리하면 홈페이지는 인스타그램을 대신하는 채널이 아니라, 이어받는 자리였어요. 인스타그램에서 우리를 발견한 사람이 더 깊이 알고 싶을 때 돌아오는 곳, 다른 동아리나 협업을 고민하는 기업에 망설임 없이 건넬 수 있는 곳이면 충분했어요. 여러 채널에 흩어진 정보가 돌아와 쌓이는 기준점에 가까웠습니다.
처음 방문한 사람이 경희대 멋사의 정체성, 활동, 사람과 분위기를 부족함 없이 이해할 수 있어야 한다.
그리고 관심이 생긴 사람에게는 구경으로 끝나지 않고 모집 알림이나 실제 지원으로 이어지는 길이 필요했어요.
이 문장을 기준으로 v1에 담을 내용을 여섯 가지로 추렸어요.
각 항목을 따로 세워두지는 않았어요. 소개와 활동으로 동아리의 방향을 보여준 뒤 프로젝트와 멤버로 구체적인 사람과 결과물을 보여주고, 블로그와 모집으로 이어지게 했습니다. 더 궁금한 사람은 과정을 읽고, 마음이 움직였다면 모집 알림을 신청하거나 지원서를 낼 수 있어요.
공개 화면만 잘 만드는 것으로는 부족했습니다. 멤버가 자신의 프로필과 글, 프로젝트를 직접 관리하고, 운영진은 멤버·모집 상태·공개 콘텐츠를 관리하게 했어요. 정보 하나를 바꿀 때마다 특정 개발자를 찾아야 한다면 홈페이지는 금세 과거에 머물 테니까요.
물론 넣지 않은 것도 많아요. 작은 조직에 비해 복잡한 승인 절차, 아직 필요성이 확인되지 않은 검색과 신고 체계, 1년에 몇 번 하지 않는 일을 위한 무거운 자동화는 뒤로 미뤘습니다. 한 달 안에 외부에 내놓을 제품을 만들려면 기능 수보다 완성도를 먼저 챙겨야 했어요.
‘외부에 내놓을 수 있는 수준’은 기능이 한 번 동작하는 데서 끝나지 않았습니다. 공개 정보가 정확해야 했고, 모바일과 데스크톱에서 무리 없이 읽혀야 했어요. 콘텐츠를 계속 고칠 수 있어야 하고, 문제가 생기면 발견하고 되돌릴 방법도 필요했습니다.
링크 하나를 그대로 외부에 보내도 되는 상태.
이 한 문장을 v1의 완료 기준으로 삼았어요.
두 명의 디자이너는 정보 구조(IA)와 와이어프레임부터 시작했어요. 첫 과제는 어떤 정보를 어떤 순서로 보여줄지였습니다.
소개, 세션, 활동, 프로젝트, 사람, 블로그, 모집은 모두 필요했어요. 그렇다고 같은 크기로 늘어놓으면 무엇부터 봐야 할지 알기 어렵죠. 어떤 정보가 첫인상을 만들지, 사람은 어디에서 보여줄지, 프로젝트와 활동은 언제 등장할지를 화면 위에서 계속 바꿔봤어요.
시각 시안에서는 ‘공식적이되 딱딱하지 않게’라는 숙제가 남았습니다. 학생 동아리의 활기는 보여주고 싶었지만 가볍게만 보여서도 안 됐고요.
색상과 컴포넌트를 고르는 일보다 먼저, 경희대 멋사가 밖에서 어떤 인상으로 기억되길 바라는지를 화면으로 답해야 했어요.
덕분에 프론트엔드도 문장으로 된 요구사항을 각자 해석하는 대신, 같은 화면과 사용자 흐름을 보며 구현을 시작할 수 있었습니다. 이 프로젝트에서 디자인은 개발 뒤에 붙는 마감 작업이 아니라, 제품을 가장 먼저 구체화하는 일이었어요.
그리고 여기서 처음의 문제와 다시 만납니다. 공식 홈페이지는 공개한 다음 날부터 낡으니까요. 멤버와 운영진이 바뀌고 새 프로젝트와 글이 생기며, 모집은 열렸다가 닫혀요. 이런 변화마다 개발자를 찾아야 한다면 사이트는 실제 동아리를 따라가지 못합니다.
그래서 운영진이 직접 사이트를 움직일 수 있는 어드민을 함께 만들었습니다. 모든 문장을 고칠 수 있는 범용 관리 도구는 아니에요. 멤버·운영진·모집처럼 자주 바뀌고 그때마다 판단이 필요한 정보만 어드민에 넣었어요. 연간 활동 계획처럼 1년에 한 번 바뀌는 단순한 정보는 코드에 두는 편이 오히려 관리하기 쉬웠고요.
왼쪽 메뉴를 보면 멤버와 관리자 계정, 모집, 콘텐츠, 보안, 인프라까지 업무가 나뉘어 있어요. 아래 세 화면은 어드민 전체가 아니라, 그중 운영진이 상태를 보고 판단하는 장면을 골라온 것입니다.
처음 만든 어드민 홈은 메뉴마다 큰 카드를 둔 바로가기 화면이었어요. 막상 써보니 왼쪽 사이드바와 같은 링크가 반복될 뿐이고, 정작 운영진이 먼저 봐야 할 사이트 상태는 다른 메뉴에 숨어 있었습니다. 그래서 홈을 통째로 사이트 이용 현황으로 바꿨어요.
여기서는 조회수와 추정 순 방문자, 긴 랜딩에서 방문자가 어디까지 내려왔는지, 지원·모집 알림·콘텐츠 탐색 버튼을 얼마나 눌렀는지를 볼 수 있어요. 어떤 프로젝트와 블로그 글이 많이 읽혔는지도 비교합니다. 모집 알림은 버튼 클릭이 아니라 실제로 새로 저장된 신청만 세고, 모집이 시작되면 접수된 지원서 수도 같은 화면에 올라와요.
어드민 전체 중 ‘이용 현황’의 첫 화면. 왼쪽 메뉴처럼 멤버·모집·콘텐츠·보안·인프라 운영은 각각의 화면으로 이어져요.
지표는 많을수록 좋다고 생각하지 않았어요. 프로젝트를 더 앞에 보여줄지, 모집 안내를 언제 올릴지, 새 글을 공개한 뒤 방문 흐름이 달라졌는지 판단하는 데 쓸 숫자만 골랐습니다. 화면에는 수치의 한계도 함께 적었어요. 조회수와 순 방문자는 다르고, 버튼 클릭이 실제 신청을 뜻하지도 않아요. 공개 전후의 변화만 보고 특정 콘텐츠의 효과라고 단정할 수도 없고요.
‘이용 현황’ 안의 방문 시간대 분석. 게시와 모집 안내를 사람들이 실제로 사이트를 보는 때에 맞추기 위한 여러 판단 도구 중 하나예요.
콘텐츠에는 게시 전 승인 단계를 두지 않았어요. 멤버가 쓴 글과 프로젝트는 바로 공개되고, 문제가 생기면 운영진이 블로그 글이나 댓글을 숨깁니다. 50명 남짓한 동아리에서 모든 글을 미리 검수하기 시작하면 쓰는 사람도 승인하는 사람도 금방 지칠 거라고 봤어요. 먼저 믿고 맡기되, 공식 홈페이지를 지킬 마지막 수단은 운영진에게 남겼습니다.
모집 준비도 어드민 안에서 끝나요. 기수와 세션에 맞춰 질문·필수 여부·선택지를 고치고, 지원자에게 보일 화면을 미리 확인합니다. 준비가 끝나면 모집 상태를 켜 공개 화면을 ‘모집 알림’에서 ‘지원하기’로 바꾸고, 알림 신청자에게 메일을 보내요. 제출 시점의 질문도 답변과 함께 저장했습니다. 다음 기수에 양식이 달라져도 예전 지원서를 엉뚱한 질문과 함께 읽는 일을 막기 위해서예요.
지원자 명단을 여는 일은 서버에 기록됩니다. 누가 언제 민감한 정보를 봤는지 남기되, 이름이나 전화번호 같은 값 자체를 로그에 한 번 더 복사하지는 않았어요. 로그인 실패, 계정 변경, 콘텐츠 숨김, 모집 시작과 종료도 같은 감사 로그에서 찾을 수 있고, 이 기록은 어드민에서 수정하거나 지울 수 없습니다.
계정에도 기수 교체를 반영했어요. 졸업하거나 탈퇴한 멤버는 로그인만 막고, 그 사람이 남긴 글과 프로젝트는 보존합니다. 새 운영진은 기존 관리자가 경희대학교 이메일로 초대하고, 실제 로그인을 확인한 뒤 이전 계정을 정리해요. 여덟 명 안팎의 조직에 최고관리자와 세부 등급까지 만들 필요는 없다고 봐서 모든 관리자가 같은 권한을 갖습니다. 대신 마지막 관리자 한 명은 삭제할 수 없어요. 실수 한 번으로 아무도 어드민에 못 들어가는 상황을 막는 최소한의 장치입니다.
인프라 상태도 같은 어드민에서 확인합니다. CPU·메모리·디스크의 현재 값과 6시간·24시간·7일 추이를 보여주고, 그래프에는 운영 임계치를 함께 그었어요. 장애 알람은 별도의 모니터링 시스템이 보내기 때문에 누군가 이 화면을 계속 켜둘 필요는 없습니다.
‘인프라’ 안의 시스템 메트릭 화면. 어드민에는 이 밖에도 애플리케이션과 데이터베이스의 정합성, 자동 복구 여부를 확인하는 배포 이력이 있어요.
배포 이력에서는 검증 환경과 실제 서비스에 어떤 버전이 올라갔는지, 애플리케이션과 데이터베이스 변경이 서로 맞는지, 실패 뒤 자동 복구가 됐는지를 SSH 접속 없이 확인할 수 있어요. 다만 재배포나 롤백 버튼은 넣지 않았습니다. 상태 확인은 쉽게, 위험한 조치는 운영 문서를 펼쳐놓고 신중하게 하자는 쪽을 택했어요.
공개 화면이 경희대 멋사의 얼굴이라면, 어드민은 그 얼굴을 계속 현재형으로 유지하는 공간이에요. 구성원이 직접 기록하고, 운영진이 문제를 바로잡고, 다음 기수가 관리 권한을 넘겨받는 일이 여기에서 이어집니다.
7월부터 8월까지 약 한 달, 모두가 학업과 개인 일정을 병행하며 만들었습니다. 프론트엔드·백엔드·인프라를 합치면 코드 49,030줄, 커밋 활동 1,623건, 완료 티켓 128개가 남았어요.
물론 이 숫자를 팀원의 생산성 점수로 볼 수는 없어요. 커밋 하나의 크기는 제각각이고, 디자인·기획·회의처럼 GitHub 밖에서 시작되는 일도 많습니다. 통합과 리뷰처럼 여러 사람의 결과에 나뉘어 남는 작업도 있고요.
그래서 이 수치는 순위표가 아니라 작업의 흔적으로 봤습니다. 작은 팀이 한 달 동안 문제를 얼마나 자주 나누고, 합치고, 다시 확인했는지 보여주는 정도로요.
그래도 이 흔적이 어떤 조건에서 남았는지는 짚어둘 만해요. 개발이 본업도 아닌 학부생 여덟 명이, 그것도 방학 한 달을 쪼개 만든 결과거든요. 그렇게 나온 게 데모가 아니라 어드민과 QA, 배포·백업까지 붙은, 링크를 그대로 외부에 보내도 되는 제품이었습니다. 5만 줄에 가까운 코드도 1,600건이 넘는 커밋도 그 과정에서 남은 흔적이지, 목표였던 건 아니고요.
이걸 회의로 하나하나 조율하며 만들려 했다면 한 달로는 어림없었을 거예요. 그래서 숫자보다 궁금한 건 그 한 달이 어떻게 굴러갔느냐인데, 그 이야기는 티켓에서 시작합니다.
방학이라 팀원마다 가능한 시간도, 머무는 지역도 달랐어요. 꼭 함께 판단해야 할 때는 대화했지만 정기 진행 회의나 상태 공유 회의는 두지 않았습니다.
대신 회의가 하던 일의 상당 부분을 티켓에 맡겼어요.
“랜딩 구현”, “API 만들기”만 적힌 티켓은 금방 한계를 드러냈어요. 담당자가 작성자를 다시 찾아가 배경부터 물어봐야 했고, 며칠 지나면 왜 시작한 일인지도 흐려졌습니다.
그 뒤로는 티켓 하나만 열어도 다음 질문에 답할 수 있게 적었어요.
일의 크기는 네 단계로 나눴습니다. Epic은 프로젝트 쇼케이스나 블로그 같은 큰 주제, Story는 “방문자가 프로젝트 목록을 볼 수 있다”처럼 사용자가 경험하는 기능 하나예요. 화면이나 API처럼 각 담당자가 실행할 일은 Story 아래 Sub-task로 두고, 특정 사용자 기능에 묶기 어려운 인프라 설정은 별도의 Task로 관리했어요.
이 구분은 PM보다 실제 티켓을 받은 개발자에게 더 유용했어요. 지금 쓰는 코드가 어느 사용자 경험으로 이어지는지 티켓 안에서 함께 볼 수 있었으니까요.
처음에는 GitHub 옆에 별도의 상태표도 두고 손으로 색을 칠했어요. 이슈가 새로 생기거나 담당자가 바뀔 때 두 곳을 함께 고치지 못했고, 얼마 지나지 않아 표와 실제 상황이 달라졌습니다. 업데이트를 더 열심히 하는 대신 상태표를 없앴어요.
하위 티켓이 닫히면 Story와 Epic 진행률이 GitHub에서 함께 올라가도록 계층을 연결했습니다. 누가 무엇을 맡았는지, 각 기능이 어디까지 왔는지를 같은 화면에서 보니 별도 보고도 필요하지 않았어요.
작업하다 발견한 내용은 이슈와 PR에 이어 적었습니다. 한 사람이 밤에 끝낸 작업을 다른 사람이 다음 날 확인해도, 왜 그렇게 됐는지는 티켓에서 따라갈 수 있었어요. 결과는 최소 한 명의 리뷰를 거쳐 dev에 합치고, 검증 환경에서 QA를 마친 뒤 main을 통해 공개했습니다.
회의를 없앤 것이 핵심은 아니었어요. 사람의 기억이나 실시간 대화에만 있던 맥락을 작업 옆에 남긴 것, 그게 서로 다른 시간에 일하면서도 프로젝트가 이어진 이유였습니다.
팀원 모두가 Claude Code를 썼어요. 그런데 그것만으론 팀의 개발 방식이 거의 바뀌지 않았습니다. 처음에는 코드를 대신 작성해 달라고 요청하는 정도였거든요.
새 대화를 열 때마다 프로젝트를 다시 설명했고, 대화 안에서 정한 이유는 세션이 끝나면 사라졌어요. 코드가 빨리 나와도 팀원이 이해하지 못하면 다음 작업에는 별 도움이 되지 않았고요.
그래서 AI도 사람과 같은 티켓에서 시작하게 했습니다. 역할별 CLAUDE.md에는 그 영역의 책임과 규칙을, 티켓에는 무엇을 왜 만드는지와 완료 기준을 적었어요.
자주 반복되는 흐름 두 개는 스킬로 묶었습니다.
작업은 조사(Research), 계획(Plan), 구현(Implementation), 검증(QA) 순서로 진행했어요. 구현하다 첫 전제가 틀렸음을 알게 되면 계획을 억지로 밀지 않고 다시 조사로 돌아갔습니다.
코드 양을 늘리는 것보다 사람과 AI가 같은 문제와 완료 기준을 보게 하는 편이 더 중요했어요. 무엇을 만들지, 어떤 단점을 감수할지, 결과를 승인해도 될지는 사람이 정했습니다. AI는 그 사이의 탐색과 초안, 구현과 1차 검토를 맡았고요.
이전 대화를 복원할 필요도 줄었어요. 팀원이 자리를 비워도 다음 세션은 티켓과 저장소에 남은 기록에서 다시 시작할 수 있었습니다.
pm/에 남긴 것
AI를 많이 쓸수록 기록 문제가 더 잘 보였어요. 대화가 끝나면 그 안의 이유도 사라졌고, 그렇다고 대화를 전부 저장하면 정작 필요한 내용을 찾기 어려웠습니다.
그래서 사람의 머릿속과 AI 대화에 흩어진 운영 정보를 의도 → 실행 → 검증 → 학습 순서로 정리했어요. 저장소의 pm/ 디렉터리가 그 결과입니다.
pm/
├── docs/
│ ├── brief.md # 왜 만들고, 누구를 위해, 어디까지 만들까
│ └── learnings.md # 다음 작업에도 재사용할 수 있는 배움
├── missions/<번호-이름>/
│ ├── proposal.md # 무엇을 왜 해야 하는가
│ ├── log.md # 조사·계획·구현 중 남은 맥락
│ └── result.md # 무엇이 달라졌고 무엇을 배웠는가
├── qa/
│ ├── criteria/ # 기대 동작: Given–When–Then
│ └── verification/ # 실제 결과: pass/fail + 관찰 근거
├── onboarding/ # 사람과 AI가 같은 방식으로 시작하는 입구
└── scripts/ + skills/ # 이슈·보드·미션 흐름을 움직이는 자동화
각 위치에는 자꾸 되풀이되던 질문 하나씩을 맡겼어요. brief는 “우리가 왜 이걸 만들고 있지?”, missions는 “이 일은 왜 시작했고 어떻게 끝났지?”, qa는 “직접 확인했나?”, learnings는 “다음에도 써먹을 배움인가?”에 답합니다.
문서는 많을수록 나빠져요. 같은 사실을 여러 곳에 베끼면 곧 서로 다른 말을 하기 시작하거든요. 상태표와 GitHub가 어긋난 뒤에는 정보마다 기준이 되는 위치를 하나씩만 정했어요.
제품이 무엇이어야 하는지는 위키, 진행 상황은 GitHub 이슈·PR·보드, 프론트엔드와 백엔드 사이의 약속은 shared/types의 코드에서 봅니다. pm/에는 이 내용을 다시 베끼지 않고, 일을 시작한 이유와 검증 결과, 다음에 쓸 배움만 연결했어요.
이슈 생성, 보드 설정, 미션 수령처럼 반복되는 일은 scripts와 skills로 실제 동작하게 만들었습니다. 기억에만 맡긴 규칙은 바쁜 순간부터 빠지기 시작한다는 걸 이미 여러 번 겪었거든요.
물론 처음부터 모든 맥락을 적을 수는 없었어요. 팀원은 이미 알아서 설명할 생각조차 못 한 정보도 있었고, 구현해 보기 전에는 아무도 몰랐던 제약도 있었습니다. 그런 사실을 뒤늦게 발견할 때마다 판단의 이유와 다음에 쓸 만한 배움을 저장소에 보탰어요.
Claude 모델 자체가 우리 팀을 새로 학습한 건 아니에요. 대신 다음 세션이 읽을 자료가 나아졌습니다. 같은 설명을 반복하는 시간은 줄었고, 첫 초안부터 우리 기준에 가까울 때가 늘었어요. 우리는 이를 ‘무수정 승인율’, 즉 사람이 큰 수정 없이 결과를 승인할 수 있는 비율로 봤습니다. 승인과 책임은 여전히 사람의 몫이고요.
바랐던 건 한 사람이 AI로 모든 직군을 대체하는 모습이 아니었어요. 사람이 바뀌어도 새 담당자가 과거의 판단을 빠르게 따라잡고, 필요한 전문가와 운영을 이어가는 상태에 가까웠습니다. 팀원의 교체가 프로젝트 기억의 소실로 이어지지 않도록요.
PR이 머지되면 “끝났다”고 말하기 쉬워요. 하지만 그 상태로 링크를 외부에 보내도 되는지는 별개의 문제였습니다.
기대 동작은 pm/qa/criteria에 Given–When–Then, 즉 어떤 상황에서 무엇을 하면 어떻게 되어야 하는지로 적었어요. 실제 결과는 pm/qa/verification의 33개 문서에 통과·실패·미실행으로 나눠 남겼습니다. 확인 방법과 날짜도 함께 적어 “될 것 같다”와 “직접 봤다”를 구분했고요.
프론트엔드에서는 단위·통합 테스트와 Playwright 브라우저 테스트를 돌렸습니다. 배포 뒤에는 서버 프로세스가 떠 있는지만 보지 않고 핵심 API를 직접 호출했어요. 모니터링과 알람, 데이터베이스 백업과 복구 경로도 한 번씩 실제로 움직여봤습니다.
기능 QA와 디자인 QA는 따로 봤어요. 모바일에서 텍스트가 깨지는지, 빠르게 스크롤할 때 현재 위치 표시가 어긋나는지, 비율이 제각각인 이미지가 들어와도 프로젝트 화면이 버티는지는 자동 테스트만으로 알기 어려웠습니다.
디자이너의 일도 시안을 전달한 순간 끝나지 않았어요. 실제 데이터가 들어간 브라우저 화면은 시안과 다르게 보이기 마련입니다. 디자이너와 개발자가 간격, 타이포그래피, 반응형 동작과 콘텐츠 밀도를 다시 보며 처음 잡은 정보 위계가 남아 있는지 확인했어요.
이때부터 포지션의 경계도 조금씩 옅어졌습니다. 프론트엔드와 백엔드는 shared/types의 실제 타입으로 약속을 맞췄고, 인프라는 마지막 배포만 맡지 않고 초기부터 비용과 복구 조건을 함께 설계했어요. 디자인 역시 정보 구조부터 실제 구현의 마지막 간격까지 이어서 봤고요. 전문 영역은 달라도 마지막에는 모두 같은 화면과 사용자 흐름을 확인했습니다.
이 프로젝트에는 PM 한 명, 디자이너 두 명, 프론트엔드 두 명, 백엔드 두 명, 인프라 한 명이 참여했어요.
@김우진 은 PM이자 제품 책임으로, 목표와 범위를 정하고 티켓·미션·QA·맥락이 실제 작업으로 이어지도록 운영 구조를 설계했어요.
@김영웅, @유한솔 은 디자인을 맡아 사용자 흐름을 정의하고, 시각 시안을 통해 경희대 멋사가 외부에 어떤 인상으로 보여야 하는지 구체화했어요.
@박일하 는 프론트엔드 기술 기반과 랜딩 전체, 블로그·모집 알림·지원 폼·관리 화면을 실제 사용할 수 있는 흐름으로 연결했어요.
@김현정 은 메인 랜딩과 블로그, 멤버·관리자 로그인처럼 사용자가 처음 만나는 진입 흐름을 구현하고 프론트엔드 테스트 기반을 만들었어요.
@신선우 는 Spring 기반을 세우고 블로그, 관리자 인증, 멤버·운영진 데이터 등 서비스의 핵심 도메인과 API 골격을 만들었어요.
@안시현 은 모집 알림, 블로그 관리, 멤버·프로젝트 API와 권한 체계를 구현해 공개 화면과 멤버 작업 화면에 필요한 데이터를 연결했어요.
@장찬욱 은 인프라와 백엔드를 오가며 CI/CD와 검증·운영 환경, 이미지 저장소, 이메일, 모니터링·백업·복구 등 서비스 운영 기반을 구축했어요.
처음의 목표는 “외부인이 경희대 멋사의 정체성, 활동, 사람과 분위기를 부족함 없이 이해할 수 있는 공식 홈페이지”였어요. v1을 마친 뒤 이 문장을 다시 꺼냈는데, 점검하려니 먼저 구분해야 할 게 있었습니다.
만든 것과 통한 것은 다릅니다. 화면을 붙이고 QA를 통과시킨 건 우리가 통제할 수 있는 산출물이에요. 하지만 방문자가 정말 5초 안에 동아리를 이해했는지, 그 관심이 지원으로 이어졌는지는 우리가 만든다고 되는 게 아니라 사용자가 만드는 성과입니다. 공개 전 v1 시점에서 정직하게 단언할 수 있는 건 대부분 앞쪽, 산출물까지예요. 그래서 목표를 이미 검증이 끝난 산출물과, 데이터가 쌓여야만 답할 수 있는 성과로 나눠 봤습니다.
만들었고, 직접 확인했고, 우리 기준으로 통과한 항목이에요.
| 목표 | 상태 | 확인한 근거 |
|---|---|---|
| 동아리의 정체성이 드러나는가 | 완료 | 첫 화면에서 소개·세션·활동·프로젝트·사람·블로그·모집으로 이어지는 하나의 흐름을 만들었어요. |
| 활동과 사람을 충분히 보여주는가 | 완료 | 프로젝트 목록과 상세, 멤버 명단, 운영진 소개, 활동 페이지와 블로그를 실제 데이터로 연결했어요. |
| 공식 정보의 기준점이 되었는가 | 완료 | 흩어져 있던 정보를 하나의 공식 링크로 모았고, 멤버와 운영진이 직접 갱신하며 다음 운영진에게 권한을 넘길 수 있게 했어요. |
| 외부에 공개할 완성도에 도달했는가 | 완료 | 반응형 화면, 기능·브라우저·디자인 QA와 배포 후 점검, 모니터링·백업·복구 경로를 확인했어요. |
제품 책임자로서 가장 신경 쓴 건 사실 이쪽이에요. 목표만 세우고 “잘 됐겠지”로 두면 다음 기수가 판단할 근거가 없으니까요. 그래서 두 가지를 미리 해뒀습니다. 하나는 판단 기준을 결과가 나오기 전에 못 박은 것 — 지표는 나중에 급하게 정하면 어느새 유리한 숫자만 고르게 되거든요. 다른 하나는 어드민 이용 현황을 만들 때 이 지표들을 실제로 수집하도록 계측을 심어둔 것이에요. 측정할 생각이 없는 목표는 목표가 아니라 바람이니까요.
이 제품의 핵심 성과(North Star)는 하나로 좁혔어요. 낯선 방문자가 지원자로 바뀌는 전환. 나머지 지표는 그 전환을 앞뒤에서 설명하는 신호로 뒀습니다.
| 성과 목표 | 핵심 지표 · 측정 방법 | 지금 상태 · 언제 판단 |
|---|---|---|
| 방문자가 동아리를 이해하는가 (선행) | 랜딩 끝까지 도달률, 체류 시간, 콘텐츠 탐색 클릭 — 어드민 이용 현황에서 자동 수집 | 계측 완료, 기준선 없음. 공개 후 첫 트래픽으로 기준선부터 확보 |
| 관심이 지원으로 이어지는가 (핵심) | 모집 알림 신청 수와 전환율, 지원서 제출 수와 전환율 — 버튼 클릭이 아니라 실제 저장된 건으로 | 경로 완성. 첫 모집 기수에서 기준선 측정, 다음 기수에 목표선 설정 |
| 기록이 계속 쌓이는가 (후행) | 기수별 활성 기여자 수 — 로그인해 글·프로젝트·프로필을 실제로 갱신한 인원 | 구조 완성. 기수 인수인계마다 재확인 |
첫 공개라 비교할 기준선 자체가 없어요. 그래서 다음 모집의 목표는 특정 숫자를 넘기는 게 아니라 기준선을 만드는 것입니다. 목표선은 그 기준선 위에서 다음 기수가 세우기로 했어요. 성과 리뷰 시점도 미리 정해뒀습니다. 첫 모집이 끝난 직후 한 번, 그리고 기수 인수인계 때마다 한 번.
기능 개수나 커밋 수를 여기에 넣지 않은 건 의도예요. 그건 우리가 얼마나 움직였는지를 보여줄 뿐, 방문자에게 무엇이 통했는지는 말해주지 않는 허영 지표에 가깝거든요. 우리가 보려는 건 방문자가 동아리를 이해하고, 그 관심이 행동으로 바뀌고, 멤버가 기록을 쌓고, 운영진이 그 흐름을 유지하는 — 사람 쪽에서 일어나는 변화입니다.
그래서 아직 정직하게 답할 수 없는 질문이 남아요. 지원 폼이 있다는 사실과 실제 지원으로 이어진다는 결과는 다르고, 기록할 화면이 있다는 것과 다음 기수가 정말 기록한다는 것도 다릅니다. 다만 이번엔 그 질문을 감으로 답하지 않아도 돼요. 무엇을, 어떤 기준으로, 언제 볼지까지 정해뒀으니, 다음 운영이 데이터로 답을 채워줄 겁니다.
이제 누군가 경희대 멋사가 어떤 곳인지 물으면 바로 보낼 공식 링크가 있어요. 처음 온 사람은 소개, 활동, 프로젝트와 사람을 한곳에서 보고, 마음이 생기면 모집 알림을 신청하거나 지원할 수 있습니다.
하지만 더 오래 남을 건 화면이 아니라 그 아래의 운영 기반이에요. 멤버는 자기 기록을 직접 쌓고, 운영진은 이용 현황과 감사 로그를 보며 판단하고, 다음 기수는 코드만이 아니라 왜 이렇게 만들었는지까지 넘겨받아요. 적어도 같은 시행착오를 처음부터 다시 겪을 필요는 없게 됐습니다. 시간이 쌓이면 기수별 활동과 프로젝트가 모여, 모집이나 외부 협업에서 긴 설명보다 먼저 내밀 수 있는 근거가 될 거고요.
그러니 배포로 경희대 멋사의 얼굴이 완성된 건 아니에요. 처음에 적었듯 공식 홈페이지는 공개한 다음 날부터 낡기 시작하니까요. 다만 이번엔, 낡는 속도보다 기록이 쌓이는 속도가 조금 더 빠르도록 만들어 뒀어요. 이 공간도 그렇게 동아리와 함께 조금씩 완성되면 좋겠어요.