Cohort Connect

오프라인 모임에서 동기들이 만나도 "무슨 일을 하시는지"부터 매번 다시 물어보고, 운영진은 그 정보를 카톡·구글폼·엑셀로 따로 모았다 흩었다 하면서 시간을 쓴다. 모임이 진행될수록 "같은 정보를 다시 모으는" 비용이 쌓이는데, 정작 그 정보로 만들 수 있는 모임 단위(소그룹·관심 영역)는 잘 보이지 않는다.

SKKU EMBA 119기 동기 그룹 대상 내부 사용(운영진 본인 포함). 학기 초에 "누구와 무엇을 같이 하면 좋을지"를 한 번에 잡지 못하면 그 학기 내내 비효율로 간다는 학습에서 시작.

같은 기수 안에서 "비슷한 관심사·직무·지역"으로 작은 모임을 찾고 싶은 원우, 그리고 모임 단위를 디자인해야 하는 운영진.

학교 계정으로만 들어올 수 있는 한 도메인에 (1) 수요조사 (2) 공지·익명 피드백 (3) 비상연락망 (4) 모임방을 모아두면, 운영진이 카톡·구글폼·엑셀을 오가지 않아도 "누가 어디서 무엇에 관심 있는지"가 운영 가능한 형태로 정리된다.

• @g.skku.edu 도메인 한정 Google OAuth - 동기만 들어올 수 있는 보안 경계
• 네트워킹 수요조사 - 기본 정보·관심사·모임 선호 지역·직무/산업을 한 폼에서 수집, 이전 응답 불러와 수정 후 재제출 가능
• 공지사항·로그인 가이드 - 로그인 후 첫 화면에 운영 정보와 사용 안내를 통합
• 익명 피드백 - 운영·커뮤니케이션·비용/회비·네트워킹·기타 카테고리, 로그인 정보·IP·기기 정보와 완전 분리
• 비상연락망·모임방·내 정보 - 동기들이 자기 정보를 직접 관리하는 영역
• 운영자 화이트리스트(ADMIN_EMAILS) + Supabase RLS - DB 레벨에서 "운영진 vs 원우" 접근 권한 분리
• Next.js 15 → Cloudflare Workers(OpenNext 어댑터) 배포 - 운영비를 학기 단위로 거의 0에 가깝게

• @g.skku.edu 도메인 제한 OAuth - "이 사이트에 누가 들어왔는지"의 신뢰가 네트워킹 데이터 입력률을 결정한다
• 익명 피드백 화면에 "로그인 정보와 연결되지 않음·IP·기기 정보 미수집·운영진은 피드백 내용만 확인" 세 약속을 명시 - 익명성이 실제로 작동한다는 확신이 있어야 첫 글이 들어온다
• 권한 모델을 RLS로 DB까지 내려보냄 - 프런트엔드 실수가 곧 데이터 노출이 되지 않게 한 겹 더
• 운영진도 동기 - 운영 화면을 따로 만들지 않고 원우 화면 위에 "관리" 액션을 얹어 한 도메인 안에서 같이 운영
• 랜딩에 "계정 설정에 2-3분 소요" 명시 - 첫 진입의 마찰을 "고장"이 아니라 "예상된 절차"로 받아들이게

• @g.skku.edu 도메인 제한 OAuth가 실제로 동기 외 계정을 막는가 - 우회 경로가 없는가
• RLS 정책을 코드 변경마다 자동화 테스트로 회귀 방지해 프런트 실수가 데이터 노출로 이어지지 않는가
• 익명 피드백이 로그인 정보·IP·기기와 절대 연결되지 않도록 DB 스키마 레벨까지 분리됐는가(화면 약속이 아니라 구조로)
• 운영진 화이트리스트(ADMIN_EMAILS)와 원우 권한 경계가 "우회되는 경우" 관점에서 검증됐는가
• 수요조사 이전 응답 불러오기·수정 후 재제출이 다른 사람 응답과 섞이지 않는가

SKKU EMBA 119기 내부 운영 중, 운영 도메인 skkuemba119.org. 사용자 수치는 미공개. 수요조사 응답 저장과 운영자 대시보드(집계·엑셀 다운로드)는 다음 마일스톤.

코호트 운영을 "카톡·구글폼·엑셀로 분산"에서 "한 도메인으로 모음"으로 옮긴 첫 라운드. 다음 라운드에서 응답 저장과 운영자 대시보드가 완성되면 "동기 운영" 도구가 다른 학회·커뮤니티로 일반화 가능한지 판단.