EMBA2026 · PM · 개발· Started(First Commit date) 2026-04-30

EMBA E-Members

성균관대 EMBA 원우들을 위한 커뮤니티 앱 - 원우수첩(인명부), 명함 QR 공유, 멘토링, 일정·게시판·식단을 하나로.

Flutter
Firebase
iOS
Android

스크린샷

마이페이지 - 학업·동호회·직장 정보를 한 곳에서 관리하고, QR 명함과 프로필을 편집한다
명함 공유 - 내 QR을 상대가 스캔하면 EMBA 앱이 열리고, 미설치 시 모바일 브라우저에 명함이 표시된다
식단 - 주차별로 학교 식당 메뉴를 사진과 함께 본다

Setup

Problem: EMBA 원우 네트워크는 그 자체가 자산인데, 정작 그 자산이 카톡방·엑셀 명단·종이 명함·학교 공지 메일로 흩어져 있다. "저분이 몇 기 누구였더라", "그 공지 어디 있더라", "오늘 학식 뭐지"가 매번 흩어진 채널을 뒤지는 일이 된다. 원우들에게 필요한 건 화려한 기능이 아니라 "한 곳에서 사람을 찾고, 명함을 주고받고, 일정과 소식을 놓치지 않는" 기본기다.
Context: 성균관대 EMBA의 공식 원우 커뮤니티 앱. PM 1명·개발 2명의 작은 팀으로 만들었고, 제임스는 PM이자 개발자로 제품 범위·우선순위를 정의하고 인수한 Flutter 코드베이스를 개발·유지보수하며 iOS·Android 양 스토어에 출시·업데이트했다 (현재 v1.1.5, 빌드 21). 원우 한 명이 끝까지 쓸 수 있는 기본기 - 사람 찾기, 명함 교환, 일정·공지 - 를 먼저 단단하게 만드는 데 집중했다.
Users: 성균관대 EMBA 재학·졸업 원우, 그리고 기수 운영진.
Hypothesis: 흩어진 채널 대신 한 앱에서 사람·명함·일정·소식을 처리하게 하면, EMBA 네트워크가 "필요할 때 실제로 닿는" 자산이 된다.

Build

What I did: PM으로 기능 범위·우선순위를 정의하고 iOS·Android 양 스토어 출시·업데이트를 운영
인수한 Flutter 코드베이스를 개발·유지보수 (현재 v1.1.5, 빌드 21)
원우수첩(인명부) - 기수·직군·이름으로 검색·필터하고, 원우 프로필을 휴대폰 연락처로 바로 저장
명함 QR 공유 - 상대가 스캔하면 EMBA 앱이 열리고, 미설치 시 모바일 브라우저에 명함이 표시되는 폴백
멘토링 - 멘토 찾기·신청과 1:1 채팅
일정 캘린더(학사·기수·개인 일정), 게시판·공지(첨부 PDF 뷰어 내장), 학교소식·웹진(웹뷰), 주차별 식단
FCM 푸시 알림과 KO/EN 다국어
Product decisions: 기본기 우선 - 화려한 소셜 기능보다 사람 찾기·명함·일정·공지를 먼저 단단하게
명함은 QR + 웹 폴백 - 상대가 앱을 안 깔았어도 명함이 전달되도록, 네트워킹 자리에서 설치를 강요하지 않음
연락처는 휴대폰 기본 주소록으로 저장 - 앱을 떠나도 남는 자산
iOS·Android 단일 코드베이스(Flutter) - 작은 팀이 두 플랫폼을 한 번에 유지보수하도록 비용 최소화
QA considerations: 인수 코드의 경계(토큰 만료·재로그인·네트워크 실패·빈 상태·푸시 미수신)가 데모가 아니라 실제 원우 손에서 견고한가
명함 QR - 상대가 앱 미설치일 때 모바일 브라우저 웹 폴백으로 명함이 반드시 전달되는가
iOS·Android 단일 Flutter 코드베이스가 두 플랫폼에서 동일하게 동작하는가(딥링크·푸시 포함)
선제 발굴한 보안 이슈(평문 비밀번호·민감정보 로그·인증키 노출)가 실제로 닫혔는지 검증했는가
핵심 흐름(로그인·푸시·원우 검색)에 회귀 테스트가 없는 상태로 인수 - "같은 입력에 같은 결과"를 어디서 보장하는가

Outcome

