밴더사 선정 기준: 라이선스, 공정성 인증, 기술력 비교 분석

Table of Contents

진단: 밴더사 선정은 ‘기능 비교’가 아니라 ‘정산·장애·분쟁 비용’의 비교다

밴더사 선정에서 가장 흔한 착각은 “콘텐츠가 많고 UI가 예쁘면 된다”로 귀결된다. 운영을 시작하면 관심사는 즉시 바뀐다. 트랜잭션 누락이 발생했을 때 누가 책임지는지, 장애 시 롤백이 가능한지, 외부 감사가 들어오면 로그와 증적을 어떤 형식으로 제출할 수 있는지가 손익을 갈라놓는다. 매출이 커질수록 리스크가 기하급수로 커지는 구조라서, 초기에 싼 밴더를 고르는 순간 미래의 사고 비용을 선결제하는 셈이 된다.

라이선스와 공정성 인증은 “있으면 좋은 옵션”이 아니다. 결제대행·은행·광고 네트워크·클라우드 사업자와의 관계에서 신뢰의 담보로 작동한다. 기술력은 더 노골적이다. 피크 타임에 초당 1,000건 트랜잭션을 처리하는 순간, 작은 설계 차이가 장애 빈도와 고객 이탈률을 결정한다. 운영자가 원하는 건 정의가 아니라 ‘끊겨도 돈이 안 새는 구조’다. 밴더 평가 프레임을 그 기준으로 재정렬해야 한다.

이 글은 밴더사의 라이선스, 공정성 인증, 기술력을 각각 따로 설명하지 않는다. 실제 현장에서 이 세 요소가 어떻게 연결되어 운영 안정성과 수익성에 영향을 주는지, 계약서와 아키텍처 수준에서 무엇을 확인해야 하는지로만 간다. 결국 선택 기준은 “문서가 그럴듯한가”가 아니라 “사고가 났을 때 살아남는가”다.

본론 1: 라이선스는 ‘합법성’보다 ‘거래 가능성’과 ‘출구 전략’을 보장한다

라이선스 검증을 단순히 국가명과 번호 확인으로 끝내면 사고가 난다. 운영 관점에서 라이선스는 세 가지 기능을 한다. 첫째, 결제·정산 파트너가 요구하는 최소 신뢰 요건을 충족한다. 둘째, 분쟁 시 관할과 준거법이 명확해져 소송 가능성이 생긴다. 셋째, 밴더가 퇴장하거나 계약이 파기될 때 데이터와 시스템을 이관할 수 있는 ‘출구’가 생긴다. 이 셋 중 하나라도 빠지면, 플랫폼은 기술적으로는 돌아가도 사업적으로는 고립된다.

관할 조항도 비용을 좌우한다. 해외 관할로 묶인 계약에서 분쟁이 발생하면, 특히는 소송을 못 한다고 봐야 한다. 그 순간부터 운영자는 기술적 하자에 대한 보상 대신 “서비스 중단 없이 버티는 것”만이 목표가 된다. 라이선스는 법적 문서이면서 동시에 운영 리스크를 가격으로 환산하는 장치다.

라이선스 실사에서 빠지기 쉬운 포인트

라이선스 범위: 배포 지역, 언어, 플랫폼(웹/모바일), 리셀 권한, 서브라이선스 가능 여부
기간과 갱신: 자동 갱신인지, 갱신 거절 시 데이터·서비스 처리 방식
감사 권한: 밴더가 제공해야 하는 로그·리포트의 형태와 제출 기한
IP 귀속: 커스터마이징한 코드, UI, 운영 데이터의 소유권과 사용권
제3자 구성요소: RNG, 결제 모듈, 분석 SDK 등 외부 컴포넌트의 라이선스 체인

가령 제3자 구성요소는 함정이 많다. 밴더는 “우리 솔루션은 문제 없다”고 말반면에, 실제로는 RNG 모듈이 다른 회사 제품이고, 로그 수집은 또 다른 SaaS를 붙여 쓰는 경우가 흔하다. 한 군데라도 계약 체인이 끊기면, 서비스는 정상이라도 파트너 심사에서 탈락한다. 라이선스는 문서 검증이 아니라 공급망 검증이다.

본론 2: 공정성 인증은 ‘마케팅 배지’가 아니라 ‘감사 가능성’과 ‘사후 재현성’의 문제다

