Covenant Personal Edition 아키텍처 개요 — AI 거버넌스 기반의 설계 사상과 구현

서론

업무에 AI를 사용하는 개인 사업자, 프리랜서, 소규모 사업자에게 있어 "기밀 정보를 AI에 전달하면 어떻게 되는가"는 무시할 수 없는 질문입니다. 클라우드 AI의 편의성은 크지만, 다루는 정보의 기밀성이 높을수록 "전송해도 괜찮았는지"를 나중에 검증할 수단이 부족한 것이 현상황입니다.

업계의 주류 접근 방식은 "계약과 인증으로 보호한다"입니다. 즉, SaaS 벤더와 데이터 처리 계약 (DPA)을 체결하여 학습에 사용하지 않을 것을 약속받고, SOC 2 / ISO 27001 등의 제3자 인증으로 운영 품질을 담보하는 방식입니다. 이는 대기업을 위한 선택지로는 잘 작동하지만, **"사고가 발생했을 때, 무엇을 보냈고 무엇을 보내지 않았는지를 스스로 검증할 수 있는가"**라는 질문에는 답하지 못합니다.

Covenant Personal Edition은 이 질문에 대해 다른 접근 방식을 제시하는 AI 거버넌스 관리 앱입니다. 사용자가 다루는 기밀 데이터의 처리를 로컬 단말기에서 완결시키고, 클라우드 AI로의 전송은 수중에 있는 로그 (audit.jsonl)에 기밀 수준과 함께 기록하는 설계를 채택하고 있습니다.

본 기사에서는 Covenant Personal Edition의 아키텍처 전체상을 설계 사상과 구현 양면에서 해설합니다. AI 거버넌스를 "계약으로 보호하는 것"이 아니라 "스스로 쥐는 것"이라는 철학에 관심이 있는 엔지니어분들에게 기술적 판단 자료를 제공하는 것을 목적으로 합니다.

🔍

본 기사의 대상 독자

• 업무 AI 이용 시 기밀 정보 관리에 관심이 있는 엔지니어, 전문직, 소규모 사업자 대표
• 로컬 퍼스트 (Local-first) 설계, Tauri + Rust + Python 하이브리드 구성에 관심이 있는 엔지니어
• "계약과 인증으로 보호하는 것" 이외의 다른 축의 선택지를 찾고 있는 분

또한, 본 기사는 Covenant의 우월성을 주장하는 것이 아니라, 설계 선택과 그 한계를 포함하여 공정하게 공개하는 것을 의意하고 있습니다. Covenant가 해결하지 못하는 영역 (§6)도 명시합니다.

1. 기본 방침: 로컬 퍼스트 (Local-first) + 1 프로세스 1 사용자

Covenant Personal Edition의 아키텍처는 다음 3가지 기본 방침에 따라 설계되었습니다.

1.1 데이터 처리의 로컬 완결

사용자가 다루는 기밀 데이터 (프롬프트, LLM 답변, 첨부 파일, 스레드 이력, 감사 보고서, YAML 정책 설정)의 처리를 로컬 단말기에서 완결시킵니다. 이것들은 Covenant 운영 벤더의 서버로는 일절 전송되지 않습니다.

클라우드 AI로의 전송은 사용자가 정의한 정책에 따라 필터링 및 경로 제어되는 설계입니다. "데이터 처리의 로컬 완결"과 "라이선스 검증 메타데이터의 전송"은 범주적으로(categorically) 분리하여 취급합니다. 상용 버전 (DR4)에서 구독 결제가 시작될 때, 암호화된 구매자 식별 토큰과 구독 상태는 Microsoft Store 및 Exapolicy의 라이선스 서버로 전송되지만, 이는 "사용자가 다루는 기밀 데이터"와는 별개의 카테고리입니다.

1.2 1 프로세스 1 사용자 설계

Covenant는 "네트워크상에서 외부로부터의 접속을 대기하는 외부 리스너를 가지지 않는" 설계입니다. 이를 통해 SaaS형 시스템이 구조적으로 직면하는 다음과 같은 취약성 카테고리를 설계 단계에서 배제합니다.

• SSRF (Server-Side Request Forgery)
• 부정한 API 인증
• 멀티테넌트 (Multi-tenant) 환경에서의 데이터 유출

