해커가 아니라 ‘봇’이 돈을 버는 구조
리워드·쿠폰 자동화 악용
“이벤트 참여자가 이렇게 많을 리가 없는데요?”
신규 고객 확보를 위해 출석 이벤트와 쿠폰 프로모션을 진행한 한 식음료 앱.
오픈 첫 주, 내부 대시보드는 화려했습니다.
- 이벤트 참여 수 급증
- 쿠폰 사용률 폭발
- DAU·MAU 상승
하지만 한 달 뒤, 숫자는 다른 이야기를 하기 시작합니다.
- 매출은 그대로인데
- 마케팅 비용만 급증
- 정상 고객의 쿠폰 사용률은 오히려 하락
이벤트를 즐긴 건 고객이 아니라 ‘봇’이었습니다.
왜 리워드·쿠폰 자동화가 위험할까?
이 공격의 가장 큰 문제는 이것입니다.
“해킹처럼 보이지 않는다”
리워드 자동화의 특징
- 정상 사용자 행동과 거의 동일
- 서버 요청도 정상
- 결제·로그인 오류 없음
즉, 보안 사고처럼 보이지 않는 비즈니스 파괴 행위입니다.
실제 사례: 에뮬레이터 농장이 만든 가짜 고객
한 멤버십 기반 식음료 앱에서 실제로 발생한 사례입니다.
발견된 현상
- 특정 시간대에 출석 체크 폭증
- 신규 계정 생성 패턴 반복
- 동일한 행동 흐름이 수백 개 계정에서 동시 발생
조사 결과
- 에뮬레이터 수십 대 동시 실행
- 매크로로 자동 클릭
- 출석 → 미션 → 쿠폰 발급 → 포인트 적립
- 일부는 바로 중고 마켓에서 쿠폰 판매
사람이 아니라 ‘자동화 환경’이 이벤트를 수확하고 있었습니다.
공격 방식은 이렇게 진행됐다
1) 에뮬레이터 다중 실행
- 실제 안드로이드 단말처럼 위장
- 기기 ID·OS 정보 랜덤화
2) 매크로·자동 입력
- 출석 버튼 자동 클릭
- 이벤트 참여 자동화
- 반복 계정 생성
3) 서버는 전부 정상 처리
- 로그인 성공
- 이벤트 참여 정상
- 쿠폰 발급 정상
서버 입장에선 “정상 사용자의 정상 요청”
보안의 문제는 어디에 있었을까?
문제는 명확했습니다. “앱이 실행되는 환경과 입력 주체를 검증하지 않았다”
구체적인 보안 공백
- 에뮬레이터 실행 차단 없음
- 자동 입력·비정상 터치 탐지 부재
- 동일 행동 반복 패턴에 대한 클라이언트 검증 없음
- 앱 무결성·신뢰도 기반 제한 미적용
즉, ‘사람이 누른 버튼’이라는 전제를 믿은 것이 문제였습니다.
LIAPP은 어떻게 방어했는가
리워드 자동화는 서버보다 ‘앱 레벨’에서 먼저 차단해야 합니다.
- 에뮬레이터 실행 환경 탐지
- 루팅·가상화·후킹 환경 감지
- 비정상 환경에서 앱 실행 제한
- 동일 좌표 반복 터치
- 비현실적인 반응 속도
적용 이후, 어떤 변화가 있었을까?
보안 적용 후 결과는 즉각적이었습니다.
- 에뮬레이터 기반 참여 거의 0
- 쿠폰 남용 중단
- 마케팅 비용 정상화
- 실제 사용자 혜택 체감도 상승
무엇보다 중요한 변화는 이것입니다.
“리워드는 비용이 아니라 ‘신뢰 기반 보상’이라는 인식”
식음료 앱이 얻어야 할 교훈
리워드·쿠폰은 고객에게는 혜택이지만 플랫폼에는 현금과 동일한 자산입니다.
그리고 이 자산은 서버보다 먼저 여기서 지켜야 합니다.
- 실행되는 앱
- 입력하는 손
- 보여지는 화면
식음료 앱 교훈
배달·멤버십 앱의 사고는 서버에서 시작되지 않는다. 주문을 만드는 ‘앱’, 누르는 ‘손’, 보이는 ‘화면’에서 시작된다. 이 3가지는 선택이 아니라, 식음료 앱 운영의 기본 방어선입니다.
#식음료앱보안 #배달앱보안 #리워드악용 #쿠폰자동화 #매크로공격 #에뮬레이터 #마케팅비용 #포인트보안 #멤버십앱 #모바일보안 #앱무결성 #자동화차단 #LIAPP #LISS #LIKEY
