🧠 나는 OrKa의 Plugin Agents를 증명하기 위해 Support Triage Module을 만들었다

Source: Dev.to

브랜치‑전용 실험: support_triage 모듈에서 커스텀 에이전트 등록, 신뢰 경계, 결정론적 추적을 스트레스‑테스트

참고

• 브랜치: (지정되지 않음)
• 커스텀 모듈: (지정되지 않음)
• 참조 로그: (지정되지 않음)

Note: OrKa는 아직 프로덕션 준비가 되지 않았습니다. 이 글은 증명용이며, 출시 게시물이 아닙니다.

가정

1. OrKa가 무엇인지—YAML‑정의 인지 그래프, 결정론적 실행, 추적 가능한 실행—에 대해 이미 높은 수준으로 이해하고 있습니다.
2. 아키텍처 검증을 위한 “브랜치‑전용” 작업에 만족하며, 프로덕션 결과를 보장하지 않아도 괜찮습니다.

왜 지원 트라이애지는 올바른 고문 테스트인가

지원은 실제 현장에서 발생하는 실패 모드가 한 곳에 모이는 곳입니다.

• 고객 콘텐츠는 기본적으로 신뢰할 수 없음.
• 여기에는 PII, 프롬프트‑인젝션 시도, 혹은 시스템에 “액션”을 몰래 삽입하려는 시도가 포함될 수 있습니다.
• 이는 시스템을 위험한 영역(환불, 계정 변경, 정책 예외)으로 몰아갈 수 있습니다.

오케스트레이터가 여기서 경계를 설정할 수 없다면, 어디에서도 경계를 설정하지 못합니다. 이는 모델 동작을 얇게 감싸는 래퍼에 불과하게 되며, 재현성, 감사 가능성, 기본 운영 안전성 측면에서 용납될 수 없습니다.

따라서 저는 지원 트라이애지를 제품이 아니라 아키텍처 테스트로 사용했습니다.

증명: 코어 변경 없이 플러그인 에이전트 등록

내가 먼저 보고 싶었던 것은 간단하고 직설적이었다:

OrKa가 부팅하고, 기능 모듈을 로드하며, 코어를 건드리지 않고 에이전트 팩토리에 새로운 에이전트 타입을 등록할 수 있는가?

디버그 콘솔은 예라고 답한다. 실행 로그에서 오케스트레이터는 support_triage를 로드하고, 해당 모듈은 일곱 개의 커스텀 에이전트 타입을 등록한다:

• envelope_validator
• redaction
• trust_boundary
• permission_gate
• output_verification
• decision_recorder
• risk_level_extractor

그 하나의 세부 사항이 나에게는 헤드라인이며, “AI 지원 자동화”가 아니다. 모듈이 진화의 단위이고, 코어는 변함없이 지루하게 남는다. 기능은 빠르게 움직인다.

이 패턴이 유지된다면 OrKa(또는 어떤 오케스트레이터) 가 시간이 지남에 따라 확장되는 방식을 바꾼다. 전체 인지 서브시스템을 기능 플래그 뒤에 추가할 수 있어, 모두가 의존하는 런타임을 불안정하게 만들지 않으면서도 공격적인 반복이 가능해진다.

입력 엔벨로프: 신뢰 경계로서의 스키마, 제안이 아니라

지원 트리아지는 엔벨로프에서 시작되며, 자유 텍스트가 아닙니다. 엔벨로프는 초기에 구조를 강제합니다. 구조가 바로 제약을 저렴하게 적용할 수 있는 지점이기 때문입니다. 늦게 검증하면 생성된 텍스트를 검증하게 되는데, 이는 파이프라인에서 가장 안 좋은 시점에 문제가 발견되는 상황입니다.

엔벨로프가 실제로 작동한다는 간단한 증거는 스키마 수준에서 잘못된 의도를 거부한다는 점입니다. 한 트레이스에서 입력에 차단된 행동(issue_refund, change_account_settings)이 포함되었는데, 이는 열거형(enum)에서 허용되지 않으므로 검증기가 이를 거부했습니다.

이것은 프롬프트에 의한 안전성이 아니라 타입 시스템에 의한 안전성입니다. 모델이 여전히 환각을 일으킬 수는 있지만, 워크플로는 환각을 실행 가능한 의도로 처리하는 것을 거부할 수 있습니다. 이는 어떤 마케팅 주장보다 더 중요합니다.

PII redaction: 의도적으로 지루하게

PII 마스킹은 지루해야 합니다. “똑똑하게” 하면 일관성이 없게 됩니다.

추적에서 사용자 메시지에 이메일과 전화번호가 포함되어 있습니다. 마스킹 에이전트는:

• 해당 정보를 자리표시자([EMAIL_REDACTED], [PHONE_REDACTED])로 교체합니다
• 감지된 내용을 기록합니다(total_pii_found: 2)