Metrics: 성균관대 EMBA 원우 대상 실서비스. iOS·Android 양 스토어에 배포되어 원우들이 사용 중 (현재 v1.1.5, 빌드 21). 상세 사용 지표는 비공개.
Result / Learning: 내가 짜지 않은 코드를 인수해 다루는 일의 무게를 확인. 새 기능을 얹는 건 쉽지만, 인수 코드 위에서는 "이걸 고치면 어디가 같이 깨지는지"가 안 보이는 게 진짜 비용이었다. 그래서 기능 요청을 받기 전에 핵심 흐름(로그인·푸시·원우 검색)의 경계부터 파악하는 게 먼저라는 결론. 다음 라운드는 그 경계에 회귀 테스트를 까는 것부터.
Retrospective: 인수 직후 기능 요청부터 받기 시작했는데, 코드의 경계를 먼저 지도화한 뒤 받았어야 했다. 모르는 코드 위에 기능을 얹으면 회귀가 어디서 날지 예측이 안 된다.
자동화 테스트가 거의 없는 상태로 인수했다. 핵심 경로부터 회귀 테스트를 깔아두는 걸 더 일찍 했어야 한다.

PM 역할 (실질)

공식 역할은 프론트엔드였지만, 인수·일정·품질·배포·이해관계자 보고까지 비어 있던 PM 기능을 실질적으로 맡은 기록.

팀에서 맡은 공식 역할은 프론트엔드 개발(Flutter)이었다. 다만 태스크 분배, 일정·리스크 관리, 진행 가시화, 이해관계자 보고 같은 PM 기능이 비어 있어, 개발을 직접 하면서 그 공백을 실질적으로 메웠다. 이전 외주사가 만들어 둔 앱을 인수받아 분석하고, 흩어져 있던 요구사항·일정·권한·품질·배포를 하나로 묶어 약 두 달 만에 총학생회 임기 종료 직전 iOS·Android 동시 출시까지 끌고 갔다. 아래는 그 PM 역할의 기록이다.

프로젝트 인수 & 권한 이관

남이 짜 둔 코드와 흩어진 운영 권한을 통제 가능한 상태로 만드는, 시작점의 가장 번거롭고 중요한 일을 맡았다.

직접 작성하지 않은 기존 코드를 전수 분석하고 수정·리팩토링 항목을 리스트업 (인수 코드라 더 오래 걸리는 핸디캡을 감수)
앱·어드민·백엔드 GitHub 저장소 3종을 신규 구축하고 이관
AWS 접근 정리 - RDS·IP 화이트리스트 이슈를 식별하고 해결 요청
Google Play Console 관리자 권한 확보, 외주사 계정 권한 회수 확인
Apple Developer 팀 관리자 초대, 인증키(.p8) revoke·재발급, 외주사 멤버 제거, 배포 인증서 점검
막히는 지점에서는 백엔드까지 같이 맡겠다고 자원해 범위 공백을 메움

역량 · 일정 · 우선순위 · 리스크 · 자원 조정

스코핑 & 요구사항 합의

흩어져 있던 논의를 회의록과 합의된 범위로 고정
인수 시점에 "스펙 100% 완료"를 받는 것을 원칙으로 삼아, 핵심 스펙 차이를 발견하고 재합의
결정이 지연되던 식단 기능을 보류하고 검색·필터·웹진·명함 UI 3종을 먼저 완료해 지연 전파를 차단

역량 · 스코핑 · 범위 합의

일정 & 병목 관리

마감에서 역산한 일정을 세우고 진행
백엔드 병목을 태스크 단위로 분할해 전달하고 진행 상황을 투명하게 보고
이해관계자의 일정 질문에 항목별로 분리해 답하고, 모호한 질문은 답변 가능한 형태로 재정의한 뒤 답변

역량 · 일정 · 병목 관리

진행 가시화 & 이해관계자 커뮤니케이션

개발팀과 비개발자(학생회) 사이의 번역기이자 단일 보고 창구 역할을 했다.

상태 보드 운영 - 완료/진행중/진행전, Frontend·Backend 분리, 기존 요구사항과 추가 요구사항 구분
데일리 진행 리포트를 학생회 전원에게 정기 공유, 비개발자가 이해할 수 있는 언어로 풀어서
리스크·제약을 숨기지 않고 공유하면서 현실적 대안 세트를 함께 제시 (외주 재의뢰 / 범위 조정 / 우선순위 조정)
압박 상황에서 책임을 먼저 수용하고 재발 방지로 전환

역량 · 스테이크홀더 관리 · 리포팅 · 기대 관리

품질 & 보안

14년 QA 경험을 요청 범위 밖에서도 적용했다.

요청 범위 외 보안 이슈 6건 이상을 선제 발굴·수정 (평문 비밀번호, 민감정보 로그, 인증키 노출 등)
비개발자용 테스트 환경 구축 - Firebase App Distribution, 테스터 등록, 데모 영상
QA 리포트와 테스트 가이드를 직접 제작

역량 · 품질 · 보안 · 테스트 환경

배포 & 릴리스

iOS·Android 동시 출시를 임기 종료 직전에 완주했다.

