리뷰 AI

1. 서비스 소개

리뷰 AI는 당사가 직접 개발한 리뷰 관리 서비스입니다.

• 대상 사용자: 배달·플레이스 리뷰를 관리하는 외식업 사업자
• 연동 플랫폼: 배달의민족, 요기요, 쿠팡이츠, 네이버플레이스
• 제공 형태: 모바일 우선 웹 서비스, 구독 결제
• 핵심 구성: 리뷰 수집 서비스 + AI 답변 생성 + 운영 통계

2. 도입 배경

음식점을 운영하면 리뷰가 배달의민족, 요기요, 쿠팡이츠, 네이버플레이스로 나뉘어 쌓입니다. 플랫폼마다 사장님 앱이 따로 있고, 로그인도 따로 해야 합니다. 답변을 달려면 앱 네 개를 돌아가며 열어야 하고, 바쁜 시간대를 넘기면 리뷰가 밀립니다. 답변을 늦게 달거나 빠뜨리는 이유는 대부분 의지가 아니라 동선의 문제입니다.

동선만 문제가 아니다

답변의 내용도 부담입니다. 좋은 리뷰에는 감사를, 낮은 평점에는 사과와 개선 약속을 담아야 하는데, 하루에 수십 건을 쓰다 보면 문장이 똑같아집니다. 복사해서 붙여 넣은 티가 나는 답변은 오히려 안 하느니만 못합니다. 그렇다고 매번 새로 쓰기에는 시간이 없습니다. 결국 평점이 낮은 리뷰만 골라 대응하거나, 아예 손을 놓게 됩니다.

쓰는 일에서 확인하는 일로

리뷰 AI는 이 두 가지 부담을 줄이기 위해 만든 자체 솔루션입니다. 2025년 6월부터 9월까지 약 4개월간 개발했습니다. 여러 플랫폼의 리뷰를 자동으로 수집해 한 화면에 모으고, AI가 리뷰 내용에 맞는 답변 초안을 만들어 줍니다. 사장님이 하는 일은 문장을 쓰는 것에서 확인하고 보내는 것으로 바뀝니다.

공개 API 없이 수집한다는 전제

설계에서 가장 먼저 정한 것은 수집 방식이었습니다. 배달 플랫폼은 대부분 사장님용 공개 API를 제공하지 않습니다. 그래서 사람이 브라우저에서 하던 조작을 자동화하는 방식(RPA)으로 리뷰를 가져와야 했고, 이 방식은 실패를 전제로 설계해야 합니다. 플랫폼 화면이 바뀌거나, 로그인이 풀리거나, 응답이 느려지는 일이 상시로 일어나기 때문입니다.

리뷰 관리가 매출과 무관한 일이었다면 이런 서비스는 필요 없었을 것입니다. 하지만 배달 앱에서 리뷰와 평점은 노출 순위에 영향을 주고, 소비자가 주문 전에 가장 먼저 보는 정보이기도 합니다. 답변이 달린 리뷰와 그렇지 않은 리뷰는 같은 평점이라도 다르게 읽힙니다. 문제는 이 사실을 알면서도 실행하기 어렵다는 점이었습니다. 알면서 못 하는 일은 대개 동기가 아니라 절차의 문제이고, 절차는 도구로 바꿀 수 있습니다.

매장의 하루를 따라가 보면 문제가 분명해집니다. 점심 피크가 끝나고 잠깐 앉았을 때, 저녁 준비를 시작하기 전까지가 리뷰를 볼 수 있는 시간입니다. 그 짧은 시간에 앱 네 개를 열어 로그인하고, 새 리뷰를 찾고, 문장을 고민해 쓰는 일은 현실적으로 어렵습니다. 도구가 해야 할 일은 이 시간을 늘리는 것이 아니라, 같은 시간 안에 끝낼 수 있게 만드는 것입니다.

한 줄 요약 사장님이 하는 일이 "문장을 쓰는 것"에서 "확인하고 보내는 것"으로 바뀝니다.

3. 활용 기능

리뷰 수집, AI 답변 생성, 운영 분석을 하나의 서비스로 묶었습니다. 저장소는 모노레포로 구성해 웹 애플리케이션, 데이터베이스 패키지, 수집 서비스를 함께 관리합니다.

수집 서비스

