Jev 시스템 아키텍트은(는) 무엇을 하나요?

목적

이 스킬을 사용하여 다음을 결정합니다:

Jev가 시스템에 전혀 속하는지 여부
Jev 경계가 정확히 어디에 있어야 하는지
어떤 판단이 Choice, Score 또는 Noul 질문이 되어야 하는지
각 판단이 보아야 할 상태(State)
어떤 질문들이 함께 실행되어야 하는지
일반 코드가 결과를 어떻게 구성(compose)해야 하는지
불확실성이 시스템 동작을 어떻게 변경해야 하는지
통합이 프로덕션 사용 전에 어떻게 평가되어야 하는지

이는 주로 아키텍처 및 분해(Decomposition) 스킬입니다.

정확한 SDK 구문, 요청/응답 필드, 모델, 제한 사항 또는 버전별 API 동작에 대해서는 현재 TypeSafe 문서를 읽고, 가능할 때 TypeSafe의 공식 에이전트 스킬을 사용하십시오.

API 필드를 임의로 만들지 마십시오.

핵심 정신 모델

Jev는 애플리케이션이 아닙니다.

Jev는 워크플로 엔진이 아닙니다.

Jev는 자율 에이전트가 아닙니다.

선호되는 아키텍처는 다음과 같습니다:

애플리케이션 상태
      ↓
제한된 의미 질문
      ↓
     JEV
      ↓
타입이 지정된 판단 + 확률
      ↓
결정론적 애플리케이션 코드
      ↓
라우팅 / 순위 지정 / 확인 / 질문 / 에스컬레이션 / 실행

모델은 프로그래밍 가능한 판단을 제공합니다.

코드는 다음을 소유합니다:

제어 흐름
권한
계산
결정론적 규칙
지속성
트랜잭션
부작용
도구 실행
인가
정책 시행

일반 소프트웨어가 구조화되지 않았거나 모호한 정보에 대한 의미론적 이해가 필요한 경우에만 Jev를 사용하십시오.

트리거 조건

시스템에 다음과 같은 형태의 경계가 포함된 경우 Jev를 고려하십시오:

구조화되지 않았거나 맥락적인 정보
                ↓
     제한된 판단이 필요함
                ↓
 소프트웨어가 계속 진행하기 위해 타입이 지정된 값이 필요함

강력한 후보는 다음과 같습니다:

의도 분류
의미론적 라우팅
중재 결정
문서 분류
증거 확인
인용 확인
의미론적 가드레일
위험 신호
메시지 해석
후보 선택
순위 차원
관련성 판단
감정 또는 긴급도
사용자 요청 해석
도구/함수 선택
알려진 후보 집합에서 추출
RAG 구절 필터링
워크플로 분류(Triage)
품질 판단
정책-사례 비교
퍼지 매칭
엔티티 정렬
에스컬레이션 결정

또한 다음과 같은 증상이 있는 코드를 검사하십시오:

LLM → 산문 → 파서 → JSON → 검증 → 재시도

또는:

대규모 정규식 트리
거대한 if/else 의미론적 분류기
임의의 JSON을 반환하는 프롬프트 기반 분류기
제한된 결정을 내리는 데만 사용되는 에이전트 루프
사소한 분류에 사용되는 고가의 추론 모델

이들은 잠재적인 Jev 삽입 지점입니다.

기본적으로 Jev를 사용하지 마십시오

다음과 같은 경우 일반 코드를 선호하십시오:

산술
이미 구조적으로 표현된 정확한 날짜
데이터베이스 조회
정확한 문자열 일치
권한
인가
스키마 검증
결정론적 비즈니스 규칙
알려진 변환
알려진 숫자 정렬
암호화 작업
이미 문제를 안정적으로 해결하는 정확한 파서

필요한 출력이 근본적으로 개방형(open-ended)인 경우 생성 모델(Generative Model)을 선호하십시오:

글쓰기
요약
설명
브레인스토밍
코드 생성
장문 합성
개방형 연구
다단계 추론

Jev는 이러한 시스템 주변에서 제한된 결정을 내려 지원할 수 있지만, 생성적 역할을 강요받아서는 안 됩니다.

1단계 — 판단 경계 찾기

입력부터 결과까지의 워크플로를 검사하십시오.

소프트웨어가 효과적으로 다음과 같이 묻는 모든 지점을 표시하십시오:

"정보는 있지만, 어떤 결정론적 경로를 취해야 할지 알기 전에 그것이 무엇을 의미하는지 이해해야 합니다."

각 후보 경계에 대해 다음을 작성하십시오:

입력 상태: 어떤 정보가 존재합니까?

판단: 어떤 의미론적 결정이 필요합니까?

출력: 코드가 계속 진행할 수 있게 해줄 제한된 값은 무엇입니까?

조치: 코드가 답변으로 무엇을 할 것입니까?

위험: 판단이 잘못되면 어떻게 됩니까?

즉시 Jev를 구현하지 마십시오.

먼저 결정론적 코드가 문제를 더 안정적으로 해결할 수 있는지 확인하십시오.

2단계 — Jev 적합성 테스트 적용

다음 조건의 대부분이 참일 때 판단은 강력한 Jev 후보입니다:

입력에 자연어 또는 맥락적 데이터가 포함됩니다.
필요한 출력을 제한할 수 있습니다.
소프트웨어가 프로그래밍 방식으로 답변을 필요로 합니다.
지식이 풍부한 인간이 신속하게 판단을 내릴 수 있습니다.
판단을 명시적으로 설명할 수 있습니다.
불확실성이 유용한 정보입니다.
결과를 예시나 레이블에 대해 테스트할 수 있습니다.
코드가 판단 후 조치를 소유할 수 있습니다.

다음과 같은 작업이 필요할 때는 회의적이어야 합니다:

깊은 숙고
긴 추론 사슬
많은 종속적인 중간 결론
개방형 생성
자율적 계획

먼저 분해하십시오.

3단계 — 질문을 원자적으로 만들기

Jev 질문은 하나의 일관된 판단을 나타내야 합니다.

나쁨:

이 고객을 분석하고 환불해야 하는지, 화가 난 정도는 어떤지, 사기 가능성은 있는지, 어떤 부서가 처리해야 하는지 결정하십시오.

더 나음:

topic → Choice
refund_requested → Noul
fraud_signal → Noul
frustration → Score

그런 다음 코드에서 이러한 답변을 구성(compose)하십시오.

목표는 다음과 같습니다:

복잡한 행동 = 많은 소규모 판단 + 결정론적 구성

코드가 해당 정책을 명시적으로 표현할 수 있을 때 거대한 의미 질문 안에 애플리케이션 정책을 숨기지 마십시오.

4단계 — 올바른 프리미티브 선택

Choice

정의된 집합에서 정확히 하나의 답변이 선택되어야 할 때 사용하십시오.

형태: 어느 것?

예시:

청구 | 기술 | 영업 | 계정
환불 | 재예약 | 정보
python | javascript | rust | 기타

제공된 옵션이 입력을 모두 포괄하지 못할 수 있는 경우 "기타", "알 수 없음" 또는 "없음" 결과를 추가하십시오.

Noul

참(true)일 확률이 유용한 명제에 사용하십시오.

형태: 이것이 참인가요?

예시:

고객이 환불을 요청합니까?
이 구절이 사용자의 질문에 답합니까?
이 메시지가 자격 증명을 요청합니까?
이력서에 전문적인 Python 경험이 명시되어 있습니까?

출력을 '예'의 확률로 해석하십시오.

~0.5를 "중간 강도"로 해석하지 마십시오.

이는 예/아니오가 거의 동등하게 그럴듯함을 의미합니다.

Score

판단이 정렬된 차원(dimension)에 존재할 때 사용하십시오.

형태: 상태가 이 정의된 스펙트럼의 어디에 해당합니까?

예시:

차분함 / 우려됨 / 매우 좌절함
관련 없음 / 부분적으로 관련 있음 / 강하게 관련 있음 / 직접적인 답변

각 수준은 구체적인 의미 조건을 설명해야 합니다.

의미가 명시적으로 정의되지 않는 한 '나쁨/괜찮음/좋음/훌륭함'과 같은 정의되지 않은 레이블을 사용하지 마십시오.

5단계 — 상태를 신중하게 설계하십시오

질문에 필요한 증거가 포함된 가장 작은 상태를 보내십시오.

구조화된 상태를 선호하십시오:

{
  "ticket": {
    "message": "...",
    "sender": {}
  },
  "customer": {
    "plan": "...",
    "orders": []
  },
  "policy": {
    "refund_policy": "..."
  }
}

하나의 거대한 산문 덩어리보다 낫습니다.

원칙:

