Supabase와 14단계 Edge 보안을 사용하여 실시간 Bounty Marketplace를 구축한 방법

저는 누구나 작업(이하 "bounty")을 게시하고, 보상을 설정하며, 사람들이 검증 가능한 증거와 함께 이를 완료할 수 있는 플랫폼을 만들고 싶었습니다. 프리랜서 작업과 비슷하지만, 증거 제출을 핵심 신뢰 메커니즘으로 하여 빠르고 조합 가능한 작업 완료에 최적화된 형태를 생각했습니다.

그 결과물은 BountyClaimer 입니다. 이는 Supabase + Vercel 위에서 실행되는 실시간 마켓플레이스로, Edge 미들웨어에 내장되고 스택의 모든 계층에 분산된 보안 시스템을 갖추고 있습니다.

🛠️ 기술 스택 (The Tech Stack)

• Frontend: React + Vite + TypeScript
• Backend: Supabase (PostgreSQL, Realtime, Storage, Auth)
• Payments: Stripe
• Hosting: Vercel (Edge Middleware)
• Security: 커스텀 "Armadillo" 시스템 (14단계)
• Architecture Pattern: 실시간 상태 일관성을 위한 Phoenix Architecture

🔄 핵심 워크플로우 (The Core Workflow)

1. Post (게시) — 사용자가 보상과 설명을 포함한 bounty를 게시합니다.
2. Claim (수령) — 다른 사용자들이 사용 가능한 bounty를 찾아 수령합니다.
3. Submit (제출) — 수령자가 작업을 완료하고 증거(이미지, 비디오, 오디오, 텍스트, 파일)를 제출합니다.
4. Settle (결제/정산) — bounty 소유자가 검토 후 승인하면 자금이 지급됩니다.
5. Sync (동기화) — 실시간 업데이트를 통해 양측의 상태를 즉시 동기화합니다.

가장 어려웠던 부분은 여러 사용자 간의 실시간 상태 동기화 (real-time state sync), 정당한 사용자를 방해하지 않으면서 남용을 방지하는 것 (anti-abuse), 그리고 Edge에서의 보안 (security at the edge) 이었습니다.

🏛️ Phoenix Architecture

제가 특히 자랑스럽게 생각하는 패턴 중 하나는 제가 Phoenix Architecture라고 부르는 것입니다. 이는 폴링 (polling) 없이 모든 클라이언트가 동일한 진실을 볼 수 있도록 보장하는 실시간 상태 관리 접근 방식입니다.

핵심 아이디어는 다음과 같습니다. 각 클라이언트가 데이터를 가져오고 그것이 최신이기를 바라는 대신, 데이터베이스의 변경 사항(bounty 상태 업데이트, 증거 제출, 수령 상태 전환 등)이 Supabase Realtime을 통해 방송(broadcast)됩니다. 연결된 모든 클라이언트는 동일한 이벤트 스트림을 수신하고 로컬에서 업데이트를 수행합니다.

// 이벤트 스트림으로부터 로컬에서 업데이트
const channel = supabase
...

폴링(Polling)도 없고, 오래된 데이터(stale data)도 없으며, "새로운 제출물을 보려면 새로고침하세요"라는 메시지도 없습니다. PostgreSQL 함수를 통한 서버 측 검증(server-side validation)과 결합되어, 이는 비즈니스 규칙이 데이터베이스 수준에서 강제되며 UI가 즉각적으로 실제 상태를 반영함을 의미합니다.

🛡️ Edge에서의 보안 (Armadillo 시스템)

가장 흥미로운 엔지니어링 과제는 Armadillo였습니다. 이는 Vercel의 Edge 네트워크에서 작동하며, 요청이 애플리케이션에 도달하기 전에 모든 요청을 가로채는 계층형 보안 시스템입니다. 이 시스템은 심층 방어(defense-in-depth)를 중심으로 설계되었습니다.

검사 항목 (Edge에서, 요청이 앱에 도달하기 전):

• 스캐너/정찰 도구 탐지 — 알려진 악성 유저 에이전트(user agents) 차단
• 다중 패스 URL 디코딩(multi-pass URL decoding)을 통한 SQL 인젝션(SQL injection) 및 XSS 스캐닝
• 메모리 효율적인 데이터 구조를 사용한 IP당 속도 제한(Rate limiting)
• 의심스러운 트래픽에 대한 적응형 작업 증명(adaptive proof-of-work) 챌린지
• 행동 분석 및 엔트로피 기반 봇 탐지
• 교차 지역 위협 인텔리전스(threat intelligence) 공유

핵심적인 통찰은 Edge에서의 보안이 컴퓨팅 리소스를 소모하기 전에 공격을 잡아낸다는 점이었습니다. 스캐너 프로브(scanner probes), 인젝션 시도, DDoS 패턴이 네트워크 경계에서 차단됩니다.

또한 브라우저에서 실행되는 **클라이언트 측 구성 요소(client-side component)**가 있어, 핑거프린팅(fingerprinting), 행동 분석 및 모니터링을 수행하고 데이터를 시스템으로 다시 전달합니다. Edge 미들웨어, 데이터베이스 계층, 그리고 클라이언트 사이에서 그 어떤 요청도 검증 없이 통과되지 않습니다.

🔐 데이터베이스 패턴

모든 중요한 작업(Bounty 생성, 증거 제출, 청구 정산)은 PostgreSQL 함수를 통해 수행됩니다. 이를 통해 비즈니스 로직을 데이터 근처에 유지하고, API 계층의 체크에서 발생할 수 있는 경쟁 상태(race conditions)를 방지합니다. 패턴은 간단합니다: 검증(validate) → 실행(execute) → 반환(return). 데이터베이스 수준에서 검증이 실패하면, 그 어떤 API 트릭으로도 이를 우회할 수 없습니다.

🧠 내가 다르게 했을 것들

• 초기 증명 유형 최소화 (Fewer initial proof types) — 첫날부터 모든 것(이미지, 비디오, 오디오, 텍스트)을 지원하는 것은 복잡성을 더합니다. 텍스트로 시작하여 나중에 확장하세요.
• 미들웨어에서 정적 파일 화이트리스트를 조기에 설정 — 매니페스트(manifest) 파일과 같은 정적 자산은 예외 처리를 잊을 경우 실수로 자체 보안 퍼즐을 트리거할 수 있습니다.
• Supabase 타입 재생성 (Supabase type regeneration) — 스키마(schema) 변경 후에는 즉시 TypeScript 타입을 재생성하세요. 시행착오를 통해 배우지 마세요.

📝 교훈 (Lessons Learned)

실제 돈이 오가는 마켓플레이스를 구축한다는 것은 보안이 단순한 기능이 아니라 기초라는 것을 의미합니다. Armadillo 시스템은 단순한 속도 제한기(rate limiter)로 시작하여 훨씬 더 포괄적인 시스템으로 성장했습니다. Edge 미들웨어 접근 방식은 공격이 리소스를 소모하기 전에 차단됨을 의미하며, Phoenix Architecture 패턴은 복잡한 클라이언트 측 로직 없이도 실시간 상태를 일관되게 유지합니다.

플랫폼은 bountyclaimer.com 에서 라이브로 운영 중입니다. 워크플로우, 아키텍처 또는 눈에 띄는 부분에 대한 피드백을 환영합니다. 질문은 댓글로 남겨주세요! 제 프로젝트에 관한 글을 읽어주셔서 감사합니다 :)