플랫폼 리뷰는 독립적으로 동작하는 수집 서비스가 가져옵니다. 이 서비스는 웹과 분리된 별도 프로세스로 돌고, 수집 요청을 받는 API와 주기 실행을 담당하는 스케줄러, 실제 수집을 수행하는 워커로 나뉩니다. 웹에서 "지금 동기화" 버튼을 눌러도, 스케줄러가 정해진 시각에 돌려도 같은 워커가 실행됩니다.

수집 범위는 매번 전체를 훑지 않고 필요한 구간만 가져옵니다. 사용자가 기간을 지정하면 그 기간을, 지정하지 않으면 데이터베이스에서 마지막 리뷰 날짜를 찾아 그 이후만 수집합니다. 조회에 실패하거나 처음 연동하는 경우에는 기본 기간을 적용합니다. 매번 전체를 가져오면 수집 시간이 계속 늘어나고 플랫폼에도 부담을 주기 때문에, 증분 수집을 기본으로 삼았습니다.

작업 큐

수집은 큐에 작업을 넣고 순서대로 처리합니다. 한 매장이 네 개 플랫폼을 연동하고 있으면 작업이 네 개 생기고, 각각 독립적으로 실행됩니다. 특정 플랫폼이 응답하지 않으면 그 작업만 실패 처리되고 나머지는 계속 진행됩니다. 실패한 작업은 재시도 대상으로 남아 다시 실행됩니다.

큐를 둔 이유는 한 가지 더 있습니다. 수집은 시간이 오래 걸리는 작업이라 웹 요청 안에서 처리할 수 없습니다. 요청은 작업을 등록하는 것으로 끝나고, 실제 수집 결과는 나중에 화면에 반영됩니다.

웹 애플리케이션

사장님은 웹에서 플랫폼 구분 없이 리뷰를 한 목록으로 봅니다. 리뷰를 선택하면 AI 답변 초안이 생성되고, 그대로 보내거나 수정해서 보냅니다. 매장 설정에서는 응답 톤과 연동 계정, 알림 조건을 관리합니다.

화면은 모바일 우선으로 구성했습니다. 사장님이 리뷰를 확인하는 시점은 대부분 매장 안이고, 그때 손에 있는 것은 휴대폰이기 때문입니다. 온보딩, 매장 등록, 플랫폼 연동, 리뷰 관리, 통계, 주간 리포트, 설정이 각각의 화면으로 존재합니다.

데이터 구조

데이터는 매장, 플랫폼 계정, 리뷰, 답변, 작업 이력으로 나눕니다. 한 매장이 여러 플랫폼 계정을 가질 수 있고, 계정마다 리뷰가 붙습니다. 답변은 리뷰에 속하되 생성된 초안과 실제로 등록된 답변을 구분해 저장합니다. 초안과 등록본을 나눠 두면 AI가 만든 문장이 얼마나 수정되어 나갔는지 확인할 수 있고, 이는 생성 품질을 점검하는 근거가 됩니다.

작업 이력은 수집 단위로 남깁니다. 언제 어떤 계정에 대해 수집을 시도했고, 몇 건을 가져왔으며, 실패했다면 어느 단계에서 멈췄는지를 기록합니다. 공개 API 없이 동작하는 시스템에서 이 기록은 장애 대응의 출발점입니다.

플랫폼 연동 관리

플랫폼 계정 연결은 한 번 해두면 끝나는 작업이 아닙니다. 비밀번호를 바꾸거나 추가 인증이 걸리면 연동이 끊기고, 그 상태로 두면 리뷰가 들어오지 않습니다. 연동 상태를 계정 단위로 관리하고, 수집이 인증 문제로 실패한 경우를 일반 실패와 구분해 표시합니다. 사용자는 어떤 계정을 다시 연결해야 하는지 화면에서 바로 확인합니다.

매장 하나에 여러 플랫폼 계정이 붙는 구조라, 계정마다 연동 상태와 마지막 수집 시각을 따로 보여 줍니다. 전체가 멈춘 것인지 특정 플랫폼만 멈춘 것인지 구분하지 못하면, 사용자는 서비스 전체를 의심하게 됩니다.

주간 리포트

한 주 동안의 리뷰 현황을 리포트로 정리합니다. 매일 확인하지 않더라도 주 단위로는 전체 흐름을 파악할 수 있어야 하기 때문입니다. 평점 변화, 리뷰 수, 답변률처럼 관리 지표가 될 만한 항목을 모아 보여 줍니다.

