가입하기 대시보드
2026년 9월 25일
글: Vi Tran 및 Boris Tane

우리는 LLM을 Jev로 교체했습니다. 39% 더 저렴합니다.

Explore with AI

Open in ChatGPT Open in Claude Open in Perplexity

우리는 상시 작동하는 온콜 에이전트를 만들고 있으며, 이 에이전트는 끊임없이 다음과 같은 결정을 내립니다.

  • 이 이슈는 얼마나 심각한가?
  • 이 슬랙 스레드에 먼저 나서야 하는가?
  • 이 인시던트를 이전에도 본 적이 있는가?

지난주까지는 이러한 작업에 LLM을 사용해 왔습니다. 이번 주 Jev에 접근할 수 있게 되자마자 실험을 시작했습니다.

Jev란 무엇인가

Jev는 TypeSafe AI의 결정 모델입니다. 텍스트를 생성하는 대신, 타입이 지정된 값과 보정된 확률로 데이터에 대한 질문에 답합니다. TypeSafe는 이를 “스마트 if문”이라고 소개하며, 직접 작성한 로직이 지나치게 취약해지는 분류, 라우팅, 점수 매기기 단계에 쓰라고 제안합니다. 그리고 출력 토큰은 무료이며 응답당 70~500ms가 걸린다고 밝히고 있습니다. 우리의 에이전트는 하루 종일 이런 결정을 내리기 때문에, 이를 프로덕션에 도입했습니다.

작동 방식

요청은 두 부분으로 구성됩니다. 결정을 내리고자 하는 텍스트나 JSON인 state와, 답을 얻고자 하는 questions입니다. 각 질문은 다음 세 가지 유형 중 하나를 갖습니다.

graph TB S["State: a message, thread, or evaluation case"] --> J["Jev"] Q["Questions"] --> J J --> N["Noul<br/>yes/no"] J --> C["Choice<br/>pick an option"] J --> R["Score<br/>rate against a rubric"] style J fill:#d1fae5,stroke:#6ee7b7,color:#065f46 style N stroke:#3b7dd8,color:#2b5fa8 style C stroke:#3b7dd8,color:#2b5fa8 style R stroke:#3b7dd8,color:#2b5fa8

  • Noul은 yes일 확률을 반환합니다.
  • Choice는 제공된 옵션 중 하나를 선택합니다.
  • Score는 정렬된 평가 기준에 따라 확률로 가중된 값을 반환합니다.

활용 사례 1: 라우팅, 즉 에이전트는 언제 응답해야 하는가

우리 에이전트는 Slack과 Github에서 먼저 나서서 행동합니다. 사용자에게 제공할 만한 의미 있는 통찰이 있을 때 Slack 메시지나 Github 댓글에 응답합니다. 에이전트는 사용자가 요청할 때 행동해야 하며, 모든 이벤트에 과잉 반응해서는 안 됩니다. 이는 Jev의 Noul 질문에 딱 맞는 활용 사례입니다.

flowchart LR E["New event"] --> M["PR comment<br/>Slack message"] M --> J["Jev Noul<br/>Triage?"] J -->|Yes| W["Wake agent<br/>to follow up"] J -->|No| N["No action"] style J fill:#77a52d,stroke:#5c8023,color:#ffffff style W stroke:#77a52d,color:#5c8023 style N fill:#e5e5e8,stroke:#d1d2d6,color:#47484d

  • 에이전트가 제출한 PR에 달린 댓글: 리뷰어가 변경을 요청하면 에이전트가 깨어납니다. CI 상태 업데이트나 “고맙습니다” 같은 댓글에는 반응하지 않습니다.
  • Slack 채널: 에이전트는 인프라에 대한 직접적인 질문처럼 명확하게 도움이 될 수 있을 때만 초대받지 않고도 끼어듭니다. 사람들끼리 조율하는 대화에는 관여하지 않습니다.
  • 에이전트가 속한 Slack 스레드: 자신에게 향한 메시지에만 답하고, 사람들끼리 나누는 대화는 무시하며, 누군가 나가 달라고 요청하면 나갑니다.

다음은 에이전트가 Slack 메시지에 후속 조치를 해야 하는지 판단하는 Jev 요청의 예시입니다.

