개인 개발 · iOS 앱
恋の裁判所 (코이사바)
역할
기획 · 디자인 · 풀스택 · 출시 (1인 개발)
기간
2026
기술 스택




개요
커플이 연애 갈등을 익명으로 '공개재판'에 올리면, 다른 유저(배심원)가 有罪·無罪·쌍방과실 3지선다로 투표하고, AI가 재판부 문체의 판결문까지 작성하는 iOS 소셜 앱. 일본 시장 전용으로 기획·디자인·프론트엔드·백엔드·출시까지 단독 담당. React Native 27개 화면과 자체 디자인 시스템, Supabase(Postgres·RLS·Edge Functions 11종·pg_cron) 위의 AI 판결 파이프라인.
담당 업무
- 01
React Native + TypeScript 프론트엔드 — 27개 화면, 자체 디자인 시스템, DynamicColorIOS 기반 다크모드. tsc·eslint·jest 221건 통과를 상시 기준으로 유지.
- 02
Supabase 백엔드 설계 — Postgres·RLS·Edge Functions(Deno) 11종·pg_cron. AI 판결 파이프라인은 멀티 프로바이더 failover 구성이고, 프롬프트를 DB로 분리해 앱 재배포 없이 교체 가능.
- 03
출시 전 핵심 흐름 피벗(기획 결정). 초안 모델은 '게시 → 투표 마감을 기다림 → 마감 후에야 AI가 民意를 서술'이었고, 마감이 사흘(72시간)이었음. 신규 앱에서 사흘 뒤 재방문을 기대하는 건 무리한 베팅이라 판단해 폐기. 현행은 작성자가 공개 전에 AI 판정을 받고, 확인한 뒤 공개 여부를 결정하는 흐름. 투표 마감은 36시간 — 저녁 프라임타임을 두 번 덮는 길이로 설정.
- 04
같은 피벗에서 비용 구조도 교체. 마감 후 전건 자동 생성(cron 배치)을 폐기하고 탭 시점 1회 생성 + 캐시로 변경 — 아무도 열지 않는 글에는 토큰이 들지 않음. 온디맨드 엣지는 verify_jwt + RLS 위임, 멱등 캐시, 429·503 처리, fail-closed, 유저당 24시간 30건 캡.
- 05
App Store 심사 §1.2(동의하지 않은 제3자를 대중이 판정) 대응을 '양측 진술 강제'가 아니라 익명성 자체로 설계. 사진 업로드를 제거하고 이모지 아바타로 대체해 UGC 이미지 모더레이션·권한 라벨 부담을 0으로. 배심원 번호는 유니크 랜덤 6자리(가입 트리거·충돌 시 재추첨) — 기존 해시 %9999 방식은 충돌 검출이 없어 폐기.
- 06
출시 전 자체 보안 감사에서, 소셜 로그인이 저장한 프로필 사진 URL이 비로그인 공개 API 응답에 그대로 실려 나가는 것을 발견(영향 1건). 화면에는 이모지로 폴백돼 육안 QA로는 잡히지 않는 유출이었음. 앱의 저장 중단 · 출구 함수의 화이트리스트 필터(레거시 행까지 커버) · 컬럼 CHECK 제약 3중으로 차단. 공개 경로의 컬럼은 '앱이 무엇을 넣는가'가 아니라 '무엇이 들어올 수 있는가' 로 판단해야 한다는 규칙으로 문서화.
- 07
Apple·Google·LINE 3종 로그인(LINE은 공식 지원이 없어 커스텀 엣지로 직접 구현), IAP 영수증 서버 검증, App Store 심사 대응(계정 삭제·Privacy Manifest·ATT). 심사 기간에는 공유 DB·엣지 함수 변경을 전면 보류하는 릴리스 규율 적용.
- 08
문서가 코드와 어긋나 잘못된 판단을 부른 사례를 겪은 뒤(커밋 537건 중 '정정' 커밋 23건의 최다 원인), 기계가 검사하는 사실표를 도입. 주요 설정값을 코드에서 추출해 문서와 대조하는 테스트를 두어, 코드를 바꾸면 문서 쪽이 먼저 실패하도록 구성.
성과
기획·디자인·개발·출시까지 혼자 완주한 프로덕션급 iOS 앱. 2026년 8월 15일 App Store 공개.