진행 방식

4개월이라는 기간 안에서 우선순위는 분명했습니다. 수집이 되지 않으면 나머지 기능은 의미가 없으므로, 한 플랫폼의 수집을 먼저 끝까지 완성했습니다. 수집한 데이터로 목록 화면을 만들고, 그 위에 답변 생성을 얹은 다음, 마지막에 플랫폼을 확장했습니다.

플랫폼을 한꺼번에 붙이지 않은 이유는 각 플랫폼마다 화면 구조와 인증 방식이 다르기 때문입니다. 하나를 끝까지 겪어 본 뒤에야 공통으로 뺄 부분과 플랫폼별로 남길 부분이 구분됩니다. 첫 플랫폼을 완성하면서 정리한 수집 인터페이스가 이후 확장의 기준이 되었습니다.

주요 기능

여러 플랫폼 리뷰 통합 관리

배달의민족, 요기요, 쿠팡이츠, 네이버플레이스 리뷰를 한 목록에서 봅니다. 플랫폼별로 앱을 옮겨 다닐 필요가 없고, 미답변 리뷰만 걸러 보거나 평점 기준으로 정렬하는 것도 한 번에 됩니다. 각 리뷰에는 출처 플랫폼이 표시되므로 어디에 달린 리뷰인지 헷갈리지 않습니다.

AI 자동 응답 생성

리뷰 내용과 평점을 반영한 답변 초안을 생성합니다. 매장마다 응답 톤을 설정할 수 있어, 같은 리뷰에도 매장 성격에 맞는 문장이 나옵니다. 격식 있는 어조를 쓰는 매장과 친근한 어조를 쓰는 매장의 답변이 달라야 하기 때문입니다. 낮은 평점 리뷰와 높은 평점 리뷰의 응답 방식도 구분합니다. 생성된 문장이 마음에 들지 않으면 다시 생성하거나 직접 고칠 수 있습니다.

증분 수집과 자동 동기화

마지막으로 수집한 리뷰 날짜를 기준으로 그 이후만 가져옵니다. 수집 시간이 데이터가 쌓이는 만큼 늘어나지 않고, 같은 리뷰를 중복으로 저장하는 일도 막습니다. 스케줄러가 주기적으로 실행하므로 사용자가 따로 동기화를 누르지 않아도 새 리뷰가 들어옵니다.

실패 작업 분리와 재시도

플랫폼 하나가 응답하지 않아도 다른 플랫폼 수집은 계속됩니다. 작업 단위를 플랫폼별로 나눴기 때문입니다. 실패한 작업은 상태가 기록되고 재시도 대상이 됩니다. 연동 계정에 문제가 생긴 경우처럼 재시도로 해결되지 않는 상황은 별도로 표시해, 사용자가 계정을 다시 연결하도록 안내합니다.

통계 대시보드

평점 추이, 플랫폼별 리뷰 수, 답변률을 기간별로 확인합니다. 리뷰가 늘거나 평점이 떨어지는 시점을 데이터로 짚을 수 있고, 특정 플랫폼에서만 평점이 낮다면 그 플랫폼의 운영 방식을 점검하는 근거가 됩니다.

주간 리포트

한 주 단위로 리뷰 현황을 정리해 제공합니다. 매일 대시보드를 확인하지 않는 사용자도 주 단위 흐름은 놓치지 않습니다. 지난주와 비교할 수 있도록 구성해, 숫자 하나가 아니라 변화를 보여 줍니다.

중요 리뷰 알림

평점이 낮거나 특정 조건에 해당하는 리뷰가 들어오면 알림을 보냅니다. 모든 리뷰를 실시간으로 확인할 수는 없으므로, 먼저 대응해야 할 리뷰만 골라 알리는 장치입니다. 알림 조건은 매장 설정에서 조정합니다.

구독 결제

서비스 이용은 구독 형태로 제공하며, 토스페이먼츠를 연동해 결제를 처리합니다. 체험 기간을 별도 경로로 두어, 결제 전에 기능을 확인할 수 있게 했습니다.

응답 톤 설정

매장의 성격에 맞는 문장이 나오도록 응답 톤을 매장 단위로 저장합니다. 격식을 갖춘 표현을 쓸지, 친근한 표현을 쓸지, 어느 정도 길이로 쓸지를 지정하면 이후 생성에 일관되게 적용됩니다. 답변마다 성격이 달라지면 여러 사람이 번갈아 쓴 것처럼 보이므로, 생성 기준을 매장에 고정하는 편이 자연스럽습니다.

