EMBA E-Members

EMBA 원우 네트워크는 그 자체가 자산인데, 정작 그 자산이 카톡방·엑셀 명단·종이 명함·학교 공지 메일로 흩어져 있다. "저분이 몇 기 누구였더라", "그 공지 어디 있더라", "오늘 학식 뭐지"가 매번 흩어진 채널을 뒤지는 일이 된다. 원우들에게 필요한 건 화려한 기능이 아니라 "한 곳에서 사람을 찾고, 명함을 주고받고, 일정과 소식을 놓치지 않는" 기본기다.

성균관대 EMBA의 공식 원우 커뮤니티 앱. 1차 라운드(4월 30일 인수 ~ 6월 25일 출시)는 PM 1명·개발 2명의 작은 팀이었고, 제임스는 PM이자 개발자로 제품 범위·우선순위를 정의하고 인수한 Flutter 코드베이스를 개발·유지보수하며 iOS·Android 양 스토어 동시 출시까지 끌고 갔다. 2차 라운드(6월 26일 ~ 10월)는 사정이 달랐다. 외주사 백엔드 개발자의 마지막 커밋이 6월 14일이라, 이후 앱·백엔드(NestJS·MySQL)·어드민(Next.js)·명함 웹(Express)·선거 시스템 5개 레포의 커밋과 PR 225건은 전부 한 사람 몫이었다. main 기준 앱 버전은 2.0.0+39(2026-08-27)다. 다만 2.0.0이 스토어에 실제로 나갔는지는 레포에 기록이 없고, 9월 18일 시점 메모는 운영 서버가 아직 구버전을 강제 업데이트하지 않는 상태라고 적고 있다. 여기엔 확인된 것만 적는다. 원우 한 명이 끝까지 쓸 수 있는 기본기 - 사람 찾기, 명함 교환, 일정·공지 - 를 먼저 단단하게 만든 뒤, 총학생회 운영에 실제로 필요한 것(도시락 배식, 예약, 선거)으로 넓혔다.

성균관대 EMBA 재학·졸업 원우, 그리고 기수 운영진.

흩어진 채널 대신 한 앱에서 사람·명함·일정·소식을 처리하게 하면, EMBA 네트워크가 "필요할 때 실제로 닿는" 자산이 된다.

• PM으로 기능 범위·우선순위를 정의하고 iOS·Android 양 스토어 출시·업데이트를 운영
• 인수한 Flutter 코드베이스를 개발·유지보수 (6월 25일 출시 뒤 main 기준 2.0.0+39, 2026-08-27)
• 원우수첩(인명부) - 기수·직군·이름으로 검색·필터하고, 원우 프로필을 휴대폰 연락처로 바로 저장
• 명함 QR 공유 - 상대가 스캔하면 EMBA 앱이 열리고, 미설치 시 모바일 브라우저에 명함이 표시되는 폴백
• 멘토링 - 멘토 찾기·신청과 1:1 채팅
• 일정 캘린더(학사·기수·개인 일정), 게시판·공지(첨부 PDF 뷰어 내장), 학교소식·웹진(웹뷰), 주차별 식단
• FCM 푸시 알림과 KO/EN 다국어
• 2.0 라운드(7~9월) - 명함 2종(학교 명함은 앱이 그리고 회사 명함은 업로드 이미지), 마이페이지 QR에 3분 토큰과 화면 캡처 차단, 복지·제휴 혜택과 교통 안내 탭, 총학생회 지원 이용처 예약, 학교 공지 자동 동기화(첨부는 자체 서버로 복사), 셔틀 실시간 모달
• 도시락 배식 키오스크 - 태블릿 키오스크(/kiosk)와 조교 폰(/operator)에서 QR 토큰 검증, 회차·요일별 명부와 예비 인원, 잔여 수량을 앱에 표시, 평일 16:00 자동 개장·23:00 마감(토요일은 10:00·18:00), 명절 선물 수령은 별도 테이블
• 백엔드(NestJS·TypeORM·MySQL)·어드민(Next.js)·명함 웹(Express)까지 직접 - 관리자 등급 300/255/233/222와 스코프 데코레이터, 로그인 시 bcrypt 지연 업그레이드, 학사일정·입학가이드 PDF 관리, 게시판 실제 페이징
• 학위계산기(degree-planner)를 웹뷰로 임베드 - 원격 번들을 먼저 읽고 실패하면 앱 에셋으로 폴백. 계산기 데이터는 Supabase에서 EMBA 백엔드로 이관
• 120기 기수장 선거를 위한 중앙선거관리시스템을 하루 만에 만들어 명함 웹에 얹었고(9월 17일), 같은 구조로 슬로건 선정 투표 3라운드를 돌렸다
• 외주사 보유였던 Apple·Google Play 계정의 앱 이전(App Transfer)을 9월 4일 시작해 17일 마무리 - 개인정보처리방침·지원 페이지를 명함 웹에 신설
• 66대 총학생회 리브랜드(2.0.0) - 색·슬로건·게시판 ID를 CouncilBrand 레이어로 분리해 다음 기수가 또 바꿀 수 있게

