Sportition

Sportition · Portfolio

p.01

Sports Community Platform Overview — 시스템 구조와 핵심 설계

Core Loop — 게임화 순환 구조 · 매 훈련 사이클

① ATTEND

키오스크 출석

하루 1회 DB 제약
KST 기준

② EARN

스킬 포인트

출석·매치로
자동 적립

③ INVEST

스킬트리 해금

선행 노드 조건
코치 승인 큐

④ COLLECT

가챠 카드

4등급 수집
천장 보장

⑤ RECORD

전적 & 프로필

공개 티어·기록
소속 이력 보존

Problem

권투·격투기 체육관의 출석은 종이에, 경기는 메신저에, 진급은 코치 주관에만 의존해 데이터 신뢰성과 검증 가능성이 전무한 구조였음.

훈련이 반복될수록 동기를 유지할 메커니즘도 부재해 이탈이 구조적으로 발생.

비구조화 데이터 위에 운영되는 체육관 관리 시스템의 한계.

Solution

선수·코치·체육관·관리자를 단일 시스템으로 연결하고, 모든 이벤트(출석·경기·진급)를 DB에 기록하는 파이프라인을 설계.

게임화 루프(출석→포인트→스킬트리→카드)를 기능이 아닌 설계 원칙으로 삼아 훈련 동기를 구조적으로 지속시킴.

Asset Overview — 주요 구성 요소

역할 기반 인증Auth · Role System

선수·코치·체육관·관리자 4가지 역할. 역할마다 다른 가입 필드와 화면 접근 권한.Row Level Security로 DB 레벨에서 권한 경계 설정.

체육관 코드 시스템Gym Code · History

내부 연결 키 / 입력 코드 / 표시 이름 3계층 분리. 오타·동명 문제를 구조적으로 해결.소속 이동 시에도 이력이 끊기지 않고 보존됨.

키오스크 출석Kiosk · KST · Points

태블릿 기반 현장 출석 시스템. 한국 시간대 기준 하루 1회 제약, 포인트 적립 자동 연동.DB 레벨 강제로 조작 불가 — 데이터 신뢰성 확보.

스킬트리 & 가챠Skill Tree · Gacha · Cards

선행 노드 조건 + 코치 승인 큐. 4등급 카드 수집, 조각 합산 레벨업, 천장 보장.출석→포인트→스킬트리→카드 순환 루프 구성.

매치 기록 & 전적Match · Auto Stats

양방향 경기 기록으로 중복 없는 통계 집계. 매치 입력 즉시 전적 자동 갱신.DB 트리거로 서버사이드 집계 — 클라이언트 로직 불필요.

프로필 & 데이터 분리Public / Private · Storage

공개 정보(전적·티어)와 민감 정보(연락처·생년월일)를 DB 레벨에서 분리.공개 뷰를 통해서만 외부 접근 — 민감 컬럼 노출 구조적 차단.

Sportition · Problem & Solution

p.02

Sports Community Platform 무엇을 해결했나

기존 체육관 운영이 안고 있던 구조적 문제 5가지를 식별하고, 각각에 대해 DB·시스템 레벨의 해결책을 설계했다.

01

종이·구두 출석 → 키오스크 출석 시스템

출석 기록이 종이나 구두에 의존해 누락과 조작 가능성이 상시 존재했다.
키오스크 기반 출석으로 전환, 하루 1회 제약을 DB 레벨에서 강제해 데이터 신뢰성을 확보했다.

조작 불가한 출석 데이터 — 포인트 자동 적립까지 연동.

02

주관적 진급 → 스킬트리 + 코치 승인 큐

선수 진급 기준이 코치의 주관에만 의존해 검증이 불가능했다.
스킬트리 마스터 + 코치 승인 큐를 도입해 진급 과정을 정량화하고 이력을 남겼다.

진급 근거가 DB에 기록되어 언제든 소환 가능.

03

메신저 전적 → 양방향 경기 기록 + 자동 집계

스파링·경기 결과가 메신저에만 남아 누적 전적 관리가 불가능했다.
경기를 양방향으로 기록하고 DB 트리거로 통계를 자동 집계, 실시간 전적 조회가 가능해졌다.

매치 입력 즉시 양방 전적이 갱신되는 자동화 파이프라인.