온보딩과 매장 연동

처음 가입한 사용자는 매장을 등록하고 플랫폼 계정을 연결하는 과정을 거칩니다. 이 과정을 단계별 화면으로 나눠, 한 번에 모든 정보를 입력하지 않아도 되도록 했습니다. 연동이 끝나면 첫 수집이 자동으로 실행되어, 사용자는 가입 직후 자기 매장의 리뷰가 들어오는 것을 확인할 수 있습니다.

미답변 리뷰 정리

리뷰 목록의 기본 상태는 "전체"가 아니라 "처리해야 할 것"에 가깝게 잡았습니다. 미답변 리뷰를 먼저 보여 주고, 답변을 보내면 목록에서 정리됩니다. 해야 할 일이 줄어드는 것이 눈에 보여야 끝까지 처리하게 되기 때문입니다. 기간과 플랫폼, 평점으로 범위를 좁히는 필터는 그 위에 얹었습니다.

핵심 설계 공개 API 없이 동작하는 수집은 실패를 전제로 설계해야 합니다. 작업을 큐로 나눠 실패 단위를 특정할 수 있게 했습니다.

4. 성과

네 개 플랫폼에 흩어져 있던 리뷰 확인과 답변 작성을 하나의 화면으로 모았습니다. 앱을 네 번 여는 대신 한 번 열고, 문장을 쓰는 대신 확인하고 보냅니다. 답변이 밀리는 가장 큰 원인이었던 동선과 작성 부담을 함께 줄였습니다.

수집을 큐 기반으로 분리한 덕분에 플랫폼 하나에 문제가 생겨도 나머지 수집은 계속됩니다. 증분 수집을 기본으로 두어 데이터가 쌓여도 수집 시간이 늘지 않습니다. 공개 API 없이 동작하는 수집 시스템에서는 이 두 가지가 안정성의 대부분을 결정합니다.

통계와 주간 리포트를 함께 제공하면서, 리뷰 관리가 개별 응답을 넘어 운영 지표로 이어지도록 했습니다. 평점이 떨어지는 시점과 그때의 리뷰 내용을 함께 볼 수 있기 때문입니다.

답변 초안을 다시 생성할 수 있게 한 것도 의도된 선택입니다. AI가 만든 첫 문장이 항상 맞을 수는 없고, 마음에 들지 않을 때 직접 고쳐 쓰라고 하면 결국 처음과 같은 부담으로 돌아갑니다. 다시 생성하는 비용을 낮춰 두면 사용자는 몇 번 눌러 보고 그중 하나를 고릅니다. 이 과정이 직접 쓰는 것보다 빠릅니다.

수집 서비스를 독립 프로세스로 분리한 구조는 이후 플랫폼을 추가할 때도 그대로 쓰입니다. 새 플랫폼은 크롤러 모듈 하나를 추가하는 일이 되고, 큐와 스케줄러, 저장 로직은 건드리지 않습니다. 연동 대상이 늘어날수록 이 구조의 이점이 커집니다.

초안과 등록본을 따로 저장한 것도 운영에 도움이 됐습니다. 생성된 문장이 얼마나 수정되어 나가는지 확인할 수 있어, 응답 품질을 감이 아니라 기록으로 점검합니다.

2025년 6월부터 9월까지 웹, 수집 서비스, 결제를 포함해 구축했습니다.

5. 기술 구성

Web

Next.js 15와 React 18, Tailwind CSS로 구성했습니다. 모바일 우선 레이아웃으로 만들고, 서버 사이드 렌더링과 API 라우트를 함께 사용합니다. 서비스 소개, 요금 안내, 약관, 환불 규정 같은 정적 페이지도 같은 애플리케이션에 포함했습니다.

수집 서비스

Node.js와 Express 기반의 독립 서비스입니다. 수집 요청을 받는 API, 주기 실행을 담당하는 스케줄러, 실제 수집을 수행하는 워커로 구성하며, 플랫폼별 수집 로직을 크롤러 모듈로 분리했습니다. 플랫폼이 추가되면 크롤러만 늘리고 나머지 구조는 그대로 둡니다.

큐 / 저장소