{
  "model": "jev-1.13.0",
  "state": {
    "slack_channel": "#Deployment",
    "user_message": "Watch this PR until fully deployed"
  },
  "questions": {
    "respond": {
      "type": "noul",
      "instructions": {
        "question": "Should the agent follow up on this user message?"
      }
    }
  }
}

우리는 Jev를 약 일주일간 실행하며 이 작업에 이전에 사용하던 LLM과 비교했습니다.

P90 latency

ms
DeepSeek V4.1 Flash 1,466 ms
Jev 472 ms

Cost per 1,000 calls

USD
DeepSeek V4.1 Flash $0.238
Jev $0.123
Figure 1
응답 라우팅: 호출 1,000건당 지연 시간과 비용

라우팅은 P90 기준 3배 빨라져 1.5초에서 500ms 미만이 되었고, 비용은 거의 절반으로 줄었습니다.

활용 사례 2: 분류, 즉 증거는 무엇을 의미하는가

우리는 에이전트가 여러 항목을 서로 다른 범주로 분류해야 하는 작업도 몇 가지 실행합니다. 예를 들어, 제공된 증거를 바탕으로 에이전트가 이슈 조사를 시작해야 하는지, 기존 이슈와 관련이 있다고 보고 접어야 하는지, 아니면 이전에 해결된 이슈의 중복인지를 판단합니다.

Jev Choice 질문은 그 증거를 우리가 정의한 기준에 따라 하나의 레이블로 변환하며, 다음 단계는 그 레이블에 따라 결정됩니다. 다음과 같은 형태입니다.

flowchart LR I["New incident"] --> E["Evidence from tool calls"] E --> J["Jev Choice"] J -->|Same root cause| D["Defer to the original"] J -->|Related| L["Link both incidents"] J -->|Independent| N["Investigate on its own"] style J fill:#77a52d,stroke:#5c8023,color:#ffffff style D stroke:#77a52d,color:#5c8023 style L stroke:#77a52d,color:#5c8023 style N fill:#e5e5e8,stroke:#d1d2d6,color:#47484d

우리는 이러한 방식으로 세 가지 분류를 실행합니다. 각각 명시적인 기준을 가진 Choice 질문을 사용하며, 각각 서로 다른 LLM을 대체했기 때문에 개별적으로 측정했습니다.

이 인시던트들은 서로 관련이 있는가

새로운 인시던트가 발생하면 에이전트는 이를 기존 인시던트와 비교합니다. 근본 원인이 같은지, 관련이 있는지, 아니면 서로 독립적인지를 판단합니다. 이 예시는 후보 하나만 보여주지만, 실제 프로덕션 호출에서는 동일한 새 인시던트에 대해 여러 후보를 비교합니다.

{
  "model": "jev-1.13.0",
  "state": {
    "incident": "Checkout cannot authenticate to the database.",
    "candidate_0": "Billing cannot authenticate to the same database.",
    "evidence": "Both services use a credential revoked at 14:00."
  },
  "questions": {
    "candidate_0": {
      "type": "choice",
      "instructions": "How is candidate_0 connected to the new incident?",
      "criteria": {
        "duplicate_same_root_cause": "One underlying problem explains both",
        "related": "Distinct problems share a trigger or blast radius",
        "independent": "No evidenced connection"
      }
    }
  }
}

이 활용 사례에서 Jev로 전환한 결과, P90 기준 거의 8배 빨라져 2.9초에서 400ms 미만이 되었고, 비용은 27% 저렴해졌습니다.

P90 latency

ms
GPT-OSS 120B 2,859 ms
Jev 373 ms

Cost per 1,000 calls

USD
GPT-OSS 120B $0.388
Jev $0.285
Figure 2
인시던트 연결성: 호출 1,000건당 지연 시간과 비용

우리가 제출한 이 PR은 왜 닫혔는가

우리 에이전트는 개발자에게 풀 리퀘스트를 제출하며, 병합률은 우리의 핵심 성공 지표 중 하나입니다. 제품을 개선하려면 풀 리퀘스트가 왜 닫히는지 이해해야 합니다.

