레디브릿지 (ReddiBridge)

만들고 싶었던 것

이전에 만들었던 레시피 앱 냠냠의 고객을 찾으러 다닐 때, 저는 Reddit에서 관련 게시글을 찾아 읽는 일부터 시작했습니다. 하지만 여러 커뮤니티의 글을 살펴보고, 제품과의 관련성을 판단하고, 영어로 대응하는 과정은 반복 작업이 많았습니다.

레디브릿지(ReddiBridge)는 이 작업을 하나의 앱에서 이어가기 위해 만든 잠재 고객 탐색 도구입니다. Flutter와 Supabase를 기반으로 게시글 탐색, AI 관련성 평가, 번역과 영문 답장 작성 지원을 연결했습니다.

기획과 개발에 그치지 않고 Apple의 월 구독 인앱 결제를 붙여 Mac App Store에 등록했습니다. 다만 출시 이후 서비스를 이어가지 못했고, 현재는 스토어에서 내린 상태입니다. 이 페이지에는 당시의 제품과 구현 과정, 어려웠던 지점과 실패에 대한 회고를 함께 남깁니다.

실제 앱 시연

아래 영상은 당시 앱의 사용 화면입니다. 프로젝트를 선택하고 수집한 게시글 목록을 살펴본 뒤, 글의 상세 내용과 분석 기능으로 이어지는 흐름을 확인할 수 있습니다.

게시글에서 고객 후보를 찾는 흐름

1. 제품과 탐색 조건 정의: 어떤 제품을 위한 고객을 찾는지, 어떤 커뮤니티를 살펴볼지 정리했습니다.
2. 로컬에서 Reddit 게시글 수집: 사용자 기기에서 프로그램이 읽기 쉬운 JSON 형식의 게시글 데이터를 직접 요청했습니다. 이 요청이 실패하면 글 목록과 요약 등을 전달하는 RSS 피드로 다시 가져오도록 구성했습니다.
3. 글의 내용과 맥락 확인: 목록에서 후보를 선택하고 본문을 읽을 수 있도록 했습니다.
4. AI로 이해와 작성 보조: 관련성 평가, 번역과 영문 답장 작성 지원을 제품 흐름에 연결했습니다.
5. 원문 확인과 판단: Reddit 원문으로 이동해 실제 맥락을 확인하고 대응을 판단할 수 있게 구성했습니다.

어려웠던 점 1 · Reddit 글을 어떻게 가져올 것인가

핵심 기능은 게시글 수집이었지만, 개발 당시 Reddit API를 사용하는 데 정책적 제약이 있어 접근 방식을 고민해야 했습니다. 데이터가 없으면 이후의 분석과 고객 탐색 기능도 성립하지 않기 때문에 제품의 기반이 되는 문제였습니다.

이 과정에서 How I built a local-first Reddit tool without cloud infrastructure를 읽고 수집 방식을 응용했습니다.

위의 글에서 사용하는 Local-first는 작업이나 데이터 처리를 중앙 서버에만 맡기지 않고 사용자의 기기에서 우선 수행하는 접근입니다. 글에서는 수집 작업을 서버에서 실행하던 웹 앱에서, 사용자의 컴퓨터에서 실행하는 데스크톱 앱으로 바꾼 사례를 설명합니다. 글에서는 Reddit의 JSON 응답을 활용하고, 해당 접근이 실패하면 RSS를 대체 경로로 사용하는 방식을 소개합니다. 저장소는 SQLite로 구성하고, 구독 상태 확인에는 Supabase를 사용합니다.

레디브릿지에 적용한 구조

레디브릿지에서도 사용자의 기기에서 Reddit의 JSON 데이터를 직접 요청하고, 실패하면 RSS로 대체하는 경로까지 구현했습니다 (현재 레딧은 공식 RSS 기능을 삭제한다고 공지했습니다). 이처럼 기본 방법이 실패했을 때 사용할 다른 처리 방법을 마련하는 것을 fallback(대체 경로)이라고 합니다. 레디브릿지에서는 JSON 요청 실패 후 RSS로 글 목록을 가져오는 경우에 해당합니다.

사용자 기기에서 게시글 수집 시작
  → Reddit JSON 데이터 요청
     ├─ 성공 → 게시글 목록 구성
     └─ 실패 → RSS로 대체 요청 → 게시글 목록 구성
  → 앱에서 글을 확인하고 AI 분석·번역·답장 지원으로 연결

참고 글의 Python·PyQt6 앱을 그대로 옮긴 것이 아니라, Flutter·Supabase 기반의 제품에 local-first 수집 방식과 RSS 대체 경로를 응용했습니다.

이 경험은 수집 코드가 실행된다는 것과, 외부 플랫폼에 의존하는 제품을 지속해서 운영할 수 있다는 것이 서로 다른 문제임을 돌아보게 했습니다.

어려웠던 점 2 · 결제 기능보다 어려웠던 도입 과정

결제는 Paddle이나 Lemon Squeezy를 이용하려고 했습니다. 하지만 검토 과정이 까다로웠고 신청이 반복해서 거절되면서, 처음 계획한 방식으로 결제를 붙이지 못했습니다.

결국 Mac App Store에서 Apple의 월 구독 인앱 결제를 사용하는 방향으로 변경했고, 이 방식으로 출시했습니다. 고객 탐색 기능을 구현하는 일과 별개로 결제 제공업체의 검토를 통과하고, 실제로 사용할 수 있는 결제 경로를 확보하는 과정이 또 하나의 과제였습니다.

이 과정에서 결제 수단은 개발 막바지에 연결하면 끝나는 항목이 아니라, 제품의 출시 방식과 함께 초기에 검토해야 할 요소라는 점을 배웠습니다.

스토어에 출시했지만, 서비스를 내린 이유

레디브릿지는 월 구독 인앱 결제를 붙여 Mac App Store에 출시했지만 결과적으로 실패했고, 이후 스토어에서 내렸습니다.

실패 이유를 스스로 돌아봤을 때 가장 크게 남는 점은 Reddit의 폐쇄적인 정책과 플랫폼의 제약을 충분히 이해하지 못한 채 시작했다는 것입니다. 글을 수집하고 AI로 분석하는 기능을 만드는 데 집중했지만, 그 데이터를 기반으로 제품을 지속할 수 있는지에 대한 검토가 부족했다고 생각합니다.

이는 제가 이 프로젝트를 돌아보며 내린 판단입니다. 앱을 완성하고 스토어에 올리는 것만으로 제품이 성립하는 것은 아니었고, 외부 플랫폼의 접근 조건과 결제 도입 가능성도 제품의 핵심 조건이었습니다.

다음 제품에서 먼저 확인할 것

• 데이터 접근의 지속 가능성: 필요한 데이터를 가져올 수 있는지뿐 아니라, 제품의 목적과 운영 방식에 맞는 접근 조건을 확보하고 있는지 먼저 확인할 것.
• 결제와 유통의 실행 가능성: 결제 제공업체의 검토와 스토어 출시를 기능 개발과 함께 검증할 것.
• 작은 범위에서의 제품 검증: 수집·분석 기능을 크게 확장하기 전에 고객에게 필요한 가치와 운영 가능한 범위를 함께 확인할 것.

이 프로젝트는 성공 사례는 아니지만, 기획·개발·결제·출시·서비스 종료까지 직접 경험한 제품입니다. 기능 구현의 바깥에 있는 데이터 접근과 플랫폼 의존성을 다음 제품의 초기 판단 기준으로 삼게 됐습니다.