포괄적이기보다는 관련성 있게
평평하게 펴기보다는 구조화하여
가정된 모델 지식보다는 관찰된 사실
오래된 내장 지식보다는 현재 정보

관찰된 사실을 추론된 판단과 구별할 수 있게 유지하십시오.

질문이 특정 상태 필드와 관련될 때는 해당 필드를 명시적으로 가리키십시오.

6단계 — 독립적인 질문을 병렬로 수행(Fan Out)하십시오

여러 질문이 동일한 기존 상태에서 답변될 수 있다면, 함께 질문하는 것을 선호하십시오.

                    ┌── topic
                    ├── urgency
상태 ── JEV ───────┼── refund_requested
                    ├── frustration
                    └── fraud_signal

다음과 같이 불필요한 직렬 호출을 생성하지 마십시오:

Jev → 답변 → Jev → 답변 → Jev → 답변

세 질문 모두 원래 상태에서 평가될 수 있었다면 말입니다.

비용이 저렴하고 나중에 유용할 수 있을 때는 추측성 질문을 하십시오.

예시: category, bug_severity, reproduction_quality, refund_requested, frustration

만약 category = billing 이라면, 코드는 버그 관련 답변을 무시하기만 하면 됩니다.

7단계 — 실제 종속성에 대해서만 여러 Jev 단계 사용

두 번째 Jev 요청은 첫 번째 답변이 다음과 같은 경우에 정당화됩니다:

새로운 증거 가져오기
새로운 상태 구성하기
다음 후보 집합 선택하기
어떤 질문이 의미 있게 질문될 수 있는지 결정하기
계층 구조 탐색하기
다음 판단에 필요한 문서 검색하기

예시:

1단계  어떤 제품군?
   ↓
코드가 해당 제품군의 제품을 검색함
   ↓
2단계  어떤 정확한 제품이 가장 잘 일치하는가?

워크플로가 개념적으로 여러 단계를 포함한다는 이유만으로 질문을 직렬화하지 마십시오.

8단계 — 구성을 코드에 유지

Jev는 의미 신호를 생성합니다.

코드는 해당 신호가 운영상 무엇을 의미하는지 결정합니다.

예시:

topic = billing
refund_requested = 0.94
frustration = high

애플리케이션 코드는 다음과 같이 결정할 수 있습니다:

if topic == billing:
    route_to_billing()

if refund_requested > REFUND_FLAG_THRESHOLD:
    add_refund_flag()

if frustration > PRIORITY_THRESHOLD:
    increase_priority()

비즈니스 로직은 검사 가능해야 합니다.

답변이 더 작은 판단들로 구성될 수 있을 때 Jev에게 "우리 전체 애플리케이션이 무엇을 해야 합니까?"라고 묻지 마십시오.

9단계 — 불확실성을 일급 신호로 취급

타입이 지정된 출력을 진실과 동등하게 취급하지 마십시오.

타입이 지정된 출력은 인터페이스가 제한되었음을 의미합니다.

의미 판단이 틀릴 수 없다는 것을 의미하지는 않습니다.

Choice 및 Score의 경우 확률과 신뢰도를 검사하십시오.

Noul의 경우 '예' 확률을 직접 검사하십시오.

다음과 같은 동작을 설계하십시오:

높은 확신 → 자동 경로
중간 확신 → 확인 요청 / 추가 증거 수집 / 더 강력한 모델 / 검토 플래그 지정
낮은 확신 → 추측하지 않음 / 에스컬레이션

임계값은 애플리케이션 정책입니다.

이는 거짓 긍정/부정의 비용, 되돌릴 수 있는 정도, 사용자/재정/보안/규정 영향을 반영해야 합니다.

예제에서 복사한 임계값이 이 시스템에 적합하다는 증거는 아닙니다.

10단계 — 신뢰도 게이트를 위험에 맞추기

하나의 보편적인 신뢰도 임계값을 사용하지 마십시오.

예시:

도움말 문서 표시 — 영향 낮음
지원 티켓 라우팅 — 영향 중간
구독 취소 — 영향 높음
송금 — 영향 매우 높음

의미 판단은 동일할 수 있지만 필요한 확신 수준과 확인 경로는 다릅니다.

영향이 큰 작업의 경우, Jev는 일반적으로 통제된 결정 경계에 정보를 제공해야 하며 부작용을 독립적으로 승인해서는 안 됩니다.

11단계 — 자동화 전에 평가 설계

