주제로 보기

신뢰

글과 패턴 15편

Cedar는 누가 접근할 수 있는지를 증명합니다. 어떤 결정이 내려질지는 누가 증명하나요?

Cedar는 Lean과 automated reasoning으로 권한 정책에 formal verification을 붙였습니다. 같은 일을 비즈니스 결정에 해낸 상용 룰 엔진은 아직 없습니다. 가격과 자격 판정과 사기 규칙을 증명하는 쪽이 왜 더 어려운 문제인지, 그리고 LexQ가 지금 어디에 서 있는지 적습니다.

2026년 8월 7일10분 읽기

블로그

비즈니스 결정에 형식 검증이 필요한 이유

테스트와 시뮬레이션은 이미 받아본 입력만 놓고 답합니다. 아직 아무도 보내지 않은 입력은 답의 범위 밖입니다. 도달 불가능한 규칙, 조용한 충돌, 아무 규칙도 덮지 않는 공백이 그 차이 안에 있습니다. 이 차이는 표본이 아니라 증명으로만 메워집니다.

2026년 8월 7일11분 읽기

패턴

차단 규칙으로 연령·지역별 보험 가입 자격 검증하기

주 인가가 바뀔 때마다 코드 세 곳을 고치는 대신, 가입 자격 검증을 규칙 넷으로 옮겨 거절 사유를 신청 단위로 남깁니다.

2026년 7월 20일13분 읽기

블로그

요금제 기능과 한도를 하드코딩하지 마세요: Feature Flag와 Entitlement는 다릅니다

요금제 등급을 if (plan == PRO)로 코드에 박으면 가격 변경 하나하나가 배포가 됩니다. Feature Flag에 entitlement를 담으면 안 되는 이유와, 새 요금제 등급을 배포 없이 규칙 변경으로 다루는 방법을 정리했습니다.

2026년 7월 15일11분 읽기

패턴

실행 시점 봉인으로 구독 일할 계산 증명하기

플랜 변경 한 건마다 요금 처리 방식을 정하고, 몇 달 뒤 분쟁이 걸려도 어느 정책 버전에서 나온 청구인지 증명하는 패턴.

2026년 7월 7일17분 읽기

블로그

감사 추적의 문제: 어떤 규칙이 어떤 결정을 내렸는지 증명하기

막힌 이체 하나가 로그에 남기는 건 한 줄뿐입니다. 몇 달 뒤 감사관이 이유를 묻지만 git은 답하지 못합니다. 코드의 이력은 남겨도 결정의 이력은 남기지 않기 때문입니다. 제대로 된 결정 감사 추적이 무엇을 기록하고, 왜 불변이어야 하는지 설명합니다.

2026년 7월 5일9분 읽기

블로그

의사결정 운영 플랫폼이란 무엇이고, 언제 필요한가

가격, 자격 판정, 사기 탐지 같은 비즈니스 결정은 자주 바뀌지만 애플리케이션 코드에 묶여 있습니다. 의사결정 운영 플랫폼은 이 결정에 고유한 라이프사이클을 줍니다. 이 카테고리가 무엇이고, 언제 필요한지 설명합니다.

2026년 6월 29일9분 읽기

패턴

차단 규칙으로 요금제 등급별 기능 권한 결정하기

코드 곳곳에 흩어진 요금제 등급 검사를 한곳의 차단 규칙으로 모으고, 막힌 기능 접근마다 사유가 남게 만드는 패턴.

2026년 6월 29일15분 읽기

블로그

핀테크를 위한 룰 엔진: 한도, 심사, 승인 결정

핀테크의 한도, 심사 기준, 승인 결정은 규제가 바뀔 때마다, 리스크 모델이 바뀔 때마다 함께 바뀌고, 서비스 코드에 박아 넣으면 감사에서 무너집니다. 이 규칙들을 어디에 둬야 하는지, 코드에 박아 넣은 방식이 왜 감사를 통과하지 못하는지, 배포 없이 한도를 바꾸는 방법.

2026년 6월 25일13분 읽기

패턴