명함용 전용 도메인과 딥링크·앱 자동 연결을 설정·배포 - 앱 미설치 외부인도 명함을 열람하도록
"금·주말 배포 지양" 원칙을 알면서도, 모니터링을 조건으로 임기 내 노출을 위해 금요일 배포를 결정
결과: 2026-06-25 Android·iOS 양 스토어 심사 정상 승인, 당일 배포

역량 · 릴리스 · 앱스토어 운영 · 인프라 의사결정

운영 이관 & 지속가능성

프로젝트를 끝내는 게 아니라 다음 주체가 이어받을 수 있게 마무리했다.

식단 기능 - 데이터 부재·운영 주체 미정 이슈를 정리하고, 프론트 영역 선반영 + 백엔드는 방학 중 처리하는 단계적 안 제시
차기(66대) 학생회·회장과의 인수인계 논의를 직접 책임으로 가져감
동아리 참여비 입금 현황 자동 체크 등 운영 효율화 아이디어 발굴
연락처 자동 저장, 명함 레이아웃, 무직 회원 표기 일관성 등 사용성 개선 다수 처리

역량 · 운영 전환 · 핸드오버 · 제품 개선

백엔드 개발자 협업 역량 (자기평가)

FE 출신이 아니어서 협업을 잘할 수 있을지 의심이 있었다. 백엔드 협업 채널 로그를 근거로 한 자기평가 - 강점과 다듬을 점.

프론트엔드 개발자 출신이 아니어서, 백엔드와 협업을 잘 해낼 수 있을지 스스로 의심이 있었다. 그래서 백엔드 협업 채널 로그(약 2주)를 근거로 협업 방식을 돌아봤다. 돌아보니 협업을 굴러가게 한 건 "FE 코딩 실력"이 아니라 인터페이스로 사고하는 힘, 요구사항 규율, 이슈 트래킹, 품질 게이트, 우선순위 정리, 그리고 사람을 대하는 태도였다. 한 분야만 깊게 판 개발자가 오히려 자주 약한 부분이다. 잘한 점과 다듬을 점을 같이 적었다.

인터페이스·의존관계 사고★★★★★
협업 도구·프로토콜 활용★★★★★
기술적 근거로 모호함 해소★★★★☆
품질·릴리스 게이트 관리★★★★★
우선순위·집중 관리★★★★☆
대인 톤·심리적 안전감★★★★☆
텍스트 커뮤니케이션 톤 · 텍스트에선 톤을 한 번 더 다듬을 여지★★★☆☆

강점

인터페이스로 사고한다

FE·BE 경계를 계약(인터페이스)으로 보고, 무엇을 주고받을지와 의존 관계를 먼저 정리한 뒤 작업을 시작했다.

협업 도구·프로토콜을 능숙하게 쓴다

필요한 API를 엔드포인트와 필드 목록 단위로 명세하고, 서브도메인 이슈는 직접 작은 express 서버를 만들어 레포에 올려 선제적으로 언블록했다. 요청에는 스크린샷 근거를 붙였다.

모호함을 근거로 닫는다

"특정 기수가 검색 드롭다운에 안 뜬다"는 모호한 이슈를 가설 수립 → 직접 테스트 → 실제 코드 확인(기수 필드가 nullable이라 "선택 안 함" 상태로 등록됨)까지 파서 "추가 수정 불필요, 현 상태 유지"로 확정했다. 동시에 지금 할 일과 나중에 개선할 일(필수값화·CSV 일괄등록 등)을 분리했다.

품질·배포 게이트를 지킨다

백엔드가 실서버 배포를 예고했을 때, 배포 전 QA·통합 확인 게이트를 요구해 검증 없는 배포를 막았다. 협업에서 가장 인상적이었던 지점.

심리적 안전감을 만든다

본인 실수를 먼저 인정하고("제가 누락한 것 같습니다"), 수정 부담을 상대에게 떠넘기지 않았다("구조적으로 문제없으니 제가 하는 게 낫겠다"). 그 결과 상대도 방어적이지 않게 자기 실수를 편히 말할 수 있었다.

다듬을 점

빠른 확인 욕구를 텍스트 톤으로 한 번 더 다듬기

이슈가 보이면 빠르게 확인하고 짚으려는 성향이 강하다. 대면에선 추진력이 되지만, 텍스트에선 같은 의도가 더 건조하게 비칠 수 있어 한 번 더 톤을 챙기면 협업이 한결 매끄러워진다.

개선 "이 부분은 제가 맥락을 놓친 것 같은데, 한 번만 정리해 주실 수 있을까요?"처럼 한 줄을 더하면 같은 정보를 더 부드럽게 주고받을 수 있다.

Tech stack: Flutter
Dart
Firebase Cloud Messaging
REST API (dio)
Hive
get_it
easy_localization
WebView
iOS
Android