공정성 인증을 요구하는 이유는 사용자 신뢰만이 아니다. 운영자는 사건이 터졌을 때 “우리는 시스템적으로 조작이 불가능했다”를 증명해야 한다. 공정성 인증의 핵심은 RNG 자체의 품질보다, RNG가 실제 운영 환경에서 어떻게 호출되고 어떤 시드(seed)와 상태(state)로 실행됐는지의 재현 가능성이다. 인증서 한 장으로 끝나는 게 아니라, 운영 로그와 증적 체계가 인증의 일부가 된다.

현장에서 흔히 보는 실패 패턴이 있다. 인증은 받았는데 운영 환경에서는 설정이 달라져 있다. 개발·스테이징·프로덕션의 빌드가 다르고, 특정 이벤트 트래픽을 처리하려고 임시 패치를 넣었는데 그게 인증 범위를 벗어난다. 감사가 들어오면 인증은 무력해진다. 공정성 인증은 “인증된 바이너리가 운영에 배포되었고, 그 상태가 유지되었다”를 증명하는 체계까지 포함해야 한다.

인증기관의 이름만 보는 것도 위험하다. 중요한 건 인증 범위와 테스트 방법론이다. 통계적 검정(예: 분포 적합성)만 했는지, 소스 코드 리뷰와 빌드 재현성까지 포함했는지, 운영 로그의 무결성 검증까지 다뤘는지에 따라 실효성이 갈린다. 운영 리스크 관점에서 공정성 인증은 ‘분쟁 비용’을 줄이는 보험이고, 보험은 약관이 전부다.

공정성 인증에서 운영자가 요구해야 하는 산출물

테스트 리포트 원문: 표본 크기, 검정 방법, 유의수준, 실패 케이스 처리 방식
버전 고정 정보: 해시값, 빌드 환경, 의존성 버전, 컴파일 옵션
운영 적용 증적: 배포 시점, 배포 대상, 변경 승인 기록, 롤백 기록
로그 무결성 설계: WORM 스토리지 또는 해시 체인 기반의 변경 불가능 로그
재현 절차: 특정 트랜잭션 ID로 결과를 재계산할 수 있는지 여부

재현 절차가 없으면 분쟁이 장기화된다. 장기화는 곧 비용이다. 고객 응대 비용, 결제 차지백, 파트너 신뢰 하락, 내부 인력 소모가 동시에 발생한다. 공정성 인증은 기술 문서이면서 운영 조직의 시간을 아껴주는 문서다.

본론 3: 기술력 비교의 본질은 TPS가 아니라 ‘실패 모드’와 ‘정산 일관성’이다

기술력 비교에서 데모 화면과 기능표는 거의 의미가 없다. 운영에 영향을 주는 건 실패 모드다. 네트워크가 끊겼을 때 트랜잭션이 중복 처리되는지, 지연 처리되는지, 누락되는지. 장애가 발생하면 자동 복구가 되는지, 수동 개입이 필요한지. 장애가 났을 때 가장 무서운 건 다운타임이 아니라 정산 불일치다. 다운은 눈에 띄지만 불일치는 뒤늦게 터진다. 그때는 이미 로그가 사라졌거나, 데이터가 서로 다른 시스템에 흩어져 복구가 불가능한 경우가 많다.

밴더 기술력을 보려면 아키텍처 질문을 던져야 한다. “DB는 무엇을 쓰나요” 같은 질문은 피상적이다. “트랜잭션 상태 머신이 있나요”. “idempotency key를 강제하나요”, “정산 원장(ledger)을 별도로 유지하나요”가 핵심이다. 특히 결제와 결과 처리 사이에 비동기 큐가 들어가는 구조에서는 exactly-once 처리가 불가능하다는 전제를 받아들이고, at-least-once에서 중복을 제거하는 설계를 갖고 있는지 확인해야 한다.

성능 수치도 맥락이 필요하다. 초당 5,000 TPS를 처리한다는 말은 쉬운데, 그 TPS가 “읽기”인지 “쓰기”인지, 트랜잭션 커밋까지 포함인지, 외부 API 호출까지 포함인지에 따라 의미가 달라진다. 운영자 입장에서 중요한 건 피크 타임에서 p95 latency가 200ms인지 2초인지, 타임아웃이 발생했을 때 재시도가 폭증하며 스노우볼이 되는지다. 결국 기술력은 숫자가 아니라 안정성 곡선이다.

기술 실사에서 반드시 확인할 설계 항목