04

자유 텍스트 입력 → 체육관 코드 시스템

체육관 이름을 자유 텍스트로 입력해 오타·중복으로 회원 연결 실패가 반복됐다.
체육관 코드 시스템으로 내부 연결 키 / 입력 코드 / 표시 이름을 분리해 구조적으로 해결했다.

오타가 데이터 정합성에 영향을 주지 않는 구조 달성.

05

반복 훈련 동기 저하 → 게임화 루프 설계

훈련이 반복될수록 동기가 저하되는 구조적 문제가 있었다.
스킬 포인트·스킬트리 해금·가챠 카드 시스템을 연결해 출석→포인트→스킬트리→카드 순환 루프를 설계했다.

훈련 행동이 곧 게임 진행으로 이어지는 내재적 동기 구조.

5가지 구조적 문제에 각각 DB·시스템 레벨 해결책을 적용 — 체육관 운영 전반을 검증 가능한 데이터 위에 재구성

Sportition · Features

p.03

Sports Community Platform 직접 구현한 기능들

역할 기반 인증 · Auth · Role System

선수·코치·체육관·관리자 4가지 역할. 역할마다 다른 가입 필드와 화면 접근 권한으로 구성.

RLS로 클라이언트 코드가 변경되어도 DB 레벨에서 접근 차단.

체육관 코드 시스템 · Gym Code · History

고유 코드로 체육관을 정확히 식별. 회원 이동 시에도 소속 이력이 끊기지 않고 보존.

내부 연결 키 / 입력 코드 / 표시 캐시 분리로 오타·동명 문제 구조적 해결.

키오스크 출석 · Kiosk · KST · Points

태블릿 기반 현장 출석. 한국 시간대 기준 하루 1회 제약, 포인트 적립까지 연동.

DB 레벨 강제로 조작 불가 — 데이터 신뢰성 확보.

스킬트리 · Skill Tree · Approval

선행 노드 조건, 포인트 투자, 코치 승인 큐까지 연결된 단계적 기술 학습 경로.

진급 과정이 정량화·이력화되어 주관 의존 탈피.

가챠 시스템 · Gacha · Cards · Pity

4등급 스킬 카드 수집. 조각 합산 레벨업, 천장 보장, 스킬트리 노드 장착 연결.

수집·강화·장착이 스킬트리와 연결되어 게임화 루프 완성.

매치 기록 & 전적 · Match · Auto Stats

양방향 경기 기록으로 중복 없는 통계 집계. 매치 입력 즉시 전적이 자동 갱신.

DB 트리거로 서버사이드 자동 집계 — 클라이언트 로직 의존 없음.

프로필 & 아바타 · Public / Private · Storage

공개 정보와 민감 정보를 DB 레벨에서 분리. 스토리지 기반 아바타 업로드 지원.

별도 테이블 분리 + 공개 뷰로 민감 컬럼 실수 노출 구조적 차단.

모바일 최적화 · 375px · Mobile First

iPhone SE 375px를 기준으로 설계. 키오스크부터 코치 패널까지 단일 코드베이스.

체육관 현장 사용이 핵심 — 모바일을 출발점으로 확장 설계.

Sportition · Tech Stack

p.04

Sports Community Platform 기술 선택과 이유

MVP 속도와 운영 단순성을 위해 별도 백엔드를 두지 않는 방향으로 스택을 구성했다. 각 기술은 독립적으로 선택된 것이 아니라 서로의 역할을 보완하는 구조로 통합되었다.

Tech Stack — 선택 기준과 결정 포인트

Next.js 15Framework

App Router 기반 SSR과 Cloudflare Workers 엣지 환경 호환성. 모바일·데스크톱을 단일 코드베이스로 처리한다.엣지 배포 + SSR을 동시에 충족하는 선택.

SupabaseBaaS · PostgreSQL

Row Level Security로 인증과 권한을 DB 레벨에서 처리. 별도 백엔드 없이 트리거·RPC로 서버사이드 로직을 구성했다.백엔드 없이 권한·자동화를 DB에서 해결.

Cloudflare WorkersEdge Deployment

OpenNext로 Next.js를 Workers 런타임으로 변환. 글로벌 엣지로 국내 사용자 레이턴시를 최소화하고 git push 시 자동 배포.응답 속도 + 자동 배포 파이프라인.

