GoRules vs Nected vs LexQ: 2026년 룰 엔진 선택 가이드

이 비교를 쓰는 이유

아래 GoRules와 Nected 정보는 2026년 9월 30일에 두 회사의 공식 페이지와 문서를 보고 적었습니다. 가격과 플랜은 자주 바뀌니, 고르기 전에 가격 페이지를 한 번 더 열어 보세요.

2026년에 룰 엔진을 찾아보면 결국 같은 세 이름 앞에 서게 됩니다. GoRules, Nected, LexQ입니다. 검색 결과에서든 동료의 추천에서든 이 셋은 빠지지 않습니다.

표면은 닮았습니다. 셋 다 클라우드를 기반으로 하고, 비즈니스 규칙을 애플리케이션 코드에서 떼어내겠다고 약속하고, 무료 플랜이 있습니다. 소개 페이지 첫 화면만 훑으면 세 제품이 같은 일을 한다고 생각하기 딱 좋습니다. 선택을 가르는 것은 그 아래입니다.

이해관계를 먼저 밝히겠습니다. 저는 LexQ를 만든 사람입니다. 편향이 있습니다. 그래도 다른 제품이 더 강한 영역은 그대로 쓰겠습니다. 그렇게 쓰지 않으면 이 글을 읽을 이유가 없기 때문입니다.

이 글은 마케팅 페이지를 비교 글로 위장한 것이 아닙니다. 제가 제품을 만들기 시작할 무렵에 누군가 써 뒀으면 했던 종류의 분석입니다.

아키텍처: 임베디드와 API

가장 근본적인 축입니다. 시뮬레이션도, 버저닝도, 가격 구조도 전부 여기서 갈라져 나옵니다. 이 절을 먼저 읽어야 나머지가 이해됩니다.

GoRules의 중심은 오픈소스 의사결정 엔진인 ZEN Engine입니다. ZEN Engine은 Rust로 만들었고, MIT 라이선스로 공개돼 있습니다. 쓰는 방법은 두 가지입니다. Rust, Node.js, Python, Go, Java, Kotlin, C#, Swift용 SDK로 애플리케이션에 넣어 쓰거나, GoRules Agent라는 독립 REST 서비스로 띄웁니다. 규칙 포맷은 JDM(JSON Decision Model)이고, 설계가 잘 잡혀 있으며 이식성도 좋습니다.

엔진 바깥에서 규칙을 작성하고 테스트하고 릴리스하는 도구(BRMS)는 무료 플랜부터 있는 별도 제품입니다. 2026년 8월부터는 GoRules가 운영하는 관리형 클라우드로도 쓸 수 있고, 직접 설치해도 됩니다. 클라우드에서는 둘 중 하나를 고릅니다. 릴리스를 GoRules 서버에 올려 두고 HTTP로 평가하거나, 사용자의 오브젝트 스토리지로 보내 Agent나 SDK가 가져가 평가하게 합니다.

규칙이 어디서 실행되는지 완전히 통제하고 싶다면 GoRules가 맞습니다. 대신 직접 돌리는 부분은 프로비저닝과 스케일링, 유지보수까지 직접 맡습니다. Agent를 띄운 서버, SDK를 넣은 애플리케이션, 자체 호스팅이라면 BRMS와 그 데이터베이스까지입니다. 자체 호스팅과 관리형 사이의 판단은 그 자체로 긴 주제라 여기서 다루지 않고 오픈소스 엔진을 직접 운영할 때 떠안는 비용과 관리형이 대신 가져가는 몫에 따로 정리해 뒀습니다.

Nected는 자사 제품을 제품팀, 그로스팀, 기술팀을 위한 로우코드/노코드 룰 엔진이자 워크플로 플랫폼으로 소개합니다. 규칙은 비주얼 UI에서 정의하고, Nected 클라우드에서 돌리거나 자체 인프라에 설치해 돌립니다. 클라우드 플랜에서는 플랜마다 만들 수 있는 규칙 수가 정해져 있습니다.

LexQ는 비주얼 콘솔이 딸린 관리형 API입니다. 규칙은 콘솔에서 만들거나 CLI 또는 MCP로 만들고, 실행은 REST API가 받습니다. 정의와 실행과 배포를 셋으로 나눈 것은 의도한 설계입니다. 그래서 규칙을 바꿀 때 애플리케이션을 다시 배포하지 않습니다. 관리할 인프라가 없고, 플랜마다 만들 수 있는 규칙 개수가 정해져 있지 않고, 시뮬레이션이 모든 플랜에 들어 있습니다.

