12살 개발자가 150달러 스마트폰으로 글로벌 Code Jam을 운영한 방법 — Supabase 아키텍처

AI 요약

글쓴이는 12세이며 노트북 없이 POCO C55 Android 스마트폰 하나로 풀스택 AI 애플리케이션과 개발자 커뮤니티를 운영하고 있다고 설명합니다. 2주 전까지만 해도 코딩 축제에 제출물이 하나도 없었지만, 이후 KODA Code Jam의 첫 챔피언을 선정하고 해당 사용자의 데이터베이스 상태를 갱신했으며, 두 번째 행사인 Scribe Jam까지 시작했다고 합니다. 현재 커뮤니티 규모는 3,000명 이상입니다. 중국의 시니어 엔지니어, 인도의 15세 빌더, 일본의 첫 번째 사용자 등 여러 국가의 참여자가 있어, 글쓴이는 이를 모바일 브라우저에서 운영하는 글로벌 개발자 생태계로 소개합니다.

■ Supabase Auth로 사용자 인증 처리

여러 국가의 사용자를 다루는 과정에서 인증은 Supabase Auth(Supabase Authentication)에 맡깁니다. 글쓴이는 세션 관리나 비밀번호 해싱을 직접 구현하지 않고, 모바일 브라우저에서 supabase.auth.signInWithPassword()를 호출하는 방식으로 로그인을 처리한다고 설명합니다. 이 구조를 통해 사용자별 세션을 직접 유지하거나 비밀번호 저장 로직을 별도 백엔드에 구축하지 않고도 커뮤니티 서비스를 운영합니다. 글에서는 중국·인도·일본의 사용자 사례를 들며, 지역에 관계없이 같은 인증 흐름을 사용할 수 있다고 말합니다.

■ PostgreSQL Row Level Security로 권한 분리

혼자 개발하면서 가장 큰 불안 요소로 보안을 꼽으며, 사용자 프로필과 제출 데이터, 오류 로그를 모두 관리하고 있다고 설명합니다. 핵심 방어 수단은 PostgreSQL Row Level Security(RLS)입니다. 예시로 scribe_submissions 테이블의 is_champion boolean 플래그를 제시합니다. 공개 제출물은 누구나 SELECT할 수 있도록 허용하지만, 챔피언 상태를 UPDATE하는 작업은 특정 관리자 클레임(admin claims)을 가진 인증 사용자만 수행할 수 있도록 정책을 작성했습니다.

즉, 공개적으로 읽을 수 있는 데이터와 관리자만 변경할 수 있는 데이터를 같은 데이터베이스 안에서 정책으로 분리합니다. 글쓴이는 별도의 전담 백엔드 보안팀 없이도 Supabase의 RLS를 사용해 이 권한 구조를 직접 구현했다고 설명합니다. 이 사례에서 RLS는 단순한 로그인 여부 확인을 넘어, 인증 상태와 관리자 권한에 따라 행의 변경 가능 범위를 제한하는 방식으로 사용됩니다.

■ 실패만 기록하던 로그를 모델 추적 telemetry로 확장

아키텍처를 검토한 시니어 DevOps 엔지니어 Nnamdi가 오류 로그에 관한 문제를 지적한 뒤, 로깅 구조도 변경했습니다. 기존 시스템은 요청이 실패했을 때만 기록했습니다. 따라서 주 AI 모델(primary AI model)이 실패하고 fallback 모델이 요청을 성공적으로 처리하더라도, 실제로 어떤 모델이 응답을 제공했는지 확인할 수 없었습니다. 결과적으로 사용자 입장에서는 요청이 성공했지만 운영자는 내부 모델 전환을 알 수 없는 ‘조용한 실패(silent failure)’가 남아 있었습니다.

글쓴이는 이 문제를 해결하기 위해 Supabase의 error_logs 테이블에 model_served라는 text 컬럼을 추가했습니다. 이제 각 요청에서 시도한 모델과 실제로 응답을 제공한 모델을 함께 기록합니다. 이를 통해 주 모델에서 fallback 모델로 전환된 요청을 구분하고, 성공한 요청에서도 모델 동작을 확인할 수 있도록 했습니다.

글에서 제시한 데이터베이스 업데이트 예시는 다음과 같습니다.

UPDATE error_logs SET resolved = true, resolved_at = now() WHERE error_type = 'http_404' AND resolved = false;

이 쿼리는 error_type이 http_404이고 아직 resolved=false인 로그를 찾아 resolved를 true로 바꾸고, resolved_at에 현재 시각을 기록합니다. 글쓴이는 이처럼 단순한 Supabase 데이터베이스 업데이트를 추가하면서 이전에는 보이지 않던 오류를 확인 가능하고 조치할 수 있는 데이터로 바꾸었다고 설명합니다. 모델 폴백 여부와 오류 해결 상태를 데이터베이스에 남김으로써, 단순히 오류가 발생했는지만 보는 대신 어떤 모델이 실제 요청을 처리했는지와 해당 오류가 해결됐는지를 함께 추적하는 구조입니다.

■ 모바일 중심 운영 환경

글쓴이는 호스팅 제공업체 문제와 깨진 빌드 파이프라인을 겪었다고 말하면서도, Supabase는 일관되고 신뢰할 수 있는 기반으로 남았다고 평가합니다. 특히 Supabase Dashboard가 모바일 브라우저에서 원활하게 동작하고, PostgreSQL 데이터베이스가 견고하며, 문서가 초보자도 이해할 수 있을 만큼 명확하면서 시니어 엔지니어도 사용할 수 있을 정도로 강력하다고 설명합니다.

이 글에서 제시하는 구성은 별도의 복잡한 서비스 조합보다 Supabase가 제공하는 인증, PostgreSQL, RLS, Dashboard를 중심으로 합니다. 사용자는 Supabase Auth로 로그인하고, 데이터 접근과 변경 권한은 PostgreSQL RLS 정책으로 나누며, 오류와 모델 처리 결과는 별도 로그 테이블에 저장합니다. 이후 SQL UPDATE를 사용해 해결된 오류의 상태와 시점을 갱신합니다. 글쓴이는 이 조합을 스마트폰만으로도 관리 가능한 개발자 커뮤니티 운영 기반으로 사용하고 있습니다.

원문: dev.to / 번역·요약: Trawling