• 기본기 우선 - 화려한 소셜 기능보다 사람 찾기·명함·일정·공지를 먼저 단단하게
• 명함은 QR + 웹 폴백 - 상대가 앱을 안 깔았어도 명함이 전달되도록, 네트워킹 자리에서 설치를 강요하지 않음
• 연락처는 휴대폰 기본 주소록으로 저장 - 앱을 떠나도 남는 자산
• iOS·Android 단일 코드베이스(Flutter) - 작은 팀이 두 플랫폼을 한 번에 유지보수하도록 비용 최소화
• QR은 3분 토큰 + 화면 캡처 차단 - 명함 QR이 도시락 체크인에도 쓰이므로 스크린샷 돌려쓰기를 막는다. 유예 기간을 두고 끝낸 뒤부터 키오스크가 토큰을 검증한다
• 대리 수령은 만들고 같은 날 되돌렸다(8월 20일) - 1인 1식 유일성이 깨지는 걸 확인한 뒤 명절 선물은 아예 별도 테이블로 떼어 식사 유일성과 섞이지 않게 했다
• 학교 공지 첨부는 자체 서버로 복사 - 앱이 외부 링크를 못 여는 제약을 동기화 설계에 흡수했다. 복지 출처 감시 크론은 해시 비교만 하고 쓰기는 사람이 승인한다
• 비로그인 명함 공개 API에서 이메일은 제외 - 명함은 전달돼야 하지만 수집 가능한 연락처가 되면 안 된다
• 제휴 상세 화면에만 흐르는 "성균관대 EMBA" 표식 - 위조 방지가 목적이라 적용 범위를 두 번 좁혔다