GoRules는 직접 호스팅할 수 있는 도구입니다. Nected는 가드레일이 있는 플랫폼입니다. LexQ는 안전망이 있는 API입니다.

시뮬레이션과 테스트

세 제품의 차이가 가장 크게 벌어지는 곳이고, 실제 선택도 대부분 여기서 갈립니다.

GoRules는 비주얼 에디터 안에 시뮬레이터를 두고 있습니다. JSON 입력 하나로 의사결정 그래프를 돌리고, 노드마다 어떻게 평가됐는지 트레이스로 봅니다. 기대 출력을 적은 테스트 케이스를 묶어 둘 수 있고, 실제로 들어온 요청을 그대로 테스트 케이스로 저장할 수도 있습니다.

문서와 API에서 찾을 수 없는 것이 두 가지입니다. 하나는 과거 실행 수천 건을 새 버전에 다시 돌려 운영 버전과 결과를 견주는 기능입니다. 마케팅 페이지에는 과거 사례를 다시 돌린다는 문구가 있지만, 그 일을 하는 기능이나 API 엔드포인트는 문서에 없습니다. 다른 하나는 라이브 트래픽을 두 버전에 나눠 보내는 기능입니다. 마케팅 페이지에는 A/B 테스트라는 말이 나오지만, 문서를 보면 환경 하나에는 한 번에 릴리스 하나만 올릴 수 있고, 같은 환경 안에서 트래픽을 나누는 방법은 나오지 않습니다.

Nected에서는 규칙을 스테이징 환경에 올려 시험합니다. 입력 하나로 바로 돌려 보거나, 입력과 기대 출력을 저장해 둔 테스트 모음을 돌립니다. 시험을 거치지 않은 규칙은 발행할 수 없습니다. 문서에서 찾을 수 없는 것은 GoRules와 같은 두 가지입니다. 과거 실행을 새 버전에 다시 돌려 보는 기능, 그리고 트래픽을 나누는 A/B 실험입니다. A/B 실험은 마케팅 페이지에만 소개돼 있습니다.

LexQ는 시뮬레이션을 발행 경로에 둡니다. 세 레이어로 나뉘어 있고, Free를 포함한 모든 플랜에서 그대로 씁니다.

1. 드라이런: 발행 전에 단일 입력으로 초안 버전을 테스트합니다. 어떤 규칙이 발동했는지, 충돌 해소에서 경쟁 탈락한 규칙은 무엇인지, 의사결정 트레이스 전체를 봅니다.
2. 변경 영향 시뮬레이션: 과거 실행 수천 건을 새 버전과 비교 기준 버전(보통 지금 운영 중인 버전)에 함께 돌립니다. 매칭률과 지표 변화량, 규칙별 통계를 나란히 놓고 비교합니다.
3. A/B 테스트: 라이브 트래픽을 두 규칙 버전으로 나눕니다. 90/10처럼 비율을 정해 실제 결과를 측정하고, 이긴 쪽을 정식 버전으로 승격합니다. 애플리케이션은 context.trafficKey에 고정된 키 하나를 실어 보내고, 비율을 바꿀 때 배포는 필요 없습니다.

판단 기준은 간단합니다. "이 규칙 변경이 프로덕션에서 문제를 일으킬까"가 주된 관심사인가요. 그렇다면 이 항목이 비교표의 다른 어떤 기능보다 중요합니다. 시뮬레이션이 있으면 규칙 변경은 도박에서 데이터 기반 의사결정으로 바뀝니다.

시뮬레이션을 부가 기능이 아니라 전제로 두고 설계한 이유는 룰 엔진에 시뮬레이션을 먼저 넣은 배경에 적어 뒀습니다.

충돌 해소

규칙이 늘어나면 같은 입력에 여러 규칙이 한꺼번에 매칭되는 상황을 반드시 만납니다. 그때 무엇이 이기는지 정하는 방식이 제품마다 다릅니다.

GoRules는 의사결정 테이블과 그래프 모델을 써서, 흐름을 눈에 보이게 설계하는 단계에서 충돌을 구조로 정리합니다.

Nected에서는 의사결정 테이블마다, 여러 행이 맞을 때 어떻게 처리할지(적용 정책)를 사용자가 고릅니다. 처음 맞은 행에서 멈추기, 맞는 행이 하나일 때만 결과 내기, 맞은 행을 테이블 순서대로 모두 모으기, 오름차순으로 모두 모으기, 모든 행을 평가하기의 다섯 가지입니다.