PostgreSQLDatabase

트리거로 매치 기록 즉시 통계 집계, 가입 시 연관 테이블 자동 초기화. 클라이언트 로직에서 누락이 생겨도 DB 레벨에서 정합성을 보장한다.트리거·RLS로 데이터 정합성을 서버에서 보장.

React 19UI Library

컴포넌트 기반으로 역할별 화면 16개를 구성. 코치 패널부터 키오스크 출석까지 하나의 컴포넌트 트리 안에서 관리한다.역할별 16개 화면을 단일 컴포넌트 트리로.

스택 구성 시각화

기술 역할 분담 — 시스템 레이어별

Frontend (React 19)

16개 화면

Framework (Next.js 15)

SSR · Routing

Auth · RLS (Supabase)

4 Roles

DB Triggers (PostgreSQL)

Auto Stats

Edge Deploy (CF Workers)

Global CDN

Backend Strategy

서버리스 · BaaS Only

별도 서버없음

권한 경계RLS (DB 레벨)

서버 로직Trigger · RPC

배포 트리거git push

Mobile Strategy

Mobile First · 375px

기준 해상도375px (iPhone SE)

코드베이스단일 (Next.js)

키오스크태블릿 대응

스타일링Tailwind CSS

Sportition · Design Decisions

p.05

Sports Community Platform 설계 과정에서 내린 판단들

기능 목록이 아니라 왜 그렇게 설계했는가의 기록. 각 판단은 초기 설계 실패 또는 구조적 제약을 직면한 뒤 내려졌다.

01

체육관 식별자를 3계층으로 분리했다

초기엔 체육관 이름으로 회원을 연결했다. 오타와 동명 문제가 반복되자 내부 연결 키 / 입력 코드 / 화면 표시 캐시를 분리하는 구조로 재설계했다.

이후 이름 변경이나 오타가 데이터 정합성에 영향을 주지 않는다.

UUID(연결) / GYM_CODE(입력) / display_name(캐시) — 3계층

02

별도 백엔드 없이 BaaS만으로 권한을 처리했다

MVP 속도를 위해 별도 서버를 두지 않았다. 대신 Row Level Security를 DB의 유일한 권한 경계로 삼았다.

클라이언트 코드가 어떻게 변경되어도 DB 레벨에서 접근이 차단된다.

03

게임화를 기능이 아닌 설계 원칙으로 뒀다

포인트·스킬트리·가챠를 독립 기능으로 추가하는 대신, 출석→포인트→스킬트리 투자→카드 장착의 순환 루프로 설계해 세 시스템이 서로를 강화하도록 연결했다.

기능 제거 시 전체 루프가 무너지는 결합도 — 의도적 설계.

04

모바일을 별도 대응이 아닌 출발점으로 삼았다

체육관 현장 사용이 핵심 시나리오다. iPhone SE 375px를 기준점으로 잡고 확장하는 방식으로 설계해, 키오스크 출석부터 코치 패널까지 단일 코드베이스로 동작한다.

모바일 대응이 아닌 모바일 우선 — 데스크톱이 확장 결과.

375px → 768px → 1280px 확장 기준

05

소속 이동 시 이력이 끊기지 않도록 설계했다

선수가 체육관을 옮기면 기존 기록 컨텍스트가 사라지는 문제가 있었다. 경기 기록에 당시 소속 스냅샷을 함께 저장하고 이동 이력을 누적해 과거 기록이 원본 컨텍스트를 유지하도록 했다.

어느 시점의 기록이든 당시 소속 정보와 함께 온전히 복원 가능.

06

공개 정보와 민감 정보를 DB 레벨에서 분리했다

전적·티어는 공개하고 연락처·생년월일은 본인만 접근해야 한다. 두 종류를 별도 테이블에 분리하고 공개 뷰를 통해서만 외부 접근이 가능하도록 설계해 민감 컬럼이 실수로 노출되는 경우를 차단했다.

민감 컬럼 노출이 구조적으로 불가능한 테이블 설계.

profiles_public (view) / profiles_private (restricted table)

6가지 판단 모두 초기 실패 또는 구조적 제약을 직면한 뒤 내려진 결정 — 기능 목록이 아닌 설계 사유의 기록