정책이 변경되었을 때 회사 문서들이 잘못되는 문제

한 회사가 환불 기간을 30일에서 14일로 변경했습니다.

승인된 정책은 업데이트되었습니다. 하지만 도움말 센터에는 여전히 30일이라고 나와 있습니다. 저장된 AI 답변은 예전 약속을 반복합니다. 환불 접수 워크플로우는 기간을 전혀 언급하지 않고도 그 도움말 페이지에 의존하고 있습니다.

결정은 바뀌었습니다. 하지만 회사의 지식(knowledge)은 따라잡지 못했습니다.

이것이 우리가 Ripple로 해결하고자 했던 문제입니다.

Ripple은 FalkorDB와 Gemini를 사용하여 Graph Hacks 2026의 Track 03: Company Brain 부문에서 구축된 그래프 기반 회사 지식(company brain)입니다.

이는 정책과 그 정책에 의존하는 문서, 클레임, 워크플로우 및 저장된 에이전트 답변을 연결합니다. 정책이 변경될 때, Ripple은 어떤 것들이 주의를 요하는지 찾아내고, 왜 그런지 설명하며, 소유자(owner)가 검토하고 수정할 수 있도록 돕습니다.

🔗 Ripple 사용해 보기

🎬 3분 작동 데모 영상 시청하기

💻 소스 코드 살펴보기

문서를 검색하는 것만으로는 충분하지 않은 이유

우리의 시작 질문은 간단했습니다:

정책 하나가 변경될 때, 어떻게 모든 것이 조용히 잘못되는 것을 찾아낼 수 있을까요?

“30일”을 검색하면 일부 오래된 진술(statement)을 포착할 수는 있지만, 다음과 같은 여러 질문들은 답하지 못합니다:

• 그 숫자가 환불, 체험 기간 또는 취소 통지 중 무엇에 대한 것인가?
• 자체 서비스 고객에게 적용되는가 아니면 기업 고객에게 적용되는가?
• 이것이 오래된 정책인가 아니면 미래의 제안인가?
• 어떤 워크플로우는 그 문구를 반복하지 않고도 문서에 의존하는가?
• 왜 특정 출처(source)를 변경해야 하는가?

이들은 관계(relationship)에 대한 질문입니다. 우리는 각 기록이 무엇을 말하는지뿐만 아니라, 기록들이 어떻게 연결되는지를 이해할 필요가 있었습니다.

그것이 그래프 데이터베이스를 유용한 기반으로 만들었습니다.

FalkorDB에서 회사 지식을 모델링한 방법

FalkorDB는 Ripple의 주요 회사 지식 데이터베이스입니다.

우리는 정책, 문서, 검토된 클레임(claims), 워크플로우, 저장된 에이전트 답변, 소유자, 결정, 검토, 수정 사항, 연구 스냅샷 및 출판 영수증을 저장합니다.

도메인 기록은 안정적인 ID를 가진 네이티브 Entity 노드와 쿼리 가능한 kind, 그리고 타입이 지정된 JSON 페이로드를 사용합니다. 관계는 네이티브 그래프 에지입니다.

핵심 의존성 모델은 다음과 같습니다:

Workflow → DEPENDS_ON → Document → ASSERTS → Claim

Claim → DEPENDS_ON → Policy version → DEPENDS_ON → Policy topic
...

클레임 노드가 특히 유용하다는 것이 밝혀졌습니다.

단일 문서에 시험 진술(trial statement)과 환불 진술(refund statement)이 모두 포함될 수 있습니다. 이러한 단언(assertions)들을 별도로 연결하면, 환불 변경 사항이 관련 클레임에 영향을 미치면서도 관련 없는 정보는 보존할 수 있게 합니다.

정책 주제 앵커(Policy-topic anchors)는 동일한 정책의 여러 버전을 연결합니다. 이를 통해 Ripple은 몇 개의 새로운 결정이 존재하더라도 오래된 클레임을 발견할 수 있습니다.

그래프 시각화는 이러한 저장된 관계를 보는 것입니다. FalkorDB는 또한 검색, 의존성 분석, 복구 및 지속적인 회상(persistent recall) 기능을 제공합니다. 데이터베이스를 제거하면 이러한 핵심 기능들이 비활성화됩니다.