BullMQ와 Redis로 작업 큐를 구성했습니다. 작업 등록과 실행을 분리하고, 실패한 작업의 상태를 추적합니다. 데이터베이스는 Prisma ORM과 PostgreSQL이며, 스키마는 별도 패키지로 분리해 웹과 수집 서비스가 같은 정의를 공유합니다.

모노레포 구성

Turborepo로 웹 애플리케이션, 데이터베이스 패키지, 수집 서비스를 하나의 저장소에서 관리합니다. 스키마가 바뀌면 두 서비스에 동시에 반영되므로, 한쪽만 구버전 스키마를 쓰는 상황이 생기지 않습니다.

배포

Docker와 Docker Compose로 구성하고, GitHub Actions로 빌드와 배포를 자동화했습니다. 수집 서비스는 웹과 별도 컨테이너로 띄워, 수집 부하가 웹 응답에 영향을 주지 않게 분리했습니다.

운영 환경

수집 작업의 성공과 실패, 처리 건수를 기록해 두고 상태를 확인합니다. 수집은 사람이 보고 있지 않을 때 실행되는 작업이므로, 기록이 없으면 문제가 생겨도 사용자가 문의하기 전까지 알 수 없습니다. 작업 이력을 남기는 것이 별도의 모니터링 도구를 붙이는 것보다 먼저 필요한 조치였습니다.

배포는 웹과 수집 서비스를 각각의 컨테이너로 올립니다. 수집 로직을 고쳐도 웹은 재배포하지 않고, 반대의 경우도 마찬가지입니다. 플랫폼 화면 변경 대응처럼 수집 쪽 수정이 잦은 서비스에서는 이 분리가 배포 부담을 줄여 줍니다.

기술 선택의 기준

이 서비스에서 가장 자주 깨지는 지점은 수집입니다. 그래서 기술 선택의 기준도 "깨졌을 때 어디가 깨졌는지 알 수 있는가"였습니다. 수집을 웹과 분리된 서비스로 두면 수집 장애가 웹 응답에 영향을 주지 않고, 작업을 큐에 넣으면 실패한 단위를 특정할 수 있습니다. 스키마를 공용 패키지로 분리하면 두 서비스가 서로 다른 구조를 가정하는 상황이 생기지 않습니다.

반대로 웹 쪽은 단순하게 유지했습니다. 리뷰 목록과 답변 작성은 복잡한 상태 관리가 필요한 화면이 아니고, 사장님이 쓰는 도구는 빠르게 뜨는 편이 낫습니다.

구현하면서 다룬 문제

플랫폼 화면 변경. 공개 API가 없는 수집은 플랫폼 화면 구조에 의존합니다. 화면이 바뀌면 수집이 깨지고, 그 사실을 사용자보다 먼저 알아야 합니다. 작업 실패를 상태로 남기고 재시도와 구분해 기록한 이유입니다.

중복 수집. 같은 리뷰를 여러 번 저장하면 통계가 어긋납니다. 마지막 수집 시점을 기준으로 범위를 정하고, 저장 단계에서도 중복을 확인합니다.

수집과 응답의 분리. 수집은 수십 초에서 수 분이 걸립니다. 이를 웹 요청 안에서 처리하면 화면이 멈춥니다. 요청은 작업 등록까지만 하고, 결과는 이후에 반영되도록 나눴습니다.

응답 품질의 일관성. 생성된 답변이 매번 다른 성격으로 나오면 매장의 목소리가 흔들립니다. 매장 단위로 응답 톤을 저장해, 생성 요청마다 같은 기준이 적용되도록 했습니다.

수집 부하 조절. 여러 매장의 수집이 같은 시각에 몰리면 플랫폼 쪽에서 비정상 접근으로 판단할 수 있습니다. 작업을 큐에 넣고 순차 처리하는 구조는 기능 분리뿐 아니라 요청 속도를 조절하는 역할도 합니다.

알림의 양. 모든 리뷰를 알리면 알림이 무시됩니다. 조건을 매장이 직접 정하게 한 이유는, 어떤 리뷰가 급한지는 업종과 운영 방식에 따라 다르기 때문입니다.

6. 프로젝트 정보

항목	내용
사업명	리뷰 AI (웹/앱, 자동 답변) 개발
담당 범위	기획, 웹·수집 서비스 개발, 결제 연동
적용 기술	Next.js, React, Node.js, Express, BullMQ, Redis, Prisma, PostgreSQL, Docker, 토스페이먼츠