우리 PR이 병합되지 않은 채 닫히면, 에이전트는 리뷰, 논의, 그리고 다른 작업에 대한 참조를 읽은 뒤 이유를 선택합니다. 수정이 잘못되었는지, 사람이 다른 방식으로 고쳤는지, 이슈가 오탐이었는지, PR이 방치되어 오래되었는지, 아니면 의도된 동작이었는지입니다.

이 활용 사례에서 Jev로 전환한 결과, P90 지연 시간은 6배 빨라졌지만 비용은 17%만 저렴해졌습니다.

P90 latency

ms
GPT-OSS 120B 2,379 ms
Jev 416 ms

Cost per 1,000 calls

USD
GPT-OSS 120B $0.123
Jev $0.102
Figure 3
수정 PR 종료 사유: 호출 1,000건당 지연 시간과 비용

이 풀 리퀘스트는 얼마나 시급한가

개발자에게 풀 리퀘스트를 제출하기 전에, 우리 에이전트는 더 심각한 사안이 위로 올라오도록 순위를 매겨야 합니다. 이 분류에서 에이전트는 근본 문제를 critical부터 info까지 등급으로 평가합니다. 가정에 따른 위험이 아니라 현재의 영향을 평가합니다.

P90 latency

ms
DeepSeek V4.1 Flash 1,456 ms
Jev 313 ms

Cost per 1,000 calls

USD
DeepSeek V4.1 Flash $0.197
Jev $0.081
Figure 4
자동 수정 심각도: 호출 1,000건당 지연 시간과 비용

여기서 Jev로 전환한 결과 비용이 크게 줄었습니다. DeepSeek V4.1 Flash보다 59% 저렴해졌고, P90 기준 거의 5배 빨라졌습니다.

Jev는 모든 분류 작업에서 더 빠릅니다. GPT-OSS 120B를 대체한 경우에는 이득이 대부분 지연 시간에서 나타납니다. DeepSeek V4.1 Flash를 대체한 경우에는 비용도 절반 이상 줄었습니다.

활용 사례 3: 순위 매기기, 즉 이 클라우드 리소스는 얼마나 중요한가

Polylane을 최대한 활용하려면 팀은 클라우드 계정을 연결합니다. 우리는 모든 클라우드 리소스에 대한 컨텍스트 그래프를 만들어, 에이전트가 컴퓨트 노드, 데이터베이스, 큐 등의 관계를 빠르게 파악할 수 있도록 합니다.

플랫폼에는 노드가 수만 개에 달하는 매우 바쁜 클라우드 계정을 가진 팀도 있습니다. 각 서버, 샌드박스, 데이터베이스, 큐는 우리 컨텍스트 그래프의 노드입니다. 에이전트가 애플리케이션에서 무엇이 중요하고 무엇은 실패해도 “괜찮은지” 알 수 있도록 이러한 노드마다 순위를 매길 필요가 있습니다.

각 리소스에는 Critical, Standard, Low, Minimal 중 하나의 우선순위 티어를 부여합니다.

flowchart LR C["Cloud account"] --> G["Context graph"] G -->|Each node + metrics| J["Jev Choice"] J --> T1["Critical"] J --> T2["Standard"] J --> T3["Low"] J --> T4["Minimal: fine to fail"] style J fill:#77a52d,stroke:#5c8023,color:#ffffff style T1 stroke:#77a52d,color:#5c8023 style T2 stroke:#77a52d,color:#5c8023 style T3 stroke:#77a52d,color:#5c8023 style T4 fill:#e5e5e8,stroke:#d1d2d6,color:#47484d

Jev는 구성, 환경, 최근 메트릭, 의존 관계를 바탕으로 한 컨텍스트와 함께 각 리소스에 대해 Choice 질문을 평가합니다.

{
  "model": "jev-1.13.0",
  "state": {
    "instructions": "Assign importance relative to the other resources in this cohort.",
    "cohort": [
      {
        "id": "database-a",
        "environment": "production",
        "daily_queries": 80000,
        "dependents": 6
      },
      {
        "id": "database-b",
        "environment": "preview",
        "daily_queries": 0,
        "dependents": 0
      }
    ]
  },
  "questions": {
    "resource_0": {
      "type": "choice",
      "instructions": "Assign the importance tier for database-a.",
      "criteria": {
        "1": "Critical: substantial production traffic or blast radius",
        "2": "Standard: active and operationally relevant",
        "3": "Low: limited activity or importance",
        "4": "Minimal: idle or disposable, without meaningful dependents"
      }
    }
  }
}