Jev 경계를 프로덕션화하기 전에 대표적인 사례를 식별하십시오.

포함: 쉬운 긍정 사례, 쉬운 부정 사례, 모호한 사례, 증거 누락 사례, 엣지 케이스, 적대적 사례, 드물지만 비용이 많이 드는 실패 사례.

기록: 상태, 질문, 예상 동작, Jev 답변, 확률/신뢰도, 애플리케이션 조치, 가능할 때 실제 결과(ground-truth outcome).

최상위 레이블이 합리적으로 보이는지 여부만이 아니라 시스템 동작을 평가하십시오.

임계값 기반 시스템의 경우 여러 임계값에서 동작을 측정하십시오.

특히 측정: 적용 범위/자동화 비율, 거짓 긍정 비율, 거짓 부정 비율, 인간 검토 비율, 오류 비용, 지연 시간, 비용.

실제 대상 도메인 데이터를 사용하여 임계값을 조정하십시오.

12단계 — Jev 정책 중앙화

Jev 질문, 기준, 가중치 및 임계값 상수를 찾고 검토하기 쉽게 유지하십시오.

다음과 같은 구조를 선호하십시오:

ai/
  jev/
    questions.*
    thresholds.*
    evaluation/
    client.*

또는 프로젝트에 적합한 동등한 구조.

수십 개의 라우트 핸들러에 의미 정책을 분산시키지 마십시오.

인간 검토자는 다음을 검사할 수 있어야 합니다:

Jev가 무엇을 판단하고 있습니까?
우리가 어떤 정의를 제공했습니까?
어떤 임계값이 어떤 조치를 유발합니까?
어떤 조치를 되돌릴 수 있습니까?
신뢰도가 낮을 때 어떻게 됩니까?

13단계 — 원시 판단 보존

실용적일 때, 유용한 원시 출력을 그로부터 파생된 조치와 별도로 보관하십시오.

예를 들어:

refund_probability = 0.91
frustration_score = 1.72
topic = billing
topic_confidence = 0.88

priority = high만 저장하는 것보다 낫습니다.

이를 통해 임계값 재평가, 가중치 변경, 동작 감사, 모델 버전 비교, 실패 조사 및 다운스트림 분석이 가능합니다.

애플리케이션의 적법한 요구 사항을 넘어서는 민감한 데이터를 보관하지 마십시오.

14단계 — 생성형 AI 주변에서 Jev 찾기

Jev는 LLM을 대체하는 것이 아니라 LLM 주변에서 종종 가치가 있습니다.

예시:

입력 → Jev 가드레일 → LLM → Jev 인용/품질 확인 → 코드가 반환 여부 결정

또는:

쿼리 → 검색 → Jev 관련성/주입 판단 → 선택된 컨텍스트 → 추론 모델

또는:

사용자 요청 → Jev 의도/함수 선택 → 결정론적 타입 함수 → 결과

이를 통해 개방형 생성 모델에 맡겨지는 애플리케이션 제어의 양을 줄일 수 있습니다.

아키텍처 검토 절차

Jev 기회에 대해 기존 시스템을 검토하도록 요청받았을 때:

1. 워크플로 매핑

식별: 입력, 결정론적 단계, 의미 결정, 모델 호출, 파서, 라우터, 도구 호출, 부작용, 인간 검토 지점.

2. Jev 기회 맵 생성

각 후보에 대해:

위치: 현재 코드/모듈/워크플로
현재 방법: 오늘날 판단이 어떻게 이루어지는가
Jev 후보: 예 / 아니오 / 아마도
이유: 제한된 의미 결정이 적절한 이유 또는 부적절한 이유
상태: 필요한 최소 증거
프리미티브: Choice / Score / Noul
질문: 제안된 원자적 판단
구성: 코드가 이를 어떻게 사용해야 하는가
불확실성: 답변이 명확하지 않을 때 어떻게 되는가
위험: 잘못된 판단의 결과
평가: 이를 검증하는 방법

3. 영향력에 따라 우선순위 지정

Jev가 취약한 의미 코드, 반복되는 LLM 파싱, 비용이 많이 드는 사소한 추론 호출, 제한되지 않은 에이전트 루프, 중복된 분류기 또는 명백한 사례에 대한 수동 검토를 대체할 수 있는 기회를 선호하십시오 — 시스템 동작을 제한되고 테스트 가능하게 유지하면서 말입니다.

4. 가장 작은 v 권장

...

Jev 시스템 아키텍트