• 인수 코드의 경계(토큰 만료·재로그인·네트워크 실패·빈 상태·푸시 미수신)가 데모가 아니라 실제 원우 손에서 견고한가
• 명함 QR - 상대가 앱 미설치일 때 모바일 브라우저 웹 폴백으로 명함이 반드시 전달되는가
• iOS·Android 단일 Flutter 코드베이스가 두 플랫폼에서 동일하게 동작하는가(딥링크·푸시 포함)
• 선제 발굴한 보안 이슈(평문 비밀번호·민감정보 로그·인증키 노출)가 실제로 닫혔는지 검증했는가
• 핵심 흐름(로그인·푸시·원우 검색)에 회귀 테스트가 없는 상태로 인수 - "같은 입력에 같은 결과"를 어디서 보장하는가
• stage와 운영이 정말 분리돼 있는가 - 8월 20일 운영 API가 약 20분간 stage DB를 바라본 사고(.env 소싱 뒤 pm2 --update-env). 서브셸 소싱, --update-env 금지, 배포 후 DB 확인 curl을 절차에 넣었다
• 장애를 배포 회귀로 오인하지 않는가 - 9월 16일 AWS 미납 정지로 Route 53·EC2·RDS가 함께 멈췄는데 처음엔 배포 문제로 읽었다. 데이터 손실은 없었고, 결제 알림 부재가 남은 숙제다
• 강제 업데이트 임계값과 키오스크 유예 종료가 어긋나 있다 - 운영 /version/check는 아직 구버전을 통과시키는데 키오스크는 토큰 없는 QR을 거절한다. 구앱 사용자가 배식에서 막히는 경로를 알고 있고 아직 닫지 못했다
• 비로그인 명함 조회 ID가 순차적이라 열거 가능하다 - mem_privacy는 동의 플래그지 공개 플래그가 아니다. 미해결로 적어둔다
• 회원 비밀번호 1,979건 중 1,940건이 평문이던 상태(8월 18일) - 로그인 시 bcrypt로 지연 업그레이드하는 경로를 넣었다
• 회귀 테스트가 실제로 늘었는가 - 원우수첩 모델 테스트 24건을 옛 브랜치에서 되살렸고(PR #67), 백엔드 spec 34개·명함 웹 61개·선거 159개. 어드민은 0이고 CI/CD는 없다

성균관대 EMBA 원우 대상 실서비스. 2026-06-25 iOS·Android 양 스토어 출시, main 기준 2.0.0+39(2026-08-27). 앱에 표시되는 원우 1,975명(8월 24일). 6월 26일 이후 5개 레포 PR 225건(앱 59·백엔드 64·어드민 28·명함 웹 72·선거 2). 도시락 평일 명부 화 92·수 82·목 65·토 118명. 학교 공지 자동 등록 16건, 차단 0건. 120기 기수장 선거 투표율 94.6%(37명 중 35명). 다운로드 수·스토어 리뷰·배식 체크인 누계는 기록 없음.

내가 짜지 않은 코드를 인수해 다루는 일의 무게를 확인. 새 기능을 얹는 건 쉽지만, 인수 코드 위에서는 "이걸 고치면 어디가 같이 깨지는지"가 안 보이는 게 진짜 비용이었다. 그래서 기능 요청을 받기 전에 핵심 흐름(로그인·푸시·원우 검색)의 경계부터 파악하는 게 먼저라는 결론. 다음 라운드는 그 경계에 회귀 테스트를 까는 것부터. 2차 라운드의 결과는 둘로 나뉜다. 제품은 넓어졌다. 명함·복지·예약·키오스크·공지 동기화·학위계산기·선거가 석 달 안에 들어갔고 외주사에 있던 스토어 계정도 넘어왔다. 반면 회귀 테스트를 깔겠다던 약속은 절반만 지켰다. 모델 테스트를 되살리고 백엔드·명함 웹·선거에 테스트를 붙였지만 CI는 아직 없고 어드민은 0건이다. 그 사이 운영 사고가 두 번 있었다. stage DB를 바라본 20분과 AWS 정지 하루. 둘 다 데이터는 잃지 않았고, 둘 다 절차로 남겼다.

• 인수 직후 기능 요청부터 받기 시작했는데, 코드의 경계를 먼저 지도화한 뒤 받았어야 했다. 모르는 코드 위에 기능을 얹으면 회귀가 어디서 날지 예측이 안 된다.
• 자동화 테스트가 거의 없는 상태로 인수했다. 핵심 경로부터 회귀 테스트를 깔아두는 걸 더 일찍 했어야 한다.
• 한 사람 팀이 되자 "승인이 필요 없다"가 "검증이 없다"로 미끄러지기 쉬웠다. stage 검증 뒤 운영 배포를 별도 결정으로 두는 규칙은 그래서 생겼고, 8월 20일 사고는 그 규칙이 환경 변수 한 줄에도 적용된다는 걸 가르쳤다.
• 터미널에 비밀키가 두 번 찍혔다(8월 15일, 9월 16일). 두 번 다 교체했지만, 자격증명은 화면에 치지 않고 파일로 옮기는 규칙은 두 번째 뒤에야 적었다.