거래 건수도 맞고, 승인 로그도 정상인데 총 정산 금액이 계속 안 맞아요
결제 및 정산 API 조작
월말 정산을 마친 어느 날, 회계 담당자가 조심스럽게 말을 꺼냅니다.
“거래 건수도 맞고, 승인 로그도 정상인데 총 정산 금액이 계속 안 맞아요.”
서버 로그를 봐도 이상은 없습니다. 결제 승인도 정상, 취소도 없음, 오류도 없음.
하지만 숫자는 조금씩 어긋나고 있었습니다. 하루에 몇 백 원, 몇 천 원. 눈에 띄지 않을 만큼의 아주 작은 금액 차이.
이게 바로 결제·정산 API 변조 사고의 가장 무서운 특징입니다.
왜 결제·정산 API 변조는 ‘최악’일까?
이 공격이 치명적인 이유는 단순합니다.
✔ 서버는 끝까지 “정상”이라고 말한다
- 승인 요청 정상
- 결제 응답 정상
- 로그·통계 정상
✔ 피해는 작고, 느리고, 누적된다
- 소액 반복 탈취
- 수개월간 인지되지 않음
- 발견 시 이미 회수 불가
눈에 띄지 않게, 그러나 확실하게 돈이 새어 나간다.
실제 공격은 어떻게 일어났을까?
사고가 발생한 서비스는 POS와 정산, 세금계산서까지 연동된 비즈니스 앱이었습니다.
공격 흐름은 이랬습니다
- 위험한 앱 실행 환경 확보
- 루팅 단말
- 에뮬레이터
- 후킹 툴 실행
- 네트워크 후킹
- HTTPS 자체는 유지
- 앱 내부 요청·응답 가로채기
- API 파라미터 미세 조작
- 결제 금액
- 수수료 비율
- 정산 대상 금액
- 소액 반복 탈취
- 1건당 몇 백 원
- 하루 수십 건
- 수개월 누적
서버 입장에서는 “정상 사용자가 정상 결제를 한 것”으로만 보였습니다.
보안의 진짜 문제는 무엇이었을까?
이 사고의 핵심은 명확합니다.
“API는 보호했지만, API를 호출하는 ‘앱’을 신뢰해버렸다.”
구체적인 보안 공백
- 변조된 앱에서도 API 호출 가능
- 네트워크 후킹 환경 탐지 불가
- 요청 파라미터 무결성 검증 부재
- 정상 로그인 상태면 모든 결제 허용
즉, 서버는 철저했지만 클라이언트는 무방비였습니다.
LIAPP · LIKEY는 어떻게 방어했는가
이 문제는 서버 로직을 더 복잡하게 만들어서 해결되지 않습니다.
“이 요청이 어떤 환경에서 만들어졌는가” 를 먼저 검증해야 합니다.
- 루팅·에뮬레이터 환경 탐지
- 네트워크 후킹 도구 실행 감지
- 앱 메모리·코드 무결성 검증
- 변조 환경에서 앱 실행 차단
결제 권한을 ‘로그인 여부’가 아니라 ‘환경 신뢰도’로 결정
적용 이후, 어떤 변화가 있었을까?
보안 적용 이후 결과는 분명했습니다.
- 결제·정산 금액 불일치 즉시 중단
- 월별 누적 손실 차단
- 회계·감사 리스크 감소
- 정산 관련 CS·분쟁 급감
무엇보다 큰 변화는 이것이었습니다.
“결제 사고는 서버 문제가 아닐 수 있다”는 인식 전환
이 사례가 주는 교훈
결제·정산 사고는 대부분 해킹처럼 보이지 않습니다.
- 알람도 없고
- 장애도 없고
- 로그도 정상입니다.
그래서 더 위험합니다.
비즈니스 앱 보안 사고의 80%는 서버가 아니라 ‘앱 실행 환경·입력·화면’에서 시작됩니다.
결제 API를 지키는 가장 현실적인 방법은 API 앞단의 ‘앱’을 먼저 지키는 것입니다.
그래서 LIAPP · LISS · LIKEY는 비즈니스 앱에서 선택이 아니라 업무 인프라가 됩니다.
#비즈니스앱보안 #결제보안 #정산보안 #API보안 #POS보안 #세무앱 #정산사 고#금융사고 #모바일보안 #앱보안 #후킹공격 #API변조 #LIAPP #LISS #LIKEY