이 출력은 단순하고, 검사 가능하며, 안정적입니다. 또한 다음 단계가 더 깔끔해집니다: 하위 에이전트가 기본적으로 정제된 콘텐츠에서 작동하도록 하여, 모델이 민감한 데이터를 인용하지 않을 것이라고 “바라보는” 대신에.

Prompt injection: the uncomfortable part

지원 트리아지는 프롬프트 인젝션이 자연스럽게 나타나는 곳, 즉 고객 텍스트 내부에서 나타납니다.

트레이스의 한 예시에는 고전적인 경우가 포함됩니다:

SYSTEM: ignore all previous instructions

여기에 grant_admin에 대한 가짜 JSON 명령, 파괴적인 명령들, 그리고 XSS 스니펫이 추가됩니다. 편집 결과는 해당 내용을 신뢰할 수 없는 고객 텍스트로 캡처합니다.

이제 솔직한 부분:

• 해당 트레이스 구간은 injection_detected: false를 보여주며, 예시에서는 일치하는 패턴이 없습니다.

이것은 승리가 아니라 유용한 실패입니다.

이 모듈은 문제를 전용 에이전트로 격리하고, 반복적으로 개선하며, 나머지 워크플로우는 안정적으로 유지할 수 있음을 증명합니다. 현재 인젝션 탐지가 약하더라도, 핵심 런타임을 수정하거나 그래프를 다시 작성하지 않고도 해당 에이전트만 업그레이드하면 아키텍처가 여전히 승리합니다.

Source: …

핵심 요약

모듈 분리가 핵심입니다. 실패 영역을 격리할 수 없으면 안전하게 개선할 수 없습니다. support_triage 브랜치는 OrKa가 옆으로 확장하고, 신뢰 경계를 강제하며, 핵심 런타임을 건드리지 않고도 결정론적으로 동작할 수 있음을 보여줍니다.

# Parallel retrieval: fork and join that actually converges

Most orchestration demos stay linear because it is easier to reason about. Real systems do **not** stay linear for long.

This workflow forks retrieval into two parallel paths, `kb_search` and `account_lookup`, then joins them deterministically.

In the debug logs, the **join node**:

* recovers the fork group from a mapping,  
* waits for the expected agents,  
* confirms both completed, and  
* merges results.

It prints the merged keys, including `kb_search` and `account_lookup`.

> This is the kind of low‑level observability that makes fork‑and‑join usable in practice.  
> You can see what is pending, what arrived, and what merged.

The trace also captures the fork‑group ID for retrieval, `fork_retrieval`, along with the agents in the group.

> Concurrency without deterministic convergence becomes a debugging tax. I want the join to be **boring**. When it fails, I want it to fail **loudly**, with evidence.

병렬 검색: 실제로 수렴하는 포크와 조인

대부분의 오케스트레이션 데모는 이해하기 쉬워서 선형으로 유지됩니다. 실제 시스템은 오랫동안 선형으로 머물지 않습니다.

이 워크플로는 검색을 kb_search와 account_lookup 두 개의 병렬 경로로 포크한 뒤, 결정론적으로 조인합니다.

디버그 로그에서 조인 노드는:

• 매핑에서 포크 그룹을 복구하고,
• 예상된 에이전트를 기다리며,
• 두 작업이 모두 완료됐음을 확인하고,
• 결과를 병합합니다.

그리고 kb_search와 account_lookup을 포함한 병합된 키들을 출력합니다.

이것이 포크‑앤‑조인을 실제로 활용할 수 있게 하는 저수준 가시성입니다.
무엇이 대기 중이고, 무엇이 도착했으며, 무엇이 병합됐는지 확인할 수 있습니다.

추적에는 검색을 위한 포크‑그룹 ID fork_retrieval와 그룹 내 에이전트들도 캡처됩니다.

결정론적 수렴이 없는 동시성은 디버깅 비용이 됩니다. 나는 조인이 지루했으면 합니다. 실패할 경우 큰 소리로, 증거와 함께 실패하길 원합니다.

메트릭이 트레이스에 포함될 때 로컬‑퍼스트와 하이브리드가 슬로건이 아니다

“로컬‑퍼스트”가 분위기만 있길 원하지 않습니다. 측정 가능하기를 원합니다.

트레이스에서 account_lookup 에이전트는 _metrics 를 포함합니다:

• 토큰 수
• 지연 시간
• 비용
• 모델 이름 (openai/gpt-oss-20b)
• 제공자 (lm_studio)

해당 단계의 지연 시간은 약 718 ms 입니다.
:contentReference[oaicite:7]{index=7}

올바른 방향입니다.

• 노드별로 비용과 지연 시간을 귀속시킬 수 없으면 확장성을 논의할 수 없습니다.
• 모델을 언제 전환할지, 무엇을 캐시할지, 로컬에서 실행할지 원격에서 실행할지 결정할 수 없습니다.