LexQ는 명시적 우선순위로 해소합니다. 서로 영향을 주는 규칙을 상호 배타 그룹으로 묶고, 한 버전 안에서 priority 값이 겹치지 않도록 강제합니다. 그래서 승자는 언제나 정확히 하나입니다.

일부러 넣지 않은 것도 있습니다. "가장 유리한 결과를 고르는" 전략입니다. 순서는 저작자가 정합니다. 값에서 추론하지 않습니다.

모든 결정은 전체 트레이스와 함께 기록됩니다. 어떤 규칙이 왜 선택됐는지, 다른 규칙은 왜 경쟁에서 탈락했는지까지 남습니다. 디버깅할 때 이 기록을 보고, 규제 준수 감사에서도 같은 기록을 그대로 냅니다.

버저닝과 배포

GoRules BRMS는 브랜치와 릴리스로 버전을 관리합니다. 릴리스마다 1.2.0 같은 유의적 버전(semantic versioning) 번호가 붙습니다. 사용자는 이 릴리스를 환경에 배포하고, 롤백할 때는 이전 릴리스를 다시 배포합니다. 릴리스와 버전 이력은 모든 플랜에 있습니다. 감사 로그는 Business 플랜(클라우드 월 결제 $600, 자체 호스팅 월 €500)부터이고, 배포 전에 반드시 승인을 거치게 하는 기능은 클라우드에서는 Enterprise 플랜에서 쓸 수 있습니다.

Nected의 규칙은 Draft에서 Published로 갑니다. 리뷰어를 지정해 제출하면 Draft와 Published 사이에 In Review 단계를 거칩니다. 승인 절차를 켜면 리뷰 요청이 기본값이 됩니다. 롤백은 이전 버전을 Draft에 덮어쓰는 방식이라, 그 뒤에 다시 Published로 올려야 합니다. 클라우드 플랜의 가격 비교표를 보면 버전 관리와 롤백, 승인 절차, 감사 기록은 Growth 플랜부터 쓸 수 있습니다.

LexQ는 Free를 포함한 모든 플랜에 Git 스타일 버저닝이 들어 있습니다. 규칙은 초안(DRAFT) 버전에서 고치고, 버전마다 커밋 메시지를 남길 수 있습니다. 초안을 발행하면 더는 고칠 수 없는 발행됨(ACTIVE) 버전이 됩니다. 이 버전을 배포하면 운영 중 버전이 되어 실제 트래픽을 받습니다. 문제가 보이면 직전에 배포한 버전으로 한 번에 롤백하고, 그 과정이 감사 추적에 전부 남습니다. 버전 관리를 쓰겠다고 플랜을 올릴 일은 없습니다.

AI 에이전트 연동

2년 전이라면 비교 항목에 넣지도 않았을 주제입니다. 2026년에는 사정이 다릅니다.

GoRules는 프로젝트마다 AI 어시스턴트(GoRules AI)를 붙여 주고, MCP 서버도 따로 제공합니다. 클라우드에서는 Free를 포함한 모든 플랜에 매달 AI 크레딧이 나오고, Free 플랜 몫은 $10 상당입니다. 자체 호스팅이라면 AI 코파일럿과 LLM 연동은 Enterprise 플랜에 들어 있습니다.

Nected 워크플로의 AI Agent 노드에서는 외부 MCP 서버를 불러 쓸 수 있습니다. 반대로 외부 에이전트가 Nected 규칙을 다루게 해 주는 MCP 서버는 문서에 없고, 연동은 API로 합니다.

LexQ는 규칙 관리 API를 AI 에이전트에 노출하는 MCP 서버를 모든 플랜에서 제공합니다. 쓰는 길은 둘입니다. OAuth 2.1을 지원하는 리모트 서버 https://mcp.lexq.io에 붙거나, CLI로 lexq serve --mcp를 띄웁니다. 에이전트는 자연어로 규칙을 만들고, 시뮬레이션을 돌리고, 버전을 배포하고, 실행 이력을 검사합니다.

CLI에는 구조화된 AI Agent Skills도 들어 있습니다. Claude Code, Cursor, Windsurf 같은 코딩 에이전트가 읽고 사람이 개입하지 않아도 정책을 자율적으로 관리하도록 돕는 문서입니다.

가격

LexQ 결제는 USD로 이루어지며 원화 금액은 참고용입니다.

숫자를 나란히 세워 봐도 직접 비교가 까다롭습니다. 셋의 과금 기준이 서로 다르기 때문입니다.