SQLite는 로컬 인증 기록에만 제한적입니다. 개발 미리보기 시뮬레이터는 제출된 FalkorDB 기반 런타임과는 별개입니다.

영향 분석을 위한 Cypher 쿼리

Ripple은 이 쿼리를 사용하여 최대 여섯 단계까지 활성 의존성을 추적합니다:

MATCH p=(a:Entity)-[:DEPENDS_ON|ASSERTS*1..6]->(topic:Entity {id: $target})
WHERE all(r IN relationships(p) WHERE r.active = true)
RETURN [n IN nodes(p) | n.id] AS ids,
...

환불 분석의 경우, $target은 topic-refund입니다.

시험 기간, 취소 통지 및 지원 응답 시간은 별도의 주제 앵커를 가지고 있습니다.

이 쿼리는 노드 ID와 관계 유형을 반환합니다. Ripple은 이를 사용하여 출처가 영향 보고서에 나타난 이유를 설명하는 검사 가능한 증거 경로(evidence path)를 표시합니다.

사용자 데이터는 매개변수를 통해 전달됩니다. Gemini는 Cypher를 생성하지 않습니다.

의존성이 있다고 해서 무조건 잘못된 것은 아니다

이는 저희가 내린 가장 중요한 설계 결정 중 하나가 되었습니다.

만약 워크플로우가 도움말 페이지에 의존한다면, 그 관계는 해당 워크플로우가 주의를 요할 수 있음을 알려줍니다. 하지만 워크플로우를 정확히 어떻게 다시 작성해야 하는지는 알려주지 않습니다.

따라서 Ripple은 결과를 세 가지 범주로 분리합니다:

셀프 서비스 정책 변경은 기업 예외 사항(enterprise exception)을 보존해야 합니다. 제안되거나 미래의 정책은 현재 적용 가능한 승인 버전을 대체해서는 안 됩니다.

Gemini가 활용되는 부분

Gemini는 언어를 해석하는 데 도움을 줍니다.

이는 정확한 출처 인용문과 함께 후보 정책 주장을 추출하고, 누군가 질문할 때 지원되는 읽기 전용(read-only) 정책 컨텍스트 도구를 선택합니다.

승인된 그래프 기록은 답변에서 반환되는 권위 있는 값들을 결정합니다. 애플리케이션 검사 및 인간의 승인이 쓰기(writes)를 관리합니다.

현재 프로토타입은 네 가지 숫자형 정책 영역을 지원합니다:

• 체험 기간 (Trial duration), 일 단위 측정.
• 환불 적격 창 (Refund eligibility window), 일 단위 측정.
• 갱신 전 취소 통지 기간 (Cancellation notice before renewal), 일 단위 측정.
• 초기 지원 응답 시간 (Initial support response time), 시간 단위 측정.

이러한 의미들을 구분하여 유지하는 것이 중요합니다.

예를 들어:

“환불 처리에는 얼마나 걸리나요?”

이는 처리 또는 정산 시간을 묻는 것입니다. 14일의 환불 적격 창은 이에 답하지 못합니다.

Ripple은 질문에

승인된 발견 사항은 버전 관리되는 정책과 출처 관계를 확립합니다. 변경된 정책을 가져오면 영향 검토(impact reviews)가 생성될 수 있습니다.

사용자는 또한 문서를 지식 라이브러리에 붙여넣어 후보 주장(candidate claims)을 추출하고, 이를 검토한 후 출처를 저장할 수도 있습니다.

저희는 공개 텍스트를 증거로 취급합니다. 웹사이트나 모델의 출력물이 에이전트가 발견했다는 이유만으로 권위 있는 것이 되지는 않습니다.

완전한 예시: 환불 기간을 30일에서 14일로 변경하기

저희 공개 데모는 가상의 Acme 회사 데이터를 사용합니다.

공유 투어는 읽기 전용입니다. **사용자만의 샌드박스 체험(Try your own sandbox)**을 클릭하면 계정이 필요 없이 서명된 방문자 세션으로 별도의 쓰기 가능한 FalkorDB 그래프가 생성됩니다.