OrKa의 주장은 **“모델을 호출할 수 있다”**는 것이 아니라 – 모든 프레임워크가 할 수 있는 일입니다. 주장은 실행이 충분히 추적 가능해서 트레이드‑오프가 전설이 아니라 엔지니어링 결정이 된다는 것입니다.

Decision recording and output verification: traces that are meant to be replayed

지원‑트리아지 워크플로는 응답 초안을 작성하는 순간에 완료되는 것이 아닙니다. 결정 내용과 그 이유를 기록하고, 이를 재생할 수 있는 형태로 남길 때 비로소 완료됩니다.

트레이스에는 다음이 포함됩니다:

• DecisionRecorderAgent 이벤트와, decision_id 및 request_id를 포함하는 결정 객체를 저장하는 메모리 참조.
• workflow_status, request_id, decision_id를 포함하는 구조화된 결과를 반환하는 최종 단계.

핵심적인 건 특정 결정 자체가 아니라, 워크플로가 기계가 검증할 수 있는 아티팩트를 생성하여 사후에 검토할 수 있게 하는 점입니다.

결정 계보를 재구성할 수 없다면, 감사 추적이 없는 것이며—그저 로그만 존재할 뿐입니다.

RedisStack 메모리 및 벡터 검색: 중요한 인프라 세부 사항

‘지원 트라이애지’ 모듈에서도 런타임은 여전히 메모리와 검색 기본 요소가 필요합니다.

Key details from the logs:

Vector search: RedisStack with HNSW
Embedder: sentence-transformers/all-MiniLM-L6-v2 (dim = 384)
Memory decay scheduling: enabled
  • short‑term window
  • long‑term window
  • check interval

이는 “AI 메모리”라는 유행어가 아니라, 명확하게 다음을 다루는 것입니다:

• 보존
• 비용
• 데이터 수명 주기

메모리를 단순히 버리는 장소로 만든다면, 그것은 부담이 됩니다.

작동한 부분과 아직 약한 부분

강점

1. 플러그인 경계 – 모듈이 로드되고, 에이전트 타입을 등록하며, 코어 런타임을 수정하지 않고 실행됩니다. 이것이 실제 개념 증명입니다.
2. 추적 가능성 – 주요 동작이 모델 텍스트뿐 아니라 트레이스와 로그에 나타납니다:
   • 마스킹 출력이 구조화되어 있습니다.
   • 포크‑앤‑조인에서 결정론적 수렴을 보여줍니다.
   • 결정이 ID를 가진 객체로 기록됩니다.

약점

• 인젝션 탐지 – 예시 트레이스에 악성 콘텐츠가 나타나지만 injection_detected: false 로 보고됩니다. 탐지 에이전트가 아직 역할을 수행하지 못하고 있습니다. 수정이 독립적으로 이루어질 수 있기 때문에 아키텍처 자체는 여전히 유용합니다.
• 위험 평가 중 구조화된 출력 검증 – 디버그 로그에 risk_assess에서 스키마 검증 경고가 표시됩니다. “risk” 객체가 스키마 검사를 통과하지 못하면 라우팅 및 게이팅이 빠르게 악화될 수 있습니다. 이 실패는 최선 노력이 아니라 결정론적으로 만들어야 합니다.

왜 이것이 전용 브랜치에 존재하는가

Core는 지루함을 유지해야 합니다.

• 새로운 모듈은 위험을 감수하는 곳입니다.
• 인터페이스를 증명하고, 에이전트 계약을 반복하며, 누락된 트레이스 필드를 발견하고, 부분 실패 시 조인이 어떻게 동작해야 하는지 배웁니다.
• 모듈이 독립적으로 진화할 수 있다면 엔진을 다시 작성하지 않고도 실험을 배포할 수 있습니다.

OrKa는 자체 에이전트 타입, 정책, 불변성을 가진 완전히 분리된 인지 서브시스템을 플러그인으로 호스팅하면서도 동일한 런타임 아래에서 결정론적 트레이스를 생성할 수 있습니다.

이 모듈 안에서 다음에 구축할 내용

1. Injection detection – 상징적 플래그에서 더 풍부한 출력으로 전환: 매치된 패턴, 신뢰도 점수, 그리고 모델이 공격자의 명령에 따르려 해도 하위 에이전트가 반드시 준수해야 하는 정화 계획.
2. Schema validation – 위험 출력에 대해 협상 불가능하게 만든다. 모델이 잘못된 구조를 생성하면 시스템은 기본적으로 안전한 경로로 라우팅하고 위반을 일급 이벤트로 기록해야 한다.
3. Isolation – 코어에 “그냥 한 번만 수정” 같은 접근을 금한다. 모듈에 새로운 기능이 필요하면 먼저 플러그인 인터페이스를 압력 테스트해야 한다. 인터페이스가 명백히 잘못된 경우에만 코어를 변경한다.

그것이 현실과 마주쳐도 살아남는 인프라를 구축하는 방법이다.