• GoRules: 사용자 수, 프로젝트 수, 배포 환경 수로 과금합니다. 클라우드 플랜에는 관리형 호스팅과 무제한 평가가 들어 있고, Agent나 SDK로 직접 평가하면 그 컴퓨팅은 사용자 몫입니다. 자체 호스팅 플랜은 유로로 값을 매기고(Team €50/월, Business €500/월), 서버와 데이터베이스, DevOps는 모두 사용자가 직접 맡습니다. 감사 로그는 두 쪽 다 Business부터입니다.
• Nected: 클라우드 플랜에서는 만들 수 있는 규칙 수가 5개, 20개, 50개로 정해져 있습니다. 규칙이 수십 개 필요한 조직이라면 호출량이 적어도 상위 플랜으로 올라가야 합니다. 버전 관리와 롤백도 Growth부터입니다. 자체 호스팅한 Nected에는 규칙 수 제한이 없습니다.
• LexQ: 실행 횟수로 과금합니다. 규칙을 몇 개 만들든 요금은 같습니다. 시뮬레이션, A/B 테스트, 버저닝, 충돌 해소, MCP 서버까지 전 기능이 모든 플랜에 들어 있습니다. 가격도 플랜 구조도 10년 동안 바꾸지 않겠다고 약속했습니다. 한도는 시간이 지나면서 늘어날 수는 있어도 줄지는 않습니다. 기능 때문에 플랜을 올릴 일은 없습니다. 실행, 시뮬레이션, 의사결정 재실행, 처리량(TPS), 보존 기간 중 하나가 모자랄 때만 올립니다.

언제 무엇을 선택할 것인가

GoRules를 고를 때

• 규칙이 어디서 실행되는지 완전히 통제하고 싶을 때
• 전체를 자체 호스팅할 선택지를 원할 때
• 애플리케이션 안에 임베딩할 의사결정 엔진이 필요할 때
• 극한 규모에서의 성능이 첫 번째 기준일 때

Nected를 고를 때

• 운영팀과 기획팀이 비주얼 에디터에서 규칙을 직접 고쳐야 할 때
• 규칙을 만드는 경험이 가장 간단한 쪽을 원할 때
• 변경 영향 시뮬레이션이나 A/B 테스트가 필요 없을 때

LexQ를 고를 때

• 프로덕션에 반영하기 전에 규칙 변경을 검증해야 할 때
• 비즈니스 규칙이 바뀔 때마다 코드를 배포하는 일을 멈추고 싶을 때
• AI 에이전트가 규칙을 자율적으로 관리하기를 원할 때
• 전체 감사 추적이 따라붙는 결정론적 충돌 해소가 필요할 때
• 첫날부터 플랜 제한 없이 모든 기능을 쓰고 싶을 때

솔직한 의견

비교 글은 결국 "상황에 따라 다르다"로 끝납니다. 이 글도 예외가 아닙니다. 그래도 무엇에 따라 다른지는 말할 수 있습니다.

제 입장부터 정리하면, LexQ는 엔지니어링 팀을 위한 의사결정 운영 플랫폼입니다. 이 범주가 낯설다면 규칙을 실행하는 일과 의사결정을 운영하는 일의 차이를 정리한 글을 먼저 보셔도 좋습니다. LexQ는 룰 엔진 라이브러리를 하나 더 만든 것이 아닙니다. 엔지니어를 의사결정에서 밀어내려는 도구도 아닙니다.

이제 무엇에 따라 갈리는지 구체적으로 적겠습니다.

엔지니어 세 명이 핀테크 제품을 만들고 가격 규칙을 매주 손보는 상황이라면, LexQ의 시뮬레이션과 A/B 테스트가 프로덕션 장애를 미리 막아 줍니다.

규모가 큰 회사의 플랫폼 팀이 고처리량 파이프라인 안에 의사결정 엔진을 심어야 한다면, GoRules의 Rust 코어가 더 합리적입니다.

운영팀과 기획팀이 비주얼 에디터에서 규칙을 직접 고쳐야 하는 조직이라면, Nected는 그 쓰임에 맞춰 만든 제품입니다.

가장 나쁜 선택은 따로 있습니다. 룰 엔진을 처음부터 직접 만드는 것입니다. 그런 팀을 여럿 봤습니다. 평가기까지는 다들 만듭니다. 버저닝과 감사 추적, 그리고 실제 트래픽에 미리 돌려 보는 일까지는 끝내 가지 못합니다.

• lexq.io에서 무료로 시작하기
• GitHub의 GoRules
• Nected