모든 대화 이력, 정책 파일, 루브릭 (평가 기준), 감사 로그는 OS 표준 사용자 데이터 디렉토리 (예: Windows = %APPDATA%\Covenant\, macOS = ~/Library/Application Support/Covenant/) 내의 SQLite 데이터베이스 등에 저장됩니다.

서버 측에서 "멀티테넌트 분리"를 설계 및 운영할 필요가 없으며, 결과적으로 사용자가 "자신의 데이터가 타인의 데이터와 혼재되지 않을까"를 걱정하는 구조 자체가 존재하지 않습니다.

1.3 정책의 육성 가능성

Covenant의 판정 로직은 사용자가 정의한 YAML 정책 (org.yaml / project.yaml의 계층 구조)에 따라 동작합니다. 판단 이력은 "자신의 정책 및 규칙"으로서 축적되며, 운용하면서 키워 나가는 설계입니다.

이는 「거버넌스를 SaaS 벤더에게 맡긴다」는 철학과는 달리, 「스스로 장악한다」는 철학에 대응하는 것입니다. 사무소 고유의 판단 노하우가 암호학적 감사 로그 (Audit Log)로서 축적됩니다.

2. 기술 스택 (Technology Stack)

Covenant의 기술 선택은 「로컬 완결」과 「일상적으로 유지보수할 수 있는 구성」의 양립을 의식하고 있습니다.

레이어	채택 기술	주요 선정 이유
프론트엔드	Tauri + React + TypeScript	Electron보다 경량이며, Rust 기반으로 OS 통합 (키체인 등)이 매끄러움
백엔드 (사이드카)	Python	LLM 에코시스템 (Ollama 연동 / 프롬프트 처리)과의 친화성
프로세스 간 통신	표준 입출력을 통한 JSON-RPC 2.0	HTTP 리스너 불필요, 로컬 퍼스트 (Local-first) 원칙과 일치
로컬 LLM 연동	Ollama (HTTP API)	모델 전환 및 양자화 (Quantization) 변동성이 풍부함
데이터 영속화	SQLite + JSONL	단일 파일 · 백업 용이 · 추가 전용 (변조 탐지에 유리)
정책 정의	YAML (계층 구조)	인간이 읽고 쓸 수 있으며, Git으로 버전 관리 가능

2.1 Tauri를 선택한 이유

Electron과의 비교에서, 다음과 같은 점에서 Tauri가 본 용도에 부합했습니다.

• 바이너리 크기: WebView를 OS 표준 것을 사용하기 때문에 경량임
• 메모리 소비: Chromium을 번들링하지 않기 때문에 작음
• OS 연동: Rust의 windows-rs / core-foundation 등으로 OS API를 직접 호출할 수 있음
• 보안 모델: 권한 (Capability) 기반으로 「무엇을 할 수 있는지」를 명시적으로 선언

단, Tauri는 WebView의 차이 (Windows = WebView2, macOS = WKWebView)가 있으므로, UI 검증은 양쪽 OS에서 수행해야 합니다. 이는 설계 선택의 트레이드오프 (Trade-off)입니다.

2.2 Python 사이드카 프로세스 (Sidecar Process)

LLM 관련 에코시스템 (프롬프트 관리, 토큰 계산, Ollama 연동, 평가 루브릭 처리)을 Python으로 구현하며, Tauri 프론트엔드에서는 표준 입출력을 통한 JSON-RPC 2.0으로 호출합니다.

# 개념 코드: 사이드카의 최소 구조
import sys, json
def handle(method: str, params: dict) -> dict:
...

HTTP 서버를 구축하지 않기 때문에, 로컬에 포트가 열리지 않습니다. 이를 통해 다른 프로세스가 해당 포트를 통해 접근하는 경로가 원리적으로 존재하지 않습니다.

3. Gate Pipeline (0/1/2/2.5/2.8/3의 6단계 구성)

Covenant의 핵심 기능인 Gate Pipeline은 사용자가 입력한 프롬프트를 클라우드 AI로 전송하기 전에, 로컬 환경 내에서 다층 심사를 수행하는 메커니즘입니다.

3.1 각 Gate의 역할