순위 매기기는 Jev가 가장 빛을 발하는 영역입니다. P90 기준 10배 넘게 빨라져 5.4초에서 약 0.5초가 되었고, 비용은 34% 저렴해졌습니다. 또한 우리 결정 중 가장 호출량이 많은 작업이라, 전체 절감의 대부분을 차지합니다.

P90 latency

ms
GPT-OSS 20B 5,445 ms
Jev 511 ms

Cost per 1,000 calls

USD
GPT-OSS 20B $0.817
Jev $0.542
Figure 5
리소스 순위 매기기: 호출 1,000건당 지연 시간과 비용

요약

전반적으로 Jev는 호출 1,000건당 지연 시간과 예상 비용을 크게 줄였습니다.

  • P90 지연 시간 감소: 4,752 ms —> 508 ms.
  • 호출 1,000건당 비용 감소: $0.76199 —> $0.46369.

P90 latency

ms · lower is better
LLMs
4,752 ms
Jev
508 ms

Cost per 1,000 calls

USD · lower is better
LLMs
$0.76199
Jev
$0.46369
Figure 6
Jev vs LLMs on P90 latency and cost per 1,000 calls
89.3%
faster at P90
4,752 ms to 508 ms
39.1%
lower cost per 1,000 calls
$0.76199 to $0.46369 per 1,000 calls

모델별로 보면 Jev는 가장 빠르면서도 가장 저렴합니다. DeepSeek V4.1 Flash보다 약간 저렴하고, 두 GPT-OSS 모델보다 훨씬 낮습니다.

Swipe to see every point.

$0.00 0 ms $0.25 1,500 ms $0.50 3,000 ms $0.75 4,500 ms $1.00 6,000 ms P90 latency (lower is better) Cost per 1,000 calls (lower is better) OpenAI GPT-OSS 20B: P90 latency 5,445 ms, Cost per 1,000 calls $0.82 OpenAI GPT-OSS 20B DeepSeek V4.1 Flash: P90 latency 1,372 ms, Cost per 1,000 calls $0.51 DeepSeek V4.1 Flash OpenAI GPT-OSS 120B: P90 latency 2,255 ms, Cost per 1,000 calls $0.74 OpenAI GPT-OSS 120B TypeSafe AI Jev: P90 latency 508 ms, Cost per 1,000 calls $0.46 TypeSafe AI Jev
Figure 7
모델별 호출 1,000건당 지연 시간과 비용

에이전트가 정해진 답변 집합 중에서 선택해야 하는 곳이라면, 이제 Jev가 기본값입니다. 우리가 옮긴 모든 결정에서 더 빠르고 더 저렴합니다.

아무도 온콜을 서지 않아야 합니다. Polylane은 인프라를 지켜보고, 조사하고, 고장 난 것을 고칩니다.

가입하기

계속 읽기

2026. 9. 21. 슬롭이 프로덕션에 배포되지 않도록 막는 방법 파이프라인의 어떤 것도 변경 사항이 프로덕션에 안전한지 묻지 않습니다. 이것이 저희가 만든, 그 질문에 답하는 검사이며, 어떻게 테스트보다 먼저 끝나도록 만들었는지에 대한 이야기입니다. 2026. 9. 14. Sub-agents are just wrong Polylane's autofix used to be a workflow of multiple agents, each responsible for a single task, with an orchestrator managing state between them. We moved to a single agent which does the entire job, from evidence gathering, hypothesis testing to pull request. 2026. 8. 26. Cloudflare Durable Objects의 메모리 초과 오류를 고친 방법 Cloudflare Durable Objects는 128 MB 하드 리밋이 있는 V8 isolate에서 실행됩니다. 저희 것은 유휴 상태에서 ~140 MB였고 하루에 ~300번 리셋되었습니다. 130 MB의 zod 스키마가 모듈 로드 시 만들어졌고, 대부분은 한 번도 호출되지 않는 코드가 만든 것이었습니다. 프로덕션 번들을 프로파일링한 방법, 두 가지 수정, 그리고 숫자들. 218 MB에서 82 MB로, 리셋은 0으로.
모든 글 RSS feed