내 역할 — 백성검
Super-Sub 는 4인 팀 프로젝트입니다. 이 사이트의 다른 페이지는 네 사람이 함께 쓴 제안서이고, 여기서는 제가 맡은 부분만 따로 정리합니다.
팀 저장소는 pmhllll12/super-sub.cloud 입니다.
팀 구성
| 이름 | 맡은 것 |
|---|---|
| 박민호 | PM — 요구사항·일정, 스프린트 진행, main 통합, QA 총괄 |
| 백성검 (나) | 프론트엔드 — Flutter 앱 전체, Next.js 웹 |
| 정어진 | 백엔드 — DB·API, 영상 수집·전처리, 파이프라인, 배포 |
| 정상호 | AI 에이전트 — 루브릭 기반 실력 검증, 근거 생성 |
개발 기간 2026.08.20 ~ 2026.10.27 (10주)
내가 만든 것
Flutter 앱 전체와 Next.js 웹 대부분을 맡았습니다. 기획·디자인·구현·배포까지 한 사람이 끝까지 가져간 영역입니다.
| 규모 | |
|---|---|
| Flutter 앱 | 159개 파일 · 33,432줄 · 화면 14개 · 시험 994개 |
| Next.js 웹 | 308개 파일 · 54,411줄 · 화면 15개 |
| 커밋 | 628개 (팀 전체 약 1,840개 중 최다) |
폴더별 커밋 비중입니다. 팀 저장소에서 git shortlog 로 바로 확인할 수 있습니다.
| 폴더 | 내 커밋 / 전체 |
|---|---|
flutter/ (앱) | 111 / 114 |
www/ (웹) | 392 / 482 |
결과물
- 안드로이드 앱 — Google Play 에 올렸습니다 (비공개 테스트 진행 중, 버전 1.0.2). 프로덕션은 구글 규정상 비공개 테스트 12명 × 14일을 채워야 신청할 수 있습니다
- 웹 — supersub-ai.com
- 코드 — github.com/paiksunggum/super-sub.cloud (팀 저장소 전체 사본. 브랜치
paik가 제 작업 브랜치입니다)
풀었던 문제 여섯
화면을 몇 개 만들었는지보다, 무엇이 막혔고 어떻게 판단했는지가 남을 것 같아 여섯 가지를 적습니다. 자세한 경위는 팀 저장소의 개발 로그(www/docs/)에 회차별로 남아 있습니다.
1. 작은 휴대폰에서 화면이 깨졌다 — 조각조각 고치다 방식을 바꿨다
테스터가 「홈 영상 줄이 통째로 안 보인다」고 알려 왔습니다. 720×1280 에서 재현해 보니, 화면들이 아래에서 고정 픽셀로 쌓는 구조라 세로가 짧으면 위쪽 요소가 음수 좌표로 밀려 화면 밖으로 나가고 있었습니다.
처음엔 요소마다 크기를 줄이는 흔한 방식으로 고쳤는데, 요소마다 비율이 갈려서 기기마다 다른 화면이 됐습니다. 사용자가 「글자나 버튼 판들이 휴대폰 길이마다 다 달라져서 별로」라고 물렸습니다.
그래서 기준 기기(411×891) 도면을 한 배율로 통째로 확대·축소하는 방식으로 바꿨습니다. min(폭/411, 높이/891) 한 값만 쓰니 어떤 폰에서도 비율이 똑같습니다. 안쪽 화면들이 실제 기기 크기를 보고 어긋난 자리를 잡지 않도록 MediaQuery 를 도면 크기로 갈아 끼웠습니다.
대가도 같이 정했습니다 — 비율이 다른 기기에서는 여백이 생깁니다. 9:16 폰에서 좌우가 비는데, 요즘 폰은 대부분 19.5:9~20:9 라 거의 안 보입니다. 모르고 감수하는 것과 알고 고르는 것은 다르다고 봤습니다.
2. 웹과 앱이 같은 카드를 다르게 그렸다 — 원인은 코드가 아니라 배포였다
같은 데이터로 같은 카드를 그리는데 웹과 앱의 결과가 달랐습니다. 코드를 아무리 비교해도 차이가 없었습니다.
원인은 배포본이 최신이 아니었던 것이었습니다. 코드를 읽는 것만으로는 못 찾는 종류였고, 이후로는 「개발에서는 되는데 도메인에서 안 된다」는 증상이 나오면 배포된 산출물을 직접 받아서 확인하는 것을 먼저 하게 됐습니다. 같은 뿌리의 문제를 세 번 겪고 나서 굳은 습관입니다.
3. 헤드리스 브라우저로 스크린샷이 안 되는 환경에서 시각 검증을 바꿨다
backdrop-filter·color-mix 를 쓰는 화면이 헤드리스 크롬에서 전부 검게 뭉개졌습니다 (GL 백엔드를 바꿔 가며 재현). 스크린샷으로 확인이 안 되니 레이아웃 결함이 여러 번 새어 나갔습니다.
스크린샷만 안 되는 것이지 나머지는 다 된다는 걸 확인하고, 검증 방식을 getBoundingClientRect() 로 좌표를 재서 단언하는 것으로 바꿨습니다. 눈으로 보는 대신 숫자로 봤습니다.
같은 도구로 원인을 특정한 적도 있습니다. 구글 로그인 버튼이 배포본에서만 반응이 없었는데, 배포본에 헤드리스 크롬을 붙여 클래스 하나씩만 바꿔 가며 A/B 로 클릭해 범인을 좁혔습니다.
4. Play 콘솔이 보여 준 서명값과 실제 서명이 달랐다
앱을 스토어에 올린 뒤 구글 로그인이 안 됐습니다. SHA-1 을 등록해야 하는데, Play Console 화면에 적힌 「앱 서명 키」 값으로는 안 됐습니다.
기기에서 설치된 APK 를 직접 꺼내 apksigner 로 서명을 재 봤더니 화면 값과 달랐습니다. 그 실측값을 등록하니 바로 됐습니다. 결과적으로 클라이언트 셋(직접 배포용 · 콘솔 표시값 · 실측값)을 다 등록해 두었습니다.
화면에 적힌 값을 믿지 말고 실물을 재라는 것이 이 건에서 남은 교훈입니다.
5. 새 사용자의 첫 화면이 막다른 길이었다 — 기능이 아니라 상태 문제였다
처음 들어온 사람은 카드도 팀도 없습니다. 그래서 스쿼드 판이 빈 격자였고, 빈 자리를 누르면 「선수 넣기 — 준비 중입니다」 가 떴습니다.
기능이 준비 중인 게 아니라 팀이 없어서 못 하는 것인데, 처음 온 사람은 「이 앱 아직 미완성이구나」로 읽습니다. 그게 새 사용자가 가장 먼저 만나는 문구였습니다.
- 로그인 시 카드가 없으면 자동으로 기본 카드를 만들도록 했습니다 (카드가 없으면 판에 앉힐 대상 자체가 없어서, 카드가 팀보다 먼저입니다)
- 빈 자리를 누르면 팀 만들기 화면으로 보내고, 흐리기만 하고 막지는 않습니다 — 로그아웃하러 온 사람이 갇히면 안 되니까요. 안내지 잠금이 아닙니다
여기서 자기 자신을 다시 부르는 무한 고리에 빠질 뻔했는데(생성 직후 서버가 아직 카드를 안 내주면 끝나지 않음), 상태 감시 대신 저장소를 직접 불러 끊었습니다.
6. 프론트만 하지 않았다 — 백엔드도 직접 고쳤다
API 계약을 화면에 붙이는 과정에서 서버 쪽 문제를 두 번 직접 고쳤습니다. 알림에 팀 이름이 안 실려 화면이 id 로는 팀명을 못 쓰던 것 같은 건, 화면에서 우회하는 것보다 내려주는 쪽을 고치는 게 맞다고 보고 백엔드 담당자와 합의한 뒤 고쳤습니다.
경계를 넘을 때는 그 영역의 규칙 문서를 먼저 읽고, 고친 것은 팀의 미결 항목에 남기는 것을 지켰습니다. 4명이 각자 브랜치에서 일하는 구조라, 말없이 고치면 계약이 어긋난 채로 배포까지 갑니다.
일하는 방식
- 1인 1브랜치. 제 브랜치는
paik이고,main통합은 PM 이 맡았습니다 - 결정은 문서에 남깁니다. 회차마다 무엇을 왜 그렇게 정했는지, 그리고 되살리면 안 되는 것을 같이 적었습니다. 다음에 같은 자리를 건드릴 사람이 이미 실패한 길을 다시 가지 않게 하려는 것입니다
- 팀원에게 넘길 일은 공용 목록에 올립니다. 각자 문서에만 적으면 읽히지 않아서, 요청·결정은 한 파일로 모았습니다