Gate	역할	기술
Gate 0	전처리 (정규화 · 공백 제거 · 이모지 처리 등)	결정론적 (Deterministic)
Gate 1	Prefilter (PII · 소스 코드 · 기밀 용어의 정적 탐지)	정규 표현식 등의 결정론적 로직
Gate 2	Policy Check (규칙 기반 평가)	YAML 정책 대조
Gate 2.5	문맥 심사 (의도 판정)	경량 LLM
Gate 2.8	무해성 프리필터 (Harmlessness Prefilter)	경량 LLM (Gate 3의 전 단계에서 계산 비용 절감)
Gate 3	LlamaEvaluator (다축 평가 엔진)	Llama 3.1 8B 등의 로컬 LLM

3.2 「평가 / 판정 / 판단」의 3단계 구조

Covenant에서는 책임을 다음과 같이 분리하여 설계하고 있습니다.

• 평가 (Evaluation) = AI가 수행. 스코어링 · 확률 분포 산출.
• 판정 (Judgment) = 정책이 수행. 임계값과의 대조, 화이트리스트 / 블랙리스트 판정.
• 판단 (Decision) = 인간이 수행. 예외 승인, 비즈니스 임팩트를 동반하는 최종 결정.

3.3 Gate 3: 윤리성 / 안전성의 2축 평가

Gate 3는 외부 API에 의존하지 않고, PC 로컬에서 구동되는 경량 LLM (Llama 3.1 8B 등)을 사용하여 입력 텍스트의 리스크를 「윤리성 (Ethics)」 과 「안전성 (Safety)」 두 축을 기준으로 1.0~10.0 사이의 연속값 스코어로 산출합니다.

중요한 점은, Gate 3는 스코어 산출만을 담당하며, 최종적인 비즈니스 의사결정 (허가·보류·거부)은 후단의 「결정 수단」 (정책과 인간의 판단)에 위임한다는 것입니다. AI에게 최종 판단을 맡기지 않는 이 설계는 PMBOK 제8판이 요구하는 「설명 책임 (Accountability)」을 시스템 수준에서 체현한 것입니다.

3.4 Fail-Closed 원칙

판정 불가능한 상황 (Gate 2.5 / 2.8에서 타임아웃, 로컬 LLM의 응답 이상 등)에서는, Fail-Closed (안전 측으로 기울어짐) 원칙에 따라 기본적으로 「보류」 또는 「차단」을 선택합니다. 이는 「모호할 때 진행하는 것」이 아니라, 「모호할 때는 인간의 확인을 기다리는」 설계입니다.

4. DLM (Data Lifecycle Management) — 기밀 분류와 다이내믹 라우팅

「클라우드 AI로의 전송 리스크」를 실용적으로 제어하기 위해, Covenant는 데이터의 기밀 수준에 따른 LLM 다이내믹 라우팅 (Dynamic Routing) 을 구현하고 있습니다. 그 기반이 되는 것이 정보를 4단계로 분류하는 DLM 기능입니다.

4.1 기밀 수준 L1~L4

레벨	데이터 정의 예시	라우팅 방침
L1 (공개 정보)	일반적인 판례, 공개된 특허 공보, 법률의 일반적인 해석	클라우드 AI 전송 가능 (고품질·고속·저비용)
L2 (사외비)	클라이언트명이 가려진 상담 내용, 사내 회의 의사록	정책 설정에 따라 필요 시 로컬 LLM으로 전송
L3 (기밀 정보)	미공개 특허 청구 범위, NDA 하의 재무 데이터, M&A 정보	클라우드 전송을 구조적으로 억제, PC 내 로컬 LLM으로 처리
L4 (극비 정보)	치명적인 PII (개인 식별 정보), 주민등록번호 등	어떠한 LLM으로의 전송도 차단, 즉시 audit 기록

사용자는 프롬프트 서두에 [L3]와 같은 접두사(Prefix)를 기술함으로써 메시지 단일 건의 기밀 수준을 명시적으로 선언할 수 있습니다. 스레드 생성 시 기본 기밀 수준을 설정하는 것도 가능합니다.

4.2 연쇄 전파 문제의 해결: thread_max와 payload_level의 분리

AI를 이용한 대화 시스템에는 「한 번 고기밀 정보를 입력하면, 그 이후의 AI 응답에도 기밀 정보가 포함된 것으로 판정되어 스레드 전체가 영구적으로 고보안 요건에 묶여버리는」 연쇄 전파 문제 (Chain-propagation) 가 존재합니다.