트랜잭션 원장: 변경 불가능한 append-only ledger가 있는지, 수정은 보정 트랜잭션으로만 가능한지
정합성 모델: 강한 일관성 vs 최종 일관성, 정산 마감 시점에 어떤 보정 프로세스를 쓰는지
중복 방지: idempotency key, 요청 서명, 재시도 정책, 중복 처리 시 사용자 경험 설계
장애 격리: 멀티 리전, 셀 아키텍처, 서킷 브레이커, 레이트 리미트 정책
관측 가능성: 분산 트레이싱, 상관관계 ID, 로그 샘플링 정책, 알람 임계치
보안: 키 관리(KMS/HSM), 시크릿 로테이션, 권한 분리, 감사 로그
배포 전략: 블루그린/카나리, 롤백 시간, 스키마 마이그레이션 방식

원장 설계가 없는 밴더는 정산 사고에 취약하다. 운영자가 원하는 건 “데이터가 맞다”가 아니라 “데이터가 틀렸을 때 어디서부터 틀렸는지 추적 가능하다”다. 추적 가능성이 없으면 운영팀은 야근으로 메운다. 야근은 비용이고, 비용은 마진을 갉아먹는다. 기술력 비교는 결국 마진 방어 전략이다.

결론: 라이선스·인증·기술은 분리 항목이 아니라 하나의 리스크 체인이다

라이선스가 약하면 파트너십이 막히고 문제가 생겨도 책임을 강제할 수 없으며, 밴더사 연동 엔진의 지연을 줄이기 위한 데이터 파이프라인 구조가 뒷받침되지 않으면 공정성 인증이 약해져 분쟁 대응에 시간을 소모하고 그 시간은 곧 현금 유출로 이어진다. 기술력이 부족한 환경에서는 장애와 정산 불일치가 반복되고, 반복은 신뢰를 파괴한다. 이 셋은 서로 다른 체크박스가 아니라 하나의 체인으로 연결돼 있으며, 체인의 약한 고리가 실제 비용이 된다.

밴더 선정은 “최고 사양”을 고르는 작업이 아니다. 운영자가 감당 가능한 실패 범위를 정의하고, 그 범위 안에서 SLA와 증적 체계를 계약으로 고정하는 작업이다. 문서가 완벽해도 시스템이 약하면 사고가 난다. 시스템이 좋아도 문서가 약하면 보상을 못 받는다. 둘 다 갖춘 밴더는 비싸 보이지만, 사고가 한 번만 나도 비용 구조가 역전된다.

실무에서는 최종 후보 2~3개를 놓고 기술 PoC를 돌리되, 성능 테스트보다 실패 테스트를 더 많이 해야 한다. 네트워크 지연, 패킷 드롭, 외부 API 타임아웃, DB 락, 큐 지연을 의도적으로 넣고 정산 원장이 어떻게 남는지 확인하는 방식이다. 밴더가 이 테스트를 불편해한다면, 운영 단계에서 더 불편한 일이 생긴다.

밴더사 선정 체크리스트(운영 리스크 기준)로 정리한다.

라이선스 체인: 원개발사까지 계약 권한이 이어지는지, 관할·준거법·감사 조항이 실효적인지

SLA: 업타임 99.9% 같은 문구가 아니라 RTO/RPO, 장애 보상, 장애 보고 기한이 명시되는지

정산 원장: append-only 원장과 보정 트랜잭션 체계가 있는지, 마감 리포트가 재현 가능한지

중복/누락 방지: idempotency, 재시도 정책, 타임아웃 시 사용자 상태 처리 규칙이 문서화됐는지

공정성 인증 산출물: 리포트 원문, 버전 해시, 운영 배포 증적, 로그 무결성 설계가 제공되는지

관측 가능성: 트랜잭션 ID로 end-to-end 추적이 가능한지, 알람이 ‘장애 전’에 울리는지

보안 운영: 키 로테이션, 권한 분리, 접근 통제, 감사 로그 보관 기간이 계약에 들어가는지

출구 전략: 계약 종료 시 데이터 덤프 포맷, 이관 지원 범위, 소스/설정 인계 범위가 정의되는지

이 항목 중 하나라도 “우린 보통 그렇게 안 한다”는 답이 나오면, 가격 협상보다 리스크 프리미엄을 먼저 계산해야 한다. 싸게 시작해서 비싸게 수습하는 패턴이 가장 흔한 실패다.