여기에 주요 워크플로우가 있습니다.

1. 원래 정책 문의하기

질문:

저희의 환불 기간은 얼마인가요?

**새로운 셀프 서비스(New self-serve)**와 2026년 10월 17일을 선택합니다.

신선한 샌드박스는 승인된 정책 증거와 함께 30일을 반환합니다.

2. 승인된 변경 기록하기

변경 스튜디오(Change studio)에서 환불 기간을 동일 고객 그룹에 대해 14일로 설정하고, 2026년 10월 17일에 발효 및 분석되도록 합니다.

Ripple은 새로운 정책 버전을 기록하고 종속성 분석(dependency analysis)을 실행합니다.

3. 결과 검토하기

새로 시드된 시나리오에서 보고서는 다음을 찾습니다:

• 확인된 충돌 3건.
• 검토가 필요한 워크플로우 2개.
• 영향받지 않은 엔터프라이즈 출처 1개.

이 수치는 작업 공간에 저장된 데이터에 따라 달라집니다.

영향을 받은 도움말 센터 페이지를 열면 이전의 30일 명세와 이를 환불 정책에 연결하는 그래프 경로가 표시됩니다.

4. 수정 검토 및 적용하기

검토 작업 공간은 원본과 제안된 텍스트를 나란히 표시합니다.

지원되는 환불 명세는 30일에서 14일로 변경됩니다. 주변 지침은 그대로 유지됩니다.

저장하기 전에 Ripple은 적용 가능한 정책 및 출처 개정/콘텐츠를 다시 확인합니다. 수정을 적용하면 원본 텍스트가 보존되고, 출처 개정이 증가하며, 수정 기록이 남습니다.

이미 적용된 검토를 재적용해도 또 다른 수정 기록이 생성되지는 않습니다.

5. 수정된 사본 내보내기 또는 게시하기

적용된 수정 사항은 Markdown 또는 JSON 형식으로 내보낼 수 있습니다.

패킷에는 수정 전후 내용, 소스 개정 사항, 정책 및 결정 출처(provenance), 그래프 증거, 행위자 및 승인 컨텍스트가 포함됩니다.

SHA-256 다이제스트는 콘텐츠의 동일성을 확인합니다. 이는 디지털 서명이 아닌 체크섬입니다.

게시(Publishing)는 별도의 작업입니다.

Acme 웹사이트에서 **승인된 사본 게시(Publish approved copy)**를 클릭하면 저희가 통제하는 샌드박스 도움말 센터가 업데이트됩니다. 고객 사본에는 이제 소스 개정 사항, 게시 시간 및 행위자가 함께 표시되며 14일이라는 기간이 나타납니다.

이는 경계를 명확히 하면서 완료된 작업을 시연합니다: 이는 관련 없는 회사의 웹사이트가 아니라 저희의 샌드박스 게시 표면을 업데이트하는 것입니다.

6. 다시 질문하고 기록 확인하기

동일한 환불 질문을 다시 해보세요:

14일.

브라우저를 새로고침하고 반복합니다:

14일.

청중(audience)을 엔터프라이즈로 변경합니다:

60일.

10월 1일에 셀프 서비스 정책에 대해 질문합니다:

30일.

그래프는 새로운 결정, 이전 정책 버전 및 고객 그룹 예외 사항을 모두 보존합니다.

이 구별은 중요합니다: 정책 승인은 권위 있는 답변을 변경합니다. 수정을 적용하는 것은 내부 소스를 복구합니다. 게시(Publishing)는 그 승인된 수정 사항을 통제되는 고객 표면에서 보이게 만듭니다.

동시 요청으로부터의 수정 보호

저희는 또한 두 개의 호스팅 서버 인스턴스가 동일한 그래프에 쓰는 경우 어떤 일이 발생하는지 고려해야 했습니다.

단순히 진행 중인 큐(in-process queue)만으로는 그것을 방지할 수 없습니다.

Ripple은 일관된 단일 쿼리에서 엔티티, 관계 및 작업 공간 메타데이터를 읽습니다. 그 원자적 저장(atomic save)은 레코드를 업데이트하기 전에 작업 공간 개정 사항을 확인합니다:

MERGE (m:RippleMeta {id: 'workspace'})
WITH m WHERE coalesce(m.revision, 0) = $expected
SET m.revision = $expected + 1, m.token = $token, m.commands = $commands

완전한 쿼리는 이 가드(guard)를 노드 및 관계 쓰기 그룹을 통해 전달합니다.

오래된 요청은 이전 소스 텍스트를 복원하는 대신 HTTP 409 오류를 반환합니다. 명령어 키는 중복 저장되는 변경 사항을 방지합니다. 작성기(writer)는 전체 투영 그래프(projected graph)를 검증하고 변경된 레코드만 저장합니다.

Ripple 개발 과정에서 배운 점

인터페이스 모호성이 정확한 그래프 로직을 저해할 수 있음

이전 버전에서는 반환 정책 제목이 체험 기간 선택기와 연결된 상태로 남아있도록 허용했습니다.

그것은 요청을 잘못된 정책 영역으로 라우팅시켰습니다.

저희는 인터페이스 동기화 문제를 수정하고, 일관되지 않은 정책 영역, 값 및 단위에 대한 서버 검증 기능을 추가했습니다. 회귀 테스트(Regression checks)는 원래의 불일치와 주제 간 격리(cross-topic isolation)를 모두 다룹니다.

배운 교훈은 간단했습니다. 정확한 순회(traversal)라 할지라도 모호하지 않은 요청이 필요합니다.

쿼리 구성이 데이터베이스 동작에 영향을 미침

저희의 원래 작성기(writer)는 그래프가 커짐에 따라 더 큰 쿼리 텍스트를 생성했습니다. 작은 Cloud 인스턴스에서는 이것이 쿼리 플랜 캐시 메모리를 소모했습니다.

저희는 관계 유형의 허용 목록(allowlist)을 가진 상수 형태의 매개변수화된 UNWIND 작성기로 변경했습니다.

그것은 그래프 레코드를 보존하면서 관찰된 실패를 수정했습니다. 또한 생성된 쿼리의 모양에 주의를 기울여야 한다는 것을 가르쳐주었습니다. 그저 올바른 결과를 반환하는지 여부를 넘어섭니다.

영구 상태는 명시적인 충돌 처리가 필요함

새로고침(refresh)은 다른 사람의 수정을 되돌려서는 안 됩니다. 요청을 반복한다고 해서 중복 감사 기록(audit records)이 생성되어서도 안 됩니다.

개정 검사, 소스 유효성 검사 및 명령어 중복 제거가 제품 신뢰성의 일부가 되었으며, 더 나중으로 미룰 수 있는 세부 사항이 아니게 되었습니다.

좋은 에이전트의 행동에는 멈출 시점을 아는 것이 포함됨

연결된 워크플로우(workflow)라고 해서 임의로 다시 작성하는 것을 정당화할 수는 없습니다. 환불 기간이라고 해서 처리 시간을 알려주지는 않습니다. 추출된 인용문(quotation) 역시 검토가 필요합니다.

명확한 경계는 프로토타입을 설명하고, 테스트하며, 신뢰하기 쉽게 만들었습니다.

검증 방법

릴리스 검증 기록은 44개의 통과된 자동화 테스트와 TypeScript/Vite 프로덕션 빌드를 문서화합니다.

별도의 Cloud 확인 기능:

• 실제 HTTP 어댑터 및 격리된 방문자 그래프.
• 수정 무결성(Correction integrity), 내보내기(exports), 게시(publication) 및 세션 재개.
• 두 개의 독립적인 데이터베이스 연결을 통한 오래된 저장 거부(Stale-save rejection).
• 명령 중복 제거(Command deduplication), 용량 제한(capacity limits) 및 백업 복원.
• 모든 네 가지 지원되는 정책 주제에 걸친 실시간 Gemini 추출 및 라우팅.

10월 18일 브라우저 녹화는 배포된 워크플로우를 테스트했습니다: 30일에서 14일로의 변경, 증거 검토, 승인된 수정, 다운로드 패킷, 게시, 새로고침 후 회수(recall after refresh), 기업 예외 및 과거 답변.

3분 데모는 합성 내레이션과 함께 실제 앱 상호작용을 보여줍니다.