Covenant의 아키텍처는 스레드 관리 지표를 두 가지 차원으로 분리함으로써 이 문제에 대처하고 있습니다.

# 개념: 스레드 상태의 2축 관리
thread_max: 3 # 스레드 내 과거 최고 수준 (단조 증가, 감사용)
payload_level: 1 # 현재 전송 페이로드의 수준 (매 턴 동적 계산)

• thread_max (감사용 워터마크): 스레드 내에서 과거에 한 번이라도 도달했던 최고 수준을 기록하며, 단조 증가만 합니다. 감사 추적(Audit trail)으로서 기능합니다.
• payload_level (동적 라우팅 판정 축): LLM으로 전송되는 데이터 (슬라이딩 윈도우 내의 이력 + 현재 메시지)의 기밀성을 매 턴 동적으로 계산합니다.

사용자 입력 메시지의 수준만을 참조하며, 어시스턴트 메시지의 수준은 무시합니다.

이러한 분리를 통해, 과거에 L3를 입력했던 스레드라도 대화가 진행되어 슬라이딩 윈도우에서 해당 기밀 정보가 밀려나면, payload_level은 L1으로 복귀합니다. 불필요한 로컬 LLM으로의 제한이 해제되어, 고성능 클라우드 AI를 다시 이용할 수 있게 됩니다.

자세한 내용은 별도 기사 「DLM 기밀 분류의 사고방식」(예정)에서 심도 있게 다루겠습니다.

5. audit.jsonl — 설명 책임의 검증 가능성 (Verifiable Accountability)

Covenant의 차별화 요소로서, 「무엇을 보냈는지·보내지 않았는지를 수중에 있는 로그로 검증할 수 있는」 설계가 있습니다.

5.1 audit.jsonl의 구조

audit.jsonl에는 다음이 기록됩니다.

{"ts":"2026-06-03T10:23:45Z","audit_id":"...","level":"L1","route":"cloud","provider":"claude","block_reason":null}
{"ts":"2026-06-03T10:24:12Z","audit_id":"...","level":"L3","route":"local","provider":"ollama","block_reason":null}
{"ts":"2026-06-03T10:25:01Z","audit_id":"...","level":"L4","route":"blocked","provider":null,"block_reason":"gate1_pii_detected"}

기록 항목:

전송 건수(기밀 레벨별 집계)

• 기밀 레벨 라벨(L1 / L2 / L3 / L4)
• 차단 사유(Gate 1 / Gate 2 / Gate 3 / Policy 등)
• 라우팅 목적지(Cloud AI 명 / Local LLM / Blocked)

5.2 메시지 본문은 남기지 않는 설계

⚠️ 중요한 설계 판단: audit.jsonl에는메시지 본문을 기록하지 않습니다. '무엇을 다루었는지'(기밀 레벨 라벨 + 건수)는 기록되지만, '구체적으로 무엇을 작성했는지'(프롬프트 본문)는 남지 않는 설계입니다.

이를 통해 사용자가 스스로 프라이버시를 확보하면서도 설명 책임의 검증 가능성을 담보할 수 있습니다. 즉, 'Covenant 자체가 기밀 정보의 축적원'이 될 위험을 구조적으로 회피하는 설계입니다.

5.3 최종 사용자(고객)에게 설명으로 연결하기

업계의 주류 접근 방식에서는 SaaS 벤더로부터 '유출되었을 가능성이 있습니다'라는 통보가 왔을 때, 최종 사용자로부터 오는 '제 정보는 유출되지 않았죠?'라는 질문에 대해 계약 조항을 참조하는 것밖에 할 수 없는 경우가 많습니다.

Covenant의 audit.jsonl은 '해당 기간 동안 기밀도가 높은 정보는 외부로 전송하지 않았습니다', '손안의 로그를 확인하실 수 있습니다'와 같이, 스스로 검증 가능한 형태로 설명할 수 있는 구조를 제공합니다.

이는 '유출되지 않음을 약속하는 것'이 아니라, '무엇이 일어났는지/일어나지 않았는지를 스스로 설명할 수 있다'는 설계입니다. 이는 설명 책임의 질적 변화라고 할 수 있습니다.

자세한 내용은 별도 기사 「설명 책임의 검증 가능성 — audit.jsonl의 구조와 업무 시나리오」(예정)에서 깊이 다루겠습니다.

