가입, 로그인, 주문, 결제, 정산 같은 금융성 행동은 서비스 입장에서 매 순간 '승인할지 막을지'를 정해야 하는 의사결정의 연속이다. 핀테크·커머스·마켓플레이스가 커질수록 이 판단을 사람이 일일이 보는 것은 불가능해지고, 그래서 사다인(Sardine), 시프트(Sift), 리스키파이드(Riskified), SEON 같은 상용 사기 방지 솔루션에 의존하게 된다. 파이닉(Finic)이 공개한 오픈소스 플랫폼 카이로스(Kairos)는 바로 이 영역을 겨냥한 아파치 2.0 라이선스 대안으로, 상용 제품과 같은 실시간 판정 기능을 제공하면서 두 가지 차별점을 내세운다. 운영 튜닝을 코딩 에이전트가 맡는다는 점, 그리고 학습용 라벨이 쌓이기 전에도 사기를 잡아낸다는 점이다.
무엇을 하는 도구인가
동작 구조 자체는 명확하다. 서비스에서 일어나는 이벤트(가입, 로그인, 주문, 정산, 차지백 등)를 카이로스로 보내면, 카이로스는 각 요청에 대해 승인(approve), 추가 인증(step up), 검토(review), 차단(block) 중 하나로 판정을 내린다. 중요한 설계는 모든 판정을 그 판단의 근거가 된 신호(signal)와 함께 보관한다는 점이다. 사기 방지 시스템에서 실무자가 가장 답답해하는 부분이 '왜 이 건을 막았는가'를 사후에 설명하지 못하는 것인데, 결정과 근거를 함께 남기면 분쟁 대응과 오탐 분석, 그리고 내부 감사 대응이 수월해진다.
가장 눈에 띄는 주장은 운영 주체에 대한 것이다. 카이로스는 MCP(Model Context Protocol)를 통해 클로드 코드(Claude Code), 커서(Cursor), 코덱스(Codex) 같은 에이전트를 연결할 수 있고, 연결된 에이전트가 사실상 사기 방지 ML 엔지니어가 하던 일을 대신하도록 설계됐다. 콘솔의 설정에서 MCP 도구 그룹을 켜고 키를 발급한 뒤 에이전트에게 "내 판정 기록을 살펴봐", "워크플로를 만들어", "실험을 돌려봐"라고 지시하는 방식이다. 규칙 튜닝과 실험 설계라는, 전통적으로 전문 인력이 전담하던 작업을 자연어 지시로 옮기려는 시도다.
결정 모델과 전통 ML의 결합
카이로스의 핵심 엔진은 파이닉의 결정 모델(decision model) '그레이슨(Grayson)'이다. "배송지가 재배송업자(reshipper)처럼 보이는가?", "이 이메일은 일회용 주소인가?" 같은 질문을 평문으로 던지면, 그레이슨은 보정된 확률(calibrated probability)로 답한다. 이 접근의 장점은 명확하다. 전통적인 지도학습 모델은 충분한 양의 라벨(사기로 확정된 사례)이 쌓여야 비로소 쓸만해지는데, 신규 서비스나 새로운 공격 패턴에는 그 라벨이 없다. 결정 모델은 라벨이 없는 초기 단계, 즉 콜드 스타트 구간에서 강점을 가진다.
다만 카이로스는 결정 모델만으로 모든 것을 해결한다고 주장하지 않는다. 오히려 전통적인 ML이 강한 지점을 분명히 인정한다. 자사 데이터로 자사의 실제 결과를 정밀하게 학습하고, 한 번 학습해 두면 건당 추론 비용이 들지 않는다는 점이다. 그래서 카이로스는 둘을 결합한다. 그레이슨의 답을 하나의 피처(feature)로 삼아 서비스 자체 필드와 나란히 놓고 로지스틱 회귀나 그래디언트 부스팅 트리(XGBoost 호환, 카이로스 내부에서 학습)에 투입한다. 그리고 어떤 조합이 자기 데이터에서 더 나은지는 실험으로 가린다. 범용 모델의 콜드 스타트 대응력과 자체 모델의 정밀도·비용 효율을 양쪽 다 취하려는 구성이다.
도입과 운영의 현실
시작 경로는 두 갈래다. 매니지드로 쓰려면 kairos.finic.ai에서 샌드박스 환경과 비밀 키를 만들면 바로 이벤트를 보낼 수 있다. 직접 운영하려면 Node.js 22, pnpm 10, 그리고 portal.finic.ai에서 발급받는 그레이슨 API 키가 필요하다. 별도 데이터베이스를 세팅할 필요는 없는데, 서버가 자체 포스트그레스(Postgres)를 띄우기 때문이다. 팀 단위로는 docker compose up --build로 올릴 수 있고, 셀프 호스팅과 로컬 셋업 문서가 함께 제공된다. 문서는 kairos.finic.ai/docs와 저장소의 docs 폴더에 있다.
실무자 입장에서 분명히 짚어둘 한계도 있다. 결정 모델 그레이슨은 파이닉의 API 키를 요구하므로, 오픈소스 코드 자체는 자유롭게 열 수 있어도 핵심 판정 능력은 외부 서비스에 의존한다. 완전한 자체 통제를 전제로 셀프 호스팅을 고려한다면 이 의존 구조와 건당 비용 모델을 먼저 확인해야 한다. 또한 '에이전트가 ML 엔지니어를 대체한다'는 메시지는 매력적이지만, 사기 방지는 오탐 하나가 정상 고객 이탈로, 미탐 하나가 실제 손실로 이어지는 민감한 영역이다. 에이전트가 제안한 워크플로와 실험 결과를 그대로 신뢰하기보다는, 판정 근거가 함께 저장된다는 이점을 활용해 사람이 검증하고 승인하는 절차를 설계하는 편이 안전하다. 상용 대안을 당장 걷어내기 위한 도구라기보다, 라벨이 부족한 초기 서비스나 새로운 사기 유형을 빠르게 실험해 보려는 팀이 먼저 검토해 볼 만한 선택지다.