6. Covenant의 한계 — 공정한 공개

본 기사는 Covenant의 우수성을 일방적으로 주장하는 것이 아닙니다. 아래는 Covenant가 해결하지 못하는 영역입니다. 배포 전에 명시합니다.

(a) 로컬 PC 자체의 유출 위험

PC 도난·악성코드 감염·물리적 접근에 의한 로컬 데이터 유출 위험은 남아 있습니다. Covenant는 SaaS 경유의 유출 위험을 대체하지만, 로컬의 물리 보안은 사용자 책임입니다. 디스크 암호화 (BitLocker / FileVault)나 OS의 일반적인 보안 대책이 전제되어야 합니다.

(b) 사용자가 명시적으로 클라우드 AI에 보내기로 판단한 경우

기밀 레벨 L1 / L2(공개 정보 상당·사외비)를 전송한 목적지 클라우드 AI 측에서 무슨 일이 일어날지는 Covenant의 범위를 벗어납니다. 전송된 목적지 SaaS의 유출 위험은 승계합니다. Covenant가 기여하는 부분은 '보내기 전 필터링'과 '보냈는지/안 보냈는지를 기록하는 것'까지입니다.

(c) 로컬 LLM의 성능 제약

dGPU 미탑재 PC에서는 Gate 3(LLM 평가)에 시간이 걸릴 수 있습니다. 사내 검증 과정에서 특정 구성에서 Gate 3가 약 184초 정도 걸린 사례도 관찰되었습니다. 권장 환경을 갖추는 것을 전제로 합니다.

Apple Silicon (M2 / M3)은 유니버설 메모리(unified memory)를 통해 실용적인 속도를 확보하기 쉽고, Windows 환경에서는 dGPU 탑재 또는 별도의 노드(중고 Mac mini 등)에서 로컬 LLM을 담당하게 하는 구성이 현실적입니다.

(d) 거버넌스의 자기 책임성

정책 (org.yaml / project.yaml)

)의 정의 및 업데이트는 사용자 책임입니다. 업계 가이드라인의 선택, 규칙 조정, 예외 승인 판단은 모두 이용자의 의사결정에 맡겨집니다. "편하게 사용하고 싶다"거나 "거버넌스를 SaaS에 위탁하고 싶다"는 계층에게는 적합하지 않습니다.

→ Covenant는 "직접 정책을 정의하고 운용하고 싶다"는 소수 계층을 위한 제품입니다. 이는 전략적 선택이며, 시장 전체를 점유하기 위한 설계가 아닙니다.

7. 연동 및 다음 단계

β1 배포 (2026년 7~9월 시작 예정, 초대제)

Covenant Personal Edition β1 시제품을 초대제 50명 이내로 한정 배포할 예정입니다. 프리랜서, 소규모 사업자, 전문직 종사자를 주요 대상으로 테스트 파트너를 모집합니다. 자세한 내용은 LP(Landing Page)를 통해 공개될 예정입니다.

후속 기사 (본 Publication에서 연재 예정)

본 기사는 아키텍처 개요입니다. 다음과 같은 주제로 심층 분석 기사를 예정하고 있습니다.

(a) 설명책임의 검증 가능성 — audit.jsonl의 구조와 업무 시나리오
(b) DLM 기밀 분류 방식 — 4단계 기밀 레벨과 다이내믹 라우팅 (Dynamic Routing)
(c) Gate 3 LlamaEvaluator — 로컬 LLM을 통한 윤리성 / 안전성 2축 평가
(d) YAML 정책 설계 실례 — org.yaml / project.yaml의 계층 구조

관련 링크

피드백 환영

본 기사의 내용에 대해 감상, 지적, 질문을 보내주시면 후속 기사 개선에 활용하겠습니다. "계약과 인증으로 보호한다"는 것 이상의 또 다른 선택지로서, Covenant의 설계 판단이 기술 커뮤니티의 토론 소재가 되기를 바랍니다.

Covenant Personal Edition은 Exapolicy LLC가 개발하는 AI 거버넌스 관리 앱입니다. 본 기사는 아키텍처 개요이며, 제품의 우위성을 주장하는 것이 아니라 설계와 한계를 공정하게 공개하는 것을 목적으로 합니다.

Discussion